Portail de déploiement Polkadot : pourquoi les projets choisissent-ils de se déployer sur Polkadot plutôt que de devenir un L2 ?

Par le passé, déployer un Rollup sur Polkadot n’a jamais été une tâche aisée. En effet, plus un système est flexible, plus le processus de déploiement devient complexe : de la mise à jour du SDK, à la vente aux enchères de slots, en passant par la gouvernance et la mise à jour du runtime, chaque étape peut représenter un défi pour les équipes.

Pour changer cette situation, Parity a lancé cette année le Polkadot Deployment Portal (PDP) — un « guichet unique » allant de la construction, au déploiement, jusqu’à l’intégration. Son objectif est clair : abaisser les barrières, simplifier les processus et permettre à toute équipe de lancer et d’exploiter rapidement et de manière stable son propre Rollup sur Polkadot.

Dans cet article, Santi Balaguer, responsable du développement produit chez Parity, nous propose de revenir sur l’évolution de l’expérience de déploiement sur Polkadot ces dernières années, d’analyser la philosophie de conception derrière le PDP, et de partager comment cet outil transforme progressivement la façon de lancer un Rollup.

Expérience de déploiement sur Polkadot : plus le système est flexible, plus il est complexe

Jay : Bienvenue chez Space Monkeys, aujourd’hui nous recevons Santi Balaguer, responsable du développement produit chez Parity. Nous allons parler du PDP, dont le nom complet est ?

Santi : C’est le Polkadot Deployment Portal — le portail de déploiement Polkadot.

Jay : Avant de travailler sur le PDP, sur quoi as-tu principalement travaillé ces quatre ou cinq dernières années chez Parity ?

Santi : J’ai toujours été en contact étroit avec la communauté des développeurs, principalement pour les aider à lancer des parachains et des Rollups sur Polkadot. Comme tu l’as dit, j’étais déjà chez Parity avant même que les parachains ne soient en ligne.

Jay : Parmi les projets avec lesquels tu as souvent été en contact, lesquels nous sont les plus familiers ?

Santi : J’étais responsable du projet Substrate Builders, qui regroupe de nombreux projets connus. Celui qui m’a le plus marqué, c’est l’équipe Hydration. Je me souviens encore de Jakub lors de sa présentation, expliquant leur idée d’Omnipool et les problèmes que Hydration voulait résoudre. Il avait utilisé un célèbre meme « money printer goes brrrr » pour illustrer pourquoi ils proposaient une nouvelle solution. Je plaisante encore souvent avec Jakub à ce sujet.

Jay : Haha, génial. Tu as sûrement vu beaucoup de projets réussir sur Polkadot, mais aussi entendu parler de leurs difficultés. Peux-tu nous parler des aspects les plus pénibles du déploiement de projets sur Polkadot ces dernières années ?

Santi : Bien sûr. Polkadot est un système très complexe, il faut vraiment le comprendre pour que le projet fonctionne correctement. Cette complexité vient en fait de sa flexibilité — plus un système est flexible, plus il est complexe.

Au début, pour faire tourner un parachain sur Polkadot, il fallait d’abord gérer toutes sortes de « mises à jour disruptives » du SDK. À l’époque, il n’y avait pas encore de Polkadot SDK, seulement Substrate, ce qui était différent d’aujourd’hui. Une fois l’environnement de développement prêt, il fallait mobiliser la communauté pour participer à la vente aux enchères de slots. Cette vente était elle-même un défi : il fallait suffisamment de soutien, et le résultat n’était connu qu’à la dernière minute. Même en cas de victoire, il fallait attendre trois mois avant que le parachain ne soit réellement en ligne. De plus, le slot n’était loué que pour deux ans. À l’époque, il fallait donc se donner à fond à la fois sur le développement technique et la mobilisation communautaire pour se faire une place sur Polkadot.

Jay : Oui. Mais ces dernières années, l’expérience s’est beaucoup améliorée. Peux-tu nous parler de cette évolution ?

Santi : Bien sûr. Je pense que Parity a fait beaucoup d’efforts, notamment pour réduire les mises à jour disruptives du Polkadot SDK.

Il y a encore des mises à jour aujourd’hui, mais c’est bien plus stable qu’avant, et la compatibilité entre versions s’est nettement améliorée. Les développeurs peuvent désormais compter sur la version du SDK qu’ils utilisent. Certains parachains fonctionnent même encore avec d’anciennes versions de Substrate, tout en restant opérationnels sur Polkadot.

Il y a aussi l’introduction de Coretime (même si cela ajoute une certaine complexité), qui a vraiment abaissé la barrière pour les développeurs. Cela facilite l’expérimentation et réduit considérablement les obstacles à l’entrée sur Polkadot. Je pense qu’il faut exploiter au maximum cet avantage.

Pourquoi choisir de déployer sur Polkadot aujourd’hui, plutôt que de faire un L2 sur Ethereum ?

Jay : Même si beaucoup de défis ont été résolus, pourquoi aujourd’hui un projet choisirait-il de se déployer sur Polkadot ? Pourquoi ne pas aller sur Ethereum en L2, ou lancer directement son propre L1 ? Quelles en sont les raisons ?

Santi : C’est une question très intéressante. D’abord, je pense que, en tant que communauté, nous devrions mieux communiquer et promouvoir ces aspects. Selon ma compréhension et mon point de vue, Polkadot est actuellement la seule blockchain conçue dès le départ pour supporter nativement les Rollups. Elle offre aux développeurs des infrastructures que l’on ne trouve pas ailleurs.

• Par exemple, Polkadot fournit une couche de disponibilité des données (data availability) très importante pour les Rollups, alors que sur Ethereum L2, il faut s’appuyer sur des systèmes externes ou des « blobs » pour résoudre ce problème.

• Autre exemple, la messagerie native entre parachains (communication inter-chaînes), qui n’existe pas sur les autres Rollups. L’absence de cette fonctionnalité réduit la sécurité du système.

• En termes de performance, Spamming a déjà démontré que le niveau de TPS des Rollups sur Polkadot est parmi les meilleurs du secteur.

• Enfin, pour la scalabilité flexible, Polkadot est actuellement le seul système capable d’étendre ou de réduire son infrastructure à la demande. Par exemple, si Mythical veut lancer un nouveau jeu et s’attend à une explosion du nombre d’utilisateurs la première semaine, ils peuvent supporter ce trafic sans quasiment rien changer.

Je pense que dans nos discussions passées sur « parachains et Rollups », nous n’avons pas réussi à mettre Polkadot au centre, ce qui est une occasion manquée. Mais il est encore temps de le remettre sur le devant de la scène.

Jay : Oui, tu m’as déjà dit que Polkadot, dès sa conception, était pensé pour les Rollups, même si à l’époque on ne les appelait pas ainsi.

Santi : Exactement, et il y a un autre point souvent négligé : la sécurité partagée. Si l’on regarde l’histoire de la blockchain : d’abord Bitcoin, puis Ethereum. Ensuite, de nombreuses nouvelles « Ethereum » sont apparues, vantant des caractéristiques A, B, C. Mais garantir la sécurité d’une nouvelle chaîne est très difficile. Il faut un ensemble de validateurs suffisamment grand et solide, ce qui n’est pas facile.

À l’époque, Gavin s’est dit : pourquoi ne pas proposer la sécurité comme un service, intégré à la couche de base ? C’est ce qui fait l’originalité de Polkadot. Il offre non seulement la sécurité partagée, mais aussi une communication efficace entre ces Rollups, ce dont Polkadot est particulièrement capable.

Comment est née l’idée du PDP ?

Jay : Super. Si un Rollup veut une disponibilité des données native (et à grande échelle), sans devoir assembler des solutions externes, tout en ayant un fort TPS et une communication fluide avec d’autres Rollups, alors Polkadot est effectivement très attractif. Mais avant le PDP, déployer un parachain restait très complexe et chronophage. D’où est venue l’idée de créer le PDP ?

Santi : En fait, cette idée mûrissait depuis un certain temps, même si nous avons vraiment commencé à travailler dessus en novembre dernier.

Notre équipe s’est consacrée à plein temps au projet à partir de mars ou avril de cette année, et les progrès sont rapides, nous concrétisons peu à peu cette idée. Ce projet était dans l’air depuis longtemps, et il existe déjà des solutions similaires dans l’industrie. Par exemple, dans l’écosystème Ethereum, il y a Conduit, Gelato ; côté Polkadot, il y avait aussi Tanssi, mais ils se sont ensuite concentrés sur Ethereum, avec une approche similaire.

Constatant que rien ne se concrétisait côté Polkadot, nous avons décidé de nous lancer nous-mêmes, pour garantir la réussite du projet. Après tout, nous comprenons mieux Polkadot et savons comment le rendre plus accessible aux développeurs pour déployer leurs projets, c’est l’objectif du PDP.

Nous ne décidons pas pour les développeurs, nous leur offrons des conseils et des choix

Jay : À qui s’adresse vraiment le PDP ? Je me souviens qu’au début de Polkadot, certains projets voulaient tout de suite faire un Rollup, alors qu’un simple smart contract aurait suffi. Selon toi, quel type de projet a vraiment besoin de son propre Rollup ?

Santi : C’est une bonne question, mais je pense qu’il n’y a pas de réponse unique. On trouve encore aujourd’hui des projets pour lesquels un contrat pourrait suffire. Mais parfois, les équipes veulent de l’indépendance, ne pas dépendre de l’infrastructure d’une autre chaîne ; parfois, elles anticipent un très grand volume de transactions, et préfèrent donc opter pour un Rollup dès le départ, ou souhaitent plus d’indépendance sur l’infrastructure.

Par exemple, l’Omnipool d’Hydration : on pourrait débattre de la possibilité d’en faire un contrat, mais je pense que c’est pertinent d’en faire une chaîne. À l’inverse, regardons Uniswap sur Ethereum : c’était d’abord un contrat, puis ils ont créé leur propre chaîne, mais en ont-ils vraiment besoin ? Peut-être pas, mais ils ont leurs propres considérations commerciales.

Il n’y a donc pas de règle absolue, c’est le résultat d’un compromis entre technique et business. Pour moi, l’essentiel est : nous ne devons pas décider à la place des développeurs, mais leur offrir des conseils pour qu’ils choisissent eux-mêmes. Qu’ils veuillent faire un Rollup ou un contrat, ils doivent pouvoir expérimenter facilement.

Découverte de l’expérience PDP : de la construction, au déploiement, à l’accès, lancer un Rollup devient simple

Jay : D’accord, supposons qu’une équipe a pris sa décision, que ce soit par elle-même ou guidée par Magenta Labs ou l’équipe BD. Elle décide finalement de déployer un Rollup sur Polkadot. Quelle sera son expérience sur le PDP ? Quel est le processus de déploiement aujourd’hui ?

Santi : Dans la conception du PDP, nous avons divisé le processus en trois grandes étapes : Build (construction) — Deploy (déploiement) — Access (accès), ces trois parties étant interconnectées.

À l’étape « construction », la question centrale est « par où commencer ». Notre idée est que la meilleure façon est d’utiliser des modèles de runtime (runtime templates). Actuellement, OpenZeppelin développe des modèles, tout comme les équipes Pop CLI et ROG. Pop CLI est essentiellement un outil que vous pouvez utiliser sur votre ordinateur pour écrire un Rollup. Nous collaborons avec eux pour intégrer Pop CLI avec les deux autres étapes du PDP (déploiement et accès).

Par exemple, une fois que vous avez construit un Rollup avec Pop CLI, vous pouvez le connecter directement au PDP pour le déployer, c’est ainsi que nous l’avons conçu et réalisé. Ainsi, les développeurs peuvent suivre tout le processus en mode CLI, comme sur Heroku ou Vercel dans le Web2, qui ont aussi leur propre CLI. Si vous préférez cette méthode, vous pouvez l’utiliser ; sinon, vous pouvez passer par l’interface graphique. Les deux options sont possibles.

Jay : Donc, en plus de construire avec des modèles, on peut aussi utiliser Pop CLI, puis déployer. Le PDP aide-t-il les développeurs à faire des choix, ou est-ce juste un outil à utiliser en autonomie ?

Santi : Les deux. Nous voulons que le PDP soit un outil en libre-service, mais si des problèmes majeurs surviennent, nous sommes là pour soutenir et aider. Bien sûr, si quelqu’un veut tout essayer seul, aucun problème haha.

Jay : Intéressant. Peux-tu donner quelques exemples concrets de modèles ? Lesquels préfères-tu ?

Santi : Par exemple, l’équipe ROG propose un modèle Pilot Revive prêt à l’emploi. OpenZeppelin propose le modèle Frontier, idéal pour lancer une chaîne avec des fonctionnalités EVM.

Jay : Cool, donc plusieurs options liées aux smart contracts.

Santi : Exactement. Il y a aussi des modèles sans smart contract. Par exemple, pour ceux qui veulent juste une chaîne de gestion d’actifs, notamment pour des projets liés aux actifs du monde réel (RWA), il existe aussi des modèles adaptés. Bref, il y aura beaucoup d’options au départ, que vous pourrez ensuite étendre.

Jay : Peut-on ajouter de nouveaux Pallets à un modèle selon ses besoins ?

Santi : Pas au début. L’idée est de démarrer avec un modèle, puis nous vous guidons étape par étape vers la mise à jour du runtime. Nous voulons ainsi aider les équipes à trouver progressivement leur product-market fit. Ce design est intéressant, c’est l’une de nos priorités actuelles. Nous utilisons un outil développé par l’équipe Puppet, qui compare le runtime à mettre à jour avec celui déjà déployé, et génère un rapport indiquant les changements, leur impact potentiel sur les développeurs, et les points d’attention.

Jay : Oui, j’ai vu que vous venez d’intégrer ça, c’est super.

Santi : Oui, c’est tout récent, cette semaine. Ainsi, vous obtenez un rapport de mise à jour du runtime, pour vérifier que ce que vous poussez correspond à vos attentes. Nous voulons aussi ajouter une fonctionnalité : simuler quelques blocs en arrière-plan pour tester le nouveau runtime. Si tout va bien, nous vous disons « prêt à être mis en ligne » ; sinon, nous vous avertissons que le test a échoué et qu’il vaut mieux vérifier. Cela évite les erreurs lors des mises à jour. L’un des avantages de Polkadot est de permettre ces mises à jour flexibles du runtime, ce qui permet aux équipes d’itérer rapidement et de trouver leur product-market fit.

Jay : Attends, donc cette partie fait déjà partie de l’étape « déploiement » ? Ce dont on vient de parler, de la construction au runtime, c’est déjà du déploiement ?

Santi : Oui, il y a un certain chevauchement. On peut dire que la construction commence avec le modèle ; le déploiement concerne l’infrastructure sous-jacente. Avant, il fallait une équipe DevOps pour installer les nœuds collator et gérer l’exploitation, mais au début, ce n’est plus nécessaire. Si le projet se développe bien et que vous avez des ressources, vous pouvez constituer votre propre équipe d’exploitation, et nous vous aiderons à migrer. Mais au début, nous nous occupons de tout ça.

Jay : Qui s’en occupe actuellement ?

Santi : Pour l’instant, c’est Parity qui fournit ce service. Mais à l’avenir, les développeurs pourront choisir sur quelle plateforme cloud déployer, voire sur un IBP (Infrastructure Provider). Il faudra un peu de temps pour abstraire cette couche, donc pour garantir l’expérience, nous utilisons pour l’instant l’infrastructure de Parity, mais nous ouvrirons plus d’options à terme.

Nous avons aussi lancé le concept de BDU (Basic Deployment Unit, unité de déploiement de base) : dès que vous déployez un Rollup sur le réseau de production, nous mettons en place une infrastructure standardisée, comprenant trois nœuds collator, dont un sert de point de terminaison RPC, et nous vous fournissons aussi un indexer.

Nous collaborons actuellement avec Subscan, qui propose une solution open source que nous prévoyons d’intégrer au PDP. Ainsi, vous aurez non seulement un indexer, mais aussi un explorateur de blocs. Avant, il fallait beaucoup de temps aux équipes pour mettre tout cela en place, maintenant nous le faisons pour vous en un seul endroit, c’est un bon design.

Jay : Waouh, ça a l’air super. Cette partie fait-elle partie de la construction ?

Santi : C’est le déploiement.

Jay : Compris, donc à ce stade le Rollup fonctionne déjà ? Il commence à produire des blocs ? L’équipe peut aussi faire des mises à jour du runtime pour itérer et trouver son product-market fit ? Ensuite vient la dernière étape, « Access », c’est bien ça ? Qu’est-ce que c’est ?

Santi : Oui ! Access est le point fort de Polkadot, c’est là que Polkadot apporte une valeur unique aux équipes Rollup. La construction et le déploiement concernent le runtime et l’infrastructure, que tout le monde peut rapidement maîtriser, mais exploiter les spécificités de Polkadot fait la différence. Par exemple, Coretime fait partie d’Access, le PDP pré-achète du Coretime, de sorte que dès qu’un développeur veut déployer un Rollup, il peut l’utiliser immédiatement, sans attendre 28 jours pour commencer à produire des blocs, ce qui améliore énormément l’expérience utilisateur.

Jay : Si je veux déployer, dois-je acheter moi-même du Coretime sur le PDP ?

Santi : Nous l’achetons pour vous, puis nous vous facturons. En fait, nous proposons différentes options pour le Coretime. Si vous voulez y aller à fond dès le début, vous pouvez utiliser un cœur complet. Mais nous proposons aussi des « cœurs fractionnés », c’est-à-dire une partie d’un cœur. Si vous voulez tester à moindre coût, vous pouvez n’utiliser qu’une petite partie du cœur.

Jay : Cette fonctionnalité est-elle déjà disponible ?

Santi : Elle est déjà disponible sur le PDP. Elle fonctionne sur les réseaux Westend et Paseo. Paseo vient d’ajouter les cœurs fractionnés, et sur Westend, vous pouvez directement échanger une partie de cœur, ce qui allonge le temps de production de blocs, mais abaisse considérablement la barrière à l’entrée, permettant de tester à très faible coût. Si le résultat est concluant, vous pouvez passer à un cœur complet, profiter d’un temps de bloc de six secondes, et tout cela se fait sur le PDP. Cependant, le mécanisme d’intégration doit encore résoudre la question de l’utilisation efficace de Polkadot. Polkadot Hub, un module fonctionnel clé, sera bientôt lancé, et nous sommes très enthousiastes à ce sujet.