د نوډ چلول

دا پاڼه وکاروئ ترڅو خپل rand-node د testnet پر وړاندې وچلوئ. دا د والټ د محرمې کارونې سپارښتل شوې لار هم ده: هغه نوډ چې تاسو یې چلوئ، له تاسو پرته له بل هېچا نه نه پوهېږي چې تاسو د ونې کومه پاڼه لګوئ. یو څارونکی نوډ همغږي کوي، هر ثبوت بیا تاییدوي او JSON-RPC وړاندې کوي. یو اعتباروړونکی همدا کارونه کوي، او کله چې یې کیلي د یوې دورې په ټولګه کې شامله شي، په اجماع کې هم برخه اخلي.

جوړول

اړتیاوې: Rust 1.98.1 (په rust-toolchain.toml کې ټاکل شوی دی او rustup یې نصبوي)، د C++ یو کمپایلر، او د RocksDB لپاره cmake. د zkVM crate په یوه circuits/ چک‌اوټ پورې د لارې انحصارونه لري. دا چک‌اوټ د ثبوت-سیسټم ذخیره (randprotocol/zkp-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): دا هغه خپرونه ده چې د نوډونو ډله یې چلوي، او rand_getVersion د هر نوډ sha ښيي. د دې خپرونې په 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 دی. یوازې تخم پټ دی. څارونکي نوډ ته هم کیلي پکار ده، ځکه د p2p پېژند همدا کیلي ده. د نوډ کیلي د والټ کیلي نه ده: د والټ لپاره rand keygen وکاروئ.

خپله کیلي پخپله جوړه کړئ او د چک‌اوټ نه بهر یې وساتئ. د fullnode ذخیره نور هېڅ کیلي نه ساتي (پلټنه v3، OPS-1). هغه deploy/node-*.key.json او deploy/payout/*.key.json فایلونه چې د 8 تر 13 زنځیرونو لپاره کمېټ شوي وو، تخمونه یې خپاره شوي دي او باید ونه کارول شي. د زنځیر 20 د اعتباروړونکو کیلي د ذخیرې نه بهر جوړې شوې دي او هېڅکله په ذخیره کې نه دي شاملې شوې. د دې 26 جینیسس اعتباروړونکي هغه اتلس کیلي دي چې د زنځیر 14 لپاره جوړې شوې وې، او هغه اته کیلي دي چې پر زنځیر 15 تړل شوې وې. دا کیلي له هغه وخته د زنځیر په هر نوي پرې کېدو کې ساتل شوې دي.

له v0.6.8 راهیسې rand-node keygen د --out هغه فایل ردوي چې مخکې شتون ولري، په داسې حال کې چې v0.6.7 به پرته له پوښتنې پر هغه بل څه لیکل. همدا فایل د تخم یوازینۍ نسخه ده. مخکې له دې چې کوم ضمانت پرې ولاړ شي، بېک‌اپ یې واخلئ.

له جینیسس څخه پیلول

د یوه زنځیر هر نوډ بایټ په بایټ همغه جینیسس فایل ته اړتیا لري. rand-node init دا فایل د ډېټا ډایرکټرۍ ته کاپي کوي او هش یې چاپوي. د زنځیر 20 لپاره دا هش باید 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 وي. فایل deploy/genesis-chain20.json دی (sha256 0020247a…3a21). دا فایل د پیل له ریکارډ سره یوځای (کمېټ 74cfaca0) د ټګ وروسته د fullnode په main کې کمېټ شو، نو د 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 لري. دوه نور یې د zUSD نوټونه دي چې 10 او 89 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 وي. هر تخصیص شوی نوټ خپل 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 سرچینې زنځیرونو لپاره د 3 او د 5 سرچینې زنځیر لپاره د 7 min_inbound_sequence؛ او rules_v2 (په هره 24 ساعته کړکۍ کې د 4,000 zUSD نړیواله د جوړولو پوله). پر زنځیر 20 دوه شیان نوي دي. یو یې rotation دی: د PQ ساتونکي یا د درولو د کیلي بدلون دې ته اړتیا لري چې نوې کیلي د خپل ملکیت ثبوت وړاندې کړي، او بدلون د کمېټ کېدو 86,400 s وروسته اغېز کوي. بل یې fees دی: زنځیر د هرې زېرمې 10 bps او د هرې سوځونې 10 bps د zUSD د یوه نوټ په بڼه د خزانې یوه پتې ته ساتي. نو یوه زېرمه ناخالص مقدار منفي فیس کریډیټ کوي، او یوه سوځونه خپل مقدار منفي فیس خوشې کوي؛
• یوه tokens برخه: د ثبت فیس 1 RAND دی چې د وړاندیز کوونکي ته نه ورکول کېږي بلکې سوځول کېږي؛ mint_cap_per_day د هر ملاتړ لپاره په اتو اعشاریو کې 100,000 ټوکنه دی؛ د ثبت‌نامې پوله 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 د زنځیر د ساعت صفر ټکی دی. کله چې خپل پیدایښت جوړوئ، هغه د پیل اصلي وخت ته نږدې وټاکئ او هېڅکله یې له هغه وړاندې مه ټاکئ. که ډېر په تېر وخت کې وي، د بلاک وخت به د دېوال له ساعت څخه وروسته پاتې وي تر څو چې په هر بلاک کې د 60 s ګام حد ورته اجازه ورکړي چې ورسره برابر شي. که له 15 ثانیو ډېر په راتلونکي کې وي، بلاک 1 هېڅ نه ثبتېږي: هره رایه، د مشر په ګډون، تر هغه وخته نه ورکول کېږي چې د دېوال وخت د پیدایښت مهال‌ټاپې ته ورسېږي. دا د هغه ماشین له ساعت سره وڅېړئ چې ټولګه پیلوي، نه د هغه چې فایل یې جوړ کړی.

چلول

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 څخه راوړل شوی.

پورته درې bootstrap نوډونه تاییدوونکي C، D او E دي، چې له زنځیر 19 راهیسې نه دي بدل شوي. زنځیر 20 پر هغو تاییدوونکو کیلیو چلېږي چې د زنځیر 14 لپاره جوړې شوې وې، نو د همتا پېژندنې یې هماغه دي چې زنځیر 14 کارولې؛ د p2p هویت له تاییدوونکي کیلي څخه اخیستل کېږي. ډېری تاییدوونکي یوازې د یوې ورځې بلاکونه ساتي، نو هغه نوډ چې له پیدایښت څخه همغږي کوي، یا له یوې ورځې ډېر وروسته پاتې دی، د بشپړې تاریخچې یو همتا هم ته اړتیا لري. له دوو آرشیفونو څخه یو ور زیات کړئ:

    --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 پرېږدئ. پیل: زېرمه پرانیستل، د دې جوړونې میلمانه د پیدایښت له hc_bundle او hc_auth سره پرتله کول، د بشپړتیا ازموینه چلول (زیانمن پای پرې کول او د رایې د خوندیتوب حالت ساتل)، له خوندي شوي سر څخه اجماع بیا پیلول، شبکه او RPC پیلول، او بیا له هر هغه همتا سره همغږي کول چې مخکې وي. RUST_LOG په ډیفالټ ډول info,libp2p=warn,libp2p_mdns=off دی؛ Ctrl-C یا SIGTERM، د systemd د درېدو سیګنال، په سمه توګه بندوي. له هماغه --datadir څخه بیا پیلول له خوندي شوي سر څخه دوام ورکوي.

د fullnode د توپولوژۍ قواعد: د NAT تر شا نوډونه له عامه پتو لرونکو نوډونو سره اړیکه نیسي؛ پر عامه نوډونو د TCP 30303 راتلونکې اړیکې پرانیزئ؛ RPC له 127.0.0.1 سره وتړئ مګر دا چې د اور دېوال تر شا وي — دا د هر هغه چا راکړې ورکړې مني چې ورته رسېدای شي، او کله چې د لید کیلي پکې وارده شي، پورټ کیلي لرونکی وګڼئ. --block-interval-ms په 1000 یا ورو کې وساتئ: د بستې ثبوت شاوخوا دوه دقیقې وخت نیسي او د هغه لنګر پر زنځیر 20 د 1,024 بلاکونو لپاره (پر زنځیر 19 د 256) اعتبار لري.

تاییدوونکی همغږی ساعت ته اړتیا لري. له زنځیر 14 راهیسې د دېوال د ساعت وخت د اجماع برخه ده (د پل ټینګښت B2). هغه بلاک چې مهال‌ټاپه یې د خپل مور بلاک له مهال‌ټاپې 60 s ډېر وروسته وي ناسم دی، او تاییدوونکی هغه بلاک ته رایه نه ورکوي چې مهال‌ټاپه یې د هغه له خپل ساعت 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

ساتل شوي همتایان

له v0.6.8 راهیسې یو نوډ تر ډېره 256 جوړې شوې او 64 نیمه‌پرانیستې راتلونکې اړیکې مني، او د libp2p هویت جوړول هېڅ لګښت نه لري، نو پردي کسان کولای شي ټول ځایونه ونیسي. درې ډوله همتایان ساتل شوي دي، چې له حد څخه هاخوا منل کېږي او د همغږۍ د بودیجې د تاییدوونکو له ونډې څخه خدمت ورته کېږي: هر --bootstrap همتا، هر --reserved-peer، او د تاییدوونکي هر هغه هویت چې له لاسلیک شوې همتا تړاو څخه زده شوی وي. هر --validator نوډ خپل libp2p هویت په خپله تاییدوونکې کیلي لاسلیکوي او ګاسیپ یې کوي؛ هغه نوډ چې کیلي د تاییدوونکو له ټولګې پېژني، هغه همتا ساتي او ریکارډ یې د بیا پیلېدو په اوږدو کې ساتي. د نوي جوړ شوي زنځیر زېرمه هېڅ تړاو نه لري، نو تر هغه چې لومړني اعلانونه را ورسېږي یوازې لومړني دوه ډوله ساتل کېږي: د نوي زنځیر پر جوړولو، د ټولګې د تاییدوونکو د همتا پېژندنې له --reserved-peer سره ورکړئ یا یې د bootstrap په لېست کې وساتئ (rand-node address --key <file> د کیلي د همتا پېژندنه چاپوي). rand_status.reserved_peers یې شمېري؛ د ټولګې پر نوډ باید د پیل په یوه دقیقه کې د تاییدوونکو شمېر ته ورسېږي.

یې وڅېړئ

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_inflight_age_ms، sync_failures، sync_late_batches)، ډیسک (disk_free_bytes، disk_low)، او د ساتنې ټیټ حد (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 د هر ګاز لپاره له 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، لنګرونه، د تاییدوونکو ثبت، پروګرامونه) بشپړ ساتي او زاړه بلاکونه، د هغوی سندونه، راکړې ورکړې او رسیدونه ړنګوي. یو دور په هر 16م ثبت شوي بلاک کې چلېږي او تر 512 پورې هغه بلاکونه ړنګوي چې د سر له مهال‌ټاپې منفي کړکۍ څخه زاړه وي؛ پیدایښت، سر او د هغه مور بلاک هېڅکله نه ړنګېږي، او ټیټ حد یوازې لوړېږي. ډیسک هغه وخت بېرته راځي چې RocksDB فشرده کړي. پر زنځیر 20، لکه پر زنځیر 19، له 26 تاییدوونکو څخه 24 یې 24h چلوي او شاوخوا د یوې ورځې بلاکونه ساتي. کله چې د زنځیر 14 لپاره پرې کول فعال شول (2026-09-25)، د هر تاییدوونکي د بلاکونو جدولونه، کله چې پاتې کار پای ته ورسېد، له 19 GB څخه 3.3–4.4 GB ته راټیټ شول؛ نور دوه، obs1 او rand-archive-2، چې له 2026-09-27 راهیسې تاییدوونکي هم دي، پرته له دې بیرغ چلېږي او هر څه ساتي. د mainnet نوډ هېڅکله دا بیرغ نه ورکوي.

پر پرې شوي نوډ، له ټیټ حد څخه لاندې د لوړوالي پر بنسټ لټون (rand_getBlockByHeight، د لوړوالي له مخې rand_getFinality، د rand_getBlocks یا rand_getCompactBlocks هغه لړۍ چې ورته رسېږي) د -32010 تېروتنه له data.floor سره ځواب ورکوي: له آرشیف څخه یې وپوښتئ. د هش پر بنسټ لټون د هغه بلاک لپاره چې نوډ یې نور نه لري null ځواب ورکوي، لکه د هغه بلاک لپاره چې هېڅکله نه و موجود. د والټ لټون اغېزمن نه دی، ځکه یادښتونه او nullifiers هېڅکله نه پرې کېږي.

د پرې شوي نوډ د پیل ازموینه جوړښتي ده (بلاک 0 او ساتل شوي بلاکونه، د هغوی QCs، د مور بلاک تړاوونه او مشران)، نه له پیدایښت څخه بیا اجرا، او ځان نه ترمیموي: که ناکامه شي، له آرشیف څخه بیا همغږي وکړئ. پرې شوې د معلوماتو لارښود له v0.5.7 څخه په زړې جوړونې مه پرانیزئ مګر دا چې له --verify-chain off سره چلېږي: د هغې ډیفالټ ازموینه له پیدایښت څخه بیا اجرا کوي، بلاک 1 ورک مومي، او دفتر تر پیدایښت پورې پرې کوي.

د ثابتوونکي کوربه‌توب

پر زنځیر 20 یو والټ د هرې بستې لپاره دوه ثبوتونه جوړوي، او لوی یې شاوخوا 6 GB حافظې ته اړتیا لري. هغه والټ چې دا نشي زغملای، کولای شي دا ثبوت هغه استازي ثابتوونکي ته وسپاري چې ورسره جوړه شوی: جلا rand-prover باینري، یا هماغه خدمت چې د یو نوډ لخوا کوربه شوی وي.

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 اختیار په مرسته د هغه له لارې ثبوتونه جوړوي. د ثابتوونکي اورېدونکی (listener) خپل جلا دی او هېڅکله د RPC میتود نه دی: هغه پته چې له --rpc سره برابره وي، نه منل کېږي. د --prover سره نوډ یوازې هغه وخت پیل کېږي چې <prover-home>/prover.key.json موجود وي (اصلي ځای یې <datadir>/prover دی) او د هر ثبوت سلاټ لپاره 5.74 GB او سربېره پر دې 1 GiB حافظه شته وي. --prover-max-parallel د سلاټونو شمېر ټاکي او په اصلي توګه یو دی.

په chain 20 کې ثابتوونکي ته د والټ د لیدلو کلیډ او یو نوی مالګه (salt) لېږل کېږي، نه د لګښت کلیډ. والټ د لګښت کلیډ پر بنسټ د اجازې ثبوت پخپله جوړوي. نو یو جوړه شوی ثابتوونکی د هغه والټ ټول تاریخ لوستلی شي، خو لګښت نه شي کولی. اورېدونکی پر 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 دی. بیا چلول (replay) د هرې بنډل ثبوت بیا تاییدوي. نو هغه build چې د محدودیتونو (constraints) ټولګه یې له هغې ټولګې توپیر ولري چې chain ورباندې جوړ شوی، په لومړي بنډل کې درېږي.

څنګه تاییدوونکی شو

تاییدوونکی یو روان chain ته د ګرو (bond) له لارې ورګډېږي، نه د نوي genesis له لارې. نوډ د --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-بلاکه epoch پولو په تېرېدو سره. په chain 20 کې ګرو دویم ګام دی. د دې chain genesis staking.admission_by_vote ټاکي. نو هغه ګرو چې نوی کلیډ ثبتوي تر هغه نه منل کېږي چې هغه تاییدوونکي چې د رایې ورکولو له وزن څخه تر دوو پر دریو ډېره برخه لري، کلیډ ته د منلو رایه ورکړي. هر یو یې د rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 سره لاسلیک کوي، او یو یې رایې د rand-node admit submit سره سپاري (کمانډ لاین). rand_getAdmitted هغه کلیډونه لیست کوي چې رایه یې اخیستې خو لا نه دي ثبت شوي. په یوه epoch پوله کې د فعال وزن له 2,500 bps څخه زیات نوی وزن نه شي جوړېدای. Staking دا بهیر ګام په ګام تشریح کوي. د یو خصوصي ازمیښتي chain لپاره، rand-node genesis یو chain جوړوي:

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 دی. که نور بیرغونه ورنه کړل شي، genesis نه hc_auth لري، نه gas برخه او نه memo. 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 د جوړولو سکرېپټ ورګډې کړې. ستاسو نوی chain باید --binding-domain 1 ورکړي: د v0.6.8 والټ له 14 تر 19 پرته پر هر chain id د genesis پورې تړلې بڼې ثبوت جوړوي.

پر سرور پلي کول

د ریپازیټوري deploy/ لارښود هغه سکرېپټونه لري چې fleet یې کاروي. deploy/push-to-vps.sh <ip> <letter> "<bootstraps>" [validator|observer] یو Linux سرور چمتو کوي: سرچینه rsync کوي، build کوي، /usr/local/bin/{rand-node,rand} نصبوي، د genesis hash پر بنسټ datadir پیلوي او د rand-node systemd خدمت نصبوي. deploy/rebuild-vps.sh <ip> پر نوي commit بیا build کوي او ډېټا ساتي او بیا پیل کوي. دوه خبرداري شته. د چمتو کولو سکرېپټ له deploy/genesis.json څخه پیلېږي، چې د chain 20 دوتنه نه ده. نو د testnet لپاره نوډ په لاس د deploy/genesis-chain20.json (پر main، پورته وګورئ) څخه جوړېږي. او دواړه سکرېپټونه /root/fullnode د --delete سره rsync کوي. نو هر کلیډ چې د دې ونې دننه ساتل شوی وي، په راتلونکي rebuild کې ړنګېږي. کلیډ په /root/keys کې وساتئ، لکه څنګه چې fleet یې ساتي او لکه څنګه چې د 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 toolchain اړتیا ده. یو 1-vCPU او 2 GB سرور باینري فایلونه build کولی نه شي. په بل ځای یې build کړئ او بیا یې دننه کاپي کړئ. د تاییدوونکي او راټولوونکي چلول اندازې او ګام په ګام جوړونه لري.

اکسپلورر

randscan.org د تاییدوونکي E ترڅنګ چلېږي او chain 20 انډکس کوي. د هغه REST API او WebSocket فیډ له نوډ پرته د chain د لوستلو تر ټولو اسانه لاره ده (Explorer API). اکسپلورر خلاصه سرچینه ده (randprotocol/randscan). د هغه انډکسر یوازې د یو نوډ rand_* JSON-RPC او یو PostgreSQL ډېټابېس ته اړتیا لري، نو ستاسو د خپل نوډ پر وړاندې هم چلېدای شي.