Cairo

Cairo permite expresar una computación y generar evidencia criptográfica de que se ha ejecutado de acuerdo con unas reglas. En Starknet se utiliza para definir contratos, almacenar estado y procesar operaciones que después se incluyen en el sistema de pruebas de la red. El programa y la infraestructura que produce la prueba cumplen funciones distintas.

Para una empresa, esa separación permite evaluar qué trabajo necesita ejecutar cada participante y qué resultado debe comprobar. Un cálculo verificable puede ser útil aunque no sea un contrato financiero. La viabilidad depende también del coste de producir la prueba, del tratamiento de los datos y de la integración con el sistema que recibe el resultado.

Cairo no convierte automáticamente una aplicación en privada. Si los datos o las transacciones son públicos, una prueba de ejecución correcta no los oculta. Los requisitos de confidencialidad se diseñan y verifican por separado.

En el desarrollo de contratos de Starknet, el código Cairo pasa por Sierra, una representación intermedia, y después por CASM. La ejecución produce información que utiliza el sistema de pruebas. Scarb organiza dependencias y compilación, mientras Starknet Foundry permite comprobar el comportamiento de contratos y sus interacciones.

Un despliegue distingue la declaración de una clase de contrato de la creación de una instancia. Esta distinción importa al registrar versiones, reproducir compilaciones y verificar qué código está utilizando una dirección. La aplicación también necesita un cliente que gestione cuentas, firmas, recursos y estados de las transacciones.

Starknet sí tiene un modelo de gas y comisiones. Intervienen recursos de ejecución y costes asociados a Ethereum; no basta con contar pasos de una traza ni asumir un precio constante. Para presupuestar una operación se simula el flujo concreto y se revisan los parámetros de la versión de protocolo utilizada.

Cairo aporta un modelo de ejecución verificable y un entorno de contratos diseñado para Starknet. Puede encajar cuando el producto necesita esa red, sus aplicaciones o sus cuentas programables, y el equipo puede asumir un stack diferente al de EVM. La elección se justifica por los requisitos del producto, no por incorporar pruebas criptográficas como una etiqueta.

Un ejemplo es una aplicación que agrupa varias acciones de usuario bajo una cuenta con permisos limitados. El diseño debe concretar qué contratos puede invocar esa cuenta, durante cuánto tiempo y con qué capacidad de gasto. Después se comprueban revocación, expiración y comportamiento ante una operación que falla.

En una evaluación técnica conviene construir un recorrido completo con el mismo tipo de cuenta y wallet previsto para producción. Así se mide la experiencia real de firma y confirmación, además del funcionamiento aislado del contrato.

Cairo requiere aprender estructuras de datos, serialización y convenciones propias. Reutilizar la lógica de un contrato Solidity suele exigir rediseñar su implementación y repetir las pruebas. También cambia el conjunto de librerías, herramientas de análisis e integraciones disponibles para el equipo.

Una prueba de validez demuestra que la ejecución respeta el programa, pero un programa puede contener reglas de negocio incorrectas. Por eso siguen siendo necesarias las pruebas de permisos, invariantes económicas y tratamiento de entradas inesperadas. Tampoco se debe equiparar la seguridad de un rollup con la de Ethereum sin revisar sus mecanismos de actualización, disponibilidad y salida.

Antes de elegir Cairo, el proyecto debe acreditar capacidad para mantener el compilador, las dependencias y las integraciones de Starknet. Si necesita desplegar el mismo producto en varias redes EVM, Solidity puede reducir el trabajo de adaptación. Si el objetivo es confidencialidad, hay que definir primero qué información debe permanecer oculta y frente a quién.