การอัปเกรด Glamsterdam และการแก้ไขข้อบกพร่อง
นักพัฒนา Ethereum ได้รวมการแก้ไขข้อบกพร่องในการจัดการการฝากเงินในอัปเกรด Glamsterdam ที่กำลังจะมาถึง ซึ่งอาจทำให้ผู้สร้างบล็อกได้รับ ETH ที่ตั้งใจจะส่งให้กับตัวตรวจสอบใหม่ หลังจากการตัดสินใจเริ่มต้นที่จะปฏิเสธการเปลี่ยนแปลงที่เสนอ ตามข้อกำหนดการเห็นพ้องของ Ethereum ผู้ดูแล Justin Traglia ได้รวมการแก้ไขเมื่อวันที่ 26 ตุลาคม หลังจากที่นักพัฒนา avsetsin ระบุปัญหาเกี่ยวกับวิธีการที่การฝากเงินที่รอดำเนินการจะถูกประมวลผลในระหว่างการแยก Gloas.
การเปลี่ยนแปลงที่สำคัญ
การเปลี่ยนแปลงนี้แยกการฝากเงินของผู้สร้างออกจากการฝากเงินของตัวตรวจสอบตามข้อมูลการถอนของพวกเขา ป้องกันไม่ให้เงินเข้าสู่บัญชีที่ผิดเมื่อทั้งสองใช้กุญแจสาธารณะเดียวกัน ช่องโหว่นี้เกี่ยวข้องกับกฎที่กำลังพัฒนา ไม่ใช่การขโมยที่ยืนยันจากเครือข่ายหลักของ Ethereum นักพัฒนาได้รวมการแก้ไขนี้เข้าไปในข้อกำหนดแล้ว แม้ว่าลูกค้าการเห็นพ้องแต่ละรายยังต้องดำเนินการและทดสอบพฤติกรรมที่แก้ไขแล้ว
ปัญหาที่เกิดขึ้น
ปัญหานี้เกิดจากการเปลี่ยนแปลงที่วางแผนไว้ภายใต้การแยกผู้เสนอและผู้สร้างที่กำหนดไว้ใน Glamsterdam ซึ่งมอบหมายการสร้างบล็อกและการเสนอให้กับบทบาทที่แตกต่างกัน ผู้สร้างจะประกอบข้อมูลการทำธุรกรรม ในขณะที่ตัวตรวจสอบจะมีส่วนร่วมในการเสนอและยืนยันบล็อกผ่านระบบ proof-of-stake ของ Ethereum
“ผู้ดำเนินการสามารถถอนเงินของโปรโตคอลได้” avsetsin เตือนในรายงาน GitHub
นักวิจัย avsetsin ได้อธิบายข้อบกพร่องเมื่อวันที่ 12 ตุลาคม โดยระบุปัญหาในกฎที่ใช้ในการประมวลผลการฝากเงินที่รออยู่เมื่อเครือข่ายอัปเกรด หากผู้สร้างลงทะเบียนโดยใช้กุญแจสาธารณะก่อนที่การฝากเงินของตัวตรวจสอบจะมาถึงภายใต้กุญแจเดียวกัน ลอจิกที่เสนออาจเครดิตการฝากทั้งสองให้กับผู้สร้าง
การตอบสนองของนักพัฒนา
การแก้ไขที่เสนอในตอนแรกเผชิญกับการต่อต้านจากนักพัฒนาลูกค้า Ethereum แม้ว่านักวิจัยจะอธิบายถึงความเสี่ยงในการจัดการการฝากเงิน เมื่อวันที่ 19 ตุลาคม Traglia ได้ปิดคำขอการรวมหลังจากการอภิปรายระหว่างนักพัฒนาหลัก “ไม่มีการสนับสนุนจากลูกค้าเพียงพอในการทำการเปลี่ยนแปลงนี้ในขณะนี้” Traglia เขียน
การตัดสินใจนี้ไม่ได้คงอยู่ โดยนักพัฒนาได้เปิดข้อเสนออีกครั้งในวันที่ 23 ตุลาคม หลังจากการตรวจสอบเพิ่มเติม ต่อมา ผู้ตรวจสอบ potuz ได้อนุมัติแนวทางนี้ แต่ขอให้มีการทดสอบเพิ่มเติมสำหรับการรวมกันของการฝากเงินเฉพาะ
การทดสอบและการรวมเข้ากับข้อกำหนด
Avsetsin ได้เพิ่มการทดสอบเหล่านั้นในวันที่ 23 ตุลาคม โดยครอบคลุมกรณีที่การฝากเงินของผู้สร้างและตัวตรวจสอบแชร์กุญแจสาธารณะ แต่ต้องการการจัดการแยกต่างหาก การเปลี่ยนแปลงสุดท้ายได้ถูกรวมเข้ากับข้อกำหนดการเห็นพ้องของ Ethereum เมื่อวันที่ 26 ตุลาคม หลังจากการตรวจสอบลูกค้าเพิ่มเติม
มันจะนำการฝากเงินของตัวตรวจสอบที่ถูกต้องเข้าสู่คิวของตัวตรวจสอบในขณะที่อนุญาตให้การฝากเงินของผู้สร้างที่ถูกต้องลงทะเบียนหรือเพิ่มเงินให้กับผู้สร้างที่มีอยู่ กฎใหม่จะแยกการฝากเงินผ่านข้อมูลการถอน ซึ่งกำหนดการจัดการการถอนที่อนุญาต
การเลื่อนการอัปเกรด
การอัปเดตข้อกำหนดมาถึงในขณะที่นักพัฒนา Ethereum กำลังตรวจสอบปัญหาแยกต่างหากที่ส่งผลกระทบต่อการเปิดใช้งาน Glamsterdam ที่กำหนดไว้ในเครือข่ายทดสอบ Hoodi. มูลนิธิ Ethereum ได้เลื่อนการอัปเกรดในวันที่ 26 ตุลาคม หลังจากนักวิจัยระบุความเสี่ยงด้านความเข้ากันได้ที่เกี่ยวข้องกับ EIP-8037
ตามที่ crypto.news รายงานก่อนหน้านี้เกี่ยวกับการเลื่อน การตัดสินใจนี้ได้ลบการเปลี่ยนแปลงการดำเนินการ Amsterdam และการเปลี่ยนแปลงการเห็นพ้อง Gloas ออกจากการเปิดใช้งานที่วางแผนไว้ของ Hoodi การเพิ่มขีดจำกัดก๊าซเป็น 200 ล้านก็ถูกเลื่อนออกไปเช่นกัน
การตรวจสอบและการทดสอบเพิ่มเติม
นักวิจัย Ethereum Toni Wahrstätter อธิบายว่า EIP-8037 อาจรบกวนสัญญาอัจฉริยะที่พึ่งพาการสมมติว่าก๊าซยังคงอยู่ระหว่างการดำเนินการ เขาได้ระบุกรณีที่การบัญชีก๊าซอาจทำให้ธุรกรรมย้อนกลับโดยไม่คาดคิดหรืออนุญาตให้มีเส้นทางการดำเนินการที่นักพัฒนาสมมติว่าไม่สามารถเข้าถึงได้
ปัญหาความเข้ากันได้ของสัญญานั้นแตกต่างจากข้อบกพร่องในการฝากเงินของผู้สร้างที่ได้รับการแก้ไขในรายงาน GitHub ทั้งสองเกี่ยวข้องกับ Glamsterdam แต่การเลื่อนของมูลนิธิเมื่อวันที่ 22 ตุลาคมได้กล่าวถึงการตรวจสอบเพิ่มเติมเกี่ยวกับการโต้ตอบของ EIP-8037 กับสัญญาที่มีอยู่
Glamsterdam ได้เปิดใช้งานแล้วในเครือข่ายทดสอบ Sepolia เมื่อวันที่ 6 ตุลาคม ซึ่งนักพัฒนาได้ตรวจสอบการเปลี่ยนแปลงการสร้างบล็อกและความสามารถในการประมวลผลธุรกรรมที่สูงขึ้น การซ้อม Hoodi ที่ตามมายังคงไม่มีการกำหนดวันเวลา โดยไม่มีวันที่ยืนยันสำหรับการเปิดใช้งานในเครือข่ายหลักของ Ethereum
การแก้ไขการฝากที่ถูกรวมมีการทดสอบการถดถอยที่ครอบคลุมวิธีการที่การฝากเงินถูกจัดประเภทในระหว่างการเปลี่ยนแปลง Gloas. ทีมลูกค้าต้องรวมการเปลี่ยนแปลงข้อกำหนดนี้เข้ากับซอฟต์แวร์ของตนและดำเนินการทดสอบเพิ่มเติมก่อนที่กฎที่อัปเดตจะสามารถทำงานได้ในระหว่างการอัปเกรดเครือข่ายในอนาคต
