EIP-2537: الطريق الطويل لتعليمات التجميع BLS12-381 في إثيريوم
EIP-2537 هو التعليمات البرمجية المسبقة لـ EVM التي تم تحديدها للإضافة في آخر ترقية للانقسام Pectra. تضيف هذه التعليمات البرمجية وظائف حسابية متعددة لمنحنى BLS12-381 لـ EVM، بما في ذلك حسابات الاقتران على مجال المنحنى.
تم تقديم EIP-2573 لأول مرة في عام 2020، ولم يتم التأكيد على إدراجه في ترقية إثيريوم حتى عام 2025. ستتناول هذه المقالة مسار حوكمة EIP-2537، وتستكشف لماذا استغرق هذا الاقتراح 5 سنوات ليتم تضمينه أخيرًا في الترقية.
خلفية الاقتراح
في يناير 2017، قدم فيتاليك بوتيرين لأول مرة خوارزمية الاقتران ومنحنى alt_bn128. بعد ذلك، اقترح فيتاليك وكريستيان ريتفايسنر EIP-196 وEIP-197، لإضافة دعم حساب منحنى alt_bn128 إلى EVM. تم اعتماد هذه الاقتراحات رسميًا في ترقية بيزنطium في أكتوبر 2017، مما أدى إلى تنفيذ حساب الاقتران في مجال المنحنى داخل EVM، مما يتيح التحقق من إثبات ZK-Snarks داخل EVM.
مع تطور علم التشفير، قدم فريق zcash في نوفمبر 2017 منحنى BLS12-381. مقارنةً بـ alt_bn128، يتمتع BLS12-381 بمزيد من الأمان وأداء أفضل. بدأت العديد من بروتوكولات blockchain في استخدام منحنى BLS12-381 بدلاً من منحنى alt_bn128.
في مايو 2018، أشار جاستن دريك إلى أن ترقية PoS والشظايا المستقبلية لإثيريوم يمكن أن تستخدم خوارزمية التوقيع المتعدد BLS المستندة إلى منحنى BLS12-381. وهذا جعل خطة EIP-1011 الأصلية تخرج من المسرح التاريخي. وقد ثبت أن ترقية ETH2 اللاحقة قد اعتمدت بالفعل منحنى BLS12-381.
مع تطوير ETH2، تزداد الدعوات لإدخال BLS12-381 في طبقة تنفيذ ETH. في فبراير 2020، اقترح الباحثون EIP-2537، على أمل أن يتم قبول هذا الاقتراح للاختبار مع شبكة اختبار ETH2. دعا مؤلف EIP-2537 أليكس ستوكز إلى إدراج EIP-2537 في الانقسام الصلب Berlin.
من الجدير بالذكر أن مؤلف 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-1962، حيث ورثت بعض منها واجهته. تشمل هذه 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، فلن يقوم عقد الإيداع بالتحقق من التوقيع، وسيتم التحقق من توقيع BLS المحدد بواسطة طبقة الإجماع بعد إيداع المستخدم، وإذا تم اكتشاف خطأ، فقد يؤدي ذلك إلى فقدان أموال المستخدم.
في هذا السياق، يأمل المطورون الأساسيون في إدخال BLS12-381 كمكون مسبق البرمجة في عقد الإيداع لتحقيق التحقق من التوقيع، لتجنب الخسائر المحتملة لأموال المستخدمين في ETH2. كان هذا هو السبب وراء اهتمام العديد من المطورين بـ EIP-1962 و EIP-2537 آنذاك.
بعد تقديم EIP-2537، أشار فيتاليك على الفور إلى مجموعة من القضايا، التي تركزت بشكل رئيسي على محتوى وثيقة EIP. ثم قام مؤلفو EIP بالرد والمناقشة. في اجتماع مطوري النواة في 6 مارس 2020، اعتبر فيتاليك أن EIP-2537 وEIPs الأخرى فعالة جدًا في إثبات SNARK التكراري، وأنها على المدى الطويل لن تضر بإيثيريوم. وأكد الاجتماع على أولوية EIP-2537، حيث اتفقت جميع العملاء على تنفيذها في أقرب وقت ممكن وتخطط لإكمال التطوير قبل ترقية برلين.
بعد ذلك، أصبحت EIP-2537 مهمة ذات أولوية عالية. أكدت اجتماع 20 مارس أن EIP-2537 ستستبدل EIP-1962 لتصبح الاقتراح الرئيسي لـ BLS، ودخلت قائمة الترشيحات لترقية برلين. في اجتماع أبريل، تم إدراج EIP-2537 رسميًا في ترقية الشوكة الصلبة لبرلين، وتم تحديد الجدول الزمني للتنفيذ في أبريل والاختبار في مايو-يونيو، وتم تصنيفها كأعلى أولوية.
بعد ذلك، دخل EIP-2537 في مرحلة تطوير واختبار كبيرة، حيث تم مناقشته في حوالي 20 اجتماعًا للمطورين الأساسيين.
في الاجتماع الخامس والثمانين، ناقش المطورون مشكلة ترميز ABI لـ EIP-2537. قالت عميل Besu إنها نفذت الوظيفة بشكل أساسي، لكن فريق Geth قال إنه لم يقم أحد بعد بأي عمل ذي صلة.
في الاجتماع رقم 86، ذكرت Geth أنها أكملت جزءًا من العمل، لكن لا يزال هناك الكثير من العمل الذي يتعين القيام به.
تناقش الاجتماع رقم 87 بشكل أساسي مشكلة تنفيذ EIP-2537. وأشار مطورو Geth إلى وجود PR مكون من 16000 سطر لتنفيذ EIP-2537، لكن لا يمكن تحديد سلامته وفعاليته، ولا يمكن إلا الحكم عليه من خلال اختبارات الضبابية البسيطة. يعتقد مطورو Geth أنه لا يمكنهم إكمال تطوير EIP-2537 قبل الموعد المحدد في برلين.
قررت الاجتماع زيادة اختبار شبكة YOLO لاختبار EIP-2537 بشكل خاص. في هذا الوقت، انخفضت أهمية EIP-2537 بشكل كبير، ويعتقد مطورو Geth أن هذا EIP من المحتمل ألا يتم تضمينه في ترقية برلين.
في الاجتماع الثامن والثمانين، اكتشف مطورو Geth أن تنفيذ PR لـ EIP-2537 يعاني من مجموعة من المشكلات التي تحتاج إلى مزيد من الاختبار والإصلاح. يوجد في نظام Geth تنفيذان لـ EIP-2537، أحدهما يحتوي على تحسينات تجميعية، والآخر مكتوب بالكامل بلغة Go، وقد اقترح البعض استخدام النسخة المكتوبة بلغة Go مباشرة لتقليل صعوبة مراجعة الكود.
ظهرت مشاكل أكثر خطورة في الاجتماع التاسع والثمانين، حيث حدثت异常 في شبكة اختبار YOLO، ويشتبه في أن يكون السبب هو توقيع BLS، لكن مطورين EIP-2537 نفوا ذلك. الخبر الجيد هو أن عقد الإيداع المعتمد على EIP-2537 قد اكتمل تطويره تقريبًا، وهو في انتظار التدقيق.
الاجتماع التاسع والتسعين حدد موعد إطلاق ترقية برلين في يوليو. كما ناقش الاجتماع مسألة هيمنة Geth، حيث اقترح البعض تجميد تنفيذ EIP الحالي لتقليل تكاليف تطوير العملاء الآخرين.
أكّدت الاجتماع رقم 92 مرة أخرى أن EIP-2537 هو EIP المطلوب لترقية برلين.
في الاجتماع رقم 96، تأمل Matter Labs في تضمين EIP-2539 أيضًا في اختبار YOLO v2 والدخول في ترقية برلين. لكن مطوري Geth اعترضوا، معتقدين أن EIP-2537 لم يتم اختباره بشكل كامل بعد في Geth. في النهاية، تم اتخاذ القرار بعدم إضافة 2696 في ترقية برلين.
قررت الاجتماع 99 نقل EIP-2537 من شبكة اختبار YOLO v3 وترقية برلين، والسبب الرئيسي هو أنها استغرقت وقتًا طويلاً من المطورين الأساسيين، مما أثر على تطوير EIPs الأخرى. العامل الثانوي هو أن مؤسسة إثيريوم اقترحت EVM384 كبديل.
في أبريل 2021، أكملت إثيريوم ترقية برلين، وكانت التطبيقات الفعلية مثل EIP-2565 التي تحتويها الأساسية ليست معقدة، مما جعل الترقية تبدو ضعيفة، وذلك لأن EIP-2537 المعقدة الأساسية تم استبعادها.
! [مراقبة حوكمة Ethereum: رحلة ما قبل التجميع EIP-2537](https://img-cdn.gateio.im/webp-social/moments-3198079b11f21298df05682606409838.webp019283746574839201
التطورات المستقبلية
أدخلت ترقية لندن التي تلت ترقية برلين EIP-1559. بالنسبة لـ EIP-2537 الذي كان مقترحًا أساسيًا، يصعب إدراجه في الترقيات اللاحقة.
تحديث لندن قيد التنفيذ، حيث نظر المطورون في إضافة EIP-2537. تمت مزامنة حالة تطوير EIP-2537 في الاجتماع رقم 109، وتم مناقشة مشكلة استخدام الغاز، حيث اقترح البعض استبدال EIP-2537 بـ EVM384. ولكن في الاجتماع رقم 111، تم إزالة EIP-2537 من تحديث لندن بسبب التعقيد. السبب الرئيسي هو أن تنفيذ معيار EIP-2537 قد غير المكتبات المعتمدة، مما أدى إلى احتمال تغيير تسعير الغاز، حيث تحتاج كل عميل إلى إعادة تقييم استهلاك الغاز.
تم اقتراح تضمين EIP-2537 في ترقية شنغهاي رسميًا في يونيو 2021. لكن ترقية الدمج استغرقت وقتًا كبيرًا من المطورين. بعد اكتمال الدمج في سبتمبر 2022، كان لدى مطوري الطبقة التنفيذية الفرصة لمواصلة مناقشة أهداف ترقية شنغهاي.
في نوفمبر 2022، ناقشت الجلسة رقم 150 لفترة قصيرة ما إذا كان ينبغي إدخال EIP-2537 في ترقية شنغهاي، لكن تم اعتبار أنه يجب تأجيل ذلك، حيث كانت النقطة الأساسية لترقية شنغهاي هي دعم سحب PoS. في النهاية، لم يتم إدخال EIP-2537 لتحقيق الوظيفة الأساسية للسحب في ترقية شنغهاي.
لم يتم مناقشة ترقية كانكون EIP-2537 حتى الآن، لأن جوهرها هو دعم EIP-4844، لتوفير طبقة بيانات Blob القابلة للاستخدام للطبقة الثانية.
في فبراير 2024، ناقشت الاجتماع 181 إدراج EIP-2537 في ترقية Pectra، واعتبرت أن التنفيذ لم يعد مشكلة، فقط توجد مشكلة في تسعير استهلاك الغاز.
في اجتماع 19 ديسمبر 2024، أكد مطورو Nethermind نموذج التسعير لـ EIP-2537 في الاجتماع رقم 202. كان الاقتراح الأصلي من Matter Labs والذي كان قد انسحب تقريبًا من المناقشة في ذلك الوقت. في الاجتماع رقم 203 في يناير 2025، تم مناقشة إعادة تسعير BLS المسبق، واقترح مطورو Geth زيادة تكلفة الغاز بنسبة 20%، وحصلوا على دعم من فريق Besu للاختبارات المرجعية.
! [مراقبة حوكمة Ethereum: رحلة ما قبل التجميع EIP-2537])https://img-cdn.gateio.im/webp-social/moments-75338d7a495f20ef25a70cca21a48381.webp(
ملخص
يمكن تلخيص تاريخ تطوير EIP-2537 كما يلي:
فبراير 2020: تم تقديم EIP-1962 بشكل رسمي و تم تقسيم EIP-2537
أبريل 2020 - أكتوبر: تم مناقشة مشاكل التنفيذ عدة مرات، وفي النهاية تم التخلي عن ترقية برلين بسبب عدم القدرة على التنفيذ
مارس-أبريل 2021: تم مناقشة مشكلة تكلفة الغاز، وتم التخلي عنها بسبب التعقيد في ترقية لندن.
نوفمبر 2022: مناقشة ما إذا كان يجب تضمين ترقية شانغهاي، دون جدوى
فبراير 2024: يعتقد أن التنفيذ لا مشكلة فيه، لا يزال هناك مشكلة تكاليف الغاز، يمكن تضمينه في ترقية Pectra
ديسمبر 2024 - يناير 2025: مناقشة نموذج التكلفة المحدد، وحل مشكلة التكلفة رسميًا
يمكن أن تعتمد EIP على تحسينات إثيريوم، وهذا يعتمد على الجهود الذاتية، وكذلك على الاعتبار التاريخي. كل ترقية لها موضوع، كانت EIP-2537 محور ترقية برلين، لكنها ألغيت بسبب تعقيدها. بعد ذلك، ركز إثيريوم على PoS، ولم تحظَ EIP الخاصة بطبقة التنفيذ النقي بالاهتمام، مما أدى إلى عدم قبول EIP-2537 لفترة طويلة. حتى مؤخرًا، بدأ المطورون في إعادة التركيز وحل المشاكل المتبقية.
! [مراقبة حوكمة Ethereum: رحلة ما قبل التجميع EIP-2537])https://img-cdn.gateio.im/webp-social/moments-55d3bb1142078f459d3a41ead42cd599.webp019283746574839201
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 25
أعجبني
25
8
إعادة النشر
مشاركة
تعليق
0/400
DefiPlaybook
· منذ 10 س
مشروع أسطوري آخر لمدة 5 سنوات، هل تحتاج إلى شيء؟
شاهد النسخة الأصليةرد0
LayerZeroHero
· منذ 10 س
لقد مرت خمس سنوات ولم يتم إطلاق الشبكة الرئيسية بعد، ما الذي يجري؟
شاهد النسخة الأصليةرد0
SchrodingerAirdrop
· منذ 13 س
ماذا يحدث إذا كنت تسير ببطء؟ الترقية المستقرة ليست أفضل من الصراخ بسرعة.
شاهد النسخة الأصليةرد0
UncleLiquidation
· 08-09 22:46
خمس سنوات حتى بدأ، إثيريوم وتيرة التطوير بطيئة حقًا
شاهد النسخة الأصليةرد0
Anon32942
· 08-09 22:45
لقد انتظرت خمس سنوات، وآخر شيء هو تقلب الأسعار.
شاهد النسخة الأصليةرد0
GasWrangler
· 08-09 22:39
في الواقع استغرقهم 5 سنوات لتحسين شيء رياضي بسيط كهذا... أتحسر على عدم الكفاءة في الطبقة الأولى
إثيريوم BLS precompiled instruction EIP-2537 بعد 5 سنوات تم اعتماده أخيرًا
EIP-2537: الطريق الطويل لتعليمات التجميع BLS12-381 في إثيريوم
EIP-2537 هو التعليمات البرمجية المسبقة لـ EVM التي تم تحديدها للإضافة في آخر ترقية للانقسام Pectra. تضيف هذه التعليمات البرمجية وظائف حسابية متعددة لمنحنى BLS12-381 لـ EVM، بما في ذلك حسابات الاقتران على مجال المنحنى.
تم تقديم EIP-2573 لأول مرة في عام 2020، ولم يتم التأكيد على إدراجه في ترقية إثيريوم حتى عام 2025. ستتناول هذه المقالة مسار حوكمة EIP-2537، وتستكشف لماذا استغرق هذا الاقتراح 5 سنوات ليتم تضمينه أخيرًا في الترقية.
خلفية الاقتراح
في يناير 2017، قدم فيتاليك بوتيرين لأول مرة خوارزمية الاقتران ومنحنى alt_bn128. بعد ذلك، اقترح فيتاليك وكريستيان ريتفايسنر EIP-196 وEIP-197، لإضافة دعم حساب منحنى alt_bn128 إلى EVM. تم اعتماد هذه الاقتراحات رسميًا في ترقية بيزنطium في أكتوبر 2017، مما أدى إلى تنفيذ حساب الاقتران في مجال المنحنى داخل EVM، مما يتيح التحقق من إثبات ZK-Snarks داخل EVM.
مع تطور علم التشفير، قدم فريق zcash في نوفمبر 2017 منحنى BLS12-381. مقارنةً بـ alt_bn128، يتمتع BLS12-381 بمزيد من الأمان وأداء أفضل. بدأت العديد من بروتوكولات blockchain في استخدام منحنى BLS12-381 بدلاً من منحنى alt_bn128.
في مايو 2018، أشار جاستن دريك إلى أن ترقية PoS والشظايا المستقبلية لإثيريوم يمكن أن تستخدم خوارزمية التوقيع المتعدد BLS المستندة إلى منحنى BLS12-381. وهذا جعل خطة EIP-1011 الأصلية تخرج من المسرح التاريخي. وقد ثبت أن ترقية ETH2 اللاحقة قد اعتمدت بالفعل منحنى BLS12-381.
مع تطوير ETH2، تزداد الدعوات لإدخال BLS12-381 في طبقة تنفيذ ETH. في فبراير 2020، اقترح الباحثون EIP-2537، على أمل أن يتم قبول هذا الاقتراح للاختبار مع شبكة اختبار ETH2. دعا مؤلف EIP-2537 أليكس ستوكز إلى إدراج EIP-2537 في الانقسام الصلب Berlin.
من الجدير بالذكر أن مؤلف 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-1962، حيث ورثت بعض منها واجهته. تشمل هذه EIP:
من بين هذه، يعد EIP-2537 الأهم، لأنه يستخدم أيضًا منحنى BLS12-381 في طبقة الإجماع. الهدف الأساسي من EIP-1962 و EIP-2537 هو تحقيق التحقق من توقيع BLS في طبقة الإجماع على الشبكة الرئيسية. في ذلك الوقت، كانت ETH2 تصمم عقد الإيداع، وبما أن طبقة التنفيذ لا تحتوي على خوارزمية تحقق BLS، فلن يقوم عقد الإيداع بالتحقق من التوقيع، وسيتم التحقق من توقيع BLS المحدد بواسطة طبقة الإجماع بعد إيداع المستخدم، وإذا تم اكتشاف خطأ، فقد يؤدي ذلك إلى فقدان أموال المستخدم.
في هذا السياق، يأمل المطورون الأساسيون في إدخال BLS12-381 كمكون مسبق البرمجة في عقد الإيداع لتحقيق التحقق من التوقيع، لتجنب الخسائر المحتملة لأموال المستخدمين في ETH2. كان هذا هو السبب وراء اهتمام العديد من المطورين بـ EIP-1962 و EIP-2537 آنذاك.
بعد تقديم EIP-2537، أشار فيتاليك على الفور إلى مجموعة من القضايا، التي تركزت بشكل رئيسي على محتوى وثيقة EIP. ثم قام مؤلفو EIP بالرد والمناقشة. في اجتماع مطوري النواة في 6 مارس 2020، اعتبر فيتاليك أن EIP-2537 وEIPs الأخرى فعالة جدًا في إثبات SNARK التكراري، وأنها على المدى الطويل لن تضر بإيثيريوم. وأكد الاجتماع على أولوية EIP-2537، حيث اتفقت جميع العملاء على تنفيذها في أقرب وقت ممكن وتخطط لإكمال التطوير قبل ترقية برلين.
بعد ذلك، أصبحت EIP-2537 مهمة ذات أولوية عالية. أكدت اجتماع 20 مارس أن EIP-2537 ستستبدل EIP-1962 لتصبح الاقتراح الرئيسي لـ BLS، ودخلت قائمة الترشيحات لترقية برلين. في اجتماع أبريل، تم إدراج EIP-2537 رسميًا في ترقية الشوكة الصلبة لبرلين، وتم تحديد الجدول الزمني للتنفيذ في أبريل والاختبار في مايو-يونيو، وتم تصنيفها كأعلى أولوية.
بعد ذلك، دخل EIP-2537 في مرحلة تطوير واختبار كبيرة، حيث تم مناقشته في حوالي 20 اجتماعًا للمطورين الأساسيين.
في الاجتماع الخامس والثمانين، ناقش المطورون مشكلة ترميز ABI لـ EIP-2537. قالت عميل Besu إنها نفذت الوظيفة بشكل أساسي، لكن فريق Geth قال إنه لم يقم أحد بعد بأي عمل ذي صلة.
في الاجتماع رقم 86، ذكرت Geth أنها أكملت جزءًا من العمل، لكن لا يزال هناك الكثير من العمل الذي يتعين القيام به.
تناقش الاجتماع رقم 87 بشكل أساسي مشكلة تنفيذ EIP-2537. وأشار مطورو Geth إلى وجود PR مكون من 16000 سطر لتنفيذ EIP-2537، لكن لا يمكن تحديد سلامته وفعاليته، ولا يمكن إلا الحكم عليه من خلال اختبارات الضبابية البسيطة. يعتقد مطورو Geth أنه لا يمكنهم إكمال تطوير EIP-2537 قبل الموعد المحدد في برلين.
قررت الاجتماع زيادة اختبار شبكة YOLO لاختبار EIP-2537 بشكل خاص. في هذا الوقت، انخفضت أهمية EIP-2537 بشكل كبير، ويعتقد مطورو Geth أن هذا EIP من المحتمل ألا يتم تضمينه في ترقية برلين.
في الاجتماع الثامن والثمانين، اكتشف مطورو Geth أن تنفيذ PR لـ EIP-2537 يعاني من مجموعة من المشكلات التي تحتاج إلى مزيد من الاختبار والإصلاح. يوجد في نظام Geth تنفيذان لـ EIP-2537، أحدهما يحتوي على تحسينات تجميعية، والآخر مكتوب بالكامل بلغة Go، وقد اقترح البعض استخدام النسخة المكتوبة بلغة Go مباشرة لتقليل صعوبة مراجعة الكود.
ظهرت مشاكل أكثر خطورة في الاجتماع التاسع والثمانين، حيث حدثت异常 في شبكة اختبار YOLO، ويشتبه في أن يكون السبب هو توقيع BLS، لكن مطورين EIP-2537 نفوا ذلك. الخبر الجيد هو أن عقد الإيداع المعتمد على EIP-2537 قد اكتمل تطويره تقريبًا، وهو في انتظار التدقيق.
الاجتماع التاسع والتسعين حدد موعد إطلاق ترقية برلين في يوليو. كما ناقش الاجتماع مسألة هيمنة Geth، حيث اقترح البعض تجميد تنفيذ EIP الحالي لتقليل تكاليف تطوير العملاء الآخرين.
أكّدت الاجتماع رقم 92 مرة أخرى أن EIP-2537 هو EIP المطلوب لترقية برلين.
في الاجتماع رقم 96، تأمل Matter Labs في تضمين EIP-2539 أيضًا في اختبار YOLO v2 والدخول في ترقية برلين. لكن مطوري Geth اعترضوا، معتقدين أن EIP-2537 لم يتم اختباره بشكل كامل بعد في Geth. في النهاية، تم اتخاذ القرار بعدم إضافة 2696 في ترقية برلين.
قررت الاجتماع 99 نقل EIP-2537 من شبكة اختبار YOLO v3 وترقية برلين، والسبب الرئيسي هو أنها استغرقت وقتًا طويلاً من المطورين الأساسيين، مما أثر على تطوير EIPs الأخرى. العامل الثانوي هو أن مؤسسة إثيريوم اقترحت EVM384 كبديل.
في أبريل 2021، أكملت إثيريوم ترقية برلين، وكانت التطبيقات الفعلية مثل EIP-2565 التي تحتويها الأساسية ليست معقدة، مما جعل الترقية تبدو ضعيفة، وذلك لأن EIP-2537 المعقدة الأساسية تم استبعادها.
! [مراقبة حوكمة Ethereum: رحلة ما قبل التجميع EIP-2537](https://img-cdn.gateio.im/webp-social/moments-3198079b11f21298df05682606409838.webp019283746574839201
التطورات المستقبلية
أدخلت ترقية لندن التي تلت ترقية برلين EIP-1559. بالنسبة لـ EIP-2537 الذي كان مقترحًا أساسيًا، يصعب إدراجه في الترقيات اللاحقة.
تحديث لندن قيد التنفيذ، حيث نظر المطورون في إضافة EIP-2537. تمت مزامنة حالة تطوير EIP-2537 في الاجتماع رقم 109، وتم مناقشة مشكلة استخدام الغاز، حيث اقترح البعض استبدال EIP-2537 بـ EVM384. ولكن في الاجتماع رقم 111، تم إزالة EIP-2537 من تحديث لندن بسبب التعقيد. السبب الرئيسي هو أن تنفيذ معيار EIP-2537 قد غير المكتبات المعتمدة، مما أدى إلى احتمال تغيير تسعير الغاز، حيث تحتاج كل عميل إلى إعادة تقييم استهلاك الغاز.
تم اقتراح تضمين EIP-2537 في ترقية شنغهاي رسميًا في يونيو 2021. لكن ترقية الدمج استغرقت وقتًا كبيرًا من المطورين. بعد اكتمال الدمج في سبتمبر 2022، كان لدى مطوري الطبقة التنفيذية الفرصة لمواصلة مناقشة أهداف ترقية شنغهاي.
في نوفمبر 2022، ناقشت الجلسة رقم 150 لفترة قصيرة ما إذا كان ينبغي إدخال EIP-2537 في ترقية شنغهاي، لكن تم اعتبار أنه يجب تأجيل ذلك، حيث كانت النقطة الأساسية لترقية شنغهاي هي دعم سحب PoS. في النهاية، لم يتم إدخال EIP-2537 لتحقيق الوظيفة الأساسية للسحب في ترقية شنغهاي.
لم يتم مناقشة ترقية كانكون EIP-2537 حتى الآن، لأن جوهرها هو دعم EIP-4844، لتوفير طبقة بيانات Blob القابلة للاستخدام للطبقة الثانية.
في فبراير 2024، ناقشت الاجتماع 181 إدراج EIP-2537 في ترقية Pectra، واعتبرت أن التنفيذ لم يعد مشكلة، فقط توجد مشكلة في تسعير استهلاك الغاز.
في اجتماع 19 ديسمبر 2024، أكد مطورو Nethermind نموذج التسعير لـ EIP-2537 في الاجتماع رقم 202. كان الاقتراح الأصلي من Matter Labs والذي كان قد انسحب تقريبًا من المناقشة في ذلك الوقت. في الاجتماع رقم 203 في يناير 2025، تم مناقشة إعادة تسعير BLS المسبق، واقترح مطورو Geth زيادة تكلفة الغاز بنسبة 20%، وحصلوا على دعم من فريق Besu للاختبارات المرجعية.
! [مراقبة حوكمة Ethereum: رحلة ما قبل التجميع EIP-2537])https://img-cdn.gateio.im/webp-social/moments-75338d7a495f20ef25a70cca21a48381.webp(
ملخص
يمكن تلخيص تاريخ تطوير EIP-2537 كما يلي:
يمكن أن تعتمد EIP على تحسينات إثيريوم، وهذا يعتمد على الجهود الذاتية، وكذلك على الاعتبار التاريخي. كل ترقية لها موضوع، كانت EIP-2537 محور ترقية برلين، لكنها ألغيت بسبب تعقيدها. بعد ذلك، ركز إثيريوم على PoS، ولم تحظَ EIP الخاصة بطبقة التنفيذ النقي بالاهتمام، مما أدى إلى عدم قبول EIP-2537 لفترة طويلة. حتى مؤخرًا، بدأ المطورون في إعادة التركيز وحل المشاكل المتبقية.
! [مراقبة حوكمة Ethereum: رحلة ما قبل التجميع EIP-2537])https://img-cdn.gateio.im/webp-social/moments-55d3bb1142078f459d3a41ead42cd599.webp019283746574839201