راه‌اندازی validator و aggregator

برای اندازه‌گیری ظرفیت یک ماشین، پیش از راه‌اندازی آن از این صفحه استفاده کنید. اعتبارسنج ارزان است، اما اثبات‌سازی ارزان نیست: حافظهٔ لازم برای یک اثبات با افزایش tier آن به‌شدت بالا می‌رود و همین یک عدد تعیین می‌کند که ماشین از عهدهٔ کار برمی‌آید یا نه. همهٔ ارقام این صفحه اندازه‌گیری‌هایی از testnet یا ثبت‌های fullnode هستند. ارقامی که نهایی نیستند مشخص شده‌اند.

هر نقش چه می‌کند

اعتبارسنج‌ها و ناظرها هرگز اثبات نمی‌سازند. انتقال shielded یا یک فراخوانی را کیف پولی که آن را می‌فرستد اثبات می‌کند، یا، فقط برای اثبات بسته، اثبات‌کننده‌ای که آن کیف پول با آن جفت شده است (اجرای یک نود). اعتبارسنج‌های fleet امروز هیچ اثباتی نمی‌سازند.

تجمیع بلاک ساخته شده اما فعال نیست. به بخش aggregation در genesis نیاز دارد. chain 20 چنین بخشی ندارد: تجمیع خاموش است، مانند chainهای 9 تا 19، و build از شروع روی genesisی که این بخش را داشته باشد خودداری می‌کند.

اندازه‌گذاری در یک نگاه

اثبات‌کننده امروز تک‌نخی است. یک droplet با 16 vCPU روی 99% از یک هسته اجرا شد. هسته‌های بیشتر یک اثبات را سریع‌تر نمی‌کنند؛ RAM بیشتر است که تعیین می‌کند اثبات به پایان می‌رسد یا نه.

اعتبارسنج‌ها و ناظرها

حافظه و CPU

هجده اعتبارسنج اصلی روی dropletهای 2 GB اجرا می‌شوند. تأیید یک اثبات ارزان است:

حافظه‌ای که اعتبارسنج برای تأیید اثبات فراخوانی tier-18 یا tier-20 لازم دارد اکنون تا حدی اندازه‌گیری شده است، روی یک لپ‌تاپ Apple-silicon با 48 GB و مستقل از droplet DigitalOceanی که هر اثبات را ساخته بود: تأیید اثبات transfer در tier-18 برابر 50.2 s با اوج RSS برابر 3.66 GB طول کشید (ترجمه‌شده) یا 49.6 s (مفسر، RSS جداگانه ثبت نشد)؛ تأیید اثبات approve در tier-16 برابر 12.2 s طول کشید (RSS جداگانه ثبت نشد). tier 20 اندازه‌گیری نشده است — هنوز هیچ اثبات tier-20 برای تأیید وجود ندارد. از v0.5.6 اعتبارسنج هرگز چنین کلید بزرگی نمی‌سازد: سرآیند اثبات فراخوانی پیش از ساخت هر کلید تأییدکننده بررسی می‌شود، و فراخوانی بالاتر از tier 14 (یا با جدول keccak بالاتر از 2^12، یا جدول sha256 بالاتر از 2^13) هم هنگام پذیرش و هم به‌عنوان قاعدهٔ اعتبار بلاک رد می‌شود. بدترین سرآیند فراخوانیِ قابل‌پذیرش که اندازه‌گیری شد، برای تأیید 4.7 s و 312 MB لازم داشت.

یک droplet با 1 vCPU و 2 GB نمی‌تواند فایل‌های اجرایی را بسازد. روی ماشین بزرگ‌تری build کنید و آن‌ها را کپی کنید (نک. راه‌اندازی).

دیسک

در chain 20، مانند chain 19، 24 اعتبارسنج از 26 اعتبارسنج با --prune-history 24h اجرا می‌شوند و حدود یک روز بلاک نگه می‌دارند؛ خود دفتر کل (نوت‌ها، نولیفایرها، anchorها، رجیستر) هرگز هرس نمی‌شود. آرشیوها، obs1 و rand-archive-2 (هر دو اعتبارسنج هم هستند)، بدون این پرچم اجرا می‌شوند. نود mainnet هرگز آن را نمی‌گیرد. نود با کمتر از --min-free-disk-mb (به‌طور پیش‌فرض 1,024 MB) فضای خالی روی فایل‌سیستم دایرکتوری داده‌هایش شروع نمی‌شود، و rand_getHealth زیر چهار برابر آن مقدار disk_low برمی‌گرداند؛ roll که منتظر ok می‌ماند، در نودی که در حال پر شدن است متوقف می‌شود. برای اینکه نود هرس‌شده هنوز به چه چیزهایی پاسخ می‌دهد، هرس تاریخچه را ببینید.

پس از انتقال به زنجیرهٔ جدید، پوشهٔ داده‌های زنجیرهٔ بازنشسته را حذف کنید. پوشه‌های داده بر اساس هش genesis نام‌گذاری می‌شوند (data-<name>-<hash8>: -6210cf07 برای زنجیرهٔ 20 و -a3defc93 برای زنجیرهٔ 19؛ شش میزبان guardian از /var/lib/randnode/data-20 استفاده می‌کنند)، بنابراین پوشه‌های قدیمی تا زمانی که حذفشان نکنید باقی می‌مانند. هنگام انتقال به زنجیرهٔ 20، یکی از اعتبارسنج‌های منطقه‌ای (syd1) با 3.9 GB فضای آزاد در وضعیت disk_low بالا آمد و راه‌اندازی را روی 25 از 26 نگه داشت، چون پوشه‌های زنجیره‌های 14 تا 17 هنوز روی آن بودند؛ حذف آن‌ها 22 GB آزاد کرد. پوشهٔ زنجیرهٔ قبلی را یک روز به‌عنوان هدف بازگشت نگه دارید و سپس حذفش کنید. در بلوک‌های پر، اثبات خام هر bundle از زنجیرهٔ 14 به بعد حدود 1.42 MB است (تا زنجیرهٔ 13 حدود 1.3 MB بود). از زنجیرهٔ 17 هر bundle یک اثبات احراز مجوز نیز دارد، پس یک انتقال حدود 2.85 MB اثبات دارد: حدود 1.49 MB برای اثبات bundle و 1.36 MB برای اثبات احراز مجوز (پروفایل production، اندازه‌گیری‌شده در 2026-09-29). تجمیع، پس از فعال شدن، اثبات یک bundle مهرشده را به حدود 3 KB هرس می‌کند، مگر اینکه گره با --keep-raw-proofs اجرا شود. این هرس اثبات احراز مجوز را شامل نمی‌شود و آن با اندازهٔ کامل باقی می‌ماند.

شبکه

پورت TCP 30303 را برای ورودی در یک گرهٔ عمومی باز کنید. گره‌هایی که پشت NAT هستند با --bootstrap به بیرون وصل می‌شوند. در بلوک‌های کامل 4 MiB، هر پیوند اعتبارسنج حدود 2 MB/s عبور می‌دهد.

ساعت

اعتبارسنج به NTP نیاز دارد. زنجیرهٔ 14 نخستین زنجیره‌ای است که در آن زمان ساعت دیواری بخشی از اجماع است (سخت‌سازی پل B2):

اعتبارسنجی که ساعتش 20 s عقب است بی‌صدا از رأی دادن بازمی‌ماند: هر بلوک درست را جلوتر از ساعت خود می‌بیند و رأیش را نگه می‌دارد، و هیچ خطایی رخ نمی‌دهد. در زنجیرهٔ 20، برای commit شدن هر چیز باید هجده از بیست‌وشش اعتبارسنج رأی بدهند. هر اعتبارسنج را بررسی کنید و هر جا ساعت همگام نیست، 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 برای genesis هم اعمال می‌شود. timestamp_ms را نزدیک زمان راه‌اندازی تنظیم کنید و هرگز جلوتر از آن نگذارید: genesis ای که بیش از 15 s در آینده باشد تا رسیدن زمان دیواری به آن هیچ بلوک 1 را commit نمی‌کند، و genesis ای که خیلی در گذشته باشد زمان بلوک را عقب‌تر از ساعت دیواری می‌گذارد و این فاصله را با حداکثر 60 s در هر بلوک جبران می‌کند (docs/deploy.md). ناظر (observer) رأی نمی‌دهد، پس قاعدهٔ رأی آن را مقید نمی‌کند.

اندازه‌های DigitalOcean که testnet روی آن‌ها اجرا می‌شود

این جدول هجده اعتبارسنج اولیه را پوشش می‌دهد. از 2026-09-27 اعتبارسنج A نیز روی یک droplet اجرا می‌شود (sgp1)، نه یک لپ‌تاپ. هشت اعتبارسنج دیگر روی زنجیرهٔ 15 bond شدند (2026-09-27): دو آرشیو، obs1 و rand-archive-2 (fra1)، و شش میزبان guardian. اندازهٔ droplet این‌ها اینجا ثبت نشده است، و همچنین اینکه آیا اندازهٔ mkc1 و mem1 تغییر کرده است یا نه. هر 26 اعتبارسنج در زنجیرهٔ 20 اعتبارسنج genesis هستند، مانند زنجیرهٔ 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 در زیر اندازه‌گیری‌اند، نه فراخوانی‌هایی که زنجیرهٔ 20 بپذیرد؛ هر فراخوانی commit شده در زنجیرهٔ 14 از tier 10 بود.

فراخوانی‌های ERC-20 در tier‌های 16 و 18 و SPL Token در tier 20 قرار می‌گیرند (Ethereum، Solana). هیچ اثباتی در tier 18 یا 20 روی ماشین 48 GB ساخته نشده است.

تجمیع‌کننده‌ها

تجمیع‌کننده زنجیره را زیر نظر می‌گیرد، اثبات‌های bundle پنجره‌ای از بلوک‌های نهایی‌شده را برمی‌دارد، یک اثبات تجمیعی بازگشتی روی آن‌ها می‌سازد و آن را ارسال می‌کند. بلوکی که آن را شامل می‌شود بلوک مهرکننده است. تجمیع‌کننده سهم اثبات bundleهای پوشش‌داده‌شده را به‌علاوهٔ یارانهٔ بلوک به‌صورت RAND تازه، به نشانی پرداخت ثبت‌شده‌اش دریافت می‌کند. تجمیع بدون مجوز است: هر اپراتوری که bond داشته باشد می‌تواند ثبت‌نام کند.

این قابلیت فقط روی زنجیره‌ای وجود دارد که genesis آن بخش aggregation دارد. زنجیرهٔ 20 چنین بخشی ندارد، و build آن از شروع روی genesis ای که چنین بخشی داشته باشد خودداری می‌کند.

سخت‌افزار

اعداد N = 2 و N = 3 روی یک droplet با 256 GB در DigitalOcean در 2026-09-28/29 و زیر constraint set 7 اندازه‌گیری شدند، و اثبات خروج production بیش از 256 GB آن ماشین لازم داشت. هیچ‌کدام زیر constraint set 8 که زنجیره‌های 18 تا 20 اجرا می‌کنند دوباره اندازه‌گیری نشده‌اند، پس ردیف N = 1 را حد پایین بدانید. backend CUDA نخستین‌بار در 2026-09-28 روی سخت‌افزار واقعی، یک NVIDIA H100، اجرا شد: kernelهایش برای sm_80 و sm_90 به PTX build می‌شوند و با مرجع CPU یکسان‌اند. اندازه‌گیری production روی یک گرهٔ GPU ناوگان هنوز باقی است. هر گره همچنین یک بار هنگام راه‌اندازی هزینهٔ ساخت کلید برنامهٔ تجمیع را می‌پردازد: 13.0 تا 13.4 s در پروفایل آزمایشی (2¹⁹)، و در production انتظار می‌رود 30 تا 70 s (2²¹).

فرمان‌ها

# 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:8545

rand status در چنین زنجیره‌ای یک بخش aggregation نشان می‌دهد: aggregatorهای ثبت‌شده، بلوک‌های مهر‌نشده و اندیس جدول یارانه. rand_getUnsealed فهرست کار است.

راه‌اندازی

این مراحل از اسکریپت‌هایی پیروی می‌کنند که testnet به کار می‌برد (deploy/vps-setup.sh، deploy/update-droplet.sh). نتیجه یک validator یا observer روی Linux است.

۱. ساخت روی یک میزبان ساخت

ساخت به build-essential clang cmake pkg-config libssl-dev، Rust 1.98.1 (که rust-toolchain.toml تثبیت می‌کند) و یک checkout از circuits در کنار checkout مربوط به fullnode نیاز دارد. نخستین ساخت ۱۰ تا ۲۰ دقیقه طول می‌کشد.

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

زنجیرهٔ ۲۰ پیش از init به v0.6.8 روی هر گره نیاز دارد. genesis آن فیلدهایی دارد که هیچ ساخت قبلی نمی‌خواند (testnet، binding_domain، proof_window_blocks، program_state، گروه‌های rotation و fees در bridge، سقف‌های gas، پذیرش staking با رأی)، و v0.6.8 تغییرات اجماع CON-4 و CH-1 از audit v6 را در خود دارد. اثبات‌ها همچنان تحت مجموعهٔ قیود ۸ تولید می‌شوند، مانند زنجیره‌های ۱۸ و ۱۹، و در کنار هر اثبات bundle یک اثبات مجوز (hc_auth) وجود دارد. ساخت v0.6.8 در run و verify genesis زنجیره‌های ۱۴ تا ۱۷ را رد می‌کند. همان یک ساختی را اجرا کنید که ناوگان اجرا می‌کند. فایل genesis روی شاخهٔ main در fullnode قرار دارد (کامیت 74cfaca0) و در تگ v0.6.8 نیست؛ به همین دلیل خط سوم git لازم است. checkout مربوط به circuits باید در کامیتی باشد که انتشار از آن vendor شده است و خط دوم git در بالا آن را از درخت fullnode می‌خواند. برای ساخت rand-prover نیز -p randprotocol-prover را اضافه کنید.

۲. نصب باینری‌ها روی گره

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/'

۳. کلید، genesis، فایروال

روی گره:

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

کلید را همان‌طور که در بالا آمده روی خود گره تولید کنید و آن را از هر checkout دور نگه دارید. دیگر هیچ کلیدی در مخزن fullnode ردیابی نمی‌شود (audit v3، OPS-1). فایل‌های deploy/node-*.key.json که برای زنجیره‌های ۸ تا ۱۳ کامیت شده‌اند seedهای منتشرشده‌اند؛ کلیدهای validator زنجیرهٔ ۲۰ (هجده کلید تولیدشده برای زنجیرهٔ ۱۴ و هشت کلیدی که روی زنجیرهٔ ۱۵ bond شدند) خارج از مخزن تولید شدند و ناوگان کلید هر droplet را در /root/keys/node-<name>.key.json و بیرون از درخت سورس نگه می‌دارد. محل کلید روی گره‌ای که با اسکریپت‌های ناوگان آماده شده اهمیت دارد: deploy/rebuild-vps.sh و deploy/push-to-vps.sh مسیر /root/fullnode را با --delete rsync می‌کنند، بنابراین کلیدی که داخل آن درخت باشد با ساخت مجدد بعدی حذف می‌شود و سپس unit نمی‌تواند دوباره راه‌اندازی شود. از v0.6.8 به بعد keygen از بازنویسی فایل موجود خودداری می‌کند (v0.6.7 بدون پرسش آن را بازنویسی می‌کرد)؛ test -e در هر دو حالت اجرای مجدد آن خط را ایمن نگه می‌دارد. پیش از bond کردن کلید، از آن بیرون از میزبان نسخهٔ پشتیبان بگیرید.

init هش genesis را چاپ می‌کند. باید 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 (زنجیرهٔ ۲۰) باشد. فایل genesis با نام genesis-chain20.json در deploy/ مخزن fullnode روی main قرار دارد. دایرکتوری داده را مانند ناوگان با هشت نویسهٔ نخست هش نام‌گذاری کنید (data-<name>-6210cf07) تا هرگز با دایرکتوری زنجیرهٔ ۱۹ (-a3defc93) یا زنجیره‌ای بعدی تداخل نکند. genesis این محدودیت‌ها را تعیین می‌کند. سقف اثبات در زنجیره‌های ۱۳ تا ۱۶ برابر 8 MiB بود و از زنجیرهٔ ۱۷ به بعد 4 MiB است، یعنی از زمانی که یک تراکنش می‌تواند تا سه اثبات حمل کند:

genesis زنجیرهٔ ۲۰ همچنین consensus_domain: 1، binding_domain: 1، testnet: true، بخش staking با پذیرش از راه رأی، بخش gas با سقف قیمت، گروه‌های rotation و fees در bridge، hardening_v6 و دو pin مهمان hc_bundle و hc_auth را دارد؛ اجرای یک گره آنچه را این‌ها تعیین می‌کنند فهرست کرده است.

۴. یک unit از systemd

این همان unit است که 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

برای observer، --validator را حذف کنید. --prune-history 24h همان چیزی است که validatorهای testnet اجرا می‌کنند، به‌جز archiveها؛ برای گرهی که تاریخچهٔ کامل را نگه می‌دارد آن را حذف کنید و هرگز آن را روی mainnet به کار نبرید. multiaddrهای bootstrap برای زنجیرهٔ ۲۰ گره‌های C (fra1)، D (ric1) و E (sgp1) هستند، بدون تغییر نسبت به زنجیرهٔ ۱۹. زنجیرهٔ ۲۰ روی کلیدهای validator تولیدشده برای زنجیرهٔ ۱۴ اجرا می‌شود و هویت p2p از کلید validator مشتق می‌شود، پس این peer idها همان‌هایی‌اند که زنجیرهٔ ۱۴ به کار می‌برد. گرهٔ تازه‌ای که از genesis همگام می‌شود به یک peer با تاریخچهٔ کامل هم نیاز دارد، پس یکی از دو archive را (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). unit منتقل‌شده از 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 rising

۵. پیوستن به مجموعهٔ validator

کلید تازه در مجموعهٔ هیچ epoch نیست. در زنجیرهٔ ۲۰ ابتدا باید به آن رأی داده شود: genesis آن staking.admission_by_vote را تنظیم می‌کند، پس validatorهایی که بیش از دوسوم وزن رأی را در اختیار دارند هر یک آن را با 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 برای آن bond کنید: یک registration را با rand-node register --key /root/keys/node.key.json --payout rand1… --v2 چاپ کنید (زنجیرهٔ ۲۰ registration نسخهٔ v1 را رد می‌کند)، سپس از یک wallet با rand bond <address> 1000 --registration <hex> bond کنید. bond منتظر epoch فعال‌سازی خود می‌ماند، دست‌کم سه مرز ۱,۰۰۰ بلوکی پس از commit شدن آن، و در هر مرز حداکثر 2,500 bps از وزن فعال به وزن جدید تبدیل می‌شود (زنجیرهٔ ۱۹ آن را روی 10,000 RAND ثابت محدود می‌کرد). Staking آن را گام‌به‌گام شرح می‌دهد.

۶. به‌روزرسانی

این بخش دربارهٔ ساختی است که همان زنجیره را اجرا می‌کند. گذار از زنجیره‌ای قدیمی‌تر به زنجیرهٔ ۲۰ به‌روزرسانی نیست: باینری تازه، genesis تازه و دایرکتوری دادهٔ نو می‌خواهد و دایرکتوری دادهٔ زنجیرهٔ قدیمی پس از آن قابل حذف است (deploy/retire-chain-dirs.sh؛ ناوگان آن را برای بازگشت یک روز نگه می‌دارد). برای انتشار یک ساخت تازه بدون برش زنجیره، یک بار بسازید، sha256 هر دو rand-node و rand را مقایسه کنید، سرویس را متوقف کنید، نصب کنید و دوباره راه بیندازید، هر بار یک گره. برخی انتشارها به‌جای آن به‌صورت توقف همگانی و راه‌اندازی همگانی اعمال می‌شوند (قاعدهٔ call-tier در v0.5.6، تغییر wire در Status در v0.5.7، راستی‌آزمایی سخت‌گیرانه‌تر اثبات در v0.6)؛ یادداشت‌های هر انتشار می‌گوید کدام‌یک. v0.6.7 هر بار یک گره روی زنجیرهٔ ۱۸ اعمال شد؛ v0.6.8 همراه زنجیرهٔ ۲۰ و به‌صورت توقف همگانی و راه‌اندازی همگانی آمد، زیرا تغییرات اجماع 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 ساخته شده‌اند؛ این checksum دانلود خراب را آشکار می‌کند و از میزبان ساخت تضمینی نمی‌دهد. v0.6.8 یک workflow انتشار دارد که باینری‌ها را از تگ می‌سازد، و deploy/update-droplet.sh نصب بدون SHA256SUMS امضاشده را رد می‌کند، مگر آنکه ALLOW_UNSIGNED=1 تنظیم شده باشد. deploy/release-signers هنوز هیچ کلیدی فهرست نکرده است، پس مسیر امضاشده تاکنون به کار نرفته است.

زنجیره‌های ۱۵، ۱۶، ۱۷ و ۱۸ ظرف 2.7 روز (از 2026-09-26 تا 2026-09-29) فعال شدند، هر یک با توقف همگانی ناوگان. زنجیرهٔ ۱۹ در 2026-10-01 ساعت 03:43 UTC آمد، یک re-genesis از زنجیرهٔ ۱۸ روی همان ساخت، و زنجیرهٔ ۲۰ در همان روز ساعت 06:17 UTC، که از یک snapshot زنجیرهٔ ۱۹ در hard fork مربوط به v0.6.8 بریده شد؛ هر گره در ارتفاع 7,700 زنجیرهٔ ۱۹ متوقف شد. یک سیاست مکتوب برش (2026-09-30) از زنجیرهٔ ۲۰ به بعد اعمال می‌شود؛ رکورد برش زنجیرهٔ ۲۰ ساخت مجدد توسط اپراتور دوم را معاف کرد، چون یک اپراتور همهٔ کلیدها را در اختیار دارد. یک برش به دلیلی نیاز دارد که به‌روزرسانی تدریجی نتواند برآورده کند، فهرستی منتشرشده از آنچه حمل می‌کند و آنچه حذف می‌کند، یک چک‌لیست ساخت مجدد کلاینت که از پیش انجام شده باشد، اپراتور دومی که genesis را بازسازی کند و به همان هش برسد، یک برنامهٔ بازگشت، و یک شناسهٔ زنجیره که پیش‌تر هرگز به کار نرفته باشد.