Redstone 論：それは Plasma ではなく、Optimium の変種である
TechFlow厳選深潮セレクト
Redstone 論：それは Plasma ではなく、Optimium の変種である
本稿では、Plasmaの原理とそれがなぜスマートコントラクトおよびDeFiに不適切であるか、そしてRedstoneとは一体何なのかについて紹介します。
Web3業界の深掘り報道に専念し潮流を洞察著者：Faust、Geek Web3
最近、「Redstone」というプロジェクトが注目を集めている。 Latticeチームが開発したこのゲーム特化型Layer2インフラは11月15日に正式リリースされ、現在テストネットが公開されている。興味深いことに、Latticeチームは「RedstoneはPlasmaに着想を得たAlt-DAチェーン」と述べている。
Redstoneのリリース前日、Vitalikは「EVM validiumsのエグジットゲーム：Plasmaの復活（Exit games for EVM validiums: the return of Plasma）」という記事を発表。 そこではかつてイーサリアムエコシステムから消えかけていた技術「Plasma」が簡単に振り返られ、有効性証明（ZK Proofと混同されることがある）を導入することでPlasmaの問題を解決できると指摘している。
これに対し、多くの人々はVitalikがこの記事を書いたのはRedstoneを後押しするためではないかと考えており、Geek Web3コミュニティ内でも「もしかしたらVitalikがRedstoneに投資しているのでは？」という声も出ている。さらに以前から話題になっていた「イーサリアムLayer2定義論争」も相まって、一時的に「Plasmaの復興」が起きると広く予想された。その結果、Celestiaなどのイーサリアム外部のDAソリューションが抑制される可能性があるとされた。なぜならPlasmaは厳格なDA要件を持たないからだ。
しかし本稿の筆者が調査したところ、RedstoneはPlasmaの枠組みに実際には合致しておらず、「Plasmaに着想を得た」という主張はむしろVitalikの記事のトレンドに乗ろうとした可能性が高い。 つまり、Vitalikが本当にRedstoneを支持しているわけではない。さらにRedstoneのDAチャレンジ方式は、2022年4月にLayer2プロジェクトMetisが導入した方式と非常に似ており、両者の違いはステートルートの更新とDAデータの公開の順序だけである。
つまり実際には、Redstoneに対して「過剰解釈」が行われている可能性が高い。 以下では簡単な推論を通じて読者にPlasmaの仕組み、それがなぜスマートコントラクトやDeFiに不向きなのか、そしてRedstoneが実際に何であるのかを説明する。
Plasma：データ保持攻撃に遭ったら緊急引き出し
Plasmaの歴史は2017年のイーサリアムICOブームまで遡る。当時、イーサリアムのユーザーの取引需要が爆発的に増加し、TPSの低いETHはその重圧に耐えきれなかった。こうした状況下で、Plasmaの最初の理論的バージョンが発表され、「世界中のほぼすべての金融シナリオを処理できる」スケーリングソリューションとして提案された。
簡単に言うと、PlasmaとはLayer2のブロックヘッダー／MerkleルートのみをLayer1に記録し、それ以外のデータ（DAデータ）はオンチェーンではなくオフチェーンで配布するスケーリング方式である。もしPlasmaのソータライザーやオペレーターがL1に無効なトランザクション（署名エラーなど）を含むMerkleルートを提出した場合、関係するユーザーは詐欺証明（fraud proof）を提出し、そのルートが無効であることを証明できる。
しかし問題は、詐欺証明を提出するにはDAデータが保持されていないことが保証されなければならない点にある。PlasmaはDA層に厳密な要件を設けておらず、ユーザーまたはL2ノードがデータを受け取れるかどうか保証できない。ある時点でソータライザーがデータ保持攻撃（データ可用性問題とも呼ばれる）を仕掛けて、新しいブロックヘッダーやMerkleルートは公開するが対応するブロックボディを公開しない場合、誰もそのルートが有効か否かを検証できず、ユーザーはソータライザーを「手が付けられない」と判断し、「Exit Game」と呼ばれる緊急撤退メカニズムを通じて資産をLayer2からLayer1へ引き出すしかない。
この操作では、ユーザーがL2上で実際に資産を保有していることを示すためにMerkle証明を提出する必要があり、これを「資産証明（ownership proof）」と呼ぶ。面白いことに、PlasmaのExit GameはZK Rollupのエスケープハッチとは異なる。ZK Rollupのユーザーは最新の有効なステートルートに対応するMerkle証明を提出しなければならないが、Plasmaのユーザーは古いMerkleルート（例えばかなり前のもの）に対応する証明を提出できる。
なぜこのような設計になっているのか？ ZK Rollupの場合、提出されたステートルートはLayer1上のコントラクトによって即座に検証される（有効性証明の正しさ）。そのため、直近に提出されたステートルートが有効であれば、ユーザーはそれに一致する正当なMerkle証明を資産証明として提出すべきだからである。
しかしPlasmaのソータライザーが提出したMerkleルートは、L1コントラクトが直接有効性を判断できない。代わりにL2ノードが自ら挑戦を仕掛けて無効なルートを排除する必要があるため、PlasmaとZK Rollupの動作原理は根本的に異なる。
例えば、ソータライザーが無効なMerkleルート101を公開し、同時にデータ保持攻撃を仕掛けてL2ノードがルート101が無効であることを証明できないようにした場合、ユーザーはルート100またはそれ以前のMerkle証明を提出して資産を引き出すことができる。
ただし、ここで一つの問題が生じる。あるユーザーがルート30またはそれ以前の資産証明を提出してLayer1への引き出しを要求しても、そのユーザーの資産状況はルート30以降に変化しているかもしれない。つまり、彼が提出するのは古くなった資産証明であり、これは典型的な二重払い攻撃（double spend）となる。
この問題に対し、Plasmaでは誰もが上記のようなケースについて詐欺証明を提出でき、あるユーザーが提出した「資産証明」が古くなっていることを指摘できる。このように「誰もが他人の引き出し要求に挑戦できる」仕組みにより、PlasmaはZK Rollupのように緊急引き出しリクエストを特別に処理する必要がない。
しかし依然として一つのリスクがある。 ソータライザーが他の人の資産を自分のL2アカウントに移転した後、データ保持攻撃を仕掛けて他人がその不正行為に挑戦できないようにする可能性だ。その後、ソータライザー自身が自分のアカウントから緊急引き出しを行い、「資産証明」を提出してL2上で確かにこれらの資産を保有していると主張する。
明らかに、この場合一部の履歴が欠落しており、ソータライザーの資産の出所に問題があることを直接証明することは困難になる。このときどうすればよいのか？ 初期のPlasmaバージョン（例：Plasma MVP）はこの点を考慮しており、「引き出し優先度」という概念を導入している。資産証明に対応するルートがより古いほど、その引き出しリクエストが優先的に処理される。
例えば、ソータライザーが101番目のルートを提出する際に上記の不正行為を行い引き出しを開始した場合、ユーザーは99番目またはそれ以前のルートに対応する資産証明を提出して緊急引き出しできる。つまり、ソータライザーが既にL1に公開された履歴を改ざんできない限り、ユーザーは脱出手段を持つ。
だがPlasmaには致命的なバグがある。 データ保持攻撃が発生すると、ユーザーは緊急引き出し（＝Exit Game）に頼って資産の安全性を確保せざるを得なくなるが、短期間に多数のユーザーが一斉に引き出しを行うと、Layer1が処理しきれなくなる可能性がある。
さらに深刻なのは、DeFiコントラクトが管理する資産を誰がLayer1に引き出すのかという問題だ。 仮に誰かがDEXのLPプールに100ETHを預けたとする。その後、Plasmaのソータライザーに障害または悪意的行為が発生し、緊急引き出しが必要になった場合、その100ETHはまだDEXコントラクトによって制御されている。このとき、これらの資産を誰がLayer1に引き出すべきだろうか？
最も良い方法は、まずユーザーがDEXプールから自分の資産を償還し、その後自分でL1に引き出すことだが、問題はPlasmaのソータライザーがすでに故障または悪意的行為を行っているため、ユーザーは償還操作を実行できない点にある。一方で、DEXコントラクトの所有者（owner）にコントラクトが管理する資産をL1に引き出す権限を与えると、所有者はいつでも資産を引き出して逃げられるようになり、これはあまりにも危険ではないか？
結局のところ、DeFiコントラクトによって支配される「共有財産」をどう扱うかは大きなリスクとなる。社会的合意に基づき、Layer1上でLayer2のDeFiコントラクトをミラーリングするコントラクトを再構築するという方法もあるが、これには非常に大きな負担が伴い、機会コストも高くなる。また、誰がそのミラーコントラクトの処理方法を決定するのかという投票主体の問題も生じる。これは公的権力の分配という難問に直結しており、以前「Xiangma」氏がインタビュー記事『高性能パブリックチェーンは新事象を生みにくい――スマートコントラクトは権力分配を含む』で言及していた点でもある。
もちろん、Vitalikの最近の記事「Exit games for EVM validiums: the return of Plasma」でもこの点が指摘されており、これがPlasmaがスマートコントラクトに不向きな理由の一つだと強調している。 過去の有名なPlasma派生形（Plasma MVPやPlasma Cashなど）は、イーサリアムのアカウントモデルではなくUTXOまたは類似モデルを採用しており、スマートコントラクトもサポートしていない。これにより上記の「資産所有権の分配」問題を回避できるが、UTXO自体にも多くの欠点があり、スマートコントラクトには不向きである。従ってPlasmaは単純な支払い処理や板形式取引所に最も適している。
その後、ZK Rollupの台頭とともにPlasmaは歴史の舞台から退場した。 RollupにはPlasmaのようなデータ保持問題が存在しないためだ。ZK Rollupのソータライザーがデータ保持攻撃を仕掛け、ETHチェーンにステートルートのみを提出してDAデータを公開しない場合、そのルートは無効と判定され、L1上のVerifierコントラクトによって拒否される。したがって、ZK Rollupの有効なステートルートに対応するDAデータはETHチェーン上で必ず照会可能となる。「ブロックヘッダーやMerkleルートだけを公開し、対応するブロックボディを公開しない」というデータ可用性問題／データ保持攻撃は解決される。
また、Rollupの過去のDAデータはイーサリアム上で照会可能であり、誰もがETHチェーンの履歴を使ってL2ノードを起動できるため、非中央集権的かつ許可不要のソータライザー実現のハードルが大幅に下がる。一方、PlasmaはDAに厳密な要件を設けていないため、非中央集権的ソータライザーの実装もより困難になる（交換可能な非中央集権的ソータライザーを実現するには、まずすべてのL2ノードが同じブロックを認識している必要があり、これはDA方式に一定の要件を課すことになる）。
さらに、ZK Rollupのソータライザーが無効なトランザクションをL2ブロックに含めようとしても、有効性証明の仕組みにより不可能となる。
結局のところ、ZK Rollupのソータライザーの悪意的行動の余地はPlasmaと比べてはるかに狭い——せいぜいステートルートの更新が停止する（UX的にはダウンタイム）、あるいは特定ユーザーのリクエストを拒否する（トランザクションの検閲）程度である。また、Rollup方式ではソータライザーに障害が発生しても、他のノードが容易に代替できる。 理想的なRollupでは、PlasmaにおけるExit Gameのトリガー確率をゼロに近づけることができる（ZK Rollupではエスケープハッチと呼ばれる）。
（L2BEATの「Proposer Failure」欄では、各L2ソリューションがソータライザー障害に対処する方法を示しており、「Self Propose」は他のノードがダウン中のソータライザーに代わることができる状態を意味する）
今日において、イーサリアムエコシステム内ではPlasma路線を継続するチームはほとんど存在せず、ほぼすべてのPlasmaプロジェクトは中止または失敗に終わっている。
（VitalikによるZK RollupがPlasmaより優れている理由の説明。許可不要のソータライザー運営およびDA問題に言及）
Redstoneとは何か：Plasmaではない、Optimiumの派生形
以上でPlasmaとそれがRollupに取って代わられた要因を簡単に説明したが、Redstoneについては、おそらくそのPlasmaとの違いに気づいたことだろう。Redstoneはデータ保持攻撃の問題を解決できる。 例えば、新しいステートルートをすぐに公開せず、まずETHチェーン外に元のDAデータを公開し、そのDAデータのdatahashを関連付ける証拠（commitment）としてETHチェーン上に提出し、「対応するdatahashの完全なデータをチェーン外に公開済み」と宣言する。
（Redstone公式がデータ保持攻撃防止策についての説明）
誰もが挑戦を仕掛け、「Redstoneのソータライザーはdatahashに対応する元データをチェーン外に公開していない」と主張できる。このとき、ソータライザーはそのdatahashに対応するデータをチェーン上に公開して、挑戦者に対応しなければならない。 もし挑戦後にソータライザーがETHチェーン上にデータを及时に公開しなかった場合、その前に提出されたdatahash／commitmentは無効と見なされる。
ソータライザーが挑戦者の要求に適切に対応すれば、挑戦者はdatahashに対応する元のDAデータを確実に取得できる。最終的に、すべてのL2ノードは必要なDAデータをほぼ確実に取得でき、データ保持攻撃の問題が解決される。 当然ながら、挑戦者自身はある程度の費用を前払いする必要があり、その額はソータライザーがETHチェーン上に元DAデータを公開するコストにほぼ等しい。これは悪意のある挑戦者がコストゼロでソータライザーを攻撃し、損失を被らせることを防ぐための措置である。
最後に、datahashに対する挑戦期間が終了した後、ソータライザーは対応するステートルートを公開する。 つまり、datahashに対応するDAデータに含まれるトランザクション列を実行した結果得られるルートである。この時点でL2ノードは詐欺証明システムを使って無効なルートに挑戦できる。もし以前にdatahashが挑戦された際、ソータライザーが対応する元DAデータを及时に公開していなければ、その後にそのdatahashに対応するステートルートを公開しても無効とみなされる。
つまり、RedstoneはまずDAデータを公開し、その後に有効なステートルートを公開することで、データ保持攻撃の問題を直接解決している（ソータライザーがルートだけを公開しDAデータを公開しないケース）。
明らかにこの方式は一般的なOptimium（イーサリアムを使わないOP Rollup、例：Arbitrum Nova）とは異なる。Optimiumは通常、チェーン外のDAC委員会に依存してデータ可用性を確保しており、DACは定期的にマルチシグトランザクションをチェーン上に提出する。Rollupコントラクトはそれを受信すると、ソータライザーがチェーン外に最新のDAデータを公開済みと見なす。
（画像出典：L2beat）
一方、MetisやArbitrum Novaなどはステートルートとdatahashを同時に提出する。誰かがソータライザーがDAデータを保持していると感じれば挑戦を試み、ソータライザーはdatahashに対応するDAデータをチェーン上に公開する。
したがって、RedstoneとMetisの鍵となる違いはここにある： 前者はまずdatahashを公開し、DAの挑戦期間が終了してからステートルートを公開する。Metisはステートルートとdatahashを同時に公開し、挑戦があればDAデータをチェーン上に載せる。明らかにRedstoneの方式の方が安全である。 Metisの場合、ソータライザーが挑戦者からのDAデータ要求にずっと応じなければ、データ保持攻撃の問題は迅速に解決できず、緊急引き出しや社会的合意、あるいは他のノードによるソータライザーの代替に頼らざるを得なくなる。
一方、Redstoneの場合、ソータライザーがデータ保持攻撃を行えば、そのステートルートは直ちに無効と見なされる。つまりステートルートとDAデータは結びついているため、RedstoneはRollupに近いDA保証を得ることができ、本質的にArbitrum NovaやMetisよりも優れたOptimiumの派生形と言える。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@godrealmx
