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

根据不同聚合能力，以及是否支持对不同消息产生签名进行聚合，常见的聚合签名方案可以分成以下两类：
我们需要根据现有的国密技术规范，提炼出聚合签名所需的密码学原语，基于标准方案进行适配构造，具体如下：

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

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

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

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

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

1、聚合签名的高效性

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

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

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

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

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

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

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

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

2、Schnorr和BLS聚合签名构造

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

Schnorr聚合签名

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

使用Schnorr聚合签名的交互过程如下：

值得注意的是，相比经典数字签名，Schnorr聚合签名多了交互随机数和聚合签名过程，同时这里所有签名均是对同一个消息进行签署。

BLS聚合签名

有别于Schnorr聚合签名，BLS聚合签名额外引入了双线性映射，其具备以下特性：

使用BLS聚合签名的交互过程如下：

通过引入双线性映射，BLS聚合签名打破了签名所对应的消息必须是同一个的限制，由此可灵活地支持各类签名聚合需求。同时BLS在聚合过程中交互较少，无需交换随机数的过程，可以有效减少网络传输带来的性能损耗。

但是，双线性映射带来神奇特性的同时，也提升了计算成本。但目前已知的双线性映射构造复杂，计算性能在工程实现上慢了几个数量级。

Schnorr聚合签名和BLS聚合签名各有所长。在聚合能力上，BLS占优，在计算性能上，Schnorr占优，两者具体比较与使用注意事项将在下节中展开。

3、聚合签名的使用注意事项

聚合签名的性能

聚合签名的首要设计目标是压缩签名数据，节省数据存储和网络传输成本。对现有计算机系统，I/O耗时通常是关键性能瓶颈，所以此项优化通常可以提升验证海量签名数据的整体吞吐量。

一般情况下，假定安全参数（参见第3论）为256位，对于Schnorr聚合签名，其典型的签名数据为一个聚合后的点和数，大小恒定为64字节，对于BLS聚合签名，其典型的签名数据为椭圆曲线上压缩后的一个点，大小恒定为33字节。

除了吞吐量之外，验证数字签名的延时通常也是重要性能指标，但这不是聚合签名的强项，以下给出一些基于开源代码实现的实测性能比较结果。

对于Schnorr聚合签名，尽管其验签的理论复杂度比ECDSA签名低，但由于在验证时需要使用公钥列表进行聚合，其性能并没有明显提升；另一方面，在签名过程中，Schnorr聚合签名多了一些交互流程，性能接近但也不及ECDSA签名。

对于BLS聚合签名，由于使用了构造复杂的双线性映射，各项计算性能均显著低于ECDSA签名。同时，双线性映射目前缺乏对应的硬件加速，软件优化也不是很成熟，这种状况可能在未来会得到改善。

聚合签名的国密化

国密化支持是当前密码技术应用的热点方向，然而我国密码行业标准化技术委员会目前发布的标准，尚未明确规定建议使用的聚合签名算法。

• 椭圆曲线公钥密码算法：GM/T 0003.5-2012《SM2 椭圆曲线公钥密码算法第4部分：公钥加密算法》
• 消息摘要算法：GM/T 0004-2012《SM3密码杂凑算法》
• 
  
• 双线性映射：GM/T 0044.5-2016《SM9 标识密码算法 第5部分：参数定义》

聚合签名的安全风险

无论是Schnorr还是BLS聚合签名，在设计过程中都提供了理论证明——即便聚合了海量签名，最终产生单个聚合签名的安全性，都与聚合前的经典数字签名安全性相当。

但是，相比原来只有单方计算的经典数字签名，聚合签名计算过程涉及多方交互，一旦参与聚合的任一方有意作恶，恰逢不安全的工程实现，难免会引发额外的安全风险。

以Schnorr聚合签名为例，一些工程实现为了减少交互成本，在关键的随机数交互过程中，采用预计算方式初始化随机数。然而，如果攻击者不遵守协议约定，构造恶意的特殊数据作为随机数，可能会造成其他用户的密钥泄露。

类似地，对于BLS聚合签名，一些工程实现为了提升计算效率，使用不安全的曲线组合来构造双线性映射，从而破坏了聚合签名算法的整体安全性，进而泄露用户密钥。

预防这些安全风险的关键在于，聚合签名的工程实现应严格按照论文或标准中的算法流程和推荐参数设置，切记不要为了优化性能而引入严重的安全风险。

总体而言，聚合签名为多方协作场景提供了一种节省存储空间和验证过程中的网络流量、提升批量数字签名验证性能的解决方案。

不同的聚合签名针对不同规模的数据量、不同业务领域均具备独特优势，其基础技术选型可以参考下图：

正是：海量契约验证难胜任，聚合签名一键理万机！

通过对多个用户生成的签名进行聚合压缩，聚合签名大幅提升数字签名存储、传输、验证效率，使得海量数字契约中的海量数字签名得以高效验证。

除了本文介绍的Schnorr和BLS聚合签名，基于双线性映射、同态加密或同态性等密码学原语，还可以构造出其他聚合签名方案，比较知名的方案有CL聚合签名、IBAS基于身份的聚合签名等。根据具体的业务需求，选用合适方案，可以显著提升数字签名的使用效率和系统的整体扩展性。

不知不觉，《隐私保护周三见》已与大家相伴近５个月，感谢交流群内各位专家的不吝分享，给予了我们许多启发。本论是栏目第一季的收官分享，下一季，我们将聚焦到具体场景中的隐私保护技术与解决方案，敬请持续关注！

为了提供更优质的内容，诚邀您花1分钟时间参与这份小调研，欢迎将这段时间以来您对栏目的所思所想反馈给我们，我们将从反馈中汲取灵感，为大家呈现更贴心的内容。