基础设定
为了建立一个清晰的讨论框架，我们采用以下基础设定：该方案基于Electra硬分叉环境，同时值得在EIP-7732(ePBS)框架下进行对比研究。我们重点考察独立区块构建和发布的场景，其中提议者不运行MEV-Boost，这是需要优先处理的核心组件，而Builder API则是次要考量因素。在硬件配置方面，我们采用当前以太坊链上常见的独立质押者设置，包括标准计算能力、内存需求和网络带宽。
参与角色
协议中涉及的主要参与者及其职责如下：包含列表(IL)委员会成员负责通过其交易集约束下一个槽位提议者；提议者负责提出下一个槽位的区块；证明者负责为链头部的下一个槽位提供证明；节点则负责验证和跟踪链状态。值得注意的是，提议者和证明者都属于质押了以太币的节点群体。
运行流程
我们假设IL委员会、提议者和证明者按照以下时间线执行诚实行为：在槽位n-1的t=6时刻，IL委员会在了解区块内容后发布针对全局主题的本地包含列表(IL)；到槽位n-1的t=9时刻，证明者和诚实验证节点锁定本地IL视图；进入槽位n的t=0时刻，该槽位的区块提议者发布包含有效负载的区块B，这些负载需要满足IL要求；最后在槽位n的t=4时刻，该槽位的证明者通过将区块B与其本地IL视图进行比对来验证IL聚合，确认区块B的”有效性”。
阶段一：IL委员会发布本地IL
IL委员会的工作
IL委员会成员从给定头部的EL客户端获取IL交易列表（通过CL→EL调用），随后签署本地IL（包含交易和摘要）并将其发布至八卦网络。这一过程涉及从EL内存池检索IL交易的CPU/内存消耗、签署包含列表的CPU开销，以及将包含列表上传至八卦网络的带宽需求。
节点与证明者的职责
链上节点需要下载IL、验证其抗DOS特性（暂不导入EL），并将其转发给其他节点。同时，节点还需将IL导入分支选择机制，并使用聚合缓存跟踪已观察到的IL。这一过程会产生下载和转发IL的带宽开销，验证IL抗DOS特性的CPU/内存消耗，以及缓存和聚合IL的内存占用。
提议者的准备工作
下一个槽位的提议者需要持续监控IL八卦网络，收集并聚合本地IL。在IL聚合截止时间（阶段二）到来时，提议者将使用IL交易列表更新其区块构建流程，这需要执行CL到EL的调用。除了继承普通节点的资源开销外，提议者还可能面临特殊情况：如果根据未见的父哈希观察到足够数量的包含列表，提议者需要手动请求缺失的信标区块，导入该区块并在其基础上进行构建。
阶段总结
通过上述分析，我们可以识别出潜在的资源密集型环节：IL委员会的CPU负载主要来自EL交易检索和签名操作，虽然这些操作相对轻量，但仍需关注；节点的带宽消耗尤为显著，特别是在当前研究未限制包含列表大小的情况下，这可能导致恶意IL委员会成员用无效交易淹没网络的DOS风险，因此需要精心设计抗DOS机制。
阶段二：节点锁定视图与提议者导入IL交易
提议者的关键操作
提议者使用包含列表交易集更新区块构建流程（CL→EL调用），这一过程会产生CPU/内存开销，特别是在交易模拟阶段可能给执行层客户端带来较大压力。在账户抽象环境下，由于交易间可能相互失效，这种情况会变得更加复杂。
节点的视图锁定
节点在此阶段锁定其包含列表视图，停止接受新的本地包含列表，这一操作本身不产生额外资源消耗。
阶段三：提议者发布区块
区块发布流程
提议者从EL客户端获取执行负载（CL→EL调用）并将其发布至信标区块八卦网络。节点在接收信标区块时需要进行新的验证步骤，包括检查包含列表聚合结构以及在CL上确认包含列表是否满足评估函数，而IL条件的实际检查（如冲突导致的跳过）则在EL上执行。这些验证步骤会带来额外的CPU负载，但总体上影响可控。
阶段四：证明者委员会验证
证明者使用LMD GHOST分叉选择规则对信标区块进行投票，仅支持满足包含列表评估函数的区块。这一过程与现有机制基本一致，不产生额外开销。
资源考量总结
综合分析表明，最关键的资源问题集中在包含列表的上传下载环节及其潜在的垃圾邮件风险。此外，节点验证和导入包含列表的开销，以及提议者为满足包含列表要求而更新区块构建流程的需求，都需要特别关注和精心设计。
待解决问题
基于上述分析，我们梳理出几个影响规范制定的关键问题：如何处理未通过评估函数的区块；包含列表委员会成员向不同节点发送不同版本包含列表的后果；提议者基于不同头部构建区块的影响；包含列表交易失效的各种情形及其处理；以及提议者监控IL委员会子网的最佳策略选择。这些问题都需要在后续工作中深入探讨和完善。
声明：文章不代表CHAINTT观点及立场，不构成本平台任何投资建议。投资决策需建立在独立思考之上，本文内容仅供参考，风险 自担！转载请注明出处：https://www.chaintt.cn/16048.html