這一篇會介紹 Eth2.0 的客戶端架構中共識和執行兩個元件的拆分以及 The Merge 對應用和開發者的影響。

在第一次寫共識與執行拆分時，當時以為 Eth 2.0 客戶端架構中的共識層（Consensus Layer，以下代稱 CL）及執行層（Execution Layer，以下代稱 EL）拆分是真的在協議設計上將共識與執行分開，但其實只是 Eth 2.0 客戶端軟體工程上的架構拆分而已，實際上共識和執行還是綁在一起的。

至於共識和執行綁在一起是什麼意思，可以參考我後來寫成的這篇：

接下來會先介紹 Eth 2.0 的 CL 和 EL 架構，然後會介紹 The Merge 將 PoW 併入 PoS 鏈後，對應用及開發者的影響。

將客戶端再細分為 CL 及 EL

這裡的資料參考 Hsiao-Wei Wang 的「以太坊 The Merge 合併之技術面懶人包 (2022–04 version)」 文件，裏面有許多連結和補充。

Eth 1.0 及 Eth 2.0 的共識機制

Eth 1.0 的共識機制由 PoW 和 Fork Choice Rule 組成，節點在收到一個新的區塊時，先驗證 PoW 的有效性，接著比對新的鏈所累積的 work 是否是最高的，如果是的話就採用新的鏈。

Eth 2.0 也是一樣的組成，只是 PoW 換成 PoS，而是否選擇新的鏈在於驗證者（Validator）的見證（Attestation）數量，如果一個區塊被越多驗證者見證則它的權重越高，而節點會選擇權重高的鏈。

執行、驗證交易

上一段講到節點收到一個新的區塊時所執行的步驟其實還少了一步：執行、驗證區塊裡的交易，確保交易是有效的。因為其他節點不會接受包含無效交易的區塊，收錄這樣的區塊會導致你的鏈分叉出去。

在 Eth 1.0 的客戶端中，驗證 PoW、Fork Choice Rule 和執行驗證交易是綁在一起的。當你跑起 Geth，每次它收到新的區塊就會執行這三個步驟。但在 Eth 2.0 的客戶端中，這三個步驟被分開了：驗證 PoS 和 Fork Choice Rule 交給 CL，執行驗證交易交給 EL。

例如當前的 Eth 2.0 客戶端之一 Prysm 就是一個 CL，那 EL 是誰呢？答案是目前還沒有。目前的 Beacon chain 節點都是對一個一個裝著無意義內容的 Dummy 區塊去達成共識，但在 The Merge 之後，原本的 Geth 就會放下驗證 PoW 及 Eth 1.0 Fork Choice Rule 的工作，專門負責執行驗證交易，變成 Eth 2.0 的 EL。

CL 和 EL 的合作方式

拆成 CL 和 EL 元件之後表示你可以選擇跑起自己的 CL（例如 Prysm），但是 EL（例如 Geth） 是和其他人一起共用，其實就像現在的礦池一樣，你加入礦池只負責算 PoW，不負責驗證交易或是打包交易。或是你也可以自己跑 CL 和 EL。

而 CL 和 EL 之間會透過一層定義好的 API （叫做 Engine API）來溝通。每當 CL 收到新的區塊時，它會將裡面的 EL 相關內容送去請 EL 驗證，並依照 EL 的回覆內容決定區塊是否合法。如果區塊合法且依照 CL 的 Fork Choice Rule 判斷，選擇將該區塊所代表的鏈作為最長鏈，則 CL 會去通知 EL「目前最新的區塊是這一個區塊，請套用裡面的交易並算出最新的 State 並更新」。

不過 CL 和 EL 分拆之後，也代表它們是各自獨立的，不只是開發者、使用者要和它們個別互動，CL 和 EL 之間的 p2p 網路也是獨立的。

原本開發者熟悉的取用鏈上資料的 web3.eth 用法還是會照舊，web3.eth 背後會去 EL （一樣是 Geth）拿資料。如果是需要共識、PoS 相關的資料，要透過新增的 web3.beacon 方法去拿，web3.beacon 背後會去 CL 拿資料。而 CL 和 EL 會分別使用不同的 p2p 網路去和其他 CL 或 EL 溝通：EL 還是使用原本的 Eth 1.0 的 devp2p，CL 則是使用 Eth 2.0 的 libp2p。

基本上就想像成原本的 Geth 節點（包含 p2p 網路）都照舊繼續運作，只是共識（PoW、Fork Choice Rule）的元件被拔掉，交給另一個獨立的節點（CL，例如 Prysm）來負責。開發者所使用的 web3 套件例如 web3.js 或 ethers.js 會自動將不同指令送到不同節點，開發者不需要擔心。

這裡可以注意的是 EVM 交易還是會走原本的 devp2p 網路送到 EL 節點而不是 CL 節點，表示如果你的 CL 節點是一個準備要 propose 區塊的驗證者時，它會需要去請 EL 幫它組 EL 區塊，裡面放的是 EVM 交易。CL 自己也要組 CL 的區塊，只是裡面放的是 Attestation，和 EVM 無關。

The Merge 的影響

The Merge 還要一段時間才會發生，雖然對開發者影響不大，但有時間還是可以提早想一下你的項目、應用或使用的服務是否會受到影響，並提早規劃遷移。尤其是使用區塊資訊當亂數來源的應用。

以下資訊是參考基金會發佈的這篇文章：

在 PoS 中，區塊間隔會固定為 12 秒產出一個區塊，每 12 秒稱作一個 slot。每個 slot 會有一個驗證者被選到負責 propose 區塊，如果驗證者不在線上或來不及送出區塊，這個 slot 就會被其他驗證者視為空的 slot，也就導致下一個區塊要再延遲 12 秒才會產出。

DIFFICULTYopcode 改名並被挪用

首先因為沒有 PoW，也就再沒有難度（Difficulty）的概念，但為了向下兼容（讓使用到 DIFFICULTY opcode 的合約不會直接壞掉），所以 DIFFICULTY opcode 將改名為 PREVRANDAO，並且這個值會改成放每一個 slot 由驗證者們累積產生的亂數值。所以原本有用到 DIFFICULTY 這個 opcode 的合約在 The Merge 之後，就不能再假設這個值會繼續遞增，而是會是一個亂數。

BLOCKHASH opcode 的值將更好被操控

Block Hash 由區塊內容決定，雖然區塊內容都是礦工決定，但因為裡面包含 PoW 算出來的結果，所以要藉由操控區塊內容來影響 Block Hash 並非易事，而且是有機會成本的（礦工算出 PoW 結果，但填入區塊後發現得出的 Block Hash 不滿意，此時如果它放棄並重算 PoW 就代表它放棄了這次的區塊獎賞機會）。因此，有些合約會利用 BLOCKHASH opcode 的值來當作亂數來源。

但在 PoS 後已經不用算 PoW，所以驗證者（PoS 的礦工）要操縱區塊內容（即操縱 Block Hash）可說是易如反掌。不過如果合約還是需要亂數來源，可以用上一段提到的 PREVRANDAO opcode，雖然還是有被操縱的風險，這個亂數來源會比 PoW 更隨機、更難操縱。

因為這個隨機值是一個經過每一個 slot 不斷融入不同驗證者所提供的亂數而被不斷更新、累加的亂數，所以一個驗證者能影響隨機值的範圍很有限。最多能做的就是在他該 propose 區塊的 slot 選擇不做事，讓隨機值到下一個 slot 保持一樣（如果這麼做對他有利的話）。或是攻擊者很有錢運氣也很好，剛好連續好幾個 slot 都是由他掌控的驗證者來 propose 區塊。

詳細關於 PREVRANDAO opcode 的安全性分析可以參考 EIP 4399 的安全性分析章節。

Finality

這是 PoS 帶來最大的影響之一，我們有了比 Block Confirmation 更可靠的 Finality 參考：如果網路運作正常且沒有攻擊者，則約 2 個 epoch（約 12 分鐘左右）區塊會被 Finalized，被 Finalized 就代表這個區塊可視為不會被推翻，除非攻擊者願意犧牲大量的押金來試圖推翻這個區塊。

Fork Choice Rule 及 Safe Head

12 分鐘的 Finality 時間對某些應用來說可能還是有點久，有沒有其他折衷方法？有的，新的區塊還是會被不斷產出，並在 12 分鐘後被 Finalized，在這期間區塊還是有可能因為網路問題而分叉，因此節點還是要有一套 Fork Choice Rule 來在這期間找出最長鏈。

當然，這些還未 Finalize 的區塊對應用來說，其實就和 PoW 一樣，要透過 Block Confirmation 機制來做機率上的確保。不過相比於 PoW，PoS 能更細緻的去計算這個機率，因為 PoS 的每個區塊所紀錄的是驗證者們的 Attestation，區塊裡收錄的 Attestation 的數量可以讓驗證者有一個相比於「收錄或不收錄這個區塊」更細緻的參考：「這個區塊只有 1/6 的驗證者的 Attestation，抖抖的，被分叉淘汰的機率頗高」、「這個區塊有 3/4 的驗證者的 Attestation，穩了，要出現 2/3 驗證者冒險分叉出去的機率很低」。

因此，這個新的 Fork Choice Rule 也會引入一個新的時間標籤 safe 。原本開發者熟悉的是默認的 latest 時間標籤：請節點給你最新收到的區塊裡的資訊。而 safe 標籤就是請節點給你它經過 Fork Choice Rule 計算後，覺得夠穩妥的區塊的資訊。在正常情況下，safe 標籤的區塊會落後 latest 標籤的區塊大約四個區塊的時間。所以在 The Merge 之後，開發者要注意 web3 套件預設會是使用 latest 還是 safe ，以及你的應用想要使用的標籤。

更多關於 safe 計算方式的細節可以參考這個投影片：