ما لفت انتباهي اليوم هو شيء كدت أفوّتُه أثناء قراءة توثيق Dusk: تقاعد معاملات Phoenix كجزء من ترقية Boreas.
افتراضي الأول كان أن ذلك صيانة بروتوكول روتينية. لكن عندما نظرت عن كثب، أدركت مدى أهمية تغييرات نموذج المعاملات بالنسبة لشبكة تركز على حالات الاستخدام المالية.
يدعم Dusk طرقًا مختلفة لنقل القيمة، بما في ذلك Moonlight للتحويلات العامة المعتمدة على الحساب، وPhoenix للتحويلات المُشفّرة. تُغيّر Boreas هذا التصميم عبر إيقاف معاملات Phoenix على مستوى الشبكة.
وهنا راودني سؤال: إذا كانت الخصوصية مهمة جدًا لدى Dusk، فلماذا يتم إزالة نموذج معاملات مُشفّرة أصلي بدلًا من مجرد تحسينه؟
يبدو أن الإجابة مرتبطة بكيفية تطور معمارية Dusk. بدلًا من الاعتماد على نوع واحد عام من المعاملات الخاصة، يشدد توثيقها الآن على أدوات خصوصية على مستوى التطبيقات مثل تدفقات الأصول السرّية، وقدرات المعرفة الصفرية، والإفصاح الانتقائي، وHedger على DuskEVM.
أجد هذا التحول مثيرًا للاهتمام لأنه يثير سؤالًا أكبر حول تصميم البلوكشين.
هل ينبغي تضمين الخصوصية في كل معاملة أساسية، أم أن التطبيقات هي من تختار آلية الخصوصية التي تحتاجها فعليًا؟
النهج الثاني قد يمنح المطورين مرونة أكبر، لكنه يضع أيضًا مسؤولية أكبر على تصميم التطبيق.
ما زلت أحاول فهم ما الذي يعنيه ذلك بالنسبة لبنية الخصوصية طويلة الأمد في Dusk. إذا انتقلت الخصوصية بشكل أكبر نحو آليات خاصة بالتطبيقات، فكيف يمكن للمطورين استخدام هذه الأدوات بشكل صحيح دون جعل النظام معقدًا بشكل غير ضروري؟
بالنسبة لي، هذا أكثر إثارة للاهتمام من مجرد وصف Boreas كتحديث بروتوكول.
إنه يبيّن أن Dusk ما زال يعمل على حل مشكلة صعبة: كيف تجعل الخصوصية عملية دون أن تجعل الشبكة أصعب في الاستخدام.
أي نهج برأيك أكثر منطقية؟ #dusk $DUSK @Dusk
افتراضي الأول كان أن ذلك صيانة بروتوكول روتينية. لكن عندما نظرت عن كثب، أدركت مدى أهمية تغييرات نموذج المعاملات بالنسبة لشبكة تركز على حالات الاستخدام المالية.
يدعم Dusk طرقًا مختلفة لنقل القيمة، بما في ذلك Moonlight للتحويلات العامة المعتمدة على الحساب، وPhoenix للتحويلات المُشفّرة. تُغيّر Boreas هذا التصميم عبر إيقاف معاملات Phoenix على مستوى الشبكة.
وهنا راودني سؤال: إذا كانت الخصوصية مهمة جدًا لدى Dusk، فلماذا يتم إزالة نموذج معاملات مُشفّرة أصلي بدلًا من مجرد تحسينه؟
يبدو أن الإجابة مرتبطة بكيفية تطور معمارية Dusk. بدلًا من الاعتماد على نوع واحد عام من المعاملات الخاصة، يشدد توثيقها الآن على أدوات خصوصية على مستوى التطبيقات مثل تدفقات الأصول السرّية، وقدرات المعرفة الصفرية، والإفصاح الانتقائي، وHedger على DuskEVM.
أجد هذا التحول مثيرًا للاهتمام لأنه يثير سؤالًا أكبر حول تصميم البلوكشين.
هل ينبغي تضمين الخصوصية في كل معاملة أساسية، أم أن التطبيقات هي من تختار آلية الخصوصية التي تحتاجها فعليًا؟
النهج الثاني قد يمنح المطورين مرونة أكبر، لكنه يضع أيضًا مسؤولية أكبر على تصميم التطبيق.
ما زلت أحاول فهم ما الذي يعنيه ذلك بالنسبة لبنية الخصوصية طويلة الأمد في Dusk. إذا انتقلت الخصوصية بشكل أكبر نحو آليات خاصة بالتطبيقات، فكيف يمكن للمطورين استخدام هذه الأدوات بشكل صحيح دون جعل النظام معقدًا بشكل غير ضروري؟
بالنسبة لي، هذا أكثر إثارة للاهتمام من مجرد وصف Boreas كتحديث بروتوكول.
إنه يبيّن أن Dusk ما زال يعمل على حل مشكلة صعبة: كيف تجعل الخصوصية عملية دون أن تجعل الشبكة أصعب في الاستخدام.
أي نهج برأيك أكثر منطقية؟ #dusk $DUSK @Dusk
