EIP-7872 解析为本地区块构建器引入可配置的最大 Blob 数量上限Max Blob Flag【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7872Max blob flag for local builders是 Ethereum Improvement Proposal 仓库EIPS中一项聚焦执行层Execution Layer, EL的提案它为区块构建器block builder新增一个客户端可配置的标志USER_CONFIGURED_MAX_BLOBS_PER_BLOCK让运行在自己节点上的本地构建器local builder能够主动限制单个区块内打包的 blob 数量而不是无条件地能塞多少塞多少。读完本文你将理解该标志的完整规范、它与 EIP-4844 / EIP-7691 中MAX_BLOB_GAS_PER_BLOCK参数的关系以及低带宽节点如何借助这一开关避免构建出无法证明数据可用性的区块这一风险。背景为什么本地构建器需要一个上限开关从 blob 吞吐量提升说起Ethereum 的 blob 数据可用性容量并非一成不变。最初由 EIP-4844Shard Blob Transactions状态 Final引入 blob 交易时执行层的两个核心参数为常量值Cancun/DencunMAX_BLOB_GAS_PER_BLOCK786432TARGET_BLOB_GAS_PER_BLOCK393216GAS_PER_BLOB2**17131072由于GAS_PER_BLOB 2**17上述取值对应每个区块最多 6 个 blob0.75 MB、目标 3 个 blob0.375 MB。此后 EIP-7691Blob throughput increase状态 Final在 Electra/Prague 分叉将其进一步提升常量值Electra/PragueMAX_BLOBS_PER_BLOCK_ELECTRA9TARGET_BLOBS_PER_BLOCK_ELECTRA6MAX_BLOB_GAS_PER_BLOCK1179648TARGET_BLOB_GAS_PER_BLOCK786432BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE5007716值得注意的是EIP-7691 的 Motivation 中已经明确预告了这类需求为了缓解对 solo-staker独立质押者的合理担忧可以考虑引入一个指示本地构建区块最大 blob 数量的标志a flag indicating the max blobs per block for locally built blocks。EIP-7872 正是把这一设想落成具体规范。问题本质带宽约束与数据可用性违约EIP-7872 的 Motivation 指出了当前协议行为的一个隐含风险目前构建器会把本地 mempool 中所有blob 全部纳入区块直至达到协议规定的最大数量。如果构建器带宽较低它可能打包了过多的 blob随后却无法说服网络这些 blob 确实是可用的available。这里涉及以太坊的数据可用性data availability机制验证者或构建者在发布包含 blob 交易的区块后还必须把 blob 的完整数据以 sidecar 的形式在 P2P 网络中传播gossip供其他节点采样和验证。EIP-4844 的 Networking 部分明确要求节点不得自动向对等节点广播 blob 交易而是通过NewPooledTransactionHashes宣告、再由对等节点显式请求GetPooledTransactions随之传输rlp([tx_payload_body, blobs, commitments, proofs])包裹数据。带宽受限的节点一旦吃下超过自身传播能力的 blob 数量就可能无法在规定时间内完成数据传播进而无法说服网络 blob 可用最终造成区块被拒绝或丢失。EIP-7872 的解法非常直接与其让协议层统一约束所有人的打包数量不如把最多打包多少个 blob的决定权交给每个节点自己——通过一个用户可配置的标志来收缩上限。规范USER_CONFIGURED_MAX_BLOBS_PER_BLOCK的完整语义EIP-7872 的 Specification 只有四条规则但每一条都值得拆解创建配置参数在区块构建器的配置中新增一个名为USER_CONFIGURED_MAX_BLOBS_PER_BLOCK的参数取最小值计算MAX_BLOB_GAS_PER_BLOCK与USER_CONFIGURED_MAX_BLOBS_PER_BLOCK的最小值下限保护如果最小值等于 0则将其置为 1用于打包决策使用上述最小值来决定区块中包含多少个 blob。规范还附带一条重要说明默认情况下USER_CONFIGURED_MAX_BLOBS_PER_BLOCK可以设置为当前分叉下的最大值。这意味着该标志是可选收紧、默认不缩小容量的设计用户不配置时构建器行为与协议默认完全一致只有显式配置了更小的值才会主动收缩 blob 打包上限。伪代码示意结合 EIP-4844 中执行层的参数语义可以将上述规范翻译为如下决策逻辑# 协议层最大值当前分叉例如 Electra/Prague 下为 1179648 max_blob_gas MAX_BLOB_GAS_PER_BLOCK # 用户配置的标志默认等于协议最大值 user_max_blob_gas USER_CONFIGURED_MAX_BLOBS_PER_BLOCK # 默认 max_blob_gas # 取最小值若为 0 则抬升为 1避免出现完全禁止 blob的边界状态 effective_max min(max_blob_gas, user_max_blob_gas) if effective_max 0: effective_max 1 # 构建区块时用 effective_max 约束累计 blob gas # blob_gas_used get_total_blob_gas(tx) effective_max其中get_total_blob_gas(tx)来自 EIP-4844def get_total_blob_gas(tx: Transaction) - int: return GAS_PER_BLOB * len(tx.blob_versioned_hashes)即每个 blob 恒定消耗2**17blob gas因此blob 数量上限与blob gas 上限在这里是线性等价的MAX_BLOB_GAS_PER_BLOCK // GAS_PER_BLOB即当前分叉的协议最大 blob 数Electra 下为 9。为什么下限保护是 1 而不是 0max(1, min(...))这条规则保证了任何配置都不会产生零 blob区块的硬性禁止。即便用户把标志误配为 0构建器仍会尝试打包至少 1 个 blob从而避免配置错误导致区块构建器罢工或与协议行为发生无法预期的偏差。这是典型的防御性设计配置参数只负责收缩上限不负责关闭功能。协议约束与本地标志的分工协议层MAX_BLOB_GAS_PER_BLOCK是不可逾越的硬上限无论本地标志如何配置区块都必须满足协议层的 blob gas 校验。EIP-4844 在执行层验证Execution layer validation中给出的核心断言是# ensure the total blob gas spent is at most equal to the limit assert blob_gas_used MAX_BLOB_GAS_PER_BLOCK # ensure blob_gas_used matches header assert block.header.blob_gas_used blob_gas_used因此 EIP-7872 中的min(MAX_BLOB_GAS_PER_BLOCK, USER_CONFIGURED_MAX_BLOBS_PER_BLOCK)意味着本地标志只能在协议上限以内往下调无论用户配置多大都不可能突破MAX_BLOB_GAS_PER_BLOCK。协议上限由分叉参数决定见 EIP-4844 与 EIP-7691而本地标志是一个纯粹的节点本地行为参数两者共同作用形成协议硬上限 ∩ 用户软上限的双层约束。与 EIP-7742 的动态化趋势相互兼容EIP-7742Uncouple blob count between CL and EL提出执行层不再自己验证 blob 最大值而是由共识层CL动态下发目标/上限。EIP-7872 与该方向并不冲突无论MAX_BLOB_GAS_PER_BLOCK的取值最终来自静态分叉常量还是共识层动态信标本地构建器始终只需要取协议当前有效上限与用户配置的较小值即可。这也解释了为何规范刻意不绑定某个固定数值——USER_CONFIGURED_MAX_BLOBS_PER_BLOCK的默认值跟随当前分叉的最大值天然适配参数动态演进的路线。配置建议与适用场景推荐配置方式默认不配置构建器打包全部可用 blob直至协议上限行为与今日一致带宽受限节点根据自身出站带宽与传播能力将USER_CONFIGURED_MAX_BLOBS_PER_BLOCK设置为较小的 blob gas 值例如对应 36 个 blob即393216786432确保侧载sidecar数据能在时限内完成 gossip测试/开发环境可用较小的值如GAS_PER_BLOB即 131072对应 1 个 blob来模拟低容量场景验证构建器在数据可用性约束下的行为。从源码结构看实现落点从 EIP-7872 的定位type: Meta仅描述配置标志的语义和仓库结构看该参数的落点位于各执行层客户端的区块构建器block builder / payload builder模块——即在本地组装执行负载payload时遍历 mempool 中的 blob 交易并累计get_total_blob_gas(tx)的那段逻辑中将协议断言blob_gas_used MAX_BLOB_GAS_PER_BLOCK见 EIP-4844替换为对effective_max的检查。由于仓库中 EIP 文档为主、客户端源码为辅具体客户端的配置项命名与默认值需以对应客户端如 geth、reth 等的发行版本为准EIP 文本只规定语义不规定参数在配置文件中的具体路径。安全性考虑与向后兼容安全考量原文档 Security Considerations 标注为 N/A。从机制本身分析这是由代码语义可推断的结论该标志只影响本地构建区块的打包数量不改变任何共识/执行层验证规则不改变 mempool 接收与 gossip 逻辑也不影响非本地构建如外部提议者/构建者分离场景的区块生产。因此它不引入新的攻击面相反它降低了低带宽节点因过度打包而无法完成数据可用性证明的风险属于安全性增强类配置。向后兼容原文档明确给出结论No backward compatibility issues found. 原因在于默认值等于当前分叉的协议最大值未配置用户不感知任何行为变化本地标志永远取min收缩不会产生超出协议上限的区块因此不会触发 EIP-4844 的验证失败该变更属于纯执行层EL本地行为原文档在 Abstract 中亦强调This is an execution layer only change不涉及共识层CL、P2P 协议或交易格式的改动。与周边 blob 提案的关系EIP-4844定义了 blob 交易格式、GAS_PER_BLOB、MAX_BLOB_GAS_PER_BLOCK及执行层验证是 EIP-7872 所约束对象的源头EIP-7691将上限从 6 提升到 9 个 blob其 Motivation 直接提出了本地构建标志的想法是 EIP-7872 的直接催化剂EIP-7742解耦 EL/CL 的 blob 数量参数使MAX_BLOB_GAS_PER_BLOCK走向动态化EIP-7872 的默认取当前分叉最大值设计与之一致EIP-7915Adaptive mean reversion blob pricing调整calc_excess_blob_gas()与 blob base fee 的定价机制影响 blob 需求的费用表现但不改变单区块 blob 数量的打包上限语义两者分别在定价与本地生产容量两个维度独立演进。总结EIP-7872 是一个小而精的执行层配置提案通过USER_CONFIGURED_MAX_BLOBS_PER_BLOCK标志让本地区块构建器在协议上限MAX_BLOB_GAS_PER_BLOCK之下按需收缩 blob 打包数量取最小值、以 1 为下限保护、默认跟随当前分叉最大值。它不改变协议验证规则不引入兼容性问题而是把打包多少 blob这一决策从协议强制转变为协议上限 节点自主为低带宽节点、独立质押者和测试环境提供了一种轻量而有效的自我保护手段。该提案的完整文本与讨论入口见 EIPS/eip-7872.md其版权声明遵循 LICENSE.md 的 CC0 公有领域协议。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-7872 解析：为本地区块构建器引入可配置的最大 Blob 数量上限（Max Blob Flag）
EIP-7872 解析为本地区块构建器引入可配置的最大 Blob 数量上限Max Blob Flag【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7872Max blob flag for local builders是 Ethereum Improvement Proposal 仓库EIPS中一项聚焦执行层Execution Layer, EL的提案它为区块构建器block builder新增一个客户端可配置的标志USER_CONFIGURED_MAX_BLOBS_PER_BLOCK让运行在自己节点上的本地构建器local builder能够主动限制单个区块内打包的 blob 数量而不是无条件地能塞多少塞多少。读完本文你将理解该标志的完整规范、它与 EIP-4844 / EIP-7691 中MAX_BLOB_GAS_PER_BLOCK参数的关系以及低带宽节点如何借助这一开关避免构建出无法证明数据可用性的区块这一风险。背景为什么本地构建器需要一个上限开关从 blob 吞吐量提升说起Ethereum 的 blob 数据可用性容量并非一成不变。最初由 EIP-4844Shard Blob Transactions状态 Final引入 blob 交易时执行层的两个核心参数为常量值Cancun/DencunMAX_BLOB_GAS_PER_BLOCK786432TARGET_BLOB_GAS_PER_BLOCK393216GAS_PER_BLOB2**17131072由于GAS_PER_BLOB 2**17上述取值对应每个区块最多 6 个 blob0.75 MB、目标 3 个 blob0.375 MB。此后 EIP-7691Blob throughput increase状态 Final在 Electra/Prague 分叉将其进一步提升常量值Electra/PragueMAX_BLOBS_PER_BLOCK_ELECTRA9TARGET_BLOBS_PER_BLOCK_ELECTRA6MAX_BLOB_GAS_PER_BLOCK1179648TARGET_BLOB_GAS_PER_BLOCK786432BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE5007716值得注意的是EIP-7691 的 Motivation 中已经明确预告了这类需求为了缓解对 solo-staker独立质押者的合理担忧可以考虑引入一个指示本地构建区块最大 blob 数量的标志a flag indicating the max blobs per block for locally built blocks。EIP-7872 正是把这一设想落成具体规范。问题本质带宽约束与数据可用性违约EIP-7872 的 Motivation 指出了当前协议行为的一个隐含风险目前构建器会把本地 mempool 中所有blob 全部纳入区块直至达到协议规定的最大数量。如果构建器带宽较低它可能打包了过多的 blob随后却无法说服网络这些 blob 确实是可用的available。这里涉及以太坊的数据可用性data availability机制验证者或构建者在发布包含 blob 交易的区块后还必须把 blob 的完整数据以 sidecar 的形式在 P2P 网络中传播gossip供其他节点采样和验证。EIP-4844 的 Networking 部分明确要求节点不得自动向对等节点广播 blob 交易而是通过NewPooledTransactionHashes宣告、再由对等节点显式请求GetPooledTransactions随之传输rlp([tx_payload_body, blobs, commitments, proofs])包裹数据。带宽受限的节点一旦吃下超过自身传播能力的 blob 数量就可能无法在规定时间内完成数据传播进而无法说服网络 blob 可用最终造成区块被拒绝或丢失。EIP-7872 的解法非常直接与其让协议层统一约束所有人的打包数量不如把最多打包多少个 blob的决定权交给每个节点自己——通过一个用户可配置的标志来收缩上限。规范USER_CONFIGURED_MAX_BLOBS_PER_BLOCK的完整语义EIP-7872 的 Specification 只有四条规则但每一条都值得拆解创建配置参数在区块构建器的配置中新增一个名为USER_CONFIGURED_MAX_BLOBS_PER_BLOCK的参数取最小值计算MAX_BLOB_GAS_PER_BLOCK与USER_CONFIGURED_MAX_BLOBS_PER_BLOCK的最小值下限保护如果最小值等于 0则将其置为 1用于打包决策使用上述最小值来决定区块中包含多少个 blob。规范还附带一条重要说明默认情况下USER_CONFIGURED_MAX_BLOBS_PER_BLOCK可以设置为当前分叉下的最大值。这意味着该标志是可选收紧、默认不缩小容量的设计用户不配置时构建器行为与协议默认完全一致只有显式配置了更小的值才会主动收缩 blob 打包上限。伪代码示意结合 EIP-4844 中执行层的参数语义可以将上述规范翻译为如下决策逻辑# 协议层最大值当前分叉例如 Electra/Prague 下为 1179648 max_blob_gas MAX_BLOB_GAS_PER_BLOCK # 用户配置的标志默认等于协议最大值 user_max_blob_gas USER_CONFIGURED_MAX_BLOBS_PER_BLOCK # 默认 max_blob_gas # 取最小值若为 0 则抬升为 1避免出现完全禁止 blob的边界状态 effective_max min(max_blob_gas, user_max_blob_gas) if effective_max 0: effective_max 1 # 构建区块时用 effective_max 约束累计 blob gas # blob_gas_used get_total_blob_gas(tx) effective_max其中get_total_blob_gas(tx)来自 EIP-4844def get_total_blob_gas(tx: Transaction) - int: return GAS_PER_BLOB * len(tx.blob_versioned_hashes)即每个 blob 恒定消耗2**17blob gas因此blob 数量上限与blob gas 上限在这里是线性等价的MAX_BLOB_GAS_PER_BLOCK // GAS_PER_BLOB即当前分叉的协议最大 blob 数Electra 下为 9。为什么下限保护是 1 而不是 0max(1, min(...))这条规则保证了任何配置都不会产生零 blob区块的硬性禁止。即便用户把标志误配为 0构建器仍会尝试打包至少 1 个 blob从而避免配置错误导致区块构建器罢工或与协议行为发生无法预期的偏差。这是典型的防御性设计配置参数只负责收缩上限不负责关闭功能。协议约束与本地标志的分工协议层MAX_BLOB_GAS_PER_BLOCK是不可逾越的硬上限无论本地标志如何配置区块都必须满足协议层的 blob gas 校验。EIP-4844 在执行层验证Execution layer validation中给出的核心断言是# ensure the total blob gas spent is at most equal to the limit assert blob_gas_used MAX_BLOB_GAS_PER_BLOCK # ensure blob_gas_used matches header assert block.header.blob_gas_used blob_gas_used因此 EIP-7872 中的min(MAX_BLOB_GAS_PER_BLOCK, USER_CONFIGURED_MAX_BLOBS_PER_BLOCK)意味着本地标志只能在协议上限以内往下调无论用户配置多大都不可能突破MAX_BLOB_GAS_PER_BLOCK。协议上限由分叉参数决定见 EIP-4844 与 EIP-7691而本地标志是一个纯粹的节点本地行为参数两者共同作用形成协议硬上限 ∩ 用户软上限的双层约束。与 EIP-7742 的动态化趋势相互兼容EIP-7742Uncouple blob count between CL and EL提出执行层不再自己验证 blob 最大值而是由共识层CL动态下发目标/上限。EIP-7872 与该方向并不冲突无论MAX_BLOB_GAS_PER_BLOCK的取值最终来自静态分叉常量还是共识层动态信标本地构建器始终只需要取协议当前有效上限与用户配置的较小值即可。这也解释了为何规范刻意不绑定某个固定数值——USER_CONFIGURED_MAX_BLOBS_PER_BLOCK的默认值跟随当前分叉的最大值天然适配参数动态演进的路线。配置建议与适用场景推荐配置方式默认不配置构建器打包全部可用 blob直至协议上限行为与今日一致带宽受限节点根据自身出站带宽与传播能力将USER_CONFIGURED_MAX_BLOBS_PER_BLOCK设置为较小的 blob gas 值例如对应 36 个 blob即393216786432确保侧载sidecar数据能在时限内完成 gossip测试/开发环境可用较小的值如GAS_PER_BLOB即 131072对应 1 个 blob来模拟低容量场景验证构建器在数据可用性约束下的行为。从源码结构看实现落点从 EIP-7872 的定位type: Meta仅描述配置标志的语义和仓库结构看该参数的落点位于各执行层客户端的区块构建器block builder / payload builder模块——即在本地组装执行负载payload时遍历 mempool 中的 blob 交易并累计get_total_blob_gas(tx)的那段逻辑中将协议断言blob_gas_used MAX_BLOB_GAS_PER_BLOCK见 EIP-4844替换为对effective_max的检查。由于仓库中 EIP 文档为主、客户端源码为辅具体客户端的配置项命名与默认值需以对应客户端如 geth、reth 等的发行版本为准EIP 文本只规定语义不规定参数在配置文件中的具体路径。安全性考虑与向后兼容安全考量原文档 Security Considerations 标注为 N/A。从机制本身分析这是由代码语义可推断的结论该标志只影响本地构建区块的打包数量不改变任何共识/执行层验证规则不改变 mempool 接收与 gossip 逻辑也不影响非本地构建如外部提议者/构建者分离场景的区块生产。因此它不引入新的攻击面相反它降低了低带宽节点因过度打包而无法完成数据可用性证明的风险属于安全性增强类配置。向后兼容原文档明确给出结论No backward compatibility issues found. 原因在于默认值等于当前分叉的协议最大值未配置用户不感知任何行为变化本地标志永远取min收缩不会产生超出协议上限的区块因此不会触发 EIP-4844 的验证失败该变更属于纯执行层EL本地行为原文档在 Abstract 中亦强调This is an execution layer only change不涉及共识层CL、P2P 协议或交易格式的改动。与周边 blob 提案的关系EIP-4844定义了 blob 交易格式、GAS_PER_BLOB、MAX_BLOB_GAS_PER_BLOCK及执行层验证是 EIP-7872 所约束对象的源头EIP-7691将上限从 6 提升到 9 个 blob其 Motivation 直接提出了本地构建标志的想法是 EIP-7872 的直接催化剂EIP-7742解耦 EL/CL 的 blob 数量参数使MAX_BLOB_GAS_PER_BLOCK走向动态化EIP-7872 的默认取当前分叉最大值设计与之一致EIP-7915Adaptive mean reversion blob pricing调整calc_excess_blob_gas()与 blob base fee 的定价机制影响 blob 需求的费用表现但不改变单区块 blob 数量的打包上限语义两者分别在定价与本地生产容量两个维度独立演进。总结EIP-7872 是一个小而精的执行层配置提案通过USER_CONFIGURED_MAX_BLOBS_PER_BLOCK标志让本地区块构建器在协议上限MAX_BLOB_GAS_PER_BLOCK之下按需收缩 blob 打包数量取最小值、以 1 为下限保护、默认跟随当前分叉最大值。它不改变协议验证规则不引入兼容性问题而是把打包多少 blob这一决策从协议强制转变为协议上限 节点自主为低带宽节点、独立质押者和测试环境提供了一种轻量而有效的自我保护手段。该提案的完整文本与讨论入口见 EIPS/eip-7872.md其版权声明遵循 LICENSE.md 的 CC0 公有领域协议。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考