لقد قمت بمقارنة @Dusk بمحفظة جديدة وتعليمات Dusk Connect بدقة، ثم أدركت أن ما أضافوه ليس “مجرد عمل غلاف جديد لمحفظة”، بل هو طبقة الربط التي كان dApp يفتقدها دائمًا. كانت محفظة الويب القديمة قادرة على التحويل والتخزين (الاستيثاق) بشكل منفصل، لكن التطبيق لم يستطع استخدام واجهة موحّدة لاكتشاف المحفظة وطلب الحسابات وتوقيع المعاملات وإرسالها؛ لذلك كان على المطورين أن يكيّفوا التطبيق حول كل محفظة على حدة.
ما فعله Dusk Connect يشبه إلى حد كبير توحيد “غراء” هذه العملية: فالمحفظة تعتمد فكرة EIP-6963 في الاكتشاف، وتتعامل RPC حسب مساحات الأسماء مع الحسابات والتوقيع والمعاملات وطلبات الشبكة، كما تجهّز للمطوّرين اختبارات اتساق جاهزة لتنفيذ المحفظة. ومنذ البداية تتوافق المحافظ الأولى الجديدة مع واجهة الـ provider هذه، لتغطي إضافة المتصفح والسطح المكتبي والجوال؛ وتُدرج عمليات التحويل العلني والخاص، وshield/unshield، والتخزين (الاستيثاق)، واستلام العوائد، وDRC-20 وDRC-721 كلها في مسار تفاعل واحد.
أكثر نقطة يمكن أن تُضلَّلها المواد الترويجية بسهولة هي اعتبار “إتاحة المستودع” مساويةً لـ“نضج المنتج” مباشرة. لا تزال الجهة الرسمية تعطيها حاليًا تصنيف developer preview. حفظ المفتاح محليًا، واستخدام PBKDF2 وAES-GCM لواجهة الإضافة (extension)، واستخدام Stronghold وArgon2 للجانب الأصلي—كل ذلك يشكّل أساسًا أمنيًا صحيحًا. لكن التجربة الحقيقية يحددها ما يلي: استعادة الاتصال عند الانقطاع، وتلميحات/تنبيهات الأذونات، واحتياطات/ملاحظات المعاملات الفاشلة، واتساق الحالة عبر أجهزة متعددة.
وهذا أيضًا سبب أنني مؤخرًا عندما نظرت إلى #dusk ، لم أكن أركز فقط على المصطلحات البروتوكولية: فبدون طبقة اتصال محفظة مستقرة، حتى أروع العقود الخصوصية لن تكون سوى عرض توضيحي للمطور. الخطوة التالية التي تحتاجها $DUSK ليست إضافة لقطة شاشة لواجهة أكثر، بل أن يتمكن dApp تابع لطرف ثالث من الاتصال به دون عناء. عندما تحكمون على أن محفظة جديدة قابلة للاستخدام، هل تنظرون أولًا إلى قائمة الوظائف، أم إلى كيفية تعاملها في سيناريوهات الفشل؟
ما فعله Dusk Connect يشبه إلى حد كبير توحيد “غراء” هذه العملية: فالمحفظة تعتمد فكرة EIP-6963 في الاكتشاف، وتتعامل RPC حسب مساحات الأسماء مع الحسابات والتوقيع والمعاملات وطلبات الشبكة، كما تجهّز للمطوّرين اختبارات اتساق جاهزة لتنفيذ المحفظة. ومنذ البداية تتوافق المحافظ الأولى الجديدة مع واجهة الـ provider هذه، لتغطي إضافة المتصفح والسطح المكتبي والجوال؛ وتُدرج عمليات التحويل العلني والخاص، وshield/unshield، والتخزين (الاستيثاق)، واستلام العوائد، وDRC-20 وDRC-721 كلها في مسار تفاعل واحد.
أكثر نقطة يمكن أن تُضلَّلها المواد الترويجية بسهولة هي اعتبار “إتاحة المستودع” مساويةً لـ“نضج المنتج” مباشرة. لا تزال الجهة الرسمية تعطيها حاليًا تصنيف developer preview. حفظ المفتاح محليًا، واستخدام PBKDF2 وAES-GCM لواجهة الإضافة (extension)، واستخدام Stronghold وArgon2 للجانب الأصلي—كل ذلك يشكّل أساسًا أمنيًا صحيحًا. لكن التجربة الحقيقية يحددها ما يلي: استعادة الاتصال عند الانقطاع، وتلميحات/تنبيهات الأذونات، واحتياطات/ملاحظات المعاملات الفاشلة، واتساق الحالة عبر أجهزة متعددة.
وهذا أيضًا سبب أنني مؤخرًا عندما نظرت إلى #dusk ، لم أكن أركز فقط على المصطلحات البروتوكولية: فبدون طبقة اتصال محفظة مستقرة، حتى أروع العقود الخصوصية لن تكون سوى عرض توضيحي للمطور. الخطوة التالية التي تحتاجها $DUSK ليست إضافة لقطة شاشة لواجهة أكثر، بل أن يتمكن dApp تابع لطرف ثالث من الاتصال به دون عناء. عندما تحكمون على أن محفظة جديدة قابلة للاستخدام، هل تنظرون أولًا إلى قائمة الوظائف، أم إلى كيفية تعاملها في سيناريوهات الفشل؟
