ڈیزائن سے متعلق عمومی سوالات

یہ صفحہ Rand کے ہر بڑے ڈیزائن فیصلے کی توجیہ درج کرتا ہے: وہ خاصیت جو کسی جزو کو فراہم کرنی ہے، وہ مفروضہ جس کے تحت وہ اسے فراہم کرتا ہے، اور اس کے بدلے میں قبول کی گئی قیمت۔ اسے 29 September 2026 کو اس سائٹ، وائٹ پیپر کے خلاصے اور ریفرنس فُل نوڈ (github.com/randprotocol/fullnode: اس کی README، docs/ اور docs/superpowers/specs/) سے مرتب کیا گیا۔ ہر جواب اس دستاویز کا حوالہ دیتا ہے جس میں توجیہ بیان کی گئی ہے؛ راستے (paths) fullnode ریپوزٹری کے لیے ہیں، سوائے ان کے جو randprotocol.org سے شروع ہوتے ہیں۔

حیثیت۔ Rand ایک testnet پر چلتا ہے جسے بانی ٹیم چلاتی ہے، اور پروٹوکول کا کوئی آزادانہ آڈٹ نہیں ہوا۔ ذیل کے کئی فیصلے چین کے مختلف ایڈیشنز (chain cuts) میں مرحلہ وار نافذ ہو رہے ہیں۔ تمام اعداد و شمار مرتب کرتے وقت چلتے ہوئے نوڈ کی پیمائشیں ہیں؛ ان میں تبدیلی متوقع ہے اور حوالہ دینے سے پہلے انہیں دوبارہ ناپنا چاہیے۔

کرپٹوگرافک بنیادی اجزاء

1. نوٹ کی انکرپشن کے لیے ML-KEM-768 (Kyber) کیوں؟

نوٹ کا پلین ٹیکسٹ اس کے وصول کنندہ کے لیے ایک لفافے (envelope) میں انکرپٹ کیا جاتا ہے جو عوامی لیجر پر غیر معینہ مدت تک موجود رہتا ہے۔ اس لیے اس کی رازداری ایک ناقابلِ تنسیخ خاصیت ہے (سوال 8): جو حریف بعد کے کسی بھی وقت کوئی کرپٹوگرافی کے لحاظ سے متعلقہ کوانٹم کمپیوٹر حاصل کر لے، وہ ایلپٹک کروو KEM کے تحت بند کیے گئے ہر تاریخی لفافے کو ڈیکرپٹ کر سکتا ہے، کیونکہ Shor کا الگورتھم ڈسکریٹ لوگارتھم کو کثیر رکنی وقت میں حل کر دیتا ہے۔ ML-KEM کو NIST FIPS 203 میں معیاری بنایا گیا ہے اور اس کی سلامتی Module-LWE پر مبنی ہے، جس کے لیے کوئی مؤثر کوانٹم الگورتھم معلوم نہیں۔ 768 پیرامیٹر سیٹ (NIST زمرہ 3) کو سلامتی کے مارجن اور 1,184 بائٹ کی انکیپسولیشن کی (encapsulation key) کے درمیان توازن کے طور پر چنا گیا، جو ہر ایڈریس کو اپنے ساتھ رکھنی پڑتی ہے۔ لفافہ ML-KEM-768 اور ChaCha20-Poly1305 کا مجموعہ ہے: 1,348 بائٹ، یا مقررہ میمو فیلڈ کے ساتھ 1,860 بائٹ۔

ماخذ: randprotocol.org (post-quantum سیکشن)؛ fullnode README؛ docs/shielded.md §2

2. Pedersen کے بجائے Poseidon2 commitments کیوں؟

Pedersen commitments مکمل طور پر چھپانے والے (perfectly hiding) ہیں مگر صرف حسابی طور پر پابند کرنے والے (computationally binding)، اور ان کی binding ڈسکریٹ لوگارتھم کے مفروضے پر منحصر ہے جسے کوانٹم حریف توڑ دیتا ہے؛ جو حریف ڈسکریٹ لوگارتھم نکال سکتا ہو وہ کسی commitment کو کسی دوسری قدر کے لیے کھول سکتا ہے۔ چونکہ آج شائع کی گئی commitment کو لیجر کی پوری عمر تک درست اور چھپانے والی رہنا ہے، اس لیے اسکیم کو ایسے مفروضوں پر قائم ہونا چاہیے جو کوانٹم حریفوں کے مقابل بھی قائم سمجھے جاتے ہیں، جس کا عملی مطلب ہیش فنکشن ہے۔ Poseidon2 ایک ریاضیاتی ساخت پر مبنی (arithmetisation-oriented) ہیش ہے جو Goldilocks فیلڈ پر متعین ہے، اس لیے STARK کے اندر اس کی تشخیص میں کم constraints لگتے ہیں۔ یہی ہیش نوٹ commitment، گہرائی 32 کے Merkle ٹری اور nullifier کو قائم کرتا ہے۔

ماخذ: randprotocol.org (post-quantum سیکشن)؛ docs/shielded.md §1–2

3. دو ہیش فنکشن — BLAKE3 اور Poseidon2 — کیوں؟

دونوں فنکشن مختلف لاگتی ماڈلز کے لیے بہتر بنائے گئے ہیں۔ Poseidon2 وہاں استعمال ہوتا ہے جہاں ہیش کو کسی ثبوت کے اندر جانچنا ہو — نوٹس، commitment ٹری، nullifiers اور zkVM کے اندرونی جداول — کیونکہ اس کی لاگت constraints میں ناپی جاتی ہے۔ BLAKE3 وہاں استعمال ہوتا ہے جہاں کوئی ثبوت شامل نہ ہو اور مقامی تھرو پُٹ غالب ہو: بلاک ہیش، ٹری، nullifier سیٹ، ویلیڈیٹر رجسٹر اور پروگرام ٹیبل پر state root، اور ویلیڈیٹر ایڈریس (پبلک کی کا BLAKE3 ڈائجسٹ)۔ Poseidon2 CPU پر نسبتاً سست ہے؛ BLAKE3 کو ریاضیاتی شکل (arithmetise) دینا نسبتاً مہنگا ہے۔ ہر ایک وہیں استعمال ہوتا ہے جہاں اس کا لاگتی ماڈل لاگو ہو۔

ماخذ: fullnode README (signatures / hashes row)؛ docs/architecture.md

4. ویلیڈیٹر دستخطوں کے لیے Dilithium2 (ML-DSA) کیوں؟

اتفاقِ رائے (consensus) کے دستخط ایک قابلِ تجدید خاصیت فراہم کرتے ہیں (سوال 8): اسکیم کے بعد میں ٹوٹنے سے مستقبل کے پیغامات کی جعلسازی ممکن ہو جاتی ہے مگر پہلے سے حتمی ہو چکے بلاکس سابقہ اثر کے ساتھ باطل نہیں ہوتے، اس لیے اصولاً اسکیم کو کوانٹم حریف کے وجود میں آنے سے پہلے بدلا جا سکتا ہے۔ اس کے باوجود جینیسس ہی سے lattice اسکیم اپنائی گئی تاکہ consensus ووٹس، bridge گارڈینز کے مشترکہ دستخط (co-signatures) اور ویلیڈیٹر رجسٹر ایک ہی post-quantum کی قسم میں شریک ہوں۔ نوڈ Dilithium2 کا round-3 پیرامیٹر سیٹ نافذ کرتا ہے (crystals-dilithium crate)، جو حتمی FIPS 204 ML-DSA-44 سے مختلف ہے؛ پبلک کیز 1,312 بائٹ اور دستخط 2,420 بائٹ کے ہیں۔

ماخذ: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2؛ randprotocol.org

5. SNARK کے بجائے شفاف STARK (Goldilocks پر FRI) کیوں؟

یہ انتخاب تین تقاضوں سے نکلتا ہے۔ اول، کوئی trusted setup نہیں: درستی (soundness) صرف ہیش فنکشن کی ٹکراؤ سے مزاحمت پر قائم ہے، کسی ساختہ حوالہ جاتی اسٹرنگ یا pairing کے موافق کروو پر نہیں۔ دوم، قرین قیاس post-quantum درستی: دلیل ڈسکریٹ لوگارتھم یا pairing کا کوئی مفروضہ نہیں بناتی۔ سوم، سوال 2 کی ہیش پر مبنی commitment اسکیم کے ساتھ مطابقت۔ قیمت ثبوت کا حجم ہے: ایک bundle ثبوت تقریباً 1.3 MB کا ہوتا ہے، جو Zcash یا Monero کے shielded ٹرانزیکشن سے 300–600 گنا بڑا ہے۔ یہ قیمت قبول کی گئی اور اسے بلاک کی سطح کی aggregation کے ذریعے الگ سے حل کیا گیا ہے (سوالات 31 اور 34)۔

ماخذ: randprotocol.org؛ docs/block-space.md §1؛ docs/zkvm.md

6. 27 کے بجائے 80-query FRI پروفائل کیوں؟

پروڈکشن پروفائل (80 queries، blowup factor 8، 20 بٹ proof-of-work grinding) تقریباً 86 بٹ ثابت شدہ (provable) درستی فراہم کرتا ہے، جبکہ 27-query پروفائل تقریباً 42 بٹ، اور ثبوت کا حجم 2.75 گنا ہوتا ہے۔ تصدیق کا وقت تقریباً بدستور رہتا ہے: cold حالت میں 809 ms سے 838 ms، اور warm حالت میں تقریباً 16 ms۔ ثابت شدہ درستی کو ثبوت کے حجم پر ترجیح دی گئی، اور حجم کی قیمت بلاک اسپیس اور aggregation کے ڈیزائن کو منتقل کر دی گئی۔

ماخذ: docs/block-space.md §1, §3

7. post-quantum دعویٰ فی بنیادی جزو کیوں بیان کیا گیا ہے، ‘پروٹوکول بھر میں 128-بٹ’ کیوں نہیں؟

ابتدائی مسودوں میں پورے پروٹوکول کے لیے 128-بٹ post-quantum سلامتی کا دعویٰ کیا گیا تھا۔ یہ دعویٰ Brassard–Høyer–Tapp حد سے ہم آہنگ نہیں، جس کے مطابق کوانٹم حریف 256-بٹ ہیش میں تقریباً 2^85 queries میں ٹکراؤ (collisions) تلاش کر لیتا ہے، اس لیے اسے مشروط کرنے کے بجائے واپس لے لیا گیا۔ مقالہ اب سلامتی ہر بنیادی جزو اور ہر کردار کے لحاظ سے بیان کرتا ہے — 384-بٹ transcript ہیش، 256-بٹ ہیش جو صرف وہاں ہیں جہاں preimage مزاحمت درکار ہے، Dilithium2، ML-KEM-768، اور ایکسٹینشن فیلڈ پر FRI — Module-LWE اور Module-SIS مفروضوں کے تحت، جبکہ ہیش فنکشنز کو quantum random oracles کے طور پر ماڈل کیا گیا ہے۔ نوڈ کا transcript ہیش فی الحال Poseidon2 ہے؛ دستاویزات اسے کھلی کنفیگریشن خلیج کے طور پر درج کرتی ہیں۔

ماخذ: randprotocol.org (post-quantum سیکشن)

8. ‘ناقابلِ تنسیخ بمقابلہ قابلِ تجدید’ درجہ بندی کیا ہے اور یہ انتخاب کو کیوں طے کرتی ہے؟

کوئی سلامتی خاصیت ناقابلِ تنسیخ (irrevocable) ہے اگر کوئی حریف جو مستقبل میں کسی بھی وقت نئی صلاحیت حاصل کرے، اسے ان ڈیٹا کے لیے سابقہ اثر کے ساتھ توڑ سکے جو پہلے ہی شائع ہو چکا ہو؛ نوٹ کی رازداری اور commitment کا چھپانا اسی قسم کی ہیں، اس لیے انہیں اشاعت کے وقت ہی کوانٹم مزاحم ہونا چاہیے۔ کوئی خاصیت قابلِ تجدید (renewable) ہے اگر وہ ہر استعمال پر نئے سرے سے قائم کی جاتی ہو، تاکہ خطرے کے سامنے آنے سے پہلے اسکیم بدلی جا سکے؛ دستخط اور ثبوت کی درستی اسی قسم کے ہیں۔ اس سیکشن میں ہر بنیادی جزو کا انتخاب اس خاصیت کی درجہ بندی سے نکلتا ہے جس کی وہ حفاظت کرتا ہے۔

ماخذ: randprotocol.org (post-quantum سیکشن)

shielded پول

9. نوٹ/UTXO ماڈل کیوں، بغیر اکاؤنٹس یا بیلنسز کے؟

اکاؤنٹ پر مبنی لیجر اپنی ساخت ہی سے بیلنسز شائع کرتا ہے؛ انہیں چھپانے کے لیے state کو انکرپٹ کرنا اور سائفر ٹیکسٹس پر بیانات ثابت کرنا پڑتا ہے، جو کہیں زیادہ مہنگا ہے۔ نوٹ پول صرف commitments اور nullifiers محفوظ کرتا ہے، جن میں سے کوئی بھی مالک یا رقم ظاہر نہیں کرتا، اس لیے عوامی state میں بیلنس کی کوئی معلومات نہیں ہوتیں۔ واحد استثنا ویلیڈیٹر رجسٹر ہے، جس کے stake وزن عوامی ہونے چاہئیں تاکہ ریپلیکاز quorum کی رکنیت پر متفق ہوں (سوال 29)۔

ماخذ: docs/shielded.md §1–2؛ docs/staking.md §1

10. ایڈریس ~1.6 KB کا کیوں ہے؟

shielded ایڈریس 32 بائٹ کے مالک فیلڈ pk اور 1,184 بائٹ کی ML-KEM-768 انکیپسولیشن کی پر مشتمل ہوتا ہے جو بھیجنے والے کو لفافہ بند کرنے کے لیے درکار ہے؛ base58 میں انکوڈ ہو کر یہ تقریباً 1,667 حروف بنتا ہے۔ یہ لمبائی post-quantum KEM کا براہِ راست نتیجہ ہے۔ ایک منظور شدہ ڈیزائن (مختصر shielded ایڈریسز، 2026-09-17) ایڈریس کی جگہ تقریباً 256 بٹ کا وصول کنندہ شناخت کنندہ لاتا ہے جو ایک قابلِ تجدید ریکارڈ تک پہنچاتا ہے، جس پر spend key سے دستخط ہوتے ہیں اور جسے explorer فراہم کرتا ہے، تاکہ انکیپسولیشن کی کو نقل کرنے کے بجائے حاصل کیا جائے۔

ماخذ: docs/shielded.md §1؛ docs/superpowers/specs/2026-09-17-short-shielded-address.md

11. ہر کی ایک 256-بٹ spend key سے کیوں اخذ کی جاتی ہے؟

تمام دیگر کی مواد ایک واحد راز sk کا قطعی (deterministic) فنکشن ہے: viewing key nk = H(NK, sk)، مالک فیلڈ pk = H(PK, nk)، nullifier H(NF, nk, cm)، outgoing viewing key اور ML-KEM ڈی کیپسولیشن کی، ہر ایک اپنے ڈومین سیپریٹر کے تحت۔ اس لیے کی فائل صرف sk محفوظ کرتی ہے، بیک اپ ایک ہی قدر ہے، اور ٹری کو leaf 0 سے دوبارہ اسکین کرنے سے ہر نوٹ بازیاب ہو جاتا ہے۔ چونکہ بازیابی کے لیے کوئی دوسری کاپی نہیں ہوتی، اس لیے والٹ موجودہ کی فائل کو اوور رائٹ کرنے سے انکار کرتا ہے۔

ماخذ: docs/shielded.md §1

12. مقررہ 4-in-4-out bundle شکل کیوں؟

مقررہ شکل ہر bundle کو ایک ہی حجم اور ساخت کا بنا دیتی ہے چاہے وہ کچھ بھی منتقل کرے۔ ہر bundle ٹھیک چار nullifiers اور چار commitments شائع کرتا ہے؛ غیر استعمال شدہ سلاٹس صفر قدر کے dummy نوٹس ہوتے ہیں، اور change آؤٹ پٹ اس وقت بھی شائع ہوتا ہے جب اس کی قدر صفر ہو، کیونکہ change آؤٹ پٹ کی عدم موجودگی ٹرانزیکشن کو ممتاز کر دیتی۔ اصل تفصیل 2-in-2-out تھی، جو Sapling کی پیروی میں تھی۔ اسے hidden-asset bundle کے ساتھ 4-in-4-out تک وسیع کیا گیا، تاکہ سلاٹس 0–1 نجی اثاثہ اٹھائیں اور سلاٹس 2–3 فیس کے لیے RAND؛ تین کے بجائے چار سلاٹس ٹوکن ٹرانسفر کو اپنی فیس زیادہ سے زیادہ دو RAND نوٹس سے ادا کرنے دیتے ہیں۔

ماخذ: docs/shielded.md §2؛ docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3

13. ایک ہی ثبوت کسی بھی اثاثے (RAND، zUSD، RPL ٹوکنز) کو کیوں منتقل کر دیتا ہے؟

چین 14 سے پہلے، ٹوکن کی منتقلی میں دو بنڈل ہوتے تھے: ایک RAND فیس کے لیے اور ایک اثاثے کے لیے۔ اس کے لیے دو ثبوت درکار تھے اور کسی بھی مشاہدہ کار پر یہ ظاہر ہو جاتا تھا کہ کون سا ٹوکن منتقل ہوا۔ پوشیدہ اثاثے والا گیسٹ اثاثے کے شناخت کنندہ کو نجی ان پٹ کے طور پر لیتا ہے، اس لیے zUSD کی منتقلی RAND کی ادائیگی سے الگ پہچانی نہیں جا سکتی۔ یہ گیسٹ ٹیئر 14 (تقریباً 100 s اور 5.7 GB میموری) میں صرف اس لیے سماتا ہے کہ وہ اپنے ان پٹس کو ایک لوپ میں پڑھتا ہے اور Merkle رکنیت کی جانچ کو اسی میں ضم کر دیتا ہے۔ مکمل طور پر unrolled نفاذ کے لیے ٹیئر 16 (تقریباً 400 s اور 21 GB) درکار ہے، جو 16 GB کی مشین کی میموری سے زیادہ ہے۔

ماخذ: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3

14. فیس عوامی کیوں ہے اور پروپوزر کو کیوں ادا کی جاتی ہے؟

عوامی فیس عوامی اسٹیک رجسٹر سے ہم آہنگ ہے اور داخلے کو سستا بناتی ہے: نوڈ کسی بھی تصدیق سے پہلے فیس کی کم از کم حد جانچ سکتا ہے۔ بنڈل کا ثبوت توازن کی مساوات Σ inputs = Σ outputs + fee + burn نافذ کرتا ہے، اس لیے فیس پوشیدہ نوٹس سے ادا ہوتی ہے اور یہ ظاہر نہیں ہوتا کہ کون سے نوٹس تھے۔ قبول کی گئی قیمت یہ ہے کہ فیس کی مقدار لین دین کی قسم (منتقلی یا پروگرام کال) ظاہر کر سکتی ہے۔

ماخذ: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (rulings table); docs/fees.md §1

15. ڈپازٹس (mint، bridge attest) کی رقم عوامی کیوں ہے؟

پول میں داخل ہونے والی قدر کا حساب عوامی طور پر رکھنا لازم ہے، اور bridge attestation اس بات کا عوامی ثبوت ہے کہ ماخذ چین پر متعلقہ لاک ہوا تھا۔ اس کے نتیجے میں نظر آنے والی معلومات صرف داخلے کے مرحلے تک محدود رہتی ہے، جو Zcash میں شفاف سے شیلڈڈ (t-to-z) لین دین کے مماثل ہے؛ جمع کیے گئے نوٹ کے بعد کے خرچ پوشیدہ رہتے ہیں۔

ماخذ: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (what is public table)

16. میمو 512 بائٹ کا مقررہ فیلڈ کیوں ہے؟

مقررہ لمبائی کا فیلڈ یقینی بناتا ہے کہ لیجر یہ ظاہر نہ کرے کہ میمو موجود ہے یا نہیں اور اس کی لمبائی کیا ہے: میمو کی سہولت والی چین پر نوٹ بنانے والا ہر envelope، بشمول dummies اور change، ٹھیک 1,860 بائٹ کا ہوتا ہے۔ میمو صرف خفیہ کردہ envelope کے اندر رکھا جاتا ہے، نوٹ، commitment یا ثبوت میں کبھی نہیں، اور اسے وہی فریق پڑھ سکتے ہیں جو پہلے ہی نوٹ کو ڈی کرپٹ کر سکتے ہیں۔ بگڑا ہوا میمو خالی میمو کے طور پر ڈی کوڈ کیا جاتا ہے، تاکہ وہ خود نوٹ کو ناقابلِ بازیافت نہ بنا سکے۔

ماخذ: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md

17. پروونگ مقامی کیوں ہے، اور تفویض شدہ پروور اسے کیسے نہیں توڑتا؟

ثبوت خود ہی خرچ کی اجازت ہے: بنڈل میں نہ کوئی دستخط ہوتا ہے اور نہ بھیجنے والے کا فیلڈ، اس لیے اسپینڈ کی کو والیٹ سے باہر جانے کی ضرورت نہیں پڑتی۔ ٹیئر 14 کے بنڈل ثبوت کے لیے تقریباً 5.7 GB میموری درکار ہے، جو فونز اور براؤزرز کی دسترس سے باہر ہے؛ اسی لیے تفویض شدہ پروور موجود ہے۔ تقسیم شدہ اجازت (bundle guest v3، genesis پیرامیٹر hc_auth) دونوں کرداروں کو الگ کرتی ہے: پروور کو صرف ویوئنگ کی nk ملتی ہے اور وہ بنڈل کا ثبوت تیار کرتا ہے، جبکہ والیٹ sk کے ذریعے ایک چھوٹا ٹیئر 10 کا اجازتی ثبوت تیار کرتا ہے۔ یوں پروور بنڈل کا ثبوت تو بنا سکتا ہے مگر خرچ کی اجازت نہیں دے سکتا (سوال 36)۔

ماخذ: docs/prover.md §1; docs/shielded.md (split authorisation); docs/superpowers/specs/2026-09-28-delegated-proving-design.md

18. anchor ونڈو 256 بلاکس کی کیوں ہے؟

ثبوت ایک مخصوص commitment-tree روٹ (اس کے anchor) کے مقابل بنایا جاتا ہے، اور ٹیئر 14 کا بنڈل ثبوت بنانے میں تقریباً 100 s لگتے ہیں۔ اس لیے لیجر کو ایسے anchors قبول کرنے چاہییں جو جمع کرانے کے وقت کئی منٹ پرانے ہوں۔ اصل تصریح میں ونڈو 64 بلاکس کی تھی اور بلاک کا وقفہ کم ہونے پر اسے 256 بلاکس تک وسیع کیا گیا، تاکہ اس کا دورانیہ گھڑی کے وقت میں پروونگ کے وقت سے زیادہ رہے۔

ماخذ: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md

zkVM اور خفیہ کمپیوٹیشن

19. گیسٹ ISA کے طور پر RV32I کیوں (RV64 کیوں نہیں)؟

32 بٹ کا لفظ ٹھیک چار بائٹ لمب میں تقسیم ہو جاتا ہے، اور Goldilocks کا مفرد عدد p = 2^64 − 2^32 + 1 اتنا بڑا ہے کہ دو 32 بٹ قدروں کا حاصلِ ضرب فیلڈ میں کبھی overflow نہیں ہوتا۔ RV64 ALU اور میموری ٹیبلز میں limb کالموں کی تعداد دوگنی کر دیتا۔ RISC-V مرکزی دھارے کے کمپائلرز کا موجودہ ہدف بھی ہے، اس لیے گیسٹ پروگرام عام کمپائل شدہ بائنریز ہوتے ہیں، کسی مخصوص مقصد کے لیے بنائی گئی زبان کے پروگرام نہیں۔

ماخذ: docs/zkvm.md §2; research/docs/01-isa.md (‘Why RV32, not RV64’)

20. 256 بٹ فیلڈ کے بجائے Goldilocks کیوں؟

Goldilocks ایک 64 بٹ مفرد عدد ہے جس کی ریاضی مقامی 64 بٹ CPU ہدایات پر مؤثر طریقے سے نقش ہوتی ہے، اور جس کے ضربی گروپ میں دو کی طاقت والا بڑا ذیلی گروپ موجود ہے، جیسا کہ FRI کا تقاضا ہے۔ 32 بٹ الفاظ کے ساتھ مل کر یہ ہر trace قطار کو تنگ رکھتا ہے، جس سے production-profile پروونگ لیپ ٹاپ پر ممکن ہو جاتی ہے۔ چھوٹے فیلڈ پر کام کرنے سے جو soundness کم ہوتی ہے وہ FRI کے چیلنج توسیعی فیلڈ سے لینے سے بحال ہو جاتی ہے۔

ماخذ: docs/zkvm.md §2; randprotocol.org (performance section)

21. فی-opcode گیس میٹرنگ کے بجائے گیس ٹیئرز کیوں؟

فی-opcode گیس Ethereum میں اس لیے ہے کہ ہر نوڈ ہر لین دین کو دوبارہ چلاتا ہے اور عمل درآمد کی لمبائی پہلے سے محدود نہیں ہوتی۔ Rand میں کوئی نوڈ پروگرام نہیں چلاتا: بھیجنے والا اسے آف چین ایک بار چلاتا ہے، اور نوڈز ایک واحد STARK کی تصدیق کرتے ہیں جس کی تصدیقی لاگت صرف ٹیئر پر منحصر ہے، کیے گئے حساب پر نہیں۔ اختتام ٹیئر کے ذریعے نافذ ہوتا ہے، کیونکہ جو عمل درآمد 2^t cycles کے اندر ختم نہ ہو اس کا ٹیئر t پر کوئی ثبوت ممکن نہیں۔ قیمت کا تعین ایک مقررہ کم از کم حد اور ہیڈر سے محدود گیس کے تخمینے سے ہوتا ہے، اور بلاک کی گنجائش بائٹ بجٹ ہے۔ گیس صرف EVM اور sBPF interpreter گیسٹس کے اندر، نجی اسٹیٹ کے طور پر، ظاہر ہوتی ہے، جہاں ماخذ چین کے معنی دوبارہ پیدا کرنے کے لیے اس کی ضرورت ہے۔

ماخذ: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md

22. trace کو LogUp بسوں سے جڑے نو ٹیبلز میں کیوں تقسیم کیا گیا ہے؟

ایک واحد یک سنگی ٹیبل ہر قطار کو سب سے چوڑے عمل کی چوڑائی تک پیڈ کرتا۔ trace کو نو ٹیبلز میں الگ کرنے سے — CPU، memory، ALU، range، nibble، Poseidon2، program، input اور public — ہر ایک صرف اپنی اونچائی تک پیڈ ہوتا ہے، اور کل trace چھوٹا رہتا ہے۔ LogUp دلائل ٹیبلز کے درمیان multiset تعلقات قائم کرتے ہیں۔ Keccak اور SHA-256 ٹیبلز اختیاری ہیں اور صرف تب شامل ہوتے ہیں جب گیسٹ متعلقہ سسٹم کال استعمال کرے۔

ماخذ: docs/zkvm.md §5

23. پروگرام کال صرف آٹھ آؤٹ پٹ الفاظ کیوں شائع کرتی ہے؟

پروگرام کال اس بات کا ثبوت ہے کہ عوامی کوڈ نجی ان پٹس پر درست طور پر چلایا گیا؛ لیجر صرف رسید درج کرتا ہے۔ آٹھ 32 بٹ الفاظ کسی نتیجے، commitment یا فیصلے کو باندھنے کے لیے کافی ہیں، اور آؤٹ پٹ کا مقررہ سائز یقینی بناتا ہے کہ رسید کی ساخت پروگرام کے بارے میں کچھ ظاہر نہ کرے۔ فی الحال آؤٹ پٹس صرف ڈیٹا ہیں: پروگرام خود قدر منتقل نہیں کر سکتا۔

ماخذ: randprotocol.org/usecases (platform note); docs/confidential.md

24. call-input envelope کیوں ہے؟

جو کالر نجی ان پٹس اپنے پاس رکھتا ہے وہ بعد میں دکھا سکتا ہے کہ کال کس ڈیٹا پر حساب کی گئی تھی۔ call-input envelope اسے پائیدار بناتا ہے: ان پٹس کو خفیہ کر کے کال کے ساتھ محفوظ کیا جاتا ہے، جہاں مقرر کردہ آڈیٹر انہیں ایک کی سے ڈی کرپٹ کر سکتا ہے۔ یہ منتخب افشا — مارکیٹ کے لیے خفیہ، مقرر کردہ ریگولیٹر کے لیے کھلا — کو ادائیگیوں سے پروگرام کے عمل درآمد تک وسعت دیتا ہے۔

ماخذ: docs/confidential.md (‘Call input envelopes’)

25. constraint-set کی تبدیلی hard fork کیوں ہے؟

ہر نوڈ ہم آہنگی (synchronisation) کے دوران ہر ثبوت کی دوبارہ تصدیق کرتا ہے، اور ثبوت صرف اسی constraint set (AIR) کے لحاظ سے درست ہوتا ہے جس کے تحت وہ بنایا گیا۔ لہٰذا AIR میں تبدیلی درست چینز کے مجموعے کو بدل دیتی ہے، اور اسے genesis cut پر متعارف کرایا جاتا ہے، نوڈ بہ نوڈ اپنایا نہیں جاتا۔

ماخذ: docs/architecture.md (‘Why a constraint-set change is a hard fork’)

26. حوالہ emulator کیوں ہے، AIR کیوں نہیں؟

emulator مشین کی پڑھنے کے قابل تصریح ہے اور AIR اس تصریح کی کثیر رکنی پابندیوں کی صورت میں انکوڈنگ ہے۔ جہاں دونوں میں اختلاف ہو، تعریف کے لحاظ سے AIR غلطی پر ہے۔ یوں معیاری تعریف اس artefact میں رہتی ہے جس کا انسانوں کے لیے آڈٹ کرنا سب سے عملی ہے۔

ماخذ: docs/zkvm.md §5

اتفاقِ رائے اور نوڈ

27. chained HotStuff BFT کیوں؟

Chained HotStuff قطعی finality فراہم کرتا ہے: دو تہائی سے زیادہ اسٹیک-وزنی quorums کے ساتھ، بلاک اس وقت حتمی ہو جاتا ہے جب اس کے اوپر لگاتار تین quorum سرٹیفکیٹ بن جائیں، اور حتمی بلاک کی کبھی تنظیمِ نو نہیں ہوتی۔ ناپا گیا بلاک وقفہ 1.2 s اور finality تک کا وقت تقریباً 3.6 s ہے۔ مطلوبہ ادارہ جاتی صارفین کو ایسی settlement finality درکار ہے جس کے مقابل وہ اندراجات کر سکیں، جو احتمالی finality والی چین فراہم نہیں کرتی۔

ماخذ: fullnode README; randprotocol.org (performance section); docs/architecture.md §6

28. ثبوت کی تصدیق consensus لوپ سے باہر کیوں ہے؟

نوڈ ہر STARK کی تصدیق اسی وقت کرتا ہے جب وہ لین دین کو داخل کرتا ہے (warm حالت میں تقریباً 32 ms)، آگے بھیجنے سے پہلے، اس لیے تصدیق بلاک تجویز کرنے کے critical path پر کبھی نہیں آتی۔ لہٰذا بلاک کا وقفہ ثبوت کے سائز سے نہیں بلکہ consensus کی latency سے طے ہوتا ہے۔ جانچیں لاگت کی ترتیب سے رکھی گئی ہیں اور STARK کی تصدیق سب سے آخر میں ہوتی ہے، تاکہ بگڑا ہوا لین دین سب سے مہنگے مرحلے سے پہلے مسترد ہو جائے۔

ماخذ: randprotocol.org; docs/architecture.md (‘How it works’)

29. باقی سب کچھ شیلڈڈ ہونے کے باوجود ویلیڈیٹر رجسٹر عوامی کیوں ہے؟

تمام replicas کو اس پر متفق ہونا لازم ہے کہ کون سے ویلیڈیٹرز تجویز کر سکتے ہیں اور کون سے ووٹ quorum بناتے ہیں، جس کے لیے اسٹیک کے وزن کا عوامی ہونا ضروری ہے۔ اس لیے رجسٹر میں اسٹیک کی مقداریں واضح صورت میں درج ہیں۔ ملکیت سے تعلق پوشیدہ رہتا ہے: بانڈ شیلڈڈ نوٹ سے فنڈ ہوتا ہے اور نکلوانے کی رقم کسی نوٹ میں ادا ہوتی ہے، اور کوئی بھی عمل یہ ظاہر نہیں کرتا کہ وہ نوٹ کس کا ہے۔

ماخذ: docs/staking.md §1

30۔ سنکنگ نوڈ سرٹیفکیٹس پر بھروسا کرنے کے بجائے ہر بلاک کو دوبارہ کیوں چلاتا ہے؟

دیر سے شامل ہونے والا نوڈ چین کو قبول کرنے سے پہلے ہر کورم سرٹیفکیٹ کی تصدیق کرتا ہے، ہر بنڈل اور کال پروف کی دوبارہ تصدیق کرتا ہے، اور حاصل شدہ رسیدوں کا موازنہ کرتا ہے۔ چونکہ درستی محض دستخطوں سے نہیں بلکہ پروفز سے قائم ہوتی ہے، اس لیے یہ طریقۂ کار ان لانگ رینج حملوں کا شکار نہیں ہوتا جو صرف دستخطوں پر قائم چینز کو متاثر کرتے ہیں۔ تاریخ سے پروفز کو ہٹانے کی تجویز مسترد کر دی گئی، کیونکہ اس سے یہ ضمانت ختم ہو جاتی۔

ماخذ: docs/architecture.md؛ docs/aggregation.md (تعارف)

31۔ پروف 1 MB سے بڑا ہونے کے باوجود بلاک کی حد 4 MiB کیوں رکھی گئی ہے؟

حد مقرر ہونے کی صورت میں بلاک کا حجم بڑھ نہیں سکتا؛ جب طلب گنجائش سے بڑھ جاتی ہے تو اس کے بجائے تھرو پٹ محدود ہو جاتا ہے (80-query پروفائل کے تحت فی بلاک تین شیلڈڈ ٹرانسفرز تک)۔ تھرو پٹ کی حد کو بلاک کے غیر محدود پھیلاؤ کے مقابلے میں زیادہ محفوظ ناکامی کی صورت سمجھا گیا۔ منتخب کردہ حل بلاک سطح کی ایگریگیشن ہے، یعنی ہر بلاک کے لیے ایک ریکرسیو پروف، نہ کہ حد بڑھانا یا سیکیورٹی کی سطح گھٹانا۔

ماخذ: docs/block-space.md §1، §6

32۔ testnet تاریخ کو ایک دن تک کیوں چھانٹتا ہے؟

18 Dilithium2 دستخطوں والا کورم سرٹیفکیٹ تقریباً 44 KB کا ہوتا ہے اور ہر بلاک میں دو بار محفوظ کیا جاتا ہے۔ ہر 1.4 s پر زیادہ تر خالی بلاکس کے ساتھ یہ فی نوڈ روزانہ تقریباً 6.6 GB بنتا تھا؛ نوڈز کی ڈسکیں بھر گئیں، اور چین نے بلندی 248,953 پر کورم کھو دیا۔ اب testnet کے فل نوڈز ایک دن کی تاریخ رکھتے ہیں، ایک واحد آرکائیو نوڈ پوری تاریخ رکھتا ہے، اور mainnet کے نوڈز پوری تاریخ رکھیں گے۔ لیجر کی حالت — ٹری، نلیفائر سیٹ، رجسٹر اور پروگرامز — کبھی نہیں چھانٹی جاتی۔

ماخذ: docs/superpowers/specs/2026-09-24-history-pruning-design.md

33۔ libp2p کیوں؟

نوڈ Noise اور Yamux کے ساتھ TCP، ٹرانزیکشنز اور ووٹس کے لیے gossipsub، پیئر دریافت کے لیے بوٹ اسٹرپ فہرست کے ساتھ Kademlia، مقامی نیٹ ورکس پر mDNS، اور بلاک سنکرونائزیشن کے لیے request-response استعمال کرتا ہے۔ یہ معیاری اور وسیع پیمانے پر استعمال ہونے والے اجزا ہیں، اس لیے نوڈ اپنی عملدرآمدیں برقرار رکھنے کے بجائے پیئر اسکورنگ، دوبارہ رابطہ اور ٹرانسپورٹ اپ گریڈز وراثت میں پاتا ہے۔

ماخذ: fullnode README (networking row)

پروونگ مارکیٹ اور ایگریگیشن

34۔ بلاک سطح کی پروف ایگریگیشن کیوں؟

اگر ہر بنڈل اپنا تقریباً 1.3 MB کا پروف لے کر آئے تو بلاک کی جگہ بنڈلز کی تعداد کے ساتھ خطی طور پر بڑھتی ہے۔ ہر بلاک کے لیے ایک واحد ریکرسیو STARK، جو تمام N بنڈل پروفز کی تصدیق کرتا ہے، آن چین پروف کی لاگت کو N سے آزاد رکھتا ہے۔ اس کے بعد ویلیڈیٹرز CPU پر ایک ہی ایگریگیٹ پروف (گرم حالت میں تقریباً 16 ms) کی تصدیق کرتے ہیں، چنانچہ عام ہارڈویئر پر بھی توثیق ممکن رہتی ہے، جبکہ GPU رکھنے والے ایگریگیٹرز فیس کے پروونگ حصے اور بلاک سبسڈی کے لیے ایک الگ، اجازت کے بغیر مارکیٹ میں مقابلہ کرتے ہیں۔

ماخذ: docs/aggregation.md §1

35۔ تین کردار کیوں — ویلیڈیٹر، ایگریگیٹر، تفویض کردہ پروور؟

تینوں کرداروں کے ہارڈویئر تقاضے مختلف ہیں اور انہیں مختلف فریق ادائیگی کرتے ہیں۔ ویلیڈیٹر CPU پر ٹرانزیکشنز کو ترتیب دیتا اور ان کی تصدیق کرتا ہے اور اسے فیس کے تصدیقی حصے سے ادائیگی ہوتی ہے۔ ایگریگیٹر GPU پر ریکرسیو بلاک پروف تیار کرتا ہے اور اسے پروونگ حصے اور سبسڈی سے ادائیگی ہوتی ہے۔ تفویض کردہ پروور اس بھیجنے والے کے لیے ایک واحد بنڈل پروف تیار کرتا ہے جس کا آلہ (فون یا براؤزر) ایسا نہیں کر سکتا، اور اسے وہی بھیجنے والا نجی طور پر ادائیگی کرتا ہے۔ کرداروں کی یہ علیحدگی توثیق کو سستا رکھتی ہے اور پروونگ کو مسابقتی بناتی ہے۔

ماخذ: docs/prover.md §1

36۔ تفویض کردہ پروور فنڈز کیوں نہیں چرا سکتا؟

تقسیم شدہ اجازت کاری (split authorisation) کے تحت پروور کو ویونگ کی nk ملتی ہے مگر خرچ کی کی sk نہیں ملتی۔ بنڈل پروف c = H(AUTH, nk || salt) کا عہد کرتا ہے، اور والٹ کا الگ اجازت کاری پروف اسی c کے لیے sk کی واقفیت ثابت کرتا ہے۔ sk کے بغیر پروور بنڈل پروف تو بنا سکتا ہے مگر درست اجازت کاری پیش نہیں کر سکتا، اور والٹ واپس آنے والے پروف کو جمع کرانے سے پہلے اس کی تصدیق کرتا ہے۔

ماخذ: docs/shielded.md (split authorisation)؛ docs/prover.md §8

برج اور zUSD

37۔ نیا اسٹیبل کوائن جاری کرنے کے بجائے USDT/USDC کو ان کی اپنی چینز پر کیوں لاک کیا جاتا ہے؟

Rand پر مقامی اجرا ریزرو کی گنجائش کو جاری کنندگان کے تعیناتی فیصلوں پر منحصر کر دیتا، جو منصوبے کے اختیار سے باہر ہیں۔ Ethereum، BSC، Tron اور Solana پر USDT اور USDC کو لاک کرنے سے ریزرو ان چینز سے حاصل ہوتے ہیں جن پر یہ اثاثے پہلے سے گردش میں ہیں، اور کوئی نیا جاری کنندہ متعارف نہیں ہوتا: zUSD کی ہر اکائی ایک عوامی طور پر قابلِ مطالعہ کسٹڈی کنٹریکٹ میں رکھے گئے USDT یا USDC پر دعویٰ ہے۔

ماخذ: randprotocol.org (reserve section)

38۔ t-of-n گارڈین سیٹ کیوں، اور اسے صاف الفاظ میں کیوں بیان کیا جاتا ہے؟

تصدیق نامہ (attestation) Rand کے پاس اس بات کا واحد ثبوت ہے کہ کسی دوسری چین پر لاک ہوا، اس لیے اس پر حد (threshold) رکھنے والے گروہ کے دستخط لازم ہیں؛ درست تصدیق نامے کے لیے گارڈینز کے دو تہائی سے زیادہ کے دستخط درکار ہوتے ہیں۔ نتیجتاً پیدا ہونے والا اعتماد کا مفروضہ واضح طور پر بیان کیا گیا ہے۔ مؤثر ضمانت ریزرو کی شرحِ ادائیگی اور برج کی سالمیت میں سے کمزور تر کے برابر ہے؛ t گارڈینز کا اتحاد متعلقہ لاک کے بغیر منٹنگ کی اجازت دے سکتا ہے؛ اور خطرہ ہر چین پر رکھی گئی کسٹڈی سے محدود ہے۔ یہ مفروضہ اصل میں برج نہ بنانے کی دلیل تھا۔ اسے واپس نہیں لیا گیا بلکہ ریزرو کی گنجائش کے بدلے قبول کیا گیا ہے۔

ماخذ: randprotocol.org (reserve section, ‘What this costs’)

39۔ ECDSA تصدیق نامے کے ساتھ Dilithium2 کا شریکِ دستخط کیوں؟

ماخذ چینز میں لیٹس پر مبنی دستخطوں کا کوئی verifier موجود نہیں، اس لیے ان چینز پر ریلیزز کلاسیکی ECDSA ہی سے محفوظ رہتی ہیں، اور خطرہ کسٹڈی اور حدود سے محدود رہتا ہے۔ گارڈینز کی طرف سے Rand لیجر جو بھی پیغام قبول کرتا ہے — ڈپازٹس اور گارڈین سیٹ کی تبدیلیاں — اس پر انہی گارڈینز کے Dilithium2 دستخطوں کا کورم بھی لازماً ہونا چاہیے۔ اس طرح منٹ کا راستہ پوسٹ کوانٹم ہے، خواہ بیرونی سرے نہ ہوں۔ شریکِ دستخط تصدیق نامے کے ساتھ منتقل ہوتے ہیں اور تعینات شدہ کنٹریکٹس میں کسی تبدیلی کی ضرورت نہیں پڑتی۔

ماخذ: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1

40۔ ڈپازٹ نوٹ کا blinding منتخب کرنے کے بجائے اخذ کیوں کیا جاتا ہے؟

پہلے ڈپازٹ نوٹ کا کمٹمنٹ اس وقت تک طے نہیں ہوتا تھا جب تک کوئی ریلیئر تصدیق نامہ جمع نہ کرا دے، اس لیے دو ریلیئرز ایک ہی تصدیق نامہ مختلف نوٹس کے ساتھ جمع کرا سکتے تھے۔ blinding فیکٹر r کو تصدیق نامے سے متعین طور پر اخذ کرنے سے کمٹمنٹ طے ہو جاتا ہے، چنانچہ مسابقتی جمع کرائیاں ایک ہی کمٹمنٹ پر ٹکراتی ہیں اور ڈپازٹ دو بار منٹ نہیں ہو سکتا۔

ماخذ: docs/bridge.md (F1, chain 14)

41۔ Tron پر لاک شدہ USDT، Ethereum پر USDT کی صورت میں کیوں نکل سکتا ہے؟

zUSD قابلِ تبادلہ ہے: ہر اکائی مجموعی ریزرو پر دعویٰ ہے، اس چین پر نہیں جس کے ذریعے وہ داخل ہوئی۔ داخلے اور اخراج کو الگ کرنے سے لیکویڈیٹی وہاں منتقل ہو سکتی ہے جہاں اس کی طلب ہے، بشرطیکہ منزل کی چین کے پاس کافی ریزرو ہوں۔ اسٹیبل کوائن پیپر ثابت کرتا ہے کہ مستقل شرط S ≤ Σ_c R_c، یعنی کل سپلائی کا فی چین ریزروز کے مجموعے سے محدود ہونا، ہر حالتی تبدیلی کے ساتھ برقرار رہتی ہے۔

ماخذ: randprotocol.org (reserve section)

42۔ شیلڈنگ تقسیم کو کیوں چھپاتی ہے مگر مقدار کو نہیں؟

zUSD کی کل سپلائی ٹوکن رجسٹر میں عوامی ہے اور ہر چین کا ریزرو ایک عوامی بیلنس ہے، اس لیے ادائیگی کی صلاحیت کی تصدیق کوئی بھی کر سکتا ہے؛ جو چھپایا جاتا ہے وہ مالکان کے درمیان ہولڈنگز کی تقسیم ہے۔ ایک حد لاگو ہوتی ہے: چاروں ریزرو بیلنسز کو کسی ایک لمحے میں بیک وقت نہیں دیکھا جا سکتا، اس لیے ان چینز کے لیے یہ جانچ ناداری کو روکنے کے بجائے بعد میں اس کا پتا لگاتی ہے۔

ماخذ: randprotocol.org (reserve section)

43۔ برن ہی وہ واحد ٹرانزیکشن کیوں ہے جو اپنے اثاثے کا نام لیتی ہے؟

برن کسی مخصوص چین پر کسی مخصوص اثاثے کو جاری کرتا ہے، اس لیے کسٹڈی کنٹریکٹ کو معلوم ہونا چاہیے کہ کون سا اثاثہ اور کون سی چین۔ باقی ہر ٹرانزیکشن ایک غیر شناخت شدہ اثاثہ منتقل کرتی ہے۔ برن برج فیس بھی ساتھ لے کر چلتا ہے، کیونکہ یہ برج کی واحد ٹرانزیکشن ہے جس کا بھیجنے والا ہی مستفید ہوتا ہے۔

ماخذ: docs/architecture.md؛ docs/shielded.md §2

تعمیل اور افشا

44۔ ویونگ کیز کیوں، ‘سب سے نجی’ کیوں نہیں؟

ریگولیٹرز نے ایسے پرائیویسی نظام قبول نہیں کیے جن میں افشا کا انحصار زیرِ تفتیش فریق کے تعاون پر ہو، جیسا کہ Tornado Cash کا معاملہ ظاہر کرتا ہے۔ اس لیے Rand افشا کو پروٹوکول کا ایک جزو سمجھتا ہے۔ حامل، یا کوئی ریگولیٹڈ ثالث، ویونگ کی اپنے پاس رکھتا ہے؛ آڈیٹر قانونی درخواست میں مذکور ٹرانزیکشنز کو ڈیکرپٹ کر سکتا ہے؛ اور ڈیزائن کا ہدف محدود دائرے کی کیز ہیں جو تجارتی حکمتِ عملی ظاہر کیے بغیر فریقِ مقابل اور رقم ظاہر کریں۔ پے رول جیسی ایپلیکیشنز کے لیے یہ آڈٹ پذیری حد نہیں بلکہ ایک لازمی تقاضا ہے۔

ماخذ: randprotocol.org/usecases (regulation section; payroll case)

45۔ سبکدوش ہونے والی ویونگ کی آنے والی کی سے الگ کیوں ہے؟

علیحدگی بھیجنے والے کو یہ ثابت کرنے دیتی ہے کہ اس نے کیا ادا کیا، بغیر وصول کنندہ کی تاریخ تک رسائی حاصل کیے، اور اس کا الٹ بھی۔ سبکدوش ہونے والی ویونگ کی ovk وہ لفافے ڈیکرپٹ کرتی ہے جو والٹ نے بھیجے ہیں؛ ML-KEM ڈی کیپسولیشن کی اس کی طرف بھیجے گئے لفافے ڈیکرپٹ کرتی ہے؛ اور فی ٹرانزیکشن کی کسی تیسرے فریق پر ٹھیک ایک آؤٹ پٹ ظاہر کرتی ہے۔

ماخذ: docs/shielded.md §1–2

معلوم حدود

46۔ پروفز آج کیا افشا کرتے ہیں، اور اسے دستاویزی شکل میں کیوں رکھا گیا ہے؟

27-09-2026 کے جائزے میں معلوم ہوا کہ v1 گیسٹ (چینز 14–15) کے تحت ہر بنڈل پروف یہ ظاہر کرتا ہے کہ کن ان پٹ سلاٹس میں حقیقی نوٹس ہیں اور ہر خرچ شدہ لیف انڈیکس کا Hamming weight کیا ہے۔ اس کی وجہ دوہری ہے: فی ٹیبل LogUp ٹوٹلز بغیر blinding کے شائع ہوتے ہیں، اور گیسٹ کا کنٹرول فلو اس پر شاخ بناتا ہے کہ کوئی ان پٹ ڈمی ہے یا نہیں۔ حل ایک بغیر شاخ والا گیسٹ (v2) ہے، جو اگلے genesis پر منتخب کیا جائے گا۔ یہ نتیجہ اس لیے شائع کیا گیا ہے کہ نیٹ ورک testnet ہے اور دستاویزات اس کے آڈٹ ریکارڈ کا کام دیتی ہیں۔

ماخذ: docs/shielded.md (‘What the proofs leak today’)

47۔ ریاست کی افزائش کی قیمت کم کیوں لگائی گئی ہے؟

Ethereum اسٹوریج رائٹس کی قیمت مقرر کرتا ہے، کیونکہ محفوظ شدہ state ہر node پر ایک مستقل بوجھ ڈالتی ہے۔ Rand اس وقت commitment tree، nullifier set اور program storage کی نمو کی قیمت صرف فی لفظ deployment fee اور مقررہ bundle fee کے ذریعے طے کرتا ہے۔ testnet کے لیے یہ کافی ہے، لیکن اسے ایک کھلے قیمت بندی کے سوال کے طور پر درج کیا گیا ہے جسے mainnet سے پہلے حل کیا جانا ہے؛ اس کے حل کے لیے فی opcode میٹرنگ درکار نہیں۔

ماخذ: docs/fees.md §3 (caveats)

48. اب تک کوئی آزاد آڈٹ مکمل کیوں نہیں ہوا؟

پروٹوکول ایک ایسے testnet پر فعال ترقی کے مرحلے میں ہے جسے ٹیم چلا رہی ہے، اور ڈیزائن کے مستحکم ہونے سے پہلے مزید constraint sets اور chain cuts متوقع ہیں۔ ویب سائٹ ہر صفحے پر یہ بات بیان کرتی ہے۔ اندرونی آڈٹ کے مراحل (v3–v5) docs/consensus.md اور ڈیزائن کی وضاحتوں میں شائع کیے گئے ہیں، تاکہ حتمی بیرونی آڈٹ کے لیے ایک مکمل ریکارڈ دستیاب ہو۔

ماخذ: randprotocol.org (footer); docs/consensus.md