此文件是基于我们在Gate.io产品上的工作而产生的FOCIL 共識規範 23，在那裡我們意識到協議需要更加深思熟慮地考慮資源限制，因為某些細節在協議中並沒有明確指定。FOCIL 以太坊研究帖子14.

先決條件

在開始之前，我們假設以下的設置來建立一個乾淨的基準，以供我們考慮:

• 該設置基於Electra硬分叉。在 EIP-7732 （ePBS） 之上重新訪問這一點進行比較也是有意義的
• 我們假設獨立的區塊建立和發布，其中提案者不運行MEV-Boost。這是正確的第一個關鍵組件，而 Builder API 是次要考慮因素。
• 我們假設使用典型的計算、記憶體需求和頻寬的獨立staker設置，您可以輕鬆地在今天的以太坊鏈上進行操作。

演員

在我們繼續之前，我們假設以下角色是協議的一部分，並分析他們的責任：

• Inclusion List (IL) 委員會成員負責通過其包含清單交易的設定來限制下一個區塊提議者。
• 提案者負責提出下一個時隙
• 對於鏈頭的下一個槽位進行見證的見證人
• 節點，用於驗證和跟蹤鏈。提議者和證明人是質押乙太幣的節點的一部分

時間軸

我們假設以下時間軸，在這個時間軸上，IL委員會、提議者和見證者執行了一些誠實的行動：

• 插槽 n-1，t=6：IL 委員會在瞭解區塊 n-1 的內容後，針對全域主題發佈其本地包含清單 （IL）
• 槽n-1，t=9：证明者和诚实的验证节点锁定他们对本地ILs的视图
• Slot n，t=0：槽n的区块提议者发布区块B，其中包括应满足IL要求的有效负载
• Slot n，t=4：第 n 槽的证明者對區塊 B 進行投票，通過將其與本地 IL 視圖進行比較來驗證 IL 匯總，並確認區塊 B 是否“有效”
  • 當我們提到區塊時，我們會過度使用“有效”這個詞，但它可能意味著“可匯入”、“規範”或其他某種意思。請參閱有關進一步澄清的開放問題。

間隔1：IL委員會發布本地IL

演員：納入清單委員會

以色列委員會成員從EL客戶端檢索IL交易列表（使用CL → EL呼叫），然後對本地IL（交易+摘要）進行簽名並將其發布到八卦網絡。

資源考量

• 從EL記憶池中檢索IL交易→ CPU / MEM
• 簽署包含列表 → CPU
• 將包含清單上傳到網絡訊息傳遞 → 頻寬（上傳）

演員：節點（包括 Attesters）

遵循鏈的節點將下載 IL，驗證其反 DOS（尚未將其導入 EL），並將其轉發給其他對等方。節點還將 IL 導入到分叉選擇中，並使用 aggreGate 緩存跟蹤已看到哪些 IL。鏈後面的證明人和節點應該具有相同的鏈視圖。

資源考量

• 下載IL → 帶寬（下載）
• IL → 頻寬（上傳）
• 驗證反DOS的IL → CPU/MEM
• 快取已見並聚合Gate ILs → MEM

演員：求婚者

下一个时隙的提议者积极监控IL信息传播网络，并收集和聚合本地IL，然后在IL聚合截止时间（间隔＃2）时，提议者将使用要包括在其块中的IL交易列表更新块构建过程。这需要进行CL到EL的调用。

資源考量

• 繼承了跟隨鏈的節點相同的成本

提案者邊緣案例

如果下一個slot的提議者觀察到足夠數量基於它未見過的父哈希的包含列表，則該提議者將需要手動請求缺失的信標區塊，導入該區塊並在該區塊之上構建。

結論

基於上述，我們可以識別潛在的資源密集型區域並將其縮小:

• IL委員會的CPU影響：從EL檢索IL交易並簽署：雖然這裡存在資源需求，但這被認為是相對廉價且不是一個重大問題。
• 節點帶寬影響：節點下載和上傳 ILs 可能會使用大量的帶寬，特別是目前的研究報告指出包含清單大小是靈活/無限制的。這可能會引入潛在的 DOS 風險，因為惡意的 IL 委員會成員可能會向網絡洪水般發送大量交易，即使它們是無效的。節點在導入 ILs 之前仍然會傳播有關 IL 的消息。需要仔細考慮反 DoS 措施。

间隔2：节点锁定视图，提案人导入 IL 交易

演員: 提議者

提案人使用包含列表交易的更新區塊建立過程。這是一個CL → EL的呼叫。

資源考量

• 使用包含清單交易更新區塊建置過程 → CPU/MEM

演員：節點（包括證明者）

鎖定包含列表視圖。從這一點開始停止接受本地包含列表。

資源考量

• 鎖定本地包含列表視圖 → 無

結論

• 提議者的CPU影響：將IL交易導入區塊建構過程可能會干擾區塊建構過程，可能會在交易模擬期間對執行層客戶端的CPU造成壓力。在帳戶摘要下，這可能變得複雜，因為交易可能會使彼此無效。這需要進一步分析。

間隔3：發起人釋放區塊

演員：提議人

提案者從EL客戶端（CL → EL調用）檢索執行載荷，並將其發布到信標塊八卦網絡。其他人隨後驗證該區塊。

資源考量

• 從EL客戶端檢索有效載荷 → CPU/MEM

演員：節點

節點接收信標區塊並對其進行驗證。新的驗證步驟包括檢查包括列表合成和確認包括列表是否滿足評估函數，該函數將在CL上完成。IL條件的檢查（是否由於衝突可以跳過或不）將在EL上執行。

資源考量

• 確認在 CL → CPU 上滿足包含清單
• 在EL → CPU上驗證包含清單條件

結論

對於提議者來說，額外的職責似乎不是一個重大的問題。對節點的新驗證步驟 - 檢查驗證包含列表是否滿足滿意條件 - 可能會引入一些額外的CPU負載，但這似乎不是一個主要問題。

間隔4：審核委員會

演員：Attester

驗證者使用LMD GHOST分叉選擇規則為信標區塊投票。根據來自區間1的觀察，驗證者只會為滿足包含列表評估函數的信標區塊投票。

資源考量

• 對符合包含列表評估函數的區塊進行投票→無額外費用

結論

今天和今天沒有區別。

資源考量摘要

如上所述，最重要的資源問題圍繞著包含清單的上傳、下載，以及節點可能遭受的垃圾郵件攻擊。另一個關鍵問題是節點為驗證和匯入包含清單所需的額外負擔，以及建議者需要更新其區塊建立流程以滿足包含清單的需求。這些方面需要仔細考慮和設計，以確保效率和安全性。

開放問題

根據以上，我們概述了幾個將影響規範撰寫方式的開放問題：

1. 未滿足評估函數的區塊：未能通過包含清單評估函數的區塊應該如何處理？在這種情況下應該考慮哪些設計因素？
   • 是否應該與blob一樣對待，不能被導入？
   • 它不應該按照分叉選擇進行過濾嗎？
   • 在狀態轉換函數中是否不應該有效？
2. 包含列表的矛盾：如果一個包含列表委員會成員將不同版本的包含列表發送給不同的節點，並且它們都在網絡上傳播，這樣做會有什麼後果？這種行為如何對提議者構建下一個區塊產生負面影響？
3. 提議者已經建立在不同的頭上：如果提議者建立在與收錄清單委員會發送的頭不同的頭上，因此需要改變其頭視圖，那麼此行動對區塊有效性和提議者行為有什麼後果？
4. Inclusion List Transactions Invalidations: 本地包含列表交易可能以幾種方式被無效。即使這些交易被無效，該區塊仍應能滿足評估功能。交易可能因多個包含列表彼此合併或與區塊中的交易合併而被無效。除了典型的nonce檢查外，賬戶抽象引入了交易被無效的新方法，因為餘額可以在靜態nonce下被耗盡。區塊生成者需要執行多少額外模擬以處理交易無效，以及這對MEV-Boost參與者和本地生成者的CPU計算產生了多少影響，這一切還有待觀察。
5. 提案者對於 IL 委員會子網的觀察：提案者監視包含清單委員會子網，以了解何時準備好構建 aggreGate。這裡有兩種設計方法，值得進一步考慮。第一種方法是貪婪的提案者，提案者等到 t=9，收集盡可能多的 IL，將它們發送給 EL，並且 EL 更新其區塊。第二種方法是選擇性的提案者，提案者等到有足夠的包含清單以滿足評估函數後，將它們發送給 EL，可以在 t=9s 或甚至更早之前完成。問題是第二種方法是否能夠證明優化，以允許提案者更早釋放包含清單 aggreGate。第二種方法可能只適用於具有自己專用的 gas 限制的 IL。

免責聲明：

1. 本文轉錄自 [ Gate.io ]ethresear]. 所有版權屬於原作者 [terence]. 如果對此轉載有異議，請聯繫Gate 學習團隊將會迅速處理。
2. 責任聲明：本文所表達的觀點和意見僅代表作者個人觀點，並不構成任何投資建議。
3. 文章的翻譯由Gate Learn團隊完成。除非另有說明，禁止複製、分發或抄襲翻譯後的文章。