Che cosa vogliamo costruire
L'obiettivo finale è un registro specializzato per la logistica capace di attestare che un evento applicativo esisteva in una certa forma e in una certa sequenza. Un evento può rappresentare, per esempio, il passaggio di un ordine a uno stato successivo oppure la pubblicazione di un'evidenza operativa. La chain conserva un envelope minimo e deterministico: identificativo opaco, tipo di evento, versione dello schema, marcatura temporale, collegamento crittografico all'evento precedente e digest del contenuto autorizzato.
Questa architettura permette a un processo indipendente di confrontare la sorgente operativa con la prova registrata. Se un record manca, compare due volte oppure produce un hash diverso, la riconciliazione apre un'anomalia. La chain non deve conoscere nome, indirizzo, email, numero di telefono, contenuto del pacco, prezzo dettagliato o credenziali. I documenti restano cifrati off-chain; sulla chain può comparire soltanto un riferimento opaco e il relativo digest, quando il caso d'uso è stato approvato.
Vector Chain non nasce come criptovaluta. Non sono previsti token destinati al pubblico, wallet cliente o meccanismi speculativi. L'utilità valutata è tecnica: evidenza, auditabilità e coordinamento tra soggetti che non dovrebbero dipendere dalla modifica silenziosa di un unico archivio.
Perché una chain dedicata
Un database tradizionale resta la scelta corretta per profili, indirizzi, prezzi, pagamenti e operazioni ad alta frequenza. Offre query, correzioni, controlli di accesso e cancellazioni che una chain non dovrebbe imitare. Il valore di un trust layer emerge invece quando più sistemi devono verificare la stessa sequenza senza concedere a uno solo la possibilità di riscrivere retroattivamente la prova.
Una chain applicativa consente di limitare il protocollo alle regole realmente necessarie. Il consenso ordina gli envelope e verifica transizioni deterministiche; non chiama carrier, mappe, banche o provider di pagamento. Le dipendenze esterne restano nel layer applicativo di VECTOR, dove possono essere gestite con timeout, retry e procedure di recupero. Questa separazione riduce il rischio che un servizio esterno blocchi il consenso o introduca risultati non riproducibili.
La scelta tecnica attuale usa Cosmos SDK per la macchina a stati e CometBFT per il consenso bizantino. Sono componenti open source studiati separatamente dal prodotto VECTOR. La loro presenza non equivale a una garanzia: versione, configurazione, gestione delle chiavi, topologia, backup e governance devono essere sottoposti a test e revisione indipendente prima di qualsiasi ruolo produttivo.
Riferimento primario per il framework della macchina a stati applicativa.
Riferimento primario per consenso, networking e funzionamento dei nodi.
Architettura attuale, in termini pubblicabili
Il fail-open non significa ignorare un errore. Significa separare disponibilità del servizio e integrità della prova: il cliente può continuare, mentre il sistema conserva l'evento, applica retry limitati e rende visibile l'anomalia agli operatori autorizzati. Una divergenza crittografica è più grave di un ritardo di pubblicazione e deve fermare la proiezione, non il flusso logistico originale.
- 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.
Dove siamo realmente
Sono completati cinque gate: protocollo, ledger deterministico, rete shadow privata, pilot reversibile e continuità operativa. Il controllo live del 14 agosto 2026 ha trovato quattro validatori alla stessa altezza, tre peer per nodo, zero restart e nessun check fallito. La decisione del soak 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à.
Come avanza la roadmap
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.
Principi che non cambiano
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.