以太坊合併後 mev 可能使寡頭情況更嚴重，mev-boost 的設計是如何使得個人質押者也能參與 mev 的提取的？以及它的實現進度如何？
來源 | ethresear.ch
本文件概述了用於區塊構建者/區塊提議者分離 (pbs) 的、基於信任的市場設計，它將與即將到來的以太坊合併分叉相容。正如在這些 flashbots pos 提案 裡所詳述的，這個基於信任的解決方案與當前 flashbots 競拍設計 (其修改由以太坊核心開發者提出，使得個人質押者可以參與且不會對以太坊共識引入變更) 最為相似。這個解決方案旨在為無需許可的 pbs 設計搭建橋樑。關於 pbs 設計，我們強烈建議可以納入合併後的清理分叉，以提高區塊構建者的去中心化水平。
術語
- 共識層客戶端 (consensus client)：負責以太坊權益證明共識的客戶端
- 執行層客戶端 (execution client)：負責以太坊虛擬機器執行的客戶端
- 執行負載 (execution payload)：包含未被簽名的執行負載的完整內容的訊息，這個訊息會被新增到一個信標區塊中
- 中介軟體 (middleware)：在共識層客戶端和執行層客戶端中間的一個新軟體，它與中繼相連
- 提議者 (proposer)：對進入網路的信標區塊進行簽名和提交的一方，通常被稱為驗證者
- 使用者：傳送交易的普通以太坊使用者
- 搜尋者：高階以太坊使用者，專門尋找 mev 機會和傳送交易捆這樣的高階交易型別
- 構建者 (builder)：專門用從使用者和搜尋者接收到的交易構建以太坊執行負載的一方 (搜尋者和使用者信任其會公平打包)
- 中繼 (relay)：專門從事 dos 保護和網路連線的一方，它們驗證和路由執行負載給區塊提議者 (構建者信任其會進行公平的路由，提議者信任其路由的負載具有區塊有效性、準確性和資料可用性)
- 第三方託管 (escrow)：負責為提議的執行負載提供冗餘的資料可用性的一方 (中繼信任其提供的資料隱私性)
架構
flashbots 競拍 ( flashbots auction) 架構允許驗證者將區塊構建外包給一個第三方區塊構建者網路。雖然驗證者能夠打包任何的負載到鏈上，我們相信當驗證者的工作只限於選出給他們支付最多 eth 的負載時，網路的去中心化和驗證者收益才能最大化。
在 pos 以太坊，flashbots 區塊構建過程包括以下步驟：
- 使用者和搜尋者透過公共的 p2p 交易池或直接的通道傳送交易給區塊構建者
- 構建者用這些驗證者提供的交易和頭部引數構建執行負載。構建者可以直接把驗證者的 feerecipient 地址設為該負載的 coinbase 地址，或構建者可以設定自己的地址並在負載裡打包一筆轉賬到 feerecipient 的交易。
- 中繼從構建者接收執行負載，驗證負載的有效性，並計算負載的數值 (即支付給 feerecipient的 eth 數額)。負載，驗證負載的有效性，並計算負載的數值 (即支付給 feerecipient 的 eth 數額)。
- 第三方託管從中繼接收完整的執行負載，以提供資料可用性。
- 驗證者從中繼接收執行負載頭 (從交易內容裡抽取出來的執行負載) 。中繼必須在每個執行頭部附上一個負載數值的標示。驗證者挑選價值最高的頭部，對負載簽名，然後返回給中繼，經由第三方託管廣播到網路。
請注意，一個實體可以在這個系統中扮演多種角色。這些角色被分別標識，因為它們都適合於某種程度的專門化。在短期內，應該有多個獨立的中繼。在未來，一個在共識水平的去信任 pbs 設計將會移除對中繼和第三方託管的需求。
在驗證者方面，這個架構利用了一個獨立的中介軟體，它在共識層客戶端和執行層客戶端之間。這個中介軟體處理與中繼的通訊、用於選擇最有價值的負載的利潤轉換邏輯，以及在中繼斷開連線時轉為使用本地執行層客戶端的回退機制。使用一箇中介軟體而不是對共識層客戶端的直接修改使得我們可以獨立維護各個元件，並可以在對 engine api 帶來最小改動的情況下實現跨客戶端的相容性。
需要注意的是，中繼只應用於在區塊構建時接收負載——中繼不應該用於履行執行層客戶端的其他職能，而且在沒有可用中繼時，驗證者應該總是回退到本地負載構建。
由於執行負載頭並不包含交易內容，驗證者搶跑的風險就消除了。這個設計使得個人質押者可以參與到 flashbots mev 提取中，從而減少經濟中心化的激勵。但是，這個設計還要求驗證者信任中繼能過濾掉無效的負載，準確地報告負載的數值，並當執行負載頭被簽名時揭示交易內容。引入第三方託管是為了透過在多個提供商間複製交易內容，以提高資料可用性。
總結：
- 驗證者信任中繼提供的資料可用性、負載有效性和負載數值的準確性
- 使用者和搜尋者信任構建者、中繼和第三方託管的搶跑保護
- 由於是中介軟體，可以最小化對共識層客戶端的修改
- 在中繼和驗證者之間的往返通訊，增加了區塊提議的延遲
討論點
客戶端修改
flashbots 將繼續使用形式規範，並將支援客戶端實現團隊為合併新增 mev 相容性。
當前的設計要求對共識層客戶端介面做出以下修改：
- 使驗證者能夠對執行負載頭 (而不是整個執行負載) 簽名並打包到信標區塊
- 使得驗證者能夠使用用於認證目的的質押金鑰對有字首的訊息進行簽名
- 使得共識層客戶端能夠路由一個已簽名的信標區塊回到中介軟體，而不是試圖傳送到網路裡
- 使得共識層客戶端能夠在中介軟體出現問題時回退到一個本地或遠端的執行層客戶端
目前不需要執行層客戶端的修改。
惡意的中繼
這種設計最重要的安全機制是讓所有驗證者能夠識別一箇中繼是否變成惡意的。
讓我們假設更糟糕的情況：有一個單一的中繼與 100% 的驗證者相連。中繼開始提議無效區塊，並謊報負載的數值，以讓驗證者總是選擇它們。
在這種情況下，一個天真的中介軟體實現可以導致區塊鏈停止執行，因為驗證者不再提議有效區塊。
中繼有三種方式提議壞的負載：
- 無效的負載：違反一些共識規則的負載
- 不準確的數值：提議的負載數值與執行後聲稱的不一致
- 缺失的資料：負載主體永遠不被中繼揭示
為了緩解這種情況，必須能夠 1) 在傳送給驗證者之前，在多方間提前驗證負載，或 2) 在一箇中繼已經提議了一個壞的負載並自動回退到一個安全的替代客戶端時，讓網路裡的所有驗證者都可以識別出該中繼。最重要的是，這種安全機制必須在面對互相敵對的中繼時是強韌的。
中介軟體和中繼間的通訊
在中介軟體和中繼間之間的通訊有多個選擇：推式 vs 拉式，直接 vs p2p。
必須注意確保滿足以下要求，以選擇最佳實現：
- 它必須保護驗證者隱私，不把驗證者金鑰與 ip 地址聯絡起來
- 它必須有儘可能低的延遲
- 它在對抗惡意中繼/驗證者是必須是強韌的
錯失 slot 的風險
如果區塊提議者未能即時廣播以收集足夠多的證明，就會出現錯失 slot 的情況。在這種情況下，區塊提議者不會收到該區塊的基本獎勵 (在質押了 1000 萬個 eth 的情況下大約是 0.025 個 eth )，交易和 mev 獎勵也不會有。由於這個架構要求在向證明者廣播前傳送已經簽名的負載頭回去中繼/第三方託管，因此瞭解什麼是可接受的錯失 slot 比率以及如何在正常的網路執行條件下將其最小化將是非常重要的。
負載頭引數
為了產生有效區塊，構建者和中繼必須瞭解執行負載頭的所有屬性。儘早提供區塊構建所需的所有輸入是符合驗證者的利益的。這使得構建者能夠最大限度地提高準確性和計算可用時間，以找到一個最佳的區塊構建。
除了 coinbase ，所有的頭部屬性都可以由構建者根據他們看到的網路狀態得出。由中介軟體來過濾建立在不正確狀態上的負載。
驗證者認證與 feerecipient 地址
驗證者需要與構建者和中繼溝通他們希望用作 feerecipient 的地址。這個地址對於準確度量被提議的負載數值是必要的。由於 feerecipient 可以是任何地址，驗證者必須在公佈時自行認證。
目前還沒有讓驗證者對他們的 feerecipient 進行認證和釋出的方法。最好的方法是是新增一個簽名域，讓驗證者可以安全地用他們的質押私鑰對任意訊息進行簽名。
部分割槽塊 vs 完整區塊
這個規範棄用了在構建者和區塊提議者之間通訊的 “flashbots bundles”，轉而使用代表一個區塊的完整排序和內容的執行負載。儘管 bundle (交易捆) 為打包交易到區塊頭提供了一個高效的競拍機制，但它對於所有排序偏好的表達力還不是很足夠。特別是，交易捆競拍不適用於大型交易或搶跑保護的用例。轉為使用完整區塊提議意味著對排序的全部偏好都可以得到表達。
用於優先處理的頻帶外賄賂與 mev 均勻分配/燒燬
有些驗證者可能會接受頻帶外的賄賂，以優先處理某些負載或試圖透過證明賄賂來進行時間盜賊攻擊 (time bandit attack) 。理論上，共識可以強制要求給區塊提議者支付最多 eth 的區塊構建者構建的區塊被打包，且把手續費分攤或燒燬，儘管這個機制超出了這個提案的討論範圍，且需要進一步的研究。
去中心化
正如上文提到的架構，中繼是受信任會提供搶跑和 dos 攻擊保護的。儘管這個系統允許有多箇中繼無需許可地互相競爭，可能的情況是隻有少數幾個成功的中繼。我們強烈建議核心開發者在清理分叉上考慮納入無需許可的設計，以減少中繼信任要求，並提高網路的去中心化水平。
客戶端最佳化
儘管不推薦，但只依賴第三方區塊構建者進行區塊構建的驗證者可以執行一個精簡版的執行層客戶端，它刪除了交易池和區塊構建邏輯，所以降低了客戶端對硬體和頻寬的要求。
mev-boost 的實現計劃
來源 | github.com/flashbots/mev-boost
一項允許以太坊共識層客戶端把區塊構建外包給執行層客戶端以外的第三方區塊構建者的服務。請看上文的高層次架構和 docs/specification.md 瞭解其規範和實現細節。
v0.2 請求流：
實現計劃
共識層客戶端變更的總結可以在這裡找到。
▲ 版本 0.1 (當前、里程碑 1，在 kiln 測試網執行)
簡單的側車 (sidecar) 邏輯，對共識層客戶端最低限度的改動，簡單的網路連線、沒有認證和手動的安全機制。
規範: https://github.com/flashbots/mev-boost/blob/main/docs/specification.md
▲ 版本 1.0 （下一步，里程碑 2，合併）
安全、認證和聲譽
- mev-boost 從共識層客戶端請求認證 feerecipient 的訊息，並在 p2p 網路定時 gossip
- 新增模組，用硬性的或統計黑名單驗證之前的中繼負載的有效性和準確性
- 新增模組，用於訂閱第三方中繼監測服務
所需的客戶端修改
- 當發生中介軟體崩潰時，共識層客戶端必須能夠繞過中介軟體，連上一個本地或遠端的執行層客戶端
- 共識層客戶端必須實現提議 promises
▲ 版本 2.0 - 隱私 (可選)
新增 p2p 通訊機制，以避免驗證者去匿名化
- mev-boost gossips 透過 p2p 對區塊+初始負載頭部簽名
所需的客戶端修改
- 共識層客戶端必須實現新的 gossipsub topics
▲ 版本 3.0 - 配置 (可選)
新增可選配置到提供替代保證
考慮新增直接的 relay_forkchoiceupdatedv1 呼叫到中繼，用於同步狀態
考慮直接返回完整負載到驗證者作為最佳化
考慮新增支付的默克爾證明，把驗證要求轉移到中繼
ecn的翻譯工作旨在為中國以太坊社羣傳遞優質資訊和學習資源，文章版權歸原作者所有，轉載須註明原文出處以及eth中文站。若需長期轉載，請聯絡[email protected]進行授權。
本文首發於：https://news.ethereum.cn/technology/mev-boost-merge-ready-flashbots-architecture
