文章讨论了以太坊中 Inclusion Lists (ILs) 的设计与作用,旨在通过允许提案者强制包含某些交易来对抗审查,并提高以太坊的抗审查性。文章分析了 ILs 的工作原理、设计考虑,以及对潜在问题的解答,同时探讨了 ILs 与账户抽象的兼容性问题。
Jai Siyaram

来源:https://explorer.rated.network/builders
目前 MEV 提取的方法需要验证者通过像 flashbots (开源) mev-boost 这样的链外协议系统来外包区块构建。根据某个来源的数据,以太坊上大约 94% 的区块是由仅仅 3 个构建者构建的!😶🌫️
虽然 Flashbots 是开源的并且运行良好,但它与以太坊去中心化、无信任和抗审查的核心价值观并不完全一致。过度依赖少数关键参与者是不好的。
需要链上协议或明确规定的 proposer-builder-seperation(提议者-构建者分离)来缓解非用户价值增加的 MEV 捕获,基本上是保护无辜用户免受诸如三明治交易或抢跑交易等 MEV 策略的侵害。目前关于 ePBS 设计的讨论:Two-slot PBS, PTC。
无论我们选择 ePBS 还是 mev-boost,区块提议者似乎都对其自己的区块没有发言权。审查风险,从下面的图中可以清楚地看到……😶

这就是包含列表(Inclusion Lists,ILs)发挥作用的地方。它们允许提议者通过提供一种可以强制包含交易的机制来保留一些权力。
为同一区块创建 ILs 的简单设计在激励方面是不相容的,并且不会被构建者接受,因为他们需要的是钱而不是限制,因此提议者将被迫创建空的 ILs。因此,mike、Vitalik、Francesco、Terence、potuz 和 Manav 在 EIP-7547 中提出了前向 ILs(为下一个区块创建 ILs)以及一些考虑因素的想法。
IL 的设计包括摘要和交易列表。摘要 = 区块链中要包含的交易的(发送者地址,gasLimit),以及交易列表中的相应交易。摘要需要必须满足,而不是交易列表,因此,如果任何不在列表中的其他交易满足摘要的条目(具有相同的发送者和 gasLimit),则不需要包含交易列表中的交易。
这是一个简化的设计,IL 的确切规范在这里。

Slot n 提议者创建一个 IL(摘要 + 交易),在 EL(执行层)上签署摘要。这被发送到 CL(共识层),然后与区块 n 一起传播到网络。与摘要一起的交易应基于 slot-n-pre-state 有效。
Slot n+1 提议者将接收区块 n 和一个或多个 IL。然后,它检查 IL 是否有效,因此分叉选择规则适用,即它可以在区块 n 上构建。然后,它将区块 + IL 发送到 mev-builder。因此,构建者可以选择最有利可图的 IL 来构建。
IL 的摘要可以由区块 n 或 n+1 中的交易满足。如果未满足,则区块 n+1 将被视为无效。
区块 n+1 需要包含它所满足的 IL 摘要和签名,以便网络的其余部分(验证者)可以验证 IL 的履行和签名。
关键!

需要考虑的几个验证点:
• IL 的交易在 N-pre-state 中应该是有效的。
• maxFeePerGas 应该至少是区块 n base fee 的 112.5%。
• 随附的交易应满足摘要的条目。
• 摘要的签名应有效。
为了防止以下情况:例如,用户创建 tx1(nonce 10, gasLimit 15), tx2(nonce 11, gasLimit 16),这些在 n-pre-state 中是有效的,并且这两个都进入了 IL。然后,为了利用该系统,他创建了另一个 txn1b(nonce 10, gasLimit 15),该交易从帐户中耗尽了 eth,因此 txn2 变得无效,并且无法满足 IL。
为了使分叉选择规则适用于该区块,该区块需要至少一个有效的 IL。因此,n+1 提议者需要考虑 IL,才能继续前进。只有当验证者看到区块提议者提出的有效 IL 时,才会考虑区块 n 以进行分叉选择规则。因此,提议者-n 应该广播区块 + IL,否则他的股份将被削减以产生无效区块。
类似地,如果 n+1 提议者否认收到 IL,基本上提出了一个不满足 IL 的区块,那么由于 IL 在验证者的视野中,他的区块将变为无效。
具有相同 nonce 的多个交易可能导致膨胀和免费数据可用性问题。如何确保这不会发生?
这不会发生,因为我们承诺的是摘要,而不是在任何可能在 n-post-state 中变为无效的特定交易。
至于免费数据可用性问题……这仅在有多个交易满足摘要中的同一条目或具有相同 nonce 的多个交易的情况下才会发生。在第一种情况下,在所有这些交易中,重要的是进入链的交易,其他交易可以丢弃,不需要存储。在 nonce 重用的情况下,只有一个交易可以被声明为有效,显然它将是满足 IL 摘要的交易,而其他交易将被丢弃。
在这种简化的 IL 应用设计中,没有措施可以防止这种情况。但是,从更广义的角度来看,我们首先为什么要使用 IL?为了赋予提议者对其区块中交易的一些权力,并防止构建者带来的审查。如果验证者不想要这个并串通创建空 IL,除了来自 MEV 的贿赂之外,没有太多动机。如果某个特定时间存在价值非常高的 MEV 交易,并且只有一小部分验证者这样做,就会发生这种情况,但是在整体情况下,由于有诚实的验证者在工作,IL 将加强以太坊的抗审查性(CR)。话虽如此,这个问题仍然需要更多的研究。
最大的问题之一似乎是 IL 设计与帐户抽象在 IL 功能中的兼容性。由于 AA 允许来自不同帐户的交易之间进行更复杂的交互,这可能导致交叉失效,即来自一个帐户的交易可能使来自另一个帐户的交易无效,从而创建 DoS 攻击的潜在向量。这可能会被利用来破坏后续区块的有效性,导致下一个提议者错过他们的 slot。我不太确定这两者的集成。这需要思考。
很多问题都通过列出发送者而不是交易来解决。了解更多信息,在这里。
No free lunch – a new inclusion list design
Payload-timeliness committee (PTC) – an ePBS design
https://www.youtube.com/watch?v=oRjG0RMnK5U
Why enshrine Proposer-Builder Separation? A viable path to ePBS
- 原文链接: hackmd.io/@vedant-asati/...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!