溯源哈希是什么：铸造前立字据、开售后对账的验证法

盲盒铸造最怕一句话：图已经抽完了，但顺序是不是原来那套？溯源哈希就是为这个问题设计的对账工具。它的思路属于密码学里经典的承诺与揭示：先公开一个无法反悔的指纹，再在事后公布原始材料，任何人都能检查两者是否吻合。

具体步骤通常有四步。第一步，发行方在合约部署前准备好全部美术图与元数据，并固定一个排列顺序，把这串顺序信息压缩成一个哈希值。做法可以是对文件名序列依次拼接后取散列，也可以把每张图的散列按顺序串起来再取散列，各家模板不同。第二步，把这个值作为构造参数或初始化函数参数写入合约，常见字段名就是 provenance 或 provenanceHash，写入后多数实现不允许修改，或只允许在铸造开始前修改一次。此时美术图还没公开，买家已经拿到一个”立了字据”的指纹：发行方此刻若临时换序，重算出的值就对不上。第三步，铸造进行，每笔铸造按合约内的计数器或随机规则从封闭池中抽取一枚图，合约把通证编号与图案编号的对应关系记进状态，这一步的中间值很多合约会直接写进事件日志。第四步，铸造结束后，发行方公布完整对照表与素材包，任何人把实际采用的顺序按同法重算一遍哈希：与链上那个值一致，说明顺序自部署起未被改动；不一致，说明中途换过图或换过序。

不同生态里这个组件的露出方式不一样。多签发行工具把 getProvenanceHash 做成现成的查询接口；链游卡牌合约会在铸造事件里附带随机种子与序号映射；也有项目把哈希只写进公告而不进合约，这种”链下立字据”约束力弱一档，因为公告可以换版本。买家侧最省事的核对，是直接读合约里公开的哈希变量与铸造事件，而不是只看官网表格。

边界要说清。溯源哈希能证明的只有一件事：公布的那套素材与顺序，和铸造开始前立字据的指纹是否吻合。它管不了字据之前的事——稀有度配比在定稿时本来就可以偏心，哈希只锁”事后不改”，不保证”事先公平”；它也管不了铸造进行中的操作空间：如果合约的随机性来自可被矿工或部署者影响的变量，或者允许暂停后重启，图序对得上也可能出现抽取时机被挑过的情况；它更不构成权属证明，美术版权链与溯源哈希无关。与之相邻还有一个容易混淆的概念：比特币铭文里也有叫溯源的字段，指的是子代铭文指向父代合约的谱系引用，两者名字相近、用途完全不同。

对普通用户的实操清单很短：铸造前查合约源码里有没有只读初始化的溯源字段；铸造中看事件日志能否拼出抽取顺序；铸造后对照官方公布的素材重算或等待社群复核。三步里只要有一步缺位，“随机铸造”就退化成”信用铸造”。

工程层面还有三个常被问到的点。哈希算法的选择要与公布口径一致：多数实现用 keccak256 或 sha256 对“文件名加属性文件名”的顺序串取散列，也有模板先对每份素材单独取散列、再按序拼接取二级散列，重算前务必照抄项目文档的拼接规则，一个分隔符的差异就足以让比对失败。公布通道同样关键：完整素材包与对照表若只在官网放一份压缩包，核对就依赖网站持续可用；更稳妥的做法是把包本身的散列写进公告或链上事件，让文件与承诺互锁。最后，溯源哈希与随机抽取是两个独立模块——哈希锁顺序，随机数决定每个编号落在顺序表哪一格，两者都正常才构成可验证的随机铸造；审查开源模板时应分别确认哈希变量是否只读、随机源是否可预测，任何一项失守，另一项只是装饰。 本文为机制说明，不构成任何投资建议。