Solidity

¿Qué es Solidity?

Solidity es un lenguaje de programación de alto nivel utilizado para escribir contratos inteligentes que se ejecutan en Ethereum y otras redes blockchain compatibles con la Ethereum Virtual Machine.

El sitio web oficial de Solidity describe Solidity como un lenguaje de programación de tipado estático y llaves diseñado para desarrollar contratos inteligentes que se ejecutan en Ethereum.

Un contrato inteligente es un programa almacenado en una blockchain que puede mantener activos, aplicar reglas, ejecutar lógica y responder a transacciones sin necesidad de un servidor tradicional.

La documentación oficial sobre contratos inteligentes de Ethereum explica que un contrato inteligente es un programa que se ejecuta en la blockchain de Ethereum.

En cripto, Solidity se utiliza para crear tokens, protocolos DeFi, colecciones de NFT, DAO, sistemas de staking, mercados de préstamos, bridges, sistemas de escrow, contratos de gobernanza y muchas otras aplicaciones on-chain.

El código Solidity no lo ejecutan directamente los usuarios.

Los desarrolladores escriben código fuente de Solidity y, después, lo compilan en bytecode que puede ejecutar la Ethereum Virtual Machine.

La documentación oficial de Solidity explica que Solidity es un lenguaje orientado a objetos y de alto nivel para implementar contratos inteligentes.

En términos sencillos, Solidity es el principal lenguaje de programación que muchos desarrolladores utilizan para crear aplicaciones cripto programables en blockchains basadas en la EVM.

Por qué Solidity es importante en cripto

Solidity es importante porque impulsa muchos de los contratos inteligentes con los que los usuarios interactúan en el ecosistema cripto.

Cuando un usuario intercambia tokens, acuña un NFT, participa en una votación de una DAO, deposita colateral, reclama recompensas o interactúa con una aplicación DeFi, un contrato inteligente de Solidity puede gestionar parte de esa acción.

Solidity ayudó a hacer viables los activos digitales programables porque los desarrolladores podían escribir reglas reutilizables para la propiedad, las transferencias, los permisos, las comisiones, la liquidez y la gobernanza.

Los tokens, como los activos fungibles y los NFT, suelen depender de estándares de contratos inteligentes que normalmente se implementan en Solidity.

El estándar de token ERC-20 oficial define una interfaz común para tokens fungibles en contratos inteligentes.

El estándar de token ERC-721 oficial define una interfaz común para tokens no fungibles.

El estándar de token ERC-1155 oficial define un estándar multitoken que puede admitir activos fungibles y no fungibles en un sistema de contratos.

Estos estándares son importantes porque las carteras, los exploradores, las aplicaciones y los protocolos pueden admitir más fácilmente comportamientos de tokens comunes.

Solidity también es importante porque los errores de los contratos inteligentes pueden afectar a fondos reales de los usuarios.

Un pequeño error en el código Solidity puede provocar pérdida de tokens, permisos defectuosos, contabilidad incorrecta, actualizaciones fallidas o lógica DeFi explotable.

Cómo funciona Solidity

Solidity permite a los desarrolladores describir las reglas de los contratos inteligentes mediante código fuente legible por humanos.

Después, el código se compila en bytecode de la EVM mediante el compilador de Solidity, conocido habitualmente como solc.

La documentación del compilador de Solidity explica que puede generar resultados como binarios, datos ABI, ensamblador, estimaciones de gas y árboles de sintaxis abstracta.

Después de la compilación, el bytecode de despliegue se envía en una transacción de blockchain para crear una cuenta de contrato.

Una vez desplegado, el contrato tiene una dirección a la que pueden llamar los usuarios y otros contratos.

Los usuarios no suelen llamar a contratos inteligentes escribiendo bytecode sin procesar.

Normalmente interactúan mediante carteras, aplicaciones, scripts o interfaces que codifican llamadas a funciones usando la ABI del contrato.

El contrato recibe datos de transacción, se ejecuta conforme a las reglas de la EVM, actualiza el almacenamiento si está permitido, emite eventos si se ha programado para ello y devuelve datos o errores.

Toda acción que modifique el estado requiere una transacción de blockchain y una comisión abonada por quien envía la transacción.

Por eso, el desarrollo con Solidity debe considerar tanto la corrección como el coste de gas.

Solidity y la Ethereum Virtual Machine

La Ethereum Virtual Machine, o EVM, es el entorno de ejecución que ejecuta el bytecode compilado de los contratos inteligentes.

La introducción de Solidity a los contratos inteligentes explica que la EVM es el entorno de ejecución de los contratos inteligentes de Ethereum y está aislada del sistema circundante.

Solidity está diseñado para utilizar la EVM como objetivo, lo que significa que el código Solidity se compila en instrucciones que la EVM entiende.

Este diseño permite que los contratos inteligentes se ejecuten de forma determinista entre numerosos nodos.

La ejecución determinista significa que cada nodo honesto debe alcanzar el mismo resultado al procesar la misma transacción bajo el mismo estado de la cadena.

Esto es esencial porque las blockchains necesitan consenso sobre saldos, propiedad, almacenamiento de contratos y resultados de transacciones.

La EVM también crea un entorno aislado que limita lo que pueden hacer los contratos.

Un contrato Solidity no puede llamar directamente a un sitio web aleatorio, leer datos privados de un servidor ni acceder a información off-chain, salvo que esa información se lleve on-chain mediante una transacción o un sistema de oráculos.

Esta limitación mejora el determinismo, pero obliga a los desarrolladores a diseñar cuidadosamente en torno a las necesidades de datos externos.

Por tanto, Solidity no es solo un lenguaje normal de programación web, porque se ejecuta dentro de un modelo de ejecución blockchain con reglas estrictas.

Solidity y los contratos inteligentes

Un contrato inteligente de Solidity es una colección de código y almacenamiento que reside en una dirección blockchain después del despliegue.

El código define qué funciones se pueden llamar y qué hacen esas funciones.

El almacenamiento conserva el estado a largo plazo, como saldos, direcciones de propietarios, valores de configuración, mappings, votos, deudas, reservas y metadatos de tokens.

Un contrato puede recibir transacciones de cuentas de propiedad externa controladas por usuarios.

Un contrato también puede llamar a otros contratos, creando sistemas on-chain componibles.

La componibilidad es una de las características cripto más importantes de Solidity porque un protocolo puede construirse sobre la interfaz de contrato de otro protocolo.

Un contrato de token puede ser utilizado por un protocolo de préstamos, un protocolo de swaps, un contrato de staking y un sistema de gobernanza.

Esto hace que Solidity sea potente, pero también genera riesgo porque el error de un contrato puede afectar a muchas aplicaciones conectadas.

Los contratos inteligentes suelen ser transparentes tras la verificación, pero la transparencia no implica automáticamente seguridad.

Los usuarios deben tratar cada interacción con un contrato como una transacción con riesgo técnico y financiero.

Sintaxis de Solidity

Solidity utiliza llaves, declaraciones de funciones, variables, tipos, structs, mappings, eventos, modificadores y patrones de herencia que pueden resultar familiares a desarrolladores que conocen JavaScript, C++, Java u otros lenguajes similares.

La documentación oficial de Solidity indica que el lenguaje está influido por C++, Python y JavaScript.

Un archivo Solidity suele comenzar con un identificador de licencia y una declaración pragma.

La declaración pragma indica a las herramientas qué versiones del compilador están previstas para el archivo fuente.

Después, una definición de contrato contiene variables de estado, eventos, errores, constructores, funciones, modificadores y, en ocasiones, tipos anidados.

Solidity tiene tipado estático, lo que significa que las variables y los parámetros de las funciones tienen tipos declarados.

Entre los tipos habituales se encuentran bool, uint256, int256, address, bytes, string, arrays, structs, enums y mappings.

Los desarrolladores deben pensar cuidadosamente en el almacenamiento, la memoria, calldata, la visibilidad, la mutabilidad y el control de acceso.

Estos detalles son importantes porque el código Solidity controla activos y puede resultar difícil de modificar después del despliegue.

Una sintaxis aparentemente simple puede producir un comportamiento on-chain complejo.

Contratos

Un contrato es el principal componente básico de Solidity.

Un contrato puede almacenar datos, definir funciones, emitir eventos, heredar de otros contratos e interactuar con otros contratos.

Un contrato de token puede almacenar saldos y allowances.

Un contrato de préstamos puede almacenar colateral, deuda, índices de interés y parámetros de liquidación.

Un contrato de gobernanza puede almacenar propuestas, votos, reglas de quórum y retrasos de ejecución.

Un contrato de staking puede almacenar depósitos, tasas de recompensa, reglas de retirada y datos de reclamación.

Cada contrato desplegado recibe su propia dirección en la blockchain.

Los usuarios llaman a esa dirección para interactuar con las funciones del contrato.

El código del contrato solo se ejecuta cuando una transacción o llamada lo activa.

Un contrato no se ejecuta continuamente como una aplicación de servidor normal.

Variables de estado

Las variables de estado son variables almacenadas permanentemente en el almacenamiento del contrato.

Se utilizan para datos que deben seguir disponibles entre transacciones.

Entre los ejemplos se incluyen saldos de tokens, direcciones de propietarios, oferta total, configuración de comisiones, reservas de protocolo, recuentos de votos y posiciones de usuarios.

El almacenamiento es costoso porque los nodos de la blockchain deben conservar y verificar estos datos.

Los desarrolladores deben evitar almacenar datos innecesarios on-chain.

También deben diseñar cuidadosamente la distribución del almacenamiento, especialmente en contratos actualizables.

Un error en la distribución del almacenamiento puede corromper un estado importante del contrato durante una actualización.

Solidity puede generar información sobre la distribución del almacenamiento mediante el compilador, lo que ayuda a desarrolladores y auditores a revisar el riesgo de actualización.

Los usuarios rara vez ven las variables de estado directamente, salvo que el contrato esté verificado o un explorador de blockchain muestre llamadas legibles.

Sin embargo, estas variables suelen determinar cómo se gestionan los fondos y permisos de los usuarios.

Funciones

Las funciones definen las acciones que puede realizar un contrato Solidity.

Una función puede leer datos, actualizar el almacenamiento, transferir tokens, llamar a otro contrato, emitir un evento o revertir cuando no se cumplen las condiciones.

La visibilidad de las funciones controla quién puede llamar a una función y cómo se puede acceder a ella.

Las palabras clave de visibilidad habituales incluyen public, external, internal y private.

La mutabilidad de una función indica si una función lee o modifica el estado.

Las palabras clave de mutabilidad habituales incluyen view, pure y payable.

Una función view puede leer el estado sin modificarlo.

Una función pure no debe leer ni modificar el estado del contrato.

Una función payable puede recibir el activo nativo de la cadena cuando se llama con valor.

El diseño de las funciones es importante porque muchas vulnerabilidades de contratos inteligentes proceden de comprobaciones ausentes, permisos incorrectos, llamadas externas inseguras o contabilidad errónea.

Eventos

Los eventos son registros emitidos por contratos Solidity durante la ejecución.

Ayudan a las carteras, exploradores, indexadores y aplicaciones a seguir lo ocurrido en una transacción.

Una transferencia de token suele emitir un evento Transfer cuando se implementa conforme a estándares de tokens comunes.

Un protocolo DeFi puede emitir eventos para depósitos, retiradas, préstamos, reembolsos, liquidaciones, swaps, votos o cambios de configuración.

Los eventos son útiles porque su almacenamiento es más barato que el almacenamiento completo del contrato y resulta sencillo indexarlos para sistemas off-chain.

Sin embargo, los eventos no son lo mismo que el estado del contrato.

Un contrato solo puede emitir un evento cuando su código se lo indica.

Las aplicaciones no deben confiar ciegamente en los registros de eventos sin comprender la lógica del contrato.

Los eventos son excelentes para la transparencia y el análisis, pero deben interpretarse junto con el código subyacente.

Para los usuarios, los eventos suelen alimentar los historiales de transacciones legibles mostrados en carteras y exploradores.

Modificadores

Los modificadores son componentes reutilizables de lógica Solidity que pueden cambiar o restringir el comportamiento de las funciones.

Un modificador habitual comprueba si quien realiza la llamada es un propietario, administrador, gobernador o rol autorizado antes de permitir que se ejecute una función.

Los modificadores pueden reducir la repetición de código y facilitar la lectura del control de acceso.

Sin embargo, los modificadores también pueden ocultar una lógica importante si se utilizan en exceso o se escriben de forma poco clara.

Una función puede parecer sencilla mientras que un modificador realiza comprobaciones importantes o cambios de estado en segundo plano.

Los desarrolladores deben mantener los modificadores claros y centrados en una tarea.

Los auditores deben revisar cuidadosamente los modificadores porque suelen proteger funciones sensibles.

Los usuarios que revisen código verificado no deben juzgar una función solo por su cuerpo visible.

También deben comprobar los modificadores heredados y las condiciones de control de acceso.

Un modificador ausente o defectuoso puede crear un riesgo de seguridad grave.

Mappings

Un mapping es una estructura de datos clave-valor utilizada habitualmente en contratos Solidity.

Los saldos de tokens suelen almacenarse en un mapping de dirección a importe.

Los allowances pueden almacenarse en un mapping anidado de propietario a gastador y a importe.

Los sistemas de gobernanza pueden utilizar mappings para registrar si una dirección ha votado.

Los sistemas de préstamos pueden utilizar mappings para registrar el colateral y la deuda de cada usuario.

Los mappings son eficientes para consultar valores por clave.

Sin embargo, no es fácil iterar directamente sobre mappings on-chain.

Los desarrolladores suelen usar eventos o estructuras de datos adicionales cuando necesitan que los sistemas off-chain enumeren entradas de mappings.

Los mappings son potentes, pero requieren una contabilidad cuidadosa.

Una actualización incorrecta de un mapping puede provocar saldos erróneos, permisos defectuosos o pérdida de fondos.

Interfaces

Una interfaz define firmas de funciones a las que otro contrato puede llamar.

Las interfaces son importantes porque los contratos inteligentes suelen necesitar interactuar con otros contratos inteligentes.

Una interfaz de token puede indicar a un contrato DeFi cómo llamar a transfer, transferFrom, approve, balanceOf o allowance.

Una interfaz de oráculo puede indicar a un protocolo de préstamos cómo leer datos de precios.

Una interfaz de gobernanza puede permitir que otro contrato compruebe el estado de una propuesta o el poder de voto.

Las interfaces mejoran la componibilidad porque los contratos pueden depender de formas de funciones comunes.

Sin embargo, una interfaz solo describe las llamadas y valores devueltos previstos.

No demuestra que el contrato detrás de una dirección se comporte de forma honesta o segura.

Los desarrolladores deben validar los supuestos sobre contratos externos antes de integrarlos.

Los usuarios deben recordar que la componibilidad de los contratos puede propagar el riesgo entre sistemas conectados.

Bibliotecas

Las bibliotecas son unidades reutilizables de código Solidity que ayudan a los desarrolladores a evitar reescribir lógica común.

Una biblioteca puede proporcionar funciones matemáticas, utilidades de direcciones, ayudantes para transferencias seguras, herramientas para arrays, herramientas para strings u operaciones de estructuras de datos.

Algunas bibliotecas se integran en el bytecode del contrato durante la compilación.

Otras bibliotecas pueden desplegarse por separado y enlazarse por dirección.

El uso de bibliotecas puede mejorar la calidad del código cuando la biblioteca está bien probada y ampliamente revisada.

El uso de bibliotecas también puede añadir riesgo si la biblioteca está obsoleta, es maliciosa, se enlaza incorrectamente o se usa de forma inadecuada.

Los desarrolladores deben fijar las versiones de las dependencias y revisar el código importado.

Los auditores deben examinar las bibliotecas como parte de toda la base de código.

Los usuarios deben entender que un contrato verificado puede depender de bibliotecas importadas y código heredado.

Un contrato es tan seguro como el conjunto completo de código que afecta a su comportamiento.

Herencia

La herencia permite que un contrato Solidity reutilice y amplíe código de otros contratos.

Resulta útil para lógica de propiedad compartida, comportamiento de tokens, control de acceso, controles de pausa, patrones de actualización y módulos reutilizables.

La herencia puede facilitar la organización del código cuando se utiliza cuidadosamente.

También puede dificultar la revisión del código cuando numerosos contratos heredados interactúan de formas complejas.

Un contrato hijo puede sobrescribir una función de un contrato padre.

La herencia múltiple puede crear problemas sutiles de orden y sobrescritura.

Los desarrolladores deben mantener las estructuras de herencia simples cuando sea posible.

Los auditores deben revisar todo el árbol de herencia, en lugar de únicamente el contrato final.

Los usuarios que lean código verificado deben comprobar los contratos padre importados y no solo el nombre del contrato mostrado en la página.

La herencia es potente, pero la lógica heredada oculta puede ser peligrosa si se ignora.

ABI

ABI significa Application Binary Interface.

La especificación oficial de la ABI de Solidity explica que la ABI es la forma estándar de interactuar con contratos en el ecosistema de Ethereum.

La ABI indica al software cómo codificar llamadas a funciones y decodificar valores devueltos.

Las carteras, los scripts, las aplicaciones y los exploradores de blockchain utilizan ABI para mostrar nombres de funciones y campos de parámetros legibles.

Sin una ABI, los usuarios tendrían que trabajar con calldata sin procesar, que es mucho más difícil de comprender.

La ABI puede incluir funciones, eventos, errores, entradas, salidas e información de tipos.

La ABI no demuestra que un contrato sea seguro.

Solo describe cómo llamar a la interfaz expuesta del contrato.

Un contrato malicioso puede seguir teniendo una ABI de aspecto limpio.

Los usuarios deben considerar los datos ABI como una capa de usabilidad, no como una garantía de confianza.

Compilador de Solidity

El compilador de Solidity, o solc, transforma el código fuente de Solidity en bytecode de la EVM y artefactos de apoyo.

Solc también puede generar datos ABI, metadatos, estimaciones de gas, distribución del almacenamiento, advertencias, errores y resultados intermedios.

La versión y configuración exactas del compilador son importantes porque afectan al bytecode final.

El anuncio de lanzamiento de Solidity 0.8.35 indica que la versión 0.8.35 introdujo un builtin erc7201, una bandera experimental de nivel superior y un generador de código experimental SSA CFG.

Las versiones del compilador importan porque Solidity evoluciona con el tiempo mediante nuevas funciones, correcciones de errores, advertencias y cambios en el objetivo de la EVM.

Un contrato compilado con una versión puede no coincidir con el mismo código fuente compilado con otra versión.

La configuración del compilador, como el estado del optimizador, las ejecuciones del optimizador, la versión de la EVM, via-IR y las direcciones de las bibliotecas, también afecta al resultado.

Por eso los contratos verificados suelen mostrar la versión y configuración del compilador utilizadas para coincidir con el bytecode desplegado.

Los desarrolladores deben fijar las versiones del compilador para despliegues de producción.

Los usuarios deben entender que el código fuente verificado depende de que coincida la configuración de compilación, no solo el texto.

Bytecode

El bytecode es el código de bajo nivel que la EVM ejecuta después de que un contrato Solidity se compile y despliegue.

El bytecode de despliegue se utiliza para crear el contrato.

El bytecode de ejecución es el código que permanece en la dirección del contrato después del despliegue.

Las blockchains ejecutan bytecode en lugar del texto fuente original de Solidity.

Por este motivo, la verificación del código fuente es importante.

La verificación muestra que el código fuente visible y la configuración del compilador pueden reproducir el bytecode desplegado.

La documentación de Ethereum sobre verificación de contratos inteligentes explica que la verificación compara el código fuente con el bytecode compilado.

El bytecode es difícil de leer directamente para la mayoría de los usuarios.

El código fuente verificado hace que el bytecode sea más comprensible.

Sin embargo, incluso el bytecode verificado requiere una revisión de seguridad antes de que los usuarios confíen fondos al contrato.

Gas

El gas es la unidad utilizada para medir el trabajo computacional necesario para ejecutar transacciones y operaciones de contratos inteligentes.

Los desarrolladores de Solidity deben tener en cuenta el gas porque un código costoso puede hacer que un contrato sea caro o poco práctico de utilizar.

Escribir en el almacenamiento suele costar más que leer de la memoria o calldata.

Los bucles sobre conjuntos de datos grandes pueden resultar peligrosos si requieren demasiado gas.

Las llamadas externas pueden añadir coste y riesgo de seguridad.

El despliegue de contratos también cuesta gas porque el bytecode debe almacenarse on-chain.

El optimizador de Solidity puede reducir en ocasiones el coste de gas o el tamaño del bytecode, pero debe configurarse y probarse cuidadosamente.

La optimización del gas no debe realizarse a costa de una lógica poco clara o insegura.

En cripto, un contrato demasiado caro de utilizar puede perjudicar a los usuarios durante la congestión de la red.

Un buen desarrollo con Solidity equilibra seguridad, claridad y eficiencia.

Solidity y los tokens

Solidity se utiliza ampliamente para crear y gestionar contratos de tokens.

Un contrato de token fungible puede registrar saldos, allowances, oferta total, transferencias, aprobaciones, acuñación, quema y controles de acceso.

Un contrato NFT puede registrar ID de tokens únicos, propietarios, aprobaciones, enlaces de metadatos y reglas de transferencia.

Un contrato multitoken puede gestionar muchos tipos de tokens dentro de un sistema de contratos.

Los estándares de tokens son importantes porque facilitan que las carteras, los exploradores y las aplicaciones admitan tokens.

Los estándares ERC-20, ERC-721 y ERC-1155 se encuentran entre los estándares de tokens a nivel de aplicación más importantes del ecosistema Ethereum.

Sin embargo, que un token esté escrito en Solidity o siga un estándar no lo hace seguro ni valioso.

Un contrato de token puede incluir autoridad de acuñación, lógica de lista negra, comisiones, controles de pausa, capacidad de actualización o permisos de administrador peligrosos.

Los usuarios deben revisar los permisos del token, la distribución de holders, la liquidez, las reglas de oferta y el código fuente verificado antes de confiar en un token.

Solidity posibilita la creación de tokens, pero la calidad del token depende del diseño y la gobernanza.

Solidity y DeFi

Solidity es fundamental para muchas aplicaciones de finanzas descentralizadas.

Los contratos DeFi pueden gestionar swaps, pools de liquidez, mercados de préstamos, vaults, derivados, staking, estrategias de rendimiento y sistemas de gobernanza.

Estos sistemas suelen mantener grandes cantidades de activos de usuarios, lo que hace que la seguridad de Solidity sea extremadamente importante.

Un protocolo DeFi puede fallar por un error de código, un problema de oráculo, un modelo contable deficiente, una regla de liquidación errónea, una actualización insegura o un ataque de gobernanza.

Solidity permite que los contratos se llamen entre sí, lo que hace que DeFi sea muy componible.

La componibilidad puede crear componentes financieros útiles.

La componibilidad también puede crear riesgo de dependencia cuando un protocolo depende del comportamiento de otro.

Los desarrolladores deben probar las integraciones en numerosas condiciones de mercado y escenarios de fallo.

Los usuarios deben entender que los contratos inteligentes DeFi pueden ser transparentes y arriesgados al mismo tiempo.

Un rendimiento elevado o un volumen alto no demuestran que el código Solidity sea seguro.

Solidity y los NFT

Solidity se utiliza habitualmente para crear contratos NFT que definen las reglas de propiedad y transferencia de activos digitales únicos.

Un contrato inteligente NFT puede asignar ID de tokens, almacenar registros de propiedad, gestionar aprobaciones y enlazar metadatos.

Los metadatos de NFT suelen apuntar a imágenes, atributos, descripciones o archivos externos.

El contrato inteligente puede no almacenar todos los medios directamente on-chain, porque almacenar grandes cantidades de datos on-chain puede ser costoso.

Los usuarios deben comprobar si los metadatos del NFT están on-chain, descentralizados, son modificables o están controlados por una autoridad del proyecto.

Un contrato NFT de Solidity verificado puede mostrar reglas de acuñación, límites de oferta, comportamiento de royalties, restricciones de transferencia y permisos de administrador.

Sin embargo, muchos riesgos de los NFT no son únicamente riesgos de código.

Los riesgos de los NFT también incluyen colecciones falsas, arte copiado, liquidez débil, metadatos defectuosos, promesas engañosas y manipulación del mercado.

Solidity proporciona la lógica de propiedad, pero no garantiza valor cultural ni demanda futura.

Los compradores de NFT deben combinar la revisión del contrato con la verificación de la colección y el análisis de liquidez.

Solidity y las DAO

Solidity se utiliza a menudo para crear contratos de gobernanza de DAO.

Un contrato de DAO puede gestionar propuestas, poder de voto, delegación, timelocks, ejecución de tesorería y permisos de roles.

Los contratos de gobernanza pueden permitir a los titulares de tokens o miembros votar sobre cambios del protocolo.

También pueden controlar acciones sensibles, como actualizaciones, transferencias de tesorería, cambios de parámetros y pausas de emergencia.

Los contratos de DAO requieren un diseño cuidadoso porque los ataques de gobernanza pueden afectar a activos reales.

Un sistema de votación mal diseñado puede ser vulnerable a baja participación, compra de votos, votación mediante flash loans, control de grandes holders o ejecuciones precipitadas.

Los timelocks pueden dar tiempo a los usuarios para reaccionar antes de que los cambios aprobados surtan efecto.

Los controles de emergencia pueden reducir daños, pero también introducir poder centralizado.

Solidity proporciona a las DAO herramientas de gobernanza programable, pero la seguridad de la gobernanza depende tanto del código como de la coordinación humana.

Los usuarios deben revisar quién puede cambiar un protocolo y con qué rapidez pueden realizarse los cambios.

Riesgos de seguridad de Solidity

La seguridad de Solidity es uno de los temas más importantes del desarrollo cripto.

La documentación de consideraciones de seguridad de Solidity cubre riesgos como la reentrancia, los límites de gas, el envío y la recepción de ether, tx.origin, detalles menores y cuestiones relacionadas con el compilador.

La reentrancia puede producirse cuando un contrato llama a un contrato externo antes de actualizar de forma segura su propio estado.

Los errores de control de acceso pueden permitir que usuarios no autorizados llamen a funciones sensibles.

Los errores de enteros y contabilidad pueden crear saldos incorrectos o lógica de comisiones defectuosa.

Los errores de oráculo pueden provocar precios incorrectos y liquidaciones injustas.

Los errores de actualización pueden sustituir una lógica segura por una lógica insegura.

Las llamadas externas no comprobadas pueden crear rutas de ejecución inesperadas.

Los errores de verificación de firmas pueden permitir ataques de repetición o aprobaciones falsas.

La seguridad de los contratos inteligentes requiere modelado de amenazas, pruebas, revisiones, auditorías, supervisión y diseño conservador.

Reentrancia

La reentrancia es una conocida vulnerabilidad de contratos inteligentes en la que una llamada externa permite que otro contrato vuelva a llamar antes de que el primer contrato termine de actualizar su estado.

Esto puede permitir retiradas repetidas, contabilidad defectuosa o flujo de control inesperado.

La documentación de seguridad de Solidity recomienda el patrón Checks-Effects-Interactions como una forma de reducir el riesgo de reentrancia.

El patrón significa que un contrato debe comprobar primero las condiciones, actualizar el estado interno en segundo lugar e interactuar con contratos externos al final.

La protección contra reentrancia también puede incluir bloqueos, diseños de pagos mediante retirada y una revisión cuidadosa de las llamadas externas.

Los desarrolladores no deben asumir que enviar activos es inofensivo.

Las llamadas externas pueden ejecutar código y cambiar el flujo de control.

Los usuarios deben tener cuidado con protocolos que tengan lógica de retirada sin auditar o rutas complejas de callback.

La reentrancia no es el único riesgo de Solidity, pero es uno de los ejemplos más importantes de por qué la lógica de los contratos inteligentes difiere del software normal.

Una transferencia aparentemente segura puede resultar peligrosa si las actualizaciones de estado se realizan en el orden incorrecto.

Control de acceso

El control de acceso determina quién puede llamar a funciones sensibles de Solidity.

Las funciones importantes pueden incluir acuñar tokens, pausar transferencias, actualizar contratos, modificar comisiones, configurar oráculos, retirar fondos de tesorería o conceder roles.

El control de acceso puede basarse en una dirección de propietario, roles, carteras multifirma, contratos de gobernanza, timelocks o sistemas de permisos personalizados.

Un control de acceso débil puede permitir que atacantes o personas internas modifiquen el comportamiento del contrato.

Un control de acceso excesivamente centralizado también puede crear riesgo de confianza para los usuarios.

Un contrato puede funcionar técnicamente y, aun así, ser inseguro si una sola clave privada puede vaciar fondos o cambiar reglas de inmediato.

Los desarrolladores deben diseñar permisos con el principio de mínimo privilegio, una separación clara de roles y planes de recuperación.

Los usuarios deben revisar los poderes de administrador antes de depositar fondos en un protocolo.

El código Solidity verificado puede revelar la lógica de permisos cuando el código fuente está disponible.

El riesgo de administrador es un riesgo de contrato inteligente incluso cuando no hay un error de programación.

Seguridad de enteros

Las operaciones con enteros son importantes en Solidity porque los contratos suelen gestionar saldos, participaciones, precios, comisiones, intereses y recompensas.

Las versiones antiguas de Solidity requerían más cuidado manual frente al desbordamiento por exceso y por defecto de enteros.

Solidity 0.8.x introdujo aritmética comprobada por defecto, que revierte ante la mayoría de condiciones de desbordamiento por exceso y por defecto, salvo que se utilicen bloques unchecked.

Esta mejora de seguridad no elimina todos los riesgos matemáticos.

Los desarrolladores aún pueden cometer errores de redondeo, precisión, factores de escala, diferencias de decimales, orden de comisiones y contabilidad de participaciones.

Los bloques unchecked pueden mejorar la eficiencia de gas en casos seleccionados, pero deben utilizarse cuidadosamente.

Los contratos DeFi suelen utilizar matemáticas de punto fijo y decimales de tokens, lo que puede generar errores sutiles.

Los auditores deben revisar los supuestos matemáticos y los casos límite.

Los usuarios deben entender que una aritmética segura no implica automáticamente una economía segura.

Las fórmulas correctas son tan importantes como la protección frente a desbordamientos.

Oráculos y datos externos

Los contratos Solidity no pueden acceder directamente a datos off-chain por sí mismos.

La documentación de Ethereum sobre oráculos explica que los oráculos proporcionan a los contratos inteligentes datos procedentes del mundo externo.

Los oráculos pueden proporcionar precios, aleatoriedad, datos de prueba, datos meteorológicos, datos deportivos, información de identidad u otras entradas off-chain.

En DeFi, los oráculos de precios son especialmente importantes porque pueden determinar valores de colateral, liquidaciones, acuñación, reembolsos y liquidación.

Un mal diseño de oráculo puede causar grandes pérdidas incluso cuando el código Solidity está correctamente escrito.

Los desarrolladores deben evitar depender de precios spot fácilmente manipulables procedentes de mercados con poca liquidez.

También deben considerar la frecuencia de actualización, el comportamiento de respaldo, los retrasos de datos y los interruptores de emergencia.

Los usuarios deben comprobar qué fuente de oráculo utiliza un protocolo antes de depositar colateral o tomar activos prestados.

Solidity puede aplicar reglas basadas en oráculos, pero no puede convertir datos deficientes en buenos datos.

Los datos externos son uno de los mayores supuestos de confianza en muchos sistemas de contratos inteligentes.

Capacidad de actualización

Los contratos Solidity suelen describirse como inmutables, pero muchos proyectos utilizan patrones de actualización para cambiar la lógica después del despliegue.

Los contratos actualizables suelen separar un contrato proxy de un contrato de implementación.

El proxy conserva la dirección y el almacenamiento, mientras que la implementación contiene una lógica que puede sustituirse mediante una función de actualización.

La capacidad de actualización puede corregir errores y añadir funciones.

También puede crear riesgo de confianza porque los administradores o la gobernanza pueden cambiar las reglas después de que los usuarios depositen fondos.

La distribución del almacenamiento debe gestionarse cuidadosamente porque las actualizaciones incorrectas pueden corromper el estado.

Los usuarios deben comprobar si un contrato es actualizable, quién controla las actualizaciones, si existe un timelock y si las actualizaciones se anuncian públicamente.

Los desarrolladores deben documentar claramente los poderes de actualización.

Los auditores deben revisar tanto la implementación actual como los controles de actualización.

La capacidad de actualización es útil, pero cambia el modelo de confianza de los contratos Solidity.

Verificación del código fuente

La verificación del código fuente ayuda a los usuarios a confirmar que el código fuente Solidity publicado coincide con el bytecode desplegado.

La documentación de verificación de Ethereum explica que la verificación compara el código fuente de un contrato con el bytecode compilado utilizado durante la creación del contrato.

La verificación suele requerir los archivos fuente exactos, la versión del compilador, la configuración del compilador, los argumentos del constructor, las direcciones de las bibliotecas y la configuración de metadatos.

El código fuente verificado mejora la transparencia porque los usuarios pueden leer la lógica del contrato.

También ayuda a las carteras y exploradores a decodificar llamadas a funciones y eventos.

Sin embargo, la verificación del código fuente no es lo mismo que una auditoría.

Un contrato verificado aún puede contener errores, controles de administrador inseguros, riesgo de actualización o un diseño económico deficiente.

Es más difícil confiar en contratos no verificados porque los usuarios no pueden comparar fácilmente código legible por humanos con bytecode desplegado.

Los usuarios deben ser cautos cuando un sitio web solicita aprobaciones o depósitos en un contrato no verificado.

La verificación es un punto de partida para la diligencia debida, no su conclusión.

Versiones de Solidity

Las versiones de Solidity son importantes porque el lenguaje cambia con el tiempo.

Las nuevas versiones pueden incorporar funciones, mejorar las advertencias, cambiar valores predeterminados, corregir errores del compilador y admitir nuevo comportamiento de la EVM.

Los anuncios de lanzamiento de Solidity oficiales publican detalles sobre las versiones del compilador y los cambios del lenguaje.

Según la información oficial de lanzamientos disponible en 2026, Solidity 0.8.35 es una versión reciente del compilador con nuevas funcionalidades y características experimentales.

Los proyectos de producción no deben actualizar las versiones del compilador sin más.

Toda actualización del compilador debe probarse porque el bytecode, el comportamiento del gas, las advertencias y los resultados de compilación pueden cambiar.

Los desarrolladores deben leer las notas de lanzamiento antes de cambiar las versiones del compilador.

Los auditores deben revisar la versión del compilador utilizada en la compilación auditada.

Los usuarios que revisen contratos verificados deben comprobar la versión del compilador mostrada en el explorador.

La elección de la versión de Solidity forma parte de la seguridad y reproducibilidad de los contratos inteligentes.

Errores del compilador de Solidity

Los errores del compilador son poco frecuentes, pero importantes, porque el compilador convierte el código fuente en el bytecode que realmente se ejecuta on-chain.

La documentación oficial de errores conocidos de Solidity registra los errores conocidos del compilador y las versiones a las que afectan.

Un contrato puede verse afectado por un problema del compilador incluso si el código fuente parece correcto.

Los desarrolladores deben comprobar los errores conocidos del compilador antes de desplegar contratos de producción.

Los auditores deben incluir la revisión de la versión del compilador en su proceso.

Los usuarios deben ser cautos cuando un contrato utiliza una versión muy antigua del compilador sin una razón clara.

No todas las versiones antiguas del compilador son automáticamente inseguras, pero las versiones antiguas pueden no contar con comprobaciones y correcciones más recientes.

Los equipos de contratos inteligentes deben tratar el compilador como parte de su cadena de suministro de software de confianza.

Las compilaciones reproducibles y la configuración registrada del compilador ayudan a identificar si puede aplicarse un error conocido.

El riesgo del compilador es otra razón por la que deben conservarse los artefactos de despliegue.

Herramientas de desarrollo de Solidity

Los desarrolladores de Solidity suelen utilizar herramientas para escribir, compilar, probar, desplegar, verificar y supervisar contratos.

El Remix IDE oficial es un entorno basado en navegador utilizado habitualmente para aprender, escribir, compilar y probar contratos Solidity.

Los frameworks de línea de comandos y los entornos de desarrollo locales pueden automatizar la compilación, las pruebas, los despliegues, las pruebas con forks y la verificación.

Las herramientas de análisis estático pueden analizar código Solidity en busca de vulnerabilidades comunes y patrones arriesgados.

Las herramientas de fuzz testing pueden generar numerosas entradas para encontrar comportamientos inesperados.

Las herramientas de verificación formal pueden demostrar propiedades seleccionadas bajo supuestos definidos.

Ninguna herramienta por sí sola puede garantizar la seguridad.

El desarrollo profesional con Solidity suele combinar pruebas unitarias, pruebas de integración, pruebas fuzz, revisión de código, auditorías, scripts de despliegue, supervisión y planificación de respuesta ante incidentes.

Los principiantes deben empezar con contratos pequeños y redes de prueba antes de utilizar fondos reales.

Los equipos avanzados deben utilizar pipelines de compilación reproducibles y controles estrictos de lanzamiento.

Pruebas de contratos Solidity

Las pruebas son esenciales porque los contratos inteligentes desplegados pueden controlar activos valiosos.

Las pruebas unitarias verifican funciones individuales y comportamientos esperados.

Las pruebas de integración comprueban cómo funcionan juntos varios contratos.

Las pruebas con forks simulan el comportamiento de contratos frente al estado real de una cadena copiado en un entorno local.

Las pruebas fuzz prueban muchas entradas aleatorias o estructuradas para detectar casos límite.

Las pruebas de invariantes comprueban que las reglas importantes sigan siendo ciertas durante numerosas acciones.

Las pruebas deben incluir flujos normales, flujos de fallo, comprobaciones de permisos, casos límite y escenarios de usuarios maliciosos.

Los desarrolladores deben probar con decimales de tokens realistas, comportamientos inusuales de tokens, valores altos, valores cero y condiciones límite.

Las pruebas no pueden demostrar que todo posible comportamiento sea seguro, pero reducen considerablemente los errores evitables.

No se debe confiar código Solidity sin probar para gestionar fondos significativos.

Auditorías

Una auditoría de contrato inteligente es una revisión de seguridad realizada por especialistas que inspeccionan el código Solidity, la arquitectura, los permisos, las pruebas y los supuestos de riesgo.

Una auditoría puede detectar errores, defectos de diseño, problemas de control de acceso, riesgos económicos, problemas de actualización y carencias de documentación.

Una auditoría no garantiza que un contrato sea seguro.

Es un proceso de reducción de riesgos, no un escudo perfecto.

La calidad de una auditoría depende del alcance, el tiempo, la habilidad del auditor, la cobertura de pruebas, la documentación y cómo el equipo corrige los hallazgos.

Los usuarios deben leer si los hallazgos de la auditoría se resolvieron o se aceptaron.

También deben comprobar si el contrato desplegado coincide con el commit auditado y la configuración del compilador.

Un proyecto puede ser auditado y posteriormente desplegar actualizaciones no auditadas.

Las auditorías son más útiles cuando se combinan con verificación pública, programas de recompensas por errores, supervisión y límites de lanzamiento conservadores.

Los contratos Solidity que gestionan grandes cantidades de valor deben revisarse seriamente antes del despliegue en mainnet.

Solidity e interacciones con carteras

Las carteras ayudan a los usuarios a firmar transacciones que llaman a contratos Solidity.

Una cartera puede mostrar la dirección del contrato, el nombre de la función, los parámetros, las aprobaciones de activos, la comisión de gas y mensajes de advertencia.

La cartera no siempre sabe si un contrato es seguro.

Algunos sitios web maliciosos pueden pedir a los usuarios que firmen transacciones peligrosas que llaman a funciones Solidity reales de formas perjudiciales.

Las aprobaciones de tokens son especialmente importantes porque una aprobación puede permitir que un contrato gaste tokens de una cartera hasta un importe definido.

Los usuarios deben revisar los importes de aprobación y las direcciones de los contratos antes de firmar.

Deben evitar firmar transacciones que no entiendan.

Deben ser cautos cuando una interfaz oculta calldata o solicita aprobaciones ilimitadas.

Solidity permite interacciones programables, pero los usuarios siguen controlando las firmas desde sus carteras.

La firma de una transacción puede mover fondos permanentemente u otorgar permisos.

Solidity y las aprobaciones de tokens

Las aprobaciones de tokens son un patrón habitual de Solidity que permite a una dirección gastar tokens en nombre de otra dirección.

En un token de estilo ERC-20, approve establece un allowance y transferFrom utiliza ese allowance.

Este diseño hace posibles los swaps, depósitos, pagos y acciones automatizadas en DeFi.

También crea riesgo porque un gastador malicioso o comprometido puede utilizar una aprobación para mover tokens dentro del límite aprobado.

Las aprobaciones ilimitadas son prácticas, pero aumentan la exposición.

Los usuarios deben aprobar solo lo necesario cuando sea práctico.

Deben revocar las aprobaciones no utilizadas mediante herramientas de cartera o seguridad de confianza.

Los desarrolladores deben diseñar interfaces que expliquen claramente las aprobaciones.

Los auditores deben comprobar la gestión de allowances en busca de condiciones de carrera, comprobaciones ausentes y supuestos inseguros.

Las aprobaciones son una de las formas más habituales en que los usuarios ordinarios interactúan con el riesgo de Solidity.

Solidity y la verificación formal

La verificación formal utiliza métodos matemáticos para demostrar que determinadas propiedades de un contrato se cumplen bajo supuestos definidos.

Esto puede ser útil para sistemas de alto valor, protocolos financieros, bridges, módulos de gobernanza y lógica contable principal.

Una propiedad podría establecer que la oferta total nunca supera un límite o que los usuarios no pueden retirar más que su saldo.

La verificación formal no elimina la necesidad de pruebas y auditorías.

Solo demuestra las propiedades que realmente se especifican.

Si la especificación es incompleta o incorrecta, la demostración puede omitir riesgos del mundo real.

Los métodos formales pueden ser costosos y requieren conocimientos especializados.

Son más potentes cuando se aplican a lógica crítica con reglas claras.

Para Solidity, la verificación formal forma parte de un proceso de seguridad maduro.

Resulta especialmente útil cuando el fallo del contrato podría crear grandes pérdidas.

Ventajas de Solidity

La primera ventaja de Solidity es la adopción de su ecosistema.

Muchas herramientas de contratos inteligentes, tutoriales, auditorías, estándares, bibliotecas y comunidades de desarrolladores admiten Solidity.

La segunda ventaja es la compatibilidad con la EVM.

Los contratos Solidity pueden utilizar Ethereum y otros entornos compatibles con la EVM cuando las reglas de red y la configuración de despliegue son compatibles.

La tercera ventaja es la componibilidad.

Los contratos Solidity pueden llamar a otros contratos y construirse sobre estándares de tokens e interfaces de protocolos existentes.

La cuarta ventaja es la expresividad.

Los desarrolladores pueden crear tokens, sistemas DeFi, DAO, juegos, NFT y lógica financiera automatizada.

La quinta ventaja es la transparencia, ya que el código fuente Solidity verificado puede ser leído y revisado por usuarios y auditores.

Estas ventajas explican por qué Solidity sigue siendo uno de los lenguajes de contratos inteligentes más importantes en cripto.

Riesgos y limitaciones de Solidity

El primer riesgo es que los errores pueden ser costosos y difíciles de corregir después del despliegue.

El segundo riesgo es que la lógica de los contratos inteligentes puede ser explotada por cualquier usuario que encuentre una debilidad.

El tercer riesgo es que los contratos Solidity suelen interactuar con otros contratos, lo que crea riesgo de dependencia.

El cuarto riesgo es que los costes de gas pueden hacer que algunos diseños sean poco prácticos.

El quinto riesgo es que la capacidad de actualización puede crear riesgo de confianza en administradores o gobernanza.

El sexto riesgo es que el código fuente verificado puede seguir siendo malicioso o estar mal diseñado.

El séptimo riesgo es que los desarrolladores pueden malinterpretar el comportamiento de la EVM, la distribución del almacenamiento, la reentrancia o las llamadas externas.

El octavo riesgo es que los usuarios pueden firmar transacciones perjudiciales sin entender qué hará el contrato Solidity.

El noveno riesgo es que los problemas de oráculos y diseño económico pueden romper un protocolo incluso cuando la sintaxis es correcta.

El décimo riesgo es que la configuración del compilador y las versiones de dependencias pueden cambiar el bytecode final desplegado.

Errores comunes en Solidity

Un error habitual es escribir un control de acceso que no protege funciones sensibles.

Otro error es realizar llamadas externas antes de actualizar de forma segura el estado interno.

Un tercer error es confiar en tx.origin para la autorización, algo contra lo que advierte la documentación de seguridad de Solidity.

Un cuarto error es ignorar los decimales de los tokens y los problemas de precisión en los cálculos.

Un quinto error es asumir que todos los tokens de estilo ERC-20 se comportan exactamente de la misma forma.

Un sexto error es utilizar contratos actualizables sin preservar la distribución del almacenamiento.

Un séptimo error es desplegar con una configuración del compilador diferente de la utilizada en la compilación auditada.

Un octavo error es ignorar las advertencias del compilador.

Un noveno error es otorgar demasiado poder a una única clave de administrador.

Un décimo error es lanzar contratos antes de probar los casos límite y los escenarios de fallo.

Cómo evaluar un contrato Solidity

Empieza comprobando si el código fuente del contrato está verificado.

Después, comprueba la versión del compilador, la configuración del optimizador, los argumentos del constructor y las bibliotecas enlazadas.

Revisa si el contrato es actualizable y quién controla las actualizaciones.

Comprueba los roles de administrador, los permisos de propietario, los controles multifirma, los timelocks y las funciones de emergencia.

Revisa la acuñación, quema, pausa, inclusión en listas negras, comisiones y restricciones de transferencia al evaluar contratos de tokens.

Revisa las fuentes de oráculos, las reglas de colateral, la lógica de liquidación y la contabilidad al evaluar contratos DeFi.

Comprueba si existen auditorías y si se corrigieron sus hallazgos.

Compara la dirección del contrato desplegado con las fuentes oficiales del proyecto.

Revisa las transacciones y eventos recientes para ver cómo se utiliza el contrato.

Un contrato Solidity debe evaluarse conjuntamente como código, infraestructura, gobernanza y diseño económico.

Prácticas recomendadas para desarrolladores

Utiliza una versión estable y reciente del compilador Solidity después de leer las notas de lanzamiento y probar el comportamiento.

Fija las versiones del compilador y de las dependencias para las compilaciones de producción.

Trata las advertencias del compilador como elementos que revisar, no como ruido inofensivo.

Utiliza controles de acceso claros y permisos de mínimo privilegio.

Sigue patrones seguros de llamadas externas, como Checks-Effects-Interactions, cuando corresponda.

Escribe pruebas para rutas normales, rutas de fallo, casos límite y comportamiento de usuarios maliciosos.

Utiliza análisis estático, fuzz testing y auditorías para contratos que gestionen un valor significativo.

Documenta los poderes de administrador, los poderes de actualización, los supuestos de los oráculos y los controles de emergencia.

Verifica el código fuente después del despliegue utilizando la configuración exacta del compilador.

Supervisa los contratos desplegados y prepara planes de respuesta ante incidentes antes del lanzamiento.

Prácticas recomendadas para usuarios

Comprueba si un contrato está verificado antes de interactuar con él.

Compara las direcciones de los contratos con fuentes oficiales del proyecto en lugar de confiar en enlaces de mensajes aleatorios.

Revisa las aprobaciones de tokens antes de firmar transacciones.

Ten cuidado con las aprobaciones ilimitadas y revoca los permisos no utilizados cuando sea práctico.

Comprueba si un contrato es actualizable y quién controla las actualizaciones.

No asumas que un contrato verificado está auditado o es seguro.

No deposites fondos en contratos que no puedas entender o en los que no puedas confiar de forma independiente.

Utiliza hardware wallets o una seguridad sólida de la cartera para interacciones de alto valor.

Ten cuidado con contratos Solidity nuevos, sin auditar, de alto rendimiento o anónimos.

Recuerda que una transacción de blockchain suele ser irreversible una vez confirmada.

FAQ

¿Para qué se utiliza Solidity?

Solidity se utiliza para escribir contratos inteligentes para Ethereum y otros entornos blockchain compatibles con la EVM.

¿Solidity es una criptomoneda?

No. Solidity es un lenguaje de programación, no una criptomoneda ni un token.

¿Solidity es solo para Ethereum?

Solidity se diseñó para Ethereum, pero también se utiliza en otras redes blockchain compatibles con la Ethereum Virtual Machine o con entornos de ejecución compatibles.

¿Qué es un contrato inteligente de Solidity?

Un contrato inteligente de Solidity es código blockchain que define reglas para almacenar datos, gestionar transacciones y activos e interactuar con usuarios u otros contratos.

¿Qué es el compilador de Solidity?

El compilador de Solidity, denominado solc, convierte código fuente de Solidity en bytecode de la EVM, datos ABI, metadatos y otros resultados de compilación.

¿Qué es la ABI en Solidity?

La ABI es la Application Binary Interface que indica a las carteras, aplicaciones y scripts cómo llamar a las funciones de un contrato y decodificar sus respuestas.

¿Es seguro Solidity?

Solidity puede utilizarse de forma segura, pero la seguridad de los contratos inteligentes depende de un diseño seguro, pruebas, auditorías, la configuración del compilador, el control de acceso y un despliegue cuidadoso.

¿Se pueden modificar los contratos Solidity después del despliegue?

Los contratos básicos desplegados suelen ser inmutables, pero los patrones de proxy actualizables pueden permitir que la lógica del contrato cambie si existen permisos de actualización.

¿Por qué los contratos Solidity necesitan auditorías?

Los contratos Solidity suelen controlar activos valiosos, por lo que las auditorías ayudan a encontrar errores, problemas de permisos, defectos económicos y supuestos inseguros antes o después del despliegue.

¿Cómo pueden comprobar los usuarios un contrato Solidity?

Los usuarios pueden comprobar la verificación del código fuente, la configuración del compilador, la dirección del contrato, las auditorías, los permisos de administrador, la capacidad de actualización, las aprobaciones de tokens, el historial de transacciones y la documentación oficial del proyecto.

Conclusión

Solidity es uno de los lenguajes de programación más importantes del ecosistema cripto porque permite crear contratos inteligentes para tokens, DeFi, NFT, DAO, sistemas de staking y muchas otras aplicaciones on-chain.

Permite a los desarrolladores escribir reglas legibles por humanos que se compilan en bytecode de la EVM y son ejecutadas por nodos de blockchain.

La fortaleza de Solidity procede de su amplio ecosistema, los estándares de contratos inteligentes, la componibilidad, las herramientas y el extenso soporte de la EVM.

Su riesgo procede del hecho de que el código desplegado puede controlar activos reales y puede ser difícil de corregir después del despliegue.

Un buen desarrollo con Solidity requiere una configuración cuidadosa del compilador, pruebas, auditorías, control de acceso, planificación de actualizaciones, conocimiento del gas y revisión de seguridad.

Un buen uso de Solidity requiere que los usuarios verifiquen las direcciones de los contratos, lean los permisos, gestionen las aprobaciones, comprueben las auditorías y eviten contratos desconocidos o no verificados.

Para principiantes, Solidity se entiende mejor como el lenguaje que utilizan los desarrolladores para escribir programas de blockchain.

Para usuarios avanzados, Solidity es un lenguaje de contratos inteligentes cuya seguridad depende de la calidad del código, el comportamiento de la EVM, la configuración del compilador, las dependencias externas, la gobernanza y el diseño económico.

En el contexto de un glosario cripto, Solidity es el principal lenguaje de alto nivel utilizado para crear y desplegar contratos inteligentes que se ejecutan en entornos blockchain de tipo Ethereum.

La idea clave es que Solidity hace posible la cripto programable, pero todo contrato Solidity debe tratarse como software de alto impacto que requiere verificación, revisión de seguridad y un criterio cuidadoso por parte del usuario.