V God の傑作ロールアップをレビューし、イーサリアムに第 2 層拡張ソリューションが必要な理由を詳しく説明

原作者：ヴィタリック

翻訳・校正：タンタンランド

元のリンク: https://vitalik.ca/general/2021/01/05/rollup.html

ロールアップはイーサリアム コミュニティで大流行しており、将来的にはイーサリアムの主要なスケーラビリティ ソリューションになることが期待されています。しかし、このテクノロジーとは正確には何で、そこから何が期待できるのでしょうか? そしてそれはどのように使われるのでしょうか？この記事では、イーサリアムのいくつかの重要な拡張計画の分析に基づいて、ロールアップに関連するいくつかの重要な質問に答えようとします。

 背景: L1 と L2 とは何ですか?

ブロックチェーンエコシステムを拡張するには 2 つの方法があります。1 つ目は、ブロックチェーン自体に高いトランザクション機能を持たせることです。このテクノロジーの主な課題は、「大きなブロック」を含むブロックチェーンは本質的に検証がより難しく、より集中化する可能性があることです。このリスクを回避するために、開発者はクライアント ソフトウェアをより効率的にするか、シャーディングなどのテクノロジーを継続的に使用して、チェーンの構築と検証の作業を複数のノードに分割できるようにします。それが現在構築中のイーサリアムのアップグレードです。

2 番目に、ブロックチェーンの使用方法を変えることができます。ユーザーは、すべてのアクティビティをブロックチェーン上で直接実行するのではなく、ほとんどのアクティビティをオフチェーンの「レイヤー 2」プロトコルで実行します。オンチェーンにはスマート コントラクトがあり、そのタスクは 2 つだけです。入出金を処理することと、オフチェーンで発生するすべてのことがルールに従っていることの証明を検証することです。これらの証明を行う方法は複数ありますが、すべての方法には、元の計算をオフチェーンで実行するよりもオンチェーンで証明を検証する方がはるかに安価であるという共通の特性があります。

 状態チャネル vs プラズマ vs ロールアップ 

L2 層ソリューションには、ステート チャネル、プラズマ、ロールアップの 3 つの主なタイプがあります。これらは異なるパラダイムに属し、異なる利点と欠点を持っていますが、以下ではこれら 3 つの異なる方式の動作方法について説明します。

ステートチャネルの仕組み

アリスがボブにネットワーク接続を提供し、ボブが 1 メガバイトあたり 0.001 ドルを支払う特定のケースを想定します。毎回支払いを要求する代わりに、トランザクションでは次の L2 スキームが使用されます。

まず、ボブは 1 USD (ETH またはステーブルコイン相当) をスマート コントラクトに投入します。アリスに最初の支払いを行うために、ボブは「$0.001」と書かれた「チケット」（オフチェーン メッセージ）に署名し、それをアリスに送信します。2 回目の支払いを行うために、ボブは「$0.002」と書かれた別のチケットに署名し、アリスに送信します。など、必要なだけ支払いを行います。アリスとボブが取引を完了すると、アリスは最高額の紙幣をチェーンに発行し、それを自分の別の署名で包みます。スマート コントラクトはアリスとボブの署名を検証し、ボブのチケットに記載されている金額をアリスに支払い、残りをボブに返します。アリスが（悪意や技術的障害により）チャネルを閉じることに抵抗がある場合、ボブは終了期間（たとえば 7 日間）を開始できます。アリスがこの期間内にチケットを提供しない場合、ボブは全額を返金します。

このテクノロジーの強力な点は、双方向の支払いを処理するスマート コントラクト関係を調整できることです。たとえば、アリスとボブはチャネル内で契約に署名します。アリスとボブが開いたチャネルを持っていて、ボブとチャーリーも開いている場合、アリスは信頼なしにチャーリーと対話できます。

ただし、チャネルでできることには制限があります。たとえば、チャネルを使用して、まだ参加していない人にオフチェーンで資金を送信することはできません。明確な論理所有者を持たないオブジェクト (Uniswap など) を表すためにチャネルを使用することはできません。単純な定期的な支払いよりも複雑なニーズがある場合、ロックするには多額の資金が必要になります。

参照: https://www.jeffcoleman.ca/state-channels および statechannels.org

プラズマの仕組み

資産を預けるために、ユーザーはプラズマチェーンを管理するスマートコントラクトに資産を送信します。プラズマ チェーンは、資産に新しい一意の ID (例: 537) を割り当てます。すべてのプラズマ チェーンにはオペレーターがあります(これは、集中型アクター、マルチシグ、または PoS や DPoS などのより複雑なものである可能性があります)。間隔ごと (15 秒、1 時間、またはその間の任意の間隔)、オペレーターはオフチェーンで受信したすべての Plasma トランザクションを含む「バッチ」を生成します。これらはマークル ツリーを生成します。ツリー内の各インデックスには、そのようなトランザクションが存在する場合には資産 ID を転送するトランザクションがあり、存在しない場合にはリーフはゼロになります。

また、各インデックスのマークル ブランチを資産の現在の所有者に送信します。資産を引き出すには、ユーザーは最新のトランザクションのマークル ブランチを公開し、資産を送信してもらいます。契約はチャレンジ期間を開始します。この期間中は、誰でも他のマークル ブランチを使用して、( i)送信者が送信時にアセットを所有していないこと、(ii)後で所有することによって、Exit が無効であることを証明しようとすることができます。クリックしてアセットを他の人に送信します。7 日以内に出金が不正であることを誰も証明できなかった場合、ユーザーは資産を出金することができます。

プラズマは、国家チャネルよりも強力な特性を備えています。システムに参加したことのない参加者にも資産を送信でき、資本要件が非常に低くなります。その代償として、「通常の動作」中、チャネルはチェーンにデータをアップロードする必要がありませんが、Plasma では各チェーンが定期的にハッシュ値を公開する必要があります。さらに、プラズマ ボディの転送は即時ではないため、間隔が終了し、ブロックがチェーン上に公開されるまで待つ必要があります。

さらに、プラズマとチャネルには共通の弱点があります。つまり、それらのセキュリティは、両方のシステムによって制御されるすべてのオブジェクトには論理的な「所有者」が存在するという理論に依存しているということです。その所有者が自分の資産を気にしない場合、その資産に関連する「無効な」結果が生じる可能性があります。これは多くのアプリケーションでは問題ありませんが、他の多くのアプリケーションにとっては問題です。所有者の同意なしにオブジェクトの状態を変更するシステム (同意なしに誰かの残高を増やすことができるアカウントベースのシステムなど) であっても、Plasma とはうまく連携できません。これは、プラズマまたはチャネルの導入では、多くの「アプリケーション固有の推論」が必要であり、イーサリアム環境 (または「EVM」) 全体をエミュレートするだけのプラズマまたはチャネル システムを作成することは不可能であることを意味します。この問題を解決するには、3 番目のオプションであるロールアップから始めましょう。

参照: http://plasma.io/plasma-deprecated.pdf

ロールアップの仕組み

ロールアップについて

プラズマとチャネルは、データと計算の両方をオフチェーンに移動しようとするという点で「完全な」L2 ソリューションです。ただし、データの可用性に関する基本的なゲーム理論の問題により、すべてのアプリケーションでこれを安全に行うことは不可能です。プラズマとチャネルは、所有者の概念に依存することでこの問題を解決しますが、これはそれらの適用範囲に影響します。ただし、ロールアップは「ハイブリッド」L2 スキームです。ロールアップは計算 (および状態ストレージ) をオフチェーンに移動しますが、各タスクのデータの一部はオンチェーンに保持されます。効率を向上させるために、可能な限りデータを計算に置き換えるために、多くの複雑な圧縮技術が使用されています。その結果、システムのスケーラビリティは依然として基盤となるブロックチェーンのデータ帯域幅によって制限されますが、程度はより低くなります。イーサリアムベースレイヤーでの ERC20 トークン転送には約 45,000 ガスのコストがかかりますが、ロールアップでの ERC20 トークン転送には 16 バイトのデータが必要です。オンチェーンスペース、コストは 300 ガス未満。

IPFSには特定のデータが利用可能かどうかについての合意がなく、データはブロックチェーン上に存在する必要があるため、「IPFS にデータを置く」ことは機能しないことに注意してください。データをオンチェーンに置くというコンセンサスにより、Rollups を使用すると、必要に応じて誰でもあらゆる操作をローカルで処理できるようになり、不正行為の検出、引き出しの開始、またはトランザクション バッチの生成を自分で開始できるようになります。データの可用性の問題が存在しないということは、悪意のあるオペレーターやオフラインのオペレーターによる被害が少ないことを意味します (たとえば、1 週間の遅延を引き起こすことができない)。ロールアップの方が推論しやすく、バッチをリリースする許可を持つユーザーが使用できるスペースが大きくなります。それに加えて、データ可用性の問題がないことは、資産を所有者にマッピングする必要がなくなったことを意味し、イーサリアム コミュニティはロールアップ拡張機能に非常に関心を持っています。ロールアップは完全にユニバーサルであり、ロールアップで EVM を実行することも可能です。既存の一部の Ethereum アプリケーションは、新しいコードをほとんど記述する必要なくロールアップに移行します。

参照: https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/

ロールアップの仕組み

チェーン上にはスマート コントラクトがあり、状態ルート、つまりロールアップ状態のマークル ルート (ロールアップ「内部」のアカウント残高、契約コードなどを意味します) を維持します。

誰でも、以前の状態ルートと新しい状態ルート (トランザクション処理後のマークル ルート) とともに、高度に圧縮されたトランザクションのセットであるバッチを公開できます。コントラクトは、バッチ内の以前の状態ルートが現在の状態ルートと一致するかどうかを確認し、一致する場合は、状態ルートを新しい状態ルートに切り替えます。

入金と出金をサポートするために、概要ステータス「アウト」のトランザクションをインポートまたはエクスポートする機能が追加されました。バッチに外部からの入力がある場合、バッチをコミットするトランザクションもそれらのアセットをロールアップ コントラクトに転送する必要があります。バッチに外部への出力がある場合、スマート コントラクトはバッチの処理中にこれらの出金を開始します。

バッチ内の状態後の原点が正しいことはどのようにしてわかりますか? 誰かが何の影響もなくポストステートルートを使用してバッチを送信できれば、ロールアップ内のすべてのコインを自分に転送できます。この問題は重大であり、2 つの異なるソリューション ファミリが生じ、その結果、2 つの異なるタイプのロールアップが生成されます。

楽観的ロールアップと ZK ロールアップ 

ロールアップには次の 2 種類があります。

1. Optimistic Rollups (Optimistic Rollups)、不正証明を使用: Rollups コントラクトは、状態ルートと各バッチのハッシュの履歴全体を追跡します。誰かがバッチのポストステートルートが間違っていることを発見した場合、バッチの計算が間違っていることを証明するリンク先の証明を投稿できます。契約により証明が検証され、このバッチと後続のすべてのバッチが復元されます。

1. ZKRollups (ゼロ知識ロールアップ)、有効性証明を使用: 各バッチには、ZK-SNARK と呼ばれる暗号証明 (たとえば、PLONK プロトコルを使用) が含まれており、ポストステートのルートがバッチ実行の正しい結果であることを証明します。証明の計算量がどれほど多くても、チェーン上で非常に迅速に検証できます。

2 種類のロールアップの間には複雑なトレードオフがあります。

財産	オプティミスティックロールアップ	ZK ロールアップ
トランザクションごとの固定ガスコスト	~40,000 (主に状態ルートの値を変更するだけの軽量トランザクション)	~500,000 (ZK-SNARK の検証はかなりの計算量を要します)
退出期間	約 1 週間 (不正行為の証拠を提出し、不正行為の場合は出金をキャンセルする時間を与えるために、出金を遅らせる必要があります)	非常に速い (次のバッチを待つだけ)
技術的な複雑さ	低い	高 (ZK-SNARK は非常に高度で複雑なテクノロジーです)
多用途性	簡単 (ユニバーサル EVM ロールアップはメインネットに近い)	より困難 (ZK-SNARK は、一般的な EVM 実行を証明するのは、単純な計算を証明するよりもはるかに困難ですが、これを改善する取り組み (例: Cairo) があります)
各トランザクションのチェーン上のガスコスト	より高い	下位 (トランザクション内のデータが検証のみを目的としており、状態変化を引き起こさない場合、このデータは省略できますが、OptimisticRollups では、不正行為の証拠としてチェックする必要がある場合に備えてデータを公開する必要があります)
オフチェーンの計算コスト	低い (ただし、計算をやり直すには多くの完全なノードが必要です)	高 (特に汎用計算の場合、ZK-SNARK 証明は高価になる可能性があり、おそらく計算を直接実行するよりも数千倍高価になる可能性があります)

全体として、短期的には、汎用 EVM コンピューティングでは Optimistic の Rollups が勝つ可能性が高く、一方、単純な決済、為替、その他のアプリケーション固有のユースケースでは ZK Rollups が勝つ可能性が高いです。

不正行為の証明の構造

オプティミスティック ロールアップのセキュリティは、誰かが無効なバッチをロールアップに公開した場合、不正行為を検出した他の人が不正行為の証拠を公開して、そのバッチが無効であり復元する必要があることを契約に証明できるという前提に基づいています。

上の図からわかるように、バッチが無効であると主張する不正証明には、グリーン データ (バッチ自体 (チェーンに保存されているハッシュと照合できる) と、マークル ツリーの必要な部分だけが含まれます) が含まれます。バッチ固有のアカウントによって読み取りおよび/または変更されたことが証明されること。黄色のツリーのノードは緑色のノードから再構築できるため、提供する必要はありません。このデータは、バッチを実行し、ポストステートのルートを計算するのに十分です (これは、ステートレス クライアントが単一のブロックを検証する方法とまったく同じであることに注意してください)。計算された事後状態ルートがバッチで提供された事後状態ルートと同じでない場合、そのバッチは不正です。

確かなことは、バッチが間違って構築され、以前のすべてのバッチが正しく構築されていた場合、バッチが間違って構築されたことを示す不正証拠を作成できる可能性があるということです。以前のバッチに関する記述に注意してください。複数の無効なバッチがロールアップに投稿された場​​合は、最も古いバッチが無効であることを証明することを試みるのが最善です。もちろん、バッチが正しく構築されていれば、そのバッチが無効であるという不正行為の証拠を作成することは決して不可能です。

データ圧縮の原理

単純な Ethereum トランザクション (ETH の送信) には約 110 バイトが必要です。ただし、ロールアップでの ETH 転送は約 12 バイトしか消費しません。

パラメータ	イーサリアム	ロールアップ
ノンス	~3	0
ガスプライス	~8	0～0.5
ガス	3	0～0.5
に	21	4
価値	~9	~3
サイン	～68（2+33+33）	~0.5
から	0 (署名から回復)	4
合計	~112	~12

これの一部は単なる高レベルのエンコードです。イーサリアムの RLP は各値の長さで 1 バイトを無駄にします。ただし、次のような特定の圧縮技術も含まれています。

• Nonce : このパラメータの目的は、リプレイ攻撃を防ぐことです。アカウントの現在のナンスが 5 の場合、そのアカウントの次のトランザクションのナンスは 5 でなければなりません。トランザクションが処理されると、アカウントのナンスは 6 に増加するため、トランザクションを再度処理することはできません。ロールアップでは、以前の状態からノンスを復元しているだけなので、ノンスを完全に省略できます。誰かが以前のノンスを使用してトランザクションを再実行しようとした場合、署名はより高いノンス チェックを含むデータに対するものとなるため、署名は検証されません。

• Gasprice : ユーザーは、2 の 16 乗など、固定範囲の Gasprice で支払うことができます。あるいは、各バッチに固定料金を設定したり、ガスの支払いをロールアップ プロトコルの外に完全に移動して、トランザクション参加者が状態チャネルを通じてバッチ作成者に支払うようにすることもできます。

• Gas : Gas の合計を 2 の倍数に制限することもできます。または、バッチ レベルでガス制限を設定します。

• To : 20 バイトのアドレスをインデックスに置き換えることができます。アドレスがツリーに追加された 4527 番目のアドレスであり、それを参照するためにインデックス 4527 を使用するだけの場合、アドレスへのインデックスを保存するためにサブツリーが状態に追加されます。

• 値: 値を科学的表記法で保存できます。ほとんどの場合、転送には有効数字 1 ～ 3 桁のみが必要です。

• 署名: BLS を使用して署名を集約できます。これにより、多数の署名を約 32 ～ 96 バイトの単一の署名に集約できます (プロトコルによって異なります)。この署名は、バッチ内のメッセージと送信者のセット全体に対してチェックできます。表の「約 0.5」は、集約して単一のブロックで検証できる署名の数に制限があることを示しているため、大規模なバッチでは 100 トランザクションごとに約 1 つの署名が必要になります。

ZK ロールアップの重要な圧縮テクニックは、トランザクションの一部が検証のみに使用され、状態更新の計算に関連しない場合、その部分はオフチェーンのままにできることです。これは、オプティミスティック ロールアップでは実行できません。これは、後から不正行為の証明でデータをチェックする必要がある場合でも、データをチェーンに含める必要があるのに対し、ZKRollups では、バッチの正しさを証明する SNARK によって次のことが証明されているためです。検証に必要なデータ。プライバシー保護機能を備えたロールアップは重要な例です。オプティミスティック ロールアップでは、各トランザクションでプライバシーに約 500 バイトが使用され、ZK-SNARK がチェーン上にある必要がありますが、ZKRollups では、バッチ全体をカバーする ZK-SNARK がすでにショーを超えています。 「内部の」ZK-SNARK が機能するかどうかは疑わしい。

これらの圧縮技術は、Rollups のスケーラビリティの鍵となります。これらがなければ、ロールアップのスケーラビリティはおそらくベース チェーンの約 10 倍にすぎません (ただし、単純なロールアップでも強力な計算集約型の特定のアプリケーションもあります) が、データ圧縮を使用すると、ほぼすべてのアプリケーションがスケーラブルになります。 100倍の改善。

誰がバッチを送信できますか?

Optimistic または ZKRollups で誰がバッチを送信できるかについては、多くの意見があります。一般に、バッチを送信できるようにするには、ユーザーが多額のデポジットを支払わなければならないことに誰もが同意します。ユーザーが不正なバッチ (無効なステート ルートなど) を送信した場合、デポジットは部分的に破棄され、部分的に付与されます。報酬として 詐欺証明者。しかし、それを超えて、多くの可能性があります。

• 完全なアナーキー: いつでも誰でもバッチを送信できます。これは最も単純な方法ですが、いくつかの重要な欠点があります。複数の参加者がいる場合、バッチが生成され、並行して送信が試行されますが、最終的に正常にパッケージ化できるのは 1 つのバッチだけです。その結果、プルーフの生成に多くの労力が無駄になり、バッチをチェーンに公開する際にガスが無駄になります。

• 集中処理: バッチを送信するためのシーケンサーがあります (出金を除く: 通常の手法では、ユーザーが最初に出金リクエストを送信し、シーケンサーが次のバッチで出金を処理しない場合は、ユーザーが自分でリクエストを送信できます)単一操作バッチ)。これは最も「効率的」ですが、その動作はコア アクターに依存します。

• 仕分け人オークション: 翌日の仕分け人になる権利を誰が持つかを決定するために、オークションが (例: 毎日) 開催されます。このテクノロジーの利点は、ロールアップによって制御される DAO を通じてさらなる配布のための資金を調達できることです。（参照：MEVオークション）

• PoS セットからランダムに選択: 誰でも ETH (またはロールアップ独自のプロトコル トークン) をロールアップ コントラクトに入金でき、各バッチの注文者は入金者の 1 人からランダムに選択されます。確率は金額に比例します。預けられた。この手法の主な欠点は、大量の不必要な資本がロックされてしまうことです。

• DPoS 投票: シーケンサーはオークションで選択されますが、パフォーマンスが悪い場合、トークン所有者はシーケンサーを投票で除外し、新しいオークションを開催できます。

分割バッチとステートルートプロビジョニング

現在開発中のロールアップは、「分割バッチ処理」方式を使用しています。つまり、L2 操作のバッチの送信と、状態のルート操作の送信は別々に完了します。これにはいくつかの重要な利点があります。

1. 多くの注文者は、他のバッチが最初に含まれていたために一部のバッチが無効になることを心配することなく、検閲耐性を高めるためにバッチを並行して公開することができます。

1. 状態ルートが不正な場合は、バッチ全体を復元する必要はありません。状態ルートを復元し、誰かが同じバッチに新しい状態ルートを提供するのを待つだけで済みます。これにより、トランザクション送信者は、トランザクションが取り消されないことをより確実に保証できます。

全体的に見て、これは効率、シンプルさ、検閲耐性、その他の目標の間の複雑なトレードオフのバランスをとろうとするかなり複雑なテクノロジーです。これらのアイデアのどの組み合わせが最適であるかを判断するのは時期尚早です。時間がすべてを証明してくれるだろう。

 ロールループはどれだけの拡張をもたらすでしょうか? 

既存のイーサリアム チェーンでは、ガス制限は 1,250 万で、トランザクション内のデータの各バイトには 16 ガスのコストがかかります。これは、ブロックに 1 つのバッチのみが含まれる場合 (ZKRollups が使用され、証明検証に 500,000 ガスのコストがかかると仮定します)、バッチには (1,200 万 / 16) = 750,000 バイトのデータを含めることができることを意味します。上に示したように、ETH 転送ロールアップにはユーザー操作ごとに 12 バイトしか必要ありません。これは、バッチに最大 62,500 個のトランザクションを含めることができることを意味します。平均ブロック時間 13 秒で、これは約 4,807 TPS に相当します (イーサリアム自体の 1,250 万 / 21,000 / 13 ~= 45 TPS と比較して、直接 ETH 転送を行うことができます)。

他の使用例の図を次​​に示します。

応用	ロールアップ内のバイト数	L1ガス料金	スケーラビリティの最大の向上
ETH送金	12	21,000	105 倍
ERC20転送	16 (さらに 4 バイトはどのトークンを指定するために使用されます)	～50,000	187倍
ユニスワップ取引	~14 (送信側 4 バイト + 受信側 4 バイト + 値 3 バイト + 最大価格 1 バイト + その他の 1 バイト)	～100,000	428倍
楽観的なロールアップ	296 (4 バイトのルート インデックス + 32 バイトのキャビテーター + 4 バイトのレシーバー + 256 バイトの ZK-SNARK プルーフ)	～380,000	77 倍
ZK ロールアップ	40 (ルートの 4 バイトのインデックス + 32 バイトのキャビテーター + 4 バイトのレシーバー)	～380,000	570倍

スケーラビリティの最大の向上は、(L1 ガスのコスト) / (ロールアップのバイト数 * 16) * 1,200 万 / 1,250 万として計算されます。

これらの数字は楽観的すぎることに注意する価値があります。少なくとも複数のロールアップが存在し、今後も存在するため、チャンクにバッチが 1 つだけ含まれることはほとんどありません。第二に、入金と引き出しは引き続き存在します。第三に、短期的には稼働率が低くなるため、固定費が大半を占めることになります。しかし、これらの要因を考慮しても、100 倍を超えるスケーラビリティの向上が標準になると予想されます。

では、約 1000 ～ 4000 TPS を超えたい場合はどうすればよいでしょうか? ここで Eth2 データ シャーディングが登場します。シャードの提案では、12 秒ごとに 16 MB のスペースが提供され、あらゆるデータに対応でき、そのデータの可用性が保証されます。このデータ容量をロールアップで利用すると、毎秒約1398kbの容量となり、既存のイーサリアムチェーンの23倍となり、長期的にはさらなるデータ容量の増加が見込まれます。したがって、Eth2 シャード データを使用するロールアップでは、最大約 100,000 件のトランザクションをまとめて処理でき、将来的にはさらに多くのトランザクションを処理できます。

 Rol lupがまだ十分に取り組んでいない課題は何ですか?

ロールアップの基本概念は現在では十分に理解されており、実行可能かつ安全であり、すでに複数のロールアップがメインネットにデプロイされていますが、ロールアップ設計にはまだ十分に検討されていない領域が多くあり、イーサリアム エコシステムの大部分が残されています。コンテンツをロールアップに完全に導入するには多くの課題があります。いくつかの重要な質問は次のとおりです。

• ユーザーとエコシステムの関与 - ロールアップを使用するプロジェクトは多くなく、ユーザーはロールアップに慣れておらず、ロールアップを統合しているウォレットはほとんどありません。販売業者や慈善団体はまだこの支払い方法をサポートしていません。

• クロスロールアップトランザクション - L1 経由で手数料を発生させることなく、資産とデータを 1 つのロールアップから別のロールアップに効率的に移動します。

• 監査インセンティブ - 少なくとも 1 つの誠実なノードがオプティミスティック ロールアップを完全に検証し、問題が発生した場合に不正行為の証拠をブロードキャストする可能性を最大化するにはどうすればよいでしょうか? 小規模なロールアップ (1 秒あたり最大数百のトランザクション) の場合、マイナーにとっては簡単なことなので、これは大きな問題ではありませんが、大規模なロールアップの場合は、マイナーにそうするよう説得するには、より十分な理由が必要です。検証。

• Plasma と Rollups の間の設計空間の探索 - 状態の更新に関連するすべてではなく、一部のデータをオンチェーンに配置して有用なものを生成する技術はありますか?

• 事前確認のセキュリティを最大化 - 多くのロールアップは、より迅速なユーザー エクスペリエンスを実現するために「事前確認」の概念を提供します。この場合、注文者は、トランザクションが次のバッチに含まれることをすぐに約束し、注文者が約束を破った場合、注文者の預金は破棄されます。しかし、多くのアクターに対して同時に多くのコミットメントを行うことができるため、このプログラムの経済的安全性には限界があります。この仕組みは改善できるのでしょうか？

• 欠落しているソーターへの対応の改善 - ロールアップのソーターが突然オフラインになった場合、この状況から短時間で回復するには、別のロールアップまたは別のソーターに迅速かつ低コストで切り替える必要があります。

• 効率的な ZK-VM  - ZK-SNARK を生成すると、汎用 EVM コード (または既存のスマート コントラクトをコンパイルできる別の VM) が正しく実行され、所定の結果が得られたことが証明されます。

 結論は 

ロールアップは強力で斬新な L2 スケーリング ソリューションであり、イーサリアムの短期および中期 (場合によっては長期) スケーリングの基礎となることが期待されています。以前の L2 拡張機能とは異なり、共通の EVM コードをサポートできるため、既存のアプリケーションを簡単に移行できます。一方、ロールアップは、トランザクション処理が完全にオフチェーンで実行されるわけではなく、各トランザクションがオンチェーンにデータのごく一部を残すという点でイーサリアム コミュニティで大きな注目を集めています。

技術的な設計の観点から見ると、不正行為の証明を使用するオプティミスティック ロールアップや、有効性の証明を使用する ZKRollups (ZK-SNARK) など、ロールアップには多くの種類があります。ロールアップはまだ初期の急速に進化しているテクノロジーであり、今後数年間でロールアップ分野でさらにエキサイティングなプロジェクトが登場すると予想されます。