Nota storica sull’esperimento Alpha 5 precedente alla ricostruzione, con eventi firmati, ancoraggi contenenti solo hash e collegamenti Railgun. Non descrive la build attuale.
In questa pagina
Cosa è cambiato
Gli eventi operativi sono rappresentati mediante hash di JSON canonico e firme Ed25519 prima di considerare un eventuale ancoraggio pubblico.
Gli ancoraggi conservano hash anziché payload privati, mentre i record di collegamento dei pagamenti contengono hash di accettazione, nullifier e impegni crittografici.
La stessa traccia di eventi collega approvazioni, contratti, traguardi, variazioni ai lavori, fatture, richieste di pagamento e ricevute, senza rendere la blockchain l’archivio principale.
I record locali restano la fonte di riferimento
Contratti, traguardi, approvazioni, variazioni ai lavori, fatture, richieste di pagamento e ricevute restano record applicativi. Il livello di prova deriva rappresentazioni canoniche degli eventi da quello stato; non trasferisce il database operativo su una blockchain pubblica.
Ogni evento può essere serializzato in modo deterministico, sottoposto a hash e firmato prima di considerare un ancoraggio esterno. Questo ordine offre al flusso locale una storia verificabile senza far dipendere l’operatività ordinaria dall’infrastruttura pubblica di regolamento.
La divulgazione è separata per livello
Payload privati, firme, ancoraggi hash e collegamenti dei pagamenti sono oggetti distinti. Un ancoraggio pubblico può conservare un digest senza pubblicare contratto, record immobiliare, file di prova o identità del nucleo familiare sottostante.
Il record di pagamento collega l’accettazione del traguardo al regolamento mediante impegni crittografici e nullifier. Si stabilisce così continuità tra un’unità di lavoro approvata e un trasferimento privato, evitando una cronologia dei pagamenti in chiaro.
La verifica segue il flusso di lavoro
La dichiarazione utile non è soltanto che un evento sia stato firmato. La traccia deve conservare l’ordine tra relazione, contratto, prove del traguardo, accettazione, richiesta di pagamento, collegamento al regolamento e ricevuta.
Questo rende visibili i confini del guasto: un evento non firmato, un hash di accettazione non corrispondente o un record di collegamento assente non possono essere presentati come un flusso di pagamento verificato e completo. L’interfaccia può restare utilizzabile mostrando esattamente quale fase di prova manca.
Nota di ingegneria
Questa architettura appartiene al ramo archiviato precedente alla ricostruzione. L’applicazione attuale usa un’interfaccia Next.js, un’API Go, PostgreSQL, allegati privati e inviti ai fornitori con accesso limitato; l’integrazione operativa di un fornitore di pagamenti resta incompleta.
Provenienza
Questa nota si basa sul codice verificato del ramo archiviato precedente alla ricostruzione, al commit fafa17d. È conservata come testimonianza tecnica e non descrive il prodotto attuale.