比特币的跨输入签名聚合（Cross-Input Signature Aggregation，CISA）

1. 引言

2024 年，人权基金会（Human Rights Foundation，简称 HRF）启动了一项研究奖学金计划，旨在探讨“跨输入签名聚合”（Cross-Input Signature Aggregation，简称 CISA）的潜在影响。CISA 是一个拟议中的比特币升级提案，预计将大幅降低私密交易的成本。目前，使用隐私保护功能的比特币交易通常需要额外费用，这限制了许多用户使用这些功能的意愿或能力。此外，这些额外费用在威权政权下可能成为一种风险，因为当局可能会质疑为何用户选择使用增强隐私的方式。

该 CISA 奖学金授予了开源开发者 Fabian Jahr，他花了六个月时间研究 CISA 的潜在影响。其在一份长达 38 页的报告——《Cross-Input Signature Aggregation for Bitcoin》中分享了他的研究成果。Jahr 在报告中出色地回顾了比特币历次升级的历史，并阐述了为何 CISA 或许是继 SegWit 和 Taproot 之后的下一个逻辑升级步骤。

1.1 内容摘要

《Cross-Input Signature Aggregation for Bitcoin》内容摘要为：

CISA 允许将来自不同输入的多个 Schnorr 签名聚合为一个单一签名，从而显著减少交易体积并节省手续费。
CISA 并不是一个单一概念，它包括不同的聚合模式（完全聚合和半聚合）与范围（交易级和区块级），需要在即将提出的提案中权衡它们的优劣。
通过降低多输入交易的成本，CISA 鼓励并常态化使用协作式隐私工具，如 CoinJoin 和 PayJoin，替代普通交易，从而增强用户匿名性并提升网络效率。
企业，尤其在进行“资金整合交易”时，能获得显著节省，这有助于抑制 UTXO 集合的增长，并加快交易所和电子商务平台的采用速度。
实现 CISA 需要进行一次软分叉（soft fork），并且仍需进一步的密码学研究，以制定一项能最大化网络收益的提案。

1.2 跨输入签名聚合（CISA）简介

跨输入签名聚合（Cross-Input Signature Aggregation，简称 CISA）是一个比特币协议的提案性增强功能，它允许将单个交易中，甚至多个交易中，不同输入所使用的多个 Schnorr 签名聚合为一个更小的单一签名。这一变更将减少比特币交易的数据体积，从而带来潜在的手续费节省以及处理效率的提升。

除了上述优势，CISA 还可能通过激励特定类型的协作式交易（如包含多个输入的 CoinJoin 和 PayJoin）来提升隐私性，这与比特币提高可替代性（fungibility）和金融隐私的长远目标一致。这种改进并不会以牺牲用户体验为代价——在最差的情况下，用户体验应与当今 CoinJoin 和 PayJoin 所提供的体验相当，而这类交易仍有大量用户体验优化空间。

CISA 是基于 Schnorr 签名在比特币中通过 Taproot 软分叉（BIP 340）所实现的激活基础之上的进一步演进。与中本聪最初选择用于比特币的 ECDSA 签名算法不同，Schnorr 签名具备可加性和线性特性，允许多个签名者将各自的签名合并为一个，同时仍能被验证。

自 Taproot 软分叉以来，比特币用户已经可以在多重签名策略（multisig policy）中使用一种被称为“密钥聚合”（key aggregation）的方式进行签名聚合，如通过 MuSig2 协议。但这些方法仅适用于密钥持有者共享同一个脚本或地址的特定场景。 而 CISA 的不同之处在于，它允许不同参与方所拥有、使用不同密钥的独立输入被聚合为单个签名进行签名验证。

如果 CISA 被激活，它可能会激励用户行为的变化，使像 CoinJoin 或 PayJoin 这样的协作式交易变得更加便宜，从而使增强隐私的实践变得常态化和普及，并整体上加强比特币网络的隐私性。对于人权倡导者或其他具有更高隐私需求的用户来说，更低成本的隐私保护功能以及更大的匿名集（anonymity set）将是重要的好处。

与此同时，对于处理大量交易的企业（如交易所），尤其是在进行 UTXO 整合操作时，也能从中享受更低的链上手续费。随着 CISA 被更广泛采用，企业以及钱包实现应当顺应趋势，优先使用协作式交易方式进行交易。出于节省成本的动机而进入该领域的企业，将为那些因隐私原因而使用这类交易的普通用户提供额外的法律保护屏障。

然而，实现 CISA 需要一次共识更改，即一次软分叉（soft fork），因此比特币社区与开发者需要就带有聚合签名的交易和区块的新验证规则达成一致。

本报告概述了 Schnorr 签名聚合及相关概念的背景，预览了 CISA 的潜在技术细节（包括“半聚合”与“完全聚合”的变体），探讨了将其纳入比特币共识规则的可行性，并展望了未来的可能开发步骤。报告还探讨了 CISA 的潜在应用，从企业视角到用户体验，并讨论了 CISA 如何与其他比特币协议提案相互作用。

2. 背景与历史语境

本节将探讨 Schnorr 签名及签名聚合在比特币中的历史背景，并简要考察其他采用签名聚合作为协议组成部分的加密货币项目。

2.1 比特币之前

德国数学家与密码学家 Claus-Peter Schnorr 于 1989 年在 CRYPTO '89 大会上发表的开创性论文中首次提出了 Schnorr 签名方案 [schnorr-wiki]。该论文题为《适用于智能卡的高效身份认证与签名》（Efficient Identification and Signatures for Smart Cards），其中 Schnorr 首先介绍了一种交互式身份认证协议，该协议可以在不泄露秘密的前提下证明对该秘密的掌握，随后他展示了如何通过 Fiat–Shamir 启发式方法将其转化为非交互式的数字签名方案 [schnorr-alinush]。

这个签名方案依赖于离散对数问题的计算困难性，这使其成为最早一批完全基于离散对数假设（而非因式分解或其他问题）构建安全性的签名设计之一 [schnorr-wiki]。

Schnorr 签名相较于早期的数字签名算法（如 RSA 或 ElGamal）是一种显著的突破。它结构更为简洁、效率更高。Schnorr 签名不仅签名更短，计算上也更为简单直接——与 RSA 中的大指数运算或 ElGamal 的双输出相比 [schnorr-cse]，Schnorr 设计体现出对实用性需求的强烈考量：该方案旨在为如智能卡等设备提供足够高效的签名方法，并通过减少计算与存储开销来改进现有方案 [schnorr-wiki]。

Schnorr 签名提出后，引起了学术界的广泛兴趣。密码学家们赞赏其优雅性——一位专家曾评论说，它是“理论与直觉上正确的做法，而不是（EC）DSA 这类令人厌恶的方案” [schnorr-cse]。早期研究进一步确立了 Schnorr 签名的安全性：如 Pointcheval 与 Stern 在 1996 年证明，在假设离散对数问题难解的前提下，Schnorr 签名在随机预言机模型中具有可证明安全性 [schnorr-cse]。在当时，签名算法具备形式化安全证明尚属新颖，因此这为 Schnorr 提供了坚实的科学基础。

尽管在密码学界获得高度认可，Schnorr 签名在现实世界中的应用却多年未能普及。主要障碍在于专利问题：Schnorr 于 1990 年为其签名算法申请了专利（美国专利号 US 4,995,082）[schnorr-wiki]，发布不久即受法律保护。这使得开发者与标准组织在面对法律风险与授权成本时望而却步。

事实上，即便 Schnorr 方案被认为简单而强大，美国国家标准与技术研究院（NIST）在制定数字签名标准时仍选择不采用，而是在 1991 年推出了与其极为相似、但刻意规避专利侵权风险的 DSA（数字签名算法）[hackmd]。尽管 Schnorr 本人坚持认为 DSA 仍侵犯了其专利权，但该主张备受争议 [bitmex]。

这种状况导致 1990 至 2000 年代初期形成了一个悖论：Schnorr 签名在理论上被认为是安全甚至更优的，但却在标准体系与主流软件中难觅踪影。相比之下，NIST 的 DSA 及其椭圆曲线版本 ECDSA 已广泛部署十余年。像 OpenSSL 这类主流密码库——支撑着现代网络安全通信加密解密工作——并未提供即插即用的 Schnorr 实现，却长期支持 ECDSA，这进一步使得新项目倾向于使用 ECDSA。

当中本聪在 2009 年推出比特币时，Schnorr 的专利刚于 2008 年到期 [bitmex]，但包括 OpenSSL 在内的工具生态尚未跟进支持 Schnorr。在当时，采用 ECDSA 是更为自然的选择——它已被验证、无需授权费用且开箱即用，尽管 Schnorr 从技术上可能更具优势。正如比特币开发者 Pieter Wuille 所指出的那样：“在比特币诞生时，已经为时已晚——人们更倾向于使用一个广为人知、标准化的方案，而不是自己设计一套加密方案。” [bse-ecdsa]

直到多年之后，摆脱法律壁垒的 Schnorr 签名重新受到比特币技术社区的关注，并因其潜在的新应用前景再次成为研究与开发热点。

2.2 比特币语境下的 Schnorr 签名聚合讨论

随着 Schnorr 签名专利的到期以及比特币逐渐成熟，开发者意识到，引入 Schnorr 签名不仅能够提升隐私性与效率，还为诸如 CISA（Cross-Input Signature Aggregation，跨输入签名聚合）等新型机制提供了可能性。这使得比特币的功能可以突破 ECDSA 所能实现的实际边界。然而，从 ECDSA 迁移到 Schnorr 需要一次软分叉和大量审查，最终在 2021 年 11 月以 Taproot 升级的形式正式激活。

Taproot（BIP 340/341/342） 以向后兼容的方式将 Schnorr 签名引入比特币 [ops-taproot]。尽管最初的 Taproot 提案并未包含 CISA 功能，但它为未来实现这项增强功能奠定了基础。事实上，本文所描述的大多数 CISA 相关构想，早在 Taproot 软分叉筹备期间就已经陆续被社区讨论。

比特币核心开发者在 2016 年 5 月于苏黎世举行的 CoreDev 会议上讨论了 Schnorr 签名聚合的问题，提出了多个聚合层级的设想。其中，“跨交易输入的签名聚合”概念首次被提出，即将一笔交易中所有输入的签名合并为一个签名。他们还进一步设想，将聚合扩展到整个区块级别（甚至考虑使用 BLS 签名），以及为隐私目的进行输入/输出方向的单向聚合，并指出若交易共享一个聚合签名，将具备一定的抗审查能力 [coredev16]。

在 2016 年中期的一次比特币开发者与矿工会议上，斯坦福大学著名密码学教授 Dan Boneh 呼吁迁移至 Schnorr 签名，并启用交易级别的签名聚合。他估计，若广泛采用这种跨输入聚合方法，可节省约 30% 的区块空间。Boneh 还建议通过一次软分叉引入此功能，作为迈向全区块级签名聚合的第一步 [boneh16]。

2016 年 10 月，Pieter Wuille 在米兰举行的 Scaling Bitcoin 会议上介绍了 Schnorr 签名，并描述了一种潜在的 CISA 功能。他指出，CISA 可将区块大小减少约 20%，这一增益虽然温和，却能通过允许 CoinJoin 参与者共享一个签名来对齐激励机制，从而共同分摊交易费用。Wuille 还解释道，在 SegWit 激活后，实现每笔交易仅一个签名将非常直接，并且通过批量验证签名的方式可以显著提升验证速度 [milan16]。

2017 年 5 月，Tadge Dryja 在 bitcoin-dev 邮件列表上提出了一种区块级非交互式 Schnorr 聚合方法。他的思路是：矿工可以将整个区块内所有 Schnorr 签名的 s 值求和，仅将聚合后的 s 值记录在 coinbase 交易中。这样，每个签名的大小可以缩减为 32 字节，不仅节省空间，也加快区块验证速度，因为整个区块只需一次标量乘法即可完成验证。他同时也指出该方案可能带来的副作用，如增加 mempool 缓存复杂度与快速失败验证机制的失效，但希望社区对此提出反馈 [tadge]。

进入 2018 年初，社区开始更加关注 CISA 的安全性问题。在 BPASE 2018 大会上，Wuille 回顾了阻碍立即部署 CISA 的主要难题。他描述了天真的多重签名方案中可能出现的“恶意密钥攻击”（rogue-key attack）：攻击者可以复制另一个签名者的公钥及消息，在不同输入中重复使用，从而欺骗性地授权花费受害者的币。已知的解决方法是要求每个签名者通过额外签名或承诺来证明其对公钥的所有权，但这样一来，这些证明必须写入链上，反而会抵消绝大多数效率收益。因此，这些未解决的安全隐患使得 CISA 无法在 Schnorr/Taproot 升级中安全地包含 [bpase]。

在 2018 年 2 月，Greg Maxwell 提出了一项对 Taproot 的扩展——Graftroot，并指出它可以利用 CISA。Graftroot 的朴素实现通常需要额外的一个 64 字节签名，但 Maxwell 指出，一个被称为 “非交互式 Schnorr 聚合技巧”（现称 half-agg）的方案可以将普通签名与 Graftroot 签名的 s 值统一合并为一个聚合签名。这样，多个 Graftroot 的代理脚本就能分别只增加约 32 字节的开销。他认为这可以将所有签名绑定到交易上，同时保持 Graftroot 与 Taproot 接近的成本 [graftroot]。

同年，开发者们也意识到 CISA 会使未来脚本升级更加复杂。开发者 Anthony Towns 指出，在软分叉中将聚合签名与新 opcode 结合将存在困难。他举了一个关于假想 covenant opcode 的例子：若第二个签名是条件性必需的，而旧节点无法验证这一条件，就会错误验证聚合签名集合，破坏软分叉的一致性假设。他提出的应对策略是将签名划分为不同“buckets桶”，以适应不同条件，但这也显著增加了复杂度。这一讨论强调了跨输入聚合与某些脚本升级操作不可同时推进的技术冲突，最终促成了暂缓引入 CISA 的决定 [aj]。

在 Taproot 激活前不久，开发者们明确指出 Taproot 不包含 CISA。2020 年 8 月，在 Reddit 的 r/Bitcoin 板块上发布的一篇帖子专门澄清了这一误解，解释称虽然 Schnorr 签名为 CISA 的实现提供了可能性，但出于工程复杂性考虑，CISA 被有意从 Taproot 提案中排除。该贴还重申了 CISA 的优势——多个输入共享一个签名可极大降低大型 CoinJoin 的体积与费用成本，但同时也强调，CISA 为未来升级带来了显著的工程挑战，且对比特币协议扩展性构成复杂性，因此选择了推迟 [reddit]。

2.3 Schnorr 聚合案例研究：MimbleWimble 协议

虽然比特币引入 Schnorr 签名的时间相对较晚，但一些其他加密货币从一开始就以支持签名聚合的方式使用 Schnorr 签名。其中一个尤其值得关注的协议是 MimbleWimble，它是 grin、beam 等加密货币的底层协议，也作为莱特币（Litecoin）的 MWEB（MimbleWimble Extension Block，MimbleWimble 扩展区块） 功能的基础。

MimbleWimble 通常被称为隐私优先协议，因为它取消了地址的概念、合并交易，并使用机密交易（Confidential Transactions）。该协议设计中的一个关键点是，它以聚合方式使用 Schnorr 签名，从而实现隐私保护与区块空间效率的双重目标。

在 MimbleWimble 中，一笔交易的所有输入和输出会共同生成一个利用 MuSig 协议 的聚合签名，用于证明对输入的所有权，而不会暴露金额或地址。由于该协议会合并中间输出，因此可以对交易数据进行修剪，仅保留最终状态和一组能够验证整个所有权链条的聚合签名。这种设计利用了 Schnorr 签名的线性特性，实现了对所有输入的部分签名进行求和 [mw1][mw2][mw3]。

接下来分别看看这种机制在 grin、beam 和 Litecoin 的 MWEB 中是如何实现的：

1）grin：
grin 是 MimbleWimble 协议的第一个主要实现 [grin]。grin 的交易构建过程要求发送者与接收者协同生成部分签名并进行组合。由于每位参与者都会为其输入和输出选择随机的盲因子（blinding factor），因此交易中最终包含一个 Schnorr 签名，该签名证明所有私钥（即盲因子）之和在椭圆曲线阶数模下等于零。
每笔交易仅包含一个聚合签名，若多个交易的输出相匹配，则可以在区块内进一步合并（称为 cut-through）。grin 通过引入交互式交易构建机制来处理这种复杂性，并仔细验证“输入承诺之和减去输出承诺之和是否为零”，该验证由 Schnorr 聚合签名完成。尽管这种交互性在实际使用中可能不够便捷，但它是该协议隐私性与效率性的核心基础。
2）beam：
beam [beam] 是另一个基于 MimbleWimble 的加密货币，其交易同样通过在每笔交易内聚合签名来实现隐私保护。与 grin 类似，beam 的交易也依赖一个多阶段流程来生成一个涵盖所有输入的 Schnorr 签名。
beam 与 grin 的主要区别在于用户体验以及在隐私性和其他功能方面的额外层次。例如，beam 团队引入了名为 “Bulletproofs+” 的范围证明机制，并将其与聚合 Schnorr 签名集成，旨在降低交易验证的计算开销。
3）MWEB（MimbleWimble Extension Block）：
莱特币在 2022 年引入了 MimbleWimble 扩展区块（MWEB）功能 [mweb]。该扩展区块与莱特币主链并行存在，使用户可以选择性地参与 MimbleWimble 交易。正如 grin 与 beam 一样，MWEB 通过聚合 Schnorr 签名来以保密的方式证明对输入的所有权。
每笔合并多个输入的 MWEB 交易都会使用一个聚合 Schnorr 签名，确保交易既具备隐私保护能力，又提升区块空间利用率。

除了 grin、beam 和 MWEB，也存在一些小型项目使用基于 Schnorr 的聚合或多重签名机制。但上述三种 MimbleWimble 实现依然是目前所知最主要的例子。它们表明，如果整个区块链架构围绕交互式签名构建，Schnorr 签名聚合完全可以成为默认的交易模型的一部分。

这为比特币提供了宝贵的启示：如果能够在交易流程中尽早合并签名，节省空间与提升隐私便能成为常态。然而，MimbleWimble 中的交互性也成为了其普及的障碍之一。此外，MimbleWimble 将所有输入合并为一个聚合签名的方式，属于一种高度定制化的设计，这意味着比特币若要引入跨输入聚合，其路径将必须有所不同，以确保向后兼容性与低交互性。

尽管如此，这些生态中的钱包使用体验为此提供了一个窗口：如果 CISA 最终在比特币中实现，未来比特币钱包的用户体验可能会呈现类似的演进路径。将在后文再次回顾 MimbleWimble 案例研究所带来的启发。

2.4 BLS 签名聚合案例研究：Chia

除了使用 Schnorr 签名进行聚合的加密货币之外，一些其他高知名度项目也使用了不同的签名聚合方案或多签构造。其中一个典型例子就是 Chia。Chia 所采用的密码学假设与设计取舍与比特币中 secp256k1 + Schnorr 的组合有所不同，但在协议层面部署聚合签名的方式及其对矿工、用户等各方的影响方面，Chia 提供了重要的借鉴意义。

Chia [chia] 与比特币的最大区别在于其使用了 BLS（Boneh-Lynn-Shacham）签名方案，该方案依赖于椭圆曲线双线性对（如 BLS12-381）实现。BLS 因其近乎无缝的非交互式聚合能力而广为人知：任何数量的 BLS 签名，即便是针对不同消息，也都可以被组合为一个简短的签名。这是因为 BLS 聚合签名的验证通过双线性对运算来完成，能够验证每个公钥是否确实签署了对应的消息。

Chia 的区块链自始至终就是围绕 BLS 构建的，这使得区块生产者可以将整个区块中所有交易的签名合并为一个聚合签名。

在 Chia 协议中，无论聚合了多少个独立签名，最终聚合签名的大小始终为 96 字节。其主要复杂性在于如何确保每个公钥的合法性。此外，尽管验证一个 BLS 聚合签名在每个签名上的计算成本可能高于单个 Schnorr 签名验证，但在处理大量签名时，整体性能仍可能更优。

对比特币开发者而言，Chia 展示了一个真正落地的跨输入、甚至跨交易的签名聚合的加密货币实现案例。它的最大不同之处在于：BLS 签名依赖于双线性对运算、不同类型的椭圆曲线，以及一套完全不同的密码学假设。

另一方面，BLS 是非交互式的。比特币之所以选择基于 secp256k1 曲线的 Schnorr 签名，是出于对延续性与保守性的考虑。

Chia 在 BLS 聚合上的成功表明，如果整个链的设计都围绕聚合展开，可以带来显著的数据效率提升。但对于比特币来说，直接替换为 BLS 几乎不可能：这不仅因为现有的安全模型与广泛部署的 secp256k1 硬件，还因为社区普遍不愿意引入基于双线性对的新型密码学假设。

因此，比特币目前对 Schnorr 签名聚合的研究，更多是试图在现有曲线与生态系统基础上复制 BLS 的一部分优势，尽管这可能需要在交互性上作出一些权衡。

将在后文再次回顾 Chia 案例研究所带来的启发。

3. CISA 深入探讨

在本章节中，将探讨 CISA（跨输入签名聚合）中可能影响未来比特币软分叉的各个方面。

3.1 前言：在比特币中区分签名聚合与密钥聚合

对于那些希望深入理解 CISA 的人来说，**密钥聚合（Key Aggregation）与签名聚合（Signature Aggregation）**之间的区别一直是一个常见的困惑来源。正因如此，在进入更具体的技术细节前，首先介绍这个区别，以避免读者在阅读本论文时产生误解。

密钥聚合指的是在地址生成时，将多个公钥合并为一个聚合公钥，使得签名者组之后可以共同生成一份 Schnorr 签名。在 MuSig 签名方案中，多个签名者相互交互，以联合签署同一条消息，最终生成一份 Schnorr 签名，该签名可通过聚合后的公钥验证。验证者无需知道个体密钥的存在——这意味着这些密钥不会出现在链上，从而提高了隐私性与交易效率。Taproot 升级引入了 Schnorr 签名，从而支持在单个输入内部进行此类密钥聚合。但它并不支持 CISA。Taproot 下的共识规则并不关心签名是如何生成的；对于每个输入，它只看到一份 Schnorr 签名和一个公钥——因为密钥聚合在签名前就已完成。[bse-keyagg] [blkstr-keyagg]

为了说明这一点，可以举个例子：Alice 和 Bob 使用 MuSig 进行密钥聚合来开设一个闪电网络通道。在设置阶段，Alice 和 Bob 各自拥有一对公钥和私钥，分别记作 (A_pub, A_priv) 与 (B_pub, B_priv)。通过 MuSig，他们可以将各自的公钥合并成一个聚合公钥，称之为 AB_pub。此过程需要他们的闪电节点在线并相互交互，尽管此时还没有任何内容上链。

在通道开启时，他们不是创建一个多签地址来同时使用 A_pub 和 B_pub，而是直接使用聚合后的 AB_pub。这样，从外部看起来就像是只有一个签名者存在。

为通道注资时，Alice 和 Bob 会共同创建一笔交易，将资金发送到对应 AB_pub 的地址。由于从这个地址花费资金需要双方合作，他们必须就交易细节达成一致。当想要关闭通道时，他们分别使用各自的私钥（A_priv 和 B_priv）生成签名，并通过 MuSig 签名过程将这些签名合并为一个，最终得出一份与 AB_pub 对应的 Schnorr 签名。

签名聚合则发生在签名时或签名之后。CISA 特指将多个签名——每个签名分别对应不同的输入、公钥与消息——合并为一份签名。验证这样的聚合签名需要一种新的算法：它接收一组公钥与消息，以及一份聚合签名，然后验证每个公钥是否确实签署了各自的消息。这要求共识层提供额外支持，如一个新的 opcode 或验证规则，能够同时查看多个输入。目前，比特币协议是逐个输入地验证签名的。[bse-keyagg]

现在将 Alice 与 Bob 的密钥聚合例子，与一个签名聚合的例子进行对比：
假设在交易层引入了某种“半聚合”（half-agg）功能，Alice 和 Bob 一同参与了一笔 CoinJoin（合币）交易，与许多其他人一起。在这个场景中，CoinJoin 的构建过程并没有改变，仍然是一个交互式过程，但签名聚合不必参与其中。每个参与者像往常一样独立为自己的输入添加签名。直到 CoinJoin 交易完成后，其协调者才将所有参与者的签名聚合为一个签名，这一步不需要 Alice 和 Bob 的再参与，然后协调者将这笔最终交易广播到网络上。这就是**后签名聚合（post-signing aggregation）**的例子。

需要指出的是，CISA 本身并不会直接提升隐私性，因为所有的输入和对应的公钥依然是可见的，观察者可以判断交易使用了多个输入。实际上，聚合签名甚至可能透露出这些输入是一起签署的这一事实。相比之下，MuSig 式的密钥聚合则可以隐藏是否存在多个签名者。[blkstr-keyagg]

这也是为什么 Taproot 更加专注于密钥聚合，而未纳入签名聚合功能的原因：密钥聚合对隐私性的提升更加直接，也更容易让用户感受到实际影响。

3.2 完全聚合与半聚合

在 Schnorr 签名聚合的广义概念下，比特币交易中的签名聚合可以采用两种主要方式：完全聚合（Full Aggregation）与半聚合（Half Aggregation）。这两种方法的目标都是将多个 Schnorr 签名压缩成更小的整体，但它们在协调要求和最终签名大小方面存在显著差异。

在完全聚合（full-agg）中，所有签名者需要协作地共同生成一份签名，相当于他们对同一内容联合签署。这一过程类似于一个扩展版的 MuSig：多方交换随机数（nonce），并合并输入，最终输出一份64 字节的 Schnorr 签名，无论聚合了多少个签名。这种最大压缩方式可以带来最优的空间节省效果。

但代价是，它需要一个交互式协议，所有参与者在签名过程中需要相互通信。每个签名者必须共享加密承诺，然后合并各自的部分签名。这也意味着他们需要进行多轮通信以生成一个有效的聚合签名。

如果所有签名都来自同一个实体，这种交互就很简单——钱包可以在内部完成所有操作，这种场景中常见的签名安全问题大多也不再适用。但如果签名来自多个独立参与者（如在 CoinJoin 或 PayJoin 中），完全聚合就会带来显著的复杂性。每位参与者都必须同时在线并配合，或者至少能够多次与其他参与者通信；一旦有任意一方拒绝配合或掉线，整个聚合签名就无法完成。

这对协议的安全性和可靠性是一个重要挑战：恶意或不稳定的参与者可能通过拒绝提供签名数据或提交无效片段，破坏整个交易的完成。像 MuSig2 或 ROAST 这样的强健多方签名协议可以缓解这些风险，处理签名者中途退出或行为异常的问题，但它们也引入了更高的复杂性。当前还没有可用的签名协议能支持 full-agg 在比特币中落地，这也是 full-agg 尚无法成为软分叉提案的一部分的重要原因。

相比之下，半聚合（half-agg）则允许在签名各自独立完成之后进行合并，不需要签名者之间的任何交互。每位参与者独立为自己的输入生成一份标准的 Schnorr 签名。之后，一个聚合者（可以是钱包、节点或矿工）将这些签名集合压缩成一份签名，其大小大约是原始签名总大小的一半。

具体而言，一个含 N 个签名的 half-agg 聚合签名大小约为 32*N + 32 字节，而非 64*N [halfagg-bip]。这主要通过拼接所有签名的 r 值，再加上一个聚合后的 s 值实现。

half-agg 的关键特性是：该过程是一个纯函数，它仅依赖于已有的签名、公钥与消息，无需任何额外的秘密数据或交互。 因此，聚合可以在事后由矿工或中间节点完成。

它最大的优势就是：签名者无需协调。参与者像往常一样单独签名，而聚合只是一个可选的优化步骤，完全可以在之后单独执行。这使得 half-agg 在多方场景中更容易部署。如，CoinJoin 用户不需要额外进行交互式签名协作，交易协调者或矿工可以在交易组装完毕后将签名聚合。

此外，还可以组合使用 full-agg 与 half-agg，以降低需要交互的参与方数量。如，一部分输入可能由单个实体或小组控制，这些输入可以通过完全聚合方式先聚合成一个签名；然后，这些结果再通过半聚合方式合并为一个最终签名。

这种混合设计意味着只有小规模组内需要交互，而跨组之间的最终聚合无需交互。因此，可以将 full-agg 保留给适合交互的场景，将 half-agg 用于聚合不同组之间的签名。这样就能将交互限制在可控范围内，同时获得大部分的压缩与效率收益。

3.3 交易级聚合与区块级聚合

在 CISA 的设计中，另一个重要的考量维度是聚合的作用范围：签名应该仅在每笔交易内聚合，还是应该跨整个区块进行聚合，或者两者兼有？这几种选择在安全性权衡和性能影响方面各有不同。

3.3.1 交易级聚合（Transaction-wide Aggregation）

交易级聚合指的是将一笔交易中所有输入的签名聚合为一个签名，或者聚合其中的一部分签名。如，假设一笔交易有 5 个输入，每个输入都需要一个签名，CISA 允许将这些签名合并为一个，涵盖全部 5 个授权验证。

这是 CISA 最直接、最现实的应用场景之一，因为每笔交易保持自包含：它携带一个聚合签名，可以独立验证，不依赖其他交易。

好处包括：

降低交易数据大小，
对于花费者而言可以降低手续费，
对像 CoinJoin 这样的应用尤其有效，如将 100 个输入签名聚合成一个，使协作型花费更加高效。

在安全方面，交易级聚合作用域更有限：聚合失败只影响该交易本身。如果签名无效，或者签名者未能成功生成聚合签名，该交易将无法被转发或打包，但不会影响其他交易或整个区块。这种局部化的失败模式更容易处理：如，钱包可以在聚合失败时回退为常规签名方式。

交易级聚合的潜在压缩空间不如区块级聚合那么高，因为每笔交易至少仍然保留一个签名。如果交易数量很多而每笔交易输入很少（比如只有 1～2 个输入），那么节省效果就不明显。交易级聚合的优势在于每笔交易包含多个输入时更为突出。不过，即使每笔交易只略微压缩一些，积少成多，也能带来可观的总收益。

此外，交易级 CISA 可以在实现上保持范围有限：比如通过引入一个新的见证版本（witness version），表明该交易的所有输入采用聚合签名，仅需在交易的某个部分包含该单一签名，并让每个输入都对此签名作出承诺。验证者只需使用该签名对所有输入公钥进行验证。这确实改变了验证规则，但作用范围仍然局限于交易内部。

需要注意的是，full-agg（完全聚合）只适用于交易级聚合，而无法用于区块级聚合。稍后会进一步说明原因。

3.3.2 区块级聚合（Block-wide Aggregation）

相比之下，区块级聚合是一个更加极端的设想：它意味着将整个区块中所有交易的输入签名聚合为一份签名。理论上，这可以实现一个区块内仅存在一个签名，而这个签名覆盖了上百甚至上千个输入 [bse-keyagg]。由此带来的空间节省非常显著——除了每个区块保留一个签名之外，几乎可以移除所有签名字节。

但与此同时，区块级聚合也带来了更大的安全性权衡与复杂性：

首先，它必须是非交互式聚合，因为每个交易的用户根本不可能事先知道自己的交易会被打包进哪个区块，也无法与区块中其他用户协作；
聚合的责任自然就落在矿工身上。

矿工在收集交易时，最初这些交易仍然带有各自的独立签名，接着矿工再在打包区块前将所有签名合并成一个 [bse-keyagg]。

矿工这样做的激励机制很清晰：聚合签名可以释放区块见证区的空间，从而让矿工能够打包更多的交易，获得更多手续费收入。

不过这也意味着，整个区块的有效性将依赖于这唯一的一份聚合签名。一旦该签名验证失败，整个区块都将作废。在实际操作中，如果矿工在聚合过程中出错，或者某笔交易中包含无效签名，那么最终的聚合签名将无法通过验证，整个区块会被拒绝。

从本质上讲，这与当前规则并无太大不同——现在也是只要区块中有一笔交易的签名无效，整个区块就会被认为无效。但在区块级聚合中，由于只有一个签名，验证者失去了定位具体出错输入的能力，如果没有额外数据，将很难追踪是哪个输入出了问题。

3.4 链下协议 / 点对点网络（P2P）

值得探讨的是，签名聚合是否可以在不改变共识规则的前提下实现，如作为链下协议的一部分，或通过对点对点网络的巧妙利用。即便像 CISA 这样的软分叉提案还需要时间落地，也有可能在某些特定场景下通过签名聚合来提前获得部分收益。

这种带外优化的核心思想是对数据进行压缩以便在网络上传输。为了简化讨论，在此假设这些签名最终并不会上链。在这样的前提下，half-aggregation（半聚合）显然更适合这类用法，因为它是非交互式的，任何人都可以对一组签名进行聚合。

已有研究提出了一个适用于闪电网络（Lightning Network）gossip 协议的用例：在通道公告（channel announcement）中，节点通常需要发送 4 个独立签名，而通过使用半聚合签名，可以将这 4 个签名合并为 1 个 [halfagg-bip]，从而大幅减少 gossip 消息的体积。因为这些签名不会进入区块链，所以网络中的节点可以约定使用聚合的 Schnorr 签名来提高效率，而无需修改 Bitcoin 的共识规则。这样做可以节省带宽资源，是链下聚合的一个成功案例：闪电网络节点只需升级以支持新的消息格式，不需要矿工或链上的任何变更。

除了闪电网络之外，还有一个全新的二层协议提案原生支持半聚合签名：Shielded CSV。这是一个注重隐私保护且具备可扩展性的协议，运行在现有区块链之上，允许用户进行币的交换和验证，而无需将所有交易细节上链。它的运作方式是：只将很小的一段“nullifier”数据广播到区块链上，用于防止双重支付；而实际的交易证明通过点对点方式在链下进行传递，这样不仅节省了区块空间，也提升了隐私性。

在默认设计中，Shielded CSV 中的每个账户都需要在链上提交一份 Schnorr 签名，以使其旧状态作废（nullify）并确认新交易。若输入或参与方较多，所有签名都上链会占用大量空间，从而违背 Shielded CSV 想要实现的“紧凑性”目标。

半聚合正好解决了这个问题：它可以将多个 Schnorr 签名合并为一个压缩后的签名，其大小仅比一份标准签名稍大。最终的链上数据，也被称为聚合 nullifier（aggregate nullifier），包含以下三个部分：

一组 Schnorr 公钥，每个代表一个被作废的账户状态；
一份半聚合签名，整体证明所有参与用户确实签名授权；
一个简短的承诺（commitment），标识是谁发布了这份聚合签名，以便给予其小额费用（由 Shielded CSV 提供）。

由于半聚合可以将多份签名压缩为大约原始大小的一半，即便在大量用户同时更新状态的情况下，链上的数据负担仍然是可控的。从概念上讲，这些签名依然是 Schnorr 签名，只是在其中加入了“签名绑定合约（sign-to-contract）”的技巧，使每个用户在签名时承诺自己对应的新交易数据。接着，由一个协调者或发布者收集这些部分签名，执行半聚合过程，生成一个签名并提交上链。

这种设计确保了每个用户的状态变更都是有效且可验证的，但区块链只需看到一个精简的聚合签名。这种最终压缩的形式使得 Shielded CSV 能够兑现其隐私强、数据开销小的核心承诺。

目前，Shielded CSV 仍处于非常早期的阶段，尚未出现实际实现。但它是一个非常有趣的例子，展示了未来二层协议可能如何在不依赖软分叉的情况下使用签名聚合技术。

4. CISA好处

4.1 空间和费用节省

从根本上说，CISA（聚合签名提案）在节省空间方面可能带来的影响有两种看法，而在比特币区块链上，节省空间就等同于节省交易费用。

第一种方式是以过去为未来的预测：如果用户行为保持与过去一致，我们能够节省多少费用？
& 第二种方式则是假设用户行为不会保持一致，而是在 CISA 推出后发生变化，甚至是剧烈变化。

在费用（以聪计算）和空间（以字节计算）的节省上，你会看到不同的表现。这是由于 SegWit（隔离见证）引入的“折扣”机制。SegWit 把验证交易所需的数据（即“见证数据”）从交易本体中移除，并放入区块的一个分离部分中。

每个输入都有一个见证，通常包括一些脚本，但最关键的是包含了必要的签名。虽然 SegWit 本质上是为了解决交易malleability易变性问题（不同的见证可以对应同一笔交易），但见证折扣的存在旨在激励 SegWit 的采用，并让花费输出的成本更低，从而减缓 UTXO 集合的膨胀。见证数据的费用折扣为 75%，而由于CISA正在聚合签名，节省下来的空间全都集中在见证部分，所以与之对应的费用节省就相对温和一些。

4.1.1 外推节省模型

外推模型假设 CISA 推出后比特币网络的使用方式不会发生根本变化。这意味着可以使用过去交易的平均结构和大小来计算用户采用 CISA 后可以节省的成本。Jonas Nick 编写了一个 Python 脚本作为这项计算的基础 [jonas-savings]，此脚本内容已被稍作修改和更新 [jonas-script]。

脚本使用的是平均每笔交易的输入和输出数量。使用的是去年（区块高度 833,000 至 886,000）得出的平均值，另一脚本得出的结果是：每笔交易平均输入数为 2.12，输出数为 2.64。
在这些条件下，若使用半聚合（half-agg），每笔交易平均可节省 6.9% 的交易费用和 19.3% 的空间。若使用全聚合（full-agg），费用节省将增至 7.3%，空间节省则为 20.5%。

这些数字可能看起来不那么惊人，特别是半聚合与全聚合之间的节省差距较小，可能会让一些读者感到失望。然而请记住，这些是历史平均值，在数值上本身就不大。而对 CISA 的乐观预期包含网络行为会发生变化的假设，而这将在下一个模型中考虑。

4.1.2 颠覆性节省模型

颠覆性模型则假设 CISA 的引入将根本改变大多数用户与比特币的互动方式，也会改变人们在链上看到的交易类型。特别是该模型认为，在 CISA 实施后，更大型的 CoinJoin 和 PayJoin 交易将变得更加经济可行。

撰写本文时，CoinJoin 交易数量极少，主要是因为近期对最受欢迎的 CoinJoin 实现方案进行了打击 [rip-wasabi][rip-samourai]。因此，若以现阶段的区块数据来预测未来 CoinJoin 的使用情况，并不合理。相反，将查看 CoinJoin 在流行时期的表现，并在乐观情景下评估其未来可能的广泛应用，特别是由 CISA 激活所触发的情况。

在此将重点研究 WabiSabi 风格的 CoinJoin，因为它倾向于使用更多的输入和输出，因此更能从 CISA 中获益。

首先来看一笔类似 WabiSabi 历史平均的 CoinJoin 交易。此类交易平均包含 76 个输入和 121 个输出 [cjadopt]。假设每个输入对应一个参与者，所需手续费率为 10 聪/vbyte。
在这些假设下，该 CoinJoin 交易将需支付 95,835 聪的交易费，交易大小为 13,347 字节。若使用 CISA 半聚合签名，则需支付 89,653 聪（大小为 2,432 字节），节省 6,078 聪，费用减少 6.35%（空间减少 18.2%）。
若使用 CISA 全聚合，则费用为 83,573 聪，节省 12,157 聪（4,863 字节），费用节省 12.7%，空间节省 36.4%。

这些数字在整体网络影响较温和的背景下，仍属可观。在更乐观的情景下，CoinJoin 的使用频率甚至可能超过之前的水平。WabiSabi 风格的 CoinJoin 一般以 100 个输入为目标，这是该交互式协议的自然限制。
在这种情况下，假设有 150 个输出，100 个参与者，每人一个输入，手续费率仍为 10 聪/vbyte。当前该交易需支付 122,105 聪费用，若采用 CISA 半聚合，则费用为 114,002 聪，节省 7,999 聪（6.6%）。采用全聚合时，费用降至 106,002 聪，节省 15,998 聪（13.1%）。

如上所述，这种大型 CoinJoin 属于 WabiSabi 风格。而另一个流行的 CoinJoin 实现 Whirlpool（由 Samourai 推出）则采用一系列较小的交易，每笔交易包含 5 个输入和 5 个输出。
作为对比，这类交易在使用 CISA 半聚合时可节省 7.6% 的费用和 20.2% 的空间；使用全聚合时则可节省 15.2% 的费用和 40.3% 的空间。
这些数字可能比前面提到的大型 CoinJoin 更高，令人意外。原因在于 Whirlpool 使用了输入输出数量相等的模型，而 WabiSabi 风格则假设输出多于输入。

当然，CISA 的激励机制可能促使 CoinJoin 的规模进一步扩大，但正如之前提到的，交互性约束可能会限制规模的上限。在 CISA 采用最乐观的情况下，更有可能是由多笔上述规模的 CoinJoin 填满一个区块。

4.1.3 合并交易（Consolidation Transaction）

对于处理大量 UTXO 的企业，比如电商平台或交易所，CISA 非常有吸引力，因为它可以显著降低合并交易的成本。这类交易并不会像 CoinJoin 那样受到交互性限制的影响，因为所有被聚合的 UTXO 都由同一个实体控制，避免了交互需求。

理论上，一个区块可以被一个包含成千上万个输入的聚合交易完全填满。但在实践中，企业通常会保持合并交易在适度规模，以确保能以具竞争力的费用率参与手续费市场，并通过多个即将打包的区块逐步完成交易。例如，加密货币交易所 OKX 曾因一次错误操作而被广泛关注——他们在一系列合并交易中出现了“自我竞价”的 bug，可能至今仍令一些读者记忆犹新【okx】。这些合并交易中每笔使用了 150 个输入，就以此为例进行节省情况说明，假设手续费率为 10 sat/vbyte。

这样的交易（150 个输入，1 个输出）目前需支付 86,785 sats 的手续费。若使用半聚合（half-agg），手续费可降至 74,865 sats，节省 13.7%；使用完全聚合（full-agg）时，总费用进一步降至 62,945 sats，节省幅度达 27.4%。

另一类可能受益于 CISA 的交易是批量支付（batched payouts）。然而，批量支付仅在包含多个输入时才可享受节省，这等同于合并交易。因此在此未提供这类交易的节省数据。实际上，一个管理良好的交易所更可能在手续费较低时尽可能先合并 UTXO，这样后续的批量支付交易就只有极少数甚至只有一个输入，也就几乎没有节省空间。

4.1.4 区块级半聚合（Block-wide half-agg）

为了估算如果引入区块级半聚合（block-wide half-agg）到比特币后能节省多少空间，可以参考过去一年每个区块中的平均签名数量。

从撰写本文之时起的一年中，每个区块平均包含 5,941 个签名，占用了大约 380 KB 的空间。若将来这些签名都能聚合成 Schnorr 签名，将可节省约 190 KB 的区块空间。腾出的空间可用于容纳更多交易，从而略微提高每个区块的手续费收入，同时提升比特币区块链的吞吐量。

4.2 隐私（Privacy）

通过将多个输入签名合并为一个签名，CISA 为比特币的隐私相关使用场景带来了诸多好处。它可以显著推动 CoinJoin 和 PayJoin 的使用，特别是在经济激励方面使这些隐私增强技术对用户更具吸引力。

在 CoinJoin 的场景中，多个参与者合并输入以混淆资金的来源与去向，这样的做法本质上追求隐私保护。在没有 CISA 的情况下，每个参与者都必须为自己的输入添加独立的签名，导致交易体积增大、消耗更多区块空间并带来更高手续费。而在引入 CISA 后，所有签名可以合并成一个，显著减少交易总体体积。这种体积上的减少直接转换为更低的手续费，惠及交易中所有参与者。

这一节省成本的机制对 CoinJoin 用户尤其有吸引力，因为原本较高的费用常使人望而却步。CISA 减轻了费用负担，降低了参与 CoinJoin 的门槛，从而可能提升其采用率。而随着更多人参与 CoinJoin，其匿名集（anonymity set）扩大，每个用户的隐私保护程度也随之提升，因为外部观察者更难追踪具体的交易路径。

PayJoin 也可从中受益。PayJoin 通常涉及两方合作创建交易，各自提供一个输入。在无 CISA 的情况下，双方都需提供独立签名，导致交易体积和费用上升。而使用 CISA 后，这些签名同样可以合并，降低交易体积和费用。

除了直接的节省，CISA 还间接通过推动 CoinJoin 和 PayJoin 的常态化来促进比特币基础层的隐私提升。上述节省数据表明，使用带有 CISA 的 CoinJoin 不仅比不带 CISA 的便宜，甚至比用户各自发送普通交易还要便宜。这种低成本和高可用性，可能吸引那些出于经济考虑的用户加入使用，从而扩大采用范围。更广泛的采用会形成网络效应，使隐私增强行为成为常态，进而削弱监控和分析的有效性。

这些隐私技术被更广泛使用后，对手方就更难通过区块链分析得出准确结论。更多的采用也可能推动更好的工具和用户体验的诞生，形成一个“飞轮效应”。

此外，CISA 还有潜力削弱**共同输入所有权启发式（common-input ownership heuristic）**的分析手段。该启发式通常用于分析交易中是否为同一实体操作多个输入。而通过 CISA 提供的经济激励促成更多多人参与的交易，分析者就更难判断一个交易到底是多个用户参与，还是一个用户在操作多个 UTXO，从而进一步提升了隐私性。

4.3 计算效率（Computational Efficiency）

尽管 CISA 通常被讨论的是手续费或空间优化方面的优势，但它在计算效率上同样带来了显著提升，因为它减少了节点需要执行的离散签名验证数量。

在常规情况下，验证一笔包含 n 个输入的交易通常需要执行 n 次独立的 Schnorr 或 ECDSA 签名验证【core-blog】。每次验证都涉及椭圆曲线运算，尽管已有优化，但这仍是节点验证时间中的重要部分。CISA 在交易被打包入区块前就将这 n 个签名聚合成一个，因此节点在首次接收该交易时只需执行一次签名验证。这样一来，当区块中包含许多多输入交易时，节点整体的签名验证数量大幅减少，带来实际的性能加速。

需要注意的是，将多个签名交由聚合算法处理的操作仅适用于 完全聚合（full-agg）。在 半聚合（half-agg） 中，聚合签名实质上会被“解压”成原始数量的签名，这些签名仍需逐个验证，因此 half-agg 不具备计算效率上的优势。

此外，即使仅使用 Schnorr 签名 也可以启用 批量验证（batch validation），即节点通过共享的椭圆曲线操作并行验证多个签名【elem】。节点可以将区块中所有聚合签名排队，执行几次群组运算后一次性完成多个签名的验证【halfagg-paper】。相关的研究和开发已经在进行中，并且这项技术可以在 不需要软分叉的前提下 应用于比特币【batch-pr】。

这并不意味着引入 full-agg CISA 不会带来额外的效率提升。区别在于，full-agg 的聚合是在签名时完成的，而批量验证则是在 验证时进行签名合并。这意味着即便在部署了批量验证的情况下，使用 full-agg 仍可带来一定程度的额外效率收益。

4.4 带宽（Bandwidth）

在上一章节中提到的 CISA 在闪电网络（Lightning Network）P2P 层的使用，确实可以节省数据传输空间，但这种节省仅限于带宽，并不影响链上空间或手续费开支。

5. 挑战（Challenges）

尽管前面提到了 CISA 的诸多令人振奋的好处，但这个概念在社区中并未获得大量关注和开发支持。造成这种情况的主要原因，可能就是 CISA 本身所带来的挑战性。下面将逐一深入探讨这些挑战。

5.1 交互性（Interactivity）

全聚合（full-agg）跨输入签名聚合面临的关键难点在于它需要所有签名参与者之间进行交互式签名协议。这与普通交易不同，普通交易中每个输入的签名都可以相对独立地完成，而 full-agg 则要求所有签名者协同生成一个联合签名。

这意味着所有参与方都必须在签名过程中在线并进行数据交换。这增加了复杂性：需要多轮通信、协调协议，如果有任意一个参与者掉线或出错，整个签名过程可能失败。full-agg 在单人控制所有输入的场景下运行良好，比如一个用户消费自己所有的 UTXO，因为该用户可以独立完成聚合签名。

然而，在 CoinJoin 或 PayJoin 这类多方交易中，实时协调所有参与者极具挑战性。这种交互性的要求，是 CISA 实施和用户体验上的主要障碍。为了避免误解，half-agg 不存在这个问题，它支持无需交互的签名聚合。

应对交互性的主要策略，是开发一个健壮的签名协议，就像 MuSig2 和 FROST 之于密钥聚合所扮演的角色。如果在考虑为 full-agg CISA 进行软分叉之前尚未开发出此类协议，那就必须视为一个严重的阻碍。缺乏这样的协议，会让外界更容易推测出所有被聚合的输入由同一个实体拥有，这在隐私性方面是个重大问题，前文已对此进行详细论述。

与此同时，也可能有人尝试自行设计签名方案并在缺乏同行评审的情况下发布，这样会严重威胁用户资金安全。

交互性是很多协议的绊脚石【inter】。在前文也提到过，MimbleWimble 协议从设计上就依赖交互式结构，即便是最流行的实现版本也面临采用困难，一些早期支持者将其归咎于交互性要求。幸运的是，比特币协议永远不会强制所有交易使用 CISA，用户始终可以选择不使用它，从而绕过交互性的问题。

5.2 隐私性

本报告前面已经提到，CISA 本身并不是隐私保护的“灵丹妙药”。实际上，CISA 并不直接改善链上的匿名性，它的目标仅仅是通过压缩签名来提升效率。

任何隐私方面的收益都将是间接的，如由于手续费降低而使 CoinJoin 更加便宜——而这并不属于协议变更本身的范围。聚焦于潜在的不利因素，发现 CISA 在某些方面实际上可能会使隐私问题变得更复杂。

通过减少交易中可见的签名数量，CISA 可能初期会迷惑一些链上分析的启发式方法。然而，分析人员将很快适应，并针对聚合签名开发出新的启发式分析手段。事实上，尤其是“共同输入启发式”在 full-agg 初期被采用时可能变得更加强烈：因为 full-agg 需要协调，一个成功使用聚合签名的交易很可能是由一个实体控制所有输入而生成的。链上监控公司已经默认所有输入由同一人拥有，除非存在明显的 CoinJoin 模式；而 CISA 中的聚合签名可能强化这一假设，因为它意味着这些输入是在一次协调的签名中完成的。为防止这一点，必须提前准备好一个健壮的签名方案，使得像 PayJoin 和 CoinJoin 这样的协作交易可以在 CISA 部署后迅速采用它。只有这样，multi-user full-agg 才能快速传播，从而防止链上分析将所有 full-agg 多输入交易标记为单一用户行为。

聚合签名还可能引入一些微妙的“指纹”，这些指纹可能被监控系统所利用。分析师可以开发启发式方法来检测某交易是否使用了 CISA，并相应地进行标记。如果 CISA 初期使用量稀少，这些交易将非常显眼，而如果仅有少数钱包支持 CISA，则这类交易更容易被归因到特定钱包软件上。

CISA 与其他隐私技术的交互也需要仔细考虑。许多高级隐私协议使用 scriptless scripts 或适配器签名（adaptor signatures）——如，原子互换（atomic swaps）和币互换（coin swaps）依赖于从签名中提取秘密。尽管这也是一个隐私问题，但它将在下一节中单独讨论。

5.3 适配器签名不兼容性

跨输入签名聚合（CISA）与适配器签名不兼容，而后者被用于诸如 Lightning 网络中的 PTLCs、基于 scriptless script 的原子交换、以及 Discreet Log Contracts 等协议。在这些协议中，链上的签名可以通过与适配器签名对比来揭示隐藏的秘密。如果所有输入或整个区块共用一个聚合签名，就无法让这个单一签名向多个不同的参与者揭示独立的秘密。简而言之，经过调整的个别签名不会出现在链上，无法用于秘密提取，因此依赖适配器签名的方案在 CISA 下将无法运行。

与所有隐私保护功能一样，目前很难判断适配器签名的实际采用程度。因此，为评估 CISA 的引入将对现有使用适配器签名的应用场景造成多大影响，还需进一步研究。然而，从中长期来看，Lightning 网络中 PTLCs 的采用似乎是确定的。虽然这本身可能并不构成严重问题，因为非协作式关闭本来就容易识别，但这仍然不是一个理想的前景。

5.4 区块重组挑战

区块级签名聚合在发生链重组（reorg）时会引入一些新的挑战。如果某个区块被重组，其中覆盖所有交易的聚合签名很可能不再有效。只要新区块中交易稍有不同，原本的聚合签名就会失效。即使新旧区块中的大部分交易一致，新的聚合签名也会不同。因此，节点必须重新从头验证新区块的聚合签名。

目前的普通交易中，每个输入的签名都可以独立验证。Bitcoin Core 会缓存验证结果，因此某个交易如果从被孤立的区块转移到新的区块中，节点在识别到它时不需要完全重新验证。但若使用区块级别的聚合签名，这种基于输入的缓存机制将无法发挥作用；“整个 half-agg 签名 S2 都必须被重新验证，包括此前已验证的 X 的部分 […] 这与普通签名不同，普通签名在重组中不需要重新验证。”换句话说，区块级聚合削弱了缓存或部分验证的好处，可能使区块在链重组后的验证效率降低。

另一个潜在问题是，在重组中被移除的交易将如何处理。假设交易 X 被包含在区块 A 中，并作为聚合签名的一部分，但 A 区块被孤立，而 X 没有被纳入新的区块 B。正常情况下，节点会将 X 返回到内存池或重新广播，因为它仍然拥有完整签名的交易。毕竟 A 区块的数据中包含了全部签名。但在区块聚合签名下，X 的个别签名从未出现在链上——它已经被吸收到区块 A 的聚合签名中。一旦 A 区块被孤立，节点无法从聚合签名中提取 X 的原始签名。除非节点此前就缓存了 X，否则它就从节点视角中“消失”了，因为现在它变成了一个无效的交易。即便节点曾经验证过 X，它看到的也只是聚合签名而非 X 的 s 值。因此，节点无法自动将 X 放回内存池或重新广播。这会带来安全性和可靠性风险：用户可能以为 X 已确认并离线，但一场链重组却使其被丢弃。若没有特别的处理方式，X 的输入资金仍可再次花费，但该交易本身可能“丢失”，直到用户或某种“守望塔”将其重新发送。归根结底，区块级聚合破坏了目前比特币协议中“一个有效交易一旦被看到，就可以在重组后重新挖出”的保证。

开发者已提出一些缓解方法来解决这些问题。其中一个方案是：即便交易已被包含在区块中，节点仍保存每个交易的原始签名数据，而不仅仅是区块的聚合签名。节点可以在区块被确认足够深、重组几率极低后，再清除这些签名缓存。在重组发生时，这种方式有两个好处：（1）如果交易仍出现在新块中，节点可以从缓存中“减去”原来的签名部分，避免重复验证；（2）如果交易被移除，节点仍然拥有完整签名的 X，可将其返回内存池或重新广播。这种缓存策略在消耗少量内存/存储空间的同时保留了比特币现有的鲁棒性。

另一个缓解方式是：在钱包层处理重组，即让交易发送者或第三方在重组后重新广播 X。但依赖用户手动重发是一个较弱的解决方案，因为这带来隐私风险，并假设用户始终在线并监控区块链。

本报告早前提及 Chia 网络使用了 BLS 签名进行区块级聚合，可能是一个解决此类问题的理想案例研究。然而，在研究后发现，Chia 目前尚未在协议层解决这些问题。相反，如果用户希望确保交易被挖出，他们需要由客户端重新提交交易。尽管如此，由于 Chia 开发速度快，仍值得持续关注其是否会提出 Bitcoin 可以借鉴的解决方案。

5.5 采用缓慢

历史已经表明，像 CISA 这样规模的新比特币特性通常会缓慢地被采用们可以预期，CISA 的采用路径将类似于之前如 SegWit 和 Taproot 等软分叉升级的过程。

以 2017 年的 SegWit 为例，尽管它提供了交易费用节省及其他好处，但并未立即在网络中占据主导地位。SegWit 的采用花了数年时间才达到大多数交易的水平。事实上，在 SegWit 激活约两年后，只有大约 50% 的交易使用了 SegWit，而用了四年才达到大约 80% 的采用率。这种缓慢的推广主要是因为钱包和服务需要时间进行升级，同时用户可以根据自己的节奏选择是否采用【chainalysis-taproot】。

2021 年底激活的 Taproot，其采用过程也同样缓慢；即便节点运营商广泛支持，实际交易中对其的使用增长依旧缓慢，因为钱包软件需要时间来添加支持。CISA 的采用很可能也会是循序渐进的。新版本的 SegWit v2 输出类型需要钱包、硬件设备、交易所、区块浏览器等生态系统组件的支持。这需要大量的开发工作和测试，不可能一蹴而就。许多钱包可能不会在一开始就优先支持 CISA，除非他们观察到明显的市场需求，尤其是对于普通用户来说，CISA 所带来的直接收益可能并不明显，毕竟他们还未参与复杂的交易。可以说，这形成了一个“先有鸡还是先有蛋”的问题。有些软件如果不再维护，可能永远不会更新，这意味着某些用户只能继续使用旧格式，除非他们更换钱包。所有这些因素导致，即使共识升级完成，CISA 要实现广泛普及和完全发挥潜力，可能仍需很长时间。

在此将 CISA 与 SegWit 和 Taproot 进行比较。SegWit 有一个明显的痛点优势：解决交易可变性和提升区块容量，但即便如此，也花了数年才变得主流。Taproot 的优势在于多签名隐私和脚本灵活性，但这些对大多数用户来说并不立即相关，因此其采用更慢、更逐步。CISA 的优势主要体现在可扩展性/手续费节省，其次是使 CoinJoin 等隐私技术更便宜。这意味着 CISA 的采用路径可能介于两者之间：如果手续费压力增大，CISA 的推广可能比 Taproot 更快；但如果用户兴趣不高，其采用速度可能更慢。

一个乐观的设想是：由于 CISA 可在地址合并等场景中节省成本，交易所可能会迅速采用它，并生成大量 CISA 交易，从而提升其可见性并带动推广。一个悲观的情境是：仅有少部分高级用户采用 CISA，而大多数钱包选择忽略它，最终导致长期处于低采用状态。无论如何，这一过渡期都需要被妥善管理。像 Bitcoin Optech 这样的协调机构可能会再次发挥作用，通过追踪 CISA 的采用数据，鼓励服务提供商实现支持，就如他们在 Taproot 推广中的做法那样【optech】。

6. CISA 选项的可行性

本节尝试概述不同 CISA 选项组合的可行性，并评估哪些组合在未来有望成为软分叉提案的候选项。

6.1 有共识更改的情况

首先，简要回顾一下所探讨的选项：

半聚合（Half-Agg）：一种非交互式方案，任何人（包括第三方）都可以将多个 Schnorr 签名合并为一个聚合签名，其大小约为原始签名总和的一半。
优点：不需要签名者在签名时进行协调 —— 参与者可以照常签名，然后由聚合者在之后压缩这些签名。这种简化也意味着实现的复杂性相对较低。
缺点：聚合后的签名仍然比单个签名大，因此与完全聚合相比，节省空间有限。
全聚合（Full-Agg）：一种交互式协议，多个签名者协作生成一个 Schnorr 签名，其大小固定为 64 字节，无论涉及多少个输入/密钥。
优点：节省空间最大。如，10 个输入只需一个 64 字节的签名，而不是十个64 字节的签名，极大提升可扩展性。签名更少也意味着验证操作更少，可能提升全节点验证速度。
缺点：需要复杂协调。签名者必须多轮交换数据才能生成联合签名，并且要在各轮之间安全地管理随机数/状态。这增加了协议复杂性和出错的可能性。在多方签名场景中，通常意味着所有参与者需要同时在线并参与互动，实操上有一定障碍。

综合来看，半聚合比全聚合更可能在当前阶段被引入到比特币中。不过值得注意的是，全聚合的问题主要在于研究和实现层面，被认为是可以解决的技术难题。

其他选项还包括：

交易级聚合（Transaction-wide Aggregation）：将一笔交易中所有输入的签名聚合成一个签名，取代每个输入携带单独签名。可以通过全聚合或半聚合实现。这将减少多输入交易的大小和费用，特别适用于合并交易（consolidation）或大量输入的 CoinJoin。将 10 个签名减少到 1 个，显著节省空间，使得单笔交易中多方协作比多笔独立交易更划算。
区块级聚合（Block-wide Aggregation）：更激进的做法，将整个区块中的签名合并为一个理论上的超级签名，假设所有签名都符合聚合条件。这会带来最大空间节省和最少验证成本。但也伴随着诸多潜在问题，尤其是链重组效率等方面。

综上权衡，交易级半聚合（tx-wide half-agg）目前是最有可能实施的方案，因为它的问题较少、实现复杂性也较低。相对而言，区块级全聚合（block-wide full-agg）目前几乎可以被视为不可能，因为要实现它，不仅所有交易的参与者必须协同，还涉及到矿工在打包区块前并不知道哪些交易会被包含的问题。这需要对交易传播、内存池和挖矿流程进行彻底重构，而这种变革几乎不可能发生。

本节中最有趣的问题可能是：区块级半聚合是否比交易级全聚合更有吸引力？
目前社区对此没有明确共识，但作者认为协议层面上的交易级全聚合复杂性更可控，且带来的副作用风险更低。此外，CISA 支持者往往希望能在软分叉时获得其全部潜力。如果全聚合仍需要更多研究才能可行，那么社区很可能选择等待这些研究完成后再推动软分叉。

最后，还应考虑这些不同选项之间的互动。如前文节省分析所述，CISA 的潜力来自于它可能改变人们在链上的协作方式，催生更多大型协作交易。如果这种趋势成真，交易级全聚合将显著减少区块中的签名数量。在这种情况下，即便之后引入区块级半聚合，其增益可能也不如在 pre-CISA 环境下那么明显。

6.2 无共识更改的情况

即使不改变比特币主链规则，在链下协议和合作机制中，也能实现部分签名聚合带来的好处。虽然 CISA 当前无法在链上直接实现，但在二层网络和点对点场景中，通过创造性的技术可以模拟其效果，或在类似方面提高效率：

例如，闪电网络（Lightning Network）的消息层也可以利用签名聚合。LN 节点向网络发布通道公告时，会发送一个包含四个签名的消息。每个节点会用自己的节点密钥和比特币密钥分别签署，以验证身份。这些通道公告虽然不上链，但需要在整个网络中传播，因此对带宽消耗较大。

开发者指出，由于这些签名都是由通道双方生成的，可以使用聚合技术进行压缩【thoughts】。如，两个节点签名可以合并成一个，甚至比特币密钥的签名也可能被聚合。实际上，由于创建通道公告本身就需要两个节点之间的协调，它们可以通过交互式协议将所有签名合并成一个签名【thoughts】。这样，通道公告的大小将显著缩小。

这就是在点对点场景下使用 CISA 来节省带宽和提升效率的实例，而无需改变区块链规则。虽然从技术上来说可行，但闪电网络开发者有许多优先级更高的任务（如路由可靠性、流动性管理、安全性等），因此利用签名聚合优化 gossip 协议可能并不是当务之急。但无疑这是 Schnorr 签名带来的明确利好：链下信息同样可以像链上交易一样被聚合。未来或许会看到 LN 协议在更新中采用这些思路，以减少网络流量。

7. 应用场景

在 CISA（Cross-Input Signature Aggregation）上线后的比特币网络中，将为所有用户带来许多令人兴奋的机遇。本节将介绍其中最具前景的一些应用想法。

7.1 从商业角度看 CISA 的采用

CISA 承诺通过减少签名数据来降低比特币业务的交易费用。从这个角度来看，不同行业的参与者可根据其主要盈利动机获得各自的好处。

7.1.1 交易所（Exchanges）

高频交易所每天处理成千上万的充值和提现操作，通常会产生大量 UTXO（未花费交易输出），这些 UTXO 最终需要进行合并，以避免在高手续费环境下花费时成本过高。CISA 将使得 UTXO 的合并变得更加经济高效。

目前，交易所可能会延迟合并低价值的 UTXO，因为逐个花费它们所需的手续费超过其本身的价值。而通过跨输入签名聚合（CISA），即使仅价值几百聪的 UTXO 也可以经济地聚合处理【trezor】。如，一个交易所可以将 100 个小额输入合并为一个输出，仅需支付一个签名的费用，而不是 100 个，从而大幅减少合并交易的大小。相关的节省示例可参考前文的“节省效益”部分。

这不仅能为企业节省手续费，也能净化 UTXO 集合，减少输出数量，利于整个网络的健康。实际上，CISA 提高了所谓“尘埃合并（dust consolidation）”的经济可行性，使得最小可经济花费的 UTXO 阈值下降。
那些早期采用了 SegWit 和交易打包技术的交易所已从中受益【segwit-batching】，而 CISA 将带来类似优势。

因此，交易所很可能会鼓励用户使用兼容 CISA 的钱包进行充值/提现，就像当年推广 SegWit 的 bech32 地址以降低自己和用户的提现费用一样。

7.1.2 电商 / 支付处理商（Ecommerce / Payment Processors）**

对于电商公司以及为电商提供服务的支付处理商，其需求场景与交易所非常相似。电商企业每完成一笔链上比特币支付就会收到一个新的 UTXO，因此频繁的 UTXO 合并操作是必要的。

此外，对于技术能力较强的电商企业来说，一旦 CISA 部署上线，也可能有兴趣尝试采用 PayJoin 模式，进一步提升交易隐私性和费用效率。

7.1.3 钱包服务商（Wallet Providers）

钱包软件，尤其是托管型或企业级钱包，通常管理大量 UTXO，因此可以通过 CISA 来优化交易结构。如，一个需要使用多个输入的支付操作在 CISA 加持下将占用更少的区块空间。

对于个人用户来说，当他们支付的金额超过单个 UTXO 时，也会涉及多个输入 —— CISA 可以间接帮助他们节省手续费【trezor】。
钱包服务商采纳 CISA 后，可为用户提供更低的交易费用，这也是一个明显的竞争优势。

部分钱包已支持 CoinJoin 功能，在 CISA 的帮助下，它们可以以更小的权重成本整合用户支付或合并多个 UTXO，使得这些隐私功能变得更易于常规使用。

这有望进一步推动 CoinJoin 和 PayJoin 的普及，特别是在那些注重用户体验、降低使用门槛的钱包中，从而提升整个网络的隐私性，这一点在前面的“隐私效益”部分已有阐述。

7.1.4 矿工（Miners）

比特币挖矿作为一种既有的商业模式，也将受到 CISA 引入的显著影响。
但由于矿工的行为和激励机制对整个网络有广泛影响，因此关于矿工的激励机制及其网络层面的效应将在下一节单独展开讨论。

7.1.5 电子现金铸造厂（Ecash Mints）

Ecash Mints 实质上是带有更好隐私保障的托管钱包，因此它们可以享受到与交易所和托管钱包相同的 CISA 效益，如交易费用更低、UTXO 管理更高效、交易打包更紧凑等。

7.1.6 潜在的新商业模式

除了改进现有业务流程外，CISA（跨输入签名聚合）还为比特币生态系统开启了全新的商业模式和服务的可能性。通过启用多个独立方在一个交易中协作，并使用“完全签名聚合（full-agg）”实现仅需一个签名，CISA 为促进这类协作的企业创造了机会。以下是一些潜在的新模式及其运作方式：

一个显而易见的新服务是由 CISA 驱动的省手续费协调器。
- 该服务允许用户在发起比特币交易前加入一个交互式交易池，而不是立即发送个人交易。协调器将多个用户的待处理交易收集起来，并使用 CISA 聚合成一个大型交易。由于所有输入只需要一个签名，整体手续费比用户分别发送交易低得多。每个参与者只需支付原本个人交易手续费的一小部分。这些分摊手续费的支付可通过闪电网络（Lightning Network）结算。
- 这种模型可以被看作是对“交易批处理（batching）”概念的扩展，但适用于彼此之间并不信任的用户。
- 本质上，它类似于当今的 CoinJoin 实现，但其卖点转向了手续费节省而不是隐私保护。
- 其价值主张十分明确：用户交易成本更低，协调器通过收取小额服务费获利。
- 这类服务对散户钱包用户、定期发放款项的商家，甚至希望合并提现的交易所都具有吸引力。
- 如果该服务以非托管形式结构化（即服务商不持有资金），则可能规避严格监管，更像是“交易中介”而非“资金保管者”。
  从而，这类“手续费池”或“聚合代理”可能在比特币经济中成为一个新兴利基，尤其在交易手续费高昂时期，节省需求最为旺盛时。

CISA 还可能为现有的 CoinJoin 商业模式提供强大助力 —— 尽管目前这类市场看起来相对低迷，但它很可能会激发新的参与者加入市场。

当前，CoinJoin 通常会带来手续费的增加 —— 因为混币过程中需添加额外的输入/输出，对追求隐私的用户来说这是可接受的代价，但对一些用户来说仍具有一定劝退作用。而借助 CISA 的跨输入聚合，含有多个输入的 CoinJoin 将变得更加经济，甚至可能比普通的单独支出更便宜【trezor】。

有分析指出，在 CISA 的加持下，CoinJoin 交易可能略微比普通交易还要省钱【trezor】。这就颠覆了原有的逻辑：隐私不仅不再额外收费，反而可能帮你省钱。

这催生了一个新的商业模式：低手续费甚至免费 CoinJoin 即服务（CoinJoin-as-a-Service）。服务商可以运行定期的、庞大的、基于 CISA 的 CoinJoin 池，任何人都可以加入，以获得匿名性和低手续费的双重好处。随着隐私功能被手续费节省所“补贴”，这些 CoinJoin 池的匿名集可能会迅速扩大，从而大幅提高混币的有效性。

举例来说，目前最大的 CoinJoin 池之一 —— Samourai 的 Whirlpool —— 在某一时间内持有大约 4350 BTC 的流动性【trezor】。如果交易成本降低，可以想象池子会更大，混币操作也会更频繁。

已经提供混币服务的企业可能会选择降低服务费，或者通过从手续费节省中抽成来实现新的盈利模式，而不是直接向用户收费。

与此同时，交易所和钱包服务商可以无额外成本地集成隐私池，这有望将隐私交易常态化。
此类交互式交易池将同时服务于隐私保护和费用优化。围绕这一点的企业，不论是以盈利为目的还是作为产品附加值，都有望涌现。

未来，甚至可能看到合作模式的出现 —— 如交易所与 CoinJoin 提供商合作，将众多用户的提现交易聚合为一个大额、私密、低费的交易。这种方案在合规方面需要特别小心处理，但技术上，它完全可以实现：让用户只需点击一次，即可获得“隐私提现”服务，且该操作对交易所来说反而比单独发送还便宜。

总的来看，CISA 有望使隐私驱动的商业模式变得更具财务可行性，并吸引更广泛的用户群体。

值得注意的是，虽然上文中提到的新商业模式很有可能出现，但最可能的情况是：这些功能将被现有钱包服务商添加为新特性，或者被新兴钱包提供商用作差异化卖点。

7.2 从用户视角看 CISA 的采用

为了实现 full-agg CISA 的好处，用户必须实时与他人协同发起交易。完全签名聚合是交互式的，要求参与者在签名过程中交换数据。这种协调在钱包中实现起来在技术上颇具挑战，如果没有无缝自动化，可能会让用户感到不便。为用户提供一个流畅的体验，帮助其寻找交易伙伴、处理通讯，以及应对失败（如某个参与者中途退出）是一个不小的难题，对于主流采用来说至关重要。

当多个独立用户在一笔交易中协作时，会出现新的信任问题。如果使用的是中心化的批处理服务或协调器，用户必须信任该服务不会泄露输入和输出之间的关联信息，或恶意中止流程。即使在去中心化的协调中，每位参与者也必须信任其他人会如约签名；一个不诚实或离线的参与者就可能阻碍整笔交易。虽然没有人能单方面盗取资金，但这种池化模型可能引入服务拒绝（DoS）攻击风险，恶意行为者可以反复破坏 CoinJoin 交易尝试。用户和企业也可能担心与“染色”币的用户一同交易，可能引发合规方面的顾虑。需要健壮的协议来缓解这些风险并建立对聚合交易的信任。

CISA 的效益随着普及率而增长。在初期，只有部分钱包和 UTXO 支持新输出类型【bse-output】。这意味着用户可能很难找到可以聚合的交易伙伴，从而限制节省费用的机会。如果只有少数人使用 CISA，用户节省的费用可能不够大，难以抵消协调的额外成本，如为了等到足够的参与者而产生的时间延迟。因此，在采用率较低的阶段，激励可能不足以引导用户改变行为，采用 CISA 的交易也可能仍属少数，反而更加显眼。只有当达到一定用户临界点后，网络效应才能真正发挥作用——整体费用降低、CoinJoin 式的批处理更为活跃、比特币的可替代性也将得到改善。在此之前，用户将面临“启动困难”问题，CISA 的好处只能部分实现。

广泛采用 CISA 有助于增强如 CoinJoin 等隐私增强技术的社会与法律正当性。通过使多用户交易在经济上具有吸引力，CISA 为此前被视为纯粹出于隐私动机的行为提供了财务上的合理性。用户和公司可以合理地声称他们是为了节省手续费而聚合交易，而不仅仅是为了混淆资金流向。实际上，CISA 会让 CoinJoin 回合的费用比普通交易更低【trezor】，这印证了早前的预测：即使只是节省一点手续费，也可能显著增加 CoinJoin 的使用率【ops-cisa】。这种费用激励可能极大地扩大 CoinJoin 的使用，增加整体匿名集，进而将其行为标准化。

如果为了节省费用而广泛采用批处理和聚合交易，这将模糊普通转账与隐私增强转账之间的界限。这种“正常化”行为将保护用户：选择 CoinJoin 会被视为一项标准经济决策，从而减少与之相关的污名或嫌疑。一些行业分析指出，如果 CoinJoin 被普遍采用，当前形式的链上监控将变得几乎不可能【trezor】。在大多数交易都被聚合的情境中，试图禁止或打压 CoinJoin 的做法将面临实际和政治上的阻力，因为这种行为将无法与普通的费用节省行为区分开。CISA 有可能通过将隐私融合进效率提升中，来增强比特币的可替代性，保障用户在“合理理财”名义下提升隐私的权利。最终，这应能改善当前执法机构对 CoinJoin 用户进行偏见性调查和迫害的问题。

7.3 矿工激励与网络层面影响

在比特币中，一笔交易的输入消耗的是先前存在的输出，并创建新的输出，这些输出成为 UTXO 集的一部分。如果输入多于输出，UTXO 集就会收缩；反之，则增长。CISA 通过大幅减少每个输入的签名开销，改变了使用多个输入的交易经济模型。这将影响用户清理 UTXO 或参与多输入交易的意愿，从而改变输出销毁与创造之间的平衡。

在现行手续费机制下，创建输出的成本和花费它们的成本存在差距。过去创建多个小额输出成本较低，而花费这些输出则成本较高。这导致了所谓的“尘埃 UTXO”，即因手续费大于其面额而长期未被花费的输出。CISA 通过降低签名成本，使得在交易中加入低价值 UTXO 的门槛进一步降低。即便是极小的输出，也可以以极小的额外开销与其他输入一起聚合处理。

这意味着用户更可能在手续费合适时清理尘埃 UTXO，而不是无限期搁置。提升对尘埃的清理能力，有助于逐渐优化 UTXO 集结构。因此，CISA 倾向于鼓励销毁输出、使用现有 UTXO，通过提升多输入交易的费用效率，有助于抑制 UTXO 集的膨胀。用户在合并或使用多个输入时将面临更少惩罚，网络可能在某些整合周期中出现 UTXO 总数的增长放缓，甚至出现净减少的情况。需要再次指出的是，SegWit 减弱了这一节省效应，因为它已通过规则设计实现了类似目标。

SegWit 引入了对见证数据的“折扣”机制：在计算区块大小时，每个见证字节只计为 0.25 字节，相当于 75% 的折扣【bse-segwit-cheap】。这个机制本就是为了降低花费输出的成本，从而缓解尘埃问题。除非未来对 SegWit 的折扣机制有所变动，CISA 的节省效果将受到此机制的影响，尽管空间节省显著，但费用节省并没有那么惊人【ops-cisa】。

从矿工的视角看，SegWit 折扣和 CISA 改变了权重的分布方式，但矿工仍希望填满每个区块的 4M 重量单位上限，以获取最大手续费收益。CISA 交易相比非聚合交易占用更小的权重，因此只要未达到非见证数据的 1MB 上限，矿工就能在区块中打包更多交易数据。如果用户对区块空间的需求保持不变，这相当于轻微提升了网络吞吐量，可能在长期内对手续费率造成温和下行压力，因为区块空间的供给略有增加。不过，这种节省的空间也可能因新增使用场景而被抵消甚至超出（即“杰文斯悖论”）。不论如何，对矿工手续费收入的总体影响预计不大。

此外，由于见证数据的空间占用减少，矿工可能更愿意在区块中打包大量 ordinal 交易。如，如果一个区块中打包了大量合并交易，可能会先达到非见证数据的 1MB 上限。这种情况下，见证区部分将显得相对较小。矿工此时可能以较低费用打包接近 3MB 的 ordinal 交易，因为 ordinals 利用见证数据在链上存储各种数据。这种现象可能引发争议，因为 ordinals 本身就具有争议性，而 SegWit 折扣被认为是其兴起的主要原因。

另一个有趣的副作用是，如果使用 half-agg 进行区块级签名聚合，用户在估算手续费时将面临新的复杂性。即他们发出的交易在传播到网络时的大小，可能与最终被打包入区块的实际大小不同。这意味着注重费用的用户可能会进一步低估当前逻辑下给出的手续费估算。因此，为了保持估算的准确性，钱包的手续费估算算法可能需要更新，以适应 CISA 启用交易所带来的变化。

8. 实现状态与前景展望

在本章中，将简要回顾 CISA（跨输入签名聚合）的当前规范与实现状态，并展望其成为完整提案所需的关键步骤。除了已经发布的部分，其余内容都可能在遇到不可预见问题时发生变化。

8.1 共识规则的更改

本节讨论需要在 BIP 中详细说明并在代码中实现的共识规则更改，以避免在后续章节中重复说明。

部署 CISA 并不像当前一些公开讨论的新操作码（op code）提案那样简单，它需要通过软分叉引入新的 SegWit 版本。根据现有的比特币规则，即使使用了 Schnorr 签名，每个输入也必须通过独立的签名验证。CISA 的目标是允许使用一个签名验证交易中所有或部分输入。这一变更将通过引入新的 SegWit 版本来实现，并定义不同的 witness 验证逻辑。

实际上，这个新版本的 SegWit 将基本复制 Taproot 的规则，但会修改为只需一个签名即可验证受支持的所有输入，并伴随一些脚本更改。使用新的 SegWit 版本的一个优势在于，不支持 CISA 的旧节点和软件将把它视为未知 witness 版本，从而将相关输出视为 anyone-can-spend 或未识别的输出类型，从而实现前向兼容性。通过将新行为隔离在新的输出类型中，可以避免对现有交易类型的歧义或回溯性更改。

如上所述，新版 SegWit 大致复制 Taproot，但需要在比特币脚本中进行一些关键修改。

首先，需要引入新的签名校验操作码，如 OP_CHECKAGGSIG 和 OP_CHECKAGGSIGADD，以实现签名聚合。
其次，这些新的聚合签名校验操作码与在 Taproot 中引入的 OP_SUCCESS 升级机制存在不兼容问题。简言之：聚合签名校验操作码会推迟签名验证，而 OP_SUCCESS 操作码可能已被重新定义（或未定义），这将导致升级节点和未升级节点之间的共识失败。如果脚本同时包含聚合签名和 OP_SUCCESS，未升级的节点可能无法检测出无效的聚合签名，因为 OP_SUCCESS 会使整个脚本直接判定为有效。

开发者 AJ Towns 已在邮件列表中指出了这一问题，并提出了几种解决方案 [cisa-success]，但目前社区尚未就最佳解决方案达成共识。

CISA 最自然的应用场景是 Taproot 的 key-path 花费路径，但对于 script-path（脚本路径）是否需要支持聚合仍有争议。目前有一个名为 “Generalized Taproot” 的替代提案，可能能优雅地解决 CISA 在脚本路径上的支持问题，同时也解决 OP_SUCCESS 带来的潜在共识分歧问题 [thoughts]。不过，这也会为 CISA 的提案增加额外的复杂性 [groot-cisa]。

8.2 比特币改进提案（BIPs）

鉴于 CISA 的复杂性，完整的软分叉提案预计将由多个 BIP 组成，这类似于 Taproot 是由 BIP 340-342 三个提案共同组成。目前提案的划分只是一个大致框架，最终版本可能会根据社区反馈发生调整。

目前用于描述“半聚合”方案的 BIP 仍处于草案阶段，只剩下少数问题待解决后即可提交至 BIP 仓库。由于“半聚合”机制在链下也有重要应用价值，因此将其作为独立 BIP 是合理的 [halfagg-bip]。

除了“半聚合”BIP外，还需要一个用于描述“全聚合”的 BIP，其核心任务是说明签名方案，其复杂度接近 MuSig2 的 BIP。围绕该签名方案的研究和开发将是 CISA 全聚合版本推进中的最大难点，后文将对此进行更详细说明。

最后，还需要至少一个新的 BIP（可能是一系列）来详细描述新的交易版本，即 SegWit version 2。这个新版本将修改 witness 程序结构，允许在聚合签名上下文中存在空签名。此外，它还会引入支持聚合签名校验的新脚本操作码，并提出与 OP_SUCCESS 不兼容问题的解决方案。

同时，也可能需要新的 PSBT（Partially Signed Bitcoin Transactions）BIPs 来扩展其行为，以支持包含聚合签名或待聚合签名的交易。

目前尚无资源专门用于开发“区块级”聚合提案，因此尚不清楚此类提案所需 BIP 的结构和数量。

8.3 代码实现

对于半聚合（half-agg），已经有几个实现可供参考，最著名的是 secp256k1-zkp 中实现的该功能 [halfagg-zkp]。基于该实现的代码，已经有一个针对 secp256k1 的拉取请求 [halfagg-secp]。此外，还有在 hacspec（待重写为 hax）和 Python 中的实现。

由于进一步的代码尚未编写，因此目前只能推测实现过程中的复杂性在哪里。Bitcoin Core 需要新增代码，允许验证聚合签名与多个（公钥，消息）对的匹配。比如可以通过一个特殊的操作码来实现，操作码在输入上积累聚合状态，然后在最后一个输入或交易级别的数据中验证最终签名。一个能够反映复杂性的一些指标是，Bitcoin Core 中的批量验证工作 [batch-core]。聚合签名需要作为一种状态在检查过程中持续存在，并且在所有签名收集到聚合签名后才会被验证。这要求修改检查排队逻辑，而这些修改在撰写本文时尚未完全完成。

如果是针对整个交易（tx-wide）的 CISA，将会对钱包软件进行相当大的修改，而如果是区块级（block-wide）的半聚合，则主要增加节点软件和矿工的工程工作量。

8.4 密码学学研究

如前所述，形成一个全聚合签名（full-agg signature）需要一个交互过程。交互性为任何协议增加了巨大的复杂性。如，所有签名者在签名时必须在线。希望集成全聚合签名的现有协议将在未来需要实现和处理这种复杂性，包括新引入的失败场景、隐私影响等。

截至目前，还没有专门针对全聚合签名的方案开发出来。但这样的方案将使用与 MuSig 和 Bellare-Neven 类似的思想。

根据密码学家 Jonas Nick 的说法，以下特性是全聚合方案所期望的：

可证明的安全性
允许重复的公钥
不需要所有权证明（proofs-of-possession）
与 Taproot 调整和 MuSig 等方案兼容
采用像 MuSig 那样的两轮签名
支持批量验证

需要明确的是，目前没有专门的研究针对这些目标。相比之下，半聚合（half-agg）已经有了更为深入的发展。目前，研究者唯一给出的建议是，Bellare-Neven 可能是一个不错的起点 [bn]。

8.5 部署

CISA 明确设想为一次软分叉升级 [thoughts]。通过使用新的 SegWit 输出版本，它确保了向后兼容，因此旧节点不会验证这些花费，但也不会拒绝它们。有关这一点的更多细节已经在共识规则更改部分进行了讨论。此外，值得注意的是，新的输出类型并不意味着地址格式也必须改变。支持 CISA 的地址很可能会使用与 Taproot 相同的 Bech32m 格式。

比特币中的软分叉升级通常需要矿工信号和生态系统中的广泛共识。关于激活机制的讨论超出了本文的范围。