Recent, API 3 a primit recent finanțare strategică de 4 milioane USD, condusă de DWF Labs, cu participarea multor VC cunoscuti. Multă vreme, traseul oracolului a fost dominat de oracole cu trei partide reprezentate de Chainlink. Paisprezece a fost și el surprins când a văzut această știre ~ De ce a putut API 3 să obțină finanțare? Va fi el perturbatorul oracolelor tradiționale? Ce îl face unic? Fiind un proiect API descentralizat (dAPI), API 3 este definit ca un oracol „primă parte” Prin rețeaua inovatoare și inovatoare OEV (bazată pe ZK-Rollup), rezolvă problema încrederii intermediare a oracolului „terț”. , Transparența datelor este scăzută și OEV (Oracle Extractable Value) este o problemă comună.
1. Pot oracolele să prezică cu adevărat viitorul?
Termenul „mașină de profeție” este oarecum mitic și poate induce cu ușurință publicul în eroare. Dar, de fapt, el se referă la instrumente care oferă date reale în afara lanțului pentru contractele inteligente în lanț, dar ce este real? Cum să asigurăm integritatea oracolului însuși? Vor face profețiile rău? Mai multe oracole se înțeleg? Cum să înțelegeți OVM (Oracle Machine Extractable Value)? În primul trimestru al anului 2024, după creșterea recentă a BTC, valoarea totală a jetoanelor blocate în proiectele DeFi a depășit, de asemenea, un nou maxim, atingând 175 de miliarde de dolari SUA, comparativ cu 103 de miliarde de dolari în T4 al anului 2023. aproape 70%, iar mașina oracolului a fost, de asemenea. Toate sunt numite nucleul sângelui DeFi. În domeniul DeFi, cum ar fi bursele descentralizate (DEX), platformele de creditare și platformele de tranzacționare cu derivate, toate se bazează pe date precise ale prețurilor pentru a funcționa. La începutul anului 2023, contractul Oracle TellorFlex folosit de BONQ, protocolul de împrumut descentralizat pe lanțul de poligoane, a fost manipulat partea proiectului a generat pierderi de aproximativ 88 milioane USD. Atacurile cauzate de problemele de cotare oracle au devenit comune. Se poate observa că datele off-chain transparente și fiabile sunt garanția de bază pentru a susține funcționarea dApp.
2. Cum se conectează oracolul la off-chain și on-chain?
Modurile de lucru ale mașinilor Oracle includ în general încărcarea programată, bazată pe evenimente și răspunsul la cerere. Luăm ca exemplu procesul general de răspuns la cerere, care este împărțit aproximativ în următorii 4 pași:
PASUL 1: Pe lanț, apelantul dApp inițiază o solicitare (în esență o tranzacție), iar contractul de server Oracle declanșează un eveniment pe lanț care urmează să fie emis.
PASUL 2: În afara lanțului, nodul oracol monitorizează evenimentele pentru a obține informații și obține informații precise în afara lanțului prin sistemele lor respective.
PASUL 3: În afara lanțului și în lanț, mașina Oracle oferă date contractului de server Oracle sub forma unei tranzacții
PASUL 4: Pe lanț, contractul de server Oracle returnează datele apelantului (dApp) Există două opțiuni: push activ și interogare secundară Dapp.
Autorul va oferi o interpretare extinsă a acestui proces:
În primul rând, cerințele privind lanțul sunt publice, deoarece evenimentele sunt un mecanism comun al blockchain-urilor bazate pe EVM, ceea ce înseamnă că întreaga rețea poate ști că Dapp are acum nevoie de informații xx.
În al doilea rând, împingerea în afara lanțului este non-atomică, iar tranzacțiile în lanț sunt finalizate în timp real, astfel încât datele în afara lanțului trebuie să aibă un anumit decalaj.
În cele din urmă, dacă există o cerere personalizată pe lanț, oracolul poate fi transformat într-un rol imparțial terț și împins la Dapp. Cu toate acestea, majoritatea datelor generale de piață, cum ar fi prețul în timp real al BTC, vor fi preluat de către Dapp însuși Contractul este achiziționat. Desigur, mașina Oracle în sine are și un mecanism de raportare programat, iar cele de mai sus sunt practic aceleași.
3. Decuplarea Luna, traseul turbulent al oracolului
Dar blockchain nu este doar Defi, prin oracole, dApps pot obține în mod sigur și eficient date în afara lanțului, extinzându-și astfel în mod semnificativ domeniul de activitate și scenariile de aplicare, extinzându-și direcțiile de afaceri la finanțare, asigurări, managementul lanțului de aprovizionare și bunuri fizice alte domenii.
Pe piața actuală, folosim datele platformei defillama pentru a arăta că Chainlink este încă ferm pe poziția de lider, cu TVS (valoarea totală a activelor în dolari americani depuse pe piață garantată de infrastructura cheie, cum ar fi oracole) atingând 45% din intreaga piata.
Cititorii atenți vor descoperi că curba din partea dreaptă a cifrei de mai sus a fluctuat violent în mai 2022, iar declanșatorul a fost celebrul eveniment de prăbușire LUNA din 2022. Din 7 mai 2022 până pe 13 mai 2022, principalul stablecoin algoritmic a experimentat UST două decuplări și în cele din urmă au căzut într-o spirală morții, atât LUNA, cât și UST prăbușindu-se. În același timp, multe proiecte care folosesc oracole interne au întâmpinat probleme serioase din cauza răspunsului lor lent la fluctuațiile prețurilor.
După cum se poate observa clar în figura de mai jos, cota de piață a oracolelor interne (roz în figura de mai jos) a căzut de pe o stâncă în mai 2022. Oracolul Chronicle (roșu în figura de mai jos) a prins foarte bine acest val de trafic și, practic, a câștigat cota de piață Piața pierdută a oracolelor interne.
4. Dilema oracolelor terților
Pe lângă evenimentele care au șocat industria, se pare că dezvoltarea oracolelor a fost blocată Într-adevăr, deoarece poziționarea industriei este foarte clară, este un instrument de conectare a datelor în sus și în jos, rezultând un produs relativ unic. funcţie.
Cel mai criticat lucru este modelul său de profit În prezent, punctele sale de profit sunt concentrate în două direcții generale: taxele de abonament la date și speranța că token-urile emise de proiect vor aprecia. Evident, veniturile generate de un singur model de profit pentru abonamentul de date sunt limitate. Luați ca exemplu funcția de taxare VRF (secvență aleatorie verificabilă) oferită de Chainlink Referindu-se la browserul blockchain Etherscan, autorul a numărat blocările contractelor ale celor două versiuni. VRF V1 și V2. Numărul total de jetoane este de aproximativ 370.000 (7+30, calculat la cursul de schimb LINK actual (16 USD), venitul total este de aproximativ 6 milioane USD. De când versiunea VRF V2 a fost lansată la sfârșitul lunii februarie 2022, a generat un venit total de 4,8 milioane USD, cu un venit mediu lunar de aproximativ 170.000 USD (1,1 W LINK). În comparație cu dimensiunea mare a Chainlink, aceste profituri sunt într-adevăr o picătură în găleată.
Cu toate acestea, din cauza naturii terței părți, mașina Oracle în sine se află într-o poziție relativ neutră și a început să coste infrastructura de securitate a stratului de aplicație. Doar prin spargerea imaginii middleware tradiționale și prin realizarea unei expansiuni funcționale diferențiate și sistematice, marjele de profit pot fi crescute.
Pe scurt, dilema mașinii oracol la nivelul pieței este că este limitată de dezavantajele naturale cauzate de modelul de operare, cu funcții unice, profituri slabe și scalabilitate care nu a fost încă dezvoltată.
Cu toate acestea, dacă extindem modelul de execuție al așa-numitului oracol terță parte, vom descoperi că problemele sale provin și din factorii „terți”, deoarece o nouă mașină de oracol este poziționată ca „primă”. -petrecere” oracol.
4.1 Compararea oracolelor terță parte și prima parte
API 3 alege să activeze capabilitățile cuprinzătoare de operare și întreținere ale nodurilor de servicii API ca punct de plecare și utilizează o abordare mai nativă web3 (ușoară + modulară) pentru a construi o punte între partea de cerere și partea de ofertă a mașinii Oracle. Operatorii API își pot construi rapid propriile noduri oracle pe baza soluției Airnode furnizată de API 3.
Fiind un proiect oracle primar, în comparație cu furnizorul API al unui terț tradițional → oracle → proces de afaceri Dapp, transformarea API 3 (furnizor API + oracol) → Dapp face ca furnizorul API să fie stăpânul problemei acționează ca un lucrător oracol terț și are mai mult cuvânt de spus.
După cum se arată în figura de mai sus, fără intervenția unei terțe părți, legătura de date este redusă. Când rolurile furnizorului de API și ale oracolului sunt integrate, nu se pune problema de unde provin datele, deoarece reputația furnizorului de API este adusă în lanț împreună cu datele.
Datorită reputației furnizorului de API și a strategiei puternice de legare a furnizării datelor, trasabilitatea este simplă, tehnic nu este permis să faci rău (fără a fi descoperit) și există un mecanism de marjă ca rezervă. Chiar dacă furnizorul de API furnizează date false pentru un câștig personal, utilizatorul vătămat poate face apel și cere despăgubiri. Pentru incidente încurcate (cum ar fi utilizatorii care se plâng cu răutate de fraudă în asigurări), aceștia vor intra în sistemul judiciar în lanț pentru arbitraj. Cu ajutorul mecanismului de asigurare oferit de API 3 DAO complet descentralizat, API 3 poate pedepsi în cea mai mare măsură furnizorii API și poate oferi despăgubiri utilizatorilor prejudiciați.
5. Înțelegerea în profunzime a modelului economic simbol al API3 DAO
Pe baza mecanismului său de miză, API3 DAO permite modelului economic simbol al API3 să funcționeze stabil prin feedback pozitiv și negativ.
5.1 Mecanismul de guvernare a angajamentelor
Mecanismul de gaj este o operațiune regulată a guvernării DAO pentru a obține profituri prin gaj, iar guvernanța gajului este, de asemenea, punctul de plecare al economiei circulare. Și API 3 a fost, de asemenea, optimizat:
Ce ar trebui să fac dacă gajul fuge după ce a primit veniturile din gaj? Venitul umflat (jetoane nou bătute) generat de mizarea utilizatorului va fi întârziat și va fi transferat în mod implicit către pool-ul de miză.
Ce altceva se poate face cu jetoanele din pool-ul de miză? Poate fi folosit pentru a compensa utilizatorii pentru pierderi.
Cum este stabil prețul valutar al grupului de gaj? API 3 controlează inflația prin mecanismele de blocare Burn și Token: condiția de schimb pentru obținerea serviciilor dAPI este ca utilizatorii să-și ardă propriile jetoane sau să-și blocheze propriile jetoane.
5.2 Bucle de feedback pozitiv și negativ
În acest fel, care va fi tendința numărului de jetoane din pool-ul de gaj? Va exista o expansiune dezordonată sau colaps din cauza plății insuficiente a despăgubirilor? Să o analizăm:
Pe măsură ce utilizatorii dAPI cresc, riscurile de sistem vor crește (costurile de operare a sistemului cresc pe măsură ce numărul utilizatorilor crește), iar numărul de incidente care necesită compensare va crește. În acest moment, jetoanele din pool-ul de gaj vor fi reduse (utilizate pentru a compensa utilizatorii deteriorați), iar cei care gajă (și managerii) vor suferi daune propriilor interese din cauza managementului defectuos. Dar, în egală măsură, o reducere a numărului de jetoane din pool-ul de miză înseamnă și o creștere a numărului de jetoane care circulă pe piață. Deoarece jetoanele deținute de utilizatori sunt afectate de inflație, în beneficiul lor, o mare parte a fluxului de jetoane este către fondul de gaj.
Când numărul de utilizatori dAPI scade, riscul sistemului scade, jetoanele din pool-ul de gaj vor crește treptat, iar numărul de jetoane care curge pe piață va deveni limitat. Dar acest lucru nu înseamnă că numărul de jetoane din grupul de gaj va continua să crească API 3 DAO îl va potrivi la o valoare țintă a sănătății prin controlul dinamic al veniturilor din gaj (și rata de expansiune).
Cele două situații de mai sus pot forma bine ciclul pozitiv și negativ prezentat în (a) din stânga în figura de mai jos. Când orice situație atinge pragul, sistemul se va auto-ajusta, iar utilizatorii dAPI se vor stabiliza așa cum se arată în (b) din stânga în figura de mai jos, făcând în cele din urmă sistemul să funcționeze într-o stare sănătoasă.
De fapt, acest tip de token de guvernare în stil Dao a fost popularizat de mult în diferite guvernări DeFi. De exemplu, DAI-ul MakerDao, benchmark-ul detaliat de implementare a monedelor stabile descentralizate pe care autorul l-a analizat înainte, are MKR ca precursor:
Ceea ce este deosebit de frumos este mecanismul său de licitație în 4 direcții: Lectură extensibilă: „Un articol explică clar – cea mai recentă propunere GHO a monedei stabile a DeFI King AAVE”
Printre acestea se numără rubrica „Insolvent, patru licitații”.
Prin urmare, guvernarea în stil DAO este modelul de operare principal pentru stabilitatea economică, dar inovația API 3 nu este inferioară.
6. Avantaje unice - Rețeaua OEV revoluționară (bazată pe ZK-Rollup)
6.1 Nașterea OEV
Similar cu MEV (Miner Extractable Value), OEV (Oracle Extractable Value) se referă la oracole care își folosesc poziția pentru a capta valoarea care altfel ar ajunge la o terță parte. MEV captează valoare prin secvențierea tranzacțiilor, în timp ce OEV utilizează diferența de preț dintre în lanț și în afara lanțului pentru a extrage valoare, cum ar fi date cheie ale pieței sau scenarii care declanșează evenimente majore în lanț (cum ar fi lichidarea).
Pentru a înțelege cum este generat OEV, trebuie să cunoașteți mai întâi problemele actuale ale mașinilor Oracle: din cauza costului de încărcare a datelor, în prezent mașinile Oracle adoptă practic un mecanism de încărcare regulată a datelor, iar intervalul de timp este setat într-un interval relativ mic. . În același timp, pentru a evita fluctuațiile uriașe de preț pe termen scurt să afecteze piața, mașina Oracle va stabili în general un prag Când intervalul de fluctuație a prețului atinge pragul într-o perioadă scurtă de timp, o actualizare va fi activă declanșat.
Deși acest remediu poate atenua unele dintre probleme, nu rezolvă în mod fundamental problema latenței de încărcare a datelor. Piața DeFi este de obicei foarte volatilă, iar prețurile activelor se pot schimba semnificativ într-o perioadă scurtă de timp.
În acest caz, terți care caută profit au perspectiva lui Dumnezeu Profitând de întârzierea actualizării datelor, pot obține profituri uriașe și se naște OEV.
Pentru dApps care se bazează pe oracole, orice actualizare sau absența fluxurilor de date poate crea oportunități pentru OEV, cum ar fi front-running, arbitraj și lichidare. De fapt, este dificil să se judece proprietatea asupra valorii exploatabile cauzată de întârzierea încărcării datelor în sine are un anumit grad de volatilitate this Valoarea exploatabilă generată de întârzierea parțială nu poate fi considerată a fi generată în mod rău intenționat de mașina oracol.
6.2 Rețeaua OEV — o etapă de licitație pentru jocuri multipartite
Datorită existenței OEV, utilizatorii și dApp, ca două părți care interacționează între ele, au valoare extrasă de către terți Acestea sunt, evident, situații pe care cele două părți nu vor să le vadă. API 3 a descoperit că oracolele au dreptul să refuze mai întâi să capteze valoarea tuturor acestor scurgeri (drepturi de preț pentru datele în lanț), așa că a fost propusă OEV NetWork.
Ca o rețea bazată pe Polygon zk rollup, este o platformă de licitație separată (intenția oricărui participant de a schimba starea blockchain-ului este o comandă), care scoate la licitație drepturile de actualizare a datelor dAPI.
API 3 și-a dezvoltat propria platformă de licitație, eliminând dependența de serviciile externe, permițând partajarea OEV între părțile interesate fără a împărți profiturile platformei de licitație și internalizând OEV în blockchain cu toate fluxurile de date integrate.
Câștigătorul licitației poate obține drepturile de actualizare a datelor dAPI și poate actualiza datele de preț Majoritatea profiturilor din licitație vor fi returnate către dApp, iar o parte foarte mică va fi returnată la API 3 pentru a acoperi costurile de operare. Evident, atunci când licitatorul (un terț) consideră că costul licitației
Ciclul de viață al licitației este prezentat în figura de mai jos. După ce căutătorul câștigă oferta, el va obține dreptul de a actualiza datele dAPI nodul Oracle După ce a plătit taxa de licitare, el poate exercita acest drept de a actualiza datele dAPI nodului Oracle. Taxa de licitație plătită este OEV capturat, care se transferă către dApp.
Tendința firească în licitații este ca terții (căutători) să mărească și mai mult prețul de licitație pentru posibilele profituri. Cu cât prețul de licitație este mai mare, cu atât diferența dintre OEV real și OEV capturat este mai mică.
Cât de mare este această prăjitură, ar fi bine să așteptăm și să vedem și să facem o judecată după ce rețeaua de testare a funcționat stabil pentru o perioadă de timp. Rezultatul licitației este aproape o situație câștigătoare pentru cele patru roluri ale utilizatorilor dApp, nodul API 3, terță parte și dAPP în același timp, poate capta cea mai mare parte a valorii OEV, deoarece forma finală a concurenței pe piață trebuie să fie concurența între terți. Pentru a căuta marje de profit, profiturile terților vor fi comprimate treptat, iar beneficiarul final trebuie să fie. fi dApp. Pentru API 3, o mică parte din valoarea OEV poate fi utilizată pentru a menține funcționarea traseului de afaceri OEV. Pentru terți, ei pot obține și o parte din acțiune. Pentru utilizatorii dApp, granularitatea poate fi crescută prin stimularea participanților terți foarte specializați să ofere metode mai perspicace pentru a determina când să actualizeze punctele de date în lanț, beneficiind în cele din urmă utilizatorilor dApp.
În acest moment, pe baza schemei de licitație OEV din API 3, problema distribuirii beneficiilor în jocurile multipartite a fost rezolvată în cea mai mare măsură, iar „profitul greșit” inițial al terței părți a fost reintrodus la nivelul relevant. părțile interesate. Această soluție este cu adevărat elegantă.
Lectură extensibilă: „Raport de cercetare UniswapX (Partea 1): Rezumarea legăturilor de dezvoltare V1-3, interpretarea principiului inovației și provocărilor următoarei generații DEX” pentru a înțelege mecanismul de licitație al UniswapX.
7. Rezumat
API 3 construiește un ecosistem de conducere autonomă bazat pe propria sa economie de simbol și face funcționarea sistemului mai stabilă prin ajustări de feedback pozitiv și negativ.
În același timp, Rețeaua OEV propusă de API 3 rezolvă în mod inteligent problema fluxului OEV prin introducerea unui mecanism de licitație pentru drepturile de actualizare a prețurilor dAPI și transferă inteligent contradicția dintre oracol și dApp din cauza OEV către o terță parte.
Odată cu popularitatea și dezvoltarea aplicațiilor descentralizate, cererea pentru servicii oracole fiabile și sigure va continua să crească, iar prototipul următoarei generații de oracole pare să fi apărut.
Cu toate acestea, API 3 se confruntă și cu unele provocări.
Un model economic nu poate fi definit și proiectat la început și poate funcționa stabil pe termen lung Procesul continuu ulterior va cădea adesea într-o guvernare excesivă sau o guvernare neglijată.
Mai mult, nucleul licitației API constă în măsurarea reputației și a veniturilor. Este în esență un model optimist, nu un model pesimist (ZK), deși LayerZero, care folosește și această structură de reputație, a continuat să funcționeze + cross-chain bridge bidirecțional risc ridicat Combinația nu a avut niciodată probleme de piață și siguranța sa poate fi dovedită, dar există încă posibilitatea riscului. Și a continua să pariezi pe reputație înseamnă că randamentul de piață al participanților trebuie să fie suficient de mare, ceea ce este strâns legat de dezvoltarea pieței a API 3.
În cele din urmă, piața mașinilor Oracle nu este ușor de concurat. Cauza principală este că ceea ce apreciază cel mai mult fiecare Dapp nu este doar capacitatea de a furniza date, ci și poziționarea de către terți a mașinii Oracle Now 3 a rupt acest punct, dar Dapp în sine este, de asemenea, posibilitatea de a participa la licitație îi face pe utilizatori să se îngrijoreze în mod inevitabil dacă se vor înțelege singuri, deși înseamnă, de asemenea, să pună în joc reputația propriei Dapp. Mai mult, chainlink-ul consacrat și alții nu sunt în măsură să urmeze exemplul. De asemenea, pot elibera mai multe OEV pentru a continua să controleze piața.