Vitalik 新文：以太坊協議可能的未來 The Verge

ChainCatcher 精選

2024-10-23 16:43:44

實際上，我們需要數年時間才能獲得以太坊共識的有效性證明。

分享至

微信掃碼

原標題：《Possible futures of the Ethereum protocol, part 4: The Verge》

作者：Vitalik Buterin

編譯：Mensh，ChainCatcher

特別感謝Justin Drake、Hsia-wei Wanp、Guillaume Ballet、Icinacio、Rosh Rudolf、Lev Soukhanoy Ryan Sean Adams和Uma Roy的反饋和審閱。

區塊鏈最強大的功能之一就是任何人都可以在自己的電腦上運行一個節點，並驗證區塊鏈的正確性。即使9596個運行鏈共識（PoW、PoS）的節點都立即同意更改規則，並開始根據新規則生產區塊，每個運行完全驗證節點的人都會拒絕接受鏈。不屬於這種陰謀集團的造幣者會自動匯聚到一條繼續遵循舊規則的鏈上，並繼續構建這條鏈，而完全通過驗證的用戶將遵循這條鏈。

這是區塊鏈與中心化系統的關鍵區別。然而，要使這一特性成立，運行一個完全驗證的節點需要對足夠多的人來說確實可行。這既適用於造勢者（因為如果造勢者不驗證鏈，他們就沒有為執行協議規則做出貢獻），也適用於普通用戶。如今，在消費類筆記本電腦（包括寫這篇文章時使用的筆記本電腦）上運行節點是可能的，但要做到這一點卻很困難。The Verge 就是要改變這種狀況，讓完全驗證鏈的計算成本變得低廉，讓每個手機錢包、瀏覽器錢包甚至智能手表都會默認進行驗證。

The Verge 2023路線圖

最初，"Verge"指的是將以太坊狀態存儲轉移到 Verkle 樹------一種允許更緊湊證明的樹形結構，可實現以太坊區塊的無狀態驗證。節點可以驗證一個以太坊區塊，而無需在其硬盤上存儲任何以太坊狀態（賬戶餘額、合約代碼、存儲空間……），代價是花費幾百KB的證明數據和幾百毫秒的額外時間來驗證一個證明。如今，Verge代表了一個更大的願景，專注於實現以太坊鏈的最大資源效率驗證，其中不僅包括無狀態驗證技術，還包括使用SNARK驗證所有以太坊執行。

除了對SNARK驗證整條鏈的長期關注之外，另一個新問題與Verkle樹是否是最佳技術有關。Verkle樹容易受到量子計算機的攻擊，因此，如果我們將目前的KECCAK Merkle Patricia樹中的Verkle樹，我們以後還得再次替換樹。Merkle樹的自替代方法是直接跳過使用Merkle分支的STARK，將其放入二叉樹。從歷史上看，由於開銷和技術複雜性，這種方法一直被認為是不可行的。不過最近，我們看到Starkware在一台筆記本電腦上使用ckcle STARKs每秒證明了170萬個Poseidon哈希，而且由於GKB等技術的出現，更多 "傳統 "哈希值的證明時間也在迅速縮短。因此，在過去的一年裡，"Verge"變得更加開放，它有幾種可能性。

The Verge：關鍵目標

無狀態客戶機：完全驗證客戶機和標記節點所需的存儲空間不應超過幾GB。
（長期）在智能手表上完全驗證鏈（共識和執行）。下載一些數據，驗證SNARK，完成。

在本章中

無狀態客戶機：Verkle還是STARKs
EVM執行的有效性證明
共識的有效性證明

無狀態驗證：Verkle 還是 STARKs

我們要解決什麼問題？

如今，以太坊客戶端需要存儲數百千兆字節的狀態數據來驗證區塊，而且這一數量每年都在增加。原始狀態數據每年增加約30GB，單個客戶端必須在上面存儲一些額外的數據，才能有效地更新三元組。

這就減少了能夠運行完全驗證以太坊節點的用戶數量：儘管足以存儲所有以太坊狀態甚至多年歷史的大硬盤隨處可見，但人們默認購買的電腦往往只有幾百千兆字節的存儲空間。狀態大小也給首次建立節點的過程帶來了巨大的摩擦：節點需要下載整個狀態，這可能需要數小時或數天的時間。這會產生各種連鎖反應。例如，它大大增加了節點製作者升級其節點設置的難度。從技術上講，可以在不停機的情況下完成升級------啟動一個新客戶端，等待它同步，後關閉舊客戶端並傳輸密鑰------但在實際操作中，這在技術上非常複雜。

它如何工作？

無狀態驗證是一種允許節點在不掌握整個狀態的情況下驗證區塊的技術。取而代之的是，每個區塊都附帶一個見證，其中包括：(i) 該區塊將訪問的狀態中特定位置的值、代碼、餘額、存儲； (ii) 證明這些值正確的加密證明。

實際上，實現無狀態驗證需要改變以太坊的狀態樹結構。這是因為當前的Merkle Patricia 樹對於實施任何加密證明方案都是極端不友好的，尤其是在最壞的情況下。無論是 "原始 "Merblk分枝，還是"包裝"成STARK的可能性，都是如此。主要困難源於MPT的一些弱點：

1.這是一棵六叉樹（即每個節點有16個子節點）。這意味著，在大小為N的樹中，一個證明平均需要32*(16-1)*log16(N) = 120* log2(N)字節，或者在2\^32項的樹中大約需要 3840字節。對於二叉樹，只需要32*(2-1)*log2(N) = 32* log2(N)字節，或大約1024字節。

2.代碼未被Merkle化。這意味著要證明賬戶代碼的任何訪問權限，都需要提供整個代碼，最多為24000字節。

我們可以計算出最壞的情況如下：

30000000 gas / 2400 (冷賬戶閱讀成本) * （5 * 488 + 24000) = 330000000字節

分支成本略有降低（用5*480代替8*480），因為當分支較多時，其頂端部分會重複出現。但即便如此，在一個時隙內要下載的數據量也是完全不現實的。如果我們嘗試用STARK來封裝它，就會遇到兩個問題：(i) KECCAK對STARK相對不友好；(ii) 330MB的數據意味著我們必須證明對KECCAK round函數的500萬次調用，這對於除了最強大的消費級硬件之外的所有硬件來說，都可能證明不了，即使我們能讓STARK證明KECCAK的效率更高。

如果我們直接用二叉樹代替十六進制樹，並對代碼進行額外的Merkle化處理，那麼最壞的情況大致會變成30000000/2400*32*(32-14+8) = 10400000字節（14是對2\^14分支的冗餘位進行的減法，而8則是進入代碼塊中葉的證明的長度）。需要注意的是，這需要改變gas成本，對訪問每個單獨的代碼塊收費；EIP-4762 就是這麼做的。10.4 MB的容量要好得多，但對於許多節點來說，在一個時隙內下載的數據還是太多了。因此，我們需要引入更強大的技術。在這方面，有兩種領先的解決方案：Verkle樹和STARKed二進制哈希樹。

Verkle樹

Verkle樹使用基於橢圓曲線的矢量承諾來進行更短的證明。解鎖的關鍵在於，無論樹的寬度如何，每個父子關係對應的證明部分都只有32字節。證明樹寬度的唯一限制是，如果證明樹過寬，證明的計算效率就會降低。為以太坊提出的實現方案寬度為256。

因此，證明中單個分支的大小變為32 - 1og256(N) = 4* log2(N)字節。因此，理論上的最大證明大小大致為30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000字節（由於狀態塊的分佈不均勻，實際計算結果略有不同，但作為第一近似值是可以的）。

另外需要注意的是，在上述所有示例中，這種 "最壞情況 "並不是最壞情況：更壞的情況是攻擊者故意"挖掘"兩個地址，使其在樹中具有較長的共同前綴，並從其中一個地址讀取數據，這可能會將最壞情況下的分支長度再延長2倍。但即使有這樣的情況，Verkle樹的最壞證明長度為2.6MB，與目前最壞情況下的校驗數據基本吻合。

我們還利用這一注意事項做了另一件事：我們讓訪問 "相鄰 "存儲空間的成本變得非常低廉：要麼是相同合同的許多代碼塊，要麼是相鄰的存儲槽。EIP - 4762提供了鄰接的定義，對鄰接訪問只收取 200 gas費。在相鄰訪問的情況下，最壞情況下的證明大小變為30000000 / 200*32 - 4800800字節，這仍大致在公差範圍內。如果為了安全起見，我們希望減少這個值，可以稍微增加相鄰訪問的費用。

STARKed二進制哈希樹

這項技術的原理不言自明：你只需做一棵二叉樹，獲取最大10.4 MB的證明，證明塊中的值，後用證明的STARK代替證明。這樣，證明本身就只包含被證明的數據，再加上來自實際STARK的100-300kB固定開銷。

這裡的主要挑戰是驗證時間。我們可以進行與上述基本相同的計算，只不過我們計算的不是字節數，而是哈希值。一個10.4 MB的區塊意味著330000個哈希值。如果再加上攻擊者 "挖掘 "地址樹中具有較長公共前綴的可能性，那麼最壞情況下的哈希值將達到約660000 哈希值。因此，如果我們能證明每秒的哈希值為200,000，那就沒問題了。

在使用 Poseidon哈希函數的消費類筆記本電腦上，這些數字已經達到，而Poseidon哈希函數是專門為STARK友好性而設計的。但是，Poseidon系統還相對不成熟，因此很多人還不信任它的安全性。因此，有兩條現實的前進道路：

快速對Poseidon進行大量安全分析，並對其足夠熟悉，以便在L1進行部署
使用更 "保守 "的哈希函數，如SHA256或BLAKE

如果要證明保守的哈希函數，Starkware的STARK圈在撰寫本文時只能在消費類筆記本電腦上每秒證明10-30k哈希值。不過，STARK技術正在迅速改進。即使在今天，基於GKR的技術也顯示出將這一速度提高到100-200k範圍。

除驗證區塊外的見證使用案例

除了驗證區塊外，還有其他三個關鍵用例需要更高效的無狀態驗證：

內存池：當交易被廣播時，P2P網絡中的節點需要在重新廣播之前驗證交易是否有效。如今驗證包括驗證簽名，還包括檢查餘額是否充足和前綴是否正確。在未來（例如，使用原生賬戶抽象，如EIP-7701，這可能會涉及運行一些EVM代碼，這些代碼會進行一些狀態訪問。如果節點是無狀態的，則交易需要附帶證明狀態對象的證明。
包含列表：這是一個提議的功能，允許（可能規模較小且不複雜的）權益證明驗證者強制下一個區塊包含交易，而不管（可能規模較大且複雜的）區塊構建者的意願。這將削弱有權勢者通過延遲交易來操縱區塊鏈的能力。不過，這需要驗證者有辦法驗證包含列表中交易的有效性。
輕客戶端：如果我們希望用戶通過錢包訪問鏈（如Metamask、Rainbow、Rabby等），要做到這一點，他們需要運行輕型客戶端（如Helios).Helios核心模塊為用戶提供經過驗證的狀態根。而為了獲得完全無信任的體驗，用戶需要為他們所做的每個RPC 調用提供證明（例如，對於以太網調用請求（用戶需要證明在調用過程中訪問的所有狀態）。

所有這些用例都有一個共同點，那就是它們需要相當多的證明，但每個證明都很小。因此，STARK證明對它們並沒有實際意義；相反，最現實的做法是直接使用Merkle分支。Merkle 分支的另一個優點是可更新：給定一個以區塊B為根的狀態對象X的證明，如果收到一個子區塊B2及其見證，就可以更新證明，使其以區塊B2為根。Verkle證明也是原生可更新的。

與現有研究有哪些聯繫：

還能做些什麼？

剩下的主要工作是

1.關於EIP-4762後果的更多分析（無狀態gas成本變化）

2.完成和測試過渡程序的更多工作，這是任何無國籍環境實施方案複雜性的主要部分

3.對Poseidon、Ajtai和其他"STARK-friendly "哈希函數的更多安全分析

4.為 "保守"（或 "傳統"）哈希進一步開發超高效STARK協議功能，例如基於Binius或GKR的觀點。

此外，我們很快就會決定從以下三個選項中選擇一個：(i) Verkle樹，(ii) STARK友好哈希函數以及(iii)保守哈希函數。它們的特性可大致歸納在下表中：

除了這些 "標題數字"，還有其他一些重要的考慮因素：

如今，Verkle樹代碼已經相當成熟。除了Verkle之外，使用其他任何代碼都會推遲部署，很可能會推遲一個硬分叉。這也沒有關係，尤其是如果我們需要額外的時間來進行哈希函數分析或驗證器實現，或者我們有其他重要的功能想要更早地納入以太坊。
使用哈希值更新狀態根比使用Verkle樹更快。這意味著基於哈希值的方法可以降低全節點的同步時間。
Verkle樹具有有趣的見證更新屬性------Verkle樹見證是可更新的。這個屬性對 mempool、包含列表和其他用例都很有用，而且還可能有助於提高實現效率：如果更新了狀態對象，就可以更新倒數第二層的見證，而無需讀取最後一層的內容。
Verkle樹更難進行SNARK證明。如果我們想把證明大小一直減小到幾千字節，Verkle證明就會帶來一些困難。這是因為Verkle證明的驗證引入了大量 256位操作，這就要求證明系統要麼有大量開銷，要麼本身有一個定制的內部結構，其中包含256位的Verkle證明部分。這對無狀態本身不是問題，但會帶來更多困難。

如果我們想以量子安全且合理高效的方式獲得Verkle見證可更新性，另一種可能的途徑是基於lattice的Merkle樹。

如果在最壞的情況下，證明系統的效率不夠高，那麼我們還可以利用多維gas這意料之外的工具來彌補這種不足：為(i) calldata；(ii)計算；(iii)狀態訪問以及可能的其他不同資源設定單獨的gas限制。多維gas增加了複雜性，但作為交換，它更嚴格地限制了平均情況和最壞情況之間的比率。有了多維gas，理論上需要證明的最大分支數可能會從12500減少到例如3000。這將使BLAKE3即使在今天也（勉強）夠用。

多維gas允許區塊的資源限制更接近於底層硬件的資源限制

另一個意料之外的工具是將狀態根計算延遲到區塊之後的時隙。這樣，我們就有整整12秒的時間來計算狀態根，這意味著即使在最極端的情況下，每秒也只有60000哈希數的證明時間是足夠的，這再次讓我們認為BLAKE3只能勉強滿足要求。

這種方法的缺點是會增加一個時隙的輕客戶端延遲，不過也有更巧妙的技術可以將這種延遲減少到僅為證明生成延遲。例如，證明可以在任何節點生成後立即在網絡上廣播，而不是等待下個區塊。

它與路線圖的其他部分如何互動？

解決無狀態問題大大提高了單人定點的難度。如果有技術能降低單人定點的最低平衡，如 Orbit SSF或應用層策略，如小隊定點，這將變得更可行。

如果同時引入EOF，多維gas分析就會變得更加容易。這是因為多維gas最主要的執行複雜度來源於處理不傳遞父調用全部gas的子調用，而EOF只需將此類子調用設為非法，就可將這一問題變得微不足道（和本機賬戶抽象將為部分gas的當前主要使用情況提供一個協議內替代方案。

無狀態驗證和歷史過期之間還有一個重要的協同作用。如今，客戶端必須存儲近1TB的歷史數據；這些數據是狀態數據的數倍。即使客戶機是無狀態的，除非我們能解除客戶機存儲歷史數據的責任，否則幾乎無存儲客戶機的夢想將無法實現。這方面的第一步是 EIP-4444，這也意味著將歷史數據存儲在torrents或門戶網站Portal Network中。

EVM執行的有效性證明

我們要解決什麼問題？

以太坊區塊驗證的長期目標很明確------應該能夠通過以下方式驗證以太坊區塊：(i)下載區塊，或者甚至只下載區塊中數據可用性採樣的一小部分；(ii)驗證區塊有效的一個小證明。這將是一個資源佔用極低的操作，可以在移動客戶端、瀏覽器錢包中完成，甚至可以在另一個鏈中完成（沒有數據可用性部分）。

要達到這一點，需要對（i）共識層（即股權證明）和（ii）執行層（即 EVM）進行SNARK或STARK證明。前者本身就是一個挑戰，應該在進一步不斷改進共識層的過程中加以解決（例如，針對單槽終局性）。後者需要EVM執行證明。

它是什麼，如何運作？

從形式上看，在以太坊規範中，EVM被定義為一個狀態轉換函數：你有一些前狀態S，一個區塊B，你正在計算一個後狀態S' = STF(S，B)。如果用戶使用的是輕客戶端，他們並不完整地擁有S和S'，甚至E；相反，他們擁有一個前狀態根R，一個後狀態根R'和一個區塊哈希值H。

公共輸入：前狀態根R, 後狀態根R' , 塊哈希H
私人輸入：程序塊主體B、程序塊Q訪問的狀態中的對象、執行程序塊Q'後的相同對象、狀態證明（如Merkle分支）P
主張 1：P是一個有效的證明，證明Q包含R所代表的狀態的某些部分
主張 2：如果在Q上運行STF，(i) 執行過程只訪問Q內部的對象，(ii) 數據塊是有效的，(iii) 結果是Q'
主張 3：如果利用Q' 和P的信息重新計算新的狀態根，就會得到R'

如果存在這種情況，就可以擁有一個完全驗證以太坊EVM執行的輕型客戶端。這使得客戶端的資源已經相當低。要實現真正的完全驗證以太坊客戶端，還需要在共識方面做同樣的工作。

用於EVM計算的有效性證明的實現已經存在，並被L2大量使用。而要使EVM有效性證明在L1中可行，還有很多工作要做。

與現有研究有哪些聯繫？

還能做些什麼？

如今，電子記賬系統的有效性證明在兩個方面存在不足：安全性和驗證時間。

一個安全的有效性證明需要保證SNARK確實驗證了EVM的計算，並且不存在漏洞。提高安全性的兩種主要技術是多驗證器和形式驗證。多驗證器指的是有多個獨立編寫的有效性證明實現，就像有多個客戶端一樣，如果一個區塊被這些實現中的一個足夠大的子集證明，客戶端就會接受該區塊。形式驗證涉及使用通常用於證明數學定理的工具，如Lean4，以證明有效性證明只接受正確執行底層EVM規範（例如EVM K語義或用python編寫的以太坊執行層規範 (EELS)）。

足夠快的驗證時間意味著任何以太坊區塊都能在不到4秒的時間內得到驗證。今天，我們離這個目標還很遙遠，儘管我們已經比兩年前想象的要接近得多。要實現這一目標，我們需要在三個方向上取得進展：

並行化------目前最快的EVM校驗器平均可在15秒內證明一個以太坊區塊。它是通過在數百個GPU之間進行並行化，後在最後將它們的工作匯總在一來實現這一點的。從理論上講，我們完全知道如何製造一個能在O(log(N))時間內證明計算的EVM驗證器：讓一個GPU完成每一步，後做一個 "聚合樹"：

實現這一點存在挑戰。即使是在最壞的情況下，即一個非常大的事務佔用了整個區塊，計算的分割也不能按次進行，而必須按操作碼（EVM或RISC-V等底層虛擬機的操作碼）進行。要確保虛擬機的"內存"在證明的不同部分之間保持一致，是實施過程中的一個關鍵挑戰。不過，如果我們能實現這種遞歸證明，那麼我們知道，即使在其他方面沒有任何改進，至少證明者的延遲問題已經解決了。

證明系統優化--新的證明系統，如Orion、Binius、GRK以及其他更多信息，很可能會導致又一次大大縮短了通用計算的驗證時間。
EVM gas成本的其他變化------EVM中的許多東西都可以優化，使其更有利於證明者，尤其是在最壞的情況下。如果攻擊者可以構建一個阻塞證明者十分鐘時間的區塊，那麼僅能在4秒內證明一個普通的以太坊區塊是不夠的。所需的EVM更改可大致分為以下幾類：
gas成本的變化------如果一個操作需要很長時間才能證明，那麼即使它的計算速度相對較快，也應該有很高的gas成本。EIP-7667是為處理這方面最嚴重的問題而提出的一個EIP：它大大增加了（傳統）哈希函數的gas成本，因為這些函數的操作碼和預編譜相對便宜。為了彌補這些gas成本的增加，我們可以降低證明成本相對較低的EVM操作碼的gas成本，從而保持平均吞吐量不變。
數據結構替換------除了用對STARK更友好的方法替換狀態樹外，我們還需要替換事務列表、收據樹和其他證明成本高昂的結構。Etan Kissling將事務和收據結構移至SSZ的EIP就是朝著這個方向邁出的一步。

除此之外，上一節提到的兩個工具（多維gas和延遲狀態根）也能在這方面提供幫助。不過，值得注意的是，與無狀態驗證不同的是，使用這兩個工具意味著我們已經擁有了足夠的技術來完成我們目前所需的工作，而即使使用了這些技術，完整的ZK-EVM驗證也需要更多的工作------只是需要的工作更少而已。

上文沒有提到的一點是證明器硬件：使用GPU、FPGA和ASIC更快地生成證明。Fabric Cryptography、Cysic和Accseal是三家在這方面取得進展的公司。這對L2來說非常有價值，但不太可能成為L1的決定性考慮因素，因為人們強烈希望L1保持高度去中心化，這意味著證明生成必須在以太坊用戶的合理範圍內，而不應受到單個公司硬件的瓶頸限制。L2可以做出更積極的權衡。

在這些領域中，還有更多的工作要做：

並行化證明要求證明系統的不同部分可以 "共享內存"（如查找表）。我們知道這樣做的技術，但需要加以實現。
我們需要進行更多的分析，以找出理想的gas成本變化集，從而最大限度地減少最壞情況下的驗證時間。
我們需要在證明系統方面做更多的工作

可能的代價是：

安全性與驗證器時間：如果選擇更激進的哈希函數、更複雜的證明系統或更激進的安全假設或其他設計方案，就有可能縮短驗證器時間。
去中心化與證明器時間：社區需要就所針對的證明器硬件的 "規格 "達成一致。要求證明者是大規模實體可以嗎？我們希望高端消費筆記本電腦能在 4 秒內證明一個以太坊區塊嗎？介於兩者之間？
打破向後兼容性的程度：其他方面的不足可以通過更積極的gas成本變化來彌補，但這更有可能不成比例地增加某些應用程序的成本，迫使開發人員重寫和重新部署代碼，以保持經濟可行性。同樣，這兩個工具也有其自身的複雜性和弊端。

它與路線圖的其他部分如何互動？

實現L1 EVM有效性證明所需的核心技術在很大程度上與其他兩個領域共享：

L2的有效性證明（即 "ZK rollup"）
無狀態的 "STARK二進制哈希證明 "方法

在L1成功實現有效性證明，就能最終實現輕鬆的單人質押：即使是最弱的計算機（包括手機或智能手表）也能質押。這進一步提高了解決單人質押的其他限制（如32ETH最低限額）的價值。

此外，L1的EVM有效性證明可以大大提高L1的gas限值。

共識的有效性證明

我們要解決什麼問題？

如果我們想用SNARK完全驗證一個以太坊區塊，那麼EVM的執行並不是我們需要證明的唯一部分。我們還需要證明共識，即系統中處理存款、取款、簽名、驗證器餘額更新以及以太坊權益證明部分其他元素的部分。

共識比EVM簡單得多，但它面臨的挑戰是，我們沒有L2 EVM卷積，因此無論如何，大部分工作都要完成。因此，任何證明以太坊共識的實現都需要 "從頭開始"，儘管證明系統本身是可以在其基礎上構建的共享工作。

它是什麼，如何工作？

信標鏈被定義為狀態轉換函數,就像EVM一樣。狀態轉換函數主要由三部分組成：

ECADD（用於驗證BLS簽名）
配對（用於驗證BLS簽名）
SHA256哈希值（用於讀取和更新狀態）

在每個區塊中，我們需要為每個驗證器證明1-16個BLS12-381 ECADD（可能不止一個，因為簽名可能包含在多個集合中）。這可以通過子集預計算技術來彌補，因此我們可以說每個驗證者只需證明一個BLS12-381 ECADD。目前，每個插槽有30000個驗證器簽名。未來，隨著單時隙終局性的實現，這種情況可能會向兩個方向發生變化：如果我們採取 "蠻力"路線，每個時隙的驗證者數量可能會增加到100萬。與此同時，如果採用Orbit SSF，驗證器數量將保持在32768個，甚至減少到8192個。

BLS 聚合如何工作：驗證總簽名只需要每個參與者一個ECADD，而不是一個ECMUL。但是30000個ECADD仍然是一個很大的證明量。

就配對而言，目前每個插槽最多有128個證明，這意味著需要驗證128個配對。通過 ElP-7549和進一步的修改，每個插槽可以減少到16個。配對的數量很少，但成本極高：每個配對的運行（或證明）時間比ECADD長數千倍。

證明BLS12-381運算的一個主要挑戰是，沒有曲線階數等於BLS12-381字段大小的便捷曲線，這給任何證明系統都增加了相當大的開銷。另一方面，為以太坊提出的Verkle樹是用 Bandersnatch曲線構建的，這使得BLS12-381本身成為SNARK系統中用於證明Verkle分支的自曲線。一个比较简单的实现每秒可以证明100 G1的加法；要使证明速度足够快，几乎肯定需要像GKR这样的巧妙技术。

对于SHA256哈希值来说，目前最糟糕的情况是纪元转换块，整个验证器短平衡树和大量验证器平衡都会被更新。每个验证器的短平衡树只有一个字节，因此有1 MB的数据会被重新取哈希。这相当于32768次SHA256调用。如果有一千个验证者的余额高于或低于一个阈值，需要更新验证者记录中的有效余额，这相当于一千个Merkle分支，因此可能需要一万次哈希值。洗牌机制需要每个验证器90比特（因此需要11 MB的数据），但这可以在一个纪元的任何时间计算。在单槽终结的情况下，这些数字可能会根据具体情况有所增减。洗牌变得没有必要，尽管Orbit可能会在一定程度上恢复这种需要。

另一个挑战是需要重新获取所有验证器状态，包括公钥，才能验证一个区块。对于100万个验证器来说，仅读取公钥就需要4800万字节，再加上Merkle分支。这就需要每个纪元数以百万计的哈希值。如果我们必须证明PoS的有效性，一种现实的方法是某种形式的增量可验证计算：在证明系统内存储一个单独的数据结构，该数据结构经过优化，可以高效查找，并证明对该结构的更新。

总之，挑战很多。要最有效地应对这些挑战，很可能需要对信标链进行深入的重新设计，而这可能与转向单槽终局同时进行。这种重新设计的特点可能包括：

哈希函数的变化：现在使用的是 "完整 "的SHA256哈希函数，因此由于填充的原因，每次调用都要对应两次底层压缩函数调用。如果改用SHA256压缩函数，我们至少可以获得2倍的收益。如果改用Poseidon，我们可能会获得100倍的增益，从而彻底解决我们的所有问题（至少在哈希值方面）：在每秒170万哈希值（54MB），即使是一百万条验证记录也能在几秒钟内 "读取 "到证明中。
如果是Orbit，则直接存储洗牌后的验证器记录：如果选择一定数量的验证器（如8192或32768个）作为给定插槽的委员会，则将它们直接放入彼此旁边的状态中，这样只需最少的哈希就能将所有验证器的公钥读入证明中。这样还可以高效地完成所有平衡更新。
签名聚合：任何高性能签名聚合方案都会涉及某种递归证明，网络中的不同节点会对签名子集进行中间证明。这就自然而然地将证明工作分担给了网络中的多个节点，从而大大减少了 "最终证明者 "的工作量。
其他签名方案：对于Lamport+ Merkle签名，我们需要256 + 32个哈希值来验证签名；乘以32768个签名者，就得到9437184个哈希值。对签名方案进行优化后，可以通过一个很小的常数因子进一步改善这一结果。如果我们使用Poseidon，这在单个插槽内就能证明。但实际上，使用递归聚合方案会更快。

与现有研究有哪些联系？

还有哪些工作要做，如何取舍：

实际上，我们需要数年时间才能获得以太坊共识的有效性证明。这与我们实现单槽终局性、Orbit、修改签名算法以及安全分析所需的时间大致相同，而安全分析需要足够的信心才能使用像Poseidon这样 "激进 "的哈希函数。因此，最明智的做法是解决这些其他问题，并在解决这些问题的同时考虑到STARK的友好性。

主要的权衡很可能是在操作顺序上，在改革以太坊共识层的更渐进的方法和更激进的 "一次改变许多 "的方法之间。对于EVM来说，渐进式方法是合理的，因为它能最大限度地减少对向后兼容性的干扰。对共识层来说，向后兼容性的影响较小，而且对信标链构建方式的各种细节进行更 "全面 "的重新思考，以最佳方式优化SNARK友好性也有好处。

它与路线图的其他部分如何互动？

在对以太坊PoS进行长期重新设计时，STARK友好性必须成为首要考虑因素，尤其是单槽终局性、Orbit、签名方案变更和签名聚合。