トークンを発行することは以前は簡単でした:それをイーサリアム上に展開すればよかったのです。そこにはユーザー、トレーダー、資本、そして流動性が集まっていました。しかし、今日、その状況ははるかに複雑です。流動性はビットコイン、イーサリアム、L2、ソラナ、その他のチェーンに分散しています。では、どこでトークンを発行すべきでしょうか?明確な答えはありません。
しかし、1つのチェーンを選ばなくてもいいとしたらどうでしょうか?どこでも機能するトークンを想像してみてください。それは、仮想通貨の経済全体にシームレスに流れるものです。
おかげで相互運用性プロトコル(またはブリッジとも呼ばれる)複数のチェーンにまたがる統一された市場でトークンを発行することが可能になりました。これにより、国境を越えたグローバルな流動性が生まれ、トークン発行者の操作が簡素化されます。より多くの流動性、より多くの採用、そして断片化の頭痛のない強力なネットワーク効果が生まれます。基本的に、どこでも機能するグローバルな銀行口座を持っているようなもので、すべてのDeFiエコシステムに統合されています。
この記事では、異なる相互運用性プロトコルで提供される主要なトークンフレームワークを比較します。目標は、独自の機能、強み、およびトレードオフを評価し、ネイティブでマルチチェーンのトークンを発行するための最良のソリューションをチームが選択するのに役立つことです。
以下のフレームワークを探求します:
さあ、潜り込みましょう。
トークンフレームワークは、既存のトークンをマルチチェーン化するか、最初からネイティブのマルチチェーントークンをローンチするかによって、2つの主要な方法で動作します。
トークンが最初の日から複数のチェーンでネイティブに発行されると、その供給量はそれらのチェーン全体に分散されます。トークンがチェーン間で移動されると、元のチェーンで燃やされ、目的のチェーンで鋳造され、総供給量が一定であることが保証されます。
それを会計システムと考えてください(多くの相互運用チームが説明しています)。以下に例を挙げます:1000トークンの総供給量を持つトークンXを考えてみましょう。需要に基づいて5つのチェーンに分散させます。
ユーザーがチェーンEからチェーンAにトークンを50個転送した場合、これらのトークンはチェーンEで燃やされ、チェーンAで鋳造されます。更新された分配は次のとおりです:
このプロセスにより、総供給量が1000トークンに保たれ、スリップなしでチェーン間のシームレスな転送が可能になります。
元々単一のチェーンに展開された既存のトークンに対しては、プロセスが若干異なります。全体の供給量は1つのチェーン上に存在し、別のチェーンに送金する際には、供給量の一部が送信元のチェーン上のスマートコントラクトにロックされ、同等の量が送信先のチェーン上に鋳造されます。
この方法は、ラップトークンがどのように動作するかと似ています。Chain A でロックされたトークンは、Chain B でラップされたバージョンが発行されることができます。しかし、これらのトークンは、バーン・ミント方法を使用して Chain B から Chain C に移動することもできます。複数のチェーンでロックする必要がなくなりました。元の供給は Chain A に残り、チェーン間の送金は単に、燃やされたトークンが発行されたものと一致していることを確認すれば済みます。
複数のチェーンにまたがる統一市場で取引可能なトークンを持つことの利点は、チームにとって重要です。
考えるCircleのクロスチェーン転送プロトコル(CCTP)CCTPを立ち上げることで、Circleはサポートされているチェーン全体でUSDCのシームレスな取引を可能にし、重要な問題に対処しました。
CircleのUSDCの独自の機能セットは、ほとんどのプロジェクトが持っていないカスタムビルドのブリッジ、CCTPのおかげです。これは、相互運用性プロトコルによって維持されるトークンフレームワークが登場する場所です。これらのフレームワークは、USDCに対してCCTPが提供するのと同様の解決策を提供し、任意のトークンに対しても同様の機能を提供します。これらのフレームワークを介してトークンを発行することで、プロジェクトは複数のサポートされたチェーン間で統一された市場を作成し、バーン/ロックおよびミントメカニズムを使用した簡単な転送を可能にすることができます。
トークンフレームワークがどのように機能し、その利点を理解したので、トークンを発行するチーム向けの市場で利用可能なさまざまなソリューションを比較しましょう。
以下は、表にカバーされている重要なセキュリティの側面の説明です:
1.検証メカニズム
検証メカニズムは、チェーン間での転送がどのように検証されるかの中核です。メッセージがどのように検証されるか、および各フレームワークが提供する検証メカニズムのセットアップのタイプについて言及しています。シングルオプション、複数のオプションを持つモジュラーシステム、または任意のブリッジと互換性のある柔軟な設計のいずれかであるかなど、トークン発行者がセキュリティ要件に基づいて最適なソリューションを選択できるようにします。
カスタム検証メカニズムには利点がありますが、デフォルトの設定が重要です。最も広く使用され続けていますしたがって、デフォルトの認証スキームのセキュリティに重点を置くことが重要です。チームは、セキュリティ設定を強化するために、デフォルトの上に追加の認証スキームを使用することが推奨されています。
ライブネスに関しては、複数の検証スキームに依存することには、利点と欠点の両方があります。プラス面としては、フォールトトレランスが向上し、1つのプロバイダーがダウンタイムが発生した場合でも、他のプロバイダーが運用を継続し、システムの信頼性を高めることができます。ただし、これによりシステムの複雑さも増します。スキームを追加するたびに潜在的な障害点が発生し、運用が中断されるリスクが高まります。
2.検証における柔軟性
検証メカニズムをカスタマイズする際の各フレームワークの柔軟性、具体的には、トークン発行者がさまざまなオプションから選択できるか、デフォルト設定に制限されるかを強調します。
3.注目すべき事前構築済み検証スキーム
プレビルド済みのスキームは、トークン発行者がメッセージの検証に使用できる使用準備が整った検証メカニズムです。広範な信頼性のあるプレビルドオプションを備えたフレームワークは、一般的には良い兆候です。
いくつかのフレームワークは他よりも多くの検証スキームを提供していますが、重要なのは彼らのセキュリティスペクトラムに基づいて評価します、単一のバリデータから包括的なバリデータセットまでの範囲に及ぶことができます。
例えば、OFTsは、CCIPやAxelarのようなより堅牢な選択肢と並んで、単一のバリデーターを使用するDVNオプションを提供しています。同様に、Warp Tokenは、Hyperlaneコミュニティによって実行されるバリデーターを含むマルチシグISMなどのISMを提供しています。同時に、Aggregation ISMのようなオプションを使用することで、チームは複数のISMからのセキュリティを組み合わせることができます。
さらに、これらの検証スキームの多くは、まだ広く採用されていないか、実際のシナリオで徹底的にテストされていない可能性があります。したがって、チームは利用可能な検証スキームの品質を慎重に評価し、希望するセキュリティレベルに合ったものを選択する必要があります。利用可能なオプションを活用して、トークン検証のための安全で回復力のあるセットアップを構築することを強くお勧めします。今後の研究記事では、各トークンフレームワークが提供するさまざまな検証スキームのセキュリティ特性について、より深く掘り下げる予定です。
4.デフォルト検証スキーム
フレームワークがデフォルトの検証メカニズムを提供しているかどうかを示します。これは重要です。なぜなら、ほとんどのチームは便宜上通常デフォルトのオプションを選択するからです。トークン発行者がデフォルトのオプションを選択する場合、セキュリティを評価し、セットアップのセキュリティを強化するために提供されているカスタマイズ機能を考慮することが重要です。
5.検証への参加
チームが検証プロセスに参加するオプションを持つか、追加のセキュリティレイヤーを追加するか、それともセキュリティを自分たちでコントロールするかをハイライトする。これは、既存のメカニズムに自分たちの検証セットアップを組み込むことでセキュリティを強化できるため重要です。これにより、他の検証方法が失敗した場合でも、潜在的な問題を防ぐために独自の保護手段に頼ることができます。
StarGate、Tapioca、BitGo、Cluster、およびAbracadabraのようなチームが、他のチームが利用できるカスタマイズをどのように活用できるかを示すために、LayerZero上で独自のDVNを運営しています。
より多くのチームが、余分な労力が必要ですが、この追加のセキュリティレイヤーを利用する必要があります。この機能を効果的に実装すると、重大な障害発生時に大きな問題を防ぐ上で非常に重要になります。
6.検閲耐性
メッセージを検閲するかどうか、およびどのように検閲するかを定義し、アプリケーションを無効にしたり、チームにとって利用性の問題を引き起こす可能性があります。ほとんどの場合、アプリが検閲されても、同じフレームワーク内の異なる検証メカニズムやリレーアに切り替えることができます。ただし、これには追加の努力が必要であり、短期的な問題に対する実用的な解決策とはならない場合があります。
7.オープンソース
オープンソースのコードベースを使用することで、開発者はフレームワークのセキュリティ機能と全体的なセットアップを監査し、実行されるコードについての透明性を確保することができます。
この表は、いくつかのトークンフレームワークの手数料構造を比較し、各フレームワークがプロトコル操作、メッセージング、およびその他の手数料に対してどのように処理するかに焦点を当てています。アプリケーションレベルでカスタムのアプリ固有の手数料を追加することができることに注意することが重要です。さらに、すべてのフレームワークで、リレーや送受信機などへ支払われる手数料を含む、検証と転送プロセスにはコストがかかります。
現在、ほとんどの手数料はメッセージの検証とリレーに関連しています。前述のように、すべてのトークンフレームワークは、メッセージを検証するための複数のメカニズムを使用するオプションを提供しています。追加の検証スキームごとにシステムのセキュリティが向上しますが、ユーザーの手数料とコストも増加します。
1.プロトコル手数料
これは、転送やその他の操作を実行するために、各フレームワークが請求するプロトコルレベルの手数料を指します。
DAOによる手数料スイッチの存在は、トークン発行者がトークンフレームワークの背後にある相互運用プロトコル(例:OFTsのLayerZeroまたはWarp TokenのHyperlane)に追加の手数料を支払う必要がある可能性を意味します。これにより、DAOガバナンスへの依存が生じ、手数料スイッチの変更が直接的にこれらのフレームワークを通じて発行されるトークンに影響を与え、手数料構造に関するDAOの決定の対象となります。
この表は、各フレームワークのスマートコントラクトの主要なプロパティを強調し、デプロイ履歴、セキュリティ監査、提供される報奨金、およびきめ細かな制御のための注目すべきカスタマイズに焦点を当てて、さまざまな程度の柔軟性、セキュリティ、およびカスタマイズを強調しています。
すべてのフレームワークでは、アプリが効果的に使用することで重要なセキュリティ機能であるレート制限とブラックリストを設定することができることに注目することが重要です。重大な財務損失を防ぐ. また、各フレームワークは、アプリの特定のニーズに応じて、スマートコントラクトを不変またはアップグレード可能ないずれかとして展開する柔軟性を提供します。
1. デプロイされた日時
このフィールドは、各フレームワークのスマートコントラクトが展開された時期を示しています。フレームワークが運用されてきた期間を示す洞察を提供します。
2. 監査
監査の回数はセキュリティの重要な指標です。監査はフレームワークのスマートコントラクトの整合性を検証し、システムを危険にさらす可能性のある脆弱性や問題を特定します。
3.バウンティ
バウンティは、外部のセキュリティ研究者が脆弱性を発見し、報告することを促すためにフレームワークが提供する金銭的なインセンティブを反映しています。
4.細かい制御のための注目すべき機能
スマートコントラクトフレームワークを使用すると、アプリケーションは特定のニーズに応じて様々なカスタマイズ可能なセキュリティ機能を実装することができます。この分野では、各フレームワークが提供するいくつかの主要なセキュリティ機能が強調されており、セキュリティを確保しています。
各フレームワークには独自の機能があり、技術的な焦点、統合、セキュリティ保証に応じて、開発者、プロトコル、プラットフォームからのさまざまなレベルの関与が見られました。
1.コアコントリビューター
このセクションでは、各フレームワークの構築と維持に積極的に関与しているさまざまなチームが紹介されています。オリジナルの開発チームを超えた多様な貢献者は、いくつかの要素のポジティブな指標です:(1)フレームワークへのより広範な需要、および(2)フレームワークのアクセシビリティと使いやすさ、許可なくまたは一般的な協力を通じて。
2.採用
採用は、各フレームワークの使用レベルと牽引力を反映しており、デプロイされたトークンの数と確保された合計価値によって測定されます。これにより、フレームワークが開発者やプロトコルにどの程度広く受け入れられているか、および資産を保護する際の信頼性に関する洞察が得られます。
3.注目のチーム
このセクションでは、各フレームワークを採用したトップチームとプロトコルが紹介され、その業界での信頼性と総合的な魅力が反映されています。
4.VMカバレッジ
VM カバレッジとは、各フレームワークでサポートされる仮想マシンの範囲を指します。VM の数が多いほど、異なるブロックチェーン環境間での柔軟性と互換性が向上します。これにより、アプリやトークン発行者は、利用できる多様なコミュニティの多様性が高まります。
5. デプロイされたチェーン
このフィールドは、各フレームワークが展開されているチェーンの数、つまり特定のフレームワークを使用することを決定した場合に各アプリまたはトークン発行者がサポートできるチェーンの数を反映しています。これは、アプリがアクセスできるマーケットとDeFiエコシステムの数に直接関係しています。チェーンの展開が高いほど、流動性へのより広範なアクセスが可能です。
さらに、異なるチェーン間でフレームワークをパーミッションレスに拡張する機能は大きな可能性を秘めていますが、開発者が重要なインフラストラクチャを自分で構築して維持する必要がある場合、困難な場合もあります。新しいチェーンのブリッジサポートを確立しようとしているチームなど、一部のチームにとっては、この取り組みは価値があるかもしれません。しかし、トークンのリーチに別のチェーンを追加しようとしているトークン発行者にとっては、不必要に複雑でリソースを大量に消費しているように感じる可能性があります。
6.ユニークな差別化要因
各フレームワークは、特別な機能、ツール、または統合形式でしばしば独自の差別化要素をもたらします。これらの差別化要素は、通常、特定の機能や利便性、または単にトークンのさらなる分散化を求める開発者やプロトコルに魅力を持たせます。
免責事項:このセクションはからのインサイトを反映しています@SlavaOnChain(LI.FIの開発者関係責任者)とさまざまなフレームワークに精通した開発者とのディスカッションを通じて、開発者の経験はバックグラウンドとユースケースによって異なる場合があります。
1.統合の容易さ
チームのサポートなしで初めての経験に基づいたフレームワークを使用してトークンを展開することがどれだけ簡単であったかを指します。
2.ドキュメンテーション
フレームワークのガイド、例、および参考資料が、開発者がプラットフォームを理解し、使用するのをサポートしているかどうかを評価します。
3. デベロッパーツール
フレームワークを使用してトークンを構築、テスト、展開するのを容易にするライブラリ、SDK、ユーティリティのセットを検討します。
トークンフレームワークが台頭しており、マルチチェーンの世界における価値移動についてすべてを変える可能性があります。現在、チェーン間で資産を移転するためには、流動性プールまたはGate.ioのテクノロジーを利用する必要があります。ソルバーズしかし、トークンフレームワークはこれらのニーズを排除します。代わりに、資産は相互運用性プロトコルを介して、直接目的のチェーン上に鋳造されることができます。
実際、トークンフレームワークは、ラップされた資産の死の鐘になる可能性があります。流動性をチェーン間で断片化する必要はもうありません。どのチェーンでも代替可能な資産を鋳造することができ、ガス代だけでチェーン間で取引することができます。私たちはすでにこの変化の兆しを目にしています。Circleは、USDCのラップドトークンの問題を回避するためにCCTPを立ち上げ、多くのビッグチームや価値の高いトークンがトークンフレームワークを採用しています。これは、物事が加速している兆候です。
しかし、第三者による感染リスクについては、正当な懸念があります。相互運用性プロトコルが失敗した場合、それらに基づいて構築されたすべてのプロジェクトに影響を与える可能性があります。これらのリスクにもかかわらず、採用は増え続けています。
別の見方をすれば、チェーンで抽象化された未来では、ソルバーがバックグラウンドでネイティブトークンをユーザーと交換するため、トークンフレームワークはもはや重要ではなくなります。そして、それにはいくつかの真実があります - ユーザーはトークンについて考える必要はありません - それは重要な角度を見逃しています。ソルバー自体についてはどうでしょうか。彼らにとって、トークンフレームワークは本当に便利です。在庫とリバランスの頭痛の種を解決し、チェーン間を移動するために流動性を必要としません。そのため、ソルバーはCCTPのようなフレームワークを使ってUSDCを移動させることを好みます - それは安価で効率的で、クロスチェーンのリバランスに最適です。
どのようにこれが形作られるかはまだ誰にもわかりません。おそらく、私たちは周辺の一握りのチェーンにだけトークンフレームワークが必要になるかもしれませんし、暗号通貨でトークンを展開するための標準になるかもしれません。今日私たちが知っていることは、相互運用フレームワークの採用が増えていること、そして競争も増えていることです。この成長の問題点は?分散です。競合するフレームワークは資産と流動性を分割し、一つの合うものがすべての解決策を見ることはできません。インセンティブはそれを許可しないだけです。
トークンを発行することは以前は簡単でした:それをイーサリアム上に展開すればよかったのです。そこにはユーザー、トレーダー、資本、そして流動性が集まっていました。しかし、今日、その状況ははるかに複雑です。流動性はビットコイン、イーサリアム、L2、ソラナ、その他のチェーンに分散しています。では、どこでトークンを発行すべきでしょうか?明確な答えはありません。
しかし、1つのチェーンを選ばなくてもいいとしたらどうでしょうか?どこでも機能するトークンを想像してみてください。それは、仮想通貨の経済全体にシームレスに流れるものです。
おかげで相互運用性プロトコル(またはブリッジとも呼ばれる)複数のチェーンにまたがる統一された市場でトークンを発行することが可能になりました。これにより、国境を越えたグローバルな流動性が生まれ、トークン発行者の操作が簡素化されます。より多くの流動性、より多くの採用、そして断片化の頭痛のない強力なネットワーク効果が生まれます。基本的に、どこでも機能するグローバルな銀行口座を持っているようなもので、すべてのDeFiエコシステムに統合されています。
この記事では、異なる相互運用性プロトコルで提供される主要なトークンフレームワークを比較します。目標は、独自の機能、強み、およびトレードオフを評価し、ネイティブでマルチチェーンのトークンを発行するための最良のソリューションをチームが選択するのに役立つことです。
以下のフレームワークを探求します:
さあ、潜り込みましょう。
トークンフレームワークは、既存のトークンをマルチチェーン化するか、最初からネイティブのマルチチェーントークンをローンチするかによって、2つの主要な方法で動作します。
トークンが最初の日から複数のチェーンでネイティブに発行されると、その供給量はそれらのチェーン全体に分散されます。トークンがチェーン間で移動されると、元のチェーンで燃やされ、目的のチェーンで鋳造され、総供給量が一定であることが保証されます。
それを会計システムと考えてください(多くの相互運用チームが説明しています)。以下に例を挙げます:1000トークンの総供給量を持つトークンXを考えてみましょう。需要に基づいて5つのチェーンに分散させます。
ユーザーがチェーンEからチェーンAにトークンを50個転送した場合、これらのトークンはチェーンEで燃やされ、チェーンAで鋳造されます。更新された分配は次のとおりです:
このプロセスにより、総供給量が1000トークンに保たれ、スリップなしでチェーン間のシームレスな転送が可能になります。
元々単一のチェーンに展開された既存のトークンに対しては、プロセスが若干異なります。全体の供給量は1つのチェーン上に存在し、別のチェーンに送金する際には、供給量の一部が送信元のチェーン上のスマートコントラクトにロックされ、同等の量が送信先のチェーン上に鋳造されます。
この方法は、ラップトークンがどのように動作するかと似ています。Chain A でロックされたトークンは、Chain B でラップされたバージョンが発行されることができます。しかし、これらのトークンは、バーン・ミント方法を使用して Chain B から Chain C に移動することもできます。複数のチェーンでロックする必要がなくなりました。元の供給は Chain A に残り、チェーン間の送金は単に、燃やされたトークンが発行されたものと一致していることを確認すれば済みます。
複数のチェーンにまたがる統一市場で取引可能なトークンを持つことの利点は、チームにとって重要です。
考えるCircleのクロスチェーン転送プロトコル(CCTP)CCTPを立ち上げることで、Circleはサポートされているチェーン全体でUSDCのシームレスな取引を可能にし、重要な問題に対処しました。
CircleのUSDCの独自の機能セットは、ほとんどのプロジェクトが持っていないカスタムビルドのブリッジ、CCTPのおかげです。これは、相互運用性プロトコルによって維持されるトークンフレームワークが登場する場所です。これらのフレームワークは、USDCに対してCCTPが提供するのと同様の解決策を提供し、任意のトークンに対しても同様の機能を提供します。これらのフレームワークを介してトークンを発行することで、プロジェクトは複数のサポートされたチェーン間で統一された市場を作成し、バーン/ロックおよびミントメカニズムを使用した簡単な転送を可能にすることができます。
トークンフレームワークがどのように機能し、その利点を理解したので、トークンを発行するチーム向けの市場で利用可能なさまざまなソリューションを比較しましょう。
以下は、表にカバーされている重要なセキュリティの側面の説明です:
1.検証メカニズム
検証メカニズムは、チェーン間での転送がどのように検証されるかの中核です。メッセージがどのように検証されるか、および各フレームワークが提供する検証メカニズムのセットアップのタイプについて言及しています。シングルオプション、複数のオプションを持つモジュラーシステム、または任意のブリッジと互換性のある柔軟な設計のいずれかであるかなど、トークン発行者がセキュリティ要件に基づいて最適なソリューションを選択できるようにします。
カスタム検証メカニズムには利点がありますが、デフォルトの設定が重要です。最も広く使用され続けていますしたがって、デフォルトの認証スキームのセキュリティに重点を置くことが重要です。チームは、セキュリティ設定を強化するために、デフォルトの上に追加の認証スキームを使用することが推奨されています。
ライブネスに関しては、複数の検証スキームに依存することには、利点と欠点の両方があります。プラス面としては、フォールトトレランスが向上し、1つのプロバイダーがダウンタイムが発生した場合でも、他のプロバイダーが運用を継続し、システムの信頼性を高めることができます。ただし、これによりシステムの複雑さも増します。スキームを追加するたびに潜在的な障害点が発生し、運用が中断されるリスクが高まります。
2.検証における柔軟性
検証メカニズムをカスタマイズする際の各フレームワークの柔軟性、具体的には、トークン発行者がさまざまなオプションから選択できるか、デフォルト設定に制限されるかを強調します。
3.注目すべき事前構築済み検証スキーム
プレビルド済みのスキームは、トークン発行者がメッセージの検証に使用できる使用準備が整った検証メカニズムです。広範な信頼性のあるプレビルドオプションを備えたフレームワークは、一般的には良い兆候です。
いくつかのフレームワークは他よりも多くの検証スキームを提供していますが、重要なのは彼らのセキュリティスペクトラムに基づいて評価します、単一のバリデータから包括的なバリデータセットまでの範囲に及ぶことができます。
例えば、OFTsは、CCIPやAxelarのようなより堅牢な選択肢と並んで、単一のバリデーターを使用するDVNオプションを提供しています。同様に、Warp Tokenは、Hyperlaneコミュニティによって実行されるバリデーターを含むマルチシグISMなどのISMを提供しています。同時に、Aggregation ISMのようなオプションを使用することで、チームは複数のISMからのセキュリティを組み合わせることができます。
さらに、これらの検証スキームの多くは、まだ広く採用されていないか、実際のシナリオで徹底的にテストされていない可能性があります。したがって、チームは利用可能な検証スキームの品質を慎重に評価し、希望するセキュリティレベルに合ったものを選択する必要があります。利用可能なオプションを活用して、トークン検証のための安全で回復力のあるセットアップを構築することを強くお勧めします。今後の研究記事では、各トークンフレームワークが提供するさまざまな検証スキームのセキュリティ特性について、より深く掘り下げる予定です。
4.デフォルト検証スキーム
フレームワークがデフォルトの検証メカニズムを提供しているかどうかを示します。これは重要です。なぜなら、ほとんどのチームは便宜上通常デフォルトのオプションを選択するからです。トークン発行者がデフォルトのオプションを選択する場合、セキュリティを評価し、セットアップのセキュリティを強化するために提供されているカスタマイズ機能を考慮することが重要です。
5.検証への参加
チームが検証プロセスに参加するオプションを持つか、追加のセキュリティレイヤーを追加するか、それともセキュリティを自分たちでコントロールするかをハイライトする。これは、既存のメカニズムに自分たちの検証セットアップを組み込むことでセキュリティを強化できるため重要です。これにより、他の検証方法が失敗した場合でも、潜在的な問題を防ぐために独自の保護手段に頼ることができます。
StarGate、Tapioca、BitGo、Cluster、およびAbracadabraのようなチームが、他のチームが利用できるカスタマイズをどのように活用できるかを示すために、LayerZero上で独自のDVNを運営しています。
より多くのチームが、余分な労力が必要ですが、この追加のセキュリティレイヤーを利用する必要があります。この機能を効果的に実装すると、重大な障害発生時に大きな問題を防ぐ上で非常に重要になります。
6.検閲耐性
メッセージを検閲するかどうか、およびどのように検閲するかを定義し、アプリケーションを無効にしたり、チームにとって利用性の問題を引き起こす可能性があります。ほとんどの場合、アプリが検閲されても、同じフレームワーク内の異なる検証メカニズムやリレーアに切り替えることができます。ただし、これには追加の努力が必要であり、短期的な問題に対する実用的な解決策とはならない場合があります。
7.オープンソース
オープンソースのコードベースを使用することで、開発者はフレームワークのセキュリティ機能と全体的なセットアップを監査し、実行されるコードについての透明性を確保することができます。
この表は、いくつかのトークンフレームワークの手数料構造を比較し、各フレームワークがプロトコル操作、メッセージング、およびその他の手数料に対してどのように処理するかに焦点を当てています。アプリケーションレベルでカスタムのアプリ固有の手数料を追加することができることに注意することが重要です。さらに、すべてのフレームワークで、リレーや送受信機などへ支払われる手数料を含む、検証と転送プロセスにはコストがかかります。
現在、ほとんどの手数料はメッセージの検証とリレーに関連しています。前述のように、すべてのトークンフレームワークは、メッセージを検証するための複数のメカニズムを使用するオプションを提供しています。追加の検証スキームごとにシステムのセキュリティが向上しますが、ユーザーの手数料とコストも増加します。
1.プロトコル手数料
これは、転送やその他の操作を実行するために、各フレームワークが請求するプロトコルレベルの手数料を指します。
DAOによる手数料スイッチの存在は、トークン発行者がトークンフレームワークの背後にある相互運用プロトコル(例:OFTsのLayerZeroまたはWarp TokenのHyperlane)に追加の手数料を支払う必要がある可能性を意味します。これにより、DAOガバナンスへの依存が生じ、手数料スイッチの変更が直接的にこれらのフレームワークを通じて発行されるトークンに影響を与え、手数料構造に関するDAOの決定の対象となります。
この表は、各フレームワークのスマートコントラクトの主要なプロパティを強調し、デプロイ履歴、セキュリティ監査、提供される報奨金、およびきめ細かな制御のための注目すべきカスタマイズに焦点を当てて、さまざまな程度の柔軟性、セキュリティ、およびカスタマイズを強調しています。
すべてのフレームワークでは、アプリが効果的に使用することで重要なセキュリティ機能であるレート制限とブラックリストを設定することができることに注目することが重要です。重大な財務損失を防ぐ. また、各フレームワークは、アプリの特定のニーズに応じて、スマートコントラクトを不変またはアップグレード可能ないずれかとして展開する柔軟性を提供します。
1. デプロイされた日時
このフィールドは、各フレームワークのスマートコントラクトが展開された時期を示しています。フレームワークが運用されてきた期間を示す洞察を提供します。
2. 監査
監査の回数はセキュリティの重要な指標です。監査はフレームワークのスマートコントラクトの整合性を検証し、システムを危険にさらす可能性のある脆弱性や問題を特定します。
3.バウンティ
バウンティは、外部のセキュリティ研究者が脆弱性を発見し、報告することを促すためにフレームワークが提供する金銭的なインセンティブを反映しています。
4.細かい制御のための注目すべき機能
スマートコントラクトフレームワークを使用すると、アプリケーションは特定のニーズに応じて様々なカスタマイズ可能なセキュリティ機能を実装することができます。この分野では、各フレームワークが提供するいくつかの主要なセキュリティ機能が強調されており、セキュリティを確保しています。
各フレームワークには独自の機能があり、技術的な焦点、統合、セキュリティ保証に応じて、開発者、プロトコル、プラットフォームからのさまざまなレベルの関与が見られました。
1.コアコントリビューター
このセクションでは、各フレームワークの構築と維持に積極的に関与しているさまざまなチームが紹介されています。オリジナルの開発チームを超えた多様な貢献者は、いくつかの要素のポジティブな指標です:(1)フレームワークへのより広範な需要、および(2)フレームワークのアクセシビリティと使いやすさ、許可なくまたは一般的な協力を通じて。
2.採用
採用は、各フレームワークの使用レベルと牽引力を反映しており、デプロイされたトークンの数と確保された合計価値によって測定されます。これにより、フレームワークが開発者やプロトコルにどの程度広く受け入れられているか、および資産を保護する際の信頼性に関する洞察が得られます。
3.注目のチーム
このセクションでは、各フレームワークを採用したトップチームとプロトコルが紹介され、その業界での信頼性と総合的な魅力が反映されています。
4.VMカバレッジ
VM カバレッジとは、各フレームワークでサポートされる仮想マシンの範囲を指します。VM の数が多いほど、異なるブロックチェーン環境間での柔軟性と互換性が向上します。これにより、アプリやトークン発行者は、利用できる多様なコミュニティの多様性が高まります。
5. デプロイされたチェーン
このフィールドは、各フレームワークが展開されているチェーンの数、つまり特定のフレームワークを使用することを決定した場合に各アプリまたはトークン発行者がサポートできるチェーンの数を反映しています。これは、アプリがアクセスできるマーケットとDeFiエコシステムの数に直接関係しています。チェーンの展開が高いほど、流動性へのより広範なアクセスが可能です。
さらに、異なるチェーン間でフレームワークをパーミッションレスに拡張する機能は大きな可能性を秘めていますが、開発者が重要なインフラストラクチャを自分で構築して維持する必要がある場合、困難な場合もあります。新しいチェーンのブリッジサポートを確立しようとしているチームなど、一部のチームにとっては、この取り組みは価値があるかもしれません。しかし、トークンのリーチに別のチェーンを追加しようとしているトークン発行者にとっては、不必要に複雑でリソースを大量に消費しているように感じる可能性があります。
6.ユニークな差別化要因
各フレームワークは、特別な機能、ツール、または統合形式でしばしば独自の差別化要素をもたらします。これらの差別化要素は、通常、特定の機能や利便性、または単にトークンのさらなる分散化を求める開発者やプロトコルに魅力を持たせます。
免責事項:このセクションはからのインサイトを反映しています@SlavaOnChain(LI.FIの開発者関係責任者)とさまざまなフレームワークに精通した開発者とのディスカッションを通じて、開発者の経験はバックグラウンドとユースケースによって異なる場合があります。
1.統合の容易さ
チームのサポートなしで初めての経験に基づいたフレームワークを使用してトークンを展開することがどれだけ簡単であったかを指します。
2.ドキュメンテーション
フレームワークのガイド、例、および参考資料が、開発者がプラットフォームを理解し、使用するのをサポートしているかどうかを評価します。
3. デベロッパーツール
フレームワークを使用してトークンを構築、テスト、展開するのを容易にするライブラリ、SDK、ユーティリティのセットを検討します。
トークンフレームワークが台頭しており、マルチチェーンの世界における価値移動についてすべてを変える可能性があります。現在、チェーン間で資産を移転するためには、流動性プールまたはGate.ioのテクノロジーを利用する必要があります。ソルバーズしかし、トークンフレームワークはこれらのニーズを排除します。代わりに、資産は相互運用性プロトコルを介して、直接目的のチェーン上に鋳造されることができます。
実際、トークンフレームワークは、ラップされた資産の死の鐘になる可能性があります。流動性をチェーン間で断片化する必要はもうありません。どのチェーンでも代替可能な資産を鋳造することができ、ガス代だけでチェーン間で取引することができます。私たちはすでにこの変化の兆しを目にしています。Circleは、USDCのラップドトークンの問題を回避するためにCCTPを立ち上げ、多くのビッグチームや価値の高いトークンがトークンフレームワークを採用しています。これは、物事が加速している兆候です。
しかし、第三者による感染リスクについては、正当な懸念があります。相互運用性プロトコルが失敗した場合、それらに基づいて構築されたすべてのプロジェクトに影響を与える可能性があります。これらのリスクにもかかわらず、採用は増え続けています。
別の見方をすれば、チェーンで抽象化された未来では、ソルバーがバックグラウンドでネイティブトークンをユーザーと交換するため、トークンフレームワークはもはや重要ではなくなります。そして、それにはいくつかの真実があります - ユーザーはトークンについて考える必要はありません - それは重要な角度を見逃しています。ソルバー自体についてはどうでしょうか。彼らにとって、トークンフレームワークは本当に便利です。在庫とリバランスの頭痛の種を解決し、チェーン間を移動するために流動性を必要としません。そのため、ソルバーはCCTPのようなフレームワークを使ってUSDCを移動させることを好みます - それは安価で効率的で、クロスチェーンのリバランスに最適です。
どのようにこれが形作られるかはまだ誰にもわかりません。おそらく、私たちは周辺の一握りのチェーンにだけトークンフレームワークが必要になるかもしれませんし、暗号通貨でトークンを展開するための標準になるかもしれません。今日私たちが知っていることは、相互運用フレームワークの採用が増えていること、そして競争も増えていることです。この成長の問題点は?分散です。競合するフレームワークは資産と流動性を分割し、一つの合うものがすべての解決策を見ることはできません。インセンティブはそれを許可しないだけです。