Vai al contenuto

Tempo di blocco

Il tempo di blocco può indicare uno slot programmato, un intervallo obiettivo proof-of-work o la distanza osservata tra blocchi canonici. Ecco come misurare ogni orologio senza confondere inclusione, conferme e finalità.

Aggiornato

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

Risposta diretta

Il tempo di blocco non è un cronometro universale. Nel proof-of-work spesso indica l’obiettivo di lungo periodo di un processo casuale di arrivo dei blocchi. Nel proof-of-stake a slot può essere la durata programmata di un’opportunità di proposta. La distanza osservata tra blocchi canonici è una terza misura; inclusione, profondità di conferma e finalità hanno orologi separati.

Sulla Mainnet Ethereum ci sono 12-second slots e 32 slots per epoca. Un proposer può mancare uno slot, quindi blocchi prodotti adiacenti possono distare 24 seconds, 36 seconds o più, pur restando lo slot di 12 seconds. In Bitcoin, 600 seconds è l’intervallo medio obiettivo del sistema di difficoltà, non una scadenza per il blocco successivo.

Dichiara chain, rete, fork, finestra e orologio. Il timestamp dell’header è dato di protocollo, non necessariamente l’istante in cui ogni nodo riceve il blocco. Un intervallo nominale più breve può anticipare l’inclusione, ma non garantisce da solo throughput maggiore, commissioni inferiori, meno reorg o finalità più rapida.

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, rete, layer, fork attivo, head canonico, nodo o RPC e finestra UTC. Registra gli hash; la sola altezza non è univoca.
  2. Definisci la metrica: intervallo obiettivo, durata dello slot, differenza tra timestamp canonici, ricezione locale, latenza di inclusione, profondità o tempo di finalità.
  3. Raccogli hash, parent hash, altezza o slot, timestamp di protocollo e ricezione monotona locale. Mantieni slot mancati, blocchi stale e riorganizzati come stati espliciti.
  4. Percorri l’ascendenza canonica, calcola intervalli e pubblica campione, finestra, media, mediana, percentili, minimo, massimo e tasso di slot mancati. Una media non descrive una distribuzione asimmetrica.
  5. Applica il consenso. Per Ethereum distingui slot, epoche, head, safe e finalized. Per Bitcoin distingui 600-second target, arrivi casuali dipendenti dall’hashrate, chainwork, finestra di 2,016-block e regole dei timestamp.
  6. Scomponi la latenza in trasmissione, attesa in mempool o sequencer, proposta, propagazione, inclusione canonica, conferme, safe/finalized ed elaborazione di bridge, piattaforma o applicazione.
  7. Confronta nodi indipendenti e testa disallineamento degli orologi, lacune RPC, proposer mancati, variazioni dell’hashrate, partizioni, reorg, ritardi di finalità, guasti del sequencer e cambi dei parametri prima di fissare uno SLA.

Esempi

  • Ethereum produce blocchi negli slot 1,000 e 1,003. La distanza programmata è (1,003 - 1,000) * 12 = 36 seconds; 1,001 e 1,002 sono mancati. L’altezza aumenta di un blocco prodotto, il numero di slot di tre.
  • In 300 slots, la finestra è 300 * 12 = 3,600 seconds. Con 294 canonical blocks, ci sono 6 missed slots, rapporto 294 / 300 = 98% e tasso 294 / 3,600 = 0.0816666667 blocks/second, il cui reciproco è 12.2448979592 seconds/block. È una statistica, non una promessa.
  • Un’epoca dura 32 * 12 = 384 seconds = 6.4 minutes; due durano 768 seconds = 12.8 minutes. Voti e partecipazione determinano la finalità: non è uno SLA fisso; Ethereum indica oggi circa 15 minutes in condizioni normali.
  • Nel modello esponenziale Bitcoin con media 600 seconds, la probabilità di nessun blocco in 1,200 seconds è e^(-1,200/600) = e^-2 = 13.5335283237%, quella di almeno uno 86.4664716763%. La finestra obiettivo è 2,016 * 600 = 1,209,600 seconds = 14 days; nessun valore pianifica un blocco singolo.

Rischi

  • Usare chain, rete, layer, fork o parametro storico errati.
  • Confrontare slot programmato, target PoW e intervallo osservato.
  • Trattare obiettivo o media come attesa massima garantita.
  • Scegliere una finestra breve, tranquilla o selezionata.
  • Trattare il timestamp come ora esatta di produzione o ricezione.
  • Mescolare orologi locali non sincronizzati.
  • Omettere slot mancati o confonderli con blocchi vuoti.
  • Includere blocchi stale o riorganizzati nella serie canonica.
  • Contare altezze senza verificare hash, parent e ascendenza.
  • Nascondere lacune RPC, indexer, websocket o log come comportamento della rete.
  • Riportare la media senza mediana, percentili, intervallo e campione.
  • Confondere attesa in mempool o sequencer con produzione.
  • Confondere prima inclusione o una conferma con finalità economica.
  • Convertire conferme in minuti deterministici.
  • Trattare il 10-minute target Bitcoin come SLA.
  • Ignorare hashrate, ritardo della difficoltà e limiti dei timestamp.
  • Ignorare pressione di propagazione, validazione e fork temporanei.
  • Trattare il parametro Ethereum 12-second slot come garanzia di un blocco non vuoto.
  • Trattare un blocco L2 come pubblicazione, settlement o finalità L1.
  • Inferire TPS, commissioni, sicurezza o decentralizzazione solo dal tempo di blocco.

Errori comuni

  • Ogni slot Ethereum contiene un blocco. È un’opportunità; proposer o propagazione possono fallire.
  • Bitcoin produce esattamente un blocco ogni dieci minuti. È obiettivo e media; le attese variano molto.
  • Il timestamp è quando ogni nodo riceve il blocco. Timestamp e ricezione locale hanno attori e orologi distinti.
  • Dimezzare il tempo raddoppia TPS sicuro e dimezza commissioni o finalità. Capacità, carico, domanda, propagazione e voti restano vincoli indipendenti.
  • Un blocco L2 rapido ha già finalità Ethereum. Inclusione del sequencer, pubblicazione L1, inclusione canonica e finalità sono stati separati.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...