V GodがEthereumのスケーラビリティソリューションRollupを理解する方法を紹介します

元のタイトル: ロールアップの不完全なガイド

オリジナル記事: VitalikButerin

元の翻訳: 0x33、BlockBeats

Rollup は Ethereum コミュニティで非常に人気があり、近い将来に Ethereum の重要なスケーラビリティ ソリューションとなるでしょう。しかし、このテクノロジーとは一体何なのか、何を期待できるのか、どのように使用するのか。この投稿では、これらの重要な質問のいくつかに答えてみたいと思います。

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

ブロックチェーンエコシステムを拡張する方法は2つあります。まず、ブロックチェーン自体のトランザクション容量を高めることができます。この技術の主な課題は、「より大きなブロック」を持つブロックチェーンは本質的に検証が難しく、より集中化される可能性があることです。このようなリスクを回避するために、開発者はクライアント ソフトウェアの効率を向上させるか、シャーディングなどのテクノロジをより持続的に使用して、チェーンの構築と検証の作業を複数のノードに分割することができます。ご存知のとおり、「ETH2.0」は現在、Ethereum へのアップグレードの構築に懸命に取り組んでいます。

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

ステート チャネル vs. プラズマ vs. ロールアップ

レイヤー 2 を拡張する主な方法は、ステート チャネル、プラズマ、ロールアップの 3 つです。これらは 3 つの異なるアプローチであり、それぞれに長所と短所がありますが、現時点では、すべてのレイヤー 2 拡張機能は、おおよそこれら 3 つのカテゴリに分類できると確信しています。 （ただし、「validium」などの命名については議論がある）。

ステート チャネルはどのように機能しますか?

こちらをクリックしてください: https://www.jeffcoleman.ca/state-channels および statechannels.org

アリスがボブにインターネット接続を提供し、その代わりにボブが 1 メガバイトあたり 0.001 ドルを支払うとします。アリスとボブは、支払いごとにトランザクションを実行する代わりに、次のレイヤー 2 スキームを使用します。

まず、ボブは 1 ドル (または ETH やステーブルコインに相当する金額) をスマート コントラクトに投入します。ボブはアリスへの最初の支払いを行うために、「$0.001」とだけ書かれた「チケット」（オフチェーン メッセージ）に署名し、それをアリスに送信します。 2 回目の支払いを行うには、ボブは「$0.002」と書かれた別の紙幣に署名し、それをアリスに送ります。などなど、必要な分だけお支払いください。アリスとボブが取引を完了すると、アリスは自分自身の別の署名を添えた最高額の紙幣をチェーンに公開できます。

スマート コントラクトは、アリスとボブの署名を検証し、ボブの約束手形の金額をアリスに支払い、残りをボブに返します。アリスがチャネルを閉じることを望まない場合（悪意または技術的な障害のため）、ボブは終了期間（例：7 日間）を開始できます。アリスがこの期間内に新しい紙幣を提供しない場合、ボブは全額返金されます。

このテクノロジーは強力です。双方向の支払い、スマート コントラクト関係 (例: アリスとボブがチャネル内で金融契約を作成する)、および構成 (アリスとボブがパブリック チャネルを持ち、ボブとチャーリーもパブリック チャネルを持っている場合、アリスはチャーリーと信頼せずに対話できます) を処理するように適応できます。

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

プラズマはどのように機能しますか?

オリジナルの Plasma 論文と Plasma Cash をご覧ください。

資産を預けるには、ユーザーはそれを Plasma チェーンを管理するスマート コントラクトに送信します。

Plasma チェーンは、アセットに一意の ID (537 など) を割り当てます。各 Plasma チェーンにはオペレーターが存在します (これは集中型のアクター、マルチシグ、または PoS や DPoS のようなより複雑なものになります)。オペレーターは、定期的に（15 秒、1 時間、またはその間の任意の間隔）、オフチェーンで受信したすべての Plasma トランザクションを含む「バッチ」を生成します。

これらは、ツリー内の各インデックス X にトランザクションがある場合は資産 ID X を転送するトランザクションが存在する Merkle ツリーを生成します。それ以外の場合はゼロになります。彼らはこの Merkle ルートをチェーン上に送信します。また、各インデックス X の Merkle ブランチをその資産の現在の所有者に送信します。資産を引き出すには、ユーザーは資産を送信した最新のトランザクションの Merkle ブランチを公開します。 Ludong からの注記: マークル ツリーは、中国語ではマークル ツリーまたはハッシュ ツリーと呼ばれます。暗号学およびコンピュータサイエンスでは、各リーフノードにデータブロックのハッシュのラベルが付けられ、リーフノード以外のノードには子ノードのラベルの暗号化されたハッシュのラベルが付けられるツリーデータ構造です。 Merkle Tree の明らかな利点は、データの一部を検証するために、ブランチを別々に (小さなツリーとして) 取り出すことができることです。これにより、多くのユースケースでハッシュ リストでは実現できない利便性と効率性が実現します。

契約はチャレンジ期間から始まり、その期間中は誰でも、(1) 送信者が送信時に資産を所有していなかった、または (2) 送信者が後日他の誰かに資産を送信したことを証明することにより、異なる Merkle ブランチを使用して終了を無効にしようと試みることができます。たとえば 7 日以内に引き出しが真実ではないことを証明する人がいない場合は、ユーザーは資金を引き出すことができます。

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

さらに、Plasma チャネルとステート チャネルには共通の弱点があります。なぜこれらは安全なのでしょうか?この背後にあるゲーム理論は、両方のシステムによって制御されるすべてのオブジェクトには何らかの論理的な「所有者」が存在するという考えに基づいています。その所有者が自分の資産を気にしていない場合、その資産に関連する「無効な」結果が生じる可能性があります。これは多くのアプリケーションでは受け入れられますが、他の多くのアプリケーション (例: Uniswap) では受け入れられません。資産オブジェクトの状態が所有者の同意なしに変更される可能性があるシステム (たとえば、誰かの同意なしに残高を増やすことができるアカウントベースのシステム) であっても、Plasma ではうまく機能しません。

つまり、現実的な Plasma または状態チャネルの展開では、多くの「アプリケーション固有の推論」が必要であり、Ethereum 環境全体 (または「EVM」) をシミュレートする Plasma またはチャネル システムを作成することは不可能です。

この問題を解決するには、ロールアップを検討します。

ロールアップ

詳細については、こちらをクリックしてください: 楽観的ロールアップと ZK ロールアップに関する EthHub。

Plasma チャネルとステート チャネルは、データと計算の両方をオフチェーンに移動しようとする完全なレイヤー 2 イニシアチブです。しかし、データの可用性に関する基本的なゲーム理論の問題により、すべてのアプリケーションでこれを安全に実行することは不可能です。プラズマとチャネルは、この問題を解決するために所有者の明確な概念に依存していますが、これが一般性を妨げています。一方、ロールアップは「ハイブリッド」レイヤー 2 ソリューションです。

Rollup は計算 (および状態ストレージ) をオフチェーンに移動しますが、各トランザクションに関する一部のデータはオンチェーンに保持します。効率を上げるために、さまざまな高度な圧縮トリックを使用し、可能な限りデータを計算に置き換えます。その結果、システムのスケーラビリティは依然として基盤となるブロックチェーンのデータ帯域幅によって制限されますが、その比率は非常に有利です。Ethereum の基盤となる ERC20 トークンの転送には約 45,000 ガスのコストがかかりますが、ロールアップで転送される ERC20 トークンは 16 バイトのオンチェーン スペースを占有し、コストは 300 ガス未満です。

データがオンチェーンであるという事実が重要です (注: データを「IPFS 上」に置くことは機能しません。IPFS は特定のデータが利用可能かどうかについて合意していないためです。データはブロックチェーン上にある必要があります)。データをオンチェーンに配置し、その事実について合意に達すると、誰でも必要に応じてロールアップ内のすべての操作をローカルで処理できるようになり、不正行為を検出したり、引き出しを開始したり、トランザクション バッチの生成を開始したりできるようになります。データの可用性の問題がないということは、悪意のあるオペレーターやオフラインのオペレーターがもたらす被害が少なくなることを意味します (例: 1 週間の遅延を引き起こすことはできません)。これにより、バッチを公開する権限を持つユーザーの設計スペースが広がり、集計の推論が容易になります。

最も重要なのは、データ可用性の問題がないということは、資産を所有者にマッピングする必要がなくなったことを意味します。これが、Ethereum コミュニティが以前の形式のレイヤー 2 スケーリングよりもロールアップに熱心な主な理由です。ロールアップは完全に汎用的であり、EVM もロールアップで実行できるため、既存の Ethereum アプリケーションをほとんど新しいコードを記述せずにロールアップに移行できます。

さて、ロールアップ作業はどれほど素晴らしいのでしょうか?

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

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

入金と出金をサポートするために、トランザクションの入力または出力がロールアップ状態を「超える」機能を追加しました。バッチに外部ソースからの入力がある場合、バッチを送信するトランザクションは、それらの資産もロールアップ コントラクトに転送する必要があります。バッチが外部に出力されている場合、スマート コントラクトはバッチを処理するときにフェッチを開始します。

つまり、ここでは重要な詳細が 1 つだけあります。バッチ内のポスト状態ルートが正しいことをどうやって確認するのでしょうか。誰かが、何の影響もなく任意のポスト状態ルートを含むバッチを送信できる場合、ロールアップ内のすべてのトークンを自分自身に転送できます。

この質問は、2 種類のロールアップにつながる 2 つの非常に異なるソリューション セットがあるため、重要です。

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

これら 2 種類のロールアップは、オプティミスティック ロールアップと ZK ロールアップです。

楽観的ロールアップでは、不正証明が使用されます。ロールアップ コントラクトは、状態ルートの全履歴と各バッチのハッシュを追跡します。バッチのポスト状態ルートが間違っていることを発見した人は、バッチが誤って計算されたことの証明をチェーンに公開できます。契約は証明を検証し、そのバッチとそれ以降のすべてのバッチを復元します。

有効性証明を使用した ZK ロールアップ: 各バッチには、状態ルートがバッチ実行の正しい結果であることを証明する ZK-SNARK (例: PLONK プロトコルを使用) と呼ばれる暗号化証明が含まれています。計算量がどれほど多くても、証明はオンチェーンで迅速に検証できます。

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

全体的に、短期的には、楽観的ロールアップが汎用 EVM 計算で勝利する可能性があり、ZKrollup は単純な支払いレイヤー、取引プラットフォーム、およびその他のアプリケーション固有のユースケースで優れていると予想されるというのが私の見解です。ただし、中長期的には、ZK-SNARK テクノロジーが向上するにつれて、ZK ロールアップがすべてのユースケースで勝利するでしょう。

不正行為の証拠を分析する

楽観的ロールアップのセキュリティは、誰かが無効なバッチをロールアップに投稿した場合、チェーンをたどって不正行為を検出した人は誰でも、バッチが無効であり元に戻す必要があることを契約に証明する不正行為の証明を投稿できるかどうかにかかっています。

バッチが無効であると主張する不正証明には、緑色のデータが含まれます。バッチ自体 (チェーン上に保存されているハッシュと照合可能) と、バッチが読み取りおよび/または変更した特定のアカウントを証明するためにのみ必要な Merkle ツリーの部分です。

黄色のツリーのノードは緑色のノードから再構築できるため、データを提供する必要はありません。このデータは、バッチ処理を実行し、ポスト状態ルートを計算するのに十分です (これは、ステートレス クライアントが単一のブロックを検証する方法とまったく同じであることに注意してください)。バッチで計算された事後状態ルートと提供された事後状態ルートが同じでない場合、バッチは不正です。

バッチが誤って構築され、以前のすべてのバッチが正しく構築されていた場合、バッチ構築が間違っていたことを示す不正証明を作成できることが保証されます。以前のバッチに関する記述に注意してください。ロールアップに複数の無効なバッチが公開されている場合は、最も古いバッチが無効であることを証明するように努めることをお勧めします。もちろん、バッチ プロセスが正しく構築されていれば、バッチ プロセスが無効であるという不正の証拠を作成することは決してできないはずです。

圧縮はどのように機能しますか?

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

これは、より高度なエンコーディングによるところが大きいです。Ethereum の RLP は、各値の長さに 1 バイトを無駄にしています。しかし、非常に巧妙な圧縮トリックもいくつかあります。

Nonce:リプレイを防止します。アカウントの現在の nonce が 5 の場合、そのアカウントの次のトランザクションには nonce 5 が必要ですが、トランザクションが処理されると、アカウントの nonce は 6 に増加されるため、そのトランザクションを再度処理することはできません。ロールアップでは、事前状態から nonce を復元するだけなので、nonce を完全に無視できます。誰かが以前の nonce を使用してトランザクションを再生しようとすると、署名は新しい、より高い nonce を含むデータと照合されるため、署名の検証は失敗します。

ガス価格: ユーザーが固定のガス価格範囲内（たとえば、2 の 16 乗）で支払うことを許可できます。あるいは、バッチごとに固定の手数料レベルを設定したり、ガス支払いをロールアップ プロトコルの外部に完全に移動して、トランザクション プロセッサがチャネルを通じてバッチ作成者に支払うようにすることもできます。

gas:同様に、ガスの総量を 2 の累乗として表すことができます。あるいは、バッチに対してのみガス制限を設定することもできます。

宛先: 20 バイトのアドレスの代わりにインデックスを使用できます。アドレスがツリーに追加された 4527 番目のアドレスである場合、そのアドレスを参照するにはインデックス 4527 を使用するだけです。インデックスとアドレスのマッピングを保存するために、状態にサブツリーを追加します。

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

署名: BLS 集約署名を使用できます。これにより、多数の署名を 1 つの約 32 〜 96 バイト (プロトコルによって異なります) の署名に集約できます。この署名は、メッセージと送信者のセット全体に対して一度に一括してチェックできます。表の ~0.5 は、署名は単一の不正証明で検証する必要があるため、集計に含めることができる署名の数に制限があることを示しています。

ZK ロールアップに特有の重要な圧縮トリックは、トランザクションの一部が検証にのみ使用され、状態更新の計算とは関係がない場合、その部分をオフチェーンのままにできることです。この楽観的なロールアップは不可能です。なぜなら、後で不正証明で確認する必要がある場合に備えて、このデータをチェーン上に含める必要があるからです。一方、ZK ロールアップでは、バッチの正しさを証明する SNARK が、検証に必要なデータを提供することがすでに証明されています。

重要な例として、プライバシーを保護する OLLPS 合計が挙げられます。楽観的なロールアップでは、各トランザクションのプライバシーのために約 500 バイトの ZK-SNARK をチェーン上に配置する必要がありますが、ZK ロールアップでは、バッチ全体をカバーする ZK-SNARK によって、「内部」ZK-SNARK が有効であることが疑いなく証明されます。

これらの圧縮トリックはロールアップのスケーラビリティの鍵となります。これらがなければ、ロールアップはベースチェーンのスケーラビリティを約 10 倍しか向上させられない可能性があります (ただし、単純なロールアップでも強力な計算コストの高いアプリケーションがいくつかあります)。一方、圧縮トリックを使用すると、ほぼすべてのアプリケーションで 100 倍を超えるスケーリング係数を実現できます。

バッチトランザクションをレビューのために送信できるのは誰ですか?

楽観的ロールアップまたは ZK ロールアップでトランザクションのバッチを送信できるユーザーについては、さまざまな意見があります。一般的に言えば、バッチを送信するには、ユーザーが多額のデポジットを送信する必要があることには誰もが同意します。ユーザーが不正なトランザクションバッチ（無効な状態ルートなど）を送信した場合、そのデポジットの一部は焼却され、一部は不正証明者への報酬として支払われます。しかし、このアプローチ以外にも多くの可能性があります。

完全に無秩序なアプローチ:誰でもいつでもトランザクションのバッチを送信できます。これは最も単純なアプローチですが、いくつか重大な欠点があります。特に、複数の参加者がトランザクションのバッチを生成して同時に送信しようとすると、これらのバッチのうち 1 つだけが正常に処理されるというリスクがあります。その結果、証明の生成に多くのエネルギーが浪費され、また、チェーン上にトランザクションのバッチを配置する必要があるため、ガスも浪費されます。

集中型シーケンサー:参加者は 1 人だけです (シーケンサー)。トランザクションのバッチを送信できます (引き出しを除く: 通常の手法では、ユーザーは最初に引き出しリクエストを送信し、ソーターが次のバッチで引き出しリクエストを処理しない場合は、ユーザーが自分で処理するための単一操作のバッチを送信できます)。これは最も「効率的」ですが、実行を継続するには集中型のアクターに依存します。

シーケンサーオークション:オークションを開催して、誰がシーケンサーになる権利を持つかを決定します (たとえば、翌日)。この技術の利点は、調達した資金を、例えばロールアップによって制御されるDAOによって分配できることです（MEVオークションを参照）。

PoS セットからのランダム選択:誰でも ETH (またはロールアップ独自のプロトコル トークン) をロールアップ コントラクトに預けることができ、各バッチのソーターは預けた金額に比例して、預けた人からランダムに選択されます。この手法の主な欠点は、多くの不必要な資本のロックアップにつながる可能性があることです。

DPoS投票:オークションで選ばれた単一のソーターが存在します。しかし、そのソーターのパフォーマンスが低かった場合、トークン保有者は投票でそのソーターを追い出し、新しいオークションを開催してそのソーターを置き換えることができます。

償却バッチ処理と状態ルートプロビジョニング

現在開発中のロールアップの中には、「分割バッチ処理」アプローチを採用しているものがあり、レイヤー 2 トランザクションのバッチを送信する操作が、状態ルートを送信する操作とは別に実行されます。このアプローチにはいくつかの重要な利点があります。

他のバッチが最初に含まれたために一部のバッチが無効になることを心配することなく、多くの発注者がトランザクションのバッチを並行して公開できるようにすることで、検閲耐性を高めることができます。

状態ルートが不正な場合は、バッチ全体を元に戻す必要はなく、状態ルートを元に戻して、誰かが同じバッチの新しい状態ルートを提供するのを待つだけで済みます。これにより、トランザクションの送信者は、トランザクションが元に戻されないという確信をより強く持つことができます。

つまり、全体として、効率性、シンプルさ、検閲耐性、その他の目標を含む複雑なトレードオフのバランスを取ろうとする、かなり複雑な技術環境が存在します。どの組み合わせが最適かを言うのは時期尚早です。時が経てば分かるだろう。

ロールアップによってどの程度のスケーラビリティが得られますか?

既存のイーサリアム チェーンでは、ガス制限は 1,250 万で、トランザクション内のデータ 1 バイトごとに 16 ガスかかります。つまり、ブロックに 1 つのバッチのみが含まれている場合 (ZK ロールアップが使用され、証明の検証に 50 万ガスが費やされているとします)、そのバッチは (1200 万 / 16) = 75 万バイトのデータになります。

上記のように、ETH 転送の概要にはユーザー操作ごとに 12 バイトしか必要ありません。つまり、バッチには最大 62,500 件のトランザクションを含めることができます。平均ブロック時間が 13 秒の場合、これは約 4,807 TPS に相当します (比較すると、Ethereum 自体での ETH 直接転送は 1250 万 / 21,000 / 13 ~= 45 TPS になります)。

その他の使用例は次のとおりです。

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

さて、これらの数字はいくつかの理由から過度に楽観的であることを覚えておく価値があります。最も重要なことは、ブロックには 1 つのバッチだけが含まれることはほとんどなく、少なくとも複数のロールアップが含まれることです。第二に、入金と出金は常に発生し続けます。 3 つ目は、短期的には利用率が低いため、固定費が大部分を占めるということです。しかし、これらの要素を考慮しても、100 倍以上のスケーラビリティが標準になると予想されます。

さて、1000〜4000 TPS を超えたい場合はどうすればよいでしょうか (具体的なユースケースによって異なります)?ここで、eth2 データ シャーディングが役立ちます。シャーディング スキームでは、12 秒ごとに 16 MB のスペースが確保され、そこに任意のデータを格納できます。また、システムはデータの可用性に関するコンセンサスを保証します。このデータ スペースはロールアップに使用できます。この約 1398k バイト/秒は、既存の Ethereum チェーンの約 60kb/秒の 23 倍の改善であり、長期的にはデータ容量がさらに増加すると予想されます。したがって、eth2 シャード データを使用したロールアップは最大 100k TPS を処理でき、将来的にはさらに処理能力が高まります。

ロールアップにおいて、まだ完全に解決されていない課題は何ですか?

ロールアップは今では理解しやすい基本概念であり、複数のロールアップ ソリューションがすでにメインネットに導入されており、本質的に実行可能で安全であると確信していますが、ロールアップ設計にはまだ十分に開発されていない領域が多くあり、スケーラビリティを活用するために Ethereum エコシステムの大部分をロールアップに完全に移行するには依然として大きな課題が残っています。

主な課題は次のとおりです。

ユーザーとエコシステムの適応:ロールアップを使用するアプリケーションはほとんどなく、ユーザーもロールアップに慣れておらず、ロールアップの統合を開始したウォレットもほとんどありません。商店や慈善団体はまだこの支払い方法を受け入れていません。

クロスロールアップトランザクション: ベースレイヤーを経由せずに、資産とデータを (Oracle 出力などを介して) あるロールアップから別のロールアップに効率的に移動します。

監査インセンティブ:何か問題が発生した場合に不正の証明を発行できるように、少なくとも 1 つの正直なノードが実際に楽観的なロールアップを完全に検証する確率を最大化するにはどうすればよいでしょうか。小規模なロールアップ (最大数百 TPS) の場合、これは重大な問題ではなく、単に利他主義に頼ることができますが、大規模なロールアップの場合は、より明確な推論が必要になります。

Plasma と Rollup 間の設計空間の調査:状態の更新に関連するデータの一部 (すべてではない) をオンチェーンで実行できる技術はありますか? また、そこからどのような有用な結論を導き出すことができますか?

事前確認の安全性を最大化:多くのロールアップでは、ユーザー エクスペリエンスを高速化するために「事前確認」の概念が採用されています。事前確認では、ソーターがトランザクションを次のバッチに含めることを即座に約束し、約束を破った場合はソーターの預金が破棄されます。しかし、この計画の経済的安全性は、多くの参加者に対して同時に多くのコミットメントを行うことが可能であるため、限られています。このメカニズムは改善できるでしょうか?

不在のソーターへの応答性の向上:ロールアップのソーターが突然オフラインになった場合、別のロールアップに一括して迅速かつ安価に退出するか、ソーターを迅速に交換することによって、できるだけ早くかつ安価にソーターを復旧することが重要です。

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

結論は

Rollup は、短期および中期的 (そしておそらく長期的に) に Ethereum スケーリングの基礎となることが期待される、強力な新しいレイヤー 2 スケーリング パラダイムです。これにイーサリアム コミュニティから大きな関心が寄せられており、以前のレイヤー 2 拡張の試みとは異なり、汎用 EVM コードをサポートできるため、既存のアプリケーションを簡単に移行できます。これを実現するために、彼らは重要な妥協案を採用しました。完全にオフチェーン化するのではなく、各トランザクションに関する少量のデータをオンチェーンに残すというものです。

ロールアップには多くの種類があり、設計分野には多くのオプションがあります。たとえば、不正証明を楽観的ロールアップで使用したり、有効性証明を ZK ロールアップ (ZK-SNARK とも呼ばれます) で使用したりします。シーケンサー (トランザクションのバッチをチェーンに公開できるユーザー) は、集中型アクター、フリー アクター、またはその間のさまざまなオプションのいずれかになります。ロールアップはまだ初期の技術であり、開発が急速に進行中ですが、機能しており、そのうちのいくつか (特に Loopring、ZKSync、DeversiFi) は数か月間稼働しています。今後数年間、Rollup 分野ではよりエキサイティングな取り組みが行われるでしょう。