なぜプラズマが長い間埋もれていたのか、そしてなぜVitalikがロールアップを強力に支持するのかについて、手がかりは主に2つの点に集中しています。Ethereumチェーンの下でDAを実装することは信頼できないため、データの隠蔽が起こりやすい。データの隠蔽が発生すると、詐欺証明が難しくなります。プラズマ自体のメカニズム設計はスマートコントラクトに非常に不親切であり、契約状態をLayer 1に移行することが特に困難です。これらの2つの点により、プラズマは基本的にUTXOや類似モデルのみを使用することになります。

上記の2つの中核的なポイントを理解するためには、DAとデータの保持の問題から始めましょう。DAのフルネームはData Availabilityであり、文字通りデータの利用可能性と翻訳されます。現在、多くの人々によって誤用されています。それほどまでに、それは「過去のデータを確認できる」と混同されています。しかし実際には、「過去のデータを確認できる」と「ストレージ証明」は、FilecoinとArweaveがすでに解決しています。Ethereum FoundationとCelestiaによると、DAの問題は純粋にデータの保持シナリオを探究しています。

Merkle TreeとMerkle RootとMerkle Proof

データの保持攻撃とDAの問題が実際に何を意味するのかを説明するには、まずMerkle RootとMerkle Treeについて簡単に話す必要があります。Ethereumやほとんどの公開チェーンでは、すべてのアカウントの状態の要約/ディレクトリとして機能するMerkle Treeと呼ばれる木構造のデータ構造が使用されるか、または各ブロックにパッケージ化されたトランザクションを記録するために使用されます。

Merkle Treeの底辺にある葉ノードは、取引や口座の状態などの元のデータのハッシュで構成されています。これらのハッシュはペアで合算され、繰り返し反復され、最終的にMerkle Rootが計算されます。

（図の一番下のレコードは、リーフノードに対応する元のデータセットです）Merkle Rootには次の特性があります：Merkle Treeの一番下にあるリーフノードが変更されると、計算されたMerkle Rootも変更されます。したがって、異なる元のデータセットに対応するMerkle Treesには異なるMerkle Rootsがあります。まるで異なる人々が異なる指紋を持つようにです。Merkle Treeのこの特性を利用した証明検証技術をMerkle Proofと呼びます。上の図を例に取ると、李剛さんは図のMerkle Rootの値しか知らない場合、完全なMerkle Treeにどのようなデータが含まれているかはわかりません。李剛さんにRecord 3が実際に図のRootと関連していることを証明したい、つまり、Record 3のハッシュがRootに対応するMerkle Treeに存在することを証明したい場合、Record3と灰色でマークされた3つのダイジェストデータブロックを李剛さんに提出するだけで、全体のMerkle Treeやすべてのリーフノードを提出する必要はありません。これがMerkle Proofのシンプルさです。Merkle Treeの基礎となるレコードが非常に多くのリーフを含む場合、たとえば、2の20乗のデータブロック（約100万）を含む場合、Merkle Proofには少なくとも21つのデータブロックが含まれるだけです。

(図中のデータブロック30及びH2は、H0に対応するマークルツリー上にデータブロック30が存在することを証明して、マークルプルーフを構成することができる)マークルプルーフのこの「シンプルさ」は、ビットコイン、イーサリアム、またはクロスチェーンブリッジでよく使用されます。私たちが知っているライトノードは、実際には上記のLi Gangです。彼は完全なブロックではなく、完全なノードからブロックヘッダーを受け取るだけです。ここで強調しておきたいのは、イーサリアムはState Trieと呼ばれるマークルツリーを使用して、すべてのアカウントの要約として機能していることです。State Trie に関連付けられたアカウントのステータスが変更される限り、StateRoot と呼ばれる State Trie のマークル ルートが変更されます。イーサリアムのブロックヘッダーにはStateRootが記録され、トランザクションツリーのMerkle Root(Txn Rootと呼ぶ)も記録されますが、トランザクションツリーとステートツリーの違いの1つは、基礎となるリーフで表されるデータが異なることです。ブロック番号 100 に 300 件のトランザクションが含まれる場合、トランザクション ツリーのリーフはこれらの 300 Txn を表します。もう一つの違いは、State Trieの全体的なデータ量が非常に大きいことです。そのボトムリーフはイーサリアムチェーン上のすべてのアドレスに対応しているため(実際、古いステートハッシュが多数あります)、ステートトライに対応する元のデータセットはリリースされません。ブロックでは、StateRoot のみがブロック ヘッダーに記録されます。トランザクションツリーの元のデータセットは各ブロックのTxnデータであり、このツリーのTxnRootはブロックヘッダーに記録されます。

ライトノードはブロックヘッダーのみを受信し、StateRoot および TxnRoot のみを把握しているため、ルートに基づいて完全な Merkle 木を推測することはできません（これは Merkle 木とハッシュ関数の特性によって決定されるため）、したがって、ライトノードはブロックに含まれるトランザクションデータを知ることができず、State Trie に対応するアカウントで何の変更が発生したかもわかりません。もし王強がライトノード（先ほど李剛が言及した）に、ブロック番号 100 に特定のトランザクションが含まれていることを証明したい場合、ブロック番号 100 のブロックヘッダーと TxnRoot をライトノードが知っていることがわかっているとします。その場合、上記の問題は次のように変換されます: TxnRoot に対応する Merkle 木にこの Txn が存在することを証明してください。この時、王強は対応する Merkle Proof を提出するだけです。

多くの軽量クライアントソリューションに基づくクロスチェーンブリッジでは、上記で言及された軽量ノードとMerkle Proofの軽さとシンプルさがよく利用されます。たとえば、Map ProtocolなどのZKブリッジでは、ETHチェーン上に契約を設定して、他のチェーン（たとえばPolygonなど）からブロックヘッダーを特に受け取ります。RelayerがPolygonの100番目のブロックのヘッダーをETHチェーン上の契約に提出すると、契約はヘッダーの妥当性を検証します（たとえば、Polygonネットワークの2/3 POSノードの署名を収集しているかどうかなど）。ヘッダーが妥当であり、ユーザーがPolygonからETHへのクロスチェーンTxnを開始したと宣言すると、TxnはPolygonの100番目のブロックにパッケージ化されます。彼は自分が開始したクロスチェーンTxnがブロックヘッダー番号100のTxnRootに対応することをMerkle Proofで証明するだけで済みます（つまり、あなたが開始したクロスチェーンTxnがPolygonの100番目のブロックに記録されていることを証明することです）。ただし、ZK Bridgeでは、Merkle Proofを検証するために必要な計算量を圧縮するために、ゼロ知識証明が使用され、クロスチェーンブリッジ契約の検証コストがさらに削減されます。

DAとデータの隠蔽攻撃問題

Merkle Tree、Merkle Root、およびMerkle Proofについて話した後、記事の冒頭で言及されたDAとデータ隠し攻撃の問題に戻りましょう。この問題は2017年に早くも議論されています。Celestiaの原著論文がDA問題の源泉であることが議論されています。Vitalik自身が2017年から2018年の文書で言及しているように、ブロックプロデューサーはブロックの特定のデータ断片を故意に隠し、不完全なブロックを外部に公開する可能性があります。その結果、フルノードはトランザクションの実行/状態遷移の正しさを確認できません。

この時点では、ブロックプロデューサーはユーザーの資産を盗むことができます。例えば、Aの口座にあるすべてのコインを他のアドレスに送金するなどですが、フルノードは最新ブロックに含まれる完全な取引を知らないため、A自身がこれを行ったかどうかを判断することはできません。

Layer 1のBitcoinやEthereumなどの公開チェーンでは、誠実なフルノードは上記の無効なブロックを直接拒否します。しかし、ライトノードは異なります。彼らはネットワークからブロックヘッダーのみを受け取ります。私たちはStateRootとTxnRootしか知らないので、これら2つのルートに対応するヘッダーと元のブロックが有効かどうかはわかりません。

ビットコインのホワイトペーパーには、実際にこの状況についての考えがいくつかあります。サトシ・ナカモトはかつて、ほとんどのユーザーがより低い構成要件を持つ軽量ノードを実行する傾向があると考えていましたが、軽量ノードはブロックヘッダーに対応するブロックが有効かどうかを判断することはできません。ブロックが無効である場合、正直なフルノードは軽量ノードに警告を送信します。

しかし、Satoshi Nakamotoはこの解決策について詳細な分析を行っていませんでした。後に、VitalikとCelestiaの創設者であるMustafaは、このアイデアを他の先達の成果と組み合わせ、正直なフルノードが必要に応じて各エリアのブロックの完全なデータを復元し、アラートを生成できるようにするためにDAデータサンプリングを導入しました。

注意：DAデータサンプリング（DAS）とCelestiaはこの記事の焦点ではありません。興味のある読者は「Geek Web3」の過去の記事を読むことができます。「データの可用性の誤解: DA = データのリリース ≠ 過去のデータの取得」

プラズマの詐欺証明

簡単に言うと、PlasmaはLayer2のブロックヘッダのみをLayer1に公開し、ブロックヘッダの外側のDAデータ(各アカウントの完全なトランザクションデータセット/ステータス変更)のみをオフチェーンで公開する拡張ソリューションです。言い換えれば、Plasmaはライトクライアントに基づくクロスチェーンブリッジのようなものです。コントラクトを使用して、ETHチェーンにレイヤー2ライトクライアントを実装します。ユーザーがL2からL1へのクロスアセットを宣言する場合、自分自身を証明するためにマークルプルーフを提出する必要があります。これらの資産を所有しています。L2 から L1 に渡る資産の検証ロジックは、上記の ZK ブリッジと似ていますが、Plasma のブリッジング モデルが ZK プルーフではなく不正プルーフに基づいており、いわゆる「オプティミスティック ブリッジ」に近い点が異なります。Plasmaネットワーク内のL2からL1への出金リクエストはすぐには解除されませんが、「チャレンジ期間」があります。チャレンジ期間の趣旨については、以下でご説明いたします。

Plasmaはデータのリリース/DAに厳格な要件を持っていません。シーケンサー/オペレーターは、各L2ブロックをオフチェーンでブロードキャストし、L2ブロックを取得したいノードは自分で取得できます。その後、ソーターはL2ブロックのヘッダーをレイヤー1に公開します。例えば、シーケンサーは最初にブロックNo.100をオフチェーンでブロードキャストし、その後ブロックヘッダーをチェーンに公開します。ブロック100に無効なトランザクションが含まれている場合、任意のPlasmaノードは「チャレンジ期間」の終了前にETHの契約にMerkle Proofを提出することができます。ブロックヘッダーNo.100が無効なトランザクションと関連付けられることを証明します。これは詐欺証明でカバーされるシナリオです。

Plasmaの不正防止アプリケーションシナリオには、次のものも含まれます:1。Plasma ネットワークの進行状況がブロック No. 200 に達したと仮定します。このとき、ユーザーAは、ブロックNo.100にいたとき、10ETHを持っていたと言って、引き出しステートメントを開始します。しかし、実際には、ユーザーAはブロック100の後に自分のアカウントでETHを使いました。したがって、Aの行動は実際には、10ETHを費やした後、過去に10ETHを持っていたと宣言し、これらのETHを引き出そうとするものです。これは典型的な「二重引き出し」と二重支出です。このとき、ユーザーAの最新の資産状況が彼の引き出しステートメントを満たさないことを証明する、つまり、ブロック100以降に記載されたお金を引き出していないことを証明するために、誰でもマークルプルーフを提出できます。(異なるPlasmaスキームでは、この状況に対する証明方法に一貫性がなく、アカウントアドレスモデルはUTXOの二重支払い証明よりもはるかに厄介です)。2. UTXOモデルに基づくPlasmaソリューションの場合(過去には主にそうでした)、ブロックヘッダーにはStateRootは含まれず、TxnRootのみが含まれます(UTXOはEthereumスタイルのアカウントアドレスモデルをサポートしておらず、State Trieなどのグローバルステートはありません)設計。言い換えれば、UTXOモデルを使用するチェーンは、トランザクションレコードのみを持ち、ステータスレコードはありません。このとき、シーケンサー自体が、再度消費されたUTXOを消費したり、何もないところからユーザーに追加のUTXOを発行したりするなど、二重支払い攻撃を仕掛ける可能性があります。すべてのユーザーは、UTXOの使用記録が過去のブロックに出現した(使用された)ことを証明したり、特定のUTXOの履歴ソースに問題があることを証明したりするために、マークルプルーフを提出することができます。

1. EVM互換/State TrieサポートPlasmaソリューションの場合、ソーターは無効なStateRootを提出する可能性があります。例えば、100番目のブロックに含まれるトランザクションを実行した後、StateRootはST+に変換されるはずですが、ソーターはLayer1に行ってしまい、提出されたのはST-でした。この場合の詐欺証明はより複雑で、Ethereumチェーン上で100番目のブロックでのトランザクションを再生する必要があります。計算量と必要な入力パラメーターは多くのガスを消費します。Plasmaを早期に採用したチームは、このような複雑な詐欺証明を達成するのに苦労し、ほとんどのチームがUTXOモデルを採用しました。結局、UTXOベースの詐欺証明はシンプルで実装しやすいです。（詐欺証明を提供する最初のロールアップソリューションであるFuelは、UTXOに基づいています）

データの隠蔽と脱出ゲームは、詐欺証明が効果的である可能性のあるシナリオですが、DA/データのリリースが効果的であるときにのみ確立されます。シーケンサーがデータの隠蔽を行い、オフチェーンで完全なブロックを公開しない場合、Plasmaノードは、レイヤー1のブロックヘッダーが有効であるかどうかを確認できず、もちろん詐欺証明をスムーズに発行することはできません。

この時点で、シーケンサーはユーザーの資産を盗むことができ、例えば、口座Aのすべてのコインを口座Bに個人的に送金し、次に口座Bから口座Cに送金し、最後にCの名前で引き出しを開始します。譲渡B->Cが公表されても、何の害もありません。しかし、選別者は無効な譲渡A->Bのデータを差し控えることができ、BとCの資産の出所に問題があることを立証することはできません(Bの資産の出所が怪しいことを証明するには、「Bに譲渡されたあるTxn」のデジタル署名が間違っていることを指摘する必要があります)。UTXOベースのプラズマソリューションには、的を絞った対策があります。たとえば、引き出しを開始する場合、資産のすべての履歴ソースを提出する必要があります。もちろん、今後さらに改善策を講じる予定です。しかし、EVM互換のプラズマソリューションであれば、この分野では弱く見えます。コントラクトに関連するTxnが関与する場合、チェーン上の状態遷移プロセスの検証には莫大なコストがかかるため、アカウントアドレスモデルとスマートコントラクトをサポートするPlasmaは、引き出しの有効性の検証スキームを簡単に実装できません。さらに、上記の話題はさておき、UTXOベースのPlasmaにせよ、アカウントアドレスモデルにせよ、いったんデータ源泉徴収が発生すると、シーケンサーがどのようなトランザクションを実行したのかわからないため、基本的にパニックに陥ります。Plasma ノードは何かがおかしいと感じますが、Plasma シーケンサーが不正の証拠に必要なデータを発行していないため、詐欺の証拠を発行することはできません。現時点では、ユーザーは対応するブロックヘッダーのみを見ることができますが、ブロックに何があるか、アカウント資産がどうなったかはわかりません。全員が集合的に出金声明を作成し、対応するブロックヘッダーを使用します。Merkle Proofはお金を引き出そうとすると、「Exit Game」と呼ばれる極端なシナリオがトリガーされ、この状況は「スタンピード」につながり、レイヤー1で深刻な混雑を引き起こし、それでも一部の人々の資産に損害を与えます。(正直なノード通知を受け取っていない人やTwitterをチェックしていない人は、シーケンサーがコインを盗んでいることを知りません)。

そのため、プラズマは信頼性の低いレイヤー2拡張ソリューションです。データ差し押さえ攻撃が発生すると、「ゲーム終了」がトリガーされ、ユーザーが損失を被りやすくなります。これが放棄の主な理由です。Plasmaがスマートコントラクトのサポートに苦労する理由Exit Gameとデータ保持の問題について話した後、Plasmaがスマートコントラクトのサポートに苦労する理由を見てみましょう。主な理由は2つあります:まず、Defiコントラクトの資産である場合、誰がそれをLayer1に引き出す必要がありますか?これは本質的に契約ステータスをレイヤー2からレイヤー1に移行しているため、誰かがDEX LPプールに100ETHを入金し、プラズマシーケンサーが何か悪いことをし、人々が緊急にお金を引き出したいとします。現時点では、ユーザーの100ETHは依然としてDEXコントラクトによって管理されています。現時点では、これらの資産は誰が所有すべきですか?Layer1 で言及されていますか?最良の方法は、ユーザーが最初にDEXから資産を償還し、次にユーザーが自分でL1に送金できるようにすることのようです。しかし、問題は、プラズマソーターが悪事を働き、いつでもユーザーの要求を拒否する可能性があることです。では、DEXコントラクトのオーナーを事前に設定しておき、緊急時にコントラクト資産をL1に引き上げられるようにしたらどうなるでしょうか?明らかに、これは契約所有者に公共資産の所有権を与えることになります。彼はこれらの資産をL1に持ち上げて、いつでも逃げることができます。これはひどいと思いませんか?明らかに、Defi契約によって管理されるこれらの「公共財産」をどのように扱うかは大きな驚きです。これは、実は公権力の分配の問題である。窃盗犯は以前、インタビューでこう語っていた「高性能なパブリックチェーンで新しいものを作ることは難しいです。スマートコントラクトは権力の分配を含んでいます。」この記事で言及されていました。

第二に、契約の移行が許可されない場合、契約は莫大な損失を被ることになります。コントラクトの状態をLayer1に移行することが許可された場合、Plasmaの不正防止で解決するのが難しい二重の引き出しが発生します:たとえば、Plasmaがイーサリアムのアカウントアドレスモデルを採用し、スマートコントラクトをサポートしていると仮定します。ボブが100番目のブロックのミキサーから50ETHを引き出すと仮定します。その後、ボブは引き出しステートメントを開始し、50ETHをレイヤー1に転送します。次に、ボブは過去のコントラクト状態スナップショット(70番目のブロックなど)を使用して、ミキサーの過去の状態をレイヤー1に移行し、ミキサーが「所有していた」100ETHもレイヤー1に転送されます。明らかに、これは典型的な「二重引き出し」、つまり二重支出であり、ボブはレイヤー1に150ETHを言及しましたが、レイヤー2ネットワークユーザーはミキサー/ボブに100ETHしか支払わず、50ETHは何もないところから引き出されました。これによりプラズマの蓄えを簡単に枯渇させることができます。理論的には、70ブロック目以降にミキサーコントラクトの状態が変化したことを証明するために、詐欺の証拠を開始することができます。しかし、ブロックNo.70の後、ボブが50ETHを奪ったトランザクションを除いて、ミキサーコントラクトと相互作用したすべてのTxnがコントラクトステータスを変更しなかった場合。証拠を示す場合は、ミキサーコントラクトがブロックNo.70以降に変更があった場合、上記のすべてのTxnをイーサリアムチェーン上で実行しなければならず、最終的にPlasmaコントラクトを確認できます。撹拌機の契約状況は確かに変化しています(なぜそんなに複雑なのかというと、プラズマ自体の構造によって決まるからです)。このバッチの Txn の数が極端に多い場合、不正の証拠を Layer1 でまったく公開できません。(イーサリアムの1ブロック分のガスリミットを超えます)。

https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598Theoretically、上記の二重支払いのシナリオでは、ミキサーの現在の状態のスナップショット(実際にはStateRootに対応するマークル証明)のみが送信されているように見えますが、実際には、Plasmaはトランザクションデータをチェーン上に公開しないため、コントラクトは送信された状態スナップショットが有効かどうかを判断できません。これは、シーケンサー自体がデータの保留を開始し、無効な状態スナップショットを送信し、取り消し者を悪意を持って有罪にする可能性があるためです。たとえば、アカウントに50ETHがあると宣言して引き出しを開始すると、シーケンサーはプライベートでアカウントを0にクリアしてから、データの源泉徴収を開始し、無効なStateRootをチェーンに送信し、対応する状態スナップショットを送信して、アカウントのお金が不足していると誤って非難する可能性があります。現時点では、シーケンサーによって送信されたStateRootと状態スナップショットは、データの保留を開始しており、不正の証明に必要な十分なデータを取得できないため、無効であることを証明することはできません。これを防ぐために、Plasma ノードが誰かが二重に支払ったことを証明するために状態スナップショットを提示すると、この期間中のトランザクションレコードも再生します。これにより、シーケンサーがデータの源泉徴収を使用して、他のユーザーがお金を引き出すのを防ぐことができます。Rollupでは、上記の二重引き出しが発生した場合、Rollupにはデータ源泉徴収の問題がなく、シーケンサーにチェーン上のDAデータを公開するように「強制」するため、理論的には過去のトランザクションを再生する必要はありません。ロールアップ シーケンサが無効な StateRoot 状態スナップショットを送信すると、コントラクトの検証に失敗するか (ZK ロールアップ)、すぐにチャレンジされます (OP ロールアップ)。実際、上記のコインミキサーの例に加えて、マルチ署名契約などのシナリオも、Plasmaネットワークでの二重引き出しにつながる可能性があります。不正防止は、このシナリオを処理する上で非常に非効率的です。この状況はETHリサーチで分析されています。要約すると、Plasmaソリューションはスマートコントラクトを助長しておらず、基本的にレイヤー1へのコントラクトステータスの移行をサポートしていないため、主流のPlasmaはUTXOまたは同様のメカニズムを使用する必要があります。UTXOは、資産所有権の競合の問題がなく、不正防止を非常にうまくサポートできるため(サイズがはるかに小さい)、単一のアプリケーションシナリオを持ち、基本的に転送またはオーダーブック交換のみをサポートできるという代償があります。また、不正防止自体がDAデータへの依存性が高いため、DA層の信頼性が低いと、効率的な不正防止システムの実装が困難になります。しかし、PlasmaのDA問題の処理はあまりにも粗雑であり、データ保留攻撃の問題を解決することはできません。ロールアップの台頭により、プラズマはゆっくりと歴史の舞台から消えていきました。

免責事項：

1. この記事は[から転載されています微信公众号：极客 Web3]. すべての著作権は元の著者に帰属します [Faust]. もし、この転載に異議がある場合は、お問い合わせください。Gate Learnチームが迅速に対処します。
2. 責任の免責事項：この記事に表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳は、Gate Learnチームによって行われています。特に断りがない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。