مؤسسة إيثريوم تحدد موعدًا نهائيًا لعام 2029 للترقيات المقاومة للحوسبة الكمية

الكاتب الأصلي: KarenZ، Foresight News

لم تطرق الحواسيب الكمية بعد باب البلوكشين، لكن مؤسسة إيثريوم سبقت وحددت تاريخًا في التقويم: ديسمبر 2029.

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

يتم تخطيط Hegotá، والتي رغم أنها لن تحول إيثريوم مباشرة إلى سلسلة بلوك مقاومة تمامًا للحوسبة الكمية، إلا أنها ستقرر ما إذا كانت الخطط المستقبلية يمكن تنفيذها في الموعد المحدد.

يُستخدم مصطلح "Q-day" عادةً للإشارة إلى نقطة زمنية افتراضية: ظهور حاسوب كمومي قادر على تنفيذ هجمات واقعية، مما يعرض أنظمة التشفير المفتاح العام الحالية لتهديد جوهري.

لا يمكن لأحد التنبؤ بدقة بموعد وصوله. كما اعترفت مؤسسة إيثريوم صراحةً بأن معظم التوقعات الموثوقة تشير إلى أن يوم Q سيأتي بعد عام 2030، بل وقد يتأخر كثيرًا، كما أنه قد لا يأتي أبدًا.

تستخدم فريق بروتوكول مؤسسة إيثريوم افتراضات هندسية محافظة: يجب التحضير لطبقة إيثريوم الأولى على أساس أن يوم Q قد يحدث في أقرب وقت في عام 2030.

لذلك، طرح فريق البروتوكول هدفًا – السعي لتحقيق قدرة كاملة ضد الحوسبة الكمية في أجزاء التنفيذ، التوافق، والبيانات في الطبقة الأولى من إيثريوم بحلول ديسمبر 2029.

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

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

وفقًا للمسار المرجعي المُعلن حاليًا من فريق بروتوكول مؤسسة إيثريوم، من المخطط إطلاق ترقية شبكة Glamsterdam على الشبكة الرئيسية في ديسمبر 2026، بينما يتم تخصيص القدرة الكاملة المقاومة للحوسبة الكمية للانقسام الصلب الخامس بعد Glamsterdam، المُسمى L*, والذي يستهدف ديسمبر 2029. من Glamsterdam إلى L* هناك فقط ثلاث سنوات، وإذا تم إكمال Hegotá و I* و J* و K* و L* بالتسلسل، فسيكون هناك ما يقارب 7.2 شهرًا فقط بين كل ترقية.

هذا جدول زمني متحمس إلى حد كبير. حاليًا، لم تُعلن مؤسسة إيثريوم عن تواريخ محددة لLaunchات Hegotá و I* و J* و K* على الشبكة الرئيسية. من المؤكد أن فرق العميل تتوقع بدء تنفيذ Hegotá في أواخر الربع الرابع من عام 2026 على أقرب تقدير، مع ضرورة المضي قدمًا في أبحاث ومواصفات واختبارات الإصدارات اللاحقة بالتوازي.

وفقًا للمسار الحالي، فإن الترتيبات الرئيسية لكل مرحلة هي كالتالي:

• Hegotá: تقع في بداية هذا المسار. الموقف الرسمي منها واضح جدًا: Hegotá ليست ترقية مقاومة للحوسبة الكمية، لكنها ستُحدد ما إذا كان يمكن المضي قدمًا في ترقية مقاومة للحوسبة الكمية في مواعيدها.
• I*: نشر سجل المفاتيح العامة المقاومة للحوسبة الكمية لإنشاء أساس بروتوكولي لتسجيل الحسابات واستخدام المفاتيح العامة المقاومة للحوسبة الكمية؛ في الوقت نفسه، يعد فصل توافق الآراء هو الاتجاه الرائد الحالي في هذه النسخة، ومن المتوقع أن تبدأ أعمال التصميم والنقل الواسعة للهيكل الحالة من I*.
• J*: إنشاء طبقة "أدنى ممكنة مقاومة للحوسبة الكمية" تُسمى MV-PQ، وتشمل مكوناتها الأساسية آلية القلب المقاومة للحوسبة الكمية على طبقة التوافق، أخذ عينات leanDA ما بعد الكمية على طبقة البيانات، ومعاملات leanSPHINCS ما بعد الكمية على طبقة التنفيذ.
• K*: وفقًا للترتيب الحالي الأساسي، يتم إدخال إثبات التنفيذ الإجباري. في ذلك الوقت، سيكون اتجاه المُحققين هو التحقق من إثباتات التنفيذ الموجزة، وليس إعادة تنفيذ الكتل الكاملة من قبل كل مُحقق.
• L*: وفقًا للترتيب الحالي للمعيار، أضف رسائل الإثبات المقاومة للحوسبة الكمية (post-quantum attestations) المطلوبة لتحقيق توافق مقاوم بالكامل للحوسبة الكمية، وتحقق الهدف الكامل المقاوم للحوسبة الكمية على طبقات التنفيذ والتوافق والبيانات بحلول ديسمبر 2029.

ومع ذلك، لم يتم تحديد ترتيب مهام K* و L* بعد. يقوم فريق البروتوكول بتقييم خطة تبديل: نقل رسالة إثبات مقاومة الكم من L* إلى K* لتمكين القدرة الكاملة المقاومة للكم في وقت أبكر، وتأجيل إثبات التنفيذ الإجباري من K* إلى L*. إذا تم اعتماد هذا الحل، فسيتغير دور K* و L* المحدد ووتيرة الترقية وفقًا لذلك. لذا، فإن أدق بيان في هذه المرحلة هو: ديسمبر 2026 هو الهدف الحالي للشبكة الرئيسية لـ Glamsterdam، وديسمبر 2029 هو الهدف في المسار الأساسي لـ L* والقدرة الكاملة المقاومة للكم؛ قد لا يزال الترتيب الداخلي بين K و L* قابلًا للتعديل.

يجب على الباحثين ومطوري العميل وفريق مراجعة الأمان وفريق الاختبار إكمال Hegotá، بالإضافة إلى إعداد المواصفات والنماذج الأولية مسبقًا لـ I* و J* و K* و L*. إذا تم تضمين عدد كبير من الوظائف المتفاعلة في Hegotá، فقد لا يؤدي ذلك إلى تأخير إطلاقه فحسب، بل أيضًا إلى استهلاك الفريق المطلوب للعمل المتعلق بمقاومة الحوسبة الكمية في المستقبل.

لذلك، قسم فريق بروتوكول مؤسسة إيثريوم مقترحات Hegotá إلى فئات S (مقترحان)، A (15 مقترحًا)، B (8 مقترحات)، C (7 مقترحات)، DFI (28 مقترحًا)، وTBD (مقترحان)، بمجمل 62 مقترحًا. تمثل الفئة S المقترحات الضرورية للتسليم؛ تمثل الفئة A ذات الأولوية العالية ومتوقعة التسليم؛ تتطلب الفئة B استيفاء شروط مثل المواصفات أو النموذج الأولي أو تأكيد المسؤول؛ تمثل الفئة C المقترحات التي تقع حاليًا تحت خط الإدراج؛ تعني DFI أنه لا يُوصى بإدماجها في هذا التحديث؛ وTBD تعني معلقة.

في التصنيف الذي أعلنه فريق البروتوكول لـ Hegotá، هناك فقط EIPان انتقلتا إلى الفئة S: EIP-7805 FOCIL على طبقة التوافق، وEIP-8141 Frame Transaction على طبقة التنفيذ.

إنها تعالج مشكلتين أساسيتين في دورة حياة المعاملة: ما إذا كانت المعاملة المؤهلة يمكن إدماجها في الكتلة، وكيف يمكن لحساب ما التحقق من المعاملة وتنفيذها.

الاسم الكامل لـ FOCIL (EIP-7805) هو "قوائم الإدراج المعززة بواسطة قاعدة اختيار الشوكة" (Fork-choice enforced Inclusion Lists). هدفها تحسين ضمانات إدراج المعاملات على إيثريوم.

حاليًا، يهيمن مُبنون الكتل المحترفون على إنشاء الكتل. يساعد هذا التقسيم في تحسين كفاءة بناء الكتل، ولكن إذا استمر تركيز إنتاج الكتل في أيدي عدد قليل من المُبنين، فقد يكتسبون قدرة كبيرة على فلترة المعاملات. لذلك، يضيف FOCIL طبقة إضافية من قيود التضمين من قبل المُحققين خارج عملية بناء الكتل العادية.

وفقًا لتصميم FOCIL، يتم اختيار مجموعة من المُحققين لكل Slot لتشكيل "لجنة قائمة الإدراج" (IL committee). يقوم أعضاء اللجنة، بناءً على المعاملات المعلقة التي يرونها، بإنشاء قوائم إدراج وإرسالها بشكل منفصل. ثم يجمع مُبنى الكتلة في Slot التالي هذه القوائم، ويُضمن في بناء الكتلة المعاملات التي تلبي شروط التنفيذ. كما يحفظ المُحققون المسؤولون عن إثبات الكتلة الجديدة قوائم الإدراج التي تلقوها في الوقت المناسب، ويفحصون ما إذا كانت الكتلة تلبي المتطلبات المقابلة.

إذا فات الكتلة قائمة المعاملات المحفوظة من قبل المُحققين دون سبب مشروع، فلن يصوت المُثبتون لصالح هذه الكتلة. حتى لو ظلت هذه الكتلة صالحة من حيث التنفيذ، فإنها لن تحصل على الدعم التوافقي اللازم للانضمام إلى السلسلة الرسمية. هذا هو معنى FOCIL: إنه لا يسمح لأعضاء اللجنة بتعديل الكتل مباشرة، بل يقيّد خيارات مُنشئي الكتل من خلال ما إذا كان المُحققون يصوتون أم لا.

يصف EIP-8369 المرافق التفاصيل الإضافية حول أي المعاملات تصلح للحصول على ضمان الإدراج الإجباري لـ FOCIL. إن أسباب إغفال المعاملات العادية سهلة النسبيًا للتحقق منها؛ بينما تسمح معاملات Frames بالتحقق القابل للبرمجة، لكن تكلفة هذا التحقق أعلى، لذا يتطلب ذلك قيودًا إضافية على نطاق الحالة القابل للقراءة والميزانية المخصصة للتحقق.

ببساطة، لا يهدف FOCIL إلى منع المُحققين من أخذ وظيفة مُبني الكتل، بل يضيف قاعدة توافقية جديدة للمُبنيين: لا يزال بإمكانك ترتيب معظم المعاملات في الكتلة، لكنك لا يمكنك تجاهل المستندات المؤهلة المدرجة من قبل اللجنة دون سبب معقول.

معالجة Frame Transactions (EIP-8141) هي مشكلة على مستوى الحساب. إنها تهدف إلى جعل التحقق من المعاملات وتنفيذها ودفع الغاز أكثر قابلية للبرمجة على مستوى البروتوكول، لتوفير أساس للاستخراج المحض للحسابات. فيتاليك هو أحد المؤلفين المشتركين لـ EIP-8141.

حاليًا، تعتمد معظم الحسابات العادية لـ Ethereum على توقيعات مفتاح خاص من نوع ثابت. ترغب Frames في جعل الحسابات تستخدم منطق مصادقة أكثر مرونة، مثل استخدام مخططات توقيع جديدة، أو دمج شروط تفويض متعددة، أو السماح لحسابات أخرى بدفع رسوم المعاملات. كما يمكنها دعم تجميع التوقيعات والسماح بإدخال مخططات توقيع جديدة في المستقبل دون الحاجة إلى إجراء تقسيم صلب منفصل لكل مخطط.

لكن Frames نفسها ليست خطة توقيع مقاومة للحوسبة الكمية، ولن تستبدل المفاتيح الحالية فور إطلاق Hegotá. فهي توفر "مرونة تشفيرية": في المستقبل، إذا لزم تغيير خطة التوقيع، يمكن للحسابات نقل بياناتها عبر التحقق القابل للبرمجة، بدلاً من البقاء محبوسة إلى الأبد في نظام مفتاح واحد.

تحتاج Frames إلى مقترحين من الفئة A كجزء أساسي من الدعم. يسمح EIP-8250 Keyed Nonces باستخدام قنوات nonce مستقلة لنفس المرسل، مما يتيح للمعاملات المختلفة عدم عرقلة بعضها البعض بسبب مشاركتها في ترتيب صارم واحد؛ بينما يسمح EIP-8272 للمعاملات باستخدام حالة سلسلة حديثة يمكن للمدققين التحقق منها، مما يضمن لمعاملات الخصوصية ذات الصلة الحصول على ضمانات الإدراج التي توفرها FOCIL.

لذلك، FOCIL وFrames ليستا ميزتين منفصلتين. الأولى تغير أي المعاملات المؤهلة يجب تضمينها في الكتلة، والثانية تغير هيكل التحقق الخاص بالمعاملة نفسها. ما إذا كان يمكن لهما العمل معًا بأمان هو أحد أهم مهام اختبار Hegotá.

يحدد الاقتراح من الفئة S المحور الرئيسي لـ Hegotá، لكن العديد من الاقتراحات من الفئة A تؤثر أيضًا على أمان الحسابات المستقبلي لـ Ethereum، والانتقال المقاوم للحوسبة الكمية، وإثبات التنفيذ، وتسعير الموارد.

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

من حيث أمان الحساب، تُعتبر EIP-7906 و EIP-8298 و EIP-8151 مجموعات توسعية لـ Frames.

يُدخل EIP-7906 آلية إعلانات المعاملات (Transaction Assertions) التي تسمح بفحص ما إذا كان الناتج المحدد قد حدث قبل تقديم المعاملة نهائيًا. تهدف هذه الآلية إلى تقليل الخسائر الناتجة عن العقود الخبيثة التي تستنزف أصول المحفظة وبعض سلوكيات MEV. ومع ذلك، فإن نطاق القراءة المحدد لهذا المقترح لا يزال قيد الدراسة والضيق، لذا لا يمكن اعتبار التصميم الحالي معيارًا نهائيًا مُغلقًا.

يسمح EIP-8298 بإعادة استخدام كود العقد الموجود من قبل الحسابات، مما يمكّن الحسابات المعتمدة من التحول إلى حسابات عقود ذكية ذات كود كامل. بينما يقيّد EIP-8151 استمرار استخدام عناوين كود الحسابات القائمة لاعتماد مصادقة ecRecover التقليدية.

بعد دمج هاتين المقترحتين، يمكن للحساب أن يتوقف فعليًا عن استخدام مفتاح secp256k1 القديم كأعلى صلاحية تحكم، مما يخلق مسارًا كاملًا للخروج من نظام المفاتيح القديم في المستقبل.

EIP-8025 (إثبات التنفيذ الاختياري) مرتبط بمسار zkEVM المستقبلي. يهدف إلى دمج التغييرات المطلوبة لإثبات التنفيذ الاختياري في المواصفة الموحدة للتنفيذ، مما يقلل من مشكلة صيانة الإصدارات المنشقة من قبل مشاريع zkVM المختلفة على المدى الطويل.

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

يهدف EIP-3298 إلى إزالة آلية استرداد الغاز بالكامل، لتقليل الحالات الاستثنائية في القياس والتنفيذ والاختبار؛ بينما يسمح EIP-5920 (PAY Opcode) للعقود بنقل ETH دون تنفيذ كود الطرف المستقبل، مما يفصل بوضوح بين "نقل القيمة" و"استدعاء العقد".

في الوقت نفسه، لا تزال بعض المقترحات التي لفتت الانتباه في المستوى B.

على سبيل المثال، يهدف EIP-8198 (Quick Slots) إلى تقليل وقت Slot، لكن فريق البروتوكول يطلب إكمال المواصفات، والنموذج الكامل، وتقييم التأثيرات السفلية المتعلقة بالتغييرات الأساسية في البروتوكول، وإثبات أنه لن يعطل تصميم التوافق المعزول في المستقبل. السبب هو أن وقت Slot لا يؤثر فقط على سرعة إنشاء الكتل، بل أيضًا على نقل الشبكة، وتحديد التوافق، وافتراضات التطبيق المتعلقة بالوقت.

بالإضافة إلى ذلك، تم تصنيف EIP-8368 و EIP-8372 على أنهما "TBD" (قيد التحديد). تتعلق المقترحان بحدود الغاز وتسعير موارد الحالة، وقرر فريق البروتوكول الانتظار حتى صدور بيانات الشبكة الرئيسية بعد إطلاق Glamsterdam في ديسمبر 2026، قبل تحديد ما إذا كان هناك حاجة إلى إعادة ضبط.

عدد EIPs التي تم تضمينها في Hegotá ليس المعيار الوحيد لقياس نجاح هذا التحديث.

الأهم من ذلك، هل يمكنه تسليم FOCIL وFrames وملحقاتها الأساسية دون التضحية بالأمان وجودة الاختبار، مع ترك موارد بحث وتطوير كافية لتسجيل المفتاح العام لـ I* وفك الارتباط في التوافق، وقدرات الحماية ضد الحواسيب الكمية الدنيا لـ J*، وإثبات التنفيذ والتوافق الكامل المقاوم للحواسيب الكمية لـ K* وL*.

وفقًا للأهداف الحالية، ستبدأ Glamsterdam دورة الترقية المكثفة هذه في ديسمبر 2026، بينما سيصل L* في المسار الأساسي إلى نقطة النهاية في ديسمبر 2029. لا يمكن لأي ترقية وسطية أن تركز فقط على إكمال وظائفها، بل يجب أن تضمن أيضًا استمرار التقدم في المرحلة التالية.

لا يمكن لأحد أن يعطي إجابة مؤكدة بشأن ما إذا كانت التهديدات الكمية ستتحول إلى واقع قبل عام 2030. لكن الخيارات الحالية لإيثريوم واضحة بالفعل: تحديد موعد نهائي للمخاطر، ثم السماح لكل مقترح بإثبات جدارته بالدخول إلى الشبكة الرئيسية من خلال المواصفات والنماذج الأولية والاختبارات.

مرجع المقال:

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446