ロールアップの不完全なガイド

編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfa​​ns)編集者注: この記事は以下から引用しました

イーサリアム愛好家 (ID: ethfa​​ns)

• イーサリアム愛好家 (ID: ethfa​​ns)

、著者: Vitalik、翻訳および校正: Shengchao & A Jian、許可を得て Odaily が転載。

翻訳者注:

原文ではRollupが単数形と複数形で同時に複数出現するが、訳書では頭文字を大文字にしてRollupと統一している。Rollup は現在のイーサリアムコミュニティではすでに非常に有名です。予見可能な将来、ロールアップはイーサリアムが拡大を達成するための重要なソリューションとなります。しかし、ロールアップとは正確には何でしょうか?このテクノロジーから何が得られ、どのように使用できるのでしょうか?この記事では、いくつかの重要な質問に答えていきます。

背景知識: レイヤ 1 拡張とは何ですか? レイヤ 2 拡張とは何ですか?

スケーリングする 2 番目の方法は、ブロックチェーンの使用方法を変えることです。ユーザーは、すべてのアクティビティをブロックチェーンのメイン チェーンに直接置く必要はありませんが、ほとんどのアクティビティをメイン チェーンの外側の「第 2 層」プロトコルで実行し、チェーンの外側で発生したすべてのアクティビティを証明する証明書を生成します。ルール。スマート コントラクトはメイン チェーンにデプロイされます。メイン チェーンには、入金と出金の処理、および上記の証明の検証という 2 つのタスクだけがあります。証明と検証を実装する方法は複数ありますが、オンチェーンで証明を検証する方が、オフチェーンで生の計算を行うよりもはるかに低コストであるという共通の特性があります。中国語翻訳）。

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

レイヤ 2 拡張には、ステート チャネル、プラズマ、ロールアップの 3 つの主なソリューションがあります。 3 つのシナリオは 3 つの異なるパラダイムを表しており、それぞれに独自の長所と短所があります。すべてのレイヤ 2 拡張は、大まかにこれら 3 つのカテゴリに分類されます (「validium」など、一部の侵害ソリューションを分類する方法については議論があります) (編集者注:https://www.jeffcoleman.ca/state-channels ，statechannels.org中国語翻訳州チャネルはどのように機能しますか?"こちらも参照"アリスがボブにネットワーク接続サービスを提供すると想像してください。その代わりに、ボブはオンラインで生成されたトラフィックに対して 0.001 ドル/MB をアリスに支払います。ボブは、第 1 層メイン チェーンにすべての料金を支払う必要はなく、両当事者は次の第 2 層ソリューションを使用します。まず、ボブは 1 ドル (ステーブルコイン、または ETH の同等額) をスマート コントラクトに入金します。アリスに最初の支払いを行うために、ボブは契約書に署名します。

請求書

（オフチェーンメッセージ）、「チケット」には「$0.001」と書かれており、アリスに送信されます。 2 回目の支払いを行うために、ボブは「$0.002」と書かれた別のメモに署名し、アリスに送信します。など、支払いのたびにこのプロセスを繰り返します (翻訳者注: 状態チャネルの参加者は最新の状態変更を保持するだけでよいため、新しいチケットが署名されると、以前のチケットは無効になります)。アリスとボブがトランザクションを完了すると、アリスは最も価値のある請求書パッケージに署名を投稿し、それをメイン チェーンに公開できます (チャネルを閉じる)。スマート コントラクトは、アリスとボブの両方の署名を検証し、検証に合格した後、ボブのチケットにマークされた金額をアリスに支払い、残りの金額 (訳者注: 1 ドルから前者を差し引いた金額) をボブに返します。アリスが（悪意または技術的障害により）チャネルを閉じることに消極的な場合、ボブは出金チャレンジ期間（たとえば 7 日間）を開始できます。アリスがこの期間内にボブが支払った請求書を提出できない場合、ボブは取り消すことができます。以前のすべてのお金はスマートコントラクトに保存されます。ステート チャネル テクノロジは強力です。一般化されたステート チャネルは、双方向の支払いをサポートし、スマート コントラクトを実装でき (たとえば、アリスとボブがチャネル内で金融契約に署名します)、構成可能です (アリスとボブの間にオープン チャネルがある場合、ボブ アリスとチャーリーの間にはオープン チャネルもあるので、アリスは信頼関係なしにチャーリーと対話できます。しかし、チャネルの役割は限られており、まだチャネルに参加していないユーザーにオフチェーンで資金を送信することはできず、明確な論理所有者のないオブジェクト (Uniswap スマート コントラクトなど) には使用できません。さらに、チャネルによって処理されるトランザクションがマイクロペイメントのシナリオよりも複雑な場合、大量の資金をチャネルにロックする必要があります。プラズマの仕組みオリジナルの Plasma ホワイト ペーパー、Plasma Cash も参照してください。"メインチェーンからプラズマチェーンに資産を預けるには、ユーザーはメインチェーン上の資産をプラズマチェーンを管理するスマートコントラクトに送信する必要があります。プラズマ チェーンは、新しい一意の ID (例: 537) をアセットに割り当てます。すべてのプラズマ チェーンにはオペレーターがあります (これは、集中型アクター、マルチシグによって制御されるもの、または PoS チェーンや DPoS チェーンなどのより複雑なものである可能性があります)。時々 (15 秒、1 時間、またはその間の任意の時間) ごとに、オペレーターはすべてのプラズマ チェーンのトランザクションの「バッチ」を生成します。演算子はマークル ツリーを生成します。インデックス X のリーフ ノードで、資産 ID X の資産がこのバッチ内にトランザクションを持っている場合、対応するトランザクションはリーフ ノードに存在します。それ以外の場合、リーフ ノードはゼロになります。オペレーターは、このツリーのマークル ルートをメイン チェーンに公開します。オペレーターは、各インデックス X のマークル フォークをそのアセットの現在の所有者に送信する必要もあります。資産をプラズマチェーンからメインチェーンに抽出する必要がある場合、ユーザーは資産の最後のトランザクションに対応するマークルブランチをメインチェーンのスマートコントラクトに送信する必要があります。その後、スマート コントラクトはチャレンジ期間 (例: 7 日間) を開始します。この期間中は、誰でも他のマークル フォークを使用して、(i) ユーザーが引き出し時に資産を所有していなかった、または (ii) ユーザーが引き出し時に資産を所有していなかったということを証明できます。ある時点で資産が他の人に送信され、それにより出金申請が無効になりました。 7 日以内に出金が不正であることを誰も証明しなかった場合、ユーザーは無事に資産を取り戻すことができます。"プラズマは、ステート チャネルよりも強力なものを提供します。レイヤー 2 に参加したことのないユーザーにアセットを送信でき、ロックされた資金ははるかに低くなります。ただし、これには代償が伴います。ステート チャネルは、「通常」の場合はメイン チェーンにデータを保存する必要がありませんが、Plasma では、各チェーンがメイン チェーン上でハッシュ値を頻繁に公開する必要があります。さらに、Plasma チェーン内のトランザクションには即時性がありません。つまり、トランザクションのバッチ (Plasma ブロックとも呼ばれます) の証拠 (つまり、マークル ルート値) がメイン チェーンに送信されるまで待つ必要があります。

Rollup

さらに、プラズマ チャネルとステート チャネルの両方には重要な欠陥があります。それらのセキュリティ モデルの基礎となるゲーム理論は、両方のシステムによって制御される資産には論理的に所有者。資産所有者が自分の資産を気にしている限り、その資産に関係する状態変更が「無効」である場合、資産所有者はその変更が「無効」であることを示す方法を見つけるでしょう。これは一部のアプリケーションでは関係ありませんが、他の多くのアプリケーション (Uniswap など) では問題になります (仮定依存の考え方は矛盾します)。システム所有者の同意なしにシステム内のオブジェクトの状態を変更できる場合でも (たとえば、アカウントベースのシステムでは、所有者の同意なしに残高を増やすことができます)、プラズマ互換とはうまく機能しません。 。これは、実際にプラズマやステートチャネルを展開する場合、「特定のアプリケーション」の潜在的なロジック設計のカスタマイズスキームを推測する必要があり、イーサリアムの動作環境（つまり「EVM」）を完全にシミュレートできるプラズマを作成することは不可能であることを意味します。 ) またはステートチャネルシステム。次に、ロールアップがこの問題をどのように解決するかを見てみましょう。

参照: EthHub のオプティミスティック ロールアップの紹介、EthHub の ZK ロールアップの紹介

プラズマ チャネル スキームとステート チャネル スキームは両方とも、データと計算の両方をオフチェーン (つまり、独自のレイヤー 2 システム) に移動するという点で、「完全な」レイヤー 2 スキームです。ただし、データの可用性に関する基本的なゲーム理論の原則は、そのようなシステムがすべてのアプリケーションを安全に実装できるわけではないことを意味します。プラズマおよび状態チャネルは、資産オブジェクトと所有者の間の関係を明示することでこの問題を解決しますが、これにより完全に一般化することができなくなります。 Rollup は、「ハイブリッドな性質」を持つ 2 層ソリューションであるという点で、前の 2 つとは異なります。ロールアップは計算 (および完全な状態ストレージ) をオフチェーンに移動しますが、各トランザクションに関する部分的なデータ情報はオンチェーンに保持されます。効率を向上させるために、Rollup は一連の派手な圧縮トリックを使用し、可能な限りデータを計算に置き換えます。結果として、このシステムのスケーラビリティは依然として基盤となるブロックチェーンのデータ帯域幅によって制限されていますが、これに基づいて達成される拡張倍率は非常に印象的です。イーサリアム メイン チェーンで ERC-20 トークン転送を実行すると、約 45,000 ガスが消費されます。しかし、ロールアップでは、各トランザクションはメイン チェーンに 16 バイトのデータを保存するだけで済み、消費されるガスは 300 バイト未満です。メインチェーン上のデータストレージは、Rollup の重要な要素です (注: これは、「IPFS」にデータを保存することとは異なります。IPFS には保存されたデータについてのコンセンサスがなく、Rollup のデータはブロックチェーンに保存する必要があるためです)。メインチェーンにデータを保存し、コンセンサスを実施することで、だれでも不正行為の検出、出金の開始、バッチの生成など、ロールアップのすべての操作をローカルで処理できるようになります。データの可用性の問題がないため、オペレーターが悪事を行ったりオフラインになったりした場合でも被害が比較的少なく (たとえば、1 週間の終了遅延を引き起こすことはできません)、誰がバッチを発行する権利を持っているかについてより明確なビューを提供します。可能性が高まるだけでなく、ロールアップを理解しやすくなります。さらに重要なのは、データの可用性が存在しないということは、資産がその所有者と明確な論理マッピング関係を持つ必要がないことを意味します。他のレイヤー 2 拡張ソリューションと比較して、これはイーサリアム コミュニティがロールアップにさらに興奮する重要な要素です。ロールアップは普遍的であり、たとえば、EVM はロールアップで実行できるため、新しいアプリケーションを作成せずに既存のイーサリアム アプリケーションを実装できます。 . コードの場合はロールアップに移行します。ロールアップは具体的にどのように機能しますか?メインチェーンにはスマート コントラクトがあり、状態ルート (ロールアップ状態を表すマークル ルート) があります。 (ステータスの内容には、ロールアップのアカウント残高、契約コードなどが含まれます)

Optimistic rollups vs ZK rollups

誰でもメイン チェーン上のスマート コントラクトでバッチ トランザクション (トランザクション) を開始できます。このバッチは、古い状態のルートと新しい状態のルート (新しい状態に基づく古い状態のルート) を含む、ロールアップ内部トランザクションの高度に圧縮されたバッチです。バッチトランザクションの実行後に生成されるステートルート)。メインチェーンコントラクトは、古いステートルートが新しいステートルートと一致するかどうかをチェックします（翻訳者注：つまり、トランザクションセットのこのバッチによってトリガーされるステート遷移によって新しいステートルートが生成できるかどうか）。検証に合格すると、メインチェーン上の古い状態ルートが新しい状態ルートに更新されます。

• 入金 (翻訳者注: メイン チェーンの他の場所からロールアップ コントラクトに資産を預けること) と出金 (翻訳者注: ロールアップ コントラクトを自身の資産の管理から解放し、チェーン上の他の場所に戻すこと) をサポートするために、バッチ処理トランザクションの入力または出力は、ロールアップの「外部」の状態になる可能性があります。入力がロールアップ外部から来るトランザクションがバッチ内にある場合、このバッチ操作はメイン チェーンの他の場所からロールアップ コントラクトに資産を転送します。バッチ内にロールアップ外部からのトランザクション出力がある場合、このバッチはスマート コントラクトで引き出し操作をトリガーし、資産をロールアップからメイン チェーンに戻します。
• ZK Rollup,プロセス全体はとても簡単です。しかし、もう 1 つ詳細があります。バッチ実行の完了後にルートのステータスが正しいことを確認するにはどうすればよいですか?誰かが何の影響もなく偽の状態ルートを送信できれば、すべての資産を自分に移すことができます。この問題には 2 つの異なる解決策があり、結果として 2 種類のロールアップが発生するため、この問題は重要です。

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

Optimistic Rollup は上記の問題を解決するために不正証明を使用します。メイン チェーンの Rollup コントラクトは、Rollup の内部状態ルート変更の完全な記録と、各バッチ (状態ルート変更をトリガーする) のハッシュ値を記録します。バッチに対応する新しい状態ルートが間違っていることに誰かが気づいた場合、そのバッチによって生成された新しい状態ルートが間違っているという証拠をメインチェーンに投稿できます。コントラクトは証明を検証し、検証に合格すると、バッチ以降のすべてのバッチ トランザクションがロールバックされます。

上記の問題を解決するには、有効性証明を使用します。各バッチには、ZK-SNARK と呼ばれる暗号証明が含まれています (たとえば、PLONK プロトコルを使用して、このバッチ操作の後に新しい状態を古い状態から変換できることを証明します (翻訳者注: ZK では) Rollup は、提出された暗号証明が小さいサイズと高速検証の特性を備えていればよく、ゼロ知識である必要はないため、ZK Rollup は SNARK のみで実現でき、ZK-SNARK は必ずしも必要ではありません。 , ZK Rollupでは、バッチトランザクション情報がメインチェーンに保存されており、この情報がまさに暗号証明システムで証明されているものであるため、ZK Rollup自体はゼロ知識を持たず、ゼロ知識を持つZKロールアップはZKと呼ばれますZK Rollup) バッチ内の計算量に関係なく、証明はメインチェーン上で効率的に検証できます。

これら 2 つのロールアップ間の設計上のトレードオフは複雑です一般に、私自身の見解では、短期的には汎用 EVM の実現では Optimisitc Rollup が勝つ可能性が高く、単純な支払い、送金、その他の特定のアプリケーションでは ZK Rollup が勝つ可能性が高いと考えています。しかし、中長期的には、ZK-SNARK テクノロジーの改善により、ZK Rollup はあらゆるアプリケーション シナリオで勝利を収めることになります。不正防止の構造

オプティミスティック ロールアップのセキュリティは、誰かが無効なバッチをロールアップに公開した場合、チェーンを同期した人は誰でも、メイン チェーン上のコントラクトに不正証明を発行して、バッチの処理が無効であり、処理されるべきであることを証明できるという考えに依存しています。ロールバック (翻訳者注: ここでの著者の「チェーン」がメイン チェーンを指すのかロールアップを指すのかは不明ですが、どちらも正しいです)。

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

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

• 圧縮はどのように行われるのでしょうか?
• 最も単純なイーサリアム転送 (ETH の送信) には約 110 バイトかかりますが、ロールアップでの ETH 転送の実装には約 12 バイトしかかかりません。
• これは、イーサリアムの RLP が現在各値の長さで 1 バイトを無駄にしているのに対し、Rollup はよりシンプルで高度なエンコード技術を使用できるためです。同時に、Rollup は非常に巧妙な圧縮トリックも使用します。
• Nonce: このパラメータの目的は、リプレイを防止することです。アカウント状態の現在のノンスが 5 の場合、アカウントの次のトランザクションのノンス パラメーターは 5 である必要がありますが、トランザクションが処理されると、アカウント状態のノンスは 6 にインクリメントされるため、トランザクションは次のようになります。 nonce 5 は再びパックされません。ロールアップでは、更新前の状態からナンスを復元するだけでよいため、ノンスを完全に省略できます。誰かが以前のノンスでトランザクションを再実行しようとすると、署名の検証では検証に失敗します。より大きなノンスデータ。
• ガス価格: ユーザーが一定範囲のガス価格で支払うことができるようにすることができます。たとえば、範囲は 0 ～ 2 の 16 乗です。あるいは、バッチごとに定額料金を請求したり、ガスの支払いをロールアップから完全に移動して、トレーダーが特定のチャネルを通じてバッチ作成者に支払えるようにすることもできます。
• ガス: ガスの合計量が 2 の累乗になるように選択することもできます。あるいは、バッチ レベルでのみガス制限を設定することもできます。 (翻訳者注: ここでのガス価格とガスは、ロールアップ コントラクトとイーサリアム ネットワークを介した転送によって生成されるデータ量を比較するためのものです。ロールアップ プロトコルにこれらの概念が含まれなければならないという意味ではありません。たとえば、楽観的なロールアップとしての燃料UTXO に基づくプロトコルには、これらの概念はまったく含まれていません。)

To: 20 バイトのアドレスをインデックスに置き換えることができます (たとえば、アドレスがツリーに追加された 4527 番目のアドレスの場合、インデックス 4527 を使用してそれを表します。インデックスを保存するために状態にサブツリーを追加します)アドレスマッピング）。"値: 値を科学的表記法で保存できます。ほとんどの場合、転送に必要な有効数字は 1 ～ 3 桁のみです。"署名: BLS を使用して署名を集約すると、多くの署名が約 32 ～ 96 バイトの 1 つの署名に集約されます (使用するプロトコルによって異なります)。この署名は、メッセージと送信者のセット全体の署名を一度に検証するためにバッチ処理できます。表の ~0.5 は、メイン チェーン ブロックで検証できる集約署名の数が制限されていることを示します。そのため、バッチ内のトランザクションが多い場合は、約 100 トランザクションごとに集約署名を生成する必要があります。 (翻訳者注: 一般的な考え方は、集約された元の署名の数が増加するにつれて、集約された署名を検証するために必要な計算量が増加し、イーサリアムのメイン チェーン ブロックで使用できるガスの数が制限されているため、集約された署名を検証することはできないということです。一度に集約できない元の署名が多すぎます。)ZK ロールアップには、特別に重要な圧縮トリックがあります。トランザクションの一部が検証のみに使用され、状態更新の計算とは何の関係もない場合、データのこの部分をメイン チェーンに保存する必要はありません。これは、後続の不正証明検証のために時折必要になるためにデータをチェーン上に保存する必要があるため、Optimisitc Rollup では実行できません。ZK Rollup では、データのバッチの正しさを証明する SNARK 証明が実証されています。関係者が検証に必要なすべてのデータを提供していること。重要な例は、プライバシー保護プロパティを備えたロールアップの実装です。Optimisitc Rollup でプライバシー保護を実現するには、各トランザクションでプライバシーを保護するために使用される約 500 バイトの ZK-SNARK をチェーンにアップロードする必要があり、ZK でプライバシー保護を実現します。 Rollup 、バッチ全体をカバーする ZK-SNARK はすでに次のことを証明できます。

内部

ZK-SNARKが効果的です。 (翻訳者注: SNARK は入れ子にすることができるため、ZK ロールアップでプライバシー保護を実現するには、最終的に生成された最も外側の SNARK をチェーンに送信するだけで済みます。外側の SNARK を検証すると、内側の SNARK が有効になります。性別は、同時。）これらの圧縮技術が Rollup の拡張の鍵となります。これらの技術がなければ、Rollup はメイン チェーンの拡張に基づいて 10 倍程度の拡張しか達成できない可能性があります (ただし、一部の特定の大規模アプリケーションでは、単純な Rollup を使用することもできます)。スケーリングはすでに強力です) が、圧縮トリックを使用すると、ほぼすべてのアプリケーションで 100 倍を超えるスケーリングが可能になります。

• 誰がバッチを送信できますか?
• オプティミスティック ロールアップまたは ZK ロールアップでバッチを送信できる人については、多くの考え方があります。一般的に、バッチを送信するユーザーは多額のデポジットを誓約する必要があると考えられており、ユーザーが不正なバッチ (無効な状態ルートの送信など) を送信した場合、このデポジットの一部は燃え続け、他の部分は燃え続けます。不正行為の証拠を提出したユーザーに報酬が与えられます。しかし、それを超えて、多くの可能性があります。
• (翻訳者注、バッチをメインチェーンに公開できるユーザーはシーケンサー (ソーター) と呼ばれます。この用語の理由は、この役割がバッチ内のトランザクションをソートする必要があるためです)
• 完全に権限のないソーター: いつでも誰でもバッチを送信できます。この方法は最も単純ですが、複数の参加者が同時にバッチを生成して送信しようとし、そのうちの 1 つしか正常に含めることができないという問題など、いくつかの重大な欠点があります。これにより、プルーフを生成するための大量の無駄な計算オーバーヘッド、またはプルーフを送信するためのガス オーバーヘッドが発生します。
• 集中型ソーター: ソーターなどのロールを通じてバッチ処理を送信します (出金操作を除く: 出金操作では、ユーザーが最初に出金リクエストを送信し、ソーターが次のバッチで出金トランザクションを処理しない場合は、ユーザーが次のバッチで出金トランザクションを処理します)出金トランザクションを 1 つだけ含むバッチ リクエストは、個人で送信できます)。この方法は最も「効率」が高くなりますが、集中化された役割に依存する必要があります。

仕分け人オークション: 誰が翌日の仕分け人になる権利を持つかを決定するためのオークション (たとえば、毎日)。このスキームの利点は、資金を調達でき、その資金を Rollup の DAO を通じて分配できることです (MEV オークションを参照)。

PoS コレクションからのランダムな選択: 誰でも ETH (またはロールアップ プロトコルによって設定されたトークン) をロールアップ コントラクトに入金でき、各バッチ ソーターはこれらの入金者の中からランダムに選択され、選択される確率は入金と同じです。量は正比例します。このスキームの主な欠点は、多数の資産をロックする必要があることです。"split batch"DPoS 投票: バッチ処理を実行するために特定のソーターがオークションによって選択されますが、パフォーマンスが低下した場合、トークン所有者は投票してそれらを追い出し、新しいオークションを開催してそれらを置き換えることができます。

• 個別のバッチ ルート コミットとステータス ルート コミット
• 現在開発中の一部のロールアップは「分割バッチ」を使用しています (

) モード、つまり、レイヤー 2 トランザクション バッチのバッチを送信する動作と、状態ルートを送信する動作は、別々に実行されます。これにはいくつかの重要な利点があります。

多くの仕分け担当者がバッチを並行して発行できるようにすることで、検閲への耐性を高め、他のバッチが事前にパックされたために一部のバッチが無効になるという懸念を軽減できます。

1 つのステート ルートが不正な場合は、バッチ全体をロールバックする代わりに、ステート ルートをロールバックして、誰かが同じバッチに新しいステート ルートを提供するのを待つことができます。これにより、送信者のトランザクションがロールバックされないことがより確実になります。ロールアップはどの程度の拡張をもたらしますか?

既存のイーサリアム メイン チェーンでは、各ブロックのガス ラインは 1,250 万で、トランザクションの各バイトにはチェーン上の 16 ガスのコストがかかります。これは、ブロックにバッチが 1 つだけ含まれている場合 (ここでは ZK ロールアップが使用され、検証証明に 500,000 ガスかかると仮定)、このバッチには 1,200 万 / 16 = 750,000 バイトのデータを含めることができます。上で述べたように、ロールアップでの各 ETH 転送には 12 バイトのストレージのみが必要です。つまり、各バッチには 62,500 のトランザクションを含めることができます。現在、イーサリアムメインチェーンのブロック間隔は13秒なので、実現されるTPSは約4807になります（比較すると、イーサリアムメインチェーンでのETH転送のTPSは約1250000 / 21000 / 13 = 45）。

次の表には、他のいくつかのアプリケーション シナリオの拡張効率が含まれています。画像の説明

最大拡張倍数の計算方法：イーサリアムメインチェーン上の該当オペレーションのガス消費量 / (Rollupにおける該当オペレーションでチェーンにアップロードされるバイト数 * 16) * 1200万 / 1250万

いくつかの理由から、これらの数字は実際には楽観的すぎることに注意する必要があります。最も重要な理由は、複数の異なるロールアップ システムが存在するため、ブロックに 1 つのバッチだけを含めることがほぼ不可能であるということです。 2つ目の理由は、常に入金と出金が発生するためです。 3 番目の理由は、ロールアップの使用量が短期的には低い可能性があるため、固定コストの課金モデルが主流になる可能性があることです。しかし、これらの要素を考慮しても、100 倍を超える拡大を達成することは難しくないはずです。

• では、(特定のアプリケーション シナリオに応じて) 1000 ～ 4000 TPS を達成したい場合はどうすればよいでしょうか?これには eth2 データの断片化が必要です。この提案では、16 MB のストレージ スペースが 12 秒ごとに作成され、そこに任意のデータを入れることができ、システムはこれらのデータの可用性についてのコンセンサスを確保します。このデータスペースはロールアップで使用できます。この約1398 kB/sのデータスループットは、現在のイーサリアムメインチェーンの約60 kB/sに比べて23倍高く、長期的にはさらにデータ容量が増加すると予想されます。したがって、eth2 データ シャーディングを使用して実装されたロールアップの TPS は 100,000 に達する可能性があり、将来的にはさらに大きくなる可能性があります。
• 残された未解決の課題は何ですか?
• Rollup の基本的な概念は人々によく知られており、Rollup が本質的に実行可能で安全であると確信しており、イーサリアム メインネットにはすでに複数の Rollup がデプロイされていますが、Rollup の設計にはまだ多くの箇所があります。 、スケーラビリティを活用するためにイーサリアム エコシステムの大部分を完全にロールアップに組み込むにはまだ課題があります。主要な課題には次のようなものがあります。
• ユーザーとエコシステムの参入: 現在、Rollup を使用するアプリケーションはそれほど多くなく、ユーザーは Rollup に慣れておらず、Rollup を統合し始めているウォレットはほとんどありません。販売業者や慈善団体はまだ支払いを受け付けていません。
• クロスロールアップトランザクション: メインチ​​ェーンを介して転送したり、対応する手数料を発生させたりすることなく、あるロールアップから別のロールアップに資産とデータ (オラクルマシンの出力など) を効果的に転送します。
• 監査インセンティブ: 少なくとも 1 つの誠実なノードがオプティミスティック ロールアップを完全に検証し、何か問題が発生した場合に誰かが不正証明を発行する確率を最大化するにはどうすればよいでしょうか?小規模なロールアップ (TPS が数百以下) の場合、これは重要な問題ではなく、利他主義に頼るだけで達成できますが、大規模なロールアップの場合は、インセンティブの問題を明確に検討する必要があります。
• 事前確認のセキュリティを最大限に高める: ユーザー エクスペリエンスを向上させるために、多くのロールアップでは「事前確認」の概念が提供されます。つまり、トランザクションが完了した後、ソーターはすぐに約束を提供します。つまり、特定のトランザクションは次のようになります。次のバッチに含まれます。仕分け者が違反した場合、その預金は破棄されます。しかし、ソーターは多くのユーザーに対して同時に多くのコミットメントを行う可能性があるため、このスキームのセキュリティは経済レベルでは制限されています。この仕組みは改善できるのでしょうか？

要約する

不在のソーターに対する応答性の向上: ロールアップのソーターが突然オフラインになった場合、別のロールアップに迅速かつ低コストで一括終了するか、ソーターを交換することによって、この状況からできるだけ早くかつ安価に回復する方法。素早い対応でとても貴重です。効率的な ZK-VM: ZK-SNARK プルーフを生成して、ユニバーサル EVM コード (または既存のコントラクトをコンパイルできる別の VM) が正しく実行され、明確な結果が得られたことを証明します。