原著者: Kyle Samani、Multicoin Capital パートナー

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

過去 2 年間、ブロックチェーンのスケーラビリティに関する議論は「モジュール化と統合」という中心的なテーマに焦点が当てられてきました。

暗号通貨の議論では、「単一」システムと「統合」システムが混同されることが多いことに注意してください。統合システムとモジュール式システムに関する技術的な議論は多岐にわたります。40年の長い歴史。新しい議論とは程遠く、暗号通貨分野におけるこの会話は、歴史と同じレンズを通して組み立てられるべきです。

モジュール性と統合を考慮する場合、ブロックチェーンが行うことができる最も重要な設計上の決定は、スタックの複雑さをアプリケーション開発者にどの程度公開するかということです。ブロックチェーンの顧客はアプリケーション開発者であるため、最終的な設計の決定はアプリケーション開発者の立場を考慮する必要があります。

今日、モジュール性はブロックチェーンを拡張する主要な方法として広く歓迎されています。この投稿では、私はこの仮定に第一原理から疑問を投げかけ、文化的な通説とモジュールシステムの隠れたコストを解明し、過去 6 年間にわたるこの議論について考えた結論を共有します。

モジュール式システムは開発の複雑さを増大させる

モジュール式システムの隠れたコストの中で最も大きなものは、開発プロセスの複雑さの増加です。

モジュラー システムでは、アプリケーション開発者が自身のアプリケーションのコンテキスト (技術的な複雑さ) と他のアプリケーションとの相互作用のコンテキスト (社会的な複雑さ) の両方で管理しなければならない複雑さが大幅に増加します。

暗号通貨の文脈では、モジュラーブロックチェーンは理論的にはより専門化を可能にしますが、その代償として新たな複雑性が生まれます。この複雑さ (本質的に技術的および社会的性質の両方) がアプリケーション開発者に伝わり、最終的にはアプリケーションの構築が困難になります。

たとえば、OP スタックを考えてみましょう。現時点では、これが最も人気のあるモジュラー フレームワークのようです。 OP スタックは開発者に採用の選択を強制します Law of Chains(これにより多くの社会的複雑さが生じます)、またはフォークして個別に管理します。どちらのオプションも、ビルダーにとってダウンストリームの複雑さを大幅に引き起こします。フォークすることを選択した場合、新しい技術標準に準拠するためにコストを負担しなければならない他のエコシステムプレーヤー (CEX、法定通貨の参入者など) から技術サポートを受けることができますか?あなたが鎖の法則に従うことを選択した場合、今日と明日、どのような規則や制約が課せられるでしょうか?

出典: OSI モデル

最新のオペレーティング システム (OS) は、数百のサブシステムを含む大規模で複雑なシステムです。最新のオペレーティング システムは、上の図のレイヤー 2 ～ 6 を処理します。これは、アプリケーション開発者に公開されるスタックの複雑さを管理するためにモジュール式コンポーネントを統合する典型的な例です。アプリケーション開発者はレイヤー 7 より下のものを扱いたくないため、オペレーティング システムが存在します。オペレーティング システムは、アプリケーション開発者がレイヤー 7 に集中できるように、下位レイヤーの複雑さを管理します。したがって、モジュール性はそれ自体が目的ではなく、目的を達成するための手段であるべきです。

現在、世界中のすべての主要なソフトウェア システム (クラウド バックエンド、オペレーティング システム、データベース エンジン、ゲーム エンジンなど) は高度に統合されており、同時に多くのモジュール式サブシステムで構成されています。ソフトウェア システムは、パフォーマンスを最大化し、開発の複雑さを軽減するために高度に統合される傾向があります。ブロックチェーンについても同様です。

ちなみに、イーサリアムは、2011年から2014年のビットコインフォーク時代に生じた複雑さを軽減しています。モジュール化の支持者は、オープン システム相互接続 (OSI) モデルを強調し、データ可用性 (DA) と実行を分離する必要があると主張することがよくありますが、この議論は広く誤解されています。目前の問題を正しく理解すると、逆の結論が得られます。OSI は、モジュール型システムではなく、統合システムを支持する議論です。

モジュラーチェーンではコードをより速く実行できない

設計上、「モジュラー チェーン」の一般的な定義は、データ可用性 (DA) と実行の分離です。つまり、あるノード セットが DA を担当し、別のノード セット (複数のセット) が実行を担当します。ノード コレクションは重複する必要はありませんが、重複することは可能です。

実際には、DA と実行を分離しても、本質的にどちらのパフォーマンスも向上するわけではありません。むしろ、世界のどこかのハードウェアが DA を実行し、どこかのハードウェアが実行を実装する必要があります。これらの関数を分離しても、どの関数のパフォーマンスも向上しません。分離によって計算コストを削減できますが、それを削減できるのは一元化された実行によってのみです。

繰り返しになりますが、モジュール式アーキテクチャか統合アーキテクチャかに関係なく、どこかのハードウェアがその作業を行う必要があり、DA と実行を別のハードウェアに分離しても、本質的に速度が向上したり、システムの総容量が増加したりするわけではありません。

モジュール化により、複数の EVM をロールアップ方式で並行して実行できるようになり、実行を水平方向に拡張できるようになると主張する人もいます。これは理論的には正しいですが、この見方は実際には、システム全体のスループットをスケーリングするという文脈で DA と実行を分離するという基本的な前提ではなく、シングルスレッド プロセッサとしての EVM の制限を強調しています。

モジュール化だけではスループットは向上しません。

モジュール化によりユーザーのトランザクションコストが増加する

定義上、各 L1 と L2 は、独自の状態を持つ独立した資産台帳です。これらの個別の状態は、トランザクションのレイテンシーが長くなり、開発者とユーザーにとってより複雑な状況になりますが (LayerZero や Wormhole などのクロスチェーン ブリッジを介して) 通信できます。

資産台帳が増えるほど、すべてのアカウントのグローバルな状態がより細分化されます。これはチェーンや複数のチェーンにわたるユーザーにとって恐ろしいことです。状態の断片化は、次のような一連の結果をもたらす可能性があります。

• 流動性が低下し、取引のスリッページが増加します。

• 総ガス消費量の増加 (クロスチェーン取引では、少なくとも 2 つの資産台帳で少なくとも 2 つの取引が必要)。

• 資産台帳間の二重計算の増加 (その結果、システムの総スループットが減少します): Binance または Coinbase で ETH-USDC の価格が変化すると、すべての資産台帳の各 ETH-USDC プールに裁定取引の機会が現れます (簡単に想像できます) Binance または Coinbase で ETH-USDC 価格が変動するたびに、さまざまな資産台帳に 10 以上のトランザクションが存在する世界です。断片化された状態で価格の一貫性を維持することは、ブロック スペースの非常に非効率的な使用です)。

より多くの資産台帳を作成すると、特に DeFi に関連する場合に、これらすべての側面にわたるコストが大幅に増加することを認識することが重要です。

DeFi への主な入力は、オンチェーン状態 (つまり、誰がどの資産を所有しているか) です。チームがアプリチェーン/ロールアップを起動すると、アプリの複雑さ (ブリッジ、ウォレット、レイテンシー、クロスチェーン MEV など) を管理する開発者であれ、ユーザーであれ、自然に状態の断片化が生じ、これは DeFi にとって非常に有害です (スリッページ、決済遅延）。

DeFi にとって最も理想的な条件は、資産が単一の資産台帳で発行され、単一のステートマシン内で取引されることです。資産台帳が増えれば増えるほど、アプリケーション開発者が管理しなければならない複雑さが増し、ユーザーのコストも高くなります。

アプリのロールアップは開発者に新たな収益機会を生み出さない

AppChain/Rollup の支持者は、インセンティブがアプリ開発者を L1 や L2 上に構築するのではなくロールアップを開発するように誘導し、アプリ自体が MEV 価値を獲得できるようにすると主張します。ただし、アプリケーション ロールアップの実行が MEV をアプリケーション層トークンにキャプチャする唯一の方法ではなく、また、ほとんどの場合最良の方法でもないため、この考えには欠陥があります。アプリケーション層トークンは、MEV を自身のトークンにキャプチャして戻すために、ユニバーサル チェーン上のスマート コントラクト内のロジックをエンコードするだけで済みます。いくつかの例を考えてみましょう。

• 清算: Compound または Aave DAO が清算ボットに流れる MEV の一部を取得したい場合は、それぞれの契約を更新するだけで、現在清算人に流れている手数料の一部が新しいチェーンではなく独自の DAO に送られるようになります。 /ロールアップが必要です。

• オラクル: Oracle トークンは、バックランニング サービスを提供することで MEV をキャプチャできます。価格更新に加えて、オラクルは、価格更新直後に実行されることが保証されている任意のオンチェーン トランザクションにバンドルできます。したがって、オラクルはサーチャーやブロックビルダーなどにバックランニングサービスを提供することで MEV をキャプチャできます。

• NFT ミント: NFT ミントにはスキャルピング ボットが蔓延しています。これは、減少する利益の再分配をコード化するだけで簡単に軽減できます。たとえば、誰かが鋳造から 2 週間以内に NFT を再販しようとすると、収益の 100% が発行者または DAO に返されます。この割合は時間の経過とともに変化する可能性があります。

MEV をアプリケーション層トークンにキャプチャするための普遍的な答えはありません。ただし、少し考えれば、アプリケーション開発者は簡単に MEV をユニバーサル チェーン上の独自のトークンに取り込むことができます。まったく新しいチェーンを立ち上げる必要はまったくありませんが、開発者にとっては技術的および社会的複雑さがさらに増し、ユーザーにとっては財布と流動性のさらなる問題が生じます。

アプリケーション ロールアップではアプリケーション間の輻輳を解決できません

アプリチェーン/ロールアップは、人気のある NFT ミントなどの他のオンチェーン アクティビティによって引き起こされるガススパイクの影響をアプリが受けないようにするためだと多くの人が信じています。この見方は部分的には正しいですが、ほとんどが間違っています。

これは歴史的な問題であり、EVM のシングルスレッドの性質に根ざしたものであり、DA と実行が分離されていないことが原因ではありません。すべての L2 は L1 に料金を支払いますが、L1 の料金はいつでも増加する可能性があります。今年初めのミームコインの流行中、アービトラムとオプティミズムの取引手数料は一時的に10ドルを超えた。最近では、Worldcoin の立ち上げを受けて、Optimism の手数料も高騰しています。

料金のピークに対処する唯一の解決策は、1) L1 DA を最大化する、2) 料金市場を可能な限り調整することです。

L1 のリソースが制限されている場合、個々の L2 での使用量の急増が L1 に伝わり、他のすべての L2 に高いコストが課せられます。したがって、AppChain/Rollup はガススパイクの影響を免れることはできません。

多数の EVM L2 の共存は、料金市場をローカライズしようとする荒っぽい方法にすぎません。料金市場を単一の EVM L1 に入れるよりは優れていますが、根本的な問題は解決されません。解決策があることに気づいたとき、ローカライズ料金の市場の場合、論理エンドポイントは (L2 ごとの料金市場ではなく) 州ごとの料金市場です。

他のチェーンもこの結論に達しています。 Solana と Aptos は、手数料市場を自然にローカライズします。これには、それぞれの実行環境に対して何年にもわたる広範なエンジニアリング作業が必要でした。モジュール化の支持者のほとんどは、ローカル料金市場エンジニアリングを構築することの重要性と困難さを著しく過小評価しています。

複数のチェーンを起動しても、開発者は実際のパフォーマンスの向上を実現することはできません。トランザクション量を増加させるアプリケーションがある場合、すべての L2 チェーンのコストが影響を受けます。

柔軟性は過大評価されている

モジュラーチェーンの支持者は、モジュラーアーキテクチャの方がより柔軟であると主張します。この声明は明らかに真実ですが、それは本当に重要でしょうか?

私は 6 年間、汎用 L1 では意味のある柔軟性が得られないアプリケーション開発者を見つけようと努めてきました。しかし、これまでのところ、3 つの非常に具体的な使用例以外では、柔軟性がなぜ重要なのか、そして柔軟性がスケーリングにどのように直接役立つのかを明確に説明できる人はいません。私が柔軟性が重要だと考える具体的な使用例は次の 3 つです。

「ホット」状態を利用するアプリケーション。ホット状態は、リアルタイムで一連の操作を調整するために必要な状態ですが、チェーンに一時的に送信されるだけであり、永久に存在するわけではありません。熱状態の例をいくつか示します。

• dYdX や Sei などの DEX での指値注文 (多くの指値注文は最終的にキャンセルされます)。

• dFlow で注文フローをリアルタイムで調整および識別します (dFlow は、マーケットメーカーとウォレット間の分散型注文フロー マーケットプレイスを促進するプロトコルです)。

• 低レイテンシのオラクルである Pyth などのオラクル。 Python は、独立した SVM のチェーンとして実行されます。 Python は非常に多くのデータを生成するため、コア Python チームは、高頻度の価格更新をスタンドアロン チェーンに送信し、必要に応じてワームホールを使用して価格を他のチェーンにブリッジすることが最善であると判断しました。

コンセンサスチェーンを変更します。最良の例は、Osmosis (バリデーターに送信される前にすべてのトランザクションが暗号化される) と Thorchain (支払われた手数料に基づいてブロック内のトランザクションが優先される) です。

何らかの方法で、Threshold Signature Scheme (TSS) のインフラストラクチャを悪用する必要があります。この例としては、Sommelier、Thorchain、Osmosis、Wormhole、Web3 Auth などがあります。

Pyth と Wormhole を除いて、上記のすべての例は Cosmos SDK を使用して構築され、スタンドアロン チェーンとして実行されます。これは、ホット状態、コンセンサス変更、およびしきい値署名スキーム (TSS) システムの 3 つのユース ケースすべてに対する Cosmos SDK の適用性とスケーラビリティを雄弁に物語っています。

ただし、上記の 3 つのユースケースの項目のほとんどはアプリケーションではなく、インフラストラクチャです。

Python と dFlow はアプリケーションではなく、インフラストラクチャです。 Sommelier、Wormhole、sei、Web3 Auth はアプリケーションではなく、インフラストラクチャです。その中で、ユーザー向けアプリケーションの特定のタイプは DEX (dYdX、Osmosis、Thorchain) の 1 つだけです。

6 年間、私は Cosmos と Polkadot の支持者に、彼らが提供する柔軟性から生じるユースケースについて尋ねてきました。いくつかの推論を行うのに十分なデータがあると思います。

まず、インフラストラクチャのサンプルは、低価値のデータ (ホット状態など、ホット状態の重要な点はデータが L1 にコミットされないことです) を生成しすぎるか、何らかの処理を行うため、ロールアップとして存在すべきではありません。資産台帳に意図的に関連付けられている状態更新関連機能 (すべての TSS ユースケースなど)。

第 2 に、私がこれまでに見た中で、コア システムの設計を変更することでメリットが得られる唯一の種類のアプリケーションは DEX です。 DEX は MEV で溢れており、ユニバーサル チェーンは CEX のレイテンシーに匹敵できないためです。コンセンサスはトランザクション実行品質と MEV の基礎であるため、コンセンサスに基づく変更は、当然のことながら DEX に多くのイノベーションの機会をもたらします。ただし、この記事で前述したように、スポット DEX への主な入力は取引される資産です。 DEX は資産をめぐって競合し、したがって資産発行者をめぐって競合します。このフレームワークの下では、資産発行者が資産を発行する際に主に考慮するのは、DEX 関連の MEV ではなく、一般的なスマート コントラクト機能と、この機能を開発者のそれぞれのアプリケーションに組み込むことであるため、スタンドアロンの DEX チェーンが成功する可能性は低いです。

ただし、デリバティブ DEX は資産発行会社をめぐって競争する必要はなく、価格を供給するために主に USDC やオラクル マシンなどの担保に依存しており、基本的にユーザー資産を住宅ローン デリバティブのポジションに固定する必要があります。したがって、スタンドアロンの DEX チェーンという意味では、dYdX や Sei などのデリバティブに焦点を当てた DEX に適用できる可能性が最も高くなります。

ゲーム、DeSoc システム (Farcaster や Lens など)、DePIN プロトコル (Helium、Hivemapper、レンダー ネットワーク、DIMO、Daylight など)、サウンド、NFT 交換など、現在存在する一般的な統合 L1 アプリケーションについて考えてみましょう。 。これらのどれも、コンセンサスの修正によってもたらされる柔軟性から特に恩恵を受けておらず、それぞれの資産台帳には、低手数料、低レイテンシ、スポット DEX へのアクセス、ステーブルコインへのアクセス、および法定チャネル（CEX など）。

ユーザー向けアプリケーションの大部分が、前の段落で列挙したものと同じ一般要件を備えているとある程度言える十分なデータが得られたと思います。一部のアプリケーションはスタック内のカスタム機能を使用してマージンで他の変数を最適化できますが、通常、これらのカスタマイズによるトレードオフには価値がありません（ブリッジの増加、ウォレットのサポートの減少、インデックス作成/クエリプログラムのサポートの減少、法定チャネルの削減など）。 ）。

新しい資産台帳を展開することは柔軟性を実現する 1 つの方法ですが、価値が付加されることはほとんどなく、ほとんどの場合、技術的および社会的な複雑さが生じ、アプリケーション開発者にとって最終的なメリットはほとんどありません。

拡張 DA は再住宅ローンを必要としません

また、モジュラーの支持者がスケーリングの文脈で再仮説について語るのを聞くこともできます。これはモジュラーチェーンの支持者によって行われた最も推測的な議論ですが、議論する価値のある議論です。

それは大まかに、再仮説化（例えば、EigenLayerのようなシステムを通じて）により、暗号エコシステム全体がETHを無制限に再仮説化することができ、無制限の数のDAレイヤー（例えば、EigenDA）と実行レイヤーを可能にする、と述べています。そのため、ETHの付加価値を確保しつつ、あらゆる面からスケーラビリティを解決します。

現状と理論上の将来の間には大きな不確実性があるにもかかわらず、私たちはすべての層別の仮定が宣伝どおりに機能することを当然のことと考えています。

現在のイーサリアムの DA は約 83 KB/s です。今年後半に EIP-4844 が導入されると、その速度はおよそ 2 倍の約 166 KB/秒になる可能性があります。 EigenDA はさらに 10 MB/s を追加できますが、異なるセキュリティ前提セットが必要です (すべての ETH が ReigenDA に再仮説されるわけではありません)。

比較すると、Solana は現在、約 125 MB/秒 (ブロックあたり 32,000 シュレッド、シュレッドあたり 1,280 バイト、1 秒あたり 2.5 ブロック) の DA を提供します。 Solana は Ethereum や EigenDA よりもはるかに効率的です。さらに、によると、ネルソンの法則, ソラナのDAは時間の経過とともにスケールします。

再担保やモジュール化を通じて DA を拡張する方法は数多くありますが、これらのメカニズムは今日ではまったく必要なく、明らかな技術的および社会的複雑さをもたらします。

アプリケーション開発者向けに構築

長年考えた結果、モジュール化それ自体が目標であってはいけないという結論に達しました。

ブロックチェーンは顧客 (つまり、アプリケーション開発者) にサービスを提供する必要があるため、開発者が世界クラスのアプリケーションの構築に集中できるように、ブロックチェーンはインフラストラクチャ レベルの複雑さを抽象化する必要があります。

モジュール性は素晴らしいです。しかし、勝利を収めるテクノロジーを構築するための鍵は、スタックのどの部分を統合する必要があり、どの部分を他の部分に任せるかを理解することです。現状では、DA と実行を統合するチェーンは本質的に、よりシンプルなエンドユーザーと開発者のエクスペリエンスを提供し、最終的にはクラス最高のアプリケーションのためのより良い基盤を提供することになります。