Sospeso il trading: Bug nei token ERC20 di Ethereum

L’exchange di criptovalute Poloniex ha sospeso tutti i depositi e i prelievi di token ERC-20 (basati su Ethereum). HitBTC ha avviato un’ispezione interna che effettua depositi e trasferimenti offline. Questo a seguito della decisione di OKEX di bloccare i depositi di token ERC20 questa mattina dopo la scoperta di un potenziale nuovo bug nello smart contract chiamato batchOverFlow.

I dettagli

We've temporarily suspended ERC-20 token deposits and withdrawals while we review all smart contracts for exposure to the reported batchOverflow bug. We take any reports of vulnerabilities very seriously to ensure that customer funds remain safe. Thank you for your patience!

— Poloniex Exchange (@Poloniex) April 25, 2018

Il tweet tradotto:

“Abbiamo temporaneamente sospeso i depositi e prelievi di token ERC20 per via dell’esposizione al bug batchOverflow riportato. Prendiamo tutte le segnalazioni di vulnerabilità molto seriamente in modo da assicurarci che i fondi dei clienti rimangano sicuri. Ringraziamo per la pazienza!”

Due to a potential issue detected in ERC20 smart contracts, we initiated an internal inspection. All deposits and transfers on ERC20 tokens will be getting online in accordance with the results of the inspection. Please refer to the System Health page for online status.

— HitBTC (@hitbtc) April 25, 2018

Segue la traduzione del tweet:

“Per via di un potenziale problema scoperto nei smart contracts ERC20, abbiamo dato il via a una ispezione interna. Tutti i depositi e trasferimenti di token ERC20 saranno messi online in accordo con i risultati dell’ispezione. Prego prendere riferimento alla pagina System Health per lo stato online.”

Una reazione da parte di molti exchange

Altre borse che hanno scelto di fermare il trading di token ERC-20 a causa della vulnerabilità recentemente scoperta. Tra questi Changelly e QUOINE. Il 23 aprile, l’utente Medium ranimes ha pubblicato un blog post dal titolo, “New batchOverflow Bug in Multiple ERC20 Smart Contracts”. Questo post descrive in dettaglio come una “vulnerabilità precedentemente sconosciuta nel contratto” potrebbe consentire ad “un aggressore di possedere una quantità enorme di token sfruttando questi contratti vulnerabili”. Questo, a sua volta, consentirebbe la manipolazione dei prezzi.

Il post sul blog osserva che, a causa del principio “code-is-law” (il codice è legge) che viene utilizzato sulla Blockchain di Ethereum (ETH), “non esiste un meccanismo tradizionale di risposta alla sicurezza ben noto in atto per porre rimedio a questi contratti vulnerabili”. Questa critica è riproposta in un tweet da Dan Larimer, “padre” di EOS, una criptovaluta che contienem meccanismi atti a risolvere simili problemi.

New eth contract bug could hack entire token supply leaving all token holders with worthless tokens. This is why code cannot be law and contracts need ability to be updated. #ethereum #eosio https://t.co/3wrCt786iG

— Daniel Larimer (@bytemaster7) April 25, 2018

Il tweet tradotto:

“Un nuovo bug nei contratti Ethereumpotrebbe protare ad una hack dell’intero approvigionamento di token lasciando i detentori di questi con token senza valore. Questo è perché il codice non può essere legge e i contratti devono poter essere aggiornati.”

Non tutti i token sono vulnerabili

L’utente di Medium John Huxtable ha commentato il post sul blog dicendo che “vale la pena notare che batchTransfer non è una funzione standard di ERC20 quindi solo i proprietari del contratto che hanno scelto di implementarlo sono vulnerabili”.

L’autore del post sul blog precedentemente citato scrive che i team che lavorano con contratto con questa vulnerabilità sono stati contattati, ma “altri exchange hanno bisogno di essere coordinati e ci sono ancora altri token negoziabili vulnerabili a batchOverflow”. Il blog menziona che un altro problema potrebbe sorgere con le borse non centralizzate che utilizzano servizi di trading offline. Questo “in quanto non possono nemmeno impedire agli attaccanti di riciclare i loro token”.

Conclusione

Il concetto “code is law” è inadatto alla maggior parte delle situazioni. Questo imprevisto è solo l’ultima dimostrazione che questo sia il caso. La quantità di smart contracts vulnerabili è alquanto assurda e il rendere impossibile rimediare è semplicemente stupido. Certo, ci sono eccezioni nelle quali l’impossibilità di apportare modifiche ad uno smart contracts comporta più vantaggi che svantaggi. In particolare in occasioni nelle quali la parte che gestisce lo smart contract non ha fiducia, ma c’è modo di rimediare anche a questo per mezzo di governance da parte dei detentori dei token. Rendere queste cose completamente statiche continua a danneggiare l’ecosistema, serve un cambiamento.

E l’EIP867 non basta. Questo non è altro che curare un sintomo. Bisogna rendere i smart contracts sospendibili ed aggiornabili. In questo modo in caso viene notata una vulnerabilità, il contratto può venire “congelato” e aggiornato risolvendo il problema. EOS intende implementare proprio questo genere di sistema, è il momento Ethereum faccia lo stesso?