トークンの設計: 大きな可能性、落とし穴、解決策、将来の展望

トークンは、プロトコルの設計方法と何を実現できるかを変える、非常に興味深く、便利で、強力な新しいツールですが、トークンは設計の中心ではありません。今日のプロトコル設計は、専門分野というよりも「錬金術」に似ています。設計者の理解は包括的または科学的とは程遠く、ほとんどのプロジェクトでは依然として多くの実験が必要だからです。
このセッションは 3 つの部分に分かれており、トークン設計における一般的な考え方から始まり、トークンの分類法が続き、トークンとは実際には何なのか、そしてその機能の開発と強化についてどのように考えることができるのかについてより具体的に話します。最後はテクノロジー ツリー理論、つまりテクノロジーを使用して設計を成功しやすくする方法です。
トークンの設計: 大きな可能性、落とし穴、解決策、将来の展望

思考モード

まず、トークンはプロトコルのためのものであり、設計プロセスの一部であるツールであり、目的であってはなりません。何かを分散化したい場合、トークンはおそらくその一部になります。なぜなら、人々がプロトコルの所有権を持つことは、人々にとっても有益であり、人々の連携を維持するためにも最適だからです。

設計の 3 つの段階

フェーズ 1: 目標を定義する

目標とは、有効なプロトコルの結果を簡潔に説明したものであり、それが特定の設計によって達成されたかどうかは明確である必要があります。したがって、成功と失敗を明確に区別する必要があります。目標が明確でない場合は、トークンのことを忘れて最初からやり直す必要があります。成功を測定する方法がまだわからない場合でも、目標は測定可能であることが理想的です。

フェーズ 2: 制限を導入する

一般に、制約には 2 つのタイプがあり、1 つは固有制約、もう 1 つは外生制約です。固有制約は、いくつかのトレードオフがあるため、または設計プロセスを簡素化するために選択される制約です。彼ら自身。

本質的な制約はさまざまなソースから得られますが、通常は設計者自身によって決定されます。外生的制約は、性質、テクノロジーの状態、規制などあらゆるものによってあなたに課せられます。それについては後で話します。

フェーズ 3: メカニズムの設計

制約と目標を設定したら、その目標を達成するメカニズムを明確に考えることができます。さて、メカニズムについて考えるときはいつでも、それがそれらの制約に違反し、その目標に近づくことができるかどうかが明確になるはずです。プロトコルは一連のメカニズムであり、すべてがいくつかの制約に従って特定の目標に向かって推進されます。

取る メーカーDAO 例として。彼らの目標は、安定したシステムを開発することです。 Ethereum ネイティブ資産。もちろん、安定性とネイティブ性についてはさまざまな解釈があります。その制限は、価格が米ドルに固定されており、ネイティブのオンチェーン資産などによって完全に裏付けられていることです。

トークンの設計: 大きな可能性、落とし穴、解決策、将来の展望

よくある落とし穴

トークンを重視しすぎます。トークンはプロトコルではないため、トークンが目的であってはなりません。それは単なるツールであるはずです。

この罠から抜け出すにはどうすればよいでしょうか?自問してみてください。トークンがなければ、このシステムはどのように機能するでしょうか?トークンを完全に削除するとシステムが完全に停止する場合は、トークンの役割を強調しすぎている可能性があります。システムのいくつかの主要な部分に障害が発生するよりはマシです。トークンは重要であり、全体のバランスには必要ですが、トークンがなくてもシステムは一貫性を保ちます。したがって、やはりシステムの目的について考える必要があります。

デザインスペースは無制限です。デザインでは、非常に多くのアイデアと可能性があり、できることが多すぎるため、どこから始めればよいのかさえわかりません。これは通常、目標が明確でないことが原因であるため、目標を絞り込む必要があります。また、外の世界があなたに課している制限を理解していない、またはあなたがその制限を受け入れていないことが原因である可能性もあります。

これらの制約を組み合わせると、設計スペースが縮小され、より明確になることがわかります。設計領域を制限するのに役立つ 2 つの質問は、次の 2 つです。構築したい強力なコンセプトは何ですか?それは、深いアイデア、利点、時代の流れの変化などかもしれません。この強力なコンセプトが何であるかを自問してください。システム全体を最初に考えるのではなく、システムを最大限に活用し、そこに集中するにはどうすればよいでしょうか?もう 1 つの質問は、この設計の最大の弱点は何でしょうか?何があなたを夜更かしさせているのか、それはあなたがうまくいかないかもしれないと思う点、あなたが心配している点、主な弱点、そしてそれを改善するためにあなたが受け入れることができる制約は何ですか?これにより、設計スペースが大幅に制限される可能性があります。

常にコミュニティに知らせてください。システムの特定の部分を設計したり、解決するためにそれらすべてをコミュニティに押し付けたり、目に見えない力がギャップを埋めることを期待したりすることには課題があります。常に人々は問題を見つけて解決してくれることを期待しますが、それは非常に危険です。パーミッションレス システムの人気と驚くべき革新にもかかわらず、コミュニティの行動を予測することはできません。また、コミュニティがシステム内の最も明白な問題を解決すると期待するべきではありません。

私たちはコミュニティに実際に何を期待し、何を与えているのでしょうか? 自問すべき重要な質問がいくつかあります。彼らに十分なトークンを与えるように要求するだけで十分ではないでしょうか?むしろ、私たちは彼らにどんな力を与えたのでしょうか?彼らにはどんな能力が与えられているのでしょうか?彼らはどのような所有権を持っていますか?彼らにはこの責任とのバランスをとるのに十分な権限が与えられていますか?

本当に彼らに何かを修正してもらうことを期待している場合、また、他の野心的な人々が興味深い拡張機能を追加したり、システムのいくつかのコンポーネントを修正したりすることを期待している場合は、まず自分自身に自問する必要があります。「ここに構築しますか?」十分な利益、十分なパワー、または十分な柔軟性がないためにそうしないのであれば、もう探す必要はありません。

トークン分類法

トークンはプロトコル内のツールであり、ツールでありプロトコルであり、より抽象的にはデータ構造です。では、このデータ構造がさまざまなプロトコルで使用されていることがどのようにわかるのでしょうか?これらは、支払い、投票、利害関係者、メタデータ、請求という 5 つの非常に一般的なカテゴリに分類できます。

支払う

支払い機能はさらに 3 つのカテゴリに分類されます。1 つ目は、コミュニティまたはプロジェクトの内部通貨としての機能です。このような例はあまりありませんが、いくつかの例があります。例えば、 ソースクレッド 興味深い例ですし、 FWB この方向に進んでいる可能性があります。

これは、通貨を管理する特定のコミュニティ内に存在し、この通貨が安定している必要があるなど、通貨を管理する特定のコミュニティ内に金融政策やその他の手段を使用できるため、USD 支払いなどの従来の支払い方法とは異なります。他の特定の資産の価値。コミュニティ全体の特定の目標に基づいて鋳造または焼却される可能性があります。

2 番目の、おそらく最も一般的に使用され、最もよく理解されている暗号通貨使用の支払い形式は、オンライン リソースとしてのものであり、イーサリアムとビットコインもこのカテゴリに分類されます。コンピューティング能力、ストレージ、またはその他の暗号通貨ネットワーク リソースに対して料金を支払います。我々は持っています EIP1559、ステーキング、流動性などを考慮して、システム内のさまざまなリソース、特にコンピューティングリソースを計算するためにトークンをどのように使用できるかを決定します。

同様のゲーム通貨として 3 番目の支払いトークンが存在します。たとえば、ゲーム、リソース、または一部のプロトコル リソースは安定している必要があり、価格を設定する必要があります。これは、システムを使用し、これらのリソースが安定している場合、トークンの価格も比較的安定している必要があるためです。アプリケーションの特定の部分を実装するためにのみ使用するため、安定供給されているかどうかは関係ありません。

では、ステーブルコインはどこに配置すべきでしょうか?もちろん、上記の3つの方法で安定した通貨を支払いとして使用することもできます。しかし、ステーブルコインをステーブルコインたらしめているのは、その背後にある安定化メカニズムであるため、ステーブルコインは一般に所有権のカテゴリーに分類されます。

所有権

一般に、所有権にはオンチェーン (デポジット) とオフチェーン (所有権) の 2 つのタイプがあります。デポジット トークンは他のトークンに対する所有権を表します。例としては、 Uniswap LP トークンこれは ERC-20 V2 では NFT、V3 では NFT です。 Makerプロトコルから派生したステーブルコインであるDAIも、あなたまたはボールト所有者が基礎となる担保を要求するために使用するため、オンチェーンデポジットでもあります。したがって、デポジット トークンは、オフチェーン環境で他のトークンを要求するために使用できることを意味します。

2 番目のトークンはオフチェーン資産の所有権を表すため、これは現実世界の資産トークン、不動産トークンなどのようなものになる可能性があります。このような例はあまり見たことがありません。より現代的な例は、現在引き換え可能と呼ばれるもので、トークンを物理的なオブジェクトと交換できます。たとえば、NFTはアートワークとアートワークを交換するために使用され、このNFTはヤードの所有権を表します。ご希望に応じて、いくつかの楽しい特典もあります。物理オブジェクトを使用して NFT を制御し、チップなどのデジタル機能を通じて後続の NFT の所有権を制御できます。

投票

投票は、プロジェクトに資金を提供したり、リソースを割り当てたり、グループとして支払いや送金を行ったり、ソフトウェアのアップグレードを行ったりするために使用できます。また、プロジェクトの将来計画を決定するためのリーダーの選出など、社会的合意の尺度としても使用できます。

プレッジ

トークンは、スマート コントラクトを通じて報酬を受け取る権利を得るように設計できます。ここには法的な合意はありませんが、メカニズムはトークンが何らかのオンチェーン アクティビティから恩恵を受けることを意味するように機能します。一例として Maker があります。 Maker トークン所有者が自分の仕事をうまくこなし、システムが適切に機能していれば、ある程度の見返りの恩恵を受けるでしょう。これがスマート コントラクトの方法であり、プロトコルの設計方法であり、コミュニティの適切なガバナンスに報いるものです。

返品の権利を与える法的合意の結果としてトークンを作成することもできます。もちろん、さまざまな法的要件や制限はありますが、会社の株式の一部または株式のシェアを表すトークンを作成できます。あまり見かけませんが、理論的にはセキュリティ トークンを作成できる人がいた時代がありました。

トークンは、リターンと引き換えにリスクを引き受けるためにも使用されます。メーカーはこの原理を利用しています。 Makerプロトコルで損失が発生した場合、より多くのMakerトークンが生成され、Maker保有者が保有する価値が薄まってしまいます。 Maker トークンを保有することで、保有者はある程度のリスクを負うことになり、これが Maker 保有者がコミュニティ構築を促進する原動力の 1 つとなっています。投資の価値が高まることを望むなら、このシステムの開発をサポートする必要があります。

まず、トークンはメンバーシップを表し、特定のスペースにアクセスできるかどうか、特定のコミュニティに所属しているかどうか、またはいくつかのグループに所属しているかどうかを決定します。一部のサードパーティによって作成されたプロトコルまたはツールは、このメンバーシップ属性を許可のない方法で使用できます。たとえば、一部の NFT コミュニティでは、このトークンを保持するなど、トークンを保持している人のみが参加できるように決定できます。特定の機能などを提供するもの。メンバーシップは、トークンによって提供される興味深いメタデータ タイプです。

トークンは評判も表します。評判を譲渡すべきかどうかを議論している人もいます。しかし、場合によっては均質になることもあれば、非均質になることもあります。それがあなたの業績に言及している場合、それは不均一である可能性があります。それが情報源、信用、またはさまざまな種類の信用スコアリング システムに言及している場合、それは同種である可能性があります。これは連続的なデータなので、一種のメタデータです。

トークンはアイデンティティまたは参照も表します。 Ens はその一例です。 ENS 名前はアドレスを指すことができ、更新することもできます。 DNS システム。

オフチェーン データは一種のメタデータである可能性があります。例としては、オフチェーン KYC またはある種の検証可能な証明書が挙げられます。もう 1 つの良い例は、卒業証書や学歴です。誰かがこの証明書を手渡すと、それは公的に表示され、追跡可能で、本物であることがわかります。オンチェーンで権限と機能を表現するケースはあまり見たことがありません。

関数を呼び出す、コードを変更する、オンチェーンで何かを転送するなどの権限を、エンティティが明示的に付与するようなものです。トークンをインターフェイスとして使用することも可能です。これまでに例を見てきましたが、トークン URI に SVG データを入れるだけでなく、HTML Web ページ全体を入れたり、少しの JavaScript を入れたりすることもできます。 nft にインターフェイスを配置したり、インターフェイスを制御したり、人々が所有および転送するオブジェクトにインターフェイスを埋め込んだりできます。

興味深い例としては、 ビープ3R、最初にテキストをNFTにミントし、次にそのテキストを他の人にブロードキャストできます ビープ3R それを所有することでホルダーになります。これらのテキストは、 ビープ3R. あなたが持っているとき ビープ3R マシンにメッセージを直接送信することもできます。 ビープ3R XMTB を単独で使用する場合と同様に、マシンホルダーを使用できます。

では、このトークンの機能は何でしょうか?これはメンバーシップトークンであり、このトークンを使用してメッセージを受信できます。この標準をサポートしている限り、アニメーション化された URL を正しく表現するウォレット インターフェイスであれば、受信したメッセージを表示できます。

BP 所有者として情報を送受信できるため、これは ID トークンでもあります。したがって、このことはそのセットでのみ発生します。 BP のトークン ID がメッセージとして送信されるため、これは ID トークンでもあります。同時にインターフェースとしても存在しており、NFTに関する情報を閲覧することができます。

トークンの設計: 大きな可能性、落とし穴、解決策、将来の展望

テックツリー理論

決済手段としてのトークンやネットワークリソースなど一部の分野は大きく進歩している一方、インターフェースやメタデータなどまだ発展していない分野もあることがわかります。では、なぜこのようなことが起こるのでしょうか?

一部の製品が特定の時間に表示されるのはなぜですか?また、一部の製品が他の製品よりも表示されるまでに時間がかかるのはなぜですか?融資プロトコルを例に挙げると、ステーブルコインなしで融資プロトコルが機能することを想像するのは困難です。これは、貸付契約で借金を貸すとき、その資産の価格を予測できるため、その資産を安定した資産で表したいためです。そのため、実際に貸付契約を結ぶ前にステーブルコインが必要です。

同様に、当社でも以下のような融資契約を結んでいます。 AMM なぜなら、レバレッジとして貸付契約、特に初期の単純な貸付契約を使用したい場合は、ステーブルコインなどの資産を借りられる必要があるからです。ステーブルコインをその資産と迅速に交換し、より多くのエクスポージャを獲得したい場合は、AMM が必要です。機能する AMM とステーブルコインが登場して初めて、融資プロトコルが進化しました。

しかし、機能する AMM とステーブルコインを入手するにはどうすればよいでしょうか?ステーブルコイン、AMM、およびそれらの周囲のすべてのシステムは、他のプロジェクトがそれらとどのように連携するかを理解する必要があるため、相互運用可能なトークン標準なしではこれを行うのは困難です。また、ERC-20 トークンを取得するには、完全にプログラム可能なスマート コントラクトが必要です。おそらく実際にはそれらは必要ありませんが、イーサリアムは ERC-20 トークン標準なしで開始されたため、これがイーサリアムに最初に登場した方法です。十分なオープンな設計スペースを残すには、完全なプログラマビリティが必要です。もちろん、これについてはさらに議論することができます。しかし結論として、特定のテクノロジーが他のテクノロジーの前提条件となるテクノロジー ツリーが存在すると思います。

ここで 2 つの質問があります。将来のアプリケーションやプロトコルを可能にする主要なテクノロジーは何ですか?つまり、有用な評判システムや分散型のトラストレスなインターフェースを開発するにはどのようなテクノロジーが必要なのでしょうか?そして 2 番目の質問は、最初の質問を逆にすると少し似ていますが、次のテクノロジーによってどのようなアプリケーションとプロトコルが利用可能になるのでしょうか?

たとえば、アカウントの抽象化、 EIP4844、垂直ツリー、ゼロ知識機械学習など。これらの質問は興味深いものです。なぜなら、設計上の制約を緩和または導入する特定のテクノロジーの登場を予見できた場合、それによって設計がどのように変化するのでしょうか?制約を軽減できる特定のテクノロジーがある場合、その開発にエネルギーを費やす必要があるでしょうか?

物事を技術ツリーとして考えると、今後何が起こるか、または必要な一連の制約を達成するために何が必要かを推論するのに役立つかもしれません。私の最初の限界点に話を戻すと、新しいテクノロジーは、私たちが以前に直面していた限界を緩和すると思います。たとえば、ERC-20 標準が存在しない場合、AMM またはステーブルコインの設計には、標準を導入するか、さまざまな異なる設計に対応できる必要があるかのどちらかが制約となります。

特定のトークン標準を使用せずに汎用 AMM を設計することを想像してみてください。それは非常に困難です。これはほとんど克服できない制限だと思いましたが、相互運用性標準があるということは、ERC-20 トークンを直接サポートできることを意味し、設計スペースが制限され、それが可能になります。

将来どのテクノロジーが出現するかを予測できる場合、それはプロトコル設計の制約にどのような影響を与えるでしょうか?特定の目標や特定の制約がある場合、どのようなテクノロジーが必要でしょうか?テクノロジーはこれらの制限を軽減し、新しいメカニズムを通じてこれらの目標を再び可能にすることができます。

免責事項:このウェブサイト上の情報は、一般的な市場の解説として提供されており、投資アドバイスを構成するものではありません。 投資する前に、独自の調査を行うことをお勧めします。

ニュースを追跡するために私たちに参加してください: https://linktr.ee/coincu

ウェブサイト: coincu.com

ハロルド

コインク ニュース

トークンの設計: 大きな可能性、落とし穴、解決策、将来の展望

トークンは、プロトコルの設計方法と何を実現できるかを変える、非常に興味深く、便利で、強力な新しいツールですが、トークンは設計の中心ではありません。今日のプロトコル設計は、専門分野というよりも「錬金術」に似ています。設計者の理解は包括的または科学的とは程遠く、ほとんどのプロジェクトでは依然として多くの実験が必要だからです。
このセッションは 3 つの部分に分かれており、トークン設計における一般的な考え方から始まり、トークンの分類法が続き、トークンとは実際には何なのか、そしてその機能の開発と強化についてどのように考えることができるのかについてより具体的に話します。最後はテクノロジー ツリー理論、つまりテクノロジーを使用して設計を成功しやすくする方法です。
トークンの設計: 大きな可能性、落とし穴、解決策、将来の展望

思考モード

まず、トークンはプロトコルのためのものであり、設計プロセスの一部であるツールであり、目的であってはなりません。何かを分散化したい場合、トークンはおそらくその一部になります。なぜなら、人々がプロトコルの所有権を持つことは、人々にとっても有益であり、人々の連携を維持するためにも最適だからです。

設計の 3 つの段階

フェーズ 1: 目標を定義する

目標とは、有効なプロトコルの結果を簡潔に説明したものであり、それが特定の設計によって達成されたかどうかは明確である必要があります。したがって、成功と失敗を明確に区別する必要があります。目標が明確でない場合は、トークンのことを忘れて最初からやり直す必要があります。成功を測定する方法がまだわからない場合でも、目標は測定可能であることが理想的です。

フェーズ 2: 制限を導入する

一般に、制約には 2 つのタイプがあり、1 つは固有制約、もう 1 つは外生制約です。固有制約は、いくつかのトレードオフがあるため、または設計プロセスを簡素化するために選択される制約です。彼ら自身。

本質的な制約はさまざまなソースから得られますが、通常は設計者自身によって決定されます。外生的制約は、性質、テクノロジーの状態、規制などあらゆるものによってあなたに課せられます。それについては後で話します。

フェーズ 3: メカニズムの設計

制約と目標を設定したら、その目標を達成するメカニズムを明確に考えることができます。さて、メカニズムについて考えるときはいつでも、それがそれらの制約に違反し、その目標に近づくことができるかどうかが明確になるはずです。プロトコルは一連のメカニズムであり、すべてがいくつかの制約に従って特定の目標に向かって推進されます。

取る メーカーDAO 例として。彼らの目標は、安定したシステムを開発することです。 Ethereum ネイティブ資産。もちろん、安定性とネイティブ性についてはさまざまな解釈があります。その制限は、価格が米ドルに固定されており、ネイティブのオンチェーン資産などによって完全に裏付けられていることです。

トークンの設計: 大きな可能性、落とし穴、解決策、将来の展望

よくある落とし穴

トークンを重視しすぎます。トークンはプロトコルではないため、トークンが目的であってはなりません。それは単なるツールであるはずです。

この罠から抜け出すにはどうすればよいでしょうか?自問してみてください。トークンがなければ、このシステムはどのように機能するでしょうか?トークンを完全に削除するとシステムが完全に停止する場合は、トークンの役割を強調しすぎている可能性があります。システムのいくつかの主要な部分に障害が発生するよりはマシです。トークンは重要であり、全体のバランスには必要ですが、トークンがなくてもシステムは一貫性を保ちます。したがって、やはりシステムの目的について考える必要があります。

デザインスペースは無制限です。デザインでは、非常に多くのアイデアと可能性があり、できることが多すぎるため、どこから始めればよいのかさえわかりません。これは通常、目標が明確でないことが原因であるため、目標を絞り込む必要があります。また、外の世界があなたに課している制限を理解していない、またはあなたがその制限を受け入れていないことが原因である可能性もあります。

これらの制約を組み合わせると、設計スペースが縮小され、より明確になることがわかります。設計領域を制限するのに役立つ 2 つの質問は、次の 2 つです。構築したい強力なコンセプトは何ですか?それは、深いアイデア、利点、時代の流れの変化などかもしれません。この強力なコンセプトが何であるかを自問してください。システム全体を最初に考えるのではなく、システムを最大限に活用し、そこに集中するにはどうすればよいでしょうか?もう 1 つの質問は、この設計の最大の弱点は何でしょうか?何があなたを夜更かしさせているのか、それはあなたがうまくいかないかもしれないと思う点、あなたが心配している点、主な弱点、そしてそれを改善するためにあなたが受け入れることができる制約は何ですか?これにより、設計スペースが大幅に制限される可能性があります。

常にコミュニティに知らせてください。システムの特定の部分を設計したり、解決するためにそれらすべてをコミュニティに押し付けたり、目に見えない力がギャップを埋めることを期待したりすることには課題があります。常に人々は問題を見つけて解決してくれることを期待しますが、それは非常に危険です。パーミッションレス システムの人気と驚くべき革新にもかかわらず、コミュニティの行動を予測することはできません。また、コミュニティがシステム内の最も明白な問題を解決すると期待するべきではありません。

私たちはコミュニティに実際に何を期待し、何を与えているのでしょうか? 自問すべき重要な質問がいくつかあります。彼らに十分なトークンを与えるように要求するだけで十分ではないでしょうか?むしろ、私たちは彼らにどんな力を与えたのでしょうか?彼らにはどんな能力が与えられているのでしょうか?彼らはどのような所有権を持っていますか?彼らにはこの責任とのバランスをとるのに十分な権限が与えられていますか?

本当に彼らに何かを修正してもらうことを期待している場合、また、他の野心的な人々が興味深い拡張機能を追加したり、システムのいくつかのコンポーネントを修正したりすることを期待している場合は、まず自分自身に自問する必要があります。「ここに構築しますか?」十分な利益、十分なパワー、または十分な柔軟性がないためにそうしないのであれば、もう探す必要はありません。

トークン分類法

トークンはプロトコル内のツールであり、ツールでありプロトコルであり、より抽象的にはデータ構造です。では、このデータ構造がさまざまなプロトコルで使用されていることがどのようにわかるのでしょうか?これらは、支払い、投票、利害関係者、メタデータ、請求という 5 つの非常に一般的なカテゴリに分類できます。

支払う

支払い機能はさらに 3 つのカテゴリに分類されます。1 つ目は、コミュニティまたはプロジェクトの内部通貨としての機能です。このような例はあまりありませんが、いくつかの例があります。例えば、 ソースクレッド 興味深い例ですし、 FWB この方向に進んでいる可能性があります。

これは、通貨を管理する特定のコミュニティ内に存在し、この通貨が安定している必要があるなど、通貨を管理する特定のコミュニティ内に金融政策やその他の手段を使用できるため、USD 支払いなどの従来の支払い方法とは異なります。他の特定の資産の価値。コミュニティ全体の特定の目標に基づいて鋳造または焼却される可能性があります。

2 番目の、おそらく最も一般的に使用され、最もよく理解されている暗号通貨使用の支払い形式は、オンライン リソースとしてのものであり、イーサリアムとビットコインもこのカテゴリに分類されます。コンピューティング能力、ストレージ、またはその他の暗号通貨ネットワーク リソースに対して料金を支払います。我々は持っています EIP1559、ステーキング、流動性などを考慮して、システム内のさまざまなリソース、特にコンピューティングリソースを計算するためにトークンをどのように使用できるかを決定します。

同様のゲーム通貨として 3 番目の支払いトークンが存在します。たとえば、ゲーム、リソース、または一部のプロトコル リソースは安定している必要があり、価格を設定する必要があります。これは、システムを使用し、これらのリソースが安定している場合、トークンの価格も比較的安定している必要があるためです。アプリケーションの特定の部分を実装するためにのみ使用するため、安定供給されているかどうかは関係ありません。

では、ステーブルコインはどこに配置すべきでしょうか?もちろん、上記の3つの方法で安定した通貨を支払いとして使用することもできます。しかし、ステーブルコインをステーブルコインたらしめているのは、その背後にある安定化メカニズムであるため、ステーブルコインは一般に所有権のカテゴリーに分類されます。

所有権

一般に、所有権にはオンチェーン (デポジット) とオフチェーン (所有権) の 2 つのタイプがあります。デポジット トークンは他のトークンに対する所有権を表します。例としては、 Uniswap LP トークンこれは ERC-20 V2 では NFT、V3 では NFT です。 Makerプロトコルから派生したステーブルコインであるDAIも、あなたまたはボールト所有者が基礎となる担保を要求するために使用するため、オンチェーンデポジットでもあります。したがって、デポジット トークンは、オフチェーン環境で他のトークンを要求するために使用できることを意味します。

2 番目のトークンはオフチェーン資産の所有権を表すため、これは現実世界の資産トークン、不動産トークンなどのようなものになる可能性があります。このような例はあまり見たことがありません。より現代的な例は、現在引き換え可能と呼ばれるもので、トークンを物理的なオブジェクトと交換できます。たとえば、NFTはアートワークとアートワークを交換するために使用され、このNFTはヤードの所有権を表します。ご希望に応じて、いくつかの楽しい特典もあります。物理オブジェクトを使用して NFT を制御し、チップなどのデジタル機能を通じて後続の NFT の所有権を制御できます。

投票

投票は、プロジェクトに資金を提供したり、リソースを割り当てたり、グループとして支払いや送金を行ったり、ソフトウェアのアップグレードを行ったりするために使用できます。また、プロジェクトの将来計画を決定するためのリーダーの選出など、社会的合意の尺度としても使用できます。

プレッジ

トークンは、スマート コントラクトを通じて報酬を受け取る権利を得るように設計できます。ここには法的な合意はありませんが、メカニズムはトークンが何らかのオンチェーン アクティビティから恩恵を受けることを意味するように機能します。一例として Maker があります。 Maker トークン所有者が自分の仕事をうまくこなし、システムが適切に機能していれば、ある程度の見返りの恩恵を受けるでしょう。これがスマート コントラクトの方法であり、プロトコルの設計方法であり、コミュニティの適切なガバナンスに報いるものです。

返品の権利を与える法的合意の結果としてトークンを作成することもできます。もちろん、さまざまな法的要件や制限はありますが、会社の株式の一部または株式のシェアを表すトークンを作成できます。あまり見かけませんが、理論的にはセキュリティ トークンを作成できる人がいた時代がありました。

トークンは、リターンと引き換えにリスクを引き受けるためにも使用されます。メーカーはこの原理を利用しています。 Makerプロトコルで損失が発生した場合、より多くのMakerトークンが生成され、Maker保有者が保有する価値が薄まってしまいます。 Maker トークンを保有することで、保有者はある程度のリスクを負うことになり、これが Maker 保有者がコミュニティ構築を促進する原動力の 1 つとなっています。投資の価値が高まることを望むなら、このシステムの開発をサポートする必要があります。

まず、トークンはメンバーシップを表し、特定のスペースにアクセスできるかどうか、特定のコミュニティに所属しているかどうか、またはいくつかのグループに所属しているかどうかを決定します。一部のサードパーティによって作成されたプロトコルまたはツールは、このメンバーシップ属性を許可のない方法で使用できます。たとえば、一部の NFT コミュニティでは、このトークンを保持するなど、トークンを保持している人のみが参加できるように決定できます。特定の機能などを提供するもの。メンバーシップは、トークンによって提供される興味深いメタデータ タイプです。

トークンは評判も表します。評判を譲渡すべきかどうかを議論している人もいます。しかし、場合によっては均質になることもあれば、非均質になることもあります。それがあなたの業績に言及している場合、それは不均一である可能性があります。それが情報源、信用、またはさまざまな種類の信用スコアリング システムに言及している場合、それは同種である可能性があります。これは連続的なデータなので、一種のメタデータです。

トークンはアイデンティティまたは参照も表します。 Ens はその一例です。 ENS 名前はアドレスを指すことができ、更新することもできます。 DNS システム。

オフチェーン データは一種のメタデータである可能性があります。例としては、オフチェーン KYC またはある種の検証可能な証明書が挙げられます。もう 1 つの良い例は、卒業証書や学歴です。誰かがこの証明書を手渡すと、それは公的に表示され、追跡可能で、本物であることがわかります。オンチェーンで権限と機能を表現するケースはあまり見たことがありません。

関数を呼び出す、コードを変更する、オンチェーンで何かを転送するなどの権限を、エンティティが明示的に付与するようなものです。トークンをインターフェイスとして使用することも可能です。これまでに例を見てきましたが、トークン URI に SVG データを入れるだけでなく、HTML Web ページ全体を入れたり、少しの JavaScript を入れたりすることもできます。 nft にインターフェイスを配置したり、インターフェイスを制御したり、人々が所有および転送するオブジェクトにインターフェイスを埋め込んだりできます。

興味深い例としては、 ビープ3R、最初にテキストをNFTにミントし、次にそのテキストを他の人にブロードキャストできます ビープ3R それを所有することでホルダーになります。これらのテキストは、 ビープ3R. あなたが持っているとき ビープ3R マシンにメッセージを直接送信することもできます。 ビープ3R XMTB を単独で使用する場合と同様に、マシンホルダーを使用できます。

では、このトークンの機能は何でしょうか?これはメンバーシップトークンであり、このトークンを使用してメッセージを受信できます。この標準をサポートしている限り、アニメーション化された URL を正しく表現するウォレット インターフェイスであれば、受信したメッセージを表示できます。

BP 所有者として情報を送受信できるため、これは ID トークンでもあります。したがって、このことはそのセットでのみ発生します。 BP のトークン ID がメッセージとして送信されるため、これは ID トークンでもあります。同時にインターフェースとしても存在しており、NFTに関する情報を閲覧することができます。

トークンの設計: 大きな可能性、落とし穴、解決策、将来の展望

テックツリー理論

決済手段としてのトークンやネットワークリソースなど一部の分野は大きく進歩している一方、インターフェースやメタデータなどまだ発展していない分野もあることがわかります。では、なぜこのようなことが起こるのでしょうか?

一部の製品が特定の時間に表示されるのはなぜですか?また、一部の製品が他の製品よりも表示されるまでに時間がかかるのはなぜですか?融資プロトコルを例に挙げると、ステーブルコインなしで融資プロトコルが機能することを想像するのは困難です。これは、貸付契約で借金を貸すとき、その資産の価格を予測できるため、その資産を安定した資産で表したいためです。そのため、実際に貸付契約を結ぶ前にステーブルコインが必要です。

同様に、当社でも以下のような融資契約を結んでいます。 AMM なぜなら、レバレッジとして貸付契約、特に初期の単純な貸付契約を使用したい場合は、ステーブルコインなどの資産を借りられる必要があるからです。ステーブルコインをその資産と迅速に交換し、より多くのエクスポージャを獲得したい場合は、AMM が必要です。機能する AMM とステーブルコインが登場して初めて、融資プロトコルが進化しました。

しかし、機能する AMM とステーブルコインを入手するにはどうすればよいでしょうか?ステーブルコイン、AMM、およびそれらの周囲のすべてのシステムは、他のプロジェクトがそれらとどのように連携するかを理解する必要があるため、相互運用可能なトークン標準なしではこれを行うのは困難です。また、ERC-20 トークンを取得するには、完全にプログラム可能なスマート コントラクトが必要です。おそらく実際にはそれらは必要ありませんが、イーサリアムは ERC-20 トークン標準なしで開始されたため、これがイーサリアムに最初に登場した方法です。十分なオープンな設計スペースを残すには、完全なプログラマビリティが必要です。もちろん、これについてはさらに議論することができます。しかし結論として、特定のテクノロジーが他のテクノロジーの前提条件となるテクノロジー ツリーが存在すると思います。

ここで 2 つの質問があります。将来のアプリケーションやプロトコルを可能にする主要なテクノロジーは何ですか?つまり、有用な評判システムや分散型のトラストレスなインターフェースを開発するにはどのようなテクノロジーが必要なのでしょうか?そして 2 番目の質問は、最初の質問を逆にすると少し似ていますが、次のテクノロジーによってどのようなアプリケーションとプロトコルが利用可能になるのでしょうか?

たとえば、アカウントの抽象化、 EIP4844、垂直ツリー、ゼロ知識機械学習など。これらの質問は興味深いものです。なぜなら、設計上の制約を緩和または導入する特定のテクノロジーの登場を予見できた場合、それによって設計がどのように変化するのでしょうか?制約を軽減できる特定のテクノロジーがある場合、その開発にエネルギーを費やす必要があるでしょうか?

物事を技術ツリーとして考えると、今後何が起こるか、または必要な一連の制約を達成するために何が必要かを推論するのに役立つかもしれません。私の最初の限界点に話を戻すと、新しいテクノロジーは、私たちが以前に直面していた限界を緩和すると思います。たとえば、ERC-20 標準が存在しない場合、AMM またはステーブルコインの設計には、標準を導入するか、さまざまな異なる設計に対応できる必要があるかのどちらかが制約となります。

特定のトークン標準を使用せずに汎用 AMM を設計することを想像してみてください。それは非常に困難です。これはほとんど克服できない制限だと思いましたが、相互運用性標準があるということは、ERC-20 トークンを直接サポートできることを意味し、設計スペースが制限され、それが可能になります。

将来どのテクノロジーが出現するかを予測できる場合、それはプロトコル設計の制約にどのような影響を与えるでしょうか?特定の目標や特定の制約がある場合、どのようなテクノロジーが必要でしょうか?テクノロジーはこれらの制限を軽減し、新しいメカニズムを通じてこれらの目標を再び可能にすることができます。

免責事項:このウェブサイト上の情報は、一般的な市場の解説として提供されており、投資アドバイスを構成するものではありません。 投資する前に、独自の調査を行うことをお勧めします。

ニュースを追跡するために私たちに参加してください: https://linktr.ee/coincu

ウェブサイト: coincu.com

ハロルド

コインク ニュース

72 回訪問、今日 1 回訪問