SUAVE

SUAVE 的全名是 Single Unifying Auction for Value Expression，目的是成為一個橫跨多個鏈的、統一的 MEV 市場，在這個市場中使用者可以以有效率的方式表達一筆交易的成交條件及獎賞，同時執行者（Executor）彼此會競爭，也會進行有效率地合作來完成使用者的請求。

SUAVE 可以作為一條區塊鏈的交易池及成為該區塊鏈負責生產區塊內容的 Builder 角色，但 SUAVE 並非要取代一條區塊鏈原有的交易池及 Builder 功能，而是以一個隨插即用（Plug and Play）的方式接上一條現有的區塊鏈。SUAVE 接入一條區塊鏈後，該區塊鏈等於多了一個去中心化、非常專業且同時擁有橫跨多條區塊鏈交易來源的強大 Builder。同時擁有多條區塊鏈交易來源將在未來逐漸成長的跨界（Cross Domain） MEV 市場中提供巨大優勢，擁有這個優勢的 Builder 將會比在單一條鏈運作的 Builder 更有競爭力。

From Flashbot to MEV-Boost to SUAVE

從 Flashbot 到 MEV-Boost，其秉持的精神都是接受 MEV 的存在，竭力將隱藏在檯面底下的經濟活動搬到檯面上，並建立一個公開市場讓任何人都可以參與其中，目的就是為了避免這個巨大的經濟利益一但默默地被少數人所掌握及把持，將逐漸使那些少數人握有越來越多的資源，最終影響整個區塊鏈網路的中心化與安全。

但隨著對 MEV 越來越了解，大家慢慢意識到除了發展最成熟的 Ethereum 上的 MEV 市場，還有跨鏈、跨界的 MEV 市場，這個跨界的 MEV 市場將比 Ethereum 的還大上許多，跨鏈的交易也比同一條鏈上的交易有更多榨取 MEV 的機會。如果沒有像當初 Flashbot 一樣來揭露跨界 MEV 市場、將其搬上檯面並讓大家公平參與，能夠榨取跨界 MEV 的少數人將會更有優勢，最終仍然會影響整個區塊鏈網路的安全性。

另一個會影響中心化、安全性的現象是 Private Order Flow：使用者的交易不再流向公開的交易池，而是直接到 Searcher 或 Builder 手上。Private Order Flow 可能是來自 Searcher 或 Builder 向使用者購買收入其交易的權利，或是 Builder 提供吸引人的服務，例如 (1) 免費取消使用者送出的交易或 DEX 訂單，或是 (2) 提供 Pre-Confirmation，在交易還未收入前就向使用者保證交易會多快被收入，讓使用者不需煩惱交易是否會被收入、多久才會被收入。部分 Private Order Flow 對使用者是有益的，但長久來看 Private Order Flow 仍然會導致中心化，因為擁有 Private Order Flow 的 Searcher/Builder 將比沒有的人獲得更多收益，且這將不利於競爭，因為沒人會無緣無故將 Private Order Flow 分享給新加入的 Searcher/Builder，導致新加入的人在比賽一開始就陷入劣勢。

為什麼從使用者的交易到 Searcher 組出來的 Bundle，都必須經由 Private Order Flow 的方式收進區塊呢？這是因為交易和 Bundle 內容都是公開、沒有加密的，只要一被別人看到、拿到，別人都可以對使用者或 Searcher 造成傷害，例如以夾擊方式榨取使用者交易的 MEV，或是拆解 Bundle 把 MEV 搶走。而這也是目前使用者和 Searcher 都要相信 Builder 的原因，因為他們都要將交易和 Bundle 的原始內容交給 Builder，並相信 Builder 不會傷害他們。

SUAVE 的出現便是要來解決跨界 MEV 及 Private Order Flow 所帶來的中心化風險。首先，透過建立一個服務於跨界 MEV 的公開市場，使用者或 Searcher 可以在這個市場裡表達自己交易或 Bundle 的收入條件，例如使用者同時有兩筆交易要分別收入到 Ethereum 及 Arbitrum，且兩筆都必須要被收入、要在哪個時間點之前被收入等等，而市場裡的 Executor（可以是 Searcher 或 Builder）會爭相滿足這個請求來獲得獎賞。但使用者或 Searcher 怎麼敢把交易或 Bundle 丟到這個公開的市場？這就需要引入隱私技術了。透過將交易加密，使用者或 Searcher 就不需擔心別人看到後能造成傷害，有了交易隱私才有 Open Order Flow 的可能。

SUAVE 更進一步提出了可編程隱私（Programmable Privacy）的概念，透過可編程隱私，使用者或 Searcher 將可以選擇是否要揭露交易或 Bundle 內容的特定部分（像是交易執行的合約地址），而不是只能在完全加密或完全不加密中做選擇。相比完全加密的交易，揭露特定資訊的交易將能更有效、更快速地被收入 Bundle 或區塊中，甚至收到回扣，詳細可以參考第四篇裡介紹的 MEV-Share；透過揭露特定資訊，Searcher 之間甚至可以互相合作，Searcher B 可以建立在 Searcher A 的 Bundle 之上：Searcher A 的 Bundle 尾隨使用者的交易進行套利，Searcher B 的 Bundle 再尾隨 Searcher A 的 Bundle 進行套利。有了隱私，才能有 Open Order Flow；有了隱私，才能使得 Searcher 有機會互相合作，讓彼此都能得利，而不是彼此競爭搶奪 MEV 機會。

SUAVE 帶來的其他好處

• 透過 SUAVE，跨鏈 DEX 交易能獲得更好的價格、跨鏈 Intent 將能夠更有效率地被執行
• 如果將 SUAVE 視為一個巨大但是去中心化的 Builder，它會比一個中心化 Builder 來得更有優勢，因為它匯聚更多的 Order Flow，如此也能吸引到更多 Builder 加入到 SUAVE，也能進一步降低 Builder 中心化帶來的風險
• 透過 SUAVE，每條鏈不必自己打造隱私的交易池及自己鏈的 MEV 市場，可以將資源及精力放在解決其他問題或提供更好的服務上

SUAVE 架構

Bulletin Board for User Preference

SUAVE 可以被形容為一個「User Preference 的佈告欄」。這裡的 User 未必是一般區塊鏈的使用者，Searcher 也可以是 SUAVE 的 User，以下將以「使用者」代指一般區塊鏈的使用者，以「SUAVE User」代指 SUAVE 的使用者。

SUAVE 的 User Preference 就像是特殊化的 Intent、專注在交易排序上的 Intent，它不像讀者可能會在其他地方看到的、可以做到指定各式各樣條件的 General Intent。如同在 Intent 中使用者會指定偏好、條件，在 Preference 中 SUAVE User 則是指定「交易或 Bundle 收入進區塊」的偏好或條件，例如

• 「我想要我的這筆交易排序在 0xabcd 這筆交易之前，且在第 110050 區塊之前被收入」，其實就像目前 Searcher 在使用 Flashbot 時，其 Bundle 所指定的條件
• 「我想要我的這個 Bundle 被收入，並為我帶來 0.05 ETH 的收益」
• 「我想要 Intent A 與 Intent B 被分別收入在鏈 X 的第 1001 區塊與鏈 Y 的第 50900 區塊裡」

註：使用者也可以將一般的區塊鏈交易（沒有指定任何 Preference）送到 SUAVE，也就是單純把 SUAVE 當成一般交易池或 Flashbot 來用，例如直接把他的 ETH 轉帳交易或 Uniswap 交易送到 SUAVE 那。

而當然如果只是單純指定條件，是沒有必要特別設計出一個新的架構來做這件事，直接用原本的 Flashbot 就好。所以其實在 SUAVE 中指定的這些 Preference 是要搭配獎賞的，否則沒有人願意無條件完成你的 Preference，當然支付的前提一定是 Preference 有被達成。而透過將 Preference 指定與獎賞做成智能合約來被履行，需求方（例如使用者或 Searcher）將能提出更細緻、更多元的 Preference 要求，而且這些要求是靠經濟誘因來滿足，而不是仰賴 Builder 的善良。

• 「我想要我的這筆交易排序在 0xabcd 這筆交易之前，且在第 110050 區塊之前被收入。如果達成的話，我就給你 3 ETH」
• 「我想要我的這個 Bundle 被收入，並為我帶來 0.05 ETH 的收益。如果達成的話，我就給你 0.02 ETH」
• 「我想要 Intent A 與 Intent B 被分別收入在鏈 X 的第 1001 區塊與鏈 Y 的第 50900 區塊裡。如果達成的話，我就給你 1.8 ETH」

SUAVE 可以視為由三個元件所組成：Preference Environment、Execution Market 與 Decentralized Block Building。

• Preference Environment 是容納來自各條鏈上的 User Preference 與獎賞的地方，包含 SUAVE 鏈及其交易池。SUAVE User 可能是一般使用者或是 Searcher
• Execution Market 則是一群專業的 Executor 尋找並執行 User Preference （透過包成 Bundle 的方式執行 User Preference）以賺取獎賞。Executor 可能是 Searcher 或 Builder
• Decentralized Block Building 是將多個 Bundle 組裝成一個或多個鏈的區塊的過程

左邊的 PE 匯聚各個鏈上的 Intent、套利交易，然後由中間的 Executor 們嘗試滿足這些 Preference 包進 Bundle 裡，並將這些 Bundle 交給右邊有權利產出區塊的角色來組裝出區塊。source

SUAVE 會有自己的一條鏈以及交易池，SUAVE 將鏈稱為 Settlement Layer，將交易池稱為 Messaging Layer。鏈上可以部署智能合約，用來訂立 Preference 與獎賞的契約，交易池則會充滿 SUAVE User 宣告 Preference 的交易及 Executor 領獎賞的交易。

一筆 SUAVE 交易的生命週期

1. Preference Expression：SUAVE User 為他的一筆或多筆 Intent/交易指定 Preference 並出價
2. Execution Optimization：Executor 找到能滿足 User Preference 的執行路徑（例如如何收入交易或代幣兌換路徑），甚至能為其找到最優的（例如換到最多代幣）
3. Preference Settlement：Executor 的 Bundle(s) 成功收進目標鏈的區塊裡，滿足 SUAVE User 指定的 Preference
4. Payment Settlement：Oracle 將目標鏈狀態回報給 SUAVE Chain，Executor 執行智能合約，合約確認 Preference 已被滿足後將 SUAVE User 的獎賞給予 Executor

Preference 從建立到執行，再到結算的四個步驟。source

SUAVE 需要能將 Preference 用程式語言撰寫出來，轉換成智能合約，才能履行 SUAVE User 和 Executor 之間的契約。SUAVE 預計會基於 EVM 來設計一個 MEV 專用的 EVM — MEVM。MEVM 會新增專門用於 MEV 的 Precompile 合約及交易類型，User Preference、打包 Bundle、Block Building 這些功能都可以在 MEVM 裡很方便地完成。

下圖的範例程式碼將 Effective Gas Price（EGP） Block Building 演算法用 Solidity、MEVM Precompile 合約寫出來。EGP Block Building 按照每個 Bundle 給的 Gas Price 來排序 Bundle，Gas Price 越高的 Bundle 會排在區塊的越前面：

圖中粉紅色的功能即是 MEVM 的 Precompile 功能，專門為 MEV 用途所設計。source

註：Block Building 演算法的執行並不會真的發生在 SUAVE Chain 鏈上，而是 Block Builder 在鏈下模擬執行（就像節點會在本地端模擬一筆交易的執行一樣），所以這個執行過程並不會真的成為一筆交易佔用 SUAVE Chain 的區塊空間及運算資源，也不會被 SUAVE Chain 的輸出效能所限制。

透過 EVM 合約的可組合性，Searcher 與 Searcher 之間或 Searcher 與 Builder 之間將能透過合約進行合作，取代原本單方面的信任關係，而合作也將能進一步提升 Bundle 效率、套取出更多 MEV，也就能造福 MEV 供應鏈的每個參與者。另外參與者都能直接沿用基於 EVM 的開發工具與基礎建設，例如 RPC Provider、測試工具例如 Foundry 等等，開發體驗會非常好。

而且 MEVM 將會提供交易隱私的功能，因為沒有隱私就沒有合作可能。沒有隱私，Searcher 就得擔心自己的 MEV 被偷走。初期這個隱私將透過可信硬體 SGX 來達成，將交易加密再送給 SGX 執行，相信 SGX 會執行其指定的程式碼而不會任意竊取 MEV。未來當其他先進密碼學技術逐漸成熟，再以密碼學來取代可信硬體，詳細介紹可以參考上一篇的 Encrypted Mempools。

註：但基於 EVM 也有缺點，像是 EVM 太 Expressive：其實要寫出 MEV 所需功能並不需要許多 EVM 裏面的 Opcode，允許這些 Opcode 的使用反而有可能讓有心人事可以寫出很複雜的執行，然後在執行的最後讓交易失敗，讓節點浪費一堆運算資源，也就是 DoS 攻擊。而 Anoma 這個項目則是重新設計了一個專門用來表達並執行 Intent 的程式語言與執行環境，未來或許 SUAVE 也會改用 Anoma 的架構來取代 MEVM。

隨插即用（Plug-N-Play）的 SUAVE

如果一條鏈的礦工或 Validator 本身知道 SUAVE 的存在並且有意使用 SUAVE 的話，那它就會把 SUAVE 當成一個 Block Builder，如果 SUAVE 為其組出的區塊提供更高的競標價的話，那礦工或 Validator 就會使用 SUAVE 的區塊。以目前 Ethereum 上的 MEV-Boost 為例，SUAVE 組出的區塊會透過 SUAVE 提供的插件來轉換成符合 MEV-Boost 競標機制的格式，Proposer 不需為了採用 SUAVE 的區塊做任何改動。

如果一條鏈的礦工或 Validator 不知道 SUAVE 的存在，那 SUAVE 的 Executor 就會透過該條鏈的手續費規則去競標收入其 Bundle。

跨鏈 MEV 的挑戰

每一條鏈都有各自的礦工和 Validator。SUAVE 的區塊 B1 被 X 鏈的礦工收入不代表區塊 B2 也會成功地被 Y 鏈的 Validator 收入，X 鏈和 Y 鏈的出塊機制和市場是各自獨立的。除非 X 鏈和 Y 鏈都採用 Shared Sequencer，同一時間由同一個 Sequencer 產出兩條鏈的區塊，那結合 SUAVE 才有辦法保證 Atomic Inclusion ：兩條鏈要不「一起收入指定的交易（或區塊）」，要不「都不收入」。

而且即便有 Shared Sequencer 能確保 Atomic Inclusion，也不代表交易被收入後會「成功」執行。沒有兩筆交易都「成功」執行就代表跨鏈 MEV 是失敗的。假設一個 SUAVE User 想完成一個跨鏈的套利，必須要兩條鏈上的交易都即時收入且成功執行他才能獲益，

• 如果 SUAVE User 不願意承擔交易執行失敗的風險，那他的 Preference 就會要求兩筆交易都要成功執行才算完成，才會付錢給 Executor，讓 Executor 來承擔風險。他可以透過指定鏈上的狀態來約束「成功執行的結果」，例如指定合約必須 emit 特定的 Event，或是指定某個地址的代幣餘額必須要大於多少。接下來願意承擔風險的 Executor 會嘗試讓兩筆交易都即時收入且成功執行，如果最終只收入其中一筆或是其中一筆交易執行「失敗」的話，那 Executor 就拿不到獎賞
• 如果 SUAVE User 願意承擔風險的話，那他的 Preference 可能就只會要求兩筆交易都有被收入就好，如果交易執行失敗（即交易 Revert）也可以。而 Executor 還是會盡力讓兩筆交易都執行成功（都執行成功可能獎賞更高），但只要能收入就能拿到獎賞

以下面的圖為例，SUAVE User 要在 Rollup 1 及 Rollup 2 之間執行跨鏈交易套利：在 Rollup 1 上以 $2000 價格買一顆 ETH，在 Rollup 2 上以 $2100 價格賣一顆 ETH。如果兩筆交易都即時收入並成功執行，那 SUAVE User 就能賺到 $100 價差。圖中表格裡的 Scenario 1 和 2 分別是「SUAVE User 願意自己承擔分險」及「由 Executor 承擔風險」。表格最下面三列依序是「兩筆都成功的獎賞」、「只有一筆成功的獎賞」及「只有一筆成功的最終結果」：

• 兩筆都成功（SUAVE User 賺到 $100）的獎賞：
  Scenario 1 — SUAVE User 付出 $50 手續費給 Executor
  Scenario 2 — SUAVE User 付出 $70 手續費給 Executor（比較貴，因為是由 Executor 來承擔風險）
• 只有一筆成功（SUAVE User 沒賺到價差）的獎賞：
  Scenario 1 — SUAVE User 付出 $25 手續費給 Executor。SUAVE User 自己吸收風險
  Scenario 2 — SUAVE User 不必付手續費，也不會承擔風險
• 只有一筆成功（SUAVE User 沒賺到價差）的結果：
  Scenario 1 — SUAVE User 付出 $25 手續費給 Executor，且手上多了一顆 ETH
  Scenario 2 — SUAVE User 不必付手續費給 Executor，手上也不會多出一顆ETH。而 Executor 手上多了一顆 ETH

不同情境下的不同執行結果。source

跨鏈 MEV 需要 Executor 有資本、願意承擔風險且有足夠技術能確保即時、Atomic 的收入與成功執行。這會是一個獲利豐富但門檻相對高的一個工作。

為什麼 SUAVE 需要自己一條鏈

為什麼不能單純地透過 p2p 網路來傳遞、分享 Preference？因為單純的 p2p 網路沒辦法防止網路被無數 Preference 塞滿（即 DoS 攻擊），如果是一條鏈的話就可以透過手續費來防止 DoS 攻擊。

為什麼 SUAVE 不沿用現有的鏈？因為 SUAVE 需要自己的（MEV）功能、自己鏈的設定值例如區塊時間、區塊大小。如果直接搭建在 Ethereum 之上，將會遇到成本太高、區塊時間太長、功能受限的問題。另外因為 SUAVE 需要得到其他鏈上的資訊來驗證 Preference 是否有被滿足，所以由一條獨立的 SUAVE Chain 匯聚所有其他鏈的資訊能保持中立。

不過 SUAVE 有自己一條鏈也表示 (1) SUAVE User 可能會需要將資產從其他鏈跨到 SUAVE Chain 上才能使用 SUAVE，(2) SUAVE 需要仰賴 Oracle 回報其他鏈的資訊。這代表 SUAVE 本身多了一個對 Oracle 的信任需求，如果 Oracle 是不安全的就會影響到 SUAVE 上合約的安全性。

註：關於 SUAVE 會不會有自己的代幣、是否需要將資產跨到 SUAVE Chain 來使用，或是如何跨到 SUAVE Chain 上，目前還沒有太多細節，只有在影片及文章提到過「SUAVE User 要先從其他鏈將資產跨到 SUAVE Chain 上才能使用」。

而 SUAVE Chain 本身的設計與安全模型目前還在討論中，如果 SUAVE Chain 是一條 Ethereum 上的 Rollup 的話那就可以直接用 Rollup 本身的機制來轉移資產和讀取其他 Rollup 的資訊，這會比仰賴其他跨鏈技術、Oracle 服務來的安全非常多。如果 SUAVE Chain 的 Validator 可以結合 Eigenlayer，直接請 Ethereum Validator 作為 SUAVE Chain Validator 也會比 SUAVE 自己生出一組 Validator 更安全可靠。但當然這些設計也有相對應的缺點，更多關於 SUAVE Chain 設計的討論可以參考這篇。

SUAVE 的挑戰總結

• SUAVE Chain 區塊時間：SUAVE Chain 的區塊時間需要夠短，短到 SUAVE User 足夠宣告自己的 Preference 讓 Executor 看到。如果 SUAVE Chain 時間比它接上的鏈（例如 Solana 或其他 Rollup）更長，就很容易造成 SUAVE User 還來不及讓 SUAVE Executor 知道他希望交易能在某條鏈的下一個區塊被收入前，下一個區塊就已經產出了
• Oracle 風險：Oracle 要負責提供其他鏈的資訊，可能也會同時負責將 SUAVE User 的資產轉移到 SUAVE Chain 上，所以 Oracle 的重要性非同小可
• 跨鏈的使用體驗：SUAVE User 需要將資產轉移到 SUAVE Chain 上也是一個使用體驗上的缺點
• 經濟模型：SUAVE 是否需要發行自己的代幣、要怎麼激勵 SUAVE Validator、要怎麼避免 SUAVE 的經濟激勵機制影響到其他鏈的經濟安全性等等
• 隱私技術：短期內 SUAVE 得仰賴可信硬體如 SGX 來提供交易隱私的功能，但長期勢必得換成更去中心化、更安全的方式以降低風險
• 合適的 Preference 語言：EVM 是否合適作為表達與執行 Preference 的方式