古典籍を1件登録したとき、Sepolia に何が書き込まれたのか。全部読み出して並べます。

結論から言うと、17 個のイベントが残り、そのうち資産固有の中身を持つものは 1 個だけでした。しかもその1個は暗号化されていて読めません。

先に、4つの言葉を区別します

この章から、似た言葉が並んで出てきます。混同しやすいので、先に整理します。

言葉意味数えると
契約（コントラクト）チェーン上に置かれたプログラム今回はログを出した契約が 4 つ
取引（トランザクション）契約を呼び出す1回の依頼今回は2本
イベント（ログ）処理の中でプログラムが書き残した1行今回は17個
ブロック取引をまとめて確定させる単位2 本が 2 つのブロックに入った
資産（アセット）データスペースに登録した 1 件分今回は『歳旦発句牒』の IIIF マニフェスト 1 件

工事にたとえると、こうなります。契約は仕事を引き受けてくれるお店、取引はそこへ出す発注書が 1 枚、イベントはお店が付ける作業日誌の 1 行です。1枚の発注書に対して日誌が何行も増えるのと同じで、1本の取引から、イベントはいくつでも出ます。

区別が効いてくるのは費用のところです。手数料がかかるのは取引を出すときで、イベントはその中で発生します。イベントが多いほど手数料は上がりますが、イベント自体を単独で出すことはできません。

以降、「イベント」という語はこの意味で使います。

用意するもの

何も要りません。ウォレットも、テスト通貨も、アカウント登録も不要です。

チェーンは公開された台帳なので、誰でも問い合わせられます。付属ツールの取引を読むページに、次のハッシュを貼ってください。

0x2b699f1d67904dc675e204702318bf7c4bca9cb53e38ecfaed3252f0cecb9103

すぐ見たい場合はこの取引の解析結果を直接開けます。

同じことは Etherscan でもできます。汎用のエクスプローラとしては Etherscan のほうが優秀なので、本書のツールは重ならない3点だけを足しています——保管領域に書いた場合との費用比較、data: URI のその場デコード、平文／暗号化／不在の仕分けです。

取引の「外側」に書かれていること

まず、取引そのものの情報です。これは中身に関係なく必ず残ります。

項目値
送信者0xa60eF4E6E8F821F3bd5D42f8067BD5d4a96e0CEf
宛先0x04ECc497632847529FC431bA780Ffc573Fe4aC47
ブロック番号11482339
使ったガス516,615
手数料0.001330 ETH（テストネットの ETH なので、金銭的な価値はありません）
送ったデータ3,940 バイト

送信者のアドレスは必ず平文で残ります。これは選べません。誰が書いたかを記録するのがチェーンの役目だからです。

匿名だと言われることがありますが、正確には仮名です。アドレスと実名が結びつく機会（取引所への入金など）が一度でもあれば、過去の履歴も遡って紐づきます。そして一度書かれたものは消せません。

取引の中身 — イベント

取引が実行されると、契約はイベントという形で「何をしたか」を書き残します。これが実質的な中身です。

ここからは 1 本目のほうを見ます。同じ要領で、次のハッシュを貼ってください。

0x2d29cc0626971b6c71bc135e4f68bbe711da1b16f6098664724bf4a7f7f8bc84
Read a transaction | Chain Lens — learn by reading transactions
Read one transaction recorded on an Ethereum testnet and sort out what stays in plain text, what is encrypted, and what was never written at all.
chain-lens-amber.vercel.app

1 本目の取引（NFT を作ったほう）では、15 個のイベントが出ていました。抜粋します。

NFTCreated
  newTokenAddress = 0x04ECc497632847529FC431bA780Ffc573Fe4aC47
  tokenName       = "PX Data NFT"
  symbol          = "PX-NFT"
  transferable    = true
  creator         = 0xa60eF4E6E8F821F3bd5D42f8067BD5d4a96e0CEf

Transfer
  from    = 0x0000000000000000000000000000000000000000
  to      = 0xa60eF4E6E8F821F3bd5D42f8067BD5d4a96e0CEf
  tokenId = 1

TokenCreated
  newTokenAddress = 0x6011B8BA5AcD3BBb925Fa793E125BfE750ae3655
  name            = "Access Token"
  symbol          = "GXAT"

Transfer の from が 0x000…000（ゼロアドレス）になっているのに注目してください。「無から誰かへ移った」という形で、新規発行を表現しています。NFT の発行に専用のイベントはなく、送り主がいない移転として書かれます。

登場した契約は4つ

1件登録しただけで、4つの契約が関わっていました。

契約アドレス役割
工場（ERC721Factory）0xEF62FB49…以前から在るもの。NFT を量産する
Data NFT0x04ECc497…今回作られた。資産そのもの
アクセストークン0x6011B8BA…利用権を表す引換券（GXAT）
Dispenser0x2720d405…以前から在るもの。無償配布の記録をここに登録した

「NFT を 1 つ作った」つもりが、契約が 2 つ新設されていました（NFT とアクセストークン）。Dispenser と工場は以前から在るもので、そこに記録が足されただけです。1 本目が使ったガスは約 1,300,000 で、2 本目（516,615）の 2.5 倍です。理由はこれです（5 章）。

資産の中身を持つイベントは 1 個だけだった

2本目の取引のイベントは2個です。

MetadataCreated
  createdBy    = 0xa60eF4E6E8F821F3bd5D42f8067BD5d4a96e0CEf
  state        = 0
  decryptorUrl = http://…:8001
  flags        = 0x02
  data         = 0x04009ab5bfa68348330fb182c0e8a8eb85…  ← 2,872 バイト
  metaDataHash = 0xc717a9eb053d7b23db3da5b30a26ba4c57a19939e697fc52c10691b055d5d78b

TokenURIUpdate
  tokenURI = data:application/json;base64,eyJuYW1lIjoiUFggRGF0YSBORlQi…

data の 2,872 バイトが、この資産の全メタデータです。題名も、説明も、ライセンスも、ファイルの場所も、全部この中。

そして暗号化されています。貼り付けても読めません。読める形にできるのは、decryptorUrl に書かれたサーバだけです（9 章）。

仕分けてみる

全17個のイベントを、3つに分けます。この仕分けが、この本で一番大事な整理だと考えています。

① 平文で、誰でも、永久に読めるもの

  • 公開した人のアドレス
  • NFT・アクセストークン・Dispenser の各アドレスと、名前（PX Data NFT / Access Token / GXAT）
  • 権限の設定（誰が管理者か、誰が発行できるか）
  • 譲渡可能かどうか（transferable = true）
  • 手数料の設定と、その受取先アドレス
  • 復号を頼むサーバの URL
  • 取引の日時・手数料・ブロック番号

② 載っているが、読めないもの

  • 暗号化された 2,872 バイト。題名・説明・ライセンス・ファイルURLが入っている

③ 平文としては載っていないもの

②の中に暗号化されて入っているだけで、平文ではどこにも無いものです。

  • 題名「歳旦発句牒」という文字列
  • 「国立国会図書館」という機関名
  • ライセンス（CC-PDDC）

暗号化された中にも無いものもあります。

  • 資料そのもの（IIIF マニフェストの中身、画像）

チェーンだけを見ても、これが何の資料なのか一切分かりません。 分かるのは「誰かが何かを登録し、その復号先はここだ」という構造だけです。

ここから考えられること

「ブロックチェーンで来歴を保証する」の中身

保証されているのは、「このアドレスの持ち主が、この時刻に、このハッシュのメタデータを登録した」という一点です。

保証されていないものを並べると、性格がはっきりします。

  • 登録した人が名乗るとおりの人物か（チェーンは身元を確認しません。10 章）
  • メタデータの内容が正しいか（書けたことしか保証しません）
  • ファイルの URL が生きているか（チェーンは外を見ません）
  • 資料が本物か

「改竄されていない」と「正しい」は別のことです。チェーンが守るのは前者だけです。

消せないものを、意図せず載せてしまう

decryptorUrl に注目してください。ここには私が立てたサーバの IP アドレスが平文で入っています。

これは仕様上必要な情報です。利用者は「どこに復号を頼めばよいか」を知る必要があるからです。ですが結果として、そのサーバの所在は公開台帳に永久に記録されました。サーバを消しても、記録は残ります。

同じことは、他の項目にも起こり得ます。

  • 資産の説明文を暗号化しない設定で公開すれば、その文章は永久に公開されます
  • 一度公開したメタデータは、更新はできても、過去の版は消せません（履歴が積み重なるだけです）

「あとで消す」が効かない——これが実務上いちばん効く性質だと私は思っています。個人情報や、公開範囲の定まっていない資料情報を扱うなら、書く前に決着をつけておく必要があります。

章のまとめ

  • チェーンを読むのに費用も鍵も要らない
  • 1 件の登録で 17 個のイベントが生まれ、ログを出した契約は 4 つ。うち新設は 2 つ
  • 内容を持つのは暗号化された1個だけ
  • 資料の題名も機関名もライセンスもチェーンには無い
  • 保証されるのは「誰が・いつ・どのハッシュを書いたか」だけ
  • 消せない。意図せず載るもの（サーバの所在など）に注意

次章では、いま並んだ 20 バイトの識別子を見分けるところから始めます。どれが人で、どれがプログラムなのか、見た目からは分かりません。