区块链轻节点和 SPV

参考：

为什么会有SPV：

在整个比特币生态中，绝大部分是普通用户，即只需要基本的比特币投资和消费支付的用户。 他们可能没有高端配置的矿机或电脑，那么他们是否也需要运行全节点？ 程序呢？ 因为随着时间的推移，目前比特币主链的区块数据已经高达200G，如果是手机钱包的话想想看。 ，或者个人PC钱包，如果下载主网的完整区块，存储压力会太大。 这时候spv出现了。

比特币网络中的一个节点在打包一个区块时，会对区块中的所有交易进行验证，一笔交易会经过6到7个区块的确认，以保证交易的最终完成。 就这样，在使用简单的支付验证时，只要判断出一笔交易出现在主链的某个区块中，就可以证明这笔交易之前已经验证过了。

【注意】：

这里有一个细节需要注意，SPV指的是“支付验证”，而不是“交易验证”。 这两种类型的验证之间存在很大差异。

“交易验证”非常复杂，涉及到验证是否有足够的余额可以花费，是否存在双花btc区块数据结构，脚本是否可以通过等，通常由运行全节点的矿工完成。

“支付验证”比较简单。 它只判断用于“支付”的交易是否经过验证，获得了多少算力保护（多少确认）。

简单来说，交易验证就是验证交易是否合法； 支付验证是验证交易是否已经存在

【考虑这样一种情况】：SPV的目标是验证一笔支付是否真实存在，收到了多少确认

A收到B的通知，声称从某某账户汇了一定数额的钱给A，在去中心化的方式下，没有人可以证明B的可靠性，收到这个通知后，A如何判断B说的是真的吗？

在比特币系统中，这个通知是作为一个固定格式的“交易”来实现的，包括B的汇款账户、B的签名、汇给A的金额、A的地址。

如果A要亲自验证这笔交易，首先，A需要遍历区块链账本，定位到B的账户，以查看B给的账户中是否有足够的钱； 接下来，A需要遍历后续的所有账本，看B是否把这个账户里的钱花给了别人（是否存在双花欺诈）； 然后验证脚本，判断B是否有账户控制权。 这个过程要求A必须获得完整的区块链。

但是，如果A只是想知道支付是否通过验证（如果验证通过就发货），他可以依靠比特币系统进行快速验证。 也就是说，检查发生此付款的交易是否已包含在区块链中以及它收到了多少确认。

SPV 的特点：

SPV节点一般会在与相邻节点的连接中设置BoomFilter（Boomfilter只接受包含钱包公钥地址的交易），当相邻节点看到一个TX符合SPV节点的BoomFilter条件时，会发送一个merkleblock消息给SPV节点发送一个区块； [merkleblock：包含 BlockHead 和连接到 TX 的 Merkle Root 的 Merkle 路径]； SPV 节点可以使用 merkle 路径将 TX 与包含 TX 的区块链接起来，并使用 BlockHead 来验证包含 TX 的区块是否在 BlockChiain 上并通过了 6 次确认。 这两个验证可以证明TX存在于区块链上。

总之，SPV只需要接收小于1KB的BlockHead和merkle路径数据

spv验证过程：获取并保存从网络到本地的最长链的所有区块头； 计算交易的哈希值tx_hash； 定位包含tx_hash的区块，验证区块头是否包含在已知最长链中的链中； 从区块中获取构建默克尔树所需的哈希值； 根据这些哈希值计算 merkle_root_hash； 如果计算结果等于区块头中的merkle_root_hash，则交易真实存在。 根据区块头的位置，判断交易收到了多少确认。

【简单来说，SPV其实做了两件事】：

1. 找出要验证的交易在哪个区块；

2.判断交易是否已经确认6次。

比如想验证上面的H(K)交易是否已经支付：

首先，节点从网络中获取需要验证的交易的认证路径，并在节点上生成相应的路径。 路径的值为图中蓝色标记的节点。 在路径确认的情况下，节点只需要计算H(KL)、H(IJKL)、H(IJKLMNOP)、H(ABCDEFGHIJKLMNOP)的哈希值两次，就可以得到默克尔根的副本。 如前所述，spv节点保存了整个区块链的所有de-block header，所以只需将这份副本与de-block header中的merkle root进行比较即可。 如果存在，则可以证明交易支付成功。

SPV的使用场景：

1. 轻钱包支付验证

2. 在侧链的双向链路中，主链和侧链需要对特定交易进行SPV验证，确保交易确实已经支付，从而实现一方锁定资产，另一方转账资产

如：（比特币侧链）

a] 当用户想要将BTC转入侧链时，首先在主链上创建一个交易【特殊交易】，将要转出的BTC发送到一个特殊的输出端，这些BTC锁定在主链上.

b) 等待一段时间的确认，让上面的交易有足够的工作量确认[eg: 6 confirmations]

c) 用户也在侧链中创建交易提取BTC【其实严格来说此时不能是侧链中的BTC，而是按比例兑换的侧链的token】，并且上述委托人需要在本次交易的输入中指定。 链的输出被锁定并提供足够的 SPV 证明。

d] 等待一段时间的竞争以防止双花

e] BTC是这样在侧链上流通【严格来说应该是按比例兑换的侧链代币】

f] 当用户想要将BTC还给主链时，采取类似的动作。

SPV 的魔力：

Merkle树是一种哈希二叉树，是一种用于快速归纳和验证大规模数据完整性的数据结构。 SPV 充分利用了 Merkle 树的这个特性。 SPV节点在验证交易是否存在时不保存所有交易或下载整个区块，只保存区块头。它使用认证路径或Merkle路径验证区块中是否存在交易，而无需下载所有区块头。区块中的交易

可以看出，当区块大小从 16 笔交易（4KB）急剧增加到 65,535 笔交易（16MB）时，Merkle 的搜索路径长度增长极其缓慢。 这样，只需要一个区块头结构，再加上这种搜索路径的开销，节点就可以以很小的代价快速定位到一笔交易。

区块头只有 80 字节。 按照每小时6个区块的速度btc区块数据结构，每年产出52560个区块。 仅保存区块头时，每年新增存储需求约为4兆字节，100年后累计存储需求仅为400兆字节，即使用户使用最低端的设备，正常情况下也可以完全加载。

安全

[1]：由于spv没有所有的交易记录，所以无法验证某笔交易不存在。 该漏洞将被针对 spv 节点的拒绝服务或双重支付攻击所利用。

参考这段话：在 SPV 模式下运行的钱包只能验证他们下载的区块头，而不能验证过滤器。 这使得“假阴性”攻击成为可能，为什么知道钱包正在等待特定交易的恶意节点可以向钱包发送不包含该交易的虚假过滤器，导致钱包不下载区块，因此不意识到交易的存在。

不可能出现“误报”情况。 如果恶意节点提供包含不存在交易的虚假过滤器，钱包将简单地下载完整区块，将其与过滤器进行比较，发现过滤器不是真实的。

【二】：spv节点需要随机链接多个节点，以增加连接到至少一个可靠节点的概率，但这种随机链接要求也容易受到网络分区和女巫攻击。

[3]：由于SPV不保存所有区块的节点信息，需要配合其他节点进行验证，因此SPV节点可能被诱导连接到虚假网络，存在被恶意攻击的可能。

如果客户端仅从单个完整节点下载区块链，则该完整节点将再次成为单点故障或妥协点。 这个完整的节点可以将客户端与网络的其余部分隔离开来，并为客户端提供一个错误的区块链“视图”

【4】：隐私泄露。 SPV 钱包只请求从全节点到 SPV 钱包拥有的密钥、全节点链接地址和关联交易的交易，使得比特币用户的匿名化变得微不足道。 虽然已经尝试用布隆过滤器修复 SPV 隐私，但这种尝试在很大程度上是无效的。如果交易请求不是通过 Tor 等匿名网络发送的，全节点不仅会获取与 SPV 钱包相关的具体地址通过一些手段，还可以获取到SPV钱包的IP地址