962 測定値

トークンエンジニアリング—持続可能な分散型経済を構築するための青写真

に Idrees11m2024/01/09

長すぎる; 読むには

分散型暗号経済システムの複雑さをナビゲートする包括的なガイドを利用して、トークンエンジニアリングの世界に飛び込みましょう。この記事では、システム要件分析、システム分析、システム設計という重要な段階に分けて、実践的な洞察、ツール、専門家の視点を提供します。持続可能なデジタル経済の構築におけるトークンエンジニアリングの重要性を理解します。

featured image - トークンエンジニアリング—持続可能な分散型経済を構築するための青写真

この包括的なガイドは、システム設計と複雑なシステムエンジニアリングに基づいた、トークンエンジニアリングの複雑かつ学際的な分野をナビゲートするための重要なリソースとして機能します。この記事では、分散型暗号経済システム開発の重要なフェーズであるシステム要件分析、システム分析、システム設計について概説します。このガイドでは、これらのフェーズを、システムエンジニアリングとトークンベースのエコシステム構築の両方で確立されたフレームワークと整合させています。さらに、各フェーズのタスク、スキル、成果物の詳細な内訳も提供します。読者は、なぜトークンエンジニアリングが持続可能なデジタル経済にとって不可欠であるのかを深く理解するだけでなく、このダイナミックな分野を形成するプロセス、ツール、専門家についての実践的な洞察も得ることができます。

コンテンツの概要

導入
トークンエンジニアリングとは何ですか?
トークンエンジニアリングプロセス
システム要件の分析
システム分析
システムデザイン
まとめ
注目すべき企業
オンラインコミュニティ
ツール
GitHub
コース
追加リソース

導入

2022 年、私はメカトロニクスとロボットエンジニアリングの背景をもとに、トークンエンジニアリングへの道を歩み始めました。過去 2 年間、私は他の人がこの新興領域をナビゲートする際に役立つと思われるリソースを集めてきました。この研究は、この分野の数人の重要人物によって大きな影響を受けています。暗号経済システムを理解するための概念的枠組みは、トークンエンジニアリングをシステム設計と複雑システムエンジニアリングの両方の分野として定義するMichael Zarghamの画期的な貢献に大きく基づいています。 Angela Kreitenweis は、 TE アカデミープラットフォームと彼女の取り組みを通じて、トークンエンジニアリングの分野の進歩において重要な役割を果たしてきました。これには、研究セッション、EthCC Barcamp などのイベント、研究グループ、コース、助成金の組織化が含まれます。また、専門家と専門家の世界的なコミュニティを結成することも含まれます。この分野の愛好家。 Krzysztof Paruch 氏、 Trent McConaghy 氏、およびAchim Struve 博士も、Web3 エコシステム内のイノベーションと開発におけるトークンエンジニアリングの中心性を強調することで、貴重な研究がこの新興領域の定義と確立において極めて重要な役割を果たした主要人物です。この分野の複雑で学際的な性質、およびトピックの複雑で多様な性質を認識して、読者が特定の概念をより深く理解できるように、記事全体にさまざまなリソースのリンクを含めました。

トークンエンジニアリングとは何ですか?

意味

トークンエンジニアリングは、トークンベースの複雑な経済システムの設計、検証、最適化です。

トークンエンジニアリングが重要な理由

トークンエンジニアリングは、デジタル資産を作成するだけではありません。これは、分散システムを設計するための包括的なアプローチを必要とする厳格な規律です。従来のシステムが綿密な計画、分析、設計を必要とするのと同様に、トークンエコシステムもその構想と実現に厳格なプロセスを必要とします。要件を収集する場合でも、スマートコントラクトを展開する場合でも、各フェーズは、分散型システムが技術的に健全であるだけでなく、経済的に実行可能で社会的に影響力があることを保証する上で重要な役割を果たします。各フェーズの微妙な違いを掘り下げていくと、トークンエンジニアリングが単なる技術的な取り組みではなく、持続可能なデジタル経済を構築するための包括的なアプローチであることがわかります。

ブロックチェーン対応の分散型経済システムという現代の状況において、分散型エコシステム開発の重要な部分としてトークンエンジニアリングの分野を掘り下げ、それをシステム設計のフレームワークを通して見て、特殊なサブセットとして位置づけます。複雑なシステムエンジニアリングの分野。

トークンエンジニアリングプロセス

この記事では、製品開発ライフサイクルの 3 つの標準フェーズの枠組み内でトークンエンジニアリングプロセスの範囲を説明します。このトークンエンジニアリングプロセスは、システムエンジニアリングで確立されたフレームワークと密接に連携しており、また、検出、設計、展開フェーズを含む Outlier Ventures のトークンベースのエコシステム作成の構造化フレームワークとも緊密に連携しています。この分野の包括的な理解を提供するために、各フェーズに必要なスキル、期待される成果物、および必須ツールの概要を説明します。

システム要件の分析
システム分析
システムデザイン

システム要件の分析

システム要件分析は、システム要件を文書化する最初のフェーズです。ここでは、システムが達成すべきことを定義します。関係者は通常、先に進む前にこれらの要件に同意します。これは、その後の分析、設計、開発フェーズの準備を整え、すべての関係者にとっての参照点として機能します。

システム要件分析フェーズは、さらに次のサブステップ/フェーズに分割されます。

システム要件の収集
要件分析

システム要件の収集

このステップでは、高レベルのニーズと制約が関係者から収集されます (文書化/口頭)。関係者がシステムで何を達成することを期待しているかを理解することに重点が置かれています。これには、機能、パフォーマンス、セキュリティ、コンプライアンスなどの機能要件と非機能要件の両方が含まれる場合があります。

プロセス

主に、システムに必要な機能を特定し、詳細に説明することに重点を置きます。このフェーズには多くの場合、関係者へのインタビュー、ユースケースの定義、機能要件と非機能要件の両方の文書化が含まれます。「システムは何をすべきですか?」などの質問に答えます。「制約は何ですか?」

関係者へのインタビューを実施して、ニーズと期待を収集します。
ユーザーストーリーやユースケースを文書化します。
機能要件と非機能要件 (セキュリティ、スケーラビリティなど) を特定します。

コンポーネント

機能要件（システムに必要な機能）
非機能要件（パフォーマンス、セキュリティ、マネーロンダリング防止法（AML）などの法的規制の遵守など）
性能要件
システムの技術要件
仕様
ユースケースまたはユーザーストーリー (システムがどのように使用されるかを説明するシナリオ)

要件分析

システム要件の最初の収集後、要件分析の 2 番目のサブステップ/フェーズでは、システムの機能要件と非機能要件を文書化しながら、これらの要件を分析、検証、優先順位付けすることで、プロジェクトの要件を調査し、洗練することに特に焦点を当てます。目的は、要件が具体的、測定可能、達成可能、関連性があり、期限がある (SMART) ことを保証することです。これには、明確化、優先順位付け、および検証の活動が含まれます。

洗練された要件は、システム分析とシステム設計の基礎となります。このステップにより、要件が明確で完全であり、プロジェクトの目標と一致していることが保証されます。これにより、すべての関係者がシステムが達成すべきことについて相互に理解できるようになります。

要件分析は、「どのような種類のステーキング報酬がネットワークへの参加を促すのか?」と答えるかもしれません。

コンポーネント

システム要件分析は多くの場合、利害関係者から初期要件を収集することから始まりますが、要件分析の部分では、明確さ、完全性、実現可能性、関連性について、以下の方法で要件を精査するためにさらに深く掘り下げていきます。

検証:収集された要件がプロジェクトの目標および関係者のニーズと一致していることを確認します。
優先順位付け: どの要件が必須であるか、あればあると便利であるかを決定します。
明確化:高レベルの要件をより詳細な仕様に分解します。
競合の解決:さまざまな関係者からの競合する要件を特定して解決します。

要件分析プロセスの出力は、多くの場合、要件仕様書が更新され、より詳細になったバージョンになります。この文書には、優先順位が付けられ、明確化され、検証された要件が含まれています。

スキル・テクニック

要件エンジニアリング
ユースケースのモデリング、ユーザーストーリーのマッピング、機能の優先順位付け
メカニズム設計とゲーム理論
コミュニケーションとステークホルダーの管理
ブロックチェーンと Web3 の概念についての基本的な理解

トークンエコシステムまたはブロックチェーンプロジェクトのコンテキストでは、フェーズにはメカニズム設計とゲーム理論が含まれる可能性があります。これらの方法は、分散型システムにとって重要なインセンティブ構造、ガバナンスモデル、その他の機能の設計に役立ちます。ここでの焦点は、システムが期待どおりに機能するためにどのようなメカニズムを導入する必要があるかということです。

成果物/成果物

要件仕様書:システムが実行すべき内容の概要を説明した詳細な文書。多くの場合、モックアップやワイヤーフレームが含まれます。

これには、最初の要件収集とより詳細な要件分析の両方が含まれます。システムが期待する動作の概要を示します。要件仕様書は「何を」、つまりシステムが何を達成すべきかに焦点を当てており、その方法については詳しく述べていません。

例

ユーザーが仮想世界でデジタル資産を所有、取引、対話できるようにするメタバースプロトコルを構築していると仮定しましょう。

要件には次のものが含まれる場合があります。

ユーザー所有のデジタル資産 (NFT)。
資産を取引するためのマーケットプレイス。
ソーシャルインタラクションのための仮想空間。
コミュニティの意思決定のためのガバナンスメカニズム。
他のメタバースプロトコルとの相互運用性。
低遅延と高性能。

システム要件分析では、メタバースプロトコルが満たさなければならないこれらの機能と基準を文書化し、これらの要件を正式に精査して改良します。この段階は基礎を設定し、システムが達成すべきことのガイドラインとして機能します。

システム分析

システムが何を行うべきかを理解したら、それをどのように実行できるか、どのような課題が発生する可能性があるかを分析します。このステップには、実現可能性調査、リスク管理、ストレステスト、経済モデリングが含まれ、場合によっては主要な仮定を検証するための初期プロトタイプが含まれます。この段階での発見により、元の要件が改良されたり、変更されたりする可能性があります。システム分析には、既存の同様のシステムを評価し、ユーザー要件、システムの制限、潜在的なボトルネックなどのさまざまな側面を理解することも含まれます。多くの場合、技術と経済の観点からプロジェクトの実現可能性を分析することが含まれます。これには、既存のエコシステムとの統合の影響や、新しいシステムを作成する可能性を検討することが含まれます。

このフェーズは、特にトークンエコシステムのような複雑なシステムでは、数学的仕様、差分仕様、状態空間表現、エージェントベースのモデリング、およびシステムダイナミクスモデリングを含み、要件分析フェーズで設計されたメカニズムの実現可能性と堅牢性を検証し、要件に関する仮定を検証します。システムの動作、ユーザーのインセンティブ、経済的な実行可能性。これらの方法は、さまざまな条件下でシステムがどのように動作するかを予測することを目的としています。

システム分析なら、「ステーキングのメカニズムは市場の極端な変動に耐えられるだろうか？そのような状況でエージェントはどのように行動するだろうか？」と答えるかもしれません。

システム分析は、これらの機能の実装に関連する要件と技術的課題を最適に実装する方法を理解することを目的としています。このフェーズには、システムが定義された要件をどのように満たせるかを理解するためのシミュレーション、モデリング、その他の形式の検証が含まれます。「これは技術的に実現可能ですか?」などの質問に答えます。「潜在的なリスクは何ですか?」

タスク

実現可能性の調査: 技術的、経済的、および運用上の実行可能性。
仮定を検証したり、システムの動作を理解したりするための予備的なモデリング。
リスク評価: 潜在的なボトルネック、制限、またはセキュリティリスクを特定します。
モデリングとシミュレーション: 動作モデリングとユーザーインセンティブの設計のため、仮定を検証し、システムの動作を理解します。

スキル・テクニック

数学的モデリング (数学的仕様、微分仕様)
状態空間表現
統計モデリング
システムダイナミクスとエージェントベースのシミュレーション

成果物/成果物

実現可能性レポート: プロジェクトの実行可能性とリスクを文書化します。
更新された要件: 分析に基づいた初期要件の変更または改良
メカニズムとシステムの数学的および微分的仕様
数学的 (状態空間表現) と統計モデル
シミュレーション (エージェントベースおよびシステムダイナミクス)

例

この段階では、要件の実現可能性と影響を評価します。メタバースの例では、これには次のものが含まれます。

実現可能性: 現在のブロックチェーンテクノロジーは、必要なパフォーマンスレベルをサポートできますか?
経済モデル: 市場は経済的にどのように機能しますか?トレーディングに関してゲーム理論的な考慮事項はありますか?
ユーザーの行動: ユーザーはアセットやユーザー同士をどのようにやり取りする可能性がありますか?
ストレステスト: エージェントは極限状態でどのように動作するでしょうか?
境界条件: 起こり得る最悪の事態とそれを回避する方法は何ですか?
セキュリティ: 攻撃者が悪用できる潜在的な脆弱性は何ですか?

システムデザイン

要件を理解し、分析を完了したら、システムのアーキテクチャとコンポーネントの設計に進みます。この段階では、テクノロジースタックの決定、データモデル、ワークフローなど、実際のシステムを構築するための青写真が作成されます。

分散システムまたはトークンエコシステムのコンテキストでは、システム設計は、システムがどのように構築され、そのコンポーネントがどのように相互作用するかを決定するアーキテクチャの青写真として機能します。このフェーズは、システム要件分析とシステム分析によってシステムが実行すべきことを確立し、それが実現可能であることを検証した後に行われます。

タスク

アーキテクチャ設計: システムの高レベルの構造をレイアウトします。
コンポーネント設計: スマートコントラクトや API、統合などの各コンポーネントの詳細な設計。
データモデリング: データをどのように保存、アクセス、管理するかを決定します。
トークンモデル、戦略、KPI、

必要なスキル

ソフトウェアアーキテクチャ
スマートコントラクトの開発
システムエンジニアリング
検証と最適化
ユーザーエクスペリエンス (UX) デザイン

成果物/成果物

システム設計ドキュメント: システムアーキテクチャ、コンポーネント、データモデル、対話フローの包括的な青写真。

システム仕様書は、システムを構築するための青写真を提供する「方法」に焦点を当てています。

このドキュメントはより技術的なものであり、通常はシステム設計フェーズの成果物です。これは、システムが要件仕様書に規定されている要件をどのように満たすかを概説します。システム仕様書には次のものが含まれる場合があります。

例

要件の設定と分析が完了したら、その要件を満たすアーキテクチャを構築するシステム設計に進みます。メタバースプロトコルの場合、これには以下が含まれる可能性があります。

ブロックチェーン層: スケーラビリティのニーズに基づいて、層 1 ソリューションと層 2 ソリューションのどちらかを選択します。
スマートコントラクト: 資産の所有権、取引、ガバナンスを処理する契約を設計します。
トークンノミクス: 参加とガバナンスの促進におけるトークンの役割を定義します。

要件分析でトークンエコシステムにガバナンストークンが必要であると判断され、システム分析でそのようなメカニズムが実現可能であることが確認された場合、システム設計フェーズでは次のように指定します。

ガバナンストークンを作成および配布するためのスマートコントラクトコード。
ガバナンス構造、定足数、定足数しきい値、議決権など

まとめ

製品開発のこれらのステップは連続的ですが、厳密には直線的ではありません。これらは多くの場合反復的であり、相互にループバックする可能性があります。

例えば：

フィードバックループ: システム分析中に、一部の要件が実現不可能であるか、最適化できる可能性があることが判明し、システム要件の改訂につながる可能性があります。
反復的な改善: 設計が進むにつれて、新しい洞察が得られ、分析または要件の段階を再検討することが必要になる場合があります。
アジャイル開発: アジャイルフレームワークでは、これらのステップが 1 つの大きなシーケンスではなく、小さな反復サイクルで発生するため、継続的な改良が可能になります。

これらのフェーズは反復的であり、改良のためにループバックされることがよくあります。たとえば、システム設計中に、要件を更新したり、特定の側面を再分析したりする必要があることに気づき、以前のフェーズに戻るきっかけとなる場合があります。各フェーズには独自の専門スキルが備わっていますが、それらはすべてプロジェクトの最終目標である機能的で効果的な Web3 システムの構築に貢献します。