موافقات الرموز وAllowance: كيف تراجع صلاحيات ERC-20 وتلغيها

يسمح اتصال الموقع للتطبيق عادةً برؤية عنوانك العام وطلب توقيعات، لكنه لا يمنحه وحده حق نقل كل رموز ERC-20. تُسجل allowance منفصلة داخل عقد الرمز. وتوضح MetaMask أيضًا الفرق بين فصل dapp وإلغاء موافقات الرموز.

ترتبط الصلاحية بعقد الرمز والشبكة وعنوان المالك وعنوان spender. فالموافقة على Ethereum لا تعني الموافقة على الرمز ذي الاسم نفسه على Polygon أو على رمز آخر. تذكّر عبارة «وافقت على الموقع» فقط قد يخفي أي رمز وأي شبكة ما زالا يملكان صلاحية نشطة.

يركز هذا الدليل على approve وallowance وtransferFrom في ERC-20 على Ethereum والشبكات المتوافقة. تحويل ETH الأصلي، وموافقة NFT عبر setApprovalForAll، والمعايير الأخرى، واتصال تسجيل الدخول ليست الوظيفة نفسها. لنسخ المفاتيح واستعادتها، راجع دليل العبارة السرية واستعادة المحفظة.

يمكن للمالك استدعاء approve(spender, amount) في عقد الرمز للسماح لعنوان محدد باستخدام كمية تصل إلى الحد. وتتيح transferFrom لذلك العنوان نقل الرموز نيابةً عن المالك. لذلك لا تغير approve الرصيد عادةً وقت تنفيذها، لكن استدعاء عقد لاحقًا قد يستهلك الصلاحية. هذا هو المسار المحدد في معيار ERC-20.

مثلًا، إذا احتوت المحفظة على 300 رمز ومنحت موجهًا صلاحية 80، فإن حد الاستخدام في ERC-20 المعتاد هو الأقل بين الرصيد المتاح والصلاحية المتبقية. وقد تشمل الموافقة أكثر من عملية؛ يستطيع العقد استدعاء transferFrom مرات متعددة. وإذا أسيء استخدام العقد الموافق عليه أو مسار التنفيذ، فقد تتحرك الرموز على نحو لم يقصده المستخدم. وقد تختلف الرموز غير القياسية أيضًا.

الموافقة غالبًا معاملة على السلسلة إلى عقد الرمز، وقد تتطلب رسوم شبكة. بعض التطبيقات تفصل الموافقة عن المبادلة، وبعضها يجمع توقيعًا معاملة لاحقة. افحص ما تطلب المحفظة توقيعه والشبكة المحددة، لا اسم زر «Approve» فقط.

غالبًا ما تعني كلمة «Unlimited» قيمة قريبة من أكبر عدد صحيح للرمز. لا تنشئ رموزًا لا نهائية ولا تنقل رصيدك عند الموافقة. لكنها قد تتيح للـspender استخدام الصلاحية لاحقًا مع رموز من النوع نفسه تصل إلى المحفظة نفسها على الشبكة نفسها. بعض التطبيقات تحتفظ بالقيمة القصوى دون إنقاصها؛ تحقّق من سلوك الرمز.

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

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

قبل التوقيع، راجع أربعة أمور: هل الشبكة المختارة هي التي يذكرها التطبيق؟ هل عنوان عقد الرمز صحيح وليس الرمز المختصر فقط؟ هل يطابق عنوان spender الوثائق الرسمية أو بيانات العقد القابلة للتحقق؟ وهل الحد مناسب للعملية أم يترك صلاحية واسعة طويلة الأجل؟

لا تصل المحفظة من رابط في رسالة خاصة أو رمز QR أو محادثة دعم أو إعلان غير موثوق. قد يقلّد موقع التصيد التطبيق الحقيقي. ابدأ من عنوان رسمي محفوظ أو من وثائق المشروع. اسم العقد المألوف لا يثبت صحة العنوان، وعلامة التحقق في مستكشف الكتل لا تضمن أمان العقد.

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

تدعم بعض رموز ERC-20 ERC-2612 permit. بدل إرسال معاملة approve عادية، يوقّع المالك بيانات منظمة، ويمكن لطرف آخر إرسال التوقيع لتعيين allowance. تتضمن رسالة المعيار المالك وspender والقيمة وnonce وdeadline، كما تربط مجال التوقيع بالشبكة والعقد.

إن deadline في ERC-2612 هو آخر وقت يمكن فيه إرسال توقيع permit. ولا يعني أن الصلاحية التي تم تعيينها بنجاح تنتهي تلقائيًا عند ذلك الوقت. قد تبقى حتى تُستخدم أو تُعدّل أو تُلغى. تستخدم بعض الرموز طرق permit مختلفة أو شروط انتهاء إضافية؛ فلا تفترض أن كل طلب يحمل اسم «permit» يتبع ERC-2612.

قد يتيح التوقيع لحساب آخر دفع الرسوم، لكنه ليس بالضرورة تأكيد دخول غير ضار. إذا لم تعرض المحفظة الرمز وspender والقيمة والتوقيت بوضوح، أو خالفت تفاصيل الطلب شرح التطبيق، فارفضه وراجع الوثائق الرسمية. ويمكن لطرف آخر إرسال توقيع لم يُرسل بعد قبل deadline.

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

يتطلب الإلغاء عادةً معاملة على السلسلة تجعل صلاحية ذلك الرمز وspender تساوي صفرًا. وتترتب عليها رسوم شبكة، وقد تبقى الصلاحية القديمة سارية حتى تأكيدها. بعد ذلك حدّث قائمة الموافقات أو استعلم عن العقد مرة أخرى وتأكد من الصفر للمحفظة والشبكة والرمز وspender نفسها. تشرح MetaMask وEthereum.org أدوات الفحص حسب الشبكة؛ تحقّق من النطاق الرسمي والشبكة المختارة.

لكل شبكة حالة مستقلة. تصفير Ethereum لا يغيّر تلقائيًا صلاحية الرمز نفسه على شبكة أخرى. راجع كل حساب وعقد رمز وspender وشبكة ذات صلة، ثم تحقق من النتيجة بعد تأكيد المعاملة. لا تحتاج أداة الإلغاء إلى العبارة السرية أو المفتاح الخاص.

بعد تأكيد allowance بقيمة صفر، لا يمكن لتلك الصلاحية أن تسمح باستدعاء transferFrom جديد. لكنها لا تعكس التحويلات المكتملة، ولا تستعيد الرموز من المستلم، ولا تحذف صلاحيات عقود أخرى. إذا نقل spender مريب الرموز بالفعل، فالإلغاء وحده لا يضمن استعادتها.

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

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

يوصي معيار ERC-20 الواجهات بتصفير allowance غير صفرية قبل استبدالها بقيمة غير صفرية أخرى. إذا دخلت معاملة spender بين الموافقة القديمة والجديدة، فقد يستخدم كمية أكبر مما توقعه المستخدم. مثلًا عند التغيير من 100 إلى 25، قد يستخدم spender المئة القديمة قبل تسجيل الخمسة والعشرين الجديدة ثم يستخدم الجديدة أيضًا.

يقلل تأكيد الصفر أولًا احتمال تداخل القيمتين، لكنه لا يعكس استخدام الصلاحية القديمة قبل تأكيد معاملة الصفر. وقد تتطلب الخطوتان رسومًا، كما تختلف الرموز. اتبع مسار التحديث الآمن الموثق للمحفظة أو الرمز وانتظر التأكيد.

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

1. تأكد من نطاق المشروع الرسمي والشبكة المختارة.
2. تحقّق من عنوان عقد الرمز وspender وقارن الحد بالكمية اللازمة للعملية.
3. اقرأ المعاملة أو البيانات المنظمة التي تعرضها المحفظة. لا توقّع طلبًا لا تفهمه.
4. راجع صلاحيات spender غير المستخدم أو غير الموثوق على الشبكة المناسبة؛ صفّر allowance عند الحاجة وتأكد من النتيجة.
5. عند مقارنة المحافظ، افحص دعم الشبكات ووضوح عرض الموافقات وإرشادات التحديث والاستعادة.

المحفظة العتادية خيار لحفظ المفتاح ومراجعة التوقيع، وليست ضمانًا لأمان العقد أو حاجزًا يمنعك من الموافقة على حد واسع. تحقّق بنفسك من spender والرمز والشبكة والكمية. ويساعد فهم بقاء allowance منفصلة عن اتصال الموقع على مقارنة ميزات أمان المحفظة وحدودها الفعلية.