솔라나 로컬 수수료 시장: 쓰기 잠금 계정이 혼잡 비용을 가르는 이유

솔라나의 로컬 수수료 시장은 특정 프로그램이나 쓰기 가능 계정(writable account)을 동시에 고치려는 거래들이 같은 자원을 두고 다툴 때, 수수료 압력이 그 경합 지점에 몰리는 구조를 말합니다. 네트워크 전체가 붐비지 않아도 인기 민팅 계정이나 자동 시장조성(AMM) 풀을 쓰는 거래는 높은 우선순위 수수료를 요구받을 수 있고, 다른 계정을 쓰는 단순 전송은 비교적 덜 붐빌 수 있습니다. getRecentPrioritizationFees에 관련 쓰기 계정 목록을 넣어 최근 관측치를 조회하되, 돌아온 값은 확정 견적이 아닙니다. 연산 단위(CU) 한도·가격·계정 집합·시점이 맞아야 실제 비용을 계산할 수 있습니다.

혼잡은 체인 전체보다 특정 쓰기 계정에 몰릴 수 있습니다

솔라나 거래는 실행 전에 읽을 계정과 쓸 계정을 메시지에 미리 밝힙니다. 여러 거래가 같은 계정을 읽기만 한다면 병렬로 처리할 여지가 있지만, 같은 계정에 쓰려고 하면 동시에 상태를 바꿀 수 없어 부딪힙니다. 인기 AMM 풀, 민팅 상태, 호가창처럼 많은 거래가 같은 쓰기 계정을 요구하면 그 주변에 로컬 경합이 생깁니다.

그래서 ‘솔라나 가스비’라는 숫자 하나로 모든 거래의 포함 비용을 나타내기는 어렵습니다. 같은 시각이라도 붐비는 풀을 건드리는 교환과, 서로 겹치지 않는 계정 사이의 전송은 스케줄러가 보는 충돌 관계가 다릅니다. 토큰 기호가 같아도 경로가 다르면 쓰기 계정 집합이 달라질 수 있습니다.

로컬 수수료 시장이 어디에 생기는지는 토큰 이름으로 찾지 않습니다. 동시에 쓰려는 계정 집합으로 찾습니다.

JOBCOIN 해설

그림으로 보기거래 요청부터 블록 확인까지

1. 01
   혼잡은 체인 전체보다 특정 쓰기 계정에 몰릴 수 있습니다

   솔라나 거래는 실행 전에 읽을 계정과 쓸 계정을 메시지에 미리 밝힙니다.

2. 02
   쓰기 잠금은 실행 순서를 묶고 스케줄러 비용에도 들어갑니다

   공식 연산 예산(Compute Budget) 문서는 스케줄러가 실행 전에 매기는 비용이 서명, 쓰기 잠금, 명령 데이터, 프로그램 실행, 불러온 계정 데이터 비용으로 이뤄진다고 설명합니다.

3. 03
   계정별 최근 수수료 조회는 질문을 좁히는 도구입니다

   솔라나 공식 RPC 문서는 getRecentPrioritizationFees가 최근 우선순위 수수료를 돌려주며, 계정 공개키 배열을 선택적으로 받는다고 밝힙니다.

설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

쓰기 잠금은 실행 순서를 묶고 스케줄러 비용에도 들어갑니다

공식 연산 예산(Compute Budget) 문서는 스케줄러가 실행 전에 매기는 비용이 서명, 쓰기 잠금, 명령 데이터, 프로그램 실행, 불러온 계정 데이터 비용으로 이뤄진다고 설명합니다. 쓰기 계정 하나마다 쓰기 잠금 비용이 붙고, 블록에는 쓰기 계정별 자원 한도도 있습니다. 이 값들은 실제 프로그램 실행 CU와 별개로, 실행 전 일정을 짜는 판단에 쓰입니다.

쓰기 잠금이 있다고 거래가 실패하지는 않습니다. 스케줄러가 충돌하는 거래를 다른 순서나 묶음에 넣을 수 있기 때문입니다. 하지만 특정 계정의 블록 한도와 남은 슬롯 시간이 모자라면 수수료를 높여도 블록에 들어가지 못할 수 있습니다. 수수료는 기회를 높이는 입력이지 계정 경합을 없애 주는 열쇠가 아닙니다.

계정별 최근 수수료 조회는 질문을 좁히는 도구입니다

솔라나 공식 RPC 문서는 getRecentPrioritizationFees가 최근 우선순위 수수료를 돌려주며, 계정 공개키 배열을 선택적으로 받는다고 밝힙니다. 빈 배열로 조회한 값과 실제 거래의 쓰기 계정을 넣고 조회한 값은 서로 다른 질문에 대한 답입니다. 뒤의 것은 해당 계정 집합을 잠그는 거래들의 경쟁을 더 가깝게 비추려는 조회입니다.

조회 대상에는 프로그램 ID를 무조건 넣기보다 실제 메시지에서 쓰기 가능으로 선언된 계정을 확인해 넣어야 합니다. 읽기 전용 계정은 병렬로 읽을 수 있어 쓰기 경합과 성격이 다릅니다. 여러 제공업체가 따로 내놓는 수수료 API는 백분위나 추천 산식이 다를 수 있으므로, 공식 RPC 원시값과 업체 가공값을 같은 필드 이름으로 저장하지 마세요.

• 거래를 먼저 구성하거나 모의 실행해 계정 메타데이터를 확보합니다
• writable=true인 계정만 따로 목록으로 뽑습니다
• 그 목록으로 최근 우선순위 수수료와 슬롯을 조회합니다
• CU 사용량을 모의 실행으로 재고, 안전 여유를 둔 한도를 정합니다
• 보낸 뒤 실제 수수료, 소비 CU, 포함 슬롯을 예상치와 비교합니다

우선순위 수수료의 단위와 반올림을 검산합니다

공식 수수료 구조 문서에 따르면 legacy·v0 형식의 우선순위 수수료는 ceil(CU price×CU limit÷1,000,000) 램포트입니다. CU 가격 단위가 CU당 마이크로 램포트이기 때문에 1,000,000으로 나누고, 램포트 단위에서 올림합니다. 수수료는 실제 소비 CU가 아니라 요청한 한도를 기준으로 계산됩니다.

가정 사례로 한도 200,000 CU, 가격 5,000 마이크로 램포트/CU를 요청하면 200,000×5,000÷1,000,000=1,000 램포트입니다. 실제로 120,000 CU만 써도 우선순위 수수료 산식에 들어가는 한도는 200,000입니다. 다만 공식 문서는 v1 거래 형식이 메시지 설정에 램포트 총액을 직접 넣는다고 구분하므로 형식 확인 없이 이 곱셈식을 적용하면 안 됩니다.

높은 수수료만으로 포함을 보장할 수 없는 이유

공식 스케줄러 우선순위 산식은 보상을 ‘추정 비용+1’로 나눈 비율에 1,000,000을 곱합니다. 보상에는 검증자가 받는 우선순위 수수료와 기본 수수료 일부가 들어가고, 비용에는 쓰기 잠금과 요청한 연산 자원이 들어갑니다. 그래서 수수료 총액이 같아도 CU 한도를 지나치게 잡았거나 쓰기 계정이 많으면 우선순위 비율이 달라질 수 있습니다.

블록에는 전체 CU, 쓰기 계정별 CU, 투표 CU 같은 별도 한도도 남아 있습니다. 특정 계정이 이미 해당 블록 자원을 많이 썼다면 수수료를 더 낸다고 물리적 한도가 늘어나지 않습니다. 최근 수수료는 지나간 경쟁의 관측치일 뿐이며, 다음 리더의 대기열과 경로, 블록 상태는 달라질 수 있습니다.

로컬 시장을 비교할 때는 거래 모양을 고정합니다

시간대별 수수료를 비교하려면 같은 명령, 같은 쓰기 계정 집합, 같은 CU 한도, 같은 거래 버전을 유지해야 합니다. 교환 경로가 바뀌거나 주소 조회 테이블 사용 여부가 달라지면, 수수료 시계열을 보는 게 아니라 서로 다른 거래를 비교하는 셈이 됩니다. 제공업체 추천 수수료의 백분위도 함께 적어 두세요.

운영 대시보드에는 대상 계정 해시, 견적 시각, 표본 슬롯, 요청 CU, CU 가격, 실제로 들어간 슬롯을 남기는 편이 좋습니다. 이 기록은 ‘얼마를 내면 무조건 성공’이라는 매매 조언이 아니라 재시도 전략과 비용 예산을 검증하는 자료입니다. 실패한 거래에도 기본 수수료와 우선순위 수수료가 붙을 수 있으니 상태와 수수료를 함께 맞춰 보세요.

자주 묻는 질문