証明ファイル(または証明書のPDF)と、原本のコピーが必要です。アップロードは一切ありません:ハッシュ値はブラウザ内で計算されます。以下に、完全な仕様を実際の値とともに手順を追って示します。
以下で説明するものと同じエンジンで、ここから証明書を確認できます。文書は端末から出ません:SHA-256はブラウザ内で計算され、送られるのはハッシュ値だけです。ハッシュ値はあなたが提供するもので、証明ファイルから取ることは決してありません。証明書のPDFをドロップした場合も、添付された証拠パッケージはブラウザ内で取り出され、PDFが送信されることはありません。
1 · 証明ファイル
2 · 原本の文書
検証ツールが証明ファイルからハッシュ値を取ることは決してありません:ハッシュ値はあなたが提供します。
パッケージとハッシュ値がPOST /api/verify/proofに送信されます。アカウント不要。上限:IPあたり1時間120回の検証。
PDF証明書に記載され、Kaspaのエクスプローラーにも表示されます。
もう一方のタブで文書をドロップして計算できます:値は共有されます。
GET /api/verify/proof/{txid}?hash=…。上限:IPあたり1時間30回(ネットワークに問い合わせるため)。
4つの環がすべて整合しています:このSHA-256を持つ文書は、示されたブロックが採掘された時点で存在していました。この証明が示さないことも忘れないでください:作成者や内容の真実性は証明しません。
再計算できた範囲は整合していますが、連鎖を閉じるためのデータ(通常はプルーニングウィンドウを過ぎたブロックの完全なヘッダー)が欠けています。証明の失敗ではなく、部分的な検証です。その時点で取得した証明ファイル、または完全な証拠パッケージがあれば完了できます。
提供されたハッシュ値に対して、少なくとも1つの環が整合しません。よくある原因は、文書がタイムスタンプを付与したものと厳密に同じではない(1バイト違うだけでSHA-256は変わります)か、証明ファイルがこの文書のものではないことです。各環の詳細をご確認ください。
パッケージに受理ウィットネスは含まれていません。これは任意であり、判定には影響しません。
注意
ここでは雄弁さより正確さが重要です。証明が反対尋問に耐えられるかどうかが、それにかかっているからです。
SHA-256が特定の値であるバイト列がKaspaネットワークのトランザクションに組み込まれたこと、そのトランザクションがブロックのヘッダー内にコミットされたこと、そしてタイムスタンプを含むそのヘッダーに対して有効なプルーフ・オブ・ワークが実行されたこと。タイムスタンプは作業の対象となったデータの内側にあるため、これを書き換えれば作業は無効になります。日時は誰かの申告ではありません:すでに費やされた物理量です。
誰が文書を作成したか、その内容が真実かどうか、作成者にそれを作る権利があったかどうか、そしてその文書がそれ以前に存在しなかったこと。証明するのはある時点より前に存在していたことであり、作成者や真実性ではありません。Proovikはいかなる時点でも文書を見ることはありません:受け取るのはそのハッシュ値だけです。
SHA-256は256ビットのダイジェスト関数です。同じダイジェストを持つ異なる2つの文書は、これまで一度も見つかっておらず、必要と見積もられる計算量は人類が計算できる範囲を超えています。したがって、提出された文書のダイジェストがチェーン上のものと一致すれば、その文書は同一であり、実務上疑いの余地はありません。
検証は連鎖です。各環が次の環につながっており、1つでも切れれば証明は成り立ちません。以下に示す値は実物で、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ではなく、完全なエンコード(signature scriptとストレージマスのコミットメントを含む)で計算された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段階、200を超えるハッシュ——にコミットしています。1つでも欠ければ、ダイジェストを再構成できません。証明ファイルがアンカリングの時点で完全なヘッダーを取得しておかなければならないのは、このためです:30時間ほど経つとネットワークはそのデータを破棄し、公開サービスは切り詰められたヘッダーを返します。
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を1秒進めたもの | 0xaee1e8274b1d268866ed… | 無効 |
文書を別の日時で提示するには、そのヘッダーのプルーフ・オブ・ワークを、ネットワークの実際の難易度に対してやり直さなければなりません。これはコストの壁ではありません:偽装しようとする期間にわたるネットワーク全体の総演算能力に匹敵する、計算量の壁です。日時は誰も申告しません。日時は支払われるものです。
率直な答えははいです。その理由を理解しておく価値があります。取得済みの証明はネットワークへのライブ問い合わせではなく、アンカリングされた時点で有効だった規則のもとで検証される歴史的事実です。Kaspaは時とともに変わります——たとえばCrescendo/Toccataへの移行は、DAAの間隔と難易度の計算を変更しました——が、それで過去が消えるわけではありません。2026年1月のブロックは2026年1月の規則で検証され、3年後のブロックは3年後の規則で検証される、というだけのことです。
リファレンス検証ツールはまさにそのために作られています:時代を区別します。各コンセンサス変更の有効化ポイント(たとえば定数CRESCENDO_DAA_MAINNET)を把握し、各ブロックには今日の規則ではなく、その時代の規則を適用します。後のハードフォークは新しい時代を追加するだけで、それ以前の時代を無効にすることはありません。
証明の永続性は、次の3つの条件にかかっています。いずれも証明を持つ人の管理下にあります:
ネットワークが完全なデータを破棄する前(およそ30〜40時間)に、アンカリングの時点で完全なヘッダーを保存すること。
証明ファイル(またはそれを埋め込んだPDF)は自己完結しています:どのサーバーも参照せず、オンラインでの問い合わせも行いません。
依存関係のないオープンなコード248行で、Kaspaの公開ソースから再導出できます。失われたとしても書き直せます。
リファレンス検証ツールは外部依存のないPython 248行です:鍵付き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
ファイルは2つです。同じフォルダーに置いて、最初のものを実行してください。何もインストールせず、ネットワークにも接続しません。
他人のコードを実行したくない方は、自分で実装し直すこともできます:4つのアルゴリズムは上で曖昧さなく説明されており、すべてのパラメーターはrusty-kaspaの公開ソースコードに由来します。照合として、公開されているKaspaのエクスプローラーでトランザクションを参照することも同じく正当ですが、その違いは理解しておく価値があります:エクスプローラーは証言であり、計算は論証です。この仕様は、前者に依存しないために存在します。
Proovikは、規則(EU)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/。
例として用いた値は実際の証明書のもので、誰でも確認できます。この仕様はバージョン管理されています:証明には、それが発行されたバージョンが内部に記録されています。