如何實現區塊構建者角色的去中心化？

本文主要圍繞Vitalik 最近的SBC MEV 研討會演講而構建，並提供進一步的分析。

原文標題：《如何實現區塊構建者角色的去中心化？這裡有兩種方法》（Decentralizing the Builder Role）

撰文：Jon Charbonneau

引言

快速回顧——本報告的一個關鍵主題是Vitalik Buterin 在《終局遊戲》一文中的想法，即所有前進道路似乎都通向：

• 中心化區塊生產

• 去中心化和去信任的區塊驗證

• 繼續提供抗審查

生產者- 構建者分離（PBS）試圖將中心化與構建者隔離（遠離驗證者），然後以太坊添加盔甲（例如crList）以減輕構建者的審查權力。構建者自然會很老練，所以懸而未決的問題主要是他們的中心化程度。我們是在說1 個構建者？還是10 個？

一個中心化構建者仍然不理想，那麼我們能做得更好嗎？解決這個問題有兩種方法：

• 擁有許多構建者的去中心化市場—— 確保構建者市場在沒有根深蒂固的參與方的情況下具有競爭力。許多構建者競爭並只獲得很小的利潤。這個角色變得非常商品化。這需要解決諸如排他性訂單流之類的問題，否則這些問題可能會鞏固單個構建者。

• 去中心化構建者角色本身—— 使獲勝的構建者本身成為去中心化的協議。一組去中心化的參與者都有助於構建一個給定的區塊。

本報告主要圍繞Vitalik 最近的SBC MEV 研討會演講而構建。我將把它分解並提供進一步的分析。

去中心化的構建者能勝出嗎？

這裡實際上有兩個潛在的問題：

• 技術可行性——我將介紹一些可行的路徑（存在其他可能性，並且正在積極探索中）

• 競爭力——用戶真的想使用它嗎？或者一個中心化構建者總是會在功能和效率上勝過去中心化構建者？

去中心化什麼？

中心化構建者很容易。下面考慮了一些可以去中心化的分佈式構建者，需要在許多搜索者和用戶之間聚合捆綁和交易：

• 算法- 構建者運行算法來聚合搜索者的捆綁包和其他交易，然後自己填寫區塊的其餘部分。該算法及其輸入可以分散。 （請注意，這裡假設分佈式構建者僅運行一種算法的簡單情況。實際上，分佈式構建者中的不同參與者可能在運行不同算法時貢獻區塊的不同部分。）

資料來源：基於Vitalik Buterin 的圖片

• 資源 – 資源需求將顯著增加，尤其是使用Danksharding。區塊將攜帶更多數據並且構建起來更加複雜→構建它們的帶寬和硬件要求更高。不需要一個節點來構建和分發整個區塊，而是可以在多個節點之間拆分工作。

• 額外的構建者服務——構建者可以發揮創意並提供新的服務，例如交易預確認。為了使分佈式構建者取得成功，他們需要提供與中心化構建者相比具有競爭力的服務。

• 訪問訂單流（orderflow）——將訂單流發送給單個構建者非常簡單，並且可以為用戶帶來好處。也許他們承諾不搶跑你的交易，他們可以在你後面給你一些回扣。在潛在的許多參與者之間分散對訂單流的訪問是比較棘手的。

• 隱私——同樣，相信您的訂單將私下執行的構建者是最容易的，因此您可以將其發送給他們。分佈式構建者需要一種方法來提供交易隱私，同時在此過程中還包括許多去中心化方。

• 跨鏈執行——分佈式構建者需要一種與外部參與者協調以捕獲跨鏈MEV 的方法（例如，如果鏈Y 上的交換將以原子方式完成，則僅在鏈X 上完成交換）。

挑戰

如果我們想在整個區塊生產供應鏈中避開受信任的第三方，有幾個障礙需要克服。我將在這裡解決的一些挑戰包括：

如何保護搜索者免受MEV 竊取？

如果建設者看到搜索者提交給他們的捆綁包，他們可以復制交易，然後用他們自己的地址替換搜索者的地址。構建者在不獎勵搜索者的情況下捕獲了MEV。

神聖（enshrined）PBS 和MEV-Boost（加上中間可信中繼）中使用的提交披露方案從提議者←→ 構建者關係中消除了同樣的MEV 竊取威脅，但對於搜索者←→ 構建者來說，這是一個未解決的問題。搜索者目前只信任構建者，但信任不是可擴展的解決方案。

如何允許聚合器機制組合搜索者輸入？

保護搜索者免受MEV 竊取意味著他們的捆綁包不能以明文形式發送。但是，如果它們不在明處，那麼構建者如何聚合它們呢？

如何保證聚合器機制能夠真正發布這個區塊？

捆綁內容最終必須明確。從密文→明文的過程是什麼，我們如何在沒有信任假設的情況下實現這一目標？

如何保護搜索者免受聚合者+ 提議者勾結？

請注意，這並不是構建分佈式構建者所面臨的挑戰的詳盡列表。還有其他懸而未決的問題（例如，您如何防止分佈式構建者受到他們被迫模擬的大量不良捆綁包的DDOS 攻擊？）和未知的未知數。

想法1 – 可信硬件

一種方法利用可信硬件- TPM（可信平台模塊）。排序如下所示：

在解密區塊之前，TPM 必須確信兩件事：

• 提議者簽名- 這種對區塊頭的承諾（沒有看到區塊體）防止提議者竊取MEV。如果提議者在構建者區塊體被公開後（通過提議替代區塊）試圖為自己竊取MEV，任何人都可以提出他們最初的承諾。這證明提議者在相同的區塊高度簽署了兩個區塊→他們被削減了。

• 提議者簽名的可用性證明- 防止聚合者+ 提議者串通。提議者的承諾存在是不夠的——它必須是可用的。如果只有聚合器收到承諾，他們可以簡單地永遠隱藏它，允許提議者提出替代的MEV 竊取區塊。 TPM 必須確信最初的提議者簽名實際上是公開的。

有幾種方法可以證明提議者簽名的可用性：

• 證明者- 驗證者可以證明看到提議者簽名，然後TPM 可以檢查提議者和這些證明者簽名。這需要更改以太坊協議。

• 低安全性實時數據可用性預言機——像Chainlink 這樣的東西可以證明簽名存在並將被重新廣播的事實。

• 聚合器內的M of N 假設- 聚合器本身可以是分佈式M of N 協議。聚合器協議中可能存在閾值投票，您對此有一個誠實的假設。

想法2 – 合併不相交的捆綁包和順序拍賣

合併不相交的捆綁包

這種方法需要M of N 聚合器，但我們可以擺脫TPM。該過程如下所示：

• 搜索者發送加密到一個閾值密鑰的捆綁包。捆綁包包含訪問列表（他們訪問的帳戶和存儲槽的列表）和正確性SNARK（注意快速生成此內容的技術複雜性）。

• 聚合器合併不相交的捆綁包，使總出價（bid）最大化。 （我們在這裡只討論聚合不相交的出價，但有可能進一步改進這一點。）

• 聚合器必須計算狀態根

最後一步很棘手。計算狀態根需要清楚地看到交易，或者至少看到它們的狀態更新。然而，即使看到狀態更新也可能足以進行MEV 竊取。對於何時計算狀態，我們有幾個選項：

• 讓一個聚合器節點解密然後計算狀態。但是，他們可以與提議者勾結。

• 只有在提議者承諾支持接收到的任何區塊和狀態根之後，才計算狀態根。這種設置將利用EigenLayer – 提議者讓自己受到額外的削減條件才能參與。提議者發送一條鏈下消息，承諾他們將依次生成的唯一區塊是包含這組捆綁包（無論它們是什麼）的區塊。只有在提議者做出承諾之後，捆綁包才會被解密，併計算狀態根。如果提議者違反了這一承諾，那麼他們將被削減。

請注意，對於此EigenLayer 構造，也可以避免前面提到的SNARK 要求。這裡的提議者可以預先提交一個替代區塊或替代區塊組合，如果提交給他們的區塊或替代區塊組合被證明是無效的。然後可以使用一個欺詐證明來檢查第一個區塊組合的無效性。

順序拍賣

EigenLayer 技術可以直接用於不相交的捆綁合併，或者它可以依賴於每個插槽內的多輪順序拍賣。 （請注意，如果需要，也可以在此順序構造中避免SNARK 要求。）

例如，以下可能發生在一個區塊中：

第1 輪

1. 提議者簽署一個EigenLayer 消息，預先同意一些交易（包括捆綁1），從而在這一輪中最大化他們的出價以啟動區塊

2. 構建者公佈該區塊的這一部分

3. 提議者發布狀態差異

第2 輪

4. 提議者簽署一條EigenLayer 消息，預先同意額外的交易（包括捆綁2），從而在本輪中最大化他們的出價以繼續這個區塊

5. 構建者公佈該區塊的這一部分

6. 提議者發布狀態差異

第3 輪…

一個缺點是這種合併可能不是最理想的。例如，提議者可能已經預先同意捆綁包1，然後他們收到了與捆綁包1 衝突的更有利可圖的捆綁包2。他們將不得不拒絕此捆綁包2。

具有相同訂單流的中心化構建者可以看到所有交易，當他們在插槽末尾構建區塊時可以包含捆綁包2（因為他們沒有預先同意捆綁包1）。

另一個潛在的缺點- 順序拍賣可能會使非原子MEV 變得非常困難，因為如果世界狀況發生變化，搜索者將無法取消或更新他們的出價（一旦承諾）。如果您需要在交易被包含之前10 秒以上提交交易，那麼如果您保留更新出價的能力，您將無法承擔盡可能多的風險。

但是，該示例假定相同的訂單流。實際上，由於它提供的保證，這種分佈式構建者可能能夠在接收更多訂單流方面勝過中心化構建者。更好的保證→ 更多的訂單流→ 構建最有利可圖的區塊（即使有其他缺點）。然後，由於分佈式構建者始終提供最高價值的區塊，因此提議者選擇這種結構（切斷自己接受其他構建器的區塊）將具有經濟意義。

為了取得成功，分佈式構建者提供的價值可能需要超過它帶來的缺點（包括效率較低的合併和非原子MEV 的挑戰）。

區塊構建post-Danksharding

Danksharding 使驗證者的節點要求較低。單個節點只負責下載區塊的一部分。

然而，最初提出的設計將有意義地增加構建以太坊區塊的硬件和帶寬要求（儘管驗證者總是可以以分佈式方式重建）。那麼問題是我們是否甚至可以以分佈式方式進行初始構建。這將消除對單個高資源實體構建完整區塊、計算所有KZG 承諾、連接到許多子網以發布它，等等。

（注意：這個架構是否會使用子網或類似DHT 的開放研究問題，但我會在這裡假設子網）。

實際上很有可能以分佈式方式構建。分佈式糾刪碼甚至沒有那麼難。

首先，包含每個數據交易的人負責對其進行編碼並將blob 區塊傳播到子網和數據可用性網絡。

當聚合器選擇包含哪些數據交易時，他們可以使用實時DA 預言機。聚合器不能只自己進行數據可用性採樣(DAS)，因為當只有一方進行DAS 時，這並不安全。所以一些分佈式預言機需要下載整個東西。

然後網絡可以從這裡填寫列。請記住，數據在此2 D 方案中得到擴展。例如，每個blob 是512 個chunks，但它被擦除編碼為1024 個chunks。然後擴展也垂直運行。例如，您在此處說圖像中有32 個blob，然後垂直擴展為64 個blob。多項式承諾在每行水平和每列垂直運行。

資料來源：Vitalik Buterin

KZG 承諾

由於KZG 承諾的線性，你可以填寫這些列，這將用於以太坊的分片設計。

KZG 的承諾(com) 具有線性關係。例如，您可以說com (A) + com (B) = com (A+B)。

你在證明中也有線性。例如，如果：

• Qᴀ 證明A = 在某個坐標z 處的某個值，並且

• Qʙ 證明B = 在同一坐標z 處的某個值，則

• 您可以對Qᴀ 和Qʙ 進行線性組合，這本身就是證明A 和B 的相同線性組合在相同坐標z 處具有正確值

更正式地說：

• 讓Qᴀ 證明A (z) 和Qʙ 證明B (z)

• 然後，cQᴀ + dQʙ 證明(cA + dB)(z)

這種線性屬性允許網絡填入所有內容。例如，如果您有第0 列中第0-31 行的證明，那麼您可以使用它來生成第0 列中第32-63 行的證明。

只有KZG 具有這種承諾線性和證明線性（IPA 和Merkle 樹，包括SNARK 的Merkle 樹不能同時滿足這兩個）。

要更深入地了解以太坊的2 D KZG 方案，您可以查看我的以太坊報告或Dankrad 最近的KZG 演講。 Vitalik 的這篇研究文章‌還談到了將KZG 與IPA 用於DAS 的考慮因素。

這裡的TLDR 是KZG 有一些非常好的屬性，允許分佈式區塊構建和重建。您不需要任何一方來處理所有數據、擴展所有數據、計算所有KZG 承諾並傳播它們。它們可以為每一行和每一列單獨完成。如果這樣做了，我們就沒有剩餘的超級節點要求：

資料來源：Dankrad Feist 和Vitalik Buterin

非KZG 替代選擇

如果我們無法實現所有KZG 魔法，那麼這是下一個最佳選擇。

行承諾的前半部分只是blob，所以沒有問題。然後，構建者必須提供其餘部分和一些列承諾。

然後這些承諾必須匹配。所以jᵗʰ 坐標處的iᵗʰ 行承諾= iᵗʰ 坐標處的jᵗʰ 列承諾。

更正式地說：

• 構建者必須提供行承諾R₁…Rₕ 和列承諾C₁…C?，其中Rᵢ(xⱼ) = Cⱼ(xᵢ)

• 以及承諾等價的證明

• 這可以像討論的那樣以分佈式方式完成，但請注意，這樣做更難：

• 前面描述的KZG 方法- 可以在一輪中完成。構建者只檢查所有blob 然後發布。網絡在不涉及構建者的完全獨立的過程中填充行。

• 此處的分佈式方法- 至少需要兩輪協議。構建者需要參與。

額外的構建者服務- 預先確認

以太坊區塊時間很慢，用戶喜歡快速的區塊時間。以太坊做出這一犧牲主要是希望支持一個大型去中心化驗證者集——Vitalik 在這裡寫過的權衡空間。但是我們能做到兩全其美嗎？

以太坊rollup 用戶已經了解並喜歡這些預先確認。構建者創新也許能夠在基礎層提供類似的服務。

例如，構建者可以同意：

• 如果用戶發送優先級費用≥ 5 的交易，構建者會立即發送一個可執行的簽名消息，同意將其包含在內。

• 如果用戶發送優先級費用≥ 8 的交易，構建者甚至提供後狀態根。因此，較高的優先級費用迫使交易以某種順序被包含在內，從而使用戶可以立即知道該交易的結果是什麼。

如果構建者不履行他們的承諾，他們可能會被削減。

在具有並行化EVM 的未來，您還可以通過預先確認獲得更高級的信息。例如，只要用戶關心的狀態沒有改變，即使在給出預先確認之後，構建者也可以重新排序一個區塊中的一些交易。

分佈式構建者可以提供預先確認嗎？

是的。分佈式構建者可以運行一些內部共識算法，例如具有快速出塊時間的Tendermint。構建者可能會因以下原因受到處罰：

• Tendermint 機制內的雙重確定性

• 簽署與Tendermint 機制認同的內容不兼容的區塊

請注意，為了在此處獲得最佳安全性，需要對最終構建者簽名進行某種帳戶抽象。閾值BLS 是不可歸因的——這意味著如果建設者只是BLS 簽署區塊，如果出現問題，我們將不知道該削減誰。抽象簽名將解決這個問題。

對於任何構建者預確認服務（分佈式或中心化的），請注意，預確認僅與他們實際構建獲勝區塊的能力一樣好。具有更高包含率的更占主導地位的構建者可以提供更好的預確認。

但是，您實際上可以通過分佈式構建者獲得更強的預先確認，例如EigenLayer 構造。如果當前提議者選擇了EigenLayer 並且您獲得了預先確認，那麼您的交易必須包括在內。您不再押注於中心化構建者的概率賠率，給您一個預先確認然後最終是否贏得區塊。

分佈式構建者的優缺點

假設所有的技術都成功了，分佈式構建者有成千上萬的參與者。你甚至可以讓大部分以太坊驗證者選擇加入提供亞秒級預確認的EigenLayer 構造。與中心化構建者相比，這種分佈式構建者俱有一些不錯的競爭優勢：

• 經濟安全——支持預確認服務的巨額安全存款

• 信任——搜索者可以信任這個分佈式構建者，而不是單個中心化實體

• 抗審查——與決定惡意的單個中心化運營商相比，破壞和控制任何安全的分佈式系統都更加困難

中心化構建者可能具有其他優勢，一些是固有的，一些基於分佈式構建者的構造：

• 更快地適應新功能——適應市場需求的靈活性是有價值的，而這可能是上述分佈式構建者構造所缺乏的。理想情況下，您可以將來自多方的獨特功能聚合到一個區塊中。

• 更低的延遲——這總是相關的，但對於跨鏈MEV 尤其如此，當世界狀態跨域變化時，搜索者更有可能想要更新他們的出價。 （如前所述，他們還希望首先在整個區塊過程中靈活地修改出價。）

結論性想法

以太坊在很大程度上是根據最壞情況假設設計的——即使只有一個構建者存在，我們如何才能最好地減輕他們的權力（例如，審查能力）？

然而，我們可以（並且應該）同時努力避免這種最壞情況的假設。這意味著設計一個並不總是導致根深蒂固的中心化構建者的系統。這裡描述的兩個想法提供了一些更有趣的可能性。然而，它們遠不是一個詳盡的清單——其他想法正在積極探索中，並且應該繼續探索。

此外，這不應被視為「專有訂單流的問題神奇地消失了，因此我們不再需要圍繞它進行構建。」dApps 必須繼續圍繞MEV 進行機制設計創新，包括減少對專有訂單流的需求。 MEV 不會去任何地方。

特別感謝Vitalik Buterin、Sreeram Kannan、Robert Miller 和Stephane Gosselin 的審閱和意見。沒有他們的工作，這份報告是不可能完成的。