ต่อจากคำพูดของเจ้าของ Yishi ในความเป็นจริง โครงสร้างสัญญาอัจฉริยะที่เปิดซอร์สเพียงอย่างเดียวมักไม่มีปัญหาเอง และทีมที่มีปัญหาด้านวินัยในระดับสัญญา มักไม่มีใครที่ไม่ผ่านการตรวจสอบหลายรอบหรือการยืนยันเชิงรูปแบบ หลายทีมยังมีวินัยในการเปิดตัวค่อนข้างดี แต่ก็ยังไม่สามารถป้องกันได้ บริษัทตรวจสอบไม่ได้รับผิดชอบในเรื่องนี้ อุบัติเหตุส่วนใหญ่เกิดจากปัญหาการจัดการสิทธิ์และการจัดการพารามิเตอร์ ไม่ว่าจะเป็นเหตุการณ์ของ Drift หรือ KELP ก็ตาม ที่นี่มีคำถามหลัก: ผลิตภัณฑ์ DeFi ควรจะมุ่งเน้นและสมมติว่า “ไม่มีอุบัติเหตุ” หรือไม่? ตรรกะของโครงการ DeFi ส่วนใหญ่ในปัจจุบัน (รวมถึง CeFi) คือ: “เพราะฉันได้ดำเนินการหลายชั้นแล้ว ดังนั้นฉันจะไม่มีอุบัติเหตุ” ผลลัพธ์โดยตรงที่ตามมาคือ เมื่อเกิดอุบัติเหตุขึ้น จะยากมากที่จะช่วยเหลือ เพราะทุกแนวทางล้วนเป็นการ “รักษาโรคก่อนเกิด” อย่างสง่างาม แล้วถ้าเราสมมติว่าอุบัติเหตุหลีกเลี่ยงไม่ได้ล่ะ? แนวทางการออกแบบจะเปลี่ยนจาก “ป้องกันโรค” เป็น “รักษาโรค” จาก “มาตรการความปลอดภัย” เป็น “แผนลดความเสียหาย” ประเด็นหลักๆ จะกลายเป็น: 1. ล็อกเวลาอัปเกรดสัญญา (หัวข้อนี้พูดกันมานานแล้ว) 2. การตรวจสอบความสามารถในการชำระหนี้ (รักษาสัดส่วนระหว่างความสามารถในการชำระหนี้ของโปรโตคอลกับจำนวนเงินที่เข้ามา): ปัญหานี้คือเหตุผลที่ว่าทำไมการให้กู้ยืมจำนวนมากจึง “ได้กำไรน้อยแต่เครียดเหมือนจัดการสารเสพติด” ธุรกิจที่มีผลกำไรเพียงเล็กน้อยกลับมี TVL มหาศาล โปรโตคอลเองไม่มีทางสามารถชำระหนี้ได้จริง 3. ระบบหยุดชั่วคราวเมื่อมีการเคลื่อนไหวเงินทุนขนาดใหญ่ จุดนี้แทบไม่มีโปรโตคอลใดมีในปัจจุบัน แต่เป็นมาตรฐานใน CEX เมื่อมีการเคลื่อนไหวเงินทุนขนาดใหญ่ โดยเฉพาะการถอนเงิน ระบบจะกระตุ้นการควบคุมความเสี่ยงโดยเลื่อนเวลาการถอน เพื่อให้กลไกควบคุมความเสี่ยงมีเวลาแทรกแซง ไม่ว่าการโจมตีแบบแฮกเกอร์จะเกิดขึ้นอย่างไร ผลลัพธ์สุดท้ายมักจะเป็นการถอนเงินขนาดใหญ่ การปิดช่องโหว่อาจทำไม่ได้ แต่เราสามารถปิดประตูขั้นสุดท้ายที่ทำให้เกิดความเสียหายได้ ระบบควบคุมความเสี่ยงแบบนี้สามารถใช้ได้ในระดับ dApp, ระดับสตูเบิลโค인 และระดับสะพานข้ามเครือข่าย โดยมีผลกระทบเล็กน้อยต่อผู้ใช้งานปกติ (รวมถึงผู้ทำ arbitrage ความถี่สูง ซึ่งไม่ได้ถอนเงินบ่อยครั้งอย่างต่อเนื่อง) สิ่งนี้เป็นข้อเสียอย่างมากสำหรับ ETH แต่เป็นข้อได้เปรียบอย่างยิ่งสำหรับโซลูชันเช่น @BNBCHAIN BNB เคยประสบความสำเร็จในการลดปัญหา MEV front-running ได้ถึง 95% ผ่านกลไก Goodwill Alliance ในระดับโหนด ดังนั้นจึงอาจสามารถเพิ่มกลไกควบคุมความเสี่ยงแบบคล้ายล็อกเวลาในระดับสะพานได้เช่นกัน แม้จะเกิดการโจมตี สะพานก็ยังเป็นเกราะป้องกันขั้นสุดท้ายที่สามารถหยุดเงินที่ถูกขโมยไว้ไม่ให้หลบหนี การใช้มาตรฐานเดียวกันควรถูกนำมาใช้กับโปรโตคอลข้ามเครือข่ายที่เกี่ยวข้องกับ BNB ประสิทธิภาพของวิธีนี้ได้รับการพิสูจน์ซ้ำแล้วซ้ำเล่าในการจัดการอุบัติเหตุด้านความปลอดภัยของโซลูชันเช่น Sui และ Hyperliquid — โดยเงื่อนไขคือไม่มีช่องโหว่อย่าง USDC CCTP ที่ไม่ทำงาน นอกจากนี้ยังมีกลไกล็อกเวลาและบล็อกลิสต์สำหรับการโอนเงินขนาดใหญ่ในระดับสตูเบิลโคิน ซึ่งตรรกะคล้ายกับสะพาน แต่อาจกระทบต่อการนำไปใช้งาน โดยรวมแล้ว ผมมองว่านี่คือโอกาสของ L1 กุญแจสำคัญอยู่ที่สี่คำ: “ควบคุมได้ด้วยตนเอง” ภายใต้เงื่อนไขนี้ แม้แต่ระดับโซลูชัน L1 ก็สามารถบรรลุ “การชดเชยความเสียหายจริง” แทนที่จะเป็น “ประกันเชิงพาณิชย์” เช่น Umbrella คนใดทำได้ คนนั้นอาจคว้าส่วนแบ่ง TVL ที่ ETH สูญเสียไป