以太坊PoW&PoS合併The Merge在即，應用層會受到哪些影響？

來源：

作者：以太坊開發者、以太坊基金會社區經理Tim Beiko

以太坊網路向權益證明的過渡（The Merge）即將到來：目前開發網路正在建立，規範也進入最終確定，社區外展準備工作已經認真開始。The Merge旨在過渡過程中對最終用戶、智能合約和 dapps 的運作方式產生最小的影響。也就是說，在這個過程中，有一些小的變化值得強調。在我們深入研究這些變化之前，下面有一些鏈接可以提供有關The Merge 整體架構的一些了解：

• 路線圖演變‌
• 合併後客戶端架構‌

本文的其餘部分將假設讀者熟悉上述內容。對於那些想要更深入挖掘的人，下面可獲得 The Merge 的完整規範：

• 執行層‌
• 共識層‌
• 引擎API‌

區塊結構

以太坊合併之後，網路上將不再存在工作量證明（PoW）。相反，以前的PoW部分將成為信標鏈（Beacon Chain）上創建的區塊的組成部分。然後，您可以將信標鏈視為以太坊新的PoS共識層，取代之前的PoW共識層。信標鏈區塊將包含 ExecutionPayloads，這是當前PoW鏈上區塊的合併後等價物。下圖顯示了這種關係：

對於最終用戶和應用開發人員來說，這些 ExecutionPayloads 是與以太坊進行交互的地方。該層上的交易仍將由執行層客戶端（Besu、Erigon、Geth、Nethermind 等）處理。幸運的是，由於執行層的穩定性，The Merge 只引入了最少的破壞性更改。

挖礦和Ommer區塊欄位

合併後，之前包含在PoW區塊頭中的幾個欄位不再使用，因為它們與PoS無關。為了最大限度地減少對工具和基礎設施的破壞，這些欄位被設置為 0，或者它們的數據結構的等效項，而不是從數據結構中完全刪除。你可以在 EIP-3675 中找到對區塊欄位的完整更改內容。

因為PoS不會像PoW那樣自然產生 ommers（又名叔塊），所以每個叔塊（ommers）中的這些列表將為空，這個列表的哈希（ommersHash）將成為 RLP 編碼哈希的一個空列表。同樣，因為PoW還包含了難度和隨機數，所以此後它們將被設置為 0，同時賦予它們位元組大小值。

另一個與挖礦相關的欄位 mixHash 不會設置為 0，而是包含信標鏈的 RANDAO 值。下文將會對此進行更多介紹。

BLOCKHASH & DIFFICULTY 操作碼更改

合併後，BLOCKHASH 操作碼仍可使用，但考慮到它不再通過PoW哈希程序偽造，此操作碼提供的偽隨機性將弱得多。

相關地，DIFFICULTY 操作碼 (0x44) 將被更新並重命名為 RANDOM。合併後，它將返回信標鏈提供的隨機信標的輸出。因此，與 BLOCKHASH 相比，儘管仍然存在偏差，此操作碼將成為應用程序開發人員使用的更強大的隨機源。

RANDOM 公開的值將存儲在 ExecutionPayload 中，其中存儲了與PoW計算相關的值 mixHash。Payload 的 mixHash 欄位也將被重命名為 random。

這是 DIFFICULTY & RANDOM 操作碼在合併前和合併後如何工作的說明：

合併前，我們看到 0x44 操作碼返回區塊頭中的難度欄位。合併後，重命名為 RANDOM 的操作碼指向先前包含 mixHash 的區塊頭欄位，現在存儲來自信標鏈狀態的隨機值。

這一變化在 EIP-4399 中得到正式化，也為鏈上應用程序提供了一種評估合併是否發生的方法。根據這個EIP的介紹：

此外，此 EIP 提出的更改允許智能合約確定是否已升級到 PoS。這可以通過分析 DIFFICULTY 操作碼的返回值來完成。如果值大於 2**64 ，則表示交易正在 PoS 區塊中執行。

出塊時間

合併將影響以太坊的平均區塊時間。目前在PoW下，平均每約 13 秒產出一個區塊，實際區塊間隔時間有相當大的差異。在權益證下，區塊間隔將恰好為12 秒，除非由於驗證者離線或因為他們沒有及時提交區塊而錯過了某個時隙。在實踐中，發生這種情況的插槽<1%。

這意味著網路上的平均出塊時間減少了約 1 秒。在計算中假設特定平均區塊時間的智能合約需要考慮到這一點。

安全頭區塊（safe head）和最終區塊

在PoW下，區塊重組在一直都可能出現。應用通常會等待在新頭區塊（safe head）上挖出幾個區塊，然後再將其視為該區塊已不太可能從規範鏈中被刪除，或已經得到「確認」。在合併之後，我們有了最終和安全的頭部區塊的概念。這些區塊可以比「已確認」的PoW區塊更可靠地使用，但需要改變理解才能正確使用。

最終確定的區塊是指被超過 2/3 的驗證者接受為規範的區塊。要創建一個衝突區塊，攻擊者必須至少銷毀ETH總質押數量的 1/3，在撰寫本文時，這意味著超過 100 億美元（或 >250 萬枚）的ETH。

安全頭區塊（safe head）是指在正常網路條件下，我們希望包含在規範鏈中的區塊。假設網路延遲小於 4 秒，大多數驗證者都是誠實的，並且沒有對分叉選擇規則的攻擊，那麼safe head將永遠不會成為孤兒塊。此處提供了詳細介紹如何在各種情況下計算safe head的演示文稿。此外，safe head的假設和保證將在即將發表的論文中得到正式定義和分析。

合併後，執行層 API（例如 JSON RPC）在要求提供最新區塊時將默認返回安全頭（safe head）。在正常的網路條件下，safe head和鏈的實際頂端將是等效的（安全頭尾僅幾秒鐘）。與當前的PoW最新區塊相比，safe head不太可能被重組。為了公開PoW鏈的實際提示，將向 JSON RPC 添加一個unsafe標誌。

最終區塊也將通過 JSON RPC 公開，通過一個新的finalized標誌。然後，這些可以作為PoW證明的更強大的替代品。下表總結了這一點：

區塊類型共識機制JSON RPC發生重組的條件headPoWlatest可以預料到，必須小心使用headPoSunsafe可以預料到，必須小心使用safe headPoSlatest可能發生，但需要大的網路延遲或對網路的攻擊才能實現。confirmedPoWN/A不太可能發生，因為需要大部分算力來挖一個深度 > # 確認的競爭鏈。finalizedPoSfinalized極不可能發生，因為需要超過 2/3 的驗證者來完成一個競爭鏈，需要至少 1/3 被削減。

下一步

我們希望這篇文章可以幫助應用程序開發人員為備受期待的PoS過渡做好準備。在接下來的幾周內，有一個測試網將可供更廣泛的社區進行測試。還有一個即將到來的 The Merge 社區呼籲基礎設施、工具和應用程序開發人員提出問題並聽取有關 The Merge 的最新技術更新。

————————————————– ——————————

感謝 Mikhail Kalinin 提供「Safe Head」部分的核心內容，感謝 Danny Ryan 和 Matt Garnett 審閱這篇文章的草稿。