Gestisci il tuo gateway Label 309

Sì, puoi gestire il tuo gateway. Un gateway Label 309 è il servizio open source che genera preventivi, carica i dati, pubblica, conferma e indicizza i record di proof-of-existence. Gestisci il tuo e la tua organizzazione diventa l'operatore: finanzi i wallet Cardano e di storage, gestisci account e API key e pubblichi record standard senza dipendere dal servizio ospitato di CardanoWall. I record che ancori sono identici a quelli di chiunque altro, perché è lo standard, non l'operatore, a definire il formato.

Il self-hosting non è la via facile. È la via del controllo. Questo articolo spiega quando vale la pena fare questa scelta, cosa il gateway esegue davvero e di cosa ti fai carico gestendolo in proprio.

Quando conviene gestire il proprio gateway?

Gestisci il tuo gateway quando il controllo operativo conta più della comodità.

Per la maggior parte degli utenti, il gateway ospitato di CardanoWall è la risposta giusta. È più semplice da avviare, più facile da finanziare ed elimina del tutto il lavoro infrastrutturale. Se pubblichi di tanto in tanto e non hai motivi di policy per tenere tu stesso le chiavi, fermati qui: la via ospitata è pensata per te.

Alcuni team, però, hanno bisogno di un modello diverso:

policy rigide su fornitori e residenza dei dati;
flussi di lavoro regolamentati o soggetti ad audit;
pubblicazione ad alto volume;
archivi di compliance interni e sistemi di prove legali;
infrastruttura di provenienza per l'AI e pipeline di prova CI/CD;
prodotti costruiti su Label 309 con un proprio marchio;
controllo diretto su chiavi, account, finanziamento e prezzi.

Per questi team, il self-hosting permette all'organizzazione di possedere l'intera pipeline anziché farla passare attraverso una terza parte.

Cosa esegue davvero il gateway?

Il gateway possiede l'intera pipeline di pubblicazione e lo stato di denaro, catena e storage che ci sta dietro. È un singolo binario Rust più PostgreSQL, e si occupa di:

creazione dei preventivi e pricing;
caricamento su storage di contenuti o testo cifrato;
finanziamento e contabilità dello storage;
costruzione, invio e tracciamento della conferma delle transazioni Cardano;
gestione dei reorg e refund automatici quando una pubblicazione fallisce in modo permanente;
l'indice pubblico dei record on-chain;
saldi degli account e ledger dei saldi;
API key, account token e il control plane dell'operatore;
webhook e audit trail.

Questa è la macchina dietro un servizio di pubblicazione affidabile. Il client continua a possedere l'intento rivolto all'utente e le chiavi private; il gateway possiede l'infrastruttura di catena, storage, pricing e account. Questa separazione è voluta — il confine resta lo stesso, che sia CardanoWall a gestire il gateway o che lo gestisca tu.

Cosa serve per il self-hosting?

Come minimo, la titolarità operativa di cinque cose.

Un deployment del gateway. Il binario, la sua configurazione, un database Postgres, l'accesso di rete, i log, il monitoraggio e un percorso di aggiornamento. Il binario applica da solo le migrazioni di schema all'avvio ed esegue ogni loop in background sotto un unico supervisore, così che un loop in errore arresti il processo invece di degradare in silenzio.

Finanziamento Cardano. Il gateway ha bisogno di un wallet finanziato per pagare le commissioni di transazione. Non gestisci tu stesso i singoli output di transazione — il wallet mantiene un piccolo pool di output pronti e curati, in modo che ogni pubblicazione paghi una commissione esatta anziché una stima. Tu tieni quel wallet rifornito; il gateway fa il resto.

Finanziamento dello storage. Se il tuo gateway accetta caricamenti di file o testo cifrato, ha bisogno di un backend di storage e dei fondi per archiviare i byte. In produzione si tratta di Arweave tramite un bundler Turbo, pagato con crediti di storage prepagati che ricarichi da un wallet Arweave. Puoi anche far girare un deployment solo-hash, senza alcuno storage: in tal caso i record portano soltanto l'hash del contenuto (e gli eventuali URI ospitati esternamente), e l'istanza non archivia nulla.

Credenziali dell'operatore. Il control plane è protetto da un operator root secret, stampato una sola volta quando provisioni l'istanza. L'amministrazione quotidiana avviene tramite operator token a breve durata generati a partire da esso. Questi segreti non devono mai raggiungere un browser, un client bundle, un'app mobile o un log di CI.

Una policy di account e billing. Anche se sei l'unico utente, il gateway deve comunque decidere chi può pubblicare e come vengono accreditati i saldi. I saldi sono autorità propria del gateway; li accrediti tramite il control plane dal rail di billing che gestisci.

Il self-hosting è infrastruttura vera. Trattalo come tale ed è affidabile; trattalo con leggerezza e diventa un rischio.

Il self-hosting cambia lo standard?

No. Un gateway self-hosted pubblica gli stessi record Label 309 di qualunque altro operatore, e i record restano standard.

A un verificatore servono solo i metadati della transazione Cardano, facoltativamente i byte del contenuto e un explorer pubblico di Cardano. Non ha bisogno di sapere — e non può capire — se un record proviene dal gateway ospitato di CardanoWall, dal gateway della tua azienda o dal portatile di uno sviluppatore. È proprio questo il senso di separare lo standard aperto dal prodotto ospitato: l'artefatto durevole è Label 309, e ogni gateway ne è un'implementazione a valle.

Il self-hosting elimina tutti i costi?

No. Elimina il margine dell'operatore ospitato, ma i costi sottostanti restano tuoi.

Continui a pagare:

le commissioni di transazione Cardano e i costi di storage per qualunque byte caricato;
i costi di infrastruttura, database e backup;
monitoraggio, logging e operazioni di sicurezza;
il tempo del personale, la gestione di tesoreria e il ripristino dai guasti;
aggiornamenti e manutenzione continua.

Se il tuo volume è basso, il gateway ospitato è spesso più conveniente nella pratica, una volta che metti in conto il costo umano di gestire un'infrastruttura. (Per i meccanismi di perché pubblicare costa, vedi perché pubblicare ha un prezzo.) Se il tuo volume è alto, o se la policy ti impone di tenere tu le chiavi, il self-hosting comincia a ripagarsi.

Chi non dovrebbe fare self-hosting?

Non fare self-hosting solo per evitare di pensare al prezzo.

Se pubblichi di tanto in tanto, non hai capacità operativa, non vuoi gestire wallet finanziati e non hai bisogno di un controllo di policy personalizzato, il gateway ospitato è quasi certamente la scelta migliore. Il self-hosting ti mette al comando di disponibilità, sicurezza, finanziamento, monitoraggio e aggiornamenti — il che è un vantaggio solo se vuoi davvero quella responsabilità.

Per la maggior parte delle persone e per molti piccoli team, CardanoWall ospitato è la via pratica.

Chi è adatto al self-hosting?

I team che già gestiscono infrastruttura seria e hanno un motivo concreto per tenere in casa la pipeline. Tra i buoni candidati:

aziende che pubblicano prove ad alto volume;
team di compliance che ancorano prove giornaliere o orarie, idealmente raggruppate sotto un solo record;
team di AI che ancorano manifesti di dataset e di output;
team DevSecOps che integrano le prove nelle pipeline di rilascio;
piattaforme legali che trattano prove sensibili;
prodotti che vogliono Label 309 con il proprio marchio;
organizzazioni che non possono far passare flussi di lavoro sensibili attraverso un servizio ospitato di terze parti.

In questi casi, gestire il gateway diventa parte della postura di sicurezza e infrastruttura già esistente nell'organizzazione, anziché una nuova cosa da accudire.

Come si costruisce un prodotto sopra un gateway?

Un prodotto può trattare il gateway come il proprio strato di base. Il gateway gestisce catena, storage, pricing, saldi, record e stato di pubblicazione; il tuo prodotto gestisce utenti, sessioni, presentazione del billing, notifiche, workflow, UI e significato specifico del dominio.

Per esempio:

un prodotto di compliance pubblica snapshot giornalieri dei controlli;
un prodotto media ancora gli hash dei manifesti Content Credentials (C2PA);
un prodotto legale sigilla prove per destinatari specifici;
uno strumento per sviluppatori pubblica prove di rilascio;
un prodotto di AI marca temporalmente lotti di output generato.

Il prodotto non ricostruisce mai l'invio su Cardano né la contabilità dello storage — chiama il gateway. È esattamente così che è costruito CardanoWall: la web app e il worker sono un wrapper attorno agli stessi piani pubblici del gateway che usa una terza parte, senza porte private. Se vuoi i pattern di integrazione in dettaglio, vedi costruisci su un gateway Label 309.

Come si connettono i client a un gateway?

Tramite l'API HTTP del gateway, suddivisa in due piani.

Una web app, un'app desktop, una CLI, un'integrazione SDK o un servizio di backend usano account token o API key per chiamare il data plane: preventivo, caricamento, pubblicazione, lettura del saldo, lettura dei record. Le azioni dell'operatore — creare account, accreditare saldi, impostare margini, generare credenziali — passano per il control plane, e sempre e soltanto da un backend fidato.

La separazione consueta:

i client agiscono con credenziali di account a scope limitato e a breve durata;
il tuo backend custodisce le credenziali dell'operatore e non le espone mai;
le chiavi di identità private restano sui dispositivi degli utenti o sotto la tua policy di gestione delle chiavi;
il gateway non decifra mai contenuto sigillato.

Un pattern pratico è il proxy che genera token: il client si autentica contro il tuo sistema di sessioni, il tuo backend scambia quella sessione con un account token a breve durata, con scope limitato esattamente a ciò che serve alla pagina, e il client vede solo quel token. Un token trafugato diventa così un problema da un'ora, non un incidente. La superficie di lettura dei record è ancora più semplice: risponde a chiamanti anonimi, quindi le pagine di verifica pubbliche e gli explorer non hanno bisogno di alcuna credenziale.

Cosa devono proteggere gli operatori?

Diverse cose, più o meno in questo ordine di gravità.

Chiavi e credenziali. Il gateway firma con un unico keyring cifrato — chiavi Cardano, di storage e dei webhook in un solo file, sotto un'unica passphrase. Crealo offline, conserva un backup offline sia del file sia della passphrase, e custodisci l'operator root secret come la password di un database di produzione. Non esiste un percorso di esportazione delle chiavi né di sweep: se perdi il keyring, blocchi qualunque fondo si trovi sui suoi indirizzi.

Fondi e autorità. Controlla chi può creare account, emettere API key, modificare i saldi e cambiare i margini. Ogni azione del control plane viene registrata nell'audit, e le modifiche ai saldi hanno un tetto per ogni chiamata, come limite del raggio d'azione: un inserimento sbagliato o un token compromesso possono spostare solo una certa cifra alla volta.

Operazioni. Mantieni log e audit trail, un piano di backup e ripristino, e il monitoraggio per fondi bassi nel wallet, storage in esaurimento, caricamenti bloccati, pubblicazioni fallite e un chain tip non aggiornato. Il binario produce log in JSON strutturato per un aggregatore di log ed espone una sonda di health.

Privilegio minimo. Un browser non deve mai ricevere le credenziali dell'operatore. Un job di CI non deve mai ricevere più potere di quanto gli serva. Dai agli account token uno scope ristretto e tienili a breve durata.

Come funziona la verifica contro un gateway self-hosted?

Esattamente come contro qualunque gateway: la verifica non si fida affatto del gateway.

Un verificatore controlla la transazione Cardano, i metadati Label 309, gli hash, le firme facoltative, le eventuali prove Merkle e i payload sigillati seguendo le regole dello standard — senza alcun server dell'emittente nel ciclo. Il gateway ti aiuta a pubblicare e indicizzare; non può rendere valida una prova non valida.

Questo conta soprattutto per i sistemi interni. Un'azienda che gestisce il proprio gateway dovrebbe comunque verificare i propri record in modo indipendente. «Il nostro gateway ha detto che ha pubblicato» non è la prova. La prova è il record on-chain più un controllo indipendente. Puoi eseguire quel controllo con lo strumento da riga di comando cardanowall open source oppure verificare un record a mano — nessuno dei due richiede che il tuo gateway sia in funzione.

Che relazione c'è con CardanoWall?

CardanoWall è il prodotto ospitato e curato, e l'operatore di riferimento per lo standard. Il self-hosting è la via dell'indipendenza. Le due cose non sono in contrasto.

Un utente può iniziare su CardanoWall, passare più avanti a un gateway self-hosted, o usare entrambi per flussi di lavoro diversi. Uno sviluppatore può costruire un prodotto sul modello del gateway. Un'azienda può tenere CardanoWall ospitato per i team più semplici, gestendo al contempo il proprio gateway per l'automazione regolamentata. Lo strato condiviso sotto a tutto questo è Label 309 — aperto, neutrale rispetto al fornitore, e identico on-chain chiunque pubblichi.

In breve

Gestisci il tuo gateway quando vuoi far funzionare tu stesso il servizio di pubblicazione. Guadagni il controllo su finanziamento, account, margini, API key, infrastruttura e policy — e ti assumi la responsabilità di disponibilità, sicurezza, wallet, storage, monitoraggio e aggiornamenti.

CardanoWall ospitato è comodità. Il self-hosting è controllo. In entrambi i casi i record di prova restano standard.

Approfondimenti

Lo standard aperto: label309.org.
Il gateway, gli SDK e la CLI, tutti open source (Apache-2.0): github.com/cardanowall.
Lo standard dei metadati è stato sottoposto al processo CIP di Cardano ed è in revisione: la pull request della proposta.
Che cos'è un gateway Label 309?
Label 309 è open source