編者按：ETH2.0合併是一個對以太坊來說很重要里程碑式的升級，從PoW轉為PoS，PANews準備了一系列關於此主題的文章，在閱讀這個主題的任一文章時，在PC端的網頁版中，推薦閱讀可以看到更多有關ETH2.0以太坊合併的文章和快訊。
點擊此處下載PANews App，隨時隨地閱讀更多區塊鏈即時快訊和深度好文。
來源 | ethresear.ch
作者：Stephane@thegostep
本文檔概述了用於區塊構建者/區塊提議者分離(PBS) 的、基於信任的市場設計，它將與即將到來的以太坊合併分叉兼容。正如在這些Flashbots POS 提案裡所詳述的，這個基於信任的解決方案與當前Flashbots 競拍設計(其修改由以太坊核心開發者提出，使得個人質押者可以參與且不會對以太坊共識引入變更) 最為相似。這個解決方案旨在為無需許可的PBS 設計搭建橋樑。關於PBS 設計，我們強烈建議可以納入合併後的清理分叉，以提高區塊構建者的去中心化水平。
術語
共識層客戶端(consensus client)：負責以太坊權益證明共識的客戶端
執行層客戶端(execution client)：負責以太坊虛擬機執行的客戶端
執行負載(execution payload)：包含未被簽名的執行負載的完整內容的消息，這個消息會被添加到一個信標區塊中
中間件(middleware)：在共識層客戶端和執行層客戶端中間的一個新軟件，它與中繼相連
提議者(proposer)：對進入網絡的信標區塊進行簽名和提交的一方，通常被稱為驗證者
用戶(user)：發送交易的普通以太坊用戶
搜索者(searcher)：高階以太坊用戶，專門尋找MEV 機會和發送交易捆這樣的高級交易類型
構建者(builder)：專門用從用戶和搜索者接收到的交易構建以太坊執行負載的一方(搜索者和用戶信任其會公平打包)
中繼(relay)：專門從事DoS 保護和網絡連接的一方，它們驗證和路由執行負載給區塊提議者(構建者信任其會進行公平的路由，提議者信任其路由的負載具有區塊有效性、準確性和數據可用性)
第三方託管(escrow)：負責為提議的執行負載提供冗餘的數據可用性的一方(中繼信任其提供的數據隱私性)
架構
Flashbots 競拍( Flashbots Auction) 架構允許驗證者將區塊構建外包給一個第三方區塊構建者網絡。雖然驗證者能夠打包任何的負載到鏈上，我們相信當驗證者的工作只限於選出給他們支付最多ETH 的負載時，網絡的去中心化和驗證者收益才能最大化。
在PoS 以太坊，flashbots 區塊構建過程包括以下步驟：
用戶和搜索者通過公共的p2p 交易池或直接的通道發送交易給區塊構建者
構建者用這些驗證者提供的交易和頭部參數構建執行負載。構建者可以直接把驗證者的feeRecipient 地址設為該負載的coinbase 地址，或構建者可以設置自己的地址並在負載裡打包一筆轉賬到feeRecipient 的交易。
中繼從構建者接收執行負載，驗證負載的有效性，併計算負載的數值(即支付給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
一項允許以太坊共識層客戶端把區塊構建外包給執行層客戶端以外的第三方區塊構建者的服務。請看上文的高層次架構和docs/specification.md 了解其規範和實現細節。
mev-boost service integration overview
v0.2 請求流：
實現計劃
共識層客戶端變更的總結可以在這裡找到。
版本0.1 (當前、里程碑1，在Kiln 測試網運行)
簡單的側車(sidecar) 邏輯，對共識層客戶端最低限度的改動，簡單的網絡連接、沒有認證和手動的安全機制。
規範: https://github.com/flashbots/mev-boost/blob/main/docs/specification.md
Version 1.0 （下一步，里程碑2，合併）
安全、認證和聲譽
mev-boost 從共識層客戶端請求認證feeRecipient 的消息，並在p2p 網絡定時gossip
添加模塊，用硬性的或統計黑名單驗證之前的中繼負載的有效性和準確性
添加模塊，用於訂閱第三方中繼監測服務
所需的客戶端修改
當發生中間件崩潰時，共識層客戶端必須能夠繞過中間件，連上一個本地或遠程的執行層客戶端
共識層客戶端必須實現提議promises
版本2.0 – 隱私(可選)
添加p2p 通信機制，以避免驗證者去匿名化
mev-boost gossips 通過p2p 對區塊+初始負載頭部簽名
所需的客戶端修改
共識層客戶端必須實現新的Gossipsub Topics
Version 3.0 – 配置(可選)
添加可選配置到提供替代保證
考慮添加直接的relay_forkchoiceUpdatedV1 調用到中繼，用於同步狀態
考慮直接返回完整負載到驗證者作為優化
考慮添加支付的默克爾證明，把驗證要求轉移到中繼
