Abstract
This proposal defines an optional execution model in which blocks may include state witnesses sufficient to independently verify and execute all transactions they contain. A state witness consists of the minimal subset of Ethereum state accessed during execution together with cryptographic proofs derived from a Verkle commitment to the canonical state root. By embedding these witnesses directly in blocks, validators and other clients can verify block correctness without maintaining the full global state locally. This approach preserves existing transaction semantics and execution outcomes while enabling stateless block verification and significantly reducing long term state storage requirements for participating nodes.
Motivation
Ethereum execution clients are required to maintain and continuously synchronize an ever growing global state in order to validate blocks. As the state expands, this requirement increases storage costs, synchronization time, and operational complexity for validators and other verifiers. These pressures create practical barriers to participation and increase reliance on specialized infrastructure, which can negatively affect decentralization over time.
While protocol level improvements aim to reduce long term state growth, they do not eliminate the requirement that every fully verifying node locally possess the complete execution state at the time of block processing. This tightly couples block verification with persistent state storage, even though the information required to verify a specific block is limited to a relatively small subset of the total state.
The absence of a standardized mechanism for block scoped state verification prevents clients from validating execution using only the state actually accessed by a block. As a result, stateless or near stateless verification models remain impractical despite ongoing progress toward Verkle based state commitments. A protocol defined approach is required to decouple block verification from full state possession while preserving deterministic execution and consensus safety.
Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Overview
This specification defines an optional block level mechanism by which an execution block may include a state witness sufficient to execute and verify all transactions in the block without requiring access to the full global execution state. The witness is cryptographically bound to the block via a commitment derived from the canonical execution state root using Verkle proofs.
Blocks that do not include a witness are processed according to existing execution rules and are unaffected by this specification.
Definitions
State Witness
A data structure containing the minimal subset of execution state required to execute all transactions in a block together with cryptographic proofs linking that state to the canonical state commitment.
Witness Commitment
A cryptographic commitment derived from the block execution state root that binds the witness contents to the canonical state.
Witness Payload
The serialized representation of the state witness included with the block.
Stateless Verification
Execution and validation of a block using only the witness payload and the block contents without accessing locally stored global state.
Witness Inclusion
An execution block MAY include a witness payload. If present, the witness payload MUST be treated as an auxiliary execution input and MUST NOT alter block structure transaction encoding or consensus critical fields other than those explicitly defined in this specification.
The presence of a witness payload MUST be explicitly signaled in the execution block metadata.
Witness Scope Requirements
If a witness payload is included it MUST contain all state elements required to execute the block deterministically including:
- All account data accessed during execution
- All contract code accessed during execution
- All storage slots read or written during execution
The witness MUST NOT include state elements that are not accessed by the block execution.
Cryptographic Binding
The witness payload MUST be cryptographically bound to the block execution state root via a Verkle proof.
The witness commitment MUST verify against the execution state root of the block.
Proof verification MUST succeed for the block to be considered valid under stateless verification.
Proof verification MUST be deterministic and independent of client specific state layout.
Blocks containing a witness with an invalid or unverifiable commitment MUST be rejected by clients performing stateless verification.
Execution Semantics
For blocks containing a valid witness payload:
- Clients MAY execute the block using only the witness payload and the block contents
- Execution MUST produce identical results to execution against the full global state
- Transaction ordering gas accounting and execution outcomes MUST NOT differ from existing semantics
For blocks without a witness payload execution MUST proceed exactly as defined by existing protocol rules.
Validation Rules
A client performing stateless verification MUST enforce the following:
- The witness payload is complete with respect to all state accesses
- All Verkle proofs contained in the witness verify correctly
- The witness commitment matches the block execution state root
- Execution using the witness produces the declared post state root
Failure of any condition MUST cause the block to be considered invalid under stateless verification.
Clients that do not support stateless verification MAY ignore the witness payload entirely.
Optionality and Compatibility
This specification introduces no mandatory requirements for block producers or validators.
Block producers MAY include witnesses.
Validators and clients MAY choose whether to support stateless verification.
No new consensus rules are introduced for blocks without witnesses.
This ensures full backward compatibility with existing clients and networks.
Networking and Propagation
The witness payload MAY be propagated alongside the execution block using existing or extended block propagation mechanisms.
This specification does not mandate a specific transport or gossip mechanism for witness data.
Failure Modes
If a witness payload is present but incomplete malformed or unverifiable:
- Stateless verification MUST fail
- Full state clients MAY still execute the block using local state
This specification does not require all clients to reject such blocks at the consensus layer.
Chain Specifics
This specification applies uniformly across mainnet, testnets, devnets, and private networks.
Genesis Block Behavior
This specification introduces no special requirements for the genesis block. Witness payloads are not applicable at genesis, and execution proceeds according to existing protocol rules.
Testnets and Devnets
On testnets and devnets, block producers MAY include witness payloads in order to exercise stateless verification paths, test witness completeness assumptions, and evaluate implementation behavior under varied execution patterns.
Clients MAY enable additional logging, diagnostics, or validation checks related to witness handling on non-mainnet networks. Such behavior MUST NOT alter execution outcomes or consensus semantics.
Network Upgrades and Activation
This specification does not define a mandatory network upgrade or activation fork. Witness inclusion is optional and does not affect block validity for clients that do not perform stateless verification.
Networks MAY choose to gate witness inclusion behind a network specific configuration flag or activation mechanism for testing purposes. Such mechanisms are outside the scope of this specification.
Client Configuration
Execution clients MAY expose configuration options to enable or disable stateless verification, witness validation, or witness propagation behavior on a per-network basis.
Differences in default configuration between mainnet and non-mainnet environments MUST NOT result in divergent execution results for the same block when stateless verification is enabled.
Private and Permissioned Networks
Private or permissioned networks MAY adopt this specification independently of public networks. Such networks MAY require witness inclusion as a local policy requirement; however, this specification does not mandate such behavior.
Rationale
The primary design goal of this specification is to decouple block verification from persistent global state storage while preserving deterministic execution and existing consensus guarantees. The chosen approach introduces state witnesses as an optional execution input, allowing clients to verify blocks using only the state actually accessed during execution.
Witness inclusion is defined at the block level rather than the transaction level to minimize redundancy and reduce complexity. Since multiple transactions within a block often access overlapping state, a block scoped witness allows shared state elements to be included once while remaining sufficient for full execution. This design also aligns naturally with block based execution and validation pipelines in existing clients.
The specification deliberately treats witness inclusion as optional to ensure backward compatibility and allow gradual adoption. Clients that do not implement stateless verification can continue to operate unchanged, while clients that do can selectively use witnesses when available. This avoids introducing mandatory consensus changes or requiring coordinated upgrades across the network.
Verkle proofs are used as the cryptographic binding mechanism because they provide efficient proof sizes and support succinct inclusion proofs over large key spaces. This choice aligns with the direction of existing protocol work toward Verkle based state commitments and enables stateless verification without relying on full Merkle Patricia Trie witnesses.
Alternative approaches were considered, including transaction level witnesses and mandatory stateless execution. Transaction scoped witnesses were rejected due to increased duplication and overhead when state is accessed across multiple transactions. Mandatory stateless execution was rejected due to deployment risk and the need to preserve flexibility for clients and networks with different operational constraints.
Related work exists in other systems that support stateless or near stateless validation through explicit state proofs or execution witnesses. This specification differs by integrating witness handling directly into the block execution model while preserving Ethereum’s existing execution semantics and client architecture.
Backwards Compatibility
This specification introduces no backwards incompatible changes.
Witness inclusion is optional and does not modify transaction formats, execution semantics, block validity rules, or consensus critical behavior for blocks that do not include a witness payload. Blocks without witnesses are processed exactly as defined by existing protocol rules.
Clients that do not implement stateless verification or witness handling remain fully compatible with networks adopting this specification. Such clients may ignore witness payloads entirely and continue to execute blocks using locally stored state without divergence.
Because witness payloads are treated as auxiliary execution inputs and do not alter canonical block fields or execution outcomes, this specification does not require a network wide coordinated upgrade or hard fork. As a result, no backwards compatibility mitigation measures are required.
Test Cases
The following test cases describe expected behavior for clients implementing this specification. No additional requirements beyond those defined in the Specification section are introduced.
Valid Witness Block
Input:
- An execution block containing a witness payload
- The witness payload includes all state elements accessed during execution
- All Verkle proofs verify correctly against the block execution state root
Expected Result:
- Stateless verification succeeds
- Block execution using the witness produces the same post state root as execution against the full global state
- The block is considered valid by clients performing stateless verification
Missing State Element
Input:
- An execution block containing a witness payload
- The witness payload omits a state element accessed during execution
Expected Result:
- Stateless verification fails due to incomplete witness data
- Clients performing stateless verification reject the block
- Clients using full state MAY still execute the block successfully
Invalid Verkle Proof
Input:
- An execution block containing a witness payload
- One or more Verkle proofs in the witness fail verification against the execution state root
Expected Result:
- Stateless verification fails
- The block is rejected by stateless verification clients
- Full state clients MAY execute the block using local state
No Witness Payload
Input:
- An execution block without a witness payload
Expected Result:
- Execution proceeds according to existing protocol rules
- Stateless verification is not attempted
- Block validity and execution results are unchanged from current behavior
Witness Commitment Mismatch
Input:
- An execution block containing a witness payload
- The witness commitment does not match the execution state root
Expected Result:
- Stateless verification fails
- The block is considered invalid under stateless verification
Reference Implementation
The following pseudocode illustrates stateless block verification using a witness payload. It is intended for explanatory purposes only and is not normative.
def verify_block_with_witness(block, witness):
# Verify witness commitment against the block execution state root
if not verify_verkle_commitment(
witness.commitment,
block.execution_state_root
):
return False
# Verify all Verkle proofs contained in the witness
for proof in witness.proofs:
if not verify_verkle_proof(proof):
return False
# Execute transactions using witness-provided state
execution_result = execute_block(
block.transactions,
witness.state_subset
)
# Verify post-state root matches block declaration
if execution_result.post_state_root != block.execution_state_root:
return False
return True This reference implementation demonstrates the logical steps required to perform stateless verification. Production implementations are expected to integrate witness handling into existing execution pipelines and optimize proof verification, caching, and execution strategies as appropriate for each client architecture.
Security Considerations
This specification introduces a new optional execution input in the form of block level state witnesses. While witness inclusion does not alter consensus rules or execution semantics, it introduces additional security considerations for clients performing stateless verification.
Witness Completeness and Correctness
A primary security concern is witness completeness. If a witness omits any state element accessed during execution, stateless verification must fail. Clients performing stateless verification MUST treat incomplete witnesses as invalid and MUST NOT attempt to infer or substitute missing state. Failure to enforce strict completeness checks could result in incorrect execution outcomes or acceptance of invalid blocks.
Cryptographic Proof Verification
Stateless verification relies on the correctness of Verkle proof verification. Clients MUST verify all proofs deterministically and independently against the block execution state root. Any deviation in proof verification logic across clients could lead to inconsistent validation results. Implementations should reuse well reviewed cryptographic libraries and avoid custom or ad hoc proof handling logic.
Execution Equivalence
Execution using witness provided state MUST be equivalent to execution against the full global state. Clients must ensure that witness based execution does not introduce differences in gas accounting, ordering, or execution side effects. Any divergence would represent a critical security failure. Implementations should include extensive cross testing between stateless and full state execution paths.
Denial of Service Risks
Witness payloads increase the amount of data processed during block validation. Malicious block producers could attempt to exploit this by including oversized or computationally expensive witnesses. Clients should enforce size limits, validation timeouts, and proof verification cost controls consistent with existing block processing safeguards.
Optionality and Client Diversity
Because witness handling is optional, networks may contain a mix of clients that do and do not perform stateless verification. This diversity mitigates systemic risk but also requires careful implementation to ensure that witness handling does not affect block validity for clients that ignore witnesses. Clients that do not implement stateless verification MUST safely ignore witness payloads without altering execution behavior.
Implementation Guidance
Clients should treat witness processing as an isolated verification path and avoid intertwining it with consensus critical logic unless explicitly required. Debugging and diagnostic features related to witness handling should be disabled or restricted in production environments to avoid information leakage or performance degradation.
This section will be expanded as implementation experience and security analysis mature during the review process.
Copyright
Copyright and related rights waived via CC0.
