此组别内的文章

查看更多

MEV（二）：Proposer-Builder Separation

Avatar
Whale
  • 更新
关注

MEV（二）：Proposer-Builder Separation - Banner.jpg

Proposer-Builder Separation 指的是将原本 Proposer 所负责，进行交易排序的工作，分拆给另一个角色 Builder 来负责，让 Proposer 专心验证区块并投票以确保 PoS 网络的安全。

而 mev-boost 其实就是一种 PBS：Builder 透过 Relay 去竞标收入自己区块内容的权利，Proposer 透过 Relay 选择对他最有利的区块内容。复杂的交易排序由 Builder 来计算，Proposer 只需单纯地选择竞标价格最高的区块内容，如此即便是普通人自己跑的 Proposer 都能享受到 MEV 收益，而不必担心自己需要参与激烈的 MEV 套利竞争。

而这篇介绍的 PBS 是 由 Ethereum 协议本身去实行 PBS 的规则，而不再像是 mev-boost 一样是单纯 Proposer、Relay 及 Builder 之间没有强制力的私下协议。

PBS 对 Ethereum 协议本身的好处

在 PBS 中，Proposer 因为不再需要处理交易排序而可以变成 Stateless 的状态，也就是 Proposer 节点不需保存着 Ethereum 完整的状态。负责交易排序的 Builder 才需要保存完整的状态，Proposer 只需要在收到 Builder 区块内容时验证 Merkle Proof 就能确认交易会使用到的 Ethereum 状态，例如 Uniswap 某个 Pool 的余额及 Alice 本身的代币余额，有了状态 Proposer 就能模拟交易执行来确认交易有效性。

MEV（二）：Proposer-Builder Separation - 1.jpg

Proposer 是 Stateless，他不保存 State，只需要验证 Merkle Proof

这让 Proposer 本身的负担又变得更轻，表示成为 Proposer 门坎又降得更低，就有更多人能成为 Proposer，让 Ethereum 变得更去中心化。

另外一个优点是 Dank-Sharding 或 Sharding 都会让区块容量变得更大，表示 Proposer 负担会变得更重。在 PBS 中这些负担是由 Builder 来承担，因此 Proposer 的中心化程度不会受影响。

Rollup 的大补帖：Proto-Danksharding（一）

In-Protocol PBS a.k.a. enshrined PBS (ePBS)

原本在 mev-boost 中是由被信任的 Relay 来担任 Proposer 及 Builder 之间的中间人。Relay 负责保管区块内容，确保 Proposer 会拿到区块内容但不能轻易偷走 Builder 的区块内容。但如果 Relay 是恶意的，则 Proposer 和 Builder 都会受害，且他们只能转向和其他 Relay 合作并期望其他 Relay 不是恶意的。PBS 则是以 Ethereum 协议来取代这个需要被信任的 Relay 角色，如果 Proposer 或 Builder 任一方作恶，都能由 Ethereum 协议本身来施加惩罚（使其付出代价），而不是必须要仰赖对某个角色的信任。

但要移除这个信任的代价不小，首先我们必须要确保

  1. Builder 的区块内容需要被保护，不能直接揭露
  2. Proposer 如果偷走 Builder 的区块内容，他必须要付出代价
  3. Builder 如果没有公布区块内容，他必须要付出代价

综合第 1, 2 点，Proposer 必须要先对 Builder 的区块内容进行承诺（commit），然后 Builder 才揭露实际的区块内容。如果 Proposer 违反承诺，改为 propose 其他区块内容，则他会被惩罚：他的押金被部分没收（即被 Slash）而且他 propose 的区块内容无效，也就是收不到该区块内容的手续费及 MEV。这也是目前 mev-boost 有的惩罚机制。

第 3 点，如果 Builder 没有公布区块内容，Builder 还是要将竞标费用支付给 Proposer。这会由 Ethereum 协议来强制执行，也是 mev-boost 做不到的。

MEV（二）：Proposer-Builder Separation - 2.jpgProposer 或 Builder 作恶都会被惩罚，反之合作则都获益

以上是 PBS 要做到，用来保护 Proposer 及 Builder 的规则，而实际上该怎么完成 Proposer 承诺及 Builder 发布区块内容则有不同方式，后面会介绍。但在那之前，必须要先提到当我们把每个区块的交易排序权利都交给 Builder 时，即便 Builder 会彼此竞争，都还是会比原本交给 Proposer 排序交易来的中心化许多。这迫使我们必须要加入额外的机制来避免 Builder 审查交易。

Censorship

Censorship 最著名的例子是 2022 年八月美国财政部将 Tornado Cash 列入反洗钱制裁名单，许多 mev-boost 的 Relay 纷纷将 Tornado Cash 的交易加入黑名单。这使得 Tornado Cash 用户的交易平均需要比普通交易等上数倍的时间才能被收入区块里。

MEV（二）：Proposer-Builder Separation - 3.jpg

绝大部分 Relay（红色）还是遵从 OFAC，来源 mevWatch.info

注 1：OFAC 甚至将一个只会 Echo 的合约纳入制裁名单。注 2：这篇文章分析 OFAC 制裁对 Builder 的影响。注 3：你可以为自己的 Proposer 节点设置一个最低竞标价门坎，避免全都采用 mev-boost 的区块，藉此增加整体网络的抗审查能力。有将近一半的 mev-boost 区块竞标价都没有到 0.05 ETH 的门坎。

虽然仍有一些 Relay 是不甩 OFAC 的，但在 PBS 中我们没有 Relay、也不能指望为数不多的 Builder 会愿意违背政府的命令。因此我们需要有机制来迫使 Builder 收录指定的交易。

Censorship 成本

在 mev-boost / PBS 之前（也就是纯 EIP-1559 的市场机制），攻击者想要审查一笔最多愿意付 X ETH 的交易（假设交易花费 150k gas），则攻击者必须要不断产生并广播新交易，迫使区块超过半满，藉此把 Base Fee 拉高到 BaseFee * 150k > X，如此该交易才不会被收入。假设每个区块只收入最多 5m gas 的交易（表示攻击者要自己填满剩下的 10m gas 才能保持超过半满），则他每个区块都要烧掉 ( X / 150k) * 10m = X * 66.67 ETH，等同于每个小时要烧掉约 X * 20000 ETH。

但在 mev-boost / PBS 中，如果 Builder Charlie 想要审查一笔交易，他只需要让他的竞标价高过其他 Builder。假设该笔交易的手续费中扣掉 Base Fee 费用后为 P，也就是 Priority Fee 的费用，也就是一个 Proposer 收入这笔交易实际会获得的手续费，则 P 就是 Charlie 在每个区块竞标时都要额外付出的成本（相比于 Charlie 不审查该笔交易，而是开心收入该笔交易）。而这和 EIP-1559 市场机制相比其实是一个非常低的成本，表示 mev-boost / PBS 让 Censorship 变得更容易。

不同 Censorship Resistance 的设计

在 PBS 中，因为我们不能仰赖 Builder 是好人，所以我们只能仰赖 Proposer，透过 Proposer 来 (1) 强迫 Builder 收入疑似被审查的交易，或是 (2) 干脆自己收入疑似被审查的交易。

注意到 (2) 其实打破了前面对 PBS Censorship 的假设，不只有 Builder 可以决定交易排序，Proposer 也可以自己插入交易，也因此 Censorship 自然就没有那么容易（Censorship 的成本会回到和 EIP-1559 市场机制一样高，因为审查者要拉高 Base Fee 让被审查的交易没办法被收入）。

(1) Inclusion List or crList (censorship resistance list)

Proposer 透过指定一个交易列表 crList，要求 Builder 只要区块还有空位，就必须收入 crList 中的交易，直到塞不下为止。

没有交易被审查的情况，crList 会为空。如果一个 Proposer 发现一笔交易的手续费符合规定可以被收入，且过去一段时间的 Builder 的区块都还有足够空间可以容纳该笔交易但却没有收入该笔交易的话，就可以怀疑该笔交易正在被审查。轮到他 propose 时他就可以将该笔交易加入到他的 crList 中，要来竞标的 Builder 就必须要收入该交易，除非区块没有足够空间。

注：一笔交易是否正在被审查是主观的，不一定每个 Proposer 都会看到一样的交易或观察到一样的现象。

MEV（二）：Proposer-Builder Separation - 4.jpg

当 crList 里有交易，Builder 就被迫要收入交易，除非塞满区块或原本就已经满了

如此一来，想要审查交易的 Builder 就必须要将区块用其他交易塞满，除了这些填充用的交易会一直消耗 Builder 的成本，Base Fee 也会因为区块持续塞满而呈指数型上升，导致 Builder 成本跟着指数型上升，其长期的审查成本会远超过单纯 EIP-1559 市场机制的审查成本。

不过想要审查交易的 Builder 可以透过在网络上发布了一系列交易黑名单，要求 Proposer 不要将里面的交易加入 crList，否则就会拒绝产出区块。假设有 Proposer 是好人，他宁愿收益减少也不会理会 Builder 的威胁，那就没问题。但如果假设 Proposer 皆为理性的，则他们会因为经济考虑而配合 Builder。因此如果我们要能在 Proposer 皆为理性的情况下还能做到抗审查，那必须要对 crList 机制做一点调整。

Revised (1): Forward Inclusion List

为了避免 Proposer 和来竞标的 Builder 有利益关系而臣服，在 Forward Inclusion List 中是由 slot n-1 的 Proposer 来决定 slot n 区块的 crList。而因为 slot n-1 的 Proposer 收的是 slot n-1 而不是 slot n 的竞标收益，所以就没有利益冲突的问题。

MEV（二）：Proposer-Builder Separation - 5.png

Proposer 不必担心 crList 会影响到来竞标的 Builder。影响的是下一个 Slot 的 Builder

注：提出 crList 的人不一定要是 Proposer，也可以由其他人来负责提 crList，只要能够避免有利益冲突即可。

(2) Proposer build partial block

除了透过 crList 指定交易的方式，我们也可以让 Proposer 来直接插入交易。依插入的交易安排在 Builder 区块的前或后可以分成 Proposer prefixes 或 Proposer suffixes。

Proposer prefixes 中 Proposer 在 commit 时会先插入他自己安排的交易，然后再告诉 Builder 剩下多少 gas 可以用以及这些交易执行完的状态，让 Builder 能够调整区块内容。

注：这会需要比较弹性的 commit 方式，称作 Slot Auction（后面会介绍），让 Builder 先竞标到产块权利再决定区块内容。

MEV（二）：Proposer-Builder Separation - 6.jpg

Proposer 先插入他安排的交易

Proposer suffixes 中 Proposer commit 时会顺便 commit 一个他想插入的交易列表并交给 Builder，Builder 发布区块内容后 Proposer 再按照列表里的顺序，一一安插交易到 Builder 的区块内容之后，直到区块空间不够或没有剩余交易。

MEV（二）：Proposer-Builder Separation - 7.png

Proposer 先 commit 他想插入的交易，最后如果有空间再一一插入

prefixes 和 suffixes 这两个方法都会加重 Proposer 的责任，而且 Proposer 因为要负责亲自插入交易，所以必须要储存完整的 Ethereum 状态来进行交易运算，也就没办法变成 Stateless 节点。

注：目前比较有共识的是 Forward Inclusion List 的做法。

以上是关于抗审查机制的设计，接下来将继续完成对 Proposer 如何 commit 及 Builder 如何发布区块内容的介绍。

mev-boost 中 Relay 要在区块最终上链之前，确保 Proposer 已经做出承诺、确保 Builder 的区块内容真的存在。我们要怎么取代这个角色呢？我们可以用 Validator Committee 来取代（以下简称 Committee）。另外 Relay 和 Proposer/Builder 之间的沟通管道也会被 p2p 网络取代。

注：目前 PoS 中每个 Slot 会有 1 个 Proposer 及 64 个 Committee 的 Validator要对该 Slot 的区块进行投票。

也因此这个机制的安全性和稳定性就会变成奠基于 PoS 之上：Committee 中非恶意成员不能超过一定比例、网络联机没有出现重大延迟，否则会和 PoS 发生 fork 一样出现错误，导致 Proposer 或 Builder 权益受损。但这还是比原本相信一个中心化角色的安全性来得高。

目前的设计中主要以整个过程多快做完分为 Two Slot PBS 及 Single Slot PBS，也就是将整个过程分为两个 Slot 来做完还是单一个 Slot 就做完（mev-boost 属于后者）。

Two Slot PBS

Two Slot PBS 中，会新增一个 Intermediate Block 的区块类别，用来放得标 Builder 的区块内容。Proposer 在 Slot n propose 一个正常的 Beacon Block，里面会包含对得标 Builder 区块内容的 commit，Builder 接着在 Slot n+1 propose Intermediate Block，里面包含他的区块内容。可以将两者视为同一个大区块，只是分成两阶段（两个 Slot）来完成，第一阶段像是 Block Header，第二阶段才是真正的 Block Body，没有 Beacon Block 就没有后面的 Intermediate Block（因为没有 Beacon Block 就没有赢得竞标的承诺）。

区块都要经过 Committee 投票，变成 Fork Choice Rule 的一部分

这两个 Block 都要经过 Committee 投票（Attestation），但 Slot n 的 Beacon Block 只有 1 个 Committee 对其投票，而 Slot n+1 的 Intermediate Block 则由剩下的 N-1 个 Committee 对其投票。

投给 Slot n Beacon Block 的投票会被收入在 Slot n+1 的 Intermediate Block 里，投给 Slot n+1 Intermediate Block 的投票会被收入在 Slot n+2 的 Beacon Block 里。

MEV（二）：Proposer-Builder Separation - 8.png

直接引用原文里的图片：https://ethresear.ch/t/two-slot-proposer-builder-separation/10980

如果 Builder 一直没有看到 Beacon Block，代表 Beacon Block 可能没有被实时发布，所以 Builder 不会发布 Intermediate Block。但如果该 Beacon Block 过一段时间后出现，是否有可能会导致 Builder 赔钱（必须要支付竞标费给 Proposer）？事实上该 Beacon Block 会因为太晚出现而被其他 Validator 的 Fork Choice Rule 拒绝，所以 Builder 不需要担心。

Single Slot PBS

Single Slot PBS 可以想象成是把 mev-boost 中心化的 Relay 角色换成是去中心化的 Committee：Committee 负责保管区块内容，等到 Proposer commit 得标 Builder 的区块内容后，Committee 再合作还原出 Builder 完整的区块内容并广播出去。

MEV（二）：Proposer-Builder Separation - 9.png

直接引用原文里的图片：https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877

Two Slot PBS v.s. Single Slot PBS

复杂程度

  • Single Slot PBS 不影响 Fork Choice Rule，因此其 Fork Choice Rule 也不需要像 Two Slot PBS 被改得更复杂，进而影响 PoS 分析难度及安全性。
  • 且 Single Slot PBS 和 mev-boost 架构相似，Proposer 和 Builder 不需要做太大的改动就可以切换。
  • 但 Single Slot PBS 需要标准化并实作一套加解密用的密码学技术（目前 Ethereum 本身协议中没有使用到加解密技术）。

区块时间影响

  • Single Slot PBS 在一个 Slot 就能执行完，不像 Two Slot PBS 基本上等于把区块时间延长，两个 Slot 的时间才能有一个 「完整」的区块出现
  • Two Slots PBS 可以选择把 Slot 时间缩短，但代价是对网络状况的要求和各个角色的负担会更高，更容易出错

对 Committee 依赖程度

  • Single Slot PBS 需要 Committee 大部分的成员都在线才有办法顺利解密，如果太多不在线会直接导致无法产出区块内容
  • Two Slot PBS 则不会因为 Committee 成员不在线而无法产出区块内容

加入 crList

如果加入 crList，则 Committee 在对区块投票时（不管是 Single Slot PBS 还是 Two Slot PBS）的规则就要调整一下：如果 Committee 成员在 crList 发布时限之前有收到 crList，则 Builder 的内容需要符合 crList 的要求，如果不符合要求则 Committee 成员当作区块内容没有被发布；如果 crList 没有及时发布，则 Committee 成员不会检查区块内容是否符合 crList 要求。

另外因为 crList 并不是包含在区块信息中，而是透过 p2p 网络传递，所以有可能 Builder 会没收到 crList，这时候他可能就会选择不竞标或降低竞标价格（风险溢价），避免发布区块内容后才发现 Committee 都有收到 crList，就他没有收到，导致区块内容不符合 crList 要求而赔钱。但要真的发生整个 p2p 网络中 Committee 成员都收到 crList，就 Builder 没收到的机率也不高。

Block Auction v.s. Slot Auction

除了目前 mev-boost 中 Builder 对区块内容做竞标，称为 Block Auction，另一种做法是对「产出区块内容的权利」做竞标，称作 Slot Auction。

Slot Auction 给 Builder 更多弹性，他可以先竞标取得产出区块内容的权利再开始组装区块内容，但缺点是 Builder 如果预估错误就有可能因为最后产出的区块内容的 MEV 比竞标价还少而赔钱，不像 Block Auction 中 Builder 可以确定就是会赚这么多钱。

[2023.08 新增] Payload-timeliness Committee (PTC)

PTC 是基于 Two Slot ePBS 的新的 ePBS 设计提案。原本在 Two Slot 中 Builder 的 Intermediate Block 也是一个区块，也会影响 Fork Choice Rule。但在 PTC 中 Builder 组装的区块内容则不会是一个独立的区块，而是由一群 Payload-timeliness Committee（从原本的 Committee 中再选出一群人）来决定 Builder 是否有实时发布区块内容。如果 PTC 判定有实时发布，那下一个 Slot（假设是 Slot n+1）的 Proposer 就会将他的区块接在有 Builder 区块内容的 Slot n 区块后面；反之，则会接在不含 Builder 区块内容的版本中。也就是 Slot n 区块里会不会有区块内容是先由 PTC 决定，然后 Slot n+1 的 Proposer 再参考 PTC 的投票来决定要接在哪个版本（有 Builder 区块内容或没有 Builder 区块内容）后面。

更多细节、优缺点分析与和 Two Slot 版本的比较请参考：https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054

总结与重点

  • PBS 能减轻 Proposer 负担，让网络更去中心化，并能顺利因应未来 Sharding 带来的区块容量大幅提升的挑战
  • 当把交易排序权都交给 Builder，自然必须要担心 Censorship 的问题
  • 有几个抗审查的设计，包含 Proposer 自己排序部分的交易，但目前比较有共识的是采取 Forward Inclusion List 的做法
  • Two Slot PBS 和 Single Slot PBS 是目前 PBS 架构的两种设计，各有优缺点
  • Single Slot PBS 较简单，但也较中心化，仰赖单一个 Committee 成员需在线且诚实
  • Two Slot PBS 较去中心化，和PoS Fork Choice Rule 整合并仰赖多组 Committee 增加安全性但又不需要 Committee 一定要在线，只是缺点是设计较复杂

下一篇将介绍一些 PBS 的补丁，让 PBS 机制及 MEV 供应链更加去中心化。

参考数据与推荐延伸阅读

Rollup-Relay

另外有人提出了介于 MEV-boost 与 In-Protocol PBS 之间的 Rollup Relay：不把 PBS 加在 L1 的共识层及 p2p 层上，而是把 PBS 实作成一个 L2（即把需信任的 Relay 角色换成一个 L2），但缺点是 L2 Sequencer 的角色是需要被信任的。因为这个点子还很新所以这边只做简短介绍，如果未来讨论更热烈会再展开来介绍：https://hackmd.io/@echno/rollup-relay

Special thanks to Lambda Guo, Chang-Wu Chen and Ping Chen for reviewing and improving this post