Uma das primeiras linguagens de contrato inteligente do Ethereum está prestes a se aposentar

Serpent, uma das primeiras linguagens de contratação inteligente do Ethereum, não é mais segura para uso.

Essa pode ser a maiorremoverde uma auditoria da linguagem de compilação Serpent do ethereum, divulgada na semana passada pela empresa de segurança de blockchain Zeppelin Solutions. As descobertas apontam para dezenas de problemas com o compilador, incluindo oito vulnerabilidades críticas.

A Zeppelin foi contratada pela Augur, um mercado de previsão baseado em ethereum, para conduzir a auditoria há dois meses. Com quase US$ 2 milhõesde seu token (REP) contido em um contrato escrito em Serpent, Augur tinha bons motivos para se preocupar com a segurança da linguagem mais antiga.

Augur foi um dos primeiros projetos de Ethereum , e na época em que seu contrato de token foi escrito, Serpent era a principal linguagem de contrato inteligente disponível. Mas logo depois, Solidity foi introduzida e assumiu como a principal linguagem de programação de contrato inteligente do ethereum, empurrando Serpent para o lado.

Mesmo assim, o CEO da Augur, Joey Krug, disse que houve poucos avisos públicos sobre possíveis problemas que impediriam a Serpent de executar o código conforme o esperado.

Ele disse ao CoinDesk:

"Ninguém nunca disse que Serpent era inseguro ou depreciado. Ele simplesmente T era tão popular [quanto Solidity]."

Embora Augur tivesse planejado mudar para outra linguagem de contrato inteligente em algum momento, os resultados da auditoria do compilador essencialmente forçaram a mão do projeto. Assim que Zeppelin notificou Augur sobre os problemas de segurança envolvidos, Augur moveu-se rapidamente para migrar seus tokens REP para um local seguro ERC-20contrato de token escrito em Solidity.

'Baixa qualidade' e 'falho'

Para outros que estão se perguntando se devem Siga o exemplo, a Zeppelin Solutions divulgou os resultados completos de sua auditoria em um Relatório de 36 páginas.

Em umpostagem de blog, Zeppelin chamou o projeto Serpent de "baixa qualidade" e "falho", e alertou os desenvolvedores para que evitassem usar a linguagem até que seus muitos problemas críticos fossem corrigidos.

A notícia levou o fundador do Ethereum , Vitalik Buterin, a enviar uma tuitar, chamando a linguagem de programação de "tecnologia ultrapassada" e alertando que ela não possuía "proteções de segurança" adequadas.

Quanto ao Augur, a vulnerabilidade mais crítica do Serpent era ONE que permitia que um hacker alterasse a data em que o contrato do token REP foi criado, essencialmente congelando o fornecimento de tokens.

"Você poderia fazer o contrato pensar que ele ainda não havia sido oficialmente criado, de modo que basicamente nenhuma das transferências funcionaria", disse Krug.

Se Serpent tivesse apenas ONE problema, Krug disse que teria consertado o código alegremente e continuado a usar a linguagem por enquanto. Mas o número de problemas revelados pela auditoria era simplesmente esmagador demais.

Então, em vez disso, seguindo um caminho de atualização delineado pelo Zeppelin, Augur decidiu reescrever seu antigo token REP em Solidity e implantar o novo contrato ERC-20 no Ethereum. Ele então efetivamente hackeou seu próprio contrato inteligente Serpent, congelando o token REP , antes de migrar o saldo do REP congelado para o novo contrato.

Em um separadopostagem de blog, Zeppelin pediu que todos os projetos de Ethereum que ainda usam Serpent Siga um caminho de migração semelhante para mover seus tokens para um contrato Solidity mais seguro.

Mais olhos necessários

A linguagem de programação Serpent e o compilador foram ambos escritos por Buterin. Mas o fato de apenas uma pessoa ter escrito o código pode estar por trás de alguns dos problemas do Serpent.

O Zeppelin escreveu em seu relatório:

"Menos olhos no código significa menos bugs sendo percebidos."

O Zeppelin também destacou que o Serpent tem dois anos, com poucos commits desde outubro de 2015. Além disso, com quase ninguém usando o Serpent atualmente, há pouca possibilidade de alguém detectar problemas no código ou de esses problemas serem corrigidos.

Solidity, por outro lado, foi escrita por umequipe de pessoasliderado porGavin Madeira, um dos fundadores do Ethereum. E como o Solidity é mais amplamente usado e vê muito mais atividade – 30 vezes mais solicitações de pull, 20 vezes mais commits, oito vezes mais Colaboradores, de acordo com o Zeppelin – comparado ao Serpent, o programa mais novo tem menos probabilidade de ter o mesmo número de problemas.

Quanto ao que os desenvolvedores devem usar em vez do Serpent, o relatório do Zeppelin sugere que o Solidity é a melhor resposta disponível hoje. No entanto, ele também sugere que os desenvolvedores considerem o Viper, um sucessor do Serpent, afirmando que o Viper "LOOKS superior" ao Serpent. Mas em um tuitarButerin recomendou que os desenvolvedores esperassem até que o Viper passasse por uma auditoria externa primeiro.

Auditoria de solidez?

Mas, talvez uma das questões mais alarmantes trazidas à tona pela auditoria do compilador Serpent da Zeppelin é que a própria Solidity também não foi auditada. E dado que milhões de dólares em tokens são atualmente gerenciados por contratos inteligentes escritos em Solidity, alguns, incluindo Krug, acham essa notícia inquietante.

Aumentando as preocupações sobre a Solidity, a auditoria do compilador Zeppelin vem na esteira de um hack de US$ 30 milhões da carteira Parity, onde umbug no código de paridadeessencialmente permitiu que o hacker transformasse três carteiras com múltiplas assinaturas em carteiras com assinatura zero e drenasse os fundos.

Em umpostagem de blogApós esse ataque, Parity apontou o dedo para o Solidity, afirmando que "parte da culpa por esse bug está na linguagem Solidity e, em sua versão atual, na dificuldade com que ONE pode entender as permissões de execução de funções".

Mas um roubo de Ethereum ainda maior ocorreu há pouco mais de um ano, quando um hacker aproveitou uma brecha no código Solidity para desviar US$ 50 milhões em ether de um projeto chamado The DAO. O dano foi considerado tão extenso que os desenvolvedores por trás do Ethereum implementaram um hard fork no protocolo para reverter seu histórico de transações.

Auditorias de código de software são um requisito em muitos setores críticos, e Demian Brener, CEO da Zeppelin, acredita que o mesmo deve ser feito para código de contrato inteligente.

"Dado o número de vulnerabilidades descobertas no Serpent, acreditamos que auditorias de compiladores, junto com auditorias de código, devem se tornar uma prática recomendada", ele escreveu em um e-mail para a CoinDesk. Ele acrescentou que o Zeppelin está atualmente conversando com a Ethereum Foundation para fazer isso acontecer.

Enquanto isso, Krug resumiu seus próprios pensamentos sobre o assunto dizendo:

"No geral, a mensagem é que mais coisas devem ser auditadas."

Pele de cobraimagem via Shutterstock