State Lock 拍賣：邁向協作區塊建設
非常感謝Quintus 、 Louis和Shea的討論和評論為本文提供了靈感。
概述
由於MEV-Boost 拍賣的公開首價性質，搜索者有動力進行垂直整合，成為“搜索者構建者”，以“更具戰略性”出價。這種旨在在 MEV-Boost 拍賣中獲得優勢的垂直化產生了不幸的後果，即大大提高了統計套利的進入壁壘，並因此造成了不利的市場結構，新的“搜索者構建者”在其中從其他建設者處批量購買訂單流，並補貼區塊作為有效的“廣告支出”，以達到與現有區塊建設者的訂單流平價。消除“戰略投標”這一優勢的嘗試主要集中在將拍賣修改為密封投標格式，但所有這些都未能實現，因為它們在缺乏 MPC 等私人且可信的承諾技術的情況下引入了新的共謀向量， FHE 和 TEE。
這篇文章大量借鑑了分佈式系統文獻，概述了一項在 mev-boost 拍賣中啟用“鎖定狀態”能力的提案，並提供了對該“鎖定狀態”的可見性的後續功能。這種方法的最終結果是，區塊建造者不再因建造區塊其餘部分的不確定性而有效地“管道停滯”，這為“協作區塊建設”打開了大門。在分佈式系統方面，我們正在利用可見性為以太坊分佈式狀態機創建一個“引導腿”去中心化多版本併發控制系統。
這種方法的主要優點是，它為在這些高速套利中競爭的搜索者保留了基本的隱私和出價更新能力，與以前的“車道”方法相比，支持更通用的套利，並且可以輕鬆部署到當前市場。主要缺點是它在區塊頂部創建了單筆交易套利的“偽神殿”，並提供了新的審查和惡意攻擊向量。由於該提案只是一個草圖，因此關於如何有效地定價鎖定狀態的成本、對搜索者出價策略的影響以及如何將拍賣推廣到鎖定一組狀態的能力，仍然存在很大的未知數。
國家鎖定拍賣的理想房產
雖然並不詳盡，但一些立即明顯的有利特性：
- 鎖櫃安全- 在確認區塊之前洩露鎖定狀態的人的地址會創建有針對性的 DoS 向量。
- 投標更新能力——提交狀態鎖的搜索者應該能夠更新其事務的參數，只要它不修改狀態訪問列表。
- 鎖定狀態可見性- 鎖定狀態的存儲槽應該對區塊構建者公開可見。
- 保證鎖定支付- 無論搜索者是否更新出價，支付交易都應包含在鎖定狀態的塊中。
- 搶注阻力——確保鎖定大量狀態的成本過高，以防止惡意破壞。
- 爭用意識- 缺乏的代價應該反映寫入該狀態的興趣程度。
訪問列表
在本文的大部分內容中，我們將要鎖定的狀態稱為“訪問列表”。在EIP-2930的上下文中，狀態訪問列表A A被定義為元組序列：
在哪裡：
- \text{address}地址是與交易交互的合約或外部擁有賬戶（EOA）的以太坊地址。
- [\text{storageKey}_1, \text{storageKey}_2, \ldots] [ storageKey 1 , storageKey 2 , … ]表示交易將訪問的指定合約存儲中的存儲密鑰列表。
附錄 A中顯示了交換的訪問列表示例。
提案：接力運行單鎖拍賣
將搜索者表示為S S ，中繼者表示為R R ，部分區塊構建者表示為PB P B ，拍賣過程如下：
- 公開拍賣：
在進入時隙的截止時間T_{cutoff} T cutoff秒之前，搜索者通過兩個不同的事務向R R提交其狀態鎖承諾：
\text{提交狀態承諾}(n, A, tx_{狀態}, tx_{付款}, b)SubmitStateCommitment ( n , A ,交易狀態,交易支付, b ) _ _ _ _ _ _ _ _ _ _ _ _在哪裡
- n n ：槽位號。
- A A ：訪問列表。
- tx_{state} t x stat e ：狀態訪問事務。
- tx_{ payment} t x payment ：確保覆蓋鎖定成本的支付交易。
- b b : 出價，
提交後R R驗證：
- b b必須滿足或超過基於A A的鎖定儲備成本。
- 鎖定儲備成本由下式確定：
\text{鎖定成本}(A) = C \times |A|鎖定成本( A ) = C × |一個|在哪裡：
- C C表示每個存儲槽的固定成本， |A| |一個|是tx_{state} t x s t a t e的訪問列表A A中存儲槽的計數。這種方法天真地使鎖定大量狀態變得更加昂貴，但遠非理想的定價規則。
- tx_{state} t x stat e應該是訪問列表等於A A的事務。
- tx_{ payment} t x payment應該是從沒有調用數據的 EOA 向驗證器付款的交易。
- ( tx_{state} t x stat e , tx_ { payment} t x payment t )在區塊頂部一起模擬，支付b b承諾的金額。
- 獲獎者選擇：
- 在T_{cutoff} T c u t o f處， RR選擇最高出價：b_{max} = \max(\{b_i | b_i \geq \text{LockCost}(A_i), \forall i \in S\})b m a x = max ( { b i | b i ≥ LockCost ( A i ) , ∀ i ∈ S } )
- R R然後向調用以下命令的任何人公開與 b_{max} b m a x關聯的獲勝訪問列表A_{ max} A m a x ：
- 投標更新和部分區塊提交：
選擇獲勝者後可能會發生兩項主要活動：
獲勝的搜索者addr_{max} a d d r m a x可以通過以下方式更新其狀態訪問事務：
\text{UpdateStateCommitment}(n, addr_{max}, A_{max}, tx_{state\_new}, b_{new})UpdateStateCommitment ( n , a add r max , A max , t x state _new , b new ) _ _ _ _ _ _ _ _ _ _ _ _ _ _在哪裡：
- n n必須等於與addr_{max} a d d r m a x中標出價相關的最新槽位
- R R必須驗證更新後的狀態訪問事務tx_{state\_new} t x s t a t e _new具有等於A_ {max} A max的訪問列表。
- 並且支付交易tx_{ payment } t x payment隱式保持不變。
部分塊構建器查詢GetLockedState(n) GetLockedState ( n )以獲得A_ { max } A max ，根據此信息構建部分塊，並使用以下命令提交它們：
\text{SubmitPartialPayload}(TX_{列表}, b_{PB})提交部分有效負載（ TX列表， bPB ） _ _ _在哪裡：
- TX_{list} T X l i s t包含交易列表
- b_{PB} b P B表示部分塊的出價。
當接收到部分有效負載提交時，中繼器 ( RR )執行以下步驟：
- 1.交易組合： RR創建
\text{CollabBlock = }(tx_{狀態}, tx_{付款},TX_{列表})CollabBlock = ( t x狀態, t x付款, TX列表) _ _ _ _ _ _ _ _ _ _ _ _ _- 2. 區塊驗證： R R模擬CollabBlock C o l l a b B l o c k執行通常的區塊驗證，並確保組合區塊出價等於b_{max} + b_{PB} b m a x + b PB 。
- 3. 支付處理： RR製作、簽名並插入支付交易以支付驗證者和部分區塊構建者
- 4.狀態根計算：如果驗證成功， R R計算塊的狀態根和相關字段，以確保與最新的 EL 和 CL 規範兼容，插入具有最新負載屬性的信標塊，並可供
getHeader調用驗證器。
以下是藝術家對上述拍賣過程的再現。
附錄 B中提供了繼電器規格變更的粗略草圖。
分析
這種方法滿足了我們狀態鎖定系統的大部分核心目標：確保Locker 安全、出價更新能力、鎖定狀態可見性和保證鎖定支付，初步嘗試抗搶佔，並且不嘗試爭用感知。更進一步，鎖定狀態可見性通過允許構建者更自信地將部分塊附加到塊頂套利，為協作塊構建奠定了基礎。該設計故意避免在SubmitPartialPayload提交部分負載期間檢查衝突事務，以避免阻塞任何其他也打算觸及有爭議鎖定狀態的事務。 BBlock 構建者可以自由發送有衝突的區塊，但他們現在可以提前意識到衝突，這對當今的市場來說是一種進步，並創造了參與的動力。搜索者也被激勵參與，因為這使得進入 stat arb 變得更容易，並增加了區塊包含的可能性。中繼會承擔額外的工作，因此會產生額外的成本，但這種方法使通過迂迴激勵中中繼之間的第二次價格拍賣獲利的能力正常化。
一個值得關注的領域是轉向更加以中繼為中心的區塊構建和標準化構建中繼。我的偏見和謹慎的初步反應是，我們應該接受這一趨勢，只要它不會就構建哪些區塊產生意見，或者給一方帶來不平等的優勢。從這個 POV 來看，中繼將繼續容納更多與拍賣相關的邏輯，作為構建者網絡中值得信賴的第三方，每一個額外的邏輯都理想地有助於促進更多協作的區塊構建。
這種方法不需要更改協議，並且可以與當前的 mev-boost 拍賣並行運行。此外，它創建了一種“通道”方法，而不將其限制為單一套利類型，但並未完全通用，因為它將塊頂套利限制為單個交易。因此，探索捆綁支持是未來的理想探索，但如果天真地進行，可能會通過提交整個區塊的新途徑造成額外的複雜性。
然而，採用這種方法存在一些複雜性。一是它存在冷啟動問題。如果在發佈時只有一名搜索者具備了在此次拍賣中競爭的能力，那麼他們很可能會在短時間內以非常便宜的價格佔據主導地位，具體取決於鎖定儲備成本價格。其雙重意義在於，只需要一名搜索者的參與就能讓其餘搜索者滾雪球。另一個需要改進的地方是，這種設計只關注單個繼電器的情況，但實際上，有很多繼電器都是獨立工作的。一種想法是同步可能並不重要，因為投標取消是一個類似的無法保證的交叉中繼問題。在多中繼場景中，最好的情況是每個人都同意要鎖定的狀態。在最壞的情況下，每個都有不同的狀態集和為所有潛在路徑構建的部分塊構建器。這會產生更多的工作，但至少它是可並行的，並且仍然比現狀有了顯著的改進。未來探索的另一個領域是，考慮到其更復雜的驗證邏輯，這種方法如何與樂觀中繼一起發揮作用。
最後，這裡最重要的未知因素是鎖定定價機制和國家承諾對搜索者策略的影響。鎖定定價機制非常不明確，而且很可能會出現滑稽的錯誤；因此，後續工作應嘗試以分析性和對抗性的方式對此進行推理。將歷史狀態訪問納入定價機制也很困難，因為如果天真地完成，這將是一個非常大的更新向量，並且無法像基本費用所依賴的那樣插入到區塊中。弄清楚這一機制的進展也將有助於評估這次拍賣的審查向量有多大，並更具體地梳理出激勵措施。還應該考慮為進行統計套利創建新的前期成本的影響，但在最壞的情況下，搜索者可以有效地取消他們的交易並簡單地支付費用，而不需要他們承諾以他們想要的價格進行大量交易。不再根據其他領域的信號發現吸引力。
附加組件
- 可以使用隨機的關閉時間來阻止最後一秒的投標。但在多個獨立接力賽的情況下，這是以每個接力賽產生不同的獲勝者為代價的。
- 國家鎖定拍賣可以採用第二價格規則來確定付款，鼓勵真實的投標。這可以通過將退款交易插入到區塊中以獲取差價來實現，成本為 21k 天然氣。
- EIP-2930 事務類型可用於狀態訪問事務，但它們確實支持對非訪問列表提供的存儲槽的訪問，因此不會啟用盲目信任。總的來說，朝這個方向前進將有助於簡化所有未來的協作建設工作。
- 中繼中的塊結構提供了插入無條件包含列表的理想時間。
- 保持競價開放，以將狀態訪問交易替換為您自己的交易，只要它觸及與原始狀態相同的狀態即可。與此相關的激勵因素還不清楚。
- 允許並行對每個重疊訪問列表進行拍賣。
- 這裡的一個挑戰是，代表對兩個池進行套利的訪問列表可以分為兩次拍賣來對每個池進行套利，並且單獨鎖定每個池的成本可能不會像有人試圖同時鎖定兩個池那樣高。因此，概括需要某種形式的組合拍賣，允許您在贏得另一次拍賣時有條件地出價。
- 另一個挑戰是，在單次拍賣的情況下，中繼可以確保獲勝的交易將產生特定的訪問列表。在雙重拍賣的情況下，我們不能再僅通過查看第一個交易的訪問列表來確定第二個交易的訪問列表。以第二筆交易為例，該交易以交易 1 中修改的餘額為條件。雖然我們應該能夠檢測到這種讀寫衝突的可能性，但它很可能不夠穩定，無法連續堆疊這些拍賣某個東西的上放。中繼可以模擬第一次拍賣獲勝者之上的第二筆交易，但這並沒有給我們足夠的時間來進行多次拍賣。最有可能的是，需要對事務寫入和讀取狀態的能力施加一些限制來解決此問題。
ePBS 的可行性
將這種方法與未來的“ePBS”之類的方法集成的挑戰是，我們需要將拍賣轉移到證明者層，這天真地需要額外的同步期。網絡必須就獲勝訪問列表“是什麼”達成一致，更不用說這在協議層激勵的 p2p 遊戲了。
反對將此類內容移入協議的一個原因是，從驗證者的角度來看，它不會影響網絡上的資源，或多或少的鎖不會影響執行驗證者職責所需的資源需求。此外，鎖定拍賣並不會對網絡造成活躍風險。如果拍賣失敗，那麼我們就會回到當前的區塊構建狀態。支持將其轉移到協議中的一個論點是，拍賣從協議的狀態中產生收入。
結論
該提案勾勒出一種相對粗糙的機制設計，用於拍賣以太坊上的區塊頂部狀態鎖，並實現區塊構建器市場中的協作。雖然不是最終解決方案，但它為狀態鎖實驗創建了一個理想的界面，並解鎖了區塊構建市場的新方面，這可能會幫助我們擺脫當前的局部最大值。假設有一個理想的鎖定定價機制，這種方法可以迅速投入使用，並使我們朝著更好的建築商市場結構邁出一步。
附錄
A. 訪問列表示例
訪問列表示例
- tx 哈希 0x84ba67793c7aa0140ae9f7cbc58a7bec04099672d467dfe280ec5987b5f26b46將
Wrapped Ether交換為Porktoshi Nakamoto。
通過 創建 通過這些python 腳本創建。
[ { "address" : "0xa65303cbe1186f58dda9cf96b29e1e89ae90b165" , "storageKeys" : [ "0x0000000000000000000000000000000000000000000000000000000000000008" ] } , { "address" : "0xb39bc86ac75118011f646276fca48d56e54c4854" , "storageKeys" : [ "0x000000000000000000000000000000000000000000000000000000000000000d" , "0x7e3bb96fe9c3e8bf8baff39136a5e5778a1f21be90df3270983ce535ed884516" , "0x9db3014a7ecc5c8baca43505a03b4e7e24c2ec389a973d5605a299f04defc730" ] } , { "address" : "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2" , "storageKeys" : [ "0x377eec8667584e30e85471441b46e69393e5f35d2b63a0b4c26a5b1f6d059aa5" ] } ]這裡
- 0xC02aaA...3C756Cc2是 WETH 代幣合約
- 0xb39BC8...e54C4854是 PORKTOSHI 代幣合約
- 0xA65303...AE90B165是 PORKTOSHI/WETH Uni V2 池
根據 PORKTOSHI 合約的存儲密鑰，我們可以看到存在一些非標準 ERC20 行為，源代碼也驗證了這一點，但這不是重點。
B. 繼電器規格粗略變更
前面幾節解釋了驗證規則和內部邏輯。
relay_SubmitStateCommitment
允許參與者提交特定時段的國家承諾。
接受：
-
n（槽位號）：表示槽位號的整數。 -
A（訪問列表）：詳細說明事務要與之交互的狀態鍵（address和storageKeys）的對象數組。 -
statetx（簽名交易）：簽名交易的十六進制字符串。 -
paymenttx（簽名交易）：簽名交易的十六進制字符串。 -
b（投標價值）：代表投標價值的整數，以 wei 為單位。
-
返回：確認提交。
relay_GetLockedState
獲取與指定槽位的中標相關聯的訪問列表。
接受：
-
n（時隙號）：表示請求訪問列表的時隙號的整數。
-
返回：
- 訪問列表 (
A)：詳細說明指定槽最高出價的狀態鍵（address和storageKeys）的對象數組。
- 訪問列表 (
relay_SubmitPartialPayload
使部分區塊構建者能夠提交一組交易作為部分區塊提案。
接受：
-
txList（交易列表）：表示交易的十六進制字符串數組。 -
b（部分區塊的出價）：代表部分區塊的以 wei 為單位的出價的整數。
-
返回：部分負載提交的確認。
