D'où viennent les effets de réseau L2 ? Qu'est-ce qui rend la L2 collante ?

Auteur : Alana Levin ; Compilateur : Huohuo, blockchain vernaculaire

Il y a deux ans, les développeurs d'applications étaient confrontés à un choix assez simple pour décider où déployer leurs applications : Ethereum, Solana, Cosmos ou peut-être une autre chaîne de couche 1. Le cumul n'est pas encore utilisé et peu de gens ont entendu le terme "pile modulaire". Les différences entre les L1 (débit, coût, etc.) sont évidentes et relativement faciles à appréhender.

** Les choses semblent très différentes aujourd'hui. Les développeurs d'applications sont confrontés à plus de choix : L1, rollups génériques (Optimistic et zk), infrastructure IBC avancée, fournisseurs de rollups en tant que service, chaînes d'applications, etc. **

Plus d'options amènent plus de questions, notamment : les équipes doivent-elles déployer des rollups génériques ou créer des rollups spécifiques à l'application ? Si vous optez pour le cumul général, lequel choisir ? S'ils optent pour le rollup d'application, quel SDK/rollup-as-a-service utiliser ? Quel niveau de disponibilité des données choisir ? EigenLayer peut-il aider ? Comment penser les séquenceurs ? S'ils choisissent d'emprunter la route OP Stack, y aura-t-il un emoji de sphère colorée dans l'écosystème de la superchaîne d'Optimism ? Ces questions sont délicates.

Pour affiner le problème, cet article adoptera le cadre d'une application déjà déployée sur Ethereum qui souhaite évoluer au sein de l'écosystème Ethereum. L'accent sera donc mis sur l'arbre de décision auquel les équipes d'application sont confrontées pour déterminer s'il convient de lancer leur propre déploiement, les hypothèses sur les types d'applications particulièrement adaptées à cette infrastructure et le moment où je pense que nous pourrions atteindre un point de basculement pour l'adoption.

1. Cadre de haut niveau

Au cœur d'une décision de rollup d'application se trouve en fait une question simple : **si l'application était sur sa propre chaîne, les utilisateurs l'utiliseraient-ils toujours ? **Il y a deux sous-ensembles de cette question :

1) Les utilisateurs sont-ils plus susceptibles d'utiliser une application si elle se trouve sur sa propre chaîne ?

2) Si l'application est sur sa propre chaîne, est-il également possible pour l'utilisateur d'utiliser l'application ?

** Les avantages du cumul spécifiques à l'application découlent d'un meilleur contrôle : ** Capacité à extraire les coûts du gaz, à limiter la congestion de la chaîne causée par d'autres activités d'application, à mieux expérimenter l'utilisation des jetons, à explorer différentes structures économiques (telles que les remises sur le gaz intégrées) , créer des environnements d'exécution personnalisés, implémenter des contrôles d'accès (tels que le déploiement d'autorisations), etc.

** Mais ce contrôle supplémentaire se fait au détriment de la connectivité à l'écosystème plus large. **Les applications d'une chaîne partagée/universelle ont déjà accès à la liquidité de cette chaîne (par exemple, sans ponts supplémentaires entre les chaînes), à la composabilité avec d'autres applications et aux utilisateurs déjà dédiés à cette chaîne. Construire sur une chaîne commune nécessite également moins de travail d'ingénierie interne/des frais généraux qu'une application exécutant sa propre chaîne.

De meilleurs contrôles pourraient améliorer l'expérience utilisateur s'ils étaient gratuits. Ainsi, la réponse à la question centrale - si les utilisateurs utiliseraient toujours une application si elle était sur sa propre chaîne - dépend vraiment de la gravité de ce compromis entre le contrôle et la connexion. **

2. Combien de connexions l'application peut-elle se permettre de perdre ?

Les connexions se présentent sous plusieurs formes. Les deux plus importants sont : 1) Attention, et 2) Capital.

** Notez la distribution native. Si le projet de l'équipe est la première chose avec laquelle les utilisateurs s'engagent lorsqu'ils entrent dans l'écosystème, il est impératif que l'application ait une distribution native. ** Les applications de contrôle de l'attention sont mieux adaptées pour démarrer leur propre chaîne ; les utilisateurs utiliseront cette application quelle que soit la chaîne sur laquelle elle existe. À mon avis, les exemples actuels d'applications qui ont une distribution native incluent Mirror, Zora, Manifold, Sound.xyz et OnCyber. Il existe également un argument selon lequel les applications sans une forte distribution peuvent choisir de lancer leurs propres chaînes pour susciter l'intérêt.

La deuxième composante de la "connectivité" est le capital. Souvent, les fonds déployés par les utilisateurs pour une application sont récupérés auprès d'une autre application du même écosystème. Je l'appelle "liquidité partagée" et ses implications sont réelles. Nous avons vu de nouvelles applications choisir un cumul à usage général plutôt qu'un autre en raison de la plus grande quantité d'ETH reliée à l'écosystème ; ** le capital existant au sein de l'écosystème peut aider à éliminer les obstacles à l'adoption par les utilisateurs (plutôt que d'essayer de convaincre les utilisateurs d'entrer dans un nouvel écosystème)**. Ces considérations sont pertinentes pour toute application qui intègre une forme de financiarisation dans son produit. Des exemples en dehors du DeFi pur peuvent inclure la collecte d'articles NFT via Mirror, le paiement pour "voler" des images sur une Stealcam, ou tout ce qui a une fonction de pourboire dans le produit.

**La perte de cette "connectivité de fonds" signifie que les applications doivent forcer les utilisateurs à garer leur inventaire sur la chaîne. ** L'une des raisons peut être que les consommateurs utilisent beaucoup l'application - l'expérience de transition est douloureuse, il sera donc plus facile de maintenir un approvisionnement sain de fonds sur la chaîne. Mais encore plus convaincant que l'inventaire inactif, il offre aux utilisateurs des options qui génèrent des revenus. Cela peut ressembler à une forme de rendement native de la chaîne, une application créant un produit adjacent qui fournit un rendement (comme le protocole de prêt de Blur), ou autre chose.

Les raisons ci-dessus (attention et capital) expliquent également pourquoi beaucoup considèrent les jeux en chaîne comme des candidats idéaux pour les cumuls spécifiques à l'application : ce sont des économies assez autonomes, contrôlent la part d'esprit des consommateurs et constituent une congestion triée et évitée. est une catégorie qui est à la fois importante pour une expérience utilisateur agréable.

En d'autres termes, les jeux en chaîne bénéficient d'un degré élevé de contrôle et ne sont pas significativement affectés s'ils sont isolés. D'autres applications bien adaptées au déploiement d'applications peuvent le faire en subventionnant les transactions (par exemple, les premières transactions sont gratuites) ou en n'exigeant aucun paiement au début (par exemple, le contenu en chaîne généré par l'utilisateur, certaines applications sociales, les réseaux DePIN, etc.) Minimiser les besoins en capital des utilisateurs initiaux.

Bien sûr, il existe d'autres raisons pour lesquelles les projets veulent plus de contrôle sur leur infrastructure. Le fait d'avoir un cumul introduit l'autorisation de déploiement ou la capacité de mettre en œuvre les exigences de filtrage des utilisateurs (telles que KYC sur les séquenceurs détenus/exploités par la chaîne). Dans ces cas, cependant, la frontière entre les bases de données cumulatives et les bases de données centralisées devient de moins en moins claire.

3. Minimiser la perte de connexion

À mesure que les solutions d'interopérabilité s'améliorent, le compromis entre connectivité et contrôle devient moins critique. ** Les ponts et les séquenceurs sont souvent l'infrastructure critique abordée dans cette question. Ils sont quelque peu similaires en ce sens qu'ils permettent tous deux aux transactions d'une chaîne d'affecter les transactions d'une autre chaîne. **Les ponts le font en transmettant des messages ou en permettant des transferts d'actifs. Un ordonnateur partagé le fait en ingérant et en ordonnant des transactions à partir de plusieurs chaînes, créant un mécanisme de coordination qui permet aux actions sur une chaîne d'affecter les actions sur une autre. La composabilité atomique nécessite des séquenceurs et des ponts partagés - le séquenceur est garanti pour contenir plusieurs transactions (interdomaines) dans un bloc, et l'exécution réelle de ces transactions nécessite généralement un pont.

L'économie unitaire des Rollups est un autre domaine où la "connectivité" a un impact. **Les frais de transaction L2 sont composés de deux facteurs : 1) le coût de publication des données vers L1 et 2) le coût que les utilisateurs paient pour l'inclusion. ** Les lots d'opérateurs de cumul appellent les données pour les transactions, ce qui permet de répartir les coûts de publication entre les utilisateurs - plus il y a de transactions, plus le coût moyen par utilisateur est faible. Cela signifie également que des cumuls moins actifs peuvent retarder la publication des transactions sur L1 jusqu'à ce qu'elles aient une taille de lot suffisamment importante. La conséquence est un temps de finalisation plus lent et une moins bonne expérience utilisateur. Les commandes partagées semblent servir de plus en plus de couches d'agrégation, où le regroupement des transactions à partir de plusieurs cumuls plus petits peut aider à créer une économie unitaire viable pour l'existence de la longue traîne.

4. Sommes-nous à un point d'inflexion ?

L'idée des chaînes d'applications et des cumuls d'applications n'est pas nouvelle. Cependant, pendant longtemps, ** cela ressemblait à un quartier résidentiel en développement : de nombreuses infrastructures étaient en construction, mais il n'y avait pas d'habitants **.

Mais ces derniers mois, nous avons commencé à voir les premiers afflux de résidents. Lattice a construit OpCraft, un monde autonome en chaîne soutenu par son propre rollup. Des projets comme Lit Protocol et Synapse ont annoncé leurs propres cumuls (bien que les deux soient davantage orientés vers l'infrastructure que vers les applications). Zora a lancé Zorachain. Des conversations récentes avec des équipes de couche d'application plus matures (en particulier celles qui envisagent des stratégies L2) ont commencé à explorer si le déploiement d'applications leur convient.

Mon hypothèse est que le véritable point d'inflexion arrivera dans (au moins) 6 à 12 mois. ** Les applications de jeu et sociales ont l'adéquation la plus évidente au marché des produits avec des cumuls spécifiques à l'application : les réseaux sociaux et les jeux dépendent fortement de l'indexation (et bénéficient grandement du fait qu'ils n'ont pas à rivaliser avec l'état partagé), des problèmes de commande (en particulier dans le gameplay) et les fonctionnalités personnalisées (comme les transactions sans gaz) sont particulièrement utiles pour les produits de consommation axés sur le divertissement**. Beaucoup de ces équipes d'application sont encore en construction. Les jeux, en particulier, peuvent prendre des années à se développer et à sortir.

Mon autre point à retenir est que l'attention est le facteur le plus critique pour les applications moins financières. Jusqu'à présent, cet article a défini les cumuls d'applications comme "une application par cumul". Mais cette vision est peut-être trop étroite. Peut-être que plusieurs applications décident de former un collectif, de mettre en commun leur "attention" et de démarrer une chaîne ensemble. De même, nous pourrions voir une application majeure décider de construire sa propre chaîne et encourager d'autres applications à se déployer dessus - en fait, en utilisant sa propre application pour tester l'adoption de l'infrastructure qu'elle veut contrôler.

Enfin, je crois fermement que nous verrons plus de rollups à l'avenir. Il y a eu une prolifération de projets créant des services d'infrastructure pour les déploiements d'applications. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. fournissent des solutions à faible portance permettant aux équipes de démarrer leur propre Rollup.

Espresso, Astria et SUAVE de Flashbots sont quelques-uns des premiers entrants dans l'espace des séquenceurs. Les coûts d'installation ont tendance à baisser et le compromis "connectivité" devient moins sévère. Les deux renforcent les arguments en faveur de l'adoption. **Mais un si grand nombre de nouveaux fournisseurs d'infrastructure signifie également que les équipes d'application peuvent prendre le temps de comprendre les différentes options et de mettre ces différents acteurs à l'épreuve avant de choisir un gagnant. ** Encore une fois, bien qu'il y ait des signes d'adoption, je pense que le point d'inflexion est encore dans quelques mois.