今回は、「Audius」について解説します。
この記事では、プログラミングなどかなり専門的知識の部分をピックアップ支えていただきました。
そのため普通にAudiusをプレイするだけであればここまでの知識は不必要になります。
概要に関してはこちらをごらください。→【 Audius（AUDIO）とは 】創設者・特徴・供給量・上場している仮想通貨取引所・投資における将来性まで解説
Audiusとは
Audiusとは、ファンとアーティストや独占的な新しい音楽を繋ぐ、デジタルストリーミングサービスです。
これは、完全に分散化されることで実現されます。
Audiusは、世界中のアーティスト・ファン・開発者の活気に満ちたオープンソースコミュニティによって所有・運営されています。
Audiusは、アーティストに、これまでに聞いたことのない音楽を共有し、ストリームを直接収益化する力を与え得ます。
開発者は、Audius上に独自のアプリを構築して、存在する中で最も特徴的なオーディオカタログの1つにアクセスできるようにすることができます。
内部的には、Audiusはブロックチェーンとコミュニティ実行ノードの上に構築されたプロトコルとプラットフォームの両方です。
Audiusは、オープンソース・オープンデータとアクセス・オープンオーナーシップです。
Audiusの公式ホームページはこちらです。
アプリの無料登録はこちらです。
背景
音楽の作成・配信は、過去20年間でテクノロジーによって劇的に変化終いsta。
音楽を作成するために、プロデューサー・オーディオエンジニアのチームは必要ありません。
寝室にいる人は誰でも安価なソフトウェアから始めることができます。
同様に、音楽を配信するために、物理的なレコードを作成する工場やレコードを店舗に持ち込むための小売関係は必要ありません。
音楽プラットフォームにより、アーティストは自分の音楽を配信できる様になりました。
デジタル配信の時代には冗長ですが、録音された音楽の初期に経営された中あきしゃとそのネットワークは依然として存続しており、価値の移転と獲得のメカニズムが依然としてほとんど難読化されている間、アーティストとキュレーターの後ろで繁栄しています。
Audiusは、既存のデジタルストリーミングプラットフォームに代わる最も直接的な消費者向けの手段です。
アーティストとファンがお互いに直接アクセスし、作成を支援しているネットワークの所有権と公平性を提供します。
詳細
Audiusは、分散型でコミュニティが所有し、アーティストが制御する音gく共有プロトコルです。
Audiusは、既存のストリーミングプラットフォームに代わるブロックチェーンベースの代替手段を提供し、アーティストが作品を公開して収益化し、ファンに直接配信できる様にします。
このプロジェクトの使命は、あらゆるオーディオを共有・共有化・聞く自由を全ての人に与えることです。
Audius Protocolリポジトリは、スマートコントラクト・サービス・その他のサポートライブラリなど、プロトコルを作成及びサポートする全ての要素を備えた単一リポジトリです。
サービスの運用に関心がある場合は、セクションを参照してください。
Audiusは、アーティスト（コンテンツ作成者）・ファン（コンテンツ消費者）・サービスプロバイダーの3つのユーザー層で構成されています。
一部のユーザーは、3つの人口統計全てに該当することを確認します。
| アーティスト | ・トラックをアップロード ・アルバムを作成 ・コンテンツをフォロワーに共有 |
| ファン | ・トラックをストリーミング ・プレイリストを作成 ・アーティストをフォロー ・購読 ・コンテンツをフォローしている人と再共有 |
| サービスプロバイダー | ・アプリトラフィックを提供 ・曲をストリーミング ・ネットワークの保護を支援 |
サービスプロバイダーは、$AUDIOトークンをステーキングしてサービスを登録することにより、次の1つ以上のサービスを提供できます。
・検出ノード：SSLをサポートするエンドポイントをホストし、エンドポイントをステークに登録
・コンテンツノード：SSLをサポートするエンドポイントをホストし、エンドポイントをステークに登録
上の図では、作成者はコンテンツのーどを自分で実行するか、ネットワークに登録されたコンテンツのーどの1つを使用できます。
【Audius サービス】
| サービス | 説明 | GitHub |
| コンテンツノード | ユーザーメタデータ・画像・オーディオコンテンツなど、IPFSでのユーザーコンテンツの可能性を維持する | https://github.com/AudiusProject/audius-protocol/tree/master/creator-node |
| ディスカバリーノード | クライアントがAPIを介してクエリできるように、Audiusコントラクトのコンテンツをイーサリアムブロックチェーンにインデックスをつけて保存する | https://github.com/AudiusProject/audius-protocol/tree/master/discovery-provider |
| アイデンティティサービス | 暗号化された認証暗号文を保存し、Twitter OAuthを実行し、ユーザーに代わってトランザクションを中継する（ガス代を支払う） | https://github.com/AudiusProject/audius-protocol/tree/master/identity-service |
【Audius スマートコントラクト&Libs】
| Lib | 説明 |
| libs | 分散Web及びAudiusサービスへの簡単なインターフェース：Identity・Service・Discovery Node（Discovery provider）・Content Node（Creator node） |
| contracts | Audiusストリーミングプロトコル用に開発されているスマートコントラクト |
| eth-contracts | Audiusストリーミングプロトコル用に開発されているイーサリアムスマートコントラクト |
ディスカバリーノード
Audius Discovery Nodeは、Audiusユーザーがクエリを実行できるように、プロトコル全体でメタデータとデータの可用性にインデックスをつけるサービスです。
インデックスに登録され他コンテンツには、ユーザー・トラック・アルバム・プレイリストの情報とソーシャル機能が含まれます。
データは素早くアクセスできるように保存され、定期的に更新され、PESTful APIを介してクライアントが利用できる様になります。
【設計目標】
①リスナー・クリエイターが対話できるクエリ可能なエンドポイントを公開する
②関連するブロックチェーンイベントを確実に保存する
③ブロックチェーンを継続的に関しし、保存されているデータがネットワークで最新であることを確認する
アーキテクチャー
検出のーどはPostgre SQLを使用します。
Postgresデータベースは、オブ稀有とリレーショナルマッパーであるAQAlchemyと、軽量のデータベース移行ツールであるAlembicを介して管理されます。
データモデルはsrc/models.pyで定義されています。
alembic/versionsの下で移行を自動的に生成するためにalembicによって使用されます。
alembicとデータモデルの間で定義された接続は、こちらにあります。
検出のーどのWebサーバーは、Audiusプロトコルを介してデータを読み取るためのエントリポイントとして機能します。
全てのクエリは、SQLAlchemyクエリの結果から解析されたJSONオブ稀有音として返され、こちらにあります。
クエリの例としては、ユーザー固有のフィード・トラフィックデータ・プレイリストデータなどがあります。
Celeryは単なるタスクキューです。
これにより、検出のーどの村座奥機関を通じて繰り返される一連の単一タスクを定義できます。
現在、単一のタスクである(src/tasks/index.py:update_task()が全てのデータベース書き込み操作を処理しています。フラスコアアプリケーションはデータから読み取り、データの正確性を認識していません。
セロリワーカーとビートは、検出ノードでのセロリの使用の背後にある重要な基本概念です。
Celery beatは、インデックスタスクを定期的にスケジュールする役割を果たし、ワーカーとは別のコンテナーとして実行されます。
定期的なタスクスケジューリングの詳細については、公式ドキュメントを参照してください。
セロリワーカーは、実際にタスクを実行するコンポーネントです。
【Celery】
Audiusでのデータ可用性の主な推進要因は、「index/blocks」セロリタスクです。
‘index/blocks’が実際に実行されるとどうなりますか？
Celeryタスクは次の操作を実行します。
①最新のブロックが「ブロック」テーブルで最後に処理されたブロックと異なるかどうかを確認します。その場合、ブロックの配列は、データベースに存在する最後のブロックハッシュから、ブロックインデックスウィンドウで指定された最新のブロック番号まで生成されます。
→ブロックインデックスウィンドウは、1回のインデックス操作で処理されるブロックの最大数に相当します。
②上記の手順の後に作成したブロック配列の各ぶろっくをトラバースします。
各ブロックで、Audiusスマートコントラクトに関連するトランzカウションが存在するかどうかを確認します。
存在する場合は、関連するトランザクションハッシュから特定のイベント情報を取得します。
例には、クリエイターとトラックのメタデータが含まれます。
そのためには、ディスカバリノードはコントラクトABIと各コントラクトのアドレスの両方を認識している必要があります。
これらは各ディスカバリのーどイメージに付属しています。
③特定のブロック内のAudiusコントラクトからの特定の操作により、タスクはデータベース内の対応するテーブルを更新します。
特定のインデックス操作では、分散ストレージ（Audius Storage Protocol）からのメタデータフェッチが必要です。
メタデータ形式はここにあります。
イベントフィルターを使用する代わりにブロックにインデックスをつけるのはなぜですか？
ブロックにインデックスを作成タスクは新しいデータベースセッションを開きます。
つまり、DBトランザクションをブロックレベルで元に戻すことができます。
検出ノードのロールバック処理はまだ実装されていませんが、ブロックレベルのインデックス作成は必要になったときに役立ちます。
【Celery Beat】
セロリワーカーと同じコンテナーですが、インデックスが定期的に実行される用に、「ビートスケジューラ」として実行されます。
デフォルトでは、この間隔は5秒です。
【Redis】
ディスカバリーノードのいくつかの目的でRedisを使用します。
①キャッシング（内部及び外部）
②セロリのブローカーとして
③Celeryジョブの単一コンテキストを確保するためのロックのメカニズムとして
Elatic Seachは、データを非正規化し、特定のクエリ（フィード・検索・関連アーティストなど）をサポートするために使用されます。
Elatic Seachデータは、Postgresデータベースに存在するデータベーストリガーによって入力され、最新の状態に保たれます。
Elstatic SeachレイヤーのETLコードは、こちらにあります。
【Web】
コンテンツノードのコアサービスは、着信リクエストを処理して次の機能を実行するHTT PAPIを備えたWebサーバーです。
・ユーザーとトラックのメタデータのアップロード
・ユーザーとトラック画像のアップロード
・ユーザートラックファイルのアップロード
・ユーザーとトラックのデータ・メタデータ・トラックファイルの取得
Webサーバーは下のアプリです。
【Persistent Storage（Postgres）】
全てのデータをpostgresqlデータベースに保存し、全ての画像とメタデータオブジェクトをファイルシステムに保存します。
ディスクに保存されている全てのコンテンツとメタデータへのポインタは、PostgresDBに保持されます。
Postgresは、移行・モデル・検証を含むSequelizeORMを使用してコードベースで管理されます。
Redisクライアントは、リソースのロック・リクエストレートの制限・制限されたキャッシュとキーストレージに使用されます。
Redisは、ioredisnqmパッケージを介してコードベースで管理されます。
【トラック】
Audisプロトコルで定義されているように、コンテンツのーどはFFMPEGを使用して、アップロードされたすべてトラックファイルをセグメント化及びトランスコードしてから保存・提供します。
【データの冗長性】
Audiusプロトコルで定義されている様に、全てのコンテンツは、可用性を最大化するために複数のノードに冗長的に保存されます。
これは全て自動的に行われます。
全てのノードがネットワーク内の他の全てののーどを監視して、全てのデータの冗長性を最小限に抑え、必要に応じてファイルを転送します。
トークン
＄AUDIO
Audiusプラットフォームトークン（AUDIO）には、Audiusプロトコルエコシステム内に3つの機能があります。
・安全
・機能へのアクセス
・ガバナンス
AUDIOは、ノードの運用やガバナンスへの参加などの付加価値サービスの担保として使用されます。
引き換えに、スタッカーは継続的な発行・ガバナンスの主に・排他的な機能へのアクセスを獲得します。
将来的には、AUDIOはネットワーク内の価値移転からグローバルな料金プールを管理します。
全てのアクターを調整するためにネイティブトークンを提供することで、Web3に固有の並行インセンティブが作成され、早期採用者がAudiusの利点を共有できる様になります。
SudiusコミュニティはAUDIOトークンが常に最も付加価値の高いアクターに集中していることを確認することを目指しています。
これは、単に最も多くのオーディオを賭けている参加者ではなく、悪低ィブブロックチェーンな参加者へのより良いルート配布を測定するための測定としてオンチェーンメトリックを使用して継続的に発行することによって行われます。
これが実際にどのように機能するかを示します。
【安全性】
AUDIoは、ネットワークを保護するためにのーどオペレーターによって賭けられます。
掛け金が大きいほど、ファンやアーティストがノードを使用する可能性が高くなります。
Audiusは、コミュニティによって完全にホスト及び運用されています。
世界の止められないストリーミングプトロコるのコンテンツを保護するのーどオペレーターの許可のないエコシステムを作成します。
【機能アクセス】
AUDIOは、追加のアーティストツールのロックを解除するための販促素材として機能します。
コミュニティによってインキュベートされた初期の例には、アーティストトークン・バッジ・収益乗数が含まれます。
将来的には、ファンはAUDIOを特定のアーティストやキュレーターに委任して、プラットフォームでの成長を共有する可能性があります。
【ガバナンス】
Audius内賭けられた全てのオーディオには、プロトコルの将来の反復を形成するために使用されるガバナンスの重みが割り当てられます。
※ガバナンストークンとは→仮想通貨における【 ガバナンストークンとは 】詳細まで分かりやすく解説
Audiusのあらゆる側面が統治可能であり、1票に相当する1つのトークンを賭けて開始します。
ガバナンスは、開始時にオペレーターのインセンティブに焦点を当て、受動的なファンでさえ製品の更新や機能のアプグレードについて意見を表明するという野心を持っていることを想定します。
継続的な発行を提供するという選択は、プラットフォームで継続的に最もアクティブな人々と力を合わせます。
Audiusがプロトコルの将来のユーザーにより適していると信じているメカニズムです。
ステーキング
イーサリアムで分散型プロトコルとして構築されたAudiusの全てのコンテンツ・情報・データは、Audiusチームではなく、拡大するサードパーティのーどオペレーターのネットワークによって保存及びインデックス付けされます。
このコンテンツを信頼して維持できる様にするには、のーどオペレーターは、プロトコルにサービスを提供するための担保または「ステーク」を提供する必要があります。
＄AUDIOで表される掛け金は、悪意のあるまたは不適切な動作が発生した場合に、のーどオペレーターがスラッシュまたは取得される可能性のあるトークンを危険に晒すことを保証します。
＄AUDIOトークンを担保として使用することにより、適切なハードウェア妖艶を持つ全ての人が、完全に許可のない方法でのーどオペレーターとして参加できます。
＄AUDIOがプロトコルに固定されるほど、ネットワークの安全性が高まり、外部からの攻撃に対する脆弱性が低くなります。
ネットワークにサービスを提供することに対する報酬として、のーどオペレーターは、自動オンチェーン発行または付加価値のあるアクターに配布される新しいトークンの継続的な作成を通じて＄AUDIOを獲得する立場にあります。
より多くの＄AUDIOをステーキングする人は、ネットワークを保護することと引き換えに、発行のより多くの部分を獲得することになります。
【Audiusの仕組み】
Audiusでは、コンテンツは2つの異なるタイプのノードにルーティングされます。
・コンテンツのーど：Audiusでストリーミングされたオーディオコンテンツ（トラック・ミックスなど）を保存及び中継する
・ディスカバリーノード：ユーザープロファイル・プレイリスト・フォロワーなどのデータにインデックスをつけてハッシュする
アーティストとして、AudiusへのアップロードはSoundcloudのようなプラットフォームへのアップロードと何ら変わりはありません。
しかし、舞台裏で起こっていることは、Audiusをとても特徴的なものにしています。
【アーティストがトラックをAudiusにアップロードする場合】
①そのコンテンツはコンテンツノードにアップロードされる
②データはトランスコードされ、トラックの識別に使用される参照コードを返す
③参照コードによってリンクされたデータは、ネットワーク上の他の2つのコンテンツノードに複製される
④トラックがAudiusに存在し、メタデータがトラックをアップロードしたプロファイルに添付されていることを示すオンチェーントランザクションが公開される
⑤トランザクションは、ディスカバリノードによってピックアップされ、インデックスが作成される
⑥クライアントは、トラックがディスカバリノードに表示され、アップロードが完了したことを示すと、トラックが正常に公開されたことを返す
他のプラットフォームでは、同様のプロセスが親会社によって運営されており、事実上、親会社をコンテンツの真の所有者にしています。
その会社が存在しなくなると、データベースに保存されている全てのコンテンツの存在しなくなります。
Audiusを使用すると、トラックはネットワークによって維持され、サードパーティ・分散型のーどオペレーターによって制御されます。
Audiusは、運営を継続するために1つの会社に依存していません。
＄AUDIOをステーキングすることで、プロトコルの保護と強化に役立ちます。
この設計により、Audiusは、Audiusチームだけでなく、サードパーティののーどオペレーターのグローバルネットワークの背後で動作することができます。
2つののーどタイプを使用sるうという決定により、Audiusはさまざまなメトリックに送還してスケーリングできます。
つまり、リスナーの数がAudiusカタログに比べて急増した場合、コンテンツノードが通常通り実行されている間に、検出ノードが重みを取得できます。
同様に、ネットワークは、任意の時点で需要を満たすために帯域幅が必要な場所に応じて、インセンティブを調整することを選択できます。
【Audius上でステーキング】
Audius上でステーキングするために、のーどオペレーターは、これらのリソースを使用してコンテンツノードやディスカバリーノードをセットアップできます。
全てのアクティブなノードオエpレーターのリストは、Audiusプロトコルダッシュボードの「サービス」タブにあります。
＄AUDIOの所有者は、MetaMaskに接続するか、Gnosis Safeを使用して、これらののーどオペレーターのいずれかに最低100個のトークンを委任できます。
委任の詳細は間も無くリリースされます。
ノードオペレータは、コンテンツノード・ディスカバリノード・両方の組み合わせのいずれかを実行することを選択できます。
特定のオペレーターにステーキングされた＄AUDIOの量は、ネットワーク上でサービスの1つまたは組み合わせを実行するための経済的な帯域幅と考えることができます。
全てののーどオペレーターは、ノードごとに200,000ドルの$AUDIOトークンの最小セルフボンドを投稿する必要があります。
コンテンツノードとディスカまりノードの両方が同じマシンを使用しますが、コンテンツノードはより多くのストレージを必要とするため、操作に少しコストがかかります。
このため、各のーどのステーキングパラメータは次の通りです。
【ディスカバリノード】
・最小保証金（ステーク）：200,000AUDIO
・最大ポンド（ステーク）：10,000,000AUDIO
【コンテンツノード】
・最小保証金（ステーク）：200,000AUDIO
・最大ポンド（ステーク）：10,000,000AUDIO
最小のステーキング量は、ゲームで十分なスキンを保証し、最大のステーキング量はプロトコルが集中しすぎるのを防ぎます。
コンテンツのーどの最小要件はわずかに高いため、ディスカバリーのーどよりも多くのステークを受け入れることができます。
各オペレーターには固有のプロファイルが与えられ、ユーザーは自分の住所・投票のタイムライン・維持している様々なノードを識別できます。
その他の重要なパラメータは次の通りです。
・ステーキングされた＄AUDIO：特定のアドレスにステーキングされた、委任されたトークンの組み合わせとして測定された、全てのオペレーのノードにわたってステーキングされた＄AUDIOの合計量
・DepoyerCut：ノードに$AUDIOをステーキングした場合に、デイゲー度がのーどオペレーターに支払うステーキング報酬の割合（のーどオペレータが構成できる）
・サービス：特定のオペレーターによって実行される一位のノードの数
・委任者：トークンをオペレーターに委任する一意のアドレスの総数
ノードオペレーターは、3Boxを介して情報を入力し、プロフィール画像・タイトル・Webサイトのリンクを表示して、代理人がネットワーク上の他のユーザーとより簡単に区別できる様にすることもできます。
Audiusは、悪意ののある動作が発生した場合にノードスラッシュされるのに十分な時間を提供するために、委任を解除又はステーキングを解除するための7二位tkなんおクールダウン期間を備えています。
ジェネシスステーキング期間中、Audius Foundationが運営するんーどのDeployerCutは100％に設定され、収益は全てのコミュニティのトレジャリーに送られ、$AUDIOトークン所有者によって管理されます。
これらのノードは近い将来廃止される予定です。
【＄AUDIOステーキング】
Audiusは、チェーン上及び週単位で配布される7％の自動年間発行率を特徴としています。
＄AUDIOの報酬は、のーどオペレーターにチェーン上で直接配布され、チェーン上のシステムはDelegator Cutを差し引き、残りの報酬をトークンを委任した人にルーティングします。
サービスプロバイダーは、ネットワークの発行を配布するために週に1つのトランザクションを実行することが期待されています。
この場合、トークンは個々のノードオペレーターがリアルタイムで要求できます。
近い将来、＄UDIOの発行は、報酬関数の呼び出しから計算される様になります。
今後、ネットワーク内の誰もが報酬関数を呼び出すことができ、トークンは毎週のリズムで配布され、いつでも請求できます。
＄AUDIOステーキングのレート・期間・パラメーターは、ガバナンスによって完全に制御されます。
ノードの実行
このセクションでは、Audiusノードを実行する方法について説明します。
Audiusプロトコルは、ディスカバリノードとコンテンツノードの2つのオフチェーンサービスを利用しています。
【でィスカバリーノード】
・Audiusプロトコル（メインネットイーサリアム・PoA・Solana）で使用されているインデックスブロックチェーン
・APIトラフィックの提供
・使用状況の指標を追跡
【コンテンツノード】
・オーディオと画像のコンテンツをホスト
・ノード間でコンテンツを同期して、データの一貫性と高可用性を確保する（内部でAudiusストレージプロトコルを使用）
ハードウェア
Audiusプロトコル全体で高品質のサービスを維持sるうために、サービスハードウェア要件はおンチェーンガバナンスプロトコルによって適用されます。
登録されたのーどごとの最小リソース要件は、次の通りです。
【でィスカバリーノード】
・8vCPU
・16GiBのRAM
・256GiB SSD
【コンテンツノード】
・8xCPU
・16GiBのRAM
・2000GiB（2TiB）SSD
のーど要件の選択履歴は、パブリックガバナンスフォーラムで表示できます。
セットアップ手順
このガイドでは、DockerComposeを介して単一のマシンでAudiusサービスを実行する方法について説明します。
DockerComposeファイルのリポジトリはFitHubにあります。
アナウンスとトラブルシューティングの支援については、Audiusディスコードサーバーのノードーオペレーターチャンネルに参加してください。
上記の実行の最小要件を満たすVMは下記です。
bash <(curl https://raw.githubusercontent.com/AudiusProject/audius-docker-compose/main/install.sh)
インストール中に、必要な環境変数の入力を求めるプロンプトが表示されます。
変数は次の通りです。
【クリエイター】
creatorNodeEndpoint-コンテンツノードのDNS。まだサービスを登録していない場合は、登録するURLを入力してください。delegateOwnerWallet-トークンを含まないがチェーンに登録され、サーバーからのJSON応答に署名するために使用されるウォレットのアドレスdelegatePrivateKey-に関連付けられた秘密鍵delegateOwnerWalletspOwnerWallet-チェーン上のコンテンツノードを登録した（または登録する予定の）ウォレット
外部で管理されているPostgres DBを使用している場合は、このセクションを参照してください。
【ディスカバリー】
audius_delegate_owner_wallet-トークンを含まないがチェーンに登録され、サーバーからのJSON応答に署名するために使用されるウォレットのアドレスaudius_delegate_private_key-に関連付けられた秘密鍵audius_delegate_owner_wallet
外部で管理されているPostgres DBを使用している場合は、このセクションを参照してください。
詳細設定
環境バリュエーションの設定
# to set individual environment variables
# valid service-names are “creator-node” or “discovery-provider”
audius-cli set-config creator-node
audius-cli set-config discovery-provider
# to set all the required environment variables for a service, use the –required flag
audius-cli set-config –required creator-node
audius-cli set-config –required discovery-provider
【クリエイター】
必要なクリエイターのーど環境変数は4つあり、ここのクリエイターノードセクションで利用できます。
変数と説明の完全なリストはここにあります。
通常、ノードオペレーターは、他の環境変数を変更する必要はありません。
【クリエイター】
必要なクリエイターのーど環境変数は4つあり、ここのクリエイターノードセクションで利用できます。
変数と説明の完全なリストはここにあります。
通常、のーどオペレーターは、他の環境変数を変更する必要はありません。
【外部クリエイターノード】
セットアップ中に外部のPostgres URLを設定した場合は、このセクションをスキップできます。
セットアップ中に外部のPostgres URLを設定せず、今すぐ追加したい場合は、次のコマンドを実行してdburlを置き換えます。
audius-cli set-config creator-node
key : dbUrl
value : <db url>
【ディスカバリー】
必要なディスカバリープロバイダー間故郷変数は2つあり、個々のディスカバリープロバイダーセクションで利用できます。
変数と説明の完全なリストはここにあります。
通常、ノードオペレーターは、他の環境変数を変更する必要はありません。
【外部検出プロバイダーのPostgres】
セットアップ中に外部のPostgres URLを設定した場合は、このセクションをスキップできます。
以下は、外部で管理されているPostgres（バージョン11.1以降）で＾食べーすを使用しちえる場合のみです。
audius-cli set-config discovery-provider
key : audius_db_url
value : <audius_db_url>
# If there’s no read replica, enter the primary db url for both env vars.
audius-cli set-config discovery-provider
key : audius_db_url_read_replica
value : <audius_db_url_read_replica>
管理対象のPostgresデータベースで、「temp_file_limit」フラグをに設定2147483647し、宛先データベースで次のSQLコマンドを実行します。
CREATE EXTENSION pg_trgm;
audius-cli launch creator-node
# or
audius-cli launch discovery-provider (–seed)
# Options:
# –seed
# Seeds the database from a snapshot. Required for first-time discovery setup.
【Kubernetesからの移行】
# Clone and install related dependencies
git clone https://github.com/AudiusProject/audius-docker-compose.git ~/audius-docker-compose
bash ~/audius-docker-compose/setup.sh
# Get configs from k8s-manifests and set them again via set-config
cat ~/audius-k8s-manifests/config.yaml
audius-cli set-config <service>
# Remember to configure firewalls and load balancers to allow the service port through
# Turn off Postgres on the host. If this command returns an error it’s not a problem.
sudo systemctl stop postgresql.service
# Remove kube
audius-cli auto-upgrade –remove
kubectl delete –all-namespaces –all deployments
kubectl delete –all-namespaces –all pods
sudo kubeadm reset
# Launch the service
audius-cli launch <service>
ガバナンス
ガバナンスは、AUDIOトークン所有者がチェーン上の提案を通じてAudiusへの変更を制定するプロセスです。
これにより、コミュニティはプラットフォームの将来のいてレーションを直接形成することができ、Audiusの分散型インフラストラクチャを推進するコア原理です。
この投稿では、Audiusでガバナンスがどのように機能するか、及びAUDIOホルダーとして参加sるうために何ができるかについて説明します。
詳細
Audiusガバナンスの信頼できる唯一の情報源は、「ガバナンス」タブのプロトコルダッシュボードにあります。
ここでは、全てのアクティブな提案と解決済みの提案リストを、それらが合格したか失敗したかとともに時系列で表示できます。
全てのガバナンス提案には、次のパラメーターの内訳が付属しています。
・提案者：提案を提出sるう責任のある住所
・説明：ガバナンス提案に伴うものの簡単な統合
・対象：提案に賛成する投票数
・反対：提案に対する投票数
全ての提案は、ステーキングされた＄AUDIOクォーらむの5％と50％の過半数の対象となります。
これは、プロポーザルが合格するには、ステーキングされた全ての＄AUDIOの少なくとも5％がプロポーザルに投票する必要があり、投票の50％以上がプロポーザルの「賛成」である必要があることを意味します。
現在、ノードを実行している人だけがチェーン上で提案をすることができます。
将来的には、許可された提案者のセットは、コミュニティが適切と考える方法で拡張される可能性があります。
【ガバナンス過程】
効果的なガバナンスは、チェーン上の提案に投票するだけでなく、Audiusでさらにアクセスしやすくしたいと考えています。
AUDIO投票の背後にあるツール・プロセス・ロジスティクスなど、Audiusの進化するガバナンスエコシステムの内訳は次の通りです。
Discordのフィードバく＞フォーラムの投稿＞ガバナンスポータルに送信＞オンチェーン投票＞実行
一部のユーザーは他のユーザーよりもこのプロセスの期間を促進する傾向があることに注意してください。
Audiusの形式に関心のある人は、Discordのトピックについて会話を始めることを意味する場合でも、可能な限り貢献することをお勧めします。
【Discordのガバナンス】
AUDIOphile Discordでは、ガバナンスと呼ばれるチャネルがあります。
これは、コミュニティのフィードバックのために、提案の初期反復とアイデアを提出できる場所です。
Discordで提案に関するフィードバックを得る必要はありませんが、フォーラムに提出してより正式な議論を行う前に、トピックを具体化する価値があるかどうかの一般的な感覚を掴むための優れた方法です。
ガバナンスのトピックは、提案者が他のコミュニティメンバーから非常に高いレベルのフィードバックを受け取り、彼らのアイデアが原則としてうまく受け入れられるかどうかを確認するためのシグナル手段とみなすことができます。
【Audius フォーラム】
Audiusガバナンスフォーラムは、提案に関する詳細を議論するための主要な真書です。
全ての提案は、次のトピックをカバーすることをお勧めします。
・タイトル：この提案は何についてですか？
・まとめ：この提案の簡単な説明/EIL5とは？
・要約：この提案が実施された場合はどうなりますか？このような追加のコンテキストと情報を提供できますか？
・動機：この提案とAudiusへの利益の背後にある理由は何ですか？
・仕様：この提案に賛成又は反対の投票はどの様な意味ですか？
・投票：この提案に賛成または反対に投票しますか？
まだ始まったばかりのAudiusガバナンスフォーラムは、意見をまとめて投票する前に、考えを形式化するのに最適な場所です。
オンチェーン投票には多くのシグナルと調整が必要になるため、ガバナンストーファムは、コミュニティ投票のためにオンチェーンで提案する前に、提案の詳細を最終決定するための優れた方法を提供します。
【ガバナンスポータル】
フィードバックを受け取った後、のーどオペレーターは、ガバナンスポータルを介してチェーン上でその提案を送信できます。
提案力は、ネットワークセキュリティのためにステーキングされた、または委任された（Delegated）AUDIOの量と相関関係があることに注意してください。
つまり、のーどオペレーターがオンチェーン提案の主要な候補です。
全てのオンチェーン提案のリストは、ここにあります。
提案の詳細は、提案の実装に必要な技術的変更に関する詳細と実装を含め、フォーラムの投稿で概説されている仕様にマッピングする必要があります。
オンチェーンでの投票
Figmentの最新のガバナンス提案を例として使用すると、様々なのーどオペレーターと委任者が、投票時間を48時間から72時間に延長することに賛成したことがあります。
総投票数（1AUDIO 1票）がクォーラム要件の〜11M＄AUDIOを上回り、50％の過半数（100％が賛成）で提案が可決されました。
そうすることで、この提案からの変更はガバナンス契約を通じて実行され、投票期間が48時間から72時間に変更されました。
【マルチシグコミュニティ】
投票が通過すると、ガバナンス契約が提案を実行します。
ただし、Audiusは、ガバナンスセクションの短絡サブセクションのホワイトペーパーで参照されている、最後の手段の拒否権としてのコミュニティマルチしぐも備えています。
これは、9人のAudiusコミュニティメンバーのセットが悪意のある提案の通過を阻止する能力を持っていることを意味します。
マルチシグが使用される場合、9人の著名者のうち6人は、提案を無効にするためにトランザクションに著名する必要があります。
Audiusが成熟し続けるにつれて、コミュニティはいつでもこの拒否権をシステムから削除するために投票することができます。
このマルチシグの著名者の詳細とその使用目的は、今後のブログ投稿で共有されます。
【ガバナンスの発展】
Audiusガバナンスは、全ての＄AUDIO保有者にプラットフォームの将来の反復の声を与えることを目的とした進化するプロセスです。
上記のプロセスは、新しいツール・製品のアップグレード・オンランプに合わせて変更される可能性があり、技術的な知識に関係なく、全てのトークンユーザーがアバなんすの決定を簡単に確認して参加できるようになります。
近い将来、ガバナンスに関する詳細を共有できることを運営側は楽しみにしているようです。
開発者
APIリセット
AudiusのRESET A PIを使用すると、ネットワーク全体でトラック・ユーザー・プレイリストをクエリ・ストリーミング・検索できます。
https://discoveryprovider.audius.co/v1/tracks/trending?app_name=ExampleAppHedgehog
アプリのようなDAppsを構築します。
Hedgehogは、ユーザー名とパスワードを使用するオープンソースのクライアント側イーサリアムウォレットです。
これは、技術に精通していないユーザーの暗号プロジェクトへの参入障壁を下げることを目的としています。
キーの制御を一元化することなく、ユーザーが他のWebサイトと同じようにDAppsを操作できる様にします。
拡張機能は必要ありません。
Hedgehogは、ブラウザでユーザーの秘密鍵とウォレットを管理するMetaMaskの代替手段です。
シンプルなAPIを公開して、ユーザーが複数のブラウザーやデバイスでウォレットにサインアップしてログインできるようにする認証スキームを作成できる様にします。
【全てのトランザクションが同じ様に作成されるわけではない】
現在のイーサリアムウォレットは、全てのトランザクションを、人生の節約を動かしているように扱います。
Hedgehogは、金銭的価値が低いか全くないユースケース向けに構築されました。
注意：エンドユーザーエクスペリエンスの主な改善点は、ウォレットの複雑さを隠し、ユーザーにトランザクションの確認を強制しないことです。これは、多額の資金を移動する場合とは逆です。
【これ以上のポップアップなし】
現在の分散がアプリは、構成と使用に多くの技術的知識を必要とし、ユーザーベースを制限し、成長の可能性を減らします。
インスとーレーション
npm i –save @audius/hedgehog
【ドキュメントの例】
完全な技術ドキュメントとAPIハウツーを確認してください。
ドキュメント→https://audiusproject.github.io/hedgehog-docs/#installation
APIハウツー→https://audiusproject.github.io/hedgehog-docs/#how-to
簡単なブラウザ側のデモについては、もう探す必要はありません。
完全なエンドツーエンドの確認デモについては、デモリポジトリを参照してください。
【これを使用する理由】
全てのトランザクションが同じ様に作成されているわけではありません。
現在利用可能なウォレットは、全てのトランザクションを、ユーザーの人生の節約を動かしているように扱います。
Hedgehog は、金銭的価値が低いか全くないユースケース向けに構築されました。
※エンドユーザーエクスペリエンスの主な改善点は、ウォレットの複雑さを隠し、ユーザーにトランザクションを常に確認させないことです。これは、多額のお金を移動するときに必要なものとは逆です。
【Hedgehog のDApps】
Hedgehog は全てのDAppsに適しているわけではありません。
ユーザーエクスペリエンスの大幅な改善は、トレードオフによってのみ可能です。
原則として、Hedgehog は多額の金額を伴うアプリには使用しないでください。
ブリッジとして、Hedgehog でユーザーを開始し、保存された値が特定のしきい値を超えて増加した場合は、より安全なウォレットに移行することを提案できます。
Hedgehog パラダイムは、既存のWeb3プロバイダーとも相互運用可能です。
【良いユースケース】
| 著名データ | ・ユーザーが著名したデータに依存する分散型アプリケーションを構築している場合（例えば、E IP-712風の著名スキームを介して）、Hedgehog はステーキング金額が十分に低い場合にエクスペリエンスを簡素化するのに役立つ |
| ゲームDApps | トランザクションに著名することほど楽しいことを台無しにするものはない ・重要な金融資産を使用しないゲーム用DAppsを構築している場合は、UXを改善することが重要 |
| 分散型音楽プレイヤー | ・消費者向けのDAppsを構築している場合、Hedgehog はユーザーエクスペリエンスを劇的に改善し、潜在的なユーザーベースを大幅に増加させる |
【悪いユースケース】
DAppsに多額の資金の移動が含まれる場合、セキュリティのトレードオフはおそらく価値がありません。
エンドユーザーエクスペリエンスに対するHedgehogの主な改善点は、ウォレットを非表示にし、ユーザーにトランザクションの確認を強制しないことです。
これは、お金を移動するときに必要なものとは逆です。
次のような状況でHedgehogを使用することは絶対にお勧めしません。
・バンキングDApps
・分散型融資
・予測市場
Hedgehogは、フロントエンドアプリケーションに存在するパッケージであり、ユーザーのエントロピー（秘密鍵の派生元）を作成及び管理します。
Hedgehogは、ユーザー名とパスワードに依存して認証アーティファクトを作成するため、ユーザーが複数のブラウザーまたはデバイスからサインアップまたはログインしてエントロピーを取得できる、使い慣れた認証しすてむを趣味レートできます。
これらのアーティファクトは、Hedgehogを介して、選択したバックエンドに保護されます。
※秘密鍵は計算されて利用可能なクライアント側でのみ使用され、ユーザーのブラウザ以外の場所に送信または保存されることはありません。
// Provide getFn, setAuthFn, setUserFn as requests to your database/backend service (more details in docs).
const hedgehog = new Hedgehog(getFn, setAuthFn, setUserFn)
let wallet
if (hedgehog.isLoggedIn()) {
wallet = hedgehog.getWallet()
} else {
wallet = await hedgehog.login(‘username’, ‘password’)
// or
wallet = await hedgehog.signUp(‘username’, ‘password’)
}
ユーザーのウォレットを作成または取得した後、ウォレットに直接資金をて供して取引手数料を支払うか、
E IP-712リレーを介して取引を中継することができます。
Auidius JabaScript SDK
Audius JavaScript（TypeScript）SDKを使用すると、Audiusプロトコルを簡単に構築して操作できます。
・Audiusでログイン
・トラックをフェッチしてストリーミングする
・ユーザー・トラック・プレイリストを検索して表示する
まとめ
この記事では、プログラミングなどかなり専門的知識の部分をピックアップ支えていただきました。
そのため普通にAudiusをプレイするだけであればここまでの知識は不必要になります。
普通にAudiusをプレイする方々は、こちらをご覧ください。→【 Audius（AUDIO）とは 】創設者・特徴・供給量・上場している仮想通貨取引所・投資における将来性まで解説
普段は私はプログラミングの知識までは追求しないのですが、あえて踏み込んでみました。
結果、やはり専門知識がないと深い理解は厳しいです。
そのためプログラミングの情報までは今後追求はしない様にします。（サッと見るだけにします。）
プログラミングなど、技術的な構造が理解できる方はここまで追求できますね。
アーティスト収益化の方法がXCADと似ているが、
— Miori (@mioriescom) July 13, 2022
これはトークン発行のためアーティストに
・トークンに流動性をつくれるくらい相当な人気
・トークン運営能力
が求められるため、収益化の難易度がかなり高いと考えられる。
既に人気なアーティストの場合はかなり稼げそうだけど、
0から始める場合は難
TikTokの場合は
— Miori (@mioriescom) July 13, 2022
・名も無きアーティストが投稿をし続け、TikTokのユーザー数増加増加と共にそのアーティストの人気者増加していった
→すると芸能人が入ってきて、更にユーザー数が増加していった
つまりTikTokの場合、順番は
名も無きアーティスト→芸能人
そう考えると
となると、
— Miori (@mioriescom) July 13, 2022
YouTubeのように再生回数などで(トークン運営能力も必要なく)楽に収益化できる分散型アプリが開発されたとしたら
そちらに一気にユーザー数を持っていかれてしまう
ただし、分散型のアプリにおいて、再生回数などで収益化する方法が可能なのかが疑問🧐
なぜなら、
もしそうだとするとライバルは中央集権のSNSになる。
— Miori (@mioriescom) July 13, 2022
分散型SNSに物凄くチャンスを感じるんだけど、
トークン価格がすんなり上昇していく道すじを想定することが難しくもある
これが考え続けていた理由でした。
結論：ガバナンストークンが相当安値で買える場合のみ私は安心していられると思う
最近のコメント