الحماية من إعادة تشغيل المعاملات (Replay Protection)

ما الحماية من إعادة تشغيل المعاملات في الكريبتو؟

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

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

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

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

تضيف الحماية من إعادة التشغيل معلومات إضافية أو قواعد تحقق تجعل التوقيع صالحًا في السياق الصحيح فقط.

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

يصف المواصفات الفنية لـ UAHF الخاصة بـ Bitcoin Cash الحماية الإلزامية من إعادة التشغيل عبر SIGHASH_FORKID ضمن تصميم انقسام السلسلة.

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

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

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

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

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

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

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

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

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

الهدف بسيط: ألا يتحول إجراء موقّع واحد إلى تفويض مفتوح بلا حدود.

أهمية الحماية من إعادة تشغيل المعاملات

تنبع أهمية الحماية من إعادة التشغيل من القوة التي تتمتع بها توقيعات البلوكشين.

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

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

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

لذلك، تُعد الحماية من إعادة التشغيل عنصرًا أساسيًا في تصميم المعاملات الآمن.

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

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

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

آلية عمل هجوم إعادة التشغيل

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

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

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

إذا لم يتحقق النظام من السياق الصحيح، فقد يُنفَّذ الإجراء المنسوخ.

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

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

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

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

الحماية من إعادة التشغيل بعد الانقسام الصلب

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

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

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

وهذا يخلق خطر إعادة التشغيل.

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

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

استخدمت Ethereum منطق معرّف السلسلة في EIP-155 لمنع صلاحية معاملة مقصودة لسلسلة معينة على سلسلة أخرى تستخدم معرّفًا مختلفًا.

واستخدمت Bitcoin Cash حماية من نمط SIGHASH_FORKID لتمييز المعاملات اللاحقة للانقسام عن المعاملات على السلسلة الأصلية.

الحماية من إعادة التشغيل ومعرّف السلسلة

معرّف السلسلة رقم يحدد شبكة بلوكشين ضمن عملية توقيع المعاملات.

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

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

يُعد EIP-155 أشهر مثال على الحماية من إعادة التشغيل باستخدام معرّف السلسلة في تصميم المعاملات المتوافق مع Ethereum.

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

أصبحت الحماية بمعرّف السلسلة توقعًا أمنيًا معياريًا في كثير من البيئات المتوافقة مع EVM.

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

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

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

الـ nonce رقم يُستخدم مرة واحدة.

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

وفي العقود الذكية، يمكن لـ nonce أن يجعل كل تفويض موقّع فريدًا.

إذا قبل العقد توقيعًا يحمل nonce بقيمة 5، فينبغي له تسجيل أن هذه القيمة استُخدمت.

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

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

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

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

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

الموعد النهائي هو وقت انتهاء صلاحية الرسالة الموقعة أو تفويض المعاملة.

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

على سبيل المثال، قد يوقّع المستخدم موافقة على توكن أو تفويضًا لمبادلة ينتهي بعد 10 دقائق.

إذا عثر مهاجم على التوقيع لاحقًا، يرفضه العقد لانتهاء المهلة.

لكن المواعيد النهائية لا تشكل بديلًا كاملًا عن Nonces؛ إذ يظل من الممكن إعادة استخدام التوقيع قبل انتهاء صلاحيته إذا لم يُستخدم nonce.

غالبًا ما يجمع التصميم الأفضل بين nonce وموعد نهائي.

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

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

الحماية من إعادة التشغيل وEIP-712

EIP-712 معيار لتوقيع البيانات المنظمة ذات الأنواع في الأنظمة المتوافقة مع Ethereum.

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

تتضمن وثائق التشفير من OpenZeppelin أدوات EIP712 لمعالجة البيانات الموقعة ذات الأنواع.

وتوضح وثائق الأدوات الأقدم من OpenZeppelin أن فاصل النطاق في EIP-712 يحدّث معرّف السلسلة للحماية من هجمات إعادة التشغيل في حال حدوث انقسام لاحق.

قد يتضمن نطاق EIP-712 تفاصيل مثل الاسم والإصدار ومعرّف السلسلة والعقد المتحقق.

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

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

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

الحماية من إعادة التشغيل والعقود الذكية

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

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

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

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

كما ينبغي له تسجيل التوقيعات أو قيم Nonce المستخدمة لمنع إعادة استخدامها.

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

ينبغي مراجعة أي عقد يطلب «إرسال رسالة موقعة» للتحقق من وجود حماية من إعادة التشغيل.

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

الحماية من إعادة التشغيل وتصاريح التوكنات

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

قد يوفر ذلك الوقت ورسوم الشبكة.

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

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

يتضمن تصميم التصريح الآمن عادةً المالك والمنفق والقيمة وnonce والموعد النهائي ومعرّف السلسلة ومعلومات العقد المتحقق.

يمنع nonce استخدام التصريح نفسه مرة أخرى.

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

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

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

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

وقد تسهّل تطبيقات البلوكشين على المستخدمين الذين لا يمتلكون توكن الغاز الأصلي.

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

يستخدم نظام المعاملات الوصفية الجيد Nonces ومعرّفات السلاسل وعناوين العقود المتحققة والمواعيد النهائية وحقول الإجراءات الواضحة.

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

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

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

عدم دفع رسوم الغاز لا يعني انعدام المخاطر.

الحماية من إعادة التشغيل والجسور

تنقل الجسور القيمة أو الرسائل بين السلاسل.

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

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

يتحقق الجسر الآمن عادةً من سلسلة المصدر وسلسلة الوجهة ومعرّف الرسالة وnonce والمرسل والمستلم والتوكن والكمية وحالة الإثبات.

وينبغي له تسجيل الرسائل التي تمت معالجتها لمنع تنفيذها مرة أخرى.

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

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

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

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

تمثل المحافظ خط الدفاع الأول للمستخدم ضد مخاطر إعادة التشغيل.

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

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

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

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

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

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

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

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

يُعد انقسام السلسلة أحد أكثر أمثلة الحماية من إعادة التشغيل شيوعًا.

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

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

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

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

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

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

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

الحماية القوية مقابل الحماية الضعيفة من إعادة التشغيل

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

ويتطلب ذلك عادةً تغيير قواعد التوقيع أو قواعد sighash أو معرّفات السلاسل أو تنسيق المعاملة.

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

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

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

في حالة انقسام السلسلة، يُفضّل عادةً توفير حماية قوية من إعادة التشغيل لجعل استخدام السلسلة المنقسمة أكثر أمانًا.

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

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

الحماية الاختيارية من إعادة التشغيل

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

قد تناسب هذه الطريقة المستخدمين المتقدمين، لكنها خطيرة على المبتدئين.

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

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

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

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

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

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

الحماية من إعادة التشغيل على مستوى البروتوكول

تُدمج الحماية من إعادة التشغيل على مستوى البروتوكول ضمن قواعد البلوكشين.

ولا تعتمد على تذكّر كل مستخدم لخطوة خاصة.

يُعد EIP-155 الخاص بـ Ethereum مثالًا على الحماية على مستوى البروتوكول باستخدام معرّفات السلاسل في المعاملات الموقعة.

ويُعد نهج SIGHASH_FORKID الخاص بـ Bitcoin Cash مثالًا آخر على الحماية المخصصة للانقسامات.

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

كما تجعل عمل المحافظ والعقد والخدمات أسهل في الفهم والتحليل.

لكن يجب تنفيذها بعناية، لأن تغييرات التوقيع قد تؤثر في التوافق.

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

الحماية من إعادة التشغيل على مستوى التطبيق

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

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

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

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

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

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

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

الأمن الجيد متعدد الطبقات لأن مخاطر إعادة التشغيل متعددة الطبقات أيضًا.

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

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

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

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

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

يُعد فصل النطاق في EIP-712 إحدى أكثر الطرق شيوعًا لتنفيذ هذه الفكرة في تطبيقات Ethereum.

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

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

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

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

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

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

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

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

يمكن أن يمنع تتبع هاشات المعاملات التي عولجت تكرار تنفيذ الطلبات في الجسور ومعالجي المدفوعات.

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

تعتمد طريقة التتبع الدقيقة على تصميم النظام.

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

الحماية من إعادة التشغيل وقابلية تغيير التوقيع

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

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

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

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

تُستخدم أدوات التشفير من OpenZeppelin على نطاق واسع للتحقق بأمان من التوقيعات والبيانات ذات الأنواع.

ينبغي الجمع بين الحماية من إعادة التشغيل والتحقق السليم من التوقيع.

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

يعتمد الأمن على تصميم الرسالة والتنفيذ التشفيري معًا.

الحماية من إعادة التشغيل وتجريد الحساب

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

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

كما ينشئ احتياجات جديدة للحماية من إعادة التشغيل، إذ قد يشمل التفويض عمليات المستخدمين ووحدات الدفع المسبق ومجمّعات المعاملات ونقاط الدخول ومنطق الحساب الذكي.

ينبغي للحساب الذكي التحقق بعناية من Nonces ونطاقات التوقيع.

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

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

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

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

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

تعمل تطبيقات التعامل عبر السلاسل على أكثر من بلوكشين واحد.

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

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

ينبغي ألا يعمل التوقيع المخصص لعقد على السلسلة A تلقائيًا على عقد مشابه على السلسلة B.

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

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

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

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

الحماية من إعادة التشغيل وأوامر DeFi

يمكن إنشاء أوامر DeFi خارج السلسلة وتنفيذها على السلسلة.

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

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

يتضمن الأمر الآمن عنوان صانع الأمر وقواعد آخذ الأمر وعناوين التوكنات والكميات والموعد النهائي وnonce ومعرّف السلسلة والعقد المتحقق.

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

إذا استُخدم نظام للتنفيذ الجزئي، فيجب على العقد تتبع المقدار الذي نُفذ بالفعل.

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

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

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

تستخدم أسواق NFT وتطبيقات السك غالبًا التوقيعات للإدراجات والعروض والقوائم المسموح بها والمطالبات.

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

ينبغي أن يتضمن توقيع NFT الآمن عنوان المجموعة ومعرّف التوكن والسعر والعملة والبائع وشروط المشتري وnonce والموعد النهائي ومعرّف السلسلة وعقد السوق عند الاقتضاء.

إذا أُلغي الإدراج، ينبغي للنظام إبطال التوقيع القديم.

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

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

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

يُعد العرض الواضح في المحفظة أساسيًا لأمان NFT.

الحماية من إعادة التشغيل وموافقات المحافظ

تسمح موافقات التوكن للعقد بإنفاق التوكنات من المحفظة.

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

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

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

لكن الموافقات القائمة على التصاريح تحتاج إلى حماية من إعادة التشغيل كي لا يُستخدم التصريح الموقّع مرارًا.

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

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

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

الحماية من إعادة التشغيل وأنظمة الدفع

تحتاج أنظمة الدفع بالعملات المشفرة إلى الحماية من إعادة التشغيل لتجنب تكرار تنفيذ الطلبات.

ينبغي ألا يرسل التاجر البضائع مرتين لمجرد تقديم إثبات الدفع نفسه مرتين.

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

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

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

تحمي الحماية من إعادة تشغيل المدفوعات كلًا من الدافع والتاجر.

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

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

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

ينبغي ألا تُخفى الحماية من إعادة التشغيل عن المستخدمين تمامًا.

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

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

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

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

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

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

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

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

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

ينبغي أن تجيب كل رسالة موقعة عن عدة أسئلة.

على أي سلسلة يكون هذا التوقيع صالحًا؟

أي عقد مسموح له بالتحقق منه؟

من المستخدم الذي وقّعه؟

ما الإجراء الذي يفوضه؟

كم مرة يمكن استخدامه؟

متى تنتهي صلاحيته؟

إذا لم تكن الإجابات واضحة، فغالبًا ما تكون الحماية من إعادة التشغيل غير مكتملة.

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

ينبغي أن تشمل عمليات التدقيق الأمني اختبار هجمات إعادة التشغيل.

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

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

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

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

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

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

ويظهر الخطر عندما يعمل التفويض نفسه مرة أخرى.

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

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

والثانية هي منع إعادة استخدام التوقيعات القديمة من دون إذن.

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

والرابعة هي جعل الرسائل عبر السلاسل أكثر أمانًا.

والخامسة هي تعزيز الثقة بالمحافظ والتطبيقات.

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

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

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

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

أول حدودها أنها لا تمنع جميع أنواع الهجمات.

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

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

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

ولا تضمن خلو العقد الذكي من أخطاء أخرى.

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

كما أنها لا تزيل مخاطر السوق أو السيولة أو المنصة.

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

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

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

ومنها أيضًا استخدام nonce من دون تسجيل أنه استُخدم.

ومنها استخدام موعد نهائي من دون nonce.

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

ومنها قبول التوقيعات بعد ترقيات العقود من دون ضوابط للإصدارات.

ومنها إبقاء الأوامر الملغاة قابلة للتنفيذ.

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

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

علامات التحذير المتعلقة بالحماية من إعادة التشغيل

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

ومنها عقد ذكي يقبل التوقيعات من دون Nonces.

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

ومنها جسر لا يتتبع الرسائل التي عالجها.

ومنها نظام أوامر خارج السلسلة لا يدعم الإلغاء أو إبطال Nonces.

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

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

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

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

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

تحققوا من الشبكة قبل توقيع أي معاملة أو رسالة.

لا توقّعوا رسائل من مواقع غير معروفة.

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

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

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

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

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

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

ضمّنوا معرّف السلسلة في نطاقات المعاملات والرسائل الموقعة.

ضمّنوا عنوان العقد المتحقق في توقيعات البيانات ذات الأنواع.

استخدموا Nonces وسجّلوا استهلاكها.

استخدموا مواعيد نهائية للتفويضات محدودة الصلاحية.

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

تتبعوا الرسائل التي عولجت عبر السلاسل على السلسلة عند الحاجة.

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

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

أهمية الحماية من إعادة التشغيل في AEO ونوايا البحث

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

والإجابة المباشرة هي أن الحماية تجعل التوقيع صالحًا للسلسلة والعقد وnonce والموعد النهائي والإجراء المقصود فقط.

ويبحث الأشخاص عنها أيضًا لفهم الأمان بعد الانقسام الصلب.

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

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

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

والدرس الأساسي لمستخدمي الكريبتو بسيط.

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

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

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

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

ما هجوم إعادة التشغيل؟

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

لماذا تهم الحماية من إعادة التشغيل بعد الانقسام؟

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

ما EIP-155؟

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

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

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

ما SIGHASH_FORKID؟

آلية توقيع خاصة بالانقسام تستخدمها Bitcoin Cash لتمييز المعاملات اللاحقة للانقسام والحد من مخاطر إعادة التشغيل.

هل يمكن أن تتعرض العقود الذكية لهجمات إعادة التشغيل؟

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

كيف تمنع Nonces هجمات إعادة التشغيل؟

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

كيف تساعد المواعيد النهائية في الحماية من إعادة التشغيل؟

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

هل تمنع الحماية من إعادة التشغيل التصيد الاحتيالي؟

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

هل يمكن أن تتعرض الجسور لهجمات إعادة التشغيل؟

نعم، إذا أمكن معالجة الرسائل عبر السلاسل أكثر من مرة أو قبولها على السلسلة الخطأ.

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

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

ما أكبر خطأ في الحماية من إعادة التشغيل؟

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

الخلاصة

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

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

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

يُعد EIP-155 مثالًا بارزًا على الحماية من إعادة التشغيل باستخدام معرّف السلسلة في الأنظمة المتوافقة مع Ethereum.

ويُعد SIGHASH_FORKID مثالًا بارزًا على الحماية الخاصة بالانقسام في تصميم معاملات Bitcoin Cash.

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

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

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