El ecosistema Ethereum continúa testigo una ráfaga de actividad en la que individuos y organizaciones implementan contratos simbólicos, agregan liquidez a los grupos e implementan contratos inteligentes para respaldar una amplia gama de modelos comerciales. Si bien es notable, este crecimiento también ha estado plagado de vulnerabilidades de seguridad, lo que ha dejado a los protocolos de finanzas descentralizadas (DeFi) vulnerables a ataques y estafas.
Por ejemplo, hallazgos recientes de la empresa de criptointeligencia Chainalysis mostrar que los hackeos relacionados con criptomonedas han aumentado un 58,3 % desde principios de año hasta julio de 2022. El informe señala además que se han perdido 1900 millones de dólares por hackeos durante este período de tiempo, una cifra que no incluye el hackeo del puente Nomad de 190 millones de dólares que ocurrida el 1 de agosto de 2022.
Aunque el código fuente abierto puede ser beneficioso para la industria de la cadena de bloques, lamentablemente los ciberdelincuentes pueden estudiarlo fácilmente en busca de exploits. Las auditorías de seguridad para contratos inteligentes tienen como objetivo resolver estos desafíos, pero este procedimiento carece de los estándares de la industria, lo que genera complejidad.
Un estándar de la industria para garantizar la seguridad de los contratos inteligentes
Chris Cordi, presidente del Grupo de trabajo de niveles de seguridad de EthTrust en Enterprise Ethereum Alliance (EEA), dijo a Cointelegraph que a medida que crece la industria de la cadena de bloques de Ethereum, también crece la necesidad de un marco maduro para evaluar la seguridad de los contratos inteligentes.
Para abordar esto, Cordi, junto con varios representantes de miembros del EEE con experiencia en auditoría y seguridad, ayudó a establecer el Grupo de Trabajo de Niveles de Seguridad de EthTrust en noviembre de 2020. Desde entonces, la organización ha estado trabajando en un documento borrador de una especificación de contrato inteligente, o industria. estándar, destinado a mejorar la seguridad detrás de los contactos inteligentes.
Más recientemente, el grupo de trabajo anunció la publicación de la Especificación de niveles de seguridad de EthTrust v1. Chaals Nevile, director del programa técnico de la AEMA, le dijo a Cointelegraph que esta especificación describe las vulnerabilidades de los contratos inteligentes que una auditoría de seguridad adecuada requiere como medida mínima de calidad:
“Es relevante para todas las plataformas de contratos inteligentes basadas en EVM donde los desarrolladores usan Solidity como lenguaje de codificación. En un análisis reciente de Splunk, esto es más de 3/4 de los contratos de red principal. Pero también hay redes privadas y proyectos que se basan en la pila de tecnología Ethereum pero que ejecutan una cadena propia. Esta especificación es tan útil para ellos como lo es para los usuarios de la red principal para ayudarlos a proteger su trabajo”.
Desde una perspectiva técnica, Nevile explicó que la nueva especificación describe tres niveles de pruebas que las organizaciones deben considerar al realizar auditorías de seguridad de contratos inteligentes.
“Nivel [S] está diseñado para que, en la mayoría de los casos, donde se utilizan características comunes de Solidity siguiendo patrones bien conocidos, el código probado pueda ser certificado por una herramienta de ‘análisis estático’ automatizada”, dijo.
Agregó que el Nivel [M] test exige un análisis estático más estricto, señalando que esto incluye requisitos en los que se espera que un auditor humano determine si el uso de una función es necesario o si se justifica una afirmación sobre las propiedades de seguridad del código.
Nevile explicó además que el Nivel [Q] test proporciona un análisis de la lógica empresarial que implementa el código probado. “Esto es para garantizar que el código no muestre vulnerabilidades de seguridad conocidas, al mismo tiempo que se asegura de que implemente correctamente lo que afirma”, dijo. También hay una prueba opcional de “buenas prácticas recomendadas” que puede ayudar a mejorar la seguridad detrás de los contratos inteligentes. Neville dijo:
“Usar el compilador más reciente es una de las ‘buenas prácticas recomendadas’. Es bastante sencillo en la mayoría de los casos, pero hay muchas razones por las que un contrato podría no haberse implementado con la última versión. Otras buenas prácticas incluyen informar nuevas vulnerabilidades para que puedan abordarse en una actualización de la especificación y escribir un código limpio y fácil de leer”.
En general, hay 107 requisitos dentro de toda la especificación. Según Nevile, alrededor de 50 de estos son de nivel [S] requisitos que surgen de errores en scompiladores de olidez.
¿Un estándar de la industria ayudará a las organizaciones y desarrolladores?
Nevile señaló que, en última instancia, la Especificación de niveles de seguridad de EthTrust tiene como objetivo ayudar a los auditores a demostrar a los clientes que están operando a un nivel apropiado para la industria. “Los auditores pueden señalar este estándar de la industria para establecer la credibilidad básica”, dijo.
Reciente: los juegos de Web3 incorporan características para impulsar la participación femenina
Arrojando luz sobre esto, Ronghui Gu, CEO y cofundador de la firma de seguridad de blockchain CertiK, le dijo a Cointelegraph que tener estándares como estos ayuda a garantizar los procesos y pautas esperados. Sin embargo, señaló que dichos estándares no son de ninguna manera un “sello de goma” para indicar que un contrato inteligente es completamente seguro:
“Es importante entender que no todos los auditores de contratos inteligentes son iguales. La auditoría de contratos inteligentes comienza con la comprensión y la experiencia del ecosistema específico para el que se audita un contrato inteligente y la pila de tecnología y el lenguaje de código que se utiliza. No todos los códigos o cadenas son iguales. La experiencia es importante aquí para la cobertura y los hallazgos”.
Dado esto, Gu cree que las empresas que desean auditar sus contratos inteligentes deben mirar más allá de la certificación que un auditor afirma tener y tener en cuenta la calidad, la escala y la reputación del auditor. Debido a que estos estándares son pautas, Gu comentó que cree que esta especificación es un buen punto de partida.
Desde la perspectiva de un desarrollador, estas especificaciones pueden resultar extremadamente beneficiosas. Mark Beylin, cofundador de Myco, una red social emergente basada en blockchain, le dijo a Cointelegraph que estos estándares serán increíblemente valiosos para ayudar a los desarrolladores de contratos inteligentes a comprender mejor qué esperar de una auditoría de seguridad. Él dijo:
“Actualmente, hay muchos recursos dispersos para la seguridad de contratos inteligentes, pero no hay un libro de reglas específico que los auditores sigan al evaluar la seguridad de un proyecto. Usando esta especificación, tanto los auditores de seguridad como sus clientes pueden estar en la misma página sobre qué tipo de requisitos de seguridad se verificarán”.
Michael Lewellen, desarrollador y colaborador de la especificación, le dijo además a Cointelegraph que estas especificaciones ayudan al proporcionar una lista de verificación de problemas de seguridad conocidos para verificar. “Muchos desarrolladores de Solidity no han recibido educación o capacitación formal reciente en los aspectos de seguridad del desarrollo de Solidity, pero aún se espera seguridad. Tener especificaciones como esta hace que sea más fácil descubrir cómo escribir código de manera más segura”, dijo.
Reciente: Ethereum Merge incita a los mineros y grupos de minería a tomar una decisión
Lewellen también señaló que la mayoría de los requisitos de especificación están escritos de manera sencilla, lo que facilita la comprensión de los desarrolladores. Sin embargo, comentó que no siempre está claro por qué se incluye un requisito. “Algunos tienen enlaces a documentación externa de una vulnerabilidad, pero otros no. Sería más fácil de entender para los desarrolladores si tuvieran ejemplos más claros de cómo podría ser el código compatible y no compatible”.
La evolución de los estándares de seguridad de los contratos inteligentes
A fin de cuentas, la especificación del nivel de seguridad está ayudando a avanzar en el ecosistema Ethereum al establecer pautas para auditorías de contratos inteligentes. Sin embargo, Nevile señaló que el aspecto más desafiante en el futuro es anticipar cómo podría ocurrir un exploit. Él dijo:
“Esta especificación no resuelve esos desafíos por completo. Sin embargo, lo que sí hace la especificación es identificar ciertos pasos, como documentar la arquitectura y la lógica comercial detrás de los contratos, que son importantes para permitir una auditoría de seguridad exhaustiva”.
Gu también piensa que diferentes cadenas comenzarán a desarrollar estándares similares a medida que avanza Web3. Por ejemplo, algunos desarrolladores dentro de la industria de Ethereum están elaborando sus propios requisitos de contrato inteligente para ayudar a otros. Por ejemplo, Samuel Cardillo, director de tecnología de RTFKT, tuiteó recientemente que creó un sistema para que los desarrolladores califiquen públicamente los contratos inteligentes en función de los elementos buenos y malos en términos de desarrollo:
Hace unos días comencé una pequeña hoja de Google para calificar públicamente los contratos inteligentes con el fin de crear conciencia y ayudar tanto a los coleccionistas como a los desarrolladores; también incluirá lo que se debe y lo que no se debe hacer al desarrollar un contrato.
https://t.co/2ixBpkNeoc— SamuelCardillo.eth – RTFKT (@CardilloSamuel) 15 de agosto de 2021
Aunque todo esto es un paso en la dirección correcta, Gu señaló que se necesita tiempo para que los estándares sean ampliamente adoptados. Además, Nevile explicó que la seguridad nunca es estática. Como tal, explicó que es posible que las personas envíen preguntas al grupo de trabajo que escribió la especificación. “Tomaremos en cuenta esos comentarios, así como también veremos cuáles son las discusiones en el espacio público más amplio porque esperamos actualizar la especificación”, dijo Nevile. Agregó que se producirá una nueva versión de la especificación dentro de seis a dieciocho meses.