การอภิปรายเชิงลึกเกี่ยวกับกลไกการให้ยืมและการชำระบัญชีของ DeFi และหลักการดำเนินการ ความเส

ชื่อเดิม: "แนวคิดการให้ยืม DeFi ตอนที่ 2: การชำระบัญชี"

การรวบรวมต้นฉบับ: Kxp, BlockBeats

การรวบรวมต้นฉบับ: Kxp, BlockBeats

ชื่อระดับแรก

หลักประกันเกินราคาและหนี้สูญ

คุณอาจจำได้จากบล็อกโพสต์ก่อนหน้าของเราว่าผู้ใช้โปรโตคอลสามารถให้ยืมหรือยืมสินทรัพย์ตามเปอร์เซ็นต์ของหลักประกันที่พวกเขาให้กับโปรโตคอลเท่านั้น สิ่งนี้สมเหตุสมผลเนื่องจากโปรโตคอลจำเป็นต้องตรวจสอบให้แน่ใจว่าสามารถกู้คืนสินทรัพย์ (หรือสินทรัพย์อื่น ๆ ที่มีมูลค่าเท่ากัน) จากคุณได้หากคุณไม่ชำระหนี้ กระบวนการจำนองสินทรัพย์นี้เริ่มต้นในระบบการเงินแบบดั้งเดิม เช่น ในปัจจุบัน ซึ่งบุคคลสามารถนำบ้านหรือ Lamborghini มาเป็นหลักประกันการชำระคืนเงินกู้ได้

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

ในโปรโตคอลการให้ยืมของ DeFi ส่วนใหญ่ สินทรัพย์เงินกู้ที่มีหลักประกันของคุณต้องมีมูลค่ามากกว่ามูลค่าเงินกู้ของคุณ ซึ่งเรียกว่าการค้ำประกันมากเกินไป

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

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

ชื่อระดับแรก

เกณฑ์การชำระบัญชีและการชำระบัญชี

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

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

ค่าใช้จ่ายในการส่งรายการหักบัญชีสูงมาก หากโปรโตคอลส่งธุรกรรมราคาแพงเหล่านี้โดยอัตโนมัติ ต้นทุนก๊าซที่เกิดขึ้นจะเพิ่มต้นทุนการดำเนินงาน ซึ่งส่งผลให้กำไรลดลง

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

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

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

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

ชื่อระดับแรก

สารประกอบ: สภาพคล่องของบัญชี

สารประกอบเกี่ยวข้องกับพารามิเตอร์ที่เรียกว่า AccountLiquidity ซึ่งคำนวณเกณฑ์การชำระบัญชีใน Comptroller ซึ่งเป็นสัญญาหลักของ Compound

Comptroller มีฟังก์ชันชื่อ getAccountLiquidity() ซึ่งจะส่งคืนข้อมูลเกี่ยวกับสภาพคล่องของบัญชี ภายใน ฟังก์ชันนี้เรียก getHypotheticalAccountLiquidityInternal():

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

จำได้จากโพสต์บล็อกก่อนหน้าของเราว่า cTokenBalance คือจำนวนของสินทรัพย์อ้างอิงที่ผู้ใช้จัดหาเพื่อเป็นหลักประกัน ในตัวอย่างนี้ เรายังสามารถเห็นการยืมบาลานซ์และ exchangeRateMantissa ลึกลับบางอย่าง ซึ่งทั้งคู่ส่งคืนจาก getAccountSnapshot()

ในตัวแปร exchangeRate ทั่วไปที่กล่าวถึงในบล็อกโพสต์ก่อนหน้านี้ เราเขียนว่า:

"อัตราดอกเบี้ยตามอำเภอใจสามารถเพิ่มจำนวนโทเค็นที่สร้างได้ หากอัตราแลกเปลี่ยน < 1 จะสามารถลดจำนวนโทเค็นได้ หากอัตราแลกเปลี่ยน > 1 ก็จะสามารถเพิ่มจำนวนโทเค็นได้"

นอกจากนี้ยังนำไปใช้กับ exchangeRateMantissa ซึ่งแสดงถึงอัตราแลกเปลี่ยนระหว่าง cToken และสินทรัพย์อ้างอิง

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

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

การกำกับดูแลของ Compound จะเปลี่ยนปัจจัยการค้ำประกันตามเงื่อนไขของตลาด แต่ ณ จุดใดก็ตาม ปัจจัยการค้ำประกันของพวกเขาจะต้องไม่เกิน 0.9 — มากถึง 90% ของหลักประกันที่คุณฝากสามารถให้ยืมได้:

จากนั้น เราจะเห็นการเรียกไปยัง oracle.getUnderlyingPrice(asset) ซึ่งเรียกสัญญาภายนอกที่เรียกว่า Oracle

Oracles เป็นกลไกที่น่าสนใจที่ควรค่าแก่การโพสต์บล็อกโดยเฉพาะ (คอยติดตาม) เพื่อความกระชับ สิ่งที่เรากำลังอธิบายในตอนนี้คือ oracle เป็นสัญญาที่ใช้เพื่อให้ได้มาซึ่งราคาของสินทรัพย์ในโปรโตคอลการให้ยืม โดยปกติจะเป็นสกุลเงินสาธารณะบางสกุลที่ใช้โดยโปรโตคอล (โดยปกติคือ USD, ETH หรือ Stablecoin ใช้โดยโปรโตคอล) เป็นพื้นฐาน

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

หมายเหตุ: ใน Compound ราคาสินทรัพย์จะเป็นสกุลเงินดอลลาร์สหรัฐ (USD)

นี่เป็นรายการตัวแปรที่ค่อนข้างยาว แต่ถ้าคุณพยายามจำส่วน Compound จากบทความ "Share Token" คุณจะพบนิพจน์ต่อไปนี้:

มันแสดงถึงมูลค่าสินทรัพย์พื้นฐานของ cToken ของผู้ใช้

นอกจากนี้ ตัวแปร loanBalance_{user} ดังที่คุณเห็นที่นี่ คือยอดรวมของสินทรัพย์ที่ผู้ใช้ยืม รวมถึงดอกเบี้ยค้างรับด้วย

ชื่อระดับแรก

Maker 

โปรโตคอลอื่นที่กำหนดเกณฑ์สำหรับการชำระบัญชีสถานะที่มีหลักประกันคือ Maker

ลองตรวจสอบสัญญาสองฉบับที่ปรับใช้โปรโตคอลเพื่อจัดการการชำระบัญชี:

สุนัข: ปรับใช้หลังจากย้ายไปยังการชำระบัญชี 2.0 (สิ่งที่การกำกับดูแลของ Maker เรียกว่า) ฟังก์ชันการชำระบัญชีที่นี่คือเปลือกไม้ ()

· Cat：liquidations 1.2 ，bite()。 

grab(): สัญญา VAT ใช้เป็นวิธีการชำระบัญชีก่อนที่จะมีการปรับใช้สัญญา cat

ลองดูตัวอย่างใน bite():

และตัวอย่างที่คล้ายกันจากbark():

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

เราสามารถใช้สมการนี้เพื่อกำหนดความไม่เท่าเทียมกันเพื่อให้ Vault (ชื่อ Maker ใช้สำหรับตำแหน่ง) ยังคงปลอดภัย:

เพิ่มประสิทธิภาพ:

เราแนะนำให้ผู้อ่านไปที่อภิธานศัพท์ MakerDAO เพื่อขยายข้อมูลที่เราให้เกี่ยวกับชื่อตัวแปรและคำศัพท์ต่างๆ ในระบบนิเวศของ Maker

หรือคุณสามารถเชื่อถือสิ่งที่เราระบุไว้ที่นี่:

• spot_{ilk} ใช้ในอสมการนี้เป็นราคาของหลักประกัน ซึ่งมีหน่วยเป็น DAI หารด้วยอัตราส่วนการชำระบัญชีของหลักประกัน (กำหนดโดยการกำกับดูแล)

• ink_{urn} คือยอดคงเหลือของตำแหน่ง

• rate_{ilk} คือความรับผิดสะสมสำหรับหลักประกันประเภทใดประเภทหนึ่ง เมื่อคูณด้วย art_{urn} ซึ่งเป็นจำนวนหนี้ปกติที่ยืมโดยโพสิชัน เราจะได้หนี้รวมในหน่วย DAI

เพื่อลดความซับซ้อนของสิ่งที่เราเพิ่งกล่าวถึง โดยไม่ใช้คำศัพท์ของ Maker เราจะนำเสนอในลักษณะนี้:

ชื่อระดับแรก

AAVE V2 - ปัจจัยด้านสุขภาพ

AAVE V2 ยังกำหนดเกณฑ์ HealthFactor ของตัวเองด้วย ผู้ใช้ที่มีค่าปัจจัยสุขภาพ H_{f} < 1 สามารถชำระบัญชีได้

กำหนดไว้ดังนี้

เห็นได้ชัดว่า เมื่อผู้ใช้ไม่มีหนี้สิน ตำแหน่งของพวกเขาจะไม่สามารถชำระบัญชีได้ ดังนั้นปัจจัยด้านสุขภาพจึงเริ่มต้นเป็นประเภท (uint 256) สูงสุด

มิฉะนั้น ปัจจัยด้านสุขภาพถูกกำหนดเป็น:

ชื่อระดับแรก

การวิเคราะห์ตำแหน่งล้มละลาย

ตอนนี้เราได้พูดถึงแนวคิดเรื่องหนี้เสียแล้ว เราจะยกตัวอย่างในโลกแห่งความเป็นจริงเพื่อเน้นย้ำถึงความสำคัญของหนี้เสีย

ตำแหน่งที่เราจะพูดถึงคือบัญชีต่อไปนี้บน AAVE V2: 0x 227 cAa 7 eF 6 D 955 A 92 F 483 d B2B D 01172997 A 1 a 623

ตรวจสอบสถานะปัจจุบันของโปรโตคอลการให้ยืม AAVE V2 โดยเรียกใช้ฟังก์ชัน getUserAccountData บนโปรโตคอล:

ตอนนี้เรามาดูรายละเอียดข้างต้นและดูว่าตำแหน่งนี้ไม่ดีอย่างไร:

· ETH ที่เป็นหนี้ทั้งหมด: 17.83508595148699 ETH

· ETH ที่จำนำทั้งหมด: 0.013596360502551568 ETH

นั่นคือทั้งหมดที่เราต้องรู้ ตำแหน่งนี้กำลังมีปัญหา - หลักประกันมีมูลค่าเพียงเศษเสี้ยวของที่เป็นหนี้อยู่

แล้วตำแหน่งนี้มีปัญหาได้อย่างไร?

เพื่อตอบคำถามนี้ เราสามารถดูการกระทำล่าสุดที่ดำเนินการโดยผู้ใช้รายนี้ใน AAVE:

ทุกอย่างดูเหมือนจะดีจนกระทั่งบล็อก 13514857 ซึ่งผู้ใช้ให้ยืมทรัพย์สินบางอย่างจาก AAVE มาดูกันว่าพวกเขาทำอะไร:

ลูกหนี้ได้ยืม MANA 700,000 MANA การดูราคา MANA ของ USD อย่างรวดเร็วเผยให้เห็นว่าราคาคือ:

0.00032838 ETH ต่อหน่วย MANA

โดยการคูณอย่างง่าย เรารู้ว่าผู้ใช้รายนี้ได้เพิ่มหนี้ของโปรโตคอลโดย: 0.00032838 * 700000 = 229.866 ETH

เป็นมูลค่าการกล่าวขวัญว่าราคา USD ที่บล็อกนั้นคือ $4417.40

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

ด้านบนคือการเรียก RPC ที่ส่งไปยังออราเคิลราคา AAVE V2 เพื่อรับค่า wei สำหรับ 1 หน่วย MANA ในบล็อกที่ระบุ

หากเราแปลงราคาข้างต้นโดยใช้ข้อมูลนี้ เราจะเห็นว่าเกิดอะไรขึ้น:

0.00033625 * 700000 = 235.375 ETH

ในเวลาเพียงไม่กี่ชั่วโมง หนี้เพิ่มขึ้น 5.5 ETH มูลค่า 24,000 ดอลลาร์

เนื่องจากเราทราบจุดสิ้นสุดของเรื่องราวสำหรับตำแหน่งนี้ เรารู้ว่าตำแหน่งนี้จะสามารถชำระได้ ณ จุดหนึ่ง ดังนั้น เรามาตรวจสอบว่ามี liquidationCall ที่เกี่ยวข้องกับที่อยู่ผู้ใช้นี้หรือไม่:

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

เราจะเห็นว่าการชำระบัญชีครั้งแรกเกิดขึ้นที่บล็อก 13520838 การชำระบัญชีนี้เกิดขึ้นก่อนที่ผู้ใช้จะฝากเงิน (ประมาณ 7 นาทีก่อนธุรกรรมการฝากเงิน)

จากนั้น ระหว่างบล็อก 13520838-13522070 มีการชำระบัญชีจำนวนเล็กน้อยที่จบลงด้วยมูลค่าค่อนข้างมาก:

เรามาตรวจสอบประเภทสินทรัพย์ค้ำประกันทั้งหมดที่ยึดโดยผู้ชำระบัญชีจากผู้ใช้ระหว่างช่วงเหล่านี้:

เราจะเห็นว่ามีเพียง 2 สินทรัพย์คือ DAI (stablecoin) และ ETH

และจำนวนของพวกเขา:

~ 50 ETH 

~ 387663 DAI 

อาจมีคนถามว่าทำไมการชำระบัญชีจึงแบ่งออกเป็นก้อนเล็ก ๆ เช่นนี้?

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

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

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

อย่างที่เราเห็น เปอร์เซ็นต์ขีดจำกัดคือ 50% ซึ่งหมายความว่ามีเพียงครึ่งหนึ่งของหนี้ของตำแหน่งเท่านั้นที่ได้รับอนุญาตให้ชำระคืนในการชำระบัญชีครั้งเดียว

ผู้ชำระบัญชีมีแรงจูงใจที่จะแบ่งการชำระบัญชีออกเป็นส่วนย่อยๆ หากมีสภาพคล่องในตลาดไม่เพียงพอที่จะจัดหาสินทรัพย์ค้ำประกันในเวลาที่ทำการชำระบัญชี ดังนั้น การแบ่งการชำระบัญชีออกเป็นชิ้นเล็ก ๆ ผู้ชำระบัญชีมีแนวโน้มที่จะได้รับสินทรัพย์ที่ชำระบัญชีและกำไรจากการชำระบัญชี

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

สุดท้าย ลองจินตนาการถึงการพยายามเลิกใช้โทเค็นบางประเภทจำนวนมากโดยไม่ได้เป็นเจ้าของโทเค็นจำนวนมาก หากคุณไปที่ DEX และพยายามแลกเปลี่ยน WETH หรือสินทรัพย์อื่นๆ เพื่อรับโทเค็นนี้ คุณอาจพบกับค่าธรรมเนียมก๊าซที่สูงมาก ซึ่งจะทำให้การชำระบัญชีของคุณไม่ได้กำไร

กลับมาที่ตัวอย่างของเรา เพื่อตรวจสอบพารามิเตอร์ตำแหน่งหลังจากการชำระบัญชีหลายครั้งในห่วงโซ่ เราจำเป็นต้องแยกวิเคราะห์ข้อมูลที่ส่งกลับมาให้เราจาก getUserAccountData:

จากนั้นเราสอบถาม chain โดยใช้ cast:

ผลลัพธ์การแยกวิเคราะห์ขั้นสุดท้าย:

ที่นี่เราเห็นผลของการชำระบัญชีในตำแหน่ง: แทบไม่มีหลักประกันเหลืออยู่ 0.6 ETH เพื่อความแม่นยำ แต่สิ่งที่เกี่ยวกับหนี้? สูงถึง 45.26716296709878 ETH

ราคา MANA สำหรับบล็อคนี้คืออะไร?

0.000862110734985458 ETH。

หากคุณจำได้ ผู้ใช้ของเราได้ยืม MANA เมื่อไม่กี่ชั่วโมงก่อนเป็นจำนวน 0.00032838 ETH นี่เทียบเท่ากับการเปิดตำแหน่งสั้นในหุ้นที่ราคาเพิ่มขึ้น 2.65 เท่า

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

สรุป

สรุป

แม้ว่าเราจะไม่แน่ใจว่ามีสมการที่กำหนดเกณฑ์สภาพคล่องสำหรับตำแหน่งหรือไม่ แต่เราสามารถเห็นความคล้ายคลึงกันระหว่างโปรโตคอลได้อย่างแน่นอน:

โปรโตคอลทั้งหมดกำหนดเกณฑ์เป็นฟังก์ชันของหลักประกันเทียบกับหนี้สินบางประเภท (ไม่ว่าจะเป็นอัตราส่วนหรือความแตกต่าง)

โปรโตคอลทั้งหมดออกจากพื้นที่สำหรับการกำกับดูแลเพื่อตัดสินใจมูลค่าของพารามิเตอร์ความเสี่ยงหลักประกันแต่ละรายการโดยอิงตามสภาวะตลาดที่เปลี่ยนแปลง เนื่องจากสินทรัพย์บางอย่างมีความผันผวนมากกว่าสินทรัพย์อื่นๆ

โปรโตคอลทั้งหมดใช้ออราเคิลเพื่อกำหนดราคาหลักประกันและตราสารหนี้ในสกุลเงินที่ยอมรับอย่างกว้างขวาง (เช่น ETH, USD, DAI)

ลิงค์ต้นฉบับ

ลิงค์ต้นฉบับ