解讀以太坊POS工作原理：Epoch、Slot 與信標區塊

來源：《 Epochs, Slots and Beacon Blocks 》by Patrick McCorry

翻譯：John, ECN

審閱：Franci, ECN

使用權益證明的以太坊的獨特性在於參與者數量的最大化設計。它允許成百上千和成千上萬的驗證者活躍地參與決策過程。在筆者撰文時已經有大約50 萬的驗證者實體（從協議的角度而言）在活躍地參與這個過程。

事實上，在約384 秒（6 分24 秒）內，所有活躍中的驗證者將有機會投下一票或提議一個區塊。在約384 秒內至少有50 萬條信息廣播，而且所有信息必須在嚴格的時間範圍內傳遞。據我所知，沒有其他共識協議被設計來處理如此活躍和龐大的共識參與者集。

至於通信模型方面，共識協議是為以下三種情況之一設計的（通常）：

• 同步通信一個普遍同意和已知的信息傳遞超時時間。
• 異步通信信息傳遞所需時間沒有上限， 但它最終會被發送。
• 部分同步通信在大多數情況下，都有一個已知的超時時間，但零星的事件可能會破壞信息傳遞，時間長短不一。

大多數現代共識協議都是為部分同步通信而設計的，因為它假設大部分時間條件良好，但由於事件可能會在短時間內中斷通信，所以存在不可預測的時期。另一方面，值得注意的是，權益證明的以太坊是為同步通信設計的。

題外話--Casper FFG 是為部分同步通信而設計的，但LMD-GHOST 的嚴格計時條件迫使整個系統必須同步。我們將在今後的文章中解釋什麼是Casper 和LMD-GHOST。

它假定在絕大多數的驗證者中幾乎沒有中斷，而且所有的信息必須在固定的最後期限前被記錄在信標區塊鏈上，這些信息才能被計入/使用。如果出現中斷，導致信息延遲傳遞，那麼發送者將根據其延遲程度而招致懲罰。在最壞的情況下，如果錯過了最後期限，那麼消息將被忽略，信息發送者將受到不活躍的最大懲罰。懲罰政策將在未來的文章中介紹。

為了更好地理解同步通信模型，我們涵蓋了Epochs & Slots 的主題。它定義了驗證者被允許參與的時間，以及圍繞消息傳遞的嚴格時間窗口。如果違反了時間窗口，不管是什麼原因，那麼就不能保證其他驗證者會就遲到的消息到達時採取行動。最後，我們將介紹驗證者如何被分配到一個時間槽（time slot），以及消息如何被記錄在信標區塊鏈中。

如果你想深入了解各種通信設置，那麼我建議閱讀這篇文章。這裡也有關於ETH2 是部分同步通信還是同步通信的精彩討論。

Epoch 和Slot

每個epoch 有32 個slot，每個驗證者在每個epoch 正好被分配到一個槽位。一個slot 是一個12 秒的時間窗口，期間驗證者可以參與權益證明協議，對新的信標區塊進行提議或投票。

slot 按epoch 分組，epoch 和slot 為驗證者參與權益證明協議扮演一個時間表的角色：

• Epoch一個包括32 個slot 的周期。
• Slot一個驗證者委員會在為期12 秒的時間裡完成任務的窗口期。

一個epoch 代表了權益證明協議的一個完整的回合， slot 為驗證者提供了一個參與該回合的機會。在一個epoch 結束時，所有活躍的驗證者都有機會參與。

Slot 委員會一個驗證者在一個epoch 中正好被分配到一個slot，所有驗證者被平均分配到各個slot，組成委員會。

一個slot 裡有兩種角色：

• 區塊提議者（Block proposer） 一個驗證者有機會向委員會成員提議一個區塊。
• 見證者（Attester） 所有剩餘的委員會成員會為一個區塊投票，他們相信那個區塊應該會成為新的區塊鏈頭。

每個epoch 有32 個區塊提議者（每個slot 一個），所有驗證者都有機會參與權益證明協議，向他們認為應該是規範信標鏈（canonical beacon chain）的鏈頭投出一票。

一個slot 代表了一個嚴格的時間窗口，供一個驗證者提議一個區塊，委員會成員對一個區塊進行投票，最後將所有該slot 的活動廣播給下一個slot 的區塊提議者。

Slot 和時間條件所有slot 都是按照時間順序一個接一個地產生的。每一個slot 都準確地按照12 秒一個被分配出來，並被分成三個階段：

• 提議區塊指定一個驗證者提議一個區塊，並在前4 秒內將其廣播給所有委員會成員。
• 投票週期所有其他委員會的成員都為一個區塊投票（見證），他們相信，接下來的四秒內他們的投票就要被這個區塊接受。
• 廣播投票在最後的四秒裡所有委員會成員的投票應該被聚合起來並發送給下個slot 的區塊提議者。

所有的區塊和投票都是在一個slot 的委員會內進行廣播。在委員會中有一個額外的角色，叫做聚合者，他們會在將證明傳遞給下一個slot 的區塊提議者之前將其聚合。他們是自選的，這是一個自願的角色，以減少通信的成本。我們將暫時跳過具體細節--因為這將在未來的文章中涉及。

如果一個提議的區塊或見證是在截止日期之後發布的，那麼就不能保證該活動會被其他驗證者認可。例如，一個遲到的區塊可能會被跳過，因為這個slot 的見證者可能已經為其父塊投了票。一個遲到的見證將被其他見證者在一個epoch 中處理，最多遲到32 個slot，並有不同程度的懲罰。如果它在32 個slot 之後被發布，那麼它將不會被任何驗證者處理。

最後提醒一下，這個嚴格的時間窗口保證了運行驗證者所需的帶寬和計算能力的下限，因為他們必須要有準時接收、處理、發送見證/區塊的能力。

驗證者委員會的分配

我們在一個epoch 裡考慮分配驗證者到slot 裡的過程。所有的slot 委員會的規模大致相同。他們根據一個隨機信標的輸出完成分配，並且提前兩個epoch 進行。這要求使用一個混洗協議和一個同帶信號傳輸隨機性的源。

混洗協議所有驗證者都根據一個叫swap-or-not 的混洗協議被分配到一個slot 裡去。我們不會去探討這個混洗協議的細節，而是會把注意力集中到隨機信標的計算方法上，這個方法奠定了混洗協議執行方式的基礎。

隨機信標所有驗證者通過一個隨機信標被分配，這個隨機信標使用了一個叫RANDAO 的協議。其目的是在新的區塊被添加到規範鏈上時通過聚合隨機性來形成隨機信標。

對於每一個新的區塊而言，有兩個階段：

• 提議產生的隨機性（每個區塊）一個新的信標區塊包括了一個叫randao_reveal 的特殊值。它是一個區塊提議者的BLS 簽名，用以充當區塊的隨機信標。它是確定的以防止被驗證者篡改，但是不可預測。
• 混合隨機性（每個區塊）所有驗證者從新的區塊裡取出隨機信標並把它和之前所有聚合起來的區塊的隨機性混合。它形成了一個新值mix，有可能作為混洗協議的候選。

正如我們所能看到的，每一個信標區塊都包括了一個隨機信標，添加並彙聚了所有之前的區塊的隨機性。

驗證者們通過第N 個Epoch 最後的隨機信標被分配到第N+2 個Epoch 的slot 裡

/* * 區塊提議者在當前epoch 號碼上進行一次BLS 簽名* 以充當這個區塊的隨機信標* 一個非常好的地方在於簽名是確定的（驗證者無法篡改它），但是直到簽名被計算出來之前都是無法預測的*/

DOMAIN_RANDAO = 0x02000000; // 一個簽名里包含的神奇數字epoch_hash = hash(current_epoch_number, DOMAIN_RANDAO); // 要簽署的哈希碼randao_reveal = BLS.sign(epoch_hash, sk); // BLS 簽名是RANDAO

/* * 使用區塊的隨機性，進行哈希計算，然後把哈希碼混合到現在聚集起來的隨機性裡*/

previous_mix = get_previous_mix(parent_block); // 來自父塊的混合（Mix）randao_reveal = new_block.randao_reveal; // 取得新區塊的randao

mix = previous_mix XOR hash(randao_reveal); // 計算新的混合store_new_mix(new_block); // 把新的“混合”（mix）和新的區塊聯繫在一起

分配會提前2 個epoch發生所有驗證者都會使用最後那個被接受的區塊匯聚起來的mix 值作為隨機信標，並在混洗算法中使用它。它會計算得出未來兩個epoch 的驗證者委員會。

所以，如果我們考慮目前的epoch 為第N 個，那麼這個epoch 裡的最後那個信標區塊會作為隨機信標決定第N+2 個epoch 的委員會分配。

驗證者們有充足的時間查找它們被分配到的slot，因為它們提前兩個epoch 就知道了。換句話說，未來64 個slot 的驗證者的分配是早就公之於眾了的(約2 個epoch）。

隨機信標的可偏倚性（bias-ability)只有一個mix 能被混洗協議使用，那就是一個epoch 中最後一個被接受的區塊的mix 值。

最後一個被接受的區塊不會總是那個在第32 個slot 被提議的區塊。而是最後一個slot 的區塊，也就是被所有驗證者認可為區塊鍊鍊頭的那個區塊。舉個例子，如果第32 個slot 沒有區塊被提議產生（或者它遲到了），那麼第32 個slot 的驗證者委員會就會為之前在第31 個slot 被提議產生的前一個區塊投票。

攻擊者可以利用這點來使隨機信標出現偏差。讓我們假設攻擊者是第32 個slot 的區塊提議者。他可以決定這麼幹：

• 準時釋放區塊攻擊者的隨機性被混合在信標裡
• 暫緩區塊強迫所有驗證者為上一個區塊投票，則攻擊者的隨機性不會被混合在信標裡。

這種決定權使得攻擊者可以使隨機信標出現1 個字節的偏倚，並最終決定到底兩個驗證者分配組合里中的哪一個會在未來的一個epoch 裡被使用。實際上如果攻擊者控制了一個epoch 裡最後N 個區塊的區塊提議者們，那麼它們可以利用這個機會釋放或暫緩釋放一個N 個區塊的組合。目前還缺乏一項嚴格的研究，來了解針對最後N 個slot 的偏倚能力的全部範圍及其影響。

檢查一個信標區塊

一個信標區塊的數據結構

一個單獨的信標區塊包含了它在信標區塊鏈裡所處位置的元數據、執行鏈的數據、以及權益證明協議的一份副本。我們會在下文探討更多細節。

一個slot 的區塊提議者會嘗試擴展規範鏈，並且只能選擇一個父塊。

信標父塊一個區塊的提議者的目標是提議並添加一個新的信標區塊到一個規範鏈的頭。若要這麼做的話，它們只能選擇一個父塊來進行擴展。父塊應該是當前的鏈頭，它在元數據中的代表是parent_root。

 Epoch 和slot 組織驗證者產生唯一一條規範信標區塊鏈。

Slot ≠ 信標區塊一個信標區塊記錄了它的slot 號碼的元數據（一個epoch 號碼的倍數）。它允許其他驗證者檢查區塊提議者是否確實被指定為這個slot 提議一個區塊，這個區塊是否就是被提議的那個區塊。如果slot 的號碼錯誤，那麼區塊會被拒絕。

重點在於，一個區塊在區塊鏈裡的位置不會與它在其中被提議的slot 號碼相對應。舉個例子，如果我們檢查第5184157 個slot，那麼我們會看到第16015362 個區塊，這種不匹配是無法避免的，因為無法保證一個被分配的slot 裡被提議的區塊會被所有其他驗證者投票通過，而且以太坊從開始到現在運行了超過7 年了。

執行鏈數據區塊提議者會提議兩個區塊，它們提議一個執行區塊，給用戶的交易排序，並把它附加到新產生的信標區塊上。這並不奇怪，因為共識層的最終目的就在於為執行層決定規範鏈。

區塊提議者同樣負責從執行層轉移信息到信標層上，並使其準備好為權益證明協議所用。這包括：

• ETH1 數據一個來自執行層的附加區塊的區塊哈希碼。
• 存款存款合約地址和一連串未記錄的存款。

這要求所有的驗證者運行一個信標客戶端和一個執行客戶端。這是必要的，因為驗證者們必須檢查對應的ETH1 區塊並根據執行層規則驗證其有效性。同樣地，正如我們在關於註冊過程的文章裡討論的一樣，存款必須在一個特定的區塊間隔期內從執行層上被轉移到一個信標區塊上，否則信標區塊會被拒絕。

• 元數據slot 號碼、epoch 號碼、隨機信標和區塊提議者
• 罰沒事件包括其他驗證者的惡意行為證據，這些證據可用於懲罰它們
• 投票歷史記錄一連串在這個區塊鏈分叉上針對之前提議的信標區塊的未被記錄的的投票
• 區塊鏈分叉它挑選了一個父塊，並反過來定義了這個區塊所延伸的規範鏈。
• 驗證者退出一連串已註冊驗證者的退出請求。

通過記錄下副本，每一個人都可以獨立地回顧整個協議，並且絕對相信目前信標鏈的狀態是正確的。比如說，惡意的驗證者會被及時罰沒，slot 和epoch 的時間表受到全體驗證者的認可，絕大多數驗證者都會以這種方式投票並產生單獨一條規範鏈。

題外話，由於弱主觀性的緣故，雖然權益證明的記錄可以使我們信服所有歷史活動都是按照規則進行的，但是尚不足以向一個外部群體說明這確實是那條真實的信標區塊鏈。簡單來說就是它提供了一個檢查歷史活動完整性的方法。

原文鏈接：https://stonecoldpat.substack.com/p/epochs-slots-and-beacon-blocks