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.
//
Busca en todas las páginas de la documentación
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.
processed como final) que desaparecen una vez que las piezas comparten un único modelo.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.
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 elegidoLeyendo 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.
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.
bigint, no flotantes IEEE, para cualquier cosa que se vaya a firmar o almacenar.sendTransaction devuelve 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.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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Muchas acciones de producto usan confirmed para una UX receptiva; usa finalized antes de efectos externos irreversibles, y trata processed solo como optimista.
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.
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í.
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.
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.
Revisado por Chris St. John·Última actualización: 19 jul 2026