Récemment, API3 a obtenu 4 millions de dollars en funding stratégique, dirigé par DWF Labs et suivi par plusieurs VC bien connus. Historiquement, le marché des oracles a été dominé par des oracles tiers comme Chainlink. Shisi a été surpris par cette nouvelle ~ Pourquoi API3 a-t-il pu obtenir des fundings ? Serait-il le perturbateur des oracles traditionnels ? Qu’est-ce qui le rend unique ? En tant que projet d’API décentralisé (dAPI), API3 se définit comme un oracle « first-party ». En tirant parti du réseau OEV innovant (basé sur ZK-Rollup), il résout les problèmes courants associés aux oracles tiers, tels que la confiance des intermédiaires, la faible transparence des données et le contrôle de la valeur extractible Oracle (OEV).

2. Comment les oracles se connectent-ils hors chaîne et sur la chaîne ?

Les oracles fonctionnent généralement selon trois modes : téléchargements planifiés, piloté par les événements et requête-réponse. Si l’on prend l’exemple du modèle demande-réponse, le processus peut être grossièrement divisé en quatre étapes :

STEP 1 : Sur la chaîne, la dApp appelante lance une demande (essentiellement une transaction) et le contrat de service oracle déclenche un événement hors chaîne.STEP 2 : Hors chaîne, les nœuds oracle écoutent l’événement pour obtenir des informations, puis collectent des données hors chaîne précises via leurs systèmes respectifs.STEP 3 : Off-chain et on-chain, l’oracle fournit les données au contrat de service oracle sous la forme d’une transaction.STEP 4 : Sur la chaîne, le contrat de service oracle renvoie les données à la dApp appelante. Cela peut être fait soit par le biais d’un push actif, soit par l’interrogation de la dApp. Voici une explication détaillée de ce processus : Tout d’abord, les demandes off-chain sont publiques. Étant donné que les événements sont un mécanisme courant dans les blockchains basées sur EVM, l’ensemble du réseau est conscient que la dApp a besoin de certaines informations. Deuxièmement, la poussée de données off-chain n’est pas atomique. Alors que les transactions on-chain sont effectuées en temps réel, les données off-chain ont intrinsèquement une certaine latence. Enfin, si la demande off-chain est personnalisée, l’oracle peut agir en tant qu’arbitre tiers et pousser les données vers la dApp. Cependant, pour les données courantes telles que les prix BTC en temps réel, la dApp récupère généralement les données du contrat lui-même. De plus, les oracles disposent souvent d’un mécanisme de reporting programmé. Les principes de base restent cohérents dans ces différents scénarios. 3. Le découplage de Luna, la course à l’oracle dynamique

Cependant, la blockchain ne se limite pas à DeFi seul. Grâce aux oracles, les dApps peuvent accéder de manière sécurisée et efficace aux données off-chain, élargissant considérablement leur champ d’activité et leurs scénarios d’application. Cela leur permet de s’étendre à la finance, à l’assurance, à la gestion de la chaîne d’approvisionnement, à l’IoT et à bien d’autres domaines.

Sur le marché actuel, selon les données de la plate-forme DeFiLlama, Chainlink occupe toujours une position dominante, avec TVL (valeur totale verrouillée, libellée en USD, sécurisée par des infrastructures critiques telles que les oracles) représentant 45% de l’ensemble du marché.

Un lecteur attentif remarquera que la courbe sur le côté droit du graphique a connu une forte volatilité en mai 2022. Le catalyseur a été le tristement célèbre crash de Luna du 7 au 13 mai 2022, où le leading algorithmique stablecoin UST a subi deux incidents de découplage, qui ont finalement entraîné une chute en même temps que Luna. Dans le même temps, de nombreux projets utilisant des oracles internes ont été confrontés à de graves problèmes en raison de réponses tardives aux fluctuations de prix.

Le graphique suivant montre clairement une forte baisse de la part de marché des oracles internes (en rose) en mai 2022. Les oracles Chronicle (en rouge) ont efficacement capturé cette augmentation du trafic, sécurisant essentiellement la part de marché perdue par les oracles internes.

4. La situation difficile des oracles tiers

Mis à part les événements qui secouent l’industrie, il semble que le développement des oracles soit au point mort. En effet, en raison de son positionnement clair dans l’industrie en tant qu’outil permettant de relier les données on-chain et off-chain, les produits oracle ont tendance à avoir des fonctionnalités relativement simples. L’un des aspects les plus critiqués est leur modèle de profit, qui tourne actuellement autour des frais d’abonnement aux données et de l’appréciation des jetons émis par les équipes de projet. De toute évidence, les revenus générés par un modèle unique d’abonnement aux données sont limités. Par exemple, en prenant l’exemple de la fonction de génération de frais de Chainlink pour la fonction aléatoire vérifiable (VRF), selon blockchain explorer Etherscan, j’ai calculé que le total des jetons verrouillés pour les versions VRF V1 et V2 s’élevait à environ 370 000 (7 + 30), ce qui se traduit par environ 6 millions de dollars de revenus sur la base du taux actuel de LINK (16 $). Depuis le lancement de VRF V2 fin février 2022, il a généré environ 4,8 millions de dollars de revenus, soit une moyenne d’environ 170 000 dollars par mois (11 000 LINK). Comparés à la vaste échelle de Chainlink, ces bénéfices sont en effet maigres. En ce qui concerne l’appréciation symbolique, les opinions varient.

Cependant, en raison de leur nature d’entités tierces, les oracles occupent intrinsèquement une position relativement neutre et commencent à servir d’infrastructure critique dans la sécurité de la couche applicative. Pour s’affranchir de l’impression traditionnelle du middleware et améliorer la rentabilité, les oracles ont besoin d’extensions fonctionnelles différenciées et systématiques. Par exemple, LayerZero, en tant que cross-chain bridge typique, s’appuie sur la sécurité portée par les oracles avec des requêtes ultra-light node. En résumé, le problème des oracles sur le marché réside dans leurs limites opérationnelles inhérentes, leur fonctionnalité unique, leur rentabilité modeste et leur évolutivité qui n’a pas encore été étendue. Néanmoins, la compréhension du modèle d’exécution des oracles dits tiers révèle que leurs problèmes découlent de leur nature « tierce partie ». API3, se positionnant comme un nouveau venu dans le secteur des oracles, se concentre sur le fait d’être un oracle « first-party », visant à surmonter ces défis.

4.1 Comparaison des oracles tiers et first-party

API3 a choisi de tirer parti de ses capacités opérationnelles complètes pour activer API nœuds de service, en utilisant une approche plus web3-native (légère + modulaire) pour créer un bridge entre les consommateurs et les fournisseurs d’Oracle. Les opérateurs d’API peuvent rapidement configurer leurs propres nœuds oracle à l’aide de la solution Airnode d’API3.

En tant que projet Oracle propriétaire, par rapport au flux traditionnel où les fournisseurs de API se connectent aux oracles, puis aux opérations dApp (fournisseurs de API → oracle → dApp), l’approche de API3 (fournisseurs API + oracle) → dApp permet aux fournisseurs de API de jouer un rôle plus central. Ils n’agissent pas plus longtemps simplement en tant que travailleurs oracle tiers, mais gagnent plus d’influence et d’autonomie dans l’écosystème.

Comme illustré ci-dessus, avec l’élimination de l’intervention d’un tiers, la chaîne de données est rationalisée. Lorsque les fournisseurs d’API et les oracles fusionnent des rôles, il n’y a pas de question plus longue de savoir d’où proviennent les données, car la réputation des fournisseurs d’API est directement liée aux données off-chain.

En raison de la réputation étroitement liée des fournisseurs d’API aux données qu’ils fournissent, le traçage est simplifié et, techniquement, les comportements malveillants ne sont pas autorisés à passer inaperçus, soutenus par un mécanisme de garantie. Même si un fournisseur d’API fournit de manière malveillante de fausses données à des fins personnelles, les utilisateurs concernés peuvent faire appel et demander une indemnisation. Les litiges complexes, tels que les cas de plaintes d’utilisateurs malveillants pour fraude à l’assurance, seraient jugés par un système judiciaire off-chain. En tirant parti du mécanisme d’assurance entièrement décentralisé fourni par API3 DAO, API3 pouvons pénaliser efficacement les fournisseurs de API et indemniser les utilisateurs touchés dans toute la mesure du possible.

5. Une plongée en profondeur dans la tokénomique de API3 DAO

La tokenomics de API3 DAO fonctionne de manière stable grâce à son mécanisme de jalonnement, en tirant parti des boucles de rétroaction positives et négatives.

5.1 Staking Mécanisme de gouvernance

Le mécanisme de staking est une pratique courante dans la gouvernance DAO, impliquant le profit du staking et la gouvernance du staking, servant de point de départ à une économie circulaire. API3 a encore optimisé ce processus :

• Que se passe-t-il si les stakers se retirent après avoir reçu des récompenses de staking ? Les récompenses inflationnistes générées par le jalonnement (jetons nouvellement frappés) sont retardées avant d’être distribuées et refluent par défaut dans le pool de jalonnement.
• À quoi d’autre les tokens du pool de staking peuvent-ils être utilisés ? Ils peuvent être utilisés pour compenser les pertes subies par les utilisateurs.
• Comment API3 stabilise-t-il le prix du jeton dans le pool de jalonnement ? L’API3 contrôle l’inflation grâce aux mécanismes de gravure et de verrouillage des jetons : les utilisateurs doivent graver ou verrouiller leurs jetons pour obtenir des services dAPI.

5.2 Boucle de rétroaction positive et négative Compte tenu de cette boucle de rétroaction positive et négative, quelle tendance la quantité de jetons dans le pool de jalonnement présentera-t-elle ? Une expansion incontrôlée ou des fonds insuffisants pour couvrir les indemnités conduiront-ils à l’effondrement ? Analysons :

• Lorsque le nombre d’utilisateurs de dAPI augmente, le risque du système augmente (coûts d’exploitation hausse avec le nombre d’utilisateurs), leading à davantage d’événements de compensation. Par conséquent, les jetons dans le pool de pool de jalonnement diminuent (utilisés pour indemniser les utilisateurs affectés), ce qui entraîne des pertes pour les jalonneurs (et les gestionnaires) en raison d’une mauvaise gestion. Cependant, réduire les jetons dans le pool de jalonnement signifie également augmenter le flux de jetons sur le marché. Étant donné que les jetons détenus par les utilisateurs sont affectés par l’inflation, une partie importante revient toujours au pool de jalonnement en raison de considérations d’intérêt personnel des utilisateurs.
• Lorsque le nombre d’utilisateurs de dAPI diminue, le risque système diminue, ce qui entraîne une augmentation progressive des jetons dans le pool de jalonnement, ce qui rend les jetons plus rares sur le marché. Néanmoins, cela n’implique pas une augmentation perpétuelle du nombre de tokens du pool de staking ; API3 DAO ajuste dynamiquement les récompenses de jalonnement (et les taux d’inflation) pour les aligner sur une valeur saine ciblée.

Les deux scénarios décrits ci-dessus forment une boucle de rétroaction positive et négative, bien représentée dans le diagramme de gauche (a). Lorsque l’un ou l’autre scénario atteint un seuil, le système s’ajuste automatiquement. Les utilisateurs de dAPI ont tendance à se stabiliser, comme le montre le diagramme de gauche (b), leading finalement le système vers un état opérationnel sain.

En fait, les jetons de gouvernance de style DAO comme ceux-ci ont longs été populaires dans divers protocoles DeFi. Par exemple, dans la mise en œuvre détaillée des stablecoins décentralisés, le DAI de MakerDAO sert de référence avec MKR comme jeton de gouvernance pionnier.

Son mécanisme à quatre enchères est particulièrement élégant. Pour en savoir plus, reportez-vous à "Une explication complète : AAVE, le leader DeFi et la dernière proposition de stablecoin GHO», en particulier la section « Sous-garantie, quatre ventes aux enchères ». Par conséquent, la gouvernance DAO est le mode opérationnel principal pour la stabilité économique, mais les innovations d’API3 sont également remarquables.

6.1 La naissance de l’OEV

L’OEV (Oracle Extractable Value) fonctionne de la même manière que MEV (Mineur Extractable Value). Il s’agit de la capacité de l’oracle à capturer de la valeur qui, autrement, serait attribuée à des tiers. Alors que MEV capture de la valeur par le biais de l’ordre des transactions, OEV exploite les écarts de prix entre les données on-chain et off-chain, en particulier dans les données de marché critiques ou les événements on-chain importants tels que les liquidations.

Pour comprendre comment l’OEV se produit, il faut être conscient des problèmes actuels avec les oracles. En raison du coût de off-chain soumission de données, les oracles utilisent généralement des téléchargements de données périodiques à des intervalles relativement short. Pour atténuer l’impact des fortes fluctuations de prix, les oracles fixent souvent des seuils déclenchant des mises à jour proactives lorsque les mouvements de prix dépassent ces limites. Bien que ces mesures atténuent certains problèmes, elles ne résolvent pas fondamentalement le problème de latence associé aux téléchargements de données.

DeFi marchés sont très volatils et les prix des actifs peuvent varier considérablement au cours de short périodes. Le mécanisme d’alimentation des oracles introduit de l’incertitude sur les marchés DeFi. En exploitant ce délai dans les mises à jour des données, les entités à la recherche de profit peuvent tirer parti de l’OEV. Pour les dApps qui dépendent d’oracles, tout retard ou mise à jour du flux de données peut potentiellement créer des opportunités pour les OEV, telles que le frontrunning, l’arbitrage et les liquidations.

Il peut être difficile d’attribuer la propriété de la valeur exploitable découlant des retards de flux de données. Les téléchargements de données ont intrinsèquement des fluctuations, de sorte que les retards ne peuvent pas toujours être attribués à une intention malveillante de la part de l’oracle. Par conséquent, la valeur exploitable générée par de tels retards ne peut pas nécessairement être considérée comme créée de manière malveillante par l’oracle.

6.2 OEV Network - Une plate-forme d’enchères multipartite

En raison de l’existence d’OEV, les utilisateurs et les dApps, en tant que parties en interaction, voient leur valeur extraite par des tiers, ce qui n’est clairement pas souhaitable pour les deux. L’API3 a identifié la nécessité de rejeter de manière préventive la capture du pouvoir de fixation des prix de toutes ces fuites (pouvoir de fixation des prix des données hors chaîne), d’où la proposition du réseau OEV. En tant que réseau basé sur le cumul Polygon zk, il s’agit d’une plate-forme d’enchères indépendante de flux de ordre (l’intention de tout participant de changer l’état de la blockchain est un ordre) pour le droit de mettre à jour les données dAPI. API3 a développé la plate-forme d’enchères elle-même, éliminant la dépendance aux services externes, permettant aux parties prenantes de partager l’OEV sans partager les bénéfices avec la plate-forme d’enchères et internalisant l’OEV dans tous les flux de données blockchain intégrés. Le gagnant de l’enchère obtient le droit de mettre à jour les données dAPI, la plupart des bénéfices de l’enchère étant reversés à la dApp et une petite partie conservée par API3 pour couvrir les coûts opérationnels. De toute évidence, lorsque le commissaire-priseur (tiers) estime que la vente aux enchères a coûté < profit de la mise à jour des prix, il participera à la vente aux enchères, ce qui la rendra également rentable pour les tiers. Bien que les utilisateurs de la plate-forme dApp puissent sembler ne pas participer à la participation aux bénéfices, ils bénéficient de la source de données de qualité fournie par dAPI pour un meilleur trading et une meilleure gestion des risques, ce qui en profite potentiellement. Le cycle de vie de l’enchère est illustré dans le diagramme ci-dessous. Lorsqu’un chercheur découvre un OEV, il lance une enchère d’enchères. L’enchérisseur gagnant obtient le droit de mettre à jour les données dAPI du nœud oracle et, après avoir payé les frais d’enchères, il peut exercer ce droit pour mettre à jour les données dAPI du nœud oracle. Les frais d’enchères payés correspondent à l’OEV capturé qui est transféré à la dApp.

La tendance des enchères implique naturellement que des tiers (chercheurs) augmentent les prix d’enchères à la recherche de profits potentiels. Un prix d’enchère plus élevé signifie une différence plus faible entre l’OEV réel et l’OEV capturé. En ce qui concerne l’ampleur de cette opportunité, nous devrons attendre de voir si le réseau de test s’est stabilisé pendant un certain temps avant de porter un jugement. Les résultats des enchères créent une situation gagnant-gagnant pour les dApps, les nœuds oracle API3, les tiers et les utilisateurs de dApp. Les dApps intégrant des sources de données API3 minimisent la laine tirée par des tiers tout en capturant la majeure partie de la valeur OEV. En fin de compte, la concurrence sur le marché entre les tiers garantit que les bénéfices sont progressivement comprimés, ce qui profite aux dApps en fin de compte. Pour l’API3, une petite partie de la valeur OEV prend en charge le chemin opérationnel de l’OEV. Les tiers reçoivent également une part. Pour les utilisateurs de dApp, le fait d’inciter des participants tiers hautement spécialisés à déterminer le moment optimal pour la mise à jour de off-chain points de données améliore la granularité, ce qui profite aux utilisateurs de dApp à la long exécution. Ainsi, le système d’enchères OEV d’API3 traite au maximum de la distribution des intérêts dans un jeu multipartite, en redirigeant les « profits mal placés » des tiers vers les parties prenantes concernées. Une telle solution est élégamment conçue. Pour en savoir plus, explorez « Rapport de recherche UniswapX (Partie I) : Résumé du parcours de développement de la V1-3, Comprendre les principes de l’innovation et les défis de la prochaine génération DEX. »

7. Conclusion

API3 a construit un écosystème autonome basé sur l’économie de ses jetons, en utilisant des mécanismes de rétroaction positifs et négatifs pour stabiliser les opérations. Dans le même temps, le réseau OEV introduit par API3 résout intelligemment le problème du flux OEV grâce à un mécanisme d’enchères pour les mises à jour de tarification dAPI, déplaçant habilement les conflits découlant de l’OEV entre les oracles et les dApps sur des tiers.

Au fur et à mesure que les applications décentralisées prolifèrent et mûrissent, la demande de services oracle fiables et sécurisés devrait augmenter, signalant l’émergence de la prochaine génération d’oracles. Cependant, API3 fait face à plusieurs défis. Les modèles économiques, même bien conçus au départ, peuvent avoir du mal à assurer la stabilité à long terme, devenant souvent la proie d’une gouvernance excessive ou d’une négligence. En outre, les enchères d’API, qui dépendent de la réputation et des bénéfices, sont intrinsèquement optimistes plutôt que des modèles pessimistes (comme ZK). Malgré l’utilisation par LayerZero d’une structure de réputation similaire et son fonctionnement continu sans problèmes de marché, même dans des combinaisons à haut risque comme les oracles et les bridges cross-chain, les risques persistent.

La poursuite des paris sur la réputation implique que les rendements du marché des participants doivent être suffisamment élevés et étroitement liés au développement du marché d’API3. En fin de compte, la difficulté du marché des oracles réside dans le fait que les DApps donnent la priorité non seulement aux capacités de fourniture de données, mais aussi au positionnement de l’oracle lui-même en tant que tiers. API3 a perturbé ce paradigme, mais des inquiétudes subsistent lorsque les DApps elles-mêmes participent à des enchères, soulevant des questions sur une collusion potentielle malgré la mise en jeu de leur propre réputation. Des acteurs établis comme Chainlink sont également capables de sortir plus d’OEV pour maintenir leur domination sur le marché.

十四君],. Tous les droits d’auteur appartiennent à l’auteur original [十四君]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn, et ils la traiteront rapidement.

Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.

Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.