أعلن مطور إيثريوم “ديريك تشيانغ” في 7 سبتمبر أن مؤلفي اقتراح تحسين إيثريوم EIP-8141 توصلوا إلى طريقة لتحويل عدة ميزات للمعاملات إلى استدعاءات برمجية قابلة للتنفيذ، بدلاً من إضافتها بشكل منفصل إلى بنية المعاملة الأساسية في إيثريوم.
وصف تشيانغ، وهو أحد المؤلفين المشاركين للاقتراح والمساهم في مشروع Ethlabs، هذا التطور بأنه “اختراق تصميمي” في منشور ناقش الأعمال الحديثة لمؤلفي الاقتراح. يعتمد هذا النهج على معالجة انتهاء صلاحية المعاملات، والتوقيعات المجمعة، وجذور Merkle لخصوصية البول، والتحقق بعد تنفيذ المعاملة كاستدعاءات تُسمى “الإطارات” (Frames).
ما هي معاملة الإطار في إيثريوم؟
تُعرِّف المواصفات الرسمية المسودة معاملة الإطار (Frame Transaction) بأنها سلسلة من استدعاءات العقود الذكية. يمكن للإطارات المختلفة التحقق من صحة معاملة، أو الموافقة على دفع رسوم الغاز، أو تنفيذ عمليات المستخدم. يوفر الاقتراح حالياً ثلاثة أوضاع رئيسية هي: الوضع الافتراضي (DEFAULT)، ووضع التحقق (VERIFY)، ووضع المرسل (SENDER).
يمكن لإطار التحقق (VERIFY) فحص ما إذا كان الشرط المطلوب مستوفياً أم لا. بينما ينفذ إطار المرسل (SENDER) عملية من الحساب الذي تم تحديده كمرسل للمعاملة. يمكن أيضاً تجميع الإطارات في دفعات ذرية، مما يعني أن كل العمليات في الدفعة تنجح معاً أو يتم التراجع عن المجموعة بأكملها عند أي خطأ.
لا يزال الاقتراح يحدد بنية أساسية للمعاملة تحتوي على حقول مثل معرف السلسلة، والرقم التسلسلي، والمرسل، والرسوم، والتوقيعات، وقائمة الإطارات. لكن نقطة تشيانغ الأساسية هي أن المطورين قد يتمكنون من إدخال وظائف إضافية من خلال أهداف وأنماط استدعاء جديدة للإطارات، دون الحاجة إلى إنشاء تنسيق بنية جديد لكل ميزة جديدة.
بنية ثابتة تقلل عبء التنسيق
تغيير بنية معاملة إيثريوم لا يؤثر فقط على عملاء التنفيذ، بل يمتد ليشمل المحافظ، وشبكات الطبقة الثانية، ومتصفحات الكتل، وأجهزة التوقيع، والمكتبات البرمجية، ومزودي البنية التحتية، إذ يجب على جميع هذه الأطراف فهم التنسيق الجديد بالكامل.
أشار تشيانغ إلى أن ترقيات إيثريوم تحدث تقريباً كل تسعة أشهر، مما يجعل التغييرات المتكررة في بنية المعاملات بطيئة ومكلفة من حيث التنسيق. يمكن لتنسيق إطارات عام وشامل أن يعمل كواجهة ثابتة بينما توفر العقود الذكية أو المكونات البروتوكولية المحددة طرق تحقق جديدة ومبتكرة.
هذا لا يعني أن الوظائف المستقبلية لن تتطلب أبداً ترقية للشبكة، فاقتراح EIP-8141 نفسه يغير قواعد إجماع إيثريوم ويتطلب تنفيذاً على مستوى العملاء. كما أن إضافة أكواد تشغيل جديدة (Opcodes) أو عقود مسبقة الترجمة (Precompiles) أو قواعد غاز جديدة قد تتطلب شوكات صلبة (Hard Forks). لكن الفائدة المقترحة هي أن المطورين لن يحتاجوا بالضرورة إلى إعادة تصميم حاوية المعاملة في كل مرة يرغبون بإضافة ميزة جديدة.
تتضمن مواصفات EIP-8141 تجريد الحسابات الأصلي (Native Account Abstraction) ضمن أهدافه الرئيسية. يمكن أن يدعم الاقتراح تدوير المفاتيح، وأنظمة التوقيع البديلة، ودفع رسوم الغاز برعاية طرف ثالث، وتجميع المعاملات. كما يهدف إلى تقليل اعتماد حسابات إيثريوم على نظام التوقيع secp256k1 المستخدم حالياً في الحسابات التقليدية المملوكة خارجياً (EOAs).
- يدعم الاقتراح تدوير المفاتيح وأنظمة التوقيع المتعددة
- يمكن للاقتراح تسهيل دفع رسوم الغاز من قبل جهات خارجية
- يسعى الاقتراح لتقليل الاعتماد على نظام التوقيع التقليدي
التكامل بين EIP-8141 و EIP-8130
اعترف تشيانغ أيضاً بوجود مقايضة في هذا التصميم، فالمعاملات شديدة التجريد قد تصبح صعبة التحليل بالنسبة للمحافظ، ومنظمي المعاملات (Sequencers)، والبنية التحتية الأخرى قبل التنفيذ. على سبيل المثال، قد يرغب منظم معاملات في شبكة الطبقة الثانية بقبول طرق توقيع محددة فقط نظراً لأن تكاليفها الحسابية يمكن التنبؤ بها بدقة.
لذلك، يستكشف المطورون كيف يمكن للإطارات أن تعمل مع اقتراح EIP-8130، وهو اقتراح آخر لتجريد الحسابات بصيغة مسودة. ينشئ EIP-8130 مخزناً للمفاتيح على السلسلة حيث تسجل الحسابات الفاعلين وعقود المصادقة الخاصة بهم. تحدد المعاملات بشكل صريح طريقة المصادقة التي تستخدمها.
يسمح هذا الهيكل للعقدة بتحديد عملية التحقق التي تتطلبها المعاملة قبل تشغيل أي كود محفظة عشوائي. بموجب ملف تعريف الطبقة الثانية المقترح في EIP-8130، يمكن للسلسلة تقييد مسار المعاملات الخاص بها على مجموعة قياسية من المصادقات ذات التكلفة الثابتة، مع إتاحة طرق مصادقة أخرى عبر تنفيذ الأجهزة الافتراضية لإيثريوم (EVM) العادي.
قال تشيانغ إن EIP-8130 يمكن أن يفرض هياكل محددة على إطارات EIP-8141، مما قد يحافظ على مرونة الإطارات بينما يمنح المحافظ والسلاسل عالية الإنتاجية تنسيق معاملات أكثر وضوحاً وقابلية للقراءة. لم يتم الانتهاء من التصميم المشترك بعد، وتبقى كلتا المواصفتين مفتوحتين للتعديل والمراجعة.
يُظهر هذا التوجه الأخير أن المطورين يبحثون الآن عن عناصر متوافقة بين الاقتراحين بدلاً من معاملتهما كخيارين متنافسين وحصريين فقط. التكامل المقترح بين الاقتراحين قد يجمع بين مرونة الإطارات ووضوح المصادقة المنظمة.
رؤية بوتيرين للتحقق المتوازي
وسع فيتاليك بوتيرين، مؤسس إيثريوم، النطاق التقني في منشور منفصل، حيث ميز بين “إجراءات” (Actions) المعاملة و”التبعيات” (Dependencies) الخاصة بها. الإجراء يغير حالة إيثريوم، مثل تحويل عملة ETH. بينما التبعية هي شرط يجب استيفاؤه، مثل التوقيع أو إثبات Merkle أو إثبات المعرفة الصفرية (Zero-Knowledge Proof).
يجادل بوتيرين بأن التبعيات المستقلة يمكن فحصها بالتوازي. الشروط التي لا تصل إلى حالة إيثريوم يمكن معالجتها مرة واحدة بواسطة مجمع الذاكرة (Mempool) بدلاً من تكرارها أثناء التنفيذ. قد يتم تمثيل الفحوصات المتعددة لاحقاً بإثبات STARK تكراري واحد، رغم أن هذا يظل اتجاهاً بحثياً وليس ميزة معتمدة نهائياً.
يمكن أن يساعد هذا التمييز أيضاً العملاء في فصل المعاملات التي يمكن التنبؤ بها عن العمليات التي تتطلب بيئة التنفيذ الديناميكية الكاملة لإيثريوم. قال بوتيرين إن النشاط الأكثر قابلية للتحليل الإحصائي يمكن أن يحصل على تكاليف غاز أقل ويتوسع بشكل أكبر، لكن لم تتم الموافقة على أي جدول رسوم من هذا القبيل حتى الآن.
يوفر نموذج الإطار واجهة محتملة لهذا النهج لأن التحقق والتنفيذ يظهران كاستدعاءات قابلة للتحديد. ستحتفظ إيثريوم بتنفيذ العقود المرن مع السماح للمعاملات الأبسط بتقديم معلومات أكثر عن متطلباتها.
الجدول الزمني لتطبيق EIP-8141
تُدرج وثيقة ترقية Hegotá الرسمية حالياً معاملات الإطارات (Frame Transactions) وآلية FOCIL كأجزاء مجدولة للإدراج في ترقية إيثريوم القادمة. يمثل هذا وضعاً أقوى من مجرد النظر السابق، لكنه لا يجمد التصميم التقني الحالي لاقتراح EIP-8141.
لا يزال EIP-8141 مُعلماً كاقتراح أساسي في مرحلة المسودة. يمكن لمؤلفيه مراجعة أوضاع الإطارات، ومعالجة التوقيعات، ومحاسبة الغاز، والعلاقة مع EIP-8130 مع استمرار أعمال التنفيذ. تترك وثيقة Hegotá أيضاً حقول تفعيل شبكات Sepolia وHoodi والشبكة الرئيسية فارغة في الوقت الحالي.
تشمل الخطوات القابلة للقياس التالية تحديث المواصفات، وتنفيذ العملاء، وشبكات التطوير، واختبارات قابلية التشغيل البيني مع المحافظ وأنظمة الطبقة الثانية. يجب على المطورين أيضاً فحص مخاطر رفض الخدمة (DoS) في مجمع الذاكرة لأن التحقق البرمجي قد يجعل رفض المعاملات غير الصالحة أكثر تكلفة حسابياً.
سيحدد الاختبار ما إذا كان الجمع المقترح بين الإطارات المرنة والمصادقات المنظمة يمكن أن يلبي احتياجات الطبقة الأساسية لإيثريوم وسلاسل EVM الأسرع. حتى صدور معايير التفعيل، يبقى EIP-8141 جزءاً مجدولاً لكنه غير مكتمل من ترقية Hegotá.
الأسئلة الشائعة
ما هو اقتراح EIP-8141 في إيثريوم؟
EIP-8141 هو اقتراح تحسين إيثريوم يقدم نموذج “معاملة الإطار” الذي يحول ميزات المعاملات مثل انتهاء الصلاحية والتوقيعات المجمعة إلى استدعاءات برمجية قابلة للتنفيذ. هذا يسمح بإضافة وظائف جديدة دون الحاجة لتغيير بنية المعاملة الأساسية في كل مرة، ويدعم الاقتراح تجريد الحسابات وتحسين مرونة النظام.
ما الفرق بين EIP-8141 و EIP-8130؟
EIP-8141 يركز على تقديم إطارات مرنة للمعاملات يمكنها التعامل مع ميزات متعددة، بينما EIP-8130 ينشئ مخزناً موحداً للمفاتيح على السلسلة وطريقة منظمة لتحديد هوية المصادقة. بدلاً من التنافس، يستكشف المطورون الآن دمج الاثنين للجمع بين مرونة الإطارات ووضوح المصادقات المنظمة، مما يسهل التحليل قبل تنفيذ المعاملات.
متى سيتم تطبيق EIP-8141 على شبكة إيثريوم الرئيسية؟
تم إدراج EIP-8141 كجزء مجدول من ترقية Hegotá القادمة، لكن التاريخ النهائي للتفعيل على شبكات الاختبار (Sepolia وHoodi) والشبكة الرئيسية لم يُحدد بعد. لا تزال المواصفات في مرحلة المسودة قابلة للتعديل، وتتطلب الخطوات التالية تنفيذ العملاء واختبارات التشغيل البيني قبل تحديد مواعيد التفعيل الرسمية.
