#dusk $DUSK @Dusk Boreas تمت ترقية الشبكة على شبكة الاختبار في مايو، وكانت أول ردة فعلي: بما أن الشبكة الرئيسية لم تُطلق بعد، هل سأرتفع؟ تحققت، فالشبكة الرئيسية أصدرت كتلًا بالفعل في 7 يناير 2025، وأنا كنت متأخرًا ثمانية أشهر.
أثناء قراءة الوثائق، الجزء الخاص بـ Phoenix جعلني أجلس بذهني. كنت أعتقد أن سلاسل الخصوصية نوعان فقط: Monero كلها مظلمة، وEthereum كلها شفافة. لكن Phoenix تقع في المنتصف، في مكان متعجرف/ملتوٍ بشكل خاص. تُحوَّل الأموال إلى notes مشفرة، ثم تُرسل المعاملة، لا يتحقق المدقق من المبلغ ولا من عنوان المُرسل/المستقبل. كل ما يهمه هو إثبات معرفة صفرية (Zero-Knowledge Proof)، يثبت عدم وجود double-spend وأن الرصيد كافٍ. حينها فكرت: أليس هذا منطق العملات الخصوصية العادي؟
لكن إلى أن قلبت تقرير التدقيق، رأيت عبارة: «يُتحقق فقط من صحة الإثبات، ولا يُتحقق من ربط الإثبات بمعاملات إدخال/إخراج المعاملة». قرأتها ثلاث مرات حتى أدركت. المدقق يراقب أن «هذه المسألة حُلّت بشكل صحيح»، وليس أن «هذه المسألة هي التي قدّمتها له تحديدًا». هذان أمران مختلفان.
هذا الفرق أرعبني. إذا لم تكن علاقة الربط محكمة، يمكن للمهاجم تمامًا أن يستخدم إثباتًا شرعيًا من معاملة قانونية للتحقق من معاملة غير قانونية أخرى. وسيمرر المدقق أيضًا، لأنك حللت مسألة رياضية بشكل صحيح.
ثم ذهبت لأتفحص منطق تحقق Plonk. التحقق من المساواة يتم عبر طبقة كثيرات الحدود للتأكد من سلامة الحسابات، لكن ما إذا كانت محتويات الإثبات تطابق فعلاً مدخلات ومخرجات تلك المعاملة يعتمد كليًا على قيود الترميز (coding constraints). إن تسللت فحوص ناقصة داخل الدائرة، فسيُقبل الإثبات. كنت أظن أن صعوبة سلاسل الخصوصية تكمن في قوة التشفير كفاية أو لا، ثم اكتشفت أن الصعوبة الحقيقية هي: «هل يتحقق المدقق من الشيء الذي تدّعي أنك تريد التحقق منه، أم لا؟»
بدون Phoenix، لدى Dusk مساران فقط لـ RWA: إما أن لا تستطيع المؤسسات على السلسلة الشفافة نشره، أو أن الإشراف/الرقابة يُغلق كل شيء على السلسلة السوداء بالكامل. حل view key لتقسيم الرؤية يعالج المشكلة، لكن بشرط أن يكون المدقق يتأكد فعلاً من المعاملة نفسها. الاتجاه صحيح، وحتى NPEX الـ 300 مليون يورو أيضًا قيد التشغيل. لكن في النهاية، الأمان يعتمد على تثبيت كل القيود بإحكام؛ حتى لو كانت الرياضيات جميلة جدًا، فإذا لم تتحملها الكود، فستكون بلا فائدة.
أثناء قراءة الوثائق، الجزء الخاص بـ Phoenix جعلني أجلس بذهني. كنت أعتقد أن سلاسل الخصوصية نوعان فقط: Monero كلها مظلمة، وEthereum كلها شفافة. لكن Phoenix تقع في المنتصف، في مكان متعجرف/ملتوٍ بشكل خاص. تُحوَّل الأموال إلى notes مشفرة، ثم تُرسل المعاملة، لا يتحقق المدقق من المبلغ ولا من عنوان المُرسل/المستقبل. كل ما يهمه هو إثبات معرفة صفرية (Zero-Knowledge Proof)، يثبت عدم وجود double-spend وأن الرصيد كافٍ. حينها فكرت: أليس هذا منطق العملات الخصوصية العادي؟
لكن إلى أن قلبت تقرير التدقيق، رأيت عبارة: «يُتحقق فقط من صحة الإثبات، ولا يُتحقق من ربط الإثبات بمعاملات إدخال/إخراج المعاملة». قرأتها ثلاث مرات حتى أدركت. المدقق يراقب أن «هذه المسألة حُلّت بشكل صحيح»، وليس أن «هذه المسألة هي التي قدّمتها له تحديدًا». هذان أمران مختلفان.
هذا الفرق أرعبني. إذا لم تكن علاقة الربط محكمة، يمكن للمهاجم تمامًا أن يستخدم إثباتًا شرعيًا من معاملة قانونية للتحقق من معاملة غير قانونية أخرى. وسيمرر المدقق أيضًا، لأنك حللت مسألة رياضية بشكل صحيح.
ثم ذهبت لأتفحص منطق تحقق Plonk. التحقق من المساواة يتم عبر طبقة كثيرات الحدود للتأكد من سلامة الحسابات، لكن ما إذا كانت محتويات الإثبات تطابق فعلاً مدخلات ومخرجات تلك المعاملة يعتمد كليًا على قيود الترميز (coding constraints). إن تسللت فحوص ناقصة داخل الدائرة، فسيُقبل الإثبات. كنت أظن أن صعوبة سلاسل الخصوصية تكمن في قوة التشفير كفاية أو لا، ثم اكتشفت أن الصعوبة الحقيقية هي: «هل يتحقق المدقق من الشيء الذي تدّعي أنك تريد التحقق منه، أم لا؟»
بدون Phoenix، لدى Dusk مساران فقط لـ RWA: إما أن لا تستطيع المؤسسات على السلسلة الشفافة نشره، أو أن الإشراف/الرقابة يُغلق كل شيء على السلسلة السوداء بالكامل. حل view key لتقسيم الرؤية يعالج المشكلة، لكن بشرط أن يكون المدقق يتأكد فعلاً من المعاملة نفسها. الاتجاه صحيح، وحتى NPEX الـ 300 مليون يورو أيضًا قيد التشغيل. لكن في النهاية، الأمان يعتمد على تثبيت كل القيود بإحكام؛ حتى لو كانت الرياضيات جميلة جدًا، فإذا لم تتحملها الكود، فستكون بلا فائدة.
