a16z：トークン設計の罠、解決策と未来の展望

出典リンク： TokenDesign: Mental Models, Capabilities, and Emerging Design Spaces with Eddy Lazzarin

動画作者：Eddy Lazzarin，a16z Crypto

編纂：倩雯，ChainCatcher

Eddy Lazzarinは暗号通貨チームのエンジニアリングリーダーであり、今回の動画では多くのトピックをカバーしています。彼は、トークンを設計する際に多くの人が直面する一般的な落とし穴とその可能な解決策を提起しました。彼はトークン設計が本当に初期の分野であり、実際にはプロトコル設計と呼ばれるべきだと考えています。なぜなら、トークンはあなたが作るべきものではなく、実際に作るべきはプロトコルだからです。

トークンは非常に興味深く、有用で、強力な新しいツールであり、プロトコルの設計方法と実現可能な結果を変えますが、トークンは設計の核心的な対象ではありません。現在のプロトコル設計は、設計者の理解がまだ完全または科学的なレベルに達していないため、"錬金術"のような学問です。ほとんどのプロジェクトは依然として大量の実験を必要としています。

今回の内容は三部構成で、まずはトークン設計における一般的な思考モデル、次にトークンの分類、そして最後にテクノロジーツリー理論、テクノロジーを利用して私たちの設計を成功させる方法についてお話しします。

一、思考モデル

まず、 トークンはプロトコルにサービスを提供するものであり、単なるツールであり、設計プロセスの一部に過ぎません。 それらは目標であるべきではありません。もしあなたが分散型のものを作りたいのであれば、トークンはその一部かもしれません。なぜなら、トークンは人々がプロトコルに対する所有権を持つのを助け、一致を保つことができるからです。

設計の三段階

私はポートフォリオ企業との接触を通じて、成功した設計プロセスから三つの段階をまとめました。

第一段階： 目標を定義すること。 目標は有効なプロトコル結果の簡潔な説明であり、明確であるべきです。つまり、具体的な設計によって実現されたかどうかです。したがって、成功と失敗については非常に明確な区分が必要です。もし私たちの目標が何であるかが不明確であれば、私たちは最初からやり直し、トークンを忘れる必要があります。理想的には、目標は測定可能であるべきで、たとえ成功を測定する方法がまだ不明確でも。

第二段階：制約を導入すること。 一般的に、制約には二種類あります。一つは内因性の制約、もう一つは外因性の制約です。内因性の制約は、設計プロセスを簡素化するために選択された制約であり、何かを選択する必要があるからです。たとえば、私たちが好きな興味深い特徴を制限することを選ぶことができます。私はSubset gameチームの講演を見たことがあります。彼らは「陷阵之志」や「超越光速」のような非常にクールなゲームを設計しましたが、彼らは制約の下で設計を行うことを言及しました。私はプロトコルを設計する人にこの講演をお勧めします。彼らが制限を選ぶとき、考慮するのはゲーム内で何が面白いかだけです。内因性の制約は多くの側面から来ることがありますが、通常は設計者自身が決定します。外因性の制約は自然界、技術状況、法規制などによって強制されます。後で詳しく説明します。

第三段階： メカニズムを設計すること。 一度制約と目標が定まれば、その目標を満たすメカニズムを明確に考えることができます。今、私たちがメカニズムを考えるとき、これらの制約に違反していないか、目標に近づいているかを本当に明確に理解する必要があります。プロトコルは一連のメカニズムであり、いくつかの制約に基づいて特定の目標に向かって推進されます。

MakerDAOを例に挙げます。彼らの目標は、安定したEthereumネイティブ資産を開発することです。もちろん、安定性とネイティブにはさまざまな解釈があります。彼らの制約は、価格がドルに連動していること、完全にネイティブのオンチェーン資産によってサポートされていることなどです。

一般的な落とし穴

（1）トークンを過度に重視すること。 私はこれについて少し触れましたが、もしあなたが常に報酬やトークンの配分を考えているだけで、システム内の参加者間の一貫性を保つ方法を考えていないのであれば、あなたはプロトコルを考えているのではなく、トークンを考えているかもしれません。トークンはプロトコルではなく、トークンはあなたの目標であるべきではありません。それは単なるツールであるべきです。

この落とし穴から抜け出す方法は？自問自答してください：トークンがなければ、このシステムはどのように機能しますか？ トークンを完全に取り除いた場合、システムが完全に失敗するのであれば、あなたはトークンの役割を過度に強調している可能性があります。システムのいくつかの重要な部分が失敗した場合、状況は前者よりも良いかもしれません。あなたのトークンは確かに重要であり、全体のバランスに必要ですが、トークンがなくてもシステムは依然として一貫しているのです。したがって、あなたはシステムの目標に戻って考えるべきです。

（2）設計空間に制限を設けないこと。 設計の際に、あなたにはあまりにも多くのアイデアや可能性があり、どこから始めればよいのかわからないことがあります。これは通常、目標が不明確であるため、目標を明確にする必要があります。また、外部からの制約についての理解が不足しているか、これらの制約を受け入れていない可能性もあります。

これらの制約を持ち込むと、設計空間が狭まり、より明確になります。制約の設計空間に役立つ二つの質問があります。それは、自問自答してください：あなたが構築したい強力な概念は何ですか？ それは深いアイデア、いくつかの利点、時代の変化などかもしれません。この強力な概念は何ですか？それを最大限に活用し、それに集中するにはどうすればよいのか、全体のシステムを考える前に。もう一つの質問は：この設計の最大の弱点は何ですか？ 何があなたを徹夜させるのか、それはあなたが行かないと思う点、心配している点、重要な弱点であり、それを改善するためにどのような制約を受け入れることができるかです。これにより、設計空間が大幅に制限されます。

（3）常にコミュニティに頼ること。 システムの特定の部分を設計する際に課題に直面し、それをすべてコミュニティに押し付けたり、見えない力に空白を埋めてもらうことを期待するのは非常に危険です。無許可のシステムが人気を博し、多くの驚くべき革新をもたらしていますが、コミュニティの行動を予測することはできず、彼らがあなたのシステム内の最も明白な問題を解決することを期待すべきではありません。

自問自答すべきいくつかの重要な質問があります。私たちがコミュニティに対して本当に期待していることは何ですか？私たちは彼らに何を提供していますか？私たちが彼らに提供しているトークンは十分ですか？それとも、私たちは彼らにどのような権限を与えていますか？彼らにはどのような能力がありますか？彼らはその責任をバランスさせるために十分な権限を与えられていますか？

もしあなたが彼らが何かを修正することを本当に期待しているのであれば、他の野心的な人々が興味深い拡張機能を追加したり、システムのいくつかのコンポーネントを修正したりすることを期待しているのであれば、まず自問自答してください。あなたはここで何かを構築しますか？もしあなたがそうしないのであれば、それは十分な成長の余地や力、柔軟性がないからです。そうであれば、他の人に期待する必要はありません。

二、トークン分類学

これは完全なリストではありません。私はチームメンバーとこの問題について議論しており、すぐに修正が行われると信じていますが、これは私たちがこれまでに見たトークンが示すすべての能力を列挙するためのものです。

トークンはプロトコル内のツールであり、ツールとプロトコルであり、より抽象的に言えば、データ構造です。では、このデータ構造が異なるプロトコルでどのように使用されるかをどのように見ていますか？それらは非常に一般的に五つのカテゴリに分けることができます：支払い、投票、利害関係、メタデータ、所有権（Claiming）。私は時間が経つにつれて、各カテゴリにもっと多くの解決策が出てくると信じています。このグループ分けは、少なくとも私には直感的に感じられます。

支払い

支払い機能はさらに三つのカテゴリに分けられます。まず、コミュニティやプロジェクトの内部通貨としての役割です。このようなケースはあまり見られませんが、いくつかの例があります。たとえば、SourceCredは興味深い例であり、FWBはこの方向に進んでいるかもしれません。これは、ドルのような従来の支払い方法とは異なり、特定のコミュニティ内に存在し、そのコミュニティがその通貨を制御しているため、彼らはその内部通貨に対して通貨政策などの手段を使用できます。たとえば、この通貨は安定しているべきであり、他の特定の資産の価値に連動すべきであり、彼らは具体的な全コミュニティの目標に基づいてそれを鋳造または燃焼するかもしれません。

第二に、最も一般的で理解しやすい暗号通貨の支払い方法は、ネットワークリソースとしての役割です。EthereumやBitcoinもこのカテゴリに含まれます。あなたは計算能力、ストレージ、または他のいくつかの暗号通貨ネットワークリソースに対して支払いを行います。私たちはEIP1559、ステーキング、流動性などを持っており、トークンがシステム内で異なるリソースを計算する方法を決定します。特に計算リソースに関してです。

第三の支払いトークンは、ゲーム内通貨のような存在です。たとえば、ゲーム、リソース、またはいくつかのプロトコルリソースは安定している必要があり、価格が設定される必要があります。なぜなら、あなたがシステムを使用する場合、これらのリソースは安定している必要があるからです。したがって、トークンの価格も相対的に安定している必要があります。供給が安定しているかどうかは重要ではありません。なぜなら、あなたがそれを使用するのは特定のアプリケーションの部分を実現するためだからです。

では、ステーブルコインはどこに位置づけられるべきでしょうか？もちろん、ステーブルコインは上記の三つの方法で支払いを行うことができます。しかし、ステーブルコインがステーブルコインである理由は、その背後にある安定化メカニズムにあります。したがって、ステーブルコインは一般的に所有権のカテゴリに属します。

所有権

一般的に、所有権には二種類あります。オンチェーン型（預金）とオフチェーン型（所有権）です。預金トークンは他のトークンに対する所有権を示します。例えば、uniswap LPトークンは、V2ではerc20、V3ではNFTです。Makerプロトコルから出てきた安定コインDaiもオンチェーン預金です。なぜなら、あなたや金庫の保有者がそれを使って基礎となる担保を請求するからです。したがって、預金トークンは、オフチェーン環境で他のトークンを請求するために使用できることを指します。

第二のトークンは、いくつかのオフチェーン資産の所有権を示します。したがって、これは現実世界の資産トークン、不動産トークン、または類似のものかもしれません。私たちはまだ大量のこのような例を見ていません。より現代的な例は、現在いわゆるリデンプション可能な物であり、トークンは実物と交換可能です。たとえば、NFTを使用してアート作品と交換することができます。このNFTは庭の所有権を表します。もしあなたが望むなら、いくつかの興味深い取引もあります。あなたは実物を使用してNFTを制御し、チップのようなデジタル機能を通じて、後続のNFTの所有権を制御することができます。

投票

投票を使用してプロジェクトに資金を提供したり、リソースを配分したり、団体として支払いまたは送金を行ったり、ソフトウェアのアップグレードを行ったりすることができます。また、リーダーを選ぶなど、社会的合意の手段としても使用できます。

ステーキング

トークンは、スマートコントラクトを通じて報酬を得る権利を持つように設計できます。ここには法的合意はありませんが、このメカニズムの運用は、トークンが何らかのオンチェーン活動から利益を得ることを意味します。例えば、Makerの場合、Makerがうまく機能し、Makerの多くのトークン保有者が自分の仕事をし、システムが正常に動作すれば、彼らは報酬の一部から利益を得ることになります。これはスマートコントラクトの方法であり、コミュニティの良好な管理を報いるためのプロトコルの設計方法です。

あなたはまた、トークンを法的合意の結果として設計し、報酬を得る権利を持つことができます。あなたは、会社の株式部分または株式シェアを表すトークンを作成することができます。もちろん、さまざまな法的要件や制限があります。かつては、安全なトークンを作成できると理論的に考えた人々がいましたが、私たちはまだ実質的な事例を見ていません。

トークンはまた、報酬を得るためにリスクを引き受けるために使用されます。Makerはこの原理を使用しています。もしMakerプロトコルに損失が発生すれば、より多くのMakerトークンが生成され、これがMaker保有者の持つ価値を希薄化します。Makerトークンを保有することで、保有者はリスクの一部を持ち、これがMaker保有者がコミュニティの構築を推進する部分的な理由でもあります。彼らが自分の投資を増やしたいと思うなら、彼らはこのシステムの発展を支持する必要があります。

メタデータ

まず、トークンはメンバーシップを表します。 それは、特定の空間にアクセスできるかどうか、特定のコミュニティにいるかどうか、または特定の団体にいるかどうかを決定します。プロトコルや第三者が作成したツールは、このメンバーシップ属性をあらゆる方法で利用できます。これは無許可であり、例えば、いくつかのNFTコミュニティは、トークンを保有している人だけが参加できることを決定することができます。例えば、このトークンを持つ人に特定の機能を提供するなどです。メンバーシップは、トークンによって提供される興味深いメタデータのタイプです。

トークンはまた、信用を表します。 一部の人々は、信用が移転可能であるべきかどうかを議論していますが、私は個人的にそれはそうでないべきだと思います。しかし、特定の状況では同質化される可能性があり、他の状況では非同質化される可能性があります。もしそれがあなたの業績を指すのであれば、それは非同質化されるかもしれません。情報源、信用、または異なるタイプの信用スコアリングシステムを指す場合、それは同質化される可能性があります。これは連続的なデータであり、したがってメタデータの一種です。

トークンはまた、アイデンティティや参照を表します。 ENSはこの点での一例であり、ENS名はアドレスを指し、更新可能であり、DNSシステムとは異なります。

オフチェーンデータはメタデータの一種です。例えば、オフチェーンのKYCや何らかの検証可能な証明書があります。もう一つの良い例は、学位や学術資格です。誰かがこの証明書をあなたに渡し、それが公開され、追跡可能であり、真実性があります。私たちはまだ、権限や能力をオンチェーンで表す多くの事例を見ていません。例えば、特定の実体があなたに権限を明示的に与えることがあります。例えば、関数を呼び出す能力、コードの一部を変更する能力、またはオンチェーンで何かを移転する能力です。トークンをインターフェースとして使用することさえできます。私たちはそのような例を見てきました。トークンURIの中にSVGデータだけでなく、HTML全体のウェブページを入れることもでき、少しのJavaScriptを入れることもできます。NFTの中にインターフェースを置き、そのインターフェースを制御することもできますし、人々が所有し、譲渡するオブジェクトにそのインターフェースを埋め込むこともできます。

興味深い例はBEEP3Rです。あなたはまずテキストをNFTとして鋳造し、それを持つことで他のBEEP3R保有者にテキストを放送できます。これらのテキストはBEEP3Rの小さな画像に表示されます。あなたがBEEP3R機を持っているとき、他のBEEP3R機の保有者に直接メッセージを送ることもできます。まるでxmtbを単独で使用するかのように。

このトークンの機能は何ですか？これはメンバーシップトークンであり、このトークンを持つことでメッセージを受信できます。アニメーションURLを正しく表示できるウォレットインターフェースは、この標準をサポートしている限り、あなたが受け取ったメッセージを表示できます。

これはまたアイデンティティトークンです。なぜなら、BP保有者として、あなたは情報を受信し、送信することができるからです。したがって、このことはその集合内でのみ発生します。これはまたアイデンティティトークンです。なぜなら、彼らはあなたのBPのトークンIDを使用してメッセージを送るからです。同時に、これはインターフェースとしても存在し、そのNFTに関連する情報を表示することができます。

三、テクノロジーツリー理論

私たちは、トークンが支払い手段やネットワークリソースとして大きく発展している分野がある一方で、インターフェースやメタデータなど、まだ成熟した発展を遂げていない分野もあることがわかります。では、なぜそうなっているのでしょうか？私は完全な答えを持っていませんが、これはテクノロジーツリーに関連している可能性があると思います。もちろん、このテクノロジーツリーはまだ完成していません。

私の疑問は、なぜ特定の製品が特定の時期に登場し、なぜ特定の製品が他の製品よりも長く存在するのかということです。借貸プロトコルを例に挙げると、ステーブルコインがなければ、借貸プロトコルが機能することは難しいでしょう。これは、借貸プロトコルで債務を借りるとき、安定した資産で表現したいからです。この資産の価格を予測できるからです。したがって、私たちはステーブルコインが必要であり、初めて本当に借貸プロトコルが存在することができます。

同様に、私たちはAMMを必要とする借貸プロトコルも持っています。なぜなら、特に初期のシンプルな借貸プロトコルを使用してレバレッジをかけたい場合、安定した資産を借りる必要があるからです。もしあなたがその安定した資産を迅速にその資産に交換したいのであれば、より多くのリスクエクスポージャーを持ちたいのであれば、AMMが必要です。正常に機能するAMMとステーブルコインが存在するまで、借貸プロトコルの発展はありませんでした。

では、正常に機能するAMMとステーブルコインをどのように得るのでしょうか？相互運用可能なトークン標準がなければ、これを達成するのは難しいです。なぜなら、ステーブルコイン、AMM、そしてそれらの周囲のすべてのシステムは、他のプロジェクトがどのようにそれらと接続するかを理解する必要があるからです。そして、erc20トークンを持つためには、完全にプログラム可能なスマートコントラクトが必要です。あなたは実際にはそれらを必要としないかもしれませんが、これがそれらがEthereum上で初めて登場した方法です。なぜなら、Ethereumはerc20トークン標準なしで立ち上げられたからです。私たちは完全なプログラム可能性が必要であり、十分にオープンな設計空間を残すことができるようにする必要があります。もちろん、これはさらに議論できます。しかし、要するに、私は技術ツリーが存在し、特定の技術が他の技術の前提条件であると考えています。

ここで二つの質問があります：未来のアプリケーションやプロトコルを解放する鍵となる技術は何ですか？ つまり、 有用な信用システムや分散型で信頼のないインターフェースを開発するために、私たちはどのような技術が必要ですか？ そして二つ目の質問は、少し一つ目の質問を反転させたもので、どのアプリケーションやプロトコルが今後の技術によって解放されるのでしょうか？

例えば、アカウントの抽象化、EIP4844、垂直ツリー、ゼロ知識機械学習などです。これらの質問が興味深いのは、もし私たちが特定の技術の到来を予見できるなら、 その技術が設計制約を軽減または導入できる場合、 それは私たちの設計にどのように影響を与えるでしょうか？ 特定の技術が制約を軽減できるなら、私たちはそれらを開発するために努力すべきでしょうか？

物事をテクノロジーツリーとして考えると、それは私たちが望む制約を達成するために必要なものや、今後のものを推論するのに役立つかもしれません。したがって、最初の制約のポイントに戻ると、新しい技術は私たちが以前直面していた制約を軽減したと考えています。たとえば、erc20標準がなければ、AMMやステーブルコイン設計の制約は、標準を導入する必要があるか、さまざまな設計に対応できる必要があります。

一般的なAMMを設計することを想像してみてください。しかし、特定のトークン標準を使用しない場合、これは非常に非常に困難です。私はこれがほぼ克服不可能な制約になると考えています。しかし、相互運用性の標準があるということは、私たちがerc20トークンを直接サポートできることを意味し、これが設計空間を制限し、実現可能にします。

もし私たちが未来にどのような技術が現れるかを予測できるなら、それは私たちのプロトコル設計の制約にどのような影響を与えるでしょうか？もし私たちが具体的な目標を持っているなら、または具体的な制約条件があるなら、私たちが必要とする技術は何ですか？その技術はこれらの制約を軽減し、新しいメカニズムを通じてこれらの目標を再び可能にすることができるでしょう。