Choix d'architecture blockchain : comment analyser les avantages et les inconvénients ?
TechFlow SélectionTechFlow Sélection
Choix d'architecture blockchain : comment analyser les avantages et les inconvénients ?
Les rollups et les L2 devraient se concentrer sur l'amélioration de l'expérience utilisateur, plutôt que de simplement devenir des L2. Les produits devraient viser à résoudre des problèmes concrets.
Dédié à des analyses Web3 approfondiesRédaction : Jon Charbonneau
Traduction : Blockchain pour Tous
Ces derniers temps, la relation entre les rollups, les L2 et les L1 fait l’objet de nombreux débats en ligne. Certains pensent qu’il faut nécessairement être un L2 d’Ethereum ou d’un autre L1 majeur pour attirer utilisateurs et applications, tandis que d’autres adoptent une perspective différente. Cet article examine en détail cette comparaison selon trois axes :
-
L1 contre L2
-
Rollup contre intégration
-
Application spécifique contre application généraliste
Nous devons mieux comprendre quand construire quelle architecture. Sinon, nous continuerons d’observer des infrastructures désordonnées, que les utilisateurs ne peuvent ni comprendre ni utiliser efficacement.
Comme le soulignait Eclipse dans sa publication avant son lancement principal :
Il existe actuellement une fausse dichotomie entre la vision modulaire des rollups et celle d’une chaîne unique offrant grande échelle, exécution parallèle et état partagé. On confond souvent « modulaire » avec « spécifique à une application », ce qui conduit à croire à tort que les rollups fragmentent les chaînes et réduisent le débit. Nous remettons cette idée en question.
Les rollups et les L2 n’impliquent pas nécessairement une mauvaise expérience utilisateur ; ce sont les rollups et L2 fragmentés qui posent problème. Des rollups et L2 bien conçus devraient améliorer l’expérience utilisateur.
1. Rollups vs. Intégration
Toutes les chaînes finiront par adopter les meilleures technologies disponibles (par exemple DAS + ZK), si elles s’avèrent utiles. Comme discuté dans mon précédent rapport « Les rollups héritent-ils de la sécurité ? », la distinction qui subsiste peut se résumer ainsi :
« Rollups » = « modulaire » – Construire des chaînes logiquement indépendantes qui publient leurs données sur une chaîne hôte (couche DA). Elles réutilisent le consensus de la chaîne hôte. « Intégré » = « monolithique » – Tout intégrer dans un seul protocole doté de son propre consensus, sans publier les données sur une chaîne hôte distincte (même si la couche DA et la couche d’exécution sont logiquement séparées au sein d’un même protocole). Solana et Eclipse représentent deux voies parallèles, comme illustré dans le document Solana de Syncracy :
Comme je l’ai récemment discuté avec Hasu dans l’émission Uncommon Core, ces deux approches ont une valeur à long terme.
Solana choisit une approche où tout est regroupé sous un seul consensus afin d’atteindre une latence minimale (actuellement 400-500 ms en moyenne, visant 200 ms à l’avenir), tout en maintenant un grand ensemble de validateurs (environ 2 000). C’est un accomplissement remarquable, mais ces deux objectifs (maximisation de la décentralisation et minimisation de la latence) entrent naturellement en tension. Maintenir la stabilité du jeu de consensus lors de la poursuite de performances maximales est extrêmement difficile, et TowerBFT n’a pas encore fait l’objet d’analyse formelle de sécurité ou de vivacité, ni d’étude claire de son rôle dans le modèle de preuve d’historique. En outre, le modèle économique des systèmes à faible latence renforce les incitations à la centralisation.
En revanche, Eclipse adopte une approche de décomposition du consensus. Les rollups peuvent fonctionner dans un environnement contrôlé avec un petit ensemble de séquenceurs (voire un seul opérateur), ce qui améliore la fiabilité, réduit davantage la latence et permet d’introduire les avantages de la cryptographie dans des produits Web2. Cela ressemble à un déploiement sur Solana d’une application de paiement Code utilisant un nonce persistant, visant des paiements instantanés et fiables. Outre une excellente expérience utilisateur proche de l’instantanéité, la compression supplémentaire du temps est essentielle pour les applications financières à haute valeur ajoutée nécessitant une très faible latence.
Les rollups peuvent publier leurs données vers un autre ensemble de consensus décentralisé, permettant une validation plus robuste à plus long terme. Par exemple, Celestia a un temps de bloc de 15 secondes et une finalité par bloc, atteignant la finalité après 32 intervalles (environ 12,8 secondes), ce qui ne diffère pas significativement du temps de confirmation de Solana (environ 400 ms).
Il existe un compromis entre les propriétés de l’ensemble de validateurs en temps réel (par exemple, Solana compte beaucoup plus de validateurs que les séquenceurs d’un rollup) et les garanties fournies. Le niveau approprié d’engagement et l’échelle temporelle forment un spectre. Certains problèmes techniques restent à résoudre, et le meilleur cas d’utilisation peut varier selon les besoins. Le coût est également crucial, rendant nécessaire l’existence de couches DA évolutives comme Celestia (utilisée par Eclipse).
Eclipse ne remplacera pas Solana. Chaque solution a ses forces et vise des marchés différents. Solana reste le cœur du développement SVM, et de nombreuses nouvelles applications y seront déployées. Mais il est clair qu’à long terme, il n’y aura pas qu’une seule chaîne SVM (Pyth en est déjà un exemple). L’avenir ne sera pas une seule chaîne, mais plutôt un développement impressionnant de la technologie SVM. Eclipse incarne le début de cette tendance à l’importer vers les L2, et d’autres projets pourraient suivre.
2. L1 vs. L2
Ici, j’utilise les termes L1 et L2 de manière large, incluant les rollups, validiums, etc.
Vitalik mentionne dans « Différents types de deuxième couche » que des ponts de vérification bidirectionnels peuvent presque transformer une chaîne en validium. Il faut aussi un engagement social : si Ethereum subit une anomalie rendant le pont inopérant, l’autre chaîne effectuera un hard fork en réponse.
La différence clé entre un L1 et un L2 réside dans leur gestion des forks. Par exemple, un validium effectue un rollback si son L1 rollback un bloc ; il effectue un hard fork si la chaîne sous-jacente fait un hard fork. Pour mettre à jour un L2, il faut une gouvernance L2 sur le L1, via un contrat de pont.
Pourquoi choisir cette approche ? A-t-il du sens pour une chaîne de délaisser son pouvoir de choix de fork à une chaîne L1 sous-jacente, là où le pont est établi ?
Bien qu’on considère généralement qu’Ethereum a gagné la course aux L1, et que tous les concurrents veulent désormais devenir des L2, devenir un L2 d’Ethereum n’est pas toujours la meilleure solution pour toutes les chaînes.
Les L2 d’Ethereum sont perçus comme la méthode la plus sûre et évolutive pour construire des chaînes. Pourtant, la sécurité est souvent mal comprise. Publier simplement une preuve sur Ethereum et déléguer la règle de choix de fork ne rend pas automatiquement une chaîne très sécurisée.
Penser que toutes les chaînes doivent être déployées comme L2 d’Ethereum pour être sécurisées est souvent incorrect. En réalité, le principal avantage d’un L2 réside dans son accès aux effets de réseau d’Ethereum. C’est une stratégie de marché.
Dans la cryptosphère, capter l’attention est crucial. Un L2 obtient généralement l’attention des développeurs, utilisateurs et médias les plus importants. Être L2 suffisait autrefois à obtenir cette attention.
Mais cette attention accordée aux L2 diminue. La liste des projets L2 d’Ethereum implémentés ou en cours de déploiement est désormais trop longue pour qu’un individu puisse la suivre. Les chaînes passant au statut de L2 ne bénéficient plus du même effet d’ascenseur qu’au départ (comme Optimism et Arbitrum). Même les projets zkEVM tant attendus peinent à attirer utilisateurs, applications et valeur.
Ainsi, être L2 ne garantit plus automatiquement l’attention générale. Cependant, si vous parvenez à attirer l’attention par d’autres moyens, cela peut encore offrir des avantages produits par rapport à une chaîne autonome. Par exemple, transformer un schéma pyramidal en carré pourrait attirer environ 700 millions de dollars vers un compte multisig sans L2. Ou alors, vous pouvez créer le premier L2 SVM d’Ethereum.
Supposons que vous ayez un produit très remarqué, examinons maintenant comment devenir L2 peut aider une chaîne à attirer le public d’Ethereum et à offrir une meilleure expérience utilisateur. Cela passe principalement par une utilisation avantageuse des actifs natifs d’Ethereum (comme l’ETH), par exemple via des ponts offrant sécurité et/ou UX attractives.
Cette valeur dépend largement de deux hypothèses fondamentales :
1) Les actifs existants d’Ethereum sont cruciaux pour un cas d’usage donné (par exemple, la dépendance du DeFi à l’ETH).
Si votre application dépend fortement des actifs de l’écosystème Ethereum, adopter une architecture L2 peut être pertinent. Mais si vous n’êtes pas intéressé par les actifs d’Ethereum, devenir un L2 d’Ethereum perd de son intérêt. Aujourd’hui, les actifs basés sur Ethereum sont cruciaux dans la cryptosphère, donc il existe une forte demande sur ce marché.
Au niveau sectoriel, la question clé est : quel sera le nouvel état futur de la cryptomonnaie ?
Si l’état futur se détache progressivement de l’état actuel d’Ethereum (par exemple, nouveaux états uniques, RWA, etc.), l’attrait des L2 pourrait diminuer. Si l’état futur reste fortement lié à l’état actuel d’Ethereum (par exemple, transactions ETH), alors les L2 pourraient jouer un rôle important. Le premier scénario suppose que nous ne voyons qu’une infime partie du développement de la cryptomonnaie, et que l’état actuel ne doit pas être surestimé. Le second suppose que l’évolution et l’adoption de la cryptomonnaie resteront liées à l’état actuel.
Les deux points de vue ont du mérite, mais je pense qu’un optimisme à long terme sur le secteur penche plutôt vers le premier. Il y aura de nombreux nouveaux états uniques, dont nous ne pouvons même pas imaginer la relation avec les états existants. Comparé à l’état futur anticipé, l’état actuel de la cryptomonnaie n’en représente qu’une petite fraction.
Par exemple, la prétendue « garantie de règlement » d’Ethereum a peu d’importance pour les actifs du monde réel (comme l’USDC ou les bons du Trésor tokenisés). Ils ne sont « réglés » que lorsque leur émetteur (par exemple Circle) le reconnaît.
Dans ce cas, l’attrait d’être un L2 d’Ethereum pourrait s’atténuer dans certaines applications. Une nouvelle application de paiement basée sur l’USDC ne se soucie pas d’être un L2 d’Ethereum ; elle cherche simplement l’infrastructure la plus économique, rapide et fiable pour offrir la meilleure expérience utilisateur.
Solana a connu des difficultés par le passé pour créer de nouveaux états, mais cette tendance change clairement. De nombreux projets notoires de DeFi et d’infrastructure lancent leur jeton sur Solana, et d’autres suivront. Cela stimule le développement de Solana.
2) La deuxième hypothèse est que, dans certains cas, un pont entre Ethereum et un L2 est préférable à un pont entre Ethereum et un L1 (pour des raisons de sécurité ou d’expérience utilisateur).
Supposons que nous satisfassions la première hypothèse (votre application dépend fortement des actifs natifs d’Ethereum), la question suivante est : le L2 présente-t-il une meilleure façon de présenter ces actifs par rapport à un L1 autonome ? Prenons un utilisateur possédant de l’ETH et souhaitant l’échanger contre de l’USDC. Que devrait-il faire ?
Bien que la sécurité des ponts soit souvent invoquée, les informations disponibles semblent affaiblir cet argument. Beaucoup de ponts principaux de rollups n’ont même pas de preuve, certains autorisent uniquement des preuves spécifiques, des mises à jour multisignatures, voire n’ont même pas de L2.
Comparés aux ponts de validation par consensus traditionnels (comme IBC), on n’a jamais observé de défaillance collective majeure des validateurs dans de tels cas. Les pannes de pont résultent généralement de piratages ou de compromission du multisig du pont (auxquels les L2 sont également vulnérables).
Même si les améliorations de sécurité ici ne me convainquent pas pleinement, l’accès facile aux utilisateurs et actifs d’Ethereum constitue selon moi l’avantage principal actuel des ponts L2. Des rollups comme Base, Optimism et Arbitrum ressemblent davantage à des extensions d’Ethereum. Les utilisateurs conservent le même portefeuille et adresse, le jeton gaz local est la version standard unique de l’ETH, l’ETH domine le DeFi (toutes les paires de trading), les applications sociales valorisent les NFT en ETH et paient les créateurs en ETH (ex. friend.tech), les dépôts sur L2 sont instantanés (car ils sont réordonnés ensemble), etc.
Les utilisateurs ne veulent pas avoir à choisir quel pont utiliser, analyser diverses hypothèses de sécurité, gérer plusieurs jetons encapsulés, obtenir des jetons locaux pour le gaz, etc. Ils veulent simplement traverser avec leur ETH, arriver de l’autre côté avec de l’ETH, et continuer à utiliser le L2 comme ils utilisent Ethereum ou tout autre L2. C’est pourquoi Eclipse utilisera l’ETH comme jeton gaz local. Imposer un nouveau jeton gaz nuit à l’expérience utilisateur.
Alors, pourquoi Solana ne peut-il pas offrir les mêmes avantages qu’un L2 d’Ethereum ? En réalité, c’est davantage un problème d’ingénierie qu’une limitation fondamentale. Avec le temps, ce problème deviendra plus facile à résoudre. Quant au gasToken et aux autres défis d’expérience utilisateur liés à l’absence de machine virtuelle Ethereum (EVM), ils ne constituent pas une différence essentielle entre L1 et L2.
-
gasToken : l’abstraction du paiement du gaz permet à l’utilisateur de choisir librement son mode de paiement.
-
Ponts : avec le temps, les solutions de pont vont converger vers des standards plus stables, réduisant la confusion des utilisateurs et la fragmentation de liquidités.
-
Portefeuilles : la nouvelle fonctionnalité MetaMask Snaps étend le support des chaînes non-EVM via des intégrations tierces comme Drift ou Solflare MetaMask Snaps.
-
Expérience développeur : la barrière linguistique s’efface progressivement. Des projets comme Solang, Neon permettent aux développeurs Solidity de programmer sur Solana, tandis que Stylus aide les développeurs Rust à travailler sur Arbitrum.
À l’avenir, si les utilisateurs recherchent les caractéristiques d’Ethereum tout en ayant besoin de la vitesse et de l’échelle de Solana, Ethereum pourrait jouer un rôle dans le DeFi Solana. Mais les utilisateurs détenant des actifs natifs d’Ethereum pourraient choisir de rester sur les L2 d’Ethereum pour diverses raisons, dès lors qu’il existe des solutions L2 évolutives adaptées.
3. Application spécifique vs. Application généraliste
Qu’elle soit L1 ou L2, une chaîne doit clairement étendre son exécution pour augmenter son débit unitaire. Un rollup ne doit pas signifier fragmentation. Regrouper de nombreuses chaînes homogènes sous un gestionnaire de séquence partagé avec état revient, du point de vue de l’évolutivité, à une chaîne parallélisée, mais pose des défis plus grands en matière d’expérience utilisateur.
Que la chaîne soit L1 ou L2, déployer un rollup dédié à une application est souvent présenté comme un « espace bloc dédié ». Pourtant, cette idée fausse découle principalement des limitations inutiles du marché des frais global EVM monothreadé. Une SVM parallélisée dispose d’un marché des frais local, réduisant fortement le besoin de chaînes dédiées. Héberger davantage d’applications sur une infrastructure partagée diminue la complexité pour les développeurs et les utilisateurs. La complexité de l’expérience utilisateur inter-chaînes et du développement dans un monde multi-chaînes est un risque de survie sous-estimé.
Cela ne signifie pas qu’il n’y aura finalement qu’une seule chaîne. Je vois quatre raisons de déployer sa propre chaîne :
1) Évolutivité et espace bloc dédié — Cette justification est souvent peu convaincante. Le mint d’un NFT ne devrait pas bloquer les autres fonctions de la chaîne, et la réponse n’est généralement pas de créer une autre chaîne. Cela peut être atténué par une VM parallélisée disposant d’un marché des frais local. Mais si la bande passante du réseau entier est limitée, le marché local ne suffit pas, et une autre chaîne devient nécessaire.
2) Souveraineté — La gouvernance cryptographique est encore fragile ; disposer de sa propre chaîne permet des forks comme mécanisme de coordination, bien que cela reste extrêmement rare.
3) Personnalisabilité — Dans certains cas, une personnalisation au niveau du consensus peut être utile, mais ces situations sont actuellement rares. Presque tous les nouveaux rollups restent de simples forks EVM avec un nouveau jeton.
4) Capture de valeur — Internaliser la valeur sur une infrastructure partagée peut être plus difficile ; une chaîne dédiée à une application permet plus facilement d’attribuer la valeur générée à l’application responsable.
De nos jours, la motivation principale pour lancer une chaîne dédiée est souvent d’améliorer la narration du projet ou l’utilité du jeton. Le marché baissier et la croissance insuffisante des applications ont stimulé le développement et le financement d’architectures excessivement complexes, obligeant les nouveaux projets à gérer leur propre complexité.
Aujourd’hui, lancer sa propre chaîne implique des compromis douloureux et inutiles (complexité, coût, mauvaise expérience utilisateur, fragmentation de liquidités, etc.). La plupart des applications ne peuvent justifier ces avantages marginaux. L’infrastructure nécessaire pour rendre cette expérience compétitive semble encore lointaine. Ce n’est pas dire qu’il ne devrait jamais exister de chaînes dédiées (elles existent bel et bien). Au contraire, nous avons trop investi dans cette narration comme direction sectorielle, et la tendance actuelle vers le regroupement est manifestement bénéfique, étant donné l’état actuel.
4. Conclusion
Solana a récemment pris un énorme élan. Ce redressement marque largement une reconnaissance de l’état actuel de l’expérience utilisateur multichaîne : elle est décentralisée, mais mauvaise. L’expérience utilisateur des applications Solana est tout simplement incroyable : fluide et rapide.
Les rollups et les L2 ont mauvaise réputation en matière d’expérience utilisateur, mais le vrai problème est la fragmentation. Nous associons rollups et L2 à la fragmentation horizontale car, en pratique, la plupart copient simplement l’EVM existante et utilisent une bande passante de disponibilité des données limitée. Le résultat est coûteux et lourd à utiliser.
Pourtant, ce n’est pas un problème fondamental. Grâce à une extension verticale sur une couche de disponibilité des données évolutive et une machine virtuelle puissante, ces problèmes d’expérience utilisateur et de coût peuvent être résolus. Pour les L1 comme pour les L2, un certain regroupement de la pile technique se produira probablement. Utilisés correctement, les L2 et les rollups devraient améliorer l’expérience utilisateur. Voilà ce qui devrait être leur véritable atout.
Ces deux approches ont leurs mérites. Avant de construire le prochain L1, L2 ou L3, posons-nous d’abord mieux les questions : « Quel problème de marché ce produit cherche-t-il à résoudre ? » et « Comment cette architecture répond-elle à mes besoins ? »
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
@dba_crypto
