企业网站优化怎么做,哪个网站可以免费建站啊免费建网站,怎样做视频直播网站,个人建站流程详解转载自#xff1a;https://www.tangshuang.net/4117.html
本文假设你已经知道区块链中merkle tree的原理#xff0c;现在搞明白具体怎么来实现交易真实性验证。
Merkle Tree
这个小节简述一下merkle的原理。简单说#xff0c;merkle tree就是一个hash二叉树#xff0c;父…转载自https://www.tangshuang.net/4117.html
本文假设你已经知道区块链中merkle tree的原理现在搞明白具体怎么来实现交易真实性验证。
Merkle Tree
这个小节简述一下merkle的原理。简单说merkle tree就是一个hash二叉树父节点是两个子节点的double sha256的结果叶子节点就是交易的content的double sha256结果。 上图中最下面那一层就是交易数据每一个交易都可以计算出一个hash从而层层向上得到merkle root。但是由于blockchain里面都merkle运算要求叶子节点是偶数所以当一个区块内包含当交易数量为奇数时把最后一个交易复制一份凑成偶数。
最后就是把merkle root保存在区块头中交易数据被保存在区块体中其实中间当那些hash并没有被保存它们只是运算过程数据。
SPV
为什么要搞这么复杂直接把所有交易数据保存起来了要验证交易是否存在还不简单吗之所以要这么干是因为比特币发明之初中本聪想到有一种轻钱包的设计这就是SPV简化支付验证Simplified Payment Verification。
轻钱包并不保存完整的区块链而是只保存每一个区块的区块头。区块体保存了完整的交易信息而交易信息需要的存储量大部分都是交易头的千倍以上。所以如果只保存交易头就可以极大的减少本地客户端存储的区块链信息。
但是不能因此让区块链无法工作啊。如果这个时候轻钱包要对某一个交易进行验证而本地又没有这个交易的信息那怎么验证呢这时区块头里面的merkle root就要起作用了。
验证路径
在讲述轻钱包的验证过程之前我们需要知道如何在merkle tree里面做验证。我们已知merkle tree里面父节点和子节点的运算关系因此当我们要证明一个叶子节点存在于这棵树时只需要得到从该叶子节点到根的运算过程里面需要的那些hash即可并不需要所有叶子节点参与计算。 你可能觉得有点奇怪为什么不直接把所有的叶子节点告诉它就行了你用所有叶子节点能算出root hash就验证通过了。但事实就是这样因为每一个父节点hash一定是由两个子节点hash运算得到所以我们只需要挑选出所有参与运算的节点就可以证明这个叶子节点存在于树中。这样可以减少hash运算的次数。而这些被挑选出来的节点以及它们之间的层级关系就是验证路径即上图中merkle root那个盒子下面的所有盒子。
如何证明交易的真实性
比特币网络中的交易只有已经被记录到区块链并且已经得到6个确认的才被认为是真实的只有基于这些真实交易发起的新交易输入与输出的概念才是合法的。
我们询问一个交易是否真实往往基于以下前提
我们在问一个交易是否已被记录到区块链中而且这个交易所在的区块链是最长的哪一条没有在分叉链上当每个节点接收到一条交易广播时我们要查询作为一笔新交易的输入的真实性矿工对交易进行打包之前对所有的输入进行真实性验证在矿工接收到交易信息时就已经验证过了打包的时候验证2000条交易信息不可能
那么对于SPV轻钱包而言怎么知道一个交易是否真实的呢SPV拿到一个交易信息之后比如接收到一笔钱并不能确认这个交易是否合法因此要对这个交易的输入进行验证。但是它只拿到了单个交易的信息而没有本地的完整区块链数据因此SPV要拿着这个交易的信息向网络发起查询请求这个请求被称为merkle block message。当其他有完整区块链数据的客户端收到这个请求之后利用传过来的交易信息在自己的区块链数据库中进行查询并把验证路径返回给请求源SPV拿到验证路径之后再做一次merkle校验确认无误之后就认为这个交易是可信的。
现在的问题是
怎么从区块链里面查一个交易怎么获取merkle验证路径怎么确保网络上这个返回的验证路径不是伪造的
从区块链查交易
区块链的数据结构是离散的比特币里面一个区块被保存在一个文件里面要得到一个交易的验证路径必须得到这个交易所在的区块链。这是一个复制的查询过程可能需要把所有的区块都遍历一遍才能找到。因此blockchain.info这样的网站孕育而生帮助你通过一个信息查这个信息在区块链上的所有相关记录。但是对于客户端而言可没那么容易它不能信任blockchain.info这个网站只能信任自己本地存储的区块链。所以只能用比较合理的算法去优化交易查询。
一种设计是把每一个区块的数据结构修改为关系型数据库通过关系型数据库可以用sql语句快速查询。但是要遍历查询所有区块链是比较浪费的。还有一种想法是利用交易的时间戳来快速定位区块位置在临近的几个区块中快速找到它。
如何获取merkle验证路径
实际上merkle的验证路径生成的前提是已经存在一棵完整的merkle树。市面上有很多merkle树的实现包有的包直接给出来getProof的方法来获取某个叶子节点的验证路径。
在客户端收到merkle block message之后要执行下面的步骤
通过上述方法找到包含该交易的区块检查该区块是否是整个网络中最长链条里面的取出所有交易生成merkle tree利用getProof方法得到该交易的验证路径将该验证路径发送回请求源
SPV得到响应之后要做如下验证
同步区块链确保是整个网络中最长的一条先拿到merkle root去区块链中查找确保该merkle root hash是在链条中利用拿到的验证路径再进行一次merkle校验确保验证路径全部合法
为什么SPV还要再做一次merkle校验呢主要是为了确保响应方发送的验证路径的有效性。
确保验证路径的真实性
上面提到了SPV还要做一次merkle校验这也是“不信任”的表现之一。我们并不确保响应我们的节点不会作弊或欺诈因此我们要自己进行校验。但是有没有可能虽然校验过程顺利但是实际上校验路径是伪造的呢
我们来做一个假设1merkle root为真2交易为假3路径中的hash可真可假。这个假设是否成立
我们知道不同字符串碰撞到同一个sha256的概率极小那么double sha256的概率就是它的平方而merkle root是经过一层一层计算上来的如果一个区块只有一个或2个交易那么就是double^(21) sha256而如果是4个交易就有double^(4 2 1) sha256更何况一个区块有那么多交易要经过merkle运算得到一个相同的hash几乎是不可能的因此在merkle验证中用一个伪造的交易hash来得到一个已知来merkle root是不可能的。
如果还想更进一步校验可以在区块头中存储区块打包的交易的数量这样就可以知道从交易hash到merkle root需要经过几层的运算。这也是一个检验点。
小结
merkle tree被广泛运用于区块链中但并不是只有区块链使用它来进行校验。比如一些p2p下载如迅雷就需要把文件分割为小块文件每块都有一个hash每块从不同的网络节点下载最后组成一个完整的文件但是也需要进行hash验证它也可以使用merkle来进行验证。merkle tree也不一定是二叉树可以是任意树结构。而在以太坊中merkle验证还不够用增加了Patricia Tree验证合起来称为“Merkle Patricia Tree”。
