دا پاڼه وکاروئ ترڅو پوه شئ چې یوه راکړه ورکړه کله وروستۍ کېږي، څومره تاییدوونکي باید فعال وي، او د بلاک هغه ساحې چې په RPC او سپړونکي کې یې وینئ څه مانا لري. اجماع د ځنځیري HotStuff BFT ده چې د ونډې له مخې وزن لرونکي نصابونه لري؛ په chain 20 کې دا له 26 تاییدوونکو څخه 18 دي.
هغه قواعد چې نوډ یې چلوي
| قاعده | څنګه چې پلي شوې |
|---|---|
| نصاب | د نصاب سند (QC) د Dilithium2 رایو یوه ټولګه ده چې له هغو تاییدوونکو څخه راځي چې د ټولې ونډې په کلکه له 2/3 څخه زیات لري |
| د مشر مهالوېش | خالص دوراني ترتیب: د لید v مشر validators[v mod n] دی، او ټولګه د پتې له مخې ترتیب شوې ده. ونډه رایو ته وزن ورکوي، نه د مشر ټاکلو ته |
| وړاندیز | د لید v مشر هغه وخت وړاندیز کوي چې د v − 1 لپاره QC ولري، یا د v لپاره د NewView پیغامونو نصاب ولري. هغه وړاندیز چې یوه ناسمه راکړه ورکړه پلي کوي، هماغه راکړه ورکړه غورځوي، نه ټول بلاک |
| رایه ورکول او خوندیتوب | یو تاییدوونکی په هر لید کې یو ځل رایه ورکوي، او یوازې هغه بلاک ته چې د خپل قفل په اړه خوندي وي (د هغه د توجیه QC له قفل شوي QC څخه نوی وي، یا بلاک قفل شوی بلاک غځوي). د خوندیتوب حالت مخکې له دې چې رایه له نوډ څخه ووځي، په RocksDB کې fsync کېږي |
| د لاسلیک ډومېن | په هغه جینیسس کې چې consensus_domain: 1 لري (chain 20، او له 15 راهیسې هر chain) د هرې رایې، نوي لید او وړاندیز لاسلیک د جینیسس هش پوښي (rand-vote-2، rand-newview-2، rand-block-2)، نو د یوه chain لاسلیک په بل هېڅ chain کې نه تاییدېږي. Chain 14 او تر هغه مخکې پرته له دې لاسلیک کول. د chain 20 binding_domain: 1 همدا قاعده د راکړې ورکړې ثبوتونو او لاسلیک شویو کړنو ته غځوي (راکړې ورکړې) |
| خوري وړاندیزونه | یو ریپلیکا د هر (لید، مشر) لپاره یو بلاک ساتي؛ د هماغه مشر له خوا د هماغه لید لپاره دویم، توپیر لرونکی بلاک د دوه مخۍ په توګه ردېږي. هغه وړاندیز چې د ریپلیکا له خپل لید څخه له 8 لیدونو زیات مخکې وي (PROPOSAL_VIEW_WINDOW) د لاسلیک له کتلو مخکې ردېږي؛ ډکه احتمالي ونه مخکې له دې چې کوم شی رد کړي، له څانګې بهر بلاکونه باسي |
| د قفل خوشې کول | قفل هېڅکله په اتوماتیک ډول نه ټیټېږي (CON-4، v0.6.8). دا یوازې هغه وړاندیز ته تسلیمېږي چې د توجیه QC یې ترې لوړ رتبه ولري، یا د قفل شوي بلاک رارسېدو ته. د لاسلیک شویو NotHeld ځوابونو نصاب د چلوونکي لپاره ثبتېږي او هېڅ شی نه خوشې کوي، او یو تاییدوونکی خپلې رایې ثبتوي ترڅو هېڅکله د هغه بلاک لپاره NotHeld لاسلیک نه کړي چې رایه یې ورکړې وه. د سر څخه پورته هر تصدیق شوی بلاک ساتل کېږي او د بیا پیل پر مهال بېرته راګرځول کېږي، نو د ټول بېړۍ بیا پیل QC په داسې بلاک نه پرېږدي چې هېڅوک یې نه لري. هغه تاییدوونکی چې قفل شوی بلاک یې د تل لپاره ورک شوی وي، په لاس او بېانټرنېټه خوشې کېږي: rand-node safety release-lock |
| د QC جوړول | هر تاییدوونکی QCs په محلي توګه له خپرو شویو رایو څخه جوړوي، نو chain تثبیت ته دوام ورکوي کله چې راتلونکی مشر آفلاین وي |
| تثبیت | ځنځیري درې-QC قاعده: یو بلاک هغه وخت تثبیتېږي چې درې سندونه په پرلهپسې لیدونو کې v, v+1, v+2 پر هغه ځنځیر شي او دا ځنځیر بېرته تثبیت شوي سر ته ورسېږي |
| د وخت تېرېدل او د لید بدلون | اساس --view-timeout-ms 3,000 ms دی، په هر پرلهپسې وخت تېرېدو سره دوه چنده کېږي، او په هر پرمختګ سره بېرته پیل ته راګرځي. د وخت تېرېدو سند پر بنسټ ګامساتونکی (CH-1، v0.6.8): هغه ریپلیکا چې ټایمر یې ودرېږي په خپل لید کې پاتې کېږي او یو NewView لاسلیک کوي چې راتلونکی لید غواړي. دا هغه وخت یو لید ته ننوځي چې د مخکیني لید لپاره QC ولري، یا کله چې هغو تاییدوونکو چې د ونډې له 2/3 څخه زیات لري، هماغه لید یا ترې وروسته لید غوښتی وي؛ دا هغه وخت یوځای کېږي (خپله غوښتنه لاسلیک کوي) چې له 1/3 څخه زیات د خپل لید څخه وروسته لید وغواړي. د هېڅ یوه تاییدوونکي NewView هېڅوک نه خوځوي. لیدونه محدود دي (MAX_VIEW_AHEAD = 10⁶) |
| سرعت تنظیمول | مشر هغه وخت تش بلاک وړاندیز کوي چې هېڅ شی په انتظار کې نه وي، لږ تر لږه --block-interval-ms (اصلي اندازه 1,000 ms) د هر وړاندیز کوونکي له وروستي لیدل شوي بلاک وروسته |
| د رایې او خپرونې حدونه | هغه رایې چې له 8 لیدونو زیات مخکې وي له پامه غورځول کېږي او د هر (لید، رایه ورکوونکي) لپاره یوه رایه شمېرل کېږي؛ د اجماع خپرونه د هر لېږدوونکي همتا لپاره اندازه کېږي (burst 256، 64/s)؛ هغه وړاندیز چې مور یې نامعلومه وي یوازې هغه وخت د یتیم په توګه ساتل کېږي چې وړاندیز کوونکی یې د اوسنۍ دورې په ټولګه کې یا د راتلونکې دورې په ټولګه کې د خپل لید مشر وي، د تثبیت شوي سر د ونې په حد کې وي، او اندازه او tx ریښه یې سمه وي (د یتیمانو حوض په 64 MiB محدود دی، او له v0.6.1 راهیسې د هر وړاندیز کوونکي لپاره په 16 یتیمانو). له v0.6.8 راهیسې یو وړاندیز یوازې هغه وخت بیا لېږدول کېږي، او یتیم یوازې هغه وخت ساتل کېږي، چې د راکړو ورکړو لیست یې هغې ریښې ته هش شي چې سرلیک یې ورته ژمن دی او هېڅ راکړه ورکړه پکې تکرار نه وي (GOSSIP-2) |
| د بلاک حدونه | د chain max_block_bytes د راکړې ورکړې بایټونه (په اصلي توګه 4 MiB، د chain 20 په جینیسس کې 20 MiB) او 2,000 راکړې ورکړې، چې د وړاندیز کوونکي له خوا او بیا د هر ریپلیکا له خوا په Ledger::apply_block کې پلي کېږي |
| د بلاک وخت | په هغه chain کې چې bridge برخه لري: د بلاک timestamp_ms نشي کولی د خپلې مور له وخت څخه مخکې وي (TimestampRewind) او نه ترې له 60 s زیات ولاړ شي (TimestampLeap)، او یو تاییدوونکی له هغه بلاک څخه خپله رایه منع کوي چې د هغه له خپل ساعت څخه له 15 s زیات مخکې وي؛ لاندې وګورئ |
د درې پرلهپسې لیدونو د تثبیت قاعده بنسټیزه ده: نرمول یې د متضاد نهاییتوب هغه تېروتنه بېرته پرانیزي چې fullnode یې لپاره د بیا راګرځېدو ازموینه لري. هر هغه څه چې پېرودونکی یې د RPC له لارې ویني تثبیت شوي دي: یوازې تثبیت شوي بلاکونه وړاندې کېږي، او د WebSocket newHeads جریان د هر تثبیت شوي بلاک لپاره یو خبرتیا په ترتیب سره لېږي.
دا جدول v0.6.8 دی، هغه خپرونه چې chain 20 یې چلوي. د هغې درې قواعد په v0.6.8 کې نوي دي (audit v6) او له هغه وخته چې chain 20 په 2026-10-01 فعال شو، فعال دي: د وخت تېرېدو سند پر بنسټ ګامساتونکی (CH-1)، د قفل اتوماتیک خوشې کول نشته (CON-4) او د وړاندیز د راکړو ورکړو د لیست کتنه (GOSSIP-2). په chains 18 او 19 (v0.6.7) کې د یوه تاییدوونکي لاسلیک شوي NewView هر ریپلیکا خپل لید ته خوځاوه، او قفل د ونډې د نصاب له لاسلیک شویو NotHeld ځوابونو سره ټیټېده. ګامساتونکی او د قفل قاعده بدلوي چې تاییدوونکي څه او کله لاسلیک کوي، نو v0.6.8 د chain 20 له پرې کولو سره د ټولو د یوځای درولو او یوځای پیلولو په توګه خپور شو، هېڅکله نوډ په نوډ نه.
د testnet شمېرې
Chain 20 26 تاییدوونکي لري، هر یو یې په کره توګه په 1,000 RAND ونډه لري، او ټول 26 یې د هغو کلیدونو او همتا پېژندنو سره په جینیسس کې دي چې chains 17 تر 19 یې چلول. په chain 15 کې اتلس یې د chain 14 په کلیدونو په جینیسس کې وو، او اته نور په 2026-09-27 د v2 ثبتونو لاندې ګرو شول او له 43مې دورې څخه فعال وو. ونډه یو شان ده، نو نصاب د سرونو شمېر دی: له 26 څخه 18 باید آنلاین وي ترڅو هر څه تثبیت شي. د 17 فعالو سره لیدونه مخ ته ځي او هېڅ شی نهایي کېږي نه. د n برابرو تاییدوونکو ټولګه د ونډې له 2/3 څخه زیات ته اړتیا لري: له 2 څخه 2، له 4 څخه 3، له 6 څخه 5، له 18 څخه 13، له 26 څخه 18. د جینیسس د وزن سقف (د هر تاییدوونکي لپاره 3,333 bps) د برابرو ونډو ټولګه نه محدودوي.
بلاکونه په اصلي 1,000 ms سرعت تنظیمېږي. په chain 15 کې دوی په عمل کې نږدې په هرو 1.2 s کې رارسېدل (د هغه په لومړیو 29 ساعتونو کې په اوسط ډول 1.18 s)؛ په chain 20 کې سپړونکي په 3,270 لوړوالي کې د 1.34 s اوسط راپور ورکړ (2026-10-01، avg_block_time_ms). سپړونکی د بلاک هغه اوسط وخت راپوروي چې یې ویني (avg_block_time_ms په GET /stats کې). د تاییدوونکي لید هر کله چې لیدونه وخت تېر کړي له لوړوالي څخه مخکې ځي، له همدې امله rand_getHead دواړه راپوروي.
دورې
د تاییدوونکو ټولګه په هرو epoch_blocks = 1,000 بلاکونو کې (د جینیسس یو پارامیټر) له راجستر څخه بیا ترلاسه کېږي. epoch(h) = h / 1000؛ د e ≥ 1 دورې ټولګه له راجستر څخه د e − 1 دورې د وروستي بلاک پر مهال ترلاسه کېږي: هر هغه قطار چې stake ≥ 1,000 RAND ولري، د ونډې له مخې لومړي 100، د پتې له مخې ترتیب شوي. په هغه chain کې چې staking برخه نه لري، ګرو په راتلونکي سرحد کې وزن کېږي. په chain 20 کې دا دوه نورې دورې انتظار باسي او په سرحد کې د فعال ګرو شوي وزن د 2,500 bps د هرې دورې د ننوتلو بودیجه لري (6,500 RAND تر هغه چې ټولګه 26,000 ولري)، او هغه ګرو چې نوی تاییدوونکی ثبتوي ردېږي، مګر دا چې ټولګې لومړی د AdmitValidator له لارې کلي ته رایه ورکړې وي (staking.admission_by_vote). د chain 19 بودیجه په هره دوره کې ثابت 10,000 RAND وه، او د منلو رایه یې نه درلوده. له ګرو ایستل په راتلونکي سرحد کې وزن کموي، په داسې حال کې چې اندازه یې دوه دورې انتظار باسي ترڅو د ایستلو وړ شي. rand_getEpoch دوره، د دورې اوږدوالی او د راتلونکې ټولګې وړاندوینه راګرځوي. ونډه اچول وګورئ.
بلاک څه لېږدوي
{
"hash": "647b…", "height": 50, "view": 92, "parent": "2d41…",
"proposer": "3v3VBJ…", "timestamp_ms": 1788000123456,
"tx_root": "0000…", "state_root": "a1b2…", "justify_view": 91,
"tx_count": 0, "transactions": []
}view هغه لید دی چې بلاک پکې وړاندیز شوی و او justify_view د هغه QC لید دی چې بلاک یې د خپلې مور لپاره لېږدوي. timestamp_ms د وړاندیز کوونکي له خوا ټاکل کېږي، د راتلونکې برخې په حدونو کې. state_root له بلاک وروسته دفتر ته ژمن دی. په chain 20 کې:
inner = blake3("rand-state-8" || tree_root || nullifier_root || validators_root || programs_root
|| bridge_root || tokens_root
|| faucet_epoch || faucet_minted_in_epoch || bond_queue_root
|| gas_price || byte_price
|| program_state_root)
state_root = blake3("rand-state-admitted-1" || inner || admitted_root)Chain 19 همدا ساحې پرته له program_state_root څخه، د rand-state-7 لاندې، او پرته له پوښ څخه تثبیتولې.
اجزا په genesis پورې اړه لري. هغه زنځیر چې هېڅ اختیاري برخه نه لري، لومړني څلور اجزا د rand-state-2 لاندې ثبتوي. د bridge برخه bridge_root ورزیاتوي. د tokens برخه له هغې وروسته tokens_root ورزیاتوي او ټول هش د rand-state-4 ډومېن ته اړوي؛ هغه genesis چې د bridge برخه لري باید د tokens برخه هم ولري، نو زنځیر 20 دواړه لري. د aggregation برخه بیا د aggregatorانو ریښه ورزیاتوي (په هغه زنځیر کې چې ټوکنونه نه لري، د rand-state-3 لاندې)؛ زنځیر 20 دا برخه نه لري. د staking برخه د faucet دوه د دورې شمېرونکي او د bond کتار ریښه (rand-bond-queue-1) په پای کې ورزیاتوي او ټول هش د rand-state-5 ډومېن ته اړوي، که نور هر څه فعال وي که نه؛ زنځیر 14 داسې برخه نه درلوده او د rand-state-4 لاندې یې هش کاوه، او زنځیرونو 15 تر 17 د rand-state-5 لاندې هش کاوه. د vesting برخه له هغې وروسته د vesting د راجستر ریښه ورزیاتوي او هش د rand-state-6 ډومېن ته اړوي؛ زنځیر 20 دا برخه نه لري. د gas برخه چې dynamic کنټرولر ولري، روان gas_price او byte_price، هر یو big-endian u64، له نورو ټولو وروسته ورزیاتوي او هش د rand-state-7 ډومېن ته اړوي. دا د زنځیر 19 ډومېن و، او زنځیر 20 هم بیې په خپله ریښه کې ساتي: بیې په هر بلاک کې یو ځل بدلېږي، د بلاک له معاملو وروسته او له ریښې مخکې (فیسونه). د gas هغه برخه چې ثابتې بیې لري په ریښه کې نه ده. د program_state برخه (RPL-2) له بیو وروسته د هر پروګرام د cells او vaults ریښه ورزیاتوي او هش د rand-state-8 ډومېن ته اړوي: دا د زنځیر 20 ډومېن دی. د Audit v6 د staking حالت د دې ریښې دننه نه، بلکې د هغې شاوخوا ورګډېږي: د staking.admission_by_vote لاندې (زنځیر 20) ریښه blake3("rand-state-admitted-1" || inner || admitted_root) ده، او د staking.slashing لاندې (چې تر اوسه په هېڅ زنځیر کې نه دی) دویمه پوښ بندي شوې ټولګه ورزیاتوي. tokens_root د blake3("rand-token-leaf-1" || bincode(TokenInfo)) پاڼو Merkle ریښه ده چې د index په ترتیب راځي، نو د هر ټوکن metadata، واک، mint_nonce، عرضه او د هرې پشتوانې locked اندازه د اجماع حالت دی: هغه دوه نوډونه چې د یوه ټوکن په یوه قطار کې سره اختلاف ولري، د زنځیر په اړه سره اختلاف لري. په زنځیر 20 کې د ټوکن ریښه د راجستر غځونه هم د rand-token-registry-3 لاندې ورګډوي: د max_tokens حد، سوځول شوې د ثبت فیس، د note د ارزښت حد او د bridge د mint حد روانې کړکۍ. د bridge ریښه خپروونکي، د ساتونکو ټولګې، لګول شوي د تصدیق digestونه، د سوځولو ترتیب، د PQ ساتونکو کیلي، د درولو کیلي، د درولو بیرغ او د حکومتولۍ دوه nonceونه پوښي؛ د دارایيو راجستر له هغې ووت او tokens_root ته ولاړ. د زنځیر 20 bridge rules_v2 لري، نو د rotation nonce او د ټولیز حد پیرامیټرونه ورزیاتېږي او ډومېن یې rand-bridge-state-5 دی (د زنځیر 14 ډومېن rand-bridge-state-4 و)؛ بیا دا ریښه د راتلونکو پیغامونو د replay لاندې حد (rand-bridge-replay-floor-1) پوښي، او په زنځیر 20 کې د rotation قواعد او پاتې rotationونه (rand-bridge-rotation-1) او د فیس ډله (rand-bridge-fees-1) هم پوښي. د validatorانو راجستر په validators_root کې هش کېږي (په زنځیر 20 کې د پاڼې ډومېن rand-validator-leaf-4 دی چې د هر قطار activation_epoch هم لري؛ په هغه زنځیر کې چې د staking برخه نه لري rand-validator-leaf-2)، نو هغه نوډ چې د راجستر په یوه قطار کې اختلاف ولري، د زنځیر په اړه اختلاف لري.
د بلاک وخت محدود دی (B2)
په هغه زنځیر کې چې bridge لري، د بلاک timestamp د ساتونکو د ټولګې پای ټاکي او دا هم ټاکي چې د یوې پشتوانې د mint ورځنی حد کومې ورځې ته حسابېږي. نو هغه leader چې ساعت مخکې ټوپ کړای شي، کولای شي د بدلې شوې ټولګې د مهلت کړکۍ وخت مخکې پای ته ورسوي یا د یوې ورځې له حد څخه تېر شي. زنځیر 20 د bridge برخه لري، نو درې قواعد پلي کېږي او ټول یې په همدې برخې پورې تړلي دي:
| قاعده | حد | ډول |
|---|---|---|
| شاته تګ نشته | timestamp_ms ≥ parent.timestamp_ms (برابر هم جواز لري)، که نه BlockError::TimestampRewind؛ وړاندیز کوونکی max(now, parent.timestamp_ms) خپروي | د اعتبار قاعده، په replay او sync کې هم کتل کېږي |
| ټوپ نشته | timestamp_ms ≤ parent.timestamp_ms + MAX_TIMESTAMP_STEP_MS (60,000 ms)، که نه BlockError::TimestampLeap | د اعتبار قاعده، په replay او sync کې هم کتل کېږي |
| د ساعت توپیر | validator هغه بلاک ته رایه نه ورکوي چې له خپل ساعت څخه تر MAX_CLOCK_DRIFT_MS (15,000 ms) زیات مخکې وي | یوازې د رایې قاعده: بلاک په اټکلي ونه کې پاتې کېږي، هغه quorum چې ساعتونه یې سره برابر وي لا هم تصدیقولای یې شي، او د ثبت شوي تاریخ replay هېڅکله دا قاعده نه پلي کوي |
په هغه زنځیر کې چې bridge لري، هر validator ته NTP اړین دی. هغه validator چې ساعت یې له 15 ثانیو زیات توپیر ولري، ناسم leader دی (کېدای شي وړاندیزونو ته یې رایه ونه رسېږي) او ناسم رایه ورکوونکی هم دی (کېدای شي د یوه صادق leader په وخت بلاک ته رایه ورنه کړي). تر څو چې د صادقې اکثریت ساعتونه سره برابر وي، له دې دواړو څخه هېڅ یو زنځیر نه دروي، خو هغه fleet چې ساعتونه یې نه دي برابر شوي، د ژوندیتوب حاشیه بې ګټې له لاسه ورکوي.
د genesis timestamp_ms باید د پیل رښتیني وخت ته نږدې وي. که په تېر کې ډېر لرې وي، د بلاک وخت له رښتیني ساعت څخه شاته پاتې کېږي تر هغه چې د ګام حد یې پوره کولو ته پرېږدي، په هر بلاک کې تر ټولو زیات 60 s. که له 15 s زیات په راتلونکي کې وي، بلاک 1 هېڅ نه ثبتېږي: هره رایه، د leader خپله رایه هم، تر هغه ساتل کېږي چې رښتینی وخت هغې ته ورسېږي. له اوږدې درېدنې وروسته همدا پوره کول کولای شي د mint حد ورځ له رښتینې ورځې چټکه بدله کړي، چې حد یې د راټول شوي ځنډ د هرې بشپړې ورځې لپاره د یوې اضافي ورځې حد دی.
د client لپاره نهاییت
- یوه معامله هغه وخت نهايي ده چې
rand_getTransaction(hash)یو بلاک راوګرځوي. دrand_sendTransactionله خوا منل یوازې mempool ته داخلېدل دي. - هغه بلاک چې RPC یې وړاندې کوي یا explorer یې index کوي، ثبت شوی دی. د نهاییت د انتظار کړکۍ نشته؛ د explorer لارښود هم همدا وايي.
- هغه head چې له
rand_subscribe["newHeads"]څخه راځي، داسې head دی چې نوډ به یې له لاسه ورنه کړي: تر هغه چې بلاک په ذخیره کې ثبت شوی نه وي، هېڅ نه لېږل کېږي. - هغه نوډ چې شاته پاتې شي، هر څه بیا تاییدوي: هر سند، هر bundle او د call ثبوت، هره رسید، مخکې له دې چې sync شوی بلاک ومني. د نهاییت لاسلیکونو ته هېڅکله د ثبوتونو پر ځای باور نه کېږي.
د بیا رغونې لنډ لارښود، د fullnode له خپل لارښود څخه: که لوړوالی مخکې نه ځي او peer_count ټیټ وي، د شبکې ستونزه ده؛ که لوړوالی مخکې نه ځي او همځولي سم وي، معنا یې دا ده چې د stake له 2/3 څخه لږ آنلاین دی؛ په پیل کې CORRUPT CHAIN معنا دا ده چې نوډ زیانمن شوی پای پرې کړی او بیا sync کېږي.