以上是透過可信硬體來解決中心化問題，而接下來要介紹的是以去中心化方式來解決問題的 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 節點的順序。

source：https://youtu.be/lB57a2wGo8Y?t=4439

因爲 Condorcet Paradox 的存在，所以我們可能沒辦法取得所有節點對交易排序的共識。

註：即便 Condorcet Paradox 不一定會發生，甚至在一個沒有故意形成該悖論的環境裡很難發生，可是一但發生就會導致共識機制當機，無法產出任何排序。

Aequitas

Chainlink 在 2020 的研究成果 Aequitas 藉由降低排序公平性的標準來繞過 Condorcet Paradox。以下是原本理想中排序公平性的定義（以交易抵達順序來排序）：

如果過半數的節點先看到 m1 才看到 m2，則所有誠實節點都會同意 m1 要排在 m2 之前。source：https://youtu.be/lB57a2wGo8Y?t=4386

但我們知道因為 Condorcet Paradox 的存在，所以這個要求沒辦法被滿足。因此 Aequitas 降低了標準，改成將其定義為以 Batch 為單位的公平性：不同 Batch 之間能滿足理想排序公平性，但 Batch 內的交易會受 Condorcet Paradox 影響，所以沒辦法滿足理想排序公平性，不過至少它們都屬於同一個 Batch。把 Batch 當作一個區塊鏈區塊來看的話，其實同一個區塊裡面的交易至少都是一起被執行的（例如它們的時間戳是一樣的）。而不同 Batch 之間則能滿足理想排序公平性：Batch 100 的交易一定都是在 Batch 101 之前抵達。定義如下圖：

不要求 Batch 內的交易要滿足理想排序公平性，但不同 Batch 之間要滿足。source：https://youtu.be/lB57a2wGo8Y?t=4474

Aequitas 的共識算法大致如下：
(1) 以絕對多數決的方式集合所有節點的交易排序，得到交易彼此之間順序圖（有向圖）：點（Vertex）為交易，邊（edge）為排序優先順序，A 指向 B 代表 A 應排序在 B 之前

Tx A-E 的優先排序，Tx A 排最前面、Tx E 排最後面

(2) 如果圖中有 Strongly Connected Component（SCC），則表示 SCC 裡的交易彼此形成 Condorcet Paradox。接著透過 Graph condensation 演算法將 SCC 壓縮成一個點，形成一個新的圖。

雲裡的三個點形成一個 SCC，表示這三個點形成 Condorcet Paradox，而這三個點會接著被壓縮成一個點，形成一個新的圖。source：https://youtu.be/lB57a2wGo8Y?t=4564

把 SCC 壓縮成一個點其實就表示 SCC 之外的點和 SCC 內部的排序是無關的。對 SCC 之外的點來說，它們要不在 SCC 所有點的排序之前，要不就在SCC 所有點的排序之後，所以可以把 SCC 視為一個點。至於 SCC 裡的交易該怎麼排序？其實只要有一個固定的算法就好，可以所有節點共同擲一個骰子來決定，反正要確保的是這些交易和 SCC 之外的交易排序的公平性。

(3) 如果新的圖中有部分區域已經沒有 Condorcet Paradox，便可以輸出該區域的交易排序：

source：https://youtu.be/lB57a2wGo8Y?t=4573

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 是壞人，它們提供的資訊是錯的，『這個』才是正確的資訊」，這個「正確」的資訊仍然是一個鏈外的資訊，鏈上合約要怎麼分辨哪個才是正確的？

「懲罰惡意 Oracle？沒問題，我再引入另外一群 Oracle 來當仲裁者💪」。source

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 的信任之上。