Поділитися цією статтею

ONE de los primeros lenguajes de contratos inteligentes de Ethereum está a punto de ser retirado

ONE de los lenguajes de contratos inteligentes de Ethereum más antiguos está mostrando signos de antigüedad y esto puede indicar debilidades subyacentes en la economía de tokens.

Serpent, ONE de los primeros lenguajes de contratos inteligentes de Ethereum, ya no es seguro de usar.

Ese podría ser el más grandellevarSegún una auditoría del lenguaje de compilación Serpent de Ethereum, publicada la semana pasada por la firma de seguridad blockchain Zeppelin Solutions, los hallazgos apuntan a docenas de problemas con el compilador, incluyendo ocho vulnerabilidades críticas.

Продовження Нижче
Не пропустіть жодної історії.Підпишіться на розсилку Crypto for Advisors вже сьогодні. Переглянути Всі Розсилки

Zeppelin fue contratado por Augur, un mercado de predicciones basado en Ethereum, para realizar la auditoría hace dos meses. Con casi 2 millones de dólaresDado que su token (REP) se encuentra en un contrato escrito en Serpent, Augur tenía buenos motivos para preocuparse por la seguridad del lenguaje antiguo.

Augur fue ONE de los primeros proyectos de Ethereum , y cuando se redactó su contrato de token, Serpent era el principal lenguaje de contratos inteligentes disponible. Sin embargo, poco después se introdujo Solidity, que se convirtió en el lenguaje insignia de programación de contratos inteligentes de Ethereum, dejando a Serpent relegado a un segundo plano.

Aun así, el CEO de Augur , Joey Krug, dijo que hubo pocas advertencias públicas sobre posibles problemas que podrían impedir que Serpent ejecutara el código como se esperaba.

Le dijo a CoinDesk:

"Nadie dijo que Serpent fuera inseguro o desvalorizado. Simplemente no era tan popular [como Solidity]".

Si bien Augur había planeado migrar a otro lenguaje de contratos inteligentes en algún momento, los resultados de la auditoría del compilador prácticamente forzaron el proyecto. En cuanto Zeppelin notificó a Augur sobre los problemas de seguridad involucrados, Augur... se movió rápidamente para migrar sus tokens REP a un lugar seguro ERC-20contrato de token escrito en Solidity.

'Baja calidad' y 'defectuoso'

Para aquellos que se preguntan si deberían Síguenos el ejemplo, Zeppelin Solutions ha detallado los resultados completos de su auditoría en un Informe de 36 páginas.

En unentrada de blogZeppelin calificó el proyecto Serpent de "baja calidad" y "defectuoso", y advirtió a los desarrolladores que se abstuvieran de usar el lenguaje hasta que se solucionaran sus numerosos problemas críticos.

La noticia impulsó al fundador de Ethereum , Vitalik Buterin, a enviar un piar, calificando el lenguaje de programación de "tecnología obsoleta" y advirtiendo que carecía de "protecciones de seguridad" adecuadas.

En cuanto a Augur, la vulnerabilidad más crítica de Serpent era una que permitía a un hacker cambiar la fecha en la que se creó el contrato del token REP , congelando esencialmente el suministro de tokens.

"Se podría hacer creer que el contrato no ha sido formalizado aún, y así ninguna de las transferencias funcionaría", explicó Krug.

Si Serpent solo hubiera tenido ONE problema, Krug afirmó que habría corregido el código con gusto y habría seguido usando el lenguaje por el momento. Pero la cantidad de problemas revelados por la auditoría fue simplemente abrumadora.

En lugar de eso, y siguiendo el camino de actualización delineado por Zeppelin, Augur decidió reescribir su antiguo token REP En Solidity, implementó el nuevo contrato ERC-20 en Ethereum. Posteriormente, hackeó su propio contrato inteligente Serpent, congelando el token REP , antes de migrar el saldo del REP congelado al nuevo contrato.

En un aparteentrada de blogZeppelin instó a cualquier proyecto de Ethereum que todavía use Serpent a Síguenos una ruta de migración similar para mover sus tokens a un contrato Solidity más seguro.

Se necesitan más ojos

Tanto el lenguaje de programación como el compilador Serpent fueron escritos por Buterin. Sin embargo, el hecho de que solo una persona escribiera el código podría ser la causa de algunos de los problemas de Serpent.

Zeppelin escribió en su informe:

"Menos ojos en el código significa que se detectan menos errores".

Zeppelin también señaló que Serpent tiene dos años, con pocas confirmaciones desde octubre de 2015. Además de eso, como casi nadie usa Serpent ahora, hay pocas posibilidades de que alguien detecte problemas en el código o de que esos problemas se solucionen.

Solidity, por otro lado, fue escrita por unequipo de personasdirigido porGavin Wood, ONE de los fundadores de Ethereum. Y dado que Solidity se usa más ampliamente y registra mucha más actividad (según Zeppelin, 30 veces más solicitudes de extracción, 20 veces más confirmaciones y ocho veces más Colaboradores), en comparación con Serpent, el programa más nuevo tiene menos probabilidades de tener la misma cantidad de problemas.

En cuanto a qué deberían usar los desarrolladores en lugar de Serpent, el informe de Zeppelin sugiere que Solidity es la mejor opción disponible actualmente. Sin embargo, también sugiere que los desarrolladores consideren Viper, un sucesor de Serpent, afirmando que Viper "LOOKS superior" a Serpent. Pero en un piarButerin recomendó a los desarrolladores esperar hasta que Viper pase primero una auditoría externa.

¿Auditoría de Solidity?

Pero quizás ONE de los problemas más alarmantes que la auditoría del compilador Serpent de Zeppelin ha sacado a la luz es que Solidity tampoco ha sido auditada. Y dado que millones de dólares en tokens se gestionan actualmente mediante contratos inteligentes escritos en Solidity, algunos, como Krug, encuentran esta noticia inquietante.

Para aumentar las preocupaciones sobre Solidity, la auditoría del compilador Zeppelin se produce poco después de un hackeo de $30 millones a la billetera Parity, donde unerror en el código de ParityBásicamente permitió al pirata informático convertir tres billeteras multi-firma en billeteras cero-firma y drenar los fondos.

En unentrada de blogTras ese ataque, Parity atribuyó la culpa a Solidity, afirmando que "parte de la culpa de este error recae en el lenguaje Solidity y, en su encarnación actual, en la dificultad con la que ONE pueden entender los permisos de ejecución de las funciones".

Pero hace poco más de un año se produjo un robo de Ethereum aún mayor, cuando un hacker aprovechó una vulnerabilidad en el código de Solidity para desviar 50 millones de dólares en ether de un proyecto llamado The DAO. El daño fue tan grave que los desarrolladores de Ethereum implementaron una bifurcación dura en el protocolo para revertir su historial de transacciones.

Las auditorías de código de software son un requisito en muchas industrias críticas, y Demian Brener, CEO de Zeppelin, cree que se debería decir lo mismo del código de contrato inteligente.

"Dada la cantidad de vulnerabilidades descubiertas en Serpent, creemos que las auditorías de compiladores, junto con las auditorías de código, deberían convertirse en una buena práctica", escribió en un correo electrónico a CoinDesk. Añadió que Zeppelin está en conversaciones con la Fundación Ethereum para que esto sea posible.

Mientras tanto, Krug resumió sus propios pensamientos sobre el asunto diciendo:

"En general, el mensaje es que se deberían auditar más cosas".

Piel de serpienteimagen vía Shutterstock

Picture of CoinDesk author Amy Castor