การควบคุมความเสี่ยง DeFi: เหตุใดโปรโตคอลจึงต้องมีเซอร์กิตเบรกเกอร์ก่อนเหตุการณ์ความเครียดครั้งถัดไป

DeFi ยังคงเพิ่มประสิทธิภาพแบบทบต้นอยู่เรื่อยๆ จนกว่าจะไม่เป็นเช่นนั้น เมื่อตลาดเกิดความปั่นป่วน การใช้เลเวอเรจ ลูปป้อนกลับ และสภาพคล่องที่บางอาจเปลี่ยนการดึงกลับตามปกติให้กลายเป็นวิกฤตระดับโปรโตคอลได้ นักพัฒนาและผู้ใช้ต่างได้เรียนรู้บทเรียนอันเจ็บปวดนี้ผ่านเหตุการณ์ต่างๆ เช่น ความวุ่นวายของการบังคับชำระบัญชีในเดือนมีนาคม 2020 การแพร่ระบาดของวิกฤตในปี 2022 และการหลุดหมุดของ stablecoin ในปี 2023

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

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

PointDetails Circuit breaker ต้องมีขอบเขตให้ความสำคัญกับการควบคุมระดับสินทรัพย์หรือตลาด (caps, fee escalators) มากกว่าการหยุดชะงักทั่วโลกเพื่อรักษาความสามารถในการรวมกันและทางออกของผู้ใช้ Oracle ต้องการแนวป้องกันใช้ค่าเกณฑ์การเบี่ยงเบน การตรวจสอบความล้าสมัย TWAP/medianization และโมดูลหน่วงเวลาเพื่อป้องกันราคาที่ผิดพลาดจากการแพร่กระจาย Rate limit ลดการแพร่ระบาดการควบคุมการถอน/การออก mint และ borrow/supply caps ชะลอ bank run แบบสะท้อนกลับและการเติบโตของความเสี่ยงที่กระจุกตัว การกำกับดูแลของมนุษย์คือการแลกเปลี่ยน Pause guardian และ multisig เพิ่มความสามารถในการตอบสนองแต่เพิ่มความเสี่ยงด้านการรวมศูนย์ ควรจับคู่กับ timelock และขอบเขต ทดสอบและสื่อสารการทดสอบแบบ chaos, dashboard ที่ชัดเจน และ runbook ที่เผยแพร่ช่วยให้ผู้ใช้และผู้รวมระบบตอบสนองได้อย่างสงบภายใต้ความเครียด

Circuit Breaker หมายความว่าอะไรในแง่ DeFi

ใน DeFi circuit breaker คือการควบคุมแบบอัตโนมัติหรือที่กำกับดูแลซึ่งจำกัดการดำเนินการที่มีความเสี่ยงชั่วคราวเมื่อตรงตามเงื่อนไขที่กำหนด ต่างจากการ "หยุดทุกอย่าง" แบบไม่ละเอียด breaker ที่มีประสิทธิภาพนั้นมีความละเอียด วัดได้ และย้อนกลับได้

• Soft pause: จำกัดการดำเนินการที่เพิ่มความเสี่ยง (การกู้ยืมใหม่, เลเวอเรจใหม่, การ mint ใหม่) ขณะที่ยังอนุญาตให้ลดเลเวอเรจ ชำระคืน และถอนเงินได้
• Rate limiter: จำกัดจำนวนที่สามารถถอน mint หรือกู้ยืมได้ในช่วงเวลาหนึ่งเพื่อป้องกันการขาดสภาพคล่องแบบชันชัน
• Market cap และ isolation: เพดาน supply/borrow และโหมด isolation ต่อสินทรัพย์ป้องกันไม่ให้สินทรัพย์ขนาดเล็กหรือที่สัมพันธ์กันเป็นอันตรายต่อตลาดหลัก
• Fee escalator: เพิ่มค่าธรรมเนียม/ความคลาดเคลื่อนของ slippage โดยอัตโนมัติในช่วงความผันผวนเพื่อสะท้อนความเสี่ยงและยับยั้งการไหลของเงินที่เป็นพิษ
• Oracle guard: การตรวจสอบ price feed ที่ปฏิเสธการอัปเดตที่ล้าสมัยหรือผิดปกติ กำหนดให้มีหน้าต่าง TWAP หรือบังคับให้มีการเคลื่อนไหวที่มีขอบเขต
• Governance lock: Timelock และการหน่วงเวลาในการเปลี่ยนแปลงพารามิเตอร์เพื่อลดการอัปเกรดที่เร่งรีบหรือเป็นอันตราย

โปรโตคอลชั้นนำหลายแห่งได้นำรูปแบบเหล่านี้มาใช้แล้ว ตัวอย่างเช่น Aave v3 ได้แนะนำ supply และ borrow cap ต่อตลาดและโหมด isolation เพื่อจำกัด tail risk (Aave v3 features) Oracle Security Module (OSM) ของ MakerDAO หน่วงเวลาการเปลี่ยนแปลงราคาเพื่อเพิ่มความปลอดภัย และ Governance Security Module (GSM) บังคับใช้การหน่วงเวลาขั้นต่ำสำหรับการเปลี่ยนแปลงระดับผู้บริหาร (Maker OSM; Maker GSM) การออกแบบของ Compound มีความสามารถในการหยุดชะงักและการควบคุมตามบทบาท ซึ่งมีรายละเอียดในเอกสารประกอบ (Compound docs)

สถานการณ์ความเครียดที่เปิดเผยจุดอ่อนของโปรโตคอล

การเข้าใจว่า breaker ช่วยได้ที่ไหนเริ่มต้นด้วยการทำแผนที่รูปแบบความล้มเหลวทั่วไป:

• ความล้มเหลวของ Oracle: ราคาที่ล้าสมัยหรือถูกจัดการอาจกระตุ้นการกู้ยืมที่ขาดหลักประกัน การบังคับชำระบัญชีที่ผิดพลาด หรือการล้มละลาย Oracle ที่ใช้ DEX เท่านั้นโดยมีหน้าต่างสั้นมีความเสี่ยงต่อการถูกจัดการในพูลที่มีสภาพคล่องต่ำเป็นพิเศษ
• การบังคับชำระบัญชีแบบลูกโซ่: การดึงกลับอย่างรุนแรงอาจผลักหลายบัญชีให้ต่ำกว่าเกณฑ์การบำรุงรักษาพร้อมกัน ทำให้ความสามารถของ keeper และสภาพคล่องบน chain ไม่เพียงพอ
• การหนีของสภาพคล่อง: เมื่อการรับรู้ความเสี่ยงพุ่งสูง ผู้ให้บริการสภาพคล่องและผู้ให้กู้ยืมออกพร้อมกัน หากไม่มีการควบคุม TVL อาจหดตัวเร็วกว่าที่ตลาดจะรองรับการไถ่ถอนได้
• การหลุดหมุดของ stablecoin: สินทรัพย์หลักประกันหรือสินทรัพย์ทางบัญชีที่หลุดจากหมุดอาจบิดเบือน LTV และทำให้เกิดการบังคับชำระบัญชีในราคาผิด
• ความเสี่ยงด้านการกำกับดูแลหรือผู้ดูแลระบบ: การอัปเกรดที่เร่งรีบหรือถูกบุกรุก หรือข้อผิดพลาดของมนุษย์ที่มีบทบาทสูง อาจล็อคหรือระบายเงินโดยไม่ตั้งใจ
• การหยุดทำงานของ Bridge หรือ L2: การพึ่งพา cross-chain นำเสนอโดเมนการหยุดชะงักเพิ่มเติม bridge ที่หยุดชะงักอาจทำให้หลักประกันถูกแยกออกหรือบล็อกการไหลของการปรับสมดุล

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

รูปแบบการออกแบบ: จาก Soft Pause ถึง Hard Stop

Breaker ที่ดีมีการทำงานแบบหลายชั้น เริ่มต้นด้วย guardrail ที่กำหนดรูปร่างความเสี่ยงอย่างต่อเนื่อง เพิ่ม trigger เพื่อชะลอการไหลในช่วงความเครียด และสำรอง hard stop ไว้สำหรับสภาวะที่ผิดปกติอย่างแท้จริง

กลไกขอบเขต Trigger ผลกระทบต่อผู้ใช้ Soft pause (ไม่มีความเสี่ยงใหม่) ต่อตลาดหรือทั่วโปรโตคอล การพุ่งของความผันผวน ความไม่แน่นอนของ oracle การละเมิดอัตราส่วนสภาพคล่อง สามารถชำระคืน/ถอนเงินได้ ไม่สามารถเปิดเลเวอเรจหรือกู้ยืมใหม่ได้ Rate limiter ต่อสินทรัพย์/หน้าต่างเวลา การใช้งานเกินเกณฑ์ (เช่น X% ต่อชั่วโมง) การถอนเงิน/การไถ่ถอนขนาดใหญ่เข้าคิวตามเวลา รายการขนาดเล็กไม่ได้รับผลกระทบ Supply/borrow cap ต่อสินทรัพย์ งบประมาณความเสี่ยงแบบคงที่ สามารถปรับได้ การ supply สินทรัพย์หรือการเติบโตของหนี้หยุดที่ cap Fee escalator ต่อตลาด คะแนนความผันผวน/สภาพคล่อง ต้นทุนเพิ่มขึ้นในช่วงความเครียด ยับยั้งการไหลที่เป็นพิษ Global pause (hard stop) ทั่วโปรโตคอล บั๊กร้ายแรง การหยุดทำงานของ oracle การโจมตีการกำกับดูแล การดำเนินการทั้งหมดหยุดชะงักจนกว่าการกำกับดูแล/ผู้ดูแลระบบจะกู้คืน

เมื่อไหร่ควรเลือกอะไร

• ท่าทางเริ่มต้น: ใช้ cap และ isolation โดยค่าเริ่มต้นเพื่อจำกัดความเสี่ยงที่สัมพันธ์กันและสินทรัพย์ long-tail
• การตอบสนองแรก: เปิดใช้งาน soft pause และ fee escalator เพื่อลดการสะท้อนกลับขณะที่ยังเปิดทางออกไว้
• ฉุกเฉินเท่านั้น: สำรอง global pause ไว้สำหรับความล้มเหลวร้ายแรงที่ยืนยันแล้วซึ่งการดำเนินการต่อนั้นเป็นอันตรายอย่างพิสูจน์ได้

การควบคุมอาจเป็นแบบอัลกอริทึมล้วนๆ หรือรวมการกำกับดูแลของมนุษย์ หาก "pause guardian" ที่ดำเนินการโดยมนุษย์มีอยู่ ให้กำหนดขอบเขตต่อตลาด กำหนดให้มีการยืนยันแบบ multi-signature และบันทึกเหตุผลบน chain แบบถาวรเพื่อความโปร่งใส

เคล็ดลับ: รวมสัญญาณอิสระหลายตัว ตัวอย่างเช่น กำหนดให้ต้องมีทั้งการละเมิดความผันผวนและสัญญาณความไม่แน่นอนของ oracle ก่อนเปิดใช้งาน soft pause

Oracle Guardrail และ Price-Feed Tripwire

Price feed เป็นจุดเดียวของความล้มเหลวที่พบบ่อย เลเยอร์ oracle ที่แข็งแกร่งโดยทั่วไปประกอบด้วย:

• ค่าเกณฑ์การเบี่ยงเบนและ heartbeat: อัปเดตเฉพาะเมื่อการเปลี่ยนแปลงราคาเกินเปอร์เซ็นต์หรือหลังจากช่วงเวลาสูงสุด ใช้กันอย่างแพร่หลายในเครือข่าย oracle มืออาชีพ (Chainlink data feeds)
• TWAP/medianization: ทำให้การซื้อขายที่ผิดปกติราบเรียบและลดการจัดการ โดยมักใช้หน้าต่างถ่วงน้ำหนักตามเวลาของ DEX (ดู Uniswap oracle docs)
• การตรวจสอบความล้าสมัย: หากการอัปเดตล่าสุดเกินอายุสูงสุด ให้ปฏิเสธการดำเนินการที่เพิ่มความเสี่ยงใหม่
• การเคลื่อนไหวที่มีขอบเขต: จำกัดการกระโดดของราคาต่อช่วงที่โปรโตคอลจะยอมรับ การเคลื่อนไหวที่รุนแรงต้องการหน้าต่างการยืนยันที่ยาวขึ้น
• โมดูลหน่วงเวลา: OSM ของ MakerDAO หน่วงเวลาการมีผลของราคา ให้เวลาการกำกับดูแลตอบสนองต่อการพิมพ์ที่น่าสงสัย (Maker OSM)
• Logic failover: หาก feed หลักขัดข้องหรือเบี่ยงเบนจาก anchor เกินกว่าที่ยอมรับได้ ให้เข้าสู่โหมดจำกัดหรือเปลี่ยนไปใช้ fallback ที่อนุรักษ์นิยม

นี่คือรูปแบบ minimalist เพื่อแสดงให้เห็นว่า breaker สามารถนั่งอยู่หน้าการดำเนินการที่ขึ้นอยู่กับราคาได้อย่างไร:

if (oracle.isStale() || oracle.deviationFromTWAP() > maxDev) { restrictRiskIncreasingActions(); emit BreakerTripped("oracle_guard"); }

ข้อผิดพลาดที่ควรหลีกเลี่ยง:

• หน้าต่างสั้นที่ใช้ DEX เท่านั้น: TWAP ที่มีหน้าต่างการสังเกตขนาดเล็กนั้นง่ายต่อการจัดการในพูลที่บาง
• ไม่มีการป้องกันความล้าสมัย: การอนุญาตให้กู้ยืมในราคาที่เก่าหลายชั่วโมงเชิญชวนความล้มละลายในช่วงการหยุดทำงาน
• Fallback ที่ซ่อนอยู่: กฎ failover ที่ไม่มีเอกสารประกอบทำลายความเชื่อมั่นของผู้ใช้เมื่อเปิดใช้งาน

การนำไปใช้โดยไม่ทำลาย UX หรือ Composability

Breaker ควรรู้สึกเหมือน speed bump ไม่ใช่ roadblock เคล็ดลับอยู่ที่การปรับเทียบ trigger และการสื่อสารสถานะ

หลักการปรับเทียบ

• เกณฑ์ที่ขับเคลื่อนด้วยข้อมูล: ใช้ความผันผวนในอดีต ความลึกของสภาพคล่อง และปริมาณงานการบังคับชำระบัญชีเพื่อกำหนดขีดจำกัด ทบทวนเป็นประจำ
• กฎอสมมาตร: ควรง่ายกว่าที่จะออกจากความเสี่ยงมากกว่าการเพิ่มเข้าไป อนุญาตให้ชำระคืน ลดเลเวอเรจ และไถ่ถอนได้เสมอเมื่อปลอดภัย
• การเสื่อมสภาพอย่างนุ่มนวล: ให้ความสำคัญกับการเพิ่มค่าธรรมเนียมและการเติมเต็มบางส่วนมากกว่าการ revert เต็มรูปแบบเมื่อเป็นไปได้
• การปรับแต่งต่อสินทรัพย์: token long-tail ต้องการ cap ที่เข้มงวดกว่าและ trigger ที่เร็วกว่า สินทรัพย์ blue-chip สามารถรับขีดจำกัดที่หลวมกว่าได้

ความสะดวกสบายของนักพัฒนา

• Endpoint สถานะสาธารณะ: เปิดเผยสถานะ breaker และพารามิเตอร์บน chain และผ่าน subgraph เพื่อให้ผู้รวมระบบปรับตัวได้
• รหัสข้อผิดพลาดที่นับได้: ส่งคืนเหตุผลข้อผิดพลาดที่ชัดเจน (เช่น ORACLE_STALE, RATE_LIMITED) เพื่อให้ UI สามารถแนะนำผู้ใช้ได้
• Keeper ที่อยู่ใน allow list: ตรวจสอบให้แน่ใจว่า keeper/liquidator ยังคงสิทธิ์ในโหมด soft-pause เพื่อปกป้องความสามารถในการชำระหนี้
• การบันทึก event ที่หลากหลาย: ส่ง event ที่มีโครงสร้างพร้อมเหตุผลการกระตุ้น เกณฑ์ และสินทรัพย์ที่เกี่ยวข้องสำหรับการนิติวิทยาศาสตร์

การสื่อสารกับผู้ใช้: แสดง banner และคำเตือนต่อสินทรัพย์ในแอป แสดงโควต้าที่เหลืออยู่ในตลาดที่มี rate limit (เช่น "การถอน: มีขีดจำกัดรายชั่วโมง 63% ที่พร้อมใช้งาน") จัดทำเอกสารสถานการณ์อย่างชัดเจน

การตรวจสอบ Composability: ทดสอบว่า breaker upstream แพร่กระจายไปยังโปรโตคอล downstream อย่างไร หาก lending market soft-pause การกู้ยืม ตรวจสอบให้แน่ใจว่า leveraged yield vault ล้มเหลวอย่างนุ่มนวลแทนที่จะบล็อกการถอน

ความเสี่ยงด้านการกำกับดูแล การมอบหมาย และมนุษย์ในวงจร

Breaker แบบอัลกอริทึมล้วนๆ อาจคาดเดาได้แต่ไม่ยืดหยุ่น ระบบที่มีมนุษย์ในวงจรสามารถตอบสนองต่อภัยคุกคามใหม่ได้แต่นำเสนอความเสี่ยงด้านความไว้วางใจและการประสานงาน

• การกำหนดขอบเขตบทบาท: หากคุณแต่งตั้ง pause guardian หรือสภาฉุกเฉิน ให้กำหนดขอบเขตอำนาจต่อตลาดและต่อฟังก์ชัน หลีกเลี่ยงสวิตช์เดียวที่หยุดทุกอย่าง
• Multi-signature และความโปร่งใส: ใช้ multi-sig พร้อมนโยบาย hardware wallet และเผยแพร่ตัวตนหรืออำนาจของผู้ลงนาม การให้เหตุผลบน chain ช่วยเพิ่มความรับผิดชอบ
• Timelock และการพักฟื้น: สำหรับการเปลี่ยนแปลงพารามิเตอร์นอกเหนือจากเหตุฉุกเฉิน ให้บังคับใช้การหน่วงเวลา (เช่น GSM ของ Maker) เพื่อให้ผู้มีส่วนได้ส่วนเสียมีเวลาตรวจสอบ (GSM overview)
• การแยกหน้าที่: key ที่แตกต่างกันสำหรับ oracle พารามิเตอร์ความเสี่ยง และความสามารถในการอัปเกรดลดรัศมีการระเบิดหากบทบาทใดบทบาทหนึ่งถูกบุกรุก
• เส้นทาง Sunset: เขียนโค้ดความสามารถในการเพิกถอนอำนาจฉุกเฉินหลังจากผ่าน milestone เพื่อให้สอดคล้องกับการกระจายอำนาจแบบก้าวหน้า

การทดสอบ Telemetry และ Runbook ก่อนเปิดตัว

Breaker ที่มีอยู่เพียงบนกระดาษก็ไม่ต่างอะไรกับไม่มีเลย ตรวจสอบ trigger ภายใต้สภาวะที่สมจริงและดำเนินการด้วยการมองเห็นแบบ real-time

การตรวจสอบก่อนการปรับใช้

• การจำลอง forked-chain: จำลองการกระแทกทางประวัติศาสตร์ (เช่น การดึงกลับ 50%, de-peg) บน fork และวัดปริมาณงานการบังคับชำระบัญชีและเวลาแฝงของ breaker
• การทดสอบแบบ property-based: Fuzz ราคาหลักประกัน สภาพคล่อง และการดำเนินการของผู้ใช้เพื่อให้แน่ใจว่า breaker เปิดใช้งานเฉพาะเมื่อตั้งใจ
• Game day: ดำเนินการซ้อมกับ guardian ผู้ให้บริการ oracle และ keeper กำหนดเวลาว่าแต่ละขั้นตอนใช้เวลานานแค่ไหน

Production telemetry

• Dashboard ความผันผวนและสภาพคล่อง: ติดตามความผันผวนโดยนัยต่อสินทรัพย์ ความลึกบน chain และการใช้งานเพื่อคาดการณ์ trigger
• Breaker stateboard: หน้าสาธารณะที่แสดงสถานะ breaker ประวัติการกระตุ้น และโควต้าที่เหลืออยู่สร้างความเชื่อมั่น
• การแจ้งเตือน: ระบบเวรกับการแจ้งเตือนเพื่อความล้าสมัยของ oracle การพุ่งสูงของการใช้งาน หรือความผิดปกติของคิวการกำกับดูแล

Runbook และ postmortem

• Playbook ทีละขั้นตอน: จัดทำเอกสารว่าต้องทำอะไรเมื่อ breaker แต่ละตัวกระตุ้น ใครลงนามอะไร และต้องสื่อสารอะไร
• การทบทวนหลังเหตุการณ์: เผยแพร่ postmortem ที่ชัดเจนและทันเวลาพร้อมการเปลี่ยนแปลงพารามิเตอร์และบทเรียนที่ได้รับ

Scorecard: การประเมิน Breaker ของโปรโตคอลในฐานะผู้ใช้

คุณไม่จำเป็นต้องเป็นนักพัฒนาหลักเพื่อตรวจสอบความสมเหตุสมผลของการควบคุมความเสี่ยง ใช้ checklist นี้ก่อนการปรับใช้เงินทุนหรือการรวมระบบ:

1. ขอบเขต: มี cap ต่อสินทรัพย์, โหมด isolation หรือเพียงแค่ global pause แบบทื่อๆ?
2. คุณภาพ Oracle: feed มีค่าเกณฑ์การเบี่ยงเบน การตรวจสอบความล้าสมัย และ TWAP/medianization หรือไม่? การกำหนดค่าเปิดเผยต่อสาธารณะและตรวจสอบหรือไม่? ดู oracle docs
3. เส้นทางออก: ในช่วง soft-pause ผู้ใช้สามารถชำระคืน ลดเลเวอเรจ และถอนเงินได้หรือไม่? rate limit สมเหตุสมผลหรือไม่?
4. ความปลอดภัยในการกำกับดูแล: มี timelock การควบคุม multi-sig และบทบาทที่โปร่งใสหรือไม่? อำนาจฉุกเฉินและขอบเขตที่เปิดเผยหรือไม่?
5. Telemetry: มีหน้าสถานะสดหรือมุมมองบน chain ของสถานะ breaker และโควต้าหรือไม่?
6. วัฒนธรรมการทดสอบ: การทดสอบความเครียดและ postmortem เปิดเผยต่อสาธารณะหรือไม่? พารามิเตอร์เปลี่ยนแปลงอย่างรอบคอบ ไม่ใช่แค่ตอบสนองเท่านั้น?
7. ความพร้อมในการรวมระบบ: เหตุผลการ revert ชัดเจนและมีเอกสารประกอบหรือไม่? SDK/ABI เปิดเผยสถานะ breaker หรือไม่?

สัญญาณเตือน: ไม่มีเอกสาร oracle; การเติบโตไม่จำกัดในสินทรัพย์ long-tail; key ผู้ดูแลระบบเดียวที่มี global pause; หรือ UI ที่ซ่อนสถานะความเสี่ยง

Breaker ที่ผ่านการคิดอย่างรอบคอบจะไม่สามารถขจัด tail risk ได้ แต่ช่วยเปลี่ยนการลดเลเวอเรจที่วุ่นวายให้กลายเป็นการลดความเสี่ยงอย่างเป็นระเบียบ ซึ่งดีกว่าสำหรับผู้ใช้ LP และระบบนิเวศโดยรวม

หากคุณต้องการการวิเคราะห์อย่างต่อเนื่องเกี่ยวกับทางเลือกในการออกแบบโปรโตคอลและวิธีที่มันส่งผลต่อผู้ใช้และนักพัฒนา Crypto Daily ครอบคลุมกรอบงานความเสี่ยง การตรวจสอบ และการเปลี่ยนแปลงการกำกับดูแลโดยไม่มีการโฆษณาเกินจริง เยี่ยมชม Crypto Daily สำหรับข้อมูลเพิ่มเติม

คำถามที่พบบ่อย

Circuit breaker คือแค่ global pause หรือเปล่า?

ไม่ใช่ Breaker ที่มีประสิทธิภาพสูงสุดมีความละเอียด: cap ต่อสินทรัพย์, rate limit และ soft pause ที่อนุญาตให้ลดเลเวอเรจ Global pause เป็นทางเลือกสุดท้ายสำหรับความล้มเหลวร้ายแรง

Rate limit จะทำให้เกิดคิวและความหงุดหงิดของผู้ใช้หรือเปล่า?

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

Breaker โต้ตอบกับ composability อย่างไร?

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

ความแตกต่างระหว่าง fee escalator และการป้องกัน slippage คืออะไร?

Fee escalator เพิ่มต้นทุนระดับโปรโตคอลภายใต้ความเครียดเพื่อสะท้อนความเสี่ยงและยับยั้งการไหลที่เป็นพิษ การตั้งค่า slippage เป็นขอบเขตฝั่งผู้ใช้ ทั้งสองสามารถอยู่ร่วมกันได้

Pause guardian ที่ดำเนินการโดยมนุษย์ต่อต้าน DeFi หรือเปล่า?

พวกเขาเพิ่มความเสี่ยงด้านการรวมศูนย์ แต่อาจเป็นประโยชน์ในทางปฏิบัติในช่วงการโจมตีแบบใหม่ บรรเทาด้วย multi-sig, ขอบเขต, ความโปร่งใสบน chain และเส้นทางสู่การยกเลิกอำนาจเหล่านั้น

Oracle ไหน "ปลอดภัย"?

ไม่มี oracle ใดที่ปราศจากความเสี่ยง ใช้การออกแบบหลายแหล่ง ค่าเกณฑ์การเบี่ยงเบน การตรวจสอบความล้าสมัย และ TWAP/medianization ตามความเหมาะสม เผยแพร่การกำหนดค่าและตัวตรวจสอบ

Circuit breaker ป้องกันการล้มละลายได้หรือไม่?

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

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