공급량

이 페이지는 rand_getSupply를 올바르게 읽고 발행량을 이해하는 데 사용합니다. RAND가 어디에서 나와 어디로 가는지, 그리고 아무도 노트를 합산할 수 없는데도 차폐 체인의 공급량을 정확하게 만드는 항등식을 다룹니다.

RAND가 나오고 나가는 곳

차폐 체인은 자기 자금을 합산할 수 없습니다. 노트의 가치는 커밋먼트 안에 있기 때문입니다. 공개되는 것은 풀의 경계를 넘나드는 모든 이동입니다. 이동에는 다섯 가지 종류가 있으며, 프로그램 금고(RPL-2, 체인 20)가 있는 체인에서는 일곱 가지입니다.

제네시스에서 tokens.burn_registration_fee를 설정한 체인(체인 20이 그러합니다)에서는, 토큰 등록의 1 RAND registration_fee도 burned를 통해 풀을 떠나지만 어떤 레지스터 항목에도 들어가지 않습니다. 이 수수료는 소멸되며, 제안자는 번들 기본 수수료만 가져갑니다.

풀 옆에는 밸리데이터 레지스터가 있으며, 합의 가중치가 공개되어야 하므로 금액을 평문으로 보관합니다. 레지스터의 스테이크는 실제 RAND입니다. 언본딩한 뒤 다시 노트로 인출할 수 있습니다. 체인 20에서는 프로그램 금고가 그 옆의 두 번째 공개 잔액입니다. invoke가 예치한 RAND는 지급을 통해 노트로 풀에 돌아올 때까지 그곳에서 계수 가능한 상태로 남습니다.

체인 20에는 블록 보상도 인플레이션도 없습니다. 이 체인의 첫 예정 발행은 블록 집계 보조금입니다. 봉인된 블록마다 감소하는 양의 새 RAND를, 그 블록을 증명에 포함한 집계자에게 지급하는 것이며, 체인 20에서는 활성화되어 있지 않습니다(증명). 체인 20은 체인 19에서 분기하여(fullnode v0.6.8, 하드 포크) 2026-10-01 06:17 UTC에 가동된 새 체인입니다. 제네시스에서 31,184.243719258 RAND를 발행했습니다. 26명의 제네시스 밸리데이터에 걸쳐 스테이킹된 26,000과, 체인 19에서 이월한 7개 운영자 지갑의 잔액인 7개 예치 노트의 5,184.243719258입니다. 체인 19에서 다른 지갑들이 보유하던 약 519.9 RAND(허용 목록 수령인에 대한 파우셋 민트, 사용자에게 보낸 결제)는 이월되지 않았습니다. 소유자의 주소 없이는 노트를 다시 만들 수 없기 때문입니다. 인출되지 않은 밸리데이터 보상 0.499 RAND도 이월되지 않았습니다. 제네시스 노트 두 개가 더 있어 모두 아홉 개이며, 이는 브리지의 99 zUSD(10과 89)를 담고 있습니다. 이는 RAND가 아니므로 이 감사의 범위 밖입니다. 체인 20의 rand_getSupply는 genesis_deposited 5,184,243,719,258 단위와 invariant_holds: true를 반환합니다(높이 3,037, 2026-10-01). 같은 날 높이 141,935의 체인 18 스냅샷에서 분기한 체인 19는 31,294.644359629 RAND를 발행했습니다. 같은 26,000이 스테이킹되었고 5,294.644359629가 7개 노트에 있었으며, 10 zUSD 노트 하나가 함께 있었습니다. 이후의 모든 파우셋 민트는 발행 수치에 더해지고, 소각된 모든 등록 수수료는 그 수치에서 차감됩니다. 2026-09-26에 분기한 체인 15는 제네시스에서 23,000 RAND를 발행했습니다. 18명의 밸리데이터에 걸쳐 스테이킹된 18,000과 5개 노트의 5,000입니다. 이후의 밸리데이터 8명은 기존 노트에서 본딩했으며, 이는 아무것도 발행하지 않았습니다.

토큰은 이 감사의 범위 밖입니다

위의 이동은 RAND의 것입니다. 브리지된 것이든 네이티브든 RPL 토큰은 RAND의 경계를 넘지 않습니다. 자산 인덱스 0은 RAND를 위해 예약되어 있고 토큰 레지스트리는 이를 내주지 않으므로, BridgeAttest, TokenMint, 또는 등록 시의 초기 민트는 언제나 다른 자산의 노트를 예치하고, BridgeBurn이나 TokenBurn의 burn_a는 언제나 그런 노트를 소멸시킵니다(burn_a를 통한 RAND 소각은 거부됩니다). fees_paid와 burned는 번들의 fee와 burn_r만으로 집계되며, 풀 안의 토큰 전송은 자산조차 공개되지 않으므로 어떤 카운터도 움직이지 않습니다. 체인 20에서 Invoke는 burn_a를 통해 토큰을 받아들일 수도 있습니다. 프로그램의 금고로 들어가는 경우(deposit)에는 공급량이 변하지 않고, 소멸되는 경우(burn)는 프로그램 자체의 토큰에 한합니다. 브리지의 수수료 노트(체인 20, 각 zUSD 예치와 소각의 10 bps, 재무 주소로)는 zUSD이며 RAND가 아닙니다. 이는 발행되고 담보된 것이므로, 예치의 담보와 공급량은 총액만큼 움직이고 소각의 경우는 amount − fee만큼 감소합니다. 토큰 자체의 공급량은 레지스트리의 공개 집계입니다. rand_getTokenSupply는 total_supply를 반환하며, 브리지된 토큰의 경우 각 담보의 locked 금액도 반환하고 이 둘의 합이 공급량과 같습니다(RPL 토큰).

감사 항등식

단위(1 RAND = 10⁹)로 표시되는 여섯 개의 단조 카운터, 소멸된 것을 기록하는 두 개, 그리고 체인 20에서는 프로그램 금고를 위한 두 개가 있습니다.

pool_value     = genesis_deposited + faucet_minted + withdraw_deposited + program_rand_out − fees_paid − burned
register_total = Σ over the register of (stake + pending + rewards)
total_supply   = pool_value + register_total + program_rand_held
issued         = genesis_deposited + genesis_staked + faucet_minted

invariant:       total_supply == issued − slashed − registration_fees_burned

pool_value는 들어온 것에서 나간 것을 뺀 값이며, 아무도 계산할 수 없는 노트의 합과 같은 수입니다. 인출의 0.001 RAND 기본 수수료는 이동이 아닙니다. 이는 한 레지스터 행에서 제안자의 행으로 옮겨질 뿐이며, 노트만이 경계를 넘었습니다. invariant_holds가 false인 것은 합의 버그이거나 손상된 데이터베이스이며, 정상적인 상태일 수 없습니다. 프로그램 항 두 개는 프로그램 금고가 없는 체인에서는 0이므로, 그곳의 항등식은 체인 19의 것과 같습니다. 어떤 체인에도 있었던 적이 없는 제네시스 vesting 섹션은 같은 방식으로 세 번째 공개 레지스터를 추가할 것입니다(JSON-RPC).

2,000을 예치하고 4,000을 스테이킹한 체인에서 1,000 RAND의 본드 한 번과 인출 한 번을 따라가 보면 다음과 같습니다.

읽는 방법

curl -s http://127.0.0.1:8545 -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"rand_getSupply","params":[]}'

{ "height": 1998,
  "genesis_deposited": "2000000000000", "genesis_staked": "4000000000000",
  "faucet_minted": "0", "withdraw_deposited": "999999000000",
  "fees_paid": "1000000", "burned": "1000000000000",
  "slashed": "0", "registration_fees_burned": "0",
  "pool_value": "1999998000000", "register_total": "4000002000000",
  "total_supply": "6000000000000", "invariant_holds": true }

JSON 숫자는 2⁵³을 넘으면 정확한 정수가 아니므로, 모든 금액은 단위의 십진 문자열입니다. 전체 객체에는 여기에 나온 것보다 많은 필드가 있습니다. 그중에는 체인 20이 예산에 대해 검사하는 파우셋의 에포크별 쌍 faucet_epoch와 faucet_minted_in_epoch, program_rand_out과 program_rand_held(v0.6.8부터), 그리고 vesting 섹션이 없는 체인 20의 제네시스에서 "0"으로 읽히는 네 개의 vesting_* 카운터가 있습니다(JSON-RPC). 익스플로러는 같은 객체를 GET /supply로, 주요 수치를 GET /stats로 제공합니다.

얼마나 정확한가

체인이 스스로 수행한 모든 것에 대해 카운터는 정확합니다. 각 카운터는 해당 동작을 적용하는 코드 경로에서 그 동작 자체의 공개 필드로부터 증가합니다.

두 항목은 이전에는 주장에 의존했으며, 체인 14가 둘 다 검사로 바꿉니다(감사 v3, POOL-1):

• faucet Mint은 노트의 오프닝을 포함합니다. 이 액션은 cm과 amount 외에 pk, time, r을 공개합니다. 승인 단계에서는 (pk, no sender, amount, asset 0, time, r)의 커밋먼트를 다시 계산하여 일치하지 않으면 the mint's commitment does not open to its published note and amount라는 메시지와 함께 거부하며, time은 번들 윈도우 안에 있어야 합니다. 민터는 일곱 개의 필드 전체에 도메인 rand-mint-2로 서명합니다. 이전에는 validator가 하나의 금액을 공개하고 다른 금액의 가치를 지닌 노트를 봉인할 수 있었습니다. 그 대가로 faucet 노트의 소유자 pk는 withdraw의 지급과 마찬가지로 공개됩니다. rand_mint의 매개변수는 변경되지 않습니다.
• genesis alloc 노트도 오프닝을 포함합니다. tokens 섹션이 있는 체인에서는 모든 행이 { cm, envelope, amount, opening: { pk, time, r } } 형식이며, 노드는 커밋먼트를 다시 계산합니다. 오프닝이 목록에 있는 토큰의 asset을 지정하지 않는 한 asset 0을 기준으로 하며, cm이 일치하지 않는 genesis 파일은 거부합니다. genesis_deposited에는 asset 0 행만 합산됩니다. 불투명한 cm은 genesis 작성자가 어떤 자산이든 담보 없는 노트를 풀에 넣으면서도 누구도 이를 검증할 수 없게 만드는 유일한 방법이었습니다. 따라서 genesis 노트의 소유자와 금액은 파일이 공개되는 순간 설계상 공개되며, 그 노트가 언제 어디에 사용되는지만 비공개로 유지됩니다. rand-node genesis는 항상 오프닝을 기록합니다.

tokens 섹션 없이 생성된 체인에서는 이전 규칙이 그대로 적용됩니다. genesis_deposited는 선언된 amount 필드의 합이며, genesis 파일의 값을 신뢰합니다. 두 genesis 금액은 모두 genesis 해시에 포함되므로, 어느 경우든 모든 노드가 같은 값에 합의합니다.

카운터는 의도적으로 합의 상태가 아닙니다. 상태 루트는 카운터를 해시하지 않으며, rand-node verify --mode quick은 체인을 재생하여 모든 카운터를 다시 계산하고 저장된 스냅샷이 일치하지 않으면 불일치를 보고합니다.