นักพัฒนา Ethereum แก้บั๊กระบบสำเร็จ ก่อนเริ่มการอัปเกรดใหญ่ Glamsterdam

นักพัฒนา EthereumETH-4.09% แก้ช่องโหว่ Validator Cache สำเร็จ

นักพัฒนา Ethereum ได้แก้ไขบั๊กเทคนิคที่ซ่อนอยู่ ก่อนที่มันจะสร้างปัญหากระทบเครือข่ายจริง โดยเมื่อวันที่ 13 พฤศจิกายน 2026 ผู้สื่อข่าว Arman Shirinyan ได้ชี้ให้เห็น pull request บน GitHub ซึ่งเป็นแพตช์ความปลอดภัยที่ถูกรวมเข้าไปใน consensus client ของ Ethereum เรียบร้อยแล้ว

แพตช์นี้มาช่วยแก้ช่องโหว่การโจมตีแบบ validator pubkey cache poisoning โดยเจาะจงแก้ปัญหารอบๆ การอัปเกรด Gloas fork ซึ่งเป็นส่วนประกอบในชั้น consensus layer สำหรับการอัปเกรด Glamsterdam ที่กำลังจะมาถึง

หากไม่มีการแก้ปัญหานี้ บั๊กดังกล่าวอาจทำให้โหนดบางส่วนในเครือข่ายปฏิเสธลายเซ็นที่ถูกต้องในระหว่างการทำ fork ส่งผลให้โหนดที่ได้รับผลกระทบหลุดแยกออกจากบล็อกเชนหลักได้

ฝากเงิน 3 รายการกับ 2 เชน: บั๊กนี้ทำงานอย่างไร?

ปัญหาหลักมาจากวิธีที่ consensus client จัดการข้อมูลใน cache ตัว client จะเก็บ public key ของ validator และเลข index ที่คู่กันไว้ใน global cache เพื่อให้ประมวลผลได้เร็วขึ้น

โดยปกติแล้ว รายการฝากเงินที่เสร็จสมบูรณ์จะสร้างรายชื่อ validator ที่เหมือนกันทุกประการบนทุกเชนของเครือข่าย แต่กรณีพิเศษอาจเกิดขึ้นได้ตรงรอยต่อของการทำ fork

ในการฉวยโอกาสจากช่องโหว่นี้ ผู้โจมตีจะต้องมีรายการฝากเงินที่รอประมวลผล 3 รายการ เรียงต่อกันพอดีก่อนเกิดการ fork:

• รายการฝากที่ 1: การเติมเงินก้อนใหญ่ให้กับ validator เดิมที่มีอยู่ในเครือข่าย
• รายการฝากที่ 2 (Key A): public key ใหม่เอี่ยมที่มีสิทธิ์ของ builder
• รายการฝากที่ 3 (Key B): public key ใหม่เอี่ยมที่มีสิทธิ์ของ validator ทั่วไป

บนเชนหลัก (canonical chain) รายการเติมเงินจะใช้โควตาสูงสุดของยอดเงินคงเหลือที่มี ส่งผลให้ Key A และ Key B ถูกประมวลผลต่อทันทีหลังการ fork โดย Key A จะได้เป็น builder ส่วน Key B จะได้รับเลข index ของ validator ทั่วไปถัดไป

อย่างไรก็ตาม ผู้โจมตีอาจสร้างเชนลับ (side chain) ขึ้นมา โดยสั่ง slashing ตัว validator ที่เพิ่งเติมเงินไปก่อนเกิดการ fork การถูก slash นี้จะทำให้ข้ามรายการเติมเงินไปเลย

การข้ามรายการฝากเงินเปิดทางให้ Key A ถูกประมวลผลเร็วขึ้นบนเชนลับ และแย่งตำแหน่ง index ที่ควรจะเป็นของ Key B ไป ระบบ global cache ที่มีบั๊กจะสมมุติว่าทั้งสองเชนสร้างรายการเหมือนกัน และบันทึก Key A ไว้ในระบบส่วนกลาง

พอถึงจังหวะการทำ fork โหนดที่มีข้อมูล cache เสียหายก็จะปฏิเสธลายเซ็นที่ถูกต้องของ Key B บนเชนหลัก และหลุดแยกออกจากเชนหลักโดยไม่ตั้งใจ

โชคดีที่การโจมตีนี้ต้องอาศัยจังหวะเวลาที่แม่นยำมาก ต้องมีเชนลับ และต้องจัดฉากเหตุการณ์ slashing อีก ด้วยความซับซ้อนนี้ บั๊กดังกล่าวจึงมีโอกาสเกิดขึ้นเองโดยบังเอิญได้ยากมาก

แพตช์อัปเดตนี้เข้ามาแก้ปัญหาอย่างไร?

การอัปเดตใหม่นี้ได้เปลี่ยนช่วงเวลาบันทึกข้อมูล key ลงในหน่วยความจำ โดยตัว client จะรอจนกว่า epoch ที่ได้รับสิทธิ์เปิดใช้งานจะได้รับการยืนยันขั้นสมบูรณ์ (finalized) เสียก่อน จึงค่อยบันทึก key ลงใน global pubkey cache

นอกจากนี้ นักพัฒนายังสร้างฟีเจอร์ใหม่ที่เรียกว่าโครงสร้าง Head Pubkeys กลไกนี้จะรวม key จากสถานะ head state และ global cache เข้าด้วยกัน

ด้วยการอัปเดตนี้ โหนดจะไม่หลุดการติดตาม key ต่างๆ แม้ว่าเชนจะเสร็จสมบูรณ์โดยไม่ได้สร้างบล็อกใหม่ก็ตาม

ขั้นตอนต่อไปจะเกิดอะไรขึ้น?

ขณะนี้ยังไม่มีการยืนยันว่าทีมพัฒนา consensus client อื่นๆ ของ Ethereum พบข้อผิดพลาดเรื่อง caching แบบเดียวกันนี้ด้วยหรือไม่

เมื่อวันอัปเกรด Glamsterdam ใกล้เข้ามา นักพัฒนาจึงเร่งค้นหาและแก้ไขกรณีพิเศษที่ซับซ้อนเพื่อปกป้องเครือข่ายอย่างเต็มที่

คุณสามารถติดตามแนวโน้มตลาดของ Ethereum (ETH) ในขณะที่การอัปเดตดำเนินไป ผลการดำเนินงานในอดีตของสินทรัพย์ดิจิทัลมิได้เป็นสิ่งยืนยันถึงผลการดำเนินงานในอนาคต