#dusk $DUSK @Dusk
كان والدي يدير دفاتر منفصلة لمتجره الصغير لسنوات: دفترًا للمبيعات النقدية، ودفترًا للحسابات الائتمانية. سألته مرة لماذا لا يجمعهما. قال إن النقد يحتاج إلى البساطة والسرعة الفورية، أما الائتمان فيحتاج إلى تتبع الشروط والمتابعات، وفرض نظام واحد ليقوم بالمهمتين سيجعل الأمور أسوأ في كلتا الوظيفتين.
ظننت أن Dusk في النهاية سيتقارب إلى نموذج واحد للمعاملات، كما تستقر معظم السلاسل على نهجٍ واحد. لكن هذا الافتراض انهار عندما تتبعت فعليًا سبب وجود Moonlight وPhoenix معًا.
Moonlight قائم على الحسابات، علني ومباشر — تصف وثائق Dusk أنه النموذج الخاص بالأرصدة ومنطق التطبيق الذي لا يحتاج إلى تمويه. بينما يعتمد Phoenix على نهج UTXO، وهو موجود تحديدًا لدعم تدفقات موجهة نحو الخصوصية: التحويلات المُحصَّنة، والإفصاح الانتقائي، وهي الأجزاء التي يحتاجها التمويل المُنظَّم فعليًا عندما لا يكون قبول الشفافية الكاملة ممكنًا.
إن دمجهما في نموذج واحد يعني إما إجبار كل معاملة على تحمل عبء الخصوصية غير الضروري، أو سحب خيارات التمويه من أي شخص يحتاجها.
الاختبار الحقيقي لـ DUSK هو ما إذا كان الاحتفاظ بالنموذجين يخدم فعلًا المطورين الذين يحتاجون إلى ضمانات مختلفة لتدفقات مختلفة، بدلًا من مجرد إضافة تعقيدٍ مفاهيمي غالبية المستخدمين لا يتعاملون معه أصلًا.
ما لم أجده موثقًا في أي مكان هو مدى شيوع احتياج تطبيق واحد فعلًا إلى النموذجين معًا في الواقع.
كان والدي يدير دفاتر منفصلة لمتجره الصغير لسنوات: دفترًا للمبيعات النقدية، ودفترًا للحسابات الائتمانية. سألته مرة لماذا لا يجمعهما. قال إن النقد يحتاج إلى البساطة والسرعة الفورية، أما الائتمان فيحتاج إلى تتبع الشروط والمتابعات، وفرض نظام واحد ليقوم بالمهمتين سيجعل الأمور أسوأ في كلتا الوظيفتين.
ظننت أن Dusk في النهاية سيتقارب إلى نموذج واحد للمعاملات، كما تستقر معظم السلاسل على نهجٍ واحد. لكن هذا الافتراض انهار عندما تتبعت فعليًا سبب وجود Moonlight وPhoenix معًا.
Moonlight قائم على الحسابات، علني ومباشر — تصف وثائق Dusk أنه النموذج الخاص بالأرصدة ومنطق التطبيق الذي لا يحتاج إلى تمويه. بينما يعتمد Phoenix على نهج UTXO، وهو موجود تحديدًا لدعم تدفقات موجهة نحو الخصوصية: التحويلات المُحصَّنة، والإفصاح الانتقائي، وهي الأجزاء التي يحتاجها التمويل المُنظَّم فعليًا عندما لا يكون قبول الشفافية الكاملة ممكنًا.
إن دمجهما في نموذج واحد يعني إما إجبار كل معاملة على تحمل عبء الخصوصية غير الضروري، أو سحب خيارات التمويه من أي شخص يحتاجها.
الاختبار الحقيقي لـ DUSK هو ما إذا كان الاحتفاظ بالنموذجين يخدم فعلًا المطورين الذين يحتاجون إلى ضمانات مختلفة لتدفقات مختلفة، بدلًا من مجرد إضافة تعقيدٍ مفاهيمي غالبية المستخدمين لا يتعاملون معه أصلًا.
ما لم أجده موثقًا في أي مكان هو مدى شيوع احتياج تطبيق واحد فعلًا إلى النموذجين معًا في الواقع.
Genuinely useful split
67%
Unnecessary overhead
33%
3 الأصوات • تمّ إغلاق التصويت