Traduzione italiana di Understanding block minting in Cardano
Traduzione italiana a cura di Lordwotton di RIOT Stake Pools. Se apprezzi queste traduzioni, per favore valuta di supportare il mio lavoro delegando i tuoi ada a RIOT 
entra nel nostro gruppo Telegram
Capire il conio dei blocchi in Cardano
Nella rete Cardano, solo i nodi che sono stati estratti a sorte negli slot assegnati e i cui certificati di registrazione sono stati memorizzati nella blockchain possono creare blocchi. Deve essere possibile verificare che i nuovi blocchi proposti siano stati coniati dal nodo che ha vinto la lotteria e che è stato autorizzato a farlo. Venite a scoprire come vengono coniati i nuovi blocchi e come vengono verificati.
Perché è necessario verificare i blocchi?
Ogni rete blockchain pubblica è soggetta a requisiti di decentralizzazione e sicurezza. Nel contesto della produzione di blocchi, ciò significa che è necessario stabilire una lotteria casuale per la selezione dei produttori di blocchi e un meccanismo di verifica dei blocchi.
Inoltre, le reti blockchain sono aperte, quindi chiunque può aderire volontariamente e in modo completamente anonimo e iniziare a produrre blocchi. Può anche essere fatto da entità che vogliono deliberatamente attaccare la rete. È quindi necessario definire le regole di funzionamento della rete (protocollo). Finché la maggior parte dei nodi della rete si comporta secondo le regole (del protocollo), sarà facile per la rete eliminare gli attacchi e aggiungere regolarmente nuovi blocchi validi alla blockchain.
La maggior parte delle blockchain attuali funziona in modo tale che in un determinato periodo di tempo un nodo produce un blocco e tutti gli altri nodi lo verificano. Il blocco proposto può essere accettato (se valido) o scartato. Se in un determinato periodo di tempo compaiono più blocchi, deve esistere una regola che determina quale blocco deve essere aggiunto alla fine della blockchain (diventerà l’ultimo blocco). La regola può dipendere dall’aggiunta di più blocchi nuovi (regola della catena più lunga).
La verifica del blocco consiste solitamente nel verificare la prova crittografica concreta che il blocco è stato creato dal nodo che ha vinto la lotteria. È possibile verificare ulteriori dati nell’intestazione del blocco. Ad esempio, per verificare l’autenticità e l’integrità del blocco.
Ogni blocco è composto da un’intestazione e da un corpo (contenuto). Anche il contenuto del blocco viene verificato, cioè vengono verificate le transazioni. Un blocco può avere un’intestazione valida, ma se il contenuto del blocco non è valido, anche il blocco non può essere valido. Questo articolo si concentra sulla produzione dei blocchi, quindi non ci interesserà il loro contenuto. Abbiamo bisogno solo dei dati contenuti nell’intestazione del blocco.
Una blockchain può essere considerata decentralizzata e sicura se un ampio insieme di nodi indipendenti è in grado di aggiungere blocchi e un aggressore non è in grado di interrompere questo processo in alcun modo. I nodi onesti sono in grado di raggiungere un consenso di rete a intervalli regolari.
Come Cardano divide il tempo
Cardano divide il tempo in slot della durata di un secondo e in epoche della durata di 5 giorni. Un’epoca dura 432.000 slot.
Quando si passa da un’epoca all’altra, viene scattata una cosiddetta istantanea.
Le istantanee vengono effettuate dai nodi che partecipano attivamente al consenso di Cardano (quindi alla produzione di blocchi). Le istantanee vengono scattate alla fine di ogni epoca e registrano la distribuzione dello stake e lo stato di delega della rete.
Gli staker possono delegare in qualsiasi momento durante l’epoca, quindi lo stake dei singoli pool e il loro numero (nuove registrazioni di stake pool) possono cambiare costantemente. Lo stato che riflette i cambiamenti è chiamato live stake. I nodi che partecipano al consenso della rete lavorano con lo stato preso durante le istantanee, che è chiamato stake attivo. Le istantanee garantiscono sicurezza, stabilità e prevedibilità al sistema.
Nell’immagine qui sotto, si può vedere l’istantanea (candidata per la partecipazione attiva) presa durante la transizione tra le epoche. Si noti che gli slot sono divisi da intervalli di 20 secondi. La casualità di Cardano è impostata in modo da produrre un nuovo blocco ogni venti slot circa. A volte l’intervallo di tempo tra i blocchi (numero di slot) può essere più breve, a volte più lungo.
Su ogni nodo si svolge una lotteria privata in ogni slot, indipendentemente dagli altri. Se un nodo (o più nodi) scopre di aver vinto il diritto di coniare un blocco, diventa il cosiddetto leader dello slot. Nell’immagine è indicato dai rettangoli gialli. Torneremo sui dettagli più avanti.
Torniamo alle epoche per spiegare un altro dettaglio. Nell’immagine sottostante, l’epoca N+3 è in corso (rettangolo verde). Un’ultima istantanea è stata scattata tra la transizione tra le epoche N+2 e N+3, ma non viene utilizzata come stake attivo. Un’istantanea scattata all’inizio dell’epoca precedente N+2 viene utilizzata come stake attivo. Questa istantanea riflette lo stato dell’epoca N+1 (rettangolo blu).
La distribuzione dello stake e lo stato di delega dell’istantanea scattata all’inizio dell’epoca precedente vengono utilizzati nell’epoca attuale come stake attivo. In altre parole, lo snapshot precedente viene utilizzato come stake attivo.
Una delle ragioni principali di questa regola è che è passato abbastanza tempo dall’acquisizione dell’istantanea precedente (5 giorni) per garantire che i blocchi della blockchain (compreso il contenuto) non cambino.
Preparazione del nodo per il conio e la verifica dei blocchi
Le lotterie casuali e il conio dei blocchi si basano sulla crittografia di Cardano. Per la lotteria casuale viene utilizzata la primitiva crittografica Verifiable Random Function. Schema di firma a chiave evolvente per firmare i blocchi e garantire l’immutabilità della storia della blockchain.
In questo articolo non tratteremo i dettagli crittografici, ma solo l’uso pratico per il conio e la verifica dei blocchi. È sufficiente sapere che gli operatori dei pool devono creare diverse coppie di chiavi che consentiranno loro di creare i certificati necessari per la registrazione dei pool e per il funzionamento dei nodi produttori di blocchi.
Ogni gestore di pool deve creare le seguenti coppie di chiavi:
- Coppia di chiavi della stake pool (chiave fredda)
- Coppia di chiavi KES (Key-Evolving Signature) (chiave calda)
- Coppia di chiavi VRF (Verification Random Function) (chiave calda)
- Coppia di chiavi dell’indirizzo di stake (chiave fredda)
Ogni coppia di chiavi consiste in una chiave privata (una chiave di firma) che il proprietario (cioè il gestore del pool) deve mantenere segreta. Inoltre, la chiave pubblica (chiave di verifica) può essere pubblicata. Nelle immagini, la chiave di firma è mostrata in rosso e la chiave di verifica in verde.
Tutti i nodi del pool utilizzano una chiave di firma VRF per la lotteria privata e una chiave di firma KES per la firma dei blocchi appena coniati.
Nell’immagine sottostante si vede l’operatore del pool che ha creato tutte le chiavi necessarie per il funzionamento del pool. Ha inserito le chiavi VRF e KES di firma nell’hot storage del nodo. Si noti che la chiave del pool di stake di verifica è utilizzata per l’identificazione del pool (ID). La chiave dell’indirizzo di stake di firma serve per prelevare le ricompense dal conto ricompense.
Affinché la verifica sia possibile, le chiavi VRF e KES di verifica devono essere disponibili per tutti i nodi della rete. Inoltre, è necessario che le chiavi siano correttamente associate a uno specifico operatore di pool. Ciò si ottiene attraverso un ID (stake pool key). I certificati sono utilizzati per distribuire le chiavi.
Tutti gli operatori di pool devono registrare il pool e inserirvi (tra le altre cose) una chiave VRF di verifica. Devono inoltre creare un certificato di chiave operativa e inserirvi una chiave KES di verifica (detta anche chiave operativa). Tutti i certificati sono distribuiti attraverso le transazioni Cardano e sono memorizzati nella blockchain.
Nell’immagine qui sotto si può vedere l’operatore della pool che ha creato il certificato di registrazione della pool e il certificato della chiave operativa, inserendovi le chiavi pubbliche richieste. Aggiungiamo che entrambi i certificati devono essere firmati dalla chiave del pool di stake firmante.
I titolari di ADA delegano il loro stake alle pool scelte attraverso una coppia di certificati, un certificato di registrazione dell’indirizzo di stake e un certificato di delega. Anche questi certificati sono memorizzati nella blockchain. Le monete ADA delegate aumentano lo stake totale dei pool.
Nell’immagine sottostante è possibile vedere l’utente che ha creato i certificati necessari per la delega di stake. Si noti che la chiave dello stake pool (ID) è inclusa nel certificato di delega.
Nell’immagine sottostante, si può vedere come gli staker e gli operatori di pool inviano i certificati alla blockchain attraverso le transazioni durante un’epoca. I certificati rimarranno memorizzati in singoli blocchi (comprese tutte le chiavi di verifica). L’immagine è solo a scopo illustrativo. Un blocco può contenere più certificati. Si vede anche un’istantanea che riflette la distribuzione dello stake e lo stato di delega della rete per una determinata epoca.
Affinché un nodo sia pronto a verificare i blocchi proposti da altri pool della rete, deve mantenere uno stato locale con tutte le informazioni necessarie. Un nodo deve essere in grado di verificare rapidamente i blocchi in arrivo senza dover cercare inutilmente informazioni nella blockchain.
I nodi tengono traccia di un insieme di indirizzi di stake attivi. I dati tracciati contengono le credenziali dell’indirizzo di stake (chiave o hash dello script) da ciascun certificato di registrazione dell’indirizzo di stake. I nodi aggiornano l’insieme in base alla convalida delle transazioni nei blocchi in arrivo. I nodi sono in grado di verificare le transazioni che ritirano le ricompense di staking dai conti reward (parte di ogni indirizzo di stake registrato).
I nodi tengono traccia di un insieme di stake pool attive, che indicizzano in base alle chiavi degli stake pool di verifica (più precisamente, gli hash delle chiavi). Inoltre, il nodo tiene traccia delle informazioni relative ai certificati delle chiavi operative, compreso un contatore che rappresenta il numero di serie del certificato. Solo il certificato con il numero di contatore più alto è valido (tutti i certificati più vecchi con un numero di contatore inferiore non sono validi).
I nodi tengono traccia dei certificati di delega attivi (tutti gli indirizzi di stake che sono delegati all’hash delle chiavi (ID) dei pool di stake di verifica).
Per poter giocare la lotteria degli slot dei leader e calcolare le ricompense per lo staking per ogni epoca, i nodi devono sapere quanto stake è delegato ai pool. Si tratta della somma di tutti gli indirizzi di stake delegati a ogni singola chiave del pool di stake di verifica (ancora una volta, gli hashtag delle chiavi).
Nell’immagine sottostante, si può vedere un nodo pool che mantiene uno stato locale con tutte le informazioni necessarie per la verifica dei blocchi (e delle transazioni). Si noti che il nodo conosce tutti i pool registrati. Conosce gli hash delle loro chiavi di pool e le loro puntate totali. Conosce anche tutte le chiavi KES (operative) e VRF attive.
Alcuni set sono costantemente aggiornati (ad esempio il set UTxO cambia ad ogni nuovo blocco aggiunto), mentre altri fanno riferimento all’istantanea precedente (stake attivo). Per garantire che tutti i nodi lavorino con lo stesso stato di produzione dei blocchi, non è possibile utilizzare uno stake attivo.
La figura seguente mostra come l’istantanea dell’epoca diventi la base per costruire lo stato locale. Tutti i certificati (e le delegazioni degli indirizzi di stake) vengono inseriti in set in modo da essere disponibili per una rapida verifica dei blocchi.
Ora sapete cosa è necessario affinché un nodo possa coniare nuovi blocchi e verificare quelli proposti da altri pool.
Conio del blocco
Immaginiamo che negli slot precedenti non sia stato eletto alcun leader. Un nuovo round di lotteria per lo slot corrente è ora in corso privatamente in ogni pool. Si tratta di una lotteria privata perché è necessario utilizzare una chiave VRF di firma che è disponibile solo all’operatore del pool e a nessun altro (se la chiave non è compromessa).
Per determinare se un nodo diventa leader dello slot, deve utilizzare la funzione VRF. La funzione VRF prende in input diversi parametri e produce un output VRF. L’input per la funzione VRF è l’ID dello slot (slot corrente), il Nonce e la chiave VRF di firma (memorizzata nell’hot storage del nodo).
Il nonce è calcolato come XOR di due valori: l’epoch nonce e l’extra entropia. L’epoch nonce è un hash creato utilizzando i primi 2/3 delle uscite VRF dei blocchi prodotti nell’epoch precedente. L’entropia extra è un valore opzionale che può essere iniettato da chiunque invii un certificato di registrazione di stake pool valido con un campo nonce non vuoto. L’entropia extra può essere utilizzata per aumentare la casualità e la sicurezza del sistema o per recuperare un nonce dell’epoca compromesso.
La funzione VRF su ogni nodo genera un’uscita casuale (Y) e una prova (⍴) per lo slot corrente. Il nodo confronta l’output VRF con una soglia che dipende dal proprio stake totale. Se l’output è inferiore alla soglia, il nodo viene eletto leader dello slot e può coniare un blocco in quello slot.
Nell’immagine sottostante si può vedere come tutti i pool della rete hanno giocato la lotteria in un determinato slot e hanno confrontato l’output del VRF con la soglia. Il nodo 7 è diventato il leader dello slot.
Nella maggior parte dei casi, in uno slot viene eletto un solo leader. Supponiamo che ciò avvenga anche nel nostro scenario. Il leader dello slot ha il diritto di costruire un blocco. Il nodo deve costruire l’intestazione del blocco e inserire transazioni valide nel corpo.
Il nodo inserisce queste informazioni nell’intestazione del blocco:
- Il numero del blocco, che è il numero sequenziale del blocco nella catena.
- Il numero di slot (ID slot) in cui il blocco è stato coniato.
- L’hash del blocco precedente, che è l’hash dell’intestazione del blocco precedente nel libro mastro.
- L’emittente del blocco. È la chiave di verifica dell’operatore dello stake pool che ha coniato il blocco.
- L’output del VRF (Y) e la prova (⍴).
- La dimensione del blocco, che è la dimensione del blocco in byte.
- L’hash del corpo del blocco. È l’hash del corpo del blocco (transazione e dati).
- Il certificato operativo.
- La versione del protocollo. È la versione dei parametri del protocollo utilizzati per la convalida del blocco.
Il blocco è visibile nell’immagine sottostante. Non lasciatevi ingannare dalle dimensioni delle proporzioni. In pratica, l’intestazione del blocco è significativamente più piccola del corpo del blocco. Nella prima fase, la funzione VRF viene utilizzata per determinare se il nodo in questione è diventato il leader dello slot. In caso affermativo, il nodo inserisce tutti i dati necessari nel blocco di intestazione e firma il blocco con la chiave KES di firma (memorizzata nell’hot storage del nodo).
Il blocco firmato è pronto per essere inviato alla rete Cardano. Il blocco verrà distribuito in tutto il mondo a tutti gli altri nodi Cardano tramite i nodi relay. Gli altri nodi iniziano a verificare le informazioni contenute nell’intestazione del blocco e, se queste sono corrette, procedono alla verifica del corpo.
- Verifica del blocco
La verifica del blocco proposto è molto semplice per i nodi, che hanno a disposizione tutte le informazioni necessarie (compreso il materiale crittografico) nei set attivi.
Un blocco sarà considerato valido se sono soddisfatte le seguenti condizioni.
Il risultato VRF è un valore casuale che determina l’idoneità dell’operatore dello stake pool a coniare un blocco in un determinato slot. La prova VRF è una prova crittografica che dimostra che l’esito VRF è stato generato dall’operatore dello stake pool utilizzando la sua coppia di chiavi VRF. Entrambi possono essere facilmente verificati.
Il nodo che deve verificare il blocco in arrivo deve conoscere il nonce dell’epoca corrente. Non è un problema poiché tutti i nodi onesti utilizzano lo stesso nonce (hanno utilizzato lo stesso processo per ottenerlo). Il nodo utilizza un algoritmo di verifica VRF per controllare se il risultato e la prova VRF corrispondono alla chiave VRF pubblica (presa dall’insieme attivo) e al nonce dell’epoca. Il nodo controlla anche se l’esito del VRF è inferiore a una soglia che dipende dallo stake del nodo che ha proposto il blocco. Se queste verifiche vengono superate, il nodo accetta che il blocco candidato sia stato coniato da un leader di slot valido.
È importante notare che questa verifica avrà successo solo se il pool con la stessa chiave (ID) del pool di stake si è registrato, il che deve avvenire al più tardi nell’epoca corrispondente all’istantanea utilizzata (stake attivo).
Un’altra parte della verifica è il controllo della firma KES. Il blocco proposto deve contenere un certificato di chiave di verifica nell’intestazione. Si ricorda che i nodi hanno a disposizione un elenco di certificati di chiave operativa attivi nel loro stato locale.
Il contatore del certificato di chiave operativa nel blocco non deve essere inferiore al contatore del certificato di chiave operativa nell’insieme attivo del nodo che verifica il blocco.
Nell’immagine seguente si può vedere come il nodo verifica l’intestazione del blocco appena arrivato, per il quale utilizza le informazioni preparate in base ai certificati memorizzati nella blockchain.
Nell’immagine sono indicate solo alcune verifiche relative alle chiavi VRF e KES. Naturalmente, è necessario verificare tutti i parametri dell’intestazione, ad esempio il numero di serie del blocco, la dimensione del blocco, il collegamento al blocco precedente, ecc.
Conclusione
Il conio dei blocchi è progettato in modo che nessun altro possa coniare un blocco in un determinato slot, a parte il leader dello slot. A tal fine, il nodo deve essere registrato nella blockchain attraverso un certificato e avere una quota totale sufficientemente grande. Inoltre, deve avere una chiave KES valida per il periodo KES indicato (la chiave privata per la firma dei blocchi viene cambiata a intervalli regolari per proteggere la storia della blockchain). Tutto il materiale crittografico per la verifica dei blocchi è disponibile a tutti i partecipanti alla blockchain. I nodi non accettano un blocco che non supera la verifica.