أولاً، دعني أقول شيئًا صريحًا: تجربة سير عمل عقود WASM في Dusk—فتح المحرر داخل Chrome، وربط المحفظة، ثم الضغط على الترجمة/التجميع—لم أقم بتركيب أي اعتماد محلي مسبقًا قبلها أو بعدها. هذه المرة كانت السلاسة فعلًا لا تُوصف. #[contract] الماكرو تغلّف عملية التصدير والتسلسل بشكل كامل، وطبقة Contract Drivers كجسر وفّرت عليّ الكثير من الوقت الذي كنت سأقضيه في البحث عن ABI. وإذا كنت ستشغّل فقط التحويلات العامة في Moonlight، من الصفر إلى الإطلاق على الشبكة، فربما ستكون أسرع حتى من فنجان قهوتك المفلتر.
لكن الحلم/البيتكوين-دولا—تقريبًا بدأ دوبل البيتكوين—والـBTC ما زالت قوية
لكن أكثر شيء جعلني أجلس لأفكر لمدة نصف ساعة هو أنني عندما كنت أتصيد/أصلح خطأ في منطق استعلام Moonlight، أدخلت تحويلًا “مُخفى/مُحجوبًا” من نوع Phoenix في منطق الاستعلام للتأكد من التحقق.
أسلوب Dusk يمشي على رجلين: Moonlight هو دفتر حسابات شفاف، الرصيد يُودَع مباشرةً في الحساب؛ أما Phoenix فهو UTXO يضع عنوانًا غير مرئي على شكل طبقة إخفاء، وبالتالي الرصيد يكون مخفيًا داخل note. تدفق الأموال بين هذين النظامين يعتمد على Transfer Contract كأنه مترجم فوري: تحويل عام يُقابل تحويل مُخفي—يتم أولاً خصم الرصيد ثم سكّ الـnote؛ تحويل مُخفي يُقابل تحويل عام—أولاً حرق الـnote ثم زيادة الرصيد. أليس هذا المنطق واضحًا؟ لكن المشكلة تبدأ عندما تكتب واجهة الاستعلام وتريد عرض مجموع رصيدي الجهتين مرة واحدة: عندها يجب أن تتعامل مع حالتي الحساب وبيانات note المشفرة، وهما نوعان مختلفان تمامًا في الصيغة والتوقيت.
الشخص الجديد في فريقي كانت أول ردة فعله أن يجمع قيمة note كما لو كانت رصيدًا مباشرة—فشل الإرسال/أُلغيت المعاملة فور بثها، لأن note الخاصة بـPhoenix يجب أن تمرّ أولاً بعملية التحقق من إثبات الملكية لفكّ القيمة، وهذا ليس نفس تسلسل قراءة رصيد Moonlight على الإطلاق.
أما الـGas فهذه أيضًا حفرة خفية. في المعاملات العامة يمكنك تقدير التكلفة وفق منطقك المعتاد، وغالبًا ستكون النتيجة قريبة جدًا من الواقع؛ لكن في المعاملات المُخفاة يجب المرور بإنشاء وتحقق إثباتات ZK، ودرجة تعقيد دائرة الإثبات ترتبط مباشرة بعدد الـnotes داخل تلك المعاملة وبشروط القيود. جرّبت تحويل Phoenix بمعدل 2 مدخل note و3 مخرجات note، وكان استهلاك الـGas أعلى—بحوالي درجتين—مقارنةً بمعاملة عامة بنفس الحجم تقريبًا. وثوابت الـGas في الوثائق يمكن اعتبارها فقط مرجعًا للسعر الأدنى؛ قبل الإطلاق الحقيقي لن تستطيع ملء سقف الـGas بثقة ما لم تُجري عدة جولات محاكاة على شبكة الاختبار بمعلمات حقيقية. إذا ملأت أقل من اللازم تُرجع المعاملة revert، وإذا ملأت أكثر تُحرق أموالًا دون فائدة.
الشيء الذي لم أفهمه بالكامل هو أن إيضاحات Dusk الرسمية حول سيناريوهات الحافة من نوع “استعلام مختلط + استدعاء عبر نماذج” تكون خفيفة جدًا من حيث تحديد الحدود. @Dusk $DUSK #dusk
لكن الحلم/البيتكوين-دولا—تقريبًا بدأ دوبل البيتكوين—والـBTC ما زالت قوية
لكن أكثر شيء جعلني أجلس لأفكر لمدة نصف ساعة هو أنني عندما كنت أتصيد/أصلح خطأ في منطق استعلام Moonlight، أدخلت تحويلًا “مُخفى/مُحجوبًا” من نوع Phoenix في منطق الاستعلام للتأكد من التحقق.
أسلوب Dusk يمشي على رجلين: Moonlight هو دفتر حسابات شفاف، الرصيد يُودَع مباشرةً في الحساب؛ أما Phoenix فهو UTXO يضع عنوانًا غير مرئي على شكل طبقة إخفاء، وبالتالي الرصيد يكون مخفيًا داخل note. تدفق الأموال بين هذين النظامين يعتمد على Transfer Contract كأنه مترجم فوري: تحويل عام يُقابل تحويل مُخفي—يتم أولاً خصم الرصيد ثم سكّ الـnote؛ تحويل مُخفي يُقابل تحويل عام—أولاً حرق الـnote ثم زيادة الرصيد. أليس هذا المنطق واضحًا؟ لكن المشكلة تبدأ عندما تكتب واجهة الاستعلام وتريد عرض مجموع رصيدي الجهتين مرة واحدة: عندها يجب أن تتعامل مع حالتي الحساب وبيانات note المشفرة، وهما نوعان مختلفان تمامًا في الصيغة والتوقيت.
الشخص الجديد في فريقي كانت أول ردة فعله أن يجمع قيمة note كما لو كانت رصيدًا مباشرة—فشل الإرسال/أُلغيت المعاملة فور بثها، لأن note الخاصة بـPhoenix يجب أن تمرّ أولاً بعملية التحقق من إثبات الملكية لفكّ القيمة، وهذا ليس نفس تسلسل قراءة رصيد Moonlight على الإطلاق.
أما الـGas فهذه أيضًا حفرة خفية. في المعاملات العامة يمكنك تقدير التكلفة وفق منطقك المعتاد، وغالبًا ستكون النتيجة قريبة جدًا من الواقع؛ لكن في المعاملات المُخفاة يجب المرور بإنشاء وتحقق إثباتات ZK، ودرجة تعقيد دائرة الإثبات ترتبط مباشرة بعدد الـnotes داخل تلك المعاملة وبشروط القيود. جرّبت تحويل Phoenix بمعدل 2 مدخل note و3 مخرجات note، وكان استهلاك الـGas أعلى—بحوالي درجتين—مقارنةً بمعاملة عامة بنفس الحجم تقريبًا. وثوابت الـGas في الوثائق يمكن اعتبارها فقط مرجعًا للسعر الأدنى؛ قبل الإطلاق الحقيقي لن تستطيع ملء سقف الـGas بثقة ما لم تُجري عدة جولات محاكاة على شبكة الاختبار بمعلمات حقيقية. إذا ملأت أقل من اللازم تُرجع المعاملة revert، وإذا ملأت أكثر تُحرق أموالًا دون فائدة.
الشيء الذي لم أفهمه بالكامل هو أن إيضاحات Dusk الرسمية حول سيناريوهات الحافة من نوع “استعلام مختلط + استدعاء عبر نماذج” تكون خفيفة جدًا من حيث تحديد الحدود. @Dusk $DUSK #dusk