Qu'est-ce qu'un gateway Label 309 ?

Un gateway Label 309 est le service qui publie des records de preuve d'existence sur Cardano. Il prend en charge tout le travail opérationnel — tarification, téléversements, soumission de la transaction, suivi de la confirmation, indexation des records, soldes, clés d'API et webhooks — pour qu'un client n'ait pas à le faire. Le client prépare la preuve et conserve ses clés privées en local ; le gateway, lui, achemine le record jusqu'au réseau.

Label 309 est le standard ouvert et neutre vis-à-vis des fournisseurs qui permet d'ancrer une empreinte de contenu sur Cardano sous le label de métadonnées 309. Le gateway en est la brique qui assure la publication. Ce n'est pas un backend privé réservé à une seule entreprise : c'est une couche de service définie que n'importe quel produit peut exploiter ou avec laquelle il peut s'intégrer, et l'implémentation de référence est open source. CardanoWall fait tourner son propre produit commercial sur exactement ces mêmes surfaces, sans aucune voie distincte qui lui serait réservée.

Pourquoi la publication a-t-elle besoin d'un gateway ?

La vérification est légère. La publication est opérationnelle.

Pour vérifier une preuve, vous partez généralement d'une référence de transaction Cardano, vous récupérez le record depuis un explorateur public, puis vous recalculez vous-même les empreintes ou les signatures. Aucun service particulier n'est requis — cette indépendance est tout l'enjeu du standard. (Voyez comment vérifier un record Label 309 pour le parcours complet.)

La publication comporte bien plus de pièces mobiles :

construire un record Label 309 valide ;
estimer le coût de la transaction Cardano ;
téléverser le texte chiffré ou le contenu lorsque des fichiers sont en jeu ;
payer les coûts de stockage ;
soumettre la transaction Cardano ;
attendre la confirmation ;
gérer les échecs et les remboursements ;
indexer le résultat ;
restituer le statut à l'utilisateur ;
maintenir des soldes de compte exacts.

Un gateway regroupe ces préoccupations derrière une API. Sans lui, chaque produit souhaitant publier devrait reconstruire le même pipeline de chaîne et de stockage. Avec lui, une équipe produit peut se concentrer sur son expérience utilisateur et son flux métier pendant que le gateway s'occupe de la chaîne, du stockage et de la comptabilité.

Que fait concrètement le gateway ?

Le gateway possède le pipeline de publication ainsi que l'état monétaire, de chaîne et de stockage qui le sous-tend. Concrètement, il peut :

établir un devis pour une preuve avant que vous ne publiiez (le prix tient pendant une courte fenêtre, environ 15 minutes) ;
accepter des téléversements chiffrés et des téléversements de contenu public, en renvoyant des URI adressés par le contenu ;
accepter un record de preuve déjà préparé ;
construire et soumettre une transaction Cardano avec des frais exacts ;
suivre la confirmation, y compris la gestion des réorganisations ;
rembourser automatiquement la charge lorsqu'une publication échoue définitivement ;
indexer chaque record Label 309 du réseau dans un flux public et partagé ;
gérer les soldes de compte prépayés et appliquer la tarification ;
émettre des clés d'API et des jetons de compte ;
envoyer des webhooks pour les événements de cycle de vie.

C'est ce qui en fait le moteur de publication derrière l'application web CardanoWall, l'application de bureau, l'outil en ligne de commande, les intégrations fondées sur le SDK, les workflows CI/CD comme les produits tiers.

Que s'interdit délibérément le gateway ?

Le gateway n'est pas la racine de confiance.

Il n'a jamais besoin de votre graine d'identité. Il n'a jamais besoin des clés privées des destinataires. Il ne déchiffre pas les fichiers scellés. Et il n'est jamais le seul endroit où une preuve peut être vérifiée. Ces propriétés sont voulues par conception : c'est en gardant ces éléments hors du gateway qu'une preuve peut tenir par elle-même.

Une preuve Label 309 valide repose sur des données publiques, pas sur la parole du gateway :

la transaction Cardano ;
les métadonnées Label 309 ;
le contenu d'origine ou le texte chiffré, au besoin ;
les signatures de record et les clés publiques ;
les preuves Merkle, pour les records regroupés ;
les propres clés du destinataire, pour les contenus scellés.

Si le gateway signale qu'une preuve existe, un vérificateur peut toujours la confirmer directement sur la chaîne — sans la moindre intervention du gateway. Pour ce qu'un opérateur de gateway peut et ne peut pas observer, voyez ce que CardanoWall peut voir.

Qu'est-ce que le plan de données ?

Le plan de données est l'API destinée à l'utilisateur. C'est ce qu'un client appelle lorsqu'il agit au nom d'un utilisateur ou d'un compte — une application web, l'application de bureau, le CLI, un SDK ou un script d'automatisation qui demande à établir un devis, à téléverser, à publier, à lire un solde ou à lister des records. Il réside sur le chemin /api/v1/*.

Le flux conceptuel est court :

Demander un devis.
Téléverser le contenu ou le texte chiffré, lorsque des fichiers sont en jeu.
Publier la preuve.
Suivre le statut.
Lire les records et les soldes.

C'est exactement le parcours qu'emprunte le produit de référence. Si un flux fonctionne pour CardanoWall, il est accessible à tous via le plan de données public.

Qu'est-ce que le plan de contrôle ?

Le plan de contrôle est destiné aux opérateurs et aux backends de produit, et réside sur le chemin /control/v1/*.

Si une entreprise construit son propre produit sur un gateway, son backend doit pouvoir créer des comptes, appliquer des crédits de facturation, émettre des jetons de compte à courte durée de vie, définir des marges par compte, créer des clés d'API et exécuter des tâches au niveau opérateur. C'est du travail de plan de contrôle, et il doit s'effectuer depuis un backend de confiance — jamais depuis du code navigateur ni un client mobile.

Le plan de contrôle est ce qui permet à un gateway de prendre en charge plus d'un produit. Une autre équipe peut faire tourner sa propre couche fournisseur par-dessus : ses propres utilisateurs, sa facturation, son interface, son support et ses propres règles produit, pendant que le gateway gère le pipeline de publication de base en dessous. La frontière entre les deux, c'est l'API HTTP et le firehose de webhooks — pas la base de données du gateway, qui reste privée au moteur.

Que signifie « aucune porte privée » ?

Cela signifie que le produit de référence publie via les mêmes surfaces que tout le monde. Il n'existe aucune voie secrète, plus rapide ou privilégiée réservée à CardanoWall.

C'est important pour la crédibilité. Si un projet prétendait que son standard est ouvert tout en publiant via une machinerie interne cachée, l'écosystème resterait dépendant de ce seul fournisseur. Le modèle du gateway supprime cette dépendance : CardanoWall peut être le premier produit abouti, pendant que d'autres équipes construisent leurs propres outils, services, tableaux de bord, clients de bureau et workflows métier sur le même chemin standard. Si vous construisez dessus, voyez construire sur un gateway Label 309.

Une entreprise peut-elle exploiter son propre gateway ?

Oui. Le cœur du gateway est open source — un unique binaire Rust accompagné de PostgreSQL — et une entreprise peut l'exploiter elle-même : approvisionner ses propres portefeuilles Cardano et Arweave, créer ses propres comptes et clés d'API, et publier des records Label 309 sans dépendre de CardanoWall comme opérateur hébergé.

L'auto-hébergement peut avoir du sens pour :

la publication à fort volume ;
les politiques fournisseurs strictes ;
les environnements réglementés ou isolés du réseau ;
les workflows de conformité interne ;
les systèmes de preuve juridique ;
l'infrastructure de provenance de l'IA ;
les pipelines de preuve CI/CD ;
les équipes qui exploitent déjà leur propre infrastructure cloud et chaîne.

L'auto-hébergement ne change rien au standard de record — un gateway auto-hébergé produit les mêmes records, vérifiables par n'importe qui. Il change seulement qui exploite le service de publication. La mise en place pratique est traitée dans exploiter votre propre gateway.

Quand utiliser le gateway hébergé de CardanoWall ?

Utilisez le gateway hébergé lorsque la commodité compte plus que d'exploiter vous-même l'infrastructure.

Le service hébergé prend en charge pour vous l'approvisionnement, la tarification, la soumission, les confirmations, le stockage et la gestion des comptes. Cela convient aux utilisateurs individuels, aux petites équipes, aux premières intégrations et aux entreprises qui veulent démarrer rapidement. Vous obtenez toujours des records standard, vous pouvez toujours vérifier à partir de données publiques, et vous pouvez toujours migrer plus tard vers votre propre outillage ou votre propre gateway. Hébergé ne veut pas dire verrouillé.

Quand vaut-il mieux auto-héberger ?

Auto-hébergez lorsque le contrôle opérationnel compte plus que la commodité. Parmi les bonnes raisons :

vous publiez à fort volume ;
vous voulez vos propres règles de frais et d'approvisionnement ;
votre organisation ne peut pas s'appuyer sur un service hébergé par un tiers ;
vos records relèvent d'un workflow interne et réglementé ;
votre produit a besoin de son propre modèle de facturation ;
vous voulez proposer la publication Label 309 sous votre propre marque ;
vous voulez un contrôle direct sur les clés d'API, les comptes et les webhooks.

L'auto-hébergement demande plus de travail. Vous faites tourner le gateway, approvisionnez les portefeuilles, surveillez les fournisseurs, gérez les secrets, exploitez la base de données, prenez en charge les mises à niveau et maintenez le service en bonne santé. La contrepartie, c'est l'indépendance.

Comment la tarification s'inscrit-elle là-dedans ?

Publier coûte de l'argent parce que le gateway assume des coûts réels. Chaque preuve ancre une transaction Cardano, qui implique des frais de réseau. Lorsque des fichiers sont en jeu, le gateway paie aussi le stockage Arweave. À cela s'ajoutent la gestion des taux de change, l'approvisionnement, l'infrastructure, la surveillance, le support, les remboursements et le risque.

Un gateway hébergé facture donc sur une base de répercussion des coûts, augmentée d'une marge de service. Les taux de change sont en direct — le gateway établit chaque devis à partir des taux de marché courants plutôt que d'une constante codée en dur — et le taux derrière un devis peut bouger, ce qui explique qu'un devis ne soit valable que pendant une courte fenêtre. Le prix affiché peut varier selon le compte, le partenaire ou la politique de l'opérateur. Pour les raisons mêmes de cette facturation, voyez pourquoi la publication a un prix.

Si vous voulez éviter la marge d'un intermédiaire hébergé, la réponse n'est pas une publication gratuite — les coûts de chaîne et de stockage sont réels dans les deux cas. La réponse, c'est d'exploiter un gateway, de l'approvisionner directement et d'assumer vous-même le travail d'exploitation.

Quel rapport entre l'application de bureau et le gateway ?

CardanoWall Desktop — une application de bureau open source bâtie sur le SDK Rust — est un client de gateway, pas un opérateur de chaîne.

Elle conserve les identités en local, synchronise et tente de déchiffrer à l'essai les records scellés sur votre propre machine, met les données en cache pour un usage hors ligne, prépare et signe les records, chiffre les fichiers et vérifie les preuves — le tout en local. Ce n'est explicitement pas un portefeuille : elle n'assure pas la garde des ADA et ne construit ni ne soumet elle-même de transactions Cardano. Pour tout ce qui touche à la chaîne ou au stockage, elle se tourne vers un gateway et le laisse posséder le pipeline de publication.

Vous choisissez quel gateway :

le gateway hébergé de CardanoWall ;
le gateway de votre entreprise ;
n'importe quel gateway tiers ;
un gateway local ou de développement.

L'application de bureau possède l'expérience locale ; le gateway possède la publication. Plus de détails sur l'application dans CardanoWall Desktop.

Que doivent garder à l'esprit les développeurs ?

Appuyez-vous sur la frontière du standard — les plans HTTP et les webhooks — et non sur les rouages internes du gateway.

Quelques règles maintiennent une intégration saine :

N'interrogez pas directement la base de données du gateway ; elle est interne au moteur et peut changer sans préavis.
Ne placez pas d'identifiants opérateur dans les clients. Tout ce qui requiert une autorité d'opérateur a sa place dans votre backend.
Ne traitez pas un solde mis en cache comme la source de vérité pour une décision de dépense ; lisez le solde du gateway lorsqu'il conditionne une charge.
Ne construisez pas votre propre chemin de remboursement pour les échecs de publication — le gateway rembourse déjà automatiquement, et un second remboursement reviendrait à payer deux fois.
Ne demandez pas au gateway de déchiffrer le contenu des utilisateurs.

La forme propre est simple : votre client ou votre backend capte l'intention de l'utilisateur, votre client garde les secrets en local, le gateway gère le devis, le téléversement, la publication, la confirmation et l'indexation, votre produit construit par-dessus sa propre interface et ses propres modèles de lecture, et la vérification reste indépendante. C'est ainsi qu'un seul standard peut prendre en charge de nombreux produits sans transformer chaque produit en opérateur de chaîne et de stockage.

En bref

Un gateway Label 309 est la couche de publication. Il établit des devis, téléverse, publie, confirme, indexe et expose des records. Il peut être hébergé par CardanoWall, auto-hébergé par une entreprise ou intégré à un autre produit.

Ce n'est pas la racine de confiance, et il ne détient pas vos clés privées. Il publie des records standard que n'importe qui peut vérifier à partir des données Cardano publiques — ce qui est précisément ce qui maintient le standard ouvert.

Pour aller plus loin

Construire sur un gateway Label 309 — modèles d'intégration pour les plans de données et de contrôle.
Exploiter votre propre gateway — faire tourner une instance auto-hébergée.
Pourquoi la publication a un prix — le modèle de coût derrière un devis.
Vérifier un record Label 309 — contrôler une preuve à partir des seules données publiques.
Le standard ouvert sur label309.org et le code open source sur github.com/cardanowall. Label 309 a été soumis au processus CIP de Cardano et est en cours d'examen par les éditeurs CIP en tant que proposition de catégorie Metadata (PR ouverte).