比特币原理分析（二）如何证明交易的真实性

如何证明交易的真实性？

比特币网络中的交易只有在被记录在区块链中并且已经收到 6 次确认时才被认为是真实的比特币交易记录查询，并且只有基于这些真实交易（输入和输出的概念）发起的新交易才是合法的。

我们询问交易是否真实，通常基于以下前提：

那么对于 SPV 轻钱包，如何知道交易是否真实？ SPV 拿到一笔交易信息（比如收到一笔钱）后，无法确认交易是否合法，所以必须验证交易的输入。但是，它只获取单个交易的信息，并没有完整的本地区块链数据。因此，SPV 需要利用该交易的信息向网络发起查询请求，称为默克尔区块消息。当其他拥有完整区块链数据的客户端收到此请求时，它们会使用传输的交易信息在自己的区块链数据库中进行查询，并将验证路径返回给请求源。 SPV拿到验证路径后，再做一次merkle check，确认无误后，认为交易可信。

现在的问题是：

检查来自区块链的交易

区块链的数据结构是离散的。比特币中的一个块存储在一个文件中。要获得一笔交易的验证路径，必须先获得交易所在的区块链。这是一个复制查询过程，可能需要遍历所有块才能找到它们。因此，blockchain.info等网站应运而生，帮助您通过一条信息查询区块链上所有相关信息的记录。但是对于客户端来说，就不是那么容易了，它不能信任 blockchain.info 网站，它只能信任自己本地存储的区块链。因此，只有合理的算法才能优化交易查询。

一种设计是将每个block的数据结构修改成一个关系型数据库，通过它可以使用SQL语句进行快速查询。但是，遍历和查询所有区块链是很浪费的。另一种思路是利用交易的时间戳快速定位区块位置，在接下来的几个区块中快速找到。

如何获取merkle验证路径？

实际上，merkle 的验证路径生成的前提是已经存在完整的 merkle 树。市面上有很多merkle树的实现包，有的包直接给出getProof方法来获取叶子节点的验证路径。

客户端收到默克尔区块消息后，执行以下步骤：

通过上述方法找到包含该交易的区块。检查该块是否是整个网络中最长的链。取出所有交易生成默克尔树，并使用getProof方法获取交易的验证路径，并将验证路径发送回请求。来源

SPV 收到响应后，验证以下内容：

同步区块链，确保它是全网最长的一条。首先获取 merkle root 在区块链中搜索，确保 merkle root hash 是链中得到的验证路径，然后再次进行 merkle check。验证验证路径是否合法

为什么 SPV 必须进行另一次 merkle 检查？主要是保证响应者发送的验证路径的有效性。

确保验证路径的真实性

上面提到SPV也需要做merkle check，这也是“不信任”的表现之一。我们不保证响应我们的节点不会作弊或作弊，所以我们自己进行验证。但是，有没有可能验证过程虽然顺利，但验证路径实际上是假的？

让我们做一个假设：1）merkle root 为真； 2）事务为假； 3）路径中的哈希可以是真也可以是假。这个假设成立吗？

我们知道不同字符串碰撞同一个sha256的概率极小，那么双sha256的概率就是它的平方，逐层计算merkle根，如果一个block只有一个（或2个）交易，那么就是double^(2+1) sha256，如果是4个交易比特币交易记录查询，就是double^(4 + 2 + 1) sha256，更何况一个区块这么多一笔交易几乎不可能通过merkle操作得到相同的hash，因此在merkle验证中使用虚假的交易hash是不可能得到已知的merkle root的。

如果要进一步验证，可以将打包在区块中的交易数量存储在区块头中，这样就可以知道从交易哈希到默克尔根需要多少层操作。这也是一个检查点。