本文介绍了一个基于 Commit-Boost 的链外包含列表模块,它允许区块提议者创建一个包含指定交易的列表,并将其传递给中继(relay),后者负责在区块构建过程中强制执行该列表。提议者为包含列表中的交易被纳入区块设置特定价值,从而在链外实现包含列表的功能。
非常感谢 Eitan Seri-Levi、Drew van der Werff、Barnabé Monnot 以及整个通过 Commit-Boost 实现包含列表模块的团队对本文档的反馈(反馈不代表认可)。
下面,我们讨论一个 Commit-Boost 模块,它允许一个 slot 的提议者创建一个它希望包含在为其 slot 生成的区块中的交易列表,同时仍然通过 MEV-Boost 外包区块构建。在这个模块中,提议者构建一个包含列表,并将其传播到一个或多个强制执行该包含列表的 relay。提议者表达了它对包含列表中的交易被包含在区块中的特定价值。这个设计用链下包含列表的采用来换取包含列表的有效性。
该包含列表模块使用 Commit-Boost 和 Bolt builder constraints API。信标节点可以将此模块视为 MEV-Boost relay。
slot $N$ 的提议者构建一个它想要包含在 slot $N$ 期间提议的区块中的交易列表。
该列表使用 get_filtered_transactions
函数构建,该函数接收一个 Transaction
对象向量作为输入;这些是在 mempool 中挂起但未包含在较早区块中的交易,以及 slot $N-1$ 期间提议的 Block
。对于 Transaction
中的每个交易,它检查是否可以基于两个条件包含该交易:1) 交易是否支付了严格为正的优先费用,以及 2) 交易的 gas limit 是否小于或等于 Block
中剩余的 gas 量。如果满足这两个条件,则将交易添加到包含列表中。
包含在 Transaction
对象中的交易是 slot $N$ 的提议者在 slot 开始时看到且未包含在任何较早区块中的交易。将要包含在 Transaction
对象中的交易的冻结截止日期设置为较早意味着提议者仅考虑更有可能被排除的交易。相反,它会增加交易被包含的平均等待时间。
提议者一旦构建好包含列表,就将其发送到其选择的 MEV-Boost relay。除了包含列表之外,提议者还会转发其附加到满足包含列表的价值。
如果 relay 收到来自提议者的包含列表,它首先检查该提议者是否确实是包含列表对应的 slot 的提议者。然后,它广播包含列表,以便与 relay 交互的 builder 知道它以及提议者附加到它的价值。
然后,每个 builder 构建区块并向 relay 提交拍卖中的 bid。当提议者调用 get_header
时,relay 转发与最高调整 bid 相对应的 header,其中最高调整 bid 的计算方式如下。请注意,最高调整 bid 纯粹是为了纳入提议者分配给包含列表的价值,而不是提议者收到的价值。relay 还应将 bid 转发给提议者。
$$ \text{最高调整 Bid} = \max{\text{满足 IL 的 Bid} + \text{提议者 IL 价值}, \enskip \text{不满足 IL 的 Bid} } $$
relay 还会随 header 转发包含列表是否已得到满足。如果提议者想要比较不同 relay 的 bid,这将很有用。
relay 可以 乐观地 计算最高调整 bid,方法是让 builder 说明它们是否满足 IL,或者非乐观地计算,方法是 1) 确保区块有效,以及 2) 确保包含列表中的所有交易都包含在区块中。
包含列表可以具有各种属性,如对链上包含列表的研究中所述。本节详细介绍此包含列表模块的设计权衡。
提议者可以乐观地或非乐观地强制执行包含列表。在这个设计中,我们选择了乐观强制执行。这意味着提议者不需要来自 builder 或 relay 的证明,证明与提议者承诺的 header 相对应的区块包含来自包含列表的交易。相反,提议者相信 relay 会正确报告提议者收到的 header 是否对应于满足包含列表的 payload。
如果 relay 出现错误并说 payload 满足包含列表,而事实并非如此,则 relay 必须赔偿提议者提议者附加到其包含列表被验证的价值。
我们选择乐观强制执行是因为提议者必须信任 relay,无论它是否使用包含列表模块,以确保提议者收到它承诺的 bid 的价值。这意味着 relay 必须检查区块是否有效并支付 bid,或者它必须保证付款。
包含列表模块不会引入定性上的新信任假设。提议者现在必须信任 relay 区块有效并满足包含。如果未满足这两个条件中的任何一个,则 relay 必须保证向提议者付款。
使用基于证明的系统,在这种系统中,提议者仅在知道包含列表已得到满足的情况下才签署 header,这将确保提议者知道包含列表是否在区块有效时得到满足。但是,区块仍然可能无效。此外,该证明会增加延迟,这将导致预期利润的减少,因此可能会导致采用率降低。
包含列表适用于构建它的提议者的 slot,因此可以被视为现货包含列表。众所周知,现货包含列表不具有激励兼容性,因为提议者限制了可以为其 slot 构建的可能区块,因此也限制了它可以提取的最大价值。
然而,这种设计假设提议者对一个区块满足其包含列表具有一些私有价值。提议者将其私有价值与包含列表一起传达给 relay,然后将该价值用于计算最高调整 bid,如前所述。鉴于这种私有估值,包含列表具有激励兼容性。
私有估值可能来自各种来源;例如,验证者可以通过包含它看到的所有交易来评估对网络可信中立性的贡献。
包含列表是无条件应用的,无论拥塞程度如何。因此,如果区块已满,则仅当包含列表中的所有交易都包含在该区块中时,包含列表才被满足。这与经常针对链上包含列表讨论的有条件包含列表不同。
这种设计选择无条件包含列表是因为它希望尽可能清楚地传达提议者对某些交易的偏好。提议者可能希望包含某些交易,而不管是否可以包含其他交易。
最后,包含列表取决于满足它的 payload 和不满足它的 payload 之间的相对价值。拥塞时也可能伴随着更高的优先费用;因此,实际上,在拥塞期间,不满足包含列表的 payload 的 bid 可能高于满足包含列表的 payload 的 bid 与私有值的总和。
不可拥挤性意味着包含列表将用于可信中立性,而不是用于其他利润驱动的动机。这不是通过 Commit-Boost 进行的链下包含列表的顾虑,因为这些包含列表没有任何特殊的属性,使其更具吸引力,可用于利润驱动的动机,因为 Commit-Boost 上构建的其他模块专门用于预确认之类的事情。与链上包含列表不同,区块有效性与包含列表是否满足无关。如果提议者想要追求利润,他们可以使用 Commit-Boost 上的另一个模块,而不是包含列表模块。
由于包含列表是乐观验证的,因此必须进行检查以确定它是否确实已满足。这可以与确定区块是否确实向验证者支付了 bid 的检查相同。
与链上包含列表不同,包含列表没有共识,因此没有严格的时序截止日期。当提议者调用 get_header
时,relay 会传达 payload 是否满足包含列表。如果包含列表未按时提交,则 relay 会传达 payload 不满足包含列表。
如果提议者指定了两个或多个包含列表,则 relay 不得受到恶意攻击并(在社交上)被迫向提议者支付。因此,在这种设计中,只要 payload 满足提议者广播的包含列表,relay 就会返回 payload 满足该包含列表。
提议者指定一个它附加到 payload 满足包含列表的价值。如果提议者完全出于利他目的制作了包含列表,则此价值充当提议者可能损失的最大价值。因此,此值类似于 MEV-Boost 中的 min-bid 参数。正如 Data Always 所表明的那样,正确设置此值非常重要,因为它是在利他主义成本和策略有效性之间的仔细平衡。
加密 mempool 增加了 审查成本,从交易支付的优先费用到所有交易支付的优先费用,因为对手不能有选择地排除一个特定的交易,但必须排除所有交易。这可以看作是对审查成本的一个很大的常数补充。链下包含列表可以通过将默认偏好值设置为一个固定的常数来模拟这个模型,很像最小 bid 参数。这也将构成一个利他主义提议者可能面临的明确的最大损失。
多个提议者将审查成本从优先费用增加到优先费用乘以提议者的数量,因为对手必须贿赂所有提议者才能排除该交易。链下包含列表可以通过将默认偏好值设置为包含在包含列表中的交易的优先费用的倍数来实现类似的审查成本。这更类似于客户端实现的 local-block-value-boost
parameter。
我认为这个设计应该使用加密 mempool / 最小 bid 模型,因为提议者更容易推理出一个正确的值,并且因为客户端正在基于 Data Always’ recent post 实现本地区块价值提升的最大值。
以下命令将运行 IL-Boost 模块。
cargo build --release
docker compose -f cb.docker-compose.yml up -d
docker build -t il-boost . -f ./Dockerfile
但首先你需要更新 cb.docker-compose.yml
和 cb-config.toml
文件。
对于 cb.docker-compose.yml
,你需要更改以下值:
${YOUR_PATH_TO_KEYS_DIR}
应替换为你的密钥目录的相对/绝对路径${YOUR_PATH_TO_SERETS_DIR}
应替换为你的 secrets 目录的相对/绝对路径${JWT}
应替换为你的节点的 JWT 密钥。请注意,此值需要在两个位置替换对于 cb-config.toml
,请参阅示例配置列表并相应地更新它们。
确保启用以下 web api 功能
admin,engine,net,eth,web3,debug,txpool
即 --http.api=admin,engine,net,eth,web3,debug,txpool
在 Geth 中
确保启用外部区块构建功能并将区块构建器 URL 指向你的本地 Commit-Boost PBS 模块
- 原文链接: github.com/eserilev/il-b...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!