面向未來的預先確認

Ethereum Research

06-16

本文為機器翻譯

展示原文

即將出臺的 EIP 如何影響預先確認

作者：Aikaterini-Panagiota Stouka和Conor McMenamin ，均為 Nethermind。

本文由PBS基金會資助完成。感謝Lin Oshitani和Davide Rezzoli的審閱和評論。觀點僅代表作者本人。

介紹

預確認是區塊提議者和構建者做出的一種特殊承諾，在提議者或構建者發佈完成的區塊進行最終確認之前，向用戶保證其交易會被納入/執行。然而，大多數預確認協議的設計和分析都參考了以太坊的當前設計。得益於以太坊改進提案 (EIP*)，以太坊一直在不斷改進和升級。其中一些 EIP 會直接影響預確認協議的兼容性，無論是設計上還是副作用。

本文從預確認的角度探討了一些最具影響力的以太坊改進方案 (EIP)，並分析這些 EIP 將如何影響預確認，以及在這些 EIP 被納入以太坊後，預確認協議可以採取哪些修訂（如有）來保持兼容性。這些 EIP 旨在修改 L1 區塊提議者的選擇方式，隱藏提議者前瞻機制，將區塊提議的責任分配給多個實體，或引入新的實體來為區塊內容和抗審查性做出貢獻。本報告基於目前最合理的 EIP 設計，分析了這些 EIP 可能如何影響預確認。

分析總結

圖片753×629 110 KB

圖片775×853 164 KB

文章提綱

在準備部分，我們介紹；

預先確認的類型，分類依據：
1. 交易對應哪一層（L1 還是 L2）
2. 預先確認所提供的擔保的性質（納入或執行）
當前設計中的關鍵預確認協議特徵：
1. 當預先約定發生偏差時進行懲罰。
2. 補償預先給予的獎勵/小費。

在分析每個 EIP 的框架部分中，我們介紹了用於評估現有預先確認設計是否以及如何受到提案和 EIP 的影響的框架。

隨後，以下各節將分別探討一個具體的 EIP。我們分析的 EIP 包括：

納入清單。具體來說：
1. Fork-Choice 強制包含列表(FOCIL)
2. 基於拍賣的以太坊抗審查納入清單設計（AUCIL）
多個併發提議者（MCP）
單一秘密領導人選舉（SSLE），
證明者提議者分離(APS)
神聖的提議者-建設者分離（ePBS）。

準備工作

預先確認的類型

預先確認有幾種可能的類型，具體取決於交易發生的區塊鏈層以及預先確認提供的保證的性質。

基於區塊鏈層的預確認類型有以下幾種：

L1 交易的預先確認；我們將其表示為L1 預先確認。
基於L2 的 L2 交易預確認；L2 區塊鏈協議中，L2 交易的排序由 L1 決定。在此分類中，有兩個重要區別：
1. 所有 L1 提議者都是 L2 提議者。對於本文進行的分析，這些預確認與 L1 預確認難以區分。出於這個原因，也為了便於表示，我們在 L1 預確認的分析中納入了基於 L2 的預確認分析，其中所有 L1 提議者都是 L2 提議者。
2. L1 提議者的一個子集是 L2 提議者。在這種情況下，一個 L2 提議者可能擁有在多個 L1 slot 內提議 L2 區塊的專有權。我們將這些預確認稱為基於 L2 的預確認。如上文 2.a 所述，這排除了所有 L1 提議者都是 L2 提議者的情況，本文將此類情況歸類為 L1 預確認。
非基於 Layer-2 的 L2 系統中的 L2 交易預確認（例如Arbitrum 、OP、Polygon Layer-2 區塊鏈協議，其中交易排序由 rollup 控制的排序器集處理）。由於在這類預確認中，交易排序不依賴於 Layer-1 的提議者，因此我們預計我們討論的 EIP 不會對這類預確認產生重大影響。

根據執行擔保的性質，可分為以下幾種類型：

包含預先確認：這些保證交易將被包含在未來的區塊中。
執行預確認：這些保證交易將被納入特定時段的特定訂單中。

注意：我們僅分析由指定提議者（包括相關的納入列表提議者/創建者，或被授予獨家提議權的實體）提供的預確認。我們省略了對不擁有提議權的實體提供的預確認的任何分析。這是為了確保重點分析預計在 L1 和 L2 上提供的主要預確認形式。非提議者和概率預確認也可能來自不保證提出必須遵守的區塊/納入列表的實體，但這超出了本文的討論範圍。

注意：對於納入預確認，許多指定的提議者（作為預協商者）可能會為同一筆交易提供預確認。提示的兼容性和有效性取決於如何處理相互競爭的納入預確認。一般而言，納入預協商者在提供預確認時必須承擔此風險。當同一插槽有多個預協商者時（例如在納入列表中以及多個併發的 EIP 提議者），此風險會更高。可以通過記錄所有預確認請求和響應的中介機構，或通過專門的支付提示的預確認平臺來降低這些風險。

在本文的其餘部分，提供預先確認的實體將被稱為預先確認者。

當前以太坊設計中預先確認的特點

為了探究各種 EIP 如何影響預確認設計，我們的分析考察了兩種關鍵的預確認協議機制可能如何受到相應 EIP 的影響。它們是懲罰機制和獎勵機制。正如之前 PBSF 資助文章中所強調的，預確認的關鍵在於激勵提議者提供並最終確認預確認的動機。通過展示每個 EIP 對現有預確認懲罰機制和獎勵機制的影響，我們能夠識別預確認的不兼容性，或者在大多數情況下，識別出預確認協議和/或底層區塊鏈功能的變更，這些變更對於正確啟用懲罰機制和獎勵機制以及預確認本身至關重要。

懲罰

所有預先確認的設計都依賴於某種形式的懲罰和/或執行機制，以阻止預先確認者違約或延遲簽發預先確認。為了便於分析，我們將根據執行懲罰的實體對這些懲罰進行分組，這受到了本文介紹的框架的啟發。

智能合約：在所有預確認設計中，智能合約可用於強制執行僅涉及客觀不當行為的條件。一些示例包括安全違規（預確認者擾亂了預確認的交易順序）以及活性違規（預確認者排除了預確認的交易）（參見預確認註冊表中的罰沒條件）。
監督者（此處擬定）：具有特殊權限，可對預先確認者強制執行某些行為或懲罰的實體。監督者最初是為了確保預先確認請求和響應的公平交換而引入的，但更廣泛地說，它們可用於強制執行客觀和主觀的預先確認要求。監督者的懲罰措施包括：
1. 削減。監督者可以任意對預先授予的抵押品施加削減條件。
2. 黑名單。監督者可以維護所有異常預決者的名單，並阻止他們在特定時期內充當預決者。
3. 訂單流損失。監督者可以通過以下方法之一減少或停止異常預先確認的訂單流（預先確認請求）：
  1. 預先確認必須由預先協商者和監督者簽署，從而允許監督者停止為不合規的預先協商者簽署預先確認。
  2. 信號。監督者可以發出信號，指出預先協商存在偏差，從而促使用戶停止向該預先協商發送預先確認請求。
用戶：用戶可以停止向異常預確認者發送預確認請求，無論是當前時段還是未來時段。這將被稱為訂單流損失，可以是短期的，也可以是長期的。

獎勵/小費

預確認者預計在發出預確認後將獲得獎勵。小費可以通過正常的交易費用支付給預確認者，也可以由監督者或專門的智能合約管理和分配。我們的分析重點在於，我們預期每個 EIP 下的小費支付機制和/或小費總額將如何變化。

分析每個生態產業園區的框架

我們使用以下框架來檢查引言中討論的每個 EIP：

我們提供了 EIP 的概述，重點關注與預先確認最相關的方面。
對於每種預先確認類型或類型組（每個小節一組），我們討論：
1. 兼容性：如果出現兼容性問題，我們會探索潛在的修改以確保一致性。
2. 因 EIP 而產生的懲罰和提示的有效性變化。

對於APS，我們採用了不同的框架，因為存在多種候選設計，每種設計都會以不同的方式影響不同預確認類型的兼容性。這將在第4節（涵蓋APS）中更詳細地解釋。

第一節納入清單

我們考察的首批 EIP 是允許多個類似提議者的實體通過構建包含列表來為區塊構建貢獻輸入的協議，其中指定一個提議者負責確定交易排序。這些協議旨在增強以太坊的抗審查能力。兩個突出的例子是強制分叉選擇 (Fork-Choice) 的包含列表(FOCIL)（EIP 參見此處）和基於拍賣的增強以太坊抗審查能力的包含列表設計(AUCIL)（預印本參見此處）。

1.1. FOCIL 和 AUCIL 概述

兩種協議都利用一個由隨機選擇的實體（稱為納入者）組成的委員會來創建交易的納入列表。

福西爾

區塊提議者創建自己的區塊，如果還有空間，他們必須將包含列表中的所有有效交易納入其中。如果未能做到，證明者可以拒絕他們的區塊。在當前設計中，用戶無需向包含者支付任何費用。我們將此核心設計稱為“無包含者費用的條件包含列表” 。此核心協議的關鍵變體包括：

無條件包含列表：區塊提議者必須包含所有包含者包含列表中的所有有效交易，即使在出現擁堵（即內存池中沒有足夠的空間容納所有交易）的情況下也是如此。交易排序由區塊提議者決定。
納入費用：如果用戶的交易同時包含在區塊和納入列表中，則用戶需向委員會支付額外費用（參見此處）。

愛爾蘭聯合基督教協會

AUCIL 是另一個旨在通過無條件包含列表增強以太坊抗審查能力的協議（參見此處第 3、15 頁）。AUCIL 的主要新增功能包括：（i）相關均衡方法，激勵包含者以特定方式創建 IL；（ii）基於拍賣的 IL 聚合：聚合器聚合 IL 並提交出價，區塊提議者選擇最大的聚合列表。如果區塊提議者不滿足關於聚合列表中包含多少個包含列表的特定要求（詳見此處），則提議者的區塊將被證明者拒絕。這些新增功能 (i) 與排序無關，也與提議者是否可以添加自己的交易無關 (ii) 可以允許更多 IL，因為我們不需要保證所有 IL 都必須對一個聚合器可用。就本文的目的而言，我們認為排序是由區塊提議者執行的，並且區塊提議者能夠添加更多交易（這與無條件 FOCIL 相同）。

1.2. 預先確認分析

我們將以下分析按預先確認類型進行分組，這些預先確認類型在與現有預先確認設計的兼容性以及相關懲罰和提示的有效性變化方面具有相似特徵。分組如下：

納入預先確認。
L1 執行預先確認。
基於 L2 執行預先確認。

1.2.a. 納入預先確認

在包含列表中，有兩個不同的參與者可能提供預先確認：區塊提議者和包含者。因此，我們分別討論每個參與者的兼容性。

兼容性：區塊提議者預先確認

使用 FOCIL 中的條件包含列表：

區塊提議者仍然可以將所有預先確認包含在他們的區塊中（因為只有當有可用空間時他們才需要遵守包含列表）
區塊提議者選舉流程保持不變。因此，我們預計與現有的預確認設計不會出現任何兼容性問題。

對於像 FOCIL 和 AUCIL 這樣的無條件包含列表，如果已知合併後的包含列表佔用的空間小於總區塊空間，我們同樣認為不會出現任何兼容性問題。在這種情況下，區塊提議者仍然可以針對剩餘的區塊空間發出預確認。

提議者可能會發布超出其自身區塊可用空間的預確認，並預期較早的 L1 提議者將利用可用區塊空間代表預確認者納入這些預確認。由於納入列表有望增強抗審查能力，這使得預確認者提供超出自身區塊空間的預確認更加可行且風險更低。

兼容性：包含者預先確認

FOCIL 中提供了無條件收錄列表，收錄者也可以發佈收錄預確認。假設 FOCIL 能夠按預期運行（例如，2 / 3的證明者是誠實的，且區塊提議者的目標是生成有效區塊），那麼收錄者的預確認與區塊提議者的預確認具有相同的優勢。

使用 AUCIL，包含者發佈的預確認風險更高，因為正如我們之前提到的，AUCIL 允許並非所有聚合器都能獲得包含列表的情況。為了獲得與 FOCIL 相同的預確認保證，我們需要在 AUCIL 設計中規定，即使區塊提議者遺漏了一個 IL，也要受到懲罰。

無條件納入列表的納入者提供預先確認的能力有一個明顯的缺點：預先確認會佔用納入列表的空間，而納入列表主要用於易受審查的交易。這個缺點被稱為“擁擠”，已在此處和此處進行了討論。

對於條件 FOCIL，我們不希望包含者發佈預先確認，因為區塊已滿時，區塊提議者可以省略 IL，而不會被證明者拒絕。此外，在下一個 slot 中，將選出新的包含者，而下一個 slot 的區塊提議者沒有義務包含之前區塊發佈的 IL 中的交易。（在 slot N+1 中，唯一需要遵守的 IL 是 slot N 的第 0 秒到第 9 秒之間傳播的 IL 。）

懲罰和提示的有效性

有條件列入名單不應影響懲罰機制的有效性，因為預先授予者仍然是相同的實體，以相同的方式和相同的頻率選舉產生。

對於無條件FOCIL和AUCIL的情況，從區塊提議者的角度來看，我們只期望與未來預先確認提示相關的懲罰機制能夠生效，也就是黑名單和訂單流丟失的懲罰。

由於無條件納入列表必須佔用一部分區塊空間，區塊提議者可用於預確認的空間會減少。這將影響預確認提示，進而影響黑名單和長期訂單流懲罰的有效性。目前，很難預測無條件納入列表對提示的確切影響，但我們至少看到兩種關鍵的抵消力量：

無條件納入名單減少了預先確認的能力，從而減少了收集提示的預先確認的數量。
由於區塊空間供應減少以及由此產生的可用空間需求增加，平均每個預確認提示應該會增加。

在納入者充當預確認者的情況下，黑名單的有效性和訂單流損失將與納入名單預確認市場的價值直接相關。與提議者預確認一樣，選舉頻率、納入名單規模以及在某個時段前多久提供預確認都會影響納入者的預確認收入。然而，這一價值的主要驅動力將來自用戶需求。在缺乏高價值預確認市場的情況下，罰沒仍然是一種可行的懲罰機制。

正如在“預先確認的類型”部分中提到的，許多納入者作為同一時段的納入預商增加了納入預先確認衝突的風險，這可能給預商帶來結算和小費風險。

1.2.b. L1執行預先確認

兼容性

在這種情況下，只有區塊提議者在區塊 N N期間才能發出預確認。此外，無論是有條件還是無條件包含列表，區塊提議者都保留對區塊排序的控制權。這確保了一旦區塊N-1 N − 1 的區塊發佈，區塊提議者在發出執行預確認時就能完全知曉必須遵循的相關L1或 L2 狀態。因此，我們預計這些類型的預確認不會出現任何兼容性問題，但在無條件包含列表中，區塊提議者應僅針對未佔用的包含列表區塊空間發出預確認。

對於執行預確認，包含者不能充當預確認者，因為他們不控制 L1 或 L2 區塊中交易的順序。

懲罰和提示的有效性

從區塊提議者的角度來看，這些預先確認的懲罰和提示的有效性與包含預先確認的懲罰和提示的有效性類似。

由於包含者無法提供執行預置，因此他們的分析與本節無關。

1.2.c. 基於 L2 執行預先確認

兼容性

不存在兼容性問題。基於 L2 執行預協商的參與者可以在其預確認槽開始後立即提供預確認。包含者（無論是無條件的還是有條件的）無法僅憑藉其作為包含者的身份提供基於 L2 執行預確認。如果包含者恰好註冊為 L2 提議者，則只有當其也是活躍的執行預協商參與者（即，它是包含者的預確認槽）時，該包含者才能提供基於 L2 執行預確認。否則，如果它是其他人的預確認槽，則其他人擁有提議 L2 區塊的專有權，從而使包含者提議的任何 L2 區塊無效。

懲罰和提示的有效性

在無條件納入列表中，預確認者擁有的可用區塊空間較少。如果這種減少影響了每個 slot 預確認的預期收益，那麼黑名單和長期訂單流也會受到影響，如 1.2.a 節所述。

除此之外，我們預計懲罰和小費的有效性不會發生重大變化，因為預選者無論是否有列入名單，都是以相同的方式和相同的頻率選舉產生的。

第 2 節多個併發提議者（MCP）

2.1. MCP概述

在MCP中，兩個或多個實體為當前 slot 提出部分區塊負載（我們將這些部分負載稱為子區塊）。最終區塊負載由所有這些子區塊中的交易並集構成，並根據某種確定性的排序規則進行排序。該確切規則尚有爭議，但優先費用排序已被考慮。BRAID 就是一個MCP協議的例子。

2.2. 預先確認分析

我們將本節的預確認分析分為以下幾部分：

納入預先確認。
執行預先確認。

2.2.a. 納入預確認

兼容性

假設子塊的並集不大於最終塊，提議者可以充當包含預先商，因為最終塊包含來自所有子塊的所有交易（也在此處、此處、此處討論）。

懲罰和提示的有效性

如第一節所述，黑名單和長期訂單流損失的有效性取決於每個週期的預確認的預期提示數量。提示數量越高，這些懲罰措施的效果就越好。雖然與單提議者協議相比，MCP 中的提議者應該被更頻繁地選舉，但為了保持網絡帶寬利用率，子塊的大小應該與提議者的數量成反比。換句話說，在 MCP 和單提議者協議中，預確認的總可用空間應該保持不變。如果是這樣，我們預計 MCP 中的預確認提示數量不會發生變化。

正如“預確認類型”部分所述，多個 MCP 提議者作為同一 slot 的納入預協商者，會增加納入預確認衝突的風險，從而可能給預協商者帶來風險。這取決於：

具體的 MCP 實現如何處理重複交易。
當多個預先確認者對同一筆交易提供預先確認時，如何向預先確認者支付小費：
- 例如，只向區塊包含交易最終副本的提議者支付一筆小費。
- 所有提供預先會議的預先會議參與者都會收到提示。

2.2.b. 執行預確認

兼容性

這取決於排序規則，但通常情況下，如果 MCP 提議者不知道合併區塊的最終排序，則無法提供 L1 執行預確認。在 MCP 實現中，如果子區塊被提前賦予排序優先級，則第一個子區塊的提議者可以提供執行預確認。話雖如此，這種 MCP 實現目前尚未得到充分考慮，儘管它與無條件 FOCIL 非常相似，其中區塊提議者擁有構建和排序區塊頂部的優先權。

對於 L2 執行預確認，如果單個 MCP 提議者擁有 L2 區塊提議的獨佔權限，則 L2 執行預確認是可行的。相反，如果多個 MCP 提議者可以提議 L2 區塊，則執行預確認不兼容。

第三節單一秘密領導者選舉

3.1. SSLE概述

在現有的單一秘密領導者選舉(SSLE) 架構中，一個共同點是驗證者在下一個週期的調度安排是隱藏的；只有當選的驗證者知道自己被分配為領導者（即提議者）的具體時間段，每個時間段只有一個領導者。這旨在增強對拒絕服務 (DoS) 的防護。SSLE 協議的具體描述是Whisk ，如下所示。

Whisk是本文介紹的協議的修改版本，其工作原理如下。首先，在引導期間，每個驗證者都會承諾一個長期隨機密鑰。然後，通過 RANDAO 隨機選擇一部分驗證者，並使用新的隨機數承諾其長期密鑰。這些承諾隨後由當前時間段的領導者進行混洗和重新隨機化。從混洗後的驗證者池中，通過 RANDAO 為每個時隙再選擇一個隨機子集，作為下一個時間段的時隙領導者。分配方法如下：只有被分配到時隙（知道與該時隙對應的密鑰）的驗證者才知道時隙分配情況。為了證明對特定時隙的領導權，驗證者必須證明其對相應承諾的所有權（而不洩露其長期密鑰）。他們通過使用零知識證明來證明他們知道承諾中嵌入的密鑰，並且該密鑰與其長期密鑰匹配，後者以加密方式與其身份綁定。

3.2. 預先確認分析

我們將第 3 節的分析分為以下幾部分：

包含和 L1 執行預先確認。
基於 L2 執行預先確認。

3.2.a. 納入和 L1 執行預先確認

兼容性

在SSLE設計中，如果預確認者願意提前透露其身份，那麼我們預計不會出現與現有預確認設計兼容的問題。當然，這確實會破壞選舉的保密性。

另一方面，如果預確認者希望在提議區塊之前保持匿名，那麼預確認機制的構建就需要仔細調整。下文我們將對兼容的改進預確認協議進行概述。

為了讓驗證者證明他們是插槽N N 的合格預分配者，同時保持匿名，驗證者必須證明以下兩個陳述成立：

該驗證者是槽位N N的領導者。
使用零知識證明來證明此陳述的方法也已在此處和此處進行了討論。在Whisk的具體案例中，驗證者需要證明他們知道與時隙N相關的承諾中隱藏的長期秘密。
如果懲罰涉及削減，則驗證者需要證明他們當前已在註冊合同中註冊以進行削減。
實現此目的的一種方法是讓註冊智能合約維護一個僅可追加的 Merkle 樹，其中包含所有註冊驗證者的公鑰，例如目前存在於通用註冊合約中。然後，預授權者可以提供證明，表明他們擁有與此 Merkle 樹中包含的公鑰相對應的私鑰（類似於Zcash中使用的技術）。
如果懲罰涉及黑名單，驗證者需要證明他們不屬於黑名單集。
實現這一點的一種方法是讓監督者（或智能合約）維護一組被列入黑名單和不在黑名單的預分配者，並讓預分配者證明他們是非黑名單集的成員，例如使用稀疏 Merkle 樹包含證明。

關於小費的兼容性，如果立即向預協商者提供小費，預協商者需要在其時間段之前披露地址，這可能會暴露其身份。相反，可以將小費支付給智能合約，並在時間段N N之後釋放給預協商者，直至不滿足任何罰沒條件。時間段N N過後，驗證者的身份將公開。因此，可以從此時開始應用小費和懲罰。

在保持預授者身份匿名的情況下，用戶施加的與聲譽相關的懲罰並非易事。或許可以啟用匿名聲譽工具，允許預授者向用戶傳達聲譽。然而，鑑於聲譽機制旨在取代黑名單和其他監督者相關協議，這意味著每個預授者的聲譽需要以用戶為單位進行維護，這非常複雜，可能與預期目的不符。

懲罰和提示的有效性

如上一節所述，不預先授予身份披露的SSLE機制會使基於聲譽的懲罰機制變得高度複雜，且可能無效。其他懲罰機制應該仍然有效，但需要根據上一節討論的實施方法謹慎實施。

理論上，SSLE 預確認機制下對預確認的需求應該基本保持不變。然而，考慮到 SSLE 預確認機制帶來的額外複雜性，我們預計提議者需要更高的預確認提示才能成為預確認者。

最後，如果選舉頻率發生變化並改變每個時期的預先確認的預期回報，那麼黑名單或訂單流損失的有效性也會受到影響，如前幾節所述。

3.2.b. 基於 L2 執行預先確認

兼容性

回想一下，這種類型的預確認可以由預協商者在其預確認槽開始時發出，該槽可以覆蓋一個或多個 L1 槽。回想一下，為了在其提議槽之前提供執行預確認，預協商者需要知道預協商前瞻。為了能夠公開預協商前瞻（或無需身份信息的預協商時間表），我們需要一種機制，強制/激勵所有預協商者公開其槽位，類似於第 3.2.a 節中描述的方式（通過公開其身份或使用零知識證明來證明其有資格參與特定槽位的預協商）。

可能的解決方案 - 使用監督者：在 L2 系統中，監督者可以設置預協商者角色披露的截止期限。這將強制所有預協商者在固定截止期限前披露其角色，例如在 SSLE 協議確定驗證者調度後的幾秒鐘內。截止期限過後，預協商者的時間段將固定，從而實現確定性的預協商調度。然而，這種方法引入了一個潛在的活躍性問題，監督者可能會拒絕及時披露其角色的預協商者。

為了緩解這種情況並消除對監督者的活性依賴，可以限制監督者僅進行罰沒，即罰沒任何未在特定截止日期前披露其角色的預協商者。這種替代解決方案本身也存在缺陷：前瞻機制不再具有確定性。如果前瞻機制不確定，則超過一個時間段的預確認窗口的執行預確認可能會被提議者在預確認窗口的較早時間段內披露其作為有效預協商者的角色而失效。因此，我們認為監督者強制執行的前瞻機制對於基於 L2 執行預確認而言是一種更可行的解決方案。

懲罰和提示的有效性

預計小費和懲罰的效果與討論的相同在上一節中介紹了 SSLE。

第 4 節：證明者提議者分離 (APS)

4.1. APS概述

在APS中，執行提議者的角色與其他驗證者職責（例如見證者）分離。這種分離使得更成熟的執行提議者能夠參與以太坊，同時還能減輕提議者對見證者的激勵溢出效應，因為見證者仍應屬於高度去中心化的驗證者集合。APS 的兩個主要設計是執行拍賣(EA) 和執行票證(ET)。

在這兩種設計中，執行提議者的角色都被分配給了經驗豐富的競爭實體。在執行提議者 (EA) 中，提議者是通過拍賣確定性地選出的；而在執行提議者 (ET) 中，提議者是通過事先購買彩票的抽籤方式隨機選出的（參見此處、此處、此處、此處）。

4.2. 預先確認分析

我們圍繞上述 APS 的兩個關鍵設計方面構建以下分析：

APS 拍賣何時進行。也就是說，提前多久選出N號槽的執行提議者。建議包括：
- 前面有很多插槽（例如 32 個插槽）。
- 在時隙N-1 N − 1的區塊被提出後t秒， Dt D 被執行（此處提出的提議；該提議表示為提前 2 個時隙的執行票，具有隨機性）。在此設計中，時隙N N的執行提議者是通過在時隙N-1 N − 1的區塊被提出後t秒提取的隨機數Dt D 來確定的。
- 在時段內通過即時拍賣（JIT）進行。
是否允許在協議內轉售提案權，即當選的提案人是否可以轉售其提案權。

對於此設計方面中每種類型的APS，我們概述了哪些類型的預先確認是兼容的，哪些是不兼容的。最後，在最後一小節中，我們討論了APS對懲罰和提示有效性的預期影響。

4.2.a. 兼容性：APS 拍賣運行時

就兼容性而言，預確認者將成為相應 APS 拍賣或抽籤的贏家。這為中心化網關鋪平了道路，這些網關可以在當前的以太坊設置中代表驗證者提供預確認，從而消除中間人，自己成為提議者，以最大限度地降低成本/最大化收益。因此，我們預計在 APS 下，Layer 1 執行提議者和預確認者將更加成熟，他們的選擇頻率將與他們存入的權益脫鉤。

如此處所討論的，在 RANDAO 是唯一隨機性來源的 APS 設計中，存在一種權衡，即所謂的多時隙 MEV 預防和與預先確認的兼容性。多時隙 MEV 是指作為多個連續時隙的提議者產生的 MEV 大於每個時隙單獨可用的 MEV 總和的現象（參見此處）。這裡提出的構造通過防止多時隙 MEV 同時仍然支持某些類型的預先確認來解決這種權衡。但是，它假設時隙N N的執行提議者是使用在前一個時隙的塊被提議後t秒提取的隨機性Dt D 來選擇的。下面，我們詳細闡述這些想法：

在提前多個時隙選定執行提議者的設計中，我們預期會看到各種類型的預先確認。這類設計的缺點是容易受到多時隙 MEV 的影響。
在區塊N-1 N − 1 的區塊提議後Dt D t秒，區塊N的執行提議者被選出的設計（如本文所述）可以避免多區塊 MEV，並且僅支持在區塊本身內發出包含和執行的預確認。較小的Dt D t可以為區塊 N 提供更多時間，並帶來更高價值的預確認。這些設計的缺點在於，它們假設在區塊N的區塊提議後提取了隨機性。
在時隙期間進行執行提議者選舉的設計（例如即時拍賣）可以防止多時隙 MEV，因為時隙N的執行提議者在知道時隙N + 1的執行提議者之前就提出了有效載荷。但是，我們並不期望這些即時選舉設計支持任何類型的提議者預先確認。

4.2.b. 兼容性：協議內轉售提案權

在設計中，執行提議者被提前選定很多個時段，但被允許在協議中轉售其權利，只要滿足以下條件之一，仍然可以支持預先確認：

存在強制執行機制，使得原始執行提議者可以強制執行購買提議權的提議者提供的任何預先確認。確切的執行機制至關重要：
- 強制執行特定交易列表的 L1 區塊頂部排序：原始提議者可以提供和執行所有類型的預先確認。
- 僅限 L1 包含：原始提議者可以提供
  - 納入預先確認。
  - 基於 L2 執行預確認，其中所有 L2 預確認交易 (1) 都需要原始提議者的簽名，並且 (2) 可以包含在單個 L1 交易中。
    但是，由於原始提議者無法強制排序，因此不支持 L1 執行預確認。
提議者承諾保留提議權。這可以是原始提議者，也可以是任何購買提議權的提議者。如果/當理性提議者認為通過提供預先確認而不是轉售提議權可以最大化收益，就會發生這種情況。關於理性提議者是否/何時會認為通過提供預先確認可以最大化收益的問題，本文已進行探討。

只要購買發生在該時段的提議時間之前（即不是即時的），具有在特定時段提議權利的最終提議者可以為該時段提供預先確認。

4.2.c. 懲罰和提示的有效性

削減的有效性將取決於預先授予抵押品的要求。雖然所有預確認協議都適用，但尚未確定的關鍵APS問題之一是對執行提議者以及預確認者的抵押品要求。如果通過APS強制執行抵押品要求，這些抵押品很可能會重新用於提議者的承諾，包括預確認。無論對執行提議者的抵押品要求是否在協議中強制執行，某種形式的預授予註冊合約都將存在，以管理預授予權利和削減。反過來，這意味著黑名單和基於聲譽的訂單流限制也將成為可能。

由於 APS 旨在控制/隔離提議者中心化的影響，APS 很可能導致少數能夠參與相應 APS 拍賣的提議者更頻繁地被選舉。每個提議者對應一個地址，這將帶來更有效的訂單流和黑名單激勵機制。然而，提議者可以選擇創建多個參與 APS 選舉的地址，以隔離因執行惡意操作而造成的聲譽損失。目前尚不清楚這種策略是否能夠有效維護執行惡意操作的提議者所擁有的非惡意地址的聲譽。這是一個聲譽機制的抗女巫攻擊問題，此前已有詳細討論。

對此的一些緩解措施包括：

要求 APS 提議者維護與身份綁定的公鑰，以便用戶進行審查和審計。身份綁定密鑰是一種典型的抗女巫攻擊措施。
允許 APS 提議者在可信執行環境 (TEE) 中運行其區塊構建代碼，具體內容請見此處和此處。這可以最大限度地減少提議者執行惡意操作的攻擊面，並可為 APS 提議者提供最低聲譽。

第五節提案者與建設者分離（ePBS）

5.1. ePBS概述

在PBS（提議者-構建者分離）中，提議者將構建執行負載的權利拍賣給被稱為構建者的複雜實體，以換取小費。在這種設置下，信標鏈提議者和構建者之間的公平交易——即確保提議者在且僅當包含構建者的有效負載時才能收到小費——由一個被稱為中繼者的可信第三方進行調解。

在ePBS （Enshrined Proposer-Builder Separation）協議中，拍賣在協議內進行，無需協議外的中繼器來確保公平交易。信標提議者直接接收來自構建者的出價，幷包含最高出價者提交的執行有效載荷的哈希值。隨後，構建者公佈完整的執行有效載荷。與當前的以太坊協議相比，ePBS 引入了額外的一輪證明機制，由驗證者委員會來證明構建者是否正確公佈了有效載荷。

5.2. 預先確認分析

我們對所有類型的預先確認進行集體研究，因為它們在兼容性以及懲罰和提示的有效性方面表現出相似的特徵。

兼容性

影響兼容性的關鍵因素有：

通過 ePBS 拍賣提案權是否是強制性的。
存在可強制執行的區塊約束，這些約束可由信標提議者指定，所有參與 ePBS 拍賣的構建者都必須遵守。此類強制執行機制過去曾被提及，但尚未確定具體的設計方案。強制構建者遵守提議者指定的區塊約束的一種可能機制是強制構建者進行質押（如 ePBS EIP-7732 中所提議的），並懲罰任何發佈不遵守區塊約束的區塊的構建者。

如果拍賣提議者權利是強制性的，並且存在可執行的區塊約束，那麼信標提議者可以提供所有形式的預先確認（有關哪些類型的執行機制支持所有類型的預先確認的具體細分，請參閱第 4.2.b 節）。如第 1 節所述，我們不考慮 ePBS 構建者的預先確認，因為構建者並不控制獨佔的提議權。

如果拍賣提議者權利是強制性的，且不存在可執行的區塊約束，則預確認機制將不兼容。具體而言，信標提議者無法安全地發佈預確認，因為最終贏得拍賣的建造者沒有義務履行這些義務。

如果拍賣是可選的，信標提議者保留髮布所有類型預確認的能力。如果存在可執行的區塊約束，提議者可以選擇自行構建區塊或拍賣構建權。如果不存在可執行的區塊約束，提議者必須自行構建區塊。

懲罰和提示的有效性

當拍賣可選時，我們預期懲罰和提示的有效性將與以太坊原始設計中的預確認機制相同。這是因為預確認者的選擇遵循相同的流程，並且他們擁有相同的可用空間來發布預確認。

在可執行區塊約束的情況下，我們也預期兼容的預確認設計將具有與原始以太坊設計中的預確認類似的懲罰和提示有效性。關鍵區別在於可用區塊空間的大小。如前文所述，區塊空間的減少可能會影響每個 slot 預確認的預期獎勵，進而影響訂單流損失或黑名單等懲罰機制的有效性。預期獎勵的增加或減少取決於提示的增加是否足以抵消區塊空間的減少。

來源

免責聲明：以上內容僅為作者觀點，不代表Followin的任何立場，不構成與Followin相關的任何投資建議。

喜歡

評論

面向未來的預先確認

介紹

分析總結

文章提綱

準備工作

預先確認的類型

當前以太坊設計中預先確認的特點

懲罰

獎勵/小費

分析每個生態產業園區的框架

第一節 納入清單

1.1. FOCIL 和 AUCIL 概述

1.2. 預先確認分析

1.2.a. 納入預先確認

1.2.b. L1執行預先確認

1.2.c. 基於 L2 執行預先確認

第 2 節 多個併發提議者（MCP）

2.1. MCP概述

2.2. 預先確認分析

2.2.a. 納入預確認

2.2.b. 執行預確認

第三節 單一秘密領導者選舉

3.1. SSLE概述

3.2. 預先確認分析

3.2.a. 納入和 L1 執行預先確認

3.2.b. 基於 L2 執行預先確認

第 4 節：證明者提議者分離 (APS)

4.1. APS概述

4.2. 預先確認分析

4.2.a. 兼容性：APS 拍賣運行時

4.2.b. 兼容性：協議內轉售提案權

4.2.c. 懲罰和提示的有效性

第五節 提案者與建設者分離（ePBS）

5.1. ePBS概述

5.2. 預先確認分析

來源

第一節納入清單

第 2 節多個併發提議者（MCP）

第三節單一秘密領導者選舉

第五節提案者與建設者分離（ePBS）