Gracias a Raja y Gracious por su ayuda con este artículo.

Los contratos inteligentes son esenciales para las finanzas descentralizadas (DeFi), y los desarrolladores de web3 deben garantizar su precisión y seguridad. Dado que los contratos inteligentes gestionan grandes cantidades de fondos, las herramientas de auditoría potentes son más necesarias que nunca. Aunque los métodos de auditoría habituales implican una revisión manual del código, los recientes avances en inteligencia artificial, concretamente ChatGPT 3 y 4 de OpenAI, han planteado la pregunta: «¿Puede la IA sustituir a los auditores humanos?».

En AuditOne, hemos analizado algunos fragmentos de código de una auditoría previa que realizamos en UniCrow utilizando ChatGPT4. El código del contrato y las conclusiones están disponibles públicamente si te interesa consultar los resultados de nuestra auditoría en «Informe de auditoría de UniCrow | AuditOne». A continuación, te mostramos algunos de los resultados de ChatGPT4.

La función que se muestra a continuación está pensada para permitir la transferencia segura de ether o tokens ERC20 desde un contrato de tesorería. Solo el contrato Unicrow Claim está autorizado a llamar a la función sendEscrowShare.

Resumen de las conclusiones del auditor

El problema es que cualquiera de las partes puede impedir que se cierre el depósito en garantía negándose a aceptar los pagos. Esto puede ocurrir si alguna de las partes no está de acuerdo con la decisión del árbitro en una disputa, y puede aprovechar esta situación para impedir que todas las partes reciban los pagos. A la hora de liquidar el depósito en garantía, el sistema utiliza un modelo «Push» para la transferencia de fondos, lo que significa que el depósito en garantía no puede liquidarse si falla alguna transferencia. Cualquiera de las partes puede aprovecharse de esto negándose a aceptar el dinero (ya sea en token nativo o en ERC777) y bloqueando el cierre del depósito en garantía. Como resultado, ninguna de las partes implicadas puede recibir los fondos.

‍

Artículo relacionado: La evolución de las auditorías de IA: adaptación a la era de la IA generativa

‍

Texto de entrada

¿Existen posibles vulnerabilidades o puntos débiles de seguridad en el código?

Resultados de ChatGPT

Resumen de los resultados de ChatCPT

ChatGPT no pudo identificar la vulnerabilidad concreta sin que se le indicara mediante una solicitud específica. Las tres primeras vulnerabilidades identificadas son falsos positivos. El modificador `onlyUnicrowClaim` y la biblioteca SafeERC20 se han implementado y auditado correctamente, mientras que la tercera vulnerabilidad ya queda cubierta por el mecanismo de control de acceso del modificador `onlyUnicrowClaim`. Los problemas detectados por ChatGPT eran en su mayoría superficiales y de carácter informativo, pero para un auditor novato, conocer estas vulnerabilidades o su potencial podría resultar útil.

Código 2

Este fragmento de código facilita la gestión de un depósito en garantía entre las partes, permitiendo la liberación de los fondos a la dirección del comprador una vez ejecutado.

Resumen de las conclusiones del auditor

Actualmente, el código utiliza el modificador «non-reentrant» para evitar ataques de reentrada y, además, realiza una comprobación para asegurarse de que «escrow.claimed» sea 0, con el fin de evitar una nueva reclamación. Sin embargo, existe una posible vulnerabilidad por la que unos atacantes malintencionados podrían reclamar fondos repetidamente de un mismo depósito en garantía y, en última instancia, quedarse con todos los fondos del contrato. Esto puede producirse cuando el comprador y el vendedor crean un contrato, y el comprador (actuando de forma maliciosa) ejecuta una función para reclamar el pago antes de que cambie el estado. Aunque tanto la función de reembolso como la de reclamación cuentan con el modificador «nonReentrant», el hecho de que se encuentren en contratos diferentes implica que el estado no se sincroniza. Los atacantes pueden aprovechar esta laguna para hacerse con todo el ETH del contrato e incluso robar tokens si estos siguen el estándar ERC777.

Texto de entrada

¿Existen posibles vulnerabilidades o puntos débiles de seguridad en el código?

Resultados de ChatGPT

Resumen de los resultados de ChatCPT

ChatGPT identificó el riesgo de un ataque de reentrada y ofreció soluciones, pero la respuesta no se adaptaba a la situación concreta. La función `safeTransfer` de la biblioteca SafeERC20 se ha sometido a pruebas exhaustivas y se considera segura. Contrariamente a lo que se temía inicialmente, la vulnerabilidad asociada a la dirección `escrow.buyer` no supone un problema real. Al examinar el código, resulta evidente que «escrow.buyer» es una cuenta de propiedad externa (EOA). Así lo ilustra la función «refund()», que permite al vendedor reembolsar al comprador y retirar los fondos a «escrow.buyer». Este enfoque parte de la base de que el comprador suele ser una EOA (cuenta de propiedad externa).

Código 3

Unicrow es un protocolo de pago seguro y de depósito en garantía para el intercambio de bienes, activos o servicios sin exponer ni retener la custodia de los fondos de los usuarios. Reduce los costes operativos, ofrece arbitraje por parte de terceros e introduce un mecanismo único de verificación para el ejercicio de recursos.

La preauditoría completa del contrato se puede consultar aquí (https://github.com/unicrowio/contracts/blob/main/contracts/Unicrow.sol)

Resumen de las conclusiones del auditor

(https://docsend.com/view/52h69q2tf3p789jq)

Texto de entrada

Identifica todas las vulnerabilidades o puntos débiles de seguridad en este código Solidity, enuméralos en una tabla con sus descripciones y asigna a cada uno un nivel de gravedad, de menor a mayor:

Resultados de ChatGPT

‍

Resumen de los resultados de ChatCPT

Durante la evaluación del contrato, ChatGPT partió de una serie de supuestos. Uno de ellos se refería a la vulnerabilidad de reentrancia, identificada mediante el ReentrancyGuard de OpenZeppelin. Sin embargo, ChatGPT no especificó ninguna función concreta que pudiera dar lugar a un ataque de reentrancia. Un auditor humano habría comprendido el propósito del uso del ReentrancyGuard de OpenZeppelin y habría señalado cualquier caso de vulnerabilidad en el código.

‍

ChatCPT ha detectado problemas relacionados con un acceso incorrecto a la función; sin embargo, para ejecutar correctamente la función `refund`, el autor de la llamada debe ser el vendedor, tal y como indica la línea `require(sender == escrow.seller, "1–011");`. Si otra cuenta intenta ejecutar esta función, la operación fallará y se generará el mensaje de error «1–011». Del mismo modo, para ejecutar la función `release`, quien la invoque debe ser el comprador, tal y como se especifica en la línea `require(sender == escrow.buyer, "1–025");`.

‍

En lo que respecta a la vulnerabilidad de desbordamiento por exceso o por defecto de enteros, la función `challenge` solo puede ser invocada por el contrato de disputa, lo cual queda garantizado por el modificador `onlyUnicrowDispute`. Del mismo modo, la función `settle` solo puede ser invocada por el contrato de arbitraje o de disputa, lo cual se comprueba mediante el modificador `onlyUnicrowArbitratorOrDispute`. Asimismo, ChatGPT también evaluó el uso de la función SafeMath, pero los desarrolladores ya habían tomado precauciones y la habían utilizado cuando era necesario. Cabe destacar que Solidity 0.8 ha solucionado la mayoría de los problemas de desbordamiento y subdesbordamiento de enteros.

Texto de entrada

Audita este contrato inteligente escrito en Solidity y elabora una tabla con los resultados en la que se clasifiquen y describan los errores detectados: Detecta todas las vulnerabilidades o debilidades de seguridad presentes en este código Solidity, enuméralas en una tabla con sus respectivas descripciones y asigna a cada una un nivel de gravedad, de menor a mayor:

Resultados de ChatGPT

‍

Falta de validación de la comisión del mercado

‍

‍

Se ha planteado una cuestión relativa a la validación de la comisión del mercado, pero se trata de un falso positivo. La función cuenta con una validación integrada que confirma que la suma de la comisión del árbitro, la comisión del mercado y la comisión del protocolo es inferior a una cifra determinada. Esto garantiza automáticamente que la comisión del mercado sea inferior o igual a dicha cifra. Por lo tanto, no hay motivo para preocuparse de que la comisión del mercado supere el límite permitido.

‍

Falta de validación de la dirección de la moneda

‍

‍

It has been suggested that there is no validation for the currency address, but this statement is not entirely accurate. The `pay` function includes a validation check that ensures the payment currency is not the zero address. This check is performed in the following code line: `if(msg.value > 0) { require(input.currency == address(0), "0–010"); }`. It ensures that if the payment is made in ETH, the `input.currency` field is set to the zero address. However, it only applies to ETH payments and does not cover other ERC20 token payments. There is no explicit check for these payments to ensure that the payment currency address does not equal the zero address.

‍

Falta de validación del importe enviado con la función `pay`

‍

Hay un error en la afirmación de que la función `pay` no valida la cantidad que se le envía. La función sí comprueba que la cantidad enviada con la llamada a la función sea mayor que cero. Esta validación se realiza mediante la siguiente línea de código: "`require(amount > 0, "0–011");```

Falta de validación de la dirección del vendedor

‍

No hay ningún error de validación de la dirección del vendedor. La función `pay` incluye una línea de código que garantiza que la dirección del vendedor no sea la dirección cero: `require(input.seller != address(0), "0–002");.`

Falta de validación de `msg.value` en la función `pay`

‍

‍

La función `pay` del código garantiza que la cantidad transferida coincida con la cantidad especificada en el parámetro `EscrowInput`. Sin embargo, no comprueba que `msg.value` sea igual a la cantidad especificada. Si el pago no se realiza en ETH, la función exige que `msg.value` sea 0 y que el parámetro `EscrowInput` sea mayor que 0. Por lo tanto, si `msg.value` es mayor que 0, no fallará la validación, pero no se considerará como el importe del pago.

Falta de validación de la dirección del árbitro en la función `pay`

‍

‍

Hay un error en la afirmación de que no existe ninguna validación de la dirección del árbitro en la función `pay`. La función `pay` incluye una validación para garantizar que la dirección del árbitro no sea la misma que la del comprador o la del vendedor. Así lo confirma la siguiente línea de código: ``` require(arbitrator != buyer && arbitrator != input.seller, “1–027”);

Resumen de las notas sobre ChatGPT

‍

En lo que respecta a la seguridad de los contratos inteligentes, hay varios aspectos clave que debes tener en cuenta para ayudar a prevenir vulnerabilidades. Una forma de reducir los riesgos de vulnerabilidades es utilizar bibliotecas ampliamente utilizadas y probadas, como las de OpenZeppelin.

Además, puedes utilizar SafeERC20 y SafeMath para gestionar de forma segura los tokens ERC20 y realizar cálculos matemáticos seguros, respectivamente. También es importante implementar protecciones contra la reentrada para prevenir ataques de reentrada y asegurarse de que los contratos estén bien estructurados y comentados, de modo que resulten más fáciles de leer y comprender. Aunque estas notas quizá no ofrezcan soluciones específicas y aplicables, aportan información valiosa sobre las mejores prácticas para el desarrollo de contratos inteligentes. Pueden servir como punto de partida para la auditoría y la implementación de contratos inteligentes.

Resumen de las conclusiones de ChatGPT en comparación con las de los auditores

‍

Conclusión

La inteligencia artificial tiene un gran potencial en la auditoría de contratos inteligentes, a pesar de ciertas limitaciones. GPT-4 ha demostrado cierta capacidad para detectar vulnerabilidades sencillas y ofrecer explicaciones claras.

La formación y mejora continuas de los modelos harán que la auditoría de contratos grandes y complejos sea más rápida, más inteligente y más exhaustiva. Sin embargo, la IA no puede realizar análisis exhaustivos ni identificar rutas de ataque en cadena. Debería servir de complemento a los auditores humanos —por ejemplo, mediante la generación automática de documentación general— en lugar de sustituirlos. En el futuro, los avances en IA podrían permitir una auditoría y certificación automatizadas más eficaces. No obstante, el reto de identificar vulnerabilidades complejas sigue existiendo, ya que los hallazgos actuales suelen ser genéricos y se basan en una lista estándar de vulnerabilidades.

Con el rápido avance de la tecnología, nos encontramos al borde de un cambio de paradigma que mejorará significativamente la eficiencia humana. Los posibles beneficios de la IA para mejorar la seguridad de la cadena de bloques son alentadores, y seguiremos evaluando el impacto de las nuevas tecnologías de IA en este tema crucial. Inevitablemente, en un futuro próximo nos integraremos con la IA en cierta medida. Las posibilidades para las herramientas de análisis y auditoría de contratos son ilimitadas, gracias al potencial que ofrece la combinación de la IA y la cadena de bloques.

Prueba nuestra herramienta gratuita herramienta gratuita de verificación del cumplimiento de la normativa de la UE en materia de IA