1 of 39

以太坊 Proof-of-Stake 之路

Hsiao-Wei Wang

2022-05-09

The Merge & Weeth

2 of 39

Hello 👋

@hwwhww @hsaio-wei#0696 @icebearhww

GitHub

Discord

Twitter

I’m Hsiao-Wei

​

Ethereum Foundation Researcher

​

hsiaowei.eth

2

3 of 39

  • 以太坊 Proof-of-Stake 權益證明
  • 什麼是合併（The Merge）
  • 技術面上如何實現
  • 對以太坊使用者的影響

3

4 of 39

以太坊 Proof-of-Stake �權益證明

4

5 of 39

Casper Proof-of-Stake

Properties

  • Deposit
  • Economic slashing
  • Settlement finality
  • Accountable safety
  • Plausible liveness

5

Illustration credits: Buterin, V and Griffith, V. Casper the Friendly Finality Gadget.

6 of 39

以信標鏈（Beacon chain）實現權益證明

6

PoW Main Chain

economic seed

Beacon Chain

(PoS Chain)�finality, randomness, orchestration

7 of 39

The Merge

7

8 of 39

什麼是 The Merge （合併）

共識機制

將共識演算法（Consensus algorithm）從工作量證明（Proof-of-Work, PoW）�切換到 權益證明（Proof-of-Stake, PoS）

客戶端系統模組化

將客戶端分成 共識層（Consensus Layer） 以及 執行層（Execution Layer）

主鏈合併

將以太坊 EVM 主鏈 與 �信標鏈（Beacon Chain）合併

9 of 39

PoW Main Chain

economic seed

Beacon Chain

(PoS Chain)�finality, randomness, orchestration

10 of 39

Beacon Chain

(PoS Chain)�finality, randomness, orchestration

PoW Main Chain

economic seed

+ Execution payload in beacon block

11 of 39

Merged!

Executable

Beacon chain

+ Execution payload in beacon block

PoW chain history and applications on EVM will be unchanged

Beacon Chain

(PoS Chain)�finality, randomness, orchestration

12 of 39

Execution Layer (EL) 執行層

12

Image: When Merge by Danny Ryan

13 of 39

Execution Layer (EL) 執行層

13

Image: When Merge by Danny Ryan

14 of 39

Consensus Layer (CL) 共識層

14

Image: When Merge by Danny Ryan

15 of 39

客戶端系統模組化

15

Image: When Merge by Danny Ryan

16 of 39

客戶端系統模組化

devp2p

libp2p

16

Image: When Merge by Danny Ryan

17 of 39

客戶端系統模組化

17

Image: When Merge by Danny Ryan

18 of 39

客戶端系統模組化

18

Image: When Merge by Danny Ryan

19 of 39

客戶端系統模組化

19

​

EL

CL

主要功能

執行 EVM

Proof-of-Stake 共識

Fork choice rule

由 CL 告知 head block

LMD-Ghost

EVM transaction pool

不變

N/A

20 of 39

客戶端系統模組化

20

​

EL

CL

Networking

以 devp2p 和其他 EL 節點連線

以 libp2p 和其他 CL 節點連線

Network serialization

RLP

SSZ

Endianness

Big-endian

Little-endian

Identity of “block”

Execution block header keccak256 hash

Beacon block SSZ root

21 of 39

Wen Merge?

21

22 of 39

SOON.

22

23 of 39

Checklist

  • CL & EL 客戶端的各種測試
    • 單元測試、模糊測試 (Fuzzing)、測試鏈、shadow forks 等
  • 公有測試鏈（Ropsten, Goerli, Sepolia）硬分岔
  • 決定 Terminal Total Difficulty (TTD) 參數值
  • 發布 Mainnet 版本客戶端

23

24 of 39

24

客戶端已實作 TheMerge 核心協議規格，並正以洪荒之力在密集測試中 🔥

25 of 39

協議如何決定何時觸發合併？(1/6)

Step 1: CL 硬分岔

  • CL 端會先進行 Bellatrix Upgrade 硬分岔，轉為和 The Merge 相容的 區塊內容欄位與 state transition 邏輯
    • BeaconBlock 新增 execution_payload: ExecutionPayload 欄位
    • BeaconState 新增 latest_execution_payload_header: ExecutionPayloadHeader 欄位
  • 在 EL 端硬分岔之前，CL 的新增欄位內容為空值

25

26 of 39

協議如何決定何時觸發合併？(2/6)

觸發合併的參數值

  • TERMINAL_TOTAL_DIFFICULTY (TTD): 觸發合併的 total difficulty 值
  • Terminal PoW block: 同時符合以下兩個條件的 PoW block:
    • pow_block.total_difficulty >= TERMINAL_TOTAL_DIFFICULTY
    • pow_block.parent_block.total_difficulty < TERMINAL_TOTAL_DIFFICULTY
  • Transition block: 第一個 execution_payload 不為空值的 PoS block

26

27 of 39

協議如何決定何時觸發合併？(3/6)

為什麼用 Terminal Total Difficulty (TTD)？

  • 若用區塊編號（block number）決定合併的區塊，礦工可能在接近硬分岔時就停止挖礦，造成以太坊的安全性下降
  • 知道區塊編號的攻擊者能夠在已知時間時發動硬分叉攻擊
  • 若被攻擊（極端狀況下），客戶端可設定強制的 TERMINAL_BLOCK_HASH 觸發 The Merge transition

​

27

28 of 39

協議如何決定何時觸發合併？(4/6)

28

Image: When Merge by Danny Ryan

29 of 39

協議如何決定何時觸發合併？(5/6)

[Step 2]

  • 信標鏈 block proposer 檢查收到的 EL 區塊
    • 若新區塊的 parent block hash 指向 terminal PoW block 且尚未合併，則此新區塊為 transition block！
  • 信標鏈 block proposer 透過 Engine API 取得 payload 並填入至信標鏈區塊中

29

30 of 39

協議如何決定何時觸發合併？(6/6)

30

Image: When Merge by Danny Ryan

31 of 39

對以太坊應用層的影響: EVM opcodes

  • DIFFICULTY (0x44) opcode:
    • 因為已無 mining，PoS 鏈上不再有挖礦 difficulty
    • EIP-4399: 為了向下相容，改名為 PREVRANDAO 並使用 beacon chain 上產生的亂數作為 PREVRANDAO 的值
  • BLOCKHASH (0x40) opcode: 由於 ExecutionPayload 中 mining 相關欄位被棄用了，所以此值更容易被操縱！不建議使用 BLOCKHASH 產生亂數值

31

32 of 39

對以太坊應用層的影響: 出塊時間

  • 信標鏈的邏輯中，區塊是以 “time slot” 來編號。
  • 正常狀況下固定為 12 秒/區塊
  • 少數狀況（<1%）會有被 “跳過” 的區塊，此時區塊時間會拉長
    • 注：特定 slot 的區塊必須由特定的驗證者負責產生並簽名，若驗證者未在一定時間內廣播出區塊，則這個 slot 會被跳過。

32

33 of 39

對以太坊應用層的影響: Finality

  • 工作量證明: 只有機率上的最終確定性，服務提供者自行選擇可信任的最少已確認區塊數量（minimum block confirmation numbers）。
  • 權益證明：一般情況下最短在 2-epoch（~12 分鐘）後可取得最終確定性（finality）
    • 一旦鏈 “finalized”，攻擊者需取得 2/3 以上的驗證者票數且付出高額罰金才可改變鏈上狀態

33

34 of 39

對以太坊應用層的影響: block “head”

34

Block Type

Consensus Mechanism

JSON-RPC

Conditions for reorg

head

Proof of Work

latest

reorg 的發生是可預期的，要謹慎使用

safe head

Proof of Stake

safe

有可能發生，可能來自大規模的網路延遲或是攻擊

confirmed

Proof of Work

N/A

不太可能，需要多數的 hashrate 參與挖一條長度大於特定確認數的鏈

finalized

Proof of Stake

finalized

極不可能，需要大於 2/3 的驗證者參與競爭鏈且至少 1/3 的驗證者會被處以罰金（slashed）

source: How The Merge Impacts Ethereum’s Application Layer

35 of 39

35

[Serenity]

36 of 39

#TestingTheMerge

  • Kiln testnet 🔥🧱

37 of 39

相關資源

38 of 39

Thanks!

Any questions?

​

@hwwhww on GitHub

@hsaio-wei#0696 on Discord

@icebearhww on Twitter

​

38

CREDITS: This presentation template was created by Slidesgo, including icons by Flaticon, infographics & images by Freepik

39 of 39

39