[RFC] New state representation for Arbitrum: proof-format change and request for feedback

Technical Discussion
1

Abstract

Offchain is researching a change to how Arbitrum commits to its state: replacing the Merkle-Patricia Trie (MPT) with a new verifiable data structure (plus auxiliary verifiable structures). The primary motivation for this change is to scale Arbitrum chains to new heights that optimizing the MPT cannot alone achieve. The change would alter the format of the proofs returned by eth_getProof and may change the hash function. Applications and end users are not expected to be impacted.

This Request For Comment (RFC) is meant to both (1) solicit feedback from the ecosystem and community, especially from those who verify Arbitrum state proofs, to understand potential downstream impacts & tradeoffs as well as to (2) raise awareness of our prospective plans for this change.

Again, please note that this effort is at the research-stage only and this post does not yet formally signal our intention to pursue this change.

Motivation

Access to the state trie sits on the critical path of every block and is understood to be one of the primary execution bottlenecks as Arbitrum scales.

Optimizing how the current MPT is stored (e.g. cross-block caching, replacing the disk database that persists the tree like what Monad’s MonadDB and Base’s TrieDB do for the MPT by swapping databases like LevelDB for specialized on-disk layouts) certainly helps, but we believe the potential upside in changing the data structure itself may yield larger benefits in the long run.

Changing the structure also has the added benefit of reducing load on disks, lowering the long term cost and hardware floor for running a node. Lastly, this type of change will keep Arbitrum’s state layer competitive with the broader field: several high-throughput chains and research efforts have already moved from the older MPT to more modern verifiable data structures (e.g. LayerZero’s QMDB, MegaETH’s SALT, Monad’s MonadDB).

Rationale

Arbitrum scales Ethereum without compromising its security or decentralization, and this change advances that mission on the terms the community cares about:

  • State remains authenticated and proofs remain verifiable, so the trust model — including settlement and fraud-proof security — is preserved.

  • A lower hardware floor supports decentralization by making it cheaper to run independent nodes and validators.

The change is designed to minimize ecosystem disruption: eth_getProof remains supported (though the proof format and proof-checking procedure change) and apps and users are not expected to be affected. Meanwhile, teams who need to migrate would be given a reference implementation, ample time, and support from Offchain to do so.

Lastly, this change would proceed transparently through the standard governance process — an ArbOS upgrade and a Constitutional DAO vote — consistent with the DAO’s commitment to open, community-governed evolution of the protocol.

Key terms

  • State root / commitment: the single hash in each block header that commits to all account and storage state (at that block height).

  • MPT: the Merkle-Patricia Trie structure that both Ethereum and Arbitrum use today to produce that commitment.

  • eth_getProof: the JSON-RPC method (EIP-1186) that returns a Merkle proof of an account or storage slot, verifiable against the state root.

  • Proof verification: third-party code that checks such a proof against a trusted state root (in an off-chain library, an on-chain verifier contract, or a ZK circuit).

Specification

What would change

  • The state representation moves from a single MPT root to a new verifiable data structure plus auxiliary verifiable data structures. The exact schema and structures are still an area of active research, but any feedback or questions are most welcome!

  • The format of eth_getProof proofs changes (different underlying tree); the hash function may change as well. We may also version the payload returned from this method.

  • Proof-verification code that targets the current MPT/keccak/RLP schema must be updated to prove using the new schema.

What would not change

  • Apps and end-user behavior: contracts, reads/writes, and opcode-level gas pricing are not expected to be impacted or changed.

  • eth_getProof remains a supported method for teams (but the payload will be different, potentially versioned).

  • A reference implementation of the new proof-checking logic will be provided.

Request for feedback

If you build on or around Arbitrum, replies to any of the following would help us scope impact:

  1. Do you consume Arbitrum account/storage proofs (e.g. eth_getProof), and for what?

  2. Do you verify those proofs yourself (vs. reading the returned values)? If so, where does verification run — off-chain library, on-chain verifier contract, or ZK circuit?

  3. If the proof format (and possibly the hash function) changed, what would migration require, and what lead time would you need?

  4. How sensitive are your workflows to the data size of the proof, if at all?

  5. ZK teams: which hash functions are cheapest in your circuits (keccak, SHA-256, Poseidon, …), and would you want input into the choice?

Replies welcome in this thread or feel free to email us at dlee@offchain.io.

1 Like
2

I broadly agree that moving beyond the current MPT can be an important step for Arbitrum’s long‑term scalability and for lowering the hardware floor for node operators. At the same time, I think we should be explicit that this direction inevitably shifts non‑trivial migration costs onto infra, bridge, and ZK teams who rely on eth_getProof and custom proof verification today.

Right now, most tokenholders will only see “apps and users are not expected to be impacted” and “standard governance process,” but may not fully appreciate the downstream engineering and coordination burden for those who do the heavy lifting under the hood. That is not a reason to avoid the change, but a reason to design the process very carefully.

A few suggestions before this evolves into any future ArbOS upgrade / AIP:

  • Clearly separate the technical design decision from any implementation / migration budget that might be requested later, so the DAO can evaluate each on its own merits.

  • Provide more concrete estimates (even if rough) of expected performance gains vs. the migration work required for proof consumers, not just the benefits at a high level.

  • Consider some form of funded migration support (tooling, reference circuits, grants) for external teams who will need to update their verification logic.

  • Explore options for independent technical review of the final design before the DAO is asked to approve an implementation and any associated spend.

I appreciate Offchain opening this up at the research stage and would be happy to engage further as the design and its ecosystem impact become clearer. @offchainlabs

2 Likes