دا مخ د ثبوت جوړولو لپاره د ماشین د اندازې ټاکلو، دا پوهېدو لپاره چې ولې یو لېږد له یوې دقیقې ډېر وخت نیسي او ولې د بلاک ځای، نه محاسبه، د لېږد ظرفیت محدودوي، او دا پوهېدو لپاره وکاروئ چې کله د ثبوت سیستم بدلېږي څه شی ماتېږي. هر څه چې یو تاییدوونکی یې مني د داسې ثبوت پر بنسټ ولاړ دي چې هغه پخپله تصدیق کړی وي.
یو ثبوت څه بیانوي
یوه اړیکه، د هر هغه پروګرام لپاره چې چین یې چلوي:
دا RV32IM پروګرام، چې په
base_pcکې پیل شوی، پر یو خصوصي ورودي وکتور چلېدلی چېH_INورته تعهد کوي او پر یوې عامه ورودي برخې چېH_PUBورته تعهد کوي، په2ᵗ − 1دورو کې دننه ودرېدلی، ترGAS_LIMITګاز زیات یې نه دي لګولي او دا اته خروجي کلمې یې خپرې کړې دي.
پروګرام د سرکټ دننه د خپل digest hc له لارې پېژندل کېږي؛ تصدیقوونکی هېڅکله د لارښوونې کلمه نه ویني. یو خوندي شوی لېږد همدا اړیکه ده چې پر پټشتمنۍ بنډل guest پلي کېږي، چې په لاس جوړ شوی ۴-ننه-۴-وتو پروګرام دی او hc یې د جینیسس په فایل کې د hc_bundle په توګه ټاکل شوی. چین 20 د guest v3 ټاکلی (guests::bundle_hidden_v3، 60af094a…6e3fce، له چین 17 راهیسې). چینونو 14 او 15 v1 ټاکلی و (83d3a370…cd0ef8) او چین 16 بېڅانګې v2 (651043e2…839b). له چین 17 راهیسې هر بنډل یو دوهم ثبوت هم لري، د auth guest (guests::auth، جینیسس hc_auth، 1e4e347f…5639c1): د بنډل ثبوت د لیدو کیلي اخلي، او د auth ثبوت ښيي چې لېږونکی د هغې تر شا د لګښت کیلي لري. دا وېشل شوې واکمنول دي، او همدا ده چې یو جوړه شوي ثبوت جوړوونکي ته، چې یوازې د لیدو کیلي لري، اجازه ورکوي چې د بنډل ثبوت جوړ کړي. پټشتمنۍ guest د ۲-ننه-۲-وتو bundle guest ځای ونیو چې تر چین 13 پورې کارېده، چې په fullnode کې یوازې د ازموینو لپاره پاتې دی او هېڅ چین یې نه ټاکي. یو محرم غوښتنه همدا اړیکه ده چې پر یو ځای پر ځای شوي پروګرام پلي کېږي (پروګرامونه).
والټ څنګه د بنډل ثبوت جوړوي
rand send <rand1…> <amount> خصوصي کار په محلي توګه ترسره کوي، او یوازې ثبوتونه، تعهدونه، nullifiers او مهر شوې لفافې چین ته رسېږي:
- سکن کړئ ونه د لیدو کیلي سره او ورودي وټاکئ: په ۲–۳ سلاټونو کې تر دوو پورې RAND نوټونه چې اندازه او فیس پوښي، او د ټوکن لېږد یا سوځولو لپاره په ۰–۱ سلاټونو کې د ټوکن تر دوو پورې نوټونه، په داسې حال کې چې RAND نوټونه یوازې فیس پوښي. یو نه کارول شوی ورودي سلاټ ډمي دی: اندازه 0، د والټ ملکیت، د غړیتوب ناکامي یې په سرکټ کې پټه شوې، خو nullifier یې بیا هم خپرېږي. له guest v2 راهیسې guest بېڅانګې دی: د ډمي لاره د یو ریښتیني نوټ په څېر ټولې 32 کچې پورته هش کېږي.
- راواخلئ د سر لنګر (
rand_getAnchor) او د هر ریښتیني ورودي 32-کچیز Merkle شاهد (rand_getWitness(index))، او بېرته راغلې ریښه د لنګر سره پرتله کړئ. - جوړ کړئ څلور وتنې: د ترلاسه کوونکي نوټ او د بدلون نوټ په هغه ډله کې چې ارزښت لېږدوي، حتی په صفر کې هم شتون لري، او په نورو ځایونو کې د صفر اندازې ډمي نوټونه، چې یوې یوځلي کیلي ته مهر شوي.
- مهر کړئ هره وتنه په یوه لفافه کې (ML-KEM-768 ترلاسه کوونکي ته، او د لېږد کیلي د والټ د
ovkلاندې پوښل شوې)، ټول لېږد د خپل عمل سره راټول کړئ، او د هغه تړون واخلئ:blake3("rand-tx-bind-1" || …)پر هغه لېږد چې ثبوتونه یې خالي شوي، اته کلمې (لېږدونه). په چین 20 کې، چې جینیسس یېbinding_domain: 1ټاکي، داblake3("rand-tx-bind-2" || …)دی چې لومړی د جینیسس هش او بیا د چین id پکې راځي، نو هغه ثبوت چې د یو چین لپاره جوړ شوی په بل هېڅ چین کې نه تصدیقېږي، حتی په هغه کې هم چې ورته د چین id لري. هغه والټ چې له v0.6.8 زوړ وي زوړ تړون اخلي، او چین 20 یې ثبوتونه ردوي. - واک ورکړئ: یو نوی 256-بیټي مالګه (salt) راوباسئ او د auth guest ثبوت د هغې پر 16-کلمیز خصوصي ورودي، د لګښت کیلي او مالګې، جوړ کړئ، په داسې حال کې چې تړون د عامه ورودي برخې په توګه وي، په پوړ 10 کې. دا له لګښت کیلي څخه
nkترلاسه کوي اوc = H(AUTH, nk ‖ salt)خپروي، چې بنډل یې دauth_commitپه توګه لېږدوي. - ثبوت جوړ کړئ د بنډل guest پر هغې 1,212-کلمیز خصوصي ورودي (د لیدو کیلي
nk، څلور ورودي سلاټونه د خپلو لارو سره، لنګر، څلور وتنې،fee،burn_a،burn_r، خصوصي شتمنيA،time، مالګه) د عامه ورودي برخې په توګه د همغه تړون سره، په پوړ 14 کې. ثبوت ملکیت، غړیتوب، دا چې هر ریښتینی ورودي د خپل سلاټ شتمني لري، څلور nullifiers، همغهc، او دوه توازنونهin₀ + in₁ = out₀ + out₁ + burn_aاوin₂ + in₃ = out₂ + out₃ + fee + burn_rښيي. دا هغه ثبوت دی چې یو جوړه شوی ثبوت جوړوونکی یې د والټ پر ځای جوړولی شي؛ د auth ثبوت د والټ پر خپل ماشین جوړېږي. - وګورئ د ثبوت خپور شوی digest د هغه سره چې له ساده متن څخه محاسبه شوی، او
Transaction { chain_id, bundle, action: None }وسپارئ.
له چین 14 راهیسې ترتیب مهم دی: لفافې او عمل له ثبوتونو مخکې شتون لري، ځکه چې ثبوتونه ورته تعهد کوي. د غوښتنې لپاره، د غوښتنې ثبوت لومړی جوړېږي او هغه هم د تړون دننه وي. په hardening_v6 چین کې د غوښتنې ثبوت پخپله د لېږد پر یو غوښتنې تړون جوړېږي چې دواړه ثبوتونه یې خالي شوي (rand-call-bind-1 په چینونو 16 تر 19 کې، rand-call-bind-2 په چین 20 کې د جینیسس هش سره)، چې د فیس بنډل nullifiers پوښي، نو د بل بنډل لاندې نه شي کاپي کېدای.
proving bundle (tier 14; about a minute on a laptop)…
proved in 98.3s: tier 14, 1423170 bytes
submitted transfer 4f2c… 1.5 RAND out, 98.499 RAND change, fee 0.001 RAND, anchored at height 192دا ثبت د چین 14 پورې د fullnode له لارښود څخه د والټ د خروجي بڼه ده؛ ښودل شوی د بایټونو شمېر د تولیدي پروفایل د هغه بنډل ثبوت دی چې په چین 14 کې ثبت شوی. له چین 17 راهیسې والټ، په چین 20 کې د v0.6.8 په ګډون، له دې کرښو مخکې دوه کرښې چاپوي، proving the spend authorisation on this machine (tier 10; seconds)… او authorisation proved in …: tier 10, … bytes، او د بنډل کرښه داسې لیکي: proving the bundle (tier 14; about a minute and a half on a laptop)….
همدا ماشین د هر عمل لګښت ورکوي، تل د دقیقاً یو بنډل سره: ځای پر ځای کول، غوښتنه، د ټوکن ثبت یا د ټوکن جوړول د RAND پر یو صفر ارزښت ځان ته لېږد سپرېږي، ضمانت پر داسې بنډل چې سټیک د burn_r له لارې سوځوي، او د ټوکن سوځول یا د پل سوځول پر یو بنډل چې شتمني له ۰–۱ سلاټونو (burn_a، burn_asset) سوځوي او د RAND فیس له ۲–۳ سلاټونو ورکوي. هغه شتمني چې یو لېږد یې لېږدوي یوه شاهد کلمه ده او په هېڅ عامه ساحه کې نشته.
څومره لګښت لري
د پراختیا پر لپټاپ (Apple Silicon، release build) اندازه شوي، هغه شمېرې چې د fullnode خپل اسناد یې ثبتوي:
| guest | کلمې | دورې | پوړ | ثبوت جوړول | د ثبوت اندازه (تولیدي، 80 پوښتنې) |
|---|---|---|---|---|---|
| بنډل guest v3 (چینونه 17 تر 20) | — | د پوړ-14 په بودیجه کې 4,024 دورې او د Poseidon2 273 پرمیوټیشنونه اضافي ځای | 14 | ≈ 100 s، 5.7 GB لوړه کچه؛ په چین 18 کې 102.5 تر 134.0 s اندازه شوي (2026-09-30) | ≈ 1.50 MB؛ په چین 18 کې 1,494,151 تر 1,504,260 بایټه اندازه شوي (2026-09-30) |
| auth guest (چینونه 17 تر 20) | — | 250 | 10 | ≈ 7 s؛ په چین 18 کې 6.6 تر 19.9 s اندازه شوي (2026-09-30) | ≈ 1.37 MB؛ په چین 18 کې 1,364,940 تر 1,375,371 بایټه اندازه شوي (2026-09-30) |
| پټشتمنۍ بنډل v1، ۴-ننه-۴-وتو (چینونه 14 او 15) | — | د پوړ-14 تر بودیجې لاندې، شاوخوا 2,071 دورې (13%) اضافي | 14 | ≈ 98–100 s، 5.7 GB لوړه کچه | ≈ 1.43 MB؛ په چین 14 کې 1,422,116 او 1,423,170 بایټه اندازه شوي |
bundle، ۲-ننه-۲-وتو (تقاعد شوی؛ تر چین 13 پورې) | 3,811 | ≈ 9,160 | 14 | ≈ 100 s (یوازې 94.6–97.9 s؛ دوه په یو وخت کې هر یو 114 s) | په چین 8 کې 1,321,773 بایټه اندازه شوي |
private_payment (یوه غوښتنه) | کوچنی | < 1,000 | 10 | ≈ 7 s | ≈ 1.37 MB (fib په پوړ 10 کې: د محدودیتونو د سیټ 7 لاندې 1,367,688 بایټه؛ د سیټ 6 لاندې 1,298,729) |
| یوه غوښتنه پرته له هش جدول (له چین بهر لیجر، چین 18) | 773 | — | 14 | 114.8 s | 1,498,589 بایټه |
| یوه غوښتنه د SHA-256 جدول سره (د مکلفیتونو ثبوت، چین 18) | 994 | — | 14 | 122.9 s | 1,911,152 بایټه |
| یوه غوښتنه د Keccak جدول سره (بېنومه رایه، چین 18) | — | — | 12 | 29.2 s | 3,346,865 بایټه |
تصدیق د اجماع لګښت دی چې هر نوډ یې ورکوي: د ګرمې تصدیقوونکې کیلي سره شاوخوا 16 ms، او شاوخوا 230 ms لومړی ځل چې د یوې ټاکلې بڼې لپاره کیلي جوړېږي. تصدیقوونکې کیلي د پروګرام په منځپانګې پورې اړه نه لري — د (tier, program_log_height, input_log_height, keccak_log_height, sha256_log_height, public_log_height) پر بنسټ ټاکل کېږي — نو یو نوډ د هرې بڼې لپاره یوه جوړوي او بیا یې کاروي؛ د ځای پر ځای شوي پروګرام لپاره کیلي یو ځل د ځای پر ځای کولو پر مهال په شالید کې محاسبه کېږي (پر لپټاپ شاوخوا 2 s، پر 2-vCPU سرور 7 s). د چین 13 او مخکې ۲-ننه-۲-وتو بنډل بڼه program 12, input 10, keccak 0, sha256 0, public 2, mem 16 اعلانوله؛ د چین-14 بنډل ثبوت public 4 اعلانوي، چې د اتو تړون کلمو لوړوالی دی، هېڅ هش جدول نه لري، او که بل پوړ، کوم یو جدول یا بل عامه لوړوالی اعلان کړي، مخکې له دې چې کومه تصدیقوونکې کیلي جوړه شي ردېږي. د محدودیتونو له سیټ 7 راهیسې هر اعلان شوی جدول لږ تر لږه 2⁷ قطارونه لري، نو د چین-20 بنډل ثبوت public 7 اعلانوي.
په 20م زنځیر کې یو لېږد له همدې امله شاوخوا 2.87 MB ثبوت لېږدوي، چې د بنډل ثبوت او د اجازې ثبوت دي، او یو غوښتنه له دې سربېره درېیم ثبوت هم لري. هر یو باید د جېنېسس max_proof_bytes کې ځای شي، چې په 20م زنځیر کې 4,194,304 (4 MiB) دی، لکه څنګه چې له 17م تر 19م زنځیرونو کې و. له 13م تر 16م زنځیرونو کې دا 8 MiB و.
د پټې شتمنۍ ګیسټ یوازې له دې امله په 14مه کچه کې ځای کېږي چې خپل خصوصي ننوتي په یوه لوپ کې لولي او د Merkle ازموینې د سیبلینګ لوستنې سره یوځای کوي. که همدا اړیکه په زاړه غځېدلي سبک لیکل شوې وای، په 16مه کچه کې به ودرېده او شاوخوا 400 s او 21–22 GB به یې غوښتل. په دې سره به 16 GB والټونه ترې پاتې وو.
د ثبوت جوړول په CPU پورې تړلي دي، او والټ نن ورځ په هر پلېټفارم کې د CPU بېکاېنډ کاروي. د لویو کچو په ازموینو کې ثبوت جوړوونکی یوتاره و: یو 16-vCPU ډراپلېټ د یوه کور په 99% کار کاوه. دا چې یو ثبوت بشپړېږي که نه، حافظې ټاکله، نه کورونو (د ثبوت جوړولو حافظه). په send، bond، call، deploy، bridge-mint او bridge-burn باندې --cuda بیرغ یو NVIDIA بېکاېنډ ټاکي، چې د --features cuda سره جوړښت ته اړتیا لري. د دې کرنلونه لومړی ځل په 2026-09-28 په ریښتیني هارډویر، یو NVIDIA H100، وچلېدل او د CPU له مرجع سره سمون یې درلود. خو هغه سرکټونو چېکاوټ کې چې رېلیز یې ځانته شاملوي هېڅ PTX نه دی ثبت شوی، نو تر هغه چې کرنلونه کمپایل شوي نه وي، جوړښت د no PTX for the GPU kernels سره ناکامېږي. د بېړۍ په کوم GPU نوډ کې تر اوسه هېڅ تولیدي ثبوت نه دی اندازه شوی. CPU ته بېرته ستنېدل په قصد نشته. یوه CUDA غوښتنه د ننوتو لفافه هم نشي مهرولی، ځکه چې مالګه هېڅکله له ثبوت جوړوونکي نه وځي. د 14مې کچې د پټې شتمنۍ د بنډل ثبوت لپاره د حافظې لوړه کچه شاوخوا 5.7 GB ده (Production FRI، CPU). د حافظې لویې کټګورۍ لاندې د انټرپرېټر او رېکرشن ثبوتونو پورې اړه لري (≥ 64 GB او پورته).
نوډ څنګه تصدیق کوي
منلو ته د رسېدو پړاو لومړی ارزانه ازموینې چلوي (لېږدونه)، بیا:
- د بنډل ډایجسټ له خپاره شوي ساده متن نه بیا محاسبه کوي (اینکر، څلور نلیفایرونه، څلور ژمنې،
fee،burn_a،burn_r،burn_asset،time، د بنډلauth_commit، او یوه داغکلمه چې په صفر ټاکل شوې) او غواړي چې دا د هغه څه سره برابر وي چې ثبوت خپور کړی. هغه ثبوت چې شاهد یې اړیکه ماته کړې وي یو داغي ډایجسټ خپروي چې له هېڅ ساده متن سره سمون نه خوري. ځینې ازموینې پر ځای یې جوړښتي دي (ګیسټ پخپله د یوې وتنې لېږونکی، شتمني او وخت برابروي، نو ثبوت جوړوونکی یې نشي ټاکلی)، او خصوصي شتمني په ډایجسټ کې نشته؛ - ثبوت ډیکوډ کوي او د هغه اعلان شوې لوړوالي د کچې پر وړاندې ازمويي (
check_declared_heights)، نو د یوه ثبوت پر بڼه د زنځیر پوله همغه ده چې د تصدیقوونکي ده. مخکې له دې چې کوم لاسلیک یا ثبوت وازمویل شي، پر هر سپارل شوي یا ګاسيپ شوي لېږد (او دhardening_v6لاندې، د بلاک په اعتبار ورکولو کې) د کانونیکي ثبوت یوه چاڼازموینه چلېږي. له fullnode v0.6.8 راهیسې (audit v6، ZKV-4) دا چاڼ لومړی هره اعلان شوې درجه په 25 بټه محدودوي (MAX_HONEST_DEGREE_BITS، د حافظې جدول سقف جمع یو). په دې توګه هغه سرلیک چې ډېره لویه درجه لري نور نوډ نشي بندولی، په داسې حال کې چې د هغه لپاره د صادق ماتولو مهالوېش بیا ترلاسه کېږي. په چاڼ کې دننه یو پانیک هغه لېږد ردوي او نوډ نه دروي؛ - د لېږد تړنه محاسبه کوي او
Machine::verify_public(hc_bundle, &binding, proof)چلوي. دا د بیچ تصدیقوونکی دی، او ورسره دا ازموینه چېH_PUBد همدې اتو کلمو ډایجسټ دی. نو هغه ثبوت چې په بل عمل، بله لفافه یا بل زنځیر id لرونکي لېږد باندې کاپي شي، یا په 20م زنځیر کې د بل زنځیر په جېنېسس باندې، نه تصدیقېږي (تر 13م زنځیر پورې برخه تشه وه او هېڅ شي ثبوت له خپل لېږد سره نه تاړه)؛ - د اجازې ثبوت د
hc_authاو همدې تړنې پر وړاندې تصدیقوي، او غواړي چې هغهcچې دا یې خپروي لهauth_commitسره برابر وي. هغه بنډل چې د اجازې ثبوت نه لري ردېږي (AuthMissing)، او همدارنګه هغه چېcیې توپیر لري (AuthMismatch)؛ - غواړي چې د بنډل ثبوت
GAS_LIMITد جېنېسس لهbundle_gas_limitسره برابر وي، چې 20,479 دی، او د اجازې ثبوت هغه له 1,279 سره، چې د دواړو ګیسټونو د سرلیک سقفونه دي (BundleGasLimit،AuthGasLimit)؛ - د یوې غوښتنې لپاره، همدا کار د پروګرام د زېرمه شوي
code_hashپر وړاندې کوي. د برخې په توګه د پروګرام عامې کلمې کارېږي او ورپسې د غوښتنې تړنه (یو RPL-2Invokeخپل بدلون د شرایطو د کلمو په توګه ورزیاتوي، پروګرامونه). بیا فیس د هغه ګاز حد پر وړاندې ازمويي چې ثبوت یې اعلانوي، او د هغه د بایټونو پر وړاندې (فیسونه).
هغه لېږد چې د RPC یا ګاسيپ له لارې سپارل کېږي، د اجماع له لوپ نه بهر، د یوې 64-ژورې کتار شاته په څلورو کارګرو کې پر یوه تصدیقېږي، او یوازې له تصدیق وروسته نورو ته ګاسيپ کېږي. د هر همتا لپاره یو ټوکن بکټ (برسټ 16، په هره ثانیه کې 4 بیا ډکول) اندازه کوي چې یو همتا یو نوډ څومره تصدیق ته اړ کولی شي. یو 8,192-ننوتي کیش د تل لپاره رد شوي لېږد تکرار ته وړیا ځواب ورکوي. د یوه وړاندیز شوي بلاک دننه د ثبوتونو تصدیق لا هم د اجماع په لوپ کې چلېږي، کله چې بلاک پلي کېږي. هغه نوډ چې همغږي کېږي، مخکې له منلو د هر بلاک هر سند او هر ثبوت بیا تصدیقوي. هېڅ شی یوازې له دې امله باوري نه ګڼل کېږي چې یوه کورم لاسلیک کړی.
کچې
| کچه | د سایکل بودیجه (2ᵗ − 1) | د cpu قطارونه | کاروونکي |
|---|---|---|---|
| 10 | 1,023 | 2¹⁰ | د اجازې ګیسټ؛ private_payment، fib |
| 12 | 4,095 | 2¹² | |
| 14 | 16,383 | 2¹⁴ | د پټې شتمنۍ د بنډل ګیسټ (او تقاعد شوی bundle ګیسټ)؛ تر ټولو لویه غوښتنه |
| 16 | 65,535 | 2¹⁶ | د ازموینې په ټولګه کې د EVM غوښتنې ثبوت؛ ژباړل شوی ERC-20 approve (په 13م زنځیر کې غوښتل شوی) |
| 18 | 262,143 | 2¹⁸ | ERC-20 transfer او transferFrom، ژباړل شوي یا انټرپرېټ شوي |
| 20 | 1,048,575 | 2²⁰ | SPL Token، ژباړل شوی یا د sBPF انټرپرېټر ګیسټ باندې |
له fullnode v0.5.6 (2026-09-25) راهیسې د 14مې کچې نه پورته د غوښتنې ثبوت د تصدیقوونکي کیلي له جوړېدو مخکې ردېږي (CallTierTooHigh). هغه بلاک چې داسې ثبوت ولري ناسم دی. یوه غوښتنه هم تر ډېره 128 Keccak-f پرموټېشنونه او 128 SHA-256 کمپرېشنونه لېږدولی شي. له 16مې تر 20مې کچې لا هم ثبوت جوړېږي، خو یوازې له زنځیر نه بهر: په 20م زنځیر کې د 14مې کچې نه پورته هېڅ قطار نشي غوښتل کېدی. 20م زنځیر د داسې پروګرام ځایپرځای کول ردوي چې د هرې 14مې کچې غوښتنې لپاره ډېر لوی وي، یعنې له عام ننوتي پرته له 8,180 کلمو ډېر (ProgramUncallable) (بودیجه).
ثبوت جوړوونکی هغه تر ټولو کوچنۍ کچه ټاکي چې بودیجه یې سایکلونه او د پروګرام او ننوتي ډایجسټ قطارونه پوښي. هغه چلول چې ځای نه نیسي، له ثبوت جوړولو مخکې ناکامېږي. یوازې کچه عامه ده. هر ګام د ثبوت جوړولو وخت شاوخوا څلور چنده کوي او د ثبوت په اندازه لږ زیاتوي. په 20م زنځیر کې د یوې غوښتنې فیس د هغه ګاز حد پسې ځي چې ثبوت یې اعلانوي او د هغه د بایټونو اندازې پسې، نه د کچې پسې (فیسونه).
د محدودیتونو ټولګې او هارډ فورکونه
د محدودیتونو ټولګه د جدولونو، ستنو، بسونو، عامو ارزښتونو او FRI پارامترونو هغه دقیقه ټولګه ده چې تصدیقوونکی یې ازمويي. هغه ثبوت چې د یوې ټولګې لاندې جوړ شوی وي د بلې لاندې نه تصدیقېږي، په هېڅ لوري کې. د نوډ د پیل بیاچلول د هغه په زنځیر کې هر ثبوت بیا تصدیقوي، نو هغه نوډ چې له بلې ټولګې جوړ شوی وي په لومړي ثبوت کې ناکامېږي او زنځیر لنډوي. له همدې امله په ټولګه کې هر بدلون د یوه نوي زنځیر id په توګه پرې کېږي، داسې چې ټول نوډونه پر یوه جوړښت وي. همدا لامل دی چې rand_status، hc_bundle او hc_auth راپور کوي، او هغه نوډ چې جوړښت یې له جېنېسس سره سمون ونه لري له پیلېدو ډډه کوي.
| ټولګه | نېټه | څه بدل شول |
|---|---|---|
| 2 | 2026-09-10 | له لومړۍ کتنې وروسته د سلامتۍ پنځه سمونونه |
| 3 | 2026-09-11 | Poseidon2 چیپ، په سرکټ کې hc، د پروګرام جدول د شاهد په توګه، د کلمې نه کوچنۍ حافظه، RV32M، FRI بیا په 27 پوښتنو تنظیم شو |
| 4 | 2026-09-11 | مالګهلرونکې د ننوتو ژمنه H_IN د خپل جدول سره؛ د فلیټ باینري لوډر |
| 5 | 2026-09-12 | اختیاري keccak جدول؛ د حافظې هغه لوړوالی چې ثبوت یې اعلانوي؛ د zk پلټنې دوه مهم سمونونه؛ FRI بېرته 80 پوښتنو ته؛ MAX_PROOF_BYTES تر 2 MiB |
| 6 | 2026-09-14 | لازمي public جدول او H_PUB؛ اختیاري sha256 جدول؛ د EVM او sBPF انټرپرېټر ګیسټونه د کتابتونونو په توګه؛ 34 عام ارزښتونه. هغه څه چې له 12م تر 15م زنځیرونو چلول. |
| 7 | 2026-09-28 | هر LogUp پای د BLIND بس له لارې پټ شو؛ هر اعلان شوی جدول لږ تر لږه 2⁷ قطارونو ته ورسېد؛ د ننوتو، عامو او مالګې پر کلمو 32-بټه د حد ازموینې؛ POSEIDON2_LEN syscall (7)؛ JALR د خپل هدف 0 بټ پاکوي او funct3 = 0 غواړي؛ د تصدیقوونکي کیلي له key_derivation_v2 نه مالګهلرونکې شوې. هغه څه چې 16م او 17م زنځیرونو چلول. |
| 8 | 2026-09-29 | د ګاز اندازهګر: د cpu په جدول کې د GAS ستنه او عام ارزښت GAS_LIMIT؛ 35 عام ارزښتونه. هغه څه چې له 18م تر 20م زنځیرونه یې چلوي. |
14م او 15م زنځیرونو هېڅ محدودیت بدل نه کړ. د 15م زنځیر نوډ د Poseidon2 86 دورې ثابتونه د تخملرونکي انتخاب پر ځای د یوه لفظي جدول په توګه ساتي (audit ZKV-2). دا همغه ارزښتونه دي، نو هېڅ هش، ډایجسټ یا ثبوت بدل نه شو. په 14م زنځیر کې د پټې شتمنۍ بنډل یو نوی ګیسټ دی (یو نوی hc_bundle)، او د لېږد تړنه هغه عامه برخه کاروي چې 6مه ټولګه یې دمخه په سرکټ کې تړي. سره له دې، دا یو هارډ فورک دی: د بنډل د تار بڼه، ټاکل شوی ګیسټ او د هر لېږد id بدل شول. نوی جوړښت د 13م زنځیر هغه لېږد ردوي چې بنډل لري، او هغه والټ چې له فورک مخکې جوړ شوی وي د تشې برخې ثبوتونه جوړوي چې زنځیر یې ردوي.
درې زنځیرونو له هغه وروسته هر یو دا بدله کړه چې ثبوت څه شی دی. Chain 16 (fullnode v0.6.1، 2026-09-28) د محدودیتونو سیټ 7 ته ولاړ، د بېڅانګې بنډل guest v2 یې ثابت کړ او hardening_v6 یې فعال کړ، وروسته له دې چې د 2026-09-27 بیاکتنې وښودله چې لنډو جدولونو او نهپټو شوو LogUp پایونو شخصي معلومات افشا کول (zkVM څنګه کار کوي). د تصدیقوونکي هره کیلي بدله شوه. Chain 17 (v0.6.3، 2026-09-29) سیټ 7 وساته او وېشل شوې اجازه یې ورزیاته کړه: بنډل guest v3، د اجازې guest، د بنډل په wire کې دوه نوې ساحې، او د راکړې ورکړې د id ډومین rand-txid-3. Chain 18 (v0.6.7-rc1، 2026-09-29) د ګاز مېټر لپاره د محدودیتونو سیټ 8 ته ولاړ. د ثبوت په اندازه کې یې اندازه شوې لګښت له 1% څخه کم دی. Chain 19 (2026-10-01) په همغه v0.6.7 build باندې د chain 18 بیا-جنسیس دی او په ثبوتونو کې یې هېڅ بدلون رانه وړ. Chain 20 (fullnode v0.6.8، 2026-10-01) د محدودیتونو سیټ 8 او همغه guests او د تصدیقوونکي کیلي ساتي، او دا بدلوي چې ثبوت په څه پورې تړل شوی دی: د راکړې ورکړې او د غوښتنې تړونونه د جنسیس هش لېږدوي (binding_domain: 1)، چې یو عامه ورودي ده او والټ او لیجر یې محاسبه کوي، نو هېڅ سرکټ ونه خوځېد. سره له دې هم دا یو هارډ فورک دی، ځکه چې د v0.6.7 والټ ثبوتونه پرې نه تصدیقېږي. هر build د جنسیس هش له مخې له ځانه مخکې زنځیرونه ردوي.
په کوډ کې دوه د پلټنې یادښتونه شته چې پېژندل یې ارزښت لري: د TIER عامه ارزښت تصدیقوونکی د ثبوت د سرلیک او د بیچ د درجې د bits په وړاندې کتل کېږي، خو پخپله سرکټ یې نه محدودوي (پلټنه ZL1، چې د راتلونکي سیټ لپاره په نښه شوې ده نه دا چې سمه شوې وي، ځکه چې لرې کول یې د عامه ارزښتونو ترتیب ځایه خوځوي)؛ او H_IN یو داسې ژمنه ده چې guest ته ښکاري او تصدیقوونکی یې د غوښتونکي له خوا ورکړل شوي ارزښت سره نه پرتله کوي، او دا په قصدي ډیزاین ده.
راتلونکی: د بلاک راټولونه
په chains 14 او 15 کې د هر پټې شتمنۍ بنډل ثبوت نږدې 1.43 MB و، نو یو 4 MiB بلاک (ډیفالټ، او د chain 12 بلاک) دوه پټ شوي لېږدونه ځایول؛ د 2-in-2-out بنډل په ~1.3 MB کې یې درې ځایول. Chains 13، 14 او 15 د بلاک حد 20 MiB ته پورته کړ (max_block_bytes)، چې د څوارلسو لپاره ځای لري. Chain 20 همغه 20 MiB ساتي، او هلته یو لېږد نږدې 2.87 MB ثبوت لېږدوي، نو یو بلاک نږدې اوه ځایوي. هغه حل چې fullnode (2026-09-12) د هرس کولو او د لوی بلاک پر ځای غوره کړ د بلاک په کچه راټولونه ده: د هرې مهر شوې کړکۍ لپاره یو بیا-تکراري ثبوت چې N بنډل ثبوتونه تصدیقوي، نو تاریخ له سره تر پایه ثبوتلرونکی پاتې کېږي پداسې حال کې چې خام ثبوتونه لرې کېدای شي. دا جوړه او ادغام شوې ده خو فعاله شوې نه ده، او له chain 14 راهیسې باید د فعالېدو مخکې بیا اندازه شي: د منل شوي بنډل بڼه یې د خالي عامه برخې (public 2) سره اندازه شوې وه، او یو په راکړې ورکړې پورې تړلی بنډل public 4 اعلانوي، نو په chain 14 کې هېڅ ثابت شوی بنډل ورسره سمون نه خوري. د محدودیتونو سیټونو 7 او 8 بڼه بیا وخوځوله: یو بنډل ثبوت اوس public 7 اعلانوي او 35 ارزښتونه خپروي، نو د راټول شوي ثبوت انٹرفیس په هر ثبوت کې 35 کلمې دی. د نوډ build په هر هغه جنسیس پیل کېدل ردوي چې aggregation برخه ولري، او chains 14 تر 20 پرته له هغې پرې شوي دي. هغه جنسیس چې متحرک د ګاز بیې لري، لکه د chain 20، هم د aggregation برخې تر څنګ ردېږي. له fullnode v0.5.8 راهیسې راټول شوی ثبوت خپل راټولوونکی هم تړي (پلټنه AGG-2: پروګرام aggregate_binding(chain_id, aggregator, nonce) جذبوي)، نو د منل شوې بڼې د پروګرام digest باید په داسې build اندازه شي چې دا بدلون ولري. فعالېدل لا هم د سم شوي بیا-تکراري تصدیقوونکي په وړاندې د جعلي راټول شوي ثبوت یوې له سره تر پایه ازموینې ته انتظار باسي، چې لا نه ده ترسره شوې، او د اجازې د ثبوت په اړه پرېکړې ته: د راټولونې پروګرام یوازې بنډل ثبوتونه تصدیقوي، نو په یوه وېشلشوېاجازې زنځیر کې د کړکۍ مهرول به یو لېږد له نږدې 2.87 MB څخه نږدې 1.37 MB ته راکم کړي، نه صفر ته.
څه چې جوړ شوي دي:
- یو دویم، Goldilocks-اصلي ماشین (د بیا-تکرار VM،
randprotocol-rvm) چې د تصدیقوونکي پروګرام یې یو RV32 ثبوت په tier 21 کې په نږدې 1.97 میلیون قطارونو کې تصدیقوي (د محدودیتونو سیټ 7 لاندې 2,044,506)، او د بنډل ثبوتونو د یوې کړکۍ پر سر یو N-عمومي د راټولونې پروګرام؛ - دوه رولونه: اعتباروونکي د CPU له پلوه ارزانه پاتې کېږي او د هر مهر شوي بلاک لپاره یو راټول شوی ثبوت تصدیقوي؛ راټولوونکي (یو بېاجازې، تضمینلرونکی راجستر چې یو پټ شوی د تادیې پته لري) راټول شوي ثبوتونه د GPU-کچې ماشینونو باندې ثابتوي او د پوښل شوو بنډلونو د ثبوت ونډه او په نوي RAND کې د نیمایي کېدو د مهالوېش له مخې د بلاک سبسایډي ورکول کېږي؛
- پنځه کړنې (
RegisterAggregator،UnbondAggregator،WithdrawAggregator،SlashAggregator،Aggregate؛SlashAggregatorپه wire کې پاتې کېږي او ردېږي، ځکه چې یو بیا هڅه شوی راټول شوی ثبوت همغه nonce بیا لاسلیکوي او دوهاړخیزتوب نه دی)، نههپړاوه منل، د پوښل شوو بنډلونو مهرول او هرس کول تر هر یوه نږدې 3 KB عامه ساحو پورې، د مهر شوې بڼې همغږي چې یو نوي نوډ ته د هرې کړکۍ لپاره یو بیا-تکراري تصدیق لګښت لري، د RPC میتودونهrand_getAggregate،rand_getAggregators،rand_getUnsealed،rand_getRawTransaction، او دrand-node aggregate --watchdaemon.
د ازموینې FRI پروفایل باندې اندازه شوي: یو N=1 راټول شوی ثبوت په یوه بار شوي لپټاپ کې په نږدې 26 دقیقو کې ثابت شو (327,035 bytes)؛ یوه نوي نوډ یو اوهبلاکه مهر شوی بیچ له یوې ثانیې په کم وخت کې د یوه بیا-تکراري تصدیق سره پلي کړ. د ماشین ټولګي لکه څنګه چې لومړی محدود شول: N=1 ته ≥ 64 GB د کوربه حافظه اړتیا ده، N=2 ته ≥ 128 GB، N=3 ته ≥ 160 GB؛ تولیدي N ≥ 2 د CUDA backend پورې اړه لري، چې یو GPU نوډ ته اړتیا لري چې لا شتون نه لري. د محدودیتونو سیټ 7 لاندې په یوه 256 GB ماشین کې اندازه شوي (2026-09-28 او 29)، N=2 راټول شوي ثبوت 133 GB ونیول، N=3 221 GB، او تولیدي د وتلو ثبوت (د تصدیقوونکي پروګرام د یوه داخلي ثبوت پر سر) له 256 GB څخه واوښت. له دې هېڅ یو د محدودیتونو سیټ 8 لاندې بیا نه دی اندازه شوی. تر هغه چې راټولونه فعاله شي، په chain 20 کې هېڅ راټول شوی ثبوت د یوه ثبوت ځای نه نیسي: د هغه دوه آرشیف نوډونه هر خام ثبوت ساتي، او اعتباروونکي یې له 24 ساعتونو زوړ تاریخ هرس کوي.