MEV（四）：反轉使用者在 MEV 生態系中的地位

本篇將介紹能讓協議或使用者在 MEV 生態系中獲得更多控制權的幾個設計，包含 McAMM、MevWeth/MevWallet、Wallet-Boost、MEV Blocker 及 MEV-Share

• 作者：Nic @ imToken Labs

• 校對：Chih-Cheng Liang／Kimi Wu
• 封面來源：Gayatri Malhotra @ Unsplash
• 先備知識：
  • 對 MEV 有基本的認識，知道 MEV 生態系中不同的角色
  • 了解 mev-boost 及一個 Bundle 從產生到被放入區塊的流程
  • 知道AMM 的運作及流動性提供者（Liquidity Provider,LP）的角色
  • MEV（三）：PBS 補丁

MEV awareness

MEV 經過多年的發展後已經變成一個既定的事實，大家從一開始的拒絕接受，到現在幾乎所有 Validator 都已接上 MEV Boost，以及有像是 Flashbot Protect 的防護管道，使用者也更謹慎地檢查所設置的 AMM 滑點，以及 RFQ/Limit Order/Batch Auction 等不被 MEV 影響的交易方式也有穩定的交易量。

https://pseudotheos.mirror.xyz/i7sv9SFb1e64W2ax_kYwp68O0M2NdACtOu9Hj12SPP8

MEV inclusive

但 MEV 的發展不會僅止於知道哪些行為會導致 MEV 而已，而是在察覺 MEV 機會的存在後，反過來將 MEV 變為一個工具，或是針對 MEV 機會進行反制或甚至販售賺取 MEV 機會的權利。 接下來將依序介紹

1. 透過販售 MEV套利機會來增加流動性提供者（LP）收益的 McAMM 設計
2. 利用 MEV 來繞過公開的手續費市場，轉而透過檯面下的 MEV 手續費市場送交易的 MevWeth/MevWallet 設計。

MEV captured AMM (McAMM)

AMM 的流動性提供者（LP）提供流動性，在使用者來交易時收取手續費，而套利者（Arbitrageur）則是賺取使用者交易導致的價差，但這個價差是否應該是 LP 可以獲得的收益來源？

註：AMM LP 的效益分析可以參考 Tim Roughgarden 的 Loss-Versus-Rebalancing（LVR） 介紹

我們無法禁止套利者來套利，甚至需要藉由套利者來把價格套回當前的市場價格，但我們可以反過來販售這個套利機會。假設一個套利者發現一個套利機會的利潤為 1 ETH 且同時有多個彼此競爭的套利者存在，則套利者的競標價會接近 1 ETH，而這接近 1 ETH 的得標費用就可以成為 LP 新的收益來源。LP 的收益更多就能吸引更多人來提供流動性，流動性好就能吸引更多使用者來交易，也就能創造更多套利機會，形成一個正向循環。

McAMM 販售的是每個區塊中到該 McAMM 執行「第一筆」交易的權利。McAMM 沒辦法針對每一筆交易都販售交易權利，因為它沒辦法分辨哪些交易是套利者交易，哪些是正常的使用者交易，如果每一筆都販售則會導致使用者要來使用該 McAMM 還要先付錢給 McAMM，如此肯定沒有人會想來使用。所以 McAMM 只能保留「第一筆」交易的交易權利給買下這個交易權利的套利者，讓他來套上一個區塊的使用者交易所產生的價差。

得標的套利者會得到 McAMM 第一筆交易的執行權利

如果得標者沒有來交易，其他使用者的交易都會 revert

McAMM 的缺點及風險

雖然上面提到 Builder 會有動機排序得標者的交易在其他 McAMM 交易之前，但這會需要 Builder 去整合 McAMM，特別為 McAMM 設計交易排序的方式。否則對一個沒有整合 McAMM 的 Builder 來說，幾乎全部的 McAMM 交易都是會失敗的交易（因為沒特別排序過），這些交易也就不會被收入進區塊裡。也就是說越少 Builder 整合 McAMM，McAMM 的交易就越難被收入區塊裡，導致使用體驗很差。

其次，「確保第一筆交易必須是得標者的交易」這個規定也有相對應的缺點，只要得標者忘了送交易或故意不送出交易，都會導致 (1) 其他使用者的交易沒辦法成功執行，或 (2) 能夠藉此發動針對 TWAP Oracle 的攻擊。這會需要例如引入多個得標者的方式來避免單點故障或中心化作惡的問題。

註：TWAP（Time-Weighted Average Price） 取的是多個連續區塊的交易價格的平均，因此如果能讓越多區塊沒有 AMM 交易發生，就有越高機率能操縱 TWAP 所計算出的價格，TWAP 的攻擊及分析可以參考 1、2、3 及 4。

另外也因為引入額外的競標機制及確保得標者權利的規定及檢查，McAMM 的 gas 成本也會比 AMM 的還高，這會影響使用者選擇來 McAMM 交易的意願（相比於使用一般的 AMM），而部署在便宜的 L2 上能讓這部分劣勢縮小 。最後 McAMM 設計者還需考量的有：該怎麼分配競標費用？如果競標費平均分享給 McAMM 的每個交易對、交易池，則羊毛黨可以藉由低成本創造一堆免洗交易對、交易池的方式來薅羊毛。McAMM 合約本身無法辨別哪些交易對是免洗、哪些不是免洗，所以還是需要某個角色來「主觀地」決定競標費的分配，這個角色可以是項目方本身，也可以是一個 DAO：DAO 成員在鏈下分析識別出羊毛黨後投票決定競標費的分配。

以上是以 McAMM 為例，介紹協議如何能從被動轉為主動，將 MEV 轉化為自身的收益。接下來會介紹 MevWeth 及 MevWallet，使用者或協議可以透過 MevWeth 及 MevWallet 將 MEV 反過來變成一個有利的工具。

MevWeth/MevWallet

假設一個使用者送一筆交易到 Uniswap 用 WBTC 換 USDT，他除了要付 ETH 當交易手續費，他實際上還可能因為滑價而被 MEV Searcher 進行三明治夾擊，導致他換到一個最差的價格。這等於是使用者付了兩次手續費：第一次是付 ETH 給 Builder，第二次則是被 Searcher 賺走滑價，而且使用者是被強迫收取第二次手續費。

Alice 除了付出交易手續費，還被轉走價差（20600–20550=50），等於又被收一次手續費

註：一筆 AMM 交易產生的 MEV 可以透過兩種方式被榨取，第一種是 Backrun 賺價差：假設使用者的交易賣 WBTC，把 1 WBTC 的價格從 20600 變成 20570（市場價格還是 20600），則 Searcher 可以接在使用者交易後面去買低於市場價格的 WBTC，賺走價差；第二種是三明治夾擊賺滑價及價差： Searcher 搶先使用者去賣 WBTC（導致使用者用最差價格買到 WBTC），再接在使用者之後去買 WBTC。三明治夾擊會比 Backrun 還賺，以下例子都會先預設 MEV Searcher 是進行三明治夾擊。

MEV 生態鏈中有自己的交易池（以下稱 MEV 交易池），由 MEV Builder/Relay 所維護的交易池。送到 MEV 交易池的交易有幾個特性和送到公開交易池的交易不太一樣：

• MEV 交易池有自己的手續費市場，獨立於公開交易池的手續費市場之外，只要使用者交易提供的經濟激勵夠多，就能比公開交易池的其他交易還快被收入進區塊。這個經濟激勵未必是給 Builder 的手續費，使用者交易所產生的 MEV 也是一種經濟激勵
• 送到 MEV 交易池的交易只有兩種結果：成功執行或完全不執行，不會出現交易失敗（revert）但還是要付手續費給 Builder 的情況

上述提到的交易特性其實是非常理想的交易特性，而 MevWeth 及 MevWallet 便是透過善加利用 MEV Pool 的特性來提升使用者體驗和協議效率的設計。

MevWallet

前面例子提到，使用者其實是被強迫收取第二次手續費的，而 MevWallet 讓使用者能拿回控制權。

MevWallet 是一個合約錢包，但使用者不是自己送交易到 MevWallet 去執行，而是對交易內容簽名並讓 Searcher 帶著交易及簽名上鏈到使用者的 MevWallet 去執行，因此這筆交易手續費是由 Searcher 支付給 Builder 的。而 Searcher 獲得的就是使用者的交易提供的經濟激勵，例如使用者交易產生的 MEV。

透過 MevWallet，Alice 以 MEV 作為手續費（$50），由 Searcher 支付 Builder 手續費（$40）

另外使用者還可以透過向 Searcher 收取 MEV 回扣（rebate），下面的 MevWeth 段落會介紹如何收取回扣。不過記得要確保使用者產生的 MEV 扣掉向 Searcher 收取的回扣，剩下的經濟激勵足夠讓 Searcher 幫他執行這筆交易，否則沒有 Searcher 會賠錢來做這件事。

Alice 以 MEV 作為手續費（$50），但要求 MEV Searcher 除了幫她送交易，還要給她回扣（$20），讓她交易成本降為 $30

註：可以看到收取回扣後， Searcher 的收益維持 $10 不變，但 Builder 的收益從 $40 變為 $20，這表示 Builder 收入這筆交易的誘因減少了，導致交易可能要比較久才會被收入。但這沒辦法避免，天下沒有白吃的午餐，如果使用者希望交易越快被收入，就要提供越多經濟激勵（給 Searcher 或 Builder）。

MevWeth

MevWeth 是Weth（Wrapped Eth）的延伸，因此和 Weth 一樣：1 MevWeth 一定可以換到 1 ETH。MevWeth 加入了幾個 MEV 相關的函式：addMev 、getMev 等等，讓使用者或協議可以透過 MevWeth 收取 MEV 回扣或主動提供 MEV 作為經濟激勵。

• 主動提供 MEV：透過addMev 提供 MevWeth

function addMev(uint256 value) external override {
 // _burnFrom(msg.sender, value);
 uint256 balance = balanceOf[msg.sender];
 require(balance >= value, "WETH: burn amount exceeds balance");
 balanceOf[msg.sender] = balance - value;
 emit Transfer(msg.sender, address(this), value);
 // add mev
 mev += value;
}

最後一行的 mev 變數紀錄的是任何人都可以任意拿走的 MevWeth 數量

• 任何人都可以透過getMev 將其他人提供的 MevWeth 拿走

function getMev() external override {
 uint256 current = mev;
 balanceOf[msg.sender] += current;
 delete mev;
 emit Transfer(address(this), msg.sender, current);
}

因為透過 addMev 提供的是任何人都可以馬上拿走的 MevWeth，所以使用情境一定是你明確知道為什麼要提供 MEV 作為經濟激勵。

使用情境

1. 使用者透過 MevWallet 收取回扣

MevWallet 使用 MevWeth 來強制收回扣的方式就是去呼叫 MevWeth 的 getMev，並確認有收到 MevWeth，否則就 revert 交易。Builder 不會將 revert 的交易打包進區塊，所以使用者可以確信如果交易執行成功，使用者一定會收到回扣。這筆交易執行步驟大概是： Searcher 在賺走使用者的 MEV 後要去 addMev，然後使用者的 MevWallet 再去呼叫 getMev 拿走 MevWeth 作為回扣。

MevWallet 透過繼承 Mevitize 這個合約就可以直接使用裡面的 subsidize modifier 來完成收取回扣（或是也可以反過來補貼 Searcher）：

modifier subsidize(int256 tip) {
 uint256 gp = tx.gasprice;
 uint256 bf = block.basefee;
 if (bf != gp) revert ExactBaseFee(); // this asserts that there is no tip
 uint256 pre = gasleft();
 _;
 uint256 post = gasleft();
 int256 loot = tip + int256(gp * (pre - post));
 if (loot > 0) {
 mevWeth.addMev(uint256(loot));
 } else {
 mevWeth.getMev(uint256(-1 * loot));
 }
}

前面的部分是在計算 gas 消耗，並乘上 gasprice 算出手續費，最後面幾行才是決定要收取回扣或補貼：

{
 modifier subsidize(int256 tip) {
 ...
 // tip 可以是負數，所以只要 tip 超過手續費 int256(gp * (pre - post))
 // loot 就會變為負數
 int256 loot = tip + int256(gp * (pre - post));
 if (loot > 0) {
 // 如果 loot 是正數，則補貼 MEV Searcher
 mevWeth.addMev(uint256(loot));
 } else {
 // 如果 loot 是負數，則向 MEV Searcher 收取回扣
 mevWeth.getMev(uint256(-1 * loot));
 }
}

要使用 subsidize 的函式繼承 subsidize modifier 並透過傳入的 tip 參數來決定要收取回扣或補貼：

{
 function mevTx(
  ...
  int256 tip,
  ...
 ) external payable subsidize(tip + int256(msg.value)) {
  ...
}

1. 協議透過 MevWeth 雇用 Searcher 執行任務

協議可以透過主動提供 MEV 來讓 Searcher 幫它執行指定的函式，例如某個協議需要定時（每一千個區塊）做一些維護更新，它就會在負責維護更新的函式（maintain）裡透過 addMev 提供 MEV，讓 Searcher 來替協議定時執行該函式。

與其自己去搶在每一千個區塊執行一次 maintain，協議交給專業的 Searcher 來替它執行，並支付 Z 數量的 MevWeth 給 MEV Searcher

Fee Escalator

Flashbot 的研究員也提出過和收取回扣類似的作法 — Fee Escalator，只是 Fee Escalator 是實作在 Ethereum 底層而非應用層，且 Fee Escalator 的回扣是可以隨著時間變動的。

Fee Escalator 會新增一個新的 Ethereum 交易型態，這種交易允許將手續費指定為負的，但手續費會隨著時間過去逐漸變為正的（負 -> 零 -> 正）。如果交易在手續費為負的時候被收進區塊，則打包區塊的 Builder 必須要付手續費給該使用者，也就是回扣的意思；如果交易沒有被收入，表示交易提供的 MEV 扣掉回扣還不足以讓 Searcher 或 Builder 把它收進區塊，只能等待回扣金額慢慢減少，看會不會有 Searcher 或 Builder 想要收入。

Alice 為她的交易設定手續費為 -100，也就是 100 的回扣，但她的交易可套取的利益只有 50

這個機制如同對交易的收入進行荷蘭式拍賣，Searcher 或 Builder 是競標者。對 Searcher 或 Builder 來說，隨著一筆交易的手續費回扣慢慢減少，其提供的經濟激勵就越來越多，當一個 Searcher 或 Builder 覺得一筆交易的經濟激勵達到他的門檻，他就會收入那筆交易。

等到手續費變為 -30 時，Searcher 收入 Alice 的交易進 Bundle 並向 Builder 出價 40 收入自己的 Bundle，Builder 收入 Bundle，從 Searcher 那獲得 40，再給 Alice 30 的回扣

上面介紹的是透過「去中心化」的方式讓使用者獲得控制權，且使用者可以選擇要向 Searcher 收取回扣或是補貼 Searcher 以加速交易被收入。接下來要介紹的是以「中心化」的方式來達成同樣一件事，會有一個中間人角色負責協調使用者及 Searcher，看哪個 Searcher 可以拿到使用者交易，獲得套利機會。

接下來將介紹的 Wallet-Boost、MEV Blocker 及 MEV Share 都是透過一個公開競標的方式決定誰可以拿到使用者交易。這其實就像是目前 MEV Boost 中 Validator 與 Builder 之間的互動：在 MEV Boost 中 Builder 向 Validator 競標「生產區塊」的權利，而在 Wallet-Boost、MEV Blocker 及 MEV Share 中，Searcher 向使用者競標「把使用者交易收入自己 Bundle」的權利。

Wallet-Boost

Wallet-Boost 由 BlockNative 所開發，透過一個 Wallet-Boost 角色替使用者的交易舉行拍賣，Searcher 競標有利可圖的交易，競標費會成為使用者的回扣。

假設使用者要到 AMM 去 swap，在使用者確認好要兌換多少錢以及滑價是多少之後，錢包會向 Wallet-Boost 送出使用者的交易內容，開始競標。

1. Wallet-Boost 會公布使用者的交易內容給有興趣的 Searcher，這個交易內容不包含使用者簽名，所以 Searcher 沒辦法直接把交易收入到自己的 Bundle 之中
2. Searcher 確定可以從這筆交易獲取多少 MEV 後就向 Wallet-Boost 出價競標
3. Wallet-Boost 從中挑選出最高競標價後通知錢包，接著使用者對交易簽名並交給 Wallet-Boost，同時 Searcher 也將自己的套利交易及支付競標費給使用者的交易交給 Wallet-Boost
4. Wallet-Boost 將這幾筆交易打包成 Bundle 並模擬，模擬確認完結果後就將 Bundle 送給白名單裡的 Builder

Wallet-Boost 交互的範例圖示，source：https://github.com/blocknative/discourse/discussions/1

註：Wallet-Boost 不會只由 BlockNative 自己營運，錢包商也都可以自己跑 Wallet-Boost。

信任需求

在 Wallet-Boost 中，Searcher 是和 Wallet-Boost 互動，且是由 Wallet-Boost 來製作 Bundle 而不是 Searcher，所以 Searcher 需要信任 Wallet-Boost。不過比起 Searcher，運營 Wallet-Boost 的人（例如錢包本身）通常累積了更多的名聲和信用，所以其作惡的成本高上許多，再加上回扣是給使用者不是給 Wallet-Boost 或錢包商，所以作惡並不會有直接的獲利。

而 Wallet-Boost 和目前的 Searcher 一樣都要信任 Builder 不會偷走 Bundle 內容。

使用者體驗

對使用者來說，使用體驗不會有太大差別：產生交易內容、簽名並發送交易。不過錢包可以選擇在收到 Wallet-Boost 回傳的最高競標費後呈現給使用者，讓使用者知道自己能獲得多少回扣，但這會受 Wallet-Boost 效能及即時的競標狀況影響。錢包商得要思考該怎麼設計，避免因為等待 Wallet-Boost 回傳資訊而導致使用者等太久。

另外是特殊狀況的處理，例如 Searcher 在得標後消失或是交易沒有順利在下一個區塊被收入（可能因為 Builder 沒有贏得競標） 。如果擔心 Searcher 得標後消失，可以要求 Searcher 在競標時就要附上他簽名好的交易，雖然會導致 Searcher 對 Wallet-Boost 所需的信任增加，但和原本所需的信任並沒有相差太多。如果交易沒有順利在下一個區塊被收入，則錢包可以選擇繼續讓 Builder 嘗試，或是重新進行一次競標，或是直接將使用者交易送出（即跳過 Wallet-Boost）。

可能的問題和風險

目前 Wallet-Boost 並沒有規定 Searcher 該用哪種方式套取 MEV，所以 Searcher 可能用對使用者無害的 Backrun 方式，也可能用對使用者有害的三明治夾擊的方式。不過 Wallet-Boost 畢竟是一個中心化角色，它可以選擇過濾掉對使用者有害的 Searcher 交易或直接宣布不接受這樣的交易，而 Searcher 也會為了錢配合這樣的要求。

註：在 MevWallet/MevWeth 或 Fee Escalator 中，使用者反而沒辦法要求 Searcher 要用哪種方式套取他的 MEV，因為使用者已經把簽名好的交易廣播出去，手上已經沒有籌碼。

MEV Blocker

MEV Blocker 是由多個團隊聯合開發的防 MEV 服務。它和 Wallet-Boost 一樣會有中心化角色為使用者交易舉行競標，競標費會是使用者的回扣來源，不過 MEV Blocker 會將其中 10% 競標費給予 Validator。

另外 MEV Blocker 明確規定 Searcher 不能搶跑或三明治夾擊使用者的交易，違反者應該會被加入黑名單。MEV Blocker 目前沒有說明背後是怎樣的機制進行競標、協調 Searcher、組出 Bundle 及分配回扣，和 Wallet-Boost 相比是屬於比較黑箱的運作。

使用體驗上，MEV Blocker 和 Flashbot Protect 一樣，都是對外開放一個 RPC 接口，任何想避免被搶跑、夾擊且同時又能獲得回扣的使用者，都直接把交易送到這個 RPC 接口，送出後就是等待結果：要不交易被收入，要不交易因為超時而被丟掉。MEV Blocker 一樣也提供兩種不同模式：Fast Execution 及 Revert Protection。Fast Execution 模式專注於越快收入交易越好，即便交易 Revert 也會收入進區塊；Revert Protection 模式則專注於確保交易不會 Revert 才收入進區塊，因此可能會需要比較久的時間才會被收進區塊。

• Fast Execution RPC：https://rpc.mevblocker.io

• Revert Protection RPC：https://rpc.mevblocker.io/noreverts

MEV Blocker 就像是有回扣版本的 Flashbot Protect，但目前 MEV Blocker 不像 Flashbot Protect 一樣有提供 API 讓使用者查詢交易狀況，使用者可能必須自己決定什麼時候要重送交易。

MEV-Share

MEV-Share 由 Flashbot 團隊所開發，將 MEV Boost 的架構移植到 Searcher 和使用者之間：Searcher 向使用者競標「收入使用者交易到自己 Bundle」的權利。MEV-Share 和 Wallet-Boost 很像，主要的差別在於 MEV-Share 引入了隱私的概念：使用者不再提供完整的交易內容給 Searcher，而是可以選擇性地揭露部分的交易內容，Searcher 再基於揭露的資訊去製作 Bundle。這也是 Flashbot 向 Programmable Privacy 這個願景往前邁進的第一步。

在 MEV-Share 中負責協調及舉行競標的是一個叫 Matchmaker 的角色。MEV-Share 的運作大致如下：

1. 使用者將交易交給 Matchmaker 並同時指定可以揭露的內容（稱為使用者的 Privacy Preferences），Matchmaker 將可以揭露的內容分享給 Searcher 們
2. 如果從揭露的資訊找到套利機會，則 Searcher 會製作部分留空的 Bundle 以及一些關於 Bundle 要放什麼樣的交易的提示（稱為 Searcher 的 Hint）並傳給 Matchmaker
3. Matchmaker 參考 Searcher 給的提示將符合條件的使用者交易一一插入 Bundle 的留空欄位並模擬，看哪些能成功套取出 MEV
4. 拼出完整 Bundle 後，Matchmaker 會為 Bundle 指定有效條件（Validity Condition）然後傳給白名單中的 Builder，Builder 要遵守 Bundle 的有效條件。有效條件例如使用者必須收到多少數量的回扣

註：不同於 Wallet-Boost，在 MEV-Share 中回扣是由 Searcher 支付給 Builder，Builder 再支付給使用者

Matchmaker 負責搓合使用者的交易及 Searcher 的 Bundle，同時保護使用者交易的隱私，source：https://collective.flashbots.net/t/mev-share-programmably-private-orderflow-to-share-mev-with-users/1264

使用者的 Privacy Preference 與 Searcher 的 Hint

使用者可以指定要揭露哪些資料給 Searcher，例如呼叫的合約地址、到 AMM 兌換的幣種，或是 Oracle 資料更新的內容（例如新的價格）：

{ 
 tx_hash_AAA: {
 to: uniswap_v3_router,
 tokens_traded: [ETH, USDC]
 },
 tx_hash_BBB: {
 data: oracle_update_parameters
 }
}

Searcher 從揭露的資料來判斷是否有 MEV 套利機會並製作相對應的 Bundle。Searcher 有兩種方式來在資訊有限的前提下安插使用者的交易進 Bundle（稱作 Private Transaction Insertion）：(1) 直接安插指定的交易或 (2) 讓 Matchmaker 代他安插。

(1) 直接安插指定的交易如果 Searcher 從揭露的資訊就已經可以做出完整的 Bundle，則他可以在 Bundle 的交易序列裡直接指定使用者交易的 hash 值。例如以下 Searcher Backrun 使用者交易 tx_hash_AAA 的例子：

{ 
 txs: [tx_hash_AAA, searcher_backrun_tx_hash]
 blockNumber: 1000000, // block number for which this bundle is valid on
}

(2) 讓 Matchmaker 代他安插如果 Searcher 沒辦法從揭露的資訊做出任何結論，則他可以在 Bundle 的交易序列裡留空，並請 Matchmaker 替他模擬插入不同的使用者交易，看是否有機會成功套取出 MEV。例如以下 Searcher 以 _ 代表插入使用者交易的位置：

{ 
 txs: [ _ , searcher_backrun_tx_hash]
 blockNumber: 1000000,
}

如果 Matchmaker 直接毫無頭緒地一筆一筆插入使用者交易去模擬，這麼做不但沒有效率，甚至找到的交易可能也不是 Searcher 所期望的。所以 Searcher 可以透過 Hint 來給 Matchmaker 提示，提升 Matchmaker 模擬的效率，例如以下例子中 Searcher 在 hints 裡指定他要 Backrun 的是「有和 0x7a25 或 0xef1c這兩個 Uniswap 地址互動」且「emit 了 0x4100 這個 event（Sync event）」的交易：

{
 txs: [ _ , searcher_backrun_tx_hash]
 blockNumber: 1000000,
 hints: {
 addresses_touched: [0x7a25, 0xef1c],
 Logs_emitted: 0x4100,
 }
}

Bundle 的 Validity Condition

Matchmaker 需要替 Bundle 指定 Bundle 成立的有效條件，例如指定使用者的地址必須獲得多少回扣（或著說這個 Bundle 執行完使用者的代幣餘額必須是多少）。例如以下例子中 Matchmaker 在 validity_conditions 裡指定 Bundle 執行完後地址 0x1234 的 ETH 餘額必須要是 1.1：

{ 
 txs: [tx_hash_AAA , searcher_backrun_tx_hash]
 blockNumber: 1000000,
 validity_conditions: {
 eth: { 0x1234, 1.1 }
 }
}

註：Validity Condition 是由 Builder 來履行，所以假設 Matchmaker 在 Validity Condition 指定要回扣的話，會是由 Builder 來支付，而這筆錢的來源會是 Searcher 在 Bundle 中付給 Builder 的（在 Wallet-Boost 中回扣是 Searcher 直接支付給使用者）。而 MEV Boost 目前也是 Searcher 在 Bundle 中付錢給 Builder，所以接入 MEV Share 的話 Searcher 不需要額外調整付錢的對象。

信任需求

• 使用者需要相信 Matchmaker 只會揭露指定的資料給 Searcher，且會替使用者指定有利的 Validity Condition
• Searcher 需要相信 Matchmaker 的搓合能力且不會偷走他的 Bundle
• 使用者和 Matchmaker 需要相信 Builder 會遵守 Bundle 的 Validity Condition
• Searcher 和 Matchmaker 需要相信 Builder 不會偷走 Bundle 內容

使用者隱私與 Searcher 獲利優化之間的 trade-off

相對於能看到完整的交易內容，基於片段內容（例如使用者互動的合約地址，或是兌換的幣種）來製作 Bundle 會讓 Searcher 的工作困難不少。如果 Searcher 的獲利因此下滑，就比較難給出好的競標價，連帶影響回扣數量及交易被收進區塊的效率。但至少使用者可以自己選擇揭露內容的多寡（Programmable Privacy），而非只能完全揭露自己的交易內容。

可能的問題和風險

因為是由 Searcher 來組 Bundle，所以 Searcher 有可能會組出進行搶跑或三明治夾擊的 Bundle，這會需要 Matchmaker 開發出一套分析的工具來檢測 Searcher 是否用對使用者有害的方式套取 MEV。

負責搓合的 Matchmaker 需要進行大量的模擬，因此 Searcher 可以透過發送大量模擬請求來對 Matchmaker 進行 DoS 攻擊。可能的防禦方案例如沿用目前 MEV Boost 裡 Builder 針對 Searcher 建立的名聲機制，或是要求 Searcher 抵押押金。

2023.04 MEV-Share goes live

MEV-Share 已經上線且送往 Flashbot Protect 的交易現在都將透過 MEV-Share 來撮合。

想了解更多 Searcher 如何接入及使用 MEV-Share 可以參考這一篇 Flashbot 寫的 high level 介紹：https://writings.flashbots.net/searching-on-mev-share。

另外 Flashbot 官方也寫了一個範例是單純靠鏈上的資訊來判斷是否有 AMM Pool 的套利機會：https://twitter.com/bertcmiller/status/1653507151988490240

以上是幾種讓使用者從自己的交易中拿回 MEV 控制權、取回屬於自己的利益（MEV）的設計：從去中心化的 MevWallet/MevWeth 到中心化的 Wallet-Boost/MEV Blocker，再到提供隱私為出發點的 MEV Share。

去中心化的 MevWallet/MevWeth 架構更為簡單，沒有額外的角色和競標機制，完全交由公開的 MEV 市場運作。中心化的 Wallet-Boost/MEV Blocker/MEV Share 架構較為複雜，但也因為有一個中心化的角色，所以可以透過它來規範 Searcher，避免使用者被搶跑或三明治夾擊。MEV Share 則進一步打開交易隱私的大門，透過 Programmable Privacy 讓使用者可以在「交易隱私」及「回扣與交易收入效率」之間進行權衡，而非只有完全公開自己交易內容這個選擇。

總結與重點

• 作為 MEV 的源頭，使用者一直都和自己產生的 MEV 無緣，甚至被搶跑、被夾擊，聰明一點的使用者則尋求 Flashbot Protect 的保護。經過多年的苦難，使用者總算能拿回控制權，除了瓜分自己產生的 MEV，還能要求 Searcher 不能搶跑和夾擊自己的交易，可謂苦盡甘來
• 使用者拿回控制權的方式就在於把最有利的籌碼 — 自己的交易 — 拿在手上，並透過拍賣自己交易的方式從中分享自己交易所產生的 MEV
• MevWallet/MevWeth 及 Fee Escalator 屬於去中心化的方式來拍賣使用者交易，架構簡單，不需引入額外的角色及互動，而且使用者或協議也可以利用 MevWeth 來補貼、聘僱 Searcher 替自己完成交易和任務
• Wallet-Boost/MEV Blocker/MEV Share 屬於中心化的方式來進行拍賣，有個需要被信任的中間人來負責拍賣與協調的工作，但優點是中間人可以要求 Searcher 不能以有害使用者的方式來套取 MEV
• MEV Share 則進一步引入 Programmable Privacy 的設計，為使用者交易提供隱私，但同時使用者也必須要注意隱私與效率之間存在的 trade-off
• 協議一樣也能從自己產生的 MEV 中分一杯羹，McAMM 透過拍賣每個區塊第一筆來 McAMM 交易的權利，和套利者分享自己的交易池所產生的 MEV

下一篇將介紹幾個從更底層的地方解決 MEV、確保 MEV 生態保持去中心化的設計

參考資料與推薦延伸閱讀

• McAMM：https://ethresear.ch/t/mev-capturing-amm-mcamm/13336

• MevWallet：https://github.com/blunt-instruments/MevWallet

• MevWeth：https://github.com/blunt-instruments/MevWeth

• Fee Escalator：https://docs.google.com/presentation/d/1RzmbsdgIfPCioZh2_OT7mdtXkCSjlX3hyc9GFh9-vXo/edit?usp=sharing

• Wallet Boost：https://github.com/blocknative/discourse/discussions/1

• MEV Blocker：https://mevblocker.io , https://ethresear.ch/t/reducing-mev-with-transaction-auction/15057
• MEV Share：
  • https://collective.flashbots.net/t/mev-share-programmably-private-orderflow-to-share-mev-with-users/1264
  • https://docs.flashbots.net/flashbots-mev-share/overview
  • https://writings.flashbots.net/searching-on-mev-share

Special thanks to Chih-Cheng Liang and Kimi Wu for reviewing and improving this post