分享

更多

   

比特币源码情景分析之SPV钱包轻量级钱包

2018-06-15  quasiceo


创建账号


        这个过程不涉及到数据同步,因而全节点钱包和SPV节点都能比较容易实现,因而一般的SPV钱包都支持这个功能,只是性能可能有所不同。因为创建账号涉及加解密的算法过程,需要一定的计算资源,有些SPV钱包使用脚本解释语言比如nodejs实现,导致效率不够,创建一个钱包可能需要10多秒

接收并验证交易


    如果钱包将所有区块数据同步到本地了,验证交易很容易,只需要查找本地数据是否存在该交易即可。既然是轻量级钱包,肯定不能下载所有区块数据了。因为比特币完整区块数据目前已经几十个G,运行轻量级钱包的移动设备不可能花费这么大的空间来存储,同时移动设备带宽有限,下载这么多数据时间和费用成本也很高。那怎么解决呢?有两种方案:
        1.服务器解决方案,服务器运行全节点钱包,SPV钱包通过web api让服务器验证
        2.只拉取区块头(blockheader),我们知道区块由区块头和区块交易数据构成,区块头很小的,目前总共才几M。那只有区块头,怎么验证一个交易是否存在呢?这就要通过merkle tree来验证。blockheader里的merkleroot包含了交易数据的merkletree, 只需要merkleroot+交易数据+partialmerklepath即可验证一笔交易是否存在某个区块

发起交易和显示交易历史


    我们知道比特币是utxos系统,发起交易必须选择属于你的还未花的utxo(交易输出)作为输入,这样就存在一个问题,spv钱包必须收集用户所有未用的utxos。由于utxos储存在区块交易内容里,所以要获取utxos,就必须同步区块内容。因而为了支持发起交易,spv钱包有如下几种方案
        1.服务器解决方案,服务器运行全节点钱包,同步区块,并建立账号-utxos map表,spv钱包通过简单的web api让服务器帮忙发起交易,由于发起交易需要使用私钥,为了避免向服务器暴露私钥,可以将构建交易的部分放在spv实现,服务器只提供utxos,即步骤为:spv向服务器请求合适的utoxs, 本地组装交易,将组装好的交易数据发送給服务器,服务器广播交易
       2.spv钱包同步区块数据内容,但是只是临时使用,只是解释出其中属于用户的utxos, 而不真正保存,这就解决存储空间问题,但是同步过程中的带宽问题还是没有解决 .--prune参数就是实现这个功能的
      3. spv钱包同步区块内容带宽解决方案---bloom filter(布隆过滤器)
            其工作机制是,spv钱包同步区块内容时可以增加一个地址过滤器,这样全节点在返回区块内容前,先将区块里面的交易和filter比较,只有满足filter的交易才会被发回spv节点,这样真正发回到spv钱包的数据量就非常少了.比如可以添加pubkey(钱包地址)filter,这样只有和特定地址相关的交易才会返回给spv钱包,这些交易就包含钱包想要的用户的utxos

 挖矿


        挖矿是一个很费资源(cpu, memory)的活,SPV是面向普通用户的,一般都不会也没法支持

总结

    SPV钱包最理想的实现方案是,服务器是全节点,SPV钱包通过服务器验证和发起交易,查询交易历史,本地做交易封装,即signRawTransaction和用户交互。SPV节点不需要运行bitcoin core代码,由于需要监听先的交易事件,需要服务器通过JPush类似的机制主动通知SPV钱包新的交易等事件。同时由于交互一般不太复杂,推荐用react native框架搭建, 可以快速实现ios/android同时开发,且性能也很不错。
    其次方案是:本地只保存区块头,通过bloom filter获取钱包用户的utxos交易历史, 需要SPV钱包运行完整的bitcoin core
 


    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。如发现有害或侵权内容,请点击这里 或 拨打24小时举报电话:4000070609 与我们联系。

    猜你喜欢
    发表评论评论公约
    喜欢该文的人也喜欢 更多