1kx: ブロックチェーン拡張の最終結果は信頼の最小化と水平方向の拡張です

オリジナル著者: weidai.eth

オリジナル編集：ルフィ、フォーサイトニュース

イーサリアムは、この記事の執筆時点では最高の経済的安全性を備え、膨大な数の資産、アプリケーション、サービスの決済台帳として機能する、パーミッションレスの世界コンピューターです。イーサリアムには限界もあります。イーサリアムメインネットではブロックスペースが希少で高価なリソースです。この問題に対する最善の解決策はL2拡張であると考えられており、近年この分野に多くのプロジェクトが参入しており、そのほとんどがロールアップである。ただし、厳密な意味でのロールアップ（データはイーサリアム L1 上に配置される）では、イーサリアムの無制限の拡張を実現するものではなく、1 秒あたり数千件のトランザクションを処理するのが上限です。

まず、次の 2 つの概念を理解してください。

• 信頼の最小化: L2 システムの機能が基礎となる L1 の外側に信頼できる部分を必要としない場合、システム (の機能) は信頼の最小化です。

• 水平方向のスケーラビリティ: グローバルなボトルネックを作成せずにインスタンスを追加できる場合、システムは水平方向にスケーラブルです。

この記事では、信頼を最小化し、水平方向にスケーラブルなシステムがブロックチェーン アプリケーションを拡張する最も有望な方法であると主張しますが、この方向性は現在十分に検討されていません。私たちは次の 3 つの質問を検討して議論を展開します。

• なぜアプリケーションの信頼を最小化する必要があるのでしょうか?

• なぜ水平方向に拡張するシステムを構築するのでしょうか?

• 信頼の最小化と水平方向のスケーラビリティを強化するにはどうすればよいでしょうか?

免責事項: この記事は基礎となる L1 としてのイーサリアムに焦点を当てていますが、ここで説明する内容の多くはイーサリアム以外の他の分散型決済レイヤーにも当てはまります。

なぜアプリケーションの信頼を最小化する必要があるのでしょうか?

アプリケーションは信頼できる方法でイーサリアムに接続でき、イーサリアム ブロックチェーン上でデータの書き込みと読み取りを行うことができますが、ビジネス ロジックが正しく実行されるには信頼が必要です。 Binance や Coinbase などの集中型取引所は、信頼できるアプリケーションの良い例です。イーサリアムに接続すると、アプリケーションは複数の資産を持つグローバル決済ネットワークを利用できるようになります。

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

一方、信頼最小化アプリケーションは、Uniswap などのスマート コントラクト アプリケーション、A.bitrum や zkSync などのロールアップ、Lagrange や Axiom などのコプロセッサなど、検証可能な方法でイーサリアムとの間で書き込みおよび読み取りを行うことができます。大まかに言うと、アプリケーションがイーサリアム ネットワークによって保護され、より多くの機能が L1 に割り当てられると、信頼が失われます。その結果、カウンターパーティやカストディアンのリスクを伴うことなく、信頼を最小限に抑えた金融サービスを提供できます。

機能を L1 にアウトソーシングすることにより、アプリケーションとサービスは 3 つの重要な属性を獲得します。

• 生存性 (および順序付け): ユーザーが送信したトランザクションは、適時に組み込まれる (実行および決済される) 必要があります。

• 有効性: トランザクションは、事前に指定されたルールに従って処理されます。

• データ (および状態) の可用性: ユーザーは、アプリケーションの現在の状態だけでなく履歴データにもアクセスできます。

上記のプロパティごとに、どのような信頼の前提が必要か、特にイーサリアム L1 がそのプロパティを提供するかどうか、または外部の信頼が必要かどうかを考えることができます。以下の表は、さまざまなアーキテクチャの例を分類しています。

なぜ水平方向に拡張するシステムを構築するのでしょうか?

水平スケーリングとは、アプリケーションやロールアップなどの独立したインスタンスまたは並列インスタンスをシステムに追加することによるスケーリングを指します。これには、システム内にグローバルなボトルネックがないことが必要です。水平スケーリングにより、システム スループットの指数関数的な増加を達成できます。

垂直スケーリングとは、システム全体 (イーサリアム L1 やデータ可用性レイヤーなど) のスループットを向上させることによるスケーリングを指します。共有リソースなどで水平スケーリングがボトルネックに遭遇した場合、垂直スケーリングが必要になることがよくあります。

ステートメント 1: ロールアップは、データ可用性 (DA) のボトルネックに遭遇する可能性があるため、水平方向に拡張できません。垂直スケーリングの DA ソリューションには、分散化における妥協が必要です。

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

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

State Difference Rollup (SDR) は、集約されたトランザクションのバッチ内の状態の違いを Ethereum L1 に公開するロールアップです。 EVM の場合、トランザクション バッチが大きくなるにつれて、L1 にパブリッシュされる各トランザクション データは定数に近づき、ロールアップのトランザクション データよりもはるかに小さくなります。

たとえば、大量の書き込みが行われたストレス テスト イベント中に、zkSync はコールデータがトランザクションあたり 10 バイトに減少したことを確認しました。比較すると、Arbitrum、Optimism、Polygon zkEVM などのロールアップは、通常のトラフィックの場合、トランザクションごとに約 100 バイトです。

validium は、トランザクション データや状態を関連付けずに、状態遷移の有効性証明をイーサリアムに公開するシステムです。 Validium は、トラフィックが少ない状況でも高度な水平スケーラビリティを備えています。また、異なるバリディアムが決済レイヤーを共有できます。

水平方向のスケーラビリティに加えて、validium は (一般の観察者からの) オンチェーンのプライバシーを提供できます。 Validium with Privacy DA は、データと状態の可用性を一元管理およびゲート制御します。つまり、ユーザーはデータにアクセスする前に認証する必要があり、オペレーターは適切なプライバシー慣行を実装できます。これにより、従来の Web サービスや金融サービスと同様のユーザー エクスペリエンスが可能になります。ユーザーのアクティビティは公的監視の対象ではありませんが、ユーザー データの信頼できる管理者 (この場合は Validium オペレーター) が存在します。

集中型ソーターと分散型ソーターはどうなるでしょうか?システムの水平方向の拡張性を維持するには、独立したソーター (集中型または分散型) が重要です。共有ソーターを使用するシステムはアトミックに構成可能ですが、システムが追加されるとソーターがボトルネックになる可能性があるため、水平方向に拡張できないことに注意してください。

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

水平方向に拡張可能なシステムの信頼の最小化

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

驚くべきことに、私たちは水平方向のスケーラビリティを犠牲にしてトラストレスな稼働性とデータの可用性を取り戻す方法を知っています。たとえば、L2 トランザクションを L1 から開始して、確実に含めることができます。 Volition は、ユーザーにオプトインの L1 ステータスの可用性を提供できます。

もう 1 つの解決策は、単純に分散化することです (ただし、L1 には依存しません)。単一のシーケンサーを使用するのではなく、分散型シーケンサー (Espresso Systems や Astria など) を使用すると、システムがより分散化され、稼働性、順序付け、およびデータの可用性に必要な信頼を最小限に抑えることができます。これを行うには、単一オペレーターのソリューションと比較して制限があります。(1) パフォーマンスは分散システムのパフォーマンスによって制限される可能性があります。(2) プライバシー DA を備えた検証の場合、分散シーケンサー ネットワークがパーミッションレスである場合、デフォルトのプライバシー保護が失われます。

シングルキャリアの有効性や SDR に対する信頼への依存をどれだけ減らすことができるでしょうか?ここにはいくつかの方向があります。

方向 1: 検証における信頼を最小限に抑えたデータ可用性。 Plasma は、特定の状態モデル (UTXO 状態モデルを含む) の取り消しの問題、またはユーザーが定期的にオンラインであることを要求する (Plasma Free) など、状態の可用性の問題をある程度解決します。

方向 2: SDR と検証における責任ある事前検証。ここでの目標は、シーケンサー組み込みトランザクションの迅速な事前確認をユーザーに提供することであり、組み込みの約束が履行されない場合、ユーザーが異議を申し立ててシーケンサーにステーキングペナルティを課すことができるようにする必要があります。ここでの課題は、トランザクションが含まれていないことを証明することです。そのためには、ユーザーが追加データを提供することが必要になる場合がありますが、シーケンサーはそのデータを保持するだけで済みます。したがって、完全な通話データまたは取引履歴を取得するためにデータ利用委員会を雇うために少なくとも SDR または検証を要求し、委員会はユーザーの要求に応じて非封じ込めの証拠 (事前に確認された取引) を提供できると想定するのが合理的です。

方向 3: 活断層からの迅速な復旧。個々のオペレーター システムでは、アクティブな障害が発生する可能性があります (Inscription イベント中に Arbitrum がダウンするなど)。同様の状況でサービスが中断されないシステムを設計できるでしょうか?ある意味、自己順序付けと状態提案を可能にする L2 は、長期的な活性障害に対する保証を提供します。短期的なアクティブ障害に対する回復力がより高いシングルオペレーターシステムは、現在十分に検討されていません。ここで考えられる解決策の 1 つは、活断層の削減を通じて責任を課すことです。もう 1 つの可能な解決策は、引き継ぎ前の遅延期間を単純に短縮することです (現在は約 1 週間に設定されています)。

結論は

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

フィードバックとディスカッションを提供してくれた Vitalik Buterin と Terry Chung、そして編集上のコメントを提供してくれた Diana Biggs に多大な感謝を申し上げます。