---
title: "Photon on Alchemy：壓縮後的 Solana 資料，標準 RPC"
description: "Photon／ZK Compression 的讀取方法現已可在 Alchemy 標準 Solana RPC URL 上執行——單一端點、具生產規模的延遲表現，從其他相容 Photon 的供應商遷移只需更換 URL。"
---

# Photon on Alchemy：壓縮後的 Solana 資料，標準 RPC

<ImageBlock
  src="https://media.alchemy.com/blog-photon.png"
  alt="Solana 標誌與 Solana Photon APIs 標籤並列,背景為淡藍紫色網格"
  width={3840}
  height={1800}
  priority
/>

對於在 Solana 上建構錢包、交易所、索引器和消費端應用的團隊來說，壓縮狀態是越來越常見的模式。高規模的 token-account 工作負載可以從 ZK compression 中獲得顯著的效益——而讀取這類資料需要用到 Photon methods，直到最近，這都意味著要另外架設一個 provider 或自行運行 indexer。

這就是為什麼我們將完整的 Photon / ZK Compression method 套件直接加入 Alchemy 的標準 Solana RPC endpoint。

## 為什麼壓縮在 Solana 上很重要

Solana 的帳戶模型速度很快，但將每一筆狀態直接寫在鏈上的成本很高，對於鑄造數百萬個 token、NFT 或忠誠度資產的高規模消費端應用來說尤其如此。ZK compression 改變了成本曲線，讓鏈上只保留一個精簡的加密承諾——狀態的一種「指紋」——再加上用來驗證更新的規則。而詳細的狀態，也就是錢包和應用實際想查詢的部分，則存放在鏈下。

這對發行方和鏈本身來說都是好事，但對客戶端來說未必如此。標準的 Solana RPC node 完全不知道什麼是壓縮的 token balance。如果沒有能監控壓縮程式活動並重建底層狀態的 indexer，壓縮資產對你的應用來說實際上是不可見的。

Photon 正是這樣的 indexer。它監控涉及壓縮協議的區塊和交易，將詳細狀態重建成可查詢的資料庫，並透過標準的 RPC method 介面公開這些資料。對於顯示餘額的錢包和驗證持有量的應用而言，Photon 就是讓壓縮資料變得可讀的關鍵。

Photon 已成為 Solana 上壓縮狀態讀取的通用介面。我們直接採用了它的 method 介面，因此從任何相容 Photon 的 provider 遷移過來，只需要改變 URL，不需要重寫程式碼。

## 運作方式

Photon 持續追蹤涉及壓縮程式的區塊和交易。每一個相關的指令——mint、transfer、burn、account update——都會根據鏈上承諾進行解碼，產生的狀態變化會套用到一個鏈下資料庫，這個資料庫反映的正是壓縮帳戶實際代表的內容。鏈上承諾仍然是唯一真實來源；索引只是它的一種確定性投影，隨時都可以從頭重建。

Photon methods 與所有其他 Solana call 位於同一個 Solana RPC endpoint 上。請求會根據 method 名稱在內部路由：標準的 JSON-RPC 會導向我們的 Solana node 叢集，Photon methods 則導向我們的 Photon 叢集。開發者可以透過同一個 URL 存取所有功能。

## 我們衡量的指標

在 Alchemy 上，Photon 讀取 methods 在美國和歐盟地區都表現最佳，並且在相同 call 上持續比其他 provider **快約 3 倍**：

- **`getCompressedTokenBalancesByOwner`** — 美國 **P50 8 ms / P95 12 ms / P99 20 ms**（相較於其他 provider 約 30 / 45 / 65 ms）；歐盟 **P50 16 ms / P99 53 ms**。
- **`getCompressedTokenBalancesByOwner` 在高負載帳戶上**（依大量壓縮 mint 集合排序的錢包）——美國 **P50 10 ms / P99 23 ms**，在尾端延遲上比其他實作**緊縮約 3 倍**。
- **`getCompressedTokenAccountsByOwner`** — 美國 **P50 10 ms / P99 25 ms**；歐盟 **P50 18 ms / P99 45 ms**。整體端對端比其他方案快約 3 倍。
- **`getValidityProof`** — 美國 **P50 130 ms / P99 200 ms**，**沒有出現數秒級的尾端延遲高峰**。我們觀察到其他 provider 在負載下，這個 method 的延遲會飆升到 **3 秒以上**——proof 生成是這個介面中最耗費資源的 call，一旦這裡的尾端延遲不穩定，就會明顯卡住錢包流程。

值得留意的是高負載帳戶的尾端延遲表現。擁有極大量壓縮 mint 集合的錢包，正是能夠揭露「支援 Photon」與「在生產規模下支援 Photon」之間差距的工作負載——而這正是這些差距最關鍵的地方。

## 開始使用

Photon methods 目前已在所有 Solana 方案中透過標準 Solana RPC endpoint 提供。如果你目前正在使用其他相容 Photon 的 provider，遷移只需要改變 URL。

- [閱讀文件](https://www.alchemy.com/docs/reference/solana-api-quickstart)
- [聯繫我們的團隊](https://www.alchemy.com/contact-sales)以取得客製化的基準測試、定價方案，或大規模應用的解決方案。
