- Ethereum passa alla proof-of-stake! La transizione, nota come “la Fusione”, deve prima essere attivata sulla Beacon Chain con l’aggiornamento Bellatrix. In seguito, la catena proof-of-work passerà a proof-of-stake una volta raggiunto uno specifico valore di Total Difficulty.
- L'aggiornamento Bellatrix è previsto per l'epoca 144896 sulla Beacon Chain alle 11:34:47 UTC del 6 settembre 2022.
- Il valore della Terminal Total Difficulty che innesca la Fusione è 5875000000000000000, previsto tra il 10 e il 20 settembre 2022.
- Nota: come annunciato in precedenza, la rete di prova Kiln è in fase di chiusura. Gli operatori chiuderanno il 6 settembre 2022.
Contesto
Dopo anni di duro lavoro, l'aggiornamento alla proof-of-stake di Ethereum è finalmente arrivato! L'aggiornamento di tutte le reti di prova pubbliche è stato completato con successo ed è stata programmata la Fusione per la rete principale Ethereum.
La Fusione è diversa dai precedenti aggiornamenti della rete per due aspetti. In primo luogo, gli operatori dei nodi devono aggiornare contestualmente sia i client del livello di consenso (CL) che quelli del livello di esecuzione (EL), e non solo uno dei due. In secondo luogo, l’aggiornamento si attiva in due fasi: la prima, denominata Bellatrix, in una determinata epoca sulla Beacon Chain, e la seconda, denominata Paris, nel momento in cui si raggiunge un valore di Total Difficulty sul livello di esecuzione.
Informazioni sull'aggiornamento
Tempo
La Fusione è un processo in due fasi. Il primo passo è un aggiornamento della rete, Bellatrix, sul livello di consenso, avviato a una determinata epoca. Segue la transizione del livello di esecuzione da proof-of-work a proof-of-stake, Paris, innescata dal raggiungimento di una specifica soglia di Total Difficulty detta Terminal Total Difficulty (TTD).
L'aggiornamento Bellatrix è previsto per l'epoca 144896 sulla Beacon Chain alle 11:34:47 UTC del 6 settembre 2022.
Paris, la parte di transizione che riguarda il livello di esecuzione, si concluderà con la Terminal Total Difficulty (TTD) di 5875000000000000000, prevista tra il 10 e il 20 settembre 2022. La data esatta in cui verrà raggiunto il valore di TTD dipende dal tasso di hash della proof-of-work. Le stime della transizione sono disponibili qui bordel.wtf e 797.io/themerge.
Una volta che il livello di esecuzione raggiunge o supera il TTD, il blocco successivo sarà prodotto da un validatore della Beacon Chain. La Fusione è considerata completa quando la Beacon Chain finalizza questo blocco. In condizioni di rete normali, questo accadrà 2 epoche (pari a ~13 minuti) dopo aver prodotto il primo blocco post-TTD!
Un nuovo tag di blocco JSON-RPC, finalized, restituisce l'ultimo blocco finalizzato, oppure un errore se non esiste un blocco dopo la fusione. Questo tag può essere utilizzato dalle applicazioni per verificare se la Fusione è stata completata. Allo stesso modo, dopo la Fusione gli smart contract possono interrogare l'opcode DIFFICULTY (0x44) (rinominato in PREVRANDAO) per determinare se la Fusione è avvenuta. Si consiglia ai fornitori di infrastrutture di monitorare la stabilità generale della rete, oltre allo stato di finalizzazione.
Rilasci di client
Le seguenti versioni del client supportano la Fusione sulla rete principale di Ethereum. Gli operatori dei nodi devono eseguire entrambi i client del livello di esecuzione e di consenso per rimanere sulla rete durante e dopo la Fusione.
Nella scelta di quale client eseguire, i validatori devono prestare particolare attenzione ai rischi dell'esecuzione di un client di maggioranza sia su EL che su CL. Una spiegazione di questi rischi e delle loro conseguenze è disponibile qui. Una stima dell'attuale distribuzione dei client EL e CL e le guide per il passaggio da un client all'altro sono disponibili qui.
Livello di consenso
| Nome | Versione | Link |
|---|---|---|
| Lighthouse | v3.1.0 | Download |
| Lodestar | v1.0.0 | Download |
| Nimbus | v22.9.0 | Download |
| Prysm | v3.1.0 | Download |
| Teku | 22.9.0 | Download |
Livello di esecuzione
| Nome | Versione | Link |
|---|---|---|
| Besu | 22.7.2 | Download |
| Erigon | v2022.09.01-alpha | Download |
| go-ethereum (geth) | v1.10.23 | Download |
| Nethermind | v1.14.1 | Download |
Attenzione: geth version v1.10.22 presenta un problema critico al database, non utilizzate questa versione e se avete già effettuato l'aggiornamento, aggiornate alla v1.10.23 il prima possibile.
Specifiche dell’aggiornamento
I cambiamenti critici della Fusione per il consenso sono specificati in due punti:
- Cambiamento del livello di consenso directory Bellatrix del repository consensus-specs
- Cambiamento del livello di esecuzione sotto la specifica Paris nel repository execution-specs
Oltre a queste, altre due specifiche riguardano le modalità di interazione tra i client del livello di consenso e di esecuzione:
- Per la comunicazione tra il livello di consenso e quello di esecuzione si usa l'Engine API, specificata nel repository execution-apis
- La sincronizzazione ottimistica (Optimistic Sync), specificata nella cartella sync del repository consensus-specs, è usata dal livello di consenso per importare blocchi mentre il client del livello di esecuzione sta sincronizzando e per consentire una visione parziale della testa della catena dal client del livello di consenso a quello di esecuzione
Bonus per la caccia ai bug relativo alla Fusione
Tutti i bonus relativi alle vulnerabilità della Fusione avranno un moltiplicatore di 4 volte da oggi all'8 settembre. I bug critici valgono fino a $1 milione di dollari.
Per maggiori dettagli vedere il Programma di Caccia ai Bug.
Domande frequenti
Come operatore di nodo, cosa devo fare?
Dopo la Fusione, un nodo Ethereum completo sarà la combinazione di un client del livello di consenso (CL), che esegue il proof-of-stake sulla Beacon Chain, e un client del livello di esecuzione (EL), che gestisce lo stato utente ed esegue i calcoli associati alle transazioni. Il client EL e CL comunicano su una porta autenticata usando un nuovo insieme di metodi RPC JSON chiamato Engine API. Il client EL e CL si autenticano a vicenda utilizzando un segreto JWT. Si rimandano gli operatori dei nodi alla documentazione dei loro client per le istruzioni su come generare e configurare questo valore.
In altre parole, se si stava già eseguendo un nodo sulla Beacon Chain, ora occorre eseguire anche un client del livello di esecuzione. Allo stesso modo, se si stava eseguendo un nodo sull'attuale rete proof-of-work, sarà necessario eseguire un client del livello di consenso. Per comunicare in modo sicuro, a ciascun client deve essere passato un token JWT. Un aggiornamento della sezione "Eseguire un nodo" del sito web ethereum.org illustra questi passaggi in modo più dettagliato.
È opportuno sottolineare che, sebbene entrambi facciano parte delle release di client del livello di consenso, eseguire un nodo beacon è diverso dall'eseguire un client del validatore. Gli staker devono eseguire entrambi, mentre gli operatori dei nodi hanno bisogno solo del primo client. Questo post spiega la differenza tra i due componenti in modo più dettagliato.
È utile osservare anche che ogni livello manterrà un insieme indipendente di peer ed esporrà le proprie API. Sia le API Beacon sia le API JSON RPC continueranno a funzionare come previsto.
Come staker, cosa devo fare?
Come spiegato in precedenza, dopo la Fusione i validatori sulla Beacon Chain dovranno eseguire un client del livello di esecuzione, oltre ai loro client del livello di consenso. Prima della Fusione, era già fortemente consigliato, ma alcuni validatori potevano esternalizzare queste funzioni a fornitori terzi. Questo era possibile perché gli unici dati richiesti al livello di esecuzione erano gli aggiornamenti del contratto di deposito.
Dopo la Fusione, i validatori devono assicurarsi che le transazioni utente e i blocchi di transizione dello stato che creano e attestano siano valide. A tal fine, ogni nodo beacon deve essere abbinato a un client del livello di esecuzione. Si noti che è ancora possibile che più validatori siano accoppiati a una singola combinazione di nodo beacon e client del livello di esecuzione. Questo estende le responsabilità dei validatori ma dà anche a un validatore che propone un blocco il diritto alle commissioni prioritarie sulla relativa transazione (che attualmente vanno ai miner).
Mentre le ricompense dei validatori maturano sulla Beacon Chain e necessitano un successivo aggiornamento per essere prelevate, le commissioni sulle transazioni saranno pagate, bruciate e distribuite sul livello di esecuzione. I validatori possono specificare qualsiasi indirizzo Ethereum come destinatario delle commissioni di transazione.
Dopo aver aggiornato il proprio client di consenso, assicurarsi di impostare il fee recipient nell’ambito delle configurazioni del client di validazione, per essere certi che le commissioni di transazione siano inviate a un indirizzo controllato dall’utente. Se lo staking è stato effettuato attraverso un fornitore esterno, spetta al fornitore selezionato specificare come vengono assegnate le commissioni.
Lo Staking Launchpad dispone di una Checklist per prepararsi alla Fusione che gli staker possono utilizzare per assicurarsi di aver eseguito tutte le fasi del processo. EthStaker ha anche organizzato Laboratori di preparazione per i validatori, e altri sono in fase di programmazione.
Gli staker che desiderano eseguire un validatore su una rete di prova in preparazione della transizione al proof-of-stake della rete principale possono farlo su Goerli (ora fuso con Prater), che ha anche un'istanza Staking Launchpad.
Perché la data stimata di Terminal Total Difficulty è così ampia?
La difficoltà incrementale aggiunta per ogni blocco dipende dal tasso di hash della rete che è volatile. Se aumenta l’hash rate della rete, la TTD verrà raggiunta prima. Allo stesso modo, se l'hash rate diminuisce, la TTD verrà raggiunta più tardi. In caso di calo significativo dei livelli di hash rate, si potrebbe coordinare un TTD Override, come è stato fatto su Ropsten.
Come sviluppatore di applicazioni o di strumenti, cosa devo fare?
Come spiegato in un post precedente, la Fusione avrà ripercussioni molto limitate su un sottoinsieme di contratti distribuiti su Ethereum, nessuna delle quali dirompente. Inoltre, la maggior parte degli endpoint API dell'utente rimangono stabili (a meno che non si stiano usando metodi specifici per il proof-of-work, come eth_getWork).
Detto questo, la maggior parte delle applicazioni su Ethereum non si limita a contratti sulla catena. Ora è il momento di assicurarsi che il proprio codice front- end, gli strumenti, la pipeline di distribuzione e altri componenti esterni alla catena funzionino correttamente. Consigliamo vivamente agli sviluppatori di eseguire un ciclo completo di test e distribuzione su Sepolia o Goerli e segnalare ai manutentori dei vari progetti qualsiasi problema con gli strumenti o le dipendenze. In caso di dubbio sull’opportunità di sollevare un problema, è possibile usare questo repository.
Inoltre, si noti che tutte le reti di prova, eccetto Sepolia e Goerli, saranno deprecate dopo la Fusione. Gli utenti di Ropsten, Rinkeby o Kiln devono pianificare la migrazione a Goerli o Sepolia. Ulteriori informazioni al riguardo sono disponibili qui.
Come utente di Ethereum o detentore di Ether, c'è qualcosa che devo fare?
Chi utilizza applicazioni Ethereum sulla catena e chi detiene Ether su una borsa o in un portafoglio auto-custodito non deve fare nulla. Se un'applicazione, una borsa o un portafoglio utilizzato offre istruzioni o raccomandazioni aggiuntive, occorre verificare l’effettiva provenienza. Attenti alle truffe!
Come miner, c'è qualcosa che devo fare?
No. Chi sta facendo mining sulla rete principale Ethereum dovrebbe sapere che dopo la Fusione la rete funzionerà completamente in modalità proof-of-stake. A quel punto, non sarà più possibile fare mining sulla rete.
Cosa succede se un miner o un operatore di nodi non partecipa all'aggiornamento?
Se si utilizza un client Ethereum non aggiornato all'ultima versione (elencata sopra), quando l'aggiornamento sarà stato eseguito, il client si sincronizzerà con la blockchain precedente alla fork.
L’utente sarà bloccato su una catena incompatibile che segue le vecchie regole e non potrà inviare Ether né operare sulla rete Ethereum successiva alla Fusione.
Come validatore, posso prelevare il mio stake?
No. La Fusione è il più complicato aggiornamento di Ethereum mai eseguito finora. Al fine di minimizzare i rischi di malfunzionamenti della rete, è stato adottato un approccio minimale che ha escluso da questo aggiornamento qualsiasi cambiamento non relativo alla transizione.
I prelievi dalla Beacon Chain saranno probabilmente introdotti nel primo aggiornamento dopo la Fusione. Le specifiche per i livelli di consenso e di esecuzione sono in fase di definizione.
Dove posso formulare altre domande?
Partecipate insieme agli sviluppatori del team client, ai membri di ETHStaker, ai ricercatori e ad altri ancora alla prossima riunione della community relativa alla Fusione venerdì 9 settembre alle 14:00 UTC!
Grazie
Il passaggio di Ethereum alla proof-of-stake ha richiesto molto tempo. Grazie a tutti coloro che hanno contribuito alla ricerca, alle specifiche, allo sviluppo, all'analisi, al test, all'esame, alla correzione o alla spiegazione di tutto ciò che ci ha portato alla Fusione.
Nel corso degli anni si sono avvicendati troppi collaboratori per poterli elencare qui, ma voi sapete chi siete. Senza tutti voi del bazar, non avremmo costruito questa cattedrale.
Quando avverrà la Fusione? Molto 🔜.
Grazie a Joseph Schweitzer e Tomo Saito per l'immagine di copertina di questo post!