AMA Protocol共识流程拆解：entry、attestation与fabric协调全链路
AMA Protocol共识流程拆解entry、attestation与fabric协调全链路【免费下载链接】node项目地址: https://gitcode.com/GitHub_Trending/node95/node想快速理解 AMA Protocol 共识机制这篇面向新手的共识流程拆解带你一步步看懂 entry、attestation 与 fabric 协调三者如何配合完成从出块、投票到最终确认的全链路。AMA Protocol 是一个主打隐私的 Layer 1 公链采用 MatMul 的有用工作量证明UPoW出块时间 500ms每 10 万个区块为一个 epoch签名使用 BLS12-381 聚合签名合约运行在 WASM 虚拟机上。AMA Protocol 共识流程的核心并不复杂entry条目即区块负责承载交易attestation认证负责给 entry 背书投票而fabric协调层负责把分散的认证聚合为最终共识。本文按时间线拆解这条全链路新手也能看懂。一图看懂AMA Protocol 共识流程全景先看整体流程再逐个环节拆解认识三个核心角色entry、attestation、consensusAMA Protocol 共识流程里有三个层次的数据结构分别解决记了什么、谁同意、同意了多少三个问题角色作用关键字段代码入口entry链上的区块打包交易header、txs、hash、sig、maskentry.exattestation验证者对 entry 的投票entry_hash、mutations_hash、signer、signatureattestation.exconsensus聚合后的共识证明entry_hash、mutations_hash、aggsig(mask)consensus.ex:::tipmutations_hash状态变更哈希是共识的灵魂验证者不只投票这个 entry 存在还投票这个 entry 执行后产生的状态变更是什么。这保证了所有节点最终执行出完全相同的状态。 :::第一步entry 如何被构造并广播当 validator 节点发现自己是下一个 slot 的出块者时FabricGen.proc_if_my_slot会触发出块流程见 fabric_gen.ex从TXPool抓取合法交易上限约 3MB调用Entry.build_next构造头部slot加一、prev_hash指向前一个 entry、dr是延迟随机数、vr是 VRF 随机数见 entry.ex调用Entry.sign用 BLS 私钥对头部哈希签名写入本地并广播event_entry给全网entry 的root_tx是交易哈希的默克尔根root_validator是当前验证者集合的根root_chain则是整条链历史状态MMR的根——这正是 AMA Protocol 共识中轻节点也能验证历史的基础。第二步应用 entry 并生成 attestation收到 entry 后每个节点都会执行FabricGen.apply_entry_1见 fabric_gen.ex这一步是全链路中最重的一环用RDB.apply_entry执行 entry 内的所有交易包括 WASM 合约产出receipts与状态变更mutations计算mutations_hash Blake3(receipts mutations)把 entry 写入主链临时尖端temporal_tip验证者用Attestation.sign对entry_hash mutations_hash签名投票见 attestation.ex这一步完成后网络中就流动着大量单张的 attestation——它们还只是个人意见需要被聚合才有分量。第三步attestation 如何汇聚成 consensus这就是fabric 协调登场的时刻。所有 attestation 会汇聚到FabricCoordinatorGen见 fabric_coordinator_gen.ex由它完成聚合校验投票者确实在当前验证者集合内用BLS12AggSig.add_padded把签名累加成一个聚合签名同时用位图mask记录谁签了写入DB.Attestation.set_consensus——注意它只保留分数更高的版本见 db_attestation.ex:::note BLS 聚合签名的妙处99 个验证者的签名最终只有96 字节广播和存储成本极低。mask_size是验证者总数mask_set_size是已签名人数两者之比就是共识分数见 bls12_aggsig.ex。 :::第四步fabric 协调——rooted_tip 如何被最终确认拿到聚合后的 consensus 还不够链必须决定哪个 entry 才算正式确认。FabricGen.proc_consensus每 100ms 检查一次临时尖端和已确认尖端见 fabric_gen.exbest_entry_for_height会为每个高度选出共识分数最高的 entry只有score 0.67约 2/3 多数的 entry 才会被写入rooted_tip正式成为链上确认块一旦确认触发FabricEventGen.event_rooted通知全网并从交易池删除已打包的交易️ 两个重要的异常保护AMA Protocol 共识流程对分叉和异常状态做了严格防御软分叉回退如果共识选出的 entry 不在本地主链上节点会rewind回退到前一个高度再重新同步见 fabric_gen.ex紧急停机如果共识选择了某 entry 但本地计算出的mutations_hash不一致说明状态已和网络脱节节点会打印 EMERGENCY 日志并直接 halt绝不带病出块见 fabric_gen.ex第五步容错与自愈机制理解 AMA Protocol 共识流程还必须知道它的两道补丁 补认证retro-attest如果节点在重启或主备切换的领导空窗期应用了 entry可能漏掉对该 entry 的认证。maybe_retro_attest会在 8 秒宽限期后为尚未拿到自己签名的尖端 entry 补上签名见 fabric_gen.ex避免链条在未认证状态下卡死。️ 认证缓存AttestationCache网络是异步的attestation 可能先于它的 entry 到达。FabricCoordinatorGen把父 entry 还没到的 attestation 暂存进缓存等 entry 到达后再补聚合缓存 30 秒自动清理过期项见 fabric_coordinator_gen.ex。关键代码入口速查表想深入阅读源码按下面路径顺着读就是完整的 AMA Protocol 共识流程主线环节模块路径关注点出块调度fabric_gen.extick 主循环entry 构造与签名entry.exbuild_next / signentry 校验entry.exvalidate_entry / validate_nextattestation 签名与校验attestation.exsign / validate / validate_vs_chain聚合签名算法bls12_aggsig.exmask / score / add_padded认证协调器fabric_coordinator_gen.exadd_attestation / aggregate_attestation共识确认决策fabric_gen.exproc_consensus / best_entry_for_height共识存储db_attestation.exset_consensus / best_consensus_by_entryhash总结一条从交易到确认的快车道把整个 AMA Protocol 共识流程浓缩成一句话出块者构造 entry → 全网应用并执行合约 → 验证者签名 attestation → fabric 协调器聚合成 consensus → 分数达到 2/3 后写入 rooted_tip → 循环往复。500ms 一个区块、BLS 聚合签名把投票压缩到 96 字节、0.67 阈值保证拜占庭容错约 1/3 恶意节点安全、mutations_hash 强制状态一致——这四个设计共同撑起了 AMA Protocol 快速、低开销又安全的共识机制。希望这篇拆解能帮你从听过名字进阶到看懂源码下次读 fabric_gen.ex 时就能顺着主线一路畅通了。 如果你正在运行 validator 节点建议重点研究proc_if_my_slot与apply_entry_1两段代码——前者决定你能否准时出块后者决定你能否产出正确的 mutations_hash两者都是参与 AMA Protocol 共识的关键。【免费下载链接】node项目地址: https://gitcode.com/GitHub_Trending/node95/node创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
