ZK Circuits for Axiom Queries

The ZK circuits underlying Axiom historic data queries.

Axiom proves in ZK that historic Ethereum on-chain data is committed to in block headers of the corresponding Ethereum block. In this page, we explain the structure of this commitment and how Axiom uses ZK circuits to prove it.

Account and Storage Proofs

Account and account storage data is committed to in an Ethereum block header via several Merkle-Patricia tries. Inclusion proofs for this data into the block header are provided by Ethereum light client proofs. For example, consider the value at storage slot slot for address address at block blockNumber. The light client proof for this value is available from the eth_getProof JSON-RPC call and consists of:

• The block header at block blockNumber and in particular the stateRoot.

• An account proof of Merkle-Patricia inclusion for the key-value pair (keccak(address), rlp([nonce, balance, storageRoot, codeHash])) of the RLP-encoded account data in the state trie rooted at stateRoot.

• A storage proof of Merkle-Patricia inclusion for the key-value pair (keccak(slot), rlp(slotValue)) of the storage slot data in the storage trie rooted at storageRoot.

Verifying this light client proof against a block hash blockHash for block blockNumber requires checking:

• The block header is properly formatted, has Keccak hash blockHash, and contains stateRoot.

• The state trie proof is properly formatted, has key keccak(address), Keccak hashes of each node along the Merkle-Patricia inclusion proof match the appropriate field in the previous node, and has value containing storageRoot.

• A similar validity check for the Merkle-Patricia inclusion proof for the storage trie.

ZK Circuits for Account and Storage Proofs

Axiom verifies light client proofs in ZK using the open-source axiom-eth ZK circuit library, which supports the following operations in ZK:

• Parsing RLP serialization: Ethereum data is serialized in the Recursive Length Prefix (RLP) format. We support parsing of individual fields in RLP-serialized fields and arrays.

• Merkle-Patricia trie inclusion: All Ethereum data is committed to in 16-ary Merkle-Patricia tries whose roots are in the block header. We support inclusion proofs into trie roots, which are used to prove inclusion into the account and storage tries.

• Ethereum block header, account, and storage proofs: We enable proving fields in the block header, account, and account storage relative to a block hash. This includes:

  • Parsing block header fields in a block.

  • Proving the balance, nonce, storageRoot, and codeHash for an account.

  • Verifying lookups into an account's local storage mapping.

The end result of these are ZK circuits for block headers, accounts, and account storage, which prove validity of the block statements:

Assuming the block hash at blockNumber is blockHash, the state root is stateRoot.

the account statements:

Assuming the state root is stateRoot at a given block, the account value for address is [nonce, balance, storageRoot, codeHash].

and storage statements:

Assuming the storage root for an account is storageRoot, the value of the storage at slot is slotValue.

Combining these circuits together gives ZK circuits for account and storage proofs.

Aggregating Proofs in Queries

To fulfill queries into Axiom with ZK proofs verified against Merkle mountain ranges cached in AxiomV1, we put together ZK circuits for account and storage proofs from the previous section with ZK circuits verifying Merkle inclusion proofs into Merkle mountain ranges. For a query in the Axiom Query Format, we generate ZK proofs of:

• Merkle inclusion proofs of each block hash in a Merkle mountain range in the format cached in AxiomV1.

• Proofs of the stateRoot in the block header committed to in each block hash.

• Account proofs for each queried account relative to its stateRoot which in particular establishes the storageRoot of the account.

• Storage proofs for each queried storage slot relative to its storageRoot.

• Consistency between the block hashes, state roots, and storage roots referenced in the four previous proofs.

We then use proof aggregation with the snark-verifier library developed by the Privacy Scaling Explorations group at the Ethereum Foundation to aggregate these ZK proofs and verify them on-chain. See On-chain ZK Verifiers for a list of the deployed on-chain verifiers used in Axiom.