Écrit par : Alana Levin; Compilé par : Luffy, Foresight News
Il y a deux ans, les développeurs d'applications étaient confrontés à un choix assez simple pour décider sur quelle chaîne déployer leur application : Ethereum, Solana, Cosmos ou une autre blockchain de couche 1. A cette époque, Rollup n'avait pas encore lancé le réseau principal, et peu de gens avaient entendu parler du terme "pile modulaire". Les différences entre les L1 (débit, frais, etc.) sont évidentes et relativement faciles à comprendre.
Les choses semblent très différentes aujourd'hui. Les développeurs d'applications sont confrontés à plus de choix : L1, Rollup à usage général (Optimistic et zk), infrastructure IBC, Rollup-as-a-service provider, AppChain, etc. Plus d'options amènent plus de questions : les équipes doivent-elles déployer des applications dans des rollups génériques ou créer des rollups spécifiques à une application ? S'ils optent pour le Rollup générique, lequel choisir ; s'ils optent pour l'itinéraire Rollup de l'application, quel SDK/Rollup-as-a-service utiliser, quelle couche de disponibilité des données choisir, EigenLayer peut-il aider, comment penser aux séquenceurs ; s'ils choisissent de prendre la route d'OP Stack, s'il peut occuper une place dans l'écosystème de la super chaîne d'Optimism.
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. Cet article se concentrera donc sur l'arbre de décision auquel les équipes d'application sont confrontées lorsqu'elles décident de lancer leur propre déploiement, quels types d'applications sont particulièrement adaptés à certains types d'infrastructure, et quand je pense que nous pouvons atteindre le point de basculement de l'adoption.
Cadre de haut niveau
Au cœur de la décision de déploiement de l'application se trouve en fait une question simple : si l'application était construite sur sa propre chaîne, les utilisateurs l'utiliseraient-ils toujours ? Le développement ultérieur est deux questions:
Les utilisateurs sont-ils plus susceptibles d'utiliser une application si elle se trouve sur sa propre chaîne ?
Si l'application est sur sa propre chaîne, les utilisateurs l'utiliseront-ils également ?
Les avantages des cumuls spécifiques à l'application sont un meilleur contrôle : la capacité d'abstraire les coûts du gaz, de limiter la congestion sur la chaîne causée par d'autres activités d'application, de mieux expérimenter la façon dont les jetons sont utilisés, d'explorer différentes structures économiques (par exemple, les remises sur le gaz), de construire environnement d'exécution, implémentez des contrôles d'accès (tels que le déploiement d'autorisations), etc.
Mais le prix de ce contrôle supplémentaire est une perte de connectivité à l'écosystème plus large. Les applications sur une chaîne universelle ont accès à la liquidité déjà sur cette chaîne (par exemple, pas besoin de ponts supplémentaires entre les chaînes), la composabilité avec d'autres applications et l'attention des utilisateurs sur la chaîne. Par rapport aux applications qui exécutent leurs propres chaînes, la construction sur la chaîne générale permet également d'économiser beaucoup de frais généraux d'ingénierie.
Un meilleur contrôle pourrait améliorer l'expérience utilisateur s'il était gratuit. 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 ce compromis entre contrôle et connectivité.
**Combien de connectivité une application peut-elle sacrifier ? **
Les connexions se présentent sous plusieurs formes, les deux plus importantes étant : 1) l'attention et 2) le capital.
L'attention est liée à la communication native. Si le projet d'une équipe est le premier projet auquel les utilisateurs s'engagent lorsqu'ils entrent dans l'écosystème, l'application est nativement virale. Les applications qui peuvent attirer l'attention sont mieux adaptées au lancement de leur propre chaîne ; les utilisateurs utiliseront l'application, quelle que soit la chaîne sur laquelle l'application se trouve. À mon avis, les applications actuelles avec propagation native incluent Mirror, Zora, Manifold, Sound.xyz et OnCyber. Il existe également un argument selon lequel les applications sans forte diffusion peuvent choisir de lancer leurs propres chaînes afin de susciter l'intérêt des utilisateurs (mais je trouve cela moins convaincant si de nombreuses chaînes poursuivent cette voie en même temps).
La deuxième forme de connectivité est le capital. Souvent, les fonds que les utilisateurs déploient sur une application sont transférés d'une autre application dans le même écosystème. Je l'appelle "liquidité partagée" et ses implications sont réelles. Un grand nombre de nouvelles applications choisissent Universal Rollup en raison de la grande quantité d'ETH reliée à cet écosystème, et le capital existant au sein de l'écosystème peut aider à éliminer les obstacles à l'adoption par les utilisateurs (au lieu d'essayer de convaincre les utilisateurs d'entrer dans un nouvel écosystème). Ces facteurs sont des considérations pour toute application qui intègre une forme de financiarisation dans son produit. Les exemples en dehors de DeFi peuvent inclure : la collecte de documents 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 des fonds sur la chaîne. L'une des raisons pourrait être que les consommateurs utilisent beaucoup l'application, les chaînes croisées sont pénibles après tout, il serait donc plus facile de maintenir un approvisionnement sain en fonds sur la chaîne. Mais encore plus convaincant que les fonds inutilisés, il donne aux utilisateurs la possibilité de générer du rendement. Cela ressemble à un rendement sous la forme de natifs de la chaîne, d'applications créant des produits adjacents qui fournissent un rendement (comme le protocole de prêt de Blur), et plus encore.
L'attention et le capital sont également la raison pour laquelle beaucoup considèrent les jeux en chaîne comme des candidats idéaux pour les rollups spécifiques à l'application : ce sont des économies assez autonomes et reposent fortement sur une expérience utilisateur fluide. En d'autres termes, les jeux en chaîne bénéficient d'un degré élevé de contrôle et ne subissent pas de pertes importantes s'ils sont orphelins. D'autres applications bien adaptées à Rollup pourraient le faire en subventionnant les transactions (par exemple, les premières transactions sont gratuites) ou en n'exigeant aucun paiement lors de la connexion (par exemple, le contenu en chaîne généré par l'utilisateur, certaines applications sociales, les réseaux DePIN, etc.) Minimise les besoins initiaux en capital de l'utilisateur.
Bien sûr, il existe d'autres raisons pour lesquelles les projets veulent plus de contrôle sur leur infrastructure. Les cumuls propriétaires permettent de déployer des autorisations et de filtrer les utilisateurs (par exemple, KYC pour les séquenceurs détenus/exploités par une chaîne). Cependant, cela conduit également à brouiller la frontière entre les bases de données Rollup et les bases de données centralisées.
Minimiser la perte de connectivité
À mesure que les solutions d'interopérabilité s'améliorent, le compromis entre connectivité et contrôle devient moins important. Les ponts et les séquenceurs sont souvent l'infrastructure critique dont il est 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, les ordonnateurs partagés le font en ingérant et en ordonnant des transactions à partir de plusieurs chaînes. Les ordonnanceurs partagés et les ponts sont nécessaires pour la composabilité atomique - l'ordonnanceur est garanti pour contenir plusieurs transactions (inter-chaînes) 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 se composent de deux parties : 1) le coût de publication des données vers L1 et 2) le coût que les utilisateurs paient pour la transaction. Regroupez les données d'appel de transaction par lots afin que le coût de la publication puisse être partagé entre les utilisateurs : plus il y a de transactions, plus le coût moyen par utilisateur est faible. Cela signifie également que les rollups moins actifs peuvent retarder la publication des transactions vers L1 jusqu'à ce qu'ils disposent d'un package de transactions suffisamment volumineux. La conséquence est des temps de finalisation plus lents et une mauvaise 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 les individus à longue traîne.
** Sommes-nous à un point d'inflexion ? **
L'idée des chaînes d'applications et des cumuls d'applications n'est pas nouvelle. Pendant longtemps, cependant, on a eu l'impression qu'il s'agissait d'un quartier résidentiel en développement : de nombreuses infrastructures étaient en construction, mais sans aucun habitant. Au cours des derniers mois, nous avons commencé à voir un afflux de premiers résidents. Lattice a construit OpCraft, un monde autonome en chaîne soutenu par son propre rollup ; Lit Protocol et Synapse ont annoncé leur propre Rollup (bien que les deux soient plus orientés vers l'infrastructure que les projets orientés vers les applications) ; Zora a lancé Zorachain. Des conversations récentes avec des équipes d'applications matures (en particulier celles qui envisagent des stratégies L2) ont commencé à explorer si les déploiements d'applications leur conviennent.
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 les rollups spécifiques aux applications : les réseaux sociaux et les jeux dépendent fortement de l'indexation, des problèmes de commande (en particulier dans le gameplay) et des fonctionnalités personnalisées (comme les transactions sans essence) pour la consommation récréative. Les produits sont très important. De nombreuses équipes d'applications sont en construction, en particulier les jeux, dont le développement et la publication peuvent prendre des années.
Mon autre point à retenir est que pour les applications moins financières, le plus important est d'attirer l'attention. Jusqu'à présent, cet article a défini les rollups d'application comme "une application par rollup". Mais cette vision est peut-être trop étroite. Peut-être y a-t-il plusieurs applications formant un collectif pour démarrer une chaîne ensemble. De même, nous pouvons voir une application construire sa propre chaîne et encourager d'autres applications à se déployer par-dessus.
Enfin, je crois fermement que nous verrons plus de Rollups à l'avenir. Les projets de création de services d'infrastructure pour les déploiements d'applications vont proliférer. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. fournissent aux équipes d'application des solutions à bas seuil pour démarrer leur propre Rollup. Espresso, Astria et SUAVE de Flashbots ont été parmi les premiers explorateurs dans le domaine des séquenceurs. Les coûts de démarrage ont tendance à baisser et le compromis « connectivité » devient moins important. Mais un si grand nombre de nouveaux fournisseurs d'infrastructure signifie également que les équipes d'application peuvent mettre du temps à comprendre les différentes options, et une guerre éclatera entre ces acteurs. Encore une fois, bien qu'il y ait des signes d'adoption, je pense que le point d'inflexion est encore dans quelques mois.
Merci à Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer et Viktor Bunin pour leurs retours, commentaires et conversations qui ont aidé à développer bon nombre de ces idées.
Voir l'original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Sous la tendance de la modularisation, l'application doit-elle construire sa propre chaîne ?
Écrit par : Alana Levin; Compilé par : Luffy, Foresight News
Il y a deux ans, les développeurs d'applications étaient confrontés à un choix assez simple pour décider sur quelle chaîne déployer leur application : Ethereum, Solana, Cosmos ou une autre blockchain de couche 1. A cette époque, Rollup n'avait pas encore lancé le réseau principal, et peu de gens avaient entendu parler du terme "pile modulaire". Les différences entre les L1 (débit, frais, etc.) sont évidentes et relativement faciles à comprendre.
Les choses semblent très différentes aujourd'hui. Les développeurs d'applications sont confrontés à plus de choix : L1, Rollup à usage général (Optimistic et zk), infrastructure IBC, Rollup-as-a-service provider, AppChain, etc. Plus d'options amènent plus de questions : les équipes doivent-elles déployer des applications dans des rollups génériques ou créer des rollups spécifiques à une application ? S'ils optent pour le Rollup générique, lequel choisir ; s'ils optent pour l'itinéraire Rollup de l'application, quel SDK/Rollup-as-a-service utiliser, quelle couche de disponibilité des données choisir, EigenLayer peut-il aider, comment penser aux séquenceurs ; s'ils choisissent de prendre la route d'OP Stack, s'il peut occuper une place dans l'écosystème de la super chaîne d'Optimism.
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. Cet article se concentrera donc sur l'arbre de décision auquel les équipes d'application sont confrontées lorsqu'elles décident de lancer leur propre déploiement, quels types d'applications sont particulièrement adaptés à certains types d'infrastructure, et quand je pense que nous pouvons atteindre le point de basculement de l'adoption.
Cadre de haut niveau
Au cœur de la décision de déploiement de l'application se trouve en fait une question simple : si l'application était construite sur sa propre chaîne, les utilisateurs l'utiliseraient-ils toujours ? Le développement ultérieur est deux questions:
Les avantages des cumuls spécifiques à l'application sont un meilleur contrôle : la capacité d'abstraire les coûts du gaz, de limiter la congestion sur la chaîne causée par d'autres activités d'application, de mieux expérimenter la façon dont les jetons sont utilisés, d'explorer différentes structures économiques (par exemple, les remises sur le gaz), de construire environnement d'exécution, implémentez des contrôles d'accès (tels que le déploiement d'autorisations), etc.
Mais le prix de ce contrôle supplémentaire est une perte de connectivité à l'écosystème plus large. Les applications sur une chaîne universelle ont accès à la liquidité déjà sur cette chaîne (par exemple, pas besoin de ponts supplémentaires entre les chaînes), la composabilité avec d'autres applications et l'attention des utilisateurs sur la chaîne. Par rapport aux applications qui exécutent leurs propres chaînes, la construction sur la chaîne générale permet également d'économiser beaucoup de frais généraux d'ingénierie.
Un meilleur contrôle pourrait améliorer l'expérience utilisateur s'il était gratuit. 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 ce compromis entre contrôle et connectivité.
**Combien de connectivité une application peut-elle sacrifier ? **
Les connexions se présentent sous plusieurs formes, les deux plus importantes étant : 1) l'attention et 2) le capital.
L'attention est liée à la communication native. Si le projet d'une équipe est le premier projet auquel les utilisateurs s'engagent lorsqu'ils entrent dans l'écosystème, l'application est nativement virale. Les applications qui peuvent attirer l'attention sont mieux adaptées au lancement de leur propre chaîne ; les utilisateurs utiliseront l'application, quelle que soit la chaîne sur laquelle l'application se trouve. À mon avis, les applications actuelles avec propagation native incluent Mirror, Zora, Manifold, Sound.xyz et OnCyber. Il existe également un argument selon lequel les applications sans forte diffusion peuvent choisir de lancer leurs propres chaînes afin de susciter l'intérêt des utilisateurs (mais je trouve cela moins convaincant si de nombreuses chaînes poursuivent cette voie en même temps).
La deuxième forme de connectivité est le capital. Souvent, les fonds que les utilisateurs déploient sur une application sont transférés d'une autre application dans le même écosystème. Je l'appelle "liquidité partagée" et ses implications sont réelles. Un grand nombre de nouvelles applications choisissent Universal Rollup en raison de la grande quantité d'ETH reliée à cet écosystème, et le capital existant au sein de l'écosystème peut aider à éliminer les obstacles à l'adoption par les utilisateurs (au lieu d'essayer de convaincre les utilisateurs d'entrer dans un nouvel écosystème). Ces facteurs sont des considérations pour toute application qui intègre une forme de financiarisation dans son produit. Les exemples en dehors de DeFi peuvent inclure : la collecte de documents 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 des fonds sur la chaîne. L'une des raisons pourrait être que les consommateurs utilisent beaucoup l'application, les chaînes croisées sont pénibles après tout, il serait donc plus facile de maintenir un approvisionnement sain en fonds sur la chaîne. Mais encore plus convaincant que les fonds inutilisés, il donne aux utilisateurs la possibilité de générer du rendement. Cela ressemble à un rendement sous la forme de natifs de la chaîne, d'applications créant des produits adjacents qui fournissent un rendement (comme le protocole de prêt de Blur), et plus encore.
L'attention et le capital sont également la raison pour laquelle beaucoup considèrent les jeux en chaîne comme des candidats idéaux pour les rollups spécifiques à l'application : ce sont des économies assez autonomes et reposent fortement sur une expérience utilisateur fluide. En d'autres termes, les jeux en chaîne bénéficient d'un degré élevé de contrôle et ne subissent pas de pertes importantes s'ils sont orphelins. D'autres applications bien adaptées à Rollup pourraient le faire en subventionnant les transactions (par exemple, les premières transactions sont gratuites) ou en n'exigeant aucun paiement lors de la connexion (par exemple, le contenu en chaîne généré par l'utilisateur, certaines applications sociales, les réseaux DePIN, etc.) Minimise les besoins initiaux en capital de l'utilisateur.
Bien sûr, il existe d'autres raisons pour lesquelles les projets veulent plus de contrôle sur leur infrastructure. Les cumuls propriétaires permettent de déployer des autorisations et de filtrer les utilisateurs (par exemple, KYC pour les séquenceurs détenus/exploités par une chaîne). Cependant, cela conduit également à brouiller la frontière entre les bases de données Rollup et les bases de données centralisées.
Minimiser la perte de connectivité
À mesure que les solutions d'interopérabilité s'améliorent, le compromis entre connectivité et contrôle devient moins important. Les ponts et les séquenceurs sont souvent l'infrastructure critique dont il est 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, les ordonnateurs partagés le font en ingérant et en ordonnant des transactions à partir de plusieurs chaînes. Les ordonnanceurs partagés et les ponts sont nécessaires pour la composabilité atomique - l'ordonnanceur est garanti pour contenir plusieurs transactions (inter-chaînes) 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 se composent de deux parties : 1) le coût de publication des données vers L1 et 2) le coût que les utilisateurs paient pour la transaction. Regroupez les données d'appel de transaction par lots afin que le coût de la publication puisse être partagé entre les utilisateurs : plus il y a de transactions, plus le coût moyen par utilisateur est faible. Cela signifie également que les rollups moins actifs peuvent retarder la publication des transactions vers L1 jusqu'à ce qu'ils disposent d'un package de transactions suffisamment volumineux. La conséquence est des temps de finalisation plus lents et une mauvaise 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 les individus à longue traîne.
** Sommes-nous à un point d'inflexion ? **
L'idée des chaînes d'applications et des cumuls d'applications n'est pas nouvelle. Pendant longtemps, cependant, on a eu l'impression qu'il s'agissait d'un quartier résidentiel en développement : de nombreuses infrastructures étaient en construction, mais sans aucun habitant. Au cours des derniers mois, nous avons commencé à voir un afflux de premiers résidents. Lattice a construit OpCraft, un monde autonome en chaîne soutenu par son propre rollup ; Lit Protocol et Synapse ont annoncé leur propre Rollup (bien que les deux soient plus orientés vers l'infrastructure que les projets orientés vers les applications) ; Zora a lancé Zorachain. Des conversations récentes avec des équipes d'applications matures (en particulier celles qui envisagent des stratégies L2) ont commencé à explorer si les déploiements d'applications leur conviennent.
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 les rollups spécifiques aux applications : les réseaux sociaux et les jeux dépendent fortement de l'indexation, des problèmes de commande (en particulier dans le gameplay) et des fonctionnalités personnalisées (comme les transactions sans essence) pour la consommation récréative. Les produits sont très important. De nombreuses équipes d'applications sont en construction, en particulier les jeux, dont le développement et la publication peuvent prendre des années.
Mon autre point à retenir est que pour les applications moins financières, le plus important est d'attirer l'attention. Jusqu'à présent, cet article a défini les rollups d'application comme "une application par rollup". Mais cette vision est peut-être trop étroite. Peut-être y a-t-il plusieurs applications formant un collectif pour démarrer une chaîne ensemble. De même, nous pouvons voir une application construire sa propre chaîne et encourager d'autres applications à se déployer par-dessus.
Enfin, je crois fermement que nous verrons plus de Rollups à l'avenir. Les projets de création de services d'infrastructure pour les déploiements d'applications vont proliférer. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. fournissent aux équipes d'application des solutions à bas seuil pour démarrer leur propre Rollup. Espresso, Astria et SUAVE de Flashbots ont été parmi les premiers explorateurs dans le domaine des séquenceurs. Les coûts de démarrage ont tendance à baisser et le compromis « connectivité » devient moins important. Mais un si grand nombre de nouveaux fournisseurs d'infrastructure signifie également que les équipes d'application peuvent mettre du temps à comprendre les différentes options, et une guerre éclatera entre ces acteurs. Encore une fois, bien qu'il y ait des signes d'adoption, je pense que le point d'inflexion est encore dans quelques mois.
Merci à Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer et Viktor Bunin pour leurs retours, commentaires et conversations qui ont aidé à développer bon nombre de ces idées.