--- title: "Prova della storia: Ordinamenti registrati, tick, slot e limiti di consenso" description: "Proof of History è l'orologio sequenziale della catena di hash di Solana: rende verificabili l'ordine registrato e i conteggi di calcolo di un produttore, ma non dimostra in modo indipendente l'ora dell'orologio, l'ordine di arrivo corretto delle transazioni, la scelta del fork o la finalità." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Prova della storia: Ordinamenti registrati, tick, slot e limiti di consenso > Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite. ## Risposta diretta Proof of History, o PoH, è l'orologio crittografico di Solana e la struttura dei dati di ordinamento del registro. Un produttore applica ripetutamente una funzione hash in modo che ogni output dipenda dall'output precedente, registri periodicamente conteggi e stati e mescoli i dati derivati ​​dalle transazioni nella catena. Un verificatore può ricalcolare tali transizioni e confermare l'ordine registrato da quella particolare catena. PoH non è un algoritmo di consenso autonomo. Non sceglie il fork canonico, non fornisce accordi ponderati in base alla quota, non finalizza blocchi o dimostra che una transazione ha raggiunto la rete in un particolare momento civile. Solana combina l'orologio con leader pianificati, esecuzione delle transazioni, voti del validatore, scelta del fork e blocchi in stile Tower BFT. Due fork possono contenere ciascuna sequenze PoH valide internamente; le regole di consenso determinano quale storia segue la rete. La portata di questa garanzia è limitata. Se una voce impegna i dati d dopo lo stato h2, lo stato successivo h3 = H(h2 || d) non può essere calcolato senza tale impegno. Ciò mostra che il produttore conosceva d prima di h3 e ne fissa la posizione registrata rispetto alle uscite successive. Non dimostra l'ora di ricezione di ogni validatore, l'equità dell'ordine, la verità dei dati esterni o lo stato canonico della voce. La generazione è sequenziale perché l'input successivo non è noto finché non esiste l'hash precedente. Gli stati al contorno pubblicati consentono ai verificatori di riprodurre segmenti delimitati separati in parallelo, ma il lavoro di hash aggregato rimane. Per questo motivo, PoH viene spesso paragonato a una funzione di ritardo verificabile, mentre la spiegazione Tower BFT di Solana lo definisce un uso approssimativo di quel termine; uno VDF formale normalmente ha un'interfaccia di valutazione e verifica la cui verifica è efficiente rispetto alla valutazione sequenziale. ## Come analizzare la prova della storia 1. **Correggere il contesto di rete e software.** Registra rete, hash di genesi, slot, epoca, Agave o altro client versione e tempo di osservazione. Leggere valori attivi come hashes_per_tick, ticks_per_slot e ns_per_slot; non importare costanti da un vecchio articolo o da un altro cluster. 2. **Ricostruisci la catena hash.** Inizia da uno stato di predecessore attendibile e verifica num_hashes di ciascuna voce, l'hash risultante e l'elenco delle transazioni. Nell'implementazione della voce di Agave, un identificatore della voce dipende dalla voce precedente e, quando sono presenti transazioni, un hash derivato dalle loro firme. 3. **Convalida i tick e il posizionamento degli slot.** Controlla le voci dei tick, i conteggi degli hash previsti, l'altezza dei tick e l'altezza massima dei tick rispetto alle regole della banca e del registratore. Il registratore mappa l'altezza del tick in uno slot utilizzando ticks_per_slot configurato; gli slot sono intervalli di protocollo, non prove indipendenti da un orologio esterno. 4. **Distinguere l'inclusione dall'arrivo.** Un impegno dimostra che l'input era noto non più tardi del suo inserimento in quella sequenza. Per richiedere un limite inferiore, identificare un riferimento all'indietro firmato a uno stato PoH precedente. Nessuno dei due limiti dimostra l'ordine first-seen globale, l'equità di mempool o un timestamp UTC affidabile. 5. **Generazione separata dalla verifica.** Misura la produzione sequenziale su una catena di dipendenze, quindi misura la riproduzione utilizzando i limiti dei segmenti autenticati e i core disponibili. Riporta gli hash totali, la latenza del percorso critico, il lavoro aggregato del verificatore e le ipotesi sui dati limite invece di dire semplicemente che la verifica è "veloce". 6. **Traccia il percorso del consenso.** Identifica il leader pianificato, lo stato della banca, i voti, i blocchi, la regola di scelta della fork, lo stato radicato o finalizzato e il livello di impegno. Una catena PoH valida può comunque appartenere a un fork perdente e un contatore dall'aspetto più lungo da solo non è un certificato di consenso. 7. **Casi operativi e contraddittori di stress.** Equivoco del leader del test, omissione e riordino delle transazioni, slot saltati, partizioni, hardware più veloce o calibrato in modo errato, conteggi di tick non validi, riproduzione ritardata, indisponibilità del registro, divergenza del cliente e controllo correlato dell'operatore o dell'infrastruttura. L'output della revisione dovrebbe distinguere quattro affermazioni: validità della sequenza, ora del protocollo configurato, stato del consenso e ora esterna. Indica quali hash iniziali e dati del registro sono stati considerati attendibili, quali hash sono stati ricalcolati, quali prove di voto o di impegno sono state controllate e quali osservazioni provenivano da orologi locali o servizi di terze parti. ## Esempi funzionati ### 1. L'inserimento di dati fissa una posizione registrata Considera h1 = H(h0), quindi h2 = H(h1). Un produttore inserisce un impegno derivato dalla transazione d e calcola h3 = H(h2 || d), seguito da h4 = H(h3). Chiunque ripeta le stesse operazioni può verificare che la catena registrata impegna d tra h2 e h3 e che h4 dipende dal risultato. L'affermazione del limite superiore è ristretta: il produttore conosceva d prima di calcolare h3. Se la transazione firmata stessa fa riferimento a h1, un verificatore può anche dimostrare che è stata formata dopo la conoscenza di quello stato precedente, previo controllo della firma e della provenienza. Senza tale riferimento all'indietro, PoH da solo non fornisce alcun limite inferiore. Nessuno dei due casi dimostra quando un altro nodo ha ricevuto per la prima volta la transazione. ### 2. La riproduzione dei segmenti riduce la latenza, non il lavoro aggregato Supponiamo che un intervallo registrato contenga 1.000.000 di hash e che i checkpoint autenticati lo dividano in 10 segmenti da 100.000 hash. Con un numero sufficiente di core, è possibile riprodurre dieci segmenti contemporaneamente, quindi la latenza di verifica può avvicinarsi alla durata di un segmento più l'overhead. I verificatori eseguono ancora collettivamente 1.000.000 di hash; i checkpoint espongono stati di partenza indipendenti ma non trasformano la catena in una prova succinta. Le prestazioni dipendono dall'hardware, dalla pianificazione, dal movimento della memoria e dalla fiducia nei limiti. Questo è il motivo per cui una riproduzione parallela di PoH non dovrebbe essere automaticamente descritta come l'efficiente algoritmo di verifica di ogni costruzione formale VDF. ### 3. L'aritmetica di tick e slot dipende dalla configurazione Assumere una configurazione illustrativa con hashes_per_tick = 100,000 e ticks_per_slot = 8. Uno slot con hash completo contiene quindi hash 100,000 * 8 = 800,000, con limiti di tick dopo ogni intervallo configurato. La modifica di uno dei parametri modifica la mappatura; questo esempio non è una costante corrente della mainnet. Agave supporta anche configurazioni che questa moltiplicazione semplificata non descrive. Un revisore deve leggere i campi effettivi di Bank e convalidare le voci secondo le regole del client. La conversione di uno slot o di un conteggio in secondi dipende anche dalla calibrazione della durata target e dall'esecuzione osservata, non solo dalla verifica crittografica. ### 4. L'ordine registrato non è l'ordine di arrivo o la finalità Supponiamo che la transazione A raggiunga un leader prima della transazione B, ma il leader registra B vicino al conteggio 300.000 e A vicino al conteggio 450.000. PoH valido dimostra che B precede A in quella sequenza prodotta. Ciò non prova che B sia arrivato per primo, che l'ordine fosse giusto o che un altro leader abbia rispettato lo stesso ordine. Supponiamo ora che una partizione produca il fork X e il fork Y, ciascuno con una sequenza valida. La convalida PoH può rifiutare voci con formato errato su entrambi i fork, ma non seleziona X o Y. La pianificazione del leader, i voti ponderati per la puntata, i blocchi, la scelta del fork e il livello di impegno richiesto determinano il risultato del consenso; le applicazioni non devono sostituire un conteggio PoH per conferma o prova definitiva. ## Rischi e errori di revisione ### Errori crittografici e di temporizzazione - Chiamare PoH un orologio da parete affidabile o richiedere un conteggio hash dimostra in modo indipendente un UTC timestamp. - Dire che l'inclusione della transazione dimostra il tempo di ricezione a livello di rete, l'ordine di prima visualizzazione o la verità dei dati esterni. - Presupporre che la generazione sequenziale impedisca a un produttore di trattenere, omettere o scegliere quando inserire dati noti. - Trattare la sola resistenza alle collisioni come un limite completo alla velocità dell'hardware, alla deriva della calibrazione o alla varianza di implementazione. - Descrivere la riproduzione di segmenti paralleli come lavoro zero o come una prova concisa senza contare gli hash aggregati. - Chiamare PoH come VDF formale senza indicare la costruzione, l'interfaccia di prova e le ipotesi di verifica da confrontare. - Affidarsi ai limiti dei checkpoint, agli hash predecessori o ai segmenti del registro scaricati senza autenticarne provenienza. ### Errori di consenso e di protocollo - Chiamata del consenso PoH, prova di palo, Tower BFT, elezione del leader, scelta del fork e finalità: lo stesso meccanismo. - Presumendo che la sequenza valida con il conteggio più alto deve essere canonica senza esaminare i voti e lo stato di scelta del fork. - Trattare una voce riprodotta localmente come confermata, rootata o finalizzata senza controllare la semantica di impegno richiesta. - Utilizzo dei valori storici hashes_per_tick, ticks_per_slot o di durata dello slot come costanti correnti universali. - Ignorare gli slot saltati, la rotazione del leader, le partizioni, gli equivoci e le differenze della versione del client quando ordine di ricostruzione. - Confronto dei conteggi di fork non correlati o stati iniziali come se appartenessero a una sequenza autenticata. - Presupponendo che il blockhash recente di una transazione sia semplicemente un timestamp dell'orologio anziché un contesto di validità del protocollo. ### Errori di operazioni, prestazioni e controllo - Benchmarking della sola generazione di hash ignorando esecuzione, verifica della firma, riproduzione, larghezza di banda e spazio di archiviazione. - Equiparando il parallelismo teorico dei segmenti con il recupero osservato del validatore sotto CPU, I/O e contesa di memoria. - Ignorando errori di convalida del tick, stalli del registratore, operazioni bancarie ritardate, lacune nel registro, attendibilità dello snapshot e stato danneggiato. - Conteggio delle identità del validatore come indipendenti quando il client, hosting, rete, infrastruttura leader o controllo sono condivisi. - Presupporre che un hardware più veloce rimuova la latenza di rete, perdita di pacchetti, censura, negazione del servizio o rischio di concentrazione delle puntate. - Presentare una durata di slot target, una stima del throughput o un vecchio benchmark come garanzia del livello di servizio. ## Idee sbagliate comuni - **PoH è l'algoritmo di consenso completo di Solana.** PoH fornisce una sequenza registrata verificabile; il voto del validatore, i blocchi, la scelta del fork e altre regole di consenso decidono la cronologia seguita dalla rete. - **PoH dimostra l'esatto tempo reale di ogni transazione.** Dimostra la dipendenza e il conteggio all'interno di una sequenza autenticata; mappare quella sequenza sul tempo civile richiede configurazione e osservazioni esterne. - **PoH garantisce un ordine equo delle transazioni.** Un leader può selezionare, ritardare, riordinare o omettere input entro i vincoli del protocollo e delle risorse; PoH rende verificabile l'ordine registrato risultante. - **PoH è un mining proof-of-work con un altro nome.** Entrambi utilizzano l'hashing, ma il ruolo principale di PoH è un orologio sequenziale, non una corsa parallela aperta il cui lavoro vincente sceglie il catena. - **Qualsiasi sequenza PoH valida è definitiva.** Ciascuna fork competitiva può essere valida internamente; la conferma e la finalità richiedono la prova del consenso della rete. ## Argomenti correlati - [Meccanismi di consenso](/it/crypto/consensus-mechanism/) - [Prova della partecipazione](/it/crypto/proof-of-stake/) - [Validatori](/it/crypto/validator/) - [Regole di scelta della fork](/it/crypto/fork-choice-rule/) - [Tempo di blocco](/it/crypto/block-time/) ## Fonti - [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (accesso: 2026-08-19) - [Solana: A New Architecture for a High Performance Blockchain](https://solana.com/solana-whitepaper.pdf) - Solana (accesso: 2026-08-19) - [Tower BFT: Solana's High Performance Implementation of PBFT](https://solana.com/news/tower-bft--solana-s-high-performance-implementation-of-pbft) - Solana (accesso: 2026-08-19) - [Agave Entry Module](https://github.com/anza-xyz/agave/blob/master/entry/src/entry.rs) - Anza (accesso: 2026-08-19) - [Agave Proof-of-History Recorder](https://github.com/anza-xyz/agave/blob/master/poh/src/poh_recorder.rs) - Anza (accesso: 2026-08-19) - [Agave Bank Runtime](https://github.com/anza-xyz/agave/blob/master/runtime/src/bank.rs) - Anza (accesso: 2026-08-19) - [Transaction Confirmation and Expiration](https://solana.com/developers/cookbook/transactions/confirmation) - Solana (accesso: 2026-08-19) - [Verifiable Delay Functions](https://eprint.iacr.org/2018/601) - IACR Archivio ePrint di crittografia (accesso: 2026-08-19) Source: https://wiki.fcontext.com/it/crypto/proof-of-history/index.mdx