La Rampa del Modelo Mental de Solana
Los nuevos desarrolladores de Solana aprenden más rápido con un orden de conceptos fijo: cuentas antes que instrucciones, instrucciones antes que transacciones, luego PDAs, CPIs y presupuestos de cómputo en Agave 4.1.1. Esta página es la secuencia de lectura y ejercicios antes de escribir código de producción en Anchor 0.32.1.
Receta
Tarjeta de referencia rápida - lista para copiar y pegar.
1. Cuentas + propietarios
2. Programas (ejecutables sin estado)
3. Instrucciones + firmantes
4. Transacciones + blockhashes
5. PDAs + semillas + bumps
6. CPIs + validación de cuentas
7. Unidades de cómputo + tarifas de prioridad
8. Clientes (@solana/kit 7.0.0 / CLI)
Cuándo recurrir a esto:
- Primera semana de incorporación antes del trabajo en funcionalidades.
- Contrataciones de EVM o Cosmos que cambian modelos de ejecución.
- Ingenieros de frontend que leerán las IDLs de los programas.
- PMs que necesitan vocabulario preciso para las especificaciones.
Ejemplo de Trabajo
# Secuencia de ejercicios en devnet (Solana CLI 3.0.10)
# 1) Ver una cuenta
solana account 11111111111111111111111111111111
# 2) Transferir SOL (instrucción + firmante)
solana transfer <RECIPIENT> 0.01 --allow-unfunded-recipient
# 3) Inspeccionar instrucciones de transacción
solana confirm -v <SIGNATURE>
# 4) Encontrar un PDA de las semillas de tu programa (Anchor registra en el despliegue de devnet)
anchor deploy && anchor run testLo que esto demuestra:
- La CLI hace que las cuentas y las instrucciones sean tangibles antes de la sintaxis de Rust.
confirmdetallado muestra IDs de programa y metadatos de cuenta.- Las pruebas de Anchor ejercitan PDAs y CPIs sin empaquetado manual.
- Los errores en Devnet son baratos; úsalos mientras aprendes.
Profundización
Etapa 1 - Cuentas y Propiedad
- Todo lo persistente es una cuenta (lamports + bytes + propietario).
- Los programas son cuentas ejecutables pero mantienen un estado mínimo en la propia cuenta del programa.
- Solo el programa propietario puede escribir los datos de una cuenta (salvo excepciones a nivel de sistema).
Etapa 2 - Instrucciones y Transacciones
- Una instrucción nombra un programa, una lista de cuentas y una carga de datos opaca.
- Una transacción ejecuta atómicamente una o más instrucciones con un blockhash reciente.
- Los firmantes autorizan el pago de tarifas y las mutaciones privilegiadas de cuentas.
Etapa 3 - PDAs
- Las Direcciones Derivadas de Programas (PDAs) no tienen clave privada; los programas firman a través de semillas + bump.
- Las semillas están separadas por dominio; las colisiones son inviables con una construcción correcta.
- Almacena el bump canónico en la cadena para evitar la búsqueda de bump en tiempo de ejecución (costo de CU).
Etapa 4 - CPIs
- La Invocación entre Programas (CPI) permite que tu programa llame a SPL Token, System u otros programas de terceros.
- Debes pasar cada cuenta que el llamado espera; el runtime no infiere.
- La recurrencia y la escalada de privilegios son áreas de enfoque de revisión.
Etapa 5 - Economía del Runtime
- Las unidades de cómputo (CU) miden la ejecución; exceder el presupuesto falla la transacción.
- Las tarifas de prioridad influyen en la programación durante la congestión.
- Los saldos mínimos exentos de alquiler determinan los costos de creación de cuentas.
Tabla de Ruta de Aprendizaje
| Día | Concepto | Ejercicio | Enlace a Documentación |
|---|---|---|---|
| 1 | Cuentas | solana account | Solana Basics |
| 2 | Instrucciones | Transferencia CLI | Transactions Basics |
| 3 | Cuentas de Anchor | #[derive(Accounts)] | Accounts struct |
| 4 | PDAs | Restricción seeds | PDAs section |
| 5 | CPI | anchor_spl::token | CPI Anchor |
| 6 | CU/tarifas | ix de simulación + presupuesto | Priority fees |
| 7 | Cliente | Lectura/escritura de kit | kit Basics |
Trampas Comunes
- Pensar que los contratos almacenan datos - EVM se mapea mal. Solución: repite "el estado vive en las cuentas".
- Omitir reglas de firmantes - conduce a exploits en mainnet. Solución: diagrama los firmantes por instrucción al principio.
- PDA como persona - los PDAs son direcciones, no billeteras con claves. Solución: practica
invoke_signed. - Ignorar las CU hasta producción - sorpresas cerca del lanzamiento. Solución: simula las CU en las pruebas de la primera semana.
- Aprender clientes antes que cuentas - errores confusos. Solución: sigue estrictamente el orden de la rampa.
Alternativas
| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| Saltar al tutorial de Anchor | Desarrollador impaciente con un compañero | Auto-servicio sin revisión |
| Solo documento de comparación EVM | Solidity experimentado | Ruta de aprendizaje principal |
| Curso solo en video | Suplemento | Único material de incorporación |
| "Aprender haciendo" en Mainnet | Nunca | Incorporación |
Preguntas Frecuentes
¿Cuánto tiempo por etapa?
Medio día por fila en la tabla para la mayoría de los ingenieros.
¿Anchor antes que nativo?
Sí, para la rampa - Anchor revela PDAs/CPIs con protecciones.
¿Profundidad para desarrolladores frontend?
Etapas 1-2 y 5-6 en profundidad; 3-4 conceptualmente con ejemplos de IDL.
¿Examen?
El compañero pregunta: ¿quién firma, quién paga el alquiler, dónde se almacena el estado?
¿Cambios en Alpenglow?
El modelo mental para cuentas/programas se mantiene; la documentación de confirmación evoluciona por separado.
¿Enfoque en tokens?
Añadir un día de SPL Token después de la etapa 2 si el producto es DeFi/NFT.
¿Local vs. devnet?
Local para bucles rápidos; devnet para tarifas realistas y comportamiento de RPC.
¿Rol de LiteSVM?
Reforzar las etapas 3-5 con pruebas unitarias en Rust.
¿Bloqueadores comunes?
El borrow checker y los tiempos de vida de las cuentas - emparejar con una hora de compañero de Rust.
¿Después de la rampa?
Continuar con el proyecto guiado Primer Programa y dApp.
Relacionado
- Checklist de Incorporación de Desarrolladores - checklist completo
- Solana Basics - fundamentos
- El Modelo Mental de Solana vs. EVM - comparación
- Program Basics - runtime
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.