#dusk $DUSK @Dusk
مؤخرًا كنت أعدّ لمشروع قمت به، ولدي عادة تبدو غبية: لا أبدأ بتصفح تويتر ولا أبدأ بعدّ الشركاء، بل أذهب مباشرةً إلى قسم "سيناريوهات الفشل" في الوثائق.
ففي الأوقات التي تسير بسلاسة، يبدو الجميع كخبراء؛ لكن الذي يكشف نضج المنتج الحقيقي غالبًا هو ما يحدث عندما يخطئ المستخدم في شيء، أو ينقطع الإنترنت، أو تتعطل عملية المعاملة—وكيف يجهّز النظام نفسه ليستقبلك.
لنأخذ @Dusk كمثال: عندما قرأت مواد التطوير الخاصة به، كان انطباعي واضحًا أن كثافة المعلومات على الجانب الهندسي ليست منخفضة، لكن عندما تغيّر زاوية النظر من "كيف يتكامل المطورون" إلى "كيف يعيش مستخدم عادي ويمر عبر العملية كاملة"، لا تبدو التفاصيل غنية بنفس القدر.
سأركز تحديدًا على هذه الأنواع من الأمور:
① المحفظة: هل توجد مسارات تشخيص واضحة بعد فشل الاتصال؟ وكيف تتم معالجة تبديل الجهاز وتبديل الشبكة وإعادة التفويض على نحو منفصل؟
② الحساب: ما هي الصلاحيات بالضبط؟ هل يمكن تفصيل التفويض؟ وما الحالات التي يمكن سحبها يدويًا/بشكل فعّال؟
③ المعاملة: ماذا تعني Pending والفشل والمهلة (timeout) على التوالي؟ وهل ينبغي على المستخدم الانتظار أو إعادة المحاولة أم إطلاق معاملة جديدة؟
④ عبر السلاسل (Cross-chain): ماذا يحدث عندما تتعطل الأصول في الحالة المتوسطة؟ وأين يتم الاطلاع على مسار الأموال بعد الفشل؟
⑤ الخصوصية: ما بيانات المعاملات التي تكون مرئية وما التي لا تكون مرئية؟ وكيف يتأكد المستخدم مما تم كشفه فعليًا؟
⑥ الاستعادة: عندما تختفي ذاكرة المتصفح المؤقتة، أو يتغير الجهاز، أو تصبح المحفظة غير طبيعية، هل لدى المستخدم مسار واضح لإنقاذ نفسه؟
هذه الأشياء قد تبدو غير مثيرة على الإطلاق، لكنها أكثر قدرة من أي ملصق إضافي لشراكات النظام البيئي على توضيح ما إذا كان المنتج قد دخل مرحلة الاستخدام الحقيقي.
بل إنني ربما سأعدّ له نموذج ملاحظة بسيط جدًا:
اكتمال دليل التطوير: مرتفع
قابلية قراءة الـ API: جيدة نسبيًا
تغطية سيناريوهات الاستثناء: متوسطة/ضعيفة نسبيًا
إرشادات استعادة المستخدم: قيد الملاحظة
تفسير الصلاحيات: قيد الملاحظة
معالجة أعطال عبر السلاسل: قيد الملاحظة
قدرة المستخدم العادي على المساعدة الذاتية: يلزم التحقق
وبالطبع، هذا لا يعني أن مسار تقنيات Dusk فيه مشكلة. على العكس تمامًا: كلما كان الأمر يتعلق بالخصوصية وRWA والامتثال وأصول السلسلة، لا يكفي أن ننظر فقط إلى "هل يمكن تشغيله"؛ بل يجب أيضًا أن نرى "هل يمكن التعامل مع المشكلة بعد وقوعها".
والذي رفع تقييمي فعلًا، ليس أن الوثائق فجأة أصبحت أطول بضع عشرات الصفحات، بل أنني في يوم ما اكتشفت: حتى الزوايا التي لا يحب أحد الكتابة عنها مثل المعاملات الفاشلة والتفويضات الخاطئة وتعطل الأصول، هناك من شرحها بجدية.
مؤخرًا كنت أعدّ لمشروع قمت به، ولدي عادة تبدو غبية: لا أبدأ بتصفح تويتر ولا أبدأ بعدّ الشركاء، بل أذهب مباشرةً إلى قسم "سيناريوهات الفشل" في الوثائق.
ففي الأوقات التي تسير بسلاسة، يبدو الجميع كخبراء؛ لكن الذي يكشف نضج المنتج الحقيقي غالبًا هو ما يحدث عندما يخطئ المستخدم في شيء، أو ينقطع الإنترنت، أو تتعطل عملية المعاملة—وكيف يجهّز النظام نفسه ليستقبلك.
لنأخذ @Dusk كمثال: عندما قرأت مواد التطوير الخاصة به، كان انطباعي واضحًا أن كثافة المعلومات على الجانب الهندسي ليست منخفضة، لكن عندما تغيّر زاوية النظر من "كيف يتكامل المطورون" إلى "كيف يعيش مستخدم عادي ويمر عبر العملية كاملة"، لا تبدو التفاصيل غنية بنفس القدر.
سأركز تحديدًا على هذه الأنواع من الأمور:
① المحفظة: هل توجد مسارات تشخيص واضحة بعد فشل الاتصال؟ وكيف تتم معالجة تبديل الجهاز وتبديل الشبكة وإعادة التفويض على نحو منفصل؟
② الحساب: ما هي الصلاحيات بالضبط؟ هل يمكن تفصيل التفويض؟ وما الحالات التي يمكن سحبها يدويًا/بشكل فعّال؟
③ المعاملة: ماذا تعني Pending والفشل والمهلة (timeout) على التوالي؟ وهل ينبغي على المستخدم الانتظار أو إعادة المحاولة أم إطلاق معاملة جديدة؟
④ عبر السلاسل (Cross-chain): ماذا يحدث عندما تتعطل الأصول في الحالة المتوسطة؟ وأين يتم الاطلاع على مسار الأموال بعد الفشل؟
⑤ الخصوصية: ما بيانات المعاملات التي تكون مرئية وما التي لا تكون مرئية؟ وكيف يتأكد المستخدم مما تم كشفه فعليًا؟
⑥ الاستعادة: عندما تختفي ذاكرة المتصفح المؤقتة، أو يتغير الجهاز، أو تصبح المحفظة غير طبيعية، هل لدى المستخدم مسار واضح لإنقاذ نفسه؟
هذه الأشياء قد تبدو غير مثيرة على الإطلاق، لكنها أكثر قدرة من أي ملصق إضافي لشراكات النظام البيئي على توضيح ما إذا كان المنتج قد دخل مرحلة الاستخدام الحقيقي.
بل إنني ربما سأعدّ له نموذج ملاحظة بسيط جدًا:
اكتمال دليل التطوير: مرتفع
قابلية قراءة الـ API: جيدة نسبيًا
تغطية سيناريوهات الاستثناء: متوسطة/ضعيفة نسبيًا
إرشادات استعادة المستخدم: قيد الملاحظة
تفسير الصلاحيات: قيد الملاحظة
معالجة أعطال عبر السلاسل: قيد الملاحظة
قدرة المستخدم العادي على المساعدة الذاتية: يلزم التحقق
وبالطبع، هذا لا يعني أن مسار تقنيات Dusk فيه مشكلة. على العكس تمامًا: كلما كان الأمر يتعلق بالخصوصية وRWA والامتثال وأصول السلسلة، لا يكفي أن ننظر فقط إلى "هل يمكن تشغيله"؛ بل يجب أيضًا أن نرى "هل يمكن التعامل مع المشكلة بعد وقوعها".
والذي رفع تقييمي فعلًا، ليس أن الوثائق فجأة أصبحت أطول بضع عشرات الصفحات، بل أنني في يوم ما اكتشفت: حتى الزوايا التي لا يحب أحد الكتابة عنها مثل المعاملات الفاشلة والتفويضات الخاطئة وتعطل الأصول، هناك من شرحها بجدية.