Blocchi

Ultima modifica: , Invalid DateTime

Visualizza chi ha contribuito

Modifica la pagina

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 adattato da Ethereum EVM illustrated

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 alcuni validatori della rete, 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:

1slot: lo slot a cui appartiene il blocco
2proposer_index: l'ID del validatore che ha proposto il blocco
3parent_root: l'hash del blocco precedente
4state_root: l'hash radice dell'oggetto di stato
5body: un oggetto contenente diversi campi, come definito di seguito
6

Il blocco body contiene a sua volta diversi campi:

1randao_reveal: un valore usato per selezionare il prossimo propositore del blocco
2eth1_data: informazioni sul contratto di deposito
3graffiti: dati arbitrari usati per etichettare i blocchi
4proposer_slashings: elenco di validatori da sottoporre a slashing
5attester_slashings: elenco di validatori da sottoporre a slashing
6attestations: elenco di attestazioni in favore del blocco corrente
7deposits: elenco di nuovi depositi al contratto di deposito
8voluntary_exits: elenco di validatori in uscita dalla rete
9sync_aggregate: sottoinsieme di validatori usati per servire i client leggeri
10execution_payload: transazioni passate dal client di esecuzione
11
Mostra tutto

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:

1aggregation_bits: un elenco di quali validatori hanno partecipato all'attestazione
2data: un contenitore con diversi campi secondari
3signature: la firma aggregata di tutti i validatori attestanti
4

Il campo data nell'attestation contiene quanto segue:

1slot: lo slot cui si correla l'attestazione
2index: indici per i validatori attestanti
3beacon_block_root: l'hash radice del blocco Beacon contenente questo oggetto
4source: l'ultimo punto di controllo giustificato
5target: il blocco di confine dell'ultima epoca
6

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:

1parent_hash: hash del blocco padre
2fee_recipient: indirizzo del conto a cui pagare le commissioni sulla transazione
3state_root: hash radice per lo stato globale dopo l'applicazione delle modifiche in questo blocco
4receipts_root: hash del trie delle ricevute delle transazioni
5logs_bloom: struttura di dati contenente i registri dell'evento
6prev_randao: valore usato nella selezione casuale del validatore
7block_number: il numero del blocco corrente
8gas_limit: il carburante massimo consentito in questo blocco
9gas_used: la quantità effettiva di carburante usata in questo blocco
10timestamp: il tempo di blocco
11extra_data: dati aggiuntivi arbitrari come byte grezzi
12base_fee_per_gas: il valore della commissione di base
13block_hash: hash del blocco di esecuzione
14transactions_root: hash radice delle transazioni nel payload
15
Mostra tutto

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):

1parent_hash: hash del blocco padre
2fee_recipient: indirizzo del conto a cui pagare le commissioni sulla transazione
3state_root: hash radice per lo stato globale dopo l'applicazione delle modifiche in questo blocco
4receipts_root: hash del trie delle ricevute delle transazioni
5logs_bloom: struttura di dati contenente i registri dell'evento
6prev_randao: valore usato nella selezione casuale del validatore
7block_number: il numero del blocco corrente
8gas_limit: il carburante massimo consentito in questo blocco
9gas_used: la quantità effettiva di carburante usata in questo blocco
10timestamp: il tempo di blocco
11extra_data: dati aggiuntivi arbitrari come byte grezzi
12base_fee_per_gas: il valore della commissione di base
13block_hash: hash del blocco di esecuzione
14transactions: elenco delle transazioni da eseguire
15
Mostra tutto

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. Questo differisce dai sistemi basati sul Proof of Work, in cui i tempi di blocco sono probabilistici e regolati dalla difficoltà di mining.

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à a seconda della domanda della rete, fino al limite del blocco di 30 milioni di gas (2 volte la dimensione prevista del blocco). L'importo totale di gas consumato da tutte le transazioni nel blocco dev'essere inferiore al limite di gas 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 community che ti è stata utile? Modifica questa pagina e aggiungila!

Argomenti correlati

• Transazioni
• Gas
• Proof of Stake