オプティミスティックロールアップについて知っておくべきことすべて

編集者注: この記事は以下から引用しましたチェーンニュース ChainNews (ID:chainnewscom)、許可を得て掲載しています。

編集者注: この記事は以下から引用しました

チェーンニュース ChainNews (ID:chainnewscom)

チェーンニュース ChainNews (ID:chainnewscom)

、許可を得て掲載しています。

著者: Georgios Konstantopoulos、暗号ベンチャーキャピタル会社パラダイムのリサーチパートナー。

編纂者: ザン・ファン

パラダイムは、Lianwen が記事の中国語版を翻訳して出版することを許可しました。

イーサリアム エコシステムにおける最大の課題の 1 つは、厳しいリソース制約 (CPU、帯域幅、メモリ、ディスク容量など) の下で低レイテンシーと高スループットをどのように達成するかです。

システムの分散化は、ネットワーク内の最も弱いノードがシステムのルールを検証する能力によって決まります。低リソースのハードウェア上で実行できる高性能プロトコルを「スケーラブル」と呼ぶことができます。

この記事では、現在の「レイヤー 2 ソリューション」がどのように機能するか、それに対応するセキュリティ モデル、およびそれらがイーサリアムのスケーラビリティの問題にどのように対処するかについて詳しく説明します。

• イーサリアムの最先端のスケーラビリティ テクノロジと、そのようなシステムを構築および設計する方法について詳しく知りたい場合は、この記事が役に立つかもしれません。

• 記事全体を通じて、重要なキーワードや概念は太字で強調表示されています。これらは、暗号通貨について学習する際に遭遇する単語や用語です。このトピックは複雑です。途中で戸惑うこともあるかもしれませんが、読み続ければ必ず何かを得られると思います。

• ブロックチェーンのリソース要件

ビットコインやイーサリアムなどの分散ネットワークでノードを実行するためのリソース要件に影響を与える要因は 3 つあります。

• 帯域幅: ブロックチェーン関連データのダウンロードとブロードキャストにかかるコスト。

• 計算: スクリプトまたはスマート コントラクトで計算を実行するコスト。

ストレージ: インデックス作成のためにトランザクション データを保存するコストと、新しいトランザクション ブロックを処理し続けるための「状態」を保存するコスト。 「状態」（アカウント残高、コントラクトバイトコード、ノンス値）の保存は、生のトランザクションデータを保存するよりもコストがかかることに注意してください。

• パフォーマンスを測定するには 2 つの方法があります。

• スループット: システムが 1 秒あたりに処理できるトランザクションの数。

レイテンシー: トランザクション処理に必要な時間。

分散化は、ビットコインやイーサリアムのような新興暗号ネットワークの望ましい特性ですが、ネットワークを分散化する要素は何でしょうか?

低い信頼性: このプロパティにより、誰でもビットコインの数が 2,100 万を超えていないこと、またはビットコインが偽造できないことを検証できます。ノード ソフトウェアを独自に実行している人が最新の状態を計算し、プロセス内ですべてのルールに従っていることを確認します。

• 低コスト: ノード ソフトウェアの運用に費用がかかる場合、個人は信頼できるサードパーティに依存して状態を確認することになります。コストが高いということは信頼性の要件が高いことを意味しますが、これは最初から避けたいものです。

• もう 1 つの望ましい特性はスケーラビリティです。つまり、システムの実行コストに合わせてスループットと待ち時間を超線形に拡張する能力です。それは良い定義ですが、「信頼」は含まれません。したがって、システムの信頼仮定を大幅に増加させることなくスケーラビリティを達成することを「分散型スケーラビリティ」と定義します。

• さらに拡大すると、イーサリアムの実行環境はイーサリアム仮想マシン (EVM) です。 EVM を介して実行されるトランザクションは、さまざまなコストでさまざまな操作を実行します。たとえば、ストア操作は追加操作よりも高価です。トランザクションの計算単位を「ガス」と呼び、1ブロックあたり最大12.5mのガスを処理するようにシステムパラメータが設定されており、トランザクションブロックは平均12.5秒ごとに生成されます。したがって、イーサリアムのレイテンシは 12.5 秒、スループットは 1 秒あたり 100 万ガスになります。

• 「1 秒あたり 100 万のガスがもたらすメリットとは何ですか?」と疑問に思うかもしれません。

1 秒あたり最大 47 件の「単純転送」トランザクション。これらのトランザクションは 21,000 ガスを消費し、ETH を A から B に送金する役割を果たし、最も単純なタイプのトランザクションです。

1 秒あたり最大 16 の ERC20 トークン転送。 ETH 転送と比較して、これらの方法にはより多くのストレージ操作が含まれるため、それぞれに最大 60,000 ガスのコストがかかります。

1 秒あたり最大 10 件の Uniswap 資産トランザクション。トークン間のトランザクションの平均コストは約 102,000 ガスです。

…任意のトランザクションのガスコストを選択し、それを 1m で割ります (12.5m / 12.5 /gas)

トランザクション実行の複雑さが増すと、システムのスループットが非常に低い値まで低下することに注意してください。まだまだ改善の余地はあります！

解決策 1: 仲介業者を利用する

当社は信頼できる第三者を利用してすべての取引を円滑に進めることができます。このようにして、非常に高いスループットを達成でき、待ち時間はわずか 1 秒未満になる可能性があります。素晴らしいです! これによりシステム全体のパラメータは変更されませんが、サードパーティによって一方的に設定された信頼モデルにオプトインします。彼らは私たちを検閲したり、私たちの資産を没収したりするかもしれません。これは望ましくないことです。

解決策 2: ブロックをより大きく、より頻繁に作成する

2 つのブロック間の時間を短縮することでレイテンシを短縮でき、ブロック ガスの制限を増やすことでスループットを向上できます。この変更によりノードの運用コストが高くなり、個人がノードを運用することが困難になります（これはすでにEOS、Solana、Rippleなどで起こっています）。

解決策 1 では、信頼の必要性が高まります。オプション 2 では、コストが増加します。これにより、スケーラビリティのオプションとしてそれらが排除されます。

第一原則から始めて、楽観的ロールアップを再発見する

次のセクションでは、読者がハッシュとマークル ツリーについてある程度の知識があることを前提としています。

これまでに学んだことに基づいて、ユーザーやノードオペレーターに負担をかけずにイーサリアムの実効スループットを向上させるプロトコルを発見することを目的として、ソクラテス対話をシミュレートしてみましょう。

Q: 信頼性とコストの前提を大幅に変更することなく、イーサリアムを拡張したいと考えています。どうすればいいですか？

A: 既存の運用に必要なシステム コストを削減したいと考えています (3 つのリソース タイプについては上記を参照)。これがなぜ簡単ではないのかを理解するには、まずイーサリアムのアーキテクチャを確認する必要があります。

現在、イーサリアムのすべてのノードは、ユーザーによって送信されたすべてのトランザクションを保存し、実行します。実行中、トランザクションは EVM を介して実行され、EVM の状態 (ストレージ、残高など) と対話します。これは非常にコストのかかる操作です。一般的なスマート コントラクト最適化手法は、状態とのやり取りの数を最小限に抑えることに重点を置いていますが、継続的に小さな改善を提供するだけです。

Q: リソースコストを低く抑えながら、国家を介在させずにトランザクションを実行する方法があるということですか?

A: 極端な場合、一部のデータをオンチェーンに保持したまま、すべての実行をオフチェーンに移動することはできますか?これは、「シーケンサー」と呼ばれるサードパーティを導入することで実現できます。これらは、ユーザーが送信したトランザクションをローカルに保存して実行する責任を負います。システムを存続させるために、注文者は受け取ったトランザクションのマークル ルートとイーサリアム上で生成された状態ルートを定期的にコミットする必要があります。 O(N) 個のオフチェーン トランザクションに対してイーサリアムの状態に O(1) データのみを保存するため、これは正しい方向への一歩です。

Q: それでは、ソーターにすべてをオフチェーンで計算させ、マークル ルートのみを公開することでスケールするのですか?

答え: はい。

Q: わかりました。一度参加すると、注文者は安い送金手数料を保証します。では、入金と出金はどのように機能するのでしょうか?

回答: ユーザーはイーサリアムにお金を入金することでシステムにアクセスし、注文者は対応する金額をユーザーのアカウントに入金します。ユーザーはイーサリアム上でそのような取引内容を提案できます。たとえば、「3 ETHを引き出したい、私のアカウントには現在3 ETH以上あり、これが証拠です」などです。レイヤー 1 に実際のユーザー状態がない場合でも、ユーザーは注文者によって公開された状態ルートを思いつき、現在の状態に十分な資金があることを示す関連するマークル証明を示すことができます。

Q: ユーザーが資金を引き出すにはマークル証明が必要であることがわかりました。ユーザーはマークル証明を作成するためのデータをどのように取得するのでしょうか?

A: ソーターにデータを提供するように依頼できます。

Q: ソーターが一時的または永続的に利用できない場合はどうなりますか?

A: ソーターは悪意のあるものであるか、単に技術的な問題によりオフラインになっている可能性があり、パフォーマンスの低下を引き起こす可能性があります (さらに悪いことに、資産が盗まれます!)。したがって、注文者には、実行ではなく保管のために完全なトランザクションデータをオンチェーンに送信することも要求する必要があります。この問題の目標は、データの可用性を取得することです。すべてのデータがイーサリアムに永続的に保存されていると仮定すると、注文者が消滅した場合でも、新しい注文者はイーサリアムからすべてのレイヤー 2 関連データを取得し、最新のレイヤー 2 状態を再構築し、前任者の場所から離れて継続することができます。

Q: 注文者がオンラインであるにもかかわらず、マークル証明データの提供を拒否した場合、イーサリアムからダウンロードできますか?

A: はい、Ethereum ノードを自分で同期したり、多くの管理対象ノード サービスの 1 つに接続したりできます。

Q: 私がまだ理解できていないことの 1 つは、イーサリアムに何かを保存したまま実行できないのはなぜでしょうか?すべてのトランザクションは EVM を経由するわけではありませんか?

回答: A から B に ETH を送金するために 10 件のトランザクションを送信するとします。各トランザクションを実行すると、A の nonce が増加し、A の残高が減少し、B の残高が増加します。これには、イーサリアムのワールド状態からのかなりの数の書き込みと読み取りが含まれます。代わりに、すべてのトランザクションのエンコードをスマート コントラクトの public (bytes_transactions) public { } 関数に送信できます。関数の本体が空であることに注意してください。これは、公開されたトランザクション データがどこにも解釈、実行、アクセスされず、ブロックチェーンの履歴ログに保存されるだけであることを意味します (書き込みコストは非常に低いです)。

Q: 仕分け業者は信頼できますか?無効な状態遷移を発行した場合はどうなるでしょうか?

A: 注文者が状態遷移のバッチを公開するたびに、いずれかの当事者が状態遷移の 1 つが無効であることを示す「不正行為の証拠」を発行できる「紛争期間」が存在します。これは、状態遷移を引き起こしたトランザクションをオンチェーンで再生し、結果の状態ルートを順序付け者によって公開された状態ルートと比較することによって実証できます。状態ルートが一致しない場合、不正行為の証明は成功し、状態遷移はキャンセルされます。無効な状態遷移の後にさらに状態遷移がある場合、それらもキャンセルされます。ただし、取引が紛争期間を過ぎた場合、異議を申し立てることはできなくなり、最終的な取引とみなされます。

Q：ちょっと待ってください！先ほど、a) コストが増加する場合、または b) 新しい信頼の前提が導入される場合、それはスケーラビリティとは言えないと言いました。あなたが説明したシナリオでは、誰かが常に不正行為を報告すると仮定していませんか?

答え: はい。不正を監視し、レイヤー1とレイヤー2の状態が一致しない場合には不正の証拠を公開する「バリデーター」と呼ばれる存在が存在すると仮定します。また、バリデーターは紛争期間内にイーサリアムに含まれる不正証拠を確実に取得できると想定しています。私たちはバリデーターの存在は「弱い」仮定であると考えています。何千人ものユーザーがいるアプリケーションがあり、バリデーターの実行に必要なのは 1 人だけであることを想像してください。それは的外れではないように思えます。一方で、イーサリアムの信頼モデルの変更やイーサリアムノードの運用コストの増加は、変更したくない「強い」前提条件です。これは、分散型スケーラビリティを定義するときに「基礎となるシステムの前提を大幅に変更する」という意味です。

Q: この新しいソリューションの成功によってすべての関係者が恩恵を受けるため、誰かがバリデーターを実行することに同意します。ただし、実際の運用コストにももちろん依存します。では、バリデーターとソーターを実行するためのリソース要件は何でしょうか?

A: 発注者と検証者は、レイヤー 2 状態を生成するために、イーサリアム フル ノード (アーカイブ ノードではない)、つまり完全なレイヤー 2 ノードを実行する必要があります。検証者が実行するソフトウェアは不正証拠の作成を担当し、注文者が実行するソフトウェアはユーザーのトランザクションをバンドルして公開する責任を負います。

Q：そうですか？

答え: はい!おめでとう！ 2019 年から 2021 年に最も期待されているスケーリング ソリューションである Optimistic Rollup (Optimistic Rollup は、「Optimistic Contracts」と「On-Chain Data Availability」(別名「Data Aggregation」) の組み合わせです) を再発見しました。これはイーサリアム コミュニティによる数年にわたる研究プロセスの最終成果物であるため、その理由は簡単に理解できます。これは、上記の短い会話ですでに経験したはずです。

楽観的なインセンティブ

• レイヤ 2 スケーリングは、実行されるオンチェーン トランザクションの数を最小限に抑えようとするという事実に基づいています。不正行為の証明を使用して、発生する可能性のある無効な状態遷移をキャンセルします。不正証明はオンチェーントランザクションであるため、イーサリアム上で発行される不正証明の数も最小限に抑えたいと考えています。理想的な世界では、不正行為は決して発生しないため、不正行為の証拠は決して発行されません。

• 当社は忠実保証金を導入することで不正行為を抑制します。ユーザーが仕分け者になるためには、まずイーサリアムに保証金を投稿する必要がありますが、不正であることが判明した場合は保証金を没収されます。個人が不正行為を発見するよう奨励するために、注文者の保証金は削減された後に検証者に配布されます。

ロイヤルティボンドと紛争期間

不正行為を証明するためのインセンティブを設計する場合、調整するパラメータが 2 つあります。

ロイヤルティボンドのサイズ: 注文者はバリデーターに分配される金額を公開する必要があります。規模が大きければ大きいほど、バリデーターとしてのインセンティブは大きくなり、注文者として不正行為をするインセンティブは少なくなります。

• 紛争期間期間: 不正行為の証明を発行できる期間。この期間を過ぎると、レイヤー 2 のトランザクションはレイヤー 1 で安全とみなされます。紛争期間が長いほど、検閲攻撃に対するセキュリティが強化されます。紛争期間が短いと、レイヤー 2 からレイヤー 1 に撤退するユーザーにとって、資金がレイヤー 1 で再利用されるまで長く待つ必要がなくなるため、優れたユーザー エクスペリエンスが生まれます。

• 私たちの意見では、両方のパラメーターの正確な静的値を見つけることは不可能です。おそらく 10 ETH 債券と 1 日の紛争期間で十分でしょう。しかし、おそらく 1 ETH と 7 日で十分でしょう。本当の答えは、バリデーターになるためのインセンティブ (ランニングコストに依存) と、不正証明の発行がどれほど簡単か (レイヤー 1 の混雑に依存) に依存するということです。これらは両方とも手動または自動で調整できる必要があります。

• EIP1559 は、オンチェーンの混雑を推定し、紛争期間の期間をプログラム的に調整するために使用できる新しい BASEFEE オペコードをイーサリアムに導入していることに言及する価値があります。

• このペナルティ メカニズムを正しく実装する方法が非常に重要です。そうしないと、実際に悪用されてしまいます。素朴で非現実的な実装とは何かを説明するための例を示します。

• アリスは 1 ETH ボンドを投稿し、システム内で注文者として機能できるようにします。

アリスが不正なステータス更新を投稿する

ボブはこれに気づき、論争を発表します。成功すると、アリスの債券の 1 ETH がボブに付与され、不正な状態の更新がキャンセルされます。

アリスさんもこの論争に気づき、投稿しました（自分自身に挑戦してみました！）

ALice は 1 ETH を取得し、不正行為を試みましたが、実際にはペナルティはありませんでした。

アリスは、「先を走る」ことによってこの攻撃を開始できます。つまり、ボブと同じトランザクションをブロードキャストしますが、ガス価格が高くなって、アリスのトランザクションがボブより先に実行されます。これは、アリスが最小限のコスト（イーサリアム取引手数料のみ）で不正行為を試み続けることができることを意味します。

この問題の解決策は簡単です。保釈金全体を係争者に与える代わりに、保釈金の X% を燃やすことです。上の例では、50% を燃焼した場合、アリスは 0.5 ETH しか得られませんが、これはステップ 2 で不正行為を試みるのを阻止するのに十分です。もちろん、ボンドをバーンすると (支払いが少なくなるため) バリデーターを実行するインセンティブが減少するため、バーンされたボンドがユーザーにバリデーターになる動機を与えるのに十分であることを確認する必要があります。

オプティミスティックロールアップに対するよくある批判と私たちの対応

オプティミスティック ロールアップの構成要素が完成したので、このメカニズムに対する最も一般的な批判を調査して対処しましょう。

• 長い撤退/紛争期間は採用と構成可能性にとって致命的です

• 長い紛争期間は安全にとって良いことであると上で述べました。ここには固有のトレードオフがあるようです。長い紛争期間はユーザーにとって好ましくなく、資金を引き出したい場合に長時間待たなければなりません。異議申し立て期間が短いと、ユーザー エクスペリエンスは確かにスムーズになりますが、詐欺が発生するリスクが生じます。

それは問題ないと思います。引き出しが長期間遅れる可能性があるため、マーケットメーカーが迅速に介入し、より迅速な引き出しを提供すると予想されます。これが可能となるのは、レイヤー 2 状態を検証する人は引き出しが不正である可能性が高いかどうかを正確に判断できるため、わずかな割引でサービスを「購入」できるからです。例えば：

• 参加者：

• アリス: レイヤー 2 には 5 つの ETH があります。

• ボブ: 「マーケットメーカー」スマートコントラクトでは、レイヤー 1 に 4.95 ETH があり、レイヤー 2 でバリデータが実行されています。

• ステップ：

• アリスはボブに「迅速な」引き出しを希望していることを伝え、手数料 0.05 ETH を支払います。

アリスはボブの「マーケットメーカー」スマートコントラクトに現金リクエストを送信します

この時点で次の 2 つのことが起こる可能性があります。

ボブは、引き出しがレイヤー 2 バリデーターで有効であることを確認し、高速引き出しを承認します。これにより、4.95 ETH がすぐにアリスのレイヤー 1 アドレスに転送されます。出金期間が終了すると、ボブは 5 ETH を請求して純利益を得ることができます。Simple Fast Withdrawalsボブのバリデーターは、トランザクションが無効であることを彼に警告します。ボブはトランザクションによって引き起こされた状態遷移に異議を唱え、トランザクションをキャンセルし、悪意のあるトランザクションの発生を許可したとして保証金を獲得します。

アリスは正直になってすぐにお金を引き出すか、不正直になって罰せられるかのどちらかです。マーケットメーカーに支払われる手数料は時間の経過とともに圧縮され、サービスの需要があれば、最終的にはプロセスがユーザーに完全に見えなくなると予想されます。

この機能の最も重要な意味は、紛争期間全体を待つことなく、レイヤー 1 コントラクトでのコンポーザビリティが可能になることです。

このテクニックが最初に導入されたのは「」であることに注意してください。

記事内に記載されている「（簡単・迅速な出金）」。

マイナーが賄賂を受け取って出金を検閲し、オプティミスティックロールアップのセキュリティを破る可能性がある

「オプティミスティックロールアップのほぼゼロコストの攻撃シナリオ」という投稿では、マイナーのインセンティブが大きすぎるため、注文者がイーサリアムマイナーと共謀し、係争中の取引をレビューすることに消極的になるのではないかと考える人もいる。もちろん、システム セキュリティが紛争解決に依存していることを考えると、これはあらゆる楽観的なシステムにとって致命的です。

バリデーターのジレンマによりバリデーターの運用が妨げられ、楽観的なロールアップが崩れる分析するそして解決Ed Felten はバリデーターのジレンマに関する優れた記事を書きました

• 分析する

• そして

• 解決

• をまとめると次のようになります。

システムのインセンティブが意図通りに機能すれば、誰も不正行為をしなくなる

誰も不正行為をしていなければバリデーターを実行する意味がありません。バリデーターを運用しても収益が得られないからです。

ソーターが不正行為を行ったため、システムが期待どおりに動作しなくなりました

結論は

これはほとんど逆説的ですが、重要なことのように思えます。報酬サイズが固定されていると仮定すると、バリデーターが増えると、単一のバリデーターに期待される報酬が減少します。また、バリデーターの数が増えると、パイと不正行為が少なくなるようで、これが問題をさらに悪化させます。フォローアップ分析で、フェルテンは検証者のジレンマに対する解決策も提供します。

私はここでは反対の立場をとりたいのですが、バリデーターの窮状は批評家が言うほど重要ではないと思います。実際には、バリデーターになるには非金銭的なインセンティブがあります。たとえば、プールされたプラットフォーム上に大規模なアプリケーションを構築し、トークンを保持している場合、システムに障害が発生すると、アプリケーションは機能しなくなるか、トークンの価値が失われます。さらに、迅速な引き出しの必要性は、（前のセクションで見たように）不正行為の影響を受けないマーケットメーカーバリデーターの存在に対するインセンティブを生み出します。より具体的に言うと、ビットコインはブロックチェーン履歴全体を保存したり、ローカルデータをピアに提供したりするインセンティブを提供しませんが、人々は利他的にそうするのです。

バリデーターを単独で実行することは奨励されませんが、システムの安全性が維持されます。これは、システムの成功に投資する企業にとって最も重要なことです。したがって、楽観的システムのレイヤー 2 では、バリデーターのジレンマを回避するメカニズムを考案する必要はないと考えています。結論は私たちは、2021 年のイーサリアムにとって重要となるテクノロジーの 1 つであるオプティミスティック ロールアップを分析します。

その利点を要約すると: Optimistic Rollup は、イーサリアム ユーザーのコストや信頼のニーズに実質的な影響を与えることなくパフォーマンスを向上させながら、イーサリアムのセキュリティ、構成可能性、開発者の堀を継承するイーサリアムの拡張機能です。楽観的ロールアップを機能させるインセンティブ構造を調査し、一般的な批判に対応します。オプティミスティック ロールアップのパフォーマンスの上限は、Tier 1 で公開されているデータによって決定されることを強調したいと思います。したがって、その利点は次のとおりです。 1) 公開するデータを可能な限り圧縮します (たとえば、BLS 署名の集約）、2）大きくて安価なデータレイヤー（例：ETH2）があります。追加の読書として、Buterin の On Rollup と