Blockchains modulaires : rêve de Lego ou cauchemar d'intégration ?

Modulaire est un mot étrangement séduisant. Il évoque des briques de Lego, des bibliothèques logicielles bien organisées et des meubles livrés en kit avec un sachet de vis sur le côté. Le terme implique flexibilité, modernité et une certaine élégance, par opposition à un mécanisme gigantesque et indestructible où chaque engrenage est soudé au suivant. C'est pourquoi ce mot trouve son habitat naturel dans le marketing crypto. Une blockchain modulaire est quelque chose qui devrait s'emboîter comme une évidence dans l'esprit : l'exécution d'un côté, le règlement de l'autre, la disponibilité des données en dessous, un pont, un peu de chiffrement à divulgation nulle de connaissance, et soudain le système tout entier devient plus efficace que son alternative monolithique.

Quiconque a déjà tenté d'assembler un système modulaire sait que la beauté n'est souvent qu'une illusion. Remplacer un ensemble de briques Lego par un autre peut décevoir si les nouvelles pièces ne sont pas aussi solides que les anciennes. Imaginez maintenant qu'à la place des briques en plastique et des vis, vous ayez des hypothèses de règlement, des frameworks de rollup, des contrats de ponts (bridges), des comités de disponibilité des données, des jetons de gouvernance, des échéances imposées par des investisseurs, des audits externes et cinq mille lignes de code initialisées par un LLM que personne ne lit car la date de lancement approche.

Les choses peuvent être bien faites si elles le sont correctement. Cette vérité banale résume tout l'intérêt de la conception d'une blockchain modulaire. Elle n'a rien de magique, elle ne promet pas de résoudre les problèmes d'elle-même ; elle affirme seulement que la complexité peut être déplacée. Il appartient aux concepteurs de s'assurer que cette nouvelle complexité distribuée reste gérable. Un système modulaire bien conçu peut délimiter un domaine spécifique et accomplir sa tâche bien mieux qu'un système monolithique. Il peut également créer une surface d'attaque aux proportions terrifiantes s'il n'est pas pensé en tenant compte de cette réalité.

Si les blockchains modulaires suscitent un tel intérêt, c'est parce que les approches traditionnelles de conception de blockchains se sont heurtées à une série de problèmes précis. Une blockchain monolithique est une couche de règlement, un environnement d'exécution, un mécanisme de consensus et une couche de disponibilité des données, le tout compacté au sein d'un seul système étroitement intégré. C'est l'équivalent du château fort médiéval : simple, élégant, avec toutes les défenses concentrées au même endroit, mais extrêmement coûteux à bâtir et à entretenir.

Le règlement, l'exécution, le consensus et la disponibilité des données sont tous essentiels, mais la concurrence pour l'espace de bloc entre ces composantes laisse souvent peu de place aux applications qui souhaitent effectuer leur règlement sur la chaîne. Les utilisateurs doivent payer pour ce que les développeurs ne parviennent pas à prioriser, et ces derniers doivent composer avec ces contraintes au lieu de concevoir la couche applicative qu'ils envisageaient. C'est pourquoi la conception d'une blockchain modulaire est une perspective séduisante : elle promet de découpler ces fonctions et de permettre à des couches spécialisées d'accomplir leur tâche plus efficacement qu'une blockchain généraliste ne pourrait le faire.

Les mises à niveau d'Ethereum axées sur les rollups sont l'exemple le plus marquant de cette approche : le règlement et la sécurité sont assurés par le mainnet d'Ethereum, tandis que l'environnement d'exécution est déployé séparément sous la forme de divers rollups. La récente mise à niveau Dencun, qui a introduit le blobspace, en est une autre illustration : elle a permis aux rollups de publier leurs données à moindre coût, ce qui rend à son tour les applications utilisant ces rollups plus économiques pour les utilisateurs.

Celestia est un protocole de blockchain modulaire expérimental qui vise également à fournir une couche de règlement distincte de l'environnement d'exécution. Il ressemble à Ethereum à bien des égards, mais se veut plus généraliste et plus allégé : les rollups d'exécution peuvent utiliser sa couche de disponibilité des données sans adopter les mécanismes de règlement et de consensus d'Ethereum. Celestia s'appuie sur le Data Availability Sampling (échantillonnage de disponibilité des données) pour permettre aux nœuds légers de vérifier que les données ont été correctement publiées sans avoir à télécharger toute la chaîne. L'ensemble de son écosystème est lui aussi modulaire : les frameworks de rollup, les couches de publication de données et d'autres outils d'infrastructure sont construits séparément mais interagissent avec la chaîne de base. La demande est réelle, mais Celestia n'en est qu'à ses débuts, tout comme de nombreuses autres blockchains modulaires.

EigenDA est une couche de disponibilité des données développée sur EigenLayer, qui permet aux rollups basés sur Ethereum d'exploiter la sécurité offerte par le restaking d'Ether via EigenDA au lieu de devoir sécuriser leurs propres chaînes de disponibilité des données. Avail, l'ancien projet de Polygon devenu une couche autonome de disponibilité des données, est un autre concurrent promettant une disponibilité des données agnostique vis-à-vis des chaînes, avec vérification par clients légers et interopérabilité. Ce sont toutes des idées prometteuses qui visent à découpler la disponibilité des données du règlement et de l'exécution, permettant ainsi aux rollups d'être plus légers et plus spécialisés.

Pour les développeurs, l'attrait des blockchains modulaires est évident. Au lieu de tout construire à partir de zéro, ils peuvent utiliser un framework particulier ou un ensemble de composants modulaires reconnus pour bâtir leur chaîne. L'OP Stack, Arbitrum Orbit, le ZK Stack, Polygon CDK, Agglayer CDK, Rollkit et diverses offres de Rollup-as-a-Service permettent tous aux développeurs de concevoir l'environnement d'exécution de leur choix tout en s'appuyant sur des hypothèses de sécurité bien établies. Au lieu de déployer une couche de règlement complète avec des validateurs, un bridge, un mécanisme de consensus et un ensemble de smart contracts, une équipe peut lancer un rollup optimiste ou ZK avec une configuration de confiance (trusted setup) et être opérationnelle en quelques semaines. Au lieu de développer une couche de disponibilité des données, un rollup peut louer de l'espace sur Ethereum ou sur une autre chaîne via EigenDA ou Celestia.

Pour les utilisateurs, les bénéfices sont moins immédiatement perceptibles. Une application basée sur un rollup plus économique est toujours appréciable, mais la véritable promesse des blockchains modulaires réside dans la spécialisation. Les couches de règlement et de disponibilité des données peuvent être optimisées pour la simplicité et la sécurité, les rollups d'exécution peuvent tirer parti de l'outillage fourni par le framework de leur choix, et les blockchains dédiées à des applications spécifiques peuvent offrir des transactions plus abordables et une meilleure UX que les chaînes généralistes. Tout cela reste très théorique, mais cette perspective plus attrayante pour les développeurs comme pour les utilisateurs représente également une menace : une menace pour la domination des blockchains monolithiques.

Le dilemme de l'armure

Les ennuis commencent lorsque la modularité quitte le domaine de l'architecture pour devenir un effet de mode. On n'est pas plus en sécurité simplement parce que ses schémas comportent davantage de blocs. Autour de chaque frontière entre ces blocs, il doit y avoir des hypothèses ; chaque message transmis entre deux couches doit être vérifié ; chaque bridge doit être conçu selon un modèle de confiance ; chaque séquenceur doit être contrôlé pour sa vivacité (liveness) ; chaque couche de disponibilité des données doit être analysée pour garantir un échantillonnage ou des opérateurs intègres ; chaque processus de mise à niveau doit être soumis à la gouvernance ; et chaque dépendance externe devient un point de défaillance potentiel alors même que l'application prétend être sécurisée.

Les hackers de l'écosystème crypto ont compris depuis longtemps que le meilleur endroit pour s'attaquer à un système est rarement son cœur, mais plutôt sa périphérie : le bridge, l'oracle, l'ensemble des validateurs, la clé de mise à niveau, le signataire hors chaîne, ou ce petit contrat auxiliaire dont personne ne pensait qu'il aurait la moindre importance. Prenez la désastreuse compromission des clés de validation de Ronin, la fraude sur le wrapping de Wormhole ou l'exploit de retrait sur le bridge Nomad : autant d'incidents qui se sont traduits par le vol de plusieurs milliards de dollars. Pour chacun d'entre eux, le coût avait été théoriquement minimisé par la conception, mais les dégâts sont survenus au point où la sécurité était la plus faible : le maillon faible de la chaîne.

C'est ici qu'intervient la métaphore de l'armure médiévale. La cotte de mailles, les plaques, le cuir, le rembourrage et d'autres formes de protection étaient autrefois assemblés de manière disparate pour offrir une liberté de mouvement maximale tout en garantissant un niveau de protection raisonnable. Chaque couche pouvait être remplacée, améliorée, réparée – mais les jointures entre les différents types d'armures constituaient toujours des points faibles, exploités par des adversaires déterminés. Ce n'est pas le maillon le plus fragile qui a causé la perte des chevaliers en selle, mais leurs sangles. Leurs aisselles, leurs visières, leur entrejambe, leurs genoux, leurs coudes : aucun de ces endroits n'était prévu pour repousser une lance, et ils sont devenus des points d'entrée privilégiés pour les attaques.

Les évolutions ultérieures de l'armure ont cherché à réduire ces faiblesses en rendant l'ensemble de la tenue plus intégré : une cuirasse, un heaume fermé, des plaques mieux réparties et des renforts aux articulations. L'ancienne méthode n'avait rien de fondamentalement mauvais, mais l'ennemi n'était pas naïf : il a cessé de viser la ceinture du chevalier. Un système modulaire n'est jamais plus solide que sa dépendance la plus faible, et plus ces dépendances sont nombreuses, plus le risque d'une défaillance augmente.

C'est à cette aune que les blockchains modulaires doivent être évaluées. Une conception modulaire est avantageuse lorsque chaque couche est dimensionnée en fonction des menaces pesant sur l'ensemble du système, mais elle devient périlleuse lorsque ses éléments individuels s'alignent sur le plus petit dénominateur commun de sécurité. Lorsque quelqu'un commence à sonder votre séquenceur, vous n'avez pas envie de réaliser que votre couche de données ou votre chaîne de règlement repose sur un contrat multi-sig ou sur un opérateur de nœud tiers.

Cela ne signifie pas pour autant que les chaînes monolithiques sont supérieures par défaut aux modulaires. Une blockchain intégrée unique comporte ses propres risques, vecteurs d'attaque, goulots d'étranglement et points de défaillance — comme en témoignent les défis de sécurité constants auxquels font face Solana, Ethereum, Bitcoin et d'autres écosystèmes majeurs. Cependant, un monolithe offre une surface plus simple à attaquer comme à défendre, avec un risque global plus réduit que son alternative. De la même façon, une pile modulaire peut permettre une plus grande scalabilité, davantage de flexibilité et une meilleure liberté d'expérimentation, mais cela se fait au prix d'une complexité accrue et du fardeau d'hypothèses de confiance supplémentaires.

Le casse-tête de l'expérience utilisateur

La faiblesse de l'approche modulaire tend à se répercuter directement sur l'expérience utilisateur. Si la couche d'exécution fonctionne parfaitement mais que la couche de données est indisponible, si le séquenceur est en pause mais que la chaîne de règlement est active, ou si un bridge est temporairement désactivé à la suite d'un incident, comment l'utilisateur est-il censé le savoir ? Il ne saisit déjà pas la distinction entre règlement et exécution, et encore moins les nuances subtiles entre les différents modèles de disponibilité des données et leurs implications sur la vivacité du réseau. Pour lui, la blockchain est en panne, tout simplement.

Les interruptions de service sur les rollups constituent l'exemple le plus flagrant de ce problème. Base, l'un des Layer 2 d'Ethereum les plus populaires, a vu sa chaîne suspendue pendant 33 minutes en raison d'un problème de basculement (failover) de son séquenceur. Heureusement pour ses utilisateurs, leurs fonds n'ont jamais été véritablement inaccessibles durant l'incident, mais l'événement reste un sérieux avertissement. L'écosystème Ethereum tout entier repose sur la sécurité du règlement sur Ethereum, mais cela n'empêche pas la survenue de pannes propres aux rollups.

Un autre exemple s'est produit lors de la récente panne du séquenceur de Linea consécutive à l'exploit de Velocore. À la suite de l'attaque, l'équipe de Linea a imposé une pause qui a bloqué les retraits des utilisateurs. Bien qu'il s'agisse sans conteste d'un moindre mal au vu de la situation, cet incident illustre le risque potentiel en matière d'UX inhérent à une architecture modulaire. Cette suspension a empêché les utilisateurs de la chaîne compatible Ethereum de Linea d'accéder à leurs actifs, alors même que ceux-ci étaient sécurisés par Ethereum. Cela a également rappelé de manière brutale que de nombreux rollups conservent un contrôle opérationnel centralisé ou semi-centralisé sur leur chaîne.

Actuellement, l'écosystème des rollups se caractérise par une prolifération d'options de disponibilité des données. Diverses blockchains modulaires offrent aux utilisateurs le choix entre des fournisseurs de Rollup-as-a-Service, Celestia DA, EigenDA, Avail, le blobspace d'Ethereum et bien d'autres solutions. Certaines chaînes, comme Base, Arbitrum Nova, Linea ou Scroll, sont déployées au-dessus des chaînes de règlement Ethereum existantes et s'appuient sur leurs mécanismes de disponibilité des données. Dans le même temps, Optimism s'apprête à lancer sa Superchain, destinée à unifier plusieurs chaînes OP au sein d'une même couche de règlement partagée.

Arbitrer entre ces options s'avère rarement simple et ne se fait presque jamais sans examiner des spécificités techniques pointues. En pratique, la majorité des utilisateurs recherchent avant tout des transactions rapides et peu coûteuses. Ils ne souhaitent pas se préoccuper des différences entre blobs et calldata, ni des relations entre les chaînes de Layer 2 et leur règlement sur le Layer 1. Dans l'UX crypto, « modulaire » est souvent assimilé à « économique », et le public visé par cette promesse est particulièrement large.

En revanche, chaque chaîne bâtie sur une autre introduit un risque supplémentaire. Les bridges Ethereum ont constitué une cible d'attaque récurrente cette année, et il est logique de penser que des incidents propres aux rollups suivront la même trajectoire. Plus il y a de couches superposées entre les fonds d'un utilisateur et leur règlement définitif, plus les risques de dysfonctionnements simultanés s'accumulent. Si le modèle de menace lié aux pannes de rollups n'atteint sans doute pas le niveau critique des bridges, il en va tout autrement sur le plan de l'UX. Le même utilisateur qui ne ferait pas la différence entre Ethereum, Arbitrum Nova, Linea ou Base ne remarquera pas non plus le moment où l'une de ces chaînes sera mise en « pause pour raisons de sécurité ».

Les utilisateurs particuliers ne sont pas les seuls à devoir composer avec la complexité de cette architecture. Assurer la sécurité des smart contracts représente déjà un défi de taille, mais auditer une pile modulaire relève d'une véritable ascension. Il ne s'agit plus seulement d'examiner le contrat cible, mais l'ensemble du code périphérique, des hypothèses, des dépendances et des outils qui constituent le système. N'importe lequel de ces éléments peut faillir de façon imprévue, et leurs interactions s'avèrent rarement intuitives. Il suffit qu'un attaquant repère une unique vulnérabilité dans un smart contract ou une seule faiblesse dans un bridge du réseau pour que son offensive aboutisse.

Face à cet enjeu, la réponse du secteur est évidente : plus de rigueur, de meilleurs outils et une architecture plus soignée. Des bridges perfectionnés dotés de vérification par clients légers. Des preuves à divulgation nulle de connaissance et des signatures à seuil (threshold signatures). Des mécanismes de limitation de débit et des coupe-circuits. Des séquenceurs et des chaînes de règlement décentralisés. De la vérification formelle, du monitoring et des interfaces utilisateur adaptées pour clarifier la situation auprès d'utilisateurs souvent désorientés. Cette tension au cœur de l'écosystème modulaire stimule l'innovation à tous les niveaux, des couches techniques les plus fondamentales jusqu'au sommet.

Des compromis, pas une solution miracle

Le développement logiciel repose avant tout sur des arbitrages. Certains sautent aux yeux, d'autres demeurent dissimulés sous la documentation et les clauses juridiques. Certains accompagnent chaque avancée majeure du secteur, à l'image des compromis sur lesquels repose l'EVM d'Ethereum. Les blockchains modulaires ne dérogent pas à la règle : elles promettent flexibilité et expérimentation, mais n'éliminent pas le fardeau d'une complexité additionnelle. Les chaînes modulaires échangent la relative simplicité technique d'une chaîne unique contre des opportunités d'optimisation. Elles troquent des garanties de sécurité directes contre une surface d'attaque élargie. Elles remplacent la congestion d'une couche de règlement unique par la charge organisationnelle d'une sécurité à plusieurs niveaux. Elles troquent la liberté des développeurs contre la décentralisation, et un potentiel brut contre une responsabilité accrue.

Pour certaines équipes, ce choix s'impose de lui-même. Certaines chaînes dédiées à une application spécifique ont tout intérêt, pour des impératifs de performance ou de viabilité économique, à ne pas partager leur couche de règlement avec l'ensemble du marché. Les jeux, les applications maintenant un état persistant, les protocoles DeFi spécialisés, les chaînes d'entreprise et les environnements de test sont autant de cas d'usage qui tirent parti de la flexibilité du modèle modulaire. De nombreux écosystèmes doivent être bâtis ex nihilo, et un rollup proposant des données plus abordables et un traitement plus véloce représente un excellent point de départ.

Pour d'autres projets, le compromis se révèle bien moins séduisant. Si un projet n'a pas un besoin avéré de sa propre chaîne, il n'y a aucun intérêt à la déployer. Si une équipe ne maîtrise pas la construction d'un bridge, elle ferait mieux de s'abstenir. Si une organisation est incapable de sensibiliser ses utilisateurs aux risques d'une conception modulaire, elle ne peut certainement pas prétendre protéger ses clients. Si la décentralisation est systématiquement renvoyée « à plus tard », le projet n'est tout simplement pas prêt à être lancé. La sécurité d'une chaîne modulaire n'est jamais supérieure à celle de son maillon le plus faible ; et si ce maillon se résume à la « promesse de futures mises à jour », il est temps de repenser l'architecture.

La leçon tirée du Moyen Âge trouve ici tout son sens : l'armure modulaire n'était pas intrinsèquement inférieure à une autre. Une armure mal pensée, en revanche, se repérait rapidement car elle laissait souvent sans protection des zones vitales du corps. Le même principe s'applique aux blockchains modulaires : la promesse de « propriétés de sécurité unifiées » sonne creux si chaque couche de l'édifice est à peine suffisante, vulnérable ou non éprouvée.

Les meilleures blockchains modulaires intègrent cette réalité et s'efforcent de minimiser ces risques au maximum. Elles ont compris qu'une conception réellement sécurisée masque la complexité derrière une interface fluide, tout comme une bonne armure est difficile à déceler de loin. Elles réduisent les hypothèses et les périmètres de confiance, restreignent la surface d'attaque et s'appuient dans la mesure du possible sur les infrastructures de sécurité existantes. Le séquençage y est décentralisé, les chaînes de règlement sont éprouvées sur le terrain, les bridges sont validés par des clients légers et les smart contracts font l'objet d'audits formels. Chaque couche supplémentaire n'est ajoutée que si elle remplit une fonction précise.

À l'inverse, les blockchains modulaires les plus médiocres paraissent séduisantes sur le papier sans être à la hauteur dans les faits. Elles dissimulent leur fragilité derrière des promesses vagues, un discours marketing sur le « multicouche » et l'argument permanent de la « flexibilité ». Elles accumulent toujours plus de complexité sans atténuer le risque global, privilégiant la vitesse et le passage à l'échelle au détriment de la sécurité. Une chaîne déployée au-dessus d'une autre n'est pas structurellement pire qu'une chaîne autonome, mais elle devient nettement plus dangereuse si l'équipe qui la pilote est incapable d'expliquer pourquoi. Si le point faible d'un projet réside dans sa promesse d'atteindre la décentralisation « un jour », c'est l'ensemble du système qui se retrouve en péril.

Le jeu en vaut-il la chandelle ?

Les blockchains modulaires ouvrent des perspectives remarquables aux développeurs. Dès lors qu'elles sont déployées à bon escient, leurs atouts sont incontestables : une flexibilité décuplée, une plus grande liberté d'expérimentation, des coûts réduits et des audits facilités. Il ne fait aucun doute que la confrontation entre modèles monolithiques et modulaires continuera de structurer le secteur pour les années à venir, chaque camp cherchant à maximiser les forces et à gommer les faiblesses de son architecture respective. Pour autant, la concrétisation de ces opportunités dépendra avant tout de l'engagement et des compétences techniques des équipes sur le terrain.

La modularité exerce indéniablement une vraie attraction. La perspective de monter un écosystème complet à partir de briques prêtes à l'emploi s'avère particulièrement séduisante. Cela permet d'accélérer le développement, de limiter les barrières à l'entrée et d'offrir une grande diversité d'expérimentations. Les optimistic rollups d'Ethereum ont déjà prouvé la viabilité de cette méthode, et l'écosystème dans son ensemble connaît aujourd'hui une vague d'innovation sans précédent.

Celestia et EigenDA, aux côtés d'Avail et du blobspace d'Ethereum, s'apprêtent tous à offrir une plus grande souplesse en matière de disponibilité des données aux chaînes de rollups qui les exploitent. L'OP Stack, Arbitrum Orbit, le CDK et l'Agglayer de Polygon, le fork d'Optimism par Linea et bien d'autres s'attachent à abaisser les barrières techniques pour les développeurs et les équipes indépendantes, leur donnant les moyens de déployer leurs propres chaînes compatibles Ethereum. L'écosystème tout entier aborde une phase de développement passionnante, à mesure que la faisabilité technique d'un avenir multi-chaînes se confirme au quotidien.

Pourtant, cette dynamique nourrit également l'optimisme dans d'autres directions. Pour certains projets, l'intérêt d'une structure monolithique demeure difficile à ignorer. Les chaînes intégrées présentent des avantages naturels : elles garantissent davantage de simplicité et de sécurité, tout en étant plus favorables à la viabilité sur le long terme. Les utilisateurs de ces plateformes risquent moins d'être déroutés ou pénalisés par les complexités techniques inhérentes à une conception modulaire. Un environnement unique, fiable et performant est bien souvent préférable à un écosystème aux frais plus bas et à l'exécution plus rapide, mais exposé à un risque global plus élevé. Même chez les développeurs Ethereum, le choix de rester sur le « mainnet » est fréquemment perçu comme l'alternative la plus robuste.

Ces principes s'appliquent de la même manière aux grandes évolutions du secteur. Les solutions destinées à automatiser les opérations en réseau TRON pour les entreprises rencontrent un succès croissant auprès des équipes qui ne souhaitent pas personnaliser leur gestion d'Energy, configurer elles-mêmes le Smart Mode et le Host Mode, ou perdre du temps en scripting et en maintenance d'API. Netts Workspace met à disposition une interface intuitive qui regroupe la location d'Energy, le Smart Mode et le Host Mode, les transactions TRON et la gestion de l'Energy, des outils de monitoring, le filtrage AML ainsi que les opérations financières, permettant aux entreprises de réduire leurs coûts tout en limitant les risques inhérents aux processus manuels.