zkVM کیسے کام کرتا ہے

میں اس پڑھنے سے Rand کے ہر ثبوت کے پیچھے کام کرنے والی مشین کو سمجھیں: یہ کیا ثابت کرتی ہے، کسی پروگرام کا ایک رن کیسے ایسی چیز بنتا ہے جسے ویلیڈیٹر چند ملی سیکنڈ میں جانچ سکے، اور رازداری کہاں سے آتی ہے۔ ثبوت کی لاگت اور والیٹ اسے کیسے بناتا ہے، اس کے لیے ثبوت دیکھیں۔ پیرامیٹرز اور ہیش کی ساختوں کے لیے خفیہ نگاری دیکھیں۔ وہ ہدایاتی سیٹ جس کے مطابق پروگرام لکھا جاتا ہے، اس کے لیے RISC-V کا ISA دیکھیں۔

وہ واحد بیان جو ہر ثبوت پیش کرتا ہے

zkVM ایک ہی قسم کا بیان ثابت کرتی ہے، چین پر چلنے والے ہر پروگرام کے لیے:

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

شیلڈڈ منتقلی یہی بیان ہے جو ایک مقررہ پروگرام، یعنی پوشیدہ اثاثہ بنڈل گیسٹ، کے بارے میں دیا جاتا ہے، جس کا hc جینیسس فائل میں hc_bundle کے طور پر طے ہے۔ چین 17 سے یہ ہر منتقلی میں دو بار دیا جاتا ہے: auth گیسٹ (جینیسس فائل میں hc_auth) کے بارے میں ایک دوسرا، چھوٹا ثبوت یہ دکھاتا ہے کہ بھیجنے والے کے پاس خرچ کی کلید موجود ہے (ثبوت)۔ خفیہ کال یہی بیان ہے جو کسی تعینات شدہ پروگرام کے بارے میں دیا جاتا ہے۔ ان سب کے لیے ایک ہی مشین، ایک ہی تصدیق کنندہ اور قیود کا ایک ہی سیٹ ہے۔ چنانچہ کسی پروگرام کو تعینات کرنا ڈیٹا کا عمل ہے (اس کے الفاظ اور hc محفوظ کرنا)، خفیہ نگاری کا عمل نہیں: نہ ہر پروگرام کے لیے الگ سرکٹ ہے اور نہ کوئی قابلِ اعتماد سیٹ اپ۔

ثبوت کا نظام ایک STARK ہے جو Plonky3 سے بنایا گیا ہے۔ اسے ہیش فنکشن کے سوا کسی چیز کی ضرورت نہیں: نہ سیٹ اپ کی تقریب اور نہ بیضوی منحنیات، اس لیے اس میں ایسا کچھ نہیں جسے Shor کا الگورتھم توڑ سکے۔

پائپ لائن

 secret input ──► run the program ──► execution trace ──► polynomials ──► commit ──► FRI ──► proof
 (keys,           (RV32IM emulator)   (nine tables,      (one per       (8× code,   (80 queries,
  notes, paths)                        one row per step)  column)        Merkle)     20-bit grinding)

 every validator:  recompute the challenges from the Merkle roots, open 80 random positions,
                   check the rules there  →  ≈ 16 ms

اوپر والی قطار ایک بار، بھیجنے والے کی مشین پر چلتی ہے، بنڈل کے لیے تقریباً 100 سیکنڈ میں اور اس کے ساتھ والے اجازت نامے کے ثبوت کے لیے تقریباً 7 سیکنڈ میں۔ نیچے والی قطار ہر ویلیڈیٹر پر چلتی ہے، صرف عوامی فیلڈز اور ثبوت کی بنیاد پر۔

1. پروگرام چلائیں اور سب کچھ درج کریں

مشین ایک 32-بٹ RISC-V پروسیسر ہے: RV32IM، جس میں سے FENCE، CSR ہدایات اور EBREAK نکال دی گئی ہیں (RISC-V کا ISA)۔ ثابت کنندہ پہلے پروگرام کو ایک ایمولیٹر پر چلاتا ہے اور ہر کلاک ٹک کے لیے ایک قطار درج کرتا ہے۔ یہ ریکارڈ عملدرآمد کا ٹریس ہے۔ جس کے پاس یہ ہو وہ رن کو قدم بہ قدم دہرا سکتا ہے؛ باقی پورا نظام اس لیے ہے کہ تصدیق کنندہ ٹریس اپنے پاس رکھے بغیر اس کی درستی پر مطمئن ہو سکے۔

پروگرام بیرونی دنیا سے صرف آٹھ سسٹم کالز کے ذریعے رابطہ کرتا ہے، کسی اور ذریعے سے نہیں:

نوٹ کمٹمنٹس، نلیفائرز اور مرکل راستے مشین میں شامل نہیں۔ یہ عام گیسٹ کوڈ ہیں جو میموری میں ڈومین ٹیگ والا پیغام تیار کر کے POSEIDON2 کو کال کرتا ہے۔ یہ سسٹم کال پیڈنگ نہیں کرتی، اس لیے [a] اور [a, 0] کا ہیش ایک جیسا ہوتا ہے۔ فراہم کردہ گیسٹ اسے صرف مقررہ لمبائی والے پیغامات پر کال کرتے ہیں۔ کوئی نیا پروگرام جو متغیر لمبائی والا ڈیٹا ہیش کرے، POSEIDON2_LEN استعمال کرتا ہے (RISC-V کا ISA)۔

اسقاط کا کوئی راستہ نہیں

پروسیسر میں کوئی ایسی ہدایت نہیں جو مکمل ہونے سے انکار کرے، اس لیے کوئی جانچ ناکام ہونے پر پروگرام رک نہیں سکتا۔ اس کے بجائے بنڈل گیسٹ ناکامی کو درج کرتا ہے: ہر ناکام جانچ bad نامی رجسٹر میں 1 کو OR کرتی ہے، اور bad وہ آخری لفظ ہے جو آؤٹ پٹ ڈائجسٹ میں ہیش ہوتا ہے:

D = H(64; anchor, nf₀..₃, cm₀..₃, fee, burn_a, burn_r, burn_asset, time, c, bad)

c اجازت نامے کی وہ کمٹمنٹ ہے جو auth ثبوت بھی شائع کرتا ہے (چین 17 سے؛ چین 14 سے 16 تک کے ڈائجسٹ میں c نہیں تھا)۔

چین D کا پری امیج کبھی بھیجنے والے سے نہیں لیتی۔ وہ لین دین کی عوامی فیلڈز سے پری امیج خود دوبارہ بناتی ہے، bad = 0 خود مقرر کرتی ہے، ہیش کرتی ہے اور موازنہ کرتی ہے۔ دھوکے باز ایسے رن کا بالکل درست ثبوت بنا سکتا ہے جس میں کوئی جانچ ناکام ہوئی ہو، مگر اس رن نے H(…, 1) لکھا، جبکہ چین H(…, 0) تلاش کر رہی ہے۔ دونوں کو ملانے کے لیے ہیش کا تصادم درکار ہے۔

2. ٹریس کو نو جدولوں میں تقسیم کریں

پورے پروسیسر کو بیان کرنے والا ایک ہی جدول بے جا طور پر چوڑا ہوتا، اس لیے ٹریس کو مخصوص جدولوں میں تقسیم کیا جاتا ہے جو ایک ہی بیچ کے طور پر اکٹھے ثابت ہوتے ہیں:

دو مزید جدول، keccak اور sha256، صرف اسی ثبوت میں موجود ہوتے ہیں جس کے پروگرام نے انہیں کال کیا ہو، اور موجود ہونے پر ہر ایک کم از کم 2⁷ قطاروں کا ہوتا ہے؛ بنڈل گیسٹ ان میں سے کوئی استعمال نہیں کرتا۔ ہر اعلان شدہ جدول پر 2⁷ قطاروں کی کم از کم حد قیود کے سیٹ 7 کے ساتھ آئی (حصہ 9)۔

درجہ t ان میں سے ایک ہے: 10، 12، 14، 16، 18 یا 20، اور یہی جدولوں کا حجم طے کرتا ہے۔ ہر بنڈل درجہ 14 پر ثابت ہوتا ہے: 16,384 قطاروں والا CPU جدول، جس میں سے گیسٹ تقریباً 12,400 استعمال کرتا ہے۔ auth گیسٹ درجہ 10 پر 250 سائیکل چلتا ہے۔ باقی پیڈنگ ہے، اس لیے ثبوت یہ تو ظاہر کرتا ہے کہ پروگرام کو کون سا درجہ درکار تھا، مگر یہ کبھی نہیں کہ اس کے اندر کتنے قدم لگے (درجات)۔

میموری جدول ہی RAM کو قابلِ جانچ بناتا ہے۔ چونکہ یہ پہلے پتے اور پھر وقت کے لحاظ سے ترتیب شدہ ہے، اس لیے “کسی پتے سے پڑھائی وہی قدر لوٹاتی ہے جو اس پتے پر آخری بار لکھی گئی” دو متصل قطاروں کے درمیان ایک اصول بن جاتا ہے۔

3. جدولوں کو بسوں سے جوڑیں

تصدیق کنندہ کو کیسے معلوم ہو کہ CPU نے جو مجموعہ استعمال کیا وہی ہے جو ALU نے حساب کیا؟ بسوں کے ذریعے۔ جب CPU کو جمع کی ضرورت ہوتی ہے تو وہ ایک پیغام (op, a, b, c) بھیجتا ہے؛ ALU اپنی حساب کردہ ہر قطار کے لیے ایک پیغام وصول کرتا ہے۔ مشین میں سترہ بسیں ہیں:

بسوں کی جانچ لوگارتھمی مشتق دلیل (LogUp) سے ہوتی ہے۔ جدولوں کے کمٹ ہونے کے بعد ایک بے ترتیب قدر α نکالی جاتی ہے، اور ہر جدول اپنے بھیجے یا وصول کیے گئے پیغامات پر ±1/(α − m) کا جاری مجموعہ رکھتا ہے۔ مجموعے ٹھیک اسی صورت میں مکمل طور پر ایک دوسرے کو منسوخ کرتے ہیں جب بھیجا گیا ہر پیغام وصول ہوا ہو، یعنی دونوں طرف ایک ہی ملٹی سیٹ ہو۔ ایک بھی جعلی پیغام ایک باقیہ چھوڑ دیتا ہے جسے بے ترتیب α انتہائی بلند امکان کے ساتھ ظاہر کر دیتا ہے۔ میموری بس اسی سے قریبی طریقہ، ملٹی سیٹ پرمیوٹیشن جانچ، استعمال کرتی ہے۔

ہر جدول اپنے جاری مجموعے کی آخری قدر، یعنی اپنا ٹرمینل، شائع کرتا ہے، اور تصدیق کنندہ جانچتا ہے کہ ٹرمینلز کا مجموعہ صفر ہے۔ قیود کے سیٹ 6 تک ٹرمینل اپنے جدول کے مندرجات کا ایک قابلِ جانچ فنکشن تھا۔ قیود کے سیٹ 7 سے ہر جدول میں پانچ اضافی کالم ہیں اور وہ اپنی پہلی قطار پر BLIND بس پر ایک بے ترتیب قدر بھیجتا ہے اور اپنے پڑوسی کی قدر وصول کرتا ہے۔ ہر ٹرمینل چیلنج فیلڈ کے ایک یکساں عنصر جتنا بدل جاتا ہے، اور مجموعہ صفر ہی رہتا ہے۔

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

4. ٹریس کو بیرونی دنیا سے مربوط کریں

پینتیس عوامی اقدار ٹریس سے باہر آتی ہیں، سب CPU جدول میں:

چونکہ hc سرکٹ کے اندر حساب کیا جاتا ہے، اس لیے کسی دوسرے پروگرام کے بارے میں ثبوت بنڈل گیسٹ کے ثبوت کے طور پر قبول نہیں ہو سکتا۔ تصدیق کنندہ کبھی کوئی ہدایتی لفظ نہیں دیکھتا؛ وہ hc کا موازنہ اس ڈائجسٹ سے کرتا ہے جس کی اسے توقع ہے۔ چونکہ H_IN پر سالٹ لگا ہوتا ہے، اس لیے یہ نجی ان پٹ کو ظاہر کیے بغیر اس کا پابند بناتا ہے، حتیٰ کہ اس شخص کے سامنے بھی جو اس کا اندازہ لگا سکتا ہو۔ چونکہ H_PUB پر سالٹ نہیں لگتا، اس لیے تصدیق کنندہ اسے ان الفاظ سے دوبارہ حساب کر سکتا ہے جو اس کے پاس پہلے سے موجود ہیں۔ بنڈل کے لیے یہ الفاظ ٹرانزیکشن بائنڈنگ ہیں، یعنی blake3("rand-tx-bind-1" ‖ chain_id ‖ tx)، جو ٹرانزیکشن پر اس کے ثبوت کے بائٹس خالی کر کے لیا جاتا ہے، لہٰذا اگر کسی ثبوت کو مختلف منزل، میمو، لفافے یا chain id والی ٹرانزیکشن پر نقل کیا جائے تو اس کی تصدیق نہیں ہوتی۔ چین 20 پر (genesis binding_domain: 1) یہ blake3("rand-tx-bind-2" ‖ genesis_hash ‖ chain_id ‖ tx) ہے، لہٰذا کسی دوسری چین پر ثبوت کی تصدیق نہیں ہوتی، خواہ chain id وہی ہو؛ یہ الفاظ عوامی ان پٹ ہیں، اس لیے اس تبدیلی سے سرکٹ میں کچھ نہیں بدلا۔ توثیقی (auth) ثبوت انہی آٹھ الفاظ پر بنایا جاتا ہے۔ چین 20 پر کال کا ثبوت بھی اسی طرح پابند کیا جاتا ہے: اس کا حصہ پروگرام کے ڈیپلائے کے وقت کے عوامی الفاظ پر مشتمل ہوتا ہے، جن کے بعد کال بائنڈنگ کے آٹھ الفاظ آتے ہیں (rand-call-bind-2، چین 20 سے پہلے rand-call-bind-1)، لہٰذا اگر کال کے ثبوت کو کسی دوسرے فیس بنڈل کے تحت نقل کیا جائے تو اس کی تصدیق نہیں ہوتی۔

گیس مشین کا وہ پیمانہ ہے جس سے کسی رن کا بوجھ ناپا جاتا ہے، اور قیود کے مجموعہ 8 سے یہ سرکٹ میں شامل ہے۔ CPU جدول میں ایک GAS کالم ہوتا ہے جو 1 سے شروع ہوتا ہے اور ہر قطار پر 1، Poseidon2 کی ہر absorb قطار پر 3، ہر SHA256 قطار پر 64 اور ہر KECCAK قطار پر 192 بڑھتا ہے۔ HALT قطار پر سرکٹ فرق کے چار رینج سے جانچے گئے اجزا (limbs) کے ذریعے GAS ≤ GAS_LIMIT ثابت کرتا ہے، اور یہ اجزا کبھی کھولے نہیں جاتے: حد عوامی ہے، جبکہ کسی رن میں خرچ ہونے والی گیس عوامی نہیں۔ تصدیق کنندہ کلید بنانے سے پہلے ہی ایسی حد کو مسترد کر دیتا ہے جو اس سے زیادہ ہو جس کی ثبوت کے اپنے ہیڈر کو ضرورت ہو سکتی ہے:

gas_max(t, k, s) = (2ᵗ − 1) + 2ᵗ⁻² + 191·(2ᵏ / 32) + 63·(2ˢ / 64)

جہاں k اور s بالترتیب keccak اور sha256 جدولوں کی اعلان کردہ لاگ بلندیاں ہیں، اور غیر موجود جدول کے لیے متعلقہ رکن صفر ہوتا ہے۔ ہیش سے خالی درجہ 10 کے ہیڈر کی بالائی حد 1,279 ہے اور درجہ 14 کے ہیڈر کی 20,479۔ چین کسی کال کی قیمت اس کی اعلان کردہ حد کے مطابق لگاتی ہے (فیس)۔

5. قواعد کو کثیر رکنی مساواتوں میں بدلنا

ہر کالم Goldilocks فیلڈ کے اعداد کی ایک فہرست ہے، یعنی ماڈیولو p = 2⁶⁴ − 2³² + 1 صحیح اعداد۔ n اعداد کی فہرست اور n سے کم درجے کی کثیر رکنی ایک ہی چیز ہیں: وہ کثیر رکنی جو ان اعداد سے گزرتی ہے جب انہیں فیلڈ کے ذیلی گروپ {1, ω, ω², …} پر ترتیب دیا جائے۔ Goldilocks میں 2³² تک دو کی ہر قوت کے حجم کے ایسے ذیلی گروپ موجود ہیں، اس لیے یہ تبدیلی فاسٹ فوریئر ٹرانسفارم کے ذریعے ہوتی ہے۔

یوں مشین کا ہر قاعدہ کالموں کی کثیر رکنیوں کے درمیان ایک مساوات بن جاتا ہے۔ “پروگرام کاؤنٹر چار آگے بڑھتا ہے، سوائے اس کے کہ ہدایت جمپ کرے” خاکے کے طور پر یوں بنتا ہے:

is_jump(x)·(pc(ωx) − target(x)) + (1 − is_jump(x))·(pc(ωx) − pc(x) − 4) = 0

ذیلی گروپ کے ہر x کے لیے، جہاں pc(ωx) کا مطلب ہے “اگلی قطار”۔ کسی جدول کے ایسے تمام قواعد کا مجموعہ اس کی AIR (الجبری درمیانی نمائندگی) کہلاتا ہے۔ CPU اور ALU کے قواعد درجہ 8 تک پہنچتے ہیں؛ باقی 2 سے 4 تک رہتے ہیں۔

جو کثیر رکنی ذیلی گروپ کے ہر نقطے پر صفر ہو، وہ Z(x) = xⁿ − 1 سے قابلِ تقسیم ہوتی ہے۔ ثبوت دہندہ تمام قواعد کو بے ترتیب اوزان کے ساتھ ملا کر ایک کثیر رکنی C(x) بناتا ہے اور اسے Z(x) سے تقسیم کرتا ہے۔ اگر ہر قاعدہ ہر قطار پر درست ہو تو خارج قسمت واقعی کم درجے کی کثیر رکنی ہوتی ہے۔ اگر ایک قاعدہ ایک قطار پر بھی ناکام ہو تو ایسا نہیں ہوتا۔ “کیا 16,000 سائیکل کے رن کا ہر قدم درست تھا؟” کا سوال اب یہ بن گیا ہے کہ “کیا یہ فنکشن کسی کم درجے کی کثیر رکنی کے قریب ہے؟”، اور اس سوال کا جواب بے ترتیب طور پر منتخب چند اقدار دیکھ کر دیا جا سکتا ہے۔

6. سوالات معلوم ہونے سے پہلے کمٹ کرنا

ثبوت دہندہ کو تصدیق کنندہ کے بے ترتیب سوالات دیکھنے سے پہلے اپنی کثیر رکنیاں طے کرنی ہوتی ہیں، ورنہ وہ اپنے جوابات ان کے مطابق ڈھال سکتا ہے۔ وہ ہر کالم کو جدول سے آٹھ گنا بڑے ڈومین پر جانچتا ہے (blow-up 8، کوڈ ریٹ 1/8) اور ان اقدار پر ایک Merkle روٹ شائع کرتا ہے۔ یہ اضافی پن ایک Reed–Solomon کوڈ ہے: کم درجے کی کثیر رکنی اپنی اقدار کے کسی بھی آٹھویں حصے سے متعین ہو جاتی ہے، لہٰذا جو دھوکے باز ٹریس کی ایک قطار بھی بدلے، اسے مطابقت برقرار رکھنے کے لیے توسیع شدہ کوڈ ورڈ کا بیشتر حصہ بدلنا پڑتا ہے، اور بے ترتیب جانچیں اس بگاڑ تک پہنچ جائیں گی۔

Merkle درخت Goldilocks پر Poseidon2 استعمال کرتے ہیں: چوڑائی 8، S-box x⁷، 4 مکمل راؤنڈ، 22 جزوی راؤنڈ اور 4 مکمل راؤنڈ، اور چار فیلڈ عناصر (تقریباً 256 بٹ) کے ڈائجسٹ۔ ہر پتے کو تازہ بے ترتیبی کے چار عناصر کے ساتھ ہیش کیا جاتا ہے، لہٰذا روٹ اپنے نیچے کی اقدار کے بارے میں کچھ ظاہر نہیں کرتا۔ یہی پرموٹیشن مشین کے اندر نوٹ کمٹمنٹ اور nullifier ہیش بھی ہے۔ اس کے 86 راؤنڈ کانسٹنٹ نوڈ کے سورس (poseidon2_constants.rs) میں ایک لفظی جدول کی صورت میں درج ہیں، لہٰذا کسی لائبریری کی اپ گریڈ سے یہ نہیں بدل سکتے۔

7. FRI کے ذریعے نمونہ جاتی جانچ

اب تصدیق کنندہ کے پاس Merkle روٹ ہیں۔ پہلے وہ خارج قسمت کو ٹریس سے جوڑتا ہے: وہ جدول کے ڈومین سے باہر ایک بے ترتیب نقطہ z چنتا ہے، وہاں ہر کالم کی قدر اور خارج قسمت کی قدر طلب کرتا ہے، اور براہِ راست C(z) = Q(z)·Z(z) جانچتا ہے۔ باقی یہ تصدیق کرنا رہ جاتا ہے کہ کمٹ کیے گئے فنکشن واقعی کم درجے کی کثیر رکنیاں ہیں، اور یہی FRI جانچتا ہے۔

FRI تہہ کرنے (folding) کے ذریعے کام کرتا ہے۔ کثیر رکنی کو جفت اور طاق حصوں میں تقسیم کریں، f(x) = fₑ(x²) + x·fₒ(x²)۔ تصدیق کنندہ کے ایک بے ترتیب β کے لیے f′(y) = fₑ(y) + β·fₒ(y) کا درجہ آدھا ہوتا ہے اور ڈومین بھی آدھے حجم کا۔ ثبوت دہندہ f′ پر کمٹ کرتا ہے، نیا β لیتا ہے، اور دوبارہ تہہ کرتا ہے (Rand ہر راؤنڈ میں آٹھ گنا تک تہہ کرتا ہے) یہاں تک کہ ایک مستقل باقی رہ جائے، جسے وہ کھلے طور پر بھیج دیتا ہے۔ پھر ایک استفسار پہلی تہہ میں ایک بے ترتیب مقام چنتا ہے اور اسے نیچے تک لے جاتا ہے، اور ہر تہہ پر جانچتا ہے کہ اوپر کھولی گئی اقدار تہہ ہو کر نیچے والی قدر بنتی ہیں۔ جو فنکشن کم درجے سے بہت دور تھا، وہ ان تمام وعدوں کو باہم مطابق نہیں رکھ سکتا۔

Rand 80 استفسارات چلاتا ہے۔ ثابت شدہ proximity-gaps مسئلے کے تحت ہر استفسار دھوکے باز کے لیے زیادہ سے زیادہ 9/16 کا امکان چھوڑتا ہے، لہٰذا 80 استفسارات سے (9/16)⁸⁰ ≈ 2⁻⁶⁶·⁴ حاصل ہوتا ہے۔ ethSTARK قیاس کے تحت، جس پر رائج STARK انحصار کرتے ہیں، ہر استفسار 1/8 چھوڑتا ہے، جو کہیں کم ہے۔

8. مکالمے کو ختم کرنا

اوپر سب کچھ ایک مکالمے کے طور پر بیان کیا گیا، لیکن ٹرانزیکشن کو ایک ایسا واحد پیغام ہونا چاہیے جسے کوئی بھی ویلیڈیٹر اکیلے جانچ سکے۔ Fiat–Shamir تبدیلی تصدیق کنندہ کو ہٹا دیتی ہے: ثبوت دہندہ ہر “بے ترتیب” چیلنج کو اب تک کمٹ کی گئی ہر چیز کے ہیش کے طور پر، Poseidon2 ڈوپلیکس اسپنج کے ذریعے، حساب کرتا ہے۔ کسی بھی کمٹمنٹ کو بدلنے سے اس کے بعد کا ہر چیلنج بدل جاتا ہے، لہٰذا ثبوت دہندہ چیلنجوں کے مطابق کمٹمنٹ نہیں چن سکتا۔

اس سے رہ جانے والے خلا دو مزید اقدامات بند کرتے ہیں:

• توسیعی فیلڈ۔ 2⁶⁴ عناصر کی فیلڈ چیلنج نکالنے کے لیے بہت چھوٹی ہے: دھوکے باز کو ضرورت ہوتی ہے کہ چیلنج کسی کثیر رکنی کی چند خراب اقدار میں سے کسی ایک پر پڑے، اور وہ تقریباً N/2⁶⁴ کے امکان سے کامیاب ہو جاتا ہے، خواہ کتنے ہی استفسارات چلائے جائیں۔ اس لیے ٹریس Goldilocks ہی میں رہتا ہے، مگر ہر چیلنج اس کی دو درجی توسیع سے نکالا جاتا ہے، جس میں تقریباً 2¹²⁸ عناصر ہیں۔
• گرائنڈنگ۔ استفسار کے مقامات اخذ کیے جانے سے پہلے ثبوت دہندہ کو ایسا nonce تلاش کرنا ہوتا ہے جس کا ٹرانسکرپٹ کے ساتھ ہیش 20 صفر بٹس سے شروع ہو، یعنی تقریباً دس لاکھ ہیش۔ دیانت دار ثبوت دہندہ یہ قیمت ایک بار ادا کرتا ہے۔ جو دھوکے باز استفسار کے مقامات کو بار بار نئے سرے سے نکالے تاکہ وہ اس کی جعل سازی سے چوک جائیں، وہ ہر کوشش پر یہ قیمت ادا کرتا ہے۔ Rand میں یہ واحد proof of work ہے، اور اس کا اتفاقِ رائے سے کوئی تعلق نہیں۔

میزان: استفسارات سے 66.4 بٹ اور گرائنڈنگ سے 20 مل کر 86 بٹ ثابت شدہ بنتے ہیں، اور قیاس کے تحت تقریباً 100 بٹ، جہاں توسیعی فیلڈ کا رکن حد بنتا ہے۔

9. زیرو نالج کہاں سے آتا ہے

STARK بذاتِ خود زیرو نالج نہیں ہوتا: استفسار کے مقامات پر کھولی گئی اقدار ٹریس کی کثیر رکنیوں کی اقدار ہوتی ہیں، اور احتیاط نہ کی جائے تو وہ معلومات افشا کرتی ہیں۔ Rand کی ترتیب چار پرتیں شامل کرتی ہے:

1. ہر کمٹ کی گئی کثیر رکنی بے ترتیب بنائی جاتی ہے (Plonky3 کا hiding FRI چار بے ترتیب کوڈ ورڈ شامل کرتا ہے)، لہٰذا 80 کھولی گئی اقدار کو تقسیم کے لحاظ سے وہ شخص بھی دوبارہ پیدا کر سکتا ہے جس نے ٹریس کبھی نہیں دیکھا؛
2. ہر Merkle پتے پر سالٹ لگایا جاتا ہے، لہٰذا روٹ اور تصدیقی راستے کچھ ظاہر نہیں کرتے؛
3. ثبوت دہندہ کی بے ترتیبی ہر ثبوت کے لیے آپریٹنگ سسٹم سے تازہ لی جاتی ہے، لہٰذا ایک ہی ادائیگی کے دو ثبوت باہم غیر متعلق دکھائی دیتے ہیں؛
4. ہر اعلان کردہ جدول میں کم از کم 2⁷ قطاریں ہوتی ہیں اور ہر LogUp ٹرمینل پوشیدہ (blinded) کیا جاتا ہے (قیود کا مجموعہ 7)۔ ایک ثبوت ہر جدول کو 80 استفساری نقاط اور ڈومین سے باہر کے دو نقاط پر کھولتا ہے، اور hiding کمٹمنٹ اتنی ہی بے ترتیب قطاریں شامل کرتا ہے جتنی جدول میں قطاریں ہیں، لہٰذا جدول اسی وقت تک پوشیدہ رہتا ہے جب تک اس میں کم از کم 82 قطاریں ہوں۔ 128 دو کی وہ سب سے چھوٹی قوت ہے جو اس شرط کو پورا کرتی ہے۔

تہہ 4 ایک تصحیح ہے۔ 2026-09-27 کے جائزے میں تین کمزوریاں سامنے آئیں۔ پروڈکشن ثبوتوں سے اُن calls کے نجی inputs بازیافت ہو گئے جن میں 31 یا اس سے کم input words تھے۔ کسی پروگرام کی مختصر program table سے اس کی fetch counts پڑھ لی گئیں۔ کسی بنڈل کے غیر مخفی terminals سے اس کے اصل input slots کو dummy slots سے الگ پہچان لیا گیا۔ یہ وہ ثبوت ہیں جو chain 15 اور اس سے پہلے بنائے گئے تھے۔ Chain 16 نے، جس میں constraint set 7 اور branch-free بنڈل guest ہیں، تینوں کمزوریاں بند کر دیں، اور chains 18 تا 20 میں یہ اصلاحات برقرار ہیں۔

ضمانت random-oracle ماڈل میں شماریاتی زیرو نالج کی ہے۔ ثبوت جو کچھ نہیں چھپاتا وہ متعین ہے: اس کا درجہ (tier)، اس کی اعلان کردہ table heights، اور اس کی عوامی قدریں، جن میں gas limit بھی شامل ہے۔ اگر keccak یا sha256 کی اعلان کردہ height صفر ہو تو اس کا مطلب ہے کہ اجرا میں وہ ہیش کبھی استعمال نہیں ہوا۔ اس لیے کسی call کے ثبوت کا ہیڈر یہ ظاہر کرتا ہے کہ call نے ہیش استعمال کیا یا نہیں، اور کم از کم حد سے اوپر یہ بھی کہ کتنی بار، دو گنا کے فرق کی درستی تک۔ بنڈل کے لیے عوامی قدریں اور فیلڈز یہ ہیں: anchor، چار نلیفائرز، چار کمٹمنٹس، فیس، burns، burn asset، وقت، اجازت کا کمٹمنٹ اور ٹرانزیکشن binding۔ کوئی ٹرانسفر جو اثاثہ منتقل کرتا ہے وہ ایک نجی input ہے، اس لیے zUSD کی ادائیگی اور RAND کی ادائیگی چین پر ایک جیسی دکھائی دیتی ہیں۔ hc متعین (deterministic) ہے، لہٰذا کوئی بھی یہ جان سکتا ہے کہ ثبوت بنڈل guest سے متعلق ہے (قدر منتقل کرنے والا ہر ثبوت اسی سے متعلق ہوتا ہے)، یا کسی call کی صورت میں یہ کہ اس نے کون سا deployed پروگرام چلایا۔

10. ویلیڈیٹر کیا جانچتا ہے

Machine::verify_public(hc, words, proof) سب سے سستی جانچ سے آغاز کرتے ہوئے یہ مراحل چلاتا ہے:

1. ثبوت کا اعلان کردہ درجہ اور table heights محدود ہوں (check_declared_heights)، اور یہ جانچ ان کی بنیاد پر کسی بھی چیز کا حجم طے ہونے سے پہلے ہوتی ہے۔ یوں ایک خراب ہیڈر کی قیمت چند موازنوں تک محدود رہتی ہے، کئی سیکنڈ کی key تیاری تک نہیں پہنچتی۔ بنڈل کے لیے لازم ہے کہ وہ درجہ 14 کا اعلان کرے اور کوئی ہیش table نہ رکھے، اور auth ثبوت درجہ 10 کا اعلان کرے؛
2. عوامی قدریں 35 ہوں اور ہر ایک canonical فیلڈ عنصر ہو۔ ساتھ ہی pv[HC] = hc ہو، pv[TIER] ثبوت کے درجے کے برابر ہو، ہر output word 2³² سے کم ہو، اور GAS_LIMIT ہیڈر کے gas_max سے زیادہ نہ ہو؛
3. batch STARK کی تصدیق ایک ایسی verifier key کے مقابل ہو جو ہر shape (tier, program, input, keccak, sha256, public heights) کے لیے cache کی جاتی ہے، ہر پروگرام کے لیے نہیں؛
4. H_PUB کی قدر words کے digest کے برابر ہو۔ بنڈل کے معاملے میں یہ وہ ٹرانزیکشن binding ہے جو node نے خود حساب کی ہو۔

ان سب سے پہلے node ہر جمع کرائے گئے یا gossip کے ذریعے موصول ہونے والے ثبوت کی canonical encoding کی جانچ کرتا ہے: اس کا FRI folding schedule وہی ہونا چاہیے جو ایک دیانت دار ثبوت دہندہ ہیڈر میں اعلان کردہ degrees کے لیے بناتا ہے۔ fullnode v0.6.8 (audit v6، ZKV-4) سے یہ جانچ سب سے پہلے 25 bits سے زیادہ کی ہر اعلان کردہ degree کو رد کر دیتی ہے (MAX_HONEST_DEGREE_BITS، یعنی memory table کی 2²⁴ کی بالائی حد جمع زیرو نالج کے لیے دوگنا کیا جانا، جو کسی قبول شدہ ثبوت میں زیادہ سے زیادہ ممکن ہے)۔ یہ حد لگنے سے پہلے، بہت بڑی degree کا اعلان کرنے والا ہیڈر node کو اپنے event loop پر ایک بہت بڑا folding schedule دوبارہ اخذ کرنے پر مجبور کر دیتا تھا اور اسے اُتنی دیر روکے رکھتا تھا جتنی دیر بھیجنے والا چاہتا۔ تصدیق کنندہ اس ثبوت کو ویسے بھی رد کر دیتا، اس لیے یہ حد صرف انکار کی لاگت بدلتی ہے۔ اب اس جانچ کے اندر panic ہونے پر node رکتا نہیں، صرف وہ ایک ٹرانزیکشن رد ہوتی ہے۔

اس کے بعد ledger بنڈل کا digest D کو bad = 0 کے ساتھ دوبارہ حساب کرتا ہے اور اس کا موازنہ ثبوت کے آٹھ output words سے کرتا ہے۔ chain 20 پر یہ بھی لازم ہے کہ بنڈل ثبوت کا GAS_LIMIT بالکل genesis کے bundle_gas_limit یعنی 20,479 کے برابر ہو، اور auth ثبوت کا 1,279 ہو، تاکہ ہر ٹرانسفر ایک جیسی قدروں کا اعلان کرے۔ key پہلے سے تیار ہو تو پوری جانچ میں تقریباً 16 ms لگتے ہیں۔

پیرامیٹرز، اور ان کے انتخاب کی وجہ

نیچے دیا گیا ہر عدد consensus کا حصہ ہے۔ تصدیق کنندہ اسے جانچتا ہے، کسی دوسری قدر سے بنایا گیا ثبوت تصدیق میں ناکام رہتا ہے، اور کسی ایک کو بدلنا ایک نیا constraint set اور ایک ہارڈ فورک ہے (Constraint sets)۔ FRI profile genesis فائل طے کرتی ہے (chain 20 پر fri_profile: production)، ثبوت کبھی طے نہیں کرتا۔

ان اعداد کا حاصل: صحتِ ثبوت کے 86 بٹ ثابت شدہ، ethSTARK قیاس کے تحت تقریباً 100 (جہاں حد سوالات نہیں بلکہ توسیعی فیلڈ ہے)، اور کوانٹم مخالف کے مقابل تقریباً 85 بٹ، جو 256 بٹ ٹرانسکرپٹ ہیش سے طے ہوتے ہیں۔ وائٹ پیپر جان بوجھ کر صحتِ ثبوت کے دونوں اعداد ساتھ ساتھ رکھتا ہے: ہر تعینات شدہ FRI-STARK اپنے آخری بٹس کے لیے اسی قیاس پر انحصار کرتا ہے، اور تعیناتی کا حجم طے کرنے والے قاری کو معلوم ہونا چاہیے کہ کون سے بٹ کس مفروضے پر قائم ہیں۔

ثبوتوں کے بارے میں ثبوت

تقریباً 1.50 MB کا بنڈل ثبوت بھاری ہے، 1.37 MB کا auth ثبوت اس کے ساتھ چلتا ہے، اور ہر نوڈ ان سب کو محفوظ کرتا ہے۔ جو علاج تیار کیا گیا ہے وہ ریکرژن ہے: ایسا ثبوت جس کا بیان یہ ہو کہ “میں نے ان ثبوتوں کی تصدیق کی ہے”۔ fullnode اس کے لیے ایک دوسری، چھوٹی مشین رکھتا ہے، ریکرژن VM، جس کا بنیادی لفظ ایک Goldilocks عنصر ہے اور جس کی ہدایات تصدیق کنندہ کی اپنی عملیات ہیں (فیلڈ حساب کاری، Poseidon2، Merkle اور FRI کے مراحل)۔ اس کا مجموعی پروگرام N بنڈل ثبوتوں کی مکمل تصدیق دوبارہ چلاتا ہے اور ان کی عوامی قدروں پر ایک ڈائجسٹ شائع کرتا ہے، جو چین، مجتمع کنندہ اور ایک nonce سے بندھا ہوتا ہے۔ اس کے اندر ایک بنڈل ثبوت کی تصدیق پر قیود کے مجموعہ 6 کے تحت 1,968,619 قطاریں اور مجموعہ 7 کے تحت 2,044,506 قطاریں لگیں؛ مجموعہ 8 کے تحت اسے دوبارہ نہیں ماپا گیا۔ یہ نافذ شدہ ہے اور اب تک ہر چین پر، chain 20 سمیت، genesis کے ذریعے بند ہے۔ مجموعی پروگرام صرف بنڈل ثبوتوں کی تصدیق کرتا ہے، اس لیے منقسم اجازت والی چین پر auth ثبوت برقرار رہے گا۔ اس کے پیداواری ثبوتوں کو منصوبے سے زیادہ میموری بھی درکار ہے: قیود کے مجموعہ 7 کے تحت ماپی گئی 133 GB اور اس سے زیادہ (آئندہ: بلاک ایگریگیشن)۔

یہ اسکیم کس چیز کا دعویٰ نہیں کرتی

• کوانٹم حاشیۂ تحفظ تقریباً 85 بٹ ہے، 128 نہیں۔ کسی n بٹ ہیش پر کوانٹم تصادم کی تلاش کی لاگت تقریباً 2ⁿ/³ ہوتی ہے۔ وائٹ پیپر کا ڈیزائن 384 بٹ ٹرانسکرپٹ ہیش کا تقاضا کرتا ہے؛ جاری چین 256 بٹ Poseidon2 ڈائجسٹ استعمال کرتی ہے۔ اسے وسیع کرنا ایک نیا مجموعۂ قیود اور ایک ہارڈ فورک ہے۔
• 100 بٹ ایک قیاس ہے؛ 86 ثابت شدہ ہے۔ ثابت شدہ عدد کو 100 تک بڑھانے کے لیے 97 استفسارات درکار ہوں گے، یعنی فی ثبوت استفسارات کا ڈیٹا تقریباً پانچواں حصہ زیادہ۔
• Poseidon2 کے مستقلات ایک بیج پر مبنی قرعہ ہیں، کوئی شائع شدہ معیاری نفاذ نہیں۔ اس پر کوئی حملہ معلوم نہیں؛ کسی معیاری مجموعے کو اپنانے سے چین کا ہر ہیش بدل جائے گا۔
• کچھ بیانات کی جانچ ثبوت کے ساتھ ساتھ ہوتی ہے، ثبوت کے اندر نہیں۔ TIER عوامی قدر کا موازنہ تصدیق کنندہ ثبوت کی ساخت سے کرتا ہے، لیکن سرکٹ اسے مقید نہیں کرتا (آڈٹ ZL1)؛ اور بنڈل گیسٹ پروگرام کے آلودگی کے ضابطے کی پشت پر مشینی طور پر جانچا ہوا ثبوت نہیں بلکہ ساختی استدلال، کمزور کیے گئے گیسٹ پروگرام کا آزمائشی ڈھانچا اور تغیراتی فزنگ ہیں۔
• ثبوت کا ہیڈر پوشیدہ نہیں ہوتا۔ درجہ اور دونوں ہیش ٹیبلوں کی بلندیاں کھلی ہوتی ہیں، اس لیے کال کا ثبوت ظاہر کر دیتا ہے کہ کال نے KECCAK استعمال کیا یا SHA256۔ ثابت کنندہ میں دونوں ٹیبلوں کو بھرائی کے ذریعے برابر کرنے کا ایک اختیار موجود ہے اور کوئی والیٹ اسے فعال نہیں کرتا: اس سے درجہ 10 کا ثبوت تقریباً 1.3 MB سے بڑھ کر تقریباً 3.6 MB ہو جاتا ہے۔
• POSEIDON2 سسٹم کال متغیر لمبائی والے ان پٹ پر یک بہ یک نہیں ہے۔ اسے جوں کا توں رکھا گیا ہے کیونکہ ہر عہد، ہر نلیفائر، ہر روٹ اور ہر پروگرام ڈائجسٹ اسی پر منحصر ہے۔ اب تک کوئی جاری شدہ گیسٹ پروگرام POSEIDON2_LEN استعمال نہیں کرتا۔
• ثبوت سازی سست ہے اور اسے بھیجنے والا خود انجام دیتا ہے، یا وہ ثابت کنندہ جس کے ساتھ بھیجنے والا جوڑ بناتا ہے: لیپ ٹاپ کے سی پی یو پر ایک بنڈل کے لیے تقریباً 100 s اور 5.7 GB۔ جی پی یو کرنلز پہلی بار 2026-09-28 کو ایک جی پی یو (NVIDIA H100) پر چلے اور سی پی یو کے حوالہ نتائج سے مطابقت رکھتے پائے گئے؛ والیٹ اب بھی سی پی یو پر ہی ثبوت تیار کرتا ہے۔

مزید مطالعے کے لیے

• وائٹ پیپر کا حصہ “The Zero-Knowledge Scheme: How a Rand Proof Works” (randprotocol.tex) انہی سات اجزا کو درستی کے مسئلات کے ساتھ مرحلہ وار بیان کرتا ہے۔
• نفاذ کا مقالہ (randprotocol_implementation.tex) ہدایاتی مجموعہ اور سسٹم کالز، بنڈل گیسٹ پروگرام، اسپنج اور ڈائجسٹ، ہر ٹیبل اور بس، مشین کی ترتیب اور تکراری ورچوئل مشین کی تفصیلات متعین کرتا ہے۔
• کوڈ: fullnode میں crates/randprotocol-zkvm/src/ — emulator.rs، tables/، machine.rs، gas.rs، guests.rs، hash.rs، poseidon2_constants.rs۔