Introduction

Ce court billet décrit les compromis concrets entre les deux :

• L1s vs. L2s
• Rollups vs. intégrés
• Spécifique à une application ou à un usage général

Nous devons mieux comprendre quelles architectures construire et à quel moment. Sinon, nous continuerons à avoir un mélange d'infrastructures confuses qu'aucun utilisateur ne pourra comprendre ou avec lesquelles il ne pourra pas interagir. C'est l'erreur la plus fréquente que je constate :

Comme l'indique le billet d'introduction d'Eclipse avant le lancement prochain de son réseau principal :

Une fausse dichotomie est souvent présentée entre la vision d'un rollup modulaire et la capacité d'avoir une chaîne unique avec une échelle massive, une exécution parallélisée et un état partagé. Le terme "modulaire" est souvent confondu avec "spécifique à une application", ce qui pourrait vous amener à penser que les rollups sont synonymes d'un monde de nombreuses chaînes fragmentées et à faible débit. Nous remettons en cause cette idée.

Les rollups et les L2 ne sont pas un mauvais UX. La fragmentation des rollups et des L2 est une mauvaise expérience utilisateur. Des rollups et L2 bien conçus devraient améliorer l'UX.

Rollups vs. intégrés

Toutes les chaînes peuvent éventuellement adopter la meilleure technologie (par exemple, DAS + ZK) si elle s'avère utile. Comme je l'ai indiqué dans mon dernier rapport, les rollups héritent-ils de la sécurité ? la distinction qui s'impose alors est à peu près la suivante :

• Les "rollups" alias. "Modulaire" - Construisez des chaînes logiquement séparées qui envoient des données à leur chaîne hôte (couche DA). Ils réutilisent le consensus de la chaîne hôte.
• "Intégré", alias "Monolithique" - Tout intégrer dans un seul protocole avec son propre consensus. Ne publiez pas de données dans une chaîne hôte distincte. (Même si la couche DA et la couche d'exécution sont en quelque sorte des éléments logiquement distincts du protocole commun).

Solana et Eclipse représentent les voies parallèles, comme le montre la thèse Solana de Syncracy :

Comme je l'ai expliqué dans mon récent épisode de Uncommon Core avec Hasu, les deux approches auront une valeur à long terme.

M. Solana adopte l'approche consistant à tout regrouper dans un seul consensus. Il vise une latence minimale(les temps de latence sont actuellement de l'ordre de 400 à 500 ms et l'on espère atteindre 200 ms à l'avenir) tout en conservant un grand nombre de validateurs(environ 2 000). Cette incroyable réalisation a nécessité plusieurs percées techniques.

Cependant, ces deux objectifs (décentralisation maximale + latence minimale) sont intrinsèquement en tension. Il est extrêmement difficile de maintenir cet ensemble de consensus stable tout en fonctionnant à la vitesse et au débit maximum. TowerBFT n'a pas d'analyse formelle de sécurité ou de pérennité, et il n'est pas certain que la preuve de l'historique soit actuellement utile et résiliente dans un modèle contradictoire ou qu'elle puisse être simplement supprimée. Les aspects économiques d'un système à faible latence incitent bien sûr davantage à la centralisation.

Eclipse adopte l'approche du dégroupage du consensus. Les rollups peuvent disposer d'un ensemble de séquenceurs plus restreint et trié sur le volet (potentiellement même géré par un seul opérateur) afin d'opérer dans un environnement contrôlé. Cela permet d'accroître la fiabilité et de réduire encore davantage la latence, en offrant un produit Web2 avec les avantages des rails cryptographiques. Code, une application de paiement déployée comme une sorte de L2 sur Solana utilisant des nonces durables, est similaire dans son désir de paiements instantanés et fiables. Au-delà de l'aspect pratique d'une latence quasi instantanée, il est également nécessaire de repousser la limite inférieure pour les applications financières à forte valeur ajoutée et à faible latence.

Les rollups peuvent ensuite envoyer leurs données à un autre ensemble de consensus décentralisé pour une vérification plus solide à une échelle de temps plus lente. Par exemple, Celestia a des temps de blocage de 15s avec une finalité à un seul slot, ce qui n'est en fait pas si différent de Solana ! Solana a des confirmations de ~400ms, et la finalité est atteinte après 32 slots (~12.8s).

Il n'y a pas de repas gratuit ici. Il existe un compromis potentiel sur les propriétés de l'ensemble des validateurs en temps réel (par exemple, Solana a beaucoup plus de validateurs que les rollups n'ont de séquenceurs) par rapport aux garanties fournies (par exemple, un environnement résilient contrôlé, une latence encore plus faible, etc.) Le niveau adéquat d'engagement (et l'échelle de temps) est une question de spectre. Des questions techniques restent en suspens, et la meilleure solution variera probablement en fonction du cas d'utilisation. Il va sans dire que le coût est également essentiel ici, de sorte que des couches DA évolutives telles que Celestia (qu'Eclipse utilise) seront nécessaires.

Eclipse ne remplacera évidemment pas Solana. Chacun d'entre eux fait des compromis différents et vise un marché différent. Solana reste le cœur et l'âme du développement du SVM, et il est probable que de nombreuses nouvelles applications y seront déployées. Cependant, il est clair qu'il y aura plus d'une chaîne de SVM à long terme (Pyth l'est déjà). L'avenir n'est pas à la chaîne unique, et le SVM est une technologie tout simplement extraordinaire. Eclipse est à l'origine de cette tendance à l'exporter vers L2, mais je m'attends à ce que d'autres réalisent la valeur de la chose et suivent leur exemple.

L1 vs. L2

J'utilise L1 et L2 dans le sens le plus courant du terme pour inclure les rollups, les validiums, etc. Comme indiqué dans l'article de Vitalik intitulé Different types of layer 2s (Différents types de couches 2):

Les ponts de validation bidirectionnels sont presque suffisants pour faire d'une chaîne un validium. Le principal ingrédient restant est un engagement social selon lequel si quelque chose d'exceptionnel se produit dans Ethereum et que le pont ne fonctionne plus, l'autre chaîne procédera à un hard-fork en réponse.

Ce qui différencie une L1 d'une L2, c'est effectivement la manière dont elle traite les fourches. Un validium reviendrait si sa L1 revenait sur un bloc, et il serait "hard-forké" si sa couche de base était "hard-forkée". Pour valoriser la L2, une forme de gouvernance de la L2 doit exister sur la L1 sous la forme d'un contrat-passerelle lisible par la L1.

Pourquoi utiliser une telle chose ? Est-il logique qu'une chaîne délègue son choix de fourche à une L1 sous-jacente et s'enracine autour de son pont ?

Malgré l'idée répandue que la guerre des L1 est terminée, qu' Ethereum a gagné et que tous les concurrents d'Ethereum veulent maintenant devenir des L2, les L2 d'Ethereum ne sont pas la meilleure solution pour toutes les chaînes.

Les L2 d'Ethereum sont souvent considérées comme le moyen le plus sûr et le plus évolutif de construire une chaîne. Cependant, ces propriétés de sécurité sont souvent très mal comprises, comme je l'ai expliqué dans mon dernier rapport. Le simple fait de publier une preuve sur Ethereum et d'y déléguer votre règle de choix de fourche ne rend pas magiquement votre chaîne super sécurisée.

L'argument selon lequel toutes les chaînes doivent se déployer en tant qu'Ethereum L2 pour leur propre sécurité est le plus souvent erroné. Le principal avantage des L2 a plutôt été la possibilité d'exploiter les effets de réseau d'Ethereum (utilisateurs, liquidités, développeurs, outils, etc.). Il s'agit d'une stratégie de mise sur le marché.

Se battre pour attirer l'attention est logique étant donné que l'attention est la seule ressource rare dans le secteur des cryptomonnaies. Les L2 ont naturellement l'occasion d'être en première ligne avec les développeurs, les utilisateurs, les médias, etc. qui comptent le plus. Autrefois, il suffisait d'être titulaire d'une L2 pour attirer l'attention.

Cependant, l'attention portée à la L2 est en train de s'estomper. La liste des L2 d'Ethereum en cours et à venir est désormais bien trop longue pour qu'un individu puisse la suivre. Les chaînes qui se tournent vers les L2 ne bénéficient pas de l'attention qu'ont reçue les premières (par exemple, Optimism et Arbitrum). Même les zkEVM tant attendus peinent à attirer les utilisateurs, les applications et la valeur.

Ainsi, le fait d'être une L2 ne suffit plus à garantir l'attention de tous. Cependant, elle peut encore offrir un avantage par rapport aux chaînes autonomes si vous pouvez attirer l'attention d'une autre manière. Par exemple, la transformation d'un système pyramidal en un carré peut attirer ~700 millions de dollars dans un multisig sans L2. Vous pouvez également construire le premier SVM L2 d'Ethereum.

En supposant que vous ayez un produit qui retient l'attention, voyons maintenant comment le fait d'être une L2 peut aider une chaîne à exploiter la base d'utilisateurs d'Ethereum et à offrir une meilleure expérience produit. Elle le ferait principalement en exploitant les actifs natifs de l'Ethereum (par exemple, l'ETH) d'une manière favorable (par exemple, des ponts avec une sécurité et/ou une expérience utilisateur attrayante).

La valeur de cette mesure dépend en grande partie de deux hypothèses fondamentales :

1. les actifs Ethereum existants sont importants pour le cas d'utilisation donné (par exemple, DeFi dépend de l'ETH)

Si votre application dépend fortement des actifs de l'écosystème Ethereum, une architecture L2 peut s'avérer utile. Si vous ne vous intéressez pas du tout aux actifs Ethereum, le fait d'être un Ethereum L2 n'a pas beaucoup d'intérêt. Les actifs basés sur l'Ethereum sont clairement les plus importants dans le domaine de la cryptographie aujourd'hui, il y a donc un grand marché à servir aujourd'hui.

Si l'on se projette dans l'avenir au niveau de l'industrie, la question centrale est de savoir quel sera le nouvel état précieux créé par les crypto-monnaies à l'avenir.

• Si cet état futur est de moins en moins lié à l'état actuel natif d'Ethereum (par exemple, nouvel état unique, RWA, etc.), l'attrait des L2 pourrait diminuer.
• Si cet état futur dépend fortement de l'état actuel de l'Ethereum (par exemple, le commerce de l'ETH), alors les L2 peuvent jouer un rôle important.

Le premier scénario part du principe que nous n'avons vu qu'une goutte d'eau dans l'océan de ce que seront les crypto-monnaies et qu'il ne faut pas surindexer ce qui existe aujourd'hui. Ce dernier scénario part du principe que le développement et les applications des crypto-monnaies seront incroyablement dépendants du chemin parcouru, de sorte que l'état actuel influencera le résultat.

Les deux sont vrais dans une certaine mesure, mais je pense que toute vision optimiste des perspectives à long terme de l'industrie penche en faveur de la première. Il y aura beaucoup d'états nouveaux et uniques que nous ne pouvons même pas imaginer et qui ne seront pas liés à l'état actuel. L'état actuel de la cryptographie est une goutte d'eau dans l'océan comparé à l'état futur attendu.

Par exemple, les "assurances de règlement" d'Ethereum couramment citées ne signifient pas grand-chose pour les actifs du monde réel (RWA) tels que les stablecoins (par exemple, USDC) ou les bons du Trésor tokenisés. Ils sont "réglés" lorsque l'émetteur (par exemple, Circle) les considère comme tels.

Dans ce scénario, l'attrait d'être un Ethereum L2 pourrait diminuer en tant que part des applications. Une nouvelle application de paiement basée sur l'USDC ne se soucie pas intrinsèquement de savoir s'il s'agit d'une Ethereum L2 ou non. Ils veulent simplement l'infrastructure la moins chère, la plus rapide et la plus fiable qui leur permette d'offrir aux utilisateurs la meilleure expérience produit.

La création de nouveaux États a toujours été un obstacle pour Solana, mais nous voyons clairement le vent tourner. De nombreux projets DeFi et d'infrastructure bien connus sur Solana lancent maintenant des jetons, et d'autres sont à venir. Il s'agit de la mise en route du volant d'inertie Solana.

2.que les ponts Ethereum ←→ L2 sont préférables aux ponts Ethereum ←→ L1 (par exemple, pour des raisons de sécurité et/ou d'UX).

Supposons que la première hypothèse soit effectivement satisfaite pour un cas d'utilisation donné (c'est-à-dire que les applications Ethereum-natives sont très utiles pour votre application). Nous devons alors nous demander si une L2 peut exposer ces actifs de manière plus favorable qu'une L1 séparée. Supposons qu'un utilisateur possède de l'ETH et qu'il souhaite l'échanger contre de l'USDC. Où vont-ils ?

Bien que la sécurité des ponts soit souvent citée comme motivation, cet argument semble peu convaincant sur la base des informations disponibles. Bon nombre des plus grands ponts roulants n'ont même pas d'épreuves, ont des épreuves sur liste blanche, des mises à niveau contrôlées par multisig, ou n'ont littéralement pas de L2.

Il s'agit d'un rapprochement classique entre le consensus et le vérificateur (par exemple, IBC). Dans la pratique, il n'y a pas eu de défaillance majeure du quorum des validateurs dans de tels scénarios. Les défaillances des ponts sont généralement dues à des piratages et/ou à des multisigs de pont compromis (auxquels les L2 sont également sensibles).

Si les améliorations en matière de sécurité me semblent moins convaincantes, l'accès pratique aux utilisateurs et aux actifs d'Ethereum est, à mon avis, un avantage majeur de la passerelle L2 aujourd'hui. Les rollups tels que Base, Optimism et Arbitrum ressemblent davantage à des extensions d'Ethereum. Les utilisateurs conservent les mêmes portefeuilles et adresses, le jeton de gaz natif est une version canonique unique de l'ETH, l'ETH domine DeFi comme toutes les paires d'échange, les applications sociales fixent le prix des NFT en ETH et rémunèrent les créateurs en ETH (par exemple, friend.tech), les dépôts dans la L2 sont instantanés (parce qu'ils se réorganiseraient ensemble), etc.

On ne peut attendre des utilisateurs qu'ils réfléchissent au pont à utiliser, qu'ils analysent les différentes hypothèses de sécurité, qu'ils obtiennent l'un des nombreux jetons enveloppés disponibles, qu'ils acquièrent le jeton natif de la chaîne pour le gaz, etc. Ils veulent simplement faire le pont avec leur ETH, obtenir l'ETH de l'autre côté et continuer à utiliser la L2 comme ils le feraient avec l'Ethereum ou n'importe quelle autre L2. C'est pourquoi Eclipse utilisera simplement l'ETH comme jeton natif utilisé pour le gaz. L'introduction forcée d'un nouveau jeton de gaz est préjudiciable à l'interface utilisateur.

Pourquoi Solana n'offre-t-il pas les mêmes avantages qu'Ethereum L2 ? En fait, il s'agit plus d'une question d'ingénierie que de quelque chose de fondamental, et cela deviendra de plus en plus facile avec le temps. Ceci est vrai pour les jetons de gaz ainsi que pour d'autres défis UX liés à la simple non-utilisation de l'EVM (qui n'est pas inhérente à L1 vs. L2) :

• Jeton de gaz - Les paiements de gaz peuvent être dissociés des utilisateurs, ce qui permet à ces derniers de payer avec le jeton de gaz de leur choix.
• Rapprochement - Le rapprochement est susceptible de se renforcer et de se normaliser davantage au fil du temps, ce qui réduira la confusion des utilisateurs et la fragmentation des liquidités.
• Portefeuilles - Les Snaps récemment dévoilés par MetaMask étendent la prise en charge de MetaMask aux chaînes non-EVM par le biais d'intégrations tierces construites au-dessus, telles que les Snaps MetaMask de Drift ou de Solflare.
• Expérience des développeurs - Les barrières linguistiques s'estompent. Des projets comme Solang et Neon peuvent aider les développeurs Solidity à s'appuyer sur Solana, et des projets comme Stylus peuvent aider les développeurs Rust à s'appuyer sur Arbitrum.

À l'avenir, il serait même possible que l'ETH joue un rôle dans Solana DeFi si les utilisateurs exprimaient une forte préférence pour l'ETH avec la vitesse et l'échelle de Solana. En pratique, il est beaucoup plus probable que ces utilisateurs disposant d'actifs natifs d'Ethereum continueront à les utiliser au sein de l'écosystème Ethereum L2 pour les raisons que nous avons évoquées, en supposant qu'ils aient accès à des L2 à l'évolutivité comparable.

Spécifique à une application ou polyvalent

Qu'il s'agisse d'une chaîne L1 ou L2, il est clairement nécessaire d'augmenter le débit d'une chaîne unique en échelonnant l'exécution. Les rollups ne doivent pas impliquer de fragmentation. L'unification de nombreuses chaînes homogènes sous un séquenceur partagé avec état finit par ressembler à une chaîne parallélisée du point de vue de la mise à l'échelle, avec une interface utilisateur plus difficile.

Nous voyons souvent des "blocs dédiés" cités comme raison de déployer un rollup spécifique à une application. Toutefois, cette idée fausse est due en grande partie aux limitations inutiles de l'EVM à fil unique avec les marchés de redevances globaux. Un SVM parallélisé avec des marchés locaux de redevances réduit considérablement le besoin de chaînes d'applications. L'hébergement d'un plus grand nombre d'applications sur une infrastructure partagée réduit considérablement la complexité pour les développeurs et les utilisateurs. La complexité de l'UX et des développeurs dans un monde à chaînes multiples est un risque existentiel sous-estimé.

Cela ne veut pas dire qu'il n'y aura littéralement qu'une seule chaîne à la fin de la journée. Je vois en gros quatre arguments pour déployer votre propre chaîne :

1. Évolutivité & Espace réservé - Comme nous l'avons mentionné plus haut, cet argument n'est généralement pas convaincant. Un hôtel de la Monnaie ne devrait pas fermer le reste de la chaîne, mais la solution n'est généralement pas de créer une autre chaîne. Ce problème est atténué par une VM parallélisée avec des marchés locaux de redevances. Toutefois, dans la mesure où la bande passante de l'ensemble du réseau est saturée, les marchés locaux de redevances ne seront d'aucun secours (c'est-à-dire que les redevances pour la chaîne partagée augmenteront au niveau mondial). Vous avez alors besoin d'une autre chaîne.
2. Souveraineté - La gouvernance des cryptomonnaies est encore assez faible, et le fait d'avoir sa propre chaîne à forker peut être un mécanisme de coordination utile. J'ai l'intuition qu'il s'agit d'une circonstance très rare, mais il est difficile de l'affirmer avec certitude. Cela va dans le sens de l'intérêt de MakerDAO pour une chaîne d'applications.
3. Personnalisation - Les personnalisations au niveau du consensus peuvent être utiles pour certaines applications (par exemple, dYdX v4), mais ces cas sont empiriquement peu nombreux à ce jour. Même dYdX, l'exemple parfait d'une chaîne d'applications, "évoluera probablement davantage vers une exécution généralisée sur la chaîne dYdX", selon Antonio dans son récent épisode de Bell Curve. Le besoin d'une personnalisation complète de la chaîne, qui ne peut être résolu par une chaîne partagée, a généralement fait défaut à la plupart des crypto-monnaies. Presque tous les nouveaux rollups continuent d'être des fourches EVM vanille avec de nouveaux jetons.
4. Capture de la valeur - Il s'agit sans doute d'un sous-ensemble de la personnalisation, mais il est assez important pour que nous le séparions. Il peut être plus difficile d'internaliser la valeur d'une infrastructure partagée qui n'est pas conçue uniquement pour votre application. Les chaînes d'applications peuvent faciliter l'attribution de la valeur aux applications responsables. Cependant, il s'agit d'un effort d'ingénierie plus que d'un effort fondamental, et des recherches sont en cours à Solana sur la manière d'y parvenir. En outre, notez qu'il y a des frais généraux importants dans le déploiement de votre propre chaîne par rapport à l'amortissement des coûts dans une infrastructure partagée.

Aujourd'hui, la principale motivation pour lancer une chaîne d'applications est souvent la perception d'une amélioration narrative et/ou d'une utilité symbolique pour un projet en difficulté. La baisse du marché et le manque de croissance des applications qui en a résulté ont encouragé le développement et le financement d'une architecture trop compliquée, ce qui a donné lieu à de nouveaux projets nécessaires pour résoudre les complexités qu'ils s'étaient eux-mêmes infligées.

Lancer sa propre chaîne aujourd'hui implique des compromis douloureux et inutiles (complexité, coût, moins bonne ergonomie, liquidité fragmentée, etc.) que la plupart des applications ne peuvent pas justifier par rapport aux avantages supplémentaires. L'infrastructure nécessaire pour rendre cette UX compétitive semble lointaine. Cela ne veut pas dire qu'il n'y a aucune raison pour que les chaînes d'applications existent un jour (il y en a certainement). Au contraire, nous avons massivement surinvesti dans cette direction sur le plan narratif en tant qu'industrie, et la tendance actuelle au regroupement est donc clairement bénéfique dans l'état actuel des choses.

Conclusion

M. Solana a, à juste titre, bénéficié d'un grand élan au cours des derniers mois. Cette correction brutale est en grande partie due à la reconnaissance de l'état actuel de l'interface utilisateur multichaîne : elle est fragmentée et douloureuse. L'interface utilisateur des applications Solana est tout simplement incroyable. Souple et rapide.

Les rollups et les L2 ont mauvaise réputation en matière d'UX, mais le vrai problème est la fragmentation. Nous associons les rollups et les L2 à une mise à l'échelle horizontale fragmentée car, dans la pratique, la plupart d'entre eux ont forké l'EVM tel quel et utilisent une bande passante DA limitée. Ils finissent par être coûteux et difficiles à utiliser.

Mais ce n'est pas fondamental. La mise à l'échelle verticale avec une VM puissante sur une couche DA évolutive résout ces problèmes d'interface utilisateur et de coût. Il est probable qu'un certain niveau de regroupement de la pile pour les L1 et les L2 se produise. Les L2 et les rollups devraient améliorer l'UX s'ils sont utilisés correctement. Cela devrait être leur véritable argument de vente.

Les deux approches ont leurs mérites. Nous devons simplement faire un meilleur travail en nous demandant d'abord "à quel marché ce produit tente-t-il de répondre ?" et "comment cette architecture peut-elle répondre à mon besoin ?" avant de construire le prochain L1, L2, L3...

Clause de non-responsabilité：

1. Cet article est repris de[dba]. Tous les droits d'auteur appartiennent à l'auteur original[Jon Charbonneau]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.