[7. 回收磁盘空间]
To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash.
[译] 为了优化它（节省空间），并且不会打乱区块的哈希，交易被哈希到一个默克尔树上，默克尔树的根保留在区块的哈希中。
[注] 什么是默克尔树？
默克尔树是一种哈希值组成的二叉树。例如下图中，将所有的交易（图中有四比交易：TX0到TX3），先将这些交易进行哈希，得到对应的哈希值HASH0到HASH3。如果将这四个哈希值合并再进行哈希，则就是HASH LIST。HASH LIST是一种高度为2的特殊的默克尔树。这里的默克尔树是将HASH0到HASH3每两个进行哈希，得到HASH01和HASH23，最后重复这个步骤，最终得到一个哈希值（这里可以认为是HASH0123，对应图中为Root Hash）。
比特币的默克尔树
区块头中保留的是默克尔树的根。这样就可以验证交易。例如，全节点在下载一个区块之后。对区块中的交易进行计算默克尔树，得到区块中交易的默克尔树的根，再与区块头的默克尔树的根进行比较。如果相同，则说明下载的交易记录正确，如果不同，则说明下载的交易记录存在错误。这个有点类似于通信中数据包使用的CRC校验，不过复杂度远比CRC校验大。
这里如果发现下载的数据不正确，还可以再通过下载叶子节点来进一步确定是哪一个交易是错误的。而CRC交易或者HASH LIST是无法做到的，他们只能判断这个下载的整体上是不是正确的。
A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year.
[译] 一个不包含交易的区块的头大约有80 bytes. 我们设定每10分钟产生一个区块，那么，80 bytes * 6 * 24 * 365 = 4.2MB每年。
[注] 这里讲的是区块头，区块头的空间较小。而区块由于包含交易，所以占用的空间很大。并且同样的空间内，由于交易信息的格式问题，一个区块放不了多少笔交易，所以，才有后面的扩容问题。
[8. 简化支付验证]
It is possible to verify payments without running a full network node.
[译] 在不运行一个全网络节点的情况下，仍然可以进行支付验证。
[注] 一般来说，矿工、交易所等会维持一个全节点，矿工进行挖矿，交易所进行频繁的转入转出数字货币。而目前比较流行的手机端钱包无法运行一个网络全节点。因为交易的大量累积，其占据的硬盘空间很大，不利于手机上进行存储（虽然手机的存储越来越大，但大多被自己的照片、视频等占据）。并且手机来存储全节点也没有必要。那么一个手机钱包（轻客户端）如何进行交易验证呢？
He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
[译] 它无法自己检验这笔交易，但是可以通过查找这笔交易在区块链中的哪个区块中，它可以看到有某个网络节点接收了这笔交易，并且这个区块后面的所有区块都在这个区块后面添加区块（添加区块之前会对前面的区块进行验证），所以说明整个网络是接收这笔交易的。
手机钱包（轻客户端）可以仅下载区块链的区块头，即第七节中描述的每个区块中的80byte的数据块。每个区块头如下包含五个元素：
上一区块头的哈希值（图中的Prev Hash）
时间戳
挖矿难度值
工作量证明随机数（图中的nonce）
该区块交易对应的Merkle Tree的根（图中的Root Hash）
如果手机钱包要确认一个交易的状态，它需要发起Merkle proof请求：该请求会查找这个交易在哪个区块中（通过Merkle Tree检索的方法）。进一步判断后面有了多少次的确认。一般认为，经过6次确认，交易就是安全的、不可更改的。
网友评论