有人给你一份聚合签名，说“四个验证者一起同意了这个区块”。验签为真就等于区块有足够票数、已经最终确定吗？不行。你至少要知道这四个公钥对应谁、该时刻谁有投票资格和多少权重、他们各自签的哪个消息与域、聚合里实际有哪些成员，再按协议状态判断阈值。聚合解决的是验证和传输大量相关签名的一部分成本，不是共识规则本身。

不要拿交易签名去解释验证者投票

28 的 Ethereum type-2 交易由执行层 EOA 用 secp256k1 授权：确定账户、nonce、链 ID 和交易字节后，执行客户端还需核对余额、费用和执行规则。共识层验证者的 BLS 签名则用于对规定的共识消息（如 attestation 指向的目标）投票，签名字节由其签名根及 domain 等上下文决定。两种签名各有独立的密钥持有人、验证对象与状态来源；拿“交易账户验签通过”推出“验证者已投票”，或反过来，都是换了命题。

1
2
3
4
5
6
7
8
执行层：钱包 secp256k1 ─► 有类型交易的签名字节 ─► 账户规则检查

共识层：验证者 BLS 私钥 ─► 指定 slot/root/domain 的签名
                        │   聚合相关签名、携带参与成员信息
                        ▼
   共识客户端：已注册公钥/权益状态 + 消息域 + 成员与签名验证
                        ▼
                  分支、阈值和最终性规则（另查）

BLS 签名在选定曲线和配对群上，允许把多个可验证的签名聚合为较短的结构；但公钥集合与参与成员仍要作为验证输入，不会凭空消失。对于“同一消息”的快速聚合检查，要确保确实是同一签名根及上下文，不把不同目标或不同 fork 的消息混为一组。恶意参与者还可能构造与别人公钥有关系的 rogue key，让简单的“公钥相加，签名相加”出现问题；注册或签名方案需要对应的成员与持有私钥证明等机制。本实验用库的 proof of possession 模式说明一个边界，不表示 Ethereum 共识实现使用了实验的同一个注册流程或相同编码。

另一个较隐蔽的分工：密码学只能回答“这些真实已配置的密钥对指定消息形成有效聚合吗”；不知道验证者名单、权益权重、epoch、slot、fork 及规则就无法回答“这份消息的支持是否过阈值”。两个验证者各持一票而总共四人时，真聚合签名可验，2/4 仍低于 2/3。即使超过一个简化阈值，也不能不检查正确检查点、可接受链分支与规则就称已达成最终性。

真 BLS 库演示与哪些东西没有演示

examples/cryptography/33_bls_votes.py 在冻结 py_ecc==8.0.0 的 G2ProofOfPossession 中，用四个公开的小整数教学密钥生成公钥及持有证明，两名对同一合成 slot-5:root-A 消息签名并合并。库验证聚合为真；把消息根改为 B，或用错公钥核对持有证明/单人签名，均失败。同时单独算 2/4 的人数条件：即使聚合成立也达不到教学上设的三分之二门槛。

先按仓库内 examples/cryptography/README.md 完成环境准备；以下命令从仓库根目录执行。

1
2
python examples/cryptography/33_bls_votes.py
python -m unittest discover -s examples/cryptography -p 'test_33*.py' -v

两项测试通过，不代表有真实验证者、共识消息编码、domain separation、签名成员 bitlist、PoP 注册流程、真实权益权重或共识客户端验收；它们全部 NOT_RUN。教学私钥公开且低熵，绝不可用于实际节点。只有把原始签名、参与成员和可信共识状态都填上，才有可能推进到历史和最终性判定。

在贯穿交易案例里，钱包经 HTTPS RPC 交给节点的是执行层签名交易：HTTPS 认证服务端和保护传输；钱包签名授权交易；共识层验证者 BLS 投票可以参与区块历史和最终性。这三个过程分别失败时，错误定位也不同。拿单个验证者聚合的成功输出冒充“订单已交付”，跨越了所有这些边界。

练习及答案

画图题： 画出两个验证者签同一个候选根、另外两个未投票、总权重均等的场景。删除“从共识状态加载本期验证者名单和权重”后，攻击者可以怎样给出一份数学上验真的聚合？

答案： 两名持有私钥的人可以生成对应根的真签名，聚合后在他们自己的两个公钥下验真；如果不核对这些公钥是否为本期有效成员或权重，攻击者可以选择自己的公钥集合并自称为验证者。即便确属四名中两名，等权 2/4 仍低于 2/3，不得标为达到门槛。链的最终性还需执行共识规则而不止人数计算。

实验变更题： 将第二人的签名消息改为 slot-5:root-B，仍按“同一消息 root-A”快速验证；再保留正确签名但把候选 public_keys[1] 换成未注册公钥。为什么两个失败不等价？

答案： 第一处混合不同消息，不能当作同一根的一组票；应按各自消息分别验证或按协议规则处理，不能把数学上的可聚合性冒充投了同一目标。第二处给验证器错误身份/成员公钥，签名与列出的公钥不对应，且新公钥还须经过成员资格与密钥持有验证。修正哈希根不会自动修正身份来源。

资料与衔接