Cardano で最初の存在証明を公開する

もっともシンプルな Label 309 証明は、Cardano 上に記録された 1 つのハッシュです。

ファイルを用意し、その暗号学的ハッシュを計算し、そのハッシュを Cardano のメタデータラベル 309 のもとで Label 309 レコードとして公開して、出来上がったトランザクションハッシュを保管します。後から元のファイルを持つ人なら誰でも、ハッシュを再計算し、対応するコミットメントがトランザクションのブロック時刻までにチェーン上へ記録されていたことを確認できます。確認にあたって、発行者のサーバーもドメインもアイデンティティも必要ありません。必要なのはトランザクション参照と公開された Cardano エクスプローラーだけです。

これが存在証明（Proof of Existence）の第一段階です。ほかのすべては、その上に積み重なっていきます。本ガイドでは、おもに cardanowall コマンドラインツールを使って証明を 1 つ公開する手順をたどり、最後に、それが本当に機能したかを確認する方法までを説明します。

実際に公開しているのは何か

基本的な証明をつくるとき、ファイルそのものを公開しているわけではありません。

公開しているのは、ファイルに対するコミットメント、つまりそのダイジェストです。ダイジェストとは、固定長の暗号学的なフィンガープリントです。ファイルが 1 バイトでも変われば、ダイジェストはまったく別のものになります。この性質こそが、ハッシュを「その正確なバイト列」の信頼できる代理として成り立たせています。

ハッシュだけの証明は、たとえば次のようなものに向いています。

契約書や請求書
リリース成果物やビルドマニフェスト
AI の出力やデータセットのスナップショット
ポリシー文書や証拠パッケージ
別のシステムがすでに生成したチェックサム

証明はファイルの中身を明らかにしません。明らかになるのは、ハッシュ、選んだハッシュアルゴリズム、そしてレコードに含めると決めた任意のメタデータだけです。どのフィールドがチェーン上に載るのかについては、ブロックチェーンに記録されるものを参照してください。

公開の前に何が必要か

公開にはゲートウェイが必要です。検証には必要ありません。

検証はすべて公開されたチェーンデータから実行できます。公開はそれとは異なります。誰かが Cardano トランザクションを構築して送信し、ネットワーク手数料を支払い、確認を扱い、ファイルをオフチェーンに保存する場合はストレージのコストも支払わなければなりません。Label 309 ゲートウェイは、こうした処理をすべて行うサービスです。オープンソースのゲートウェイと、その周辺のツール群はゲートウェイに依存しない設計なので、鍵を持っているゲートウェイにツールを向けるだけで使えます。

最初の証明には、次のものが必要です。

ファイルまたは計算済みのダイジェスト
Label 309 ゲートウェイのベース URL
そのゲートウェイの API キー、または短命のアカウントトークン
ゲートウェイアカウントに十分な残高
レコードに署名したい場合は、任意で Identity Seed（アイデンティティの種）

ホスティングされた CardanoWall ゲートウェイを使う場合、ゲートウェイアカウントとプリペイド残高は CardanoWall が運用します。自分でゲートウェイを運用する場合は、その Cardano とストレージのウォレットへの資金供給はご自分で行います。いずれにしても、実際の手数料がお客様に代わって支払われるため、公開には費用がかかります。これについては公開に費用がかかる理由で扱っています。

なぜワークフローは「先に見積もり、それから公開」なのか

ゲートウェイが黙って公開し、あとから請求で利用者を驚かせるようなことがあってはなりません。そこで、どの公開も同じ 2 段階の形をとります。まず価格を固定し、それから送信します。

レコードを構築または見積もります。
ゲートウェイに見積もりを要求します。
見積もり ID と価格の内訳（ネットワーク手数料、ストレージ、サービスマージン）を受け取ります。
その見積もりとともに、確定したレコードを送信します。
トランザクションがまだ送信中の段階で、ゲートウェイのレコード ID をただちに受け取ります。
トランザクションがチェーン上で確認されるまで、ステータスを追跡します。
結果を独立して検証します。

見積もりは、限られた時間（現在は 15 分）だけ価格を固定します。公開する前に有効期限が切れた場合は、新しい見積もりを要求します。為替レートが動いていれば価格は変わる可能性がありますが、それ以外は何も変わりません。

この 2 段階のパターンこそが、自動化を安全にします。スクリプトは見積もりをログに記録し、独自の支出ポリシーを適用し、そのうえで初めて公開できます。これにより、価格の急騰や打ち間違いによるバッチ処理が、残高を勝手に使い込んでしまうことは決して起きません。

CLI でファイルを公開する

ローカルファイルの場合、コマンドラインの流れは意図的に小さく抑えてあります。

cardanowall submit \
  --file ./contract.pdf \
  --base-url https://your-gateway.example \
  --api-key "$CARDANOWALL_API_KEY"

CLI はファイルをハッシュ化し、Label 309 レコードを構築し、ゲートウェイに見積もりと公開を依頼して、結果を出力します。--base-url と --api-key は CARDANOWALL_BASE_URL と CARDANOWALL_API_KEY の環境変数からも読み取られるため、CI ではコマンドから省けます。

繰り返し使う場合は、エンドポイントを毎回渡す代わりに、ゲートウェイを名前付きプロファイルとして保存します。

cardanowall gateway add prod --base-url https://your-gateway.example
cardanowall gateway use prod
cardanowall submit --file ./contract.pdf

cardanowall バイナリは、インストールすべきランタイムを持たない、単一で自己完結したネイティブツールです。crates.io から cargo install cardanowall-cli でインストールするか（クレート名は cardanowall-cli、インストールされるコマンドは cardanowall です）、github.com/cardanowall にあるオープンソースのリポジトリからビルドしてください。

すでに持っているハッシュを公開するには

ダイジェストがすでに存在することもあります。ビルドパイプライン、コンテナレジストリ、リリースプロセス、あるいはデータアーカイブから得られたものなどです。その場合は、ファイルを介さず、ダイジェストを直接公開します。

cardanowall submit --hash <64-hex-digest>

デフォルトのハッシュモードは sha2-256 です。別のアルゴリズムが必要なときは --alg blake2b-256 を渡してください。レコードには使用したアルゴリズムが記録されるので、検証ツールは後からダイジェストを再計算する方法を知ることができます。

計算済みのハッシュを公開するのは、元のファイルが大きすぎたり、機密性が高すぎたり、管理が厳格すぎたりして汎用ツールに通せない場合にも適した方法です。重要なのは、正確なバイト列と正確なハッシュ化のプロセスが再現可能なまま保たれることだけです。そうでなければ、誰も一致するダイジェストを再計算できません。

レコードに署名すべきか

特定の Label 309 アイデンティティがそのレコードを保証したことを証明したいときは、レコードに署名してください。

ハッシュだけの証明は、「これらのバイト列はこの時刻までに存在した」と述べます。署名付きの証明は、そこに「そして、この署名鍵がこの正確なレコードの裏付けとなっている」を加えます。この追加の主張は、企業のリリースレコード、公式アーカイブ、CI/CD パイプライン、法的証拠のワークフロー、AI の来歴ログ、そして長期にわたって存続する公開発行者のアイデンティティにとって重要です。

署名は常に任意です。署名のない証明も、完全で十分に検証可能な存在証明です。Label 309 は設計上、発行者に依存せず、検証者が発行者を信頼する必要は一切ありません。署名はただ、別の問いに答えるだけです。つまり、レコードを保証するのは「誰か」であって、バイト列が存在「したかどうか」ではありません。

Identity Seed をゲートウェイに送ってはいけません。CLI と SDK は、署名がローカルで行われ、完成した署名だけが送られるようにつくられています。シードは、むき出しの --seed 引数ではなく、--seed-stdin または --seed-file を通して渡してください。コマンドライン引数は、シェル履歴、プロセス一覧、CI ログを通じて漏えいするからです。

cardanowall submit --file ./release-manifest.json --seed-stdin

ファイルを添付すべきか、ハッシュだけにすべきか

チェーン上にコミットする内容の多さの順に、3 つの選択肢があります。

ハッシュのみ。 もっとも小さく、もっともプライベートな証明です。ファイルを自分が管理する場所に保存しておくとすでにわかっている場合には、これで十分です。レコードはダイジェストを保持し、取得方法については何も持ちません。

ハッシュにコンテンツアドレス指定リンクを加える。 ar://（Arweave）や ipfs://（IPFS）の URI を添付すると、検証者は後からバイト列を取得できます。取得したバイト列が一致するかどうかを決めるのは、あくまでハッシュです。コンテンツアドレス指定の URI は、バイト列をそのリンク自体に結びつけるため、検証者は正しいファイルを取得したと知るのにゲートウェイや DNS、TLS を信頼する必要がありません。

封印。 ファイルを暗号化し、暗号文をオフチェーンに保存して、封印エンベロープをレコードに入れます。これは、機密性のあるレコード、特定の受信者宛ての配信、そしてローカルコピーを失った場合に後から内容を復元したいときに選ぶ方法です。

最初の証明では、ハッシュのみから始めてください。署名、オフチェーンストレージ、Merkle バッチ処理、封印配信は、実際のユースケースが必要としたときに追加すればよいのです。

本当に成功したとどう判断するか

「ゲートウェイが受け付けた」で止めてはいけません。証明が完成するのは、トランザクションがチェーン上にあり、検証に通ったときだけです。

公開すると、ゲートウェイはすぐにレコード ID を返し、トランザクションが構築・送信されたあとで、トランザクションハッシュが非同期に埋まります。そのため、公開後は次のものを保管してください。

Cardano のトランザクションハッシュ
ゲートウェイを使った場合は、ゲートウェイのレコード ID
元のファイルまたはダイジェスト
署名した場合は、署名鍵の公開アイデンティティ
バッチ処理した場合は、Merkle のリーフリストまたは包含証明
証明が封印されている場合は、復元用の素材

そのうえで、第三者がするのとまったく同じやり方で、ゲートウェイを介さず、公開されたチェーンからトランザクションを検証します。

cardanowall verify <tx-hash> --json

valid の判定がゴールラインです。ほかの判定は、次に何をすべきかを教えてくれます。

pending — トランザクションがまだ十分な深さまで確定していません。確認がさらに増えるのを待ってから再試行してください。
unverifiable — レコードに問題はありませんが、必要なチェックを実行できませんでした。データソース、オフチェーンストレージの可用性、ネットワークポリシーを確認してください。
failed — レコードに起因する実際の問題です。レコードそのものを調査してください。

failed と unverifiable を分けているのは意図的です。failed はレコードが間違っていることを意味し、unverifiable は検証ツールがチェックを完了できなかったことを意味します。検証の全体の流れについては、Label 309 レコードを検証するを参照してください。

公開後に UI は何を表示すべきか

優れたインターフェースは、「公開済み」という言葉以上のものを示します。最初の証明では、次の情報を表に出してください。

短いトランザクションハッシュ（コピーボタン付き）
詳細ビューでの完全なトランザクションハッシュ
ハッシュアルゴリズムとダイジェスト
公開ステータス
確認後のブロック時刻
検証の判定
レコードが署名されているかどうか
ファイルが添付または封印されているかどうか
スキップされたチェックがあるかどうか

これにより、誰も仕様書を読まされることなく、証明を理解できるようになります。

公開時に何が問題になり得るか

公開の失敗のほとんどは、不可解なものではなく、運用上のものです。アカウントの残高が不足しているかもしれません。見積もりの有効期限が切れているかもしれません。レコードが Cardano トランザクションには大きすぎるかもしれません。アップロードしたファイルの保存に失敗するかもしれません。Cardano トランザクションが恒久的に失敗するかもしれません。その場合、よくできたゲートウェイは課金そのものを取り消すので、チェーン上に載った分だけが請求されます。あるいは、ゲートウェイの資金供給済みウォレットに、単に対応が必要なだけかもしれません。

本格的な公開ワークフローは、再試行をべき等に扱います。ゲートウェイは、レコードの正確なバイト列によって公開の再試行を重複排除します。つまり、同一のレコードを再送信すると、二重に支払う代わりに既存の結果が返ります。さらに、アップロードバッチではべき等キーを受け付けるため、再配信されたアップロードはリプレイに対して安全です。ユーザー向けの製品では、再試行の経路は、最初の実顧客がネットワークタイムアウトに遭遇したあとではなく、その「前」に設計してください。

これをパイプラインに組み込もうとしているなら、CLI を自動化で使うが、JSON 出力、終了コード、安全なシークレットの扱いについてさらに掘り下げています。

最初の証明が証明しないものは何か

存在証明は、何を主張するのかについて厳密です。それはつまり、何を主張しないのかについても厳密だということです。

所有権は証明しません。
著作・作成者は証明しません。署名し、署名鍵を主張されたアイデンティティに結びつけられる場合は別です。
ファイルが真正・適法・オリジナルであることは証明しません。
ファイルを保全しません。どこか永続的な場所に保存する場合は別です。

証明するのは、正確で永続的なことです。コミットされたハッシュと一致する正確なバイト列が、トランザクションのブロック時刻までに存在したこと。そして、任意の署名、ストレージのチェック、封印された内容のチェックが、検証ツールのポリシーに従って検証に通ったことです。

これは本当に役立つには十分であり、信頼されるには十分なほど厳密です。タイムスタンプが立証できること・できないことのより広い境界については、証明が証明しないものを参照してください。

さらに読む

Label 309 レコードを検証する — このワークフローの、トラストレスでアカウント不要なもう半分です。
公開に費用がかかる理由 — その手数料が何の対価なのか。
CLI を自動化で使う — JSON 出力、終了コード、CI でのシークレット。
ブロックチェーンに記録されるもの — レコードが実際に保持するフィールド。
オープンスタンダードとリファレンス実装: label309.org と、github.com/cardanowall にあるソース。