#dusk أنا منزعج لأن رتبتي لا تتحسن، جرّبت كل شيء الآن انتهيت $TREE n $HEMI هل النجم الصاعد اليوم

قضيت مهمة الغسق في التنقيب عبر تحديث هندسي وتعطلت بسبب آلية تحويل لم أكن قد فكرت فيها حقًا: لا يَجب على عقد ذكي قبول DUSK فقط لأن عقدًا آخر يرسله.
أضاف Dusk transfer_to_contract، حيث يمكن لعقد واحد تحويل DUSK إلى عقد آخر وإرفاق بيانات عشوائية بالنداء. يحق للعقد المستلم فحص تلك البيانات ثم قبول التحويل أو رفضه.
يبدو الأمر صغيرًا. لكنه ليس كذلك.
في نموذج التحويل المعتاد، تُعامل الأموال الواردة على أنها شيء سلبي. إذا أرسل شخص قيمة إلى عنوان، تصل القيمة. هنا، يمكن أن يصبح الاستلام جزءًا من منطق التطبيق. يمكن للعقد أن يقول فعليًا: “أقبل هذا الدفع فقط إذا كانت المعلومات المرفقة به تَستوفي قواعدي.”
عدت مرارًا إلى ما يعنيه ذلك لعمليات سير العمل المالية. قد يحتاج الدفع إلى أن يتوافق مع تعليمات أو حالة أو شرط معيّن قبل أن تعتبره أداة الاستقبال صالحًا. بدلًا من قبول الأموال أولًا ثم معرفة ما كانت عليه لاحقًا، يمكن للمستلم أن يجعل القبول جزءًا من التنفيذ نفسه.
هذا أنظف، لكن أيضًا يعني أن المدفوعات لم تعد محايدة عالميًا كما كانت. للعقد الوجه سلطة في إتمام التحويل، ومن الممكن أن تؤدي منطق قبولٍ سيئ التصميم إلى رفض تدفقات شرعية تمامًا.
الغريب أن الجزء المثير للاهتمام ليس أن العقود يمكنها إرسال الأموال. هذا متوقع. المثير هو أن جهة الاستلام تحصل على صوت.
فهل قبول الاستقبال الصريح هو العنصر البدائي الصحيح لعقود مالية تحتاج إلى مدفوعات مشروطة، أم أن السماح للعقود برفض القيمة الواردة يضيف تعقيدًا إلى شيء يجب أن يظل بسيطًا مثل التحويلات؟
#dusk $DUSK @Dusk

المدفوعات الشرطية لـ DUSK: عنصر بدائي أفضل أم تعقيد إضافي؟