摘要：特別感謝Justin Drake 以及Flashbots 團隊給予的反饋和討論。威脅共識網絡持續去中心化的一個主要風險是圍繞礦工可提取價值（MEV）的經濟學，這是從選擇下一個區塊內容的能力中獲取利潤的複雜技巧。列舉一個簡單的MEV 示例：針對自上一個區塊以來發生的價格變動對所有鏈上去中心化交…
特別感謝Justin Drake 以及Flashbots 團隊給予的反饋和討論。
威脅共識網絡持續去中心化的一個主要風險是圍繞礦工可提取價值（電動汽車）的經濟學，這是從選擇下一個區塊內容的能力中獲取利潤的複雜技巧。列舉一個簡單的MEV 示例：針對自上一個區塊以來發生的價格變動對所有鏈上去中心化交易所進行套利。雖然一般的 權益證明 奖励是相当平等的，因为单一验证器的回报率与强大的验证池相同，但在寻找复杂的 MEV 提取机会方面，存在着显著的规模经济性。简单说，一个规模大 10 倍的池子就拥有 10 倍的机会来提取 MEV，并且它可以花费更多的精力来进行优化，以从每个利润机会中提取更多。除了这个问题之外，MEV 还使得去中心化池复杂化，因为在去中心化池子中，仍然需要一个实体来负责打包并提出区块，并且他们可以轻松地秘密提取 MEV，而无需和池子本身分割收入。
最出名的解決方案就是提議者（proposer）/區塊構建者（block-builder）分離。與區塊提議者試圖自己生產收益最大化的區塊不同，他們依賴於一個市場，在這個市場中，我們稱之為區塊構建者的外部參與者生產包含完整區塊內容和提議者費用的bundle 包，而提議者選擇最高費用的bundle 包。提議者的選擇被簡化為選取費用最高的bundle 包，這種算法非常簡單，以至於在一個去中心化池子中，它甚至可以在MPC 內完成以防止欺詐。
這篇文章提出了一些關於如何實現這一點的設計。
另請參閱2018 年的想法，這些想法與此處的想法密切相關：優化提議承諾方案（Optimised proposal commitment scheme）
提議者/構建者分離區塊提議設計的所需屬性
我們將重點關註五個主要的期望屬性：
1.不受信任的提議者友好性：提議者欺騙區塊構建者的風險很小或沒有風險，因此區塊構建者沒有動機選擇具有一定鏈下聲譽或與構建者有個人關係的提議者（因為這將有利於大型池子）。
2.不受信任的構建者友好性：區塊構建者欺騙提議者的風險很小或沒有風險，因此提議者沒有動機選擇具有一定鏈下聲譽或與提議者有個人關係的構建者（因為這會讓新的構建者更難進入市場）。如果需要存款來實現這一點，則應最大限度地降低門檻。
3.弱提議者友好性：該機制不應該要求提議者俱有(i) 高帶寬或其他計算資源或(ii) 高技術複雜性。
4.Bundle 包不可竊取：提議者應不可接受區塊構建者提出的Bundle 包並從中提取交易來製作自己的Bundle 包，從而阻止區塊構建者獲利（並可能進一步損害他們）。
5.共識層的簡單性和安全性：從共識層的角度來看，該機制應該繼續是安全的，並且最好與現有的區塊提議機制進行相同的分析。
想法 1
1.區塊構建者生成bundle 包並發布它們創建的bundle 包的頭（headers），一個bundle 包頭包含對包主體（bundle body）的commitment 承諾（預期的區塊內容）、對提議者的付款以及構建者的簽名。
2.提議者選擇提供最高付款的bundle 包頭（僅考慮構建者有足夠餘額來實際支付的bundle 包）。他們簽署並發布包含該包頭（bundle header）的提議。
3.看到簽名的提議後，提供包含包頭（bundle header）的區塊構建者將發布完整的bundle 包。
在這一點上，分叉選擇規則有能力做出三個判斷中的一個（而不是通常的兩個）：
1.區塊提議不存在
2.區塊提議存在，但包主體（bundle body）不存在
3.區塊提議存在，並且包主體（bundle body）存在
請注意，在第二種情況下，proposal 仍然成為了鏈的一部分，並且至關重要的是，區塊構建者向提出者的付款仍在處理（但區塊構建者自己不會獲得任何費用或自己獲取MEV）。
分析
五個屬性中的三個很容易滿足：
1.提議者無條件地接受承諾的付款，因此bundle 包不能欺騙提議者；
2.三個步驟都是非常自動化和低帶寬的，因此這滿足弱提議者友好性；
3.提議者無法看到他們正在簽署的bundle 包的內容，因此這滿足bundle 包的不可竊取性；
而共識層屬性，以及不受信任的提議者友好性要更加棘手。這種設計確實改變了分叉選擇的工作方式，將其從2 個選項增加到3 個選項，這也意味著提議者不再是遊戲中的最後一個參與者。從理論上講，人們可以推斷，如果分叉選擇能夠做出決定，那麼這應該是好的，但這仍然是一個潛在未知的重大變化。
提議者看不到bundle 包內容，也不能通過bundle 包竊取來欺騙區塊構建者，但是他們可以對區塊構建者使用更微妙的攻擊。他們可以在一個slot 時間段的末尾發布他們的提議，確保證明人（可能）按時看到proposal 提議，但不能給區塊構建者足夠的時間發布body，因此證明人很有可能沒有按時看到body 。這給區塊構建者帶來了風險，並激勵他們青睞值得信賴的提議者。此外，它還創造了一個機會，通過這個機會，惡意的大多數人可以對自己不喜歡的區塊構建者進行重罰。
對於這一問題，我認為有兩種緩解方法：
1.證明人在接受提議的最長時間和接受一個body 的最長時間之間有2 秒的延遲。如果你信任證明人，這基本上可以解決問題，儘管區塊構建者有損失資金風險的基本問題仍然存在。此外，尚不清楚證明者以這種方式投票是否符合激勵措施（儘管可通過要求他們證明提案的2 秒長VDF 解決方案來迫使他們等待）。
2.如果一個body 沒有被包含在內，提議者只會得到一半的付款（而區塊構建者只支付一半）。這使得提議者惡意破壞的代價很高，但它仍確保了區塊構建者惡意破壞的代價仍然很高（在這兩種情況下，代價都足以讓你相信甚至匿名參與者也不想這麼做） 。例如，如果一個bundle 包的提議者費用為1，區塊構建者利潤為1.05:
（1）誠實的行為將導致（構建者，提議者）回報為（0.05, 1）；
（2）提議者或證明人發布太晚，導致一個只有header 頭的區塊被接受，則回報為(-0.5, 0.5) ；
想法 2
1.區塊構建者製作bundle 包並發布他們創建的bundle 包頭。一個bundle 包頭包含對內容的承諾、對提議者的付款以及來自構建者的簽名。
2.提議者選擇並簽署一份聲明，該聲明由他們所看到的bundle 包頭列表組成。
3.看到該聲明後，選定的區塊構建者會發布其相應的包主體（bundle body）。
4.提議者從他們預先提交的列表中選擇一個bundle 包頭，並用它發布一個提議。
有一個新的罰沒條件，它可以驅逐和懲罰任何發布不屬於（相同slot 時間段內）列表提議的提議者。
還要注意的是，提議者在步驟（2）中提交的bundle 包頭列表也可以是包頭的加密哈希列表，其中每個哈希都加密到該bundle 包的構建者的公鑰，以便只有構建者知道它們是否被接受。這降低了DoS 攻擊風險。
分析
同樣，五個屬性中有三個很容易滿足：
-
提議者不能竊取bundle 包，因為他們只有在已將自己限制在有限的現有bundle 包頭集時才能看到任何bundle 包主體。
-
如果不包括完整的body，就不可能發生構建者對提議者的付款，因此提議者也不能在經濟上欺騙構建者。
-
共識屬性和以前一樣，因為系統仍然是提議者為最後一個行動者的遊戲，並且共識規則決定的內容沒有變化。
在這種情況下要確保的兩個較難的屬性是，弱提議者友好性和不受信任的區塊構建者友好性。令人擔憂的是，惡意的區塊構建者可以通過提出大量的提議來攻擊提議者，這些提議都提供了非常高的費用，但從不公佈其中任何一個提議的body。如果提議者對他們接受多少bundle 包有上限，那麼這種攻擊可以將所有合法bundle 包定價，並使提議者沒有可合法包含在其區塊中的bundle 包。如果提議者可接受的bundle 包數量沒有上限，那麼這可能導致向提議者發送無限數量的全bundle 包體（相想每個500 kb），這是一個巨大的帶寬需求。
該難題的一個解決方案是以某種非硬性限制的方式對bundle 包頭提交進行速率限制。
1.提交bundle 包的費用，通過一些類似EIP-1559 的機制進行調整以達到一定的速率（例如每個slot 8 個bundle 包）。
2.作為區塊建設者的存款要求，以及一條規則，即當更低價格的bundle 包被包含了，而你發布的bundle 包沒有被包含，那麼你就不能為接下來的N 個slot 提交bundle包。
費用本身也可能僅在你的bundle 包未包含，但較低價格的undle 包包含在內的情況下收取，因為這是你可能存在惡意行為的具體情況（或提議者是惡意的或網絡當時是壞的）。
這是有先例的，比如ENS 拍賣收取0.5% 的失敗者費用，以阻止人們在顯然不會獲勝的情況下進行出價（只是為了增加獲勝者必須支付的金額）。
然而，這些技術存在對提議者引入信任要求的風險，因此需要謹慎完成，並且未能將bundle 包包含在內的懲罰不能太高。
另一種解決方案是允許免費和無限制的bundle 包主體發布，但限製網絡層的主體傳播。一種簡單的算法是：
-
為可以傳播bundle 包主體的最小時間添加一個輕微的延遲：最高支付bundle 包的延遲為0 秒，第二高支付bundle 包的延遲為0.2 秒，第三高支付bundle 包的延遲為0.38 秒，第K 高支付的bundle 包，就延遲
秒。
-
添加一個規則，如果節點已廣播了一個更高收入的bundle 包主體，則該節點不會再廣播一個bundle 包主體。
這兩種技術可以結合在一起：你可以收取少量費用來將預期的bundle 包數量減少到（例如）每slot 50 個，然後使用這樣的網絡層機制進一步降低帶寬需求。
結論
截至目前，我還無法確定上述兩種方法是否是解決問題的唯一途徑，可能還會有其他的方法。在這兩種方法中，想法(1) 在概念上更簡單，但它給區塊構建者帶來了風險以及更複雜的分叉選擇規則要求。
而從分叉選擇和共識角度來看，想法(2) 要更簡單，但它在處理惡意區塊構建者DoS 攻擊方面存在挑戰，並且該問題的任何解決方案也有可能產生其他的問題（儘管可以想像這可以最小化）。到目前為止，我仍然不確定哪個方案會更好一些。
