دالة Fallback

ما دالة Fallback؟

دالة Fallback هي دالة خاصة في Solidity تتعامل مع الاستدعاءات الخارجية التي لا تطابق أي دالة أخرى معرفة في العقد الذكي.

وهي خيار توجيه الاستدعاء الأخير للعقد عندما يتعذر على Solidity تحديد دالة عادية من بيانات المعاملة المرسلة.

وقد تعمل دالة Fallback أيضًا عندما لا يحتوي الاستدعاء على بيانات ولا يتضمن العقد دالة receive منفصلة.

تُستخدم هذه الدالة على نطاق واسع في تطبيقات العملات المشفرة، بما في ذلك العقود الذكية القابلة للترقية وأنظمة الوكلاء والمحافظ المعيارية وعقود الدفع وموجّهات الاستدعاء المخصصة.

وفقًا للوثائق الرسمية لـSolidity، لا يمكن أن يحتوي العقد على أكثر من دالة Fallback واحدة.

يجب أن تكون للدالة صلاحية الوصول external لأنها مصممة للاستجابة للاستدعاءات الواردة من خارج العقد.

وقد تكون payable إذا احتاج العقد إلى قبول عملة مشفرة أصلية عبر استدعاء غير مطابق.

كما يمكنها فحص بيانات المعاملة كاملة وإرجاع بيانات استجابة خام عند استخدام الصيغة المتقدمة للدالة.

دالة Fallback ليست معالجًا عامًا للأخطاء في جميع عمليات العقود الذكية الفاشلة.

إنما تعمل في ظروف محددة لتوجيه الاستدعاءات وفق قواعد Solidity والآلة الافتراضية Ethereum.

لماذا تسمى دالة Fallback؟

تشير كلمة Fallback إلى إجراء بديل يُستخدم عندما لا يتوفر الإجراء المفضل أو المتوقع.

عندما يستدعي المستخدم دالة عادية في عقد ذكي، تحاول Solidity أولًا مطابقة بيانات المعاملة المرسلة مع إحدى دوال العقد المعلنة.

إذا لم تجد تطابقًا، ينتقل العقد إلى دالة Fallback.

يتيح هذا السلوك للمطورين تحديد ما يحدث عند إرسال محفظة أو عقد ذكي أو تطبيق استدعاء غير مدعوم.

يمكن لدالة Fallback رفض الاستدعاء أو قبول دفعة أو تسجيل حدث أو إرجاع بيانات أو تمرير الاستدعاء إلى عقد آخر.

إذا لم يتضمن العقد دالة Fallback مناسبة، فعادةً ما يُرفض الاستدعاء غير المدعوم.

متى تُستدعى دالة Fallback؟

تُستدعى دالة Fallback عندما يصل استدعاء خارجي إلى عقد ذكي ولا تطابق أي دالة عادية محدد الدالة المرسل.

وتُستدعى أيضًا عندما يكون الاستدعاء خاليًا من بيانات calldata ولا يعرّف العقد دالة receive.

قد يصل الاستدعاء الذي يتضمن بيانات غير فارغة إلى دالة Fallback سواء نقل عملة مشفرة أصلية أم لا.

يجب أن تكون دالة Fallback من النوع payable إذا تضمن الاستدعاء قيمة غير صفرية من العملة المشفرة.

ترفض دالة Fallback غير القابلة للدفع الاستدعاء غير المطابق الذي يحاول نقل قيمة.

أما الاستدعاء الخالي من البيانات فيصل إلى دالة receive بدلًا منها إذا عرّفها العقد.

لذلك تختلف مسؤوليات دالة Fallback بحسب وجود دالة receive في العقد من عدمه.

كيف يعمل توجيه دوال العقود الذكية؟

تتضمن الاستدعاءات الخارجية للعقود الذكية عادةً بيانات مشفرة للمعاملة تُعرف باسم calldata.

تحتوي البايتات الأربع الأولى من استدعاء دالة قياسي على محدد الدالة.

يعرّف مواصفات Solidity ABI المحدد بأنه أول أربعة بايتات من تجزئة Keccak-256 للتوقيع القياسي للدالة.

يجمع التوقيع القياسي اسم الدالة مع أنواع معاملاتها.

تقارن Solidity المحدد الوارد بمحددات الدوال العامة والخارجية في العقد.

إذا وُجد محدد مطابق، تعالج الدالة المقابلة الاستدعاء.

إذا لم يوجد تطابق، توجه Solidity الاستدعاء إلى دالة Fallback عند توفرها.

لا تستطيع calldata الأقصر من أربعة بايتات عادةً تحديد دالة Solidity عادية، ولذلك قد تصل إلى دالة Fallback.

أما calldata الفارغة فتخضع لقاعدة توجيه منفصلة تمنح الأولوية لدالة receive.

دالة Fallback مقابل دالة receive

دالتا Fallback وreceive مدخلان منفصلان في Solidity، ولكل منهما غرض مختلف.

صُممت دالة receive خصيصًا للاستدعاءات ذات calldata الفارغة.

أما دالة Fallback فتتعامل أساسًا مع الاستدعاءات التي تحتوي بيانات لا تطابق دالة معلنة.

تكون دالة receive دائمًا payable لأن غرضها الأساسي قبول العملة المشفرة الأصلية.

ولا تكون دالة Fallback قابلة للدفع إلا إذا سمح المطور بذلك صراحةً.

عندما يعرّف العقد الدالتين، يصل تحويل القيمة ذي البيانات الفارغة إلى دالة receive.

أما الاستدعاء غير المطابق الذي يتضمن بيانات فيصل إلى دالة Fallback.

إذا لم يتضمن العقد دالة receive، فقد تعالج دالة Fallback القابلة للدفع تحويلًا ببيانات فارغة.

توصي إرشادات Solidity الحالية بشأن استقبال العملات المشفرة بتعريف دالة receive عند وجود دالة Fallback قابلة للدفع.

يساعد هذا الفصل على التمييز بين الدفعة المقصودة واستدعاء الدالة المشفر على نحو غير صحيح.

دالة Fallback مقابل الدالة العادية

لدالة Solidity العادية اسم معلن، ويكون لها عادةً محدد دالة خاص بها.

يمكن للتطبيقات استدعاء دالة عادية عبر واجهة عقد معروفة.

ليس لدالة Fallback اسم عادي يمكن استدعاؤها به.

ولا تملك محددًا مخصصًا يستدعيها المستخدمون مباشرةً.

إنما تتعامل مع الاستدعاءات التي لا تطابق الواجهة العادية للعقد.

يمكن أن يحتوي العقد على دوال عادية عديدة، لكنه لا يحتوي إلا على دالة Fallback واحدة.

ينبغي أن تتضمن الدوال العادية عادةً منطق العمل الأساسي للتطبيق اللامركزي.

وينبغي أن يكون غرض دالة Fallback محدودًا وموثقًا بوضوح، إلا إذا استُخدمت عمدًا كموجّه لوكيل.

دالة Fallback مقابل معالجة الأخطاء

لا تعمل دالة Fallback كلما فشلت دالة أخرى في العقد الذكي.

إذا طابقت calldata دالة عادية ثم أُلغيت تلك الدالة، فلن تُستدعَ دالة Fallback.

وإذا رفضت دالة مطابقة دفعة لأنها غير قابلة للدفع، فلن تعيد Solidity توجيه الدفعة إلى دالة Fallback.

إذا كان محدد الدالة صحيحًا لكن الوسائط مشوهة، فعادةً ما يُرفض الاستدعاء المطابق أثناء فك الترميز.

كذلك لا يؤدي إخفاق شرط أو فحص حسابي أو قاعدة تحكم في الوصول أو استدعاء خارجي أو خطأ مخصص إلى تفعيل دالة Fallback.

يجب على المطورين معالجة هذه الإخفاقات عبر معالجة الأخطاء المعتادة أو التحقق من القيم المرجعة أو الأخطاء المخصصة أو منطق try-and-catch الملائم.

تتعامل دالة Fallback مع الاستدعاءات غير المطابقة، لا مع الإخفاقات داخل الاستدعاءات المطابقة.

ما دالة Fallback القابلة للدفع؟

تستطيع دالة Fallback القابلة للدفع قبول العملة المشفرة الأصلية المرفقة باستدعاء خارجي غير مطابق.

تكون قيمة العملة المرسلة مع الاستدعاء متاحة في حقل قيمة المعاملة.

كما يكون عنوان المرسل متاحًا للدالة.

وقد تحدث دالة Fallback القابلة للدفع حالة العقد أو تصدر حدثًا أو تمرر الاستدعاء أو تنفذ إجراءً آخر مسموحًا عند توفر غاز كافٍ.

ينشئ جعل الدالة قابلة للدفع مسؤوليات مالية على العقد.

وقد يحتاج العقد إلى محاسبة موثوقة للأرصدة وسحوبات مضبوطة وإجراءات طوارئ وحماية من إعادة الدخول.

ينبغي للعقد الذي لم يُصمم للاحتفاظ بالعملات المشفرة أن يرفض الدفعات غير المتوقعة عادةً.

لا ينبغي إضافة قابلية الدفع إلا لغرض محدد في البروتوكول.

ما دالة Fallback غير القابلة للدفع؟

يمكن لدالة Fallback غير القابلة للدفع معالجة الاستدعاءات غير المطابقة التي لا تنقل عملة مشفرة أصلية.

يُرفض الاستدعاء غير المطابق الذي يحمل قيمة غير صفرية إذا لم تكن الدالة قابلة للدفع.

يفيد هذا التصميم عندما يحتاج العقد إلى توجيه مخصص أو تسجيل، لكنه لا ينبغي أن يقبل الأموال.

كما يمكن لدالة Fallback غير القابلة للدفع أن ترفض محددات الدوال غير المدعومة صراحةً.

قد يساعد رفض الاستدعاءات غير المعروفة المستخدمين والتطبيقات على اكتشاف استخدام واجهة غير صحيحة.

ما المعلومات التي يمكن لدالة Fallback قراءتها؟

يمكن لدالة Fallback الوصول إلى عنوان الجهة التي بدأت الاستدعاء الحالي.

كما يمكنها الوصول إلى مقدار العملة المشفرة الأصلية المرفقة بالاستدعاء إذا كانت قابلة للدفع.

وتستطيع فحص calldata كاملة التي أرسلها المستدعي.

وتشمل calldata الكاملة المحدد المحتمل وأي قيم إضافية مشفرة.

يمكن للصيغة ذات المعلمات من دالة Fallback تلقي هذه البيانات كسلسلة بايتات.

كما يمكنها إرجاع بايتات خام مباشرةً إلى المستدعي.

لا تطبق Solidity تلقائيًا ترميز ABI المعتاد على البيانات الخام التي تعيدها دالة Fallback.

يفيد هذا السلوك خصوصًا عقود الوكيل التي تحتاج إلى إرجاع البيانات نفسها التي أعادها عقد التنفيذ.

هل ينبغي لدالة Fallback فك ترميز calldata؟

يمكن لدالة Fallback فحص calldata وفك ترميزها يدويًا.

ويمكن مقارنة أول أربعة بايتات بالمحددات المتوقعة.

كما يمكن فك ترميز البايتات المتبقية إلى أنواع المعلمات المتوقعة.

لكن وثائق Solidity توصي بأن يكون فك الترميز اليدوي داخل Fallback ملاذًا أخيرًا فقط.

توفر الدوال المسماة العادية واجهات أوضح وفك ترميز تلقائيًا أكثر أمانًا وتكاملًا أسهل.

يجب أن يتحقق فك الترميز اليدوي من طول calldata والإزاحات والأنواع والمحددات المدعومة.

ينبغي رفض البيانات المشوهة قبل حدوث أي تغيير حساس في الحالة.

قد يؤدي فك الترميز غير الصحيح إلى سلوك غير متوقع أو معاملات فاشلة أو ثغرات أمنية.

دوال Fallback في عقود الوكيل القابلة للترقية

تُعد عقود الوكيل القابلة للترقية من أهم استخدامات دوال Fallback في تطبيقات العملات المشفرة.

يفصل الوكيل عنوان العقد وحالته المخزنة عن الشيفرة التي تحتوي منطق التطبيق.

يرسل المستخدمون المعاملات إلى عنوان الوكيل.

ويخزن الوكيل عنوان عقد التنفيذ الذي يحتوي المنطق النشط.

تصل الاستدعاءات التي لا تطابق دوالًا معرفة مباشرةً في الوكيل إلى دالة Fallback الخاصة به.

تمرر دالة Fallback هذه الاستدعاءات إلى عقد التنفيذ باستخدام delegatecall.

يوضح توثيق Ethereum بشأن ترقيات الوكلاء أن هذه البنية تتيح تغيير منطق العمل مع استمرار المستخدمين في التفاعل مع عنوان الوكيل نفسه.

يحتفظ الوكيل بالأرصدة وبيانات التطبيق المخزنة بعد تغيير عقد التنفيذ.

وقد يتيح ذلك إصلاح الأخطاء وإضافة ميزات جديدة من دون نقل كل مستخدم إلى عنوان عقد جديد.

ما delegatecall؟

delegatecall عملية في آلة Ethereum الافتراضية تنفذ شيفرة عقد آخر ضمن سياق العقد المستدعي.

في نظام الوكيل، يوفر عقد التنفيذ الشيفرة.

أما الوكيل فيوفر العنوان ورصيد العملة المشفرة والتخزين الدائم.

ويظل المرسل الأصلي وقيمة المعاملة متاحين أثناء التنفيذ المفوض.

لذلك يتصرف عقد التنفيذ كما لو أن منطقه جزء من الوكيل.

قدم EIP-7 عملية delegatecall منخفضة المستوى لتنفيذ شيفرة خارجية مع الحفاظ على سياق المرسل والقيمة لدى المستدعي.

تتميز delegatecall بقوتها لأن عقد التنفيذ يستطيع قراءة مساحة تخزين الوكيل وتعديلها.

وهذا هو سبب خطورتها أيضًا.

قد يؤدي عقد تنفيذ خبيث أو غير متوافق إلى إفساد الأرصدة أو الصلاحيات أو بيانات الملكية أو غيرها من الحالات الأساسية.

كيف توجه دالة Fallback في الوكيل الاستدعاء؟

يستقبل الوكيل أولًا calldata كاملة التي أرسلها المستخدم.

ثم تحدد دالة Fallback عنوان عقد التنفيذ الحالي.

ويمرر الوكيل calldata الأصلية إلى عقد التنفيذ باستخدام delegatecall.

ينفذ عقد التنفيذ منطقه باستخدام مساحة تخزين الوكيل.

يجمع الوكيل بيانات الاستجابة من عقد التنفيذ.

إذا نجح الاستدعاء المفوض، يعيد الوكيل الاستجابة نفسها إلى المستدعي الأصلي.

وإذا فشل، ينبغي للوكيل تمرير معلومات الإخفاق الأصلية إلى المستدعي.

قد يؤدي التمرير غير الصحيح إلى إخفاء الأخطاء أو تعديل البيانات المرجعة أو جعل عمليات التكامل تفسر النتيجة على نحو خاطئ.

خانات تخزين الوكيل

يجب أن يخزن الوكيل عنوان عقد التنفيذ في موضع ما من مساحة التخزين الدائمة للعقد.

ويجب ألا يتعارض موضع التخزين مع المتغيرات التي يستخدمها عقد التنفيذ.

يحدد ERC-1967 خانات تخزين موحدة لمعلومات تنفيذ الوكيل والـBeacon والمسؤول.

اختيرت هذه المواضع لتجنب خانات التخزين العادية التي يعينها مترجم Solidity.

وتساعد الخانات الموحدة مستكشفي البلوكشين وأدوات التطوير على اكتشاف علاقات الوكلاء.

يقلل استخدام خانة تخزين معتمدة احتمال التعارض العرضي، لكنه لا يزيل جميع مخاطر الترقية.

ولا يزال يتعين على إصدارات التنفيذ الحفاظ على توافق تخطيط التخزين.

مخاطر تخطيط التخزين

يحتفظ الوكيل ببياناته الحالية عند ترقية عقد التنفيذ.

ويجب أن يفسر التنفيذ الجديد تلك البيانات بالطريقة نفسها التي اتبعها التنفيذ السابق.

قد يؤدي تغيير ترتيب متغيرات الحالة القائمة إلى قراءة إحدى القيم على أنها قيمة أخرى.

وقد يؤدي تغيير نوع المتغير إلى إفساد معناه أو تعذر الوصول إليه.

وقد يغير تعديل الوراثة تخطيط التخزين المتوقع أيضًا.

يجب إضافة متغيرات الحالة الجديدة وفق قواعد التخزين الخاصة ببنية الوكيل المستخدمة.

قد تنجح الترقية على مستوى المعاملة، مع إتلاف بيانات العقد بصمت.

لذلك يجب التحقق من توافق التخزين قبل كل تحديث للتنفيذ.

تعارض محددات الدوال

يتكون محدد الدالة من أربعة بايتات فقط.

ومن الممكن نظريًا أن ينتج توقيعان مختلفان محددًا واحدًا.

وتُعرف هذه الحالة بتعارض المحددات.

ويكتسب التعارض أهمية خاصة عندما يعرّف كل من الوكيل وعقد التنفيذ دوال قابلة للاستدعاء.

قد يعترض الوكيل محددًا توقع المستخدم أن يصل إلى عقد التنفيذ.

يوضح ERC-1967 أن تعارض المحددات قد يؤدي إلى استجابات غير متوقعة، وقد يخفي سلوكًا خبيثًا للوكيل.

ينبغي للمطورين اختبار جميع المحددات بين دوال الوكيل والتنفيذ والإدارة والترقيات المخطط لها.

لا يكفي اسم الدالة وحده لإثبات تفرد محددها عبر عقود متعددة.

مخاطر صلاحية الترقية

يملك الوكيل القابل للترقية عادةً حسابًا أو آلية حوكمة مخولة بتغيير عنوان عقد التنفيذ.

تستطيع الجهة التي تسيطر على هذه الصلاحية تغيير الشيفرة المنفذة عبر دالة Fallback.

وقد يثبت مفتاح ترقية مخترق تنفيذًا ينقل الأصول أو يغير أرصدة الحسابات.

كما قد يستبدل مسؤول خبيث المنطق المشروع بمنطق ضار.

ينبغي للمستخدمين فحص عنوان المسؤول وحد التوقيعات وعملية الحوكمة ومهلة التنفيذ والصلاحيات الطارئة وسجل الترقيات.

لا تضمن دالة Fallback موثق مصدرها في الوكيل أن يكون كل تنفيذ مستقبلي آمنًا.

تضيف قابلية الترقية ثقة مستمرة في الحوكمة والعمليات.

دوال Fallback في عقود Diamond

يوجه عقد Diamond محددات الدوال المختلفة إلى عقود تنفيذ متعددة تُعرف باسم Facets.

تفحص دالة Fallback المحدد الوارد وتحدد Facet المسؤول عن الدالة.

ثم تمرر الاستدعاء إلى Facet المحدد باستخدام delegatecall.

يحدد ERC-2535 بنية وكيل متعددة الـFacets لأنظمة العقود الذكية المعيارية.

قد تدعم هذه البنية تطبيقات تتضمن منطقًا أكبر مما يمكن لعقد تنفيذ واحد استيعابه بسهولة.

كما يمكن إضافة مجموعات الدوال الفردية أو استبدالها أو إزالتها.

وتزيد هذه المرونة تعقيد المحددات والتخزين والتهيئة والصلاحيات والترقيات.

لا تكشف مراجعة Facet واحدة كل السلوكيات المتاحة عبر عنوان Diamond.

دوال Fallback في الحسابات الذكية المعيارية

قد تستخدم حسابات العقود الذكية معالجات Fallback لإضافة ميزات معيارية.

قد يدعم المعالج التوقيعات أو عمليات رد التوكنات أو استعادة الحساب أو صلاحيات الجلسات أو واجهات خاصة بتطبيق معين.

يصف ERC-7579 معالجات Fallback بأنها وحدات توسع وظائف الحسابات الذكية.

يجب أن يضبط الحساب الجهات المخولة بتثبيت المعالجات واستبدالها وإزالتها.

قد يتيح المعالج غير المصرح به سلوكًا غير متوقع للحساب.

ينبغي لمستخدمي المحافظ فهم أن تغيير وحدة Fallback قد يغير استجابة الحساب للاستدعاءات الخارجية.

الغاز ودوال Fallback

قد تنفذ دالة Fallback عمليات معقدة إذا وفر المستدعي غازًا كافيًا.

لكن ينبغي ألا تفترض أن كل مستدعٍ سيوفر المقدار نفسه.

لا تمرر بعض طرق تحويل العملات المشفرة القديمة إلا قدرًا صغيرًا من الغاز إلى العقد المستقبِل.

تحذر وثائق Solidity الحالية من أن send وtransfer مهملتان ومقرر إزالتهما.

قد لا يكفي مقدار الغاز الصغير لتحديث التخزين أو إجراء تحويلات إضافية أو إنشاء عقد أو تنفيذ استدعاءات خارجية مرتفعة التكلفة.

وقد تتغير تكاليف الغاز أيضًا مع ترقيات الشبكة.

لذلك ينبغي ألا يعتمد مسار الدفع على منطق معقد في Fallback.

ولا ينبغي للمطورين اعتبار حد الغاز الصغير الوسيلة الوحيدة للحماية من عمليات الاستدعاء الخبيثة.

مخاطر إعادة الدخول في دالة Fallback

قد تستدعي دالة Fallback عقدًا آخر عند توفر غاز كافٍ.

وقد تعيد الاستدعاء إلى العقد الذي أرسل العملة المشفرة أو بدأ التفاعل.

وقد ينشأ عن ذلك هجوم إعادة دخول إذا لم يكمل العقد المرسل حساباته قبل الاستدعاء الخارجي.

يوضح دليل Solidity الأمني بشأن إعادة الدخول أن الاستدعاءات إلى العقود الخارجية قد تعيد التحكم قبل اكتمال العملية الأصلية.

ينبغي للعقود التحقق من الشروط قبل إجراء استدعاءات خارجية.

كما ينبغي تحديث الحالة الداخلية المهمة قبل نقل التحكم إلى عقد غير موثوق.

وقد توفر الحماية المناسبة من إعادة الدخول طبقة دفاع إضافية.

ينبغي التعامل مع كل استدعاء خارجي على أنه تنفيذ محتمل لشيفرة غير موثوقة.

مخاطر حجب الخدمة

قد تُلغي دالة Fallback التنفيذ عمدًا أو عن غير قصد.

إذا اشترط عقد آخر نجاح دفعة قبل إكمال عملية أكبر، فقد يمنع سلوك المستقبِل إتمام العملية.

وقد تستهلك دالة Fallback غازًا مفرطًا أو تجري استدعاءات خارجية مرتفعة التكلفة.

ويكون ذلك خطرًا خصوصًا إذا أدت دفعة فاشلة واحدة إلى إلغاء حلقة توزيع كاملة.

توصي إرشادات Solidity بشأن إرسال العملات المشفرة باستخدام تصاميم السحب في كثير من أنظمة الدفع.

يتيح نموذج السحب لكل مستفيد المطالبة بأمواله بصورة مستقلة.

وبذلك يقل احتمال أن يمنع سلوك Fallback لمستفيد واحد المدفوعات الخاصة بالمستخدمين الآخرين.

نجاح غير متوقع للاستدعاءات منخفضة المستوى

يشير الاستدعاء منخفض المستوى إلى نجاح التنفيذ لدى الجهة المستهدفة أو تراجعه.

لكن نجاحه لا يثبت وجود الدالة المسماة المقصودة.

قد يصل المحدد غير المعروف إلى دالة Fallback متساهلة وينجح التنفيذ.

وقد يفترض العقد المستدعي خطأً حدوث العملية المطلوبة إذا اكتفى بفحص حالة النجاح.

ينبغي للمطورين التحقق من البيانات المرجعة وتغيرات الحالة المتوقعة عند استخدام الاستدعاءات منخفضة المستوى.

تكون الواجهة ذات الأنواع المحددة أكثر أمانًا عمومًا إذا كانت الدالة المستهدفة معروفة مسبقًا.

دوال Fallback والعملات المشفرة الأصلية

يمكن لدالة Fallback قابلة للدفع قبول العملة المشفرة الأصلية عبر استدعاءات غير مطابقة.

وإذا لم توجد دالة receive، فقد تتعامل أيضًا مع تحويل عادي ذي calldata فارغة.

يرفض العقد عادةً التحويلات المباشرة العادية إذا لم يتضمن دالة receive أو Fallback قابلة للدفع.

لكن لا يمكن للعقد ضمان بقاء رصيده عند الصفر دائمًا.

تتضمن EVM طرقًا استثنائية لزيادة رصيد العقد من دون تنفيذ منطق receive أو Fallback.

ولا ينبغي للمحاسبة الداخلية للعقد افتراض أن رصيده الفعلي يساوي دائمًا المجموع المسجل عبر دوال معالجة الدفع.

دوال Fallback وتوكنات ERC-20

لا يستدعي تحويل توكن ERC-20 العادي دالة Fallback في العقد المستقبِل.

يغير عقد التوكن الأرصدة في مساحة تخزينه الخاصة.

وقد يتلقى العقد رصيدًا من التوكنات من دون تنفيذ أي شيفرة.

يحدد ERC-20 التحويلات عبر عقد التوكن نفسه، لا عبر استدعاء إلزامي للمستقبِل.

ينبغي ألا يعتمد العقد على تنفيذ Fallback لاكتشاف كل إيداع للتوكنات.

تستخدم التطبيقات عادةً دوال إيداع صريحة أو قواعد منفصلة لمحاسبة الأرصدة.

دوال Fallback وNFT

تستدعي بعض طرق نقل NFT الآمنة دالة مستقبِل محددة في العقد الوجهة.

تختلف دالة المستقبِل هذه عن دالة Fallback العامة.

إذا غابت دالة المستقبِل المتوقعة، فقد يصل الاستدعاء إلى Fallback لأن المحدد غير مطابق.

ينبغي ألا تحاكي دالة Fallback متساهلة دعم استقبال NFT ما لم ينفذ العقد السلوك المطلوب عمدًا.

قد تؤدي الاستجابة غير الصحيحة إلى رفض التحويل أو مشكلة في استعادة الأصل.

هل يمكن لدالة Fallback إصدار أحداث؟

يمكن لدالة Fallback إصدار أحداث عند تلقي دفعة أو استدعاء غير مدعوم.

وقد يسجل الحدث المرسل أو المبلغ المحول أو المحدد أو قيمة أخرى مفيدة.

قد تساعد هذه المعلومات المطورين على مراقبة عمليات التكامل والتحقيق في الأنشطة غير المتوقعة.

يستهلك إصدار الحدث غازًا وقد يفشل إذا خصص المستدعي مقدارًا محدودًا جدًا.

الأحداث على السلسلة علنية، ولا ينبغي التعامل معها كسجلات سرية.

وقد يؤدي تسجيل calldata كاملة إلى تكاليف غير ضرورية لأن بيانات المعاملة متاحة للعامة أصلًا.

هل يمكن لدالة Fallback تعديل التخزين؟

يمكن لدالة Fallback تعديل تخزين العقد عند توفر غاز كافٍ.

وقد تحدث العدادات أو سجلات المدفوعات أو الصلاحيات أو معلومات التوجيه أو غيرها من الحالات.

يزيد تعديل التخزين استهلاك الغاز ويوسع أثر الدالة الأمني.

ينبغي أن تخضع دالة Fallback التي تغير حالة مهمة لضوابط وصول واضحة وشروط مختبرة بعناية.

ينبغي ألا يعتمد استقبال المدفوعات على الكتابة في التخزين عندما قد يخصص المستدعي قدرًا محدودًا من الغاز.

هل يمكن توريث دالة Fallback؟

يمكن أن تدخل دالة Fallback ضمن وراثة Solidity.

وقد تُعلن virtual ثم يستبدلها عقد مشتق.

كما يمكن أن تستخدم المُعدِّلات.

قد تجعل الوراثة سلوك الاستدعاء النهائي صعب الفهم عندما تسهم عدة عقود بمنطق مترابط.

ينبغي للمدققين مراجعة بنية الوراثة الكاملة بعد الترجمة، لا ملف مصدر واحد فقط.

كيفية اختبار دالة Fallback

ينبغي للمطورين اختبار استدعاء يتضمن محددًا مجهولًا من أربعة بايتات.

وعليهم اختبار calldata أقصر من أربعة بايتات.

كما ينبغي اختبار calldata فارغة من دون عملة مشفرة مرفقة.

واختبار calldata فارغة مع عملة مشفرة مرفقة.

واختبار calldata غير فارغة وغير مطابقة مع قيمة مرفقة ومن دونها.

ينبغي التحقق من اختلاف التوجيه عند وجود دالة receive.

يجب اختبار الوكيل للتأكد من تمرير البيانات المرجعة وبيانات الإلغاء على نحو صحيح.

وينبغي أن تؤكد اختبارات الترقية بقاء جميع بيانات التخزين القائمة سليمة.

كما ينبغي أن تشمل الاختبارات الأمنية إعادة الدخول وتعارض المحددات وcalldata المشوهة والترقيات غير المصرح بها ونقص الغاز.

كيفية تدقيق دالة Fallback

ينبغي أن يحدد التدقيق أولًا جميع أنواع الاستدعاءات التي قد تصل إلى دالة Fallback.

ويجب تحديد ما إذا كانت الدالة قابلة للدفع.

ينبغي التحقق من وجود دالة receive منفصلة في العقد.

كما يجب فحص كل تحديث للتخزين واستدعاء خارجي ومُعدِّل وعملية assembly وفحص للصلاحيات.

في تدقيق الوكيل، يجب التحقق من كيفية اختيار عنوان عقد التنفيذ.

ويجب ألا يتمكن مستخدم غير مخول من تغيير هدف delegatecall.

ينبغي تمرير البيانات المرجعة وبيانات الإلغاء بدقة.

ويجب أن تحافظ ترقيات التنفيذ على توافق التخزين.

كما ينبغي أن تشمل المراجعة المسؤول وعملية الحوكمة وتأخير الترقية وضوابط الطوارئ.

أفضل الممارسات لدالة Fallback

استخدم الدوال العادية المسماة لسلوك التطبيق المعتاد متى أمكن.

عرّف دالة receive منفصلة إذا كان العقد يقبل عمدًا تحويلات عادية للعملة المشفرة الأصلية.

ارفض المحددات غير المدعومة إذا لم تكن هناك حاجة إلى توجيه مخصص.

اجعل سلوك Fallback المتعلق بالمدفوعات بسيطًا.

تعامل مع جميع البيانات والمستدعين بوصفهم غير موثوقين.

تحقق من المحددات وطول البيانات قبل فك الترميز اليدوي.

استخدم معايير وكلاء خضعت للمراجعة بدلًا من إنشاء منطق تمرير غير مختبر.

احمِ خانات تخزين التنفيذ والمسؤول والـBeacon.

حافظ على تخطيط التخزين عبر الترقيات.

طبق ضوابط وصول واضحة على كل وظيفة ترقية.

مرر بيانات النجاح والإخفاق بدقة عند توجيه الاستدعاءات.

استخدم ترتيبًا آمنًا لتحديث الحالة وحماية مناسبة من إعادة الدخول.

اختبر الاستدعاءات غير المعتادة التي قد لا تنشئها واجهات المحافظ العادية مطلقًا.

استخدم إصدارًا مستقرًا حديثًا من مترجم Solidity وراجع القائمة الرسمية بأخطاء المترجم المعروفة.

أخطاء شائعة في دوال Fallback

من الأخطاء الشائعة افتراض أن Fallback تعمل بعد إلغاء دالة مطابقة.

ومنها جعل الدالة قابلة للدفع من دون نظام آمن للسحب.

تقبل بعض العقود دفعات عادية عبر Fallback من دون تعريف دالة receive أوضح.

وقد يجري فك ترميز calldata يدويًا من دون فحص طول البيانات.

وقد يخلط المستدعي منخفض المستوى بين نجاح تنفيذ Fallback ونجاح تنفيذ الدالة المطلوبة.

وقد يخزن الوكيل عنوان التنفيذ في موضع يتعارض مع حالة التطبيق.

وقد تعيد الترقية ترتيب المتغيرات فتفسد الأرصدة أو الصلاحيات.

قد يسمح هدف delegatecall غير المقيد بتنفيذ شيفرة اعتباطية ضمن سياق الوكيل.

وقد تفشل دالة Fallback المعقدة إذا تلقت غازًا أقل من المتوقع.

وقد يتوقع المطور خطأً أن يؤدي تحويل ERC-20 إلى تشغيل Fallback.

مفاهيم خاطئة شائعة عن دوال Fallback

دالة Fallback ليست معالجًا عامًا لأخطاء العقود الذكية.

ولا تُستدعى بعد كل معاملة فاشلة.

ولا تكون قابلة للدفع تلقائيًا.

وليست دائمًا الدالة المناسبة لاستقبال دفعات العملات المشفرة العادية.

لا يمكن أن يحتوي العقد إلا على دالة Fallback واحدة.

ليس لدالة Fallback محدد دالة عادي.

يمكنها معالجة calldata غير المطابقة حتى من دون تحويل عملة مشفرة.

لا يثبت نجاح Fallback أن المستدعي استخدم واجهة العقد الصحيحة.

قد تعرض Fallback الخاصة بالوكيل المستخدمين لشيفرة غير مخزنة في عنوان الوكيل.

لا تثبت مراجعة الشيفرة المصدرية للوكيل وحدها أن تنفيذه الحالي آمن.

الأسئلة الشائعة

ما دالة Fallback في Solidity؟

هي دالة خارجية خاصة تعالج الاستدعاءات التي لا تطابق دالة أخرى في العقد الذكي.

متى تعمل دالة Fallback؟

تعمل عندما لا تطابق أي دالة معلنة المحدد المرسل، أو عندما تكون calldata فارغة ولا توجد دالة receive.

هل يمكن للعقد امتلاك عدة دوال Fallback؟

لا، لا يمكن أن يحتوي عقد Solidity على أكثر من دالة Fallback واحدة.

هل لدالة Fallback اسم؟

لا، تُعرّف باستخدام الكلمة المفتاحية fallback بدلًا من اسم دالة عادي.

هل يجب أن تكون دالة Fallback خارجية؟

نعم، يجب أن تستخدم دالة Fallback مستوى الوصول external.

هل تكون دالة Fallback قابلة للدفع تلقائيًا؟

لا، ولا تقبل العملة المشفرة الأصلية إلا إذا وُسمت صراحةً بأنها payable.

ماذا يحدث عند إرسال قيمة إلى Fallback غير قابلة للدفع؟

يُرفض الاستدعاء غير المطابق إذا حاول نقل مبلغ غير صفري.

ما الفرق بين Fallback وreceive؟

تتعامل receive مع calldata الفارغة، بينما تتعامل Fallback أساسًا مع الاستدعاءات التي لا تطابق دالة معلنة.

أي دالة تتعامل مع تحويل عادي للعملة المشفرة؟

تتعامل معه دالة receive عند وجودها، بينما لا تتعامل معه Fallback القابلة للدفع إلا في غياب receive.

هل تعمل Fallback بعد فشل دالة أخرى؟

لا، فالإخفاق داخل دالة مطابقة لا يعيد توجيه التنفيذ إلى Fallback.

هل تستطيع Fallback فحص بيانات المعاملة؟

نعم، يمكنها الوصول إلى calldata كاملة التي أرسلها المستدعي.

هل تستطيع Fallback إرجاع بيانات؟

نعم، يمكن لصيغتها المتقدمة إرجاع بايتات خام مباشرةً إلى المستدعي.

لماذا تستخدم عقود الوكيل Fallback؟

لتمرير استدعاءات المستخدمين إلى عقد تنفيذ باستخدام delegatecall.

ما الذي تحافظ عليه delegatecall؟

تحافظ على المرسل الأصلي والقيمة، مع تنفيذ شيفرة عقد التنفيذ في مساحة تخزين الوكيل ورصيده.

هل تعدل delegatecall مساحة تخزين عقد التنفيذ؟

لا، فعادةً ما تقرأ شيفرة التنفيذ المفوضة مساحة تخزين الوكيل المستدعي وتكتب فيها.

ما عقد التنفيذ؟

هو العقد الذي يحتوي منطق العمل المنفذ عبر وكيل قابل للترقية.

ما تعارض المحددات؟

يحدث عندما تنتج تواقيع دوال مختلفة محددًا واحدًا من أربعة بايتات.

لماذا يهم تخطيط التخزين؟

قد يؤدي عدم توافق التخزين إلى قراءة التنفيذ الذي تمت ترقيته بيانات الوكيل القائمة على نحو خاطئ أو الكتابة فوقها.

هل قد تسبب Fallback إعادة الدخول؟

نعم، يمكنها استدعاء عقد آخر عند توفر غاز كافٍ.

هل يمكن لـFallback رفض دفعة؟

نعم، يمكن لـFallback غير القابلة للدفع أو التي تلغي التنفيذ صراحةً رفض دفعة عادية عبر استدعاء رسالة.

هل يستطيع العقد منع كل زيادة محتملة في رصيده؟

لا، فقد تزيد بعض آليات EVM رصيد العقد من دون تنفيذ منطق receive أو Fallback.

هل يؤدي تحويل ERC-20 إلى تشغيل Fallback؟

عادةً لا، لأن عقد التوكن يحدث الأرصدة من دون استدعاء المستقبِل.

هل يمكن لـFallback إصدار حدث؟

نعم، بشرط توفير غاز كافٍ لعملية إصدار الحدث.

هل يمكن لـFallback تحديث التخزين؟

نعم، لكن تحديث التخزين يزيد التكلفة وقد يفشل عند محدودية الغاز المتاح.

هل يمكن لـFallback استخدام المُعدِّلات؟

نعم، يمكن لدالة Fallback استخدام مُعدِّلات Solidity.

هل يمكن توريث Fallback؟

نعم، يمكن تعريفها virtual واستبدالها في عقد مشتق.

هل يثبت نجاح الاستدعاء منخفض المستوى وجود الدالة المطلوبة؟

لا، فقد تكون دالة Fallback قد قبلت المحدد المجهول.

هل ينبغي لكل عقد ذكي أن يتضمن دالة Fallback؟

لا، لا ينبغي تعريفها إلا عند الحاجة إلى معالجة مخصصة للاستدعاءات غير المطابقة.

هل دالة Fallback آمنة في عقد قابل للترقية؟

قد تكون آمنة إذا صُمم منطق التمرير وتخطيط التخزين والتنفيذ وصلاحية الترقية ودُققت على نحو صحيح.

ما أكبر مخاطر دالة Fallback؟

يعتمد الخطر الأكبر على الغرض منها، لكن التفويض عبر الوكيل والاستدعاءات الخارجية غير المقيدة والترقيات غير الآمنة وسلوك الدفع غير المتوقع كلها مخاطر حرجة.

الخاتمة

دالة Fallback مدخل خاص في Solidity للاستدعاءات الخارجية التي لا تطابق دالة أخرى معلنة في العقد الذكي.

وقد تتعامل أيضًا مع calldata الفارغة إذا لم يعرّف العقد دالة receive.

تستطيع Fallback القابلة للدفع قبول العملة المشفرة الأصلية، بينما ترفض Fallback غير القابلة للدفع الاستدعاءات غير المطابقة التي تحمل قيمة.

تكون دالة receive عادةً الخيار الأوضح للتحويلات العادية المقصودة للعملة المشفرة.

تُعد دوال Fallback أساسية للوكلاء القابلين للترقية، إذ يمكنها تمرير الاستدعاءات إلى عقود التنفيذ عبر delegatecall.

تحافظ هذه العملية على المرسل الأصلي والقيمة أثناء تنفيذ شيفرة عقد التنفيذ ضمن مساحة تخزين الوكيل.

ينشئ توجيه الاستدعاءات عبر Fallback في الوكيل مخاطر تتعلق بتخطيط التخزين وتعارض المحددات وصلاحية الترقية وdelegatecall.

وقد تنشئ دوال Fallback أيضًا مخاطر إعادة الدخول وحجب الخدمة والغاز وفك الترميز ونجاح الاستدعاءات غير المتوقعة.

ينبغي للمطورين حصر سلوك Fallback ورفض الاستدعاءات غير المدعومة عند الاقتضاء واستخدام الدوال العادية المسماة لمنطق التطبيق المعتاد.

يُعد فهم دالة Fallback ضروريًا لتقييم العقود الذكية للعملات المشفرة، إذ يمكن لهذا المدخل غير المسمى التحكم في المدفوعات وتوجيه الوكلاء وسلوك الحسابات المعيارية وتنفيذ تطبيق لامركزي كامل.