Riesgo en los Contratos Inteligentes. Perspectiva de Jan Xie

Una de las mayores preocupaciones que nos abordan en esta nueva era DeFi es la seguridad asociada a los contratos inteligentes. La numerosa experiencia de robos y fallos que tuvieron como consecuencia la pérdida de grandes capitales, ha puesto la lupa encima del universo DeFi con la finalidad de evaluar aquellos detalles que inciden sobre la seguridad.

En este sentido tenemos un interesante arículo publicado por Jan Xie, cofundador de Nervos, en Diciembre de 2019: The Smart Contract Risk in DeFi. Finance is the art of risk management… | by Jan Xie | Nervos Network | Medium
En él podemos encontrar interesantes aspectos ligados a la seguridad de los contratos inteligentes, comparando la estructura de tokens nativos en una red como Ethereum con los de una red como Nervos o Cardano. En estas cadenas los tokens nativos no están ligados a un contrato a diferencia de lo que ocurre con los tokens ERC20 en Ethereum.

Asímismo Jan presenta una serie de soluciones que se han implementado en la cadena de Nervos con las que se muestra un entorno DeFi más seguro.
Recordemos que uno de los paradigmas de Nervos, compartido por Cardano, es la interoperabilidad entre cadenas. Se puede adivinar fácilmente un futuro común en la operabilidad de ambas.

Les dejo la traducción del citado artículo.

El Riesgo del Contrato Inteligente en DeFi

Las finanzas son el arte de la gestión de riesgos. Los riesgos existen tanto en los activos como en las operaciones. Un activo tiene un precio. Este precio es un reflejo de su valor intrínseco y del conjunto de sus riesgos. No podemos evaluar un activo sin analizar su riesgo. Los riesgos en las operaciones provienen principalmente del factor humano, propenso a errores y corruptible. La evaluación del riesgo, tanto del activo como de sus operaciones, es el núcleo de las finanzas sin importar si se refiere a las finanzas tradicionales basadas en activos tradicionales o a las nuevas y brillantes finanzas descentralizadas (también conocidas como DeFi) que se ejecutan en criptoactivos nativos.

El Control de Daños es la Clave

El riesgo de los criptoactivos se compone de riesgos externos, como cambios en la regulación, y riesgos internos, como fallas de diseño y errores de implementación. En Ethereum, el activo nativo es ETH, y los activos no nativos son lo que llamamos tokens ERC, que se refiere a tokens que cumplen con cualquiera de los estándares ERC20 y sus compañeros, como ERC721 y ERC777, etc. El riesgo del activo nativo es menor que el riesgo de un activo no nativo porque este último puede verse afectado tanto por errores propios de Ethereum como por errores de contratos inteligentes. Para los tokens ERC y DeFi, los errores en un contrato inteligente son la mayor preocupación porque DeFi como sistema es una red complicada entretejida a través de contratos inteligentes interminables creados por diferentes desarrolladores de diferentes lugares. Llamamos a los riesgos causados ​​por errores de contratos inteligentes “ Smart contract risks ” (riesgos de contratos inteligentes).

Muchos esfuerzos de investigación se han centrado en las vulnerabilidades de los contratos inteligentes y hemos encontrado muchos métodos de defensa. Si te interesa, aquí tienes un buen estudio . Sin embargo, se sabe comúnmente que eliminar errores en cualquier contrato inteligente no trivial (o simplemente en cualquier programa) es imposible. Vivimos en un mundo lleno de errores de comunicación y aleatoriedad, que causan “distorsión” en cada paso: no podemos convertir la idea en nuestra mente en una especificación precisa y, de manera similar, no podemos convertir una especificación en una implementación perfecta.

Si esta es la cruel realidad, no solo deberíamos considerar defensas proactivas y reactivas en nuestra implementación de criptoactivos, sino también métodos de control de daños que puedan minimizar la pérdida cuando sucede algo malo, para evitar convertir una mariposa en un cisne negro. Hay muchos patrones de diseño que pueden adoptar los contratos inteligentes para el control de daños, el más importante (creo) es la descentralización del estado de la aplicación porque la centralización del estado de la aplicación amplificará el daño causado por los errores de los contratos inteligentes. Permítanme explicar con más detalle lo que quiero decir exactamente con eso.

El riesgo de los tokens ERC

Los estándares de token ERC difieren en la interfaz pero comparten algunas características comunes. El patrón básico de un token ERC es usar un contrato de token para administrar el registro de tokens, y los usuarios interactúan con el contrato de token para emitir, transferir o quemar tokens. Todos los registros del libro mayor ( ledger ) del token se almacenan en el contrato del token, y el contrato en sí es simplemente una cuenta en Ethereum.

Por ejemplo, supongamos que hay un token ERC ‘Copa’, Alice tiene 100 Copas y Bob tiene 50 Copas. El ledger del token es un contrato inteligente de Ethereum ubicado en la dirección/cuenta 0x1234. Este contrato token 0x1234 mantiene una base de datos interna, que almacena registros como “Alice tiene 100 Copas” y “Bob tiene 50 Copas”. Cuando Alice quiere transferir 30 Copas a Bob, envía un mensaje firmado al contrato 0x1234 que dice “transfiera 30 Copas a Bob”, el contrato 0x1234 verificará que el mensaje sea de Alice y modificará su base de datos interna, actualizará los registros correspondientes a “Alice tiene 70 Copas” y “Bob tiene 80 Copas”.

El problema aquí es que toda la lógica y el estado se mantienen en el contrato único 0x1234. Alice y Bob no tienen acceso directo a sus propios registros porque los registros se mantienen bajo la custodia del contrato 0x1234. Todos los usuarios de este token interactúan con este contrato, y la única forma de administrar sus tokens es enviando un mensaje al contrato 0x1234.

En otras palabras, el contrato del token es un punto central . El punto central de cualquier sistema es también el punto de ataque más lucrativo. Cualquier problema con el punto central afecta a todos los usuarios porque todos los tokens/registros los guarda y todos tienen que interactuar con él. Por ejemplo, con las vulnerabilidades “ TransferFlaw ” / “ AllowAnyone ” causadas por un desbordamiento de enteros o la vulnerabilidad “ ItchySwap ” causada por una autorización sin cautela, un atacante puede robar los tokens de otros mientras el propietario no interactúa con el contrato. Con la vulnerabilidad “ OwnerAnyone ”, un atacante puede tomar el control del contrato de token para bloquear los tokens de todos. En todos estos ejemplos una vez que se rompe el contrato del token todos están en problemas.

Un token ERC se mantiene mediante un contrato de token, no por usuarios individuales, y esto es muy diferente de los tokens nativos como Ether (ETH). Los registros de los saldos de ETH no se almacenan mediante ningún contrato inteligente, sino que los usuarios los controlan directamente. Cada propietario de ETH tiene su propia cuenta y registro de saldo. Por ejemplo, si Alice tiene 100 ETH y Bob tiene 50 ETH en la cadena de bloques de Ethereum, Alice tiene un registro de “saldo = 100” en su propia cuenta y Bob tiene un registro de “saldo = 50” en su propia cuenta. El saldo de Alice solo se puede disminuir utilizando su firma, y ​​lo mismo se aplica a la cuenta de Bob. Los registros de propiedad en ETH están descentralizados en múltiples cuentas en lugar de centralizados en una sola cuenta. Mientras sus claves privadas estén seguras, nadie puede robarles ETH. Por el contrario, la interfaz de ataque de un token ERC es más grande porque un atacante siempre puede intentar romper el contrato del token, lo cual es mucho más fácil que romper el protocolo en sí.

Los diferentes riesgos inherentes hacen que los tokens ERC y ETH sean dos clases diferentes de activos. Un contrato inteligente que se ejecuta en una red descentralizada no es lo mismo que la red descentralizada. El problema de la centralización lo presentan nuevamente los tokens ERC en la capa de aplicación, lo que amplifica el daño potencial de cualquier error de contrato inteligente y, desafortunadamente, sabemos que los humanos siempre cometerán errores. Siempre habrá errores. La descentralización de la capa de red/consenso no puede resolver un problema de centralización en la capa de aplicación.

Cómo quitar el amplificador de riesgo

El punto de centralización surge en los tokens ERC porque su estado no es un “first-class citizen” en el modelo de programación de Ethereum. Un fragmento de estado es un archivo adjunto al código, pero no se puede consultar ni comparar directamente. Es natural poner el estado con las mismas reglas de validación (por ejemplo, registros del mismo token) en el mismo contrato, sin embargo, este contrato se convierte en un punto de centralización. Esta es una consecuencia del modelo de programación de Ethereum.

En CKB, el patrón se invierte porque el estado es un “first-class citizen”. El estado es el objeto con el que los usuarios juegan directamente, y el código es un archivo adjunto al estado. Podemos comparar y agrupar estados con las mismas reglas de validación de forma natural, incluso cuando estos estados los tienen directamente diferentes usuarios.

Nos referimos a un token no nativo en CKB como “Token definido por el usuario” o UDT. Para un UDT dado, la definición de activos (código) y los registros de activos (estado) están separados, y los registros de diferentes usuarios (direcciones) también están separados. La definición de activos describe la lógica del token, por ejemplo, “El límite de emisión es 1 millón” o “Bob puede emitir nuevos tokens”, y los registros son información como “Alice tiene 100 tokens”. La definición de activos es un contrato creado por un desarrollador de tokens y almacenado en una celda propiedad del desarrollador (Celda de definición de activos), mientras que los registros se mantienen en las celdas de los usuarios y todos usan el mismo script de “tipo”. Cada usuario usa su propia celda para almacenar sus propios registros de tokens. Éstos comparten las mismas reglas de validación definidas por la celda de definición de activos. Con esta estructura, los registros se almacenan de forma descentralizada.

image

Como muestra la figura anterior, el token de Alice se almacena en la propia celda de Alice y está protegido por su propia secuencia de comandos de bloqueo, que es Secp256k1 de forma predeterminada. Incluso si hay un error en la definición de activos, un atacante no puede modificar el registro de Alice porque para hacerlo requiere la clave privada de Alice. Debido a que Alice tiene el token directamente, no hay forma de que un atacante pueda eludir el candado de Alice. Al descentralizar el estado de un token, se puede controlar el daño de un error en la definición de activos.

Todavía existe la posibilidad de errores que afecten a todos: por ejemplo, podría haber un error en la definición de activos que permita a cualquiera emitir más tokens de los esperados. La ventaja de UDT es, primero, que se elimina una gran parte de los errores; y segundo, la celda de definición de activos está protegida por un candado que puede ser parte de la lógica de autenticación de emisión de tokens, naturalmente. Siempre es fácil utilizar el mecanismo de autenticación proporcionado por el protocolo. Este desacoplamiento de la autorización y la lógica comercial es una buena práctica de ingeniería y es un valor predeterminado en CKB. UDT está más descentralizado que los tokens ERC, por lo que el riesgo de contrato inteligente de UDT es menor que el token ERC pero aún más alto que un token nativo.

Una DAO segura en Nervos

La descentralización del estado de la aplicación también puede ayudar al diseño de la aplicación DeFi. Nervos DAO es la primera aplicación DeFi en CKB. Es un contrato inteligente con el que los usuarios pueden interactuar de la misma manera que cualquier contrato inteligente en CKB. Una función de Nervos DAO es proporcionar una contramedida de dilución para los titulares de CKByte. Al depositar en Nervos DAO, los titulares obtienen recompensas secundarias proporcionales, lo que garantiza que sus tenencias solo se vean afectadas por la emisión primaria con límite máximo como en Bitcoin. Hay más de mil millones de CKBytes depositados en la DAO en el momento de escribir este artículo y el número va en aumento, lo que lo convierte en un contrato muy atractivo para los atacantes. ¿Deberíamos estar preocupados?

Tal vez no tanto, porque los CKBytes bloqueados en Nervos DAO no se agrupan en un solo contrato inteligente, ¡sino que aún están en manos de diferentes usuarios! Cuando un usuario quiere depositar en Nervos DAO, construye la transacción de depósito seleccionando celdas (UTXO de CKBytes) y establece sus scripts de referencias de tipo en 0x82d76d1b75fe2fd9a27dfbaa65a039221a380d76c926f378d3f81cf3e7e13f2e, que apunta al script Nervos DAO . Los scripts de bloqueo no se modifican para esas celdas . Debido a que los scripts de tipo DAO de Nervos están desacoplados de los scripts de bloqueo de los usuarios, un atacante nunca puede gastar esos CKBytes depositados sin el permiso de los usuarios.

Para retirar los CKBytes depositados, se deben proporcionar los testigos (firmas) de los scripts de bloqueo correspondientes. Esta validación está garantizada por la red CKB, no por ningún contrato inteligente, y no hay otra alternativa. El script Nervos DAO está ahí para asegurarse de que el cálculo de la compensación sea correcto en el retiro, no para retener fondos.

El impacto en DeFi

Es difícil analizar cuantitativamente el impacto del riesgo de contrato inteligente en DeFi, pero podemos obtener algunas pistas del producto de seguro proporcionado por Nexus Mutual , que es una ‘alternativa descentralizada al seguro’. Su primer producto, SmartContractCover , permite a un usuario comprar cobertura de seguro en cualquier contrato inteligente para que pueda recibir una compensación si el contrato inteligente es pirateado. La prima de una SmartContractCover está determinada por el mercado, correlacionada positivamente con el período y monto de la cobertura. Según esta publicación, la cobertura de seguro de 1000 DAI en Nuo durante 90 días te costará 6,41 DAI, mientras que la cobertura de seguro de 1 ETH en Uniswap durante 365 días te costará 0,013 ETH. Con base en estos números, podemos llegar a una estimación de que el costo anualizado del riesgo del contrato inteligente es de alrededor del 2%.

El costo del 2% es una ineficiencia del mercado causada por el riesgo de contrato inteligente, y por eso es importante una mejora en el modelo de programación de contrato inteligente. Un modelo de programación diferente puede reducir el riesgo de contratos inteligentes y brindarnos un mercado DeFi más eficiente.

Gracias a Haseeb Qureshi , Cipher Wang , Matt Quinn y Christopher Heymann por sus comentarios sobre el borrador de esta publicación.

1 Like