اس صفحے کی مدد سے مشین چلانے سے پہلے اس کی گنجائش طے کریں۔ ویلیڈیٹر سستا ہے، مگر ثبوت سازی سستی نہیں: کسی ثبوت کی میموری اس کے درجے کے ساتھ تیزی سے بڑھتی ہے، اور یہی وہ ایک عدد ہے جو طے کرتا ہے کہ کوئی مشین یہ کام کر سکتی ہے یا نہیں۔ یہاں ہر عدد testnet یا fullnode کے ریکارڈ سے لی گئی پیمائش ہے۔ جو اعداد حتمی نہیں، ان کی نشاندہی کر دی گئی ہے۔
ہر کردار کیا کرتا ہے
| کردار | کیا کرتا ہے | کیا چلاتا ہے | ثبوت بناتا ہے؟ |
|---|---|---|---|
| ویلیڈیٹر | ٹرانزیکشنز کو ترتیب دیتا ہے، ہر بلاک کے ہر ثبوت کی تصدیق کرتا ہے، HotStuff میں ووٹ دیتا ہے | rand-node run --validator | نہیں |
| مشاہدہ کار | ہم آہنگی کرتا ہے، ہر ثبوت کی دوبارہ تصدیق کرتا ہے، JSON-RPC فراہم کرتا ہے؛ ووٹ نہیں دیتا | rand-node run | نہیں |
| پروور (ایک والیٹ) | اپنے بنڈلز اور کالز کے ثبوت مقامی طور پر بناتا ہے، پھر انہیں جمع کراتا ہے | rand send، rand call، rand program deploy | ہاں، ہر ٹرانزیکشن کا |
| تفویض شدہ پروور | اپنے ساتھ جوڑے گئے والیٹ کے لیے بنڈل ثبوت بناتا ہے؛ چین 20 پر اسے اس والیٹ کی ویونگ کلید بھیجی جاتی ہے، خرچ کی کلید کبھی نہیں | rand-prover run، یا rand-node run --prover | ہاں، صرف بنڈل ثبوت |
| ایگریگیٹر | کسی سیلنگ بلاک کے لیے بنڈل ثبوتوں کی ایک ونڈو پر ایک تکراری ثبوت بناتا ہے | rand-node aggregate --watch | ہاں، سب سے بڑے ثبوت |
| بلڈ ہوسٹ | rand-node اور rand کو کمپائل کرتا ہے اور بائنریز چھوٹے نوڈز کو دیتا ہے | cargo build --release | نہیں |
ویلیڈیٹرز اور مشاہدہ کار کبھی ثبوت نہیں بناتے۔ کسی شیلڈڈ منتقلی یا کال کا ثبوت وہ والیٹ بناتا ہے جو اسے بھیجتا ہے، یا صرف بنڈل ثبوت کی حد تک وہ پروور بناتا ہے جس کے ساتھ وہ والیٹ جوڑا گیا ہو (نوڈ چلانا)۔ فلیٹ کے ویلیڈیٹرز فی الحال کسی چیز کا ثبوت نہیں بناتے۔
بلاک ایگریگیشن تیار ہے مگر فعال نہیں۔ اس کے لیے genesis میں aggregation حصہ درکار ہے۔ چین 20 میں یہ حصہ موجود نہیں: چین 9 تا 19 کی طرح ایگریگیشن بند ہے، اور جس genesis میں یہ حصہ ہو اس پر موجودہ بلڈ شروع ہونے سے انکار کر دیتی ہے۔
گنجائش ایک نظر میں
| کردار | RAM | CPU | ڈسک |
|---|---|---|---|
| ویلیڈیٹر یا مشاہدہ کار | 2 GB (اصل فلیٹ)؛ ویلیڈیٹر کو ہم وقت شدہ گھڑی بھی درکار ہے (گھڑی) | 1 vCPU (اصل فلیٹ کا بیشتر حصہ) | --prune-history 24h کے ساتھ تقریباً ایک دن کے بلاک: چین 14 پر بلاک ٹیبلز 3.3–4.4 GB ناپے گئے؛ 4 GB سے زیادہ جگہ خالی رکھیں (ڈسک) |
| آرکائیو (مکمل تاریخ) | ویلیڈیٹر جتنی | ویلیڈیٹر جتنی | چین کے ساتھ بڑھتی ہے: چین 14 کے 18 دستخطوں والے QCs اور 1.4 s بلاکس پر تقریباً 3.6 GB روزانہ ناپی گئی؛ چین 18 تا 20 پر اس سے زیادہ، جن کے QCs میں 26 تک دستخط ہوتے ہیں، اور اس کی دوبارہ پیمائش نہیں ہوئی؛ testnet کے دونوں آرکائیو 250 GiB والیومز پر ہیں |
| بلڈ ہوسٹ | 8 GB (نوڈ E) | 4 vCPU (نوڈ E) | سورس ٹری، target/، اور کم از کم 20 GB خالی جگہ |
| پروور، شیلڈڈ منتقلی (درجہ 14) | چین 18 پر منتقلی کے لیے زیادہ سے زیادہ 6.1 GB، ادائیگی والے بنڈل سمیت کال کے لیے 6.1 تا 6.6 GB (2026-09-30) | ایک کور؛ چین 18 پر دو ثبوت، درجہ 14 کا بنڈل ثبوت 102 تا 134 s میں اور درجہ 10 کا اجازتی ثبوت 7 تا 23 s میں (Apple Silicon لیپ ٹاپ، 2026-09-30)؛ چین 14 پر صرف 4-ان پٹ 4-آؤٹ پٹ پوشیدہ اثاثہ بنڈل کے لیے تقریباً 100 s؛ چین 13 کے 2-ان پٹ 2-آؤٹ پٹ بنڈل کے لیے لیپ ٹاپ پر 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 کے سب سے بڑی میموری والے ڈراپلیٹ (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 والا ڈراپلیٹ ایک کور کی 99% صلاحیت پر چلا۔ زیادہ کور ایک ثبوت کو تیز نہیں کرتے؛ زیادہ RAM طے کرتی ہے کہ ثبوت مکمل ہوتا ہے یا نہیں۔
ویلیڈیٹرز اور مشاہدہ کار
میموری اور CPU
اصل اٹھارہ ویلیڈیٹرز 2 GB ڈراپلیٹس پر چلتے ہیں۔ ثبوت کی تصدیق سستی ہے:
| عمل | لاگت |
|---|---|
| بنڈل ثبوت کی تصدیق، تصدیقی کلید پہلے سے لوڈ ہو | تقریباً 16 ms |
| کسی نئی شکل پر پہلی تصدیق | تقریباً 230 ms |
| تعینات پروگرام کی تصدیقی کلید بنانا (ایک بار، پس منظر میں) | 2-vCPU سرور پر تقریباً 7 s |
| ایک مجموعی ثبوت کی تصدیق (جب ایگریگیشن فعال ہو) | سرد حالت میں تقریباً 0.8 s، پہلے سے لوڈ ہونے پر تقریباً 16 ms (ڈیزائن کے اعداد) |
درجہ 18 یا درجہ 20 کے کال ثبوت کی تصدیق کے لیے ویلیڈیٹر کو درکار میموری اب جزوی طور پر ناپی جا چکی ہے، 48 GB والے Apple-silicon لیپ ٹاپ پر، اس DigitalOcean ڈراپلیٹ سے الگ جس نے ہر ثبوت بنایا: درجہ 18 کے transfer ثبوت کی تصدیق میں 50.2 s لگے اور زیادہ سے زیادہ RSS 3.66 GB رہی (ترجمہ شدہ)، یا 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 سے پہلے چین 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 کی صفائی مکمل ہونے کے بعد چین 14 کا ویلیڈیٹر (2026-09-25) | بلاک ٹیبلز 19 GB سے گھٹ کر 3.3–4.4 GB؛ ڈسکیں 18–37% استعمال شدہ | AGENTS.md، v0.5.7 |
| نوڈ A کی ڈیٹا ڈائریکٹری، چین 12 بلندی 62,276 پر | تقریباً 10 GB | deploy/README.md، v0.3 کا رول آؤٹ |
| بھرے ہوئے بلاکس چلانے والی چین | ہر 2 s میں 4 MiB، تقریباً 170 GB روزانہ (چین 12 تک کی بلاک حد؛ چین 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 |
چین 20 پر، چین 19 کی طرح، 26 میں سے 24 ویلیڈیٹرز --prune-history 24h کے ساتھ چلتے ہیں اور تقریباً ایک دن کے بلاک رکھتے ہیں؛ لیجر خود (نوٹس، نلیفائرز، اینکرز، رجسٹر) کبھی حذف نہیں ہوتا۔ آرکائیو، 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) | ویلیڈیٹر، بلڈ ہوسٹ اور ایکسپلورر |
یہ جدول اصل اٹھارہ ویلیڈیٹرز کا احاطہ کرتا ہے۔ 2026-09-27 سے ویلیڈیٹر A بھی لیپ ٹاپ کے بجائے ایک ڈراپلیٹ (sgp1) پر چلتا ہے۔ چین 15 پر (2026-09-27) مزید آٹھ ویلیڈیٹرز بانڈ کیے گئے: دو آرکائیو، obs1 اور rand-archive-2 (fra1)، اور چھ نگہبان ہوسٹ۔ ان کے ڈراپلیٹ سائز یہاں درج نہیں، اور نہ یہ کہ mkc1 اور mem1 کا سائز بڑھایا گیا یا نہیں۔ چین 19 کی طرح چین 20 پر بھی تمام 26 جینیسس ویلیڈیٹرز ہیں، ہر ایک 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 (دو ان پٹ اور دو آؤٹ پٹ والا گیسٹ) | Apple Silicon لیپ ٹاپ پر 92.2–96.0 s (پروڈکشن، چین 13، 2026-09-19)؛ زیادہ سے زیادہ میموری درج نہیں کی گئی۔ چین 14 کا چار ان پٹ اور چار آؤٹ پٹ والا پوشیدہ اثاثہ گیسٹ اسی درجے پر مقرر ہے: تقریباً 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، 48 GB والے M-series لیپ ٹاپ پر 22.9 GB زیادہ سے زیادہ RSS کے ساتھ | 48 GB والا لیپ ٹاپ |
| ERC-20 کالز | 18 | تقریباً 66k سے 162k | پہلے مرحلے کا transfer (79,203 سائیکل، کوڈ گارڈ سے پہلے) 48 GB لیپ ٹاپ پر 1,016 s کے بعد 24.7 GB پر SIGKILL کر دیا گیا؛ 64 GB ڈراپلیٹ پر ایک رن 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 ڈراپلیٹ پر 10 m 41 s کے بعد 65.1 GB پر OOM کی وجہ سے ختم کر دیا گیا | ابھی ثبوت نہیں بنا؛ تخمینہ تقریباً 330 GB اور تقریباً 3.6 h (درجہ 16/18 کی ناپی گئی اسکیلنگ: ہر +2 درجوں پر میموری تقریباً ×3.9، وقت تقریباً ×4.1) — جو DigitalOcean کے سب سے زیادہ میموری والے ڈراپلیٹ (m-32vcpu-256gb، 256 GB) سے بھی زیادہ ہے |
| rVM درجہ 21 کا پروڈکشن ایگزٹ ثبوت (ریکرشن VM کے اندر تصدیق شدہ ایک بنڈل ثبوت) | 21 | 1,968,619 قطاریں | چلانے سے پہلے اخذ کردہ ضرورت 48.6 GB؛ قیود کے مجموعہ 7 کے تحت اسے 256 GB ڈراپلیٹ کی دستیاب میموری سے زیادہ درکار تھی (2026-09-28/29) | 256 GB سے زیادہ؛ قیود کے مجموعہ 8 کے تحت دوبارہ نہیں ناپا گیا |
ERC-20 کالز درجہ 16 اور 18 پر اور SPL Token درجہ 20 پر آتے ہیں (Ethereum، Solana)۔ 48 GB والی کسی مشین پر درجہ 18 یا 20 کا کوئی ثبوت نہیں بنایا گیا۔
تجمیع کنندگان
تجمیع کنندہ چین پر نظر رکھتا ہے، حتمی شدہ بلاکس کی ایک ونڈو کے بنڈل ثبوت لیتا ہے، ان پر ایک تکراری مجموعی ثبوت بناتا ہے، اور اسے جمع کراتا ہے۔ جس بلاک میں یہ شامل ہو وہ مہر بندی کا بلاک کہلاتا ہے۔ تجمیع کنندہ کو احاطہ شدہ بنڈلز کا ثبوت سازی کا حصہ اور نئے RAND میں ایک بلاک سبسڈی اس کے رجسٹرڈ ادائیگی ایڈریس پر ادا کی جاتی ہے۔ تجمیع بلا اجازت ہے: بانڈ رکھنے والا کوئی بھی آپریٹر رجسٹر کر سکتا ہے۔
یہ صرف اس چین پر موجود ہوتی ہے جس کے جینیسس میں aggregation سیکشن ہو۔ چین 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 ڈراپلیٹ پر، قیود کے مجموعہ 7 کے تحت ناپے گئے، اور پروڈکشن ایگزٹ ثبوت کو اس مشین کے 256 GB سے زیادہ میموری درکار تھی۔ قیود کے مجموعہ 8 کے تحت، جس پر چین 18 سے 20 چلتی ہیں، ان میں سے کسی کو دوبارہ نہیں ناپا گیا، اس لیے N = 1 کی قطار کو نچلی حد سمجھیں۔ CUDA بیک اینڈ پہلی بار 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:8545aggregate فلیگ | طے شدہ قدر | مفہوم |
|---|---|---|
--key | لازمی | وہ aggregator کلید جو رجسٹر میں درج ہے؛ ہر مجموعے پر دستخط کرتی ہے |
--rpc | http://127.0.0.1:8545 | وہ نوڈ جس سے پوچھا جائے اور جس کو جمع کرایا جائے |
--watch | بند | ایک بار جمع کرانے کے بجائے مسلسل پوچھتے رہنا |
--interval-secs | 15 | --watch کے ساتھ پوچھنے کا وقفہ |
--no-wait | بند | نوڈ کے مجموعہ قبول کرتے ہی واپس آ جانا |
ایسی چین پر rand status ایک aggregation حصہ دکھاتا ہے: رجسٹرڈ aggregators، غیر مہر شدہ بلاکس اور سبسڈی شیڈول کا اشاریہ۔ rand_getUnsealed کام کی فہرست ہے۔
تنصیب
یہ مراحل ان اسکرپٹس کے مطابق ہیں جو testnet استعمال کرتا ہے (deploy/vps-setup.sh، deploy/update-droplet.sh)۔ ان سے ایک Linux validator یا مبصر نوڈ تیار ہوتا ہے۔
1. بلڈ ہوسٹ پر بلڈ
بلڈ کے لیے build-essential clang cmake pkg-config libssl-dev، Rust 1.98.1 (جسے rust-toolchain.toml مقرر کرتا ہے)، اور fullnode کے checkout کے ساتھ circuits کا ایک checkout درکار ہے۔ پہلا بلڈ 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 اتفاقِ رائے کی تبدیلیاں شامل ہیں۔ ثبوت اب بھی constraint set 8 کے تحت بنائے جاتے ہیں، جیسے چین 18 اور 19 پر، اور ہر بنڈل ثبوت کے ساتھ ایک اجازت نامے کا ثبوت (hc_auth) ہوتا ہے۔ v0.6.8 کا بلڈ چین 14 سے 17 کے جینیسس کو run اور verify پر رد کر دیتا ہے۔ وہی ایک بلڈ چلائیں جو fleet چلاتا ہے۔ جینیسس فائل fullnode کی main شاخ پر ہے (کمٹ 74cfaca0)، v0.6.8 ٹیگ میں نہیں، اسی لیے تیسری git سطر موجود ہے۔ circuits کا checkout اسی کمٹ پر ہونا چاہیے جس سے ریلیز vendor کی گئی تھی، جسے اوپر کی دوسری 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کلید نوڈ پر ہی بنائیں، جیسا کہ اوپر دکھایا گیا ہے، اور اسے کسی بھی checkout سے باہر رکھیں۔ fullnode ریپوزٹری میں اب کوئی کلید ٹریک نہیں ہوتی (آڈٹ v3، OPS-1)۔ چین 8 سے 13 کے لیے کمٹ کی گئی deploy/node-*.key.json فائلیں شائع شدہ seeds ہیں؛ چین 20 کی validator کلیدیں (چین 14 کے لیے بنائی گئی اٹھارہ اور چین 15 پر بانڈ کی گئی آٹھ) ریپوزٹری سے باہر بنائی گئیں، اور fleet ہر droplet کی کلید /root/keys/node-<name>.key.json میں، سورس ٹری سے باہر، رکھتا ہے۔ fleet کے اسکرپٹس سے تیار کیے گئے نوڈ پر یہ مقام اہم ہے: 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 ہے۔ ڈیٹا ڈائریکٹری کا نام ہیش کے پہلے آٹھ حروف پر رکھیں، جیسا کہ fleet کرتا ہے (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 حصہ | کوئی نہیں (aggregation بند) |
چین 20 کے جینیسس میں consensus_domain: 1، binding_domain: 1، testnet: true، ووٹ کے ذریعے داخلے والا ایک staking حصہ، قیمت کی بالائی حدوں والا ایک gas حصہ، برج کے rotation اور fees گروپ، hardening_v6 اور دو guest pins 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 کے validators چلاتے ہیں، سوائے آرکائیوز کے؛ مکمل تاریخ رکھنے والے نوڈ کے لیے اسے ہٹا دیں، اور mainnet پر اسے کبھی نہ دیں۔ چین 20 کے بوٹ اسٹریپ multiaddrs نوڈ C (fra1)، D (ric1) اور E (sgp1) ہیں، جو چین 19 سے غیر تبدیل شدہ ہیں۔ چین 20 انہی validator کلیدوں پر چلتی ہے جو چین 14 کے لیے بنائی گئی تھیں، اور p2p شناخت validator کلید سے اخذ ہوتی ہے، اس لیے یہ peer ids وہی ہیں جو چین 14 نے استعمال کیے۔ جینیسس سے ہم آہنگ ہونے والے نئے نوڈ کو مکمل تاریخ والا ایک peer بھی درکار ہے، اس لیے دونوں آرکائیوز میں سے ایک شامل کریں (پہلے 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 کا عوامی listener کھولتا ہے (--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. validator سیٹ میں شمولیت
نئی کلید کسی بھی ایپوک کے سیٹ میں شامل نہیں ہوتی۔ چین 20 پر پہلے اسے ووٹ کے ذریعے داخل کیا جانا ضروری ہے: اس کا جینیسس staking.admission_by_vote مقرر کرتا ہے، لہٰذا ووٹنگ وزن کے دو تہائی سے زیادہ کے حامل validators میں سے ہر ایک 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؛ fleet اسے رول بیک کے لیے ایک دن رکھتا ہے)۔ چین کٹ کے بغیر نیا بلڈ نافذ کرنے کے لیے، ایک بار بلڈ کریں، rand-node اور rand دونوں کا sha256 موازنہ کریں، سروس روکیں، تنصیب کریں اور دوبارہ شروع کریں، ایک وقت میں ایک نوڈ۔ بعض ریلیزز اس کے بجائے سب کو روک کر سب کو شروع کرنے کے طریقے سے نافذ کی جاتی ہیں (v0.5.6 کا call-tier قاعدہ، v0.5.7 کی Status wire تبدیلی، 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 تک) فعال ہوئیں، ہر ایک fleet کو مکمل طور پر روک کر۔ چین 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 جو پہلے کبھی استعمال نہ ہوئی ہو۔