このコンテンツは 3 つの部分に分かれています。

1 つ目は、トークン設計における一般的な思考パターンです。

2 番目はトークンの分類で、実際のトークンとは何か、そしてその機能の開発と強化についてどのように考えているかについてより具体的に説明します。

最後に、テクノロジー ツリー理論、つまりテクノロジーを使用して設計をより成功させる方法があります。

1. 思考モデル

まず、トークンはプロトコルを提供するために存在し、単なるツールであり、設計プロセスの一部であり、目的であってはなりません。何かを分散化したい場合、トークンをその一部にすることができます。トークンは人々にプロトコルの所有権を与え、人々の連携を保つのに優れているからです。

設計の 3 段階

ポートフォリオ企業とのやり取りの中で、私は成功する設計プロセスの 3 つの段階を特定しました。

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

フェーズ 2: 制限を導入します。一般に、制限には 2 種類あり、1 つは内生的な制限で、もう 1 つは外生的な制限です。内生的な制限は、いくつかのトレードオフを行う必要があるため、設計プロセスを簡素化するために選択した制限です。または、それらはトレードオフです。彼ら自身。たとえば、気に入った興味深い機能を制限することもできます。内生的制約はさまざまなソースから発生する可能性がありますが、通常は設計者自身によって決定されます。外生的制約は、自然、技術的条件、規制などさまざまなものによって課せられます。詳しくは後ほどお話します。

第 3 段階: メカニズムの設計。制約と目標を設定したら、その目標を満たすメカニズムについて明確に考えることができます。さて、メカニズムについて考えるときはいつでも、それがこれらの制約に違反しているかどうか、そしてそれが私たちをその目標に近づけるかどうかを明確にする必要があります。プロトコルは一連のメカニズムであり、すべてはいくつかの制約のもとで特定の目標に向かって推進されます。

よくある落とし穴

(1) トークンの偏重。これについては少し触れましたが、システム内の参加者間の一貫性を維持する方法ではなく、報酬やトークンの配布について常に考えている場合は、おそらくプロトコルについてではなく、トークンについて考えているでしょう。トークンはプロトコルではなく、トークンが目的であってはなりません。それは単なるツールであるはずです。

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

(2) 設計スペースに制限がありません。デザインでは、非常に多くのアイデアと可能性があり、できることが多すぎるため、どこから始めればよいのかさえわかりません。これは通常、目標が明確でないため、目標を改良する必要があります。また、外の世界によってあなたに課されている制限について理解が足りていない、またはこれらの制限をまだ受け入れていない可能性もあります。

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

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

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

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

2. トークン分類法

これは完全なリストではありません。これについてはチームメンバーと話し合っており、すぐに改訂すると確信していますが、これは、これまでにトークンが実証したすべての機能を列挙したものにすぎません。

トークンはプロトコル内のツールであり、ツールでありプロトコルであり、より抽象的にはデータ構造です。では、このデータ構造がさまざまなプロトコルで使用されることをどのように確認できるのでしょうか?それらは、支払い、投票、利害関係者、メタデータ、所有権 (請求) の 5 つの非常に一般的なカテゴリに分類できます。少なくとも私にとっては、時間の経過とともに、このグループ化にはさらに多くのソリューションが存在すると考えられます。より直感的に。

支払う

まず、コミュニティまたはプロジェクトの内部通貨として。これは、通貨を管理する特定のコミュニティ内に存在し、内部通貨に基づいて金融政策やその他の手段を使用できるため、米ドル支払いなどの従来の支払い方法とは異なります。たとえば、この通貨は安定している必要があります。 , それは他の特定の資産の価値に結び付けられるべきであり、おそらく彼らは特定のコミュニティ全体の目標に基づいてそれを鋳造したり燃やしたりするでしょう。

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

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

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

所有

一般に、所有権にはオンチェーン (デポジット) とオフチェーン (所有権) の 2 つのタイプがあります。

最初のオンチェーン (デポジット) デポジット トークンは、他のトークンの所有権を表します。Uniswap LP トークンは、V2 では ERC 20、V3 では NFT です。 MAKER プロトコルから出てくるステーブルコイン DAI も、あなたまたはボールト所有者が基礎となる担保を要求するために使用するため、オンチェーン預金でもあります。したがって、デポジット トークンは、オフチェーン環境で他のトークンを要求するために使用できることを意味します。

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

投票する

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

誓約

トークンは、スマート コントラクトを通じて報酬を受け取る権利を得ることができるように設計できます。ここには法的な合意はありませんが、このメカニズムの動作は、トークンが何らかのオンチェーン アクティビティから恩恵を受けることを意味します。例としては DroneLink が挙げられます。DroneLink がうまく機能し、DRONE の多数のトークン所有者がその仕事をし、システムが正常に実行されれば、彼らは何らかの報酬から恩恵を受けることになります。それがスマート コントラクトのやり方であり、プロトコルの設計方法です。良い報酬を得るためにコミュニティの管理。

リターンを受け取る権利を与える法的合意の結果としてトークンを作成することもできます。企業の株式部分または株式のシェアを表すトークンを作成できますが、当然ながらさまざまな法的要件や制限があります。

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

メタデータ

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

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

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

オフチェーン データは一種のメタデータである可能性があります。例としては、オフチェーン KYC またはある種の検証可能な証明書が挙げられます。もう 1 つの良い例は、卒業証書や学歴です。誰かがこの証明書を手渡すと、それは公的に閲覧でき、追跡可能で、本物であることがわかります。オンチェーンで権限と機能を表現するケースはあまり見たことがありません。たとえば、一部のエンティティは、関数の呼び出し、コードの一部の変更、チェーン上の何かの転送などのアクセス許可を明示的に付与します。トークンをインターフェイスとして使用することも可能で、トークン URI に SVG データを配置できるだけでなく、HTML ページ全体を配置したり、少しの JavaScript を配置したりする例も見てきました。 nft にインターフェイスを配置してそのインターフェイスを制御することも、人々が所有して転送するオブジェクトにインターフェイスを埋め込むこともできます。

興味深い例は BEEP3R です。最初にテキストを NFT にミントし、次にテキストを所有することで他の BEEP3R ホルダーにテキストをブロードキャストできます。 BEEP3Rの小さい画像上に文字が表示されます。 BEEP3R マシンをお持ちの場合は、XMTB を単独で使用する場合と同様に、他の BEEP3R マシン所有者にメッセージを直接送信することもできます。

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

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

3. テクノロジーツリー理論

支払い方法としてのトークンやネットワーク リソースなど、いくつかの領域はすでに大きく開発されていますが、インターフェイスやメタデータなどの一部の領域はまだ開発されていないことがわかります。では、なぜそうなるのでしょうか？完全な答えはありませんが、技術ツリーと関係があるのではないかと考えていますが、もちろん完全には程遠いです。

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

同様に、AMM を必要とする融資プロトコルもあります。これは、レバレッジのために融資プロトコル、特に初期の単純な融資プロトコルを使用したい場合は、ステーブルコインなどの資産を借入できる必要があるためです。ステーブルコインをその資産と迅速に交換し、より多くのエクスポージャを獲得したい場合は、AMM が必要です。 AMM とステーブルコインが機能するまでは、融資プロトコルの開発はありません。

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

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

たとえば、アカウント抽象化、EIP 4844、垂直ツリー、ゼロ知識機械学習などです。これらの質問は興味深いものです。なぜなら、設計上の制約を緩和または導入できる特定のテクノロジーの登場を予見できたら、それによって設計はどのように変わるのでしょうか?特定の技術で制約を緩和できるのであれば、その開発に力を入れるべきでしょうか？

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

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

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