[J’ai jeté un coup d’œil pour essayer de comprendre AlignedLayer.] On entend maintenant partout que les ZK sont géniaux. Les calculs se font hors chaîne, seule la preuve est publiée sur chaîne, et Ethereum n’a qu’à vérifier cette preuve. Ça a l’air très propre, juste en l’entendant. Mais c’est là que commencent les vrais problèmes. Créer une preuve est difficile, vérifier une preuve est coûteux, et comme le coût de vérification est élevé, on ne peut pas la publier fréquemment, et comme on ne peut pas la publier fréquemment, l’expérience utilisateur devient lente. Au final, il est vrai que « utiliser ZK permet de scaler », mais la question qui reste est : qui va vérifier ces preuves ZK de manière bon marché et rapide ? Aligned est un projet qui s’attaque à ce point précis. En termes simples, c’est une couche de vérification ZK qui permet de vérifier les preuves ZK sur Ethereum de manière plus rapide et moins chère. Le document officiel décrit Aligned comme une pile verticalement intégrée pour créer un « internet vérifiable ». C’est un peu grandiloquent, mais traduit simplement : Créer une couche de vérification ZK, mettre en place un service d’agrégation de preuves, faciliter le déploiement de ZK rollups via RaaS, offrir un wallet-as-a-service, du meta proving, et de l’interopérabilité, tout cela pour « éviter aux équipes qui veulent créer des applications vérifiables de tout reconstruire depuis zéro ». Personnellement, en regardant Aligned, le point clé n’est pas le token ou l’airdrop, mais le fait que plus il y aura d’applications ZK, plus la vérification des preuves deviendra un goulot d’étranglement. Aujourd’hui, tout le monde parle de zkVM, zkML, zkTLS, ZK rollup, ZK identity. Mais à quoi servent autant de preuves si… le coût de vérification est trop élevé pour les publier sur chaîne ? Dans ce cas, ces preuves ne servent qu’à tourner en interne dans le service. Aligned tente de résoudre cela par deux approches : la Proof Verification Layer et le Proof Aggregation Service. La première : la Proof Verification Layer. Elle utilise EigenLayer restaking : certains validateurs Ethereum — plus précisément, des opérateurs — vérifient les preuves, signent le résultat avec une signature BLS, et dès que 2/3 au moins sont d’accord, ils publient ce résultat sur Ethereum. L’utilisateur envoie sa preuve via CLI ou SDK, un batcher regroupe les preuves, les opérateurs les vérifient, un aggregator rassemble les signatures et enregistre le résultat sur Ethereum. Cela semble compliqué en mots, mais l’idée est simple : Ne vérifiez pas les preuves sur EVM en gaspillant du gas, vérifiez-les rapidement dans un environnement natif, et ne publiez sur Ethereum que le résultat. Selon la documentation, Aligned supporte des systèmes de preuve que Ethereum ne peut pas traiter efficacement, et vise à rendre le coût de vérification moins dépendant du système de preuve spécifique. Il prend en charge des verifyurs comme Groth16, Plonk, SP1, Risc0, Circom, et teste déjà des verifyurs liés à Mina sur le testnet. Jolt, Nexus et d’autres sont aussi prévus dans la roadmap. C’est important car lorsqu’un développeur choisit un système de preuve, il n’a plus à se demander : « Est-ce que c’est vérifiable sur Ethereum ? » « Est-ce que je peux me permettre le gas ? » « Et s’il n’y a pas de precompile ? » Avant, chaque système de preuve avait un coût de vérification on-chain différent ; certains étaient tellement coûteux qu’ils étaient irréalisables sur Ethereum ; pour intégrer un nouveau système de proving, il fallait attendre un contrat intelligent optimisé en gas ou un precompile. Aligned veut rendre cela beaucoup plus flexible. La deuxième approche : le Proof Aggregation Service. Cela consiste à compresser plusieurs preuves en une seule preuve récursive, afin qu’un seul proof final soit vérifié directement sur Ethereum. Si la Proof Verification Layer se concentre sur la vérification rapide et peu coûteuse, le Proof Aggregation Service se concentre sur une finalité forte, directement validée par L1, même si elle est un peu plus lente. C’est pourquoi la documentation recommande de choisir selon le cas d’usage : Si vous avez besoin d’une UX rapide, d’une faible latence et d’un grand volume de preuves → utilisez la Verification Layer. Si vous avez besoin d’une finalité L1 complète et d’une sécurité maximale, et que vous voulez regrouper plusieurs preuves en un point de contrôle final → utilisez l’Aggregation Service. Les deux peuvent aussi être utilisés ensemble. Par exemple : traitez l’UX utilisateur rapidement via la Verification Layer, et créez périodiquement un point de contrôle L1 via l’Aggregation Service. Ce modèle s’adapte particulièrement bien à plusieurs cas : Les ZK rollup doivent constamment produire des preuves ; les ponts doivent vérifier les preuves d’état des chaînes sources ; zkTLS doit prouver des données Web2 comme les soldes bancaires ou le KYC sans exposer les données brutes ; zkML doit prouver que l’inference AI s’est bien exécutée ; les protocoles d’identité doivent vérifier l’âge ou les conditions d’éligibilité sans révéler d’informations personnelles ; les jeux onchain doivent constamment prouver les scores ou les logiques anti-triche. Tout cela nécessite des preuves. Mais plus il y a de preuves, plus le coût de vérification devient un problème. Aligned considère que « quand l’ère des preuves arrive, il faut aussi une infrastructure pour les vérifier ». C’est un point beaucoup plus important qu’il n’y paraît. Le marché parle aujourd’hui de ZK comme d’une technologie géniale, mais pour les applications réelles, ce qui compte vraiment, c’est le coût et l’UX. Si vérifier une seule preuve coûte trop cher, on ne peut pas l’utiliser. Si la vérification prend trop de temps, les utilisateurs ne l’utiliseront pas.Si le développement prend plusieurs mois pour intégrer un verifier, le lancement du produit sera retardé. Après tout, même une excellente technologie reste uniquement un document de recherche si elle est chère, lente et complexe. Aligned semble vouloir transformer cela en produit. RaaS suit la même logique. Dans sa documentation, Aligned propose de regrouper le RISC-V zkVM, le client d’exécution Ethrex, et la couche de vérification ZK pour offrir un déploiement ZK-rollup en un seul clic. Il met particulièrement l’accent sur les based rollups. Les based rollups n’ont pas recours à un séquenceur centralisé distinct, mais exploitent directement l’infrastructure proposer/builder de l’Ethereum L1 pour le séquençage. En termes simples, il s’agit d’utiliser plus directement l’infrastructure de construction de blocs d’Ethereum pour les rollups. Si cela fonctionne, on pourrait réduire des problèmes tels que la fragmentation de la liquidité, le risque lié au séquenceur, la résistance à la censure et la composabilité avec Ethereum. Bien sûr, il s’agit encore d’un domaine en expérimentation pour l’ensemble du marché ; il ne faut pas considérer cela comme « inévitable ». Ce qui compte vraiment, c’est la capacité d’Aligned à attirer des clients et du trafic réels. Mais la direction est claire. Aligned n’est pas un projet qui se contente de créer une seule L2. Dans son FAQ officiel, Aligned affirme explicitement qu’il ne s’agit pas d’une L2 Ethereum. Au contraire, il s’agit davantage d’une pile d’infrastructure ZK native Ethereum, qui combine la vérification ZK, l’agrégation de preuves, le déploiement de rollups, le wallet, le proving et l’interopérabilité. Ainsi, lorsqu’on examine Aligned, la bonne question n’est pas : « Quelle chaîne est-ce ? » mais plutôt : « Dans un avenir où les preuves ZK seront nombreuses, qui assurera leur vérification ? » Si les applications ZK ne se développent pas, une infrastructure comme Aligned n’aura évidemment aucun intérêt. Mais si les rollups, les ponts, les zkTLS, les preuves AI, l’identité, les oracles, les jeux — tous veulent utiliser des preuves, alors le goulot d’étranglement ne sera plus la création des preuves, mais plutôt la capacité à les vérifier rapidement et à moindre coût. En fin de compte, Aligned est un projet qui cherche à répondre à cette question : « J’ai créé une preuve… mais où puis-je la vérifier ? » Quand le marché sera favorable, tout le monde ajoutera des mots comme ZK, AI, Ethereum alignment, restaking, based rollup — et se félicitera. Mais ce qui survivra réellement ne sera pas celui qui utilise le plus de beaux termes, mais celui qui permet aux développeurs d’économiser de l’argent, aux utilisateurs d’attendre moins longtemps, et aux applications de publier des preuves plus fréquemment. Aligned est au moins un projet qui observe bien ce problème. Il ne s’agit pas simplement de dire « C’est une infrastructure ZK » — les goulets d’étranglement qu’il cible sont précisément identifiés.
