V God Rollupsの作品を振り返り、なぜイーサリアムに2層拡張計画が必要なのかを詳しく説明します。
原作者：Vitalik
原作者：TinTinLand
ロールアップはイーサリアム コミュニティで大流行しており、将来的にはイーサリアムの主要なスケーラビリティ ソリューションになることが期待されています。しかし、このテクノロジーとは一体何なのでしょうか?また、そこから何を期待できるのでしょうか?どのように使用されるのでしょうか？この記事では、イーサリアムのいくつかの重要な拡張スキームの分析に基づいて、ロールアップに関連するいくつかの重要な質問に答えようとします。
最初のレベルのタイトル
背景: L1 と L2 とは何ですか?
第二に、ブロックチェーンの使用方法を変えることができます。ユーザーは、すべてのアクティビティをブロックチェーン上で直接実行するのではなく、ほとんどのアクティビティをオフチェーンの「レイヤー 2」プロトコルで実行します。オンチェーンにはスマート コントラクトがあり、そのタスクは 2 つだけです。入出金の処理と、オフチェーンで発生するすべてのことがルールに従っていることの証拠の検証です。これらの証明を行うにはさまざまな方法がありますが、それらはすべて、生の計算をオフチェーンで実行するよりもオンチェーンで証明を検証する方がはるかに安価であるという特性を共有しています。
最初のレベルのタイトル
L2 層スキームには、ステート チャネル、プラズマ、ロールアップの 3 つの主なタイプがあります。これらは異なるパラダイムに属し、異なる利点と欠点を持っていますが、以下ではこれら 3 つの異なる方式の動作方法について説明します。
副題
ステートチャネルの仕組み
アリスがボブにインターネット接続を提供し、ボブがその料金を 1 メガバイトあたり 0.001 ドル支払うという具体的なケースを想定します。毎回支払うのではなく、トランザクションでは次の L2 スキームが使用されます。
まず、ボブは 1 ドル (ETH またはステーブルコイン相当) をスマート コントラクトに投入します。アリスに最初の支払いを行うために、ボブは「$0.001」と書かれた「チケット」（オフチェーン メッセージ）に署名し、それをアリスに送信します。 2 回目の支払いを行うために、ボブは「$0.002」と書かれた別のチケットに署名し、アリスに送信します。など、必要なだけ支払いを行っていきます。アリスとボブが取引を完了すると、アリスは最高額の紙幣をチェーンにポストし、それを自分の別の署名で包みます。スマート コントラクトは、アリスとボブの両方の署名を検証し、ボブのチケットに記載されている金額をアリスに支払い、残りをボブに返します。アリスが（悪意や技術的障害のため）チャネルを閉じることに抵抗がある場合、ボブは終了期間（たとえば 7 日間）を開始できます。アリスがこの期間内にチケットを提供しない場合、ボブは全額を返金します。
このテクノロジーの力は、双方向の支払いを処理するスマートコントラクト関係を調整できるという事実にあります。たとえば、アリスとボブはチャネル内で契約を結び、アリスとボブが開いたチャネルを持っている場合、ボブとチャーリーも同様に、アリスはチャーリーとトラストレスな対話を行うことができます。
参照: https://www.jeffcoleman.ca/state-channels および statechannels.org
副題
プラズマの仕組み
資産をデポジットするには、ユーザーはそれをプラズマ チェーンを管理するスマート コントラクトに送信します。プラズマ チェーンは、資産に新しい一意の ID (例: 537) を割り当てます。すべてのプラズマ チェーンにはオペレーターがあります (これは、集中型アクター、マルチシグ、または PoS や DPoS などのより複雑なものである可能性があります)。間隔ごと (おそらく 15 秒、1 時間、またはその中間) に、オペレーターはオフチェーンで受信したすべての Plasma トランザクションを含む「バッチ」を生成します。これらはマークル ツリーを生成します。ツリー内の各インデックスには、そのようなトランザクションが存在する場合は資産 ID を転送するトランザクションがあり、存在しない場合はリーフがゼロになります。
また、各インデックスのマークル フォークをその資産の現在の所有者に送信します。資産を引き出すには、ユーザーが最新のトランザクションのマークル フォークを公開すると、資産が送信されます。契約はチャレンジ期間を開始します。この期間中は、誰でも他のマークル ブランチを使用して、(i) 送信者が送信時にアセットを所有していなかった、(ii) 後で送信者がアセットを所有していなかった、のいずれかの方法でエグジットが無効であることを証明しようとすることができます。資産を他の人に送るため。 7 日以内に出金が不正であることを誰も証明できなかった場合、ユーザーは資産を出金することができます。
プラズマは、国家チャネルよりも強力な特性を提供します。つまり、システムに参加したことのない参加者に資産を送信でき、資本要件が低くなります。トレードオフは次のとおりです。「通常の動作」中、チャネルはオンチェーンにデータを置く必要はありませんが、Plasma では各チェーンが定期的にハッシュを発行する必要があります。また、プラズマボディの転送は即時ではないため、間隔が終了し、ブロックがパブリックにオンチェーンになるまで待つ必要があります。
参照: http://plasma.io/plasma-deprecated.pdf
副題
ロールアップの仕組み
ロールアップについて
プラズマとチャネルは、データと計算の両方をオフチェーンに移動しようとするという点で「完全な」L2 ソリューションです。ただし、データの可用性に関する基本的なゲーム理論の問題により、すべてのアプリケーションでこれを安全に実行することは不可能です。プラズマとチャネルは、所有者の概念に依存することでこの問題を解決しますが、これはそれらの適用範囲に影響します。ただし、Rollups は「ハイブリッド」L2 ソリューションです。ロールアップは計算 (および状態ストレージ) をオフチェーンに移動しますが、各タスクのデータの一部はオンチェーンに保持されます。効率を向上させるために、彼らは多くの複雑な圧縮手法を使用し、可能な限りデータを計算に置き換えます。その結果、システムのスケーラビリティは依然として基盤となるブロックチェーンのデータ帯域幅によって制限されますが、程度はより低くなります。イーサリアムのベースレイヤーでの ERC20 トークン転送のコストは約 45000 ガスですが、イーサリアムのベースレイヤーでの ERC20 トークン転送のコストは約 45000 ガスです。ロールアップはチェーン上で 16 バイトのスペースを占有し、コストは 300 ガス未満です。
IPFS には特定のデータが使用可能かどうかについての合意がなく、データはブロックチェーン上に存在する必要があるため、データを「IPFS 上」に置くことは機能しないことに注意してください。データをオンチェーンに置くというコンセンサスにより、Rollups を使用すると、誰でも必要に応じてあらゆる操作をローカルで処理できるようになり、不正行為の検出、引き出しの開始、またはトランザクションのバッチの生成を自分で開始できるようになります。データの可用性に関する懸念がないということは、悪意のあるオペレーターやオフラインのオペレーターによる被害が少なくなり (たとえば、1 週間の遅延を引き起こすことができない)、ロールアップを推論するのが容易になり、バッチを発行する権限を持つユーザーが使用できる余地が増えることを意味します。 。それに加えて、データ可用性の問題がないことは、アセットを所有者にマッピングする必要がなくなったことを意味し、そのためイーサリアム コミュニティはロールアップ スケーリング ソリューションに非常に興味を持っています。一部のイーサリアム アプリケーションは、新しいコードをほとんど書くことなくロールアップに移行します。
参照: https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/
ロールアップの仕組み
チェーン上には状態ルート、つまりロールアップ状態のマークル ルート (ロールアップ「内部」の口座残高、契約コードなどを意味します) を維持するスマート コントラクトがあります。
誰でも、以前の状態ルートと新しい状態ルート (トランザクション処理後のマークル ルート) とともに、高度に圧縮されたトランザクションのセットであるバッチを公開できます。コントラクトは、バッチ内の以前の状態ルートが現在の状態ルートと一致するかどうかを確認し、一致する場合は、状態ルートを新しい状態ルートに切り替えます。
バッチ内の状態後のルートが正しいことはどのようにしてわかりますか?誰かが影響を受けずにポストステートルートを使用してバッチを送信できれば、ロールアップ内のすべてのコインを自分に転送できます。この問題は重大であり、この問題に対して 2 つの異なるソリューション群が発生し、2 つの異なるロールアップが作成されます。
最初のレベルのタイトル
楽観的ロールアップと ZK ロールアップ
ロールアップには次の 2 種類があります。
不正証明を使用した楽観的ロールアップ: ロールアップ コントラクトは、各バッチの状態ルートとハッシュの履歴全体を追跡します。誰かが間違ったポストステートルートを持つバッチを見つけた場合、そのバッチが間違って計算されたことをリンクする証拠を投稿できます。契約は証拠を検証し、そのバッチと後続のすべてのバッチを復元します。
ZKRollups (ゼロナレッジ ロールアップ)、有効性証明を使用: 各バッチには、ZK-SNARK (たとえば、PLONK プロトコルを使用) と呼ばれる暗号証明が含まれており、ポストステート ルートがバッチ実行の正しい結果であることを証明します。どんなに計算量が多くても、証明はオンチェーン上で非常に迅速に検証できます。
全体として、短期的には、一般的な EVM 計算ではオプティミスティック ロールアップが勝つ可能性が高く、一方、単純な支払い、為替、その他のアプリケーション固有のユースケースでは ZK ロールアップが勝つ可能性が高くなります。
副題
不正行為の証明の構造
オプティミスティック ロールアップのセキュリティは、誰かが無効なバッチをロールアップに投稿した場合、不正行為を検出した他の誰もが不正行為の証拠を投稿して、バッチが無効であり復元されるべきであることを契約に証明できるという前提に基づいています。
確かに、バッチが間違って構築され、以前のすべてのバッチが正しく構築されていた場合、バッチが間違って構築されたという不正証拠を作成する可能性があります。以前のバッチに関する記述に注意してください。複数の無効なバッチがロールアップにリリースされる場合は、最も古いバッチが無効であることを証明することを試みるのが最善です。もちろん、バッチが正しく構築されていれば、バッチが無効であるという不正証明を作成することは決して不可能です。
副題
データ圧縮の原理
単純な Ethereum トランザクション (ETH の送信) には約 110 バイトかかります。ただし、ロールアップでの ETH 転送には約 12 バイトしかかかりません。
これの一部は単なる高レベルのエンコードです。イーサリアムの RLP は各値の長さで 1 バイトを無駄にします。ただし、次のような特定の圧縮技術も含まれています。
Nonce: このパラメータの目的は、リプレイ攻撃を防ぐことです。アカウントの現在のナンスが 5 の場合、そのアカウントの次のトランザクションはナンス 5 でなければなりません。トランザクションが処理されると、アカウント内のナンスは 6 に増加するため、トランザクションを再度処理することはできません。ロールアップでは、前の状態からノンスを復元しているだけなので、ノンスを完全に省略できます。誰かが以前のノンスでトランザクションを再実行しようとすると、署名はより高いノンスを含むデータに対するものになるため、署名は検証できません。チェック。
Gasprice: ユーザーは、2 の 16 乗など、Gasprice の固定範囲で支払うことができます。あるいは、バッチごとに固定料金を設定したり、ガスの支払いをロールアッププロトコルから完全に外したりして、トランザクション参加者に州のチャネルを介してバッチ作成者に料金を支払わせることも可能です。
ガス: ガスの合計を 2 の倍数に制限することもできます。または、バッチ レベルでガス制限を設定します。
To: 20 バイトのアドレスをインデックスに置き換えることができます。アドレスがツリーに追加された 4527 番目のアドレスである場合、インデックス 4527 を使用してそれを参照するだけで、アドレスへのインデックスを保存するためにサブツリーが状態に追加されます。
値: 値を科学的表記法で保存できます。ほとんどの場合、転送に必要な有効数字は 1 ～ 3 桁のみです。
署名: BLS 集約署名を使用できます。これにより、多数の署名を約 32 ～ 96 バイトの 1 つの署名に集約できます (プロトコルに応じて)。この署名は、バッチ内のメッセージと送信者のセット全体に対してチェックできます。表中の「約 0.5」は、1 つのブロックで検証できる集合体に結合できる署名の数に制限があることを示しており、大規模なバッチでは 100 トランザクションごとに約 1 つの署名が必要になります。
これらの圧縮テクニックは、ロールアップのスケーラビリティの鍵となります。これらがなければ、ロールアップのスケーラビリティはおそらくベース チェーンの約 10 倍にすぎません (ただし、単純なロールアップでも強力な特定の計算集約型アプリケーションもあります)。データ圧縮を使用すると、ほぼすべてのアプリケーションのスケーラビリティは両方とも 100 以上を達成できます。回の改善。
副題
誰がバッチを送信できますか?
Optimistic または ZKRollups で誰がバッチを送信できるかについては、多くの議論があります。一般に、バッチを送信するには、ユーザーが多額のデポジットを支払わなければならないことに誰もが同意します。そのユーザーが不正なバッチ (無効なステート ルートなど) を送信した場合、このデポジットは部分的に破棄され、部分的に付与されます。報酬として詐欺証明者。しかし、それを超えて、多くの可能性があります。
完全な無秩序: 誰でもいつでもバッチを送信できます。これは最も簡単な方法ですが、いくつかの重要な欠点があります。複数の参加者がいる場合は、並行してバッチを生成して送信しようとしますが、最終的に正常にパッケージ化できるのは 1 つのバッチだけです。これは、プルーフの生成に多くの無駄な労力を費やすだけでなく、チェーンにバッチを公開する際のガスの無駄にもつながります。
集中処理: バッチを送信するためのシーケンサーが存在します (出金を除く: 通常の手法では、ユーザーはまず出金リクエストを送信し、シーケンサーが次のバッチで出金を処理しない場合は、ユーザーが自分でリクエストを送信できます)単一操作バッチ)。これは最も「効率的」ですが、その動作はコア アクターに依存します。
仕分け人オークション: 翌日の仕分け人になる権利を誰が持つかを決定するために、オークションが (たとえば毎日) 開催されます。このテクノロジーの利点は、ロールアップによって制御される DAO を通じてさらなる配布のための資金を調達できることです。 （参照：MEVオークション）
DPoS 投票: シリアライザーはオークションで選択されますが、パフォーマンスが低い場合、トークン所有者は投票してシリアライザーを追い出し、新しいオークションを開催できます。
副題
分割バッチとステートルート供給
現在開発中のロールアップは、「分割バッチ」アプローチを使用しています。つまり、L2 操作のバッチの送信と状態ルートの送信は別々に行われます。これにはいくつかの重要な利点があります。
多くのソーターは、他のいくつかのバッチが最初に含まれたために一部のバッチが無効になることを心配することなく、検閲耐性を高めるためにバッチを並行して公開することができます。
全体として、これは効率、単純さ、検閲耐性、その他の目標の間で複雑なバランスをとろうとする、かなり複雑な手法です。これらのアイデアのどの組み合わせが最適であるかを判断するのは時期尚早です。時間がすべてを証明してくれるだろう。
最初のレベルのタイトル
ロールアップはどの程度のスケーリングを実現できますか?
他の使用例の図を次に示します。
画像の説明
スケーラビリティの最大の向上は、(L1 ガスのコスト) / (ロールアップのバイト数 * 16) * 1,200 万 / 1,250 万として計算されます。
では、1000 ～ 4000 TPS を超えたい場合はどうすればよいでしょうか?ここで Eth2 データ シャーディングが登場します。シャーディングの提案では、12 秒ごとに 16 MB のスペースが提供され、あらゆるデータに対応でき、そのデータの可用性が保証されます。このデータ容量をRollupsで利用すると、毎秒約1398kbの容量となり、既存のイーサリアムチェーンの23倍となり、長期的にはさらなるデータ容量の増加が見込まれます。したがって、Eth2 シャード データを使用するロールアップでは、最大約 100,000 件のトランザクションを共同処理でき、将来的にはさらに多くのトランザクションを処理できます。
最初のレベルのタイトル
ロールアップには完全には解決されていないどのような課題がありますか?
ロールアップの基本概念は現在では十分に理解されており、実行可能かつ安全であり、メインネットに複数のロールアップがデプロイされていますが、ロールアップ設計にはまだ十分に検討されていない領域が多くあり、イーサリアム エコシステムの大部分が残されています。コンテンツをロールアップに完全に取り込むには多くの課題があります。いくつかの重要な質問は次のとおりです。
ユーザーとエコシステムのエントリー - ロールアップを使用するプロジェクトはそれほど多くなく、ユーザーはロールアップに慣れておらず、ロールアップを統合しているウォレットはほとんどありません。販売業者や慈善団体はまだこの支払い方法をサポートしていません。
クロスロールアップトランザクション - L1 手数料を発生させることなく、あるロールアップから別のロールアップにアセットとデータを効率的に移動します。
監査インセンティブ - 少なくとも 1 つの誠実なノードがオプティミスティック ロールアップを完全に検証し、問題が発生したときに不正行為の証拠をブロードキャストできる可能性を最大化するにはどうすればよいでしょうか?小規模なロールアップ (1 秒あたり最大数百のトランザクション) の場合、この問題はマイナーの労力の問題であるため、大きな問題ではありませんが、大規模なロールアップの場合、マイナーにそうするよう説得するにはさらに多くの理由が必要です。検証。
Plasma と Rollups の間の設計空間を探索する - 状態の更新に関連するデータのすべてではなく一部をオンチェーンに配置して、何か役立つものを生み出すためのテクニックはありますか?
最大限の事前確認の安全性 - 多くのロールアップは、より迅速なユーザー エクスペリエンスを実現するために「事前確認」の概念を提供します。この場合、注文者は、トランザクションが次のバッチに含まれることをすぐに約束し、注文者が約束に違反した場合、預金者の預金は破棄されます。しかし、多くのアクターに対して同時に多くのコミットメントを行うことができるため、このスキームの経済的安全性には限界があります。この仕組みは改善できるのでしょうか？
効率的な ZK-VM - 汎用 EVM コード (または既存のスマート コントラクトがコンパイルできる別の VM) が正しく実行され、所定の結果が得られたことを証明する ZK-SNARK を生成します。
最初のレベルのタイトル
結論は
技術設計の観点から見ると、不正証明を使用するオプティミスティック ロールアップや有効性証明を使用する ZK ロールアップ (ZK-SNARK) など、ロールアップには多くの種類があります。ロールアップはまだ初期の、急速に発展しているテクノロジーであり、今後数年間でロールアップの分野でさらに多くのエキサイティングなプロジェクトが登場すると予想されます。
