本文作者为万向区块链、PlatON首席经济学家邹传伟。; _1 t$ z5 ?+ n) ^1 e" V* o  O

. j6 b6 E' w( j5 v$ G! }; K' i3 y2 D1 u2020 年 1 月，由比特币核心开发人员 Pieter Wuille 于去年 5 月提出的 Taproot/Schnorr 软分叉升级提案已正式作为比特币改进提案（BIPs）发布，相关提案序号为 BIP 340-342。Taproot/Schnorr 升级如果获得社区支持，将是比特币自闪电网络上线后最大的技术拓展。本文查询了 BIP 340-342 相关文档 ，对 Taproot/Schnorr 升级做一个简单介绍。本文分三部分，第一部分简单介绍比特币目前的 ECDSA 签名算法，第二部分详细介绍 Schnorr 签名算法，第三部分介绍 Taproot。( `1 Z" o$ }5 z! R5 Y6 _

; f- D4 B8 Z% v6 a一、比特币 ECDSA 签名算法
( l& n' a2 h, x% V. D0 u7 I( T1 j6 R4 W
比特币目前使用的 ECDSA 签名算法与建议的 Schnorr 签名算法，都属于椭圆曲线数字签名算法，它们使用的椭圆曲线都是 secp256k1。这一部分先介绍椭圆曲线 secp256k1，再介绍 ECDSA 签名算法。
3 [  O6 N) u; X: y, l) E
+ |" y0 l; D3 H: C' d- A, X（一）椭圆曲线 secp256k1
: H( Z0 a! n1 x9 A, g& \: Y$ {) I' o7 Z5 ?6 }% |

% C2 z# v. m) g1 B  l9 l5 X, q; x+ V! T# G/ d, e# O
（二） ECDSA 签名算法
) _) L# q0 p* l7 R
8 D$ E/ P6 W/ W' `7 ]2 q1 @注： G 坐标为 （79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8）， 阶等于 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141， 均采用 16 进制表达。
* e. ]8 |+ F# F! `9 _3 O4 n: }* M9 D( ?) ], w
二、Schnorr 签名算法; G+ y( [8 q( R1 ~3 @5 F8 ]

, R5 ]  E9 L5 I: P; L4 \7 z8 B" [" ^这一部分先介绍 Schnorr 签名算法主要特点，再分步骤介绍 Schnorr 签名算法及批验证，最后介绍基于 Schnorr 签名的多重签名算法。
6 N' I4 i1 }0 N4 G; I& G
+ [, d+ t+ B5 @, x9 W（一）主要特点Schnorr 签名算法与 ECDSA 签名算法使用同样的椭圆曲线 secp256k1 和哈希函数 SHA256，所以在这个层面它们具有同样的安全性。Schnorr 签名算法主要有以下优点。
  T* X; w% g( K! d/ M' t2 b9 [* y: q! I5 u1 N7 O4 y
第一，Schnorr 签名算法有可证明安全性。在假设椭圆曲线离散对数问题难度的随机寓言（Random Oracle）模型，以及假设原像抗性（Preimage Resistance）和次原像抗性（Second Preimage Resistance）的通用群模型下，Schnorr 签名算法具备选择消息攻击下的强不可伪造性（Strong Unforgeability under Chosen Message Attack，SUF-CMA）。换言之，如果不知道 Schnorr 签名的私钥，即使有针对任意消息的有效 Schnorr 签名，也没法推导出其他有效 Schnorr 签名。而 ECDSA 签名算法的可证明安全性则依赖于更强的假设。
% ]8 r4 R& I: L, ?
% z5 Z& }  V) g6 X第二，Schnorr 签名算法具有不可延展性（Non-malleability）。签名延展性的含义是，第三方在不知道私钥的情况下，能将针对某一公钥和消息的有效签名，改造成针对该公钥和信息的另一个有效签名。ECDSA 签名算法则有内在的可延展性，这是 BIP 62 和 BIP 146 针对的问题。
% i( c, k8 K" ^& k3 x9 l$ B, [9 f9 F6 P- e" s
第三，Schnorr 签名算法是线性的，使得多个合作方能生成对他们的公钥之和也有效的签名。这一特点对多重签名、批验证（Batch Verification）等应用非常重要，既能提高效率，也有助于保护隐私。而在 ECDSA 签名算法下，如无额外的见证数据，批验证相对逐个验证并无效率提升。
7 W, j, A& W2 ]8 l9 V3 ]; S# A
& G9 S0 Y" Z: e3 S2 n最后，Schnorr 签名算法因为使用同样的椭圆曲线 secp256k1 和哈希函数 SHA256，能兼容目前的比特币公私钥生成机制。4 L4 U& m  _* ]

1 h9 @& U. {- O0 l（二） Schnorr 签名算法
( d7 Y  E% L" Q2 P
+ ]6 c- E0 N6 s* {9 L% K6 u公私钥生成
0 @( L* Q5 C- y
+ R) Y, m5 S+ V8 l7 o签名生成( R, Y6 W( k6 V6 \4 v, n

* @: [0 G5 M% K* z. J# M, m签名验证
7 i* B1 T" r/ B% }7 x
+ [" O% T+ |# C) v批验证
; s) b4 \; C* y2 v  y0 s% ~  ?0 l0 X9 Q# _
& Z. G- f- I" \/ N' K" c
6 d8 T0 I6 r* F( L  H" Q! v! x
（三） Schnorr 签名算法与多重签名
. a: i, E7 R# h; h  p' F! l1 G! M; h
密钥生成
- a3 r, v; E) T9 H6 n1 \$ l: K! S5 j5 k! t
签名生成
$ b1 ^1 r  z) X( F/ L: Y4 F  A. r! F" n; {: |
签名验证
- v/ x; a" ]1 o- \2 |5 t" o# q9 o  e  `4 P3 s! C
三、Taproot 升级; P6 N8 S& b+ y$ `% j
. r9 H" v2 L; K' ~. G0 I* q' _
Taproot 升级可以视为默克抽象语言树（Merkelized Abstract Syntax Tree，简称 MAST）的一个应用，而 MAST 又与支付到脚本哈希（Pay-to-Script-Hash，简称 P2SH）有关。因此，这部分依次介绍 P2SH、MAST 和 Taproot。/ y7 W. E7 D7 b4 ]

' v2 s9 y2 e& w6 e9 v（一） P2SHP2SH 是 2012 年推出的一类新型交易，使复杂脚本的使用与直接向比特币地址支付一样简单。在 P2SH 中，复杂的锁定脚本被其哈希值所取代，称为兑换脚本（Redeem Script）。当随后出现的一笔交易试图花费这个 UTXO 时，必须包含与哈希值匹配的脚本，同时解锁脚本。P2SH 的主要优点包括：一是在交易输出中，复杂脚本由哈希值取代，使得交易代码变短。二是将构建脚本的负担转移至接收方，而非发送方。三是隐私保护性更好。理论上，除了接收方，任何其他方都可以不知道兑换脚本中包含的支出条件。比如，在多重交易中，发送方可以不知道与多重签名地址有关的公钥；只在接收方支出资金时，才披露公钥。但 P2SH 也存在不足：一是所有可能的支出条件最终都必须被披露，包括那些实际上没有被触发的支出条件。二是在有多个可能的支出条件时，P2SH 将变得繁复，会增加计算和验证的工作量。0 G* |- k) Q1 |  |% d
, p: D, s# O* {
（二） MASTMAST 使用默克树来加密复杂的锁定脚本（图 3），其叶子是一系列相互不重叠的脚本（比如，多重签名或时间锁）。要支出时，只需披露相关脚本以及从该脚本通向默克树根的路径。比如，在图 3 中，要使用 script 1，只需披露 script 1、script 2 以及 hash 3 即可。
- a! \" H8 c7 L1 U# M8 H" B6 p0 J/ Z5 S* |& X2 O3 H
, v9 r" _( m  T+ Q" k* ?8 g+ l/ S
' ?( ^& X  W5 O5 W% m0 X! K+ E. v
MAST 的主要优点包括：一是支持复杂的支出条件。二是不用披露未被执行的脚本或未被触发的支出条件，提供更好的隐私保护。三是压缩交易大小。随着脚本数量的增加，非 MAST 交易大小是线性增长，而 MAST 交易大小是对数增长（图 4）。
, x, w6 k0 I7 |; R7 T0 [# I! h7 D4 g% h, v. @* A
1 B9 d7 S; B& j9 T8 k6 T3 F

& o6 p1 ^& y  A/ _（三） Taproot但 P2SH 与常见的支付到公钥哈希（Pay-to-Public-Key-Hash，P2PKH）在表现上不一样，仍然有隐私保护问题。有没有可能让 P2SH 和 P2PKH 在链上看起来一样？这就是 Taproot 要解决的问题。. Z$ v. |# b+ X( Q! q# _3 ~

* d  o$ Y4 i9 o) i涉及有限数量签名者的脚本，可以分解成两部分：第一部分是多重签名，所有签名者都同意某一支出结果，称为「协作式支出」；第二部分称为「非协作式支出」，可以有非常复杂的脚本结构。这两部分是「或」的关系。比如，在图 3 中，Script 3 是一个 2-of-2 型多重签名，需要 Alice 和 Bob 两人都签名才有效，是「协作式支出」；Script 1 和 2 是「非协作式支出」。