karnotxyz / madara-orchestrator Goto Github PK

Implement proof registration job here -

1. Assume that you already have the proof stored in S3 (or some equivalent storage) with the URL inside metadata of the job.
2. Fetch the proof from the storage
3. Submit the proof on chain
   • this part must be generalised across verification layers (Ethereum or Starknet for now)
   • for start, we can implement this for Ethereum inside settlement_clients just like how we do it for da_clients in #7.
   • use the Zaun repo to interact with the Ethereum verifier contracts

Currently, we send a hardcoded value of 30mn. We should fix this and make it the approximate gas it takes to send a DA transaction with state update to avoid loss of money.

Fact registry is used for storing succinct evidences of successful proof verification.
https://github.com/starkware-libs/starkex-contracts/blob/master/scalable-dex/contracts/src/components/FactRegistry.sol

Implement state update job here -

1. Assume the proof has been verified on the base chain already
2. Make the state update generic across settlement layers (Etheruem or Starknet for now)
3. Implement the logic inside settlement_clients similar to how its done in #7
4. If the PR #12 is already in progress, sync with it to avoid conflicts
5. For Ethereum, implement update_state_blobs. We need to figure out how to calculate kzg_proof here
6. For Starknet, implement update_state_calldata. We need to figure out how to calculate onchain_data_hash and onchain_data_size here

Ethereum 4844 DA support should be added with this PR - #7. Adding new DA layers should be very similar to this approach. The steps would be

1. Create a new crate inside da_clients
2. Implement the DaClient trait from da-client-interface
   • publish_state_diff: push the data on chain and return the txn_hash
   • verify_inclusion: taking the txn_hash as input, check if the txn has been finalized on chain

Complete the SNOS job implementation over here -

1. We plan to add an endpoint on Madara called getSnosInput. For now, we can assume this endpoint exists and we can call it to get the SNOS input - https://github.com/keep-starknet-strange/snos/blob/da26557078111b5d489154b162f3f810174f5b69/src/io/input.rs#L19
2. Use this input to execute the SNOS and get the PIE
3. Store the PIE in a database/S3. I think storing in S3 might make more sense as we won't really need to query the database
4. To add S3 support, we can add a generalised trait like we do for database and queues already

Running the orchestrator requires knowledge about multiple contract addresses - core contracts, verifier, memory page registry etc. We need to add these in the config