Proving - RISC Zero
Our proving will look similar to Anatoly's SVM fraud proofs SIMD, which is itself similar to John Adler's insight that state serialization is expensive, and it is possible to avoid it.
Specifically, we want to avoid reintroducing a Merkle tree into the SVM. We experimented with inserting a Sparse Merkle Tree into the SVM early on, but updating the Merkle tree after each transaction results in substantial performance hits. Proving without a Merkle tree rules out existing generalist rollup frameworks like the OP Stack as a basis for SVM rollups, and it also requires a more creative fault proof architecture.
At a high level, a fault proof requires:
A commitment to inputs for a transaction,
The transaction itself, and
Proof that re-executing the transaction leads to a different output than what was specified onchain.
The input commitment is typically made by providing the Merkle root for the rollup's state tree. Our executor will instead post a list of inputs and outputs (including account hashes and relevant global state) for each transaction, along with an index of the transaction which produced each input. The transactions are published to Celestia, so any full node can follow along to pull input accounts from its own state, compute the output accounts, and confirm that the commitment on Ethereum is correct.
There are two possible types of major faults:
Incorrect outputs - In this case, the verifier provides a ZK proof onchain of the correct outputs. We're using RISC Zero to create ZK proofs of SVM execution, continuing our previous work proving BPF bytecode execution. This allows our settlement contract to ensure correctness without having to run the transactions themselves onchain.
Incorrect inputs - In this case, the verifier posts onchain a reference to the historical data showing that the input state is not as claimed. Using Celestia's Quantum Gravity Bridge, our settlement contract ensures that this historical data does indeed prove fraud.
Last updated