> บทความนี้จะนำเสนอประวัติการบริหารจัดการของ EIP-2537 และสำรวจว่าทำไมจึงใช้เวลา 5 ปีในการนำเสนอข้อเสนอนี้เข้าสู่การอัปเกรด. ### เขียนโดย：shew ## ภาพรวม EIP-2537 เป็นคำสั่ง Pre-assembly EVM ที่กำหนดเพิ่มในการอัปเกรดการแยก Pectra ล่าสุด คำสั่งนี้เพิ่มฟังก์ชันการคำนวณหลายอย่างของ BLS12-381 curve ให้กับ EVM เช่น การคำนวณการจับคู่ในโดเมนของ curve เป็นต้น. EIP-2573 ถูกเสนอครั้งแรกในปี 2020 และได้รับการยืนยันว่าจะรวมเข้ากับการอัปเกรด Ethereum ในปี 2025 บทความนี้จะนำเสนอประวัติการกำกับดูแลของ EIP-2537 และสำรวจว่าทำไมจึงใช้เวลาถึง 5 ปีในการนำข้อเสนอนี้เข้าสู่อัปเกรด. ## พื้นหลังของข้อเสนอ ในเดือนมกราคมปี 2017 Vitalik Buterin ได้นำเสนออัลกอริธึมการจับคู่และเส้นโค้ง alt\_bn128 เป็นครั้งแรกใน Exploring Elliptic Curve Pairings หลังจากนั้นในเดือนกุมภาพันธ์ปี 2017 Vitalik Buterin และ Christian Reitwiessner ได้เสนอข้อเสนอ EIP-196 และ EIP-197 โดยเนื้อหาของข้อเสนอคือการเพิ่มการสนับสนุนการคำนวณเส้นโค้ง alt\_bn128 ให้กับ EVM. ในการอัปเกรด Byzantium ในเดือนตุลาคมปี 2017 ได้มีการนำเข้า alt\_bn128 curve อย่างเป็นทางการ พูดง่ายๆ คือ alt\_bn128 ได้ทำการคำนวณการจับคู่โดเมนของเส้นโค้งภายใน EVM เป็นครั้งแรก ซึ่งทำให้การตรวจสอบการพิสูจน์ ZK-Snarks สามารถทำได้ภายใน EVM. แต่เมื่อการพัฒนาของวิทยาการเข้ารหัสดำเนินไป ในเดือนพฤศจิกายน 2017 ทีมพัฒนา zcash ได้เสนอ BLS12-381: New zk-SNARK Elliptic Curve Construction ซึ่งเป็นครั้งแรกที่นำเสนอเส้นโค้ง BLS12-381 ขึ้นมา เมื่อเปรียบเทียบกับ alt_bn128 เส้นโค้ง BLS12-381 มีความปลอดภัยสูงกว่าและประสิทธิภาพที่ดีกว่า โปรโตคอลบล็อกเชนจำนวนมากหลังจากนั้นได้ใช้เส้นโค้ง BLS12-381 และเลิกใช้เส้นโค้ง alt_bn128. ในเดือนพฤษภาคมปี 2018 Justin Drake ได้เผยแพร่เอกสาร Pragmatic signature aggregation with BLS ใน ethresear โดยชี้ให้เห็นว่าสำหรับการอัปเกรด PoS และ sharding ในอนาคตของ Ethereum สามารถใช้ BLS multi-signature algorithm ที่อิงจาก BLS12-381 curve ได้ ในขณะนั้นนักวิจัย Ethereum หวังที่จะใช้ EIP-1011 แก้ปัญหาชั้นการเห็นพ้อง แต่แผน EIP-1011 รองรับได้มากสุดเพียง 900 นักตรวจสอบ ดังนั้นจึงตั้งค่าความต้องการฝากที่สูงถึง 1500 ETH สำหรับนักตรวจสอบแต่ละคน เมื่อมีการเสนอแผน BLS multi-signature EIP-1011 ก็ถูกลบออกจากเวทีประวัติศาสตร์ พบว่าในภายหลังการอัปเกรด ETH2 ก็ใช้ BLS12-381 curve ในที่สุดด้วยเช่นกัน. ด้วยการพัฒนา ETH2 การแนะนํา BLS12-381 ที่ใช้โดย ETH2 ในชั้นการดําเนินการ ETH เริ่มถูกเรียก ในเดือนกุมภาพันธ์ 2020 นักวิจัยหลายคนเสนอ EIP-2537 และหวังว่าข้อเสนอนี้สามารถทดสอบร่วมกันบน ETH2 testnet ผู้เขียน EIP-2537 Alex Stokes เรียกร้องให้รวม EIP-2537 ไว้ใน Berlin hard fork ในสิ่งที่ eth2 ต้องการจาก eth1 ในบทความหกเดือนข้างหน้า น่าสนใจที่ผู้เขียน EIP-2537 ก็เป็นหนึ่งในผู้ก่อตั้ง Matter Labs และผลิตภัณฑ์ที่โด่งดังที่สุดของ Matter Labs คือ ZKSync ## Berlin ความวุ่นวาย ก่อนที่เราจะนำเสนอเนื้อหาต่อไป เราจำเป็นต้องแนะนำ 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 แยกจาก EIP-1962 ในเดือนกุมภาพันธ์ 2020 ซึ่ง EIP เหล่านี้ล้วนสืบทอดบางส่วนจากอินเทอร์เฟซของ EIP-1962 EIP เหล่านี้รวมถึง: * EIP-2537 สนับสนุน BLS12-381* EIP-2539 สนับสนุน BLS12-377* PR#2541 ให้การสนับสนุน BLS12-377 (Zexe curve) แต่โปรดทราบว่า ข้อเสนอนี้ไม่ได้รับหมายเลข EIP สุดท้าย จึงไม่สามารถค้นหาในเอกสาร EIP บนเว็บไซต์ทางการได้ EIP เหล่านี้ภายในนั้น EIP-2537 เป็นสิ่งที่สำคัญที่สุด เพราะชั้นการเห็นชอบยังใช้ BLS12-381 curve รวมถึงวัตถุประสงค์หลักของ EIP-1962 และ EIP-2537 ก็เพื่อให้สามารถตรวจสอบลายเซ็น BLS ในชั้นการเห็นชอบภายในเครือข่ายหลัก ในขณะนั้น ETH2 กำลังพัฒนาการออกแบบสัญญาเงินฝากสำหรับชั้นการเห็นชอบ เมื่อการออกแบบสัญญาเงินฝากในตอนแรก เนื่องจากชั้นการดำเนินการไม่มีอัลกอริธึมการตรวจสอบ BLS ดังนั้นสัญญาเงินฝากจะไม่ทำการตรวจสอบลายเซ็น ลายเซ็น BLS จะถูกตรวจสอบโดยชั้นการเห็นชอบหลังจากที่ผู้ใช้ทำการฝากเงิน หากพบว่ามีความไม่ถูกต้อง (สำหรับผู้ตรวจสอบใหม่) เงินฝากจะล้มเหลว และ ETH ที่ผู้ใช้ฝากจะหายไป. ในบริบทนี้ นักพัฒนาหลักต้องการนำ BLS12-381 พรีแอสเซมบลีเข้ามาใช้ในสัญญาฝากเงินเพื่อทำการตรวจสอบลายเซ็น โดยหลีกเลี่ยงความสูญเสียที่อาจเกิดขึ้นจากการฝากเงิน ETH2 ของผู้ใช้ นี่คือเหตุผลที่นักพัฒนาจำนวนมากให้ความสนใจกับ EIP-1962 และ EIP-2537 ในขณะนั้น. เมื่อ EIP-2537 ถูกเสนอขึ้นมาใหม่ ๆ วิทาลิคก็พบปัญหาชุดหนึ่งที่มีอยู่ใน EIP ทันที: ! [](https://img.gateio.im/social/moments-3cbd667f5db2fc97ec210fefb5dee418) แบบสอบถามเหล่านี้มุ่งเน้นไปที่เนื้อหาของเอกสาร EIP ซึ่งได้รับการตอบกลับและอภิปรายโดยผู้เขียน EIP ต่อมาเมื่อวันที่ 6 มีนาคม 2020 ที่ Ethereum Core Devs Meeting #82 EIP-2537 ได้รับการกล่าวถึงโดยนักพัฒนาหลักของ Ethereum ในระหว่างเซสชั่นนี้ Vitalik แย้งว่า EIPs เช่น EIP-2537 มีประสิทธิภาพมากสําหรับการพิสูจน์ SNARK ซ้ําและไม่สร้างความเสียหายให้กับ Ethereum ในระยะยาว ในเวลาเดียวกันลําดับความสําคัญของ EIP-2537 ได้รับการยืนยันและลูกค้าทั้งหมดตกลงที่จะใช้ EIP-2537 โดยเร็วที่สุดและวางแผนที่จะพัฒนาทั้งหมดให้เสร็จสิ้นก่อนการอัพเกรดเบอร์ลิน ต่อมา EIP-2537 ได้กลายเป็นภารกิจที่มีความสำคัญสูงขึ้น เมื่อวันที่ 20 มีนาคม 2020 ในการประชุม Ethereum Core Devs Meeting #83 EIP-2537 ยังคงเป็นข้อเสนอที่ถูกอภิปรายเป็นอันดับแรก การประชุมครั้งนี้ยืนยันว่า EIP-2537 จะมาแทนที่ EIP-1962 เพื่อเป็นข้อเสนอ BLS หลักและรวมอยู่ในรายชื่อ EIP ที่คัดเลือกไว้สำหรับการอัปเกรด Berlin ( นั่นคือ Eligibility for Inclusion (EFI)). ในการประชุม Ethereum Core Devs Meeting #84 ในเดือนเมษายน 2020 การประชุมได้อย่างเป็นทางการนำ EIP-2537 เข้าสู่การอัปเกรด Berlin Hard Fork และกำหนดกรอบเวลาสำหรับการดำเนินการในเดือนเมษายนและการทดสอบในเดือนพฤษภาคม - มิถุนายน การพูดคุยในครั้งนี้ EIP-2537 ถูกระบุว่าเป็นเรื่องที่มีลำดับความสำคัญสูงสุด. ! [](https://img.gateio.im/social/moments-4196e3cf52ca0c09f27a18bea998889d) ต่อจากนั้น EIP-2537 เข้าสู่ขั้นตอนการพัฒนาและการทดสอบจํานวนมากและในการประชุมนักพัฒนาหลักเกือบ 20 ครั้งการประชุมแต่ละครั้งเกี่ยวข้องกับการอภิปรายของ EIP-2537 ต่อไปเรามาดูกันว่าคําถามเกี่ยวกับ EIP-2537 ถูกกล่าวถึงในการประชุมแต่ละครั้ง ในการประชุม Ethereum Core Devs Meeting #85 Danno และ Axic ได้พูดคุยเกี่ยวกับปัญหาการเข้ารหัส ABI ของ EIP-2537 ต่อมา นักพัฒนาหลักได้ซิงโครไนซ์สถานะการดำเนินการในปัจจุบัน ซึ่งเนื่องจากผู้เสนอ EIP-2537 คือ Matter Labs ได้ทำการ implement เวอร์ชัน Rust เสร็จสิ้นไปแล้ว ดังนั้นลูกค้า Besu จึงประกาศว่าได้ดำเนินการฟังก์ชันของ EIP-2537 เสร็จสิ้นแล้ว แต่ Geth ระบุว่าในขณะนี้ยังไม่มีใครทำงานเกี่ยวกับการ implement EIP-2537. ในการประชุม Ethereum Core Devs Meeting #86 การดำเนินการของ EIP-2537 ที่แตกต่างกันของโหนด Ethereum ได้มีการซิงโครไนซ์กันอีกครั้ง ซึ่ง Geth ระบุว่าได้ทำงานบางส่วนเสร็จสิ้น แต่ยังมีงานจำนวนมากที่รอการทำให้เสร็จสมบูรณ์. ! [](https://img.gateio.im/social/moments-cd46b9475493fe9baa78df4a1fc777ec) ในการประชุม Ethereum Core Devs Meeting #87 เนื้อหาหลักของการประชุมผู้พัฒนาครั้งนี้คือปัญหาการนำ EIP-2537 ไปใช้ ผู้พัฒนา Geth กล่าวว่าขณะนี้มี PR ที่มีความยาว 16000 บรรทัดในการนำ EIP-2537 ไปใช้ แต่ผู้พัฒนา Geth ไม่สามารถยืนยันได้ว่า PR นั้นได้ถูกนำไปใช้อย่างปลอดภัยและมีประสิทธิภาพในการนำ EIP-2537 ไปใช้ ดังนั้นผู้พัฒนาจึงสามารถตัดสินสถานะของโค้ดได้เพียงผ่านการทดสอบแบบฟัซซี่ที่ง่ายและตรงไปตรงมาเท่านั้น. นักพัฒนา Geth กล่าวว่า: "ดังนั้นปฏิกิริยาในใจของฉันคือไม่มีโอกาสที่ Geth จะพร้อมกับการดำเนินการ BLS curve สำหรับการเปิดตัว mainnet ในเดือนกรกฎาคม" หมายความว่า Geth มีโอกาสสูงที่จะไม่สามารถเสร็จสิ้นการพัฒนาเกี่ยวกับ EIP-2537 ก่อนเวลาที่กำหนดใน Berlin. Hudson Jameson ได้เสนอให้หาวิศวกรเข้ารหัสเพื่อช่วยในการตรวจสอบ PR ของ Geth และยังได้เสนอให้ใช้ testnet ในการทดสอบความปลอดภัยของการใช้งาน EIP-2537 เนื่องจากตอนนี้ทีมพัฒนา ETH2 ก็กำลังทำการตรวจสอบ BLS signature verification ด้วย ดังนั้นทีม ETH2 จึงสามารถเข้าร่วมการทดสอบได้. ที่นี่เราจำเป็นต้องเสริมความรู้พื้นฐานว่า PR การดำเนินการ EIP-2537 ของ Geth ใช้โค้ดแอสเซมบลีจำนวนมากเพื่อให้มีประสิทธิภาพ ซึ่งโค้ดแอสเซมบลีนี้อ่านและเข้าใจได้ยากมาก ดังนั้น Alex Vlasov จึงแนะนำให้เอาการปรับแต่งแอสเซมบลีที่ซับซ้อนภายใน PR ออกเพื่อลดความยากในการตรวจสอบ. เราได้แนะนำไปแล้วในบทความข้างต้นว่า เป้าหมายหลักของ EIP-2537 คือการช่วยสัญญาเงินฝาก ETH2 แต่ในการประชุมครั้งนี้ ผู้พัฒนาสัญญาเงินฝากได้แสดงให้เห็นว่า สัญญาเงินฝากที่ไม่ใช้ EIP-2537 ได้ผ่านการตรวจสอบแล้ว ดังนั้นผู้พัฒนาส่วนหนึ่งจึงเสนอว่า ควรจะไม่พัฒนาสัญญาเงินฝากที่ใช้ EIP-2537 ขึ้นมาอีก สุดท้ายแล้ว ที่ประชุมได้ตัดสินใจเพิ่ม YOLO testnet ซึ่งเป็นการทดสอบ EIP-2537 โดยเฉพาะ ในความจริงแล้ว ในการประชุมครั้งนี้ เราสามารถเห็นความสำคัญของ EIP-2537 ที่ลดลงอย่างมากตามความสำเร็จของสัญญาเงินฝาก และในขณะนี้นักพัฒนาของ Geth เชื่อว่า EIP นี้มีความเป็นไปได้สูงที่จะไม่สามารถนำไปใช้ได้ก่อนการอัปเกรด Berlin ดูเหมือนว่า EIP-2537 จะไม่ได้รับการตอบรับจากการอัปเกรด Berlin อย่างแน่นอน. ในการประชุม Ethereum Core Devs Meeting #88 นักพัฒนาของ Geth พบว่ามีปัญหาหลายประการใน PR การนำ EIP-2537 มาใช้ นักพัฒนาระบุว่าจำเป็นต้องมีการทดสอบและแก้ไขเพิ่มเติม ในขณะนั้นมีการนำ EIP-2537 มาใช้สองรายการในระบบ Geth โดยหนึ่งในนั้นมีการปรับแต่งด้วยการเขียน Assembly ขณะที่อีกหนึ่งรายการเขียนโดยใช้ภาษา Go นักพัฒนาคนหนึ่งเสนอให้ใช้เวอร์ชันที่เขียนด้วยภาษา Go โดยตรงเพื่อลดความยุ่งยากในการตรวจสอบโค้ด. ใน Ethereum Core Devs Meeting #89 เกิดปัญหาร้ายแรงขึ้นกับการทดสอบ YOLO และนักพัฒนาสงสัยว่าปัญหานี้เกิดจากลายเซ็น BLS แต่นักพัฒนา EIP2537 ปฏิเสธโดยให้เหตุผลว่าปัญหา testnet ไม่ได้เกิดจากลายเซ็น BLS ข่าวดีสําหรับ EIP-2537 คือสัญญาเงินฝากที่ใช้ EIP-2537 ได้รับการพัฒนาโดยทั่วไปและสัญญากําลังรอการตรวจสอบสัญญา ในการประชุม Ethereum Core Devs Meeting #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 นักพัฒนาคนหนึ่งได้เสนอให้ใช้โซลูชันแบบโมดูลาร์เพื่อลดต้นทุนการพัฒนาเพื่อเพิ่มความหลากหลายของไคลเอนต์ หากผู้อ่านสนใจในความหลากหลายของไคลเอนต์ Ethereum สามารถไปอ่านบันทึกการประชุมทั้งสองครั้งนี้ได้ ในการประชุม Ethereum Core Devs Meeting #92 EIP 2537 ยังคงได้รับการยืนยันว่าเป็น EIP ที่จำเป็นสำหรับการอัปเกรด Berlin. ในการประชุม Ethereum Core Devs Meeting #96 ได้มีการนำ EIP-2537 และ EIP-2539 มาใช้ในการอัปเกรดฮาร์ดฟอร์กของเครือข่าย Celo ดังนั้น Matter Labs จึงหวังที่จะนำ EIP-2539 ซึ่งเสนอพร้อมกับ EIP-2537 มาทดสอบในเครือข่ายทดสอบ YOLO v2 และนำเข้าสู่อัปเกรด Berlin อย่างไรก็ตามนักพัฒนา Geth คัดค้าน โดยมองว่า EIP-2537 ยังไม่ได้ผ่านการทดสอบอย่างครบถ้วนใน Geth ในที่สุดการประชุมจึงตัดสินใจไม่เพิ่ม 2696 ในการอัปเกรด Berlin และให้รอการอภิปรายในอนาคต. ใน Ethereum Core Devs Meeting #99 มีการตัดสินใจที่จะย้าย EIP-2537 ออกจาก testnet YOLO v3 และการอัปเกรดเบอร์ลินเหตุผลหลักคือ EIP-2537 เสียเวลามากเกินไปสําหรับนักพัฒนาหลักและขัดขวางการพัฒนา EIP อื่น ๆ ภายในการอัพเกรดเบอร์ลิน ปัจจัยรองคือ Ethereum Foundation ได้เสนอ EVM384 แทน EIP-2537 ซึ่งเป็นวิธีแก้ปัญหาทั่วไปสําหรับการคํานวณเส้นโค้งวงรี อย่างไรก็ตามนักพัฒนาหลักแสดงความกังวลด้านความปลอดภัยในระหว่างการอภิปรายการประชุม นี่คือประวัติศาสตร์ช่วงต้นของ EIP-2537 ซึ่งเป็นหนึ่งใน EIPs ที่สําคัญที่สุดในการอัพเกรดเบอร์ลินในช่วงแรก ๆ แต่ในที่สุดก็ถูกยกเลิกเนื่องจากปัญหาการใช้งาน ในที่สุดในเดือนเมษายน 2021 Ethereum เสร็จสิ้นการอัพเกรดเบอร์ลินและการใช้งานจริงเช่น EIP-2565 ที่รวมอยู่ในหลักของการอัพเกรดนั้นไม่ซับซ้อนและดูเหมือนว่าการอัพเกรดเบอร์ลินจะบางลงเล็กน้อยเนื่องจาก EIP-2537 ที่ซับซ้อนที่สุดถูกไล่ออกจากการอัพเกรดเบอร์ลิน ! [](https://img.gateio.im/social/moments-d1344072659b676926596e29491399fb) ## การพัฒนาต่อเนื่อง เป็นที่ทราบกันดีว่า ทุกการอัปเกรดของ Ethereum จะมีข้อเสนอหลัก เช่น การอัปเกรด Berlin ที่ตามมาด้วยการอัปเกรด London ซึ่งได้นำเสนอข้อเสนอค่าธรรมเนียมที่สำคัญที่สุดในประวัติศาสตร์ของ Ethereum คือ EIP-1559 สำหรับ EIP-2537 ซึ่งเคยเป็นข้อเสนอหลัก การอัปเกรดครั้งต่อๆ ไปนั้นยากที่จะรวมข้อเสนอนี้เข้าไปได้. ในการอัปเกรดลอนดอนหลังจากเบอร์ลิน นักพัฒนาได้ซิงค์สถานะการพัฒนา EIP-2537 ใน issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109 ในขณะนั้นเนื่องจากการใช้ไลบรารีอื่นในการดำเนินการ EIP-2537 จึงได้มีการนำเสนอการอภิปรายเกี่ยวกับการใช้ gas ของ EIP-2537 ขณะเดียวกันก็มีนักพัฒนาคนหนึ่งเสนอให้ใช้ EVM384 แทนที่ EIP-2537 อย่างไรก็ตามในที่ประชุม Ethereum Core Devs Meeting #111 ในเดือนเมษายน 2021 EIP-2537 ถูกนำออกจากการอัปเกรดลอนดอนเนื่องจากความซับซ้อน ความซับซ้อนหลักคือการเปลี่ยนแปลงไลบรารีที่ใช้ในการดำเนินการ EIP-2537 อาจทำให้มีการเปลี่ยนแปลงการตั้งราคา gas การดำเนินการของไคลเอนต์ที่แตกต่างกันต้องใช้เวลาในการประเมินการใช้ gas ใหม่อย่างเหมาะสม. ในเดือนมิถุนายนปี 2021 ได้มีการเสนออย่างเป็นทางการใน issues#343 เพื่อรวม EIP-2537 เข้ากับการอัปเกรด Shanghai อย่างไรก็ตามควรสังเกตว่าหลังจากการอัปเกรด London จริง ๆ แล้วการอัปเกรด Pairs หรือที่เรียกว่า The Merge ได้ใช้เวลามากจากนักพัฒนา โดยนักพัฒนาชั้นการดำเนินการต้องเขียนโค้ดจำนวนมากเพื่อดำเนินการอัปเกรด PoS ในเดือนกันยายนปี 2022 การอัปเกรด Pairs เสร็จสิ้น และนักพัฒนาชั้นการดำเนินการในที่สุดก็มีโอกาสที่จะหารือเกี่ยวกับเป้าหมายบางอย่างของการอัปเกรด Shanghai ต่อไป. ในเดือนพฤศจิกายน 2022 การประชุม Ethereum Core Devs Meeting #150 ได้มีการหารือสั้น ๆ เกี่ยวกับการรวม EIP-2537 ในการอัปเกรด Shanghai แต่ผู้พัฒนามีความเห็นว่า EIP-2537 ควรที่จะเลื่อนออกไป เนื่องจากการอัปเกรด Shanghai มีจุดมุ่งหมายหลักในการสนับสนุนการถอนเงิน PoS สุดท้าย EIP-2537 ไม่ได้ถูกนำเข้ามาในอัปเกรด Shanghai ซึ่งมุ่งเน้นไปที่ฟังก์ชันการถอนเงิน. เรื่องที่น่าเศร้ายิ่งกว่านั้นคือการอัปเกรด Cancun ยังไม่มีการพูดคุยเกี่ยวกับ EIP-2537 เนื่องจากแกนหลักของการอัปเกรด Cancun คือการสนับสนุน EIP-4844 โดยโหนดชั้นการดำเนินการ EIP-4844 มอบ Blob ให้กับ Ethereum ชั้นสองเพื่อให้ชั้นสองสามารถใช้ Ethereum เป็นชั้นข้อมูลที่สามารถใช้งานได้. ในที่สุดในการประชุม Ethereum Core Devs Meeting #181 เดือนกุมภาพันธ์ 2024 นักพัฒนาได้หารือเกี่ยวกับการรวม EIP-2537 ไว้ในการอัปเกรด Pectra และ ณ จุดนี้นักพัฒนาตัดสินใจว่าการใช้งาน EIP-2537 ไม่ใช่ปัญหาอีกต่อไปเพียงส่วนหนึ่งของปัญหาคือการกําหนดราคาปริมาณการใช้ก๊าซ ในการประชุม Ethereum Core Devs Meeting #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203 วันที่ 19 ธันวาคม 2024 นักพัฒนาได้อภิปรายเกี่ยวกับการปรับราคาใหม่ของ BLS precompile โดยนักพัฒนา Geth Jared Wasinger เสนอให้เพิ่มค่าใช้จ่าย gas ขึ้น 20% และได้รับการสนับสนุนจากการทดสอบประสิทธิภาพของทีม Besu. ## สรุป ! [](https://img.gateio.im/social/moments-83869acb7e11edb61a8e7fe71d51d51f) เห็นได้ชัดว่า EIP จะถูกรวมไว้ในการอัปเกรด Ethereum หรือไม่ "แน่นอนว่าต้องพึ่งพาความตั้งใจของตัวเอง แต่ก็ต้องพิจารณาประวัติศาสตร์ด้วย" ทุกการอัปเกรด Ethereum จะมีธีมของตัวเอง เช่น EIP-2537 ที่เคยเป็น EIP ที่สำคัญที่สุดสำหรับการอัปเกรด Berlin แต่ถูกยกเลิกเนื่องจากความยากและความซับซ้อนในการดำเนินการ หลังจากนั้น Ethereum ก็เข้าสู่กระบวนการประวัติศาสตร์ของ PoS EIP ที่เป็นชั้นการดำเนินการที่ซับซ้อนจึงไม่เป็นที่สนใจ ในขณะที่ EIP ที่เกี่ยวข้องกับ PoS จำนวนมากถูกมองว่าเป็นเป้าหมายการอัปเกรดหลัก ทำให้ EIP-2537 ไม่ได้รับการยอมรับเป็นเวลานาน
Ethereum การสังเกตการบริหารจัดการ: EIP-2537 ประวัติการพรีแอสเซมบลี｜GCC Research
เขียนโดย：shew
ภาพรวม
EIP-2537 เป็นคำสั่ง Pre-assembly EVM ที่กำหนดเพิ่มในการอัปเกรดการแยก Pectra ล่าสุด คำสั่งนี้เพิ่มฟังก์ชันการคำนวณหลายอย่างของ BLS12-381 curve ให้กับ EVM เช่น การคำนวณการจับคู่ในโดเมนของ curve เป็นต้น.
EIP-2573 ถูกเสนอครั้งแรกในปี 2020 และได้รับการยืนยันว่าจะรวมเข้ากับการอัปเกรด Ethereum ในปี 2025 บทความนี้จะนำเสนอประวัติการกำกับดูแลของ EIP-2537 และสำรวจว่าทำไมจึงใช้เวลาถึง 5 ปีในการนำข้อเสนอนี้เข้าสู่อัปเกรด.
พื้นหลังของข้อเสนอ
ในเดือนมกราคมปี 2017 Vitalik Buterin ได้นำเสนออัลกอริธึมการจับคู่และเส้นโค้ง alt_bn128 เป็นครั้งแรกใน Exploring Elliptic Curve Pairings หลังจากนั้นในเดือนกุมภาพันธ์ปี 2017 Vitalik Buterin และ Christian Reitwiessner ได้เสนอข้อเสนอ EIP-196 และ EIP-197 โดยเนื้อหาของข้อเสนอคือการเพิ่มการสนับสนุนการคำนวณเส้นโค้ง alt_bn128 ให้กับ EVM.
ในการอัปเกรด Byzantium ในเดือนตุลาคมปี 2017 ได้มีการนำเข้า alt_bn128 curve อย่างเป็นทางการ พูดง่ายๆ คือ alt_bn128 ได้ทำการคำนวณการจับคู่โดเมนของเส้นโค้งภายใน EVM เป็นครั้งแรก ซึ่งทำให้การตรวจสอบการพิสูจน์ ZK-Snarks สามารถทำได้ภายใน EVM.
แต่เมื่อการพัฒนาของวิทยาการเข้ารหัสดำเนินไป ในเดือนพฤศจิกายน 2017 ทีมพัฒนา zcash ได้เสนอ BLS12-381: New zk-SNARK Elliptic Curve Construction ซึ่งเป็นครั้งแรกที่นำเสนอเส้นโค้ง BLS12-381 ขึ้นมา เมื่อเปรียบเทียบกับ alt_bn128 เส้นโค้ง BLS12-381 มีความปลอดภัยสูงกว่าและประสิทธิภาพที่ดีกว่า โปรโตคอลบล็อกเชนจำนวนมากหลังจากนั้นได้ใช้เส้นโค้ง BLS12-381 และเลิกใช้เส้นโค้ง alt_bn128.
ในเดือนพฤษภาคมปี 2018 Justin Drake ได้เผยแพร่เอกสาร Pragmatic signature aggregation with BLS ใน ethresear โดยชี้ให้เห็นว่าสำหรับการอัปเกรด PoS และ sharding ในอนาคตของ Ethereum สามารถใช้ BLS multi-signature algorithm ที่อิงจาก BLS12-381 curve ได้ ในขณะนั้นนักวิจัย Ethereum หวังที่จะใช้ EIP-1011 แก้ปัญหาชั้นการเห็นพ้อง แต่แผน EIP-1011 รองรับได้มากสุดเพียง 900 นักตรวจสอบ ดังนั้นจึงตั้งค่าความต้องการฝากที่สูงถึง 1500 ETH สำหรับนักตรวจสอบแต่ละคน เมื่อมีการเสนอแผน BLS multi-signature EIP-1011 ก็ถูกลบออกจากเวทีประวัติศาสตร์ พบว่าในภายหลังการอัปเกรด ETH2 ก็ใช้ BLS12-381 curve ในที่สุดด้วยเช่นกัน.
ด้วยการพัฒนา ETH2 การแนะนํา BLS12-381 ที่ใช้โดย ETH2 ในชั้นการดําเนินการ ETH เริ่มถูกเรียก ในเดือนกุมภาพันธ์ 2020 นักวิจัยหลายคนเสนอ EIP-2537 และหวังว่าข้อเสนอนี้สามารถทดสอบร่วมกันบน ETH2 testnet ผู้เขียน EIP-2537 Alex Stokes เรียกร้องให้รวม EIP-2537 ไว้ใน Berlin hard fork ในสิ่งที่ eth2 ต้องการจาก eth1 ในบทความหกเดือนข้างหน้า
น่าสนใจที่ผู้เขียน EIP-2537 ก็เป็นหนึ่งในผู้ก่อตั้ง Matter Labs และผลิตภัณฑ์ที่โด่งดังที่สุดของ Matter Labs คือ ZKSync
Berlin ความวุ่นวาย
ก่อนที่เราจะนำเสนอเนื้อหาต่อไป เราจำเป็นต้องแนะนำ EIP-1962 ก่อน EIP-1962 เป็นข้อเสนอแรกเกี่ยวกับการเตรียมการพรีแอสเซมบลีของการจับคู่โดเมนวงรีที่เสนอโดย Matter Labs ในเดือนเมษายน 2019 โดยข้อเสนอนี้รองรับสามเส้นโค้ง ได้แก่:
EIP นี้เตรียมเพิ่มคำสั่งแอสเซมบลีพรีที่ 10 คำสั่งเพื่อจัดการกับเส้นโค้งต่างๆ อย่างไรก็ตามหลังจากที่ข้อเสนอเกิดขึ้น นักพัฒนาจำนวนมากตั้งคำถามว่าข้อเสนอนั้นซับซ้อนเกินไปจนทำให้การพัฒนาทำได้ยาก พร้อมกับที่ EIP1962 มีความเป็นสากลสูง ทำให้การเรียกใช้สำหรับวิศวกรสมาร์ทคอนแทรกต์นั้นยุ่งยากมาก แน่นอนว่าในฐานะที่เป็นผู้เสนอ EIP-1962 Matter Labs ได้ทำงานพัฒนาอัลกอริธึมเส้นโค้งเอลิปติกเสร็จสิ้นแล้ว และได้จัดเตรียมการใช้งานอ้างอิงใน Rust / Go / C++ ไว้ให้ด้วย.
เพื่อแก้ไขปัญหาของ EIP-1962 Matter Labs ได้เสนอหลาย EIP แยกจาก EIP-1962 ในเดือนกุมภาพันธ์ 2020 ซึ่ง EIP เหล่านี้ล้วนสืบทอดบางส่วนจากอินเทอร์เฟซของ EIP-1962 EIP เหล่านี้รวมถึง:
EIP เหล่านี้ภายในนั้น EIP-2537 เป็นสิ่งที่สำคัญที่สุด เพราะชั้นการเห็นชอบยังใช้ BLS12-381 curve รวมถึงวัตถุประสงค์หลักของ EIP-1962 และ EIP-2537 ก็เพื่อให้สามารถตรวจสอบลายเซ็น BLS ในชั้นการเห็นชอบภายในเครือข่ายหลัก ในขณะนั้น ETH2 กำลังพัฒนาการออกแบบสัญญาเงินฝากสำหรับชั้นการเห็นชอบ เมื่อการออกแบบสัญญาเงินฝากในตอนแรก เนื่องจากชั้นการดำเนินการไม่มีอัลกอริธึมการตรวจสอบ BLS ดังนั้นสัญญาเงินฝากจะไม่ทำการตรวจสอบลายเซ็น ลายเซ็น BLS จะถูกตรวจสอบโดยชั้นการเห็นชอบหลังจากที่ผู้ใช้ทำการฝากเงิน หากพบว่ามีความไม่ถูกต้อง (สำหรับผู้ตรวจสอบใหม่) เงินฝากจะล้มเหลว และ ETH ที่ผู้ใช้ฝากจะหายไป.
ในบริบทนี้ นักพัฒนาหลักต้องการนำ BLS12-381 พรีแอสเซมบลีเข้ามาใช้ในสัญญาฝากเงินเพื่อทำการตรวจสอบลายเซ็น โดยหลีกเลี่ยงความสูญเสียที่อาจเกิดขึ้นจากการฝากเงิน ETH2 ของผู้ใช้ นี่คือเหตุผลที่นักพัฒนาจำนวนมากให้ความสนใจกับ EIP-1962 และ EIP-2537 ในขณะนั้น.
เมื่อ EIP-2537 ถูกเสนอขึ้นมาใหม่ ๆ วิทาลิคก็พบปัญหาชุดหนึ่งที่มีอยู่ใน EIP ทันที:
!
แบบสอบถามเหล่านี้มุ่งเน้นไปที่เนื้อหาของเอกสาร EIP ซึ่งได้รับการตอบกลับและอภิปรายโดยผู้เขียน EIP ต่อมาเมื่อวันที่ 6 มีนาคม 2020 ที่ Ethereum Core Devs Meeting #82 EIP-2537 ได้รับการกล่าวถึงโดยนักพัฒนาหลักของ Ethereum ในระหว่างเซสชั่นนี้ Vitalik แย้งว่า EIPs เช่น EIP-2537 มีประสิทธิภาพมากสําหรับการพิสูจน์ SNARK ซ้ําและไม่สร้างความเสียหายให้กับ Ethereum ในระยะยาว ในเวลาเดียวกันลําดับความสําคัญของ EIP-2537 ได้รับการยืนยันและลูกค้าทั้งหมดตกลงที่จะใช้ EIP-2537 โดยเร็วที่สุดและวางแผนที่จะพัฒนาทั้งหมดให้เสร็จสิ้นก่อนการอัพเกรดเบอร์ลิน
ต่อมา EIP-2537 ได้กลายเป็นภารกิจที่มีความสำคัญสูงขึ้น เมื่อวันที่ 20 มีนาคม 2020 ในการประชุม Ethereum Core Devs Meeting #83 EIP-2537 ยังคงเป็นข้อเสนอที่ถูกอภิปรายเป็นอันดับแรก การประชุมครั้งนี้ยืนยันว่า EIP-2537 จะมาแทนที่ EIP-1962 เพื่อเป็นข้อเสนอ BLS หลักและรวมอยู่ในรายชื่อ EIP ที่คัดเลือกไว้สำหรับการอัปเกรด Berlin ( นั่นคือ Eligibility for Inclusion (EFI)).
ในการประชุม Ethereum Core Devs Meeting #84 ในเดือนเมษายน 2020 การประชุมได้อย่างเป็นทางการนำ EIP-2537 เข้าสู่การอัปเกรด Berlin Hard Fork และกำหนดกรอบเวลาสำหรับการดำเนินการในเดือนเมษายนและการทดสอบในเดือนพฤษภาคม - มิถุนายน การพูดคุยในครั้งนี้ EIP-2537 ถูกระบุว่าเป็นเรื่องที่มีลำดับความสำคัญสูงสุด.
!
ต่อจากนั้น EIP-2537 เข้าสู่ขั้นตอนการพัฒนาและการทดสอบจํานวนมากและในการประชุมนักพัฒนาหลักเกือบ 20 ครั้งการประชุมแต่ละครั้งเกี่ยวข้องกับการอภิปรายของ EIP-2537 ต่อไปเรามาดูกันว่าคําถามเกี่ยวกับ EIP-2537 ถูกกล่าวถึงในการประชุมแต่ละครั้ง
ในการประชุม Ethereum Core Devs Meeting #85 Danno และ Axic ได้พูดคุยเกี่ยวกับปัญหาการเข้ารหัส ABI ของ EIP-2537 ต่อมา นักพัฒนาหลักได้ซิงโครไนซ์สถานะการดำเนินการในปัจจุบัน ซึ่งเนื่องจากผู้เสนอ EIP-2537 คือ Matter Labs ได้ทำการ implement เวอร์ชัน Rust เสร็จสิ้นไปแล้ว ดังนั้นลูกค้า Besu จึงประกาศว่าได้ดำเนินการฟังก์ชันของ EIP-2537 เสร็จสิ้นแล้ว แต่ Geth ระบุว่าในขณะนี้ยังไม่มีใครทำงานเกี่ยวกับการ implement EIP-2537.
ในการประชุม Ethereum Core Devs Meeting #86 การดำเนินการของ EIP-2537 ที่แตกต่างกันของโหนด Ethereum ได้มีการซิงโครไนซ์กันอีกครั้ง ซึ่ง Geth ระบุว่าได้ทำงานบางส่วนเสร็จสิ้น แต่ยังมีงานจำนวนมากที่รอการทำให้เสร็จสมบูรณ์.
!
ในการประชุม Ethereum Core Devs Meeting #87 เนื้อหาหลักของการประชุมผู้พัฒนาครั้งนี้คือปัญหาการนำ EIP-2537 ไปใช้ ผู้พัฒนา Geth กล่าวว่าขณะนี้มี PR ที่มีความยาว 16000 บรรทัดในการนำ EIP-2537 ไปใช้ แต่ผู้พัฒนา Geth ไม่สามารถยืนยันได้ว่า PR นั้นได้ถูกนำไปใช้อย่างปลอดภัยและมีประสิทธิภาพในการนำ EIP-2537 ไปใช้ ดังนั้นผู้พัฒนาจึงสามารถตัดสินสถานะของโค้ดได้เพียงผ่านการทดสอบแบบฟัซซี่ที่ง่ายและตรงไปตรงมาเท่านั้น.
นักพัฒนา Geth กล่าวว่า: "ดังนั้นปฏิกิริยาในใจของฉันคือไม่มีโอกาสที่ Geth จะพร้อมกับการดำเนินการ BLS curve สำหรับการเปิดตัว mainnet ในเดือนกรกฎาคม" หมายความว่า Geth มีโอกาสสูงที่จะไม่สามารถเสร็จสิ้นการพัฒนาเกี่ยวกับ EIP-2537 ก่อนเวลาที่กำหนดใน Berlin.
Hudson Jameson ได้เสนอให้หาวิศวกรเข้ารหัสเพื่อช่วยในการตรวจสอบ PR ของ Geth และยังได้เสนอให้ใช้ testnet ในการทดสอบความปลอดภัยของการใช้งาน EIP-2537 เนื่องจากตอนนี้ทีมพัฒนา ETH2 ก็กำลังทำการตรวจสอบ BLS signature verification ด้วย ดังนั้นทีม ETH2 จึงสามารถเข้าร่วมการทดสอบได้.
ที่นี่เราจำเป็นต้องเสริมความรู้พื้นฐานว่า PR การดำเนินการ EIP-2537 ของ Geth ใช้โค้ดแอสเซมบลีจำนวนมากเพื่อให้มีประสิทธิภาพ ซึ่งโค้ดแอสเซมบลีนี้อ่านและเข้าใจได้ยากมาก ดังนั้น Alex Vlasov จึงแนะนำให้เอาการปรับแต่งแอสเซมบลีที่ซับซ้อนภายใน PR ออกเพื่อลดความยากในการตรวจสอบ.
เราได้แนะนำไปแล้วในบทความข้างต้นว่า เป้าหมายหลักของ EIP-2537 คือการช่วยสัญญาเงินฝาก ETH2 แต่ในการประชุมครั้งนี้ ผู้พัฒนาสัญญาเงินฝากได้แสดงให้เห็นว่า สัญญาเงินฝากที่ไม่ใช้ EIP-2537 ได้ผ่านการตรวจสอบแล้ว ดังนั้นผู้พัฒนาส่วนหนึ่งจึงเสนอว่า ควรจะไม่พัฒนาสัญญาเงินฝากที่ใช้ EIP-2537 ขึ้นมาอีก
สุดท้ายแล้ว ที่ประชุมได้ตัดสินใจเพิ่ม YOLO testnet ซึ่งเป็นการทดสอบ EIP-2537 โดยเฉพาะ ในความจริงแล้ว ในการประชุมครั้งนี้ เราสามารถเห็นความสำคัญของ EIP-2537 ที่ลดลงอย่างมากตามความสำเร็จของสัญญาเงินฝาก และในขณะนี้นักพัฒนาของ Geth เชื่อว่า EIP นี้มีความเป็นไปได้สูงที่จะไม่สามารถนำไปใช้ได้ก่อนการอัปเกรด Berlin ดูเหมือนว่า EIP-2537 จะไม่ได้รับการตอบรับจากการอัปเกรด Berlin อย่างแน่นอน.
ในการประชุม Ethereum Core Devs Meeting #88 นักพัฒนาของ Geth พบว่ามีปัญหาหลายประการใน PR การนำ EIP-2537 มาใช้ นักพัฒนาระบุว่าจำเป็นต้องมีการทดสอบและแก้ไขเพิ่มเติม ในขณะนั้นมีการนำ EIP-2537 มาใช้สองรายการในระบบ Geth โดยหนึ่งในนั้นมีการปรับแต่งด้วยการเขียน Assembly ขณะที่อีกหนึ่งรายการเขียนโดยใช้ภาษา Go นักพัฒนาคนหนึ่งเสนอให้ใช้เวอร์ชันที่เขียนด้วยภาษา Go โดยตรงเพื่อลดความยุ่งยากในการตรวจสอบโค้ด.
ใน Ethereum Core Devs Meeting #89 เกิดปัญหาร้ายแรงขึ้นกับการทดสอบ YOLO และนักพัฒนาสงสัยว่าปัญหานี้เกิดจากลายเซ็น BLS แต่นักพัฒนา EIP2537 ปฏิเสธโดยให้เหตุผลว่าปัญหา testnet ไม่ได้เกิดจากลายเซ็น BLS ข่าวดีสําหรับ EIP-2537 คือสัญญาเงินฝากที่ใช้ EIP-2537 ได้รับการพัฒนาโดยทั่วไปและสัญญากําลังรอการตรวจสอบสัญญา
ในการประชุม Ethereum Core Devs Meeting #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 นักพัฒนาคนหนึ่งได้เสนอให้ใช้โซลูชันแบบโมดูลาร์เพื่อลดต้นทุนการพัฒนาเพื่อเพิ่มความหลากหลายของไคลเอนต์ หากผู้อ่านสนใจในความหลากหลายของไคลเอนต์ Ethereum สามารถไปอ่านบันทึกการประชุมทั้งสองครั้งนี้ได้
ในการประชุม Ethereum Core Devs Meeting #92 EIP 2537 ยังคงได้รับการยืนยันว่าเป็น EIP ที่จำเป็นสำหรับการอัปเกรด Berlin.
ในการประชุม Ethereum Core Devs Meeting #96 ได้มีการนำ EIP-2537 และ EIP-2539 มาใช้ในการอัปเกรดฮาร์ดฟอร์กของเครือข่าย Celo ดังนั้น Matter Labs จึงหวังที่จะนำ EIP-2539 ซึ่งเสนอพร้อมกับ EIP-2537 มาทดสอบในเครือข่ายทดสอบ YOLO v2 และนำเข้าสู่อัปเกรด Berlin อย่างไรก็ตามนักพัฒนา Geth คัดค้าน โดยมองว่า EIP-2537 ยังไม่ได้ผ่านการทดสอบอย่างครบถ้วนใน Geth ในที่สุดการประชุมจึงตัดสินใจไม่เพิ่ม 2696 ในการอัปเกรด Berlin และให้รอการอภิปรายในอนาคต.
ใน Ethereum Core Devs Meeting #99 มีการตัดสินใจที่จะย้าย EIP-2537 ออกจาก testnet YOLO v3 และการอัปเกรดเบอร์ลินเหตุผลหลักคือ EIP-2537 เสียเวลามากเกินไปสําหรับนักพัฒนาหลักและขัดขวางการพัฒนา EIP อื่น ๆ ภายในการอัพเกรดเบอร์ลิน ปัจจัยรองคือ Ethereum Foundation ได้เสนอ EVM384 แทน EIP-2537 ซึ่งเป็นวิธีแก้ปัญหาทั่วไปสําหรับการคํานวณเส้นโค้งวงรี อย่างไรก็ตามนักพัฒนาหลักแสดงความกังวลด้านความปลอดภัยในระหว่างการอภิปรายการประชุม
นี่คือประวัติศาสตร์ช่วงต้นของ EIP-2537 ซึ่งเป็นหนึ่งใน EIPs ที่สําคัญที่สุดในการอัพเกรดเบอร์ลินในช่วงแรก ๆ แต่ในที่สุดก็ถูกยกเลิกเนื่องจากปัญหาการใช้งาน ในที่สุดในเดือนเมษายน 2021 Ethereum เสร็จสิ้นการอัพเกรดเบอร์ลินและการใช้งานจริงเช่น EIP-2565 ที่รวมอยู่ในหลักของการอัพเกรดนั้นไม่ซับซ้อนและดูเหมือนว่าการอัพเกรดเบอร์ลินจะบางลงเล็กน้อยเนื่องจาก EIP-2537 ที่ซับซ้อนที่สุดถูกไล่ออกจากการอัพเกรดเบอร์ลิน
!
การพัฒนาต่อเนื่อง
เป็นที่ทราบกันดีว่า ทุกการอัปเกรดของ Ethereum จะมีข้อเสนอหลัก เช่น การอัปเกรด Berlin ที่ตามมาด้วยการอัปเกรด London ซึ่งได้นำเสนอข้อเสนอค่าธรรมเนียมที่สำคัญที่สุดในประวัติศาสตร์ของ Ethereum คือ EIP-1559 สำหรับ EIP-2537 ซึ่งเคยเป็นข้อเสนอหลัก การอัปเกรดครั้งต่อๆ ไปนั้นยากที่จะรวมข้อเสนอนี้เข้าไปได้.
ในการอัปเกรดลอนดอนหลังจากเบอร์ลิน นักพัฒนาได้ซิงค์สถานะการพัฒนา EIP-2537 ใน issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109 ในขณะนั้นเนื่องจากการใช้ไลบรารีอื่นในการดำเนินการ EIP-2537 จึงได้มีการนำเสนอการอภิปรายเกี่ยวกับการใช้ gas ของ EIP-2537 ขณะเดียวกันก็มีนักพัฒนาคนหนึ่งเสนอให้ใช้ EVM384 แทนที่ EIP-2537 อย่างไรก็ตามในที่ประชุม Ethereum Core Devs Meeting #111 ในเดือนเมษายน 2021 EIP-2537 ถูกนำออกจากการอัปเกรดลอนดอนเนื่องจากความซับซ้อน ความซับซ้อนหลักคือการเปลี่ยนแปลงไลบรารีที่ใช้ในการดำเนินการ EIP-2537 อาจทำให้มีการเปลี่ยนแปลงการตั้งราคา gas การดำเนินการของไคลเอนต์ที่แตกต่างกันต้องใช้เวลาในการประเมินการใช้ gas ใหม่อย่างเหมาะสม.
ในเดือนมิถุนายนปี 2021 ได้มีการเสนออย่างเป็นทางการใน issues#343 เพื่อรวม EIP-2537 เข้ากับการอัปเกรด Shanghai อย่างไรก็ตามควรสังเกตว่าหลังจากการอัปเกรด London จริง ๆ แล้วการอัปเกรด Pairs หรือที่เรียกว่า The Merge ได้ใช้เวลามากจากนักพัฒนา โดยนักพัฒนาชั้นการดำเนินการต้องเขียนโค้ดจำนวนมากเพื่อดำเนินการอัปเกรด PoS ในเดือนกันยายนปี 2022 การอัปเกรด Pairs เสร็จสิ้น และนักพัฒนาชั้นการดำเนินการในที่สุดก็มีโอกาสที่จะหารือเกี่ยวกับเป้าหมายบางอย่างของการอัปเกรด Shanghai ต่อไป.
ในเดือนพฤศจิกายน 2022 การประชุม Ethereum Core Devs Meeting #150 ได้มีการหารือสั้น ๆ เกี่ยวกับการรวม EIP-2537 ในการอัปเกรด Shanghai แต่ผู้พัฒนามีความเห็นว่า EIP-2537 ควรที่จะเลื่อนออกไป เนื่องจากการอัปเกรด Shanghai มีจุดมุ่งหมายหลักในการสนับสนุนการถอนเงิน PoS สุดท้าย EIP-2537 ไม่ได้ถูกนำเข้ามาในอัปเกรด Shanghai ซึ่งมุ่งเน้นไปที่ฟังก์ชันการถอนเงิน.
เรื่องที่น่าเศร้ายิ่งกว่านั้นคือการอัปเกรด Cancun ยังไม่มีการพูดคุยเกี่ยวกับ EIP-2537 เนื่องจากแกนหลักของการอัปเกรด Cancun คือการสนับสนุน EIP-4844 โดยโหนดชั้นการดำเนินการ EIP-4844 มอบ Blob ให้กับ Ethereum ชั้นสองเพื่อให้ชั้นสองสามารถใช้ Ethereum เป็นชั้นข้อมูลที่สามารถใช้งานได้.
ในที่สุดในการประชุม Ethereum Core Devs Meeting #181 เดือนกุมภาพันธ์ 2024 นักพัฒนาได้หารือเกี่ยวกับการรวม EIP-2537 ไว้ในการอัปเกรด Pectra และ ณ จุดนี้นักพัฒนาตัดสินใจว่าการใช้งาน EIP-2537 ไม่ใช่ปัญหาอีกต่อไปเพียงส่วนหนึ่งของปัญหาคือการกําหนดราคาปริมาณการใช้ก๊าซ
ในการประชุม Ethereum Core Devs Meeting #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203 วันที่ 19 ธันวาคม 2024 นักพัฒนาได้อภิปรายเกี่ยวกับการปรับราคาใหม่ของ BLS precompile โดยนักพัฒนา Geth Jared Wasinger เสนอให้เพิ่มค่าใช้จ่าย gas ขึ้น 20% และได้รับการสนับสนุนจากการทดสอบประสิทธิภาพของทีม Besu.
สรุป
!
เห็นได้ชัดว่า EIP จะถูกรวมไว้ในการอัปเกรด Ethereum หรือไม่ "แน่นอนว่าต้องพึ่งพาความตั้งใจของตัวเอง แต่ก็ต้องพิจารณาประวัติศาสตร์ด้วย" ทุกการอัปเกรด Ethereum จะมีธีมของตัวเอง เช่น EIP-2537 ที่เคยเป็น EIP ที่สำคัญที่สุดสำหรับการอัปเกรด Berlin แต่ถูกยกเลิกเนื่องจากความยากและความซับซ้อนในการดำเนินการ หลังจากนั้น Ethereum ก็เข้าสู่กระบวนการประวัติศาสตร์ของ PoS EIP ที่เป็นชั้นการดำเนินการที่ซับซ้อนจึงไม่เป็นที่สนใจ ในขณะที่ EIP ที่เกี่ยวข้องกับ PoS จำนวนมากถูกมองว่าเป็นเป้าหมายการอัปเกรดหลัก ทำให้ EIP-2537 ไม่ได้รับการยอมรับเป็นเวลานาน