Comment déployer un rollup personnalisé sur Caldera

Dernière mise à jour 2026-07-23 05:17:31
Temps de lecture: 6m
Le déploiement d’un rollup personnalisé sur Caldera permet de créer une app chain hébergée par Rollup Engine, avec le framework de votre choix et, en option, un Gas Token personnalisé. Sur Testnet, utilisez le Dashboard : connectez-vous → Commencer → sélectionnez le framework et Testnet → définissez le Gas Token, le nom, le sous-domaine et l’ID de chaîne → Déployez. Le lancement sur mainnet a généralement lieu après l’engagement sur le framework choisi et la chaîne de règlement (Arbitrum Nitro, Optimism Bedrock ou zkSync ZK Stack). Après la mise en production, il est possible de connecter Metalayer pour l’agrégation de bridge et Metatoken.

Déployer un rollup personnalisé sur Caldera crée un environnement d’exécution dédié, hébergé par le Rollup Engine de Caldera, avec framework configurable, identifiants et Gas Token natif inclus. Le Testnet est généralement accessible en libre-service sur le Dashboard, tandis que le Mainnet nécessite une brève phase d’engagement avant la mise en production par Caldera. La difficulté est de niveau intermédiaire : les équipes doivent gérer les compromis du stack et définir des Chain IDs uniques, sans avoir à déployer une flotte de nœuds de zéro. Pour plus de contexte produit, consultez Caldera (ERA) et Metalayer ; pour comparer les solutions RaaS, voir Caldera vs AltLayer et Conduit.

Le parcours est contrôlable de bout en bout : préparez le compte et les identifiants ; ouvrez Gérer les Rollups → Commencer ; choisissez Testnet ou Mainnet ; sélectionnez Nitro, Bedrock ou ZK Stack ; définissez Gas Token, Nom, Sous-domaine et Chain ID ; Déployez (ou finalisez le lancement Mainnet) ; connectez l’app RPC ; connectez éventuellement Metalayer pour la liquidité cross-chain.

Prérequis au déploiement

Rassemblez quatre éléments clés : accès, intention réseau, token/identifiants et plan de migration applicative.

Élément Exigence Importance
Compte Dashboard Connexion autorisée Accès au Testnet et gestion continue
Intention réseau Testnet en libre-service ou engagement Mainnet Différences d’approbation et de sécurité
Préférence framework Nitro / Bedrock / ZK Stack Définit le modèle de preuve et les outils associés
Gas Token ETH ou ERC-20 éligible Un Gas Token personnalisé requiert un contrat et des décimales
Identifiants Nom, Sous-domaine, Chain ID Difficiles à modifier après écriture ; uniques requis
Checklist app Contrats, RPC, oracles, bridges Pour intégration post-déploiement et tests de régression

Les tokens à offre élastique ne conviennent généralement pas comme Gas natif. Contrôlez l’absence de conflit de Chain ID avant le déploiement. Les ressources publiques évoquent souvent la rapidité des ports d’applications Ethereum, mais la gestion des dépendances et des oracles reste prédominante dans la planification.

Étape 1 : Ouvrir la console et choisir Testnet ou Mainnet

Connectez-vous, ouvrez Gérer les Rollups, puis Commencer pour accéder à Déployer un nouveau Rollup. Le type de réseau conditionne la suite du processus.

Testnet Mainnet
Accès Libre-service Dashboard Engagement / Démo, puis lancement
Objectif Valider stack, Gas, RPC, ports Règlement de production et opérations
Déployeur Votre équipe clique sur Déployer Caldera déploie la chaîne selon accord
Risques principaux Mauvaise configuration, collisions d’ID Bridges, clés d’upgrade, finalité

Un Testnet actif ne garantit pas la préparation au Mainnet. Un mauvais choix de réseau implique des reprises sans modifier le modèle de sécurité.

Étape 2 : Choisir un framework (Nitro, Bedrock ou ZK Stack)

Sélectionnez le framework sur la page Déployer avant de renseigner les identifiants. Le Rollup Engine de Caldera prend en charge :

  • Arbitrum Nitro et Optimism Bedrock (OP Stack) — Modèles optimistes ; les litiges s’appuient sur des fraud proofs.
  • zkSync ZK Stack — Preuves de validité sur les mises à jour d’état.

Si vous réutilisez les outils Arbitrum ou OP, Nitro ou Bedrock facilitent le portage. Pour une structure à preuves de validité, privilégiez ZK Stack. Une fois le choix arrêté, RPC, bridges natifs et runbooks s’ancrent autour de ce framework — finalisez les tests de régression Testnet avant tout changement.

Déploiement d’un rollup personnalisé sur Caldera en cinq étapes Figure 1. Parcours de déploiement : connexion → réseau → framework → Gas Token et identifiants → Déploiement et intégration applicative (Metalayer en option).

Étape 3 : Configurer Gas Token, Nom, Sous-domaine et Chain ID

Sur Déployer un nouveau Rollup, définissez le Gas Token natif et trois identifiants :

  1. Verrouillez le Gas Token (actif natif ou ERC-20 éligible) avec les décimales correctes.
  2. Assurez-vous que le Chain ID n’est pas déjà utilisé (wallets, bridges).
  3. Vérifiez le Nom et le Sous-domaine pour les espaces de noms console et RPC.

Des champs incorrects peuvent entraîner des réseaux wallet erronés, des mappings de bridges défectueux ou des incohérences Explorer. Déployez uniquement lorsque la configuration est stabilisée.

Étape 4 : Déployer et intégrer votre application

Testnet : Déployez un nouveau Rollup → attendez le statut prêt → copiez RPC, Chain ID et Explorer dans les wallets et CI. Redirigez contrats, interfaces, actif gas et oracles vers la nouvelle chaîne. Testez toutes les transactions et scénarios d’échec.

Mainnet : Après engagement, Caldera lance le rollup de production sur le framework et les paramètres convenus. Sécurisez séparément permissions, clés d’upgrade, monitoring, et testez les limites bridge ou Metalayer. “Chaîne en ligne” ≠ “ouverte au trafic”.

Étape 5 : Connecter Metalayer pour la liquidité cross-chain (optionnel)

Si des actifs doivent circuler entre chaînes Caldera ou autres réseaux compatibles, connectez Metalayer une fois l’application single-chain opérationnelle :

  • L’agrégation de bridges interroge les fournisseurs en parallèle et gère les routes.
  • Metatoken maintient des actifs à adresse identique et offre unifiée en hub-and-spoke.
  • Stack public : Exécution → Fournisseurs de bridge → Règlement (messagerie Hyperlane).

Utilisez SDK, widget ou API — inutile de développer une infrastructure bridge complète. Ouvrez les limites avec précaution et choisissez rapidité ou finalité complète en connaissance de cause. Un rollup déployé ne garantit pas la sécurité de tous les chemins bridge.

Connexion Metalayer après déploiement du rollup Caldera Figure 2. Connexion Metalayer post-déploiement entre Exécution, fournisseurs de bridge et Règlement.

Erreurs fréquentes et solutions

Erreur Cause Solution
Wallet ne parvient pas à joindre RPC Mauvais Sous-domaine/RPC ou réseau Copier le RPC officiel depuis le Dashboard
Mauvais actif gas dans les transactions Gas Token ≠ valeur par défaut du wallet Ajouter Chain ID ; vérifier le contrat Gas natif
Conflit Chain ID ID dupliqué ou inversé Choisir un Chain ID libre ; mettre à jour app et bridges
Déploiement Mainnet indisponible Mainnet non accessible en libre-service Engagement / Démo ; aligner framework et règlement
Retard ou échec cross-chain Limites Metalayer ou chemin non atteintes Vérifier route, limites, finalité ; tester de petits montants
Erreurs oracle après portage Feeds toujours sur l’ancienne chaîne Rediriger les oracles vers le nouveau Chain ID

Distinguez “chaîne non prête” de “client mal configuré” avant de modifier Gas Token ou les paramètres bridge.

Checklist sécurité après déploiement

Le déploiement suit des flux publics, mais les frontières de sécurité subsistent :

  • Rollup : hypothèses sur le séquenceur et DA, clés de mise à niveau, oracle Gas Token personnalisé ou risque d’offre.
  • Metalayer : modèles de confiance et de liquidité propres à chaque fournisseur ; arbitrages rapidité vs finalité complète.
  • Externe : faux dashboards, RPC usurpés, faux $ERA — vérifiez domaines et contrats.

Documentez framework Mainnet, chaîne de règlement, monitoring et gestion des incidents afin d’éviter toute confusion entre hébergement et externalisation sans responsabilité. Utilisez limites, listes d’autorisation et tests progressifs avant d’ouvrir le trafic cross-chain. Ces notes sont descriptives uniquement — il ne s’agit pas de conseils de lancement.

Résumé

Pour déployer un rollup sur Caldera, distinguez le parcours Testnet en libre-service (connexion → réseau → framework → Gas Token et IDs → déploiement → intégration) de l’engagement Mainnet, puis ajoutez Metalayer uniquement si la liquidité cross-chain est requise. Framework et identifiants, une fois définis, structurent wallets, outils et bridges. L’audit sécurité doit couvrir clés d’upgrade, confiance bridge et surfaces de phishing — et non se limiter à un badge “déployé”.

FAQ

Comment déployer un rollup sur Caldera ?

Testnet : Dashboard → Gérer les Rollups → Commencer → framework + Testnet → Gas Token, Nom, Sous-domaine, Chain ID → Déployer. Mainnet : engagement ou démo ; Caldera lance le rollup de production, puis vous intégrez l’application.

Quelle est la différence entre Testnet et Mainnet ?

Testnet est en libre-service pour valider stack et portage. Mainnet débute après engagement et couvre règlement de production et limites opérationnelles. Le succès sur Testnet ne garantit pas la préparation Mainnet.

Peut-on personnaliser le Gas Token sur Caldera ?

Oui — sous frameworks supportés, un ERC-20 standard peut être utilisé comme Gas natif ; les tokens à offre élastique sont généralement exclus. Vérifiez adresse, décimales et affichage wallet en amont.

Comment connecter Metalayer après déploiement ?

Après validation de l’application single-chain, utilisez le SDK, widget ou API Metalayer. L’agrégation gère le routage ; Metatoken gère l’offre unifiée multi-chaînes. Vérifiez limites, finalité et chemins fournisseurs avant la connexion.

Quels sont les principaux risques de déploiement ?

Clés d’upgrade, hypothèses séquenceur/DA, surfaces Gas Token personnalisées, modèles de confiance bridge divergents et consoles ou RPC usurpés. Vérifiez domaines, contrats et chemins avant d’ouvrir au trafic.

Quels frameworks Caldera prend-il en charge ?

Les parcours publics proposent généralement Arbitrum Nitro, Optimism Bedrock et zkSync ZK Stack. Validez les compromis Optimistic vs ZK sur Testnet avant de verrouiller le Mainnet.

Auteur : Jayne
Clause de non-responsabilité
* Les informations ne sont pas destinées à être et ne constituent pas des conseils financiers ou toute autre recommandation de toute sorte offerte ou approuvée par Gate.
* Cet article ne peut être reproduit, transmis ou copié sans faire référence à Gate. Toute contravention constitue une violation de la loi sur le droit d'auteur et peut faire l'objet d'une action en justice.

Articles Connexes

Quelles sont les différences fondamentales entre Solana (SOL) et Ethereum ? Analyse comparative des architectures de blockchain publique
Intermédiaire

Quelles sont les différences fondamentales entre Solana (SOL) et Ethereum ? Analyse comparative des architectures de blockchain publique

Cet article examine les distinctions majeures entre Solana (SOL) et Ethereum, notamment en ce qui concerne l’architecture, les mécanismes de consensus, les options de scalabilité et la structure des nœuds, et propose un cadre structuré et réutilisable pour comparer les blockchains publiques.
2026-03-24 11:58:38
Comment Midnight assure-t-il la confidentialité sur la blockchain ? Analyse des preuves à divulgation nulle de connaissance et des mécanismes de confidentialité programmables
Débutant

Comment Midnight assure-t-il la confidentialité sur la blockchain ? Analyse des preuves à divulgation nulle de connaissance et des mécanismes de confidentialité programmables

Midnight, conçu par Input Output Global, est un réseau blockchain centré sur la confidentialité et joue un rôle clé dans l'écosystème Cardano. Grâce à l'utilisation de preuves à divulgation nulle de connaissance, d'une architecture de registre à double état et de fonctionnalités de confidentialité programmables, Midnight permet aux applications blockchain de préserver les données sensibles tout en maintenant la vérifiabilité.
2026-03-24 13:49:11
Morpho vs Aave : analyse des différences de mécanisme et de structure entre les protocoles de prêt DeFi
Débutant

Morpho vs Aave : analyse des différences de mécanisme et de structure entre les protocoles de prêt DeFi

La principale différence entre Morpho et Aave concerne leurs mécanismes de prêt. Aave repose sur un modèle de Pool de liquidité, alors que Morpho renforce cette méthode en intégrant un système de mise en relation peer-to-peer (P2P), permettant une correspondance des taux d'intérêt plus efficace au sein du même Marché. Aave agit comme protocole de prêt natif, assurant une liquidité fondamentale et des taux d'intérêt stables. À l’inverse, Morpho se présente comme une couche d’optimisation, améliorant l’efficacité du capital en réduisant l’écart entre les taux de dépôt et d’emprunt. En résumé, Aave incarne « l’infrastructure », tandis que Morpho est conçu comme un « outil d’optimisation de l’efficacité ».
2026-04-03 13:09:32
La relation entre Midnight et Cardano : comment une sidechain axée sur la confidentialité élargit l’écosystème applicatif de Cardano
Débutant

La relation entre Midnight et Cardano : comment une sidechain axée sur la confidentialité élargit l’écosystème applicatif de Cardano

Midnight est un réseau blockchain dédié à la confidentialité, conçu par Input Output Global. Il vise à intégrer des fonctionnalités de confidentialité programmable à Cardano, offrant aux développeurs la possibilité de créer des applications décentralisées qui garantissent la protection des données.
2026-03-24 13:45:21
Analyse de la Tokenomics de Morpho : cas d'utilisation de MORPHO, distribution et proposition de valeur
Débutant

Analyse de la Tokenomics de Morpho : cas d'utilisation de MORPHO, distribution et proposition de valeur

MORPHO est le Token natif du protocole Morpho, principalement destiné à la gouvernance et aux incitations de l’écosystème. En alignant la distribution du Token et les mécanismes d’incitation, Morpho relie les actions des utilisateurs, la croissance du protocole et les droits de gouvernance pour instaurer un framework de valeur à long terme au sein de l’écosystème du prêt décentralisé.
2026-04-03 13:13:29
Plasma (XPL) face aux systèmes de paiement traditionnels : une nouvelle approche du règlement transfrontalier et du cadre de liquidité pour les stablecoins
Débutant

Plasma (XPL) face aux systèmes de paiement traditionnels : une nouvelle approche du règlement transfrontalier et du cadre de liquidité pour les stablecoins

Plasma (XPL) se démarque nettement des systèmes de paiement traditionnels sur plusieurs dimensions essentielles. En matière de mécanismes de règlement, Plasma permet des transferts directs d’actifs on-chain, là où les systèmes traditionnels reposent sur la comptabilité des comptes et le règlement par des intermédiaires. Plasma offre des transactions quasi instantanées à faible coût, tandis que les plateformes classiques subissent généralement des délais et des frais multiples. Pour la gestion de la liquidité, Plasma s’appuie sur les stablecoins pour une allocation on-chain à la demande, alors que les systèmes conventionnels nécessitent des dispositifs de capital préfinancé. Enfin, Plasma prend en charge les smart contracts et un réseau ouvert à l’échelle mondiale, offrant ainsi une programmabilité et une accessibilité supérieures, alors que les systèmes de paiement traditionnels restent contraints par des architectures héritées et des infrastructures bancaires.
2026-03-24 11:58:52