لفت انتباهي وجود دالتين مُرسِل في عقود Dusk الذكية: caller() و public_sender(). تبدوان كطريقتين للإجابة عن السؤال نفسه، من الذي بدأ هذا الإجراء، لكنهما قد تشير إلى جهات فاعلة مختلفة. هذه التفرقة مهمة مع سعي Dusk إلى نقل الأسواق المالية إلى السلسلة (onchain) عبر مؤسسات مُرخّصة من الاتحاد الأوروبي، حيث يجب أن تستمر صلاحية/تفويض التصرف عبر تفاعلات تعاقدية أكثر تعقيدًا دون فقد تتبّع الجهة الفاعلة الأصلية. caller() يحدد العقد الذي يقوم بالنداء المباشر، بينما public_sender() يمكنه ما يزال أن يشير إلى حساب Moonlight الذي بدأ المعاملة.
ما لا أعرفه بعد هو ما إذا كانت عقود Dusk ستقوم دائمًا بتفويض المستخدم الذي بدأ الإجراء فعليًا، أم أن إضافة عقود وسيطة يمكنها أن تغيّر خفيةً أي هوية يرى منطق التفويض. الآليات التي تستحق المراقبة واضحة نسبيًا: عندما تعتمد العقود على caller()، وعندما تعتمد على public_sender()، وما الذي يحدث بمجرد أن يجلس batchers أو forwarders في المنتصف.
إن نجاح معاملة ما لا يكفي للإجابة عن ذلك. الاختبار الأقوى هو ما إذا كانت قواعد التفويض نفسها ما تزال تشير إلى الجهة الفاعلة المقصودة حتى عندما تتغير مسار التنفيذ.
يهِمّني أقل عدد العقود الوسيطة التي يمر عبرها إجراء ما، بقدر ما يهمني أن يبقى التفويض يحلّ إلى الجهة التي بدأت الإجراء فعليًا.
يهم ذلك لأن إضافة وسيط قد تغيّر من الذي يراه عقدٌ ما دون تغيير من الذي فوّض فعليًا الإجراء.
السؤال هو ما إذا كان بإمكان Dusk إضافة مسارات تنفيذ أكثر قابلية للتأليف (composable) دون جعل التفويض يعتمد على أي عقدٍ يقع في المنتصف.
أنا أراقب كيفية استخدام caller() و public_sender() مع تطور هذه الأنماط.

@Dusk $DUSK #dusk