要點提煉
永久性分片鏈（persistent shard chain）的概念將不復存在，相反，每個分片區塊都直接就是一個交聯（crosslink）。提議人發出提案，交聯（crosslink）委員會負責批准，一錘定音。分片數量從之前的 1024 減少到 64，分片區塊大小從（目標值 16，上限值 64）kB增加到（目標值 128，上限值 512）kB。分片總容量為 1.3-2.7 MB/s，具體值取決於時隙（slot time）。如果需要的話，分片數量和區塊大小可隨時間的推移而增加，比方說 10 年後最終達到 1024 個分片，以及 1 MB 區塊。在 L1 和 L2 層實施了諸多簡化方案：（i）所需的分片鏈邏輯更少，（ii）因為 「原生的」 跨分片通信可以在 1 個時隙內完成，所以無需通過 Layer-2 為跨分片通信加速，（iii）無需通過去中心化交易所來促進跨分片交易費手續的支付，（iv）執行環境能夠進一步簡化，（v）無需再混合序列化和哈希；主要劣勢：（i）信標鏈的開銷更大，（ii）分片區塊產生時間更長，（iii）對 「突增性」 帶寬需求更高，但對 「平均」 帶寬的需求更低。
序言/理念
當前的以太坊 2.0 架構過於複雜，尤其是在手續費市場層面，有些人就想到要用 Layer-2 的應變方法來解決 Eth2 基礎層的主要問題：雖然分片內的區塊時間是非常短的（3-6s），然而分片間的基礎層通信時間特別長，需要 1-16 個 epoch（如果超過 1/3 的驗證者離線，則要花費更長時間）。這就亟待 「樂觀」 的解決方案：一個分片內的子系統通過某種次等安全的機制（如輕客戶端），「假裝」 提前知道其它分片的狀態根，並使用這些不確定的狀態根來處理交易，以此來計算自己的狀態。一段時間後，一個 「rear-guard」 進程遍歷所有分片、檢查哪些計算使用了其他分片狀態的 「正確」 信息，並拋棄未使用 「正確」 信息的所有計算。但這個過程是存在問題的，雖然它在很多情況下都能夠有效地模擬出超高速通信時間，但是 「樂觀」 ETH 和 「真實」 ETH 之間的區別衍生出了其他複雜情況。具體而言，我們不能假設區塊提議者 「知道」 樂觀的 ETH（譯者註：即完全知曉樂觀 ETH 的確定狀態），因此，如果分片 A 上的用戶向分片 B 上的用戶發送 ETH，則分片 B 上的用戶要隔一段時間才能收到協議層 ETH（也是唯一能用於支付交易手續費的 ETH）。如果想避免延遲，要麼需要去中心化交易所（存在複雜性和低效率問題），要麼需要中繼市場（又使人擔心壟斷中繼者可能會審查用戶的交易）。
此外，目前的交聯（crosslink）機制大大增加了複雜性，實際上它需要一整套區塊鏈邏輯，包括獎懲計算、單獨存儲分片內獎勵的狀態以及分叉選擇規則等，這些都需要被納入分片鏈中作為階段1的組成部分。本文檔提出了一個大膽的替代方案，用以解決所有這些問題，使以太坊 2.0 能夠更快地投入使用，同時降低風險，其中還有一些折中方案。
方案細節
我們把 SHARD_COUNT （分片數量）從 1024 減少到 64，並將每個時隙處理的分片數上限從 16 增加到 64。這意味著現在的 「最優」 工作流是：在每一次信標鏈生成區塊的期間，每個分片都會產生一個交聯（為了清楚起見，我們不再使用 「交聯」（crosslink）一詞，因為並沒有 「連接」 到分片鏈，直接使用 「分片區塊」 更合適）。
請注意一個關鍵細節：現在任何分片位於時隙 N+1 處的區塊都可以通過一條路徑知道所有分片的在時隙 N 處的區塊。因此，我們現在有了一流的單時隙跨分片通信（通過 Merkle 收據）。
-現狀（近似）-
-新提案-
在這個提議中我們改變了見證消息（attestation）所連接對象的結構：在原先的方案中，見證消息中包含著 「交聯」（crosslink），交聯中包含著以某種複雜序列化形式表示的許多分片區塊的 「數據根」；但在新提案中，見證消息只包含著一個數據根，該數據根代表著一個區塊內的內容（內容完全由「提議者」決定）。分片區塊還將包括來自提議者的籤名。為了促進 p2p 網絡的穩定性，計算提議者的方式依然使用之前基於常設委員會的算法（persistent-committee-based algorithm）。如果沒有可用提案，交聯委員會成員也可以就 「零提案」 進行投票。
我們依然在狀態中存儲一個映射 latest_shard_blocks: shard -> (block_hash, slot) ，不同的是參數由 epoch 變為時隙。在理想狀況下，我們希望每個時隙這個映射都能夠得到更新。
將 online_validators 定義為活躍驗證者的子集，活躍驗證者即在過去 8 個時段（epoch）中至少有一個 epoch 包含其見證消息。只有 2/3 的 online_validators （以總餘額計算比例）都對給定分片的同一個新區塊達成共識，上述映射才會進行更新。
假設當前時隙是 n ，但對於給定分片 i，latest_shard_blocks.slot < n-1（即在前一個時隙中該分片有一個區塊被跳過），我們則需要對該分片的見證消息來提供範圍 [latest_shard_blocks.slot + 1….min(latest_shard_blocks.slot + 8, n-1)] 內所有時隙的數據根。
分片區塊仍需指向 「先前的分片區塊」，我們還是要強制保證一致性，因此該協議就要求多時隙的見證消息來保證一致性。委員會採用以下「分叉選擇規則」：
對於每個有效且可用的分片區塊 B（該區塊的祖先區塊也必須有效且可用），計算其最新消息支持 B 或 B 的後代的驗證者總權重，暫且將該權重稱為分片區塊 B 的 「得分」。即使是空白的分片區塊也可以有得分。在 latest_shard_blocks[i].slot + 1 處根據最高得分選出相應區塊在 latest_shard_blocks[i].slot + k （k > 1）處選擇區塊時，也根據最高得分來選，但僅考慮其父塊已在 latest_shard_blocks[i].slot + (k-1) 處被選擇的區塊
概述
從信標區塊 N 到信標區塊 N+1 的發布過程如下：信標區塊 N 發布；對於任何給定的分片 i，分片 i 的提議者提議一個分片區塊。該區塊的執行過程可知信標區塊 N 和先前區塊的根（如果有需要，我們可以將可見性降到區塊 N-1 和舊區塊，這使得我們可以對信標區塊和分片區塊同時進行提議）；被分配到分片 i 的見證者提交見證消息，包括其對時隙 N 處的信標區塊和分片 i 區塊的意見（在特殊情況中也包括分片 i 中先前的分片區塊）；信標區塊 N+1 發布，其中包括對所有分片的見證消息。區塊 N+1 的狀態轉換函數對這些見證消息進行處理，並且更新所有分片的 「最新狀態」。
成本分析
請注意，參與者不需要隨時主動下載分片區塊數據。相反地，提議者發布提議時，只需要在 3 秒內上傳上限為 512 kB 的數據（假設有 400 萬個驗證者，每個提議者平均 12.8 萬個時隙才需要上傳一次），隨後委員會驗證提議時，只需要在 3 秒內下載上限為 512 kB 的數據（要求是每個驗證者要在每個 epoch 中下載一次數據，因為我們保留了一個屬性：在任意給定時段中， 每個驗證者都會在特定時隙中被分配到一個特定的交聯）。請注意，此操作的要求低於目前每個驗證者的長期負載要求，即每個 epoch 約 2MB。然而，這對 「突增性」 負載的要求更高：之前是 3 秒內上限 64KB，現在 3 秒內上限會提高到 512KB。
見證消息（attestations）負載的信標鏈數據更改如下。
每條見證消息有 224 字節的基本開銷（其中 128 字節是 AttestationData，96 字節是籤名數據），再加上見證者欄位（attester bitfield）需要少則 32 字節（正常情況），多則 256 字節（最糟糕的情況）的數據。也就是說，一條見證消息需要 256-280 字節的開銷。一個區塊最多可以有 256 條見證消息，平均則是約 128 條（猜測），所以單個區塊的消息開銷在平均條件下是 32768 字節（約 0.03 MB），最糟糕的情況下是 122880 字節（約 0.1 MB）。每個分片狀態更新消息需要：（i）區塊體 chunk 數據根，每 128 kB 的區塊數據（或其一部分）就需要一個數據根，所以平均需要 48 字節，最大需要 128 字節；（ii）分片狀態根，128 字節；（iii）區塊體長度，8 字節；（iv）custody bits，少則 32 字節，多則 256 字節。因此，平均來看需要 216 字節，最大需要 520 字節。單個區塊最多可以有 256 條分片狀態更新消息，平均是 64 條。因此平均需要 13824 字節（約 0.01 MB），最大需要 133120 字節（約 0.1 MB）。每個證明有大約300位元組的固定數據，加上一個位欄位，即每個epoch 400萬bit，每個時隙8192位元組。因此，目前方案的最大負載為128 * 300 + 8192 = 46592，平均情況中的負載可能更接近32 * 300 + 8192 = 17792，即使這樣還可以通過壓縮證明中的冗餘信息來降低負載。
出於效率考量，在一個區塊中我們僅包含勝出見證消息（winning attestation）中的分片狀態更新數據；對所有其它見證消息中的分片狀態更新數據都僅保存其哈希值作為替代。這樣就可以大幅節省數據開銷。
還要注意的是，見證聚合在每個分片中每個時隙的成本為 65536 * 300 / 64 = 307200 字節。這對運行節點提出了一個天然的系統需求門檻，因此要再壓縮區塊數據的話也沒有什麼意義。
從計算層面來說，唯一大幅增加的花銷是需要更多的配對（更確切地說，是更多的 Miller循環），每個區塊的上限從 128 增加到 192，而這將使得區塊處理時間延長 200ms。
「基礎作業系統」 分片
每個分片都有一個狀態，就是一個 ExecEnvID -> (state_hash, balance) 的映射。一個分片區塊被分成一組 chunk，每個 chunk 指定一個執行環境。一個 chunk 的執行依靠狀態根和 chunk 的內容（即分片區塊數據的一部分）作為輸入，並輸出 [shard, EE_id, value, msg_hash] 元組的一個列表，每個分片最多擁有一個 EE_id（ 我們添加兩個 「虛擬」 分片：向分片 -1 的轉帳表示驗證者在向信標鏈存儲保證金，而向分片 -2 的轉帳是向提議支付手續費）。我們也會從該 EE 的餘額中減去 value 的總數。在分片區塊頭裡，我們放置了一個 「收據根（receipt root）」，裡面包含了一個映射： shard-> [[EE_id, value, msg_hash]…] （每個分片最多8 個 元素；在一個大多數大多數跨分片 EE 轉帳都是發往同一個 EE 的的轉帳中，甚至只需要更少元素）。
在分片 i 上的一個分片區塊，應有一個默克爾分支，包含所有其它分片的收據，而這棵默克爾分支就是由其它分片的收據根生成的（因此任意分片 i 都可以知道其它任意分片 j 的收據根）。收到的價值會被分配到其 EE，且 EE 可以訪問 msg_has 。
這就使得不同的分片可以在 EE 間實現即時的 ETH 轉移，此時每個區塊的開銷為 (32 * log(64) + 48) * 64 = 15360 字節。msg_hash 可以被用於減少伴隨 ETH 轉移所傳遞的跨分片信息見證內容的大小，因此在一個高度活躍的系統裡，15360 字節數據是必不可少的。
主要益處：更簡單的費用市場
我們可以接著修改執行環境（EE）系統：每個分片都有一個狀態，該狀態包含狀態根和執行環境的餘額。執行環境將能夠發送收據，向其它分片的同一 EE 直接發送貨幣。這個過程將使用默克爾分支處理機制來完成，每個分片的 EE 狀態儲存著一個其餘每個分片的 nonce，用以抵禦重放（replay）攻擊。EE 也可以用來直接向區塊提交者支付費用。這提供了足夠強大的功能性，使得 EE 能夠建立在這樣的基礎之上：允許用戶在分片上存幣，並將其用於支付交易手續費；在分片間轉移幣就如在同一分片內進行操作一樣簡便，從而消除了對中繼市場需求的緊迫性，也不需要讓 EE 來承擔實現 optimistic 跨分片狀態的負擔。
完全的和壓縮後的見證消息
出於對效率問題的考量，我們還進行了以下的優化。如前所述，指向時隙 n 的見證消息可完整地包含在時隙 n+1 中。但是，如果此種見證消息需要被包含在後續的時隙中，則必須以 「精簡形式」 進行嵌套，僅包含信標區塊（頭部、target、source），而不包含任何交聯數據。這不僅起到了裁減數據的效用，更重要的是，通過強制 「舊見證消息」 保存相同數據，可以減少用於驗證見證消息所需的配對數：在大多數情況下，所有來自相同時隙的舊見證消息都可以經由單一配對驗證。如果鏈不分叉，那麼在最壞的情況下，用以驗證舊見證消息所需的配對數會被限制在 epoch 長度的 2 倍。如果鏈確實分叉，則要包含所有見證消息的能力就得依賴於一個更高的誠實提議者比例（譬如 1/32，而非 1/64），並且要將更早的證明也包含進去。
保證輕客戶端的參與
每天，我們隨機選擇一個由大約 256 個驗證者組成的委員會，這個委員會可以在每個區塊上進行籤名，其中簽名被包含的驗證者便可以在區塊 n+1 中獲得獎勵。這樣做的目的是允許計算能力不高的輕客戶端參與。題外話：數據可用性根
證明一個 128 kB 數據的可用性的操作是多餘的，幾乎沒有價值。與此相反，有意義的是：要求一個區塊能夠提供該區塊接受並組合在一起的所有分片區塊數據的串聯根（也許這個分片區塊數據根以列表形式存在，其中每個根代表 64 kB 數據，這樣使得串聯更容易）。 然後可以根據此數據創建單個數據可用性根（平均 8 MB，最壞情況下達到 32 MB）。 請注意，創建這些根可能要花費比一個時隙更長的時間，因此，最好用於檢查一個 epoch 前的數據的可用性（即，從這些數據可用性根中進行採樣將是額外的「確定性檢查」）。其他可能方案
時隙 n 的分片區塊必須引用時隙 n-1的信標鏈區塊，而不是時隙 n 處的信標鏈區塊。此種措施將允許以時隙為單位的循環並行發生，而不是串聯發生，從而減少時隙時間，這樣做的代價是導致跨分片通信時間從 1 個時隙上升到 2 個時隙。如果一個區塊提議者試圖將區塊大小擴大到 64KB 以上（備註：目標128kB），他需要首先生成 64kB 的數據，然後讓交聯委員會對其進行籤名，接著，他們可以添加一個引用第一個籤名的 64kB 數據，以此類推。這將鼓勵區塊創建者每隔幾秒提交他們區塊的部分完成版本，從而創建一種預先確認的機制。加快秘密領導人選舉的發展（簡單起見，即使一個約 8 到 16 人的匿名集環籤名版本也能有所作用）。與其使用 「強制嵌入」 機制，我們不如尋求一個更簡單的替代方案：每個分片為其餘的每個分片維護一個 「inbound nonce」 和一個 「outbound nonce」（即 8 * 64 * 2 = 1024 字節的狀態），一個分片製造的收據將需要手動進行添加，並由接收的分片按順序進行處理。收據生成將受限於每個區塊每個目標分片的少數收據，以確保一個分片能夠處理所有傳入的收據，即使是所有分片同時向它分送收據。本文由 ECN 以太坊中國社區翻譯，EthFans 經授權使用譯本。再出版時，根據原文的改動更新了譯本。