Merkle バッチから 1 ファイルを証明する：包含証明書

ファイルのバッチを Cardano に公開するとき、チェーン上へ載るのは小さな指紋ひとつだけです。リスト全体を代表する単一の Merkle ルートです。これによって公開は安価なままに保たれます。けれども、当然の疑問が湧きます。チェーン上にあるのがルートだけなら、後からある特定の 1 ファイルが本当にバッチに含まれていたことを、どうやって証明するのでしょうか。

その答えが包含証明書です。ある特定のファイルのハッシュが、公開されたそのバッチの一部だったことを証明する、ダウンロード可能な小さなファイルです。誰でも、ご自分のブラウザで、任意の公開 Cardano エクスプローラーに対して確認でき、CardanoWall を信頼する必要は一切ありません。そして証明がファイルに焼き込まれているため、いつまでも機能し続けます。

これは Merkle バッチ処理の日々の相棒です。バッチ処理は数千のファイルに一度にコミットするための仕組みであり、包含証明書はそのうちの 1 つを後から取り出して証明するための仕組みです。

包含証明書はどんな問題を解決するのか

去年、1 つのバッチで千個のファイルを公開したと想像してください。契約書を集めたフォルダ、リリース成果物の一式、ある 1 日分の監査ログ。それらはすべて 1 つの Merkle ルートに畳み込まれ、そのルートが Cardano 上でタイムスタンプされました。安く、コンパクトに、完了です。

ところが今、そのファイルのうちの 1 つだけに対して異議が唱えられたとします。たとえば取引相手が「この契約書が締切前に存在していたことを示せますか」と尋ねるかもしれません。ブロックチェーンが保持しているのはルートだけで、ファイルもリストもありません。トランザクションを指し示せるのは、既知のサイズの何らかのバッチが存在したことだけで、この 1 つの文書がその中にあったことまでは示せません。

包含証明書はこの隙間を埋めます。小さく、自己完結したファイルで、実質的にこう言っています。「このファイルのハッシュは、この Cardano トランザクションの背後にあるバッチの 42 番目の項目であり、誰でも実行して確認できる正確な計算がここにあります」。あなたが証明書を渡せば、相手はあなた自身も、あなたのアカウントも、私たちのウェブサイトすらも存在し続けることなく、それを確認できます。

証明書には実際に何が入っているのか

封をした証拠パケットだと考えてください。3 つの部分でできています。

あなたのファイルの指紋。 ファイルそのものではなく、ハッシュだけです。証明書はあなたの文書の中身を一切運ばないため、ファイルが非公開のものであっても安全に共有できます。
証明経路。 短い「兄弟」指紋のリストで、これによって誰でもあなたのファイルのハッシュを Merkle ツリーの上へと畳み戻し、公開されたルートにちょうどたどり着けます。これこそ証明書を自己完結させている部分です。計算が焼き込まれているので、バッチの残りを誰かに尋ねる必要は決してありません。
ブロックチェーンのアンカー。 ルートが公開された Cardano トランザクション、ブロックチェーンがそれに記録した時刻、そして誰でも自分で調べられるよう、いくつかの公開エクスプローラーへのリンク。

さらに、その証明書が何を証明するかを述べた平易な claim の 1 行と、独立して検証する方法についての短い注記も含まれます。1 つの証明書は 1 ファイルを対象にすることも、複数を一度に対象にすることもできます。それぞれに独自の証明経路と、明確な verified の印が付きます。

CardanoWall はこのパケットをいくつかの形式で渡せます。JSON ファイル（ツールが再確認できる、機械可読の原本）と PDF（人や法務ファイル向けの、読みやすく印刷できる版で、JSON が添付として文書の中に収められているため、文書のまま機械検証が可能）です。

どうやって手に入れるのか

トランザクションのページで、ご自分のブラウザで、自分自身で作ります。

バッチを運んだトランザクションの公開ページを開きます。レコードに Merkle ルートが含まれているため、ページは包含チェックを提供します。そこからは 2 つの小さな手順です。

どのファイルかを伝える。 ファイルのハッシュを貼り付けるか、ファイルをページにドロップするだけです。ブラウザはローカルでハッシュ化し、アップロードは決してしません。
結果を読む。 ページはバッチのリーフリストを取得し、証明を再計算し、明確な緑（ファイルはバッチに含まれる）または赤（含まれない）の結果を示します。

緑のときは、証明書をダウンロードします。JSON、PDF、またはその両方です。そのダウンロードが、持ち運べる証明です。メールで送り、保管し、契約書に添付し、データルームに置いてください。これでもう、CardanoWall とは完全に独立しています。

すべてはクライアント側で行われます。私たちがサーバーで証明書を生成して、それを信頼してくださいとお願いするのではありません。あなた自身のブラウザが処理を行います。だからこそ結果は信頼に足るのです。

なぜ誰も CardanoWall を信頼する必要がないのか

証明書のどこをとっても、私たちが正直であること、オンラインであること、ましてや事業を続けていることに依存していないからです。

包含証明書の中には 2 つの主張があり、そのどちらも誰でも自分で確認できることです。

あなたのファイルはバッチに含まれていた。 検証者はあなたのファイルのハッシュを証明経路に沿って畳み上げ、それが公開されたルートを再現することを確認します。これは純粋な算術です。必要なのは証明書ファイルだけで、ほかには何もいりません。あなたのファイルが 1 ビットでも変われば、畳み込みは別のルートに着地し、チェックは失敗します。
ルートは本当に Cardano 上にある。 検証者は任意の公開 Cardano エクスプローラー（Cardanoscan、AdaStat、自分で選んだもの）でトランザクションを調べ、同じルートがオンチェーンのレコードに収まっていることを確認します。その調べものに CardanoWall のサーバーは一切関与しません。

この 2 つのチェックを合わせれば、ブロックチェーンがそのトランザクションに刻んだ時刻までに（あるいはそれ以前に）ファイルが存在していたことが証明されます。そしてその時刻は Cardano から来るのであって、私たちから来るのではありません。私たちはブロックを早送りすることも、トランザクションの日付をさかのぼらせることも、歴史をこっそり書き換えることもできません。いつ起きたかを決めるのはブロックチェーンです。会社の時計を信頼してくださいと頼む代わりに、公開チェーンに錨を下ろすことの意義は、まさにここにあります。

CardanoWall が明日消えたとしても、私たちがこれまで発行したすべての証明書は検証され続けます。オープンソースの cardanowall コマンドラインツール、そしてこの形式を理解するあらゆる独立したツールが、同じチェックをもう一度実行できます。

flowchart LR
  A["あなたのファイル"] -->|"ローカルでハッシュ化"| B["ファイルハッシュ"]
  B --> C["証明経路を畳み上げる"]
  C --> D["再計算したルート"]
  E["Cardano トランザクション<br/>(公開エクスプローラー)"] --> F["公開されたルート + ブロック時刻"]
  D -->|"一致しなければならない"| F
  F --> G["ブロック時刻まで<br/>(あるいはそれ以前)に存在していた"]

証明書が証明しないものは何か

証明書は 1 つのことについては正確で、それ以外のすべてについては沈黙しています。そしてそれを正直に示すことこそが、証明書を信頼に足るものにしています。

証明書が証明するのは、ある特定のファイルのハッシュが、ブロックチェーンのブロック時刻**まで（あるいはそれ以前）**に存在し、コミットされたバッチの一部だったということです。それだけです。具体的には次のとおりです。

ファイルを誰が作成したかは証明しません。 証明書は作成者について何も語りません。バッチを公開したのは誰でもあり得ます。（Label 309 における作成者の表明は、別個の、任意の署名であり、決して前提とされません。証明が証明しないものを参照してください。）
ファイルが真実、正確、または適法であることは証明しません。 バイト列がある時刻までに存在していたことは証明しますが、その中身が正しいことまでは証明しません。
ファイルが唯一の版や原本であることは証明しません。 このまさにこのファイルがバッチに含まれていたことは証明しますが、別の版が存在しないことまでは証明しません。
「適格」タイムスタンプではありません。 これはブロックチェーンに錨を下ろしたタイムスタンプであり、ほかのブロックチェーンタイムスタンプと同じ系統のものです。時間に関する強力な裏付け証拠ではありますが、規制された機関による eIDAS 適格電子タイムスタンプではありません。あるプロセスが適格タイムスタンプを明確に要求している場合、これ単体ではその基準を満たしません（存在証明とタイムスタンプ機関の比較を参照してください）。

証明書の価値は、まさに何も過大に主張しない点にあります。タイミングと完全性を確実に押さえ、意味づけはそれを取り巻く文書や人々に委ねます。

これは OpenTimestamps とどう関係するのか

OpenTimestamps をすでにご存じなら、この考え方はなじみ深く感じられるはずです。

OpenTimestamps は小さな .ots 証明ファイルを渡します。持ち運べる自己完結したタイムスタンプで、それを作ったサービスを信頼しなくても、誰でも後から検証できます。包含証明書も同じ形のもの、つまり誰にでも渡せる持ち運び可能な証明ファイルです。ただし、知っておく価値のある違いが 2 つあります。

タイムスタンプ機関が Cardano ブロックチェーンであり、時間はカレンダーサーバーからではなく、あなたのルートを運んだブロックから取られます。そして証明の計算は、この標準のほかの場所で使われているのと同じ Merkle ツリーの構成なので、1 つの証明書だけで、コミットされた大きなバッチから 1 ファイルを取り出せます。精神は同じ、アンカーが違う、というわけです。

より詳しい一覧比較は、存在証明と OpenTimestamps の比較をご覧ください。

短くまとめると

多数のファイルを 1 つの Merkle ルートで公開すれば、ブロックチェーンのコストはごく小さく保てます。包含証明書は、それらのファイルのうちのどの 1 つでも、後から本当にバッチに含まれていたことを証明するための仕組みです。小さなダウンロードで、ご自分のブラウザで、任意の公開 Cardano エクスプローラーに対して確認でき、時間はチェーンが供給し、CardanoWall を信頼する必要はありません。証明経路はファイルに焼き込まれているため、特定のツール、アカウント、会社が姿を消したずっと後でも、証明書は機能し続けます。

さらに読む

数千ファイルを 1 レコードで — Merkle バッチ処理が、証明書が照合する相手となる単一のルートへとリスト全体を畳み込む仕組み。
存在証明と OpenTimestamps の比較 — もっとも近い親戚。もう 1 つの、持ち運べる自己検証型の証明ファイル。
証明が証明すること、そして証明しないこと — あらゆる証明書に当てはまる、正直な限界。
Label 309 レコードを検証する — 証明書のアンカーが指し示すオンチェーンレコードを確認する。
標準、オープンソースの SDK と CLI、そして仕様書のテキスト：label309.org と github.com/cardanowall。