ロールアップはイーサリアム コミュニティで大流行しており、近い将来、イーサリアム が整っています。 の重要なスケーラビリティ ソリューションとなる態勢 しかし、このテクノロジーとは正確には何なのか、何を期待できるのか、どのように使用できるのでしょうか?この投稿では、これらの重要な質問のいくつかに答えようとします。 背景: レイヤー 1 およびレイヤー 2 のスケーリングとは 。 ブロックチェーン エコシステムをスケーリングするには 2 つの方法があります。まず、ブロックチェーン自体のトランザクション容量を大きくすることができます この手法の主な課題は、「より大きなブロック」を持つブロックチェーンは本質的に検証が難しく、より集中化される可能性が高いことです. このようなリスクを回避するために、開発者はクライアント ソフトウェアの効率を高めるか、より持続可能な方法 手法を使用して、チェーンの構築と検証の作業を多数のノードに分割できるようにすることができます。 は、現在、このイーサリアムへのアップグレードを構築しています。 として、シャーディングなどの 「eth2」として知られる取り組み 。 アクティビティをブロックチェーンに直接配置する代わりに、ユーザーは「レイヤー 2」プロトコルでオフチェーンでアクティビティの大部分を実行します。 次に、ブロックチェーンの使用方法を変更できます すべての オンチェーンのスマート コントラクトには、入金と出金の処理と、オフチェーンで発生するすべてがルールに従っていることの証明の検証という 2 つのタスクしかありません。 これらの証明を行う方法は複数ありますが、オンチェーンでの証明の検証は、元の計算をオフチェーンで行うよりもはるかに安価であるという特性を共有しています。 状態チャンネル vs プラズマ vs ロールアップ レイヤ 2 スケーリングの 3 つの主なタイプは、 、 、およびロールアップです。 状態チャネル プラズマ これらは 3 つの異なるパラダイムであり、異なる長所と短所があります。この時点で、すべてのレイヤー 2 スケーリングがほぼこれらの 3 つのカテゴリに分類されるとかなり確信しています (ただし、端には命名の論争が存在します。たとえば、 を参照してください)。 「validium」 チャネルはどのように機能しますか? 参照: および https://www.jeffcoleman.ca/state-channels statechannels.org Alice が Bob にインターネット接続を提供する代わりに、Bob が 1 メガバイトあたり 0.001 ドルを支払うと想像してください。 Alice と Bob は、支払いごとに取引を行う代わりに、次のレイヤー 2 スキームを使用します。 まず、ボブは 1 ドル (または ETH またはステーブルコイン相当額) をスマート コントラクトに入れます。 Alice への最初の支払いを行うために、Bob は「0.001 ドル」とだけ書かれた「チケット」(オフチェーン メッセージ) に署名し、それを Alice に送信します。 2 回目の支払いを行うために、ボブは「0.002 ドル」と書かれた別のチケットに署名し、それをアリスに送信します。などなど、必要に応じて多くの支払いが行われます。 Alice と Bob がトランザクションを完了すると、Alice は自分自身からの別の署名でラップされた、最も価値の高いチケットをチェーンに公開できます。 スマート コントラクトは Alice と Bob の署名を検証し、Alice に Bob のチケットの金額を支払い、残りを Bob に返します。 アリスが (悪意または技術的な障害により) チャネルを閉鎖することを望まない場合、ボブは撤回期間 (例: 7 日間) を開始できます。アリスがその時間内にチケットを提供しない場合、ボブはすべてのお金を取り戻します。 この手法は強力です。双方向の支払い、スマート コントラクトの関係 (アリスとボブがチャネル内で金融契約を結ぶなど)、構成 (アリスとボブがチャネルを開いており、ボブとチャーリーもチャネルを開いている場合) を処理するように調整できます。 Alice は信頼せずに Charlie とやり取りできます)。 しかし、チャンネルができることには限界があります。 チャネルを使用して、まだ参加していない人にオフチェーンで資金を送ることはできません。チャネルは、明確な論理的所有者を持たないオブジェクト (Uniswap など) を表すために使用することはできません。 また、チャネルは、特に単純な定期支払いよりも複雑なことを行うために使用される場合、多額の資本をロックする必要があります。 プラズマはどのように機能しますか? 以下も参照してください: および 。 元の Plasma paper Plasma Cash アセットをデポジットするために、ユーザーはそれをプラズマ チェーンを管理するスマート コントラクトに送信します。 Plasma チェーンは、そのアセットに新しい一意の ID (例: 537) を割り当てます。 各 Plasma チェーンには があります (これは、集中化されたアクター、マルチシグ、または PoS や DPoS のようなより複雑なものである可能性があります)。間隔ごとに (これは 15 秒、1 時間、またはその間の任意の時間)、オペレーターは、オフチェーンで受け取ったすべての Plasma トランザクションからなる「バッチ」を生成します。 オペレーター 彼らはマークル ツリーを生成します。ツリー内の各インデックス には、資産 ID を転送するトランザクションが存在する場合、そのようなトランザクションが存在し、そうでない場合、リーフはゼロになります。彼らは、このツリーのマークル ルートをチェーンに公開します。 X X また、各インデックス のマークル ブランチをそのアセットの現在の所有者に送信します。資産を引き出すには、ユーザーは資産を送信した最新のトランザクションのマークル ブランチを発行します。 X コントラクトはチャレンジ期間を開始します。この期間中、誰でも他の Merkle ブランチを使用して、(i) 送信者が送信時にアセットを所有していなかったこと、または (ii) アセットを送信したことを証明することにより、終了を無効にすることができます。後の時点で他の誰かに。 (例) 7 日間、出口が不正であると誰も証明しなかった場合、ユーザーは資産を引き出すことができます。 Plasma はチャネルよりも強力な特性を提供します。システムの一部ではない参加者に資産を送信でき、資本要件ははるかに低くなります。 ただし、コストがかかります。「通常の操作」では、チャネルはチェーンにデータを送信する必要はありませんが、Plasma では各チェーンが定期的に 1 つのハッシュを発行する必要があります。 さらに、Plasma 転送は即時ではありません。間隔が終了し、ブロックが公開されるまで待つ必要があります。 さらに、Plasma とチャネルには共通の重要な弱点があります。それらが安全である理由の背後にあるゲーム理論は、両方のシステムによって制御される各オブジェクトには何らかの論理的な「所有者」がいるという考えに依存しています。 その所有者が自分の資産を気にしない場合、その資産が関係する「無効な」結果が生じる可能性があります。これは多くのアプリケーションでは問題ありませんが、他の多くのアプリケーション (Uniswap など) にとっては問題です。 所有者の同意なしにオブジェクトの状態を変更できるシステム (たとえば、誰かの同意なしに残高を ことができるアカウント ベースのシステム) でさえ、Plasma ではうまく機能しません。 増やす これはすべて、現実的なプラズマまたはチャネルの展開には大量の「アプリケーション固有の推論」が必要であることを意味し、完全なイーサリアム環境 (または「EVM」) をシミュレートするだけのプラズマまたはチャネル システムを作成することはできません。 .この問題を回避するには、... ロールアップを使用します。 ロールアップ 楽観的なロールアップと も参照してください。 ZK ロール アップに関する EthHub プラズマとチャネルは、データ 計算の両方をオフチェーンに移動しようとするという点で、「完全な」レイヤー 2 スキームです。 と ただし、 は、すべてのアプリケーションに対してこれを安全に行うことは不可能であることを意味します。 Plasma とチャネルは、所有者の明示的な概念に依存することでこれを回避しますが、これにより完全に一般化することができなくなります。 データの可用性に関する基本的なゲーム理論の問題 一方、ロールアップは「ハイブリッド」レイヤー 2 スキームです。 ます。 ロールアップは、計算 (および状態ストレージ) をオフチェーンに移動しますが、トランザクションごとの一部のデータをオンチェーンに保持し 効率を改善するために、彼らは可能な限り に、たくさんの派手な圧縮トリックを使用します。 データを計算に置き換えるため その結果、スケーラビリティは基盤となるブロックチェーンのデータ帯域幅によって依然として制限されるシステムになりますが、非常に好ましい比率で: イーサリアム ベースレイヤーの ERC20 トークン転送には ~45000 ガスのコストがかかりますが、ロールアップでの ERC20 トークン転送には 16 ガスが必要です。バイト単位のオンチェーン スペースと 300 ガス未満のコスト。 データがチェーン上にあるという事実が重要です (注: IPFS は特定のデータが利用可能かどうか を提供し ため、データを「IPFS 上に置く」ことはできません。データはブロックチェーン上に移動する があります)。 についてコンセンサス ない 必要 データをチェーンに入れ、その事実についてコンセンサスを得ることで、誰でも必要に応じてロールアップ内のすべての操作をローカルで処理できるようになり、詐欺を検出したり、引き出しを開始したり、個人的にトランザクション バッチの生成を開始したりできるようになります。 データの可用性の問題がないということは、悪意のあるオペレーターまたはオフラインのオペレーターが害を及ぼす可能性が (たとえば、1 週間の遅延を引き起こすことはできません)、バッチを公開する権利を持っている人にはるかに大きな設計スペースが開かれ、ロールアップが非常に簡単になることを意味します。について推論する。 さらに少なくなり そして最も重要なことは、データの可用性の問題がないということは、資産を所有者にマッピングする必要がなくなったことを意味し、イーサリアム コミュニティが以前の形式のレイヤー 2 スケーリングよりもロールアップに非常に興奮している主な理由につながります。 。 ロールアップは完全に汎用で、ロールアップ内で EVM を実行することもできるため、新しいコードをほとんど書く必要なく、既存の Ethereum アプリケーションをロールアップに移行できます では、ロールアップはどの程度正確に機能するのでしょうか? を維持するチェーン上のスマート コントラクトがあります: ロールアップのステートのマークル ルート (つまり、ロールアップの「内部」にある口座残高、コントラクト コードなど)。 ステート ルート 誰でも、前の状態ルートと新しい状態ルート (トランザクション処理 のマークル ルート) と共に、高度に圧縮された形式のトランザクションのコレクションである を発行できます。 後 バッチ コントラクトは、バッチ内の以前の状態ルートが現在の状態ルートと一致することを確認します。存在する場合は、状態ルートを新しい状態ルートに切り替えます。 入金と出金をサポートするために、入力または出力がロールアップ状態の「外部」であるトランザクションを持つ機能を追加します。 バッチに外部からの入力がある場合、バッチを送信するトランザクションは、これらのアセットもロールアップ コントラクトに転送する必要があります。バッチに外部への出力がある場合、バッチの処理時にスマート コントラクトがそれらの引き出しを開始します。 以上です！ 1 つの主要な詳細を除いて: バッチ内のポストステート ルートが正しいことを確認するにはどうすればよいでしょうか? 誰かがポストステート ルートを含むバッチを結果なしで送信できる場合、ロールアップ内のすべてのコインを自分自身に転送することができます。 問題に対するソリューションには 2 つの非常に異なるファミリーがあり、これら 2 つのソリューション ファミリーが 2 つのタイプのロールアップにつながるため、この質問は重要です。 楽観的ロールアップと ZK ロールアップ ロールアップには次の 2 種類があります。 を使用する ロールアップ : ロールアップ コントラクトは、状態ルートの全履歴と各バッチのハッシュを追跡します。 不正証明 楽観的 あるバッチの事後状態のルートが正しくないことを誰かが発見した場合、そのバッチが正しく計算されなかったことを証明する証明をチェーンに公開できます。 コントラクトはプルーフを検証し、そのバッチとそれ以降のすべてのバッチを元に戻します。 を使用する : すべてのバッチには、ZK-SNARK と呼ばれる暗号証明が含まれています (たとえば、 プロトコルを使用)。これは、状態後のルートがバッチを実行した正しい結果であることを証明します。 有効性証明 ZK ロールアップ PLONK 計算がどれほど大きくても、証明はオンチェーンで非常に迅速に検証できます。 ロールアップの 2 つのフレーバーの間には複雑なトレードオフがあります。 一般的に、私自身の見解では、短期的には、楽観的なロールアップが汎用 EVM 計算に勝つ可能性が高く、ZK ロールアップが単純な支払い、交換、およびその他のアプリケーション固有のユースケースに勝つ可能性が高いと考えています。 ZK-SNARK 技術が向上するにつれて、中長期的な ZK ロールアップはすべてのユースケースで勝ちます。 不正証明の構造 楽観的ロールアップの安全性は、誰かが無効なバッチをロールアップに公開した場合、チェーンに追いついて不正を検出した他の が不正証明を公開し、そのバッチが無効であることをコントラクトに証明できるという考えに依存しています。元に戻す必要があります。 誰か バッチが無効であると主張する詐欺証明には、緑色のデータが含まれます: バッチ自体 (チェーンに保存されたハッシュと照合することができます) と、読み取られた特定のアカウントだけを証明するために必要なマークル ツリーの部分と/またはバッチによって変更されます。 ツリー内の黄色のノードは、緑色のノードから再構築できるため、指定する必要はありません。 このデータは、バッチを実行してポストステート ルートを計算するのに十分です (これは、 が個々のブロックを検証する方法とまったく同じであることに注意してください)。 ステートレス クライアント バッチ内で計算された状態後のルートと提供された状態後のルートが同じでない場合、そのバッチは不正です。 バッチが ことを示す不正証明を作成できることが保証されています。 正しく構築されておらず、以前のすべてのバッチが正しく構築されていた場合、バッチが正しく構築されなかった 以前のバッチに関する主張に注意してください。ロールアップに発行された無効なバッチが複数ある場合は、最も古いバッチが無効であることを証明することをお勧めします。もちろん、バッチが正しく作成された場合、バッチが無効であることを示す不正証明を作成することは決してできないことも保証されています。 圧縮のしくみ 簡単な Ethereum トランザクション (ETH を送信するため) には、約 110 バイトかかります。ただし、ロールアップでの ETH 転送には、最大 12 バイトしかかかりません。 これの一部は、単に優れたエンコーディングです。イーサリアムの RLP は、各値の長さで値ごとに 1 バイトを無駄にします。しかし、進行中の非常に巧妙な圧縮トリックもいくつかあります。 : このパラメーターの目的は、リプレイを防ぐことです。アカウントの現在のナンスが 5 の場合、そのアカウントからの次のトランザクションのナンスは 5 でなければなりませんが、トランザクションが処理されると、アカウントのナンスは 6 に増加するため、トランザクションを再度処理することはできません。 Nonce ロールアップでは、nonce を完全に省略できます。これは、前の状態から nonce を回復するだけだからです。誰かが以前のノンスでトランザクションをリプレイしようとすると、署名は新しいより高いノンスを含むデータに対してチェックされるため、署名の検証に失敗します。 : ユーザーがガスプライスの固定範囲で支払うことを許可できます。 16 の連続する 2 のべき乗の選択。 ガスプライス あるいは、バッチごとに一定の料金レベルを設定するか、ガス支払いを完全にロールアップ プロトコルの外に移動し、取引者がチャネルを通じて含めるバッチ作成者に支払うようにすることもできます。 : 同様に、全ガスを 2 の連続するべき乗の選択に制限することができます。あるいは、バッチ レベルでのみガス制限を設定することもできます。 ガス : 20 バイトのアドレスを に置き換えることができます (たとえば、アドレスがツリーに追加された 4527 番目のアドレスである場合、インデックス 4527 を使用してそれを参照します。 To インデックス アドレスへのインデックスのマッピングを格納するために、状態にサブツリーを追加します)。 : 科学表記法で値を格納できます。ほとんどの場合、転送には 1 ～ 3 桁の有効数字しか必要ありません。 値 : を使用できます。これにより、多くの署名を 1 つの ~32 ～ 96 バイト (プロトコルによって異なります) の署名に集約できます。 署名 BLS 集約署名 この署名は、メッセージと送信者のセット全体に対して一度にチェックできます。 表の ~0.5 は、1 つのブロックで検証できる集計で組み合わせることができる署名の数に制限があるという事実を表しており、大きなバッチでは ~100 トランザクションごとに 1 つの署名が必要になります。 ZK ロールアップに固有の重要な圧縮トリックの 1 つは、トランザクションの一部が検証のみに使用され、状態更新の計算に関連しない場合、その部分をオフチェーンのままにしておくことができるということです。 これは、楽観的なロールアップでは実行できません。なぜなら、ZK ロールアップでは、バッチの正確性を証明する SNARK が、任意のデータがすでに検証に必要なものが提供されました。 これの重要な例は、プライバシーを保護するロールアップです。楽観的なロールアップでは、各トランザクションでプライバシーに使用される最大 500 バイトの ZK-SNARK がチェーンに入る必要がありますが、ZK ロールアップでは、バッチ全体をカバーする ZK-SNARK はすでに何も残していません。 「内側」の ZK-SNARK が有効であることを疑います。 これらの圧縮のトリックは、ロールアップのスケーラビリティの鍵です。それらがなければ、ロールアップはおそらくベース チェーンのスケーラビリティを最大 10 倍改善するだけです (ただし、単純なロールアップでも強力な特定の計算負荷の高いアプリケーションがいくつかあります) が、圧縮のトリックを使用すると、スケーリング ファクターはほぼ 100 倍を超える可能性があります。すべてのアプリケーション。 誰がバッチを送信できますか? 誰が楽観的または ZK ロールアップでバッチを提出できるかについて、多くの考え方があります。 一般に、バッチを送信できるようにするためには、ユーザーは多額の預金をしなければならないことに誰もが同意します。そのユーザーが不正なバッチ (たとえば、無効な状態のルートを含む) を送信した場合、そのデポジットは一部が焼失し、一部が不正証明者への報酬として与えられます。しかし、それを超えて、多くの可能性があります。 : 誰でもいつでもバッチを送信できます。これは最も単純なアプローチですが、いくつかの重要な欠点があります。 完全無秩序 特に、複数の参加者がバッチを生成して並行して送信しようとするリスクがあり、それらのバッチの 1 つだけを正常に含めることができます。 これは、プルーフを生成する際の大量の無駄な労力および/またはチェーンへのバッチの発行における無駄なガスにつながります。 : 単一のアクター、 があり、バッチを送信できます (引き出しの場合は例外です: 通常の手法では、ユーザーは最初に引き出しリクエストを送信し、シーケンサーが次の引き出しを処理しない場合バッチの場合、ユーザーは単一操作のバッチを自分で送信できます)。 集中化されたシーケンサー シーケンサー これは最も「効率的」ですが、ライブ性は中心的なアクターに依存しています。 : 誰が翌日のシーケンサーになる権利を持っているかを決定するために、オークションが (たとえば毎日) 開催されます。 シーケンサー オークション この手法には、資金を調達できるという利点があります。ロールアップによって制御される DAO ( を参照) MEV オークション : 誰でも ETH (またはロールアップ独自のプロトコル トークン) をロールアップ コントラクトに入金でき、各バッチのシーケンサーは入金者の 1 人からランダムに選択され、選択される確率は金額に比例します。預けた。 PoS セットからのランダム選択 この手法の主な欠点は、大量の不必要な資本ロックアップにつながることです。 : オークションで選択された単一のシーケンサーがありますが、パフォーマンスが悪い場合、トークン所有者は投票してそれらを追い出し、新しいオークションを開催してそれらを置き換えることができます. DPoS投票 分割バッチ処理とステート ルート プロビジョニング 現在開発中のロールアップの一部は、レイヤー 2 トランザクションのバッチを送信するアクションと状態ルートを送信するアクションが別々に実行される「分割バッチ」パラダイムを使用しています。 これにはいくつかの重要な利点があります。 他のバッチが最初に含まれたために一部のバッチが無効になることを心配することなく、検閲耐性を向上させるために、多くのシーケンサーが並行してバッチを発行できるようにすることができます。 状態ルートが不正である場合、バッチ全体を元に戻す必要はありません。状態ルートだけを元に戻し、誰かが同じバッチに新しい状態ルートを提供するのを待つことができます。 これにより、トランザクション送信者は、トランザクションが元に戻されないことをより確実に保証できます。 全体として、効率性、シンプルさ、耐検閲性、およびその他の目標を含む複雑なトレードオフの間でバランスをとろうとする、かなり複雑なテクニックの動物園があります。 これらのアイデアのどの組み合わせが最も効果的かを判断するにはまだ時期尚早です。時が教えてくれる。 ロールアップはどのくらいのスケーリングを提供しますか? 既存の Ethereum チェーンでは、ガスの上限は 1250 万で、トランザクションのデータ 1 バイトあたり 16 ガスの費用がかかります。 これは、ブロックに 1 つのバッチしか含まれていない場合 (ZK ロールアップが使用され、証明検証に 500k ガスが費やされるとします)、そのバッチは (1200 万 / 16) = 750,000 バイトのデータを持つことができることを意味します。 上に示したように、ETH 転送のロールアップには、ユーザー操作ごとに 12 バイトしか必要ありません。つまり、バッチには最大 62,500 のトランザクションを含めることができます。 の平均ブロック時間で、これは ~4807 TPS に変換されます (1250 万 / 21000 / 13 ~= 45 TPS であるイーサリアム自体での ETH の直接転送と比較して)。 13 秒 他の使用例のチャートを次に示します。 最大スケーラビリティ ゲインは、(L1 ガス コスト) / (ロールアップのバイト数 * 16) * 1,200 万 / 1,250 万として計算されます。 さて、これらの数字はいくつかの理由で過度に楽観的であることを心に留めておく価値があります。最も重要なことは、少なくとも複数のロールアップが存在するため、ブロックに 1 つのバッチだけが含まれることはほとんどないということです。 第二に、預金と引き出しは引き続き存在します。第 3 に は使用量が少なくなるため、固定費が支配的になります。しかし、これらの要因を考慮しても、100 倍を超えるスケーラビリティの向上が標準になると予想されます。 、短期的に では、1000 ～ 4000 TPS を超えたい場合はどうすればよいでしょうか (特定のユース ケースによって異なります)。ここで、 の出番です。 eth2 データ シャーディング シャーディングの提案により、12 秒ごとに 16 MB のスペースが開かれ、そこに任意のデータを入力できます。システムは、そのデータの可用性に関するコンセンサスを保証します。このデータ領域は、ロールアップで使用できます。 この最大 1398k バイト/秒は、既存の Ethereum チェーンの最大 60 kB/秒の 23 倍の改善であり、長期的には、データ容量はさらに増加すると予想されます。 したがって、eth2 シャード データを使用するロールアップは、最大 100,000 TPS をまとめて処理でき、将来的にはさらに多くを処理できます。 ロールアップでまだ完全に解決されていない課題は何ですか? ロールアップの基本的な概念は現在十分に理解されていますが、それらが基本的に実現可能で安全であることは確信しており、複数のロールアップがすでにメインネットにデプロイされていますが、まだ十分に調査されていないロールアップ設計の多くの領域があります.また、イーサリアム エコシステムの大部分を完全にロールアップしてスケーラビリティを活用するには、かなりの数の課題があります。 主な課題には次のようなものがあります。 - ロールアップを使用するアプリケーションは多くなく、ロールアップはユーザーにとってなじみがなく、ロールアップの統合を開始したウォレットはほとんどありません。 ユーザーとエコシステムのオンボーディング 商人や慈善団体は、まだ支払いを受け付けていません。 - ベース レイヤーを通過する費用を負担することなく、アセットとデータ (オラクルの出力など) をあるロールアップから別のロールアップに効率的に移動します。 クロス ロールアップ トランザクション - 少なくとも 1 つの正直なノードが楽観的なロールアップを実際に完全に検証して、何か問題が発生した場合に詐欺の証拠を公開できるようにする方法は? 監査のインセンティブ 小規模なロールアップ (最大数百 TPS) の場合、これは重大な問題ではなく、単純に利他主義に頼ることができますが、大規模なロールアップの場合は、これに関するより明確な理由が必要です。 - 状態更新関連データをチェーン上に配置するテクニックはありますが、その ではありません。 プラズマとロールアップの間の設計空間を探る 一部の すべて - 多くのロールアップは、より高速な UX のために「事前確認」の概念を提供します。この場合、シーケンサーはトランザクションが次のバッチに含まれるという約束を即座に提供し、シーケンサーの預金は、彼らが彼らの約束を破ると破棄されます。語。 事前確認のセキュリティを最大化 しかし、非常に多くの関係者に同時に多くの約束をする可能性があるため、このスキームの経済的安全性は限られています。このメカニズムを改善することはできますか？ - ロールアップのシーケンサーが突然オフラインになった場合、その状況から最大限に迅速かつ安価に回復することは価値があります。迅速かつ安価に別のロールアップに一括終了するか、シーケンサーを交換します。 存在しないシーケンサーへの応答速度の向上 - 汎用 EVM コード (または既存のスマート コントラクトをコンパイルできる別の VM) が正しく実行され、所定の結果が得られたという ZK-SNARK 証明を生成します。 効率的な ZK-VM 結論 ロールアップは、強力な新しいレイヤー 2 スケーリング パラダイムであり、短期および中期の将来 (そしておそらく長期的にも) の Ethereum スケーリングの基礎となることが期待されています。 これまでのレイヤー 2 スケーリングの試みとは異なり、汎用の EVM コードをサポートできるため、既存のアプリケーションを簡単に移行できるため、イーサリアム コミュニティから大きな期待が寄せられています。 完全にオフチェーンに移行しようとするのではなく、トランザクションごとに少量のデータをオンチェーンに残します。 ロールアップには多くの種類があり、設計空間には多くの選択肢があります。不正証明を使用した楽観的なロールアップ、または有効性の証明 (別名 ZK-SNARK) を使用した ZK ロールアップを使用できます。 シーケンサー (トランザクション バッチをチェーンに公開できるユーザー) は、集中化されたアクター、自由参加のアクター、またはその間の他の多くの選択肢のいずれかになります。 ロールアップはまだ初期段階の技術であり、急速に開発が続けられていますが、それらは機能しており、一部 (特に 、 、 ) はすでに数か月間実行されています。今後数年間で、ロールアップ スペースからさらにエキサイティングな作品が出てくることを期待してください。 Loopring ZKSync DeversiFi
