Análisis de vulnerabilidades del compilador Solidity y estrategias de respuesta
El compilador es una de las partes fundamentales de los sistemas informáticos modernos. Es un programa informático especial que se encarga de convertir el código fuente de lenguajes de programación de alto nivel, que son fáciles de entender y escribir para los humanos, en instrucciones que pueden ser ejecutadas por la CPU de la computadora o por una máquina virtual de bytecode.
Aunque la mayoría de los desarrolladores y expertos en seguridad suelen centrarse más en la seguridad del código de la aplicación, la seguridad del propio compilador tampoco debe ser ignorada. Como un tipo de programa informático, los compiladores también pueden tener vulnerabilidades de seguridad, las cuales en ciertos casos pueden representar serios riesgos de seguridad. Por ejemplo, al compilar y analizar el código front-end de Javascript, el navegador puede ser vulnerable a ataques que permiten la ejecución remota de código debido a fallas en el motor de análisis de Javascript, lo que podría llevar a que un atacante tome el control del navegador de la víctima o incluso de todo el sistema operativo.
El compilador de Solidity no es una excepción, existen vulnerabilidades de seguridad en varias versiones diferentes.
Vulnerabilidades del compilador Solidity
La función principal del compilador de Solidity es convertir el código del contrato inteligente escrito por los desarrolladores en código de instrucciones ejecutable por la Máquina Virtual de Ethereum (EVM). Este código de instrucciones de EVM se empaqueta y se sube a la red de Ethereum a través de transacciones, y finalmente es解析并执行由 EVM.
Es importante tener en cuenta que las vulnerabilidades del compilador Solidity son diferentes de las vulnerabilidades de la EVM en sí. Las vulnerabilidades de la EVM se refieren a problemas de seguridad que ocurren cuando la máquina virtual ejecuta instrucciones. Dado que los atacantes pueden cargar cualquier código a la red de Ethereum, este código se ejecutará finalmente en cada programa cliente P2P de Ethereum. Si hay vulnerabilidades de seguridad en la EVM, podría afectar a toda la red de Ethereum, causando un denegación de servicio (DoS) e incluso permitiendo que un atacante controle toda la cadena de bloques. Sin embargo, dado que el diseño de la EVM es relativamente simple y el código central no se actualiza con frecuencia, es menos probable que surjan tales problemas.
Las vulnerabilidades del compilador de Solidity se refieren a problemas que ocurren cuando el compilador convierte el código de Solidity en código EVM. A diferencia de la situación en la que un navegador compila y ejecuta JavaScript en la computadora del cliente del usuario, el proceso de compilación de Solidity solo se lleva a cabo en la computadora del desarrollador de contratos inteligentes y no se ejecuta en la red de Ethereum. Por lo tanto, las vulnerabilidades del compilador de Solidity no afectan directamente a la red de Ethereum en sí.
Una de las principales amenazas de las vulnerabilidades del compilador de Solidity es que pueden resultar en que el código EVM generado no coincida con las expectativas del desarrollador del contrato inteligente. Dado que los contratos inteligentes en Ethereum a menudo implican activos de criptomonedas de los usuarios, cualquier error en el contrato inteligente causado por el compilador podría resultar en la pérdida de activos de los usuarios, lo que provoca consecuencias graves.
Los desarrolladores y los auditores de contratos pueden centrarse en los problemas de implementación de la lógica del código del contrato, así como en problemas de seguridad a nivel de Solidity, como reentradas y desbordamientos de enteros. Sin embargo, es difícil detectar vulnerabilidades del compilador de Solidity solo a través de la auditoría de la lógica del código fuente del contrato. Se requiere un análisis conjunto de versiones específicas del compilador y patrones de código específicos para determinar si un contrato inteligente se ve afectado por vulnerabilidades del compilador.
Ejemplo de vulnerabilidad del compilador Solidity
A continuación se presentan algunos ejemplos reales de vulnerabilidades en compiladores de Solidity, que muestran las formas específicas, causas y peligros.
SOL-2016-9 HighOrderByteCleanStorage
Esta vulnerabilidad existe en versiones anteriores del compilador Solidity (>=0.1.6 <0.4.4).
Considera el siguiente código:
solidez
contrato C {
uint32 a = 0x1234;
uint32 b = 0;
función f() pública {
a += 1;
}
function run() public view returns (uint) {
return b;
}
}
La variable de almacenamiento b no ha sido modificada, por lo tanto, la función run() debería devolver el valor predeterminado 0. Sin embargo, en el código generado por la versión del compilador con vulnerabilidades, run() realmente devuelve 1.
Es difícil para los desarrolladores comunes detectar los problemas en el código mencionado a través de una simple revisión de código. Aunque este ejemplo es relativamente simple y puede no tener consecuencias especialmente graves, si la variable b se utiliza para validaciones de permisos, contabilidad de activos u otros usos críticos, esta discrepancia con lo esperado podría llevar a graves riesgos de seguridad.
La raíz de este problema radica en que EVM utiliza una máquina virtual basada en pila, donde cada elemento en la pila tiene un tamaño de 32 bytes (es decir, el tamaño de la variable uint256). Cada slot en el almacenamiento subyacente también tiene un tamaño de 32 bytes. Sin embargo, el lenguaje Solidity admite tipos de datos menores de 32 bytes, como uint32. Al manejar variables de estos tipos, el compilador necesita realizar operaciones de limpieza adecuadas en los bits de mayor peso para asegurar la validez de los datos. En el caso mencionado, cuando la suma provoca un desbordamiento entero, el compilador no limpia correctamente los bits de mayor peso del resultado, lo que provoca que un bit de 1 se escriba en el almacenamiento después del desbordamiento, sobrescribiendo así la variable a y modificando el valor de la variable b a 1.
La vulnerabilidad existe en compiladores de versiones >=0.8.13 <0.8.15. Considere el siguiente código:
solidez
contrato C {
function f() public pure returns (uint) {
ensamblaje {
mstore(0, 0x42)
}
uint x;
ensamblaje {
x := mload(0)
}
return x;
}
}
El compilador de Solidity no solo se encarga de traducir el lenguaje Solidity a código EVM de manera sencilla. También realiza un análisis profundo del flujo de control y de los datos, implementando diversos procesos de optimización de compilación para reducir el tamaño del código generado y optimizar el consumo de gas durante el proceso de ejecución. Este tipo de operaciones de optimización son bastante comunes en los compiladores de varios lenguajes de alto nivel, pero debido a la complejidad de las situaciones a considerar, también es fácil que surjan errores o vulnerabilidades de seguridad.
La vulnerabilidad del código anterior proviene de este tipo de optimizaciones. El compilador considera que, si hay código que modifica los datos en la dirección de memoria 0 dentro de una función, pero no se utiliza en ninguna otra parte, entonces se puede eliminar directamente el código que modifica la memoria 0, ahorrando gas y sin afectar la lógica del programa posterior.
Esta estrategia de optimización en sí misma no tiene problemas, pero en la implementación del código del compilador de Solidity, este tipo de optimización solo se aplica a un único bloque de assembly. En el código PoC mencionado, la escritura y el acceso a la memoria 0 se encuentran en dos bloques de assembly diferentes, mientras que el compilador solo ha realizado un análisis de optimización en un bloque de assembly por separado. Dado que no hay ninguna operación de lectura después de la escritura en la memoria 0 en el primer bloque de assembly, se determina que la instrucción de escritura es redundante y se elimina, lo que genera un bug. En la versión con vulnerabilidad, la función f( devolverá el valor 0, mientras que en realidad el valor correcto que debería devolver el código mencionado es 0x42.
En condiciones normales, la variable a devuelta por el código anterior debería ser "aaaa". Sin embargo, en la versión con vulnerabilidades, devolverá una cadena vacía "".
La causa de esta vulnerabilidad es que Solidity realiza una operación abi.encode en un array de tipo calldata, limpiando incorrectamente algunos datos, lo que provoca la modificación de otros datos adyacentes y causa inconsistencias en los datos después de la codificación y decodificación.
Es importante tener en cuenta que Solidity codifica implícitamente los parámetros mediante abi.encode al realizar llamadas externas y emitir eventos, por lo que la probabilidad de que aparezca el código de vulnerabilidad mencionado es mayor de lo que podría parecer a simple vista.
![Análisis de vulnerabilidades del compilador Solidity y medidas de respuesta][0]https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(
Consejos de seguridad
Tras el análisis del modelo de amenazas de vulnerabilidades del compilador Solidity y la revisión de vulnerabilidades históricas, presentamos las siguientes recomendaciones para desarrolladores y personal de seguridad.
) Para los desarrolladores:
Utiliza una versión más reciente del compilador de Solidity. Aunque las versiones nuevas también pueden introducir nuevos problemas de seguridad, generalmente hay menos problemas de seguridad conocidos que en las versiones anteriores.
Mejorar los casos de prueba unitarios. La mayoría de los errores a nivel de compilador provocan que los resultados de la ejecución del código no coincidan con lo esperado. Este tipo de problemas son difíciles de detectar mediante la revisión del código, pero pueden salir a la luz fácilmente durante la fase de prueba. Por lo tanto, al aumentar la cobertura del código, se pueden evitar al máximo este tipo de problemas.
Intenta evitar el uso de ensamblado en línea, operaciones complejas como la codificación y decodificación de ABI para matrices multidimensionales y estructuras complejas, y evita el uso ciego de nuevas características del lenguaje y funciones experimentales sin una necesidad clara. Según el análisis de vulnerabilidades históricas, la mayoría de las vulnerabilidades están relacionadas con operaciones como el ensamblado en línea y los codificadores ABI. Los compiladores son más propensos a errores al manejar características complejas del lenguaje. Por otro lado, los desarrolladores también pueden caer en errores de uso al emplear nuevas características, lo que puede llevar a problemas de seguridad.
para el personal de seguridad:
Al realizar una auditoría de seguridad del código Solidity, no se deben ignorar los riesgos de seguridad que pueden introducirse a través del compilador de Solidity. En la Clasificación de Debilidades de Contratos Inteligentes ###SWC(, el ítem correspondiente de verificación es SWC-102: Versión de Compilador Desactualizada.
En el proceso de desarrollo interno de SDL, se insta al equipo de desarrollo a actualizar la versión del compilador de Solidity y se puede considerar la introducción de una verificación automática de la versión del compilador en el proceso de CI/CD.
Pero no hay que entrar en pánico excesivo por las vulnerabilidades de los compiladores; la mayoría de las vulnerabilidades de los compiladores solo se activan en patrones de código específicos, y no significa que los contratos compilados con versiones vulnerables del compilador presenten necesariamente un riesgo de seguridad. El impacto real en la seguridad debe evaluarse específicamente según las circunstancias del proyecto.
Recursos prácticos
Artículos de alerta de seguridad publicados regularmente por el equipo de Solidity
Lista de errores actualizada periódicamente en el repositorio oficial de Solidity
Lista de errores de los compiladores de cada versión. Se puede utilizar para introducir automáticamente la verificación de la versión del compilador en el proceso de CI/CD, alertando sobre las vulnerabilidades de seguridad presentes en la versión actual.
En Etherscan, el triángulo con el signo de exclamación en la esquina superior derecha de la página del contrato -> Código puede indicar las vulnerabilidades de seguridad presentes en la versión actual del compilador.
![Análisis de vulnerabilidades del compilador Solidity y medidas de respuesta])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(
Resumen
Este artículo comienza con los conceptos básicos de los compiladores, presenta las vulnerabilidades del compilador de Solidity y analiza los riesgos de seguridad que pueden surgir en el entorno de desarrollo de Ethereum. Finalmente, se ofrecen varias recomendaciones prácticas de seguridad para desarrolladores y personal de seguridad. Al comprender estas vulnerabilidades y tomar las medidas preventivas adecuadas, podemos proteger mejor la seguridad de los contratos inteligentes y reducir el riesgo de pérdidas de activos potenciales.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
12 me gusta
Recompensa
12
6
Compartir
Comentar
0/400
0xLuckbox
· hace9h
Los fallos lógicos realmente duelen. Me voy, me voy.
Ver originalesResponder0
LidoStakeAddict
· hace23h
¡Desbordamiento! El código todavía necesita ser modificado.
Ver originalesResponder0
StablecoinArbitrageur
· 07-30 09:26
*ajusta las gafas* hmm... estadísticamente hablando, los riesgos del compilador están severamente subestimados en los cálculos de tvl de defi
Ver originalesResponder0
BoredStaker
· 07-30 09:24
¡Cuándo se puede hablar como una persona!
Ver originalesResponder0
ArbitrageBot
· 07-30 09:24
¿Otra vez meterse en el lío de compilar?
Ver originalesResponder0
APY追逐者
· 07-30 09:15
Solo recordé la vulnerabilidad del compilador cuando estaba cazando el gas.
Análisis de vulnerabilidades del compilador Solidity y prácticas de prevención de seguridad
Análisis de vulnerabilidades del compilador Solidity y estrategias de respuesta
El compilador es una de las partes fundamentales de los sistemas informáticos modernos. Es un programa informático especial que se encarga de convertir el código fuente de lenguajes de programación de alto nivel, que son fáciles de entender y escribir para los humanos, en instrucciones que pueden ser ejecutadas por la CPU de la computadora o por una máquina virtual de bytecode.
Aunque la mayoría de los desarrolladores y expertos en seguridad suelen centrarse más en la seguridad del código de la aplicación, la seguridad del propio compilador tampoco debe ser ignorada. Como un tipo de programa informático, los compiladores también pueden tener vulnerabilidades de seguridad, las cuales en ciertos casos pueden representar serios riesgos de seguridad. Por ejemplo, al compilar y analizar el código front-end de Javascript, el navegador puede ser vulnerable a ataques que permiten la ejecución remota de código debido a fallas en el motor de análisis de Javascript, lo que podría llevar a que un atacante tome el control del navegador de la víctima o incluso de todo el sistema operativo.
El compilador de Solidity no es una excepción, existen vulnerabilidades de seguridad en varias versiones diferentes.
Vulnerabilidades del compilador Solidity
La función principal del compilador de Solidity es convertir el código del contrato inteligente escrito por los desarrolladores en código de instrucciones ejecutable por la Máquina Virtual de Ethereum (EVM). Este código de instrucciones de EVM se empaqueta y se sube a la red de Ethereum a través de transacciones, y finalmente es解析并执行由 EVM.
Es importante tener en cuenta que las vulnerabilidades del compilador Solidity son diferentes de las vulnerabilidades de la EVM en sí. Las vulnerabilidades de la EVM se refieren a problemas de seguridad que ocurren cuando la máquina virtual ejecuta instrucciones. Dado que los atacantes pueden cargar cualquier código a la red de Ethereum, este código se ejecutará finalmente en cada programa cliente P2P de Ethereum. Si hay vulnerabilidades de seguridad en la EVM, podría afectar a toda la red de Ethereum, causando un denegación de servicio (DoS) e incluso permitiendo que un atacante controle toda la cadena de bloques. Sin embargo, dado que el diseño de la EVM es relativamente simple y el código central no se actualiza con frecuencia, es menos probable que surjan tales problemas.
Las vulnerabilidades del compilador de Solidity se refieren a problemas que ocurren cuando el compilador convierte el código de Solidity en código EVM. A diferencia de la situación en la que un navegador compila y ejecuta JavaScript en la computadora del cliente del usuario, el proceso de compilación de Solidity solo se lleva a cabo en la computadora del desarrollador de contratos inteligentes y no se ejecuta en la red de Ethereum. Por lo tanto, las vulnerabilidades del compilador de Solidity no afectan directamente a la red de Ethereum en sí.
Una de las principales amenazas de las vulnerabilidades del compilador de Solidity es que pueden resultar en que el código EVM generado no coincida con las expectativas del desarrollador del contrato inteligente. Dado que los contratos inteligentes en Ethereum a menudo implican activos de criptomonedas de los usuarios, cualquier error en el contrato inteligente causado por el compilador podría resultar en la pérdida de activos de los usuarios, lo que provoca consecuencias graves.
Los desarrolladores y los auditores de contratos pueden centrarse en los problemas de implementación de la lógica del código del contrato, así como en problemas de seguridad a nivel de Solidity, como reentradas y desbordamientos de enteros. Sin embargo, es difícil detectar vulnerabilidades del compilador de Solidity solo a través de la auditoría de la lógica del código fuente del contrato. Se requiere un análisis conjunto de versiones específicas del compilador y patrones de código específicos para determinar si un contrato inteligente se ve afectado por vulnerabilidades del compilador.
Ejemplo de vulnerabilidad del compilador Solidity
A continuación se presentan algunos ejemplos reales de vulnerabilidades en compiladores de Solidity, que muestran las formas específicas, causas y peligros.
SOL-2016-9 HighOrderByteCleanStorage
Esta vulnerabilidad existe en versiones anteriores del compilador Solidity (>=0.1.6 <0.4.4).
Considera el siguiente código:
solidez contrato C { uint32 a = 0x1234; uint32 b = 0; función f() pública { a += 1; } function run() public view returns (uint) { return b; } }
La variable de almacenamiento b no ha sido modificada, por lo tanto, la función run() debería devolver el valor predeterminado 0. Sin embargo, en el código generado por la versión del compilador con vulnerabilidades, run() realmente devuelve 1.
Es difícil para los desarrolladores comunes detectar los problemas en el código mencionado a través de una simple revisión de código. Aunque este ejemplo es relativamente simple y puede no tener consecuencias especialmente graves, si la variable b se utiliza para validaciones de permisos, contabilidad de activos u otros usos críticos, esta discrepancia con lo esperado podría llevar a graves riesgos de seguridad.
La raíz de este problema radica en que EVM utiliza una máquina virtual basada en pila, donde cada elemento en la pila tiene un tamaño de 32 bytes (es decir, el tamaño de la variable uint256). Cada slot en el almacenamiento subyacente también tiene un tamaño de 32 bytes. Sin embargo, el lenguaje Solidity admite tipos de datos menores de 32 bytes, como uint32. Al manejar variables de estos tipos, el compilador necesita realizar operaciones de limpieza adecuadas en los bits de mayor peso para asegurar la validez de los datos. En el caso mencionado, cuando la suma provoca un desbordamiento entero, el compilador no limpia correctamente los bits de mayor peso del resultado, lo que provoca que un bit de 1 se escriba en el almacenamiento después del desbordamiento, sobrescribiendo así la variable a y modificando el valor de la variable b a 1.
SOL-2022-4 EfectosSecundariosDeMemoriaEnEnsambladorEnLínea
La vulnerabilidad existe en compiladores de versiones >=0.8.13 <0.8.15. Considere el siguiente código:
solidez contrato C { function f() public pure returns (uint) { ensamblaje { mstore(0, 0x42) } uint x; ensamblaje { x := mload(0) } return x; } }
El compilador de Solidity no solo se encarga de traducir el lenguaje Solidity a código EVM de manera sencilla. También realiza un análisis profundo del flujo de control y de los datos, implementando diversos procesos de optimización de compilación para reducir el tamaño del código generado y optimizar el consumo de gas durante el proceso de ejecución. Este tipo de operaciones de optimización son bastante comunes en los compiladores de varios lenguajes de alto nivel, pero debido a la complejidad de las situaciones a considerar, también es fácil que surjan errores o vulnerabilidades de seguridad.
La vulnerabilidad del código anterior proviene de este tipo de optimizaciones. El compilador considera que, si hay código que modifica los datos en la dirección de memoria 0 dentro de una función, pero no se utiliza en ninguna otra parte, entonces se puede eliminar directamente el código que modifica la memoria 0, ahorrando gas y sin afectar la lógica del programa posterior.
Esta estrategia de optimización en sí misma no tiene problemas, pero en la implementación del código del compilador de Solidity, este tipo de optimización solo se aplica a un único bloque de assembly. En el código PoC mencionado, la escritura y el acceso a la memoria 0 se encuentran en dos bloques de assembly diferentes, mientras que el compilador solo ha realizado un análisis de optimización en un bloque de assembly por separado. Dado que no hay ninguna operación de lectura después de la escritura en la memoria 0 en el primer bloque de assembly, se determina que la instrucción de escritura es redundante y se elimina, lo que genera un bug. En la versión con vulnerabilidad, la función f( devolverá el valor 0, mientras que en realidad el valor correcto que debería devolver el código mencionado es 0x42.
) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup
La vulnerabilidad afecta a los compiladores de las versiones >= 0.5.8 < 0.8.16. Considere el siguiente código:
solidez contrato C { función f###string( calldata a[1] externo puro devuelve )string memoria( { return abi.decode)abi.encode(a(, )string([1])); } }
En condiciones normales, la variable a devuelta por el código anterior debería ser "aaaa". Sin embargo, en la versión con vulnerabilidades, devolverá una cadena vacía "".
La causa de esta vulnerabilidad es que Solidity realiza una operación abi.encode en un array de tipo calldata, limpiando incorrectamente algunos datos, lo que provoca la modificación de otros datos adyacentes y causa inconsistencias en los datos después de la codificación y decodificación.
Es importante tener en cuenta que Solidity codifica implícitamente los parámetros mediante abi.encode al realizar llamadas externas y emitir eventos, por lo que la probabilidad de que aparezca el código de vulnerabilidad mencionado es mayor de lo que podría parecer a simple vista.
![Análisis de vulnerabilidades del compilador Solidity y medidas de respuesta][0]https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(
Consejos de seguridad
Tras el análisis del modelo de amenazas de vulnerabilidades del compilador Solidity y la revisión de vulnerabilidades históricas, presentamos las siguientes recomendaciones para desarrolladores y personal de seguridad.
) Para los desarrolladores:
Utiliza una versión más reciente del compilador de Solidity. Aunque las versiones nuevas también pueden introducir nuevos problemas de seguridad, generalmente hay menos problemas de seguridad conocidos que en las versiones anteriores.
Mejorar los casos de prueba unitarios. La mayoría de los errores a nivel de compilador provocan que los resultados de la ejecución del código no coincidan con lo esperado. Este tipo de problemas son difíciles de detectar mediante la revisión del código, pero pueden salir a la luz fácilmente durante la fase de prueba. Por lo tanto, al aumentar la cobertura del código, se pueden evitar al máximo este tipo de problemas.
Intenta evitar el uso de ensamblado en línea, operaciones complejas como la codificación y decodificación de ABI para matrices multidimensionales y estructuras complejas, y evita el uso ciego de nuevas características del lenguaje y funciones experimentales sin una necesidad clara. Según el análisis de vulnerabilidades históricas, la mayoría de las vulnerabilidades están relacionadas con operaciones como el ensamblado en línea y los codificadores ABI. Los compiladores son más propensos a errores al manejar características complejas del lenguaje. Por otro lado, los desarrolladores también pueden caer en errores de uso al emplear nuevas características, lo que puede llevar a problemas de seguridad.
para el personal de seguridad:
Al realizar una auditoría de seguridad del código Solidity, no se deben ignorar los riesgos de seguridad que pueden introducirse a través del compilador de Solidity. En la Clasificación de Debilidades de Contratos Inteligentes ###SWC(, el ítem correspondiente de verificación es SWC-102: Versión de Compilador Desactualizada.
En el proceso de desarrollo interno de SDL, se insta al equipo de desarrollo a actualizar la versión del compilador de Solidity y se puede considerar la introducción de una verificación automática de la versión del compilador en el proceso de CI/CD.
Pero no hay que entrar en pánico excesivo por las vulnerabilidades de los compiladores; la mayoría de las vulnerabilidades de los compiladores solo se activan en patrones de código específicos, y no significa que los contratos compilados con versiones vulnerables del compilador presenten necesariamente un riesgo de seguridad. El impacto real en la seguridad debe evaluarse específicamente según las circunstancias del proyecto.
Recursos prácticos
![Análisis de vulnerabilidades del compilador Solidity y medidas de respuesta])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(
Resumen
Este artículo comienza con los conceptos básicos de los compiladores, presenta las vulnerabilidades del compilador de Solidity y analiza los riesgos de seguridad que pueden surgir en el entorno de desarrollo de Ethereum. Finalmente, se ofrecen varias recomendaciones prácticas de seguridad para desarrolladores y personal de seguridad. Al comprender estas vulnerabilidades y tomar las medidas preventivas adecuadas, podemos proteger mejor la seguridad de los contratos inteligentes y reducir el riesgo de pérdidas de activos potenciales.