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