区块哈希是什么？区块的唯一身份标识，链上区块核验原理

区块哈希是区块链里每个区块的“数字指纹”。它由区块头里的关键字段经过密码学哈希函数一次性算出，既是该区块的唯一身份标识，也是前后区块互相咬合、全网节点快速核验账本是否被篡改的核心依据。

用户可以把它想成快递单号加封条，单号唯一，封条一拆就变，谁改了区块里的交易、时间戳或其他关键字段，哈希立刻对不上，后面整条链都会跟着露馅。普通人查区块浏览器、节点同步、轻钱包校验，本质上都在核对这些哈希是不是前后一致。

区块哈希怎么算出来

哈希函数吃进去任意长度的数据，吐出固定长度的一串十六进制字符。比特币用的是双重SHA-256，结果是64个十六进制字符（256位），以太坊区块头主要用Keccak-256，长度同样是32字节，输入差一个比特，输出就面目全非，而且没法从结果反推原文，这叫单向性。

实际参与计算的不是整块交易原文，而是区块头，比特币区块头大致包括版本号、上一区块哈希、默克尔根、时间戳、难度目标（nBits）和随机数nonce，矿工不断改nonce（以及部分额外字段），直到算出的哈希满足当前难度，也就是前面有足够多的前导零。这个“撞出来”的哈希，就成了该区块的身份证。

为什么能当唯一身份

同一条链上，两个不同区块头几乎不可能算出同一个哈希，碰撞概率低到可以忽略。节点之间传区块、浏览器展示、轻客户端同步，都用这个哈希当主键，在区块浏览器里点开某个高度，地址栏或详情页上那一长串就是它。

1、全局唯一性：内容一变，哈希必变，冲突可视为不存在。

2、可快速比对：节点只存、只传固定长度的摘要，带宽和存储都省。

3、不可伪造关联：想冒充某区块，必须同时满足内容与共识规则，成本极高。

比特币创世块的哈希是000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f，至今仍是教材级例子，前导零体现了当时的工作量证明，整串则永久钉死了那一页账本。

链上核验怎么跑

核验不是只看一个哈希漂不漂亮，而是看整条链有没有被“拆开重焊”。

前后咬合

每个区块头都写着父区块哈希。节点收到新块，先算一遍本块哈希是否达标，再核对“我声称的父哈希”是不是本地已有的最新合法块。对不上，直接丢掉。于是从创世块到当前尖端，形成一条只能向前延伸、很难回头改的链条。

默克尔根管交易

区块里可能有上千笔交易，全塞进区块头不现实。于是先把交易两两哈希，层层汇总成一棵默克尔树，根哈希写进区块头。你只要拿到某笔交易的默克尔路径，就能证明“它确实在这个块里”，而不用下载整块。轻钱包、SPV类校验靠的就是这套。

难度与共识

工作量证明链（如比特币）还要求哈希低于当前目标值。权益证明链（如以太坊合并后）则用验证者签名、随机信标等替代“挖矿撞哈希”，但区块哈希作为身份与链接字段的角色没有消失。节点同步时仍会按哈希索引、按父哈希串联、按状态根核对执行结果。

核验时注意点

1、单块合法性：区块头哈希是否达标、时间戳是否在合理窗口、签名或工作量是否有效。对不上就孤立或直接拒绝。

2、链接完整性：声称的父哈希是否等于本地已有的父块，对不上就分叉或丢弃。

3、交易包含性：默克尔根与提供的证明路径是否匹配。对不上证明就无效。

4、状态一致性：状态根、收据根等是否与执行结果一致。对不上执行层就判定无效。

日常会碰到的场景

查一笔转账是否上链，浏览器会显示所在区块的哈希和确认数。确认数本质是在这个哈希后面，又连上了多少个被全网接受的新块，后面盖得越多，想回滚改你这笔，就要重写整段链条并追上全网算力或共识权重，代价陡增。

自己跑全节点时，初始同步就是从可信的创世哈希出发，一块块验父哈希、验工作量或签名、验默克尔与状态。轻客户端则多半只拉区块头链，再用默克尔证明抽查交易。跨链桥、交易所入账、浏览器API，底层也在比对这些哈希字符串是否一致。

常见问题

区块哈希会重复吗？

在现有密码学假设和链的设计下，实际运行中可视为不会。一旦真发生可用碰撞，整条依赖该哈希算法的安全模型都要重估，那是算法级事件，不是日常运维问题。

改了历史交易，只重算一个块行不行？

不行。改一笔交易会改默克尔根，块哈希变了，后面所有块的“父哈希”全对不上，必须整段重做并超过原链的共识权重。这也是“越久远的确认越难推翻”的直接原因。