دا پاڼه وکاروئ ترڅو د چلولو دمخه د ماشین اندازه وټاکئ. تاییدکوونکی ارزانه دی. ثبوت جوړول داسې نه دي: د یوه ثبوت حافظه د هغه له کچې سره په چټکۍ لوړېږي، او همدا هغه یوازینۍ شمېره ده چې پرېکړه کوي چې آیا یو ماشین دا کار ترسره کولی شي که نه. دلته هره شمېره له testnet یا د fullnode له ثبتونو څخه اندازه شوې ده. هغه شمېرې چې وروستۍ نه دي، نښه شوې دي.
هر رول څه کوي
| رول | څه کوي | چلوي | ثبوت جوړوي؟ |
|---|---|---|---|
| تاییدکوونکی | راکړې ورکړې ترتیبوي، په هر بلاک کې هر ثبوت تصدیقوي، په 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 | نه |
تاییدکوونکي او څارونکي هېڅکله ثبوت نه جوړوي. یو پټ لېږد یا یوه غوښتنه د هغې بټوې له خوا ثابتېږي چې یې لېږي، یا، یوازې د بنډل ثبوت لپاره، د هغه ثبوتوونکي له خوا چې دا بټوه ورسره جوړه شوې ده (د نوډ چلول). د بېړۍ تاییدکوونکي نن ورځ هېڅ شی نه ثابتوي.
د بلاکونو راټولول جوړ شوي خو فعال نه دي. دې ته په genesis کې د aggregation برخې اړتیا ده. chain 20 دا برخه نه لري: راټولول بند دي، لکه په chains 9 تر 19 کې، او جوړونه په هغه genesis چې دا برخه ولري له پیل کولو انکار کوي.
په یوه کتنه کې اندازه
| رول | RAM | CPU | ډیسک |
|---|---|---|---|
| تاییدکوونکی یا څارونکی | 2 GB (لومړنۍ بېړۍ)؛ تاییدکوونکي ته همغږي شوې ساعت هم اړین دی (ساعت) | 1 vCPU (د لومړنۍ بېړۍ ډېری) | د --prune-history 24h سره، د شاوخوا یوې ورځې بلاکونه: په chain 14 کې د بلاک جدولونه 3.3–4.4 GB اندازه شوي؛ له 4 GB څخه ډېر خالي ځای وساتئ (ډیسک) |
| آرشیف (بشپړ تاریخ) | د تاییدکوونکي په څېر | د تاییدکوونکي په څېر | له زنځیر سره لویږي: د chain 14 د 18-لاسلیکه QCs لپاره په 1.4 s بلاکونو کې شاوخوا 3.6 GB په ورځ اندازه شوي، په chains 18 تر 20 کې ډېر، چې QCs یې تر 26 لاسلیکونو پورې لري، او دا بیا نه دي اندازه شوي؛ د 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 تر 134 s کې او د کچې 10 د اجازې ثبوت په 7 تر 23 s کې (Apple Silicon لپ ټاپ، 2026-09-30)؛ په chain 14 کې یوازې د 4-in-4-out پټې شتمنۍ بنډل لپاره شاوخوا 100 s؛ د chain 13 د 2-in-2-out بنډل لپاره په یوه لپ ټاپ کې 92.2–96.0 s اندازه شوي (تولید، 2026-09-19) | کوچنی |
| سپارل شوی ثبوتوونکی | د هر هغه ثبوت لپاره چې په یو وخت کې یې چلوي 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 تر ټولو لوی حافظه لرونکي 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% کې چلېده. ډېر کورونه یو ثبوت نه چټکوي؛ ډېر RAM پرېکړه کوي چې آیا پای ته رسېږي که نه.
تاییدکوونکي او څارونکي
حافظه او CPU
لومړني اتلس تاییدکوونکي په 2 GB droplets چلېږي. د یوه ثبوت تصدیق ارزانه دی:
| عملیات | لګښت |
|---|---|
| د بنډل ثبوت تصدیق، ګرمه تصدیقوونکې کیلي | شاوخوا 16 ms |
| په نوي شکل کې لومړی تصدیق | شاوخوا 230 ms |
| د ځای پر ځای شوي پروګرام د تصدیقوونکې کیلي جوړول (یو ځل، په شالید کې) | په 2-vCPU سرور کې شاوخوا 7 s |
| د یوه راټول شوي ثبوت تصدیق (کله چې راټولول فعال وي) | شاوخوا 0.8 s سوړ، شاوخوا 16 ms ګرم (د ډیزاین شمېرې) |
هغه حافظه چې یو تاییدکوونکی یې د کچې 18 یا کچې 20 د غوښتنې ثبوت د تصدیق لپاره اړتیا لري، اوس په یوه 48 GB Apple-silicon لپ ټاپ کې، د هغه DigitalOcean droplet څخه په خپلواک ډول چې هر ثبوت یې جوړ کړی، په برخه ییز ډول اندازه شوې ده: د کچې 18 د transfer ثبوت تصدیق په 3.66 GB لوړه RSS کې 50.2 s ونیول (ژباړل شوی) یا 49.6 s (مفسر، RSS جلا نه دی ثبت شوی)؛ د کچې 16 د approve ثبوت تصدیق 12.2 s ونیول (RSS جلا نه دی ثبت شوی). کچه 20 نه ده اندازه شوې — تر اوسه د کچې 20 هېڅ ثبوت نشته چې تصدیق شي. له v0.5.6 راهیسې یو تاییدکوونکی هېڅکله دومره لویه کیلي نه جوړوي: د یوې غوښتنې د ثبوت سرلیک د هرې تصدیقوونکې کیلي له جوړېدو دمخه کتل کېږي، او له کچې 14 پورته غوښتنه (یا د 2^12 څخه پورته keccak جدول، یا د 2^13 څخه پورته sha256 جدول لرونکې غوښتنه) د منلو پر مهال او د بلاک د اعتبار د قاعدې په توګه ردېږي. تر ټولو بد د منلو وړ د غوښتنې سرلیک د تصدیق لپاره 4.7 s او 312 MB اندازه شو.
یو 1-vCPU، 2 GB droplet باینري فایلونه نشي جوړولی. په یوه لوی ماشین یې جوړ کړئ او کاپي یې کړئ (جوړښت وګورئ).
ډیسک
| شمېره | ارزښت | سرچینه |
|---|---|---|
| د chain 14 یو بېکاره بلاک، له v0.5.5 دمخه | په 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 |
د chain 14 یو تاییدکوونکی وروسته له دې چې --prune-history 24h تش شو (2026-09-25) | د بلاک جدولونه 3.3–4.4 GB، له 19 GB څخه؛ ډیسکونه 18–37% کارول شوي | AGENTS.md، v0.5.7 |
| د node A د معلوماتو لارښود، chain 12 په 62,276 لوړوالي کې | شاوخوا 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 چلوي او د شاوخوا یوې ورځې بلاکونه ساتي؛ پخپله لیجر (یادښتونه، nullifiers، anchors، راجستر) هېڅکله نه پرې کېږي. آرشیفونه، obs1 او rand-archive-2 (دواړه تاییدکوونکي هم دي)، پرته له دې بیرغ څخه چلېږي. د mainnet نوډ هېڅکله دا نه ورکوي. نوډ له پیل کولو انکار کوي که د هغه د معلوماتو د لارښود په فایل سیسټم کې له --min-free-disk-mb (په ډیفالټ ډول 1,024 MB) څخه کم خالي ځای وي، او rand_getHealth له دې څلور چنده څخه کم کې disk_low ځواب ورکوي؛ هغه رول چې پر ok انتظار باسي، په هغه نوډ کې درېږي چې ډکېږي. د دې لپاره چې پرې شوی نوډ لا هم څه ځوابوي، د تاریخ پرې کول وګورئ.
پر یوه زنځیر له لېږد وروسته، د تقاعد شوي زنځیر د معلوماتو لارښود ړنګ کړئ. د معلوماتو لارښودونه د جنیسس په هش کلیدي شوي دي (data-<name>-<hash8>: د زنځیر 20 لپاره -6210cf07، د زنځیر 19 لپاره -a3defc93؛ شپږ ساتونکي کوربه /var/lib/randnode/data-20 کاروي)، نو زاړه لارښودونه تر هغه پاتې کېږي چې تاسو یې لرې کړئ. د زنځیر 20 په لېږد کې یو سیمهییز تاییدوونکی (syd1) د 3.9 GB خالي ځای سره په disk_low حالت کې راپورته شو او پیل یې په 26 کې په 25 کې ودراوه، ځکه چې د 14 تر 17 زنځیرونو لارښودونه لا هم پرې پاتې وو؛ د هغوی ړنګولو 22 GB خوشې کړل. د مخکیني زنځیر لارښود د بېرته ګرځېدو د هدف په توګه یوه ورځ وساتئ، بیا یې لرې کړئ. په بشپړو بلاکونو کې، له زنځیر 14 راهیسې هر خام بنډل ثبوت شاوخوا 1.42 MB دی (تر زنځیر 13 پورې شاوخوا 1.3 MB). له زنځیر 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 ته اړتیا لري. زنځیر 14 لومړنی زنځیر دی چې پکې د دېوال ساعت وخت د اجماع برخه ده (د پل ټینګښت B2):
| قاعده | حد | ډول |
|---|---|---|
| د یوه بلاک مهالټاپه باید د خپل مور بلاک له مهالټاپې څخه له دې اندازې زیات وړاندې نه وي | 60 s (MAX_TIMESTAMP_STEP_MS) | د اعتبار قاعده؛ بلاک ناسم دی (BlockError::TimestampLeap) |
| تاییدوونکی هغه بلاک ته رایه نه ورکوي چې مهالټاپه یې د هغه له خپل ساعت څخه له دې اندازې زیاته مخکې وي | 15 s (MAX_CLOCK_DRIFT_MS) | د رایې قاعده |
هغه تاییدوونکی چې ساعت یې 20 s وروسته وي، په چوپتیا سره رایه ورکول بندوي: هر صادق بلاک د خپل ساعت څخه مخکې ویني او رایه یې نه ورکوي، او هېڅ شی نه ماتېږي. په زنځیر 20 کې، د هر شي د ثبتولو لپاره د شپږویشتو څخه اتلس باید رایه ورکړي. هر تاییدوونکی وګورئ، او چېرته چې ساعت همغږی نه وي، 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 هغه اندازې چې testnet پرې چلېږي
| اندازه | 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 (هلته یوازینۍ کوچنۍ اندازه) | ډیسکونه د زنځیر 13 په لېږد کې ډک وو (29 GB)؛ د زنځیر 11 د مړو معلوماتو لارښودونو له ړنګولو وروسته 7 GB خالي؛ د اندازې بدلون ته اړتیا لري |
| 4 vCPU، 8 GB | 8 GB، 4 | E (sgp1) | تاییدوونکی، د جوړونې کوربه او explorer |
دا جدول اصلي اتلس تاییدوونکي رانغاړي. له 2026-09-27 راهیسې تاییدوونکی A هم پر droplet (sgp1) چلېږي، نه پر لپټاپ. اته نور تاییدوونکي په زنځیر 15 کې (2026-09-27) تړل شول: دوه آرشیفونه، obs1 او rand-archive-2 (fra1)، او شپږ ساتونکي کوربه. د هغوی د droplet اندازې دلته نه دي ثبت شوې، او نه دا چې mkc1 او mem1 د اندازې بدلون موندلی که نه. ټول 26 په زنځیر 20 کې د جنیسس تاییدوونکي دي، لکه په زنځیر 19 کې، هر یو په 1,000 RAND، او تر 2026-09-30 پورې ټولې 26 کیلي د یوه چلوونکي سره دي.
د ثبوت حافظه
والټ هره هغه راکړه ورکړه ثابتوي چې لېږي یې، نو د یوه پروګرام غوښتونکی د هغه پروګرام د کچې لپاره حافظې ته اړتیا لري. دا اندازه شوي حدونه دي. د کچې 18 چلونې پای ته رسېدلې، ثابت او تصدیق شوې دي پر DigitalOcean؛ کچه 20 نه ده. له v0.5.6 راهیسې زنځیر له کچې 14 څخه پورته د غوښتنې ثبوت ردوي (MAX_CALL_TIER)، نو لاندې د کچې 16، 18 او 20 کرښې اندازهګیرنې دي، نه هغه غوښتنې چې زنځیر 20 یې مني؛ په زنځیر 14 کې هره ثبت شوې غوښتنه د کچې 10 وه.
| کاري بار | کچه | دورې | څه اندازه شول | اړتیا |
|---|---|---|---|---|
پټه لېږدونه (د bundle مېلمه) | 14 | په زنځیر 13 کې شاوخوا 9,160 (د 2-ننوت 2-وتون مېلمه) | پر Apple Silicon لپټاپ 92.2–96.0 s (تولیدي، زنځیر 13، 2026-09-19)؛ د حافظې لوړه کچه نه ده ثبت شوې. د زنځیر 14 د 4-ننوت 4-وتون پټې شتمنۍ مېلمه په همدې کچه ټاکل شوی: شاوخوا 100 s او شاوخوا 1.42 MB ثبوت. په زنځیر 20 کې یوه لېږدونه دوه ثبوتونه ده (وېشل شوې اجازه، له زنځیر 17 راهیسې): د کچې 14 بنډل ثبوت، 102 تر 134 s او شاوخوا 1.49 MB، او د کچې 10 د اجازې ثبوت، 7 تر 23 s او شاوخوا 1.36 MB. د یوې بشپړې راکړې ورکړې لپاره د حافظې لوړه کچه 6.1 تر 6.6 GB (Apple Silicon لپټاپ، زنځیر 18، 2026-09-30) | د پراختیا پر لپټاپ چلېږي |
ERC-20 approve (تولیدي، په زنځیر 13 کې، 2026-09-19) | 16 | 48,119 | د غوښتنې ثبوت 388.7 s، 3,412,405 بایټه؛ ټول rand call 622.8 s په 22.9 GB لوړه RSS پر 48 GB M-series لپټاپ | یو 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 پورته وه | 85.0 GB (ژباړل شوی) / 85.5 GB (تفسیر شوی) لوړه RSS، 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 کې ودرول شو، لا هم په ثابتولو بوخت؛ د کچې 20 یوه چلونه پر 64 GB droplet له 10 m 41 s وروسته په 65.1 GB کې د OOM له امله ووژل شوه | تر اوسه نه دی ثابت شوی؛ اټکل شوی شاوخوا 330 GB او شاوخوا 3.6 h (د کچې 16/18 اندازه شوې پراختیا: د هرو +2 کچو لپاره حافظه شاوخوا ×3.9، وخت شاوخوا ×4.1) — د DigitalOcean د تر ټولو لویې حافظې droplet (m-32vcpu-256gb، 256 GB) څخه زیات |
| د rVM د کچې 21 تولیدي وتون (یو بنډل ثبوت د تکرار VM دننه تصدیق شوی) | 21 | 1,968,619 قطارونه | له چلولو مخکې اټکل شوې اړتیا 48.6 GB؛ د محدودیتونو د 7 ټولګې لاندې یې د یوه 256 GB droplet له ظرفیت څخه زیات ته اړتیا درلوده (2026-09-28/29) | له 256 GB څخه زیات؛ د محدودیتونو د 8 ټولګې لاندې بیا نه دی اندازه شوی |
د ERC-20 غوښتنې په 16 او 18 کچو او SPL Token په 20 کچه کې راځي (Ethereum، Solana). د کچې 18 یا 20 هېڅ ثبوت پر 48 GB ماشین نه دی جوړ شوی.
راټولوونکي
راټولوونکی زنځیر څاري، د نهايي شويو بلاکونو د یوې کړکۍ بنډل ثبوتونه اخلي، پر هغوی یو تکراري راټول ثبوت جوړوي، او وړاندې کوي یې. هغه بلاک چې دا پکې شامل وي، مهرکوونکی بلاک دی. راټولوونکي ته د پوښل شويو بنډلونو د ثبوت ونډه او په نوي RAND کې د بلاک مرسته، د هغه ثبت شوي تادیې پتې ته ورکول کېږي. راټولونه بېاجازې ده: هر چلوونکی چې ضمانت ولري، ثبت کېدای شي.
دا یوازې پر هغه زنځیر شته چې جنیسس یې د aggregation برخه ولري. زنځیر 20 هېڅ نه لري، او جوړونه یې پر هغه جنیسس له پیل څخه انکار کوي چې دا برخه ولري.
هارډویر
| راټول ثبوت | د کوربه RAM | backend |
|---|---|---|
| N = 1 بنډل | لږ تر لږه 64 GB | CPU؛ د ازموینې پروفایل یو یې پر یوه بوخت لپټاپ شاوخوا 26 دقیقو کې ثابت کړ (327,035 بایټه) |
| N = 2 | 133 GB اندازه شوی؛ پخوانی حد لږ تر لږه 128 GB و | د تولید لپاره GPU backend |
| N = 3 | 221 GB اندازه شوی؛ پخوانی حد لږ تر لږه 160 GB و | د تولید لپاره GPU backend |
| د بېړۍ 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 ټولګې لاندې اندازه شوې، او تولیدي وتون ثبوت د هغه ماشین له 256 GB څخه زیات ته اړتیا درلوده. هېڅ یو د محدودیتونو د 8 ټولګې لاندې بیا نه دی اندازه شوی، چې 18 تر 20 زنځیرونه پرې چلېږي، نو د N = 1 کرښه د ټیټ حد په توګه وګڼئ. CUDA backend لومړی ځل په 2026-09-28 پر ریښتیني هارډویر، پر یوه NVIDIA H100 وچلېد: کرنلونه یې د sm_80 او sm_90 لپاره PTX ته جوړېږي او د CPU له مرجع سره سمون لري. د بېړۍ پر GPU نوډ تولیدي اندازهګیرنه لا پاتې ده. هر نوډ د راټول پروګرام لپاره د پیل یو ځلي کیلي جوړونه هم تادیه کوي: د ازموینې په پروفایل (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:8545د aggregate فلګ | تلواله | مانا |
|---|---|---|
--key | اړین | د راټولوونکي هغه کیلي چې راجستر یې پېژني؛ هر راټول شوی ثبوت لاسلیکوي |
--rpc | http://127.0.0.1:8545 | هغه نوډ چې پوښتنه ترې کېږي او ورته سپارل کېږي |
--watch | بند | د یو ځل سپارلو پر ځای پرلهپسې پوښتنې کوي |
--interval-secs | 15 | له --watch سره د پوښتنو وقفه |
--no-wait | بند | کله چې نوډ راټول شوی ثبوت ومني، بېرته راګرځي |
rand status په داسې زنځیر کې یوه aggregation برخه ښيي: راجستر شوي راټولوونکي، نامهر شوي بلاکونه او د سبسایډۍ د مهالوېش شمېره. 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 toزنځیر 20 له init مخکې په هر نوډ کې v0.6.8 ته اړتیا لري. د دې پیدایښت داسې ساحې لري چې هېڅ پخوانۍ جوړونه یې نه لولي (testnet، binding_domain، proof_window_blocks، program_state، د پُل rotation او fees ډلې، د ګاز پورتنۍ پولې، د رایې له لارې د سټېکینګ منل)، او v0.6.8 د v6 پلټنې د CON-4 او CH-1 د اجماع بدلونونه لري. ثبوتونه لا هم د 8م محدودیت سیټ لاندې جوړېږي، لکه څنګه چې په 18م او 19م زنځیرونو کې، او د هر بنډل ثبوت تر څنګ د اجازې یو ثبوت (hc_auth) شته. د v0.6.8 جوړونه د 14م تر 17م زنځیرونو پیدایښت په run او verify کې ردوي. هماغه یوه جوړونه وچلوئ چې د نوډونو ډله یې چلوي. د پیدایښت فایل د fullnode په main کې دی (کمېټ 74cfaca0)، نه د v0.6.8 په ټګ کې، له همدې امله د git درېیمه کرښه شته. د circuits چکاوټ باید په هماغه کمېټ کې وي چې خپرونه ترې اخیستل شوې، او د 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 په ذخیره کې هېڅ کیلي نه تعقیبېږي (v3 پلټنه، OPS-1). د deploy/node-*.key.json هغه فایلونه چې د 8م تر 13م زنځیرونو لپاره کمېټ شوي، خپاره شوي تخمونه دي؛ د زنځیر 20 د تاییدوونکو کیلي (هغه اتلس چې د زنځیر 14 لپاره جوړې شوې او هغه اته چې په زنځیر 15 کې ګرو شوې) د ذخیرې بهر جوړې شوې، او د نوډونو ډله د هر ډراپلېټ کیلي د سرچینې له ونې بهر په /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 (زنځیر 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 واحدونه)؛ په هر invoke کې تر ډېره 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 هغه څه دي چې د testnet تاییدوونکي یې چلوي، پرته له آرشیفونو؛ د هغه نوډ لپاره یې لرې کړئ چې بشپړ تاریخ ساتي، او هېڅکله یې په mainnet کې مه ورکوئ. د زنځیر 20 د پیل multiaddr پتې C (fra1)، D (ric1) او E (sgp1) نوډونه دي، د زنځیر 19 په پرتله نه دي بدل شوي. زنځیر 20 د هغو تاییدوونکو په کیلیو چلېږي چې د زنځیر 14 لپاره جوړې شوې، او د p2p پېژندنه له تاییدوونکي کیلي څخه اخیستل کېږي، نو د دې ملګرو پېژندنې هماغه دي چې زنځیر 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/12D3KooWPocyZGcNB9Vp68VSfgVvNXhSzBBoJa4h9R1yMkp71XHhRPC په 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 د call-tier قاعده، د 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 له لاسلیک شوي SHA256SUMS پرته نصب ردوي، مګر دا چې ALLOW_UNSIGNED=1 ټاکل شوی وي. 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 د پرې کولو ثبت د دویم چلوونکي له بیا جوړونې تېر شو، ځکه چې یو چلوونکی ټولې کیلي لري. پرې کول یو داسې دلیل ته اړتیا لري چې پرلهپسې تازه کول یې نه شي پوره کولای، د هغه څه خپور لېست چې ورسره وړل کېږي او هغه څه چې پرېښودل کېږي، د پېرېدونکو د بیا جوړونې یو چکلېست چې مخکې بشپړ شوی وي، یو دویم چلوونکی چې پیدایښت هماغه هش ته بیا جوړوي، د بېرته ګرځېدو پلان، او د زنځیر یوه پېژندنه چې مخکې هېڅکله نه وي کارول شوې.