Axiom V2 Docs Old
  • Introduction
    • What is Axiom?
    • Quickstart
  • Examples
    • Autonomous Airdrop
      • AxiomREPL Code
      • Contract
      • Web App
      • DataQuery-only Version
  • Developers
    • Axiom for Developers
    • Specifying a Query into Axiom
    • AxiomREPL
      • AxiomREPL Examples
    • Exporting a Client Side Prover
    • Handling Axiom Callbacks
    • Common Issues
      • Callback Debugging
  • SDK and REPL Reference
    • Axiom SDK Reference
      • QueryBuilderV2
      • Data Subqueries
        • Header Subquery
        • Account Subquery
        • Storage Subquery
        • Transaction Subquery
        • Receipt Subquery
        • Solidity Nested Mapping Subquery
    • AxiomREPL Reference
      • Circuit Types
      • Circuit Functions
      • Data Functions
      • Compute Functions
  • Protocol Design
    • Architecture Overview
    • Caching Block Hashes
    • Axiom Query Protocol
      • Axiom Query Format
    • ZK Circuits for Axiom Queries
    • Ethereum On-chain Data
    • Guardrails
  • Transparency and Security
    • KZG Trusted Setup
    • Contract Addresses
    • On-chain ZK Verifiers
    • Security
  • Zero Knowledge Proofs
    • Introduction to ZK
    • ZK Examples
    • Getting Started with halo2
    • halo2-repl
  • Additional Resources
    • Axiom V2 Explorer
    • Github
    • Website
    • Telegram
    • Discord
    • Axiom V1 Docs
Powered by GitBook
On this page
  1. Protocol Design

Ethereum On-chain Data

A review of Ethereum data structures

PreviousZK Circuits for Axiom QueriesNextGuardrails

Last updated 1 year ago

On-chain data in Ethereum is stored in four different mappings, each of which are encoded in a . Each block header contains commitments to these four tries, thereby committing to all of the current Ethereum state. The types of data this comprises are:

  • : This is a mapping between keccak(address) and rlp(acct), where rlp denotes the serialization and acct is the array [nonce, balance, storageRoot, codeHash] of information associated to each Ethereum account.

  • : Each account has a storage trie which is a mapping between keccak(slot) and rlp(slotValue) which encodes the storage of each account, which is a mapping between the uint256 slot and uint256 slot value.

  • : Each block also commits to the transactions in that block via a mapping between the encoded transaction index rlp(txIndex) and the serialization TransactionType . TransactionPayload or LegacyTransaction. The serialization of a transaction is specified in the documentation.

  • : Finally, the receipts trie commits to a mapping between the encoded receipt index rlp(receiptIndex) and the serialization TransactionType . ReceiptPayload or LegacyReceipt. The serialization of a receipt is specified in the documentation.

The block header of each block contains the roots stateRoot, transactionsRoot, and receiptsRoot, which together commit to each of these tries and thus all of the Ethereum on-chain data.

Merkle-Patricia trie
State trie
RLP
Storage trie
Transaction trie
EIP 2718
Receipt trie
EIP 2718