发表时间：2020年8月25日
作者：张伟 / Wei Zhang
信息来源：https://medium.com/nchain/simplified-payment-verification-48ac60f1b26c
简易支付验证（SPV）的概念可以追溯到2008年发表的比特币白皮书。它以一种可扩容且高效的方式验证一笔交易是否被记录在一区块中。然而，SPV有一些细微但却十分重要的方面往往被忽视。这篇文章将探索SPV在即时支付、数据所有权和法律合规性方面所起到的作用。
区块纳入证明（Proof of Publication in a block）
比特币白皮书的第8章节介绍了SPV是某笔支付是否已被比特币网络接受的一种验证过程。假设验证者可以访问区块头列表，以及一笔比特币交易的数据和这笔交易的Merkle Proof，而且通过这个Merkle Proof推导出Merkle root出现在某个区块头中，那么这就能证明这笔交易的确已被纳入了该区块头对应的区块中。这个验证之所以被认为是“简易”的，是因为整个过程只需要三样信息：
- 区块头列表（截至目前，这个列表只有52MB）；
- 一笔交易的完整数据（对于支付至公钥哈希P2PKH的简单交易（脚注1）来说，这个数据不到400字节）；
- 一个Merkle Proof（即使一个区块包括10亿笔交易，这个Merkle Proof也仅有928字节）
试想有一个商家Bob，维护并实时更新一个区块头列表。当他从他的顾客Alice那里收到一笔支付交易时，他可以在获得这笔交易的Merkle Proof后立即核实这笔交易是否已被记录在某一区块中。如果实施了BIP-270流程，那么就应是Bob本人（或收款方）负责将支付交易发送到比特币网络并获取Merkle Proof。在拥有SPV客户端的情况下，这个流程十分有效，因为商家本身就拥有简易支付验证所需的上述三样信息。
对于Bob来说，他运行此系统的成本远低于维护完整区块链所需花费的成本。这种SPV验证机制在存储和带宽方面的需求具有天然的轻量级特性，因此不难看出它可以很容易地扩展开来。
即时支付（Instant Payments）
这可能有些违背常理，但SPV确实还可以用在那些即刻生效的支付场景中。在这个情况下，[1] 顾客Alice需要提供两个交易和一个Merkle Proof给商家Bob：一个是本次支付的交易；另一个是该支付交易所花费的交易输出，该输出所在的那笔交易将被引用为“前序交易”；这里的Merkle Proof是“前序交易”的。（注：此处“前序交易”的数量实际上应取决于本次支付交易的全部输入来自多少个不同交易，但在本例子中为了简化，我们假设Alice这次支付的输入值来自一笔前序交易。）
请注意，此时Alice的这笔支付交易并没有Merkle Proof。
对前序交易进行简易支付验证（SPV）的动机之一，是为了加入一个快速失败机制，即Bob在发送这笔交易到比特币节点之前，可以自行快速检测到无效的支付交易。这是因为如果前序交易被证明确实存在于全球账簿上，那么这就证实了Alice在过去某个时刻确实拥有此次支付所需的资金。
事实上，简易支付验证有一个更根本的动机——验证交易的完整性：确保顾客提供的前序交易的数据没有被篡改过。在详细解释这一点之前，我们想做一个合理的假设：数字签名具有法律约束力。请注意，英国自2000年起一直是这样。
数字签名的有效性（Digital signature validity）
假设Alice想从Bob那里买个游戏机，她向Bob发了一笔支付交易。
图：此笔支付交易
在查看这个支付交易时，Bob可以确定它花费了前序交易（TX_previous）的一个输出，并按照他的收款要求将x分配给他。为了确定这笔交易的有效性，他可以将此交易发送到比特币节点等待反馈，但需要等待一段时间。为了更好地为顾客服务，Bob注意到在这笔支付交易中有一个数字签名（Sig_A,PK_A），如果他能够验证这个数字签名有效并确保它来自Alice，他就可以很乐意地完成这笔买卖。因为有了Alice的数字签名，所以Alice将对她的行为承担法律责任。以此类比，我们可以联想到人们在使用信用卡支付时，需要签字来确认支付，此时验证签名的方式就是检查付款人的签字是否与卡背面的签名相同。当购买一件高价值商品时，可能还需要用带有照片的身份证来辅助验证。
此处一个隐含的假设是Bob能够将Alice的身份与公钥联系起来。这种假设在某些情况下可能不成立，例如当交易价值相当低的时候。不过，考虑到有效即时支付的益处以及审计和税收的需要，我们可以通过诚信计划、认证公钥（脚注2）或任何其它激励系统或法律法规强制要求等方式来使这一假设具备合理性和实现性。或许很快就会出台法规当购买金额超过某一额度时，要求付款者提供可验证的身份证明。
一般来说，验证一个数字签名需要三个[2] 信息：
- 数字签名
- 公钥
- 所签消息
我们可以看到Bob已经有了前两个信息，但是所需的那一条所签消息不仅取决于这笔支付交易，还涉及到了前序交易TX_previous。
图：前序交易TX_previous
这个被签的消息包含前序交易的第一个输出，即输出值（Value）和锁定脚本（Locking script），它在支付交易的输入中被引用。有人会说Alice可以额外提供仅仅 w 和 OP_DUP OP_HASH160 <H(PK_A)> OP_EQUALVERIFY OP_CHECKSIG 给Bob验证数字签名，然而Alice无法证明从前序交易中所提取的数据的完整性（未被篡改过），除非她能提供完整的前序交易及这个交易的Merkle Proof。Merkle Proof作为交易完整性的证明可以告诉Bob以下两点：
- 锁定脚本确实是要求提供针对特定公钥的数字签名（例如P2PKH脚本）；
- 锁定脚本未被修改过。
对前序交易的完整性进行确认的重要性经常被低估。前序交易中的一个锁定脚本如OP_DROP OP_DROP OP_TRUE将允许Alice在解锁脚本中放置任何一对看起来像签名和公钥的字符串。如果Bob只有这笔支付交易的信息，他是不能判断签名的有效性及公钥的合法性的。此外，因为不知道前序交易中的锁定脚本是什么，这意味着Bob也不能认定比特币节点会验证此签名。上述例子的锁定脚本里并没有OP_CHECKSIG，因此脚本执行时不会有验证签名的步骤。
请注意许多数据应用程序（如Metanet应用程序）依赖于交易解锁脚本中的签名及公钥的有效性，从而来表明数据所有权或访问权限。交易的有效性并不意味着签名的有效性，除非提供了前序交易，并且它的锁定脚本表明需要提供特定公钥的签名（脚注3）。如果Bob仅仅要求了锁定脚本和输出值，那么Alice有可能会生成任意一对新的私钥和公钥，并创建一个与公钥对应的伪P2PKH锁定脚本来隐藏自己的身份或冒充他人身份。接下来她就可以对消息进行签名，这样当Bob在对支付交易和伪造的锁定脚本进行验证时，结果签名会是有效的。因此对于Bob来说，在进行签名验证之前，对前序交易进行简易支付验证从而对交易完整性进行检查是至关重要的。
通过成功验证消息中与Alice身份相关的公钥的数字签名，Bob确信Alice确实拥有（数额）w 比特币的合法控制权，并且她通过数字签名批准将其中的x比特币转移给自己。在这种情况下，Bob就愿意完成这笔交易，因为他知道如果Alice进行双花，她将承担法律责任。这就是SPV如何有效地实现即时支付。
总结
当某些场景中需特别使用到解锁脚本中的数字签名和公钥时，前序交易的完整性，或者更准确地说，前序交易中锁定脚本的完整性就变得极其重要。完整性证明确保了解锁脚本中的数字签名和特定公钥会在比特币网络中被有效验证。如上所述，这完整性证明可以通过对前序交易进行简易支付验证来实现。
在上面的例子中，签名和公钥（与Alice的身份相关联）被视为Alice同意向Bob支付比特币购买商品的证据，因此Bob需要确保签名是有效的，并且确实来自Alice。这个概念也同样适用于交易中的数据所有权或数据证明，例如Metanet应用程序或通过一笔交易在OP_RETURN的荷载中公证一个文档。
最后我们要强调的是，SPV不仅可以用于证明已发布交易的存在性，而且还可以用于证明交易的完整性，而交易的完整性就意味着该交易中的任何数据的完整性。
脚注：
[1] 如果只提供交易ID来验证它的存在性，那么验证者需要知道Merkle树的深度或者交易ID出自的原始交易，才能确认这个交易的存在。这是为了确保交易ID确实是Merkle树上的叶子，而不是内部节点。任何信息都可能使验证者需要存储或访问一些额外信息。
[2] 为了避免重复使用已获得认证的身份密钥，Alice可以在Bob验证她的身份之后从她的身份密钥派生出一个密钥对：如可以通过使用BIP32未硬化的密钥路径，或者基于Alice和Bob之间的Diffie-Hellman密钥交换来实现派生。这是为了确保Bob可以验证支付中使用的公钥和经过认证的身份公钥这两者之间的对应关系。
[3] 我们感谢Volt的CTO淘小杰，他此前独立发现了前序交易在验证Metanet交易中的重要性（参考文章：https://www.yuque.com/docs/share/0b224413-7987-4ebf-b0e3-6b268ae18f27），并促使我们写了这篇文章。
Bitcoin SV是唯一遵循着中本聪于2008年发表的白皮书《比特币：点对点的电子现金系统》中协议的区块链。