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

最後更新：2026年5月14日2 分鐘閱讀

Solana 標誌與 Solana Photon APIs 標籤並列,背景為淡藍紫色網格

對於在 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，一旦這裡的尾端延遲不穩定，就會明顯卡住錢包流程。