news 2026/9/16 20:22:19

EIP-8390 深度解读:移除 Altair 同步委员会,用离线 ZK 证明重塑轻客户端验证

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
EIP-8390 深度解读:移除 Altair 同步委员会,用离线 ZK 证明重塑轻客户端验证

EIP-8390 深度解读:移除 Altair 同步委员会,用离线 ZK 证明重塑轻客户端验证

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs

EIP-8390(Remove the Sync Committee)是一项提案,目标是从以太坊共识层移除 Altair 升级引入的 onchain 同步委员会(Sync Committee)及其全部奖励,并以链下 ZK(零知识)证明作为替代。该提案同时废除完全依赖同步委员会的 Altair 轻客户端同步协议。阅读本文后,你将完整理解同步委员会的设计缺陷、EIP-8390 对共识层各模块(常量、容器、函数、网络、验证者职责)的具体删除清单、其与 EIP-7657(同步委员会罚没)的取舍关系,以及激活该提案前必须解决的安全前提。

同步委员会:为什么存在,为什么被淘汰

Altair 时代的设计背景

同步委员会诞生于 2021 年 Altair 升级,其存在的前提是:当时的轻客户端无法在单个 epoch 内验证上百万个验证者的 BLS 签名。作为折中,协议从活跃验证者集合中抽取512 个验证者作为样本,每256 个 epoch(约 27.3 小时)重新抽样一次。轻客户端信任该样本中三分之二以上签名过的区块头,从而以极低计算成本跟踪链。

在 eip-2982.md 中可以看到对这一机制的概括:一个由 512 名验证者组成的同步委员会每约 27 小时被选出并签署一个区块,其公钥被保存在一个易访问的列表中,使超轻客户端可以轻松验证签名。这套设计在当时是合理的工程取舍,但它留下了三个结构性缺陷,正是 EIP-8390 的动机所在。

缺陷一:同步委员会消息不可罚没(Not Slashable)

Altair 协议为同步委员会消息定义了任何罚没(slashing)条件。一个被腐化的委员会可以签署一个并不存在的链的区块头,而不会损失任何东西。EIP-8390 引用了 EIP-7657 作为最清晰的证据——该提案正是在为同步委员会消息引入罚没条件,这本身就说明今天不存在此类惩罚。

EIP-7657 指出,一旦同步委员会中出现不诚实的绝对多数,攻击者就能构造出恶意但"合法"的LightClientUpdate,诱导依赖轻客户端同步协议的信任最小化桥合约采用非规范的最终化区块头。它提出的SyncCommitteeSlashing机制将攻击成本提升到SYNC_COMMITTEE_SIZE * MAX_EFFECTIVE_BALANCE = 512 * 32 ETH = 16384 ETH(主网)。

缺陷二:样本太小

EIP-8390 给出了具体数字:当时活跃验证者集合为901,505 名验证者,持有42,328,615 ETH。而同步委员会只有其中 512 个席位,相当于每 1,761 个验证者才有 1 个席位。这意味着跟随同步委员会的轻客户端,其安全背书仅来自验证者集合的0.06%,且每天轮换、说谎无罚——一个极薄的安全基础。

缺陷三:发行量为它付费

共识层奖励通过权重分配:SYNC_REWARD_WEIGHT为 2,WEIGHT_DENOMINATOR为 64,因此同步委员会拿走共识发行的2/64 = 1/32。按当时的质押量估算,这相当于每年约33,800 ETH(总发行约 1,082,000 ETH)被用于维持一个存在上述缺陷的机制。

替代方案在今天已经可行:ZK 证明取代抽样

EIP-8390 的核心论点是:同步委员会当年只是"百万签名验证难题"的临时解,而简洁证明(Succinct Proof)已经消除了这一限制。

  • 证明端:对完整活跃验证者集合上的 Casper FFG 最终性进行证明,现在可以在单个 GPU 上、一个 epoch 内完成。
  • 验证端:验证这样的证明只需毫秒级时间,且除了对验证程序的承诺(commitment)外不需要任何密钥材料。
  • 跨链性:同一个证明可以在其他链上验证——而同步委员会机制在其他链上从来无法使用。文中明确指出"实现今天已经存在"(Implementations exist today)。

更重要的是安全语义的升级:由这种证明背书的轻客户端继承的是FFG 最终性保证。要逆转一个已最终化的检查点,三分之二的质押者联盟必须自相矛盾地投票(surround its own vote),且三分之一的质押将被罚没。相比之下,同步委员会没有任何可比的惩罚。

规范详解:EIP-8390 从共识层删除了什么

EIP-8390 的关键词遵循 RFC 2119 与 RFC 8174 的 MUST/SHOULD/MAY 语义。文中未定义的名称沿用ethereum/consensus-specs仓库定义,EIP8390_FORK_EPOCH为激活 epoch。执行层(Execution Layer)无需任何修改——这是一次纯粹的共识层变更。

被移除的常量

以下常量被整体移除:

  • SYNC_COMMITTEE_SIZEEPOCHS_PER_SYNC_COMMITTEE_PERIODSYNC_COMMITTEE_SUBNET_COUNTTARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEESYNC_COMMITTEE_BRANCH_DEPTH,以及轻客户端广义索引(generalized indices)。
  • SYNC_REWARD_WEIGHT。注意WEIGHT_DENOMINATOR保持 64 不变,且该权重不会被重新分配(详见 Rationale)。
  • DOMAIN_SYNC_COMMITTEEDOMAIN_SYNC_COMMITTEE_SELECTION_PROOFDOMAIN_CONTRIBUTION_AND_PROOF。实现方MUST NOT复用这些DomainType值。

被移除的容器

SyncAggregateSyncCommitteeSyncCommitteeMessageSyncCommitteeContributionContributionAndProofSignedContributionAndProofSyncAggregatorSelectionData,以及轻客户端全家族:LightClientBootstrapLightClientUpdateLightClientFinalityUpdateLightClientOptimisticUpdateLightClientHeader

被移除的函数

process_sync_aggregateprocess_sync_committee_updatesget_next_sync_committeeget_next_sync_committee_indices,以及所有建立在其上的轻客户端辅助函数。作为对照,可以在 eip-7658.md 中看到当前process_sync_committee_updates的职责——它负责在委员会周期边界将周期数据归档到previous_best_sync_data,以支持历史轻客户端数据回溯。

BeaconBlockBody 与 BeaconState 的修改

  • BeaconBlockBody:移除sync_aggregate字段,其余字段保持顺序与类型不变。
  • BeaconState:移除current_sync_committeenext_sync_committee字段,其余字段保持顺序与类型不变。

修改后的 process_block

process_sync_aggregate调用被删除,其余流程原样保留:

def process_block(state: BeaconState, block: BeaconBlock) -> None: process_block_header(state, block) process_withdrawals(state, block.body.execution_payload) process_execution_payload(state, block.body, EXECUTION_ENGINE) process_randao(state, block.body) process_eth1_data(state, block.body) process_operations(state, block.body) # process_sync_aggregate(state, block.body.sync_aggregate) # [Removed in EIP-8390]

修改后的 process_epoch

process_sync_committee_updates的调用同样被移除。

奖励结构

get_flag_index_deltasget_proposer_reward均不改变。SYNC_REWARD_WEIGHT是剩余2/64份额的唯一使用者,因此该份额将不再被发行——净效果是共识层发行量下降2/64

网络层变更

  • Gossip 主题:移除sync_committee_{subnet_id}sync_committee_contribution_and_prooflight_client_finality_updatelight_client_optimistic_update
  • ENR 字段:移除syncnets
  • Req/Resp 方法:移除LightClientBootstrapLightClientUpdatesByRangeLightClientFinalityUpdateLightClientOptimisticUpdate

EIP8390_FORK_EPOCH及之后的 slot,节点MUST NOT在这些主题上发布消息,且MUST忽略收到的相关消息。

验证者职责

移除同步委员会相关的全部职责:委员会分配(assignment)、消息生产、子网订阅、聚合者选择与贡献生产。

分叉过渡

分叉升级函数拷贝所有保留字段并丢弃两个同步委员会字段。在EIP8390_FORK_EPOCH及之后,包含sync_aggregate的区块无效

Rationale:为什么是"移除"而非"修补"

修补不够:与 EIP-7657 的对比

EIP-7657 将同步委员会消息变为可罚没,这确实改善了现状,但 EIP-8390 认为这不够:罚没只是把腐化委员会的成本抬高到 512 名验证者的质押额,却没有让委员会成为关于验证者集合的声明。轻客户端仍然信任一个样本、仍然假设样本内部存在诚实多数、仍然支付1/32的发行量。而"三分之二质押者实际证明过什么"的证明,让样本彻底无事可做。

奖励权重不重新分配

移除SYNC_REWARD_WEIGHT而保持WEIGHT_DENOMINATOR = 64,发行量直接下降1/32,无需其他改动。若将分母降为 62 则可保持发行量不变。EIP-8390 明确表态:发行量政策超出本提案范围,但不为已移除的机制继续付费则属于本提案范围。

域类型退役

DomainType值很廉价。退役这三个值,可以防止任何分叉前由同步委员会产生的签名在后来的上下文中继续有效。

向后兼容性影响

这是一次共识层破坏性变更,需要协调分叉:

  • 所有已部署的 Altair 轻客户端都会失效:通过LightClientUpdate同步的客户端在分叉时停止工作。
  • Beacon API 端点移除POST /eth/v1/beacon/pool/sync_committeesGET /eth/v1/beacon/states/{state_id}/sync_committeesPOST /eth/v1/validator/duties/sync/{epoch}GET /eth/v1/validator/sync_committee_contributionPOST /eth/v1/validator/contribution_and_proofsPOST /eth/v1/validator/sync_committee_subscriptions,以及/eth/v1/beacon/light_client/*
  • 编码变化BeaconStateBeaconBlockBody形状改变,按分叉解码它们的工具必须更新。分叉前的状态与区块在其自有分叉 schema 下仍可解码。
  • 验证者无需操作:质押者什么都不用做,同步委员会职责停止分配;质押收益率随发行量下降1/32的共识部分而下降。

安全考虑:激活前的硬前提

激活必须先于替代设施就绪

移除同步委员会会同时移除协议内轻客户端跟踪链的唯一途径。因此本 EIP 激活前,必须已存在公开的证明基础设施,持续发布具有消费者可依赖特性的最终性证明。EIP-8390 明确指出:它不规定该基础设施,调度由客户端团队决定,而非本文档。

证明生产没有协议内激励

本 EIP不增加任何协议内激励来驱动最终性证明的生产,也未提议任何此类激励——这是留给生态的开放问题。

复用域导致签名重放

DOMAIN_SYNC_COMMITTEE0x07000000)与DOMAIN_SYNC_COMMITTEE_SELECTION_PROOF0x08000000)被退役。如果后续某个消息类型采用了任一值,分叉前同步委员会生成的签名将能针对它完成验证——这是实现方在设计新消息类型时必须规避的风险。

总结

EIP-8390 是一份"减法式"的核心协议提案:不新增任何机制,只完整移除一个已失去存在理由的中间层。它用 ZK 证明替代统计抽样,把轻客户端的安全基础从"0.06% 样本的诚实多数假设"升级为"FFG 最终性的质押罚没保证",同时砍掉1/32的共识发行。该提案与 EIP-7657(打补丁)形成鲜明对照,并在 EIP-7658(轻客户端数据回溯)等提案的背景下,勾勒出以太坊轻客户端从"抽样信任"走向"证明信任"的演进方向。当前其状态为 Draft,激活时机与证明基础设施的部署节奏紧密绑定,值得持续跟踪。

Copyright and related rights waived via CC0.

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/16 20:21:59

基于电容电流反馈有源阻尼的单相LCL并网逆变器仿真模型

做并网逆变器仿真这几年,我有个很深的体会:单相LCL拓扑看着简单,真正把仿真跑稳、把谐振压住,才算入了门。网上关于LCL并网逆变器的资料不少,但很多讲原理的多、给可复现细节的少,尤其电容电流反馈有源阻尼…

作者头像 李华
网站建设 2026/9/16 20:21:40

直流牵引系统谐波治理与无源滤波器设计实践

1. 项目概述在直流电气铁路牵引供电系统(TPSS)中,谐波污染是一个长期存在的技术难题。马来西亚自1995年发展电气化铁路以来,采用十二脉冲整流器将交流电转换为直流电的过程中,不可避免地产生了第11次和第13次特征谐波。…

作者头像 李华
网站建设 2026/9/16 20:19:12

Python天气数据工程全链路实战:采集、清洗、建模与可视化

简介:本资源是一份面向计算机专业本科生的Python期末大作业实战项目,聚焦天气数据爬取与可视化分析全流程,适用于课程设计、毕业设计选题及项目能力提升场景。压缩包共24个文件,含4个核心Python脚本(main.py、GetData.…

作者头像 李华
网站建设 2026/9/16 20:16:55

选择排序可视化动图:Python+Canvas从状态快照到动画实现

1. 选择排序为什么值得单独配一张会动的图排序算法这东西,书上看三遍不如自己盯着屏幕看一遍动画来得实在。尤其是选择排序(Selection Sort),它的执行逻辑特别适合做成可视化动图——因为它的行为模式非常"有节奏"&…

作者头像 李华