この記事の由来は a16z cryptoこの記事の由来は

、原著者：Guy Wuollet、Odaily翻訳者のKatie Guによって編集されました。

実際、多くのチームは、プロジェクトに「適切な」トークン設計を見つけるのに苦労しています。しかし、業界にはテスト済みの設計フレームワークが不足しているため、将来の世代は先代と同じ課題に繰り返し遭遇します。幸いなことに、初期のトークン設計の成功例も（少数ですが）あります。最も効果的なトークン モデルには、その目的に固有の固有の要素がありますが、欠陥のあるトークン設計のほとんどには、いくつかの共通のバグがあります。したがって、この記事では、なぜ単なる「トークン経済学」ではなくトークンの研究と設計を考慮する必要があるのか​​を説明し、7 つの「落とし穴」のヒントを挙げます。

副題

#1 トークン設計の目標を明確にするトークン設計における最大の問題は、明確な目標を達成する前に、複雑なトークン モデルをどのように構築するかということです。最初のステップは、目標を定義し、それが何なのか、なぜ重要なのか、チーム全体が完全に理解していることを確認することです。本当に何を達成しようとしているのでしょうか?

目標を厳密に定義しないと、再設計が必要になり、時間が無駄になることがよくあります。目的を明確にすることは、一部のトークン エコノミー設計でよくある「トークン エコノミー設計のためにトークン エコノミーを発明する」問題を回避するのにも役立ちます。

• また、目標はトークン自体にあるべきですが、これはしばしば見落とされます。明確な目標の例は次のとおりです。

• 最適なスケーラビリティとサポート モデリングを可能にするトークン モデルを使用してゲームを設計します。

• DeFiプロトコルは、参加者間でリスクを合理的に配分するトークンモデルを設計したいと考えています。

• 金銭を保証する評判プロトコルを設計することは、評判を直接置き換えることはできません（たとえば、評判シグナルから流動性を切り離すことによって）。

• ファイルを低遅延で利用可能な状態に保つストレージ ネットワークを設計します。

• 最大限の経済的安全性を提供するステーキング ネットワークを設計します。

真のユーザーの好みや最大限のエンゲージメントを引き出すガバナンス メカニズムを設計します。

リストは続きます。トークンがあらゆるユースケースをサポートし、あらゆる目標を達成できるようにします。その逆ではありません。では、明確な目標を定義するにはどうすればよいでしょうか?

明確に定義された目標は、多くの場合、「プロジェクトのミッション」から導き出されます。 「プロジェクトのミッション」は高レベルで抽象的なものになりがちですが、目標は具体的で最も基本的な形に落とし込む必要があります。

EIP-1559 を例に挙げてみましょう。 Roughgarden 氏は、EIP-1559 の明確な目標を述べました。「EIP-1559 は、需要が急成長する時期を除いて、『明確な最良入札』の形で単純なコスト見積もりを行うことで、ユーザー エクスペリエンスを向上させる必要があります。」

これら 2 つの例に共通するのは、大まかな目標を述べ、他の人が目標を理解できるように関連する例えを提供し、続いてその目標を最もよくサポートする設計の代替案の概要を説明することです。

副題

#2 基本原則に照らして既存の作品を評価する

新しいものを作成するときは、すでに持っているものから始めるのが良いでしょう。既存のプロトコルや文献を評価するときは、技術的なメリットに基づいて客観的に評価する必要があります。これらの要素は、トークン モデルが定められた目標を達成する能力には関係しない可能性があります。評価、人気、またはトークン モデルを評価するその他の単純な方法により、ビルダーは「さらに回り道をする」可能性があります。実際には機能しないにもかかわらず、他のトークン モデルが適切に機能すると仮定すると、「本質的に欠陥のある」トークン モデルを作成している可能性があります。

副題

#3 仮定を明確にする

自分の仮定を明確に述べます。トークンの構築に集中していると、基本的な前提を当然のことと考えてしまいがちです。また、実際に行っている仮定を誤って伝えることも簡単です。

たとえば、ハードウェアのボトルネックが計算速度であると想定している新しいプロトコルを考えてみましょう。その仮定をトークン モデルの一部にすること (たとえば、プロトコルに参加するために必要なハードウェア コストを制限することによって) は、設計を望ましい動作に合わせるのに役立ちます。

仮定を明確にすると、トークンの設計を理解し、それが機能することを確認しやすくなります。また、仮定を明確にしない限り、仮定をテストすることはできません。

副題

#4 仮説を検証する

「問題を引き起こすのは、何を知らないかではない。問題がないと確信していることである。」という格言があります。

トークン設計者は、さまざまな方法で仮説を検証できます。厳密な統計モデリングは、多くの場合エージェントベースのモデルの形式で行われ、これらの仮説をテストするのに役立ちます。ユーザーの行動に関する仮説は、多くの場合、ユーザーと話すことによって、できれば (ユーザーが言っていることではなく) 実際に何をしているかを観察することによってテストすることもできます。これは、特にサンドボックス環境で経験的な結果を生み出すインセンティブ付きのテストネットを通じて、検証が成功する可能性が高くなります。正式な検証や集中的な監査も、コード ベースが期待どおりに機能していることを確認するのに役立ちます。

副題

#5 「抽象的な障壁」を明確にする

「抽象化バリア」は、システムまたはプロトコルの異なる層間のインターフェイスです。これは、システムのさまざまなコンポーネントを分離するために使用され、各コンポーネントを独立して設計、実装、変更できるようにします。明確な抽象化バリアは、エンジニアリングのすべての分野、特にソフトウェア設計で役立ちますが、分散開発や個人では理解できない複雑なシステムを構築する大規模なチームではさらに必要です。

トークンの設計において、抽象化の障壁を取り除く目的は、複雑さを最小限に抑えることです。トークン モデルの異なるコンポーネント間の (内部) 依存関係を減らすと、コードがよりクリーンになり、バグが減り、トークンの設計が改善されます。

一例として、多くのブロックチェーンは大規模なエンジニアリング チームによって構築されています。チームは、長期にわたるハードウェアコストについての仮定を立て、それを使用して、特定のトークン価格でブロックチェーンにハードウェアを提供するマイナーの数を決定する可能性があります。別のチームがパラメータとしてトークン価格に依存していても、ハードウェア コストに関する最初のチームの仮定を知らない場合、簡単に矛盾する仮定を立てる可能性があります。

アプリケーション層では、構成可能性を可能にするために、明確な抽象化バリアが重要です。相互に組み合わされるプロトコルが増えるにつれ、適応、構築、拡張、リミックスする能力がますます重要になります。構成が大きくなると、可能性も高まりますが、複雑さも増します。アプリケーションが合成を行う場合、使用する合成プロトコルの詳細を理解する必要があります。

明確な抽象化バリアを作成することで、トークン設計者は、特定の変更がトークン設計の各部分にどのような影響を与えるかをより簡単に予測できます。また、抽象化の障壁が明確であるため、トークンやプロトコルの拡張が容易になり、より包括的でスケーラブルな Builder コミュニティを作成することができます。

副題

#6 外部パラメータへの依存を減らす

外部パラメータはシステムに固有のものではありませんが、コンピューティング リソースのコスト、トランザクション量、トークン モデル作成の初期段階での待ち時間など、全体的なパフォーマンスと成功に影響を与える可能性があります。ただし、トークン モデルはパラメーターが限られた範囲内に保たれている場合にのみ機能しますが、予期しない動作を示す可能性があります

あるいは、別の例を挙げると、分散型ネットワークは、解決が困難ではあるが、不可能ではない暗号アルゴリズムや計算パズルに依存することがよくあります。多くの場合、難易度は、コンピューターがハッシュ関数やゼロ知識証明を計算できる速度などの外部変数に依存します。特定のハッシュ関数を計算できる速度を仮定し、それに応じてトークン報酬を支払うプロトコルを考えてみましょう。誰かがハッシュ関数をより速く計算するための新しい方法を発明したり、システムでの実際の作業に比例しない問題を解決するために単に膨大なリソースを持っていたりすると、予想外に大きなトークンが得られる可能性があります。

副題

#7 前提を再検証する

トークンの設計は、敵対的なシステムの設計と似ている必要があります。トークンの仕組みが変わると、ユーザーの行動も変わります。よくある間違いは、ユーザーの任意のアクションが許容可能な結果を​​生み出すことを保証せずにトークン モデルを調整することです。トークン モデルの変更によってユーザーの行動が変わらないとは考えないでください。

通常、この種の間違いは設計プロセスの後半で発生します。そこでは、誰かがトークンの目標を定義し、その機能を定義し、意図したとおりに動作することを確認するための検証に多くの時間を費やします。その後、特殊なケースを特定し、それに対応するためにトークンの設計を変更しましたが、トークン モデル全体を再検証するのを忘れていました。 1 つの特殊なケースを修正することで、別の (またはその他の) 意図しない結果が生じました。