في عالم سلسلة الكتل، يحتاج المستخدمون في كثير من الأحيان إلى منح الأذونات (السماحيات) التي تسمح للعقود الذكية بإنفاق الرموز نيابة عنهم. على سبيل المثال، عند استخدام بورصة لامركزية (DEX) لتبادل الرموز، يجب على المستخدم أن يفوض أولاً عقد التبادل لنقل كمية معينة من الرموز من محفظتهم. في إطار النظام التقليدي ERC-20وفقًا للمعيار، يتطلب هذا العملية عمليتين منفصلتين على السلسلة: واحدة للموافقة والأخرى لنقل الرمز المميز فعليًا. هذه العملية ذات خطوتين ليست فقط مُعقدة بل تترتب عليها رسوم غاز إضافية. من أجل تحسين تجربة المستخدم والأمان على حد سواء، قدمت مجتمع الإيثيريوم آلية تفويض معتمدة على التوقيع.تصريح(مثل EIP-2612)، وبعد ذلك تم تطوير نسخة متقدمة تسمى Permit2. تتيح هذه الآليات الجديدة للمستخدمين منح موافقات الرموز من خلال التواقيع خارج الشبكة، مما يتجنب الحاجة إلى معاملات إضافية على الشبكة.

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

أساسيات نموذج تفويض ERC-20

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

كيف تعمل موافقات ERC-20 التقليدية

ERC-20 هو المعيار للرموز على إيثيريوم. يحدد وظائف مثل الموافقة والتحويل من, التي تمكّن معًا من تفويض الرموز. التفويض هنا يعني أن حامل الرمز (المالك) يسمح لحساب آخر، عادةً عقد ذكي (المصروف)، بنقل مبلغ معين من الرموز نيابة عنه. يعمل العملية الأساسية مثل هذا:

1. يقوم حامل الرمز بدعوة وظيفة الموافقة على عقد الرمز الممول (المصروف، المبلغ). يتم تسجيل هذا المبلغ المسموح به في تعيين العقد الداخلي، المعبر عادة عنه كالتالي: allowance[owner][spender] = amount. على سبيل المثال، إذا قام المستخدم A بتخويل عقد Uniswap لإنفاق ما يصل إلى 100 رمز، سيقوم العقد بتخزين allowance[A][Uniswap] = 100. يتطلب هذه الخطوة عملية تحويل على السلسلة ورسوم غاز يدفعها A.
2. نائب.iod نقل (transferFrom): في وقت لاحق، عندما يحتاج Uniswap (أو تطبيق dApp آخر) لإنفاق الرموز بالنيابة عن A، يقوم بالاتصال بـ transferFrom(A, B, المبلغ) على عقد الرمز. يتحقق العقد مما إذا كانت الباحثة[A][Uniswap] كافية. إذا كانت كذلك، يقوم العقد بنقل المبلغ المحدد من A إلى B ويخصم هذا المبلغ من الباحثة.

القيود والتحديات لنموذج الموافقة

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

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

إدارة الموافقات المتشظية
عندما يتفاعل المستخدمون مع العديد منتطبيقات الويب الموزعةعند استخدام نفس الرمز (على سبيل المثال، التداول على Uniswap ثم الإيداع في بروتوكول DeFi مختلف)، يتطلب كل تطبيق للذكاء الاصطناعي موافقة منفصلة، على الرغم من أنه نفس الرمز في نفس المحفظة. وهذا يؤدي إلى الموافقات المتكررة، مما يضيع الوقت والغاز.

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

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

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

تصريح: تفويض ERC-20 القائم على التوقيع (EIP-2612)

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

كيف يعمل التصريح

التصريح هو آلية تفويض تعتمد على التواقيع الرقمية. بموجب المعيار EIP-2612، تضيف عقود ERC-20 التي تدعم التصريح وظيفة تسمى permit() التي تبدو كما يلي:

وظيفة تصريح(
مالك العنوان، المنفق عنوان،
قيمة uint256، الموعد النهائي uint256،
uint8 v، bytes32 r، bytes32 s
) خارجي;

هنا، المالك، المنفق، والقيمة تحدد من يعطي الإذن، ومن يتلقى الإذن، والمبلغ المسموح به. الموعد النهائي يشير إلى متى ينتهي الإمضاء. تشكل المعلمات v، r، وs ECDSAالتوقيع الرقمي. باستخدام تصريح، يتجاوز المستخدمون الموافقة الفردية على السلسلة الفرعية - ببساطة يوقعون على الرسالة (دون دفع الغاز) ويضمنون هذا التوقيع مع عمليتهم لاستكمال التفويض في خطوة واحدة.

عملية التصريح

بالمقارنة مع الموافقة التقليدية، يزيل تصريح الحاجة إلى عملية سلسلة إضافية على السلسلة، مما يوفر الوقت ورسوم الغاز. كما يتيح التحكم الدقيق في الموافقات. على سبيل المثال، يمكن لمستخدم توقيع تصريح يسمح بإنفاق 50 دولارًا أمريكيًا تمامًا، صالح لمدة 5 دقائق فقط. حتى إذا تم تعريض التوقيع، يصبح غير قابل للاستخدام بعد الموعد النهائي، مما يقلل من المخاطر. اليوم، تدعم العديد من بروتوكولات الديفي، مثل التبادلات اللامركزية ومنصات الإقراض، بالفعل التصريح. أمثلة معروفة تشمليونيسواب V2/V3رموز LP،DAI، وUSDC, التي قد نفذت معيار EIP-2612، مما يتيح الموافقات بناءً على التوقيع في خطوة واحدة.

ومع ذلك، فإن أكبر قيد لـ Permit هو أنه يجب تنفيذه مباشرة داخل عقد الرمز المميز. إذا لم يضف مطور رمز مميز طريقة permit() - الأمر الذي يعني عدم دعم EIP-2612 - فإنه ببساطة لا يمكن استخدام Permit. نظرًا لأن EIP-2612 تم تقديمها فقط في عام 2020، فإن العديد من الرموز المميزة القديمة لا تتضمنها، وحتى الرموز الجديدة لا تعتمدها دائمًا. وهذا يقيد قابلية استخدام Permit: الرموز غير المدعومة تتطلب ما زال استخدام تدفق الموافقة التقليدي.

مشكلة أخرى هي أن برامج المحافظ يجب أن تتعامل بشكل صحيح وتعرض تواقيع التصريح بشكل صحيح، والتي عادة ما تكون مهيأة باستخدام EIP-712. تدعم معظم المحافظ الرئيسية ذلك الآن، ولكن بعضها لا يزال يعرض البيانات الخام بدلاً من الرسائل التي يمكن قراءتها بواسطة الإنسان، مما يجعل من الصعب على المستخدمين فهم ما يوقعون عليه. بدون واجهة واضحة لـ EIP-2612، قد تعوق المحافظ فهم موافقات التوقيع. علاوة على ذلك، في حالات النشر الموازي (مثل العقود ذات العناوين المماثلة على سلاسل مختلفة)، يمكن إعادة استخدام التواقيع بشكل محتمل في بيئات أخرى. لذا يجب على المستخدمين التحقق من أن معرف السلسلة وعنوان العقد في تواقيعهم يتطابقان مع البيئة الحالية لمنع إعطاء الأذونات الممنوحة للرموز على سلسلة A من الاستخدام السيئ من قبل عقود مماثلة على سلسلة B.

في جوهرها ، تعمل Permit على تحسين كفاءة ومرونة موافقات ERC-20 بشكل كبير ، مما يمثل معلما رئيسيا في آليات الموافقة الخالية من الغاز. ومع ذلك ، فهو ليس حلا مثاليا: فهو يتطلب دعما على مستوى الرمز المميز ، ويقدم مخاطر جديدة. بعد ذلك ، سنفحص كيف يبني تصريح Uniswap 2 على الأساس الذي وضعه التصريح ويوسعه.

Permit2: عقد إدارة الترخيص العالمي

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

كيف يعمل تصريح 2

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

1. تفويض إذن مرة واحدة: يوافق المستخدمون على إذن مرة واحدة لكل رمز باستخدام الأسلوب التقليدي الموافقة (إذن مرة واحدة ، الحد الأقصى). يُوصى باستخدام كمية كبيرة أو غير محدودة نظرًا لأن هذا هو الموافقة الرئيسية. بمجرد الانتهاء ، يكتسب عقد إذن مرة واحدة القدرة على استدعاء transferFrom نيابة عن المستخدم لذلك الرمز. يتطلب هذا معاملة على سلسلة الكتل ولكن يحتاج فقط إلى القيام به مرة واحدة.
2. التوقيع خارج السلسلة للتفويض الفرعي: عندما يرغب المستخدمون في التفاعل مع تطبيق لامركزي (على سبيل المثال، باستخدام راوتر يونيسواب العالمي لتبديل العملات المتعددة)، يوقعون رسالة تفويض خارج السلسلة وفقًا لمواصفات Permit2. يتضمن هذا التوقيع تفاصيل مثل الرمز المصرح به، المبلغ، المتلقي المستهدف (مثل عقد تطبيق لامركزي معين)، ووقت انتهاء الصلاحية.
3. طلب تحويل DApp باستخدام التوقيع: عندما يتلقى DApp توقيع المستخدم ويحتاج إلى استخدام الرموز، بدلاً من استدعاء عقد الرمز مباشرة، يستدعي وظائف Permit2 (مثل permitTransferFrom). تقوم هذه الوظيفة بالتحقق من بيانات توقيع المستخدم وتأكيد أن العملية ضمن الأذونات الممنوحة (الرمز، المبلغ، الموعد النهائي). بعد التحقق، يستخدم Permit2 موافقته الرئيسية لاستدعاء transferFrom، محركًا الرموز من المستخدم إلى المستلم المحدد. النقطة الرئيسية: العقد Permit2 نفسه يعمل كجامع، باستخدام سلطته الخاصة لنقل الرموز، مع خطوة إضافية للتحقق من التوقيع.
4. اكتمال العملية: بمجرد أن ينفذ Permit2 بنجاح transferFrom، تنتقل الأموال بسلاسة من المستخدم إلى التطبيق اللامركزي أو العنوان المحدد. من وجهة نظر المستخدم، يقومون فقط بتقديم توقيع في المعاملة، بينما يتولى العقد جميع الإجراءات التالية.

سير تفويض Permit2 بسيط: يحتاج المستخدمون فقط إلى منح الموافقة القصوى لـ Permit2 مرة واحدة فقط لكل رمز. بعد ذلك، عند التفاعل مع التطبيقات (مثل Uniswap Universal Router أو بروتوكولات أخرى)، يقومون ببساطة بتضمين توقيع Permit2 في معاملتهم لإكمال التفويض والتحويل، دون الموافقات الإضافية على السلسلة. يتحقق عقد Permit2 من التوقيع وينفذ النقل باستخدام موافقته الرئيسية. (المصدر: تقديم تصريح 2 وجهاز التوجيه العالمي)

من خلال هذا النموذج ، يوسع Permit2 مفهوم التفويض القائم على التوقيع الخاص ب EIP-2612 ليشمل جميع الرموز المميزة ERC-20 ، بغض النظر عما إذا كانوا يطبقون طريقة permit() بأنفسهم. طالما أن المستخدمين يأذنون في البداية بعقد Permit2 ، فيمكنهم استخدام التوقيعات للعمليات اللاحقة. والجدير بالذكر أن Uniswap صممت Permit2 كعقد بدون مالك وغير قابل للترقية تم نشره بنفس العنوان عبر شبكة Ethereum الرئيسية وشبكات Layer 2 المتعددة. هذا يعني أن جميع التطبيقات تستخدم بالفعل نفس مثيل Permit2 ، مما يحقق وظيفة "الموافقة مرة واحدة ، والاستخدام في كل مكان" الحقيقية.

ميزات رئيسية لتصريح2

كنظام تفويض الجيل التالي، يمكن لـ Permit2 ليس فقط تمكين الموافقات القائمة على التوقيع لجميع الرموز ولكن أيضاً يقدم ميزات إضافية لتعزيز الأمان والاستخدام. إليك ميزاته الرئيسية:

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

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

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

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

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

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

للتلخيص، يعمل Permit2 كامتداد وتحسين لآلية التصريح التقليدية. دعونا نفحص الفروق الرئيسية بين هاتين النهجين:

تبني وتنفيذ نظام تصريح2 البيئي

منذ أن قدمت Uniswap Permit2، قامت العديد من المشاريع بدمج هذا الآلية، مما يسرع عملية توحيد المعايير في الصناعة. وفقًا لأحدث البيانات من تحليلات ديون، اعتبارًا من أبريل 2025، وافق أكثر من 3.1 مليون عنوان رئيسي لـ Ethereum على منح تفويض لعقد Permit2، مما يدل على اعتماده الواسع.

حالة نظام تصريح2 وتنفيذه. المصدر:تحليلات دون

على سبيل المثال ، قامت Uniswap بدمج Permit2 في جهاز التوجيه العالمي الخاص بها ، مما يتيح تبادل الرموز المتعددة و NFT في معاملة واحدة. من خلال Universal Router ، يمكن للمستخدمين ربط عمليات متعددة في معاملة واحدة ، مثل تبادل ثلاثة رموز مميزة مقابل رمزين مستهدفين وشراء NFTs ، مع التعامل مع جميع متطلبات التفويض بواسطة توقيعات Permit2. هذا يبسط العملية بشكل كبير ويقلل من إجمالي تكاليف الغاز ، مما يعرض التأثير المباشر ل Permit2 على تحسين تجربة المستخدم.

علاوة على ذلك ، مع نشر Permit2 مفتوح المصدر عبر سلاسل مختلفة ، بدأ عدد متزايد من المحافظ وأدوات DApp في دعمه. قامت أدوات الأمان مثل Revoke.cash بتحديث خدماتها للسماح للمستخدمين بعرض سجلات تفويض Permit2 وإبطالها. نفذت ماتشا أيضا وحدة SignatureTransfer الخاصة ب Permit2 ، مما يتيح آلية "تفويض لمرة واحدة".

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

مقارنة تصريح2 مع الحلول الجديدة: مفاتيح الجلسة وERC-4337

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

إلى جانب Permit2 ، هناك حلان ناشئان للتفويض جدير بالملاحظة هما مفاتيح الجلسة و ERC-4337 تجريد الحساب، كل واحدة تقدم نهجًا مميزًا للمشكلة.

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

يتبع ERC-4337 نهجًا مختلفًا من خلال تضمين منطق الترخيص مباشرة في الحسابات الذكية، مما يتيح للمستخدمين تخصيص شروط الترخيص وتخطي الخطوات التقليدية المطلوبة. من خلال آليات UserOperation و Paymaster المرنة، يتحقق من تحقيق أمان وتجربة مستخدم محسنة.

من النظرة إلى اتجاهات المستقبل، من المحتمل أن تتعايش هذه الحلول المختلفة. في المدى القصير، ستستمر Permit2 في كونه المعيار للتطبيقات اللامركزية الناشئة، مما يحسن تجربة المستخدم من خلال الموافقات مرة واحدة مع تعزيز التعليم الأمني ودعم الأدوات لتقليل مخاطر التصيُّد الاحتيالي. في المدى المتوسط، مع انتشار ERC-4337 والتجريد الحسابي عبر Layer 2s و mainnets بشكل أكبر، سيتمكن المستخدمون من التحرر من قيود الموافقة التقليدية لـ ERC-20، وإدارة الموافقات بشكل أكثر دقة وذكاء، مما قد يقلل من الحاجة إلى Permit2.

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

بشكل عام، يقدم Permit2 حلا عمليا يمكن تنفيذه على الفور، بينما تشير التقنيات مثل Session Keys و ERC-4337 نحو تحسينات أكثر أساسية وطويلة الأمد في كيفية التعامل مع الترخيص.

مخاطر الأمان الناتجة عن التوقيع القائم على التفويض

مثل أي تقنية جديدة، تقدم Permit و Permit2 ليس فقط كفاءات جديدة ولكن أيضًا مخاطر جديدة، خاصة حول هجمات التفويض القائمة على التوقيع.

في النظم القائمة على التوقيع مثل Permit2 و EIP-2612 Permit، تتضمن تصاميم العقود الأساسية عدة طبقات من الحماية للحماية ضد الاستخدام السيء وهجمات الإعادة:

1. حماية اللعب المعادية استنادًا إلى العدد

يحتفظ Permit2 بعداد nonce منفصل لكل tuple (owner، token، spender). في كل مرة يوقع فيها المستخدم على تفويض جديد، يتم زيادة الـ nonce المقابل. إذا حاول المهاجم إعادة استخدام توقيع قديم، فسيفشل لأن العقد يتحقق مما إذا كان الـ nonce قد تم استخدامه بالفعل.

2. تنفيذ الموعد النهائي

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

3. التحكم الناعم في السماح

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

4. أوضاع الاستخدام الفردية والدفعة

بالإضافة إلى الموافقات القائمة على السماح، يدعم Permit2 أيضًا التوقيعات للاستخدام الفردي عبر SignatureTransfer. هذه التوقيعات صالحة لصفقة واحدة فقط وتصبح باطلة على الفور بعد التنفيذ. هذا مثالي للمدفوعات مرة واحدة ويمنع استخدام التوقيع مجددًا أو استغلاله في وقت لاحق.

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

ومع ذلك، حتى مع الحماية الآمنة على مستوى العقد، يظل الهندسة الاجتماعية (وخاصة الاصطياد الاحتيالي) أصعب تهديد للدفاع عنه. في القسم التالي، سنلقي نظرة على تكتيكات الاصطياد الاحتيالي الشائعة وكيف يخدع المهاجمون المستخدمين للتوقيع بشكل غير مدرك على الموافقات الخبيثة التي تسوء استخدام Permit2. كما سنقدم نصائح حول كيفية البقاء آمنًا.

كيف تحدث هجمات الصيد الاحتيالي بالتوقيع؟

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

1. تنقر الضحية على نسخة مزيفة من موقع DEX معروف (موقع تصيد احتيالي). عندما يحاول المستخدم التفاعل ، يطالب الموقع بطلب توقيع المحفظة ، مدعيا أنه "لتأكيد تسجيل الدخول" أو لأغراض أخرى تبدو مشروعة. ومع ذلك ، فإن هذا الطلب هو في الواقع توقيع تفويض Permit2 ، يمنح عقد المهاجم إذنا غير محدود لسحب USDC للضحية مع فترة صلاحية ممتدة.
2. توقيع الضحية، ناقص اليقظة، يوقع الطلب مباشرة. في هذه النقطة، لا يتم إنفاق الغاز ولا يحدث أي نشاط على السلسلة، مما يترك أي آثار مشبوهة.
3. بمجرد حصول المهاجم على التوقيع ، فإنه يتصل على الفور بوظيفة تصريح () عقد Permit2 لإرساله. بعد أن يتحقق عقد Permit2 من صحة التوقيع ، فإنه يسجل التفويض لعقد المهاجم تحت عنوان الضحية (أي ما يعادل تنفيذ الضحية للموافقة ، ولكن يكملها المهاجم). قد تمر هذه العملية دون أن يلاحظها أحد من قبل الضحية نظرا لأن محفظتها لا تظهر أي نفقات - يتم تحديث تعيين بدل الرمز المميز فقط على blockchain.
4. بعد ذلك، يقوم المهاجم على الفور ببدء عملية نقل (الضحية، عنوان المهاجم، المبلغ) من عنوانهم، مما ينتقل بنجاح USDC للضحية باستخدام إذن Permit2 الأخير. الضحية لا تدرك السرقة إلا عندما يكون الأمر متأخرًا.

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

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

تتضمن أحدث حوادث ابتزاز العملات المشفرة تفويض التوقيع. على سبيل المثال، Scam Sniffer'sالإحصاءاتمنذ بداية عام 2024، تظهر البيانات أن أكثر من 55 مليون دولار من الأصول تمت سرقتها من خلال احتيال التوقيع في شهر واحد فقط. منذ تفعيل Permit2، أصبح المهاجمون أكثر عدوانية في إقناع المستخدمين بتوقيع تفويضات Permit/Permit2، مما أدى إلى العديد من الضحايا في فترة قصيرة. من الواضح أنه عندما يتم إساءة استخدام تفويض التوقيع، يمكن أن يكون مدمرًا وصعب الكشف عنه.

لماذا تكون مخاطر الاحتيال القائم على التوقيع أعلى من الأساليب التقليدية؟

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

بالإضافة إلى ذلك، تعرض المحافظ المختلفة رسائل EIP-712 بطرق مختلفة. بعض المحافظ الحديثة (مثل أحدثميتاماسك(تحليل وعرض الحقول بوضوح، مع عرض رسائل مثل 'السماح للعقد بإنفاق X مقدار من رموزك.' ومع ذلك، تعرض العديد من المحافظ بيانات سداسية عشرية فقط أو وصف بسيط، مما يجعل من الصعب على المستخدمين العاديين التحقق من الأصالة. يستغل المهاجمون ذلك عن طريق تضمين وصف مضلل في الرسائل (مثل التظاهر بتواقيع إنتاج NFT) لخداع المستخدمين وجعلهم يوقعون.

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

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

كيف يمكن للمستخدمين حماية أنفسهم من هجمات التوقيع؟

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

تأكد من أن بحثك تدعم عرض البيانات EIP-712. محافظ رئيسية مثل MetaMask، ترست واليت، وLedger Live تعمل على تحسين تجربة عرض محتوى التوقيع الخاصة بهم. على سبيل المثال ، يمكن ل MetaMask الآن تحليل رسائل الأذونات الشائعة إلى لغة واضحة. إذا كانت محفظتك تعرض بيانات سداسية عشرية طويلة فقط عند التوقيع ، ففكر في التبديل أو التحديث. يجب على مستخدمي محفظة الأجهزة أيضا تحديث البرامج الثابتة الخاصة بهم لدعم التنسيقات الجديدة ، أو قد لا يرون المعلومات بشكل صحيح على الشاشة.

سواء كنت تستخدم توقيعات الإذن أو الإذن2، يمكنك عادة ضبط معلمات الإذن. لا توقع مبالغ غير محدودة (القيمة = 2^256-1) إلا إذا كان ذلك ضروريًا تمامًا - بدلاً من ذلك، قم بتفويض المبلغ الذي تحتاجه بالإضافة إلى مخزن صغير. أيضًا، لا تحدد المواعيد النهائية بعيدة جدًا في المستقبل. بهذه الطريقة، حتى لو وقع توقيعك في أيدي خاطئة، يتم تقييد الخسائر المحتملة، وسينتهي التوقيع في النهاية.

طور عادة التحقق بانتظام من حالة تفويض عنوانك باستخدام أدوات مثل Revoke.cash أو الموافقة على رمز Etherscan أو الميزات المضمنة في محفظتك. وهذا يشمل كلا من الموافقات التقليدية وبدلات التصريح 2. إذا لاحظت أي تراخيص مشبوهة أو غير ضرورية ، فقم بإلغائها على الفور. بالنسبة إلى Permit2 ، كن على دراية بمستويين من الإلغاء: أولا ، التفويض الرئيسي (موافقتك على عقد Permit2 نفسه ، والذي قد ترغب في تعيينه على 0 عندما لا يكون قيد الاستخدام) ؛ ثانيا ، التراخيص الفرعية (بدلات Permit2 لمختلف التطبيقات اللامركزية ، والتي عادة ما تنتهي صلاحيتها تلقائيا ولكن يمكن إنهاؤها مبكرا إذا كانت لها فترات صلاحية طويلة). إذا كنت تشك في أنك وقعت على تصريح مشبوه ، فإن الإجراء الأكثر أمانا هو تعديل nonce على الفور: التوقيع على تصريح جديد لنفس المنفق (حتى مع 0 بدل) لإبطال التوقيع القديم في حوزة المهاجم.

كن حذرا دائما عند زيارة مواقع الويب غير المألوفة أو تنزيل التطبيقات. لا تنقر على روابط غير معروفة ، خاصة "العروض الترويجية" أو "أحداث النعناع" التي تتم مشاركتها من خلال إعلانات وسائل التواصل الاجتماعي أو الرسائل الخاصة. تحدث العديد من محاولات التصيد الاحتيالي من خلال حسابات رسمية مزيفة تنشر روابط نشاط احتيالية ، مما يؤدي إلى طلبات التوقيع. اجعل من المعتاد كتابة عناوين URL الرسمية ل DApp مباشرة أو استخدام الإشارات المرجعية لتجنب الوقوع في مواقع الويب المزيفة.

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

استنتاج

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