使用本頁，可在運行機器前估算所需規格。運行驗證者的成本很低，證明則不然：證明所需記憶體隨層級急劇增長，也是決定一台機器能否勝任的唯一數字。此處所有數字均來自測試網（testnet）或全節點的記錄實測；尚未最終確定的數字已特別標明。
各角色的職責
| 角色 | 職責 | 運行指令 | 是否證明？ |
|---|---|---|---|
| 驗證者 | 為交易排序，驗證每個區塊中的每個證明，在 HotStuff 中投票 | rand-node run --validator | 否 |
| 觀察者 | 同步、重新驗證每個證明、提供 JSON-RPC 服務；不投票 | rand-node run | 否 |
| 證明者（錢包） | 在本機為自己的交易包和調用生成證明，然後提交 | rand send、rand call、rand program deploy | 是，每筆交易 |
| 委託證明者 | 為與其配對的錢包生成交易包證明；在 chain 20 上，它收到的是該錢包的查看密鑰，絕不是花費密鑰 | rand-prover run，或 rand-node run --prover | 是，僅限交易包證明 |
| 聚合者 | 為一個封存區塊，將一個窗口內的交易包證明聚合成一個遞歸證明 | rand-node aggregate --watch | 是，最大的證明 |
| 構建主機 | 編譯 rand-node 和 rand，並將二進制文件交給小型節點 | cargo build --release | 否 |
驗證者和觀察者從不生成證明。屏蔽轉賬（shielded transfer）或調用，由發送它的錢包生成證明；若只涉及交易包證明，則可由與該錢包配對的證明者生成（運行節點）。目前，集群中的驗證者不生成任何證明。
區塊聚合已構建完成，但尚未啟用。它需要在創世區塊中設有 aggregation 部分。Chain 20 沒有該部分：聚合處於關閉狀態，與 chain 9 至 19 相同；若創世區塊帶有該部分，構建版本會拒絕啟動。
規格一覽
| 角色 | 記憶體 | CPU | 磁碟 |
|---|---|---|---|
| 驗證者或觀察者 | 2 GB（原有集群）；驗證者還需要同步的時鐘（時鐘） | 1 vCPU（原有集群大部分節點） | 使用 --prune-history 24h 時，約保留一天的區塊：chain 14 上實測區塊表為 3.3–4.4 GB；請保留超過 4 GB 的可用空間（磁碟） |
| 存檔節點（完整歷史） | 與驗證者相同 | 與驗證者相同 | 隨鏈增長：以 chain 14 的 18 簽名 QC、1.4 秒區塊計，實測約每日 3.6 GB；chain 18 至 20 的 QC 最多帶有 26 個簽名，開銷更大，但尚未重新測量；測試網的兩個存檔節點使用 250 GiB 的卷 |
| 構建主機 | 8 GB（節點 E） | 4 vCPU（節點 E） | 源代碼樹、target/，以及至少 20 GB 可用空間 |
| 證明者，屏蔽轉賬（tier 14） | chain 18 上轉賬峰值為 6.1 GB，連同支付交易包的調用為 6.1 至 6.6 GB（2026-09-30） | 一個核心；chain 18 上有兩個證明，tier-14 交易包證明需 102 至 134 秒，tier-10 授權證明需 7 至 23 秒（Apple Silicon 筆記本電腦，2026-09-30）；chain 14 上僅 4 入 4 出的隱藏資產交易包約需 100 秒；chain 13 的 2 入 2 出交易包在筆記本電腦上實測為 92.2–96.0 秒（正式版本，2026-09-19） | 小 |
| 委託證明者 | 同時運行的每個證明需 5.74 GB，另加 1 GiB 餘量；可用記憶體不足時拒絕啟動 | 每個證明一個核心 | 小 |
| 證明者，tier-18 調用（ERC-20；自 v0.5.6 起鏈上拒絕，見證明記憶體） | 85.0 GB（已轉譯的 transfer）/ 85.5 GB（解釋執行），在 m-16vcpu-128gb 上實測 | 一個核心 | 小 |
| 證明者，tier-20 調用（SPL Token；自 v0.5.6 起鏈上拒絕） | 尚未完成證明；推算約需 330 GB，超過 DigitalOcean 最大的記憶體型 droplet（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 節點 | 與驗證者相同 |
證明者目前是單線程的。 一台 16 vCPU 的 droplet 僅以單一核心 99% 的負載運行。更多核心無法加快單個證明；決定證明能否完成的，是記憶體的多寡。
驗證者與觀察者
記憶體與 CPU
最初的十八個驗證者運行於 2 GB 的 droplet 上。驗證一個證明的成本很低：
| 操作 | 成本 |
|---|---|
| 驗證一個交易包證明，驗證密鑰已預熱 | 約 16 毫秒 |
| 在新的形狀（shape）下首次驗證 | 約 230 毫秒 |
| 構建已部署程序的驗證密鑰（一次，在後台進行） | 在 2 vCPU 的伺服器上約 7 秒 |
| 驗證一個聚合證明（聚合啟用時） | 冷啟動約 0.8 秒，預熱後約 16 毫秒（設計數字） |
驗證者驗證 tier-18 或 tier-20 的調用證明所需的記憶體，現已部分測得：在一台 48 GB 的 Apple Silicon 筆記本電腦上測量，與生成各證明的 DigitalOcean droplet 相互獨立。驗證 tier-18 的 transfer 證明需 50.2 秒，RSS 峰值為 3.66 GB（已轉譯），或 49.6 秒（解釋器，RSS 未另行記錄）；驗證 tier-16 的 approve 證明需 12.2 秒（RSS 未另行記錄）。Tier 20 尚未測量，因為目前還沒有可供驗證的 tier-20 證明。自 v0.5.6 起，驗證者不會構建如此大的密鑰：在構建任何驗證密鑰之前，會先檢查調用證明的標頭；高於 tier 14 的調用（或 keccak 表大於 2^12、sha256 表大於 2^13 的調用）會被拒絕，在准入時如此，作為區塊有效性規則亦然。所測得最差的可准入調用標頭，驗證耗時 4.7 秒、佔用 312 MB。
1 vCPU、2 GB 的 droplet 無法構建二進制文件。請在較大的機器上構建，再複製過去（見設置）。
磁碟
| 數據 | 數值 | 來源 |
|---|---|---|
| v0.5.5 之前，chain 14 上一個空閒區塊 | blocks 中約 60 KB，加上 qcs 中約 49 KB：18 簽名的 Dilithium2 QC 被存儲兩次，以 1.4 秒區塊計約每日 6.6 GB | 2026-09-24 磁碟事故，AGENTS.md |
| v0.5.5 起的同一區塊 | 約 60 KB：已提交區塊的 QC 只存儲一次，位於其子區塊的 justify 中；以 1.4 秒區塊計約每日 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） | 區塊表 3.3–4.4 GB，原為 19 GB；磁碟使用率 18–37% | AGENTS.md，v0.5.7 |
| 節點 A 的數據目錄，chain 12，高度 62,276 | 約 10 GB | deploy/README.md，v0.3 部署 |
| 運行滿載區塊的鏈 | 每 2 秒 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（兩者同時也是驗證者）不使用該標誌運行。主網節點絕不使用該標誌。若數據目錄所在文件系統的可用空間低於 --min-free-disk-mb（默認 1,024 MB），節點拒絕啟動；可用空間低於該值的四倍時，rand_getHealth 會返回 disk_low；等待 ok 的滾動升級會在一個即將寫滿的節點上停止。已修剪的節點仍可回應哪些請求，見歷史修剪。
刪除已退役鏈的資料目錄,須在切換(cut-over)後進行。資料目錄以創世雜湊(genesis hash)作鍵(data-<name>-<hash8>:chain 20 為 -6210cf07,chain 19 為 -a3defc93;六台守護者(guardian)主機使用 /var/lib/randnode/data-20),因此舊目錄會一直保留,直至你將其移除。在 chain-20 切換時,一個區域驗證者(syd1)啟動後出現 disk_low,僅餘 3.9 GB 可用空間,並令啟動停留在 25 / 26,原因是 chain 14 至 17 的目錄仍留在該主機上;刪除這些目錄後釋出 22 GB。上一條鏈的目錄應保留一天,作為回滾目標,其後才移除。在區塊全滿時,自 chain 14 起每個原始 bundle 證明約為 1.42 MB(至 chain 13 約為 1.3 MB)。自 chain 17 起,每個 bundle 另附一份授權證明,因此一筆轉賬的證明合共約 2.85 MB:bundle 證明約 1.49 MB,授權證明約 1.36 MB(production profile,於 2026-09-29 量度)。聚合(aggregation)一旦啟用,會將已封存 bundle 的證明修剪至約 3 KB,除非節點以 --keep-raw-proofs 運行。授權證明不在此列,仍保持完整大小。
網絡
在公開節點上開放 TCP 30303 入站連接。處於 NAT 後的節點以 --bootstrap 主動連出。在 4 MiB 區塊全滿時,驗證者之間的連結約承載 2 MB/s。
時鐘
驗證者須使用 NTP。Chain 14 是首條將掛鐘時間(wall-clock time)納入共識的鏈(橋接加固 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)。觀察者(observer)不投票,因此投票規則對其不適用。
testnet 所用的 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) | 驗證者、編譯主機及 explorer |
此表涵蓋最初的十八個驗證者。自 2026-09-27 起,驗證者 A 亦運行於 droplet(sgp1),而非筆記型電腦。另有八個驗證者於 chain 15(2026-09-27)完成質押:兩個存檔節點 obs1 與 rand-archive-2(fra1),以及六台守護者主機。其 droplet 規格在此未有記錄,mkc1 與 mem1 是否已調整規格亦未有記錄。在 chain 20 上,全部 26 個均為創世驗證者,與 chain 19 相同,每個質押 1,000 RAND,且截至 2026-09-30,全部 26 條密鑰由同一個營運者持有。
證明記憶體
錢包會為其發出的每筆交易生成證明,因此程式的調用者需要具備該程式所屬層級(tier)所需的記憶體。以下為實測界限。Tier-18 的運行已在 DigitalOcean 上完成證明並通過驗證;tier-20 則尚未完成。自 v0.5.6 起,鏈會拒絕 tier 14 以上的調用證明(MAX_CALL_TIER),因此下列 tier-16、18 及 20 各行屬於量度結果,並非 chain 20 接納的調用;chain 14 上提交的每次調用均為 tier 10。
| 工作負載 | 層級 | 週期數 | 量度內容 | 需要 |
|---|---|---|---|---|
隱私轉賬(shielded transfer,bundle guest) | 14 | 在 chain 13 上約 9,160(2 入 2 出的 guest) | 在 Apple Silicon 筆記型電腦上為 92.2–96.0 s(production,chain 13,2026-09-19);未有記錄峰值記憶體。Chain 14 的 4 入 4 出隱藏資產 guest 固定於同一層級:約 100 s,證明約 1.42 MB。在 chain 20 上,一筆轉賬包含兩份證明(自 chain 17 起拆分授權):tier-14 的 bundle 證明,102 至 134 s,約 1.49 MB;以及 tier-10 的授權證明,7 至 23 s,約 1.36 MB。整筆交易的峰值記憶體為 6.1 至 6.6 GB(Apple Silicon 筆記型電腦,chain 18,2026-09-30) | 可在開發用筆記型電腦上運行 |
ERC-20 approve(production,於 chain 13,2026-09-19) | 16 | 48,119 | 調用證明 388.7 s,3,412,405 bytes;整個 rand call 為 622.8 s,在 48 GB M 系列筆記型電腦上峰值 RSS 為 22.9 GB | 48 GB 筆記型電腦 |
| ERC-20 調用 | 18 | 約 66k 至 162k | 第一階段的 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 bytes。於 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 小時(實測 tier-16/18 的比例:每增加 2 個層級,記憶體約 ×3.9,時間約 ×4.1)——超過 DigitalOcean 最大的記憶體型 droplet(m-32vcpu-256gb,256 GB) |
| rVM tier-21 production exit(在遞歸 VM 內驗證一份 bundle 證明) | 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)。在 48 GB 的機器上,尚未有 tier 18 或 20 的證明得以完成。
聚合者
聚合者(aggregator)監察區塊鏈,取得一個窗口內已最終確定區塊的 bundle 證明,對其證明一個遞歸聚合證明,並提交。包含該證明的區塊稱為封存區塊。聚合者會獲得所涵蓋 bundle 的證明份額,另加以新 RAND 發放的區塊補貼,支付至其登記的收款地址。聚合是無需許可的:任何持有質押的營運者均可登記。
此功能只存在於創世含有 aggregation 部分的鏈上。Chain 20 沒有該部分,其編譯版本會拒絕在含有該部分的創世上啟動。
硬件
| 聚合 | 主機 RAM | 後端 |
|---|---|---|
| N = 1 個 bundle | 至少 64 GB | CPU;test profile 在負載較重的筆記型電腦上約 26 分鐘證明一個(327,035 bytes) |
| 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 的數字是在一部 256 GB 的 DigitalOcean droplet 上於 2026-09-28/29 在約束集 7 下量度的,而生產環境的 exit 證明所需超過該機器的 256 GB。以上均未在約束集 8 下重新量度(chain 18 至 20 採用約束集 8),因此 N = 1 一行應視為下限。CUDA 後端於 2026-09-28 首次在真實硬件(NVIDIA H100)上運行:其 kernel 編譯為 sm_80 及 sm_90 的 PTX,並與 CPU 參考實現一致。在機群 GPU 節點上的生產環境量度仍待進行。每個節點亦須為聚合程式承擔一次性的啟動密鑰建構:test profile(2¹⁹)為 13.0 至 13.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 | 必填 | 登記冊所認可的聚合者密鑰;為每個聚合簽署 |
--rpc | http://127.0.0.1:8545 | 輪詢並提交聚合的節點 |
--watch | 關閉 | 持續輪詢,而非只提交一次 |
--interval-secs | 15 | 配合 --watch 時的輪詢間隔 |
--no-wait | 關閉 | 節點接受聚合後即返回 |
在這類鏈上,rand status 會顯示 aggregation 一節:已登記的聚合者、未封存的區塊,以及補貼時間表索引。rand_getUnsealed 即工作清單。
設置
以下步驟依循測試網所用的腳本(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 to鏈 20 要求每個節點在 init 之前先升級至 v0.6.8。 其創世區塊帶有早期版本均不讀取的欄位(testnet、binding_domain、proof_window_blocks、program_state、橋的 rotation 與 fees 組別、gas 上限、以投票方式准入的質押),而 v0.6.8 載有審計 v6 的 CON-4 與 CH-1 共識變更。證明仍依約束集 8 生成,與鏈 18 及 19 相同,每個捆綁證明旁附有一份授權證明(hc_auth)。v0.6.8 構建在 run 與 verify 時會拒絕鏈 14 至 17 的創世區塊。請使用機群所運行的同一構建。創世文件位於 fullnode 的 main(提交 74cfaca0),不在 v0.6.8 標籤之內,故有第三行 git。circuits 檢出目錄必須位於該版本所源自的提交,此提交由上文第二行 git 從 fullnode 目錄樹中讀出。加上 -p randprotocol-prover 可一併構建 rand-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 倉庫已不再追蹤任何密鑰(審計 v3,OPS-1)。為鏈 8 至 13 提交的 deploy/node-*.key.json 文件是已公開的種子;鏈 20 的驗證節點密鑰(為鏈 14 生成的十八個,以及在鏈 15 上綁定的八個)均在倉庫之外生成,機群將每個 droplet 的密鑰存放於 /root/keys/node-<name>.key.json,位於源碼目錄樹之外。對於由機群腳本配置的節點,此位置至關重要:deploy/rebuild-vps.sh 與 deploy/push-to-vps.sh 以 --delete 對 /root/fullnode 進行 rsync,因此存放於該目錄樹內的密鑰會在下一次重建時被刪除,服務單元隨後便無法重新啟動。自 v0.6.8 起,keygen 拒絕覆寫既有文件(v0.6.7 會不經詢問直接覆寫);test -e 使該行無論如何重複運行都是安全的。綁定密鑰之前,請先在主機以外備份。
init 會印出創世哈希,必須為 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135(鏈 20)。創世文件為 fullnode 倉庫 main 分支 deploy/ 下的 genesis-chain20.json。數據目錄請依機群做法,以哈希的前八個字符命名(data-<name>-6210cf07),使其不會與鏈 19 的(-a3defc93)或之後任何鏈的相衝突。創世區塊設定了以下限制。證明大小上限在鏈 13 至 16 為 8 MiB,自鏈 17 起為 4 MiB,因為由該鏈起一筆交易最多可攜帶三份證明:
| 限制 | 鏈 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(每個票據信封,連同其加密備註欄) |
proof_window_blocks | 1,024(鏈 19 為 256) |
program_state | 單元費用 0.1 RAND(10,000,000 單位);每次調用最多 8 次讀取、8 次寫入及 4 次支付 |
aggregation 一節 | 無(聚合關閉) |
鏈 20 的創世區塊還帶有 consensus_domain: 1、binding_domain: 1、testnet: true、設有投票准入的 staking 一節、設有價格上限的 gas 一節、橋的 rotation 與 fees 組別、hardening_v6,以及兩個訪客程式釘選 hc_bundle 與 hc_auth;運行節點列出了它們所設定的內容。
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 是測試網驗證節點(存檔節點除外)所運行的設定;若節點需保留完整歷史,請去掉此項,在 mainnet-beta 上則絕不可傳入。鏈 20 的引導 multiaddr 為節點 C(fra1)、D(ric1)和 E(sgp1),與鏈 19 相同。鏈 20 運行於為鏈 14 生成的驗證節點密鑰之上,而 p2p 身份由驗證節點密鑰派生,因此這些對等節點 id 即鏈 14 所用的 id。從創世區塊開始同步的新節點還需要一個保存完整歷史的對等節點,故請加入兩個存檔節點之一(先 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. 加入驗證者集合
新密鑰不在任何紀元的集合之中。在鏈 20 上,它必須先被投票准入:其創世區塊設定了 staking.admission_by_vote,因此持有超過三分之二投票權重的驗證節點各自以 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 印出登記資料(鏈 20 拒絕 v1 登記),再從錢包以 rand bond <address> 1000 --registration <hex> 進行綁定。綁定須等待其生效紀元,最早為提交後的第三個 1,000 區塊邊界,且每個邊界成為新權重的部分最多為活躍權重的 2,500 bps(鏈 19 則限定為固定的 10,000 RAND)。質押對此有逐步說明。
6. 更新
本節適用於運行同一條鏈的構建。由較早的鏈遷移至鏈 20 並不屬於更新:它需要新的二進制文件、新的創世區塊及全新的數據目錄,舊鏈的數據目錄其後可以刪除(deploy/retire-chain-dirs.sh;機群會保留一天以供回滾)。若要在不切換鏈的情況下推出新構建,請構建一次,比對 rand-node 與 rand 兩者的 sha256,停止服務,安裝,然後重新啟動,一次一個節點。部分版本採取全部停止、全部啟動的方式推出(v0.5.6 的調用層級規則、v0.5.7 的 Status 線上格式變更、v0.6 更嚴格的證明驗證);各版本的發布說明會註明採用何種方式。v0.6.7 以一次一個節點的方式推出至鏈 18;v0.6.8 隨鏈 20 而來,採全部停止、全部啟動,因為其 CON-4 與 CH-1 共識變更絕不可逐節點滾動推出。請等待每個節點重新加入後再處理下一個,使法定人數永不短缺多於一個節點。deploy/update-droplet.sh <ip> [build-host] 正是透過 SSH 執行此流程。
v0.6.8 及之前的版本均由一台主機手動構建,且未經簽署。v0.6.8 的 GitHub 發行版帶有 rand-node、rand、rand-prover 與 SHA256SUMS,於節點 E 上構建;該校驗和可發現下載損毀,但不能為構建主機作擔保。v0.6.8 附帶一個由標籤構建二進制文件的發布工作流程,而 deploy/update-droplet.sh 除非設定 ALLOW_UNSIGNED=1,否則會拒絕安裝沒有已簽署 SHA256SUMS 的版本。deploy/release-signers 尚未列出任何密鑰,故已簽署的途徑至今未被使用。
鏈 15、16、17 與 18 在 2.7 天內(2026-09-26 至 2026-09-29)相繼上線,每次均為機群全部停止。鏈 19 於 2026-10-01 03:43 UTC 隨後上線,是在同一構建上對鏈 18 重新生成創世區塊;鏈 20 則於同日 06:17 UTC 上線,在 v0.6.8 硬分叉處由鏈 19 的快照切出;每個節點均在鏈 19 區塊高度 7,700 停止。一份書面的切換政策(2026-09-30)自鏈 20 起適用;鏈 20 的切換紀錄豁免了第二位運營者的重建,因為所有密鑰均由一位運營者持有。切換須具備:滾動更新無法滿足的理由、一份公開的所載內容與所棄內容清單、事先完成的客戶端重建清單、由第二位運營者將創世區塊重建至相同哈希、回滾計劃,以及從未使用過的鏈 id。