虾说区块链-基础篇-13

一直在说区块链是一系列技术结合后的新的技术架构，那么这里分别介绍下这些相关技术，也涉及到一些扩展开去的相关内容。

 

相关技术-merkle tree：

区块链学习中经常会出现一些词汇，之前介绍过一些SPV、POS、RSA等，这里介绍下merkle tree。Merkle tree其实在网上也有很多资料介绍说明，这里大致对merkle tree做一个简单的归纳整理。

Merkle tree中文叫做梅克尔树，这当然不是一棵真正的植物树，merkle tree是计算机数据结构中的一种树，是由计算机科学家 Ralph Merkle 提出的，并以他本人的名字来命名。

 

Merkle tree是数据结构中的一种树结构，可以是二叉树，也可以是多叉树，他和数据结构中树的特点几乎一致，和普通树不同的是：merkle tree上的叶节点存放hash计算后的hash值，非叶节点是其对应的子节点串联的字符串的hash值。上图可知：hash0=hash0-0+hash0-1。中本聪在比特币系统中很好的运用了merkle tree树，现在的以太坊也使用该模式来做区块链系统中的验证互联。

在维基上对merkle tree解释：

 

 

在具体介绍merkle tree之前先明确两个概念：

HASH：hash运算一直出现在区块链的介绍文章中，这个技术其实在互联网中一直被广泛应用，一段数据经过hash运算后生成一段密文哈希值，在网络环境中把这个hash值作为一段数据校验，我们在网络上下载文件的时候，把数据文件下载到本地，然后运算hash，如果和之前的hash值一致，那么就说明这个下载文件在网络传输下载过程中并没有损坏和篡改，保证数据一致。Hash算法保证了，一旦黑客或者恶意操作的人对源头数据作任何一点点的修改就会导致整个hash值会出现较大不一样。从而使用这种方式验证数据完整性和安全性还是十分有效的。

 

HASH LIST：结合上图hash算法后，一组数据生成一组hash值。在我们常用的P2P下载软件中，数据通过网络中节点之间互相通讯的方式传输，很多人认为在传输过程中只是一个文件，事实上很多数据文件都会进行一个切割，然后生成一个hash list，一个数据被分割后传输，一旦出现一个或者多个数据被篡改，那么结合hash list就可验证那几个数据块是有问题的，即可选择有问题的数据块重新下载即可。这里涌入一个hash root的概念，在区块链中有merkle hash root值。这个数据值就是拼凑在一起的hash值，通过hash root，我们可以通过事先获知hash root，然后结合hash list计算，逐步校验每一块的hash值并进行组合，组合值和hash root比较，一致就说明数据块是没有问题的，这种方式更好的运用在实际的网络数据传输中。

 

 

Merkle tree：之前的hash list中如果深入思考下，在网络传输中分切很多数据块后，你获得了正确的hash root，那么你必须要获得素有的块hash值才能去组合计算，并和正确的hash root比较，那么这样会导致整个效率问题。Merkle tree的机制就是通过树结构，不需要全部获取块hash值，也可验证。大致说明下原理：

 

这是一个merkle tree，根节点为root值，hash7+hash8生成hash3，hash3+hash4生成hash1。以此类推。简单结合实际网络中应用。Hash（7...14）是一个数据的切块hash值，每一对值生成上一层的hash，也就是hash（3...6），然后生成hash1和hash2，最后hash1+hash2结合后生成merkle root。这种方式在网络中验证恶意或者篡改数据块，事前先有准备的merkle root，这里假设7是恶意节点：

首先比对 merkle tree root，发现不一致。

比对：hash1和hash2，那么可以得知hash2一致，hash1不一致。

比对：hash3和hash4，那么可以得知hash4一致，hash3不一致。

比对：hash7和hash8，那么hash7不一致。

 

 

在验证恶意节点的时候，上面举例红色节点和hash2，经过这些验证即可，那么hash7很快就被找出来了，这种检索的效率理论上为：Log(N)

结合区块链，在比特币系统的使用就是merkle tree root证明，了解比特币的知道，区块链中的区块分为区块头和区块数据。区块头中：上一区块头的hash值、时间戳、难度值、nonce、merkle tree root值。结合笔者前文SPV认证。可以让节点只下载区块头，然后通过merkle tree原理做支付验证。

 

 

在以太坊中，一个区块头中，包含三个merkle tree，分为交易、收据（receipts）、状态。三种状态树支持以下查询操作：这笔交易是否包含在特定的区块中，查询某地址在过去一段时间内，发出某类型事件的所有实例，当前余额，账户真实存在性，合约的假设性运行结果模拟。

 

SPV（Simplified Payment Verification）：

SPV简单支付验证（Simplified Payment Verification），这个概念出现其实很简单，以比特币为例子，目前节点如果存储完整的区块链数据那么有几百G，一般的个人终端上无法满足这个量级的存储空间，而且这个数据量还会一直增加，那么针对个人的终端需要一种简单的验证模式，相应就出现了SPV，比如MultiBit这种轻量级钱包用的就是SPV模式。

 

 

SPV简单支付验证，在SPV节点不保存全部的区块链数据，只保存区块头的数据，这样的话大小应该是全部数据的千分之一，对整个存储的容量要求就小多了，这种节点一般也称为SPV客户端或者轻量级客户端。存储区块头信息理解区块链结构的可能了解，这种模式无法验证全部交易，但是能验证支付，所谓验证支付就是通过区块头的HASH信息去验证这笔支付是否被确认，根据区块的深度，获知这个支付是否被支付确认。如果是交易验证，那么就涉及到了很复杂的过程，包括需要知道是否有足够余额，是否存在双花情况、脚本运行情况等，这些交易验证一般都有运行全部区块链数据的节点去验证。

举个例子：A和B进行交易，在全数据库节点，通过回溯从当前区块到创世区块，链接后查询UTXO数据库，检查交易是否有被支付，验证交易的有效性。但是在SPV节点UTXO是无法验证是否支付，SPV节点通过查询区块间的梅克尔树路径，然后在当前区块等待之后6个区块的生成的，确保交易被确认，这种方式能证明这个交易不是双重支付。

 

 

具体再说明下整个验证过程：

当SPV节点收到一个交易请求，其实节点是无法证实对端节点的可靠性的，那么在一个交易发起过程中，一般会包括对端节点的支付UTXO、对端节点的签名、交易金额、SPV节点的地址。SPV节点验证通过支付验证，检查区块头信息来确认发生这个交易的是否在区块链中，并且在当前的区块链系统中有多少区块进行确认。这里啰嗦下区块头，区块头中包括prev_block_hash和merkle_root_hash这两个最为重要的验证值。

SPV节点通过getheaders从相邻的全数据节点获得区块头信息（这里涉及一个问题，SPV对特定的几个交易选择读取，无疑会透露钱包地址信息）

计算当前交易的HASH值。

用计算后后的HASH值，去比对定位block head，确定是否存在目前的最长一条链接上。

从区块中获取构建merkle tree 所需的hash值，并计算merkle_root_hash

计算结果如果一致说明交易真实存在。

根据block header来确认有多少区块确认交易。

 

SPV的由于数据量的精简，一旦去请求全数据区块头信息的时候，会出现全节点的恶意发送或者节点拒绝服务，那么这时候就要求与多节点交互保证节点诚实数据可靠。另一方面你SPV节点去请求也会不可避免的暴露自身的地址，这需要对匿名隐私上有一定的考虑。

Bloom filter：bloom过滤器解决了客户端检索的问题，原理是Bloom filter可以快速判断出某检索值一定不存在于某个指定的集合，从而可以过滤掉大量无关数据，减少客户端不必要的下载量。这样的节点可以为去中心化方式SPV查询提供必要的支持。从而从安全性上得到一定的保证。

来源：

来源：中币网  https://www.zhongbi.net/news/jishu/2116.html
声明：登载此文仅出于分享区块链知识，并不意味着赞同其观点或证实其描述。文章内容仅供参考，不构成投资建议。投资者据此操作，风险自担。 此文如侵犯到您的合法权益，请联系我们3111859717@qq.com，我们将第一时间处理。