术语表 /协议与升级
批量验证
- 批量验证是什么？
- 批量验证是在一个椭圆曲线方程中一次性检查多个 Schnorr 签名，而不是逐个检查，并对整组签名只返回一个通过或失败的结果。
规定于 BIP-340。
验证方将 u 个签名打包，除第一个外都乘以一个随机标量作为权重，并用一个方程而不是 u 个方程完成整包的验证。BIP-340正是为此而设计，把签名固定为64字节，而标准化的 ECDSA 除非添加额外的见证数据，否则完全无法批量验证。是否批量处理由每个验证方自行决定，因此它改变的是节点检查历史记录的速度，与您的比特币无关。
运作方式
批量验证在 BIP-340中被规定为 BatchVerify，它接收 u 个32字节的公钥、u 条消息和 u 个64字节的签名，并对所有这些签名一次性给出答复。
首先确定权重。验证方生成 u-1个取值范围在1至 n-1之间的整数（n 为曲线的阶），生成方式是确定性的，所用生成器以该批次中所有输入（公钥、消息和签名）的哈希作为种子。BIP-340认为 SHA256 是安全的种子哈希，ChaCha20 是将其扩展为256位整数的安全方式，并跳过落在范围之外的整数。
随后整个批次被归结为一次检验：各 s 值的加权和乘以生成点，必须等于对 R 点以及每个签名的挑战值乘以其自身公钥所施加的同样加权结果。这 u 次独立检查变成了一次比较，BIP-340认为这能带来显著的提速。
这一节省以每个签名的额外开销为代价。BatchVerify 会把每个 r 值还原到曲线上，而单个验证从不这样做：Verify 根据 s 和挑战值重新计算 R，然后只检查其 x 坐标是否等于 r。
这一保证是刻意不对称的。如果批次中的每个签名都有效，BatchVerify 必然成功；如果哪怕只有一个签名无效，它成功的概率至多可以忽略不计。它不会指出是哪个签名出了问题，因此需要知道哪个签名出错的验证方，会逐个检查这些签名。
在哪里会遇到它
批量验证完全发生在网络的验证方一侧，因此它从不出现在钱包界面或手续费估算中。
它的价值体现在节点一次性处理多年的 Taproot 花费时，而不是钱包发送一笔付款时。BIP-340在任何地方都没有强制要求批量处理：单个签名验证才是定义，批次只是验证方可以选择的做法。该 BIP 要求算法在字节层面精确规定，这种精确性是 DER 解析在 BIP-66之前所缺乏的，因此没有人能构造出对一些验证方有效、对另一些验证方无效的签名。由于验证方自行选择批次，这一特性使批量验证与单个验证即使面对试图让二者结果不一致的攻击者，也只可能以可以忽略不计的概率出现差异。
批量处理还解释了 BIP-340中一些单独来看似乎随意的选择。签名本可以采用更短的形式，即16字节的哈希就足以满足128位的安全目标，但该 BIP 否决了它：当互不信任的签名方共同签名时，短哈希是脆弱的，而带有 R 的较长形式才支持批量处理。公钥为32字节，而不是比特币通常的33字节压缩编码，这是出于紧凑性的选择，由此省去的 y 坐标被固定为偶数，而不是留作歧义，因为高效验证和批量处理都需要它没有歧义。
ECDSA 无法获得其中任何一项。BIP-340把这一点列为更换签名方案的理由之一：除非添加额外的见证数据，标准化的形式无法比逐个验证更高效地批量验证。
批量验证 vs MuSig2
批量验证和 MuSig2 都能让大量签名的处理成本更低，但只有 MuSig2 会改变所广播的内容。
MuSig2 在交易到达网络之前，把多个签名方聚合为一个密钥和一个普通的64字节签名，因此它的节省体现在隐私和区块空间上，并且是 n-of-n 的：每个签名方都必须参与。批量验证让每个签名保持原样，只重新安排验证者执行的运算，不需要任何人的配合，甚至无需任何人知晓：节点可以把陌生人在相隔数年、互不相关的交易中产生的签名一起批量处理。