たとえば、Li Gang が図のマークル ルートの値しか知らない場合、完全なマークル ツリーにどのようなデータが含まれているかはわかりません。 李剛に、レコード3が実際に図のルートに関係していること、またはレコード3のハッシュがルートに対応するマークルツリーに存在することを証明する必要があります。
Record3 とグレーでマークされた 3 つのダイジェストブロックを Li Gang に送信するだけで、Merkle Tree 全体またはそのすべてのリーフノードをコミットする必要はなく、これが Merkle Proof のシンプルさです。 マークルツリーの基になるレコードに、2の2乗データブロック(約100万)など、多数のリーフがある場合、マークルプルーフには少なくとも21のデータブロックを含めるだけで済みます。
Wang Qiangがライトノード(前述のLi Gang)に対して、ブロック100に特定のトランザクションが含まれていることを証明したい場合、ライトノードがブロック100のブロックヘッダーを知っていて、TxnRootを知っていることがわかっている場合、上記の問題は、このTxnがTxnRootに対応するマークルツリー上に存在することを証明することになります。 このとき、Wang Qiangは対応するマークルプルーフを提出するだけで済みます。
データ源泉徴収と不正防止:Plasmaがスマートコントラクトをサポートしない理由
著者: ファウスト、オタクweb3
なぜPlasmaが長い間埋もれていたのか、そしてなぜVitalikがRollupを強力にサポートするのかについて、手がかりは主に2つの点を指しています:EthereumチェーンにDAをオフチェーンで実装することは信頼性が低く、データ源泉徴収が発生しやすいこと、そしてデータ源泉徴収が発生すると、不正防止を開発することは困難です。 **この2点により、Plasmaは基本的にUTXOまたは近似モデルのみになります。
この2つの重要なポイントを理解するために、まずDAとデータ保持から始めましょう。 DAはData Avalibilityの略で、文字通りデータの可用性を意味し、現在では多くの人々に誤用されているため、「履歴データを確認できる」とひどく混同されています。 しかし、実際には、「履歴データ」と「保存の証明」は長年の問題であり、FilecoinやArweaveなどによって解決されています。 イーサリアム財団とセレスティアによると、DAの問題は純粋にデータ源泉徴収のシナリオに関するものです。 **
マークルツリー & マークルルート & マークルプルーフ
データ保留攻撃とDAの問題が何を意味するかを説明するために、まずマークルルートとマークルツリーについて簡単に説明する必要があります。 **イーサリアムやほとんどのパブリックチェーンでは、マークルツリーと呼ばれるツリー状のデータ構造を使用して、アカウント全体の状態の要約/ディレクトリとして機能したり、各ブロック内にパッケージ化されたトランザクションを記録したりします。
**マークルツリーの一番下にあるリーフノードは、トランザクションやアカウントステータスなどの生データのハッシュで構成されており、これらのハッシュはペアと反復で合計され、最終的にマークルルートを計算できます。
(図の下部のレコードは、リーフ ノードに対応する元のデータセットです)
マークルルートには、マークルツリーの一番下のリーフノードが変化すると、計算されたマークルルートも変化するという特性があります。 したがって、異なる元のデータセットに対応するマークルツリーは、人によってフィンガープリントが異なるように、異なるマークルルーツを持つことになります。 マークルプルーフと呼ばれる証明検証技術は、マークルツリーのこの特性を利用しています。
たとえば、Li Gang が図のマークル ルートの値しか知らない場合、完全なマークル ツリーにどのようなデータが含まれているかはわかりません。 李剛に、レコード3が実際に図のルートに関係していること、またはレコード3のハッシュがルートに対応するマークルツリーに存在することを証明する必要があります。
Record3 とグレーでマークされた 3 つのダイジェストブロックを Li Gang に送信するだけで、Merkle Tree 全体またはそのすべてのリーフノードをコミットする必要はなく、これが Merkle Proof のシンプルさです。 マークルツリーの基になるレコードに、2の2乗データブロック(約100万)など、多数のリーフがある場合、マークルプルーフには少なくとも21のデータブロックを含めるだけで済みます。
(図中のデータブロック30及びH2は、マークルプルーフを構成することができ、データブロック30がH0に対応するマークルツリー上に存在することを証明することができる)**
ビットコイン、イーサリアム、またはクロスチェーンブリッジでは、マークルプルーフのこの「シンプルさ」がよく使用されます。 私たちが知っているライトノードは、実際には上記のLi Gangであり、フルブロックではなく、フルノードからブロックヘッダーのみを受け取ります。 ここで強調しておきたいのは、イーサリアムはステートトライと呼ばれるマークルツリーを使用しており、アカウント全体の要約として機能していることです。 StateRootと呼ばれるState TrieのMerkle Rootは、State Trieに関連付けられたアカウントの1つの状態が変更されるたびに変更されます。
イーサリアムのブロックヘッダーにはStateRootが記録され、トランザクションツリーのMerkle Root(Txn Rootと呼ぶ)も記録されます。 ブロック 100 に 300 のトランザクションが含まれている場合、トレーディング ツリーのリーフはこれらの 300 Txn を表します。
もう一つの違いは、State Trieの全体的なデータ量が特に大きく、その基礎となるリーフがイーサリアムチェーン上のすべてのアドレスに対応しているため(実際、多くの古いステートハッシュがあります)、State Trieに対応する元のデータセットはブロックに公開されず、StateRootのみがブロックヘッダーに記録されることです。 トランザクションツリーの元のデータセットは各ブロックのTxnデータであり、ツリーのTxnRootはブロックヘッダーに記録されます。
ライトノードはブロックヘッダーのみを受信し、StateRootとTxnRootのみを認識し、ルートに基づいて完全なマークルツリーを推測できないため(これはマークルツリーとハッシュ関数の性質によって決定されます)、ライトノードはブロックに含まれるトランザクションデータを知ることができず、ステートトライに対応するアカウントにどのような変更が発生したかを知ることもできません。 **
Wang Qiangがライトノード(前述のLi Gang)に対して、ブロック100に特定のトランザクションが含まれていることを証明したい場合、ライトノードがブロック100のブロックヘッダーを知っていて、TxnRootを知っていることがわかっている場合、上記の問題は、このTxnがTxnRootに対応するマークルツリー上に存在することを証明することになります。 このとき、Wang Qiangは対応するマークルプルーフを提出するだけで済みます。
ライトクライアントソリューションに基づく多くのクロスチェーンブリッジでは、上記のライトノードとマークルプルーフの軽さとシンプルさがよく使用されます。 例えば、Map ProtocolなどのZKブリッジは、ETHチェーン上にコントラクトを設定し、他のチェーン(Polygonなど)からブロックヘッダーを受信します。 RelayerがPolygonの100ブロック目のヘッダーをETHチェーン上のコントラクトに送信すると、コントラクトはヘッダーの有効性(Polygonネットワーク内の2/3 POSノードからの署名が十分にあるかどうかなど)を検証します。
ヘッダーが有効で、ユーザーがPolygonからETHへのクロスチェーンTxnを開始したと宣言した場合、TxnはPolygonの100番目のブロックにパックされます。 彼は、マークルプルーフを通じて、彼が開始したクロスチェーンTxnがブロック100ヘッダーのTxnRootに対応できることを証明するだけで済みます(言い換えれば、彼が開始したクロスチェーンTxnがPolygonのブロック100にレコードを持っていることを証明します)。 しかし、ZKブリッジはゼロ知識証明を使用して、マークルプルーフの検証に必要な計算量を圧縮し、クロスチェーンブリッジ契約の検証コストをさらに削減します。
DAとデータ保持攻撃の問題
Merkle TreeとMerkle RootとMerkle Proofの話が終わったら、2017年以前に検討した記事の冒頭で触れたDAとデータ保留攻撃の問題に戻り、CEESTIAの元の論文でDA問題の起源を考古学化しました。 2017~18年のドキュメントで、ヴィタリック自身が、ブロッカーがブロックの特定のデータフラグメントを意図的に隠蔽し、不完全なブロックを公開して、フルノードがトランザクションの実行/状態遷移の正しさを確認できないようにする方法について話しました。
この時点で、ブロックプロデューサーは、アカウントAのすべてのコインを別のアドレスに転送するなど、ユーザーの資産を盗むことができ、フルノードは、最新のブロックに含まれる完全なトランザクションデータを知らないため、A自身がそうしたかどうかを判断できません。
ビットコインやイーサリアムなどのレイヤー1パブリックチェーンでは、正直なフルノードは上記の無効なブロックを直接拒否します。 しかし、ライトノードは異なり、ネットワークからブロックヘッダーを受け取るだけで、StateRootとTxnRootのみを認識し、ヘッダーと2つのルートに対応する元のブロックが有効かどうかはわかりません。
ビットコインのホワイトペーパーでは、実際にこの状況の頭脳の穴があり、サトシ・ナカモトはかつて、ほとんどのユーザーは構成要件の低いライトノードを実行する傾向があり、ライトノードはブロックヘッダーに対応するブロックが有効かどうかを判断できず、ブロックが無効な場合、正直なフルノードがライトノードにアラームを送信すると信じていました。
しかし、サトシ・ナカモトはこのソリューションの詳細な分析を行わず、後にヴィタリックとセレスティアの創設者であるムスタファは、このアイデアに基づいて、他の前任者の仕事と組み合わせて、DAデータサンプリングを導入し、誠実なフルノードが各ブロックの完全なデータを復元し、必要に応じてアラームを発することができるようにしました。
注:DAデータサンプリング(DAS)とCelestiaはこの記事の焦点ではありません、興味のある読者はGeek Web3の以前の記事を読むことができます: “データの可用性に関する誤解:DA=データ公開≠履歴データ検索”
Plasmaの不正防止
簡単に言うと、Plasmaはレイヤー2のブロックヘッダーのみをレイヤー1に公開するスケーリングソリューションであり、ブロックヘッダーの外側のDAデータ(アカウントごとの完全なトランザクションデータセット/状態変更)はオフチェーンでのみ公開されます。 言い換えれば、Plasmaはライトクライアントに基づくクロスチェーンブリッジのようなもので、ETHチェーン上のコントラクトでレイヤー2ライトクライアントを実装し、ユーザーがL2からL1に資産をクロスしたいと宣言すると、実際に資産を所有していることを証明するためにマークルプルーフを提出する必要があります。
**L2 から L1 までの資産の検証ロジックは、上記の ZK ブリッジと似ていますが、Plasma ブリッジ モデルは、いわゆる「オプティミスティック ブリッジ」に近い ZK プルーフではなく、不正プルーフに基づいている点が異なります。 **PlasmaネットワークにおけるL2からL1への出金リクエストは、すぐには解除されませんが、「チャレンジ期間」があり、チャレンジ期間の目的については、以下で説明します。
Plasma にはデータリリース/DA の厳密な要件はなく、シーケンサー/オペレーターは各 L2 ブロックをオフチェーンでブロードキャストするだけで、L2 ブロックを取得するノードは独自にブロードキャストします。 その後、シーケンサーは L2 ブロックのヘッダーをレイヤー 1 に公開します。 例えば、シーケンサーはブロック100をオフチェーンでブロードキャストし、次にブロックのヘッダーをオンチェーンで公開する。 ブロック100に無効なトランザクションが含まれている場合、任意のプラズマノードは、「チャレンジ期間」が終了する前にETHのコントラクトにマークルプルーフを提出して、ブロック100ヘッダーが無効なトランザクションに関連付けられることを証明することができます。
Plasmaの不正防止のユースケースには、次のようなものがあります。
つまり、Aの行動は、実際には10ETHを費やし、過去に10ETHを持っていたと宣言し、ETHを引き出そうとすることです。 これは古典的な「二重引き出し」、二重支出です。 現時点では、誰でもユーザーAの最新の資産状況を証明するためにマークルプルーフを提出することができ、その出金明細書を満たしていない、つまり、ブロック100以降にAが出金明細書を持っていなかったことを証明することができます(異なるPlasmaスキームでは、この状況に対する証明方法に一貫性がなく、口座アドレスモデルはUTXOの二重支払い証明よりもはるかに厄介です)。
この場合、シーケンサー自体が、すでに消費されたUTXOを使用したり、何もないところからユーザーに追加のUTXOを発行したりするなど、二重支払い攻撃を仕掛ける可能性があります。 すべてのユーザーは、UTXOの使用履歴が以前のブロックに出現した(使用された)ことを証明したり、UTXOの過去の起源が疑わしいことを証明したりするために、マークルプルーフを提出することができます。 **
この場合、不正の証明はより複雑であり、ブロック100のトランザクションをイーサリアムチェーン上で再生する必要があり、必要な計算量と入力パラメータの量で大量のガスを消費します。 初期のPlasma導入チームにとって、このような複雑な不正証明を実現することは難しいため、UTXOベースの不正証明は非常にシンプルで実装が容易であるため、ほとんどのチームはUTXOモデルを使用しています(不正証明を開始する最初のロールアップスキームであるFuelは、UTXOに基づいています)
データ保持とゲームの終了****
もちろん、不正の証拠が有効になる上記のシナリオは、DA/データリリースが有効な場合にのみ確立されます。 シーケンサーがデータを差し控え、フルブロックをオフチェーンで公開しない場合、Plasmaノードはレイヤー1のブロックヘッダーが有効かどうかを確認できず、もちろん不正の証拠をスムーズに公開することはできません。
このとき、シーケンサーは、口座Aから口座Bにすべてのコインを送金し、次に口座Bから口座Cに送金し、最後にCの名前で引き出しを開始するなど、ユーザーの資産を盗むことができます。 アカウントBとCはシーケンサーが所有しており、B->Cの譲渡は一般に公開されても無害ですしかし、シーケンサーはA->Bの無効な譲渡のデータを差し控えることができ、BとCの資産の出所に問題があることを証明することはできません(Bの資産の出所に問題があることを証明するには、「Bに譲渡されたあるTxn」のデジタル署名が間違っていることを指摘する必要があります)。
UTXOベースのPlasmaソリューションは、引き出しを開始する人は誰でも資産の完全な履歴を提出する必要があるという事実をターゲットとしていますが、後でさらに改善が加えられます。 しかし、EVM互換のプラズマ溶液であれば、この辺りは弱いでしょう。 コントラクト関連のTxnが関与する場合、チェーン上の状態遷移プロセスの検証に莫大なコストがかかるため、アカウントアドレスモデルとスマートコントラクトPlasmaをサポートすることで、引き出しの有効性の検証スキームを実装することは困難です。
また、上記のトピックとは別に、UTXOベースであろうとアカウントアドレスモデルベースのPlasmaであろうと、シーケンサーが実行しているトランザクションがわからないため、データ保留はパニックを引き起こす可能性があります。 **Plasma ノードは何か問題を発見しますが、Plasma シーケンサーが不正の証拠に必要なデータを送信しないため、詐欺の証拠を公開することはできません。
現時点では、人々は対応するブロックヘッダーしか見ることができませんが、ブロックに何があるかはわからず、自分の口座資産がどうなっているかもわからないため、集団で出金明細書を開始し、履歴ブロックに対応するマークルプルーフで出金を試み、「エグジットゲーム」と呼ばれる極端なシナリオを引き起こし、「スタンピード」につながり、レイヤー1を深刻に混雑させ、一部の人の資産に損害を与える (正直なノード通知を受け取らなかったり、Twitterをスワイプしなかったりする人は、シーケンサーがコインを盗んでいることに気づかないでしょう。
そのため、Plasmaは信頼性の低いレイヤー2スケーリングソリューションであり、データ差し押さえ攻撃が発生すると、ユーザーが損失を被りやすい「Exit Game」がトリガーされ、それが放棄の主な理由です。 **
プラズマがスマートコントラクトに対応しにくい理由****
Exit Gameとデータ保持の問題についてお話しした後、主に2つの理由から、Plasmaがスマートコントラクトをサポートするのが難しい理由を見てみましょう。
まず、Defiコントラクトの資産である場合、誰がレイヤー1に引き出すべきでしょうか? これは本質的に契約の状態をレイヤー2からレイヤー1に移行するため、誰かがDEXのLPプールに100ETHを請求し、プラズマシーケンサーが悪事を働き、人々が緊急に引き出したいとした場合、この時点で、ユーザーの100ETHはまだDEXコントラクトによって管理されていますが、この時点で誰がこれらの資産をレイヤー1に言及する必要がありますか?
これを行う最善の方法は、最初にユーザーにDEXから資産を償還させ、その後、ユーザーが自分でL1にお金を引き出すことのようですが、問題は、プラズマシーケンサーが何か悪いことをしていて、いつでもユーザーの要求を拒否する可能性があることです。
では、DEXコントラクトのオーナーを事前に設定しておけば、緊急時に契約資産をL1に置けるようにしておくとどうなるでしょうか? 明らかに、これは契約所有者に公共資産の所有権を与え、彼はいつでもこれらの資産をL1に置いて逃げることができます、それはひどいことではありませんか?
明らかに、Defi契約によって支配されているこれらの「公共財産」をどうするかは、大きな雷です。 **これは実際には公的電力の分配の問題に関係しており、Xiangma氏は以前のインタビューで「高性能なパブリックチェーンが新しいことをすることは難しく、スマートコントラクトは電力の分配を伴う」と話していました。
第二に、コントラクトがその状態を移行することを許可されていない場合、コントラクトは莫大な損失を被り、コントラクトがその状態をレイヤー1に移行することを許可された場合、Plasma詐欺防止で解決するのが難しい二重の引き出しが発生します。
例えば、Plasmaがイーサリアムのアカウントアドレスモデルを採用し、スマートコントラクトをサポートし、コインミキサーを持ち、現在100ETHを入金し、コインミキサーの所有者がボブによって管理されているとします。
ボブがブロック100でミキサーから50ETHを引き出すとします。 その後、ボブは引き出し声明を開始し、50ETHを越えてレイヤー1に移動しました。
その後、ボブは過去のコントラクト状態(ブロック70など)のスナップショットを使用して、ミキサーの過去の状態をレイヤー1に移行し、ミキサーがレイヤー1に「かつて持っていた」100ETHも超えます。
明らかに、これは典型的な「ダブルドローダウン」であり、二重の支出です。 150 ETHはボブによってレイヤー1に言及されましたが、レイヤー2ネットワークユーザーはミキサー/ボブに100ETHしか支払わず、50ETHは何もないところから引き出されました。 これにより、プラズマの蓄えを簡単に消耗する可能性があります。 理論的には、ブロック70以降にミキサーコントラクトの状態が変化したことを証明するために、不正証明を開始することができます。
しかし、ブロック70以降にMixerコントラクトが変更されたという証拠を示したいのであれば、上記のすべてのTxnをEthereumチェーン上で実行して、最終的にPlasmaコントラクトにMixerコントラクトの状態が実際に変化したと判断させる必要があります(Plasmaコントラクトが非常に複雑である理由は、Plasma自体の構造によって決定されます)。 Txnの量が非常に多い場合、レイヤー1では不正の証拠がまったく公開されません(イーサリアムの1ブロックのガスリミットを超えます)。
理論的には、上記の二重支払いのシナリオでは、ミキサーの現在の状態のスナップショット(実際にはStateRootに対応するマークルプルーフ)を提出するだけでよいように見えますが、実際には、Plasmaはチェーン上でトランザクションデータを公開しないため、コントラクトは送信した状態のスナップショットが有効かどうかを判断することはできません。 **これは、シーケンサー自体がデータの保持を開始し、無効なステータススナップショットを送信し、悪意を持って引き出しを指摘する可能性があるためです。 **
例えば、アカウントに50ETHがあると宣言して出金を開始すると、シーケンサーはプライベートでアカウントを0にクリアし、データの源泉徴収を開始し、無効なStateRootをチェーンに送信し、対応する状態スナップショットを送信して、アカウントの資金が不足していると偽って非難する可能性があります。 この時点では、シーケンサーがデータの保持を開始したため、シーケンサーによって送信された StateRoot と State Snapshot が無効であることを証明できず、不正を証明するために必要な十分なデータを取得できません。 **
これを防ぐために、Plasma ノードは、誰かが二重支払いをしたことを証明するために状態のスナップショットを提示する際に、この期間中のトランザクション履歴を再生し、シーケンサーがデータを保留して他の人が引き出すのを防ぎます。 Rollupでは、上記の二重引き出しが発生した場合、Rollupにはデータ源泉徴収の問題がなく、シーケンサーにチェーン上のDAデータを公開するように「強制」するため、理論的には過去のトランザクションを再生する必要はありません。 **無効な StateRoot 状態スナップショットを送信するロールアップ シーケンサーは、コントラクト検証に失敗するか (ZK ロールアップ)、すぐにチャレンジされます (OP ロールアップ)。
実際、上記のコインミキサーの例に加えて、マルチシグ契約などのシナリオも、Plasmaネットワークでの二重引き出しにつながる可能性があります。 不正の証明は、このようなシナリオを処理するには非効率的です。 **この状況はETHリサーチで分析されています。
要約すると、Plasmaスキームはスマートコントラクトを助長しておらず、基本的にレイヤー1へのコントラクト状態の移行をサポートしていないため、主流のPlasmaはUTXOまたは同様のメカニズムを選択する必要があります。
また、不正防止自体がDAデータへの依存性が高いため、DA層の信頼性が低いと効率的な不正防止システムを実現することは困難です。 しかし、DA問題に対するPlasmaの処理は、データ保留攻撃の問題を解決するには初歩的すぎ、Rollupの台頭により、Plasmaは徐々に歴史から消えていきました。 **