เมื่อเร็วๆ นี้ API 3 ได้รับเงินทุนเชิงกลยุทธ์มูลค่า 4 ล้านเหรียญสหรัฐ ซึ่งนำโดย DWF Labs โดยมีส่วนร่วมจาก VC ที่มีชื่อเสียงหลายราย เป็นเวลานานแล้วที่เส้นทาง Oracle ถูกครอบงำโดยสามฝ่ายที่ Chainlink เป็นตัวแทน สิบสี่ก็ประหลาดใจเช่นกันเมื่อเห็นข่าวนี้ ~ ทำไม API 3 ถึงสามารถรับเงินทุนได้? เขาจะเป็นผู้ขัดขวางคำทำนายแบบดั้งเดิมหรือไม่? อะไรทำให้เขามีเอกลักษณ์เฉพาะตัว? API 3 ซึ่งเป็นโปรเจ็กต์ API แบบกระจายอำนาจ (dAPI) ถูกกำหนดให้เป็นออราเคิล บุคคลที่หนึ่ง ผ่านเครือข่าย OEV ที่ล้ำสมัยและล้ำสมัย (อิงจาก ZK-Rollup) ช่วยแก้ปัญหาของคนกลางของออราเคิล บุคคลที่สาม ความโปร่งใสของข้อมูลอยู่ในระดับต่ำ และ OEV (Oracle Extractable Value) เป็นปัญหาที่พบบ่อย
1. พยากรณ์ทำนายอนาคตได้จริงหรือ?
คำว่า ออราเคิล ค่อนข้างเป็นตำนานและอาจทำให้สาธารณชนเข้าใจผิดได้ง่าย แต่ในความเป็นจริง เขาหมายถึง เครื่องมือที่ให้ข้อมูลจริงแบบ off-chain สำหรับสัญญาอัจฉริยะแบบ on-chain แต่อะไรคือเรื่องจริง? จะมั่นใจในความสมบูรณ์ของ oracle ได้อย่างไร? คำทำนายจะทำชั่วหรือไม่? ออราเคิลหลายอันกำลังสมรู้ร่วมคิดหรือไม่? จะเข้าใจ OVM (Oracle Machine Extractable Value) ได้อย่างไร
ในไตรมาสที่ 1 ปี 2024 หลังจากที่ BTC พุ่งสูงขึ้นเมื่อเร็ว ๆ นี้ มูลค่ารวมของโทเค็นที่ถูกล็อคในโครงการ DeFi ก็ทะลุระดับสูงสุดใหม่ โดยสูงถึง 175 พันล้านดอลลาร์สหรัฐ เพิ่มขึ้นเกือบ 70% เมื่อเทียบกับ 103 พันล้านดอลลาร์สหรัฐในไตรมาสที่ 4 ปี 2566 และ oracles ต่างก็ถูกเรียกว่าเป็นสายเลือดหลักของ DeFi ในพื้นที่ DeFi เช่น การแลกเปลี่ยนแบบกระจายอำนาจ (DEX) แพลตฟอร์มการให้ยืม และแพลตฟอร์มการซื้อขายอนุพันธ์ ล้วนอาศัยข้อมูลราคาที่แม่นยำในการดำเนินการ ในช่วงต้นปี 2023 สัญญา Oracle ของ TellorFlex ที่ใช้โดย BONQ ซึ่งเป็นโปรโตคอลการให้ยืมแบบกระจายอำนาจบนห่วงโซ่รูปหลายเหลี่ยมถูกจัดการ ด้านโครงการสร้างความเสียหายประมาณ 88 ล้านดอลลาร์สหรัฐ การโจมตีที่เกิดจากปัญหาใบเสนอราคาของ Oracle กลายเป็นเรื่องปกติ จะเห็นได้ว่าข้อมูลนอกเครือข่ายที่โปร่งใสและเชื่อถือได้คือการรับประกันขั้นพื้นฐานในการสนับสนุนการทำงานของ dApp
2. oracle เชื่อมต่อกับ off-chain และ on-chain อย่างไร?
โดยทั่วไปโหมดการทำงานของเครื่อง Oracle ประกอบด้วยการอัปโหลดตามกำหนดการ ตามเหตุการณ์ และการตอบสนองของคำขอ มาดูกระบวนการทั่วไปของการตอบกลับคำขอเป็นตัวอย่าง ซึ่งแบ่งออกเป็น 4 ขั้นตอนคร่าวๆ ดังต่อไปนี้:
ขั้นตอนที่ 1: บนเชน ผู้เรียก dApp จะเริ่มคำขอ (โดยพื้นฐานแล้วคือธุรกรรม) และสัญญาเซิร์ฟเวอร์ oracle จะทริกเกอร์เหตุการณ์บนเชนที่จะออก
ขั้นตอนที่ 2: นอกเครือข่าย โหนด oracle จะตรวจสอบเหตุการณ์เพื่อรับข้อมูล และรับข้อมูลนอกเครือข่ายที่แม่นยำผ่านระบบที่เกี่ยวข้อง
ขั้นตอนที่ 3: Off-chain on-chain เครื่อง oracle ให้ข้อมูลกับสัญญาเซิร์ฟเวอร์เครื่อง oracle ในรูปแบบของธุรกรรม
ขั้นตอนที่ 4: บนเชน สัญญาเซิร์ฟเวอร์ Oracle จะส่งคืนข้อมูลไปยังผู้เรียก (dApp) มีสองตัวเลือก: การพุชที่ใช้งานอยู่และการสืบค้นรองของ Dapp
ผู้เขียนจะให้การตีความกระบวนการนี้เพิ่มเติม:
ประการแรก ข้อกำหนดบนเชนเป็นแบบสาธารณะ เนื่องจากเหตุการณ์เป็นกลไกทั่วไปของบล็อกเชนที่ใช้ EVM ซึ่งหมายความว่าทั้งเครือข่ายสามารถรู้ได้ว่าตอนนี้ Dapp ต้องการข้อมูล xx
ประการที่สอง การพุชแบบออฟไลน์ไม่ใช่แบบอะตอมมิก และธุรกรรมแบบออนไลน์จะเสร็จสมบูรณ์แบบเรียลไทม์ ดังนั้นข้อมูลแบบออฟไลน์จึงต้องมีความล่าช้าอยู่บ้าง
สุดท้ายนี้ หากมีความต้องการที่กำหนดเองในห่วงโซ่ ออราเคิลสามารถเปลี่ยนเป็นบทบาทที่เป็นกลางของบุคคลที่สามและผลักดันไปยัง Dapp อย่างไรก็ตาม ข้อมูลตลาดทั่วไปส่วนใหญ่ เช่น ราคาแบบเรียลไทม์ของ BTC จะถูกดึงกลับมา โดย Dapp เองก็ได้รับสัญญา แน่นอนว่าเครื่อง Oracle เองก็มีกลไกการรายงานตามกำหนดการเช่นกัน และกลไกข้างต้นก็เหมือนกัน
3. การแยกตัวของ Luna เส้นทางพยากรณ์ที่ปั่นป่วน
แต่บล็อกเชนไม่ได้เป็นเพียง Defi dApps สามารถรับข้อมูลนอกเครือข่ายได้อย่างปลอดภัยและมีประสิทธิภาพ ซึ่งขยายขอบเขตธุรกิจและสถานการณ์การใช้งานได้อย่างมาก ขยายทิศทางธุรกิจไปสู่การเงิน การประกันภัย การจัดการห่วงโซ่อุปทาน และอินเทอร์เน็ตและสินค้าทางกายภาพ สาขาอื่นๆ
ตลาดในปัจจุบันช่วยให้เราสามารถใช้ข้อมูลแพลตฟอร์ม defillama เพื่อแสดงให้เห็นว่า Chainlink ยังคงเป็นผู้นำอย่างมั่นคง และ TVS (มูลค่ารวมของสินทรัพย์ในสกุลเงิน USD ที่ฝากไว้ในตลาดที่รับประกันโดยโครงสร้างพื้นฐานที่สำคัญ เช่น oracles) สูงถึง 45% ของ ตลาดทั้งหมด
ผู้อ่านที่ระมัดระวังจะพบว่าเส้นโค้งทางด้านขวาของตัวเลขด้านบนผันผวนอย่างรุนแรงในเดือนพฤษภาคม 2565 และต้นเหตุคือเหตุการณ์ความผิดพลาดของ LUNA อันโด่งดังในปี 2565 ตั้งแต่วันที่ 7 พฤษภาคม 2565 ถึงวันที่ 13 พฤษภาคม 2565 UST ซึ่งเป็น Stablecoin อัลกอริธึมชั้นนำ ประสบกับการแยกตัวสองครั้งและในที่สุดก็ตกอยู่ในเกลียวแห่งความตาย โดยที่ทั้ง LUNA และ UST พังทลายลง ในเวลาเดียวกัน หลายโครงการที่ใช้ oracles ภายในบริษัทประสบปัญหาร้ายแรงเนื่องจากการตอบสนองต่อความผันผวนของราคาช้า
ดังที่เห็นได้ชัดเจนในรูปด้านล่าง ส่วนแบ่งการตลาดของ Oracle ภายใน (สีชมพูในรูปด้านล่าง) ตกลงมาจากหน้าผาในเดือนพฤษภาคม 2022 Chronicle Oracle (สีแดงในรูปด้านล่าง) จับคลื่นของการเข้าชมนี้ได้เป็นอย่างดีและโดยทั่วไป ชนะส่วนแบ่งการตลาด ตลาดที่หายไปของออราเคิลภายใน
4. ภาวะที่กลืนไม่เข้าคายไม่ออกของออราเคิลของบุคคลที่สาม
นอกจากเหตุการณ์ที่ทำให้อุตสาหกรรมตกตะลึงแล้ว ดูเหมือนว่าการพัฒนาของ oracles จะติดขัดจริงๆ เนื่องจากตำแหน่งของอุตสาหกรรมมีความชัดเจนมาก จึงเป็นเครื่องมือในการเชื่อมต่อข้อมูลขึ้นและลงในห่วงโซ่ ส่งผลให้ผลิตภัณฑ์ค่อนข้างเดียว การทำงาน.
สิ่งที่ถูกวิพากษ์วิจารณ์มากที่สุดคือ รูปแบบกำไร ปัจจุบันคะแนนกำไรนั้นกระจุกตัวอยู่ในสองทิศทางทั่วไป: ค่าธรรมเนียมการสมัครสมาชิกข้อมูลและความหวังว่าโทเค็นที่ออกโดยโครงการจะเพิ่มขึ้น แน่นอนว่ารายได้ที่เกิดจากรูปแบบการสมัครสมาชิกข้อมูลเดียวนั้นมีจำกัด ยกตัวอย่างฟังก์ชันการชาร์จ VRF (Verifiable Random Sequence) ที่ Chainlink มอบให้เป็นตัวอย่าง VRF V1 และ V2 จำนวนโทเค็นทั้งหมดอยู่ที่ประมาณ 370,000 (7+30) คำนวณตามอัตราแลกเปลี่ยน LINK ปัจจุบัน ($16) รายได้รวมอยู่ที่ประมาณ 6 ล้านเหรียญสหรัฐ นับตั้งแต่เปิดตัวเวอร์ชัน VRF V2 เมื่อปลายเดือนกุมภาพันธ์ 2565 ก็สร้างรายได้รวม 4.8 ล้านดอลลาร์สหรัฐ โดยเฉลี่ยประมาณ 170,000 ดอลลาร์สหรัฐต่อเดือน (1.1 W LINK) เมื่อเทียบกับขนาดของ Chainlink ผลกำไรเหล่านี้ลดลงอย่างแน่นอน สำหรับการคาดหวังให้โทเค็นมีมูลค่าเพิ่มขึ้น ทุกคนมีความคิดเห็นที่แตกต่างกัน
อย่างไรก็ตาม เนื่องจากธรรมชาติของบุคคลที่สาม ตัว Oracle เองจึงอยู่ในตำแหน่งที่ค่อนข้างเป็นกลางและเริ่มมีค่าใช้จ่ายในโครงสร้างพื้นฐานด้านความปลอดภัยของเลเยอร์แอปพลิเคชัน มีเพียงการทำลายความประทับใจแบบดั้งเดิมของมิดเดิลแวร์และดำเนินการขยายการทำงานที่แตกต่างและเป็นระบบเท่านั้นที่จะสามารถเพิ่มอัตรากำไรได้ ตัวอย่างเช่น LayerZero ซึ่งเป็นสะพานข้ามสายโซ่ทั่วไปจะวางความปลอดภัยไว้บนส่วนหัวคำขอโหนดแบบ ultra-light ที่ดำเนินการโดย oracle เครื่องจักร.
กล่าวโดยสรุป ภาวะที่กลืนไม่เข้าคายไม่ออกของเครื่อง Oracle ในระดับตลาดก็คือมันถูกจำกัดด้วยข้อเสียตามธรรมชาติที่เกิดจากโหมดการทำงาน โดยมีฟังก์ชันเดียว กำไรน้อย และความสามารถในการขยายขนาดที่ยังไม่ได้รับการพัฒนา
อย่างไรก็ตาม หากเราขยายโมเดลการดำเนินการของสิ่งที่เรียกว่า oracle บุคคลที่สาม เราจะพบว่าปัญหานั้นมาจากปัจจัย บุคคลที่สาม ด้วย ในฐานะเครื่อง Oracle ใหม่ API 3 จึงอยู่ในตำแหน่งหลักเป็น อันดับแรก -ปาร์ตี้ ออราเคิล
4.1 การเปรียบเทียบออราเคิลของบุคคลที่สามและบุคคลที่หนึ่ง
API 3 เลือกที่จะเปิดใช้งานความสามารถในการดำเนินการและการบำรุงรักษาที่ครอบคลุมของโหนดบริการ API เป็นจุดเริ่มต้น และใช้แนวทาง web3 Native (น้ำหนักเบา + โมดูลาร์) มากขึ้นเพื่อสร้างสะพานเชื่อมระหว่างฝั่งอุปสงค์และฝั่งอุปทานของเครื่อง Oracle ผู้ดำเนินการ API สามารถสร้างโหนด oracle ของตนเองได้อย่างรวดเร็วโดยใช้โซลูชัน Airnode ที่ API 3 มอบให้
ในฐานะโปรเจ็กต์ Oracle บุคคลที่หนึ่ง เมื่อเปรียบเทียบกับซัพพลายเออร์ API ของ Oracle บุคคลที่สามแบบดั้งเดิม → oracle → กระบวนการทางธุรกิจ Dapp การเปลี่ยนแปลงของ API 3 (ซัพพลายเออร์ API + Oracle) → Dapp ทำให้ซัพพลายเออร์ API เป็นต้นแบบ อีกต่อไป มันเพียงแต่ทำหน้าที่เท่านั้น ในฐานะผู้ปฏิบัติงาน Oracle บุคคลที่สามและมีสิทธิ์พูดมากกว่านี้
ดังแสดงในรูปด้านบน หากปราศจากการแทรกแซงของบุคคลที่สาม การเชื่อมต่อข้อมูลจะลดลง เมื่อบทบาทของผู้ให้บริการ API และ Oracle ถูกรวมเข้าด้วยกัน ก็ไม่ต้องสงสัยเลยว่าข้อมูลมาจากไหน เนื่องจาก ชื่อเสียงของผู้ให้บริการ API ถูกนำเข้าสู่เครือข่ายออนไลน์พร้อมกับข้อมูล
เนื่องจากชื่อเสียงของผู้ให้บริการ API และกลยุทธ์การเชื่อมโยงที่แข็งแกร่งในการให้ข้อมูล การตรวจสอบย้อนกลับจึงเป็นเรื่องง่าย ในทางเทคนิคแล้วไม่ได้รับอนุญาตให้ทำสิ่งชั่วร้าย (โดยไม่ถูกค้นพบ) และมีกลไกมาร์จิ้นเป็นตาข่ายนิรภัย แม้ว่าผู้ให้บริการ API จะให้ข้อมูลที่เป็นเท็จเพื่อผลประโยชน์ของตนเอง ผู้ใช้ที่ได้รับบาดเจ็บยังสามารถอุทธรณ์และเรียกร้องค่าชดเชยได้ สำหรับเหตุการณ์ที่พัวพัน (เช่น ผู้ใช้ที่ร้องเรียนเกี่ยวกับการฉ้อโกงประกันภัย) พวกเขาจะเข้าสู่ระบบศาลออนไลน์เพื่อดำเนินการอนุญาโตตุลาการ ด้วยกลไกการประกันที่จัดทำโดย API 3 DAO ที่มีการกระจายอำนาจอย่างสมบูรณ์ API 3 จึงสามารถลงโทษผู้ให้บริการ API ได้ในระดับสูงสุดและชดเชยความเสียหายให้กับผู้ใช้ได้
5. ความเข้าใจเชิงลึกเกี่ยวกับโมเดลเศรษฐศาสตร์โทเค็นของ API3 DAO
ตามกลไกการวางเดิมพัน API3 DAO ช่วยให้โมเดลทางเศรษฐกิจโทเค็นของ API3 ทำงานได้อย่างเสถียรผ่านการตอบรับเชิงบวกและเชิงลบ
5.1 กลไกการกำกับดูแลคำมั่นสัญญา
กลไกการจำนำเป็นการดำเนินงานปกติของการกำกับดูแลของ DAO การจำนำผลกำไร และการกำกับดูแลการจำนำยังเป็นจุดเริ่มต้นของเศรษฐกิจแบบวงกลมอีกด้วย และ API 3 ก็ได้รับการปรับให้เหมาะสมเช่นกัน:
หากผู้จำนำหนีหลังจากได้รับเงินจำนำแล้วต้องทำอย่างไร? รายได้ที่สูงเกินจริง (โทเค็นที่เพิ่งสร้างใหม่) ที่สร้างโดยการเดิมพันของผู้ใช้จะล่าช้าและจะไหลไปยังพูลการเดิมพันตามค่าเริ่มต้น
มีอะไรอีกที่สามารถทำได้ด้วยโทเค็นในกลุ่มการปักหลัก? สามารถใช้เพื่อชดเชยความสูญเสียของผู้ใช้
ราคาสกุลเงินของกลุ่มจำนำมีเสถียรภาพอย่างไร? API 3 ควบคุมการพองตัวผ่านกลไกการล็อกการเบิร์นและโทเค็น: เงื่อนไขการแลกเปลี่ยนเพื่อรับบริการ dAPI คือผู้ใช้จำเป็นต้องเบิร์นโทเค็นของตนเองหรือล็อคโทเค็นของตนเอง
5.2 ลูปป้อนกลับเชิงบวกและเชิงลบ
ด้วยวิธีนี้ จำนวนโทเค็นในกลุ่มจำนำจะเป็นอย่างไร? จะมีการขยายตัวหรือการล่มสลายอย่างไม่เป็นระเบียบเนื่องจากการจ่ายค่าชดเชยไม่เพียงพอหรือไม่? มาวิเคราะห์กัน:
เมื่อจำนวนผู้ใช้ dAPI เพิ่มขึ้น ความเสี่ยงของระบบก็จะเพิ่มขึ้น (ต้นทุนการดำเนินงานของระบบจะเพิ่มขึ้นตามจำนวนผู้ใช้ที่เพิ่มขึ้น) และจำนวนเหตุการณ์ที่ต้องชดเชยจะเพิ่มขึ้น ในเวลานี้ โทเค็นในกลุ่มคำสัญญาจะลดลง (ใช้เพื่อชดเชยผู้ใช้ที่เสียหาย) และผู้ให้คำมั่น (และผู้จัดการ) จะได้รับความเสียหายต่อผลประโยชน์ของตนเองเนื่องจากการจัดการที่ไม่ดี แต่เช่นเดียวกัน การลดจำนวนโทเค็นในกลุ่มการปักหลักยังหมายถึงการเพิ่มจำนวนโทเค็นที่ไหลเข้าสู่ตลาดด้วย เนื่องจากโทเค็นที่ผู้ใช้ถืออยู่ได้รับผลกระทบจากภาวะเงินเฟ้อ เพื่อผลประโยชน์ของตนเอง กระแสโทเค็นส่วนใหญ่จึงไปที่กลุ่มจำนำ
เมื่อจำนวนผู้ใช้ dAPI ลดลง ความเสี่ยงของระบบจะลดลง โทเค็นในกลุ่มคำมั่นสัญญาจะค่อยๆ เพิ่มขึ้น และจำนวนโทเค็นที่ไหลเข้าสู่ตลาดจะหายาก แต่ไม่ได้หมายความว่าจำนวนโทเค็นในกลุ่มคำมั่นสัญญาจะเพิ่มขึ้นเสมอไป API 3 DAO จะปรับให้เข้ากับค่าความสมบูรณ์เป้าหมายโดยการควบคุมรายได้จากคำมั่นสัญญาแบบไดนามิก (และอัตราการขยาย)
สถานการณ์ทั้งสองข้างต้นสามารถสร้างวงจรเชิงบวกและเชิงลบได้ดีดังแสดงใน (a) ทางด้านซ้ายในรูปด้านล่าง เมื่อสถานการณ์ใดๆ ถึงเกณฑ์ ระบบจะปรับเปลี่ยนตัวเอง และผู้ใช้ dAPI จะมีเสถียรภาพดังที่แสดงใน (b) ทางด้านซ้ายในภาพด้านล่าง ซึ่งจะทำให้ระบบทำงานในสถานะที่สมบูรณ์ในที่สุด
ในความเป็นจริง โทเค็นการกำกับดูแลแบบ Dao ประเภทนี้ได้รับความนิยมมายาวนานในการกำกับดูแล DeFi ต่างๆ ตัวอย่างเช่น DAI ของ MakerDao ซึ่งเป็นเกณฑ์มาตรฐานการใช้งานโดยละเอียดของคอกม้าแบบกระจายอำนาจที่ผู้เขียนได้วิเคราะห์มาก่อน มี MKR เป็นผู้บุกเบิก:
สิ่งที่สวยงามเป็นพิเศษคือกลไกการประมูลแบบ 4 ทิศทางของเขา: การอ่านเพิ่มเติม: บทความหนึ่งอธิบายได้ทั้งหมด - ข้อเสนอ Stablecoin GHO ล่าสุดของ DeFI King AAVE
หนึ่งในนั้นคือคอลัมน์ Insolvent, Four Auctions
ดังนั้น การกำกับดูแลแบบ DAO จึงเป็นโหมดการทำงานกระแสหลักเพื่อความมั่นคงทางเศรษฐกิจ แต่นวัตกรรมของ API 3 ก็ไม่ด้อยไปกว่ากัน
6. ข้อได้เปรียบที่ไม่เหมือนใคร - เครือข่าย OEV ที่ก้าวล้ำ (อิงจาก ZK-Rollup)
6.1 การกำเนิดของ OEV
เช่นเดียวกับ MEV (ค่าที่สกัดได้ของนักขุด) OEV (ค่าที่แยกได้ของ oracle) หมายถึง oracles ที่ใช้ตำแหน่งในการจับค่าที่อาจตกเป็นของบุคคลที่สาม MEV รวบรวมมูลค่าผ่านการเรียงลำดับธุรกรรม และ OEV ใช้ส่วนต่างของราคาทั้งในและนอกห่วงโซ่เพื่อดึงมูลค่า เช่น ในข้อมูลตลาดที่สำคัญหรือสถานการณ์ที่ก่อให้เกิดเหตุการณ์สำคัญบนเครือข่าย (เช่น การเลิกกิจการ)
เพื่อให้เข้าใจถึงวิธีการสร้าง OEV คุณต้องทราบปัญหาปัจจุบันของเครื่อง Oracle ก่อน เนื่องจากค่าใช้จ่ายในการอัปโหลดข้อมูล เครื่องของ Oracle ในปัจจุบันจึงใช้กลไกในการอัปโหลดข้อมูลเป็นประจำ และช่วงเวลาที่ตั้งไว้ภายในช่วงที่ค่อนข้างเล็ก . ในเวลาเดียวกัน เพื่อหลีกเลี่ยงความผันผวนของราคาอย่างมากในระยะสั้นไม่ให้ส่งผลกระทบต่อตลาด โดยทั่วไปเครื่อง Oracle จะกำหนดเกณฑ์ เมื่อช่วงความผันผวนของราคาถึงเกณฑ์ในช่วงเวลาสั้น ๆ การอัปเดตจะเริ่มทำงาน กระตุ้น
แม้ว่าการแก้ไขนี้จะช่วยบรรเทาปัญหาได้บางส่วน แต่ก็ไม่ได้แก้ปัญหาความล่าช้าในการอัปโหลดข้อมูลโดยพื้นฐาน ตลาด DeFi มักจะมีความผันผวนสูง และราคาสินทรัพย์อาจเปลี่ยนแปลงอย่างมีนัยสำคัญในช่วงเวลาสั้นๆ
ในกรณีนี้ ผู้แสวงหาผลกำไรจากบุคคลที่สามมีมุมมองของพระเจ้า โดยการใช้ประโยชน์จากความล่าช้าในการอัปเดตข้อมูล พวกเขาสามารถได้รับผลกำไรมหาศาล และ OEV ก็ถือกำเนิดขึ้น
สำหรับ dApps ที่ต้องอาศัย oracles การอัปเดตหรือไม่มีฟีดข้อมูลอาจสร้างโอกาสสำหรับ OEV เช่น front-running การเก็งกำไร และการเลิกกิจการ จริงๆ แล้วเป็นการยากที่จะตัดสินการระบุแหล่งที่มาของค่าที่สามารถหาประโยชน์ได้ซึ่งเกิดจากความล่าช้าในการอัปโหลดข้อมูลนั้นมีความผันผวนในระดับหนึ่ง ดังนั้น หากการอัปโหลดข้อมูลล่าช้าไประยะหนึ่ง ปัญหาของเครื่อง Oracle ก็จะไม่เกิดขึ้น อยู่ จากนั้นสิ่งนี้ ค่าที่ใช้ประโยชน์ได้ซึ่งเกิดจากการหน่วงเวลาบางส่วนไม่สามารถกล่าวได้ว่าเครื่อง Oracle สร้างขึ้นโดยมีเจตนาร้าย
6.2 O EV Network—เวทีการประมูลสำหรับเกมหลายฝ่าย
เนื่องจากการมีอยู่ของ OEV ผู้ใช้และ dApps จึงได้รับคุณค่าจากบุคคลที่สาม เนื่องจากทั้งสองฝ่ายมีปฏิสัมพันธ์กัน เห็นได้ชัดว่านี่เป็นสถานการณ์ที่ทั้งสองฝ่ายไม่ต้องการเห็น API 3 ค้นพบว่า oracles มีสิทธิ์ในการปฏิเสธครั้งแรกในการจับมูลค่าของการรั่วไหลดังกล่าวทั้งหมด (สิทธิ์การกำหนดราคาสำหรับข้อมูลออนไลน์) ดังนั้นจึงเสนอ OEV NetWork
เนื่องจากเป็นเครือข่ายที่ใช้ Polygon zk rollup จึงมีขั้นตอนการสั่งซื้อแยกต่างหาก (ความตั้งใจของผู้เข้าร่วมที่จะเปลี่ยนสถานะบล็อคเชนคือคำสั่งซื้อ) แพลตฟอร์มการประมูลที่ประมูลสิทธิ์ในการอัปเดตข้อมูล dAPI
API 3 พัฒนาแพลตฟอร์มการประมูลของตัวเอง ลดการพึ่งพาบริการภายนอก ช่วยให้สามารถแบ่งปัน OEV ระหว่างผู้มีส่วนได้ส่วนเสียโดยไม่ต้องแบ่งผลกำไรให้กับแพลตฟอร์มการประมูล และนำ OEV ไปไว้ในบล็อกเชนด้วยฟีดข้อมูลแบบรวมทั้งหมด
ผู้ชนะการประมูลสามารถรับสิทธิ์ในการอัปเดตข้อมูลของ dAPI และอัปเดตข้อมูลราคาได้ กำไรส่วนใหญ่จากการประมูลจะถูกส่งกลับไปยัง dApp และ API 3 จะใช้ส่วนเล็ก ๆ เพื่อครอบคลุมต้นทุนการดำเนินงาน แน่นอนว่าการประมูลจะเกิดขึ้นก็ต่อเมื่อผู้ประมูล (บุคคลที่สาม) เชื่อว่าต้นทุนการประมูลน้อยกว่ารายได้ที่ได้จากราคาที่อัปเดต ดังนั้นบุคคลที่สามก็จะทำกำไรได้เช่นกัน ในฐานะผู้ใช้แพลตฟอร์ม dApp ดูเหมือนว่าไม่มีประโยชน์ที่แท้จริงจากการเข้าร่วมในการกระจายผลประโยชน์ ที่จริงแล้ว ต้องขอบคุณแหล่งข้อมูลคุณภาพสูงที่ dAPI มอบให้กับ dApp ทำให้สามารถทำธุรกรรมและการบริหารความเสี่ยงได้ดีขึ้น และจะได้รับผลประโยชน์ที่เป็นไปได้
วงจรชีวิตการประมูลจะแสดงในรูปด้านล่าง เมื่อผู้ค้นหาค้นพบ OEV ก็จะเริ่มการประมูล หลังจากที่ผู้ค้นหาชนะการประมูล เขาจะได้รับสิทธิ์ในการอัปเดตข้อมูล dAPI ของโหนด oracle หลังจากชำระค่าธรรมเนียมการประมูลแล้ว เขาสามารถใช้สิทธิ์นี้เพื่ออัปเดตข้อมูล dAPI ของโหนด oracle ได้ ค่าธรรมเนียมการประมูลที่จ่ายคือ OEV ที่บันทึกไว้ ซึ่งไหลไปยัง dApp
แนวโน้มปกติในการประมูลมีไว้สำหรับบุคคลที่สาม (ผู้ค้นหา) ที่จะขึ้นราคาประมูลเพิ่มเติมเพื่อให้ได้ผลกำไรที่เป็นไปได้ ยิ่งราคาประมูลสูง ความแตกต่างระหว่าง OEV จริงกับ OEV ที่ยึดได้ก็จะยิ่งน้อยลง
ส่วนเค้กชิ้นนี้จะใหญ่ขนาดไหน เราอาจรอดูและตัดสินหลังจากที่เครือข่ายทดสอบทำงานได้เสถียรมาระยะหนึ่งแล้ว ผลลัพธ์ของการประมูลเกือบจะได้ประโยชน์ทั้งสองฝ่ายสำหรับบทบาททั้งสี่ของ dApp, API 3 oracle node, บุคคลที่สาม และผู้ใช้ dAPP ในขณะเดียวกันก็สามารถจับมูลค่า OEV ได้มากที่สุด เนื่องจากการแข่งขันในตลาดรูปแบบสุดท้ายจะต้องเป็นการแข่งขันระหว่างบุคคลที่สาม เพื่อแสวงหาผลกำไร ผลกำไรของบุคคลที่สามจะค่อยๆ ถูกบีบอัด และผู้รับผลประโยชน์ขั้นสุดท้ายจะต้อง เป็น dApp สำหรับ API 3 ค่า OEV ส่วนเล็กๆ สามารถใช้เพื่อรักษาการดำเนินงานของเส้นทางธุรกิจ OEV ได้ สำหรับบุคคลที่สาม พวกเขายังสามารถได้รับส่วนแบ่งจากการดำเนินการอีกด้วย สำหรับผู้ใช้ dApp รายละเอียดที่เพิ่มขึ้นสามารถทำได้โดยการจูงใจผู้ดำเนินการบุคคลที่สามที่มีความเชี่ยวชาญสูงเพื่อจัดหาวิธีการที่ชาญฉลาดมากขึ้นในการพิจารณาว่าเมื่อใดควรอัปเดตจุดข้อมูลออนไลน์ ซึ่งจะเป็นประโยชน์ต่อผู้ใช้ dApp ในท้ายที่สุด
ณ จุดนี้ โครงการประมูล OEV ที่ใช้ API 3 ได้แก้ไขปัญหาการกระจายผลประโยชน์ในเกมหลายฝ่ายได้ในระดับสูงสุด และส่งคืน ผลกำไรที่ไม่ถูกต้อง ของบุคคลที่สามดั้งเดิมให้กับผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้อง โซลูชันนี้หรูหราจริงๆ
การอ่านแบบขยายได้: รายงานการวิจัย UniswapX (ตอนที่ 1): สรุปลิงก์การพัฒนา V1-3 ตีความนวัตกรรมหลักและความท้าทายของ DEX รุ่นต่อไป เพื่อทำความเข้าใจกลไกการประมูลของ UniswapX
7. สรุป
API 3 สร้างระบบนิเวศที่ขับเคลื่อนด้วยตนเองโดยอิงตามเศรษฐศาสตร์โทเค็นของตัวเอง ทำให้ระบบมีเสถียรภาพมากขึ้นผ่านการปรับเปลี่ยนผลตอบรับเชิงบวกและเชิงลบ
ในเวลาเดียวกัน เครือข่าย OEV ที่เสนอโดย API 3 แก้ปัญหาการไหลของ OEV อย่างชาญฉลาดด้วยการแนะนำกลไกการประมูลสำหรับสิทธิ์ในการอัปเดตราคา dAPI และถ่ายโอนข้อขัดแย้งระหว่าง oracles และ dApps อันเนื่องมาจาก OEV ไปยังบุคคลที่สามอย่างชาญฉลาด
ด้วยความนิยมและการพัฒนาแอปพลิเคชันแบบกระจายอำนาจ ความต้องการบริการ Oracle ที่เชื่อถือได้และปลอดภัยจะยังคงเติบโตต่อไป และดูเหมือนว่าต้นแบบของ Oracle รุ่นต่อไปจะปรากฏขึ้น
อย่างไรก็ตาม API 3 ยังเผชิญกับความท้าทายบางประการเช่นกัน
แบบจำลองทางเศรษฐกิจไม่สามารถกำหนดและออกแบบได้ตั้งแต่เริ่มต้นและดำเนินไปได้อย่างมั่นคงในระยะยาว กระบวนการต่อเนื่องที่ตามมามักจะตกอยู่ในการปกครองที่มากเกินไปหรือละเลยการปกครอง
นอกจากนี้ แกนหลักของการประมูล API ยังอยู่ที่การวัดชื่อเสียงและรายได้ โดยพื้นฐานแล้ว มันเป็นโมเดลในแง่ดี ไม่ใช่โมเดลในแง่ร้าย (ZK) แม้ว่า LayerZero ซึ่งใช้โครงสร้างชื่อเสียงนี้จะยังคงดำเนินการต่อไป แม้แต่ oracle ก็ตาม + สะพานข้ามโซ่ ความเสี่ยงสูงแบบสองทาง การรวมกันไม่เคยมีปัญหาด้านตลาดใด ๆ และสามารถพิสูจน์ความปลอดภัยได้ แต่ยังคงมีความเสี่ยงอยู่ การเดิมพันชื่อเสียงอย่างต่อเนื่องหมายความว่าผลตอบแทนในตลาดของผู้เข้าร่วมจะต้องสูงเพียงพอ ซึ่งเกี่ยวข้องอย่างใกล้ชิดกับการพัฒนาตลาดของ API 3
สุดท้ายนี้ ตลาดสำหรับเครื่อง Oracle ไม่ใช่เรื่องง่ายที่จะแข่งขันกัน สาเหตุที่แท้จริงคือสิ่งที่ Dapp แต่ละตัวให้ความสำคัญมากที่สุดไม่ใช่แค่ความสามารถในการให้ข้อมูลเท่านั้น แต่ยังรวมถึงการวางตำแหน่งของเครื่อง Oracle เองในฐานะบุคคลที่สามอีกด้วย 3 ได้ทำลายจุดนี้ไปแล้ว แต่ตัว Dapp เองก็สามารถเข้าร่วมการประมูลได้ ทำให้ผู้ใช้กังวลอย่างหลีกเลี่ยงไม่ได้ว่าพวกเขาจะสมรู้ร่วมคิดกันเองหรือไม่ แม้ว่ามันจะหมายถึงการทำให้ชื่อเสียงของ Dapp ของตัวเองตกอยู่ในอันตรายด้วย ยิ่งไปกว่านั้น chainlink ที่จัดตั้งขึ้นและอื่นๆ ไม่สามารถปฏิบัติตามได้ พวกเขายังสามารถปล่อย OEV ได้มากขึ้นและยังคงควบคุมตลาดต่อไป
