수수료

이 페이지는 트랜잭션의 수수료를 설정하고, 배포나 호출의 비용을 추정하고, 검증자(validator)가 무엇을 보상으로 받는지 이해하는 데 사용합니다. 수수료는 RAND로 표시되는 하한입니다. 호출을 제외한 모든 동작은 고정 수수료를 냅니다. 체인 20에서 호출은 증명이 선언한 가스 한도와 바이트 수에 대해 수수료를 내며, 가격은 블록이 얼마나 찼는지에 따라 변동하고 상한에서 멈춥니다.

수수료 하한

수수료의 단위는 10⁻⁹ RAND입니다. 상수는 randprotocol_core::gas에 정의되어 있습니다.

수수료는 번들의 공개 워드이며 항상 RAND입니다. 히든 에셋 번들 게스트는 이를 RAND 그룹의 잔액 관계 in₂ + in₃ = out₂ + out₃ + fee + burn_r(슬롯 2–3)에 결합하므로, 어느 노트인지 드러내지 않고 숨겨진 노트에서 수수료가 지불됩니다. 토큰은 같은 번들의 슬롯 0–1을 통해 자체 관계 in₀ + in₁ = out₀ + out₁ + burn_a에 따라 이동합니다. 따라서 하나의 증명으로 토큰을 이동하고 RAND 수수료를 지불하며, 토큰은 보유하고 있으나 사용 가능한 RAND가 없는 지갑은 증명 생성 전에 거부됩니다.

브리지의 수수료가 소각에 부과되는 이유는 소각이 발신자가 RAND를 보유하고 있음이 확실한 유일한 브리지 트랜잭션이기 때문입니다. 입금자는 아직 RAND가 없으므로 입금은 기본 수수료만 지불합니다. 등록 수수료는 fee_floor의 일부가 아니라 원장의 사실이므로, 호출의 가스 또는 티어 부분이 증명이 디코딩된 뒤에 부과되는 것과 같은 방식으로 해당 동작 고유의 규칙(RegistrationFeeTooLow)으로 검사됩니다. 호출의 하한은 두 번 검사되는데, 호출이 선언하는 내용은 증명이 검증된 뒤에야 신뢰할 수 있기 때문입니다. 체인 20에서 검증 이전의 첫 번째 검사는 호출의 바이트와 선언된 한도 1을 기준으로 가격을 매기며(Invoke는 여기서 셀 수수료도 부담합니다), 두 번째 검사는 검증된 증명이 선언한 한도를 기준으로 가격을 매깁니다. gas 섹션이 없는 체인에서는 두 검사가 BUNDLE_BASE + CALL_BASE와 티어를 정확히 반영한 하한입니다.

추측하지 말고 노드에 물어보십시오.

rand fee bundle          # 0.001 RAND
rand fee deploy 256      # 0.0266 RAND
rand fee call 14 --gas 20479 --bytes 1350000   # 0.0041 RAND at chain 20's starting prices

→ {"method":"rand_estimateFee","params":[{"kind":"call","tier":14,"gas":20479,"bytes":1350000}]}
← "4103100"

이 응답은 시작 가격에서 1,000,000 + 100 × 20,479 + 800 × 1,319입니다. 노드는 질문을 받은 시점의 팁(tip)에 있는 가격으로 계산합니다. 체인 20에서는 JSON-RPC로 호출 사양의 gas 필드가 필수입니다(없으면 -32602). --gas 없는 rand fee call <tier>는 티어의 상한을 보내고, --bytes가 없으면 바이트에는 가격을 매기지 않습니다. invoke도 같은 방식으로 가격이 매겨지며, "kind":"invoke"와 "created_cells": c가 c개의 셀 수수료를 더합니다(셀 두 개를 가진 위 예시는 24103100이며, 2026-10-01에 체인 20에 질의한 값입니다). gas 섹션이 없던 체인 15에서 rand fee call 14는 0.0022 RAND로 응답했습니다.

지갑의 기본값은 하한과 정확히 같으며, 기본값에 여유분을 더하는 체인 20의 호출은 예외입니다(아래). rand send --fee <RAND>와 bond, call, bridge-mint, bridge-burn(기본값 0.01) 및 token 하위 명령의 --fee 플래그로 이를 높일 수 있습니다. 하한을 초과하는 금액은 팁입니다.

체인 18의 가스

2026-09-29부터 2026-10-01까지 가동된 체인 18은 최초의 가스 계량 체인이었고, 같은 빌드로 재제네시스된 체인 19는 동일한 gas 섹션을 가졌습니다. 체인 20(v0.6.8)은 이 섹션의 모든 규칙을 유지하면서 두 개의 가격 상한을 추가하고, 지불 대상이 되는 바이트에 대해서만 바이트 부하를 계산합니다(아래). gas 섹션이 없는 체인은 위 표의 티어 요율표를 따릅니다.

계량 대상. 1 가스는 zkVM cpu 테이블의 한 행입니다. 따라서 일반 명령어의 비용은 1입니다. 시스템 호출이 유일한 다른 비용입니다.

선언된 한도. 호출 증명은 이전보다 공개 값 하나를 더 담으며, 이것이 GAS_LIMIT입니다. 회로(제약 집합 8)는 실행에 사용된 가스가 이 값 이하임을 증명합니다. 정확한 가스는 비공개로 유지됩니다. 증명 자체 헤더의 상한을 넘는 한도는 검증자 키가 만들어지기 전에 거부됩니다.

gas_max = (2ᵗ − 1) + 2^(t−2) + 191 × (keccak rows / 32) + 63 × (sha256 rows / 64)

해시 테이블을 전혀 쓰지 않는 호출의 경우 티어 10에서 1,279, 티어 12에서 5,119, 티어 14에서 20,479입니다.

하한. 원장은 블록이 시작될 때 적용되는 가격으로 선언된 한도와 바이트에 대해 수수료를 부과합니다.

fee ≥ BUNDLE_BASE + gas_price × gas_limit + byte_price × ⌈bytes / 1024⌉

bytes는 호출 증명에 입력 봉투를 더한 것입니다. 티어 요율표와 무료 허용량은 이런 체인에는 적용되지 않습니다. 풀(pool)은 블록이 요구하는 것과 정확히 같은 수준을 요구하며, 더 싼 호출은 FeeTooLow로 거부합니다.

번들과 인가 증명은 고정된 한도를 선언합니다. 모든 번들 증명은 제네시스의 bundle_gas_limit인 20,479(티어 14의 상한)를 정확히 선언해야 하며, 그렇지 않으면 트랜잭션은 BundleGasLimit로 거부됩니다. 체인 20은 체인 17 이후의 모든 체인과 마찬가지로 분리 인가를 실행하므로, 모든 번들은 티어 10 인가 증명을 담으며 이 증명은 1,279를 선언해야 합니다(AuthGasLimit). 둘 다 요금이 아닙니다. 전송, 본딩, 배포는 여전히 위 표의 고정 하한을 지불합니다. 지갑이 두 값을 스스로 선언합니다.

가격은 변동합니다. 체인 20의 gas 섹션에는 dynamic 컨트롤러가 있으므로 gas_price와 byte_price는 상태 루트에 커밋되는 원장 상태입니다. 블록당 한 번, 트랜잭션이 처리된 뒤에 각 가격은 블록이 목표 대비 얼마나 찼는지에 따라 움직입니다.

price' = min(max_price, max(min_price, price + ⌊price × adjust_bps × (used − target) / (10,000 × target)⌋))

used는 목표의 두 배로 제한되므로, adjust_bps는 한 블록이 어느 방향으로든 만들 수 있는 가장 큰 변동입니다. max_price는 제네시스 상한이며, 체인 18과 19에는 없었습니다. byte_price는 블록의 지불 대상 바이트(아래)를 따르고, gas_price는 호출과 invoke가 선언한 한도의 합에 번들마다 20,479를 더한 값을 따릅니다.

목표치에 못 미치는 블록은 가격을 낮추므로, 한산한 체인에서는 가격이 하한에 머뭅니다. rand_getLimits는 팁 블록의 현재 gas_price와 byte_price를 gas_metering: "circuit", bundle_gas_limit, adjust_bps와 함께 제공하며, v0.6.8부터는 max_gas_price, max_byte_price, byte_load도 제공합니다(해당 필드가 없는 체인에서는 null). rand_status는 같은 두 가격을 gas_prices로 보고합니다.

상한과 paying 바이트 부하

둘 다 gas.dynamic의 제네시스 필드로, v0.6.8(audit v6, POOL-2)에서 신설되었으며 chain 20이 이를 처음으로 설정한 체인입니다. 이 필드들은 chain 18과 chain 19에 있던 결함을 바로잡습니다. 그 체인들에서는 byte_price가 모든 트랜잭션의 인코딩 길이에 따라 움직였지만, 이를 실제로 지불하는 것은 call뿐이었습니다. 전송 7건(각각 약 2.85 MB, 정액 수수료)이면 블록이 바이트 목표의 약 1.9배까지 차고 가격이 블록당 약 11% 오르는데, 상한이 없으므로 이런 블록 약 65개가 쌓이면 가격이 시작값의 1,000배에 이르고, 그러면 call 한 건의 비용은 약 0.004 RAND가 아니라 약 1 RAND가 됩니다.

• 상한. max_gas_price와 max_byte_price는 컨트롤러가 넘어 올리지 않는 가격입니다. 조정 폭은 동일하게 계산한 뒤 상한으로 잘라내므로(gas::next_price_capped), 상한에 도달한 가격은 블록이 연속해서 가득 차도 그대로 유지되고, 목표에 못 미치는 첫 블록에서 내려갑니다. 제네시스는 각 상한을 시작 가격 이상으로 설정해야 합니다. chain 20의 상한에서 위의 tier-14 call(20,479 gas, 1,319 KiB)의 하한 수수료는 0.3113 RAND이며, 이것이 하한 수수료가 도달할 수 있는 최댓값입니다.
• paying 바이트 부하. byte_load: "paying"에서는 블록의 bytes_used가 바이트 가격이 부과되는 바이트만 셉니다. 즉 각 Call과 Invoke의 증명에 입력 엔벨로프를 더한 크기(gas::call_bytes)만 세며, 전송, 본드, 소각은 전혀 세지 않습니다. 전송으로만 이루어진 블록은 바이트 가격을 움직이지 않습니다. Ledger::block_usage가 제안자와 복제본 양쪽에 대해 이 수치를 계산하므로 둘은 일치합니다.

paying 부하에서는 전송으로 가득 찬 블록이 call에 어떤 가격 신호도 주지 못하므로, 정직한 제안자는 call을 위한 공간도 따로 확보합니다. 이것은 유효성 규칙이 아니라 노드 정책입니다. call 또는 invoke가 풀에 있고 현재 하한 수수료를 지불하는 동안, 정액 수수료 트랜잭션은 첫 번째 패스에서 블록 바이트의 최대 4분의 3만 차지하고, call이 쓰고 남긴 마지막 4분의 1은 보류해 둔 전송으로 채웁니다(Mempool).

call에 지갑이 지불하는 금액

rand call은 먼저 에뮬레이터에서 프로그램을 실행하고 gas: <exact> (declaring <limit>, tier <t>)를 출력합니다. 기본값으로는 정확한 gas를 2^(tier − 2)의 배수로 올림해 선언하며, --gas-limit N은 정확한 값을 선언하고 --gas-limit max는 헤더의 상한을 선언합니다.

기본 수수료가 하한보다 높아지는 이유는 두 가지입니다.

• 증명은 상한 크기로 가격이 매겨집니다. chain 16(hardening_v6, chain 20 포함)부터 call 증명은 자신의 트랜잭션에 결합되므로, 수수료는 증명이 만들어지기 전에 확정됩니다. 지갑은 실제 증명 크기 대신 체인의 증명 상한인 4 MiB로 가격을 산정합니다(wallet::hardened_call_quote_bytes). 이 방식은 과다 지불로만 이어질 수 있습니다.
• 두 단계의 가격 변동 여유분. rand_getLimits는 확정된 헤드의 가격을 제공하는데 call은 두세 블록 뒤에 반영되므로, 기본값은 하한에 (1 + adjust_bps / 10,000)²를 곱하며, chain 20에서는 1.125²입니다.

2026-09-30에 chain 18에서 측정한 결과, 이 기본값으로 call 네 건의 비용은 각각 0.0057~0.0075 RAND였습니다(Example programs). --fee는 기본값을 덮어씁니다. 지갑은 제출하기 전에 실제 증명 크기로 수수료를 다시 산정하며, 하한 미만의 수수료는 거부합니다.

수수료의 행방

하한과 팁을 포함한 수수료 전액은 검증인 레지스터에 있는 **블록 제안자의 rewards**에 적립됩니다. 이 레지스터는 이 체인에서 금액을 평문으로 저장하는 유일한 곳이며, 예외가 하나 있습니다. tokens.burn_registration_fee가 설정된 제네시스(chain 15 이후의 모든 체인과 마찬가지로 chain 20)에서는 RegisterToken 또는 RegisterBridgedToken의 registration_fee가 소각되고 제안자는 fee − registration_fee를 가져가며, rand_getSupply는 이를 registration_fees_burned로 집계합니다. 이 플래그가 없던 chain 14에서는 제안자가 수수료 전액을 가졌습니다. 그 밖에는 소각되는 것이 없으며 분배도 없습니다. 검증인은 rand-node withdraw로 누적된 보상을 노트로 전환합니다(Staking). invoke의 셀 수수료는 번들 수수료의 일부이며 나머지와 함께 제안자에게 돌아갑니다. chain 20에는 블록 보상도 인플레이션도 없습니다. 검증인의 수입은 전적으로 수수료입니다.

chain 20에는 RAND가 아니며 어떤 검증인에게도 가지 않는 수수료가 하나 있습니다. 제네시스의 bridge.fees(v0.6.8에서 신설)에 따라 브리지는 모든 zUSD 입금과 모든 zUSD 소각에서 10 bps를 담보 자산의 릴리스 단위 정수로 내림하여 가져가고, 이를 제네시스에 명시된 트레저리 주소로 가는 zUSD 노트로 보관합니다. 입금은 입금자에게 총액에서 수수료를 뺀 금액을 적립하고, 소각은 원본 체인에서 amount − fee를 릴리스합니다. 수수료 노트는 발행된 상태로 담보가 유지됩니다. Bridge와 RPL tokens를 참조하십시오.

멤풀은 후보 트랜잭션을 KiB당 하한 초과 지불액 기준으로, 그다음 수수료 기준으로 정렬하므로(Mempool), 수수료를 높이는 것은 혼잡할 때만 의미가 있습니다. 전송 한 건은 약 2.85 MB(chain 18에서 측정)로, 1.49 MB의 번들 증명과 1.36 MB의 인가 증명으로 구성되므로 chain 20의 20 MiB 블록에는 약 7건이 들어갑니다. 풀노드 자체의 메모는, 메인넷 이전에 하한이 되어야 할 것은 옵코드가 아닌 바이트에 대한 수수료 시장이라는 것이었습니다. chain 20의 바이트 가격은 call에 대한 그 시장이며, call이 지불하는 바이트로만 움직입니다. 전송의 하한은 여전히 정액입니다.

이곳에서 gas가 한도가 아닌 가격인 이유

Ethereum은 모든 노드가 모든 트랜잭션을 실행하고 실행에 끝이 없으므로 모든 옵코드를 계량합니다. Rand에서는 어떤 노드도 아무것도 실행하지 않습니다. 발신자가 프로그램을 오프체인에서 한 번 실행하고 체인에는 증명을 넘깁니다. 트랜잭션당 노드의 작업은 고정된 순서, 즉 공개 필드를 디코딩하고, 무료 검사를 수행하고, STARK 하나를 검증하는 것이며, 이 검증은 프로그램이 무엇을 했든 워밍업된 검증 키를 사용할 때 약 16 ms가 걸립니다. 그래서 gas의 세 가지 역할이 서로 분리됩니다.

• 종료는 tier가 강제합니다. 2ᵗ − 1 사이클 안에 정지하지 않는 실행은 아예 증명할 수 없으며, 그 실패는 prover가 감당합니다.
• 작업의 가격 산정은 chain 18 이후 gas 하한이 하는 일입니다. 명령어당 네트워크 비용은 0에 가깝지만 발신자의 증명 작업은 실제 비용이며, 정액 하한은 백만 사이클짜리 call을 천 사이클짜리와 같은 가격으로 매겼습니다. chain 18 이전의 하한은 tier별 정액이었습니다.
• 블록 크기 조정은 바이트 예산(기본값은 MAX_BLOCK_BYTES = 4 MiB이고, 그렇지 않으면 제네시스의 max_block_bytes)과 트랜잭션 수(2,000)로 합니다.

풀노드가 분명히 밝히는 단서가 두 가지 있습니다. 바이트는 실제로 달라지며(증명은 1 MB가 넘으므로 부족한 자원은 연산이 아니라 블록 공간입니다), 상태 증가, 즉 트리, 널리파이어 집합, 배포된 프로그램 바이트는 워드당 배포 수수료와 정액 기본 수수료로만 가격이 매겨집니다. 이는 testnet에는 충분하지만 상태 크기가 문제가 될 때 재검토할 가치가 있습니다.

발신자가 대신 지불하는 것: 증명 생성

달라지는 유일한 비용은 STARK 증명을 만드는 일이며, 이는 발신자의 기기만 부담합니다. 영향이 큰 순서대로 나열하면 다음과 같습니다.

1. tier t ∈ {10, 12, 14, 16, 18, 20} (v0.5.6부터 체인에서 14를 넘는 call은 거부됩니다. 번들은 14로 고정되며 chain 17부터는 tier-10 인가 증명이 함께 붙어 약 7 s가 더 걸립니다). cpu 테이블은 2ᵗ 행으로 패딩되며, 한 단계 올라갈 때마다 패딩된 트레이스는 대략 4배가 됩니다. 개발용 노트북에서 측정한 결과, tier 10의 private_payment는 약 7 s, tier 14의 숨은 자산 번들 게스트는 어떤 자산을 옮기든 약 100 s였습니다.
2. 실행된 사이클 수. 이것이 tier를 결정하기 때문입니다. 기준은 작성된 명령어가 아니라 실행된 명령어입니다.
3. 프로그램 크기. 영향은 작으며, 트레이스 시작 부분에서 4워드당 다이제스트 행 하나입니다.
4. 비공개 입력 크기. 같은 방식으로 작용합니다.
5. 어떤 테이블이 존재하는가. keccak 또는 sha256 테이블은 게스트가 실제로 사용한 경우에만 해당 열의 몫만큼 비용이 듭니다.
6. FRI 프로파일. 쿼리 27개 대신 80개를 쓰면 증명 크기는 3배가 되지만 증명 시간은 거의 달라지지 않습니다.

증명은 금액, 발신자가 보유한 노트의 수, 체인의 크기에 좌우되지 않습니다. 멤버십은 고정 깊이 트리를 대상으로 증명되므로, 전송 비용은 블록 10에서나 블록 천만에서나 같습니다.

참조