--- slideOptions: theme: solarized # transition: 'fade' slideNumber: true --- # 以太坊 The Merge 合併之技術面懶人包 (2022-04 version) #### A Brief Technical Summary of The Merge Upgrade on Ethereum <br></br> #### Hsiao-Wei Wang #### GitHub @hwwhww | Twitter @icebearhww #### Ethereum Foundation | Researcher #### 2022-04-11 Taipei Ethereum Meetup --- [TOC] ## Abstract 萬眾期待以太坊的共識演算法主網大升級，隨著近期的規格書與程式碼迭代、測試鏈如火如荼展開，今年有高機率主鏈會有一次大改版。 以下介紹以太坊合併協議、客戶端（client）技術架構以及對以太坊開發者有什麼影響。 --- ## 所謂合併 The Merge 1. 將以太坊的共識演算法（Consensus algorithm）從工作量證明（Proof-of-Work, PoW）切換到 **權益證明（Proof-of-Stake, PoS）** 2. 將以太坊 EVM 主鏈 與 信標鏈（Beacon chain）合併 3. 將未來以太坊系統分成 **共識層（Consensus Layer）** 以及 **執行層（Execution Layer）** --- ## 前情提要：信標鏈 Beacon Chain - 2020 年 12 月 Ethereum beacon chain phase 0 上線。Phase 0 的 beacon chain： 1. 核心採用 **Casper FFG** 協定實現權益證明共識機制 2. 是以太坊 PoW 主鏈的側鏈：要成為 beacon chain 上的驗證者（validator），使用者需在 PoW 主鏈上按照協議抵押 32 ETH 在 *deposit contract* 上。而 beacon chain 的節點們會根據 deposit contract 上的 log，在 beacon chain state 中加入通過驗證的此筆驗證者資料（例如：公鑰、餘額、提款方式），進而成為驗證者。 - 截至 2022 年 4 月，有 10M ETH 已投入 deposit contract staking，多達 34 萬個有效最小單位驗證者 (validator) 🔥 - 最新數據可參考 [Beacon chain explorer](https://beaconcha.in/) - 有多達四個以上信標鏈節點軟體客戶端（client）開發團隊 - [EthStaker](https://ethstaker.cc/) --- ## Components  --- ### Execution Layer (EL) 執行層 #### 目前的 PoW chain  #### Execution Layer 的 `ExecutionPayload`  - PoW mining 相關的欄位將會被棄用 - 一樣使用 EVM 執行交易 ##### Image: [When Merge](https://opensea.io/collection/when-merge) by Danny Ryan --- ### Consensus Layer (CL) 共識層 #### 合併後的 BeaconBlock  - `BeaconBlock` 會含有來自 EL 的 [`ExecutionPayload`](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/beacon-chain.md#executionpayload) - 外層的`state_root`: beacon chain state - EL 內的 `state_root`: EVM account state ##### Image: [When Merge](https://opensea.io/collection/when-merge) by Danny Ryan --- ### 相關 APIs  ##### Image: [When Merge](https://opensea.io/collection/when-merge) by Danny Ryan - Beacon node (CL) 和 execution engine (EL) 之間會以 [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md) 溝通。 - P2P：各自開啟向外網路所需的接口 port - web3：或將新增 beacon chain 相關 web3 APIs --- #### Engine API usecase example ```sequence Note over CL: Beacon block B arrives CL -> EL: engine_newPayload(B.payload) Note over EL: B.payload validation EL --> CL: "PayloadStatus: VALID" Note over CL: B becomes the head CL -> EL: engine_forkchoiceUpdated(forkchoiceState, payloadAttributes) EL --> CL: "PayloadStatus: VALID" ``` --- ### EL/CL Separation | | EL | CL | | -------- | -------- | -------- | | 主要功能 | 執行 EVM | Proof-of-Stake 共識 | | Fork choice rule | 由 CL 告知 head block | LMD-Ghost | EVM transaction pool | 不變 | N/A | | 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 --- ## 協議如何決定何時觸發合併? (1/2) - Step 1: - CL 端會先進行 [*Bellatrix Upgrade 硬分岔*](https://github.com/ethereum/consensus-specs#bellatrix-also-known-as-the-merge)，以轉為和 The Merge 相容的 state transition 邏輯與區塊格式 - 在 `BeaconBlock` 新增 `execution_payload: ExecutionPayload` 欄位 - 在 `BeaconState` 新增 `latest_execution_payload_header: ExecutionPayloadHeader` 欄位 - 在 EL 端硬分岔之前，新欄位內容為空值 --- ## 協議如何決定何時觸發合併? (2/2) - 定義： - **`TERMINAL_TOTAL_DIFFICULTY` (TTD)**: 觸發合併的 total difficulty 值 - **Terminal PoW block**: 需同時符合以下 *兩個* 條件的 PoW block: 1. `pow_block.total_difficulty >= TERMINAL_TOTAL_DIFFICULTY` 2. `pow_block.parent_block.total_difficulty < TERMINAL_TOTAL_DIFFICULTY` - **Transition block**: 第一個 `execution_payload` 不為空值的 PoS block - Step 2: - Beacon block proposer 呼叫 Engine API 以取得一個 parent block hash 指向 terminal PoW block 的 非空 execution payload，並將此 execution payload 值填入至 beacon block 中。 - 此 beacon block 即為 transition block --- ## Merge Transition  ##### Image: [When Merge](https://opensea.io/collection/when-merge) by Danny Ryan - `TERMINAL_TOTAL_DIFFICULTY`: 上圖第 2 個 PoW block - `TRANSITION_BLOCK`: 上圖第三個 Beacon block --- ## 相關規格及文件 - EL: [Paris Upgrade Specification](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md) - [EIP-3675: Upgrade consensus to Proof-of-Stake](https://eips.ethereum.org/EIPS/eip-3675) - [EIP-4399: Supplant DIFFICULTY opcode with PREVRANDAO](https://eips.ethereum.org/EIPS/eip-4399) - CL: [Bellatix Upgrade Specification](https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix) - [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md) --- ## 對以太坊應用層的影響 ### 1. EVM - **`DIFFICULTY (0x44)`** opcode: - 因為已無 mining，PoS 鏈上不再有 difficulty - [EIP-4399](https://eips.ethereum.org/EIPS/eip-4399): 為了向下相容，改名為`PREVRANDAO` 並使用 beacon chain 上產生的亂數作為 `PREVRANDAO` 的值 - **`BLOCKHASH (0x40)`** opcode: 由於 ExecutionPayload 中 mining 相關欄位被棄用了，所以此值更容易被操縱！不建議使用 `BLOCKHASH` 產生亂數值  ##### Ref: [How The Merge Impacts Ethereum’s Application Layer](https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/) --- ### 2. Block time 區塊時間 - 信標鏈的邏輯中，區塊是以 "time slot" 來編號。正常狀況下固定為 12 秒/區塊 - 少數狀況（<1%）會有被 "跳過" 的區塊，此時區塊時間會拉長 - 注：特定 slot 的區塊必須由特定的驗證者負責產生並簽名，若驗證者未在一定時間內廣播出區塊，則這個 slot 會被跳過。 --- ### 3. Finality 最終確定性 - 要注意權益證明的區塊鏈 finality (最終確定性) 有所不同。 - 工作量證明: 只有**機率上的**最終確定性，服務提供者自行選擇所信任的已確認 (confirmed) 區塊(多少) 數量 - 權益證明：一般情況下最短在 2-epoch（~12 分鐘）後可取得最終確定性（finality） - Note: 一旦鏈 "finalized"，攻擊者需取得 2/3 以上的驗證者票數且付出高額罰金才可改變鏈上狀態 --- ### 4. Safe Head - 轉自 [How The Merge Impacts Ethereum’s Application Layer](https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/) - 現階段先用 justified block 作為 safe head，未來會再優化計算出更近期的 safe head | 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） | --- ## 近期開發進度 (2022年4月) - 大型公開測試鏈 [Kiln testnet](https://kiln.themerge.dev/) 已在 3 月 15 日上線，歡迎以太坊使用者可以先在測試鏈上測試如何架設節點 - Core devs 在 Goerli testnet 上進行了多次 shadow forks，發現了一些 issue 並修正 - 注：shadow fork：對公鏈進行分岔出私鏈，不影響公鏈運作狀況 - 近期將在 Mainnet 上測試 shadow forks - 4月底 core devs 會決定是否延期難度炸彈 - 注：若不延期，5月開始會有感難度提升 --- ## 其他 "longer-term extras"  ##### Image: [roadmap diagram](https://twitter.com/VitalikButerin/status/1466411377107558402) by Vitalik Buterin --- ### Post-merge 硬分岔 - EL: [Shanghai upgrade](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) - CL: [暫名/內容仍在作業中] [Capella upgrade](https://github.com/ethereum/consensus-specs/tree/dev/specs/capella) - 主要新增了讓驗證者可提領在 beacon chain 的餘額至 EL 的功能 --- ### Single secret leader election (SSLE) - 目前的區塊 proposer 決定方式為：協議會預先根據偽隨機亂數爲各個 block slot 計算出區塊 proposer 和負責驗證的 validator set - SSLE 研究意圖以密碼學技術使得協議可在其他人無法得知的情況下，隨機選出區塊 proposer - Ref: - [Single Secret Leader Election](https://eprint.iacr.org/2020/025.pdf) paper by D. Boneh, Saba Eskandarian, L. Hanzlik, Nicola Greco - [Ethresear.ch 上的討論](https://ethresear.ch/tag/single-secret-leader-election) --- ### Single slot finality - 當前信標鏈需至少 12 分鐘，區塊才會 finalized。 - 為了提升 UX、MEV reorg resistance、與減少協議的複雜度，Single slot finality 研究能如何突破目前資源限制以在一個 slot 內達到 finality。 - Ref: [Paths toward single-slot finality](https://notes.ethereum.org/@vbuterin/single_slot_finality) by Vitalik --- ### Better signature aggregation - 目前信標鏈的 BLS 簽名在 P2P層廣播的過程中，會先廣播至較小的 subnet，由 aggregator 聚合，然後再廣播至 global network - 更有效率的 aggregation model，將可幫助縮短 block time。 - Ref: - [Paths toward single-slot finality](https://notes.ethereum.org/@vbuterin/single_slot_finality#Idea-2-try-really-hard-to-make-very-high-attester-counts-work) by Vitalik - [A note on Ethereum 2.0 attestation aggregation strategies ](https://notes.ethereum.org/@hww/aggregation) by Hsiao-Wei Wang --- ## 補充資料 - [The Merge Mainnet Readiness Checklist](https://github.com/ethereum/pm/blob/master/Merge/mainnet-readiness.md) - [What’s New in Eth2](https://eth2.news/) --- # Thank you! ## 🐼 --- <style> .reveal { font-size: 24px !important; } .reveal h1 { font-size: 70px !important; } .reveal h4 { font-size: 30px !important; } .reveal h5 { font-size: 16px !important; } .reveal code { color: #268bd2 !important; } .reveal li { padding-top: 0.5em; } .reveal b, strong { color: #d33682; } .reveal i, em { color: #2aa198 !important; } .reveal section img { border: 0; box-shadow: 0 0 0px } </style>