Dal pacco alla prova, senza duplicare il dato
Immaginiamo una spedizione che passa da confermata ad affidata al carrier. VECTOR conserva il record operativo completo nel sistema autorizzato; Vector Chain riceve soltanto un envelope minimo: riferimento opaco, tipo di evento, versione, tempo, digest e collegamento alla prova precedente. Chi verifica può confermare integrità e sequenza senza leggere il contenuto originale.
Un controllo indipendente confronta sorgente, outbox e ricevuta. Se una prova manca, compare due volte o genera un digest differente, la riconciliazione apre un'anomalia invece di correggere silenziosamente la storia. Documenti e dati sensibili rimangono cifrati off-chain, dove accesso, rettifica e conservazione possono essere governati correttamente.
Vector Chain non nasce come criptovaluta. Non prevede token pubblici, wallet cliente o meccanismi speculativi. Il valore studiato è operativo: una prova leggibile dalle macchine, verificabile da più soggetti e separata dall'archivio che gestisce il lavoro quotidiano.
Perché non basta chiamarla blockchain
Profili, indirizzi, prezzi e pagamenti appartengono a un database tradizionale: devono poter essere interrogati, corretti e protetti con controlli granulari. Una chain aggiunge valore solo quando più sistemi devono verificare la stessa sequenza senza affidarsi alla modifica retroattiva di un unico archivio. Usarla per tutto sarebbe più lenta, meno privata e tecnicamente ingiustificata.
Per questo il consenso ordina soltanto envelope deterministici. Non chiama carrier, mappe, banche o provider di pagamento. Le dipendenze esterne restano nel layer applicativo, dove timeout, retry e recupero possono essere gestiti senza rendere il consenso dipendente da Internet o da una risposta commerciale.
Il prototipo usa Cosmos SDK per la macchina a stati e CometBFT per il consenso bizantino. Sono fondamenta open source, non una garanzia automatica: configurazione, chiavi, topologia, backup, operatori e governance devono superare verifiche separate prima di ottenere qualsiasi autorità produttiva.
Riferimento primario per il framework della macchina a stati applicativa.
Riferimento primario per consenso, networking e funzionamento dei nodi.
Come protegge il flusso reale
Il principio fail-open non nasconde un errore: separa la disponibilità del servizio dall'integrità della prova. Se la rete shadow è temporaneamente indisponibile, il cliente può continuare e l'evento resta in una coda controllata. Se invece compare una divergenza crittografica, la proiezione viene fermata e segnalata. Il flusso logistico originale non viene riscritto per far sembrare corretta la Chain.
- Rete shadow privata multi-validatore, priva di endpoint pubblico e separata dal percorso cliente.
- Ledger applicativo deterministico che accetta envelope versionati e senza dati personali.
- Transactional outbox: l'evento nasce insieme alla transazione PostgreSQL, evitando pubblicazioni scollegate dalla sorgente.
- Writer idempotente: firma, invia, attende finalità e registra l'evidenza senza duplicare l'evento.
- Reconciler indipendente: confronta sorgente, outbox e chain e segnala assenze, duplicati o divergenze.
- Fail-open controllato: un'indisponibilità della chain non ferma pagamenti, label o spedizioni; l'evento resta in coda per il recupero.
- Health semantico e recupero della mesh: la readiness verifica consenso, peer e avanzamento reale, non soltanto il processo in esecuzione.
- Recovery verificato: snapshot applicativo, restore isolato e state sync hanno riprodotto lo stato della sorgente.
- Archivio centralizzato hash-chained: i log dei quattro validatori sono raccolti senza concedere accesso ai segreti.
- Documenti e dati sensibili off-chain, cifrati e soggetti alle normali regole di accesso e conservazione.
Stato reale, non una percentuale promozionale
Sono completati cinque gate: protocollo, ledger deterministico, rete shadow privata, pilot reversibile e continuità operativa. L'ultimo ciclo verificato ha trovato quattro validatori sincronizzati, tre peer per nodo, zero restart e nessuna divergenza durante il soak. La decisione operativa resta GO.
Sono inoltre riusciti il recovery drill con snapshot e state sync, l'archivio centralizzato hash-chained dei log e la prova isolata della cerimonia tra operatori. Il pacchetto interno della mainnet è pronto al confine di provisioning. Il candidato usato per i test è stato poi disattivato, così da non sostenere capacità inattiva prima dei gate esterni.
Non esiste una mainnet pubblica di Vector Chain e non è stato autorizzato alcun cutover. Audit esterno, custodia indipendente delle chiavi, almeno tre operatori indipendenti, un secondo provider e una cerimonia multiparte restano condizioni obbligatorie. La proiezione verso la chain è disattivata e PostgreSQL mantiene piena autorità.
Una roadmap che può anche tornare indietro
Ogni obiettivo ha un gate tecnico o organizzativo. La barra viene calcolata sul numero di gate completati, non sul tempo trascorso e non sul volume di codice scritto. Un gate può tornare in revisione se un controllo successivo rileva una regressione. Lo stato pubblico viene aggiornato soltanto attraverso una release verificata, così una misura interna temporanea non diventa automaticamente una promessa esterna.
La continuità ha superato il proprio gate con mesh stabile, blocchi recenti, risorse entro soglia e soak senza restart inattesi. Il gate corrente è l'assurance indipendente: restore e log verificabili sono pronti, mentre separazione degli operatori, custodia remota delle chiavi e audit esterno devono ancora essere completati. La testnet con partner non inizierà finché responsabilità, diritto di uscita, aggiornamenti e gestione degli incidenti non saranno definiti per iscritto.
L'ultimo obiettivo non implica che il database debba essere eliminato. Una possibile architettura di produzione può mantenere PostgreSQL per il dato operativo e usare la chain come livello di attestazione. Qualsiasi estensione dell'autorità verrà valutata per dominio, con migrazione reversibile e confronto continuo tra le due rappresentazioni.
Confini pubblici e non negoziabili
Questi limiti sono parte dell'architettura, non una nota commerciale. Servono a preservare privacy, reversibilità e correttezza delle affermazioni pubbliche. La tecnologia verrà adottata soltanto dove aggiunge una prova che un sistema tradizionale, da solo, non può offrire con lo stesso modello di fiducia.
- Nessun dato personale, segreto, payload carrier o dettaglio di pagamento viene scritto on-chain.
- Nessun token pubblico o modello economico speculativo viene introdotto senza un progetto distinto e approvato.
- Nessun flusso cliente attende il consenso della chain durante la fase shadow.
- Nessun nodo validatore espone direttamente un'API pubblica o interroga servizi esterni.
- Nessuna percentuale di avanzamento aumenta senza evidenza associata al gate.
- Nessuna dichiarazione di decentralizzazione viene fatta finché operatori e infrastrutture non sono realmente indipendenti.