الانتقال إلى المحتوى
Financial Context Wiki

توقيعات EIP-712 المهيكلة: النطاقات والملخصات والتحقق الآمن

يجعل EIP-712 رسائل Ethereum المهيكلة حتمية وقابلة للعرض، لكن التوقيع الآمن يتطلب التحقق الدقيق من النطاق والنوع والقيمة والرقم الفريد والمهلة والتنفيذ وسياسة الموقّع.

آخر تحديث

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

الإجابة المباشرة

يوحّد EIP-712 طريقة وصف تطبيقات Ethereum للبيانات المهيكلة ذات الأنواع، وحساب تجزئتها، وطلب توقيعها. يتضمن الطلب types وprimaryType وdomain وmessage، ويكون ملخصه keccak256("\x19\x01" || domainSeparator || hashStruct(message)). يجعل ذلك الترميز حتميًا، ويسمح للمحفظة المتوافقة بعرض الحقول بوضوح أكبر من تجزئة مبهمة.

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

توقيعات EIP-712 المهيكلة
0 / 5
0 العناصر التي تمت مراجعتها; 5 العناصر لا تزال دون حل

إن استكمال هذه المراجعة لا يثبت أن الأصل أو المعاملة أو النظام آمن.

آلية العمل

1. تحديد الإجراء ومسار التحقق

حدّد ما إذا كان الطلب يجيز تسجيل الدخول أو أمرًا أو تصويتًا أو سماحية رمز أو تحويلًا أو استدعاءً عبر مرحّل أو إجراءً آخر. اعثر على الكود الذي يعيد بناء الملخص ويستهلك التوقيع. في الحساب المملوك خارجيًا، يستعيد التحقق عادة عنوانًا من توقيع ECDSA؛ أما حساب العقد فقد يتطلب ERC-1271 isValidSignature(hash, signature) وفحص قيمة النجاح 0x1626ba7e.

2. تثبيت النطاق

افحص نوع EIP712Domain الدقيق وقيمه. الحقول القياسية هي name وversion وchainId وverifyingContract وsalt، لكن الحقول المدرجة فقط تدخل في التجزئة. أكّد مستقلًا الشبكة النشطة والكود المنشور وعقد التحقق المقصود؛ فلا يكفي اسم أو رمز أو ملصق وكيل أو عنوان checksum مألوف. يمكن لـ ERC-5267 eip712Domain() كشف النطاق، لكن دعمه اختياري ويظل سلوك الوكيل والترقية بحاجة إلى مراجعة.

3. إعادة بناء مخطط الأنواع

ابدأ من primaryType، وحافظ على ترتيب الأعضاء، واجمع البنى المشار إليها تكراريًا. يضيف encodeType تعريفاتها مرتبة حسب اسم النوع. يدعم EIP-712 الأعداد الصحيحة ثابتة العرض وaddress وbool ومن bytes1 إلى bytes32 وbytes وstring الديناميكيين والمصفوفات والبنى؛ ولا يعرّف الاختصارين uint وint أو أنواع الفاصلة الثابتة أو القيم الدورية.

4. فك كل قيمة ووحدة

طابق كل قيمة مع نوعها المعلن ومعناها في التطبيق. افحص العناوين كاملة والوحدات الصحيحة الخام والإشارات وترتيب المصفوفات والمستلمين والمنفقين والأصول والمبالغ والرسوم والحدود والوجهات وتجزئات calldata والنصوص المقروءة. تُمثل bytes وstring الديناميكية داخل encodeData بتجزئة Keccak-256 لمحتواها؛ وتستخدم المصفوفات تجزئة ترميزات العناصر المتصلة، وتستخدم البنى المتداخلة hashStruct الخاص بها.

5. إعادة حساب الملخص بشكل مستقل

احسب typeHash = keccak256(encodeType(primaryType)) ثم hashStruct(message) = keccak256(typeHash || encodeData(message)). احسب فاصل النطاق بالطريقة نفسها، واجمعه مع بايتي إصدار ERC-191 0x19 0x01. قارن نتيجة الواجهة ومكتبة التوقيع وعقد التحقق وتنفيذ مستقل؛ فتماثل شكل JSON لا يثبت تماثل الترميز ذي الأنواع.

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

لا يتضمن EIP-712 بذاته حماية من إعادة الاستخدام. تأكد من أن عقد التحقق يفحص الموقّع المقصود، ويستهلك الرقم الفريد الصحيح أو يبطله، ويفرض deadline أو نافذة الصلاحية، ويربط كل معاملات التنفيذ الحساسة، ويحافظ على النتيجة المقصودة إذا أرسل المرحّل أو المتسابق أولًا. يفصل النطاق بين النطاقات المرمزة فعليًا فقط؛ وقد تترك الحقول المفقودة أو الخاطئة مسارات إعادة استخدام بين العقود أو الشبكات.

7. التوقيع بأقل صلاحية ومطابقة النتيجة

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

أمثلة حسابية

المثال 1: بناء النوع والملخص

في Order(address maker,address token,uint256 amount,uint256 nonce,uint256 deadline)، تكون typeHash تجزئة Keccak-256 لهذه السلسلة الدقيقة بما فيها ترتيب الحقول. تجزئة الرسالة هي keccak256(typeHash || maker || token || amount || nonce || deadline) ويشغل كل عضو مرمز 32 بايت. يضيف الملخص النهائي 0x1901 وفاصل النطاق وتجزئة الرسالة؛ ويؤدي تغيير amount من 250000000 إلى 250000001 إلى تغيير الملخص وإبطال التوقيع القديم.

المثال 2: الوحدات والمهلة

يُرمز مبلغ 250 USDC لرمز من ست خانات عشرية بالقيمة الخام 250000000 لا 250. إذا كان الطابع الزمني الحالي 1727000000 والمهلة 1727000900، فالنافذة هي 900 seconds = 15 minutes. العرض العشري للمحفظة والساعة المحلية وسيلتا مساعدة فقط؛ إذ يستخدم عقد التحقق العدد الخام وقاعدة الوقت على السلسلة التي اختارها.

المثال 3: التحكم في إعادة الاستخدام

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

المثال 4: صلاحية محفظة العقد

توافق محفظة عقد 2 من 3 على ملخص عند إعداد الموقّعين A وB وC. قد تجعل توقيعات A وB معيار ERC-1271 يعيد 0x1626ba7e اليوم. إذا استبدلت ترقية الوحدة B بـ D فقد تصبح بايتات التوقيع نفسها غير صالحة، لأن صلاحية ERC-1271 قد تعتمد على حالة العقد وسياساته ووقته واستدعاءاته الخارجية الحالية؛ ولا يكفي استرداد العنوان لتقرير صلاحية حساب العقد.

المخاطر

  • chainId خاطئ أو مفقود
  • verifyingContract مزيف أو غير متوقع
  • name أو version مضلل في النطاق
  • تغيّر تنفيذ الوكيل أو النطاق بعد الترقية
  • primaryType خاطئ أو نوع خفي بملصق مشابه
  • عدم تطابق ترتيب الأعضاء أو التبعيات أو المرمّز
  • اختصار العنوان أو استبداله أو وسمه بصورة مضللة
  • خطأ في خانات الرمز أو العدد الصحيح ذي الإشارة
  • عنصر مصفوفة أو بنية متداخلة أو حمولة bytes مخفية
  • مبلغ غير محدود أو نطاق واسع أو مستلم يتحكم فيه المهاجم
  • رقم فريد مفقود أو قديم أو مشترك أو مستهلك خطأ
  • مهلة مفقودة أو بعيدة أو فائضة أو غامضة التفسير
  • إعادة استخدام بين الشبكات أو العقود أو الحسابات أو الإجراءات
  • حجب المرحّل أو رقابته أو سبقه أو إعادة توجيهه للتنفيذ
  • قابلية تغيير التوقيع أو تساهل استرداد ECDSA
  • تغيّر موقّع ERC-1271 أو وحدته أو عتبته أو حالته أو كوده
  • فشل عرض المحفظة أو التوقيع الأعمى أو نوع غير مدعوم
  • اختلاف JSON في الواجهة عن ملخص عقد التحقق
  • خسارة الإلغاء أو السحب في سباق ترتيب المعاملات
  • الخلط بين مطالبة التوقيع والإيصال وتغيّر الحالة والنهائية

مفاهيم خاطئة شائعة

المفهوم الخاطئ 1: توقيعات EIP-712 معاملات

هي رسائل موقعة خارج السلسلة. يمكن لمرحّل أو طرف آخر إرسالها لاحقًا إلى عقد، وقد تستهلك المعاملة الناتجة Gas وتغيّر الحالة من دون أن يرسلها الموقّع.

المفهوم الخاطئ 2: العرض المهيكل يعني أن الطلب آمن

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

المفهوم الخاطئ 3: فاصل النطاق يمنع كل إعادة استخدام

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

المفهوم الخاطئ 4: استرداد العنوان المتوقع يثبت الصلاحية

يثبت الاسترداد توقيع حساب خارجي على الملخص، لا معنى التطبيق. تحتاج حسابات العقود إلى سياسة ERC-1271 الخاصة بها بدل استرداد العنوان العادي.

المفهوم الخاطئ 5: إغلاق الصفحة أو فصل المحفظة يلغي التوقيع

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

موضوعات ذات صلة

المصادر

التنقل

ابحث في الويكي...