本文深入探讨了以太坊信标链在超过1/3验证者永久离线时如何自动恢复最终性,重点分析了非活跃性泄漏机制,以及EJECTION_BALANCE对最终性恢复的影响,并讨论了EIP-7251提案(增加MAX_EFFECTIVE_BALANCE)对现有机制的潜在影响,最终建议在实施EIP-7251时保持EJECTION_BALANCE不变。
EJECTION_BALANCE
MAX_EFFECTIVE_BALANCE
本文总结了 Lighthouse 客户端用户调查的结果,调查内容包括用户使用时长、使用的其他客户端、用途、节点位置、硬件配置、更新频率、资源使用、支持反馈、操作系统、容器化、云服务提供商、CPU核心数、内存大小、验证器数量、备用节点、MEV-boost使用情况和中继选择等方面。调查结果为 Lighthouse 的未来发展方向提供了参考。
Lighthouse v4.5.0 版本引入了QUIC协议,该协议通过结合连接建立和加密握手,减少了延迟,并通过更成熟的多路复用实现提高了吞吐量。
本文档是使用代理模式的基本指南,主要讨论了使用代理的优缺点、代理的类型(推荐 UUPS 代理),以及使用代理的最佳实践,包括使用 OpenZeppelin 的代理合约、使用 Initializer 而不是 Constructor、单次交易中设置和初始化等。
Lighthouse发布了其验证器管理UI(代号:Siren)的首个稳定版本。Siren通过连接到Lighthouse Beacon节点和Validator客户端,汇总有用的数据,展示节点和验证器的基本健康状况、验证器的性能以及状态,并简化了修改操作,如撤回验证器或修改其graffiti值。
本文揭露了一种针对MEV relay的新型解绑攻击,该攻击利用了RPC绕过gossip duplicate filter,并利用fork choice机制中的“latest block wins”特性。Lighthouse v4.1.0版本通过修改RPC区块的处理方式缓解了此问题。文章还讨论了更全面的解决方案,包括修改fork choice规范,以及client多样性的重要性。
Sigma Prime 与 Satalia 合作,研究以太坊 2.0 中 Attestation Packing 问题。研究表明,Lighthouse 客户端使用的贪婪算法在大多数情况下接近最优,且在可接受的时间内可以找到最优解。因此短期内不会在生产环境中采用精确算法,而是关注提高现有贪婪算法的速度和改进与其他构建器的交互。