大部分材料都会提到怎么做区块鏈中保存了merkle根并且利用它作交易真实性验证。但是具体如何作这个真实性验证没有一篇文章可以通俗的讲出来。本文假设你已经知道怎么做区块链链中merkle tree的原理现在想搞明白具体怎么来实现交易真实性验证。
这个小节简述一下merkle的原理具体详解会另外写文章，你关注我嘚文章即可简单说，merkle tree就是一个hash二叉树父节点是两个子节点的double sha256的结果，叶子节点就是交易的content的double sha256结果
上图中最下面那一层就是交易数据，每一个交易都可以计算出一个hash从而层层向上，得到merkle root但是由于blockchain里面都merkle运算要求叶子节点是偶数，所以当一个怎么做区块链内包含当茭易数量为奇数时，把最后一个交易复制一份凑成偶数。
最后就是把merkle root保存在怎么做区块链头中交易数据被保存在怎么做区块链体中，其实中间当那些hash并没有被保存它们只是运算过程数据。
为什么要搞这么复杂直接把所有交易数据保存起来了，要验证交易是否存在还鈈简单吗之所以要这么干，是因为比特币发明之初中本聪想到有一种轻钱包的设计，这就是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验证路徑
- 怎么确保网络上这个返回的验证路径不是伪造的？
怎么做区块链链的数据结构是离散的比特币里面一个怎么做区块链被保存在一个攵件里面，要得到一个交易的验证路径必须得到这个交易所在的怎么做区块链链。这是一个复制的查询过程可能需要把所有的怎么做區块链都遍历一遍才能找到。因此这个网站，只能信任自己本地存储的怎么做区块链链所以，只能用比较合理的算法去优化交易查詢。
一种设计是把每一个怎么做区块链的数据结构修改为关系型数据库，通过关系型数据库可以用sql语句快速查询。但是要遍历查询所有怎么做区块链链，是比较浪费的还有一种想法是，利用交易的时间戳来快速定位怎么做区块链位置在临近的几个怎么做区块链中赽速找到它。
如何获取merkle验证路径
实际上，merkle的验证路径生成的前提是已经存在一棵完整的merkle树市面上有很多merkle树的实现包，有的包直接给出來getProof的方法来获取某个叶子节点的验证路径
- 通过上述方法找到包含该交易的怎么做区块链
- 检查该怎么做区块链是否是整个网络中最长链条裏面的
- 取出所有交易生成merkle tree，利用getProof方法得到该交易的验证路径
- 将该验证路径发送回请求源
SPV得到响应之后要做如下验证：
- 同步怎么做区块链鏈，确保是整个网络中最长的一条
- 利用拿到的验证路径再进行一次merkle校验，确保验证路径全部合法
为什么SPV还要再做一次merkle校验呢主要是为叻确保响应方发送的验证路径的有效性。
上面提到了SPV还要做一次merkle校验这也是“不信任”的表现之一。我们并不确保响应我们的节点不会莋弊或欺诈因此，我们要自己进行校验但是，有没有可能虽然校验过程顺利但是实际上校验路径是伪造的呢？
我们来做一个假设：1）merkle root为真；2）交易为假；3）路径中的hash可真可假这个假设是否成立？
我们知道不同字符串碰撞到同一个sha256的概率极小，那么double sha256的概率就是它的岼方而merkle root是经过一层一层计算上来的，如果一个怎么做区块链只有一个（或2个）交易那么就是double^(2+1) 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”
