تسجّل هذه الصفحة المسوّغات وراء كل قرار تصميمي رئيسي في Rand: الخاصية التي يجب أن يوفّرها المكوّن، والافتراض الذي يوفّرها في ظله، والكلفة المقبولة في مقابلها. أُعدّت في 29 September 2026 استناداً إلى هذا الموقع وملخّص الورقة البيضاء والعقدة الكاملة المرجعية (github.com/randprotocol/fullnode: ملف README والمجلد docs/ والمجلد docs/superpowers/specs/). تشير كل إجابة إلى الوثيقة التي ورد فيها مسوّغها؛ وتشير المسارات إلى مستودع fullnode ما لم تبدأ بـ randprotocol.org.
الحالة. تعمل Rand على testnet يشغّلها الفريق المؤسس، ولم يخضع البروتوكول لتدقيق مستقل. تُنفَّذ عدة قرارات أدناه على مراحل عبر إصدارات السلسلة. جميع الأرقام قياسات للعقدة العاملة وقت الإعداد؛ ومن المتوقع أن تتغير، ويجب إعادة قياسها قبل الاستشهاد بها.
الأوليات التشفيرية
1. لماذا ML-KEM-768 (Kyber) لتشفير المذكرات؟
يُشفَّر النص الأصلي للمذكرة إلى مستلمها داخل غلاف يبقى على السجل العام إلى أجل غير محدد. ولذلك فإن سريّته خاصية غير قابلة للإلغاء (السؤال 8): فمن يحصل في أي وقت لاحق على حاسوب كمّي ذي صلة تشفيرية يستطيع فك تشفير كل غلاف تاريخي مختوم بآلية تغليف مفاتيح (KEM) قائمة على المنحنيات الإهليلجية، لأن خوارزمية Shor تحل اللوغاريتم المتقطع في زمن متعدد الحدود. وقد قُنّن ML-KEM في NIST FIPS 203، ويرتد أمانه إلى Module-LWE الذي لا تُعرف له خوارزمية كمّية فعّالة. واختير مجموعة المعاملات 768 (الفئة 3 في NIST) بوصفها موازنة بين هامش الأمان ومفتاح التغليف البالغ 1,184 بايت الذي يجب أن يحمله كل عنوان. والغلاف هو ML-KEM-768 مقترناً بـ ChaCha20-Poly1305: 1,348 بايت، أو 1,860 بايت مع حقل المذكرة النصية الثابت.
المصدر: randprotocol.org (قسم ما بعد الكم)؛ ملف README في fullnode؛ docs/shielded.md §2
2. لماذا تعهّدات Poseidon2 بدلاً من Pedersen؟
تعهّدات Pedersen مخفية إخفاءً تاماً لكنها ملزِمة حسابياً فقط، ويرتد إلزامها إلى افتراض اللوغاريتم المتقطع الذي يكسره الخصم الكمّي؛ فمن يستطيع حساب اللوغاريتمات المتقطعة يستطيع فتح التعهّد على قيمة مختلفة. ولأن التعهّد المنشور اليوم يجب أن يبقى سليماً ومخفياً طوال عمر السجل، فلا بد أن تقوم الآلية على افتراضات يُعتقد أنها صامدة أمام الخصوم الكمّيين، وهو ما يعني عملياً دالة تجزئة. وPoseidon2 دالة تجزئة موجّهة نحو الحساب الجبري (arithmetisation) ومعرّفة على حقل Goldilocks، ولذلك فإن تقييمها داخل STARK يكلّف قيوداً قليلة. وتُنشئ الدالة نفسها تعهّد المذكرة وشجرة Merkle ذات العمق 32 والمُبطِل (nullifier).
المصدر: randprotocol.org (قسم ما بعد الكم)؛ docs/shielded.md §1–2
3. لماذا دالتا تجزئة — BLAKE3 وPoseidon2؟
الدالتان مُحسَّنتان لنموذجَي كلفة مختلفين. تُستخدم Poseidon2 حيثما يجب تقييم التجزئة داخل إثبات — المذكرات وشجرة التعهّدات والمُبطِلات والجداول الداخلية لـ zkVM — لأن كلفتها تُقاس بالقيود. وتُستخدم BLAKE3 حيثما لا يوجد إثبات ويغلب الإنتاج الأصلي: تجزئات الكتل، وجذر الحالة فوق الشجرة ومجموعة المُبطِلات وسجل المصادِقين وجدول البرامج، وعناوين المصادِقين (ملخّص BLAKE3 للمفتاح العام). وPoseidon2 بطيئة نسبياً على وحدة المعالجة المركزية؛ وBLAKE3 مكلفة نسبياً في الحساب الجبري. وتُستخدم كل منهما حيث ينطبق نموذج كلفتها فقط.
المصدر: ملف README في fullnode (صف التواقيع / التجزئات)؛ docs/architecture.md
4. لماذا Dilithium2 (ML-DSA) لتواقيع المصادِقين؟
توفّر تواقيع الإجماع خاصية قابلة للتجديد (السؤال 8): فكسر الآلية لاحقاً يتيح تزوير رسائل مستقبلية لكنه لا يُبطل بأثر رجعي الكتل التي أُقرّت نهائياً، ومن ثم يمكن من حيث المبدأ استبدال الآلية قبل ظهور الخصم الكمّي. ومع ذلك اعتُمدت آلية شبكية (lattice) منذ كتلة التكوين (genesis) كي تتشارك أصوات الإجماع وتواقيع الحرّاس المشتركة في الجسر وسجل المصادِقين نوع مفتاح واحداً ما بعد كمّي. وتنفّذ العقدة مجموعة معاملات Dilithium2 من الجولة الثالثة (الحزمة 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؟
يتبع الاختيار من ثلاثة متطلبات. الأول، غياب الإعداد الموثوق: إذ تقوم السلامة (soundness) على مقاومة التصادم لدالة تجزئة فحسب، لا على سلسلة مرجعية مهيكلة ولا على منحنى صديق للاقترانات. والثاني، سلامة ما بعد كمّية مرجَّحة: فالحجّة لا تفترض اللوغاريتم المتقطع ولا الاقترانات. والثالث، التوافق مع آلية التعهّد القائمة على التجزئة في السؤال 2. أما الكلفة فهي حجم الإثبات: إذ يبلغ إثبات الحزمة نحو 1.3 MB، أي 300–600 ضعف حجم معاملة محمية في Zcash أو Monero. وقد قُبلت هذه الكلفة وتُعالج على حدة بالتجميع على مستوى الكتلة (السؤالان 31 و34).
المصدر: randprotocol.org؛ docs/block-space.md §1؛ docs/zkvm.md
6. لماذا ملف FRI ذو 80 استعلاماً بدلاً من 27؟
يوفّر ملف الإنتاج (80 استعلاماً، وعامل التوسّع 8، و20 بتاً من إثبات العمل grinding) نحو 86 بتاً من السلامة القابلة للإثبات، مقابل نحو 42 بتاً لملف الـ27 استعلاماً، بحجم إثبات أكبر 2.75 مرة. ويكاد زمن التحقق لا يتغير: 809 ms ترتفع إلى 838 ms على البارد، ونحو 16 ms على الدافئ. وقد أُعطيت الأولوية للسلامة القابلة للإثبات على حجم الإثبات، ونُقلت كلفة الحجم إلى تصميم فضاء الكتل والتجميع.
المصدر: docs/block-space.md §1، §3
7. لماذا يُذكر الادعاء ما بعد الكمّي لكل أولية على حدة لا بوصفه ‘protocol-wide 128-bit’؟
زعمت مسوّدات سابقة أمان 128 بتاً ما بعد كمّي للبروتوكول ككل. وهذا الادعاء لا يتسق مع حد Brassard–Høyer–Tapp، الذي يجد الخصم الكمّي بموجبه تصادمات في تجزئة من 256 بتاً بنحو 2^85 استعلاماً، ولذلك سُحب بدلاً من تقييده. وتذكر الورقة الآن الأمان لكل أولية ولكل دور — تجزئة نص الإثبات (transcript) من 384 بتاً، وتجزئات 256 بتاً لا تُستخدم إلا حيث تلزم مقاومة الصورة الأولية، وDilithium2، وML-KEM-768، وFRI فوق حقل ممتد — تحت افتراضَي Module-LWE وModule-SIS مع نمذجة دوال التجزئة بوصفها عرّافات عشوائية كمّية. وتجزئة نص الإثبات في العقدة هي حالياً Poseidon2؛ وتُدرج الوثائق ذلك بوصفه فجوة إعداد مفتوحة.
المصدر: randprotocol.org (قسم ما بعد الكم)
8. ما هو تصنيف ‘غير القابل للإلغاء مقابل القابل للتجديد’ ولماذا يوجّه الاختيارات؟
تكون الخاصية الأمنية غير قابلة للإلغاء إذا استطاع خصم اكتسب قدرة جديدة في أي وقت مستقبلي أن ينتهكها بأثر رجعي على بيانات نُشرت من قبل؛ وسرّية المذكرة وإخفاء التعهّد من هذا النوع، ولذلك يجب أن يكونا مقاومَين للحوسبة الكمّية وقت النشر. وتكون الخاصية قابلة للتجديد إذا أُعيد إرساؤها عند كل استخدام، بحيث يمكن استبدال الآلية قبل أن يتحقق التهديد؛ والتواقيع وسلامة الإثبات من هذا النوع. ويتبع كل اختيار لأولية في هذا القسم من تصنيف الخاصية التي تحميها.
المصدر: randprotocol.org (قسم ما بعد الكم)
المجمّع المحمي
9. لماذا نموذج مذكرات/UTXO دون حسابات أو أرصدة؟
يُنشر الرصيد في السجل القائم على الحسابات بحكم البنية؛ وإخفاؤه يتطلب تشفير الحالة وإثبات عبارات على النصوص المشفّرة، وهو أكلف بكثير. أما مجمّع المذكرات فلا يخزّن سوى التعهّدات والمُبطِلات، ولا يكشف أيٌّ منهما مالكاً ولا مبلغاً، فلا تحتوي الحالة العامة على أي معلومة عن الأرصدة. والاستثناء الوحيد هو سجل المصادِقين، إذ يجب أن تكون أوزان حصصه علنية كي تتفق النسخ المتماثلة على عضوية النصاب (السؤال 29).
المصدر: docs/shielded.md §1–2؛ docs/staking.md §1
10. لماذا يبلغ العنوان نحو 1.6 KB؟
يتكوّن العنوان المحمي من حقل المالك pk البالغ 32 بايت ومفتاح تغليف ML-KEM-768 البالغ 1,184 بايت الذي يحتاجه المرسل لختم الغلاف؛ وبترميز base58 يبلغ ذلك نحو 1,667 حرفاً. والطول نتيجة مباشرة لآلية تغليف المفاتيح (KEM) ما بعد الكمّية. ويستعيض تصميم معتمد (العناوين المحمية القصيرة، 2026-09-17) عن العنوان بمعرّف مستلم من نحو 256 بتاً يُحلّ إلى سجل قابل للتحديث، موقّع بمفتاح الإنفاق ويقدّمه المستكشف، بحيث يُجلب مفتاح التغليف بدلاً من نسخه يدوياً.
المصدر: 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، لكلٍّ منها فاصل نطاق (domain separator) خاص به. ولذلك لا يخزّن ملف المفاتيح سوى sk، والنسخة الاحتياطية قيمة واحدة، وإعادة مسح الشجرة من الورقة 0 تستعيد كل مذكرة. ولأنه لا توجد نسخة ثانية يمكن الاسترداد منها، فإن المحفظة ترفض الكتابة فوق ملف مفاتيح موجود.
المصدر: docs/shielded.md §1
12. لماذا شكل حزمة ثابت بأربعة مدخلات وأربعة مخرجات؟
يجعل الشكل الثابت كل حزمة بالحجم والبنية نفسيهما أياً كان ما تنقله. تنشر كل حزمة أربعة مُبطِلات وأربعة تعهّدات بالضبط؛ والخانات غير المستخدمة مذكرات وهمية بقيمة صفر، ويُنشر مخرج الباقي حتى عندما تكون قيمته صفراً، لأن غيابه كان سيميّز المعاملة. وكانت المواصفة الأصلية 2-in-2-out وفق Sapling. ثم وُسّعت إلى 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 والأخرى للأصل. وكان ذلك يتطلب إثباتين ويكشف لأي مراقب أي رمز جرى تحويله. أما guest الأصل المخفي فيأخذ معرّف الأصل مُدخلًا خاصًا، ولذلك لا يمكن تمييز تحويل zUSD عن دفعة بعملة RAND. ويتسع هذا الـ guest للمستوى 14 (نحو 100 ثانية و5.7 GB من الذاكرة) لأنه يقرأ مُدخلاته في حلقة تكرارية ويدمج فحص العضوية في شجرة Merkle. أما التنفيذ المفكوك بالكامل فيتطلب المستوى 16 (نحو 400 ثانية و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. لماذا تكون قيمة الإيداعات (السك، وإثبات الجسر) علنية؟
يجب احتساب القيمة الداخلة إلى المجمّع علنًا، وإثبات الجسر هو الدليل العلني على حدوث قفل مقابل في السلسلة المصدر. وتقتصر الرؤية الناتجة عن ذلك على خطوة الدخول، على نحو مماثل لمعاملة التحويل من الشفاف إلى المحمي (t-to-z) في Zcash، أما عمليات الإنفاق اللاحقة للمذكرة المودَعة فتبقى مخفية.
المصدر: docs/superpowers/specs/2026-09-11-shielded-pool-design.md؛ docs/shielded.md (جدول ما هو علني)
16. لماذا تكون المذكرة النصية (memo) حقلًا ثابتًا بحجم 512 بايت؟
يضمن الحقل ثابت الطول ألا يكشف السجل ما إذا كانت المذكرة النصية موجودة أو ما طولها: ففي سلسلة تدعم المذكرات النصية، يبلغ حجم كل مظروف ينشئ مذكرة، بما فيه المظاريف الوهمية ومظاريف الباقي، 1,860 بايت بالضبط. وتُحمل المذكرة النصية داخل المظروف المشفّر فقط، ولا تدخل أبدًا في المذكرة أو الالتزام أو الإثبات، ولا يقرؤها إلا الأطراف القادرون أصلًا على فك تشفير المذكرة. وتُفكّ المذكرة النصية المعيبة على أنها مذكرة نصية فارغة، حتى لا تجعل المذكرة نفسها غير قابلة للاسترداد.
المصدر: docs/shielded.md §2؛ docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. لماذا يكون الإثبات محليًا، وكيف لا يُخلّ المُثبِت المفوَّض بذلك؟
الإثبات نفسه هو تفويض الإنفاق: فالحزمة لا تحمل توقيعًا ولا حقل مُرسِل، ولذلك لا حاجة إلى أن يغادر مفتاح الإنفاق المحفظة. ويتطلب إثبات حزمة من المستوى 14 نحو 5.7 GB من الذاكرة، وهو ما يتجاوز قدرة الهواتف والمتصفحات، ومن هنا جاء المُثبِت المفوَّض. ويفصل التفويض المجزّأ (guest الحزمة v3، ومعامل التكوين hc_auth) بين الدورين: يتلقى المُثبِت مفتاح العرض nk فقط وينتج إثبات الحزمة، بينما تنتج المحفظة إثبات تفويض صغيرًا من المستوى 10 باستخدام sk. وبذلك يستطيع المُثبِت بناء إثبات حزمة، لكنه لا يستطيع تفويض عملية إنفاق (السؤال 36).
المصدر: docs/prover.md §1؛ docs/shielded.md (التفويض المجزّأ)؛ docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. لماذا نافذة مرساة من 256 كتلة؟
يُبنى الإثبات مقابل جذر معيّن لشجرة الالتزامات (مرساته)، ويستغرق بناء إثبات حزمة من المستوى 14 نحو 100 ثانية. ولذلك يجب أن يقبل السجل مراسيَ يبلغ عمرها عدة دقائق وقت الإرسال. وكانت النافذة 64 كتلة في المواصفة الأصلية، ثم وُسّعت إلى 256 كتلة مع تناقص الفاصل الزمني بين الكتل، للإبقاء على مدتها بالزمن الفعلي أعلى من زمن الإثبات.
المصدر: docs/shielded.md؛ docs/superpowers/specs/2026-09-11-shielded-pool-design.md
الـ zkVM والحوسبة السرية
19. لماذا RV32I بوصفها ISA للـ guest (وليس RV64)؟
تتحلل الكلمة ذات 32 بتًا إلى أربعة أطراف بايت بالضبط، والعدد الأولي 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 بتًا تُطابق حساباته بكفاءة تعليمات المعالج الأصلية ذات 64 بتًا، وتضم زمرته الضربية زمرة جزئية كبيرة من قوى العدد اثنين، كما يتطلب FRI. ومع الكلمات ذات 32 بتًا، يبقي ذلك كل صف في الأثر ضيقًا، مما يجعل الإثبات بملف الإنتاج ممكنًا على حاسوب محمول. أما السلامة (soundness) التي تُفقد بالعمل على حقل صغير فتُستعاد بسحب تحديات FRI من حقل ممتد.
المصدر: docs/zkvm.md §2؛ randprotocol.org (قسم الأداء)
21. لماذا مستويات الغاز بدلًا من قياس الغاز لكل تعليمة؟
يوجد الغاز لكل تعليمة في Ethereum لأن كل عقدة تعيد تنفيذ كل معاملة، ولأن طول التنفيذ غير محدود مسبقًا. أما في Rand فلا تنفّذ أي عقدة البرنامج: يُنفّذه المُرسِل مرة واحدة خارج السلسلة، وتتحقق العقد من STARK واحد لا تعتمد كلفة التحقق منه إلا على المستوى، لا على الحساب المنجَز. ويفرض المستوى الإنهاء، لأن تنفيذًا لا يتوقف خلال 2^t دورة لا يقبل إثباتًا عند المستوى t. ويتألف التسعير من حد أدنى ثابت إضافة إلى تقدير للغاز تحدّه الترويسة، وسعة الكتلة ميزانية بالبايت. ولا يظهر الغاز إلا داخل الـ guest الخاصين بمفسّري EVM وsBPF، بوصفه حالة خاصة، حيث تلزم محاكاة دلالات السلسلة المصدر.
المصدر: docs/fees.md §3–4؛ docs/superpowers/specs/2026-09-28-gas-model-design.md
22. لماذا يُقسَّم الأثر إلى تسعة جداول تربطها نواقل LogUp؟
كان جدول واحد متجانس سيملأ كل صف حتى عرض أعرض عملية. أما فصل الأثر إلى تسعة جداول، هي CPU والذاكرة وALU والمدى والنِّبل (nibble) و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. لماذا المحاكي هو المرجع وليس الـ AIR؟
المحاكي هو المواصفة المقروءة للآلة، والـ AIR ترميز لتلك المواصفة في صورة قيود متعددة حدود. وحيث يختلف الاثنان، يكون الـ AIR هو المخطئ بحكم التعريف. وهذا يضع التعريف المعياري في الأثر الأكثر عملية لتدقيق البشر.
المصدر: docs/zkvm.md §5
الإجماع والعقدة
27. لماذا HotStuff BFT المتسلسل؟
يوفّر HotStuff المتسلسل نهائية حتمية: فبنِصابات مرجَّحة بالحصص تتجاوز الثلثين، تصبح الكتلة نهائية متى تشكلت فوقها ثلث شهادات نصاب متتالية، ولا تُعاد هيكلة كتلة نهائية أبدًا. ويبلغ الفاصل المقيس بين الكتل 1.2 ثانية، وزمن بلوغ النهائية نحو 3.6 ثوانٍ. ويحتاج المستخدمون المؤسسيون المستهدفون إلى نهائية تسوية يسجّلون قيودهم استنادًا إليها، وهو ما لا توفره سلسلة ذات نهائية احتمالية.
المصدر: README الخاص بـ fullnode؛ randprotocol.org (قسم الأداء)؛ docs/architecture.md §6
28. لماذا يقع التحقق من الإثبات خارج حلقة الإجماع؟
تتحقق العقدة من كل STARK عند قبولها المعاملة (نحو 32 ms والمخزن دافئ)، قبل إعادة بثها، فلا يقع التحقق أبدًا على المسار الحرج لاقتراح الكتل. ولذلك يتحدد الفاصل بين الكتل بزمن استجابة الإجماع لا بحجم الإثبات. وتُرتَّب الفحوص بحسب كلفتها، ويُترك التحقق من STARK إلى الأخير، بحيث تُرفض المعاملة المعيبة قبل الخطوة الأعلى كلفة.
المصدر: randprotocol.org؛ docs/architecture.md (‘كيف يعمل’)
29. لماذا سجل المدققين (validators) علني بينما كل شيء آخر محمي؟
يجب أن تتفق جميع النسخ المتماثلة على المدققين المسموح لهم بالاقتراح وعلى الأصوات التي تشكّل نصابًا، وهو ما يتطلب أن تكون أوزان الحصص علنية. ولذلك يحتفظ السجل بمقادير الحصص مكشوفة. أما الصلة بالملكية فتبقى مخفية: إذ يُموَّل الرهن من مذكرة محمية ويُدفع السحب إلى مذكرة محمية، ولا تكشف أي من العمليتين لمن تعود المذكرة.
المصدر: docs/staking.md §1
30. لماذا تعيد العقدة المتزامنة تنفيذ كل كتلة بدلًا من الوثوق بالشهادات؟
تتحقق العقدة التي تنضم متأخرة من كل شهادة نصاب، وتعيد التحقق من كل حزمة ومن كل إثبات استدعاء، وتقارن الإيصالات الناتجة قبل قبول السلسلة. ولأن الصلاحية تثبتها البراهين لا التواقيع وحدها، فإن هذا الإجراء غير معرّض لهجمات المدى الطويل التي تصيب السلاسل المؤمَّنة بالتواقيع فقط. وقد رُفض حذف البراهين من السجل التاريخي لأنه سيُسقط هذا الضمان.
المصدر: docs/architecture.md؛ docs/aggregation.md (المقدمة)
31. لماذا يبقى سقف الكتلة 4 MiB مع أن الإثبات الواحد يتجاوز 1 MB؟
مع سقف ثابت لا يمكن أن يزداد حجم الكتلة؛ وعندما يتجاوز الطلب السعة يتحدد الأداء بدلًا من ذلك (بثلاث تحويلات محمية لكل كتلة وفق ملف 80 استعلامًا). وقد رُئي أن تحديد الإنتاجية أكثر أمانًا كنمط إخفاق من نمو الكتلة بلا حد. والعلاج المعتمد هو التجميع على مستوى الكتلة، بإثبات تعاودي واحد لكل كتلة، لا رفع السقف ولا خفض مستوى السلامة.
المصدر: 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؟
تستخدم العقدة TCP مع Noise وYamux، وgossipsub للمعاملات والأصوات، وKademlia مع قائمة تمهيد لاكتشاف الأقران، وmDNS في الشبكات المحلية، والطلب والاستجابة لمزامنة الكتل. وهذه مكوّنات قياسية واسعة الانتشار، ولذلك ترث العقدة تقييم الأقران وإعادة الاتصال وترقيات النقل بدلًا من صيانة تطبيقات خاصة بها.
المصدر: README الخاص بالعقدة الكاملة (صف الشبكات)
سوق الإثبات والتجميع
34. لماذا تجميع الإثباتات على مستوى الكتلة؟
تنمو مساحة الكتلة خطيًا مع عدد الحزم إذا حملت كل حزمة إثباتها الخاص البالغ نحو 1.3 MB. أما STARK تعاودي واحد لكل كتلة، يتحقق من جميع إثباتات الحزم الـ N، فيُبقي كلفة الإثبات على السلسلة ثابتة بالنسبة إلى N. ثم يتحقق المدقّقون من إثبات مجمَّع واحد (نحو 16 ms في حالة التسخين) على وحدة معالجة مركزية، فيبقى التحقق ممكنًا على عتاد عادي، بينما يتنافس المجمِّعون المزوَّدون بوحدات GPU في سوق منفصلة بلا إذن على حصة الإثبات من الرسوم وعلى إعانة الكتلة.
المصدر: docs/aggregation.md §1
35. لماذا ثلاثة أدوار — المدقّق والمجمِّع والمُثبِت المفوَّض؟
للأدوار الثلاثة متطلبات عتاد مختلفة، ويدفع لها أطراف مختلفون. يرتّب المدقّق المعاملات ويتحقق منها على وحدة معالجة مركزية، ويُدفع له من حصة التحقق من الرسوم. ويُنتج المجمِّع إثبات الكتلة التعاودي على GPU، ويُدفع له من حصة الإثبات ومن الإعانة. ويُنتج المُثبِت المفوَّض إثبات حزمة واحدة لمرسِل لا يستطيع جهازه ذلك (هاتف أو متصفح)، ويدفع له ذلك المرسِل بصورة خاصة. وفصل الأدوار يُبقي التحقق منخفض الكلفة ويجعل الإثبات تنافسيًا.
المصدر: docs/prover.md §1
36. لماذا لا يستطيع المُثبِت المفوَّض سرقة الأموال؟
في التفويض المنفصل يتلقى المُثبِت مفتاح العرض nk ولا يتلقى مفتاح الإنفاق sk. يلتزم إثبات الحزمة بالقيمة c = H(AUTH, nk || salt)، ويُثبت إثبات التفويض المنفصل الصادر عن المحفظة معرفةَ sk للقيمة c نفسها. وبغير sk يستطيع المُثبِت حساب إثبات الحزمة لكنه لا يستطيع إنتاج تفويض صالح، وتتحقق المحفظة من الإثبات المُعاد قبل إرساله.
المصدر: docs/shielded.md (التفويض المنفصل)؛ docs/prover.md §8
الجسر وzUSD
37. لماذا قفل USDT/USDC على سلاسلهما الأصلية بدلًا من إصدار عملة مستقرة جديدة؟
كان الإصدار الأصلي على Rand سيجعل سعة الاحتياطي رهنًا بقرارات الجهات المصدِرة بشأن النشر، وهي قرارات خارجة عن سيطرة المشروع. أما قفل USDT وUSDC على Ethereum وBSC وTron وSolana فيستمد الاحتياطيات من السلاسل التي يتداول عليها هذان الأصلان أصلًا، ولا يُدخل جهة مصدِرة جديدة: فكل وحدة zUSD مطالبة بـ USDT أو USDC محفوظ في عقد حفظ يمكن لأي أحد قراءته علنًا.
المصدر: randprotocol.org (قسم الاحتياطي)
38. لماذا مجموعة حراس بعتبة t من n، ولماذا التصريح بذلك بوضوح؟
الشهادة هي الدليل الوحيد المتاح لـ Rand على حدوث قفل على سلسلة أخرى، ولذلك يجب أن توقّعها مجموعة ذات عتبة؛ وتتطلب الشهادة الصالحة تواقيع أكثر من ثلثي الحراس. ويُصرَّح بافتراض الثقة الناتج صراحةً. فالضمان الفعلي هو الأضعف بين ملاءة الاحتياطي وسلامة الجسر؛ ويستطيع ائتلاف من t حارسًا أن يأذن بسكّ العملة دون قفل مقابل؛ ويتحدد التعرض بالأصول المحفوظة على كل سلسلة. وكان هذا الافتراض في الأصل الحجة ضد بناء جسر. وهو لم يُسحب، بل قُبل مقابل سعة الاحتياطي.
المصدر: randprotocol.org (قسم الاحتياطي، «ما كلفة ذلك»)
39. لماذا توقيع مشترك بـ Dilithium2 إلى جانب شهادة ECDSA؟
لا توفر السلاسل المصدر مدقّقًا لتواقيع الشبكات الشبكية، ولذلك تبقى عمليات الإفراج على تلك السلاسل مؤمَّنة بـ ECDSA التقليدي، مع تحديد التعرض بالأصول المحفوظة والسقوف. ويجب أن تحمل كل رسالة يقبلها سجل Rand من الحراس — الإيداعات وتدوير مجموعات الحراس — فوق ذلك نصابًا من تواقيع Dilithium2 من الحراس أنفسهم. وبذلك يكون مسار السكّ مقاومًا للحوسبة الكمّية رغم أن النقاط الخارجية ليست كذلك. وتُرسَل التواقيع المشتركة بجانب الشهادة ولا تتطلب أي تغيير في العقود المنشورة.
المصدر: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. لماذا يُشتق تعمية ملاحظة الإيداع بدلًا من اختيارها؟
كان التزام ملاحظة الإيداع سابقًا غير محدد إلى أن يرسل مرحِّل الشهادة، فكان بوسع مرحِّلَين إرسال الشهادة نفسها بملاحظتين مختلفتين. أما اشتقاق عامل التعمية r اشتقاقًا حتميًا من الشهادة فيثبّت الالتزام، فتتصادم الإرسالات المتنافسة على التزام واحد، ولا يمكن سكّ الإيداع مرتين.
المصدر: docs/bridge.md (F1، chain 14)
41. لماذا يمكن لـ USDT المقفل على Tron أن يخرج بصورة USDT على Ethereum؟
zUSD قابل للاستبدال: فكل وحدة مطالبة بالاحتياطي المجمَّع، لا بالسلسلة التي دخلت عبرها. وفصل الدخول عن الخروج يتيح انتقال السيولة إلى حيث يوجد الطلب، بشرط أن تحتفظ سلسلة الوجهة باحتياطيات كافية. وتُثبت ورقة العملة المستقرة أن الثابت S ≤ Σ_c R_c، أي أن إجمالي العرض محدود بمجموع احتياطيات السلاسل، يُحفظ في كل انتقال حالة.
المصدر: randprotocol.org (قسم الاحتياطي)
42. لماذا يخفي الحجب التوزيع ولا يخفي الكمية؟
إجمالي عرض zUSD علني في سجل الرموز، واحتياطي كل سلسلة رصيد علني، ولذلك يستطيع أي أحد التحقق من الملاءة؛ والمخفي هو توزيع الحيازات بين المالكين. وينطبق قيد واحد: لا يمكن رصد أرصدة الاحتياطي الأربعة ذريًا في لحظة واحدة، ولذلك يكشف الفحص في تلك السلاسل العجز عن الوفاء بعد وقوعه بدلًا من منعه.
المصدر: randprotocol.org (قسم الاحتياطي)
43. لماذا يكون الحرق المعاملة الوحيدة التي تسمّي أصلها؟
يُفرج الحرق عن أصل محدد على سلسلة محددة، ولذلك يجب أن يعرف عقد الحفظ أي أصل وأي سلسلة. أما كل معاملة أخرى فتنقل أصلًا غير محدد الهوية. ويحمل الحرق أيضًا رسم الجسر، لأنه المعاملة الوحيدة في الجسر التي يكون مرسِلها هو المستفيد.
المصدر: docs/architecture.md؛ docs/shielded.md §2
الامتثال والإفصاح
44. لماذا مفاتيح العرض بدلًا من «خاص عن الجميع»؟
لم يقبل المنظِّمون أنظمة الخصوصية التي يتوقف فيها الإفصاح على تعاون الطرف الخاضع للتحقيق، كما تُظهر حالة Tornado Cash. ولذلك تعامل Rand الإفصاح بوصفه كائنًا في البروتوكول. يحتفظ الحامل، أو وسيط منظَّم، بمفتاح عرض؛ ويستطيع المدقِّق فك تشفير المعاملات المسمّاة في طلب قانوني؛ والهدف التصميمي مفاتيح محدودة النطاق تكشف الطرف المقابل والمبلغ دون كشف استراتيجية التداول. وفي تطبيقات مثل الرواتب، تكون قابلية التدقيق هذه شرطًا لا قيدًا.
المصدر: randprotocol.org/usecases (قسم التنظيم؛ حالة الرواتب)
45. لماذا يُفصل مفتاح العرض الصادر عن الوارد؟
يتيح الفصل للمرسِل أن يثبت ما دفعه دون أن يطّلع على سجل المستلم، والعكس صحيح. فمفتاح العرض الصادر ovk يفك تشفير المظاريف التي أرسلتها المحفظة؛ ومفتاح فك التغليف في ML-KEM يفك تشفير المظاريف المرسَلة إليه؛ ومفتاح خاص بكل معاملة يكشف مخرجًا واحدًا بعينه لطرف ثالث.
المصدر: docs/shielded.md §1–2
القيود المعروفة
46. ما الذي تسرّبه البراهين اليوم، ولماذا يُوثَّق ذلك؟
وجدت مراجعة 2026-09-27 أنه في ظل الضيف v1 (السلسلتان 14–15) يكشف كل إثبات حزمة أي خانات إدخال تحمل ملاحظات حقيقية ووزن هامينغ لفهرس كل ورقة مُنفَقة. والسبب مزدوج: تُنشر مجاميع LogUp لكل جدول دون تعمية، ويتفرع تدفق التحكم في الضيف بحسب ما إذا كان الإدخال وهميًا. والعلاج ضيف خالٍ من التفرع (v2)، يُختار عند التكوين الأول التالي. وتُنشر النتيجة لأن الشبكة testnet ولأن التوثيق يُعدّ سجل تدقيقها.
المصدر: docs/shielded.md («ما الذي تسرّبه البراهين اليوم»)
47. لماذا تُسعَّر زيادة الحالة بأقل من كلفتها؟
Ethereum تسعّر عمليات الكتابة إلى التخزين لأن الحالة المخزَّنة تفرض كلفة دائمة على كل عقدة. أما Rand فتسعّر حاليًا نموّ شجرة الالتزامات ومجموعة المُبطِلات (nullifiers) وتخزين البرامج عبر رسم النشر لكل كلمة ورسم الحزمة الثابت فقط. وهذا كافٍ لشبكة testnet، لكنه مسجَّل بوصفه مسألة تسعير مفتوحة يجب حسمها قبل mainnet-beta؛ ولا يتطلب حسمها قياسًا لكلفة كل شيفرة تشغيل على حدة.
المصدر: docs/fees.md §3 (caveats)
48. لماذا لم يكتمل أي تدقيق مستقل حتى الآن؟
البروتوكول قيد التطوير النشط على شبكة testnet يشغّلها الفريق، ومن المتوقع إدخال مجموعات قيود إضافية وإصدارات جديدة للسلسلة قبل أن يستقر التصميم. ويذكر الموقع ذلك في كل صفحة. وتُنشر جولات التدقيق الداخلي (v3–v5) في docs/consensus.md ومواصفات التصميم، ليجد التدقيق الخارجي المرتقب سجلًا كاملًا يستند إليه.
المصدر: randprotocol.org (footer); docs/consensus.md