솔라나의 로컬 수수료 시장은 특정 프로그램이나 writable account를 동시에 수정하려는 거래들이 같은 자원을 두고 경쟁할 때 수수료 압력이 그 경합 영역에 집중되는 구조를 뜻합니다. 네트워크 전체가 혼잡하지 않아도 인기 민팅 계정이나 AMM 풀을 쓰는 거래는 높은 우선순위 수수료를 요구받을 수 있고, 다른 계정을 쓰는 단순 전송은 상대적으로 덜 혼잡할 수 있습니다. getRecentPrioritizationFees에 관련 writable account 목록을 넣어 최근 관측치를 조회하되, 반환값은 확정 견적이 아니며 CU limit·가격·계정 집합·시점이 맞아야 실제 비용을 계산할 수 있습니다.
혼잡은 체인 전체보다 특정 writable account에 모일 수 있다
Solana 거래는 실행 전에 읽을 account와 쓸 account를 메시지에 선언합니다. 여러 거래가 같은 account를 읽기만 하면 병렬 처리 여지가 있지만, 같은 account를 쓰려 하면 동시에 상태를 바꿀 수 없어 충돌합니다. 인기 AMM 풀, 민팅 상태, 오더북처럼 많은 거래가 같은 writable account를 요구하면 그 주변에 로컬 경합이 생깁니다.
따라서 ‘솔라나 가스비’라는 한 숫자로 모든 거래의 포함 비용을 표현하기 어렵습니다. 동일 시각에도 혼잡한 풀을 건드리는 스왑과 서로 겹치지 않는 계정 사이 전송은 scheduler가 보는 충돌 관계가 다릅니다. 토큰 티커가 같아도 route가 다르면 writable account 집합이 달라질 수 있습니다.
로컬 수수료 시장의 위치는 토큰 이름이 아니라 동시에 쓰려는 계정 집합으로 찾는다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 혼잡은 체인 전체보다 특정 writable account에 모일 수 있다
Solana 거래는 실행 전에 읽을 account와 쓸 account를 메시지에 선언합니다.
- write lock은 실행 순서를 제한하고 scheduler cost에도 들어간다
공식 Compute Budget 문서는 scheduler의 사전 실행 비용이 signature, write lock, instruction data, program execution, loaded account data 비용으로 구성된다고 설명합니다.
- 계정별 최근 수수료 조회는 질문을 좁히는 도구다
Solana 공식 RPC 문서는 getRecentPrioritizationFees가 recent prioritization fees를 반환하며 선택적으로 account public key 배열을 받는다고 명시합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
write lock은 실행 순서를 제한하고 scheduler cost에도 들어간다
공식 Compute Budget 문서는 scheduler의 사전 실행 비용이 signature, write lock, instruction data, program execution, loaded account data 비용으로 구성된다고 설명합니다. writable account 하나마다 write lock cost가 추가되고, 블록에는 writable account 자원 한도도 있습니다. 이 값들은 실제 프로그램 실행 CU와 별도의 사전 스케줄링 판단에 쓰입니다.
write lock이 있다고 거래가 실패하는 것은 아닙니다. scheduler가 충돌 거래를 다른 순서나 배치에 놓을 수 있습니다. 하지만 특정 account의 블록 한도와 남은 slot 시간이 부족하면 높은 수수료를 붙여도 포함되지 않을 수 있습니다. 수수료는 기회를 높이는 입력이지 계정 경합을 제거하는 열쇠가 아닙니다.
| 값 | 무엇을 나타내나 | 주의할 점 |
|---|---|---|
| writable accounts | 거래가 상태를 바꿀 계정 집합 | route 변경 시 집합도 바뀔 수 있음 |
| write lock cost | scheduler가 추정하는 계정 잠금 비용 | 프로그램의 실제 실행 CU와 별도 |
| CU limit | 거래가 요청한 최대 연산량 | 과다 요청하면 fee와 priority 효율이 달라짐 |
| CU price | 요청 CU당 micro-lamport 가격 | legacy·v0 산식이며 v1 형식은 총액 방식 |
| recent fee sample | 최근 slot에서 관측된 우선순위 수수료 | 미래 포함을 보장하는 견적이 아님 |
계정별 최근 수수료 조회는 질문을 좁히는 도구다
Solana 공식 RPC 문서는 getRecentPrioritizationFees가 recent prioritization fees를 반환하며 선택적으로 account public key 배열을 받는다고 명시합니다. 빈 배열로 조회한 값과 실제 거래의 writable account를 넣은 값은 질문이 다릅니다. 후자는 해당 계정 집합을 잠그는 거래 경쟁을 더 가깝게 반영하려는 조회입니다.
조회 대상에는 프로그램 ID를 무조건 넣는 방식보다 실제 메시지에서 writable로 선언되는 계정을 확인해야 합니다. read-only account는 병렬 읽기가 가능하므로 쓰기 경합과 성격이 다릅니다. 여러 provider의 자체 fee API는 percentile·추천 산식이 다를 수 있으므로 공식 RPC 원시값과 공급자 가공값을 같은 필드명으로 저장하지 않습니다.
- 거래를 먼저 구성하거나 시뮬레이션해 account metadata를 확보한다
- writable=true인 account만 별도 목록으로 추출한다
- 그 목록으로 최근 prioritization fee와 slot을 조회한다
- CU 사용량을 시뮬레이션하고 안전 여유를 둔 limit을 정한다
- 전송 뒤 실제 fee, consumed CU, 포함 slot을 예상치와 비교한다
우선순위 수수료의 단위와 반올림을 검산한다
공식 Fee Structure에 따르면 legacy·v0 형식의 prioritization fee는 ceil(CU price×CU limit÷1,000,000) lamports입니다. CU price 단위가 micro-lamports per CU이기 때문에 1,000,000으로 나누며 lamport 단위에서 올림합니다. 수수료는 실제 소비 CU가 아니라 요청 limit을 기준으로 계산됩니다.
가정으로 limit 200,000 CU, price 5,000 micro-lamports/CU를 요청하면 200,000×5,000÷1,000,000=1,000 lamports입니다. 실제 120,000 CU만 써도 우선순위 수수료 산식의 limit은 200,000입니다. 단, 공식 문서는 v1 거래 형식이 message config에 lamport 총액을 직접 넣는다고 구분하므로 형식 확인 없이 이 곱셈식을 적용하면 안 됩니다.
높은 fee만으로 포함을 보장할 수 없는 이유
공식 scheduler priority 산식은 reward를 estimated cost+1로 나눈 비율에 1,000,000을 곱합니다. reward에는 validator가 받는 priority fee와 base fee 일부가 포함되고 cost에는 write lock과 요청 compute 자원이 들어갑니다. 따라서 fee 총액이 같아도 과도한 CU limit이나 많은 writable account 때문에 priority 비율이 달라질 수 있습니다.
또한 block의 전체 CU, writable account CU, vote CU 같은 별도 한도가 남습니다. 특정 account가 이미 해당 블록 자원을 많이 사용했다면 더 높은 fee가 물리적 한도를 늘리지 않습니다. recent fee는 경쟁의 과거 관측치이며 다음 leader의 큐, route, block 상태는 달라질 수 있습니다.
로컬 시장을 비교할 때 거래 모양을 고정한다
시간대별 fee를 비교하려면 동일한 instruction, writable account 집합, CU limit, transaction version을 유지해야 합니다. 스왑 route가 바뀌거나 address lookup 사용 여부가 달라지면 단순 fee 시계열이 아니라 서로 다른 거래를 비교하게 됩니다. 제공자 추천 fee의 percentile도 함께 기록합니다.
운영 대시보드에는 target accounts hash, quote time, sample slots, requested CU, CU price, 실제 landed slot을 남기는 것이 좋습니다. 이 기록은 ‘얼마를 내면 무조건 성공’이라는 매매 조언이 아니라 재시도와 비용 예산을 검증하는 자료입니다. 실패 거래도 base fee와 priority fee가 부과될 수 있으므로 status와 fee를 함께 대사합니다.
자주 묻는 질문
솔라나가 혼잡하면 모든 거래가 같은 우선순위 수수료를 내야 하나요?
아닙니다. 실제 경쟁은 겹치는 writable account와 블록 자원에 따라 달라질 수 있습니다. 같은 시각에도 거래 경로와 계정 집합이 다르면 fee 관측치가 달라집니다.
getRecentPrioritizationFees 반환값이 권장 수수료인가요?
최근 slot의 관측값입니다. account 목록과 표본 범위를 확인해야 하며 미래 leader가 거래를 포함한다는 보장은 아닙니다.
실제 사용 CU만큼만 우선순위 수수료를 내나요?
legacy·v0 거래의 공식 산식은 요청한 CU limit과 CU price를 곱합니다. 실제 사용량보다 limit이 크면 사용하지 않은 요청분도 fee 계산에 반영됩니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
