以太坊基金會｜明年若成功轉PoS後，對應用層會有什麼影響？

(本文由鏈新聞翻譯自以太坊基金會文章，原文請見)

以太坊過渡至權益證明 (PoS，proof of stake) 將至 – The Merge(合併)：目前 Devnet (開發者社群) 已建立、規格也確立了，正迫不急待地與社群分享。The Merge(合併) ，是以對終端用戶、智能合約與 dapp(去中心化應用) 最小化影響為設計。也就是說，只有些許次要的改變值得受到關注。在我們深究之前，可以從以下這幾個連結了解背景知識：

• 路線演進
• 合併後的用戶端架構

這篇文章會假定讀者已經有上述的基礎知識。如果想了解更深，可以從以下內容了解完整的規格：

• Execution Layer
• Consensus Layer
• Engine API

區塊結構

在合併後，工作證明的區塊將不再存在於網路上。取而代之的是，過往工作證明的內容，將成為 Beacon Chain 上創建區塊的元件。你可以將 Beacon Chain 想成新的以太坊權益證明共識層，而它取代了先前的工作證明共識層。Beacon Chain 區塊將包含 ExecutionPayloads，它等同於合併後在現在工作證明鏈上的區塊。如下圖表示：

對終端用戶與應用開發者來說，這些 ExecutionPayloads 指的是與以太坊發生互動的地方。此層的交易仍會由執行層的客戶端處理 (Besu, Erigon, Geth, Nethermind 等)。好處是，因為執行層的穩定，合併只會有極小的突破性改變。

挖礦與 Ommer 區塊字段

合併後，許多字段包含工作證明的區塊頭 (block header)，將因為與權益證明無關而被棄用。為了減少工具與基礎建設的傷害，這些字段將被設為 0，或是其資料架構的同質物，而不會接將其從資料架構完全移除。完整的區塊字段改變可以參照 EIP-3676。

因為權益證明不會像工作證明一樣自然產生 Ommers (也就是「叔塊」uncle block)，每個區塊中的這些列表 (ommers) 會是空值 (empty)，而這個列表的 hash (ommers hash) 將會變成一組空值列表的 RLP (Recursive Length Prefix) 編碼 hash。相同地，因為難度 (difficulty) 與 nonce 是工作證明的主要特點，這些也會被設為 0，以位元組的值顯示。

mixHash，是另一個與挖礦有關的字段，但不會被設為 0，而是含有 beacon chain 的 RANDAO 值。更多內容如下。

BLOCKHASH 與 DIFFICULTY 操作碼改變

合併後，BLOCKHASH 的操作碼還是可以使用，但因為不再有工作證明的雜湊過程，這個操作碼所提供的偽隨機性將會大幅削弱。

還有，DIFFICULTY 操作碼 (0x44) 將會更新，並重命名為 RANDOM。合併後，它將傳回由 beacon chain 所提供的隨機 beacon 輸出值。比起 BLOCKHASH，這個操作碼對於應用開發者來說，會是更強大 (儘管這是主觀意見) 的隨機來源。

由 RANDOM 產出的值會被處存在 ExecutionPayloadwhere，也就是之前 mixHash (與工作證明計算有關的值) 的儲存位置。payload 的 mixHash 字段也會被重新命名為 random。

下圖是 DIFFICULTY 跟 RANDOM 兩操作碼在合併前與合併後的運作方式：

合併前，我們看到 0x44 操作碼傳回區塊頭中的 difficulty 的字段。合併後，原先指向先前包含 mixHash 頭字段的操作碼，會重新命名為 RANDOM，負責儲存來自 beacon chain 狀態的 random 值。

這項改變，是在 EIP-4399 中擬定，它提供鏈上應用去評定合併是否已經發生。根據該 EIP：

而且，由這項改進建議所提出的改變，可以讓智能合約判別 PoS 升級是否已經發生。這是透過分析 DIFFICULTY 操作碼傳回的值所做到的。當值大於 2**64，就代表交易已經在 PoS 區塊中執行了。

區塊時間

合併將影響以太坊平均區塊時間。目前在工作證明之下，平均出塊時間大概是 13 秒，實際每次時間仍有差異。在權益證明下，出塊會變成確切的每 12 秒一次，除非驗證者離線獲釋他們沒有及時提交區塊，才會錯過一個時段 (slot)。實際上，這樣的情況在所有時段中是小於 1% 的。

這表示，整體網路平均出塊時間減少了約一秒。因此有設置特定平均區塊時間的智能合約會需要考慮到這件事。

安全頭塊與最終塊

在工作證明之下，都會有重組 (reorg) 可能。應用程式通常會等待新頭塊後的數個區塊後，才會確認它不會從主鏈 (canonical chain) 上被移除，或是「區塊確認」。在合併之後，我們不會有這些「最終化」(finalized) 與安全頭塊的概念。比起工作證明的「區塊確認」這些區塊可以更可靠地被使用，但也需要理解和適應，正確地被使用。

最終塊 (finalized block) 是指被主鏈上大於三分之二的驗證者接受。要創建與之衝突的區塊，攻擊者需要銷毀至少三分之一的質押總數 (total stake)。截稿時，這相當於以太坊上超過 100 億美元價值 (或大於 250 萬個 ETH)。

安全頭塊 (safe head block) 是指，在正常網路狀況下，我們預期它會被納入主鏈。假設網路延遲少於四秒，有誠實多數的驗證者，也沒有人選擇用分叉規則來攻擊，安全頭塊將永遠不會成為孤塊 (orphaned)。可以在這邊看到安全頭塊在多種情境下是如何被計算的。而且，這些安全頭塊假設與保證已在即將出爐的報告中正式的被定義與解析。

合併後，執行層的 API (像是 JSON RPC) 會在要求最新區塊時，預設將安全頭塊傳回。在正常的網路狀態下，安全頭塊與實際的最新鏈會是相同的 (基於安全頭塊只需幾秒就跟上)。比起現在的工作證明最新區塊，安全頭塊將不太可能被區塊重組。為了顯示權益證明鏈上的實際最新狀態，JSON RPC 會增添 unsafe 標示。

下一步

我們希望這篇文章能夠幫助應用開發者做好準備，迎接眾所期待的權益證明過渡。未來幾週，存在已久的測試網將會給更廣大的社群測試。也會有支持合併的社群，透過電話會議向基礎設施、工具與應用開發者提問，了解最新合併的最新技術更新。期待與你相見。

原文連結