أول مرة رأيت تصميم نموذج التداول المزدوج، كانت لديّ أول ردّة فعل بأن الأمر معقّد قليلًا. على سلسلة واحدة يتم تشغيل نموذجين مختلفين للمعاملات: نموذج حساب ونموذج UTXO. أعطاني ذلك انطباعًا كأنني أُثبّت نظامي تشغيل على نفس الكمبيوتر. يمكنه العمل، لكن هل سيحدث تقطيع عند التبديل؟ وهل ستظهر مشكلات توافق؟ في ذلك الوقت لم أكن متأكدًا من نفسي.
لاحقًا، عندما نظرت بعناية إلى الورقة البيضاء، فهمت تدريجيًا كيف تموضع النموذجان ولماذا صُمما بهذه الطريقة.
Moonlight هو نموذج حساب شفاف، شبيه بما هو موجود في Ethereum: رصيد الحسابات يكون معلنًا، ومناسب للسيناريوهات التي تتطلب تدقيقًا شفافًا. مثلًا، تريد جهة ما أن تُثبت مقدار الأصول التي تملكها، وأن يكون اتجاه تدفق الأموال $DUSK متوافقًا؛ يمكنها ببساطة تنفيذ ذلك عبر Moonlight، حيث يكون كل شيء واضحًا للوهلة الأولى.
أما Phoenix فيسلك مسار UTXO، ويدعم نوعين من المعاملات: شفافة ومُموِّهة. لا يعني “التعمية” هنا إخفاءً كاملًا للهوية، بل يجعل من الصعب على أي طرف ثالث ربط طرفي المعاملة مباشرة ببعضهما. تذكر الورقة البيضاء أن تقنيات التشفير التي يستخدمها تشمل: توافق المفاتيح، وتشفير المنحنيات البيضاوية، وإثباتات عدم المعرفة (Zero Knowledge Proofs)، وهي حلول تشفير خضعت للتدقيق. @Dusk
تعايش النموذجين معًا يعني في جوهره توزيع متطلبات الخصوصية المختلفة على مسارات مختلفة. ما يحتاج للشفافية يمر عبر Moonlight، وما يحتاج للسرية يمر عبر Phoenix. يختار المستخدم بنفسه، والبروتوكول لا يتخذ القرار نيابةً عنه.
بعد ذلك، أدركت شيئًا مهمًا: التناقض الأساسي في هذا التصميم ليس ما إذا كانت التقنية يمكن أن تتحقق أم لا، بل هو “إعطاء المستخدم حق الاختيار”. السلاسل العامة التقليدية أعطت طريقًا واحدًا فقط للشفافية، والعملات الخاصة بالخصوصية أعطت طريقًا واحدًا للخصوصية. Dusk مهّدت الطريقين معًا، لتتمكن من اختيار المسار وفقًا للسيناريو. الثمن هو زيادة تعقيد البروتوكول، لكن المقابل هو قدرة أعلى على التكيف مع سيناريوهات مالية أكثر مرونة. #dusk
لاحقًا، عندما نظرت بعناية إلى الورقة البيضاء، فهمت تدريجيًا كيف تموضع النموذجان ولماذا صُمما بهذه الطريقة.
Moonlight هو نموذج حساب شفاف، شبيه بما هو موجود في Ethereum: رصيد الحسابات يكون معلنًا، ومناسب للسيناريوهات التي تتطلب تدقيقًا شفافًا. مثلًا، تريد جهة ما أن تُثبت مقدار الأصول التي تملكها، وأن يكون اتجاه تدفق الأموال $DUSK متوافقًا؛ يمكنها ببساطة تنفيذ ذلك عبر Moonlight، حيث يكون كل شيء واضحًا للوهلة الأولى.
أما Phoenix فيسلك مسار UTXO، ويدعم نوعين من المعاملات: شفافة ومُموِّهة. لا يعني “التعمية” هنا إخفاءً كاملًا للهوية، بل يجعل من الصعب على أي طرف ثالث ربط طرفي المعاملة مباشرة ببعضهما. تذكر الورقة البيضاء أن تقنيات التشفير التي يستخدمها تشمل: توافق المفاتيح، وتشفير المنحنيات البيضاوية، وإثباتات عدم المعرفة (Zero Knowledge Proofs)، وهي حلول تشفير خضعت للتدقيق. @Dusk
تعايش النموذجين معًا يعني في جوهره توزيع متطلبات الخصوصية المختلفة على مسارات مختلفة. ما يحتاج للشفافية يمر عبر Moonlight، وما يحتاج للسرية يمر عبر Phoenix. يختار المستخدم بنفسه، والبروتوكول لا يتخذ القرار نيابةً عنه.
بعد ذلك، أدركت شيئًا مهمًا: التناقض الأساسي في هذا التصميم ليس ما إذا كانت التقنية يمكن أن تتحقق أم لا، بل هو “إعطاء المستخدم حق الاختيار”. السلاسل العامة التقليدية أعطت طريقًا واحدًا فقط للشفافية، والعملات الخاصة بالخصوصية أعطت طريقًا واحدًا للخصوصية. Dusk مهّدت الطريقين معًا، لتتمكن من اختيار المسار وفقًا للسيناريو. الثمن هو زيادة تعقيد البروتوكول، لكن المقابل هو قدرة أعلى على التكيف مع سيناريوهات مالية أكثر مرونة. #dusk