Vitalikのブログ解読：Web3インフラの次のステップはパッケージ化か拡張か？

原文タイトル：《封装还是扩展？探讨 Web3 基础设施的下一站------关于 Vitalik Enshrinement 博客的解读》

原文著者：CP，Artela CTO \& co-founder

Vitalikは先週、ブログ《Should Ethereum be okay with enshrining more things in the protocol?》を発表し、Ethereumの「封装」（enshrine）に必要な基盤機能についての考察を共有し、より多くの上層アプリケーションに必要な基盤機能を封装するためのフレームワークを提案する方法を探討しました。

これは典型的なプラットフォーム型システムが直面する重要な問題です：チームが重要な上層アプリケーション機能を「封装」して基盤に組み込むのか、それともアプリケーション開発者がアプリケーション層でこれらの機能を「拡張」（extend）するのか。基盤インフラが大規模な拡張の前夜に達したとき、「封装 vs 拡展」の設計は非常に重要であり、それが大規模なアプリケーションに影響を与える重要な設計の一つとなります。

ここ半年間、いくつかの基盤インフラが重要な技術更新を発表しました：UniswapはHookメカニズムを導入し、カスタマイズ機能を持つプールを拡張することをサポートしました；MetaMaskウォレットはSnapsを導入し、開発者がユーザー拡張を追加できるようにしました；Ethereumも今、「封装 vs 拡展」の難題に直面しています。

この記事では、Web3基盤インフラが「封装 vs 拡展」の設計選択についてどのように考えているか、また公チェーン基盤インフラに関する私の考えを探討します。

Ethereumはどのような問題に直面しているのか？封装 or 拡展

「封装 vs 拡展」の問題において、Ethereumは常に「拡展」を選択してきました。

Ethereumの設計哲学はUnixに由来し、極めてシンプルで汎用的なカーネルを作成し、ユーザーのニーズをアプリケーション層で開発者が実現することを目指しています。Ethereumがこれを実現するための重要な技術はEVMです。チューリング完全なスマートコントラクト言語により、開発者はアプリケーション層でそれぞれのアプリケーションをカスタマイズできます。

このモデルは一見合理的に見えますが、「去中心化のUnix」ではあまりうまく機能しません。その重要な理由の一つは、EVMのいわゆるチューリング完全性が、実際の使用においてそれほど「完全」ではないことです。ガスメカニズムと限られたopcodeの下で、プログラムは限られたステップ内で限られたopcodeを使用してタスクを完了する必要があり、この点が大きく制限され、アプリケーションがWeb2プログラムのようにUnixのユーザー層で自由に機能することが難しくなります。多くの高度なdAppが必要とする能力をEVMは満たせません。RollupやAAウォレットにおいても、L1を変更せずに動作することはできても、常にMVP製品であり、効率と体験は目標から遠く離れています。

開発者が直面する選択肢はEIPです。重要な機能をEthereumのコアチームに「封装」してもらい、アプリケーション層で使用できるようにすることです。

EVMに基づく「拡展」ではアプリケーションの発展ニーズを満たせず、今彼らは「封装」を真剣に考える必要があります。

しかし、去中心化の基盤インフラが上層アプリケーション機能を封装するのは簡単ではありません。それは単にコードを統合するだけではなく、去中心化システムの最大の課題であるガバナンスが関わっています。「封装」は、コアチームが開発とメンテナンスに加えて、これらの機能のガバナンス作業も担うことを意味し、同時にEthereumの信頼モデルを弱めるリスクを伴い、持続可能な発展に影響を与える可能性があります。

したがって、最終的な効果は非常に明確です：コアチームが「封装」できる機能の数は限られており、その機能の重要性はコミュニティの広範な合意を得る必要があります。最後に、その実現効率はそれほど高くなく、数年かかることが予想されます。

同時に、必要な機能が広く合意されていない基盤機能である場合、Ethereumはあなたを受け入れることができないかもしれません。あなたの試みも受け入れられないかもしれず、その結果、自分自身でアプリケーションチェーンを構築することを選択し、高い開発と運営コストを負担し、スマートコントラクトの世界の組み合わせの美しさを失うことになるかもしれません。

「封装 vs 拡展」の問題において、Ethereumはまだ明確な解決策を持っていません。「封装」を「秩序立てて進める」方法、つまりVitalikが言及したように、彼らはまだ封装するべき機能の目標を特定し、それらをどのように封装するかのフレームワークを探求しています。

Unixから何を学べるか？Native Extension！

「封装 vs 拡展」の問題において、Ethereumは主にEVMの拡張能力不足が原因で、コアチームが封装を行う必要が生じています。別の視点から考えてみましょう。アプリケーション層の拡張性を高めることができれば、多くの問題を解決できるのではないでしょうか？例えば、アプリケーション開発者が自分の考えに基づいて必要な基盤機能をカスタマイズできるようにし、基盤チームが封装するのを待つ必要がなくなるのです。

私たちは、EthereumがUnixから多くの設計哲学を吸収していることを知っています。それでは、Unixシステムの中で考えを探してみましょう。

Unixに基づく商用オペレーティングシステムは、PC市場を対象としており、アプリケーション層の多様なニーズや企業使用シーンからの拡張ニーズに直面しています。しかし、これらの商用オペレーティングシステムでは、コアチームに「封装」の負担があまりなく、アプリケーションに提供される拡張性が十分に高く、大部分の機能をユーザー自身が解決できるようになっています。

Mac OS Xを例に挙げると、一般的なオペレーティングシステムはカーネルモードとユーザーモードを区別し、ユーザーアプリケーションは一般的にユーザーモードで実行され、カーネルモードプログラムが提供する機能を使用します。簡単（しかし完全ではない）な比較として、EVM上のスマートコントラクトはユーザーモードのアプリケーションに相当し、Ethereumプロトコル層はカーネルモードに相当します。

しかし、Mac OS Xはアプリケーション開発者が自らプログラムをカーネルモードにデプロイし、カーネルモードの機能を拡張できることを許可しており、Mac OS Xのコアチームがケースバイケースで封装する必要はありません。Mac OS Xが提供するコアメカニズムは「カーネル拡張」と「システム拡張」であり、これらの拡張により、開発者は一定の安全モードでカーネル拡張を開発し、より高い権限の機能を使用して、純粋なユーザーモードアプリケーションでは実現できない機能を開発できます。

私たちが得たインスピレーションは、「カーネル拡張」というモデルが「去中心化のUnix」で機能するかどうかです。そのモデルは以下のようになります。

ブロックチェーンプロトコルでは、「スマートコントラクト」をサポートするだけでなく、もう一つのプログラム「Native Extension」をサポートしています。

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

2）その実行環境の効率はEVMよりも桁違いに向上する

3）基盤プロトコルと隔離されており、基盤プロトコルの安定性に影響を与えない

4）したがって、ガバナンス面では基盤チームによって維持される必要はなく、アプリケーションチームによって維持される

このモデルが技術的に上記の4つの点を満たすことができれば、多くの問題を解決できるようです：アプリケーション開発者は自分の考えに基づいて必要な基盤機能をカスタマイズでき、基盤チームが封装するのを待つ必要がなくなります。

このパラダイムを「Native Extension」パラダイムと呼び、次に既存のWeb3基盤インフラの中にその影を探してみましょう。

Hook, Hook, Hooks…

ソフトウェアの世界では、偉大な車輪はしばしば偉大なシーンによって生み出されます。DeFi基盤インフラのUniswapは、「プラットフォーム」になるための重要な段階にあり、「封装 vs 拡展」の特性において驚くべきデザインを提供しました：Hook。これは、開発者が許可なしにHookを利用してプールに拡張を追加し、多様なプール体験を実現できるようにし、コアチームが常に「封装」を通じて機能をアップグレードする必要がなくなります。

Hookのメカニズムは、上記のNative Extensionの複数の条件に似ています：

· Hookはプールの実行ライフサイクルに切り込むことができ、実行時データにアクセスできるため、より高度なアクセスレベルを持つ

· Hookとプールは独立したコントラクトであり、Hookの安全性はプールに影響を与えない

· ガバナンス面では、Hookは第三者の開発者によって許可なしに開発・デプロイされ、全体的にアクティブではなく、異なるプールが必要に応じて異なるHookをバインドしてカスタマイズ機能を起動する

Hookは小さくて美しいデザインであり、プールの拡張性の問題を解決します。アプリケーション層の基盤インフラはこれらの概念を先駆けて適用しました。次に、より複雑な基盤プロトコル（L1/L2）の考え方を見てみましょう。

新しい公チェーンプロジェクトの拡張思考

Ethereumが困難に直面している中、Layer1の拡張に取り組むLayer2プロジェクトはどのような考えを持っているのでしょうか。

Arbitrum Stylusは、アプリケーション開発者が自らプリコンパイルコントラクトを封装できるようにします！

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

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

これはEthereumの「封装」問題を最適化する実現の一つとなります。EVMの拡張ニーズはもはや基盤チームの封装を待つ必要がなく、基盤チームはその実行層拡張環境のメンテナンスに集中し、新機能の導入、開発、ガバナンスなどはアプリケーション層に任せることができます。

ただし、Stylusはまだ初期段階にあり、このモデルにはさらなる課題があり、解決できる問題は限られています。現在、動的にプリコンパイルコントラクトを封装することしかサポートされておらず、Ethereumはプリコンパイルコントラクト以外にも多くの封装の難題に直面しています。しかし、嬉しいことに、これは私たちが見ることができるNative Extensionパラダイムの実現に近づいている一例です。新世代の基盤インフラの代表として、拡張性の設計を導入し、エコシステムの将来的な規模化に直面する「封装」問題を解決することを考慮しています。

Native Extension：モジュール化封装のアプローチ！

Web2とWeb3のこれらの基盤プロジェクトを振り返ると、「封装 vs 拡展」という問題に対して明確な考え方が見えてきます。それは、拡張能力を高めることで、開発者が自分たちの必要な機能をモジュール化の方法で封装できるようにすることです。

これがNative Extensionパラダイムが基盤インフラにおいて果たす重要な役割です。基盤インフラの拡張能力を高めることで、選択権を開発者に戻し、コアプロトコルの安定性に影響を与えずに、開発者が自由にモジュール化の方法で機能を封装し、拡張できるようにします。

Ethereumは「封装」の効率を高めようとしていますが、Arbitrum Stylusはプリコンパイルコントラクトの解放に取り組んでいます。さらに遠くを見れば、公チェーンはNative Extensionパラダイムを通じてアプリケーション層の創造性を完全に解放できる可能性があります。まるでUniswap V4が皆さんに与えた感覚のように。

Native Extensionパラダイムに基づく新しいL1公チェーン：Artela

ここで視点を切り替えます。「私たち」とは、私がCTOとして所属するチームArtelaを指します。この問題に関する私たちの考えと行動を共有します。

Artelaブロックチェーンでは、EVMに加えてWASM実行環境も設置しています。一方では、状態を持つプログラムを実行でき、状態を持つプリコンパイルコントラクトに似ています。また、その上にHookに似たメカニズムをサポートし、ブロックとトランザクション処理の複数のライフサイクルノードで実行をトリガーできます。つまり、これは単にArbitrum Stylusのようにプリコンパイルコントラクトを封装するためだけではなく、トランザクションとブロックの実行フローをカスタマイズし、より広範な機能の封装を実現します。例えば、トランザクション検証段階でWASMのNative Extensionをトリガーし、新しいアルゴリズムを使用してトランザクションを識別し、検証します。これらのHookはArtelaではJoin Pointと呼ばれ、これらのNative ExtensionはSmart Contractとは呼ばれず、Aspect（アスペクト）と呼ばれます。これはAoP（Aspect-oriented Programming）の概念に似ており、稼働中のブロックチェーンシステムで動的に各Join Pointに新機能を切り込むことができます！

具体的な例を挙げると、私たちは投資家やWeb2機関と交流し、大規模な資産をWeb3に導入する最大の障害は何かを議論しました。最も多くの意見が出たのは安全性の問題でした！Web2レベルのリスク管理技術は数十億の資産を安全に保護していますが、それはWeb3の技術スタックに入りにくいのです。NASAの宇宙分野からのCarlも同様の意見を述べています：なぜ私たちはRuntime ProtectionとAspectが必要なのか。

Runtime Protectionは安全性とリスク管理の核心的手段です。現在のWeb3では、非常に強力なセキュリティ会社が存在し、静的監査や形式的検証、リアルタイム監視、取引の先取りなどが行われていますが、Web2レベルのリアルタイムリスク管理にはまだ遠く及びません。その根本的な問題は、mempoolに関する安全手段が限られていることです。取引がMempoolを越えると、もはや手の施しようがありません。Mempool後の取引実行段階で、拡張能力があれば、安全専門家がruntimeレベルの安全戦略をデプロイでき、安全レベルがさらに向上します。Aspectは、開発者に実行層への安全拡張能力を提供します！

開発者は、自分のプロジェクト専用のAspectをデプロイし、必要なプロトコル層機能をカスタマイズできます。例えば、実行時の安全性を高めるために、取引が大きな資金の盗難を引き起こす可能性がある場合、それはAspect内でブロックされます。

開発者はまた、複数のプロジェクトで再利用できる基盤機能を封装する公共のAspectをデプロイすることもできます。例えば、特定のアルゴリズムと取引タイプを実装したAspectがAAウォレットをよりプログラム可能で組み合わせ可能にし、他の開発者もこのAspectを有効にして自分のプロジェクトでこの基盤特性を使用できます。

Artelaにとって、私たちの考えはますます確信を持つようになっています：

· 開発者がアプリケーション層でNative Extensionを通じて許可なしに問題を解決できるようにし、基盤公チェーンチームの封装を待つ必要がない

· Web2の背景を持つ大規模機関や資金がブロックチェーン上で質権を持つことを恐れないようにする（Web2レベルのruntimeリスク管理を強化することによって）

· 開発者が良いエコシステム環境で新しいことに挑戦できるようにする（EVMはすぐに限界に達するかもしれませんが、EVM+Native Extensionはより多くの可能性を持つかもしれません）

· 全チェーンゲームやRWAなど、より多くのビジネスロジックをブロックチェーンに移行したいdAppに理想的な環境を提供する

私たちは、Ethereumがアプリケーション特性を「封装」する方法を模索している段階にあり、彼らの「封装」圧力を解放して創造性を再び開発者に戻す計画が見えていないことを理解しています。去中心化アプリケーションの革新を探索する勇気のある次世代の革新者にとって、この状況は非常に窮屈です。一方では、彼らは強固な去中心化ネットワークを必要とし、もう一方では、自由に動くことができません。これが、私たちがNative Extensionパラダイムに基づいて新しいL1公チェーンを構築することに取り組んでいる核心的な理由です。基盤インフラが革新の歩みを拒まないようにするためです。

Import Web2

最後に、この2つの言葉でこの記事を締めくくります。コードのレベルでは、去中心化のWeb3スタックとWeb2スタックは完全に異なる思考ですが、設計哲学や発展の歴史の観点からWeb2という図書館で宝物を探すことを妨げるものではありません。keep building！