Plasmaがスマートコントラクトをサポートしない理由の解析：データ保持と詐欺証明
TechFlow厳選深潮セレクト
Plasmaがスマートコントラクトをサポートしない理由の解析：データ保持と詐欺証明
Plasmaはデータ保持問題を解決できず、またコントラクトの状態をLayer1に移行することも不利であるため、必然的に廃止されることになる。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Faust、Geek web3
Plasmaが長期間埋もれていた理由、そしてVitalikがRollupを強く支持する背景には主に二つのポイントがある。一つは、イーサリアムのレイヤー2（L2）でデータ可用性（DA）を実現することが信頼できないこと、つまり容易にデータ保持攻撃（データホルディング攻撃）が発生し、それが起これば詐欺証明（Fraud Proof）の展開が困難になる点。もう一つは、Plasmaのメカニズム設計自体がスマートコントラクトに対して非常に非友好であり、特にコントラクト状態をレイヤー1（L1）へ移行することをサポートするのが難しいという点である。この二つにより、Plasmaは基本的にUTXOモデルまたはそれに近いモデルしか採用できなくなっている。
上記二つの核心的な見解を理解するために、まずDAとデータ保持問題について説明する。DAとはData Availabilityの略で、「データ可用性」と直訳されるが、現在多くの人が誤って使用しており、「履歴データが参照可能であること」と混同されがちである。しかし実際には、「履歴データの参照可能性」や「ストレージ証明（Proof of Storage）」はFilecoinやArweaveなどが既に解決済みの課題である。イーサリアム財団やCelestiaの定義によれば、DA問題とは純粋にデータ保持シナリオを扱うものである。
Merkle Tree と Merkle Root、および Merkle Proof
データ保持攻撃とDA問題の意味を明らかにするために、まずMerkle RootとMerkle Treeについて簡単に説明する必要がある。イーサリアムや大多数のパブリックブロックチェーンでは、アカウント全体の状態の要約／ディレクトリ、あるいは各ブロック内にパッケージされたトランザクションを記録するために、Merkle Treeと呼ばれる木構造のデータ構造が用いられている。
Merkle Treeの最下層にある葉ノードは、トランザクションやアカウント状態などの元データのハッシュ値から構成されており、これらのハッシュ値を二つずつ組にして反復的に計算することで、最終的に一つのMerkle Rootを得ることができる。
（図中の最下部にあるrecordが葉ノードに対応する元データセット）
Merkle Rootには次のような性質がある：Merkle Treeの底層にあるいずれかの葉ノードが変化すると、計算されるMerkle Rootも変化する。したがって、異なる元データセットに対応するMerkle Treeはそれぞれ異なるMerkle Rootを持つ。これは異なる人々が異なる指紋を持つことに似ている。また、Merkle Proofと呼ばれる検証技術は、この性質を利用している。
上の図を例にすると、李剛（リ・ガン）が図中のMerkle Rootの数値だけを知っていて、完全なMerkle Treeに含まれるデータを知らないとする。我々が李剛に、Record 3が確かに図中のRootに関連していること、つまりRecord 3のハッシュが該当するMerkle Tree上に存在することを証明したい場合、
Merkle Tree全体やそのすべての葉ノードを送るのではなく、Record 3と灰色でマークされた3つのdigestデータブロックを李剛に送るだけでよい。これがMerkle Proofの簡潔性である。Merkle Treeの底層に非常に多くのレコード（例えば2の20乗個、約100万個）がある場合でも、Merkle Proofは最低21個のデータブロックで済む。
（図中のデータブロック30とH2でMerkle Proofを構成し、データブロック30がH0に対応するMerkle Tree上に存在することを証明できる）
ビットコイン、イーサリアム、クロスチェーンブリッジなどでは、Merkle Proofの「簡潔性」がよく使われる。いわゆるライトノードは、前述の李剛のようなもので、フルノードから完全なブロックではなく、ブロックヘッダー（header）だけを受け取る。ここで強調すべきは、イーサリアムではState Trieと呼ばれるMerkle Treeが全アカウントの要約として使われており、State Trieに関連するアカウント状態が変化すれば、State TrieのMerkle Root（StateRootと呼ばれる）も変化するということである。
イーサリアムのブロックヘッダーにはStateRootが記録されており、同時にトランザクションツリーのMerkle Root（Txn Root）も記録されている。トランザクションツリーと状態ツリーの違いは、底層の葉ノードが表すデータが異なる点にある。たとえば100番目のブロックに300件のトランザクションが含まれていれば、トランザクションツリーの葉ノードはこれら300件のTxnを表す。
もう一つの違いは、State Trieの全体データ量が非常に大きく、底層の葉ノードはイーサリアム上のすべてのアドレス（実際には多くの古くなった状態ハッシュも含む）に対応しているため、State Trieの元データセットはブロック内に公開されず、ブロックヘッダーにはStateRootのみが記録される。一方、トランザクションツリーの元データセットは各ブロック内のTxnデータであり、そのTxnRootもブロックヘッダーに記録される。
ライトノードはブロックヘッダーのみを受け取り、StateRootとTxnRootしか知らないため、Rootから完全なMerkle Treeを逆算することはできない（これはMerkle Treeとハッシュ関数の性質による）。したがって、ライトノードはブロック内に含まれるトランザクションデータや、State Trieに対応するアカウントの変更内容を知ることができない。
王強（ワン・チャン）があるライトノード（前述の李剛）に、100番目のブロックに特定のトランザクションが含まれていることを証明したい場合、ライトノードが100番目のブロックのヘッダーとTxnRootを知っていることが前提となる。この場合、問題はそのトランザクションがTxnRootに対応するMerkle Tree上に存在することを証明することに帰着する。このとき、王強は対応するMerkle Proofを提出すればよい。
多くのライトクライアント型クロスチェーンブリッジでは、上述のライトノードとMerkle Proofの軽量性と簡潔性がよく利用される。例えばMap ProtocolなどのZKブリッジでは、ETHチェーン上にコントラクトを設置し、他チェーン（例：Polygon）のブロックヘッダーを受信する。RelayerがETHチェーン上のコントラクトにPolygonの100番目のブロックヘッダーを提出すると、コントラクトはヘッダーの有効性（例：Polygonネットワーク内の2/3のPoSノードの署名が集まっているか）を検証する。
ヘッダーが有効であり、あるユーザーがPolygonからETHへのクロスチェーンTxnを発行し、それがPolygonの100番目のブロックにパッケージされていると主張する場合、彼はMerkle Proofによって、自分が発行したクロスチェーンTxnが100番目のブロックヘッダーのTxnRootに対応すること（言い換えれば、自分の発行したクロスチェーンTxnがPolygonの100番目のブロック内に記録されていること）を証明すればよい。ただしZKブリッジではゼロ知識証明により、Merkle Proof検証に必要な計算量を圧縮し、クロスチェーンブリッジコントラクトの検証コストをさらに削減している。
DAとデータ保持攻撃問題
Merkle Tree、Merkle Root、Merkle Proofの説明を終え、冒頭で触れたDAとデータ保持攻撃問題に戻る。この問題は2017年以前から議論されており、Celestiaのオリジナル論文ではDA問題の起源に関する文献調査が行われている。Vitalik自身も2017～2018年のドキュメントで、ブロック生成者が意図的にブロックの一部データを隠蔽し、不完全なブロックを外部に公開する可能性について言及している。こうなると、フルノードはトランザクションの実行／状態遷移の正当性を確認できなくなる。
このとき、ブロック生成者はユーザーの資産を盗むことができる。例えばAアカウントのコインを他のアドレスにすべて移動しても、フルノードはA本人が本当にそうしたのかどうか判断できない。なぜなら最新ブロックに含まれる完全なトランザクションデータを知らないからである。
ビットコインやイーサリアムなどのレイヤー1（L1）パブリックチェーンでは、正直なフルノードがこのような無効ブロックを直接拒否する。しかしライトノードは異なり、ネットワークからブロックヘッダー（Header）のみを受け取るため、StateRootやTxnRootしか知らず、ヘッダーと二つのRootに対応する元ブロックが有効かどうかは分からない。
ビットコインの白書では、このような状況に対するアイデアが示されており、中本氏は多くのユーザーが設定要件の低いライトノードを運用する傾向にあると考え、ライトノードはブロックヘッダーに対応するブロックが有効かどうか判断できないが、無効ブロックがあれば正直なフルノードがライトノードに警告を出すと考えていた。
しかし中本氏はこの案をさらに詳細に分析しておらず、後にVitalikやCelestiaの創設者Mustafaがこのアイデアを基に、他の先人の成果と統合し、DAデータサンプリングを導入。正直なフルノードが各ブロックの完全なデータを再構築でき、必要に応じて警告を発出できるようにした。
Plasmaの詐欺証明
簡単に言えば、Plasmaはレイヤー2（L2）のブロックヘッダーのみをレイヤー1（L1）に公開するスケーリングソリューションであり、ブロックヘッダー以外のDAデータ（完全なトランザクションデータセット／各アカウントの状態変化）はオフチェーンで公開される。言い換えると、Plasmaはライトクライアントベースのクロスチェーンブリッジのように、ETHチェーン上のコントラクトでL2のライトクライアントを実装し、ユーザーがL2からL1へ資産を移動する際に、自分が実際にその資産を所有していることを証明するためにMerkle Proofを提出しなければならない。
L2からL1への資産移動の検証ロジックは、前述のZKブリッジと類似しているが、PlasmaのブリッジモデルはZK証明ではなく詐欺証明に基づいており、「オプティミスティックブリッジ」とも呼ばれるものに近い。Plasmaネットワーク内でL2からL1への引き出し要求は即時には許可されず、「チャレンジ期間」が設けられる。このチャレンジ期間の目的については後述する。
Plasmaはデータ公開／DAに対して厳格な要求を設けておらず、Sequencer／Operatorはオフチェーンで各L2ブロックを放送し、取得を希望するノードが自ら取得する。その後、SequencerはL2ブロックのヘッダーをL1に公開する。例えば、Sequencerがまずオフチェーンで100番目のブロックを放送し、その後ヘッダーをオンチェーンに公開する。もし100番目のブロックに無効なトランザクションが含まれていた場合、任意のPlasmaノードは「チャレンジ期間」終了前にETH上のコントラクトにMerkle Proofを提出し、100番目のブロックヘッダーが無効なトランザクションに関連していることを証明できる。これが詐欺証明の一場面である。
Plasmaの詐欺証明の応用シーンには以下の幾つかがある：
1. Plasmaネットワークの進行が200番目のブロックに達したと仮定し、ユーザーAが100番目のブロック時点で10ETHを保有していたと引き出しを宣言する。しかし実際には、ユーザーAは100番目のブロック以降にそのETHを使ってしまっていた。
つまり、ユーザーAの行為は「10ETHを使ってしまった後、過去に10ETHを持っていたと宣言し、それを引き出そうとする」ものであり、典型的な「二重支出（ダブルスピンド）」である。このとき、誰でもMerkle Proofを提出して、ユーザーAの最新の資産状況が引き出し宣言を満たしていないことを証明できる（つまり、100番目のブロック以降にユーザーAが宣言した金額を持っていないことを証明できる）。ただし、異なるPlasma方式ではこのケースの証明方法が異なり、アカウントアドレスモデルの二重支出証明はUTXOモデルよりもはるかに複雑である。
2. UTXOモデルに基づくPlasma方式（従来は主にこれだった）では、ブロックヘッダーにStateRootは含まれず、TxnRootのみが含まれる（UTXOはイーサリアム型のアカウントアドレスモデルをサポートせず、State Trieのようなグローバル状態設計もない）。つまり、UTXOモデルのチェーンにはトランザクション記録しかない。
この場合、Sequencer自身が二重支出攻撃を行う可能性がある。例えば、すでに使われたUTXOを再度使う、またはユーザーにUTXOを無から生成するなど。 どのユーザーでもMerkle Proofを提出して、そのUTXOの使用記録が過去のブロックに存在すること（＝使われた）、またはそのUTXOの履歴的由来に問題があることを証明できる。
3. EVM互換／State Trie対応のPlasma方式の場合、Sequencerが無効なStateRootを提出する可能性がある。例えば、100番目のブロック内のトランザクションを実行した後、StateRootはST+に変換されるべきだが、SequencerがL1に提出するのはST-である。
このような場合の詐欺証明はより複雑で、イーサリアムチェーン上で100番目のブロックのトランザクションを再実行する必要があり、計算量と入力パラメータが必要とするガス量が非常に大きくなる。初期のPlasmaチームはこのような複雑な詐欺証明を実現するのが難しく、そのため多くがUTXOモデルを採用した。UTXOに基づく詐欺証明は簡潔で実装しやすい（最初に詐欺証明を実装したRollupソリューションFuelもUTXOに基づいている）。
データ保持とExit Game
もちろん、上記の詐欺証明が機能するのは、DA／データ公開が有効な場合に限られる。もしSequencerがデータ保持を行い、オフチェーンで完全なブロックを公開しなければ、PlasmaノードはL1上のブロックヘッダーが有効かどうか確認できず、当然ながら詐欺証明も正常に発行できない。
このとき、Sequencerはユーザーの資産を盗むことができる。例えば、AアカウントのコインをすべてBアカウントに移動し、その後BアカウントからCアカウントに転送し、最後にCの名義で引き出しを行う。BとCのアカウントはSequencerが所有しており、B→Cのトランザクションは外部に公開されても問題ない。しかし、SequencerはA→Bの無効なトランザクションのデータを保持し、他人がBとCの資産の由来に問題があることを証明できなくなる（Bの資産由来に問題があることを証明するには、「Bに送金したトランザクション」のデジタル署名が不正であることを指摘する必要がある）。
UTXOベースのPlasma方式にはこれに対する対策があり、例えば誰かが引き出しを行う際に資産の全履歴的由来を提出させるなどがあるが、その後さらに改良が加えられた。しかしEVM互換のPlasma方式では、この点で非常に弱い。コントラクト関連のトランザクションが絡む場合、オンチェーンでの状態遷移検証には巨額のコストがかかるため、アカウントアドレスモデルとスマートコントラクトをサポートするPlasmaでは、引き出しの有効性を検証する仕組みを実現するのが難しい。
さらに、上記の話題を離れて、UTXOベースであろうとアカウントアドレスモデルベースであろうと、Plasmaでデータ保持が発生すれば、人々の恐慌を引き起こす可能性が高い。なぜならSequencerがどのようなトランザクションを実行したか誰にも分からないからである。Plasmaノードは異常を感じ取れるが、具体的な詐欺証明を発行できない。なぜなら詐欺証明に必要なデータをPlasma Sequencerが公開していないからである。
このとき、人々は対応するブロックヘッダーしか見えず、ブロック内に何があるか、自分のアカウント資産がどうなったか分からない。そのため、全員が一斉に引き出しを宣言し、過去のブロックに対応するMerkle Proofを使って引き出しを試みる。これにより「Exit Game」と呼ばれる極端な状況が発生し、踏みつけ（クラッシュ）が起き、L1が深刻に混雑し、依然として一部の人々が資産を失うことになる（正直なノードからの通知を受け取っていない人、またはTwitterをチェックしない人は、Sequencerがコインを盗んでいることに気づかない）。
したがって、Plasmaは信頼性の低いL2スケーリングソリューションであり、データ保持攻撃が発生すれば「Exit Game」がトリガーされ、ユーザーが損失を被りやすくなる。これが廃れてしまった大きな理由の一つである。
Plasmaがスマートコントラクトをサポートしにくい理由
Exit Gameとデータ保持問題を説明した上で、なぜPlasmaがスマートコントラクトをサポートしにくいのか、主に二つの理由がある：
第一に、DeFiコントラクトの資産の場合、誰がそれらをL1に引き出すのか？これは本質的にコントラクトの状態をL2からL1に移行することに等しい。例えば、誰かがDEXのLPプールに100ETHを預けた後、PlasmaのSequencerが悪意を持ったとしよう。人々が緊急に引き出しを試みるとき、その100ETHはまだDEXコントラクトによって管理されている。このとき、これらの資産を誰がL1に引き出すべきだろうか？
最も良い方法は、ユーザーにまずDEXから資産を償還させ、その後ユーザー自身がL1に引き出すことかもしれない。しかし問題は、Plasma Sequencerがすでに悪意を持っているため、いつでもユーザーのリクエストを拒否する可能性がある。
それならば、DEXコントラクトにOwnerを事前に設定し、緊急時にコントラクト資産をL1に引き出すことを許可するというのはどうだろうか？明らかに、これはコントラクトのOwnerに公共資産の所有権を与えてしまう。Ownerはいつでもその資産をL1に引き出して逃げられる。これはあまりに恐ろしいではないか？
明らかに、DeFiコントラクトが支配する「公共財」をどのように処理すべきかは巨大な地雷である。これは実質的に公的権力の分配問題に突き当たるもので、かつて響馬氏はインタビュー『高性能パブリックチェーンは新事が出にくく、スマートコントラクトは権力分配を含む』でこの点に触れている。
第二に、コントラクトの状態移行を許可しないと、巨額の損失を被る。一方、コントラクトが自身の状態をL1に移行することを許可すれば、Plasmaの詐欺証明では解決が難しい二重支出が発生する：
例えば、Plasmaがイーサリアムのアカウントアドレスモデルを採用し、スマートコントラクトをサポートすると仮定する。あるミキサー（混幣器）に現在100ETHが預けられており、そのOwnerはBobが制御しているとする。
Bobが100番目のブロックでミキサーから50ETHを引き出したと仮定する。その後、Bobが引き出しを宣言し、この50ETHをL1に移動する。
さらに、Bobは過去のコントラクト状態スナップショット（例えば70番目のブロック）を使用して、ミキサーの過去の状態をL1に移行する。これにより、ミキサーが「かつて保有していた」100ETHもL1に移動される。
明らかに、これは典型的な「二重支出」、つまりダブルスピンである。BobはL1に150ETHを引き出したが、L2ネットワークのユーザーはミキサー／Bobに100ETHしか支払っていない。50ETHが空中分解のように消失した。これによりPlasmaの準備金が枯渇してしまう可能性がある。理論的には人々が詐欺証明を発行し、ミキサーのコントラクト状態が70番目のブロック以降に変化したことを証明できる。
しかし、70番目のブロック以降、ミキサーモントラクトと相互作用したすべてのトランザクションがコントラクト状態を変えなかったとすると、Bobが50ETHを引き出したトランザクションを除けば、証拠を提示してミキサーの状態が70番目以降に変化したことを示すには、イーサリアムチェーン上で上記のすべてのトランザクションを再実行する必要がある。ようやくPlasmaコントラクトがミキサーの状態が実際に変化したことを確認できる（これほど複雑なのはPlasma自体の構造による）。もし一連のトランザクション数が極めて多ければ、詐欺証明はL1上で発行できない（イーサリアムの単一ブロックのガス上限を超えてしまう）。
理論的には、上記のダブルスピンシナリオでは、ミキサーの現在の状態スナップショット（StateRootに対応するMerkle証明）を提出すればよいように思えるが、実際にはPlasmaはオンチェーンでトランザクションデータを公開しないため、コントラクトは提出された状態スナップショットが有効かどうか確認できない。なぜならSequencer自身がデータ保持を仕掛けて、無効な状態スナップショットを提出し、任意の引き出し者を悪意を持って告発する可能性があるからだ。
例えば、あなたが自分のアカウントに50ETHがある
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@godrealmx
