#dusk $DUSK @Dusk

دخلتُ إلى Dusk متوقّعًا أن تكون الأجزاء الأكثر إثارة هي Phoenix.

إثباتات ZK. ملاحظات مُشفّاة. مُبطِلات. كامل مكدس الخصوصية.

لكن كلما نظرتُ أكثر إلى طبقة المعاملات، شعرتُ أنني أعود إلى شيء أبسط:

لماذا تحتاج Dusk أصلًا إلى نموذج معاملات عام؟

Moonlight مصمّمة لتكون شفافة عمدًا. تستخدم حسابات عامة، وأرصدة مرئية، و nonces متسلسلة.

تسلك Phoenix الطريق المعاكس. تتحرك الأموال عبر ملاحظات مُشفّاة، وتقوم إثباتات ZK بالتحقق دون كشف تفاصيل المعاملة الأساسية.

في البداية، يبدو ذلك كتقسيم غير ضروري.

إذا كانت الخصوصية هي الهدف، فلماذا لا نجعل كل شيء خاصًا؟

عندها تبدأ الزاوية المؤسسية في أن تكون أكثر منطقًا.

فالبورصات، والأطراف المقابلة، والجهات الخاضعة للتنظيم تحتاج إلى وضوح المعاملات في سير عمل معيّن. يوضح الورقة البيضاء الخاصة بـ Dusk أن Moonlight أُدخل جزئيًا لتبسيط التكامل مع البورصات والجهات الأخرى، مع الإبقاء على Phoenix متاحة للتسوية الخاصة.

وهنا أرى أن المعمار يصبح أكثر إثارة للاهتمام.

Dusk لا تختار فعليًا بين الخصوصية والشفافية.

إنها تحاول جعلهما حالتين لنظام تسوية واحد.

يمكن للمستخدم الانتقال بين أرصدة Moonlight وملاحظات Phoenix، بدلًا من إجبار كل معاملة على نموذج واحد من حيث الرؤية.

وهذا يطرح علي سؤالًا مختلفًا:

هل الابتكار الحقيقي هنا هو خصوصية ZK نفسها، أم القدرة على تحديد متى يجب أن توجد الخصوصية؟

لأن الأسواق المالية لا تعمل بإعداد واحد للوضوح.

بعض المعلومات يجب أن تكون عامة.

وبعضها يجب أن يظل سرّيًا.

وبعضها ربما يحتاج إلى أن يكون قابلاً للإثبات فقط للطرف المخوّل برؤيته.

هذه مشكلة تصميم أصعب بكثير من مجرد إخفاء المعاملات.

لذا لم أعد مهتمًا كثيرًا بسؤال ما إذا كانت Dusk «خاصة».

أنا أسأل:

هل يمكن لسلسلة كتل أن تجعل الشفافية قابلة للبرمجة دون تحويل الخصوصية إلى استثناء؟

بالنسبة لي، هذا هو النقاش الأكثر إثارة للاهتمام بين Moonlight وPhoenix.
$BTR
$ONG