Hébergez votre propre gateway Label 309

Oui — vous pouvez héberger votre propre gateway. Un gateway Label 309 est le service open source qui établit les devis, téléverse, publie, confirme et indexe les records de preuve d'existence. Hébergez le vôtre et votre organisation devient l'opérateur : vous approvisionnez les portefeuilles Cardano et de stockage, vous gérez les comptes et les clés API, et vous publiez des records standard sans dépendre du service hébergé de CardanoWall. Les records que vous ancrez sont identiques à ceux de n'importe qui d'autre, parce que c'est le standard, et non l'opérateur, qui définit le format.

L'auto-hébergement n'est pas la voie la plus simple. C'est la voie du contrôle. Cet article explique quand ce compromis vaut la peine, ce que le gateway exécute réellement, et ce que vous prenez en charge en l'hébergeant vous-même.

Quand héberger votre propre gateway ?

Hébergez votre propre gateway lorsque le contrôle opérationnel compte plus que la commodité.

Pour la plupart des utilisateurs, le gateway hébergé de CardanoWall est la bonne réponse. Il est plus simple à démarrer, plus facile à approvisionner, et il supprime entièrement le travail d'infrastructure. Si vous publiez ponctuellement et qu'aucune raison de politique interne ne vous oblige à détenir les clés vous-même, arrêtez-vous ici : la voie hébergée est faite pour vous.

Certaines équipes, en revanche, ont besoin d'un autre modèle :

• des politiques strictes en matière de fournisseurs et de résidence des données ;
• des processus réglementés ou audités ;
• une publication à fort volume ;
• des archives de conformité internes et des systèmes de preuve juridique ;
• une infrastructure de provenance pour l'IA et des chaînes de preuve CI/CD ;
• des produits bâtis sur Label 309 sous leur propre marque ;
• un contrôle direct des clés, des comptes, de l'approvisionnement et de la tarification.

Pour ces équipes, l'auto-hébergement permet à l'organisation de posséder l'ensemble du pipeline plutôt que de le faire transiter par un tiers.

Qu'exécute réellement le gateway ?

Le gateway possède l'ensemble du pipeline de publication, ainsi que l'état monétaire, de la chaîne et du stockage qui le sous-tend. C'est un unique binaire Rust accompagné de PostgreSQL, et il gère :

• la création des devis et la tarification ;
• le téléversement du contenu ou du texte chiffré vers le stockage ;
• l'approvisionnement et la comptabilité du stockage ;
• la construction, la soumission et le suivi de confirmation des transactions Cardano ;
• la gestion des réorganisations et les remboursements automatiques lorsqu'une publication échoue définitivement ;
• l'index public des records sur la chaîne ;
• les soldes de compte et le grand livre des soldes ;
• les clés API, les jetons de compte et le plan de contrôle de l'opérateur ;
• les webhooks et la piste d'audit.

Voilà la mécanique qui se cache derrière un service de publication fiable. Le client conserve l'intention côté utilisateur et les clés privées ; le gateway possède la chaîne, le stockage, la tarification et l'infrastructure de comptes. Cette répartition est délibérée — c'est la même frontière, que ce soit CardanoWall ou vous qui exécutiez le gateway.

De quoi avez-vous besoin pour auto-héberger ?

Au minimum, de la responsabilité opérationnelle de cinq éléments.

Un déploiement du gateway. Le binaire, sa configuration, une base de données Postgres, l'accès réseau, les journaux, la supervision et une trajectoire de mise à niveau. Le binaire applique lui-même ses migrations de schéma au démarrage et exécute toutes ses boucles d'arrière-plan sous un superviseur unique : ainsi, une boucle défaillante arrête le processus au lieu de se dégrader silencieusement.

L'approvisionnement Cardano. Le gateway a besoin d'un portefeuille approvisionné pour payer les frais de transaction. Vous ne gérez pas vous-même les sorties de transaction individuelles — le portefeuille maintient un petit ensemble de sorties prêtes, soigneusement entretenues, afin que chaque publication paie des frais exacts plutôt qu'une estimation. Vous maintenez ce portefeuille approvisionné ; le gateway s'occupe du reste.

L'approvisionnement du stockage. Si votre gateway accepte le téléversement de fichiers ou de texte chiffré, il a besoin d'un backend de stockage et des fonds nécessaires pour stocker les octets. En production, il s'agit d'Arweave via un bundler Turbo, payé au moyen de crédits de stockage prépayés que vous rechargez depuis un portefeuille Arweave. Vous pouvez aussi exécuter un déploiement sans stockage, limité aux empreintes : les records ne portent alors que l'empreinte du contenu (et d'éventuelles URI hébergées en externe), et l'instance ne stocke rien.

Les identifiants d'opérateur. Le plan de contrôle est protégé par un secret racine d'opérateur, affiché une seule fois lors du provisionnement de l'instance. L'administration au quotidien repose sur des jetons d'opérateur éphémères qui en sont dérivés. Ces secrets ne doivent jamais atteindre un navigateur, un bundle client, une application mobile ou un journal de CI.

Une politique de comptes et de facturation. Même si vous êtes le seul utilisateur, le gateway doit tout de même décider qui peut publier et comment les soldes sont crédités. Les soldes relèvent de l'autorité propre du gateway ; vous les créditez via le plan de contrôle, depuis le rail de facturation que vous exploitez.

L'auto-hébergement, c'est de la véritable infrastructure. Traitez-le comme tel et il sera fiable ; prenez-le à la légère et il deviendra un risque.

L'auto-hébergement modifie-t-il le standard ?

Non. Un gateway auto-hébergé publie les mêmes records Label 309 que n'importe quel autre opérateur, et ces records restent standard.

Un vérificateur n'a besoin que des métadonnées de la transaction Cardano, éventuellement des octets du contenu, et d'un explorateur Cardano public. Il n'a pas besoin de savoir — et ne peut pas distinguer — si un record provient du gateway hébergé de CardanoWall, du gateway de votre entreprise ou de l'ordinateur portable d'un développeur. C'est tout l'intérêt de séparer le standard ouvert du produit hébergé : l'artefact durable est Label 309, et chaque gateway n'en est qu'une implémentation en aval.

L'auto-hébergement supprime-t-il tout le coût ?

Non. Il supprime la marge de l'opérateur hébergé, mais les coûts sous-jacents restent à votre charge.

Vous payez toujours :

• les frais de transaction Cardano et les coûts de stockage de tout octet téléversé ;
• les coûts d'infrastructure, de base de données et de sauvegarde ;
• la supervision, la journalisation et les opérations de sécurité ;
• le temps des équipes, la gestion de trésorerie et la reprise après incident ;
• les mises à niveau et la maintenance continue.

Si votre volume est faible, le gateway hébergé revient souvent moins cher en pratique, une fois pris en compte le coût humain de l'exploitation d'une infrastructure. (Pour comprendre pourquoi la publication a un coût en premier lieu, voir pourquoi la publication a un prix.) Si votre volume est élevé, ou si votre politique vous impose de détenir les clés, l'auto-hébergement commence à devenir rentable.

Qui ne devrait pas auto-héberger ?

N'auto-hébergez pas simplement pour éviter de penser au prix.

Si vous publiez ponctuellement, que vous manquez de capacité opérationnelle, que vous ne souhaitez pas gérer des portefeuilles approvisionnés et que vous n'avez pas besoin d'un contrôle de politique sur mesure, le gateway hébergé est presque à coup sûr le meilleur choix. L'auto-hébergement vous met aux commandes de la disponibilité, de la sécurité, de l'approvisionnement, de la supervision et des mises à niveau — un avantage uniquement si vous voulez réellement assumer cette responsabilité.

Pour la plupart des particuliers et de nombreuses petites équipes, CardanoWall hébergé est la voie pratique.

Pour qui l'auto-hébergement est-il pertinent ?

Pour les équipes qui exploitent déjà une infrastructure sérieuse et qui ont une raison concrète de maîtriser le pipeline elles-mêmes. Parmi les bons candidats :

• les entreprises qui publient des preuves à fort volume ;
• les équipes de conformité qui ancrent des pièces chaque jour ou chaque heure, idéalement regroupées sous un seul record ;
• les équipes IA qui publient des manifestes de jeux de données et de sorties ;
• les équipes DevSecOps qui intègrent des preuves dans les pipelines de version ;
• les plateformes juridiques qui traitent des pièces sensibles ;
• les produits qui veulent Label 309 sous leur propre marque ;
• les organisations qui ne peuvent pas faire transiter des processus sensibles par un service hébergé tiers.

Dans ces cas, l'exploitation du gateway s'intègre à la posture de sécurité et d'infrastructure existante de l'organisation, au lieu de constituer une nouvelle chose à surveiller.

Comment un produit se bâtit-il sur un gateway ?

Un produit peut considérer le gateway comme sa couche de base. Le gateway prend en charge la chaîne, le stockage, la tarification, les soldes, les records et le statut de publication ; votre produit gère les utilisateurs, les sessions, la présentation de la facturation, les notifications, le flux de travail, l'interface et le sens propre à votre domaine.

Par exemple :

• un produit de conformité publie chaque jour des instantanés de ses contrôles ;
• un produit média ancre les empreintes de manifestes Content Credentials (C2PA) ;
• un produit juridique scelle des pièces pour des destinataires précis ;
• un outil de développement publie des preuves de version ;
• un produit IA horodate des lots de sorties générées.

Le produit ne reconstruit jamais la soumission Cardano ni la comptabilité du stockage — il appelle le gateway. C'est exactement ainsi que CardanoWall est construit : l'application web et le worker sont une surcouche autour des mêmes plans publics du gateway qu'utilise un tiers, sans porte dérobée. Si vous voulez approfondir les schémas d'intégration, voir bâtir sur un gateway Label 309.

Comment les clients se connectent-ils à un gateway ?

Via l'API HTTP du gateway, scindée en deux plans.

Une application web, une application de bureau, un CLI, une intégration SDK ou un service backend utilise des jetons de compte ou des clés API pour appeler le plan de données : devis, téléversement, publication, lecture du solde, lecture des records. Les actions d'opérateur — créer des comptes, créditer des soldes, fixer des marges, émettre des identifiants — passent par le plan de contrôle, et toujours uniquement depuis un backend de confiance.

La séparation habituelle :

• les clients agissent avec des identifiants de compte limités et éphémères ;
• votre backend détient les identifiants d'opérateur et ne les expose jamais ;
• les clés d'identité privées restent sur les appareils des utilisateurs ou sous votre propre politique de clés ;
• le gateway ne déchiffre jamais de contenu scellé.

Un schéma pratique est le proxy d'émission de jetons : le client s'authentifie auprès de votre propre système de sessions, votre backend échange cette session contre un jeton de compte éphémère limité à ce dont la page a précisément besoin, et le client ne voit jamais que ce jeton. Une fuite de jeton devient alors un problème d'une heure, pas un incident. La surface de lecture des records est encore plus simple — elle sert des appelants anonymes, si bien que les pages de vérification publiques et les explorateurs n'ont besoin d'aucun identifiant.

Que doivent protéger les opérateurs ?

Plusieurs éléments, à peu près dans cet ordre de gravité.

Les clés et identifiants. Le gateway signe avec un unique keyring chiffré — les clés Cardano, de stockage et de webhook dans un seul fichier sous une seule phrase secrète. Créez-le hors ligne, conservez une sauvegarde hors ligne du fichier comme de la phrase secrète, et protégez le secret racine d'opérateur comme un mot de passe de base de données de production. Il n'existe aucune voie d'export de clé ni de retrait des fonds : perdez le keyring et vous immobilisez les fonds qui se trouvent sur ses adresses.

Les fonds et l'autorité. Contrôlez qui peut créer des comptes, émettre des clés API, ajuster des soldes et modifier des marges. Chaque action du plan de contrôle est consignée dans l'audit, et les ajustements de solde sont plafonnés par appel comme limite de rayon d'impact : ainsi, une saisie maladroite ou un jeton compromis ne peut déplacer qu'un montant limité à la fois.

Les opérations. Tenez des journaux et une piste d'audit, un plan de sauvegarde et de restauration, et une supervision qui surveille un portefeuille à court de fonds, un stockage qui s'épuise, des téléversements bloqués, des publications échouées et une tête de chaîne figée. Le binaire journalise en JSON structuré pour un agrégateur de journaux et expose une sonde de santé.

Le moindre privilège. Un navigateur ne doit jamais recevoir d'identifiants d'opérateur. Une tâche de CI ne doit jamais recevoir plus de pouvoir qu'il ne lui en faut. Limitez étroitement la portée des jetons de compte et gardez-les éphémères.

Comment se déroule la vérification face à un gateway auto-hébergé ?

Exactement comme face à n'importe quel gateway : la vérification ne fait aucunement confiance au gateway.

Un vérificateur contrôle la transaction Cardano, les métadonnées Label 309, les empreintes, les signatures facultatives, les éventuelles preuves Merkle et les contenus scellés à l'aide des règles du standard — sans aucun serveur d'émetteur dans la boucle. Le gateway vous aide à publier et à indexer ; il ne peut pas rendre valide une preuve qui ne l'est pas.

Cela compte avant tout pour les systèmes internes. Une entreprise qui exécute son propre gateway devrait néanmoins vérifier ses propres records de façon indépendante. « Notre gateway a dit qu'il a publié » n'est pas la preuve. Le record sur la chaîne et un contrôle indépendant, voilà la preuve. Vous pouvez effectuer ce contrôle avec l'outil en ligne de commande open source cardanowall ou vérifier un record à la main — ni l'un ni l'autre n'exige que votre gateway tourne.

Quel est le lien avec CardanoWall ?

CardanoWall est le produit hébergé et abouti, et l'opérateur de référence du standard. L'auto-hébergement est la voie de l'indépendance. Les deux ne s'opposent pas.

Un utilisateur peut démarrer sur CardanoWall, migrer plus tard vers un gateway auto-hébergé, ou utiliser les deux pour des processus différents. Un développeur peut bâtir un produit sur le modèle du gateway. Une entreprise peut conserver CardanoWall hébergé pour ses équipes les plus simples tout en exploitant son propre gateway pour l'automatisation réglementée. La couche commune sous tout cela, c'est Label 309 — ouvert, indépendant des fournisseurs, et identique sur la chaîne quel que soit l'auteur de la publication.

En résumé

Hébergez votre propre gateway lorsque vous voulez exploiter vous-même le service de publication. Vous gagnez le contrôle de l'approvisionnement, des comptes, des marges, des clés API, de l'infrastructure et de la politique — et vous assumez la responsabilité de la disponibilité, de la sécurité, des portefeuilles, du stockage, de la supervision et des mises à niveau.

CardanoWall hébergé, c'est la commodité. L'auto-hébergement, c'est le contrôle. Dans les deux cas, les records de preuve restent standard.

Pour aller plus loin

• Le standard ouvert : label309.org.
• Le gateway, les SDK et le CLI, tous open source (Apache-2.0) : github.com/cardanowall.
• Le standard de métadonnées est soumis au processus CIP de Cardano et en cours d'examen : la pull request de la proposition.
• Qu'est-ce qu'un gateway Label 309 ?
• Label 309 est open source