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

ببساطة، إعادة الدخول هي عندما يتم استدعاء عقد ذكي مرات متعددة قبل إكمال الاستدعاء الأول. تخيل الأمر هكذا: ContractA ينفذ وظيفة، ويستدعي ContractB، و ContractB يعيد استدعاء ContractA مرة أخرى بينما لم ينته ContractA بعد. هذه ثغرة يمكن للمهاجم استغلالها.

مثال محدد: EtherStore لديه 10 إيثير، و ContractB أرسل 1 إيثير إليه. عندما يستدعي ContractB وظيفة السحب، يتحقق مما إذا كان الرصيد أكبر من 0، وإذا كان كذلك، يرسل الإيثير مرة أخرى. لكن هنا تكمن الخطورة - تحديث الرصيد إلى 0 يحدث بعد إرسال الإيثير. لذلك، يمكن للمهاجم إنشاء وظيفة رد الفعل (fallback) عند استلام الإيثير، بحيث تعيد استدعاء وظيفة السحب مرة أخرى. ستستمر هذه الحلقة حتى يتم استنفاد كل الإيثير.

سأذكر ثلاث طرق لمكافحة إعادة الدخول:

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

الثانية هي تطبيق نمط Checks-Effects-Interactions. بدلاً من تحديث الرصيد بعد إرسال الإيثير، قم بتحديثه قبل ذلك. بهذه الطريقة، حتى لو حدث استدعاء مرة أخرى، سيكون الرصيد قد أصبح 0، وبالتالي ستفشل عملية التحقق.

الثالثة هي إنشاء عقد حماية إعادة دخول عالمية (GlobalReentrancyGuard). تستخدم متغير حالة مشترك للتحكم في إعادة الدخول عبر عدة عقود في آن واحد. مفيد بشكل خاص عندما يكون مشروعك يتضمن العديد من العقود التي تتفاعل مع بعضها. بدلاً من التحقق في كل عقد على حدة، تتحقق من مكان مركزي واحد.

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