解けたこと

10章かけて確かめたのは、次の4点でした。

解けたこと使ったもの
発行元への問い合わせが要る署名の検証だけで済む電子署名 + 公開鍵の配布
発行元に閲覧履歴が溜まる半分だけ。鍵をキャッシュするか did:key を使えば消えるが、試作の既定設定では消えていない提示（VP）のモデル
誰でも発行者になれてしまう受け入れる署名者を絞る名簿（trust list）
機関が自分の過去を作り直せる記録が機関の管理外にあるチェーン上のイベント

最初の3つにブロックチェーンは要りませんでした。静的ファイルを置けば足ります（2つ目は、鍵をどこから取るかまで設計した場合に限ります）。

4つ目だけが残ります。ただし言い方には注意が要ります。「オフチェーンでは埋まらない」は言い過ぎでした。第4章で見た通り、複数の機関で head を控え合う、紙面に印字する、タイムスタンプ局に預ける、といった手段でも埋まります。正確には、事前に「誰に控えてもらうか」を決めずには埋まらない、です。公開チェーンが効くのは、その調整が要らない一点です。

これは EU の制度設計とも整合します。EU の電子 ID ウォレット（EUDI Wallet）は、ウォレット実装に ISO/IEC 18013-5 の mdoc と SD-JWT VC の両方のサポートを義務づけ、身元確認データ（PID）は両形式で発行させています。信頼の起点は X.509 の公開鍵基盤で、適格な属性証明の発行者は eIDAS 第22条の信頼リストに、ウォレット提供者や PID 提供者は欧州委員会が公開する信頼エンティティリスト（LoTE）に載ります。Gaia-X の信頼枠組みも、発行者の DID メソッドを did:web に限定列挙し、X.509 のチェーンが認定トラストサービス事業者まで辿れることを必須にしています。

どちらも、参加者が自前のチェーンを信頼の起点にする経路は用意されていません。ただしこれは明文の禁止ではなく、規定が無いという形の排除です。実際 Gaia-X の Architecture Document は did:ebsi のような分散台帳ベースのメソッドを将来の拡張として表に載せていますし、EUDI の側も非適格な属性証明については「代替の信頼モデルを採用してよい」と明記しています。制度が閉じているのは、いちばん硬い層だけです。

解けていないこと

アドレスの名寄せ

これが一番大きい問題です。

申請者や支払者をアドレスで記録すると、そのアドレスからの活動がすべて公開の場で連なります。個々の記録は仮名でも、繰り返すと利用傾向が形になり、機関が実名と紐づけた時点で遡って可視化されます。

第2章で、VC が「提示」というモデルを採る理由は、発行元に閲覧履歴を溜めないためだと書きました。ところがチェーンを使うと、

オフチェーン … 発行元だけが見える（鍵をキャッシュすれば、それも見えなくできる）
オンチェーン … 全世界が見える

改竄への耐性と引き換えに、観測可能性が上がるという取引になっています。紙の紹介状が持っていたプライバシーを守るために始めた設計が、別の経路で同じものを失いかけている、という構図です。

緩和の手はあります。

  • 利用者ごとに使い捨てのアドレスを払い出す
  • 申請者を載せず、申請書のハッシュ（requestId）だけを載せる
  • ゼロ知識証明で「支払った」ことだけを示し、誰が払ったかは隠す

どれも別の面倒を持ち込みます。使い捨てアドレスは資金の移動と管理が要り、requestId だけでは証明書の名宛人が決まらず、ゼロ知識証明は実装と検証のコストが跳ね上がります。ここは未解決です。

なお、この論点は国際標準化の場でも扱われています。世宗大学校の李鍾赫（Jong-Hyouk Lee）教授が提案した ISO/TC 307 の標準案「分散台帳ベースの ID 管理においてトラストアンカーが関与する際のプライバシー保護」は、2024年9月30日〜10月4日のシドニー総会で新規プロジェクトとして承認され（賛成率96%、8か国が参加を表明）、現在 ISO/CD 24876 として審議中です。同教授は韓国初のデジタル身分証であるモバイル運転免許証の標準開発にも携わっています。

削除要求に返せるものがない

承認記録も支払い記録も消せません。削除を求められても返せるのは「消しました」ではなく「消せないと記録しました」だけです。

不変性は利点であると同時に、そのまま制約になります。だから試作では、申請の中身をチェーンに載せない方針にしました。載せるのは申請書のハッシュだけで、氏名・所属・利用目的はオフチェーンに置きます。

関連して、スマートコントラクトの private は機密性を意味しません。他のコントラクトからのアクセスを止めるだけで、外から状態を直接読むことは誰にでもできます。個人情報をオンチェーンに置いてよい理由にはなりません。

名簿を誰が維持するか

第6章の maintainer 欄は空のままです。誰が名簿を維持し、誰を入れ、誰を外すかは技術では決まりません。

これはチェーンを持ち込んでも外れない問題です。ARCHANGEL が permissioned chain で「どの公文書館を sealer node にするか」と呼んだものと、C2PA の Trust List と、eIDAS の信頼リストは、すべて同じ場所にあります。EU の場合は加盟国政府がその役を負っていて、制度が先にあり技術が後から乗っている、という順序になっています。

文化資源の分野に、これに相当する制度はまだありません。この本で解けなかったものの中では、これが最も制度寄りで、最も動かしにくいと思います。

「重大な変更」を機械が判定できない

第5章で見た通り、誤字の修正も権利表示の書き換えも画像の差し替えも、すべて同じ drifted になります。ハッシュは二値なので「どこが変わったか」までしか言えません。

第7章で対象を記述と実体に分けたことで、画像の差し替えだけは切り出せました。ただしこれは機械が重大さを判定できるようになったのではなく、判断を先に設計へ埋め込んだだけです。rights の書き換えは、いまも誤字と同じ drifted のままです。

埋めるには主張の粒度をさらに分けるしかありません。rights だけを対象にしたライセンス証明を別に発行する、といった設計です。ただし証明書の数が増え、失効の管理も増えます。

非可逆な移行の同一性は、機械には言えない

第8章で見た通り、階調を落とすような移行の後で「これは同じ資料だ」と言っているのは機関です。検証者にできるのは、その主張に署名があることを確かめることだけで、主張の当否は確かめられません。

誰の「同一だ」を受け入れるかが、そのまま資料の同一性を決めます。 真正性の最後の一段は制度の側に残り、そこは暗号では動かせませんでした。

移行を記録し続けられるか

第8章の署名付き移行連鎖は、1件でも記録を落とすとそこで切れます。学習ハッシュ方式が持っていた「記録し忘れても後から照合できる」という性質を、正面から手放しています。

OAIS の AIP には保存記述情報を書く場所がもともとあるので、新しく足す話ではありません。ただし100年にわたって書き続けられるかは、技術ではなく組織の持続性の問題です。

提示の検証が未実装

発行された利用許諾を、本人が持っていることの証明はまだ組んでいません。

第2章の提示（challenge への署名）と同じことをやればよいのですが、Ethereum のアドレスは secp256k1 という別の曲線を使っています。試作1は P-256 なので、2本目の曲線を足す作業になります。ここは残タスクです。

有料閲覧という題材について

最後に、この本が題材にした「閲覧料」について。

閲覧の有料化それ自体を推奨するものではありません。 所蔵機関はオープンアクセスに向かっていて、「見るのに金を取る」仕組みを作ることに主張はありません。

支払いを題材にしたのは、イベントに自然な希少性があるからです。誰でもタダで書けるログは荒らされますが、支払いを伴えばコストが防波堤になります。機構としては、次のどれでも同じです。

記録する事実使いどころ
支払い経済的コストが乱発を抑える
利用申請の承認機関の判断を、機関が消せない形で残す
同意の記録撮影・公開への同意がいつ与えられたか
助成金の支出誰の資金で何が行われたか

ApprovalRegistry を並べて作ったのは、そのためです。

結論

ブロックチェーンが効いているのは、「機関が自分の過去を作り直せない」という一点だけです。

この一点は本物です。第4章の改竄シナリオ C は、追記ログもハッシュ連鎖も止められませんでした。ホストを自分で持っている限り、全体を作り直せてしまう。それを止めるには、記録が自分の管理外にある必要があります。

一方で、それ以外のほぼすべてはチェーンなしで解けます。公開鍵の配布も、署名の検証も、証明書の流通も、失効も、鍵の更新も、署名者の名簿も、フォーマット移行の追跡も。試作1と試作2 はチェーンを1バイトも使っていません。

そして第4章・第5章・第8章で、同じ形の穴に3回当たりました。自分でホストする追記ログは、公開鍵の履歴であれ、資料の版であれ、移行の連鎖であれ、丸ごと作り直せます。3回とも同じ場所で破れたことが、この穴が実装の粗さではなく構造から来ているという判断の根拠です。塞ぎ方が公開チェーンでなければならない理由のほうは、第4章で見た「参加者を事前に決めなくてよい」という一点にあります。

デジタルアーカイブの文脈で「ブロックチェーンを使うべきか」と問われたら、まず聞き返すべきなのは次のことだと思います。

改竄不能な台帳が欲しいのか、相互運用可能な検証が欲しいのか。

後者なら、チェーンは不要です。むしろ独自のチェーンを選ぶと、そのチェーン固有の DID メソッド、固有の証明書プロファイル、固有の検証手順がセットで付いてきて、国境や機関の境界で止まります。

前者だけが本当に必要なら、この本で見た形が1つの答えになります。ただしそのときは、名寄せと削除不能という代償を引き受ける覚悟が要ります。

試作の一覧

内容依存パッケージ
試作1did:key / did:web / did:webvh と VC、改竄シナリオ、witnessゼロ
試作2IIIF マニフェストの版への署名、署名者の名簿、実体への署名、移行連鎖ゼロ
試作3JPYC の残高読み取りとログ検索、決済コントラクト、did:pkh読み取りはゼロ、コントラクトは Foundry

暗号処理はすべて Node 標準の Web Crypto（ECDSA P-256）です。ライブラリを避けたのは禁欲のためではなく、中で何が起きているかを隠さないためでした。実際、ERC-20 の呼び出しデータは「セレクタ4バイト + 引数を32バイトずつ並べる」だけで、固定長の型しか使わない限りライブラリは要りませんでした。

道具の中身が見えていると、その道具が何を解いていて何を解いていないかも見えます。この本の結論は、そうやって出てきたものです。