阅读提示

· 在阅读本文前，需要对 MEV 有基本认知

· 熟悉以太坊交易，了解一笔交易所包含的内容及其最后如何被收进区块

· 知道 Merkle Tree、知道零知识证明的作用

· 点击阅读：MEV（五）：更公平的 MEV 生态系（上）

前一篇介绍了 (1) 透过可信硬件来增加 Block Builder 公正性的 Flashbot SGX Builder 设计以及 (2) 透过将交易排序角色去中心化来防止 MEV 的 Chainlink FSS 设计。

本篇将介绍的是 (3) 透过密码学的方式来为交易提供隐私，从源头来降低或避免 MEV 的设计 — Encrypted Mempools。

Encrypted Mempools

两个目标：MEV 保护及抗审查（Censorship Resistance）

如果有一个工具让用户可以将自己的交易先加密再广播出去，且直到被收入进区块才解密的话，使用者将不必担心被榨取 MEV，因为 MEV Searcher 根本看不到交易内容，用户也不必担心自己的交易会因为被 Proposer 针对或违反政府制裁而被拒绝收入。而建造这个工具的基石就是 —— 密码学。

Encrypted Mempools 利用密码学来 (1) 加密用户的交易内容，保护用户，同时 (2) 在交易被加密的状态下证明交易的有效性，避免攻击者可以透过产生一堆无效但加密过的交易对链发动 DoS 攻击，使得 Proposer 浪费区块空间收入一堆最后一刻才发现无效的交易。

阅读提示：单纯的加密还不能完全确保能抗审查，因为想要审查的 Proposer 还是可以拒绝收入任何加密过的交易，因此加密只是把审查的成本提高（Proposer 放弃所有加密交易的手续费）。要达到更好的抗审查能力保障会需要搭配像是 PBS 的 Inclusion List。

确保交易能被解密（Guaranteed Decryption）

交易加密后必须要确保能被解密，否则会变相变成一个 DoS 攻击的弱点：攻击者持续送一堆最终不会被解密的交易，节点必须要一直保存这些交易直到交易过期，最终节点的交易池都会被这些垃圾交易塞满。

有一些方式能确保交易能被解密（以下中文翻译未必精确）：

1.纯信任（In-flight）

2.可信硬件（Trusted Hardware、Enclave）

3.门坎加密 / 解密（Threshold Encryption/Decryption）

4.延迟加密 / 解密（Delay Encryption/Decryption）

5.见证加密 / 解密（Witness Encryption/Decryption）

△ 确保交易能被解密的几种方式及其实例。复杂度从左到右递增，纯信任最简单，见证解密最困难。

图源：https://www.youtube.com/watch?v=XRM0CpGY3sw

Commit-reveal

那 Commit-reveal 这种机制是否也能达成同样的目的呢？用户先将自己的交易内容丢进哈希函数得到一个哈希值，也就是 Commitment，等到 Proposer 承诺将用户交易的 Commitment 收进区块后，用户再 Reveal 完整的交易内容。

阅读提示：承诺的方式可以像是 PBS 中 Proposer 透过签名承诺会收入 Builder 区块一样，是有保证的承诺，如果 Proposer 违反承诺会受到惩罚。

△ Proposer 承诺会收入 Alice 交易的 Commitment

虽然 Commit-reveal 和加密能达到一样的目的：隐藏用户交易内容、避免被榨取 MEV 及被审查，但 Commit-reveal 却没办法做到保证解密（Guaranteed Decryption），因为 Reveal 的权力是掌握在使用者手上的，使用者可以选择不 Reveal（不管是有意还无意）。

我们可以要求使用者附上押金，当他们最后没有 Reveal 的话就没收押金，但这会让 Commit-reveal 已经不优的使用体验雪上加霜。

△ Alice 可以不 Reveal 她的交易

1.纯信任（In-flight）

用户将交易加密后送给中心化角色，中心化角色解密并确保交易直到被收进区块之前都不会泄露 。用户基本上就是相信中心化角色，当作交易到被收入进区块前都是加密状态（虽然中心化角色收到交易马上就会解密）。

阅读提示：这个中心化角色会是例如 PBS 的 Builder、Proposer 或 Rollup 的 Sequencer/Operator。

2.可信硬件 （Trusted Hardware、Enclave）

和纯信任运作方式一样，只是比纯信任更好，因为使用者是信任一个可信硬件及其执行的程序代码，而不是信任一个人、一个组织或一家公司。

3.门坎加密/解密（Threshold Encryption/Decryption）

Chainlink FSS 也是使用门坎加解密，只是在 Chainlink FSS 中门坎钥匙的管理者们是 Chainlink 的 Oracle 们，而在 Encrypted Mempools 中管理者们（称为 Keyper）可能是 L1 或 L2 的 Validator 们（假设 L2 也有去中心化的 Validator 的话）。

门坎加密/解密有几个缺点：

• Strong honest majority assumption：必须假设过半的 Keyper 是诚实的，如果它们不诚实便可以任意解密看到用户交易，并审查交易或是榨取交易 MEV。
• Lack of accountability：只要超过门坎数量的 Keyper 合力就能解密，而且当 Keyper 联合作恶时，我们没有办法知道到底作恶的是哪几个。Keyper，也就没办法设计惩罚机制，因此我们只能仰赖过半 Keyper 是诚实的假设。
• Weakened liveness：过多 Keyper 下线导致在线的 Keyper 数量不足门坎会导致没办法解密，也就没办法顺利产出区块，链也就会因此停住。这和 Ethereum PoS 机制相冲突：Ethereum PoS 强调即便在第三次世界大战发生时，链还是会持续产出区块，且最终还是可以达成 Finality。可以推断 Ethereum PoS 采用门坎加解密的机率并不高。

因为要采用门坎加解密得要引入不小的改动，因此 L2 会比 L1 更适合采用这种做法 。

这篇文章提出实作在 L1 的设计及考虑，正在试验这个设计的项目可以参考 Shutter Network，了解更多请查阅：https://ethresear.ch/t/shutterized-beacon-chain/12249

4.延迟加密/解密（Delay Encryption/Decryption）

延迟加密可以保证密文（Cipthertext）经过一段时间便能自动解密。不过解密并不是真的自动发生，而是会需要有人担任解密者进行持续的运算，在一段时间（该加密所设计的难度时间）后就能完成运算并成功解密。

延迟加解密背后的概念和 Verifiable Delay Function (VDF) 很像，它们也都是同属于 Time-release Cryptography 这个密码学家族。

VDF 让我们能快速的验证 F(x)：一个「耗时的连续性计算」的计算结果。这和 PoW 很像，但 VDF 的计算是连续性计算（Sequencial Computation），而不像 PoW 的计算是可以透过平行运算来加速，VDF 的解密者只能一步一步老实进行重复计算。

△ 透过 VDF 你可以在例如 0.01 秒内验证我花了 10 秒才完成的计算结果，而且我没办法平行化我的计算。图源：https://techtelegraph.co.uk/verifiable-delay-functions-on-bitcoin

延迟加解密也和 VDF 一样是连续性计算，没办法透过平行化运算来加速。不过都必须要考虑到会有人透过硬件上的优化来加速解密的过程。所以如果要采用这个技术并运用在实际的公开环境中，就必须确保不会有一方有悬殊的硬件差距，能提前先完成解密（而且解密是私底下进行，因此很难察觉）。

目前 Ethereum Foundation 及 Protocol Labs 已经在合作进行 VDF 的 ASIC 芯片研究，希望能输出最先进的计算硬件到市面上，使得没有一方能有悬殊的硬件优势，暗中提前解密，了解更多请查阅：https://filecoin.io/blog/posts/collaboration-with-the-ethereum-foundation-on-vdfs/

阅读提示：VDF 也可以用在 增加 Ethereum 随机数的不可操纵性。

延迟加解密相比于门坎加解密的优点在于不需要相信或仰赖一群 Keypers 正常运作，时间到就会自动解密。但这个强加上的解密时间也是延迟解密的缺点：加密过的交易都必须经过一段时间才能解密，也就表示用户交易上链时间有个固定的延迟时间。另外硬件竞赛也是这个方法不可忽略的风险，我们很难知道是否有人已经研发出更快的芯片来解密。

5.见证加密/解密（Witness Encryption/Decryption）

想象一个密文不是靠密钥或连续计算来解密，而是只有在某个「条件」达成的时候才能解密，例如「当这道等式被解出」就能解密密文或是「当这个密文被收进区块」就能解密密文等等。

阅读提示：「知道解密一个密文的密钥」或是「知道连续计算的结果」其实也是一种条件。

透过见证加解密，我们不仅能做到像是门坎加解密及延迟加解密的效果，我们还能组合这两种解密方式，例如将条件设定成「条件一：『一组 Keypers 同意要解密这个密文』或条件二：『经过五分钟后』」：当 Keypers 都在线时就能很快达成条件一来解密，但如果不够多的 Keypers 在线的话，我们至少能确保可以透过 VDF 证明「已经过了五分钟」来达条件二并解密。

△ 足够多 Keypers 在线（上图）或经过足够多时间（下图）都可以解密

只要能证明条件的达成就能解密，而证明的方式可以透过例如零知识证明，零知识证明可以快速有效地验证一段很复杂的计算（假设证明条件达成的运算很复杂）或隐藏信息（假设证明者不希望证明的过程泄露某些信息）。不过虽然见证加解密非常强大，但现有的技术还不足以提供任何实际用途。

△ 不同加解密技术的成熟度，见证加解密（Witness）还不够成熟。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591

透过同态加密来对密文进行操作和运算

前面的段落介绍了不同方式来确保交易能被解密，但交易什么时候可以被解密？答案是：交易被收入区块、确定排序之后。但 Block Builder 要怎么从一堆乱码中组出一个区块，甚至有效率地组出一个获利高的区块？答案是：同态加密（Homomorphic Encryption、HE）。

△ 同态加密用于投票的范例：投票的内容被加密过，但还是可以对密文进行加总的运算，并在算出结果后解密。图源：https://twitter.com/khushii_w/status/1660278622291210242

阅读提示：如果是透过纯信任（In-flight）或可信硬件的方式加解密，其实并不会真的等到交易收入区块、确定排序后才解密。毕竟都相信对方了，所以它在收到交易后就会马上解密并排序，如此可以加快组出区块的速度，也不需要耗费额外的资源进行同态加密的运算。

透过同态加密我们不需解密就能对密文做运算，不需解密交易就能将排列交易、组出一个合法区块的运算过程套用在这些加密过的交易上，获得一个被加密的区块。当区块被解密后我们会获得一个完整且合法的区块，里面的交易都已解密且是按照加密之前的顺序所排序。

△ 透过同态加密，Block Builder 能从加密的交易中组出一个完整且合法的区块

阅读提示：同态加密有分等级，例如部分同态加密（Partially HE）及完全同态加密（Fully HE）。部分同态加密只能对密文进行加法或乘法，而完全同态加密可以对密文进行加法与乘法（基本上就是可以进行任意运算）。

△ 第三列：不同加解密技术支持 FHE 的成熟度，除了 in-flight 及 enclave 不需进行 HE 所以视为已支持外，其他都还不可用。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620

以上介绍了为交易加解密的不同机制，它们各自有不同的优缺点，但最终它们能做到的都是隐藏交易内容并确保在条件满足时可被解密，交易内容被隐藏后就能避免被榨取 MEV 及被审查的风险。

但事务数据本身会有相关的 Metadata，例如交易发起人、支付的手续费或交易签名，这些是用来验证交易有效性，另外还有交易发起人的 IP 地址也是一种 Metadata，或甚至是交易的数据大小也是。这些 Metadata 都有可能泄露使用者的隐私，因此我们也必须针对这些 Metadata 进行保护。

确保 Metadata 不会泄露隐私

以下列出加密交易的各种不同 Metadata，以及相对应的保护措施，这会需要像是同态加密及零知识证明等密码学技术。

1.IP 地址

2.交易签名

3.交易手续费

4.交易发起人及其 Nonce 值

5.交易大小

△ 交易的不同 Metadata，都有可能会泄露使用者隐私。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709

IP 地址

使用者连上的、用来送出加密交易的网络会因为用户的 IP 地址而可能泄露用户身份，也就有可能被审查。而在网络这一层的隐私保护得仰赖例如 Tor 这样的技术。

交易签名、手续费、交易发起人及其 Nonce 值

这几个 Metadata 是用来证明交易有性，但都会泄露使用者身份，因此都必须加密。加密了我们就必须利用其他的工具来在不揭露这些信息的前提下证明交易有效性，否则网络就可能会被 DoS 攻击，被塞满一堆解密后才发现无效的交易。

一个节点在收到一笔加密交易时，都要 (1) 先确认交易发起人确实有发起这笔交易，也就是对交易签名（signature）进行验证，接着 (2) 确认发起人有足够的 ETH 来支付这笔交易（user balance ≥ gas price * gas limit），以及 (3) 检查发起人的 Nonce 值（sender nonce）来避免交易的重放攻击（Replay Attack）。

零知识证明

我们可以利用零知识证明来在不揭露这些信息的前提下证明交易能通过上述这些检查。一个零知识证明由公开的信息（Public Input）、私人信息（Private Witness）及该证明想要证明的陈述（Statement）所组成。

△ 例如公开信息（public input）是加密的交易（tx ciphertext），私人信息（private witness）是未经加密的交易（tx ciphertext），而这个零知识证明要证明的陈述（zk statement）是「这个加密的交易是合法的」（tx ciphertext valid）。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391

例如假设 Alice 想要向 Bob 证明她有超过 10 ETH，但又不想透露她的地址，则她可以透过一个零知识证明来向 Bob 证明她的地址真的有超过 10 ETH 的余额。

「证明 Alice 的地址有超过 10 ETH 余额」就是这个零知识证明要证明的陈述（zk statement），而为了产生这个证明，Alice 必须提供她的地址及她持有该地址私钥的证明（例如用私钥产生一个签章），另外她也要提供这个地址的 ETH 余额，例如用一个 Merkle Proof 证明这个地址在第 1001 个区块时持有多少 ETH。

地址、签名及 Merkle Proof 这些信息不能被揭露，属于私人信息（ private witness）。

当这个证明产出来后，Bob 便可以将这个证明搭配第 1001 区块的状态树的 Merkle Root（称为 State Root）进行验证，任何人都知道每个区块的 State Root，这属于公开信息（public input）。

Bob 知道的信息只有 State Root 这个公开信息及验证的结果，他不会知道 Alice 的任何私人信息。

△ Alice 提供 Merkle Proof 及签章两个 private input；Bob 提供 State root 这个 public input。而 zk statement 能验证 Alice 有一个地址且该地址余额 > 10 ETH

(1) 验证交易签名

交易签名的验证包含两部分：(a) 交易发起人是合法的及 (b) 交易签名是交易发起人所签的。

(a) 主要是验证交易发起人的 Ethereum 地址是合法的地址，而不是一个随机的随机数，这会透过一个 Merkle Proof 证明该地址存在于 Ethereum 的状态树中。

(b) 则是验证交易签名是该交易发起人的私钥所签的。

△ 这个证明验证 (a) 交易发起人的地址（透过 sender pubkey Merkle proof）以及 (b) 交易内的签名是合法的（签名会包含在 tx plaintext 中）。tx plaintext 是原始未加密的事务数据，是交易发起人提供的私人信息。

图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_736

阅读提示：上图中的红字指的是这个证明验证通过后代表的意思（也就是「交易的签章是合法的」），它并不是 zk statement 的一部分。蓝色的部分是交易本身相关的信息，包含加密过的（公开的）事务数据及未加密过的（私人的）事务数据。绿色的部分是要完成证明所要额外提供的数据，有公开的也有私人的。

△ 证明交易发起人的地址存在于 Ethereum 状态树中且交易发起人真的有该地的私钥

(2) 确认交易发起人有足够 ETH 支付手续费

和前面的 Alice、Bob 证明余额 > 10 ETH 的例子一样，交易发起人要提供自己地址余额的 Merkle Proof，而要证明的陈述是「该地址的余额 ≥ 交易手续费」。交易手续费等于 gas price 乘上 gas limit，gas price、gas limit 这两个信息都包含在原始未加密的事务数据中（tx plaintext）中，tx plaintext 是由交易发起人提供的私人信息。

△ 这个证明验证交易发起人地址的余额（透过 sender balance Merkle proof）大于等于交易手续费（交易手续费信息包含在 tx plaintext 中）。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_743

△ 证明交易发起人的地址的余额 > gas price

(3) 验证交易发起人的 Nonce 值

因为 Nonce 也纪录在 Ethereum 状态中，所以一样是透过 Merkle Proof 来证明交易发起人目前的 Nonce 值，然后和交易里指定的 Nonce 值进行比对，确认交易没有被重放。

△ 这个证明比对交易发起人地址的 Nonce 值（透过 nonce Merkle proof）和交易指定的 Nonce 值（交易指定的 Nonce 值包含在 tx plaintext 中）。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_327

△ 证明交易发起人的地址的 nonce = tx nonce

但这个检查防不了恶意的攻击者产生多笔有同样 Nonce 值的交易（这些交易都能通过 Nonce 值检查）进行 DoS 攻击，因此我们需要加入额外的检查。

我们要求交易发起人要多提供一个 Replay Tag 用来确保同一个 Nonce 值的交易只会有一笔，Replay Tag 是 Nonce 值和交易发起人私钥的哈希值：replay tag = H(nonce, private key)，所以同一个交易发起人的不同 Nonce 值会各自对应到一个唯一的 Replay Tag。

因此节点可以透过 Replay Tag 来识别一个交易发起人是否发起了多笔同样 Nonce 值的交易（这些交易的 Replay Tag 都会一样），并拒绝第二笔有相同 Replay Tag 的交易。

△ 这个证明会计算 replay tag 并与 public input 传入的 replay tag 进行比对。交易的 Nonce 值包含在 tx plaintext 中，而 private key 则是包含在 private witness。

图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_750

△ 证明交易发起人的地址的 nonce = tx nonce 且 replay tag = H(nonce, key)

或如果我们考虑到交易发起人可能会想将同 Nonce 值的交易更换成另一笔交易，或许是因为他不想执行原本的交易了，或是他想拉高 gas price 让交易能更快被收入。

这时我们可以将 PoS 的 Slot 值引入到 Replay Tag 的计算中：replay tag = H(nonce, private key, slot)。例如 Bob 在 Slot 1001 送出一笔 Nonce 为 5 的交易但迟迟没有被收入，所以他决定在其他字段不动的情况下将交易的 gas price 提高一倍，并在 Slot 1005 送出这笔更新过的交易，而因为 Slot 已经改变所以 Replay Tag 是不一样的，这笔新的交易也就不会因为 Nonce 值一样而被拒绝。

△ public input 会再多传入 slot 值来进行 replay tag 计算。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_757

5.交易大小

有些加密方式会使得加密完后的事务数据大小会和加密前一样，而透过大小还是有机率能推敲出一些信息，例如去 Uniswap 执行兑换的交易的事务数据一定比单纯 ETH 转账的事务数据还大，所以交易大小一样是个可能会泄露隐私的 Metadata。

一个直觉的做法是在加密前先将事务数据进行 Padding 的动作，例如补一堆零在后面直到交易大小变成二的次方，或甚至全都补到变成固定大小。藉此降低观察者透过交易大小来识别交易的机率。Block Builder 会将 Padding 过的交易们拼成一个区块。

△ 白色是 Padding。蓝色和橘色的交易会是一样大小，所以没办法用大小分辨出这两笔交易。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860

但这个做法的缺点是 (1) 没效率，因为区块里会有很多空间浪费在 Padding 上，且 (2) 未必能提供足够隐私保护，例如上图中的红色交易的大小（四格）可能很少见，所以还是可能被推敲出来。如果所有交易都固定 Padding 到一个固定的大小（例如 64 格）能提升隐私，但相对地会变得非常浪费区块空间。

△ 缺点是没效率及帮助有限的隐私保护。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_812

更好的做法是交易都先 Padding 到一个固定的大小，但可以利用同态加密来移除 Padding。

交易因为都 Padding 到一个固定的大小，所以观察者看到的所有交易都会是一样大小。而 Block Builder 可以透过一个函式将加密过的交易组合起来并同时顺便移除 Padding。

△ 透过同态加密运算在组合加密交易的同时顺便移除 Padding。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_908

阅读提示：纯信任或是可信硬件的 Block Builder 不需要同态加密就可以达成一样的功效（毕竟都信任它了）。

Block Builder 如何组出效益高的区块

即便我们透过同态加密可以有效率地将加密交易组合成一个区块，但还是有一些问题要解决，例如 (1) 不同交易可能会对同样的状态进行读写（例如都到 Uniswap 交易），引此可能导致排在后面的交易更容易失败，以及 (2) Block Builder 无法按照手续费高低来收入交易。

理想的解决方案是能将 EVM 跑在同态加密里，就像将一个 EVM 放到一个黑盒子里去执行，如此 Block Builder 就能和现在一样透过 EVM 模拟交易执行来组出最有效益、收入最高的区块。但这个技术复杂度太高，还要等很久才有可能实现。

替代方案是交易要附上加密过的手续费与加密过的 Access List（Access List 用来注明该笔交易会读写哪些状态），并用同态加密验证有效性。如此 Block Builder 可以透过手续费决定交易收入顺序，并搭配 Access List 来避免交易彼此互相影响而导致交易执行效益降低。

△ 由手续费搭配 Access List 来决定要收入哪些交易及交易收入顺序。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133

交易出现的时间点

如果担心加密交易被送到 p2p 网络的时间点可能会泄露隐私的话（例如 Alice 都在 UTC+8 00:00–04:00 做交易），我们可以要求 Validator 们定时送出一堆加密过的 Dummy Transaction 来混淆观察者。

Dummy Transaction会需要附上零知识证明来证明是由 Validator 送出且限制频率，避免网络被 Dummy Transaction 塞满（观察者不会知道这是一笔 Dummy Transaction，只知道它是「合法有效的」）。

而 Dummy Transaction 在组区块的同态加密运算过程会被识别出来并丢弃。

△ Validator 们定时送出（灰色的） Dummy Transaction 混淆观察者，但相对地这会增加网络和节点负担。图源：https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1210

Encrypted Mempools v.s. FSS

上一篇的 FSS 中也有介绍到 FSS 也会将交易先加密，然后再交给 Chainlink Oracle 排序。而 FSS 将交易加密、验证加密交易有效性的这个过程其实就和 Encrypted Mempools 是一样的，只是：

• FSS 的交易加密没有提到有针对 Metadata 做保护，而 Encrypted Mempools 则是会将 Metadata 隐藏起来并搭配零知识证明证明交易有效性。
• FSS 目前是采用 Threshold Encryption / Decryption，并由 Chainlink Oracle 联合进行解密，也就是要相信 Chainlink Oracle。而 Encrypted Mempools 则没有指定要用什么方式排序，只着重于将交易进行加密并搭配零知识证明证明其有效性。
• 相比于 FSS 只强调「公平性」，Encrypted Mempools 对「如何有效率地组出区块内容、如何让 Proposer 组出一个最有益的区块而不是只能随机决定交易顺序」有更多着墨。

未来或许 FSS 也会采用 Encrypted Mempools 里的技术来补强或取代其加解密交易的环节。

Tackling MEV with Cryptography

这个 Talk 是 Encrypted Mempools 作者分享能透过哪些密码学技术及 Ethereum 共识层的改进来帮助对抗 MEV 带来的问题，详情请查阅：https://www.youtube.com/watch?v=mpRq-WFihz8

总结与重点

1.Encrypted Mempools 的目的是透过将交易加密来进行 MEV 保护及抗审查。其他人只能知道你的交易是有效的，但没办法知道你的交易里要做什么事。

2.不过要真的达到有效地抗审查还是需要搭配像是 PBS Inclusion List 的机制，否则 Builder 还是可以透过拒绝收入加密交易的方式进行审查。

3.要证明一笔加密交易是有效的并不简单，你需要多个零知识证明来分别证明交易的签名、交易发起人的 Nonce 值、有足够手续费等等。

4.另外还要避免像是 IP、事务数据大小或交易发送时间等等 Metadata 泄露交易的隐私。

5.最后最重要的就是要能确保交易能被解密 —— Guaranteed Encryption，分别有纯信任（In-flight）、可信硬件（Trusted Hardware、Enclave）、门坎加密 / 解密（Threshold Encryption / Decryption）、延迟加密 / 解密（Delay Encryption / Decryption）及见证加密 / 解密（Witness Encryption / Decryption）五种方式，每个方式都有各自的优缺点。

参考数据与推荐延伸阅读

Encrypted Mempools

• https://www.youtube.com/watch?v=XRM0CpGY3sw
• https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
• 密码学如何从应用层及共识层协助解决 MEV 带来的问题：https://youtu.be/jLHf6yw7b5Y?t=4139

Special thanks to Steven Wu, Kimi Wu , Kevin Mai-Hsuan Chia and Anton Cheng for reviewing and improving this post.

声明：

1. 本文转载自[ imToken Labs]，著作权归属原作者[Nic]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。