كشف مطورو إيثريوم مؤخرًا عن تقدم جديد في تصميم EIP-8141. يحاول هذا المقترح كتابة بعض وظائف المعاملات كاستدعاءات عقد قابلة للبرمجة، تُعرف بـ "frames"، بدلاً من تعديل تنسيق تغليف معاملات إيثريوم كلما أضيفت ميزة جديدة.
تم تغيير وظيفة التداول لتصبح قابلة للاستدعاء البرمجي
تشمل هذه الفكرة الوظائف التالية: انتهاء الصفقة، التوقيع المجمع، جذور Merkle المرتبطة بمجموعات الخصوصية، وفحص الادعاءات بعد تنفيذ الصفقة. يرى المطورون أنه إذا كانت هذه الواجهات كافية من حيث العمومية، فعندما يُدخل إيثريوم طرق تحقق جديدة في المستقبل، لن تحتاج المحافظ والمتصفحات وأجهزة التوقيع وطبقة 2 إلى التكيف مع غلاف صفقة جديد في كل مرة.
يُعرّف مشروع EIP-8141 معاملة Frame كسلسلة من استدعاءات العقد. يمكن لـ frames مختلفة مسؤولية التحقق من شروط المعاملة، أو الموافقة على دفع رسوم الغاز، أو تنفيذ إجراءات المستخدم.
يُدرج المسودة الحالية ثلاثة أنماط: DEFAULT و VERIFY و SENDER. حيث يُستخدم إطار VERIFY للتحقق من استيفاء شرط معين، بينما يمثل إطار SENDER تنفيذ عملية باسم مرسل المعاملة. كما يمكن تجميع عدة إطارات في معالجة ذرية، بحيث تكون جميعها ناجحة أو تُلغي جميعها كوحدة واحدة.
تقليل تكاليف تنسيق المحافظ والبنية التحتية
الرأي الأساسي للمطور ديريك تشيانغ هو أن الميزات الجديدة المستقبلية لا تحتاج بالضرورة إلى تصميم حزمة تداول جديدة بالكامل؛ بل يمكن توسيع القدرات مع الحفاظ على استقرار البنية الأساسية من خلال التعبير عن طريق أهداف إطار عمل جديدة وأنماط استدعاء جديدة.
كل تعديل على حزمة المعاملات في إيثريوم لا يؤثر فقط على عميل التنفيذ، بل يجب على المحافظ وطبقات الطبقة الثانية ومتصفحات الكتل وأجهزة التوقيع والمكتبات البرمجية وخدمات البنية التحتية المختلفة فهم الدعم والدعم الجديد.
أشار تشيانغ إلى أن ترقية إيثريوم تحدث تقريبًا كل تسعة أشهر، وإذا تم تغيير حزم التداول بشكل متكرر، فستكون تكاليف التنسيق مرتفعة. على العكس، إذا أصبح تنسيق frame واجهة أكثر استقرارًا، فيمكن تكليف طرق التحقق الجديدة بشكل أكبر للعقود أو مكونات البروتوكول المحددة.
ومع ذلك، فهذا لا يعني أن جميع الوظائف المستقبلية ستتمكن من تجاوز التحديثات الشبكية. لا يزال EIP-8141 سيُعدّل قواعد إجماع الإيثيريوم، ويتطلب تنفيذًا من العميل. إذا تضمنت تغييرات في أكواد تشغيل جديدة أو عقود مُعدّة مسبقًا أو قواعد الغاز، فقد لا يزال من الضروري إجراء تقسيم صلب.
EIP-8130 واتجاه التحقق المتوازي
يُقر المطورون أيضًا أن زيادة مستوى تجريد المعاملات تجعل من الصعب على المحافظ والمرتبين تحليل المعاملات قبل التنفيذ. ولذلك، تقوم الفريق بدراسة كيفية تكامل EIP-8141 مع مسودة تجريد الحساب الأخرى EIP-8130.
EIP-8130 تقترح بنية keystore على السلسلة تسمح بتسجيل الحسابات مسبقًا للمشاركين وعقود التحقق، وتحديد طريقة التحقق صراحةً في المعاملات. وبهذا، يمكن للعقد أن يحدد نوع عملية التحقق المطلوبة قبل تشغيل أي كود محفظة. بالنسبة لـ Layer 2، يساعد هذا في تقييد مجموعة طرق التحقق التي تكون تكلفتها أكثر قابلية للتنبؤ.
كما شرح فيتاليك بوتيرين الاتجاه ذي الصلة في منشور آخر. قسم المعاملات إلى جزأين: "الإجراءات" و"الشروط المعتمدة". تتحمل الإجراءات مسؤولية تغيير حالة إيثريوم، بينما تشمل الشروط المعتمدة شروطًا مسبقة مثل التوقيعات وإثباتات ميركل أو إثباتات الصفرية المعرفة. إذا كانت هذه الاعتمادات مستقلة عن بعضها البعض، فقد يمكن التحقق منها بالتوازي في المستقبل، مما يقلل من تكلفة معالجة بعض المعاملات.
تم إضافته إلى Hegotá، لكن وقت التفعيل غير محدد
تمت إضافة Frame Transactions إلى قائمة الترقيات المخطط لها من قبل EIP الرسمي لـ Hegotá Meta، مما يعني أن حالتها تقدمت مقارنةً بالسابق. لكن EIP-8141 لا يزال مسودة أساسية، ولم تُحسم بعد التفاصيل التقنية.
العمل الذي لا يزال يتعين推进ه يشمل: تحديث المواصفات، وإكمال تنفيذ العميل، وإنشاء شبكة تطوير، وإجراء اختبارات التوافق مع المحافظ وأنظمة الطبقة 2. كما يجب على المطورين تقييم مخاطر هجوم حجب الخدمة على حوض الذخيرة، نظرًا لأن التحقق القابل للبرمجة قد يزيد من تكلفة الحساب لتصفية المعاملات غير الصالحة.
حاليًا، أوقات تفعيل Hegotá على Sepolia وHoodi والشبكة الرئيسية لا تزال فارغة. تم إدراج EIP-8141 في خطة الترقية، لكنه لا يزال يمر بمرحلة تنفيذ واختبار قبل التفعيل النهائي.