- Torna al menu
- Torna al menuPrezzi
- Torna al menuRicerca
- Torna al menuConsenso
- Torna al menu
- Torna al menu
- Torna al menu
- Torna al menuWebinar ed Eventi
ONE dei primi linguaggi per contratti intelligenti di Ethereum è destinato al pensionamento
ONE dei più vecchi linguaggi di smart contracting Ethereum sta mostrando segni di invecchiamento e potrebbe indicare debolezze sottostanti nell'economia dei token.
Serpent, ONE dei primi linguaggi per gli smart contract di Ethereum, non è più sicuro da usare.
Potrebbe essere il più grandeporta viada un audit del linguaggio di compilazione Serpent di Ethereum, pubblicato la scorsa settimana dalla società di sicurezza blockchain Zeppelin Solutions. I risultati indicano decine di problemi con il compilatore, tra cui otto vulnerabilità critiche.
Zeppelin è stata assunta da Augur, un mercato di previsione basato su ethereum, per condurre l'audit due mesi fa. Con quasi 2 milioni di dollaridel suo token (REP) inserito in un contratto scritto in Serpent, Augur aveva buone ragioni per preoccuparsi della sicurezza del vecchio linguaggio.
Augur è stato ONE dei primi progetti Ethereum e, al momento in cui è stato scritto il suo contratto token, Serpent era il principale linguaggio di smart contract disponibile. Ma subito dopo, è stato introdotto Solidity e ha preso il sopravvento come linguaggio di programmazione di punta per smart contract di ethereum, spingendo Serpent in secondo piano.
Nonostante ciò, il CEO Augur Joey Krug ha affermato che sono stati pochi gli avvertimenti pubblici circa possibili problemi che avrebbero impedito a Serpent di eseguire il codice come previsto.
Ha detto a CoinDesk:
"Nessuno ha mai detto che Serpent fosse insicuro o deprezzato. Semplicemente T era popolare [come Solidity]."
Mentre Augur aveva pianificato di passare a un altro linguaggio di smart contract a un certo punto, i risultati dell'audit del compilatore hanno sostanzialmente forzato la mano del progetto. Non appena Zeppelin ha informato Augur dei problemi di sicurezza coinvolti, Augur mosso rapidamente per migrare i suoi token REP su un server sicuro ERC-20contratto token scritto in Solidity.
"Scarsa qualità" e "difettoso"
Per gli altri che si chiedono se dovrebbero Seguici l'esempio, Zeppelin Solutions ha spiegato i risultati completi del suo audit in un Rapporto di 36 pagine.
In unpost del blog, Zeppelin definì il progetto Serpent "di bassa qualità" e "imperfetto", e raccomandò agli sviluppatori di astenersi dall'utilizzare il linguaggio finché i suoi numerosi problemi critici non fossero stati risolti.
La notizia ha spinto il fondatore Ethereum Vitalik Buterin a inviare un twittare, definendo il linguaggio di programmazione "tecnologia obsoleta" e avvertendo che mancava di adeguate "protezioni di sicurezza".
Per quanto riguarda Augur, la vulnerabilità più critica di Serpent era ONE che avrebbe consentito a un hacker di modificare la data di creazione del contratto del token REP , congelando di fatto la fornitura di token.
"Si potrebbe far credere al contratto che in realtà non è ancora stato creato ufficialmente, in modo che sostanzialmente nessuno dei trasferimenti funzionerebbe", ha affermato Krug.
Se Serpent avesse avuto solo ONE problema, Krug ha detto che avrebbe volentieri sistemato il codice e continuato a usare il linguaggio per il momento. Ma il numero di problemi rivelati dall'audit era semplicemente troppo schiacciante.
Quindi, seguendo un percorso di aggiornamento delineato da Zeppelin, Augur si è mosso per riscrivere il suo vecchio token REP in Solidity e implementare il nuovo contratto ERC-20 su Ethereum. Ha quindi hackerato in modo efficace il suo stesso smart contract Serpent, congelando il token REP , prima di migrare il saldo del REP congelato al nuovo contratto.
In un separatopost del blogZeppelin ha esortato tutti i progetti Ethereum che utilizzano ancora Serpent a Seguici un percorso di migrazione simile per spostare i propri token su un contratto Solidity più sicuro.
Servono più occhi
Il linguaggio di programmazione e il compilatore Serpent sono stati entrambi scritti da Buterin. Ma il fatto che solo ONE persona abbia scritto il codice potrebbe essere alla base di alcuni dei problemi di Serpent.
Zeppelin scrisse nel suo rapporto:
"Meno occhi puntati sul codice significa meno bug notati."
Zeppelin ha anche sottolineato che Serpent ha due anni, con pochi commit da ottobre 2015. In aggiunta a ciò, con quasi nessuno che usa Serpent ora, ci sono poche possibilità che qualcuno individui problemi nel codice o che questi problemi vengano risolti.
Solidity, d'altra parte, è stato scritto da unsquadra di personeguidato daLegno di Gavin, ONE dei fondatori di Ethereum. E poiché Solidity è più ampiamente utilizzato e vede molta più attività (30 volte le richieste di pull, 20 volte i commit, otto volte più Collaboratori, secondo Zeppelin) rispetto a Serpent, è meno probabile che il programma più recente abbia lo stesso numero di problemi.
Per quanto riguarda cosa gli sviluppatori dovrebbero usare al posto di Serpent, il rapporto Zeppelin suggerisce che Solidity è la migliore risposta disponibile oggi. Tuttavia, suggerisce anche che gli sviluppatori prendano in considerazione Viper, un successore di Serpent, affermando che Viper "LOOKS superiore" a Serpent. Ma in un twittareButerin ha raccomandato agli sviluppatori di aspettare che Viper superi prima un audit esterno.
Verifica della solidità?
Ma forse ONE dei problemi più allarmanti portati alla luce dall'audit del compilatore Serpent di Zeppelin è che neanche Solidity è stato sottoposto ad audit. E dato che milioni di dollari di token sono attualmente gestiti da smart contract scritti in Solidity, alcuni, tra cui Krug, trovano questa notizia inquietante.
Ad aumentare le preoccupazioni su Solidity, la verifica del compilatore Zeppelin arriva subito dopo un hack da 30 milioni di dollari del portafoglio Parity, dove unbug nel codice Parityha sostanzialmente permesso all'hacker di trasformare tre portafogli multi-firma in portafogli senza firma e di prosciugare i fondi.
In unpost del blogIn seguito a quell'attacco, Parity ha puntato il dito contro Solidity, affermando che "parte della colpa di questo bug ricade sul linguaggio Solidity e, nella sua attuale incarnazione, sulla difficoltà con cui ONE possono comprendere i permessi di esecuzione sulle funzioni".
Ma un furto Ethereum ancora più grande è avvenuto poco più di un anno fa, quando un hacker ha sfruttato una falla nel codice Solidity per sottrarre 50 milioni di dollari in ether da un progetto chiamato The DAO. Il danno è stato ritenuto così esteso che gli sviluppatori di Ethereum hanno implementato un hard fork nel protocollo per ripristinare la cronologia delle transazioni.
Gli audit del codice software sono un requisito in molti settori critici e Demian Brener, CEO di Zeppelin, ritiene che lo stesso principio dovrebbe essere applicato al codice degli smart contract.
"Dato il numero di vulnerabilità scoperte in Serpent, crediamo che gli audit del compilatore, insieme agli audit del codice, dovrebbero diventare una buona pratica", ha scritto in un'e-mail a CoinDesk. Ha aggiunto che Zeppelin sta attualmente parlando con la Ethereum Foundation per far sì che ciò accada.
Nel frattempo, Krug ha riassunto i suoi pensieri sulla questione dicendo:
"In generale, il messaggio è che più cose andrebbero sottoposte a verifica".
Pelle di serpenteimmagine tramite Shutterstock