Fundamentos de Solana en Profundidad
El desarrollo en Solana deja de parecer una lista de APIs no relacionadas una vez que ves las cuentas, programas, transacciones, moneda, claves, clústeres y confirmación como un único sistema cerrado.
Cada otra página de esta sección (conceptos básicos, unidades, keypairs, clústeres, flujo de transacciones y el contraste con EVM) es un zoom en una cara de ese sistema, no una tecnología separada.
Esta página es el paraguas: cómo esas piezas encajan para que puedas razonar sobre una transferencia de billetera, un despliegue de programa o una llamada RPC fallida con la misma imagen subyacente.
Resumen
- Solana es una máquina de cuentas: los programas ejecutan contra cuentas nombradas en transacciones atómicas, valoradas y almacenadas en lamports enteros, autorizadas por firmas Ed25519 (o PDAs), en un clúster específico, hasta que un nivel de compromiso elegido dice que el resultado es lo suficientemente duradero para tu UX.
- Por Qué Importa: Los modelos mentales fragmentados producen errores clásicos (tratar los programas como contratos con almacenamiento, importes de SOL de punto flotante, RPCs de clúster incorrectos o UI que trata
processedcomo final) que desaparecen una vez que las piezas comparten un único modelo. - Conceptos Clave: cuenta, programa, instrucción, transacción, metadatos de cuenta, Sealevel, lamport, keypair, PDA, clúster, compromiso (commitment), exención de alquiler (rent exemption).
- Cuándo Usar: Primera orientación antes de escribir clientes o programas; incorporación de ingenieros de EVM o Web2; depuración de "cuenta no encontrada", transacciones caídas o contención paralela inesperada.
- Limitaciones / Compensaciones: Las listas explícitas de cuentas y los tamaños de cuenta fijos compran paralelismo y costos de almacenamiento predecibles, pero fuerzan más trabajo de diseño que los modelos de almacenamiento implícito y hacen que "un gran mapeo global" sea inviable.
- Temas Relacionados: Conceptos Básicos de Solana, SOL y lamports, keypairs y PDAs, clústeres, flujo de transacciones y el modelo mental Solana vs. EVM.
Fundamentos
La abstracción raíz es la cuenta.
Cada entidad en la cadena es una: un saldo de billetera, el bytecode de un programa desplegado, una acuñación de token, la estructura del perfil de un usuario o una retención temporal propiedad del sistema comparten los mismos campos estructurales: lamports, un buffer de bytes de datos, un ID de programa propietario, un indicador ejecutable y una época de alquiler heredada.
Nada "más" vive en la cadena fuera de esa forma.
Un programa es una cuenta cuyo indicador executable es verdadero y cuyos datos contienen bytecode BPF/SBF que el runtime puede cargar.
Los programas son sin estado (stateless) en el sentido de aplicación: no guardan saldos de usuario ni mapeos dentro de su propia cuenta después del despliegue, como lo hacen muchos contratos EVM con sus ranuras de almacenamiento.
El estado de aplicación mutable vive en cuentas separadas propiedad de ese programa (o del Programa del Sistema hasta que se asigne la propiedad).
Solo el programa propietario puede escribir los datos de una cuenta; las transferencias de lamports y algunas reglas a nivel de sistema son las principales excepciones alrededor de las cuales diseñas.
Esa separación es la razón por la que diseñas diseños de cuentas (account layouts) en lugar de "almacenamiento de contratos", y por la que El Modelo Mental de Solana vs. EVM existe como un contraste enfocado más adelante en esta sección.
La moneda nativa es SOL, pero cada importe en la cadena es un número entero de lamports, donde 1 SOL = 1,000,000,000 lamports.
Los clientes y programas tratan los saldos, tarifas y depósitos de alquiler como enteros u64 / bigint, nunca como SOL de punto flotante en el límite del protocolo.
La identidad es Ed25519: un keypair es una clave pública de 32 bytes (la dirección) más una clave secreta utilizada para firmar.
Las Direcciones Derivadas de Programa (PDAs) son direcciones válidas de 32 bytes que intencionalmente se encuentran fuera de la curva Ed25519, por lo que no existe una clave privada; los programas "firman" por ellas con semillas a través de invoke_signed, que es cómo funcionan las bóvedas propiedad del programa y las cuentas deterministas por usuario.
Un clúster (mainnet-beta, devnet, testnet o tu localnet) es una cadena completamente separada con su propio génesis, validadores y conjunto de cuentas.
Una dirección que tiene SOL en devnet no tiene ese saldo en mainnet-beta; la URL RPC, la red de la billetera y el explorador deben coincidir.
El compromiso (Commitment) - processed, confirmed, finalized - indica hasta qué punto ha progresado una transacción a través de la ejecución del líder y la votación de los validadores antes de que tu cliente la considere lo suficientemente buena.
Ninguno de estos temas es un trasfondo opcional; son la misma máquina vista a diferentes escalas.
Mecánicas e Interacciones
El trabajo entra en la red como una transacción: un paquete atómico de una o más instrucciones, cada una nombrando un ID de programa y las cuentas que esa instrucción puede tocar.
Cada entrada de cuenta lleva metadatos de cuenta (account metas): si la cuenta es escribible y si debe firmar, para que el runtime pueda bloquear cuentas y hacer cumplir la autorización antes de que se ejecute el bytecode.
Si alguna instrucción falla, toda la transacción falla; el éxito parcial no es un resultado de transacción de Solana.
Sealevel, el runtime paralelo en los validadores Agave 4.1.1, utiliza las listas de cuentas declaradas para programar transacciones no superpuestas concurrentemente y para serializar transacciones que comparten una cuenta escribible.
Compras rendimiento particionando el estado a través de cuentas para que usuarios no relacionados no compitan por una cuenta "caliente".
Una cuenta de datos duradera debe contener al menos el mínimo de lamports exento de alquiler (rent-exempt) para su tamaño de datos (consultado a través de getMinimumBalanceForRentExemption); las cuentas con fondos insuficientes no son un diseño sostenible para el estado a largo plazo.
Las tarifas se pagan en lamports por un pagador de tarifas designado; la prioridad se expresa con límites de unidades de cómputo y precio, superpuestos a las tarifas base basadas en firmas.
El camino desde el cliente hasta la confirmación es un único pipeline, no productos separados de "enviar" y "esperar":
Cliente (billetera / kit / CLI)
| construir instrucciones + metadatos de cuenta
| firmar con keypair(s) Ed25519
v
Nodo RPC ---- sendTransaction ---->
|
| Gulf Stream reenvía al próximo líder
v
Líder (slot actual)
| ordenar vía PoH, ejecutar vía Sealevel
| cada instrucción: cargar cuentas -> ejecutar programa -> escribir
v
Propagación de bloque (Turbine) + votos de validadores
|
| escalera de compromiso (commitment ladder):
| processed -> confirmed -> finalized
v
Cliente consulta o se suscribe hasta el compromiso elegido
Leyendo ese flujo con los fundamentos en mente: el cliente está ensamblando qué cuentas un programa sin estado puede tocar, financiando cualquier cuenta nueva con lamports, firmando con keypairs, apuntando a un clúster RPC, y esperando un compromiso que coincida con el riesgo de la UX.
Cómo Fluye una Transacción profundiza en cada salto; esta página solo necesita que veas que los saltos no son una segunda arquitectura.
El trabajo entre programas todavía está dentro de una sola transacción: un programa puede hacer CPI a otro programa, pero todas las cuentas que el llamado necesita ya deben aparecer en la lista de cuentas de la transacción con los metadatos correctos.
La componibilidad es cableado explícito, no contexto de llamada ambiental.
Consideraciones Avanzadas y Aplicaciones
Una vez que el bucle central está claro, las decisiones de diseño siguen de él en lugar de la folclore del framework.
Particiona el estado para que Sealevel pueda ejecutar usuarios independientes en paralelo; una única cuenta global en la que todos los usuarios deben escribir se convierte en un techo de rendimiento y un problema de alquiler/tamaño.
Prefiere PDAs para bóvedas controladas por programas y diseños deterministas de "una cuenta por usuario/entidad"; prefiere keypairs ordinarios para autoridades humanas y pagadores de tarifas.
Haz coincidir el compromiso con la consecuencia: los dashboards a menudo usan confirmed; los efectos secundarios fuera de la cadena irreversibles y las liquidaciones de alto valor generalmente esperan a finalized.
Mantén los entornos estrictos: un keypair de desarrollo, un keypair de mainnet y un keypair de validador local son identidades diferentes en cadenas diferentes, incluso cuando las cadenas base58 se ven similares entre clústeres solo por coincidencia de generación, no por estado compartido.
Al portar desde EVM, no busques "almacenamiento dentro del programa"; busca "qué cuentas declara esta instrucción, quién las posee y quién firma?"
La siguiente tabla comprime los dos modelos de cuentas sin reemplazar la página dedicada a EVM.
| Aspecto | Contratos estilo EVM | Modelo de cuentas de Solana |
|---|---|---|
| Dónde vive el código | Bytecode del contrato en una dirección | Cuenta de programa ejecutable (ID de programa) |
| Dónde vive el estado | Ranuras de almacenamiento dentro del contrato | Cuentas de datos separadas propiedad de un programa |
| Cómo se identifican los llamadores | msg.sender implícito | Cuentas firmantes explícitas en la instrucción |
| Cómo funcionan los mapeos | mapping en el almacenamiento del contrato | Muchas cuentas, a menudo PDAs con semillas basadas en material clave |
| Paralelismo | Limitado por el almacenamiento compartido del contrato | Sealevel paraleliza bloqueos de cuentas no superpuestos |
| Economía del almacenamiento | Gas para actualizaciones estilo SSTORE | Depósito de lamports exento de alquiler dimensionado a los bytes de la cuenta |
| Trabajo atómico de varios pasos | Una transacción, llamadas secuenciales | Una transacción, instrucciones explícitas múltiples + CPI |
Los niveles de compromiso son otra tabla operativa que deberías internalizar pronto.
| Compromiso | Significado aproximado | Uso típico |
|---|---|---|
processed | Ejecutado por el líder; aún no votado fuertemente | UI optimista, lecturas especulativas |
confirmed | Mayoría superpuesta ha votado sobre el bloque | Predeterminado para muchas acciones de aplicaciones |
finalized | Enraizado / prácticamente irreversible bajo condiciones normales | Liquidaciones, retiros, callbacks entre sistemas |
Los clústeres forman un tercer eje del mismo modelo: localnet para CI rápida, devnet para SOL de sandbox público y pruebas compartidas, testnet para experimentos orientados a validadores, mainnet-beta para valor real.
Clústeres y Redes y SOL, Lamports y Unidades detallan las operaciones y la precisión; aquí el punto avanzado es simplemente que las matemáticas de importes, la gestión de claves y la política de confirmación solo tienen sentido después de fijar en qué cadena te encuentras.
Conceptos Erróneos Comunes
- "Los programas almacenan el estado de mi aplicación como un contrato inteligente." Los programas son ejecutables; el estado vive en cuentas que poseen y que cada instrucción debe pasar explícitamente.
- "Los importes de SOL pueden ser flotantes en el cliente si tengo cuidado." Los valores en la cadena son lamports enteros; convierte en el límite de la UI con matemáticas enteras/
bigint, no flotantes IEEE, para cualquier cosa que se vaya a firmar o almacenar. - "Los PDAs son solo claves públicas elegantes con claves secretas que derivas." Los PDAs no tienen clave privada; solo un programa que conoce las semillas puede autorizar firmas de PDA a través del runtime.
- "Devnet y mainnet-beta comparten cuentas si la dirección coincide." Los clústeres son ledgers separados; el mismo keypair controla diferentes estados de cuenta en cada cadena, y el RPC debe apuntar al clúster que deseas.
- "Si
sendTransactiondevuelve una firma, la transferencia es final." Una firma significa que el nodo aceptó la ruta de envío; la durabilidad depende del nivel de compromiso que esperes después. - "Listar menos cuentas hace que las transacciones sean más baratas o simples." Omitir una cuenta requerida falla en tiempo de ejecución; bloquear en exceso cuentas escribibles reduce el paralelismo - la corrección necesita el conjunto verdadero, el rendimiento necesita un diseño bien particionado.
Preguntas Frecuentes
¿Cuál es la versión de una sola frase del modelo mental de desarrollador de Solana?
Todo es una cuenta; los programas ejecutan contra cuentas nombradas en transacciones atómicas, financiadas en lamports, autorizadas por firmas o PDAs, en un clúster, hasta que tu compromiso elegido dice que puedes confiar en el resultado.
¿Por qué "todo es una cuenta" es útil en lugar de eslóganes bonitos?
Unifica billeteras, programas, acuñaciones y datos bajo un mismo modelo de carga/almacenamiento y propiedad, por lo que las tarifas, el alquiler, los bloqueos y las lecturas RPC utilizan el mismo vocabulario.
Si los programas son cuentas, ¿cómo difiere un programa de una cuenta de datos?
Una cuenta de programa está marcada como ejecutable y contiene bytecode que el cargador ejecuta; una cuenta de datos contiene bytes de aplicación interpretados por su programa propietario y no se ejecuta como código.
¿Quién tiene permitido cambiar los bytes de datos de una cuenta?
Solo el programa que posee la cuenta puede modificar sus datos (sujeto a las reglas del runtime); otros programas necesitan hacer CPI al propietario o deben poseer lamports/firmantes para operaciones que el sistema permite.
¿Qué garantiza realmente una transacción?
Todas sus instrucciones tienen éxito o ninguno de sus efectos se confirma; no hay aplicación parcial de la lista de instrucciones de una transacción fallida.
¿Por qué se debe listar cada cuenta por adelantado?
El runtime utiliza la lista para el bloqueo, las comprobaciones de firma y la programación de Sealevel; las cuentas no declaradas no se pueden cargar a mitad de vuelo como algunas VMs permiten el acceso implícito al almacenamiento.
¿Cómo decide Sealevel qué se puede ejecutar en paralelo?
Las transacciones que no comparten bloqueos de cuenta conflictivos, especialmente cuentas escribibles superpuestas, pueden ejecutarse concurrentemente; las conflictivas se ordenan para que las escrituras permanezcan consistentes.
¿Qué es un lamport y por qué no usar SOL en todas partes?
Un lamport es la unidad entera base (1 SOL = 1e9 lamports); la cadena y las APIs hablan en enteros para que los importes nunca dependan del redondeo de punto flotante.
¿Qué es la exención de alquiler (rent exemption) en una línea?
Un saldo mínimo de lamports basado en el tamaño de los datos que mantiene una cuenta viva sin recolección de alquiler continua bajo la economía actual: finánciala en la creación a través del mínimo exento de alquiler.
¿Cómo encajan tanto los keypairs como los PDAs en la misma historia de identidad?
Los keypairs prueban la autoridad humana o del servidor con firmas Ed25519; los PDAs son direcciones controladas por programas sin secretos, autorizadas solo cuando el programa propietario proporciona las semillas correctas en el momento de la CPI.
¿Por qué mi explorador no muestra nada cuando el saldo de mi CLI parece estar bien?
Casi siempre es una discrepancia de clúster: CLI en devnet, explorador en mainnet-beta, o una URL RPC apuntando a una red diferente a la de la billetera.
¿Por qué nivel de compromiso debería esperar mi dapp por defecto?
Muchas acciones de producto usan confirmed para una UX receptiva; usa finalized antes de efectos externos irreversibles, y trata processed solo como optimista.
¿En qué se diferencia esta página de "El Modelo Mental de Solana vs. EVM"?
Esta página es el modelo completo del constructor (cuentas hasta confirmación); la página de EVM es un contraste de portabilidad enfocado para ingenieros que ya piensan en contratos con almacenamiento.
¿Cambian Anchor o @solana/kit este modelo mental?
No, Anchor 0.32.1 y @solana/kit 7.0.0 son capas ergonómicas sobre las mismas superficies de cuentas, instrucciones, metadatos y RPC/compromiso descritas aquí.
¿A dónde debo ir después de esta página?
Revisa Conceptos Básicos de Solana para ejemplos prácticos, luego profundiza en moneda, claves, clústeres y flujo de transacciones a través de los enlaces Relacionados a continuación mientras construyes.
Relacionados
- Conceptos Básicos de Solana - orientación práctica sobre cuentas, programas, transacciones y SOL
- SOL, Lamports y Unidades - denominaciones enteras, precisión y cantidades de tarifas/alquiler
- Keypairs y Direcciones - identidad Ed25519, roles de firma y direcciones PDA
- El Modelo Mental de Solana vs. EVM - cuentas y programas frente a contratos con almacenamiento
- Cómo Fluye una Transacción - del cliente al líder hasta el compromiso en detalle operativo
- Clústeres y Redes - mainnet-beta, devnet, testnet y localnet como cadenas separadas
Versiones de la Pila: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 y @solana/kit 7.0.0.