撰文：Tim Beiko
編輯：南風
以太坊向PoS 的過渡——合併——即將到來：devnets (開發網絡) 正在被建立起來，規范正在被敲定，向社區拓展也已經正式開始。合併被設計為對以太坊終端用戶、智能合約和 dapps 的影響最小化。儘管如此，還是有一些細微的變化值得強調。在我們深入研究這些變化之前，這裡有一些鏈接提供關於整體合併架構的概述：
- 以太坊路線圖的演變：
- https://tim.mirror.xyz/CHQtTJb1NDxCK41JpULL-zAJe7YOtw-m4UDw6KDju6c
- 合併之後的客戶端架構：
- https://tim.mirror.xyz/CHQtTJb1NDxCK41JpULL-zAJe7YOtw-m4UDw6KDju6c
本文的其餘部分將假設讀者熟悉上述內容。如果你想要更深入地了解合併的完整規範，可參閱：
- 執行層：
- https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/merge.md
- 共識層：https://github.com/ethereum/consensus-specs/tree/dev/specs/merge
- 引擎API：
- https://github.com/ethereum/execution-apis/tree/main/src/engine
01. 區塊結構
在合併之後，PoW 區塊將不再存在於以太坊網絡上。相反，此前的PoW 內容將成為信標鏈上創建的區塊的一部分。屆時你可以將信標鏈視為以太坊新的PoS 共識層，取代之前的PoW 共識層。信標鏈區塊將包含ExecutionPayloads, 這是當前PoW 鏈的區塊在合併之後的等價物。下圖展示了這種關係：
對於終端用戶和應用開發者而言，這些 ExecutionPayloads 是與以太坊發生交互的地方。在這一層上面的交易將依舊被執行層客戶端(Besu、Erigon、Geth、Nethermind 等) 處理。幸運的是，由於執行層的穩定性，合併只會引入最小的破壞性更改。
挖礦& Ommer 區塊字段
合併後，之前包含在PoW 區塊頭中的幾個字段將不再使用，因為它們與PoS 無關。為了盡量減少對工具和基礎設施的破壞，這些字段被設置為0，或者它們的數據結構的等效值，而不是從數據結構中完全刪除。區塊字段的全部變化可以在 EIP-3675 中找到：
https://eips.ethereum.org/EIPS/eip-3675#block-structure
由於PoS 不像PoW 那樣自然產生ommers (又稱叔塊)，因此每個區塊中的這些列表(ommers) 將是空的，而該列表的哈希(ommerHash) 將成為一個空列表的RLP 編碼哈希。類似地，由於 difficulty 和nonce是PoW 具有的特徵，它們將被設置為0，同時賦予它們字節大小值。另一個與挖礦相關的字段mixHash將不會被設置為0，而是將包含信標鏈的RANDAO 值。下文將更加詳細地對此進行闡述。
BLOCKHASH & DIFFICULTY 操作碼變更
合併之後，BLOCKHASH 操作碼將仍然可以使用，但鑑於它將不再通過PoW 哈希過程締造，因此此操作碼提供的偽隨機性將會弱得多。與此相關，DIFFICULTY 操作碼(0x44) 將被更新並重命名為 RANDOM。合併後，此操作碼將返回信標鏈提供的隨機信標的輸出(output)。因此，與 BLOCKHASH 相比，這個操作碼將成為應用程序開發者們使用的一個更強大的(儘管仍然存在偏差的) 隨機性來源。 RANDOM 公開的值將存儲在 ExecutionPayload 中，其中存儲了與PoW 計算相關的 mixHash 值值。該payload 的mixHash 字段也將被重命名為random。下方是 DIFFICULTY & RANDOM 操作碼在合併前和合併後如何運作的圖解：
在合併之前，我們看到 0x44 操作碼會返回區塊頭的 difficulty 字段。合併之後，此操作碼重命名為 RANDOM，並指向先前包含 mixHash 的區塊頭字段，現在存儲來自信標鏈狀態的 random 值。此變更在 EIP-4399中正式提出，也為鏈上應用提供了一個評估合併是否發生的方式。 EIP-4399:
https://eips.ethereum.org/EIPS/eip-4399
下方摘取自EIP-4399：
此外，此EIP 提議的更改將允許智能合約確定是否已經升級到 PoS。這可以通過分析DIFFICULTY 操作碼的返回值來確定。如果該返回值大於2**64，則表示交易正在PoS 區塊中被執行。
02. 出塊時間
合併將影響以太坊上的平均出塊時間。目前，在PoW 機制中，出塊時間平均每~13秒，實際出塊時間可能有相當大的變化。在PoS 機制中，出塊時間被精確到12 秒，除非由於某個驗證者離線或者因為沒有及時提交區塊而導致某個slot 沒有出塊。但在實踐中，這種情況只發生在不到1% 的slots 中。這意味著PoS 網絡上的平均出塊時間減少了約1 秒。對於在計算中假定了某個特定的出塊時間的智能合約，將需要考慮到這一點。
03. 安全頭部區塊 & 被敲定區塊
在PoW 機制中，總是存在區塊重組的可能性。應用程序通常會等待在新的頭部區塊(head block) 之上挖出幾個區塊之後，才會將該這個區塊視為不太可能從權威鏈中被移除，也即視該區塊“被確認”(confirmed)。而在合併之後，我們有了“被敲定”(finalized) 和“安全的頭部區塊”(safe head block) 的概念。與PoW 機制中“被確認”的區塊相比，PoS 中的這些區塊要更加可靠，但需要理解上的轉變才能正確地使用。 “被敲定”的區塊是指該區塊被超過2/3 的PoS 驗證者接受為規範(權威) 的區塊。如果攻擊者想要創建一個與之相衝突的區塊，那麼攻擊者將必須銷毀ETH 總質押量的1/3。截至撰文時，這意味著超過價值100 億美元(或超過250 萬枚) 的ETH。安全頭部區塊 (safe head block) 是指在正常的網絡條件下，我們期望被納入權威鏈中的區塊。假設網絡延遲小於4 秒，且大多數驗證者都是誠實的，同時沒有對分叉選擇規則的攻擊，那麼安全頭部區塊就永遠不會成為孤塊。下方鏈接是一個詳細介紹在各種情況下如何計算安全頭部區塊，此外我們將在之後發表的文章中對安全頭部區塊的假設和保證進行正式定義和分析：
https://docs.google.com/presentation/d/1MUVaFyd9ce3hPQ5L-UhqVSfxf1ajMYFbkActkp5xNKI/edit#slide=id.gf1d0105ca5_0_147
合併之後，執行層API (例如JSON RPC) 將在被要求提供 latest (最新) 區塊時默認返回安全頭部區塊。在正常的網絡條件下，安全頭部區塊和區塊鏈的頂端將是等同的(安全頭部區塊會落後幾秒鐘)。與當前PoW 的 latest (最新) 區塊相比， PoS 中的安全頭部區塊將更不可能被重組。為了顯露出PoS 鏈的實際頂端，將向JSON RPC 添加一個 unsafe 標誌。被敲定的區塊也將通過JASON RPC 的一個全新的 finalized (被敲定) 標誌來顯露出來。這些可以作為PoW 確認的一個強大的替代方式。下表對此進行了總結：
04. 後續行動
我們希望這篇文章能幫助應用程序開發者為期待已久的PoS 過渡做好準備。在接下來的幾週內，一個長期存在的合併測試網將被更廣泛的社區用於測試。還有一場即將到來的有關合併的社區電話會議(見下方鏈接)，讓基礎設施、工具和應用程序的開發者們拋出問題，並聽取關於合併的最新技術更新。我們不見不散👋🏻：
https://github.com/ethereum/pm/issues/419
感謝Mikhail Kalinin 提供了本文“安全頭部區塊”部分的核心內容，感謝Danny Ryan 和Matt Garnett 審閱了本文的草稿。
特別聲明
免責聲明：本文不代表0x财经立場，且不構成投資建議，請謹慎對待，如需報導或加入交流群，請聯繫微信：VOICE-V。
來源：Unitimes