نوڈ چلانا

اس صفحے کی مدد سے testnet پر اپنا rand-node چلائیں۔ والٹ کو نجی طور پر استعمال کرنے کا تجویز کردہ طریقہ بھی یہی ہے: جو نوڈ آپ خود چلاتے ہیں اسے آپ کے سوا کسی اور سے یہ معلوم نہیں ہوتا کہ آپ کون سا لیف خرچ کرنے والے ہیں۔ مشاہدہ کار نوڈ چین سے ہم آہنگ ہوتا ہے، ہر ثبوت کی دوبارہ تصدیق کرتا ہے اور JSON-RPC فراہم کرتا ہے۔ ویلیڈیٹر بھی یہی سب کرتا ہے، اور جب اس کی کلید کسی ایپوک کے سیٹ میں شامل ہو جائے تو اتفاقِ رائے میں بھی حصہ لیتا ہے۔

تعمیر

ضروریات: Rust 1.98.1 (جو rust-toolchain.toml میں مقرر ہے اور جسے rustup خود انسٹال کر دیتا ہے)، RocksDB کے لیے ایک C++ کمپائلر اور cmake۔ zkVM کریٹ کی path انحصاریاں ثبوتی نظام کی ریپوزٹری (randprotocol/zkp-circuits) کے ایک ہم پہلو circuits/ چیک آؤٹ میں جاتی ہیں۔ یہ چیک آؤٹ fullnode/ کے برابر میں ہونا چاہیے اور اسی کمٹ پر ہونا چاہیے جس سے ریلیز میں کوڈ شامل کیا گیا تھا۔ یہ کمٹ crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md کی circuits: والی سطر میں درج ہے (v0.6.8 کے لیے aeacf31، جیسا کہ v0.6.7 کے لیے تھا)۔ پہلی تعمیر میں 10 سے 20 منٹ لگتے ہیں۔

git clone https://github.com/randprotocol/fullnode
cargo build --release          # target/release/rand-node, target/release/rand, target/release/rand-prover

v0.6.8 چلائیں۔ فلیٹ یہی ریلیز چلاتا ہے: git checkout v0.6.8، کمٹ c9c9bd3c۔ کسی نوڈ کا sha rand_getVersion بتاتا ہے۔ اس کی GitHub ریلیز میں rand-node، rand، rand-prover اور SHA256SUMS شامل ہیں۔ یہ سب فلیٹ کے ایک ہی میزبان پر تیار کیے گئے ہیں اور ان پر دستخط نہیں ہیں۔ چین 20 کو اسی ریلیز کی ضرورت ہے کیونکہ اس کے جینیسس میں ایسے فیلڈ ہیں جنہیں اس سے پہلے کی کوئی تعمیر نہیں پڑھتی: testnet، binding_domain، proof_window_blocks، program_state، برج کے rotation اور fees گروپ، گیس کی بالائی حدیں، اور ووٹ کے ذریعے اسٹیکنگ میں داخلہ۔ اس کے علاوہ v0.6.8 میں اتفاقِ رائے کی ایسی تبدیلیاں ہیں جو پرانا نوڈ نہیں چلاتا۔ ثبوت اب بھی قیود کے سیٹ 8 کے تحت بنائے جاتے ہیں، جیسا کہ چین 18 اور 19 پر ہوتا تھا۔ ہر بنڈل میں اب بھی بنڈل کے ثبوت کے ساتھ اجازت کا ایک ثبوت ہوتا ہے (منقسم اجازت، چین 17 سے)۔ اس لیے جینیسس وہی دو گیسٹ مقرر کرتا ہے: بنڈل گیسٹ v3 (hc_bundle 60af094a…) اور اجازت کا گیسٹ (hc_auth 1e4e347f…)۔ جینیسس میں ایک gas حصہ، hardening_v6 اور envelope_bytes بھی شامل ہیں۔ v0.6.8 کی تعمیر چین 14، 15، 16 اور 17 کے جینیسس کو ہیش کی بنیاد پر run اور verify دونوں مراحل پر رد کر دیتی ہے، البتہ چین 19 کا جینیسس اب بھی چلا سکتی ہے۔ ہر نوڈ فلیٹ والی تعمیر ہی چلاتا ہے۔

چین 20: مکمل توقف والا ہارڈ فورک

چین 20 بتاریخ 2026-10-01 کو 06:17 UTC پر فعال ہوئی۔ اسے چین 19 کے ایک اسنیپ شاٹ سے تیار کیا گیا اور سب نوڈز ایک ساتھ روک کر ایک ساتھ دوبارہ شروع کیے گئے: چین 19 کا ہر نوڈ بلندی 7,700 پر رکا، اور ہر نوڈ v0.6.8 کے ساتھ چین 20 پر شروع ہوا۔ یہ مرحلہ وار اپ ڈیٹ نہیں تھا، اور اس کی دو وجوہات تھیں۔ پہلی یہ کہ چین 20 ایک نیا جینیسس ہے، اس لیے اس کا کوئی بلاک چین 19 کے ساتھ مشترک نہیں۔ دوسری یہ کہ v0.6.8 میں آڈٹ v6 سے آنے والی اتفاقِ رائے کی ایسی تبدیلیاں ہیں جنہیں کبھی ایک ایک نوڈ کر کے نافذ نہیں کیا جانا چاہیے: CON-4 ویلیڈیٹر کے لاک کا خودکار اخراج ختم کرتا ہے، اور CH-1 ٹائم آؤٹ سرٹیفکیٹ پر مبنی پیس میکر شامل کرتا ہے۔ تمام 26 ویلیڈیٹر، ان کی کلیدیں، پیئر شناختیں اور بوٹ اسٹریپ جوں کے توں منتقل ہوئے۔ کورم اب بھی 26 میں سے 18 ہے۔ چین 19 اور 18 ریٹائر کر دی گئی ہیں۔

اس لیے کسی نوڈ کو چین 19 سے چین 20 پر منتقل کرنے کے لیے نیا بائنری، نئی جینیسس فائل اور ایک تازہ ڈیٹا ڈائریکٹری درکار ہیں، جیسا کہ نیچے بیان کیا گیا ہے۔ چین 20 پر بھیجنے کے لیے والٹس کو v0.6.8 درکار ہے، کیونکہ اس کا جینیسس ہر ثبوت اور ہر دستخط شدہ پیغام کو اپنے ہیش سے باندھتا ہے (binding_domain: 1)، اور پرانا والٹ ایسا نہیں کرتا۔

کلیدیں

rand-node keygen --out node.key.json      # prints the address
rand-node address --key node.key.json     # address, public key, libp2p peer id

فائل کی ساخت { "seed", "address", "public_key" } ہے اور اس کا موڈ 0600 ہے۔ اس میں صرف seed خفیہ ہے۔ مشاہدہ کار نوڈ کو بھی کلید درکار ہے، کیونکہ وہی اس کی p2p شناخت ہے۔ نوڈ کی کلید والٹ کی کلید نہیں ہوتی؛ والٹ کے لیے rand keygen استعمال کریں۔

اپنی کلید خود بنائیں اور اسے چیک آؤٹ سے باہر رکھیں۔ fullnode ریپوزٹری اب کوئی کلید ٹریک نہیں کرتی (آڈٹ v3، OPS-1)۔ چین 8 سے 13 کے لیے جو deploy/node-*.key.json اور deploy/payout/*.key.json فائلیں کمٹ کی گئی تھیں، ان کے seed شائع ہو چکے ہیں اور انہیں استعمال نہیں کیا جانا چاہیے۔ چین 20 کی ویلیڈیٹر کلیدیں ریپوزٹری سے باہر بنائی گئیں اور کبھی ریپوزٹری میں نہیں رہیں۔ اس کے 26 جینیسس ویلیڈیٹروں میں اٹھارہ کلیدیں وہ ہیں جو چین 14 کے لیے بنائی گئیں اور آٹھ وہ جو چین 15 پر بانڈ کی گئیں۔ یہ سب اس کے بعد کی ہر نئی چین میں منتقل ہوتی رہی ہیں۔

v0.6.8 سے rand-node keygen کسی ایسی --out فائل کو قبول نہیں کرتا جو پہلے سے موجود ہو؛ v0.6.7 اسے پوچھے بغیر اوور رائٹ کر دیتا تھا۔ seed کی واحد نقل یہی فائل ہے۔ کسی بانڈ کا انحصار اس پر ہونے سے پہلے اس کا بیک اپ بنا لیں۔

جینیسس سے آغاز

کسی چین کے ہر نوڈ کو بائٹ بہ بائٹ یکساں جینیسس فائل درکار ہے۔ rand-node init اسے ڈیٹا ڈائریکٹری میں کاپی کرتا ہے اور اس کا ہیش دکھاتا ہے۔ چین 20 کے لیے یہ ہیش 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 ہونا چاہیے۔ فائل deploy/genesis-chain20.json ہے (sha256 0020247a…3a21)۔ اسے لانچ ریکارڈ کے ساتھ fullnode کی main میں کمٹ کیا گیا (کمٹ 74cfaca0)، اور یہ ٹیگ کے بعد ہوا۔ اس لیے v0.6.8 کے چیک آؤٹ میں یہ فائل موجود نہیں؛ اسے main سے حاصل کریں۔

git -C fullnode show origin/main:deploy/genesis-chain20.json > genesis-chain20.json
rand-node init --datadir ./data-6210cf07 --genesis genesis-chain20.json

اس سے <datadir>/db (RocksDB) بنتا ہے جس میں تین چیزیں ہوتی ہیں۔ پہلی، بلاک 0۔ دوسری، نو جینیسس نوٹ جو درخت کے پہلے لیف ہیں: سات RAND نوٹ جن میں چین 19 کے آپریٹر والٹس کے 5,184.243719258 RAND ہیں، اور 10 اور 89 zUSD کے دو zUSD نوٹ، یعنی وہ 99 zUSD جو برج کی تحویل میں لاک ہیں۔ تیسری، ویلیڈیٹروں کا رجسٹر۔ اسی جینیسس کے ساتھ دوبارہ چلانے کا کوئی اثر نہیں ہوتا، جبکہ مختلف جینیسس رد کر دیا جاتا ہے؛ already initialized with a different genesis کا مطلب ہے کہ یہ ڈیٹا ڈائریکٹری کسی دوسری چین کی ہے۔ ڈیٹا ڈائریکٹری کا نام جینیسس ہیش کے پہلے آٹھ حروف پر رکھیں، جیسا کہ فلیٹ کرتا ہے (data-<name>-6210cf07)، تاکہ یہ کبھی چین 19 کی ڈائریکٹری (-a3defc93) سے نہ ٹکرائے۔

جینیسس فائل کی ساخت:

{
  "chain_id": 20,
  "timestamp_ms": 1790835251661,
  "validators": [ { "public_key": "<hex>", "stake": 1000000000000, "payout": "rand1…" } ],
  "alloc": [ { "cm": "<64 hex>", "envelope": { "kem_ct": "…", "to_receiver": "…", "to_sender": "…", "body": "…" }, "amount": 1000000000000,
               "opening": { "pk": "<64 hex>", "time": 0, "r": "<64 hex>" } },
             { "cm": "…", "envelope": { … }, "amount": 1000000000,
               "opening": { "pk": "<64 hex>", "time": 0, "r": "<64 hex>", "asset": 1 } } ],
  "faucet": true,
  "confidential": true,
  "fri_profile": "production",
  "hc_bundle": "60af094acfe65d85fdb18fb3d06cf9085dcf28c96e59e87f1ee527226e6e3fce",
  "bridge": { "emitter": "<64 hex>", "guardians": [ "<40 hex>" ], "emitters": { "2": "<64 hex>", "3": "…", "4": "…", "5": "…" },
              "pq_guardians": [ "<hex>" ], "pause_key": "<hex>",
              "rules_v2": { "global_mint_cap_per_window": 400000000000, "cap_window_secs": 86400 },
              "guardian_set_index": 1, "burn_sequence": 13,
              "min_inbound_sequence": { "2": 3, "3": 3, "4": 3, "5": 7 },
              "rotation": { "delay_secs": 86400, "needs_possession": true },
              "fees": { "mint_bps": 10, "burn_bps": 10, "recipient": "rand1…" } },
  "tokens": { "registration_fee": 1000000000, "mint_cap_per_day": 10000000000000,
              "tokens": [ { "name": "Shielded USD", "symbol": "zUSD", "salt": "<64 hex>",
                            "backings": [ { "chain": 2, "token": "<64 hex>", "decimals": 6 }, … ] } ],
              "max_tokens": 4096, "burn_registration_fee": true, "bound_note_value": true },
  "consensus_domain": 1,
  "staking": { "faucet_budget_per_epoch": "10000000000000", "bond_activation_epochs": 2,
               "max_weight_bps": 3333, "registration_v2": true,
               "faucet_recipients": [ "rand1…" ], "faucet_minters": [ "<validator address>" ],
               "max_stake_entry_bps_per_epoch": 2500, "admission_by_vote": true },
  "epoch_blocks": 1000,
  "max_program_words": 65535,
  "max_proof_bytes": 4194304,
  "max_block_bytes": 20971520,
  "max_call_envelope_bytes": 65536,
  "max_program_public_words": 32768,
  "envelope_bytes": 1860,
  "hardening_v6": true,
  "hc_auth": "1e4e347f44cf86750b30a9a4bdf9ec9256efe353d4ff8017451eca7d195639c1",
  "gas": { "gas_price": "100", "byte_price": "800", "bundle_gas_limit": 20479, "metering": "circuit",
           "dynamic": { "target_block_bytes": 10485760, "target_block_gas": 262144,
                        "adjust_bps": 1250, "min_gas_price": "100", "min_byte_price": "800",
                        "max_gas_price": "10000", "max_byte_price": "80000", "byte_load": "paying" } },
  "testnet": true,
  "binding_domain": 1,
  "proof_window_blocks": 1024,
  "program_state": { "cell_fee": 10000000 }
}

ہر فیلڈ جینیسس ہیش میں شامل ہے۔ hc_bundle وہ بنڈل گیسٹ مقرر کرتا ہے جس کے مقابل ہر بنڈل ثبوت جانچا جاتا ہے، اور hc_auth وہ اجازت کا گیسٹ جس کے مقابل ہر اجازت کا ثبوت جانچا جاتا ہے۔ اگر کسی نوڈ کی تعمیر کوئی مختلف گیسٹ بناتی ہے تو وہ نوڈ شروع ہونے سے انکار کر دیتا ہے اور دونوں ڈائجسٹ بتاتا ہے۔ پانچوں max_* فیلڈ اختیاری ہیں اور صرف موجود ہونے کی صورت میں ہیش میں شامل ہوتے ہیں؛ چین 20 پانچوں مقرر کرتی ہے۔ max_proof_bytes کی قدر 4 MiB ہے، جبکہ چین 13 سے 16 میں یہ 8 MiB تھی۔ اس کی وجہ یہ ہے کہ چین 17 سے ایک ٹرانزیکشن میں تین ثبوت (بنڈل، اجازت، کال) ہو سکتے ہیں، اور جس جینیسس میں hc_auth ہو اس میں max_block_bytes کم از کم max_proof_bytes کے تین گنا جمع 1 MiB ہونا لازم ہے۔ ہر alloc نوٹ کے ساتھ اس کا opening ہوتا ہے (pk، time، r، اور ٹوکن نوٹ کے لیے asset)، اس لیے جینیسس نوٹ کا مالک اور رقم دانستہ طور پر عوامی ہیں۔ چین 20 میں یہ شامل ہیں:

• ایک bridge حصہ۔ اس میں انڈیکس 1 پر گارڈین سیٹ 1 ہے جس میں آٹھ گارڈین ہیں؛ ماخذ چین 2، 3، 4 اور 5 کے لیے ایمیٹرز ہیں (وہی جو چین 19 کے تھے)؛ آٹھ Dilithium2 pq_guardians ہیں؛ ایک pause_key ہے؛ burn_sequence 13 ہے؛ ماخذ چین 2، 3 اور 4 کے لیے min_inbound_sequence کی قدر 3 اور ماخذ چین 5 کے لیے 7 ہے؛ اور rules_v2 ہے (ہر 24 h کے وقفے میں 4,000 zUSD کی مجموعی منٹ حد)۔ چین 20 پر نئے گروپ دو ہیں۔ پہلا rotation ہے: اس کے تحت PQ گارڈین یا pause key کی تبدیلی کے لیے نئی کلیدوں کی ملکیت کا ثبوت درکار ہے، اور تبدیلی کمٹ ہونے کے 86,400 s بعد نافذ ہوتی ہے۔ دوسرا fees ہے: اس کے تحت چین ہر ڈپازٹ اور ہر برن کا 10 bps ایک ٹریژری پتے کے نام zUSD نوٹ کی صورت میں رکھتی ہے، چنانچہ ڈپازٹ میں کل رقم سے فیس منہا کر کے کریڈٹ کیا جاتا ہے اور برن میں اس کی رقم سے فیس منہا کر کے جاری کیا جاتا ہے؛
• ایک tokens حصہ۔ اس میں 1 RAND کی رجسٹریشن فیس ہے جو تجویز کنندہ کو ادا کرنے کے بجائے برن کی جاتی ہے؛ آٹھ اعشاریوں پر ہر پشت پناہی کے لیے 100,000 ٹوکن کا mint_cap_per_day ہے؛ رجسٹری کی حد 4,096 ٹوکن ہے؛ نوٹ کی قدر کی حد 2^63 ہے؛ اور zUSD جینیسس پر اپنی سات پشت پناہیوں کے ساتھ درج ہے۔ دونوں جینیسس zUSD نوٹوں کے مقابل 99 zUSD لاک ہیں: Ethereum USDT 22، BSC USDT 22، Tron USDT 30 اور Solana USDT 25؛
• consensus_domain: 1: اتفاقِ رائے کا ہر دستخط اسی جینیسس سے بندھا ہوا ہے (اتفاقِ رائے)؛
• ایک staking حصہ۔ اس میں فاسٹ 16 والٹس اور 18 منٹ کرنے والی ویلیڈیٹر کلیدوں تک محدود ہے، اور ہر ایپوک کا بجٹ 10,000 RAND ہے۔ بانڈ کی تاخیر دو ایپوک، وزن کی حد 3,333 bps اور رجسٹریشن v2 ہے، جیسا کہ چین 19 پر تھا۔ چین 20 پر دو چیزیں نئی ہیں۔ پہلی admission_by_vote ہے: نئی ویلیڈیٹر کلید تبھی رجسٹر ہوتی ہے جب ویلیڈیٹر سیٹ اس کے حق میں ووٹ دے۔ دوسری داخلے کا بجٹ ہے، یعنی ہر ایپوک کی حد پر فعال وزن کا 2,500 bps، جبکہ چین 19 پر یہ مقررہ 10,000 RAND تھا (اسٹیکنگ)۔ اس میں کوئی slashing نہیں؛
• ایک gas حصہ۔ کال اس گیس کی حد کی قیمت ادا کرتی ہے جو اس کا ثبوت ظاہر کرتا ہے، اور اپنے بائٹس کی بھی۔ قیمتیں فی گیس 100 یونٹ اور فی KiB 800 یونٹ سے شروع ہوتی ہیں۔ ہر بلاک کے بعد قیمتیں اس بلاک کے بھراؤ کے مطابق بدلتی ہیں، جس کا ہدف 10,485,760 بائٹس اور 262,144 گیس ہے۔ یہ تبدیلی فی بلاک زیادہ سے زیادہ 1,250 bps ہوتی ہے، اور قیمتیں کبھی ابتدائی قیمتوں سے نیچے نہیں جاتیں؛ چین 20 پر نیا یہ ہے کہ وہ کبھی 10,000 اور 80,000 سے اوپر بھی نہیں جاتیں۔ بائٹ کی قیمت کے بوجھ میں صرف وہ بائٹس شمار ہوتے ہیں جو بائٹ کی قیمت ادا کرتے ہیں، یعنی کال کا ثبوت اور ان پٹ لفافہ (byte_load: "paying")۔ ہر بنڈل ثبوت ایک ہی حد ظاہر کرتا ہے، یعنی 20,479 (فیس)؛
• envelope_bytes: 1860: ہر نوٹ لفافہ ٹھیک 1,860 بائٹس کا ہے اور اس میں ایک خفیہ کردہ میمو فیلڈ ہوتا ہے؛
• hardening_v6: true: v0.6 کی مضبوطی کا سوئچ، جسے چین 16 سے ہر چین نے فعال رکھا ہے؛
• testnet: true: وہ نشان جس کی بدولت برج کے حصے کے ساتھ فاسٹ بھی رہ سکتا ہے؛
• binding_domain: 1: ہر ٹرانزیکشن کے ثبوتوں اور ہر دستخط شدہ عمل کے پیغام میں جینیسس ہیش شامل ہوتا ہے، اس لیے ایک چین کے لیے ثابت یا دستخط کی گئی کوئی چیز دوسری چین پر تصدیق نہیں پاتی؛
• proof_window_blocks: 1024: کسی بنڈل کا اینکر آخری 1,024 بلاک اختتامی روٹس میں سے کوئی ایک ہو سکتا ہے، اور اس کا time بلندی سے زیادہ سے زیادہ 1,024 بلاک پیچھے ہو سکتا ہے (چین 19 پر 256)۔ اس سے سست یا تفویض کردہ ثابت کنندہ کو تقریباً بیس منٹ مل جاتے ہیں؛
• program_state، یعنی RPL-2: پروگرام سیلز، پروگرام تجوریاں اور Invoke عمل۔ invoke جو بھی سیل بناتا ہے اس پر فی سیل 0.1 RAND فیس ہے (JSON-RPC میں حدود درج ہیں)۔

اس میں کوئی aggregation حصہ نہیں، اور جس جینیسس میں یہ حصہ ہو اس پر تعمیر شروع ہونے سے انکار کر دیتی ہے۔

timestamp_ms چین کی گھڑی کا صفر ہے۔ جب آپ اپنا genesis خود تیار کریں تو اسے اصل آغاز کے وقت کے قریب رکھیں اور کبھی اس سے آگے نہ رکھیں۔ اگر یہ بہت پیچھے ہو تو بلاک کا وقت حقیقی وقت سے پیچھے رہتا ہے، یہاں تک کہ فی بلاک 60 s کی حد اسے بتدریج برابر لے آئے۔ اگر یہ 15 سیکنڈ سے زیادہ آگے ہو تو بلاک 1 کمٹ ہی نہیں ہوتا: ہر ووٹ، بشمول لیڈر کے، اس وقت تک روکا جاتا ہے جب تک حقیقی وقت genesis کے timestamp تک نہ پہنچ جائے۔ اسے اس مشین کی گھڑی سے جانچیں جو fleet کو شروع کرتی ہے، نہ کہ اس مشین سے جس نے فائل تیار کی۔

چلائیں

rand-node run --datadir ./data --key node.key.json \
    --listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns \
    --bootstrap /ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe \
    --bootstrap /ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw \
    --bootstrap /ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ

--prover-accept-spend-key ختم کر دیا گیا ہے: اگر v0.6.8 نوڈ کو یہ دیا جائے تو وہ شروع ہونے سے انکار کر دیتا ہے، لہٰذا v0.6.7 سے منتقل ہونے والی ہر unit فائل سے اسے نکال دیں۔

اوپر دیے گئے تین bootstraps توثیق کنندگان C، D اور E ہیں، جو چین 19 سے غیر تبدیل شدہ ہیں۔ چین 20 انہی توثیق کنندہ کلیدوں پر چلتی ہے جو چین 14 کے لیے بنائی گئی تھیں، اس لیے ان کی peer ids وہی ہیں جو چین 14 میں استعمال ہوئیں؛ p2p شناخت توثیق کنندہ کی کلید سے اخذ کی جاتی ہے۔ زیادہ تر توثیق کنندگان صرف ایک دن کے بلاکس رکھتے ہیں، اس لیے genesis سے sync کرنے والے نوڈ کو، یا ایک دن سے زیادہ پیچھے رہ جانے والے نوڈ کو، مکمل تاریخ والے peer کی بھی ضرورت ہے۔ دونوں archives میں سے ایک شامل کریں:

    --bootstrap /ip4/168.144.46.203/tcp/30303/p2p/12D3KooWS5usdMPvsbaWSaT2xtKndHvDYurwmueoNvaRRarb2wRf    # obs1
    --bootstrap /ip4/206.81.29.236/tcp/30303/p2p/12D3KooWPocyZGcNB9Vp68VSfgVvNXhSzBBoJa4h9R1yMkp71XHh    # rand-archive-2

مشاہدہ کار نوڈ چلانے کے لیے --validator کو چھوڑ دیں۔ آغاز کا عمل: storage کھولنا، اس build کے guests کو genesis کے hc_bundle اور hc_auth سے جانچنا، سالمیت کی جانچ چلانا (خراب آخری حصہ کاٹ کر اور ووٹ کے تحفظ کی حالت برقرار رکھ کر)، محفوظ شدہ head سے اتفاقِ رائے دوبارہ شروع کرنا، نیٹ ورکنگ اور RPC شروع کرنا، اور پھر کسی بھی آگے والے peer سے sync کرنا۔ RUST_LOG کی طے شدہ قدر info,libp2p=warn,libp2p_mdns=off ہے؛ Ctrl-C یا SIGTERM، جو systemd کا بند کرنے کا سگنل ہے، نوڈ کو صاف طریقے سے بند کرتا ہے۔ اسی --datadir سے دوبارہ شروع کرنے پر نوڈ محفوظ شدہ head سے آگے بڑھتا ہے۔

fullnode کے topology اصول: NAT کے پیچھے موجود نوڈز عوامی پتوں والے نوڈز سے رابطہ کرتے ہیں؛ عوامی نوڈز پر آنے والی TCP 30303 کھولیں؛ RPC کو 127.0.0.1 سے باندھیں جب تک کہ وہ firewall کے پیچھے نہ ہو — یہ ہر اس شخص سے ٹرانزیکشنز قبول کرتا ہے جو اس تک پہنچ سکے، اور جب اس میں کوئی viewing key درآمد ہو جائے تو اس پورٹ کو کلید کا حامل سمجھیں۔ --block-interval-ms کو 1000 یا اس سے سست رکھیں: bundle کا ثبوت تقریباً دو منٹ لیتا ہے اور اس کا anchor چین 20 پر 1,024 بلاکس تک درست رہتا ہے (چین 19 پر 256)۔

توثیق کنندہ کو ہم آہنگ گھڑی درکار ہے۔ چین 14 سے حقیقی وقت اتفاقِ رائے کا حصہ ہے (bridge hardening B2)۔ ایسا بلاک جس کا timestamp اپنے parent سے 60 s سے زیادہ آگے ہو، نادرست ہے، اور توثیق کنندہ ایسے بلاک کو ووٹ نہیں دیتا جس کا timestamp اس کی اپنی گھڑی سے 15 s سے زیادہ آگے ہو۔ اس لیے جس توثیق کنندہ کی گھڑی سست چلتی ہو وہ کوئی خرابی درج کیے بغیر ووٹ دینا بند کر دیتا ہے، اور چین 20 پر کمٹ کے لیے چھبیس میں سے اٹھارہ کا ووٹ لازمی ہے۔ ہر توثیق کنندہ پر NTP چلائیں اور نوڈ شروع کرنے سے پہلے اسے جانچیں:

timedatectl                     # want "System clock synchronized: yes" and "NTP service: active"
chronyc tracking
apt-get install -y chrony && systemctl enable --now chrony    # if it is not synchronised

محفوظ peers

v0.6.8 سے ایک نوڈ زیادہ سے زیادہ 256 قائم شدہ اور 64 نیم کھلے آنے والے کنکشنز قبول کرتا ہے، اور libp2p شناخت بنانے پر کوئی لاگت نہیں آتی، اس لیے اجنبی تمام خانے گھیر سکتے ہیں۔ تین قسم کے peers محفوظ ہیں، جنہیں حد سے بالاتر داخلہ ملتا ہے اور sync بجٹ میں توثیق کنندگان کے حصے سے خدمت ملتی ہے: ہر --bootstrap peer، ہر --reserved-peer، اور ہر وہ توثیق کنندہ شناخت جو دستخط شدہ peer binding سے معلوم ہوئی ہو۔ ہر --validator نوڈ اپنی libp2p شناخت پر اپنی توثیق کنندہ کلید سے دستخط کرتا ہے اور اسے gossip کرتا ہے؛ جو نوڈ کسی توثیق کنندہ سیٹ سے وہ کلید جانتا ہے وہ اس peer کو محفوظ کرتا ہے اور یہ ریکارڈ دوبارہ شروع ہونے پر بھی برقرار رکھتا ہے۔ نئی تیار شدہ چین کے store میں کوئی bindings نہیں ہوتیں، اس لیے پہلے اعلانات آنے تک صرف پہلی دو قسمیں محفوظ ہوتی ہیں: نئی چین تیار کرتے وقت fleet کے توثیق کنندگان کی peer ids کو --reserved-peer کے ذریعے دیں یا انہیں bootstrap فہرست میں رکھیں (rand-node address --key <file> کسی کلید کی peer id دکھاتا ہے)۔ rand_status.reserved_peers انہیں شمار کرتا ہے؛ fleet کے نوڈ پر آغاز کے ایک منٹ کے اندر اسے توثیق کنندگان کی تعداد تک پہنچ جانا چاہیے۔

جانچ کریں

rand-node status                # rand_status verbatim
rand --rpc http://127.0.0.1:8545 status
rand peers

rand_status درج ذیل رپورٹ کرتا ہے: height، view، syncing، sync_target، peer_count، connected_peers، reserved_peers، mempool_size، is_validator، active_validator، faucet، confidential، testnet، fri_profile، programs، notes، nullifiers، tree_root، hc_bundle، hc_auth، binding_domain، gas_prices، نوڈ کا address اور peer_id، اور sync کی تشخیصی معلومات (sync_inflight_age_ms، sync_failures، sync_late_batches)، ڈسک (disk_free_bytes، disk_low)، اور retention کی نچلی حد (prune_floor، جو سب کچھ رکھنے والے نوڈ پر 0 ہوتی ہے؛ prune_history_secs، جو مقرر نہ ہونے پر null ہوتی ہے)۔ چین 20 پر یہ متوقع ہے: hc_bundle 60af094a…، hc_auth 1e4e347f…، faucet true، confidential true، testnet true، binding_domain 1، fri_profile "production"، اور gas_prices فی gas 100 اور 10,000 کے درمیان اور فی KiB 800 اور 80,000 کے درمیان۔ rand_getGenesisHash کا جواب لازماً 6210cf07…5135 اور rand_getVersion کا 0.6.8 ہونا چاہیے۔

جب خالی جگہ --min-free-disk-mb کے چار گنا سے کم ہو تو rand_getHealth، ok، syncing یا behind سے پہلے disk_low جواب دیتا ہے (free_bytes کے ساتھ)۔

تاریخ کی کٹائی

--prune-history 24h کے ساتھ شروع کیا گیا نوڈ لیجر (نوٹس، nullifiers، anchors، توثیق کنندگان کا رجسٹر، پروگرامز) کو مکمل رکھتا ہے اور پرانے بلاکس، ان کی اسناد، ٹرانزیکشنز اور رسیدیں حذف کر دیتا ہے۔ ہر 16ویں کمٹ شدہ بلاک پر ایک دور چلتا ہے جو head کے timestamp میں سے window منہا کرنے کے بعد اس سے پرانے زیادہ سے زیادہ 512 بلاکس حذف کرتا ہے؛ genesis، head اور اس کا parent کبھی حذف نہیں ہوتے، اور نچلی حد صرف اوپر جاتی ہے۔ RocksDB کے compact کرنے کے بعد ڈسک کی جگہ واپس ملتی ہے۔ چین 20 پر، چین 19 کی طرح، 26 میں سے 24 توثیق کنندگان 24h چلاتے ہیں اور تقریباً ایک دن کے بلاکس رکھتے ہیں۔ جب چین 14 کے لیے کٹائی فعال کی گئی (2026-09-25)، تو بقایا کام ختم ہونے پر ہر توثیق کنندہ کے بلاک ٹیبلز 19 GB سے گھٹ کر 3.3–4.4 GB رہ گئے؛ باقی دو، obs1 اور rand-archive-2، جو 2026-09-27 سے توثیق کنندگان بھی ہیں، اس flag کے بغیر چلتے ہیں اور سب کچھ محفوظ رکھتے ہیں۔ mainnet نوڈ کبھی یہ flag استعمال نہیں کرتا۔

کٹائی شدہ نوڈ پر، نچلی حد سے نیچے height کے ذریعے کی گئی تلاش (rand_getBlockByHeight، height کے ذریعے rand_getFinality، یا rand_getBlocks یا rand_getCompactBlocks کی ایسی رینج جو اس تک پہنچے) data.floor کے ساتھ خرابی -32010 جواب دیتی ہے: کسی archive سے رجوع کریں۔ hash کے ذریعے کی گئی تلاش اس بلاک کے لیے جو نوڈ کے پاس اب موجود نہیں، null جواب دیتی ہے، بالکل اسی طرح جیسے کبھی موجود نہ رہنے والے بلاک کے لیے۔ والیٹ کی اسکیننگ متاثر نہیں ہوتی، کیونکہ نوٹس اور nullifiers کی کبھی کٹائی نہیں ہوتی۔

کٹائی شدہ نوڈ کی آغاز پر جانچ ساختی ہوتی ہے (بلاک 0 اور محفوظ کردہ بلاکس، ان کے QCs، parent روابط اور لیڈرز)، genesis سے replay نہیں، اور یہ خود اپنی مرمت نہیں کرتی: اگر یہ ناکام ہو تو کسی archive سے دوبارہ sync کریں۔ کٹائی شدہ ڈیٹا ڈائریکٹری کو v0.5.7 سے پرانے build کے ساتھ نہ کھولیں، الا یہ کہ وہ --verify-chain off کے ساتھ چل رہا ہو: اس کی طے شدہ جانچ genesis سے replay کرتی ہے، بلاک 1 کو غائب پاتی ہے، اور لیجر کو genesis تک کاٹ دیتی ہے۔

ثبوت ساز کی میزبانی

چین 20 پر والیٹ ہر bundle کے لیے دو ثبوت بناتا ہے، اور ان میں سے بڑے کو تقریباً 6 GB میموری درکار ہوتی ہے۔ جو والیٹ اسے سنبھال نہ سکے وہ یہ ثبوت اپنے ساتھ جوڑے گئے کسی تفویض شدہ ثبوت ساز کو سونپ سکتا ہے: یہ الگ rand-prover binary ہو سکتا ہے، یا وہی سروس جس کی میزبانی کوئی نوڈ کرے۔

rand-prover --home /root/prover keygen
rand-prover --home /root/prover pair --name laptop --url https://prover.example.net
rand-node run --datadir ./data --key node.key.json --prover 127.0.0.1:8600 --prover-home /root/prover

pair ایک randprover: لنک پرنٹ کرتا ہے۔ والیٹ اسے rand prover pair <link> کے ذریعے لیتا ہے اور پھر عمومی --prover آپشن کے ساتھ اسی کے ذریعے ثبوت تیار کرتا ہے۔ پروور کا لسنر اس کا اپنا ہے، کبھی RPC کا کوئی میتھڈ نہیں ہوتا: --rpc کے برابر پتہ رد کر دیا جاتا ہے۔ --prover کے ساتھ نوڈ اس وقت تک شروع ہونے سے انکار کرتا ہے جب تک <prover-home>/prover.key.json موجود نہ ہو (طے شدہ <datadir>/prover) اور ہر پروونگ سلاٹ کے لیے 5.74 GB کے علاوہ 1 GiB میموری دستیاب نہ ہو؛ --prover-max-parallel سلاٹس کی تعداد مقرر کرتا ہے، طے شدہ طور پر ایک۔

chain 20 پر پروور کو والیٹ کی ناظر کلید اور ایک تازہ سالٹ بھیجا جاتا ہے، خرچ کی کلید نہیں۔ والیٹ اجازت کا ثبوت خرچ کی کلید پر خود بناتا ہے، اس لیے جوڑا گیا پروور اس والیٹ کی پوری تاریخ پڑھ سکتا ہے مگر خرچ نہیں کر سکتا۔ لسنر کو loopback پر رکھیں، الا یہ کہ اس کے آگے TLS ختم کرنے والا پراکسی ہو، اور اسے ایسی مشین پر نہ چلائیں جو عوامی RPC فراہم کرتی ہو۔ بندش جاری ثبوت کے مکمل ہونے کا انتظار کرتی ہے، اس لیے systemd یونٹ کو TimeoutStopSec=180 دیں۔

تصدیق اور مرمت

rand-node verify --datadir ./data                  # full: hashes, QCs, signatures, proofs, ledger replay, the supply counters
rand-node verify --datadir ./data --mode quick     # structure and ledger replay
rand-node verify --datadir ./data --repair         # truncate a damaged tail; peers resync the rest

پہلے نوڈ بند کریں۔ ہم آہنگ ہونے پر ایگزٹ کوڈ 0، اور اگر کوئی مسئلہ ملا ہو اور --repair نہ دیا گیا ہو تو 2۔ دوبارہ چلانا ہر بنڈل ثبوت کی ازسرِنو تصدیق کرتا ہے، اس لیے جس بلڈ کا قیود کا مجموعہ اس سے مختلف ہو جس نے چین بنائی، وہ پہلے ہی بنڈل پر رک جاتا ہے۔

توثیق کنندہ بننا

توثیق کنندہ کسی چلتی چین میں بانڈنگ کے ذریعے شامل ہوتا ہے، نئی جینیسس کے ذریعے نہیں: نوڈ کو --validator کے ساتھ شروع کریں، rand-node register --key node.key.json --payout <rand1…> --v2 سے رجسٹریشن پرنٹ کریں (chain 20 v1 رجسٹریشن رد کرتی ہے)، کسی والیٹ سے rand bond <address> 1000 --registration <hex> کے ذریعے کم از کم 1,000 RAND بانڈ کروائیں، اور بانڈ فعال ہوتے ہی نوڈ تجاویز پیش کرنے لگتا ہے: chain 20 پر، بانڈ کے بعد جلد از جلد 1,000 بلاک والی تین ایپوک حدود گزرنے پر۔ chain 20 پر بانڈ دوسرے نمبر پر آتا ہے۔ اس کی جینیسس staking.admission_by_vote مقرر کرتی ہے، اس لیے نئی کلید رجسٹر کرنے والا بانڈ اس وقت تک رد ہوتا ہے جب تک ووٹنگ وزن کے دو تہائی سے زیادہ کے حامل توثیق کنندگان اس کلید کے حق میں ووٹ نہ دے دیں: ہر ایک rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 سے دستخط کرتا ہے، اور ان میں سے ایک rand-node admit submit سے ووٹ جمع کراتا ہے (کمانڈ لائن)۔ rand_getAdmitted ان کلیدوں کی فہرست دیتا ہے جنہیں ووٹ مل چکے ہیں اور جو ابھی رجسٹر نہیں ہوئیں۔ کسی ایک ایپوک حد پر فعال وزن کے 2,500 bps سے زیادہ نیا وزن نہیں بنتا۔ اسٹیکنگ اس کا مرحلہ وار بیان کرتا ہے۔ نجی آزمائشی چین کے لیے rand-node genesis ایک چین بناتا ہے:

rand-node genesis --chain-id 88 \
    --validator a.key.json,1000,rand1<a's payout address> \
    --validator <hex public key of b>,1000,rand1<b's payout address> \
    --alloc rand1<address>=1000 \
    --epoch-blocks 1000 --faucet --fri-profile production \
    --out genesis.json

اور scripts/local-testnet.sh ایک ہی مشین پر دو توثیق کنندگان چلاتا ہے جن کا RPC 8545 اور 8546 پر ہوتا ہے۔ مزید فلیگز کے بغیر جینیسس میں نہ hc_auth ہوتا ہے، نہ gas حصہ اور نہ کوئی میمو۔ chain 20 اس کے اوپر --hardening-v6 --bundle-guest v3 --auth-guest --gas-price 100 --byte-price 800 --bundle-gas-limit 20479 --gas-dynamic 10485760,262144,1250 --max-gas-price 10000 --max-byte-price 80000 --gas-byte-load paying --envelope-bytes 1860 --testnet --binding-domain 1 --proof-window-blocks 1024 --program-state-cell-fee 10000000 کے ساتھ بنائی گئی (chains 18 اور 19 میں --envelope-bytes تک کے فلیگز تھے)، اور اس کے bridge اور staking حصے اور consensus_domain چین بنانے والی اسکرپٹ نے جوڑے۔ آپ کی اپنی نئی چین کو --binding-domain 1 دینا چاہیے: v0.6.8 والیٹ 14 سے 19 کے باہر ہر chain id پر جینیسس سے بندھی صورت کا ثبوت تیار کرتا ہے۔

سرور پر تعیناتی

ریپوزیٹری کی deploy/ ڈائریکٹری میں وہ اسکرپٹس ہیں جو فلیٹ استعمال کرتا ہے: deploy/push-to-vps.sh <ip> <letter> "<bootstraps>" [validator|observer] ایک Linux سرور تیار کرتا ہے (سورس rsync کرنا، بلڈ کرنا، /usr/local/bin/{rand-node,rand} انسٹال کرنا، جینیسس ہیش سے منسوب datadir شروع کرنا، rand-node systemd سروس انسٹال کرنا)، اور deploy/rebuild-vps.sh <ip> نئی کمٹ پر دوبارہ بلڈ کرتا ہے اور ڈیٹا برقرار رکھتے ہوئے دوبارہ شروع کرتا ہے۔ دو احتیاطیں۔ تیاری کی اسکرپٹ deploy/genesis.json سے آغاز کرتی ہے، جو chain 20 کی فائل نہیں ہے، اس لیے testnet کا نوڈ deploy/genesis-chain20.json سے ہاتھ سے ترتیب دیا جاتا ہے (main پر، دیکھیں اوپر)۔ اور دونوں اسکرپٹس /root/fullnode کو --delete کے ساتھ rsync کرتی ہیں، اس لیے اس درخت کے اندر رکھی کلید اگلے ری بلڈ میں حذف ہو جاتی ہے: اسے /root/keys میں رکھیں، جیسا کہ فلیٹ کرتا ہے اور جیسا کہ v0.6.8 کی تیاری کی اسکرپٹ اب طے شدہ طور پر کرتی ہے (v0.6.7 کی اسکرپٹ کلید /root/fullnode/deploy/ کے تحت لکھتی تھی)۔ سروس کا انتظام systemctl status rand-node اور journalctl -u rand-node -f سے ہوتا ہے۔ سرور کو build-essential clang cmake pkg-config libssl-dev اور ایک Rust ٹول چین درکار ہے۔ 1-vCPU اور 2 GB والا سرور بائنریز بلڈ نہیں کر سکتا؛ کہیں اور بلڈ کریں اور انہیں اس میں کاپی کریں۔ توثیق کنندہ اور مجمع کنندہ چلانا میں سائز اور مرحلہ وار ترتیب درج ہے۔

ایکسپلورر

randscan.org توثیق کنندہ E کے ساتھ چلتا ہے اور chain 20 کی فہرست سازی کرتا ہے؛ اس کا REST API اور WebSocket فیڈ نوڈ کے بغیر چین پڑھنے کا آسان ترین طریقہ ہیں (ایکسپلورر API)۔ ایکسپلورر اوپن سورس ہے (randprotocol/randscan) اور اس کے انڈیکسر کو صرف کسی نوڈ کا rand_* JSON-RPC اور ایک PostgreSQL ڈیٹا بیس درکار ہے، اس لیے اسے آپ اپنے نوڈ کے ساتھ بھی چلا سکتے ہیں۔