1 · 交易中的数据就是文件的摘要
相符- 它检查什么
- 你的文件的哈希值正是 Kaspa 上的那一个。
- 如果它失败了
- 那说明有人改动过这份文件,哪怕只有一个字节。
- 怎么做的
- 每一笔 Kaspa 交易都允许带一个自由字段
payload。Proovik 只在那里写入文件 SHA-256 的 32 个字节,别无其他。这项检查就是一次逐字节的直接比对。
查看计算过程
SHA-256(documento) == transaccion.payload
你需要证明文件(或证书 PDF)以及你自己那份原始文件。什么都不会上传:哈希值在你的浏览器中计算。下面是完整规范,分步说明并附真实数值。
在这里用下文所述的同一套引擎校验证书。文件不会离开你的设备:它的 SHA-256 在你的浏览器中计算,只有哈希值会被发送。哈希值由你提供,绝不会从证明文件中取用。如果你拖入证书 PDF,其中附带的证据包会在你的浏览器中提取出来,PDF 同样不会被发送。
1 · 证明文件
2 · 原始文件
验证器绝不会从证明文件中取用哈希值:哈希值由你提供。
数据包和哈希值会发送到 POST /api/verify/proof。无需账号。限制:每个 IP 每小时 120 次验证。
它印在证书 PDF 上,也显示在 Kaspa 区块浏览器中。
你可以在另一个标签页中拖入文件来计算:数值是共享的。
GET /api/verify/proof/{txid}?hash=…。限制:每个 IP 每小时 30 次(需要查询网络)。
四个环节全部成立:具有该 SHA-256 的文件在所示区块被挖出时已经存在。请记住这份证明不能证明什么:既不能证明作者,也不能证明内容是否属实。
能够重新计算的部分都成立,但缺少某些数据(通常是完整的区块头,已经超出修剪窗口),无法闭合整条链。这不是证明本身的失败:这是一次部分验证。用当时保存下来的证明文件,或者用完整的证据包,就可以补全。
至少有一个环节与所提供的哈希值对不上。最常见的原因是:文件并不完全是当时存证的那一份(哪怕只差一个字节,SHA-256 也会变),或者证明文件与这份文件并不对应。请查看每个环节的详情。
数据包中不含接受见证。它是可选的:不影响判定结果。
提示
在这里,精确比雄辩更重要,因为这份证明能否经受住质证正取决于此。
一串 SHA-256 为某个特定值的字节被写入了一笔 Kaspa 交易,这笔交易被承诺在某个区块头之内,而在这个包含时间戳的区块头之上执行了有效的工作量证明。由于时间戳位于工作所针对的数据内部,改动它就会让这份工作失效。日期不是任何人的声明:它是一个已经耗费掉的物理量。
谁创建了这份文件、它的内容是否属实、作者是否有权创建它,以及这份文件是否更早就已存在。它证明的是相对某一时刻的在先性,而不是作者身份或内容真实性。Proovik 任何时候都看不到文件:它只收到文件的哈希值。
SHA-256 是一个 256 位的摘要函数。至今没有人找到过摘要相同的两份不同文件,而所需的估算工作量超出了人类能够计算的范围。因此,如果所提交文件的摘要与链上的那个一致,那就是同一份文件,实际上没有怀疑的余地。
验证是一条链。每个环节都连着下一个,只要有一个断了,整份证明就失去价值。下面出现的数值是真实的:它们来自 2026 年 9 月 20 日签发的一份证书。
payload。Proovik 只在那里写入文件 SHA-256 的 32 个字节,别无其他。这项检查就是一次逐字节的直接比对。SHA-256(documento) == transaccion.payload
acceptedIdMerkleRoot 这个字段不再是简单的 Merkle 根,而是一个链式数值:它把父区块的承诺与已接受交易的根结合在一起。忽略这种链式结构的重算必然失败,而这正是验证出错最常见的原因。nodo(a,b) = blake2b-256( clave = "MerkleBranchHash", a ‖ b ) AIMR = raiz Merkle sobre las transacciones aceptadas, en orden canonico SeqCommit = nodo( SeqCommit_del_padre_seleccionado , AIMR ) valido ⟹ SeqCommit == cabecera.acceptedIdMerkleRoot
已接受交易的排序采用 KIP-15 规定的规范顺序,既不是某个 API 返回的顺序,也不是按哈希排列的顺序。此外,区块树的叶子节点——在验证包含性而不是接受性时——不是 txid,而是 tx::hash,它按完整编码计算(包括签名脚本和存储质量承诺)。
h = blake2b-256( clave = "BlockHash" )
h ← version u16 little-endian
h ← numero de niveles u64 little-endian
para cada nivel:
h ← numero de padres u64 little-endian
h ← cada hash de padre 32 bytes
h ← hashMerkleRoot 32 bytes
h ← acceptedIdMerkleRoot 32 bytes
h ← utxoCommitment 32 bytes
h ← timestamp u64 little-endian ← la marca temporal
h ← bits u32 little-endian
h ← nonce u64 little-endian
h ← daaScore u64 little-endian
h ← blueScore u64 little-endian
h ← longitud de blueWork u64 little-endian
h ← blueWork big-endian, sin ceros a la izquierda
h ← pruningPoint 32 bytes
区块头承诺了所有父级层级——如今是 56 层,包含两百多个哈希值。只要缺少其中一个,摘要就无法重建。这正是证明文件必须在锚定当时捕获完整区块头的原因:大约三十小时之后,网络就会丢弃这些数据,公共服务返回的将是被截断的区块头。
pre = hash_de_cabecera( con timestamp = 0 y nonce = 0 )
M = matriz 64x64 generada con xoshiro256++ sembrado con pre,
regenerada hasta que su rango sea 64
p = cSHAKE256("ProofOfWorkHash")( pre ‖ timestamp ‖ 32 ceros ‖ nonce )
r = cSHAKE256("HeavyHash")( (M · nibbles(p)) ⊕ p )
valido ⟹ entero_little_endian(r) ≤ objetivo(bits)
这部分通常是质证时最被追问的,所以与其论证,不如直接展示。时间戳位于区块头内部,而区块头正是工作量证明的输入。改变时间就改变了输入,这份工作也就不再有效。可以通过修改第 4 步中已验证的区块头并重复计算,用实验来验证这一点:
| 区块头 | 工作结果 | 判定结果 |
|---|---|---|
| 原始,未改动 | 0x15222b53caabb3b049ec… | 有效 |
nonce + 1 | 0x6775abc19ba960657f66… | 无效 |
timestamp 向前拨快一秒 | 0xaee1e8274b1d268866ed… | 无效 |
要让这份文件带着另一个日期出现,就得按网络的真实难度把那个区块头的工作量证明重做一遍。这不是一道成本壁垒:这是一道计算壁垒,量级相当于整个网络在想要伪造的那段时间里的总算力。日期不由任何人声明。日期是要付出代价的。
诚实的回答是能,而且值得弄清楚为什么。一份已经捕获的证明不是对网络的实时查询:它是一个历史事实,按照锚定当时生效的规则来验证。Kaspa 会随时间变化——比如 Crescendo/Toccata 过渡就改变了 DAA 的节奏和难度计数——但这并不会抹去过去:它只是意味着 2026 年 1 月的区块用 2026 年 1 月的规则验证,三年后的区块用三年后的规则验证。
参考验证器正是为此而做的:它能区分不同时期。它知道每一次共识变更的激活点(例如常量 CRESCENDO_DAA_MAINNET),并对每个区块套用它所属时期的规则,而不是今天的规则。之后的硬分叉只会增加一个新的时期;它不会让之前的时期失效。
因此,证明的持久性取决于三个条件,而它们全都掌握在持有证明的人手中:
在锚定当时保存完整的区块头,赶在网络丢弃完整数据之前(大约 30-40 小时)。
证明文件(或内嵌它的 PDF)是自足的:它不指向任何服务器,也不做任何在线查询。
248 行开源代码,没有依赖,可以从 Kaspa 的公开源码重新推导出来。就算丢了,也能重写。
参考验证器是 248 行不依赖任何外部库的 Python 代码:它实现了带密钥的 blake2b、Keccak-f[1600] 置换、xoshiro256++ 生成器以及矩阵运算。一个下午读得完,两个下午审得完。
$ python3 verificador_kaspa.py prueba.json 0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8 OK 1. El payload on-chain es el hash del documento OK 2. La transaccion esta en el arbol Merkle del bloque OK 3. La cabecera produce el hash de bloque declarado OK 4. La prueba de trabajo de esa cabecera es valida RESULTADO: PRUEBA VALIDA
不愿意运行别人代码的人可以自己重新实现:上文已经毫无歧义地描述了这四种算法,所有参数都来自 rusty-kaspa 的公开源码。在任何公开的 Kaspa 区块浏览器中查一下这笔交易作为对照同样正当,但要弄清其中的差别:区块浏览器是一种证言;计算是一种论证。本规范存在的意义,正是为了不必依赖前者。
Proovik 提供的是欧盟第910/2014号条例第 3 条第 16 项 i) 意义上的非合格电子时间戳服务。有必要把这意味着什么讲清楚。
Proovik 不核实文件的内容、作者身份或合法性,而且任何时候都不会接触到文件本身:它只收到文件的密码学摘要。所证明的是相对某一确定时刻的存在性与在先性证明。
区块头与交易的序列化、Merkle 树的构建以及工作量证明,依据 Kaspa 参考实现(rusty-kaspa)的源码:consensus/core/src/hashing/header.rs、consensus/core/src/hashing/tx.rs、consensus/core/src/merkle.rs、crypto/hashes/src/pow_hashers.rs、consensus/pow/。
用作示例的数值来自真实的证书,任何人都可以核验。本规范有版本管理:每份证明内部都标明了它签发时所依据的版本。