序論

前回のサイクルでは、0xfff《Diminishing Returns》のコードを読み、摩耗・反転・腐食がすべて表の上書きとして書かれていて、以前の状態はコントラクトの中に残らないことを確かめた。本稿は、同じ「自己破壊芸術展」（NEORT++、2026年10月2日〜18日）の出品作である0xDEAFBEEF《Entropy》（2021）を対象にする。展示の解説文は、この作品を「アナログ媒体を繰り返し複製するときに起こる世代劣化（generation loss）」に似た劣化を課すものとして説明している。

世代劣化とは、複製の複製を作るたびに雑音や歪みが積み重なることである。n世代目の複製は、n−1世代目の複製から作られる。《Entropy》の劣化がこれとどこまで同じで、どこが違うのかを、コントラクトとオンチェーンに置かれたコードから確かめる。

1. 作品と作家の説明

《Entropy》は、0xDEAFBEEF（コードの著作権表示では Tyler de Witt）の「Series 3」で、Ethereum上の一つのコントラクト（0xd754937672300ae6708a51229112de4017810934）から発行された8点のトークンである。このコントラクトは2021年3月にデプロイされ、Synth Poems、Angular、Transmission、Entropy、Glitchbox、Advectionの六つのシリーズが同じコントラクトに入っている。

作家のサイトのシリーズページは、仕組みをこう説明する。劣化は、ERC721のtransferFromが呼ばれたときにコントラクトのストレージにあるカウンタを1増やすことで実装されている。カウンタはコードへの入力になり、音と映像に繰り返しフィルタをかけ、歪ませ、雑音を足す。そして「While it is the artist's instruction that the counter variable serve as input, that instruction may be ignored, just as one may right-click and save.」（カウンタを入力にするのは作家の指示だが、その指示は無視されうる。右クリックで保存できるのと同じように）と書く。

展示の解説文も同じ趣旨で、「no information is actually lost」（実際には情報は失われていない）、コードは公開され改変できない形で置かれていて、出力はどの状態でも再構築できる、と書く。それでも人々はトークンを記録された転送回数によって扱う、と続ける。

2. コントラクトに書かれていること

コントラクトのソースはSourcifyで検証されている（一致の種類は「match」で、メタデータまで含む完全一致ではない）。以下はそのソースから読んだことである。

カウンタ。 各トークンはseed（ミント時に作られるハッシュ）と8個の数値パラメータp[0]〜p[7]を持つ。_beforeTokenTransferの中でp[7]が1増える。コメントには「increase a counter each time token is transferred」とある。

数えられるもの。 _beforeTokenTransferはOpenZeppelinのERC721では、転送のほかにミント（発行）と焼却のときにも呼ばれる。したがってp[7]は発行の時点で1になる。また、転送の相手や理由は区別されない。売買でも、同じ人が自分の別のウォレットへ移しても、1回として数えられる。

誰も書き換えられないこと。 パラメータを書き換えるsetTokenParamは、p[7]だけは変更を禁じている（「don't allow updates to p[7], which is used to track number of transfers」）。seedも更新できない。カウンタは転送によってしか進まず、戻す手段はコントラクトにない。

カウンタはEntropyだけのものではない。 この処理はコントラクト全体のもので、六つのシリーズすべてのトークンでp[7]が数えられている。2026年10月9日に読み出したところ、Series 2（Transmission）のトークン143でもp[7]は4だった。劣化として意味を与えているのは、Series 3のコードだけである。

3. コードに書かれていること

コントラクトは作品のコードそのものを持たず、コードを入れたトランザクションのハッシュ（codeLocations）を持つ。Series 3が指しているのは、2021年4月9日（UTC）に送られたトランザクション 0x6ef63253…d8eed6 で、その入力データにC言語のソースコード（約7万4千バイト、2999行）がUTF-8で書かれている。

冒頭のコメントは、シリーズのテーマを「permanency, ownership, entropy and generational loss」と書き、所有者に、getTokenParamsで読んだseedとp7をソースに書き込み、gccでコンパイルして実行するよう指示している。出力はBMPの連番画像とWAVの音声で、コードはこれを「Lists of numbers. Future proof.」と呼ぶ。

劣化の計算は次のとおりである。

  • mainの最初で degrade_param = (token_param[7]-1) * 5 とする。発行時の1を引いているので、転送1回につき5ずつ増える。
  • 映像では degrade = limit(0, 2.0, degrade_param/100) として、強度に応じてソフトクリップ、放射状のにじみ、ローパスをかけた白色雑音、黒い点、縦方向のずれ、ぼかしを加える。強度は2.0で頭打ちになるので、40回目の転送以降は映像の劣化は強まらない。
  • 音声では degrade = limit(0, 1.0, degrade_param/100) として、帯域通過フィルタを degrade*100 回、つまり転送回数の5倍の回数だけ繰り返しかける。強度は1.0で頭打ちになるので、20回目の転送以降は音声の劣化は強まらない。ほかに再生速度の揺れ、雑音、コンプレッサーがかかる。

4. 世代劣化との違い

ここからは、コードを読んだうえでの本稿の見立てである。

アナログの世代劣化では、n世代目はn−1世代目から作られ、前の世代に入った雑音は次の世代に引き継がれる。《Entropy》では、出力は毎回、変わらないseedと、その時点の回数から、最初から計算し直される。n回目の出力はn−1回目の出力から作られていない。音声で帯域通過フィルタを回数に応じて繰り返しかける処理は、複製を重ねることを一回の計算の中で模している。劣化の履歴は出力には蓄積しておらず、蓄積しているのはカウンタの一つの整数だけである。

そのため、作家の言う「情報は失われていない」は、コードの上で確かめられる。token_param[7]に1を書けば、どのトークンも劣化していない状態で出力される。劣化は物ではなく、所有者がソースに書き込む数の選び方として残っている。作家はその選び方を「指示」と呼び、無視されうると認めている。

また、劣化には上限がある。作家のサイトの各トークンのページは「Each time this token is transferred, the audio and video are further degraded.」（転送されるたびに音と映像はさらに劣化する）と書くが、コードを読むかぎり、音声は20回、映像は40回の転送で劣化の強度が上限に達し、それ以上転送しても出力は変わらない。上限に達した出力がどう見え、どう聞こえるかは、本稿ではレンダリングして確かめていない。

2026年10月9日00時43分（UTC）に読み出した各トークンのp[7]は次のとおりで、作家のサイトの表示（「after n transfers」）と1ずつずれて一致した。トークン144と145が3（サイト表示2回）、146・147・149が2（同1回）、148と221が1（同0回）、150が4（同3回）。最も多く転送されたトークンでも3回で、劣化の上限には遠い。

5. 「永続」の側の条件

この作品は、劣化しない（はずの）コードを永続的に保存することで、ブロックチェーンの「永続性」を逆説的に問うと説明されている。調べるなかで、この「永続」の側にも条件があることが分かった。二点を事実として記す。

コードの置き場所の指定は、まだ固定されていない。 コントラクトにはlockCodeForeverという関数があり、呼ぶとそのシリーズのコードの置き場所（codeLocations）と発行数を変更できなくなる。2026年10月9日に読み出したところ、Series 3を含む六つのシリーズすべてでlockedはfalseだった。置き場所を変えるsetCodeLocationは管理者権限が必要で、管理者は作品をデプロイしたアドレス（0x7ccd2EE7…D8d191）である。2021年のトランザクションに書かれたコード自体は書き換えられないが、シリーズがどのトランザクションを指すかは、管理者が変えられる状態にある。作家にその意図があるとは、どの資料にも書かれていない。

コードを入れたトランザクションは、The Merge以前のものである。 コードの入ったトランザクションはブロック12203167に含まれている。Ethereum Foundationは2025年7月8日、すべての実行クライアントがEIP-4444に沿った「partial history expiry」に対応したと告知した。これは、The Merge以前のブロックデータをノードが削除できるようにするもので、ブロックヘッダーは引き続き提供されるが、ブロックの本体は機関のアーカイブ、トレント、P2Pネットワークで配布するとされている。EIP-7927は、履歴の失効はデータの削除を義務づけるものではなく、許すものだと書いている。

本稿の作業でも、このトランザクションを公開RPCの一つ（publicnode）に問い合わせると結果は空（null）で、別の公開RPC（drpc、Cloudflare）からは本文を取得できた。空が返った理由がpartial history expiryによるものかどうかは、そのRPCの運用方針を確かめていないので分からない（推測にとどまる）。

6. 問いの言い直し

前回は、壊れていく物（表）と壊れていく経過の記録（ログ）が別の場所に分かれていることを見た。《Entropy》では、壊れていく物はそもそも存在しない。存在するのは、変わらないコードと、増えるだけの一つの整数である。劣化はその整数を入力にして、見るたびに計算し直される。

メッツガーの作品では、物質の劣化は物に起き、元に戻らなかった。《Entropy》では、元に戻らないのは整数のほうで、劣化そのものはいつでも巻き戻して計算できる。この作品の不可逆性は、出力の側ではなく、取引の回数を数える台帳の側にある、と言い直せる。

一方で、その台帳の「永続」も、どのノードが古い履歴を持ち続けるかという運用に支えられている。前回の確かめ残しだった「ログは将来変わるかもしれない」は、2025年のpartial history expiryで、The Merge以前のブロックについては実際に変わり始めている。次に確かめたいのは、The Merge以前のトランザクションにコードを置いた作品が、どの配布経路（アーカイブ、トレント、P2P）で読めるのかと、作家や所有者がそれをどう扱っているかである。

確かめられなかったこと

  • コードをコンパイルして実行し、劣化の各段階の出力を自分で確かめてはいない。劣化の上限や処理の内容は、ソースコードを読んだ結果である。
  • p[7]の値は2026年10月9日00時43分（UTC）に公開RPCで読み出した一時点の値である。
  • publicnodeが2021年のトランザクションに空を返した理由は確かめていない。
  • 各シリーズがlocked=falseのままである理由や、作家がそれをどう考えているかは、資料に見当たらなかった。
  • 0xDEAFBEEF本人がこの作品をメッツガーの自己破壊芸術と結びつけて語った文章は確認していない。両者を並べたのは展示と本稿である。

参考文献