イーサリアムは、本稿執筆時点で(おそらく)最高額の経済的安全性を持つパーミッションレスな世界のコンピューターであり、膨大な数の資産、アプリケーション、サービスの決済台帳として機能しています。 イーサリアムには限界があり、ブロックスペースはイーサリアムのレイヤー1(L1)上の希少で高価なリソースです。 レイヤー 2 (L2) スケーリングは、 この問題の解決策と見なされており、近年、主にロールアップの形で、多数のプロジェクトが市場に登場しています。 しかし、 厳密な意味で のロールアップ(ロールアップデータがイーサリアムL1上にあることを意味する)では、イーサリアムが無期限にスケーリングできるわけではなく、 1秒間に数千件のトランザクションしか許可されません。

信頼の最小化 – L2 システム(の機能)は、ベース L1 の外部の信頼を必要とせずに機能する場合、信頼が最小限に抑えられます。

水平スケーリング – グローバルなボトルネックを課すことなくインスタンスを追加できる場合、システムは水平方向にスケーラブルです。

本稿では、信頼を最小化し、水平方向にスケーラブルなシステムが、ブロックチェーンアプリケーションをスケーリングする最も有望な方法であるが、現時点では十分に検討されていないことを論じる。 ここでは、3つの疑問を探ることで、この議論を提示します。

1. アプリケーションの信頼性を最小限に抑える必要があるのはなぜですか?
2. 水平方向にスケーラブルなシステムを構築する理由
3. 信頼の最小化と水平方向のスケーラビリティの両方を最大化するにはどうすればよいでしょうか。

(免責事項:この記事ではベースL1としてイーサリアムに焦点を当てますが、ここで説明する内容のほとんどは、イーサリアム以外の分散型決済レイヤーにも当てはまります。

アプリケーションの信頼性を最小限に抑える必要があるのはなぜですか?

アプリケーションは信頼できる方法でイーサリアムに接続することができ、イーサリアムブロックチェーンへの書き込みやイーサリアムからの読み取りは可能ですが、ビジネスロジックを正しく実行するオペレーターを信頼しています。 BinanceやCoinbaseのような中央集権的な取引所は、信頼できるアプリケーションの好例です。 イーサリアムに接続されているということは、アプリケーションが多様な資産を持つグローバルな決済ネットワークを利用できることを意味します。

信頼できるオフチェーンサービスには重大なリスクが伴います。 2022年の FTX や Celsiusなどの主要な取引所やサービスの崩壊は、信頼できるサービスが誤動作して失敗した場合に何が起こるかについての大きな教訓です。

一方、信頼が最小限に抑えられたアプリケーションは、イーサリアムへの書き込みとイーサリアムからの読み取りを検証可能です。 例としては、Uniswapなどのスマートコントラクトアプリケーション、ArbitrumやzkSyncなどのロールアップ、LagrangeやAxiomなどのコプロセッサなどがあります。 大まかに言えば、アプリケーションがイーサリアムネットワークによって保護されるようになり、より多くの機能(下記参照)がL1にアウトソーシングされるようになると、信頼が失われます。 その結果、信頼を最小化した金融サービスを、カウンターパーティやカストディアンのリスクなしに提供することができます。

アプリケーションとサービスには、L1 にアウトソーシングできる 3 つの主要なプロパティがあります。

1. ライブネス (および順序付け): ユーザーが送信したトランザクションは、タイムリーに含める (実行および決済する) 必要があります。
2. 有効性:トランザクションは事前に指定されたルールに従って処理されます。
3. データ (および状態) の可用性: 履歴データと現在のアプリケーションの状態にユーザーがアクセスできるようになります。

上記の各プロパティについて、必要な信頼の前提が何であるかを考えることができます。特に、Eth L1 はプロパティを提供するか、外部の信頼が必要ですか。 次の表は、さまざまなアーキテクチャ パラダイムでこれを分類したものです。

水平方向にスケーラブルなシステムを構築する理由

水平スケーリングとは、システムの独立したインスタンスまたは並列インスタンスを追加することによるスケーリングを指します。 アプリケーションまたはロールアップ。 これには、グローバルなボトルネックが存在する必要はありません。 水平スケーリングは、指数関数的な成長を可能にし、促進します。

垂直スケーリングとは、Eth L1 やデータ可用性レイヤーなどのモノリシック システムのスループットの向上によるスケーリングを指します。 水平方向のスケーリングがこのような共有リソースのボトルネックになると、多くの場合、垂直方向のスケーリングが必要になります。

クレーム 1: (トランザクション データ) ロールアップは、データの可用性 (DA) によってボトルネックになる可能性があるため、水平方向にスケーリングできません。 DAソリューションを垂直方向に拡張するには、分散化について妥協する必要があります。

データの可用性 (DA) は、ロールアップのボトルネックのままです。 現在、各 L1 ブロックの最大サイズ ターゲットは ~1 MB (85 KB/秒) です。 EIP-4844 では、(長期的には) さらに ~2 MB (171 KB/s) が使用可能になります。Dankshardingにより、Eth L1は最終的に最大1.3MB/sのDA帯域幅をサポートする可能性があります。 Eth L1 DAは、多くのアプリケーションやサービスが競合する共有リソースです。 したがって、DA に L1 を使用すると最高のセキュリティが提供されますが、このようなシステムの潜在的なスケーラビリティがボトルネックになります。 DAにL1を使用するシステムは、(通常)水平方向に拡張できず、 規模の不経済性が生じます。 CelestiaやEigenDAなどの代替DAレイヤーにも帯域幅制限があります(ただし、それぞれ6.67 MB/sと15 MB/sと大きくなります)。 しかし、その代償として、信頼の前提をイーサリアムから別の(多くの場合、分散化されていない)ネットワークに移行し、(経済的な)セキュリティが損なわれます。

主張 2: 信頼が最小限に抑えられたサービスを水平方向に拡張する唯一の方法は、トランザクションごとに (ほぼ) ゼロの限界 L1 データを取得することです。 既知の 2 つのアプローチは、状態差分ロールアップ (SDR) と検証です。

状態差分ロールアップ (SDR) は、トランザクションの集約されたバッチ全体の状態差分をイーサリアム L1 にポストするロールアップです。 EVM では、トランザクション バッチが大きくなるにつれて、L1 にポストされるトランザクションごとのデータは、トランザクション データ ロールアップの定数よりもはるかに小さい定数に減少します。

たとえば、碑文が大量に殺到したストレステストイベントでは、zkSyncではトランザクションあたりのコールデータがトランザクション あたり10バイトまで減少しました。 対照的に、Arbitrum、Optimism、Polygon zkEVM などのトランザクション データ ロールアップでは、通常、通常のトラフィックでは トランザクションあたり約 100 バイト が表示されます。

バリディウムは、関連するトランザクションデータや状態を含まずに、状態遷移の有効性の証明をイーサリアムに投稿するシステムです。 バリディウムは、トラフィックが少ない状況でも水平方向に拡張可能です。 これは、異なるバリデウムの決済を集約できるため、特に当てはまります。

水平方向のスケーラビリティに加えて、バリディウムはオンチェーンのプライバシー(一般のオブザーバーから)を提供することもできます。 プライベートDAを備えたバリディウムは、データと状態の可用性を一元化し、ゲートで制御しているため、ユーザーはデータにアクセスする前に自分自身を認証する必要があり、オペレーターは優れたプライバシー対策を実施できます。 これにより、従来のウェブサービスや金融サービスと同様のレベルのユーザーエクスペリエンスが実現し、ユーザーの活動は一般の監視から隠されますが、ユーザーデータの信頼できる管理者(この場合はバリディウムオペレーター)がいます。

集中型シーケンサーと分散型シーケンサーはどうでしょうか? システムを水平方向にスケーラブルに保つには、集中型または分散型の独立したシーケンサーをインスタンス化することが重要です。 特に、共有シーケンサーを使用するシステムは、 アトミック <a href="https://hackmd.io/ @EspressoSystems /SharedSequencing">コンポーザビリティを享受していますが、システムが追加されるにつれてシーケンサーがボトルネックになる可能性があるため、水平方向にスケーリングできません。

相互運用性についてはどうですか? 水平方向にスケーラブルなシステムは、共有決済レイヤーを介してあるシステムから別のシステムにメッセージを送信できるため、すべてのシステムが同じ L1 に安定する場合、追加の信頼なしで相互運用できます。 運用コストとメッセージングの遅延の間にはトレードオフがあります (これはアプリケーション層で 解決 できる可能性があります)。

水平方向にスケーラブルなシステムのための信頼の最小化

水平方向にスケーラブルなシステムにおける活性、順序付け、およびデータの可用性に関する信頼要件をさらに最小限に抑えることはできますか?

注目すべきは、水平方向のスケーラビリティを犠牲にして、トラストレスな活性とデータの可用性を救う方法を知っていることです。 たとえば、L2 トランザクションを L1 から開始して、包含を保証することができます。 Volition は、ユーザーにオプトイン L1 状態の可用性を提供できます。

別の解決策は、単に 分散化 することです(ただし、L1に依存しません)。 単一のシーケンサーの代わりに、分散型シーケンサー(Espresso SystemsやAstriaなど)を利用することで、システムの分散化が進み、ライブネス、オーダー、データの可用性に必要な信頼性を最小限に抑えることができます。 これを行うと、(1)パフォーマンスは分散システムのパフォーマンスによって制限される可能性があり、(2)プライベートDAを使用するvalidiumsの場合、分散型シーケンサーネットワークがパーミッションレスの場合、デフォルトのプライバシー保証が失われます。

シングルオペレーターのバリデーションやSDRの信頼性をさらにどの程度最小限に抑えることができるか? ここにはいくつかのオープンな方向性があります。

オープンな方向 1: バリデウムにおける信頼最小化されたデータの可用性。 Plasmaは、特定の状態モデル(UTXO状態モデルを含む)の引き出しのみ、またはユーザーが定期的にオンラインであることを要求する( Plasma Free )かのいずれかの問題を解決します。

オープン・ディレクション2:SDRとバリディウムにおける説明責任のある事前確認 ここでの目標は、シーケンサーからのトランザクションの包含の迅速な事前確認をユーザーに提供することであり、その確認により、ユーザーは、包含の約束が果たされない場合に、シーケンサーの経済的利害関係に挑戦し、削減できるようにする必要があります。 ここでの課題は、(スラッシングに必要)インクルージョンがないことを証明するには、ユーザーの追加データが必要になる可能性が高く、シーケンサーはそれを単に差し控えることができるということです。 したがって、少なくとも、SDRまたはバリディウムは、完全なコールデータまたは取引履歴について(潜在的に許可された)データ可用性委員会を雇用し、同じ委員会がユーザーの要求に応じて(事前確認された取引の)不包含の証明を提供できるようにすることを要求するのが妥当です。

オープン方向 3: 活性障害からの迅速な回復。 シングルオペレーターシステムは、活性障害(例: アービトラムは碑文イベント中にオフラインになりました)。 このシナリオで、サービスの中断を最小限に抑えるシステムを設計できますか? ある意味では、自己シーケンスと状態提案を可能にするL2は、長期にわたる生存障害に対する保証を提供します。 短時間の故障に対する回復力の高い単一オペレーターシステムの設計は、現在十分に検討されていません。 ここで考えられる解決策の 1 つは、活性障害に対するスラッシングを提供することで、活性障害に責任を持たせることです。 もう1つの解決策として考えられるのは、引き継ぎが行われるまでの遅延期間(現在、約1週間に設定されています)を単純に短縮することです。

結論

信頼の最小化を維持しながらグローバルな決済台帳をスケーリングすることは、難しい問題です。 今日のロールアップとデータ可用性の世界では、垂直スケーリングと水平スケーリングが明確に区別されていません。 信頼を最小化したシステムを地球上のすべての人に真に拡張するには、信頼を最小化し、水平方向にスケーラブルなシステムを構築する必要があります。

確認

フィードバックと議論をしてくれた Vitalik Buterin 氏と Terry Chung、編集コメントをいただいた Diana Biggs 氏に感謝します。

声明：

免責事項：

1. この記事は[Mirror]からの転載です。 すべての著作権は原著作者[1kx]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。