Back

Tu primer vistazo a Solana

El 18 de agosto de 2026 di la Sesión 1 del bootcamp de La Familia: la charla de apertura, pensada para una sala mixta de gente técnica y no técnica que nunca había tocado Solana. Esto es una versión escrita de esa sesión, sin las notas de ensayo que uso yo para prepararla, solo lo que le sirve a quien no estuvo ahí o quiere repasarlo.

Qué es una blockchain

La definición corta que uso: una base de datos compartida que no es de nadie, y que cualquiera puede verificar.

Una base de datos normal, la de un banco, la de Instagram, vive en los servidores de una empresa. Esa empresa puede cambiar los datos, borrarlos o negarte acceso. Una blockchain guarda información igual, pero la guarda replicada en miles de computadoras independientes, los validadores, ninguna de las cuales tiene más autoridad que las demás.

Las transacciones se agrupan en bloques, y cada bloque guarda el hash del bloque anterior. Si alguien altera un bloque del pasado, su hash cambia, y todos los bloques que vienen después dejan de encajar. Los anteriores no se ven afectados, solo lo que viene después. Por eso se llama block-chain: el pasado queda sellado.

Y esa cadena no la guarda un solo servidor, la guardan miles de validadores en paralelo. Una copia alterada no coincide con las demás y la red la rechaza. Mentir exige alterar miles de copias a la vez y que nadie lo note. Verificar, en cambio, lo puede hacer cualquiera, gratis, en cualquier momento.

Eso deja una pregunta abierta: si no hay un dueño único, ¿quién decide qué es verdad? Vuelvo a esto más abajo.

Por qué Solana

Solana apunta a tres cosas que se refuerzan entre sí: un bloque nuevo cada ~400 milisegundos, comisiones de fracciones de centavo, y ejecución en paralelo.

Los números en sí no son el punto. El punto es lo que desbloquean: cuando mover valor no cuesta casi nada y confirma casi al instante, se vuelven posibles pagos cotidianos, micropagos y aplicaciones de consumo masivo, cosas que en cadenas más lentas y caras simplemente no tienen sentido de negocio.

Wallets y claves

El malentendido más común: pensar que la wallet "contiene" tus criptomonedas.

En realidad, los activos viven en la blockchain, no en la wallet. La wallet guarda claves: un par compuesto por una clave pública (tu dirección) y una clave privada (la que firma). Poseer la clave privada correcta es, matemáticamente, lo único que demuestra que esos activos son tuyos.

La seed phrase (12 o 24 palabras) genera ese par de claves de forma determinística. Quien la tiene puede regenerar las mismas claves en cualquier otro dispositivo. No es una contraseña más, es el origen matemático de tus claves.

Accounts: todo es una cuenta

Esta es la pieza central del modelo mental de Solana. En vez de tener distintos tipos de estructuras para distintas cosas, Solana usa un solo concepto: la cuenta. Tu saldo es una cuenta. Cada token que tienes vive en su propia cuenta. Un programa desplegado es una cuenta ejecutable. Los datos que produce ese programa también viven en cuentas.

Piénsalo como un sistema de archivos gigante y compartido: cada cuenta es como un archivo, con una dirección, un contenido y un dueño.

El contraste importante con otras blockchains: en Solana el código y los datos viven separados. Un programa no guarda estado propio, es stateless. Cuando lo invocas, le pasas explícitamente las cuentas sobre las que debe actuar.

Si te llevas una sola idea técnica de esta charla: todo es una cuenta.

Transactions e instructions

Una transacción es un paquete de instrucciones. Cada instrucción dice tres cosas: qué programa invocar, qué cuentas necesita tocar, y qué datos le estás pasando.

Y aquí está el "ajá" de la sesión: como cada transacción declara por adelantado exactamente qué cuentas va a tocar, la red puede saber de antemano cuáles chocan entre sí y cuáles no, antes de ejecutar nada. La regla, en cuatro casos:

  • Dos transacciones que escriben la misma cuenta: chocan.
  • Una que escribe y otra que solo lee la misma cuenta: chocan.
  • Dos que solo leen la misma cuenta: no chocan, corren en paralelo.
  • Dos que no comparten ninguna cuenta: nunca chocan.

Cuentas declaradas por adelantado, la red sabe qué no choca, lo que no choca corre en paralelo. Esa cadena causal es lo que hace que Solana sea rápida incluso bajo mucha carga.

Consenso: quién decide qué es verdad

Esta es la pregunta que quedó pendiente arriba. Solana usa Proof of Stake. Stake significa, literalmente, lo que pones en juego. Un validador deposita SOL como garantía, y participar demuestra que tienes algo que perder, en vez de gastar electricidad como en Proof of Work.

Cómo funciona, en cuatro pasos:

  1. Un validador deposita SOL, su stake.
  2. Al inicio de cada epoch (~432.000 slots, ~2 días), la red calcula el leader schedule: qué validador propone el bloque en cada slot, proporcional a su stake.
  3. Cuando le toca su turno, el validador líder propone el siguiente bloque.
  4. Los demás validadores lo verifican y votan, con un peso proporcional a su stake. Se necesita una súper-mayoría para confirmar el bloque.

El stake no decide "quién verifica primero", no es una carrera. Decide dos cosas: qué tan seguido te toca proponer, y cuánto pesa tu voto al confirmar. Y al no depender de minería, el gasto energético de participar es bajo.

El reloj de Solana: Proof of History

Verificar y votar es relativamente rápido. Lo genuinamente difícil en cualquier red distribuida es ponerse de acuerdo en el orden exacto de los eventos, porque cada nodo tiene su propio reloj y ninguno confía ciegamente en el de los demás. Ahí es donde entra Proof of History.

El truco: una cadena continua de hashes SHA-256, donde cada hash se calcula sobre el anterior. Producirla solo se puede hacer en secuencia, no hay atajo. Y esa secuencialidad es justo lo que la vuelve útil como reloj: si algo se registra en el hash número 1.000, y otra cosa en el número 2.000, cualquiera puede verificar matemáticamente que lo primero ocurrió antes, porque llegar al 2.000 exigió pasar primero por el 1.000.

Un reloj criptográfico no dice qué hora es. Demuestra cuánto tiempo pasó.

Un slot dura ~400 ms y tiene un líder asignado. Un epoch son 432.000 slots, ~2 días, y al terminar se recalcula el leader schedule. Los programas leen la hora on-chain con el sysvar Clock.

Programs

Los smart contracts de Solana se escriben en Rust, y Anchor los hace manejables. Se despliegan como cuentas ejecutables y, como ya vimos, no guardan estado propio: actúan sobre las cuentas que les pasas.

La demo: desplegar un contador real

Para cerrar la parte técnica, desplegué en vivo un contador mínimo (~20 líneas), con dos instrucciones: initialize crea la cuenta que guarda el número, increment le suma uno. Tres cosas del código, cada una conectada a un concepto de arriba: declare_id! (el programa también es una cuenta), el struct del contador (el estado vive en cuentas, no en el programa), y increment (recibe las cuentas y actúa sobre ellas).

$ anchor deploy --provider.cluster devnet

Deploying cluster: https://api.devnet.solana.com
Deploying program "solana-counter-demo"...
Program Id: 7duj3z3rarbiKXLUG75XMi1mzVB28kyeuy3G1KAE6Rtw

Deploy success

Existe, es público, cualquiera lo puede ver en el Solana Explorer. El repo completo está en github.com/cxalem/solana-counter-demo.

La tarea

Le puse una condición a la tarea de esta sesión: solo cuenta si se publica en X. El post es la entrega, no el código en sí.

Nivel 1, para todos, incluidos los no técnicos: Solana Playground en el navegador, con wallet y airdrop de devnet integrados, sin instalar nada. Se despliega el mismo contador de la demo. Prueba: una captura del program ID en el Explorer, más una línea sobre qué hace. 20 a 30 minutos.

Nivel 2, para quienes quieren más: reproducir la demo en su máquina. Clonar el repo o correr npx create-solana-dapp, instalar la toolchain, y desplegar desde su propia terminal con anchor deploy. Prueba: repo en GitHub más el program ID.

Alternativa no técnica: un post explicando con sus propias palabras uno de los conceptos de la charla.

El post puede ser en español o en inglés, lo que prefieran. Y en vez de un hashtag, les pedí que me mencionaran directo: @_cxalem.

Recursos

Cierre

tx-indexer, un paquete que hoy tiene más de 1.100 descargas al mes, empezó como un post explicando lo que había aprendido construyéndolo. La tarea de hoy es la misma jugada: un deploy y un post. El código que escriban esta semana ya es portfolio, si lo ponen donde la gente pueda verlo.