原文標題：《Sticking to 8192 signatures per slot post-SSF: how and why》

原文作者：Vitalik Buterin，ETH research

原文編譯：Luccy，BlockBeats< /blockquote>

編按：

SSF（Single Slot Finality）即單槽確定性，它提供了一種方法來顯著減少以太坊的延遲。在區塊鏈共識機制領域，最終性意味著交易或區塊變得不可撤銷，確保其不能被篡改或逆轉。實現最終確定性對於去中心化系統的信任和安全至關重要，因為它消除了雙重支出和其他惡意活動的風險。

SSF 建議在區塊鏈共識機制中，單一時隙或時間單位可以被視為「最終確定」。它與最初的以太坊共識不同，可以讓所有驗證者參與認可或簽署插槽，能夠減少交易確認時間並改善整體用戶體驗。

Vitalik「回歸」ETH research 探討了為什麼需要在SSF 後讓參與的驗證者每個槽位有兩個簽名，即達到8192 個簽名數，同時對如何實現這一目標提出3 種假設，即全面質押、兩層質押和輪換參與，分析了在保持協議安全性的前提下，如何更有效地處理每個槽位的簽名數量，並討論了它們的優劣勢以及對協議和用戶的影響。 BlockBeats 將原文編譯如下：

以太坊與大多數其他（帶有終局性的）權益證明系統的一個主要區別在於，以太坊力圖支持極大數量的驗證者：目前我們擁有895,000 個驗證者，Zipf 定律的分析表明，這相當於數以萬計的獨立的個體或實體。這樣做的目的是為了支持去中心化，使普通人能夠參與質押，而不需要每個人都放棄自己的行動能力並把控制權交給少數幾個質押池之一。

然而，這種方法要求以太坊鏈在每個插槽處理大量的簽章（今天約為28,000 個；SSF 後為1,790,000 個），這是一種非常高的負載。為了支援這種負載，必須做出許多技術上的犧牲：

· 它需要一個複雜的證明傳播機制，其中證明被分割到多個子網之間，需要超級優化BLS 簽章操作來驗證這些簽章等等。

· 我們目前沒有明確的、能夠高效應對的量子抗性替代方案。

· 像視圖合併這樣的分叉選擇修復變得更加複雜，因為無法提取單一簽名。

· 對這麼多簽章進行 SNARK 處理很困難。 Helios 需要在一個專門的額外簽名上運行，稱為同步委員會簽名。

· 它要求一個槽內有三個子槽而不是兩個，從而增加了安全最小槽時間。

簽章聚合系統乍看之下似乎合理，但實際上它產生了遍布整個系統的系統性複雜性。

此外，它甚至沒有實現其目標。質押的最低要求仍然是 32 ETH，這對許多人來說是不可及的。僅從邏輯分析的角度來看，長期內讓每個人在每個插槽都簽名的系統，真正為普通人提供質押的目標似乎是不可行的：如果以太坊有5 億用戶，其中10% 參與質押，那意味著每個槽位有1 億個簽名。從資訊理論的角度來看，在這個設計中處理懲罰至少需要每個插槽 12.5 MB 的資料可用空間，大致相當於全面分片的目標。也許是可行的，但要求質押本身依賴數據可用性抽樣是一個很大的複雜性增益。而且即便如此，參與質押的僅是全球人口中的 約 0.6%，而且還沒有開始涉及驗證這麼多簽章的計算問題。

因此，與其依賴密碼學家創造魔法子彈（或魔法防彈）來實現每個槽位中籤名數量不斷增加，我建議我們進行一次哲學性的轉變：首先放棄對此類期望。這將大大擴展權益證明設計空間，並允許大量技術簡化，透過允許Helios 直接在以太坊共識上進行SNARK，使其更加安全，並透過使即使是像Winternitz 這樣無趣但長期存在的簽名方案也變得可行來解決量子抗性問題。

為什麼不「只用委員會」？

許多面臨這個確切問題的非以太坊區塊鏈採用基於委員會的安全方法。在每個插槽期間，它們隨機選擇 N 個驗證者（例如，N ≈ 1000），這些驗證者負責最終確認該插槽。值得提醒的是，為什麼這種方法不足夠，因為它沒有提供問責制。

為了了解原因，假設發生了 51% 的攻擊。這可能是終態逆轉攻擊或審查攻擊。為了進行攻擊，您仍然需要經濟參與者控制大部分股份，以在攻擊中達成一致，即運行參與攻擊的軟體，並與最終被選為委員會的所有驗證者一起參與攻擊。數學上的隨機抽樣確保了這一點。然而，他們因此而受到的懲罰微乎其微，因為大多數同意攻擊的驗證者最終並未被選為委員會成員，因此未被看到。

目前，以太坊的做法完全相反。如果發生了 51% 的攻擊，整個攻擊驗證者集合的大部分將被削減他們的押金。目前攻擊的成本約為 900 萬 ETH（約 200 億美元），並且假設網路同步中斷以最有利於攻擊者的方式進行。

我認為這是一個很高的成本，但這代價太高了，我們可以在這個問題上做出一些犧牲。即使攻擊成本為 1-2 百萬 ETH 也完全足夠。此外，目前以太坊存在的主要中心化風險體現在一個完全不同的地方：如果最低押金金額降低到接近零，大規模的質押池的力量將減弱不了多少。

這就是為什麼我提倡一個中庸的解決方案：在驗證者責任上做一些犧牲，但仍然保持很高的總可削減ETH 數量，作為交換，我們可以享受到較小驗證者集的大部分好處。

在 SSF 下，每個插槽有 8192 個簽章會是什麼情況呢？

假設採用傳統的兩輪共識協議（就像Tendermint 使用的協議，以及SSF 無可避免地會使用的協議），每個參與的驗證者每個槽位需要兩個簽名。我們需要解決這個現實，我看到有三種主要方法可以解決這個問題。

方法1：全面採用去中心化的質押池

Python 之禪包含一句很關鍵的話：

There should be one-- and preferably only one --obvious way to do it.（應該有一種－最好只有一種－明顯的方法來完成它。）

對於使質押變得平等的問題，以太坊目前違反了這個規則，因為我們同時在執行兩種不同的策略以實現這一目標：（i）小規模的獨立質押，和（ii）使用分散式驗證器技術（DVT）的去中心化質押池。基於上述原因，（i）只能支持一些個人質押者；總是會有很多人的最低押金金額太大。然而，以太坊正在支付支援（i）的非常高的技術負擔成本。

一個可能的解決方案是放棄（i），全力以赴（ii）。我們可以將最低押金金額提高到 4096 ETH，並設定總驗證者上限為 4096 個（約 1670 萬 ETH）。預期小規模質押者將加入 DVT 池：透過提供資本或成為節點業者。為防止攻擊者濫用，節點運營者角色需要以某種方式受到聲望門檻的限制，各個池將透過在這方面提供不同選項來競爭。資本提供將是無需許可的。

我們可以透過設定懲罰上限（例如，為總提供押金的 1/8）使這個模型中的質押更加「寬容」。這將允許減少對節點運營商的信任，儘管由於概述的問題，值得謹慎對待。

方法2：兩層質押

我們創造兩層質押者：一個「重「層，要求4096 ETH 參與終態確認，和一個「輕」層，沒有最低要求（也沒有押金和提現延遲，沒有削減的漏洞），增加了第二層安全性。為了使一個區塊終態確認，既需要重層終態確認，又需要輕層中至少 50% 的線上輕驗證者證明。

這種異質性對於審查和攻擊抵抗是有益的，因為為了攻擊成功，需要同時腐化重層和輕層。如果一層被腐化而另一層沒有，鏈將停止；如果是重層被腐化，可以對其進行懲罰。

這樣做的另一個好處是，輕層可以包含同時用作應用程式內抵押的 ETH。主要的缺點是透過確立小規模質押者和大規模質押者之間的分歧，使質押變得不那麼平等。

方法3：輪替參與（即委員會但有問責）

我們採取一種類似於在這裡提出的超級委員會設計的方法：對於每個槽位，我們選擇4096 個當前活躍的驗證者，並在每個槽位中仔細調整該集合，以便我們仍然具有安全性。

然而，我們在這個框架內做了一些不同的參數選擇，以在其中獲得“物有所值”。尤其是，我們允許驗證者使用任意高餘額參與，並且如果驗證者的 ETH 數量超過一定數量 M（這將必須是浮動的），則他們在每個插槽中參與委員會。如果驗證者有 N<M ETH，那麼他們在任何給定的插槽中，都有 N/M 的機率參與委員會。

在這裡我們有一個有趣的槓桿，即在激勵目的上解耦“權重”與共識目的上的“權重”：委員會中每個驗證者的獎勵應該是相同的（至少對於使用≤M ETH 的驗證者來說），以保持平均獎勵與餘額成比例，但我們仍然可以透過ETH 加權計算委員會中的共識驗證者權重。這確保打破最終性所需的 ETH 量等於委員會中總 ETH 的 1/3 倍以上。

一個粗略的Zipf 定律分析會計算出這個ETH 數量，如下：

· 在總餘額的每個二次方級別，驗證者的數量與該餘額等級成反比，而這些驗證者的總餘額將相同。

· 因此，委員會將有來自每個餘額級別的等量 ETH 參與，除了超過障礙 M 的級別，其中驗證者始終在委員會中。

註：為更清楚展示計算數據，接下來的步驟將截圖展示

這種方法的主要缺點是在協議中隨機選擇驗證者的複雜性略有增加，以便我們可以在委員會更改的情況下獲得共識安全性。

主要優點是它以一種可識別的形式保留了獨立質押，保持了一個單一類別系統，甚至允許將最低押金金額降低到非常低的水平（例如1 ETH）。

結論

如果我們確定在SSF 協議後，要堅持使用8192 個簽名，這將使技術實施者以及輕客戶端等側基礎設施的建構者的工作變得更加容易。任何人都可以更輕鬆地運行共識客戶端，用戶、質押愛好者等人可以立即根據這個假設進行工作。以太坊協議的未來負載不再是未知的：未來可以透過硬分叉進行提升，但只有當開發人員確信技術已經足夠改進，能夠在相同輕鬆的水平上處理每個槽位更多的簽名。

剩下的工作將是決定我們要採用上述三種方法中的哪一種，或者可能是完全不同的方法。這將是一個我們對哪些權衡我們感到滿意的問題，特別是我們如何處理液體質押等相關問題，這可能可以與現在變得更加容易的技術問題分開解決。

「原文連結」

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia