@offchain
The scalability objective is clear, but this RFC currently begins one architectural layer too late.
The discussion is centered on the representation and interface layer: which authenticated structure should replace the MPT, which hash function should be used, how large the new proofs will be, and how existing eth_getProof consumers will migrate.
Those questions matter, but they are downstream.
The first protocol-level question is:
What exact invariant will prove that every block still commits to one and only one logical state when a single MPT is replaced by a primary authenticated structure plus one or more auxiliary authenticated structures?
Until that invariant is specified, proof-format versioning and verifier migration are premature.
Authenticated components do not automatically compose into an authenticated state. Every individual root may be cryptographically valid while the collection of roots is semantically inconsistent.
- Define the logical state before selecting its representation
The MPT is a representation of Arbitrum state. It is not the state itself.
Before evaluating replacement structures, the design needs a representation-independent definition of the logical state committed at block N.
At minimum, that definition must fix:
account identity and key derivation;
nonce, balance, code hash, and storage semantics;
account existence and non-existence;
storage-slot existence and zero-value semantics;
deletion and recreation behavior;
canonical serialization;
update ordering within a block;
treatment of empty and default values;
historical-state semantics;
the exact post-state boundary committed by the block.
The required invariant is not that the old and new roots are equal. Different structures will necessarily produce different roots.
The invariant is that they decode to the same logical state:
DecodePrimary(PrimaryRoot_N) = LogicalState_N
For every auxiliary structure:
DecodeAux_i(AuxRoot_i,N) = Project_i(LogicalState_N)
where Project_i is a precisely defined projection of the canonical logical state.
That projection cannot remain implicit in implementation code. It must be normative.
Otherwise, two implementations can agree on the primary root while disagreeing on what an auxiliary root is supposed to represent, or each auxiliary structure can verify internally while referring to a different effective state boundary.
2. Classify every auxiliary structure before using it
Every auxiliary structure must belong to exactly one of two categories.
A. Non-consensus derived structure
This is an index, cache, lookup accelerator, or other reconstructible representation.
It may improve proof generation or state access, but:
it is not an independent trust anchor;
it must be deterministically reconstructible from canonical state;
corruption of the structure must not change the accepted logical answer;
any proof produced through it must terminate at the canonical state commitment;
rebuilding it must produce the same externally observable result.
B. Consensus-bearing authenticated structure
This structure contributes information required to determine or verify canonical state.
In that case:
its root must be atomically bound to the block’s state commitment;
its update rules must be deterministic;
every validating implementation must derive the same root;
a block cannot commit the primary structure at state N and the auxiliary structure at state N-1 or N+1;
partial persistence cannot expose a mixed-version commitment.
There is no safe intermediate category.
If an auxiliary root can influence whether a proof is accepted, but is neither reconstructibly derived from the canonical root nor atomically included in the consensus commitment, the system creates a second, incompletely anchored state plane.
3. Replace the single root with an atomic commitment envelope
If multiple consensus-bearing structures are required, the block must still expose one atomic state commitment.
Conceptually:
StateCommitment_N = H(
domain_separator,
chain_id,
commitment_version,
logical_state_semantics_id,
primary_structure_type,
primary_root_N,
ordered_auxiliary_descriptors_and_roots_N,
hash_suite_id,
encoding_version
)
The exact encoding can differ, but the properties cannot:
the structure list must be ordered and unambiguous;
every component type must be domain-separated;
every root must be bound to its interpretation;
the hash suite must be explicit;
the commitment version must determine the verification rules;
omission, reordering, or substitution of an auxiliary component must change the final commitment;
all components must refer to the same block and state boundary.
If the existing 32-byte stateRoot field remains, it can commit to this envelope. What must not happen is allowing the field to authenticate only the primary structure while separately trusting auxiliary roots returned by an RPC node.
A cryptographically valid proof against an unauthenticated auxiliary root is still an unauthenticated claim.
4. Introduce a dual-representation epoch before activation
The migration should not move directly from:
MPT canonical
to:
new representation canonical
There should be a shadow epoch in which the current MPT remains canonical while the replacement representation is independently constructed for every block.
For each block:
The same canonical state transition is applied to both backends.
The old MPT root is produced.
The new primary root and all required auxiliary roots are produced.
The new atomic commitment envelope is produced.
Both representations export their logical state through independently implemented decoders.
Deterministic presence and absence proofs are generated through both proof paths.
Any mismatch identifies the first diverging block and prevents activation.
The shadow representation must not be permitted to “catch up” silently after skipping a failed update. A divergence is a protocol event, not a recoverable cache miss.
A crash between writing the primary structure and writing an auxiliary structure must also be explicitly tested. Atomicity cannot depend on the normal execution path completing successfully.
5. Use a representation-independent state digest during migration
Comparing a selected set of accounts and storage slots is useful for diagnostics, but it does not prove full-state equivalence.
A transition protocol should additionally define a canonical logical-state stream, independent of both physical structures.
For deterministic checkpoints:
LogicalDigest_N =
H_stream(CanonicalSerialize(LogicalState_N))
Both the MPT backend and the replacement backend must independently export the full canonical stream and derive the same LogicalDigest_N.
This digest is not a replacement for the runtime state commitment. It is a migration certificate proving that two different physical representations decode to the same complete logical state at a fixed block.
The procedure must define:
canonical account ordering;
canonical storage ordering;
domain separation between account and storage records;
inclusion of empty or absent values where semantically required;
completion markers preventing truncated streams from hashing as valid prefixes;
deterministic encoding of integers and byte strings;
independent implementations of the exporter and verifier.
Per-block write-set comparison can locate divergence quickly. Full-state checkpoint digests establish complete equivalence.
Both are needed.
6. Make proof versioning mandatory and fail-closed
The RFC states that the eth_getProof payload may be versioned.
It must be versioned.
Changing the proof structure or hash function while retaining the same method name is not semantic compatibility. A legacy verifier that assumes MPT, Keccak, and RLP must never be allowed to interpret a new proof as an old proof.
Every proof response should explicitly bind:
chain ID;
block hash;
state commitment;
commitment version;
proof type;
proof schema version;
hash suite;
node or element encoding;
primary structure type;
auxiliary structure types, when present;
activation epoch;
the exact account and storage keys being proven.
For example:
proofType
proofVersion
commitmentType
commitmentVersion
hashSuite
encoding
chainId
blockHash
stateCommitment
accountKey
storageKeys
primaryProof
auxiliaryProofs
A verifier must select its verification procedure from these authenticated identifiers and reject unknown combinations.
It must not infer the proof family from payload shape.
There should also be explicit downgrade protection. A consumer requesting the new proof family must not receive a legacy proof merely because a node, proxy, or provider does not support the new format.
A separate RPC method may be cleaner than silently redefining the response semantics of eth_getProof. If the existing method is retained, negotiation and rejection behavior must be exact.
7. Bind every proof to an exact block
latest is not an adequate verification boundary for a security-sensitive proof.
A proof must be bound to a specific block hash and the corresponding state commitment. Otherwise, the trusted header and the returned proof can refer to different moving states even when each request succeeds independently.
The verification path should be:
trusted chain context
-> exact block hash
-> authenticated block header
-> typed state commitment
-> typed account/storage proof
-> logical value or logical absence
Every step must bind the next one.
The proof response should not merely contain a block number. It should identify the exact block hash against which verification is expected, and canonical-chain requirements should be explicit where relevant.
8. Define historical-proof behavior before activation
The migration creates at least two historical proof families.
For blocks before activation, the block header commits to the MPT state root.
For blocks after activation, it may commit to the new state commitment.
That raises a non-optional question:
What proof does a node return when a caller requests state for a pre-activation block after the migration is complete?
There are only a few coherent options.
Preserve the original proof family
For a pre-activation block, return the original MPT proof against the state root committed in that block header.
This preserves the original trust path but requires archival availability of the old representation or deterministic reconstruction of it.
Introduce separately authenticated historical commitments
A new-format historical proof can be returned only if the corresponding new commitment for that historical state has been authenticated by a separate protocol commitment.
A node-generated conversion is not enough.
A new proof against a root that was never committed by the historical block is a derived statement from the node, not a proof against the original block header.
Return both with explicit status
The response may distinguish:
the original block-header-committed proof;
a derived replacement-format proof;
the authenticated mapping, if one exists, between the two commitments.
Those categories must never be presented as security-equivalent unless the linkage itself is authenticated.
Historical proof policy affects bridges, archival systems, on-chain verifiers, ZK circuits, monitoring systems, and any application that reconstructs past state. It cannot be deferred until after the structure is selected.
- Specify negative-proof equivalence separately
The most dangerous semantic divergence may not concern an existing value. It may concern absence.
The current proof model can establish that an account or storage path does not exist. A replacement structure may encode absence through a different mechanism:
an empty branch;
a default node;
an omitted leaf;
a zero value;
a tombstone;
a compressed path;
an auxiliary non-membership witness.
The logical specification must answer:
Is a missing storage slot distinguishable from an explicitly represented zero?
What proves that an account does not exist?
How is a deleted account represented?
What happens when an account or slot is created, cleared, and recreated?
Can the primary and auxiliary structures disagree on existence while agreeing on the returned EVM value?
Which differences are merely physical, and which are consensus-observable?
Both proof families must produce the same logical conclusion:
PRESENT(value)
or:
ABSENT
under the same normative rules.
A verifier accepting a zero value when it should require a non-membership proof is not equivalent to a verifier that proves absence, even if both display 0 to the application.
10. Preserve settlement and fraud-proof security by obligation, not assumption
The RFC states that the trust model, including settlement and fraud-proof security, will be preserved.
That property does not follow merely from the fact that the new structures are authenticated and their individual proofs are verifiable.
The required obligation is stronger:
For every valid state transition T:
all honest implementations derive the same StateCommitment_N+1.
And:
For every invalid transition or inconsistent component update:
the dispute and verification machinery can identify and reject it.
The state-transition system, validators, replay implementations, dispute machinery, block-header commitment path, snapshot logic, and recovery logic must all agree on the same commitment semantics.
Local verification of an eth_getProof response demonstrates membership or non-membership under a root. It does not, by itself, prove that the root represents the correct post-state, that all auxiliary roots refer to that same post-state, or that the transition into the root was valid.
Those are separate proof obligations.
11. Define an activation barrier and rollback anchor
Activation should require a deterministic certificate, not a calendar date alone.
The certificate should bind:
activation block;
final canonical MPT root;
first canonical new commitment;
logical-state digest at the transition boundary;
migration schema version;
hash-suite version;
client implementation versions;
test-corpus commitment;
replay range;
independent implementation results;
last divergence-free checkpoint.
The activation conditions should include:
a predefined divergence-free shadow period;
agreement among independent implementations;
complete reconstruction from an agreed checkpoint;
successful historical-proof verification;
successful non-membership testing;
crash and partial-write recovery;
snapshot export and import;
auxiliary-structure destruction and reconstruction;
rollback rehearsal.
After activation, the old representation should remain available for a defined rollback horizon.
The protocol must identify the last block at which both representations were proven equivalent and explain how the system returns to that point without combining state components from different versions.
12. The adversarial test matrix must target cross-representation failure
Ordinary performance benchmarks and valid-proof test vectors are not sufficient.
The transition should be tested against:
primary root at block N with auxiliary root at N-1;
partial database commit after a crash;
corrupted auxiliary structure rebuilt from canonical state;
different account iteration orders;
different serialization of zero and empty values;
non-existent account proofs;
zero-valued storage proofs;
deletion and recreation;
repeated writes to one slot within a block;
snapshot import at the activation boundary;
historical proof requests immediately before and after activation;
proof-version confusion;
unsupported-version downgrade;
wrong hash-suite identifier;
cross-chain proof replay;
proof for the correct state under the wrong block hash;
reorganization during proof retrieval;
archival pruning;
inconsistent recovery between primary and auxiliary stores;
independent full replay from the same inbox and chain history.
The acceptance condition is not merely that both systems return the same displayed value for ordinary reads.
It is that no adversarial state, interruption, version mismatch, or historical query can cause two conforming verifiers to accept different logical conclusions for the same authenticated block.
Recommended design sequence
The correct order is:
Define the representation-independent logical state.
Define presence, absence, deletion, and historical semantics.
Classify every auxiliary structure as derived or consensus-bearing.
Define the atomic state commitment envelope.
Define dual-representation construction and full-state equivalence certification.
Define typed proof families and fail-closed version negotiation.
Define historical-proof and archival behavior.
Define activation, rollback, and recovery invariants.
Validate the complete transition adversarially.
Only then select the physical structure and hash suite that satisfy those obligations with the required performance.
The tree, hash function, proof size, and migration cost are important engineering decisions.
But they are not the foundation.
The foundation is the invariant proving that every representation, every auxiliary structure, every verifier, and every historical proof refers to the same canonical logical state at the same authenticated block.
Without that invariant, the system can contain several individually valid proofs and still lack one coherent state.