Worker Integration: Data Availability Sample Integration
This guide showcases sample code and testing steps for DA worker integration with Crestal. Use it to explore how to set up listeners, submit a test deployment request and proof of deployment, to understand the flow before implementing a production setup.
# Clone the SDKgit clone https://github.com/crestalnetwork/crestal-js-sdk.git# Install and buildcd crestal-js-sdknpminstall# or yarnnpm run build # or yarn build
When you run the event listener, it listens for incoming RequestProposal events on the specified network. These events contain detailed information about the proposal request, including the projectID, requestID, and parameters like chainRequestParam that describe the required data availability (DA) configuration.
The chainRequestParam field in the RequestProposal event provides all the necessary information required to craft and submit a proposal.
The proposal we are sending now for test purposes doesnโt have to match the request exactly, as they are dummy values, but it must conform to the required format.
For detailed guidance about proposals, refer to the Solver Integration Walkthrough.
We are going to submit a proposal with private worker, this means that we mention a specific worker that will be the only one who can
make the deployment. To do this, weโll use utils/examples/submitPrivateProposalExample.ts.
Populate Required Variables:
solver_address: Your account address as a solver.
project_id: Use the project_id from the event listener output.
request_id: Use the request_id from the event listener output.
privateKey: The private key for the solver_address.
worker_address: The address of the worker handling the deployment. This can be the same as the solver address.
Use the following command to run the script and submit the proposal:
The deployment request must be submitted to both the backend and the smart contract. For private proposals with a private worker, the request only needs to be submitted to the backend.
The Deployment type represents the data structure required for submitting deployment requests.
It also contains the proposal itself. The deployment details are also included in this type, but they are only
required when submitting the proof of deployment.
The requestId and projectId can be extracted from the RequestPrivateDeployment event.
exportinterfaceDeployment{ request_id:string;// Required field, unique ID for the deployment request chain_id:number; project_id?:string;// Optional field, project ID from the Crestal website worker_name?:string;// Optional field, name of the worker worker_address:string;// Required field, worker's Ethereum address in hex format solver_address:string;// Required field, solver's Ethereum address in hex format status: DeployStatus;// Required field, current status of the deployment proposal_hash?:string;// Optional field, hash of the proposal proposal?: object;// Optional field, serialized JSON string of the proposal deployment_details?: DeploymentDetails ;// Optional field, serialized JSON string of the deployment details}
However, in a real-world scenario, the actual data for the proposal can be extracted from the RequestPrivateDeployment eventโs decodedProposal field. Hereโs an example:
The deployment status needs can be updated by submitting requests to the backend.
To achieve this, you can use the utils/examples/updateDeploymentExample script.
Use the same projectId and requestId from Step 5. In the example, the status is set to deployed, indicating that the deployment has been successfully completed.
For the full list of possible statuses please check Step 5.
After the status is updated to deployed, the frontend will automatically update the status to Generating Proof. This signifies that the deployment is complete and now awaits the submission of the Proof of Deployment.
To submit to the smart contract, use the example from utils/examples/submitDeploymentProofContract.ts.
The format that needs to be submitted is of type ProofOfDeploymentContract.
The deployment process is now fully completed. The Proof of Deployment has been submitted to both the backend and the smart contract, and all events have been processed successfully. Verify on the frontend that the deployment status reflects the completion, confirming that everything is finalized.