V神:我们如何约束构建者,并尽量减少提议者的责任?
对建设者集中化的风险(主要是审查,但也有各种形式的经济剥削)的一个自然反应是试图限制建设者拥有的权力。与其说建设者在赢得拍卖后可以全权建造整个区块,不如说建设者将拥有更有限的权力。这种权力应该仍然足以捕获几乎所有可以捕获的MEV,而且最好仍然足以捕获PBS的其他好处,但它应该被削弱以限制滥用的机会。 这个想法有时被称为部分区块拍卖:与其拍卖决定区块中的一切的权利,不如拍卖决定某些事情的权利,这些“某些事情”可以比“建造者选择区块的前半部分而不是后半部分”更细微:你可以给建造者重新排序、预置、追加的权利,你甚至可以约束提议者。这篇文章介绍了一些可能的方法,以及由此产生的一些权衡因素。 包含列表 在包含列表模式中,提议者提供一个包含列表,即他们要求必须包含在区块中的交易列表,除非构建者能够用其他交易完全填充区块。 对于一个不受不寻常的外部激励影响的利润最大化的建设者来说,包含清单根本不是什么约束:在区块的末尾增加一个额外的交易总是给建设者带来该交易的优先费作为额外的利润。 在区块被填满的情况下(目标的2倍),所以建造者将不得不在该交易和其他交易之间做出选择,该约束被禁用。从长远来看,这并不影响收录,因为满区块的运行只能短暂维持,因为它使基本费用呈指数级上升(每6个区块~2.02倍)。 然而,如果一个建设者确实有一些愿望,拒绝包括它不赞成或被激励排除的特定交易,该建设者将被迫不参与拍卖。 这种设计是相当简单的,但描述它的一些弱点是很重要的: 激励性的兼容性问题:建造者提前看到了包含列表,建造者可以拒绝建造包含他们不想建造的包含列表的区块。这就直接激励了提案者拥有空的包含列表,以最大限度地提高建造者为他们建造区块的机会。 提案人的额外负担:提案人需要能够识别付费的交易。这需要(i)访问mempool和(ii)能够读取状态以确定支付费用的能力,或者是连接到交易的证人。证人是最好的,因为他们会保留PBS的属性,即验证者可以是无状态的客户。 构建者仍然可以从事一些滥用行为:特别是三明治攻击。然而,如果不采取极端的方法,如使用先进的密码学来加密内存池,就不清楚如何能消除这个问题,因为否则从构建者手中夺走这个权力就意味着把它交给提议者,这将激励提议者加入权益池。 需要部分奉行才能使账户抽象化发挥作用:见账户抽象化之路 – HackMD 11 提案人后缀 另一种构造是允许提议者为区块创建一个后缀。构建者在构建区块时不会看到关于提议者意图的信息,而提议者能够将构建者遗漏的任何交易添加到末端。 减少了激励的兼容性问题:建设者仍然可以追溯性地惩罚包括建设者不赞成的交易的提议者(例如,拒绝在未来为他们建设),并将根发给建设者。这是不可避免的,但这比建造者能够实时拒绝建造区块要对提议者友好得多(特别是由于每个单独的提议者只是偶尔提议,现在每两个月一次)。 对提议者来说甚至有更多的额外负担–提议者现在必须计算post-state root,这意味着提议者必须持有整个状态。因此,没有无状态是可能的,除非提议者将这项任务外包给一个单独的中介。 […]





