1) 過去4〜5年で多くのSolanaアプリケーションアーキテクチャを試してきましたが、そろそろその成果をまとめる時期だと感じました。最も単純なものから始めて、徐々に複雑さを増やしていく。では、まず始めます:Solanaアプリケーションアーキテクチャというスレッドです。

2) まずはイージーモードから始めましょう。おそらくこれがあなたの最初のSolanaアプリのようなものです。シンプルなReactフロントエンドは、RPCへの接続を確立します。APIサーバーは必要ありません。RPCはあなたのサーバーです。初期の頃は、getAccountInfosやカスタムのトランザクション構築ロジックなどが散見されていました。 後でパフォーマンスが落ちたときには、キャッシュやバッチ処理の層を追加します。そこで登場するのがgetMultipleAccountsです。WebSocketのサブスクリプション+ポーリングを追加してUIをリアルタイム更新するのもいいかもしれません。 このアーキテクチャは非常に高速なプロトタイピングを可能にします。デヴオペレーションはほとんどありません。サーバーコストはほとんどありません(Vercelにデプロイするだけで十分です)。ただし、いくつか大きな欠点もあります。

3) 最初に直面する問題は複雑なクエリです。このアーキテクチャでは、バニラのSolana RPCしかありません。つまり、SolanaをRPCが露出させるように、態度の問題を持つNoSQLデータベースとして扱う必要があります。ポイントクエリは問題ありません。PDAを使って、グラフデータベースのようにプログラムデータを駆使する工夫もできます。 しかし、最初のGPAを取得する必要があると、最大の痛みが待つことになります。インターフェースは全く人間工学的ではありません。動的に長さのデータを持っている場合は、まったく使えません。RPCプロバイダーによっては信じられないほど遅くなることがあります。 GPAがなくても、この方法はサーバー側レンダリングと通常のデータベースを備えた典型的なWeb2アプリよりもかなり遅い傾向があります。

4) 次に指摘された問題はトランザクション構築ロジックの移植性です。この仕組みでは、トランザクションを構築するすべてのロジックは(a)フロントエンドのコード内か、(b)コードがインポートするライブラリの中にあります。(a)の場合、フロントエンド外でトランザクションを構築したい人は最大限の苦労を味わうことになります(あなたも含めて、結局はもっと多くのアプリが必要になる場合に限られます)。(b)トランザクション構築ロジックの変更はライブラリの公開、全員のパッケージ更新、そしてUIの更新が必要です。 アカウント解決のようなAnchorツールに大きく依存することで、移植するロジックの量を最小限に抑えられますが、問題は残ります。これにより機敏性が失われ、スマートコントラクトのエンドポイントを変更しつつ、TXビルディングロジックのすべてのバージョンが動作し続けることを難しくします。

5) 三つ目の問題は、UIが一般的にトランザクションの提出に苦手で、特にリトライロジックに関してはそういうことです。ユーザーはページから離れて移動できますが、TXは再試行を停止します。大量の取引はなかなか成立しにくい傾向があります。遠くからなぜ物が着地しないのかデバッグするのは難しいです。

6) ここでの最後の問題は、このアーキテクチャを持つのはあなただけではないということです。RPCは価値があり、基本的にフロントエンドでRPCのURLを公開する必要があります。今では、誰かにRPCを盗まれてコストが上がらないように、猫とネズミのゲームに巻き込まれることになります。

7) では、次は何をするのか?たとえTXのポータビリティに触れなくても、アドレスリストのクエリを扱う必要が出ることになります。GPAは最悪で、みんなそれを知っています。つまり、ハイブリッドアーキテクチャを構築することができます。 このアーキテクチャでは、迅速なプロトタイプ作成は可能ですが、難解で醜いクエリをAPIに移行できます。その良い具体例がガバナンスです――提案書が作成され、そこには「経済」「技術」などのタグが付けられています。gPAはタグによるフィルター機能ができません。

8) このアーキテクチャはトランザクションの移植性やRPCの奪取を解決していません。しかし大規模であれば、遅い/不可能なGPAの問題は少なくとも解決できます。 しかし、新たな問題が生まれます――インデクサーです。この点については後ほど詳しく説明します。

9) 最後に、私が「エンタープライズ」と呼ぶSolanaスタックがあります。もはやSolanaをNoSQLデータベースとして扱うわけではありません。代わりに、イベントバスのように扱っているのです。フロントエンドはSolanaのデータモデルについて何も知りません。サーバーはトランザクションを構築し、それをUIに渡して署名させ、その後Solana本体に送信します。これをイベントとして扱い、インデクサーに伝播して基礎データが変わるのを待ちます。 この構成はトランザクションの移植性が非常に優れており、誰でもクリーンなパラメータでAPIにアクセスしてトランザクションや命令を返すことができます。 非常にスキビリしたUIを実現しています――UIに関して言えば、これは基本的にWeb2です。SSRを最大限に活用できます。 RPCは抽象化されてしまい、誰にもクレジットを盗まれません。 しかし、このセットアップには問題があります

10) 最初に直面する問題はインデクサーの痛みです。ここ数年(Triton、Helius、StreamingFastのチームのおかげで)は改善されましたが、それでもインデクサーを定期的にレンチで叩いてしまうことがあります。メッセージを見逃すでしょう。メッセージを見逃すと、UIが変な状態になります(例:私がNFTを送ったら、チェーン上で受け取ったのに、私のデータベースはまだ所有していると表示されます)。こういった問題はデバッグが本当に厄介です。あなたのせいですか?それはあなたのデータプロバイダーですか?誰にもわかりません！午後の時間が全部消えたな。

11) 次に直面する問題はタイミングです。すべてを直接RPCで行う場合は、コミットメントを渡し、最新のデータを処理できます。インデクサーの場合は、すべて手動で処理します。つまり、取引を構築する際には、古いデータに基づいて構築することになる可能性があります。失敗が確実な取引を返品する。 古いデータ問題は、非常に高速なデータを提供するプロバイダー(例:Heliusレーザーストリーム)を使うことで解決できます。しかし、その場合は手動で組織変更に対応しなければなりません。つまり、実際に取引が通り過ぎなかった場合は、インデックスするデータをアンインデックス化する必要があります。これは悪夢だ。

12) タイミングの問題を「ハック」することで、トランザクションはRPCのデータのみを使い、インデックスデータだけをUIに入力します。しかし、それでもユーザーはUIとチェーンの間に潜在的な不整合の問題を抱えるでしょう。つまり、フロントエンドはこのNFTを所有しているので移管できると言い、バックエンドは怒鳴って「できない」と言います。

13) この仕組みで直面する最後の問題はコストであり、大げさに言えば「分散化の死」です。Web3の夢は、大量の中央集権サーバーを展開する必要がなくなることでした。これでWeb2ショップのリードアーキテクトの仕事を得るのに十分なインフラを導入しました。お金がかかります。時間がかかります。そしてすべてが非常に中央集権的です。Web2 APIを通じて最も効果的に相互作用するなら、あなたのプロトコルはどれほど分散化されていますか?そして、SolanaにはAPIなしで操作方法を知っている開発者が72人くらいいます。

14) 最終的には、分散化に関しては絶対に譲らない。ユーザーにとって最善のことが、たいてい最善の選択となります。「エンタープライズ」のセットアップは、高速で最新のウェブアプリと、関心事のクリーンな分離をもたらします。欠点としては、DevOpsコストが増え、機敏さが落ちることがあります。ほとんどのスタートアップは、高速さが明確に求められたり複雑なクエリセマンティクスを持つものを作る場合を除き、直接RPC方式から始めることをお勧めします。市場投入までの時間が鍵となります。後で中堅エンジニアを雇ってインデックスダンジョンに放り込むこともできます。

15) フィニ。もしより良いセットアップを見つけた方がいれば教えてください。これらは私が試したすべての方法です。最近はエンタープライズのセットアップで遊ぶのがかなり楽しんでいます。