پرسش‌های متداول طراحی

این صفحه دلیل هر تصمیم طراحی مهم در Rand را ثبت می‌کند: ویژگی‌ای که یک مؤلفه باید فراهم کند، فرضی که این ویژگی در سایه‌ی آن برقرار می‌شود، و هزینه‌ای که در ازای آن پذیرفته شده است. این صفحه در ۲۹ سپتامبر ۲۰۲۶ از روی همین سایت، خلاصه‌ی whitepaper و full node مرجع (github.com/randprotocol/fullnode: فایل README، پوشه‌ی docs/ و docs/superpowers/specs/) گردآوری شده است. هر پاسخ به سندی ارجاع می‌دهد که دلیل تصمیم در آن بیان شده است؛ مسیرها به مخزن fullnode اشاره دارند، مگر آنکه با randprotocol.org آغاز شوند.

وضعیت. Rand روی یک testnet اجرا می‌شود که تیم مؤسس آن را اداره می‌کند، و پروتکل هنوز به‌صورت مستقل حسابرسی نشده است. چند تصمیم از تصمیم‌های زیر مرحله‌به‌مرحله و در برش‌های متوالی زنجیره پیاده‌سازی می‌شوند. همه‌ی اعداد اندازه‌گیری‌های گره‌ی در حال اجرا در زمان گردآوری هستند؛ انتظار می‌رود تغییر کنند و پیش از استناد باید دوباره اندازه‌گیری شوند.

primitiveهای رمزنگاری

1. چرا ML-KEM-768 (Kyber) برای رمزنگاری یادداشت؟

متن آشکار یک یادداشت در یک پاکت (envelope) به گیرنده‌اش رمزنگاری می‌شود و این پاکت برای همیشه روی دفتر کل عمومی باقی می‌ماند. بنابراین محرمانگی آن یک ویژگی بازگشت‌ناپذیر است (پرسش 8): مهاجمی که در هر زمان بعدی به یک رایانه‌ی کوانتومی مرتبط با رمزنگاری دست یابد، می‌تواند همه‌ی پاکت‌های تاریخی را که با یک KEM مبتنی بر منحنی بیضوی مهروموم شده‌اند رمزگشایی کند، زیرا الگوریتم Shor لگاریتم گسسته را در زمان چندجمله‌ای حل می‌کند. ML-KEM در NIST FIPS 203 استانداردسازی شده و امنیت آن به Module-LWE فروکاسته می‌شود که برای آن الگوریتم کوانتومی کارایی شناخته نشده است. مجموعه‌پارامتر 768 (دسته‌ی 3 در NIST) به‌عنوان مصالحه میان حاشیه‌ی امنیت و کلید کپسوله‌سازی 1,184 بایتی انتخاب شد که هر نشانی باید آن را حمل کند. پاکت از ترکیب ML-KEM-768 با ChaCha20-Poly1305 ساخته می‌شود: 1,348 بایت، یا 1,860 بایت همراه با فیلد ثابت memo.

منبع: randprotocol.org (بخش post-quantum)؛ README مخزن fullnode؛ docs/shielded.md §2

2. چرا تعهدهای Poseidon2 و نه Pedersen؟

تعهدهای Pedersen کاملاً پنهان‌کننده‌اند اما فقط از نظر محاسباتی مقیِّدکننده‌اند، و مقیِّد بودن آن‌ها به فرض لگاریتم گسسته فروکاسته می‌شود که مهاجم کوانتومی آن را می‌شکند؛ مهاجمی که بتواند لگاریتم گسسته را محاسبه کند می‌تواند یک تعهد را روی مقداری متفاوت باز کند. چون تعهدی که امروز منتشر می‌شود باید در تمام عمر دفتر کل درست و پنهان‌کننده بماند، طرح باید بر فرض‌هایی استوار باشد که در برابر مهاجمان کوانتومی معتبر دانسته می‌شوند، و در عمل این یعنی یک تابع درهم‌ساز. Poseidon2 یک تابع درهم‌ساز متناسب با حسابی‌سازی (arithmetisation) است که روی میدان Goldilocks تعریف شده، و بنابراین ارزیابی آن درون STARK قیود کمی مصرف می‌کند. همین تابع درهم‌ساز تعهد یادداشت، درخت Merkle با عمق 32 و نالیفایر را پیاده می‌کند.

منبع: randprotocol.org (بخش post-quantum)؛ docs/shielded.md §1–2

3. چرا دو تابع درهم‌ساز — BLAKE3 و Poseidon2؟

این دو تابع برای مدل‌های هزینه‌ی متفاوتی بهینه شده‌اند. Poseidon2 در هر جا که تابع درهم‌ساز باید درون یک اثبات ارزیابی شود به کار می‌رود — یادداشت‌ها، درخت تعهد، نالیفایرها و جدول‌های داخلی zkVM — زیرا هزینه‌ی آن با تعداد قیود سنجیده می‌شود. BLAKE3 در هر جا به کار می‌رود که اثباتی در میان نیست و توان عملیاتی بومی غالب است: درهم‌های بلوک، ریشه‌ی حالت روی درخت، مجموعه‌ی نالیفایرها، ثبت‌نامه‌ی validatorها و جدول برنامه‌ها، و نشانی validatorها (درهم BLAKE3 کلید عمومی). Poseidon2 روی CPU نسبتاً کند است؛ BLAKE3 حسابی‌سازی‌اش نسبتاً پرهزینه است. هر کدام فقط در جایی به کار می‌رود که مدل هزینه‌اش صدق می‌کند.

منبع: README مخزن fullnode (ردیف signatures / hashes)؛ docs/architecture.md

4. چرا Dilithium2 (ML-DSA) برای امضای validatorها؟

امضاهای اجماع یک ویژگی تجدیدپذیر فراهم می‌کنند (پرسش 8): شکسته شدن طرح در آینده جعل پیام‌های آینده را ممکن می‌کند اما بلوک‌هایی را که پیش‌تر نهایی شده‌اند به‌طور عطف‌به‌ماسبق باطل نمی‌کند، بنابراین در اصل می‌توان طرح را پیش از پدید آمدن مهاجم کوانتومی جایگزین کرد. با این حال از همان genesis یک طرح مبتنی بر شبکه (lattice) به کار گرفته شد تا رأی‌های اجماع، هم‌امضایی نگهبانان پل و ثبت‌نامه‌ی validatorها یک نوع کلید پساکوانتومی واحد داشته باشند. گره مجموعه‌پارامتر دور سوم Dilithium2 را پیاده می‌کند (crate با نام crystals-dilithium) که با ML-DSA-44 نهایی در FIPS 204 تفاوت دارد؛ کلیدهای عمومی 1,312 بایت و امضاها 2,420 بایت‌اند.

منبع: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2؛ randprotocol.org

5. چرا STARK شفاف (FRI روی Goldilocks) و نه SNARK؟

این انتخاب از سه الزام نتیجه می‌شود. نخست، بدون تنظیم مورد اعتماد (trusted setup): درستی (soundness) فقط بر مقاومت در برابر برخورد یک تابع درهم‌ساز استوار است، نه بر رشته‌ی مرجع ساخت‌یافته یا منحنی سازگار با pairing. دوم، درستی پساکوانتومی محتمل: این برهان هیچ فرض لگاریتم گسسته یا pairing ندارد. سوم، سازگاری با طرح تعهد مبتنی بر تابع درهم‌ساز در پرسش 2. هزینه‌ی آن اندازه‌ی اثبات است: اثبات یک bundle حدود 1.3 MB است، یعنی 300 تا 600 برابر اندازه‌ی یک تراکنش شیلد‌شده در Zcash یا Monero. این هزینه پذیرفته شد و جداگانه با تجمیع در سطح بلوک پاسخ داده می‌شود (پرسش‌های 31 و 34).

منبع: randprotocol.org؛ docs/block-space.md §1؛ docs/zkvm.md

6. چرا نمایه‌ی FRI با 80 پرس‌وجو و نه 27؟

نمایه‌ی تولید (80 پرس‌وجو، ضریب blowup برابر 8، و 20 بیت grinding اثبات کار) حدود 86 بیت درستی اثبات‌پذیر فراهم می‌کند، در برابر حدود 42 بیت برای نمایه‌ی 27 پرس‌وجویی، با 2.75 برابر اندازه‌ی اثبات. زمان راستی‌آزمایی تقریباً تغییر نمی‌کند: 809 ms که در حالت سرد به 838 ms می‌رسد، و در حالت گرم حدود 16 ms. درستی اثبات‌پذیر بر اندازه‌ی اثبات اولویت یافت و هزینه‌ی اندازه به طراحی فضای بلوک و تجمیع منتقل شد.

منبع: docs/block-space.md §1، §3

7. چرا ادعای پساکوانتومی برای هر primitive جداگانه بیان می‌شود و نه به‌صورت «128 بیت در سراسر پروتکل»؟

پیش‌نویس‌های پیشین 128 بیت امنیت پساکوانتومی را برای کل پروتکل ادعا می‌کردند. این ادعا با کران Brassard–Høyer–Tapp سازگار نیست، که بر پایه‌ی آن مهاجم کوانتومی برخورد در یک تابع درهم‌ساز 256 بیتی را در حدود 2^85 پرس‌وجو پیدا می‌کند؛ از این رو ادعا به‌جای آنکه مشروط شود، پس گرفته شد. مقاله اکنون امنیت را برای هر primitive و هر نقش بیان می‌کند — یک درهم‌ساز transcript با 384 بیت، درهم‌سازهای 256 بیتی که فقط جایی به کار می‌روند که مقاومت در برابر پیش‌تصویر لازم است، Dilithium2، ML-KEM-768، و FRI روی یک میدان توسعه‌یافته — تحت فرض‌های Module-LWE و Module-SIS و با مدل‌سازی توابع درهم‌ساز به‌صورت اوراکل‌های تصادفی کوانتومی. درهم‌ساز transcript گره در حال حاضر Poseidon2 است؛ مستندات این مورد را به‌عنوان یک شکاف پیکربندی باز فهرست می‌کنند.

منبع: randprotocol.org (بخش post-quantum)

8. طبقه‌بندی «بازگشت‌ناپذیر در برابر تجدیدپذیر» چیست و چرا انتخاب‌ها را تعیین می‌کند؟

یک ویژگی امنیتی بازگشت‌ناپذیر است اگر مهاجمی که در هر زمان آینده توانایی تازه‌ای کسب می‌کند بتواند آن را برای داده‌ای که پیش‌تر منتشر شده است به‌طور عطف‌به‌ماسبق نقض کند؛ محرمانگی یادداشت و پنهان‌کنندگی تعهد از این نوع‌اند، پس باید در لحظه‌ی انتشار در برابر رایانه‌ی کوانتومی مقاوم باشند. یک ویژگی تجدیدپذیر است اگر در هر بار استفاده دوباره برقرار شود، به‌طوری که بتوان طرح را پیش از تحقق تهدید جایگزین کرد؛ امضاها و درستی اثبات از این نوع‌اند. هر انتخاب primitive در این بخش از طبقه‌بندی ویژگی‌ای که از آن محافظت می‌کند نتیجه می‌شود.

منبع: randprotocol.org (بخش post-quantum)

استخر شیلد‌شده

9. چرا مدل یادداشت/UTXO بدون حساب و موجودی؟

دفتر کل مبتنی بر حساب، به‌حکم ساختار، موجودی‌ها را منتشر می‌کند؛ پنهان کردن آن‌ها مستلزم رمزنگاری حالت و اثبات گزاره‌ها روی متن‌های رمزشده است که به‌مراتب پرهزینه‌تر است. استخر یادداشت فقط تعهدها و نالیفایرها را نگه می‌دارد که هیچ‌کدام مالک یا مقدار را آشکار نمی‌کنند، بنابراین حالت عمومی هیچ اطلاعات موجودی ندارد. تنها استثنا ثبت‌نامه‌ی validatorهاست که وزن‌های سهام آن باید عمومی باشد تا replicaها بر سر عضویت حدنصاب توافق کنند (پرسش 29).

منبع: docs/shielded.md §1–2؛ docs/staking.md §1

10. چرا نشانی حدود 1.6 KB است؟

یک نشانی شیلد‌شده از فیلد مالک 32 بایتی pk و کلید کپسوله‌سازی 1,184 بایتی ML-KEM-768 تشکیل می‌شود که فرستنده برای مهروموم کردن پاکت به آن نیاز دارد؛ با کدگذاری base58 این حدود 1,667 نویسه می‌شود. این طول پیامد مستقیم KEM پساکوانتومی است. یک طراحی تأییدشده (نشانی‌های شیلد‌شده‌ی کوتاه، 2026-09-17) نشانی را با یک شناسه‌ی گیرنده در حدود 256 بیت جایگزین می‌کند که به یک رکورد به‌روزشدنی تبدیل می‌شود، با کلید خرج (spend key) امضا شده و توسط explorer ارائه می‌شود، به‌طوری که کلید کپسوله‌سازی واکشی می‌شود و نیازی به رونویسی دستی نیست.

منبع: docs/shielded.md §1؛ docs/superpowers/specs/2026-09-17-short-shielded-address.md

11. چرا همه‌ی کلیدها از یک کلید خرج 256 بیتی مشتق می‌شوند؟

همه‌ی مواد کلیدی دیگر تابعی قطعی از یک راز واحد sk هستند: کلید مشاهده nk = H(NK, sk)، فیلد مالک pk = H(PK, nk)، نالیفایر H(NF, nk, cm)، کلید مشاهده‌ی خروجی و کلید رمزگشایی ML-KEM، هر یک با جداکننده‌ی دامنه‌ی خودش. بنابراین فایل کلید فقط sk را ذخیره می‌کند، پشتیبان‌گیری یک مقدار واحد است، و پیمایش دوباره‌ی درخت از برگ 0 همه‌ی یادداشت‌ها را بازیابی می‌کند. چون نسخه‌ی دومی برای بازیابی وجود ندارد، کیف پول از بازنویسی یک فایل کلید موجود خودداری می‌کند.

منبع: docs/shielded.md §1

12. چرا شکل ثابت bundle با 4 ورودی و 4 خروجی؟

شکل ثابت باعث می‌شود هر bundle، صرف‌نظر از آنچه جابه‌جا می‌کند، اندازه و ساختار یکسانی داشته باشد. هر bundle دقیقاً چهار نالیفایر و چهار تعهد منتشر می‌کند؛ جایگاه‌های استفاده‌نشده یادداشت‌های ساختگی با مقدار صفر هستند، و خروجی باقی‌مانده (change) حتی وقتی مقدارش صفر است منتشر می‌شود، زیرا نبودن آن تراکنش را متمایز می‌کرد. مشخصات اولیه 2 ورودی و 2 خروجی بود و از Sapling پیروی می‌کرد. با bundle دارایی پنهان به 4 ورودی و 4 خروجی گسترش یافت، به‌طوری که جایگاه‌های 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) را جابه‌جا می‌کند؟

پیش از زنجیرهٔ ۱۴، یک انتقال توکن دو بسته حمل می‌کرد، یکی برای کارمزد RAND و دیگری برای دارایی. این کار به دو اثبات نیاز داشت و به هر ناظری نشان می‌داد کدام توکن جابه‌جا شده است. guest دارایی پنهان، شناسهٔ دارایی را به‌عنوان ورودی خصوصی می‌گیرد؛ بنابراین یک انتقال zUSD از یک پرداخت RAND قابل تشخیص نیست. این guest تنها به این دلیل در رده ۱۴ جا می‌شود (تقریباً 100 s و 5٫7 GB حافظه) که ورودی‌هایش را در یک حلقه می‌خواند و بررسی عضویت Merkle را با آن ادغام می‌کند؛ پیاده‌سازی کاملاً بازشده به رده ۱۶ نیاز دارد (تقریباً 400 s و 21 GB) که از حافظهٔ یک دستگاه 16 GB فراتر می‌رود.

منبع: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3

۱۴. چرا کارمزد عمومی است و به پیشنهاددهندهٔ بلوک پرداخت می‌شود؟

کارمزد عمومی با دفتر عمومی سهام سازگار است و پذیرش تراکنش را ارزان می‌کند: یک گره می‌تواند پیش از انجام هر گونه راستی‌آزمایی، کف کارمزد را بررسی کند. اثبات بسته، معادلهٔ توازن Σ ورودی‌ها = Σ خروجی‌ها + کارمزد + سوزاندن را اعمال می‌کند؛ بنابراین کارمزد از یادداشت‌های پنهان پرداخت می‌شود، بی‌آنکه معلوم شود کدام یادداشت‌ها. هزینه‌ای که پذیرفته شده این است که مقدار کارمزد ممکن است نوع تراکنش (انتقال یا فراخوانی برنامه) را آشکار کند.

منبع: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (rulings table); docs/fees.md §1

۱۵. چرا سپرده‌ها (mint، bridge attest) مقدار عمومی دارند؟

ارزشی که وارد استخر می‌شود باید به‌طور عمومی حسابرسی شود، و گواهی پل شاهد عمومی است بر این‌که قفل متناظر در زنجیرهٔ مبدأ انجام شده است. آشکاری حاصل به گام ورود محدود می‌ماند و مشابه تراکنش شفاف‌به‌محافظت‌شده (t-to-z) در Zcash است؛ خرج‌های بعدی یادداشت واریزشده پنهان‌اند.

منبع: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (what is public table)

۱۶. چرا پیام ضمیمه (memo) یک فیلد ثابت 512 بایتی است؟

فیلد با طول ثابت تضمین می‌کند که دفتر کل آشکار نکند پیام ضمیمه وجود دارد یا چه طولی دارد: در زنجیری که memo در آن فعال است، هر پاکت سازندهٔ یادداشت، از جمله پاکت‌های ساختگی و باقی‌مانده، دقیقاً 1٬860 بایت است. پیام ضمیمه فقط درون پاکت رمزگذاری‌شده حمل می‌شود و هرگز در یادداشت، تعهد یا اثبات قرار نمی‌گیرد، و دقیقاً برای طرف‌هایی خواناست که پیش‌تر می‌توانند یادداشت را رمزگشایی کنند. پیام ضمیمهٔ نادرست به‌صورت پیام ضمیمهٔ تهی رمزگشایی می‌شود تا نتواند خود یادداشت را غیرقابل بازیابی کند.

منبع: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md

۱۷. چرا اثبات محلی انجام می‌شود، و اثبات‌کنندهٔ تفویض‌شده چگونه این را نقض نمی‌کند؟

خود اثبات همان مجوز خرج است: بسته هیچ امضا و هیچ فیلد فرستنده‌ای ندارد، بنابراین کلید خرج هرگز نیازی به خروج از کیف پول ندارد. اثبات بستهٔ رده ۱۴ تقریباً به 5٫7 GB حافظه نیاز دارد که از توان تلفن‌ها و مرورگرها فراتر است؛ از این رو اثبات‌کنندهٔ تفویض‌شده وجود دارد. مجوزدهی تقسیم‌شده (guest بستهٔ v3، پارامتر پیدایش hc_auth) این دو نقش را جدا می‌کند: اثبات‌کننده فقط کلید مشاهده nk را دریافت می‌کند و اثبات بسته را تولید می‌کند، در حالی که کیف پول با sk یک اثبات مجوز کوچک در رده ۱۰ تولید می‌کند. بنابراین اثبات‌کننده می‌تواند اثبات بسته بسازد اما نمی‌تواند خرجی را مجاز کند (پرسش ۳۶).

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

۱۸. چرا پنجرهٔ لنگر 256 بلوک است؟

یک اثبات در برابر یک ریشهٔ مشخص درخت تعهد (لنگر آن) ساخته می‌شود، و ساخت اثبات بستهٔ رده ۱۴ تقریباً 100 s طول می‌کشد. بنابراین دفتر کل باید لنگرهایی را بپذیرد که در لحظهٔ ارسال چند دقیقه قدمت دارند. این پنجره در مشخصات اولیه 64 بلوک بود و با کاهش فاصلهٔ بلوک‌ها به 256 بلوک افزایش یافت تا مدت آن بر حسب زمان واقعی بالاتر از زمان اثبات بماند.

منبع: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md

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

۱۹. چرا RV32I به‌عنوان ISA مهمان (و نه RV64)؟

یک کلمهٔ 32 بیتی دقیقاً به چهار لیمب بایتی تجزیه می‌شود، و عدد اول Goldilocks یعنی p = 2^64 − 2^32 + 1 آن‌قدر بزرگ است که حاصل‌ضرب دو مقدار 32 بیتی هرگز از میدان سرریز نمی‌کند. RV64 تعداد ستون‌های لیمب را در جدول‌های ALU و حافظه دو برابر می‌کرد. RISC-V همچنین هدفی موجود برای کامپایلرهای رایج است، بنابراین برنامه‌های guest دودویی‌های کامپایل‌شدهٔ معمولی‌اند و نه برنامه‌هایی در زبانی ساخته‌شده برای این منظور.

منبع: docs/zkvm.md §2; research/docs/01-isa.md (‘Why RV32, not RV64’)

۲۰. چرا Goldilocks و نه یک میدان 256 بیتی؟

Goldilocks یک عدد اول 64 بیتی است که حساب آن به‌خوبی روی دستورهای بومی 64 بیتی CPU نگاشت می‌شود و گروه ضربی آن زیرگروهی بزرگ از توان‌های دو دارد، آن‌گونه که FRI می‌طلبد. این میدان در کنار کلمات 32 بیتی، هر سطر ردگیری را باریک نگه می‌دارد، و همین اثبات با پروفایل تولید را روی یک لپ‌تاپ شدنی می‌کند. صحتی که با کار روی میدان کوچک از دست می‌رود، با انتخاب چالش‌های FRI از یک میدان توسعه جبران می‌شود.

منبع: docs/zkvm.md §2; randprotocol.org (performance section)

۲۱. چرا ردهٔ گاز به‌جای اندازه‌گیری گاز برای هر opcode؟

گاز به ازای هر opcode در Ethereum وجود دارد، زیرا هر گره هر تراکنش را دوباره اجرا می‌کند و طول اجرا از پیش کران‌دار نیست. در Rand هیچ گرهی برنامه را اجرا نمی‌کند: فرستنده آن را یک بار و بیرون از زنجیره اجرا می‌کند و گره‌ها یک STARK واحد را راستی‌آزمایی می‌کنند که هزینهٔ راستی‌آزمایی آن فقط به رده بستگی دارد، نه به محاسبهٔ انجام‌شده. پایان‌پذیری را رده اعمال می‌کند، زیرا اجرایی که در 2^t چرخه متوقف نشود، در رده t اثباتی نمی‌پذیرد. قیمت‌گذاری یک کف ثابت به‌علاوهٔ تخمین گاز کران‌دار با سرآیند است، و ظرفیت بلوک یک بودجهٔ بایتی است. گاز تنها درون guestهای مفسر EVM و sBPF، به‌صورت حالت خصوصی، ظاهر می‌شود، آن‌جا که برای بازتولید معناشناسی زنجیرهٔ مبدأ لازم است.

منبع: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md

۲۲. چرا ردگیری به نه جدول تقسیم شده که با باس‌های LogUp به هم متصل‌اند؟

یک جدول یکپارچهٔ واحد، هر سطر را تا عرض پهن‌ترین عملیات پر می‌کرد. جداسازی ردگیری به نه جدول — CPU، حافظه، ALU، بازه، نیبل، Poseidon2، برنامه، ورودی و عمومی — که هر کدام فقط تا ارتفاع خودشان پر می‌شوند، کل ردگیری را کوچک نگه می‌دارد. آرگومان‌های LogUp روابط چندمجموعه‌ای میان جدول‌ها را برقرار می‌کنند. جدول‌های Keccak و SHA-256 اختیاری‌اند و فقط وقتی گنجانده می‌شوند که guest فراخوانی سیستمی متناظر را صدا بزند.

منبع: docs/zkvm.md §5

۲۳. چرا یک فراخوانی برنامه فقط هشت کلمهٔ خروجی منتشر می‌کند؟

فراخوانی برنامه اثباتی است بر این‌که کد عمومی روی ورودی‌های خصوصی به‌درستی اجرا شده است؛ دفتر کل فقط رسید را ثبت می‌کند. هشت کلمهٔ 32 بیتی برای الزام یک نتیجه، یک تعهد یا یک تصمیم کافی است، و اندازهٔ ثابت خروجی تضمین می‌کند که شکل رسید چیزی دربارهٔ برنامه آشکار نکند. خروجی‌ها در حال حاضر فقط داده‌اند: یک برنامه خودش نمی‌تواند ارزشی منتقل کند.

منبع: randprotocol.org/usecases (platform note); docs/confidential.md

۲۴. چرا پاکت ورودی فراخوانی وجود دارد؟

فراخواننده‌ای که ورودی‌های خصوصی را نگه می‌دارد، می‌تواند بعداً نشان دهد فراخوانی روی چه چیزی محاسبه شده بود. پاکت ورودی فراخوانی این امکان را ماندگار می‌کند، با ذخیرهٔ ورودی‌ها به‌صورت رمزگذاری‌شده در کنار فراخوانی، جایی که یک حسابرس تعیین‌شده می‌تواند آن‌ها را با یک کلید رمزگشایی کند. این کار افشای گزینشی — محرمانه برای بازار، باز برای یک ناظر تعیین‌شده — را از پرداخت‌ها به اجرای برنامه گسترش می‌دهد.

منبع: docs/confidential.md (‘Call input envelopes’)

۲۵. چرا تغییر مجموعهٔ قیدها یک هاردفورک است؟

هر گره هر اثبات را هنگام همگام‌سازی دوباره راستی‌آزمایی می‌کند، و یک اثبات تنها نسبت به مجموعهٔ قیدها (AIR) که تحت آن تولید شده معتبر است. بنابراین تغییر AIR مجموعهٔ زنجیره‌های معتبر را تغییر می‌دهد، و در یک برش پیدایش معرفی می‌شود و نه این‌که گره به گره پذیرفته شود.

منبع: docs/architecture.md (‘Why a constraint-set change is a hard fork’)

۲۶. چرا مرجع، شبیه‌ساز است و نه AIR؟

شبیه‌ساز مشخصهٔ خوانای ماشین است و AIR رمزگذاری آن مشخصه به‌صورت قیدهای چندجمله‌ای است. هرجا این دو ناسازگار باشند، AIR بنا به تعریف خطا دارد. این کار تعریف هنجاری را در مصنوعی قرار می‌دهد که برای ممیزی انسانی عملی‌ترین است.

منبع: docs/zkvm.md §5

اجماع و گره

۲۷. چرا HotStuff BFT زنجیره‌ای؟

HotStuff زنجیره‌ای نهایی‌شدگی قطعی فراهم می‌کند: با حد نصاب‌های وزن‌دار بر پایهٔ سهام به بیش از دو سوم، یک بلوک پس از تشکیل سه گواهی حد نصاب متوالی بر روی آن نهایی است، و یک بلوک نهایی هرگز بازسازماندهی نمی‌شود. فاصلهٔ بلوک اندازه‌گیری‌شده 1٫2 s و زمان تا نهایی‌شدگی تقریباً 3٫6 s است. کاربران نهادی مورد نظر به نهایی‌شدگی تسویه نیاز دارند تا بتوانند در برابر آن ثبت حسابداری کنند، و زنجیری با نهایی‌شدگی احتمالاتی این را فراهم نمی‌کند.

منبع: fullnode README; randprotocol.org (performance section); docs/architecture.md §6

۲۸. چرا راستی‌آزمایی اثبات بیرون از حلقهٔ اجماع است؟

گره هر STARK را هنگام پذیرش تراکنش (تقریباً 32 ms در حالت گرم) و پیش از بازپخش آن راستی‌آزمایی می‌کند؛ بنابراین راستی‌آزمایی هرگز روی مسیر بحرانی پیشنهاد بلوک قرار نمی‌گیرد. در نتیجه فاصلهٔ بلوک را تأخیر اجماع تعیین می‌کند و نه اندازهٔ اثبات. بررسی‌ها بر اساس هزینه مرتب شده‌اند و STARK آخر راستی‌آزمایی می‌شود، تا تراکنش ناقص پیش از گران‌ترین گام رد شود.

منبع: randprotocol.org; docs/architecture.md (‘How it works’)

۲۹. چرا وقتی همهٔ چیزهای دیگر محافظت‌شده (shielded) است، دفتر اعتبارسنج‌ها عمومی است؟

همهٔ replicaها باید دربارهٔ این‌که کدام اعتبارسنج‌ها می‌توانند پیشنهاد دهند و کدام رأی‌ها حد نصاب را تشکیل می‌دهند توافق داشته باشند، و این مستلزم عمومی بودن وزن سهام است. بنابراین دفتر مقدار سهام را آشکارا نگه می‌دارد. پیوند با مالکیت پنهان می‌ماند: وثیقه از یک یادداشت محافظت‌شده تأمین می‌شود و برداشت به یکی از آن‌ها پرداخت می‌شود، و هیچ‌یک از این دو عملیات آشکار نمی‌کند یادداشت از آنِ چه کسی است.

منبع: docs/staking.md §1

30. چرا گره در حال همگام‌سازی هر بلاک را دوباره اجرا می‌کند و به گواهی‌ها اعتماد نمی‌کند؟

گرهی که با تأخیر به شبکه می‌پیوندد، پیش از پذیرش زنجیره، هر quorum certificate را تأیید می‌کند، همه‌ی اثبات‌های bundle و call را دوباره راستی‌آزمایی می‌کند و رسیدهای حاصل را با هم مقایسه می‌کند. از آنجا که اعتبار را اثبات‌ها برقرار می‌کنند و نه امضاها به‌تنهایی، این رویه در برابر حملات بُرد بلند (long-range) که زنجیره‌های مبتنی صرفاً بر امضا را تهدید می‌کنند، آسیب‌پذیر نیست. حذف اثبات‌ها از تاریخچه رد شد، زیرا این ضمانت را از میان می‌برد.

Source: docs/architecture.md; docs/aggregation.md (introduction)

31. چرا سقف بلاک با وجود اثباتی بزرگ‌تر از 1 MB روی 4 MiB نگه داشته می‌شود؟

با سقف ثابت، اندازه‌ی بلاک نمی‌تواند رشد کند؛ وقتی تقاضا از ظرفیت فراتر رود، به‌جای آن، گذردهی محدود می‌شود (در پروفایل 80-query، سه انتقال shielded در هر بلاک). محدودیت گذردهی به‌عنوان حالت شکست امن‌تر نسبت به رشد بی‌حد اندازه‌ی بلاک ارزیابی شد. راه‌حل برگزیده تجمیع در سطح بلاک است، یعنی یک اثبات بازگشتی برای هر بلاک، و نه افزایش سقف یا کاهش سطح سلامت (soundness).

Source: docs/block-space.md §1, §6

32. چرا testnet تاریخچه را به یک روز هرس می‌کند؟

یک quorum certificate که حامل 18 امضای Dilithium2 است، تقریباً 44 KB حجم دارد و برای هر بلاک دو بار ذخیره می‌شود. با بلاک‌های عمدتاً خالی در هر 1.4 s، این به حدود 6.6 GB برای هر گره در روز می‌رسید؛ دیسک گره‌ها پر شد و زنجیره در ارتفاع 248,953 حد نصاب (quorum) را از دست داد. اکنون full nodeهای testnet تاریخچه‌ی یک روز را نگه می‌دارند، یک گره‌ی آرشیو همه‌ی آن را حفظ می‌کند و گره‌های mainnet همه‌ی آن را نگه خواهند داشت. حالت لجر (ledger) — درخت، مجموعه‌ی nullifier، رجیستر و برنامه‌ها — هرگز هرس نمی‌شود.

Source: docs/superpowers/specs/2026-09-24-history-pruning-design.md

33. چرا libp2p؟

گره از TCP همراه با Noise و Yamux، از gossipsub برای تراکنش‌ها و رأی‌ها، از Kademlia با فهرست bootstrap برای کشف همتا، از mDNS در شبکه‌های محلی و از request-response برای همگام‌سازی بلاک‌ها استفاده می‌کند. این‌ها مؤلفه‌های استاندارد و به‌طور گسترده مستقر هستند؛ از این رو گره، امتیازدهی به همتایان، اتصال مجدد و ارتقای انتقال را به ارث می‌برد و نیازی به نگه‌داری پیاده‌سازی‌های خودش ندارد.

Source: fullnode README (networking row)

Proving market and aggregation

34. چرا تجمیع اثبات در سطح بلاک؟

اگر هر bundle اثبات مخصوص خود را با حجم تقریبی 1.3 MB حمل کند، فضای بلاک به‌صورت خطی با تعداد bundleها رشد می‌کند. یک STARK بازگشتی واحد برای هر بلاک که همه‌ی N اثبات bundle را تأیید می‌کند، هزینه‌ی اثبات روی زنجیره را نسبت به N ثابت نگه می‌دارد. آنگاه validatorها یک اثبات تجمیعی را (حدود 16 ms در حالت warm) روی CPU تأیید می‌کنند؛ بنابراین سخت‌افزار معمولی همچنان می‌تواند اعتبارسنجی کند، در حالی که aggregatorها با GPU در بازاری جداگانه و بدون نیاز به مجوز برای سهم اثبات از کارمزدها و یارانه‌ی بلاک رقابت می‌کنند.

Source: docs/aggregation.md §1

35. چرا سه نقش — validator، aggregator و prover واگذارشده؟

این سه نقش نیازمندی‌های سخت‌افزاری متفاوتی دارند و طرف‌های متفاوتی هزینه‌شان را می‌پردازند. validator تراکنش‌ها را روی CPU مرتب و تأیید می‌کند و از سهم تأیید در کارمزدها دریافت می‌کند. aggregator اثبات بازگشتی بلاک را روی GPU تولید می‌کند و از سهم اثبات و یارانه‌ی بلاک دریافت می‌کند. prover واگذارشده برای فرستنده‌ای که دستگاهش از عهده‌ی این کار برنمی‌آید (مانند تلفن یا مرورگر) یک اثبات bundle تولید می‌کند و پرداخت را به‌صورت خصوصی از همان فرستنده دریافت می‌کند. جداسازی نقش‌ها اعتبارسنجی را کم‌هزینه نگه می‌دارد و اثبات‌سازی را رقابتی می‌کند.

Source: docs/prover.md §1

36. چرا prover واگذارشده نمی‌تواند وجوه را بدزدد؟

در احراز اختیار تفکیک‌شده (split authorisation)، prover کلید مشاهده‌ی nk را دریافت می‌کند، اما کلید خرج sk را نه. اثبات bundle به c = H(AUTH, nk || salt) متعهد می‌شود و اثبات احراز اختیار جداگانه‌ی کیف پول، آگاهی از sk را برای همان c نشان می‌دهد. prover بدون sk می‌تواند اثبات bundle را محاسبه کند، اما نمی‌تواند احراز اختیار معتبری تولید کند، و کیف پول پیش از ارسال، اثبات بازگشتی را تأیید می‌کند.

Source: docs/shielded.md (split authorisation); docs/prover.md §8

The bridge and zUSD

37. چرا USDT/USDC را در زنجیره‌های مبدأ قفل کنیم و stablecoin جدیدی صادر نکنیم؟

صدور بومی روی Rand ظرفیت ذخیره را به تصمیم‌های استقرار صادرکنندگان وابسته می‌کرد، تصمیم‌هایی که خارج از کنترل پروژه است. قفل کردن USDT و USDC روی Ethereum، BSC، Tron و Solana ذخایر را از زنجیره‌هایی تأمین می‌کند که این دارایی‌ها از پیش در آن‌ها در گردش‌اند و صادرکننده‌ی جدیدی وارد نمی‌کند: هر واحد zUSD ادعایی است بر USDT یا USDC نگهداری‌شده در یک قرارداد امانی که برای همگان قابل خواندن است.

Source: randprotocol.org (reserve section)

38. چرا مجموعه‌ی نگهبانان t-از-n، و چرا این را صریح بگوییم؟

گواهی (attestation) تنها شاهدی است که Rand برای وقوع قفل در زنجیره‌ای دیگر در اختیار دارد؛ بنابراین باید توسط گروهی با آستانه امضا شود و گواهی معتبر امضای بیش از دو سوم نگهبانان را لازم دارد. فرض اعتماد حاصل صراحتاً بیان می‌شود. ضمانت مؤثر، ضعیف‌تر از دو مورد یعنی توان پرداخت ذخایر و درستی پل است؛ ائتلافی از t نگهبان می‌تواند بدون قفل متناظر، ضرب (mint) را مجاز کند؛ و میزان مواجهه با ریسک به حجم امانت نگهداری‌شده در هر زنجیره محدود است. این فرض در آغاز استدلالی علیه ساخت پل بود. پس گرفته نشده، بلکه در ازای ظرفیت ذخیره پذیرفته شده است.

Source: randprotocol.org (reserve section, ‘What this costs’)

39. چرا هم‌امضای Dilithium2 در کنار گواهی ECDSA؟

زنجیره‌های مبدأ هیچ تأییدکننده‌ی امضای شبکه‌ای (lattice) ارائه نمی‌دهند؛ از این رو برداشت‌ها در آن زنجیره‌ها همچنان با ECDSA کلاسیک ایمن می‌شوند و میزان مواجهه با ریسک به حجم امانت و سقف‌ها محدود است. هر پیامی که لجر Rand از نگهبانان می‌پذیرد — واریزها و چرخش مجموعه‌ی نگهبانان — باید علاوه بر آن حامل حد نصابی از امضاهای Dilithium2 از همان نگهبانان باشد. بنابراین مسیر ضرب (mint) پساکوانتومی است، هرچند نقاط انتهایی بیرونی چنین نیستند. هم‌امضاها در کنار گواهی منتقل می‌شوند و به هیچ تغییری در قراردادهای مستقر نیاز ندارند.

Source: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1

40. چرا blinding یادداشت واریز استخراج می‌شود و انتخاب نمی‌شود؟

پیش‌تر، تعهد یادداشت واریز تا زمانی که یک relayer گواهی را ارسال کند تعیین نمی‌شد؛ از این رو دو relayer می‌توانستند همان گواهی را با یادداشت‌های متفاوت ارسال کنند. استخراج قطعی عامل blinding یعنی r از گواهی، تعهد را ثابت می‌کند؛ در نتیجه ارسال‌های رقیب روی یک تعهد واحد برخورد می‌کنند و واریز نمی‌تواند دو بار ضرب شود.

Source: docs/bridge.md (F1, chain 14)

41. چرا USDT قفل‌شده روی Tron می‌تواند روی Ethereum به‌صورت USDT خارج شود؟

zUSD مثلی (fungible) است: هر واحد ادعایی است بر ذخیره‌ی تجمیعی، نه بر زنجیره‌ای که از طریق آن وارد شده است. جداسازی ورود از خروج به نقدینگی اجازه می‌دهد به جایی برود که تقاضا وجود دارد، مشروط بر آنکه زنجیره‌ی مقصد ذخایر کافی داشته باشد. مقاله‌ی stablecoin ثابت می‌کند که پایایی S ≤ Σ_c R_c، یعنی کران‌دار بودن عرضه‌ی کل با مجموع ذخایر هر زنجیره، در هر گذار حالت حفظ می‌شود.

Source: randprotocol.org (reserve section)

42. چرا shielded بودن توزیع را پنهان می‌کند اما مقدار را نه؟

عرضه‌ی کل zUSD در رجیستر توکن عمومی است و ذخیره‌ی هر زنجیره یک موجودی عمومی است؛ بنابراین هر کسی می‌تواند توان پرداخت را راستی‌آزمایی کند؛ آنچه پنهان می‌ماند توزیع دارایی‌ها میان مالکان است. یک محدودیت وجود دارد: موجودی‌های چهار ذخیره را نمی‌توان به‌طور اتمی در یک لحظه‌ی واحد مشاهده کرد؛ از این رو برای این زنجیره‌ها بررسی، ناتوانی در پرداخت را پس از وقوع تشخیص می‌دهد و از آن پیشگیری نمی‌کند.

Source: randprotocol.org (reserve section)

43. چرا سوزاندن (burn) تنها تراکنشی است که دارایی خود را نام می‌برد؟

سوزاندن، دارایی مشخصی را روی زنجیره‌ای مشخص آزاد می‌کند؛ از این رو قرارداد امانی باید بداند کدام دارایی و کدام زنجیره. هر تراکنش دیگری دارایی‌ای ناشناس را منتقل می‌کند. سوزاندن همچنین کارمزد پل را حمل می‌کند، زیرا تنها تراکنش پلی است که فرستنده‌اش ذی‌نفع است.

Source: docs/architecture.md; docs/shielded.md §2

Compliance and disclosure

44. چرا کلیدهای مشاهده و نه «خصوصی از دید همه»؟

مقررات‌گذاران سامانه‌های حریم خصوصی را که افشا در آن‌ها به همکاری طرفِ تحت بررسی وابسته است نپذیرفته‌اند، چنان‌که پرونده‌ی Tornado Cash نشان می‌دهد. از این رو Rand افشا را یک شیء پروتکلی در نظر می‌گیرد. دارنده یا یک واسط تحت نظارت، کلید مشاهده را نزد خود نگه می‌دارد؛ حسابرس می‌تواند تراکنش‌های نام‌برده‌شده در یک درخواست قانونی را رمزگشایی کند؛ و هدف طراحی، کلیدهایی با دامنه‌ی محدود است که طرف مقابل و مبلغ را آشکار می‌کنند بی‌آنکه راهبرد معاملاتی را افشا کنند. برای کاربردهایی مانند پرداخت حقوق، این حسابرس‌پذیری یک الزام است و نه یک محدودیت.

Source: randprotocol.org/usecases (regulation section; payroll case)

45. چرا کلید مشاهده‌ی خروجی از کلید ورودی جداست؟

این جداسازی به فرستنده اجازه می‌دهد آنچه را پرداخت کرده اثبات کند، بی‌آنکه به تاریخچه‌ی گیرنده دسترسی یابد، و برعکس. کلید مشاهده‌ی خروجی ovk پاکت‌هایی را که کیف پول فرستاده رمزگشایی می‌کند؛ کلید رمزگشایی ML-KEM پاکت‌هایی را که به آن فرستاده شده رمزگشایی می‌کند؛ و کلید مخصوص هر تراکنش دقیقاً یک خروجی را برای شخص ثالث افشا می‌کند.

Source: docs/shielded.md §1–2

Known limitations

46. اثبات‌ها امروز چه چیزی را نشت می‌دهند و چرا این موضوع مستند شده است؟

بازبینی 2026-09-27 نشان داد که در guest نسخه‌ی v1 (زنجیره‌های 14–15) هر اثبات bundle آشکار می‌کند کدام اسلات‌های ورودی یادداشت واقعی دارند و وزن همینگ هر اندیس برگ خرج‌شده چقدر است. علت دوگانه است: مجموع‌های LogUp برای هر جدول بدون blinding منتشر می‌شوند و جریان کنترل guest بر اساس ساختگی بودن ورودی شاخه می‌شود. راه‌حل، یک guest بدون شاخه (v2) است که در genesis بعدی انتخاب خواهد شد. این یافته منتشر شده است، زیرا شبکه یک testnet است و مستندات به‌منزله‌ی سابقه‌ی حسابرسی آن عمل می‌کند.

Source: docs/shielded.md (‘What the proofs leak today’)

47. چرا رشد state کم‌قیمت‌گذاری شده است؟

Ethereum قیمت‌گذاری نوشتن در حافظه را بر عهده می‌گیرد، زیرا حالت ذخیره‌شده هزینه‌ای دائمی بر دوش هر node می‌گذارد. Rand در حال حاضر رشد درخت commitment، مجموعه nullifier و حافظهٔ برنامه را فقط از طریق هزینهٔ استقرار به‌ازای هر word و هزینهٔ ثابت bundle قیمت‌گذاری می‌کند. این روش برای یک testnet کافی است، اما به‌عنوان یک پرسش قیمت‌گذاری باز ثبت شده است که باید پیش از mainnet حل شود؛ حل آن به اندازه‌گیری به‌ازای هر opcode نیاز ندارد.

منبع: docs/fees.md §3 (caveats)

48. چرا هنوز هیچ ممیزی مستقل تکمیل نشده است؟

این پروتکل در حال توسعهٔ فعال روی یک testnet است که تیم آن را اداره می‌کند، و پیش از پایدار شدن طراحی، مجموعه‌های قید (constraint) و برش‌های زنجیرهٔ (chain cut) بیشتری انتظار می‌رود. وب‌سایت این موضوع را در هر صفحه بیان می‌کند. دورهای ممیزی داخلی (v3–v5) در docs/consensus.md و مشخصات طراحی منتشر شده‌اند، تا ممیزی خارجی نهایی سابقه‌ای کامل برای کار در اختیار داشته باشد.

منبع: randprotocol.org (footer); docs/consensus.md