下一个 mev-boost 社区电话会议定于下周举行！将讨论 fusaka 和潜在的 glamsterdam 对构建者/中继生态系统的影响。 希望能在那儿见到你！下条推文中有详细链接。

各客户团队的重点推荐： 执行层： - Geth: EIP-7928（区块级访问列表） - Reth: EIP-7928 + EIP-7732（ePBS） + EIP-7805（FOCIL）扩展 - Erigon（执行层 + 共识层）：EIP-7928 + EIP-7805 + EIP-7782（减少区块延迟） - Nethermind: EIP-7928 + EIP-7732，同时支持EIP-7805 + EIP-7692 - Besu: EIP-7928 + EIP-7732 + EIP-7805扩展 共识层： - Lighthouse: EIP-7732（ePBS） - Prysm: EIP-7732 + EIP-7805扩展 - Grandine: EIP-7732 + EIP-7805扩展 - Lodestar: EIP-7732 + EIP-7805扩展 + EIP-7919 Pureth用于执行层 - Teku: EIP-7732 - Nimbus（共识层 + 执行层）：EIP-7732 + EIP-7919

每个区块链选择的技术和文化权衡使其更适合某些用例而不是其他用例。 我之所以是以太坊的粉丝，是因为它在构建未来金融方面选择了比其他区块链更好的权衡。这是我认为最有趣的用例。

EIP-7782：6个时隙时间 将区块时间减半。这将改善用户体验、互操作性和MEV。 一个额外的意外好处是，缩短的时隙时间可以通过减少每个时隙的空闲时间来改善扩展性。

EIP-7805: FOCIL = 分叉选择包含列表 在每个时隙中增加更多提议者，以提高网络的抗审查能力 将减少被审查交易的包含时间，并减少对家庭质押者在抗审查能力上的依赖

EIP-7732: ePBS = 规定的提议者构建者分离 重构时隙以减少空闲时间并延长传播和执行窗口 ePBS 可能会增加包含时间（这不好），尽管这一点存在很大争议，并且取决于构建者的行为

EIP-7886: DE = 延迟执行 还扩展了传播和执行窗口 与 ePBS 互斥，但更专注于执行而非共识

EIP-7928: BAL 的 = 区块访问列表 当与最大交易大小的上限（EIP-7825）结合时，能够实现每个区块的并行处理 并行处理的好处可能要到 Glamsterdam 之后才能准备好

每个人都在对 glamsterdam EIP 形成看法，但几乎没有人理解每个提案的技术含义。 这里是对重要维度上头条 EIP 的直接比较：

呼吁所有 L2 团队和希望在 Fusaka 中实现 EIP 7907 的智能合约开发者，开发者们正在认真考虑在升级中加入此提案，并将在本周四的 ACDE 电话会议上决定下一步行动，因此如果你对此事感兴趣，请务必参加！