Vitalik氏のブログ記事を解説：Web3インフラの次のステップはラッピングか、それともスケーリングか？

2023.10.27

共有先

TechFlow厳選深潮セレクト

Vitalik氏のブログ記事を解説：Web3インフラの次のステップはラッピングか、それともスケーリングか？

本稿では、Web3インフラが「ラッピング vs 拡張」においてどのような設計上の選択を行っているかについて考察し、パブリックチェーンインフラにおけるこの問題に対する個人的な見解を述べる。

2023.10.27 - 07:47:32

Vitalik

Web3業界の深掘り報道に専念し潮流を洞察

著者：CP、Artela CTO兼共同創業者

先週、Vitalikはブログ「Should Ethereum be okay with enshrining more things in the protocol?」を発表し、イーサリアムが上位層アプリケーションに必要な基盤機能をプロトコルに「組み込む（enshrine）」ことについての考察を共有しました。また、より多くの上位層アプリケーションが必要とする基盤機能をどのように組み込むかというフレームワークの構築についても議論しています。

これは典型的なプラットフォーム型システムが直面する重要な課題です。すなわち、開発チームが上位層の重要な機能を底層に「組み込む」べきか、それともアプリケーション開発者がアプリ層でそれらの機能を「拡張（extend）」すべきかという選択です。インフラストラクチャーが大規模なスケーリングの前夜を迎える際、「組み込み vs 拡張」の設計は極めて重要であり、それが大規模普及を実現できるかどうかの鍵となる設計の一つです。

ここ半年間、主要ないくつかのインフラプロジェクトは重要な技術アップデートを発表しました。Uniswapはカスタム機能を持つプールを可能にするHookメカニズムを導入し、MetaMaskウォレットはユーザー拡張機能を追加できるSnapsをリリースしました。そして今やイーサリアムも「組み込み vs 拡張」というジレンマに直面しています。

本稿では、Web3インフラストラクチャーにおける「組み込み vs 拡張」に関する設計上の選択と、パブリックチェーンインフラがこの問題に対して私が抱く考えについて探ります。

イーサリアムが直面している問題：組み込みか、それとも拡張か

「組み込み vs 拡張」という問題に関して、イーサリアムはこれまで一貫して「拡張」を選んできました。

イーサリアムの設計哲学はUnixに由来しており、極めてシンプルかつ汎用的なカーネルを作り、ユーザーのニーズはアプリケーション層で開発者が実装することを目指しています。これを支える中心技術がEVMです。チューリング完全なスマートコントラクト言語により、開発者はアプリケーション層で独自のアプリを自由に構築できます。

このモデルは理にかなっているように見えますが、「分散化されたUnix」としては必ずしもうまく機能しません。その大きな理由の一つは、EVMが言う「チューリング完全性」が実際の使用においてはそれほど「完全」ではない点です。Gasメカニズムと限られたOpcodeの下では、プログラムは有限のステップ内で限られたOpcodeを使ってタスクを完了させる必要があり、これがアプリケーションの自由度を大きく制限しています。Web2のプログラムがUnixのユーザーレイヤーでほぼ何でもできたのに対し、多くの高度なdAppが求める能力はEVMでは満たせません。RollupであろうとAAウォレットであろうと、L1を変更しない限り、それらは動くことは動きますが、あくまでMVP製品にとどまり、効率性や体験は目標とは大きくかけ離れています。

開発者の前にある選択肢はEIPです。つまり、自らが依存する重要な機能を、イーサリアムのコアチームが底層に「組み込み」てもらい、アプリケーション層で利用できるようにすることです。

EVMによる「拡張」だけではアプリケーションの発展ニーズを満たせないため、今こそ「組み込み」について真剣に検討すべき時なのです。

しかし、分散化されたインフラストラクチャーにとって、上位層アプリケーションの機能を「組み込む」ことは簡単ではありません。単なるコードの統合ではなく、分散化システム最大の難題である「ガバナンス」が背景にあります。「組み込み」とは、コアチームが開発・メンテナンスに加えて、これらの機能に対するガバナンス責任も負うことになり、イーサリアムの信頼モデルを損なうリスクや、持続可能性に悪影響を与える可能性を内包します。

そのため、最終的に見られる結果は明らかです。コアチームが「組み込み」可能な機能の数は限られており、さらにその機能がコミュニティの大半の合意を得るほど重要でなければならず、実装スピードも高くなく、年単位でかかる場合があります。

同時に、これはつまり、あなたが求めている機能が広範な合意を得られない基盤機能でない限り、イーサリアムはそれを受け入れず、あるいは試みさえも許されない可能性があるということです。その結果、独自のアプリチェーンを構築せざるを得ず、高い開発・運用コストを負い、スマートコントラクト世界の素晴らしいコンポーザビリティを失ってしまうかもしれません。

「組み込み vs 拡張」という問題に関して、イーサリアムにはまだ明確な解決策がありません。Vitalikが述べたように、「組み込み」を「秩序立てて推進する」方法、つまりどの機能を組み込み対象とし、どうやってそれを実装するかというフレームワークを模索中です。

Unixから他に学べること？ネイティブエクステンション！

「組み込み vs 拡張」という問題において、イーサリアムは主にEVMの拡張能力不足ゆえに、コアチームが「組み込み」作業を行う補完的役割を担っています。視点を変えて考えてみましょう。アプリケーション層の拡張性を高めれば、多くの問題が解決されるのではないでしょうか。例えば、開発者が自身のアプリに必要な底層機能を自由にカスタマイズでき、底層チームの「組み込み」を待つ必要がなくなるのです。

また、イーサリアムがUnixから多くの設計哲学を採用していることも知られています。そこで、今一度Unixの体系からアイデアを探ってみましょう。

Unixをベースにした商用オペレーティングシステムはPC市場を対象としており、アプリケーション層での多様なニーズに加え、企業利用シーンからの拡張要求にも直面しています。しかし、こうした商用OSのコアチームはそれほど高い「組み込み」負担を背負っていません。なぜなら、提供される拡張性が十分に高く、ほとんどの機能はユーザー側で自分で解決できるからです。

Mac OS Xを例に挙げると、通常のOSはカーネルモードとユーザーモードに分かれ、アプリケーションはユーザーモードで動作し、カーネルモードが提供する機能を利用します。簡単に（ただし完全ではない）比較すれば、EVM上でのスマートコントラクトはすべてユーザーモードのアプリに相当し、イーサリアムのプロトコル層がカーネルモードに相当します。

しかしMac OS Xでは、アプリ開発者が独自にプログラムをカーネルモードにデプロイし、カーネル機能を拡張することが可能であり、Mac OS Xのコアチームが個別に「組み込み」を行う必要はありません。Mac OS Xが提供する主要な仕組みは「カーネルエクステンション」と「システムエクステンション」であり、これらは一定のセキュリティモードの下で開発者がカーネル拡張を開発し、より高い権限の機能を利用して、純粋なユーザーモードアプリでは実現できない機能を構築することを可能にします。

私たちが得られる示唆は、「カーネルエクステンション」というモデルが「分散化されたUnix」においても可能かどうかです。そのモデルは以下の図の通りです。

ブロックチェーンプロトコル上で、「スマートコントラクト」に加えて、もう一種類のプログラム「ネイティブエクステンション（Native Extension）」をサポートすることです。それは

1）スマートコントラクトよりも多くの底層プロトコルAPIへのアクセス権を持つ

2）その実行環境の効率がEVMよりも桁違いに高い

3）底層プロトコルとの間に隔離性を持ち、底層プロトコルの安定性に影響を与えない

4）したがってガバナンス面でも底層チームがメンテナンスする必要はなく、アプリ開発チームが自身でデプロイ・管理を行う

もし技術的にこの四つの条件を満たすことができれば、多くの問題が解決しそうです。開発者は底層チームの「組み込み」を待つことなく、自身のアイデアに基づいて必要な底層機能をカスタマイズできるようになります。

このパラダイムを仮に「ネイティブエクステンション（Native Extension）」パラダイムと呼び、既存のWeb3インフラにその影が見えるか見てみましょう。

フック、フック、フック…

ソフトウェアの世界では、偉大な仕組みは往々にして偉大なユースケースによって生み出されます。DeFiインフラであるUniswapは、「プラットフォーム」へ移行する重要な段階にあり、「組み込み vs 拡張」の特性において驚くべき設計を提示しました。それが「フック（Hook）」です。開発者は許可なしにフックを利用してプールに拡張機能を追加でき、さまざまな機能を持つプール体験を実現できます。これにより、コアチームが常に「組み込み」で機能をアップグレードする必要がなくなります。

フックの仕組みは前述のネイティブエクステンションと多くの点で似ています。

・フックはプールの実行ライフサイクル中に介入でき、ランタイムデータにアクセスできるため、より高度なアクセスレベルを持つ

・フックとプールは独立したコントラクトであり、フックのセキュリティがプールに影響しない

・ガバナンス面では、フックは第三者開発者による無許可での開発・デプロイが可能であり、グローバルに有効化されるわけではなく、異なるプールがニーズに応じて異なるフックをバインドすることでカスタム機能を有効化します。

フックは小さくて美しい設計であり、プールの拡張性の問題を解決しました。アプリケーション層のインフラがまずこうした概念を適用した例ですが、次に複雑な底層プロトコル（L1/L2）の考え方を見てみましょう。

新規パブリックチェーンプロジェクトの拡張のアプローチ

イーサリアムが苦戦している中、L1の拡張を目指すL2プロジェクトはどのような考えを持っているでしょうか。

Arbitrum Stylus：開発者が自らプリコンパイルコントラクトを「組み込む」！

ご存知の通り、EVMは「プリコンパイルコントラクト」によって機能を拡張できます。そのコードはEVM内ではなくノードに統合され、底層で実行されます。例えば新しい暗号アルゴリズムを追加する場合、計算が複雑かつ高価なため、プリコンパイルコントラクトとして実装され、アプリケーションコントラクトがそれを呼び出して利用できます。しかし、プリコンパイルコントラクトの追加権限は開発者に開放されておらず、EIPを通じてイーサリアム開発チームが「組み込み」を行う必要があります。

Arbitrum Stylusは「EVM+」パラダイムを提案しました。L2はEVM同等性／互換性を追求しつつ、開発者がEVMの制約を突破し、無許可でより高性能なプリコンパイルコントラクトをデプロイできるようにします。その実現方法は、実行層にWASM実行環境を追加し、WASMコントラクトを動的にロードして実行することです。WASMはEVMよりも桁違いの効率を提供し、複数のプログラミング言語もサポートします。

これはイーサリアムの「組み込み」問題を最適化する実装の一つです。EVMの拡張ニーズはもはや底層チームの「組み込み」を待つ必要がなく、底層チームは実行層の拡張環境の維持に集中し、新機能の導入・開発・ガバナンスはアプリ層に委ねられます。

ただしStylusはまだ初期段階であり、このモデルが直面するさらなる課題はまだ顕在化しておらず、解決できる問題も限定的です。現状では動的なプリコンパイルコントラクトの「組み込み」のみをサポートしており、イーサリアムが直面する他の「組み込み」課題には対応していません。しかし嬉しいことに、これはネイティブエクステンションパラダイムに近い実装の一つであり、次世代インフラの代表として、将来のスケーリングに伴う「組み込み」問題に対処する拡張性設計を導入し、長期的なエコシステム発展を考慮している点が評価できます。

ネイティブエクステンション：「モジュラーな組み込み」のアプローチ！

Web2およびWeb3のこれらのインフラプロジェクトを振り返ると、「組み込み vs 拡張」という問題に対して明確な方向性が見えてきます。それは、拡張性を高めることで、開発者がモジュラーな方法で自身が必要とする機能を「組み込み」できるようにすることです。

これがネイティブエクステンションパラダイムがインフラストラクチャーにおいて果たす重要な役割です。インフラの拡張性を高めることで、選択権を再び開発者に還元し、コアプロトコルの安定性を損なうことなく、開発者が自由にモジュラーな方法で機能を「組み込み」・拡張できるようにします。

イーサリアムは「組み込み」の効率を高めようとしています。Arbitrum Stylusはプリコンパイルコントラクトの解放を進めています。さらに先を見据えると、パブリックチェーンはネイティブエクステンションパラダイムを通じてアプリ層の創造性を完全に解放できるでしょう。ちょうどUniswap V4が私たちに与えた印象のように。

ネイティブエクステンションパラダイムに基づく新規L1パブリックチェーン：Artela

ここで視点を切り替えます。「我々」とは、私がCTOを務めるチームArtelaを指します。この問題に対する私たちの考えと行動を紹介します。

Artelaブロックチェーンでは、EVMに加えてWASM実行環境も搭載しています。一方で、これは状態を持つプログラム（stateful program）を実行でき、状態付きのプリコンパイルコントラクトのようなものです。さらにその上に、ブロックやトランザクション処理の複数のライフサイクルポイントでトリガーされる、フックに似たメカニズムをサポートしています。つまり、Arbitrum Stylusのようにプリコンパイルコントラクトの「組み込み」に留まらず、トランザクションやブロックの実行フローをカスタマイズし、より広範な機能の「組み込み」を実現できます。例えば、トランザクション検証フェーズでWASMのネイティブエクステンションを起動し、新しいアルゴリズムでトランザクションを識別・検証することが可能です。これらのフックはArtelaでは「ジョインポイント（Join Point）」と呼ばれ、これらのネイティブエクステンションはスマートコントラクトとは呼ばず、「アスペクト（Aspect）」と呼ばれます。これはAoP（アスペクト指向プログラミング）の概念に近く、実行中のブロックチェーンシステム内で、各ジョインポイントに動的に新機能を挿入します！

具体的な例を挙げます。私たちは投資家やWeb2機関と交流し、「大規模資産をWeb3に導入する最大の障壁は何ですか？」という問いに対して、最も多く上がった答えは「セキュリティ問題」でした。Web2レベルのリスク管理技術は数十億ドル規模の資産を守っていますが、それがWeb3の技術スタックに入りづらいのです。NASAの宇宙分野出身のCarlも同様の意見を表明しています。「なぜRuntime ProtectionとAspectが必要なのか」。

Runtime Protectionはセキュリティリスク管理の核心的手法です。現在のWeb3では、静的監査、形式的検証、リアルタイム監視、トランザクションのフロントランニング対策など、強力なセキュリティ企業が存在します。一見するとすべての手段が整っているように見えますが、Web2レベルのリアルタイムリスク管理にはまだ遠く及んでいません。根本的な問題は、mempool周辺のセキュリティ手段に限界があることです。トランザクションが一度mempoolを通過してしまうと、その後の対応はできません。mempool以降のトランザクション実行フェーズに拡張性があれば、セキュリティ専門家がruntimeレベルのセキュリティポリシーをデプロイでき、セキュリティレベルはさらに一段階上がります。アスペクトは、開発者に実行層へのセキュリティ拡張能力を提供するのです！

開発者は自身のプロジェクト専用のアスペクトをデプロイし、必要なプロトコル層機能をカスタマイズできます。例えば、実行時のセキュリティ強化を行い、取引が大量の資金を盗まれる可能性がある場合、アスペクト内で阻止されます。

開発者は共通のアスペクトをデプロイし、複数のプロジェクトが再利用可能な基盤機能を「組み込み」することもできます。例えば、特定のアルゴリズムと取引タイプを実装したアスペクトにより、AAウォレットのプログラマビリティとコンポーザビリティが高まり、他の開発者もこのアスペクトを有効化して自身のプロジェクトにこの底層機能を利用できます。

Artelaにとって、私たちの考えは次第に明確になってきました。

・開発者がアプリレイヤーでネイティブエクステンションを通じて無許可で問題を解決できるようにし、底層パブリックチェーンチームの「組み込み」を待つ必要がないようにする

・Web2出身の大手機関・大口資金がブロックチェーンに安心して参加できるようにする（Web2レベルのランタイムリスク管理を導入することで）

・開発者が良い環境で既存の枠を超えたイノベーションを行えるようにする（EVMはすぐに頭打ちになるが、EVM＋ネイティブエクステンションにはより大きな可能性がある）

・オールチェーンゲーム、RWAなど、より多くのビジネスロジックをブロックチェーンに持ち込みたいdAppにとって理想的なホームを提供する

私たちは、イーサリアムがアプリ固有の機能をどう「組み込む」かという段階にあり、その「組み込み」圧力を解放し、創造性を再び開発者に戻す計画はまだ見えていません。分散化アプリの革新を推進しようとする次世代の潜在的イノベーターたちにとって、この状況は非常に窮屈です。彼らは堅牢な分散化ネットワークを必要としている一方で、思うように活動を展開できません。だからこそ、私たちはネイティブエクステンションパラダイムに基づき、新たなL1パブリックチェーンを構築することに尽力しているのです。インフラがイノベーションの足を止めてはいけないからです。