P-Token: Solana의 차세대 대규모 효율성 혁신

소개

Solana가 빠르게 도입된 배경에는 토큰을 안전하고 간단하며 표준화된 방식으로 처리한다는 점이 있습니다. 하지만 이는 상대적으로 덜 주목받았습니다. 다른 많은 블록체인과 달리 Solana에서는 토큰을 생성할 때 커스텀 컨트랙트를 배포할 필요가 없습니다. 대신 모든 작업은 Solana Labs가 처음 배포하고 철저한 감사와 실전 검증을 거친 SPL token program(Tokenkeg이라고도 함)을 통해 실행됩니다. 이 방식 덕분에 토큰 발행, 소각, 전송과 같은 일반적인 작업이 매우 간단합니다. 예를 들어 CLI 명령 하나만으로 Solana 토큰을 배포할 수 있습니다.

SPL Token Program은 System program을 제외하면 Solana에서 가장 많이 사용되는 프로그램입니다. 지난 6개월 동안 SPL token program을 통해 새로 생성된 대체 가능 토큰은 주당 평균 20만~30만 개였습니다. 이는 주간 신규 SPL 토큰 생성량이 보통 1만 개 미만이었던 2년 전인 2023년 9월보다 20배 증가한 수치입니다. 전체적으로 2023년을 제외하면 Solana 출시 이후 매년 신규 토큰 발행량이 크게 늘었습니다. 아래 차트에서 이를 확인할 수 있습니다.

SPL 토큰 전송량의 증가세는 더욱 두드러집니다. 지난 3개월 동안 주간 전송 건수는 꾸준히 6억 5천만 건을 넘었으며, 7월 말에는 8억 6,780만 건으로 정점을 기록했습니다. 이는 2023년 8월 초에 기록한 주간 최저치 4,940만 건보다 17.5배 증가한 수치입니다.

P-Token의 등장

P-token은 현재 SPL Token 프로그램을 대체할 수 있도록 컴퓨트 효율을 최적화한 드롭인 솔루션입니다. Anza 팀이 지난 3월 SIMD-0266: 효율적인 토큰 프로그램을 통해 처음 제안했습니다. 기존 SPL 토큰과 완전한 하위 호환성을 유지하면서 컴퓨트 유닛(CU) 사용량을 크게 줄입니다. 

P-token은 SPL Token 프로그램과 완전히 동일한 명령어 세트와 계정 레이아웃을 사용하므로 직접 교체할 수 있습니다. 즉, p-token은 새로운 토큰 표준이 아닙니다. 클라이언트 코드는 이전과 동일하게 작동합니다. 애플리케이션이나 사용자가 별도로 조정하지 않아도 전환만으로 효율성을 크게 높일 수 있습니다.

P-token 도입 추진은 프로그램과 프레임워크의 효율을 높이려는 Solana의 광범위한 방향과 맞닿아 있습니다. 이는 네트워크 용량 확대 작업을 보완하며, 대표적인 예로 2025년 사용 가능한 블록 공간을 두 배로 늘리는 목표가 있습니다.

최근 Solana에서 거둔 독점 AMM의 성공은 낮은 컴퓨트 비용의 영향과 고효율 프로그램의 이점을 보여줍니다. 예를 들어 HumidiFi 같은 플랫폼의 오라클 업데이트는 단 143 CU까지 고도로 최적화되었습니다. BlueShift가 개발한 새로운 오픈 소스 오라클 프로그램 Doppler는 비용을 단 21 CU까지 더 낮춥니다.

Pinocchio

P-token의 “p”는 Anza가 개발한 Pinocchio를 뜻합니다. Pinocchio는 Solana 프로그램 작성을 위한 최적화된 고성능 무의존성 라이브러리입니다. 명령어와 계정 데이터를 처리할 때 제로 카피 타입을 광범위하게 사용하는 표준 solana-program crate를 대체합니다. 제로 카피를 사용하면 데이터를 읽거나 쓸 때 새로운 메모리 위치에 복제하지 않습니다. 대신 포인터를 통해 상태에 직접 접근합니다. 불필요한 메모리 작업을 피해서 컴퓨트 사용량을 크게 줄이고 런타임 오버헤드도 낮춥니다.

Pinocchio는 no_std이기도 합니다. Solana Virtual Machine(SVM)이 이미 런타임 환경을 제공하므로 Rust 표준 라이브러리나 힙 할당에 의존하지 않습니다. 실행 과정을 더욱 간소화하고 의존성을 줄여 더 가볍고 빠른 프로그램을 구현합니다.

효율성 향상

CU는 Solana 런타임의 실행 비용을 측정합니다. 두 정수의 덧셈이나 비트 연산 같은 가장 작은 작업은 1 CU를 사용합니다. 프로그램 한도는 명령어당 20만 CU, 트랜잭션당 140만 CU입니다.

P-Token은 표준 SPL 토큰 트랜잭션의 CU 사용량을 약 95% 줄여 획기적인 효율 향상을 제공합니다. 효율이 19배 높아지는 셈입니다. 실행 속도가 빨라져 사용자 경험이 더 매끄러워집니다. 확보된 컴퓨트 용량 덕분에 각 블록에 더 많은 트랜잭션을 담을 수 있어 네트워크 처리량도 직접 향상됩니다.

현재 Token program 명령어는 블록 전체 CU 사용량의 약 10%를 차지합니다. P-token이 비용을 현재 수준의 5%로 줄이면 이 비중은 10%에서 0.5%로 낮아집니다. 다른 트랜잭션이 사용할 수 있는 블록 용량이 9.5% 추가로 확보됩니다. 또한 p-token은 전체 CU 사용량과 크로스 프로그램 호출(CPI) 비용을 줄여 조합성을 개선하므로 다운스트림 프로그램에도 이점을 제공합니다.

아래 차트와 표는 현재 SPL Token 프로그램과 비교했을 때 p-token 명령어가 확보하는 CU 효율을 자세히 보여줍니다.

주로 `no_std` 덕분에 가능해진 또 다른 주요 최적화는 프로그램 바이너리 크기를 131KB에서 95KB로 줄인 것입니다.

추가 명령어

P-token은 기존 SPL token program에 없던 세 가지 새 명령어(`withdraw_excess_lamports`, `batch`, `unwrap_lamports`)를 token program에 추가할 것을 제안합니다.

초과 Lamport 인출

현재 SPL Token-2022 구현과 마찬가지로 `withdraw_excess_lamports`를 사용하면 발행 계정에 잘못 묶인 초과 SOL을 회수할 수 있습니다. 보통 사용자가 실수로 토큰 발행 계정에 lamport를 보냈을 때 발생합니다.

인출하려면 발행 권한자의 승인이 필요합니다. 표준 발행 계정은 지정된 서명자, 멀티시그 계정은 멀티시그의 승인을 받아야 합니다. 대부분의 SPL 토큰은 발행 권한이 취소된 상태입니다. 이 경우 발행 계정 자체를 서명 권한자로 사용하고 발행 계정의 비공개 키로 명령어에 서명해 승인할 수 있습니다.

모든 SPL 토큰 발행 계정 중 약 869,000개가 최소 임대료 면제 기준인 0.0014616 SOL보다 많은 SOL을 보유하고 있습니다. 이를 합치면 토큰 발행 계정에 묶인 SOL은 176,961.5개이며, 현재 가격으로 미화 3,600만 달러에 해당합니다. 토큰 발행 계정에 가장 많은 SOL이 묶인 자산은 주로 밈코인, 레거시 토큰, 주요 블루칩 자산입니다. 단일 토큰 발행 계정에 묶인 SOL이 가장 많은 사례는 밈코인인 BOOK OF MEME($BOME)로, 6,328 SOL이 들어 있습니다. P-token이 도입되면 이러한 잔액을 잠재적으로 해제할 수 있어 토큰 개발팀이 뜻밖의 수익을 얻을 수 있습니다.

배치

두 번째 새 명령어는 `batch`이며, p-token 프로그램과의 CPI 상호작용을 간소화합니다. `batch`를 사용하면 token program을 여러 번 호출하는 대신 하나의 호출 안에서 가변 개수의 토큰 명령어를 실행할 수 있습니다. 따라서 기본 CPI 비용 1,000유닛이 각 명령어마다 발생하지 않고 한 번만 발생합니다.

그 결과 하나의 명령어에서 여러 토큰 CPI를 사용하는 프로토콜의 컴퓨트 사용량이 크게 줄어듭니다. 이는 Solana DeFi 전반에서 흔히 볼 수 있는 패턴입니다. 예를 들어 AMM은 스왑 한 번에 두 차례 전송을 수행할 수 있고, 유동성 풀 예치에는 전송과 발행이 모두 포함될 수 있습니다. 프로그램은 이러한 상황에서 `batch`를 사용해 CU를 크게 절감할 수 있습니다.

Lamport 언래핑

`unwrap_lamports` 명령어는 최근 별도의 PR에서 추가되었으며, 대상 계정으로 lamport를 직접 전송할 수 있게 해 임시 네이티브 토큰 계정을 만들 필요를 없앱니다.

이전에는 래핑된 SOL 계정에서 lamport를 언래핑하려면 수신자의 연결 토큰 계정(ATA)을 생성한 후 닫아야 했습니다. 이번 업데이트로 네이티브 SOL 계정에서 lamport를 직접 전송할 수 있어 절차가 간소화됩니다.

전송 명령어를 위한 빠른 경로

메인넷의 token program 사용량을 분석한 결과, 전송 명령어에 사용이 크게 집중되어 있으며 전체 활동의 거의 절반을 차지했습니다. 가장 자주 사용되는 명령어 5개는 다음과 같습니다.

• transfer_checked(36.33%)
• transfer(13.22%)
• close_account(12.23%)
• initialize_account3(9.98%)
• initialize_immutable_owner(9.78%)

이 사용 패턴은 p-token을 전송에 맞게 추가로 최적화하고 CU 사용량을 줄일 기회를 보여줍니다. 이 최적화 작업의 상당 부분은 Temporal의 Cavey가 기여했습니다. 접근 방식을 자세히 알아보려면 그의 X 라이브 스트리밍을 확인하세요.

이러한 개선을 위해 p-token은 전송 명령어의 빠른 경로를 지원하는 커스텀 엔트리포인트를 도입하고, `sync_native`와 `initialize_immutable_owner`의 우선순위를 높이도록 프로세서를 업데이트합니다. 이 변경 사항들은 관측된 사용 패턴에 맞춰 CU 효율을 크게 개선합니다.

로깅

P-token 도입과 함께 현재 로깅 동작을 유지할지 여부가 미해결 과제로 남아 있습니다. 최신 제안 버전은 로그 제거를 권장합니다. Solana에서 로그는 프로그램의 디버깅, 모니터링, 이벤트 데이터를 추출하는 주요 수단입니다. 기존 token program의 로그는 최소한으로 구성되어 실행 중인 명령어 이름만 출력합니다. 예시는 다음과 같습니다.

Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [1],
Program log: Instruction: TransferChecked,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA consumed 6281 of 7738 compute units,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA success

하지만 사소해 보이는 이 로그 줄 `Instruction: <name>`에는 약 103 컴퓨트 유닛이 필요합니다. 실제로 이 오버헤드는 명령어 자체와 거의 같은 수준의 컴퓨트를 사용할 수 있습니다. 예를 들어 단순 전송에 필요한 전체 컴퓨트 중 약 40%를 로깅이 차지합니다.

이러한 로그는 비용이 들 뿐 아니라 항상 신뢰할 수 있는 것도 아닙니다. 로그가 잘리거나 로그 인젝션을 통해 조작될 수 있어 다운스트림 파서가 잘못 해석할 위험이 있습니다. 반면 로그를 완전히 제거하면 현재 로그에 의존하는 개발자와 애플리케이션의 워크플로가 중단될 수 있습니다.

로그가 제거되면 프로그램 동작의 가시성을 제공하기 위해 팀이 IDL을 공개하는 일이 더욱 중요해집니다. 예를 들어 Anchor는 명시적으로 비활성화하지 않는 한 모든 새 프로그램의 IDL을 기본으로 게시하도록 적용하고 있습니다.

감사

완전한 하위 호환성과 보안을 보장하기 위한 p-token 프로그램 감사가 이미 진행 중입니다. P-token이 도입되려면 현재 Token program과 완전히 동일한 명령어와 계정 레이아웃을 엄격하게 준수하고 동작도 정확히 재현해야 합니다. 어떤 차이도 위험을 초래할 수 있으므로 광범위한 테스트와 독립 감사를 통해 이를 검증하고 있습니다.

감사 기관 Neodyme는 동등성 테스트를 수행했습니다. 최근 몇 달 동안의 모든 메인넷 트랜잭션을 기존 token program과 p-token으로 각각 한 번씩, 총 두 번 재실행했습니다. 결과는 출력이 동일함을 확인하는 동시에 CU가 크게 절감됨을 보여주었습니다.

분석에 따르면 2025년 8월 3일부터 8월 11일까지 p-token을 사용했다면 로깅 활성화 시 8조 9천억 CU, 로깅 비활성화 시 9조 1,400억 CU의 오버헤드를 줄일 수 있었습니다. 이는 전체 블록 공간 사용량의 각각 12.0%와 12.3%에 해당합니다.

P-token은 현재 Zellic의 두 번째 감사와 Runtime Verification의 정형 검증을 받고 있습니다.

출시 절차

P-token은 단계적으로 출시될 예정입니다. 먼저 감사, 퍼징, 정형 검증을 완료합니다. 이후 p-token 도입을 위한 검증인 거버넌스 투표와 SIMD 266의 공식 승인이 진행됩니다. 그다음 p-token 기능을 클러스터에 배포하고 기능 게이트 뒤에 배치합니다.

프로그램은 먼저 지정된 계정(ptokN…UkkZ2)에 배포됩니다. 에포크 경계에서 기능 게이트가 활성화되면 모든 검증인의 런타임이 Upgradable Loader v3를 사용해 기존 token program(Tokenkeg…VQ5DA)을 새 구현으로 교체합니다.

다른 방법으로는 p-token 프로그램을 새 주소에 배포하고 사용자와 애플리케이션이 직접 마이그레이션하도록 할 수 있습니다. 하지만 많은 사용자가 전환을 망설이거나 늦게 전환해 도입을 방해하고 전반적인 이점을 줄일 가능성이 크므로 선호되는 방식은 아닙니다.

경제적 영향

P-token 도입은 Solana의 전체 용량을 크게 확장해 각 블록에 더 많은 트랜잭션을 담을 수 있게 할 여러 개선 사항 중 하나입니다. 그 밖의 주요 업그레이드로는 블록 공간을 1억 CU로 두 배 확대하는 작업과 계정당 CU 한도를 고정된 1,200만 CU에서 블록의 40%로 높이는 작업이 있습니다.

현재 단일 계정의 한도는 블록당 1,200만 CU입니다. 아래 Anza 차트에서 볼 수 있듯이 각 블록에서 경합이 가장 심한 계정은 이 한도에 자주 도달합니다. P-token만으로도 계정이 이 한도에 도달하기 어려워지므로 핫 스테이트의 병목 현상이 발생하는 빈도를 줄일 수 있습니다.

오늘날 거의 모든 트랜잭션에는 검증인이 해당 트랜잭션을 블록에 포함하도록 유도하기 위한 우선순위 수수료나 Jito 팁이 들어갑니다. 우선순위는 CU당 수수료로 결정되므로 더 적은 CU를 사용하는 p-token 트랜잭션은 다른 조건이 같다면 동일한 수수료나 팁으로 더 높은 우선순위를 받아야 합니다. 다만 모든 SPL 토큰 트랜잭션이 p-token 업그레이드의 혜택을 받으므로 트랜잭션 우선순위에 미칠 전반적인 영향은 지켜봐야 합니다.

결론

거버넌스 투표를 통과한다면 p-token 도입은 Solana의 효율성과 확장성을 개선하는 중대한 진전이 될 것입니다. 컴퓨트 사용량을 대폭 줄이고 CPI 상호작용을 간소화해 네트워크에서 가장 많이 사용되는 프로그램의 기반을 강화하는 동시에 전체 블록 용량을 확장합니다. 성공한다면 p-token은 Associated Token Account(ATA) 프로그램과 System program 등 널리 사용되는 다른 프로그램의 Pinocchio 최적화 버전을 개발하는 청사진이 될 수 있습니다. 더 빠르고 효율적인 런타임으로 나아갈 길을 열 것입니다.

추가 자료

• p-token 저장소 - GitHub
• Pinocchio 저장소 - GitHub
• Solana Program Library(SPL) - GitHub
• p-Token SOL 절감액 계산기 - SendAI