L’ultima mazzata alla credibilità di Ethereum viene da queste news di Aprile che descrivono come da una semplice transazione del BeautyToken BEC di non so quanti trilioni di trilioni di token ognuno con un controvalore di circa $0.32 sarebbe la più grande transazione commerciale della storia. Vedere per credere i massimi token holder al momento
https://etherscan.io/token/0xc5d105e63711398af9bbff092d4b6769c82f793d#balances
Purtroppo, pare che questo bug non sia limitato al solo BEC token ma una dozzina di altri token abbiano evidentemente copy/pasted lo stesso codice. Qui una lista di quelli noti
Ovviamente di tratta di glitch, bugs, exploit di qualche malfunzionamento del codice. Come risposta gli exchange hanno chiuso tutte le transazioni di token ERC20 (per chi non lo sapesse ERC20 sono le specifiche che descrivono come uno smart contract Ethereum deve essere fatto per funzionare come un token).
Sembra che tutto il problema derivi da questa funzione batchTransfer ( )
che vorrebbe in pratica con una sola transazione spedire un po’ di token a diversi destinatari. Una specie di airdrop insomma.
Ma si sa, la programmazione è la diabolica arte di inserire bug nei programmi, oppure se preferite un programma è il codice che sembra funzionare tra un bug e l’altro. Insomma per farla breve questo codice presenta un problema di overflow.
2 + 2 = 0
se il vostro registro è fatto con soli due bit. Se i bit sono 256 il concetto non cambia.
A prima vista si direbbe che i devs fossero consapevoli dei problemi di overflow perché hanno utilizzato la SafeMath library (questo lo capiamo dal fatto che somme e sottrazioni sono nella forma .sub( ) e .add( )
Importare e usare queste librerie che sono scritte apposta per evitare gli overflow è una condizione necessaria ma non sufficiente. Soprattutto se da qualche parte ti dimentichi di usarla come avviene nella riga 257. Passando alla funzione batchTransfer( ) dei parametri opportunamente forgiati:
batchTransfer([addressA,addressB],0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000)
avviene il fattaccio, ovvero che la variabile amount nella linea 257 diventa
uint256 amount = 2 * 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000
che è esattamente 0 a causa dell’overflow.
Quindi il successivo require alla linea 259 risulta rispettato e il codice successivo viene eseguito quando invece non dovrebbe.
Risultato finale: addressB e addressA ricevono dal nulla la modesta cifra di 0x8000<altri 60 zeri a seguire> token che significa 2^255 token a testa. Non male.
Di chi è la colpa?
Colpa di Ethereum!!! colpa di Vitalik !!! colpa dei token !!!.
Si è letto un po’ di tutto in giro. Soprattutto FUD. Ci sta che gli exchange sospendano le transazioni ERC20 per verificare quali di questi token tra le migliaia ormai listate possano soffrire della stessa vulnerabilità. Ma bisogna specificare che questo è un bug di chi ha scritto lo smart contract per questi token e non è un bug della piattaforma Ethereum.
Secondo punto, non è nemmeno qualcosa che deriva dallo standard ERC20 che non prevede la possibilità di fare questo batchTransfer( ). Ricordiamo quali sono le funzioni previste per ERC20
Quindi non è colpa di Vitalik se non nella misura in cui Ethereum è stato progettato per permettere a chiunque di mettere user code in blockchain. Ma questa in fondo è la più grande forza di Ethereum, senza di questa ci bastava Bitcoin (e per molti effettivamente è così).
Rispondi