数字化契约如何守护？解析聚合签名的妙用

海量数字签名数据如何进行高效存储和验证？能否对来自多个参与方的签名实现数据聚合压缩？如果每个参与方使用不同的签名私钥对不同消息进行签名，聚合签名技术是否依旧可以支持？聚合签名技术使用过程中又有哪些值得警惕的风险？

伴随着经济数字化转型深入，以区块链技术为代表的多方协作技术逐渐普及，如何验证承载着多样化价值的数据有效性早已成为全行业的普遍需求。满足这一需求的关键是引入各式各样数字化契约，而支持契约中数字签名高效验证则是关键中的关键。

海量数据带来了海量数字契约，海量数字契约也进一步带来了海量数字签名，由此难免遇到数字签名数据飞速增长、验证效率不断下降的困扰。

以区块链应用为例，一般情况下，在区块链节点共识过程中，所有节点都需要对整个区块进行签名，并将相关数据，如区块数据、节点公钥、签名数据存储在区块中。随着应用使用量增加，签名相关存储数据也会不停增长。不同于传统应用，链上数据在理论上只增不减，而海量签名带来的海量数据，对于数据存储、网络传输、签名验证都是巨大负担。

在保证海量签名数据可验证的前提下，对数字签名数据进行聚合压缩，其具体技术如何实现？聚合签名在提升系统效率的同时，有没有带来额外风险？且看本文对此逐一解析。

1. 聚合签名的高效性

一个典型的数字契约一般包括消息原数据、公钥、签名三部分。用户通过公钥确认签名者身份，通过数据确认契约内容，从而来认证数字契约的有效性。

对应地，聚合签名的主要设计目标是将多个签名数据压缩合并成单个聚合签名。验证者通过所有签名相关的数据和公钥组成的列表对单个聚合签名进行验证，若验证通过，其效果等同于对所有相关签名进行独立验证且全部通过。

一般情况下，聚合签名产生的签名数据（不包括消息原数据和公钥列表）具有大小固定的特性，即无论有多少原始签名，聚合后签名数据的大小总是恒定的。

聚合签名可以有效降低存储空间和验证过程中网络流量成本，尤其对签名频次较低但验证频次较高的业务场景有显著效果。

回到区块链节点共识应用场景，当前大多数联盟链共识采用ECDSA签名算法。针对区块数据，每个节点用自身私钥生成独立的数字签名，并广播给其他节点。其他节点会验证该签名，并将其写入下一区块数据中。

使用这种方式，当共识节点数较多时，会导致每轮共识区块存储的签名数据不断增加，占用存储空间。每当新节点加入网络，需要同步历史区块时，大量签名数据会对网络带宽造成不小的挑战。

聚合签名方案可以在一定程度上解决以上问题。相比直接保存多个独立签名，使用聚合签名技术后，每个节点会收集其他节点广播的聚合签名分片，然后将签名分片聚合保存。这样，当新节点加入时，同步历史区块只需下载聚合后的签名数据，大大减少对网络带宽的占用。

 

除了数据存储和传输效率提高，当被聚合的数字签名数量足够大，理论上也能提高签名验证的计算效率。聚合签名方案的实际性能与其具体构造方式密不可分，下面我们将以目前最常用的Schnorr与BLS聚合签名为例，介绍其构造细节。

2. Schnorr和BLS聚合签名构造

根据不同聚合能力，以及是否支持对不同消息产生签名进行聚合，常见的聚合签名方案可以分成以下两类：

• 只能对同一个消息使用的不同签名进行聚合，即甲、乙、丙三方对同一份合同A签名，期间产生的三个签名可以合并成一个聚合签名。其典型的构造方案是Schnorr聚合签名，此类构造方案也常被称为多重签名方案。

• 可以对不同消息使用的不同签名进行聚合，即甲对合同A签名、乙对合同B签名、丙对合同C签名，三个不相干的签名可以合并成一个聚合签名。其典型的构造方案是BLS聚合签名。

Schnorr聚合签名

Schnorr聚合签名可以看作一类椭圆曲线上数字签名方案的扩展，其基本构造方式如下：