来源|?notes.ethereum.org
作者|VitalikButerin
特别感谢Francesco提出解决方案2里的核心想法，并感谢Francesco、JustinDrake、AlexObadia和PhilDaian的反馈和评论。
区块提议者/构建者分离方案是如何运作的？
在现行的交易市场里，区块提议者?(当前是矿工，合并后是验证者)直接通过看交易池里哪些交易支付最高的小费来选择哪些交易被打包到下一个区块。这使得区块交易者可以使用复杂的策略来选择打包哪些交易，或甚至打包他们自己的交易，以利用像DEX套利和清算的机会(为了简洁，下文只称为MEV)来最大化他们的收益。这些策略的复杂性给运行一个有效矿工或验证者节点造成很高的固定成本，并使得代表其参与者使用这些策略的中心化池占据优势。
区块提议者/构建者分离(PBS)?方案通过把区块构建的角色从区块提议者上分离开来解决这问题。分离出来的一类行动者叫构建者(buiders)，他们构建执行区块主体(execblockbodies)?(基本上是一个有序的交易列表，这些交易会成为区块里的主要负载)和提交出价。提议者的工作就只是接收出价最高的执行区块。值得注意的是，提议者(和其他所有人)直到他们选择了在竞价中胜出的区块头(即也选择了区块主体)后都不知道任何执行区块主体里的内容。这种确认前的隐私(pre-confirmationprivacy)?对以防止“MEV窃取”是有需要的，因为懂行的提议者会发现构建者的MEV提取策略并复制它们而不分给构建者。
PBS与现状相比，有哪些抗审查挑战？
首先是现状，假设有一笔150kgas的交易，且当前的gas上限是30m(目标是15m)。经济实力强的行动者试图审查该交易。在当前的交易市场里，如果该笔交易愿意支付基本费和多于1~2?gas的小费，区块提议者就会愿意对其打包；平均每个区块有大约15m的gas松弛空间让他们这样做。要审查一笔发送者为打包愿意支付x的交易，攻击者需要把基本费提到高于每gas?X/150k，并将其保持在那里。如果他们这样做了，其他用户将因费用太高而退出竞价——毕竟，如果基本费高到足以让一笔重要到足以吸引有人试图进行针对性审查的交易退出，攻击者将可能必须自己支付区块中交易费最贵的交易。保守地说，攻击者很可能必须自己支付高达每slot?(X/150k)*10m=X*66.7?(因此大约是每小时?x*20000?)
Watcher.Guru：Vitalik Buterin撰写以太坊白皮书时只有19岁:金色财经报道，Watcher.Guru发推特表示，Vitalik Buterin撰写Ethereum白皮书时只有19岁。[2023/2/20 12:16:52]
现在，让我们来探讨一下PBS的情况。假设有一个区块构建者一直比其他构建者表现更好，要么因为他们说服不老练的用户运行只给他们发送交易的钱包("专有订单流")，要么因为他们有更好的算法和数据访问来发现MEV机会。假设有一些特定受害交易是构建者(“审查构建者”)试图审查的。设：
M?为在没有受害交易的情况下非审查构建者的出价P=X-basefee*150k?为受害交易总交易费的小费部分M+P?为受害者交易能够被打包的情况下非审查构建者的出价A?为审查构建者获得的优势(advantage)(等于他们所赚的费用+MEV与非审查构建者可以赚最多的费用+MEV的差值)M+A?是审查构建者的出价，无论是否有受害交易(因为审查构建者不想打包受害交易)
如果?P>A，非审查构建者将能够给出比审查构建者的0收益出价(M+A)高出?P-A?的出价。为了保持审查，审查构建者将必须把他们的出价提高到?M+P，并每slot损失?P-A?以保持出价高于非审查构建者(还要额外牺牲每个slot获利A的机会，因此总损失是每slot?P?)。这样成本仍然很高。但请注意这比每slot?X*66.7?要便宜得多。
如果?P<A，尽管不打包受害交易，审查构建者也能赢得竞拍，虽然他们的确不得不把他们的出价提高到稍稍高于?M+P?，从而牺牲了每个slot的?P?收益(审查构建者的收益变成?A-P?而不是?A)。
请注意，在两种情况里，攻击者都会因为审查而损失每slot的?P?收益?——对于仅是把一笔交易排除在链外来说，这仍然是一个巨大且持续的成本，但远不像每笔交易在费用市场中的成本那么高。
?PBS的审查经济学和出块时间
上述分析的一个重要结果是，在PBS里，审查的成本是按每slot算的(严格来说是每个区块，但为了简单，我们忽略两者的区别，因为实际上以太坊上几乎所有slot都有一个区块)。如果出块频率减低10倍，审查成本会减少10倍。如果出块频率增加10倍，审查成本就会增加10倍。这是反直觉的，但与上一部分的逻辑是一致的。请特别注意，现在的收费市场有点像PBS，有100多个竞价同时抢一笔交易的打包位置；但是，这是一个有问题的PBS市场，因为它缺乏确认前的隐私保护。
OKEx将于5月26日19时暂停VITE充提:据官网公告，由于VITE主网升级 ，OKEx将于2020年5月26日19:00 暂停VITE的充提，待升级完成后开放。[2020/5/26]
因此，很自然要问这样一个问题：我们能否尝试扩展PBS，以实现快速出块，但使得那些区块是并行出现而不是按顺序的？
抗审查方案有哪些设计目标？
DOS保护和没有免费的数据可用性：提议者(或构建者)不应该能够打包没人支付的数据，因为这可能会被攻击者利用，使链数据膨胀，或给rollup交易费用的机会。例如，这意味着如果一个区块包含了一笔交易因为余额不足或同一个区块里其他交易而被证明是无效的，协议必须仍然向提议者收取该交易的基本费。
最小额外带宽消耗：这个机制不应该只对链上数据有效，对p2p网络上的数据也要有效。举个例子，在网络上漂浮着数百个来自不同构建者的冗余完整区块主体是不现实的。
不再重新引入提议者中心化：PBS的全部意义就在于它不需要提议者是老练的。我们不希望创建一个机制会为老练的提议者重新引入好处，从而激励提议者进入进一步的协议外竞拍关系或加入池。
理想情况下，允许提议者是无状态的：验证者能够变成完全无状态(一旦Verkletrees被部署到了主网)将会是进一步去中心化和提高可扩展性的一个重大福音。
如果我们依赖利他主义，不要让利他主义变得昂贵：我们一般可以依赖这样一个假设——至少有百分之几的提议者是利他的，且将忽略贿赂出价和接受被审查的交易。但是，如果这样做在协议内是成本高的，这个假设就会变得很不现实。提议者不应该必须牺牲大额收益来帮助确保被审查的交易能被打包。
解决方案1：我们可以同时运行很多确认前隐私PBS竞价吗？
假设在每个slot里有一个竞拍是用于主要执行区块?(primaryexecblock)?和有?N-1?个竞拍是用于辅助执行区块(auxilaryexecblock)?(因此总共有?N?个竞拍)，且它们是并行运行的。这些区块是按顺序被执行的(顺序为先主后辅)，但它们共识的达成是平行进行的。
假设一个交易发送人愿意支付?P?小费。要把该交易排除在链外，审查者将需要愿意给每个辅助执行区块竞拍的控制员每slot?P+1，因此他们将必须支付每slot(P+1)*N。
动态 | EOS 的Activity指数为43,721,037 排名第一:据IMEOS报道，截止12月16号11点，blocktivity.info上显示，排名第一的 EOS 的Activity指数为43,721,037 ，排名第二、第三分别为 TLOS 和 IOST 。Acitivity指数为最近24小时内在区块链上执行的操作数量。[2019/12/16]
攻击者必须每个slot都出价，且不仅当有人试图进行辅助打包时才需要出价，因为如果攻击者只自动出价高于辅助打包，提议者会开始提交虚假的自我出价来迫使攻击者出价高于他们。
但有一个问题：辅助执行区块会如何被构建？构建主要执行区块的构建者("主要构建者")会相对比较简单，因为他们看到他们正在构建的区块所建基的前状态：这是前一个区块的后状态。另一方面，构建辅助执行区块的构建者(辅助构建者)则没那么幸运：他们在同一个slot里构建的任何区块都需要基于主要执行区块(和较底部索引的辅助执行区块)。因此，当辅助构建者在选择打包哪些交易是并不知道他们要基于什么状态来构建的。
如果一个辅助构建者打包一笔已经被打包到前一个区块的交易，他们必须支付直到签名和随机数验证前的数据和执行的gas，但他们不会得到来自该笔交易的手续费。因此，他们会损失钱?(在这种情况下设计一个免除数据+验证gas费的协议是不安全的，因为这可能会被rollup和其他存储数据到区块链的用例滥用)。
这就提出了一个问题：辅助构建者是否有一个安全策略来打包交易到辅助执行区块？这个策略在正常情况下应该是可获利的(预期里)，且如果一个会进行审查的主要构建者明显正在试图攻击他们时能提供保护。一个攻击的可能例子是，一个会进行审查的主要构建者可以在直到他们预见有辅助构建者开始打包交易时突然打包那些交易，从而实现审查。如果他们一直这样做，他们可以导致辅助构建者亏钱；一旦辅助构建者亏损太多，他们就会退出市场，让会进行审查的构建者可以自由审查交易。
?最低限度可行的辅助构建者策略
请记住，在“好的情况”下，辅助区块会是空的，因为任何想被打包的交易都会被打包到主要区块。因此，这个策略只需要在审查真的发生的时候才激活。
设：
N?=每个slot上发生的竞拍总数(包括主要的和辅助的)P?=交易小费B?=当前的基本费首先，为了简单起见，假设?N=2?(因此，每个slot只有一个辅助执行区块)。也假设?P=B?(审查的受害者总是支付两倍的费用，以吸引辅助构建者和避免审查)。下面是一个建议的辅助构建者策略：
动态 | Stellar发布公告提醒用户警惕欺诈性空投活动Stellar-Activity:Stellar官方Reddit发布公告，提醒用户警惕欺诈性空投活动。最初是StellarShade然后变成Stellar Dolphin Fork，现在叫Stellar-Activity（XLA）。此类局使用相同的运作模板进行——先是在bitcointalk.org发帖称将在某一特定日期进行大空投，然后开始发放赠品，推行营销策略以在社交媒体上吸引不知情的粉丝来传播这一消息，粉丝们在不知情的情况下间接地进行二次传播，致使更多的人上当。子们声称将会以2:1的比例给你提供XLA（每持有1XLM就给予2XLA），然后诱使你在他们的账户查看器里输入私钥，之后盗取你所有的账户存款。[2018/12/2]
如果一个辅助构建者看见一笔交易在?k?个slot前第一次被接收，但还未被打包，并且从那时起就一直有效，那么构建者应该在他们的提议区块里打包这笔交易的概率是。
假设会进行审查的主要构建者在k个slot后接受了受害者交易。要么?k=0，在这种情况里他们只有?0.00000001?的机会能“陷害”辅助构建者(意思是，审查构建者和辅助构建者在同一个slot里发布，导致他们会亏损钱)，要么?k>0，在这种情况下攻击者陷害辅助构建者的概率与辅助构建者先于攻击者打包受害交易的概率相等(即??，因为k≥1)。
在后一种情况下，辅助构建者平均来说是不赚不赔。这是因为在攻击者陷害他们时，他们亏损?B，而在他们打包了一笔交易时，他们获利?P，而我们在上文假设?P=B。将指数基数降低到?2?以下，使数学运算更简单，并确保辅助构建者是可获利的。我们可以通过把基数设为??延展到任意小费。
而?N>2?的情况比较棘手，因为有可能出现干扰：如果一笔交易同时被打包到两个辅助执行区块呢？但是，如果我们假设辅助构建者使用独立的随机策略，发生冲突的机会是可控的(一个模拟脚本表明，如果基数是2，无论有多少名构建者，P都接近于1/4)。
在实践中，上述的数字几乎肯定是太悲观的。被审查的交易可能在几个slot后就被辅助构建者打包了，而辅助构建者将对攻击作出动态反应。此外，交易失败时的成本比成功时低，所以在实践中，?P?仅需要大量交易的几个百分点的?B。相反，上述内容更多的是作为一个存在证明，即辅助构建者可以使用固定的特定策略，甚至在攻击下也能获利。
金色财经现场报道 以太坊创始人Vitalik Buterin：验证节点的“4个不要”:金色财经6月3日现场报道，在今天的以太坊技术及应用大会上，以太坊创始人Vitalik Buterin做了题为“Casper与分片技术最新进展”的主题演讲。V神介绍说，验证节点不要加入跟别人一样的权益池，不要用跟别人一样的VPS，不要使用跟比人一样的操作系统；不要用跟别人一样的客户端。[2018/6/3]
在主要执行区块内容已知后，为什么不让辅助构建者通过一个位字段选择要排除哪些交易到链外
一个位字段仍然携带足够多的信息，攻击者可将指令编码到智能合约，以了解如何利用MEV机会。此外，如果有多个辅助构建者，他们将必须按顺序提供他们的位字段。因此，这将简单地将辅助竞拍转换为一系列主要竞拍。
解决方案2：我们是否仍然可以使用提议者(“混合式PBS")，但仅用作”打包的最后手段”
防止审查的另一个自然想到的方法是把当前的交易费用市场和PBS融合起来。这种方法将依靠提议者来抗审查。只有少数提议者需要实际上使用这个方案；即使95%的提议者不知怎么地就成功被贿赂了，都假装没有看到交易并只接受PBS机制下产生的区块，剩下的5%意味着，平均来说，任何受害交易仍会在20个slot后被打包。
这个方案的工作原理如下。在每个slot：
1.提议者广播?crList，这是提议者看到的应该被打包的交易列表(即它们的状态里有正确的随机数和被打包的充足余额、小费和最高基本费)。这个?crList?只能包含一名?sender?(发送人)的一笔交易。提议者也要对一个?crListSummary?签名和广播，它包含在?crList?上每笔?tx?的?tx.sender?和?tx.gaslimit。
2.构建者创建一个提议主体，它必须包含在?crListSummary?里
3.提议者接受胜出的区块头
4.构建者发布主体。主体的验证需要检查在?crListSummary?上的每个?(sender,gaslimit)，要么是否?block.gasused+gaslimit>block.gaslimit，要么?sender?是否区块里某笔交易里的发送人。
为了进一步节省空间，还有一个更复杂的替代方法，就是要求?crList?按照?tx.gaslimit?的降序排序，然后要求主体只包括(i)在?crList?上不能被打包的第一笔交易的Merkle证明，和(ii)区块中那些在?crList?上的交易的位字段。任何人都可以通过重建Merkle证明之前树的那部分并检查它是否与Merkle证明相符来验证。
请注意，无论哪种解决方案，如果提议者错误地构建了?crList，构建者可能无法安全地提议一个执行区块主体。在这种情况下，构建者应该就直接不提议任何东西，就像提议者根本没有广播过?crList?一样。
?融合PBS和无状态
PBS的一个重要的次要目标是允许验证者是完全无状态的(一旦Verkletrees被部署了)。PBS会实现这点是因为只有构建者需要真正地构建主体；构建者还负责附上见证数据(witness)到他们的区块，使得验证者可以在无状态下验证区块。
而要把这个属性扩展到这个方案，每笔交易都需要伴有一个简单的见证数据，证明交易发送人的余额和随机数。如果用户是无状态的，这个见证数据可以由中间节点(例如，构建者可以自愿做这件事)来添加。
?混合式PBS会如何与二层账户抽象交互(例如ERC4337)
ERC4337从根本上改变了抗审查的博弈情况，因为它将以太坊层面上交易的概念与用户意图对象的经济概念解耦了。归根结底，我们试图确保用户意图对象是抗审查的。当两者相同时(就像今天一样)，这可以被说成是交易的抗审查。但是，在ERC4337，交易变成了一个包含许多用户意图对象(在ERC4337里这被称为useroperations)的封装器。
在"常规的"PBS中，这个区分并不重要，因为协议只直接与执行区块交互。构建者可以创建一个包含很多笔("常规")交易的执行区块，或他们可以创建一个包含一笔封装了多项useroperations的交易的执行区块，或是两者的混合。两种情况的机制是完全相同的；封装器与封装器的封装器之间区别不大。
如果辅助执行区块被用作抗审查，那么机制仍然是一样的。如果使用混合式PBS，那么对现状交易和ERC4337?useroperations的处理就会出现差异：对现状交易的抗审查性是直接得到保证的，但对ERC4337?useroperations的抗审查性只是间接提供的。
无论是ERC4337还是混合式PBS都需要稍作修改，以确保其在混合式PBS的世界中集成抗审查性。要了解原因，首先看看一个为什么ERC4337将保有抗审查性的第一个有问题的论点：
携带ERC4337?useroperations的”交易“直接映射到上述”辅助区块“的概念。如果一个给定的ERC4337?useroperations不被会进行审查的主要构建者打包，那么任何人(我们把他们称为”中继者”)都可以创建一笔打包了useroperations的交易(一个假的辅助执行区块)，并期望从中获利。当然，审查者可以在那个确切的时间打包useroperations，并夺走中继者的收入，但并不总是如此，因此平均而言，中继者将是可获利的，原因与上述辅助构建者策略部分的解释一样。
这个论点的关键缺陷是，“不总是”是错的。这是因为在辅助执行区块的情况和ERC4337交易情况之间存在根本的区别。在辅助执行区块的情况里，主要和辅助执行区块的主体是同时被提交的。因此，两边都不能看到另外一边在做什么，也做不了抢跑。但在ERC4337交易的情况里，胜出的构建者能看到交易，因此他们能做抢跑。
解决方案1：修改ERC4337
我们可以对ERC4337做如下修改：useroperations将需要有能力指定允许打包它们的一个单一中继者。这可以保护useroperations不被“窃取”(不过要注意的是，与用户合谋的审查构建者可能仍然可以汲极辅助构建者的收益，因为会进行审查的构建者可以对有相同随机数但不同用户操作的中继者进行抢跑)。
解决方案2：修改混合式PBS
需要在crList上的交易在所有其他交易前被执行。这就防止构建者抢跑。但是，实际上使用这个功能对提议者来说可能成本更大，因为它可能会减少他们从MEV竞拍中获得的收益，因为在?crList?上的交易本身可能就在提取MEV。因此，用这个方法可能会激励提议者在?crList??的构建上用更复杂的方法，这又把中心化激励带回来了。
总结
PBS是一个活跃发展的研究领域。减轻MEV带来的验证者中心化风险对任何寻求保持其去中心化性质的区块链来说都非常重要。但是，防止构建者中心化变成另一种类型的审查漏洞也同样重要。
在这个时间点上，我在短期更倾向于混合式的PBS。混合式PBS在当前和“纯”PBS模型之间得到两全其美的效果：
即使是一个利他主义的提议者也可以打包任何其他提议者和交易捆打包者正在审查的交易，因此我们保有了现有的抗审查性。MEV提取所需的优先位置被竞拍给另一群专门的行为者，因此验证者不需要碰MEV，这样我们就减轻了MEV驱动验证者中心化的风险。提议者不需要亲自执行区块，因此验证者可以是完全无状态的。这意味着大幅提高一层的区块容量会变得更安全。在更长期的未来，混合式PBS的问题以及希望有更多的抽象性这两点都会是探索辅助执行区块这样概念的原因，它们会与主要执行区块被并行构建。
此外，这篇文章中的论点提出了一些有趣的理由，可能最终会考虑在协议层承认ERC4337的useroperations。在短期内，ERC4337应该保持作为一个额外协议ERC，因为在那里它的创新速度会快得多。但是，长期来看，很明显把它写入协议层，并在协议层明确承认用户意图对象能为确保它们免受审查提供更多的选择。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。