أطلقت Dusk للتو محفظة وSDK، لكن لماذا لم تفعل ذلك بالطريقة التي يفعل بها السوق؟ هذا الجزء هو الذي يستحق القراءة

معظم ما كتبته عن Dusk في هذه الحملة دار حول البروتوكول: الإصدار الأصلي (native issuance)، نموذج الخصوصية، والشركاء المؤسسيين. لكن هناك شيئًا واحدًا كنت أتجاوزه دائمًا—وهو الشيء الذي يحدد إن كان أي بروتوكول سيُستخدم فعلًا من قِبل المُطوّرين: تجربة المطوّر (Developer Experience).

في أبريل 2026، قامت Dusk بشحن النسخة التجريبية من Dusk Wallet وDusk Connect SDK. امتدادات لـ Chrome وFirefox، بقاعدة كود واحدة، تدعم الحسابات العامة والمشفّرة (shielded) ضمن واجهة واحدة.

واجهة برمجة مزوّد الخدمة (Provider API) مبنية على EIP-1193—وهي الواجهة الدقيقة التي تستخدمها MetaMask—وهي مألوفة لمعظم مطوري Web3. وبما أن Dusk ليست EVM، فإن الطرق تستخدم بادئة dusk_*، وبروتوكول الاكتشاف قائم على الأحداث (event-based)، لذلك يمكن لعدة محافظ متوافقة أن تتعايش في الصفحة نفسها دون تعارض.

المحرّك (driver) هو الجزء الأكثر تميزًا: يقوم المطورون بنشر عقد ذكي إلى جانب «driver» يقوم المستخدمون بتثبيته داخل المحفظة للتفاعل بالطريقة نفسها التي قصدها المطور. وهذا يحل مشكلة حقيقية: كانت إثباتات ZK تتطلب مفاتيح prover أثقل من 200MB في الأصل. قامت المجموعة بضغطها إلى بضعة KB باستخدام تقنية توصيف الدوائر (circuit descriptor).

كما يوضح ذلك لماذا لم تتبع Dusk اتجاه «المحفظة المدمجة» السائد في 2026—حيث يقوم المستخدمون بتسجيل الدخول عبر البريد الإلكتروني أو Google ويتم إنشاء محفظة تلقائيًا خلف الـ SDK. هذا النموذج يجعل توليد إثباتات ZK يتم على خادم طرف ثالث. مع Dusk، يجب تشغيل الإثباتات على جهاز العميل (client-side)، ولا يمكنك تفويض ذلك مع الحفاظ على نموذج الخصوصية.

السؤال الذي أضعه في اعتباري: إن معدل قيام المُنشئين الحقيقيين بنشر dApps سيكون مقياسًا أكثر صدقًا من أي معيار لأداء البروتوكول.
@Dusk $DUSK #dusk $BTC $BNB

#dusk @Dusk