區塊鏈最強大的功能之一是允許任何人都可以在計算機上運行節點并驗證該鏈是否正確。即使 95% 的節點都同意更改規則并開始根據新規則生成區塊，運行全節點的每個誠實個體都有會拒絕接受該鏈。不屬于此類陰謀集團的權益持有者會自動匯聚在一起并繼續構建一條遵循舊規則的鏈，并且完全驗證的用戶將遵循該鏈。
這是區塊鏈和中心化系統之間的一個關鍵區別。然而，如果要保持這一特性，運行一個全節點需要足夠簡單，這樣才能確保大多數人有機會運行節點。這既適用于質押者（如果質押者沒有驗證鏈，他們實際上并沒有為執行協議規則做出貢獻），也適用于普通用戶。如今，在筆記本電腦上運行節點已成為可能，真正做到還是很困難。The Verge 希望改變這一點，讓鏈的完整驗證成本變得更低，以至于每個手機錢包、瀏覽器錢包，甚至智能手表都可以成為驗證節點。
TheVerge，2023年路線圖
- Verkle tree 是一種更緊湊證明的樹形結構，可實現以太坊區塊的無狀態驗證。節點可以在硬盤上不擁有任何以太坊狀態（賬戶余額、合約代碼、存儲......）的情況下驗證以太坊區塊，但需要花費幾百千字節的證明數據和幾百毫秒的額外時間來驗證證明。而如今 Verge 愿景已經變得更為宏大，Verge 希望實現以太坊鏈的最大資源效率驗證，其中不僅包括無狀態驗證技術，還包括使用 SNARK 驗證所有以太坊執行。
除了需要長期關注對整個鏈進行的 SNARK 驗證之外，還需要考慮另一個問題，即Verkle tree 是否是最好的技術。Verkle tree 容易受到量子計算機的攻擊，因此如果我們用 Verkle tree 替換當前的，我們以后將不得不再次替換樹。Merkle 樹的自然替代方案是直接使用中 Merkle 分支的。從歷史上看，由于開銷和技術復雜性，這被認為是不可行的。然而，最近我們看到 Starkware 在筆記本電腦上使用每秒等技術，從中可以感覺到，更「傳統」哈希值的證明時間也在迅速改善。
在過去的一年里，Verge 正變得更加開放，并且展現出了豐富的可能性。
The Verge：關鍵目標
無狀態客戶端：完全驗證客戶端和質押節點不需要超過幾 GB 的存儲空間
未來，能夠實現在智能手表進行鏈的驗證（共識和執行）。即只要下載一些數據，驗證 SNARK，就可以完成。
無狀態驗證：Verkle 或 STARK
我們要解決什么問題？
如今，以太坊客戶端需要存儲才能驗證區塊，而且這一數量每年都在增加。原始狀態數據，各個客戶端必須在其上存儲一些額外數據才能有效地更新 trie。
這減少了可以運行完全驗證的以太坊節點的用戶數量：盡管只要有足夠大的硬盤就可以存儲多年的所有以太坊狀態甚至歷史記錄，但人們默認購買的計算機往往只有幾百 GB 的存儲空間。狀態大小也給首次設置節點的過程帶來了很大的阻力：節點需要下載整個狀態，這可能需要數小時或數天的時間。這會產生各種連鎖反應。例如，它使質押者升級其質押設置變得更加困難。從技術上講，可以在不停機的情況下做到這一點 - 啟動一個新客戶端，等待它同步，然后關閉舊客戶端并傳輸密鑰 - 但在實踐中這一技術很復雜。
無狀態驗證是什么以及它是如何運行的？
無狀態驗證是一種允許節點在不掌握完整狀態的情況下驗證區塊的技術。相反，每個區塊都帶有一個見證，其中包括 (i)區塊將訪問的狀態中特定位置的值（例如代碼、余額、存儲），以及 (ii)這些值正確的加密證明。
實際上，實現無狀態驗證需要更改以太坊狀態樹結構。這是因為當前的 Merkle Patricia 樹對于實現任何加密證明方案都極其不友好，尤其是在最壞的情況下。對于「原始」Merkle 分支以及將 Merkle 分支「包裝」在 STARK 中的可能性都是如此。關鍵困難源于 MPT 的兩個弱點：
它是十六叉樹（即每個節點有 16 個子節點）。這意味著平均而言，大小為 N 的樹中的證明有32 * (16 - 1) * log16(N) = 120 * log2(N)字節，或者在 2 (32)項樹中大約有 3840 字節。使用二叉樹，您只需要32 * (2 - 1) * log2(N) = 32 * log2(N)字節，或者大約 1024 字節。
代碼未經過默克爾化。這意味著證明任何賬戶代碼的訪問都需要提供整個代碼，最多 24000 字節。
我們可以計算的最壞情況如下：
30,000,000 gas / 2,400 ("cold" account read cost) * (5 * 480 24,000) = 330,000,000字節
分支成本略有下降（5 * 480而不是8 * 480），因為當分支數量較多時，分支的頂部會重復。但即便如此，這也意味著在一個 slot 內下載的數據量完全不切實際。如果我們嘗試將其包裝在 STARK 中，我們會遇到兩個問題：（i）KECCAK 相對不利于 STARK，（ii）330 MB 的數據意味著我們必須證明對 KECCAK 輪函數的 500 萬次調用，這在除最強大的消費級硬件之外的所有硬件上都太多了，即使我們可以讓 STARK 證明的 KECCAK 更加高效。
如果我們只是用二叉樹替換十六叉樹，并且我們另外對代碼進行默克爾化，那么最壞的情況大約是 14 個字節（14 是 ~2 (14 個)30,000,000 / 2,400 * 32 * (32 - 14 8) = 10,400,000分支的冗余位的減法，8 是塊中葉子節點的證明長度）。請注意，這需要改變 gas 成本，以收取訪問每個單獨的代碼塊的費用；就是這樣做的。10.4 MB 要好得多，但對于許多節點來說，在一個 slot 內下載的數據仍然太多。所以我們需要引入一些更強大的技術。為此，有兩種領先的解決方案：Verkle tree和STARKed 二叉哈希樹。
Verkle trees
Verkle tree 使用基于橢圓曲線的向量承諾來做出更短的證明。關鍵在于，無論樹的寬度是多少，與每個父子關系相對應的證明部分只有 32 個字節。樹寬度的唯一限制是，如果樹太寬，證明的計算效率就會降低。以太坊提出的實現寬度為 256。
因此，證明中單個分支的大小為32 * log256(N) = 4 * log2(N)字節。因此，理論上的最大證明大小大約為30,000,000 / 2,400 * 32 * (32 - 14 8) / 8 = 1,300,000字節（由于狀態塊分布不均勻，實際計算結果略有不同，但作為初步近似值，這沒問題）。
另外需要注意的是，在上述所有示例中，這種「最壞情況」并不完全是最糟糕的情況：更糟糕的情況是攻擊者故意「挖掘」兩個地址，使樹中有一個較長的公共前綴，并從其中一個地址讀取，這可以將最壞情況分支長度再延長約 2 倍。但即使有了這個警告，Verkle tree 也能讓我們獲得約 2.6 MB 的最壞情況證明，這與當今最壞情況的 calldata 大致相當。
我們還利用這個警告來做另一件事：我們讓訪問「相鄰」存儲變得非常便宜：要么是同一合約的許多代碼塊，要么是相鄰的存儲槽。EIP提供了相鄰的定義，并且相鄰訪問僅收取 200 gas。對于相鄰訪問，最壞情況下的證明大小變為30,000,000 / 200 * 32 = 4,800,800字節，這仍然大致在容差范圍內。如果我們希望出于安全考慮降低此值，我們可以稍微增加相鄰訪問成本。
STARK 型二叉哈希樹
這里的技術非常不言自明：你創建一個二叉樹，取出證明區塊中值所需的最大 10.4 MB 證明，并用該證明的 STARK 替換該證明。這樣，證明本身就只包含要證明的數據，加上實際 STARK 的約 100-300 kB 固定開銷。
這里的主要挑戰是驗證時間。我們可以進行與上述基本相同的計算，只是我們計算哈希值而不是字節數。10.4 MB 的區塊意味著 330,000 個哈希值。如果我們加上攻擊者「挖掘」樹中具有較長公共前綴的地址的可能性，那么真正的最壞情況就是大約 660,000 個哈希值。因此，如果我們每秒可以驗證約 200,000 個哈希值，那就沒問題了。
的消費級筆記本電腦上達到 ，該函數專為 STARK 友好性而設計。然而，Poseidon 相對不成熟，因此許多人還不相信它的安全性。因此，有兩條現實的前進道路：
快速對 Poseidon 進行大量安全分析，并熟悉如何在 L1 上部署它
使用更「保守」的哈希函數，例如 SHA256 或 BLAKE
在撰寫本文時，Starkware 的圓形 STARK 證明器在證明保守哈希函數的情況下，在消費級筆記本電腦上每秒只能證明約 10-30k 個哈希值。然而，STARK 技術正在迅速改進。即使在今天，基于 GKR 的技術也有望將其提高到約 100-200k 的范圍。
除了驗證區塊之外的見證人的用例
除了驗證區塊之外，還有另外三個更高效的無狀態驗證關鍵用例：
內存池：當交易被廣播時，p2p 網絡中的節點需要在重新廣播之前驗證交易是否有效。目前，驗證涉及驗證簽名，還涉及檢查余額是否足夠以及隨機數是否正確。在未來（例如使用本機帳戶抽象，如），這可能涉及運行一些 EVM 代碼，這些代碼會進行一些狀態訪問。如果節點是無狀態的，則交易將需要附帶證明狀態對象的證明。
包含列表：這是一項，允許（可能規模較小且不太復雜的）權益證明驗證者強制下一個區塊包含交易，而不管（可能規模較大且比較復雜的）區塊構建者的意愿如何。這將降低強大參與者通過延遲交易來操縱區塊鏈的能力。但是，這要求驗證者有辦法驗證包含列表中交易的有效性。
輕客戶端：如果我們希望用戶通過錢包（例如 Metamask、Rainbow、Rabby……）訪問區塊鏈而不信任中心化參與者，他們需要運行輕客戶端（例如）。核心 Helios 模塊為用戶提供經過驗證的狀態根。但是，為了獲得完全無需信任的體驗，用戶需要為他們進行的每個 RPC 調用提供證明（例如，對于，用戶需要提供調用期間訪問的所有狀態的證明）
所有這些用例都有一個共同點，那就是它們需要相當多的證明，但每個證明都很小。因此，STARK 證明實際上對它們來說沒有意義；相反，直接使用 Merkle 分支是最現實的。Merkle 分支的另一個優點是它們是可更新的：給定一個狀態對象 X 的證明，根植于區塊 B，如果您收到一個帶有其見證的子區塊 B2，您可以更新該證明以使其根植于區塊 B2。Verkle 證明本身也是可更新的。
與現有研究有哪些聯系？
Verkle樹：
John Kuszmaul 的原始 Verkle tree 論文：
Starkware 證明數據：
Poseidon2 論文：
Ajtai（基于格硬度的替代快速哈希函數）：
Verkle.info：https://verkle.info/
還剩下什么要做？有哪些需要權衡？
剩下要做的主要工作是：
（無國籍 gas 成本變化）后果的更多分析
完成和測試過渡程序需要做更多工作，這是無國籍 EIP 復雜性的很大一部分
對 Poseidon、Ajtai 和其他「STARK 友好型」哈希函數的更多安全性分析
針對「保守」（或「傳統」）哈希函數的超高效 STARK 協議的更多開發，例如基于或的想法。
我們很快就會有一個決策點，選擇以下三個選項：（i）Verkle tree，（ii）STARK 友好哈希函數，以及（iii）保守哈希函數。它們的屬性可以粗略地總結在下表中：
除了這些「總體數字」之外，還有其他一些重要考慮因素：
如今，Verkle tree 代碼已經相當成熟。使用除 Verkle 之外的任何代碼實際上都會延遲部署，很可能是一次硬分叉。這沒關系，特別是如果我們無論如何都需要額外的時間來進行哈希函數分析或證明器實現，并且如果我們有其他重要功能希望更早地包含在以太坊中。
使用哈希更新狀態根比使用 Verkle tree 更快。這意味著基于哈希的方法可以縮短全節點的同步時間。
Verkle tree 具有有趣的見證更新屬性- Verkle tree 見證是可更新的。此屬性對于內存池、包含列表和其他用例非常有用，并且還可能有助于提高實現效率：如果狀態對象已更新，您甚至可以在不讀取最后一級的情況下更新倒數第二級的見證。
Verkle tree 更難通過 SNARK 證明。如果我們想將證明大小一直減少到幾千字節，Verkle 證明會帶來一些困難。這是因為 Verkle 證明的驗證引入了大量 256 位操作，這要求證明系統要么有大量開銷，要么本身具有自定義內部構造，其中 256 位部分用于 Verkle 證明。這對無狀態性本身來說不是問題，但會在以后帶來更多困難。
如果我們希望以量子安全且合理高效的方式實現 Verkle 見證可更新性，另一種可能的途徑是。
如果證明系統在最壞情況下效率不夠高，我們可以使用另一個「出其不意」的辦法來彌補這種不足，那就是gas：對（i）調用數據、（ii）計算、（iii）狀態訪問以及可能的其他不同資源設置單獨的 gas 限制。多維 gas 增加了復雜性，但作為交換，它更嚴格地限制了平均情況和最壞情況之間的比率。使用多維 gas ，理論上需要證明的最大分支數可能會從30,000,000 / 2400 = 12,5003000 減少到 3000。這樣的話，即使是如今的 BLAKE3 也足夠了，無需對 proof 進行進一步改進。
另一個「出乎意料」的是將狀態根計算延遲到區塊之后的slot。這將給我們整整 12 秒的時間來計算狀態根，這意味著即使在最極端的情況下，也只有 ~60,000 哈希/秒的證明時間就足夠了，這再次使我們處于 BLAKE3 的范圍內，這才勉強夠用。
這種方法的缺點是它會增加輕客戶端延遲，不過這種技術還有更巧妙的版本，可以將延遲減少到證明生成延遲。例如，只要任何節點生成證明，就可以在網絡上廣播，而不必等待下一個區塊。
它如何與路線圖的其他部分互動？
解決無狀態問題極大地提高了 SOLo 質押的便利性。如果能夠降低 solo 質押最低余額的技術（例如 Orbit SSF 或等應用層策略）可用，這將變得更有價值。
如果同時引入 EOF，多維 gas 會變得更加容易。這是因為執行在于處理不傳遞父調用的全部 gas 的子調用，而 EOF 只需使此類子調用非法即可使這個問題變得微不足道（并且本機帳戶抽象將為當前部分 gas 子調用的主要用例提供協議內替代方案）。
另一個重要的協同作用是無狀態驗證和歷史過期之間的協同作用。如今，客戶端必須存儲近 1TB 的歷史數據；這些數據比狀態大幾倍。即使客戶端是無狀態的，除非我們能夠減輕客戶端存儲歷史的責任，否則幾乎無存儲客戶端的夢想也無法實現。這方面的第一步是，它還意味著將歷史數據存儲在 torrent 或 Portal 網絡中。
EVM 執行的有效性證明
我們要解決什么問題？
以太坊區塊驗證的長期目標很明確：您應該能夠通過以下方式驗證以太坊區塊：（i）下載區塊，或者甚至僅下載區塊的一小部分（使用數據可用性采樣）；（ii）驗證小型 proof。這將是一項資源消耗極低的操作，可以在移動客戶端、瀏覽器錢包內甚至（沒有數據可用性部分）在另一條鏈中完成。
要達到這一點，需要有 (i)共識層（即權益證明）和 (ii)執行層（即 EVM）的 SNARK 或 STARK 證明。前者本身就是一個挑戰，應該在進一步改進共識層（例如，single slot 最終性）的過程中加以解決。后者需要 EVM 執行的證明。
EVM 執行有效性證明是什么以及它是如何工作的？
在以太坊規范中，EVM 被定義為狀態轉換函數：你有一些預狀態S，一個區塊B，并且你正在計算一個后狀態S' = STF(S, B)。如果用戶正在使用輕客戶端，他們沒有S和S'甚至B全部；相反，他們有一個前狀態根R，一個后狀態根R'和一個區塊哈希H。需要證明的完整陳述大致如下：
公共輸入：前狀態根R、后狀態根R'、區塊哈希H
私有輸入：區塊主體B，區塊訪問的狀態中的對象Q，執行區塊之后的相同對象Q'，狀態證明（例如 Merkle 分支）P
聲明 1：是包含以下部分狀態的P有效證明 ：QR
聲明 2：如果在 上運行 STFQ，則 (i) 執行僅訪問內部的對象Q，(ii) 該塊有效，并且 (iii) 結果是Q'
聲明 3Q'：如果你使用和中的信息重新計算新的狀態根，P你將得到R'
如果存在這種情況，您可以擁有一個完全驗證以太坊 EVM 執行情況的輕量級客戶端。這已經使客戶端的資源占用非常低。要獲得真正完全驗證以太坊客戶端，您還需要對共識端進行同樣的操作。
EVM 計算的有效性證明實現已經存在，并被 layer2 大量使用。然而，要使 EVM 有效性證明適用于 L1，還有很多工作要做。
與現有研究有哪些聯系？
EF PSE ZK-EVM（現已停用，因為有更好的選擇）：
Zeth 的工作原理是將 EVM 編譯到 RISC-0 ZK-VM 中：
ZK-EVM 形式化驗證項目：
還剩下什么要做？有哪些需要權衡？
目前，EVM 的有效性證明在兩個方面存在不足：安全性和證明時間。
安全的有效性證明涉及確保 SNARK 確實驗證了 EVM 計算，并且其中沒有錯誤。提高安全性的兩種主要技術是和。multi-provers 意味著擁有多個獨立編寫的有效性證明實現，就像有多個客戶端一樣，并且如果這些實現中足夠大的子集證明了某個塊，則客戶端會接受該塊。形式驗證涉及使用常用于證明數學定理的工具（例如）來證明有效性證明僅接受正確執行底層 EVM 規范的輸入（例如，用 python 編寫的或）。
足夠快的證明時間意味著任何以太坊區塊都可以在不到 4 秒的時間內完成證明。今天，我們距離這個目標還很遠，盡管我們比兩年前想象的要近得多。為了實現這一目標，我們需要在三個方向上取得進展：
并行化- 目前最快的 EVM 證明器可以在約 15 秒內對一個普通的以太坊區塊完成證明。它通過在數百個 GPU 之間并行化，然后在最后將它們的工作聚合在一起來實現這一點。從理論上講，我們確切地知道如何制作一個可以在 O(log(N)) 時間內證明計算的 EVM 證明器：讓一個 GPU 執行每個步驟，然后創建一個「聚合樹」：
實現這一點存在挑戰。即使在最壞的情況下，即一筆非常大的交易占據了整個區塊，計算的拆分也不能是按交易進行的；它必須是按操作碼進行的（EVM 或像 RISC-V 這樣的底層 VM）。一個關鍵的實現挑戰使得這一點并不完全簡單，那就是需要確保 VM 的「內存」在證明的不同部分之間是一致的。然而，如果我們可以做出這種遞歸證明，那么我們知道，至少證明延遲問題已經得到解決，即使沒有對任何其他軸進行任何改進。
證明系統優化、、等新的證明系統可能會再次大幅減少通用計算的證明時間。
EVM gas 成本其他變化- EVM 中的許多內容可以進行優化，以更加方便證明者，尤其是在最壞的情況下。如果攻擊者可以構建一個區塊，讓證明者的時間阻塞十分鐘，那么能夠在 4 秒內證明一個普通的以太坊區塊是不夠的。所需的 EVM 更改大致可分為兩類：
gas 成本變化- 如果一個操作需要很長時間才能證明，那么即使計算速度相對較快，其 gas 成本也應該很高。EIP是針對這方面最嚴重的違規者提出的一項 EIP：它顯著增加了（傳統）哈希函數的 gas 成本，這些哈希函數以相對便宜的操作碼和預編譯的形式公開。為了補償這些 gas 成本的增加，我們可以降低證明成本相對較低的 EVM 操作碼的 gas 成本，從而保持平均吞吐量不變。
數據結構替換- 除了用更適合 STARK 的替代方案替換狀態樹之外，我們還需要替換交易列表、收據樹和其他證明成本高昂的結構。Etan Kissling 的 EIP 將交易和收據結構移至 SSZ（）是朝這個方向邁出的一步。
除此之外，上一節中提到的兩只「帽子里變出來的兔子」（多維 gas和延遲狀態根）也可以在這里提供幫助。然而，值得注意的是，與無狀態驗證不同，使用帽子里變出來的兔子意味著我們有足夠的技術來完成我們今天需要做的事情，即使使用這些技術，完整的 ZK-EVM 驗證也會需要更多的工作（它只需要更少的工作）。
上面沒有提到的一件事是證明器硬件：使用 GPU、FPGA 和 ASIC 來更快地生成證明。Fabric、和是三家正在推動這一進程的公司。這對于 layer2 來說將非常有價值，但它不太可能成為 layer1 的決定性考慮因素，因為人們強烈希望保持 layer1 的高度去中心化，這意味著證明生成必須在相當大一部分以太坊用戶的能力范圍內，而不應受到單個公司硬件的限制。 layer2 可以做出更積極的權衡。
以下每個領域仍有許多工作要做：
并行化證明需要證明系統，其中證明的不同部分可以「共享內存」（例如查找表）。我們知道實現這一點的技術，但它們需要實現。
我們需要進行更多分析來找出理想的 gas 成本變化，以最大限度地減少最壞情況的驗證時間。
我們需要在證明系統方面做更多的工作
這里可能的權衡包括：
安全性與證明時間：可以通過選擇更積極的哈希函數、更復雜或更積極的安全假設的證明系統或其他設計選擇來縮短證明時間。
去中心化與證明時間：社區需要就其所針對的證明硬件的「規格」達成一致。要求證明者是大型實體可以嗎？我們是否希望高端消費筆記本電腦能夠在 4 秒內證明以太坊區塊？介于兩者之間？
破壞向后兼容性的程度：其他領域的不足可以通過進行更激進的 gas 成本變更來彌補，但這更有可能不成比例地增加某些應用程序的成本，并迫使開發人員重寫和重新部署代碼以保持經濟可行性。同樣，「帽子里的兔子」也有其自身的復雜性和缺點。
它如何與路線圖的其他部分互動？
實現 layer1 的 EVM 有效性證明所需的核心技術與其他兩個領域高度共享：
layer2 的有效性證明（即「ZK rollups」）
「STARK 二進制哈希證明」 無國籍方法
在 layer1 成功實施有效性證明可實現極致輕松的solo 質押：即使是最弱的計算機（包括手機或智能手表）也能夠進行質押。這進一步增加了解決solo 質押的其他限制（例如最低 32 ETH）的價值。
此外，L1 的 EVM 有效性證明可以顯著提高 L1 的 gas 限制。
共識的有效性證明
我們要解決什么問題？
如果我們希望使用 SNARK 完全驗證以太坊區塊，那么 EVM 執行并不是我們需要證明的唯一部分。我們還需要證明共識：系統中處理存款、取款、簽名、驗證者余額更新以及以太坊權益證明部分的其他元素的部分。
該共識比 EVM 簡單得多，但它面臨的挑戰是，我們沒有 layer2 EVM rollup，這也是大部分工作無論如何都要完成的原因。因此，任何證明以太坊共識的實現都需要「從頭開始」，盡管證明系統本身是可以在此基礎上構建的共享工作。
它是什么以及它是如何工作的？
信標鏈被，就像 EVM 一樣。狀態轉換函數由三件事主導：
ECADD（用于驗證 BLS 簽名）
配對（用于驗證 BLS 簽名）
SHA256 哈希（用于讀取和更新狀態）
在每個區塊中，我們需要為每個驗證者證明 1-16 個 BLS12-381ECADD（可能不止一個，因為簽名可以包含在多個聚合中）。這可以通過子集預計算技術來補償，因此總的來說，我們可以說每個驗證者有一個 BLS12-381 ECADD。今天，每個 slot 中有大約 30,000 個驗證者簽名。在未來，隨著單 slot 的終結，這可能會朝任何一個方向改變（請參閱）：如果我們采取「蠻力」路線，這可能會增加到每個 slot 100 萬個驗證者。同時，使用 Orbit SSF，它將保持在 32,768，甚至減少到 8,192。
BLS 聚合的工作原理。驗證聚合簽名僅需要每個參與者進行一次 ECADD，而不是 ECMUL。但 30,000 次 ECADD 仍有大量工作需要證明。
對于配對，目前每個 slot 最多有 128 個證明，這意味著需要驗證 128 個配對。隨著和進一步的變更，這個數字可能會減少到每個 slot 16 個。配對數量很少，但成本極高：每個配對的運行時間（或證明時間）是 ECADD 的數千倍。
證明 BLS12-381 操作的一個主要挑戰是，沒有方便的曲線，其曲線階數等于 BLS12-381 字段大小，這會給任何證明系統增加相當大的開銷。另一方面，為以太坊提出的 Verkle tree 是用構建的，這使得 BLS12-381 本身成為 SNARK 系統中用來證明 Verkle 分支的自然曲線。一個相當簡單的實現可以證明每秒約 100 個 G1 加法；幾乎肯定需要像 GKR 這樣的巧妙技術來使證明足夠快。
對于SHA256 哈希值，目前最糟糕的情況是 epoch 轉換塊，其中整個驗證器短余額樹和大量驗證器余額都會更新。驗證器短余額樹每個驗證器占一個字節，因此大約有 1 MB 的數據被重新哈希。這相當于 32,768 次 SHA256 調用。如果一千個驗證器的余額高于或低于需要更新驗證器記錄中的有效余額的閾值，這相當于一千個 Merkle 分支，因此可能還需要一萬個哈希值。需要每個驗證器 90 位（因此需要 11 MB 數據），但這可以在一個 epoch 的過程中隨時計算。在single slot 最終性的情況下，這些數字可能會根據細節再次增加或減少。改組變得沒有必要，盡管 Orbit 可能會在一定程度上重新需要改組。
另一個挑戰是需要讀取所有驗證器狀態（包括公鑰）才能驗證區塊。僅讀取公鑰就需要 4800 萬字節（100 萬個驗證器，加上 Merkle 分支）。這需要每個時期數百萬個哈希值。如果我們今天必須證明權益證明的驗證，那么一種現實的方法將是某種形式的增量可驗證計算：在證明系統內存儲一個單獨的數據結構，該結構針對高效查找進行了優化，并證明對該結構的更新。
總而言之，有很多挑戰。
要最有效地解決這些挑戰，可能需要對信標鏈進行深度重新設計，這可能與切換到 single slot 最終性同時發生。此重新設計的特點可能包括：
哈希函數更改：今天，使用「完整」SHA256 哈希函數，因此由于填充，每次調用都對應兩個底層壓縮函數調用。至少，通過切換到 SHA256 壓縮函數，我們可以獲得 2 倍的收益。如果我們切換到 Poseidon，我們可以獲得潛在的約 100 倍的收益，這可以完全解決我們所有的問題（至少對于哈希而言）：以每秒 170 萬個哈希（54 MB）的速度，即使一百萬個驗證器記錄也可以在幾秒鐘內「讀入」證明中。
如果是 Orbit，則直接存儲打亂的驗證者記錄：如果您選擇一定數量的驗證者（例如 8,192 或 32,768）作為給定 slot 的委員會，則將它們直接放入彼此相鄰的狀態中，這樣就需要最少量的哈希來將所有驗證者公鑰讀入證明。這還將允許高效地完成所有余額更新。
簽名聚合：任何高性能簽名聚合方案實際上都會涉及某種遞歸證明，其中簽名子集的中間證明將由網絡中的各個節點進行。這自然會將證明負載分攤到網絡中的許多節點上，從而使「最終證明者」的工作量大大減少。
其他簽名方案：對于 Lamport Merkle 簽名，我們需要 256 32 個哈希值來驗證簽名；乘以 32,768 個簽名者可得到 9,437,184 個哈希值。對簽名方案的優化可以通過一個小的常數因子進一步改善這一點。如果我們使用 Poseidon，這在單個 slot 內即可證明。但實際上，使用遞歸聚合方案可以更快地完成這一過程。
與現有研究有哪些聯系？
簡潔的以太坊共識證明（僅同步委員會）：
簡潔，SP1 內的 Helios：
簡潔的 BLS12-381 預編譯：
基于 Halo2 的 BLS 聚合簽名驗證：
還剩下什么要做？有哪些需要權衡？
實際上，我們需要數年時間才能證明以太坊共識的有效性。這大致與我們需要實現 single slot 最終性、Orbit、簽名算法更改以及潛在安全分析的時間相同，這些安全分析需要足夠自信地使用像 Poseidon 這樣的「激進」哈希函數。因此，解決這些其他問題是最有意義的，并且在進行這些工作時要牢記 STARK 友好性。
主要的權衡可能在于操作順序，即在改革以太坊共識層的更漸進方法和更激進的「一次進行許多更改」方法之間。對于 EVM，漸進方法是有意義的，因為它最大限度地減少了對向后兼容性的破壞。對于共識層，向后兼容性問題較小，并且更「全面」地重新思考信標鏈構建的各種細節是有好處的，從而最大限度地優化 SNARK 友好性。
它如何與路線圖的其他部分互動？
在以太坊權益證明共識的長期重新設計中，STARK 友好性需要成為主要關注點，最值得注意的是 single slot 最終性、Orbit、簽名方案的更改以及簽名聚合。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
