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

ما هو المشكلة الأساسية لثغرة إعادة الدخول؟ تحدث عندما يستدعي عقد ذكي عقدًا آخر، ويمكن لذلك العقد أن يستدعي العقد الأصلي مرة أخرى أثناء تنفيذه. المهاجم يمكنه استغلال هذه الفترة لسرقة الأموال.

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

سأوضح لك ثلاث طرق لحماية العقد من هجوم إعادة الدخول هذا.

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

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

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

أنصحك بتطبيق جميع التقنيات الثلاث حسب الحالة. مع وظائف السحب أو نقل الأصول، دائمًا استخدم إما nonReentrant أو Checks-Effects-Interactions. وإذا كان مشروعك يتضمن نظام عقود معقد، فكر في استخدام GlobalReentrancyGuard كطبقة حماية إضافية.

هذه واحدة من أكثر الثغرات شيوعًا التي تؤدي إلى خسائر كبيرة، لذا فهم ثغرة reentrancy مهم جدًا إذا أردت كتابة عقود ذكية آمنة.