Construire un Rollup dédié à l'application : trouver l'équilibre entre connectivité et contrôle
TechFlow SélectionTechFlow Sélection
Construire un Rollup dédié à l'application : trouver l'équilibre entre connectivité et contrôle
Les Rollup spécifiques à l'application sont-ils vraiment la tendance de demain ?
Dédié à des analyses Web3 approfondiesRédaction : Alana Levin
Traduction : TechFlow
Introduction
Dans le monde de la blockchain, les développeurs d'applications décentralisées (dApp) sont confrontés à une décision cruciale : sur quelle chaîne déployer leur application.
Avec l'évolution technologique, ils disposent désormais de davantage d'options, voire celle de construire leur propre Rollup spécifique à l'application. Cet article explore en profondeur ce processus décisionnel, notamment les facteurs à prendre en compte lorsqu'on hésite à déployer un Rollup dédié à son application.
Cette décision repose sur un arbitrage fondamental : connectivité contre contrôle.
Le premier terme fait référence au nombre d'utilisateurs et d'écosystèmes auxquels votre application peut se connecter, tandis que le second concerne le niveau de maîtrise que vous avez sur des éléments clés comme le jeton de votre application, les frais de gaz ou encore l'environnement d'exécution.
Comment alors les développeurs peuvent-ils trouver un équilibre entre ces deux aspects ? Le modèle du Rollup spécifique à une application est-il vraiment la tendance de demain ? Examinons cela à travers cet article.
Il y a deux ans, le choix pour les développeurs d'applications était relativement simple : Ethereum, Solana, Cosmos, ou peut-être quelques autres blockchains de couche 1. Les Rollups n'étaient pas encore opérationnels, et très peu de personnes connaissaient l'expression « pile technologique modulaire ». Les différences entre les L2 (débit, frais, etc.) étaient nettes et faciles à comprendre.
Aujourd'hui, la situation est radicalement différente. Les développeurs font face à un éventail bien plus large d'options : blockchains de couche 1, Rollups généraux (Optimistic ou zk), infrastructures IBC avancées, fournisseurs de services « Rollup as a Service », chaînes dédiées aux applications, etc. Ce foisonnement d'options engendre également davantage de questions : faut-il déployer sur un Rollup général ou construire un Rollup spécifique à l’application ? Si c’est un Rollup général, lequel choisir ? En cas de choix d’un Rollup applicatif, quel SDK ou service utiliser ? Quelle couche de disponibilité des données privilégier ? EigenLayer apporte-t-il un avantage ? Comment gérer le séquenceur ? Tout cela devient vite accablant.
Pour circonscrire le sujet, cet article prendra pour exemple des applications déjà déployées sur Ethereum, et s'intéressera principalement à l'arborescence décisionnelle qu'un projet doit suivre pour déterminer s'il doit lancer son propre Rollup, à mon hypothèse concernant les types d’applications particulièrement adaptées à cette infrastructure, ainsi qu’à mon estimation du moment où nous atteindrons un seuil critique d'adoption.
Cadre général
La question centrale lorsqu’on envisage de déployer sa propre chaîne applicative est en réalité très simple : les utilisateurs continueront-ils à utiliser l’application si elle se trouve sur sa propre chaîne ?
-
Les utilisateurs seront-ils plus enclins à utiliser l’application si elle est sur sa propre chaîne ?
-
Les utilisateurs auront-ils la même probabilité de l’utiliser, qu’elle soit sur une autre chaîne ou sur la sienne propre ?
Les avantages d’un Rollup spécifique à une application proviennent d’un meilleur contrôle : abstraction des coûts de gaz, réduction de la congestion causée par d'autres applications, expérimentation facilitée autour de l'utilisation du jeton, exploration de structures économiques différentes (par exemple remises en gaz pour intégrations), création d’environnements d’exécution personnalisés, mise en œuvre de contrôles d’accès (déploiements autorisés, etc.).
Cependant, cette plus grande autonomie s’accompagne d’une perte de connectivité avec l’écosystème global. Une application déployée sur une chaîne partagée bénéficie de la liquidité existante (pas besoin de passer par des ponts supplémentaires), de la composable avec d'autres applications, et attire l’attention des utilisateurs déjà présents sur cette chaîne. Construire sur une chaîne générale requiert aussi moins de travail interne et de ressources techniques comparé au déploiement d'une chaîne autonome.
Sans coût excessif, un meilleur contrôle pourrait améliorer l’expérience utilisateur. Ainsi, la réponse à la question initiale — les utilisateurs continueront-ils à utiliser l’application si elle est sur sa propre chaîne ? — dépend largement de la gravité de cet arbitrage entre contrôle et connectivité.
Quelle perte de connectivité une application peut-elle supporter ?
La connectivité revêt plusieurs formes, mais deux composantes dominent : l’attention et les capitaux.
L’attention est liée à la diffusion native. À mes yeux, les applications actuellement dotées d’une distribution naturelle incluent Mirror, Zora, Manifold, sound.xyz et OnCyber. Certains pensent aussi que des applications sans fort canal de distribution pourraient opter pour leur propre chaîne afin de susciter de l’intérêt (bien que je juge cette approche moins efficace si trop de chaînes adoptent la même stratégie).
Le deuxième pilier est financier. Généralement, les fonds déployés par les utilisateurs dans une application proviennent d’une autre application du même écosystème. Je parle alors de « liquidité partagée », dont l’impact est tangible. Nous avons vu des projets choisir un Rollup général plutôt qu’un autre simplement parce que davantage d’ETH avait été transféré vers cet écosystème via des ponts ; le capital existant facilite l’adoption (plutôt que de convaincre les utilisateurs de basculer vers un nouvel écosystème). Ces considérations sont pertinentes pour toute application intégrant une forme de financiarisation. Hors DeFi, on peut citer la collecte d’articles NFT sur Mirror, le paiement pour « voler » une image sur Stealcam, ou tout produit intégrant un système de pourboires.
Perdre cette « connexion financière » signifie que l’application devra attirer les utilisateurs autrement : meilleure expérience, rendements plus élevés (comme le protocole de prêt de Blur), ou autres incitations.
Ces deux raisons — attention et capital — expliquent pourquoi beaucoup considèrent que les jeux sur chaîne sont des candidats idéaux pour les Rollups spécifiques : il s’agit d’économies relativement autonomes capables de contrôler les comportements des consommateurs sans subir de perturbations majeures. D’autres applications compatibles avec les Rollups applicatifs peuvent réduire le besoin initial de capital en subventionnant les transactions (par exemple, premières transactions gratuites) ou en ne demandant aucun paiement à l’inscription (contenus générés par les utilisateurs, certaines applis sociales). Lorsque ces Rollups introduisent des déploiements autorisés ou exigent des filtres utilisateurs (KYC sur le séquenceur contrôlé par la chaîne), la frontière entre Rollup et base de données centralisée devient floue.
En fin de compte, la perte de connectivité qu’une application peut supporter dépend fortement de ses caractéristiques propres et des besoins de ses utilisateurs cibles. Pour certaines, perdre une partie de cette connectivité est acceptable, car elles peuvent compenser par d’autres leviers. Pour d’autres, en revanche, la connectivité est vitale, car elles reposent sur les interactions avec d'autres applications et utilisateurs. Il est donc essentiel, avant de choisir un Rollup dédié, d’évaluer soigneusement cet arbitrage.
Réduire la perte de connectivité
Grâce aux progrès des solutions d’interopérabilité, l’arbitrage entre connectivité et contrôle devient moins contraignant. À cet égard, les ponts inter-chaînes et les séquenceurs partagés sont des infrastructures clés. Les ponts permettent le transfert de messages ou d’actifs. Les séquenceurs partagés ordonnancent les transactions provenant de plusieurs chaînes, créant ainsi un mécanisme de coordination qui permet à une action sur une chaîne d’affecter une autre. Ces deux composants sont nécessaires à la composable atomique : le séquenceur garantit l’inclusion de plusieurs transactions (transdomaines) dans un même bloc, tandis que l’exécution effective repose souvent sur un pont inter-chaînes.
Un autre domaine où la « connectivité » joue un rôle crucial est celui de l’économie unitaire des Rollups. Les frais de transaction sur L2 résultent de deux éléments : 1) le coût de publication des données sur la L1, et 2) le paiement effectué par l’utilisateur pour inclusion. Les opérateurs de Rollup regroupent les données des transactions, ce qui permet de mutualiser les coûts de publication. Plus il y a de transactions, plus le coût moyen par utilisateur diminue. Cela implique aussi que les Rollups peu actifs peuvent retarder la publication vers la L1 jusqu’à atteindre un volume suffisant, ce qui ralentit la finalité et dégrade l’expérience utilisateur. Les séquenceurs partagés apparaissent de plus en plus comme des couches d’agrégation : en regroupant les transactions de plusieurs petits Rollups, ils rendent viables les économies unitaires pour la longue traîne.
Sommes-nous à un point de basculement ?
L'idée des chaînes applicatives et des app-Rollups n'est pas nouvelle. Pendant longtemps, cependant, cela ressemblait à un lotissement en construction : beaucoup d’infrastructures, mais aucun habitant. Mais ces derniers mois, nous assistons aux premières arrivées. Lattice a lancé OpCraft, un monde autonome sur chaîne soutenu par son propre Rollup. Des projets comme Lit Protocol et Synapse ont annoncé leurs propres Rollups (bien que davantage orientés infrastructure que produits finaux). Zora a lancé Zorachain.
Mon hypothèse est que le véritable point de basculement interviendra (au minimum) dans 6 à 12 mois. Les jeux et les applications sociales présentent la meilleure adéquation produit-marché avec les Rollups spécifiques : les deux dépendent fortement de l’indexation (et bénéficient énormément de ne pas concurrencer un état partagé), l’ordonnancement est crucial dans les jeux, et des fonctionnalités personnalisées (comme les transactions sans gaz) sont particulièrement utiles pour des produits grand public orientés divertissement. Beaucoup de ces équipes sont encore en phase de développement. Surtout, les jeux peuvent prendre plusieurs années avant d’être complètement conçus et lancés.
Une autre conviction que je défends est que, pour les applications non financiarisées, l’attention des utilisateurs est le facteur le plus critique. Jusqu’ici, j’ai défini l’app-Rollup comme « un Rollup par application ». Mais cette vision est peut-être trop restrictive. Peut-être plusieurs applications décideront-elles de former un collectif, de mutualiser leur « attention » et de lancer ensemble une chaîne. De même, nous pourrions voir une application phare créer sa propre chaîne et inciter d’autres applications à s’y déployer, utilisant ainsi son influence pour promouvoir une infrastructure qu’elle souhaite contrôler.
Enfin, je suis fermement convaincue que nous verrons émerger davantage de Rollups. Un grand nombre de projets proposent déjà des services d’infrastructure pour les app-Rollups. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer offrent des solutions peu coûteuses pour lancer rapidement son propre Rollup. Espresso, Astria et SUAVE de Flashbots sont des pionniers dans le domaine des séquenceurs. Les coûts d’installation baissent, et l’arbitrage « connectivité vs contrôle » s’atténue. Ces deux tendances renforcent l’intérêt pour ces solutions. Toutefois, le grand nombre de nouveaux fournisseurs signifie aussi que les équipes prendront probablement le temps d’étudier chaque option et de tester ces différents acteurs en conditions réelles avant de choisir un vainqueur. Par conséquent, je le répète : bien que les signes indiquent une adoption croissante, je pense que le point de basculement est encore à plusieurs mois de distance.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Variant
