#dusk $DUSK @Dusk حدّقتُ في مستندات Dusk قرابة أربعين دقيقة تقريبًا، وظللت أفكر مرارًا في سؤال واحد: كيف تنتهي قصّة مجموعتَي Moonlight وPhoenix هذه؟
تسير Moonlight على خطّ الحسابات العامة. تُكتب الأرصدة، والمرسل والمستقبل للتحويل والمبلغ على السلسلة، ويمكن لأي شخص رؤيتها. هذه مناسبة لسيناريوهات مثل شحن البورصات والحسابات والتطابقات المؤسسية حيث يجب أن تكون الأمور شفافة.
أما Phoenix فهي منطق مختلف تمامًا: تتحول الأصول إلى note مُشفّر، مخبّأة داخل شجرة Merkle. عندما تنفق أموالًا، لا تكشف أي note بعينها، بل ترمي nullifier مع برهان ZKP. يمكن للشبكة التحقق من أنك تملك المال ولا يحدث double-spend، لكنها لا ترى المبلغ ولا المرسل. وعند الحاجة إلى تدقيق الحسابات، يمكن استخدام viewing key للإفصاح بشكل انتقائي.
في بداية الشهر صادفت سؤالًا مشابهًا عندما كتبت ملاحظات عن تحويل SEPA—عندما تحتاج أن تقوم أنظمتان بنكيّتان بمطابقة الحسابات، كم يكون الأمر مزعجًا عندما تكون الحالات غير متطابقة! لقد كانت النتيجة أنني تعبت حتى الساعة الثانية صباحًا.
إذا كانت تقنية البلوكشين ستفعل أيضًا شيئين دفاترَ حسابات منعزلين عن بعضهما، فالأمر عندها لن يكون أفضل من التمويل التقليدي.
في ذلك الوقت كنت منزعجًا قليلًا، وشعرت أن المستند لم يوضح هذا الموضوع بقدر كافٍ. قلبت إلى قسم البنية التعاقدية في وحدة Rusk، ولم أشعر كثيرًا في أول مقطعين؛ كان الأمر مجرد وصف لهياكل البيانات الخاصة بـ Moonlight وPhoenix كل على حدة. حتى وصلت إلى المقطع الرابع، ورأيت أن تعريف واجهة Transfer Contract يستخدم نوعًا عدديًا (enum) لـ payload، عندها أدركت تصميمه المقصود.
Transfer Contract هو بوابة تنسيق. يستقبل payload بصيغ مختلفة—واحد بصيغة Moonlight وآخر بصيغة Phoenix. لا يهتمّ العقد من أين أتيت، بل بما تحمله الـ payload من حقول، ثم يوجّهها إلى منطق التحقق المناسب. يتحقق Moonlight مباشرة من حالة الحساب العام، بينما يتحقق Phoenix عبر تشغيل برهان ZK proof. بعد أن ينجح التحقق على الطرفين، يتم تسجيل النتيجة في نفس شجرة الحالة العالمية. فكّرتُ طويلًا حتى فهمت الخطوة الحاسمة في هذا الأمر: إذا دمجت شجرتَي حالة النظامين معًا في شجرة واحدة، ففي النهاية فإن تحويل أموال من حساب عام إلى note خصوصي هو مجرد تحويل لصيغة الـ payload، ولا يحتاج إلى جسر بين السلاسل، ولا إلى بروتوكول مزامنة معقد. تحديث الحالة يكون ذريًا: إما أن ينجح كل شيء، أو يُلغى بالكامل ويُعاد كما كان.
تسير Moonlight على خطّ الحسابات العامة. تُكتب الأرصدة، والمرسل والمستقبل للتحويل والمبلغ على السلسلة، ويمكن لأي شخص رؤيتها. هذه مناسبة لسيناريوهات مثل شحن البورصات والحسابات والتطابقات المؤسسية حيث يجب أن تكون الأمور شفافة.
أما Phoenix فهي منطق مختلف تمامًا: تتحول الأصول إلى note مُشفّر، مخبّأة داخل شجرة Merkle. عندما تنفق أموالًا، لا تكشف أي note بعينها، بل ترمي nullifier مع برهان ZKP. يمكن للشبكة التحقق من أنك تملك المال ولا يحدث double-spend، لكنها لا ترى المبلغ ولا المرسل. وعند الحاجة إلى تدقيق الحسابات، يمكن استخدام viewing key للإفصاح بشكل انتقائي.
في بداية الشهر صادفت سؤالًا مشابهًا عندما كتبت ملاحظات عن تحويل SEPA—عندما تحتاج أن تقوم أنظمتان بنكيّتان بمطابقة الحسابات، كم يكون الأمر مزعجًا عندما تكون الحالات غير متطابقة! لقد كانت النتيجة أنني تعبت حتى الساعة الثانية صباحًا.
إذا كانت تقنية البلوكشين ستفعل أيضًا شيئين دفاترَ حسابات منعزلين عن بعضهما، فالأمر عندها لن يكون أفضل من التمويل التقليدي.
في ذلك الوقت كنت منزعجًا قليلًا، وشعرت أن المستند لم يوضح هذا الموضوع بقدر كافٍ. قلبت إلى قسم البنية التعاقدية في وحدة Rusk، ولم أشعر كثيرًا في أول مقطعين؛ كان الأمر مجرد وصف لهياكل البيانات الخاصة بـ Moonlight وPhoenix كل على حدة. حتى وصلت إلى المقطع الرابع، ورأيت أن تعريف واجهة Transfer Contract يستخدم نوعًا عدديًا (enum) لـ payload، عندها أدركت تصميمه المقصود.
Transfer Contract هو بوابة تنسيق. يستقبل payload بصيغ مختلفة—واحد بصيغة Moonlight وآخر بصيغة Phoenix. لا يهتمّ العقد من أين أتيت، بل بما تحمله الـ payload من حقول، ثم يوجّهها إلى منطق التحقق المناسب. يتحقق Moonlight مباشرة من حالة الحساب العام، بينما يتحقق Phoenix عبر تشغيل برهان ZK proof. بعد أن ينجح التحقق على الطرفين، يتم تسجيل النتيجة في نفس شجرة الحالة العالمية. فكّرتُ طويلًا حتى فهمت الخطوة الحاسمة في هذا الأمر: إذا دمجت شجرتَي حالة النظامين معًا في شجرة واحدة، ففي النهاية فإن تحويل أموال من حساب عام إلى note خصوصي هو مجرد تحويل لصيغة الـ payload، ولا يحتاج إلى جسر بين السلاسل، ولا إلى بروتوكول مزامنة معقد. تحديث الحالة يكون ذريًا: إما أن ينجح كل شيء، أو يُلغى بالكامل ويُعاد كما كان.
