จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน ระบบการให้กู้ยืมและการชำระบัญชี DeFi อาจทำให้เกิดการสูญเสียอย่างรวดเร็วและไม่อาจเรียกคืนได้
คำตอบโดยตรง
ความล้มเหลวของ Keeper การชำระบัญชีหนึ่งรายมักทำให้ธุรกรรมตกหล่นหรือถูกย้อนกลับ ไม่ใช่ทำให้โปรโตคอลล้มเหลวทันที ในโปรโตคอลให้กู้ยืมจำนวนมากไม่มี Keeper ที่มีสิทธิ์แต่เพียงผู้เดียว การชำระบัญชีเปิดให้ทุกคนดำเนินการได้โดยไม่ต้องขออนุญาต ดังนั้นบอต สัญญา หรือผู้ใช้รายอื่นจึงส่งธุรกรรมแทนได้ ตัวอย่างเช่น Aave ระบุว่าผู้เข้าร่วมเครือข่ายรายใดก็สามารถชำระบัญชีสถานะที่เข้าเกณฑ์ได้ และอธิบายว่าการชำระบัญชีมีการแข่งขันสูง
กรณีที่ร้ายแรงคือความล้มเหลวโดยรวม ซึ่งไม่มีผู้เข้าร่วมรายใดสามารถหรือยินดีดำเนินการในราคาที่คุ้มค่าทางเศรษฐกิจ สถานะอาจอยู่ต่ำกว่าเกณฑ์การชำระบัญชีต่อไป ขณะที่ดอกเบี้ยสะสมและมูลค่าหลักประกันยังคงเปลี่ยนแปลง หากการชำระบัญชีในภายหลังกู้คืนมูลค่าได้น้อยกว่าหนี้และต้นทุนที่บันทึกให้กับสถานะนั้น ส่วนต่างจะกลายเป็นยอดขาดหรือหนี้เสียตามหลักการบัญชีของโปรโตคอลนั้น
ผู้ที่รับภาระยอดขาดขึ้นอยู่กับแต่ละโปรโตคอล ฟังก์ชัน absorb ของ Compound III โอนหนี้ของบัญชีที่มีหนี้เกินสินทรัพย์ไปยังโปรโตคอลและใช้เงินสำรองของสินทรัพย์ฐาน ขณะที่โปรโตคอลรับหลักประกันไว้ ส่วน Dog.bark ของ Maker โอนหนี้ของ Vault ที่ไม่ปลอดภัยไปยังโปรโตคอล เริ่มการประมูลหลักประกัน และบันทึกหนี้ในระบบบัญชี ระบบอื่นอาจใช้เงินสำรอง กองทุนประกันหรือกองทุนรักษาเสถียรภาพ การเพิ่มทุนผ่านธรรมาภิบาล การกระจายผลขาดทุน หรือหลายวิธีร่วมกัน
ดังนั้นระบบชำระบัญชีอัตโนมัติจึงไม่ใช่บริการ stop-loss สำหรับผู้กู้ วิธีที่ปลอดภัยคือเฝ้าติดตามสถานะและชำระหนี้หรือเพิ่มหลักประกันก่อนข้ามเกณฑ์ การชำระบัญชีที่ล่าช้าอาจเพิ่มทั้งการสูญเสียหลักประกันและโอกาสเกิดยอดขาดที่ไม่สามารถกู้คืนได้
วิธีการทำงาน
เส้นทางทั่วไปของผู้ชำระบัญชีภายนอกมีห้าขั้นตอน:
- การเข้าเกณฑ์: โปรโตคอลอ่าน oracle ที่กำหนดค่าไว้และพิจารณาว่าบัญชีข้ามเกณฑ์การชำระบัญชีแล้ว oracle ที่ล้าสมัยหรือหยุดทำงานอาจทำให้การเปลี่ยนสถานะนี้ล่าช้าหรือถูกบล็อก แม้ราคาตลาดจะเปลี่ยนไปแล้วก็ตาม
- การตรวจจับและกำหนดราคา: บอตนอกเชนจัดทำดัชนีสถานะ จำลองการชำระบัญชี ประเมินมูลค่าที่จะได้รับจากหลักประกัน และตัดสินใจว่าโอกาสนั้นทำกำไรได้หรือไม่
- การบรรจุธุรกรรม: ผู้ชำระบัญชีจัดหาเงินในสินทรัพย์หนี้ที่จำเป็น ส่งธุรกรรม และแข่งขันเพื่อพื้นที่ในบล็อก ความแออัด ค่าธรรมเนียมที่ต่ำเกินไป RPC ที่ล้มเหลว ความขัดแย้งของ nonce หรือการที่ผู้ชำระบัญชีรายอื่นชนะก่อน อาจทำให้ธุรกรรมค้างอยู่หรือถูกย้อนกลับ
- การดำเนินการของสัญญา: สัญญาตรวจสอบราคาปัจจุบัน สถานะบัญชี close factor หรือขีดจำกัดการประมูล การควบคุมการหยุดชั่วคราว และสภาพคล่องที่มีอยู่ ธุรกรรมที่ใช้ได้ในระหว่างการจำลองอาจล้มเหลวหลังจากข้อมูลใดข้อมูลหนึ่งเปลี่ยนแปลง
- การจำหน่ายหลักประกัน: ผู้ชำระบัญชีหรือโปรโตคอลต้องขาย ป้องกันความเสี่ยง หรือประมูลหลักประกันที่ยึดมา สภาพคล่องที่เบาบางและตลาดขาลงอาจเปลี่ยนโบนัสที่ดูน่าสนใจให้เป็นผลขาดทุน
การตัดสินใจอย่างง่ายของผู้ชำระบัญชีคือ expected profit = liquidation incentive - gas - price impact - hedge cost - expected revert loss และอาจมีต้นทุนเงินทุนกับค่าธรรมเนียมโปรโตคอลด้วย โบนัสที่ประกาศไว้สูงยังไม่เพียงพอ หากขายหลักประกันใกล้ราคา oracle ไม่ได้หรือมีโอกาสน้อยที่การดำเนินการจะสำเร็จ
ความล้มเหลวมักเกิดเพียงบางส่วน ไม่ใช่ทั้งหมด บัญชี ประเภทหลักประกัน เชน oracle ผู้ให้บริการ RPC หรือการประมูลรายการหนึ่งอาจล้มเหลว ขณะที่ส่วนอื่นยังทำงานต่อไป ตัวอย่างเช่น เอกสาร Liquidation 2.0 ของ Maker มีขีดจำกัดการประมูลทั้งรายหลักประกันและระดับรวม การเริ่มการประมูลใหม่ สิ่งจูงใจสำหรับ Keeper และ circuit breaker สี่ระดับ การควบคุมเหล่านี้เปลี่ยนวิธีที่ความล่าช้าในการดำเนินการแพร่กระจายภายในระบบนั้นโดยเฉพาะ
ตัวอย่างการคำนวณ
สมมติว่าบัญชีที่เข้าเกณฑ์มีหนี้ 100,000 USDC และหลักประกันมูลค่า 103,000 USDC โปรโตคอลแบบง่ายอนุญาตให้ผู้ชำระบัญชีชำระคืน 50,000 USDC และรับหลักประกันมูลค่า 52,500 USDC ซึ่งเป็นสิ่งจูงใจก่อนหักต้นทุน 5%
- คาดว่าการขายหลักประกันจะมีต้นทุนจากผลกระทบต่อราคา
2,000 USDC - ค่า gas และค่าธรรมเนียมลำดับความสำคัญเท่ากับ
700 USDC - ต้นทุนคาดหมายของธุรกรรมที่ถูกย้อนกลับหรือถูกคู่แข่งดำเนินการตัดหน้าเท่ากับ
300 USDC - ดังนั้นกำไรคาดหมายคือ
52,500 - 50,000 - 2,000 - 700 - 300 = -500 USDC
ผู้ชำระบัญชีที่มีเหตุผลอาจรอหรือข้ามบัญชีนี้ หากไม่มีใครดำเนินการและหลักประกันลดลงอีก 5% มูลค่าจะเหลือ 97,850 USDC ทำให้เกิดยอดขาด 2,150 USDC เมื่อเทียบกับหนี้เดิม ก่อนรวมดอกเบี้ยหรือค่าธรรมเนียมเพิ่มเติม การชำระบัญชีในภายหลังยังช่วยลดความเสียหายได้ แต่ไม่สามารถสร้างมูลค่าหลักประกันที่ไม่มีอยู่อีกแล้ว
นี่เป็นเพียงตัวอย่าง ไม่ใช่แบบจำลองของตลาดใดตลาดหนึ่งที่ใช้งานจริง ต้องอ่าน close factor โบนัส ราคา oracle ค่าธรรมเนียมโปรโตคอล กฎเงินสำรอง และต้นทุนธุรกรรมจริงจากสัญญาปัจจุบันและเอกสารทางการ ตัวอย่างเช่น กฎที่ Aave เผยแพร่กำหนดสัดส่วนสูงสุดที่ชำระบัญชีได้แตกต่างกันตาม health factor และขนาดสถานะ
ความเสี่ยงและมาตรการป้องกัน
- การควบคุมของผู้กู้: รักษาส่วนเผื่อเหนือเกณฑ์การชำระบัญชีอย่างตั้งใจ ตั้งการแจ้งเตือนอิสระ และเตรียมวิธีที่ผ่านการทดสอบแล้วสำหรับชำระหนี้หรือเพิ่มหลักประกัน อย่าสันนิษฐานว่าส่วนหน้า ผู้ให้บริการระบบอัตโนมัติ หรือผู้ชำระบัญชีจะพร้อมใช้งานเสมอในช่วงที่เครือข่ายแออัด
- การควบคุมของโปรโตคอล: ระบบที่แข็งแกร่งกระจายโครงสร้างพื้นฐาน oracle และธุรกรรม ปรับโบนัสและขนาดสถานะขั้นต่ำ จำกัดปริมาณการชำระบัญชี รองรับการชำระบัญชีบางส่วนหรือแบบกลุ่มเมื่อเหมาะสม และกำหนดการหยุดชั่วคราว การเริ่มการประมูลใหม่ เงินสำรอง และการจัดการยอดขาดไว้ก่อนเกิดวิกฤต
- การควบคุมของผู้ชำระบัญชี: ผู้ดำเนินการควรใช้ endpoint RPC หลายแห่ง กระทบยอดสถานะบนเชนก่อนลงนาม จำลองกับสถานะที่รอดำเนินการ จัดการการแทนที่ nonce จำกัด slippage และหลีกเลี่ยงการพึ่งพาศูนย์ซื้อขายหรือแหล่งสภาพคล่องแบบ flash เพียงแห่งเดียว
- การตรวจสอบของผู้ให้กู้และผู้ฝาก: ระบุลำดับการรับภาระหนี้เสียที่แน่นอน ตรวจสอบว่าเงินสำรองใดครอบคลุมตลาดใด ใครเปลี่ยนพารามิเตอร์ได้ เงินสำรองมีสภาพคล่องและเข้าถึงได้หรือไม่ และจะเกิดอะไรขึ้นหลังเงินสำรองหมด
ไม่มีมาตรการป้องกันใดรับประกันการดำเนินการได้ สิ่งจูงใจอาจน้อยเกินไปในตลาดที่สงบ แต่สูงเกินควรหรือเปิดช่องให้แสวงหาประโยชน์หลังพารามิเตอร์เปลี่ยนแปลง การหยุดชั่วคราวและ circuit breaker อาจจำกัดความเสียหายจาก oracle หรือสัญญาที่ผิดพลาด แต่ก็อาจจงใจหยุดการชำระบัญชีและปล่อยให้ความเสี่ยงด้านราคาสะสม คำถามที่สำคัญคือทั้งระบบทำงานอย่างไรเมื่อเกิดแรงกดดันด้านราคา สภาพคล่อง เครือข่าย และโครงสร้างพื้นฐานพร้อมกัน
ความเข้าใจผิดที่พบบ่อย
ความเชื่อผิด 1: ทุกโปรโตคอลแต่งตั้ง Keeper ที่เชื่อถือได้หนึ่งราย
โปรโตคอลจำนวนมากอนุญาตให้ทุก address ดำเนินการชำระบัญชีได้ บอตที่ถูกระบุชื่ออาจเป็นเพียงผู้เข้าร่วมหรือผู้ให้บริการอินเทอร์เฟซรายหนึ่ง การหยุดทำงานของบอตมีผลก็ต่อเมื่อไม่มีผู้แทนรายใดดำเนินการได้
ความเชื่อผิด 2: สถานะที่เข้าเกณฑ์ถูกชำระบัญชีแล้ว
การเข้าเกณฑ์คือสถานะของสัญญา ส่วนการชำระบัญชีเป็นธุรกรรมหรือการประมูลแยกต่างหาก ความเสี่ยงต่อตลาดยังคงอยู่จนกว่าการดำเนินการนั้นจะสำเร็จ และมีการบันทึกบัญชีหนี้กับหลักประกันที่เกิดขึ้นแล้ว
ความเชื่อผิด 3: การเพิ่ม gas แก้ไขความล้มเหลวได้เสมอ
ค่าธรรมเนียมธุรกรรมที่สูงขึ้นอาจเพิ่มลำดับความสำคัญในการบรรจุ แต่ไม่สามารถแก้ไข oracle ที่ล้าสมัย ตลาดที่ถูกหยุด เงินทุนไม่เพียงพอ allowance ที่ขาดหาย สถานะบัญชีที่เปลี่ยนไป การขายหลักประกันที่ไม่ทำกำไร หรือการย้อนกลับของสัญญา
ความเชื่อผิด 4: หนี้เสียหมายความว่าผู้ให้กู้เสียเงินจำนวนเท่ากันทันที
หนี้เสียจะเข้าสู่ลำดับการรับภาระผลขาดทุนที่โปรโตคอลกำหนดไว้ก่อน เงินสำรองหรือกลไกหนุนหลังอื่นอาจรับภาระแทน ผู้ให้กู้หรือผู้ถือโทเค็นธรรมาภิบาลจะได้รับผลกระทบตามกฎที่ใช้และทรัพยากรที่มีเท่านั้น และช่วงเวลาอาจต่างจากขณะที่ยอดขาดปรากฏขึ้น
หัวข้อที่เกี่ยวข้อง
- การชำระบัญชีคริปโต
- โบนัสการชำระบัญชี
- Close factor ของการชำระบัญชี
- ราคา oracle ล้าสมัย
- กองทุนประกันคริปโต
แหล่งที่มา
- Health Factor & Liquidations - Aave (เข้าถึงเมื่อ: 2026-08-21)
- Compound III Docs: Liquidation - Compound (เข้าถึงเมื่อ: 2026-08-21)
- Liquidation 2.0 Module - Maker Protocol Technical Docs (เข้าถึงเมื่อ: 2026-08-21)