Auteur : ChiHaoLu (chihaolu.eth) Source : medium Traduction : Shanoba, Golden Finance

Cet article se concentre sur le développement de l’abstraction de compte (AA) dans la solution Aztec Layer 2 et les contenus associés. Je cite un certain nombre de ressources officielles d’Aztec, y compris la documentation officielle, les blogs et les tutoriels. Vous trouverez ces excellentes ressources dans la section des références à la fin de l’article !

Contexte

En raison de la complexité accrue d’Aztec par rapport à d’autres implémentations AA natives dans ZK-Rollups, les lecteurs peuvent bénéficier d’un peu de contexte pour mieux comprendre cet article.

• Familiarité avec les portefeuilles de contrats intelligents et leurs fonctionnalités
• Familiarité avec EIP-4337
• Familiarité avec l’abstraction de compte native dans ZK-Rollups
• Concepts de base de l’UTXO
• Le concept de base des ZK-Rollups
• Concepts de base des programmes de preuve à divulgation nulle de connaissance

Préambule

Jetez un coup d’œil à Aztec

Aztec est un réseau open source de couche 2 conçu pour assurer l’évolutivité et la protection de la vie privée d’Ethereum. Aztec s’appuie sur les preuves zkSNARK pour assurer la protection de la confidentialité et l’évolutivité via le service ZK-Rollup. Les utilisateurs d’Aztec n’ont pas besoin de tiers de confiance ou de mécanismes de consensus supplémentaires pour accéder aux transactions privées.

Nous savons tous que dans les ZK-Rollups traditionnels, « ZK » ne signifie pas nécessairement la confidentialité ; Il s’agit d’utiliser des preuves à divulgation nulle de connaissance (ZKP) pour prouver que certains calculs ont été effectués correctement hors chaîne. Cependant, dans Aztec, la confidentialité est implémentée dans ZK-Rollup en plus de l’évolutivité. En creusant plus profondément, dans le passé, les détails de chaque transaction étaient visibles publiquement sur la chaîne, mais chez Aztec, l’entrée et la sortie de chaque transaction sont cryptées. Ces transactions sont vérifiées par ZKP pour prouver que les informations cryptées sont exactes et proviennent de texte clair. Seul l’utilisateur qui construit ces transactions privées connaît les informations réelles en clair.

Même les caractères importants de ZK-Rollup, tels que Sequencer et Prover, ne peuvent pas déterminer ce qu’est le texte en clair. Toutes les informations relatives à la transaction, y compris l’expéditeur, le destinataire, les données de transaction et la valeur du transfert, sont masquées. Bien que seuls les utilisateurs eux-mêmes connaissent les détails de la transaction, ils peuvent toujours avoir confiance en l’exactitude de la transaction. Cette confiance découle du fait que seules les transactions légitimes peuvent générer des preuves valides à divulgation nulle de connaissance pour prouver leur exactitude.

Comment mettre en œuvre des transactions privées et comment vérifier leurs fondamentaux est un vaste sujet qui dépasse le cadre de cet article. En termes simples, ce dont nous avons besoin, c’est d’une « couche supplémentaire pour la vérification de la preuve à divulgation nulle de connaissance » pour valider les listes ZKP, chacune d’entre elles validant une transaction privée. C’est pourquoi on les appelle « ZK-ZK-Rollups ».

Qu’est-ce que le Noir ?

Dans Aztec, une abstraction de compte native est utilisée, ce qui signifie qu’il n’y a pas de différence entre un compte externe (EOA) et un compte contractuel. Tous les comptes sont des contrats intelligents. Par conséquent, nous donnerons un bref aperçu de l’écosystème de développement de contrats d’Aztec, car il est crucial de comprendre le développement de contrats. Toutefois, si vous n’avez pas l’intention d’élaborer vous-même le contrat de compte, la lecture et la compréhension de cet article ne vous obligent pas à allumer votre ordinateur et à rédiger le contrat. Il vous suffit de comprendre la logique du code de contrat de compte. Vous pouvez explorer la profondeur du sujet à votre guise !

Noir est un langage d’écriture de programmes SNARK, similaire à Circcom et ZoKrates. Non seulement il vous permet de générer automatiquement des contrats Solidity Verifier après la création du circuit, mais il peut également être utilisé pour écrire vos propres protocoles ou même des blockchains. Étant donné que Noir ne s’appuie pas entièrement sur Aztec (il ne compile pas selon un système de preuve spécifique), vous pouvez atteindre vos objectifs en implémentant un serveur backend et une interface de contrat intelligent pour le système de preuve.

Chez Aztec, Noir est utilisé pour écrire des contrats intelligents où les variables (états) et les fonctions peuvent être protégées par la confidentialité.

Qu’est-ce que le statut privé et les notes privées ?

Selon notre compréhension des blockchains publiques, tous les États sont généralement publics. En aztèque, il est important de saisir le concept d’État privé et comment le gérer (ajouter, modifier, supprimer). L’état privé est crypté et appartient à son détenteur. Par exemple, si je suis le propriétaire d’un contrat, une variable spécifique de ce contrat peut être chiffrée et masquée en tant qu’état privé. Il n’y a que moi, en tant que propriétaire de cet état privé, qui puisse déchiffrer le texte chiffré pour obtenir le texte en clair.

L’état privé est stocké en attachant uniquement l’arborescence de la base de données. Cela est dû au fait que la modification directe de la valeur d’état peut entraîner une fuite de beaucoup d’informations du diagramme de transaction. Cependant, la base de données ne stocke pas directement la valeur de l’état privé. Au lieu de cela, il les enregistre sous forme de notes privées sous forme cryptée (par exemple, x=0 -> x=1) addr=0x00 -> addr=0x01. Donc, en réalité, ces variables privées, bien qu’elles semblent être des variables, sont en fait constituées d’un tas de notes privées immuables. C’est l’abstraction des variables. Si ce n’est pas clair, passons à autre chose.

Lorsque vous devez supprimer un état privé, vous pouvez ajouter les caractères non valides associés à cet état privé à une autre base de données non valide pour l’invalider. Lorsque vous devez modifier l’état privé, invalidez-le d’abord, puis ajoutez-y un nouveau commentaire privé.

Nous aborderons bientôt le concept des annulateurs. Vous pouvez le considérer comme la clé dont vous avez besoin pour lier une note privée à son caractère invalide. Seul le propriétaire d’une clé non valide peut identifier et utiliser la note privée qui lui est associée.

À ce stade, les lecteurs avertis auront peut-être remarqué que cette structure est très similaire aux UTXO (sorties de transaction non dépensées), et nous pouvons itérer sur les UTXO pour déterminer l’état actuel de l’état privé (bien qu’il soit important de se rappeler que c’est l’utilisateur qui signe la transaction, pas l’UTXO ; Nous l’expliquerons plus tard).

! [TEg3TOpeZXF82AgjnmG7in3uwiZp3ZtIpGsNQvxc.png] (https://img.jinse.cn/7128680_watermarknone.png « 7128680 »)

Qu’est-ce qu’une note privée ? Un UTXO s’appelle une note, et nous parcourons cette arborescence de notes pour obtenir des informations sur l’état privé. Lorsque nous voulons modifier l’état privé, les étapes sont les suivantes :

1. L’utilisateur récupère toutes les notes privées liées à ce statut privé à partir de la base de données des notes.
2. L’utilisateur (qui est en fait le nœud Aztec que l’utilisateur exécute) atteste localement de l’existence de chaque annotation récupérée dans cette arborescence de base de données.
3. L’utilisateur ajoute un caractère non valide pour empêcher d’autres personnes de relire la même feuille.
4. L’utilisateur insère une nouvelle feuille (un nouveau commentaire) pour mettre à jour la valeur de cet état privé.

Le mécanisme AA d’Aztec

Qu’est-ce que la couche protocolaire et qu’est-ce que la couche applicative ?

Comme nous le savons tous, l’EIP-4337 vise à déplacer l’ensemble du processus de transaction vers la couche applicative, à mettre en œuvre un système de relais ouvert et à faire abstraction de la signature (mécanisme de vérification) et du modèle de paiement grâce à la nature programmable des contrats intelligents. Cependant, pour l’abstraction de compte natif, que ce soit à l’époque de StarkNet, zkSync ou Aztec, qui est l’objet de cet article, certains éléments doivent être gravés dans le protocole de la couche 2 afin de fonctionner correctement. Par exemple, dans Aztec, les clés de chiffrement et les clés non valides doivent être implémentées au niveau du protocole.

Comprendre l’abstraction native des comptes nécessite une compréhension plus approfondie du fonctionnement de l’ensemble de la chaîne (en supposant qu’elle soit appelée « native », la logique d’exécution d’AA étant naturellement liée à un protocole de couche 2 spécifique). Par exemple, à l’ère de zkSync, il est nécessaire de comprendre le contrat système, dans StarkNet, il est nécessaire de comprendre comment fonctionne le séquenceur, et dans Aztec, il est crucial de comprendre le rôle de ces « clés et leur état privé sous-jacent ».

Points d’entrée du compte et phases de vérification

Dans Aztec, contrairement à d’autres implémentations de l’abstraction de compte, il n’y a pas de nom de fonction strictement défini (signature de fonction) comme point d’entrée du contrat de compte (par exemple, validateUserOp dans EIP-4337, validateTransactionzkSync Era et __validate__StarkNet). L’utilisateur est libre de choisir n’importe quelle fonction du contrat de compte comme point d’entrée et d’envoyer une transaction avec les paramètres correspondants.

La fonction choisie par l’utilisateur (nous l’appelons entrypoint()) doit être privée (exécutée dans l’environnement d’exécution privé de l’utilisateur). Il ne peut être appelé qu’à partir du client du propriétaire du contrat de compte (le portefeuille de l’utilisateur). Lorsque la fonction entrypoint () du portefeuille de l’utilisateur est exécutée localement, elle génère également une preuve à divulgation nulle de connaissance. Cette attestation informe le protocole Aztec de la phase de vérification que l’exécution off-chain a eu lieu et a réussi.

Limites de la phase de validation

Cela s’étend également à la question de savoir s’il faut ou non imposer des restrictions sur ce qui peut être fait pendant la phase de validation. Il est bien connu que, puisqu’il n’y a pas de limite de coût pour la validation des transactions (essentiellement, la validation des transactions est une vue de fonction), un attaquant peut effectuer une attaque par déni de service (DOS) sur le mempool pour compromettre le bundler (EIP-4337) ou l’opérateur/séquenceur (AA natif). EIP-4337 définit quels opcodes sont interdits et comment l’accès au stockage est restreint. zkSync Era assouplit l’utilisation de certains OpCode, tandis que StarkNet n’autorise pas du tout les appels de contrats externes.

Étant donné que le protocole Aztec implique que le client valide une preuve à divulgation nulle de connaissance jointe, plutôt que d’appeler une fonction de validation pour déterminer que le résultat est ou , trueAztecfalse, contrairement à d’autres protocoles, n’impose aucune restriction pendant la phase de validation. Le point d’entrée de contrat dans le compte peut librement appeler d’autres contrats, accéder à n’importe quel stockage et effectuer n’importe quel calcul.

Flux d’interaction

Plus en détail, dans zkSync Era et StarkNet, seul le « contrat de compte » peut initier une transaction, car le protocole appelle une fonction spécifiée comme point d’entrée, imposant cette restriction. Cependant, dans Aztec, « tous les contrats » peuvent initier des transactions, car il n’y a pas de limite à la fonction que le protocole appelle comme point d’entrée. Cela signifie que sur Aztec, il ne s’agit plus d’un flux d’interaction fixe dans lequel un utilisateur envoie une transaction à un rôle spécifique (tel que le contrat EntryPoint dans EIP-4337 ou le séquenceur/opérateur dans Native AA), puis appelle le contrat cible. Les utilisateurs peuvent envoyer des transactions via le portefeuille et laisser directement le contrat cible effectuer les interactions pertinentes, ce qui améliore considérablement la flexibilité.

Si vous êtes familier avec EIP-2938, une autre implémentation d’AA, vous constaterez qu’Aztec s’apparente davantage à l’approche multi-locataire. Cependant, il s’agit d’un sujet plus profond que vous pouvez explorer par vous-même.

Clés dans votre compte Aztec

Dans Aztec, chaque compte dispose généralement de deux clés principales : la clé principale de signature et la clé principale de confidentialité.

Clé de signature

La clé de signature est utilisée pour représenter l’autorisation de l’utilisateur à effectuer une action spécifique à l’aide de la clé privée. Un exemple simple est lorsqu’un utilisateur enregistre une clé publique dérivée de la clé de signature dans le contrat de compte. La signature générée peut ensuite être restaurée dans le contrat en signant la transaction ou le message à l’aide de cette clé de signature pour vérifier qu’elle correspond à la clé publique enregistrée dans le contrat (également connue sous le nom de clé contrôlée par le propriétaire, qui est stockée sous la forme d’une clé). addressSolidity wallet).

Le choix de l’algorithme pour la courbe elliptique des signatures numériques appartient à l’utilisateur. Par exemple, Ethereum utilise secp256k1, tandis qu’Aztec fournit un exemple de schnorr à utiliser. Dans le contrat de compte, la fonction entrypoint() agit comme un point d’entrée (la source de l’appel) et est utilisée par la logique de validation (is_valid_impl()) pour vérifier si la signature Schnorr correspond à la clé publique d’enregistrement std ::schnorr ::verify_signature(…).

! [eWwFvxmMF7pNt0axLcucSvjcig6QHMXl2HKH3luz.png] (https://img.jinse.cn/7128683_watermarknone.png « 7128683 »)

La clé de signature est essentiellement la même que la clé contrôlée par le propriétaire dans le portefeuille de contrats intelligents que nous connaissons, elle devrait donc être relativement facile à comprendre. En fait, les clés de signature ne sont pas absolument nécessaires. Si le développeur du compte a mis en place un mécanisme de vérification différent, il se peut que le compte ne dispose pas d’une clé de signature.

Clé maîtresse de confidentialité

La clé principale de confidentialité de votre compte Aztec n’est pas transférable ; Chaque compte Aztec est lié à une clé principale privée. La clé principale privée dérive la clé principale publique, qui est ensuite hachée avec le code du contrat pour générer l’adresse du contrat de compte.

! [9WujRrvfd8YccfQkh9kbCtz0O1GVAKvNVJI7kXtm.png] (https://img.jinse.cn/7128684_watermarknone.png « 7128684 »)

Nous public_master_key l’account_address, l’partial_address et collectivement de l’utilisateur comme l’adresse complète du compte. Lorsqu’il s’agit d’un état privé, l’utilisateur doit fournir ces trois informations afin que quiconque puisse vérifier que la clé publique correspond à l’adresse prévue.

Cependant, s’il s’agit d’une application public_master_key qui n’a pas l’intention de gérer l’état privé et qui est manquante (par exemple DeFi), vous pouvez simplement remplir ce champ public_master_key 0 pour indiquer qu’elle ne souhaite pas recevoir de notes privées.

Ainsi, alors qu’Aztec nous permet de mettre en œuvre un mécanisme de vérification et même un mécanisme de récupération dans le contrat de compte pour améliorer la sécurité du compte, le mécanisme lié à la clé principale de confidentialité est imprimé dans le protocole et lié à l’adresse. Par conséquent, il n’est pas interchangeable.

L’implication ici est que cette clé est tout aussi importante que la clé privée d’un EOA (compte externe) dans Ethereum, ce qui en fait un point de défaillance unique (SPoF) pour un compte. Si un utilisateur perd ou si la clé principale de confidentialité d’un compte est volée, il ne fait aucun doute que le compte ne sera pas récupérable.

La clé principale de confidentialité utilise également un processus similaire à BIP-32 pour exporter les clés de chiffrement et les clés non valides. Les utilisateurs peuvent utiliser différentes clés de chiffrement et des clés non valides dans différentes applications ou actions pour garantir la confidentialité et la sécurité.

Clé de chiffrement

La clé publique de la clé de chiffrement est utilisée pour chiffrer la note privée, tandis que la clé privée est utilisée pour la déchiffrer. Par exemple, dans un scénario de transfert de jetons, si je (l’expéditeur du jeton) veux transférer des jetons à mon ami (destinataire du jeton), je dois chiffrer la note privée (le transfert de jetons implique de changer les variables, essentiellement l’équilibre consiste à modifier la variable d’état privée UTXO à l’aide de la clé publique cryptographique de mon ami) et l’envoyer.

D’un point de vue extérieur, sans connaître la clé privée cryptographique du destinataire du jeton, il ne peut pas déchiffrer cette note privée ou savoir qui est le destinataire du jeton.

Caractère nul

Chaque fois qu’une note privée est utilisée, un caractère non valide dérivé de ce commentaire privé est généré (chiffré avec une clé non valide). Ce mécanisme est utilisé pour éviter les doubles dépenses (pour empêcher d’autres d’utiliser la même méthode pour déterminer l’emplacement d’un billet de banque ou pour déduire des fonds deux fois) car le protocole aztèque vérifie si les caractères invalides sont uniques. Afin de faire correspondre ce caractère non valide à une note privée, une clé privée non valide est nécessaire pour le déchiffrer, de sorte que seul son propriétaire peut établir une relation entre les deux.

Transactions aztèques

Décrire le concept d’une transaction dans Aztec peut être difficile car il peut être facilement confondu avec un UTXO (Private Notes) et le mode d’exécution d’une transaction dans EVM et Aztec est complètement différent.

Dans Aztec, chaque transaction est diffusée sous la forme d’une preuve à divulgation nulle de connaissance (évidemment pour des raisons de confidentialité). Les utilisateurs doivent effectuer des calculs localement sur leurs nœuds (applications de portefeuille ou clients) pour générer des preuves correspondant aux transactions, plutôt que de simplement envoyer des objets de transaction au mempool du mineur ou à tout opérateur de couche 2 via l’API RPC comme nous le faisions auparavant.

Hachages et nonces de transaction

Lorsqu’un utilisateur crée une transaction localement, il y a deux éléments importants :

1. Adresse de l’expéditeur : Il s’agit de l’adresse du contrat de compte qui traite la transaction. Dans ce contrat de compte, il y a le point d’entrée que nous avons mentionné précédemment, qui sert de fonction de vérification pour les parties externes afin de vérifier si l’action (transaction) est autorisée par le propriétaire du compte.
2. Données de charge utile : Il s’agit d’informations sur la transaction, telles que la signature, l’adresse du contrat de destination, la valeur, les données, etc.

! [xReWU4p6VrxP45q5EYNXZGAziaZhIG1DTrjeO4yD.png] (https://img.jinse.cn/7128688_watermarknone.png « 7128688 »)

Au niveau du protocole d’Aztec, le hachage de chaque transaction valide est utilisé comme un moyen d’empêcher la même transaction d’être exécutée plusieurs fois. Le développeur du contrat de compte peut décider s’il doit y avoir un nonce dans le contrat de compte et la logique associée. Par exemple, ils peuvent définir des exigences telles que s’assurer que le champ nonce de la transaction est strictement augmenté ou que la transaction peut être traitée dans n’importe quel ordre.

Étant donné qu’il n’y a pas d’exigence stricte de nonce au niveau du protocole, Aztec n’est pas en mesure d’annuler une transaction en attente en soumettant une nouvelle transaction avec le même nonce et des frais de gaz plus élevés.

Exécuter la requête

Comme mentionné précédemment, l’utilisateur peut spécifier n’importe quelle fonction dans le contrat de compte comme point d’entrée en fonction de la situation, et l’opération dans Aztec n’est pas contrôlée par un simple objet de trading. En fait, ce qui indique au compte du contrat ce qu’il doit faire, c’est un objet appelé « demande d’exécution ». L’objet représente le comportement de l’utilisateur, par exemple « Appeler la fonction de transfert sur le contrat avec 0x1234 des paramètres suivants ».

L’utilisateur initie une transaction localement dans le portefeuille, où le sender_address est l’adresse du contrat de compte, contenant les données d’encodage pertinentes de la fonction dans le contrat cible d’appel de charge utile transfer(), et la signature qui peut être vérifiée par le contrat de compte. Le portefeuille convertit ces deux éléments en une demande d’exécution.

Le portefeuille saisit ensuite une note privée, une clé de chiffrement ou un secret non valide dans une machine virtuelle locale pour simuler cette demande d’exécution. Au cours du processus de simulation, une trace d’exécution sera générée, qui sera remise au prouveur pour générer une preuve à divulgation nulle de connaissance. Cette preuve montre que ces calculs (l’exécution de fonctions privées) sont bien effectués localement par l’utilisateur.

Grâce à ce processus, nous obtenons deux informations : proof et private_data (la sortie du circuit privé du noyau pour cette transaction). Le portefeuille envoie ensuite l’objet de transaction contenant ces deux informations au mempool Sequencer d’Aztec et termine la transaction.

ZKP basé sur le client au lieu d’un environnement d’exécution de type EVM

Dans Aztec, nous ne nous contentons pas d’entrer toutes les informations dans une machine de Turing comme l’EVM pour générer l’état mis à jour. Au lieu de cela, il s’appuie sur les circuits de chaque Dapp pour déterminer comment les informations de confidentialité doivent fonctionner. Cela signifie que les développeurs Dapp doivent disposer d’un moyen de prouver l’état des variables contractuelles. Prenons l’exemple du solde de l’utilisateur dans un contrat de token ERC-20. Si nous voulons transférer 10 tokens DAI, le contrat peut avoir la logique suivante :

1. Vérifiez si le solde de l’expéditeur est supérieur à 10 DAI (c’est-à-dire > 10 DAI).
2. Si le solde de l’expéditeur est suffisant, un caractère non valide est créé pour indiquer la destruction des 10 DAI de l’expéditeur (ce qui peut compenser la possession par l’expéditeur du billet privé de 10 DAI).
3. Créez une nouvelle note privée pour le destinataire.
4. Diffusez et cryptez tous les messages transmis avec 10 DAI.

D’un point de vue extérieur, ils ne peuvent voir que de nouvelles nullités et commentaires apparaître, et ils sont tous chiffrés. Ainsi, tout le monde sait qu’un nouvel accord a eu lieu, mais ce qui se passe exactement à l’intérieur n’est connu que des participants impliqués.

! [B2NwqMIhntBOllrlchIWeaetEbkSSdoTARJiM27A.png] (https://img.jinse.cn/7128690_watermarknone.png « 7128690 »)

En savoir plus sur les contrats de compte Aztec

Portefeuille

Les portefeuilles dans Aztec sont une partie importante de la gestion des interactions des utilisateurs avec la blockchain et leurs données privées. Voici un récapitulatif des tâches que le portefeuille Aztec doit gérer :

1. Créer un compte : Le portefeuille doit permettre aux utilisateurs de créer de nouveaux contrats de compte, ce qui signifie essentiellement déployer de nouveaux contrats de compte sur la blockchain.
2. Gestion de la clé privée : Le portefeuille est responsable de la gestion de la phrase de récupération et de la clé privée de l’utilisateur, y compris la clé principale de confidentialité et la clé de signature (selon la conception du contrat de compte). Cette gestion peut également être étendue à l’intégration de portefeuilles matériels.
3. Afficher les comptes : les utilisateurs doivent être en mesure de consulter leurs comptes et les statuts associés, y compris les soldes et autres statuts privés. Cela signifie que le portefeuille doit maintenir une base de données locale de toutes les notes privées liées à l’utilisateur.
4. Interagissez avec les Dapps : Les portefeuilles doivent faciliter l’interaction entre les utilisateurs et les Dapps. Lorsqu’un utilisateur interagit avec une Dapp, celle-ci peut demander l’envoi d’une transaction à partir du compte de l’utilisateur.
5. Consentement de l’utilisateur : Les Dapps peuvent exiger le consentement de l’utilisateur pour afficher certains états du contrat, tels que le solde du contrat de jeton. Pour exposer ces états, le portefeuille doit être en mesure de recevoir les demandes des utilisateurs (car l’exposition des soldes nécessite le consentement de la clé de l’utilisateur).
6. Générer une preuve : Pour envoyer une transaction au nom d’un utilisateur, le portefeuille doit être en mesure de générer une preuve localement. Il s’agit de créer et de traiter des preuves de validité des transactions à divulgation nulle de connaissance.

Un point clé à noter est que le portefeuille doit analyser tous les blocs en commençant par le bloc genesis, utiliser la clé de l’utilisateur pour découvrir et déchiffrer les notes privées pertinentes, puis les stocker dans une base de données locale pour une utilisation future. C’est essentiel pour faciliter l’interaction avec les utilisateurs et garantir que les données privées de l’État peuvent être gérées efficacement.

Vous avez mentionné un autre aspect important d’Aztec, à savoir la nécessité pour les utilisateurs de diffuser l’adresse complète. Lorsqu’un portefeuille crée un billet cryptographique pour le destinataire d’une transaction cible, il doit également être en mesure d’obtenir l’adresse complète du destinataire. Pour ce faire, il suffit de saisir ou de maintenir manuellement une base de données locale de l’adresse du destinataire. Pour plus de détails à ce sujet, veuillez vous référer à la documentation officielle aztèque.

Contrat de compte

Dans Aztec, les tâches principales d’un contrat de compte sont de vérifier les signatures (confirmant que les transactions sont autorisées par le titulaire du compte, et donc plus largement autorisées, plutôt que nécessairement « vérifiées par un algorithme de signature numérique spécifique »), de gérer la consommation de gaz et d’invoquer d’autres contrats.

Il s’agit d’un exemple officiel d’un contrat de compte Aztec utilisant l’algorithme de signature Schnorr. Le point d’entrée de toutes les transactions est la fonction entrypoint() (vous êtes libre de choisir la fonction ou le nom comme point de départ, mais dans ce cas, entrypoint() est utilisé).

! [LahY9kfNGKkYkSm5ULPlReKATiTA3K5bjFGIClh0.png] (https://img.jinse.cn/7128692_watermarknone.png « 7128692 »)

Lorsque nous appelons le compte entrypoint() avec la charge utile de la pièce jointe, le contrat de compte entrypoint() appellera la bibliothèque de compte Aztec AA entrypoint().

! [OskBKScb0LqWpcTMIuhBMjeSB151sFvSWbwXl.png] (https://img.jinse.cn/7128697_watermarknone.png « 7128697 »)

Aztec n’exige pas que nos contrats de compte soient importés dans les bibliothèques de comptes EntrypointPayload et Aztec AA ; Vous êtes libre de concevoir votre propre logique de contrat de compte.

! [HNskT1CkOOPiZZaAVvqlJNf7L5VxU39Fz9ir2Ica.png] (https://img.jinse.cn/7128698_watermarknone.png « 7128698 »)

est le contexte, un objet qui est disponible dans toutes les fonctions de Aztec.nr. Contient toutes les informations du noyau nécessaires à l’exécution de l’application contextuelle. Citation de la documentation officielle aztèque. - Quel est le contexte ?

Ce qui précède est le code entrypoint() de la bibliothèque de compte Aztec AA. Il est chargé de déterminer si l’opération est autorisée par le propriétaire du compte en fonction de la fonction de validation () définie sur le contrat de compte est_valid_impl, et effectue les appels nécessaires à la mise en œuvre de l’opération _calls requise pour la transaction.

Cela signifie que si vous souhaitez référencer cette bibliothèque Aztec AA et que votre contrat de compte n’a pas d’implémentation est_valid_impl avec la même signature de fonction, cette étape échouera.

! [QZuhkG4BTiKMQF4hFZKGw0gi9MBlU5VGcDjyQyU9.png] (https://img.jinse.cn/7128699_watermarknone.png « 7128699 »)

Un autre détail clé de l’implémentation est d’utiliser get_auth_witness() pour récupérer les signatures. Vous pouvez consulter les références ci-dessous pour en savoir plus sur le fonctionnement des Témoins. En termes simples, un témoin est « une autorisation donnée à l’utilisateur de faire ce qu’il veut ».

Un témoin d’authentification est un schéma permettant de vérifier les opérations sur Aztec, afin que les utilisateurs puissent autoriser des tiers, tels que des protocoles ou d’autres utilisateurs, à effectuer des actions en leur nom. Citation de la documentation officielle aztèque. — Témoins certifiés

La raison pour laquelle on l’appelle « témoin » plutôt que simplement « signature » est que la façon dont le contrat de compte est vérifié n’implique pas nécessairement la vérification de la signature.

Par exemple, supposons qu’il y ait une opération qui transfère 1000 jetons du compte d’Alice vers une plateforme DeFi. Dans ce cas, le contrat de jeton doit interroger le contrat de compte d’Alice pour voir si elle approuve « l’action ». Cette « action » nécessite qu’un témoin d’authentification soit généré dans le portefeuille d’Alice (localement), qui peut ensuite être vérifié par le biais de son contrat de compte. Si le contrat de compte est vérifié avec succès, le contrat de jeton saura que « l’action » a été autorisée.

! [WJkuu8NWicgcHvCyH08YpHhjYtTtYiP8GbRxwwKs.png] (https://img.jinse.cn/7128700_watermarknone.png « 7128700 »)

En conclusion

Pour l’instant, Aztec n’a pas mis en place de mécanisme de redevances, et son objectif est également de faire abstraction du paiement des frais. Cela signifie que pour qu’une transaction soit considérée comme valide, elle doit prouver qu’elle a bloqué suffisamment de fonds pour couvrir ses propres frais. Cependant, il ne précise pas d’où doivent provenir ces fonds, ce qui permet d’effectuer facilement des paiements ou des paiements en nature grâce à un échange instantané.