Erik Weijers, un anno fa
Ieri ci si è concentrati non solo sul calo del prezzo dell'Ether, ma anche sulla Beacon Chain. Qui ha avuto luogo una cosiddetta "riorganizzazione dei blocchi" di ben sette blocchi di profondità. Tali riorganizzazioni si verificano occasionalmente sulle catene proof-of-work, ma la speranza era che fossero un ricordo del passato sulla catena proof-of-stake di Ethereum. Dobbiamo preoccuparci?
La catena Beacon di Ethereum è la catena parallela su cui viene testata a fondo la proof-of-stake. Dopo il merge (si spera) della seconda metà del 2022, Ethereum funzionerà davvero su quella che attualmente è una rete di prova proof-of-stake. Quindi c'è ancora tempo per individuare le vulnerabilità. La riorganizzazione dei blocchi è stato uno di quei momenti in cui gli sviluppatori si sono scambiati DM: cosa sta succedendo qui? Può essere dannoso? Sembra di no.
Quando si concatenano i blocchi delle transazioni, è normale che si verifichi un fork per un breve periodo di tempo. Come avviene questo fenomeno? Nelle catene Proof-of-work come Bitcoin, è perché due minatori hanno completato il loro "puzzle" quasi nello stesso momento e sono autorizzati a creare un blocco. Essi inviano questo blocco ai nodi. Se ciò avviene quasi contemporaneamente, è più probabile che alcuni nodi approvino un blocco e altri nodi un altro. Si verificherà quindi una biforcazione (split). Questa si risolve di solito con il blocco successivo, dopo il quale la catena vincente è l'unica rimasta. La possibilità che la creazione di blocchi quasi simultanei si ripeta è molto bassa, per non parlare di quella che si verifichi per tre o quattro volte di seguito. (Questa possibilità di biforcazione è il motivo per cui molti scambi e wallet di criptovalute attendono un certo numero di conferme/blocchi. Solo quando una transazione è nascosta a quattro, cinque, sei blocchi di profondità c'è una possibilità quasi nulla che possa essere invertita).
Come è potuto accadere che la catena Beacon di Ethereum abbia avuto questo conflitto per ben sette blocchi (per inciso, il tempo di blocco di Ethereum è di soli 12 secondi circa)? Ha a che fare con i diversi client Ethereum (versioni del software Ethereum) che erano in circolazione. Alcuni nodi stavano eseguendo client sui quali era già stata apportata una modifica al protocollo, mentre altri non avevano ancora effettuato l'aggiornamento.
L'aggiornamento del protocollo in questione riguardava la cosiddetta funzione boost. Questa funzione garantisce che i blocchi creati rapidamente vengano distribuiti più rapidamente, proprio per evitare che circolino versioni contrastanti della catena. Poiché non tutti i client avevano implementato questa funzione di boost, i diversi nodi traevano conclusioni diverse su quale fosse il blocco giusto su cui basare il resto della catena.
Questo è ciò che sembra essere accaduto. L'autopsia esatta seguirà senza dubbio in seguito. Come già detto, il verificarsi di fork temporanei e successive riorganizzazioni non è di per sé un problema. Senza dubbio tutti i clienti inizieranno a implementare questa funzione di boost, dopo di che questo tipo di riorganizzazione dei blocchi non si verificherà più.
La riorganizzazione del blocco non aveva nulla a che fare con un attacco al sistema, un tentativo di doppia spesa - nemmeno un bug, in realtà. Quindi non c'era nulla di troppo grave. Ma il fatto che questo tipo di evento non sia stato previsto dagli sviluppatori di Ethereum la dice lunga sulla complessità del passaggio alla proof-of-stake. Si tratta di un sistema di convalida delle transazioni molto, molto più complesso del proof-of-work. I prossimi mesi e anni - anche dopo il merge - dovrebbero rivelare quali sorprese sono ancora in serbo.
Iscriviti per rimanere informato tramite i nostri aggiornamenti e-mail