Día 3: Mi primer Solana Program
Conoce Anchor y la manera en la que construímos programas usando este framework.
En este día vamos a dar el salto de “entender Solana” a construir en Solana: escribirás tu primer programa on-chain y verás cómo se conecta con una wallet y con transacciones reales en la red. El objetivo es que entiendas el flujo completo (código → despliegue → interacción), y que empieces a familiarizarte con dos piezas fundamentales del desarrollo en Solana: Anchor (el framework más usado) y el modelo de cuentas (dónde vive el estado y cómo lo manipulan los programas).
Anchor
Anchor es un framework para construir programas en Solana que simplifica el desarrollo con una combinación de macros en Rust, herramientas de proyecto y clientes para interactuar con el programa (por ejemplo desde TypeScript). Su idea central es reducir el “boilerplate” que normalmente escribirías en Rust nativo y, al mismo tiempo, ayudarte a aplicar checks de seguridad comunes de forma más consistente.
En otras palabras: Anchor te permite enfocarte más en la lógica de tu aplicación y menos en el código repetitivo que necesitas para que un programa sea correcto y seguro en Solana.
¿Por qué usar Anchor en vez de Rust “puro”?
Solana se puede programar en Rust sin frameworks (lo que normalmente se llama “native Rust”). Ese enfoque te da control total, pero también implica escribir y mantener mucho código repetitivo: serialización/deserialización, validación de cuentas, manejo de errores y patrones estándar del runtime.
Anchor suele preferirse (especialmente en un bootcamp) porque:
Acelera el desarrollo: te da una estructura estándar de proyecto y reduce código repetitivo.
Mejora la experiencia del desarrollador: la forma de definir instrucciones y cuentas es más clara y consistente.
Facilita la interacción desde el cliente: genera una IDL que hace más fácil construir un cliente (por ejemplo en TypeScript) para llamar instrucciones con menos fricción.
Anchor no “reemplaza” Rust; Anchor es Rust, pero con herramientas y convenciones que te ayudan a construir más rápido y con menos errores.
Estructura típica de un programa en Anchor
Un proyecto de Anchor suele tener una estructura que separa el programa on-chain de las pruebas y scripts del lado cliente. A alto nivel, verás componentes como:
programs/: aquí vive el programa on-chain en Rust (el “smart contract”).lib.rs(dentro del programa): define el módulo principal del programa, sus instrucciones y la lógica.#[program]: macro donde se definen las funciones/instrucciones públicas del programa.#[derive(Accounts)]: estructuras que declaran qué cuentas requiere cada instrucción (y qué reglas deben cumplir).Anchor.toml: configuración del workspace (clusters, program IDs, providers, etc.).tests/: pruebas (usualmente TypeScript) para desplegar e invocar el programa en un entorno de desarrollo.
La gran idea detrás de esta estructura es que cada instrucción quede definida con:
la lógica (qué hace), y
los requisitos de cuentas (con qué cuentas puede operar y bajo qué condiciones), manteniendo el programa más legible y fácil de auditar.
Modelo de cuentas en Solana
En Solana, los programas (contratos inteligentes) no guardan su estado como “variables globales” dentro del contrato, como suele imaginarse en otras plataformas. En lugar de eso, el estado vive en cuentas (accounts) separadas, y los programas operan sobre esas cuentas cuando reciben una transacción. Esta idea es clave: cuando llamas a un programa, debes indicarle explícitamente qué cuentas va a leer o escribir, y bajo qué permisos.
Una analogía útil: el programa es como una función/servicio “sin estado” que sabe cómo procesar datos, y las accounts son como los “registros/archivos” donde están los datos persistentes. El programa no “posee” esos datos: los recibe como entrada (en forma de cuentas) y los actualiza si tiene permiso.
¿Entonces, qué es un Account?
Un Account en Solana es un contenedor en la blockchain que puede almacenar:
lamports (la unidad mínima de SOL),
datos (data) en bytes (tu estado),
un owner (quién controla/modifica esa cuenta),
y metadatos como si es executable (si es un programa).
Lo más importante del owner:
Si una cuenta tiene como owner a un programa (por su Program ID), entonces ese programa es quien puede modificar los datos de esa cuenta (bajo las reglas del runtime).
Tu wallet puede firmar, pero eso no significa que pueda escribir en cualquier cuenta: solo el owner (programa dueño) tiene autoridad para mutar datos.
Almacenamiento: quién lo paga y el rol del payer
Crear una cuenta con espacio para datos cuesta SOL, porque estás reservando almacenamiento en la blockchain. En Solana, ese costo lo cubre un payer (pagador), que normalmente es el usuario que inicializa el estado.
En Anchor, cuando ves algo como “init” (inicializar), suele existir un payer = ... que indica qué cuenta va a pagar:
la creación de la cuenta,
y el mínimo necesario para que sea rent-exempt (o cumpla las reglas actuales de renta/almacenamiento).
El payer paga la cuenta, pero el owner de los datos suele ser tu programa (para que tu programa pueda modificar ese estado).
Space: tamaño y “espacio” básico
Como los datos en una cuenta son bytes, cuando creas una cuenta debes definir su tamaño (space). Esto es como decir: “resérvame X bytes para mi estado”.
En Anchor, space suele calcularse como:
un overhead fijo (Anchor agrega un discriminador),
el tamaño de tu struct (campos, strings, vectores, etc.).
La idea práctica es simple:
Si
spacees muy pequeño, tu programa fallará al intentar guardar datos.Si
spacees muy grande, pagarás más SOL del necesario al crear la cuenta.
En el bootcamp lo vamos a manejar con ejemplos concretos, pero desde el inicio es importante entender que el estado en Solana no crece mágicamente: el tamaño se decide al crear la cuenta.
Last updated