---
title: "حالة السباق في موافقات ERC-20"
description: "قد يستخدم المنفق السماح القديم لرمز ERC-20 قبل تأكيد موافقة بديلة، ثم يستخدم السماح الجديد. تعرّف على آلية حالة السباق وكيفية تغيير الموافقات أو إلغائها بأمان أكبر."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

<a id="answer"></a>

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

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

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

<a id="mechanism"></a>

## آلية العمل

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

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

<a id="example"></a>

## مثال

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

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

<a id="risks"></a>

## المخاطر

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

<a id="misconceptions"></a>

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

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

<a id="related"></a>

## مواضيع ذات صلة

- [كيفية التمييز بين الرموز المرجعية والرموز المغلّفة](/ar/crypto/canonical-vs-wrapped-token/)
- [مجمع الذاكرة](/ar/crypto/mempool/)
- [مخاطر توقيع Permit2](/ar/crypto/permit2-signature-risk/)
- [أوامر خفض المركز فقط](/ar/crypto/reduce-only-order/)
- [موافقة المحفظة](/ar/crypto/wallet-approval/)

<a id="sources"></a>

## المصادر

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-20)
- [ERC20 | OpenZeppelin Docs](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20) - OpenZeppelin (تاريخ الاطلاع: 2026-08-20)

Source: https://wiki.fcontext.com/ar/crypto/erc20-approval-race-condition/index.mdx