Vai al contenuto principale
Change page

Blocchi

Ultima modifica: , 18 gennaio 2024

I blocchi sono un insieme di transazioni che contengono un hash del blocco precedente nella catena. Per questo motivo, sono collegati l'uno all'altro nella catena, perché gli hash vengono calcolati crittograficamente dai dati del blocco. Questi impedisce anche le frodi, perché un cambiamento in qualsiasi blocco nella cronologia invaliderebbe tutti i blocchi successivi, dato che gli hash successivi cambierebbero e tutti coloro che eseguono la blockchain se ne accorgerebbero.

Prerequisiti

Quello dei blocchi è un argomento piuttosto basico. Ma, per aiutarti a comprendere meglio questa pagina, ti consigliamo innanzitutto di leggere sui Conti, sulle Transazioni e la nostra introduzione a Ethereum.

Perché i blocchi?

Per far sì che tutti i partecipanti della rete Ethereum siano sincronizzati e concordino sulla cronologia esatta delle transazioni, le transazioni vengono raggruppate in blocchi. Significa che decine (o centinaia) di transazioni vengono inviate, approvate e sincronizzate in una volta sola.

Diagramma che mostra una transazione in un blocco che provoca cambiamenti di stato Diagramma adattato da Ethereum EVM illustrated(opens in a new tab)

Scaglionando gli invii, diamo a tutti i partecipanti della rete abbastanza tempo per giungere al consenso: anche se arrivano decine di richieste di transazione al secondo, i blocchi su Ethereum vengono creati e inviati a Ethereum solo più o meno ogni quindici secondi.

Come funzionano i blocchi

Per preservare la cronologia delle transazioni, i blocchi sono ordinati in modo rigoroso (ogni nuovo blocco che viene creato contiene un riferimento al blocco padre) e anche le transazioni all'interno del blocco sono ordinate altrettanto rigorosamente. A parte in rari casi, in ogni momento, tutti i partecipanti della rete concordano sul numero e sulla cronologia esatta dei blocchi e lavorano per raggruppare le richieste di transazione live nel blocco successivo.

Dopo essere stato realizzato da un validatore della rete selezionato casualmente, un blocco viene propagato al resto della rete; tutti i nodi vengono aggiunti al blocco alla fine della relativa blockchain e un nuovo validatore viene selezionato per creare il successivo. Il processo esatto di costruzione dei blocchi e il processo di invio/consenso è attualmente specificato nel protocollo "Proof of Stake" di Ethereum.

Protocollo Proof of Stake

Proof of Stake significa quanto segue:

  • I nodi di convalida devono mettere in staking 32 ETH in un contratto di deposito come garanzia contro i comportamenti malevoli. Questo aiuta a proteggere la rete, poiché le attività palesemente disoneste portano alla distruzione di parte o dell'intero stake.
  • In ogni slot (a distanza di dodici secondi), un validatore è selezionato casualmente per essere il propositore del blocco. Questo raggruppa le transazioni, le esegue e determina un nuovo 'stato'. Avvolge queste informazioni in un blocco e lo passa agli altri validatori.
  • Gli altri validatori che vengono a conoscenza di un nuovo blocco ri-eseguono le transazioni per assicurare di acconsentire alla modifica proposta allo stato globale. Supponendo che il blocco sia valido, lo aggiungono al proprio database.
  • Se un validatore è a conoscenza di due blocchi in conflitto per lo stesso slot, usa il proprio algoritmo di scelta della diramazione per selezionare quello supportato da più ETH in staking.

Maggiori informazioni sul Proof of Stake

Cosa c'è in un blocco?

In un blocco sono contenute molte informazioni. Al livello più alto, un blocco contiene i seguenti campi:

CampoDescrizione
slotlo slot a cui appartiene il blocco
indice_proponentel'ID del validatore che propone il blocco
parent_rootl'hash del blocco precedente
state_rootl'hash radice dell'oggetto di stato
corpoun oggetto contenente più campi, come definito di seguito

Il blocco body contiene a sua volta diversi campi:

CampoDescrizione
randao_revealun valore utilizzato per selezionare il prossimo proponente di blocchi
et1_datainformazioni sul contratto di deposito
graffitidati arbitrari utilizzati per contrassegnare blocchi
proposer_slashingselenco di validatori da tagliare
taglio_attestatorielenco di validatori da tagliare
attestazionielenco di attestazioni a favore del blocco corrente
depositielenco dei nuovi depositi nel contratto di deposito
uscite_volontarieelenco di validatori che escono dalla rete
sync_aggregatesottoinsieme di validatori, utilizzato per servire i client leggeri
execution_payloadtransazioni passate dal client di esecuzione

Il campo attestations contiene un elenco di tutte le attestazioni nel blocco. Le attestazioni hanno il proprio tipo di dati, contenente diversi pezzi di dati. Ogni attestazione contiene:

CampoDescrizione
aggregation_bitsun elenco dei validatori che hanno partecipato a questa attestazione
datiun contenitore con diversi campi secondari
firmafirma aggregata di tutti i validatori attestanti

Il campo data nell'attestation contiene quanto segue:

CampoDescrizione
slotlo slot cui si riferisce l'attestazione
indiceindici per l'attestazione dei validatori
beacon_block_rootl'hash radice del blocco Beacon contenente questo oggetto
fontel'ultimo punto di controllo giustificato
obiettivoil blocco di confine dell'ultima epoca

L'esecuzione delle transazioni nell'execution_payload aggiorna lo stato globale. Tutti i client ri-eseguono le transazioni nell'execution_payload per assicurare che il nuovo stato corrisponda a quello nel campo state_root del nuovo blocco. Così, i client, possono dire che un nuovo blocco è valido e sicuro da aggiungere alla loro blockchain. L'execution payload stesso è un oggetto composto da diversi campi. Inoltre, esiste un execution_payload_header, contenente importanti informazioni sommarie sui dati di esecuzione. Queste strutture di dati sono organizzate come segue:

L'execution_payload_header contiene i seguenti campi:

CampoDescrizione
parent_hashhash del blocco padre
fee_recipientindirizzo del conto a cui pagare le commissioni sulla transazione
state_roothash radice per lo stato globale dopo l'applicazione delle modifiche in questo blocco
receipts_roothash del trie delle ricevute delle transazioni
logs_bloomstruttura di dati contenente i registri dell'evento
prev_randaovalore usato nella selezione casuale del validatore
numero_blocconumero del blocco corrente
limite_gascarburante massimo consentito in questo blocco
gas_utilizzatoquantità effettiva di carburante usata in questo blocco
marca orariatempo di blocco
dati_extradati aggiuntivi arbitrari come byte grezzi
fee_base_per_gasil valore base della commissione
hash_del_bloccoHash del blocco di esecuzione
transactions_roothash radice delle transazioni nel payload
withdrawal_roothash radice del prelievo nel payload

Lo stesso execution_payload contiene quanto segue (si noti che è identico all'intestazione, tranne per il fatto che, invece dell'hash radice delle transazioni, include l'elenco effettivo delle transazioni e informazioni sui prelievi):

CampoDescrizione
parent_hashhash del blocco genitore
fee_recipientindirizzo del conto a cui pagare le commissioni di transazione
stato_del_roothash radice per lo stato globale, dopo l'applicazione di modifiche in questo blocco
receipts_roothash dell'albero delle ricevute di transazione
logs_bloomstruttura dei dati contenente registri di eventi
prev_randaovalore usato in una selezione casuale del validatore
numero_blocconumero del blocco corrente
limite_gasgas massimo allocato in questo blocco
gas_utilizzatol'attuale ammontare di gas utilizzato in questo blocco
marca orariatempo del blocco
dati_extradati arbitrari aggiuntivi, in byte grezzi
fee_base_per_gasil valore base della commissione
hash_del_bloccoHash dell'esecuzione del blocco
transazionielenco delle transazioni da eseguire
prelievielenco degli oggetti prelievo

L'elenco dei withdrawals contiene oggetti withdrawal strutturati nel modo seguente:

CampoDescrizione
addressindirizzo del conto che ha prelevato
amountimporto del prelievo
indicevalore dell'indice di prelievo
validatorIndexvalore dell'indice del validatore

Tempo di blocco

Il tempo di blocco si riferisce al tempo che separa i blocchi. In Ethereum, il tempo è diviso in unità da dodici secondi, dette 'slot'. In ogni slot viene selezionato un singolo validatore per proporre un blocco. Supponendo che tutti i validatori siano online e totalmente operativi, ci sarà un blocco in ogni slot, a significare che il tempo del blocco è 12 secondi. Tuttavia, occasionalmente, i validatori potrebbero essere offline quando chiamati a proporre un blocco, a significare che talvolta gli slot possono rimanere vuoti.

Questa implementazione differisce dai sistemi basati sul proof-of-work, in cui i tempi di blocco sono probabilistici e regolati dalla difficoltà di mining target del protocollo. Il tempo medio di blocco(opens in a new tab) di Ethereum è un esempio perfetto da cui è possibile desumere il passaggio da proof-of-work a proof-of-stake in base alla coerenza del nuovo tempo di blocco da 12 secondi.

Dimensioni del blocco

Un'ultima nota importante: i blocchi stessi sono limitati in termini di dimensioni. Ogni blocco ha una dimensione prevista di 15 milioni di gas, ma la dimensione dei blocchi aumenterà o diminuirà in base alle esigenze della rete, fino al limite di 30 milioni di gas (2x dimensioni del blocco previste). La quantità totale di carburante usato da tutte le transazioni nel blocco deve essere inferiore al limite di carburante del blocco. Ciò è importante perché evita che i blocchi siano arbitrariamente grandi. Se i blocchi potessero essere arbitrariamente grandi, i nodi completi meno performanti, gradualmente, non riuscirebbero più stare al passo con la rete per via dei requisiti di spazio e velocità. Più grande è il blocco, maggiore sarà la potenza di calcolo richiesta per elaborarlo in tempo per il prossimo slot. Questa è una forza centralizzante, a cui si resiste limitando le dimensioni dei blocchi.

Letture consigliate

Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!

Questo articolo è stato utile?