EIP-2537 هو توجيه مسبق محدد في تحديث الانقسام Pectra الأخير لإيثريوم. يضيف هذا التوجيه مجموعة من الوظائف الحسابية على منحنى BLS12-381 لـ EVM، مثل حسابات الاقتران على مجال المنحنى.
تم اقتراح EIP-2537 لأول مرة في عام 2020 ولم يتم تأكيده ليتم تضمينه في ترقية Ethereum حتى عام 2025. ستتناول هذه المقالة مسار إدارة EIP-2537، وتستكشف سبب اعتماد هذا الاقتراح بعد 5 سنوات.
خلفية الاقتراح
في يناير 2017، قدم فيتاليك بوتيرين لأول مرة خوارزمية الاقتران ومنحنى alt_bn128 في مقال. ثم في فبراير، اقترح فيتاليك وكريستيان رايتفيسنر EIP-196 وEIP-197، مقترحين إضافة دعم حساب منحنى alt_bn128 إلى EVM.
تم دمج ترقية بيزنطية في أكتوبر 2017 رسميًا في منحنى alt_bn128، مما أدى إلى تنفيذ حسابات مطابقة نطاق المنحنى داخل EVM، مما يجعل التحقق من إثباتات ZK-Snarks ممكنًا داخل EVM.
لكن مع تطور علم التشفير، قدم فريق zcash في نوفمبر 2017 منحنى BLS12-381، الذي يتمتع بأمان أعلى وأداء أفضل مقارنةً بمنحنى alt_bn128. العديد من بروتوكولات البلوكتشين اعتمدت لاحقًا منحنى BLS12-381 بدلاً من alt_bn128.
في مايو 2018، نشر جاستين دريك مقالًا يشير إلى أن ترقية PoS والشظايا المستقبلية لإيثيريوم يمكن أن تستخدم خوارزمية BLS المتعددة التوقيع المستندة إلى BLS12-381. وقد وضعت هذه الأساس لترقية ETH2 اللاحقة.
مع تطوير ETH2، بدأت الأصوات ترتفع لإدخال BLS12-381 في طبقة التنفيذ. في فبراير 2020، اقترح الباحثون EIP-2537، على أمل اختباره مع شبكة اختبار ETH2. دعا مؤلف EIP-2537، أليكس ستوك، إلى دمجه في الانقسام الصلب برلين.
من الجدير بالذكر أن مؤلف EIP-2537 هو أيضاً أحد مؤسسي Matter Labs، والشركة الأكثر شهرة منتجاتها هي ZKSync.
برلين المضطرب
قبل تقديم المحتوى التالي، يجب أن نفهم EIP-1962. هذا هو أول اقتراح مسبق للتجميع في مجال منحنيات الإهليلجي الذي قدمته Matter Labs في أبريل 2019، ويدعم ثلاث منحنيات هي BLS12 و BN و MNT4/6.
يخطط EIP-1962 لزيادة 10 أوامر مسبقة التنفيذ مرة واحدة لمعالجة منحنيات مختلفة. ومع ذلك، يعتقد العديد من المطورين أن ذلك معقد للغاية وصعب التنفيذ، وغير مناسب لمهندسي العقود الذكية. ومع ذلك، أكملت Matter Labs تطوير الخوارزمية وقدمت تنفيذات مرجعية متعددة اللغات.
لحل مشكلة EIP-1962، اقترحت Matter Labs في فبراير 2020 عدة خطط لتقسيم EIP:
EIP-2537 يوفر دعم BLS12-381
EIP-2539 يوفر دعم BLS12-377
PR#2541 يوفر دعم BLS12-377(Zexe curve)، لكنه لم يحصل على رقم EIP.
من بين هذه، تعتبر EIP-2537 الأهم، لأن طبقة الإجماع تستخدم أيضًا منحنى BLS12-381. الهدف الأساسي من EIP-1962 و EIP-2537 هو تحقيق التحقق من توقيع BLS في طبقة الإجماع على الشبكة الرئيسية.
كان ETH2 في ذلك الوقت قيد تطوير عقد الإيداع. نظرًا لعدم وجود تحقق BLS في طبقة التنفيذ، لم يتحقق عقد الإيداع من التوقيع في التصميم الأصلي، بل تم التحقق منه من قبل طبقة الإجماع، وإذا كان غير صحيح، فإن الإيداع يفشل مما يؤدي إلى خسارة الأموال.
لذلك، أراد المطورون الأساسيون إدخال BLS12-381 كودًا مسبقًا، للتحقق من التوقيعات في عقد الإيداع لتجنب مخاطر الأموال. وكانت هذه أيضًا سبب اهتمام المطورين في ذلك الوقت بـ EIP-1962 و EIP-2537.
بعد تقديم EIP-2537، أشار فيتاليك على الفور إلى سلسلة من المشاكل، تركزت بشكل رئيسي على محتوى الوثيقة. ثم قام المؤلف بالرد والنقاش.
عقد اجتماع المطورين الرئيسيين في 6 مارس 2020 رقم 82 لمناقشة EIP-2537. يعتبر فيتاليك أنه فعال جدًا في إثباتات SNARK المتكررة، وعلى المدى الطويل لن يضر بالإيثيريوم. أكد الاجتماع على أولوية EIP-2537، حيث اتفقت جميع العملاء على تنفيذها في أقرب وقت ممكن وإكمال التطوير قبل ترقية برلين.
بعد ذلك أصبحت EIP-2537 مهمة ذات أولوية عالية. في اجتماع 20 مارس، تمت مناقشة الاقتراح مرة أخرى كأولوية، وتم التأكيد على أنه سيحل محل EIP-1962 ليصبح الاقتراح الأساسي لـ BLS، وسيتم تضمينه في قائمة الترشيحات لترقية برلين.
اجتماع أبريل 84 رسمياً يدرج EIP-2537 في شق برلين الصلب، ويحدد الجدول الزمني للتنفيذ في أبريل والاختبار في مايو-يونيو. تم تصنيف EIP-2537 كأعلى أولوية.
بعد ذلك دخل EIP-2537 في مرحلة تطوير واختبار مكثفة، حيث تم مناقشة الموضوع تقريبًا في كل اجتماع من الاجتماعات الرئيسية للمطورين التي تلت ذلك والتي كانت تقارب 20 مرة.
ناقشت الاجتماع 85 مشكلة ترميز ABI. نظراً لأن Matter Labs قد أكملت بشكل أساسي تنفيذ Rust، فإن عميل Besu قد أعلن أنه قد نفذ بشكل أساسي وظيفة EIP-2537، ولكن Geth أفاد أنه لم يبدأ بعد في العمل.
اجتماع 86 جميع العقد تزامن مرة أخرى حول حالة التنفيذ، قالت Geth إنها أكملت بعض الأعمال ولكن لا يزال هناك الكثير من المهام التي يتعين إكمالها.
المحتوى الأساسي للاجتماع 87 هو مشكلة تنفيذ EIP-2537. قال مطورو Geth إنه يوجد PR يتكون من 16000 سطر لتنفيذ EIP-2537، لكن لا يمكن تحديد ما إذا كان آمنًا وفعالًا، ويمكن الحكم عليه فقط من خلال اختبار ضبابي بسيط. تعتقد Geth أنه من المحتمل جدًا أنه لن يتم الانتهاء من التطوير ذات الصلة قبل الموعد المحدد في برلين.
اقترح هادسون جيمسون البحث عن مهندسي تشفير لمساعدة في مراجعة PR لـ Geth، كما اقترح اختبار التنفيذ على شبكة اختبار للتحقق من الأمان. يمكن لفريق ETH2 أيضًا المشاركة في الاختبار.
ومن المهم أن نضيف أن تنفيذ EIP-2537 الخاص بـ Geth يستخدم الكثير من تعليمات التجميع لضمان الكفاءة، مما يجعله صعب القراءة والفهم. اقترح أليكس فلاسوف إزالة تحسينات تعليمات التجميع المعقدة لتقليل صعوبة التدقيق.
على الرغم من أن أحد الأهداف الأساسية لـ EIP-2537 هو مساعدة عقد إيداع ETH2، إلا أن مطوري عقد الإيداع في هذه الاجتماع ذكروا أنهم لا يستخدمون النسخة التي تم تدقيقها من EIP-2537، واقترح بعض المطورين عدم إصدار إصدار جديد يستخدم EIP-2537.
قررت الاجتماع الأخير زيادة اختبار شبكة YOLO لاختبار EIP-2537 بشكل خاص. في هذه المرحلة، يمكن أن نرى أنه مع اكتمال عقد الإيداع، انخفضت أهمية EIP-2537 بشكل كبير، ويعتقد مطورو Geth أنه من المحتمل ألا يتم تحقيق ذلك قبل ترقية برلين. يبدو أن عدم إدراج EIP-2537 في برلين قد أصبح محسوماً.
في الاجتماع 88، اكتشف مطورو Geth أن هناك مجموعة من المشكلات في تنفيذ PR الخاص بـ EIP-2537، وأشاروا إلى الحاجة إلى مزيد من الاختبار والإصلاح. في هذه المرحلة، كان هناك إصداران من Geth، أحدهما يحتوي على تحسينات التجميع، والآخر مكتوب بالكامل بلغة Go. اقترح البعض استخدام إصدار Go مباشرة لتقليل صعوبة مراجعة الشفرة.
ظهرت مشاكل أكثر خطورة في المؤتمر 89، وظهرت استثناءات في شبكة اختبار YOLO، ويُشتبه في أنها ناتجة عن توقيع BLS، لكن مطوري EIP-2537 ردوا على ذلك. الخبر الجيد هو أن عقد الإيداع المستند إلى EIP-2537 قد اكتمل تقريبًا في التطوير، وهو في انتظار التدقيق.
اجتمعت 90 لتحديد موعد إطلاق ترقية برلين في يوليو. كما ناقشت الاجتماع مشكلة تنوع العميل، حيث اقترح البعض تجميد تنفيذ EIP الحالي لتقليل تكلفة تطوير العملاء الآخرين. حتى أن الاجتماع 91 اقترح استخدام الحلول المعيارية لزيادة تنوع العملاء.
اجتماع 92 يؤكد مرة أخرى أن EIP-2537 هو EIP المطلوب لترقية برلين.
تناقش الاجتماع 96 ما إذا كان ينبغي تضمين EIP-2539 أيضًا في اختبار برلين، حيث قامت Celo بإدراج EIP-2537 وEIP-2539 في ترقية الشبكة الخاصة بها. ومع ذلك، عارض مطورو Geth، معتبرين أن EIP-2537 نفسه لم يتم اختباره بالكامل بعد. في النهاية، تم اتخاذ القرار بعدم إضافة EIP-2696 في برلين.
قررت الاجتماع 99 نقل EIP-2537 من شبكة اختبار YOLO v3 وترقية برلين، والسبب الرئيسي هو أنه استغرق وقتًا طويلاً من المطورين مما أثر على تطوير EIPs أخرى. العامل الثانوي هو أن مؤسسة إيثريوم اقترحت EVM384 كبديل. لكن المطورين أعربوا عن مخاوفهم بشأن أمانه.
هذه هي المسيرة المبكرة لـ EIP-2537. كانت واحدة من أهم EIPs في ترقية برلين، لكنها أُلغيت في النهاية بسبب مشكلات في التنفيذ. في أبريل 2021، أكمل الإيثيريوم ترقية برلين، وكانت تنفيذات EIPs الأساسية مثل EIP-2565 بسيطة نسبيًا، مما جعلها تبدو ضعيفة بعض الشيء، وذلك لأن EIP-2537 الأكثر تعقيدًا تم استبعاده.
التطورات المستقبلية
من المعروف أن كل ترقية لإيثريوم لديها اقتراحات رئيسية، مثل إدخال EIP-1559 بعد برلين. فيما يتعلق بـ EIP-2537 الذي كان اقتراحًا رئيسيًا، سيكون من الصعب إدراجه في الترقيات اللاحقة.
عند ترقية لندن، نظر المطورون في إضافة EIP-2537. وقد تم تنسيق الاجتماع 109 حول حالة تطويره، حيث أثار استخدام المكتبة الجديدة مناقشات حول الغاز. اقترح البعض استبداله بـ EVM384. لكن الاجتماع 111 أزاله بسبب التعقيد، حيث أدى التغيير في المكتبة إلى تغيير في تسعير الغاز، مما يتطلب إعادة تقييم.
في يونيو 2021، تم اقتراح رسميًا إدراج EIP-2537 في ترقية شنغهاي. لكن بعد لندن، استحوذ الدمج على وقت كبير من المطورين. بعد الانتهاء من الدمج في سبتمبر 2022، أصبح لدى مطوري الطبقة التنفيذية الفرصة لمواصلة مناقشة أهداف شنغهاي.
اجتماع نوفمبر 2022 ناقش بإيجاز 150 ما إذا كان ينبغي تضمين شنغهاي، لكن المطورين اعتبروا أنه يجب تأجيله، حيث أن جوهر شنغهاي هو دعم سحب PoS. في النهاية، لم يتم تضمين EIP-2537 في ترقية شنغهاي التي تركز على السحب.
أسوأ من ذلك، لم يتم مناقشة ترقية Cancun المتعلقة بـ EIP-2537، لأن جوهرها هو دعم EIP-4844، لتوفير إمكانية استخدام بيانات Blob للطبقة الثانية.
أخيرًا، في اجتماع 181 في فبراير 2024، تم مناقشة دمج ترقية Pectra في EIP-2537، ويعتقد المطورون أن التنفيذ لم يعد مشكلة، فقط توجد مشكلة تسعير الغاز.
في اجتماع 202 في 19 ديسمبر 2024، حدد مطورو Nethermind نموذج تسعير EIP-2537 بشكل نهائي. كان الاقتراح الأصلي من Matter Labs قد انسحب تقريبًا من المناقشة في ذلك الوقت. في اجتماع 203 في يناير 2025، تم مناقشة إعادة التسعير، حيث اقترح مطورو Geth زيادة تكلفة الغاز بنسبة 20%، وحصل على دعم من فريق Besu.
ملخص
استغرق اعتماد EIP-2537 خمس سنوات طويلة منذ طرحه. كان محور ترقية برلين ولكنه تم التخلي عنه بسبب صعوبة التنفيذ. بعد ذلك، دخلت إيثيريوم في عملية تاريخية من PoS، حيث لم يتم الاهتمام بـ EIP الطبقة التنفيذية البحتة المعقدة، وأصبح عدد كبير من EIPs المتعلقة بـ PoS أهدافًا رئيسية، مما أدى إلى عدم قبول EIP-2537 لفترة طويلة. حتى عام 2025، مع حل المشكلات التقنية الرئيسية، أصبح من الممكن أخيرًا تنفيذ EIP-2537 في ترقية Pectra.
تشير هذه الرحلة إلى أن إمكانية تضمين EIP في ترقية الإيثيريوم لا تعتمد فقط على قيمتها التقنية الخاصة، ولكن أيضًا تحتاج إلى أخذ مرحلة تطوير الإيثيريوم وأولوياته بعين الاعتبار. كل ترقية لها موضوعها الخاص، فقط EIP التي تلبي الاحتياجات الحالية وتكون ناضجة تقنيًا يمكن أن يتم اعتمادها في النهاية.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
EIP-2537 المسار الطويل: من أولوية عالية في برلين إلى اعتماد ترقية Pectra
EIP-2537: الرحلة الطويلة من 2020 إلى 2025
EIP-2537 هو توجيه مسبق محدد في تحديث الانقسام Pectra الأخير لإيثريوم. يضيف هذا التوجيه مجموعة من الوظائف الحسابية على منحنى BLS12-381 لـ EVM، مثل حسابات الاقتران على مجال المنحنى.
تم اقتراح EIP-2537 لأول مرة في عام 2020 ولم يتم تأكيده ليتم تضمينه في ترقية Ethereum حتى عام 2025. ستتناول هذه المقالة مسار إدارة EIP-2537، وتستكشف سبب اعتماد هذا الاقتراح بعد 5 سنوات.
خلفية الاقتراح
في يناير 2017، قدم فيتاليك بوتيرين لأول مرة خوارزمية الاقتران ومنحنى alt_bn128 في مقال. ثم في فبراير، اقترح فيتاليك وكريستيان رايتفيسنر EIP-196 وEIP-197، مقترحين إضافة دعم حساب منحنى alt_bn128 إلى EVM.
تم دمج ترقية بيزنطية في أكتوبر 2017 رسميًا في منحنى alt_bn128، مما أدى إلى تنفيذ حسابات مطابقة نطاق المنحنى داخل EVM، مما يجعل التحقق من إثباتات ZK-Snarks ممكنًا داخل EVM.
لكن مع تطور علم التشفير، قدم فريق zcash في نوفمبر 2017 منحنى BLS12-381، الذي يتمتع بأمان أعلى وأداء أفضل مقارنةً بمنحنى alt_bn128. العديد من بروتوكولات البلوكتشين اعتمدت لاحقًا منحنى BLS12-381 بدلاً من alt_bn128.
في مايو 2018، نشر جاستين دريك مقالًا يشير إلى أن ترقية PoS والشظايا المستقبلية لإيثيريوم يمكن أن تستخدم خوارزمية BLS المتعددة التوقيع المستندة إلى BLS12-381. وقد وضعت هذه الأساس لترقية ETH2 اللاحقة.
مع تطوير ETH2، بدأت الأصوات ترتفع لإدخال BLS12-381 في طبقة التنفيذ. في فبراير 2020، اقترح الباحثون EIP-2537، على أمل اختباره مع شبكة اختبار ETH2. دعا مؤلف EIP-2537، أليكس ستوك، إلى دمجه في الانقسام الصلب برلين.
من الجدير بالذكر أن مؤلف EIP-2537 هو أيضاً أحد مؤسسي Matter Labs، والشركة الأكثر شهرة منتجاتها هي ZKSync.
برلين المضطرب
قبل تقديم المحتوى التالي، يجب أن نفهم EIP-1962. هذا هو أول اقتراح مسبق للتجميع في مجال منحنيات الإهليلجي الذي قدمته Matter Labs في أبريل 2019، ويدعم ثلاث منحنيات هي BLS12 و BN و MNT4/6.
يخطط EIP-1962 لزيادة 10 أوامر مسبقة التنفيذ مرة واحدة لمعالجة منحنيات مختلفة. ومع ذلك، يعتقد العديد من المطورين أن ذلك معقد للغاية وصعب التنفيذ، وغير مناسب لمهندسي العقود الذكية. ومع ذلك، أكملت Matter Labs تطوير الخوارزمية وقدمت تنفيذات مرجعية متعددة اللغات.
لحل مشكلة EIP-1962، اقترحت Matter Labs في فبراير 2020 عدة خطط لتقسيم EIP:
من بين هذه، تعتبر EIP-2537 الأهم، لأن طبقة الإجماع تستخدم أيضًا منحنى BLS12-381. الهدف الأساسي من EIP-1962 و EIP-2537 هو تحقيق التحقق من توقيع BLS في طبقة الإجماع على الشبكة الرئيسية.
كان ETH2 في ذلك الوقت قيد تطوير عقد الإيداع. نظرًا لعدم وجود تحقق BLS في طبقة التنفيذ، لم يتحقق عقد الإيداع من التوقيع في التصميم الأصلي، بل تم التحقق منه من قبل طبقة الإجماع، وإذا كان غير صحيح، فإن الإيداع يفشل مما يؤدي إلى خسارة الأموال.
لذلك، أراد المطورون الأساسيون إدخال BLS12-381 كودًا مسبقًا، للتحقق من التوقيعات في عقد الإيداع لتجنب مخاطر الأموال. وكانت هذه أيضًا سبب اهتمام المطورين في ذلك الوقت بـ EIP-1962 و EIP-2537.
بعد تقديم EIP-2537، أشار فيتاليك على الفور إلى سلسلة من المشاكل، تركزت بشكل رئيسي على محتوى الوثيقة. ثم قام المؤلف بالرد والنقاش.
عقد اجتماع المطورين الرئيسيين في 6 مارس 2020 رقم 82 لمناقشة EIP-2537. يعتبر فيتاليك أنه فعال جدًا في إثباتات SNARK المتكررة، وعلى المدى الطويل لن يضر بالإيثيريوم. أكد الاجتماع على أولوية EIP-2537، حيث اتفقت جميع العملاء على تنفيذها في أقرب وقت ممكن وإكمال التطوير قبل ترقية برلين.
بعد ذلك أصبحت EIP-2537 مهمة ذات أولوية عالية. في اجتماع 20 مارس، تمت مناقشة الاقتراح مرة أخرى كأولوية، وتم التأكيد على أنه سيحل محل EIP-1962 ليصبح الاقتراح الأساسي لـ BLS، وسيتم تضمينه في قائمة الترشيحات لترقية برلين.
اجتماع أبريل 84 رسمياً يدرج EIP-2537 في شق برلين الصلب، ويحدد الجدول الزمني للتنفيذ في أبريل والاختبار في مايو-يونيو. تم تصنيف EIP-2537 كأعلى أولوية.
بعد ذلك دخل EIP-2537 في مرحلة تطوير واختبار مكثفة، حيث تم مناقشة الموضوع تقريبًا في كل اجتماع من الاجتماعات الرئيسية للمطورين التي تلت ذلك والتي كانت تقارب 20 مرة.
ناقشت الاجتماع 85 مشكلة ترميز ABI. نظراً لأن Matter Labs قد أكملت بشكل أساسي تنفيذ Rust، فإن عميل Besu قد أعلن أنه قد نفذ بشكل أساسي وظيفة EIP-2537، ولكن Geth أفاد أنه لم يبدأ بعد في العمل.
اجتماع 86 جميع العقد تزامن مرة أخرى حول حالة التنفيذ، قالت Geth إنها أكملت بعض الأعمال ولكن لا يزال هناك الكثير من المهام التي يتعين إكمالها.
المحتوى الأساسي للاجتماع 87 هو مشكلة تنفيذ EIP-2537. قال مطورو Geth إنه يوجد PR يتكون من 16000 سطر لتنفيذ EIP-2537، لكن لا يمكن تحديد ما إذا كان آمنًا وفعالًا، ويمكن الحكم عليه فقط من خلال اختبار ضبابي بسيط. تعتقد Geth أنه من المحتمل جدًا أنه لن يتم الانتهاء من التطوير ذات الصلة قبل الموعد المحدد في برلين.
اقترح هادسون جيمسون البحث عن مهندسي تشفير لمساعدة في مراجعة PR لـ Geth، كما اقترح اختبار التنفيذ على شبكة اختبار للتحقق من الأمان. يمكن لفريق ETH2 أيضًا المشاركة في الاختبار.
ومن المهم أن نضيف أن تنفيذ EIP-2537 الخاص بـ Geth يستخدم الكثير من تعليمات التجميع لضمان الكفاءة، مما يجعله صعب القراءة والفهم. اقترح أليكس فلاسوف إزالة تحسينات تعليمات التجميع المعقدة لتقليل صعوبة التدقيق.
على الرغم من أن أحد الأهداف الأساسية لـ EIP-2537 هو مساعدة عقد إيداع ETH2، إلا أن مطوري عقد الإيداع في هذه الاجتماع ذكروا أنهم لا يستخدمون النسخة التي تم تدقيقها من EIP-2537، واقترح بعض المطورين عدم إصدار إصدار جديد يستخدم EIP-2537.
قررت الاجتماع الأخير زيادة اختبار شبكة YOLO لاختبار EIP-2537 بشكل خاص. في هذه المرحلة، يمكن أن نرى أنه مع اكتمال عقد الإيداع، انخفضت أهمية EIP-2537 بشكل كبير، ويعتقد مطورو Geth أنه من المحتمل ألا يتم تحقيق ذلك قبل ترقية برلين. يبدو أن عدم إدراج EIP-2537 في برلين قد أصبح محسوماً.
في الاجتماع 88، اكتشف مطورو Geth أن هناك مجموعة من المشكلات في تنفيذ PR الخاص بـ EIP-2537، وأشاروا إلى الحاجة إلى مزيد من الاختبار والإصلاح. في هذه المرحلة، كان هناك إصداران من Geth، أحدهما يحتوي على تحسينات التجميع، والآخر مكتوب بالكامل بلغة Go. اقترح البعض استخدام إصدار Go مباشرة لتقليل صعوبة مراجعة الشفرة.
ظهرت مشاكل أكثر خطورة في المؤتمر 89، وظهرت استثناءات في شبكة اختبار YOLO، ويُشتبه في أنها ناتجة عن توقيع BLS، لكن مطوري EIP-2537 ردوا على ذلك. الخبر الجيد هو أن عقد الإيداع المستند إلى EIP-2537 قد اكتمل تقريبًا في التطوير، وهو في انتظار التدقيق.
اجتمعت 90 لتحديد موعد إطلاق ترقية برلين في يوليو. كما ناقشت الاجتماع مشكلة تنوع العميل، حيث اقترح البعض تجميد تنفيذ EIP الحالي لتقليل تكلفة تطوير العملاء الآخرين. حتى أن الاجتماع 91 اقترح استخدام الحلول المعيارية لزيادة تنوع العملاء.
اجتماع 92 يؤكد مرة أخرى أن EIP-2537 هو EIP المطلوب لترقية برلين.
تناقش الاجتماع 96 ما إذا كان ينبغي تضمين EIP-2539 أيضًا في اختبار برلين، حيث قامت Celo بإدراج EIP-2537 وEIP-2539 في ترقية الشبكة الخاصة بها. ومع ذلك، عارض مطورو Geth، معتبرين أن EIP-2537 نفسه لم يتم اختباره بالكامل بعد. في النهاية، تم اتخاذ القرار بعدم إضافة EIP-2696 في برلين.
قررت الاجتماع 99 نقل EIP-2537 من شبكة اختبار YOLO v3 وترقية برلين، والسبب الرئيسي هو أنه استغرق وقتًا طويلاً من المطورين مما أثر على تطوير EIPs أخرى. العامل الثانوي هو أن مؤسسة إيثريوم اقترحت EVM384 كبديل. لكن المطورين أعربوا عن مخاوفهم بشأن أمانه.
هذه هي المسيرة المبكرة لـ EIP-2537. كانت واحدة من أهم EIPs في ترقية برلين، لكنها أُلغيت في النهاية بسبب مشكلات في التنفيذ. في أبريل 2021، أكمل الإيثيريوم ترقية برلين، وكانت تنفيذات EIPs الأساسية مثل EIP-2565 بسيطة نسبيًا، مما جعلها تبدو ضعيفة بعض الشيء، وذلك لأن EIP-2537 الأكثر تعقيدًا تم استبعاده.
التطورات المستقبلية
من المعروف أن كل ترقية لإيثريوم لديها اقتراحات رئيسية، مثل إدخال EIP-1559 بعد برلين. فيما يتعلق بـ EIP-2537 الذي كان اقتراحًا رئيسيًا، سيكون من الصعب إدراجه في الترقيات اللاحقة.
عند ترقية لندن، نظر المطورون في إضافة EIP-2537. وقد تم تنسيق الاجتماع 109 حول حالة تطويره، حيث أثار استخدام المكتبة الجديدة مناقشات حول الغاز. اقترح البعض استبداله بـ EVM384. لكن الاجتماع 111 أزاله بسبب التعقيد، حيث أدى التغيير في المكتبة إلى تغيير في تسعير الغاز، مما يتطلب إعادة تقييم.
في يونيو 2021، تم اقتراح رسميًا إدراج EIP-2537 في ترقية شنغهاي. لكن بعد لندن، استحوذ الدمج على وقت كبير من المطورين. بعد الانتهاء من الدمج في سبتمبر 2022، أصبح لدى مطوري الطبقة التنفيذية الفرصة لمواصلة مناقشة أهداف شنغهاي.
اجتماع نوفمبر 2022 ناقش بإيجاز 150 ما إذا كان ينبغي تضمين شنغهاي، لكن المطورين اعتبروا أنه يجب تأجيله، حيث أن جوهر شنغهاي هو دعم سحب PoS. في النهاية، لم يتم تضمين EIP-2537 في ترقية شنغهاي التي تركز على السحب.
أسوأ من ذلك، لم يتم مناقشة ترقية Cancun المتعلقة بـ EIP-2537، لأن جوهرها هو دعم EIP-4844، لتوفير إمكانية استخدام بيانات Blob للطبقة الثانية.
أخيرًا، في اجتماع 181 في فبراير 2024، تم مناقشة دمج ترقية Pectra في EIP-2537، ويعتقد المطورون أن التنفيذ لم يعد مشكلة، فقط توجد مشكلة تسعير الغاز.
في اجتماع 202 في 19 ديسمبر 2024، حدد مطورو Nethermind نموذج تسعير EIP-2537 بشكل نهائي. كان الاقتراح الأصلي من Matter Labs قد انسحب تقريبًا من المناقشة في ذلك الوقت. في اجتماع 203 في يناير 2025، تم مناقشة إعادة التسعير، حيث اقترح مطورو Geth زيادة تكلفة الغاز بنسبة 20%، وحصل على دعم من فريق Besu.
ملخص
استغرق اعتماد EIP-2537 خمس سنوات طويلة منذ طرحه. كان محور ترقية برلين ولكنه تم التخلي عنه بسبب صعوبة التنفيذ. بعد ذلك، دخلت إيثيريوم في عملية تاريخية من PoS، حيث لم يتم الاهتمام بـ EIP الطبقة التنفيذية البحتة المعقدة، وأصبح عدد كبير من EIPs المتعلقة بـ PoS أهدافًا رئيسية، مما أدى إلى عدم قبول EIP-2537 لفترة طويلة. حتى عام 2025، مع حل المشكلات التقنية الرئيسية، أصبح من الممكن أخيرًا تنفيذ EIP-2537 في ترقية Pectra.
تشير هذه الرحلة إلى أن إمكانية تضمين EIP في ترقية الإيثيريوم لا تعتمد فقط على قيمتها التقنية الخاصة، ولكن أيضًا تحتاج إلى أخذ مرحلة تطوير الإيثيريوم وأولوياته بعين الاعتبار. كل ترقية لها موضوعها الخاص، فقط EIP التي تلبي الاحتياجات الحالية وتكون ناضجة تقنيًا يمكن أن يتم اعتمادها في النهاية.