วิธีแก้ไขปัญหา Oracle MEV (OEV) โดยใช้กลไกตลาด

หมายเหตุ: ข้อความต้นฉบับรวบรวมจากทวีตมากกว่า 2,000 คำบน Twitter อย่างเป็นทางการของ Geek web3 เกี่ยวกับปัญหา OEV และวิธีแก้ไข เนื่องจากหัวข้อนี้น่าสนใจเป็นพิเศษ เราจึงได้รวบรวมเป็นบทความสั้น ๆ เพื่อใช้อ้างอิง

OEV คืออะไร (Oracle MEV)

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

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

เป็นที่เชื่อกันโดยทั่วไปว่าการสร้างและการแยก OEV เป็นส่วนย่อยของปัญหา MEV เราจะแนะนำวิธีสร้าง OEV สั้นๆ ในที่นี้ สาเหตุหลักอยู่ในสองประเด็นต่อไปนี้:

1. ระบบ DeFi ใช้ oracles เพื่อรับราคาและดำเนินการชำระบัญชีและตรรกะอื่น ๆ ตามราคาของ oracle และการชำระบัญชีสินทรัพย์มักบ่งชี้ว่ามีอัตรากำไรสูง

2. มีปัญหาที่ละเอียดในการอัพเดต Oracle เฉพาะเมื่อมีการเบี่ยงเบนบางอย่างระหว่างราคานอกเครือข่ายและราคาออนไลน์ ข้อมูลบนเครือข่ายจะได้รับการอัปเดต ซึ่งจะแสดงในรูปแบบของธุรกรรม

การสร้าง OEV หมายถึงการสูญเสียมูลค่าของผู้ให้บริการสภาพคล่อง ข้อมูลบางส่วนแสดงให้เห็นว่าจากสองประเด็นข้างต้น สามารถสร้าง OEV ได้สามวิธี:

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

Arbitrage: เนื่องจากการอัพเดตราคา on-chain ของเครื่อง oracle ขึ้นอยู่กับความแตกต่างระหว่างราคา on-chain และราคา off-chain ซึ่งหมายความว่าใบเสนอราคาเครื่อง oracle อาจไม่สอดคล้องกับใบเสนอราคาของระบบอื่น ๆ และพื้นที่การเก็งกำไร จะเกิดขึ้นในเวลานี้

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

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

กระบวนการสกัด OEV ถือเป็นขั้นตอนสำคัญ

สำหรับการดึงข้อมูล OEV ผู้ค้นหาจะตรวจสอบ “คำแนะนำในการอัปเดตข้อมูลของ Oracle” ในพูลหน่วยความจำ รวมชุดคำสั่งธุรกรรมการอัปเดตข้อมูลของ Oracle เข้ากับคำสั่งธุรกรรมที่เริ่มต้นโดยพวกเขาผ่านโครงสร้างพื้นฐาน MEV และดำเนินการตามขั้นตอนสุดท้ายเพื่อให้ได้ผลกำไร

แน่นอนว่าสำหรับการเก็งกำไรและการเคลียร์ธุรกรรม ผู้ค้นหาจะต้องตรวจสอบความเบี่ยงเบนระหว่างราคา on-chain และราคา off-chain และสุดท้ายให้แน่ใจว่าธุรกรรมที่พวกเขาเริ่มต้นนั้นดำเนินการบนลูกโซ่ก่อนผ่านโครงสร้างพื้นฐาน MEV

ไม่ว่าผู้ค้นหาจะใช้กระบวนการใดก็ตาม เราจะเห็นว่าประโยชน์ของ OEV มีการกระจายระหว่างโครงสร้างพื้นฐาน MEV และผู้ค้นหา OEV และโปรโตคอลที่ "บันทึก" ค่า OEV จะไม่ได้รับผลประโยชน์ที่สมควรได้รับ (จากข้อมูลบางส่วน ปัญหา OEV ทำให้กำไรของแพลตฟอร์ม GMX หายไปเกือบ 10% ก่อนหน้านี้)

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

ในเรื่องนี้ GMX ได้แนะนำ Rook และ whitelist พูดง่ายๆ ก็คือ การอัปเดต Oracle ของ GMX จะดำเนินการผ่าน Rook และ Rook จะดำเนินการแยก OEV ตามสภาวะตลาดในปัจจุบันเพื่อรับ OEV ในตลาด 80% ของ OEV เหล่านี้จะถูกส่งกลับไปยังโปรโตคอล GMX

โดยสรุป GMX ให้สิทธิ์ Rooks ในการอัปเดต oracle ผ่านรายการที่อนุญาต แยก OEV ผ่าน Rook เพื่อหลีกเลี่ยงไม่ให้ผู้ค้นหารายอื่นแยกออกมา และในขณะเดียวกันก็ส่งคืน 80% ของ OEV ไปยังระบบ GMX กิจวัตรนี้จริงๆ แล้วค่อนข้างเรียบง่ายและหยาบคาย

กลไกการประมูล OEV ตามการประมูลของตลาด

ก่อนที่จะแนะนำโครงการประมูล OEV ที่เสนอโดย API3 ซึ่งมีการพูดคุยกันอย่างมากในช่วงไม่กี่วันที่ผ่านมา เราจะแนะนำหลักการทำงานของเครื่อง Oracle ของ API3 อย่างคร่าวๆ ก่อน แกนหลักของ API3 เรียกว่าโปรโตคอล Airnode โปรโตคอลนี้อนุญาตให้ผู้ให้บริการ API จัดทำแพ็กเกจ Web2 API ของตนลงใน Oracle ของ Web3 ได้โดยตรง

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

สำหรับผู้ให้บริการ API การบรรจุบริการ Web2 API ของตนเป็น blockchain oracles จริงๆ แล้วต้องการเพียงแค่เพิ่มลิงก์ลายเซ็นคีย์ส่วนตัวเท่านั้น โครงสร้างพื้นฐานของผู้ให้บริการ API จำนวนมากสามารถนำมาใช้ซ้ำได้โดยตรง ซึ่งช่วยลดเกณฑ์สำหรับธุรกิจ API ในการเข้าสู่สาขาเครื่อง Oracle ได้อย่างมาก

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

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

การมีอยู่ของ OEV Relay นำมาซึ่งข้อดีสองประการต่อไปนี้:

1. ให้ข้อมูลทั้งหมดแก่ผู้ค้นหาในลักษณะที่เป็นหนึ่งเดียว และลดจำนวนผู้ค้นหาที่โต้ตอบกับโหนด oracle เพียงอย่างเดียว

2. ปกป้องโหนด oracle เดียวในเครือข่ายและป้องกันไม่ให้โหนด oracle เดียวถูกโจมตีโดยการโจมตี DoS ที่ดำเนินการโดยผู้ค้นหา

ผู้ค้นหาสามารถรับข้อมูลใบเสนอราคารวมของ Oracle Network และลายเซ็นภายใน OEV Relay เมื่อผู้ค้นหาเชื่อว่าใบเสนอราคาปัจจุบันของเครือข่ายออราเคิลสามารถช่วยพวกเขาดำเนินการสกัด OEV บางอย่างได้สำเร็จ ผู้ค้นหาจะเริ่มการประมูลไปยัง OEV Relay

ในระหว่างขั้นตอนการเสนอราคา หากผู้ค้นหาให้ราคาเสนอสูงสุด OEV Relay จะส่งคืน meta-tx ที่ได้รับการลงนามและสามารถอัปโหลดไปยังเชนโดยตรงเพื่ออัพเดตราคาของเครื่อง oracle บนเชนได้ ผู้ค้นหาสามารถรวมธุรกรรมการอัปเดตราคานี้เข้ากับธุรกรรมอื่น ๆ บนเครือข่ายและดำเนินการเพื่อรับรายได้ OEV ในขณะนี้ เนื่องจากธุรกรรมการอัพเดตราคาถูกบรรจุไว้ในเชนด้วย ราคาของ oracle บนเชนก็จะถูกอัพเดตด้วย

เราจะเห็นได้ว่าผลกระทบประการหนึ่งของการสนับสนุนการประมูล OEV คือการบรรลุการอัพเดตราคา oracle ออนไลน์ที่มีความถี่สูง ยกตัวอย่างแหล่งข้อมูล AAPL/USD ก่อนที่จะมีการประมูล OEV เมื่อราคานอกเครือข่ายและออนไลน์เบี่ยงเบนไป 1% ส่วนเบี่ยงเบนขนาดใหญ่นี้จะทำให้ Oracle อัปเดตราคาออนไลน์อย่างแข็งขัน

แต่หากเครื่องของ Oracle อนุญาตให้โลกภายนอกส่งคำแนะนำในการอัปเดตข้อมูลหลังจากเปิดการประมูล OEV ผู้ค้นหาอาจคิดว่าส่วนต่างของราคา 0.1% ระหว่างราคา on-chain และ off-chain สามารถนำมาซึ่งผลประโยชน์ OEV มหาศาล สิ่งนี้จะกระตุ้นให้ผู้ค้นหาใช้ meta-tx เพื่ออัปเดตราคาเมื่อราคาต่างกัน 0.1% และอัปโหลดคำสั่งซื้อธุรกรรมไปยังเชน

สิ่งนี้จะเร่งความเร็วการอัปเดตแหล่งข้อมูล AAPL/USD โดยไม่ต้องเสียค่าใช้จ่ายในการอัปเดต Oracle เพิ่มเติมสำหรับแอปพลิเคชันที่ใช้ Oracle นี้

ดังนั้น ค่าใช้จ่ายในการอัปเดตข้อมูล Oracle จะถูกส่งต่อไปยังผู้เก็บค่า OEV และรีเลย์ OEV ของ API3 สามารถรับค่าธรรมเนียมการประมูลจำนวนมากจากผู้เล่น OEV จากนั้นป้อนค่าธรรมเนียมเหล่านี้กลับไปยังโปรโตคอล Defi ที่เก็บค่า OEV

เป็นที่คาดการณ์ได้ว่าเมื่อตลาด OEV ขยายตัว ผู้ค้นหาจะแข่งขันกันอย่างดุเดือดในราคาประมูล ส่งผลให้มูลค่า OEV ส่วนใหญ่ (แม้แต่ 95%) ถูกโอนไปยังโปรโตคอล API3 หลังจากที่โปรโตคอล API3 ได้รับรายได้ OEV ส่วนนี้แล้ว โปรโตคอลจะแยกแหล่งที่มาของค่า OEV และส่งคืนไปยังโปรโตคอล Defi ที่ซึ่งค่า OEV ถูกจับ

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

สรุป

API3 ได้พัฒนาโซลูชันการประมูล OEV โดยใช้โปรโตคอล Airnode และได้รับแรงบันดาลใจจาก Flashbot ซึ่งมีข้อดีดังต่อไปนี้:

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

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

ข้อสงวนสิทธิ์：

1. บทความนี้พิมพ์ซ้ำจาก [PANews] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Geek Web3] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว