لاحظت شيئًا ما أثناء التنقيب في تصميم معاملات @Dusk الذي غيّر طريقة تفكيري بشأن أطروحة الخصوصية الخاصة به.

الجزء المثير للاهتمام ليس فقط أن Dusk يوفّر معاملات خاصة.

بل إن Moonlight وPhoenix موجودان جنبًا إلى جنب.

Moonlight هو نموذج الحساب الشفاف: يمكن رؤية المرسل والمستلم والمبلغ على السلسلة. أما Phoenix فيتّبع المقابل تمامًا، إذ يستخدم ملاحظات مُحصّنة وإثباتات معرفة-صفرية بحيث لا تُكشف قيم المعاملات ولا المشاركون علنًا.

في البداية، بدا ذلك كتفصيل تنفيذي تقني.

لكن كلما درست الأمر أكثر، بدا لي كقرار للبنية التحتية.

النشاطات في الأسواق المالية نادرًا ما تعمل بالكامل في العلن أو بالكامل في السر. فبعض الأنشطة تحتاج إلى شفافية للتسوية أو الحفظ أو إعداد التقارير. أما معلومات أخرى، خصوصًا حجم المعاملات والأطراف المقابلة الحسّاسة، فقد تحتاج إلى سرّية.

@Dusk يفصل هذه المتطلبات عمليًا بدلًا من إجبار نموذج معاملات واحد على التعامل مع كل شيء.

وهذا يخلق توترًا مفيدًا.

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

أعتقد أن هذا أهم من الملصق المعتاد: «بلوكشين خصوصية».

السؤال الحقيقي هو ما إذا كان المطورون والتطبيقات المالية يستخدمون هذه المرونة بالفعل في سير عمل ذي معنى.

لأن وجود نموذجين للمعاملات يُعد ميزة معمارية.

أما جعل الحدود بين النشاط العام والخاص مفيدة فعليًا فهو المشكلة الأصعب.

لذلك أنا أراقب شيئًا واحدًا تالياً: هل تحوّل Dusk هذا الفصل إلى بنية تحتية مالية حقيقية، أم يبقى ميزة أنيقة في البروتوكول؟
@Dusk #dusk $DUSK