Livraison de données basée sur l'intention : pourquoi cela importe et comment cela fonctionne

Les oracles dans le contexte des blockchains doivent apporter des données de l'extérieur de la blockchain vers le monde de la blockchain. Dans notre [article précédent], nous avons discuté des trois types d'oracles différents : l'oracle pull, l'oracle push et notre nouvel oracle basé sur l'intention.

Résumé rapidement de leur fonctionnement, afin qu'il devienne évident pourquoi nous avons besoin d'un nouveau type d'oracle, celui basé sur l'intention.

Oracles Push

L'« oracle push » est probablement l'idée la plus ancienne. Avec un oracle push, les données sont facilement disponibles sur la chaîne et sont mises à jour après un certain temps ou lorsque un seuil est atteint. Par exemple, un composant hors chaîne observe la température moyenne à Paris. Il fait 25°C au début et écrit ce point de donnée sur la chaîne. Maintenant, tout le monde sur la chaîne peut accéder à ces données. Il peut y avoir une règle selon laquelle les données sont mises à jour sur la chaîne lorsque la température change de 1°C ou après 60 minutes, ce qui est appelé un « heartbeat », pour savoir que l'oracle fonctionne en général. Supposons maintenant que la température change à 25,6, 25,7, 25,8°C, mais rien ne change sur la chaîne. Hors chaîne, la tendance devient très évidente. Elle atteint finalement 26°C et une transaction est envoyée à la blockchain pour mettre à jour la température dans le contrat oracle dit.

La partie importante est de comprendre ce qui se passe là : la transaction est envoyée, mais elle n'est pas immédiatement visible sur la chaîne. Elle doit d'abord être minée ou confirmée. En fait, puisque toutes les informations sont publiques, il est connu quel sera le nouveau point de donnée avant que la transaction ne soit confirmée.

Imaginons qu'il existe un grand marché des dérivés sur chaîne utilisant ces données où vous pouvez parier sur la température. Cela pourrait être aussi simple que : vous pariez que la température va augmenter, mais vous pouvez toujours sortir de votre position. Si vous avez déjà négocié des options, cela pourrait sembler très familier. Imaginez que vous pariez sur des températures en baisse et que vous voyez qu'il y a une nouvelle transaction à venir avec des températures plus élevées qui pourraient rendre votre position invalide. Vous pouvez simplement envoyer une transaction avec un gaz plus élevé pour devancer la mise à jour de l'oracle, la faire confirmer avec l'ancienne température de 25°C juste avant que l'oracle ne se mette à jour à 26°C.

Ainsi, les données ne sont pas en temps réel, selon n'importe quel critère commun qui définit le terme « en temps réel ». Les données sont principalement obsolètes et sont publiques et visibles avant d'être confirmées.

Même avec des seuils de plus en plus petits, et/ou des « heartbeats » de plus en plus rapides, cette architecture ne s'échelonne pas bien. Allons à l'extrême et disons que nous voulons amener les données traditionnelles d'actions américaines sur chaîne. Il n'est pas rare qu'une action soit négociée plusieurs milliers ou dizaines de milliers de fois par seconde, modifiant légèrement le prix de quelques centimes à la hausse et à la baisse. Sur Ethereum, une transaction (actuellement) est confirmée toutes les ~14 secondes. Sur Polygon, c'est beaucoup plus rapide. Ce n'est pas le débit de transaction qui compte, mais aussi le temps de confirmation. Des dizaines de milliers de mises à jour par seconde - et par marché - sont irréalisables avec cette architecture. La mise à jour des informations sur chaîne par une approche push ne fonctionne tout simplement pas si les données doivent être sur la chaîne en temps réel. En dehors de la congestion du réseau, un simple calcul sur le coût de toutes les transactions, même si elles sont à 0,001 cent par transaction, ne pourra pas gérer toutes les mises à jour de prix avec un taux d'échantillonnage suffisamment élevé pour satisfaire les entreprises qui dépendent des données en temps réel.

Oracles Pull

C'est ici que les oracles pull interviennent. Un oracle pull renverse le problème de la dépendance aux données. Au lieu de rendre les données facilement disponibles sur la chaîne, un oracle pull les rend facilement disponibles hors chaîne avec des mécanismes de signature pour pouvoir vérifier que les données sont valides.

Vous vous abonnez à un flux de données http/websocket régulier. Vous recevez des mises à jour en temps réel. Et lorsque vous avez besoin d'un prix, vous utilisez les données dans votre propre transaction. Les données vous sont fournies de manière à ce que vous ne puissiez pas altérer les données.

Revenons à l'exemple avec la température et le pari sur la température. Il y a l'Oracle (O), le Participant ou Utilisateur (U) et le Marché (M).

O possède les données. U souhaite trader sur M. Au lieu de requêter les données sur la chaîne, l'Utilisateur U obtient la température de O hors chaîne. Mais O n'envoie pas simplement la température actuelle, il l'envoie avec une signature cryptographique afin que M (ou quiconque d'autre) puisse vérifier qu'elle n'a pas été altérée. Maintenant, l'Utilisateur envoie la transaction sur la chaîne contenant les données de l'Oracle au Marché, qui peut alors confirmer que le point de données provient réellement de l'oracle hors chaîne et vous permet de trader ce que vous souhaitez trader.

Cela évolue bien, mais introduit deux autres problèmes très importants :

1. Du côté Utilisateur/Marché, l'Utilisateur peut voir les données avant qu'elles ne soient envoyées. L'utilisateur requête les données et, bien qu'il ne puisse pas altérer (modifier) les données, il peut décider d'envoyer la transaction ou non.
2. Les données sont publiquement disponibles, ce qui pose un problème pour la licence de données et les droits sur les données. Beaucoup de données, en particulier les données financières, sont étroitement licenciées pour la distribution, l'affichage et d'autres droits. Si l'oracle lui-même a besoin que les données soient visibles et les distribue via un socket, cela signifie généralement que les fournisseurs de données traditionnels ne peuvent pas (et ne voudront pas) fournir des données par le biais de cet oracle.

L'Oracle Morpher est différent des deux approches.

Le système basé sur l'intention s'appuie sur l'abstraction de compte, également connue sous le nom d'ERC4337. L'ERC4337 en lui-même n'a rien à voir avec les oracles, mais c'est la technologie que Morpher utilise pour construire sa technologie d'oracle afin de résoudre les deux problèmes restants des oracles pull.

Abstraction de Compte : une brève plongée approfondie

L'abstraction de compte résout un problème non lié aux oracles, mais un problème de longue date pour les systèmes basés sur l'EVM (Ethereum Virtual Machine). 

Avec les systèmes basés sur l'EVM, une transaction envoyée nécessite du "gaz" - quelqu'un qui paie pour la transaction. Les transactions ne sont pas gratuites et constituent une partie économique cruciale du fonctionnement de la blockchain et du paiement de ses validateurs ou mineurs. 

Dans les systèmes EVM actuels, il existe deux types de comptes : EOA (comptes détenus de manière externe) et comptes de contrat. Les EOA sont ceux que vous voyez généralement dans votre portefeuille, contrôlés par une clé privée. Les comptes de contrat sont des contrats intelligents. 

Sur Ethereum, seuls les EOA peuvent payer pour les transactions. Et cela ne peut pas être délégué. Je ne peux pas dire : « Je veux envoyer cette transaction, mais je veux que [autre compte] paie pour cela ». Ce problème a été tenté de le résoudre pendant des années en créant une construction appelée « abstraction de compte ». Ce terme signifie généralement que la ligne entre les EOA et les contrats devient floue, où peut-être les contrats peuvent payer eux-mêmes pour les transactions. 

Dans les premiers brouillons de l'abstraction de compte (il y a eu de nombreux brouillons qui n'ont jamais été mis en production), un contrat pouvait payer pour des transactions. Mais il s'avère que c'est un problème très complexe à résoudre, nécessitant des changements profonds dans l'architecture de la blockchain et des nœuds eux-mêmes, nécessitant probablement un certain nombre de hard forks et de mises à jour disruptives et généralement le consentement de la communauté.

Ensuite, une autre proposition est venue - la proposition numéro 4337, ou ERC4337. Ici, aucun changement à la blockchain elle-même n'était nécessaire. C'était entièrement compatible avec les versions antérieures et relativement facile à mettre en œuvre. 

L'idée était d'utiliser un certain nombre de mécanismes de signature différents et des participants hors chaîne et en chaîne pour déléguer l'envoi de la transaction. 

Chacun des participants aurait une fonction distincte et ne pourrait soit pas altérer les données, soit, principalement par théorie des jeux, ne pas vouloir retenir des données.

Faisons un exemple concret.

Dans le monde de l'ERC4337, il existe plusieurs participants. 

1. Il y a vous, l'utilisateur qui souhaite envoyer une transaction. 
2. Il y a un bundler, qui est un logiciel prenant en charge les opérations utilisateur, très similaires aux transactions régulières, mais encore impayées. 
3. Il y a un paymaster, qui est quelqu'un qui pourrait payer pour votre transaction. C'est la partie cruciale où vous pouvez déléguer le paiement des transactions à quelqu'un d'autre. Cette personne peut alors s'assurer qu'elle est payée par vous soit hors chaîne, soit directement et de manière transparente en chaîne. 
4. Il y a un point d'entrée, qui est un contrat intelligent validant principalement les signatures et s'assurant que tout le monde est correctement payé. 
5. Il y a un portefeuille en chaîne, un soi-disant compte intelligent, qui est encore un autre contrat intelligent. Les comptes intelligents existaient déjà avant l'ERC4337 et sont développés en parallèle ou indépendamment de l'abstraction de compte, ils se complètent simplement. Ce sont des contrats intelligents qui se comportent comme des portefeuilles réguliers, contrôlés par un compte détenu de manière externe (un compte contrôlé par une clé privée). 
6. Ensuite, il y a le contrat final avec lequel vous souhaitez interagir.

La partie cruciale de l'ERC4337 est que ce n'est pas vous, avec votre compte détenu de manière externe, qui interagissez avec le contrat final, mais vous demandez à votre portefeuille en chaîne d'interagir avec le contrat final que vous souhaitez utiliser.

En général, la recommandation commune est d'utiliser des portefeuilles en chaîne plutôt que des EOA, que vous utilisiez ou non l'abstraction de compte. Par exemple https://safe.global/ : cela présente de nombreux avantages, tels que l'autorisation multi-signature, la récupération sociale et bien d'autres. Bien que cela dépasse le cadre de cet article, le mouvement se dirige vers des portefeuilles en chaîne.

Pour notre exemple, disons que vous souhaitez envoyer 1 ETH de votre portefeuille intelligent à quelqu'un d'autre. Mais au lieu d'interagir directement avec votre portefeuille intelligent, vous souhaitez l'envoyer de manière « sans gaz ». Cela signifie que votre EOA pourrait avoir 0 ETH pour payer la transaction, mais vous souhaitez quand même demander à votre portefeuille en chaîne de quelque manière que ce soit d'envoyer les 1 ETH de lui-même à quelqu'un d'autre en votre nom.

Cela fonctionne en créant une UserOperation (userOp). Une userOp ressemble très structurellement à une transaction régulière.

Examinons cela de plus près pour une meilleure compréhension :

1. Il a un expéditeur, qui est votre compte intelligent. 
2. Il a un nonce, qui est un nombre en constante augmentation. Très similaire à une transaction normale, cependant, au lieu de le récupérer auprès des nœuds de la blockchain, vous l'obtenez auprès du point d'entrée. 
3. Il a un initCode, qui crée un compte intelligent (portefeuille en chaîne) si vous n'en avez pas encore un. 
4. Il a un callData, qui est similaire à la partie de données d'une transaction régulière. Cette partie demande à votre portefeuille intelligent de faire quelque chose en votre nom.
5. Ensuite, il a un certain nombre de variables de gaz pour déterminer combien payer au bundler. 
6. Ensuite, il y a un paymaster, qui est un autre participant qui pourrait payer pour la transaction.
7. La signature est un mécanisme cryptographique pour rendre la userOp à l'abri des falsifications. C'est un schéma de signature de message du compte détenu de manière externe, où il signe l'ensemble de la userOp sans l'envoyer en tant que transaction.

Ensuite, nous avons terminé. Celle-ci est envoyée au bundler.

Un bundler est un logiciel qui a essentiellement un seul but : il prend des userOps (une ou plusieurs d'entre elles, c'est important !), les regroupe dans une véritable transaction qu'il paie et les envoie au point d'entrée. Le bundler n'est pas une œuvre de charité, il n'envoie pas les userOps sans être payé. C'est là que les variables de gaz dans la userOp entrent en jeu. Le point d'entrée utilise ces variables pour déterminer combien « rembourser » le bundler. 

Comme cela est connu à l'avance, le bundler peut également vérifier avant d'envoyer la transaction réelle qu'il est suffisamment payé (au moins autant que le coût d'envoi de la transaction réelle). Faire fonctionner un bundler devrait être une opération économiquement viable après tout.

Ensuite, le point d'entrée transmet l'intention de l'utilisateur avec le callData à l'expéditeur (le portefeuille intelligent de l'utilisateur) et le portefeuille intelligent exécute l'action que l'utilisateur souhaitait effectuer. Bien sûr, tout est signé, double signé et triple signé, donc personne ne peut altérer les données. Puisque tout le monde est payé en cours de route avec un petit mais joli bénéfice, il n'y a également aucune raison de croire qu'ils chercheraient à s'entendre pour retenir une transaction.

Les bundlers eux-mêmes sont connectés via un pool où ils partagent les opérations utilisateur en attente, similaire à un pool de transactions réel sur Ethereum.

La partie intéressante pour l'oracle est : un bundler peut envoyer une ou plusieurs userOps dans la même transaction. Ainsi, c'est une transaction qui regroupe plusieurs userOps.

L'Oracle Morpher

C'est ce que l'Oracle Morpher utilise pour injecter une information de prix ou un point de données dans le système.

Dans un schéma d'abstraction de compte régulier, l'utilisateur interagit avec un agrégateur en envoyant une requête POST à une certaine URL. L'agrégateur prendrait cette userOp et l'ajouterait à sa file de transactions.

Dans l'Oracle Morpher, l'utilisateur interagit également avec un agrégateur, cependant, au lieu d'envoyer une UserOp, l'utilisateur envoie une requête légèrement différente, qui est une DataOp.

La dataOp ressemble exactement à la userOp, mais avant d'envoyer la transaction à l'endpoint de cette manière, l'agrégateur injectera ce point de données en tant que userOp avant la véritable userOp de l'utilisateur. Cela est déterminé par le contrat avec lequel l'utilisateur interagit, qui peut spécifier une nouvelle exigence pour l'interaction :

Du côté hors chaîne, avant d'envoyer la transaction, cela est vérifié et il est alors déterminé que le contrat a besoin de données supplémentaires et celles-ci sont injectées en tant que userOp.

C'est une opération atomique, il n'y a pas deux transactions, mais une seule transaction envoyée au point d'entrée avec deux (ou plusieurs) userOps. La première userOp met à jour l'oracle, très similaire à un oracle push, mais basé sur l'intention, où les données sont effectivement en temps réel du point de vue de l'utilisateur. La seconde userOp est la userOp de l'utilisateur qui interagit ensuite avec son portefeuille intelligent, qui interagit avec le contrat final, qui lit les données de l'oracle depuis le contrat oracle.

L'oracle lui-même peut s'assurer qu'il est également rémunéré par un schéma de paiement similaire, transparent et en chaîne, où l'interaction avec l'oracle n'est alors pas gratuite.

Les données ne sont pas seulement à l'abri des falsifications du point de vue de l'utilisateur et du contrat final. Il n'est également pas possible de retenir des données, car elles sont privées. Un utilisateur ne peut pas voir les données avant qu'elles ne soient envoyées au contrat final en chaîne. De plus, la plupart, sinon la totalité, des problèmes de licence pour les fournisseurs de données sont résolus, car les données restent privées. Il n'est pas nécessaire d'avoir des droits d'affichage ou des droits de distribution. Les données restent lisibles uniquement pour le contrat final qui a besoin du point de données et qui en paie le prix.

Vous êtes curieux de voir comment fonctionnent les oracles basés sur l'intention ? Découvrez-le en direct sur Morpher Oracle.

Souhaitez-vous approfondir la discussion ? Rejoignez notre groupe Telegram.

Avertissement : Tous les investissements comportent des risques et les performances passées d'un titre, d'un secteur, d'un marché, d'un produit financier, d'une stratégie de trading ou des transactions d'un individu ne garantissent pas les résultats ou les rendements futurs. Les investisseurs sont entièrement responsables de toutes les décisions d'investissement qu'ils prennent. Ces décisions doivent être basées uniquement sur une évaluation de leur situation financière, de leurs objectifs d'investissement, de leur tolérance au risque et de leurs besoins en liquidités. Ce post ne constitue pas un conseil en investissement.