آلية الموافقة

ما آلية الموافقة؟

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

في معظم النقاشات المتعلقة بالعملات المشفرة، تشير آلية الموافقة عادةً إلى الموافقات على التوكنات في شبكات البلوكشين التي تدعم العقود الذكية.

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

ومن أكثر الأمثلة شيوعًا نظام الموافقة ERC-20، إذ يستدعي حامل التوكن approve() لمنح جهة الإنفاق إذنًا بتحريك كمية معينة من التوكنات عبر transferFrom().

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

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

فعلى سبيل المثال، قد يحتاج تطبيق إقراض إلى موافقة قبل إيداع العملات المستقرة الخاصة بالمستخدم في مجمع.

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

وقد يحتاج سوق NFT إلى الموافقة قبل نقل NFT بعد إتمام عملية بيع.

وقد يحتاج عقد Staking إلى الموافقة قبل نقل توكنات التخزين إلى العقد.

تفيد آلية الموافقة لأنها تفصل بين منح الإذن ونقل الأصول فعليًا.

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

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

أهمية آليات الموافقة في العملات المشفرة

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

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

وتُعد الموافقة إحدى الطرق الرئيسية لمنح هذا الإذن.

لذلك تشكل الموافقات جزءًا أساسيًا من DeFi وNFTs والألعاب وStaking وتبديل التوكنات وجسور التوكنات والمدفوعات وغيرها من الأنشطة على السلسلة.

من دون آليات الموافقة، سيضطر المستخدمون إلى إرسال التوكنات يدويًا لتنفيذ كثير من الإجراءات، ما يجعل عمليات العقود الذكية أبطأ وأقل مرونة.

أما آليات الموافقة، فتتيح للمستخدم تفويض عقد للعمل ضمن حد إنفاق محدد أو صلاحية مشغّل.

وتتمثل الفائدة في سهولة الاستخدام.

أما الخطر، فهو احتمال إساءة جهة إنفاق خبيثة أو مخترقة استخدام الإذن.

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

وإذا وافق المستخدم على مشغّل خبيث لإدارة جميع NFTs في مجموعة، فقد يتمكن المشغّل من نقل تلك الـ NFTs.

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

آليات الموافقة ليست مجرد تفاصيل تقنية مخفية في النوافذ المنبثقة للمحفظة.

فهي تحدد من يمكنه تحريك الأصول، والكمية التي يمكنه تحريكها، وما قد يحدث إذا اختُرق عقد أو مفتاح خاص.

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

تعتمد موافقات ERC-20 على علاقة بين ثلاثة أطراف.

الطرف الأول هو مالك التوكن.

والطرف الثاني هو جهة الإنفاق.

والطرف الثالث هو عقد توكن ERC-20.

يحتفظ مالك التوكن بالتوكنات في عنوان محفظة.

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

يسجل عقد التوكن حد الإنفاق في مساحة التخزين الداخلية لديه.

عندما يستدعي المالك approve(spender, amount)، يحدّث عقد التوكن عدد التوكنات التي يمكن لجهة الإنفاق تحريكها من رصيد المالك.

وعندما تستدعي جهة الإنفاق لاحقًا transferFrom(owner, receiver, amount)، يتحقق عقد التوكن من أن حد الإنفاق المتاح كافٍ.

إذا كان حد الإنفاق كافيًا وكان رصيد المالك يسمح بذلك، يمكن تنفيذ التحويل.

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

تشرح وثائق OpenZeppelin الخاصة بـ ERC-20 الوظائف المرتبطة بحدود الإنفاق وامتداد permit المستخدم في تطبيقات التوكن الحديثة.

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

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

حد الإنفاق

حد الإنفاق هو كمية التوكنات التي يُسمح لجهة الإنفاق بتحريكها من محفظة المالك.

في توكنات ERC-20، يُخزَّن حد الإنفاق عادةً في خريطة داخل عقد التوكن.

لا يرسل المالك التوكنات عند إنشاء حد الإنفاق.

بل يمنح إذنًا بتحويلها مستقبلًا فحسب.

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

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

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

يحدّ حد الإنفاق الصغير من الكمية التي يمكن لجهة الإنفاق تحريكها.

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

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

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

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

الموافقة مقابل التحويل

الموافقة ليست مثل التحويل.

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

أما الموافقة، فتغيّر الأذونات داخل عقد التوكن.

عندما يوافق المستخدم جهة إنفاق، تظل التوكنات عادةً في محفظته في تلك اللحظة.

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

ولهذا قد تكون عمليات الاحتيال القائمة على الموافقات مربكة.

فقد يوقّع المستخدم موافقة ولا يلاحظ تحرك أي توكنات فورًا.

ثم قد يستدعي المهاجم transferFrom() لاحقًا لتحريك التوكنات باستخدام الموافقة القائمة.

كان منح الموافقة هو الإجراء الخطير، حتى وإن حدثت السرقة في وقت لاحق.

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

قد تمنح رسالة تأكيد المحفظة التي تعرض «موافقة» صلاحية إنفاق مستقبلية.

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

الموافقة غير المحدودة

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

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

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

يوفر ذلك سهولة الاستخدام، لكنه يترك الأصول معرّضة للخطر مدة طويلة.

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

وجد بحث أكاديمي حول مخاطر الموافقات غير المحدودة لتوكنات ERC-20 أن هذه الموافقات شائعة وتعرّض المستخدمين لمخاطر ملموسة في منظومة Ethereum.

المشكلة الرئيسية ليست أن الموافقة غير المحدودة تؤدي دائمًا إلى خسارة.

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

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

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

الموافقة المحدودة

تعني الموافقة المحدودة منح الإذن بكمية محددة من التوكنات فقط.

فمثلًا، قد يوافق المستخدم على 100 توكن لأن الإجراء التالي يحتاج إلى 100 توكن فقط.

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

تكون الموافقات المحدودة عادةً أكثر أمانًا من الموافقات غير المحدودة.

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

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

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

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

كما تفيد عند استخدام محفظة تحتوي على أصول قيّمة.

ومن أفضل الممارسات الشائعة الموافقة على الكمية اللازمة للإجراء الحالي فقط.

بعد إتمام الإجراء، يستطيع المستخدم إلغاء أي حد إنفاق متبقٍ.

إلغاء الموافقات

يعني إلغاء الموافقة تغيير إذن جهة الإنفاق إلى صفر أو إزالة صلاحية المشغّل.

وهذه إحدى أهم عادات الأمان في عالم العملات المشفرة.

يوصي دليل Ethereum.org لإلغاء الوصول إلى التوكنات بتجنب منح وصول غير محدود إلى التوكنات وإلغاء صلاحيات حدود الإنفاق بانتظام.

لا يؤدي الإلغاء عادةً إلى نقل التوكنات.

بل يغيّر قدرة جهة الإنفاق على تحريكها لاحقًا.

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

أما في NFTs، فقد يعني الإلغاء إزالة الموافقة على توكن محدد أو إزالة موافقة المشغّل على مجموعة كاملة.

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

لكن قد تكون التكلفة بسيطة مقارنةً بالخسارة المحتملة من ترك أذونات خطرة مفتوحة.

ينبغي للمستخدمين مراجعة الموافقات القديمة بعد استخدام تطبيقات جديدة، أو توقيع معاملات مريبة، أو المشاركة في مطالبات التوكنات، أو الاتصال بمواقع غير مألوفة.

لا يشكل الإلغاء دفاعًا مثاليًا، لكنه يقلل عدد المنافذ المفتوحة التي قد يستغلها المهاجمون.

آلية الموافقة وERC-2612 Permit

يضيف ERC-2612 وظيفة permit() التي تتيح للمستخدمين تعديل حد إنفاق ERC-20 عبر رسالة موقعة بدلًا من معاملة approve() مباشرةً على السلسلة.

يوضح معيار ERC-2612 permit الرسمي أن permit يتيح للمستخدمين تعديل خريطة حدود الإنفاق باستخدام رسالة موقعة.

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

يمكن لطرف آخر إرسال تصريح permit موقّع، ودفع رسوم الغاز، وإكمال مسار الموافقة.

تشيع الموافقات المستندة إلى permit في تطبيقات DeFi الحديثة لأنها تقلل عدد الخطوات.

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

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

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

بل عليهم مراجعة التوكن وجهة الإنفاق والكمية والمهلة والشبكة والنطاق المعروض في المحفظة.

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

آلية الموافقة وNFTs

تختلف آليات الموافقة على NFTs عن حدود الإنفاق في ERC-20.

في ERC-721، يستطيع المستخدم الموافقة على عنوان لنقل NFT محدد واحد.

كما يمكنه استخدام setApprovalForAll() للموافقة على مشغّل لإدارة جميع NFTs في تلك المجموعة.

هذا النوع الثاني قوي ومحفوف بالمخاطر، لأنه قد يشمل كل NFT في المجموعة التي يملكها المستخدم.

وفي توكنات ERC-1155، قد تتيح setApprovalForAll() للمشغّل إدارة جميع توكنات المستخدم ضمن ذلك العقد.

يوضح معيار ERC-1155 متعدد التوكنات الرسمي أن setApprovalForAll تتيح للمشغّل إدارة مجموعة التوكنات كاملةً نيابةً عن مانح الموافقة.

ينبغي لمستخدمي NFTs توخي الحذر الشديد عند منح الموافقات على مستوى المجموعة.

فقد تسمح موافقة مشغّل خبيث لمهاجم بنقل NFTs قيّمة من دون طلب الموافقة على كل عنصر على حدة.

لهذا السبب، ينبغي التعامل بجدية مع تحذيرات المحفظة بشأن موافقات NFTs.

على المستخدمين إلغاء موافقات مشغّلي NFTs القديمة عندما لا تعود مطلوبة.

آلية الموافقة وأذونات العقود الذكية

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

تتضمن أنظمة العملات المشفرة كثيرًا من أنواع الموافقات، مثل موافقات المسؤولين والأدوار والمدققين والحوكمة، إضافةً إلى التفويضات على مستوى الحساب.

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

وقد تتطلب محفظة متعددة التوقيعات موافقات عدة قبل إرسال معاملة.

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

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

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

تشترك آليات الموافقة هذه جميعًا في الفكرة الأساسية نفسها.

إذ يُمنح شخص أو نظام ما الإذن بالتصرف وفق قواعد محددة.

ويبقى السؤال الأمني الأساسي واحدًا دائمًا.

من الجهة التي ستحصل على الموافقة؟ وما الذي يمكنها فعله؟ وكم تستمر صلاحية الإذن؟ وكيف يمكن إلغاؤه؟

آلية الموافقة وEIP-7702

قدّم EIP-7702 نموذجًا جديدًا لتفويض الحسابات المملوكة خارجيًا ضمن مسار ترقية Pectra في Ethereum.

توضح وثائق Pectra 7702 على Ethereum.org أن EIP-7702 يحدد آلية تتيح للحسابات المملوكة خارجيًا اكتساب تحسينات وظيفية قصيرة الأجل عبر إضافة سلوك برمجي.

وهذا يختلف عن موافقة ERC-20 العادية على التوكنات.

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

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

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

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

وهنا يتجاوز سؤال الموافقة حد إنفاق توكن واحد.

إذ يصبح السؤال متعلقًا بالرمز البرمجي الذي يسمح الحساب له بالتصرف عبر المحفظة.

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

وهذا يعني أيضًا ضرورة جعل واجهات المحافظ أوضح وأكثر أمانًا.

آلية الموافقة والنوافذ المنبثقة للمحفظة

غالبًا ما يواجه المستخدمون آليات الموافقة للمرة الأولى عبر النوافذ المنبثقة للمحفظة.

قد تطلب المحفظة من المستخدم الموافقة على إنفاق التوكنات، أو توقيع permit، أو إتاحة الوصول إلى NFTs، أو تأكيد معاملة، أو تفويض سلوك للحساب.

لكن كثيرًا من هذه النوافذ يصعب على المستخدمين فهمها.

فقد تعرض عناوين العقود أو بيانات بالنظام الست عشري أو أسماء وظائف تقنية أو تسميات مبهمة للأذونات.

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

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

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

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

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

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

آلية الموافقة وDeFi

تعتمد تطبيقات DeFi بدرجة كبيرة على آليات الموافقة.

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

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

وقد يتطلب إجراء Staking الموافقة قبل أن يستقبل عقد التخزين التوكنات.

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

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

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

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

وقد يظل بعضها مفتوحًا حتى إذا لم يعد المستخدم يستعمل التطبيق.

ينبغي لمستخدمي DeFi إدراج مراجعة الموافقات ضمن روتين الأمان المنتظم.

ويكتسب ذلك أهمية خاصة للمحافظ التي تحتفظ بأرصدة كبيرة أو مدخرات طويلة الأجل.

آلية الموافقة والجسور

تتطلب الجسور غالبًا موافقات قبل نقل التوكنات من سلسلة إلى أخرى.

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

بعد ذلك، يقفل الجسر الأصل أو يحرقه أو ينقله وفقًا لتصميمه.

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

إذا اختُرق عقد الجسر أو مسار الموافقة، فقد تصبح حدود الإنفاق المفتوحة خطرة.

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

وعليهم التحقق من عنوان الجسر الرسمي عبر مصادر موثوقة.

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

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

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

آلية الموافقة وتجريد الحساب

يغيّر تجريد الحساب الطريقة التي يمكن للمحافظ من خلالها تفويض الإجراءات.

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

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

تصبح آليات الموافقة أكثر مرونة في هذه البيئة.

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

وقد يوافق على حد دفع لتطبيق يشبه خدمات الاشتراك.

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

قد يحسّن ذلك تجربة المستخدم ويقلل مطالبات المحفظة المتكررة.

لكنه ينشئ أيضًا تحديات جديدة لإدارة الأذونات.

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

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

آلية الموافقة والحوكمة

تختلف موافقات الحوكمة عن موافقات إنفاق التوكنات، لكنها تتبع منطق الأذونات نفسه.

قد يتطلب مقترح DAO موافقة حاملي التوكنات قبل تغيير معلمات البروتوكول أو إنفاق أموال الخزانة.

وقد تتطلب خزانة متعددة التوقيعات موافقة عدة موقّعين قبل تنفيذ معاملة.

وقد تتطلب ترقية البروتوكول موافقة الحوكمة قبل تفعيل الشيفرة الجديدة.

تحمي هذه الموافقات الأنظمة المشتركة من التصرف الأحادي.

لكنها قد تنطوي على مخاطر أيضًا عندما تتركز قوة التصويت أو تتعرض حسابات الموقّعين للاختراق.

قد تؤدي موافقة حوكمة سيئة إلى تغيير الرسوم أو ترقية العقود أو تحويل الأموال أو تعديل إعدادات المخاطر.

ينبغي للمستخدمين فهم أن الموافقات لا تقتصر على المحافظ.

فهي مهمة أيضًا على مستوى البروتوكول والمجتمع.

يحتاج نظام العملات المشفرة الآمن إلى موافقات آمنة لتحريك الأصول الفردية واتخاذ القرارات الجماعية على حد سواء.

مخاطر أمان آليات الموافقة

الخطر الأول والرئيسي هو الموافقة غير المحدودة.

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

الخطر الثاني هو عناوين جهات الإنفاق الخبيثة.

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

الخطر الثالث هو اختراق العقود.

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

الخطر الرابع هو ضعف عرض المعلومات في المحفظة.

إذا لم توضح المحفظة الموافقة جيدًا، فقد يوقّع المستخدمون من دون فهم الإذن.

الخطر الخامس هو ظروف السباق في الموافقات.

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

الخطر السادس هو إساءة استخدام التوقيعات.

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

الخطر السابع هو نسيان الموافقات.

قد تظل الأذونات القديمة فعالة مدة طويلة بعد توقف المستخدم عن استعمال التطبيق.

ظروف السباق في الموافقات

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

إذا كان لدى جهة الإنفاق حد قدره 100 توكن، وغيّره المستخدم إلى 50، فقد تحاول جهة إنفاق خبيثة استخدام الحد القديم البالغ 100 قبل تأكيد الحد الجديد البالغ 50.

إذا جاء التوقيت ضد المستخدم، فقد تتمكن جهة الإنفاق من استخدام كمية أكبر مما قصده.

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

من الأنماط الأكثر أمانًا ضبط حد الإنفاق على صفر أولًا، ثم تحديد الحد الجديد المطلوب.

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

ينبغي للمطورين تصميم مسارات التوكنات والتطبيقات بما يتجنب التغييرات غير الآمنة في حدود الإنفاق.

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

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

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

ينبغي للمستخدمين الموافقة على الكمية المطلوبة فقط كلما كان ذلك عمليًا.

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

كما ينبغي مراجعة عنوان جهة الإنفاق قبل توقيع الموافقة.

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

ينبغي إلغاء الموافقات القديمة بعد الانتهاء من استخدام التطبيق.

كما يجب توخي الحذر مع التوقيعات التي تنشئ تصاريح أو تفويضات.

ومن الأفضل استخدام محافظ منفصلة لحفظ الأصول عالية القيمة والتفاعل النشط مع التطبيقات.

وينبغي الاحتفاظ بالموجودات طويلة الأجل في محافظ بأقل عدد ممكن من الموافقات المفتوحة.

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

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

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

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

ينبغي للمطورين طلب أقل مقدار من الموافقة يفي بغرض المستخدم.

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

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

ينبغي تحديد عقد جهة الإنفاق التي ستتلقى الإذن بوضوح.

كما ينبغي دعم المسارات المستندة إلى permit فقط عندما يستطيع المستخدمون فهم ما يوقّعون عليه.

وعلى المطورين تقديم إرشادات لإلغاء الموافقات بعد التفاعلات عالية المخاطر.

ينبغي تجنب موافقات المشغّل غير الضرورية على NFTs والعقود متعددة التوكنات.

كما ينبغي تصميم العقود بحيث تكون الموافقات محددة النطاق وقابلة للتدقيق وسهلة الإلغاء.

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

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

آلية الموافقة مقابل ربط المحفظة

ربط المحفظة ليس مثل منح الموافقة.

يتيح ربط المحفظة للموقع الإلكتروني عادةً رؤية عنوانها وطلب تنفيذ إجراءات.

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

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

كثيرًا ما يخلط المستخدمون بين الإجراءين.

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

لهذا السبب، ينبغي ألا يعتمد المستخدمون على فصل المحفظة وحده لضمان الأمان.

إذا وافق المستخدم على جهة إنفاق، فقد يظل حد الإنفاق قائمًا إلى أن يُغيّر على السلسلة.

ولإزالة الإذن، يحتاج المستخدم عادةً إلى إلغاء الموافقة أو تحديثها.

يساعد فهم هذا الفرق على تجنب الشعور الزائف بالأمان.

آلية الموافقة مقابل التوقيع

التوقيع ليس دائمًا مثل الموافقة، لكن بعض التوقيعات قد تنشئ موافقات.

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

وقد يفوّض توقيع permit حد إنفاق لتوكن.

وقد يفوّض توقيع على مستوى الحساب منطقًا برمجيًا أو سياسةً لتعمل عبر المحفظة.

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

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

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

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

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

في العملات المشفرة الحديثة، يمكن منح الموافقات عبر المعاملات والرسائل الموقعة على حد سواء.

آلية الموافقة ومعايير التوكنات

تستخدم معايير التوكنات المختلفة آليات موافقة مختلفة.

يستخدم ERC-20 موافقات قائمة على حدود الإنفاق للتوكنات القابلة للاستبدال.

ويستخدم ERC-721 موافقات على NFTs الفردية وموافقات للمشغّلين على مستوى المجموعات.

أما ERC-1155، فيستخدم موافقات للمشغّلين قد تشمل عدة معرّفات توكنات ضمن عقد واحد.

ويضيف ERC-2612 موافقات permit موقعة إلى التوكنات المشابهة لتوكنات ERC-20.

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

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

فالموافقة على عملة مستقرة واحدة تختلف عن الموافقة على جميع NFTs في مجموعة.

وتوقيع permit يختلف عن معاملة approve مباشرةً.

كما يختلف تفويض الحساب عن حد إنفاق التوكن.

والسؤال الأكثر أمانًا دائمًا هو: ما الصلاحية المحددة التي تمنحها الموافقة؟

مفاهيم خاطئة شائعة عن آليات الموافقة

من المفاهيم الخاطئة الشائعة أن الموافقة تنقل التوكنات فورًا.

فالموافقة تمنح الإذن عادةً، بينما قد ينقل التوكناتَ تحويلٌ لاحق.

ومن المفاهيم الخاطئة أيضًا أن فصل المحفظة يلغي الموافقات.

ففصل المحفظة لا يغيّر عادةً حد الإنفاق المسجل في عقد التوكن.

وثمة مفهوم خاطئ ثالث، وهو أن الموافقة غير المحدودة تؤثر في الرصيد الحالي فقط.

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

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

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

والمفهوم الخاطئ الخامس هو أن التطبيقات الموثوقة لا تحتاج أبدًا إلى إلغاء الموافقات.

حتى التطبيقات الموثوقة قد تتعرض لأخطاء أو تحديثات أو اختراق مفاتيح أو تغير في ظروف المخاطر.

والمفهوم الخاطئ السادس هو أن موافقات NFTs منخفضة المخاطر لأنها لا تتعلق بتوكنات قابلة للاستبدال.

قد تمنح موافقات مشغّلي NFTs سيطرة واسعة على مقتنيات أو أصول ألعاب قيّمة.

مصطلحات مشفرة ذات صلة

حد الإنفاق هو كمية توكنات ERC-20 التي يجوز لجهة إنفاق تحريكها من محفظة المالك.

approve() هي وظيفة ERC-20 المستخدمة لتحديد حد إنفاق جهة ما.

transferFrom() هي وظيفة ERC-20 التي تستخدمها جهة الإنفاق لتحريك التوكنات بعد حصولها على حد إنفاق.

Permit هو أسلوب موافقة موقّع يمكنه تغيير حد الإنفاق من دون أن يرسل المالك مباشرةً معاملة approve.

setApprovalForAll() وظيفة تُستخدم في معايير NFTs والتوكنات المتعددة للموافقة على مشغّل لإدارة مجموعة أوسع من الأصول.

الإلغاء هو عملية إزالة الموافقة أو تقليل نطاقها.

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

المشغّل هو عنوان معتمد لإدارة NFTs أو الأصول متعددة التوكنات نيابةً عن المالك.

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

العقد الذكي هو شيفرة على البلوكشين تنفذ القواعد تلقائيًا عند استدعائها.

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

ما المقصود بآلية الموافقة في العملات المشفرة؟

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

ما الموافقة على التوكن؟

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

ما موافقة ERC-20؟

موافقة ERC-20 هي نظام حد الإنفاق الذي يفوض فيه مالك التوكن جهة إنفاق لتحويل كمية محددة من التوكنات كحد أقصى عبر transferFrom().

ما حد الإنفاق؟

حد الإنفاق هو كمية التوكنات التي يُسمح لجهة إنفاق بتحريكها من محفظة المالك.

هل الموافقة مثل التحويل؟

لا. تمنح الموافقة إذنًا، بينما ينقل التحويل التوكنات فعليًا.

لماذا تشكل الموافقات غير المحدودة خطرًا؟

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

كيف يلغي المستخدمون موافقات التوكنات؟

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

هل يؤدي فصل المحفظة إلى إلغاء الموافقات؟

لا. لا يؤدي فصل المحفظة عن موقع إلكتروني عادةً إلى إلغاء موافقات التوكنات المسجلة على السلسلة.

ما موافقة permit؟

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

هل موافقات NFTs خطرة؟

قد تكون موافقات NFTs خطرة عندما تسمح لمشغّل بإدارة NFT قيّم أو مجموعة كاملة.

ما الذي ينبغي للمستخدمين التحقق منه قبل الموافقة؟

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

ما أكثر ممارسات الموافقة أمانًا؟

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

الخاتمة

تُعد آلية الموافقة أحد أهم أنظمة الأذونات في العملات المشفرة.

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

أكثر أشكالها شيوعًا هو موافقة توكن ERC-20، حيث يمنح المستخدم جهة إنفاق حدًا للإنفاق.

تتيح آليات الموافقة تنفيذ عمليات DeFi وNFTs والجسور وStaking والمدفوعات والألعاب وغيرها من مسارات العقود الذكية.

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

والدرس الأساسي هو أن الموافقة ليست خطوة خلفية غير ضارة.

إنها إذن قد يحدد ما إذا كان بإمكان عنوان آخر تحريك أصول قيّمة.

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

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

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

مع تطور محافظ العملات المشفرة عبر توقيعات permit وتجريد الحساب ومفاتيح الجلسات وتفويض الحساب على نمط EIP-7702، ستصبح آليات الموافقة أقوى وأكثر تعقيدًا.

وهذا يجعل إدارة الأذونات جزءًا أساسيًا من أمان العملات المشفرة.

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

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

لذلك، لا تقتصر آلية الموافقة على كونها ميزة تقنية.

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