默克尔树

默克尔树用一个根哈希承诺有序数据，并在无需传输完整数据集的情况下提供紧凑的包含证明。

仅供教育用途；不构成投资建议。投资可能导致损失。

直接回答

默克尔树把每条数据哈希成叶子，反复合并相邻哈希，得到一个顶层默克尔根。根哈希是对叶子以及建树时采用的顺序和哈希规则的紧凑承诺。

默克尔证明为一片叶子提供每一层的兄弟哈希。验证者从叶子重新计算到根，只有结果与可信根匹配时才接受包含关系。因此验证者不需要其他叶子或完整数据集。

这种承诺针对的是数据表示，而不是真实性。根匹配并不能说明源数据准确、数据仍然可用，或合约、桥、预言机和市场安全。验证者必须通过经过认证的协议获得根和叶子，并理解域分离、排序和奇数叶处理规则。

默克尔树存在于多种设计中。比特币把区块交易的默克尔根放入每个区块头；以太坊则用修改版默克尔-帕特里夏树表示状态及其他可认证结构。它们共享构造思想，但编码、证明格式、更新规则和安全假设不同，证明不能互换。

系统首先定义确定性的叶子编码和哈希函数，然后哈希每片叶子，将成对的子节点哈希成父节点，重复直到只剩一个根。当验证者无法从协议推断位置时，证明还必须包含叶子位置或方向信息。

对于平衡二叉树，1024 片叶子中的一片约需 10 个兄弟哈希，因为每层覆盖范围都会加倍。实际大小还取决于树形、哈希长度、重复叶子策略，以及是否使用多重证明或压缩格式。

核心关系可以写成 parent = Hash(left || right) 和 root = fold(parent, leaves)。这只是示意：协议可能为叶子和内部节点加入前缀、使用不同分支数，或在字典树中编码键。证明说明数据符合指定构造，但不能让一个未经独立信任的根获得认证。

在区块链中，根由区块头、状态记录或合约承诺。轻客户端或应用可以请求叶子及其认证路径，重新计算根，然后应用协议的确认、最终性、新鲜度和可用性规则。哈希验证不能替代这些规则。

假设一个区块包含 1024 笔交易，并使用二叉交易树。一笔交易可以附带约 10 个兄弟哈希，而不是传输其余 1023 笔交易。验证者仍需要相关区块头，以及交易编码和定位规则。

如果证明失败，应先检查叶子字节、字节序、树填充、根的来源和区块状态，再判断交易不存在。针对未最终确定或过时根的有效证明，在技术上可能正确，却不再代表规范链状态。

对于显示余额或奖励的应用，应把证明有效性与经济结果分开。显示金额仍可能受手续费、价格变化、滑点、合约权限、提现限额或数据源不可用影响。默克尔证明验证的是承诺中的成员关系，不保证可赎回金额。

主要技术风险包括编码含义不明确、误用哈希函数、二次原像或碰撞弱点、兄弟节点顺序错误，以及接受来自不可信或过时来源的根。叶子与内部节点之间的域分离有助于避免结构歧义，但必须一致实现。

运行风险位于哈希计算之外。桥、预言机、排序器、交易所或合约管理员可能发布、延迟、审查或替换根；数据可用性故障可能阻止用户获得叶子或证明；链重组也可能使绑定在旧区块上的证明失效。

依赖证明前，应确认谁认证根、如何检查新鲜度和最终性、如何处理缺失或奇数叶，以及用户能否独立恢复数据。当错误根、签名者被攻破、数据不可用或协议升级造成的损失无法界定时，应限制授权和暴露金额。

它只证明所给叶子在指定构造下与承诺根一致。如果预言机或运营者提交了错误值，证明仍会忠实地验证这个错误值。

验证者仍需信任哈希函数、编码规则、根的认证路径以及提供数据的系统。共识、最终性、可用性和治理仍是独立的安全问题。

比特币交易树、以太坊修改版默克尔-帕特里夏树和应用专用树在布局及证明规则上不同。不能假设一个协议的证明格式适用于另一个协议。

证明尺寸能减少数据传输，但验证 gas、存储读取、网络拥堵、合约漏洞以及提现或清算风险仍可能主导结果。