区块链轻节点和SPV

参考:
https://blog.csdn.net/qq_25870633/article/details/81980376
https://www.cnblogs.com/gzhlt/p/10271849.html

为什么会有SPV:

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

比特币网络里的节点在打包一个区块的时候,会对区块里所有的交易进行验证,并且,一个交易还会得到6至7次区块的确认来确保交易最后的完成。正是如此,在使用简单支付验证时,只要判断出一个交易在主链上的某个区块里出现过,则可以证明该交易之前已被验证过。

【注意】:

这里有个细节需要注意,SPV指的是“支付验证“,而不是“交易验证”。这两种验证有很大区别。
"交易验证”非常复杂,涉及到验证是否有足够余额可供支出、是否存在双花、脚本能否通过等等,通常由运行完全节点的矿工来完成。
“支付验证”则比较简单,只判断用于“支付”的那笔交易是否已经被验证过,并得到了多少的算力保护(多少确认数)。

简单的说,交易验证就是要检验这个交易是否合法;支付验证就是验证这笔交易是否已经存在

【考虑这样一种情况】:SPV的目标是验证某个支付是否真实存在,并得到了多少个确认

A收到来自B的一个通知,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 condition 符合的话,他就会用 merkleblock 消息给该SPV节点发送一个 区块;【merkleblock:包含了 BlockHead 和一个连接到该 TX 的Markle Root 的一个Markle 路径】;SPV 节点可以利用该markle路径把TX和包含TX的区块联系起来,并用BlockHead来校验包含该TX的Block是在BlockChiain上的且已经过了6个确认的。这两个验证可以证明该TX是存在于区块链上的。

总之SPV只需要接收小鱼 1KB的BlockHead 和 markle 路径数据

spv 校验过程:

  1. 从网络上获取并保存最长链的所有block header至本地;
  2. 计算该交易的hash值tx_hash;
  3. 定位到包含该tx_hash所在的区块,验证block header是否包含在已知 的最长链中;
  4. 从区块中获取构建merkle tree所需的hash值;
  5. 根据这些hash值计算merkle_root_hash;
  6. 若计算结果与block header中的merkle_root_hash相等,则交易真实存 在。
  7. 根据该block header所处的位置,确定该交易已经得到多少个确认。

【简单的讲,其实SPV就做了两件事】:

1、找到要验证的这笔交易在哪个区块;

2、确定这个交易是否被6次确认过了。
在这里插入图片描述
比方说想验证上面的H(K)交易是否支付完成:
首先,节点从网络上获取需要验证的交易的认证路径,在节点上生成对应的一个路径,该路径的值就是图中蓝色标示的节点。在路径确认的情况下,节点只需要计算H(KL)、H(IJKL)、H(IJKLMNOP),H(ABCDEFGHIJKLMNOP)的两次hash值,这样得到的一个merkle根的副本。前面讲过spv节点保存了整个区块链的所有去块头,所以只要拿这个副本和去块头中的merkle根比较。如果存在就能证明该交易支付成功。

SPV的使用场景:

1、轻钱包中的支付校验

2、侧链的双向挂钩中,主链和侧链需要通过对某笔特定的交易做SPV验证,以确保该笔交易确实发生过支付,好使得一方锁定资产,一方转移资产

如:(比特币的侧链)

a】当用户要想侧链转移BTC时,首先在主链上创建一笔交易【一笔特殊的交易】,待转移的BTC被发往一个特殊的输出,这些BTC在主链上被锁定。

b】 等待一段确认其,使得上述交易获得足够的工作量确认 【如: 6个确认】

c】 用户在侧链中也创建交易来提取BTC 【其实严格来说这时候在侧链中不能是BTC了,而是比例兑换的侧链的token】,需要在这笔交易的输入指明 上述主链被锁定的输出,并提供足够的SPV证明。

d】等待一段竞争期,防止双花

e】BTC就这样在侧链上流通了 【严格来说应该是比例兑换的侧链token】

f】当用户想让BTC返回主链时,采用类似的动作。<现在侧链创建交易,待返回的BTC【侧链的token】被发往一个特殊输出,等待一段时间确认期后,在主链用足够的对侧链输出的SPV证明来解锁最早被锁定的输出。等待一段竞争期,珠帘的BTC被解锁,恢复流通>

SPV的神奇:

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

可以看出,当区块大小由16笔交易(4KB)急剧增加至65,535笔交易(16MB)时,Merkle的搜索路径长度增长却极其缓慢。这样一来,只需要一个区块头部结构,再加一个这样的搜索路径的开销,一个节点就能花费很小的代价快速定位一个交易。

区块头部只有80字节。按照每小时6个的出块速度,每年产出52560个区块。当只保存区块头部时,每年新增的存储需求约为4兆字节,100年后累计的存储需求仅为400兆,即使用户使用的是最低端的设备,正常情况下也完全能够负载。

安全性

【一】:spv由于没有全部的交易记录,不能验证某个交易不存在,这个漏洞会被针对spv节点的拒绝服务或者双重支付攻击利用。
参考这段话:Wallets operating in SPV mode are only able to validate the block headers they download and not the filters. This makes a “false-negative” attack possible, whereby a malicious peer that knows a wallet is waiting for a particular transaction could send the wallet a fake filter which does not include the transaction, resulting in the wallet not downloading the block and so not becoming aware of the transactions existence.
A “false-positive” scenario is not possible. If a malicious node provides a fake filter which includes a non-existent transaction, the wallet will simply download the full block, compare it to the filter and discover that the filter is not genuine.
【二】:spv节点需要随机链接多个节点,增加与至少一个可靠节点相连接的概率,但是这种随机链接的需求也会容易受到网络分区和sybil攻击。
【三】:SPV因为没有保存全部区块的节点信息,需要和其他节点配合才能进行验证,所以SPV节点存在被诱导连入了一个虚假的网络中的情况,存在被恶意攻击的可能。
如果客户端仅从单个完整节点下载区块链,则该完整节点将再次成为单点故障或危害。这个完整的节点可以将客户端与网络的其余部分隔离开来,并向客户端提供区块链的虚假“视图”
【四】:隐私泄漏。SPV钱包仅向SPV钱包拥有的密钥请求来自完整节点的交易,整个节点链接地址和关联交易,使得比特币用户的匿名化变得微不足道。虽然已经尝试用Bloom过滤器来修复SPV隐私,但这种尝试在很大程度上是无效的。如果没有通过诸如Tor的匿名网络发送交易请求,则完整节点不仅会通过一些方式得到SPV钱包相关的特定地址,还会得到SPV钱包的IP地址

猜你喜欢

转载自blog.csdn.net/weixin_43927408/article/details/90414574
0条评论
添加一条新回复