Lors du sommet ETHShanghai 2023, le fondateur d'Axiom, Yi Sun, a présenté le coprocesseur ZK d'Ethereum Axiom et son importance en termes d'accès aux données et de puissance de calcul. Axiom réalise l'expansion de l'accès aux données et du calcul grâce au concept d'opération de réflexion, et réalise la validité de la requête en vérifiant la chaîne de hachage et en maintenant le cache. Les applications pour Axiom incluent des applications à coût élevé, un accès plus large aux données, des applications basées sur des protocoles de gestion de données historiques, etc. Grâce à Axiom, les contrats intelligents peuvent obtenir des données et une puissance de calcul plus larges, favorisant davantage le développement d'applications Ethereum.
Le texte suivant est la version chinoise compilée du discours de Yi Sun, et le lien est la vidéo en direct :
Tout d'abord, comprenons le parcours de l'utilisateur pour accéder réellement aux informations Ethereum. Lorsque nous avons utilisé Ethereum pour la première fois, nous recevions des informations sur ce qui se passait en chaîne via des appels JSON-RPC pour archiver les annotations. Le but de l'API JSON-RPC est de présenter à l'utilisateur des informations sur l'historique de la chaîne. Essentiellement, toutes les informations que nous voyons sur la blockchain sont extraites de ces appels API et présentées comme une entrée sur le site Web que l'utilisateur peut lire.
Maintenant, à mesure que les utilisateurs deviennent plus aptes à interagir avec la blockchain, nous commençons à exiger des vues de plus en plus complexes de la chaîne. Par conséquent, différents types de nœuds d'archivage sont en cours de développement pour différents compromis d'utilisateurs. Il y avait donc Geth, Erigon, Nethermind et maintenant Reth. Nous pouvons choisir le nœud d'archivage le plus approprié en fonction de nos propres besoins.
Si les utilisateurs ne sont pas satisfaits d'une API JSON-RPC distincte, un indexeur peut être choisi pour appliquer le post-traitement lors du suivi des transactions. Pour différentes applications, les utilisateurs peuvent être intéressés par les données renvoyées par The Graph ou Covalent.
Plus récemment, il y a également eu des portefeuilles et d'autres produits qui offrent une simulation de transaction au-dessus des nœuds d'archivage. Cela signifie que nous pouvons voir le résultat réel d'une transaction virtuelle avant de la valider. Dans l'ensemble, en tant qu'utilisateurs finaux, la façon dont nous interagissons avec Ethereum devient de plus en plus sophistiquée, utilisant davantage de calculs en plus des données que nous lisons.
Maintenant, si nous y pensons non pas du point de vue d'un utilisateur, mais du point de vue d'un contrat intelligent sur Ethereum. Bien sûr, les contrats veulent également pouvoir accéder aux données et effectuer des calculs dessus, mais c'est plus difficile. En fait, si nous allons sur OpenSea et regardons la liste de CryptoPunk, nous constaterons que de toutes les informations de la page, seule une petite partie est accessible dans le contrat intelligent de la chaîne.
En fait, pour les listes de CryptoPunk, ces informations ne concernent que les détenteurs actuels. Bien sûr, il y a beaucoup d'autres informations sur la page, mais toutes les informations relatives aux informations de transfert historiques, aux prix historiques et aux détenteurs historiques sont en fait inaccessibles au contrat intelligent car elles appartiennent à l'historique passé. Ces historiques constituent des informations en chaîne, mais ils ne sont pas disponibles pour les contrats intelligents car nous devons éviter de forcer chaque nœud Ethereum complet à conserver ces informations dans son accès aléatoire pour vérifier les transactions.
De plus, comme tout développeur de blockchain peut vous le dire, l'exécution de calculs en chaîne est extrêmement coûteuse, bien qu'Ethereum ait des opérations de machine virtuelle (VM) relativement efficaces, et la précompilation rend certains types d'opérations moins chers. Par exemple, Ethereum fournit un support relativement bon marché pour les opérations de courbe elliptique sur la courbe BN254. Cependant, pour certaines applications spécifiques, la machine virtuelle Ethereum reste un environnement d'exécution très coûteux. Lors de la conception d'une machine virtuelle blockchain, il faut choisir un ensemble inhérent d'opérations qui doivent être soigneusement mesurées pour s'assurer que chaque nœud peut vérifier les transactions à un moment cohérent. En outre, la sécurité dans le pire des cas et la stabilité du consensus doivent également être prises en compte. Le défi ici est donc de savoir comment mettre en œuvre une mise à l'échelle spécifique à l'application pour les applications en chaîne. Axiom vise à étendre les capacités d'accès aux données et de calcul pour les contrats intelligents afin de répondre aux besoins d'expansion de différentes applications.
Ce qu'Axiom construit, c'est ce qu'il appelle un coprocesseur Ethereum (coprocesseur ZK), qui permet à certains contrats intelligents de déléguer en toute confiance à notre système hors chaîne afin qu'ils puissent déléguer des lectures de données et des calculs vérifiables à Axiom. Pour émettre une requête à Axiom, un contrat intelligent peut envoyer une transaction à notre système en chaîne. Notre nœud hors ligne recevra la transaction et générera un résultat basé sur la requête historique d'Ethereum, et joindra une preuve de connaissance nulle pour prouver l'exactitude du résultat. Enfin, nous vérifions les résultats en chaîne et fournissons de manière crédible les résultats aux contrats intelligents en aval.
Ceci est similaire à la façon dont le CPU d'un ordinateur délègue le calcul au GPU et récupère les résultats lorsqu'ils sont connus. Ce concept s'appelait coprocesseur (Coprocesso) à ses débuts. Sur la diapositive, je montre une image d'un coprocesso mathématique avancé du début des années 1990 qui est analogue à ce que fait l'Axiom.
Nous pouvons avoir un aperçu des types d'opérations qu'Axiom peut effectuer. Chaque requête adressée à Axiom peut être divisée en trois parties.
La première est la partie lecture, qui correspond à la manière dont les requêtes Axiom sont saisies - nous pouvons lire de manière fiable les données historiques en chaîne.
La deuxième partie est que nous pouvons exécuter des calculs de validation sur ces données. Cela peut commencer par une analyse de base, comme la somme de certains nombres, la recherche du maximum ou du minimum, jusqu'à des calculs plus complexes. Par exemple, certaines agrégations ou vérifications de signatures à partir de la cryptographie, et même l'apprentissage automatique basé sur la connaissance zéro, comme la vérification du fonctionnement de certains algorithmes de réputation sur les données sociales de la chaîne ou l'utilisation de certains algorithmes d'apprentissage automatique dans des applications financières. A terme, nous fournirons des fonctions composites informatiques programmables via des machines virtuelles.
La dernière partie, après les étapes de lecture et de calcul, nous obtenons un résultat et jumelons toujours ce résultat avec une preuve à connaissance nulle que le calcul du résultat était valide. Par conséquent, nous vérifions cette preuve dans le contrat intelligent Ethereum, puis stockons le résultat pour une utilisation par le contrat.
Étant donné que tous les résultats renvoyés par Axiom sont en fait vérifiés avec des preuves à connaissance nulle, cela signifie que la sécurité de tout ce qui est renvoyé par Axiom est cryptographiquement équivalente à celle d'Ethereum lui-même. La philosophie d'Axiom est que nous ne voulons pas imposer d'hypothèses supplémentaires aux utilisateurs au-delà des hypothèses cryptographiques qu'ils ont déjà en utilisant Ethereum.
Ensuite, je présenterai en détail son principe de mise en œuvre, qui implique le concept d'opération de réflexion mentionné dans le titre du discours. Le principe de base qui rend tout cela possible est que chaque bloc de la blockchain contient un historique complet. Nous pouvons commencer par le bloc Ethereum actuel et revenir aux blocs précédents qui nous intéressent. En prenant tous les en-têtes de bloc entre le bloc passé et le bloc actuel, et en vérifiant la chaîne de hachage de ces en-têtes de bloc, nous pouvons en fait inverser l'engagement du bloc passé vers le bloc actuel.
Alors, quels sont les avantages de la réflexion ?
Nous pouvons prendre un bloc de l'Ethereum actuel et revenir à un bloc précédent qui nous intéresse. Si nous obtenons les en-têtes de bloc entre le bloc passé et le bloc actuel, nous pouvons inverser l'engagement du bloc passé dans le bloc actuel en vérifiant le chemin de hachage entre ces en-têtes de bloc. Ensuite, si nous sommes intéressés par des informations d'un bloc passé, nous pouvons donner une preuve d'inclusion dans l'engagement de ce bloc. Plus précisément, cela pourrait être une preuve Merkle Patricia Trie que les informations existent dans le trie d'état du bloc, le trie de transaction ou le trie de réception. Dans l'EVM, du moins en principe, toute information passée sur la chaîne n'est accessible que par la connaissance des hachages de blocs récents.
Malheureusement, cela coûte cher dans l'EVM. Comme nous venons de le mentionner, vous devez vérifier les chaînes de hachage et les preuves Merkle de tous les en-têtes de bloc, ce qui implique de nombreux calculs de hachage Keccak sur une grande quantité de données. Donc une fois qu'on remonte dans le temps, ça devient très difficile. Par conséquent, nous appliquons l'opération de réflexion en enveloppant cette preuve avec ZK dans l'EVM. Ainsi, au lieu de mettre tous les en-têtes de bloc passés et toutes ces preuves Merkle en chaîne, puis de les vérifier, nous vérifions sans connaissance s'il existe une séquence d'en-têtes de bloc passés et des preuves de vérification.
Cela a deux avantages. Tout d'abord, cela nous évite d'avoir à mettre des données de preuve dans les données d'appel. Deuxièmement, cela nous permet d'agréger des preuves, ce qui est impensable sans l'utilisation de ZK. L'idée ici est que lors de la vérification d'un nombre quelconque de calculs sur Ethereum, le coût du gaz est fixe, nous pouvons donc utiliser une seule preuve ZK pour vérifier une grande quantité d'accès aux données historiques.
Permettez-moi d'aborder brièvement les compromis du concept d'opération de réflexion basé sur ZK.
Il existe deux façons d'accéder aux données. La première est la façon dont vous le savez auparavant - vous pouvez accéder aux données sur Ethereum directement à partir du contrat intelligent. Cela a le très gros avantage que l'accès est synchrone. Par conséquent, vous pouvez appeler directement la fonction de lecture dans le contrat intelligent pour obtenir la valeur actuelle. Par exemple, lorsque vous négociez sur Uniswap, vous avez besoin de cette synchronicité. Cependant, il présente également de nombreuses limites. Votre puissance de calcul est limitée par les coûts de carburant et vous n'avez accès à aucune donnée historique.
Deuxièmement, si vous souhaitez profiter de la capacité de ZK à se refléter dans Ethereum, car vous devez générer des preuves que votre accès est correct, il n'y a aucun moyen de le faire de manière synchrone. Il n'y a donc en fait aucun accès direct à l'état actuel de la chaîne, car vous devez attester d'un état.
D'autre part, si vous vous autorisez à accéder aux données historiques de manière asynchrone, vous pouvez y appliquer des calculs presque illimités et avoir accès à d'énormes quantités de données. Par conséquent, en assouplissant le concept de synchronisation, l'accès aux données opérationnelles de Reflection basé sur ZK peut être considérablement étendu.
Nous examinons ensuite comment implémenter les opérations de réflexion via Axiom.
Tout d'abord, nous devons en fait conserver un cache de tous les blocs précédents dans notre contrat intelligent. Dans l'EVM, les 256 derniers hachages de bloc sont disponibles en mode natif. Nous pouvons prouver que dans chaque lot de 1024 blocs, le hachage du dernier bloc du lot précédent est validé dans le bloc suivant. De même, le hachage de l'avant-dernier bloc du lot précédent est validé dans le dernier bloc, et ainsi de suite. Par conséquent, nous pouvons inverser la vérification de cette chaîne de hachage et prouver la validité de cette chaîne de hachage grâce à une connaissance nulle.
Cela nous permet de mettre en cache les hachages de blocs à partir du bloc le plus récent jusqu'au bloc de genèse. En fait, nous l'avons implémenté dans notre contrat intelligent de réseau principal, qui contient des chemins Merkle mis en cache tous les 1024 hachages de bloc à partir du bloc de genèse.
Une autre caractéristique que nous ajoutons est Merkle Mountain Range. Il est construit au-dessus de ce cache de hachage de bloc, une structure de données qui nous permet de référencer chaque hachage de bloc dans Ethereum dans un ADN limité.
Une fois que nous avons construit le cache, nous pouvons interroger Axiom en validant les blocs dans le cache. Pour que cela fonctionne, nous devons prouver que chaque élément de données de l'historique Ethereum auquel nous essayons d'accéder est en fait engagé dans le cache d'un bloc. Deuxièmement, nous devons prouver que tous les calculs que nous effectuons sur cette requête sont corrects. Pour vérifier cela en chaîne, nous vérifions la validité de la preuve de connaissance zéro. Nous vérifions également qu'il est en corrélation avec les informations que nous avons enregistrées sur la chaîne. Nous établissons toujours la confiance dans nos caches ou nos caches de blocs et faisons correspondre les informations de ces caches de blocs avec des informations publiques dans des preuves à connaissance nulle.
Parlons maintenant des applications possibles de l'opération Réflexion envisagée.
L'axe horizontal représente la complexité des données, la quantité de données réellement nécessaire pour implémenter l'application. L'axe vertical représente la complexité de calcul, c'est-à-dire la quantité de ressources de calcul réellement nécessaires pour accomplir la tâche.
Par conséquent, le premier type d'application est une application qu'Axiom ou tout type de mécanisme d'opération de réflexion peut être implémenté sur Ethereum, mais le coût est légèrement plus élevé.
Quelques exemples de cela incluent la lecture de nonces de niveau consensus à partir d'en-têtes de bloc dans la couche de consensus Ethereum, la vérification de l'âge des comptes historiques ou la lecture de différents types de données oracle à partir d'informations sur les prix historiques. Dans l'EVM, diverses solutions peuvent être employées pour mettre en œuvre ces applications, mais en plaçant ces solutions dans la connaissance zéro, l'efficacité peut être augmentée.
Maintenant, il existe une autre classe d'applications qui nécessitent généralement plus d'accès aux données et donc plus de calculs. À mon avis, ces applications ne seraient pas possibles sans l'utilisation du coprocesseur ZK.
A titre d'exemple, une application intéressante est de permettre à un Roll-up sur Ethereum de lire l'état de la couche de base ou d'un autre Roll-up de manière fiable, en utilisant la connaissance zéro pour interagir. Une de ces applications pourrait être de permettre aux roll-ups de lire des instantanés de solde complet des jetons ERC20.
Si nous tournons notre attention du stockage vers l'historique des transactions des comptes, vous pouvez imaginer construire une réputation de confiance, une identité ou un système de notation de crédit en enregistrant l'historique complet des adresses Ethereum. Cela pourrait être utilisé pour la notation de crédit, ou pour vous donner accès à un certain type de DAO en chaîne, ou pour vous donner accès à l'émission de NFT personnalisés.
Il existe également une classe d'applications qui utilisent des données historiques en chaîne pour gérer réellement le protocole. Généralement connu sous le nom de comptabilité d'accord.
L'idée ici est que des protocoles existent pour coordonner le comportement des participants, et le principe de base de la coordination est la capacité de récompenser ou de punir les participants pour leur comportement. Si vous regardez de nombreux protocoles sur Ethereum, l'enregistrement des actions des participants est en fait entièrement conservé en chaîne. Ainsi, avec Axiom, nous pouvons imaginer que sur la base de l'ensemble complet des actions des participants au protocole, le protocole peut déterminer la structure de paiement, ou même imposer un certain type de pénalité aux participants, ce qui, selon nous, peut vraiment élargir l'espace de conception du protocole. applications.
Enfin, si nous remontons vraiment le niveau de calcul, nous pensons qu'il pourrait être très intéressant d'utiliser des modèles d'apprentissage automatique pour ajuster les paramètres en chaîne. Si vous pensez aux applications financières traditionnelles, il est très courant de modéliser des paramètres futurs complexes basés sur de grandes quantités de données historiques, telles que des données de prix, des données économiques, etc. Et quand on regarde la DeFi actuelle, elle est loin d'atteindre ce niveau. Je ne pense pas que DeFi devrait fonctionner exactement de la même manière que la finance traditionnelle, mais nous pensons que l'injection de certaines bases de données historiques et de modèles et d'informations basés sur l'apprentissage automatique peut aider à créer un protocole DeFi plus dynamique.
Ce ne sont là que quelques idées de ce que les opérations de réflexion peuvent apporter à la blockchain.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Démontage des avantages techniques du coprocesseur Ethereum ZK Axiom
Auteur : Réseau de masques
Lors du sommet ETHShanghai 2023, le fondateur d'Axiom, Yi Sun, a présenté le coprocesseur ZK d'Ethereum Axiom et son importance en termes d'accès aux données et de puissance de calcul. Axiom réalise l'expansion de l'accès aux données et du calcul grâce au concept d'opération de réflexion, et réalise la validité de la requête en vérifiant la chaîne de hachage et en maintenant le cache. Les applications pour Axiom incluent des applications à coût élevé, un accès plus large aux données, des applications basées sur des protocoles de gestion de données historiques, etc. Grâce à Axiom, les contrats intelligents peuvent obtenir des données et une puissance de calcul plus larges, favorisant davantage le développement d'applications Ethereum.
Le texte suivant est la version chinoise compilée du discours de Yi Sun, et le lien est la vidéo en direct :
Tout d'abord, comprenons le parcours de l'utilisateur pour accéder réellement aux informations Ethereum. Lorsque nous avons utilisé Ethereum pour la première fois, nous recevions des informations sur ce qui se passait en chaîne via des appels JSON-RPC pour archiver les annotations. Le but de l'API JSON-RPC est de présenter à l'utilisateur des informations sur l'historique de la chaîne. Essentiellement, toutes les informations que nous voyons sur la blockchain sont extraites de ces appels API et présentées comme une entrée sur le site Web que l'utilisateur peut lire.
Maintenant, à mesure que les utilisateurs deviennent plus aptes à interagir avec la blockchain, nous commençons à exiger des vues de plus en plus complexes de la chaîne. Par conséquent, différents types de nœuds d'archivage sont en cours de développement pour différents compromis d'utilisateurs. Il y avait donc Geth, Erigon, Nethermind et maintenant Reth. Nous pouvons choisir le nœud d'archivage le plus approprié en fonction de nos propres besoins.
Si les utilisateurs ne sont pas satisfaits d'une API JSON-RPC distincte, un indexeur peut être choisi pour appliquer le post-traitement lors du suivi des transactions. Pour différentes applications, les utilisateurs peuvent être intéressés par les données renvoyées par The Graph ou Covalent.
Plus récemment, il y a également eu des portefeuilles et d'autres produits qui offrent une simulation de transaction au-dessus des nœuds d'archivage. Cela signifie que nous pouvons voir le résultat réel d'une transaction virtuelle avant de la valider. Dans l'ensemble, en tant qu'utilisateurs finaux, la façon dont nous interagissons avec Ethereum devient de plus en plus sophistiquée, utilisant davantage de calculs en plus des données que nous lisons.
Maintenant, si nous y pensons non pas du point de vue d'un utilisateur, mais du point de vue d'un contrat intelligent sur Ethereum. Bien sûr, les contrats veulent également pouvoir accéder aux données et effectuer des calculs dessus, mais c'est plus difficile. En fait, si nous allons sur OpenSea et regardons la liste de CryptoPunk, nous constaterons que de toutes les informations de la page, seule une petite partie est accessible dans le contrat intelligent de la chaîne.
En fait, pour les listes de CryptoPunk, ces informations ne concernent que les détenteurs actuels. Bien sûr, il y a beaucoup d'autres informations sur la page, mais toutes les informations relatives aux informations de transfert historiques, aux prix historiques et aux détenteurs historiques sont en fait inaccessibles au contrat intelligent car elles appartiennent à l'historique passé. Ces historiques constituent des informations en chaîne, mais ils ne sont pas disponibles pour les contrats intelligents car nous devons éviter de forcer chaque nœud Ethereum complet à conserver ces informations dans son accès aléatoire pour vérifier les transactions.
De plus, comme tout développeur de blockchain peut vous le dire, l'exécution de calculs en chaîne est extrêmement coûteuse, bien qu'Ethereum ait des opérations de machine virtuelle (VM) relativement efficaces, et la précompilation rend certains types d'opérations moins chers. Par exemple, Ethereum fournit un support relativement bon marché pour les opérations de courbe elliptique sur la courbe BN254. Cependant, pour certaines applications spécifiques, la machine virtuelle Ethereum reste un environnement d'exécution très coûteux. Lors de la conception d'une machine virtuelle blockchain, il faut choisir un ensemble inhérent d'opérations qui doivent être soigneusement mesurées pour s'assurer que chaque nœud peut vérifier les transactions à un moment cohérent. En outre, la sécurité dans le pire des cas et la stabilité du consensus doivent également être prises en compte. Le défi ici est donc de savoir comment mettre en œuvre une mise à l'échelle spécifique à l'application pour les applications en chaîne. Axiom vise à étendre les capacités d'accès aux données et de calcul pour les contrats intelligents afin de répondre aux besoins d'expansion de différentes applications.
Ce qu'Axiom construit, c'est ce qu'il appelle un coprocesseur Ethereum (coprocesseur ZK), qui permet à certains contrats intelligents de déléguer en toute confiance à notre système hors chaîne afin qu'ils puissent déléguer des lectures de données et des calculs vérifiables à Axiom. Pour émettre une requête à Axiom, un contrat intelligent peut envoyer une transaction à notre système en chaîne. Notre nœud hors ligne recevra la transaction et générera un résultat basé sur la requête historique d'Ethereum, et joindra une preuve de connaissance nulle pour prouver l'exactitude du résultat. Enfin, nous vérifions les résultats en chaîne et fournissons de manière crédible les résultats aux contrats intelligents en aval.
Ceci est similaire à la façon dont le CPU d'un ordinateur délègue le calcul au GPU et récupère les résultats lorsqu'ils sont connus. Ce concept s'appelait coprocesseur (Coprocesso) à ses débuts. Sur la diapositive, je montre une image d'un coprocesso mathématique avancé du début des années 1990 qui est analogue à ce que fait l'Axiom.
Nous pouvons avoir un aperçu des types d'opérations qu'Axiom peut effectuer. Chaque requête adressée à Axiom peut être divisée en trois parties.
La première est la partie lecture, qui correspond à la manière dont les requêtes Axiom sont saisies - nous pouvons lire de manière fiable les données historiques en chaîne.
La deuxième partie est que nous pouvons exécuter des calculs de validation sur ces données. Cela peut commencer par une analyse de base, comme la somme de certains nombres, la recherche du maximum ou du minimum, jusqu'à des calculs plus complexes. Par exemple, certaines agrégations ou vérifications de signatures à partir de la cryptographie, et même l'apprentissage automatique basé sur la connaissance zéro, comme la vérification du fonctionnement de certains algorithmes de réputation sur les données sociales de la chaîne ou l'utilisation de certains algorithmes d'apprentissage automatique dans des applications financières. A terme, nous fournirons des fonctions composites informatiques programmables via des machines virtuelles.
La dernière partie, après les étapes de lecture et de calcul, nous obtenons un résultat et jumelons toujours ce résultat avec une preuve à connaissance nulle que le calcul du résultat était valide. Par conséquent, nous vérifions cette preuve dans le contrat intelligent Ethereum, puis stockons le résultat pour une utilisation par le contrat.
Étant donné que tous les résultats renvoyés par Axiom sont en fait vérifiés avec des preuves à connaissance nulle, cela signifie que la sécurité de tout ce qui est renvoyé par Axiom est cryptographiquement équivalente à celle d'Ethereum lui-même. La philosophie d'Axiom est que nous ne voulons pas imposer d'hypothèses supplémentaires aux utilisateurs au-delà des hypothèses cryptographiques qu'ils ont déjà en utilisant Ethereum.
Ensuite, je présenterai en détail son principe de mise en œuvre, qui implique le concept d'opération de réflexion mentionné dans le titre du discours. Le principe de base qui rend tout cela possible est que chaque bloc de la blockchain contient un historique complet. Nous pouvons commencer par le bloc Ethereum actuel et revenir aux blocs précédents qui nous intéressent. En prenant tous les en-têtes de bloc entre le bloc passé et le bloc actuel, et en vérifiant la chaîne de hachage de ces en-têtes de bloc, nous pouvons en fait inverser l'engagement du bloc passé vers le bloc actuel.
Alors, quels sont les avantages de la réflexion ?
Nous pouvons prendre un bloc de l'Ethereum actuel et revenir à un bloc précédent qui nous intéresse. Si nous obtenons les en-têtes de bloc entre le bloc passé et le bloc actuel, nous pouvons inverser l'engagement du bloc passé dans le bloc actuel en vérifiant le chemin de hachage entre ces en-têtes de bloc. Ensuite, si nous sommes intéressés par des informations d'un bloc passé, nous pouvons donner une preuve d'inclusion dans l'engagement de ce bloc. Plus précisément, cela pourrait être une preuve Merkle Patricia Trie que les informations existent dans le trie d'état du bloc, le trie de transaction ou le trie de réception. Dans l'EVM, du moins en principe, toute information passée sur la chaîne n'est accessible que par la connaissance des hachages de blocs récents.
Malheureusement, cela coûte cher dans l'EVM. Comme nous venons de le mentionner, vous devez vérifier les chaînes de hachage et les preuves Merkle de tous les en-têtes de bloc, ce qui implique de nombreux calculs de hachage Keccak sur une grande quantité de données. Donc une fois qu'on remonte dans le temps, ça devient très difficile. Par conséquent, nous appliquons l'opération de réflexion en enveloppant cette preuve avec ZK dans l'EVM. Ainsi, au lieu de mettre tous les en-têtes de bloc passés et toutes ces preuves Merkle en chaîne, puis de les vérifier, nous vérifions sans connaissance s'il existe une séquence d'en-têtes de bloc passés et des preuves de vérification.
Cela a deux avantages. Tout d'abord, cela nous évite d'avoir à mettre des données de preuve dans les données d'appel. Deuxièmement, cela nous permet d'agréger des preuves, ce qui est impensable sans l'utilisation de ZK. L'idée ici est que lors de la vérification d'un nombre quelconque de calculs sur Ethereum, le coût du gaz est fixe, nous pouvons donc utiliser une seule preuve ZK pour vérifier une grande quantité d'accès aux données historiques.
Permettez-moi d'aborder brièvement les compromis du concept d'opération de réflexion basé sur ZK.
Il existe deux façons d'accéder aux données. La première est la façon dont vous le savez auparavant - vous pouvez accéder aux données sur Ethereum directement à partir du contrat intelligent. Cela a le très gros avantage que l'accès est synchrone. Par conséquent, vous pouvez appeler directement la fonction de lecture dans le contrat intelligent pour obtenir la valeur actuelle. Par exemple, lorsque vous négociez sur Uniswap, vous avez besoin de cette synchronicité. Cependant, il présente également de nombreuses limites. Votre puissance de calcul est limitée par les coûts de carburant et vous n'avez accès à aucune donnée historique.
Deuxièmement, si vous souhaitez profiter de la capacité de ZK à se refléter dans Ethereum, car vous devez générer des preuves que votre accès est correct, il n'y a aucun moyen de le faire de manière synchrone. Il n'y a donc en fait aucun accès direct à l'état actuel de la chaîne, car vous devez attester d'un état.
D'autre part, si vous vous autorisez à accéder aux données historiques de manière asynchrone, vous pouvez y appliquer des calculs presque illimités et avoir accès à d'énormes quantités de données. Par conséquent, en assouplissant le concept de synchronisation, l'accès aux données opérationnelles de Reflection basé sur ZK peut être considérablement étendu.
Nous examinons ensuite comment implémenter les opérations de réflexion via Axiom.
Tout d'abord, nous devons en fait conserver un cache de tous les blocs précédents dans notre contrat intelligent. Dans l'EVM, les 256 derniers hachages de bloc sont disponibles en mode natif. Nous pouvons prouver que dans chaque lot de 1024 blocs, le hachage du dernier bloc du lot précédent est validé dans le bloc suivant. De même, le hachage de l'avant-dernier bloc du lot précédent est validé dans le dernier bloc, et ainsi de suite. Par conséquent, nous pouvons inverser la vérification de cette chaîne de hachage et prouver la validité de cette chaîne de hachage grâce à une connaissance nulle.
Cela nous permet de mettre en cache les hachages de blocs à partir du bloc le plus récent jusqu'au bloc de genèse. En fait, nous l'avons implémenté dans notre contrat intelligent de réseau principal, qui contient des chemins Merkle mis en cache tous les 1024 hachages de bloc à partir du bloc de genèse.
Une autre caractéristique que nous ajoutons est Merkle Mountain Range. Il est construit au-dessus de ce cache de hachage de bloc, une structure de données qui nous permet de référencer chaque hachage de bloc dans Ethereum dans un ADN limité.
Une fois que nous avons construit le cache, nous pouvons interroger Axiom en validant les blocs dans le cache. Pour que cela fonctionne, nous devons prouver que chaque élément de données de l'historique Ethereum auquel nous essayons d'accéder est en fait engagé dans le cache d'un bloc. Deuxièmement, nous devons prouver que tous les calculs que nous effectuons sur cette requête sont corrects. Pour vérifier cela en chaîne, nous vérifions la validité de la preuve de connaissance zéro. Nous vérifions également qu'il est en corrélation avec les informations que nous avons enregistrées sur la chaîne. Nous établissons toujours la confiance dans nos caches ou nos caches de blocs et faisons correspondre les informations de ces caches de blocs avec des informations publiques dans des preuves à connaissance nulle.
Parlons maintenant des applications possibles de l'opération Réflexion envisagée.
L'axe horizontal représente la complexité des données, la quantité de données réellement nécessaire pour implémenter l'application. L'axe vertical représente la complexité de calcul, c'est-à-dire la quantité de ressources de calcul réellement nécessaires pour accomplir la tâche.
Par conséquent, le premier type d'application est une application qu'Axiom ou tout type de mécanisme d'opération de réflexion peut être implémenté sur Ethereum, mais le coût est légèrement plus élevé.
Quelques exemples de cela incluent la lecture de nonces de niveau consensus à partir d'en-têtes de bloc dans la couche de consensus Ethereum, la vérification de l'âge des comptes historiques ou la lecture de différents types de données oracle à partir d'informations sur les prix historiques. Dans l'EVM, diverses solutions peuvent être employées pour mettre en œuvre ces applications, mais en plaçant ces solutions dans la connaissance zéro, l'efficacité peut être augmentée.
Maintenant, il existe une autre classe d'applications qui nécessitent généralement plus d'accès aux données et donc plus de calculs. À mon avis, ces applications ne seraient pas possibles sans l'utilisation du coprocesseur ZK.
A titre d'exemple, une application intéressante est de permettre à un Roll-up sur Ethereum de lire l'état de la couche de base ou d'un autre Roll-up de manière fiable, en utilisant la connaissance zéro pour interagir. Une de ces applications pourrait être de permettre aux roll-ups de lire des instantanés de solde complet des jetons ERC20.
Si nous tournons notre attention du stockage vers l'historique des transactions des comptes, vous pouvez imaginer construire une réputation de confiance, une identité ou un système de notation de crédit en enregistrant l'historique complet des adresses Ethereum. Cela pourrait être utilisé pour la notation de crédit, ou pour vous donner accès à un certain type de DAO en chaîne, ou pour vous donner accès à l'émission de NFT personnalisés.
Il existe également une classe d'applications qui utilisent des données historiques en chaîne pour gérer réellement le protocole. Généralement connu sous le nom de comptabilité d'accord.
L'idée ici est que des protocoles existent pour coordonner le comportement des participants, et le principe de base de la coordination est la capacité de récompenser ou de punir les participants pour leur comportement. Si vous regardez de nombreux protocoles sur Ethereum, l'enregistrement des actions des participants est en fait entièrement conservé en chaîne. Ainsi, avec Axiom, nous pouvons imaginer que sur la base de l'ensemble complet des actions des participants au protocole, le protocole peut déterminer la structure de paiement, ou même imposer un certain type de pénalité aux participants, ce qui, selon nous, peut vraiment élargir l'espace de conception du protocole. applications.
Enfin, si nous remontons vraiment le niveau de calcul, nous pensons qu'il pourrait être très intéressant d'utiliser des modèles d'apprentissage automatique pour ajuster les paramètres en chaîne. Si vous pensez aux applications financières traditionnelles, il est très courant de modéliser des paramètres futurs complexes basés sur de grandes quantités de données historiques, telles que des données de prix, des données économiques, etc. Et quand on regarde la DeFi actuelle, elle est loin d'atteindre ce niveau. Je ne pense pas que DeFi devrait fonctionner exactement de la même manière que la finance traditionnelle, mais nous pensons que l'injection de certaines bases de données historiques et de modèles et d'informations basés sur l'apprentissage automatique peut aider à créer un protocole DeFi plus dynamique.
Ce ne sont là que quelques idées de ce que les opérations de réflexion peuvent apporter à la blockchain.