ผู้เขียนต้นฉบับ: เอเดรียน โชว
บริจาคโดย Jonathan Yuen และ Wintersoldier
สรุป:
● Oracle เป็นสิ่งที่ขาดไม่ได้ในการรับประกันมูลค่าที่ถูกล็อคของโปรโตคอล DeFi จากปริมาณ DeFi ที่ล็อคไว้ทั้งหมดจำนวน 5 หมื่นล้านดอลลาร์สหรัฐ มี oracles รับประกัน 33 พันล้าน
● อย่างไรก็ตาม การหน่วงเวลาโดยธรรมชาติในการอัปเดตฟีดราคาของ Oracle ส่งผลให้เกิดประเภทย่อยของการแยกค่าที่เรียกว่า Maximal Extractable Value (MEV) ซึ่งเรียกว่า Oracle Extractable Value (OEV) ; OEV รวมถึง oracle frontrunning, Arbitrage และการชำระบัญชีที่ไม่มีประสิทธิภาพ
● มีการใช้งานการออกแบบจำนวนมากขึ้นเพื่อป้องกันหรือบรรเทาการสูญเสีย OEV เชิงลบ โดยแต่ละแบบมีข้อด้อยเฉพาะตัวของตัวเอง บทความนี้จะกล่าวถึงตัวเลือกการออกแบบที่มีอยู่และข้อดีข้อเสีย ตลอดจนเสนอแนวคิดใหม่สองแนวคิด ข้อเสนอคุณค่า ปัญหาที่เปิดกว้าง และคอขวดของการพัฒนา
การแนะนำ
Oracle อาจกล่าวได้ว่าเป็นหนึ่งในโครงสร้างพื้นฐานที่สำคัญที่สุดใน DeFi ในปัจจุบัน สิ่งเหล่านี้เป็นส่วนสำคัญของโปรโตคอล DeFi ส่วนใหญ่ ซึ่งอาศัยฟีดราคาเพื่อชำระสัญญาอนุพันธ์ ปิดสถานะที่ต่ำกว่าหลักประกัน และอื่นๆ ปัจจุบัน oracles รับประกันมูลค่า 33 พันล้านดอลลาร์สหรัฐ ซึ่งคิดเป็นอย่างน้อยสองในสามของปริมาณที่ถูกล็อคไว้ทั้งหมด 50 พันล้านดอลลาร์สหรัฐในห่วงโซ่ 1 อย่างไรก็ตาม สำหรับนักพัฒนาแอปพลิเคชัน การเพิ่ม oracles นำมาซึ่งข้อดีข้อเสียและปัญหาด้านการออกแบบที่ชัดเจน ซึ่งมีสาเหตุมาจากการสูญเสียมูลค่าผ่านการดำเนินกิจการส่วนหน้า การเก็งกำไร และการชำระบัญชีที่ไม่มีประสิทธิภาพ บทความนี้จัดประเภทการสูญเสียมูลค่านี้เป็น Oracle Extractable Value (OEV) สรุปประเด็นสำคัญจากมุมมองของแอปพลิเคชัน และพยายามที่จะแสดงให้เห็นถึงการเพิ่ม OEV ลงในโปรโตคอล DeFi ที่ปลอดภัยและเชื่อถือได้โดยอิงจากการวิจัยในอุตสาหกรรม ข้อควรพิจารณาที่สำคัญสำหรับ Oracle
ค่าที่แยกได้ของออราเคิล (OEV)
ในส่วนนี้จะถือว่าผู้อ่านมีความเข้าใจพื้นฐานเกี่ยวกับฟังก์ชันการทำงานของ Oracle และความแตกต่างระหว่าง Oracle แบบพุชและแบบดึง ราคาฟีดสำหรับออราเคิลแต่ละรายการอาจแตกต่างกันไป ดูภาคผนวกสำหรับภาพรวม การจำแนกประเภท และคำจำกัดความ
แอปพลิเคชันส่วนใหญ่ที่ใช้ฟีดราคาของ oracle ต้องการเพียงการอ่านราคาเท่านั้น: การแลกเปลี่ยนแบบกระจายอำนาจที่ใช้โมเดลการกำหนดราคาของตัวเองนั้นใช้ฟีดราคาของออราเคิลเป็นราคาอ้างอิง การฝากหลักประกันสำหรับสถานะสินเชื่อที่มีหลักประกันมากเกินไปนั้นจำเป็นต้องมีการอ่านของออราเคิลเท่านั้น รับราคาเพื่อกำหนดพารามิเตอร์เริ่มต้น เช่น มูลค่าการยืม เทียบกับราคาปิด ยกเว้นกรณีที่รุนแรง เช่น สินทรัพย์หางยาวที่การอัปเดตราคาไม่บ่อยเกินไป โดยพื้นฐานแล้วความล่าช้าในการอัปเดตฟีดราคาของ oracle นั้นไม่สำคัญเมื่อพิจารณาการออกแบบระบบ ดังนั้น ข้อควรพิจารณาที่สำคัญที่สุดสำหรับ oracles คือ - ความถูกต้องของผู้ร่วมให้ข้อมูลราคา และประสิทธิภาพการกระจายอำนาจของผู้ให้บริการ oracle
แต่หากเวลาแฝงในการอัปเดตฟีดราคาเป็นข้อพิจารณาที่สำคัญ ควรให้ความสนใจมากขึ้นว่า oracle โต้ตอบกับแอปพลิเคชันอย่างไร โดยทั่วไปในกรณีนี้ ความล่าช้าดังกล่าวนำไปสู่โอกาสในการสกัดมูลค่า เช่น การดำเนินกิจการล่วงหน้า การเก็งกำไร และการชำระบัญชี ประเภทย่อยของ MEV นี้เรียกว่า OE V2 เราจะสรุปโครงร่างรูปแบบต่างๆ ของ OEV ก่อนที่จะหารือเกี่ยวกับการใช้งานต่างๆ และข้อดีข้อเสีย
การเก็งกำไร
Oracle front-running และการเก็งกำไรมักเรียกกันว่า กระแสที่เป็นพิษ ในโปรโตคอลอนุพันธ์เนื่องจากธุรกรรมเหล่านี้ดำเนินการภายใต้ความไม่สมดุลของข้อมูลและมักจะปราศจากความเสี่ยงโดยที่ผู้ให้บริการสภาพคล่องต้องเสียค่าใช้จ่าย โปรโตคอล OG DeFi เช่น Synthetix ประสบปัญหานี้มาตั้งแต่ปี 2018 และได้ลองใช้วิธีแก้ปัญหาต่างๆ เมื่อเวลาผ่านไปเพื่อลดผลกระทบภายนอกเชิงลบเหล่านี้
เราจะอธิบายด้วยตัวอย่างง่ายๆ โดย xyz การแลกเปลี่ยนแบบกระจายอำนาจตามสัญญาแบบถาวรใช้ Chainlink oracle ในตลาด ETH/USD ตัวอย่างนี้ใช้ฟีดราคา ETH/USD เพื่อแสดงให้เห็น:
รูปที่ 1: ตัวอย่างการเก็งกำไรโดยใช้ Chainlink oracles
แม้ว่าตัวอย่างข้างต้นเป็นตัวอย่างที่เรียบง่ายเกินไปซึ่งไม่ได้คำนึงถึงปัจจัยต่างๆ เช่น Slippage ค่าธรรมเนียม หรือเงินทุน แต่ก็แสดงให้เห็นโอกาสที่เกิดจากการขาดรายละเอียดราคาที่เกิดจากบทบาทของเกณฑ์การเบี่ยงเบน ผู้ค้นหาสามารถตรวจสอบเวลาแฝงของการอัปเดตราคาตลาดทันที และดึงมูลค่าความเสี่ยงเป็นศูนย์จากผู้ให้บริการสภาพคล่อง (LP) โดยอิงตามพื้นที่จัดเก็บข้อมูลออนไลน์ของ Chainlink
วิ่งหน้า
Front-runing คล้ายกับการเก็งกำไร เป็นอีกรูปแบบหนึ่งของการแยกมูลค่าที่ผู้ค้นหาตรวจสอบ mempool เพื่อดูการอัปเดตของ oracle และเรียกใช้ราคาตลาดจริงก่อนส่งมอบแบบออนไลน์ ด้วยวิธีนี้ ผู้ค้นหาจะมีเวลาในการเสนอราคาและซื้อขายก่อนที่ Oracle จะได้รับการอัปเดต และธุรกรรมจะเสร็จสิ้นในราคาที่เอื้ออำนวยต่อทิศทางการซื้อขายของพวกเขา
การแลกเปลี่ยนแบบกระจายอำนาจตามสัญญาแบบถาวร เช่น GMX ตกเป็นเหยื่อของ front-running ที่เป็นพิษมาโดยตลอด ก่อนที่ oracles ทั้งหมดใน GMX จะได้รับการอัปเดตผ่านโปรโตคอลการประสานงาน KeeperDAO ประมาณ 10% ของผลกำไรของโปรโตคอลจะสูญเสียไปให้กับ front-running 4
จะเป็นอย่างไรถ้าเราเลือกใช้โมเดลแบบดึง?
คุณค่าที่นำเสนออย่างหนึ่งของ Python คือการใช้ Python ที่ใช้สถาปัตยกรรม Solana ผู้เผยแพร่สามารถพุชการอัปเดตราคาไปยังเครือข่ายทุกๆ 300 มิลลิวินาที 5 ดังนั้นจึงรักษาฟีดราคาแฝงที่ต่ำไว้ ดังนั้น เมื่อแอปพลิเคชันสอบถามราคาผ่าน Application Programming Interface (API) ของ Pyth แอปพลิเคชันจะสามารถดึงราคาล่าสุด อัปเดตไปยังที่เก็บข้อมูลออนไลน์ของเครือข่ายเป้าหมาย และดำเนินการดาวน์สตรีมใดๆ ในตรรกะของแอปพลิเคชันในธุรกรรมเดียว
ดังที่กล่าวไว้ข้างต้น แอปพลิเคชันสามารถสืบค้น Python โดยตรงสำหรับการอัพเดตราคาล่าสุด อัปเดตที่เก็บข้อมูล on-chain และดำเนินการตรรกะที่เกี่ยวข้องทั้งหมดให้เสร็จสิ้นในธุรกรรมเดียว วิธีนี้ช่วยแก้ปัญหา front-running และการเก็งกำไรได้อย่างมีประสิทธิภาพหรือไม่
นั่นไม่ใช่ทั้งหมด - การอัปเดต Pyth ที่ให้ผู้ใช้สามารถเลือกราคาที่จะใช้ในการทำธุรกรรมอาจนำไปสู่การเลือกที่ไม่พึงประสงค์ (พิษร้ายอีกประการหนึ่ง) แม้ว่าราคาจะต้องถูกเก็บไว้บนเครือข่ายเมื่อเวลาผ่านไป ผู้ใช้ยังคงสามารถเลือกราคาใดๆ ที่ตรงตามข้อจำกัดเหล่านี้ได้ ซึ่งหมายความว่าการเก็งกำไรยังคงมีอยู่ เนื่องจากช่วยให้ผู้ค้นหาเห็นราคาในอนาคตก่อนที่จะใช้ราคาที่ผ่านมา เอกสารของ Pyth6 แนะนำว่าวิธีง่ายๆ ในการป้องกันเวกเตอร์การโจมตีนี้คือการเพิ่มการตรวจสอบความเก่าเพื่อให้แน่ใจว่าราคาล่าสุดเพียงพอ - อย่างไรก็ตาม จะต้องมีเวลาบัฟเฟอร์ที่แน่นอนก่อนที่จะอัปเดตข้อมูลธุรกรรมในบล็อกถัดไป เราจะตรวจสอบได้อย่างไร เกณฑ์เวลาที่เหมาะสมที่สุด?
ให้เรายกตัวอย่างการวิเคราะห์แบบกระจายอำนาจของสัญญาถาวร xyz คราวนี้พวกเขากำลังใช้ฟีดราคา Pyth ETH/USD และเวลาตรวจสอบการหมดอายุคือ 20 วินาที ซึ่งหมายความว่าการประทับเวลาของราคา Pyth จะต้องดำเนินการ ภายใน 20 วินาทีของการประทับเวลาบล็อกของธุรกรรมดาวน์สตรีม:
รูปที่ 2: กระบวนการตัวอย่างที่ทำงานส่วนหน้าโดยใช้ Pyth
แนวคิดตามสัญชาตญาณคือเพียงลดเกณฑ์การตรวจสอบการหมดอายุลง แต่เกณฑ์ที่ต่ำกว่าอาจนำไปสู่การตอบกลับของเครือข่ายที่คาดเดาไม่ได้ในเวลาบล็อก ซึ่งส่งผลต่อประสบการณ์ผู้ใช้ เนื่องจากฟีดราคาของ Pyth ขึ้นอยู่กับการเชื่อมโยง จึงจำเป็นต้องมีการบัฟเฟอร์ที่เพียงพอเพื่อ ก) ให้เวลาแก่ผู้พิทักษ์ Wormhole เพื่อพิสูจน์ราคา และ ข) อนุญาตให้ห่วงโซ่เป้าหมายประมวลผลธุรกรรมและรวมไว้ในบล็อก ข้อเสียเปรียบเหล่านี้มีรายละเอียดอยู่ในส่วนถัดไป
ปิดตำแหน่ง
การปิดสถานะเป็นส่วนสำคัญของข้อตกลงใดๆ ที่เกี่ยวข้องกับการใช้ประโยชน์ และรายละเอียดของการอัปเดตฟีดราคามีบทบาทสำคัญในการพิจารณาประสิทธิภาพของการปิดสถานะ
ในกรณีของ Push oracle ตามเกณฑ์ เมื่อราคาสปอตถึงเกณฑ์ แต่ไม่ตรงตามพารามิเตอร์ที่กำหนดไว้ล่วงหน้าของฟีดราคาของ Oracle รายละเอียด (หรือขาดรายละเอียด) ของการอัปเดตราคาจะส่งผลให้พลาดโอกาสที่จะ ปิดตำแหน่ง สิ่งนี้สร้างผลกระทบภายนอกเชิงลบในรูปแบบของความไร้ประสิทธิภาพของตลาด
เมื่อการชำระบัญชีเกิดขึ้น แอปพลิเคชันมักจะจ่ายส่วนหนึ่งของหลักประกันการชำระบัญชี และบางครั้งก็ให้รางวัลแก่ผู้ใช้ที่เริ่มการชำระบัญชี ตัวอย่างเช่น ในปี 2545 Aave จ่ายเงินรางวัลการชำระบัญชีบน mainnet เพียงอย่างเดียวจำนวน 37.9 ล้านดอลลาร์ 7 สิ่งนี้เป็นการชดเชยบุคคลที่สามมากเกินไปอย่างชัดเจน และสร้างประสิทธิภาพที่ไม่ดีให้กับผู้ใช้ นอกจากนี้ เมื่อมีมูลค่าที่สามารถแยกออกมาได้ Gas Wars ที่ตามมาจะทำให้มูลค่าหมดไปจากแอปพลิเคชัน และไหลไปสู่ห่วงโซ่อุปทาน MEV
พื้นที่การออกแบบและข้อควรพิจารณา
เมื่อพิจารณาถึงปัญหาข้างต้น วิธีแก้ปัญหาการใช้งานต่างๆ ที่อิงตามการออกแบบแบบผลัก การดึง และทางเลือกต่างๆ จะถูกกล่าวถึงด้านล่าง ซึ่งแต่ละวิธีมีประสิทธิภาพในการแก้ปัญหาข้างต้นและข้อเสียที่เกี่ยวข้อง การแลกเปลี่ยนสามารถอยู่ในรูปแบบของการรวมศูนย์เพิ่มเติม และเชื่อถือเงื่อนไขเบื้องต้น หรือประสบการณ์ผู้ใช้ที่ไม่ดี
Order Flow Auctions (OFA) สำหรับออราเคิลโดยเฉพาะ
การเสนอราคาตามขั้นตอนการสั่งซื้อ OFA กลายเป็นโซลูชันในการขจัดผลกระทบภายนอกเชิงลบที่เกิดจาก MEV พูดอย่างกว้างๆ OFA เป็นบริการเสนอราคาของบุคคลที่สามที่มีจุดประสงค์ทั่วไป ซึ่งผู้ใช้สามารถส่งคำสั่งซื้อให้ (การค้าขายหรือความตั้งใจ) และผู้ค้นหาที่แยก MEV สามารถเสนอราคาเพื่อรับสิทธิ์พิเศษในการดำเนินกลยุทธ์ตามคำสั่งซื้อของตนได้ รายได้จากการประมูลส่วนสำคัญจะถูกส่งกลับไปยังผู้ใช้เพื่อชดเชยมูลค่าที่พวกเขาสร้างขึ้นในคำสั่งซื้อเหล่านี้ อัตราการยอมรับ OFA เพิ่มขึ้นเมื่อเร็ว ๆ นี้ โดยมากกว่า 10% ของธุรกรรม Ethereum ดำเนินการผ่านช่องทางส่วนตัว (RPC/OFA ส่วนตัว) (รูปที่ 3) ซึ่งเชื่อว่าจะกระตุ้นการเติบโตต่อไป
รูปที่ 3: จำนวนธุรกรรม Ethereum ส่วนตัวรายวันรวม ที่มา: Blocknative
ปัญหาในการใช้ Universal OFA ในการอัปเดตของ Oracle คือ Oracle ไม่มีทางทราบได้ว่าการอัปเดตตามกฎมาตรฐานจะสร้าง OEV ใด ๆ หรือไม่ และหากไม่เป็นเช่นนั้น ก็จะทำให้เกิดความล่าช้าเพิ่มเติมเมื่อ Oracle ส่งธุรกรรมเข้าสู่การประมูล ในทางกลับกัน วิธีที่ง่ายที่สุดในการปรับปรุง OEV และลดเวลาแฝงให้เหลือน้อยที่สุด คือการป้อนโฟลว์ลำดับของ oracle ทั้งหมดให้กับผู้ค้นหาที่โดดเด่นเพียงรายเดียว แต่เห็นได้ชัดว่าสิ่งนี้นำมาซึ่งความเสี่ยงในการรวมศูนย์อย่างมาก อาจส่งเสริมพฤติกรรมการแสวงหาค่าเช่าและการเซ็นเซอร์ และนำไปสู่ประสบการณ์ผู้ใช้ที่ไม่ดี
รูปที่ 4: OFA ทั่วไปและ OFA เฉพาะของ Oracle
การอัปเดตราคาสำหรับ OFA เฉพาะของ Oracle ที่ไม่รวมการอัปเดตตามกฎที่มีอยู่จะยังคงทำใน Mempool สาธารณะ ซึ่งช่วยให้การอัปเดตราคาของ Oracle และค่าที่แยกได้ใดๆ ที่เป็นผลลัพธ์นั้น ยังคงอยู่ในเลเยอร์แอปพลิเคชัน เนื่องจากเป็นผลพลอยได้ มันยังเพิ่มความละเอียดของข้อมูลด้วยการอนุญาตให้ผู้ค้นหาร้องขอการอัปเดตแหล่งข้อมูล โดยไม่ต้องกำหนดให้โหนดของออราเคิลต้องรับผิดชอบค่าใช้จ่ายเพิ่มเติมของการอัพเดตบ่อยครั้งมากขึ้น
OFA เฉพาะของ Oracle เหมาะอย่างยิ่งสำหรับการชำระบัญชีสถานะ เนื่องจากสามารถนำการอัปเดตราคาที่ละเอียดมากขึ้น เพิ่มการคืนทุนสูงสุดให้กับผู้กู้ยืมที่มีการชำระสถานะ ลดรางวัลโปรโตคอลที่จ่ายให้กับผู้ชำระบัญชี และในโปรโตคอล ค่าที่ดึงมาจาก ผู้เสนอราคาจะยังคงอยู่ในผู้เสนอราคาเพื่อแจกจ่ายให้กับผู้ใช้ พวกเขายังแก้ปัญหาได้ในระดับหนึ่ง แม้ว่าจะไม่ใช่ทั้งหมดก็ตาม - ปัญหาของการดำเนินธุรกิจแนวหน้าและการเก็งกำไร ภายใต้การแข่งขันที่สมบูรณ์แบบและกระบวนการประมูลราคาที่ปิดผนึกราคาแรก ผลลัพธ์ของการประมูลควรเป็นต้นทุนพื้นที่บล็อกใกล้กับโอกาสในการดำเนินการ 8 ซึ่งแยกมาจากฟีดข้อมูล OEV ที่ดำเนินการอยู่แนวหน้า มูลค่า ตลอดจนการลดโอกาสในการเก็งกำไรที่เกิดจาก รายละเอียดราคาที่เพิ่มขึ้นของการอัปเดตฟีดราคา
ในปัจจุบัน การใช้ OFA เฉพาะของ Oracle จำเป็นต้องเข้าร่วมบริการเสนอราคาจากบุคคลที่สาม (เช่น OEV-Share) หรือสร้างบริการเสนอราคาโดยเป็นส่วนหนึ่งของแอปพลิเคชัน API 3 ได้รับแรงบันดาลใจจาก Flashbots โดยใช้รีเลย์ OEV (รูปที่ 5) เป็น API ที่ออกแบบมาเพื่อให้บริการป้องกัน DoS สำหรับการประมูล รีเลย์นี้มีหน้าที่รวบรวมธุรกรรมเมตาจาก Oracles รวบรวมและรวบรวมราคาเสนอของผู้ค้นหา และแจกจ่ายรายได้ในลักษณะที่ไม่น่าเชื่อถือโดยไม่ต้องควบคุมราคาเสนอ เมื่อผู้ค้นหาชนะการประมูล การอัปเดตแหล่งข้อมูลจะอาศัยการโอนจำนวนราคาเสนอไปยังสัญญาพร็อกซีที่โปรโตคอลเป็นเจ้าของเท่านั้น ซึ่งจะอัปเดตแหล่งที่มาของราคาด้วยข้อมูลที่ลงนามโดยผู้ส่งต่อ
รูปที่ 5: ตัวทวน OEV สำหรับ API 3
อีกทางหนึ่ง โปรโตคอลสามารถละทิ้งคนกลางและสร้างบริการประมูลของตนเองเพื่อรวบรวมมูลค่าที่ดึงมาจาก OEV ทั้งหมด BBOX เป็นหนึ่งในโปรโตคอลที่กำลังจะมีขึ้นซึ่งหวังว่าจะฝังการประมูลลงในกลไกการชำระบัญชีเพื่อจับ OEV และส่งคืนให้กับแอปพลิเคชันและผู้ใช้ 9
เรียกใช้โหนดกลางหรือ Keeper
แนวคิดแรกเริ่มที่เกิดจากระลอกแรกของการแลกเปลี่ยนแบบกระจายอำนาจตามสัญญาแบบถาวรเพื่อต่อสู้กับ OEV คือการใช้เครือข่าย Keeper แบบรวมศูนย์ (เครือข่ายผู้ดูแลประตู) เพื่อรวมราคาที่ได้รับจากแหล่งบุคคลที่สาม (เช่น การแลกเปลี่ยนแบบรวมศูนย์) จากนั้นใช้ประโยชน์จากฟีดข้อมูลเช่น Chainlink เป็น แผนฉุกเฉินหรือเบรกเกอร์ โมเดลนี้ได้รับความนิยมใน GMX v1 10 และทางแยกรุ่นต่อมาอีกมากมาย และคุณค่าหลักของมันคือ เนื่องจากเครือข่าย Keeper ดำเนินการโดยโอเปอเรเตอร์เพียงรายเดียว จึงได้รับการปกป้องอย่างแน่นอนจากการวิ่งหน้า
แม้ว่าวิธีนี้จะช่วยแก้ปัญหาหลายประการที่กล่าวมาข้างต้น แต่ก็ยังมีข้อกังวลเรื่องการรวมศูนย์ที่ชัดเจน ระบบ Keeper แบบรวมศูนย์สามารถกำหนดราคาดำเนินการได้โดยไม่ต้องตรวจสอบแหล่งที่มาของราคาและวิธีการรวบรวมอย่างเหมาะสม ในกรณีของ GMX v1 Keeper ไม่ใช่กลไกแบบออนไลน์หรือโปร่งใส แต่เป็นโปรแกรมที่ลงนามโดยที่อยู่ของทีมที่ทำงานบนเซิร์ฟเวอร์ส่วนกลาง บทบาทหลักของ Keeper ไม่เพียงแต่ในการดำเนินการตามคำสั่งเท่านั้น แต่ยังดำเนินการตามคำสั่งตามคำจำกัดความที่กำหนดไว้ล่วงหน้าด้วย"ตัดสินใจ"ราคาธุรกรรม ไม่มีวิธีตรวจสอบความถูกต้องหรือแหล่งที่มาของราคาดำเนินการที่ใช้
เครือข่าย Keeper อัตโนมัติและโฟลว์ข้อมูล Chainlink
วิธีแก้ปัญหาความเสี่ยงจากการรวมศูนย์ที่กล่าวมาข้างต้นที่เกิดจากเครือข่าย Keeper ที่มีผู้ดำเนินการเพียงรายเดียวคือการใช้ผู้ให้บริการบุคคลที่สามเพื่อสร้างเครือข่ายอัตโนมัติที่มีการกระจายอำนาจมากขึ้น Chainlink Automation เป็นหนึ่งในผลิตภัณฑ์ดังกล่าว และให้บริการนี้ร่วมกับ Chainlink Data Streams ซึ่งเป็นออราเคิลแบบดึงข้อมูลใหม่ที่มีความหน่วงต่ำ ผลิตภัณฑ์เพิ่งเปิดตัวและขณะนี้อยู่ในช่วงเบต้าแบบปิด แต่ GMX v2 11 ได้ใช้งานแล้ว และสามารถใช้เป็นข้อมูลอ้างอิงสำหรับระบบที่ใช้การออกแบบนี้ได้
ในระดับสูง กระแสข้อมูล Chainlink ประกอบด้วยสามส่วนหลัก: ข้อมูล DON (เครือข่ายออราเคิลแบบกระจายอำนาจ), DON อัตโนมัติ และสัญญาการตรวจสอบความถูกต้องแบบออนไลน์ 12 Data DON เป็นเครือข่ายข้อมูลนอกเครือข่ายที่มีสถาปัตยกรรมคล้ายกับวิธีที่ Python ดูแลรักษาและรวบรวมข้อมูล DON อัตโนมัติคือเครือข่ายผู้พิทักษ์ที่ได้รับการรักษาความปลอดภัยโดยผู้ดำเนินการโหนดเดียวกันกับ Data DON ซึ่งใช้ในการแยกราคาจาก Data DON แบบออนไลน์ สุดท้ายนี้ สัญญาเครื่องมือตรวจสอบความถูกต้องจะถูกนำมาใช้เพื่อตรวจสอบว่าลายเซ็นนอกเครือข่ายนั้นถูกต้อง
รูปที่ 6: สถาปัตยกรรมโฟลว์ข้อมูล Chainlink
รูปด้านบนแสดงกระบวนการธุรกรรมในการเรียกใช้ฟังก์ชันธุรกรรมที่เปิดอยู่ ซึ่ง DON อัตโนมัติมีหน้าที่รับราคาจากข้อมูล DON และอัปเดตที่เก็บข้อมูลออนไลน์ ปัจจุบัน ตำแหน่งข้อมูลสำหรับการสืบค้นข้อมูล DON โดยตรงถูกจำกัดไว้สำหรับผู้ใช้ที่อนุญาตพิเศษ ดังนั้นโปรโตคอลสามารถเลือกที่จะถ่ายโอนงานบำรุงรักษา Keeper ไปที่ Automation DON (Automation DON) หรือเรียกใช้ Keeper ของตัวเอง แต่เมื่อวงจรการพัฒนาผลิตภัณฑ์ดำเนินไป คาดว่าสิ่งนี้จะค่อยๆ เปลี่ยนไปเป็นโครงสร้างที่ไม่ได้รับอนุญาต
ในระดับความปลอดภัย สมมติฐานด้านความน่าเชื่อถือที่ใช้ DON อัตโนมัติจะเหมือนกับสมมติฐานสำหรับ DON ของข้อมูลเพียงอย่างเดียว ซึ่งเป็นการปรับปรุงที่สำคัญเหนือการออกแบบ Keeper เดียว อย่างไรก็ตาม หากมอบอำนาจในการอัปเดตฟีดราคาให้กับ DON อัตโนมัติ โอกาสในการแยกมูลค่าจะเหลือไว้เฉพาะโหนดในเครือข่าย Keeper เท่านั้น ในทางกลับกัน หมายความว่าโปรโตคอลจะไว้วางใจผู้ดำเนินการโหนด LinkToken (ส่วนใหญ่เป็นสถาบัน) เพื่อรักษาชื่อเสียงทางสังคมของตน และไม่ขัดขวางผู้ใช้จากการดำเนินงาน ซึ่งคล้ายกับการไว้วางใจผู้ดำเนินการโหนด Lido Node เพื่อรักษาชื่อเสียงของตน และไม่ให้มีส่วนแบ่งการตลาดขนาดใหญ่ และผูกขาดพื้นที่บล็อก
ดึง: การชำระบัญชีล่าช้า
หนึ่งในการเปลี่ยนแปลงที่ใหญ่ที่สุดใน Synthetix perps v2 คือการแนะนำฟีดราคา Python สำหรับการชำระสัญญาแบบไม่จำกัดระยะเวลา 13 ซึ่งช่วยให้สามารถชำระคำสั่งซื้อขายได้ที่ราคา Chainlink หรือ Pyth โดยที่ราคาจะต้องไม่เบี่ยงเบนเกินกว่าเกณฑ์ที่กำหนดไว้ล่วงหน้า และการประทับเวลาจะผ่านการตรวจสอบวันหมดอายุ อย่างไรก็ตาม ดังที่กล่าวไว้ข้างต้น การเปลี่ยนไปใช้ Oracle แบบดึงเพียงอย่างเดียวจะไม่สามารถแก้ปัญหาที่เกี่ยวข้องกับ OEV สำหรับโปรโตคอลทั้งหมดได้ เพื่อแก้ปัญหา front-running สามารถนำเสนอในรูปแบบของคำสั่งล่าช้าได้"ดูครั้งล่าสุด"กลไกการกำหนดราคา ในทางปฏิบัติจะแบ่งลำดับการตลาดของผู้ใช้ออกเป็นสองส่วน:
1. ธุรกรรม #1: ส่งคำสั่งตลาดบนเครือข่าย"เจตนา"และจัดเตรียมพารามิเตอร์การสั่งซื้อมาตรฐาน เช่น ขนาด เลเวอเรจ หลักประกัน และความทนทานต่อการเลื่อนหลุด ในเวลาเดียวกัน จะต้องเสียค่าธรรมเนียม Keeper เพิ่มเติมเพื่อให้รางวัล Keeper สำหรับการดำเนินการธุรกรรม #2
2. ธุรกรรม #2: Keeper ได้รับคำสั่งซื้อที่ส่งในธุรกรรม #1, ขอฟีดราคา Pyth ล่าสุด และเรียก Synthetix เพื่อดำเนินการตามสัญญาในธุรกรรมเดียว สัญญาจะตรวจสอบพารามิเตอร์ที่กำหนดไว้ล่วงหน้า เช่น ความทันเวลาและการเลื่อนหลุดของราคา หากผ่านทั้งคู่ คำสั่งซื้อจะถูกดำเนินการ การจัดเก็บราคาออนไลน์จะได้รับการอัปเดต และตำแหน่งจะถูกสร้างขึ้น ผู้ดูแลจะเรียกเก็บค่าธรรมเนียมเพื่อชดเชยก๊าซที่ใช้และบำรุงรักษาเครือข่าย
การใช้งานนี้ไม่ได้เปิดโอกาสให้ผู้ใช้เลือกราคาที่ส่งทางออนไลน์ในทางลบ ซึ่งช่วยแก้ไขโอกาสในการดำเนินการล่วงหน้าและการเก็งกำไรสำหรับโปรโตคอลได้อย่างมีประสิทธิภาพ อย่างไรก็ตาม ข้อดีข้อเสียของการออกแบบนี้คือประสบการณ์ของผู้ใช้: การดำเนินการ Market Order นี้ต้องใช้กระบวนการธุรกรรม 2 ขั้นตอน ผู้ใช้จำเป็นต้องชดเชยก๊าซสำหรับการดำเนินการ Keeper และแบ่งปันค่าใช้จ่ายในการอัปเดตพื้นที่เก็บข้อมูลบน Oracle Chain สิ่งที่เคยเป็นค่าธรรมเนียมคงที่ 2 sUSD เพิ่งถูกเปลี่ยนเป็นค่าธรรมเนียมแบบไดนามิกโดยอิงตาม Optimism gas oracle + พรีเมียม ซึ่งจะเปลี่ยนแปลงตามกิจกรรมเครือข่ายเลเยอร์ 2 ไม่ว่าในกรณีใด นี่ถือเป็นวิธีแก้ปัญหาในการปรับปรุงความสามารถในการทำกำไรของ LP โดยแลกกับประสบการณ์ผู้ใช้ของเทรดเดอร์
ประเภทการดึง: การชำระในแง่ดี
เนื่องจากคำสั่งซื้อที่ล่าช้าจะนำค่าธรรมเนียมเครือข่ายเพิ่มเติมมาสู่ผู้ใช้ (สัดส่วนกับค่าธรรมเนียม DA ของเครือข่ายชั้นที่สอง) หลังจากการระดมความคิด เราจึงได้เกิดรูปแบบการชำระเงินตามคำสั่งซื้ออื่นขึ้นมา ซึ่งเราเรียกว่า"การตั้งถิ่นฐานเชิงบวก"โมเดลนี้มีศักยภาพในการลดต้นทุนของผู้ใช้ในขณะที่ยังคงรักษาการกระจายอำนาจและความปลอดภัยของโปรโตคอล ตามชื่อที่แนะนำ กลไกนี้ช่วยให้เทรดเดอร์สามารถดำเนินการซื้อขายในตลาดแบบอะตอมมิก โดยระบบจะยอมรับราคาทั้งหมดอย่างแข็งขันและให้หน้าต่างสำหรับผู้ค้นหาในการส่งหลักฐานว่ามีการสั่งซื้อโดยมีเจตนาร้าย ส่วนนี้จะสรุปแนวคิดนี้ กระบวนการคิดของเรา และปัญหาที่ยังไม่ได้รับการแก้ไขในเวอร์ชันต่างๆ
แนวคิดเริ่มแรกของเราคือการสร้างกลไกที่จะอนุญาตให้ผู้ใช้สามารถส่งราคาผ่าน parsePriceFeedUpdates เมื่อเปิดคำสั่งซื้อของตลาด จากนั้นอนุญาตให้ผู้ใช้หรือบุคคลที่สามใดๆ ส่งธุรกรรมการชำระเงินโดยใช้ข้อมูลฟีดราคา และทำธุรกรรมให้เสร็จสิ้นในราคานั้นเมื่อ การทำธุรกรรมได้รับการยืนยันแล้ว ในการชำระบัญชี ความแตกต่างเชิงลบระหว่างราคาทั้งสองจะรวมอยู่ในงบกำไรขาดทุนของผู้ใช้เป็นค่าสลิปเพจ ข้อดีของแนวทางนี้ ได้แก่ การลดภาระต้นทุนสำหรับผู้ใช้และลดความเสี่ยงในการดำเนินการส่วนหน้า ผู้ใช้ไม่จำเป็นต้องแบกรับของพรีเมี่ยมที่ตอบแทนผู้พิทักษ์อีกต่อไป และเนื่องจากไม่ทราบราคาชำระเมื่อส่งคำสั่งซื้อ ความเสี่ยงของการวิ่งหน้าจึงยังคงสามารถจัดการได้ อย่างไรก็ตาม ขั้นตอนนี้ยังคงแนะนำกระบวนการชำระหนี้แบบสองขั้นตอน ซึ่งเป็นหนึ่งในข้อเสียที่เราพบในรูปแบบการชำระเงินแบบเลื่อนเวลาของ Synthetix ในกรณีส่วนใหญ่ หากความผันผวนระหว่างการวางคำสั่งซื้อและการชำระบัญชีไม่เกินเกณฑ์ front-run ที่ทำกำไรได้ตามที่ระบบกำหนด ธุรกรรมการชำระเงินเพิ่มเติมอาจไม่จำเป็น
วิธีแก้ปัญหาอื่นเพื่อหลีกเลี่ยงปัญหาข้างต้นคือการอนุญาตให้ระบบยอมรับคำสั่งซื้ออย่างแข็งขันจากนั้นเปิดช่วงท้าทายที่ไม่ได้รับอนุญาตในระหว่างที่สามารถส่งหลักฐานเพื่อพิสูจน์ว่าการเบี่ยงเบนราคาระหว่างการประทับเวลาของราคาและการประทับเวลาบล็อกได้รับอนุญาตให้ดำเนินการได้ ส่วนหน้าที่มีกำไร - กำลังดำเนินการข้อตกลง
การดำเนินการเฉพาะมีดังนี้:
1. ผู้ใช้สร้างคำสั่งซื้อตามราคาตลาดปัจจุบัน จากนั้นพวกเขาจะส่งราคาพร้อมกับข้อมูลไบต์ฟีดราคา Python ที่ฝังไว้เป็นธุรกรรมการสร้างคำสั่งซื้อ
2. สัญญาอัจฉริยะจะตรวจสอบและจัดเก็บข้อมูลนี้อย่างจริงจัง
3. หลังจากยืนยันคำสั่งซื้อในห่วงโซ่แล้ว จะมีช่วงท้าทายที่ผู้ค้นหาสามารถส่งหลักฐานการเลือกแบบย้อนกลับได้ หลักฐานนี้จะยืนยันว่าผู้ค้าใช้ข้อมูลฟีดราคาที่ล้าสมัยโดยมีจุดประสงค์เพื่อเก็งกำไรระบบ หากระบบยอมรับข้อพิสูจน์ ส่วนต่างจะถูกนำไปใช้กับราคาดำเนินการของเทรดเดอร์ในรูปของส่วนต่างของราคา และมูลค่าส่วนเกินจะมอบให้กับ Keeper เป็นรางวัล
4. หลังจากช่วงเวลาท้าทายสิ้นสุดลง ระบบจะถือว่าราคาทั้งหมดถูกต้อง
โมเดลนี้มีข้อดี 2 ประการ: ช่วยลดภาระต้นทุนสำหรับผู้ใช้ ผู้ใช้จะต้องชำระค่าธรรมเนียม gas สำหรับการสร้างคำสั่งซื้อและการอัปเดต oracle ในธุรกรรมเดียวกันเท่านั้น นอกจากนี้ยังป้องกันการวิ่งหน้า ปกป้องความสมบูรณ์ของแหล่งรวมสภาพคล่อง และรับประกันเครือข่าย Keeper ที่ดีพร้อมสิ่งจูงใจทางการเงินสำหรับการส่งหลักฐานไปยังระบบที่พิสูจน์การวิ่งหน้า
อย่างไรก็ตาม ยังมีปัญหาบางประการที่ต้องแก้ไขก่อนที่จะนำแนวคิดนี้ไปปฏิบัติจริง:
● คำจำกัดความ"การเลือกที่ไม่พึงประสงค์": ระบบจะแยกแยะระหว่างผู้ใช้ที่ส่งราคาที่หมดอายุเนื่องจากความล่าช้าของเครือข่าย และผู้ใช้ที่จงใจเก็งกำไรได้อย่างไร แนวคิดเริ่มแรกอาจเป็นการวัดความผันผวนภายในระยะเวลาตรวจสอบการหมดอายุ (เช่น 15 วินาที) และหากความผันผวนเกินค่าธรรมเนียมการดำเนินการสุทธิ คำสั่งดังกล่าวจะถูกทำเครื่องหมายว่าเป็นการหาประโยชน์ที่อาจเกิดขึ้น
● กำหนดช่วงเวลาท้าทายที่เหมาะสม: เมื่อพิจารณาว่ากระแสคำสั่งซื้อขายที่เป็นพิษอาจเปิดได้ในช่วงเวลาสั้นๆ เท่านั้น กรอบเวลาที่เหมาะสมสำหรับ Keeper ในการท้าทายราคาคืออะไร? การพิสูจน์อักษรเป็นชุดอาจมีความคุ้มทุนมากกว่า แต่เนื่องจากกระแสคำสั่งซื้อที่คาดเดาไม่ได้เมื่อเวลาผ่านไป จึงเป็นเรื่องยากที่จะกำหนดเวลาในการพิสูจน์อักษรเป็นชุดเพื่อให้แน่ใจว่าข้อมูลราคาทั้งหมดได้รับการพิสูจน์แล้วหรือมีเวลาเพียงพอที่จะถูกท้าทาย
● รางวัลทางเศรษฐกิจสำหรับผู้ดูแล: สำหรับการส่งหลักฐานที่สมเหตุสมผลสำหรับผู้ดูแลที่ได้รับสิ่งจูงใจทางการเงิน รางวัลที่เกี่ยวข้องกับการส่งหลักฐานที่ชนะจะต้องมากกว่าค่าน้ำมันที่เกี่ยวข้องกับการส่งหลักฐาน เนื่องจากขนาดการสั่งซื้อที่แตกต่างกัน สมมติฐานนี้อาจไม่รับประกัน
● จำเป็นต้องมีกลไกที่คล้ายกันในการปิดคำสั่งซื้อหรือไม่? หากเป็นเช่นนั้น ประสบการณ์ผู้ใช้จะด้อยลงอย่างไร
● ตรวจสอบให้แน่ใจว่าการเลื่อนหลุดที่ ไม่สมเหตุสมผล ไม่ตกอยู่กับผู้ใช้: ในกรณีที่เกิดข้อขัดข้องแบบฉับพลัน อาจมีความแตกต่างของราคาอย่างมากระหว่างการสร้างคำสั่งซื้อและการยืนยันออนไลน์ อาจจำเป็นต้องใช้ทางเลือกสำรองหรือเซอร์กิตเบรกเกอร์บางประเภท และพิจารณาใช้ราคา EMA ของ Pyth เพื่อให้มั่นใจถึงเสถียรภาพของฟีดราคาก่อนใช้งาน
โปรเซสเซอร์ร่วม ZK - การใช้ข้อมูลอีกรูปแบบหนึ่ง
อีกทิศทางหนึ่งที่ควรค่าแก่การสำรวจคือการใช้โปรเซสเซอร์เสริม ZK ซึ่งได้รับการออกแบบมาเพื่อรับสถานะ on-chain เพื่อทำการคำนวณที่ซับซ้อนแบบ off-chain และในขณะเดียวกันก็แสดงหลักฐานว่าดำเนินการคำนวณอย่างไร วิธีนี้สามารถใช้ได้โดยไม่ได้รับอนุญาต ตรวจสอบ. โปรเจ็กต์ต่างๆ เช่น Axiom ช่วยให้สัญญาสามารถสืบค้นข้อมูลบล็อกเชนในอดีต ทำการคำนวณนอกเครือข่าย และส่งข้อพิสูจน์ ZK เพื่อพิสูจน์ว่าผลการคำนวณได้รับการคำนวณอย่างถูกต้องตามข้อมูลออนไลน์ที่ถูกต้อง โปรเซสเซอร์รองเปิดโอกาสให้สร้าง TWAP oracles แบบกำหนดเองพร้อมความยืดหยุ่นในการควบคุมโดยใช้ราคาในอดีตจากแหล่งสภาพคล่องดั้งเดิมของ DeFi หลายแห่ง (เช่น Uniswap + Curve)
เมื่อเปรียบเทียบกับ oracles แบบดั้งเดิมที่ปัจจุบันเข้าถึงได้เฉพาะข้อมูลราคาสินทรัพย์ล่าสุดเท่านั้น ตัวประมวลผลเสริม ZK จะขยายช่วงของข้อมูลที่ให้กับ dApps ในลักษณะที่ปลอดภัย (Pyth จะให้ราคา EMA สำหรับนักพัฒนาเพื่อใช้เป็นการตรวจสอบอ้างอิงสำหรับข้อมูลล่าสุด ราคา) ด้วยวิธีนี้ แอปพลิเคชันสามารถแนะนำตรรกะทางธุรกิจเพิ่มเติมที่ทำงานร่วมกับข้อมูลบล็อกเชนในอดีต เพื่อปรับปรุงความปลอดภัยของโปรโตคอลหรือปรับปรุงประสบการณ์ผู้ใช้
อย่างไรก็ตาม โปรเซสเซอร์เสริม ZK ยังอยู่ในช่วงเริ่มต้นของการพัฒนา และยังมีปัญหาคอขวดอยู่บ้าง เช่น:
● ในสภาพแวดล้อมตัวประมวลผลเสริม การได้มาและการคำนวณข้อมูลบล็อกเชนจำนวนมากอาจต้องใช้เวลาพิสูจน์นาน
● การให้ข้อมูลบล็อคเชนเพียงอย่างเดียวไม่ได้ตอบสนองความต้องการการสื่อสารที่ปลอดภัยกับแอปพลิเคชันที่ไม่ใช่ Web3
โซลูชันที่ไม่ใช้ Oracle – อนาคตของ DeFi?
อีกวิธีหนึ่งในการแก้ปัญหานี้คือ ขจัดความจำเป็นในการป้อนราคาภายนอกโดยการออกแบบแบบดั้งเดิมตั้งแต่ต้น ดังนั้น
การแก้ปัญหาการพึ่งพา Oracle ของ DeFi การพัฒนาล่าสุดในด้านนี้คือการใช้โทเค็น AMM LP ต่างๆ เป็นวิธีการกำหนดราคา แนวคิดหลักคือ ตำแหน่ง LP ของผู้ดูแลสภาพคล่องที่มีฟังก์ชันคงที่คือโทเค็นที่แสดงถึงน้ำหนักที่กำหนดไว้ล่วงหน้าของสินทรัพย์สองรายการ และมีโทเค็นสองรายการ สูตรการกำหนดราคาอัตโนมัติ (เช่น xy=k) ด้วยการใช้ประโยชน์จากโทเค็น LP (เป็นหลักประกัน เกณฑ์การกู้ยืม หรือในกรณีการใช้งานล่าสุด เพื่อย้ายตำแหน่ง v3 LP ไปยังจุดทำเครื่องหมายที่แตกต่างกัน) โปรโตคอลสามารถรับข้อมูลที่ปกติจะได้รับจาก oracles เป็นผลให้เกิดคลื่นลูกใหม่ของโซลูชันแบบไร้ Oracle ที่ปราศจากความท้าทายข้างต้น ตัวอย่างการใช้งานตามทิศทางนี้ได้แก่:
Panoptic กำลังสร้างโปรโตคอลออปชั่นแบบถาวรที่ไม่ใช้ออราเคิล โดยใช้ประโยชน์จากสถานะสภาพคล่องแบบรวมศูนย์ของ Uniswap v3 เนื่องจากตำแหน่งสภาพคล่องแบบรวมศูนย์จะถูกแปลงเป็นสินทรัพย์อ้างอิง 100% เมื่อราคาสปอตเกินขีดจำกัดบนของตำแหน่ง LP ผลตอบแทนที่ให้แก่ผู้ให้บริการสภาพคล่องจะคล้ายคลึงกับผลตอบแทนที่ผู้ขายของออปชันขายเป็นอย่างมาก ดังนั้น ตลาดออปชั่นทำงานโดยผู้ให้บริการสภาพคล่องฝากสินทรัพย์หรือตำแหน่ง LP และผู้ซื้อและผู้ขายออปชั่นยืมสภาพคล่องและย้ายเข้าหรือออกจากช่วง ดังนั้นจึงสร้างผลตอบแทนออปชั่นแบบไดนามิก เนื่องจากเงินกู้อยู่ในตำแหน่ง LP จึงไม่จำเป็นต้องมี oracle ในการชำระหนี้
Infinity Pools ใช้ประโยชน์จากตำแหน่งสภาพคล่องแบบรวมศูนย์ของ Uniswap v3 เพื่อสร้างแพลตฟอร์มการซื้อขายแบบมีเลเวอเรจ โดยไม่มีการชำระบัญชีและไม่มี oracles ผู้ให้บริการสภาพคล่องของ Uniswap v3 สามารถให้ยืมโทเค็น LP ของตนได้ และเทรดเดอร์ก็ฝากหลักประกันบางส่วน ยืมโทเค็น LP และแลกสินทรัพย์ที่เกี่ยวข้องกับการซื้อขายตามทิศทางของพวกเขา เงินกู้ยืมที่ไถ่ถอนจะกำหนดเป็นสินทรัพย์หรือสินทรัพย์ที่เสนอราคา ขึ้นอยู่กับราคาที่ไถ่ถอน และสามารถคำนวณได้โดยตรงโดยการตรวจสอบองค์ประกอบ LP บน Uniswap ซึ่งช่วยลดการพึ่งพา oracles
Timeswap กำลังสร้างแพลตฟอร์มการให้ยืมแบบมีระยะเวลาคงที่ ไม่มีสภาพคล่อง และไม่มีออราเคิล เป็นตลาดที่มีบุคคลที่สามซึ่งประกอบด้วยผู้ให้กู้ ผู้กู้ยืม และผู้ให้บริการสภาพคล่อง ต่างจากตลาดการให้กู้ยืมแบบดั้งเดิมที่ใช้"พื้นฐานเวลา"(ตามเวลา) การชำระบัญชีมากกว่า"พื้นฐานราคา"(ตามราคา) การปิดสถานะ ในการแลกเปลี่ยนแบบกระจายอำนาจ ผู้ให้บริการสภาพคล่องจะถูกตั้งค่าโดยอัตโนมัติให้ซื้อจากผู้ขายและขายให้กับผู้ซื้อเสมอ ในขณะที่อยู่ใน Timeswap ผู้ให้บริการสภาพคล่องจะให้ยืมแก่ผู้ยืมและยืมจากผู้ให้กู้ในตลาดเสมอ มีบทบาทที่คล้ายกัน พวกเขายังต้องรับผิดชอบต่อการผิดนัดชำระหนี้และมีลำดับความสำคัญในการรับหลักประกันที่ถูกริบไปเป็นค่าชดเชย
สรุปแล้ว
ข้อมูลราคายังคงเป็นส่วนสำคัญของแอปพลิเคชันที่มีการกระจายอำนาจจำนวนมาก และมูลค่ารวมที่ได้รับจาก Oracle ยังคงเพิ่มขึ้นอย่างต่อเนื่องเมื่อเวลาผ่านไป ซึ่งเป็นการยืนยันถึงความเหมาะสมของตลาดผลิตภัณฑ์ (p ความเหมาะสมกับตลาดผลิตภัณฑ์) วัตถุประสงค์ของบทความนี้คือการแจ้งให้ผู้อ่านทราบและให้ภาพรวมของความท้าทายที่เกี่ยวข้องกับ OEV ที่เราเผชิญอยู่ รวมถึงพื้นที่การออกแบบในการใช้งานโดยยึดตามการผลัก การดึง และการออกแบบอื่น ๆ โดยใช้ผู้ให้บริการสภาพคล่อง AMM หรือตัวช่วยนอกเครือข่าย โปรเซสเซอร์
เรารู้สึกตื่นเต้นที่ได้เห็นนักพัฒนาที่กระตือรือร้นมองหาวิธีแก้ปัญหาการออกแบบที่ยากลำบากเหล่านี้ หากคุณกำลังทำงานในโครงการก่อกวนในพื้นที่นี้ เรายินดีรับฟังจากคุณ!
การอ้างอิงและการรับทราบ
ขอขอบคุณ Jonathan Yuen และ Wintersoldier สำหรับการมีส่วนร่วมและการสนทนา ซึ่งมีส่วนอย่างมากต่อบทความนี้
ขอขอบคุณ Erik Lie, Richard Yuen (Hailstone), Marc, Mario Bernardi, Anirudh Suresh (Pyth), Ugur Mersin (API 3 DAO) และ Mimi (Timeswap) สำหรับความคิดเห็น ข้อเสนอแนะ และบทวิจารณ์อันมีค่าของพวกเขา
1.https://defillama.com/oracles( 14 Nov)
2. OEV Litepaper https://drive.google.com/file/d/ 1 wuSWSI 8 WY 9 ChChu 2 hvRgByJSyQlv_ 8 SO /edit
3.Frontrunning on Synthetix: A History by Kain Warwick https://blog.synthetix.io/frontrunning-synthetix-a-history/
5. https://docs.pyth.network/documentation/pythnet-price-feeds/on-demand
6. https://docs.pyth.network/documentation/solana-price-feeds/best-practices#latency
7.Aave liquidation figures https://dune.com/queries/3247324
8.https://drive.google.com/file/d/ 1 wuSWSI 8 WY 9 ChChu 2 hvRgByJSyQlv_ 8 SO /edit
9.https://twitter.com/bboexchange/status/1726801832784318563
10.https://gmx-io.notion.site/gmx-io/GMX-Technical-Overview-47fc5ed832e243afb9e97e8a4a036353
11. https://gmxio.substack.com/p/gmx-v2-powered-by-chainlink-data
12. https://docs.chain.link/data-streams
13.https://sips.synthetix.io/sips/sip-281/
ภาคผนวก
คำจำกัดความ: ออราเคิลแบบผลักและแบบดึง
เครื่อง Push Oracle จะรักษาราคานอกเครือข่ายในเครือข่าย P2P และรักษาการอัปเดตราคาตามโหนดบนเครือข่ายที่กำหนดไว้ล่วงหน้า จากตัวอย่าง Chainlink การอัปเดตราคาจะขึ้นอยู่กับพารามิเตอร์ทริกเกอร์สองตัว: ค่าเบี่ยงเบน (เกณฑ์ค่าเบี่ยงเบน) และการเต้นของหัวใจ (การเต้นของหัวใจ) ฟีดราคา Ethereum ETH/USD ด้านล่างจะได้รับการอัปเดตเมื่อใดก็ตามที่ราคานอกเครือข่ายเบี่ยงเบน 0.5% จากราคาออนไลน์ล่าสุด หรือตัวจับเวลาการเต้นของหัวใจ 1 ชั่วโมงถึงศูนย์
ในกรณีนี้ ผู้ดำเนินการของ Oracle จะต้องชำระค่าธรรมเนียมธุรกรรมสำหรับการอัปเดตราคาแต่ละครั้ง ซึ่งเป็นการแลกเปลี่ยนระหว่างต้นทุนและความสามารถในการขยายขนาด การเพิ่มจำนวนแหล่งที่มาของราคา การรองรับบล็อกเชนเพิ่มเติม หรือการเพิ่มการอัปเดตบ่อยครั้งมากขึ้น จะทำให้เกิดต้นทุนการทำธุรกรรมเพิ่มเติม ดังนั้นสินทรัพย์หางยาวที่มีพารามิเตอร์ทริกเกอร์ที่สูงกว่าย่อมมีแหล่งที่มาของราคาที่มีความน่าเชื่อถือต่ำอย่างหลีกเลี่ยงไม่ได้ ลองใช้ CRV/USD เป็นตัวอย่างเพื่ออธิบายสิ่งนี้ - เพื่อให้ราคาใหม่ได้รับการอัปเดตบนห่วงโซ่ จำเป็นต้องมีเกณฑ์ส่วนเบี่ยงเบน 1% โดยมีฮาร์ทบีทเป็น 24 ชั่วโมง ซึ่งหมายความว่าหากราคาไม่เบี่ยงเบนไป มากกว่า 1% ภายใน 24 ชั่วโมง จากนั้นจะมีการอัพเดตราคาใหม่เพียง 1 รายการทุกๆ 24 ชั่วโมง การขาดรายละเอียดในแหล่งที่มาของราคาสำหรับสินทรัพย์หางยาวย่อมส่งผลให้แอปพลิเคชันจำเป็นต้องพิจารณาปัจจัยเสี่ยงเพิ่มเติมเมื่อสร้างตลาดสำหรับสินทรัพย์เหล่านี้ ซึ่งจะอธิบายว่าทำไมกิจกรรม DeFi ส่วนใหญ่ยังคงวนเวียนอยู่กับสินทรัพย์ที่มีสภาพคล่องมากที่สุด ด้วยโทเค็นมูลค่าตลาดที่แข็งแกร่งและใหญ่ที่สุด
ในทางตรงกันข้าม Pull oracles อนุญาตให้ดึงราคาเข้าสู่ห่วงโซ่ได้ตามความต้องการ Pyth เป็นตัวอย่างที่โดดเด่นที่สุดในปัจจุบัน โดยการส่งการอัปเดตราคาแบบออฟไลน์ การลงนามการอัปเดตแต่ละครั้งเพื่อให้ทุกคนสามารถตรวจสอบความถูกต้องได้ และการรักษาราคารวมบน Pythnet ซึ่งเป็นบล็อกส่วนตัวที่อิงตามสายโซ่รหัส Solana เมื่อจำเป็นต้องมีการอัปเดต ข้อมูลจะถูกถ่ายโอนผ่าน Wormhole ตรวจสอบบน Python จากนั้นจึงดึงเข้าสู่ห่วงโซ่โดยไม่ได้รับอนุญาต
รูปด้านบนอธิบายโครงสร้างของฟีดราคา Pyth: เมื่อจำเป็นต้องอัปเดตราคาใน chain ผู้ใช้สามารถขออัปเดตผ่าน Pyth API ราคาที่ตรวจสอบแล้วบน Pythnet จะถูกส่งไปยังสัญญา Wormhole สัญญา Wormhole จะ สังเกต สร้าง และส่งชื่อสถานที่ VAA ซึ่งสามารถตรวจสอบได้บนบล็อกเชนใดๆ ที่มีการปรับใช้สัญญา Pyth
IOS
Android