يركز EIP-8361 بشكل خاص على القبول المعتمد على الإثبات لمعاملات إطار EIP-8141، دون أن يحل محل تنفيذ Ethereum أو يقدم نوع معاملة جديد أو ينشر عقدًا ذكيًا أو يوفر خصوصية للمعاملات أو يغيّر مكافآت المُدقِّقين أو يحدد فترة تنفيذ 18 شهرًا. الهدف العملي هو تقليل الحسابات الزائدة عند التحقق من المعاملات مع الحفاظ على الضمانات ضد المعاملات غير الصالحة أو كثيفة الموارد.
توضح الأقسام التالية آلية عمل الإثبات، وما تتحقق منه العقد، والفروق بين EIP-8361 وإثباتات صحة الـrollup ومحاكاة المعاملات، إضافة إلى القيود التقنية غير المحلولة.
النقاط الرئيسية
- EIP-8361 يوحّد بيانات إثبات صحة المعاملات لتسهيل نشرها بين النظراء. قد تحمل معاملة الإطار إثبات STARK يثبت وصول بادئة التحقق إلى حالة معتمدة.
- العقد تتحقق من الإثبات بدلًا من إعادة تنفيذ منطق التفويض المكلف. هذا الفصل بين الإثبات والتحقق يقلل من تكرار العمليات الحسابية على مستوى العقد في شبكة Ethereum.
- الإثبات خارج الإجماع. يُرسل مع المعاملة، ويستخدم للقبول في الـmempool، ويتم تجاهله عند عدم الحاجة.
- التصميم يدعم التحقق المعقّد من الحسابات الذكية. مثل قواعد التوقيع المتعدد، أنظمة التوقيع البديلة، ممولي الرسوم، والتفويضات المعتمدة على الإثبات.
- EIP-8361 ما زال مسودة. لم يتم تفعيله كتحديث ولا ينبغي الخلط بينه وبين EIP-7701 أو EIP-7702 أو إثباتات الـrollup أو مقترحات مكافآت التخزين.
ما هو EIP-8361؟
يقترح EIP-8361، بعنوان إثباتات صحة المعاملات، آلية شبكية تسمح للمعاملة بأن تصل مع دليل تشفيري يثبت أن منطق التحقق الخاص بها يوافق عليها. هذه المسودة مكملة لتغييرات البروتوكول في EIP-8141، الذي يحدد معاملات الإطار ومراحل التحقق القابلة للبرمجة.
مقترح تحسين Ethereum هو وثيقة تقنية تصف معيارًا أو ميزة أو واجهة أو عملية محتملة. نشر EIP لا يعني اعتماده أو تنفيذه تلقائيًا. يظل EIP-8361 مسودة قابلة للتغيير في المواصفات والاعتماديات والحالة.
يجيب المقترح عن سؤال جوهري:
كيف يمكن للعقدة قبول معاملة ذات تفويض مكلف دون أن يضطر كل نظير لتكرار نفس العملية المكلفة؟
في EIP-8361، ينفذ المُثبِت منطق التحقق خارج السلسلة وينتج إثبات STARK. تتحقق العقدة من هذا الإثبات، وتراجع الافتراضات مقابل الحالة الحالية، وتقرر إدراج المعاملة في الـmempool.
يجب أن تبقى المعاملة متوافقة مع قواعد تنفيذ Ethereum عند إضافتها إلى كتلة. يدعم الإثبات سياسة القبول ولا يستبدل التنفيذ على مستوى البروتوكول أو التحقق من الصحة في الإجماع.
لماذا يصعب التحقق المعقّد من معاملات Ethereum؟
الحساب التقليدي (EOA) يعتمد على مفتاح خاص وتوقيع ECDSA، وتحتوي المعاملة على nonce، وعنوان الوجهة، والقيمة، وchain ID، وحد الرسوم، وسعر الرسوم أو معلمات EIP-1559.
الفحوصات هنا متوقعة: التحقق من التوقيع، وجود رصيد كافٍ، صحة nonce، ورفض المعاملات غير الصالحة.
أما الحسابات الذكية فتفتح سطح تحقق أوسع، حيث قد تعتمد على:
- عدة مفاتيح عامة
- حدود إنفاق
- مفاتيح جلسات
- عقود مفوضة
- قواعد ممولي الرسوم
- توقيعات ما بعد الكم
- شروط استرداد
- إثباتات معرفة صفرية
- كود تفويض خاص بالتطبيق
قد يوجد هذا المنطق في عقد ذكي منشور أو جديد. إنشاء أو نشر العقد قد يتطلب التحقق من المصنع أو كود التهيئة أو عنوان العقد.
لا يمكن لعقد Ethereum تنفيذ كود تحقق غير محدود لكل معاملة غير مؤكدة دون مخاطرة. قد يرسل المهاجم معاملات احتيالية تستهلك موارد العقدة رغم أنها غير صالحة.
لذلك، إثباتات صحة معاملات EIP-8361 تنقل العمل المكلف إلى المُثبِت وتبقي التحقق ضمن حدود معقولة.
كيف تعمل معاملات EIP-8361 المعتمدة على الإثبات؟
يقترح EIP-8361 مسارين لقبول معاملة إطار EIP-8141:
- القبول بالمحاكاة: حيث تنفذ العقدة بادئة التحقق.
- القبول المعتمد على الإثبات: حيث تتحقق العقدة من إثبات STARK يثبت صحة بادئة التحقق.
المسار الثاني مخصص للحالات التي تتجاوز فيها المحاكاة ميزانية التحقق المسموح بها للعقدة.
-
المعاملة تحدد منطق التحقق الخاص بها
يمكن لمعاملة إطار EIP-8141 تقسيم عملها إلى إطارات متعددة: بعضها للتحقق، أو تحديد الدافع، أو التحضير للتنفيذ. تعمل بادئة التحقق قبل التنفيذ العادي.
قد تستدعي بادئة التحقق عقدًا ذكيًا للمرسل أو عقدًا مفوضًا آخر لفحص التوقيعات، الصلاحيات، الأرصدة، شروط الانتهاء، أو القواعد الأخرى قبل تنفيذ APPROVE.
يختلف EIP-8141 عن المعاملة التقليدية التي تعتمد على توقيع ECDSA واحد. يدعم نموذج التحقق القابل للبرمجة تجريد الحساب الأصلي ولا يعتمد على قائمة تفويض EIP-7702.
-
المُثبِت ينفذ بادئة التحقق
يشغّل المُثبِت بادئة التحقق مقابل مدخلات وافتراضات حالة معلنة. قد يشمل ذلك التحقق من:
- التوقيع والمفتاح العام
- رصيد الحساب
- رصيد ممول الرسوم
- صلاحية خانة التخزين
- chain ID
- nonce
- انتهاء كود التحقق بالموافقة
ينتج المُثبِت إثبات STARK يلتزم بالمعاملة، الاعتماديات، الافتراضات، الدافع، وشروط الصحة.
-
الإثبات يعلن افتراضات الحالة
لا يمكن أن يبقى الإثبات مفيدًا إذا اعتمد على حالة تغيرت. لذلك، يقترح EIP-8361 متجه افتراضات يصف حقائق الحالة المستخدمة.
قد يشترط المساواة أو أن يكون الرصيد أكبر من أو يساوي حدًا أدنى. تربط الافتراضات الإثبات بحالة سابقة دون تضمين حالة Ethereum الكاملة. عند تحديث البيانات، تعيد العقدة التحقق.
هذه الآلية مركزية في التحقق من صحة mempool في EIP-8361: لا تثق العقدة عمياء في إثبات قديم.
-
العقد تتحقق من STARK
تجري العقدة فحوصات أولية منخفضة التكلفة، ثم تتحقق من STARK بمفتاح التحقق، وتراجع الاعتماديات والافتراضات مقابل الحالة الحالية.
أنظمة الإثبات الحديثة تنتج إثباتات أسرع للتحقق من إعادة الحساب الأصلي. إثبات واحد يكفي بدل محاكاة متكررة من عدة نظراء.
إنتاج الإثبات نفسه مكلف، لكنه ينقل العبء بدلًا من إلغائه.
-
المعاملة تدخل الـmempool
عند نجاح فحوصات الإثبات والحالة، تقبل العقدة المعاملة وتنشرها دون إعادة تنفيذ بادئة التحقق.
يبقى الإثبات بيانات تعريفية بين النظراء، ولا يضاف إلى بيانات الاستدعاء أو حالة الحساب أو جذر Merkle للكتلة.
عند تنفيذ المعاملة، تطبق قواعد البروتوكول. إذا أزيلت المعاملة أو أصبح الإثبات قديمًا، يمكن تجاهل البيانات التعريفية.
ماذا يثبت إثبات صحة EIP-8361؟
إثبات صحة EIP-8361 هو دليل تشفيري على أن عملية تحقق معينة تمت بشكل صحيح بموجب الافتراضات المعلنة وبلغت حالة الموافقة المطلوبة.
قد يثبت فحص التوقيع، الرصيد، nonce، الدافع، أو تفويض العقد. لكنه لا يثبت صحة كل انتقال حالة لاحق في EVM.
التمييز مهم:
- EIP-8361 يثبت التحقق المتعلق بالقبول.
- إثبات صحة الـrollup يثبت انتقالات حالة خارج السلسلة.
- إثبات Merkle يثبت الإدراج في بنية بيانات مصدق عليها.
- إثبات المعرفة الصفرية قد يخفي معلومات، لكن الصحة وحدها لا تضمن الخصوصية.
إثبات Merkle يوضح انتماء معاملة لدفعة أو كتلة أو شجرة حالة. في ZK rollups، تثبت إثباتات Merkle وجود الحسابات في الحالة السابقة، وأن الأرصدة المحدثة تنتج الجذر الجديد.
يستخدم EIP-8361 إثبات STARK للكفاءة، لكن هدف المسودة ليس التنفيذ السري. تبقى المعاملة والاعتماديات مرئية للعقد المشاركة.
مقارنة EIP-8361 مع إثباتات صحة ZK-Rollup
تستخدم حلول الطبقة الثانية إثباتات الصحة بشكل أوسع. ينفذ ZK rollup دفعة معاملات خارج السلسلة ويقدم إثباتًا مختصرًا إلى عقد التحقق في Ethereum. يثبت هذا الإثبات صحة الدفعة حسب قواعد الـrollup.
بدلًا من إعادة تنفيذ كل معاملة على Ethereum، يتحقق عقد التحقق من الإثبات والمدخلات العامة. هذا يقلل من استهلاك الموارد على السلسلة ويوزع رسوم الغاز على عدة معاملات. قد تجمع أنظمة الإثبات التكرارية عدة إثباتات في إثبات واحد.
تمنع إثباتات الصحة ZK rollup من إنهاء انتقال حالة غير صالح، وتسمح بسرعة إنهاء من L2 إلى L1 أسرع من أنظمة تتطلب نافذة نزاع.
EIP-8361 مختلف: لا يثبت دفعة حسابات كاملة أو يحدث جذر Merkle في L2 أو يطلق سحبًا. يثبت أن معاملة إطار واحدة تلبي متطلبات القبول.
| البعد |
EIP-8361 |
إثبات صحة ZK-Rollup |
| الغرض الأساسي |
القبول في mempool العام |
التحقق من انتقال الحالة في L2 |
| الحساب المثبت |
بادئة التحقق |
دفعة معاملات أو انتقال حالة |
| موقع التحقق |
عقد Ethereum |
غالبًا عقد التحقق في L1 |
| مخزن على السلسلة |
لا |
الإثبات أو التزام مستمد من الإثبات |
| الفائدة الرئيسية |
تجنب تكرار المحاكاة |
تجنب إعادة تنفيذ معاملات L2 على L1 |
| الخصوصية مضمونة |
لا |
ليس بالضرورة |
| دور في الإجماع |
لا شيء مباشر |
يدعم التسوية في L2 |
إثباتات صحة EIP-8361 مقابل إثباتات الاحتيال
الـrollups المتفائلة تفترض صحة التحديثات ما لم يتم الطعن فيها. تتطلب إثباتات الاحتيال من المراقبين اكتشاف انتقال متنازع عليه وتقديم دليل خلال فترة التحدي. قد يبقى الادعاء غير الصالح مقبولًا مؤقتًا حتى حله.
في أنظمة إثبات الصحة، يُقبل التزام الحالة بعد تأكيد الموثق الدليل التشفيري. غالبًا ما يتيح ذلك سحبًا أسرع.
الفروق الرئيسية تشمل تعقيد المُثبِت، أمان الموثق، توفر البيانات، الإعدادات الموثوقة، افتراضات التحدي، ونضج التنفيذ.
EIP-8361 ليس نموذج أمان rollup. يُتحقق من إثباته قبل القبول في الـmempool، بينما تحمي إثباتات الاحتيال والصحة أنظمة التوسع خارج السلسلة.
مقارنة EIP-8361 مع تفويض الحساب في EIP-7702
يسمح EIP-7702 للحسابات المملوكة خارجيًا بتعيين مؤشر تفويض في الكود، بحيث تنفذ المكالمات كود عقد ذكي معين. قدم نوع معاملة 4 يحتوي على authorization_list.
تتضمن كل مجموعة تفويض chain_id، عنوان العقد المفوض، nonce الحساب، وحقول التوقيع.
يوقع التفويض بالمفتاح الخاص. يمكن أن يحمل التفويض من عدة EOAs. يمكن لكل تفويض تحديث مؤشر التفويض قبل التنفيذ.
يسمح ذلك بتفويض قدرات التنفيذ لعقود ذكية بتفويضات موقعة دون تحويل الحساب بشكل دائم. يدعم الكود المفوض التجميع، رعاية الرسوم، الصلاحيات، أو سلوك الحساب الذكي.
يخلق EIP-7702 اعتبارات أمان مهمة. قد يجعل chain ID بقيمة صفر التفويض صالحًا عبر السلاسل. تؤثر nonces والحقول الموقعة على هجمات إعادة التنفيذ. يمكن للكود المفوض التأثير على tx.origin والمعاملات المعلقة والتخزين وأرصدة الحسابات.
EIP-8361 لا يستبدل authorization_list ولا يمددها. يعالج قبول العقد للمعاملات ذات منطق التحقق المعقّد. الفروق بين إثباتات صحة EIP-8361 ومحاكاة المعاملات تتعلق بالحساب في الـmempool، وليس تفويض كود الـEOA.
مقارنة EIP-8361 مع EIP-7701 لتجريد الحساب الأصلي
تم إنشاء EIP-7701 في 1 مايو 2024 كمقترح لتجريد الحساب الأصلي. قسّم معالجة المعاملات إلى التحقق، التنفيذ، وما بعد العملية، واقترح نوع معاملة جديد EIP-2718.
استخدم التصميم عنوان نقطة الدخول الأصلية 0x7701، أكواد عمليات تعتمد على الدور، تحقق منفصل للمرسل وممول الرسوم، ودفع الرسوم من خلال العقد. لم يتطلب تدفق bundler لـERC-4337 لنوع المعاملة الأصلي.
تم سحب EIP-7701 لاحقًا لصالح EIP-8141. تسرد المواصفة المنشورة سبب السحب مباشرة. الادعاء بأن EIP-7701 يتطلب عقودًا بتنسيق EOF ليس جزءًا من المواصفة النهائية.
يبني EIP-8361 حول نموذج معاملات الإطار في EIP-8141. يدعم بذلك تجريد الحساب على مستوى البروتوكول من خلال تسهيل نشر التحقق القابل للبرمجة المكلف بأمان.
يوفر EIP-2718 غلاف المعاملة المطبوع الذي تستخدمه مقترحات مثل EIP-7701 وEIP-7702 وEIP-8141. يعرّف المعاملة حسب النوع والحمولة، ما يقلل خطر إعادة التوقيع عبر الأنواع.
الأثر العملي على المحافظ والعقد والمطورين
يمكن لمطوري المحافظ استخدام القبول المعتمد على الإثبات عندما يكون تفويض الحساب الذكي مكلفًا جدًا لمحاكاة الـmempool العادية. قد تطلب المحفظة إثباتًا من مُثبِت محلي أو خدمة أو شبكة موزعة قبل إرسال المعاملة.
سيحتاج مطورو العقد إلى تنفيذ نقل الإثبات بين النظراء، مفاتيح تحقق مرقمة، حدود حجم الإثبات، فحوصات الافتراضات والاعتماديات، حدود معدل لكل نظير، إخلاء الإثباتات القديمة، وسلوك محاكاة احتياطي.
يمكن لمطوري العقود الذكية الاحتفاظ بالتحقق الخاص بالتطبيق دون الحاجة لتنفيذ جميع العقد لتكلفته الكاملة. يدعم ذلك توقيعات ما بعد الكم، سياسات متعددة المفاتيح، ممولي رسوم معقدين، أو صلاحيات معتمدة على الإثبات.
سيعتمد أثر EIP-8361 على المحافظ والعقد والمطورين على سرعة الإثبات، وتبني العميل، والتوافقية، والمواصفة النهائية لـEIP-8141.
على سبيل المثال، يمكن للمتداول تقييم رد فعل السوق في Gate تجاه ترقية مستقبلية لـEthereum بمقارنة إعلانات الشبكة مع مخطط سوق ETH/USDT. لا يمكن لسعر السوق أو حجم التداول أو رسوم الغاز تحديد ما إذا كان مقترح EIP قد تم قبوله أو تفعيله تقنيًا.
اعتبارات الأمان والقيود
يقدم EIP-8361 عدة اعتبارات أمنية:
- صحة الإثبات تعتمد على صحة دائرة STARK ومفتاح التحقق. قد يثبت خطأ في الدائرة قواعد تحقق غير دقيقة.
- التحقق من الإثبات يستهلك حسابًا وعرض نطاق. قد يرسل المهاجمون إثباتات مشوهة أو ضخمة، لذا الفحوصات الأولية وحدود الحجم ضرورية.
- قد تصبح الافتراضات قديمة مع تغير الحالة في كتلة جديدة.
- سياسات العقد غير المتسقة قد تؤدي إلى تجزئة نشر المعاملات.
- إنتاج الإثبات قد يسبب مركزية إذا كانت الموارد أو البرمجيات متوفرة لدى عدد محدود فقط.
لا يزيل EIP-8361 تكاليف المعاملات العادية. إذا وصلت المعاملة إلى التنفيذ، يظل المرسل أو الدافع مسؤولًا عن تكلفة الغاز. إثبات الصحة يقلل من التكرار الحسابي خارج السلسلة، لكنه لا يلغي رسوم الغاز.
ما الذي لا يقترحه EIP-8361
لا يقوم EIP-8361 بـ:
- تحديد فترة انتقالية 18 شهرًا
- إزالة حد أدنى لعائد التخزين
- تحديد مكافآت المُدقِّقين
- خصم المكافآت مع اقتراب التخزين من %50
- إنشاء توازن تخزين مدفوع بالسوق
- إدخال قائمة تفويض EIP-7702
- إدخال نقطة دخول أصلية لـEIP-7701
- إنشاء نوع معاملة جديد EIP-2718
- ضمان الخصوصية
- تسوية دفعات ZK-rollup
- استبدال إثباتات الاحتيال
- التنازل عن الحقوق التعاقدية أو الحقوق ذات الصلة للمستخدمين
قد تنص فقرة حقوق النشر على التنازل عن الحقوق بموجب CC0، وهذا يخص وثيقة المقترح فقط، وليس أموال المستخدمين أو حقوق المعاملات أو صلاحيات العقود الذكية.
الخلاصة
يقترح EIP-8361 قبول المعاملات المعتمدة على الإثبات في mempool العام لشبكة Ethereum. ينفذ المُثبِت بادئة تحقق EIP-8141 المعقدة مرة واحدة، وينتج STARK، ويسمح للعقد بالتحقق من النتيجة دون إعادة نفس العمليات المكلفة.
أقوى استخداماته في التفويض القابل للبرمجة الذي يتجاوز حدود التحقق العادية، مثل الحسابات الذكية المتقدمة، وأنظمة التوقيع البديلة، وممولي الرسوم، والعقود المعتمدة على الإثبات. يقلل التصميم من التكرار الحسابي مع إبقاء الافتراضات المتعلقة بالحالة مرئية وقابلة لإعادة الفحص.
لا ينبغي الخلط بين EIP-8361 وتسوية ZK-rollup أو إثباتات الاحتيال أو تفويض الحساب في EIP-7702 أو تصميم EIP-7701 المسحوب. يظل مقترحًا مسودًا يحتاج إلى مزيد من التطوير قبل تطبيقه على Ethereum.
الأسئلة الشائعة
هل ينشئ EIP-8361 نوع معاملة جديد؟
لا. يطبق القبول المعتمد على الإثبات على معاملات إطار EIP-8141. يوفر EIP-2718 إطار المعاملات المطبوع العام، ولا يقدم EIP-8361 غلاف معاملة جديد.
هل إثباتات EIP-8361 هي إثباتات معرفة صفرية؟
تقترح المسودة إثباتات صحة معتمدة على STARK. الصحة لا تعني الخصوصية بالضرورة. يثبت الإثبات تحققًا صحيحًا بموجب الافتراضات بدلًا من إخفاء كل بيانات المعاملة.
هل يمكن لإثبات واحد أن يغطي عدة معاملات؟
يمكن لأنظمة الإثبات تجميع الحسابات أو استخدام إثباتات تكرارية، وقد تضغط الـrollups عدة إثباتات في واحد. يركز EIP-8361 الحالي على قبول معاملة إطار معينة وليس تجميع دفعات المعاملات.
هل يقلل EIP-8361 من رسوم الغاز؟
ليس بشكل مباشر. قد يقلل المقترح من التكرار الحسابي خارج السلسلة، لكن المعاملة المدرجة تدفع الغاز لتنفيذ Ethereum.
ما الفرق بين EIP-8361 وEIP-7702؟
يسمح EIP-7702 للحسابات المملوكة خارجيًا بتفويض تنفيذ الكود عبر تفويضات موقعة. يقترح EIP-8361 طريقة معتمدة على الإثبات لقبول العقد للمعاملات ذات التحقق القابل للبرمجة المكلف.
إخلاء مسؤولية
هذا المحتوى تعليمي ويصف مقترحات تقنية مسودة وليست ترقيات مضمونة لـEthereum. قد تتغير المواصفات وخطط التنفيذ وافتراضات الأمان ودعم الشبكة. التطورات في البروتوكول والبيانات السوقية التاريخية لا تتنبأ بأداء ETH المستقبلي.
