Vitalik のブログ投稿の解釈: Web3 インフラストラクチャの次の目的地はカプセル化ですか、それとも拡張ですか?

星球君的朋友们

Odaily资深作者

2023-10-27 02:21

この記事は約4306文字で、全文を読むには約7分かかります

この記事では、Web3 インフラストラクチャの「カプセル化と拡張」の設計上の選択と、パブリックチェーンインフラストラクチャのこの問題に関する個人的な考えについて説明します。

AI要約

展開

原題：「カプセル化か拡張か？」 Web3 インフラストラクチャについて議論する次の目的地 - Vitalik Enshrinement ブログの解釈

原著者: CP、Artela CTO 兼共同創設者

Vitalik氏は先週、「イーサリアムはプロトコルにもっと多くのことを組み込んでも大丈夫ですか？」というブログを公開し、イーサリアムの上位層アプリケーションを「組み込む」ために必要な基本機能についての考えを共有し、より多くの基本的なものをカプセル化するためのフレームワークを推奨する方法について議論した。上位層アプリケーションに必要な機能。

これは、一般的なプラットフォームシステムが直面する重要な問題です。チームは主要な上位層のアプリケーション機能を最下位層に「カプセル化」すべきか、それともアプリケーション開発者がこれらの機能をアプリケーション層で「拡張」すべきかです。インフラストラクチャが大規模な拡張に発展する場合、「カプセル化と拡張」の設計は非常に重要であり、大規模に適用できるかどうかを左右する重要な設計の 1 つになります。

過去 6 か月の間に、いくつかの主要なインフラストラクチャが重要な技術アップデートを開始しました: Uniswap はカスタム機能を拡張するプールをサポートするフックメカニズムを開始しました; MetaMask ウォレットは開発者によるユーザー拡張機能の追加をサポートするために Snaps を開始しました; イーサリアムも現在、「カプセル化と拡張機能」に直面しています。「難しい問題。

イーサリアムはどのような問題に直面していますか?カプセル化または拡張

「カプセル化と拡張」の問題に関して、イーサリアムは常に「拡張」を選択してきました。

イーサリアムの設計哲学は Unix に由来しており、開発者がアプリケーション層でユーザーのニーズを実現できるよう、ミニマリストでユニバーサルなカーネルを作成しています。これを実現するためにイーサリアムをサポートする主要なテクノロジーは EVM です。チューリング完全スマートコントラクト言語により、開発者はアプリケーション層でアプリケーションをカスタマイズできます。

このモデルは合理的であるように見えますが、「分散型 Unix」ではあまりうまく機能しません。重要な理由の 1 つは、EVM のいわゆるチューリング完全性が実際の使用ではそれほど「完全」ではないことです。ガスメカニズムと制限されたオペコードの下では、プログラムはタスクを完了するために限られたステップで制限されたオペコードを使用する必要があります。これによりアプリケーションが大幅に制限され、Unix のユーザー層の Web2 プログラムのように全能になることが困難になります。アプリケーション高レベルの dApp に必要な機能は EVM では満たせません。 Rollup にせよ、AA ウォレットにせよ、L1 を変更しなくてもスムーズに動作することはできますが、依然として MVP プロダクトであり、効率性やエクスペリエンスは目標には程遠いです。

開発者の選択は EIP です。イーサリアムのコアチームに、依存する重要な機能を最下層に「カプセル化」させ、それによってアプリケーション層が使用できるようにします。

EVM ベースの「拡張機能」ではアプリケーション開発のニーズを満たすことができないため、拡張機能を「カプセル化」する方法を慎重に検討する必要があります。

しかし、分散インフラストラクチャが上位層のアプリケーション機能をカプセル化することはそれほど単純ではなく、単にコードを統合するだけではなく、分散システムの最大の問題であるガバナンスが背後にあります。「カプセル化」とは、開発と保守に加えて、コアチームがこれらの機能のガバナンスにも責任を負わなければならないことを意味すると同時に、イーサリアムの信頼モデルが弱体化し、持続可能性に影響を与える可能性のある問題が発生するリスクがあります。発達。

したがって、最終的な効果は簡単にわかります: コアチームが「カプセル化」できる機能の数は限られています。第 2 に、この機能の重要性がコミュニティによって広く認識される必要があります。最後に、その実装効率はそれほど高くありません。高くて数年かかります。

同時に、これは、必要な機能が広く認識されている基本的な機能でない場合、イーサリアムでは対応できない可能性があり、たとえ対応しようとしても、独自のアプリケーションチェーンを構築することを選択しなければならない可能性があることを意味します。開発コストや運用コストが高くつき、スマートコントラクトの世界では構成の美しさが失われます。

「カプセル化と拡張」の問題に関して、イーサリアムはまだ明確な解決策を持っていません。 Vitalik 氏は、「カプセル化」を「秩序ある方法で」実現する方法について言及しましたが、カプセル化するターゲット関数を決定する方法と、それらをカプセル化する方法については、まだフレームワークを模索中です。

Unix から他に何を学べるでしょうか?ネイティブ拡張機能！

「カプセル化と拡張」の問題に関しては、イーサリアムでは主に、EVM の拡張機能の不足を補うためにコアチームがカプセル化を行う必要があります。別の視点から考えてみると、アプリケーション層のスケーラビリティを向上させれば、問題の大部分は解決できるのでしょうか？たとえば、アプリケーション開発者は、基盤となるチームがカプセル化するのを待たずに、アプリケーションに必要な基盤となる機能を独自のアイデアに従ってカスタマイズできます。

また、イーサリアムが Unix から多くの設計哲学を吸収していることもわかっているので、引き続き Unix システムのアイデアを探してみましょう。

Unix ベースの商用オペレーティングシステムは、PC 市場を指向しており、アプリケーション層でのより多様化した要求、さらにはエンタープライズ使用シナリオからの拡張要求にも直面しています。しかし、これらの商用オペレーティングシステムでは、コアチームに大きな「カプセル化」の負担がかからず、アプリケーションに提供される拡張性が十分に高いため、ユーザーはほとんどの機能を自分で解決できます。

Mac OS Xを例に挙げると、一般的なオペレーティングシステムではカーネルモードとユーザーモードが区別されており、ユーザーアプリケーションは通常ユーザーモードで動作し、カーネルモードプログラムが提供する機能を利用します。単純な (ただし不完全な) 比較は、EVM 上のスマートコントラクトがユーザーモードアプリケーションに相当し、イーサリアムプロトコル層がカーネルモードに相当するということです。

ただし、Mac OS X では、アプリケーション開発者が Mac OS を必要とせずに、カーネル状態にプログラムを独自に展開して、カーネル状態の機能を拡張することができます。 Mac OS の機能が提供するコアメカニズム。

私たちが得たインスピレーションは、「カーネル拡張」モデルは「分散型 Unix」上で実現可能かということでした。そのパターンを下図に示します。

「スマートコントラクト」のサポートに加えて、ブロックチェーンプロトコルは別のプログラム「Native Extension」もサポートしています。

1) スマートコントラクトよりも基盤となるプロトコル API アクセス権を持っています

2) また、その実行環境の効率は EVM よりも桁違いに高くなります。

3) また、基礎となるプロトコルから分離されており、基礎となるプロトコルの安定性に影響を与えません。

4) したがって、ガバナンスの観点からは、基盤となるチームによって保守される必要はなく、アプリケーションチームによって保守およびデプロイされます。

このモデルが技術的に上記の 4 つのポイントを満たすことができれば、多くの問題を解決できると思われます。アプリケーション開発者は、基盤となるチームがカプセル化するのを待つことなく、アプリケーションに必要な基盤となる機能を独自のアイデアに従ってカスタマイズできるようになります。

ひとまずこのパラダイムを「ネイティブ拡張」パラダイムとしてまとめてから、既存の Web3 インフラストラクチャにその影があるかどうかを見てみましょう。

Hook, Hook, Hooks…

ソフトウェアの世界では、多くの場合、優れたシナリオによって優れた車輪が作成されます。 DeFi インフラストラクチャとして、Uniswap は「プラットフォーム」になる重要な段階にあり、「カプセル化と拡張」の特性に関する驚くべき設計、つまりフックを備えています。これにより、開発者はフックを使用して許可なくプールに拡張機能を追加し、コアチームが「カプセル化」を通じて機能を継続的にアップグレードする必要がなく、機能的に多様なプールエクスペリエンスを実現できます。

Hook のメカニズムは、前述の Native Extension の複数の条件と似ています。

· フックはプールの実行ライフサイクルに切り込み、実行時データにアクセスできます。これはより高度なアクセスレベルです。

· フックとプールは 2 つの独立したコントラクトであり、フックのセキュリティはプールには影響しません。

· ガバナンスの観点から、フックはサードパーティの開発者によって許可なく開発および展開されており、グローバルにアクティブ化されず、代わりに、カスタム機能をアクティブ化するために、必要に応じて異なるプールが異なるフックをバインドします。

フックは、プールのスケーラビリティの問題を解決する、小さいながらも美しいデザインです。アプリケーション層インフラストラクチャは、これらの概念を適用する上で先導しました。続いて、より複雑な基盤となるプロトコル (L1/L2) の概念を見てみましょう。

新しいパブリックチェーンプロジェクトの拡張アイデア

イーサリアムは困難に直面しています。レイヤー 1 の拡張に特化したレイヤー 2 プロジェクトのアイデアを見てみましょう。

Arbitrum Stylus を使用すると、アプリケーション開発者はプリコンパイルされたコントラクトを自分でパッケージ化できます。

EVM は「プリコンパイルされたコントラクト」を通じてその機能を拡張できることを誰もが知っているはずです。そのコードは EVM では実行されませんが、ノードに統合され、下部で実行されます。たとえば、計算が複雑すぎてコストがかかるため、新しい暗号化アルゴリズムを追加したい場合、それをプリコンパイルされたコントラクトとして実装し、アプリケーションコントラクトがそれを呼び出して新しい暗号化アルゴリズムを使用できます。ただし、プリコンパイルされたコントラクトの追加された権限はアプリケーション開発者には公開されておらず、追加する前に EIP を通じてイーサリアム開発チームによって「カプセル化」される必要があります。

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

これは、イーサリアムの「カプセル化」問題を最適化できる実装の 1 つです。EVM の拡張要件は、最下位チームがカプセル化するのを待つ必要はなくなりました。最下位チームは、実行層の拡張環境の維持に重点を置き、導入、新しい機能の開発とガバナンスが交換され、アプリケーション層によって開発されます。

ただし、Stylus はまだ初期段階にあります。このモデルのさらなる課題はまだ明らかにされておらず、解決できる問題は限られています。現在、Stylus はプリコンパイルされたコントラクトの動的パッケージングのみをサポートしており、イーサリアムもプリコンパイルされたコントラクト以外のパッケージ化の問題にも直面しています。契約。しかし幸いなことに、これはネイティブ拡張パラダイムに近い実装の 1 つであり、新世代のインフラストラクチャの代表として、エコシステムが将来遭遇する「カプセル化」問題を解決するためのスケーラビリティ設計を導入しています。長期的な生態系の発展を考慮して、「規模。」の問題を解決します。

ネイティブ拡張: 「モジュール式カプセル化」のアイデア!

Web2 や Web3 などのインフラストラクチャプロジェクトを検討した後、「カプセル化と拡張」の問題を振り返ると、拡張機能を向上させることで、開発者はモジュール方式を使用して必要なものをカプセル化できるという明確なアイデアがわかります。

これは、ネイティブ拡張パラダイムがインフラストラクチャで果たす重要な役割です。インフラストラクチャのスケーラビリティを向上させることで、その選択肢が開発者に返され、開発者はコアプロトコルの安定性に影響を与えることなくインフラストラクチャを自由に使用できるようになります。カプセル化とモジュール化のアプローチ望む機能を拡張します。

イーサリアムは「カプセル化」の効率を向上させようとしており、Arbitrum Stylus はプリコンパイルされたコントラクトを解放しています。さらに先を見据えると、Uniswap V4 がもたらすのと同じように、パブリックチェーンはネイティブ拡張パラダイムを通じてアプリケーション層の創造性を完全に解放することもできます。みんなにそう感じてください。

ネイティブ拡張パラダイムに基づく新しい L1 パブリックチェーン: Artela

ここで視点を変えて、「私たち」とは、私が CTO として働いているチーム、Artela を指します。この問題に関する私たちの考えと行動を共有しましょう。

Artela ブロックチェーン上には、EVM に加えて、WASM 実行環境もインストールされました。一方で、ステートフルなプリコンパイル済みコントラクトと同様のステートフルプログラムを実行できますが、他方では、フックのようなメカニズムをサポートし、ブロックおよびトランザクション処理の複数のライフサイクルノードでトリガーできるようにします。言い換えれば、Arbitrum Stylus のようなプリコンパイルされたコントラクトをカプセル化するために使用されるだけでなく、トランザクションとブロックの実行プロセスをカスタマイズして、より広範な機能のカプセル化を実現することもできます。たとえば、WASM のネイティブ拡張機能はトランザクション検証フェーズ中にトリガーされ、トランザクションの識別と検証に新しいアルゴリズムが使用されます。これらのフックは Artela ではジョインポイントと呼ばれ、ネイティブ拡張はスマートコントラクトではなくアスペクトと呼ばれ、AoP (アスペクト指向プログラミング) の概念に似ており、実行中のブロックチェーンシステム内で動的に新しい機能が追加されます。入会ポイントへ！

具体的な例を挙げると、大規模なアセットを Web3 にインポートする際の最大の障害は何かを調査するために、投資家や Web2 機関と連絡を取り合いました。最も議論されている問題はセキュリティです。 Web2 レベルのリスク管理テクノロジは数十億の資産のセキュリティを保証しますが、Web3 テクノロジスタックに参入することは困難です。 NASA の航空宇宙分野出身の Carl 氏も、なぜランタイム保護とアスペクトが必要なのかという同じ見解を表明しました。

ランタイム保護はセキュリティリスクコントロールの中核的な方法です。今日の Web3 では、非常に強力なセキュリティ企業のグループが静的監査と形式的検証、リアルタイムの監視とフロントランニングトランザクションの両方を備えていることがわかります。これがすべての方法であるようです。 , しかし、Web2 レベルのリアルタイムリスク制御にはまだ程遠いです。根本的な根本問題は、トランザクションが Mempool を通過すると何もできないため、mempool の周囲にセキュリティ方法が限られていることです。 Mempool以降のトランザクション実行フェーズでは、拡張機能があり、セキュリティ専門家がランタイムレベルのセキュリティポリシーを導入できれば、セキュリティレベルはより高いレベルに引き上げられます。 Aspect は、開発者に実行層の奥深くまで踏み込んだセキュリティ拡張機能を提供します。

開発者は、自分のプロジェクトにのみ機能するアスペクトをデプロイして、必要なプロトコル層機能をカスタマイズできます。たとえば、実行時のセキュリティを強化するために、トランザクションが多額の資金の盗難につながる可能性がある場合、そのトランザクションは Aspect でブロックされます。

開発者は、パブリックアスペクトをデプロイして、複数のプロジェクトで再利用できる基本機能をカプセル化することもできます。たとえば、アスペクトは特定のアルゴリズムとトランザクションタイプを実装し、AA ウォレットをよりプログラム可能かつ組み合わせやすくします。他の開発者もこのアスペクトを有効にして、この基礎となる機能を独自のプロジェクトに使用できます。

アルテラに関しては、その過程で私たちの考えはますます固まっていきました。

· 開発者は、基盤となるパブリックチェーンチームがカプセル化するのを待つのではなく、アプリケーションの状態でネイティブ拡張機能を通じて許可なく問題を解決できるようになります。

· Web2 のバックグラウンドを持つ大規模な機関がブロックチェーン上で多額の資金を約束できるようにする (Web2 レベルのランタイムリスク制御の導入により強化される)

· 開発者が循環を打ち破ることを行うための良好な環境環境を確保できるようにする (EVM はすぐに上限に達する可能性があり、EVM + ネイティブ拡張機能にはさらに可能性がある可能性があります)

· フルチェーンゲーム、RWA、およびより多くのビジネスロジックをチェーンに移動したいその他の dApp に理想的なホームを持たせる

イーサリアムはアプリケーション機能をどのように「カプセル化」するかという段階にあり、「カプセル化」の圧力を解放して創造性を再び開発者の手に戻す計画はないことがわかります。分散型アプリケーションで画期的なイノベーションを探求する勇敢な潜在的な次世代イノベーターのグループにとって、この状況は非常に制限的であり、一方ではそのような堅牢な分散型ネットワークが必要ですが、他方では彼らはそのような強力な分散型ネットワークを使用することができません。手と足。これが、インフラストラクチャがイノベーションのペースに抵抗しないように、ネイティブ拡張パラダイムに基づいて新しい L1 パブリックチェーンの構築に注力している主な理由です。