Partager cet article

I client Ethereum rilasciano un nuovo software in seguito al ritardo dell'hard fork

I principali clienti Ethereum stanno rilasciando nuove versioni del loro software per impedire l'attivazione dell'hard fork Constantinople, ora posticipato.

I principali client Ethereum , tra cui Go-Ethereum (Geth) e Parity, hanno rilasciato aggiornamenti software in seguito alla precedente decisione di ritardare l'aggiornamento pianificato dell'intero sistema denominato Constantinople.

L'aggiornamento è statorinviato martedì durante una chiamata degli sviluppatori, una mossa che è arrivata dopo che la società di revisione blockchain Chain Security ha scoperto una vulnerabilità di sicurezza in Ethereum Improvement Proposal (EIP) 1283, ONE delle modifiche pianificate incluse in Constantinople. Se sfruttato, il bug avrebbe consentito "attacchi di reingresso", consentendo ad attori malintenzionati di prelevare fondi dalla stessa fonte più volte.

La Suite Ci-Dessous
Ne manquez pas une autre histoire.Abonnez vous à la newsletter Crypto for Advisors aujourd. Voir Toutes les Newsletters

Un nuovo blocco di attivazione per l'aggiornamento verrà deciso durante un'altra chiamata nel corso di questa settimana.

Per evitare che si verificasse il fork, dato che alcuni client software sulla rete erano già stati aggiornati prima del fork, gli sviluppatori delle principali implementazioni Ethereum hanno iniziato a pubblicare nuove versioni.

Geth ha rilasciato un hotfix di emergenza (versione 1.8.21) progettato per ritardare l'aggiornamento, anche se lo sviluppatore Péter Szilágyi ha fatto notare che gli utenti che non desiderano eseguire l'aggiornamento alla nuova versione del client possono anche eseguire il downgrade dei loro client esistenti alla versione 1.8.19 o continuare a eseguire la versione corrente (1.8.20) con un override.

Allo stesso modo, i clienti Parity possono aggiornare i loro client esistenti alla versione 2.2.7 (la versione stabile) o 2.3.0 (una versione beta) oppure effettuare il downgrade alla versione 2.2.4 (beta).

Il responsabile della sicurezza di Parity Technologies, Kirill Pimenov, parlando in unchat degli sviluppatori di Ethereum COREsu Gitter, ha affermato di aver consigliato agli utenti di eseguire l'aggiornamento alla nuova versione, piuttosto che eseguire il downgrade a una versione precedente, spiegando:

"Voglio ribadire: declassare Parity alle versioni pre-Costantinopoli è una cattiva idea, T lo consigliamo a nessuno. In teoria dovrebbe anche funzionare, ma T vogliamo avere a che fare con questo pasticcio."

Allo stesso modo, Afri Schoedon, responsabile delle release di Parity, ha dichiarato a CoinDesk che consiglia la versione 2.2.7, anche se anche le altre due dovrebbero funzionare altrettanto bene.

In un post di blog, lo sviluppatore CORE Hudson Jameson ha scritto che chiunque non gestisca un nodo o non partecipi in altro modo alla rete non deve fare nulla.

Anche i titolari di contratti intelligenti non devono fare nulla, anche se "potrebbero scegliere di esaminare l'analisi della potenziale vulnerabilità e controllare i propri contratti", ha scritto.

Ha tuttavia sottolineato che la modifica che potrebbe causare il potenziale problema non verrà abilitata.

Al momento della pubblicazione del post del blog, i ricercatori di sicurezza di ChainSecurity,chi ha scoperto inizialmente il buge TrailOfBits stanno analizzando l'intera blockchain.

Attacchi di rientro

Finora non sono stati scoperti casi di vulnerabilità nei contratti attivi. Tuttavia, Jameson ha osservato che "esiste ancora un rischio diverso da zero che alcuni contratti possano essere interessati".

Per evitare attacchi di reentrance nei trasferimenti su Ethereum , viene pagata una piccola quantità di Ether, chiamata GAS , che impedisce agli aggressori di riutilizzare un trasferimento per rubare fondi.

Tuttavia, come spiegato a CoinDesk da Hubert Ritzdorf, la persona che ha scoperto la vulnerabilità e CTO di Chain Security, un "effetto collaterale" dell'EIP 1283 garantisce che gli aggressori possano sfruttare questa piccola quantità di GAS per scopi dannosi.

"La differenza è che prima T si poteva fare qualcosa di malevolo con questa piccola BIT di GAS, si poteva fare qualcosa di utile ma non malevolo, mentre ora, poiché alcune operazioni sono diventate più economiche, è possibile fare qualcosa di malevolo con questa piccola BIT di GAS", ha affermato Ritzdorf.

Sebbene il problema della reentrancy sia sempre al centro dell'attenzione degli sviluppatori di smart contract che scrivono codice in Solidity su Ethereum, Matthias Egli, COO di Chain Security, ha spiegato che gli sviluppatori CORE che si occupano esclusivamente della meccanica della macchina virtuale T avrebbero potuto individuare facilmente questa vulnerabilità.

Ha detto a CoinDesk:

"È una questione di Solidity, non è una questione CORE [ Ethereum virtual machine] che in pratica ha permesso questo attacco. Quello era parte di questa disconnessione che in pratica piccole modifiche al costo GAS consentiranno nuovi tipi di attacchi che T erano stati presi in considerazione prima."

Inoltre, Ritzdorf ha aggiunto che la soluzione a questo problema T è semplice come aggiornare i limiti dei costi GAS di Ethereum, spiegando che "se ora modificassimo questo importo in un numero piccolo, risolveremmo la vulnerabilità ma interromperemmo anche molti contratti [intelligenti] esistenti".

Pertanto, per il momento, secondo Egli, posticipare Costantinopoli è stata la scelta giusta da parte degli sviluppatori CORE .

"È stata la decisione giusta perché almeno dà un po' di tempo ai ricercatori per valutare l'impatto nel mondo reale. Con alta probabilità, questo [EIP] verrà ritirato e non incluso nel prossimo hard fork che ora è in ritardo di forse un mese", ha sostenuto.

Prossimi passi

Al momento in cui scriviamo, gli sviluppatori stanno contattando exchange, wallet, mining pool e altri gruppi che utilizzano o interagiscono con la rete Ethereum .

Gli sviluppatori CORE hanno in programma di discutere i passaggi a lungo termine, tra cui quando eseguire Constantinople e come risolvere il bug in EIP 1283, durante un'altra chiamata il 18 gennaio.

Molti sviluppatori hanno suggerito di avviare una sorta di programma di bug bounty incentrato sull'analisi del codice, per garantire che i bug futuri vengano scoperti con largo anticipo, piuttosto che "proprio prima del giorno [hard fork]."

Szilágyi ha osservato che l'EIP è stato disponibile per la revisioneper quasi un anno,aggiungendo che"Forse non è una cattiva idea erogare delle sovvenzioni per occhi più attenti."

Immagine del codicetramite Shutterstock

Nikhilesh De

Nikhilesh De è il caporedattore di CoinDesk per la Politiche e la regolamentazione globali, che si occupa di regolatori, legislatori e istituzioni. Quando non scrive di asset e Politiche digitali, lo si può trovare ad ammirare Amtrak o a costruire treni LEGO. Possiede < $ 50 in BTC e < $ 20 in ETH. È stato nominato giornalista dell'anno dall'Association of Criptovaluta Journalists and Researchers nel 2020.

Nikhilesh De
Christine Kim

Christine è un'analista di ricerca per CoinDesk. Si concentra sulla produzione di approfondimenti basati sui dati sul settore delle Criptovaluta e della blockchain. Prima del suo ruolo di analista di ricerca, Christine era una reporter tecnologica per CoinDesk, occupandosi principalmente degli sviluppi sulla blockchain Ethereum . Portafoglio Criptovaluta : nessuno.

Christine Kim