ثبوت

اس صفحے کی مدد سے آپ ثبوت تیار کرنے والی مشین کی گنجائش کا تعین کر سکتے ہیں۔ یہ صفحہ بتاتا ہے کہ ایک منتقلی میں ایک منٹ سے زیادہ وقت کیوں لگتا ہے، اور تھروپٹ کی حد کمپیوٹ کے بجائے بلاک کی جگہ کیوں مقرر کرتی ہے۔ اس سے یہ بھی معلوم ہوتا ہے کہ ثبوت کا نظام بدلنے پر کیا ٹوٹتا ہے۔ ہر وہ چیز جسے validator قبول کرتا ہے، ایسے ثبوت پر مبنی ہوتی ہے جس کی تصدیق اس نے خود کی ہو۔

ثبوت کیا بیان کرتا ہے

چین جو بھی پروگرام چلاتی ہے، ان سب کے لیے ایک ہی تعلق ہے:

یہ RV32IM پروگرام base_pc سے شروع ہوا، H_IN کے ذریعے کمٹ کیے گئے نجی ان پٹ ویکٹر اور H_PUB کے ذریعے کمٹ کیے گئے عوامی ان پٹ حصے پر چلا، 2ᵗ − 1 سائیکلوں کے اندر رک گیا، زیادہ سے زیادہ GAS_LIMIT گیس خرچ کی، اور یہ آٹھ آؤٹ پٹ الفاظ شائع کیے۔

پروگرام کی شناخت اس کے اِن سرکٹ ڈائجسٹ hc سے ہوتی ہے؛ تصدیق کنندہ کبھی کوئی ہدایتی لفظ نہیں دیکھتا۔ پوشیدہ منتقلی یہی تعلق ہے جس کا اطلاق پوشیدہ اثاثے والے بنڈل گیسٹ پر ہوتا ہے۔ یہ ہاتھ سے اسمبل کیا گیا 4-ان-4-آؤٹ پروگرام ہے جس کا hc جینیسس فائل میں hc_bundle کے طور پر مقرر ہے۔ Chain 20 گیسٹ v3 (guests::bundle_hidden_v3، 60af094a…6e3fce، chain 17 سے) مقرر کرتی ہے۔ Chains 14 اور 15 نے v1 (83d3a370…cd0ef8) مقرر کیا تھا اور chain 16 نے بغیر شاخوں والا v2 (651043e2…839b)۔ chain 17 سے ہر بنڈل میں ایک دوسرا ثبوت بھی ہوتا ہے، جو اجازت گیسٹ (guests::auth، جینیسس hc_auth، 1e4e347f…5639c1) کا ہے۔ بنڈل کا ثبوت دیکھنے کی کلید لیتا ہے، اور اجازت کا ثبوت دکھاتا ہے کہ بھیجنے والے کے پاس اس کے پیچھے موجود خرچ کی کلید ہے۔ اسے منقسم اجازت کہتے ہیں، اور اسی کی بدولت ایک منسلک ثابت کنندہ، جس کے پاس صرف دیکھنے کی کلید ہو، بنڈل کا ثبوت بنا سکتا ہے۔ پوشیدہ اثاثے والے گیسٹ نے chain 13 تک کی چینوں کے 2-ان-2-آؤٹ bundle گیسٹ کی جگہ لی۔ وہ گیسٹ fullnode میں صرف ٹیسٹوں کے لیے باقی ہے اور کوئی چین اسے مقرر نہیں کرتی۔ خفیہ کال بھی یہی تعلق ہے جس کا اطلاق کسی تعینات شدہ پروگرام پر ہوتا ہے (پروگرام)۔

والیٹ بنڈل کا ثبوت کیسے بناتا ہے

rand send <rand1…> <amount> نجی کام مقامی طور پر کرتا ہے۔ چین تک صرف ثبوت، کمٹمنٹس، نلیفائرز اور مہر بند لفافے پہنچتے ہیں:

1. اسکین: دیکھنے کی کلید سے درخت کو اسکین کر کے ان پٹ منتخب کریں۔ slots 2–3 میں زیادہ سے زیادہ دو RAND نوٹ ہوتے ہیں جو رقم اور فیس دونوں پوری کریں۔ ٹوکن کی منتقلی یا برن میں slots 0–1 میں اس ٹوکن کے زیادہ سے زیادہ دو نوٹ ہوتے ہیں، اور RAND نوٹ صرف فیس پوری کرتے ہیں۔ غیر استعمال شدہ ان پٹ سلاٹ ایک ڈمی ہوتا ہے: رقم 0، مالک والیٹ، رکنیت کی ناکامی سرکٹ میں چھپا دی جاتی ہے، مگر نلیفائر پھر بھی شائع ہوتا ہے۔ گیسٹ v2 سے گیسٹ بغیر شاخوں کے ہے: ڈمی کا راستہ بھی اصل نوٹ کی طرح تمام 32 سطحوں تک ہیش کیا جاتا ہے۔
2. حاصل کریں: سرے کا اینکر (rand_getAnchor) اور ہر اصل ان پٹ کا 32 سطحی Merkle گواہ (rand_getWitness(index)) حاصل کریں، اور واپس آنے والے روٹ کو اینکر سے ملا کر جانچیں۔
3. تیار کریں: چار آؤٹ پٹ بنائیں۔ جو گروپ قدر منتقل کرتا ہے اس میں وصول کنندہ کا نوٹ اور بقایا نوٹ ہوتے ہیں، چاہے ان کی رقم صفر ہو۔ باقی جگہوں پر صفر رقم کے ڈمی ہوتے ہیں جو ایک عارضی کلید پر مہر بند ہوتے ہیں۔
4. مہر بند کریں: ہر آؤٹ پٹ کو ایک لفافے میں مہر بند کریں (وصول کنندہ کے لیے ML-KEM-768، اور ساتھ ٹرانزیکشن کلید جو والیٹ کے ovk کے تحت لپیٹی گئی ہو)۔ پھر پوری ٹرانزیکشن اس کے عمل سمیت جوڑیں اور اس کی بائنڈنگ لیں: blake3("rand-tx-bind-1" || …)، جو ثبوتوں کو خالی کر کے پوری ٹرانزیکشن پر لی جاتی ہے، آٹھ الفاظ (ٹرانزیکشنز)۔ chain 20 پر، جس کی جینیسس binding_domain: 1 مقرر کرتی ہے، یہ blake3("rand-tx-bind-2" || …) ہے جس میں پہلے جینیسس ہیش آتا ہے، پھر chain id۔ یوں ایک چین کے لیے بنایا گیا ثبوت کسی دوسری چین پر تصدیق نہیں پاتا، چاہے اس کا chain id یکساں ہو۔ v0.6.8 سے پرانا والیٹ پرانی بائنڈنگ لیتا ہے، اور chain 20 اس کے ثبوت مسترد کر دیتی ہے۔
5. اجازت دیں: ایک تازہ 256 بٹ نمک لیں اور اجازت گیسٹ کا ثبوت درجہ 10 پر بنائیں۔ اس کا 16 الفاظ کا نجی ان پٹ خرچ کی کلید اور نمک ہے، اور بائنڈنگ عوامی ان پٹ حصہ ہے۔ یہ خرچ کی کلید سے nk اخذ کرتا ہے اور c = H(AUTH, nk ‖ salt) شائع کرتا ہے، جسے بنڈل auth_commit کے طور پر ساتھ رکھتا ہے۔
6. ثبوت بنائیں: بنڈل گیسٹ کا ثبوت درجہ 14 پر بنائیں۔ اس کا 1,212 الفاظ کا نجی ان پٹ یہ ہے: دیکھنے کی کلید nk، چار ان پٹ سلاٹ اپنے راستوں سمیت، اینکر، چار آؤٹ پٹ، fee، burn_a، burn_r، نجی اثاثہ A، time اور نمک۔ عوامی ان پٹ حصہ وہی بائنڈنگ ہے۔ یہ ثبوت ملکیت اور رکنیت دکھاتا ہے، اور یہ بھی کہ ہر اصل ان پٹ اپنے سلاٹ کا اثاثہ رکھتا ہے۔ یہ چاروں نلیفائرز، وہی c، اور دونوں توازن بھی دکھاتا ہے: in₀ + in₁ = out₀ + out₁ + burn_a اور in₂ + in₃ = out₂ + out₃ + fee + burn_r۔ یہی وہ ثبوت ہے جو ایک منسلک ثابت کنندہ والیٹ کی جگہ بنا سکتا ہے؛ اجازت کا ثبوت والیٹ کی اپنی مشین پر بنتا ہے۔
7. جانچیں: ثبوت کے شائع شدہ ڈائجسٹ کو سادہ متن سے نکالے گئے ڈائجسٹ سے ملائیں، اور Transaction { chain_id, bundle, action: None } جمع کرائیں۔

chain 14 سے ترتیب اہم ہے: لفافے اور عمل ثبوتوں سے پہلے موجود ہوتے ہیں، کیونکہ ثبوت انہی پر کمٹ کرتے ہیں۔ کال کی صورت میں کال کا ثبوت پہلے بنتا ہے اور وہ بھی بائنڈنگ میں شامل ہوتا ہے۔ hardening_v6 چین پر کال کا ثبوت خود ٹرانزیکشن کی ایک کال بائنڈنگ پر بنتا ہے جس میں دونوں ثبوت خالی ہوتے ہیں۔ chains 16 سے 19 پر یہ rand-call-bind-1 ہے، اور chain 20 پر جینیسس ہیش کے ساتھ rand-call-bind-2۔ یہ بائنڈنگ فیس بنڈل کے نلیفائرز کا احاطہ کرتی ہے، اس لیے کال کا ثبوت کسی دوسرے بنڈل کے تحت نقل نہیں کیا جا سکتا۔

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

یہ ٹرانسکرپٹ chain 14 کے وقت fullnode کی گائیڈ میں درج والیٹ کا آؤٹ پٹ فارمیٹ ہے؛ دکھائی گئی بائٹ تعداد chain 14 پر کمٹ کیے گئے پروڈکشن پروفائل کے بنڈل ثبوت کی ہے۔ chain 17 سے والیٹ، بشمول chain 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 کے ذریعے اسٹیک کو برن کرتا ہے۔ ٹوکن برن یا برج برن ایک ہی بنڈل کے ساتھ جاتا ہے جو slots 0–1 سے اثاثہ برن کرتا ہے (burn_a، burn_asset) اور slots 2–3 سے RAND فیس ادا کرتا ہے۔ منتقلی جس اثاثے کو منتقل کرتی ہے وہ ایک گواہ لفظ ہے اور کسی عوامی خانے میں موجود نہیں۔

اس کی لاگت کیا ہے

ترقیاتی لیپ ٹاپ (Apple Silicon، ریلیز بلڈ) پر ناپے گئے اعداد، جو fullnode کی اپنی دستاویزات میں درج ہیں:

تصدیق اتفاقِ رائے کی لاگت ہے جو ہر نوڈ ادا کرتا ہے: گرم تصدیقی کلید کے ساتھ تقریباً 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)۔ chain 13 اور اس سے پہلے کے 2-ان-2-آؤٹ بنڈل نے program 12, input 10, keccak 0, sha256 0, public 2, mem 16 کی شکل ظاہر کی تھی۔ chain 14 کا بنڈل ثبوت public 4 ظاہر کرتا ہے، جو آٹھ بائنڈنگ الفاظ کی اونچائی ہے، اور کوئی ہیش ٹیبل ساتھ نہیں رکھتا۔ اگر وہ کوئی دوسرا درجہ، دونوں میں سے کوئی ٹیبل، یا کوئی دوسری عوامی اونچائی ظاہر کرے تو کوئی تصدیقی کلید بننے سے پہلے ہی مسترد کر دیا جاتا ہے۔ پابندیوں کے سیٹ 7 سے ہر ظاہر کردہ ٹیبل میں کم از کم 2⁷ قطاریں ہوتی ہیں، اس لیے chain 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 والا ایک droplet ایک کور کے 99% پر چلا، اور ثبوت کے مکمل ہونے یا نہ ہونے کا فیصلہ کوروں نے نہیں بلکہ میموری نے کیا (ثبوت سازی کی میموری)۔ send، bond، call، deploy، bridge-mint اور bridge-burn پر --cuda فلیگ ایک NVIDIA بیک اینڈ منتخب کرتا ہے جس کے لیے --features cuda کے ساتھ تیار کردہ بلڈ درکار ہے۔ اس کے کرنلز پہلی بار حقیقی ہارڈویئر، یعنی NVIDIA H100، پر 2026-09-28 کو چلے اور CPU کے حوالہ نتائج سے مطابقت رکھتے پائے گئے، لیکن ریلیز جس circuits checkout کو شامل کرتی ہے اس میں کوئی PTX کمٹ نہیں کیا گیا، اس لیے جب تک کرنلز کمپائل نہ ہوں بلڈ no PTX for the GPU kernels کے ساتھ ناکام ہوتا ہے۔ فلیٹ کے کسی GPU نوڈ پر کسی پیداواری ثبوت کی پیمائش نہیں کی گئی۔ CPU کی طرف کوئی متبادل راستہ دانستہ طور پر نہیں رکھا گیا۔ CUDA کال ان پٹ لفافے کو مہر بند بھی نہیں کر سکتی، کیونکہ سالٹ کبھی ثبوت ساز سے باہر نہیں جاتا۔ درجہ 14 کے پوشیدہ اثاثے والے بنڈل ثبوت کی زیادہ سے زیادہ میموری تقریباً 5.7 GB ہے (پیداواری FRI، CPU)؛ میموری کے بڑے درجات نیچے مذکور مترجم اور تکراری ثبوتوں سے متعلق ہیں (≥ 64 GB اور اس سے زیادہ)۔

نوڈ تصدیق کیسے کرتا ہے

داخلے کے وقت پہلے سستی جانچیں چلتی ہیں (ٹرانزیکشنز)، پھر نوڈ:

• شائع شدہ سادہ متن سے بنڈل ڈائجسٹ دوبارہ حساب کرتا ہے (اینکر، چار نلیفائر، چار کمٹمنٹس، fee، burn_a، burn_r، burn_asset، time، بنڈل کا auth_commit، اور صفر پر مقرر ایک آلودگی لفظ) اور شرط رکھتا ہے کہ یہ ثبوت کے شائع کردہ ڈائجسٹ کے برابر ہو — جس ثبوت کے گواہ نے رشتہ توڑا ہو وہ ایک آلودہ ڈائجسٹ شائع کرتا ہے جو کسی سادہ متن سے مطابقت نہیں رکھتا۔ بعض جانچیں اس کے بجائے ساختی ہیں (گیسٹ کسی آؤٹ پٹ کا بھیجنے والا، اثاثہ اور وقت خود فراہم کرتا ہے، اس لیے ثبوت ساز انہیں منتخب نہیں کر سکتا)، اور نجی اثاثہ ڈائجسٹ میں شامل نہیں؛
• ثبوت کو ڈی کوڈ کرتا ہے اور اس کی اعلان کردہ اونچائیوں کو درجے کے مقابل جانچتا ہے (check_declared_heights)، تاکہ ثبوت کی ساخت پر چین کی حد وہی ہو جو تصدیق کنندہ کی ہے۔ کسی بھی دستخط یا ثبوت کی جانچ سے پہلے، ہر جمع کرائی گئی یا گوسپ کی گئی ٹرانزیکشن پر (اور hardening_v6 کے تحت بلاک کی توثیق میں بھی) ایک معیاری ثبوت کی چھلنی چلتی ہے؛ fullnode v0.6.8 (آڈٹ v6، ZKV-4) سے یہ چھلنی سب سے پہلے ہر اعلان کردہ درجۂ کثیر رقمی کو 25 بٹس تک محدود کرتی ہے (MAX_HONEST_DEGREE_BITS، میموری جدول کی بالائی حد جمع ایک)، چنانچہ بہت بڑے درجے والا ہیڈر اب نوڈ کو اس وقت تک روکے نہیں رکھتا جب تک اس کے لیے دیانت دار تہہ بندی کا شیڈول دوبارہ اخذ کیا جائے، اور چھلنی کے اندر کوئی panic نوڈ کو روکنے کے بجائے اس ٹرانزیکشن کو رد کر دیتا ہے؛
• ٹرانزیکشن کی بائنڈنگ کا حساب کرتا ہے اور Machine::verify_public(hc_bundle, &binding, proof) چلاتا ہے — یعنی بیچ تصدیق کنندہ، اور ساتھ یہ جانچ کہ H_PUB ان آٹھ الفاظ کا ڈائجسٹ ہے، چنانچہ جو ثبوت کسی دوسرے عمل، دوسرے لفافے یا دوسری chain 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-2 کا Invoke اپنی تبدیلیٔ حالت کو سیاقی الفاظ کے طور پر شامل کرتا ہے، پروگرامز)، پھر فیس کو ثبوت کی اعلان کردہ گیس حد اور اس کے بائٹس کے مقابل جانچتا ہے (فیسیں)۔

RPC یا گوسپ کے ذریعے جمع کرائی گئی ٹرانزیکشن کی تصدیق اتفاقِ رائے کے لوپ سے الگ، 64 گہری قطار کے پیچھے چار ورکرز میں سے کسی ایک پر ہوتی ہے، اور تصدیق کے بعد ہی اسے آگے گوسپ کیا جاتا ہے؛ فی ہم منصب ٹوکن بالٹی (یکبارگی 16، فی سیکنڈ 4 کی بھرائی) اس کی پیمائش کرتی ہے کہ کوئی ہم منصب نوڈ سے کتنی تصدیق کروا سکتا ہے، اور 8,192 اندراجات والا کیش مستقل طور پر رد شدہ ٹرانزیکشن کے اعادے کا جواب بلا لاگت دیتا ہے۔ تجویز کردہ بلاک کے اندر موجود ثبوتوں کی تصدیق اب بھی بلاک کے اطلاق کے وقت اتفاقِ رائے کے لوپ پر ہی چلتی ہے۔ ہم آہنگی کرنے والا نوڈ ہر بلاک کو قبول کرنے سے پہلے اس کے ہر سرٹیفکیٹ اور ہر ثبوت کی دوبارہ تصدیق کرتا ہے؛ کسی چیز پر محض اس لیے اعتماد نہیں کیا جاتا کہ کسی کورم نے اس پر دستخط کیے ہیں۔

درجات

fullnode v0.5.6 (2026-09-25) سے درجہ 14 سے اوپر کا کال ثبوت تصدیقی کلید بننے سے پہلے ہی رد کر دیا جاتا ہے (CallTierTooHigh)، اور ایسا ثبوت رکھنے والا بلاک غیر معتبر ہے؛ ایک کال زیادہ سے زیادہ 128 Keccak-f تبادلے اور 128 SHA-256 دباؤ بھی رکھ سکتی ہے۔ درجات 16 تا 20 اب بھی ثبوت بناتے ہیں، مگر صرف آف چین: اوپر دی گئی ان قطاروں میں سے کوئی بھی چین 20 پر کال نہیں کی جا سکتی، اور چین 20 کسی ایسے پروگرام کی تعیناتی رد کر دیتی ہے جو درجہ 14 کی کسی بھی کال کے لیے بہت بڑا ہو، یعنی عوامی ان پٹ کے بغیر 8,180 الفاظ سے زیادہ (ProgramUncallable) (بجٹ)۔

ثبوت ساز وہ سب سے چھوٹا درجہ چنتا ہے جس کا بجٹ سائیکلوں کے ساتھ پروگرام اور ان پٹ ڈائجسٹ کی قطاروں کا احاطہ کرے؛ جو رن اس میں نہ سمائے وہ ثبوت سازی سے پہلے ہی ناکام ہو جاتا ہے۔ صرف درجہ عوامی ہوتا ہے۔ ہر قدم ثبوت سازی کا وقت تقریباً چار گنا کر دیتا ہے اور ثبوت کے حجم میں تھوڑا اضافہ کرتا ہے۔ چین 20 پر کال کی فیس درجے کے بجائے اس کے ثبوت کی اعلان کردہ گیس حد اور بائٹس میں اس کے حجم کے مطابق ہوتی ہے (فیسیں)۔

قیود کے مجموعے اور ہارڈ فورک

قیود کا مجموعہ جدولوں، کالموں، بسوں، عوامی اقدار اور FRI پیرامیٹرز کا وہ عین مجموعہ ہے جسے تصدیق کنندہ جانچتا ہے۔ ایک مجموعے کے تحت بنایا گیا ثبوت دوسرے کے تحت تصدیق نہیں پاتا، کسی بھی سمت میں، اور نوڈ کا آغازی اعادہ اس کی چین کے ہر ثبوت کی دوبارہ تصدیق کرتا ہے — چنانچہ مختلف مجموعے سے بنا نوڈ پہلے ہی ثبوت پر ناکام ہو کر چین کو وہیں سے کاٹ دیتا ہے۔ اسی لیے مجموعے میں ہر تبدیلی ایک نئی chain id کے طور پر جاری کی جاتی ہے جس میں ہر نوڈ ایک ہی بلڈ پر ہو، اور اسی لیے rand_status hc_bundle اور hc_auth رپورٹ کرتا ہے اور جس نوڈ کا بلڈ جینیسس سے اختلاف رکھے وہ شروع ہونے سے انکار کر دیتا ہے۔

چین 14 اور 15 نے کوئی قید نہیں بدلی۔ چین 15 کا نوڈ Poseidon2 کے 86 راؤنڈ مستقلات کو بیج سے اخذ کرنے کے بجائے ایک لفظی جدول کی صورت میں رکھتا ہے (آڈٹ ZKV-2) — اقدار وہی ہیں، اس لیے کوئی ہیش، ڈائجسٹ یا ثبوت نہیں بدلا۔ چین 14: پوشیدہ اثاثے والا بنڈل ایک نیا گیسٹ ہے (نیا hc_bundle) اور ٹرانزیکشن کی بائنڈنگ وہ عوامی حصہ استعمال کرتی ہے جسے مجموعہ 6 پہلے ہی سرکٹ میں باندھتا ہے۔ اس کے باوجود یہ ہارڈ فورک ہے — بنڈل کا ترسیلی فارمیٹ، طے شدہ گیسٹ اور ہر ٹرانزیکشن id بدل گئی، بنڈل رکھنے والی چین 13 کی ٹرانزیکشن نیا بلڈ رد کر دیتا ہے، اور فورک سے پہلے بنا والیٹ خالی حصے والے ثبوت بناتا ہے جنہیں چین رد کر دیتی ہے۔

تین چینز سے، ہر چین نے یہ بدلا ہے کہ ثبوت کیا ہوتا ہے۔ Chain 16 (fullnode v0.6.1، 2026-09-28) قیود کے سیٹ 7 پر منتقل ہوئی، اس نے شاخ سے پاک بنڈل گیسٹ v2 کو مقرر کیا اور hardening_v6 نافذ کیا، کیونکہ 2026-09-27 کے جائزے سے ظاہر ہوا تھا کہ مختصر جدولیں اور غیر پوشیدہ LogUp اختتامی اقدار نجی ڈیٹا افشا کرتی تھیں (zkVM کیسے کام کرتا ہے)۔ ہر تصدیق کنندہ کلید بدل گئی۔ Chain 17 (v0.6.3، 2026-09-29) نے سیٹ 7 برقرار رکھا اور منقسم اجازت کا اضافہ کیا: بنڈل گیسٹ v3، اجازت گیسٹ، بنڈل کی ترسیلی ساخت میں دو نئے فیلڈ اور ٹرانزیکشن شناخت کا دائرہ rand-txid-3۔ Chain 18 (v0.6.7-rc1، 2026-09-29) گیس میٹر کے لیے قیود کے سیٹ 8 پر منتقل ہوئی۔ ثبوت کے حجم میں اس کی ناپی گئی لاگت 1% سے کم ہے۔ Chain 19 (2026-10-01) اسی v0.6.7 بلڈ پر chain 18 کی ازسرِنو جینیسس ہے اور اس نے ثبوتوں میں کچھ نہیں بدلا۔ Chain 20 (fullnode v0.6.8، 2026-10-01) قیود کا سیٹ 8 اور وہی گیسٹ اور تصدیق کنندہ کلیدیں برقرار رکھتی ہے، اور یہ بدلتی ہے کہ ثبوت کس چیز سے بندھا ہے: ٹرانزیکشن اور کال کے بندھن جینیسس ہیش (binding_domain: 1) ساتھ رکھتے ہیں، جو ایک عوامی ان پٹ ہے جسے والیٹ اور لیجر شمار کرتے ہیں، اس لیے کوئی سرکٹ نہیں بدلا۔ اس کے باوجود یہ ایک ہارڈ فورک ہے، کیونکہ v0.6.7 والیٹ کے ثبوت اس پر تصدیق نہیں پاتے۔ ہر بلڈ جینیسس ہیش کے ذریعے اپنے سے پہلے کی چینز کو مسترد کرتا ہے۔

کوڈ میں درج دو آڈٹ نوٹس جاننے کے لائق ہیں: TIER عوامی قدر کو تصدیق کنندہ ثبوت کے ہیڈر اور بیچ کے ڈگری بٹس کے مقابل جانچتا ہے، مگر سرکٹ خود اسے مقید نہیں کرتا (آڈٹ ZL1، جسے درست کرنے کے بجائے اگلے سیٹ کے لیے نشان زد کیا گیا، کیونکہ اسے ہٹانے سے عوامی اقدار کی ترتیب سرک جاتی ہے)؛ اور H_IN گیسٹ کو نظر آنے والا ایک عہد ہے جسے تصدیق کنندہ دانستہ طور پر کال کنندہ کی فراہم کردہ کسی قدر سے نہیں ملاتا۔

آئندہ: بلاک ایگریگیشن

chains 14 اور 15 پر فی پوشیدہ اثاثہ بنڈل ثبوت تقریباً 1.43 MB کے حساب سے، 4 MiB کے بلاک (جو طے شدہ حد ہے، اور chain 12 کی بھی تھی) میں دو شیلڈڈ منتقلیاں سماتی تھیں؛ 2-ان پٹ 2-آؤٹ پٹ بنڈل کے ~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 الفاظ ہے۔ نوڈ کا بلڈ کسی بھی ایسی جینیسس پر شروع ہونے سے انکار کرتا ہے جس میں aggregation حصہ ہو، اور chains 14 تا 20 ایسے کسی حصے کے بغیر جاری کی گئیں۔ متحرک گیس قیمتوں والی جینیسس، جیسے chain 20 کی، بھی aggregation حصے کے ساتھ مسترد کی جاتی ہے۔ fullnode v0.5.8 سے ایگریگیٹ ثبوت اپنے ایگریگیٹر کو بھی باندھتا ہے (آڈٹ AGG-2: پروگرام aggregate_binding(chain_id, aggregator, nonce) جذب کرتا ہے)، اس لیے منظور شدہ ساخت کا پروگرام ڈائجسٹ ایسے بلڈ پر ناپا جانا چاہیے جس میں یہ تبدیلی شامل ہو۔ فعال کرنا اب بھی دو باتوں کا منتظر ہے: درست کیے گئے تکراری تصدیق کنندہ کے خلاف جعلی ایگریگیٹ کی ابتدا سے انتہا تک ایک مشق، جو ابھی نہیں کی گئی؛ اور اجازت ثبوت کے بارے میں ایک فیصلہ: ایگریگیٹ پروگرام صرف بنڈل ثبوتوں کی تصدیق کرتا ہے، اس لیے منقسم اجازت والی چین پر ونڈو کو مہر بند کرنے سے منتقلی تقریباً 2.87 MB سے گھٹ کر تقریباً 1.37 MB رہ جائے گی، صفر نہیں ہوگی۔

جو تیار ہو چکا ہے:

• ایک دوسری، Goldilocks کی مقامی مشین (تکراری VM، randprotocol-rvm)، جس کا تصدیق کنندہ پروگرام tier 21 پر تقریباً 1.97 ملین قطاروں میں ایک RV32 ثبوت کی جانچ کرتا ہے (قیود کے سیٹ 7 کے تحت 2,044,506)، اور بنڈل ثبوتوں کی ایک ونڈو پر چلنے والا N کے لحاظ سے عمومی ایگریگیٹ پروگرام؛
• دو کردار: ویلیڈیٹرز CPU کے لحاظ سے کم خرچ رہتے ہیں اور ہر مہر بند بلاک کے لیے ایک ایگریگیٹ کی تصدیق کرتے ہیں؛ ایگریگیٹرز (ایک اجازت سے آزاد، ضمانت یافتہ رجسٹر، جس میں ادائیگی کے لیے شیلڈڈ پتہ ہوتا ہے) GPU درجے کی مشینوں پر ایگریگیٹ ثابت کرتے ہیں، اور انہیں شامل بنڈلز کا ثبوت سازی کا حصہ نیز نئے RAND میں نصف ہوتے جدول کے مطابق بلاک سبسڈی ادا کی جاتی ہے؛
• پانچ ایکشن (RegisterAggregator، UnbondAggregator، WithdrawAggregator، SlashAggregator، Aggregate؛ SlashAggregator ترسیلی ساخت میں موجود رہتا ہے مگر مسترد کیا جاتا ہے، کیونکہ دوبارہ کوشش کیا گیا ایگریگیٹ اسی nonce پر دوبارہ دستخط کرتا ہے اور یہ دوغلا پن نہیں)، نو مراحل پر مشتمل داخلہ، مہر بندی اور شامل بنڈلز کی کانٹ چھانٹ جس کے بعد ہر ایک کے تقریباً 3 KB عوامی فیلڈ باقی رہتے ہیں، مہر بند صورت میں ہم آہنگی جس پر نئے نوڈ کو فی ونڈو ایک تکراری تصدیق کی لاگت آتی ہے، RPC طریقے rand_getAggregate، rand_getAggregators، rand_getUnsealed، rand_getRawTransaction، اور rand-node aggregate --watch ڈیمن۔

آزمائشی FRI پروفائل پر ناپا گیا: ایک N=1 ایگریگیٹ ایک زیرِ بار لیپ ٹاپ پر تقریباً 26 منٹ میں ثابت ہوا (327,035 بائٹس)؛ ایک نئے نوڈ نے سات بلاکس کا مہر بند بیچ ایک سیکنڈ سے کم میں ایک تکراری تصدیق کے ساتھ لاگو کیا۔ مشینوں کے درجے، جیسا کہ پہلی بار حد بندی کی گئی: N=1 کو ≥ 64 GB میزبان میموری درکار ہے، N=2 کو ≥ 128 GB، N=3 کو ≥ 160 GB؛ پیداواری N ≥ 2 کا تعلق CUDA بیک اینڈ سے ہے، جسے ایک GPU نوڈ درکار ہے جو ابھی موجود نہیں۔ قیود کے سیٹ 7 کے تحت 256 GB کی مشین پر ناپا گیا (2026-09-28 اور 29): N=2 ایگریگیٹ نے 133 GB لیے، N=3 نے 221 GB، اور پیداواری اختتامی ثبوت (ایک اندرونی ثبوت پر تصدیق کنندہ پروگرام) 256 GB سے تجاوز کر گیا۔ ان میں سے کچھ بھی قیود کے سیٹ 8 کے تحت دوبارہ نہیں ناپا گیا۔ جب تک ایگریگیشن فعال نہیں ہوتی، chain 20 پر کوئی ایگریگیٹ کسی ثبوت کا قائم مقام نہیں: اس کے دو آرکائیو نوڈ ہر خام ثبوت محفوظ رکھتے ہیں، اور اس کے ویلیڈیٹرز 24 گھنٹے سے پرانی تاریخ کی کانٹ چھانٹ کر دیتے ہیں۔