#dusk $DUSK @Dusk كنتُ في السابق عند القيام بالمدفوعات على السلسلة اعتدتُ أن أدرج رقم الطلب ضمن حقل memo بشكلٍ عفوي، لكن بعد قراءة مستند Transaction Lifecycle الخاص بـ @Dusk اكتشفت أن هذا الأسلوب لا يمكن نقله مباشرةً. وذلك لأن بيانات معاملات Dusk تكون في علاقة اختيارٍ أحادي بين memo واستدعاء العقد ونشر العقد وblob، ولا يمكن لـ memo أن يُفترض أنه يُرفق تلقائيًا مع حمولات أخرى. وهذا الاختلاف سيؤثر بشكل مباشر على طريقة توصيل نظام الدفع. إذا كان التاجر يريد استلام المدفوعات وفي الوقت نفسه استدعاء عقد لإتمام العملية، فلن يستطيع افتراض أن بإمكانه الاستمرار في وضع رقم الطلب في memo داخل نفس معاملة الدفع. على العميل أولًا أن يحدد المهمة الرئيسية لهذه المعاملة، ثم يَصمم سجلًا موثوقًا آخر لربط الطلب. أما سيناريو ضغط الحمل (pressure场景) فهو محدد بالفعل: فبعد أن يقدّم المستخدم معاملة دفع تتضمن فعل استدعاء عقد، يعرض الواجهة الأمامية أنها أُرسلت، لكن الخلفية تُطابق الطلبات اعتمادًا على memo. النتيجة أن المبلغ يصل، لكن رقم الطلب لا يظهر كما هو متوقع، فيضطر مركز خدمة العملاء إلى البحث يدويًا عن المعاملة. قد لا تكون المشكلة أن Dusk “فقدت” البيانات، بل ربما أن جهة التكامل فرضت عادات معاملات سلسلة أخرى بشكلٍ جامد على Dusk. لذلك عند النظر إلى تكامل دفع DUSK الآن، لن أكتفي بسؤال ما إذا كان التحويل يمكن أن ينجح فقط؛ بل سأؤكد أولًا ما إذا كانت المعاملة تحمل memo أم استدعاء عقد، ثم سأتحقق مما إذا كان ربط الطلبات يمكن مراجعته بشكل مستقل. @Dusk قد كتب حدود الـ payload بوضوح، لكن الأهم هو ما إذا كانت الأمثلة ستُمكن المطورين من تجنب هذا الاستخدام الخاطئ مسبقًا—وهو الأمر الذي يستحق التحقق أكثر عندما يدخل Dusk سيناريوهات الدفع الواقعية.