ช่องโหว่ที่น่ากลัวบน Solana ถูกเปิดเผย: แฮกเกอร์เกือบทำให้เครือข่ายล่มสลาย

เมื่อทีมบำรุงรักษา Solana เรียกร้องให้ validator อัปเกรดเป็น Agave v3.0.14 อย่างเร่งด่วน ข้อความที่ออกมามีระดับความเร่งด่วนสูงกว่าข้อมูลทางเทคนิค

บัญชีสถานะของ Solana เรียกการปล่อยเวอร์ชันนี้ว่า “ฉุกเฉิน” ซึ่งรวมถึง “การแก้ไขสำคัญหลายรายการ” สำหรับ validator บน Mainnet Beta

ภายในเวลาเพียงหนึ่งวัน การอภิปรายสาธารณะได้เปลี่ยนเป็นคำถามที่ซับซ้อนขึ้น: หากเครือข่าย PoS ต้องการอัปเกรดพร้อมกันในเวลาสั้น ๆ จะเกิดอะไรขึ้นเมื่อผู้ดำเนินการไม่สามารถประสานงานกันได้?

ช่องว่างนั้นชัดเจนในตัวเลขการใช้งานเบื้องต้น วันที่ 11/1 บัญชีที่แชร์กันอย่างแพร่หลายรายงานว่า มีเพียงประมาณ 18% ของ stake ที่ถูกอัปเกรดเป็น v3.0.14 ณ เวลานั้น ซึ่งหมายความว่าส่วนใหญ่ของ “มูลค่าทางเศรษฐกิจ” ของเครือข่ายยังคงรันเวอร์ชันเก่าอยู่ในช่วงที่ถูกระบุว่าเป็นฉุกเฉิน

สำหรับบล็อกเชนที่ใช้เวลาทั้งปีในการส่งเสริมความน่าเชื่อถือควบคู่กับความเร็ว เรื่องราวจึงเปลี่ยนจากตัวซอฟต์แวร์ไปเป็นคำถามว่า ทีมงานสามารถรวบรวมตัวเองได้รวดเร็วพอเมื่อสถานการณ์สำคัญจริงหรือไม่

ในช่วงประมาณ 10 วันที่ผ่านมา ภาพรวมเริ่มชัดเจนและเป็นประโยชน์มากกว่าหัวข้อข่าวแรก

Anza ซึ่งเป็นกลุ่มเบื้องหลัง Agave ได้ประกาศสรุปการแก้ไขด้านความปลอดภัยเมื่อวันที่ 16/1 อธิบายว่าทำไม v3.0.14 จึงสำคัญ และทำไมผู้ดำเนินการจึงถูกขอให้เร่งอัปเกรด

ในเวลาเดียวกัน ระบบนิเวศของ Solana ส่งสัญญาณว่าการประสานงานไม่ใช่แค่เรื่องความตั้งใจดีเท่านั้น แต่ยังมีเกณฑ์การอนุมัติ stake ของ Solana Foundation ที่ชัดเจนเกี่ยวกับเวอร์ชันซอฟต์แวร์ รวมถึง Agave 3.0.14 และ Frankendancer 0.808.30014 เป็นส่วนหนึ่งของมาตรฐานที่ validator ต้องปฏิบัติตามเพื่อให้สามารถรับ stake ที่ได้รับอนุมัติได้ต่อไป

โดยรวม เหตุการณ์เหล่านี้ทำให้ v3.0.14 กลายเป็นกรณีศึกษาว่า “การเงินที่ทำงานเสมอ” ต้องการอะไรบน Solana ในความเป็นจริง — ไม่ใช่แค่ซอฟต์แวร์ แต่รวมถึงกลไกจูงใจและพฤติกรรมการดำเนินงานภายใต้แรงกดดันของเวลา

บล็อกเชนความเร็วสูงยังคงขึ้นอยู่กับมนุษย์ที่ดำเนินการ

Solana เป็นบล็อกเชนแบบ proof-of-stake ที่ออกแบบมาเพื่อรองรับปริมาณธุรกรรมจำนวนมากด้วยความเร็วสูง validator ลงคะแนนเสียงสำหรับบล็อกและรักษาความปลอดภัยของสมุดบัญชีตามสัดส่วน SOL ที่ได้รับอนุญาต

สำหรับผู้ใช้ที่ไม่ได้รัน validator เอง การมอบหมาย stake ให้กับ operator จึงเป็นทั้งกลไกความปลอดภัยและสัญญาณทางเศรษฐกิจ ซึ่งเป็นรางวัลให้ validator ที่ทำงานเสถียรและมีประสิทธิภาพ

การออกแบบนี้ส่งผลให้เกิดผลลัพธ์ที่อาจถูกมองข้ามหากดูแค่กราฟราคาโทเคน บล็อกเชนไม่ใช่เครื่องจักรที่ตั้งอยู่ในที่เดียวกัน “เครือข่าย” บน Solana คือกลุ่มของ operator อิสระนับพันที่รันซอฟต์แวร์ที่เข้ากันได้ อัปเกรดในเวลาที่ต่างกัน บนโครงสร้างพื้นฐานที่แตกต่างกัน ด้วยระดับอัตโนมัติและความเสี่ยงที่แตกต่างกัน

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

ภาพรวมของ client บน Solana ยิ่งเพิ่มความสำคัญของการประสานงานมากขึ้น โดย client ที่นิยมที่สุดในปัจจุบันคือสาย fork Agave ของ Anza ที่ดูแลรักษาไว้ นอกจากนี้ เครือข่ายยังมุ่งเน้นการกระจาย client ผ่านความพยายามของ Firedancer จาก Jump Crypto โดยมี Frankendancer เป็นจุดกึ่งกลาง

การมี client ที่หลากหลายสามารถลดความเสี่ยงจากข้อผิดพลาดเดียวที่อาจทำให้ stake ส่วนใหญ่หยุดทำงานพร้อมกัน แต่ก็ไม่สามารถละเลยความจำเป็นในการอัปเกรดด้านความปลอดภัยแบบพร้อมกันได้ เมื่อมีการปล่อยแพตช์ที่มีความอ่อนไหวด้านเวลา

นี่คือบริบทที่ v3.0.14 เข้ามาเกี่ยวข้อง ความเร่งด่วนนี้มีเป้าหมายเพื่อปิดเส้นทางที่อาจนำไปสู่การหยุดชะงักก่อนที่จะถูกโจมตี

สิ่งที่เปลี่ยนแปลงใน 10 วันที่ผ่านมา: เหตุผลที่เปิดเผยและแรงจูงใจทางเศรษฐกิจที่ปรากฏ

ประกาศของ Anza ได้เติมเต็มส่วนที่ขาดหายไปของเรื่องราว สองช่องโหว่ที่เป็นไปได้รุนแรงถูกเปิดเผยในธันวาคม 2025 ผ่านคำแนะนำด้านความปลอดภัยบน GitHub Anza ระบุว่าปัญหาเหล่านี้ได้รับการแก้ไขร่วมกับ Firedancer, Jito และ Solana Foundation แล้ว

ช่องโหว่แรกเกี่ยวข้องกับระบบ gossip ของ Solana — กลไกที่ validator แชร์ข้อความบางส่วนของเครือข่าย แม้ในขณะที่กระบวนการสร้างบล็อกหยุดชะงัก ตามคำอธิบายของ Anza ข้อผิดพลาดในการจัดการข้อความบางประเภทอาจทำให้ validator ล่มในเงื่อนไขบางอย่าง หากถูกโจมตีแบบร่วมมือและ stake ที่ถูกโจมตีจำนวนมาก ความพร้อมใช้งานของเครือข่ายโดยรวมอาจลดลงอย่างมีนัยสำคัญ

ช่องโหว่ที่สองเกี่ยวข้องกับการโหวต — ศูนย์กลางของกลไกฉันทามติ ตามคำอธิบายของ Anza การตรวจสอบที่ขาดหายไปอาจอนุญาตให้ผู้โจมตีทำให้ validator ล้นด้วยข้อความโหวตที่ไม่ถูกต้อง สร้างความสับสนในกระบวนการโหวตปกติ และอาจทำให้ฉันทามติหยุดชะงักในระดับสูง

แพตช์นี้รับประกันว่าข้อความโหวตจะได้รับการตรวจสอบอย่างถูกต้องก่อนเข้าสู่กระบวนการในระหว่างการสร้างบล็อก

ข้อมูลเหล่านี้เปลี่ยนมุมมองต่อเรื่อง “การใช้งานช้า” เดิม การอัปเกรดฉุกเฉินนี้ปิดเส้นทางสองเส้นทางที่อาจนำไปสู่การหยุดชะงักรุนแรง: หนึ่งคือการทำให้ validator ล่ม, อีกหนึ่งคือการรบกวนกลไกโหวตในระดับสูง

คำถามด้านความสามารถในการดำเนินงานยังคงสำคัญ แต่กลายเป็นรายละเอียดมากขึ้น: ทีมงานแบบกระจายสามารถปล่อยแพตช์ได้รวดเร็วแค่ไหนเมื่อสถานการณ์ผิดปกติชัดเจนและเป็นระบบ?

พร้อมกันนั้น ข้อกำหนดการอนุมัติ stake ของ Solana ทำให้กลไกการประสานงานชัดเจนขึ้น เกณฑ์ของ Solana Foundation รวมถึงข้อกำหนดด้านเวอร์ชันซอฟต์แวร์และมาตรฐานการตอบสนอง ลิสต์เวอร์ชันบังคับที่ประกาศในหลาย epoch รวมถึง Agave 3.0.14 และ Frankendancer 0.808.30014

สำหรับ operator ที่ได้รับการอนุมัติจาก Foundation การอัปเกรดกลายเป็นเรื่องเศรษฐกิจ: หากไม่ปฏิบัติตามข้อกำหนดอาจถูกถอน stake ที่ได้รับอนุมัติ จนกว่าจะผ่านมาตรฐาน

นี่คือความเป็นจริงในการดำเนินงานเบื้องหลังแนวคิด “การเงินที่ทำงานเสมอ” ซึ่งสร้างขึ้นจากโค้ด แต่ดำเนินการด้วยแรงจูงใจทางเศรษฐกิจ, dashboards สำหรับการตรวจสอบ และมาตรฐานที่ผลักดันให้บุคคลอิสระนับพันมารวมตัวกันในช่วงเวลาสั้น ๆ ที่เกิดจากความผิดพลาดด้านความปลอดภัย

อย่างไรก็ตาม แม้จะประกาศชัดเจนและมีแรงจูงใจทางเศรษฐกิจ การอัปเกรดอย่างรวดเร็วก็ยังไม่ราบรื่น Anza ระบุว่าผู้ดำเนินการต้องสร้างจาก source ตามคำแนะนำของพวกเขา

การสร้างจาก source ไม่ใช่ความเสี่ยงโดยอัตโนมัติ แต่เพิ่มภาระด้านการดำเนินงาน เนื่องจาก validator ต้องพึ่งพา pipeline การสร้าง, การจัดการ dependency และการทดสอบภายในก่อนนำไปสู่สภาพแวดล้อม production

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

เหตุการณ์ v3.0.14 ก็ไม่ได้หยุดการปล่อยเวอร์ชันของ Solana ในวงกว้าง

วันที่ 19/1 โค้ดเบส Agave ออกเวอร์ชัน v3.1.7 ซึ่งเป็นเวอร์ชันทดสอบและแนะนำสำหรับ devnet รวมถึงสูงสุด 10% ของ mainnet beta แสดงให้เห็นว่ามี pipeline ที่เปลี่ยนแปลงอย่างต่อเนื่อง ซึ่ง operator ต้องติดตามและวางแผน วันที่ 22/1 หน้าแผนงานของ v3.1 ของ Agave ก็อัปเดตต่อเนื่องด้วยแผนการปล่อยตามคาด

ระดับความพร้อมจึงกลายเป็นสิ่งที่สามารถวัดได้ด้วยตัวชี้วัดเฉพาะ

ตัวชี้วัดแรกคือความเร็วในการรวมเวอร์ชันภายใต้แรงกดดัน หมายถึงปริมาณ stake ที่เปลี่ยนไปเป็นเวอร์ชันที่แนะนำอย่างรวดเร็วเมื่อเกิดการแจ้งเตือนฉุกเฉิน รายงานเบื้องต้นเกี่ยวกับ v3.0.14 แสดงให้เห็นว่าค่าใช้จ่ายของการช้าในการเคลื่อนย้าย

ตัวชี้วัดที่สองคือความสามารถในการต้านทานข้อผิดพลาดพร้อมกันในวงกว้าง การมี client ที่หลากหลายผ่าน Firedancer และ Frankendancer ช่วยลดความเสี่ยงที่ซอฟต์แวร์สายเดียวจะทำให้เครือข่ายล่ม แต่ต้องเป็นไปตามระดับการใช้งานที่เพียงพอของ client ที่เปลี่ยนแปลง

ตัวชี้วัดที่สามคือระดับความสอดคล้องของแรงจูงใจทางเศรษฐกิจ ซึ่งเกณฑ์การอนุมัติและข้อกำหนดเวอร์ชันเปลี่ยน “ความปลอดภัยเชิงกลยุทธ์” ให้กลายเป็นเงื่อนไขทางเศรษฐกิจที่จำเป็นสำหรับหลาย operator

เหตุการณ์ v3.0.14 เริ่มต้นด้วยป้าย “ฉุกเฉิน” และความกังวลเกี่ยวกับความเร็วในการใช้งาน แล้วค่อย ๆ กลายเป็นมุมมองที่ชัดเจนมากขึ้นเกี่ยวกับวิธีที่ Solana จัดการแก้ไขข้อผิดพลาด, ประสานงาน และบังคับใช้มาตรฐานบนทีม validator ที่กระจายตัว

วังเจี้ยน