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

ECN以太坊中国

特邀专栏作者

2021-01-05 21:37 (UTC+8)

この記事は約9121文字で、全文を読むには約14分かかります

Vitalik は、さまざまな第 2 層拡張ソリューションの簡単な分析「Optimistic rollup vs. ZK rollup?」を公開しました。

AI要約

Vitalik は、さまざまな第 2 層拡張ソリューションの簡単な分析「Optimistic rollup vs. ZK rollup?」を公開しました。

出典 | vitaik.ca

著者 | ヴィタリック・ブテリン

Rollups ソリューションはイーサリアムコミュニティで大流行しており、将来的にはイーサリアムの主要なスケーリングソリューションになることが期待されています。しかし、そのテクノロジーとは具体的にはどのようなものなのでしょうか？それは私たちに何をもたらしてくれるでしょうか？このテクノロジーをどのように活用するのでしょうか?この記事では、これらの重要な質問のいくつかに答えていきます。

最初のレベルのタイトル

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

ブロックチェーンを拡張するには 2 つの方法があります。まず、ブロックチェーン自体のトランザクション容量を増やすことができます。このテクノロジーの主な課題は、ブロックサイズが大きくなるにつれて、ブロックチェーンの検証がますます困難になり、集中化の度合いがますます高くなるということです。このようなリスクを回避するために、開発者はクライアントソフトウェアの効率を向上させることができます。または、別のより持続可能な方法を選択します。シャーディングなどのテクノロジーを使用して、ブロックチェーン上のブロックの構築と検証作業を多くのノードに分散できるようにします (このテクノロジーは Eth2 アップグレードでイーサリアムに導入されます)。

状態チャネル 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」で別のチケットに署名し、アリスに送信します。など、好きなだけ支払いを行うことができます。トランザクションが完了すると、アリスは最高値のチケットをチェーンにポストして署名できます。チェーン上のスマートコントラクトは、アリスとボブの署名を検証し、ボブのメモに記載された金額をアリスに支払い、残りのお金をボブに返します。

このテクノロジーは強力です。双方向の支払い、スマートコントラクト関係の処理 (例: アリスとボブがチャネルで金融契約を結ぶ)、およびチャネルの結合 (例: アリスとボブ、ボブとチャーリー・アリスとチャーリーの間にオープン・チャネルがある場合、トラストレス・トランザクションを実行することもできます。

ただし、ステートチャネルの役割は制限されています。参加していないユーザーに資金をチェーンの外に送信することはできません。チャネルは、論理的に明確な所有者がいないオブジェクト (Uniswap など) を表すことはできません。さらに、より複雑なトランザクションを実行する場合は、 , 多額の資金をチャネルに固定する必要があります。

最初のレベルのタイトル

プラズマの仕組み

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

Plasma Cash：

https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298

詳細については、👇を参照してください。

最古のプラズマ論文:

ユーザーはプラズマチェーンのスマートコントラクトに資産を送信して、入金を完了します。プラズマチェーンは、一意の ID (537 など) を資産に割り当てます。すべてのプラズマチェーンにはオペレーター「オペレーター」がいます (オペレーターは集中アクター、マルチシグネチャー、または PoS/DPoS などのより複雑なものになる可能性があります)。オペレーターは時々 (15 秒から 1 時間の範囲で)、バッチ処理を待つ集約トランザクション (オフチェーンで収集したすべての Plasma トランザクションで構成されます) を生成します。

これらの演算子はマークルツリーを生成します。ツリー内の各インデックス X には、トランザクションがある場合、転送トランザクションの資産 ID X が表示されます。トランザクションがない場合、リーフ値は 0 になります。次に、そのマークルツリーのマークルルートを、各インデックス X のマークルブランチとともに、その資産の現在の所有者にオンチェーンで送信します。

ユーザーが出金を希望する場合は、最後に資産を送信したトランザクションのマークルブランチを公開します。その後、スマートコントラクトはチャレンジ期間を開始します。この期間中は、誰でも他の Merkle ブランチを使用して出金の無効化を試みることができます。 (i) 送信者は送信時にアセットの所有者ではなかった、(ii) 送信者は後でアセットを他の人に送信した、のうち少なくとも 1 つを証明する必要があります。一定期間（7 日間など）以内に出金が不正であることを誰も証明しなかった場合、ユーザーは自分の資産を引き出すことができます。

繰り返しになりますが、プラズマとチャネルの両方には重要な弱点があります。両方のスキームを安全にするには、両方のシステムによって制御されるオブジェクトの論理「所有者」が必要です。その資産の所有者が自分の資産を気にしない場合、その資産が無効であることが証明される可能性があります。これは多くのアプリケーションでは許容できますが、他の多くのアプリケーション (Uniswap など) にとっては問題です。所有者の同意なしにオブジェクトの状態を変更できるシステム (同意なしに誰かの残高を増やすことができるアカウントベースのシステムなど) であっても、Plasma には適していません。

Rollups

これは、実際のプラズマまたはチャネルをデプロイする場合、多くの「特定のアプリケーションに関する推論」が必要であり、完全なイーサリアム環境 (または「EVM」) をシミュレートするプラズマまたは状態チャネルシステムを作成することは不可能であることを意味します。この問題を解決するために、さまざまなロールアップスキームが登場しました。

EthHub on optimistic rollups：

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

ZK rollups：

https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/

最初のレベルのタイトル

他のリソースについては、👇を参照してください。

プラズマクラスとチャネルクラスは、データと計算の両方をオフチェーンに移動するという点で、「純粋な」レイヤー 2 ソリューションです。ただし、「データの可用性」をめぐる基本的なゲーム理論の問題は、これらのスキームがすべてのアプリケーションにとって必ずしも安全であるとは限らないことを意味します。プラズマおよびチャネルのソリューションは、所有者による状態の完全な知識に依存していますが、これにより、そのようなソリューションを完全に一般化することができなくなります。ロールアップは、「ハイブリッド」2 層ソリューションです。ロールアップは計算 (および状態ストレージ) をオフチェーンに移動しますが、各トランザクションに関する一部のデータはオンチェーンに置かれます。

データがオンチェーンにあることが重要です (注: IPFS では特定のデータが利用可能かどうかについてのコンセンサスが得られないため、データを「IPFS に」置くことは機能しません。データはオンチェーンに記録される必要があります)。データをオンチェーンに置き、それについて合意に達すると、誰でも必要に応じてロールアップ内のすべての操作をローカルで処理できるようになり、不正行為の検出、引き出しの開始、またはトランザクションのバッチ処理を自分で開始できるようになります。データの可用性が欠如しているということは、悪意のあるオペレーターやオフラインのオペレーターによる影響がさらに小さくなり（たとえば、1 週間の遅延を引き起こすことができない）、トランザクションのバッチを発行する権限を持つ人にとってより多くの設計スペースが開かれ、ロールアップの追跡が容易になります。。

さらに重要なのは、データの可用性が欠如しているということは、資産を所有者にマッピングする必要がなくなったことを意味します。これが、イーサリアムコミュニティが以前のレイヤー 2 スケーリングソリューションよりもロールアップを期待している主な理由の 1 つにつながります。ロールアップは完全に汎用的です。、ロールアップ内で EVM を実行することもできるため、新しいコードをほとんど記述することなく、既存の Ethereum アプリケーションをロールアップに移行できます。

最初のレベルのタイトル

ロールアップの原理とは一体何なのでしょうか？

チェーン上にはスマートコントラクトがあり、これには状態ルート (ロールアップ状態のマークルルート) (つまり、ロールアップ内のアカウント残高、契約コードなど) が含まれています。

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

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

これがロールアップの仕組みです。しかし、もう 1 つ重要な詳細があります。バッチ内のポストステートのルートが正しいことをどのようにして知ることができるのでしょうか?誰かが何の影響もなく任意のポストステートルートを使用してバッチを送信できる場合、ロールアップ内のすべてのトークンを自分に転送できます。この質問は 2 つの異なる解決策につながり、さらに 2 つの異なるロールアップにつながるため、この質問は重要です。

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

2 つのロールアップは次のとおりです。

1. 楽観的なロールアップ。その解決策は不正行為の証明です。このタイプのロールアップは、各バッチのすべての履歴状態のルートとハッシュ値を追跡します。特定のバッチのポストステートルートが間違っていることに誰かが気づいた場合、そのバッチが誤って計算されたという証拠をブロックチェーンに投稿できます。コントラクトはプルーフを検証し、バッチと後続のバッチをロールバックします。

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

一般に、私の個人的な意見は、短期的にはオプティミスティックロールアップの大きな利点は汎用の EVM 計算にあるのに対し、ZK ロールアップは支払い、トランザクション、その他の特定のユースケースに使用される可能性が高い、というものです。しかし、中長期的には、ZK-SNARK テクノロジーが成熟するにつれて、ZK ロールアップはあらゆるユースケースで利点を発揮するようになります。

最初のレベルのタイトル

不正証拠の解体

上の図では、バッチが無効であると主張する不正証明には、緑色のデータが含まれます。バッチ自体が必要です (チェックのためにオンチェーンに保存されているハッシュと比較してください) とマークルツリーの一部です。グラフ内の黄色のノードは緑色のノードによって再構築できるため、指定する必要はありません。このデータは、バッチを実行し、ポストステートのルートを計算するのに十分です (これは、ステートレスクライアントが単一のブロックを検証する方法とほぼ同じです)。計算された事後状態ルートが、取得したバッチ内の事後状態ルートと矛盾する場合、そのバッチは無効です。

バッチが間違っていても、以前のバッチはすべて正しかった場合、そのバッチが間違っていたことを示す不正証拠を作成できることが保証されています。以前のバッチの宣言に注意してください。複数の無効なバッチがロールアップに公開されている場合は、最も古い無効なバッチを証明することを試みるのが最善です。また、バッチが正しければ、それを無効にする不正証明は決して作成できないとも言えます。

最初のレベルのタイトル

圧縮はどうやって行うのですか？

単純な Ethereum トランザクション (ETH の送信) のサイズは約 110 バイトです。ただし、ロールアップ時の ETH 転送の場合、サイズはわずか約 12 バイトです。

この一部は単なる高レベルのエンコーディングです。イーサリアムの RLP エンコーディングは値ごとに 1 バイトを無駄にします。ただし、いくつかの賢い圧縮テクニックも含まれています。

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

➤ ガス価格: ユーザーが 2 の 16 乗などの固定ガス価格範囲で支払うことができるようになります。あるいは、バッチごとに固定のガス料金を請求したり、ガス料金の支払いをロールアッププロトコルから完全に移動して、トレーダーがチャネルを使用して対応する料金をバッチ作成者に支払えるようにすることもできます。

➤ ガス: 同様に、総ガスを 2 の倍数として設定できます。あるいは、ガスをバッチレベルに制限することもできます。

➤ To: インデックスを使用して 20 バイトのアドレスを置き換えることができます（たとえば、アドレスがマークルツリーに追加された 4527 番目のアドレスの場合、それを表すためにインデックス 4527 を使用するだけで済みます。その後、「サブツリー」（サブツリー）を追加します） ) インデックスとアドレス自体の間のマッピング関係を保存します)。

➤ 値: 値を科学表記法で保存できます。ほとんどの場合、トランザクションに必要な有効数字は 1 ～ 3 桁だけです。

➤ 署名: BLS 集約署名を使用して、多数の署名を約 32 ～ 96 バイトの署名に集約できます (プロトコルに応じて)。集約された署名は、バッチのメッセージセットと送信者セットに基づいて一度に確認できます。表内の「~0.5」は、不正行為の証拠として集約署名を検証できる必要があるため、集約署名に含めることができる署名の数に制限があることを示しています。

プライバシー保護を備えたロールアップは重要な例です。楽観的なロールアップでは、各トランザクションのプライバシー保護のための ZK-SNARK 証明がオンチェーンにあり、約 500 バイトを占める必要があります。 ZK ロールアップでは、バッチ全体を含む ZK-SNARK が「内部」ZK-SNARK の有効性を証明しました。

これらの圧縮技術は、ロールアップのスケーラビリティの鍵となります。そうでない場合、ロールアップのスケーラビリティは、基礎となるネットワークと比較して約 10 倍しか向上できません (ただし、一部の特定のコンピューティング集約型アプリケーションでは、単純なロールアップスキームで十分です)。圧縮後、データは処理され、ほぼすべてのアプリケーションでスケーラビリティが 100 倍以上向上します。

最初のレベルのタイトル

トランザクションをバッチにパッケージ化して送信できるのは誰ですか?

オプティミスティックロールアップおよび ZK ロールアップにおけるトランザクションのパッケージ化権については、多くの主張があります。一般に、トランザクションをパッケージ化して送信したいユーザーは、多額のデポジットをロックする必要があります。ユーザーが不正/無効なトランザクション (無効なステートルートを含むなど) を含むバッチを送信した場合、ユーザーのデポジットの一部は破棄され、残りの部分は不正証明者に報酬として与えられます。それ以外にも、次のような可能性があります。

➤ 完全な「アナーキー」: 誰でもいつでもトランザクションをバッチ処理して送信できます。これが最も簡単な方法ですが、もちろん欠点もあります。特に、複数の参加者が同時に送信しようとしても、最終的に 1 つのバッチだけが正常にパッケージ化できる場合は特にそうです。その結果、バッチを発行するためのプルーフやガスを生成するための多くの無駄な作業が発生します。

➤ 集中処理: バッチを送信するアクター、つまりシーケンサが存在します（ただし、出金には例外があります。通常、ユーザーは最初に出金リクエストを送信できますが、シーケンサが次のバッチで出金を処理しない場合は、その後ユーザーが自分でバッチを送信できます)。これは最も「効率的な」方法ですが、集中化された役割に依存します。

➤ PoS セットのランダム選択: 誰でも ETH (またはロールアッププロトコルのトークン) をロールアップコントラクトに入金し、入金者の中から各バッチのソーターをランダムに選択できます。選択される可能性は、ロックされた資産の割合に比例します。。このアプローチの主な欠点は、多額の資本が不必要にロックされてしまうことです。

➤ DPoS 投票: 仕分け者はオークションによって決定され、仕分け者のパフォーマンスが良くない場合、トークン所有者はその仕分け者を追放し、新しいオークションを開始するよう投票できます。

最初のレベルのタイトル

個別のバルクパッケージ化とステートルート処理

現在開発中の一部のロールアッププロジェクトでは、第2層トランザクションのバッチ投入処理とステートルート投入処理を分離する「独立バッチパッケージ化」の手法を採用しています。このアプローチの利点は次のとおりです。

2. ステートルートが無効な場合、バッチ全体をロールバックする必要はありません。ステートルートをロールバックし、他のユーザーがバッチに新しいステートルートを提供するのを待つだけです。これにより、送信者のトランザクションがロールバックされなくなります。

要約すると、効率、シンプルさ、検閲耐性のトレードオフは複雑であり、多くのオプションが検討されています。どのコンセプトが最適な組み合わせであるかを判断するのは時期尚早であり、時間が経てば分かるでしょう。

最初のレベルのタイトル

ロールアップはどこまで拡大できるのでしょうか？

既存のイーサリアムチェーンではガスの上限は1,250万で、トランザクションではデータ1バイトあたり16ガスかかります。これは、ブロックにバッチが 1 つしか含まれていない場合 (これは、zk ロールアップをパッケージ化し、証明検証に 500,000 ガスを費やすのと同等であると言います)、そのバッチには (1,200 万 / 16) 750,000 バイトのデータを含めることができることを意味します。上に示したように、イーサリアム転送のロールアップの場合、各ユーザー操作に必要なのは 12 バイトのみです。これは、トランザクションのバッチに最大 62,500 個のトランザクションを含めることができることを意味します。現在、平均ブロック時間は 13 秒で、これは 1 秒あたり約 4,807 トランザクションに相当します (イーサリアムでの直接転送の場合、1,250 万/21,000/13~= 1 秒あたり 45 トランザクションと比較)

次の表は、他の使用例の例です。

さて、これらの数字はいくつかの理由からあまりにも楽観的すぎることに注目する価値があります。最も重要なことは、少なくとも複数のロールアップが存在するため、ブロックにバッチが 1 つだけ含まれることはほぼ不可能であるということです。第二に、入金と引き出しは常に存在します。第三に、短期的には稼働率が低いため、固定費が大半を占めることになります。しかし、これらの要素を考慮したとしても、100 倍を超えるスケーリングレベルが標準になると予想されます。

(特定の使用例に応じて) 1 秒あたり 1000 ～ 4000 のトランザクションを達成したい場合はどうすればよいでしょうか?ここで eth2 データシャーディングが登場します。シャーディングプロトコルは、あらゆるデータに対して 12 秒ごとに 16 MB のスペースを提供し、システムはデータの可用性についてのコンセンサスを確保します。データスペースはロールアップで使用できます。この 1 秒あたり約 1398 kb のスペースは、イーサリアムチェーンの現在の 1 秒あたり 60 kb の 23 倍であり、長期的にはデータ容量は増加し続けると予想されます。したがって、eth2 シャードデータを使用したロールアップは、1 秒あたり約 100,000 トランザクションのスループットでバッチ処理でき、将来的にはさらに増加する可能性があります。

最初のレベルのタイトル

ロールアップにはどのような未解決の問題が残っていますか?

ロールアップの基本的な概念は現在ではよく理解されていますが、私たちはロールアップが完全に実現可能で安全であると確信しています。また、複数のロールアップがメインネットにデプロイされていますが、ロールアップの設計にはまだ十分に検討されていない領域が多くあり、実装はアクティビティのほとんどをロールアップに移行して、そのスケーラビリティを活用することは困難です。主な問題には次のようなものがあります。

➤ ユーザーとエコロジーの定着 - ロールアップを使用するアプリケーションはそれほど多くなく、ユーザーはロールアップに慣れておらず、ロールアップを統合し始めているウォレットはわずかです。販売業者や慈善団体はまだこの支払い方法をサポートしていません。

➤ クロスロールアップトランザクション - 基本層を介して手数料を発生させることなく、資産とデータ (Oracle 出力など) を 1 つのロールアップから別のロールアップに効率的に移動します。

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

➤ プラズマとロールアップの間の設計空間を探索する - すべてのデータではなく、一部の状態更新関連データをチェーンに配置できるテクノロジーはありますか? このデータは有用なものを生成しますか?

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

結論は

最初のレベルのタイトル

元のリンク:

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

ECN の翻訳作業は、中国のイーサリアムコミュニティに高品質の情報と学習リソースを提供することを目的としています。記事の著作権は原著者に帰属し、転載する場合は原文の出典と ETH 中国の Web サイトを表示する必要があります。長期にわたって再版する場合は、eth@ecn.co に連絡して許可を取得してください。

公式アカウント: ETHチャイニーズステーション

ETH

Vitalik

Odaily公式コミュニティへの参加を歓迎します