Photon on Alchemy: 압축된 Solana 데이터, 표준 RPC

작성자: Alchemy

마지막 업데이트: 2026년 5월 14일3분 읽기

부드러운 파란색과 보라색 격자 배경 위에 Solana 로고와 Solana Photon APIs 라벨

Solana 위에서 지갑, 거래소, 인덱서, 컨슈머 앱을 구축하는 팀들에게 압축 상태(compressed state)는 점점 더 흔한 패턴이 되고 있습니다. 대규모 토큰 계정 워크로드는 ZK 압축으로부터 상당한 이점을 얻을 수 있는데, 해당 데이터를 읽으려면 Photon 메서드가 필요했고, 최근까지 이는 별도의 프로바이더를 구축하거나 자체 인덱서를 운영해야 한다는 것을 의미했습니다.

그래서 저희는 Photon / ZK Compression 메서드 전체를 Alchemy의 표준 Solana RPC 엔드포인트에 직접 추가했습니다.

Solana에서 압축이 중요한 이유

Solana의 계정 모델은 빠르지만, 모든 상태 데이터를 온체인에 직접 기록하는 것은 비용이 많이 듭니다. 특히 수백만 개의 토큰, NFT, 또는 로열티 자산을 발행하는 대규모 컨슈머 앱의 경우 더욱 그렇습니다. ZK 압축은 이 비용 구조를 뒤집어, 온체인에는 상태의 "지문"에 해당하는 압축된 암호학적 커밋먼트와 그 업데이트를 검증하기 위한 규칙만 남도록 합니다. 지갑과 앱이 실제로 조회하고자 하는 세부 상태는 오프체인에 존재합니다.

이는 발행자와 체인 입장에서는 좋은 일이지만, 클라이언트 입장에서는 반드시 그렇지만은 않습니다. 표준 Solana RPC 노드는 압축된 토큰 잔액이 무엇인지 알지 못합니다. 압축 프로그램 활동을 감시하고 기저 상태를 재구성하는 인덱서가 없다면, 압축된 자산은 사실상 앱에서 보이지 않게 됩니다.

Photon이 바로 그 인덱서입니다. 압축 프로토콜과 관련된 블록과 트랜잭션을 감시하고, 세부 상태를 조회 가능한 데이터베이스로 재구성하며, 이를 표준 RPC 메서드 형태로 노출합니다. 잔액을 표시하는 지갑과 보유 자산을 검증하는 앱 입장에서, Photon은 압축 데이터를 읽을 수 있게 만들어주는 역할을 합니다.

Photon은 Solana에서 압축 상태 읽기를 위한 공통 인터페이스로 자리 잡았습니다. 저희는 그 메서드 형태를 그대로 채택했기 때문에, Photon 호환 프로바이더로부터의 마이그레이션은 재작성이 아니라 URL 변경만으로 가능합니다.

작동 방식

Photon은 압축 프로그램과 관련된 블록과 트랜잭션을 지속적으로 추적합니다. 민팅, 전송, 소각, 계정 업데이트 등 관련된 모든 명령어는 온체인 커밋먼트를 기준으로 디코딩되며, 그 결과로 발생하는 상태 변경은 압축된 계정이 실제로 나타내는 바를 반영하는 오프체인 데이터베이스에 적용됩니다. 온체인 커밋먼트는 여전히 신뢰할 수 있는 원천(source of truth)으로 남아 있으며, 인덱스는 이를 결정론적으로 투영한 것으로서 언제든 처음부터 재구성할 수 있습니다.

Photon 메서드는 다른 모든 Solana 호출과 동일한 Solana RPC 엔드포인트에 존재합니다. 요청은 메서드 이름에 따라 내부적으로 라우팅됩니다. 표준 JSON-RPC는 저희 Solana 노드 플릿으로, Photon 메서드는 저희 Photon 플릿으로 전달됩니다. 개발자는 하나의 URL을 통해 모든 것에 접근할 수 있습니다.

측정 결과

Alchemy의 Photon 읽기 메서드는 미국과 유럽 지역 모두에서 가장 뛰어난 성능을 보이며, 동일한 호출에서 다른 프로바이더보다 약 3배 더 빠르게 일관되게 작동합니다:

getCompressedTokenBalancesByOwner — 미국에서 P50 8 ms / P95 12 ms / P99 20 ms (다른 프로바이더는 약 30 / 45 / 65 ms); 유럽에서 P50 16 ms / P99 53 ms.
getCompressedTokenBalancesByOwner 대형 계정 기준 (압축 민트 세트가 큰 지갑 기준 정렬) — 미국에서 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, 수 초 단위의 테일 스파이크 없음. 다른 프로바이더는 부하 상황에서 이 메서드에서 3초 이상까지 스파이크가 발생하는 것으로 관찰되었습니다. 증명 생성은 이 메서드 세트 중 가장 무거운 호출이며, 여기서 테일이 불안정하면 지갑 흐름이 눈에 띄게 멈추게 됩니다.