Gli sviluppatori Ethereum propongono di attivare l'hard fork di Constantinople a fine febbraio

AGGIORNAMENTO (18 gennaio 2019, 15:40 UTC):L'attivazione dell'hard fork di Constantinople è stata impostata per il blocco numero 7.280.000, la cui data di uscita è prevista per il 27 febbraio, secondo lo sviluppatorePietro Szilágyi.

----------

Gli sviluppatori CORE Ethereum hanno proposto di attivare Constantinople, un aggiornamento pianificato per l'intero sistema che è stato annullato all'inizio di questa settimana, a fine febbraio.

Conosciuto anche come hard fork, gli sviluppatori stimano che Constantinople sarà disponibile tra il 26 e il 28 febbraio, con un numero di blocchi che verrà determinato in una data futura.

La proposta è stata fatta durante una telefonata con uno sviluppatore CORE il Venerdì mattina, e tra i partecipanti alla chiamata c'erano il creatore Ethereum Vitalik Buterin e altri sviluppatori, tra cui Hudson Jameson, Lane Rettig, Afri Schoedon, Péter Szilágyi, Martin Holste Swende, Danny Ryan e Alexey Akhunov, tra gli altri.

La decisione arriva dopo che la società di revisione dei contratti intelligenti ChainSecurity ha segnalatoMartedì una vulnerabilità di sicurezza in ONE delle cinque proposte di miglioramento Ethereum (EIP) destinate all'inclusione a Costantinopoli, in relazione ai costi di archiviazione dei dati sulla blockchain.

A causa della vulnerabilità, Constantinople, la cui attivazione è prevista per il mese prossimo, non includerà l'EIP difettoso, che verrà testato e rimodellato per l'inclusione in un hard fork successivo.

Invece, Constantinople verrà rilasciato in due parti contemporaneamente sulla rete principale. Il primo aggiornamento includerà tutti e cinque gli EIP originali e un secondo aggiornamento rimuoverà specificamente l'EIP 1283.

Questa strategia, suggerita per la prima volta da Szilágyi durante la chiamata odierna, ha lo scopo di garantire che le reti di prova e le reti private che hanno già implementato l'aggiornamento completo di Constantinople possano facilmente implementare una correzione senza annullare alcun blocco.

"Il mio suggerimento è di definire due hard fork, Constantinople così com'è attualmente e Constantinople fix up che disabilita semplicemente questa funzionalità... Avendo due fork, chiunque abbia effettivamente effettuato l'aggiornamento può avere un secondo fork per effettuare un downgrade, per così dire", ha spiegato Szilágyi.

La decisione è stata presa dopo che martedì la società di revisione contabile dei contratti intelligenti ChainSecurity ha segnalato una vulnerabilità di sicurezza in ONE dei cinque EIP destinati all'inclusione in Constantinople, in relazione ai costi di archiviazione dei dati sulla blockchain.

Parlando conCoinDesk Martedì, Matthias Egli – COO di ChainSecurity – ha sottolineato che il problema probabilmente non è stato individuato dagli sviluppatori CORE durante l’esecuzione dei test sul software, dato che l’impatto è radicato nello sviluppo di contratti intelligenti, non necessariamente nello sviluppo “ CORE [della macchina virtuale Ethereum ]”.

Una decisione tempestiva di riattivare Constantinople il prima possibile si è resa necessaria in parte a causa dell'attivazione prolungata della bomba di difficoltà di Ethereum, un pezzo di codice incorporato nella blockchain che allunga progressivamente i tempi di blocco.

Destinato a incoraggiare la transizione verso un nuovo algoritmo di consenso noto comeprova di partecipazione (PoS), nell'EIP 1234 è stato suggerito un ritardo della bomba a causa dell'attuale insufficiente ricerca per una transizione al PoS.

Una volta attivato sulla rete principale, Constantinople includerà EIP 1234 e rinvierà il livello di difficoltà per un periodo di 12 mesi.

Nota dell'editore: L'articolo è stato aggiornato con informazioni aggiuntive.

Codice binarioimmaginetramite Shutterstock