Aztec vs Miden : deux modèles architecturaux de confidentialité complètement divergents

Lorsque l’on compare @aztecnetwork et @0xMiden, la classification initiale est simple : ce sont deux solutions L2 avec confidentialité native et preuves ZK. En apparence, elles semblent suivre le même chemin. Cependant, leurs architectures fondamentales révèlent une divergence bien plus profonde que ce que leur catégorisation superficielle laisse penser. Le vrai contraste ne réside pas dans l’utilisation de ZK ou de la confidentialité, mais dans où et comment elles décident que l’exécution des transactions ait lieu.

Où la transaction s’exécute-t-elle réellement ?

C’est le point de basculement entre ces deux visions. Chez Aztec, les transactions privées sont simulées et exécutées côté portefeuille. Le client génère la preuve cryptographique localement, mais la validation et l’ordre sont assurés par le séquenceur. La structure est claire : portefeuille → génération de preuve → envoi au séquenceur → inclusion dans le bloc. La production de blocs suit un modèle séquentiel, avec un séquenceur et un comité de validateurs. C’est essentiellement un rollup orienté confidentialité, profondément intégré à la logique d’Ethereum.

Miden réimagine complètement ce processus. Chaque compte fonctionne comme son propre contrat intelligent autonome. La transaction s’exécute entièrement sur l’appareil de l’utilisateur. L’état global complet transite localement avant de générer une preuve STARK. Ce design transforme l’architecture en une chaîne avec exécution côté client, et non un rollup traditionnel. La différence n’est pas cosmétique ; c’est la base même du système.

En résumé : Aztec dit “rollup privé intégré” ; Miden dit “chaîne privée avec vérification côté client”. Cette distinction fondamentale engendre toutes les autres différences.

Modèles d’état : flexibilité versus naturalité

Aztec utilise un modèle hybride délibérément conçu pour permettre le choix. L’état public suit la structure d’Ethereum (basée sur des comptes). L’état privé adopte un style UTXO avec des notes chiffrées. Les développeurs décident explicitement quelles données sont publiques et quelles fonctions sont privées. C’est flexible, mais cela introduit une complexité inhérente.

Miden, en revanche, est purement basé sur des acteurs. Chaque compte fonctionne comme une entité indépendante. L’état est représenté par des engagements cryptographiques stockés sur la chaîne, tandis que l’état réel réside chez l’utilisateur. Ce design a une conséquence architecturale cruciale : il permet un parallélisme naturel. Comme les comptes sont indépendants et ne partagent pas de verrou global, plusieurs mises à jour peuvent être traitées simultanément.

L’implication de ce design est profonde : Aztec nécessite une coordination explicite entre public et privé ; Miden l’évite structurellement.

Philosophie de la confidentialité : fonction versus prédéfinie

Chez Aztec, la confidentialité est une fonction que les développeurs invoquent et contrôlent. Il est clair ce qui est privé versus public car c’est le programmeur qui le définit. Cette approche s’aligne avec la “privacy native d’Ethereum” : elle étend la plateforme en conservant son paradigme.

Chez Miden, la confidentialité est le paramètre par défaut du système. Les données de transaction sont visibles uniquement pour les parties concernées par conception architecturale, et non par choix. Ce pattern se rapproche davantage de la confidentialité de niveau Web2 : où les données privées ne quittent jamais le client.

La différence est profondément philosophique. Aztec demande : “Qu’est-ce que nous rendons privé ?” Miden demande : “Qu’est-ce que nous permettons d’être public ?”

Le flux d’un transfert privé simple

Un exemple pratique révèle ces divergences :

Flux Aztec : Le portefeuille simule la fonction privée → une preuve UTXO est générée → envoyée au séquenceur → validée et ordonnée → incluse dans un bloc.

Flux Miden : Le compte s’exécute localement sur l’appareil → l’état est mis à jour localement → une preuve STARK de la transition est générée → envoyée à un validateur → une nouvelle note cryptographique est créée.

Chez Miden, le transfert est une extension naturelle de la logique du compte. Chez Aztec, c’est une invocation discrète d’une fonction privée. Ce changement de mentalité a d’énormes implications pour l’expérience du développeur et celle de l’utilisateur.

Abstraction du compte : familiarité versus radicalisme

Les comptes d’Aztec restent proches de la structure d’Ethereum. Le modèle de signatures, la logique de contrat et les flux de validation (PXE) sont des motifs reconnaissables. La courbe d’apprentissage est progressive pour les développeurs familiers avec Ethereum.

Chez Miden, chaque compte est un contrat intelligent entièrement flexible. Multi-signature ? Récupération sociale ? Logique d’autorisation personnalisée ? Tout est intégré directement dans le code du compte, sans restrictions externes. C’est un design radicalement plus ouvert, mais qui demande aussi une plus grande sophistication dans l’implémentation.

Le vrai compromis : fonctionnalités versus adoption

Forces de Miden :

• Exécution parallèle des transactions (sans contenu global)
• Génération de preuves côté client (zéro confiance dans les serveurs)
• Confidentialité forte par défaut
• Mais nécessite : une nouvelle machine virtuelle, un nouvel écosystème d’outils, un matériel plus puissant côté client

Forces d’Aztec :

• Intégration profonde avec Ethereum (composabilité)
• Écosystème Noir mature et outils connus
• Architecture de rollup familière
• Mais implique : production séquentielle de blocs, séparation complexe entre public et privé

La question : laquelle est supérieure ?

La réponse dépend entièrement du cas d’usage. Aztec optimise la confidentialité dans le paradigme d’Ethereum. Miden déplace l’exécution hors chaîne pour construire un système parallèle, privé et scalable par conception. L’un est un L2 privé classique. L’autre est une tentative bien plus ambitieuse : redéfinir où et comment l’exécution elle-même a lieu. Et cette ambition de refonte est ce qui fait que le pattern Miden est plus qu’une simple variante — c’est une vision totalement différente de l’avenir de la confidentialité sur blockchain.