#dusk $DUSK @Dusk نظرتُ هذا الأسبوع في فهرس ورقة Dusk البيضاء — الصفحة 2 من 22، ولا شيء سوى المخطط التفصيلي. لكن البنية أخبرتني شيئًا. القسم 4، "المعاملات"، ينقسم إلى قسمين: Moonlight (الصفحة 13) وPhoenix (الصفحة 14). نموذجان للمعاملات في المستند نفسه.

سأكون صريحًا بشأن ما أعرفه فعليًا مقابل ما أُخمّنُه. من الفهرس وحده، أستطيع تأكيد أن Dusk توثق نوعين من المعاملات تحت سلسلة واحدة. لم أقرأ النص الكامل لتلك الأقسام، لذلك لا أستطيع التحقق بيقين من كيفية اختلافهما آليًا — أستنتج، بناءً على نمط التسمية وأنماط الصناعة العامة، أن أحدهما يُرجّح أن يكون شفافًا/مبنيًا على الحساب، والآخر محافظًا على الخصوصية. هذا افتراض، وليس حقيقة مؤكدة من هذا المصدر.

ما هو مؤكد من الفهرس: يضمّ الإجماع ستة أقسام فرعية كاملة (3.1–3.9، الصفحات 6–11) — مقدّمو الخدمة (provisioners)، واللجان (committees)، والإثباتات (attestations)، والـ sortition، ووضع الطوارئ (emergency mode)، والبديل (fallback)، والنهائية المتجددة (rolling finality)، والحوافز (incentives). هذا هيكل كثيف حتى لجهة النهائية وحدها. لا أستطيع التحقق من الفهرس وحده ما إذا تم اختبار هذا التصميم في ظروف هجومية على نطاق واسع — وهذا يتطلب المحتوى التقني الفعلي أو عمليات التدقيق أو بيانات الشبكة الرئيسية (mainnet)، ولا يوجد أيٌّ منها أمامي الآن.

لذا فموقفي الصادق هو: يُشير هيكل الورقة إلى فصلٍ متعمَّد بين التعامل مع المعاملات الشفافة وتلك السرّية، وهو أمر مهم لسيناريوهات التمويل الخاضعة للتنظيم. لكن الادعاءات المتعلقة بتحمّل الأعطال أو صمود اللجان تحتاج إلى تحقق مستقل — تدقيقات، أو سجلّ حوادث، أو مراجعة من طرف ثالث — قبل أن أتعامل معها على أنها مُستقرّة.

هل سبق لأحد أن رأى آلية إجماع Dusk تمت مراجعتها عبر تدقيق أمني مستقل، أم أنها ما زالت معلّقة؟ $TAC.US
$SOON