Introduction

Et si vous perdiez la mémoire toutes les heures ? Et vous devez constamment demander à quelqu'un de vous dire ce que vous avez fait ? Tel est l'état actuel des contrats intelligents. Sur les blockchains comme Ethereum, les contrats intelligents ne peuvent pas accéder directement aux états au-delà de 256 blocs. Ce problème est encore exacerbé dans l'écosystème multichaîne, où la récupération et la vérification des données à travers les différentes couches d'exécution sont encore plus difficiles.

En 2020, Vitalik Buterin et Tomasz Stanczak ont proposé un moyen d'accéder aux données dans le temps. Alors que l'EIP est devenu stagnant, son besoin a refait surface dans le monde multichaîne centré sur les rouleaux. Aujourd'hui, les preuves de stockage ont émergé comme une frontière, pour donner de la conscience et de la mémoire aux contrats intelligents.

Accès aux données de la chaîne

Les dapps peuvent accéder aux données et à l'état de plusieurs manières. Toutes ces approches exigent que l'application fasse confiance à des personnes/entités, à une sécurité économique cryptographique ou à un code, et présentent certains compromis :

Confiance dans les humains/entités :

• Nœuds d'archivage : Les opérateurs peuvent gérer eux-mêmes un nœud d'archivage ou faire appel à des fournisseurs de services de nœuds d'archivage tels qu'Alchemy ou Infura pour accéder à toutes les données depuis le bloc Genesis. Ils fournissent les mêmes données qu'un nœud complet, mais aussi toutes les données historiques de l'ensemble de la blockchain. Les services hors chaîne comme Etherscan et Dune Analytics utilisent des nœuds d'archivage pour accéder aux données de la chaîne. Les acteurs hors chaîne peuvent attester de la validité de ces données, et les contrats intelligents sur chaîne peuvent vérifier que les données ont été signées par un acteur/comité de confiance. L'intégrité des données sous-jacentes n'est pas vérifiée. Cette approche exige que la dapp ait confiance dans le fait que le fournisseur de services du nœud d'archivage gère l'infrastructure correctement et sans intention malveillante.

Faites confiance à la sécurité économique de Crypto :

• Indexeurs : Le protocole d'indexation organise toutes les données de la blockchain, ce qui permet aux développeurs de créer et de publier des API ouvertes que les applications peuvent interroger. Les indexeurs individuels sont des opérateurs de nœuds qui mettent en jeu des jetons pour fournir des services d'indexation et de traitement des requêtes. Cependant, des litiges peuvent survenir lorsque les données servies sont incorrectes et la procédure d'arbitrage peut prendre du temps. En outre, les données provenant d'indexeurs tels que The Graph ne peuvent pas être directement utilisées par la logique commerciale des contrats intelligents et sont utilisées dans le contexte de l'analyse de données basée sur le web2.
• Oracles : Les fournisseurs de services Oracle utilisent les données agrégées de nombreux opérateurs de nœuds indépendants. La difficulté réside dans le fait que les données disponibles auprès d'Oracles peuvent ne pas être mises à jour fréquemment et que leur portée est limitée. Les oracles tels que Chainlink ne conservent généralement que des états spécifiques, tels que les flux de prix, et ne sont pas réalisables pour les états et les historiques spécifiques à une application. En outre, cette approche introduit également un certain niveau de déviation dans les données et nécessite la confiance dans les opérateurs de nœuds.

Code fiduciaire :

• Variables et fonctions spéciales : Les blockchains comme Ethereum ont des variables et des fonctions spéciales qui sont principalement utilisées pour fournir des informations sur la blockchain ou sont des fonctions d'utilité générale. Un contrat intelligent ne peut accéder qu'au hachage des 256 blocs les plus récents. Pour des raisons d'évolutivité, les hachages de blocs ne sont pas disponibles pour tous les blocs. Il serait utile d'avoir accès aux hachages de blocs historiques, car cela permettrait de vérifier les preuves qui s'y rapportent. Aucun opcode dans l'exécution de l'EVM ne permet d'accéder au contenu d'anciens blocs, à des transactions antérieures ou à des sorties de reçus, de sorte qu'un nœud peut oublier ces éléments en toute sécurité tout en étant en mesure de traiter de nouveaux blocs. Cette méthode est également limitée à une seule blockchain.

Compte tenu des difficultés et des limites de ces solutions, il est manifestement nécessaire de stocker et de fournir des hachages de blocs sur la chaîne. C'est là qu'interviennent les preuves de stockage. Afin de mieux comprendre les preuves de stockage, examinons rapidement le stockage des données dans les blockchains.

Stockage de données dans une blockchain

Une blockchain est une base de données publique qui est mise à jour et partagée par de nombreux ordinateurs au sein d'un réseau. Les données et l'état sont stockés dans des groupes consécutifs appelés blocs et chaque bloc référence cryptographiquement son parent en stockant le hachage de l'en-tête du bloc précédent.

Prenons l'exemple du bloc Ethereum. Ethereum utilise un type particulier d'arbre de Merkle appelé "Merkle Patricia tree" (MPT). Les en-têtes de blocs Ethereum contiennent les racines de quatre tentatives Merkle-Patricia différentes, à savoir Trie d'état, Trie de stockage, Trie de recettes et Trie de transactions. Ces 4 essais codent les mappages qui comprennent toutes les données Ethereum. Les arbres de Merkle sont utilisés en raison de leur efficacité dans le stockage des données. En utilisant des hachages récursifs, seul le hachage de la racine doit être stocké, ce qui permet d'économiser beaucoup d'espace. Ils permettent à quiconque de prouver l'existence d'un élément dans l'arbre en prouvant que le hachage récursif des nœuds aboutit au même hachage de la racine. Les preuves de Merkle permettent aux clients légers sur Ethereum d'obtenir des réponses à des questions telles que :

• Cette transaction existe-t-elle dans un bloc particulier ?
• Quel est le solde actuel de mon compte ?
• Ce compte existe-t-il ?

Au lieu de télécharger chaque transaction et chaque bloc, un "client léger" peut seulement télécharger la chaîne des en-têtes de blocs et vérifier les informations à l'aide de preuves de Merkle. Cela rend le processus global très efficace. Consultez ce blog de Vitalik et l'article de recherche de Maven11 pour mieux comprendre la mise en œuvre, les avantages et les défis associés aux Merkle Trees.

Preuves de stockage

Les preuves de stockage nous permettent de prouver que quelque chose est engagé dans la base de données et qu'il est également valide en utilisant des engagements cryptographiques. Si nous pouvons fournir une telle preuve, il s'agit d'une affirmation vérifiable que quelque chose s'est produit sur la blockchain.

Que peuvent permettre les preuves de stockage ?

Les preuves de stockage permettent deux fonctions principales :

1. Accédez aux données historiques de la chaîne au-delà des 256 derniers blocs, en remontant jusqu'au bloc d'origine.
2. Accéder aux données de la chaîne (historiques et actuelles) d'une blockchain sur une autre blockchain avec l'aide de la vérification du consensus ou du pont L1-L2 dans le cas des L2.

Comment fonctionnent les preuves de stockage ?

Les preuves de stockage vérifient à un niveau très élevé si le bloc spécifique fait partie de l'histoire canonique de la blockchain et vérifient ensuite si les données spécifiques demandées font partie du bloc. Cet objectif pourrait être atteint par les moyens suivants

• Traitement en chaîne : les applications pourraient prendre le bloc de confiance initial, transmettre le bloc en tant que données d'appel pour accéder au bloc précédent et remonter jusqu'au bloc d'origine. Cela nécessite beaucoup de calculs sur la chaîne et une grande quantité de données d'appel. Cette approche n'est pas du tout réalisable en pratique en raison de l'énorme quantité de calculs nécessaires sur la chaîne. Aragon a essayé d' utiliser l'approche "on chain" en 2018, mais cela n'a pas été possible en raison du coût élevé de l'approche "on chain".
• Utilisation de preuves ZK : L'approche est similaire au traitement en chaîne, à l'exception du fait que le prouveur ZK est utilisé pour déplacer le calcul complexe hors de la chaîne.

1. Accès aux données de la même chaîne : La preuve ZK peut être utilisée pour affirmer qu'un en-tête de bloc historique arbitraire est un ancêtre de l'un des 256 en-têtes de bloc les plus récents accessibles dans l'environnement d'exécution. L'autre approche consiste à indexer l'ensemble de l'historique de la chaîne source et à générer une preuve ZK pour prouver que l'indexation s'est déroulée correctement. Cette preuve est régulièrement mise à jour au fur et à mesure que de nouveaux blocs sont ajoutés à la chaîne source. Accès aux données entre les chaînes : Le fournisseur recueille les en-têtes de blocs de la chaîne source sur la chaîne de destination et atteste de la validité de ces en-têtes de blocs à l'aide de la preuve de consensus ZK. Il est également possible d'utiliser une solution AMP existante comme Axelar, Celer ou LayerZero pour interroger les en-têtes de blocs.
2. Un cache de hachages d'en-têtes de blocs de la chaîne source, ou le hachage racine d'un accumulateur de hachages de blocs hors chaîne, est conservé sur la chaîne de destination. Ce cache est mis à jour régulièrement et est utilisé pour prouver efficacement sur la chaîne qu'un bloc donné existe et qu'il a un lien cryptographique avec un hachage de bloc récent accessible à partir de l'état. Ce processus est connu sous le nom de preuve de la continuité de la chaîne. Il est également possible d'utiliser une blockchain dédiée pour stocker les en-têtes de blocs de toutes les chaînes sources.
3. Les données historiques/blocs sont accessibles à partir des données indexées hors chaîne ou du cache sur chaîne (en fonction de la complexité de la demande), conformément à la demande de l'application sur la chaîne de destination. Alors que le cache d'un hachage d'en-têtes de blocs est conservé sur la chaîne, les données réelles peuvent être stockées en dehors de la chaîne.
4. L'existence de données dans le bloc spécifié est vérifiée au moyen de preuves d'inclusion merkle et une preuve zk est générée. Cette preuve est combinée avec la preuve d'indexation correcte de ZK ou la preuve de consensus de ZK et la preuve est mise à disposition sur la chaîne pour une vérification sans confiance.
5. Les dapps peuvent alors vérifier cette preuve sur la chaîne et utiliser les données pour exécuter l'action souhaitée. Parallèlement à la vérification de la preuve ZK, les paramètres publics tels que le numéro de bloc et le hachage du bloc sont vérifiés par rapport au cache des en-têtes de bloc conservés sur la chaîne.

Parmi les projets qui adoptent cette approche, citons Herodotus, Lagrange, Axiom, Hyper Oracle, Brevis Network et nil foundation. Alors que des efforts considérables sont déployés pour rendre les applications conscientes de l'état de plusieurs blockchains, l'IBC (Inter Blockchain Communication) se distingue comme une norme d'interopérabilité qui permet des applications telles que ICQ (Interchain queries) et ICA (Interchain accounts). L'ICQ permet aux applications de la chaîne A d'interroger l'état de la chaîne B en incluant la requête dans un simple paquet IBC et l'ICA permet à une blockchain de contrôler en toute sécurité un compte sur une autre blockchain. En les combinant, il est possible d'obtenir des cas d'utilisation inter-chaînes intéressants. Les fournisseurs de RaaS comme Saga offrent ces fonctionnalités à toutes leurs chaînes d'applications par défaut en utilisant l'IBC.

Il existe de nombreuses façons d'optimiser les preuves de stockage afin de trouver le bon équilibre entre la consommation de mémoire, le temps de preuve, le temps de vérification, l'efficacité de calcul et l'expérience du développeur. Le processus global peut être divisé en trois sous-processus principaux.

• Accès aux données
• Traitement des données
• ZK Génération de preuves pour l'accès et le traitement des données

Accès aux données : Dans ce sous-processus, le fournisseur de services accède aux en-têtes de blocs de la chaîne source de manière native sur la couche d'exécution ou en maintenant un cache sur la chaîne. Pour l'accès aux données entre les chaînes, il est nécessaire de vérifier le consensus de la chaîne source sur la chaîne de destination. Voici quelques-unes des approches et des optimisations adoptées :

• La blockchain Ethereum existante : La structure existante de la blockchain Ethereum peut être utilisée pour prouver la valeur de n'importe quel emplacement de stockage historique par rapport à la tête de bloc actuelle en utilisant ZKP. On peut considérer qu'il s'agit d'une grande preuve d'inclusion. Il est prouvé que, étant donné un en-tête de bloc récent X à la hauteur b, il existe un en-tête de bloc Y qui est un ancêtre de X à la hauteur b-k. Il repose sur la sécurité du consensus d'Ethereum et nécessite un système de vérification rapide pour être efficace. C'est l'approche utilisée par Lagrange.
• Cache de chaînes de montagnes Merkle (MMR) : Une chaîne de montagnes de Merkle peut être considérée comme une liste d'arbres de Merkle où les arbres de Merkle individuels sont combinés lorsque deux arbres atteignent la même taille. Les arbres de Merkle individuels du MMR sont combinés en ajoutant des nœuds parents aux racines précédentes des arbres. Le MMR est une structure de données similaire aux arbres de Merkle avec quelques avantages supplémentaires, tels que l'ajout efficace d'éléments et des requêtes de données efficaces, en particulier lors de la lecture de données séquentielles à partir de grands ensembles de données. L'ajout de nouveaux en-têtes via l'arbre de Merkle nécessiterait de passer par tous les nœuds frères à chaque niveau. Afin d'ajouter des données de manière efficace, Axiom utilise MMR pour maintenir un cache du hachage des en-têtes de blocs sur la chaîne. Herodotus stocke le hachage de la racine de l'accumulateur de hachage du bloc MMR sur la chaîne. Cela leur permet de vérifier les données extraites par rapport à ces hachages d'en-tête de bloc au moyen de preuves d'inclusion. Cette approche nécessite une mise à jour régulière de la mémoire cache et pose des problèmes de disponibilité si elle n'est pas décentralisée.
• Hérodote présente deux MMR différents. En fonction de la blockchain ou de la couche spécifique, les accumulateurs peuvent être adaptés pour utiliser différentes fonctions de hachage, optimisant ainsi l'efficacité et les coûts de calcul. Pour la preuve sur Starknet, le hash de Poséidon peut être utilisé, mais le hash de Keccack peut être utilisé pour les chaînes EVM.
• Cache MMR hors chaîne : Herodotus maintient un cache hors chaîne des requêtes et des résultats précédemment récupérés pour permettre une récupération plus rapide au cas où les données seraient à nouveau demandées. Cela nécessite une infrastructure supplémentaire par rapport au simple fonctionnement d'un nœud d'archivage. Les optimisations réalisées sur l'infrastructure hors chaîne peuvent potentiellement réduire les coûts pour l'utilisateur final.
• Blockchain dédiée pour le stockage : Brevis s'appuie sur un rollup ZK dédié (couche d'agrégation) pour stocker tous les en-têtes de blocs de toutes les chaînes qu'ils attestent. Sans cette couche d'agrégation, chaque chaîne devrait stocker les en-têtes de bloc de toutes les autres chaînes, ce qui entraînerait O(N2) "connexions" pour N chaînes de blocs. En introduisant une couche d'agrégation, chaque blockchain n'a plus qu'à stocker la racine de l'état pour le rollup, ce qui réduit les connexions globales à O(N). Cette couche est également utilisée pour agréger plusieurs preuves pour les en-têtes de blocs/résultats de requêtes et une seule preuve pour la vérification sur chaque blockchain connectée peut être soumise.
• Transmission de messages L1-L2 : La vérification du consensus de la chaîne source peut être évitée dans le cas des L2, car ces derniers prennent en charge la messagerie native pour la mise à jour des contrats L2 sur L1. Le cache pourrait être mis à jour sur Ethereum et le passage de messages L1-L2 peut être utilisé pour envoyer le hachage du bloc ou la racine de l'arbre compilé hors chaîne à d'autres L2. Hérodote adopte cette approche, mais elle n'est pas réalisable pour les L1 alt.

Traitement des données :

Outre l'accès aux données, les contrats intelligents devraient également être en mesure d'effectuer des calculs arbitraires au-dessus des données. Si certains cas d'utilisation ne nécessitent pas de calcul, il s'agit d'un service à valeur ajoutée important pour de nombreux autres cas d'utilisation. De nombreux fournisseurs de services permettent d'effectuer des calculs sur les données, car une preuve zk du calcul peut être générée et fournie sur la chaîne pour en vérifier la validité. Comme les solutions AMP existantes telles que Axelar, LayerZero, Polyhedra Network pourraient potentiellement être utilisées pour l'accès aux données, le traitement des données pourrait devenir un facteur de différenciation pour les fournisseurs de services de preuve de stockage.

Hyper Oracle, par exemple, permet aux développeurs de définir des calculs personnalisés hors chaîne avec JavaScript. Brevis a conçu une place de marché ouverte de moteurs de requête ZK qui accepte les requêtes de données des dApp et les traite à l'aide des en-têtes de blocs attestés. Le contrat intelligent envoie une requête de données, qui est récupérée par un prouveur sur la place de marché. Le prouveur génère une preuve basée sur l'entrée de la requête, les en-têtes de blocs pertinents (provenant de la couche d'agrégation de Brevis) et les résultats. Lagrange a introduit ZK Big Data Stack pour prouver les modèles de programmation distribués comme SQL, MapReduce et Spark/RDD. Les preuves sont modulaires et peuvent être générées à partir de n'importe quel en-tête de bloc provenant de ponts inter-chaînes et de protocoles AMP existants. ZK MapReduce, le premier produit de la pile BigData de Lagrange ZK, est un moteur de calcul distribué (basé sur le modèle de programmation MapReduce bien connu) pour prouver les résultats de calculs impliquant des ensembles importants de données multi-chaînes. Par exemple, une seule preuve ZKMR peut être utilisée pour prouver les changements de liquidité d'un DEX déployé sur 4 à 5 chaînes sur une période donnée. Pour les requêtes relativement simples, le calcul peut également être effectué directement sur la chaîne, comme le fait actuellement Herodotus.

Génération de preuves :

• Preuves actualisables : Les preuves actualisables peuvent être utilisées lorsqu'une preuve doit être calculée et maintenue efficacement sur un flux de blocs en mouvement. Lorsqu'une dapp souhaite maintenir une preuve pour une moyenne mobile pour une variable contractuelle (comme le prix d'un jeton), au fur et à mesure que de nouveaux blocs sont créés, sans recalculer la nouvelle preuve à partir de zéro, les preuves existantes peuvent être mises à jour de manière efficace. Pour prouver le calcul dynamique en parallèle sur un état de la chaîne, Lagrange construit un engagement vectoriel par lot, appelé Recproof, sur une partie de MPT, le met à jour à la volée et calcule dynamiquement dessus. En créant récursivement un arbre de Verkle au-dessus de MPT, Lagrange est en mesure de calculer efficacement de grandes quantités de données dynamiques sur l'état de la chaîne.
• Arbres de Verkle : Contrairement aux arbres de Merkle, pour lesquels nous devons fournir tous les nœuds qui partagent un parent, les arbres de Verkle ne nécessitent que le chemin vers la racine. Ce chemin est beaucoup plus petit que tous les nœuds frères dans le cas de l'arbre de Merkle. Ethereum étudie également l' utilisation d'arbres de Verkle dans les prochaines versions afin de minimiser la quantité d'état que les nœuds complets d'Ethereum doivent conserver. Brevis s'appuie sur Verkle Tree pour stocker les en-têtes de blocs attestés et les résultats des requêtes dans la couche d'agrégation. Il réduit considérablement la taille de la preuve d'inclusion des données, en particulier lorsque l'arbre contient un grand nombre d'éléments, et permet également une preuve d'inclusion efficace pour un lot de données.
• Surveillance de Mempool pour une génération de preuves plus rapide : Herodotus a récemment annoncé turbo, qui permet aux développeurs d'ajouter quelques lignes de code à leur code de contrat intelligent pour spécifier la requête de données. Herodotus surveille le mempool pour les transactions de contrat intelligent qui interagissent avec le contrat turbo. Le processus de génération de preuves commence lorsque la transaction se trouve dans le pool de mémoire lui-même. Une fois la preuve générée et vérifiée sur la chaîne, les résultats sont inscrits dans le contrat d'échange turbo sur la chaîne. Les résultats ne peuvent être inscrits dans le contrat de swap turbo qu'une fois qu'ils ont été authentifiés par des preuves de stockage. Dans ce cas, une partie des frais de transaction est partagée avec le séquenceur ou le constructeur de blocs, ce qui les incite à attendre un peu plus longtemps pour percevoir les frais. Pour les demandes de données simples, il est possible que les données demandées soient mises à disposition sur la chaîne avant que la transaction de l'utilisateur ne soit incluse dans le bloc.

Application des preuves d'état/de stockage

Les preuves d'état et de stockage peuvent débloquer de nombreux nouveaux cas d'utilisation pour les contrats intelligents au niveau de l'application, de l'intergiciel et de l'infrastructure. En voici quelques-unes :

Couche d'application :

La gouvernance :

• Vote entre chaînes : Un protocole de vote sur la chaîne pourrait permettre aux utilisateurs de la chaîne B de prouver qu'ils possèdent des actifs sur la chaîne A. Les utilisateurs n'auront pas à transférer leurs actifs pour obtenir un droit de vote sur une nouvelle chaîne. Exemple : SnapshotX sur Hérodote
• Distribution de jetons de gouvernance : Les applications pourraient distribuer davantage de jetons de gouvernance aux utilisateurs actifs ou aux utilisateurs précoces. Exemple : RetroPGF sur Lagrange

Identité et réputation :

• Preuve de propriété : Un utilisateur peut fournir une preuve de propriété d'un certain NFT, SBT ou actif sur la chaîne A, ce qui lui permet d'effectuer certaines actions sur la chaîne B. Par exemple, une chaîne d'applications de jeux peut décider de lancer sa collection de NFT sur une autre chaîne avec des liquidités existantes, comme Ethereum ou toute autre L2. Cela permettra au jeu de puiser dans les liquidités qui existent ailleurs et de combler l'utilité des NFT sans qu'il soit nécessaire de combler les NFT.
• Preuve d'utilisation : Les utilisateurs pourraient se voir accorder des remises ou des primes sur la base de leur utilisation historique de la plate-forme (prouver que l'utilisateur a négocié un volume X sur Uniswap).
• Preuve d'OG : un utilisateur peut prouver qu'il possède un compte actif datant de plus de X jours.
• Score de crédit en chaîne : Une plateforme d'évaluation de crédit multichaîne peut agréger les données de plusieurs comptes d'un même utilisateur pour générer une évaluation de crédit.

Toutes les preuves ci-dessus peuvent être utilisées pour fournir une expérience personnalisée aux utilisateurs. Les dapps pourraient proposer des réductions ou des privilèges pour fidéliser les traders ou les utilisateurs expérimentés et offrir une expérience utilisateur simplifiée aux novices.

Defi :

• Prêts entre chaînes : Les utilisateurs pourraient bloquer des actifs sur la chaîne A et contracter un prêt sur la chaîne B au lieu de faire le pont entre les jetons.
• Assurance sur la chaîne : Les défaillances peuvent être déterminées en accédant aux données historiques de la chaîne et l'assurance peut être réglée entièrement sur la chaîne.
• TWAP du prix des actifs dans un pool : Une application peut calculer et obtenir le prix moyen d'un actif dans un pool AMM sur une période donnée. Exemple : Uniswap TWAP Oracle avec Axiom
• Prix des options : un protocole d'options sur la chaîne peut fixer le prix d'une option en utilisant la volatilité d'un actif sur les n derniers blocs d'une bourse décentralisée.

Les deux derniers cas d'utilisation nécessiteront la mise à jour de la preuve chaque fois qu'un nouveau bloc est ajouté à la chaîne source.

Logiciels intermédiaires :

• Intentions : Les preuves de stockage permettront aux utilisateurs d'être plus explicites et plus clairs dans leurs intentions. Bien qu'il appartienne aux résolveurs d'exécuter les étapes nécessaires pour répondre à l'intention de l'utilisateur, ce dernier pourrait spécifier plus clairement les conditions sur la base des données et des paramètres de la chaîne. Les résolveurs peuvent également prouver la validité des données de la chaîne utilisées pour trouver la solution optimale.
• Abstraction de compte : Les utilisateurs pourraient s'appuyer sur des données provenant d'autres chaînes utilisant des preuves de stockage pour établir des règles via l'abstraction de compte. Exemple : Chaque portefeuille possède un nonce. Nous pouvons prouver qu'il y a un an, le nonce était un nombre particulier, et qu'actuellement le nonce est le même. Cela peut être utilisé pour prouver que ce portefeuille n'a pas été utilisé du tout et l'accès au portefeuille peut alors être délégué à un autre portefeuille.
• Automatisation en cours de chaîne : Les contrats intelligents pourraient automatiser certaines actions sur la base de conditions prédéfinies qui dépendent des données de la chaîne. Des programmes automatisés sont nécessaires pour appeler des contrats intelligents à certains intervalles afin de maintenir le flux de prix optimal de l'AMM ou de maintenir les protocoles de prêt en bonne santé en évitant les créances irrécouvrables. Hyper Oracle permet l'automatisation et l'accès aux données de la chaîne.

L'infrastructure

• Oracle sans confiance sur la chaîne : Les réseaux d'oracles décentralisés regroupent les réponses de nombreux nœuds d'oracles individuels au sein d'un réseau d'oracles. Oracle Networks peut éliminer cette redondance et tirer parti de la sécurité cryptographique pour les données de la chaîne. Le réseau Oracle pourrait ingérer des données provenant de plusieurs chaînes (L1, L2 et alt L1) sur une seule chaîne et en prouver simplement l'existence en utilisant des preuves de stockage ailleurs. Les solutions DeFi qui ont un succès significatif peuvent également travailler sur une solution personnalisée. Par exemple, Lido Finance, le plus grand fournisseur de liquidités, s'est associé à la Nil Foundation pour financer le développement de zkOracle. Les solutions permettront un accès sans confiance aux données historiques de l'EVM et sécuriseront 15 milliards de dollars de liquidités Ethereum mises en jeu par Lido Finance.
• Protocoles AMP : Les solutions AMP existantes pourraient accroître l'expressivité de leurs messages en s'associant à des fournisseurs de services de preuve de stockage. Il s'agit d'une approche suggérée par Lagrange dans son article sur les thèses modulaires.

Conclusion

La sensibilisation permet aux entreprises technologiques de mieux servir leurs clients. De l'identité de l'utilisateur au comportement d'achat en passant par les graphes sociaux, les entreprises technologiques exploitent la connaissance pour débloquer des capacités telles que le ciblage de précision, la segmentation de la clientèle et le marketing viral. Les entreprises technologiques traditionnelles ont besoin de l'autorisation explicite de leurs utilisateurs et doivent faire preuve de prudence dans la gestion des données des utilisateurs. Cependant, toutes les données des utilisateurs sur les blockchains sans permission sont accessibles au public sans nécessairement révéler l'identité de l'utilisateur. Les contrats intelligents devraient pouvoir exploiter les données publiques disponibles pour mieux servir les utilisateurs. Le développement et l'adoption d'écosystèmes plus spécialisés feront de la connaissance des états à travers le temps et les blockchains un problème de plus en plus important à résoudre. Les preuves de stockage peuvent permettre à Ethereum de devenir une couche d'identité et de propriété d'actifs, ainsi qu'une couche de règlement. Les utilisateurs pourraient conserver leur identité et leurs actifs clés sur Ethereum, qui pourraient être utilisés sur plusieurs blockchains sans avoir à relier les actifs en permanence. Nous restons enthousiastes à l'idée des nouvelles possibilités et des nouveaux cas d'utilisation qui se présenteront à l'avenir.

Clause de non-responsabilité：

1. Cet article est repris de[medium]. Tous les droits d'auteur appartiennent à l'auteur original[LongHash Ventures]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. 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, distribuer ou plagier les articles traduits.