---
title: "Alchemy上のPhoton:圧縮されたSolanaデータを標準RPCで"
description: "Photon / ZK Compressionの読み取りメソッドが、AlchemyのSolana標準RPC URL上で実行可能になりました。エンドポイントは1つ、レイテンシは本番運用レベルで、他のPhoton互換プロバイダーからの移行もURLの変更のみで完了します。"
---

# Alchemy上のPhoton:圧縮されたSolanaデータを標準RPCで

<ImageBlock
  src="https://media.alchemy.com/blog-photon.png"
  alt="柔らかい青紫のグリッド背景に、Solanaロゴと「Solana Photon APIs」のラベル"
  width={3840}
  height={1800}
  priority
/>

Solana上でウォレット、取引所、インデクサー、コンシューマーアプリを構築するチームにとって、圧縮ステートは今や一般的なパターンになりつつあります。大規模なトークンアカウントのワークロードはZK Compressionの恩恵を大きく受けられますが、そのデータを読み取るにはPhotonメソッドが必要であり、これまでは別のプロバイダーを立てるか、自前でインデクサーを運用する必要がありました。

そこで私たちは、Photon / ZK Compressionのメソッド一式をそのままAlchemyの標準SolanaのRPCエンドポイントに追加しました。

## Solanaにおいて圧縮が重要な理由

Solanaのアカウントモデルは高速ですが、あらゆるステートをオンチェーンに直接書き込むのはコストがかかります。特に、何百万ものトークンやNFT、ロイヤリティ資産をミントする大規模なコンシューマーアプリにとっては顕著です。ZK Compressionはこのコスト構造を転換し、オンチェーンにはステートの「フィンガープリント」となるコンパクトな暗号コミットメントと、それに対する更新を検証するルールのみが存在するようにします。詳細なステート、つまりウォレットやアプリが実際にクエリしたい部分は、オフチェーンに置かれます。

これは発行者にとってもチェーンにとっても好都合ですが、クライアントにとっては必ずしもそうとは限りません。標準のSolana RPCノードは、圧縮トークン残高が何であるかを認識しません。圧縮プログラムのアクティビティを監視し、背後にあるステートを再構築するインデクサーがなければ、圧縮アセットはアプリからは実質的に見えない存在になります。

Photonはそのインデクサーです。圧縮プロトコルに関わるブロックとトランザクションを監視し、詳細なステートをクエリ可能なデータベースへと再構築した上で、標準的なRPCメソッドのインターフェースとして公開します。残高を表示するウォレットや保有資産を検証するアプリにとって、Photonは圧縮データを読み取れるようにする存在です。

Photonは、Solanaにおける圧縮ステート読み取りの共通インターフェースとして定着しています。私たちはそのメソッドのインターフェースをそのまま採用したため、Photon互換の他プロバイダーからの移行はURLの変更のみで済み、書き直しは不要です。

## 仕組み

Photonは圧縮プログラムに関わるブロックとトランザクションを継続的に追跡します。ミント、転送、バーン、アカウント更新など、関連するすべての命令はオンチェーンのコミットメントと照合してデコードされ、その結果生じるステートの変化は、圧縮アカウントが実際に表すものを反映するオフチェーンデータベースに適用されます。オンチェーンのコミットメントは信頼できる情報源であり続け、インデックスはそこから決定的に導かれる射影であり、いつでもゼロから再構築可能です。

Photonのメソッドは、他のすべてのSolana呼び出しと同じSolana RPCエンドポイント上にあります。リクエストはメソッド名に基づいて内部でルーティングされます。標準のJSON-RPCは当社のSolanaノード群に、Photonメソッドは当社のPhoton群に届きます。開発者は1つのURLからすべてにアクセスできます。

## 計測している内容

Alchemy上のPhoton読み取りメソッドは、米国・EU両リージョンで最も高いパフォーマンスを示しており、同一の呼び出しにおいて他プロバイダーより一貫して**約3倍高速**です。

- **`getCompressedTokenBalancesByOwner`** — 米国で**P50 8 ms / P95 12 ms / P99 20 ms**（他プロバイダーでは約30 / 45 / 65 ms）、EUで**P50 16 ms / P99 53 ms**。
- **`getCompressedTokenBalancesByOwner`（重いアカウントにおいて）**（大量の圧縮ミントセットを持つウォレットでソート）— 米国で**P50 10 ms / P99 23 ms**、他プロバイダーの実装に比べて**テール部分で約3倍のばらつきの少なさ**。
- **`getCompressedTokenAccountsByOwner`** — 米国で**P50 10 ms / P99 25 ms**、EUで**P50 18 ms / P99 45 ms**。他プロバイダーと比較してエンドツーエンドで約3倍高速。
- **`getValidityProof`** — 米国で**P50 130 ms / P99 200 ms**、**数秒単位のテールスパイクは発生しません**。私たちが観測したところ、他プロバイダーは負荷がかかるとこのメソッドで**3秒以上**までスパイクすることがありました。証明生成はこのインターフェースの中で最も重い呼び出しであり、ここでのテールの不安定さはウォレットのフローを目に見える形で滞らせます。

注目すべきは、重いアカウントにおけるテール部分です。非常に大きな圧縮ミントセットを持つウォレットこそが、「Photonをサポートしている」ことと「本番規模でPhotonをサポートしている」ことの差を露呈させるワークロードであり、こうした差が最も重要になる場面です。

## 始め方

Photonのメソッドは、標準のSolana RPCエンドポイントを通じて、すべてのSolanaプランで本日より利用可能です。すでに他のPhoton互換プロバイダーを利用している場合、移行はURLの変更のみで完了します。

- [ドキュメントを読む](https://www.alchemy.com/docs/reference/solana-api-quickstart)
- カスタムベンチマーク、料金、大規模なソリューションについては[チームにお問い合わせください](https://www.alchemy.com/contact-sales)。
