Editeur | Wu parle de blockchain

Ce qui suit est un résumé du podcast Wu Speaks English

Veuillez écouter la version complète :

https://www.youtube.com/watch?v=6HskTaYR4vU

Pouvez-vous nous donner un bref historique de l'API3 et de la manière dont le réseau OEV a été lancé ?

API3 est un projet Oracle issu de l'expérience antérieure des fondateurs dans l'exécution de nœuds ChainLink et de leur quête de conception d'un système plus efficace, plus simple et vérifiable. Cela a conduit à la création de l'API3. Les oracles ont un large éventail d'applications, le cas d'utilisation le plus connu étant la fourniture de prix, un besoin clé dans le domaine de la finance décentralisée (DeFi). Actuellement, les offres de prix ne génèrent pas de revenus importants, car l'opération est principalement subventionnée par la vente de ses propres jetons pour soutenir les projets Oracle proposés ou par l'investissement de millions de dollars dans ces services via le réseau. C'est pourquoi l'API3 met fortement l'accent sur l'identification des segments de marché autosuffisants qui permettent à un projet Oracle d'être financièrement viable. Cette approche ouvre la voie au lancement du réseau OEV, en se concentrant sur la création d'un modèle où la fourniture de services Oracle peut elle-même être rentable.

Qu'est-ce que l'OEV (Oracle Extractable Value) ? Pourquoi c'est important?

La valeur extractible Oracle (OEV) est un type spécifique de valeur extractible par mineur (MEV) qui se concentre sur l'impact des mises à jour Oracle, ou leur absence, dans les systèmes blockchain. Semblable au MEV, où les mineurs peuvent prioriser les transactions pour un gain personnel, OEV implique de prioriser stratégiquement les transactions oracle pour extraire de la valeur, en particulier dans les scénarios où les oracles fournissent des données de marché critiques ou déclenchent des événements majeurs en chaîne tels que des liquidations.

À quoi sert la création de Zk-rollup ?

Au départ, le concept de passer à un système basé sur le cumul, notamment dans le contexte des ralentissements MEV (Miner Extractable Value) et des mises à jour d'Oracle, semblait non conventionnel. Cependant, reconnaître la nature centralisée des solutions MEV existantes telles que Flashbots, MEV Share ou MEV Blocker nécessite clairement un changement. Ces solutions fonctionnent sur des serveurs centralisés et exigent que les utilisateurs accordent une grande confiance à leurs opérations, ce qui contredit la philosophie décentralisée de la technologie blockchain.

Notre première approche de vente des mises à jour d'Oracle reposait également sur des serveurs centraux, créant un système dans lequel les utilisateurs devaient non seulement nous faire confiance pour exécuter les mises à jour, mais également nous faire confiance pour gérer de grandes quantités de fonds en raison des exigences de garantie requises pour participer. Cette configuration soulève des hypothèses de confiance considérables, notamment en ce qui concerne la légitimité du processus d'enchères de mise à jour d'Oracle, qui manque de transparence et de vérifiabilité.

L'utilisation de rollups permet des interactions plus confidentielles, permettant aux utilisateurs de transférer leurs garanties sur la plateforme sans nous donner le contrôle total de leurs fonds. De plus, il fournit un enregistrement en chaîne de la participation aux enchères, des gagnants et de l'exécution des mises à jour, réduisant considérablement les hypothèses de confiance. Avec les rollups, l'ensemble du processus devient transparent et vérifiable, ce qui réduit le besoin pour les utilisateurs d'accorder une confiance indue à l'intégrité de l'API3 ou au processus d'enchères. Cette approche est plus conforme au principe de décentralisation de la blockchain et garantit que les utilisateurs peuvent participer au système avec plus de confiance et de sécurité.

Pourquoi choisir Polygone ?

Nous avons choisi Polygon en raison de notre partenariat solide avec eux et de notre confiance dans le développement futur de la technologie Zero Knowledge Proof (ZK). Nous avons pris cette décision sur la base de notre compréhension approfondie de la machine virtuelle Ethereum (ZK EVM) sans connaissance de Polygon et de la reconnaissance de la forte demande de services Oracle dans son écosystème. La volonté de Polygon de commercialiser sa solution ZK lui confère un net avantage sur les autres plates-formes et c'est la principale raison pour laquelle nous avons choisi de travailler avec elles.

Quel rôle le token API3 jouera-t-il dans le réseau OEV ?

Dans le réseau OEV, les enchérisseurs retenus doivent payer une commission supplémentaire de 10 % en plus de leur offre, qui va directement à l'API3. Ce modèle diffère légèrement du scénario MEV typique, dans lequel 90 % de la valeur extraite est restituée à l'utilisateur et 10 % appartiennent au fournisseur de services MEV. Dans le cas d'API3, le montant total de l'offre profite à l'application, tandis que les frais supplémentaires de 10 % sont divisés en deux, la moitié étant détenue par API3 en tant qu'organisateur de l'enchère et l'autre moitié étant attribuée au fournisseur Oracle.

API3 utilise sa part des frais pour les rachats et les brûlages de jetons, une stratégie détaillée dans le livre blanc. Cette approche vise à réinvestir les revenus directement dans l'écosystème de jetons API3. Par exemple, un contrat a été élaboré qui utilise les frais collectés pour acheter des jetons API3, fournir des liquidités sur Uniswap et, finalement, tout reconvertir en API3 pour destruction après un an. Cette approche vise à augmenter la liquidité et la valeur des jetons API3, en alignant les intérêts des participants au réseau sur la santé et le succès à long terme de l'écosystème.

Le réseau API3 OEV utilise un modèle de source de données propriétaire, pourquoi ?

Les modèles Oracle tiers et propriétaires impliquent l'agrégation de données, mais la principale différence réside dans la source des données et les hypothèses de confiance requises. Dans les modèles Oracle tiers, comme celui principalement utilisé par Chainlink (et certains oracles propriétaires également), les données sont obtenues indirectement. Par exemple, si j'exploite un nœud et prétends obtenir mes prix auprès de CoinGecko, tout consommateur de données doit non seulement faire confiance à CoinGecko, mais également me faire confiance en tant qu'intermédiaire. Cette configuration introduit un niveau de confiance supplémentaire et des coûts potentiels, car chaque participant à la chaîne de fourniture de données doit être rémunéré.

En revanche, les oracles propriétaires impliquent directement les données provenant du processus oracle. Les sources de données telles que CoinGecko exécutent elles-mêmes les oracles plutôt que par un intermédiaire, ce qui permet une fourniture de données vérifiables et directes. Cette approche réduit considérablement le nombre d’entités auxquelles les consommateurs doivent faire confiance et réduit les coûts globaux en supprimant les frais intermédiaires. Il en résulte un système plus efficace, plus rentable et rapidement déployable sur une variété de réseaux.

Cette efficacité est essentielle, d’autant plus que la fourniture de données de base, sans s’engager dans des activités telles que l’extraction MEV, n’est souvent pas rentable. Les projets Oracle fonctionnent souvent à perte, subventionnant les flux de données dans l'espoir d'une future appréciation symbolique, ou recherchant des subventions externes pour couvrir les coûts d'exploitation. En minimisant le nombre de parties impliquées et donc en réduisant les dépenses d'exploitation, les oracles de première partie offrent aux partenaires potentiels une solution plus attrayante, combinant efficacité avec des exigences de confiance réduites et des coûts réduits.

Quelles sont les relations de la théorie des jeux dans les enchères de flux d'ordres (OFA) ?

Essentiellement, lorsque vous négociez via une plateforme comme MEV Share, vos transactions ont le potentiel de créer de la valeur. Ce concept est utilisé dans les enchères de flux d'ordres où les gens peuvent enchérir sur la valeur générée par vos transactions. Les chercheurs MEV peuvent alors vous rémunérer avec une grande partie de la valeur extraite du packaging et de la vente de votre flux de transactions. Par exemple, un ordre de vente important peut déclencher une liquidation rentable, rendant votre transaction très précieuse pour les enchérisseurs qui sont en mesure de profiter de ces opportunités, vous rapportant ainsi un cashback substantiel.

Dans le contexte du réseau OEV, l'accent est mis sur les mises à jour Oracle plutôt que sur les transactions classiques. Nous participons aux enchères de flux de commandes spécifiquement pour ces mises à jour. Les soumissionnaires peuvent concourir pour avoir l'opportunité de lancer des mises à jour Oracle, les bénéfices provenant de l'application ou du protocole impliqués étant financés. Par exemple, un changement de prix mineur déclenchant une liquidation majeure pourrait représenter une opportunité de profit importante, incitant les gens à rivaliser pour le droit d'exécuter cette mise à jour Oracle.

Ce système reflète la dynamique observée dans les enchères traditionnelles de flux d'ordres sur le réseau principal Ethereum, où les liquidations et les mises à jour d'oracle peuvent générer une valeur significative. Cependant, notre approche est conçue pour garantir que les bénéfices soient répartis plus équitablement. En permettant au marché de déterminer la valeur des mises à jour Oracle, nous créons un environnement dans lequel les applications peuvent récupérer une plus grande partie des incitations généralement utilisées pour payer la compensation, réduisant ainsi considérablement les coûts.

En résumé, les mises à jour Oracle peuvent générer une valeur significative, il est donc essentiel de laisser le marché déterminer leur valeur. Actuellement, les mises à jour d'Oracle s'effectuent sans cette approche axée sur le marché, ce qui entraîne souvent des occasions manquées de récupérer de la valeur. Notre système vise à changer cela, en permettant potentiellement aux DApp de conserver une plus grande part des incitations qu'elles offrent.

Que se passe-t-il si les récompenses en cas de mauvaise conduite sont supérieures aux frais de service et aux amendes ?

Nous nous concentrons sur les oracles propriétaires car ils s'appuient sur une activité commerciale réelle, ce qui les rend responsables de leurs données. Si ces oracles se comportent mal, leurs actions sont enregistrées sur la blockchain, permettant un recours direct. API3 gère et surveille ces fournisseurs de données pour garantir le respect des normes de qualité. Les fournisseurs qui ne respectent pas ces normes seront remplacés pour garantir l'intégrité de la fourniture de données. Cette approche repose sur la confiance dans ces prestataires mais vise à minimiser la confiance par la transparence et la responsabilité. L’objectif est d’évoluer vers un système qui repose moins sur la confiance dans l’avenir.

Comment l’API3 rivalise-t-elle avec Chainlink et Python ? Quel est le but ultime ?

Nous ne nous concentrons pas principalement sur la valeur totale verrouillée (TVS) comme mesure de base, car la TVS ne contribue pas directement à la rentabilité. La raison en est que la fourniture de données opérationnelles, quelle que soit la taille du TVS, n’est actuellement pas une entreprise rentable : il n’existe aucun mécanisme direct permettant d’injecter la valeur récupérée de la fourniture de données opérationnelles dans des jetons. Que l'on protège 5 milliards ou 500 millions de dollars, les résultats financiers restent les mêmes : il n'y a pas de profit sur l'activité elle-même. Cette prise de conscience nous a amenés à nous concentrer sur le réseau OEV, qui offre un moyen de rapporter de l'argent aux projets et de générer réellement des revenus.

Le réseau OEV transforme les TVS en chiffres significatifs, s’éloignant d’un modèle construit sur « les espoirs et les rêves » en liant directement les efforts de sécurité aux revenus potentiels via des liquidations et d’autres mécanismes. Actuellement, le réseau OEV fonctionne parallèlement au flux de données API3, permettant des mises à jour et des sources de revenus supplémentaires. Nous envisageons d'étendre le réseau OEV à d'autres oracles, ce qui nous permettrait potentiellement de nous éloigner des aspects non rentables de la fourniture de données opérationnelles et de nous concentrer sur les opérations OEV rentables.

Sur de nombreuses plates-formes de deuxième niveau, la fondation sous-jacente subventionne la fourniture, ce qui signifie que les coûts réels sont souvent supportés par Chainlink Labs ou l'organisme directeur de deuxième niveau plutôt que d'utiliser les projets fournis. Dans une large mesure, la fourniture de données importantes et couramment utilisées ne génère pas de bénéfices directs pour les projets Oracle. Le passage à un réseau OEV représente une approche innovante pour créer de la valeur dans l'espace Oracle, en se concentrant sur les interactions rentables plutôt que de simplement sécuriser de grandes quantités de TVS sans retour financier direct.

Il n’est pas tout à fait exact de dire que les services Oracle comme Chainlink ne rapportent pas d’argent. Ils génèrent potentiellement des revenus en répercutant les coûts sur les réseaux qu'ils exploitent, comme Arbitrum, où la Fondation Arbitrum supporte ces coûts. La relation entre le volume d'utilisation du projet fourni et les revenus générés n'est souvent pas simple ; ces services sont souvent conçus pour couvrir les coûts d'exploitation plutôt que pour générer des bénéfices importants.

L'expansion dans de nouveaux domaines comme CCIP démontre une stratégie visant à créer de la valeur au-delà de la simple offre de prix, qui peut être considérée comme un outil de développement de marque ou une opération d'équilibre plutôt qu'un centre de profit. Les discussions sur la gouvernance au sein de ces projets révèlent souvent les défis financiers liés à l'exploitation des services Oracle, mettant en évidence les évolutions vers des solutions potentiellement plus rentables.

En quoi API3 est-il différent d’Ovale ? Quels sont les avantages par rapport à l’UMA ?

Oval est construit sur une infrastructure d'oracles et de Flashbots, démontrant un moyen de tirer parti de la valeur des mises à jour d'oracle en pré-vendant les droits de mise à jour. Cependant, il repose sur des composants centralisés et, en raison des limitations des Flashbots, sa portée de fonctionnement est limitée au réseau principal Ethereum, montrant un système avec des dépendances importantes.

API3 propose un modèle plus flexible qui fournit une solution complète au-delà de ce qu'Oval réalise. Il fournit des options pour utiliser les propres flux de données d'API3 pour obtenir des mises à jour plus précises ou pour augmenter d'autres oracles avec une granularité plus fine via le réseau OEV. Cette approche réduit la dépendance à l'égard d'un réseau ou d'une solution unique et vise à permettre une applicabilité plus large sur les blockchains sans les limitations imposées par les dépendances à l'égard de services tels que Flashbots.

Essentiellement, la stratégie d’API3 consiste à s’appuyer sur les frameworks Oracle existants, à fournir une granularité améliorée et à étendre le potentiel de capture de valeur sur plusieurs blockchains. Cette approche à multiples facettes vise à répondre à la complexité des services Oracle et à remédier aux limites des modèles actuels tout en explorant les voies vers une plus grande efficacité et une applicabilité plus large du réseau.

Par rapport à l'UMA, l'avantage de l'API3 est qu'elle met l'accent sur la création d'un fournisseur de données décentralisé et sur la réduction de la dépendance à l'égard des services centralisés et tiers. Le réseau OEV et la stratégie de fourniture de données d'API3 fournissent un flux de données plus décentralisé, transparent et vérifiable, ce qui est essentiel pour garantir l'équité et la sécurité des applications blockchain. En outre, l'API3 vise à fournir une solution compatible entre les chaînes, permettant une applicabilité et une flexibilité plus larges, tandis que l'UMA se concentre sur la fourniture d'éléments de base pour les contrats financiers décentralisés, qui peuvent présenter des différences en termes de champ d'application et de mise en œuvre technique.