ความเสี่ยงจากการหยุดทำงานของ Oracle ใน DeFi: เหตุใดฟีดข้อมูลเดียวจึงสามารถทำให้โปรโตคอลการเทรดหยุดชะงักได้

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

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

คำตอบโดยย่อ

การหยุดทำงานของ oracle มีความสำคัญเพราะแอป DeFi จำนวนมากพึ่งพา price feed เดียวในการกำหนดมูลค่าหลักประกัน กระตุ้นการ liquidation หรือตรวจสอบการซื้อขาย หาก feed นั้นหยุดอัปเดต ส่งคืนข้อมูลเก่า หรือเบี่ยงเบนออกจากความเป็นจริงอย่างรวดเร็ว protocol อาจหยุดตลาดหรือบล็อกธุรกรรมเพื่อป้องกันการสูญเสียแบบลูกโซ่ ความยืดหยุ่นมาจากการกระจายแหล่งข้อมูล circuit breaker แบบเป็นชั้น และกระบวนการตอบสนองต่อเหตุการณ์ที่ชัดเจน

• Feed เดียวอาจกลายเป็น single point of failure สำหรับการกำหนดราคาและการตรวจสอบความเสี่ยง
• ปัญหาทั่วไป ได้แก่ ความล้มเหลวด้าน liveness ราคาที่ล้าสมัย และความล่าช้าข้ามเชน
• มาตรการบรรเทา: การรวม multi-oracle, เกณฑ์ deviation + heartbeat, TWAP บนเชน และการหยุดชั่วคราวโดยใช้ quorum
• Runbook, canary และการทดสอบ chaos ช่วยลดระยะเวลาการกู้คืนเมื่อเกิดเหตุขัดข้อง

Oracle ของ DeFi คืออะไร และทำไม protocol จึงต้องพึ่งพามัน?

Oracle ของ DeFi คือ middleware ที่นำข้อมูลภายนอก ซึ่งส่วนใหญ่เป็นราคาสินทรัพย์ มาบนเชนเพื่อให้ smart contract สามารถดำเนินการได้ ตลาดสินเชื่อใช้ oracle ในการประเมินมูลค่าหลักประกันและหนี้สิน ตลาด perpetual exchange ต้องการเพื่อชำระ funding และ liquidation Stablecoin อ้างอิงเพื่อปกป้อง peg หากไม่มี oracle ที่เชื่อถือได้ "autonomous finance" ก็ขาดข้อมูลที่จำเป็นในการคำนวณความเสี่ยง

ระบบ oracle ส่วนใหญ่รวมแหล่งข้อมูล off-chain หลายแหล่ง ลงนามการสังเกต และเผยแพร่ราคาที่รวมกันไปยัง blockchain รูปแบบการออกแบบมีความหลากหลาย: บางส่วนส่งการอัปเดตเมื่อราคาเปลี่ยนแปลงเพียงพอ บางส่วนถูกสอบถามตามความต้องการ (pull) บางส่วนเป็นแบบ optimistic และอนุญาตให้มีการโต้แย้ง บางส่วนเป็นแบบชัดเจนโดยมีคณะกรรมการ validator หรือผู้ให้บริการข้อมูลโพสต์ราคา

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

Data feed เดียวสามารถทำให้ protocol หยุดชะงักได้อย่างไร?

แอป DeFi เข้ารหัสมาตรการป้องกันที่อาศัยราคาที่อัปเดตล่าสุด เมื่อมาตรการเหล่านั้นล้มเหลวเพราะ oracle หยุดทำงาน เส้นทางธุรกรรมอาจปิดตัวเองโดยอัตโนมัติเป็นการป้องกัน ตัวอย่างเช่น:

การหยุดการซื้อขาย: หาก DEX หรือสถานที่ซื้อขาย perp ต้องการราคา oracle "ล่าสุด" (เช่น อัปเดตภายใน heartbeat ที่กำหนด) timestamp ที่หมดอายุจะทำให้คำสั่งหรือการอัปเดตถูกยกเลิก ดีกว่าที่จะหมดเวลามากกว่าการ fill ในราคาที่ผิดพลาด

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

สถานการณ์การหยุดทำงานแบบใดที่พบบ่อยที่สุด?

แม้ว่าแต่ละเหตุการณ์จะมีลักษณะเฉพาะ แต่รูปแบบหลายอย่างเกิดซ้ำข้ามเชนและผู้ให้บริการ oracle การทำความเข้าใจรูปแบบเหล่านี้ช่วยให้คุณออกแบบการป้องกันล่วงหน้าได้

ความล้มเหลวด้าน Liveness: Validator หรือผู้เผยแพร่ข้อมูลล้มเหลวในการโพสต์การอัปเดต สาเหตุ ได้แก่ ความแออัดของเครือข่าย การหยุดทำงานของผู้ให้บริการ ปัญหาการหมุนเวียน signer หรือ gas spike ที่ทำให้การอัปเดตไม่คุ้มค่าทางเศรษฐกิจ

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

Tick ที่ผิดพลาดหรือค่าผิดปกติ: การอัปเดตที่ผิดพลาดครั้งเดียว (fat-finger, print จากตลาดที่ไม่ดี หรือข้อผิดพลาดในการรวมข้อมูล) เบี่ยงเบนออกจากความเป็นจริงของตลาดอย่างมาก การใช้งานที่ดีจะใช้เกณฑ์ deviation และการตรวจสอบข้ามแหล่งหลายแหล่งเพื่อปฏิเสธหรือกักกันค่าผิดปกติ

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

การบิดเบือนข้อมูลในช่วงที่ venue หยุดทำงาน: หาก centralized exchange รายใหญ่หยุดตลาด spot ที่สำคัญ oracle ที่ให้น้ำหนักกับ venue นั้นมากเกินไปอาจรับการบิดเบือนไป ในขณะที่ราคาตลาดที่กว้างขึ้นเคลื่อนไหวไปที่อื่น

การออกแบบ oracle ชั้นนำแตกต่างกันอย่างไรในทางปฏิบัติ?

เครือข่าย oracle เข้าถึง liveness, ความแม่นยำ และการแก้ข้อพิพาทแตกต่างกัน ตารางด้านล่างแสดงความแตกต่างในระดับสูงที่คุณสามารถตรวจสอบได้ในเอกสารทางการ

Oracle รูปแบบการอัปเดต การจัดหาข้อมูล การโต้แย้ง/การป้องกัน หมายเหตุที่น่าสังเกต เอกสาร Chainlink Push-based พร้อม deviation + heartbeat ผู้ให้บริการ off-chain หลายรายที่รวมกัน เกณฑ์ Aggregator; logic fallback บนเชนต่อ client รวมเข้ากับระบบอย่างกว้างขวาง; เน้นการอัปเดตแบบอนุรักษ์นิยม docs.chain.link Pyth Network ผู้เผยแพร่ความถี่สูง; pull/push ผ่าน relay ผู้มีส่วนร่วมจากตลาดแลกเปลี่ยนและ market maker ช่วงความเชื่อมั่น; การตรวจสอบ price attestation เน้น price attestation ที่มีความหน่วงต่ำ docs.pyth.network Band Protocol Oracle script บนเชนเฉพาะ Validator-set สอบถามแหล่งข้อมูล ฉันทามติบนเชน oracle; ส่งต่อตามความต้องการ ชุดข้อมูลที่ปรับแต่งได้ผ่าน oracle script docs.bandchain.org UMA (Optimistic) Propose-and-dispute ผู้เสนอใดก็ได้ส่ง; ผู้ลงคะแนนแก้ไขข้อพิพาท การรับประกันทางเศรษฐกิจผ่าน dispute bond และการลงคะแนน ยืดหยุ่น ไม่ใช่แค่ price feed docs.umaproject.org Maker Oracles Feed set เผยแพร่ไปยัง medianizer บนเชน Feed ที่คัดสรร; บริหารจัดการโดย governance Medianization และการหยุดชั่วคราวที่ควบคุมโดย governance กรอบความเสี่ยงหลักประกันที่ดำรงมานาน docs.makerdao.com

ความแตกต่างไม่ได้หมายความว่าดีกว่าหรือแย่กว่าโดยสากล ขึ้นอยู่กับกรณีการใช้งานของคุณ Perp ที่มีความหน่วงต่ำอาจต้องการการอัปเดตที่บ่อยครั้งพร้อมช่วงความเชื่อมั่น ในขณะที่การให้กู้ยืมแบบ overcollateralized อาจต้องการ heartbeat แบบอนุรักษ์นิยมและการรวมข้อมูลที่กว้างขึ้น Protocol ที่เติบโตเต็มที่หลายแห่งรวมการออกแบบเข้าด้วยกัน: เช่น push-based feed หลักบวกกับ TWAP บนเชนเป็นการตรวจสอบความสมเหตุสมผล

รูปแบบความซ้ำซ้อนใดที่ลดความเสี่ยงของ oracle ได้จริง?

การบรรเทาเริ่มต้นด้วยสมมติฐานว่าส่วนประกอบเดียวใดๆ อาจล้มเหลวได้ รูปแบบต่อไปนี้ถูกใช้กันอย่างแพร่หลายเพื่อป้องกันไม่ให้ feed เดียวทำให้แอปทั้งหมดหยุดชะงัก

• การรวม Multi-oracle: อ่านจาก oracle อิสระสองตัวขึ้นไปและใช้ค่ามัธยฐาน/ค่าเฉลี่ยที่ตัดแต่ง ความเป็นอิสระมีความสำคัญ ควรหลีกเลี่ยงแหล่งที่มีความสัมพันธ์กันหรือผู้เผยแพร่ที่ใช้ร่วมกัน
• Logic Deviation + heartbeat: กระตุ้นการอัปเดตหรือรับราคาใหม่เฉพาะเมื่อเกินเกณฑ์หรือผ่านขีดจำกัดเวลา สิ่งนี้สร้างสมดุลระหว่างความสดใหม่กับค่า gas และลดหน้าต่างราคาล้าสมัย
• TWAP fallback บนเชน: ใช้ time-weighted average price จาก decentralized exchange เป็นการตรวจสอบข้ามหรือ fallback ชั่วคราว โดยคำนึงถึงหน้าต่างการจัดการ ดูเอกสาร Uniswap oracle สำหรับคำแนะนำ
• กฎที่ตระหนักถึงความเชื่อมั่น: หาก oracle ของคุณให้ช่วงความเชื่อมั่นหรือส่วนเบี่ยงเบนมาตรฐาน ให้ปรับขนาดปัจจัยหลักประกันหรือเพดานตำแหน่งในทิศทางผกผันกับความไม่แน่นอน
• Kill-switch โดย quorum: อนุญาตให้ multisig หรือ council ที่มี timelock หยุดตลาดเฉพาะได้อย่างรวดเร็ว พร้อมเหตุผลที่โปร่งใสบนเชนและการสิ้นสุดอัตโนมัติเพื่อหลีกเลี่ยงการหยุดชะงักอย่างไม่มีกำหนด
• ความเป็นอิสระข้ามเชน: ต้องการ feed ที่เป็นพื้นเมืองบนแต่ละเชนเมื่อเป็นไปได้เพื่อหลีกเลี่ยงการผูกติดกับความล่าช้าของ bridge มิฉะนั้น ให้มอนิเตอร์ความล่าช้าของ relay และตั้งเกณฑ์ความล้าสมัยที่เข้มงวดยิ่งขึ้นบนเชนปลายทาง

ทีมความเสี่ยงควรมอนิเตอร์อะไรแบบ real time?

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

• ความสดใหม่ของราคา: เวลาตั้งแต่การอัปเดตล่าสุดเทียบกับ heartbeat ที่กำหนดสำหรับแต่ละตลาด
• Flag deviation: ช่องว่างระหว่างราคา oracle และ TWAP บนเชนหรือ feed สำรอง; แจ้งเตือนทั้งเกณฑ์แบบสัมบูรณ์และเปอร์เซ็นต์
• สุขภาพของผู้เผยแพร่: จำนวนผู้ให้บริการข้อมูล/validator ที่ active และอัตราความเห็นพ้อง (เมื่อ oracle เปิดเผย)
• สภาวะของเชน: Gas spike, ความแออัดของ mempool หรือความล่าช้าของ finality ที่อาจขัดขวางการอัปเดต
• ความล่าช้าของ relay ข้ามเชน: อายุและลำดับของ attestation ที่ bridge จากเชนต้นทางไปยังเชนปลายทาง
• Backlog การ liquidation: จำนวนตำแหน่งที่มีความเสี่ยงที่ไม่สามารถ liquidate ได้เนื่องจากการตรวจสอบความล้าสมัย
• Pause lever: สถานะของ circuit breaker และการควบคุม guardian; เวลาที่เหลืออยู่บนการดำเนินการที่มี timelock

ป้อนสัญญาณเหล่านี้เข้าสู่ playbook อัตโนมัติ: ลดเพดาน leverage เมื่อความเชื่อมั่นขยายตัว เพิ่ม maintenance margin ในช่วงที่เกิดการหยุดทำงานบางส่วน หรือจำกัดการกู้ยืมใหม่ในขณะที่อนุญาตให้ชำระคืนได้เพื่อลดความเสี่ยงเชิงระบบ

จะหยุดชั่วคราวอย่างปลอดภัยโดยไม่ทำให้ตลาดหยุดชะงักถาวรได้อย่างไร?

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

กำหนดระดับ: เริ่มต้นด้วยเบรกแบบนุ่มนวล (ปรับ LTV ให้แน่นขึ้น, ปิดการใช้ leverage ใหม่) ก่อนหยุดสมบูรณ์ (ปิดการซื้อขาย) รักษา allowlist สำหรับการดำเนินการที่ไม่เป็นอันตราย เช่น การชำระคืน การถอนภายในการค้ำประกันที่ดี หรือการปิดตำแหน่งตามความต้องการของผู้ใช้โดยใช้ราคา fallback แบบอนุรักษ์นิยม

ตั้งตัวตั้งเวลาอัตโนมัติและหน้าต่างการตรวจสอบ: การหยุดฉุกเฉินใดๆ ควรมีวันหมดอายุเว้นแต่ governance จะต่ออายุ บวกกับข้อกำหนด post-mortem สาธารณะ สิ่งนี้ป้องกันการหยุดชะงัก "ชั่วคราว" ไม่ให้ยืดเยื้อ

รายการตรวจสอบการเปิดใช้งานใหม่: ต้องการไฟเขียวหลายดวง ได้แก่ จังหวะราคาที่สด deviation ที่แก้ไขแล้ว publisher set ที่ได้รับการตรวจสอบ และการ liquidation dry run จำลอง ก่อนเปิดใหม่

หมายเหตุการใช้งาน: จากการออกแบบสู่การทดสอบ

ความยืดหยุ่นไม่ใช่แค่เรื่องของสถาปัตยกรรม แต่เป็นเรื่องของพฤติกรรมภายใต้ความเครียด ฝังแนวปฏิบัติเหล่านี้ไว้ในวงจรชีวิตการพัฒนาของคุณ

• Oracle abstraction layer: รวม feed ไว้หลัง module ที่สามารถสลับผู้ให้บริการ ปรับเกณฑ์ หรือใส่ fallback โดยไม่ต้องเขียน business logic ใหม่
• Shadow feed ในโปรดักชัน: บันทึก oracle/TWAP สำรองนอกเส้นทางเพื่อให้คุณสามารถเปรียบเทียบและตรวจสอบการตัดสินใจย้อนหลังได้
• Chaos engineering: จำลอง oracle stall, ค่าผิดปกติกะทันหัน, ความล่าช้าข้ามเชน และความล้มเหลวของผู้เผยแพร่บางส่วนเป็นประจำในสภาพแวดล้อม mainnet แบบ fork
• Dry-run liquidation: ในระหว่างเหตุการณ์ ให้ทดสอบ liquidation แบบ off-chain กับราคา fallback ที่เสนอเพื่อประมาณความเสี่ยงการขาดทุนก่อนที่จะเปิดใช้งานใหม่
• การสื่อสารที่โปร่งใส: เผยแพร่ไทม์ไลน์เหตุการณ์และเกณฑ์การเปิดใหม่ ความชัดเจนลดความตื่นตระหนกและบรรเทาการไหลออกของทุน

เมื่อเป็นไปได้ ให้ปรับการใช้งานของคุณให้สอดคล้องกับรูปแบบอ้างอิงที่ผ่านการตรวจสอบอย่างดีจาก protocol ที่เป็นที่ยอมรับ ตัวอย่างเช่น Open Price Feed ของ Compound นำเสนอรูปแบบการออกแบบสำหรับการอ่านและตรวจสอบราคาที่ลงนามแบบ off-chain ก่อนโพสต์บนเชน ดูรายละเอียดที่ repository ของโครงการ: Compound Open Oracle

การกำกับดูแลและการกำกับดูแลกฎหมายเข้ามาอยู่ที่ใด?

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

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

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

ข้อผิดพลาดทั่วไป

1. การพึ่งพา oracle เดียว: การพึ่งพา feed เดียวโดยไม่มี fallback เปลี่ยนปัญหาเล็กน้อยให้กลายเป็นการหยุดชะงักทั่วทั้ง protocol เพิ่มการตรวจสอบข้ามอิสระอย่างน้อยหนึ่งรายการ
2. การละเลยความเชื่อมั่นหรือความล้าสมัย: การถือว่าทุกราคามีความน่าเชื่อถือเท่ากันเชิญชวนการ liquidation ที่ไม่ยุติธรรม รวมหน้าต่างความถูกต้องและพารามิเตอร์ที่ตระหนักถึงความไม่แน่นอน
3. แหล่งที่มีความสัมพันธ์กัน: Feed สองตัวที่ดึงจาก venue ต้นน้ำเดียวกันไม่ได้ให้ความซ้ำซ้อนที่แท้จริง มุ่งเป้าหมายไปที่เส้นทางข้อมูลแบบ orthogonal
4. Pause hammer แบบทั่วไป: การหยุดฟังก์ชันทั้งหมดกักขังผู้ใช้และเพิ่มความเสี่ยง ต้องการการควบคุมแบบละเอียดที่อนุญาตให้ลดหนี้และชำระคืนได้
5. การตอบสนองต่อเหตุการณ์ที่ไม่ได้ฝึกซ้อม: Runbook ที่ไม่ได้ทดสอบคือ runbook ที่ไม่พร้อม ฝึกซ้อมบน fork และบันทึกเมตริกเพื่อการปรับปรุงอย่างต่อเนื่อง
6. การออกแบบที่มองไม่เห็น bridge: การถือว่า attestation ข้ามเชนเกิดขึ้นทันทีนำไปสู่การอ่านที่ล้าสมัย มอนิเตอร์อายุ relay และปรับเกณฑ์ต่อเชน

สำหรับการวิเคราะห์อย่างต่อเนื่องและคำอธิบายเชิงปฏิบัติเกี่ยวกับการออกแบบ oracle การบริหารความเสี่ยง และโครงสร้างตลาด DeFi ติดตาม Crypto Daily ที่ cryptodaily.co.uk

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

DEX TWAP เพียงพอที่จะแทนที่ oracle ภายนอกได้หรือไม่?

TWAP มีคุณค่าในฐานะการตรวจสอบความสมเหตุสมผลและสามารถทำหน้าที่เป็น fallback ชั่วคราวได้ แต่ไม่ใช่การแทนที่ที่ใช้ได้ทั่วไป TWAP อาจถูกจัดการในช่วงที่มีสภาพคล่องต่ำหรือหน้าต่างสั้น และอาจไม่สะท้อนราคา venue แบบ off-chain ที่สำคัญสำหรับการประเมินมูลค่าหลักประกัน การรวม TWAP กับ oracle ภายนอกและพารามิเตอร์แบบอนุรักษ์นิยมมักจะปลอดภัยกว่า

ความแตกต่างระหว่างเกณฑ์ deviation และ heartbeat คืออะไร?

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

Oracle แบบ optimistic อาจไม่ปลอดภัยในช่วงที่ราคาตกอย่างรวดเร็วหรือไม่?

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

Perp ข้ามเชนต้องการการตั้งค่า oracle ที่แตกต่างกันหรือไม่?

ใช่ เชนปลายทางมักประสบกับความล่าช้าของ relay และการรับประกัน finality ที่แตกต่างกัน ใช้เกณฑ์ความล้าสมัยที่เข้มงวดกว่า บัฟเฟอร์ความเชื่อมั่นที่กว้างขึ้น และ circuit breaker ที่ปรับแต่งตามโปรไฟล์ความหน่วงและความแออัดของแต่ละเชน

จะวัด "ความเป็นอิสระ" ระหว่าง oracle ได้อย่างไร?

จับแผนที่แหล่งที่มาและผู้เผยแพร่: ระบุตลาดแลกเปลี่ยน market maker, validator operator หรือ relayer ที่ใช้ร่วมกัน ตรวจสอบความสัมพันธ์ของการหยุดทำงานและข้อผิดพลาดด้านราคาเมื่อเวลาผ่านไป ความเป็นอิสระดีขึ้นเมื่อข้อมูล การขนส่ง และชุด signer ไม่ทับซ้อนกันอย่างมีนัยสำคัญ

ผู้ใช้ควรมองหาอะไรก่อนฝากเงินใน protocol?

ตรวจสอบว่า protocol แสดงรายการผู้ให้บริการ oracle เกณฑ์ความล้าสมัย และนโยบายการหยุดหรือไม่ มองหาการตั้งค่า multi-oracle, การตรวจสอบข้าม TWAP และรายงานเหตุการณ์ที่โปร่งใส หากเอกสารหายไป ให้ถือว่านั่นเป็นสัญญาณเตือน

มีมาตรฐานสำหรับการเปิดเผยความเสี่ยงของ oracle หรือไม่?

ไม่มีมาตรฐานเดียวที่ครอบงำ แต่หลายโครงการเผยแพร่กรอบความเสี่ยงและหมายเหตุการออกแบบ oracle ในเอกสารของตน อ้างอิงทรัพยากรทางการจากผู้ให้บริการอย่าง Chainlink, Pyth และ MakerDAO สำหรับแนวปฏิบัติพื้นฐาน และปรับให้เข้ากับความเสี่ยงที่ protocol ของคุณยอมรับได้

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