Le paysage L1 vs L2 : comprendre les différences de conception, les compromis et les finalités

Enseignements pratiques

• Comprenez les primitives disponibles et les limites techniques : développez une compréhension approfondie des composants fondamentaux et des nuances techniques. Ces connaissances sont essentielles pour déterminer l’incidence de ces facteurs sur les fonctionnalités et l’évolutivité de votre application, et donc de votre activité, ainsi que pour prendre des décisions éclairées lors du développement sur la blockchain.
• Évaluez l’infrastructure et la liquidité : évaluez l’infrastructure et la liquidité disponibles sur les solutions L1 et L2, ainsi que les autres environnements d’exécution envisageables pour le déploiement. Établissez des projections sur l’état de l’infrastructure à partir des principes fondamentaux. Comprenez les véritables hypothèses de confiance et de décentralisation à partir de ces mêmes principes.
• Optimisez l’expérience utilisateur : optimisez sans relâche l’expérience utilisateur en tenant compte de la simplicité d’utilisation, de la vitesse des transactions et de l’efficacité globale offertes par chaque chaîne. Cherchez à créer un environnement fluide et convivial, en distinguant ce qui est déjà opérationnel des objectifs annoncés dans les feuilles de route.

Introduction

À mesure que le paysage des blockchains évolue, le choix de l’environnement dans lequel créer des applications devient de plus en plus complexe pour les développeurs. Ce rapport examine les différences entre les solutions de couche 1 (L1) et de couche 2 (L2) pour les plateformes généralistes de smart contracts, ainsi que leurs conséquences sur l’engagement des utilisateurs, les marges économiques et la croissance des entreprises.

Malgré la diversité et les progrès du secteur de la blockchain, sa base d’utilisateurs reste modeste par rapport aux grandes plateformes numériques. Par exemple, la crypto rassemble actuellement environ 5,5 millions d’adresses uniques attribuables chaque jour, contre près de 2 milliards d’utilisateurs quotidiens pour des plateformes comme Facebook.

Aujourd’hui, les clients des blockchains sont les développeurs. Les blockchains vendent de l’espace de bloc aux développeurs d’applications afin qu’ils puissent créer des produits novateurs. Le choix de l’environnement dans lequel développer votre application est l’une des décisions les plus importantes auxquelles un développeur est aujourd’hui confronté. D’un point de vue commercial, c’est également une décision majeure qui influera ensuite sur les utilisateurs potentiels, la liquidité et la culture. Après le lancement, la migration des systèmes constitue une entreprise difficile, tant sur le plan technique que social, sans être impossible. Des équipes comme dydx ont réussi leur migration d’Ethereum vers une appchain Cosmos, tandis que y00ts a rencontré des difficultés lors de sa migration de Solana vers Polygon, puis vers Ethereum.

Ce rapport n’a pas vocation à prendre parti dans le débat actuel entre architectures modulaires et intégrées. Il propose plutôt aux développeurs, aux futurs développeurs et aux dirigeants une perspective pratique pour mieux comprendre le paysage L1/L2, avec des exemples concrets des compromis applicatifs propres à certaines conceptions.

Caractéristiques d’une blockchain

Avant d’aborder les différences entre les L1 et les L2, nous devons d’abord définir les caractéristiques d’une blockchain.

Une blockchain est une machine à états répliquée et déterministe. Il s’agit d’un système complexe conçu pour parvenir à un consensus et maintenir un registre unifié et sécurisé sur un réseau distribué.

Déterministe

Les processus internes d’une blockchain sont prédéterminés par le protocole sous-jacent. Lorsque la « fonction de transition d’état » (STF) d’une blockchain est exécutée avec une entrée donnée et l’état actuel, elle produit le même nouvel état sur tous les nœuds. Ce caractère déterministe garantit un résultat cohérent, indépendamment de la personne qui exécute la fonction ou du nœud qui traite la transaction. Les processus déterministes garantissent la fiabilité et la prévisibilité des opérations du réseau.

Répliquée

Les blockchains s’appuient sur un réseau de nœuds qui conservent chacun une copie de l’état complet de la blockchain. Cette réplication contribue à la décentralisation et renforce la résilience face à la perte et à la falsification des données. Chaque nœud détenant une réplique de l’état, toute tentative de modification de l’historique nécessiterait de modifier simultanément la majorité des nœuds. Dans un réseau distribué suffisamment vaste, une telle opération est pratiquement irréalisable.

Machine à états

Une blockchain est fondamentalement un système qui gère des états : des instantanés d’un moment précis regroupant toutes les informations ayant fait l’objet d’un accord, comme les soldes des comptes, les états des smart contracts et les registres de propriété. La blockchain évolue au moyen de transactions, qui sont des demandes visant à passer d’un état à un autre. Ces transitions sont régies par les règles encodées dans le protocole de la blockchain.

Ces propriétés produisent un registre que tout le monde peut lire ou modifier. Comme Balaji l’a souligné en 2019, les blockchains publiques sont des bases de données mondiales multiclients dans lesquelles chaque utilisateur dispose des privilèges root. Elles offrent ainsi une vue globale du nombre d’actifs (tokens, NFT, etc.) détenus par chaque utilisateur et permettent une innovation sans autorisation autour de l’état public mondial partagé.

Participants au marché de la blockchain

Les blockchains facilitent un marché mondial d’informations convenues reposant sur une confiance décentralisée. Un réseau blockchain compte deux grandes catégories de parties prenantes :

• Fournisseurs de confiance : stakers, validateurs et mineurs (selon que le réseau utilise la PoW ou la PoS)
• Consommateurs de confiance : applications (qui regroupent souvent les transactions et répercutent le coût opérationnel marginal sur l’utilisateur)

Autrement dit, les blockchains facilitent un marché biface entre acheteurs et vendeurs, comme tout autre marché économique. Selon l’offre et la demande, le marché fixe le coût associé aux échanges entre les deux parties.

Les blockchains publiques ont besoin de frais pour empêcher le spam et attribuer les ressources rares. Ces frais constituent la principale forme de rémunération ou de revenu des validateurs et des mineurs, couvrant leurs frais généraux (équipement, électricité et autres ressources). Les mécanismes de tarification varient selon les protocoles, mais toutes les grandes blockchains publiques intègrent le gas au protocole d’une manière ou d’une autre. Quelqu’un exploite du matériel informatique quelque part dans le monde et doit être rémunéré pour y être incité.

Définition des L1 et des L2

Maintenant que nous comprenons mieux ce qu’est une blockchain et ce qu’elle permet, nous pouvons formaliser la définition d’une L1 et d’une L2.

La définition exhaustive et rigoureuse des L1 et des L2, ainsi que leurs connotations respectives, fait l’objet d’un débat animé parmi les chercheurs et l’ensemble de la communauté crypto. Différentes variantes de rollups ont émergé (optimistic, à divulgation nulle de connaissance, inscrits dans le protocole), avec des détails d’implémentation et des hypothèses de confiance différents (validiums, volitions, souverains, entre autres).

Avant d’aborder les compromis entre les L1 et les L2, nous devons les définir.

Couches 1 (L1)

Les blockchains L1 sont des réseaux fondamentaux qui constituent l’infrastructure principale d’une cryptomonnaie. Ce sont des réseaux autonomes dotés de leurs propres protocoles sous-jacents, mécanismes de consensus et tokens natifs. Les L1 sont souvent qualifiées de couche de base d’un écosystème blockchain, car elles fournissent le cadre fondamental de sécurité et de gouvernance.

Ethereum a inauguré le concept de confiance modulaire lors de son lancement en 2015. Ethereum n’était toutefois pas, et n’est toujours pas, optimisé pour l’échelle nécessaire à l’intégration de millions d’utilisateurs. De nouvelles solutions d’évolutivité, comme les rollups, sont donc apparues comme une piste prometteuse pour faire évoluer Ethereum.

Couches 2 (L2)

Les solutions L2 sont construites au-dessus des blockchains L1 pour améliorer l’évolutivité et le débit des transactions sans modifier la couche de base. Les rollups comptent parmi les solutions L2 les plus prometteuses et les plus étudiées.

Les rollups déchargent les transactions de la L1, les traitent séparément, puis enregistrent l’état final sur la L1, souvent sous la forme d’une racine d’état. Cette approche permet au rollup d’exécuter des transactions supplémentaires dans un environnement d’état distinct, à un coût inférieur à celui d’une exécution directe sur la L1. Les rollups regroupent, ou « enroulent », plusieurs transactions en une seule transaction sur la L1 afin de réduire la charge et d’améliorer l’efficacité. Les différentes solutions L2 reposent sur différentes hypothèses de confiance et cherchent généralement à hériter des propriétés de sécurité et de décentralisation de la L1 sous-jacente. Elles constituent ainsi des alternatives sécurisées mais plus évolutives au traitement de chaque transaction sur la L1.

Celestia a formalisé cette définition des rollups :

En pratique, Ethereum possède les actifs les plus intéressants et à la valeur nominale la plus élevée du secteur crypto. Les utilisateurs se montrent disposés à transférer leurs actifs vers différentes solutions L2 sans trop se préoccuper de certains de leurs aspects plus centralisés, qui font l’objet d’un développement actif mais ne sont souvent pas encore opérationnels, afin de profiter de frais nettement inférieurs à ceux du mainnet Ethereum. 

La sécurité est une préoccupation courante lors du transfert d’actifs entre chaînes. Bien que de nombreux bridges de rollups reconnus ne disposent pas de systèmes de preuve rigoureux et aient été critiqués en raison de points de contrôle potentiellement centralisés, ils offrent une extension fluide de l’expérience Ethereum grâce à une expérience similaire de type EVM et à l’uniformité des wallets. Des rollups comme Base, Optimism et Arbitrum préservent autant que possible le wallet et l’infrastructure d’adresses Ethereum existants de l’utilisateur, fluidifiant considérablement les transitions entre la chaîne principale et les L2. Cette simplicité, associée à la domination de l’ETH dans les applications DeFi et sociales, fait des L2 une proposition attrayante pour les utilisateurs en quête de familiarité et de facilité d’utilisation. Ethereum possède l’état le plus populaire avec lequel les autres développeurs souhaitent interagir, et les L2 sont considérées comme une extension naturelle d’Ethereum.

Autrement dit, le fait d’« hériter » de certaines garanties de sécurité d’Ethereum arrive loin dans la liste des raisons pour lesquelles une équipe choisit de se lancer sous forme de L2 Ethereum ou de migrer d’une L1 autonome vers une L2.

De nouvelles technologies comme Solang et Neon comblent l’écart pour les développeurs habitués à Solidity d’Ethereum, tandis que Snaps de Metamask étend la prise en charge des wallets aux chaînes non-EVM. Ces évolutions annoncent un avenir dans lequel l’UX masquera efficacement nombre des complexités des différents environnements d’exécution.

Bien que l’Ethereum Foundation ait financé une grande partie des recherches sur les L2, toutes les L2 sont des entités indépendantes qui ne sont pas exploitées par l’Ethereum Foundation. L’innovation sans autorisation ne se limite pas à la couche des applications décentralisées, et aucune L1 réellement neutre ne dispose de la capacité technique de décider quelles L2 peuvent être déployées au-dessus d’elle.

Implémentations et architectures « typiques » des L1 et L2

Pour bien comprendre les compromis entre les L1 et les L2, il est essentiel de comprendre leurs chaînes d’approvisionnement respectives, les acteurs concernés et leurs hypothèses de confiance.

Cycle de vie d’une transaction L1

Bien que chaque L1 présente des détails d’implémentation uniques, toutes les grandes L1 ont relativement les mêmes parties prenantes et le même cycle de vie des transactions. Cette section décrit le parcours commun d’une transaction, de sa génération à son inclusion finale.

1. Intention

L’utilisateur part d’un objectif ou d’une action précise qu’il souhaite accomplir sur le réseau Ethereum, comme envoyer de l’ETH, interagir avec un smart contract ou échanger des tokens. Cette étape couvre le processus de décision de l’utilisateur et sa compréhension de ce qu’il souhaite réaliser. Elle détermine le parcours de la transaction.

2. Génération de la transaction

La transaction prend ici forme. Souvent à l’aide d’une interface utilisateur comme un wallet ou une application décentralisée, l’utilisateur saisit les informations nécessaires, telles que l’adresse du destinataire, le montant à envoyer ou la méthode du contrat à appeler. Cette étape traduit l’intention de l’utilisateur en une requête structurée que le réseau Ethereum peut traiter. À ce stade, l’utilisateur détermine le coût de la transaction, qui comprend le prix et la limite de gas. Celui-ci dépend fortement de la chaîne et est souvent masqué par le fournisseur du wallet. Ethereum et Solana en implémentent tous deux une version au moyen de frais de base et de frais de priorité (pourboire), avec des implémentations et des niveaux de déterminisme différents pour l’inclusion des transactions.

3. Transmission

L’utilisateur signe la transaction avec sa clé privée, une signature numérique qui prouve son autorisation. Une fois signée, la transaction est diffusée sur le réseau, généralement par l’intermédiaire d’un fournisseur RPC intégré au wallet, le plus souvent via le mempool public ou des enchères privées de flux d’ordres, où elle attend d’être traitée.

4. Confirmation de l’inclusion

La transaction arrive à son terme lors de cette dernière étape. L’utilisateur reçoit la confirmation que la transaction a bien été incluse dans un bloc, avec des niveaux de finalité variables selon le protocole. La finalité clôt le processus et permet aux utilisateurs de vérifier les résultats, comme la mise à jour des soldes ou de l’état des contrats.

La chaîne d’approvisionnement d’Ethereum

Ethereum vise à offrir une couche d’infrastructure réellement neutre pour les applications résistantes à la censure. Le mécanisme de sa chaîne d’approvisionnement a considérablement évolué. Initialement fondé sur la preuve de travail (PoW), Ethereum confiait aux mineurs le contrôle de l’inclusion et de l’ordre des transactions. Des enchères prioritaires de gas (PGA) ont alors émergé : les chercheurs se disputaient l’espace de bloc, ce qui gonflait le mempool et entraînait une utilisation inefficace de la chaîne. Flashbots Auction, un relais hors protocole destiné aux lots MEV, a atténué certains effets centralisateurs de la MEV en transférant les marchés MEV hors chaîne, mais reposait sur l’honnêteté de l’opérateur du relais et des mineurs.

Avec le passage à la preuve d’enjeu (PoS), la production des blocs d’Ethereum a été transférée aux validateurs ayant staké des actifs, introduisant une nouvelle dynamique et de possibles problèmes de centralisation. Sous la PoS, les économies d’échelle liées à l’extraction de MEV pourraient centraliser les enjeux et menacer la résistance d’Ethereum à la censure.

Pour répondre aux préoccupations concernant la centralisation des enjeux, Flashbots a introduit la séparation entre proposant et constructeur (PBS). Elle a d’abord été mise en œuvre sous la forme de MEV-Boost, un nouveau régime de production des blocs. Dans ce système, les chercheurs envoient des lots aux constructeurs de blocs, qui construisent ensuite les blocs et soumettent des offres au proposant par l’intermédiaire de relais de blocs. MEV-Boost déplace les forces centralisatrices vers la couche des constructeurs de blocs, ce qui exige de faire confiance aux constructeurs et aux relais. En décembre 2023, plus de 93 % des blocs Ethereum étaient proposés par des validateurs exécutant MEV-Boost.

MEV-Boost et PBS ne sont toutefois pas exempts de problèmes. Le relais MEV-Boost exploité par Flashbots impose la conformité OFAC, un équilibre indésirable pour un système équitable et sans autorisation. La centralisation des relais crée un risque de censure et de comportement malhonnête, car ils deviennent des intermédiaires essentiels entre les constructeurs et les validateurs. La forte dépendance envers des logiciels hors protocole comme MEV-Boost accroît aussi la vulnérabilité d’Ethereum aux exploits et aux attaques, comme l’illustrent des incidents tels que l’exploit low-carb-crusader. Des discussions sont en cours pour intégrer PBS au protocole (ePBS) Ethereum, en reprenant une grande partie des travaux financés par Flashbots. La centralisation des constructeurs est une autre préoccupation : quelques acteurs dominent le marché et pourraient exercer une censure ou une influence sur le réseau. De nouvelles solutions comme SUAVE cherchent à atténuer ces risques.

La chaîne d’approvisionnement de Solana

Lancée en 2020, Solana est une L1 distincte qui a introduit de nombreuses avancées afin de résoudre le problème d’évolutivité sur la couche de base sans solution tierce supplémentaire telle qu’une L2. En permettant avant tout aux applications de « partager leur état », Solana assure une composabilité native entre elles, avec un travail minimal pour les développeurs et sans opérations utilisateur complexes ni hypothèses de confiance supplémentaires, contrairement aux bridges.

Sur Solana, une transaction comprend trois composants principaux : un ensemble d’instructions définissant ses opérations, une liste des comptes et des autorisations associées avec lesquels elle interagira, et les signatures nécessaires à son authentification. Une fois la transaction confirmée par l’utilisateur, elle est envoyée à un serveur RPC Solana, qui la transmet au leader actuel du réseau chargé de produire les blocs. Ce mécanisme est appelé Gulf Stream, l’une des huit innovations propres à Solana.

À sa réception, le leader valide la transaction et planifie son exécution. Le modèle d’exécution parallèle de Solana lui permet de traiter plusieurs transactions simultanément et rend possibles le parallélisme et les « marchés de frais locaux ». Il s’appuie pour cela sur un ordonnanceur multithread dans lequel les transactions sont mises en file d’attente en fonction des frais de priorité et du temps.

Après l’exécution, le leader enregistre la transaction dans le registre et la diffuse sur le réseau. Son statut est ensuite mis à jour par étapes : après l’exécution, elle devient « confirmée » une fois qu’un nombre suffisant de votes de consensus a été obtenu, puis « finalisée » lorsque le nombre requis de blocs supplémentaires (31 ou plus) a été construit de manière sécurisée par-dessus.

Contrairement à Ethereum, qui offre empiriquement des garanties bien plus robustes sur l’ordre des transactions en fonction des frais, Solana n’utilise pas d’ordre déterministe. Les transactions assorties de frais de priorité plus élevés ont généralement plus de chances d’être placées en tête d’un bloc, et la concurrence pour un état exige souvent des frais plus élevés, mais ce résultat n’est pas garanti. La probabilité de ces événements dépend du caractère non déterministe de l’algorithme d’ordonnancement par défaut de Solana, qui détermine l’inclusion et la position des transactions dans un bloc. Cela encourage les activités hors protocole, notamment les accords directs entre chercheurs et validateurs, qui produisent des externalités négatives pour l’utilisateur médian.

Il est vrai que la MEV sur Ethereum constitue un marché bien plus vaste, avec plus de 750 millions de dollars (373 701 ETH) extraits depuis The Merge. Davantage de temps et de ressources ont donc été consacrés à la MEV, qui est beaucoup mieux comprise et étudiée au moyen de mécanismes compatibles avec les incitations.

Il s’agit de l’une des principales différences philosophiques entre Ethereum et Solana, qui se reflète dans l’allocation des ressources et la culture de chaque écosystème. Ethereum investit massivement dans la recherche et la conception de mécanismes compatibles avec les incitations, comme PBS, avec des discussions en cours sur ePBS. Le protocole central de Solana est quant à lui spécialement conçu pour synchroniser l’état mondial et délègue les services et garanties d’ordonnancement spécialisés à des équipes de l’écosystème comme Jito. Anatoly, CEO de Solana Labs, exprime clairement son avis selon lequel l’état actuel de Solana constitue un meilleur équilibre temporaire pour l’utilisateur médian.

Expérience utilisateur (UX) sur les L1

Du point de vue de l’utilisateur, soumettre une transaction à une blockchain de couche 1 comme Ethereum ou Solana est l’une des opérations les plus simples du secteur crypto. Elle comprend généralement les étapes suivantes :

1. Configuration du wallet

L’utilisateur doit d’abord télécharger un wallet. Il peut s’agir d’un wallet logiciel comme MetaMask, d’une application mobile ou d’un wallet matériel offrant davantage de sécurité.

2. Acquisition du token natif de la L1

Assurez-vous que votre wallet contient suffisamment d’ETH/SOL pour couvrir la transaction et les frais de gas. Vous pouvez acheter de l’ETH sur différentes plateformes d’échange centralisées. Des équipes et des protocoles travaillent sur l’abstraction de compte, dont l’une des fonctionnalités permet de payer le gas avec n’importe quel token, et non uniquement avec le token natif de la L1. Ethereum l’implémente au moyen de l’EIP-4337. Solana intègre une abstraction de compte native au protocole, ainsi qu’un relais de transactions sans gas appelé Octane.

3. Saisie des détails de la transaction

Accédez à votre wallet et sélectionnez l’option permettant d’envoyer de l’ETH ou des tokens. Saisissez l’adresse Ethereum du destinataire, le montant d’ETH ou le nombre de tokens à envoyer, ainsi que toute donnée supplémentaire requise pour les interactions avec des smart contracts. Lors d’une interaction avec une application, la transaction est généralement préparée à votre place par le développeur de l’application.

4. Définition du prix et de la limite de gas

Le wallet les définit automatiquement ou vous permet de les choisir. L’implémentation exacte du gas varie selon la L1 avec laquelle vous interagissez.

5. Signature et envoi

Signez la transaction avec votre wallet. Ce processus varie selon le wallet. Celui-ci diffuse ensuite la transaction sur le réseau, généralement par l’intermédiaire d’un nœud RPC.

6. Confirmation

Une transaction est confirmée lorsqu’elle est incluse dans un bloc et ajoutée à la blockchain. La plupart des wallets vous signalent la fin de la transaction. Vous pouvez également la suivre dans un explorateur de blockchain comme Etherscan ou Solscan.

Expérience utilisateur (UX) sur les L2

L’interaction avec une L2 présente des différences notables en matière d’UX. Voici comment un nouvel utilisateur peut rejoindre Optimism, l’une des plus grandes L2 d’Ethereum :

1. Téléchargement d’un wallet

Si vous n’en avez pas, téléchargez et configurez un wallet. Les utilisateurs se servent généralement du même wallet dans plusieurs écosystèmes EVM, par exemple Metamask.

2. Ajout du réseau Optimism

3. Dépôt d’ETH sur Optimism

• Pour les grandes L2, cette opération peut souvent être effectuée nativement dans le wallet.
• Vous pouvez également accéder au bridge officiel d’Optimism.
• Choisissez le montant d’ETH à transférer vers Optimism et confirmez la transaction.

4. Passage au réseau Optimism dans votre wallet

Ouvrez votre wallet et sélectionnez « Optimism » dans le menu déroulant des réseaux.

5. Interaction avec les applications et interfaces compatibles avec Optimism

Sélectionnez « Optimism » dans les applications qui prennent en charge le réseau Optimism.

Les L2 ont progressé en matière d’UX, notamment pour les actifs natifs et l’intégration des utilisateurs. Circle, qui exploite USDC, propose des versions natives d’USDC sur la plupart des grandes L2, éliminant le risque de contrepartie supplémentaire généralement associé aux bridges et aux tokens enveloppés. Par ailleurs, l’avantage de Coinbase en matière de distribution a permis une intégration étroite entre sa plateforme et Base, une L2 d’Ethereum dont Coinbase est l’unique opérateur du séquenceur.

Composants des L2

Après le transfert des fonds vers une L2 donnée, une opération parfois obscure et complexe selon la L2 utilisée, l’expérience de transaction sur une L2 ressemble souvent à celle d’une L1. Les L2 utilisaient auparavant principalement Ethereum pour différents éléments de la pile blockchain, mais beaucoup privilégient aujourd’hui une approche « modulaire ». Cette approche permet de combiner différents écosystèmes et infrastructures en séparant les principaux composants d’une L2 : l’exécution, le règlement et la disponibilité des données. Les L2 utilisaient auparavant Ethereum pour tout sauf l’exécution, mais cette situation évolue rapidement avec l’apparition de nouvelles solutions de règlement et de disponibilité des données. Les L1 proposent quant à elles tous ces composants de manière intégrée et prescriptive, sans permettre aux développeurs de choisir l’architecture souhaitée sans l’accord de la gouvernance.

Exécution

L’exécution vise à appliquer une fonction de transition d’état à l’état antérieur afin d’obtenir l’état ultérieur. Différentes machines virtuelles (VM), comme l’Ethereum Virtual Machine (EVM), Sealevel de Solana (SVM), MoveVM ou FuelVM, servent de normes pour régir ces transitions d’état. Chaque VM offre des fonctionnalités propres qui influent sur la compatibilité, la disponibilité des outils de développement et l’efficacité du traitement des transactions. Elles créent l’environnement d’exécution des smart contracts et des protocoles.

C’est au niveau de la couche d’exécution que les développeurs d’applications déploient effectivement le code, que les transactions ont lieu et que les utilisateurs interagissent avec l’état de la blockchain. Cette couche est conçue pour traiter rapidement les transactions tout en déléguant les responsabilités de sécurité et de disponibilité des données à d’autres couches spécialisées.

Rien n’impose que la machine virtuelle de la L2 corresponde à celle de la L1. Bien que cela ait historiquement été le cas, la plupart des L2 étant des rollups EVM ou compatibles avec l’EVM, davantage d’équipes explorent cet espace de conception avec différentes machines virtuelles qui « règlent » leurs opérations sur Ethereum, comme Eclipse et Movement Labs.

Règlement

Beaucoup considèrent désormais le terme « règlement » comme un terme surchargé. Pour comprendre le règlement, il est important de distinguer le point de vue du « rollup » de celui du « bridge ». Les bridges appliquent souvent un processus de finalisation d’une semaine, mais le bridge n’est pas le rollup. Du point de vue du rollup, la finalisation intervient après la vérification de la transition d’état et la publication des données pertinentes sur une couche de disponibilité des données.

Les couches de règlement remplissent plusieurs fonctions essentielles pour les rollups :

• Vérification et gestion des litiges : elles servent de plateformes sur lesquelles les rollups peuvent publier leurs preuves afin qu’elles soient validées de manière externe. Cette fonction est essentielle aux rollups optimistic qui reposent sur des preuves interactives de fraude.
• Centre de connexion : en constituant un point central, les couches de règlement permettent aux rollups de s’interconnecter, ce qui évite de devoir créer un bridge individuel entre chaque rollup.
• Source de liquidité : tous les rollups associés peuvent accéder à la liquidité présente sur la couche de règlement, ce qui fluidifie les transactions et les interactions.

Comme indiqué, Ethereum possède les actifs les plus intéressants et à la valeur nominale la plus élevée du secteur crypto : les utilisateurs souhaitent interagir avec l’état d’Ethereum. Ethereum sert de « couche de règlement », car les utilisateurs ont montré une nette préférence pour les interactions avec un bridge inscrit dans le protocole menant à une chaîne distincte, à savoir la L2 Ethereum qu’ils utilisent. Le marché n’a pas considéré les bridges L1 vers L1 de la même manière, probablement en raison des piratages antérieurs et d’une UX plus complexe. Le transfert d’une L1 vers une L2 peut souvent être étroitement intégré à un seul wallet. L’UX s’améliore rapidement grâce à des wallets comme Phantom, qui prend en charge Ethereum et Solana, et à la sortie de Snaps par Metamask. En termes plus formels, les utilisateurs acceptent d’interagir avec le bridge inscrit dans le protocole défini par un rollup donné.

Le comportement des utilisateurs évolue rapidement. Wormhole a enregistré plus de 500 millions de dollars de volume au cours des 30 derniers jours, réduisant l’écart avec les 825 millions de dollars de volume du bridge Optimism sur 30 jours.

On peut avancer que les bridges L1-L1 ont souffert d’une dépendance au sentier, avec des piratages majeurs comme celui de Wormhole au début de l’année 2022. Si le partage de la DA permet des hypothèses de confiance techniques spécifiques, les implémentations réelles des bridges L1-L2 et L1-L1 sont souvent sécurisées par un multisig.

Il faut surtout retenir que les rollups « règlent leurs opérations sur Ethereum », ou plus précisément finalisent un bridge inscrit dans le protocole vers Ethereum, afin d’accéder à l’état d’Ethereum dans le but explicite d’obtenir des utilisateurs et de la liquidité. Le règlement n’est pas en lui-même une activité rentable pour Ethereum, car des rollups comme Optimism paient moins de 50 dollars par jour en ETH à Ethereum pour le règlement. Plus de 80 % des coûts des rollups proviennent de la publication des données dans les blocs de la L1 Ethereum sous forme de calldata. C’est pourquoi les solutions de disponibilité des données font aujourd’hui l’objet d’une telle concurrence. Au total, les L2 représentent environ ~6 % des frais de la L1 Ethereum, lorsqu’elles utilisent Ethereum pour la disponibilité des données.

Disponibilité des données (DA)

La disponibilité des données dans les blockchains désigne la garantie que toutes les données d’un bloc sont effectivement publiées et accessibles au réseau. Ce concept est essentiel au fonctionnement et à la sécurité des blockchains, en particulier lors de leur mise à l’échelle. Un bloc se compose généralement d’un en-tête et des données de transaction. Les nœuds complets téléchargent et valident chaque transaction, tandis que les clients légers, moins gourmands en ressources, utilisent uniquement l’en-tête du bloc et supposent que les transactions sont valides. Le problème de disponibilité des données survient lorsqu’un producteur de blocs publie l’en-tête d’un bloc, mais retient une partie ou la totalité des données de transaction.

Bien qu’elles ne se soient pas encore produites, les attaques par rétention de données menacent les réseaux blockchain. Lors d’une telle attaque, un producteur de blocs malveillant retient délibérément une partie des données de transaction d’un nouveau bloc. Cela empêche les autres participants du réseau de valider les transactions du bloc. Les conséquences peuvent aller d’une perturbation du réseau à des problèmes plus graves, comme l’autorisation de transactions frauduleuses. La gravité et l’incidence de ces attaques varient selon la structure de la blockchain, couche 1 ou couche 2, et selon que la disponibilité des données est gérée sur chaîne ou hors chaîne. Ce risque souligne l’importance de mécanismes robustes garantissant la disponibilité des données et de stratégies efficaces pour atténuer ces attaques.

Le problème de disponibilité des données peut être résolu en demandant à tous les nœuds complets de télécharger toutes les données, ce qui peut exiger beaucoup de ressources, ou au moyen d’approches innovantes comme les preuves de disponibilité des données et l’échantillonnage de disponibilité des données (DAS). Ces preuves utilisent des techniques comme le codage d’effacement, qui permet aux clients de vérifier la disponibilité des données en ne téléchargeant qu’une petite partie du bloc.

Selon la terminologie la plus récente, un véritable « rollup Ethereum » doit utiliser Ethereum pour la disponibilité des données. Pour être considéré comme un rollup, il doit donc publier ses données de transaction sous forme de calldata sur la L1 Ethereum. Ethereum travaille actuellement à l’implémentation de l’EIP-4844, qui créera un marché distinct pour le blobspace (les données de transaction) et permettra de publier des blobs de données à un tarif encore réduit. Même lorsque la version 4844 sera opérationnelle, elle n’augmentera la disponibilité des données que d’un facteur d’environ ~7, soit environ 100 TPS (transactions par seconde) pour l’ensemble des rollups. À titre de comparaison, la demande d’espace de bloc de Solana s’établit à environ 500 TPS et le réseau a démontré sa capacité à traiter plus de 2 000 TPS. De plus, Solana est conçu pour évoluer avec le matériel, selon la loi de Moore, et avec des avancées logicielles comme Firedancer.

Bien que la disponibilité des données puisse présenter de légers effets de réseau, la concurrence ramènera probablement le coût de publication des données sur une solution de disponibilité des données très près du coût opérationnel marginal.

La DA garantit que toutes les données de transaction nécessaires sont accessibles afin de reconstruire l’état d’une L2 sur une période prédéfinie. À court terme, les validiums et les volitions utilisent des couches de disponibilité des données distinctes, tandis que la feuille de route à long terme d’Ethereum prévoit une solution améliorée grâce à des mises à niveau comme l’EIP-4844. D’autres solutions de disponibilité des données, comme Polygon Avail, Celestia et EigenDA, devraient jouer un rôle important et approfondir l’exploration de différentes architectures de DA. Il convient toutefois de noter que ces solutions ne sont pas encore opérationnelles, à l’exception de Celestia, qui vient de lancer son mainnet mais ne reçoit encore les données d’aucun rollup. Elles reposent toutes sur de nouveaux systèmes dont le fonctionnement à grande échelle en production n’a pas encore été prouvé, avec un large éventail d’hypothèses propres en matière de sécurité et de confiance. Elles offrent une solution provisoire en attendant que la couche complète de disponibilité des données d’Ethereum devienne opérationnelle, et pourraient conserver des effets de réseau même après l’intégration d’Ethereum.

Cycle de vie d’une transaction L2

Le cycle de vie d’une transaction sur Arbitrum, un protocole de couche 2, comprend plusieurs étapes allant de son lancement à sa confirmation et sa finalisation :

1. Le séquenceur reçoit la transaction

Les transactions commencent auprès du séquenceur. Elles sont reçues directement ou hors chaîne pour les transactions L2, ou depuis la L1 par l’intermédiaire de la Delayed Inbox pour les dépôts.

2. Le séquenceur ordonne la transaction hors chaîne

Le séquenceur ordonne la transaction dans son Inbox hors chaîne et l’exécute avec l’Arbitrum Nitro VM, en fournissant au client un reçu « instantané ». La finalité de cette phase dépend de la confiance accordée au séquenceur.

3. Le séquenceur publie la transaction dans un lot sur la chaîne

Le séquenceur publie à intervalles réguliers des lots de transactions L2 sur la L1, accompagnés des données pertinentes sous forme de calldata. S’il n’inclut pas une transaction, le client peut forcer son inclusion après un délai, ce que l’on appelle l’inclusion forcée. À ce stade, s’il existe au moins un validateur Arbitrum actif et fiable, la finalité de la transaction équivaut à celle d’une transaction Ethereum.

4. Le validateur atteste un bloc de rollup (RBlock) contenant la transaction

Les validateurs attestent à intervalles réguliers l’état de la chaîne L2 sur la L1. Les attestations RBlock comprennent des affirmations sur l’état de l’Outbox pour les messages allant de la L2 à la L1. En cas de contestation : lors d’un litige, les validateurs entreprennent une procédure de vérification détaillée jusqu’à une opération unique, arbitrée par des contrats sur la L1.‍

5. Le RBlock est confirmé sur la L1

Après la résolution des litiges et l’écoulement d’un délai suffisant, le RBlock est confirmé sur la L1 et la racine de l’Outbox est mise à jour.

Ce processus garantit qu’une fois confirmée la transaction L1 qui enregistre un lot, la transaction L2 qu’il contient bénéficie du même niveau de finalité qu’une transaction Ethereum ordinaire. Si la transaction comprend des messages allant de la L2 à la L1, ceux-ci ne deviennent exécutables sur la L1 qu’après la confirmation du RBlock.

Comme les rollups existent en dehors d’Ethereum, ce qui ne doit pas être confondu avec le fait que nombre d’entre eux sont aujourd’hui fondés sur l’EVM ou équivalents à l’EVM, la chaîne d’approvisionnement des transactions implique d’autres considérations et parties prenantes. Voici les caractéristiques d’Arbitrum et d’Optimism, les rollups qui dominent actuellement Ethereum :

• Séquenceur centralisé : Arbitrum et Optimism, les plus grands rollups optimistic d’Ethereum, fonctionnent actuellement avec un seul séquenceur centralisé. Celui-ci est chargé d’ordonner toutes les transactions. Il est prévu de décentraliser ce rôle, potentiellement au moyen de nœuds L2 élus par la communauté, mais les détails et les calendriers restent flous. Les utilisateurs font confiance au séquenceur pour qu’il ne vende pas le flux d’ordres, ne réordonne pas les transactions et n’extraie pas de MEV d’une autre manière. Les preuves de fraude figurent sur la feuille de route, mais les contestations sans autorisation ne sont pas encore opérationnelles.
• Hypothèse de confiance : à ce stade, la finalité dépend de la confiance accordée au séquenceur. Son rôle se limite à ordonner ou retarder les transactions, et non à les modifier. Arbitrum permet l’inclusion forcée des transactions retardées de plus de 24 heures, tandis qu’Optimism inclut automatiquement les transactions L1 dans le prochain bloc L2 disponible.
• Réorganisations de la L1 : lorsqu’une réorganisation de la L1 se produit, la politique de poursuite et de gestion des blocs L2 n’est pas explicitement détaillée. La finalité des transactions reste donc quelque peu incertaine pendant les réorganisations de la L1.
• Finalité : les séquenceurs regroupent les transactions L2 et les publient sur Ethereum sous forme de calldata. Elles obtiennent ainsi une « finalité forte » équivalente à celle du bloc Ethereum dans lequel elles sont incluses. La racine de l’arbre d’état de la L2, qui représente le dernier état du rollup, est ensuite mise à jour sur la L1, ce qui garantit l’irréversibilité des changements d’état.
• Période de contestation et retrait : les validateurs d’Arbitrum peuvent contester les racines d’état et lancer une procédure de résolution des litiges. Si un engagement d’état n’est pas contesté pendant la période prévue, il devient définitif. Après la période de contestation, les retraits de la L2 vers la L1 fondés sur l’état final sont autorisés.
• Transfert par bridge : les protocoles de bridge tiennent compte de différents niveaux de finalité, des reçus instantanés sous « finalité souple » aux calldata regroupées sous « finalité forte ». Les bridges peuvent choisir une messagerie plus rapide en fonction des besoins des clients ou respecter des normes de finalité plus strictes selon le type de transaction et l’évaluation des risques.

Quand les L2 sont pertinentes

Les L2 sont des systèmes avec état. Chaque L2 supplémentaire fragmente l’état entre les différentes L2. Même si la composabilité atomique est sacrifiée — à tort ou à raison —, un déploiement sur une L2 est pertinent pour certaines applications. En outre, il est très important de choisir la bonne L2, même si celle-ci s’exécute dans un environnement d’exécution populaire comme l’EVM. Les expériences utilisateur, les intégrations et la distribution varient considérablement d’une L2 à l’autre.

Sans entrer dans des détails trop techniques, les L2 peuvent globalement être réparties entre les rollups spécifiques à une application et les rollups généralistes.

Rollups spécifiques à une application

Contrairement aux L1 et aux autres L2 mentionnées précédemment, les rollups spécifiques à une application ne partagent pas l’espace de bloc avec d’autres applications. Ce sont au contraire des blockchains dédiées à une application particulière, ou à un ensemble d’applications. Vous êtes donc responsable de l’exploitation de toute l’infrastructure correspondante.

Certaines équipes sont intégrées verticalement et exploitent effectivement leur propre infrastructure (dydx), mais cela représente un travail d’ingénierie considérable. En général, seules les équipes ayant déjà trouvé leur adéquation produit-marché (PMF) y parviennent. Dans le cas de dydx, l’équipe bénéficie d’une adéquation produit-marché, d’une communauté solide et de ressources suffisantes pour le faire, après avoir trouvé son PMF sur Ethereum, puis sur une L2 Ethereum. D’autres projets comme Maker explorent des architectures telles qu’une chaîne applicative SVM. En pratique, la plupart des équipes n’exploitent pas leur propre matériel. Elles s’appuient plutôt sur des fournisseurs de rollup-as-a-service (RaaS) qui cherchent à combler ce besoin, comme Caldera et Conduit.

On ignore encore si les chaînes spécifiques à une application pourront générer suffisamment de revenus pour être rentables à long terme. Dans ces situations, il est important de comprendre le risque de contrepartie et la structure tarifaire des fournisseurs de RaaS. Ceux-ci facturent souvent des frais fixes, généralement compris entre 5 000 et 100 000 $, selon la taille de l’application, ainsi qu’un pourcentage des bénéfices du séquenceur. La plupart des fournisseurs de RaaS s’appuient sur des standards largement reconnus comme l’OP Stack pour éviter toute dépendance propriétaire. Ainsi, même si le fournisseur de RaaS fait faillite, vous pouvez toujours exploiter votre propre matériel, à condition de pouvoir surmonter l’interruption temporaire de disponibilité.

Comme le jeu vidéo est un cas d’usage plus spécialisé, de nouvelles implémentations et de nouveaux protocoles sont activement développés, notamment le World Engine d’Argus. Le 5 décembre, Dark Frontiers a été lancé comme shard d’exécution sur la L2 EVM d’Argus pour les jeux entièrement on-chain, contrairement aux autres jeux on-chain actuels, qui ne publient que des éléments simples du jeu sur la blockchain. Bien que cela reste à confirmer, cette approche semble se situer à mi-chemin entre les rollups spécifiques à une application et les rollups généralistes.

Rollups généralistes

Parce qu’ils constituent des environnements isolés où moins de capital économique est en jeu, les rollups sont quelque peu incités à expérimenter avec certaines couches de la pile, notamment celles de l’exécution et du consensus, afin de proposer un produit différencié. Cependant, la plupart des rollups utilisent des versions prêtes à l’emploi de VM existantes, à l’exception de Fuel. Ils cherchent ainsi à faciliter au maximum le déploiement des applications existantes sur leur L2. Cette dynamique a poussé les équipes qui innovent au niveau de l’exécution et du consensus à lancer leur propre L1, comme Monad.

La couche d’exécution pourrait bientôt faire l’objet de davantage d’expérimentations, car le nombre de rollups dépasse largement un équilibre raisonnable, surtout parmi ceux qui peinent à attirer des utilisateurs et des liquidités.

État actuel des rollups généralistes

Les rollups généralistes comme Arbitrum, Optimism et Base ont produit de puissants effets de réseau et attiré de nombreuses applications existantes et nouvelles, telles que GMX et friend.tech, qui se sont lancées sur ces L2. La présence des actifs natifs et de l’état d’Ethereum sur ces L2 — souvent avec Ethereum comme unité de compte pour leur jeton de gas — garantit aux utilisateurs et aux développeurs l’accès à un écosystème riche et mature. Cet accès est essentiel pour les applications qui recherchent des liquidités et veulent interagir avec des protocoles et actifs existants basés sur Ethereum. En matière d’expérience utilisateur, des plateformes comme Coinbase ont intégré à Base la prise en charge native des portefeuilles et des paiements, tout en exploitant son unique séquenceur, ce qui rend les interactions fluides et conviviales.

Lorsque vous évaluez différentes L2, il est important de prendre en compte les autres environnements d’exécution disponibles pour le déploiement, les liquidités et l’infrastructure de la L2 elle-même. La structure des coûts de disponibilité des données, les futures évolutions possibles des frais de réseau et la transformation du marché des fournisseurs d’infrastructure doivent éclairer la prise de décision. Les développeurs d’applications doivent comprendre la structure actuelle des coûts pour les utilisateurs et établir des projections raisonnables pour l’avenir en fonction de différents facteurs, notamment le coût de la disponibilité des données. Pour les développeurs qui envisagent un déploiement sur une L2, il est essentiel de comprendre les nuances de ces systèmes, en accordant une attention particulière à l’environnement d’exécution choisi et aux autres possibilités de déploiement.

Des recherches innovantes menées par l’Ethereum Foundation, notamment sur les « based rollups » séquencés par la L1, permettront aux rollups de continuer à progresser en matière de disponibilité, de décentralisation et d’expérience utilisateur. Les séquenceurs décentralisés — ou au moins une rotation entre plusieurs séquenceurs pour assurer la disponibilité — en sont encore au stade de la recherche, mais offrent des avancées prometteuses pour améliorer la fiabilité et réduire les risques actuels liés aux séquenceurs. Aujourd’hui, les utilisateurs font confiance au séquenceur exploité par l’équipe principale de la L2 pour ordonner équitablement les transactions, sans extraire de MEV de manière malveillante en les réordonnant. En cas de censure par le séquenceur, ils peuvent également soumettre leurs transactions directement à la L1 grâce à l’inclusion forcée.

D’un autre côté, il manque aux rollups actuels certaines fonctionnalités essentielles qui, selon leurs feuilles de route, sont en cours de développement. Par exemple, aucun des principaux rollups optimistes ne propose de preuves de fraude sans autorisation, et ces systèmes sont souvent contrôlés par des contrats évolutifs via des multisigs. De plus, de nombreux rollups ne disposent d’aucun mécanisme de secours permettant aux utilisateurs de retirer leurs fonds en présence d’un séquenceur malveillant.

L’aboutissement des rollups généralistes

L’un des scénarios possibles serait l’aboutissement d’un rollup généraliste doté d’un séquenceur « puissant », ou d’un ensemble de séquenceurs. Dans un monde où Ethereum conserve sa position de chaîne à l’état le plus intéressant et où les utilisateurs continuent de préférer nettement les bridges entre L1 et L2, une ou plusieurs L2 généralistes de type rollup pourraient offrir d’importants avantages d’exécution et une bien meilleure expérience utilisateur. 

La L1 n’existerait alors effectivement que pour fournir les propriétés requises par le rollup. Cela éliminerait pour la L2 le risque de réorganisation de la L1 et permettrait à la L2 d’optimiser les dimensions qui comptent pour les utilisateurs finaux : la latence et la mise à jour la plus efficace possible de l’état, généralement sous la forme de meilleurs prix. Ethereum, la L1 privilégiée, conserverait néanmoins un rôle, car le consensus social continuerait d’attribuer de la valeur à son état pour des raisons culturelles : parties impliquées dont la décentralisation est crédible, lancement équitable, etc. La L2 existerait comme une entité étrangère à la L1.

Les rollups présenteront les fonctionnalités et propriétés suivantes :

• Innovation sans autorisation – tout le monde peut créer et déployer de nouvelles applications
• Résistance à la censure – grâce à l’inclusion forcée sur la L1
• Disponibilité des données – directement sur la L1 ou sur une couche DA distincte
• Validité – preuves de fraude ou preuves zk
• Environnement d’exécution parallélisé – les transactions sont traitées de manière extrêmement efficace

Dans ce scénario final, quelques rollups, peut-être deux, concentrent un nombre significatif d’utilisateurs et un volume important. Une nouvelle application choisit de se déployer sur ce rollup, car l’accès à un grand nombre d’utilisateurs compense largement le coût du partage de l’espace de bloc, amorti pour se rapprocher autant que possible de zéro. Les préférences révélées des utilisateurs montrent qu’ils accordent une très grande importance à la simplicité de l’UX. Si nous atteignons un jour ce stade, la crypto aura effectivement réinventé la finance traditionnelle en y apportant plusieurs améliorations majeures : innovation sans autorisation, résistance à la censure, absence de conservation par un tiers et transparence. Seul un petit groupe d’acteurs dispose d’un accès en écriture aux marchés financiers traditionnels. Le NYSE et les autres bourses sont des marchés strictement réglementés et soumis à autorisation, qui peuvent censurer des personnes conformément aux lois et réglementations.

Dans ce scénario, la latence et la colocalisation avec les séquenceurs existeraient toujours, comme dans la finance traditionnelle avec les serveurs de carnets d’ordres. Actuellement, un accès soumis à autorisation, dicté par la politique et la dépendance au chemin suivi, détermine quelles entités ont le droit d’installer leur infrastructure à proximité des serveurs du NYSE. Les décennies d’expertise de Citadel dans l’optimisation des infrastructures et des algorithmes qui offrent de meilleurs prix aux utilisateurs finaux resteraient pertinentes dans un environnement sans autorisation. Dans ce scénario final des rollups, les personnes et les équipes rivaliseraient plutôt avec tous les autres talents du monde uniquement sur la base des performances, ce qui améliorerait les prix et l’expérience des utilisateurs finaux.

Tout cela semble séduisant en théorie, mais l’état actuel des L2 dresse un tableau bien différent. Non seulement les seuls séquenceurs sont exploités par l’équipe principale — créant un point unique de défaillance pour la disponibilité —, mais celle-ci contrôle souvent les actions les plus importantes, qu’il s’agisse du contrat du bridge ou des preuves de fraude soumises à autorisation. Même si de nombreuses L2 prévoient dans leur feuille de route de se décentraliser et de supprimer la multisig, ce n’est pas encore la réalité actuelle.

Quand les L1 sont pertinentes

Le concept d’état partagé sur les blockchains de Layer 1, comme Solana et Ethereum, permet une composabilité sans autorisation : les applications peuvent interagir entre elles de manière sécurisée et sans confiance. Cette propriété est notamment utile pour des stratégies marketing telles que les airdrops ciblés. Par exemple, grâce à l’état partagé, un projet peut identifier et récompenser des communautés NFT précises, ce qui permet de créer des mécanismes de récompense très ciblés et efficaces. Pyth, un oracle multichaîne dédié aux données, a récemment effectué un airdrop de $PYTH sur Solana à toute personne ayant interagi avec son protocole sur plus de 40 blockchains. En analysant les modèles de propriété et l’engagement des communautés au sein de la blockchain, les projets peuvent adapter leurs récompenses — par exemple des jetons exclusifs ou l’accès à de nouveaux services — afin d’inciter et d’engager des segments précis de la communauté blockchain. Ils peuvent ainsi créer des initiatives marketing plus pertinentes et plus percutantes.

L’état partagé rend possibles, de manière unique, ces attributions on-chain destinées aux récompenses et aux actions. Jupiter, un agrégateur de trading unifié qui garantit aux utilisateurs les meilleurs prix possible, illustre le type d’application qui ne peut exister que sur une chaîne à état partagé comme Solana.

Avec la DeFi, les paiements constituent l’un des cas d’usage les plus importants de la crypto. Ils permettent aux utilisateurs d’envoyer n’importe quelle somme sans intermédiaires prédateurs comme Western Union. Les paiements englobent aussi bien les transactions de pair à pair, comme avec Venmo, que les transactions des entreprises vers les consommateurs, comme les achats en ligne. Surtout, ils doivent être suffisamment rapides et peu coûteux pour que les utilisateurs n’aient pas à tenir compte des frais de gas lorsqu’ils envoient de l’argent. Sur Solana, plus de la moitié des transferts d’USDC sont inférieurs à 5 $, ce qui n’est possible que sur des blockchains aux frais de gas extrêmement faibles comme Solana.

Cela permet de créer de nouvelles entreprises, comme Tiplink, qui permet d’envoyer de l’argent à l’aide d’une URL sans devoir configurer de portefeuille ; vous pouvez même vous inscrire avec vos identifiants Google. Shopify a intégré Solana Pay pour permettre aux clients de régler leurs achats en USDC sur Solana. Visa a choisi d’intégrer Solana afin de régler des transactions en USDC pour les acquéreurs internationaux Worldpay et Nuvei. Code a utilisé des nonces durables pour créer un environnement d’exécution pseudo-asynchrone et développer un système de notification de paiement extrêmement rapide ainsi qu’une expérience utilisateur fluide. Même si certains qualifient ce système de L2, il ne dispose d’aucune preuve de fraude et vise uniquement à améliorer l’expérience de l’utilisateur final.

Solana n’a pas de L2 parce que les transactions y sont déjà très peu coûteuses et que, dans un bloc donné, l’état est nativement séparé et tarifé. Dès sa conception, Solana a été optimisée pour synchroniser l’état aussi rapidement que le permettent les lois de la physique et rapprocher le coût d’une transaction de son coût opérationnel marginal. Sur Ethereum, les transactions sont beaucoup plus coûteuses, en partie à cause de l’EVM monothread. L’état ne peut être tarifé séparément que lorsqu’une autre instance de la machine virtuelle s’exécute, ce que font les L2. Solana et les autres blockchains dotées de VM parallèles permettent des marchés de frais locaux, où les frais varient selon les différentes parties de l’état en fonction du niveau de concurrence qu’elles suscitent. Un point chaud localisé dans l’état peut être géré sans aggraver la concurrence ni augmenter les frais sur l’ensemble de la blockchain. En pratique, cela signifie que le mint d’un NFT ou un airdrop n’a que peu d’effets externes sur votre application distincte. 

Contrairement aux L2, l’aboutissement de Solana n’est pas inscrit sur une feuille de route : il existe déjà aujourd’hui. Même si Solana est activement maintenue et améliorée au moyen de SIMDs, il s’agit d’un registre d’actifs fonctionnel et d’une neutralité crédible, qui ne nécessite aucune confiance supplémentaire envers des multisigs, un alignement ou de simples impressions.

Quelle est la meilleure solution pour vous ?

Cela dépend de ce que vous cherchez à optimiser. En règle générale, un développeur d’applications ou un dirigeant d’entreprise doit consacrer le moins de temps possible à la maintenance de l’infrastructure blockchain et le plus de temps possible à l’amélioration continue de son produit afin d’offrir la meilleure expérience utilisateur. La question est donc la suivante : quel investissement est nécessaire pour vous ?

Lorsque vous choisissez une chaîne, vous devez étudier attentivement les primitives qu’elle propose. Prenez par exemple des applications comme Drip, qui comptent plus de 60 millions de NFT mintés et 500 000 collectionneurs.

Vos priorités d’optimisation finiront par réduire votre choix de chaînes. À partir de la synthèse précédente des différentes L1 et L2, voici quelques dimensions à prendre en compte :

1. Utilisateurs on-chain
2. Utilisation on-chain (si vous optimisez une fonction on-chain particulière, comme le trading, vous devrez examiner les chaînes qui proposent de faibles frais, comme Solana, Sui ou Optimism. Vous devrez comprendre les compromis techniques et les limites liés à des temps de bloc plus courts, des blocs plus volumineux, etc.)
3. Temps d’exécution
4. Liquidité on-chain
5. Grands détenteurs et liquidité on-chain (par exemple, l’écosystème EVM tend à disposer de davantage de liquidités en raison de la précédente vague de lancements de jetons, mais la situation évolue rapidement)
6. Accès à des communautés on-chain précises (artistes, traders, etc.)
7. Disponibilité des subventions et du capital-risque (les écosystèmes plus récents disposent de davantage de subventions, mais de moins de capital-risque)
8. Complexité technique et charge de gestion (par exemple, Code n’a besoin que de 2 ingénieurs pour exploiter son application sur Solana, contre plus de 30 ingénieurs et chercheurs pour dydx)
9. Programmabilité et souveraineté des règles de la chaîne (par exemple, des règles de règlement des transactions propres à celle-ci)
10. Accès aux acteurs institutionnels (par exemple, Coinbase sur Base, ainsi que Visa et Shopify sur Solana)
11. Composabilité avec les autres applications de l’écosystème (par exemple, les applications DeFi et de paiement)

Le déploiement sur certaines architectures de rollup peut être pertinent pour les applications qui comprennent les propriétés mentionnées précédemment et savent les exploiter de manière unique. Pour la plupart des applications, Solana fournit les primitives nécessaires à leur réussite. Ses choix de conception uniques lui permettent d’être rapide, économique et performante, et elle fonctionne en production depuis de nombreuses années.

Conclusion

Comprendre l’écosystème blockchain et s’y orienter, en particulier lorsqu’il faut choisir entre des plateformes de Layer 1 (L1) et de Layer 2 (L2), exige une compréhension nuancée des compromis impliqués. Le choix entre une L1 et une L2 va au-delà d’une décision technique : c’est une stratégie commerciale déterminante qui influence la scalabilité, la sécurité et la viabilité globale d’un projet. La refactorisation de l’ensemble d’une base de code augmente également la dette technique et réduit vos chances de créer une application performante.

On ne saurait surestimer le rôle de l’expérience utilisateur dans l’adoption de la blockchain. À mesure que la technologie gagne en maturité, l’attention doit se porter davantage sur la création d’interfaces intuitives, fluides et conviviales, capables de combler le fossé entre une infrastructure blockchain complexe et l’utilisateur final. Même si chaque application bénéficie d’un degré de flexibilité différent, la plupart des développeurs devraient choisir une plateforme qui leur permet de consacrer un maximum de temps à la création du meilleur produit possible.

Merci à Akshay, 0xIchigo et Jon Charbonneau pour leur relecture et leurs commentaires.