Vai al contenuto
Financial Context Wiki

Conferme di blocco

Guida basata sulla verifica della profondità di conferma PoW, degli stati safe e finalized di PoS, della sostituzione nel mempool, delle riorganizzazioni e delle politiche di accredito dei depositi.

Aggiornato

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

Risposta diretta

Una conferma di blocco è un’affermazione specifica dell’osservatore e del protocollo: una transazione è inclusa in un blocco della chain canonica corrente dell’osservatore. La comune convenzione inclusiva di Bitcoin Core conta il blocco contenente la transazione come prima conferma. Per altezza di inclusione h e altezza della best chain H, la profondità è H - h + 1. Alcuni servizi mostrano soltanto i discendenti come H - h; occorre quindi dichiarare la convenzione.

La profondità Proof of Work riduce il rischio di riorganizzazione sotto ipotesi esplicite, ma non crea un punto magico di finalità assoluta. I sistemi Proof of Stake possono esporre stati nativi del protocollo. Ethereum distingue latest, safe e finalized; un numero fisso di blocchi, slot o minuti non sostituisce tali etichette. Gli stati rilevato, accreditato, negoziabile e prelevabile di una piattaforma sono politiche interne distinte anche dopo il raggiungimento della soglia della chain.

Attesa prevista
1.2 min
Gamma illustrativa
54s - 1.5 min

I risultati sono approssimazioni didattiche. Escludono regole della sede, tasse, latenza, comportamento degli oracoli e altri parametri specifici del protocollo se non indicati.

Come funziona

  1. Fissa chain e rete, asset, identificatore della transazione, nodo o API, istante di osservazione, modello di consenso e convenzione di conteggio. Verifica destinatario, importo ed eventuale memo o tag prima di trattare un hash corrispondente come pagamento previsto.
  2. Separa firmata, trasmessa, accettata dal mempool locale di un nodo e propagata. I mempool sono viste di policy, non una coda globale di consenso. Controlla stato delle commissioni, antenati non confermati, Replace-by-Fee o sostituzione con lo stesso nonce e spese in conflitto.
  3. Verifica l’inclusione tramite hash del blocco, altezza, indice della transazione e discendenza canonica, non solo tramite altezza o badge dell’explorer. Nelle account chain, esamina anche stato della ricevuta, log e modifica effettiva dello stato; un’esecuzione inclusa può comunque revertire.
  4. Applica il modello di consenso. Per PoW, dichiara la convenzione, calcola la profondità e confronta viste indipendenti di best chain e lavoro cumulato. Per PoS, interroga gli stati nativi head, safe, justified o finalized; non dedurli da una distanza fissa in blocchi o slot.
  5. Registra il ciclo di vita con stati espliciti: creata, trasmessa, accettata nel mempool locale, inclusa, profondità canonica o stato safe/finalized, riorganizzata, reinclusa, sostituita o in conflitto. Una riorganizzazione non garantisce che la transazione originale ritorni in ogni mempool.
  6. Mantieni separato il registro della piattaforma: osservata, soglia di rete raggiunta, accreditata, negoziabile e prelevabile. Applica la policy vigente specifica per asset, rete, importo e incidente; manutenzione, compliance e revisione manuale possono aggiungere ritardi indipendenti.
  7. Confronta nodi o provider indipendenti e continua a monitorare fino allo stato richiesto. Registra hash, altezze, timestamp, etichette RPC e snapshot della policy, e simula sostituzione, riorganizzazione, ritardo della finalità, nodo obsoleto, relay del bridge e indisponibilità della piattaforma.

Esempi svolti

  • Convenzione di conteggio. Una transazione Bitcoin si trova nel blocco canonico h = 900,000 e il tip della best chain è H = 900,005. La profondità inclusiva è 900,005 - 900,000 + 1 = 6 confirmations; un display che conta solo i discendenti riporta 900,005 - 900,000 = 5. La differenza è terminologica se entrambi si riferiscono allo stesso hash e alla stessa discendenza.
  • Riorganizzazione e reinclusione. La transazione ha inizialmente 1 confirmation nel blocco 900,000; poi il blocco esce dalla best chain e il valore torna a 0 se resta valida e senza conflitti. Se viene reinclusa a 900,003 e il tip raggiunge 900,006, la profondità inclusiva è 900,006 - 900,003 + 1 = 4 confirmations. Se un conflitto confermato la sostituisce, Bitcoin Core può invece riportare conferme negative.
  • Le etichette PoS non sono conteggi di blocchi. Supponiamo che una transazione Ethereum sia nel blocco di esecuzione 20,000,000 e che un nodo riporti latest = 20,000,020, safe = 20,000,012 e finalized = 19,999,980, tutti sulla stessa discendenza. La profondità latest numerica è 20,000,020 - 20,000,000 + 1 = 21; la transazione è safe, ma non finalized. Servono discendenza degli hash ed etichette del consenso; le altezze non bastano.
  • Soglia della chain e accredito della piattaforma. La policy richiede 6 confirmations. Un deposito nel blocco 900,000 è a 5/6 quando il tip è 900,004 e raggiunge 6/6 a 900,005. Se poi si applica una 15-minute compliance hold, idoneità on-chain e tempi di accredito, negoziazione o prelievo restano stati distinti; la sospensione non è una settima conferma.

Rischi

  • Esaminare chain, rete o asset sbagliati.
  • Usare hash, destinatario, memo o tag errati.
  • Trattare una transazione firmata ma non trasmessa come pending.
  • Trattare il mempool di un nodo come stato globale della rete.
  • Non rilevare rifiuto per policy, espulsione o mancata propagazione.
  • Ignorare una sostituzione RBF, same-nonce o una spesa in conflitto.
  • Interpretare male antenati, discendenti o package fee non confermati.
  • Mescolare conteggi inclusivi e dei soli discendenti.
  • Fidarsi di un nodo obsoleto, in sincronizzazione o isolato.
  • Confrontare altezze senza verificare hash e discendenza.
  • Perdere conferme in una breve riorganizzazione PoW.
  • Trattare una profondità fissa come sicurezza assoluta per ogni valore e avversario.
  • Confondere tempo trascorso, slot, epoch e blocchi prodotti.
  • Trattare un head block PoS come safe.
  • Trattare un blocco safe come finalized.
  • Non rilevare ritardo della finalità mentre la chain produce ancora blocchi.
  • Trattare un’esecuzione inclusa ma revertita come successo applicativo.
  • Confondere log di token o UI dell’explorer con lo stato risultante.
  • Equiparare rilevamento, accredito, negoziazione e permesso di prelievo.
  • Trattare la conferma sulla source chain come completamento di bridge, emittente o flusso di destinazione.

Errori comuni

  • Un hash ricercabile o una voce del mempool locale sono già confermati.
  • Una convenzione e la soglia di sei conferme valgono per ogni chain, importo e servizio.
  • Una commissione più alta fa arrivare prima blocchi successivi o finalità PoS.
  • Un conteggio fisso di blocchi o slot Ethereum equivale a safe o finalized.
  • Inclusione o finalità garantisce esecuzione corretta, destinatario corretto, accredito o completamento del bridge.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...