ストレージの過去からコンピューティングの未来へ：AO超並列コンピュータ

はじめに

現在、Web3の2つの主要な流れは区別されている。ブロックチェーンアーキテクチャの設計は、それがモジュラーパブリックチェーンの普及であるかどうか、常にパフォーマンスを強調するが、L1の新しいタイプのパフォーマンスの利点を反映していない、その生態系は、イーサリアムエコシステムまたは微妙な改善のレプリカであると言うことができる必然的にいくつかの審美的な疲労を人々に作っている、ユーザーの新鮮さの損失の高度な経験の同質性。しかし、Arweaveが提案した最新のAOプロトコルは目を引くもので、超高性能コンピューティングを実現し、ストレージのパブリックチェーン上で準Web2のような体験さえできる。これは、我々が現在慣れ親しんでいるスケーリング方法やアーキテクチャ設計とは大きく異なるようだ。また、そのパフォーマンスを支えるロジックはどこから来るのでしょうか？

AOを理解する方法

AOはアクター・モデルのプログラミング・パラダイムにちなんで名付けられました。Orientedの略で、Smart Weaveの拡張からその全体的な設計のアイデアだけでなく、コアコンセプトとしてメッセージパッシングにアクターモデルに従っています。簡単に言えば、AOは、Arweaveネットワーク上でモジュールアーキテクチャによって動作する「超並列コンピュータ」と理解することができる。実装面では、AOはモジュール型の実行レイヤーではなく、メッセージングとデータ処理を司る通信プロトコルである。このプロトコルの中核的な目標は、メッセージの受け渡しを通じて、ネットワーク内のさまざまな「アクター」間のコラボレーションを実現することであり、その結果、無制限に性能を積み重ねることができるコンピューティング・レイヤーを実現し、最終的には、分散化された信頼できる環境で、Arweaveの「巨大なハードディスク・ドライブ」を実現することである。その結果、Arweaveの「巨大ハードディスクドライブ」は、中央集権化されたクラウドのレベルで、分散化された信頼環境のスピード、スケーラビリティ、拡張性を持つことになる。

AOのアーキテクチャ

AOの哲学は、昨年のPolkadot DecodedカンファレンスでGavin Woodが提案した「コアタイム」の分割と再合成に似ているところがあるようです。どちらも、いわゆる「高性能ワールドコンピュータ」を実現するために、コンピューティングリソースをスケジューリングし、調整するというものだ。しかし、本質的には両者にはいくつかの違いがあり、エキゾチック・スケジューリング（Exotic Scheduling）は、中継チェーンのブロック空間リソースの分解・再編成であり、ボカのアーキテクチャには大きな変化はなく、計算性能も、スロットモデルの下での単一並列チェーンの限界は突破するものの、上限はやはりボカの最大アイドルコア数に制限される。AOは理論的にはほぼ無制限の計算能力を提供でき（実際にはネットワークインセンティブのレベルに依存するはずである）、ノードの水平拡張を通じてより高い自由度を提供できる。 建築的には、AOはデータ処理方法とメッセージの表現を規制し、3つのネットワークユニット（サブネット）を通じて情報の並べ替え、スケジューリング、計算を完了し、規制の方法と異なるユニットの機能は公式情報に従って分析できる。

• プロセス：プロセスは、AOで実行される命令の集まりとみなすことができる。プロセスは、仮想マシン、スケジューラ、メモリ要件、必要な拡張機能など、必要なコンピューティング環境を定義することで初期化できる。これらのプロセスは、「ホログラフィック」状態（以下の検証可能な問題のセクションで説明するように、各プロセスデータは、Arweaveのメッセージログに独立してその状態を保存することができます）を維持します。ホログラフィックな状態は、プロセスが独立して動作できること、実行が動的で適切な計算ユニットによって実行できることを意味します。

• メッセージ: ユーザー(メッセージは、ArweaveのネイティブなANS-104データ・アイテムに準拠しなければなりませんので、Arweaveの情報保存のためにネイティブな構造を一貫したものに保つことができます。より理解しやすい意味では、メッセージは従来のブロックチェーンにおける取引ID（TX ID）と多少似ていますが、同一ではありません。

• メッセンジャーユニット（MU）：MUは、シームレスな相互作用を保証するためにメッセージを中継する「クランク」と呼ばれるプロセスを通じて、システム内の通信の配信を担当します。メッセージが送信されると、MUはそれをネットワーク内の適切な宛先（SU）にルーティングし、相互作用を調整し、生成された送信トレイメッセージを再帰的に処理する。このプロセスは、すべてのメッセージが処理されるまで続けられる。メッセージの中継に加えて、MUはプロセスのサブスクリプションを管理し、時間指定されたcronインタラクションを処理するなど、さまざまな機能を提供します。

• スケジューラーユニット（SU）：メッセージが受信されると、SUは以下を開始します。プロセスの継続性と整合性を維持するために、一連の重要な処理を開始する。メッセージを受信すると、SUは、同じプロセス内の他のメッセージとの相対的な順序を保証する一意のインクリメンタルNonceを割り当てる。この割り当てプロセスは、真正性とシーケンスの完全性を保証する暗号署名によって形式化される。プロセスの信頼性をさらに高めるため、SUは署名の割り当てとメッセージをArweaveデータレイヤーにアップロードします。

• コンピューティング・ユニット（CU）：CUは、ピアツーピアのコンピューティング・マーケットプレイス内で、ユーザーとSUを完了させることで互いに競争します。ユーザーとSUがプロセスの状態を計算するサービスを解決する。状態計算が完了すると、CUは特定のメッセージの結果を署名した証明書を呼び出し元に返す。さらに、CUは、他のノードが読み込むことができる状態の署名付き証明を生成して公開することができ、もちろんこれにはコストの割合が必要です。

オペレーティングシステムAOS

AOSは、スレッドのダウンロード、実行、管理に使用できるAOプロトコルのオペレーティングシステム、またはターミナルツールと考えることができます。開発者がアプリケーションを開発、デプロイ、実行できる環境を提供する。AOS上で、開発者はAOプロトコルを使用してアプリケーションを開発、展開し、AOネットワークとやりとりすることができます。

ランタイムロジック

アクターモデルは「すべてはアクターである」という哲学を推進しています。モデル内のすべてのコンポーネントとエンティティはモデル内のすべてのコンポーネントとエンティティは「アクター」と見なすことができ、それぞれが独自の状態、振る舞い、メールボックスを持ち、非同期メッセージングを通じて通信や共同作業を行う。同じロジックがAOネットワークにも適用され、コンポーネントやユーザーまでもが「アクター」として抽象化され、プロセスを相互リンクするメッセージングレイヤーを通じて互いに通信することができ、並列計算と非共有状態を持つ分散作業システムが織り成す中で構築される。

メッセージング・フローチャートのステップを簡単に説明します：

2. ユーザーまたはプロセスは、他のプロセスにリクエストを送信するためにメッセージを作成します。他のプロセスにリクエストを送るために。

3. MU（メッセンジャーユニット）はメッセージを受信し、POSTリクエストを使って他のサービスに送信します。

4. メッセージの処理と転送:

• MUはPOSTリクエストを処理し、SU（スケジューリングユニット）にメッセージを転送します。

• SUはArweaveストレージまたはデータレイヤーとやり取りし、メッセージを保存します。

5. メッセージIDに基づいて結果を取得する：

• CU(Compute)はGETリクエストを受け取り、メッセージIDに基づいて結果を取得し、プロセス上でメッセージを評価します。単一のメッセージ識別子に基づいて結果を返すことができます。

6. メッセージの取得：

• SUはGETリクエストを受信し、指定された時間範囲とプロセスIDに基づいてメッセージ情報を取得します。

7. 送信箱メッセージをプッシュする:

• 最後のステップは、すべての送信トレイメッセージをプッシュすることです。

• このステップでは、結果オブジェクト内のメッセージをチェックし、生成します。

• このチェックの結果に応じて、ステップ2、3、4を関連するメッセージや生成ごとに繰り返すことができます。style="text-align: left;">AOは何を変更したのか？"1"

  一般的なネットワークとの違い：

  1. 並列処理能力：ベースレイヤーと各ロールアップが実際には単一のプロセスとして実行されるイーサなどのネットワークとは異なり、AOは、計算の検証可能性が損なわれないようにしながら、並列に実行される任意の数のプロセスをサポートします。さらに、これらのネットワークはグローバルに同期した状態で動作するが、AOプロセスはそれ自身の独立した状態を維持する。この独立性により、AOプロセスはより多くの相互作用と計算スケーラビリティを扱うことができ、高いパフォーマンスと信頼性を要求するアプリケーションに特に適しています。

  2. 検証可能な再現性AkashやピアツーピアシステムUrbitのようないくつかの分散型ネットワークは、大規模な計算能力を提供しますが、AOとは異なり、相互作用の検証可能な再現性を提供しません。

  AOのノードネットワークは、従来のコンピューティング環境とどう違うのか：

  • 互換性：AOは、WASMまたはEVMに基づくかどうかにかかわらず、さまざまな形式のスレッドをサポートしています。

  • コンテンツ共創プロジェクト：AOはコンテンツ共創プロジェクトもサポートしており、アトミックNFTを公開したり、データをアップロードしたり、UDLを組み合わせてAO上でNFTを構築することができます。

  • コンテンツ共創プロジェクト：AOはコンテンツ共創プロジェクトもサポートしています。

  • データコンポーザビリティ：ARとAOのNFTは、データコンポーザビリティを可能にします。これは、データソースと元のプロパティの一貫性を維持しながら、記事やコンテンツの一部を複数のプラットフォームで共有および表示することを可能にします。コンテンツが更新されると、AOネットワークはその更新状況をすべての関連プラットフォームにブロードキャストすることができ、コンテンツが同期され、最新の状態が発信されることが保証される。

  • 価値と所有権：コンテンツ制作者は、NFTとして作品を販売し、AOネットワークを通じて所有権情報を渡すことで、コンテンツに価値を還元することができます。

  プロジェクトのサポート：

  1. Arweave上に構築：AOは、単一障害点、データ漏洩、検閲などの集中型プロバイダーに関連する脆弱性を排除するArweaveの機能を活用しています。

  2. 分散型基盤：AOの分散型基盤は、物理インフラによって課されるスケーラビリティの制約を克服するのに役立ちます。専門的な知識やツール、インフラを必要とせず、誰でも簡単にAOプロセスを作成できるため、個人や小規模な組織であっても、グローバルなリーチと参加が可能になります。

  AOの検証可能性の問題

  AOのフレームワークとロジックを理解した後、通常は一般的な問題があります。には、従来の分散型プロトコルやチェーンのようなグローバルな特徴はないようで、Arweaveにデータをアップロードするだけで、検証可能性と分散化を実現できるのだろうか？実は、これこそがAOの設計の謎なのだ。AOはオフチェーンの実装であり、検証可能性の問題を解決したり、コンセンサスを変えたりするものではない。ARチームのアイデアは、AOとArweaveの機能を分離し、接続をモジュール化して、AOは通信と計算のみを行い、Arweaveはストレージと検証のみを行うというものだ。両者の関係はマッピングのようなもので、AOはArweaveにインタラクション・ログが保存されていることを確認するだけでよく、その状態をArweaveに投影してホログラムを作成することができる。このホログラフィックな状態投影により、状態を計算する際のアウトプットの一貫性、信頼性、確実性が保証される。さらに、AOプロセスを逆にトリガーして、アルウィーヴのメッセージログから特定の操作を実行することもできます（アルウィーヴは自ら起動し、あらかじめ定義された条件やスケジュールに従って、対応する動的操作を実行することができます）。

  

  Hill氏がOutprogと共有した内容に基づくと、検証ロジックをもう少し単純化すれば、AOは超並列インデクサに基づく碑文計算フレームワークと考えることができる。ビットコインの碑文インデクサーは、碑文からJSON情報を抽出し、オフチェーンデータベースに残高情報を記録し、一連のインデクシングルールによって検証を完了することで、碑文を検証することは周知の通りです。インデクサはオフチェーン検証ですが、ユーザーは複数のインデクサを置き換えたり、自分自身でインデックスを実行することで、碑文の検証を行うことができ、インデクサが悪であることを心配する必要がなくなります。メッセージの順序やプロセスのホログラフィックな状態といったデータがArweaveにアップロードされることは前述したとおりである。したがって、SCPパラダイム（Storage Consensus Paradigm、ここでは単純にSCPがチェーン上のインデクシング・ルールのインデクサであることを意味すると理解すればよい。AO上のホログラフィック・データ、あるいはAO上のどのスレッドからでもホログラフィック・データを復元することができる。また、ユーザーは信頼された状態を確認するためにフルノードを実行する必要はない。インデックスを交換する場合と同様に、SUを介して単一または複数のCUノードにクエリーリクエストを行うだけでよい。Arweaveのストレージ容量は大きく安価であるため、このロジックを使えば、AOの開発者はビットコインのインスクリプションの能力をはるかに超えるスーパーコンピューティング・レイヤーを実装することができる。

  AOとICP

  AOの特徴をもう少しキーワードでまとめると、巨大なネイティブハードドライブ、上限なしの並列処理、上限なしの計算、モジュール式全体的なアーキテクチャ、ホログラフィック・ステート・プロセス。どれも素晴らしく聞こえるが、ブロックチェーン上の様々なパブリック・チェーン・プロジェクトに詳しい人は、AOが世界で「最も致命的な」プロジェクトの1つ、かつて人気を博した「インターネット・コンピュータ」ICPに似ていることに気づくかもしれない。

  ICPはかつて、ブロックチェーン界の最後の一流プロジェクトと称され、一流機関からも高い人気を誇り、21年の強気相場では2000億ドルのFDVに達したが、その波が引くにつれ、ICPのトークン価値は急落した。23年の弱気相場まで、ICPのトークン価値は史上最高値の260倍近く下落した。しかし、トークン価格のパフォーマンスを考慮せずに、この時点でICPを改めて見たとしても、ICPにはICPのユニークな特徴が多く残っており、現在のICPが持つAOの素晴らしい特徴の多くは、当時も存在していた。では、AOはICPのように失敗するのだろうか？まず、なぜ両者が似ているのかを理解しよう。 ICPとAOはどちらもアクター・モデルに基づいており、ローカルで実行されるブロックチェーンに焦点を当てている。 ICPサブネットワーク・ブロックチェーンは、独立して所有・制御される多数の高性能ハードウェア・デバイス（ノードマシン）で構成され、インターネット・コンピュータ・プロトコル（ICP）を実行する。ICPは、サブネット・ブロックチェーン内のすべてのノードにわたって状態と計算を複製するため、バンドルとしてレプリカとなる多数のソフトウェア・コンポーネントによって実装される。

  ICPのレプリケーション・アーキテクチャは、上から4つのレイヤーに分けることができます：

  ピアツーピア（P2P）ネットワーク・レイヤー：ユーザー、そのサブネットワーク・ブロックチェーン内の他のノード、およびサブネットワーク・ブロックチェーン内の他のノードから情報を収集し、アドバタイズするために使用されます。他のノード、および他のサブネットワークブロックチェーンから情報を収集します。

  コンセンサス層：ユーザーや異なるサブネットから受信したメッセージを選択、ソートしてブロックチェーンブロックを作成し、進化し続けるブロックチェーンを形成するフォールト・トレラント・コンセンサスのビザンチンによって公証、最終決定されます。公証と最終化のためのフォールト・トレラント・コンセンサス。

  メッセージルーティング層：ユーザーやシステムが生成したメッセージをサブネット間でルーティングし、Dappの入力キューと出力キューを管理し、メッセージの実行をスケジュールするために使用されます。

  実行環境層：メッセージルーティング層から受信したメッセージを処理することで、スマートコントラクトの実行に関わる決定論的な計算を行う。

  

  サブネット・ブロックチェーン

  サブネットと呼ばれるものは、独自のブロックチェーンを作成するために、コンセンサスメカニズムの別々のインスタンスを実行する相互作用するレプリカの集まりであり、その上で一連の「コンテナ」を実行することができる。各サブネットは他のサブネットと通信することができ、ルートサブネットによって制御される。ルートサブネットは、チェーンキー暗号を使用して個々のサブネットに権限を委譲する。従来のブロックチェーン（と個々のサブネット）の問題点は、コンセンサス・アルゴリズムに参加するためには、各ノードがブロックチェーン上で起こるすべてのことを実行しなければならないため、単一のノードのマシンの計算能力によって制限されてしまうことだ。複数の独立したサブネットを並行して実行することで、ICPはこのシングルマシンの壁を突破することができる。

  なぜ失敗するのか

  ICPアーキテクチャが実現しようとしているのは、前述したように、単なる分散型クラウドサーバです。数年前、このアイデアはAOと同じくらい衝撃的だったが、なぜ失敗したのだろうか？簡単に言えば、高みも低みも達成できず、Web3と独自のコンセプトのバランスがうまく取れず、最終的にはWeb3ではなく、中央集権型のクラウドのようにうまく機能しないという恥ずかしい事態を招いたのである。結論から言えば、3つの問題があった。第一に、ICPのプログラムシステムであるCanisterは、上記の記事でいう「コンテナ」であり、実際にはAOのAOSやプロセスと多少似ているが、同じではない。ICPのプログラムはCanisterによってカプセル化され実装されており、外部からは見えないため、特定のインターフェースを通じてデータにアクセスする必要がある。DeFiプロトコルの契約呼び出しのための非同期通信の下では、非常に不親切であるため、DeFiの夏では、ICPは対応する財務価値を捕捉しません。

  

  2つ目のポイントは、ハードウェア要件が非常に高く、結果としてプロジェクトが分散化されていないことです。下図は、当時ICPが示したノードの最小ハードウェア構成ですが、現在に置き換えたとしても、非常に誇張されており、Solanaの構成よりもはるかに多く、ストレージ要件でさえストレージパブリックチェーンよりも高くなっています。

  

  3点目はエコロジーの欠如です。ICPは現在でも非常に高性能なパブリックチェーンです。DeFiアプリがないのであれば、他のアプリは？申し訳ないが、ICPは誕生以来キラーアプリを走らせておらず、そのエコシステムはWeb2もWeb3もユーザーを取り込んでいない。結局のところ、これほど分散化が進んでいないのであれば、コンテンツが豊富で成熟した中央集権型のアプリケーションを使えばいいのではないか？しかし結局のところ、ICPの技術が依然として一流であることは否定できず、その逆ガス、高い互換性、無制限のスケーラビリティは、次の10億人のユーザーを惹きつけるために依然として必要であり、現在のAIの波の中で、ICPが独自のアーキテクチャの利点をうまく利用できれば、まだ逆転の可能性があるかもしれない。

  では、上の質問に戻るが、AOはICPのように失敗するのだろうか？個人的には、AOが同じ失敗を繰り返すとは思いません。 そもそもICPの失敗を招いた最後の2点は、AOにとっては問題ではありません。アーウィーブはすでに優れたエコロジーの基盤を持っていますし、ホログラフィック状態投影は中心性の問題を解決しています。より多くの挑戦は、経済モデルの設計、DeFiのサポート、そして世紀のパズルである、非金融とストレージの世界でWeb3がどのような形をとるべきか、に焦点を当てなければならないかもしれない。

  Web3は物語で止まるべきではない

  Web3の世界で最も頻繁に使われる言葉は「物語」である。「そして私たちは、ほとんどのトークンの価値をナラティブという観点から測定するようにさえなっています。これは当然、Web3のプロジェクトのほとんどが、素晴らしいビジョンを持っているが使いづらいというジレンマからきている。これとは対照的に、ArweaveはすでにWeb2レベルの体験に完全に根ざし、ベンチマークされた数多くのアプリケーションを持っている。例えば、Mirror、ArDrive、これらのプロジェクトを使ったことがある人なら、従来のアプリケーションとの違いを感じるのは難しいはずだ。しかし、ストレージ・パブリック・チェーンとしてのArweaveの価値獲得にはまだ大きな限界があり、コンピュートの方がいいかもしれない。特にAIがトレンドとなっている今日の対外的な世界では、Web3は現段階ではまだ取り入れるには自然な障壁が多く、それは過去の記事でもお話しした通りだ。ArweaveのAOは、非イーサ・モジュラー・ソリューションのアーキテクチャによって、Web3 x AIに素晴らしい新しいインフラを与えた。アレクサンドリアの図書館から超並列コンピュータまで、Arweaveは独自のパラダイムを歩んでいる。