حالة السباق في موافقات ERC-20

قد يستخدم المنفق السماح القديم لرمز ERC-20 قبل تأكيد موافقة بديلة، ثم يستخدم السماح الجديد. تعرّف على آلية حالة السباق وكيفية تغيير الموافقات أو إلغائها بأمان أكبر.

لأغراض تعليمية فقط؛ لا يشكل ذلك نصيحة استثمارية أو توصية استثمارية. قد تؤدي الاستثمارات إلى خسائر.

الإجابة المباشرة

قد تحدث حالة السباق في موافقات ERC-20 عندما يستبدل المالك سماحًا غير صفري بسماح آخر عبر استدعاء approve(spender, newAmount). يستطيع المنفق رؤية التغيير المعلّق، وإنفاق السماح القديم أولًا باستخدام transferFrom، ثم الإنفاق من السماح البديل بعد تأكيده.

لذلك توصي مواصفات ERC-20 بأن تضبط واجهات العملاء السماح أولًا على 0 قبل تعيين قيمة جديدة للمنفق نفسه. يجب تأكيد كل معاملة بالترتيب. وعندما يدعم الرمز ذلك، تتجنب استدعاءات increaseAllowance أو decreaseAllowance الذرية استبدال سماح غير صفري مباشرةً.

معرف السلسلة والتحقق من العقد يتطابقان مع التطبيق المقصوديتم فك تشفير الوظيفة والمنفق والرمز المميز والمبلغ والرقم والموعد النهائيتم فحص دلالات البدل والاستبدال الحاليةتمت محاكاة تغييرات الرصيد والموافقةتتسبب المكالمات أو المفوضون أو عمليات نقل القيمة غير المتوقعة في الرفض

0 / 5

0 العناصر التي تمت مراجعتها; 5 العناصر لا تزال دون حل

إن استكمال هذه المراجعة لا يثبت أن الأصل أو المعاملة أو النظام آمن.

آلية العمل

تعرّف ERC-20 الدالة approve باعتبارها عملية استبدال: يضبط الاستدعاء الناجح approve(spender, amount) سماح المنفق على amount. وبشكل منفصل، تتيح transferFrom(owner, recipient, amount) لذلك المنفق نقل رموز المالك، وتخفض عادةً السماح المتبقي. لا تحجز المعاملات المعلّقة ترتيبًا للتنفيذ، لذلك قد يرسل المنفق عملية نقل تُنفّذ قبل تغيير المالك للموافقة.

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

مثال

منحت Alice بروتوكولًا موافقة على إنفاق 100 رمز. ثم أرسلت approve(protocol, 50) بقصد خفض السماح المتبقي إلى 50. قبل تأكيد هذه المعاملة، يرسل منفق البروتوكول transferFrom(Alice, recipient, 100) وتُنفّذ معاملته أولًا. بعد ذلك تضبط موافقة Alice السماح على 50، ويمكن للمنفق استخدامه في عملية نقل أخرى. يبلغ مجموع عمليتي النقل 150 رمزًا.

تتمثل عملية الاستبدال الأكثر أمانًا في إرسال approve(protocol, 0)، وانتظار التأكيد، وفحص السماح والرصيد الناتجين، وبعد ذلك فقط إرسال approve(protocol, 50) إذا ظلت الموافقة الجديدة مناسبة. إذا استخدم المنفق السماح القديم قبل تأكيد معاملة التصفير، تستطيع Alice رؤية تغيّر الرصيد والتوقف قبل منح السماح الجديد البالغ 50.

المخاطر

لا يؤدي ضبط السماح على 0 إلى إلغاء إنفاق نُفّذ بالفعل أو منع استخدام السماح القديم قبل تأكيد معاملة التصفير.
يؤدي إرسال موافقتي التصفير والاستبدال معًا، من دون انتظار تأكيد الأولى، إلى إعادة مخاطر ترتيب التنفيذ.
لا تُعد increaseAllowance وdecreaseAllowance جزءًا من معيار ERC-20 الأساسي؛ لا تستخدمهما إلا عندما يدعمهما عقد الرمز الذي جرى التحقق منه.
قد يعرّض السماح غير المحدود كامل رصيد رموز المالك للخطر ما دام نشطًا. تحقّق من الشبكة وعقد الرمز والمنفق والمبلغ قبل التوقيع.
تتصرف بعض الرموز بطريقة غير قياسية عند الموافقة. اقرأ محاكاة المحفظة وبيانات استدعاء المعاملة، وتأكد من السماح على السلسلة بعد كل خطوة.

مفاهيم خاطئة شائعة

“تحل أحدث معاملة موافقة محل القديمة فورًا.” لا تغيّر الحالة إلا عند تنفيذها على السلسلة.
“يؤدي خفض السماح إلى حصر إجمالي الإنفاق المستقبلي في المبلغ الجديد.” قد يستخدم المنفق السماح القديم قبل تنفيذ التغيير.
“التصفير أولًا يضمن عدم خروج المزيد من الرموز.” يظل السماح القديم قابلًا للاستخدام حتى تأكيد معاملة التصفير.
“يتضمن كل رمز ERC-20 الدالتين increaseAllowance وdecreaseAllowance.” إنهما امتدادان اختياريان وليستا من متطلبات ERC-20.
“إلغاء اتصال الموقع يلغي موافقة الرمز.” حالة اتصال المحفظة والسماح المسجل على السلسلة في عقد الرمز أمران منفصلان.

المصادر

ERC-20: Token Standard - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-20)
ERC20 | OpenZeppelin Docs - OpenZeppelin (تاريخ الاطلاع: 2026-08-20)