이 페이지를 참고하여 머신을 선정한 뒤 노드를 운영하십시오. 밸리데이터는 비용이 적게 듭니다. 증명은 그렇지 않습니다. 증명의 메모리 사용량은 티어가 올라갈수록 가파르게 증가하며, 이 수치 하나가 해당 머신이 작업을 수행할 수 있는지를 좌우합니다. 여기에 실린 모든 수치는 testnet 또는 fullnode 기록에서 얻은 측정값입니다. 확정되지 않은 수치는 따로 표시했습니다.
역할별 기능
| 역할 | 기능 | 실행 명령 | 증명 여부 |
|---|---|---|---|
| 밸리데이터 | 트랜잭션을 정렬하고, 모든 블록의 모든 증명을 검증하며, HotStuff에서 투표합니다 | rand-node run --validator | 아니요 |
| 옵저버 | 동기화하고, 모든 증명을 다시 검증하며, JSON-RPC를 제공합니다. 투표는 하지 않습니다 | rand-node run | 아니요 |
| 증명자 (지갑) | 자신의 번들과 호출을 로컬에서 증명한 뒤 제출합니다 | rand send, rand call, rand program deploy | 예, 모든 트랜잭션 |
| 위임 증명자 | 자신과 연결된 지갑을 대신해 번들 증명을 생성합니다. chain 20에서는 해당 지갑의 조회 키(viewing key)를 전달받으며, 지출 키는 받지 않습니다 | rand-prover run 또는 rand-node run --prover | 예, 번들 증명만 |
| 집계자 | 봉인 블록을 위해 번들 증명 묶음 전체에 대한 재귀 증명 하나를 생성합니다 | rand-node aggregate --watch | 예, 가장 큰 증명 |
| 빌드 호스트 | rand-node와 rand를 컴파일하여 소형 노드에 바이너리를 전달합니다 | cargo build --release | 아니요 |
밸리데이터와 옵저버는 증명을 하지 않습니다. 차폐 전송이나 호출은 이를 보내는 지갑이 증명하며, 번들 증명만큼은 그 지갑과 연결된 증명자가 대신 수행할 수 있습니다 (노드 운영). 현재 플릿의 밸리데이터는 어떠한 증명도 하지 않습니다.
블록 집계는 구현되어 있으나 활성화되어 있지 않습니다. 제네시스에 aggregation 섹션이 필요합니다. chain 20에는 이 섹션이 없습니다. chain 9부터 19까지와 마찬가지로 집계는 꺼져 있으며, 이 섹션이 포함된 제네시스에서는 빌드가 시작을 거부합니다.
사양 한눈에 보기
| 역할 | RAM | CPU | 디스크 |
|---|---|---|---|
| 밸리데이터 또는 옵저버 | 2 GB (최초 플릿 기준). 밸리데이터는 동기화된 시계도 필요합니다 (시계) | 1 vCPU (최초 플릿 대부분) | --prune-history 24h를 사용하면 약 하루치 블록을 보관합니다. chain 14에서 블록 테이블은 3.3–4.4 GB로 측정되었습니다. 여유 공간을 4 GB 넘게 확보하십시오 (디스크) |
| 아카이브 (전체 기록) | 밸리데이터와 동일 | 밸리데이터와 동일 | 체인과 함께 증가합니다. chain 14의 1.4 s 블록에서 18개 서명 QC 기준으로 하루 약 3.6 GB가 측정되었습니다. QC에 최대 26개 서명이 담기는 chain 18~20에서는 더 많으나 다시 측정하지 않았습니다. testnet의 아카이브 두 대는 250 GiB 볼륨을 사용합니다 |
| 빌드 호스트 | 8 GB (node E) | 4 vCPU (node E) | 소스 트리, target/, 그리고 최소 20 GB의 여유 공간 |
| 증명자, 차폐 전송 (티어 14) | chain 18에서 전송 시 최대 6.1 GB, 결제 번들이 포함된 호출 시 6.1~6.6 GB (2026-09-30) | 코어 하나. chain 18에서는 증명이 두 개이며, 티어 14 번들 증명은 102 | 소형 |
| 위임 증명자 | 동시에 실행하는 증명 하나당 5.74 GB에 여유분 1 GiB를 더한 용량. 사용 가능한 메모리가 이보다 적으면 시작을 거부합니다 | 증명당 코어 하나 | 소형 |
| 증명자, 티어 18 호출 (ERC-20. v0.5.6부터 체인에서 거부됨, 증명 메모리 참조) | 85.0 GB (변환된 transfer) / 85.5 GB (인터프리트), m-16vcpu-128gb에서 측정 | 코어 하나 | 소형 |
| 증명자, 티어 20 호출 (SPL Token. v0.5.6부터 체인에서 거부됨) | 아직 증명된 적 없음. 약 330 GB로 외삽되며, 이는 DigitalOcean의 최대 메모리 드롭릿(m-32vcpu-256gb, 256 GB)보다 큽니다 | 코어 하나 | 소형 |
| 집계자, N = 1 | 2026-09-28/29 실행 이전에는 최소 64 GB가 하한이었습니다. 집계자 참조 | 현재는 CPU | 밸리데이터와 동일 |
| 집계자, N = 2 / N = 3 | 제약 집합 7 기준 133 GB / 221 GB 측정 (2026-09-28/29) | 프로덕션 N ≥ 2에는 GPU 노드 | 밸리데이터와 동일 |
현재 증명자는 단일 스레드입니다. vCPU 16개짜리 드롭릿에서도 코어 하나의 99%만 사용되었습니다. 코어를 늘린다고 증명 하나가 빨라지지는 않으며, 증명이 끝까지 완료되는지는 RAM이 좌우합니다.
밸리데이터와 옵저버
메모리와 CPU
최초 밸리데이터 18대는 2 GB 드롭릿에서 실행됩니다. 증명 검증은 비용이 적게 듭니다.
| 연산 | 비용 |
|---|---|
| 번들 증명 검증, 검증 키가 준비된 상태 | 약 16 ms |
| 새로운 shape에서의 첫 검증 | 약 230 ms |
| 배포된 프로그램의 검증 키 생성 (한 번, 백그라운드) | vCPU 2개 서버에서 약 7 s |
| 집계 증명 하나의 검증 (집계가 활성화된 경우) | 콜드 상태 약 0.8 s, 웜 상태 약 16 ms (설계 수치) |
밸리데이터가 티어 18 또는 티어 20 호출 증명을 검증하는 데 필요한 메모리는 이제 일부 측정되었습니다. 각 증명을 생성한 DigitalOcean 드롭릿과는 별개로 48 GB Apple Silicon 노트북에서 측정했습니다. 티어 18 transfer 증명의 검증에는 변환 방식에서 최대 RSS 3.66 GB로 50.2 s가 걸렸고, 인터프리터 방식에서는 49.6 s가 걸렸습니다 (RSS는 별도로 기록하지 않음). 티어 16 approve 증명의 검증에는 12.2 s가 걸렸습니다 (RSS는 별도로 기록하지 않음). 티어 20은 측정하지 못했습니다. 검증할 티어 20 증명이 아직 없기 때문입니다. v0.5.6부터 밸리데이터는 그만한 크기의 키를 만들지 않습니다. 검증 키를 만들기 전에 호출 증명의 헤더를 먼저 확인하며, 티어 14를 넘거나 keccak 테이블이 2^12를 넘거나 sha256 테이블이 2^13을 넘는 호출은 수락 단계에서, 그리고 블록 유효성 규칙으로서 거부됩니다. 수락 가능한 최악의 호출 헤더를 검증하는 데 4.7 s와 312 MB가 측정되었습니다.
1 vCPU, 2 GB 드롭릿에서는 바이너리를 빌드할 수 없습니다. 더 큰 머신에서 빌드한 뒤 복사하십시오 (설정 참조).
디스크
| 항목 | 값 | 출처 |
|---|---|---|
| v0.5.5 이전 chain 14의 유휴 블록 | blocks에 약 60 KB, qcs에 약 49 KB. 서명 18개의 Dilithium2 QC가 두 번 저장되어 1.4 s 블록 기준 하루 약 6.6 GB | 2026-09-24 디스크 장애, AGENTS.md |
| v0.5.5 이후 같은 블록 | 약 60 KB. 커밋된 블록의 QC는 자식 블록의 justify에 한 번만 저장되어 1.4 s 블록 기준 하루 약 3.6 GB | docs/deploy.md, v0.5.5 롤 노트 |
| RocksDB 선행 기록 로그 | 2026-09-24 수정 이후 256 MB로 제한. 그 전에는 밸리데이터당 정리되지 않은 로그가 13 GB | AGENTS.md |
--prune-history 24h가 소진된 이후의 chain 14 밸리데이터 (2026-09-25) | 블록 테이블 19 GB에서 3.3–4.4 GB로 감소, 디스크 사용률 18–37% | AGENTS.md, v0.5.7 |
| node A의 데이터 디렉터리, 높이 62,276의 chain 12 | 약 10 GB | deploy/README.md, v0.3 롤아웃 |
| 블록이 가득 찬 상태로 운영되는 체인 | 2 s마다 4 MiB, 하루 약 170 GB (chain 12까지의 블록 상한이며, chain 20의 상한은 20 MiB) | docs/block-space.md |
| 플릿이 빌드용으로 확보해 두는 여유 공간 | 최소 20 GB | docs/block-space.md |
| 체인 세 개의 데이터 디렉터리를 담은 30 GB 디스크 | 가득 참. RocksDB No space left on device, 크래시 루프 | mkc1과 mem1, deploy/README.md |
chain 20에서도 chain 19와 마찬가지로 밸리데이터 26대 중 24대가 --prune-history 24h로 실행되어 약 하루치 블록을 보관합니다. 원장 자체(노트, 널리파이어, 앵커, 레지스터)는 절대 정리되지 않습니다. 아카이브인 obs1과 rand-archive-2(둘 다 밸리데이터를 겸함)는 이 플래그 없이 실행됩니다. mainnet 노드는 이 플래그를 절대 사용하지 않습니다. 노드는 데이터 디렉터리의 파일 시스템에 --min-free-disk-mb(기본값 1,024 MB)보다 적은 여유 공간이 있으면 시작을 거부하며, rand_getHealth는 그 네 배 미만이면 disk_low를 응답합니다. ok를 기다리는 롤은 공간이 차 가는 노드에서 멈춥니다. 정리된 노드가 여전히 응답하는 내용은 기록 정리를 참조하십시오.
retired chain의 데이터 디렉터리는 전환 후에 삭제합니다. 데이터 디렉터리는 제네시스 해시를 기준으로 이름이 붙으므로(data-<name>-<hash8>: chain 20은 -6210cf07, chain 19는 -a3defc93이며, 가디언 호스트 여섯 대는 /var/lib/randnode/data-20을 사용합니다), 이전 디렉터리는 직접 제거하기 전까지 남아 있습니다. chain 20 전환 때 지역 밸리데이터 한 대(syd1)는 chain 14~17의 디렉터리가 남아 있어 여유 공간 3.9 GB로 disk_low 상태가 되었고, 시작이 26대 중 25대에서 멈췄습니다. 해당 디렉터리를 삭제해 22 GB를 확보했습니다. 이전 chain의 디렉터리는 롤백 대상으로 하루 동안 보관한 뒤 제거하십시오. 블록이 가득 찼을 때 원시 번들 증명 하나는 chain 14 이후 약 1.42 MB입니다(chain 13까지는 약 1.3 MB). chain 17 이후 모든 번들에는 인가 증명도 포함되므로, 전송 한 건의 증명은 약 2.85 MB입니다. 번들 증명이 약 1.49 MB, 인가 증명이 1.36 MB입니다(프로덕션 프로파일, 2026-09-29 측정). 집계가 활성화되면 봉인된 번들의 증명은 약 3 KB로 정리됩니다. 단, 노드를 --keep-raw-proofs로 실행하면 정리되지 않습니다. 인가 증명은 집계 대상이 아니며 원래 크기로 남습니다.
네트워크
공개 노드에서는 TCP 30303 인바운드를 개방하십시오. NAT 뒤의 노드는 --bootstrap으로 외부에 연결합니다. 4 MiB 블록이 가득 찬 상태에서 밸리데이터 링크 하나는 약 2 MB/s를 전송합니다.
시계
밸리데이터에는 NTP가 필요합니다. chain 14는 실제 시각(wall-clock time)이 합의의 일부가 된 첫 번째 chain입니다(브리지 강화 B2).
| 규칙 | 한도 | 종류 |
|---|---|---|
| 블록의 타임스탬프는 부모 블록의 타임스탬프보다 이 값을 초과하여 앞설 수 없음 | 60 s (MAX_TIMESTAMP_STEP_MS) | 유효성 규칙. 해당 블록은 무효임 (BlockError::TimestampLeap) |
| 밸리데이터는 타임스탬프가 자신의 시계보다 이 값을 초과하여 앞선 블록에는 투표하지 않음 | 15 s (MAX_CLOCK_DRIFT_MS) | 투표 규칙 |
시계가 20 s 느린 밸리데이터는 아무 오류 없이 투표를 중단합니다. 모든 정상 블록이 자신의 시계보다 앞서 있는 것으로 보여 투표를 보류하기 때문입니다. chain 20에서는 26대 중 18대가 투표해야 무엇이든 커밋됩니다. 모든 밸리데이터를 점검하고, 시계가 동기화되지 않은 곳에는 chrony를 설치하십시오.
timedatectl # want "System clock synchronized: yes" and "NTP service: active"
chronyc tracking 2>/dev/null || timedatectl show-timesync --all 2>/dev/null
apt-get install -y chrony && systemctl enable --now chrony같은 15 s 한도가 제네시스에도 적용됩니다. timestamp_ms는 시작 시각에 가깝게 설정하되 그보다 앞서지 않게 하십시오. 15 s를 넘어 미래인 제네시스는 실제 시각이 그 시점에 도달할 때까지 블록 1을 커밋하지 못하며, 과거로 크게 벗어난 제네시스는 블록 시간이 실제 시각보다 뒤처진 채 블록당 최대 60 s씩만 따라잡습니다(docs/deploy.md). 옵저버는 투표하지 않으므로 투표 규칙의 적용을 받지 않습니다.
테스트넷이 사용하는 DigitalOcean 사양
| 사양 | RAM, vCPU, 디스크 | 노드 | 비고 |
|---|---|---|---|
s-1vcpu-2gb | 2 GB, 1 | 대부분의 지역 밸리데이터 (ams3, nyc1, nyc2, sfo2 등) | 빌드 불가. 바이너리를 복사해 넣음 |
s-1vcpu-2gb-amd | 2 GB, 1 | atl1 | 위와 같음 |
s-2vcpu-2gb-intel | 2 GB, 2 | D (ric1) | |
s5-1vcpu-2gb-30gb | 2 GB, 1, 30 GB | mkc1, mem1 (해당 지역의 유일한 소형 사양) | chain 13 전환 때 디스크가 가득 찼음(29 GB). 폐기된 chain 11 데이터 디렉터리를 삭제한 뒤 7 GB가 비었음. 사양 변경 필요 |
| 4 vCPU, 8 GB | 8 GB, 4 | E (sgp1) | 밸리데이터, 빌드 호스트, 익스플로러 |
이 표는 원래의 밸리데이터 열여덟 대를 다룹니다. 2026-09-27부터 밸리데이터 A도 노트북이 아닌 droplet(sgp1)에서 실행됩니다. chain 15(2026-09-27)에서는 밸리데이터 여덟 대가 추가로 본딩되었습니다. 아카이브 두 대인 obs1과 rand-archive-2(fra1), 그리고 가디언 호스트 여섯 대입니다. 이들의 droplet 사양은 여기에 기록되어 있지 않으며, mkc1과 mem1의 사양이 변경되었는지도 기록되어 있지 않습니다. chain 20에서는 chain 19와 마찬가지로 26대 모두 각 1,000 RAND의 제네시스 밸리데이터이며, 2026-09-30 기준으로 26개의 키를 모두 한 운영자가 보유합니다.
증명 메모리
지갑은 전송하는 모든 트랜잭션을 증명하므로, 프로그램의 호출자에게는 해당 프로그램의 tier에 필요한 메모리가 있어야 합니다. 아래는 측정된 한계입니다. tier 18 실행은 DigitalOcean에서 증명과 검증을 마쳤고, tier 20은 아직 마치지 못했습니다. v0.5.6 이후 chain은 tier 14를 초과하는 호출 증명을 거부하므로(MAX_CALL_TIER), 아래 표의 tier 16, 18, 20 행은 측정값일 뿐 chain 20이 허용하는 호출이 아닙니다. chain 14에서 커밋된 호출은 모두 tier 10이었습니다.
| 워크로드 | tier | 사이클 | 측정 내용 | 필요 사양 |
|---|---|---|---|---|
차폐 전송 (bundle 게스트) | 14 | chain 13에서 약 9,160 (2-in-2-out 게스트) | Apple Silicon 노트북에서 92.2–96.0 s (프로덕션, chain 13, 2026-09-19). 최대 메모리는 기록되지 않음. chain 14의 4-in-4-out 숨김 자산 게스트도 같은 tier로 고정되어 있으며 약 100 s, 증명 크기 약 1.42 MB. chain 20에서 전송은 증명 두 개입니다(chain 17 이후 분리된 인가): tier 14 번들 증명은 102 | 개발용 노트북에서 실행 가능 |
ERC-20 approve (프로덕션, chain 13, 2026-09-19) | 16 | 48,119 | 호출 증명 388.7 s, 3,412,405 바이트. rand call 전체는 48 GB M 시리즈 노트북에서 622.8 s, 최대 RSS 22.9 GB | 48 GB 노트북 |
| ERC-20 호출 | 18 | 약 66k~162k | 1단계 transfer(79,203 사이클, 코드 가드 이전)는 48 GB 노트북에서 1,016 s 후 24.7 GB에서 SIGKILL되었고, 64 GB droplet 실행은 25분 시점에 47 GB를 넘었음 | 최대 RSS 85.0 GB(변환) / 85.5 GB(해석), 증명 시간 3,230.5 s / 3,143.3 s, 증명 크기 811,600 / 805,108 바이트. m-16vcpu-128gb에서 측정, 2026-09-19 |
| SPL Token 벡터 | 20 | 약 700k~770k | 변환된 Transfer(692,854 사이클, ELF 가드 이전)는 48 GB 노트북에서 225 s 후 30.77 GB에서 증명이 진행 중인 상태로 중단되었고, tier 20 실행은 64 GB droplet에서 10분 41초 후 65.1 GB에서 OOM으로 종료되었음 | 아직 증명되지 않음. 약 330 GB와 약 3.6 h로 외삽(측정된 tier 16/18 확장: +2 tier마다 메모리 약 ×3.9, 시간 약 ×4.1). DigitalOcean의 가장 큰 메모리 droplet(m-32vcpu-256gb, 256 GB)보다 큼 |
| rVM tier 21 프로덕션 종료 (재귀 VM 안에서 번들 증명 하나를 검증) | 21 | 1,968,619 행 | 실행 전 도출한 요구량은 48.6 GB였으나, 제약 집합 7에서는 256 GB droplet이 제공하는 양보다 더 필요했음 (2026-09-28/29) | 256 GB 초과. 제약 집합 8에서는 다시 측정하지 않음 |
ERC-20 호출은 tier 16과 18에, SPL Token은 tier 20에 해당합니다(Ethereum, Solana). tier 18이나 20의 증명은 48 GB 머신에서 만들어진 적이 없습니다.
집계자
집계자는 chain을 감시하다가 확정된 블록 구간의 번들 증명을 모아 이를 아우르는 재귀 집계 증명 하나를 만들고 제출합니다. 이를 포함하는 블록이 봉인 블록입니다. 집계자는 포괄된 번들의 증명 몫과 새로 발행되는 RAND의 블록 보조금을 등록된 지급 주소로 받습니다. 집계는 허가가 필요 없으며, 본드를 가진 운영자라면 누구나 등록할 수 있습니다.
집계는 제네시스에 aggregation 섹션이 있는 chain에서만 존재합니다. chain 20에는 이 섹션이 없으며, 이 섹션이 있는 제네시스에서는 빌드가 시작을 거부합니다.
하드웨어
| 집계 | 호스트 RAM | 백엔드 |
|---|---|---|
| N = 1 번들 | 최소 64 GB | CPU. 테스트 프로파일은 부하가 걸린 노트북에서 하나를 약 26분에 증명함 (327,035 바이트) |
| N = 2 | 133 GB 측정. 이전 한계는 최소 128 GB | 프로덕션에서는 GPU 백엔드 |
| N = 3 | 221 GB 측정. 이전 한계는 최소 160 GB | 프로덕션에서는 GPU 백엔드 |
| 플릿 GPU 노드 | 호스트 최소 160 GB, 디바이스 80 GB (H100 또는 A100-80G) | Linux, R580+ 드라이버, CUDA 13, LLVM 21, sm_80+. 아직 존재하지 않음 |
N = 2와 N = 3의 수치는 2026-09-28/29에 256 GB DigitalOcean droplet에서 제약 집합 7로 측정한 값이며, 프로덕션 종료 증명은 그 머신의 256 GB보다 더 많은 메모리가 필요했습니다. chain 1820이 사용하는 제약 집합 8에서는 어느 것도 다시 측정하지 않았으므로 N = 1 행은 하한으로 보십시오. CUDA 백엔드는 2026-09-28에 NVIDIA H100에서 실제 하드웨어로 처음 실행되었습니다. 커널은 sm_80과 sm_90용 PTX로 빌드되며 CPU 참조 구현과 일치합니다. 플릿 GPU 노드에서의 프로덕션 측정은 아직 남아 있습니다. 모든 노드는 집계 프로그램에 대해 시작 시 키 빌드를 한 번 수행해야 하며, 테스트 프로파일(2¹⁹)에서는 13.013.4 s, 프로덕션(2²¹)에서는 30~70 s가 예상됩니다.
명령어
# print a signed registration; the bond burns out of a wallet bundle as the register bundle's burn
rand-node aggregator register --key agg.key.json --bond <RAND> --payout rand1… --rpc http://127.0.0.1:8545
# the daemon: poll rand_getUnsealed, fetch the raw bundles, prove, seal the payment note, submit
rand-node aggregate --key agg.key.json --rpc http://127.0.0.1:8545 --watch
# leave, then withdraw the released bond into a note at the payout address
rand-node aggregator unbond --key agg.key.json --rpc http://127.0.0.1:8545
rand-node aggregator withdraw --key agg.key.json --rpc http://127.0.0.1:8545aggregate 플래그 | 기본값 | 의미 |
|---|---|---|
--key | 필수 | 레지스터가 인식하는 aggregator 키이며, 모든 aggregate에 서명합니다 |
--rpc | http://127.0.0.1:8545 | 폴링하고 제출할 대상 노드 |
--watch | off | 한 번만 제출하지 않고 계속 폴링합니다 |
--interval-secs | 15 | --watch 사용 시 폴링 간격 |
--no-wait | off | 노드가 aggregate를 수락하면 즉시 반환합니다 |
rand status는 이러한 체인에서 aggregation 섹션을 표시합니다. 등록된 aggregator, 봉인되지 않은 블록, 보조금 일정 인덱스가 여기에 나옵니다. rand_getUnsealed는 작업 목록입니다.
설정
이 단계는 testnet이 사용하는 스크립트(deploy/vps-setup.sh, deploy/update-droplet.sh)를 따릅니다. 이 단계를 거치면 Linux 검증자 노드 또는 옵저버 노드가 만들어집니다.
1. 빌드 호스트에서 빌드
빌드에는 build-essential clang cmake pkg-config libssl-dev, Rust 1.98.1(rust-toolchain.toml로 고정), 그리고 fullnode 체크아웃 옆의 circuits 체크아웃이 필요합니다. 첫 빌드에는 10~20분이 걸립니다.
git clone https://github.com/randprotocol/fullnode
git clone https://github.com/randprotocol/zkp-circuits circuits
cd fullnode
git checkout v0.6.8 # c9c9bd3c, the build chain 20 runs
git -C ../circuits checkout "$(sed -n 's/^circuits: //p' crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)" # aeacf31 for v0.6.8
git show origin/main:deploy/genesis-chain20.json > deploy/genesis-chain20.json # committed after the tag
cargo build --release -p randprotocol-node -p randprotocol-client
sha256sum target/release/rand-node # compare on every node you copy it toChain 20은 init 이전에 모든 노드에 v0.6.8이 필요합니다. Chain 20의 제네시스에는 이전 빌드가 읽지 못하는 필드(testnet, binding_domain, proof_window_blocks, program_state, 브리지의 rotation 및 fees 그룹, 가스 상한, 투표에 의한 스테이킹 허가)가 들어 있으며, v0.6.8에는 audit v6의 CON-4 및 CH-1 합의 변경이 포함되어 있습니다. 증명은 chains 18 및 19와 마찬가지로 여전히 제약 집합 8 아래에서 생성되며, 모든 번들 증명 옆에 인가 증명(hc_auth)이 함께 붙습니다. v0.6.8 빌드는 chains 14~17의 제네시스를 run 및 verify에서 거부합니다. 플릿이 실행하는 것과 동일한 빌드를 사용하십시오. 제네시스 파일은 v0.6.8 태그가 아니라 fullnode의 main(커밋 74cfaca0)에 있으므로 세 번째 git 줄이 필요합니다. circuits 체크아웃은 릴리스가 vendoring된 커밋에 있어야 하며, 이 커밋은 위의 두 번째 git 줄이 fullnode 트리에서 읽어 옵니다. rand-prover도 함께 빌드하려면 -p randprotocol-prover를 추가하십시오.
2. 노드에 바이너리 설치
scp target/release/rand-node target/release/rand deploy/genesis-chain20.json root@<node>:/root/
ssh root@<node> 'install -m 755 /root/rand-node /root/rand /usr/local/bin/'3. 키, 제네시스, 방화벽
노드에서 다음을 실행합니다.
install -d -m 700 /root/keys
test -e /root/keys/node.key.json || rand-node keygen --out /root/keys/node.key.json # prints the address; keep the seed secret
rand-node init --datadir /root/data-6210cf07 --genesis /root/genesis-chain20.json
timedatectl # "System clock synchronized: yes" (see Clock)
ufw allow 22/tcp && ufw allow 30303/tcp && ufw enable위와 같이 노드에서 키를 생성하고, 어떤 체크아웃에도 두지 마십시오. 이제 fullnode 저장소에는 추적되는 키가 없습니다(audit v3, OPS-1). chains 8~13용으로 커밋된 deploy/node-*.key.json 파일은 공개된 시드입니다. Chain 20의 검증자 키(chain 14용으로 생성된 18개와 chain 15에서 본딩된 8개)는 저장소 밖에서 생성되었으며, 플릿은 각 droplet의 키를 소스 트리 바깥인 /root/keys/node-<name>.key.json에 보관합니다. 플릿의 스크립트로 프로비저닝된 노드에서는 이 위치가 중요합니다. deploy/rebuild-vps.sh와 deploy/push-to-vps.sh는 /root/fullnode를 --delete 옵션으로 rsync하므로, 그 트리 안에 둔 키는 다음 리빌드에서 삭제되고 유닛이 재시작에 실패하게 됩니다. v0.6.8부터 keygen은 기존 파일을 덮어쓰기를 거부합니다(v0.6.7은 묻지 않고 덮어썼습니다). test -e는 어느 쪽이든 이 줄을 다시 실행해도 안전하게 유지해 줍니다. 본딩하기 전에 키를 호스트 밖에 백업하십시오.
init은 제네시스 해시를 출력합니다. 출력은 반드시 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135(chain 20)여야 합니다. 제네시스 파일은 fullnode 저장소 main의 deploy/에 있는 genesis-chain20.json입니다. 플릿과 마찬가지로 데이터 디렉터리의 이름은 해시의 처음 여덟 문자로 짓고(data-<name>-6210cf07), chain 19의 -a3defc93이나 이후 체인의 디렉터리와 충돌하지 않도록 하십시오. 제네시스는 다음 한도를 설정합니다. 증명 상한은 chains 13~16에서 8 MiB였고, 트랜잭션이 최대 세 개의 증명을 담기 시작한 chain 17부터 4 MiB입니다.
| 한도 | chain 20 |
|---|---|
max_program_words | 65,535 |
max_proof_bytes | 4,194,304 (4 MiB) |
max_block_bytes | 20,971,520 (20 MiB) |
max_call_envelope_bytes | 65,536 |
max_program_public_words | 32,768 |
envelope_bytes | 1,860 (모든 note 봉투, 암호화된 메모 필드 포함) |
proof_window_blocks | 1,024 (chain 19에서는 256) |
program_state | 셀 수수료 0.1 RAND (10,000,000 units); invoke당 읽기 최대 8회, 쓰기 최대 8회, 지급 최대 4회 |
aggregation 섹션 | 없음 (aggregation 꺼짐) |
Chain 20의 제네시스에는 consensus_domain: 1, binding_domain: 1, testnet: true, 투표에 의한 허가를 설정한 staking 섹션, 가격 상한을 설정한 gas 섹션, 브리지의 rotation 및 fees 그룹, hardening_v6, 그리고 두 개의 게스트 핀 hc_bundle과 hc_auth도 들어 있습니다. 이들이 설정하는 내용은 Running a node에 정리되어 있습니다.
4. systemd 유닛
다음은 위의 경로를 적용한 deploy/vps-setup.sh가 작성하는 유닛입니다.
[Unit]
Description=RAND full node
After=network-online.target
[Service]
Environment=RUST_LOG=info,libp2p=warn,libp2p_mdns=off
ExecStart=/usr/local/bin/rand-node run --datadir /root/data-6210cf07 --key /root/keys/node.key.json --validator --listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns --prune-history 24h --bootstrap <multiaddr> --bootstrap <multiaddr>
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target옵저버 노드에서는 --validator를 빼십시오. --prune-history 24h는 아카이브를 제외한 testnet 검증자들이 실행하는 값이며, 전체 이력을 보관하는 노드에서는 빼고 mainnet에서는 절대 사용하지 마십시오. Chain 20의 부트스트랩 multiaddr은 노드 C(fra1), D(ric1), E(sgp1)이며 chain 19와 동일합니다. Chain 20은 chain 14용으로 생성된 검증자 키로 실행되고 p2p 식별자는 검증자 키에서 파생되므로, 이 peer id는 chain 14에서 사용된 것과 같습니다. 제네시스부터 동기화하는 새 노드에는 전체 이력을 가진 피어도 필요하므로 두 아카이브(obs1, 그다음 rand-archive-2) 중 하나를 추가하십시오.
/ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe
/ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw
/ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ
/ip4/168.144.46.203/tcp/30303/p2p/12D3KooWS5usdMPvsbaWSaT2xtKndHvDYurwmueoNvaRRarb2wRf
/ip4/206.81.29.236/tcp/30303/p2p/12D3KooWPocyZGcNB9Vp68VSfgVvNXhSzBBoJa4h9R1yMkp71XHh방화벽이 보호하지 않는 한 RPC는 127.0.0.1에 유지하십시오. 공개 서비스를 제공할 노드는 그 옆에 v0.6.8의 공개 리스너(--public-rpc <ADDR>)를 열고, 프록시는 --rpc가 아니라 그 리스너 앞에 두십시오(JSON-RPC). v0.6.7에서 가져온 유닛에는 --prover-accept-spend-key를 넣어서는 안 되며, v0.6.8은 시작 시 이를 거부합니다.
systemctl daemon-reload && systemctl enable --now rand-node
journalctl -u rand-node -f
rand status # height climbing, peer_count rising5. 검증자 집합에 참여
새 키는 어떤 epoch의 집합에도 속해 있지 않습니다. Chain 20에서는 먼저 투표로 승인되어야 합니다. 제네시스가 staking.admission_by_vote를 설정하므로, 투표 가중치의 3분의 2 이상을 가진 검증자들이 각자 rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash>로 서명하고, 그중 하나가 rand-node admit submit으로 투표를 제출합니다. 그러면 rand_getAdmitted가 해당 키를 나열합니다. 그다음 그 키에 최소 1,000 RAND를 본딩합니다. rand-node register --key /root/keys/node.key.json --payout rand1… --v2로 등록 정보를 출력하고(chain 20은 v1 등록을 거부합니다), 지갑에서 rand bond <address> 1000 --registration <hex>로 본딩합니다. 본딩은 활성화 epoch까지 대기하며, 이는 커밋 이후 최소 1,000블록 경계 세 번째이고, 경계마다 새 가중치로 편입되는 양은 활성 가중치의 최대 2,500 bps입니다(chain 19는 고정 10,000 RAND로 제한했습니다). Staking에서 전체 과정을 안내합니다.
6. 업데이트
이 내용은 같은 체인을 실행하는 빌드에 적용됩니다. 이전 체인에서 chain 20으로 옮기는 것은 업데이트가 아닙니다. 새 바이너리, 새 제네시스, 새 데이터 디렉터리가 필요하며, 이전 체인의 데이터 디렉터리는 나중에 삭제할 수 있습니다(deploy/retire-chain-dirs.sh; 플릿은 롤백에 대비해 하루 동안 보관합니다). 체인 컷 없이 새 빌드를 롤링하려면 한 번 빌드하고 rand-node와 rand 둘 다의 sha256을 비교한 뒤, 서비스를 중지하고 설치한 다음 재시작하되 노드를 하나씩 진행합니다. 일부 릴리스는 대신 전체 중지 후 전체 시작으로 롤아웃합니다(v0.5.6의 call-tier 규칙, v0.5.7의 Status 와이어 변경, v0.6의 더 엄격한 증명 검증). 어느 방식인지는 각 릴리스 노트에 적혀 있습니다. v0.6.7은 chain 18에 노드를 하나씩 롤링했고, v0.6.8은 chain 20과 함께 전체 중지 후 전체 시작으로 나왔는데, CON-4 및 CH-1 합의 변경은 노드별로 롤링해서는 안 되기 때문입니다. 다음 노드로 넘어가기 전에 각 노드가 다시 합류하기를 기다려, 쿼럼이 한 노드보다 더 부족해지지 않게 하십시오. deploy/update-droplet.sh <ip> [build-host]는 이를 SSH로 그대로 수행합니다.
v0.6.8까지의 릴리스는 한 호스트에서 수작업으로 빌드되었으며 서명되지 않았습니다. v0.6.8 GitHub release에는 노드 E에서 빌드된 rand-node, rand, rand-prover, SHA256SUMS가 들어 있습니다. 이 체크섬은 손상된 다운로드는 잡아내지만 빌드 호스트를 보증하지는 않습니다. v0.6.8에는 태그에서 바이너리를 빌드하는 릴리스 워크플로가 포함되어 있으며, deploy/update-droplet.sh는 ALLOW_UNSIGNED=1이 설정되지 않은 한 서명된 SHA256SUMS가 없는 설치를 거부합니다. deploy/release-signers에는 아직 키가 등록되어 있지 않으므로, 서명 경로는 사용된 적이 없습니다.
Chains 15, 16, 17, 18은 2.7일 안에(2026-09-26~2026-09-29) 가동되었으며, 각각 플릿 전체를 중지하는 방식이었습니다. Chain 19는 2026-10-01 03:43 UTC에 이어졌는데, 같은 빌드에서 chain 18을 다시 제네시스한 것이었고, chain 20은 같은 날 06:17 UTC에 v0.6.8 하드 포크 시점의 chain 19 스냅샷에서 분기되었습니다. 모든 노드는 chain 19 높이 7,700에서 중지했습니다. 2026-09-30의 문서화된 컷 정책은 chain 20부터 적용됩니다. Chain 20의 컷 기록은 두 번째 운영자의 리빌드를 면제했는데, 한 운영자가 모든 키를 보유하기 때문입니다. 컷에는 롤링 업데이트로는 충족할 수 없는 사유, 컷이 담는 것과 버리는 것의 공개 목록, 사전에 완료된 클라이언트 리빌드 체크리스트, 제네시스를 같은 해시로 다시 빌드하는 두 번째 운영자, 롤백 계획, 한 번도 쓰이지 않은 체인 id가 필요합니다.