บทวิจารณ์ฉบับสมบูรณ์ของการหยุดให้บริการ 4 ชั่วโมงของ Lighter: เหตุใด PerpDex จึง "ปิดตัวลง" ในคืนที่เกิดการชำระบัญชีมูลค่า 19 พันล้านดอลลาร์?
- 核心观点:Lighter因技术架构缺陷导致宕机亏损。
- 关键要素:
- 单一排序器过载引发单点故障。
- ZK证明生成瓶颈延迟清算执行。
- 交易量激增至平常79.8倍致系统崩溃。
- 市场影响:暴露PerpDex技术瓶颈,促进行业升级。
- 时效性标注:中期影响。
ที่มา: Beosin
เมื่อวันที่ 11 ตุลาคม ตลาดคริปโทเคอร์เรนซีเผชิญกับการเรียกหลักประกัน (margin call) ครั้งใหญ่ที่สุดในประวัติศาสตร์ โดยมียอดการชำระบัญชีรวมประมาณ 1.9 หมื่นล้านดอลลาร์สหรัฐ ในช่วงการทดสอบตลาดที่รุนแรงนี้ แพลตฟอร์มซื้อขายแบบกระจายศูนย์ (Perpetual Swap) หลายแพลตฟอร์ม (PerpDex) ประสบปัญหาขัดข้อง โดย Lighter ได้รับผลกระทบรุนแรงที่สุด การสูญเสียที่เกิดขึ้นในกลุ่มผู้ให้บริการสภาพคล่อง (LLP) ก่อให้เกิดการถกเถียงกันอย่างกว้างขวางในตลาดเกี่ยวกับแพลตฟอร์ม PerpDex
เนื่องจากเป็นบริษัทรักษาความปลอดภัย Web3 ที่ ได้ตรวจสอบแพลตฟอร์ม Perp Dex หลายแห่ง รวมถึง Surf Protocol และ Tifo.trade บริษัท Beosin จึงจะนำเทคโนโลยีที่สะสมมาหลายปีและประสบการณ์การวิเคราะห์ข้อมูลบนเชนมาใช้เพื่อช่วยให้ทุกคน มีความเข้าใจที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับสาเหตุของการหยุดให้บริการของ Lighter
กรอบเทคโนโลยีที่เบากว่า
Lighter โดดเด่นท่ามกลางกระแสความนิยมของ PerpDex ด้วยค่าธรรมเนียมการทำธุรกรรมที่เป็นศูนย์ ดึงดูดผู้ใช้จำนวนมากให้เข้ามาซื้อขายบนแพลตฟอร์ม Lighter สร้างขึ้น บน zkLight ซึ่งเป็น ZK Rollup L2 เฉพาะทาง เพื่อเพิ่มประสิทธิภาพการทำธุรกรรมและประสิทธิภาพการจับคู่คำสั่งซื้อขาย กลไกการทำงานหลักแสดงไว้ด้านล่าง:

Sorter : เนื่องจากเป็นจุดแรกในการโต้ตอบกับผู้ใช้ จึงมีหน้าที่รับคำสั่งธุรกรรม จัดเรียงธุรกรรม และแพ็กเก็ตข้อมูลเป็นชุด (แพ็กเก็ตข้อมูลชุดของธุรกรรม)
ระบบจับคู่ จะรับชุดข้อมูลจากเครื่องเรียงลำดับและ ปฏิบัติตามตรรกะการจับคู่แบบ "ราคาก่อน เวลาก่อน" อย่างเคร่งครัด การจับคู่ที่ประสบความสำเร็จแต่ละครั้งจะเตรียมข้อมูลเพื่อสร้างหลักฐานแบบ Zero-Knowledge เพื่อให้แน่ใจว่าทุกคนสามารถตรวจสอบความยุติธรรมของกระบวนการจับคู่ได้ในภายหลัง ป้องกันการบิดเบือนข้อมูล
Prover : สร้างการทำงานของเครื่องจับคู่เป็นหลักฐาน ZK-SNARK ที่กระชับ สำหรับการตรวจยืนยันความถูกต้องของการดำเนินการจับคู่และการเปลี่ยนสถานะในภายหลัง
สัญญาเมนเน็ต : รับผิดชอบในการตรวจสอบหลักฐานความรู้ศูนย์ที่ส่งโดยผู้พิสูจน์ เมื่อตรวจสอบแล้ว รากสถานะจะได้รับการอัปเดต และผลลัพธ์ของธุรกรรมจะได้รับการยืนยันบน Ethereum ในที่สุด
นอกเหนือจากฟีเจอร์ข้างต้นแล้ว Lighter ยังมีฟีเจอร์ Vault ให้กับผู้ใช้ ซึ่งช่วยให้ผู้ใช้สามารถฝากเงินเข้า Lighter Liquidity Pool (LLP) ได้ คลัง สภาพคล่องนี้ทำหน้าที่เป็นทั้งผู้ให้สภาพคล่อง ผู้กำหนดราคา และแพลตฟอร์มการบริหารความเสี่ยง ผู้เข้าร่วม LLP จะได้รับส่วนแบ่งกำไรและผลขาดทุนจากคู่สัญญาบนแพลตฟอร์ม ขณะเดียวกันก็ต้องรับความเสี่ยงบางส่วนในกรณีที่ผู้ใช้ถูกเรียกหลักประกัน ซึ่งถือเป็นกลไกบัฟเฟอร์ความเสี่ยงที่ทำงานร่วมกับระบบการชำระบัญชีของ Lighter
การตรวจสอบระยะเวลาหยุดทำงานที่เบากว่า
เมื่อวันที่ 11 ตุลาคม 2568 ตลาดคริปโตมียอดการชำระบัญชีสัญญาที่ทำลายสถิติ ท่ามกลางสถานการณ์ตลาดที่ตึงเครียดเช่นนี้ Lighter ประสบปัญหาการหยุดให้บริการนานหลายชั่วโมง ส่งผลให้ผู้ใช้ไม่สามารถดำเนินการตามสถานะของตนได้ และส่งผลให้ขาดทุนประมาณ 5.35% ใน LLP
Beosin วิเคราะห์ข้อมูลบนเครือข่ายในช่วงเวลาหลักของเหตุการณ์นี้ (00:17-05:08 ตามเวลาปักกิ่ง ในวันที่ 11 ตุลาคม 2025) และพบว่า Lighter สูญเสียข้อมูลสามชุดเริ่มจากชุดที่ #55661 และกลับมาดำเนินการผลิตชุดใหม่ในเวลา 00:17 น. (ในเวลา 00:23 น. Lighter ได้ออกประกาศแจ้งว่าไม่สามารถประมวลผลหรือดำเนินการตามคำสั่งของผู้ใช้ได้)
ก่อนเกิดการขัดข้อง แพลตฟอร์ม Lighter ประมวลผลธุรกรรมได้ประมาณ 4,005 รายการต่อนาที ตั้งแต่เวลา 00:17 น. ปริมาณธุรกรรมเพิ่มขึ้นอย่างรวดเร็ว ชุด ที่ 55665 ประกอบด้วย 560 บล็อก และประมวลผลธุรกรรมได้ 196,913 รายการ โดยเฉลี่ยแล้ว มีการประมวลผลธุรกรรมประมาณ 65,638 รายการต่อนาที ซึ่งเร็วกว่าเวลาประมวลผลปกติประมาณ 16 เท่า
ต่อไปนี้เป็นแผนภูมิสถิติของจำนวนธุรกรรมที่ดำเนินการในแต่ละจุดเวลาการส่งชุดตั้งแต่ 00:17 น. ถึง 05:08 น. ในวันที่ 11 ตุลาคม:

จัดทำโดย Beosin Statistics
เวลา 04:56 น. ของวันที่ 11 ตุลาคม แบตช์ หมายเลข 55743 มีจำนวนธุรกรรมสูงสุดที่ทำได้ โดย ทำธุรกรรมเสร็จสิ้น 639,370 รายการภายในสองนาที ซึ่งสูงกว่าอัตราการทำธุรกรรมเฉลี่ยต่อนาทีถึง 79.8 เท่า จากการวิเคราะห์ข้อมูลของ Lighter จากเหตุการณ์นี้ เราพบ ว่าแบตช์ของ Lighter สามารถรองรับบล็อกได้สูงสุด 1,600 บล็อก โดยแต่ละบล็อกมีธุรกรรมสูงสุด 500 รายการ จำนวนธุรกรรมสูงสุดตามทฤษฎีต่อแบตช์คือ 800,000 รายการ แต่จำนวนธุรกรรมสูงสุดจริงคือ 639,370 รายการ
ธุรกรรมข้างต้นคือธุรกรรมที่แพลตฟอร์ม Lighter ดำเนินการสำเร็จ อย่างไรก็ตาม ผู้ใช้หลายรายไม่สามารถปรับตำแหน่งได้เนื่องจากความล้มเหลวในการส่งธุรกรรม (เวลาหยุดทำงาน) ส่งผลให้ข้อมูลไม่ได้รับการบันทึกลงในเชน จากมุมมองด้านสถาปัตยกรรมทางเทคนิค เวลาหยุดทำงานนี้และการสูญเสียที่เกิดขึ้นจาก LLP เกิดจากสองสาเหตุหลัก:
1. นอกจากปัญหาในการเข้าถึงหน้า front-end และการส่งคำสั่งซื้อแล้ว ZK Rollup ของ Lighter ยังใช้เครื่องเรียงลำดับเพียงเครื่องเดียวสำหรับการเรียงลำดับและการบรรจุธุรกรรม แม้ว่า ZK Proof จะถูกใช้สำหรับการตรวจสอบผลลัพธ์ แต่การรวมศูนย์ของเครื่องเรียงลำดับยังก่อให้เกิดความเสี่ยงจากจุดล้มเหลวเพียงจุดเดียว ในช่วงที่ราคาลดลง เครื่องเรียงลำดับและฐานข้อมูลจะไม่สามารถรับมือกับภาระงานที่เกิดขึ้นอย่างกะทันหัน ส่งผลให้เกิดความเสียหายต่อดัชนีฐานข้อมูลและการบล็อกธุรกรรม ซึ่งนำไปสู่การตัดการเชื่อมต่อระหว่างเครื่องจับคู่และไคลเอนต์โดยตรง
2. เมื่อปริมาณธุรกรรมเพิ่มสูงขึ้น ความสามารถในการประมวลผลที่ประสานกันของโหนดสร้างหลักฐานและฐานข้อมูลจะกลายเป็นปัญหาคอขวดในกระบวนการสร้างหลักฐานและส่งข้อมูลของ ZK-SNARK ในสภาวะตลาดที่รุนแรง การจับคู่การซื้อขายและการหักบัญชีที่เพิ่มขึ้นพร้อมกันจะเริ่มต้นคำขอไปยังโหนดสร้างหลักฐานของ ZK พร้อมกัน แพลตฟอร์มอาจไม่ได้นำกลไกการจองทรัพยากรมาใช้สำหรับงานที่มีความสำคัญสูง เช่น การหักบัญชี ทำให้เกิดการแข่งขันทรัพยากรระหว่างธุรกรรมปกติและคำขอสร้างหลักฐานการหักบัญชี ส่งผลให้การตอบสนองของระบบล่าช้ายิ่งขึ้น และ กระบวนการหักบัญชีไม่สามารถดำเนินการได้อย่างรวดเร็ว ส่งผลให้เกิดการสูญเสียของผู้ใช้มากขึ้น
ในระดับปฏิบัติการ วลาดิเมียร์ โนวาคอฟสกี ซีอีโอของ Lighter ตอบว่า "เดิมที Lighter วางแผนที่จะอัปเกรดฐานข้อมูลในช่วงสุดสัปดาห์ที่เกิดเหตุการณ์ล่มเมื่อเร็วๆ นี้ เพื่อรองรับความต้องการในการซื้อขายที่เพิ่มขึ้น" เหตุการณ์นี้ชี้ให้เห็นว่า "ช่วงเวลาอัปเกรดที่ไม่ถูกต้อง" นี้เกิดจากทีมงานที่เตรียมความพร้อมรับมือกับความเสี่ยงในตลาดไม่เพียงพอ ในช่วงที่แพลตฟอร์มขยายตัวอย่างรวดเร็ว พวกเขาไม่สามารถอัปเกรดโครงสร้างพื้นฐานให้เสร็จทันเวลา ส่งผลให้เกิดความล้มเหลวของระบบในสภาวะตลาดที่เลวร้ายในที่สุด
เหตุการณ์นี้เผยให้เห็นถึงความท้าทายหลักที่ PerpDex กำลังเผชิญ นั่นคือ การรักษาการดำเนินงานของแพลตฟอร์มให้เป็นปกติในสภาวะตลาดที่ผันผวน ในส่วนของความปลอดภัยของสัญญาอัจฉริยะ ทีมโครงการของ PerpDex ควรดำเนินการตรวจสอบความปลอดภัยของสัญญาอย่างครอบคลุมและเป็นมืออาชีพ Beosin เคยให้บริการตรวจสอบความปลอดภัยแก่โครงการ PerpDex เช่น Surf Protocol และ Tifo.trade การตรวจสอบเหล่านี้ ครอบคลุมถึงความปลอดภัยของโค้ดสัญญาอัจฉริยะ ความถูกต้องของตรรกะในการนำไปใช้งานทางธุรกิจ (เช่น การซื้อขายแบบเลเวอเรจ การชำระบัญชี และการจัดการกลุ่มสภาพคล่อง) การเพิ่มประสิทธิภาพโค้ดแก๊สสัญญา และการค้นพบและแก้ไขช่องโหว่ที่อาจเกิดขึ้น Beosin ประสบความสำเร็จในการช่วยให้ทีมโครงการแก้ไขช่องโหว่ความเสี่ยงปานกลางและสูงหลายรายการ

https://www.beosin.com/audits/Surf%20Protocol%20V2_202403281200.pdf
นอกจากนี้ ทีมโครงการ Perp Dex ยังต้องพิจารณาถึงความซ้ำซ้อนทางสถาปัตยกรรมและกลไกการรับมือเหตุฉุกเฉิน ในอนาคต ด้วยการประยุกต์ใช้เทคโนโลยีต่างๆ เช่น ตัวเรียงลำดับหลายตัวและการจัดตารางทรัพยากรแบบไดนามิก คาดว่า Perp Dex จะสามารถแก้ไขปัญหาคอขวดในปัจจุบันนี้ รองรับผู้ใช้งานได้มากขึ้น และกลายเป็นโครงสร้างพื้นฐานหลักของระบบการเงินคริปโต


