EIP-2537 هو أمر تجميع مسبق لـ EVM تم تحديده لإضافته في ترقية Pectra الجديدة لإيثيريوم. يضيف هذا الأمر وظائف حسابية متعددة على منحنى BLS12-381 لـ EVM، مثل حسابات الاقتران على نطاق المنحنى.
تم اقتراح EIP-2537 لأول مرة في عام 2020، ولم يتم تأكيده كجزء من ترقية الإيثريوم حتى عام 2025. ستستعرض هذه المقالة تاريخ حوكمة EIP-2537، وتستكشف سبب استغراق هذا الاقتراح 5 سنوات ليتم اعتماده في النهاية.
خلفية الاقتراح
في يناير 2017، قدم فيتالك بوتيرين لأول مرة خوارزمية الاقتران ومنحنى alt_bn128 في مقال. بعد ذلك، اقترح فيتالك وكريستيان رايتفايسنر EIP-196 وEIP-197، مما يقترح إضافة دعم حسابات منحنى alt_bn128 إلى EVM.
في أكتوبر 2017، تم تقديم ترقية بيزنطية بشكل رسمي والتي أدخلت منحنى alt_bn128، مما سمح بحسابات الاقتران في مجال المنحنى داخل EVM، مما يجعل التحقق من إثباتات ZK-Snarks ممكنًا داخل EVM.
ومع تطور التشفير، قدم فريق تطوير زكاش في نوفمبر 2017 منحنى BLS12-381. مقارنةً بـ alt_bn128، يتمتع BLS12-381 بأمان أعلى وأداء أفضل. اعتمدت العديد من بروتوكولات بلوكتشين لاحقًا منحنى BLS12-381، متخلية عن alt_bn128.
في مايو 2018، نشر جاستين دريك مقالاً يشير إلى أن ترقية PoS وتقسيم الإيثيريوم في المستقبل يمكن أن تستخدم خوارزمية التوقيع المتعدد BLS المستندة إلى منحنى BLS12-381. هذه الخطة تحل مشكلة العدد المحدود من المدققين في خطط PoS السابقة. وقد ثبت أن ترقية ETH2 اللاحقة قد اعتمدت بالفعل منحنى BLS12-381.
مع تقدم تطوير ETH2، تزداد الأصوات المطالبة بإدخال BLS12-381 إلى طبقة تنفيذ ETH. في فبراير 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 عدة EIPs لتقسيم EIP-1962، حيث ورثت هذه EIPs جزئيًا واجهة EIP-1962:
EIP-2537 يدعم BLS12-381
EIP-2539 يوفر دعم BLS12-377
PR#2541 يوفر دعم منحنى BLS12-377(Zexe )، لكن الاقتراح لم يحصل في النهاية على رقم EIP.
ومن أهمها EIP-2537، لأن طبقة الإجماع تستخدم أيضًا منحنى BLS12-381. الهدف الأساسي من EIP-1962 و EIP-2537 هو تحقيق التحقق من توقيع BLS في طبقة الإجماع على الشبكة الرئيسية. في ذلك الوقت، كانت ETH2 تطور عقد إيداع طبقة الإجماع. في التصميم الأولي، وبما أن طبقة التنفيذ لا تحتوي على خوارزمية التحقق من BLS، فلن يتم التحقق من التوقيع في عقد الإيداع، وسيتم التحقق من التوقيع BLS المحدد من قبل طبقة الإجماع بعد إيداع المستخدم، وإذا تم اكتشاف عدم صحة، فسيفشل الإيداع، وقد تفقد ETH التي أودعها المستخدم.
في هذا السياق، يأمل المطورون الرئيسيون في إدخال BLS12-381 كترجمة مسبقة لتنفيذ التحقق من التوقيع في عقد الإيداع، لتجنب فقدان أموال المستخدمين. وكانت هذه أيضًا هي السبب وراء اهتمام العديد من المطورين بـ EIP-1962 و EIP-2537 في ذلك الوقت.
عندما تم تقديم EIP-2537 ، أشار فيتاليك إلى مجموعة من المشكلات المتعلقة بالاقتراح. كانت هذه الشكوك تتركز بشكل أساسي على محتوى وثيقة EIP ، وبعد ذلك رد مؤلفو EIP على ذلك وناقشوه.
عقدت الاجتماع رقم 82 لمطوري إيثريوم الأساسيين في 6 مارس 2020 لمناقشة EIP-2537. اعتقد فيتالك أن هذا الـ EIP فعال جداً لإثباتات SNARK التكرارية، وأنه على المدى الطويل لن يؤثر سلباً على إيثريوم. أكد الاجتماع على أولوية EIP-2537، حيث اتفقت جميع العملاء على تنفيذ هذا الـ EIP في أسرع وقت ممكن وتخطط لإكمال جميع التطويرات قبل ترقية برلين.
بعد ذلك، أصبحت EIP-2537 مهمة ذات أولوية أعلى. في الاجتماع الثالث والثمانين لمطوري النواة في 20 مارس، تم مناقشة الاقتراح كأولوية رئيسية مرة أخرى. أكد الاجتماع أن EIP-2537 سيحل محل EIP-1962 ليصبح الاقتراح الأساسي لـ BLS، وتم إدراجه في قائمة الترشيحات لترقية برلين.
عُقد الاجتماع الرابع والثمانون في أبريل رسميًا لإدراج EIP-2537 في ترقية الانقسام الصلب برلين، وتم تحديد الجدول الزمني لتحقيق ذلك في أبريل واختباره في مايو ويونيو. ومن الجدير بالذكر أن EIP-2537 تم تصنيفه في هذه المناقشة كأولوية قصوى.
بعد ذلك، دخل EIP-2537 في مرحلة تطوير واختبار كبيرة، حيث تم مناقشة الموضوع في كل اجتماع من الاجتماعات الأساسية التي بلغت نحو 20 اجتماعًا.
في الاجتماع الخامس والثمانين، ناقش المطورون قضية ترميز ABI لـ EIP-2537. نظرًا لأن Matter Labs قد أكملت تقريبًا تنفيذ النسخة Rust، فقد ذكرت عميل Besu أنها قد نفذت تقريبًا وظيفة EIP-2537، لكن جانب Geth قال إنه لا يوجد حاليًا أي شخص يعمل على هذا الموضوع.
في الاجتماع السادس والثمانين، تم تحقيق مزامنة جديدة لتقدم EIP-2537 بين العقد المختلفة. أفاد Geth بأنه أكمل جزءًا من العمل، لكن لا يزال هناك الكثير من المهام التي يجب إنجازها.
ناقشت الاجتماع رقم 87 بشكل رئيسي قضايا تنفيذ EIP-2537. أشار مطورو Geth إلى وجود PR يحتوي على 16000 سطر لتنفيذ EIP-2537، لكن لم يكن من الممكن التأكد مما إذا كان هذا PR قد نفذ EIP-2537 بشكل آمن وفعال، ويمكن فقط الحكم على حالة الشيفرة من خلال أبسط اختبارات الضبابية.
قال مطور Geth: "بحدس مني، من غير الممكن أن يكون Geth جاهزًا لتشغيل منحنى BLS قبل إطلاق الشبكة الرئيسية في يوليو."
اقترح هادسون جيمسون العثور على مهندس تشفير لمساعدة في مراجعة PR لـ Geth، واقترح استخدام شبكة الاختبار لاختبار أمان تنفيذ EIP-2537. نظرًا لأن فريق تطوير ETH2 يعمل أيضًا على تنفيذ التحقق من توقيع BLS، يمكنهم المشاركة في الاختبار.
من الضروري الإشارة إلى أن تنفيذ EIP-2537 في Geth يستخدم الكثير من شفرة التجميع لضمان الكفاءة، وهذه الشفرة صعبة للغاية في القراءة والفهم. اقترح ألكس فلاسوف إزالة التحسينات المعقدة في الشفرة لتقليل صعوبة المراجعة.
الهدف الأساسي من EIP-2537 هو مساعدة عقد إيداع ETH2، لكن مطوري عقد الإيداع الذين حضروا الاجتماع قالوا إن العقد الذي لا يستخدم EIP-2537 قد تم تدقيقه، ويعتقد بعض المطورين أنه من الأفضل عدم إصدار نسخة جديدة من العقد تستخدم EIP-2537.
في النهاية، قررت الاجتماع زيادة شبكة اختبار YOLO، المخصصة لاختبار EIP-2537. في الواقع، من خلال هذا الاجتماع يمكن أن نرى أنه مع الانتهاء من عقد الإيداع، انخفضت أهمية EIP-2537 بشكل كبير، وفي نفس الوقت يعتبر مطورو Geth أن هذا EIP من المحتمل جداً ألا يتم تنفيذه قبل ترقية Berlin. يبدو أن عدم اعتماد EIP-2537 في ترقية Berlin أصبح أمراً محسوماً.
في الاجتماع رقم 88، اكتشف مطورو Geth أن تنفيذ PR الخاص بـ EIP-2537 يعاني من مجموعة من المشكلات، وأشاروا إلى الحاجة إلى مزيد من الاختبارات والإصلاحات. في هذه الأثناء، يوجد في نظام Geth تنفيذان لـ EIP-2537، أحدهما يتضمن تحسينات تجميعية، والآخر مكتوب بالكامل بلغة Go. اقترح بعض المطورين استخدام النسخة المكتوبة بلغة Go مباشرةً لتقليل صعوبة مراجعة الكود.
في الاجتماع رقم 89 ظهرت مشاكل أكثر خطورة، حيث ظهرت بعض الشواذ على شبكة اختبار YOLO، ويشتبه المطورون في أن السبب هو توقيع BLS، لكن مطورو EIP-2537 ردوا على ذلك. الخبر الجيد هو أن عقد الودائع المستند إلى EIP-2537 قد اكتمل تطويره بشكل أساسي، وهو في انتظار التدقيق.
حدد الاجتماع التاسع والتسعين الموعد النهائي لإطلاق ترقية برلين في يوليو. كما ناقش الاجتماع قضية تنوع العملاء، والتي تتعلق بشكل رئيسي بسيطرة Geth، حيث اقترح بعض المطورين تجميد التنفيذ الحالي لـ EIP لتقليل تكاليف تطوير العملاء الآخرين. في الاجتماع التسعين، اقترح بعض المطورين استخدام خطة معيارية لتقليل تكاليف التطوير وزيادة تنوع العملاء.
تم التأكيد على EIP-2537 كـ EIP المطلوب لترقية برلين في الاجتماع رقم 92.
في الاجتماع السادس والتسعين، بسبب أن Celo قد دمجت EIP-2537 وEIP-2539 في نفس الوقت في عملية الشوكة الصلبة لشبكتها، تأمل Matter Labs في وضع EIP-2539 أيضًا في اختبار YOLO v2 والدخول في ترقية برلين. لكن مطورو Geth عارضوا، معتبرين أن EIP-2537 لم يتم اختباره بشكل كامل في Geth بعد. في النهاية، قررت الاجتماع عدم إضافة EIP-2696 في ترقية برلين، وترك الأمر للنقاش في المستقبل.
قررت الاجتماع التاسع والتسعين نقل EIP-2537 من شبكة اختبار YOLO v3 وترقية Berlin، وكان السبب الرئيسي هو أن EIP-2537 استهلك الكثير من وقت المطورين الرئيسيين، مما أدى إلى عرقلة تطوير EIPs الأخرى لترقية Berlin. والعامل الثانوي هو أن مؤسسة Ethereum اقترحت EVM384 كبديل لـ EIP-2537، حيث تقدم حلاً أكثر عمومية لحسابات المنحنيات الإهليلجية. لكن المطورين الرئيسيين أعربوا عن مخاوفهم بشأن مسائل الأمان.
هذه هي المسيرة المبكرة لـ EIP-2537. يمكننا أن نرى أن EIP-2537 كان في البداية واحدًا من أهم EIP في ترقية برلين، ولكن تم التخلي عنه في نهاية المطاف بسبب مشاكل في التنفيذ. في أبريل 2021، أكملت الإيثيريوم ترقية برلين، لم تكن EIPs الأساسية مثل EIP-2565 معقدة في التنفيذ فعليًا، وبدت الترقية ضعيفة بعض الشيء، وذلك لأن EIP-2537 المعقدة في جوهرها تم استبعادها.
التطورات المستقبلية
كما هو معروف، كل ترقية للإيثريوم تأتي مع اقتراح أساسي. الترقية من برلين إلى لندن أدخلت أهم اقتراح لرسوم الإيثريوم في التاريخ EIP-1559. بالنسبة للاقتراح الأساسي السابق EIP-2537، سيكون من الصعب إدخاله في التحديثات اللاحقة.
تمت ترقية لندن بعد برلين ، حيث نظر المطورون في المسألة #369 في إضافة EIP-2537. تم تحديث حالة تطوير EIP-2537 في الاجتماع رقم 109 لمطوري النواة، وبسبب استخدام مكتبات أخرى في التنفيذ، أثار ذلك مناقشات حول استخدام الغاز. اقترح أحد المطورين استبدال EIP-2537 بـ EVM384. ولكن في الاجتماع رقم 111 في أبريل 2021، تم استبعاد EIP-2537 من ترقية لندن بسبب تعقيده. السبب الرئيسي هو أن التنفيذ القياسي لـ EIP-2537 غير مكتبة الاعتماد، مما أدى إلى احتمال تغيير تسعير الغاز، حيث يتطلب تنفيذ العملاء المختلفين وقتًا طويلاً لإعادة تقييم استهلاك الغاز.
في يونيو 2021، تم تقديم المسألة #343 رسميًا لإدراج EIP-2537 في ترقية شانغهاي. لكن بعد ترقية لندن، استحوذ الدمج على الكثير من وقت المطورين، حيث كان على مطوري الطبقة التنفيذية كتابة الكثير من الشفرات لتنفيذ ترقية PoS. في سبتمبر 2022، بعد الانتهاء من الدمج، أصبح لمطوري الطبقة التنفيذية الفرصة لمواصلة مناقشة أهداف ترقية شانغهاي.
في نوفمبر 2022، تم مناقشة باختصار في الاجتماع الـ 150 لمطوري النواة ما إذا كان يجب تضمين EIP-2537 في Shanghai، لكن المطورين اعتبروا أنه يجب تأجيل ذلك، حيث أن جوهر Shanghai هو دعم سحب PoS. في النهاية، لم يتم تضمين EIP-2537 لتحقيق ترقية Shanghai التي تركز على السحب.
للأسف، لم يتم مناقشة ترقية كانكون EIP-2537، لأن التركيز في كانكون هو دعم EIP-4844، لتوفير Blob للطبقة الثانية من إيثيريوم لاستخدام إيثيريوم كطبقة توفر البيانات.
حتى الاجتماع رقم 181 للمطورين الأساسيين في فبراير 2024، لم يناقش المطورون تضمين EIP-2537 في ترقية Pectra. في ذلك الوقت، اعتقد المطورون أن تنفيذ EIP-2537 لم يعد مشكلة، فقط بعض مسائل تسعير استهلاك الغاز تحتاج إلى حل.
في الاجتماع رقم 202 الذي عُقد في 19 ديسمبر 2024 ، حدد مطورو Nethermind أخيرًا نموذج تسعير EIP-2537. من الجدير بالذكر أن Matter Labs ، مقدمة الاقتراح الأصلي لـ EIP-2537 ، قد انسحبت تقريبًا من المناقشات في هذا الوقت. ناقش الاجتماع رقم 203 في يناير 2025 إعادة تسعير BLS Precompile ، حيث اقترح مطور Geth Jared Wasinger زيادة تكلفة الغاز بنسبة 20% ، وحصل على دعم من فريق Besu في الاختبارات المرجعية.
ملخص
مرت عملية اعتماد EIP-2537 منذ تقديمه حتى اعتماده النهائي بمرحلة طويلة ومتعرجة:
فبراير 2020: تم اقتراح EIP-2537 رسمياً كفصل من EIP-1962
أبريل - أكتوبر 2020: مناقشات متعددة حول مشاكل التنفيذ، في النهاية تم التخلي عن الترقية إلى برلين بسبب عدم إمكانية التنفيذ
مارس-أبريل 2021: مناقشة مشكلة تكاليف الغاز، تم التخلي عنها بسبب التعقيد في ترقية لندن
نوفمبر 2022: مناقشة ما إذا كان سيتم تضمين ترقية Shanghai، ولكن دون جدوى
فبراير 2024: يعتبر تحقيق ذلك لم يعد مشكلة، لا تزال هناك بعض مشاكل تكاليف الغاز، يمكن تضمينها في ترقية Pectra
ديسمبر 2024 - يناير 2025: مناقشة نموذج حساب التكاليف المحددة، وحل تكلفة الغاز رسميًا
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 12
أعجبني
12
6
مشاركة
تعليق
0/400
StableGenius
· 08-03 06:12
من الناحية التجريبية، استغرق الأمر منهم 5 سنوات للقيام بما كان ينبغي أن يتم في 6 أشهر. مسرحية حوكمة الإيث الكلاسيكية
شاهد النسخة الأصليةرد0
RugResistant
· 08-01 07:29
حللنا eip. الأعلام الحمراء المحتملة في تنفيذ bls تحتاج إلى تدقيق أعمق بصراحة
شاهد النسخة الأصليةرد0
NFTDreamer
· 08-01 07:29
واو، فيتاليك بوترين كان يريد فعل ذلك منذ فترة.
شاهد النسخة الأصليةرد0
TokenSleuth
· 08-01 07:29
آه، يجب الانتظار لخمس سنوات.. يكفي من المعاناة
شاهد النسخة الأصليةرد0
0xSunnyDay
· 08-01 07:14
5 سنوات في انتظار eip صعبة جداً
شاهد النسخة الأصليةرد0
LiquidityHunter
· 08-01 07:11
تاه إثيريوم هذا التحرك بطيء لدرجة أنني مللت من الانتظار
EIP-2537: ترقية إثيريوم الهامة التي استغرقت 5 سنوات من الجدل إلى الاعتماد
EIP-2537: الطريق الطويل من الجدل إلى الاعتماد
EIP-2537 هو أمر تجميع مسبق لـ EVM تم تحديده لإضافته في ترقية Pectra الجديدة لإيثيريوم. يضيف هذا الأمر وظائف حسابية متعددة على منحنى BLS12-381 لـ EVM، مثل حسابات الاقتران على نطاق المنحنى.
تم اقتراح EIP-2537 لأول مرة في عام 2020، ولم يتم تأكيده كجزء من ترقية الإيثريوم حتى عام 2025. ستستعرض هذه المقالة تاريخ حوكمة EIP-2537، وتستكشف سبب استغراق هذا الاقتراح 5 سنوات ليتم اعتماده في النهاية.
خلفية الاقتراح
في يناير 2017، قدم فيتالك بوتيرين لأول مرة خوارزمية الاقتران ومنحنى alt_bn128 في مقال. بعد ذلك، اقترح فيتالك وكريستيان رايتفايسنر EIP-196 وEIP-197، مما يقترح إضافة دعم حسابات منحنى alt_bn128 إلى EVM.
في أكتوبر 2017، تم تقديم ترقية بيزنطية بشكل رسمي والتي أدخلت منحنى alt_bn128، مما سمح بحسابات الاقتران في مجال المنحنى داخل EVM، مما يجعل التحقق من إثباتات ZK-Snarks ممكنًا داخل EVM.
ومع تطور التشفير، قدم فريق تطوير زكاش في نوفمبر 2017 منحنى BLS12-381. مقارنةً بـ alt_bn128، يتمتع BLS12-381 بأمان أعلى وأداء أفضل. اعتمدت العديد من بروتوكولات بلوكتشين لاحقًا منحنى BLS12-381، متخلية عن alt_bn128.
في مايو 2018، نشر جاستين دريك مقالاً يشير إلى أن ترقية PoS وتقسيم الإيثيريوم في المستقبل يمكن أن تستخدم خوارزمية التوقيع المتعدد BLS المستندة إلى منحنى BLS12-381. هذه الخطة تحل مشكلة العدد المحدود من المدققين في خطط PoS السابقة. وقد ثبت أن ترقية ETH2 اللاحقة قد اعتمدت بالفعل منحنى BLS12-381.
مع تقدم تطوير ETH2، تزداد الأصوات المطالبة بإدخال BLS12-381 إلى طبقة تنفيذ ETH. في فبراير 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 عدة EIPs لتقسيم EIP-1962، حيث ورثت هذه EIPs جزئيًا واجهة EIP-1962:
ومن أهمها EIP-2537، لأن طبقة الإجماع تستخدم أيضًا منحنى BLS12-381. الهدف الأساسي من EIP-1962 و EIP-2537 هو تحقيق التحقق من توقيع BLS في طبقة الإجماع على الشبكة الرئيسية. في ذلك الوقت، كانت ETH2 تطور عقد إيداع طبقة الإجماع. في التصميم الأولي، وبما أن طبقة التنفيذ لا تحتوي على خوارزمية التحقق من BLS، فلن يتم التحقق من التوقيع في عقد الإيداع، وسيتم التحقق من التوقيع BLS المحدد من قبل طبقة الإجماع بعد إيداع المستخدم، وإذا تم اكتشاف عدم صحة، فسيفشل الإيداع، وقد تفقد ETH التي أودعها المستخدم.
في هذا السياق، يأمل المطورون الرئيسيون في إدخال BLS12-381 كترجمة مسبقة لتنفيذ التحقق من التوقيع في عقد الإيداع، لتجنب فقدان أموال المستخدمين. وكانت هذه أيضًا هي السبب وراء اهتمام العديد من المطورين بـ EIP-1962 و EIP-2537 في ذلك الوقت.
عندما تم تقديم EIP-2537 ، أشار فيتاليك إلى مجموعة من المشكلات المتعلقة بالاقتراح. كانت هذه الشكوك تتركز بشكل أساسي على محتوى وثيقة EIP ، وبعد ذلك رد مؤلفو EIP على ذلك وناقشوه.
عقدت الاجتماع رقم 82 لمطوري إيثريوم الأساسيين في 6 مارس 2020 لمناقشة EIP-2537. اعتقد فيتالك أن هذا الـ EIP فعال جداً لإثباتات SNARK التكرارية، وأنه على المدى الطويل لن يؤثر سلباً على إيثريوم. أكد الاجتماع على أولوية EIP-2537، حيث اتفقت جميع العملاء على تنفيذ هذا الـ EIP في أسرع وقت ممكن وتخطط لإكمال جميع التطويرات قبل ترقية برلين.
بعد ذلك، أصبحت EIP-2537 مهمة ذات أولوية أعلى. في الاجتماع الثالث والثمانين لمطوري النواة في 20 مارس، تم مناقشة الاقتراح كأولوية رئيسية مرة أخرى. أكد الاجتماع أن EIP-2537 سيحل محل EIP-1962 ليصبح الاقتراح الأساسي لـ BLS، وتم إدراجه في قائمة الترشيحات لترقية برلين.
عُقد الاجتماع الرابع والثمانون في أبريل رسميًا لإدراج EIP-2537 في ترقية الانقسام الصلب برلين، وتم تحديد الجدول الزمني لتحقيق ذلك في أبريل واختباره في مايو ويونيو. ومن الجدير بالذكر أن EIP-2537 تم تصنيفه في هذه المناقشة كأولوية قصوى.
بعد ذلك، دخل EIP-2537 في مرحلة تطوير واختبار كبيرة، حيث تم مناقشة الموضوع في كل اجتماع من الاجتماعات الأساسية التي بلغت نحو 20 اجتماعًا.
في الاجتماع الخامس والثمانين، ناقش المطورون قضية ترميز ABI لـ EIP-2537. نظرًا لأن Matter Labs قد أكملت تقريبًا تنفيذ النسخة Rust، فقد ذكرت عميل Besu أنها قد نفذت تقريبًا وظيفة EIP-2537، لكن جانب Geth قال إنه لا يوجد حاليًا أي شخص يعمل على هذا الموضوع.
في الاجتماع السادس والثمانين، تم تحقيق مزامنة جديدة لتقدم EIP-2537 بين العقد المختلفة. أفاد Geth بأنه أكمل جزءًا من العمل، لكن لا يزال هناك الكثير من المهام التي يجب إنجازها.
ناقشت الاجتماع رقم 87 بشكل رئيسي قضايا تنفيذ EIP-2537. أشار مطورو Geth إلى وجود PR يحتوي على 16000 سطر لتنفيذ EIP-2537، لكن لم يكن من الممكن التأكد مما إذا كان هذا PR قد نفذ EIP-2537 بشكل آمن وفعال، ويمكن فقط الحكم على حالة الشيفرة من خلال أبسط اختبارات الضبابية.
قال مطور Geth: "بحدس مني، من غير الممكن أن يكون Geth جاهزًا لتشغيل منحنى BLS قبل إطلاق الشبكة الرئيسية في يوليو."
اقترح هادسون جيمسون العثور على مهندس تشفير لمساعدة في مراجعة PR لـ Geth، واقترح استخدام شبكة الاختبار لاختبار أمان تنفيذ EIP-2537. نظرًا لأن فريق تطوير ETH2 يعمل أيضًا على تنفيذ التحقق من توقيع BLS، يمكنهم المشاركة في الاختبار.
من الضروري الإشارة إلى أن تنفيذ EIP-2537 في Geth يستخدم الكثير من شفرة التجميع لضمان الكفاءة، وهذه الشفرة صعبة للغاية في القراءة والفهم. اقترح ألكس فلاسوف إزالة التحسينات المعقدة في الشفرة لتقليل صعوبة المراجعة.
الهدف الأساسي من EIP-2537 هو مساعدة عقد إيداع ETH2، لكن مطوري عقد الإيداع الذين حضروا الاجتماع قالوا إن العقد الذي لا يستخدم EIP-2537 قد تم تدقيقه، ويعتقد بعض المطورين أنه من الأفضل عدم إصدار نسخة جديدة من العقد تستخدم EIP-2537.
في النهاية، قررت الاجتماع زيادة شبكة اختبار YOLO، المخصصة لاختبار EIP-2537. في الواقع، من خلال هذا الاجتماع يمكن أن نرى أنه مع الانتهاء من عقد الإيداع، انخفضت أهمية EIP-2537 بشكل كبير، وفي نفس الوقت يعتبر مطورو Geth أن هذا EIP من المحتمل جداً ألا يتم تنفيذه قبل ترقية Berlin. يبدو أن عدم اعتماد EIP-2537 في ترقية Berlin أصبح أمراً محسوماً.
في الاجتماع رقم 88، اكتشف مطورو Geth أن تنفيذ PR الخاص بـ EIP-2537 يعاني من مجموعة من المشكلات، وأشاروا إلى الحاجة إلى مزيد من الاختبارات والإصلاحات. في هذه الأثناء، يوجد في نظام Geth تنفيذان لـ EIP-2537، أحدهما يتضمن تحسينات تجميعية، والآخر مكتوب بالكامل بلغة Go. اقترح بعض المطورين استخدام النسخة المكتوبة بلغة Go مباشرةً لتقليل صعوبة مراجعة الكود.
في الاجتماع رقم 89 ظهرت مشاكل أكثر خطورة، حيث ظهرت بعض الشواذ على شبكة اختبار YOLO، ويشتبه المطورون في أن السبب هو توقيع BLS، لكن مطورو EIP-2537 ردوا على ذلك. الخبر الجيد هو أن عقد الودائع المستند إلى EIP-2537 قد اكتمل تطويره بشكل أساسي، وهو في انتظار التدقيق.
حدد الاجتماع التاسع والتسعين الموعد النهائي لإطلاق ترقية برلين في يوليو. كما ناقش الاجتماع قضية تنوع العملاء، والتي تتعلق بشكل رئيسي بسيطرة Geth، حيث اقترح بعض المطورين تجميد التنفيذ الحالي لـ EIP لتقليل تكاليف تطوير العملاء الآخرين. في الاجتماع التسعين، اقترح بعض المطورين استخدام خطة معيارية لتقليل تكاليف التطوير وزيادة تنوع العملاء.
تم التأكيد على EIP-2537 كـ EIP المطلوب لترقية برلين في الاجتماع رقم 92.
في الاجتماع السادس والتسعين، بسبب أن Celo قد دمجت EIP-2537 وEIP-2539 في نفس الوقت في عملية الشوكة الصلبة لشبكتها، تأمل Matter Labs في وضع EIP-2539 أيضًا في اختبار YOLO v2 والدخول في ترقية برلين. لكن مطورو Geth عارضوا، معتبرين أن EIP-2537 لم يتم اختباره بشكل كامل في Geth بعد. في النهاية، قررت الاجتماع عدم إضافة EIP-2696 في ترقية برلين، وترك الأمر للنقاش في المستقبل.
قررت الاجتماع التاسع والتسعين نقل EIP-2537 من شبكة اختبار YOLO v3 وترقية Berlin، وكان السبب الرئيسي هو أن EIP-2537 استهلك الكثير من وقت المطورين الرئيسيين، مما أدى إلى عرقلة تطوير EIPs الأخرى لترقية Berlin. والعامل الثانوي هو أن مؤسسة Ethereum اقترحت EVM384 كبديل لـ EIP-2537، حيث تقدم حلاً أكثر عمومية لحسابات المنحنيات الإهليلجية. لكن المطورين الرئيسيين أعربوا عن مخاوفهم بشأن مسائل الأمان.
هذه هي المسيرة المبكرة لـ EIP-2537. يمكننا أن نرى أن EIP-2537 كان في البداية واحدًا من أهم EIP في ترقية برلين، ولكن تم التخلي عنه في نهاية المطاف بسبب مشاكل في التنفيذ. في أبريل 2021، أكملت الإيثيريوم ترقية برلين، لم تكن EIPs الأساسية مثل EIP-2565 معقدة في التنفيذ فعليًا، وبدت الترقية ضعيفة بعض الشيء، وذلك لأن EIP-2537 المعقدة في جوهرها تم استبعادها.
التطورات المستقبلية
كما هو معروف، كل ترقية للإيثريوم تأتي مع اقتراح أساسي. الترقية من برلين إلى لندن أدخلت أهم اقتراح لرسوم الإيثريوم في التاريخ EIP-1559. بالنسبة للاقتراح الأساسي السابق EIP-2537، سيكون من الصعب إدخاله في التحديثات اللاحقة.
تمت ترقية لندن بعد برلين ، حيث نظر المطورون في المسألة #369 في إضافة EIP-2537. تم تحديث حالة تطوير EIP-2537 في الاجتماع رقم 109 لمطوري النواة، وبسبب استخدام مكتبات أخرى في التنفيذ، أثار ذلك مناقشات حول استخدام الغاز. اقترح أحد المطورين استبدال EIP-2537 بـ EVM384. ولكن في الاجتماع رقم 111 في أبريل 2021، تم استبعاد EIP-2537 من ترقية لندن بسبب تعقيده. السبب الرئيسي هو أن التنفيذ القياسي لـ EIP-2537 غير مكتبة الاعتماد، مما أدى إلى احتمال تغيير تسعير الغاز، حيث يتطلب تنفيذ العملاء المختلفين وقتًا طويلاً لإعادة تقييم استهلاك الغاز.
في يونيو 2021، تم تقديم المسألة #343 رسميًا لإدراج EIP-2537 في ترقية شانغهاي. لكن بعد ترقية لندن، استحوذ الدمج على الكثير من وقت المطورين، حيث كان على مطوري الطبقة التنفيذية كتابة الكثير من الشفرات لتنفيذ ترقية PoS. في سبتمبر 2022، بعد الانتهاء من الدمج، أصبح لمطوري الطبقة التنفيذية الفرصة لمواصلة مناقشة أهداف ترقية شانغهاي.
في نوفمبر 2022، تم مناقشة باختصار في الاجتماع الـ 150 لمطوري النواة ما إذا كان يجب تضمين EIP-2537 في Shanghai، لكن المطورين اعتبروا أنه يجب تأجيل ذلك، حيث أن جوهر Shanghai هو دعم سحب PoS. في النهاية، لم يتم تضمين EIP-2537 لتحقيق ترقية Shanghai التي تركز على السحب.
للأسف، لم يتم مناقشة ترقية كانكون EIP-2537، لأن التركيز في كانكون هو دعم EIP-4844، لتوفير Blob للطبقة الثانية من إيثيريوم لاستخدام إيثيريوم كطبقة توفر البيانات.
حتى الاجتماع رقم 181 للمطورين الأساسيين في فبراير 2024، لم يناقش المطورون تضمين EIP-2537 في ترقية Pectra. في ذلك الوقت، اعتقد المطورون أن تنفيذ EIP-2537 لم يعد مشكلة، فقط بعض مسائل تسعير استهلاك الغاز تحتاج إلى حل.
في الاجتماع رقم 202 الذي عُقد في 19 ديسمبر 2024 ، حدد مطورو Nethermind أخيرًا نموذج تسعير EIP-2537. من الجدير بالذكر أن Matter Labs ، مقدمة الاقتراح الأصلي لـ EIP-2537 ، قد انسحبت تقريبًا من المناقشات في هذا الوقت. ناقش الاجتماع رقم 203 في يناير 2025 إعادة تسعير BLS Precompile ، حيث اقترح مطور Geth Jared Wasinger زيادة تكلفة الغاز بنسبة 20% ، وحصل على دعم من فريق Besu في الاختبارات المرجعية.
ملخص
مرت عملية اعتماد EIP-2537 منذ تقديمه حتى اعتماده النهائي بمرحلة طويلة ومتعرجة: