EVM vs SmartWeave: 同意する開発者のための包括的なガイド (パート 2)

EVM vs SmartWeave: 同意する開発者のための包括的なガイド (パート 2)

アップランド: ベルリンはここです!アップランド: ベルリンはここです!

からの第二弾です EVM vs SmartWeave: 同意する開発者のための包括的なガイド.

遅延実行: 別の視点

モジュラー理論は、過去数年間、ブロックチェーン分野で最も顕著な物語の 1 つです。 主要な LXNUMX のほとんどすべてが、ブロックチェーンのすべてのプロパティを提供する役割を担うモノリシック層に依存するのではなく、モジュラーアプローチによって分散型ネットワークを拡張することに落ち着いた Solana は唯一の例外かもしれません。 SmartWeave は、モジュール式の理論に対する独自のアプローチであり、データ ストレージを実行層から分離することによって分散台帳コンピューティング機能を拡張することだけに焦点を当てています。

SmartWeave の「遅延評価」アプローチでは、スマート コントラクト コードを実行する責任がネットワーク ノードからスマート コントラクト ユーザーに移されます。

これは本質的に、トランザクション検証の計算が必要になるまで延期され、ネットワーク ノードの作業負荷が軽減され、トランザクションのより効率的な処理が可能になることを意味します。 このアプローチにより、ユーザーは追加料金を発生させることなく必要なだけの計算を実行でき、他のスマート コントラクト システムでは実現できない機能が提供されます。 その結果、評価がユーザーにオフロードされる場合、ビルダーはガスの最適化について心配する必要がなくなりました。

EVM と SmartWeave の適合性の評価

金融プリミティブはブロックチェーン テクノロジーの最も重要なアプリケーションの 2 つであり、EVM はすべてのネットワーク ノードでスマート コントラクト コードを厳密かつ決定的に実行するため、この目的に特に適しています。 さらに、イーサリアムメインネットやそれに付随するLXNUMXなどのEVMプラットフォームの基盤となる巨額の資金は高レベルのセキュリティを提供し、EVMベースのスマートコントラクトネットワークがDeFi市場を獲得する上で有利な立場にあります。

考慮すべきもう XNUMX つの重要な要素は、大量の計算を必要とする SmartWeave アプリケーションをスケーリングする必要性です。 これは、ユーザーのデバイスのみに依存するのは現実的ではないため、実行層を特殊なエンティティに委任することによってのみ実現できます。 何千ものユーザー CPU インタラクションを伴うコントラクトを評価しようとしても無駄です。

Warp の DRE のような抽象化レイヤーは、この課題を克服するために開発されました。 これは、コントラクトの計算を処理する分散型バリデーター ネットワークで構成され、応答時間とユーザー エクスペリエンスを大幅に向上させます。

ただし、この抽象化レイヤーが最終段階で完全に分散化された状態を維持することは、サードパーティの依存関係や検閲の問題を回避するために重要です。 それにもかかわらず、仮想的な悪意のあるアクティビティの影響を受けやすい可能性がある上層の実行層が、Arweave に保存されている SmartWeave データの分散化と不変性を損なうことができないことは注目に値します。 どのエンティティも Arweave から直接データを取得し、コントラクトの状態を独立して実行できるため、不正行為を防ぐことができます。

多くのアプリケーションはすでに Permaweb ユーザーに付加価値を提供していますが、Arweave エコシステムはまだ初期段階にあります。 現在、主要な ERC 標準が作成されたイーサリアムの初期の頃と同様に、標準の探索と定義が進行中です。

EVM システムと比較すると、開発者のアクティビティと利用可能なツールは依然としてニッチです。 これは、急な学習曲線により新規参入者にとって不利になる可能性がありますが、同時に、暗号通貨業界の根幹である真のイノベーションのためのエキサイティングな機会も提供します。

SmartWeave の市場適合性

理論的にアーキテクチャ設計の利点と制約について話すのは興味深いですが、実用的な側面に焦点を当て、EVM が最適ではない可能性のある特定の使用例を検討してみましょう。 SmartWeave がニッチ市場を埋める可能性があるのはそこです。 DeSoc (分散型ソーシャル) は最近、暗号通貨分野の主要なトレンドとして浮上しており、伝説的な DeFi の夏に似た興奮、コミュニティの参加、開発者の関与を生み出しています。

DeSoc は、ソーシャル グラフ データを解放するオープン アーキテクチャを通じて、クリエイターのバラバラな収益化や不均衡なプラットフォーム価値など、従来のソーシャル メディアの課題を解決することを目指しています。 ただし、Lens Protocol、Farcaster、Cyber​​Connect などのソーシャル グラフ プロトコルはまだ開発の初期段階にあり、さまざまな標準やトレードオフを考慮する必要があります。

ソーシャル グラフ プロトコルで考慮すべき問題の XNUMX つは、EVM の制限です。 これには、高額なガス料金と長いファイナリティ期間が含まれます。 「いいね!」アクションの処理に XNUMX 分も待ちたい人はいません。 考えられる解決策は、「いいね!」やミラーなどの重要性の低いデータをオフチェーンに保存し、より重要なアクションをオンチェーンに投稿することです。 ただし、このアプローチでは、オンチェーンのプログラマビリティと分散化を犠牲にする必要がある場合があります。

しかし、Warp は、その珍しいアーキテクチャと、ユーザー エクスペリエンスを犠牲にすることなくパーマウェブ (Arweave 台帳) 上でユーザー インタラクションを維持できる機能のおかげで、これらの EVM の制約に優れています。 特定の高コストまたは高スループットのアクションを Warp に委任することで、EVM チェーン上に構築された既存のソーシャル グラフ プロトコルをシームレスな SmartWeave 統合で強化し、両方のテクノロジーの強みを活用できます。 このような相互共生の例を以下の図に示します。

EVM vs SmartWeave: 同意する開発者のための包括的なガイド (パート 2) PlatoBlockchain Data Intelligence。垂直検索。あい。EVM vs SmartWeave: 同意する開発者のための包括的なガイド (パート 2) PlatoBlockchain Data Intelligence。垂直検索。あい。

SmartWeave の導入は、オンチェーンに保存された透明な基盤データと、それを他の Arweave ネットワーク モジュールと組み合わせる機能の利点のおかげで、AI と財務モデリングを検討することで強化できます。 ストレージのコストが高いため、EVM システムではこのような統合は経済的に不可能です。

まだ初期段階ではありますが、Warp ソフトウェアを利用した機械学習モデルの実験はすでに今日行われています。 こちら。 現在広く採用されている最も一般的なユース ケースの XNUMX つは、Warp SDK を使用して構築されたさまざまなデータベース実装システムであり、EVM ネットワークでは管理できない大規模なデータ セット上で本番環境に対応した大量のインタラクションを処理できます。 WeaveDB、FirstBatch、Glacier、Kwil など、いくつかのプロジェクトがパーミッションレス DB コホートをリードしています。

Warp プロトコルには、文書管理や取引署名のためのビジネス ロジックをオンチェーンに導入するなど、興味深い未開発の可能性がまだたくさんあります。 技術スタックと Web3 ゲームの初期段階では、スコアボードやアイテムの台帳など、特定のエンジン モジュールがオンチェーン上に存在する機会も提供されます。 これらの分野は、たとえ XNUMX つの大企業やゲーム スタジオがワークフローの一部をオンチェーンにオフロードすることを決定したとしても、Warp の成長に大きな牽引力をもたらす可能性があります。

最終的な考え

最終的に、EVM と SmartWeave のどちらを使用するかの決定は、プロジェクト固有のニーズと開発者の好みによって決まります。 イーサリアム仮想マシン (EVM) はブロックチェーン アプリケーションの頼りになるソリューションとして広く受け入れられていますが、常に最良の選択であるとは限りません。

Warp では、状態検証のためのネットワーク全体の合意の制限のない永続的かつ不変の実行環境である SmartWeave が、Web3 エコシステムの補完的なネットワークまたは特定のモジュールの実行可能な代替として機能すると考えています。

ゲスト投稿者: Jakub Wojciechowski、CEO 兼創設者 ワープコントラクト および 赤石

タイムスタンプ:

より多くの CryptoSlate