EIP-8141: لماذا لا تعتبر ميزة التجريد الحسابي الأصلي ميزة رئيسية في ترقية Hegota الخاصة بإيثريوم

كتابة: imToken

في الأسبوع الماضي، نوقش رسميًا في اجتماع مطوري إيثريوم الأساسي ما إذا كان ينبغي تضمين EIP-8141 في ترقية Hegota، وكانت النتيجة مفاجئة: لم يُصنَّف هذا الاقتراح الذي دعمه فيتاليك شخصيًا كـ"ميزة رئيسية" في Hegota، بل حصل على حالة "النظر في التضمين" (CFI).

وفي هذا الأسبوع، أصدر فريق Google Quantum AI ورقة بيضاء جديدة، أفادت فيها أنه في ظل افتراضات الأجهزة المحددة، انخفض تقدير عدد الكيوبتات الفيزيائية المطلوبة لكسر ECDLP-256 بنسبة 20 مرة مقارنة بالتقديرات السابقة. وعلى الرغم من أن هذا لا يعني أن الهجمات الكمية وشيكة، إلا أنه يذكّرنا بشكل حقيقي بأنه إذا لم تتمكن أنظمة الحسابات من تغيير منطق المصادقة بمرن في المستقبل، فقد تتحول العديد من المناقشات الحالية حول تجربة المحافظ إلى مشكلات أمنية.

رغم النظر إلى الواقع العملي لدفع البروتوكول، فإن EIP-8141 لا يزال ثقيلًا حاليًا، خاصة في تنفيذ العميل وأمان حوض المعاملات وتعقيد التحقق، ولم يتشكل بعد توافق كافٍ.

لكن في هذه النقطة الزمنية الحالية، يبدو أن هناك المزيد والمزيد من الجوانب في EIP-8141 التي تستحق المناقشة والمراجعة الجادة.

EIP-8141، الذي يُدفع من قبل فيتاليك بوتيرين و timbeiko وآخرين من المساهمين الأساسيين، يُعرف رسميًا باسم Frame Transactions.

بصيغة أبسط، الهدف ليس إضافة ميزة واحدة للمحفظة، بل محاولة التحرر من قيود مسار التوقيع الوحيد ECDSA على مستوى البروتوكول، بحيث يمكن لأي حساب أن يمتلك منطقًا أكثر مرونة للتحقق والتنفيذ.

هذا يعني أيضًا أن التوقيع المتعدد، رعاية الغاز، تبديل المفاتيح، الاسترداد الاجتماعي، وحتى التكامل المستقبلي مع حلول التوقيع المقاومة للحوسبة الكمية، لم تعد مجرد ميزات خارجية مُضافَة على المحافظ، بل لديها فرصة أن تصبح "أعضاء أصليين" في نظام حسابات إيثريوم.

إذا نظرنا فقط إلى السطح، فإن EIP-8141 يناقش مجموعة من القدرات التي تبدو محددة جدًا: دفع رسوم الغاز باستخدام العملات المستقرة، ودمج العمليات المتعددة في معاملة واحدة، ودعم طرق توقيع أكثر مرونة، وحتى تخصيص مساحة للتوقيعات المقاومة للحوسبة الكمية في المستقبل. يمكن القول إن العديد من التحسينات التي تم إجراؤها على تجربة المحافظ على مدار السنوات، بدءًا من ERC-4337 وحتى EIP-7702، تهدف جوهريًا إلى جعل الحسابات لا تقتصر على مفتاح خاص واحد، بل تصبح بوابة يمكن تخصيص قواعدها.

المشكلة هي أن هذه التحسينات جعلت المحافظ تشبه بشكل متزايد الحسابات الذكية، لكنها لم تلمس أبداً نموذج الحساب الافتراضي الأساسي لإيثريوم.

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

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

إذا كنت قد استخدمت imToken أو محفظة Web3 أخرى، فمن المحتمل أنك واجهت هذه النقاط المؤرقة، مثل وجود كمية كبيرة من USDC في المحفظة ولكن لا يمكنك إرسال معاملة لأن الغاز يُدفع فقط بـ ETH؛ فقدان كلمة الاسترداد يعني فقدان الأموال بشكل دائم ولا يمكن استعادتها؛ وتنفيذ عملية "الموافقة + التبديل" تتطلب توقيعًا وتأكيدًا مرتين، وهكذا دواليك.

هذه المشكلات ليست نتيجة أن منتج المحافظ "غير جيد"، بل هي نتيجة تصميم نموذج حساب إيثريوم نفسه.

من هذا المنظور، فقد أصبح التطور خلال السنتين الماضيتين واضحًا جدًا: فقد أطلق ERC-4337 مفهوم تجريد الحسابات على طبقة التطبيق دون تعديل البروتوكول؛ ثم أثبتت EIP-7702 لاحقًا أن الحسابات الخارجية (EOA) ليست غير قابلة للتوسيع تمامًا، بل يمكنها على الأقل اكتساب مؤقت بعض القدرات المشابهة للحسابات الذكية.

بمعنى آخر، لم تكن إيثريوم ترغب في تجنب تجريد الحسابات، بل كانت تسعى باستمرار إلى التقدم تدريجيًا وبطريقة أكثر اعتدالًا وتحفظًا نحو تحقيق ذلك. ويعني ظهور EIP-8141 أن هذه المسار وصل إلى نقطة جديدة، حيث لم تعد راضية عن إضافة طبقة إضافية من قدرات الحسابات الذكية حول النظام الحالي، بل تحاول دمج تجريد الحسابات مباشرة في نموذج المعاملات نفسه، بحيث يصبح للحسابات من المستوى البروتوكولي فورًا منطق تحقق وتنفيذ قابل للبرمجة.

وهذا هو السبب في أن EIP-8141 يشهد تجددًا اليوم. من ناحية، أصبحت تجربة المحافظ العليا أقرب بكثير إلى تجريد الحسابات الأصلي، ويجب على طبقة البروتوكول أن تلحق بالركب في وقت ما؛ ومن ناحية أخرى، فإن الضغط طويل الأمد الناتج عن الحوسبة الكمية يحول "إمكانية تغيير طريقة التوقيع بسهولة للحسابات" من مسألة تقنية بعيدة إلى مشكلة واقعية تتطلب تفكيرًا جادًا.

في النهاية، يُدخل EIP-8141 نوعًا جديدًا من المعاملات — معاملة الإطار (Frame Transaction)، برقم النوع 0x06.

إذا كان المنطق الأساسي للتعاملات التقليدية على إيثريوم هو أن كل معاملة تقابل استدعاءً واحدًا، فإن هدف EIP-8141 هو تقسيم المعاملة الواحدة إلى مجموعة من "الإطارات" التي يمكن تنفيذها وفق ترتيب محدد، بحيث يتم فصل عمليات التحقق والدفع والتنفيذ التي كانت مدمجة معًا سابقًا.

كل "إطار" لديه ثلاثة أنماط تنفيذ:

• VERIFY (التحقق من الإطار): مسؤول عن التحقق من صحة المعاملة، حيث يُشغّل منطق التحقق المخصص للحساب، وإذا نجح، فإنه يستدعي رمز التشغيل APPROVE الجديد لمنح الصلاحية للتنفيذ وتحديد الحد الأقصى للغاز.
• المرسل (إرسال الإطار): ينفذ العمليات الفعلية، مثل التحويل أو استدعاء العقد الذكي، إلخ. عنوان المُستدعي هو نفسه مرسل المعاملة.
• DEFAULT (إطار الدخول): استخدام عنوان الدخول للنظام كمتصل، لاستخدامات مثل نشر العقد والتحقق من Paymaster؛

معنى هذه الآلية ليس جعل التداول أكثر تعقيدًا، بل أول مرة تُفصل فيها "التحقق، الدفع، التنفيذ" كثلاث مهام من إجراءات الحساب، وتُسند إلى الجدولة الأصلية للبروتوكول.

في الماضي، كان التحقق من المعاملات، ودفع رسوم الغاز، وتنفيذ العمليات الفعلية، كلها مرتبطًا بعملية حساب واحدة، لكن في تصميم EIP-8141، يمكن تقسيم هذه المهام إلى إطارات منفصلة، يتم تنفيذها من قبل البروتوكول بالترتيب المحدد، ولهذا السبب، لم يعد الحساب مُقيّدًا بالاعتماد على مفتاح خاص واحد لـ"التوقيع الشامل"، بل بدأ يتخذ شكلًا أكثر قربًا من كونه كيانًا قابلًا للبرمجة.

على سبيل المثال، افترض أنك ترغب في استخدام USDC لدفع رسوم الغاز لإتمام عملية تبديل، في إطار EIP-8141، يمكن نظريًا تنظيم هذه العملية كسلسلة كاملة من الخطوات: أولاً، التحقق من التوقيع وصلاحيات التنفيذ من قبل الحساب، ثم التحقق من طرف الدفع أو Paymaster من شروط استعدادهم لتحمل التكاليف، تليها إتمام دفع الرسوم بالعملة المقابلة، وأخيرًا تنفيذ عملية التبديل الفعلية.

بهذه الطريقة، يمكن دمج دفع Gas مع المعاملة الرئيسية في عملية ذرية واحدة، إما أن تنجح جميعها أو تُلغى جميعها.

أبسط تغيير بالنسبة للمستخدمين هو أن العديد من العمليات التي كانت تتطلب سابقًا تقسيمها إلى خطوتين أو ثلاث خطوات، مع وجود مخاطر فشل في الوسط، ستصبح في المستقبل أكثر شبهاً بحركة واحدة متكاملة، وبالتالي فإن هذا التمازج هو أحد العوامل الأساسية التي تهدف إليها EIP-8141 لحل مشكلة تجزئة تجربة المستخدم.

ماذا يعني ذلك لمستخدمي المحافظ؟ من النتائج، فإن أوضح التغييرات على الأقل لها أربع طبقات:

• تم تجريد دفع رسوم الغاز: امتلاك عملة مستقرة في المحفظة لا يعني بعد الآن أنك بحاجة إلى التحضير لكمية إضافية من ETH لإجراء العمليات؛ في المستقبل، سيصبح دفع رسوم الغاز من قبل DApp أو Paymaster أو أطراف راعية أخرى أكثر طبيعية؛
• تم دمج العمليات متعددة الخطوات: مثل "التصديق + التبديل" و"التصديق + الرهن"، والتي تتطلب غالبًا توقيعات متعددة، وتصبح الآن فرصة لدمجها في عملية واحدة أكثر شمولاً؛
• تم تفعيل قواعد أمان الحساب: التوقيع المتعدد، الاسترداد الاجتماعي، الحدود اليومية، قفل الوقت، واستبدال المفاتيح، لم تعد هذه ميزات متقدمة تُقدم كإضافة من قبل منتجات المحافظ فحسب، بل بدأت تُبنى على منطق حسابات أكثر أصالة؛
• لم تعد خطة التوقيع ملزمة بالمسار الوحيد لـ ECDSA: مما يمنح الحسابات لأول مرة إمكانية انتقال على مستوى البروتوكول إلى أنظمة تشفير مختلفة، بما في ذلك مخططات التوقيع ما بعد الكمية؛

نقطة يُهملها الكثيرون ولكنها حاسمة لمستخدمي المحافظ: حتى لو تم تنفيذ EIP-8141 في النهاية، لن يتم استبدال نظام الحسابات الحالي بالكامل.

حتى إذا كنت تستخدم حاليًا محفظة Web3 موجودة مثل imToken، فلا حاجة للنقل، لأنها متوافقة للخلف، ويمكنك الاستمرار في استخدام عنوان EOA الحالي، ما عليك سوى اختيار "ترقية" منطق المصادقة للحساب في الوقت المناسب.

لكن من الناحية المعاكسة، بالضبط بسبب التغييرات العميقة التي أُجريت عليه، لم يصبح الميزة الرائدة في المناقشة الأخيرة لـ Hegotá. ومع ذلك، وفقًا لعملية مُؤيد EIP لعام 2026، فإن معنى CFI (Considered for Inclusion) ليس رفضه، بل دخوله مرحلة التقييم الجاد، لكنه لم يصل بعد إلى مرحلة اتخاذ القرار النهائي للإطلاق.

بعبارة أخرى، المطورون الأساسيون لا يرفضون اتجاه EIP-8141، بل يعترفون بقيمته في الوقت نفسه ويعتبرونه لا يزال ثقيلًا جدًا حاليًا.

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

ماذا سيحدث بعد ذلك؟ يمكن تقسيمه إلى خطين:

• بما أن EIP-8141 لا تزال في حالة CFI، فهذا يعني أنها لا تزال قيد التقييم المستمر، وسيواصل مؤلفو المقترح تكميل التفاصيل الأساسية المتعلقة بأمان حوض المعاملات وقواعد التحقق وتنفيذ العميل، كما سيعيد اجتماعات ACD لاحقًا مراجعة ما إذا كانت تتمتع بالشروط اللازمة للتقدم أكثر.
• إذا تم ضغط هذه عدم اليقين بشكل مستمر، فسيكون لديها فرصة للدخول إلى مرحلة أكثر جوهرية في الترقيات القادمة؛ وإذا لم تُضغط، فقد تُؤجل بالكامل إلى دورة ترقية أحدث؛

بصراحة، لا يُعد EIP-8141 المقترح الوحيد المتعلق بالتجريد الأصلي للحسابات، ولا يُعد بحد ذاته أي مخطط توقيع بعد كمي جاهز قادر على حل مشكلة الحوسبة الكمية مباشرة، لكن أهميته تكمن في أنه لأول مرة يقدم مخرجاً بمستوى البروتوكول لتحرير الحسابات من المسار الأحادي لـ ECDSA.

من هذا المنظور، لا تكمن القيمة الحقيقية لـ EIP-8141 في كونه الإجابة الصحيحة الوحيدة، بل في أنه وضع لأول مرة سؤال "كيف يجب أن يبدو النهاية النهائية للتجريد الحسابي الأصلي" بشكل كامل على طاولة مناقشات بروتوكول إيثريوم.

إنه ليس الحل الوحيد، لكنه أحد أكثر الحلول طموحًا وقربًا من الحد الأقصى للتخيلات المتعلقة بـ "AA الأصلي الكامل" حاليًا.

سواء أكان EIP-8141 سيتمكن في النهاية من اللحاق بـ Hegotá أم لا، فإن هذا النقاش نفسه على الأقل يوضح شيئًا واحدًا:

لم ينتظر الإيثيريوم تفاقم المشكلات، بل يبني بشكل تدريجي طريقًا مسبقًا لنظام الحسابات من الجيل التالي.