MEV（五）： 更公平的 MEV 生態系（上）
本篇將介紹兩個設計：SGX Builder 及 Chainlink FSS。SGX Builder 能降低 MEV 產業鏈裡的信任成本，Chainlink FSS 則希望能進一步從源頭讓 MEV 最小化。
作者：Nic @ imToken Labs
封面來源：Tingey Injury Law Firm @ Unsplash
先備知識：
對 MEV 有基本的認識
熟悉以太坊交易，一筆交易所包含的內容及其最後如何被收進區塊
知道區塊鏈上的 Oracle 服務（例如 Chainlink）的運作方式
大家已經習慣 Flashbot、MEV-Boost 的存在，基本上現狀就是和 MEV 共存。不過也有研究持續在進行，目的是希望能夠防止 MEV 的出現或盡可能地降低 MEV 曝露的機會，例如 Chainlink 的 Fair Sequencer Service（FSS）及 Encrypted Mempool。另外目前 MEV 產業鏈仍然存在信任問題，例如 MEV Searcher 需要相信 Block Builder 不會偷走他的 MEV 獲利，因此像是 Flashbot 正在研究的 SGX Block Builder 就是針對這部分的信任問題提出解法。
未來 Ethereum 不一定會採用這些設計來保護使用者，畢竟這些設計背後都有相對應的代價，尤其是對使用者體驗的影響。但 L2 會是很好實驗這些設計的環境，目前在絕大多數 L2 中使用者都必須完全相信項目方運營的 Sequencer，相信這個有唯一決定交易順序權力的 Sequencer 不會榨取 MEV，或至少不會進行對使用者有害的榨取方式，例如搶跑或三明治夾擊。
FCFS and latency game
這些 Sequencer 現在基本上都是採用 First Come First Serve（FCFS）的機制：Sequencer 按照它收到交易的時間點來排序交易，先到就先收入。FCFS 很簡單，但公平性卻也容易被操縱，甚至進而影響效能：攻擊者或是希望交易快速被收入的使用者只要瘋狂地重送交易給 Sequencer（也就是 spamming）就能夠比一般使用者有更高的機會提早被收入。 另外這也會讓 MEV 的競爭市場變成是單純網路延遲的競爭（Latency game），即便 Sequencer 是公正的，使用者交易在抵達 Sequencer 之前仍然有被 MEV Searcher 偷看到的可能性，而這時 MEV Searcher 們便是互相競爭誰和 Sequencer 的伺服器在地理位置上最接近、誰的網路延遲最低，這樣的競爭市場最終將導致 MEV 掌握在少數網路延遲最低的人身上。
註：Arbitrum 其實在排序交易這一方面有很多公開的討論和計畫，例如在 FCFS 中再引入競標機制或 PoW。但這些設計不盡理想，或許得等到 Chainlink 的 FSS 上線後，看 FSS 是否能為 Arbitrum 解決 MEV 問題。
接下來將要依序介紹
-
Flashbot 以可信硬體 SGX 來增加 Block Builder 公正性的設計
-
透過去中心化的 Oracle 來決定交易排序，以防止 MEV 的 Chainlink FSS
-
用密碼學加密交易來保護使用者的 Encrypted Mempool 設計（下一篇）
-
為 MEV 市場引入隱私和公平性機制的 SUAVE（下一篇）
SGX Block Builder
SGX 是可信硬體（Trusted Hardware）的一種，可信硬體會執行它被指定要執行的程式碼，並對執行結果簽名來讓第三方驗證結果的真實性，且其無法被外界（例如硬體的作業系統、保管人、維護者）所影響或監控。透過 SGX 我們能把 MEV 產業鏈中需要信任的角色都取代掉，例如 Block Builder、MEV-Boost 的 Relay 等等。但可信硬體也有其限制及缺點，包含硬體本身效能及需信任硬體製造商。
SGX Block Builder 很直白，就是讓 Block Builder 變成一個機器人。它只會執行固定的程式碼，不會惡意奪取 Searcher 的 MEV 或以對使用者有害的方式榨取 MEV，且 Searcher 或使用者的交易都可以先加密過後再傳進去給 SGX Block Builder，不需擔心交易在傳輸途中洩露而被搶走 MEV 或被惡意榨取 MEV。
Flashbot 在去年底就已經實驗過將 Geth 客戶端跑在 SGX 裡，當時遇到的最大問題是硬體限制及效能問題，詳細可參考：https://writings.flashbots.net/geth-inside-sgx/
接著今年三月 Flashbot 成功在 SGX 裡完成 Block Building：https://writings.flashbots.net/block-building-inside-sgx
目前 Mainnet SGX Block Builder 已經持續在運行並 propose 了數百個區塊！接下來的任務包含提升效能、避免 SGX 因為旁通道攻擊而洩露資訊、多個 SGX Block Builder 進行合作、進一步將 MEV 供應鏈其他角色 SGX 化，以及嘗試其他種可信硬體等等。
SGX and MPC Searcher
Flashbot 另外也在進行 SGX Searcher 及 MPC Searcher 的研究，SGX/MPC Searcher 的目的是為了保護使用者的交易隱私並去掉使用者對 Searcher 的信任需求：如果使用者將交易交給 Searcher，Searcher 不會用搶跑或夾擊的方式榨取使用者的 MEV，而是使用 Backrun 的方式套利並給予使用者回扣。如果 Searcher 使用 SGX，使用者便可以改成信任 SGX 而非 Searcher；如果 Searcher 使用 MPC，使用者便可以改成信任一群 Searcher 裡誠實的人佔多數而非相信單一個 Searcher。
註：SGX/MPC Searcher 處理的是使用者與 Searcher 之間的信任，不包含對 Builder 的信任，使用者與 Searcher 都必須要信任 Builder，除非 Builder 也是 SGX（或 MPC）。
如果今天使用者透過例如 MEV-Share 來拍賣他的交易，則因為已經有一個中心化角色 — Matchmaker — 是需要被信任的，此時就不需要再額外將 Searcher 變成 SGX 或 MPC 形式，因為是由 Matchmaker 來確保使用者交易的隱私及不會被惡意榨取 MEV。
以上是透過可信硬體來解決中心化問題，而接下來要介紹的是以去中心化方式來解決問題的 Chainlink FSS。
Chainlink Fair Sequencing Service (FSS)
既然由單一個 Sequencer 來排序交易太中心化，不如就由一群人來共同決定交易排序吧。但要用什麼標準來決定交易誰先誰後？其實沒有一個統一的標準，只要這群人用同樣的標準即可，如此才能方便達成共識。最簡單直覺的就是按照交易抵達的先後順序來決定，也就是每個人按照自己收到的交易的抵達順序來給出一個排序，然後再由多數決來決定最終排序。交易在 p2p 網路被接收到的順序對鏈本身來說其實就是一個外部資訊，而已經有一群穩健的 Oracle 節點的 Chainlink 便是為鏈帶來「交易被接收到的先後順序」這個外部資訊再適合不過的人選。
FSS 由 Chainlink 所提出，是一套實現交易排序規則的框架。透過 FSS，開發者可以使用、實作不同的交易排序規則，Chainlink 有數篇論文分別在探討 BFT 機制缺乏交易排序公平性，以及近一步提出不同改進交易排序公平性的版本： 參考 1，參考 2。或是開發者想實作一個用猜拳決定排序的規則也可以，或是像 MEV-Boost 一樣用競標的方式也可以。
Secure Causality Preservation
除了排序公平性（Order-fairness）外，另一個 FSS 提供的特質是確保安全的因果順序（Secure causality preservation），也就是一個事件 A 如果發生在一個事件 B 之前，則它的排序必須在 B 之前，而「安全」指的則是交易的內容在排序決定之前不會被洩露。為什麼還會需要再加上「安全」這個特性？這是因為在分布式（去中心化）的系統裡面某些人可能是惡意角色，會透過插入他們自己的交易在受害者交易之前的方式榨取 MEV，違反因果順序。如果在一個去中心化的系統裡且使用者的交易內容是公開的，就像現在大多數的區塊鏈一樣，則會導致的結果就是 — 顯然易見的 — 使用者的交易被榨取 MEV。
註：如果是中心化的系統，則不需要確保交易內容在排序前不會被洩露，也就是不需要「安全」特性，但其實中心化系統也沒有排序公平性或安全因果順序的問題，因為使用者只能相信該中心化系統。
達成「安全」的方式有許多種，包含使用密碼學工具來達成，例如使用 Commit-reveal 的方式，等到排序決定後才 reveal 內容，或是 Secret Sharing 、門檻簽章演算法（Threshold Encryption），先將內容加密且只有足夠多的參與成員（例如 Oracle 們）一起合作才能解密（假設壞人人數不會多到可以直接解密）。
兩階段部署
Chainlink 計畫分成兩階段來推出 FSS 服務。第一階段著重在將交易加密，降低被搶跑、被夾擊 MEV 的風險，第二階段才會引入他們所研究的交易排序機制。
註：Chainlink 在最早的文章中是將 FSS 描述為一個框架，且當時主打的是提供給 dApp 作為交易排序的服務來避免 MEV，但後來轉向為和 Arbitrum 建立合作關係，可能將為 Arbitrum 提供交易排序的服務，且會搭配 Chainlink 自己的 Oracle 網路及其所研究的交易排序機制來進行排序，以下馬上會介紹。或許在 Arbitrum 上試驗 FSS 成功後，才會有更多交易排序機制能被嘗試，讓 FSS 真正變成一個框架。
第一階段：加密交易並交由 Chainlink Oracle 來排序
在第一階段 FSS 只會先達成 Secure causality preservation，也就是防止交易內容洩露。使用者的交易內容會先被加密並送到 Chainlink 的 Oracle 網路，直到 Oracle 們排序好這些加密過的交易資料後，交易內容才會被解密。目前沒有關於如何加密及 Oracle 們如何排序的細節，可能是透過門檻簽章的方式，只有在足夠多的 Oracle 們合作之下才能解密使用者交易內容，或是只允許 Arbitrum 的 Sequencer 才能解密。
但雖然交易內容已經加密，攻擊者還是可以透過交易的 Metadata 例如使用者的 IP 地址或是交易的 sender 的地址等資訊來推敲可能的交易內容並嘗試榨取 MEV，例如透過 IP 地址或 sender 得知是 Alice 的交易，而 Alice 常常使用 Uniswap 交易 ETH/USDT 所以高機率她的這一筆交易是要去 Uniswap 兌換。
註：加密的交易至少得附上一些 Metadata 例如 sender 的原因是因為要避免被 Spam：如果沒有像是 sender 的資訊讓節點可以先驗證交易有效性，則會發生排序完交易並解密後，才發現交易 sender 根本沒有錢可以支付手續費。
攻擊者也可以採用 Blind front running 的方式，例如 Oracle 中某個成員推測正在建造的這個區塊內容裡有包含了一筆某個 ICO 或 NFT 專案發行的交易（藉由發行時間點推測），因此它想盡辦法將自己的搶購交易排在區塊的越前面越好。而此時即便交易內容都是加密的也沒辦法防止 Blind front running 這樣的攻擊。
而引入基於交易抵達 Oracle 節點的順序來排序交易的機制，就能防止像是 Metadata 或是 Blind front running 這種攻擊方式。因為當攻擊者看到使用者交易或是得知 ICO/NFT 發行交易時才送出自己的交易，此時要能排在該筆使用者交易之前的機會就小的許多。而這也是第二階段的目標。
第二階段：引入基於交易抵達節點順序來排序的共識機制
第一階段的排序機制目前看起來是一個黑箱的機制，第一階段著重於為交易進行加密，並試驗整個「加密交易 -> 排序加密交易 -> 解密交易並執行」的流程。第二階段就是在 Chainlink Oracle 網路引入他們設計的交易排序機制 — Aequitas。這個排序機制會按照交易抵達節點的順序來排序，每個節點會有自己的本地排序，例如：交易 X 在交易 Y 之前抵達，交易 Y 在交易 Z 之前抵達，而每個節點看到的順序不會完全一樣。接著再運行共識機制，以絕對多數決（Supermajority，超過 2/3 同意）的方式對「全局的交易排序」達成共識。
如此不但能透過加密交易內容防止 MEV Searcher 榨取 MEV，還能透過 FIFO 的規則防止針對 Metadata 的攻擊及 Blind front running 攻擊。
註 1：其實這就是一個去中心化版本的 FIFO 機制。
註 2：兩階段部署的文章在 2021 年發布，但後來交易排序機制有持續的改進，所以到時會採用 Themis 而不是 Aequitas。
Condorcet Paradox
不過要在去中心化系統裡去針對排序達成共識會遇到一個大問題 — Condorcet Paradox（或稱投票悖論）。Condorcet Paradox 指的是實現從個人的偏好到集體的偏好會遇到的障礙，例如 Alice 對候選人 X、Y 及 Z 的偏好是：X > Y > Z，而集體的偏好就是綜合所有投票人的偏好。你可能會以為採取例如多數決的方式來決定出最終集體偏好一定可以得出一個決定性的偏好，例如 X > Z > Y，但事實上這個集體偏好可能是沒有傳遞性的（Non-transitivity）且是循環的（Cyclic），例如會發現綜合所有投票人的偏好後會得出 X > Z > Y > X 這樣矛盾的結果，這就是 Condorcet Paradox。
如下圖，透過多數決的方式決定出三個人的集體偏好，會出現 X > Z > Y > X 的矛盾結果。而在 FSS 中，投票人就是 Chainlink 的 Oracle 節點，投票人的偏好就是交易抵達 Oracle 節點的順序。
因爲 Condorcet Paradox 的存在，所以我們可能沒辦法取得所有節點對交易排序的共識。
註：即便 Condorcet Paradox 不一定會發生，甚至在一個沒有故意形成該悖論的環境裡很難發生，可是一但發生就會導致共識機制當機，無法產出任何排序。
Aequitas
Chainlink 在 2020 的研究成果 Aequitas 藉由降低排序公平性的標準來繞過 Condorcet Paradox。以下是原本理想中排序公平性的定義（以交易抵達順序來排序）：
但我們知道因為 Condorcet Paradox 的存在，所以這個要求沒辦法被滿足。因此 Aequitas 降低了標準，改成將其定義為以 Batch 為單位的公平性：不同 Batch 之間能滿足理想排序公平性，但 Batch 內的交易會受 Condorcet Paradox 影響，所以沒辦法滿足理想排序公平性，不過至少它們都屬於同一個 Batch。把 Batch 當作一個區塊鏈區塊來看的話，其實同一個區塊裡面的交易至少都是一起被執行的（例如它們的時間戳是一樣的）。而不同 Batch 之間則能滿足理想排序公平性：Batch 100 的交易一定都是在 Batch 101 之前抵達。定義如下圖：
Aequitas 的共識算法大致如下：(1) 以絕對多數決的方式集合所有節點的交易排序，得到交易彼此之間順序圖（有向圖）：點（Vertex）為交易，邊（edge）為排序優先順序，A 指向 B 代表 A 應排序在 B 之前
(2) 如果圖中有 Strongly Connected Component（SCC），則表示 SCC 裡的交易彼此形成 Condorcet Paradox。接著透過 Graph condensation 演算法將 SCC 壓縮成一個點，形成一個新的圖。
把 SCC 壓縮成一個點其實就表示 SCC 之外的點和 SCC 內部的排序是無關的。對 SCC 之外的點來說，它們要不在 SCC 所有點的排序之前，要不就在SCC 所有點的排序之後，所以可以把 SCC 視為一個點。至於 SCC 裡的交易該怎麼排序？其實只要有一個固定的算法就好，可以所有節點共同擲一個骰子來決定，反正要確保的是這些交易和 SCC 之外的交易排序的公平性。
(3) 如果新的圖中有部分區域已經沒有 Condorcet Paradox，便可以輸出該區域的交易排序：
Themis
Themis 是 Aequitas 的優化版本，主要是改善 Aequitas 的效能及輸出的方式：
-
Aequitas 是透過所有節點互相分享訊息來達成共識，導致訊息數量很多，變成效能瓶頸；Themis 則是每一輪會固定選出一個 Leader 來統一收集訊息並負責執行計算，並向所有節點證明計算結果的正確性，如此大幅降低來回訊息的時間及訊息總量
-
Aequitas 是在所有 Condorcet Cycle 都解掉且確定一個 Batch 裡所有交易的排序之後才輸出最終排序；Themis 則是逐步輸出，避免計算卡住導致共識停止，且 Leader 不一定要提出完整的最終排序，Leader 可以解出部分排序（其他部分還需要解 Condercet Cycle 或決定最終排序）並交給下一個 Leader 繼續完成，如此能避免因為出現 Condorcet Cycle 太長而導致共識停擺、產出不了任何區塊
dApp 和鏈都可以使用 FSS
FSS 的設計不只是鏈可以使用，dApp 也可以接入 FSS 服務。對鏈來說，就是由 FSS 來決定最新一個區塊裡的交易排序。而對 dApp 來說，就是在合約裡規定只有 FSS 才可以帶交易來該 dApp 執行，帶上來的交易就代表都是已經經過 FSS 所排序。不管是鏈或是 dApp，接入 FSS 後，使用者都是改成把交易送到 FSS，FSS 排序完後再交給鏈的 Sequencer/Proposer 或是送到 dApp 上。
不過對一個 dApp 來說，接入 FSS 可能碰到、待解決的問題是：一筆交易可能很複雜，經過很多合約，執行該 dApp 可能只是其中一個步驟，而這筆交易也因此必須要配合該 dApp 接受 FSS 排序，這對該 dApp 的使用者來說是可以接受的嗎？或甚至經過兩個 dApp 而兩個 dApp 都使用 FSS 且有各自的排序規則，那該怎麼辦？Chainlink 2.0 白皮書的 5.2.2 節有提到 dApp 使用 FSS 的問題及一些可能的解法。
潛在問題
即使 FSS 解決 Condorcet Paradox、解決效能問題，且可以順利產出公平的交易排序，但仍然必須注意的是：如果一個 Oracle 節點不誠實提供它實際收到交易的順序的話，是否有相對應的懲罰機制？
沒錯，我們已經假設 Oracle 節點的壞人數量不會超過某個門檻（才能順利達成共識），但我們能假設剩下的節點都是誠實無私的好人嗎？如果壞人透過賄賂的方式來誘使其他節點提供對壞人有利的交易排序呢？我們的機制設計能夠降低節點被收買的動機嗎？
Chainlink 也有提到他們接下來會研究如何設計出合適的激勵機制來激勵好的行為、懲罰壞的行為。但可以思考的是：要怎麼證明一個節點有「如實」提供它收到的交易抵達順序？或是證明一個節點「謊報」交易抵達順序？這問題其實和 Oracle 網路本身很難設計出一個懲罰機制一樣，對使用 Oracle 服務的角色（例如一條鏈或鏈上的智能合約）來說，Oracle 提供的資訊都是鏈外的資訊。即便你設計出一套懲罰機制說「這些 Oracle 是壞人，它們提供的資訊是錯的，『這個』才是正確的資訊」，這個「正確」的資訊仍然是一個鏈外的資訊，鏈上合約要怎麼分辨哪個才是正確的？
Frequent Batch Auction-FCFS (FBA-FCFS)
Flashbot 的研究員也有向 Arbitrum 提出另一套 FBA-FCFS 設計，這個設計維持 Arbitrum 的單一 Sequencer 但採用 Aequitas/Themis 所定義的以 Batch 為單位的公平性。在這個設計中不是透過一群節點來對交易抵達順序達成共識（畢竟 Arbitrum 只有一位 Sequencer），而是以時間區間（例如 500 毫秒）來決定一個新的 Batch 該包含哪些交易：在 T 到 T+500 毫秒之間抵達的交易會在同一個 Batch，T+500 到 T+1000 的交易會是下一個 Batch。決定出一個 Batch 包含哪些交易後，接著再透過競標方式決定 Batch 裡的交易排序：給越多手續費（Priority Tip）的交易會排在 Batch 的越前面。如此除了能滿足以 Batch 為單位的公平性，在 Batch 內的交易也可以透過手續費讓交易發起人（例如一般使用者或 MEV Searcher）可以選擇是否要調整自己交易在 Batch 裡的排序，而非只能全然靠 Latency game 來爭奪 Batch 裡的交易優先順序。
註：FBA-FCFS 能維持以 Batch 為單位的公平性，也提供在 Batch 內透過手續費來影響排序，但這都建立於對 Sequencer 的信任之上。
總結與重點
-
FCFS 簡單且直覺，但會讓 MEV 市場變成 Latency game，導致中心化
-
透過可信硬體例如 SGX 來作為 Block Builder，Searcher 可以不必擔心 MEV 被 Builder 偷走。降低 MEV 產業鏈信任成本，也就降低中心化程度
-
Chainlink 的 FSS 則希望透過加密交易及它的去中心化 Oracle 網路來嘗試提供一個公平的交易排序，從源頭將 MEV 最小化
-
但在 FCFS 或是 FSS 這樣的機制中，決定交易排序的都是交易抵達順序，使用者（或攻擊者）沒辦法透過像是手續費來表達他們期望的交易排序偏好，結果就是當使用者（或攻擊者）有排序偏好時，只能透過不斷送新交易（或重送舊交易）來爭取交易更快被收入，導致網路更容易出現壅塞
-
安全假設：使用可信硬體便是相信可信硬體的安全性；Chainlink FSS 則是相信它的去中心化 Oracle 網路
下一篇將介紹幾個著重於使用密碼學來防止 MEV 的設計
參考資料與推薦延伸閱讀
SGX Block Builder
SGX/MPC Searcher
FSS
-
Arbitrum FCFS with bidding: https://arxiv.org/abs/2306.02179
-
https://blog.chain.link/chainlink-fair-sequencing-services-enabling-a-provably-fair-defi-ecosystem/
-
https://blog.chain.link/arbitrum-and-chainlink-fair-sequencing-services/
-
Chainlink 2.0 White Paper（FSS in Chapter 5.3）：https://research.chain.link/whitepaper-v2.pdf
-
FSS 的幾個介紹影片：
-
Aequitas：https://eprint.iacr.org/2020/269.pdf
-
FBA-FCFS：
-
Arbitrum 排序設計介紹（2023/08 SBC）：
Special thanks to Martinet Lee and Peter Lai for reviewing and improving this post