Comparación con los contratos de solidity

CosmWasm sigue un enfoque diferente al de Ethereum para desplegar y ejecutar contratos inteligentes. Implica tres fases para tener un contrato inteligente en funcionamiento:

1. Subir Código - En este paso, sólo subes un poco de código wasm optimizado. A diferencia de los contratos inteligentes en Ethereum, en este paso, no necesitas preocuparte ni del estado ni de la dirección del contrato.

2. Instanciar Contrato - En este paso, se instancia una referencia de código con un estado inicial y se crea una dirección de contrato.

3. Ejecutar el contrato: una vez que el contrato está activo, puede admitir diferentes llamadas en función del diseño específico del contrato.

De forma similar a Ethereum:

• La instanciación y ejecución de contratos requieren gas.

• Tanto la instanciación como la ejecución permiten al firmante enviar algunos tokens al contrato junto con el mensaje.

A diferencia de Ethereum:

• El envío de tokens directamente a un contrato (es decir, a través de SendMsg) no activa ningún código de contrato. Ya que la ejecución del contrato necesita ser solicitada explícitamente. Esta decisión de diseño de CosmWasm ayuda a reducir posibles vectores de ataque. Por ejemplo, en Ethereum, cuando se transfieren tokens a un contrato, la función fallback del contrato se activa automáticamente. Si esta función fallback no está bien implementada o tiene vulnerabilidades de seguridad, puede dejar el contrato o incluso todo el sistema susceptible a diferentes tipos de ataques, incluyendo ataques de reentrada.

Instanciación de contratos inteligentes

En CosmWasm, la carga del código de un contrato y la instanciación de un contrato se consideran eventos separados (a diferencia de Ethereum). Esto es para permitir que un pequeño conjunto de arquetipos de contrato vetados existan como múltiples instancias que comparten el mismo código base, pero que aún pueden ser configurados con diferentes parámetros.

Un contrato de vesting es un tipo de contrato inteligente que bloquea tokens y los libera gradualmente durante un periodo de tiempo determinado. Mediante el uso de diferentes parámetros durante la instanciación, puede crear múltiples instancias de la misma plantilla de contrato de vesting para adaptarse a diversos casos de uso.

Por ejemplo, si un contrato de adquisición permitiera los siguientes parámetros:

// VestingContract.wasm
{
  "vesting_start_time": "1616678400", // Unix timestamp for vesting start time
  "vesting_duration": "31536000",     // Vesting duration in seconds (1 year)
  "total_tokens": "1000000",          // Total tokens to be vested
  "beneficiary_address": "archway1xyz" // Address of the beneficiary
}

Al instanciar este contrato de adquisición de derechos con diferentes valores de parámetros, puede crear múltiples instancias que se adapten a varios escenarios de adquisición de derechos. Por ejemplo:

Instance A: Employee A receives 1,000,000 tokens vested over three years.
Instance B: Employee B receives 500,000 tokens vested over two years.
Instance C: Advisor A receives 250,000 tokens vested over one year with a six-month cliff.

Utilizando una única plantilla de contrato de adquisición de derechos y personalizando los parámetros durante la instanciación, puede crear contratos de adquisición de derechos únicos para diferentes beneficiarios y condiciones de adquisición de derechos.

Evitar los ataques de reentrada

Los ataques de reentrada se evitan por diseño. Esta es una cuestión importante, ya que un gran número de exploits en Ethereum se basan en ataques de reentrada. Para ilustrar cómo funcionan los ataques de reentrada en los contratos inteligentes de Ethereum, considere el siguiente escenario:

En medio de la ejecución de una función en el contrato A, se realiza una llamada implícita o explícita. Esta llamada transfiere el control de ejecución al contrato B (que ahora puede ejecutar código) y vuelve a llamar al contrato A. Como ahora hay dos copias del Contrato A ejecutándose, necesitas ser extremadamente cuidadoso en cuanto a la gestión del estado antes de ejecutar cualquier contrato remoto (o hacer límites de gas muy estrictos en las sub-llamadas). Los ataques de reentrada pueden desencadenar un comportamiento indefinido en el Contrato A, sentando las bases para exploits (similar al hack del DAO de Ethereum).

Cosmwasm evita completamente los ataques de reentrada impidiendo que cualquier contrato llame directamente a otro. Como queremos permitir la composición y al mismo tiempo evitar las llamadas de funciones en línea a código malicioso, CosmWasm permite que cualquier contrato devuelva una lista de mensajes para ser ejecutados en la misma transacción. Esto significa que un contrato necesita terminar su ejecución antes de poder realizar una llamada a otro contrato. Si los mensajes futuros fallan, entonces toda la transacción se revierte, incluyendo las actualizaciones del estado del contrato. Este enfoque CosmWasm permite la composición atómica.

Limitacion de recursos

Otro vector de ataque para los contratos inteligentes son los ataques de denegación de servicio (DoS). Por ejemplo, un actor malicioso podría cargar un contrato que ejecutara un bucle infinito para detener la cadena o escribir toneladas de datos para llenar las capacidades de almacenamiento. Como Web Assembly proporciona una caja de arena hermética sin acceso predeterminado al sistema operativo, sólo tenemos que preocuparnos de proporcionar límites de recursos estrictos para los contratos inteligentes. Todos los desarrolladores deben ser conscientes de estos límites.

Uso de Memoria - Al instanciar una VM Wasm, se le proporcionan 32MB de RAM por defecto. Esto es para almacenar el código de bytes así como toda la memoria utilizada por el proceso en ejecución (pila y montón). Esto debería ser lo suficientemente grande para casi cualquier contrato, pero tal vez algunos circuitos complejos de conocimiento-cero alcanzarían límites allí. También es lo suficientemente pequeño como para garantizar que los contratos tengan un impacto mínimo en el uso de memoria de la cadena de bloques.

Uso de la CPU - El Wasmer Runtime que utilizamos puede inyectar lógica de medición en el código wasm. Calcula los precios de varias operaciones, cargos, y comprueba los límites antes de cada sentencia de salto (bucle, llamada a función, etc.), para producir un precio de gas determinista independientemente de la velocidad de la CPU, plataforma, etc. Antes de ejecutar un contrato, se establece un límite de gas wasm basado en el gas Cosmos SDK restante, y el gas se deduce al final del contrato (hay un multiplicador constante para convertir, actualmente 100 gas wasm por 1 gas SDK). Esto pone un límite duro en cualquier cálculo de la CPU como usted debe pagar por los ciclos utilizados.

Uso del disco - Todo el acceso al disco es a través de lecturas y escrituras en el KVStore. El SDK de Cosmos ya impone los pagos de gas para el acceso KVStore. Dado que todo el acceso al disco en los contratos se realiza a través de devoluciones de llamada en el SDK, se cobra allí. Si uno fuera a integrar CosmWasm en otro tiempo de ejecución, uno tendría que asegurarse de cobrar por el acceso allí también.

Lecciones aprendidas de Ethereum

Para producir funcionalidades robustas de contratos inteligentes, es útil aprender tanto de los éxitos como de los defectos de Ethereum. Por lo tanto, podemos echar un vistazo a los vectores de ataque más comunes de Ethereum junto con las estrategias de mitigación, para que podamos comparar cuánto de esta lista se aplica a Cosmwasm. Encontrarás que muchos de estos vectores de ataque están cerrados por diseño, mientras que un número permanece, y se planea una sección para evitar los problemas restantes.

1. Reentrada Como ya se ha comentado, en CosmWasm devolvemos mensajes para ejecutar otros contratos en la misma operación atómica, pero después de que el contrato haya terminado su ejecución. Esto se basa en el modelo de actor y evita la posibilidad de ataques de reentrada. Más concretamente, nunca hay un estado volátil cuando se llama a un contrato.

2. Rust te permite simplemente establecer overflow-checks = true en el manifiesto Cargo para abortar el programa si se detecta algún desbordamiento. No hay manera de optar por matemáticas seguras.

3. Llamada Delegada En CosmWasm, no hay lógica de Llamada Delegada. Puede importar módulos, pero están vinculados entre sí en tiempo de compilación, lo que les permite ser probado como un todo, y no hay puntos de entrada sutiles dentro de la lógica de un contrato.

4. Visibilidades por defecto En lugar de autogenerar puntos de entrada para cada función/método de su código (o peor aún, asumir que es público si no se especifica), el desarrollador debe definir claramente una lista de mensajes a tratar y enviarlos a las funciones adecuadas. De esta forma, es imposible exponer accidentalmente una función.

5. Ataque de Dirección/Parámetro Corto Este es un exploit que se aprovecha del mecanismo de codificación RLP y del tamaño fijo de pila de 32 bytes. No se aplica al analizador JSON de comprobación de tipos de CosmWasm.

6. Valores de retorno de CALL no comprobados CosmWasm no permite llamar a otros contratos directamente, pero en su lugar, los mensajes enviados serán despachados por un enrutador. El enrutador comprobará el resultado de todos los mensajes, y si algún mensaje en la cadena devuelve un error, se aborta toda la transacción, y se retroceden los cambios de estado. Esto te permite centrarte de forma segura en el caso de éxito cuando programes llamadas a otros contratos, sabiendo que todos los estados se revertirán si no va según lo planeado.

7. Punteros de almacenamiento no inicializados CosmWasm no rellena automáticamente las variables, ya que debes cargarlas explícitamente desde el almacenamiento. Rust no permite variables no inicializadas en ninguna parte, haciendo el almacenamiento explícito en lugar de implícito.

8. Puntos flotantes y precisión Tanto Solidity como CosmWasm no admiten operaciones de punto flotante debido al posible no determinismo en el redondeo, que depende de la CPU. Solidity no tiene alternativa a las operaciones matemáticas con números enteros, y muchos desarrolladores hacen a mano aproximaciones de números enteros a números decimales, lo que puede introducir errores de redondeo. En CosmWasm, puede importar cualquier paquete de Rust y simplemente elegir un paquete apropiado y utilizarlo internamente. Por ejemplo, puedes utilizar rust_decimal, "una implementación de Decimal escrita en Rust puro adecuada para cálculos financieros que requieren dígitos integrales y fraccionarios significativos sin errores de redondeo", o debe ser fijo para proporcionar matemáticas decimales de punto fijo. Soporta números de hasta 128 bits, lo que es suficiente para 18 dígitos antes del decimal y 18 después, lo que debería ser suficiente para cualquier caso de uso.

9. Autenticación Tx.Origin CosmWasm no expone tx.origin, sino sólo el contrato o el usuario que llama directamente al contrato como params.message.signer. Esto significa que es imposible confiar en la autenticación incorrecta, ya que sólo hay un valor para comparar.