Execution layer cross validation

Resilience without swapping clients


24 August 2024

ETHTokyo



Péter Szilágyi

Go Ethereum Lead

Faults, penalties and diversity

Safety vs. liveness (i.e. what could go wrong)

Consensus mechanisms aim for two properties:

Reality has another annoying property... partitioning

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

Ethereum must stay alive ⇒ network needs self-heal

Consensus faults can be much more interesting:

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

Famous chart I grew to hate... 🫠

Detecting consensus faults... in advance

Rethinking the problem

Run multiple clients vs. verify with multiple clients?

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:

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:

Witness execution

Verify an EVM execution via another implementation

Must run production EVM

Witness integration (apologies for the wonky abbreviations)

Engine API seems the tightest

Proposed API usage:

Witness integration feasibility (pre-Verkle)

Thank you

Go Ethereum Lead