EIP-7742: 解耦 CL 和 EL之间的 blob 计数

让 CL 验证 blob 最大值，并让 EL 从 CL 获取目标值

摘要

从 EIP-4844 更新 blob 最大值和目标验证。

执行层不再验证 blob 最大值，而是从共识层动态接收目标值。

动机

在 EIP-4844 之后，执行层（EL）维护一个硬编码的 blob 目标值和 blob 最大值。鉴于 EL 和共识层（CL）节点软件之间的关系， 对 blob 最大值的验证是多余的，因此可以完全移除，而不会对安全性产生任何影响。blob 最大值仍然通过 Engine API 在区块构建期间提供。 本 EIP 还改变了 EL 获取当前 blob 目标值的方式，原因有二：

1) 获得对该值更大的灵活性，而不是 EIP-4844 中静态的 TARGET == MAX // 2 关系。

2) 在需要更改 blob 目标值的情况下，解耦 CL 和 EL 层的开发和部署。

背景

通过 EIP-4844 引入的数据设施向以太坊区块添加了 blob，这些 blob 只是固定大小的数据集，可以包含在规范链中，但没有执行语义（参见以太坊交易中的 calldata）。

该协议规定了每个区块允许的最大 blob 计数，以防止通过滥用此数据设施造成的 DoS 向量。 该协议还维护一个类似于 EIP-1559 的“目标”值，用于表示每个单位时间的预期运行平均 blob 吞吐量。 blob 的使用量与此目标进行比较，以影响“blob 基本费用”，从而管理将此资源分配给以太坊协议的用户。

在 EIP-4844 之后，这两个值目前都在 EL 中硬编码，blob 最大值在 EIP-4844 之后单独在 CL 中硬编码。本 EIP 提出了一组更改，以解耦 CL 和 EL 之间的这些值，从而更容易开发和部署对 blob 计数的更改。

每个区块的最大 blob 数

blob 最大值在 CL 节点中验证，EL 在 Engine API 指定的与每个 blob 对应的版本化哈希的一致性检查期间继承此验证。因此，EIP-4844 指定的严格检查是不必要的。

每个区块的目标 blob 数量

目前，目标值是根据 blob 计数指定的固定值。以太坊社区计划增加 blob 参数，作为其扩展策略的一部分，并且能够拥有一个更灵活的目标值（相对于 blob 最大值）是可取的，以减少此协议参数的刚性。

即使 EL 保持基于最大值的固定目标值，移除最大值意味着 EL 将不知道目标值应该是什么。为了解决这种信息不足的问题，本 EIP 建议 CL 通过 Engine API 随每个提供的 payload 将当前目标值发送到 EL。EL 区块头还需要使用此目标值进行扩展，以保持乐观同步的安全性。

规范

区块结构和有效性

在激活此 EIP 后，执行客户端必须使用一个额外的 64 位字段扩展头模式：target_blobs_per_block。此值设置为当前目标 blob 计数。Engine API 随本 EIP 一起修改，以提供带有每个 payload 的 target_blobs_per_block，并且实现可以使用此值来正确设置区块头字段。

target_blobs_per_block 的有效性由共识层保证，就像处理提款的方式一样。

在验证区块时，执行客户端必须确保区块头中的目标 blob 计数与共识客户端提供的 blob 计数相匹配。

对于没有现有父区块的创世区块，该值应根据该创世区块协议规则集给出的目标 blob 计数的约定规范进行设置。

区块处理

在激活此 EIP 后（即，在处理任何交易之前），可以跳过 EIP-4844 中给出的 blob 最大值的验证。具体来说，这意味着可以弃用与 EIP-4844 中给出的 MAX_BLOB_GAS_PER_BLOCK 相关的任何逻辑。

此外，calc_excess_blob_gas 按如下方式更新：

def calc_excess_blob_gas(parent: Header) -> int:
    target_blob_gas = parent.target_blobs_per_block * GAS_PER_BLOB
    if parent.excess_blob_gas + parent.blob_gas_used < target_blob_gas:
        return 0
    else:
        return parent.excess_blob_gas + parent.blob_gas_used - target_blob_gas

否则，EIP-4844 的规范不会更改。例如，blob 基本费用会计和超额 blob gas 跟踪以完全相同的方式发生。

区块构造

Engine API 扩展为在 CL 请求 EL 构建用于提议的 payload 时，提供 target_blobs_per_block 和 max_blobs_per_block。

应使用这些值来确保在任何构建的 payload 中包含正确数量的 blob，并确保正确计算 blob 基本费用核算。

理由

为什么不让 CL 也计算 blob 基本费用，并从 EL 处理中删除任何 blob 计数的概念？

将完整计算提升到 CL 中是可能的，但这确实违反了协议栈这两层之间的关注点分离。 CL 维护一个最大值来解决例如 DoS 风险，EL 维护目标值的知识来解决费用核算。 将目标计算放在 CL 中违反了每一层的各自职责。

向后兼容性

没有问题。

测试用例

不适用

参考实现

不适用

安全注意事项

不适用

版权

通过 CC0 放弃版权和相关权利。

Citation

Please cite this document as:

Alex Stokes (@ralexstokes), "EIP-7742: 解耦 CL 和 EL之间的 blob 计数 [DRAFT]," Ethereum Improvement Proposals, no. 7742, July 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7742.