Dans notre précédent post, qui serait actionable, nous avons discuté du rôle de consensus proof de cette méthode émergente de minimisation de la confiance dans la facilitation du pont entre les blockchains.

Dans cet article, nous explorerons la preuve de stockage, qui prend le concept de vérification de minimisation de confiance et l'étend aux transactions dans les anciens blocs historiques. La capacité de vérifier les transactions passées et l'activité des utilisateurs de cette manière ouvre un grand nombre de cas d'utilisation inter-chaînes.

Dans notre message précédent, nous avons introduit la Preuve de Consensus — une approche de minimisation de la confiance pour le transfert de fonds entre les blockchains. Comme les utilisateurs de ponts veulent généralement voir les transactions se produire immédiatement au moment le plus récent, la preuve de consensus est très utile car ils vérifient constamment l'état le plus récent de la blockchain pendant son fonctionnement.

Ce concept de minimisation de la confiance peut également être appliqué dans une autre direction, qui consiste à remonter dans le passé et à utiliser des preuves de connaissance nulle pour vérifier les transactions et les données dans les anciens blocs. Ces 'preuves de stockage historique' prennent en charge une gamme diverse de cas d'utilisation inter-chaînes, et dans cet article, nous couvrirons ces cas d'utilisation, leur fonctionnement, et les acteurs intégrés dans cet espace.

Récupérer des données historiques

Il existe de nombreuses utilisations pour les données historiques de la blockchain. Elles peuvent être utilisées pour prouver la propriété d'actifs, le comportement des utilisateurs et l'historique des transactions, puis les intégrer dans des contrats intelligents ou des applications on-chain.Au moment de l'écriture, plus de 18 millions de blocs ont été écrits sur Ethereum.Les contrats intelligents ne peuvent accéder qu'aux 256 derniers blocs (ou aux données des 30 dernières minutes), donc les "données historiques" font référence à tout ce qui n'est pas les 256 derniers blocs.

Aujourd'hui, pour accéder aux données historiques, les protocoles interrogent souventnœud d'archivefournisseurs, c'est-à-dire des tiers tels qu'Infura, Alchemy ou d'autres indexeurs. Cela signifie leur faire confiance et compter sur eux et leurs données.

Données historiques

Ces données peuvent cependant être assouplies de manière plus minimisée en matière de confiance, grâce à l'utilisation de preuves de stockage.

Données historiques

Cependant, ces données peuvent être récupérées de manière plus minimisée en matière de confiance en utilisant des preuves de stockage.

La preuve de stockage est une preuve de connaissance nulle qui permet la vérification des données historiques stockées sur la blockchain. Plus précisément, la preuve de stockage peut être utilisée pour prouver l'existence d'un état spécifique dans un bloc particulier dans le passé.Cette approche ne nécessite pas de faire confiance à des tiers ou à des oracles; au lieu de cela, sa confiance est intégrée à la preuve de stockage.

Comment les preuves de stockage peuvent-elles aider à vérifier que certaines données existent dans des blocs historiques plus anciens ? Cela nécessite de vérifier deux choses :

• La première étape consiste à vérifier si un bloc spécifique fait partie de l'histoire réglementaire de la blockchain, c'est-à-dire si le bloc fait partie valide de l'histoire de la chaîne source
• La deuxième étape consiste à vérifier si des données spécifiques font partie du bloc, c'est-à-dire qu'une information (comme une transaction spécifique) fait partie du bloc (ceci peut être prouvé par une preuve d'inclusion de Merkle)

Après avoir reçu et vérifié la preuve, le destinataire (comme un smart contract sur la chaîne cible) croit en la validité des données et peut exécuter l'ensemble correspondant d'instructions. Le concept peut être étendu encore plus loin : des calculs supplémentaires hors chaîne peuvent être exécutés avec des données validées, puis une autre preuve de zéro connaissance est générée pour prouver les données et les calculs.

En termes simples, la preuve de stockage prend en charge la récupération de données sur la chaîne historique de manière à minimiser la confiance. C'est important car, comme nous l'avons souligné dans notre premier article, nous voyons le web3 devenir un espace de plus en plus multi-chaînes et multi-niveaux au cours des prochaines années. L'émergence de plusieurs protocoles de couche 1, de rollups et de chaînes d'application signifie que l'activité on-chain des utilisateurs peut être dispersée sur plusieurs chaînes. Cela souligne davantage la nécessité de solutions d'interopérabilité minimisant la confiance qui maintiennent la composabilité des actifs des utilisateurs, des identités et de l'historique des transactions à travers plusieurs domaines. Il s'agit d'un problème que la preuve de stockage peut aider à résoudre.

Quels sont les cas d'utilisation de la preuve de stockage ?

La preuve de stockage permet aux contrats intelligents de vérifier toute transaction ou donnée historique comme prérequis. Cela rend la conception d'applications inter-chaînes plus flexible.

Tout d'abord, stocker des preuves peut prouver n'importe quelle donnée historique sur la blockchain source, comme

1. Solde du compte et possession de jetons
2. Activité de trading de l'utilisateur ou état statique
3. Le prix historique d'une transaction d'actif sur une période de temps spécifiée
4. Solde d'actifs en temps réel du pool de liquidité inter-chaînes

La preuve peut ensuite être envoyée à la chaîne cible pour débloquer toute une gamme de cas d'utilisation inter-chaînes :

1. Permet aux utilisateurs de voter sur des propositions de gouvernance sur des accords de couche 2 à moindre coût
2. Permettre aux détenteurs de NFT de recevoir de nouveaux jetons NFT ou des avantages communautaires sur une nouvelle chaîne
3. Récompenser les utilisateurs en fonction de leur historique et de leurs interactions avec des dApps spécifiques (par exemple, via des largages aériens)
4. Prêts qui offrent des taux d'intérêt personnalisés basés sur l'historique global des transactions et de crédit de l'utilisateur
5. Déclencher la récupération de compte pour les comptes dormants
6. Calcul de l'historique des swaps à terme TWAP
7. Calculer des prix de swap AMM plus précis basés sur des pools de liquidités multi-chaînes

Essentiellement, les preuves de stockage permettent aux applications d'interroger et de porter l'activité et l'historique des utilisateurs on-chain à travers plusieurs chaînes pour les entrer dans un contrat intelligent ou une application sur une autre chaîne.

Cas d'utilisation de la preuve de stockage

Prenons un exemple détaillé pour comprendre comment fonctionne la preuve de stockage.

Comment fonctionne la preuve de stockage : exemples détaillés

Suppose “X,” which is a DeFi protocol with tokens on Ethereum. A governance proposal is about to be put forward, and they want to promote on-chain voting on lower cost target chains. Users can only vote if they hold X tokens on Ethereum at a specific point in time (we call it a “snapshot”), such as block #17,000,000

Comment se fait actuellement le vote sur la chaîne ?

L'approche actuelle consiste à interroger le nœud d'archive pour obtenir la liste complète des détenteurs de jetons éligibles au bloc #17,000,000. L'administrateur de DAO stocke ensuite cette liste dans un smart contract sur la chaîne cible pour déterminer qui peut voter. Il y a quelques limitations à cette approche :

1. La liste des électeurs peut être très longue, et chaque instantané change, ce qui rend cher le stockage et la mise à jour de chaque proposition de vote sur la chaîne ;
2. Il existe une confiance implicite dans le fournisseur de nœuds d'archive et les données qu'il fournit;
3. Les membres qui gèrent le DAO doivent être dignes de confiance pour ne pas altérer la liste des électeurs

Comment la preuve de stockage résout-elle ce problème ?

Comme nous l'avons expliqué dans l'article 2, les calculs coûteux peuvent être transférés aux preuves de zéro connaissance hors chaîne.

Le vérificateur zk générera une preuve concise et l'enverra à la chaîne cible pour vérification. Pour les exemples d'éligibilité des votants DAO ci-dessus, les suivants sont :

1. L'attestateur génère une preuve de connaissance nulle que le bloc n°17,000,000 fait partie de l'histoire d'Ethereum (comme dans la première étape* ci-dessus).
2. Après avoir prouvé la validité du bloc, nous pouvons utiliser Merkle pour inclure la preuve que l'utilisateur détenait des jetons DAO lorsque le bloc a été finalisé (comme à l'étape 2 ci-dessus*)

Vérifiez les données historiques pour permettre le vote inter-chaînes

La preuve est ensuite envoyée à un contrat intelligent sur la chaîne cible pour vérification. Si la vérification est réussie, alors le contrat intelligent sur le protocole de couche 2 permet aux utilisateurs de voter.

Cette approche a résolu quelques problèmes. Il ne nécessite pas:

Faites confiance au fournisseur de nœuds d'archive;

1. que l'accord maintienne des listes d'électeurs onéreuses on-chain;
2. Pour que les utilisateurs transfèrent des actifs à la chaîne de but

Quels paramètres sont nécessaires pour la preuve de stockage ?

Jusqu'à présent, nous avons abstrait certaines des subtilités des preuves de stockage. Cependant, les utiliser nécessite également une configuration initiale soigneuse par le fournisseur de services pour garantir qu'elles peuvent être utilisées sans avoir à faire confiance au fournisseur. Deux éléments sont générés et stockés on-chain pendant ce processus :

1. Preuve de connaissance zéro complète de chaîne ("promesse zk") : Le fournisseur de services regroupe tous les blocs historiques sur la chaîne source en "blocs" de taille fixe et continue (en utilisant des arbres de Merkle)et génère des preuves à divulgation nulle pour chaque bloc, qui sont utilisées pour vérifier les regroupements. Ces preuves sont ensuite combinées de manière récursive jusqu'à ce qu'une preuve à divulgation nulle finale soit obtenue, une « promesse zk » à l'ensemble de la chaîne. Cela prouve que le fournisseur a correctement indexé l'ensemble de l'historique de la chaîne.

La "promesse zk" explique toute l'histoire d'Ethereum

• **Chaîne de montagnes de Merkle : ** Le fournisseur stocke également les racines de Merkle Keccak des hachages de blocs (blocs) de la chaîne source regroupés dans une structure de données sur la chaîne appelée Chaîne de montagnes de Merkle (MMR). Cette structure de données est utilisée car elle est facile à interroger et à mettre à jour, et permet aux fournisseurs de prouver efficacement qu'un bloc donné existe dans l'historique de la chaîne. MMR est créé en utilisant un hachage Keccak256, un hachage Poseidon, ou les deux. Les hachages Poseidon sont plus conviviaux pour la confidentialité et prennent en charge le calcul des données historiques. La validité des données et du calcul peut ensuite être prouvée via une preuve de zéro connaissance.

Illustration de la chaîne de montagnes Merkel (MMR)

À mesure que de nouveaux blocs sont ajoutés à la chaîne source, les fournisseurs de services mettent régulièrement à jour (par exemple toutes les heures ou tous les jours) l'engagement “zk” et MMR pour suivre le rythme de la chaîne. Cela est fait de manière à ce que le bloc précédent soit toujours lié à l'un des 256 blocs actuellement accessibles depuis l'EVM. Cela garantit que les données historiques sont liées à l'un des blocs actuellement disponibles sur Ethereum.

Sur l'image ci-dessous, nous avons détaillé comment compléter la configuration :

En résumé, ce qui suit montre comment utiliser la preuve de stockage une fois la configuration terminée dans le contexte de l'exemple de vote de DAO que nous avons couvert précédemment :

1. Les fournisseurs de services créent et stockent des "promesses zk" pour l'ensemble de la chaîne (c'est-à-dire l'histoire d'Ethereum) et MMR sur la chaîne cible
2. Le fournisseur permet aux applications d'interroger des données historiques on-chain ou off-chain via une API
3. Une dApp de vote sur la chaîne de but envoie une requête au contrat intelligent du fournisseur pour savoir si l'utilisateur détient des jetons DAO sur le bloc n°17,000,000 sur Ethereum

Le fournisseur vérifiera deux choses :

1. Le bloc interrogé fait partie de l'histoire réglementaire d'Ethereum (première étape ci-dessus); le fournisseur génère ensuite une preuve de connaissance nulle du contenu du bloc via Merkle Mountain Range
2. L'utilisateur détient des jetons DAO dans le bloc n°17,000,000 (étape 2 ci-dessus); le fournisseur génère ensuite une autre preuve de connaissance nulle que l'utilisateur détient des jetons DAO dans le bloc
3. Le fournisseur agrège la preuve générée ci-dessus dans une preuve de zéro connaissance
4. La preuve ZK agrégée est ensuite renvoyée au contrat intelligent d'application de vote sur la chaîne cible pour vérifier la preuve ZK et permettre à l'utilisateur de voter une fois que la vérification a réussi.

Construction d'équipe dans ce domaine

Certains participants sont en train de construire des contrats intelligents qui permettent aux contrats intelligents d'accéder aux données sur les chaînes historiques d'une manière qui minimise la confiance.

Actuellement, Axiomfonctionne sur Ethereum et s'engage à fournir des contrats intelligents sur Ethereum et à accéder aux données historiques d'Ethereum grâce à des preuves de stockage zk. L'équipe améliore également les capacités de calcul hors chaîne basées sur des données historiques et utilise le savoir-faire zéro pour prouver l'exactitude de ces données et calculs.

Protocole Relicfournit une approche technique similaire à Axiom, et le protocole s'exécute sur Ethereum et zkSync Era. Relic utilise des preuves d'inclusion de Merkle pour prouver l'inclusion des données (par opposition à la méthode d'Axiom qui consiste à prouver l'inclusion de Merkle en zéro connaissance).

Hérodotetravaille à fournir des données historiques sur Ethereum pour les protocoles de couche 2. La mise en œuvre de test est maintenant disponible sur Starknet et zkSync Era. Avec le financement de la Fondation OP, nous pensons savoir où l'équipe d'Hérodote se dirige ensuite.

Lagrange Labs Labsa introduit une preuve entièrement mise à jour grâce à son innovation récente ZK MapReduce (ZKMR). Il utilise une nouvelle promesse vectorielle appelée Recproofspour étendre le concept de mise à jour à la computation des données.

Équipes travaillant sur la certification du stockage

épilogue

Dans cet article, nous avons décrit comment la preuve de stockage peut soutenir la vérification des données sur la chaîne historique sans faire confiance aux tiers. Cela en fait un outil précieux pour la composition on-chain et l'interopérabilité entre chaînes.

Alors que la valeur totale verrouillée (TVL) continue de migrer d'Ethereum vers l'écosystème de niveau 2, nous anticipons l'émergence de applications plus expressives qui utilisent des données historiques on-chain à travers des preuves de stockage.

Alors que la technologie du zéro-connaissance devient de plus en plus rapide et moins chère, générer continuellement des preuves de stockage pour suivre les coûts associés au fait d'être sur la chaîne reste un défi. La rentabilité de ces services dépendra du volume de requêtes générées par l'application de requête.

Malgré les défis, l'importance de la preuve de consensus et de la preuve de stockage soutenue par la technologie de connaissance nulle ne peut être surestimée. Nous sommes impatients de voir comment ces technologies seront utilisées pour construire un avenir multi-chaîne avec un minimum de confiance.

Disclaimer：

1. Cet article est repris de [ miroir]. Tous les droits d'auteur appartiennent à l'auteur original [Jacob, Hitesh, Ji Hao]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe Gate Learn（gatelearn@gate.io) et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.