Execution layer cross validation

Recovering from faults (i.e. fix it or lose it)

Ethereum must stay alive ⇒ network needs self-heal

• Single or small (1/3-) partition ⇒ network stays healthy
• Large (1/3+) temporary partition ⇒ network stops finalizing
• Large (1/3+) permanent partition ⇒ network starts inactivity leak

Consensus faults can be much more interesting:

• Non-super-majority fault (2/3-) ⇒ same as network split
• Super-majority fault (2/3+) ⇒ auto self-healing becomes impossible

Client diversity for the win (i.e. avoiding nasty faults)

Famous chart I grew to hate... 🫠

• Effort is rewarded by social slashing
• Nice theory, but switch- /integration costs?

Detecting consensus faults... in advance

Rethinking the problem

Run multiple clients vs. verify with multiple clients?

• CPU: EVM execution is ~100ms single threaded ⇒ ok
• RAM: Max memory expansion is ~4MB at 30M gas ⇒ ok
• Net: EL traffic is tx propagation at ~69/79KB/s in/egress ⇒ ok...
• Disk: Mainnet is ~275GB state data + ~850GB chain history ⇒ ugh...
• Infra: CLs and ELs match up 1-to-1, no support for N-of-M links ⇒ ugh...
• Time: Maintenance effort of running many clients scales non-linearly ⇒ ugh...

Observation: a block only touches ~4.5MB worth of state. What if we gut out clients? 🤔

Minimal data for trustless block execution

EVM execution need a variety of data... we need verifiability:

• State: account infos, contract storage, code hashes, etc. ⇒ ok
• Bytecode: when calling contracts, is outside the state trie ⇒ hmm
• Block-hash: when accessing past hashes, outside the state ⇒ hmm
• MPT siblings: when verifying the post-state-root, passive state ⇒ ok-ish

witness = [headers, codes, state]    
    
headers = [header₁, header₂, ...] // Descending list of headers  - Enforces parent linking
codes   = [binary₁, binary₂, ...] // Unordered soup of bytecodes - Enforces by-hash access
state   = [binary₁, binary₂, ...] // Unordered soup if trienodes - Enforces MPT structure

Witness creation

Relatively straightforward with a few gotchas:

• Bytecodes are accessed by the transaction, CALL* and EXTCODE* opcodes
• The BLOCKHASH opcode needs all headers from current to the refed one
• Clients have flat states, SLOAD needs prefetching, siblings postfetching

Witness execution

Verify an EVM execution via another implementation

• Hide post root and receipt root ⇒ no cheating

Must run production EVM

• Witness is hash dataset
• Flat/path need transform
• Use a RAM db vs. disk one

Witness integration (apologies for the wonky abbreviations)

Engine API seems the tightest

• fcUpdated ⇒ forkchoiceUpdatedWithWitness
• getPayload ⇒ returns witness on fcUpdatedWithWitness
• newPayload ⇒ newPayloadWithWitness + executeStatelessPayload

Proposed API usage:

• Local block production ⇒ fcuWithWitness + getPayload + executeStatelessPayload
• Remote block validation ⇒ newPayloadWithWitness + executeStatelessPayload
• MEV/Verkle block creation ⇒ fcuWithWitness + getPayload, network witness

Witness integration feasibility (pre-Verkle)

Thank you