Según el sitio web oficial , los contratos inteligentes de Ethereum se ejecutan "exactamente según lo programado, sin ninguna posibilidad de tiempo de inactividad, censura, fraude o interferencia de terceros". Hoy intentaré averiguar si todo es tan color de rosa, de hecho, después de examinar algunos de los problemas que enfrentan los usuarios de contratos inteligentes en la práctica.
Al final del artículo, resumo mis pensamientos con una breve guía para escribir contratos seguros e inteligentes.
- Este artículo se centrará solo en los contratos inteligentes de Ethereum. La comunidad ha identificado tácitamente los contratos inteligentes con los contratos inteligentes de Ethereum. Mientras tanto, el primero es más un concepto, y el segundo es la implementación, y la cuestión de cómo esta implementación cumple con el concepto puede discutirse (así como, en principio, el concepto mismo de contratos inteligentes y otras posibles implementaciones). Este tema es complejo, subestimado e interesante, pero este no es el tema de este artículo, por lo que referiré a aquellos interesados en los trabajos de Nick Szabo . En consecuencia, en todas partes, donde digo "contratos inteligentes", en realidad me refiero a "contratos inteligentes de Ethereum".
- El artículo se centrará solo en el lenguaje de los contratos inteligentes Solidity como el más popular y para el usuario de Ethereum, de hecho, el único en este momento.
Problemas de seguridad de contrato inteligente
Se tratará de los problemas que los desarrolladores de contratos inteligentes enfrentan al final, y no de la seguridad de la plataforma en sí (aunque un poco al respecto). Convencionalmente, dividimos estos problemas en los siguientes tipos:
- problemas en el código de contrato inteligente;
- problemas en el proceso de desarrollo;
- problemas en el idioma;
- problemas de concepto
1. Problemas en el código de contrato inteligente
Por problemas en el código de un contrato inteligente aquí, me refiero a los problemas que se resuelven editando el archivo .sol. Esto es en particular:
- Construcciones vulnerables conocidas (por ejemplo, reencuentro ).
Ejemplo de vida : reencuentro o, más ampliamente, violación del patrón Checks-Effects-Interactions, incluso vulnerabilidades ampliamente conocidas (y previamente explotadas ) continúan encontrándose en nuevos contratos. - Construcciones vulnerables del autor (en particular, errores en la lógica del código).
Ejemplo de vida : una billetera MultiSig que en realidad no es una MultiSig. Para firmar una transacción y transferir fondos, necesita el número de firmas de los propietarios de la billetera igual al required . Al mismo tiempo, para cambiar lo required (por ejemplo, por uno, para firmar más transacciones usted mismo), solo la firma de uno de los propietarios es suficiente:
- Mala arquitectura
Ejemplo de vida : un intento de implementar un token, una billetera y un almacén de claves dentro de un solo contrato. El contrato resulta ser demasiado complicado, el código es difícil de mantener, auditar, modificar. Como resultado, la seguridad también sufre. - Código de baja calidad.
Ejemplo de vida : contratos con diferentes sangrías, saltos de línea arbitrarios y espacios. El código es difícil de leer, lo que significa que la seguridad vuelve a sufrir. A pesar de que ya hay linters para Solidity ( Solium , Solhit ).
Los problemas en el código conducen directamente a ataques y pérdida de fondos. La buena noticia es que los problemas de código pueden identificarse durante el proceso de auditoría y resolverse. Es importante comprender de dónde provienen para evitarlos en el futuro. Por lo tanto, pasamos al siguiente párrafo.
2. Problemas en el proceso de desarrollo.
Los problemas en el código son causados principalmente por un proceso de desarrollo creado incorrectamente. Parecería que el desarrollo de software es un negocio muy estudiado con las mejores prácticas establecidas. Sin embargo, la juventud del campo de los contratos inteligentes, el dinero desproporcionadamente grande y la exageración conducen al hecho de que las personas por una razón u otra descuidan los procedimientos estándar, lo que a menudo conduce a problemas graves. De los más típicos, vale la pena mencionar:
- TK: La mayoría de los contratos inteligentes de Ethereum se escriben sin una tarea técnica. A lo que esto puede conducir, a explicar innecesariamente.
- Tiempo: en promedio, se asigna muy poco tiempo para el desarrollo, aproximadamente un mes. Un ejemplo extremo de mi práctica: el cliente le pidió al desarrollador que redactara un contrato inteligente 3 días antes del ICO.
- Nivel de desarrollador: mucha gente viene al campo, incluso sin experiencia en programación.
- Comprender el ecosistema: e incluso si se trata de un contexto, a menudo los desarrolladores no están profundamente inmersos en el tema y no entienden los detalles de los contratos inteligentes.
- Costo de desarrollo: y, sin embargo, quienes escriben contratos inteligentes son pocos; incluso menos que los escriban bien. De ahí el costo irrazonablemente alto del desarrollo.
3. Problemas en el idioma.
Agrega alquitrán al lenguaje de la solidez misma. Inicialmente, se creó más para que una gran cantidad de personas pudiera dominarlo rápidamente, en lugar de hacerlo conveniente para escribir contratos inteligentes seguros en él. Estas son solo algunas de sus características que interfieren con la seguridad:
- Herencia múltiple,
using for , call / delegate call : todo esto inicia el código no desde la fuente actual, lo que significa que reduce la legibilidad y, como resultado, la seguridad del código. - Patrón Checks-Effects-Interactions: si las construcciones que violan el CEI no son seguras, ¿por qué no prohibirlas (y muchas otras) simplemente a nivel de lenguaje?
- Al llamar a otro contrato, puede caer repentinamente en su función alternativa con consecuencias inesperadas.
Está claro que el proyecto Ethereum se está desarrollando, y es imposible tener todo en cuenta de antemano. Pero al final, los desarrolladores se ven obligados a recordar muchas características y usar muletas para hacer seguro su contrato inteligente.
4. Problemas en el concepto.
Sin embargo, el problema más grave es aún más profundo: muchos no entienden lo suficiente por qué se necesitan contratos inteligentes, qué pueden, qué no pueden y cómo funcionan. En el peor de los casos, esto lleva al hecho de que el contrato inteligente:
No inteligente:
- Mal escrito: hace lo que está escrito, pero no lo que se pretende.
- Está fuertemente vinculado al backend y / o frontend, y este código ya no es un contrato inteligente, se ejecuta de la manera habitual y su implementación está completamente controlada por el administrador del servidor.
No es un contrato:
- No registra las obligaciones de las partes; por ejemplo, ICO vende sus tokens por ETH, pero los tokens son esencialmente envoltorios de caramelos, porque no imponga a quien los liberó ninguna restricción u obligación.
- Permite cambios unilaterales, y resulta que una de las partes puede cambiar el contrato después de su firma.
Ejemplo de vida : el propietario del contrato puede cambiar arbitrariamente la capitalización, la tasa y la duración de la venta de tokens:
No es necesario:
- El contrato inteligente se agregó no porque fuera técnicamente necesario, sino al tratar de averiguar qué hacer con los contratos inteligentes y montar una ola de exageraciones;
- Intentamos descubrir cómo vincular los contratos inteligentes con un producto existente.
Contrato inteligente como amenaza de seguridad para el inicio de blockchain
Cual es el resultado? Querían que fuera blockchain de moda, seguro, pero obtenemos un costoso código no compatible que amenaza la seguridad y no es necesario en absoluto. Queríamos que nuestros contratos inteligentes se ejecutaran "exactamente como estaba programado, sin ninguna posibilidad de tiempo de inactividad, censura, fraude o intervención de terceros", y al final realmente se ejecutan tal como están escritos, solo están escritos con vulnerabilidad. Y todo lo que nos queda es agitar un bolígrafo a nuestra manera. Bueno, o hacer un hard fork (desacreditando así la idea original en sí) si los creadores de Ethereum perdieron dinero debido a la vulnerabilidad.
Cómo escribir contratos inteligentes seguros
De hecho, por supuesto, no todo es tan malo. Simplemente exagero en un intento de llamar la atención sobre algunos puntos importantes, en mi opinión. En general, el área se está desarrollando, las personas están aprendiendo, incluida la seguridad.
Si el lector decide escribir un contrato inteligente, le aconsejaría:
- entender por qué se necesita un contrato inteligente (y si es necesario);
- recibir del cliente o escribir TK;
- calcular el tiempo;
- utilizar herramientas de desarrollo y prueba ( Truffle , Remix , SmartCheck , Solhint o Solium linter );
- escribir pruebas;
- realizar varias auditorías independientes y recompensas de errores;
- supervisar la seguridad de los componentes restantes del proyecto (sitio web, Twitter, etc.).
Siguiendo estas simples recomendaciones, puede evitar la mayoría de los problemas descritos anteriormente (sin embargo, desde una bifurcación dura, esto aún no se guardará).
El artículo fue creado en conjunto con Eugene Marchenko ( eMarchenko ).