الاستقلالية الحسابات الأصلية + مقاومة التهديدات الكمومية: لماذا لم يصبح EIP-8141 بعد النجم الأول في إيثريوم Hegotá؟

في الأسبوع الماضي، نوقش رسميًا في اجتماع مطوّري الواجهة الأساسية الخاصة بـ Ethereum ما إذا كان ينبغي إدراج EIP-8141 في ترقية Hegotá، ونتيجة غير متوقعة: لم يتم تصنيف هذا الاقتراح—الذي دافع عنه Vitalik شخصيًا—ضمن “ميزات الصفحة الرئيسية/التركيز” الخاصة بـ Hegotá، بل حصل على حالة “Considered for Inclusion” (CFI).

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

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

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

أولاً، ما المشكلة التي يسعى EIP-8141 إلى حلها؟

يتم دفع EIP-8141 من قِبل Vitalik Buterin إلى جانب مساهمين أساسيين مثل timbeiko، والاسم الرسمي له هو Frame Transactions (معاملات الإطارات).

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

وهذا يعني أن Multi-sig، وGas Sponsorship، وKey Rotation، وSocial Recovery، وحتى في المستقبل إمكانية الوصول إلى حلول توقيع مقاومة للهجمات الكمية، لم تعد مجرد قدرات ملحقة من خارج المحفظة، بل صار هناك احتمال أن تصبح “عضوًا أصيلاً” داخل نظام حسابات Ethereum.

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

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

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

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

إذا كنت قد استخدمت imToken أو غيرها من محافظ Web3، فمن المرجح أنك واجهت أيضًا نقاط الألم هذه: على سبيل المثال، يوجد داخل المحفظة كومة من USDC لكنك لا تستطيع إرسال معاملة لأنك لا تملك ETH (لأن Gas لا يمكن دفعه إلا باستخدام ETH)؛ وفقدان عبارة الاسترداد يعني فقدان الأموال نهائيًا دون إمكانية استعادتها؛ وأن عملية من نوع “تفويض + تبادل” تتطلب توقيعًا مرتين وتأكيدًا مرتين، وهكذا.

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

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

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

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

ثانيًا، كيف يعمل EIP-8141؟

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

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

لكل “إطار” ثلاثة أوضاع للتنفيذ:

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

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

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

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

وبذلك، يمكن إدراج دفع Gas والمعاملة الرئيسية ضمن نفس سلسلة التنفيذ الذرية: إما أن ينجح كل شيء، أو يتم التراجع عن كل شيء بالكامل (rollback).

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

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

• تجريد دفع الغاز: وجود عملات مستقرة داخل المحفظة لا يعني بعد ذلك بالضرورة أنك تحتاج إلى تحضير كمية إضافية من ETH حتى تتمكن من القيام بالعملية؛ مستقبلاً، سيصبح دفع Gas عبر DApp أو Paymaster أو جهات رعاية أخرى أكثر أصالة؛
• دمج العمليات متعددة الخطوات: مثل العمليات الحالية التي تتطلب توقيعات متعددة بشكل متكرر، مثل “تفويض + Swap” و“تفويض + إيداع/تخزين (staking)”، لديها فرصة للتعبئة في عملية واحدة أكثر اكتمالاً؛
• فتح قواعد أمان الحساب: Multi-sig، وSocial Recovery، والحدود اليومية، وTime Locks، وKey Rotation؛ لم تعد مجرد ميزات متقدمة إضافية يقدمها منتج محفظة بعينه، بل يمكن أن تتاح إمكانية بنائها على منطق حساب أكثر أصالة؛
• لم يعد مخطط التوقيع محصورًا بالضرورة في مسار ECDSA واحد فقط: وهذا يمنح الحساب—في المستقبل—إمكانية الانتقال إلى أنظمة تشفير مختلفة، بما في ذلك أنظمة توقيع مقاومة للهجمات الكمية، ولأول مرة يمنحه “إمكانية” ذات معنى على مستوى البروتوكول؛

ثالثًا، لماذا لم يصبح نجماً في Hegotá؟

هناك نقطة يسهل تجاهلها، لكنها بالغة الأهمية لمستخدمي المحافظ: حتى لو تم إرساء EIP-8141 في النهاية، فلن يؤدي ذلك إلى إلغاء نظام الحسابات الحالي ككل.

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

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

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

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

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

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

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

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

ليس هو الخيار الوحيد، لكنه بالتأكيد واحد من أكثر الخيارات طموحًا، والأقرب إلى سقف تخيل “تجريد حساب أصلي مكتمل” حتى الآن.

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

Ethereum لا ينتظر فقط أن تتفاقم المشكلات وتشتد من مكانها؛ بل إنه يمهد—خطوة خطوة—بشكل جاد—الطريق مسبقًا لنظام الحسابات القادم.