Fast mode
Fast mode in an nutshell
Architecture
Aligned’s architecture is shown in the figure below:
Here, the validators/AVS operators are the ones responsible for proof verification. They fetch the proof data from the data service and verify it using the different proving systems supported by Aligned.
Flow for sending a proof and publishing the result on Ethereum
The flow for sending a proof and having the results on Ethereum is as follows:
The user uses a provided CLI or SDK to send one proof or many to the batcher, and waits.
The batcher answers with a BatchInclusionData for each proof.
The user invokes the VerifyBatchInclusion function in the ServiceManager contract with this data to check that the proof has been verified in Aligned and is included in the batch.
Then, it is checked that the commitment of the proven program matches the expected one.
Full flow with internals of the proof
The user uses a provided CLI or SDK to send one proof or many to the batcher, and waits (Alternatively, the user can run a batcher or interact directly with Ethereum).
The batcher accumulates proofs of many users for a small number of blocks (typically 1-3).
The batcher creates a Merkle Tree with commitments of all the data submitted by users, uploads the proofs to the Data Service, and creates the verification task in the ServiceManager.
The operators, using the data in Ethereum, download the proofs from the DataService. They then verify that the Merkle root is equal to the one in Ethereum, and verifies all the proofs.
If the proofs are valid, they sign the root and send this to the BLS signature aggregator.
The signature aggregator accumulates the signed responses until reaching the quorum, then sends the aggregated signature to Ethereum.
Ethereum verifies the aggregated signatures and changes the state of the batch to verified.
Last updated
