構造が機能を決定する：AO分析とNostr分析の比較

超並列コンピューティングのAOと分散型ソーシャル・プロトコルのNostrの比較は？それぞれの位置づけと発展の道筋を教えてください。

見出しを読むと、AOは超並列コンピューティングの略で、Nostrは分散型ソーシャル・プロトコルの略であり、全く異なる分野のように思われ、比較するのは容易ではないと思われるかもしれない。しかし、技術的な実装を掘り下げてみると、両者は本質的に「メッセージング・プロトコル」であり、比較可能であることがわかる。

メッセージング・プロトコルとして、核となる要素は当然メッセージそのものであり、すべてはメッセージの配信を中心に展開されます。では、AOとNostrのネットワークでは、メッセージはどのように定義されているのでしょうか？メッセージングをサポートするネットワーク・アーキテクチャはどのように構築されているのか？他のプロトコルとどのように統合されているのか？それぞれの立場、主要なアプリケーションシナリオ、そしてトレンドは何でしょうか？

本稿では、AOとNostrの詳細な比較を行い、プロトコル構造が機能に与える影響に焦点を当て、これらの問題を詳細に分析することを目的としています。

メッセージの概念と特徴

AOにおけるメッセージ

AOネットワークアーキテクチャでは、メッセージは個々のネットワークユニット（MU、SU、CU）間、または個々のプロセス間でやり取りされる情報の基本単位です。メッセージを送受信することで、情報を交換し、共同作業を行います。

AOはメッセージ駆動型の非同期通信ネットワークとして設計されています。第一に、AOは作業を開始（プロセスを起動）する際に、外部ユーザーや他のプロセスから来るメッセージによって駆動される必要があります。第二に、AOにおけるプロセス間通信は非同期であり、メッセージは送信側と受信側の操作とは無関係に送受信される。メッセージを送信したプロセスは、受信側からの応答や確認を待つ必要がなく、すぐに他の処理を続けることができる。この機能は、AO並列コンピューティングの効率を大幅に向上させます。

AOネットワークでは、メッセージの非同期転送と待機の欠如により、システムの一部が他のプロセスの応答を長時間待つことなく並列実行できるため、大規模な並列コンピューティングタスクを処理するのに理想的です。

AOでは、各メッセージはArweaveエコシステムのANS-104標準に準拠しています。これは、バイナリの複数のトランザクションを単一のネイティブ・トランザクションに直列化することで、データの読み取り/書き込みのスループットを劇的に向上させるデータ・パッキング・プロトコルです。このプロトコルは、パックされたデータに所有者、署名、宛先アドレス、タグ、データなどのフィールドを追加することで、単純なデータパックを超えています。この設計により、ANS-104は、文書、画像、オーディオ、ビデオ、ゲーム、データモデル、プログラムコード、ホログラフィックステートなど、さまざまなデータタイプをサポートすることができます。さらに、データの所有権と署名検証をサポートし、データのセキュリティと整合性を提供します。

AANS-104標準のこれらの機能は、AOにとって特に重要です。なぜなら、AOは異なるデータタイプに対して多様なアプリケーションシナリオを構築することができるからです。また、統一されたメッセージフォーマットは、効率的なコミュニケーションとプロセス間のシームレスなコラボレーションを大幅に促進し、Arweave上のストレージと決済処理の効率を向上させるため、AOはデータ可用性レイヤーとデータコンセンサスを効率的に構築し、幅広いアプリケーション要件をサポートすることができます。

イベント

Nostrプロトコルでは、さまざまなタイプのデータを記述するために、JSON構造に基づいた標準メッセージフォーマットが定義されています。Nostrプロトコルでは、さまざまなタイプのデータを記述するために、JSON構造に基づいた標準的なメッセージフォーマットが定義されています。このメッセージフォーマットはイベントと呼ばれ、Nostrネットワークの基本的なデータオブジェクトです。

最も一般的に使用されるメッセージ構造は、NIPs（Nostr Implementation Possibilities）プロトコル標準と呼ばれる、一般的に従う標準に統合されています。この一貫性と標準化により、データ処理と管理の効率が大幅に改善され、システムの相互運用性と安定性が向上します。NIPsにより、ユーザーはデータ形式の違いや非互換性を気にすることなく、Nostrネットワーク上でさまざまな操作ややり取りを行うことができます。

JSON構造は、Nostrプロトコルのイベントデータのフォーマットを定義するために使用され、それぞれ異なる役割を持つフィールドを含んでいます：

• pubkeyフィールド。strong>pubkeyフィールド:イベントを送信したユーザーの公開鍵を示します。この公開鍵は、イベントの真正性と完全性を保証するためのデジタル署名に使用される。

• kind field:イベントのタイプを示すために使用されます。チャットルームメッセージ、ウォレットメッセージなど、異なるメッセージタイプを示すこともできますし、リレーリストの推奨、アクションの実行など、特定のユーザー行動を示すこともできます。

• content field:イベントの特定のコンテンツを含みます。このフィールドは、ソーシャルメディアへの投稿、エッセイ、オーディオ、ビデオなど、さまざまなデータタイプをサポートしています。ユーザーは伝えたい様々な情報やデータをここで表現することができます。

• sig field:イベントのデジタル署名を保存するために使用されます。この署名は送信者が秘密鍵を使って生成し、受信者のクライアントが対応する公開鍵を使って検証します。この署名は、対応する公開鍵を持つユーザーが特定の日付に実際にイベントを送信したことを保証し、イベントの信頼性と検証可能性を高めます。

• ......

イベントデータ構造の詳細な説明は以下にある。https://nostr.how/zh/the-protocolcontent。これらのフィールドと構造により、Nostrプロトコルはイベントを送信、受信、検証するための明確なフレームワークを提供します。この設計は、データのセキュリティ、一貫性、および信頼性を確保するのに役立ちます。

すべてのフィールドは、特定の役割を果たす完全なイベントを表現する方法として組み合わされます。一言で言えば、イベントは任意のコンテンツを含み、ユーザーによって署名されたデータ構造であり、この構造はNostrの立場、アイデンティティ、役割を反映しています。

• Nostrは情報を公開、保存、受信するシステムです。JSON構造とNIPsプロトコル標準を採用することで、Nostrは効率的なデータ交換と管理のフレームワークを確立し、情報の一貫性と解決可能性を保証し、ユーザーに安定した信頼性の高い統一された情報通信環境を提供します。strong>クライアント側での検証をサポート：データ構造はクライアント側での検証をサポートしているため、中継サーバーや第三者を信頼する必要がなく、イベントの真正性と完全性を直接検証することができます。

• Build a decentralised, censorship-resistant, and verifiable social network: このデータ構造の性質により、Nostrは分散型プラットフォームとして機能することができます。検閲やメッセージの改ざんを恐れることなく。

メッセージングをサポートしたネットワーク構造

共同ネットワークとしてのAO: MU/SU/CU

共同ネットワークとしてのAO: MU/SU/CU

共同ネットワークとしてのAO: MU/SU/CU

AOネットワークは、図1-1に示すように、MU、SU、CUの3つのモジュール式基本ユニットで構成され、メッセージとプロセスを通じて動作し、協働する。

図1-1：モジュール式で相互運用可能なネットワークユニットがAOネットワークを形成している。AOのネットワーク・アーキテクチャを形成するネットワーク・ユニット（画像はAOホワイトペーパーより）

プロセスは、AOネットワークにおける計算の単位です。 アプリケーションを起動することは、AO上で1つ以上のプロセスを起動することと同じであり、システムはMUなどの各プロセスのリソースを割り当て、スケジューリングします、

• MU（メッセンジャー・ユニット）：これはメッセンジャー・ユニットで、情報を適切なSUに送信して処理し、CUに配信して計算を実行し、計算結果をメッセンジャー・ユニットであるSUに返します。

• SU（スケジューラーユニット）：これはスケジューラーユニットで、スケジューリングとメッセージの順序付けを担当し、メッセージをArweaveにアップロードします。

• CU（計算ユニット）：これは計算ユニットで、メッセージを受け取り、計算を実行し、状態遷移を実装します。

上記のように、AOのネットワーク構造と動作は、以下のことを示しています：

• AOはメッセージングシステム

  です。p>

メッセージはプロセスの中核要素であり、MU、SU、CUが取り組む唯一のものである。プロセス全体はメッセージを中心に回っており、プロセスとはメッセージの集まりの実行活動であり、メッセージの受け入れから、メッセージの送信、メッセージのスケジューリングと順序付け、計算（メッセージの状態遷移）の実行、計算結果の出力と保存までを包括している。

つまりAOは、分散型ソーシャルネットワーク、ソーシャルメディア、分散型オーディオ/ビデオオンデマンド/ライブプラットフォームなど、情報発信やリアルタイムコミュニケーション、インタラクション、コンテンツ配信のためのアプリケーション構築に特化したメッセージングシステムなのです。

• AOは超並列コンピューティングネットワークです

AOはモジュラーネットワークであり、計算がオフチェーンで実行されます。ブロックコンセンサスによる制約がないため、計算ユニット（ノード）は必要に応じて無限に拡張でき、計算性能が大幅に向上します。

AO環境では、任意の数の計算タスク（並列プロセス）を同時に開始し、異なる計算ノード上で独立して実行し、ローカルで検証することができます。これにより、AOは分散型の検証可能な超並列コンピュータとなります。

個々の計算プロセスは、異なるノード上で独立して実行することができますが、統一メッセージフォーマット（ANS-104）を通じて、互いにメッセージを送り合い、協力することができます。このアプローチでは、独立して実行されている計算プロセスを結びつけて、統一されたネットワークを形成します。

• AOはオープンプラットフォームです

AOはその中核にメッセージングプロトコルを持ち、そのプロトコルによって、異なるアプリケーション上で実行されている異なるアプリケーション同士が通信することができます。異なるアプリケーションが互いに通信できるようにします。各アプリケーションは、AOネットワークを介して他のアプリケーションにメッセージを送信することができ、AOを使用して組み合わせ演算を実行し、チェーン全体で情報を交換することができます。

AOネットワークはオフチェーンで動作し、Web2アプリケーションとのシームレスな接続を可能にします。Web2アプリケーションは、AOプロトコル・インターフェースを呼び出すことで、この分散型ネットワークに参加することができます。

AOの通信プロトコル設計メカニズムにより、AOは開発者にとって無限の可能性を秘めたオープンプラットフォームとなります。

要約すると、AOのネットワーク・アーキテクチャは、コンポーザブルで、相互運用可能で、スケーラブルで、検証可能で、分散型で、オープンなコンピュータ・ネットワーク・プラットフォームをサポートします。これは、情報発信やコミュニケーションの相互作用に焦点を当てたソーシャル・アプリケーションに適しているだけでなく、機械学習、自律的意思決定エージェント、グラフィカル・レンダリング、オンライン・ゲーム、DeFiアプリケーションなど、より高い計算性能要件やより複雑なビジネス・ロジックを持つアプリケーションをサポートすることもできます。

Nostr：クライアント-リレー・アーキテクチャ

Nostrは「ノートとリレーによって送信されるその他のもの」アーキテクチャです。Other Stuff Transmitted by Relays」、つまり「リレーによって送信されるノートとその他のもの」という意味です。ネットワークには主に2つのコンポーネントがあり、ネットワーク構造は図1-2のようになっている。

図1-2 Nostrのネットワーク・アーキテクチャ

• Client

これはユーザー側で実行されるアプリケーションで、中継サーバーにデータを読み書きします。クライアントは公開鍵をユーザーがイベントを送受信するアドレスとして使用し、秘密鍵はイベントが送信される際に、それがユーザー自身の行為であることを証明し、改ざんを防ぐための署名に使用されます。イベントを受信する際、クライアントは秘密鍵を使って署名を検証し、イベントの発信元と整合性を確認する。

クライアントは、ユーザーが異なる場所にある任意の数のリレーサーバーに接続することを可能にします。ユーザーはあるリレーで情報を公開し、別のリレーで情報を取得することができます。つまり、クライアント（ユーザー）は特定のリレーサーバーに依存する必要がないため、ユーザーのデータや行動を効果的に保護することができます。

• リレーサーバー

リレーサーバーには、接続されたクライアントからのイベントをリッスンし、キャプチャし、保存する機能があります。クライアントを受信し、それらのイベントをサブスクライブしているクライアントに転送します。

誰でもリレーサーバーを運営することができ、複数のリレーサーバーを互いに代用することができる。 この設計は、単一のリレーの重要性を弱め、単一障害点のリスクを低減し、検閲を改善する。さらに、複数のリレー間の競争は、より大きなストレージ容量、より速い応答時間、スパムフィルタリングなどのサービスを提供するなど、サービスの質の向上を促進することができます。

リレーサーバーは、加入者のコンテンツのすべてまたは一部を必要な期間だけ保存することを選択できるため、リレーの位置づけやビジネスの進め方に柔軟性が生まれます。同時に、リレー・サーバーは互いに通信する必要がないため、コンセンサス・レベルもなく、データ同期も必要ない。データの同期はクライアント間でイベントを送受信することで実現され、ブロックチェーンノードとは根本的に異なる。

このアーキテクチャは、システムの柔軟性と効率を向上させるだけでなく、さまざまな利用シーンや要件に効果的に対応します。

このように、NostrはClient-Relayのような軽量なネットワーク構造を採用しており、システムの柔軟性と効率を向上させるだけでなく、表現の自由、円滑なコミュニケーション、データセキュリティとプライバシー管理といった人々のニーズを満たす、検閲に強く検証可能な分散型情報発信システムの構築を効果的にサポートしています。データ・セキュリティとプライバシー・コントロールのニーズこの設計は、中央集権型ソーシャルメディアの課題と欠点に効果的に対処している。その結果、Nostrは分散型ソーシャル・プロトコルとして歓迎され、Damus、YakiHonne、Irisなどの分散型ソーシャル・アプリケーションを構築する開発者に人気がある。

他のプロトコルとの統合

AO+Arweave：分散型ワールドコンピュータ