Rapidblocks with split proofs: execution proofs that outlive their state

Rapidblocks with Split Proofs: Execution Proofs That Outlive Their State

TL;DR – Split proofs divide a block’s execution proof into three parts, allowing a block to stay valid even as the underlying state evolves, and separating agreement on blocks from agreement on state roots.

---

1. Why a Monolithic Proof Falls Short

In the rapidblocks model, a block may be built on a virtual state that never appears on the canonical chain. A traditional proof that says “block b transforms state root r into r′” is tied to a specific root that the chain might never actually adopt. Validators would have to re‑execute the block on the real chain state, defeating the goal of stateless verification.

2. The Three‑Part Split Proof

For each block b we define:

• \(\Pi_T\) – The heavyweight EVM execution proof. It takes the block’s transactions, the inputs \(I(b)\) (the exact key‑value pairs read), and the execution context \(X(b)\), and produces the outputs \(O(b)\).
• \(\Pi_{in}\) – A Merkle‑style proof that the declared inputs match the state at the moment the block’s slot begins. This is essentially a multi‑proof that the values in \(I(b)\) are present in the current state root.
• \(\Pi_{out}\) – A Merkle or SNARK proof that applying the outputs \(O(b)\) to the input state yields a new state root \(\sigma'\).

The monolithic proof is simply the composition \(\Pi{out}\circ\PiT\circ\Pi{in}\). By keeping the parts separate, we can verify \(\PiT\) without needing the exact state root, as long as the inputs are correct.

3. The Input Rule – Validity Beyond a Single State

A block is considered in if:

1. Its slot’s value points to the block.
2. \(\Pi_T\) is valid.
3. The inputs \(I(b)\) are current – i.e., they match the values produced by the most recent blocks that wrote those keys.
4. The execution context matches the agreed‑upon horizon.

Because \(\Pi_T\) only depends on the values it reads, any later state change that does not modify those keys leaves the proof valid. This optimistic concurrency control replaces the older Hist rule, which required a block’s entire history to be present. Under the input rule, only blocks that actually read a changed key are invalidated; others survive unchanged.

4. Two Parallel Tracks: Blocks vs. State Roots

The split proof design naturally separates consensus into two loosely coupled tracks:

1. Block Track (every slot) – Voters run a window vote that checks the header, the availability of the body, \(\PiT\), and the freshness of inputs via \(\Pi{in}\). No full state is needed; voters fetch the latest values for each read key from the most recent block in the window or from the horizon root.
2. State‑Root Track (per horizon slot) – Once a prefix up to the horizon is decided, validators produce \(\Pi{out}\) recursively, proving that the canonical outputs of all in‑blocks lead to a new state root. This root is then checkpointed and can be used as the reference for future \(\Pi{in}\) proofs.

The block track can progress ahead of the state‑root track, enabling faster finality for block availability while still guaranteeing eventual consistency of the state.

5. Practical Implications

• Stateless Verification – Anyone can verify a block’s execution proof without holding the full state, simply by checking the three proofs against the header commitments.
• Robustness to Reorgs – Since validity hinges on input values rather than a specific root, a block remains valid across many slots unless a concurrent block overwrites one of its read keys.
• Simplified Validator Logic – Validators no longer need to re‑execute every block; they only need to verify \(\Pi_T\) and the Merkle proofs for inputs and outputs.
• MEV Neutrality – State‑root proofs are generated after block availability is decided, removing incentives to manipulate roots for profit.

6. Open Questions & Next Steps

The split‑proof concept is still at the idea stage. Key areas for further work include:

• Formal security proofs for the input rule under adversarial concurrency.
• Efficient SNARK constructions for \(\PiT\) and \(\Pi{out}\) that keep witness sizes practical.
• Integration with existing access‑list mechanisms (e.g., EIP‑7928) to capture read keys and values.
• Simulation of network performance with realistic latency and validator participation models.

---

Conclusion Split proofs reshape rapidblocks by decoupling execution verification from state commitment. By committing to the exact inputs a block reads, a proof stays valid across many slots, and consensus can advance block availability independently of state‑root finality. This opens a path toward truly stateless, high‑throughput Ethereum consensus while preserving security guarantees.