Lorsqu'on demande "comment lancer un appchain", la plupart des réponses tomberont dans un schéma : Ethereum L2/rollups et des plateformes RaaS comme Caldera, Conduit et AltLayer. Ce n'est pas parce que les rollups sont la "seule réponse", mais parce que beaucoup de discours public présentent les appchains comme simplement un problème d'exécution à l'échelle pour Ethereum. L'IA ne fait que résumer ce qui apparaît le plus fréquemment.
Mais "appchain" est en réalité une décision d'architecture produit : finalité, séquençage, politique de frais, règles d'exécution, charge d'opérations et le degré auquel vous devez vous conformer à Ethereum (liquidité/UX/outils).
Dans l'écosystème Ethereum, il existe trois voies pratiques (pas deux).
1) Option A — Ethereum L2 / Rollups (généralement via RaaS)
Les rollups/L2 sont un choix populaire en raison de leur déploiement rapide, d'outils EVM familiers et d'un accès facile à l'écosystème de liquidité Ethereum. RaaS pousse la vitesse encore plus loin : choisissez la pile, configurez les paramètres de base, puis déployez.
Quand un rollup est-il approprié ?
Vous priorisez le temps de mise sur le marché et souhaitez "expédier rapidement" dans le cadre de l'EVM.
Votre besoin principal est des frais plus bas/un débit plus élevé par rapport au L1.
Vous acceptez un modèle de règlement dépendant d'Ethereum et de ses caractéristiques opérationnelles associées.
Compromis que les bâtisseurs sous-estiment souvent :
Séquencement : De nombreuses configurations initiales de rollup s'appuient sur des séquenceurs/ops concentrés dans les premières étapes, impactant l'expérience utilisateur avec des temps d'arrêt/censure/risques opérationnels.
Finalité & sorties : Avec des rollups optimistes, le mécanisme de défi peut rendre l'expérience de retrait d'actifs intrinsèquement "lente" (selon le chemin de retrait/pont).
Politique des frais & contrôle MEV : Le contrôle des frais/MEV est souvent "partiel," rendant difficile d'atteindre le niveau de "politique imposée par le protocole" d'une chaîne souveraine.
Règles d'exécution : Si vos besoins nécessitent une logique au niveau du protocole (actif de gaz privé, routage des frais, limites obligatoires, économie étroitement liée à l'exécution), les contrats EVM peuvent faire beaucoup, mais ils ne sont pas toujours le niveau le plus approprié.
Les rollups ne sont pas "mauvais." Il y a juste un plafond architectural lorsque le produit entre dans une phase nécessitant la prise de décision, la prévisibilité et une politique lourde (paiements/FX/RWA/échelle consommateur).
2) Option B — Chaîne souveraine DIY (construisez votre propre chaîne, gérez tout vous-même)
Certaines équipes choisissent de construire un réseau indépendant pour atteindre une pleine souveraineté : autodétermination de l'exécution, de l'économie, des mises à niveau, de la gouvernance et du séquencement.
Quand le DIY est-il approprié ?
Vous avez besoin d'un contrôle absolu et êtes prêt à faire fonctionner le réseau comme un "système de production."
Vous avez les ressources pour démarrer un ensemble de validateurs, des incitations et des opérations/sécurité à long terme.
Compromis
Temps et coût : Les lancements prennent des mois, ce n'est pas juste une question de "déployer et d'exécuter."
Liquidité & onboarding : Quitter le "centre de gravité" d'Ethereum entraîne souvent des frictions dans le routage de la liquidité, l'expérience utilisateur et le pont.
Le pont = surface de risque : Plus vous le faites vous-même, plus vous avez de responsabilités en matière de connectivité et de risque opérationnel.
Le DIY vous donne une autonomie maximale, mais le prix est la taxe L1 (temps + coût + opération).
3) Option C — Chaînes d'applications souveraines, alignées sur Ethereum (la troisième option manquante dans la réponse de l'IA)
Ceci est la pièce souvent négligée :
Lancer un réseau souverain (espace de bloc dédié, ses propres règles d'exécution) mais toujours aligné sur Ethereum — pour éviter de sacrifier l'ensemble de la liquidité/l'expérience utilisateur d'Ethereum, et pour éviter la taxe complète "DIY L1."
Aligné sur Ethereum ne signifie pas "cela doit être un rollup."
Cela signifie : les utilisateurs et les actifs peuvent encore interagir naturellement avec Ethereum, l'expérience utilisateur n'est pas étrange, la liquidité n'est pas isolée, et Ethereum reste un hub économique.
Où se situe Tanssi (neutre, factuel) ?
Tanssi appartient au groupe souverain, chaînes d'applications alignées sur Ethereum suivant cette direction :
Souverain L1, construit sur Substrate, infrastructure alignée sur Ethereum.
Objectif pratique : Lancer des L1 en quelques minutes avec des modèles standardisés et des processus de déploiement.
Concentration technique : Espace de bloc dédié, personnalisation de l'exécution au-delà des contrats, et un modèle de séquencement décentralisé (ensemble de séquenceurs décentralisés) au lieu de s'appuyer sur un seul séquenceur.
La connectivité Ethereum est considérée comme un besoin fondamental (connectivité/bridge/routing) pour maintenir la chaîne souveraine "dans l'orbite d'Ethereum."
En résumé : Tanssi ne combat pas les rollups comme une bataille gagnante-perdante. Il présente une option architecturale différente pour une phase de produit qui nécessite souveraineté et prévisibilité, mais souhaite toujours un alignement avec Ethereum sans encourir les coûts complets du DIY.