Vai al contenuto
Financial Context Wiki

Finalità della blockchain: prove, ipotesi e livelli di regolamento

La finalità è la garanzia specifica di un protocollo che una decisione non venga sostituita senza violare le ipotesi di sicurezza o attivare un recupero eccezionale. Validità, fork choice, prova di finalità, limiti di guasto, dipendenze tra livelli e regolamento applicativo vanno separati.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

La finalità è la garanzia specifica di un protocollo che una decisione accettata, come un blocco, checkpoint o impegno di stato, non venga sostituita senza violare le ipotesi di sicurezza dichiarate o ricorrere a un recupero eccezionale. Non è una proprietà fisica dei byte della transazione né significa soltanto «la transazione è riuscita». Ogni affermazione deve indicare oggetto, rete, versione, prove, modello di guasto e temporale, punto iniziale fidato e osservatore.

Validità, canonicità e finalità sono distinte. Un blocco valido soddisfa le regole di transizione e autorizzazione. Il fork choice seleziona la testa canonica corrente tra candidati validi. La finalizzazione applica un predicato aggiuntivo, come un certificato di commit o un checkpoint finalizzato, a un antenato della testa. Una transazione può riuscire in un blocco valido poi escluso; una testa può essere canonica ma non finalizzata; un evento finalizzato sulla catena sorgente può ancora fallire in un bridge, exchange o applicazione.

Il proof of work offre solitamente regolamento probabilistico, non un bit esplicito di finalità: accumulando lavoro valido sopra un blocco, sostituirlo diventa in genere meno probabile e più costoso sotto le ipotesi di hash power e rete. Un protocollo BFT può offrire finalità deterministica condizionale: dopo un certificato valido, due decisioni in conflitto non possono essere entrambe committed se il peso guasto resta sotto il limite dimostrato. In PoS può essere anche responsabile o economica, perché voti conflittuali identificano peso sottoponibile a slashing. Sono prove diverse, non sinonimi.

Nessun protocollo rende la storia assolutamente immutabile. Compromissione catastrofica di chiavi, violazione del limite di guasto, bug client, transizioni invalide accettate dalle implementazioni, governance o recupero sociale possono oltrepassare il modello. «Finalizzato» deve significare che il normale percorso di riorganizzazione non può sostituire quella decisione sotto tali ipotesi; recupero eccezionale e autorità vanno documentati a parte.

Come analizzare la finalità

  1. Definire oggetto e ambito. Identificare transazione, blocco, checkpoint, state root, messaggio cross-chain o prelievo; registrare catena, rete, livello, versione, altezza o slot, hash e checkpoint fidato.
  2. Verificare la validità prima dello stato. Rieseguire o validare altrimenti transizione e ascendenza. Quorum, punteggio di lavoro o badge dell’interfaccia non possono finalizzare un oggetto invalido secondo le regole effettive.
  3. Separare selezione della testa e finalizzazione. Ricostruire fork choice e percorso canonico, quindi trovare l’antenato finalizzato o committed. Registrare se è solo osservato, confermato, giustificato, sicuro, committed o finalizzato.
  4. Riprodurre le prove. In PoW verificare header, target e chainwork cumulato sopra il blocco. Nei protocolli di voto verificare idoneità, snapshot dei pesi, dominio, sorgente e destinazione, altezza, round, disuguaglianza di quorum, firme, lock e ascendenza del certificato.
  5. Dichiarare ipotesi di safety e liveness. Specificare peso bizantino o offline, sincronia, ritardo, equivocazione, compromissione di chiavi, correlazione client, cambi di membri, disponibilità dello slashing e comportamento allo stallo. Un arresto può preservare safety perdendo liveness.
  6. Mappare ogni livello di regolamento. Seguire ricezione del sequencer, esecuzione L2, pubblicazione dati, inclusione L1, finalità L1, fine di prova o disputa, esecuzione bridge, accredito exchange e azione applicativa. Etichette simili tra livelli possono indicare predicati diversi.
  7. Definire e monitorare una policy applicativa. Stabilire prove accettabili per valore e conseguenza, interrogare nodi indipendenti, gestire riorganizzazioni e allarmi di finalità conflittuale, sospendere azioni irreversibili se cadono le ipotesi e registrare chi autorizza il recupero.

Il numero di conferme è un’osservazione, non una regola universale. In Bitcoin Core, confirmations dipende dalla posizione del blocco nella catena attiva, mentre chainwork indica il lavoro atteso cumulato. In Ethereum, scelta della testa LMD-GHOST e giustificazione e finalizzazione Casper FFG sono transizioni separate. In CometBFT, un commit richiede oltre due terzi del potere in precommit per lo stesso blocco, altezza e round. Ogni stato va interpretato nel proprio protocollo.

Esempi calcolati

1. Regolamento PoW probabilistico

Il white paper Bitcoin modella un attaccante con quota hash q=0.10 che tenta di raggiungere la catena onesta dopo un vantaggio z=6. Con tentativi hash indipendenti e ipotesi di Poisson, la probabilità calcolata è:

P=0.0002428 = 0.02428%

È piccola, non zero, e non è una garanzia universale di «sei conferme». La policy reale considera valore, chainwork osservato, concentrazione hash, rischio eclipse o partizione, incentivi delle fee e credibilità della quota costante del modello.

2. Giustificazione e finalizzazione Ethereum

Si consideri un percorso semplificato di checkpoint consecutivi con saldo effettivo attivo totale 100. Voti 67/100 che collegano il checkpoint giustificato C_0 al target C_1 raggiungono almeno due terzi e giustificano C_1. Un successivo link valido 67/100 da C_1 al figlio diretto C_2 può finalizzare C_1 secondo la regola Casper FFG applicabile.

La testa può proseguire oltre C_2 mentre la parte nuova resta non finalizzata. Se il saldo 34 è offline, rimane 66 e la finalizzazione immediata si blocca anche se fork choice e produzione continuano. Dopo oltre quattro epoch senza finalità, l’inactivity leak di Ethereum penalizza la mancata partecipazione affinché una supermaggioranza attiva possa recuperarla.

3. Safety e liveness in CometBFT

Siano il potere totale 100 e il requisito >2/3 precommit per lo stesso blocco, altezza e round. Il potere intero 67 esegue il commit. Due insiemi di 67 si intersecano per almeno 67 + 67 - 100 = 34. Con peso bizantino sotto un terzo e validatori onesti che rispettano i lock, due commit conflittuali non possono formarsi.

Se il peso 34 non è disponibile, solo 66 può votare e non si forma un commit. Il protocollo può preservare safety mentre la finalità si arresta. «Nessun blocco finalizzato conflittuale» e «i nuovi blocchi continuano a finalizzarsi» sono garanzie diverse.

4. Stati OP Stack e tempi di prelievo

Un sequencer OP Stack può esporre inizialmente un blocco L2 come unsafe. Quando è interamente derivabile dai dati della catena L1 canonica corrente, il nodo rollup può marcarlo safe. Quando gli input L1 corrispondenti ricevono il segnale di finalità L1, il blocco L2 derivato può diventare finalized.

Lo stato riguarda la derivazione da input finalizzati. Un output optimistic rollup o prelievo L2-L1 ha un proprio processo di prova e disputa e può dirsi «finalizzato» solo dopo la condizione di contestazione. Un’app che riduce conferma del sequencer, inclusione dati L1, finalità del consenso L1 ed esecuzione del prelievo a un solo istante può liberare valore troppo presto.

Rischi ed errori di revisione

Definizione e prove

  • Chiamare «finale» ogni esecuzione, ricevuta, conferma, checkpoint o badge riuscito.
  • Omettere catena, rete, versione, hash dell’oggetto, altezza o slot, livello e osservatore.
  • Trattare la testa del fork choice come antenato finalizzato o presumere che la finalizzazione scelga la testa più recente.
  • Contare blocchi o minuti senza validare ascendenza, target, lavoro, voti o certificati.
  • Confrontare «due conferme» o «dieci minuti di finalità» tra protocolli con prove e guasti diversi.
  • Verificare firme senza idoneità, peso, dominio, sorgente, target, altezza e round.
  • Equiparare costo economico, prova slashable ed effettiva applicazione della sanzione.
  • Descrivere rischio probabilistico come zero o safety deterministica condizionale come irreversibilità assoluta.

Guasti di protocollo e operativi

  • Superare il limite bizantino, perdere peso online necessario alla liveness o nascondere una partizione.
  • Lasciare divergere le implementazioni su validità, fork choice, transizioni, arrotondamento del quorum o ascendenza del certificato.
  • Accettare voti, commit, checkpoint o dati di weak subjectivity obsoleti, ripetuti o di altra rete.
  • Concentrare chiavi, stake, hash power, client, relay, cloud o viste RPC dietro identità nominalmente distinte.
  • Presumere che inactivity leak, timeout o view change ripristini subito e senza conseguenze il progresso.
  • Non allertare su ritardo di finalità, certificati conflittuali, riorganizzazione profonda, equivocazione o root divergenti.
  • Usare governance d’emergenza o recupero sociale senza documentare autorità, coordinamento, release client e garanzie coinvolte.

Disallineamento tra livelli e applicazione

  • Trattare inclusione del sequencer come safety L2, pubblicazione L1, finalità L1, accettazione prova e prelievo completato insieme.
  • Rilasciare asset bridged prima che evento sorgente e verifica del bridge soddisfino la policy.
  • Accreditare depositi o eseguire trade irreversibili dallo stato di un solo RPC senza riconciliazione indipendente.
  • Presumere che la finalità garantisca verità dell’oracolo, correttezza del contratto, disponibilità dati, solvibilità o regolamento legale.
  • Applicare la stessa soglia fissa a ogni valore, controparte, incentivo d’attacco e costo di recupero.

Idee errate comuni

  • Una transazione riuscita è finale. Il successo descrive una transizione in una storia candidata; canonicità e finalità richiedono altre prove.
  • Più conferme portano esattamente a zero il rischio PoW. La probabilità può calare molto ma resta condizionata e non diventa impossibilità logica.
  • Due terzi significano sempre finalità. Disuguaglianza, messaggio, peso, altezza, round, relazione sorgente-target e lock dipendono dal protocollo.
  • La finalità garantisce che la rete prosegua. La safety può restare intatta mentre partecipazione o connettività insufficienti bloccano nuove finalizzazioni.
  • La finalità L1 completa ogni azione L2 o bridge. Derivazione, prova di validità o frode, finestra di contestazione ed esecuzione destinazione aggiungono tempi e guasti distinti.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...