L2、Solana、それとも Appchain?アプリケーションをデプロイするのに最適な選択は誰ですか?

本文は約4926字で,全文を読むには約7分かかります
暗号通貨の世界では、アプリケーションを汎用 L2、Solana、またはアプリケーション固有のチェーンのいずれにデプロイするかを選択することが重要であり、各オプションには固有の利点と欠点があり、特定のニーズに基づいて比較検討する必要があります。

原作者:ザ・ロールアップ

オリジナル編集: Vernacular Blockchain

今日の暗号通貨の世界では、アプリケーションをデプロイするプラットフォームを選択することは、製品自体と同じくらい重要です。

これは、現在多くの開発者の頭の中にある10億ドル規模の質問であると思います。「アプリをデプロイするのに最適なプラットフォームはどれか?」ということです。

今日の記事では、私が現在最善だと考えている 3 つのオプションを取り上げ、それぞれの長所と短所を分析し、今後の技術の進歩によってこの選択が現在よりもさらに簡単になることを分析します。

開発者にとって現時点での最善の選択肢は、Solana エコシステム内の汎用レイヤー 2 ネットワークにデプロイするか、アプリケーション固有のチェーンを構築する 3 つです。これらの決定は、パフォーマンス、セキュリティ、ユーザー エクスペリエンス、および長期的な存続可能性に重大な影響を与えます。

この記事では、これらのオプション間の技術的な違いを詳しく掘り下げ、それぞれの長所と短所を通してそれらを分析し、イーサリアムとソラナの戦いにおいてアプリケーション固有のチェーンの重要性が高まっていることを示します。

1. ユニバーサル レイヤ 2 ネットワーク/L2 ロールアップ

1) メリット

セキュリティの継承: 汎用 L2 またはロールアップ (Optimism や Arbitrum など) は、イーサリアムのセキュリティを継承します。これは、これらのプラットフォーム上に構築されたアプリケーションが、独自の検証クラスターを維持することなく、イーサリアムの強力なセキュリティの恩恵を受けることができることを意味します。バリデーターのクラスター (通常は L1 として) を通じて独自の経済的セキュリティをブートストラップするのは非常に難しいため、これはアプリケーションの起動では特に重要です。

言うまでもなく、かなりの数の異なる汎用 L2 が利用可能です。

構成可能性: Universal L2 は高度な構成可能性を提供し、同じ L2 上のアプリケーションとプロトコルがシームレスに対話できるようにします。 「通貨レゴ」という用語は、2020年のDeFi夏に初めて提案され、現在でも意味を持っています。チェーン上に構築する最大の利点の 1 つは、構成可能性です。

このレベルの構成可能性は、従来の金融または暗号ドメイン以外のソフトウェアでは不可能です。これは、流動性と相互運用性に依存する DeFi アプリケーションにとって特に有益です。

開発者に優しい: 汎用 L2 上に構築するということは、(通常は) EVM を利用することを意味します。EVM はほとんどの暗号ネイティブ開発者がすでに使い慣れており、学習曲線を短縮し、開発をスピードアップします。他の仮想マシンのロールアップ (altVM) については、Rust (Soon SVM などのスタック用)、C、C++ (Arbitrum Stylus)、Move (Movement Labs およびLumio)、Linux (Cartesi)、Web Assembly (Fluent)、さらには Fuel Network の Sway も含まれます。

2) デメリット

輻輳とスケーラビリティの問題: 同じ L2 上にデプロイされるアプリケーションが増えると、輻輳が問題になり、料金の増加やトランザクションの速度低下につながる可能性があります。これにより、特に低遅延を必要とするアプリケーションの場合、ユーザー エクスペリエンスが低下する可能性があります。

「騒音の多い隣人」問題は現実のものであり、清算やユーザー インタラクションが多いイベント中に L2 で発生することが確認されています。これは微妙な見方であり、MegaETH のような EVM 並列化は、ロールアップまたは上記のさまざまな実行環境に基づいて、この問題を軽減するのに役立ちます。

限られたカスタマイズと収益性: 汎用 L2 は、幅広いアプリケーションのニーズを満たすように設計されており、多くの場合、単一アプリケーションの特定のニーズに合わせて最適化する柔軟性に欠けています。これは、カスタム ガス トークン、カスタム ブロック時間、トランザクション順序ルールを必要とする開発者にとっては問題になる可能性があります。これにより、パフォーマンスのチューニングとユーザー エクスペリエンスの最適化が制限される可能性があります。

私には、MEV の問題と収入の仕分けに関する素晴らしい経験があります。アプリケーションを汎用 L2 にデプロイし、収益分配を提供しない場合、基本的にはロールアップ オペレーターからブロック スペースを借りて、アプリケーションやコミュニティに再分配できる収益を得ることができます。これについては後で説明します。

2. アプリケーション固有のチェーン

1) メリット

完全にカスタマイズ可能: アプリケーション固有のチェーンにより、開発者はアプリケーションのニーズに合わせてブロックチェーン環境のあらゆる側面を最適化できます。これにより、パフォーマンスが向上し、コストが削減され、ユーザー エクスペリエンスが向上します。

収益を内部化し、独自の主権発注者を通じてトランザクションの注文を制御し、ガス支払者や高度なアカウント抽象化ソリューション、または非常に高速なブロック時間 (Reya の 100 ミリ秒のブロック時間や、立ち上げたばかりの Clearpool の RWA に焦点を当てたものなど) を通じて、より低い手数料とより良いユーザー エクスペリエンスを提供できます。独自の機能を多数備えたオゼのアプリケーション チェーン)。これにより、チェーン上の開発者とユーザーが相互に有益な方法で独自の収益化方法を利用できるようになります。手数料、トランザクション、使用量が増えると、コミュニティ全体に分配されるソーターの収益が増加し、希望する方法で分配できます。

スケーラビリティ: チェーンは単一のアプリケーションまたは関連アプリケーションのグループ専用であるため、他のプロジェクトによって引き起こされる輻輳のリスクはありません。独自のブロック スペースを持つことができ、チェーン上の「うるさい隣人」(輻輳) 問題を排除できます。ガス料金のスパイクを軽減し、ブロックスペースをより適切に制御します。

2) デメリット

複雑さとオーバーヘッド: Gelato Network、Conduit、Caldera などの RaaS プロバイダーは、新しいチェーンを立ち上げるプロセスの簡素化に役立ちますが、アプリケーション固有のチェーンの構築と維持は、一般的な L2 でのアプリケーションのデプロイ (スマート コントラクトのデプロイとデプロイの比較) と比較されます。チェーン全体)には、より多くの準備とリソースが必要です。

Layer Labs やその他のインキュベーターのようなチームが支援することはできますが、チェーンを立ち上げるプロセス全体としてはより面倒です。初日から、相互運用性プロバイダー、注文 (ほとんどの RaaS にはいくつかのオプションが用意されています)、RPC などの問題を考慮する必要がありますが、この点では Lava Network が役立つ可能性があります。

相互運用性の課題: Cosmos などのフレームワークは組み込みの相互運用性ソリューションを提供しますが、汎用 L2 の使用は、より広範なイーサリアム L2 エコシステムと対話するよりも複雑です。アプリ チェーンとして直面する最大の疑問は、初日からユーザーを獲得する方法と、どの相互運用プロバイダーが支援しサポートしてくれるかということです。

Hyperlane、Union Build、Jumper Exchange、LayerZero、そして最終的には Omni と AggLayer を検討してください。 Astria や Nodekit などのチームも、ブロック構築の調整において重要な役割を果たします。

さらに、ソルバーに高速な相互運用性を提供したい場合は、Everclear、AcrossProtocol、LiFi Protocol、Wintermute などの大規模なソルバー チームとの関係を構築する必要がある場合があります。これらの課題は、クロスチェーンのユーザー エクスペリエンスの問題と相まって、アプリケーション チェーンを立ち上げる際の最大の問題となります。

これについては後ほど詳しく説明します。

3. ソラナ

1) メリット

非常に高いパフォーマンス: Solana は高性能アプリケーション向けに設計されており、非常に低いレイテンシーで 1 秒あたり数千のトランザクションを処理できます (ただし、トランザクションが失敗する場合もあります)。その速度により、Solana は低遅延と高パフォーマンスを必要とするアプリケーションに最適です。これらの要素はユーザーエクスペリエンスにも適用され、あらゆる暗号通貨ユーザーにとって非常に使いやすいものになっています。

統合されたエクスペリエンス: Solana の単一ステート マシンは、構成可能性の観点から非常に魅力的です。これにより、「お金のレゴ」の構築がブロックチェーン上よりも簡単になりますが、一般的な L2 での経験と似ています。このアーキテクチャは、すべてのアプリケーションが同じ状態を共有する統合環境を提供し、Kamino Finance や JupiterExchange などの成功したアプリケーションからネットワーク効果を引き出すこともできます。

エコシステムの成長軌道: Solana のエコシステムと開発者の成長は着実に増加しています。このエコシステムは、DeFi、NFT、さらに幅広い Web3 アプリケーション、さらには memecoin を強力にサポートしています。 Rust ではコードを記述できるため、その開発者コミュニティは継続的に成長しており、新しいプロジェクトや非暗号ネイティブ開発者向けに、より多くのリソースとツールを提供しています。

このエコシステムは今後も拡大し続けると思いますが、アプリケーションはこの拡大によってもたらされるネットワーク効果の恩恵を受ける可能性があります。今年初めに作成された以下のエコシステム マップを参照してください。

2) デメリット

集中化のリスク: Solana は技術的な利点にもかかわらず、集中化の問題によりある程度の批判を受けています。イーサリアムと比較すると、そのバリデーターネットワークは小規模であり、セットアップに高価です。イーサリアム L1 上に構築されていると比較すると、Solana は検閲耐性に劣りますが、中央集中型の発注者を持つ L2 と比較すると、Solana に利点があると思います。ただし、チェーンのやや集中化された性質は、開発の初期段階で生じたものであり、考慮する必要があります。

ネットワークの停止: Solana は複数のネットワークの停止と安定性の問題を経験しており、その信頼性について懸念が生じています。毎回通常に戻りますが、常にオンラインにする必要がある開発者にとっては依然としてリスクです。最近ではこのようなことは再発していないが、これは明るい兆しである。

上記の理由は可能な限り客観的かつ中立的に説明されていますが、それでもトレードオフとパフォーマンスの観点から、アプリケーション固有のチェーンは汎用 L2 と Solana の間にあると私は結論付けています。

このグラフも非常に役立つことがわかりました。

私の意見では、アプリケーション固有のチェーンは、モジュラーエコシステムがパフォーマンスと開発者のエクスペリエンスの点でモノリシック L1 と競合するための実行可能な戦略を提供します。開発者が特定のユースケースに最適化されたカスタマイズされた環境を構築できるようにすることで、アプリケーション チェーンは、これらの L1 に匹敵する、またはそれを超えるパフォーマンスと柔軟性を提供できます。

ただし、重要なのは、このロールアップ中心のモジュラー スケーリング ロードマップを達成するには、適切な相互運用性とチェーンの抽象化が鍵であることを理解することです。新しいチェーンが立ち上げられ続けると、断片化の問題はさらに深刻になるでしょう。

Xion、Okto、Particle Network、NEAR Protocol、Halliday、Aarc などのチームがチェーンの抽象化に取り組んでおり、そこで重要な役割を果たすことになります。これらのより優れた相互運用性ソリューションがなければ、モジュール式の未来は危険にさらされます。

4. まとめ

General L2 と Solana はそれぞれ魅力的な利点を提供しますが、アプリケーション固有のチェーンは、General L2、Solana、および他の L1 と競合することで、ビルダーが収益性、専門性、拡張性と構成可能性を達成する機会を提供します。

モジュラーエコシステムが拡大するにつれて、アプリケーション固有のチェーンが人気のあるアプリケーションの成長において重要な役割を果たすようになるでしょう。ただし、このビジョンは、相互運用可能なソリューションの標準をできるだけ早く確立することに厳密に依存しています。

この目標はうまく達成され、相互接続されたアプリケーション固有のロールアップが今後数年間で盛んになると私は信じています。

オリジナル記事、著者:白话区块链。転載/コンテンツ連携/記事探しはご連絡ください report@odaily.email;法に違反して転載するには必ず追究しなければならない

ODAILYは、多くの読者が正しい貨幣観念と投資理念を確立し、ブロックチェーンを理性的に見て、リスク意識を確実に高めてください、発見された違法犯罪の手がかりについては、積極的に関係部門に通報することができる。

おすすめの読み物
編集者の選択