Découvrez comment Aztec unité l'exécution privée et publique sur L2

Contenu d'apprentissageicon

Apprenez avec Aztec (AZTEC) : Des contrats intelligents axés sur la confidentialité sur Ethereum L2

Introduction : Aztec est une couche 2 axée sur la confidentialité qui permet aux développeurs de créer des contrats intelligents avec un état privé et public, ainsi qu'une exécution privée et publique, permettant des applications à « confidentialité sélective » qui ressemblent à des DeFi normaux — sans exposer tout sur la chaîne.

Qu'est-ce qu'Aztec ?

Aztec est un réseau de couche 2 axé sur la confidentialité dès la conception, tout en permettant la composable publique lorsque nécessaire.
L'idée principale est simple :
  • Exécution privée et état privé pour les actions utilisateur sensibles (soldes, identité, intention, stratégie).
  • Exécution publique et état public pour les éléments qui doivent être globalement visibles (liquidité publique, logique de contrat publique, état partagé).
Au lieu de choisir « tout public » ou « tout privé », Aztec prend en charge les applications hybrides.

Comment fonctionne une transaction sur Aztec

Aztec divise l'exécution en deux environnements distincts :
  1. Environnement d'exécution privé (PXE) — s'exécute côté utilisateur

Les fonctions privées sont exécutées côté client dans le PXE (prononcé « pixie ») pour maximiser la confidentialité.
Le PXE :
  • exécute des fonctions privées localement
  • possède les clés + notes
  • génère des preuves à divulgation nulle de connaissance pour les opérations privées
  • est inclus dans aztec.js (TypeScript), exécutable dans Node ou le navigateur
  1. VM publique (AVM) — s'exécute sur les nœuds Aztec

Les fonctions publiques s'exécutent sur le réseau dans la Machine Virtuelle Aztec (AVM), conceptuellement similaire à l'EVM (donc l'intuition d'efficacité en gaz s'applique davantage comme avec Solidity).

Règle d'exécution directionnelle (important)

Une transaction passe de privé → public :
  • Les fonctions privées peuvent mettre en file d'attente des fonctions publiques pour qu'elles s'exécutent plus tard.
  • Les fonctions publiques ne peuvent pas appeler les fonctions privées.
Cette séparation est intentionnelle : le réseau public ne doit pas pouvoir « atteindre » l'exécution privée.

État privé vs état public : Notes, nullificateurs et arbres

Aztec utilise différents modèles d'état en fonction de la confidentialité :

État privé = « notes » de type UTXO

L'état privé est stocké sous forme de notes (blocs de données similaires aux UTXO). Pour maintenir la confidentialité :
  • Les notes sont ajoutées à un arbre UTXO en ajout uniquement
  • Lorsqu'une note est « dépensée/supprimée », un nullifier est créé
  • Les nullifiers sont stockés dans un arbre de nullifiers distinct
Cela permet au réseau de faire respecter la règle « dépensé une seule fois » sans révéler le contenu privé des notes.

État public = stockage public de type compte

L'état public se comporte davantage comme Ethereum :
  • stocké dans un arbre de données public
  • mis à jour directement et visible sur la chaîne
Point clé pour les développeurs :
  • Travail d'état privé = engagements + nullificateurs (prouver la correction sans révéler les données)
  • État public = mises à jour directes (comportement normal du stockage sur blockchain)

Abstraction de compte : chaque compte est un contrat intelligent

Aztec intègre l'abstraction de compte au niveau du protocole :
  • Il n'y a pas d'EOA (aucun compte simple « keypair »)
  • Chaque compte est un contrat intelligent
  • Les développeurs peuvent définir leurs propres règles pour :
    • authentification (signatures, multisig, passkeys, logique personnalisée)
    • politiques d'autorisation (limites, autorisations, clés de session)
    • nonce / protection contre les rejeux
    • stratégie de paiement des frais (payer les frais en différents tokens, modèles de parrainage, etc.)

Pourquoi cela aide contre les attaques DoS (le problème « la validation est coûteuse »)

Le modèle d'Aztec effectue la validation complexe côté client :
  • Le client valide et génère une preuve ZK indiquant que « la validation a réussi »
  • Le séquenceur vérifie une preuve de taille constante
  • Ainsi, la complexité de la validation n'augmente pas le coût de vérification du réseau
Cela permet une logique de compte « power-user » sans ralentir la chaîne.

Clés dans les comptes Aztec (axés sur la confidentialité)

Chaque compte Aztec est soutenu par 3 paires de clés :
  • Paire de clés Nullifier : utilisée pour le calcul des nullifiers de notes
  • Paire de clés de visualisation entrante : utilisée pour chiffrer les notes destinées au destinataire
  • Paire de clés de visualisation sortante : utilisée pour chiffrer les notes destinées à l'expéditeur
Étant donné que les comptes sont des contrats intelligents, ils ne possèdent pas automatiquement une paire de clés de signature — l'authentification dépend de la conception du contrat de compte.

Témoins d'authentification : Plus sûrs que les « approbations infinies »

Aztec remplace le modèle à risque « approbation infinie » par des Témoins d'authentification (AuthWit) :
  • au lieu d'accorder une autorisation illimitée à perpétuité,
  • les utilisateurs autorisent des actions spécifiques avec des paramètres spécifiques
Cela est conçu pour réduire le risque d'autorisation persistante tout en permettant une bonne expérience utilisateur (regroupement, automatisation).

Développez sur Aztec avec Noir

Les contrats intelligents Aztec sont écrits en Noir, un langage axé sur les preuves zero-knowledge pour écrire des programmes/contrats vérifiables. Une alerte importante du documentation : les fonctions privées peuvent être écrites de manière défectueusement non optimisée, car la preuve repose sur une intuition de performance différente de l'exécution normale — apprendre « comment écrire du Noir performant » est donc essentiel.