
بالنسبة للمبتدئين الذين يصادفون "معاملات الإطار" في مناقشات Ethereum وHegotá، أبسط تصور هو أن المعاملة تتكون من عدة خطوات منسقة. قد يتحقق إطار من المرسل، وآخر يمنح الموافقة على الدفع، وتنفذ الإطارات التالية إجراء المستخدم الفعلي. تركز هذه المقالة على هذا الهيكل الأساسي دون التوسع في اقتراح EIP-8141 الكامل.
يقدم EIP-8141 نوعًا جديدًا من معاملات الإطار، ويُخصص له حاليًا نوع المعاملة 0x06.
يمكن للمعاملة الواحدة أن تضم حتى 64 إطارًا، ولكل إطار وضع تنفيذ وحدود للرسوم الخاصة به.
تفصل الإطارات بين التحقق من المعاملة، دفع الغاز، وتنفيذ المستخدم.
يتيح كود التشغيل APPROVE الموافقة بشكل منفصل على التنفيذ، الدفع، أو كليهما.
يسمح تجريد الإطار بتجريد الحساب الأصلي، تجميع دفعة ذرية (atomic batch)، رعاية الغاز، والتحقق المبرمج للتوقيع.
توضح المواصفة الرسمية لـ معاملة إطار EIP-8141 معاملة جديدة يمكن تحديد صلاحيتها ودفع الغاز بشكل مجرد. مواصفة EIP-8141
تحتوي حمولة المعاملة على عنوان المرسل، التوقيعات، الرسوم، وقائمة الإطارات. يحدد كل إطار وضعه، العلامات، الهدف، حدود التنفيذ وحالة الرسوم، القيمة، والبيانات. تحدد المواصفة الحالية MAX_FRAMES بـ64 وFRAME_TX_TYPE بـ0x06.
بشكل مبسط، تتبع المعاملة التقليدية نمطًا ثابتًا حيث يوقع المرسل ويدفع. أما تجريد الإطار فيحول هذا النمط إلى سلسلة قابلة للبرمجة.
يحمل كل إطار في EIP-8141 أحد ثلاثة أوضاع تنفيذ:
| الوضع | الغرض الأساسي |
|---|---|
| VERIFY | يحدد الإطار كتحقق للمعاملة |
| SENDER | ينفذ باستخدام المرسل كمنادي للمعاملة |
| DEFAULT | ينفذ مستخدمًا هوية ENTRY_POINT (نقطة الدخول) المعرفة في البروتوكول |
يحدد وضع التنفيذ سياق الإطار. يمكن لإطار VERIFY تشغيل منطق التحقق قبل تنفيذ إطارات المرسل، بينما يسمح وضع SENDER للعمليات المصرح بها بأن تكون نداءات من عنوان المرسل. ويوفر وضع DEFAULT هوية تنفيذ محايدة على مستوى البروتوكول.
تعد هذه البنية المعيارية جوهرية في تجريد الحساب الأصلي لأن التحقق لم يعد مقيدًا بمفتاح سري أو نظام توقيع واحد.
يضيف EIP-8141 كود التشغيل APPROVE الذي يحدث سياق الموافقة للمعاملة.
يمكن لمنطق التحقق استخدام نطاقات موافقة مختلفة:
APPROVE_PAYMENT يوافق على دفع الغاز.
APPROVE_EXECUTION يوافق على تنفيذ إطارات المرسل التالية.
APPROVE_EXECUTION_AND_PAYMENT يوافق على كليهما.
يجب أن يكون الهدف المحدد للإطار هو منادي APPROVE، ما يحد من من يمنح الموافقة. بعد الموافقة على التنفيذ، يمكن لإطارات SENDER التالية أن تُنفذ باستخدام سياق المرسل.
يتيح هذا الفصل لعقد راعي أو paymaster (جهة دفع الغاز) الموافقة على الحد الأقصى لتكلفة الغاز بينما يوافق منطق التحقق الخاص بالمستخدم على التنفيذ بشكل منفصل.
تتضمن المواصفة الحالية سبع تعليمات جديدة تخص الإطار:
| كود التشغيل | الوظيفة |
|---|---|
| APPROVE | يوافق على الدفع و/أو التنفيذ |
| TXPARAM | يقرأ معلمات المعاملة |
| FRAMEDATALOAD | يحمل البيانات من إطار محدد |
| FRAMEDATACOPY | ينسخ مدخلات الإطار إلى الذاكرة |
| FRAMEPARAM | يقرأ معلمات الإطار وحالة التنفيذ |
| SIGPARAM | يقرأ بيانات التوقيع الوصفية |
| SIGDATACOPY | ينسخ بيانات التوقيع المدعومة |
مثلًا، يمكن لـ TXPARAM عرض معلومات خاصة بالمعاملة مثل المرسل، الحد الأقصى للرسوم، تجزئة التوقيع، وعدد الإطارات. أما FRAMEPARAM فتعرض تفاصيل على مستوى الإطار مثل وضع التنفيذ، العلامات، الغاز المستخدم، وما إذا كان علم الدفعة الذرية مفعّلًا. تبلغ تكلفة عمليات البحث الأساسية للغاز 2.
تفصل معاملات الإطار دفع الغاز عن المرسل. يمكن لإطار VERIFY الموافقة على حساب أو عقد راعي مختلف للدفع، مما يوفر آلية أصلية لرعاية الغاز.
على سبيل المثال، يمكن أن يحتفظ المستخدم بعملات مستقرة بينما يعمل حساب آخر كدافع للغاز. قد تنقل معاملة الإطار رموز ERC-20 لتعويض الراعي بينما يتم تسوية تكلفة المعاملة الأساسية عبر الدافع المعين.
يحصل كل إطار على حدود تنفيذ وحدود رسوم للحالة. يقلل الغاز غير المستخدم من المبلغ النهائي الذي يُخصم من الدافع بدلًا من أن يصبح سعة تنفيذ إضافية للإطارات المتبقية.
ترتبط دفعة ذرية (atomic batch) بعدة إطارات تنفيذ بحيث تنجح أو تفشل معًا.
مثال، الموافقة على ERC-20 تليها عملية مبادلة. وعند تفعيل علم دفعة ذرية (atomic batch)، إذا تراجعت عملية المبادلة، تتراجع الموافقة السابقة أيضًا. وهذا يمنع بقاء صلاحية الرموز غير المرغوبة بعد فشل المعاملة المقصودة.
وهذا سبب عملي يجعل معاملات الإطار تبسط التفاعلات متعددة الخطوات مع العقود الذكية.
يستخدم إطار ERC-4337 لتجريد الحساب في Ethereum حسابات ذكية (smart accounts)، مُجمع (bundler)، عمليات مستخدم (UserOperations)، وpaymaster لتوفير سلوك قابل للبرمجة للمحفظة. توفر معاملات الإطار مزيدًا من هذه المرونة مباشرة في طبقة البروتوكول.
يدعم التحقق القابل للبرمجة في EIP-8141 أنظمة توقيع مختلفة، تدوير المفاتيح، تجميع التواقيع في المستقبل، ومسار نحو الجاهزية لما بعد الكم. تتيح الشيفرة الافتراضية للحسابات غير المنشورة المشاركة، بينما يدعم إطار النشر نشر الحساب قبل التحقق.
تقدم هذه المرونة بعض المقايضات. قد ينتج منطق التحقق التعسفي مخاطر رفض الخدمة أو الإبطال الجماعي في تجمع المعاملات، لذا تفرض قواعد تجمع المعاملات العامة قيودًا على بادئة التحقق وكيفية التعامل مع معاملات الإطار المعلقة.
معاملة إطار Ethereum هي معاملة واحدة مكونة من عدة إطارات قابلة للبرمجة. بدلاً من تقييد التحقق ودفع الغاز والتنفيذ في دور المعاملة ذاته، يسمح EIP-8141 للإطارات المتعددة بأداء كل مهمة.
هذا هو التمييز الأساسي: EIP-8141 هو اقتراح البروتوكول؛ معاملات الإطار هي صيغة المعاملة الجديدة التي يقدمها. هيكلهم المعياري هو ما يتيح رعاية الغاز، تجميع دفعة ذرية (atomic batch)، التحقق القابل للبرمجة، التواقيع المرنة، وتجريد الحساب الأصلي دون تحويل كل ميزة إلى نظام معاملات منفصل.
نعم. يُستخدم وضع VERIFY للتحقق وصُمم ليعمل دون إجراء تغييرات دائمة على الحالة. يساعد ذلك العقد على محاكاة التحقق بأمان أكبر قبل اتخاذ قرار بشأن دخول أو بقاء معاملة الإطار المعلقة في تجمع المعاملات العامة.
ليس دائمًا. في EIP-8141، يمكن اختيار الدافع عبر منطق تحقق قابل للبرمجة، لذا لا يمكن تحديد الدافع دائمًا من بيانات المعاملة فقط. تُحدد الموافقة على الدفع أثناء التحقق من المعاملة.
يتم تأسيس موافقة المرسل أولًا، وبعدها تُؤكد الموافقة على الدفع للحساب أو paymaster (جهة دفع الغاز) الذي يغطي تكلفة الغاز. يسمح هذا الفصل لطرف بالموافقة على التنفيذ بينما يوافق حساب آخر على دفع الغاز.
لا. يمنع حساب الغاز في معاملة الإطار إطارًا من الاقتراض من ميزانية الغاز غير المستخدمة لإطار آخر. كل إطار له حدود تنفيذ وحالة رسوم محددة، ويشمل حد الغاز الإجمالي للمعاملة الغاز الذاتي وحدود التنفيذ الخاصة بالإطارات المعنية.
يتبع paymaster القياسي تنفيذًا معرفًا من قبل البروتوكول ويجب أن تتطابق شيفرة عقده مع المواصفة المتوقعة. يمكن للعقد تتبع التزامات الغاز المعلقة بشكل أكثر توقعًا. أما paymaster غير القياسي فلديه قيود تجمع معاملات أكثر صرامة، منها حد معاملة واحدة معلقة لتقليل مخاطر الإبطال الجماعي ورفض الخدمة.
هذا المحتوى لأغراض تعليمية فقط. لا يزال EIP-8141 جزءًا من خارطة طريق بروتوكول Ethereum المتطورة، وقد تتغير تفاصيل المواصفة قبل تفعيلها على الشبكة الرئيسية (mainnet).











