Día 4: Despliegue e interacción con Solana
Aplica todos los conocimientos adquiridos durante el programa y despliega un programa a la red de Solana.
En este día conectamos todo lo anterior en un flujo “de vida real”: tomar un programa que ya funciona en desarrollo, desplegarlo en una red de Solana y comenzar a interactuar con él como lo haría una aplicación (cliente) real. Además, reforzaremos conceptos que se vuelven críticos cuando algo vive “en cadena”: cómo se comporta un programa desplegado, cómo se modela y almacena el estado (datos), y qué consideraciones básicas de costos y seguridad debes tener presentes desde el inicio.
Desplegar un programa: ¿qué pasa cuando hacemos anchor deploy?
anchor deploy?Cuando ejecutas anchor deploy, Anchor automatiza varios pasos para publicar tu programa en la red. A alto nivel, ocurre lo siguiente:
Compilación: tu código Rust se compila al formato que Solana ejecuta on-chain (BPF/SBF).
Publicación en la red: el binario compilado se sube a la blockchain y queda asociado a un Program ID.
Registro como “executable”: el Program ID representa una cuenta especial marcada como ejecutable; a partir de ese momento, cualquier transacción puede invocar ese programa (siempre que envíe las cuentas requeridas).
Interacción vía transacciones: ya desplegado, tu programa no “corre todo el tiempo” como un servidor; solo se ejecuta cuando una transacción lo invoca con instrucciones, cuentas y firmas válidas.
Desplegar un programa es como publicar una “lógica” a la que cualquiera puede llamar, pero cada ejecución depende de una transacción que trae los datos y permisos correctos. El programa es determinístico: con el mismo input, debe producir el mismo resultado.
Modelo de datos: space, rent-exemption y costos básicos
En Solana, el estado de tu aplicación vive en cuentas (accounts), no como variables globales dentro del programa. Cuando quieres guardar datos, normalmente creas una cuenta de estado y defines cuánto espacio necesita. Por eso, el modelado de datos en Solana empieza con una pregunta muy concreta:
¿Cuántos bytes necesita mi estado para funcionar?
space en Anchor: por qué importa
space en Anchor: por qué importaEn Anchor, al inicializar una cuenta (por ejemplo con init), debes especificar el space, que es el tamaño reservado para almacenar los datos. Si asignas menos bytes de los necesarios, tu programa fallará cuando intente serializar o escribir datos. Si asignas demasiado, estarás pagando más SOL de lo necesario al crear la cuenta.
El tamaño de una cuenta se decide al momento de creación; el almacenamiento no crece dinámicamente “gratis”. Por eso space es parte del diseño, no un detalle de implementación
Rent-exemption (cuentas “rent-exempt”)
Crear una cuenta con datos cuesta SOL porque estás reservando almacenamiento en la blockchain. Históricamente Solana introdujo el concepto de “rent” para cuentas, y en la práctica lo más común es crear cuentas con el mínimo necesario para que sean rent-exempt, es decir, que cumplan el requisito de balance mínimo para mantenerse activas sin penalizaciones.
En Anchor, esto suele manejarse automáticamente al inicializar cuentas: el payer paga el costo de creación + el mínimo requerido según el tamaño (space).
Fees y transacciones
En Solana, cada interacción con tu programa sucede dentro de una transacción, y las transacciones tienen una comisión (fee). A nivel conceptual:
Fee: costo por procesar la transacción (ejecutar instrucciones, verificar firmas, etc.).
Costo de almacenamiento: costo adicional cuando creas cuentas (porque reservas espacio on-chain).
Esto contrasta con redes donde “gas” es la metáfora dominante: en muchas blockchains, el costo se expresa como gas consumido por cómputo + almacenamiento, con variaciones fuertes según congestión. En Solana, aunque el costo depende del tipo de transacción y recursos, el modelo para el usuario suele sentirse como: comisión baja por transacción + costo al crear/almacenar cuentas.
Para desarrollo, lo importante es entender que hay dos “tipos” de costos:
ejecución (fees por transacción)
persistencia (SOL para crear cuentas con espacio)
PDA (Program Derived Addresses)
En Solana, muchas veces necesitas que “el programa sea dueño” de una cuenta de estado o de fondos, pero sin que exista una clave privada humana que controle esa cuenta. Para eso existen las Program Derived Addresses (PDAs): direcciones que se generan de forma determinística a partir de semillas (seeds) + el Program ID, y que están diseñadas para no tener clave privada.
La idea es poderosa: un PDA puede representar una cuenta “controlada por el programa” (por ejemplo, el perfil de un usuario, una bóveda/tesorería, un registro global o un estado de juego). Nadie puede firmar como ese PDA, porque no existe una llave privada correspondiente; en cambio, el programa puede autorizar acciones sobre ese PDA cuando se invoca correctamente, validando las seeds y usando el mecanismo de firma del runtime (invoke_signed). Esto mejora seguridad y diseño, porque evita depender de llaves privadas “custodiadas” por alguien y permite construir lógica de propiedad y permisos completamente on-chain.
En Anchor, los PDAs se vuelven muy prácticos porque puedes declararlos en tus structs de cuentas con seeds y bump, y Anchor valida automáticamente que la cuenta recibida corresponde al PDA esperado. Eso reduce errores comunes (como recibir una cuenta incorrecta) y hace más explícito el modelo de datos y permisos.
Seguridad básica (Anchor + Solana)
A continuación tienes un checklist corto (pero muy útil) de prácticas de seguridad que aplican desde el primer programa:
1) Valida siempre las cuentas que recibes
En Solana, el cliente envía qué cuentas participan en la instrucción. Eso significa que si no validas, alguien puede intentar pasar cuentas inesperadas (por ejemplo, una cuenta de estado que no corresponde, o una cuenta de token distinta).
En Anchor, usa constraints para expresar estas reglas de forma explícita: has_one, constraint = ..., seeds, bump, etc. (anchor-lang.com)
2) Usa Signer cuando la acción lo requiera
Signer cuando la acción lo requieraSi una acción necesita autorización del usuario (crear, actualizar, transferir, cerrar cuentas), asegúrate de requerir un Signer. Esto evita que cualquiera ejecute acciones “en nombre de otro” sin firma. (anchor-lang.com)
3) Usa PDAs para estado y control “sin llave privada”
Para estados importantes (perfiles, vaults, registros), prefiere PDAs: te ayudan a evitar custodias riesgosas y hacen que el control esté en la lógica del programa. Además, con seeds puedes “namespacar” estados por usuario, por tipo de cuenta, etc.
4) Define correctamente owner y evita escribir en cuentas que no te pertenecen
owner y evita escribir en cuentas que no te pertenecenRegla general: un programa solo debe modificar datos de cuentas de las que es owner (o cuentas que su instrucción controla explícitamente). En Anchor, esto se vuelve más simple porque las cuentas Account<'info, T> suelen asumir ownership correcto, pero igual es importante entender qué estás recibiendo.
5) Cuidado con “authority” y permisos
Muchos diseños incluyen un campo authority (quién puede actualizar). Asegúrate de:
guardar y validar esa autoridad,
y no permitir cambios de autoridad sin firma/verificación.
Este patrón aparece en tokens, vaults, perfiles, etc.
6) Controla el tamaño (space) y evita writes fuera de lo esperado
space) y evita writes fuera de lo esperadoErrores de tamaño o serialización pueden romper tu programa o abrir puertas a estados inconsistentes. space no es un detalle: es parte de la seguridad y confiabilidad del estado. (anchor-lang.com)
7) Evita “trust” implícito en datos del cliente
El cliente puede mentir. Todo dato crítico debe:
validarse on-chain,
o derivarse de cuentas/estado verificado (por ejemplo, PDAs o campos guardados en cuentas owner del programa).
Last updated