Architecture technique d'Anoma : comment fonctionne le Web3 centré sur l'intention ?

Contrairement aux blockchains classiques où l'utilisateur signe chaque étape d'une transaction, sélectionne manuellement les Bridges et trace son chemin, le paradigme centré sur les intentions fait de « l'état souhaité » sa primitive fondamentale : l'utilisateur énonce des objectifs et des contraintes, et le système se charge de la découverte de contreparties, du calcul des itinéraires et de l'exécution multi-chaîne. Anoma conçoit les intentions comme universelles, composables et indépendantes de toute dApp particulière, permettant à la fois l'appariement DeFi, les paiements confidentiels, le trading NFT, le financement quadratique et bien d'autres cas, le tout sous une architecture unique — sans que chaque application ait besoin de son propre carnet d'ordres centralisé ou de middleware Web2.

Du point de vue de l'évolution des infrastructures blockchain, Anoma marque un saut du « règlement programmable » vers les « applications décentralisées full-stack ». La couche de règlement repose toujours sur la sécurité des chaînes existantes, mais la découverte de contreparties et la résolution sont désormais intégrées au protocole. Sa différenciation technique tient au déchiffrement à seuil Ferveo, à l'environnement d'exécution confidentiel et composable Taiga, ainsi qu'aux commits atomiques multi-chaîne pilotés par Chimera Chain et Paxos hétérogène. Parcourons l'architecture module par module : son fonctionnement, sa montée en charge, ses mécanismes cross-chain et de confidentialité, ainsi qu'un regard objectif sur les défis et l'avenir de cette voie.

Qu'est-ce que l'architecture centrée sur les intentions ?

Dans Anoma, une intention est l'expression par un utilisateur d'une préférence sur l'état du système — elle peut décrire une transition d'état complète (par exemple, Alice envoie USDT à Bob) ou une contrainte partielle qu'un solveur devra compléter (par exemple, « verser une prime selon la température à Berlin »). Au niveau architectural, les intentions sont des chaînes d'octets opaques ; la couche applicative définit les actifs et les règles métier.

L'architecture centrée sur les intentions peut se diviser en trois générations :

Anoma oppose le déclaratif (exprimer ce que l'on veut) à l'impératif de l'EVM (dire comment le faire). Le concept initial d'« Intent Machine » (IM) a évolué vers ARM (Abstract Resource Machine) en 2024–2025, modélisant les changements d'état comme création et consommation de ressources, les intentions étant validées par les règles ARM.

Le DOS (système d'exploitation décentralisé) s'articule en : couche application (Anoma App + SDK), couche réseau (Intent Gossip/Interpool + solveur) et couche règlement (adaptateurs de protocole par chaîne + instance Fractal optionnelle). À partir de septembre 2025, le lancement du mainnet a priorisé XAN et la gouvernance sur Ethereum, ARM s'étendant progressivement à Base, Arbitrum et BNB Chain via un adaptateur de protocole EVM.

Comment fonctionne le réseau de solveurs ?

Le réseau de solveurs constitue le moteur d'exécution de l'architecture centrée sur les intentions, prenant en charge les tâches de recherche NP que les relayeurs centralisés, les Market makers ou les séquenceurs effectuent habituellement.

Déroulement type :

1. Création : L'utilisateur signe une intention via une interface applicative, en y joignant éventuellement des frais conditionnels, payables uniquement en cas de règlement réussi.
2. Diffusion : Le client envoie l'intention aux nœuds Intent Gossip (couche réseau, également appelée Interpool) — un réseau P2P décentralisé sans moteur d'appariement unique.
3. Écoute et appariement : Les solveurs fonctionnent sans autorisation préalable, s'abonnent à tout ou partie des intentions et recherchent des sous-ensembles composables au sein du pool d'intentions connu et des états de chaîne.
4. Construction de transaction : Plusieurs intentions sont combinées en une transition d'état complète (transaction) respectant les règles ARM et celles de la couche de règlement. Dans le modèle déclaratif, le soumetteur doit seulement garantir que l'état final est correct, sans avoir à faire confiance aux chemins de contrats proxy intermédiaires.
5. Règlement : La transaction est soumise à la chaîne sous-jacente pour confirmation via un adaptateur de protocole ou une instance Fractal.

Les solveurs peuvent être spécialisés (routage de stablecoins, services de preuve ZK) ou généralistes. Sur le plan économique, lorsque les intentions portent des frais ou que des écarts existent, la concurrence conduit à une meilleure exécution. Les nœuds Gossip et le solveur final peuvent se partager les frais d'intention ; la couche de consensus perçoit des frais d'ordonnancement. Les futures phases du mainnet pourraient introduire le staking de XAN et le slashing pour dissuader les comportements malveillants ou paresseux (sous réserve des mises à jour officielles).

Contrairement aux intentions propres à un scénario comme CoW Protocol ou UniswapX, Anoma met l'accent sur les intentions généralisées : toute application peut définir son propre format d'intention, en fournissant des prédicats de validité et des algorithmes de solveur.

Comment le consensus Fractal améliore la scalabilité

Une instance Fractal est une unité de déploiement indépendante du protocole de consensus et d'exécution d'Anoma, qui combine :

• Domaine de sécurité : Les utilisateurs font confiance à un ensemble spécifique de validateurs formant un quorum byzantin tolérant aux pannes.
• Domaine de concurrence : Ordonne uniquement les transactions au sein de cette instance.
• Domaine de disponibilité des données : Fragments d'état interrogeables depuis l'extérieur.

Chaque instance Fractal est souveraine — elle ne dépend pas d'autres instances pour fonctionner. Les ensembles de validateurs peuvent se chevaucher, permettant un règlement atomique multi-chaîne. Les instances peuvent personnaliser la résistance Sybil (PoS, PoA, etc.), la tarification du gas et la gouvernance locale, réalisant une « architecture homogène, sécurité hétérogène ».

Typhon est le moteur de consensus et d'exécution de production d'Anoma, mêlant Narwhal (un mempool basé sur DAG pour un débit de propagation plus élevé), Paxos hétérogène (commits atomiques à travers des quorums de chaînes hétérogènes) et des partitions d'exécution concurrentes. Une innovation clé est la séparation de l'ordonnancement de la validité d'exécution : les « tentatives de solution » du solveur peuvent d'abord être ordonnées via consensus, puis validées par ARM pour l'état final — permettant un traitement parallèle des intentions et brisant le goulot d'étranglement d'ordonnancement mono-threadé de l'EVM.

Sur GitHub, le code du nœud Anoma intègre déjà Narwhal + Bullshark et d'autres modules, montrant une itération en cours. Les spécifications de production et les audits restent la référence. Les premières instances fonctionnaient sur Tendermint ; la feuille de route à long terme le remplace par Typhon pour alimenter Chimera Chain.

La logique de montée en charge : horizontalement, ajouter des instances Fractal pour répartir la charge et personnaliser les règles ; verticalement, utiliser des instances locales (voire un consensus à la demande entre appareils) pour des scénarios à faible latence tout en restant interopérables avec les instances globales.

Comment Anoma réalise l'unification d'état cross-chain

Anoma prône l'interopérabilité sans pont : éviter les risques de détention et de contrat des ponts traditionnels (lock-and-wrap), et s'appuyer plutôt sur les intentions + le règlement atomique + le chevauchement des validateurs.

Voie 1 : Adaptateur de protocole multi-chaîne (déjà en production)

ARM est déployé sur les chaînes EVM sous forme d'adaptateurs de protocole (PA) en Solidity, coexistant avec les VM existantes. Les applications construites une fois peuvent régler sur Ethereum, Base, Arbitrum et d'autres chaînes dotées de PA. Les utilisateurs expriment leurs objectifs cross-chain avec une seule intention ; les solveurs gèrent l'exécution sur chaque chaîne. C'est la forme principale du déploiement du mainnet 2025–2026.

Voie 2 : Chimera Chain + Paxos hétérogène (recherche/feuille de route)

Chimera Chain est une chaîne logique couvrant les partitions d'état de plusieurs chaînes de base. Les transactions sont soumises sous forme de lots atomiques — soit toutes sont commitées, soit aucune. Paxos hétérogène, étant donné un chevauchement honnête dans les ensembles de validateurs, vise un consensus en un tour pour commettre atomiquement sur plusieurs chaînes, surpassant le verrouillage en deux phases des ponts. Plus le chevauchement est important, plus l'atomicité est forte ; un moindre chevauchement peut dégrader l'atomicité, nécessitant une gestion explicite au niveau applicatif.

Voie 3 : Messages inter-instances Fractal

Typhon gère les messages asynchrones entre instances Fractal et les messages synchrones (atomiques) au sein de Chimera ; la sémantique est interprétée par les applications de couche supérieure comme Taiga.

Pour les utilisateurs, l'« unification d'état » cross-chain signifie une seule application, une seule interaction d'intention — les mises à jour d'état sous-jacentes sont réparties entre les chaînes, mais la cohérence est garantie par les solveurs et le consensus. Il ne s'agit pas de fusionner toutes les chaînes en un registre global, mais de réaliser une unification logique avec distribution physique au niveau de la couche de coordination.

Comment la confidentialité et la technologie Zero-Knowledge sont intégrées

Les intentions placées dans un mempool public sont exposées aux risques de MEV et de front-running. Anoma utilise une approche de confidentialité multicouche :

(1) Déchiffrement à seuil Ferveo Une clé publique distribuée basée sur DKG ; les utilisateurs soumettent des intentions chiffrées, et après ordonnancement par consensus, les validateurs déchiffrent avec un quorum d'au moins 2/3 des nœuds avant exécution. Ferveo est non interactif, ce qui réduit les hypothèses supplémentaires de théorie des jeux. Utilisé pour la confidentialité du mempool, l'ordonnancement équitable et la résistance à la censure.

(2) Confidentialité composable Taiga Environnement d'exécution unifié où les intentions transparentes, protégées et privées coexistent dans la même application — la confidentialité est un choix de l'utilisateur, non un choix binaire à l'échelle de la chaîne. Cela contraste avec les dApps qui ne supportent que la transparence ou que le mélange.

(3) ZK au niveau des ressources ARM modélise la confidentialité comme un attribut de ressource : les prédicats de validité peuvent exiger des preuves de propriété ZK sans révéler le détenteur. Le projet sœur Namada utilise des pools protégés multi-actifs comme MASP sur le mainnet, validant le concept de Resource Machine. Anoma DOS fournit des rails privés pour ERC-20 et d'autres actifs sur les chaînes EVM via des PA (ex. AnomaPay sur BNB Chain en test public avec paiements ZK, temps de preuve ~15 secondes — sous réserve de la version réelle).

(4) Traitement par lots et horloges logiques Le domaine de disponibilité des données prend en charge le déchiffrement par lots des intentions chiffrées ; les solveurs rivalisent pour trouver les solutions optimales après l'ouverture du lot, équilibrant confidentialité et composabilité.

La confidentialité et la conformité peuvent être équilibrées par une divulgation sélective : confidentialité de type suisse plus partage de données sur demande pour l'audit — répondant aux besoins des paiements institutionnels et des scénarios RWA.

En quoi Anoma diffère des architectures blockchain traditionnelles

Anoma n'est pas un concurrent L1 d'Ethereum en termes de débit. C'est une couche de coordination et d'abstraction au-dessus ; la sécurité du règlement reste ancrée dans les chaînes sous-jacentes. Son argument : le Web3 a besoin d'un système d'exploitation au niveau applicatif, pas de plus d'infrastructure homogène.

Quels défis rencontre la piste basée sur les intentions ?

• (1) Confiance et qualité des solveurs : Un marché de solveurs décentralisé avec trop peu de participants pourrait conduire à une mauvaise exécution, des frais opaques ou une « centralisation molle » contraire aux intérêts des utilisateurs.
• (2) Normes et fragmentation : UniswapX, CoW, Across, Essential et d'autres définissent chacun leurs propres formats d'intention — pas de standard universel encore, l'interopérabilité repose sur des couches d'adaptation.
• (3) Compromis MEV/confidentialité : Les intentions entièrement publiques sont facilement extraites ; les intentions entièrement chiffrées augmentent les coûts de déchiffrement et de preuve, nuisant à la latence et à l'UX.
• (4) Conditions d'atomicité cross-chain : L'approche Chimera dépend du chevauchement des validateurs ; les écosystèmes multi-chaînes réels ont des ensembles de validateurs divergents, donc les garanties atomiques ne tiennent pas partout.
• (5) Complexité technique : Les chaînes d'outils comme ARM, Typhon, PA et Juvix sont encore en maturation ; la charge cognitive du développeur est plus élevée que pour un simple EVM.
• (6) Réglementation et conformité : Les paiements privés et le routage de stablecoins transfrontaliers font face à des différences juridictionnelles ; l'adoption institutionnelle nécessite une conception auditable.
• (7) Mainnet phasé : Après septembre 2025, XAN, la gouvernance et certains PA sont en activité, mais le mainnet complet de Typhon et le staking des solveurs sont encore en cours de déploiement — il existe un écart potentiel entre les attentes et les livraisons.

Orientations futures de la technologie Anoma

La feuille de route officielle et open-source inclut notamment :

• Extension de la couverture PA : Passer des L2 Ethereum à des chaînes non EVM comme Solana et Bitcoin.
• Production de Typhon + Chimera : Atteindre des commits atomiques multi-chaînes en un tour au niveau recherche.
• Affinement de l'économie des solveurs : Staking transparent, slashing et marchés de frais.
• Intégration profonde Taiga + ARM : Confidentialité composable comme capacité par défaut des dApp.
• SDK et portail Anoma App : Abaisser la barrière pour construire des applications d'intention, agréger la gouvernance, les paiements et la découverte d'applications.
• Applications de référence comme AnomaPay : Exécuter des paiements privés, des paiements par agent proxy, des trésoreries institutionnelles, etc., pour valider la valeur du DOS.

La vision à long terme : les utilisateurs expriment leurs objectifs aussi naturellement qu'avec une application Web2, les chaînes, ponts et itinéraires étant invisibles. Les développeurs écrivent des applications Web3 comme ils écrivent des applications Windows — sans redéploiement pour chaque nouvelle chaîne.

Résumé

L'architecture technique d'Anoma est construite sur le paradigme centré sur les intentions, avec ARM + réseau de solveurs + consensus Fractal/Typhon comme colonne vertébrale. Elle se connecte au monde multi-chaînes réel via des adaptateurs de protocole et construit la confidentialité via Ferveo, Taiga et ZK. La logique opérationnelle : les intentions se propagent via Interpool → les solveurs rivalisent pour les résoudre → règlement atomique sur la couche de règlement. La scalabilité provient de la division horizontale des instances Fractal ; le cross-chain, de la connexion verticale des PA et des lots atomiques Chimera.

En 2026, le DOS est déployé sur plusieurs chaînes EVM, avec XAN et la gouvernance en activité. L'ensemble des capacités est libéré par phases. La concurrence sur la piste des intentions s'intensifie. La différenciation d'Anoma réside dans sa combinaison d'intentions universelles + abstraction au niveau OS + recherche sur l'interopérabilité sans pont. Pour évaluer son succès technique, suivez des métriques vérifiables comme le volume d'intentions, le nombre de solveurs actifs, les chaînes couvertes par les PA et la rétention des applications de confidentialité — pas seulement le battage médiatique narratif.