يركز هذا المقال على تاريخ حوكمة EIP-2537 ، ويستكشف لماذا استغرق الأمر 5 سنوات لإدراج هذا الاقتراح في الترقية.
الكلمات: شيو
نظرة عامة
EIP-2537 هو الأمر المسبق لإعادة التجميع الذي تم تحديده للإضافة في أحدث ترقية لفرع Pectra. يضيف هذا الأمر العديد من وظائف الحساب على منحنى BLS12-381 إلى EVM، مثل الحسابات المقرونة على مجال المنحنى وغيرها.
تم اقتراح EIP-2573 لأول مرة في عام 2020، ولم يتم تأكيده للانضمام إلى ترقية الإيثيريوم حتى عام 2025. يركز هذا المقال بشكل أساسي على تاريخ حوكمة EIP-2537، ويستكشف لماذا استغرق الأمر 5 سنوات لإدراج هذا الاقتراح في الترقية.
خلفية الاقتراح
في يناير 2017، قدم فيتاليك بوتيرين خوارزمية الاقتران ومنحنى alt_bn128 لأول مرة في Exploring Elliptic Curve Pairings. بعد ذلك، في فبراير 2017، اقترح فيتاليك بوتيرين وكريستيان ريتفيسنر اقتراحات EIP-196 و EIP-197، والتي تتعلق بإضافة دعم حساب منحنى alt_bn128 إلى EVM.
في ترقية بيزنطية في أكتوبر 2017، تم دمج منحنى alt_bn128 رسميًا. ببساطة، تحقق alt_bn128 لأول مرة حسابات الاقتران في مجال المنحنيات داخل EVM، مما يجعل من الممكن إكمال التحقق من إثباتات ZK-Snarks داخل EVM.
لكن مع تطور علم التشفير، في نوفمبر 2017، قدم فريق تطوير zcash لأول مرة منحنى BLS12-381 في BLS12-381: New zk-SNARK Elliptic Curve Construction. بالمقارنة مع alt_bn128، فإن BLS12-381 يتمتع بأمان أعلى وأداء أفضل. وقد استخدمت العديد من بروتوكولات blockchain بعد ذلك منحنى BLS12-381 وتخلت عن منحنى alt_bn128.
في مايو 2018، نشر جاستين دريك في ethresear مقالًا بعنوان تجميع التوقيع العملي باستخدام BLS، مشيرًا إلى أنه يمكن استخدام خوارزمية BLS متعددة التوقيعات المستندة إلى منحنى BLS12-381 في ترقية PoS والشظايا المستقبلية لإيثيريوم. في ذلك الوقت، كان الباحثون في إيثيريوم يأملون في استخدام EIP-1011 لحل مشاكل طبقة الإجماع، لكن خطة EIP-1011 كانت تستوعب في أقصى حد 900 مدقق، مما حدد حجم الرهان الضخم لكل مدقق بمقدار 1500 ETH. مع تقديم خطة BLS متعددة التوقيعات، خرج EIP-1011 من المسرح التاريخي. ثبت أن ترقية ETH2 اللاحقة استخدمت أيضًا في النهاية منحنى BLS12-381.
مع تطوير ETH2، تم استدعاء طبقة التنفيذ ETH التي تستخدم BLS12-381. في فبراير 2020، اقترح بعض الباحثين EIP-2537، و希望 أن يتم اختبار هذا الاقتراح مع شبكة اختبار ETH2. دعا مؤلف EIP-2537 أليكس ستوكس في مقاله "ماذا يحتاج eth2 من eth1 في الأشهر الستة المقبلة" إلى تضمين EIP-2537 في الانقسام الصلب برلين.
من المثير للاهتمام أن مؤلف EIP-2537 هو أيضاً أحد مؤسسي Matter Labs، وأشهر منتج لمatter Labs هو ZKSync.
برلين الاضطرابات
قبل أن نقدم المحتوى اللاحق، نحتاج أولاً إلى تقديم EIP-1962. EIP-1962 هو الاقتراح الأول الذي قدمه Matter Labs في أبريل 2019 بشأن تجميع مسبق للاقتران في مجالات المنحنيات البيضاوية، والذي دعم ثلاث منحنيات، وهي:
BLS12
*الجبهه الوطنيه
MNT4 / 6 (Ate pairing)
تستعد EIP لإضافة 10 تعليمات تجميع مسبقة لمعالجة منحنيات مختلفة دفعة واحدة. ومع ذلك، بعد ولادة هذا الاقتراح، تساءل عدد كبير من المطورين عما إذا كان الاقتراح معقدًا للغاية لدرجة أنه سيكون من الصعب على المطورين تنفيذه. في الوقت نفسه، نظرًا لأن EIP1962 شديدة العمومية، فإن استدعائها يعد أمرًا مزعجًا لمهندسي العقود الذكية. بالطبع، كمنشئ لـ EIP-1962، فقد أكملت Matter Labs فعليًا تطوير خوارزمية منحنى البيضاوي، ووفرت تنفيذات مرجعية بلغة Rust / Go / C++.
لمعالجة مشكلة EIP-1962 ، اقترحت Matter Labs تقسيمات EIP متعددة في فبراير 2020 ل EIP-1962 ، وكلها ترث جزئيا واجهة EIP-1962. تشمل هذه EIPs:
EIP-2537 يوفر دعم BLS12-381
EIP-2539 يدعم BLS12-377
PR#2541 يوفر دعم BLS12-377 (Zexe curve)، ولكن لاحظ أن هذا الاقتراح لم يحصل في النهاية على رقم EIP، لذا لا يمكن العثور عليه في موقع وثائق EIP الرسمي.
من بين هذه EIP ، الأهم هو EIP-2537، لأن طبقة الإجماع تستخدم أيضًا منحنى BLS12-381. تشمل الأهداف الأساسية لكل من EIP-1962 و EIP-2537 تحقيق التحقق من توقيع BLS في طبقة الإجماع على الشبكة الرئيسية. في ذلك الوقت، كان ETH2 يقوم بتطوير تصميم عقد الإيداع لطبقة الإجماع. عند التصميم الأولي لعقد الإيداع، نظرًا لعدم احتواء طبقة التنفيذ على خوارزمية التحقق من BLS، فلن يتحقق عقد الإيداع من التوقيع، وسيتم التحقق من توقيع BLS المحدد بعد إيداع المستخدم بواسطة طبقة الإجماع، وإذا تم اكتشاف عدم صحة (بالنسبة للمدققين الجدد)، سيفشل الإيداع وستفقد ETH المودعة من قبل المستخدم.
في هذا السياق، يأمل المطورون الرئيسيون في إدخال BLS12-381 مسبق التجميع لتحقيق التحقق من التوقيع داخل عقد الإيداع، لتجنب الخسائر المحتملة لمستخدمي ETH2. وكان هذا أيضًا سبب اهتمام عدد كبير من المطورين بـ EIP-1962 و EIP-2537 آنذاك.
عندما تم اقتراح EIP-2537 لأول مرة، اكتشف فيتاليك على الفور مجموعة من المشكلات الموجودة في EIP.
!
تتركز هذه الشكوك فقط على محتوى وثيقة EIP، ثم قام مؤلفو EIP بالرد والمناقشة. بعد ذلك، في 6 مارس 2020، في اجتماع مطوري Ethereum الأساسي رقم 82، ناقش مطورو Ethereum الأساسيون EIP-2537. في هذا الاجتماع، اعتبر فيتاليك أن EIP-2537 و EIPs الأخرى فعالة جداً لإثبات SNARK التكراري، وأنها لن تضر Ethereum على المدى الطويل. كما أكد الاجتماع على أولوية EIP-2537، حيث اتفقت جميع العملاء على تنفيذ EIP-2537 في أقرب وقت ممكن وتخطط لإنهاء جميع التطويرات قبل ترقية برلين.
في وقت لاحق ، أصبح EIP-2537 أولوية أعلى. في 20 مارس 2020 ، في اجتماع Ethereum Core Devs # 83 ، كان EIP-2537 لا يزال أول اقتراح تتم مناقشته. أكد الاجتماع أن EIP-2537 حل محل EIP-1962 كاقتراح BLS الأساسي وأصبح قائمة EIP المختارة مسبقا لترقية برلين ( ، أي الأهلية للإدراج (EFI)).
في اجتماع مطوري Ethereum الأساسي #84 في أبريل 2020، تم إدراج EIP-2537 رسميًا في ترقية برلين الصلبة، وتم تحديد الجدول الزمني لترقية برلين لتحقيقها في أبريل وإجراء الاختبارات في مايو - يونيو. من الجدير بالذكر أن EIP-2537 تم إدراجه كأولوية قصوى في هذه المناقشة.
!
بعد ذلك، دخل EIP-2537 في مرحلة كبيرة من التطوير والاختبار، حيث تم تناول مناقشة EIP-2537 في كل اجتماع من الاجتماعات الأساسية للمطورين التي عقدت تقريبًا 20 مرة. بعد ذلك، يمكننا إلقاء نظرة على القضايا المتعلقة بـ EIP-2537 التي تم مناقشتها في كل اجتماع.
في اجتماع مطوري Ethereum Core Devs Meeting #85، ناقش Danno و Axic مشكلة ترميز ABI لـ EIP-2537. بعد ذلك، قام المطورون الأساسيون بمزامنة حالة التنفيذ الحالية، حيث أن مقترح EIP-2537 من Matter Labs قد أكمل تقريبا تنفيذ النسخة Rust، لذا أعلنت عميل Besu أنها قد نفذت تقريبا وظيفة EIP-2537، ولكن من جانب Geth، تم الإشارة إلى أنه لا يوجد أحد يعمل حاليا على تنفيذ EIP-2537.
في اجتماع مطوري Ethereum الأساسيين رقم 86، تم مزامنة حالة تنفيذ EIP-2537 مرة أخرى بين تنفيذات عقد Ethereum المختلفة، حيث ذكر Geth أنه أكمل جزءًا من العمل، ولكن لا يزال هناك الكثير من العمل الذي ينتظر الإنجاز.
!
في اجتماع مطوري Ethereum Core Devs Meeting #87، كانت القضية الأساسية في هذه الاجتماع هي مسألة تنفيذ EIP-2537. أشار مطورو Geth إلى أن هناك حاليًا PR يتكون من 16000 سطر لتنفيذ EIP-2537، ولكن لم يتمكن مطورو Geth من التأكد مما إذا كان PR يمثل تنفيذًا آمنًا وفعالًا لـ EIP-2537، لذا يمكن للمطورين فقط الاعتماد على اختبار الضبابية البسيط لتقييم حالة الكود.
قال مطور Geth: «لذا فإن رد فعلي الغريزي هو أنه لا فرصة لأن يكون Geth جاهزًا مع عمليات منحنى BLS لإطلاق الشبكة الرئيسية في يوليو.»، مما يعني أن Geth من المرجح جدًا ألا يكمل تطوير EIP-2537 قبل الموعد المحدد في برلين.
اقترح هادسون جيمسون البحث عن مهندسي تشفير لمساعدة مراجعة PR لـ Geth، واقترح أيضًا استخدام شبكة اختبار لاختبار أمان تنفيذ EIP-2537. نظرًا لأن فريق تطوير ETH2 كان أيضًا يعمل على تنفيذ التحقق من توقيع BLS، فإن فريق ETH2 يمكنه المشاركة في الاختبار.
هنا، نحتاج إلى إضافة معرفة خلفية، وهي أن تنفيذ Geth لـ EIP-2537 PR قد استخدم بشكل كبير التعليمات البرمجية التجميعية لضمان الكفاءة، وهذه التعليمات البرمجية التجميعية يصعب قراءتها وفهمها. لذلك اقترح أليكس فلاسوف إزالة تحسينات التجميع المعقدة داخل PR لتقليل صعوبة المراجعة.
لقد قدمنا في النص السابق أن أحد الأهداف الأساسية لـ EIP-2537 هو مساعدة عقد إيداع ETH2، ولكن في هذا الاجتماع، أشار مطورو عقد الإيداع إلى أن عقد الإيداع الذي لا يستخدم EIP-2537 قد تم تدقيقه، لذلك اقترح بعض المطورين أنه من الأفضل عدم إصدار عقد إيداع يستخدم EIP-2537.
في النهاية، قررت الاجتماع زيادة شبكة اختبار YOLO، حيث أن جوهر هذه الشبكة هو اختبار EIP-2537. في الواقع، يمكننا أن نرى في هذا الاجتماع أن أهمية EIP-2537 قد انخفضت بشكل كبير مع الانتهاء من عقد الإيداع، بينما اعتبر مطورو Geth أن هذا EIP من المرجح جدًا أنه لن يتم تحقيقه قبل ترقية برلين. يبدو أن عدم قبول EIP-2537 في ترقية برلين قد أصبح أمرًا محسومًا.
في اجتماع مطوري Ethereum Core Devs رقم 88، اكتشف مطورو Geth أن هناك سلسلة من المشكلات في PR تنفيذ EIP-2537، وأشار المطورون إلى الحاجة إلى مزيد من الاختبار والإصلاح. في هذا الوقت، كان هناك تنفيذان لـ EIP-2537 في نظام Geth، أحدهما يتضمن تحسينات تجميع، بينما الآخر مكتوب بالكامل بلغة Go، واقترح أحد المطورين استخدام النسخة المكتوبة بلغة Go مباشرة لتقليل صعوبة مراجعة الكود.
في اجتماع مطوري Ethereum الأساسي رقم 89، حدثت مشكلة أكثر خطورة، حيث ظهرت بعض المشكلات في اختبار YOLO، ويشتبه المطورون في أن المشكلة ناتجة عن توقيع BLS، لكن مطوري EIP2537 ردوا على ذلك، معتقدين أن مشكلة شبكة الاختبار ليست ناتجة عن توقيع BLS. الخبر الجيد بشأن EIP-2537 هو أن عقد الإيداع القائم على EIP-2537 قد اكتمل تطويره بشكل أساسي، والعقد في انتظار تدقيق العقد.
في #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 اجتماع Ethereum Core Devs ، اقترح أحد المطورين زيادة تنوع العملاء باستخدام نهج معياري لتقليل تكاليف التطوير. إذا كنت مهتما بتنوع عملاء Ethereum ، فيمكنك قراءة نصوص هذين الاجتماعين.
في اجتماع مطوري Ethereum Core رقم 92، تم التأكيد مرة أخرى على أن 2537 هو EIP المطلوب لترقية برلين.
في اجتماع Ethereum Core Devs # 96 ، تريد Matter Labs وضع EIP-2539 المقترح في نفس الوقت مع EIP-2537 في شبكة اختبار YOLO v2 والدخول في ترقية برلين ، بالنظر إلى أن Celo قد أدرجت كلا من EIP-2537 و EIP-2539 في ترقية الهارد فورك للشبكة. ومع ذلك ، اعترض مطورو Geth ، بحجة أن EIP-2537 الحالي لم يتم اختباره بالكامل داخل Geth. قرر الاجتماع الأخير عدم إضافة 2696 إلى ترقية برلين ، وتركها للمناقشة المستقبلية.
في اجتماع مطوري Ethereum الأساسيين رقم 99، تقرر إخراج EIP-2537 من شبكة اختبار YOLO v3 وترقية Berlin، والسبب الرئيسي هو أن EIP-2537 أهدرت الكثير من الوقت على المطورين الأساسيين، مما أدى إلى تعثر تطوير EIPs الأخرى في ترقية Berlin. العامل الثانوي هو أن مؤسسة Ethereum اقترحت EVM384 كبديل لـ EIP-2537، حيث يقدم EVM 384 حلاً أكثر عمومية لحسابات المنحنيات البيضاوية. ومع ذلك، أعرب المطورون الأساسيون في مناقشات الاجتماع عن مخاوفهم بشأن قضايا الأمان.
المحتوى المذكور هو التاريخ المبكر لـ EIP-2537، ويمكننا أن نرى أن EIP-2537 كان أحد أهم EIP في ترقية برلين في بدايتها، ولكن بسبب مشاكل التنفيذ تم التخلي عنه في النهاية. أخيرًا، في أبريل 2021، أكملت الإيثيريوم ترقية برلين، وكانت EIP-2565 وغيرها من التنفيذات الفعلية التي تم تضمينها في الترقية ليست معقدة، ويبدو أن ترقية برلين قد تبدو ضعيفة بعض الشيء، وذلك لأن EIP-2537 الأكثر تعقيدًا تم استبعاده من ترقية برلين.
!
التطورات المستقبلية
كما هو معروف، كل ترقية لإيثيريوم تأتي مع اقتراح أساسي، مثل ترقية لندن التي تلت ترقية برلين والتي قدمت أهم اقتراح لرسوم المعاملات في تاريخ إيثيريوم EIP-1559. بالنسبة للاقتراح EIP-2537 الذي كان اقتراحًا أساسيًا في الماضي، كان من الصعب دمج هذا الاقتراح في التحديثات اللاحقة.
في ترقية لندن بعد برلين، قام المطورون في issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109 بمزامنة حالة تطوير EIP-2537 الحالية، وفي ذلك الوقت، نظرًا لاستخدام مكتبات أخرى لتنفيذ EIP-2537، تم إدخال نقاش حول استخدام الغاز في EIP-2537. في الوقت نفسه، اقترح بعض المطورين استبدال EIP-2537 بـ EVM384. ولكن في اجتماع مطوري Ethereum Core في أبريل 2021 #111، تم إزالة EIP-2537 من ترقية لندن بسبب التعقيد. تكمن التعقيد الأساسي في أن تنفيذ معيار EIP-2537 قد غير المكتبات المعتمدة، مما أدى إلى احتمال تغير تسعير الغاز، وتحتاج تنفيذات العملاء المختلفة إلى وقت كبير لإعادة تقييم استهلاك الغاز.
في يونيو 2021، تم طرح EIP-2537 رسميًا في الترقية Shanghai من خلال issues#343. ولكن يجب ملاحظة أنه بعد ترقية London، استحوذت في الواقع ترقية Pairs، المعروفة أيضًا باسم The Merge، على وقت كبير من المطورين، حيث كان يتعين على مطوري الطبقة التنفيذية كتابة كود كبير لتحقيق ترقية PoS. في سبتمبر 2022، اكتملت ترقية Pairs، وأتيحت أخيرًا لمطوري الطبقة التنفيذية الفرصة لمواصلة مناقشة بعض أهداف ترقية Shanghai.
في نوفمبر 2022، تم مناقشة إمكانية تضمين EIP-2537 في ترقية شنغهاي خلال اجتماع مطوري إيثيريوم الأساسي #150، لكن المطورين اعتبروا أن EIP-2537 يحتاج إلى تأجيل، حيث أن جوهر ترقية شنغهاي هو دعم سحب PoS. في النهاية، لم يتم تضمين EIP-2537 ضمن ترقية شنغهاي التي تركز على وظيفة السحب.
الأسوأ من ذلك هو أن ترقية كانكون لم تناقش EIP-2537 على الإطلاق، لأن جوهر ترقية كانكون هو دعم عقد الطبقة التنفيذية لـ EIP-4844. يوفر EIP-4844 Blob للطبقة الثانية من إيثريوم لتسهيل استخدام الطبقة الثانية لإيثريوم كطبقة لتوافر البيانات.
أخيرًا، في اجتماع مطوري Ethereum الأساسي #181 في فبراير 2024، ناقش المطورون تضمين EIP-2537 في ترقية Pectra، وفي ذلك الوقت اعتبر المطورون أن تنفيذ EIP-2537 لم يعد مشكلة، فقط بعض القضايا المتعلقة بتسعير استهلاك الغاز.
في اجتماع مطوري إيثريوم الأساسيين في 19 ديسمبر 2024 #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203 ، ناقش المطورون إعادة تسعير BLS السابق التجميع ، واقترح مطور Geth جاريد واسنجر زيادة تكلفة الغاز بنسبة 20٪ ، وحصل على دعم من فريق Besu للاختبارات المرجعية.
ملخص
!
من الواضح أن ما إذا كان EIP سيتم تضمينه في ترقية الإيثيريوم "بالطبع يعتمد على الكفاح الذاتي، ولكن يجب أيضًا مراعاة مسار التاريخ". كل ترقية للإيثيريوم لها موضوع خاص بها، تمامًا كما أصبح EIP-2537 أحد أهم EIPs في ترقية برلين، ولكن تم التخلي عنه بسبب صعوبة تنفيذه وتعقيده. بعد ذلك، دخل الإيثيريوم في مسار تاريخ PoS، حيث لم تحظ EIPs المعقدة الخاصة بطبقة التنفيذ الخالصة بالاهتمام، بينما تم اعتبار العديد من EIPs التنفيذية المتعلقة بـ PoS أهدافًا رئيسية للترقية، مما أدى إلى عدم قبول EIP-2537 لفترة طويلة.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
إثيريوم إدارة المراقبة: مسار التجميع المسبق لـ EIP-2537 | GCC Research
الكلمات: شيو
نظرة عامة
EIP-2537 هو الأمر المسبق لإعادة التجميع الذي تم تحديده للإضافة في أحدث ترقية لفرع Pectra. يضيف هذا الأمر العديد من وظائف الحساب على منحنى BLS12-381 إلى EVM، مثل الحسابات المقرونة على مجال المنحنى وغيرها.
تم اقتراح EIP-2573 لأول مرة في عام 2020، ولم يتم تأكيده للانضمام إلى ترقية الإيثيريوم حتى عام 2025. يركز هذا المقال بشكل أساسي على تاريخ حوكمة EIP-2537، ويستكشف لماذا استغرق الأمر 5 سنوات لإدراج هذا الاقتراح في الترقية.
خلفية الاقتراح
في يناير 2017، قدم فيتاليك بوتيرين خوارزمية الاقتران ومنحنى alt_bn128 لأول مرة في Exploring Elliptic Curve Pairings. بعد ذلك، في فبراير 2017، اقترح فيتاليك بوتيرين وكريستيان ريتفيسنر اقتراحات EIP-196 و EIP-197، والتي تتعلق بإضافة دعم حساب منحنى alt_bn128 إلى EVM.
في ترقية بيزنطية في أكتوبر 2017، تم دمج منحنى alt_bn128 رسميًا. ببساطة، تحقق alt_bn128 لأول مرة حسابات الاقتران في مجال المنحنيات داخل EVM، مما يجعل من الممكن إكمال التحقق من إثباتات ZK-Snarks داخل EVM.
لكن مع تطور علم التشفير، في نوفمبر 2017، قدم فريق تطوير zcash لأول مرة منحنى BLS12-381 في BLS12-381: New zk-SNARK Elliptic Curve Construction. بالمقارنة مع alt_bn128، فإن BLS12-381 يتمتع بأمان أعلى وأداء أفضل. وقد استخدمت العديد من بروتوكولات blockchain بعد ذلك منحنى BLS12-381 وتخلت عن منحنى alt_bn128.
في مايو 2018، نشر جاستين دريك في ethresear مقالًا بعنوان تجميع التوقيع العملي باستخدام BLS، مشيرًا إلى أنه يمكن استخدام خوارزمية BLS متعددة التوقيعات المستندة إلى منحنى BLS12-381 في ترقية PoS والشظايا المستقبلية لإيثيريوم. في ذلك الوقت، كان الباحثون في إيثيريوم يأملون في استخدام EIP-1011 لحل مشاكل طبقة الإجماع، لكن خطة EIP-1011 كانت تستوعب في أقصى حد 900 مدقق، مما حدد حجم الرهان الضخم لكل مدقق بمقدار 1500 ETH. مع تقديم خطة BLS متعددة التوقيعات، خرج EIP-1011 من المسرح التاريخي. ثبت أن ترقية ETH2 اللاحقة استخدمت أيضًا في النهاية منحنى BLS12-381.
مع تطوير ETH2، تم استدعاء طبقة التنفيذ ETH التي تستخدم BLS12-381. في فبراير 2020، اقترح بعض الباحثين EIP-2537، و希望 أن يتم اختبار هذا الاقتراح مع شبكة اختبار ETH2. دعا مؤلف EIP-2537 أليكس ستوكس في مقاله "ماذا يحتاج eth2 من eth1 في الأشهر الستة المقبلة" إلى تضمين EIP-2537 في الانقسام الصلب برلين.
من المثير للاهتمام أن مؤلف EIP-2537 هو أيضاً أحد مؤسسي Matter Labs، وأشهر منتج لمatter Labs هو ZKSync.
برلين الاضطرابات
قبل أن نقدم المحتوى اللاحق، نحتاج أولاً إلى تقديم EIP-1962. EIP-1962 هو الاقتراح الأول الذي قدمه Matter Labs في أبريل 2019 بشأن تجميع مسبق للاقتران في مجالات المنحنيات البيضاوية، والذي دعم ثلاث منحنيات، وهي:
تستعد EIP لإضافة 10 تعليمات تجميع مسبقة لمعالجة منحنيات مختلفة دفعة واحدة. ومع ذلك، بعد ولادة هذا الاقتراح، تساءل عدد كبير من المطورين عما إذا كان الاقتراح معقدًا للغاية لدرجة أنه سيكون من الصعب على المطورين تنفيذه. في الوقت نفسه، نظرًا لأن EIP1962 شديدة العمومية، فإن استدعائها يعد أمرًا مزعجًا لمهندسي العقود الذكية. بالطبع، كمنشئ لـ EIP-1962، فقد أكملت Matter Labs فعليًا تطوير خوارزمية منحنى البيضاوي، ووفرت تنفيذات مرجعية بلغة Rust / Go / C++.
لمعالجة مشكلة EIP-1962 ، اقترحت Matter Labs تقسيمات EIP متعددة في فبراير 2020 ل EIP-1962 ، وكلها ترث جزئيا واجهة EIP-1962. تشمل هذه EIPs:
من بين هذه EIP ، الأهم هو EIP-2537، لأن طبقة الإجماع تستخدم أيضًا منحنى BLS12-381. تشمل الأهداف الأساسية لكل من EIP-1962 و EIP-2537 تحقيق التحقق من توقيع BLS في طبقة الإجماع على الشبكة الرئيسية. في ذلك الوقت، كان ETH2 يقوم بتطوير تصميم عقد الإيداع لطبقة الإجماع. عند التصميم الأولي لعقد الإيداع، نظرًا لعدم احتواء طبقة التنفيذ على خوارزمية التحقق من BLS، فلن يتحقق عقد الإيداع من التوقيع، وسيتم التحقق من توقيع BLS المحدد بعد إيداع المستخدم بواسطة طبقة الإجماع، وإذا تم اكتشاف عدم صحة (بالنسبة للمدققين الجدد)، سيفشل الإيداع وستفقد ETH المودعة من قبل المستخدم.
في هذا السياق، يأمل المطورون الرئيسيون في إدخال BLS12-381 مسبق التجميع لتحقيق التحقق من التوقيع داخل عقد الإيداع، لتجنب الخسائر المحتملة لمستخدمي ETH2. وكان هذا أيضًا سبب اهتمام عدد كبير من المطورين بـ EIP-1962 و EIP-2537 آنذاك.
عندما تم اقتراح EIP-2537 لأول مرة، اكتشف فيتاليك على الفور مجموعة من المشكلات الموجودة في EIP.
!
تتركز هذه الشكوك فقط على محتوى وثيقة EIP، ثم قام مؤلفو EIP بالرد والمناقشة. بعد ذلك، في 6 مارس 2020، في اجتماع مطوري Ethereum الأساسي رقم 82، ناقش مطورو Ethereum الأساسيون EIP-2537. في هذا الاجتماع، اعتبر فيتاليك أن EIP-2537 و EIPs الأخرى فعالة جداً لإثبات SNARK التكراري، وأنها لن تضر Ethereum على المدى الطويل. كما أكد الاجتماع على أولوية EIP-2537، حيث اتفقت جميع العملاء على تنفيذ EIP-2537 في أقرب وقت ممكن وتخطط لإنهاء جميع التطويرات قبل ترقية برلين.
في وقت لاحق ، أصبح EIP-2537 أولوية أعلى. في 20 مارس 2020 ، في اجتماع Ethereum Core Devs # 83 ، كان EIP-2537 لا يزال أول اقتراح تتم مناقشته. أكد الاجتماع أن EIP-2537 حل محل EIP-1962 كاقتراح BLS الأساسي وأصبح قائمة EIP المختارة مسبقا لترقية برلين ( ، أي الأهلية للإدراج (EFI)).
في اجتماع مطوري Ethereum الأساسي #84 في أبريل 2020، تم إدراج EIP-2537 رسميًا في ترقية برلين الصلبة، وتم تحديد الجدول الزمني لترقية برلين لتحقيقها في أبريل وإجراء الاختبارات في مايو - يونيو. من الجدير بالذكر أن EIP-2537 تم إدراجه كأولوية قصوى في هذه المناقشة.
!
بعد ذلك، دخل EIP-2537 في مرحلة كبيرة من التطوير والاختبار، حيث تم تناول مناقشة EIP-2537 في كل اجتماع من الاجتماعات الأساسية للمطورين التي عقدت تقريبًا 20 مرة. بعد ذلك، يمكننا إلقاء نظرة على القضايا المتعلقة بـ EIP-2537 التي تم مناقشتها في كل اجتماع.
في اجتماع مطوري Ethereum Core Devs Meeting #85، ناقش Danno و Axic مشكلة ترميز ABI لـ EIP-2537. بعد ذلك، قام المطورون الأساسيون بمزامنة حالة التنفيذ الحالية، حيث أن مقترح EIP-2537 من Matter Labs قد أكمل تقريبا تنفيذ النسخة Rust، لذا أعلنت عميل Besu أنها قد نفذت تقريبا وظيفة EIP-2537، ولكن من جانب Geth، تم الإشارة إلى أنه لا يوجد أحد يعمل حاليا على تنفيذ EIP-2537.
في اجتماع مطوري Ethereum الأساسيين رقم 86، تم مزامنة حالة تنفيذ EIP-2537 مرة أخرى بين تنفيذات عقد Ethereum المختلفة، حيث ذكر Geth أنه أكمل جزءًا من العمل، ولكن لا يزال هناك الكثير من العمل الذي ينتظر الإنجاز.
!
في اجتماع مطوري Ethereum Core Devs Meeting #87، كانت القضية الأساسية في هذه الاجتماع هي مسألة تنفيذ EIP-2537. أشار مطورو Geth إلى أن هناك حاليًا PR يتكون من 16000 سطر لتنفيذ EIP-2537، ولكن لم يتمكن مطورو Geth من التأكد مما إذا كان PR يمثل تنفيذًا آمنًا وفعالًا لـ EIP-2537، لذا يمكن للمطورين فقط الاعتماد على اختبار الضبابية البسيط لتقييم حالة الكود.
قال مطور Geth: «لذا فإن رد فعلي الغريزي هو أنه لا فرصة لأن يكون Geth جاهزًا مع عمليات منحنى BLS لإطلاق الشبكة الرئيسية في يوليو.»، مما يعني أن Geth من المرجح جدًا ألا يكمل تطوير EIP-2537 قبل الموعد المحدد في برلين.
اقترح هادسون جيمسون البحث عن مهندسي تشفير لمساعدة مراجعة PR لـ Geth، واقترح أيضًا استخدام شبكة اختبار لاختبار أمان تنفيذ EIP-2537. نظرًا لأن فريق تطوير ETH2 كان أيضًا يعمل على تنفيذ التحقق من توقيع BLS، فإن فريق ETH2 يمكنه المشاركة في الاختبار.
هنا، نحتاج إلى إضافة معرفة خلفية، وهي أن تنفيذ Geth لـ EIP-2537 PR قد استخدم بشكل كبير التعليمات البرمجية التجميعية لضمان الكفاءة، وهذه التعليمات البرمجية التجميعية يصعب قراءتها وفهمها. لذلك اقترح أليكس فلاسوف إزالة تحسينات التجميع المعقدة داخل PR لتقليل صعوبة المراجعة.
لقد قدمنا في النص السابق أن أحد الأهداف الأساسية لـ EIP-2537 هو مساعدة عقد إيداع ETH2، ولكن في هذا الاجتماع، أشار مطورو عقد الإيداع إلى أن عقد الإيداع الذي لا يستخدم EIP-2537 قد تم تدقيقه، لذلك اقترح بعض المطورين أنه من الأفضل عدم إصدار عقد إيداع يستخدم EIP-2537.
في النهاية، قررت الاجتماع زيادة شبكة اختبار YOLO، حيث أن جوهر هذه الشبكة هو اختبار EIP-2537. في الواقع، يمكننا أن نرى في هذا الاجتماع أن أهمية EIP-2537 قد انخفضت بشكل كبير مع الانتهاء من عقد الإيداع، بينما اعتبر مطورو Geth أن هذا EIP من المرجح جدًا أنه لن يتم تحقيقه قبل ترقية برلين. يبدو أن عدم قبول EIP-2537 في ترقية برلين قد أصبح أمرًا محسومًا.
في اجتماع مطوري Ethereum Core Devs رقم 88، اكتشف مطورو Geth أن هناك سلسلة من المشكلات في PR تنفيذ EIP-2537، وأشار المطورون إلى الحاجة إلى مزيد من الاختبار والإصلاح. في هذا الوقت، كان هناك تنفيذان لـ EIP-2537 في نظام Geth، أحدهما يتضمن تحسينات تجميع، بينما الآخر مكتوب بالكامل بلغة Go، واقترح أحد المطورين استخدام النسخة المكتوبة بلغة Go مباشرة لتقليل صعوبة مراجعة الكود.
في اجتماع مطوري Ethereum الأساسي رقم 89، حدثت مشكلة أكثر خطورة، حيث ظهرت بعض المشكلات في اختبار YOLO، ويشتبه المطورون في أن المشكلة ناتجة عن توقيع BLS، لكن مطوري EIP2537 ردوا على ذلك، معتقدين أن مشكلة شبكة الاختبار ليست ناتجة عن توقيع BLS. الخبر الجيد بشأن EIP-2537 هو أن عقد الإيداع القائم على EIP-2537 قد اكتمل تطويره بشكل أساسي، والعقد في انتظار تدقيق العقد.
في #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 اجتماع Ethereum Core Devs ، اقترح أحد المطورين زيادة تنوع العملاء باستخدام نهج معياري لتقليل تكاليف التطوير. إذا كنت مهتما بتنوع عملاء Ethereum ، فيمكنك قراءة نصوص هذين الاجتماعين.
في اجتماع مطوري Ethereum Core رقم 92، تم التأكيد مرة أخرى على أن 2537 هو EIP المطلوب لترقية برلين.
في اجتماع Ethereum Core Devs # 96 ، تريد Matter Labs وضع EIP-2539 المقترح في نفس الوقت مع EIP-2537 في شبكة اختبار YOLO v2 والدخول في ترقية برلين ، بالنظر إلى أن Celo قد أدرجت كلا من EIP-2537 و EIP-2539 في ترقية الهارد فورك للشبكة. ومع ذلك ، اعترض مطورو Geth ، بحجة أن EIP-2537 الحالي لم يتم اختباره بالكامل داخل Geth. قرر الاجتماع الأخير عدم إضافة 2696 إلى ترقية برلين ، وتركها للمناقشة المستقبلية.
في اجتماع مطوري Ethereum الأساسيين رقم 99، تقرر إخراج EIP-2537 من شبكة اختبار YOLO v3 وترقية Berlin، والسبب الرئيسي هو أن EIP-2537 أهدرت الكثير من الوقت على المطورين الأساسيين، مما أدى إلى تعثر تطوير EIPs الأخرى في ترقية Berlin. العامل الثانوي هو أن مؤسسة Ethereum اقترحت EVM384 كبديل لـ EIP-2537، حيث يقدم EVM 384 حلاً أكثر عمومية لحسابات المنحنيات البيضاوية. ومع ذلك، أعرب المطورون الأساسيون في مناقشات الاجتماع عن مخاوفهم بشأن قضايا الأمان.
المحتوى المذكور هو التاريخ المبكر لـ EIP-2537، ويمكننا أن نرى أن EIP-2537 كان أحد أهم EIP في ترقية برلين في بدايتها، ولكن بسبب مشاكل التنفيذ تم التخلي عنه في النهاية. أخيرًا، في أبريل 2021، أكملت الإيثيريوم ترقية برلين، وكانت EIP-2565 وغيرها من التنفيذات الفعلية التي تم تضمينها في الترقية ليست معقدة، ويبدو أن ترقية برلين قد تبدو ضعيفة بعض الشيء، وذلك لأن EIP-2537 الأكثر تعقيدًا تم استبعاده من ترقية برلين.
!
التطورات المستقبلية
كما هو معروف، كل ترقية لإيثيريوم تأتي مع اقتراح أساسي، مثل ترقية لندن التي تلت ترقية برلين والتي قدمت أهم اقتراح لرسوم المعاملات في تاريخ إيثيريوم EIP-1559. بالنسبة للاقتراح EIP-2537 الذي كان اقتراحًا أساسيًا في الماضي، كان من الصعب دمج هذا الاقتراح في التحديثات اللاحقة.
في ترقية لندن بعد برلين، قام المطورون في issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109 بمزامنة حالة تطوير EIP-2537 الحالية، وفي ذلك الوقت، نظرًا لاستخدام مكتبات أخرى لتنفيذ EIP-2537، تم إدخال نقاش حول استخدام الغاز في EIP-2537. في الوقت نفسه، اقترح بعض المطورين استبدال EIP-2537 بـ EVM384. ولكن في اجتماع مطوري Ethereum Core في أبريل 2021 #111، تم إزالة EIP-2537 من ترقية لندن بسبب التعقيد. تكمن التعقيد الأساسي في أن تنفيذ معيار EIP-2537 قد غير المكتبات المعتمدة، مما أدى إلى احتمال تغير تسعير الغاز، وتحتاج تنفيذات العملاء المختلفة إلى وقت كبير لإعادة تقييم استهلاك الغاز.
في يونيو 2021، تم طرح EIP-2537 رسميًا في الترقية Shanghai من خلال issues#343. ولكن يجب ملاحظة أنه بعد ترقية London، استحوذت في الواقع ترقية Pairs، المعروفة أيضًا باسم The Merge، على وقت كبير من المطورين، حيث كان يتعين على مطوري الطبقة التنفيذية كتابة كود كبير لتحقيق ترقية PoS. في سبتمبر 2022، اكتملت ترقية Pairs، وأتيحت أخيرًا لمطوري الطبقة التنفيذية الفرصة لمواصلة مناقشة بعض أهداف ترقية Shanghai.
في نوفمبر 2022، تم مناقشة إمكانية تضمين EIP-2537 في ترقية شنغهاي خلال اجتماع مطوري إيثيريوم الأساسي #150، لكن المطورين اعتبروا أن EIP-2537 يحتاج إلى تأجيل، حيث أن جوهر ترقية شنغهاي هو دعم سحب PoS. في النهاية، لم يتم تضمين EIP-2537 ضمن ترقية شنغهاي التي تركز على وظيفة السحب.
الأسوأ من ذلك هو أن ترقية كانكون لم تناقش EIP-2537 على الإطلاق، لأن جوهر ترقية كانكون هو دعم عقد الطبقة التنفيذية لـ EIP-4844. يوفر EIP-4844 Blob للطبقة الثانية من إيثريوم لتسهيل استخدام الطبقة الثانية لإيثريوم كطبقة لتوافر البيانات.
أخيرًا، في اجتماع مطوري Ethereum الأساسي #181 في فبراير 2024، ناقش المطورون تضمين EIP-2537 في ترقية Pectra، وفي ذلك الوقت اعتبر المطورون أن تنفيذ EIP-2537 لم يعد مشكلة، فقط بعض القضايا المتعلقة بتسعير استهلاك الغاز.
في اجتماع مطوري إيثريوم الأساسيين في 19 ديسمبر 2024 #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203 ، ناقش المطورون إعادة تسعير BLS السابق التجميع ، واقترح مطور Geth جاريد واسنجر زيادة تكلفة الغاز بنسبة 20٪ ، وحصل على دعم من فريق Besu للاختبارات المرجعية.
ملخص
!
من الواضح أن ما إذا كان EIP سيتم تضمينه في ترقية الإيثيريوم "بالطبع يعتمد على الكفاح الذاتي، ولكن يجب أيضًا مراعاة مسار التاريخ". كل ترقية للإيثيريوم لها موضوع خاص بها، تمامًا كما أصبح EIP-2537 أحد أهم EIPs في ترقية برلين، ولكن تم التخلي عنه بسبب صعوبة تنفيذه وتعقيده. بعد ذلك، دخل الإيثيريوم في مسار تاريخ PoS، حيث لم تحظ EIPs المعقدة الخاصة بطبقة التنفيذ الخالصة بالاهتمام، بينما تم اعتبار العديد من EIPs التنفيذية المتعلقة بـ PoS أهدافًا رئيسية للترقية، مما أدى إلى عدم قبول EIP-2537 لفترة طويلة.