legacy와 v0 거래의 우선순위 수수료는 요청한 CU limit에 CU price를 곱하고 1,000,000으로 나눠 올림한 lamport입니다. 실제 소비 CU가 더 적어도 요청 한도를 기준으로 냅니다. 그러므로 먼저 거래를 시뮬레이션해 소비량을 측정하고 적정 여유를 더한 뒤 가격을 정해야 합니다. v1 거래는 메시지 config에 총 priority fee를 직접 넣는 별도 방식이므로 형식을 확인해야 합니다.
세 숫자를 먼저 분리한다
Compute unit은 프로그램 실행 자원을 재는 단위입니다. CU limit은 거래가 소비할 수 있는 최대치이고, CU price는 legacy·v0 메시지에서 요청 CU 한 단위에 붙이는 micro-lamport 가격입니다. consumed CU는 실행 뒤 실제로 쓴 양입니다. 한도가 300,000이라고 300,000을 반드시 쓰는 것도 아니고, 가격이 높다고 프로그램이 더 많은 연산을 허용받는 것도 아닙니다.
공식 문서는 명시적 limit이 없을 때 instruction 유형별 기본값을 합산하고 transaction 최대치로 제한한다고 설명합니다. 이 기본값은 편리하지만 실제 로직보다 클 수 있습니다. 한도가 부족하면 실행이 실패하고, 지나치게 크면 legacy·v0의 priority fee 계산에서 쓰지 않은 여유까지 지불합니다. 한도와 가격은 각각 성공 여유와 포함 경쟁을 다루는 서로 다른 손잡이입니다.
CU 한도는 계산할 권리의 상한이고, CU 가격은 그 요청을 앞세우기 위한 가격이다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 세 숫자를 먼저 분리한다
Compute unit은 프로그램 실행 자원을 재는 단위입니다.
- 산식은 요청 한도를 사용한다
legacy·v0 우선순위 수수료는 ceil(compute_unit_price × compute_unit_limit ÷ 1,000,000) lamports입니다.
- 시뮬레이션은 한도 추정의 출발점이다
공식 안내는 transaction을 시뮬레이션해 CU 소비량을 측정하고 안전 여유를 더하는 절차를 제시합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
산식은 요청 한도를 사용한다
legacy·v0 우선순위 수수료는 ceil(compute_unit_price × compute_unit_limit ÷ 1,000,000) lamports입니다. 가정 예시로 limit 250,000 CU, price 4,000 micro-lamports/CU라면 곱은 1,000,000,000 micro-lamports이고 결과는 1,000 lamports입니다. 실제 180,000 CU만 써도 계산 기준은 250,000입니다.
같은 가격에서 limit을 400,000으로 올리면 1,600 lamports가 됩니다. 실행 안정성에 필요하지 않은 150,000 CU가 600 lamports 차이를 만든 셈입니다. 반대로 limit을 실제 소비보다 낮추면 수수료 절감 전에 거래가 compute budget 초과로 실패할 수 있습니다. 실패 거래도 기본 수수료가 부과될 수 있으므로 단순 최저 한도 경쟁은 비용 최적화가 아닙니다.
| CU limit | CU price | priority fee |
|---|---|---|
| 200,000 | 1,000 μ-lamports | 200 lamports |
| 250,000 | 4,000 μ-lamports | 1,000 lamports |
| 400,000 | 4,000 μ-lamports | 1,600 lamports |
| 300,000 | 0 | 0 lamports |
시뮬레이션은 한도 추정의 출발점이다
공식 안내는 transaction을 시뮬레이션해 CU 소비량을 측정하고 안전 여유를 더하는 절차를 제시합니다. 예컨대 정상 경로에서 182,000 CU가 나왔다고 곧바로 182,001로 고정하면 계정 상태와 분기 변화에 취약합니다. 여러 입력과 상태를 표본화하고 상위 분위수를 본 뒤 서비스가 감당할 실패율에 맞춰 여유를 정해야 합니다.
시뮬레이션과 실제 실행 사이에 계정 상태가 바뀔 수 있으며 CPI 경로도 달라질 수 있습니다. 따라서 측정값, 설정 limit, 실제 consumed CU, 오류 코드를 함께 로그로 남깁니다. 지속적으로 여유가 크면 낮추고 특정 입력만 초과하면 프로그램 경로를 개선합니다. 가격을 올리기 전에 실패가 compute 초과인지 blockhash 만료인지 계정 충돌인지 구분해야 합니다.
- 대표 입력과 최악 경로를 시뮬레이션해 consumed CU 분포를 기록한다
- 측정치에 명시적 안전 여유를 더하되 근거와 재조정 시점을 남긴다
- limit×price 산식을 lamport 단위로 다시 계산하고 올림을 반영한다
- 전송 후 실제 CU·수수료·slot·오류를 저장해 다음 설정에 반영한다
우선순위는 보장권이 아니다
priority fee는 경쟁 거래보다 앞서 스케줄될 가능성을 높이지만 포함이나 성공을 보장하지 않습니다. 스케줄러는 보상과 추정 비용을 함께 보며, 블록과 writable account 자원 한도도 존재합니다. 같은 핫 계정을 쓰는 거래의 상태 의존성은 가격으로 제거되지 않습니다. 프로그램 오류나 서명 오류도 높은 가격으로 고쳐지지 않습니다.
RPC의 최근 수수료 자료를 사용할 때도 어떤 writable 계정 집합과 시간 창을 반영하는지 확인합니다. 전역 중앙값을 특정 민팅 계정의 혼잡에 그대로 적용하면 부족하거나 과도할 수 있습니다. 사용자에게는 base fee와 optional priority fee, 실패 시 부과 가능성을 분리해 보여 주는 편이 정확합니다.
v1 형식은 별도 규칙으로 읽는다
확인일 현재 Solana 공식 문서는 v1 transaction이 모든 클러스터에서 활성화됐고 resource limit을 message config에 담는다고 설명합니다. 이 형식에서는 ComputeBudget instruction이 설정 수단이 아니며 no-op으로 실행되고, priority fee는 price×limit이 아니라 절대 lamport 총액입니다. SDK 함수와 메시지 버전을 확인하지 않으면 같은 이름의 설정을 다른 형식에 적용할 수 있습니다.
따라서 계산기는 먼저 message version을 입력받아야 합니다. legacy·v0이면 price와 limit을 곱하고, v1이면 config의 총액을 읽습니다. 문서의 기존 예제를 현재 모든 거래에 일반화하지 말고 실제 직렬화 형식과 클러스터 지원 상태를 확인해야 합니다. 이 경계를 지키면 과다 한도와 단위 변환 오류를 동시에 줄일 수 있습니다.
자주 묻는 질문
실제 사용한 CU만큼만 우선순위 수수료를 내나요?
legacy·v0에서는 아닙니다. 실제 사용량이 아니라 요청한 CU limit을 기준으로 계산합니다.
CU price를 높이면 compute limit도 늘어나나요?
아닙니다. 가격과 실행 상한은 별도 설정이며 limit이 부족하면 가격과 무관하게 실패할 수 있습니다.
v1 거래도 SetComputeUnitPrice를 쓰나요?
공식 문서 기준 v1은 메시지 config에 절대 lamport 총액을 설정하며 ComputeBudget instruction 방식과 다릅니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
