يمكنني تثبيت محافظ Dusk اثنتين وإجراء تحويل DUSK صالح يغادر من المحفظة الخاطئة دون أي خطأ في السلسلة.
تبدأ المخاطرة قبل التوقيع. اكتشاف محفظة Dusk يعتمد على الأحداث، وليس على أساس المفرد (singleton). تقوم dApp بإرسال dusk:requestProvider، ويمكن لكل محفظة متوافقة أن ترد بـ dusk:announceProvider، ويحمل كل مزوّد معرف uuid ثابت وحالة ملفه الشخصي الخاصة به.
إذا اكتفيت بالاحتفاظ بـ providers[0] واستدعيت dusk_requestProfiles، فأنا حوّلت ترتيب الإعلانات إلى اختيار المحفظة. لا يزال من الممكن أن تكون المعاملة صالحة تمامًا. المزوّد الخاطئ يفتح طلب الموافقة، والملف الشخصي الخاطئ يزوّد الحساب، و dusk_sendTransaction يقوم بالتوقيع من تلك المحفظة.
لذلك لن أعتبر أبدًا أن “يوجد مزوّد Dusk” كافٍ. عندما يتوفر أكثر من مزوّد واحد، أريد أن يختار المستخدم المحفظة من خلال هويتها المُعلنة، وأن أُخزّن ذلك uuid، ثم أربط الملف الشخصي والحساب الظاهرين بهذا المزوّد المختار قبل أن أُظهر أي موافقة على التحويل.
النتيجة ليست معاملة فاشلة. إنها أسوأ لأن كل شيء يعمل.
على Dusk، يخبرني اكتشاف المزوّدين أي المحافظ موجودة. لا يخبرني أي محفظة قصد المستخدم الإنفاق منها.
#dusk $DUSK @Dusk
تبدأ المخاطرة قبل التوقيع. اكتشاف محفظة Dusk يعتمد على الأحداث، وليس على أساس المفرد (singleton). تقوم dApp بإرسال dusk:requestProvider، ويمكن لكل محفظة متوافقة أن ترد بـ dusk:announceProvider، ويحمل كل مزوّد معرف uuid ثابت وحالة ملفه الشخصي الخاصة به.
إذا اكتفيت بالاحتفاظ بـ providers[0] واستدعيت dusk_requestProfiles، فأنا حوّلت ترتيب الإعلانات إلى اختيار المحفظة. لا يزال من الممكن أن تكون المعاملة صالحة تمامًا. المزوّد الخاطئ يفتح طلب الموافقة، والملف الشخصي الخاطئ يزوّد الحساب، و dusk_sendTransaction يقوم بالتوقيع من تلك المحفظة.
لذلك لن أعتبر أبدًا أن “يوجد مزوّد Dusk” كافٍ. عندما يتوفر أكثر من مزوّد واحد، أريد أن يختار المستخدم المحفظة من خلال هويتها المُعلنة، وأن أُخزّن ذلك uuid، ثم أربط الملف الشخصي والحساب الظاهرين بهذا المزوّد المختار قبل أن أُظهر أي موافقة على التحويل.
النتيجة ليست معاملة فاشلة. إنها أسوأ لأن كل شيء يعمل.
على Dusk، يخبرني اكتشاف المزوّدين أي المحافظ موجودة. لا يخبرني أي محفظة قصد المستخدم الإنفاق منها.
#dusk $DUSK @Dusk