此组别内的文章

查看更多

MEV（五）： 更公平的 MEV 生态系（上）

Avatar
Whale
  • 更新
关注

MEV（五）： 更公平的 MEV 生态系（上） - Banner.jpg

本篇将介绍两个设计：SGX Builder 及 Chainlink FSS。SGX Builder 能降低 MEV 产业链里的信任成本，Chainlink FSS 则希望能进一步从源头让 MEV 最小化

大家已经习惯 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 问题。

接下来将要依序介绍

  1. Flashbot 以可信硬件SGX 来增加 Block Builder 公正性的设计
  2. 透过去中心化的 Oracle 来决定交易排序，以防止 MEV 的 Chainlink FSS
  3. 用密码学加密交易来保护用户的 Encrypted Mempool 设计（下一篇）
  4. 为 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 节点的顺序。

MEV（五）： 更公平的 MEV 生态系（上） - 1.png

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

因为 Condorcet Paradox 的存在，所以我们可能没办法取得所有节点对交易排序的共识。

注：即便 Condorcet Paradox 不一定会发生，甚至在一个没有故意形成该悖论的环境里很难发生，可是一但发生就会导致共识机制当机，无法产出任何排序。

Aequitas

Chainlink 在 2020 的研究成果 Aequitas 藉由降低排序公平性的标准来绕过 Condorcet Paradox。以下是原本理想中排序公平性的定义（以交易抵达顺序来排序）：

MEV（五）： 更公平的 MEV 生态系（上） - 2.png

如果过半数的节点先看到 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 之前抵达。定义如下图：

MEV（五）： 更公平的 MEV 生态系（上） - 3.jpg

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

Aequitas 的共识算法大致如下：(1) 以绝对多数决的方式集合所有节点的交易排序，得到交易彼此之间顺序图（有向图）：点（Vertex）为交易，边（edge）为排序优先级，A 指向 B 代表 A 应排序在 B 之前

MEV（五）： 更公平的 MEV 生态系（上） - 4.png

Tx A-E 的优先排序，Tx A 排最前面、Tx E 排最后面

(2) 如果图中有 Strongly Connected Component（SCC），则表示 SCC 里的交易彼此形成 Condorcet Paradox。接着透过 Graph condensation 算法将 SCC 压缩成一个点，形成一个新的图。

MEV（五）： 更公平的 MEV 生态系（上） - 5.png

云里的三个点形成一个 SCC，表示这三个点形成 Condorcet Paradox，而这三个点会接着被压缩成一个点，形成一个新的图。source：https://youtu.be/lB57a2wGo8Y?t=4564

把 SCC 压缩成一个点其实就表示 SCC 之外的点和 SCC 内部的排序是无关的。对 SCC 之外的点来说，它们要不在 SCC 所有点的排序之前，要不就在SCC 所有点的排序之后，所以可以把 SCC 视为一个点。至于 SCC 里的交易该怎么排序？其实只要有一个固定的算法就好，可以所有节点共同掷一个骰子来决定，反正要确保的是这些交易和 SCC 之外的交易排序的公平性。

(3) 如果新的图中有部分区域已经没有 Condorcet Paradox，便可以输出该区域的交易排序：

MEV（五）： 更公平的 MEV 生态系（上） - 6.png

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 是坏人，它们提供的信息是错的，『这个』才是正确的信息」，这个「正确」的信息仍然是一个链外的信息，链上合约要怎么分辨哪个才是正确的？

MEV（五）： 更公平的 MEV 生态系（上） - 7.png

「惩罚恶意 Oracle？没问题，我再引入另外一群 Oracle 来当仲裁者💪」。source：https://ercwl.medium.com/whats-wrong-with-the-chainlink-2-0-whitepaper-for-simpletons-d50f27049464

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

Special thanks to Martinet Lee and Peter Lai for reviewing and improving this post