ที่มา: ชุมชน AZEx

ในช่วงเช้าตรู่ของวันที่ 26 สิงหาคม XPL เผชิญกับความผันผวนของราคา Hyperliquid เป็นเวลาหลายนาที:
05:36 คำสั่งซื้อจำนวนมหาศาลทำให้สมุดคำสั่งซื้อว่างเปล่า โดยแต่ละการซื้อขายมีมูลค่าตั้งแต่หลักหมื่นไปจนถึงหลักแสนดอลลาร์ ทำให้ราคา XPL พุ่งสูงขึ้นอย่างรวดเร็ว
05:36–05:55 ราคาเป้าหมาย ซึ่งถูกครอบงำโดยการจับคู่ตลาดภายใน ได้พุ่งสูงขึ้นเกินกว่าราคาอ้างอิงตลาดภายนอกของ CEX อย่างมาก ทำให้สถานะการขายชอร์ตจำนวนมากตกลงไปต่ำกว่ามาร์จิ้นรักษาสภาพคล่อง ระบบได้เริ่มดำเนินการชำระบัญชี: คำสั่งซื้อขายถูกวางลงในสมุดคำสั่งซื้อโดยตรง ทำให้เกิดวงจรป้อนกลับเชิงบวกแบบ "การกวาดล้างคำสั่งซื้อ → การชำระบัญชี → การกวาดล้างคำสั่งซื้อเพิ่มเติม" ส่งผลให้ราคา XPL พุ่งสูงขึ้นอย่างต่อเนื่อง 05:55 ราคาพุ่งขึ้นสูงสุดเกือบ 200% ในเวลาเพียงสิบนาทีเศษ ในขณะเดียวกัน บัญชีวาฬก็ทำกำไรได้กว่า 16 ล้านดอลลาร์ภายในเวลาเพียงนาทีเดียว บัญชีชอร์ตบางบัญชีถูกชอร์ตหลายล้านดอลลาร์ภายในไม่กี่นาที 05:56 ตลาดฟื้นตัว และราคาก็ร่วงลงอย่างรวดเร็ว ทำให้ตลาดสัญญา XPL กลับสู่ภาวะปกติ อย่างไรก็ตาม บัญชีชอร์ตจำนวนหนึ่งก็สูญเสียเงินทั้งหมดไป ในเวลาเดียวกันนั้น ราคา ETH perpetual swaps บนแพลตฟอร์ม Lighter ก็ร่วงลงอย่างรวดเร็วเช่นกัน โดยลดลงเหลือ 5,100 ดอลลาร์ในช่วงเวลาสั้นๆ นี่แสดงให้เห็นว่าปัญหานี้ไม่ได้เกิดขึ้นกับแพลตฟอร์มเดียว แต่เกิดจากการกระจุกตัวของความเสี่ยงเชิงโครงสร้างของตลาด DeFi perpetual swaps ทั้งหมด 2. อะไรเป็นสาเหตุของเหตุการณ์เหล่านี้? วาฬได้กำไรอย่างงดงาม ในขณะที่บัญชีชอร์ตขาดทุนอย่างหนัก แม้แต่ผู้ป้องกันความเสี่ยงที่ใช้เลเวอเรจต่ำก็ได้รับผลกระทบ
หลายคนคิดว่าการป้องกันความเสี่ยงด้วยเลเวอเรจ 1 เท่าเท่ากับ "ปราศจากความเสี่ยง" อย่างไรก็ตาม ในเหตุการณ์นี้ แม้แต่สถานะขายชอร์ตที่มีเลเวอเรจ 1 เท่าที่มีหลักประกันจำนวนมากก็ถูกขายออกไปอย่างยับเยิน ส่งผลให้ขาดทุนหลายล้านดอลลาร์ สิ่งนี้ทำให้ผู้ใช้หลายคนสรุปว่า "ฉันจะไม่แตะตลาดที่แยกส่วนแบบนี้อีก" แต่ความจริงนั้นซับซ้อนกว่านั้นมาก
หลังจากเหตุการณ์ XPL มีการพูดคุยกันมากมายเกี่ยวกับ "การพึ่งพาออราเคิลเดียว" หรือ "การขาดการจำกัดสถานะ" อย่างไรก็ตาม ปัญหาเหล่านี้มองข้ามแก่นของปัญหา
โปรโตคอล Perp เองมีเส้นทางการใช้งานหลายเส้นทาง:
สมุดคำสั่งซื้อขาย (Orderbook)
Peer-to-Pool (คู่สัญญาแบบพูล)
และรูปแบบไฮบริดของ AMM/Hybrid
ปัญหาในปัจจุบันคือการใช้งานสมุดคำสั่งซื้อขาย ข้อบกพร่องเชิงโครงสร้างมีดังนี้:
ความลึกที่มีประสิทธิภาพและการกระจายชิป
1. สมุดคำสั่งซื้อขายอาจดูเหมือนลึก แต่ความลึกที่มีประสิทธิภาพจริงขึ้นอยู่กับการกระจายชิป
2. เมื่อชิปกระจุกตัวอยู่ในมือของนักลงทุนรายใหญ่เพียงไม่กี่ราย แม้การผลักดันเพียงเล็กน้อยก็สามารถก่อให้เกิดปฏิกิริยาลูกโซ่ได้
การยึดราคาขึ้นอยู่กับการซื้อขายภายใน
1. ในตลาดที่มีความผันผวน ธุรกรรมในสมุดคำสั่งซื้อขายจะเป็นตัวกำหนดราคาโดยตรง
2. แม้จะมี Oracle การพึ่งพานี้ก็เป็นจุดอ่อน ตราบใดที่จุดยึดราคาภายนอกยังไม่แข็งแกร่งพอ
การชำระบัญชีและสมุดคำสั่งซื้อขายสร้างผลตอบรับเชิงบวก
1. คำสั่งชำระบัญชีจำเป็นต้องเข้าสู่สมุดคำสั่งซื้อขาย ซึ่งจะทำให้ราคาสูงขึ้นไปอีก กระตุ้นให้มีการชำระบัญชีเพิ่มขึ้น 2. ในตลาดที่มีสภาพคล่องต่ำ การดำเนินการเช่นนี้ถือเป็นการแห่กันเข้ามาอย่างหลีกเลี่ยงไม่ได้ ไม่ใช่เรื่องบังเอิญ สำหรับการกำหนดขีดจำกัดสถานะสำหรับผู้ใช้แต่ละรายนั้น การดำเนินการนี้ไม่มีความหมาย สถานะสามารถถูกแบ่งออกได้อย่างง่ายดายในหลายบัญชีย่อยหรือหลายวอลเล็ต และยังคงมีความเสี่ยงในระดับตลาด ดังนั้น การปั๊มและทิ้งจึงไม่ใช่การปั่นราคาโดยผู้ไม่หวังดี แต่เป็นชะตากรรมของกลไกสมุดคำสั่งซื้อขายภายใต้สภาวะที่มีสภาพคล่องต่ำ 4. กลับไปที่พื้นฐาน: สวอปแบบถาวรช่วยแก้ปัญหาอะไรได้บ้าง? เมื่อคุณพูดว่า "ฉันต้องการเปิดสถานะ Long ใน ETH" เบื้องหลังที่แท้จริงคืออะไร? หากเป็นการซื้อขายแบบ Spot คุณต้องจ่าย 1,000 U เพื่อซื้อ ETH หากราคาเพิ่มขึ้น คุณจะได้กำไร หากราคาลดลง คุณจะได้กำไร - หากเป็นสัญญาแบบถาวรที่มีมาร์จิ้น 1,000U คุณสามารถเปิดตัวคูณ 10 เท่า โดยใช้ตำแหน่ง 10,000U แม้ว่าผลตอบแทนของคุณจะสูงขึ้น แต่ความเสี่ยงของคุณก็เพิ่มขึ้นเช่นกัน คำถามสำคัญสองข้อที่เกิดขึ้นคือ เงินมาจากไหน? กำไรของคุณต้องมาจากคู่สัญญา (ผู้ขายชอร์ต) หรือจากแหล่งเงินทุนที่จัดหาโดยหุ้นส่วนจำกัดของคุณ ใครเป็นผู้กำหนดราคา? ตลาดแบบดั้งเดิม: ธุรกรรมในสมุดคำสั่งซื้อขายสะท้อนราคาโดยตรง ยิ่งคุณซื้อมาก ราคาก็จะยิ่งสูงขึ้น นี่คือกลไกการตอบรับสำหรับแนวโน้มตลาด สัญญาแบบถาวรบนเครือข่าย: โปรโตคอลส่วนใหญ่ (เช่น GMX) ไม่มีสมุดคำสั่งซื้อขายของตัวเอง แต่จะใช้ราคา Oracle ของ CEX แทน 5. ปัญหาเกี่ยวกับ Oracle Modelsโดยทั่วไปราคาของ Oracle จะมาจากธุรกรรม Spot บน CEX ซึ่งหมายความว่าปริมาณการซื้อขายแบบ On-chain ไม่สามารถสะท้อนกลับเข้าสู่ราคาได้ แม้ว่า Oracle จะประสบปัญหา Latency แต่ปัญหาพื้นฐานกว่านั้นคือ คุณเปิดสถานะ U มูลค่า 100 ล้าน U บนเครือข่าย แต่ไม่มีปริมาณการซื้อขายแบบ Spot ภายนอกที่สอดคล้องกัน กล่าวอีกนัยหนึ่ง ความต้องการในการซื้อขายแบบ On-chain ไม่สามารถมีอิทธิพลต่อราคาได้ และความเสี่ยงจะถูก "สะสม" ไว้ภายในระบบ ซึ่งตรงกันข้ามกับแบบจำลอง Order Book: ราคาใน Order Book ตอบสนองเร็วเกินไป ทำให้อาจถูกควบคุมได้ ส่วน Oracle Price Feedback ล่าช้า ทำให้การปลดปล่อยความเสี่ยงล่าช้ากว่า 6. อัตราพื้นฐานและอัตราเงินทุน คำถามสำคัญอีกข้อหนึ่งคือ จะแก้ไขส่วนต่างราคา (Basis) ระหว่างราคา Spot และ Futures ได้อย่างไร ในตลาดแบบดั้งเดิม หากจำนวนสถานะ Long มากกว่าสถานะ Short มาก ราคาสัญญาจะสูงกว่าราคา Spot สัญญาแบบ Perpetual ใช้กลไกอัตราเงินทุนเพื่อควบคุมเรื่องนี้: สถานะ Long ที่มากเกินไป → อัตราเงินทุนจะกลายเป็นบวก และสถานะ Long จ่ายผลตอบแทนให้กับสถานะ Short สถานะขายชอร์ตที่มากเกินไป → อัตราเงินทุนจะกลายเป็นลบ และสถานะขายชอร์ตจะจ่ายผลตอบแทนแบบ long ในทางทฤษฎี อัตราเงินทุนสามารถยึดราคาสัญญาให้กลับมาอยู่ที่ราคาสปอตได้ อย่างไรก็ตาม สำหรับสัญญาแบบ on-chain perpetual สถานการณ์มีความซับซ้อนมากขึ้น หากตลาดสปอตขาดความลึก แม้แต่อัตราเงินทุนที่สูงก็อาจไม่สามารถแก้ไขพื้นฐานได้ โดยเฉพาะอย่างยิ่งสำหรับผลิตภัณฑ์ที่ไม่เป็นที่นิยม สัญญา on-chain อาจเบี่ยงเบนไปจากราคาสปอตเป็นเวลานาน จนกลายเป็น "ตลาดเงา" ที่แทบจะเป็นอิสระ 7. ภาพลวงตาของความลึกของ on-chain หลายคนเชื่อว่ามีเพียงสินทรัพย์ที่ไม่เป็นที่นิยมเท่านั้นที่จะถูกปั่นราคา ในขณะที่สินทรัพย์ระดับบนสุดจะปลอดภัย แต่ความจริงคือ ความลึกที่แท้จริงของการซื้อขาย on-chain spot นั้นน้อยกว่าที่คาดการณ์ไว้มาก ยกตัวอย่างเช่นโทเค็นสามอันดับแรกในแต่ละระบบนิเวศ: ใน Arbitrum ความลึกของโทเค็นกระแสหลักอื่นๆ นอกเหนือจาก ETH มักจะอยู่ที่เพียงไม่กี่ล้านดอลลาร์ภายในช่วงสเปรด 0.5% สำหรับ DEX ชั้นนำอย่าง Uniswap หรือแม้แต่ "eco-coin" อย่าง UNI ความลึกของการซื้อขายแบบ on-chain ก็ไม่เพียงพอที่จะต้านทานการตกฮวบของมูลค่าหลายสิบล้านดอลลาร์อย่างฉับพลันได้ นั่นหมายความว่าอย่างไร? ความลึกที่แท้จริงมักจะต่ำกว่าความลึกที่รายงานไว้มาก โดยเฉพาะอย่างยิ่งเมื่อมีการกระจุกตัวของเงินเดิมพัน ทำให้แนวต้านที่แท้จริงยิ่งอ่อนแอลง
ในสภาพแวดล้อมเช่นนี้ เกณฑ์สำหรับการจัดการราคาไม่สูงนัก แม้แต่โทเค็นสามอันดับแรกในระบบนิเวศก็ยังสามารถถูกดันขึ้นหรือลงได้อย่างง่ายดายในสภาวะตลาดที่รุนแรง
กล่าวอีกนัยหนึ่ง: ความเสี่ยงเชิงโครงสร้างของ on-chain perp ไม่ใช่ "กรณีพิเศษ" ในตลาดเฉพาะกลุ่ม แต่เป็น "บรรทัดฐาน" ของระบบนิเวศทั้งหมด 8. แนวทางสำหรับการออกแบบโปรโตคอลรุ่นถัดไป เหตุการณ์ปลั๊กอิน XPL ทำให้เห็นได้ชัดเจนว่าปัญหาไม่ใช่ช่องโหว่ในแพลตฟอร์มใดแพลตฟอร์มหนึ่ง แต่เป็นความขัดแย้งเชิงโครงสร้างระหว่างสมุดคำสั่งซื้อขายที่มีอยู่และสภาพคล่องบนเชน ดังนั้น หากเราต้องการหารือเกี่ยวกับ "โปรโตคอล perp รุ่นถัดไป" อย่างน้อยสามประเด็นที่ควรได้รับการสำรวจเพิ่มเติม: 1. การควบคุมความเสี่ยงเชิงรับ: ทุกการเปิดสถานะ การสับเปลี่ยน การเพิ่มหรือลดสภาพคล่อง และการปิด/ปิดสถานะ ควรนำหน้าด้วยการจำลองสุขภาพของตลาดหลังการดำเนินการ หากความเสี่ยงเกินเกณฑ์ที่กำหนด ควรจำกัดหรือปรับไว้ล่วงหน้า แทนที่จะขายสินทรัพย์อย่างไม่ใส่ใจหลังจากที่สถานะนั้นต่ำกว่ามาร์จิ้นบำรุงรักษา 2. การเชื่อมโยง Spot Pool: โมเดล on-chain ในปัจจุบันมีทั้งการตอบรับที่รวดเร็วเกินไป (สมุดคำสั่งซื้อขาย) หรือการตอบรับที่ล่าช้า (ออราเคิล) แนวทางที่ดีกว่าคือการเชื่อมโยงสถานะสัญญากับกลุ่มซื้อขายแบบ Spot Pool เมื่อความเสี่ยงสะสม ความผันผวนของระดับความลึกของตลาด Spot สามารถบรรเทาหรือเจือจางสถานะได้ วิธีนี้จะช่วยหลีกเลี่ยงปัญหาค้างที่ล่าช้าและลดความปั่นป่วนที่เกิดขึ้นอย่างฉับพลัน 3. ให้ความสำคัญกับการป้องกัน LP: ไม่ว่าจะเป็นในสมุดคำสั่งซื้อขายหรือแบบ Peer-to-Pool LP ถือเป็นจุดอ่อนที่สุด โปรโตคอลรุ่นต่อไปจำเป็นต้องผสานกลไกการควบคุมความเสี่ยงของ LP เข้ากับเลเยอร์โปรโตคอล ทำให้ความเสี่ยงของ LP มีความโปร่งใสและควบคุมได้ แทนที่จะแบกรับความรับผิดชอบแบบเฉยๆ 9. การสำรวจและโอกาสในทางปฏิบัติ: การพูดคุยเกี่ยวกับทิศทางเป็นเรื่องง่าย แต่การนำไปปฏิบัติจริงนั้นยาก อย่างไรก็ตาม มีความพยายามใหม่ๆ บางอย่างที่กำลังดำเนินการอยู่: การควบคุมความเสี่ยงเชิงรับ: จำลองภาวะตลาดก่อนการซื้อขายเพื่อกรองความเสี่ยงล่วงหน้า การเชื่อมโยงสัญญากับกลุ่มซื้อขายแบบ Spot Pool: อนุญาตให้สถานะมีปฏิสัมพันธ์กับสภาพคล่องแบบ Spot เพื่อป้องกันการสะสมความเสี่ยงหรือการปั่นป่วนที่เกิดขึ้นอย่างกะทันหัน การจัดลำดับความสำคัญของการป้องกัน LP: การรวมการควบคุมความเสี่ยงของ LP เข้ากับเลเยอร์โปรโตคอล แทนที่จะกำหนดให้ LP ครอบคลุมการขาดทุนแบบเฉยๆ ในขณะเดียวกัน เราไม่สามารถมองข้ามความเป็นจริงของตลาดที่ใหญ่กว่านี้ได้ นั่นคือ ตลาดสวอปแบบถาวรสร้างรายได้ค่าธรรมเนียมและค่าคอมมิชชั่นมากกว่า 3 หมื่นล้านดอลลาร์ต่อปี ในอดีต ส่วนแบ่งนี้แทบจะถูกแบ่งให้กับตลาดแลกเปลี่ยนแบบรวมศูนย์และผู้ดูแลสภาพคล่องมืออาชีพเพียงไม่กี่แห่ง หากโปรโตคอลยุคใหม่สามารถผสานรวมเทคโนโลยี AMM เข้ามาได้ โดยแบ่ง Market Making ออกเป็นการจัดสรรสภาพคล่องแบบรวมศูนย์ ผู้เข้าร่วมทั่วไปก็จะสามารถแบ่งปันเงินปันผลในตลาดนี้ได้มากขึ้น นี่ไม่เพียงเป็นนวัตกรรมในการควบคุมความเสี่ยงเท่านั้น แต่ยังเป็นการสร้างกลไกจูงใจขึ้นใหม่ด้วยท่ามกลางการสำรวจเหล่านี้ โครงการใหม่ๆ บางโครงการก็เริ่มสำรวจเส้นทางที่แตกต่างออกไป ตัวอย่างเช่น AZEx ซึ่งใช้กลไก Uniswap v4 Hook กำลังพยายามผสาน "การควบคุมความเสี่ยงก่อนการดำเนินการ + อัตราเงินทุนแบบไดนามิก + การตรึงตลาดในสถานการณ์ที่รุนแรง" เข้ากับ "การแบ่งปันผลกำไรแบบรวมของ LP" ในสัปดาห์หน้า AZEx จะเปิดตัวเครือข่ายทดสอบ ผู้อ่านที่สนใจสามารถติดตามความคืบหน้าล่าสุดได้ที่ [https://x.com/azex_io] 10. สรุป เหตุการณ์ XPL PIN เตือนเราว่า ความเสี่ยงไม่ได้อยู่ที่กราฟ แต่อยู่ที่โปรโตคอล สัญญา DeFi แบบถาวรในปัจจุบันส่วนใหญ่ขับเคลื่อนโดยคำสั่งซื้อขาย ตราบใดที่สภาพคล่องยังไม่เพียงพอและผู้เดิมพันยังคงกระจุกตัวอยู่ เรื่องราวที่คล้ายคลึงกันก็มักจะเกิดขึ้นซ้ำอีก การแข่งขันที่แท้จริงระหว่างโปรโตคอล Perp รุ่นต่อไปไม่ได้เกี่ยวกับ UI คะแนน หรือส่วนลด เนื้อหาเกี่ยวกับ: เราสามารถออกแบบโปรโตคอล Perp แบบใหม่ที่สร้างวงจรปิดสำหรับการค้นพบราคา การควบคุมความเสี่ยง และการปกป้อง LP แทนที่จะต้องมาวุ่นวายซ้ำแล้วซ้ำเล่าในสภาวะตลาดที่ตึงเครียดได้หรือไม่? เราจะสามารถโยกย้ายกำไรมูลค่า 3 หมื่นล้านดอลลาร์จากผู้เข้าร่วมเพียงไม่กี่รายไปสู่ผู้เข้าร่วมที่มากขึ้นได้หรือไม่? โปรโตคอลรุ่นต่อไปต้องไม่เพียงแต่จัดการกับความเสี่ยงเท่านั้น แต่ยังต้องกระจายผลประโยชน์อีกด้วย ใครก็ตามที่สามารถบรรลุสองสิ่งนี้ได้ จะมีโอกาสกำหนดตลาดสัญญาแบบถาวรของ DeFi รุ่นต่อไป บทความนี้เป็นบทความสนับสนุนและไม่ได้สะท้อนมุมมองของ BlockBeatsยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:
กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats
กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App
บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia
