1 of 83

The Merge

October 2021 | PEEPanEIP

Paul Hauner�Sigma Prime | Lighthouse�@paulhauner

2 of 83

Topic

Merging Ethereum

3 of 83

Introduction

Paul Hauner @paulhauner

Co-founder & director of Sigma Prime.
Lighthouse developer
Heavily involved in Beacon Chain engineering since its inception.

4 of 83

Introduction

Sigma Prime @sigp_io

Established in 2016
Team of ~20 people
Lighthouse maintainer
Works closely with Eth. Foundation
Information-security (“auditing”) firm

5 of 83

The Merge: An Overview

6 of 83

The Merge: An Overview

Replace Proof-of-Work

7 of 83

The Merge: An Overview

With Proof-of-Stake

8 of 83

The Specification

EIP-3675: Upgrade consensus to Proof-of-Stake

Staking Stuff

+ �Transaction Stuff

Staking Stuff

Transaction Stuff

Staking Stuff

+ �Transaction Stuff

PoW Ethereum

PoS Ethereum�(Beacon Chain)

9 of 83

Chain Structure

One PoS chain to rule them all?

10 of 83

Chain Structure

Ehh... kinda...

11 of 83

Chain Structure

Staking Stuff

+ �Transaction Stuff

Staking Stuff

+ �Transaction Stuff

PoS Ethereum�(Beacon Chain)

One chain

Staking Stuff

+ �Transaction Stuff

12 of 83

Chain Structure

Staking Stuff��

PoS Ethereum�(Beacon Chain)

...with a sneaky inside chain

^{Transaction Stuff}

Staking Stuff��

^{Transaction Stuff}

13 of 83

Chain Structure

Why sneaky inside chain?

14 of 83

Chain Structure

Ethereum Chain

^{Transaction Stuff}

Reason 1: existing tooling and dependencies

Parent�Hash

State Trie

EVM

Dapps + Infra

15 of 83

Chain Structure

Implementing the EVM is hard
Storing the state trie is hard
Processing transaction is hard
Placing txs in blocks is hard
Being secure is hard

All these hard things are already done very well by existing Ethereum PoW clients.

Reason 2: no need to implement the wheel

16 of 83

Chain Structure

Managing validators is hard
Multi-client PoS is hard
Performant PoS is hard
Secure PoS is hard

All these hard things are already done very well by existing Ethereum PoS clients.

Reason 2: no need to implement the wheel

17 of 83

Chain Structure

Staking Stuff��

^{Transaction Stuff}

Staking Stuff��

^{Transaction Stuff}

18 of 83

Terminology

Time for some terminology

19 of 83

Terminology

Staking Stuff

^{Transaction Stuff}

Staking Stuff

^{Transaction Stuff}

Consensus Layer

Execution Layer

20 of 83

Terminology

Consensus Clients

Execution Clients

21 of 83

Terminology

Competing Terminology

Existing�Eth2�Eth1

New�Consensus�Execution

Equivalent

22 of 83

Terminology

I use the “new” terminology.

You do you.

23 of 83

Terminology

Moar terminology

24 of 83

Terminology

Staking Stuff��

^{Transaction Stuff}

^Transaction^Stuff

Staking Stuff��

^Transaction^Stuff

Beacon Blocks

Execution Payloads

25 of 83

Terminology

Beacon Block��

^Execution

^Payload

^Execution

^Payload

Beacon Block��

^Execution

^Payload

26 of 83

Data Structures

27 of 83

Data Structures

28 of 83

Intermission 1/3

29 of 83

Block Production

Producing a Beacon Block

30 of 83

Block Production

consenus_client.exe

execution_client.exe

Validator #42

31 of 83

Block Production

consenus_client.exe

execution_client.exe

Validator #42

My validator has been elected to produce the next block!

32 of 83

Block Production

consenus_client.exe

execution_client.exe

Validator #42

To: execution_client.exe��Please prepare to produce a block!

engine_forkchoiceUpdated

33 of 83

Block Production

consenus_client.exe

execution_client.exe

Validator #42

Waiting until it’s time to produce a block.

Working to find best set of transactions...

34 of 83

Block Production

consenus_client.exe

execution_client.exe

Validator #42

It’s time to produce a block!

Working to find best set of transactions...

35 of 83

Block Production

consenus_client.exe

execution_client.exe

Validator #42

To: execution_client.exe��Please send me an execution payload!

Working to find best set of transactions...

engine_getPayload

36 of 83

Block Production

consenus_client.exe

execution_client.exe

Validator #42

Beacon Block��

^???

^{Execution Payload}

37 of 83

Block Production

consenus_client.exe

execution_client.exe

Validator #42

Beacon Block��

^{Execution Payload}

38 of 83

Block Production

consenus_client.exe

execution_client.exe

Validator #42

Beacon Block��

^{Execution Payload}

39 of 83

Block Production

consenus_client.exe

execution_client.exe

Validator #42

To: execution_client.exe��That payload is at the head of the chain!

engine_forkchoiceUpdated

40 of 83

Block Production

Validators must run an EL client and a CL client to produce blocks.
They must be connected via some RPC (e.g., HTTP JSON-RPC)
A CL client is unable to produce an Execution Payload.
The EL client relies upon the CL client to know which chain is canonical.

Producing a block: what have we learned?

41 of 83

Block Processing

Processing a Beacon Block

42 of 83

Block Processing

consenus_client.exe

execution_client.exe

Generic User

43 of 83

Block Processing

consenus_client.exe

execution_client.exe

Generic User

Beacon Block��

^{Execution Payload}

44 of 83

Block Processing

consenus_client.exe

execution_client.exe

Generic User

Beacon Block��

^{Execution Payload}

45 of 83

Block Processing

consenus_client.exe

execution_client.exe

Validator #42

To: execution_client.exe��Please verify this execution payload

engine_executePayload

^{Execution Payload}

46 of 83

Block Processing

consenus_client.exe

execution_client.exe

Generic User

Beacon Block��

^{Execution Payload}

47 of 83

Block Processing

consenus_client.exe

execution_client.exe

Generic User

Beacon Block��

^{Execution Payload}

48 of 83

Block Processing

consenus_client.exe

execution_client.exe

Generic User

Beacon Block��

^{Execution Payload}

49 of 83

Block Processing

consenus_client.exe

execution_client.exe

Validator #42

To: execution_client.exe��That payload is at the head of the chain!

engine_forkchoiceUpdated

50 of 83

Block Processing

All users must run an EL client and a CL client to verify blocks.
The EL client needs a second message to confirm that an Execution Payload was accepted by the CL client. Verifying the payload itself is not enough!

Processing a block: what have we learned?

51 of 83

Intermission 2/3

52 of 83

Infrastructure

The Merge: Infrastructure

53 of 83

Infrastructure

consenus_client.exe

execution_client.exe

JSON RPC

54 of 83

Infrastructure

consenus_client.exe

execution_client.exe

JSON RPC

55 of 83

Infrastructure

consenus_client.exe

56 of 83

Infrastructure

execution_client.exe

57 of 83

Infrastructure

A malicious EL client can cause double-spends!

A malicious CL can censor transactions!

Trust

58 of 83

Infrastructure

consenus_client.exe

execution_client.exe

The Internet

The User

discv5 (udp)

libp2p (tcp)

devp2p (udp)

devp2p (tcp)

JSON-RPC (http,ws,etc)

REST API (tcp)

59 of 83

Infrastructure

execution_client

chain_db

accounts

consensus_client

beacon_chain_db

validator_keys

60 of 83

Syncing

The Merge: Syncing

61 of 83

Syncing

Naive “lockstep” sync

Block

62 of 83

Syncing

Lockstep sync after a partition

Block

63 of 83

Syncing

✅ Simple
✅ Safe
❓ Recovers from partition between EL/CL
❌ Compatible with sophisticated sync algorithms

In lockstep sync, the CL “spoon-feeds” blocks to the EL.

64 of 83

Syncing

“Optimistic” sync

Block

65 of 83

Syncing

❌ Simple
✅ Safe
✅ Recovers from partition between EL/CL
✅ Compatible with sophisticated sync algorithms

In optimistic sync, it is assumed the EL can get blocks from its own P2P network.

66 of 83

Syncing

Only build blocks on fully verified blocks.
Only attest to fully verified blocks.

Consensus safety in optimistic sync

67 of 83

Syncing

Do not build blocks here

Build blocks here

...or attest here

Attest here

68 of 83

Syncing

Allow attesting/block-production if there are any optimistically-verified blocks?
Serve optimistically-verified blocks via the API?

Optimistic sync open questions

69 of 83

Syncing

https://github.com/sigp/lighthouse/issues/2691

Optimistic sync discussion

70 of 83

Intermission 3/3

71 of 83

Progress

The Merge: Progress so Far

72 of 83

Greece Workshop

Amphora Workshop

73 of 83

Greece Workshop

Disclaimer: I participated remotely

74 of 83

Greece Workshop

Get everyone together in the same physical space.
Hack together on merge testnets.
Get to know each other.
Form relationships important relationships for a post-merge Ethereum.
Go swimming, look at ancient artifacts, eat, drink...

Face-to-Face (F2F) in Greece 🇬🇷

75 of 83

Greece Workshop

The ultimate goal:

multi-client merge devnet

76 of 83

Greece Workshop

🙀 n²

77 of 83

Greece Workshop

M0: Start implementation
M1: Specification implemented, test vectors passing
M2: 1-to-1 interop between EL/CL (without merge transition)
M3: 1-to-1 interop between EL/CL (with merge transition)
M4: Many-to-many interop
M5: All-to-all persistent devnet

Milestones

78 of 83

Greece Workshop

79 of 83

Greece Workshop

80 of 83

Greece Workshop

Instructions to join (for humans): https://bit.ly/2Zgr0no

81 of 83

Greece Workshop

82 of 83

Greece Workshop

Public, multi-client testnet is running (Pithos)
Only major client not yet on Pithos
Downstream tooling is still immature
Specification requires another round of iteration
New devnets late-October or early-November

Merge Engineering Standing

83 of 83

Thank You

Get in touch...

Paul Hauner�Sigma Prime | Lighthouse�@paulhauner

Lighthouse

github.com/sigp/lighthouse