a16z：トークン設計の欠陥を避けるための7つの提案

原文タイトル：7 トークン設計前のサニティチェック

著者：Guy Wuollet

編訳：Katie 辜，Odaily 星球日报

トークンは多様な方法で定義できる強力な新しい原語です。トークン設計のスペースは非常に豊富ですが、私たちはまだ探索の初期段階にいます。

実際、多くのチームがプロジェクトにとって「正しい」トークン設計を見つけるために努力しています。しかし、業界はテストされた設計フレームワークが欠如しているため、後の人々は前の人々と同じ課題に繰り返し直面しています。幸いなことに、（少数ですが）初期の成功したトークン設計の例も存在します。ほとんどの有効なトークンモデルには、その目的に対する独自の要素がありますが、ほとんどの欠陥のあるトークン設計にはいくつかの共通のバグがあります。したがって、この記事では、なぜ私たちが「トークン経済」だけでなく、トークンの研究と設計を考慮すべきかを議論し、7つの「避けるべき落とし穴」の小技を列挙します。

#1 トークン設計の目標を明確にする

トークン設計における最大の問題は、目標を明確にする前に複雑なトークンモデルを構築することです。最初のステップは目標を特定し、チーム全体が完全に理解できるようにすることです：それは何で、なぜ重要なのか、あなたが本当に達成したいことは何ですか？目標を厳密に定義できないと、再設計や時間の無駄につながることがよくあります。目標を明確にすることは、「トークン経済を設計するために作り出されたトークン経済」という問題を避けるのにも役立ちます。これは、特定のトークン経済設計の一般的な現象です。

さらに、目標はトークン自体を中心に設定されるべきですが、これはしばしば見落とされます。目標を明確にする例には以下が含まれます：

• 最適なスケーラビリティを実現し、モデリングをサポートするトークンモデルのゲームを設計する。

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

• 担保金の信用プロトコルを設計するが、信用を直接代替することはできない（例えば、流動性と信用信号を分離することによって）。

• 低遅延でファイルが利用可能であることを保証できるストレージネットワークを設計する。

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

• 真のユーザーの好みや最大の参加度を引き出すガバナンスメカニズムを設計する。

このような例は数え切れません。トークンがあらゆるユースケースをサポートし、あらゆる目標を達成できるようにするのではなく、逆の方向に進むべきです。

では、どのようにして明確な目標を定義し始めるのでしょうか？明確に定義された目標は通常「プロジェクトの使命」から来ます。プロジェクトの使命はしばしば高次で抽象的ですが、目標は具体的で、最も基本的な形に簡素化されるべきです。

EIP-1559を例に挙げてみましょう。RoughgardenはEIP-1559の明確な目標を次のように述べています：「EIP-1559は、需要が急増する時期を超えて、'明らかに最適な入札'の形で、簡単な手数料の見積もりを通じてユーザー体験を改善するべきです。」

彼はさらに別の明確な目標を提案しました：「私たちは、イーサリアムの取引手数料メカニズムを再設計し、取引のGas価格を設定することを、アマゾンで買い物をするように'スムーズ'にできるでしょうか？理想的には、価格発表メカニズムが必要で、これは各ユーザーにGas価格を受け入れるか放棄するかのメカニズムを提供することを意味します。」

これら二つの例の共通点は、高次の目標を述べ、他の人があなたの目標を理解するのを助けるための関連する類似点を提供し、その後、この目標を最も支援する設計案を描くことです。

#2 基本原則に基づいて既存の作業を評価する

新しいものを創造する際には、既存のものから研究を始めるのが良いアイデアです。既存のプロトコルや文献を評価する際には、その技術的な優位性に基づいて客観的に評価する必要があります。

トークンモデルは通常、トークンの価格や関連プロジェクトの人気に基づいて評価されます。これらの要因は、トークンモデルがその定められた目標を達成する能力とは無関係である可能性があります。評価、人気、またはトークンモデルを評価するための他の単純な方法は、ビルダーが「遠回り」する原因となる可能性があります。他のトークンモデルが正常に機能していると仮定すると、実際にはそれらが正常に機能していない場合、「生まれつき欠陥のある」トークンモデルが作成される可能性があります。

#3 あなたの仮定を明確にする

あなたの仮定を明確に表現してください。トークンを構築することに集中していると、基本的な仮定を当然のこととして扱うのが容易です。また、あなたが実際に行った仮定を誤って表現することも簡単です。

新しいプロトコルの例を挙げると、そのプロトコルはハードウェアのボトルネックが計算速度であると仮定しています。この仮定をトークンモデルの一部として（例えば、プロトコルに参加するために必要なハードウェアコストを制限することによって）組み込むことで、設計を期待される行動と一致させるのに役立ちます。

しかし、プロトコルとトークン設計者が彼らの仮定を明確に表現しない場合、または彼らが表現した仮定が間違っている場合、参加者がその不一致に気づく可能性があります。ハッカーは通常、最初にシステムを構築した人々よりもシステムをよりよく理解しています。

あなたの仮定を明確にすることで、他の人があなたのトークン設計を理解しやすくし、正常に機能することを保証できます。仮定を明確にしなければ、あなたの仮定を検証することもできません。

#4 あなたの仮定を検証する

「あなたが知らないことがあなたを困らせるのではなく、あなたが確信していることがそうである」という言葉があります。

トークンモデルは通常、一連の仮定を行います。このアプローチは部分的にビザンチンシステム設計に由来し、これはブロックチェーンのインスピレーションの源です。システムは仮定を行い、その仮定が真である場合に特定の出力を保証する関数を構築します。例えば、ビットコインは同期ネットワークモデルにおける活性を保証し、ネットワーク内の51％のハッシュパワーが誠実であれば、一貫性を保証します。いくつかの小さなブロックチェーンは51％攻撃を受け、中本聡がブロックチェーンの正常な動作に必要とする誠実な仮定の数を破りました。

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

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

「抽象障壁」（abstraction barrier）は、システムやプロトコルの異なるレイヤー間のインターフェースです。これはシステムの異なるコンポーネントを分離し、各コンポーネントを独立して設計、実装、変更できるようにします。明確な抽象障壁は、すべてのエンジニアリング分野、特にソフトウェア設計の分野で有用ですが、分散型開発や大規模チームが個々に理解できない複雑なシステムを構築する際には特に必要です。

トークン設計において、抽象障壁を取り除く目標は複雑性を最小限に抑えることです。トークンモデルの異なるコンポーネント間の（内部）依存関係を減らすことで、より簡潔なコード、バグの減少、より良いトークン設計を生み出すことができます。

例えば、多くのブロックチェーンは大規模なエンジニアリングチームによって構築されています。あるチームは、一定期間内のハードウェアコストに関する仮定を行い、それを使用してどれだけのマイナーが特定のトークン価格でブロックチェーンにハードウェアを提供するかを決定します。別のチームがトークン価格をパラメータとして依存しているが、最初のチームのハードウェアコストに関する仮定を知らない場合、彼らは互いに矛盾する仮定を容易に行うことができます。

アプリケーション層では、明確な抽象障壁が可組み性を実現するために重要です。ますます多くのプロトコルが相互に組み合わさるにつれて、適応、構築、拡張、再混合の能力はますます重要になります。より大きな構成はより大きな可能性をもたらしますが、同時により大きな複雑性ももたらします。アプリケーションが組み合わさりたい場合、それらは使用する組み合わせプロトコルの詳細を理解する必要があります。

不透明な仮定やインターフェースは、特に初期のDeFiプロトコルにおいて、あいまいなバグを引き起こすことがあります。あいまいな抽象障壁は、プロトコルの異なるコンポーネントを扱うチーム間で必要なコミュニケーションの効率を増加させ、開発時間を延長します。あいまいな抽象障壁は、プロトコルの複雑性を増加させ、そのメカニズムを完全に理解することを困難にします。

明確な抽象障壁を作成することで、トークン設計者は特定の変更がトークン設計の各部分にどのように影響するかを予測しやすくなります。明確な抽象障壁は、トークンやプロトコルの拡張を容易にし、より包括的で拡張可能なビルダーコミュニティを作成します。

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

外部パラメータはシステムに固有のものではありませんが、全体の性能や成功に影響を与えます。例えば、トークンモデルの作成初期における計算リソースのコスト、取引量、または遅延などです。

しかし、トークンモデルがパラメータが限られた範囲内にあるときにのみ機能する場合、予期しない動作が発生する可能性があります。例えば、サービスを販売し、固定トークン報酬の形でリベートを提供するプロトコルがあるとします。もしトークンの価格が予想外に高い場合、トークン報酬の価値はサービスのコストを上回る可能性があります。この場合、プロトコルから無限にサービスを購入することは非常にお得であり、トークン報酬とサービスを最大限に活用します。

また、別の例として、分散型ネットワークは通常、解決が難しい暗号アルゴリズムや計算問題に依存していますが、これらは不可能ではありません。難易度は通常、外生変数に依存します。例えば、コンピュータがハッシュ関数やゼロ知識証明を計算する速度です。あるプロトコルが、特定のハッシュ関数を計算する速度に基づいてトークン報酬を支払うと仮定している場合、もし誰かがそのハッシュ関数をより速く計算する新しい方法を発明したり、システム内での実際の作業に対して不釣り合いな超大規模なリソースを持っていたりすると、彼らは予期しない巨額のトークン報酬を得ることができます。

#7 仮定を再検証する

トークンを設計することは、対抗システムを設計することと同じであるべきです。ユーザーの行動は、トークンの動作方法が変わるにつれて変わります。

一般的な誤りは、任意のユーザー行動が依然として受け入れ可能な結果を生むことを確認せずにトークンモデルを調整することです。ユーザーの行動がトークンモデルの変化によって変わらないと考えないでください。このような誤りは、設計プロセスの後半で発生することが多く、誰かがトークンの目標を定義し、その機能を定義し、期待通りに動作することを確認するために多くの時間を費やします。その後、彼らは特例を特定し、それに合わせてトークン設計を変更しますが、全体のトークンモデルを再検証することを忘れます。特例を修正することで、彼らは別の（または他のいくつかの）予期しない結果を生み出すことになります。

苦労した作業を無駄にしないように、プロジェクトがトークンモデルを変更するたびに、それが期待通りに機能するかどうかを再検証してください。