الحماية من إعادة استخدام Nonce

ما الحماية من إعادة استخدام Nonce؟

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

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

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

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

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

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

توضح وثائق حسابات Ethereum أن حساب Ethereum يحتوي على حقل Nonce، وأنه لا يمكن تنفيذ سوى معاملة واحدة لكل حساب تحمل قيمة Nonce معينة.

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

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

أهم النقاط حول الحماية من إعادة استخدام Nonce

• • تمنع الحماية من إعادة استخدام Nonce قبول الإجراء المشفر الموقّع نفسه أكثر من مرة.
  • قد تكون قيمة Nonce تسلسلية أو عشوائية أو خاصة بنطاق أو حساب أو عقد أو مسار.
  • تستخدم الحسابات المملوكة خارجياً في Ethereum قيم Nonce تسلسلية للمعاملات لمنع تنفيذ المعاملة نفسها أكثر من مرة.
  • يضيف EIP-155 معرّف السلسلة إلى بيانات المعاملة الموقّعة للحد من مخاطر إعادة استخدامها عبر السلاسل.
  • تظل البيانات ذات الأنواع المحددة في EIP-712 بحاجة إلى حماية من إعادة الاستخدام على مستوى التطبيق، إذ يمكن إرسال التوقيعات ذات الأنواع المحددة أكثر من مرة إذا لم ترفض العقود التكرار.
  • يستخدم تصريح ERC-2612 قيم Nonce خاصة بالمالك ومواعيد نهائية لمنع إعادة استخدام توقيعات الموافقة على التوكنات إلى أجل غير محدد.
  • يستخدم ERC-3009 قيم Nonce عشوائية بطول 32 بايت وحالة التفويض لمنع تكرار التحويلات الموقّعة.
  • تستخدم الحسابات الذكية في ERC-4337 تصميماً أكثر مرونة لقيم Nonce لدعم تجريد الحسابات وسير العمل المتوازي.
  • ينبغي أيضاً ربط التوقيعات بالسلسلة والعقد والوظيفة والمستخدم والموعد النهائي والإجراء المقصود الصحيح.
  • قد يؤدي التصميم الضعيف لقيم Nonce إلى الإنفاق المزدوج، وتكرار الموافقات، وتعطل المعاملات، وأضرار سرقة التوقيعات، وفشل المعاملات الوسيطة، وهجمات إعادة الاستخدام عبر السلاسل.

أهمية هجمات إعادة الاستخدام في العملات المشفرة

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

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

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

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

قد ينقل التحويل المعاد استخدامه الأموال مرة أخرى.

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

وقد تستنزف مطالبة المكافآت المعاد استخدامها مجمع المكافآت.

وقد يؤدي تكرار التصويت في الحوكمة إلى تحريف القرار إذا لم يسجل العقد حالة التصويت.

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

تحوّل الحماية من إعادة استخدام Nonce التوقيع القابل لإعادة الاستخدام إلى تفويض صالح للاستخدام مرة واحدة.

كيف تمنع قيمة Nonce إعادة الاستخدام؟

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

عندما يوقّع المستخدم إجراءً، تُضمّن قيمة Nonce في البيانات الموقّعة.

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

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

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

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

وهذا تمييز مهم.

تثبت صلاحية التوقيع أن المستخدم فوّض الرسالة.

أما حداثة قيمة Nonce فتثبت أن التفويض لم يُستهلك من قبل.

يحتاج النظام الآمن إلى الأمرين معاً.

قيم Nonce التسلسلية

قيمة Nonce التسلسلية هي عدّاد يزداد بعد كل إجراء مقبول.

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

إذا كانت قيمة Nonce للحساب 10، فعادةً ما تحتاج المعاملة التالية الصالحة من ذلك الحساب إلى القيمة 10.

وبعد إدراج تلك المعاملة، تحتاج المعاملة الصالحة التالية إلى القيمة 11.

يمنع ذلك تنفيذ معاملتين مختلفتين تحملان قيمة Nonce الحساب نفسها.

كما يحدد ترتيباً للمعاملات، إذ لا يمكن عادةً معالجة قيمة Nonce لاحقة قبل استكمال القيم السابقة.

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

لكنها قد تصبح غير ملائمة للمعاملات الوسيطة وسير العمل المجمّع والأجهزة المتعددة والجلسات المؤتمتة وأنظمة تجريد الحسابات.

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

قيم Nonce العشوائية

قيمة Nonce العشوائية هي قيمة فريدة تُنشأ عشوائياً بدلاً من زيادتها كعدّاد.

تشيع هذه القيم في التفويضات الموقّعة وأنظمة المعاملات الوسيطة التي لا تتطلب ترتيباً صارماً للمعاملات.

يستخدم ERC-3009 قيماً عشوائية بطول 32 بايت تكون فريدة لكل عنوان مفوِّض.

يحدد معيار ERC-3009 دالة لحالة التفويض وأحداثاً تسجل ما إذا كانت قيمة Nonce الخاصة بالتفويض قد استُخدمت أو أُلغيت.

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

كما يتجنب مشكلة حجب قيمة Nonce تسلسلية معلقة للتفويضات اللاحقة.

لكن على العقد تخزين قيم Nonce العشوائية المستخدمة أو التحقق منها حتى لا يتكرر التفويض نفسه.

تتطلب قيم Nonce العشوائية عشوائية قوية.

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

قيم Nonce الخاصة بالحسابات

تحمي قيمة Nonce الخاصة بالحساب معاملات الحساب نفسه.

وفي الحسابات المملوكة خارجياً، تساعد قيمة Nonce على جعل كل معاملة فريدة وتتحكم في ترتيب المعاملات.

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

أما الأخرى فقد تُرفض أو تُستبدل أو تظل غير صالحة، وفقاً لسلوك الشبكة والرسوم.

لذلك تتتبع المحافظ قيمة Nonce التالية للحساب بعناية.

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

وإذا استخدمت قيمة أعلى من اللازم، فقد تنتظر المعاملة إلى أن تُؤكد قيم Nonce السابقة المفقودة.

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

تحمي قيم Nonce الحسابات من إعادة الاستخدام، لكنها تخلق أيضاً مشكلات عملية في إدارة المعاملات.

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

الحماية من إعادة الاستخدام باستخدام معرّف السلسلة

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

ازدادت أهمية ذلك بعد انقسامات السلاسل ونمو الشبكات المتوافقة مع EVM.

أضاف EIP-155 معرّف السلسلة إلى بيانات معاملات Ethereum الموقّعة.

والهدف هو جعل المعاملة صالحة لسلسلة واحدة وغير صالحة لسلسلة أخرى ذات معرّف مختلف.

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

تختلف الحماية باستخدام معرّف السلسلة عن الحماية باستخدام Nonce الحساب.

تمنع قيمة Nonce الحساب تكرار المعاملة نفسها على السلسلة نفسها.

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

وتحتاج الحماية القوية عادةً إلى كليهما.

فصل النطاق

يعني فصل النطاق ربط التوقيع بسياق توقيع محدد.

وقد يشمل هذا السياق معرّف السلسلة وعنوان العقد واسم البروتوكول وإصداره ونوع الوظيفة وعنوان المستخدم وقيمة Nonce والموعد النهائي.

يحدد EIP-712 توقيع البيانات المنظّمة ذات الأنواع المحددة، ويشمل حقول النطاق مثل name وversion وchainId وverifyingContract.

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

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

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

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

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

ويساعد فصل النطاق على منع الاستخدام في سياق غير صحيح.

كلا الإجراءين ضروريان لسلامة التوقيعات خارج السلسلة.

الحماية من إعادة استخدام Nonce في رسائل EIP-712

يجعل EIP-712 الرسائل أسهل للفهم للمحافظ والمستخدمين، لكنه لا يجعل كل رسالة موقّعة صالحة للاستخدام مرة واحدة تلقائياً.

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

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

يمكن أن تتضمن الرسالة ذات الأنواع المحددة قيمة Nonce، لكن على العقد المستقبِل التحقق منها واستهلاكها.

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

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

تحسن البيانات ذات الأنواع المحددة وضوح الرسالة، لا سلامتها من إعادة الاستخدام بحد ذاتها.

تتحقق السلامة من إعادة الاستخدام عبر التصميم الكامل.

يستخدم مسار EIP-712 الآمن فصل النطاق وتتبع قيم Nonce والتحقق من التوقيع وربط التوقيع بالإجراء وفحص الموعد النهائي معاً.

قد يؤدي إغفال أي من هذه العناصر إلى مخاطر إعادة الاستخدام.

الحماية من إعادة استخدام Nonce في تصريح ERC-2612

يتيح تصريح ERC-2612 لمالك التوكن الموافقة على إنفاقه برسالة موقّعة بدلاً من معاملة موافقة مباشرة على السلسلة.

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

يتطلب معيار ERC-2612 دالة nonces، وينص على ضرورة زيادة قيمة Nonce الخاصة بالمالك عند نجاح التصريح.

ويذكر المعيار أيضاً أن خريطة nonces موجودة للحماية من إعادة الاستخدام.

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

يتضمن ERC-2612 أيضاً معاملاً للموعد النهائي.

ويحدد الموعد النهائي المدة التي يظل خلالها التصريح الموقّع صالحاً.

وهذا مهم لأن الوسيط الذي يتلقى تصريحاً يمكنه اختيار وقت إرساله قبل انتهاء صلاحيته.

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

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

الحماية من إعادة استخدام Nonce في ERC-3009

ERC-3009 هو نمط تفويض تحويل للتوكنات يعتمد على التوقيع.

وبدلاً من الموافقة أولاً على جهة الإنفاق، يوقّع حامل التوكن تفويضاً لتحويل محدد.

ثم يتحقق العقد من التوقيع وفترة الصلاحية وقيمة Nonce قبل التنفيذ.

يستخدم ERC-3009 خريطة authorizationState لتتبع ما إذا كانت قيمة Nonce قد استُخدمت.

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

وهذا يمنع تنفيذ التحويل الموقّع نفسه مرة أخرى.

تدعم بعض تطبيقات ERC-3009 أيضاً إلغاء التفويضات.

كما تتضمن حقلي validAfter وvalidBefore لتحديد فترة صلاحية التفويض.

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

ويوضح أيضاً أن الحماية من إعادة الاستخدام تتجاوز مجرد استخدام عدّاد.

ينبغي أن يتضمن التفويض الآمن قيمة Nonce فريدة ونافذة زمنية ومستقبلاً واضحاً ومبلغاً محدداً ونطاقاً صحيحاً.

الحماية من إعادة استخدام Nonce في الحسابات الذكية ERC-4337

يتيح ERC-4337 تجريد الحسابات عبر UserOperations وحسابات العقود الذكية.

يحدد معيار ERC-4337 قيمة Nonce في UserOperation على أنها معامل لمكافحة إعادة الاستخدام.

كما يشترط اعتماد التوقيعات على معرّف السلسلة وعنوان EntryPoint لمنع إعادة الاستخدام عبر السلاسل أو عبر نقاط EntryPoint متعددة.

يستخدم ERC-4337 نموذجاً لقيمة Nonce ذات تجريد جزئي.

ويمكن التعامل مع قيمة Nonce على أنها مزيج من مفتاح وتسلسل.

يتيح ذلك للحسابات الذكية دعم مسارات Nonce متعددة.

فقد تستخدم المحفظة، مثلاً، مساراً للمعاملات العادية وآخر للإجراءات الإدارية.

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

هذا التصميم أكثر مرونة من قيمة Nonce تسلسلية واحدة.

لكن هذه المرونة الإضافية تعني ضرورة إدارة مطوري المحافظ لمسارات Nonce بعناية.

مسارات Nonce

مسار Nonce هو تدفق مستقل لقيم Nonce.

وبدلاً من فرض تسلسل واحد على كل إجراء صادر عن الحساب، تتيح مسارات Nonce لفئات الإجراءات المختلفة التقدم بشكل مستقل.

يفيد ذلك الحسابات الذكية ومفاتيح الجلسات والمدفوعات المؤتمتة والاشتراكات وإجراءات الاسترداد وحركات الألعاب والمحافظ القائمة على الإضافات.

قد يخصص المستخدم، مثلاً، مساراً للإنفاق اليومي وآخر لإجراءات الاسترداد.

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

قد تحسن مسارات Nonce المرونة وتجربة المستخدم.

لكنها قد تزيد التعقيد إذا لم تعرضها المحافظ بوضوح.

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

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

تكون مسارات Nonce فعالة فقط عندما يسهل فهم قواعدها.

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

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

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

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

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

وقد يخزن عقد التصريح قيمة Nonce لكل مالك.

وقد يخزن عقد الجسر معرّفات الرسائل التي عالجها.

وقد يخزن نظام ضمان شبيه بالسوق هاشات الطلبات التي نُفذت أو أُلغيت.

كل هذه أشكال للحماية من إعادة الاستخدام.

قد تختلف بنية البيانات الدقيقة، لكن الهدف واحد.

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

الحماية من إعادة الاستخدام في الجسور

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

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

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

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

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

كما ينبغي أن يرفض الرسالة نفسها إذا أُرسلت مرة أخرى.

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

يجب أن يربط الجسر كل رسالة بسلسلة المصدر المقصودة وسلسلة الوجهة وعقد الجسر والمرسل والمستقبِل والمبلغ وقيمة Nonce.

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

الحماية من إعادة الاستخدام في المعاملات الوسيطة

المعاملة الوسيطة هي تعليمات يوقّعها المستخدم ويرسلها طرف آخر.

يوقّع المستخدم خارج السلسلة، ثم يرسل الوسيط المعاملة على السلسلة.

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

تتطلب المعاملات الوسيطة عناية في الحماية من إعادة استخدام Nonce.

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

وقد تسبب قيم Nonce التسلسلية مشكلات عندما يوقّع المستخدمون عدة معاملات وسيطة في تطبيقات مختلفة في الوقت نفسه.

قد تحد القيم العشوائية أو مساحات Nonce الخاصة بكل تطبيق من هذه التعارضات.

وقد تحد المواعيد النهائية من مخاطر التعليمات الموقّعة القديمة.

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

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

الحماية من إعادة الاستخدام في رسائل تسجيل الدخول بالمحفظة

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

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

ينبغي أن يتضمن توقيع تسجيل الدخول قيمة Nonce أو تحدياً ينشئه الخادم.

وينبغي للخادم تعليم ذلك التحدي على أنه مستخدم بعد نجاح تسجيل الدخول.

ويُستحسن أن تتضمن الرسالة أيضاً النطاق والسلسلة ووقت الإصدار ووقت الانتهاء والإجراء المقصود.

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

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

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

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

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

الحماية من إعادة الاستخدام في الحوكمة

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

قد يخزن عقد التصويت ما إذا كان عنوان ما قد صوّت على مقترح.

وقد يستخدم عقد التفويض بالتوقيع قيماً لـNonce لمنع استخدام توقيع التفويض نفسه مراراً.

وقد يعلّم نظام تنفيذ المقترحات المقترح على أنه نُفّذ بعد التنفيذ بنجاح.

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

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

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

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

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

وحتى حينها، يجب أن تكون قواعد الاحتساب النهائية واضحة.

الحماية من إعادة الاستخدام في الإيردروب والمطالبات

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

قد يخزن نظام المطالبات البسيط حالة المطالبة لكل عنوان مؤهل.

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

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

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

ينبغي أن تراعي الحماية أيضاً الفصل بين الحملات.

يجب ألا يعمل توقيع المطالبة الخاص بالحملة A في الحملة B.

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

كما يجب ألا يجيز طلب توكن معين المطالبة بتوكن آخر.

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

الحماية من إعادة الاستخدام والمواعيد النهائية

الموعد النهائي هو حد زمني لصلاحية التفويض الموقّع.

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

يستخدم تصريح ERC-2612 حقلاً للموعد النهائي.

ويستخدم ERC-3009 الحقلين validAfter وvalidBefore.

يمكن أن تتضمن UserOperations في ERC-4337 نطاقات صلاحية عبر بيانات التحقق.

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

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

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

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

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

الحماية من إعادة الاستخدام ومبدأ Idempotency

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

يشير EIP-712 إلى ضرورة رفض التطبيقات الرسائل الموقّعة المكررة أو جعل الإجراء المفوّض غير متغير بتكراره.

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

أما تحويل 100 توكن مرتين فليس أمراً غير ضار.

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

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

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

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

ينبغي رفض تكرار تنفيذ معظم الإجراءات التي تنقل قيمة.

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

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

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

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

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

وإذا وقّع المستخدم على رقم فقط من دون عنوان التوكن، فقد يُفسّر الرقم على أنه خاص بتوكن خاطئ.

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

وإذا اقتصر على عنوان المستخدم من دون عنوان العقد، فقد يقبله عقد آخر.

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

يوضح التوقيع ضيق النطاق ما هو مسموح به تحديداً ولا شيء غيره.

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

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

الحماية من إعادة الاستخدام والتصيد الاحتيالي

لا تستطيع الحماية من إعادة استخدام Nonce حماية المستخدمين من التصيد الاحتيالي حماية كاملة.

إذا وقّع المستخدم رسالة خبيثة بقيمة Nonce صالحة، فقد يستخدمها المهاجم مرة واحدة.

قد تمنع قيمة Nonce التكرار، لكن الاستخدام الأول قد يظل ضاراً.

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

وقد يتضمن التصريح قيمة Nonce صالحة وموعداً نهائياً.

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

تمنع الحماية من إعادة الاستخدام التكرار، لا النوايا الخبيثة.

لا يزال على المستخدمين مراجعة ما يوقعون عليه.

ولا يزال على المحافظ عرض تحذيرات واضحة ومفهومة.

كما يجب على العقود قصر صلاحيات التوقيعات على إجراءات محددة.

الحماية من إعادة الاستخدام والاستباق (Front-running)

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

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

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

يشير ERC-2612 إلى أن طرفاً آخر قد يسبق الطرف المقصود في استدعاء permit، مع أن أثر الموافقة النهائي قد يكون نفسه بالنسبة إلى الموقّع.

يتضمن ERC-3009 الدالة receiveWithAuthorization للحد من بعض مشكلات الاستباق، عبر ضمان تطابق المستفيد مع المستدعي.

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

تمنع قيمة Nonce تكرار التنفيذ.

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

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

ولا ينبغي للمصممين افتراض أن فحوص Nonce وحدها تحل جميع هجمات مجمع المعاملات.

الحماية من إعادة الاستخدام عبر العقود

تحدث إعادة الاستخدام عبر العقود عندما يقبل عقد توقيعاً كان مخصصاً لعقد آخر.

وقد يحدث ذلك إذا لم تتضمن البيانات الموقّعة عنوان العقد الذي يتحقق منها.

يساعد فصل النطاق في EIP-712 على الحد من هذا الخطر بإدراج verifyingContract في النطاق.

يوصي ERC-2612 بفاصل نطاق فريد للعقد والسلسلة.

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

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

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

لذلك يُعد ربط التوقيع بعنوان العقد أمراً ضرورياً.

ينبغي ألا ينتقل التوقيع الصالح بحرية بين العقود.

بل يجب أن ينتمي إلى نطاق تحقق محدد بعينه.

الحماية من إعادة الاستخدام عبر السلاسل

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

يحد EIP-155 من هذا الخطر في معاملات Ethereum بإضافة معرّف السلسلة إلى هاش المعاملة الموقّعة.

كما تدعم البيانات ذات الأنواع المحددة في EIP-712 إدراج chainId في نطاق التوقيع.

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

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

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

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

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

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

تجعل التصاميم الآمنة السلسلة واضحة.

الحماية من إعادة الاستخدام واستبدال المعاملات

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

لا يُعد ذلك بحد ذاته هجمة إعادة استخدام.

بل هو أسلوب عادي لإدارة المعاملات في كثير من مسارات العمل المشابهة لـEthereum.

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

قد يستبدل المستخدم معاملة بطيئة بأخرى أسرع.

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

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

تجعل الحماية من إعادة استخدام Nonce الاستبدال ذا معنى.

فهي تجبر الشبكة على اختيار معاملة واحدة لذلك الموضع.

ينبغي للمستخدمين توخي الحذر، لأن استبدال قيمة Nonce خاطئة قد يلغي إجراءً ما زالوا يريدونه أو يحل محله.

الحماية من إعادة الاستخدام والمعاملات العالقة

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

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

وهذا أثر جانبي للقيم التسلسلية.

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

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

تدير المحافظ ذلك عادةً تلقائياً، لكن تعيين قيم Nonce يدوياً قد يسبب التباساً.

إذا عين المستخدم قيمة أعلى من اللازم، فقد لا تُؤكد المعاملة إلى أن تُستكمل قيم Nonce السابقة.

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

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

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

الحماية من إعادة الاستخدام ومفاتيح الجلسات

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

تفيد في الألعاب والاشتراكات والاستراتيجيات المؤتمتة ومحافظ تجريد الحسابات.

تحتاج إلى حماية قوية من إعادة استخدام Nonce لأنها قد توقّع عدداً كبيراً من الإجراءات الصغيرة.

ينبغي أن يتضمن تفويض مفتاح الجلسة قيوداً مثل الوظائف المسموح بها وحدود الإنفاق وعقود الوجهة ووقت الانتهاء ومعرّف السلسلة وقواعد Nonce.

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

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

قد تساعد مسارات Nonce على فصل إجراءات مفاتيح الجلسات عن إجراءات المحفظة الرئيسية.

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

ينبغي أن يكون إلغاء مفاتيح الجلسات سهلاً.

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

الحماية من إعادة الاستخدام ومحافظ التوقيع المتعدد

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

غالباً ما تتضمن معاملة المحفظة متعددة التوقيعات قيمة Nonce داخلية لتتبع إجراءات المحفظة المنفذة.

يوافق الموقّعون على هاش معاملة محددة يتضمن قيمة Nonce الخاصة بالمحفظة وتفاصيل الإجراء.

وبعد تنفيذ المحفظة للمعاملة، تزداد قيمة Nonce أو يُعلّم هاش المعاملة على أنه منفذ.

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

ينبغي أن تربط الحماية في محافظ التوقيع المتعدد التوقيعات بعنوان المحفظة ومعرّف السلسلة والعنوان المستهدف والقيمة والبيانات ونوع العملية وقيمة Nonce.

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

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

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

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

الحماية من إعادة الاستخدام وOracles

قد توقّع أنظمة Oracle تحديثات الأسعار أو شهادات البيانات أو تقارير الاحتياطيات أو مخرجات العشوائية أو الرسائل عبر السلاسل.

وتحتاج حزم البيانات الموقّعة هذه إلى حماية من إعادة الاستخدام.

يجب ألا يظل تحديث السعر القديم مقبولاً إلى الأبد.

ولا ينبغي إعادة استخدام نتيجة عشوائية في جولة لعبة مختلفة.

كما يجب ألا يعاد استخدام شهادة احتياطيات بعد انتهاء صلاحيتها.

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

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

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

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

حداثة بيانات Oracle وضبط Nonce كلاهما جزء من أمان العقود الذكية.

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

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

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

تستخدم الموافقة العادية على السلسلة قيمة Nonce لمعاملة الحساب وتحدّث حالة الحد المسموح به للإنفاق.

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

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

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

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

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

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

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

يقلل تصميم الموافقات المقاوم لإعادة الاستخدام أحد أكثر المسارات شيوعاً لسرقة أصول المحافظ.

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

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

إذا رُقّي العقد، فقد تظل التوقيعات القديمة صالحة ما لم يتغير إصدار النطاق أو منطق Nonce أو قواعد التحقق.

يتضمن EIP-712 حقلاً للإصدار في نطاق التوقيع لهذا السبب.

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

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

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

قد يؤدي عدم نقل حالة Nonce إلى إتاحة إعادة استخدام التوقيعات القديمة أو جعل التوقيعات الصالحة غير قابلة للاستخدام.

ينبغي أن تتضمن خطط الترقية نقل التوقيعات وتغيير النطاق وتخطيط تخزين Nonce والتواصل مع المستخدمين.

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

بل يجب أن تستمر خلال الترقيات وعمليات النقل.

الحماية من إعادة الاستخدام والانقسامات

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

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

صُممت حماية معرّف السلسلة في EIP-155 للحد من هذا الخطر في معاملات Ethereum.

ومع ذلك، تظل التوقيعات على مستوى التطبيقات بحاجة إلى ربطها بالسلسلة.

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

ينبغي للمستخدمين توخي الحذر أثناء انقسامات السلاسل.

وينبغي للمحافظ والتطبيقات تحديث معرّفات السلاسل وفواصل النطاق على نحو صحيح.

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

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

ويحتاج كلا المستويين إلى الاهتمام.

فوائد الحماية من إعادة استخدام Nonce

الفائدة الأولى هي التفويض لمرة واحدة.

يمكن استهلاك الإجراء الموقّع مرة واحدة ثم رفضه.

الفائدة الثانية هي تميّز المعاملات.

يمكن فصل معاملات الحساب نفسه باستخدام قيم Nonce.

الفائدة الثالثة هي ترتيب المعاملات.

تساعد قيم Nonce التسلسلية على تحديد الترتيب الصالح لمعاملات الحساب.

الفائدة الرابعة هي الأمان عبر السلاسل عند اقترانها بمعرّفاتها.

إذ يمكن ربط التوقيعات بالشبكة المقصودة.

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

يمكن للعقود منع تكرار التصاريح والمطالبات والأصوات والتحويلات ورسائل الجسور.

الفائدة السادسة هي تحسين أمان تجربة المستخدم.

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

مخاطر الحماية من إعادة استخدام Nonce وقيودها

القيد الأول هو أن الحماية باستخدام Nonce لا تمنع أول استخدام خبيث لرسالة موقّعة.

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

القيد الثاني هو تعقيد إدارة المعاملات.

قد تؤدي قيم Nonce التسلسلية إلى معاملات عالقة وقوائم انتظار محجوبة.

القيد الثالث هو تكلفة التخزين.

قد تزيد العقود التي تخزن قيماً عشوائية مستخدمة لـNonce من استهلاك التخزين على السلسلة.

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

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

القيد الخامس هو تعقيد النطاقات المتعددة.

قد تحمي قيمة Nonce عقداً، لكنها لا تحمي عقداً أو سلسلة أخرى.

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

قد تتعطل حالة Nonce أثناء نقل العقود إذا لم تُدار بعناية.

أخطاء شائعة في الحماية من إعادة استخدام Nonce

من الأخطاء الشائعة التحقق من التوقيع من دون التحقق من قيمة Nonce.

ومنها التحقق من قيمة Nonce مع نسيان زيادتها أو تعليمها على أنها مستخدمة.

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

والخطأ الرابع إغفال معرّف السلسلة من البيانات الموقّعة.

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

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

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

والخطأ الثامن عدم نقل تخزين Nonce أثناء الترقيات.

والخطأ التاسع استخدام قيم عشوائية يمكن توقعها لـNonce.

والخطأ العاشر افتراض أن EIP-712 يمنع تلقائياً جميع هجمات إعادة الاستخدام.

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

أدرج قيمة Nonce في كل تفويض خارج السلسلة يمكنه تغيير قيمة أو حالة.

تتبع قيم Nonce لكل موقّع بدلاً من تتبعها عالمياً، ما لم يتطلب التصميم بوضوح تسلسلاً عاماً.

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

أدرج معرّف السلسلة في نطاق التوقيع عندما يكون سياق السلسلة مهماً.

أدرج عنوان العقد الذي يتحقق من التوقيع في نطاقه.

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

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

افصل مساحات Nonce عن مسارات العمل غير المرتبطة عندما يلزم التنفيذ المتوازي.

أصدر أحداثاً عند استخدام التفويضات أو إلغائها.

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

أفضل الممارسات للمحافظ والتطبيقات

اعرض للمستخدمين السلسلة والعقد وجهة الإنفاق والمبلغ والموعد النهائي وسياق Nonce ونوع الإجراء قبل التوقيع.

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

استخدم تحديات تسجيل دخول جديدة لمصادقة المحافظ.

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

تجنب طلب توقيع رسائل مبهمة أو غير مقروءة.

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

تعامل بوضوح مع قيم Nonce للمعاملات العالقة، ووفر خيارات التسريع والإلغاء.

لا تخفِ سلوك استبدال المعاملات عن المستخدمين.

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

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

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

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

تحقق من السلسلة قبل التوقيع.

تحقق من العقد أو التطبيق الذي يطلب التوقيع.

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

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

لا توقّع رسائل تسجيل دخول من نطاقات مشبوهة.

لا تفترض أن قيمة Nonce تجعل التوقيع الخبيث آمناً.

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

ألغِ موافقات التوكنات غير الضرورية عند الاقتضاء.

توخَّ الحذر عند تعيين قيم Nonce يدوياً ما لم تكن تفهم حالة المعاملات المعلقة.

متى تكون الحماية من إعادة استخدام Nonce أكثر أهمية؟

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

وهي مهمة للمعاملات العادية على البلوكتشين.

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

وهي مهمة لتحويلات التوكنات دون رسوم الغاز.

وهي مهمة لرسائل الجسور.

وهي مهمة لأصوات الحوكمة والتفويضات.

وهي مهمة لمطالبات الإيردروب ومطالبات المكافآت.

وهي مهمة لتحديات تسجيل الدخول بالمحفظة.

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

وهي مهمة في كل موضع قد يؤدي فيه نسخ توقيع إلى آثار متكررة أو غير مقصودة.

الحماية من إعادة استخدام Nonce في جملة واحدة

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

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

ما المقصود بالحماية من إعادة استخدام Nonce؟

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

ما قيمة Nonce في العملات المشفرة؟

Nonce رقم أو قيمة فريدة تُستخدم مرة واحدة في سياق محدد لجعل معاملة أو رسالة أو تفويض فريداً.

ما هجمة إعادة الاستخدام؟

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

كيف تستخدم Ethereum قيم Nonce؟

تستخدم حسابات Ethereum عدّاد Nonce بحيث لا يمكن تنفيذ سوى معاملة واحدة لكل حساب تحمل قيمة Nonce معينة.

ما الحماية من إعادة الاستخدام باستخدام معرّف السلسلة؟

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

هل يمنع EIP-712 هجمات إعادة الاستخدام تلقائياً؟

لا. ينظم EIP-712 البيانات الموقّعة، لكن التطبيقات تظل بحاجة إلى فحوص Nonce ومواعيد نهائية وفصل صحيح للنطاق.

لماذا تحتاج التصاريح إلى قيم Nonce؟

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

ما الفرق بين قيمة Nonce والموعد النهائي؟

تجعل قيمة Nonce التوقيع صالحاً للاستخدام مرة واحدة، بينما يحد الموعد النهائي من مدة صلاحية التوقيع.

هل تمنع الحماية من إعادة الاستخدام التصيد الاحتيالي؟

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

ماذا يحدث إذا أُعيد استخدام قيمة Nonce؟

إذا عولجت قيمة Nonce على نحو صحيح، فينبغي أن يفشل الاستخدام الثاني. لكن سوء التصميم قد يؤدي إلى إعادة الاستخدام أو فشل المعاملات.

لماذا تحتاج العقود الذكية إلى فحوص Nonce خاصة بها؟

لأن قيم Nonce العادية للحسابات لا تحمي تلقائياً التوقيعات خارج السلسلة أو التصاريح أو المطالبات أو الأصوات أو رسائل الجسور.

ما تصميم الحماية من إعادة الاستخدام الأكثر أماناً؟

يجمع التصميم الأكثر أماناً بين قيم Nonce لكل موقّع ومعرّف السلسلة والعقد الذي يتحقق من التوقيع وتفاصيل الإجراء الدقيقة والموعد النهائي وتتبع حالة الاستخدام والتحقق الدقيق من التوقيع.

الخاتمة

الحماية من إعادة استخدام Nonce إحدى ركائز الأمان الأساسية غير الظاهرة في العملات المشفرة.

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

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

تضيف قيمة Nonce طبقة الحداثة هذه.

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

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

تتجاوز الحماية الحديثة من إعادة الاستخدام استخدام عدّاد واحد.

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

تعالج كل طبقة مشكلة مختلفة من مشكلات إعادة الاستخدام.

تمنع قيم Nonce الحسابات تكرار معاملات الحساب نفسه على السلسلة نفسها.

وتمنع معرّفات السلاسل نسخ المعاملات بين السلاسل.

وتمنع قيم Nonce الخاصة بالعقود إعادة استخدام الرسائل الموقّعة داخل التطبيقات.

وتمنع المواعيد النهائية بقاء التوقيعات القديمة صالحة إلى الأبد.

ويمنع فصل النطاق انتقال التوقيعات إلى العقد أو التطبيق الخطأ.

وتتيح مسارات Nonce للحسابات الذكية دعم سير عمل متوازٍ مع الحفاظ على الحماية من إعادة الاستخدام.

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

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

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

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

والقاعدة بسيطة للمطورين.

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

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

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

لا تجعل الحماية من إعادة استخدام Nonce العملات المشفرة خالية من المخاطر.

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