💻 computer science

Safety and Liveness of Cross-Domain State Preservation under Byzantine Faults: A Mechanized Proof in Isabelle/HOL

Questo articolo presenta una prova meccanizzata in Isabelle/HOL che stabilisce garanzie sia di sicurezza che di liveness per la preservazione dello stato regolatorio cross-domain sotto guasti bizantini, utilizzando un framework riutilizzabile di sette locale generiche istanziate contro un modello completo di requisiti regolatori finanziari globali.

Autori originali: Jinwook Kim

Pubblicato 2026-06-01

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Jinwook Kim

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un mondo in cui gli asset digitali (come azioni o immobili tokenizzati) possono muoversi liberamente tra diversi "quartieri" (blockchain) e "registri cartacei" (sistemi off-chain). Il problema è: se un giudice nel Quartiere A congela un asset, questo congelamento deve avvenire istantaneamente e perfettamente anche nel Quartiere B, nel Quartiere C e nel registro cartaceo. Se non accade, i cattivi attori potrebbero praticare l'"arbitraggio regolamentare", nascondendo gli asset in luoghi in cui le regole non sono applicate.

Questo documento è una dimostrazione matematica che un sistema specifico per il movimento di questi asset è sia sicuro (non commette mai errori) che vivo (non si blocca mai), anche se alcuni partecipanti cercano di sabotarlo.

Ecco la suddivisione utilizzando analogie semplici:

1. L'Obiettivo: La "Staffetta Perfetta"

Pensate al sistema come a una corsa a staffetta in cui il testimone è un "stato regolamentare" (come "Congelato" o "Attivo").

La Sfida: Quando un corridore (una blockchain) cambia il colore del testimone, tutti gli altri corridori della squadra devono vedere istantaneamente lo stesso colore.
Il Rischio: Se un corridore mente, dimentica o si blocca, l'intera corsa potrebbe fermarsi, o il testimone potrebbe finire per avere due colori diversi contemporaneamente.

2. Le Due Grandi Vittorie (Sicurezza e Vitalità)

Gli autori hanno dimostrato due cose riguardo al loro sistema:

A. Sicurezza: Lo "Specchio Indistruttibile"

Cosa significa: Se il sistema funziona, il risultato è sempre coerente. Se la Catena A dice "Congela", la Catena B deve dire "Congela". Non c'è ambiguità.
L'Analogia: Immaginate un set di specchi magici. Se mettete una palla rossa davanti allo Specchio A, lo Specchio B, lo Specchio C e il registro cartaceo mostreranno tutti una palla rossa. Non mostreranno mai una palla blu e non saranno mai in disaccordo.
La Dimostrazione: Gli autori hanno costruito una "mappa" (chiamata locale) che dimostra che questo riflesso avviene perfettamente, anche se le catene parlano lingue diverse (vocabolari tecnici differenti) o se l'asset si sta muovendo tra una blockchain e un database cartaceo. Hanno dimostrato che non importa come si rimescoli l'ordine delle operazioni, l'immagine finale è sempre la stessa.

B. Vitalità: Il "Meccanismo Anti-Blocco"

Cosa significa: Il sistema non si blocca mai, anche se alcuni partecipanti sono "Bizantini" (un termine elegante per indicare nodi malevoli o guasti che mentono, ritardano i messaggi o rifiutano di lasciare andare gli asset).
L'Analogia: Immaginate un gruppo di persone che cerca di far passare una scatola pesante attraverso un corridoio stretto.
- Il Problema: Un malintenzionato potrebbe afferrare la scatola e rifiutarsi di lasciarla andare, bloccando tutti gli altri.
- La Soluzione: Il sistema ha un "timeout" integrato (come una botola a molla). Se qualcuno tiene la scatola troppo a lungo, il sistema la strappa automaticamente dalle sue mani e la passa alla persona successiva.
- La Dimostrazione: Hanno dimostrato matematicamente che anche se fino a 1/3 delle persone sta cercando di bloccare il corridoio, la scatola arriverà sempre a destinazione. Nessun asset rimarrà mai bloccato per sempre.

3. Il "Trucco Magico": Combinare i Due

Di solito, le dimostrazioni di sicurezza assumono che tutti siano onesti. Le dimostrazioni di vitalità assumono che alcune persone siano cattive.

Il Trucco del Documento: Hanno combinato i due. Hanno dimostrato che il "Meccanismo Anti-Blocco" (Vitalità) è così forte da correggere l'assunzione di "Persone Oneste" richiesta dalla "Sicurezza".
Il Risultato: Non c'è bisogno di fidarsi di nessuno. Anche con attori malvagi, il sistema è garantito per essere coerente e in movimento.

4. Il Toolkit: "Mattoncini Lego" per la Matematica

Gli autori non hanno costruito questa dimostrazione solo per una specifica blockchain. Hanno creato 7 mattoncini riutilizzabili (chiamati locali in Isabelle/HOL).

Come funziona: Questi mattoncini sono generici. È possibile agganciarli a qualsiasi sistema (una banca, una catena di approvvigionamento, un gioco) per ottenere istantaneamente le stesse garanzie di sicurezza e vitalità.
Test nel mondo reale: Non hanno lasciato i mattoncini nella scatola. Li hanno agganciati a tre scenari molto diversi e reali per dimostrare che funzionano:
1. Linguaggi Diversi: Una catena che parla solo "Congela" contro una catena che parla "Congela" e "Scongela".
2. Mondi Diversi: Una blockchain rispetto a un complesso documento legale off-chain (DAML).
3. Il Motore di Consenso: Il meccanismo di voto specifico utilizzato per decidere chi si muove successivamente.

5. Cosa NON è

Per chiarezza sui limiti del documento:

Non verifica se un giudice specifico abbia effettivamente il diritto legale di congelare un asset. Verifica solo che, se viene ordinato un congelamento, questo avvenga correttamente ovunque.
Non prova che il codice informatico (Rust/Solidity) sia privo di bug; prova che il modello matematico del sistema è solido.
Non gestisce il caos di una rete che aggiunge o rimuove costantemente nuove catene mentre è in funzione (questo è un lavoro futuro).

Riassunto

Questo documento è un certificato matematico di fiducia. Dice: "Abbiamo costruito un sistema in cui le regole regolamentari (come il congelamento degli asset) sono applicate perfettamente in mondi diversi. Anche se alcuni partecipanti cercano di romperlo, il sistema possiede un meccanismo di autocorrezione che assicura che le regole vengano seguite e che il sistema non si blocchi mai."

Ci sono riusciti scrivendo 3.215 righe di codice in un assistente alla dimostrazione (Isabelle/HOL che un computer ha controllato passo dopo passo per garantire che non ci fossero falle logiche.

Riepilogo Tecnico: Sicurezza e Liveness della Preservazione dello Stato Cross-Domain sotto Guasti Bizantini

1. Definizione del Problema

Il documento affronta la sfida critica di garantire la coerenza degli stati di conformità normativa per gli asset tokenizzati che operano attraverso reti blockchain eterogenee e registri off-chain. Senza garanzie formali, l'arbitraggio normativo diventa strutturalmente possibile; ad esempio, un ordine di congelamento emesso in una giurisdizione deve essere immediatamente e deterministicamente riflesso in tutti i domini connessi.

Il problema è scomposto in due dimensioni:

Safety (Sicurezza): Garantire che, se viene eseguita una sincronizzazione, lo stato risultante sia coerente in tutti i domini con preservazione strutturale.
Liveness (Vitalità): Garantire che, in un ambiente decentralizzato contenente nodi bizantini (attori malevoli), il processo di sincronizzazione proceda effettivamente, evitando deadlock e starvation.

I lavori precedenti non hanno verificato formalmente entrambe le proprietà simultaneamente in un unico framework, né hanno verificato proprietà di consenso specifiche per la regolamentazione (come il determinismo delle priorità e l'assenza di deadlock degli asset) utilizzando Isabelle/HOL.

2. Metodologia

Gli autori impiegano un approccio di prova meccanizzata utilizzando Isabelle/HOL. Lo sviluppo consiste in 3.215 righe di codice distribuite in quattro file di teoria, costruiti senza l'uso di sorry o oops (assunzioni non provate).

2.1 Modelli di Sistema e di Minaccia

Modello di Sistema: Il sistema comprende un insieme finito di domini (chain/registri) che condividono una struttura di macchina a stati. La sincronizzazione è modellata come un'operazione atomica che prevede verifica, validazione, acquisizione del lock, aggiornamento dello stato e rilascio del lock.
Modello di Minaccia:
- Proprietà 1 (Safety): Inizialmente assume nodi onesti e canali affidabili.
- Proprietà 2 (Liveness): Rilassa l'assunzione di nodi onesti per consentire fino a $f < n/3$ nodi bizantini. I nodi bizantini possono trattenere il rilascio dei lock o agire in modo malevolo.
- Combinata: La Proprietà 2 scarica l'assunzione di "nodi onesti" della Proprietà 1, producendo una garanzia incondizionata.

2.2 Modello di Transizione dello Stato Regolatorio

Il modello formale si basa sul framework Regulatory Compliance Protocol (RCP), che sistematizza 31 requisiti provenienti da 15 autorità finanziarie globali.

Stati: Cinque stati regolatori (ACTIVE, FROZEN, SEIZED, CONFISCATED, RESTRICTED).
Azioni: Sette azioni regolatorie (FREEZE, SEIZE, CONFISCATE, RESTRICT, UNFREEZE, UNRESTRICT, RELEASE).
Vincoli: Il modello impone specifici vincoli legali, come l'esclusione delle transizioni "SEIZED → FROZEN" (poiché il sequestro è un vincolo legale più forte del congelamento) e la natura terminale dello stato CONFISCATED.

2.3 Infrastruttura di Verifica: Generic Locales

Il nucleo della metodologia risiede nella definizione di sette generic locale, indipendenti dal dominio in Isabelle/HOL. Questi locale fungono da infrastruttura di verifica riutilizzabile. I teoremi provati all'interno di questi locale vengono ereditati automaticamente da qualsiasi dominio concreto che li istanzia tramite il meccanismo di interpretazione di Isabelle.

Locale di Safety (4):
1. state_machine: Definisce stati finiti, azioni e transizioni deterministiche.
2. state_preservation: Stabilisce una condizione di naturalità in cui la sincronizzazione commuta con le transizioni di stato (omomorfismo).
3. symmetric_state_preservation: Aggiunge mappe inverse per garantire la preservazione bidirezionale del roundtrip.
4. multi_domain_preservation: Generalizza la coerenza a un insieme arbitrario di domini finiti (coerenza N-domain) e garantisce l'isolamento per singolo asset.
Locale di Liveness (3):
1. priority_system: Garantisce la selezione deterministica delle azioni tramite priorità iniettive.
2. deadlock_free_locking: Assicura che nessuna risorsa rimanga bloccata indefinitamente tramite il rilascio forzato basato su timeout.
3. fair_leader_system: Garantisce la starvation freedom sotto uno scheduling periodico di un leader onesto.

3. Contributi Chiave

3.1 Prova Meccanizzata di Safety (Proprietà 1)

Il documento estende il pattern Merkle Functor (precedentemente limitato all'integrità dei dati unidirezionale in un singolo dominio) a un framework cross-domain, bidirezionale e multi-dominio.

Bidirectional Roundtrip: Dimostra che le transizioni di stato sono riflesse fedelmente in entrambe le direzioni tra i domini.
Coerenza N-Domain: Dimostra che dopo una sincronizzazione su un dominio, tutti i domini connessi raggiungono lo stesso stato risultante.
Isolamento Per-Asset: Dimostra che la sincronizzazione su un asset non influisce sullo stato di altri asset.
Istanze Concrete: Gli autori forniscono testimoni concreti per garantire che i locale non siano soddisfatti in modo vacuo:
- Istanza di Escalation: Un'istanza di azioni eterogenee in cui una chain supporta solo azioni di escalation (FREEZE, SEIZE, ecc.) mentre l'altra supporta l'intero set, provando la preservazione strutturale attraverso vocabolari differenti.
- Istanza di Layer-Crossing: Un ponte bidirezionale tra un enum reg_state on-chain e un record di permessi DAMM off-chain, provando l'iniettività e l'assenza di perdita di informazioni.

3.2 Prova Meccanizzata di Liveness (Proprietà 2)

Questa è la prima utilizzazione di Isabelle/HOL da sola per verificare la liveness del consenso BFT in un contesto blockchain.

Determinismo: Gli azioni regolatorie conflittuali sono risolte tramite un ordine totale su chiavi di priorità (livello di autorità, timestamp, severità, ID del nodo).
Deadlock Freedom: Dimostra che anche se i nodi bizantini trattengono i rilasci dei lock, il meccanismo di timeout assicura che il lock scada entro un tempo limitato.
Starvation Freedom: Dimostra che sotto un limite di fairness (garantendo un leader onesto entro $k$ epoche), tutte le richieste pendenti vengono eventualmente elaborate.

3.3 Scarico delle Assunzioni (Garanzia Combinata)

Il documento dimostra un pattern di ragionamento assume-guarantee. La Proprietà 2 scarica l'assunzione di "nodi onesti" richiesta dalla Proprietà 1. Dimostrando che il sistema rimane vivo e deterministico anche in presenza di guasti bizantini ( $f < n/3$ ), la garanzia di sicurezza condizionata viene elevata a una garanzia incondizionata: la preservazione dello stato cross-domain è mantenuta anche in presenza di nodi bizantini.

4. Risultati e Artefatti

Artefatti della Prova: Lo sviluppo include otto interpretazioni concrete di locale (che coprono tutti i sette locale generici) insieme a un'istanza parametrica multi-dominio.
Modello Regolatorio: Il modello copre 31 requisiti regolatori mappati su 5 stati e 7 azioni.
Disponibilità: Tutti gli artefatti sono pubblicamente disponibili su GitHub e sono stati sottoposti all'Archive of Formal Proofs (AFP) per la revisione.
Guida al Design: Le prove fornis cuiiscono vincoli di parametrizzazione specifici per l'implementazione (ad esempio, $n \ge 3f + 1$ , timeout positivi, limiti di fairness) che si traducono direttamente in una razionale di design matematico per i sequencer decentralizzati.

5. Significato e Rivendicazioni

Il documento rivendica importanza in tre aree primarie:

Novità nella Verifica Formale: È il primo lavoro a verificare formalmente sia la safety che la liveness simultaneamente per le transizioni di stato regolatorio cross-domain. È anche il primo a verificare proprietà di consenso specifiche per la regolamentazione (determinismo delle priorità, deadlock freedom degli asset regolatori) in qualsiasi strumento.
Avanzamento Metodologico: Utilizzando una gerarchia di locale generici, gli autori forniscono un'infrastruttura di verifica riutilizzabile che è indipendente dal dominio. Ciò consente di applicare le stesse prove di safety e liveness ad arbitrarie domini (ad esempio, DeFi, database distribuiti) semplicemente istanziando i locale.
Collegamento tra Teoria e Pratica: Il lavoro va oltre la verifica dell'astratto consenso (come agreement/validity) per affrontare vincoli regolatori specifici del dominio. Colma esplicitamente il divario tra una macchina a stati teorica e un modello di conformità regolatoria, fornendo una "guida di design" per i parametri di implementazione derivati direttamente dalle prove.

Gli autori notano esplicitamente le limitazioni: il modello non verifica le caratteristiche specifiche della chain (gas, tempi di blocco), non prova il raffinamento formale verso codice Rust/Solidity e assume un sistema chiuso (l'arrivo dinamico di richieste è un lavoro futuro). L'attuale framework stabilisce i locale e le istanze fondamentali, ma non ha ancora formalizzato le leggi dei funtori della teoria delle categorie (identità e composizione), che sono riservate a lavori futuri per raggiungere il pieno status di "funtore".