Fondamenti della finalità

Perché “completato” richiede una definizione

Nel linguaggio comune, un pagamento è completato quando le parti ritengono che l’obbligazione sia stata adempiuta. In un sistema di asset digitali, diversi traguardi possono essere definiti “completati”: un wallet ha firmato una transazione; un servizio l’ha accettata; i partecipanti alla rete l’hanno ricevuta; un registro l’ha inclusa; è stata soddisfatta una specifica regola di finalità; oppure un’istituzione ricevente ha accreditato il cliente. Questi eventi possono verificarsi in momenti diversi e avere conseguenze giuridiche diverse. Un rapporto competente indica sempre quale evento è stato osservato.

La finalità è il grado in cui una transazione o una transizione di stato è considerata conclusa. La finalità tecnica riguarda la capacità del sistema di sostituire o annullare la cronologia registrata in base alle proprie regole. La finalità operativa riguarda le politiche interne di un servizio, ad esempio il momento in cui vengono accreditati i depositi. La finalità giuridica riguarda il momento in cui la legge applicabile riconosce l’adempimento o l’irrevocabilità di un’obbligazione. Un sistema può raggiungere questi traguardi in momenti diversi. Pertanto, la frase “le transazioni blockchain sono irreversibili” è troppo generica senza importanti precisazioni.

La conferma non è una garanzia universale

In alcune blockchain, una transazione è inizialmente visibile come invio in sospeso, poi compare in un blocco e successivamente si consolida sempre più man mano che vengono aggiunti altri blocchi. Il numero di conferme viene spesso usato come indicazione pratica della profondità di inclusione. Protocolli diversi possono usare altre terminologie o messaggi espliciti di finalizzazione. Un servizio può scegliere la propria politica di accredito, perciò transazioni identiche possono diventare disponibili in momenti diversi per destinatari diversi.

Una soglia di una, diverse o più conferme è una scelta di policy che dipende dalla rete, dall’importo, dal modello di minaccia e dai requisiti operativi. Non dovrebbe essere applicata acriticamente a sistemi diversi come regola di sicurezza universale. Alcuni registri prevedono condizioni di finalità deterministica o economica definite dal protocollo; altri offrono un livello di certezza che aumenta progressivamente, anziché un singolo momento assoluto. I dettagli su come una rete seleziona i blocchi e garantisce l’accordo saranno trattati nel modulo successivo; qui l’attenzione è rivolta all’interpretazione dello stato osservabile da operatori e revisori.

Fork: significati diversi

Il termine fork può descrivere due fenomeni diversi. Un fork del software o del protocollo si verifica quando un progetto o una comunità modifica le regole o il software della rete, talvolta creando una rete che continua a esistere separatamente. Un fork temporaneo della chain si verifica quando diversi partecipanti osservano momentaneamente storie candidate diverse, compatibili con le regole pertinenti. Non si tratta dello stesso evento. Una modifica del protocollo può essere ampiamente coordinata senza provocare una divisione duratura, mentre una divergenza temporanea nella cronologia registrata può verificarsi senza che nessuno proponga un cambiamento nella governance del progetto.

Un hard fork descrive in genere una modifica delle regole non compatibile con le versioni precedenti per i partecipanti interessati, mentre un soft fork descrive un tipo di modifica delle regole progettato per restare compatibile con determinati comportamenti di convalida precedenti. Si tratta di definizioni operative di alto livello; la compatibilità esatta dipende dalla modifica e dal comportamento dei nodi. I fork possono derivare da aggiornamenti pianificati, disaccordi, guasti o registrazioni concorrenti. La loro rilevanza dipende dal fatto che utenti, fornitori di servizi e operatori convergano su un unico sistema che prosegue oppure mantengano sistemi separati.

Riorganizzazioni e relative conseguenze

Una riorganizzazione della chain, o reorg, è la sostituzione locale di una cronologia del registro precedentemente accettata con una cronologia alternativa valida. Una transazione che sembrava inclusa può diventare non confermata, essere inclusa successivamente in una posizione diversa oppure entrare in conflitto con un’altra transazione. Il fatto che un servizio abbia mostrato una transazione in un blocco non garantisce, di per sé, che l’osservazione rimanga invariata in ogni circostanza. Nel documentare un’osservazione, gli analisti dovrebbero conservare la data e l’ora, la chain o la rete, l’identificativo del blocco, l’identificativo della transazione e ogni stato dichiarato.

Un semplice scenario illustra il rischio. Un destinatario vede una transazione in un blocco e rilascia immediatamente i beni. In seguito, la vista locale cambia e mostra una cronologia valida diversa, che non include lo stesso trasferimento. Il destinatario si trova quindi coinvolto in una controversia, anche se l’osservazione iniziale era autentica al momento in cui è stata fatta. Ciò non significa che sia probabile che ogni transazione venga sostituita, ma dimostra perché un destinatario dovrebbe definire una politica di accettazione adeguata al proprio sistema e alla propria esposizione al rischio.

Le riorganizzazioni sono spesso discusse in relazione a reti la cui cronologia accettata può cambiare temporaneamente. La loro possibilità e profondità dipendono dalla progettazione della rete e dalle condizioni. Possono derivare da normali blocchi concorrenti o da interruzioni più gravi. Una dashboard può indicare un evento come “annullato” anche se il meccanismo effettivo è stato una riorganizzazione del registro, un rollback dell’applicazione, un rimborso o una rettifica contabile interna. Descrizioni precise evitano confusione inutile nei rapporti sugli incidenti.

Confini operativi e giuridici

Anche le registrazioni tecnicamente concluse non risolvono ogni controversia del mondo reale. Un tribunale potrebbe ordinare a un intermediario di restituire una proprietà, un custode potrebbe congelare un conto oppure un emittente potrebbe invalidare una pretesa contrattuale in base alla legge applicabile. Queste azioni non comportano necessariamente la riscrittura della blockchain. Viceversa, una cronologia tecnicamente reversibile non significa che ogni inversione sia lecita o che un cliente possa pretenderla. Le capacità tecniche, i termini contrattuali e i rimedi giuridici dovrebbero essere analizzati separatamente.

Nei sistemi del settore pubblico, la finalità può interagire anche con la conservazione dei documenti e la responsabilità. Un ufficio pubblico dovrebbe decidere se una marca temporale registrata è autorevole, quali prove giustificano l’accettazione, chi può correggere registrazioni errate e quale procedura documenta le correzioni. In un registro permissioned, l’autorità di un amministratore può differire dal comportamento definito dal protocollo di una rete pubblica. Il termine “immutabile” dovrebbe essere considerato un’affermazione che richiede una spiegazione specifica di chi può modificare cosa e in quali circostanze.

Lista di controllo per la rendicontazione pratica

1. Identificare la rete esatta e l’identificativo pertinente della transazione o della registrazione.
2. Registrare se la transazione è stata soltanto inviata, inclusa, confermata o finalizzata secondo una regola identificata.
3. Conservare l’ora dell’osservazione e la fonte dei dati, invece di presentare la visualizzazione di un’interfaccia come un fatto immutabile.
4. Distinguere una riorganizzazione da un rimborso, uno storno, un’azione di uno smart contract o una rettifica contabile interna.
5. Descrivere le conseguenze distinte del regolamento contrattuale o giuridico, se pertinenti.

Un rapporto conciso sullo stato potrebbe indicare: “All’ora di osservazione registrata, la transazione risultava inclusa nel blocco X sulla rete Y, con N blocchi successivi visibili. Il servizio ricevente non aveva ancora contrassegnato il deposito come disponibile.” In questo modo non si esagerano le garanzie tecniche né i diritti del cliente. Un rapporto successivo può aggiornare lo stato conservando la registrazione precedente. Questa precisione è importante per la verifica delle prove, la riconciliazione operativa e le comunicazioni pubbliche in caso di ritardi di un servizio.

Non confondere l’ordine delle transazioni con la legittimità morale o giuridica. Una rete può finalizzare un trasferimento che utilizza credenziali rubate e un’istituzione può registrare una rettifica lecita al di fuori di quella rete. Perciò, controlli efficaci iniziano prima dell’invio, proseguono durante il monitoraggio e l’accettazione e includono la gestione delle eccezioni. La finalità dovrebbe essere un elemento della governance e della gestione del rischio, non un sostituto dell’autorizzazione, della verifica dell’identità o delle procedure per la risoluzione delle controversie.

In vista dell’esame: Distinguere invio, inclusione, conferma, finalità tecnica, accredito operativo e regolamento giuridico; spiegare le differenze tra un fork del protocollo e una riorganizzazione della chain.