وظيفة Permit (EIP-2612)

ما وظيفة Permit (EIP-2612)؟

وظيفة Permit، المحددة في EIP-2612، هي امتداد لرموز ERC-20 يتيح لمالك التوكن الموافقة على إنفاق طرف آخر للتوكنات عبر توقيع رسالة خارج السلسلة، بدلاً من إرسال معاملة موافقة منفصلة على السلسلة.

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

توضح المواصفة الرسمية لـ EIP-2612 أن هذا المعيار يوسّع ERC-20 بإضافة وظيفة جديدة باسم

، تعدّل خريطة التخصيص (allowance) باستخدام رسالة موقعة بدلاً من .

ببساطة، تتيح EIP-2612 للمستخدم القول: «أوافق على أن ينفق هذا العقد الذكي هذه الكمية من توكناتي»، وذلك بتوقيع رسالة في المحفظة.

بعد ذلك، يمكن لحساب أو عقد آخر إرسال هذه الموافقة الموقعة إلى البلوكشين.

وهذا يعني أن مالك التوكن لا يحتاج إلى إرسال معاملة الموافقة بنفسه.

كما قد لا يحتاج مالك التوكن إلى الاحتفاظ بتوكن الغاز الأصلي للشبكة لمجرد الموافقة على إنفاق توكن ERC-20.

لا تنقل وظيفة Permit التوكنات بحد ذاتها.

فهي تحدد فقط مبلغاً مسموحاً بإنفاقه، ويمكن استخدامه لاحقاً عبر

أو ضمن مسار عقد آخر يستهلك هذا المبلغ المسموح به.

هذا التمييز أساسي، لأن الموافقة لطرف على الإنفاق لا تعادل إرسال التوكنات إليه.

من الأفضل فهم Permit على أنها تفويض موقّع يحدّث حالة التخصيص في ERC-20 على السلسلة بعد إرسال التوقيع.

أهم النقاط حول وظيفة Permit

• • تضيف EIP-2612 وظائف
    permit
    و
    nonces
    و
    DOMAIN_SEPARATOR
    إلى توكنات ERC-20.
  • تتيح وظيفة Permit للمستخدمين الموافقة على إنفاق توكنات ERC-20 بتوقيع خارج السلسلة.
  • تتبع الرسالة الموقعة قواعد البيانات المهيكلة ذات الأنواع في EIP-712.
  • تغيّر Permit مبلغ التخصيص، لكنها لا تنقل التوكنات بحد ذاتها.
  • تمنع Nonces إعادة استخدام توقيع Permit نفسه.
  • تحدّ المواعيد النهائية من مدة صلاحية Permit الموقعة.
  • تحسّن Permit تجربة المستخدم، لكنها لا تلغي مخاطر الموافقة أو التصيد الاحتيالي عبر التوقيعات.

لماذا أُنشئت EIP-2612؟

تستخدم توكنات ERC-20 نموذج موافقة يتيح لعنوان تفويض عنوان آخر بإنفاق التوكنات نيابةً عنه.

يحدد معيار ERC-20 الأصلي وظائف مثل

و و.

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

لكن مسار الموافقة المعتاد في ERC-20 يتطلب غالباً معاملتين على السلسلة.

المعاملة الأولى هي معاملة

.

أما الثانية فهي إجراء العقد الذكي الفعلي الذي يستخدم التوكنات التي تمت الموافقة عليها.

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

كما يسبب مشكلة للمستخدمين الذين يملكون توكنات ERC-20، لكنهم لا يملكون توكن الغاز الأصلي اللازم لإرسال معاملة الموافقة.

تحل EIP-2612 هذه المشكلة تحديداً عبر إتاحة الموافقة بواسطة رسالة موقعة.

يوقّع مالك التوكن على Permit خارج السلسلة، ويمكن لطرف آخر إرسالها إلى السلسلة.

وهذا يتيح لمسار العقد الذكي دمج الموافقة والإجراء بكفاءة أكبر.

على سبيل المثال، يمكن للمستخدم توقيع Permit، ثم يستهلكها عقد وينقل التوكنات ضمن مسار معاملة واحدة.

لكن هذا لا يجعل معاملات الشبكة مجانية.

فلا يزال هناك من يدفع رسوم الغاز لإرسال Permit إلى السلسلة.

وتتمثل الفائدة في أن دافع رسوم الغاز ليس مضطراً إلى أن يكون مالك التوكن.

آلية عمل وظيفة Permit

تأخذ وظيفة EIP-2612 الأساسية الشكل التالي:

.

يمثل

حامل التوكن الذي يوقّع الموافقة.

يمثل

العنوان الذي سيحصل على مبلغ التخصيص المسموح به.

تمثل

كمية التوكنات المسموح بإنفاقها.

يمثل

آخر وقت يمكن فيه استخدام Permit.

القيم

و و هي أجزاء من التوقيع المشفر.

عند إرسال Permit، يتحقق عقد التوكن من صحة التوقيع.

ويتحقق أيضاً مما إذا كان الموعد النهائي قد انقضى.

كما يتحقق من تطابق nonce المستخدم في الرسالة الموقعة مع nonce الحالي للمالك.

إذا اجتازت جميع عمليات التحقق المطلوبة، يحدد العقد

بالقيمة الموافق عليها.

ثم يزيد العقد nonce الخاص بالمالك لمنع إعادة استخدام التوقيع نفسه.

ويصدر العقد أيضاً حدث

، بما يحافظ على توافق السلوك مع التوقعات المرتبطة بموافقات ERC-20.

تحوّل هذه العملية توقيع المحفظة إلى تحديث لمبلغ التخصيص على السلسلة.

الوظائف الرئيسية الثلاث في EIP-2612

تُلزم EIP-2612 التوكنات المتوافقة بإضافة ثلاث وظائف إلى جانب وظائف ERC-20.

الوظيفة الأولى هي

.

تتحقق وظيفة

من صحة الموافقة الموقعة وتحدّث مبلغ التخصيص.

الوظيفة الثانية هي

.

تعرض وظيفة

قيمة nonce الحالية لعنوان المالك.

الوظيفة الثالثة هي

.

تعرض وظيفة

فاصل نطاق EIP-712 المستخدم لجعل التوقيع خاصاً بعقد توكن ونطاق توقيع محددين.

تعمل هذه الوظائف الثلاث معاً.

يحدد توقيع Permit الموافقة.

ويمنع nonce إعادة تشغيل التوقيع.

ويساعد فاصل النطاق على ربط التوقيع بالعقد والسياق الصحيحين للشبكة.

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

ما المقصود بمبلغ التخصيص (Allowance)؟

مبلغ التخصيص هو كمية توكنات ERC-20 التي وافق مالكها على إتاحتها لطرف آخر لاستخدامها.

على سبيل المثال، إذا وافقت Alice على أن ينفق عقد ذكي 100 توكن، يصبح مبلغ التخصيص من Alice إلى ذلك العقد 100 توكن.

يمكن للطرف المصرح له بعد ذلك استدعاء

لنقل توكنات بما يصل إلى المبلغ الموافق عليه، وفقاً لعقد التوكن ومسار التطبيق.

لا تلغي وظيفة Permit نظام التخصيص.

بل تغيّر طريقة إنشاء مبلغ التخصيص.

فبدلاً من اشتراط استدعاء مالك التوكن لوظيفة

مباشرةً، تتيح EIP-2612 للمالك توقيع رسالة تفوض تحديث مبلغ التخصيص.

يحسّن ذلك سهولة الاستخدام مع الحفاظ على التوافق مع نموذج تخصيص ERC-20 المألوف.

مع ذلك، ينبغي للمستخدمين التعامل بحذر مع مبالغ التخصيص، لأن الطرف الموافق له قد يتمكن من نقل التوكنات ضمن الحد المسموح به.

قد تكون الموافقة على مبلغ غير محدود مريحة، لكنها قد تؤدي أيضاً إلى خسائر كبيرة إذا كان العقد المصرح له ضاراً أو مخترقاً أو أسيء فهمه.

وظيفة Permit مقارنةً بوظيفة Approve

يستدعي مالك التوكن وظيفة

التقليدية مباشرةً ضمن معاملة على السلسلة.

أما وظيفة Permit، فيفوضها مالك التوكن عبر توقيع خارج السلسلة، ثم يرسلها طرف آخر إلى السلسلة لاحقاً.

مع

، يتعين على مالك التوكن دفع رسوم الغاز لمعاملة الموافقة.

أما مع

، فيوقّع مالك التوكن رسالة، ويمكن لجهة وسيطة أو تطبيق أو طرف مُنفق دفع رسوم الغاز لإرسالها.

في حالة

، يرتبط إجراء الموافقة مباشرةً بـ .

أما في حالة

، فيرتبط إجراء الموافقة بتوقيع موثّق صادر عن المالك.

قد تكون النتيجة تحديث مبلغ التخصيص نفسه، لكن تجربة المستخدم تختلف.

ولهذا توصف EIP-2612 غالباً بأنها تتيح الموافقات دون رسوم غاز على المستخدم.

والأدق أنها تتيح الموافقات من دون أن يضطر مالك التوكن إلى إرسال معاملة الموافقة بنفسه.

فلا تزال البلوكشين تتطلب معاملة ورسوم غاز لتحديث الحالة.

أهمية EIP-712 لوظيفة Permit

تستخدم EIP-2612 بيانات مهيكلة ذات أنواع تستند إلى EIP-712.

يمثل EIP-712 معياراً لتجزئة البيانات المهيكلة وتوقيعها بدلاً من توقيع سلاسل بايتات مبهمة.

وهذا مهم لأن مستخدمي المحافظ يحتاجون إلى فهم ما يوقعون عليه.

قد يكون طلب توقيع سلسلة سداسية عشرية خام مربكاً وخطيراً.

يمكن للتوقيع ذي البيانات المهيكلة أن يعرض حقولاً مثل المالك والطرف المُنفق والقيمة وnonce والموعد النهائي بوضوح أكبر.

ويستخدم EIP-712 أيضاً فاصل نطاق.

يساعد فاصل النطاق على الفصل بين سياق توقيع وآخر.

في EIP-2612، يتضمن ذلك عادةً معلومات مثل اسم التوكن وإصداره ومعرّف الشبكة وعنوان العقد المُتحقِّق.

يساعد هذا التصميم على منع صلاحية توقيع مخصص لتوكن أو شبكة معينة في سياق مختلف.

ويشير EIP-712 نفسه إلى أنه لا يوفر حماية من إعادة التشغيل بمفرده.

وتضيف EIP-2612 الحماية من إعادة التشغيل عبر قيم nonce منفصلة لكل مالك.

Nonces والحماية من إعادة التشغيل

Nonce هو رقم يُستخدم مرة واحدة.

في EIP-2612، يتتبع عقد التوكن قيمة nonce لكل عنوان مالك.

عندما يوقّع المستخدم على Permit، تتضمن البيانات الموقعة قيمة nonce الحالية للمالك.

بعد استخدام Permit بنجاح، يزيد عقد التوكن قيمة nonce.

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

وهذا يؤدي إلى رفض التوقيع المُعاد استخدامه.

تُعد الحماية باستخدام nonce ضرورية لأن التوقيعات قابلة للنسخ.

ومن دونها، قد يعيد طرف مُنفق أو مهاجم استخدام Permit الموقعة نفسها عدة مرات.

يجب أن يتعامل التنفيذ الجيد لـ Permit مع قيم nonce بوصفها جزءاً من الرسالة الموقعة، وألا يحدّثها إلا عند نجاح Permit.

أما بالنسبة إلى المستخدمين، فالمعنى العملي بسيط.

ينبغي أن يكون توقيع Permit صالحاً للاستخدام مرة واحدة، لا إلى الأبد.

المواعيد النهائية وانتهاء صلاحية التوقيع

يحدّ معامل

من مدة صلاحية توقيع Permit.

إذا تجاوز الطابع الزمني للكتلة الحالية الموعد النهائي، فينبغي رفض Permit.

يحمي ذلك المستخدمين من إرسال توقيعات قديمة بعد وقت طويل من توقيعها للاستخدام.

قد يقلل تحديد موعد نهائي قريب المخاطر لأنه يحد من الفترة المتاحة للإرسال.

وقد يزيد الموعد النهائي البعيد سهولة الاستخدام لأن التوقيع يظل صالحاً مدة أطول.

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

ينبغي للمستخدمين الانتباه إلى المواعيد النهائية عندما تعرض المحافظ بيانات Permit المهيكلة.

كما ينبغي للمطورين تجنب المواعيد النهائية الواسعة جداً ما لم يكن هناك سبب واضح لذلك.

وينبغي للتطبيقات شرح معنى الموعد النهائي بطريقة مفهومة للمستخدمين.

فاصل النطاق وسياق الشبكة

يُعد فاصل النطاق جزءاً أساسياً من التوقيع وفق EIP-712.

وفي EIP-2612، يساعد على ربط Permit بعقد توكن ونطاق محددين.

يتضمن النطاق الشائع اسم التوكن وإصداره ومعرّف الشبكة وعنوان العقد المُتحقِّق.

يقلل ذلك احتمال إعادة تشغيل Permit موقعة لعقد معين على عقد آخر.

كما يقلل احتمال إعادة استخدام Permit موقعة على شبكة في شبكة أخرى.

لكن أمان فاصل النطاق يعتمد على تنفيذه على نحو صحيح.

إذا استخدم عقد التوكن فاصل نطاق غير مكتمل، فقد تزداد مخاطر إعادة التشغيل.

وإذا تغيّر معرّف الشبكة أو نُشر العقد على عدة شبكات، فعلى المطورين التفكير بعناية في كيفية فصل التوقيعات.

غالباً ما يكون فاصل النطاق مخفياً عن المستخدمين خلف واجهة المحفظة.

أما بالنسبة إلى المطورين، فهو من أهم التفاصيل في تنفيذ Permit آمن.

شرح الموافقات دون رسوم غاز

قد تكون عبارة «الموافقة دون رسوم غاز» مربكة.

لا تجعل EIP-2612 معاملات Ethereum أو EVM مجانية.

إنها تتيح لمالك التوكن الموافقة على الإنفاق بتوقيع رسالة بدلاً من إرسال معاملة.

بعد ذلك، يمكن لجهة وسيطة أو تطبيق أو عقد ذكي أو طرف مُنفق إرسال Permit الموقعة إلى السلسلة ودفع رسوم الغاز.

قد يساعد ذلك المستخدمين الذين يملكون توكنات ERC-20 لكن لا يملكون ما يكفي من توكن الغاز الأصلي للموافقة على إنفاقها.

كما قد يساعد التطبيقات على توفير تجربة أسهل من خطوة واحدة.

على سبيل المثال، قد يوقّع المستخدم على Permit ثم يكمل إيداعاً أو دفعة أو إجراءً متعلقاً بالتوكن من دون إرسال موافقة منفصلة يدوياً أولاً.

تبدو تجربة المستخدم أبسط، لكن البلوكشين تظل تسجل تغيير الحالة عبر معاملة على السلسلة.

ينبغي للمطورين توضيح ذلك، لأن المستخدمين قد يظنون خلاف ذلك أن الرسائل الموقعة لا تترتب عليها عواقب.

قد تترتب على توقيع Permit عواقب فعلية على السلسلة بعد إرساله من طرف ما.

حالات استخدام EIP-2612 الشائعة في الكريبتو

تُستخدم EIP-2612 غالباً في التمويل اللامركزي والتطبيقات القائمة على التوكنات.

قد يستخدم بروتوكول إقراض Permit لتمكين المستخدم من الموافقة على الضمان وإيداعه ضمن مسار واحد.

وقد يستخدم عقد Staking Permit لتمكين المستخدم من الموافقة على توكنات التخزين من دون معاملة موافقة منفصلة.

وقد يستخدم تطبيق دفع Permit لتمكين الدافع من تفويض نقل التوكنات عبر عملية دفع أكثر سلاسة.

وقد تستخدم المحفظة Permit لتقليل عدد خطوات المعاملات في تفاعلات ERC-20 الشائعة.

وقد تستخدم خدمة وسيطة Permit لدفع رسوم الغاز نيابةً عن المستخدم واسترداد الرسوم بطريقة أخرى.

يمكن للعقد الذكي دمج Permit مع

لتتم الموافقة ونقل التوكنات ضمن مسار المعاملة نفسه.

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

وقد يقلل أيضاً من الالتباس، إذ يمكن للتطبيق إرشاد المستخدم خلال عملية واحدة متكاملة.

لا تقتصر الفائدة الرئيسية على توفير رسوم الغاز.

بل تتمثل أساساً في تقليل التعقيد المرتبط بتفويض استخدام التوكنات.

وظيفة Permit وتجريد الحساب

تُناقش وظيفة Permit أحياناً مع تجريد الحساب، لأن كليهما يحسّن تجربة استخدام المحافظ.

تتيح Permit لمالك توكن ERC-20 تفويض تغييرات مبلغ التخصيص عبر التوقيعات.

ويهدف تجريد الحساب إلى جعل حسابات الكريبتو أكثر قابلية للبرمجة والمرونة.

هما أداتان مختلفتان، لكنهما تشتركان في هدف عام متقارب.

إذ تسعيان كلتاهما إلى تقليل تعقيد التفاعلات مع البلوكشين.

تركز Permit على الموافقات المتعلقة بالتوكنات.

أما تجريد الحساب فيركز بصورة أوسع على كيفية تفويض الحسابات للإجراءات ودفع تكلفتها.

يمكن لتطبيق للعملات المشفرة استخدام الفكرتين معاً في تصميم المنتج نفسه.

على سبيل المثال، قد يدعم نظام محفظة أو حساب ذكي المعاملات المدعومة، مع استخدام موافقات للتوكنات متوافقة مع Permit.

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

مخاطر الأمان في وظيفة Permit

أبرز المخاطر التي تواجه المستخدمين هي التصيد الاحتيالي عبر التوقيعات.

قد يطلب موقع ضار من المستخدم توقيع Permit تمنح طرفاً مُنفقاً خطيراً صلاحية الإنفاق.

ولأن توقيع Permit ليس تحويلاً عادياً للتوكنات، قد يظن بعض المستخدمين أنه غير ضار.

وهذا افتراض خطير.

قد تفوض Permit طرفاً مُنفقاً بنقل التوكنات لاحقاً.

ينبغي للمستخدمين مراجعة عنوان الطرف المُنفق ومقدار التوكنات واسم التوكن والموعد النهائي قبل التوقيع.

وينبغي رفض التوقيعات غير الواضحة أو غير المتوقعة أو التي تطلبها مواقع مجهولة.

ومن المخاطر الأخرى الموافقة على مبلغ غير محدود.

إذا وقّع المستخدم على Permit بقيمة كبيرة جداً، فقد يحصل الطرف المُنفق على صلاحية واسعة للإنفاق ضمن تخصيص ذلك التوكن.

الخطر الثالث هو التنفيذ غير السليم.

إذا لم يتعامل عقد التوكن مع قيم nonce أو فصل النطاق أو استعادة التوقيع أو المواعيد النهائية على نحو صحيح، فقد يُعاد تشغيل التوقيعات أو تُقبل رغم وجوب رفضها.

الخطر الرابع هو الالتباس الناتج عن واجهة المستخدم.

إذا لم تعرض المحفظة البيانات المهيكلة بوضوح، فقد يوقّع المستخدمون على موافقات لا يفهمونها.

تحسّن Permit سهولة الاستخدام، لكنها تزيد أيضاً أهمية التوعية بالتوقيعات.

Permit لا تلغي مخاطر الموافقة

تغيّر EIP-2612 طريقة تفويض الموافقة، لكنها لا تغيّر المخاطر الأساسية لمنح طرف صلاحية الإنفاق.

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

قد تكون موافقة Permit بقدر قوة معاملة

العادية.

يكمن الاختلاف في أن الموافقة تبدأ كتوقيع، لا كمعاملة يرسلها مالك التوكن.

لذلك ينبغي للمستخدمين التعامل مع توقيعات Permit بالحذر نفسه الذي يتعاملون به مع معاملات الموافقة.

ينبغي تجنب توقيع Permits غير محدودة ما لم يثق المستخدمون بالطرف المُنفق تماماً ويفهموا المخاطر.

وينبغي إلغاء مبالغ التخصيص غير المستخدمة عندما لا تعود مطلوبة.

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

ينبغي التحقق من عناوين العقود من مصادر موثوقة قبل الموافقة على الوصول إلى التوكنات القيّمة.

Permit والسبق في تقديم المعاملات (Front-Running)

يمكن لأي شخص يملك الرسالة الموقعة إرسال توقيعات Permit.

وهذا يطرح اعتباراً خاصاً يتعلق بالسبق في تقديم المعاملات.

إذا وقّع المستخدم على Permit وأرسلها إلى تطبيق، فقد يرسلها طرف آخر اطلع على التوقيع قبله.

في كثير من الحالات، لا يؤدي ذلك إلا إلى استهلاك Permit وتحديد مبلغ التخصيص نفسه الذي قصده المستخدم.

لكن إذا توقع التطبيق تنفيذ Permit وإجراء آخر معاً، فقد يؤدي إرسال Permit مسبقاً إلى فشل المعاملة المجمّعة اللاحقة، لأن قيمة nonce تكون قد تغيرت.

ينبغي للمطورين تصميم مسارات تتعامل مع هذه الحالة بسلاسة.

يمكن للعقد الذكي في كثير من الأحيان التحقق مما إذا كان مبلغ التخصيص المتوقع متاحاً بالفعل، ثم المتابعة بدلاً من الفشل دون داعٍ.

وينبغي لواجهات المستخدم أيضاً شرح تعثر مسارات Permit بوضوح.

أما النقطة الأساسية للمستخدمين فهي أن Permits الموقعة تظل قابلة للنقل إلى حين استخدامها أو انتهاء صلاحيتها.

لا تشارك بيانات Permit الموقعة ما لم تكن تثق بالمسار المستخدم.

اعتبارات التنفيذ للمطورين

ينبغي للمطورين الالتزام بمواصفة EIP-2612 بدقة.

يجب أن يتطابق تجزئة نوع Permit مع بنية التوقيع المتوقعة.

ينبغي أن يستخدم الملخص ترميز EIP-712 مع فاصل النطاق وتجزئة بنية Permit.

ينبغي للعقد رفض Permits منتهية الصلاحية.

وينبغي له رفض التوقيعات غير الصالحة.

كما ينبغي له رفض Permits التي لا يكون الموقّع المستعاد فيها هو المالك.

وينبغي للعقد رفض الحالات غير المناسبة التي يكون فيها المالك هو العنوان الصفري.

ينبغي للعقد زيادة nonce الخاص بالمالك بعد تنفيذ Permit بنجاح.

وينبغي للعقد إصدار حدث

القياسي بعد تغيير مبالغ التخصيص.

ينبغي للمطورين استخدام مكتبات خضعت لمراجعة جيدة متى أمكن.

توفر وثائق ERC20Permit من OpenZeppelin نمط تنفيذ واسع الاستخدام لمشاريع Solidity.

وتوثق OpenZeppelin أيضاً استخدام ERC-20 Permit في بيئات أخرى، مثل ERC-20 Permit for Stylus.

حتى عند استخدام مكتبة، ينبغي للمطورين اختبار سلوك التوكن المحدد بعناية.

وظيفة Permit مقارنةً بالمعاملات الوصفية (Meta-Transactions)

المعاملة الوصفية هي نمط أوسع يوقّع فيه المستخدم على رسالة ويرسل طرف آخر معاملة نيابةً عنه.

يمكن النظر إلى EIP-2612 على أنها نمط توقيع محدد يركز على الموافقات.

ولا تعمم الإجراءات المتعلقة بالتوكنات كلها لتصبح إجراءات موقعة.

إنها توحّد الموافقات الموقعة لمبالغ تخصيص ERC-20 فقط.

هذا النطاق المحدود مقصود.

فالمعيار المحدود أسهل في الاعتماد والدمج عبر المحافظ والعقود والتطبيقات.

قد يحتاج المطورون الراغبون في عمليات نقل موقعة أو إجراءات مجمعة أو رعاية مخصصة لرسوم الغاز إلى عقود أو معايير إضافية.

تكتسب Permit قوتها من حل مشكلة شائعة من دون تغيير نموذج ERC-20 بأكمله.

وهي تكمّل أنظمة المعاملات الوصفية بدلاً من أن تحل محلها جميعاً.

وظيفة Permit مقارنةً بنقل التوكنات

Permit ليست عملية نقل.

تنقل عملية النقل التوكنات من عنوان إلى آخر.

أما Permit فتحدّث مبلغ التخصيص الذي يمنحه عنوان لعنوان آخر.

وهذا يعني أن المستخدم قد يوقّع على Permit وتظل التوكنات في المحفظة نفسها إلى أن يستخدم الطرف المُنفق مبلغ التخصيص.

عادةً ما يتم نقل التوكنات فعلياً عبر

.

هذا الاختلاف مهم لأمان المحافظ.

قد لا يرى المستخدم تغيراً فورياً في رصيد التوكنات بعد توقيع Permit.

لكن ذلك لا يعني أن التوقيع غير ضار.

فقد يظل الطرف المُنفق مخولاً بنقل التوكنات لاحقاً.

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

وظيفة Permit مقارنةً بـ Permit2

EIP-2612 معيار على مستوى التوكن.

يجب أن ينفذ عقد التوكن نفسه وظيفة Permit حتى يدعم التوكن معيار EIP-2612.

وقد توفر أنظمة موافقة أخرى سلوكاً شبيهاً بـ Permit عبر عقود خارجية.

لكن هذه الأنظمة ليست مماثلة للدعم الأصلي لـ EIP-2612.

ويهم هذا الاختلاف لأن مطالبات المحفظة وعناوين الأطراف المُنفقة وأنظمة nonce ونطاقات الموافقة ومسارات الإلغاء قد تختلف.

عندما يوقّع المستخدم على موافقة شبيهة بـ Permit، ينبغي له التحقق من العقد الذي سيحصل على الصلاحية.

وعندما يدمج المطورون Permits، ينبغي لهم التحقق مما إذا كان التوكن يدعم EIP-2612 مباشرةً أو يتطلب آلية موافقة مختلفة.

إن وصف كل موافقة موقعة بأنها «EIP-2612» قد يسبب الالتباس.

فلدى EIP-2612 واجهة وبنية توقيع محددتان.

كيفية قراءة المستخدمين لطلب توقيع Permit

ينبغي للمستخدم أولاً التحقق من اسم التوكن.

ثم التحقق من عنوان الطرف المُنفق أو التطبيق الذي يطلب الإذن.

وينبغي التحقق من المبلغ الموافق على إنفاقه.

كما ينبغي التأكد مما إذا كانت القيمة محدودة أو غير محدودة عملياً.

ويجب التحقق من الموعد النهائي.

وينبغي التأكد من أن الطلب ظهر بعد إجراء مقصود.

على المستخدم رفض الطلب إذا ظهر بشكل غير متوقع.

وينبغي توخي حذر إضافي إذا طلب الموقع عدة توقيعات متتالية.

كما ينبغي تجنب توقيع رسائل Permit من روابط في الرسائل المباشرة أو محادثات الدعم المزيفة أو الإعلانات المشبوهة أو صفحات التوكنات المجهولة.

ينبغي تذكر أن توقيع Permit قد يمنح عنواناً آخر صلاحية إنفاق التوكنات.

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

لماذا تحسّن Permit تجربة المستخدم؟

تحسّن Permit تجربة المستخدم من خلال تقليل عدد المعاملات المطلوبة على السلسلة.

وقد تلغي خطوة الموافقة المنفصلة في كثير من مسارات التطبيقات اللامركزية.

كما قد تتيح للمستخدمين التفاعل مع توكنات ERC-20 حتى عندما لا يملكون ما يكفي من توكن الغاز الأصلي لإرسال موافقة مستقلة.

وقد تساعد التطبيقات على رعاية رسوم الغاز أو تجميع الموافقة مع إجراء آخر.

كما قد تقلل حالات تعثر المستخدمين الذين يوافقون على توكن ثم ينسون إكمال المعاملة الثانية.

وقد تجعل عملية التسجيل أسهل للمستخدمين الجدد على التطبيقات القائمة على السلسلة.

تكتسب هذه الفوائد أهمية خاصة لأن موافقات ERC-20 من أكثر نقاط الاحتكاك شيوعاً في عالم العملات المشفرة.

لكن سلاسة الموافقة لا تعني تلقائياً أنها أكثر أماناً.

يجب أن تقترن تجربة المستخدم الجيدة بمطالبات توقيع واضحة وتصميم دقيق للأطراف المُنفقة وإدارة سهلة لمبالغ التخصيص.

أخطاء شائعة في استخدام EIP-2612

من الأخطاء الشائعة الاعتقاد بأن Permit تنقل التوكنات فوراً.

فهي تحدّث مبلغ التخصيص فقط.

ومن الأخطاء الشائعة أيضاً الاعتقاد بأن الموافقة دون رسوم غاز تعني أن لا أحد يدفع رسوم الغاز.

إذ لا تزال Permit تحتاج إلى معاملة على السلسلة لتحديث حالة العقد.

والخطأ الثالث هو توقيع موافقات غير محدودة دون فهم مخاطر الطرف المُنفق.

والخطأ الرابع هو تجاهل حقل الموعد النهائي.

والخطأ الخامس هو الوثوق بطلب توقيع لمجرد أنه لا يبدو كمعاملة عادية.

والخطأ السادس هو افتراض أن كل توكنات ERC-20 تدعم EIP-2612.

والخطأ السابع هو دمج Permit من دون اختبار سلوك معرّف الشبكة وفاصل النطاق وnonce عبر عمليات النشر المختلفة.

والخطأ الثامن هو التعامل مع جميع الأنظمة الشبيهة بـ Permit كما لو كانت مطابقة لـ EIP-2612.

والخطأ التاسع هو عدم التعامل مع إرسال Permit مسبقاً في مسارات العقود المجمّعة.

والخطأ العاشر هو عرض مطالبات Permit بطريقة يصعب على المستخدمين فهمها.

أفضل الممارسات للمستخدمين

لا توقّع رسائل Permit إلا على المواقع والتطبيقات التي تثق بها.

راجع التوكن والطرف المُنفق والمبلغ والموعد النهائي قبل التوقيع.

تجنب الموافقات غير المحدودة ما لم يوجد سبب وجيه لها.

استخدم مبالغ موافقة صغيرة متى أمكن.

ألغِ مبالغ التخصيص القديمة التي لم تعد مطلوبة.

لا توقّع رسائل Permit المرسلة عبر روابط عشوائية أو رسائل دعم مزيفة أو صفحات إيردروب مجهولة.

استخدم محفظة منفصلة للتطبيقات اللامركزية التجريبية ومحفظة أخرى للاحتفاظ طويل الأجل.

تحقق من تحذيرات المحفظة بعناية.

لا تفترض أن التوقيع آمن لمجرد أنه لا يعرض رسوم غاز مباشرةً.

تذكر أن شخصاً آخر قد يرسل Permit موقعة لاحقاً قبل انتهاء صلاحيتها.

أفضل الممارسات للمطورين

استخدم تنفيذات Permit خاضعة للتدقيق وجيدة الصيانة متى أمكن.

التزم بواجهة EIP-2612 الرسمية بدقة عند الادعاء بدعم المعيار.

استخدم البيانات المهيكلة ذات الأنواع في EIP-712 كي تتمكن المحافظ من عرض معلومات التوقيع بوضوح.

نفّذ فصل النطاق على نحو صحيح.

تتبّع قيم nonce لكل عنوان مالك.

ارفض التوقيعات منتهية الصلاحية.

ارفض الموقّعين غير الصالحين وحالات العنوان الصفري للمالك.

أصدر حدث

بعد تحديث مبالغ التخصيص بنجاح.

صمّم مسارات Permit المجمّعة بحيث تتعامل مع إرسال Permit قبل المعاملة الرئيسية.

اعرض أسماء الأطراف المُنفقة ومبالغ التوكنات وتفاصيل انتهاء الصلاحية للمستخدمين بلغة واضحة.

وفّر وثائق سهلة تشرح للمستخدمين كيفية إلغاء مبالغ التخصيص.

اختبر التوقيعات عبر معرّفات الشبكات والتفرعات والترقيات ومزودي المحافظ.

وظيفة Permit في جملة واحدة

تتيح وظيفة Permit في EIP-2612 لمالك توكن ERC-20 الموافقة على إنفاق طرف آخر عبر توقيع EIP-712، ما يسمح بتحديث مبلغ التخصيص على السلسلة من دون أن يرسل المالك معاملة موافقة منفصلة.

الأسئلة الشائعة

ما وظيفة Permit في EIP-2612؟

وظيفة Permit امتداد لـ ERC-20 يتيح لمالك التوكن الموافقة لطرف على الإنفاق بتوقيع خارج السلسلة يمكن إرساله لاحقاً إلى السلسلة.

هل تنقل Permit التوكنات؟

لا، تقتصر Permit على تحديد مبلغ التخصيص ولا تنقل التوكنات بحد ذاتها.

ما فائدة EIP-2612؟

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

هل يدفع مالك التوكن رسوم الغاز عند استخدام Permit؟

لا يحتاج مالك التوكن إلى إرسال معاملة الموافقة، لكن لا بد أن يدفع أحدهم رسوم الغاز لإرسال Permit الموقعة إلى السلسلة.

ما الفرق بين approve وpermit؟

يمثل approve معاملة على السلسلة يرسلها مالك التوكن، بينما تمثل permit توقيعاً خارج السلسلة يمكن لطرف آخر إرساله إلى السلسلة.

ما علاقة EIP-712 بـ Permit؟

يوفر EIP-712 توقيعاً لبيانات مهيكلة ذات أنواع، ما يساعد المحافظ على عرض تفاصيل Permit بوضوح أكبر، كما يساعد على ربط التوقيعات بنطاق محدد.

ما nonce في EIP-2612؟

Nonce قيمة خاصة بكل مالك تمنع إعادة استخدام توقيع Permit نفسه.

ما الموعد النهائي في Permit؟

الموعد النهائي هو وقت انتهاء الصلاحية الذي ينبغي بعده ألا يظل توقيع Permit صالحاً.

هل EIP-2612 آمن؟

قد يكون EIP-2612 آمناً عند تنفيذه واستخدامه على نحو صحيح، لكن ينبغي للمستخدمين الانتباه إلى التصيد الاحتيالي عبر التوقيعات والموافقات غير المحدودة والأطراف المُنفقة الضارة ومطالبات المحافظ غير الواضحة.

هل تدعم جميع توكنات ERC-20 وظيفة Permit؟

لا، لا يدعم وظيفة Permit القياسية إلا توكن ERC-20 الذي ينفذ امتداد EIP-2612.

هل يمكن تقديم توقيع Permit مسبقاً؟

نعم، يمكن لأي شخص يملك توقيع Permit صالحاً إرساله قبل معاملة أخرى، لذلك ينبغي للمطورين تصميم مسارات تتعامل مع هذا الاحتمال.

كيف يمكن للمستخدمين تقليل مخاطر Permit؟

يمكن للمستخدمين تقليل مخاطر Permit عبر التحقق من الطرف المُنفق، والحد من مبالغ الموافقة، واستخدام مواعيد نهائية قصيرة، وتجنب المواقع المشبوهة، وإلغاء مبالغ التخصيص غير المستخدمة.

الخاتمة

تُعد وظيفة Permit في EIP-2612 من أهم التحسينات التي طرأت على تجربة الموافقة في ERC-20.

فهي تتيح للمستخدمين تفويض مبالغ تخصيص التوكنات باستخدام التوقيعات بدلاً من معاملات الموافقة المنفصلة.

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

يعتمد المعيار على البيانات المهيكلة ذات الأنواع في EIP-712، وفصل النطاق، وقيم nonce، والمواعيد النهائية لجعل الموافقات الموقعة أكثر أماناً وتحديداً.

لكن Permit لا تلغي المخاطر الأساسية لمبالغ تخصيص التوكنات.

فقد يمنح توقيع Permit طرفاً مُنفقاً صلاحية فعلية على توكنات المستخدم.

ينبغي للمستخدمين التعامل مع توقيعات Permit بالجدية نفسها التي يتعاملون بها مع معاملات الموافقة.

وينبغي للمطورين تنفيذ المعيار بعناية، وعرض معلومات التوقيع بوضوح، والتعامل مع الحالات الخاصة مثل الحماية من إعادة التشغيل والتوقيعات منتهية الصلاحية وإرسال Permit مسبقاً.

عند استخدام EIP-2612 على نحو صحيح، تصبح توكنات ERC-20 أسهل استخداماً من دون تغيير الفكرة الأساسية لإنفاق التوكنات عبر مبالغ التخصيص.

إنه معيار صغير لكنه مهم، يحسّن سهولة استخدام تطبيقات العملات المشفرة عملياً، مع الحفاظ على التوافق مع منظومة ERC-20 الأوسع.