
ABCDE : Quelles sont les évolutions observées dans le secteur des infrastructures de chaînes publiques dans le contexte actuel de frénésie autour de l'IA ?
TechFlow SélectionTechFlow Sélection

ABCDE : Quelles sont les évolutions observées dans le secteur des infrastructures de chaînes publiques dans le contexte actuel de frénésie autour de l'IA ?
On peut prévoir que la bulle de l'IA atteindra son apogée dans un ou deux ans.
Rédaction : Laobai,ABCDE

Ces derniers temps sur le marché primaire, le domaine le plus en vogue est sans aucun doute l'IA, suivi par le BTC. Les projets dont on discute chaque jour sont à 80 % concentrés sur ces deux secteurs. Personnellement, j'ai pu discuter jusqu'à cinq ou six projets IA par jour.
On peut prévoir que la bulle IA atteindra son apogée dans un ou deux ans. Avec des centaines de nouveaux projets IA qui seront lancés, la capitalisation du secteur grimpera vers des sommets. Lorsque la bulle finira par éclater, laissant derrière elle désordre et déception, naîtront aussi de véritables licornes ayant trouvé le point d'intersection idéal entre IA et Crypto, capables de faire avancer durablement ce secteur et toute l'industrie.
Dans ce contexte actuel de surchauffe autour de l’IA, prenons un moment pour examiner calmement les évolutions récentes au niveau de l’infrastructure, en particulier dans le domaine des infrastructures de chaînes publiques. Certains développements méritent d’être soulignés.
I. ETH, ou la déconstruction accrue des blockchains monolithiques
Lorsque Celestia a introduit pour la première fois le concept de modularité ainsi que celui de couche DA (Data Availability), le marché a mis un certain temps à assimiler et comprendre ces idées. Aujourd'hui, ces concepts sont profondément ancrés, au point que les infrastructures RaaS (Rollup-as-a-Service) ont proliféré à un stade exagéré où le nombre d'infrastructures dépasse largement celui des applications, qui lui-même excède déjà celui des utilisateurs.
Au cours des derniers mois, des progrès techniques distincts ont été accomplis respectivement au niveau de la couche d'exécution, de la couche DA et de la couche de règlement. Chaque couche a vu émerger de nouvelles solutions technologiques, et même le concept de « couche de règlement » n'est plus l'apanage exclusif d'ETH. Examinons brièvement une technologie représentative par couche.
II. Couche d’exécution
Le concept phare dans la couche d'exécution est sans conteste celui du Parallel EVM — incarné par des projets tels que Monad, Sei et MegaETH. Des projets existants comme FTM ou Canto envisagent également de migrer dans cette direction. Toutefois, tout comme tous les projets ZK ne garantissent pas nécessairement la confidentialité, les projets étiquetés « Parallel EVM » divergent fortement quant à leurs orientations techniques et objectifs finaux.
Prenons une illustration de Sei pour visualiser clairement l’amélioration significative des performances permise par le passage d’un traitement séquentiel à un traitement parallèle, dans un scénario optimiste.

En réalité, le Parallel EVM peut être subdivisé selon plusieurs axes techniques différents.
D’un point de vue transactionnel — Rien de nouveau sous le soleil : la distinction entre a priori et a posteriori
L’approche a priori, représentée par Solana et Sui, exige que les transactions indiquent explicitement quelles parties de l’état de la blockchain elles modifient. Cela permet de détecter avant le regroupement en blocs d’éventuels conflits d’état (par exemple, accès concurrent à un même pool AMM). En cas de conflit, les transactions responsables sont rejetées.
L’approche a posteriori, appelée aussi parallélisme optimiste, s’inspire du modèle BlockSTM d’Aptos. Elle suppose initialement l’absence de conflits et accepte toutes les transactions. Après exécution, un contrôle est effectué : si des conflits sont détectés, les transactions concernées sont invalidées, leur résultat est annulé, puis elles sont relancées. Ce processus itère jusqu’à ce que toutes les transactions du bloc soient exécutées avec succès. Sei, Monad, MegaETH et Canto adoptent une solution similaire.
Sur le marché primaire, nous observons également quelques solutions explorant la parallélisation dans des cas de conflits d’état (comme mentionné ci-dessus, accès simultané à un même pool AMM). Ces approches semblent toutefois relativement complexes sur le plan ingénierie, et leur viabilité commerciale reste incertaine. Nous les évaluons encore.
Selon le degré d’importance accordé au Parallel EVM — Deux courants principaux
-
Un premier courant, incarné par Monad et Sei, fait de la parallélisation des transactions sa principale stratégie d’évolutivité. La parallélisation constitue ici la narration centrale. Par exemple, outre le traitement parallèle optimiste, Monad développe spécifiquement une base de données nommée MonadDB et met en œuvre un système d’E/S asynchrones optimisé pour accompagner cette parallélisation.
-
Un second courant, porté par Fantom, Solana et MegaETH, considère la parallélisation comme une composante parmi d’autres de leur stratégie d’évolutivité. Ici, la parallélisation joue un rôle secondaire. Les gains de performance proviennent davantage d'autres innovations techniques.
Par exemple, la mise à niveau Sonic de Fantom repose sur la machine virtuelle FVM associée à un mécanisme de consensus Lachesis optimisé. Pour Solana, la prochaine étape tourne autour du client Firedancer, dont l’architecture modulaire améliore les communications réseau et la vérification des signatures. Quant à MegaETH, il vise à créer une « blockchain en temps réel ». Basé sur le client haute performance Reth récemment développé par Paradigm, il réalise des optimisations poussées sur plusieurs fronts : synchronisation d’état au niveau des nœuds complets (seules les différences d’état sont transférées), conception matérielle du Séquenceur (utilisant une grande quantité de RAM haute performance avec fonction de stockage pour accéder rapidement à l’état, évitant ainsi les E/S disque lentes), améliorations de la structure de données Merkle Trie, etc. Bref, MegaETH pousse au maximum la performance de l’EVM en optimisant logiciel, matériel, structures de données, E/S disque, communication réseau et ordonnancement des transactions, se rapprochant ainsi d’une « blockchain en temps réel ».
III. Couche DA (Disponibilité des Données)
La couche DA n’a connu aucune grande itération technique récente. Ce secteur est donc bien moins compétitif que celui de l’exécution, et les principaux acteurs restent peu nombreux.
La mise à jour d’ETH transformant CallData en Blob a considérablement réduit les frais des différentes couches 2. ETH est désormais une solution DA « pas trop chère ».
L’impact majeur de Celestia vient surtout du fait qu’en tant que premier projet à avoir popularisé le concept de couche DA, il a fait passer la valorisation théorique du secteur de 2 milliards à 20 milliards de dollars. Cette percée a redéfini le champ des possibles. Désormais, de nombreuses nouvelles appchains Layer 2 choisissent naturellement Celestia comme couche DA.
Avail, séparé de Polygon, ressemble techniquement à une « version améliorée de Celestia ». Il utilise par exemple le mécanisme de consensus Grandpa+BABE issu de Polkadot, qui théoriquement supporte plus de nœuds et donc une meilleure décentralisation que Tendermint utilisé par Celestia. Il prend aussi en charge des preuves de validité (Validity Proof), non supportées par Celestia. Toutefois, les différences techniques pèsent moins lourd que celles au niveau de l’écosystème, où Avail doit encore rattraper son retard.
EigenDA a été lancé il y a quelques jours aux côtés du mainnet d’EigenLayer. Étant donné que EigenLayer est l’un des projets les plus forts en termes de narration et de partenariats commerciaux de ce cycle, je pense que le taux d’adoption d’EigenDA sera élevé. Théoriquement, tant qu’une solution paraît « sûre et bon marché », peu de projets se soucient vraiment de savoir s’il s’agit de Validity Proof ou Fraud Proof, ou si DAS est supporté.
Les trois solutions DA suivantes méritent toutefois une attention particulière :
-
Near DA — Near est une blockchain fascinante. Initialement conçue autour du sharding, elle poursuit ce chemin tout en développant aussi une couche DA — plus économique que Celestia, et supportant un règlement rapide des L2. Abstraction de chaîne — récemment, Near a lancé une signature multi-chaînes, permettant à un utilisateur de demander la signature d’une transaction sur n’importe quelle blockchain via un seul compte NEAR. IA — son fondateur Illia fait partie des huit auteurs fondateurs du modèle Transformer, salué par Jensen Huang lors de la conférence NVIDIA ; Near prévoit maintenant d’embaucher des ingénieurs IA et annoncera bientôt near.ai… Un guerrier hexagonal, que j’ai aussi classé dans le segment DA.
-
BTC & CKB — Comme la couche 1 de BTC ne supporte pas les contrats intelligents, elle ne peut pas servir directement de couche de règlement. Ainsi, des dizaines de L2 EVM basés sur BTC utilisent aujourd’hui BTC comme couche DA. La seule différence réside dans le fait de publier directement la preuve ZK sur BTC ou seulement son hash. On dirait presque qu’on ne peut pas s’appeler « L2 BTC » sans le faire… Récemment, j’ai rencontré un nouveau projet affirmant : « Je ne fais plus semblant, je suis un L2 ETH, avec DA et règlement sur ETH, mais je sers l’écosystème BTC ! » — assez drôle… Le seul véritable cas atypique est RGB++ proposé par CKB. Dans ce cadre, CKB devient une entité similaire à une couche DA, tandis que BTC, grâce à une technologie noire liant les UTXO de manière isomorphe, devient quasi la couche de règlement de RGB++.
-
Nouvelles solutions DA — deux nouvelles approches intéressantes, sans citer les noms des projets. L’une combine DA et IA : en plus d’être une couche DA haute performance, elle peut également servir de couche de stockage pour les grands modèles d’IA, leurs données d’entraînement et leurs trajectoires d’apprentissage. L’autre améliore le mécanisme de code correcteur d’erreurs utilisé par Celestia et autres DA, offrant une meilleure robustesse même dans un réseau dynamique instable (où plusieurs nœuds tombent aléatoirement à chaque tour).
IV. Couche de règlement
À l’origine, cette couche était presque entièrement monopolisée par ETH. La couche DA dispose de Celestia comme concurrent, l’exécution a ses propres L2. Mais concernant le règlement, d’autres blockchains comme Solana ou Aptos n’ont pas encore de L2, et les L2 BTC ne peuvent ni ne veulent utiliser BTC comme couche de règlement. À ce jour, la seule option concevable pour la couche de règlement est ETH.
Toutefois, cette situation va bientôt changer. Plusieurs nouveaux projets s’engagent dans la direction mentionnée au début de cet article, et certains anciens projets commencent à pivoter vers ce nouveau modèle : une couche de vérification/règlement ZK — autrement dit, une déconstruction supplémentaire d’ETH (en concurrence directe avec lui).
Pourquoi ce concept émerge-t-il maintenant ?
La raison est que l’exécution de contrats de vérification de preuves ZK sur la couche 1 d’ETH n’est théoriquement pas une solution optimale.
D’un point de vue technique, pour vérifier la validité d'une preuve ZK, les développeurs doivent écrire en Solidity un contrat de vérification adapté au projet ZK et au type de preuve ZK choisi. Cela implique souvent l’utilisation d’algorithmes cryptographiques complexes, comme le support de différentes courbes elliptiques. Or, l’architecture EVM-Solidity n’est pas idéale pour implémenter efficacement ces algorithmes. Pour certains projets ZK, le coût de développement et de vérification de ces contrats reste élevé.
Cela freine quelque peu l’intégration native des écosystèmes ZK dans l’écosystème EVM. Ainsi, des langages ZK-friendly comme Cairo, Noir, Leo ou Lurk ne peuvent pour l’instant être vérifiés que sur leurs propres blockchains Layer 1. Par ailleurs, ETH, en raison de sa taille et de sa complexité, souffre d’une certaine inertie face aux mises à jour — « un grand navire peine à virer de bord ».
Du côté des coûts, bien que les frais de « protection » payés par les L2 soient majoritairement absorbés par la couche DA, la vérification des contrats ZK engendre aussi des frais en gaz. Effectuer cette vérification sur ETH n’est certainement pas une option économique. Ajoutons à cela les pics fréquents du prix du gaz sur Ethereum, qui transforme parfois la chaîne en « blockchain aristocratique », rendant le coût de vérification très volatile.
C’est pourquoi de nouveaux projets émergent autour du concept de couche de vérification/règlement ZK. Ces projets sont encore jeunes, Nebra en étant un exemple représentatif. Certains anciens projets pivotent également vers ce modèle, comme Mina ou Zen, qui vient juste d’adopter une nouvelle proposition.
La plupart de ces projets partagent une vision commune :
-
Supporter plusieurs langages ZK ;
-
Permettre l’agrégation des preuves ZK, pour une vérification plus efficace et moins coûteuse ;
-
Offrir un temps de finalité (finality time) plus rapide ;
La couche de règlement ZK et le marché décentralisé de preuves (Proof Market) risquent fortement de converger. Après tout, même avec la meilleure technologie, il faut encore disposer de puissance de calcul. On pourrait voir des collaborations entre projets de règlement et projets de Proof Market, ou bien des projets de règlement maîtrisant la puissance de calcul lançant leur propre Proof Market, voire des projets techniques de Proof Market créant leur propre couche de règlement. La voie exacte reste à définir par le marché.
Concernant d'autres domaines de l'infrastructure — comme les oracles, l'OEV (Opportuniste Extraction de Valeur) dans le domaine MEV, ou les clients légers ZK dans l'interopérabilité — de nombreux articles existent déjà en ligne, inutile d’y revenir ici. La prochaine fois que j’aurai repéré de nouvelles idées intéressantes, je les partagerai avec vous !
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News












