Puntos clave
- Un canister reúne código, estado y una identidad dentro de la red.
- Los cycles cubren recursos de ejecución y deben monitorizarse como parte de la operación.
- Las actualizaciones y llamadas entre canisters requieren un diseño explícito del estado.
¿Qué es Internet Computer?
Internet Computer amplía el uso de contratos hacia aplicaciones que conservan lógica y datos en canisters. Cada canister tiene una identidad y un programa que expone métodos para interactuar con su estado. El desarrollo puede utilizar lenguajes como Motoko o Rust.
Para un producto, el alcance depende de qué partes del backend deben ejecutarse en la red. Esa decisión se toma por requisitos de verificación, control y disponibilidad. Mantener toda la aplicación on-chain no es un objetivo por sí mismo si añade complejidad sin una necesidad concreta.
Cómo funciona
Los canisters ejecutan código WebAssembly y se comunican mediante mensajes. La aplicación distingue operaciones de lectura y actualizaciones de estado, así como llamadas que atraviesan varios componentes. Su consumo de recursos se financia con cycles.
El diseño debe contemplar la persistencia durante una actualización, los permisos de administración y el comportamiento ante respuestas tardías o errores de otros canisters. Un flujo distribuido no equivale a una única operación de base de datos. Conviene modelar cada etapa y sus compensaciones antes de convertir el backend en varios servicios on-chain.
Un canister conserva estado y expone métodos que pueden consultar o modificarlo. Las llamadas de actualización pasan por el protocolo de consenso; las consultas tienen un recorrido distinto y su verificación debe diseñarse según el dato servido. Las comunicaciones entre canisters introducen puntos de espera y posibles errores que la aplicación debe manejar explícitamente.
Qué aporta Internet Computer
Internet Computer puede encajar cuando un producto necesita que determinadas reglas y datos se ejecuten dentro de una infraestructura blockchain. Permite evaluar registros compartidos, servicios programables y aplicaciones con componentes que deben poder verificarse fuera de un servidor convencional.
En Metlabs, la evaluación delimita qué código va al canister y qué sistemas externos permanecen. Después se prueban autenticación, consumo de recursos y recuperación de estado. El presupuesto de operación incluye ciclos de actualización y monitorización del saldo de cycles, no solo la escritura inicial del programa.
Una aplicación documental puede guardar su lógica y servir parte de su interfaz desde canisters. El plan operativo incluye saldo de cycles para financiar recursos, controles sobre quienes pueden actualizar el código y preservación del estado durante una actualización. También se prueba cómo continúa una operación si falla una llamada entre componentes. Integrar datos o activos externos no elimina esas dependencias, aunque el núcleo de la aplicación se ejecute en la red.
Limitaciones y criterios de elección
El modelo exige conocimientos distintos de un backend tradicional o de una dApp Solidity. Las llamadas entre componentes, la gestión de memoria y las actualizaciones necesitan pruebas específicas. También importa quién controla un canister y bajo qué condiciones puede modificarlo.
Una aplicación convencional con evidencias registradas en otra red puede ser más sencilla si solo necesita verificar algunos hitos. La comparación debe partir de qué garantías exige el producto. Trasladar computación a la red sin justificar esas garantías puede aumentar el coste de mantenimiento sin resolver un problema adicional.
También conocido como
- ICP
