(╯°□°)╯︵ 💻

3. Ethereum

Questo argomento è stato trattato in blockchains

Ethereum condivide molti elementi con altre blockchains, ma la sua particolarità è il fatto di essere progettata per essere una blockchain programmabile e general purpose per superare le limitazioni dello scripting di Bitcoin, proponendo un linguaggio Turing complete.

Smart contract

Smart contract: definizione

Uno smart contract è un programma che viene eseguito sulla blockchain di Ethereum. È una collezione di codice (funzioni) e dati (il suo stato) che risiede a uno specifico indirizzo sulla blockchain di Ethereum.

Gli smart contract di Ethereum sono equiparati a un account Ethereum: hanno un saldo e possono essere oggetto di transazioni.

I contratti non sono controllati da utenti, ma sono sono rilasciati sulla rete e funzionano in base a come sono programmati. Gli account utente possono interagirvi inviando transazioni.

Account

Un account Ethereum è un’entità con un saldo in Ether (EHT) che può inviare delle transazioni. Ne esistono di due tipi:

  • externally-owned account (EOA), che sono controllati da chiunque abbia la relativa chiave privata;
  • contract account, uno smart contract distribuito sulla rete e controllato dal codice.

Entrambi i tipi possono ricevere, trattenere e inviare ETH e token, oltre che interagire con gli smart contract che sono stati rilasciati.

Externally Owned Account (EOA)

Per creare un account, non è necessario sostenere alcuna spesa. Un account può iniziare transazioni: tra due EOAs, si possono trasferire solo ETH e token.

Gli account si compongono di una coppia di chiavi crittografiche, una pubblica e una privata, che controllano le attività dell’account.

Contract

Creare un contratto ha un costo, poiché si utilizza lo storage della rete. Un contratto può solo inviare transazioni in risposta a una transazione ricevuta.

Le transazioni da un account esterno a un contratto possono invocare l’esecuzione di codice che può eseguire svariate azioni, come il trasferimento di token o la creazione di un nuovo contratto.

Gli account di tipo contract non hanno chiavi private poiché sono controllati dalla logica del codice stesso dello smart contract.

Decentralized Application (DApp)

Decentralized Application: definizione

Un’applicazione decentralizzata è un’applicazione costruita su una rete decentralizzata che combina smart contracts e un’interfaccia utente per il frontend.

Transazioni

Le transazioni sono istruzioni firmate crittograficamente tra due account. Un account che inizia una transazione aggiorna lo stato della rete Ethereum.

Una transazione Ethereum si riferisce a un’azione iniziata da un EOA.

Semantica della transazione

{
	from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
	to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
	gasLimit: "21000", // gas units. 21000 is the standard price for a money transfer
	maxFeePerGas: "300", // gwei (1ETH = 1.000.000.000 gwei)
	maxPriorityFeePerGas: "10",// gwei
	nonce: "0",
	value: "10000000000"
	// data: <address of the function>; if not specified, the transaction is a simple money transfer, rather than a contract deployment/interaction
}

Gas

Affinché una transazione possa avvenire, è necessario corrispondere una commissione che possa coprire il lavoro compiuto dalla rete per svolgere quella transazione. Questo viene espresso dai campi gasLimit, maxFeePerGas, maxPrioriyFeePerGas nella transazione.

Il gas è una unità (astratta) che misura l’unità di lavoro che è necessario pagare per fare un’operazione. Ciascuna unità di gas corrisponde poi a un certo “prezzo” in gwei; in questo contesto, il campo maxFeePerGas specifica l’ammontare in gwei che l’account che avvia la transazione è disposto a corrispondere per singola unità di gas. Il costo di ogni unità di gas non è fissato e viene stabilito in base alla congestione della rete Ethereum nel momento in cui avviene la transazione.

In aggiunta alla “base fee”, il campo maxPriorityFeePerGas specifica una commissione aggiuntiva al prezzo di ogni unità di gas, che costituisce la mancia per i validator della rete, come incentivo a includere la transazione nel primo blocco a disposizione.

Le unità di gas consumate per la transazione sono “bruciate” e, l’equivalente moneta in ETH viene distrutta (non viene corrisposta ad alcun account e chi dispone la transazione ne verrà sottratto), per fornire a ETH stabilità economica. Le unità di gas indicate come “priority fee” sono invece accreditate ai validator della transazione e del blocco.

Tipologie di transazione

  • regular: una transazione da un account a un altro;
  • contract deployment: una transazione senza valore nel campo to (tipicamente null o 0x0), in cui il campo data è usato per trasmettere il codice del contract;
  • execution: una transazione che interagisce con uno smart contract, in cui il campo data contiene la funzione da eseguire e il campo to l’indirizzo del contratto.

Ethereum Virtual Machine (EVM)

La Ethereum Virtual Machine (EVM) è un ambiente virtuale decentralizzato che esegue codice in maniera consistente e sicura su tutti i nodi Ethereum.

I nodi usano la EVM per eseguire smart contracts, usando il gas per misurare lo sforzo computazionale richiesto per le operazioni e garantendo un’allocazione efficiente delle risorse e la sicurezza della rete.

Consenso

La rete Ethereum iniziò a operare usando un meccanismo di consenso basato su Proof of Work. Questo perché Proof of Work è neutrale, sicuro e più facile da implementare rispetto a Proof of Stake, ma consuma più energia, richiede hardware specializzato e pool di mining possono dominare il processo, portando a centralizzazione.

Più recentemente (2022), Ethereum è passato a Proof of Stake.

Proof of Stake

Proof of Stake si basa sul fatto che i validators provano di avere qualcosa di valore da “impegnare” nella rete che può essere distrutto se questi agiscono in maniera disonesta. La messa in pegno (stake) avviene con uno smart contract.

i validator sono responsabili di controllare che i nuovi blocchi che vengono propagati sulla rete siano validi e di creare e propagare nuovi blocchi (occasionalmente). Sono coordinati dalla Beacon Chain.

Validators

Affinché sia possibile partecipare come validator, è necessario depositare 32 ETH ed eseguire 3 componenti software: un execution client, un consensus client e un validator client.

Depositando gli ETH, il validator si unisce a una coda di attivazione che ha lo scopo di limitare il tasso con cui nuovi validator entrano nella rete.

I validators ricevono poi i nuovi blocchi dai pari sulla rete Ethereum. Le transazioni consegnate in blocco sono rieseguite per controllare che i cambiamenti allo stato di Ethereum siano validi, e viene controllata la firma del blocco. Infine, il validator invia un voto (attestation) in favore di quel blocco sulla rete.

Timing

Contrariamente a PoW, il timing dei blocchi è fissato ed è diviso in slot (12 secondi) e epochs (32 slots), per una durata complessiva di circa 6.4 minuti.

Uno slot è un intervallo di 12 secondi in cui un blocco può essere proposto. Per ogni slot, un validator è selezionato casualmente (utilizzando RANDAO pesato sul saldo del validator) per proporre un blocco: se questi è online e funziona in maniera corretta, crea un blocco e lo condivide con la rete. Se il validator è offline, perde il turno e lo slot rimane vuoto, con nessun blocco che viene aggiunto in quei 12 secondi. Mentre un validator propone il blocco, nello stesso intervallo temporale, la rete crea dei committees (gruppi di validators), che votano sulla validità del blocco proposto. Se il blocco è valido, viene aggiunto immediatamente alla catena.

L’Epoch è una unità di tempo che consiste di 32 slots. La fine dell’epoch funge da “punto di gestione” in cui la rete finalizza le transazioni e aggiorna l’insieme di validators. Prima della validazione, la transazione apparirà come “pending” oppure con una sola conferma; al termine dell’epoch (se i dei validators hanno votato correttamente) diventa justified e, dopo un’ulteriore epoch, finalized (il punto di non ritorno). Questo meccanismo avviene in protezione rispetto ai fork che possono generarsi e comporta che una transazione viene finalizzata in circa 16 minuti (2.5 epochs, ammettendo che una transazione avvenga alla metà di un’epoch).

Attestazioni

L’attestazione è il voto positivo di altri validator sulla proposta di un blocco, ed è pesata dal saldo in ETH del validator.

Un’attestazione contiene due voti:

  • Latest Message-Drive Heaviest Observed Subtree (LMD Ghost Vote), che sono i voti per la testa della catena e servono a determinare quale blocco deve essere considerato l’ultimo blocco valido;
  • Finality Gadget Vote (FFG), che consiste di due componenti di voto, sorgente e target. Il voto sorgente (source vote) si riferisce all’ultimo checkpoint justified, mentre il target vote si riferisce al checkpoint che il validator crede debba essere finalizzato.

Committees

In ogni slot, un committee di validators (128 membri) è scelto casualmente e i voti sono usati per determinare la validità del blocco che viene proposto. Un attaccante ha possibilità trascurabili di controllare i 2/3 del committee.

Dividere i validato in committee è importante per mantenere il carico di rete gestibile. I committee dividono l’insieme di validators in modo che ogni validator attivo produca un’attestazione in ogni epoch, ma non in ogni slot.

Un validator può essere in un solo committee per epoch. Tipicamente, ci sono ci sono più di 8192 validators, quindi c’è più di un committee per slot. Tutti i committee sono della stessa dimensione e hanno almeno 128 validators.

La sicurezza diminuisce quando ci sono meno di 4096 validators, perché tutti i committee avrebbero meno di 128 validators.

Checkpoint

Un voto espresso dai 2/3 del saldo totale di tutti i validator attivi è detto supermaggioranza (supermajority).

Crypto-Economic Security

A un validator è richiesto di mantenere l’hardware e la connessione sufficiente per partecipare nella validazione e proposta di un blocco.

Partecipare come validator offre opportunità agli utenti disonesti di attaccare la rete per guadagno personale o sabotaggio; affinché ciò sia impedito, i validators perdono le ricompense se non partecipano quando sono chiamati e la somma da loro impegnata può essere distrutta quando si comportano in maniera disonesta.

Correlation Penalty

La quantità di ETH oggetto di slashing (distruzione) dipende da quanti validators sono subiscono lo slashing nello stesso tempo, dunque può essere sia minoritaria (ca. 1% del pegno per singolo validator che viene slashato), sia coinvolgere il 100% del pegno del validator.

Lo slashing è imposto a metà di un periodo di uscita forzata che inizia con una penalità immediata al giorno 1 che consiste nella perdita di parte del pegno e la sospensione dalle attività di validator. Fino al giorno 18 (metà del processo), essendo ancora sulla rete, il validator disonesto pagherà delle “inactivity penalties” ogni giorno poiché non inviano voti validi; al giorno 18, poi, vi è la correlation penalty: la rete controlla quanti altri validator hanno agito in maniera disonesta nello stesso intervallo e viene comminata una sanzione sul pegno tanto maggiore quanti più attaccanti vi erano (si presume l’avvio di un attacco coordinato). Al giorno 36, il validator è espulso dalla rete e gli è permesso il recupero di eventuali somme residue del pegno.

Slashable offence (attacchi che comportano slashing)

TBC

  • doppia proposta: si ha quando un validator propone più di un blocco per ogni slot assegnato;
  • LMD Ghost double vote: si ha quando un validator che attesta per due diverse teste della Beacon Chain per ogni slot assegnato;
  • surround vote: si ha quando un validator casta un voto FFG che

Fork

Quando la rete è attiva in maniera ottimale e onesta, c’è sempre solo un nuovo blocco alla testa della catena e i validator lo attestano.

I validator possono avere una visione differente sulla testa della catena a causa della latenza di rete o perché un proposer del blocco ha creato un equivoco.

Il consensus client richiede un algoritmo per decidere quale “testa” favorire: si tratta di LMD-Ghost che identifica il fork che ha il peso maggiore relativamente alle attestazioni nella sua cronologia.

51% Attack

Un attacco al 51% è più rischioso, con PoS, per un attaccante. La forza di PoS sta nella flessibilità che la community ha nel proporre un contrattacco:

  • i validatori onesti possono decidere di continuare a costruire sulla catena di minoranza e ignorare il fork dell’attaccante, incoraggiando app, exchange e pools a fare lo stesso;
  • i validatori possono anche decidere di rimuovere in maniera forzosa un attaccante dalla rete e distruggere gli ETH impegnati dall’attaccante.

Vantaggi e Svantaggi di PoS

Vantaggi:

  • maggiore efficienza energetica (servono anche meno ETH emessi, come ricompense, per incentivare la partecipazione);
  • minori barriere per entrare nella rete e requisiti hardware minori;
  • ridotto rischio di centralizzazione, poiché più nodi rendono sicura la rete;
  • penalità economiche per comportamenti errati, rendendo attacchi al 51% più costosi per un attaccante;
  • ricorso al recupero sociale di una catena onesta se un attacco al 51% sorpassa le difese critto-economiche.

Contro

  • è più recente e meno testato rispetto a PoW;
  • più complesso da implementare;
  • un utente deve eseguire tre software per partecipare al PoS di Ethereum.