此组别内的文章

查看更多

MEV（三）：PBS 补丁

Avatar
Whale
  • 更新
关注

MEV（三）：PBS 補丁 - Banner.jpg

将 Builder 角色去中心化？

PBS 解决了 Proposer 和 Builder 之间的信任问题，但 MEV 供应链上还有其他角色之间仍然维持着信任关系：Searcher 需要相信 Builder 不会偷走他的 Bundle。如果 Builder 市场变得中心化，Searcher 在这个关系中就更趋弱势。另外 Builder 中心化也可能破坏 PBS 的稳定，如果 Builder 是一家独大（Dominant Builder），则 Proposer 们将被迫配合该 Builder 的各种要求，抗审查机制像是 Forward Inclusion List 就会变成一个装饰。

什么情况可能会导致 Dominant Builder？

Private Order Flow

Private Order Flow 指的是用户将交易直接交给特定的 Builder，而不将交易广播给公开网络。会出现这种情况可能单纯是因为

  1. 该 Builder 提供更好的交易体验或特殊服务给使用者，也可能是
  2. 该 Builder 直接向钱包商或基础服务提供商购买「打包这笔交易的权利」（也就是榨取这笔交易的权利）

其中 1. 的例子像是

  • 透过 Flashbot 的交易只有执行成功才会上链，交易失败则不会上链，也就不会耗费使用者手续费
  • Flashbot Protect 保护用户的交易，避免被榨取 MEV

  • 以前曾出现过的 Taichi Network，将用户交易直接放进自己矿工产出的区块。曾经协助白帽黑客打漏洞把钱拿走，避免被 Searcher 抢跑

  • 未来 Builder 可以提供交易 Pre-Confirmation，也就是提前给用户一个交易会被收入的保证（例如在第 X 个区块一定会被收入）。或是提供免费帮用户取消交易或订单的服务（反正交易都掌握在他手上）。

这些都是因为特殊的服务而获得的 Private Order Flow，这样的 Private Order Flow 对生态系是正向的，因为他能激发 Builder 们去竞争设计更多吸引用户的功能。但 2. 的例子却是不利于整体的，因为透过购买而来的 Order Flow 会让该 Builder 更有竞争力，也能渐渐淘汰其他 Order Flow 更少的 Builder 及拉高新 Builder 加入的门坎，并形成一个正向循环直到最终只剩一个主宰的 Builder。

MEV（三）：PBS 補丁 - 01.png

https://twitter.com/jon_charb/status/1562916395683299329/photo/1

注：钱包商和基础设施服务商会是下一个 MEV 供应链里重要的角色，因为他们掌握了 Order Flow（也就是用户交易）的来源及流向。

以上介绍了 Builder 中心化甚至出现 Dominant Builder 的缺点，接下来将介绍两个目前讨论中将 Builder 去中心化（Decentralized Builder）的方案。

Builder 负责从 Searcher 们那搜集 Bundle 并组出获利最高的 Bundle 组合，作为向 Proposer 竞标的区块内容。因此将 Builder 去中心化的第一个挑战便是 Builder 如何用去中心化的方式组出 Bundle 组合。

方案 1：使用可信硬件取代 Builder

方案 1 使用 TEE（Trusted Execution Environment） 或 TPM（Trusted Platform Module），一个可信硬件来取代 Builder 的任务，这个角色会称为 Aggregator。Searcher 会将 Bundle 内容加密后交给 Aggregator，Aggregator 会以可被验证的方式运行固定的程序代码，因此 Searcher 不必担心 Aggregator 会将 Bundle 内容解密后传给其他人。Aggregator 在收到多个 Bundle 后会计算出最有利的组合，然后向 Proposer 竞标，并在得标后释出区块内容。基本上就是把 Builder 组区块的工作交给一个可信的机器人。

注：这个方案并不是真的将 Builder 去中心化，而是改用一个可信任的硬件来取代原本不该被信任的 Builder 营运商，相信（可被公开验证的）程序代码不会作恶。

MEV（三）：PBS 補丁 - 02.jpghttps://www.youtube.com/watch?v=fAgrIdyWIqc

有了一个可信的角色来处理问题就轻松很多，唯一需要担心的是 Proposer 和运营 Aggregator 的人合谋，运营 Aggregator 的人可能像是原本的 Builder（Builder 整合 Aggregator 到自己的营运系统里） 。当 Proposer 和运营者合谋，就能以 Proposer 签章诱骗 TPM 释出区块内容，然后再偷走里面的 Bundle，最后发布另一个区块内容。在 PBS 中，Proposer 这样的行为是要被惩罚的，但 TPM 没办法确保 Proposer 给它的签名最后会被广播出去当作证据：TPM 只能确保自己本身的执行是正确且可验证的，没办法确保和外界通讯的可靠性。因此我们会需要额外的手段来确保 Proposer 合谋时会被抓到并惩罚，也就是确保证据（Proposer 的签名）是可得的，称为 Proof of Availability (of proposer signature)。

选项一：请负责投票的 Validator 一起确保

负责对 Proposer 区块投票的 Validator 一起来协助确保 Proposer 签名的可得性，Aggregator 会验证这些 Validator 的签名后才释出区块内容。这个选项假设这些 Validator 是多数诚实的，且这会需要 Ethereum 协议的改动（请 Validator 对 Proposer 的签名作签名）。

选项二：使用其他 Oracle 服务

使用例如像是 Chainlink 的 Oracle 服务，要求 Proposer 把签名同时送给 Chainlink，Chainlink 再签名表示自己有 Proposer 的签名。Aggregator 会在验证 Chainlink 的签名后才释出区块内容。这个选项假设 Chainlink 不会一起加入合谋。

选项三：Aggregator 组成一个联盟

多个 Aggregator 可以组成一个联盟，只有在一定数量的 Aggregator 都相信 Proposer 没有和运营者们合谋时才释出区块内容。

MEV（三）：PBS 補丁 - 03.pnghttps://joncharbonneau.substack.com/p/decentralizing-the-builder-role

Flashbot 最新的试验：在 SGX 中进行 Block Building

Flashbot 开源了他们在进行的 Block Building inside SGX 试验：在可信硬件 Intel SGX 中执行 Flashbot 用 Geth 所写的 Block Building 程序。目前遇到的问题是 Ethereum 状态需要太大的储存空间、处理的效能与延迟，未来要能开放让 Searcher 来使用还有许多困难需要克服。

详细可参考：https://writings.flashbots.net/block-building-inside-sgx

方案 2：Aggregator 联盟

和方案 1 的选项三一样，由多个 Aggregator 组成联盟，但在方案 2 中 Aggregator 不是一个可信硬件，而是和原本的 Builder 一样是由服务商所运营，因此方案 2 等于是多个 Builder 组成联盟（以下还是用 Aggregator 称呼）。这样的设计一样仰赖多数的 Aggregator 必须是诚实的，否则就能合谋偷走 Searcher 的 Bundle。

当然我们也不能完全仰赖多数 Aggregator 是诚实的，而是要让他们在合谋犯罪时是可咎责的。Aggregator 联盟会使用门坎签章算法组成一把共同公钥，Searcher 会将他的 Bundle 以这把共同公钥加密（只有超过一定数量门坎的 Aggregator 们才能协力解密 Bundle）后再传给 Aggregator 们，并附上一些信息协助 Aggregator 们去组合出区块内容。因为 Bundle 内容是看不到的，所以 Aggregator 要有办法排序组合这些加密过的 Bundle 就会需要知道每个 Bundle 所牵涉到的账户有哪些，例如一笔 AMM swap 的交易中会牵涉用户 Alice 及 AMM 合约，有了这些信息 Aggregator 在组合排序交易时就能避免安排两个相冲突、使用到同一个帐户的交易而导致区块内容不合法。

注：Searcher 实际上会传送给 Aggregator 们的东西包含：加密过的 Bundle、Bundle 的 Access List（Bundle 里交易牵涉到的所有帐户）及一个零知识证明来证明这个 Bundle 真的使用到 Access List 里提供的账户。

MEV（三）：PBS 補丁 - 04.png

Searcher 要附上 ZK Proof 证明他的 Bundle 真的牵涉到 Access List 里包含的账户

当 Aggregator 组合出彼此不冲突且获利最高的 Bundle 们后，就要执行过一遍这些交易以算出这些交易执行后的状态，然后去向 Proposer 竞标。但这里有个问题：要能算出交易执行后的状态就会需要交易的完整内容，也就是需要解密 Searcher 的 Bundle 内容，但解密后 Aggregator 就可以偷走 Searcher 的 Bundle 内容。所以我们必须要求 Proposer 先做出承诺：承诺他会收进这一批 Bundle（例如对这些 Bundle 做成的 Merkle Tree Root 签章），如果最后 Proposer propose 的区块和他承诺的 Bundle 内容不一样，Proposer 就会被惩罚（被 Slash）。

MEV（三）：PBS 補丁 - 05.pngAggregator 请 Proposer 对 Bundle 签名，作为会包含这些 Bundle 的承诺

MEV（三）：PBS 補丁 - 06.png只有在拿到 Proposer 的承诺后，Aggregator 们才会合力解密 Bundle

不过这个惩罚规则会需要 PBS 机制配合修改或使用像是 EigenLayer 这样的协议（下一段会快速介绍 EigenLayer），因为目前 PBS 设计中，Proposer 不是针对「会收进哪些 Bundle」做出承诺，所以我们没办法在 Proposer 的区块漏了某个 Bundle 时惩罚他。

EigenLayer

EigenLayer 是一个旨在提升 Ethereum Validator 效益和信任成本效率的协议。Ethereum Validator 目前质押了 32 ETH，只单纯负责参与 PoS 共识，如果我们能透过另外的协议来让 Validator 参与到其他各式各样的机制呢？例如 Validator 可以选择同时成为一个 Oracle 为 DeFi 协议提供预言机服务，增加收益。如此 Validator 可以选择透过 EigenLayer 提升他的资本利用率，且整个生态系也不会因为「又一个 Chainlink」的出现而突然又多出了一个新的币只为了「确保该预言机的安全性」，而是可以直接沿用现有 Validator 及其 ETH 的质押，可说是一石二鸟。

因为要能在 Validator 违反规定时惩罚他、收走他的押金，所以 Validator 会需要透过 EigenLayer 的 Restaking 机制将质押的 ETH/stETH 等代币锁进 EigenLayer 合约。Validator 如果有违规的纪录就会在合约里被收取罚金，剩下的才会在 Validator 赎回时退还给 Validator。

MEV（三）：PBS 補丁 - 07.pngEigenLayer 是 Validator 的人力市场，Validator 透过 Restaking 加入 EigenLayer 以获得打工机会

藉由 EigenLayer，Validator 可以自行选择承接其他工作，获得原本 Staking 奖励外的收益。接越多工作的收益就越多，但相对地风险（因违规被罚款）也越高。

透过 EigenLayer，我们就可以弹性地去新增或修改 Proposer 需要遵守的规则，让 Proposer 对「会收进哪些 Bundle」做出承诺，并在他的区块漏了某个 Bundle 的时候惩罚他、没收他的 ETH。

去中心化 Builder 的优势

不管是方案 1 还是方案 2，去中心化的 Builder 对 Searcher 或是整个生态系来说都是一个改善，但我们不能强迫 Builder 变成去中心化，而是要确保去中心化的 Builder 是有优势的，如此才能透过市场来驱动 Builder 去中心化，否则如果去中心化 Builder 没优势，肯定竞争不过中心化 Builder（因为去中心化的成本），那最后一样只有中心化 Builder 能存活。

多个 Builder 联合组成的去中心化 Builder 会比中心化 Builder 有更好的安全保障。以提供交易 Pre-Confirmation（提前给用户保证一定会收入他的区块）这个功能为例，Builder 会需要透过签名来提供保证，让使用者可以知道如果 Builder 违反承诺则他的签名会让他付出代价，例如没收押金。而去中心化 Builder 因为有更多 Builder 参与且都要签名，也就表示加总起来的押金更多，给使用者的保证也就更高。这样的保障也适用于其他 Builder 可以提供的功能、服务。另外多个 Builder 表示会比单一 Builder 有更多 Order Flow 来源，也就更有机会造出价值更高的区块内容，增加竞争力。

当然还有去中心化本身提供的优势，例如 Searcher 可以更安心地交出 Bundle、整个系统的抗审查能力的提升。但相对地去中心化一样有其劣势，例如建置成本较高、使用者请求的延迟时间会因为 Builder 要彼此沟通来达成共识而比较高，另外提供新功能或服务的效率也会比中心化 Builder 来得低。

MEV Smoothing

MEV Smoothing 想要解决的问题是：MEV 并非每个区块都会出现或是每个区块能赚取的 MEV 收益都差不多，事实上 MEV 的出现及收益大小是非常不稳定的。大型的 Staking Pool 会比小型或甚至 Solo 的 Validator 更有机会获得偶发的超高 MEV 收益，因为他们的 Validator 成为 Proposer 的机率更高，长久下来大型 Staking Pool 收益会高于小型 Pool 或 Solo Validator，导致后者被竞争淘汰造成 Validator 中心化。另外这个不稳定性也会让攻击者更有动机去发动 Reorg 来劫走 MEV。

Flashbot 研究员抓取时间长度为四个月的链上信息（约 90 万个区块），模拟有 20 万个 Validator 的情况下每个 Validator 的平均年化，发现 MEV 获利呈现的是一个长尾分布（Long-tail Distribution）而非常态分布。

MEV（三）：PBS 補丁 - 08.png

来源：https://notes.ethereum.org/cA3EzpNvRBStk1JFLzW8qg#Smoothing

第一张图是 MEV 年化（x 轴）与 Validator 数量（y 轴）的关系，呈现长尾分布。

MEV（三）：PBS 補丁 - 09.png

来源：https://notes.ethereum.org/cA3EzpNvRBStk1JFLzW8qg#Smoothing

第二张图是 Validator 百分比（x 轴）与 MEV 年化的第 p 百分位数（y 轴）的关系。当 p=50（x 轴），p-th percentile=1.45（y 轴），表示 50% 的 Validator 年化小于 1.45%。而 Validator MEV 年化的中间值（Mean）是 1.97，整整比中位数（Median） 1.45 高上 36%，且中间值约落在 p=70，表示约有 70% 的 Validator 是赚不到中间值（整体平均）的。

注 1：台积电 2021 年的平均薪资（Mean）是 246 万，比中位数 206 万高出近 20%。总裁薪资是中位数的 194 倍。

注 2：2021 年 Flashbot 即曾以当时的 MEV 数据对 Eth 2.0 的 MEV 进行分析及预估：https://hackmd.io/@flashbots/mev-in-eth2#factoring-in-time-amp-REV-distribution。

Committee-driven MEV Smoothing

而 MEV Smoothing 则是提议让 MEV 收益平均分配给该 Slot 的所有 Validator，而不再是让 Proposer 一个人独占。以这个设计再以上面的数据仿真则可以得到更趋于平均分布的 MEV 年化：

MEV（三）：PBS 補丁 - 10.png来源：https://notes.ethereum.org/cA3EzpNvRBStk1JFLzW8qg#Smoothing

注：所有 Validator 会被平均分配到一个 Epoch 里的每一个 Slot（一个 Epoch 有 32 个 Slot），每个 Slot 的 Validator 会再被平分到 64 个 Committee。

当然 Proposer 不可能愿意主动把 MEV 平分给其他人，所以我们必须改变一下 PBS 机制及共识机制，让 Committee 参与到 PBS 中，给他们话语权，避免 Proposer 和 Builder 连手做一个象征性的竞标过程，然后私底下把 MEV 交给 Proposer 独占。

Validator 投票时要确保 Proposer 选了收益最高的区块

当 Validator 在投票时，除了看 Proposer propose 的区块是否合法且实时 propose 之外，现在要多一个规则是：该区块的 MEV 收益必须是该 Validator 看到的所有竞标中收益最高的，如果 Validator 看到有 Builder 竞标 X ETH 但 Proposer 最后选择另一个竞标费小于 X 的区块时，Validator 就不会投给它。只要有足够多的 Validator 观察到这个情况，Proposer propose 的区块就会因为投票数不够而被舍弃，也就是被 Fork Choice Rule 所淘汰，最后拿不到任何收益（连 propose 的奖励都没有）。

MEV（三）：PBS 補丁 - 11.pngValidator 看到 Proposer 选择最高竞标费的区块所以投给他

MEV（三）：PBS 補丁 - 12.png

Validator 看到 Proposer 不是选择最高竞标费的区块所以不投给他

当然如果 Committee 中有足够多的 Validator 是坏人的话，他们是可以故意不投给 Proposer 的区然后块再抢走他区块里的 MEV 的。不过 PoS 目前已经假设 Committee 大多数 Validator 是好人，毕竟如果大多数 Committee 的 Validator 是坏人，他们是能做出比偷走 MEV 严重许多的伤害。而且偷了以后一样得平分给其他 Validator，所以这个攻击的实际收益并不高。

假设多个竞争的 Builder 并存且网络状况良好

不过在这个设计中，必须假设有多个彼此竞争的 Builder 存在以及 Builder 的竞标信息都能顺利传播给网络中的其他 Validator。毕竟如果只有一个 Dominant Builder 存在，则透过 Validator 投票来迫使 Proposer 选择收益最高的区块也是徒劳无功，因为只有一个 Builder 在竞标而已。或如果 Validator 因为网络问题看不到其他 Builder 的竞标，那效果也是一样受限。

不过我们没办法确保所有 Validator 都能看到每个 Builder 的竞标。有可能因为网络或时间差导致每个 Validator 看到的当前竞标状况不一样，就如同现在网络中每个节点看到的「等待被收入的交易」也不会完全一样。那 Builder 是否可以利用这一点来攻击 Proposer，例如将竞标延后送出导致只有部分的 Validator 实时收到（Proposer 没有收到），藉此诱导他们对 Proposer propose 的区块投下反对票？没错，所以我们会需要设立一个 Builder 竞标的死线，只有在死线之前广播出来的竞标才会被 Validator 考虑，确保 Proposer 和每个 Validator 看到的竞标情况能够越一致越好。

MEV（三）：PBS 補丁 - 13.png在死线前只有 Builder B 和 C 送出竞标

MEV（三）：PBS 補丁 - 14.pngBuilder A 死线后才送出竞标，虽然竞标费更高，但一样不会被 Proposer 和 Validator 接受

MEV Burn

MEV Burn 是近期提出的构想，大意是将 MEV 也变成像 EIP-1559 Fee Market 里的 Base Fee 一样给烧掉。Proposer 躺着赚 Builder 的竞标费，但会有像前面 MEV Smoothing 提到的大型 Staking Pool 比小型或 Solo Validator 更容易获得高额的 MEV 收益，如果改成将这笔收益烧掉，那Proposer 就不会因为 MEV 收益而导致大者恒大、中心化的问题（因为 MEV 收益都被烧掉了），所以这其实也是一种简单版本的 MEV Smoothing — 直接烧掉 MEV 收益，让 Proposer 都只靠区块奖励过活。

MEV Burn 大概的运作机制是将 Builder 的竞标机制复制搬到 Proposer 中，每个 Slot 会有多位 Validator 被选出，可以竞标成为 Proposer 以获得区块奖励，而竞标费用来源就会是 Builder 的竞标费用。得标的 Validator 成为 Proposer，propose 出价最高的 Builder 的区块，从 Builder 那获得区块内容的竞标费，但同时也要上缴自己成为 Proposer 的竞标费，然后协议会将 Proposer 竞标费烧掉，并给予 Proposer 区块奖励。

MEV（三）：PBS 補丁 - 15.png

被选出的 Validator 也要透过竞标才能成为真正的 Proposer

当然 Validator 也可以尝试竞标少一点的价格，藉此从 Builder 竞标费与自己竞标费的价差赚点钱，但因为每个 Slot 会有多个 Validator 被随机选出，所以除非你能掌控所有被随机选出的 Validator，否则每个 Validator 都会按照各自看到的最高的 Builder 的竞标价，去出价竞标成为 Proposer，而且两个价差之间预期会非常小，因为如果 Validator 竞标失败就根本成为不了 Proposer，也就赚不到想赚的价差，甚至是区块奖励。

除了能达成类似于 MEV Smoothing 的功效，另外的好处是让 ETH 能捕捉到链上活动产生的价值（也就是 MEV），而不只是单纯的作为手续费媒介。而且烧掉更多 ETH 也能增加 ETH 作为资产的价值。以上这两个好处都特别吸引看好 ETH、将 ETH 作为投资目标的人。

不过这个构想还很新，且也有反对的意见，想了解可多可以参考 Ethresearch forum 的文章 及 Flashbot forum 的文章。

另一种更兼容目前 PBS 的竞标设计

后来也有另一种 MEV Burn 设计被提出，在这个新的设计中 Proposer 维持原样：每个 Slot 固定一个 Proposer，Validator 不需竞标成为 Proposer。Builder 一样竞标收入自己区块的权利，但其中竞标费会像 EIP-1559 一样分为 Base fee 及 tip 的部分，Base fee 会被烧掉，而 tip 会给 Proposer。

而其他投票的 Validator 会负责确保 Validator 选的竞标费不会太低，避免 Proposer 和 Builder 合谋来避免 MEV 被烧掉，分赃 MEV。Builder 的竞标会公布到 p2p 网络中，负责投票的 Validator 会监看这些竞标费并确认最后 Proposer 选择的竞标费有高于投票 Validator 观察到的最低的竞标费。如果低于最低竞标费，表示 Proposer 可能和 Builder 合谋，那 Validator 就不会投给该 Proposer。

这个设计会需要

  1. 假设网络顺畅，否则 Proposer 有可能真的会没收到竞标信息
  2. 假设投票的 Validator 大部分都是诚实的，避免故意不投给诚实的 Proposer
  3. 假设有多个 Builder 在竞争，否则如果只有少数的 Builder 在竞争，则 Builder 很容易结盟一起控制竞标费

不过以上这三点假设基本上都是目前 PoS 机制与 PBS 机制已经有的，所以这个 MEV Burn 设计不会额外引入新的安全假设。

Protocol Enforced Proposer Commitment (PEPC)

虽然 In-Protocol PBS（以下简称 IP-PBS）的设计还在讨论中，但可以确定的是这个机制将会有「非常明确」的设计，这里的明确并非指清晰明了，而是相对于一般性、通用性，这个机制明确定义了「该怎么做」来「解决某个问题」。例如要解决 Censorship 问题，则机制会加入 Inclusion List、Forward Inclusion List、Proposer build partial block 等等；如果想要让 Builder 更有弹性地去建构区块，则可以将竞标内容从 Block Auction 改成 Slot Auction；然后还有共识机制要搭配看是 Single Slot PBS 或 Two Slot PBS 去更改。

于是 PEPC 的作者提出一些问题及思路：我们真的要将这个机制设计得这么「明确」吗？我们确定这些「明确」的机制真的可以有效解决相对应的问题吗？这些机制是否有额外的副作用，可能在日后才会浮现？回到 PBS 的初衷：让 Proposer 负担越轻越好（才能保持 Validator 去中心化），但加入了这些机制后真的有让 Proposer 负担变轻吗？例如 Proposer build partial block 中 Proposer 也要负责建构一部分的区块，或像是 Inclusion List 设计中要考虑 Proposer 有可能受制于 Builder 的经济诱因威胁而不能单纯地假设 Proposer 会勇敢对抗审查的 Builder。

另外如果 Proposer 和 Builder 结盟，他们便可以绕过竞标过程，私下达成协议（例如 X 个 Slot 之前就先谈好到时候会由 Builder 得标），等同于绕过 IP-PBS。而这个可能性就有机会造成积极的 Proposer 和被动的 Proposer 之间的收入差异，如果差异显著，则会让 Proposer 都加入积极寻求增加收益的队伍，也就和我们希望 Proposer 负担越轻越好的目标背道而驰。

因此他提出了 Protocol Enforced Proposer Commitment（PEPC） 的设计：由协议来强制执行 Proposer 是否遵守承诺所对应的奖赏及惩罚，而和 Proposer 缔结契约（立下承诺）的对象则不再限定是 Builder，可以是任何人，且契约内容也不再只有 PBS 中「买卖生产区块内容的权利」的契约，而可以是各式各样的契约内容，只要契约内容的条件能写入智能合约中来实行。

MEV（三）：PBS 補丁 - 16.pngProposer 和第三方立下各式各样的契约，并由 PEPC 强制执行奖赏和惩罚

In-Protocol EigenLayer

而我们其实已经有一个可以让 Validator 和任意第三方进入任意合约关系的设计了，也就是 EigenLayer。因此我们只需要将 EigenLayer 整合进 Ethereum 协议中，就可以有一个协议层级的 Validator 人力市场。

注 1：将 EigenLayer 整合进协议中也能顺便弥补 EigenLayer 的一个缺点 — Validator 在 EigenLayer 上被惩罚不会反映在共识层上，也就是共识层不会知道这个 Validator 在其他地方作恶被惩罚了，对共识层来说这个 Validator 还是尽责地在履行他的义务。将 EigenLayer 整合进协议后，共识层就可以知道 Validator 在 EigenLayer 上被惩罚并藉此作出反应，例如扣除他在共识层的押金。

注 2：这里以 EigenLayer 为例，但未来如果有其他 Restaking 机制都可适用

以 PBS 为例

PBS 中「Proposer 贩卖生产区块内容的权利给 Builder」会是 PEPC 中众多 Proposer 可以立下的契约之一，在这个例子中 Proposer 所立下的承诺（Commitment）会是：「我会 propose Builder B 所生产的区块内容，这个区块内容的 hash 值是 X，如果我 propose 了另一个区块内容（其 hash 值不是 X），则我的 ETH 押金会被没收」，这个承诺所定的条件及惩罚都会在 EVM 中去检查并实行。

注：这会需要 EVM 能够知道 Proposer 在共识层所 propose 的区块内容，所以会需要新增一个 Opcode 来让 EVM 能读取共识层的区块内容。

如果 Proposer 的对手方违反承诺，例如 Builder 最后没有公布区块内容，则 Builder 一样要付钱给 Proposer。在 IP-PBS 中 Proposer 和 Builder 的契约规则是写在共识层，所以共识层可以直接在 Builder 违反承诺时没收他的钱，但在 PEPC 中则需要将 Builder 的承诺「我愿意付出 N个 ETH 来换取生产 Proposer P 的区块内容的权利，我的区块内容的 hash 值是 X」变成一个可以在 EVM 中实行的规则，可以是一笔交易或是一个签名，兑现的条件就是 EVM 确定 Proposer P 的区块内容的 hash 值的确是 X，只要 Proposer 的确 propose 该区块内容就可以从该 Builder 身上拿走 N个 ETH。

MEV（三）：PBS 補丁 - 17.pngEVM 可以读取到共识层区块内容，所以可以判断 Builder 是否该付钱

如果是 Proposer 违反承诺，则证据（Proposer 做出承诺的签名及实际 propose 的区块内容）也都非常清楚明白，可以直接在 EVM 中检查并惩罚 Proposer。

MEV（三）：PBS 補丁 - 18.pngProposer 违反承诺，EVM 可以判断 Proposer 是否该被惩罚

负责投票的 Validator 所扮演的角色

但如果违反承诺（例如偷走 Builder 的 MEV）所赚的钱更多， Proposer 宁愿被惩罚也要 propose 另一个区块呢？在 IP-PBS 中，负责对 Proposer 区块投票的 Validator（Attester）知道 PBS 的规则，所以如果发现 Proposer 违反承诺，则他们不会投给他的区块。但在 PEPC 中，共识层不会知道这些（各式各样的）契约规则，这些契约规则都是执行层（EVM 里）的规则，所以 PEPC 中即便 Proposer 违反承诺，Validator 仍然会投给他的区块。

不过投票的 Validator 真的没办法知道 Proposer 是否有违反承诺吗？其实应该是可以的，毕竟我们都已经假设 EigenLayer 被整合进去协议里了，Proposer 是否违反承诺应该是可以验证的吧？例如在 p2p 网络里分享传递着 Proposer 的承诺、违规证据等等，然后 Validator 也将 EigenLayer 契约检查逻辑整合进去，投票时顺便检查 Proposer 是否有违反在 EigenLayer 上的承诺。如果 PEPC 被采用，可预期各种验证 Proposer 的承诺的工具会慢慢成熟，方便让 Validator 验证 Proposer 是否违反承诺。例如执行一笔简单的 EVM 交易检查 Proposer 承诺给 Builder 的签名，及检查该区块内容是否真的是该 Builder 所生产的区块内容，检查不通过则回传 False 或 revert。

MEV（三）：PBS 補丁 - 19.pngValidator 检查收到的 Proposer 承诺及证据来投票

我们可以要求 Proposer 要主动在区块内附上这样的检查，如果没有主动附上检查证明自己有遵守承诺，则 Validator 就不会投给他的区块。更进阶一点，我们也可以把负责投票的 Validator 也加进这份契约中：如果 Validator 投给违反承诺的 Proposer 的区块，则 Validator 也会被没收押金。

MEV（三）：PBS 補丁 - 20.png要求 Proposer 要主动附上证明，证明自己有兑现自己的承诺

注：Proposer 要能在区块内附上检查表示 Proposer 要能安插交易到区块内容里，也就是不能让 Builder 完全决定区块内容。这会需要采用例如在前一篇提到的 Proposer prefixes/postfixes，或其他类似的做法，例如特别规划一个 10 万 Gas 的额度给 Proposer 放他的交易。

以上是关于 PEPC 的介绍，PEPC 提供一个更通用的 Proposer 承诺框架，避免如 IP-PBS 定死各种 Proposer 与 Builder 之间的游戏规则而导致未来假设发现规则有漏洞或规则老旧时，难以进行更新或需要硬分叉来更新。

而至于更通用的 Proposer 承诺到底会让 Proposer 变得更轻松还是更繁重则还有待讨论及研究。

总结与重点

  • 不好的 Private Order Flow 会导致 Builder 中心化，对 MEV 生态系造成负面影响
  • 去中心化 Builder 成本较高，效能也会比中心化 Builder 高，但仍然有其优势。如果能将 Builder 去中心化，Searcher 及使用者都将受惠
  • MEV Smoothing 旨在解决 MEV 收益呈现长尾分布而导致大型 Staking Pool 比小型 Staking Pool 或 Solo Staker 平均能获得更多收益的问题，作法为将 MEV 收益平均分配给 Proposer 及所有投票的 Validator
  • MEV Burn 则像是 MEV Smoothing 简单粗暴的版本，直接烧掉 MEV 收益就不需担心大型 Staking Pool 长久下来会占有更大优势，且也能同时增加 ETH 的价值捕获
  • PEPC 有别于 IP-PBS 定死 PBS 相关的规则，提出一个通用的 Proposer 承诺框架，让 Proposer 能选择有更多弹性的规则去做出承诺

下一篇我们将焦点移到 Proposer/Builder 之外，介绍几个从应用、使用者角度出发的设计，让这些角色从被动的一方转变为主动的一方，并在 MEV 生态系中获得一席之地

参考数据与推荐延伸阅读

Private Order Flow:

Decentralizing Builder:

MEV Smoothing:

MEV Burn:

PEPC:

Special thanks to Lambda Guo, Chang-Wu Chen and Kevin Mai-Hsuan Chia for reviewing and improving this post