共识机制（Consensus Mechanism）是区块链事务达成分布式共识的算法。区块链节点共识过程中，所有节点都需要对整个区块进行签名，并将区块数据、节点公钥、签名数据等数据存储在区块中。区块链主要使用数字签名来实现权限控制、识别交易发起者的合法身份，以防止恶意节点冒充。

而随着区块链技术的发展与广泛应用，签名相关存储数据也会不停增长。区别于传统的应用，理论上区块链上的数据只会不断地增加，海量签名带来了海量数据，给签名验证带来了巨大负担。验签时所需要使用的公钥究竟有多大？不同的签名算法数据也有所不同，一般而言 ECDSA/Schnorr/EdDSA 算法 256 bits、BLS 算法 384 bits，如果有上万公钥在验证时候被需要，那么所需的存储的数据量十分庞大。

由上可知，在算法层面大量验证信息需要被存储、被处理，那该如何解决区块链网络繁重的验证问题？近期，Web3 基金会的研究员 Syed Hosseini 介绍了完全简洁的 BLS 聚合签名 APK 证明的强大功能和验证示例。下面将为大家翻译整理 Syed Hosseini 报告中的关键内容，感兴趣的开发者可至文末查看所有参考文献的来源链接。

APK 证明技术所解决的问题

在传统的数字签名算法中，如果一个委员会有很多成员，验证者需要知道每个成员的公钥，并收集每个成员在签署过程中的签名信息，但是这样操作的验证成本非常高。

APK 验证是由 Web3 基金会研究人员设计和实现的一种协议。它允许验证者在不知道每个成员的个别公钥的情况下，验证由签署委员会的部分成员（如一组验证者集合）签署的事实。这项协议的关键之处在于，它利用了 SNARKs 技术，将验证所需的成本大大降低。下面将介绍其如何利用 SNARKs 技术和 BLS 聚合签名实现上述功能。

SNARKs 技术

首先让我们认识一下 SNARKs 技术，其是一种零知识证明的形式，具有以下关键特点：

尽管 SNARKs 非常有潜力，但不可忽视的事，其在“可信设置”初始阶段会生成一些必须保密的参数。如果这些参数受到损害，整个系统的安全性就会受到损害。这导致了其他零知识证明系统的发展，如 zk-STARKs，它们不需要可信的设置，但该技术目前尚不成熟，未得到广泛应用。

而 APK 证明的 SNARKs 基于多项式协议和多项式承诺。其将在委员会成员的公共关键点坐标之间定义一组多项式关系。如果证明者能够说服验证者这些关系成立，那么验证者可以确定小组委员会的聚合公钥是正确的。即 APK 证明可以有效地验证多个成员的签名，而无需知道每个成员的具体公钥。

BLS 聚合签名

BLS 聚合签名是 Boneh–Lynn–Shacham 的简称，其最初由斯坦福大学教授 Dan Boneh 等人提出的一种签名方案。BLS 特点在于采用了基于双线性映射的椭圆曲线配对技术，以实现签名的验证与聚合，即 BLS 签名使用配对函数进行验证来节省区块空间。在运行 APK 证明时，并不需要验证 BLS 签名本身，只验证聚合公钥是否确实正确聚合，这只需要在 Einnₑr （BLS 公钥在曲线 Einnₑr 上定义）上添加功能，并且验证者在验证聚合公钥正确之前，永远不需要使用配对功能。

总之，APK 证明利用了一种承诺机制，只需要验证者拥有一个固定大小的已验证的公钥集合，就可以通过协议提供的简单的证明，来验证聚合签名的正确性。由此，其极大地简化了验证过程，并且减少了所需的信息交换量。这为构建安全可靠的去中心化应用和系统，提供了更加高效和可扩展的解决方案。

APK 证明的区块链轻客户端实践

目前，现有区块链上的计算和存储成本远高于现代手机浏览器中的成本。因此，受到手机等设备在计算能力方面存在的限制，很多区块链应用无法得到普及。目前轻客户端又依赖于全节点去执行大量操作，轻客户端需要发送多个请求来执行简单的操作，因此所需的总体网络带宽高于全节点的带宽。

此外，对于波卡生态而言，区块链互操作性的一个关键挑战是实现一个拥有高效且安全的链上轻客户端协议。现有的协议在验证方面要么缺乏责任制，要么效率低下。如 Cosmos 的采用跨链通信 IBC 协议，该协议的效率问题成为网桥中使用链上轻客户端验证器的障碍。而 APK 证明凭借高效的验证，为构建安全可靠的去中心化应用和系统，提供了更加高效和可扩展的解决方案。

责任制的轻客户端系统

Web3 基金会研究员定义设计并实现了第一个责任制的轻客户端系统（accountable light client system），其具有高效验证、安全等优势，且可作为核心模块集成到 SNARKs 友好的 PoS 区块链安全桥中。具体而言，该轻客户端系统将具有以下特点：

- 责任制：该轻客户端系统是负责任的。即如果轻客户端验证器被误导，并且其通信的记录被提供给网络，那么可以识别到大量行为不端的共识参与者。一方面，当向轻客户端验证器发送最少的数据时，在轻客户端系统上识别行为不端的共识参与者是具有挑战性的。另一方面，识别不当行为对于任何利益证明协议都是必要的，其安全依赖于识别和惩罚不当行为的共识参与者。

- 异步安全：即在共识的诚实假设下，该轻客户验证器不会被误导。即使它对网络的视野有限，如其只连接到一个节点，这可能是恶意的。这是其继承了区块链拜占庭协议的异步 (asynchronous) 安全特性，在异步的网路环境中，确定性质的协议无法容忍任何错误。

- 递增性：即它的简洁状态（Succinct State）是渐进更新的。有效的更新与桥接应用程序关系密切，而不是试图优化验证区块链起源的共识决策。

总之，责任制的轻客户端系统在使用 BLS 聚合签名和 SNARKs 技术的区块链之上轻松实现高效验证。作为 Polkadot 生态系统的一部分，目前开发人员正在将该轻客户端整合到 Polkadot 和 Kusama 中的 live Substrate bridge。

以下是利用此类证明设计的区块链轻客户端部分代码示例：

use std::cell::RefCell;use std::collections::HashSet;use ark_bls12_377::{G1Projective, G2Projective}use ark_bw6_761::BW6_761;use ark_ec::AffineRepr;use ark_serialize::CanonicalSerialize;use ark_std::{end_timer, start_timer};use ark_std::test_rng;use fflonk::pcs::kzg::params::{KzgCommitterKey, RawKzgVerifierKey};

示例全文请参阅：

https://github.com/w3f/apk-proofs/blob/main/bw6/examples/recursive.rs

轻客户端将为去中心应用程序的发展、促进加密网络的大范围采用提供关键推动力。如上文所述，APK 以技术创新实现强大的功能，进一步提高轻客户端协议的效率和可靠性，也期待该技术后续更多地应用到去中心化应用之中。OneBlock 将持续关注波卡与 Substrate 生态相关技术更新，希望能够为各位开发者提供一些启发。

参考文献

Fully Succinct BLS Signature Aggregation

https://github.com/w3f/apk-proofs

Accountable Light Client Systems for PoS Blockchains

https://eprint.iacr.org/2022/1205.pdf

Zero Knowledge Proofs, SNARKs, STARKs and Bulletproofs

https://medium.com/@alfonsocamblor/zero-knowledge-proofs-snarks-starks-and-bulletproofs-871bdbbafa99

Research Update: APK Proofs By Hand and Sage

https://medium.com/web3foundation/apk-proofs-by-hand-and-sage-3f5feb3fcca4

Accountable light clients From SNARKS

https://docs.google.com/presentation/d/16LlsXWY2Q6_6QGZxkg84evaJqWNk6szX/edit#slide=id.g19944a07c60_0_137