د ډیزاین پوښتنې او ځوابونه

دا مخ د Rand د هر لوی طراحي پرېکړې دلیل ثبتوي: هغه ځانګړنه چې یو برخه یې باید وړاندې کړي، هغه انګیرنه چې ورسره دا ځانګړنه وړاندې کوي، او هغه لګښت چې په بدل کې منل شوی دی. دا مخ د 2026 کال د سپتمبر په 29 نېټه له دې وېبپاڼې، د whitepaper له لنډيز، او له مرجع بشپړ نوډ (github.com/randprotocol/fullnode: README، docs/ او docs/superpowers/specs/) څخه ترتیب شوی دی. هر ځواب هغه سند را اخلي چې دلیل پکې بیان شوی دی؛ لارې د fullnode ذخیرې ته اشاره کوي، مګر هغه چې په randprotocol.org پیل کېږي.

وضعیت. Rand په یوه testnet چلېږي چې د بنسټ‌ایښودونکې ډلې لخوا اداره کېږي، او پروتوکول په خپلواک ډول نه دی پلټل شوی. لاندې څو پرېکړې د chain په بېلابېلو پرېکونو کې په پړاوونو پلې کېږي. ټول شمېرې د ترتیب په وخت د چلېدونکي نوډ اندازې دي؛ تمه کېږي چې بدلې شي، او د حواله کولو دمخه باید بیا اندازه شي.

کریپټوګرافیک ابتدايي برخې

1. د نوټ د ړنګولو لپاره ولې ML-KEM-768 (Kyber)؟

د یوې نوټ plaintext د هغې اخیستونکي ته په یوه کڅوړه کې کوډ کېږي چې په عامه کتاب (ledger) کې تل پاتې کېږي. نو د دې محرمیت یوه نه‌بدلېدونکې ځانګړنه ده (8 پوښتنه): هغه مخالف چې په هر وروستي وخت کې د کریپټوګرافي له پلوه اړوند کوانټم کمپيوټر ترلاسه کړي، کولای شي هره تاریخي کڅوړه خلاصه کړي چې د elliptic-curve KEM لاندې تړل شوې وي، ځکه چې د Shor الګوریتم discrete logarithm په polynomial وخت کې حلوي. ML-KEM د NIST FIPS 203 کې معیاري شوی دی او امنیت یې په Module-LWE کې راټیټېږي، چې د هغې لپاره هېڅ اغېزمن کوانټمي الګوریتم نه دی پېژندل شوی. د 768 پارامتر ټولګه (د NIST کټګوري 3) د امنیتي حاشیې او د 1,184-بایټه encapsulation کیلي ترمنځ د تعادل په توګه غوره شوه، چې هر پته باید یې له ځان سره ولري. کڅوړه ML-KEM-768 او ChaCha20-Poly1305 سره یو ځای ده: 1,348 بایټه، یا د ټاکلې memo ساحې سره 1,860 بایټه.

سرچینه: randprotocol.org (د post-quantum برخه)؛ fullnode README؛ docs/shielded.md §2

2. ولې د Pedersen پر ځای Poseidon2 commitments؟

Pedersen commitments په بشپړ ډول پټوونکي دي، خو یوازې په محاسبوي ډول پابند دي، او پابندي یې د discrete-logarithm په انګیرنه راټیټېږي، چې کوانټمي مخالف یې ماتوي؛ هغه مخالف چې discrete logarithms محاسبه کولای شي، کولای شي یو commitment په بلې ارزښت ته خلاص کړي. ځکه چې نن خپور شوی commitment باید د ledger د ټول ژوند لپاره سالم او پټوونکی پاتې شي، سکیم باید په هغو انګیرنو ولاړ وي چې باور کېږي د کوانټمي مخالفانو پر وړاندې دوام کوي، چې په عمل کې د hash فنکشن معنا لري. Poseidon2 د Goldilocks ساحې پر سر تعریف شوی د ریاضي‌کوډ‌کولو‌پر‌بنسټ hash دی، نو په STARK کې یې ارزونه لږ محدودیتونه لګوي. همدا hash د نوټ commitment، د depth-32 Merkle ونې او nullifier جوړوي.

سرچینه: randprotocol.org (د post-quantum برخه)؛ docs/shielded.md §1–2

3. ولې دوه hash فنکشنونه — BLAKE3 او Poseidon2؟

دا دوه فنکشنونه د لګښت د بېلابېلو ماډلونو لپاره غوره شوي دي. Poseidon2 هلته کارول کېږي چېرې چې hash باید په یوه ثبوت کې ارزول شي — نوټونه، د commitment ونه، nullifiers او د zkVM داخلي جدولونه — ځکه چې لګښت یې په محدودیتونو اندازه کېږي. BLAKE3 هلته کارول کېږي چېرې چې هېڅ ثبوت نه وي او اصلي توان پر لوړ حالت دی: د بلاک hashes، پر ونې، د nullifier ټولګې، د validator ثبت او د پروګرام جدول د state root، او د validator پتې (د عامې کیلي BLAKE3 digest). Poseidon2 په CPU کې نسبتاً ورو دی؛ BLAKE3 د ریاضي‌کوډ‌کولو لپاره نسبتاً ګران دی. هر یو یوازې هلته کارول کېږي چېرې چې د هغه د لګښت ماډل پلي کېږي.

سرچینه: fullnode README (د signatures / hashes کتار)؛ docs/architecture.md

4. د validator لاسلیکونو لپاره ولې Dilithium2 (ML-DSA)؟

د اجماع لاسلیکونه یوه نوې کېدونکې ځانګړنه وړاندې کوي (8 پوښتنه): د سکیم وروسته ماتېدل د راتلونکو پیغامونو جعل ته اجازه ورکوي، خو هغه بلاکونه چې دمخه وروستي شوي، شاته نه باطلوي، نو سکیم کېدای شي د کوانټمي مخالف له شتون دمخه بدل شي. بیا هم یو lattice سکیم له پیدايښت (genesis) راهیسې غوره شو، ترڅو د اجماع رایې، د bridge ساتونکو ګډ لاسلیکونه او د validator ثبت یو واحد post-quantum کیلي ډول شریک کړي. نوډ د دریم پړاو Dilithium2 پارامتر ټولګه پلي کوي (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)؟

دا انتخاب له درې اړتیاوو څخه راځي. لومړی، هېڅ باوري تنظیم نشته: سالمیت یوازې د hash فنکشن په ټکر‌مقاومت ولاړ دی، نه په جوړښتي حوالې تار یا pairing‑دوستانه منحني. دوهم، د post-quantum احتمالي سالمیت: دلیل هېڅ discrete-logarithm یا pairing انګیرنه نه کوي. دریم، د 2 پوښتنې د hash‑پر‑بنسټ 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‑پوښتنې FRI پروفایل؟

د تولید پروفایل (80 پوښتنې، blowup factor 8، د proof-of-work grinding 20 بټونه) نږدې 86 بټه ثابت‌شوی سالمیت وړاندې کوي، د 27‑پوښتنې پروفایل د نږدې 42 بټونو پر وړاندې، د ثبوت اندازې 2.75 چنده سره. د تصدیق وخت نږدې بدلون نه کوي: 809 ms چې په سړو حالت کې 838 ms ته ختلی، او په ګرم حالت کې نږدې 16 ms. ثابت‌شوی سالمیت د ثبوت پر اندازې لومړیتوب ترلاسه کړ، او د اندازې لګښت د block‑space او aggregation طرحې ته لیږدول شو.

سرچینه: docs/block-space.md §1، §3

7. ولې د post-quantum ادعا د هر ابتدايي برخې په توګه بیانېږي، نه د ‘پروتوکول‑پراخ 128‑بټ’ په توګه؟

پخوانیو مسودو د ټول پروتوکول لپاره 128‑بټ post-quantum امنیت ادعا کوله. دا ادعا د Brassard–Høyer–Tapp له حد سره ناسمه ده، چې له مخې یې کوانټمي مخالف په 256‑بټ hash کې ټکرونه نږدې په 2^85 پوښتنو کې موندلای شي، نو دا ادعا له مخې پرته له شرطه ایستل شوه. مقاله اوس امنیت د هر ابتدايي برخې او د هر رول لپاره بیانوي — د 384‑بټ transcript hash، 256‑بټ hashes چې یوازې هلته کارول کېږي چېرې چې د preimage مقاومت اړین وي، Dilithium2، ML-KEM-768، او د توسعې ساحې پر سر FRI — د Module-LWE او Module-SIS انګیرنو لاندې، پداسې حال کې چې hash فنکشنونه د کوانټمي تصادفي oracles په توګه ماډل شوي. د نوډ transcript hash اوس مهال Poseidon2 دی؛ اسناد دا د ترتیب د یوې پرانیستې تشې په توګه لیست کوي.

سرچینه: randprotocol.org (د post-quantum برخه)

8. ‘نه‌بدلېدونکی د نوې کېدونکي پر وړاندې’ طبقه‌بندي څه ده او ولې انتخابونه ټاکي؟

یوه امنیتي ځانګړنه نه‌بدلېدونکې ده که هغه مخالف چې په هر راتلونکي وخت کې نوې وړتیا ترلاسه کړي، کولای شي د هغو معلوماتو لپاره چې دمخه خپاره شوي دي، شاته یې خرابه کړي؛ د نوټ محرمیت او د commitment پټوالی د همدې ډول دي، نو باید د خپرېدو په وخت کې د کوانټم‑مقاوم وي. یوه ځانګړنه نوې کېدونکې ده که هغه په هر کارونې کې بیا جوړېږي، ترڅو سکیم د ګواښ له رامنځته کېدو دمخه بدل شي؛ لاسلیکونه او د ثبوت سالمیت د همدې ډول دي. په دې برخه کې هر ابتدايي برخې انتخاب د هغې ځانګړنې له طبقه‌بندۍ څخه راځي چې ساتي یې.

سرچینه: randprotocol.org (د post-quantum برخه)

شیلډ شوی pool

9. ولې د نوټ/UTXO ماډل چې حسابونه یا بیلانسونه نه لري؟

حساب‑پر‑بنسټ ledger د جوړښت له مخې بیلانسونه خپروي؛ پټولو یې state کوډ‌کولو او پر ciphertexts د بیاناتو ثبوت ته اړتیا لري، چې خورا ګران دی. د نوټ pool یوازې commitments او nullifiers ساتي، چې هېڅ یو مالک یا مقدار نه افشا کوي، نو عامه state هېڅ د بیلانس معلومات نه لري. یوازینی استثنا د validator ثبت دی، چې د stake وزنونه یې باید عامه وي ترڅو replicas د quorum په غړیتوب موافق شي (29 پوښتنه).

سرچینه: docs/shielded.md §1–2؛ docs/staking.md §1

10. ولې پته ~1.6 KB ده؟

یوه shielded پته د 32‑بایټه مالک ساحې pk او د 1,184‑بایټه ML-KEM-768 encapsulation کیلي څخه جوړه ده چې لیږونکي ته د کڅوړې د تړلو لپاره اړینه ده؛ د base58 په کوډ کې، دا نږدې 1,667 توري دي. اوږدوالی د post-quantum KEM مستقیم پایله ده. یوه تصویب شوې طرح (لنډې shielded پتې، 2026-09-17) پته د نږدې 256 بټو د اخیستونکي پېژندګلوي سره بدلوي چې یو نوي‌کېدونکي ریکارډ ته حل کېږي، د spend کیلي سره لاسلیک شوی او د explorer لخوا وړاندې شوی، ترڅو encapsulation کیلي راوړل شي، نه لیکل.

سرچینه: docs/shielded.md §1؛ docs/superpowers/specs/2026-09-17-short-shielded-address.md

11. ولې هره کیلي له یوې 256‑بټ spend کیلي څخه ترلاسه کېږي؟

نور ټول کیلي مواد د یوه واحد پټ sk ټاکونکی فنکشن دی: viewing کیلي nk = H(NK, sk)، مالک ساحه pk = H(PK, nk)، nullifier H(NF, nk, cm)، د وتلو viewing کیلي او د ML-KEM decapsulation کیلي، هر یو د خپل ډومین جلا‌کوونکي لاندې. نو د کیلي فایل یوازې sk ساتي، بیک‌اپ یوازې یو ارزښت دی، او د ونې له 0 پاڼې بیا سکین کول هره نوټ بیرته ترلاسه کوي. ځکه چې د بیرته ترلاسه کولو لپاره دویمه نسخه نشته، والیټ د موجود کیلي فایل د پر‌لیکلو څخه ډډه کوي.

سرچینه: docs/shielded.md §1

12. ولې د 4‑in‑4‑out ټاکلې bundle بڼه؟

ټاکلې بڼه هره bundle په اندازه او جوړښت کې یو شان کوي، که هر څه لېږدوي. هره bundle دقیقاً څلور nullifiers او څلور commitments خپروي؛ ناکارېدلې خالي ځایونه صفر‑ارزښت dummy نوټونه دي، او د بدلون خروجي حتی هغه وخت خپرېږي چې ارزښت یې صفر وي، ځکه چې د بدلون د خروجي نشتون به معامله توپیر کړي. اصلي مشخصات 2‑in‑2‑out وو، د Sapling پیروي. دا د پټ‑شتمنۍ 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 توکنونه) لېږدوي؟

د chain 14 څخه مخکې، د ټوکن یو لیږد دوه بنډلونه درلودل، یو د RAND فیس لپاره او بل د شتمنۍ لپاره. دې کار دوه ثبوتونه غوښتل او هر لیدونکي ته یې څرګنده کوله چې کوم ټوکن لیږدول شوی دی. د پټې شتمنۍ guest د شتمنۍ پېژندونکی د خصوصي ورودي په توګه اخلي، نو د zUSD لیږد د RAND له تادیې څخه د توپیر وړ نه دی. دا guest یوازې په 14 پوړ (نږدې 100 s او 5.7 GB حافظه) کې ځای کېږي، ځکه چې خپلې ورودي په یوه کړۍ کې لولي او د Merkle د غړیتوب تحقیق ورسره یوځای کوي؛ بشپړ پرانیستل شوې پلي کول 16 پوړ (نږدې 400 s او 21 GB) غواړي، چې د 16 GB ماشین له حافظې څخه ډېر دی.

سرچینه: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3

14. ولې فیس عام دی او وړاندیزوونکي ته تادیه کېږي؟

عام فیس د عامې ونډې له ثبت سره سمون لري او داخلېدل ارزانه کوي: یو نوډ کولی شي د هر ډول تصدیق له سرته رسولو مخکې د فیس ټیټه کچه وڅاري. د بنډل ثبوت د انډول معادله Σ ورودي = Σ وتل + فیس + سوځول پلي کوي، نو فیس له پټو نوټونو څخه تادیه کېږي پرته له دې چې څرګنده شي کوم نوټونه دي. منل شوی لګښت دا دی چې د فیس اندازه کولی شي د معاملې ټولګی (لیږد یا د پروګرام غږ) څرګند کړي.

سرچینه: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (د پریکړو جدول); docs/fees.md §1

15. ولې زېرمې (mint، د bridge تصدیق) عامه اندازه لري؟

هغه ارزښت چې حوض ته ننوځي باید په عامه توګه حساب شي، او د bridge تصدیق د دې عام شاهد دی چې په سرچینې زنځیر کې اړونده بندول (lock) رامنځته شوی. پایله کې لیدل یوازې د ننوتلو ګام پورې محدود دي، د Zcash د شفاف-څخه-خوندي (t-to-z) معاملې په څېر؛ د زېرمه شوي نوټ وروسته لګښتونه پټ دي.

سرچینه: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (د عامو معلوماتو جدول)

16. ولې memo یو ثابت 512 بایټه ساحه ده؟

ثابت اوږدوالی ډاډ ورکوي چې دفتر نه څرګندوي چې memo شته که نه او څومره اوږد دی: په هغه زنځیر کې چې memo ملاتړ لري، هر هغه لفافه چې نوټ جوړوي، د ځای ډکوونکو او پاتې پیسو په ګډون، دقیقاً 1,860 بایټه ده. memo یوازې د کوډ شوې لفافې دننه وړل کېږي، هیڅکله په نوټ، ژمنې یا ثبوت کې نه، او یوازې د هغو ډلو لپاره لوستل کېږي چې دمخه نوټ کوډ پرانیستلی شي. خراب memo د تش memo په توګه کوډ پرانیستل کېږي، ترڅو نوټ پخپله د بیا ترلاسه کولو وړ نه شي.

سرچینه: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md

17. ولې ثبوت جوړول محلي دي، او سپارل شوی ثبوت جوړونکی دا نه ماتوي؟

ثبوت پخپله د لګښت اجازه ده: بنډل نه لاسلیک لري او نه د لیږونکي ساحه، نو د لګښت کیلي هېڅکله اړتیا نه لري چې له بټوې بهر شي. د 14 پوړ د بنډل ثبوت نږدې 5.7 GB حافظه غواړي، چې له هغه څخه ډېره ده چې ټيلیفونونه او براوزرونه یې برابرولی شي، له همدې امله سپارل شوی ثبوت جوړونکی شته. ویشل شوې اجازه (د بنډل guest v3، د genesis پارامېټر hc_auth) دغه دوه رولونه جلا کوي: ثبوت جوړونکی یوازې د کتنې کیلي nk ترلاسه کوي او د بنډل ثبوت جوړوي، پداسې حال کې چې بټوه د sk په کارولو سره د 10 پوړ کوچنی اجازه ثبوت جوړوي. نو ثبوت جوړونکی کولی شي د بنډل ثبوت جوړ کړي خو د لګښت اجازه نشي ورکولی (پوښتنه 36).

سرچینه: docs/prover.md §1; docs/shielded.md (ویشل شوې اجازه); docs/superpowers/specs/2026-09-28-delegated-proving-design.md

18. ولې د 256 بلاکونو د لنګر کړکۍ؟

ثبوت د ژمنو د ونې د یوې ځانګړې ریښې (خپل لنګر) په وړاندې جوړېږي، او د 14 پوړ د بنډل ثبوت جوړول نږدې 100 s وخت نیسي. نو دفتر باید هغه لنګرونه ومني چې د سپارلو په وخت څو دقیقې زاړه وي. کړکۍ په اصلي مشخصاتو کې 64 بلاکه وه او کله چې د بلاک تر منځ وقفه کمه شوه، 256 بلاکونو ته پراخه شوه، ترڅو د دیوال ساعت په وخت کې موده د ثبوت جوړولو له وخت څخه پورته پاتې شي.

سرچینه: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md

zkVM او محرم محاسبه

19. ولې RV32I د guest ISA په توګه (او نه RV64)؟

یو 32 بټیز کلمه دقیقاً په څلورو بایټ برخو (limbs) ویشل کېږي، او د Goldilocks لومړی عدد p = 2^64 − 2^32 + 1 دومره لوی دی چې د دوو 32 بټیزو ارزښتونو ضرب هېڅکله له ساحې نه تېرېږي. RV64 به د ALU او حافظې په جدولونو کې د برخو ستنې دوه چنده کړې وای. RISC-V د عمده کمپایلرونو موجوده موخه هم ده، نو guest پروګرامونه عادي کمپایل شوي دودیز فایلونه دي، نه د ځانګړي ډول جوړ شوې ژبې پروګرامونه.

سرچینه: docs/zkvm.md §2; research/docs/01-isa.md (‘ولې RV32، نه RV64’)

20. ولې Goldilocks او نه د 256 بټه ساحه؟

Goldilocks یو 64 بټیز لومړی عدد دی چې حساب یې په اغېزمنه توګه د CPU له اصلي 64 بټیزو لارښوونو سره سمون لري، او ضربي ګروپ یې لوی د دوه د توان فرعي ګروپ لري، لکه څنګه چې FRI یې غواړي. له 32 بټیزو کلمو سره یوځای، دا هر د ټریس قطار تنګ ساتي، چې په لپټاپ کې د تولیدي پروفایل ثبوت جوړول شونی کوي. هغه امنیت چې د کوچنۍ ساحې په کارولو سره له لاسه ځي، د FRI ننګونې د غځول شوې ساحې څخه راایستلو سره بیرته ترلاسه کېږي.

سرچینه: docs/zkvm.md §2; randprotocol.org (د فعالیت برخه)

21. ولې د هر opcode د ګیس اندازه کولو پر ځای د ګیس پوړونه؟

د هر opcode ګیس په Ethereum کې شته ځکه چې هر نوډ هره معامله بیا اجرا کوي او د اجرا اوږدوالی له مخکې نه محدود دی. په Rand کې هیڅ نوډ پروګرام نه اجرا کوي: لیږونکی یې یو ځل، له زنځیر بهر، اجرا کوي او نوډونه یو واحد STARK تصدیقوي چې د تصدیق لګښت یې یوازې په پوړ پورې اړه لري، نه د سرته رسول شوې محاسبې په اندازه. پای ته رسېدل د پوړ په واسطه پلي کېږي، ځکه چې هغه اجرا چې په 2^t دورو کې ودرېږي نه، په t پوړ کې هېڅ ثبوت نه مني. بیه ایښودل یو ثابت حد او د سرلیک په واسطه محدود شوی د ګیس اټکل دی، او د بلاک ظرفیت د بایټونو بودیجه ده. ګیس یوازې د EVM او sBPF د تفسیرګر guests دننه، د خصوصي حالت په توګه، ښکاري، چې هلته د سرچینې زنځیر د معنا د بیا تولید لپاره اړین دی.

سرچینه: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md

22. ولې ټریس په نهو جدولونو ویشل شوی چې د LogUp بسونو په واسطه سره نښلول کېږي؟

یو واحد یکپارچه جدول به هر قطار د پراخترین عملیات تر پلنوالي ډک کړی وای. ټریس په نهو جدولونو ویشل — CPU، حافظه، ALU، حد (range)، نیبل، Poseidon2، پروګرام، ورودي او عام — چې هر یو یوازې خپل ارتفاع ته ډکېږي، ټول ټریس کوچنی ساتي. د LogUp دلیلونه د جدولونو ترمنځ د څو ټولګې اړیکې ټینګوي. د Keccak او SHA-256 جدولونه اختیاري دي او یوازې هغه وخت شاملېږي چې guest اړونده سیسټمي غږ وکاروي.

سرچینه: docs/zkvm.md §5

23. ولې د پروګرام غږ یوازې اته د وتلو کلمې خپروي؟

د پروګرام غږ د دې ثبوت دی چې عام کوډ په خصوصي ورودیو سم اجرا شوی؛ دفتر یوازې رسید ثبتوي. اته 32 بټیزې کلمې د پایلې، ژمنې یا پریکړې تړلو لپاره بسنه کوي، او د وتلو ثابت اندازه ډاډ ورکوي چې د رسید بڼه د پروګرام په اړه هېڅ نه څرګندوي. وتلې اوس مهال یوازې معلومات دي: پروګرام پخپله نشي کولی ارزښت ولیږدوي.

سرچینه: randprotocol.org/usecases (د پلاتفورم یادښت); docs/confidential.md

24. ولې د غږ د ورودي لفافه شته؟

هغه غږ کوونکی چې خصوصي ورودي ساتي، وروسته کولی شي وښيي چې غږ په څه محاسبه شوی و. د غږ د ورودي لفافه دا دایمي کوي، ځکه چې ورودي، کوډ شوې، د غږ سره ذخیره کوي، چېرې چې ټاکل شوی پلټونکی یې په یوې کیلي کوډ پرانیستلی شي. دا انتخابي افشا — بازار ته محرم، ټاکل شوي مقرراتي ته پرانیستې — له تادیاتو څخه پروګرام اجرا ته غځوي.

سرچینه: docs/confidential.md (‘د غږ د ورودي لفافې’)

25. ولې د قیدونو د ټولګې بدلون سخت فورک دی؟

هر نوډ د همغږۍ پر مهال هر ثبوت بیا تصدیقوي، او ثبوت یوازې د هغې قیدونو ټولګې (AIR) په اړه معتبر دی چې لاندې جوړ شوی. د AIR بدلون نو د معتبرو زنځیرونو ټولګه بدلوي، او په genesis پرې کولو کې معرفي کېږي، نه د نوډ په نوډ منلو سره.

سرچینه: docs/architecture.md (‘ولې د قیدونو د ټولګې بدلون سخت فورک دی’)

26. ولې emulator مرجع دی، نه AIR؟

emulator د ماشین لوستونکې مشخصات دی او AIR د دې مشخصاتو د څو ګڼ قیدونو په توګه کوډ کول دي. چېرې چې دواړه سره توپیر ولري، AIR په تعریف سره غلط دی. دا معیاري تعریف هغه اثر ته ځای ورکوي چې د انسانانو لپاره د پلټنې لپاره ډېر عملي دی.

سرچینه: docs/zkvm.md §5

همغږي او نوډ

27. ولې زنجیرې HotStuff BFT؟

زنجیرې HotStuff قطعي پای (finality) برابروي: د ونډې له مخې وزن شویو نصابونو سره چې له دوه پر دریمې برخې ډېر وي، بلاک هغه وخت پای ته رسېدلی دی چې په سر یې درې پرله پسې د نصاب تصدیقونه جوړ شي، او پای ته رسېدلی بلاک هیڅکله بیا نه تنظیمېږي. اندازه شوې د بلاک وقفه 1.2 s او د پای ته رسېدو وخت نږدې 3.6 s دی. موخه شوي بنسټیز کاروونکي د جوړجاړي پای ته رسېدل غواړي چې په وړاندې یې ثبتونه ولیکي، چې احتمالي پای لرونکی زنځیر یې نه برابروي.

سرچینه: fullnode README; randprotocol.org (د فعالیت برخه); docs/architecture.md §6

28. ولې د ثبوت تصدیق د همغږۍ له کړۍ بهر دی؟

نوډ هر STARK د معاملې د منلو پر مهال (نږدې 32 ms ګرم)، د لیږد مخکې، تصدیقوي، نو تصدیق هیڅکله د بلاک د وړاندیز په جدي لار کې نه پروت وي. د بلاک وقفه نو د همغږۍ د ځنډ په واسطه ټاکل کېږي، نه د ثبوت د اندازې په واسطه. څېړنې د لګښت له مخې ترتیب شوې دي، چې STARK وروستی تصدیق کېږي، ترڅو خراب جوړ شوې معامله له تر ټولو ګران ګام څخه مخکې رد شي.

سرچینه: randprotocol.org; docs/architecture.md (‘دا څنګه کار کوي’)

29. ولې د اعتبارکوونکو ثبت عام دی کله چې نور هر څه خوندي دي؟

ټول نقلونه باید په دې موافق وي چې کوم اعتبارکوونکي کولی شي وړاندیز وکړي او کوم رایې نصاب جوړوي، چې دا غواړي د ونډې وزنونه عام وي. نو ثبت د ونډې اندازې په څرګند ډول ساتي. د ملکیت سره اړیکه پټه پاتې کېږي: ژمنه (bond) له یوه خوندي شوي نوټ څخه تمویلېږي او ایستل یې یوه ته تادیه کېږي، او هیڅ یو عملیات نه څرګندوي چې نوټ د چا دی.

سرچینه: docs/staking.md §1

۳۰. ولې یو همغږي کیدونکی نوډ د تصدیقنامو په ځای هر بلاک بیا اجرا کوي؟

هغه نوډ چې ناوخته یوځای کیږي، زنځیر مني مخکې هر د نصاب تصدیقنامه تصدیق کوي، هر بنډل او د هر ایستلو ثبوت بیا تصدیق کوي، او پایله شوې رسیدونه سره پرتله کوي. ځکه چې اعتبار د یوازې لاسلیکونو پر ځای د ثبوتونو له لارې ټینګیږي، دا طریقه د هغو اوږدمهاله بریدونو سره مخ نه ده چې یوازې په لاسلیکونو خوندي زنځیرونو اغېزمن کوي. له تاریخ څخه د ثبوتونو لرې کول رد شول، ځکه چې دا به دغه تضمین له منځه یوسي.

سرچینه: docs/architecture.md؛ docs/aggregation.md (سریزه)

۳۱. ولې د بلاک سقف 4 MiB وساتل شي کله چې یو ثبوت له 1 MB څخه لوی وي؟

د ټاکل شوي سقف په شتون کې د بلاک اندازه نشي زیاتېدلی؛ کله چې غوښتنه له ظرفیت څخه ډېره شي، پر ځای یې تېرایستل محدودیږي (د 80-پوښتنو پروفایل لاندې په هر بلاک کې درې خوندي شوي لیږدونه). د تېرایستلو محدودیت د بلاک د بې حده زیاتوالي په پرتله یو خوندي ناکامي حالت وګڼل شو. غوره شوی حل د بلاک په کچه راټولول دي، یعنې په هر بلاک کې یو بیارغونیز ثبوت، نه د سقف لوړول یا د سالمیت د کچې ټيټول.

سرچینه: docs/block-space.md §1، §6

۳۲. ولې 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

۳۳. ولې libp2p؟

نوډ د Noise او Yamux سره TCP، د معاملاتو او رایو لپاره gossipsub، د ملګرو موندلو لپاره د بوټسټرېپ لیست سره Kademlia، په محلي شبکو کې mDNS، او د بلاک همغږي کولو لپاره غوښتنه-ځواب کاروي. دا معیاري او پراخه ځای پر ځای شوي برخې دي، نو نوډ د خپلو پلي کولو ساتلو پر ځای د ملګرو نمرې ورکول، بیا نښلېدل او د ټرانسپورټ ښه کولو ترلاسه کوي.

سرچینه: fullnode README (د شبکې کرښه)

د ثبوت بازار او راټولول

۳۴. ولې د بلاک په کچه د ثبوت راټولول؟

که هر بنډل خپل ثبوت ولري چې نژدې 1.3 MB دی، د بلاک ځای د بنډلونو له شمېر سره خطي ډیریږي. په هر بلاک کې یو واحد بیارغونیز STARK، چې ټول N د بنډل ثبوتونه تصدیق کوي، په زنځیر کې د ثبوت لګښت د N په اړه ثابت ساتي. بیا اعتبارورکوونکي په CPU یو راټول شوی ثبوت تصدیق کوي (نژدې 16 ms ګرم)، نو عادي تجهیزات لا هم اعتبار ورکولی شي، پداسې حال کې چې د GPU لرونکي راټولوونکي د فیسونو د ثبوتي برخې او د بلاک د سبسیدي لپاره په یوه جلا بې اجازې بازار کې سیالي کوي.

سرچینه: docs/aggregation.md §1

۳۵. ولې درې رولونه — اعتبارورکوونکی، راټولوونکی، سپارل شوی ثبوت جوړوونکی؟

دا درې رولونه جلا تجهیزاتي اړتیاوې لري او د جلا اړخونو لخوا تادیه کیږي. اعتبارورکوونکی په CPU معاملات ترتیبوي او تصدیقوي او د فیسونو د تصدیق له برخې تادیه کیږي. راټولوونکی په GPU د بلاک بیارغونیز ثبوت جوړوي او د ثبوتي برخې او سبسیدي څخه تادیه کیږي. سپارل شوی ثبوت جوړوونکی یوازې یو بنډل ثبوت هغه لیږونکي ته جوړوي چې وسیله یې نشي کولی (ټیلیفون یا براوزر) او د همدې لیږونکي لخوا په خصوصي توګه تادیه کیږي. د رولونو جلا کول اعتبار ورکول ارزانه ساتي او ثبوت جوړول سیالي کوونکی کوي.

سرچینه: docs/prover.md §1

۳۶. ولې سپارل شوی ثبوت جوړوونکی نشي کولی پیسې غلا کړي؟

د ویشل شوې اجازې لاندې ثبوت جوړوونکی د لیدو کیلي nk ترلاسه کوي خو د لګولو کیلي sk نه. د بنډل ثبوت c = H(AUTH, nk || salt) ته ژمن کیږي، او د والټ جلا د اجازې ثبوت د همدې c لپاره د sk پوهه ښيي. پرته له sk ثبوت جوړوونکی کولی شي د بنډل ثبوت محاسبه کړي خو معتبره اجازه نشي جوړولی، او والټ بېرته راستون شوی ثبوت له سپارلو مخکې تصدیقوي.

سرچینه: docs/shielded.md (ویشل شوې اجازه)؛ docs/prover.md §8

پل او zUSD

۳۷. ولې USDT/USDC په خپلو اصلي زنځیرونو کې وتړل شي، پر ځای د دې چې نوی سټېبلکوین خپور شي؟

په Rand کې اصلي خپرول به د ذخیرو ظرفیت د خپروونکو د ځای پر ځای کولو پرېکړو پورې تړلی کړي، چې د پروژې له واک بهر دي. په Ethereum، BSC، Tron او Solana کې د USDT او USDC تړل ذخیرې له هغو زنځیرونو څخه راکاږي چې دا شتمنۍ پکې لا مخکې څرخي، او هېڅ نوی خپروونکی نه معرفي کوي: هر zUSD واحد په یوه عامه لوستونکې امانتي قرارداد کې د ساتل شوي USDT یا USDC پر ضد ادعا ده.

سرچینه: randprotocol.org (د ذخیرو برخه)

۳۸. ولې t-له-n د ساتونکو ډله، او ولې دا په څرګنده ووایو؟

گواهي یوازینی شاهد دی چې Rand ته شته چې په بل زنځیر کې تړل ترسره شوی، نو باید د یوې حد لرونکې ډلې لخوا لاسلیک شي؛ یوه معتبره گواهي د ساتونکو له دوو پر دریمو برخو زیاتو لاسلیکونه غواړي. پایله شوې باور انګېرنه په څرګنده بیان شوې ده. اغېزمن تضمین د ذخیرو د پوره والي او د پل د بشپړتیا له دواړو څخه کمزوری دی؛ د t ساتونکو یوه ډله کولی شي پرته له اړوند تړلو د مینټ اجازه ورکړي؛ او خطر د هر زنځیر پر امانت محدودیږي. دا انګېرنه په اصل کې د پل نه جوړولو دلیل و. دا نه ده بېرته اخیستل شوې بلکې د ذخیرو د ظرفیت په بدل کې منل شوې ده.

سرچینه: randprotocol.org (د ذخیرو برخه، ‘دا څومره لګښت لري’)

۳۹. ولې د ECDSA گواهۍ تر څنګ Dilithium2 ګډ لاسلیک؟

سرچینې زنځیرونه د جالي لاسلیک تصدیق کوونکی نه لري، نو پر هغو زنځیرونو خلاصونه د کلاسیک ECDSA له لارې خوندي پاتې کیږي، چې خطر یې د امانت او سقفونو پر مټ محدودیږي. هر پیغام چې د Rand دفتر یې له ساتونکو منلی شي — زېرمې او د ساتونکو د ډلې بدلونونه — باید له همدغو ساتونکو څخه د Dilithium2 لاسلیکونو نصاب هم ولري. نو د مینټ لاره پس-کوانټمي ده سره له دې چې بهرني پای ټکي نه دي. ګډ لاسلیکونه له گواهۍ سره یوځای لیږدول کیږي او په ځای پر ځای شویو قراردادونو کې بدلون ته اړتیا نه لري.

سرچینه: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1

۴۰. ولې د زېرمې یادښت پټوالی ترلاسه کیږي نه ټاکل کیږي؟

مخکې د زېرمې د یادښت ژمنتیا تر هغه نه وه ټاکل شوې چې یو لیږدوونکي گواهي وسپارله، نو دوو لیږدوونکو کولی شو یوه گواهي د جلا یادښتونو سره وسپاري. د پټوالي فکتور r له گواهۍ څخه په ټاکلې توګه ترلاسه کول ژمنتیا ټاکي، نو سیالې سپارنې په یوې ژمنتیا کې سره ټکر کوي او زېرمه دوه ځلې مینټ نشي کیدی.

سرچینه: docs/bridge.md (F1، chain 14)

۴۱. ولې په Tron کې تړل شوی USDT په Ethereum کې د USDT په توګه وتلی شي؟

zUSD بدلېدونکی دی: هر واحد د ټولیزې ذخیرې پر ضد ادعا ده، نه د هغه زنځیر پر ضد چې له لارې یې داخل شوی. د داخلېدو او وتلو جلا کول اجازه ورکوي چې نغدینه هغې خوا ته لاړه شي چیرې چې غوښتنه ده، پدې شرط چې موخه زنځیر کافي ذخیرې ولري. د سټېبلکوین مقاله ثابتوي چې بدلون S ≤ Σ_c R_c، یعنې ټوله عرضه د هر زنځیر د ذخیرو له مجموعې پورې محدوده، د هرې حالتي لېږد په واسطه ساتل کیږي.

سرچینه: randprotocol.org (د ذخیرو برخه)

۴۲. ولې خوندي کول ویش پټوي خو کمیت نه؟

د zUSD ټوله عرضه د ټوکن په ثبت کې عامه ده او د هر زنځیر ذخیره یو عام بیلانس دی، نو پوره والی هر څوک تصدیقولی شي؛ هغه څه چې پټیږي د مالکانو ترمنځ د ساتونو ویش دی. یو محدودیت شته: څلور ذخیره بیلانسونه په یو واحد شېبه کې په اټومي ډول نشي کتل کیدی، نو د دغو زنځیرونو لپاره کتنه ناپوره والی وروسته له پېښې کشفوي نه د هغې مخنیوی.

سرچینه: randprotocol.org (د ذخیرو برخه)

۴۳. ولې سوځول هغه یوازینی معامله ده چې خپله شتمني نومولي؟

سوځول په ټاکلي زنځیر کې یوه ټاکلې شتمني خلاصوي، نو امانتي قرارداد باید پوه شي چې کومه شتمني او کوم زنځیر. هره بله معامله یوه نامعلومه شتمني لیږدوي. سوځول د پل فیس هم لري، ځکه دا یوازینۍ د پل معامله ده چې لیږونکی یې ګټه اخیستونکی دی.

سرچینه: docs/architecture.md؛ docs/shielded.md §2

تطابق او افشا

۴۴. ولې د لیدو کیلۍ، نه ‘له هر چا خصوصي’؟

مقررات جوړوونکو هغه د محرمیت سیستمونه نه دي منلي چې افشا یې د هغه اړخ په همکارۍ پورې تړلې وي چې څېړل کیږي، لکه څنګه چې د Tornado Cash قضیه ښيي. نو Rand افشا د پروتوکول یو څیز ګڼي. ساتونکی، یا یو مقرراتي منځګړی، د لیدو کیلي ساتي؛ یو پلټونکی کولی شي هغه معاملات خلاص کړي چې په قانوني غوښتنه کې نومول شوي؛ او د ډیزاین هدف ځانګړې کیلۍ دي چې طرف او مقدار څرګندوي پرته له دې چې د سوداګرۍ ستراتیژي ښکاره کړي. د معاشونو په څېر کارونو لپاره دا پلټنه یوه اړتیا ده نه محدودیت.

سرچینه: randprotocol.org/usecases (د مقرراتو برخه؛ د معاشونو قضیه)

۴۵. ولې د وتلو د لیدو کیلي د راتلو له کیلۍ جلا ده؟

جلا کول لیږونکي ته اجازه ورکوي ثابت کړي چې څه یې ورکړي پرته له دې چې د ترلاسه کوونکي تاریخ ته لاسرسی ومومي، او برعکس. د وتلو د لیدو کیلي ovk هغه پاکټونه خلاصوي چې والټ لیږلي؛ د ML-KEM د ډیکپسولېشن کیلي هغه پاکټونه خلاصوي چې دې ته لیږل شوي؛ او د هرې معاملې کیلي یوازې یو محصول دریم اړخ ته افشا کوي.

سرچینه: docs/shielded.md §1–2

پېژندل شوي محدودیتونه

۴۶. ثبوتونه نن ورځ څه افشا کوي، او ولې دا مستند شوي؟

د 2026-09-27 کتنې وموندله چې د v1 مېلمه (chains 14–15) لاندې هر د بنډل ثبوت ښيي چې کومې د ننوتلو خونې ریښتینې یادښتونه لري او د هر لګول شوي پاڼې شاخص د Hamming وزن. لامل دوه اړخیز دی: د هر جدول LogUp مجموعې پرته له پټولو خپرېږي، او د مېلمه د کنټرول جریان په دې اړه څانګه کوي چې ایا ننوتل ساختګی دی. حل یو بې څانګې مېلمه (v2) دی، چې په راتلونکي genesis کې به وټاکل شي. موندنه ځکه خپره شوې چې شبکه testnet ده او اسناد د هغې د پلټنې ریکارډ په توګه کار کوي.

سرچینه: docs/shielded.md (‘ثبوتونه نن ورځ څه افشا کوي’)

۴۷. ولې د حالت د ودې بیه ټيټه ټاکل شوې ده؟

Ethereum د ذخیرې د لیکلو بیه ټاکي، ځکه چې ذخیره شوې حالت په هر نوډ یو دایمي لګښت لګوي. Rand اوس مهال د ژمنې ونې، د nullifier ټولګې او د پروګرام د ذخیرې وده یوازې د هر کلمې په اړه د ځای پر ځای کولو فیس او د بنډل ثابت فیس له لارې بیه کوي. دا د testnet لپاره بسنه کوي، خو د یوې پرانیستې بیه‌ټاکنې پوښتنې په توګه ثبت شوې ده چې باید د mainnet دمخه حل شي؛ د دې حل د هر opcode اندازه‌کولو ته اړتیا نه لري.

سرچینه: docs/fees.md §3 (caveats)

48. ولې تر اوسه هیڅ خپلواک پلټنه نه ده بشپړه شوې؟

پروتوکول د ټیم لخوا پرمخ وړل کېدونکي testnet کې د فعالې پراختیا لاندې دی، او تمه کېږي چې د ډیزاین له ثبات دمخه نور د بندیزونو ټولګې او د زنځیر کټونه راشي. ویب‌پاڼه دا خبره په هره پاڼه کې بیانوي. داخلي پلټنې پړاوونه (v3–v5) په docs/consensus.md او د ډیزاین په مشخصاتو کې خپاره شوي، څو وروستۍ بهرنۍ پلټنه د کار لپاره بشپړ ریکارډ ولري.

سرچینه: randprotocol.org (footer); docs/consensus.md