Modelo de cuentas de Solana: Guía técnica

Esta Guía técnica del modelo de cuentas de Solana explica los campos de tiempo de ejecución y las reglas de acceso en las que confían los programas, incluyendo la propiedad, las cuentas ejecutables, las cuentas de tokens, la exención de renta, las direcciones derivadas del programa, las cuentas de tokens asociadas e invocación entre programas.

Los detalles de implementación, como el manejo de la renta, los límites de tamaño de las cuentas y las API de los clientes, pueden cambiar. Los desarrolladores deben consultar la documentación actual de Solana y consultar los parámetros actuales de la red antes de implementar.

Cada transacción en Solana toca una cuenta. Cada token que posees, cada programa que implementas, cada NFT que acuñas: todo vive en cuentas. Antes de escribir una sola línea de código en Solana, comprender cómo funcionan las cuentas no es un conocimiento de fondo opcional. Es el requisito previo para todo lo demás.

Piensa en Solana como un archivador. Cada cajón contiene una carpeta y cada carpeta tiene una etiqueta (su dirección), contenido (sus datos), un sello de balance y un nombre de departamento en la portada que indica qué programa tiene autoridad para editar lo que hay dentro. Ya seas un desarrollador que migra desde Ethereum, un investigador que evalúa la arquitectura de Solana o un estudiante que forma su primer modelo mental de la gestión del estado On-Chain, esta guía cubre el panorama completo: anatomía de la cuenta, tipos de cuenta, reglas de propiedad, mecánica de la renta, direcciones derivadas del programa, una comparación paralela con Ethereum y código anotado para construir en la práctica.

Descripción general de la Guía técnica del modelo de cuentas de Solana

El modelo de cuentas de Solana es la arquitectura de almacenamiento de datos y gestión de estados de la Blockchain de Solana. Cada parte del estado en Solana, incluidos los balances de tokens, la lógica del programa, los datos del usuario y la configuración del sistema, se almacena en cuentas discretas identificadas por claves públicas únicas de 256 bits. Consulta la documentación oficial de cuentas de Solana para ver la especificación canónica.

Cada parte del estado en Solana vive en una cuenta. Los programas no almacenan sus propios datos; leen y escriben en las cuentas que se les pasan durante la ejecución. Esta única decisión arquitectónica separa el diseño de Solana de la mayoría de las otras blockchains.

La analogía del archivador se traslada directamente a la estructura de datos: el archivador es la Blockchain de Solana, las carpetas son cuentas, la etiqueta de cada carpeta es su clave pública (la dirección On-Chain), el contenido de la carpeta es el campo de datos, el sello de balance es el campo de lamports y el sello del departamento en la portada es el campo del propietario que registra qué programa tiene autoridad de escritura. Solo el departamento nombrado en ese sello puede alterar lo que hay dentro.

Si vienes de Ethereum, esta distinción es importante: los contratos inteligentes de Ethereum almacenan su propio estado internamente, mientras que los programas de Solana no tienen estado (stateless). La comparación completa se encuentra en una sección específica a continuación.

Anatomía de una cuenta de Solana

Cada cuenta de Solana, ya sea que almacene SOL, código de programa o estado de la aplicación, se construye a partir de los mismos cinco campos.

Los cinco campos de cada cuenta de Solana

Cada cuenta en Solana contiene exactamente cinco campos, cada uno con una función distinta. Comprender estos campos en términos sencillos antes de examinar el código hace que los detalles técnicos sean mucho más fáciles de interiorizar.

lamports: el Balance de SOL para esta cuenta, expresado en Lamports (la denominación más pequeña de Solana, explicada en la siguiente sección). En la analogía del archivador, este es el valor monetario sellado en la portada de la carpeta.

data: una matriz de bytes sin procesar (Vec<u8>) que almacena cualquier estado que necesite el programa propietario. Para una cuenta de programa, este campo contiene bytecode BPF compilado. Para una cuenta de datos, contiene el estado de la aplicación serializado. Los programas definen su propio formato de serialización (comúnmente Borsh) para leer y escribir datos estructurados en este campo. El equivalente en el archivador es el contenido físico dentro de la carpeta.

owner: la clave pública del programa autorizado para modificar el campo de datos de esta cuenta. Ningún otro programa puede escribir en él. Este es el sello del departamento en la portada de la carpeta.

executable: una bandera booleana. Cuando se establece en true, la cuenta almacena código de programa y puede ejecutarse. Cuando es false, la cuenta es un contenedor de datos.

rent_epoch: un campo heredado que anteriormente rastreaba el tiempo de recaudación de renta. Este campo se está desestimando y no tiene importancia operativa para las cuentas exentas de renta, que es el estándar de producción.

Cada cuenta de Solana se identifica mediante una clave pública única de 256 bits derivada de un par de claves ed25519, que sirve como su dirección y su identificador On-Chain. El tamaño máximo del campo de datos para una sola cuenta es de 10 MB a partir de las actualizaciones recientes del protocolo; verifique los límites actuales con la documentación de cuentas de Solana, ya que este valor ha cambiado a lo largo de la historia de Solana.

Lamports: La unidad más pequeña de Solana

Un Lamport es la denominación más pequeña de SOL: 1 SOL equivale a 1.000.000.000 Lamports (10⁹). La unidad lleva el nombre de Leslie Lamport, un científico de la computación cuyo trabajo en sistemas distribuidos y tolerancia a fallos subyace en gran parte de la teoría moderna de la computación distribuida. Los Lamports existen porque toda la aritmética On-Chain, incluidos los cálculos de renta, las tarifas de transacción y los balances de las cuentas, debe utilizar aritmética de enteros para evitar errores de precisión de punto flotante. Expresar los valores en Lamports hace que cada cálculo sea exacto.

¿Es una cuenta de Solana lo mismo que una billetera?

Una cuenta de Solana y una billetera no son lo mismo. Lo que consideras como tu billetera, la aplicación Phantom o Solflare en tu teléfono, es software Off-Chain que gestiona una clave privada. La entidad On-Chain es una cuenta del sistema que contiene tu Balance de SOL. Tu billetera controla una cuenta del sistema; no es una cuenta en sí misma. Las cuentas de tokens, las cuentas de programas y las cuentas de datos no tienen equivalente en la billetera: son puramente contenedores de datos On-Chain que ninguna aplicación de billetera de consumo representa directamente.

Las cuentas de Solana se dividen en cuatro categorías, cada una definida por su programa propietario y su bandera ejecutable.

1. Cuentas del sistema: propiedad del Programa del Sistema; se utilizan para el almacenamiento de SOL y billeteras de usuarios
2. Cuentas de programa: cuentas ejecutables que almacenan bytecode BPF compilado
3. Cuentas de datos/estado: propiedad de programas; almacenan el estado específico de la aplicación
4. Cuentas de tokens: cuentas de datos especializadas propiedad del Programa de Tokens SPL (con Cuentas de Tokens Asociadas como el subconjunto canónico)

Cuentas del sistema

Las cuentas del sistema son propiedad del Programa del Sistema, y las billeteras de los usuarios son cuentas del sistema. El Programa del Sistema es el programa nativo de Solana responsable de tres operaciones principales: crear nuevas cuentas (asignar espacio de datos On-Chain), asignar la propiedad de la cuenta (establecer el campo del propietario en un programa específico) y transferir SOL entre cuentas. Cada cuenta nueva en Solana comienza como una cuenta del sistema propiedad del Programa del Sistema.

El Programa del Sistema tiene una dirección bien conocida: 11111111111111111111111111111111 (32 unos en base58). Consulta la documentación del Programa del Sistema para ver su conjunto de instrucciones completo. Cuando un desarrollador crea una cuenta de datos para su programa, invoca la instrucción Create Account del Programa del Sistema, especificando el tamaño de los datos, el Depósitos de Lamport exento de renta y la clave pública del nuevo programa propietario.

Cuentas de programa

Las cuentas de programas almacenan el código de bytes BPF compilado, no el estado. El indicador ejecutable en estas cuentas está configurado como true. Los programas no tienen estado: cuando un programa se ejecuta, recibe una lista de cuentas para leer o escribir a través de la instrucción de la transacción. No mantiene ningún estado interno entre llamadas. Si vienes de Ethereum, puede que conozcas el código ejecutable On-Chain como contratos inteligentes, pero los programas de Solana funcionan de forma fundamentalmente diferente porque no tienen un estado propio. Las cuentas de programas son propiedad del programa BPF Loader. Una vez desplegada, una cuenta de programa es inmutable a menos que se haya designado un par de claves de autoridad de actualización durante el despliegue.

Cuentas de datos y de estado

Las cuentas de datos contienen el estado de la aplicación que los programas leen y escriben durante la ejecución. El indicador ejecutable en estas cuentas es false. El campo de datos almacena el estado definido por el programa serializado con Borsh. Algunos ejemplos son la Posición de préstamo de un usuario en un protocolo DeFi, los metadatos de NFT o un contador de aplicación. El programa propietario es la única entidad que puede escribir en el campo de datos de esta cuenta, una regla que se explica detalladamente en la sección de propiedad.

Cuentas de tokens y cuentas de tokens asociadas

Las cuentas de tokens son cuentas de datos propiedad del programa SPL Token, y cada una mantiene un Balance de un token específico para una billetera específica. Una sola dirección de billetera puede tener múltiples cuentas de tokens, una para cada tipo de token que posea.

Una Cuenta de Token Asociada (ATA) es la cuenta de token canónica para un par específico de [dirección de billetera, dirección de mint]. Las ATA se derivan de forma determinista como una Dirección Derivada del Programa (PDA) utilizando la dirección de la billetera y la dirección de mint del token como semillas. Esto garantiza que cada billetera tenga exactamente una cuenta "oficial" por tipo de token. Las ATA son el estándar utilizado por billeteras como Phantom y Solflare, por los exchanges y por los protocolos: cuando recibes un token en la interfaz de tu billetera, este va a tu ATA para ese token.

Si no existe una ATA para un par dado de [billetera, mint], debe crearse antes de poder recibir tokens, y la creación cuesta un Depósitos de Lamports exento de renta. Esta es la razón por la que algunas transacciones incluyen una pequeña "comisión de creación de cuenta" en las interfaces de las billeteras. Para ver la especificación completa de la ATA, consulta la documentación de la cuenta de token asociada de SPL.). Una ATA es una cuenta de token, pero no todas las cuentas de tokens son ATA, y la distinción es importante al depurar programas relacionados con tokens.

Propiedad de la cuenta: Cómo controla Solana el acceso a los datos

La propiedad de la cuenta en Solana es un mecanismo de autoridad de escritura, no un concepto de propiedad de activos.

La regla de propiedad

Solo el programa propietario de la cuenta puede modificar su campo de datos. Ningún otro programa puede escribir en él, independientemente de lo que el usuario autorice a nivel de transacción. El campo owner en AccountInfo almacena la Clave pública del programa que ostenta esta autoridad. Los programas que no son propietarios pueden leer el campo de datos libremente, pero escribir requiere ser el propietario designado.

El Programa del Sistema asigna la propiedad durante la creación de la cuenta. Cuando un desarrollador crea una cuenta de datos para su programa, la instrucción Create Account establece el campo owner con la Clave pública de su programa. La propiedad se puede reasignar, pero solo por el programa propietario actual utilizando la instrucción Assign. Ninguna parte externa puede transferir la propiedad unilateralmente.

Propietario frente a autoridad: Una distinción crítica

Propietario y autoridad son dos conceptos diferentes en la gestión de cuentas de Solana. El propietario es el programa registrado en el campo owner de la cuenta, es decir, el programa que puede escribir en el campo de datos. La autoridad (o firmante) es el par de claves que puede firmar transacciones para la cuenta.

Considera una cuenta de token como ejemplo: la Clave privada de tu billetera firma la transacción (tú eres la autoridad), pero el Programa SPL Token es el propietario de tu cuenta de token y es la única entidad que puede modificar tu Balance de tokens en el campo de datos. Puedes autorizar una transacción que mueva tokens, pero la escritura real en el campo de datos la realiza el Programa de Tokens, no tú directamente. Confundir estos dos conceptos produce la mayoría de los errores de depuración de propiedad de cuentas para los desarrolladores nuevos en Solana.

La propiedad en la práctica: Un ejemplo de DEX

Un programa de DEX solo puede escribir en las cuentas que posee directamente. Para transferir tokens de la cuenta de token de un usuario (propiedad del Programa SPL Token, no del DEX), el DEX no puede escribir en esa cuenta directamente. Los programas pueden llamar a otros programas dentro de la misma transacción, un patrón llamado Invocación entre programas (CPI), lo que permite a un DEX dar instrucciones al Programa de Tokens para que mueva tokens en nombre de un usuario. El DEX envía una CPI al Programa de Tokens, proporcionando la autorización firmada del usuario, y el Programa de Tokens realiza la escritura en el campo de datos de la cuenta de token del usuario. Así es como el modelo de propiedad del programa se extiende a las interacciones entre programas. Para una guía completa, consulta la guía de Invocación entre programas (CPI) para desarrolladores de Solana.

Renta de la cuenta y exención de renta

La renta de Solana es un mecanismo de coste de almacenamiento, no una comisión recurrente.

¿Qué es la renta?

La renta es el mecanismo de Solana para fijar el precio del almacenamiento On-Chain. Cada cuenta debe mantener un Balance mínimo de SOL proporcional a su tamaño de datos para permanecer activa On-Chain. La corrección que la mayoría del contenido de la competencia omite: la renta no es una comisión recurrente en la práctica. El estándar de producción es la exención de renta, donde realizar Depósitos de suficientes SOL por adelantado para cubrir aproximadamente dos años de almacenamiento hace que una cuenta esté permanentemente exenta de cualquier deducción de renta. La gran mayoría de las cuentas desplegadas operan bajo exención de renta.

Exención de renta: El estándar práctico

La exención de renta es el estándar de producción para todas las cuentas de Solana desplegadas. El Balance mínimo para la exención de renta es de aproximadamente 6.960 Lamports multiplicados por el tamaño de los datos de la cuenta en bytes, más una cantidad base de aproximadamente 890.880 Lamports para una cuenta de cero bytes.

Un ejemplo práctico: una cuenta de datos de 100 bytes requiere aproximadamente 890.880 + (6.960 × 100) = 1.586.880 Lamports, o aproximadamente 0,00159 SOL. Estas cifras son aproximadas y están sujetas a cambios. Verifica los valores actuales con el comando de la CLI de Solana solana rent <bytes> o la documentación de renta de Solana.). Un cambio propuesto para convertir la renta en un modelo de comisión por transacción no se ha activado en el momento de escribir este artículo; consulta la documentación actual para conocer el estado más reciente del protocolo.

¿Qué ocurre cuando una cuenta se queda sin SOL?

La creación de cuentas actual generalmente requiere financiación exenta de renta. Los desarrolladores deben consultar los requisitos actuales de RPC en lugar de confiar en el comportamiento heredado de cobro de renta. Este es el comportamiento que suscita preocupación sobre la "eliminación" de las cuentas.

El tiempo de ejecución nunca cierra automáticamente las cuentas exentas de renta. Las cuentas de producción siempre se financian hasta el umbral de exención de renta, por lo que la recolección de basura no les afecta. Cerrar cuentas intencionadamente es un patrón separado y deliberado: los programas pueden cerrar cuentas de datos para reclamar los Depósitos de Lamports. En un protocolo DeFi, por ejemplo, cerrar una Posición de préstamo devuelve al usuario los SOL que financiaron la cuenta de datos de esa posición. Se trata de un patrón de diseño de protocolo común, no de una eliminación involuntaria.

Explicación de las Direcciones Derivadas del Programa (PDA)

Las Direcciones Derivadas del Programa resuelven un problema específico: cómo un programa puede controlar una cuenta sin que nadie posea la Clave privada correspondiente.

Una Dirección Derivada del Programa (PDA) es una dirección de cuenta generada de forma determinista derivada de un ID de programa y uno o más valores de semilla utilizando el hashing SHA-256. Las PDA se sitúan intencionadamente fuera de la curva elíptica ed25519, lo que significa que no tienen una Clave privada correspondiente. Solo el programa propietario puede firmar transacciones para cuentas en direcciones PDA. Consulta la documentación de las PDA de Solana) para ver la especificación completa.

Todas las direcciones de cuentas regulares de Solana se encuentran en la curva elíptica ed25519. Las PDA se colocan intencionadamente fuera de esa curva. La propiedad fuera de la curva no es un error; es el mecanismo de diseño que hace que una clave privada sea matemáticamente imposible. Ningún ser humano, ningún hardware wallet y ningún sistema de gestión de claves puede producir la clave privada para una PDA porque no existe tal clave en la curva.

Por qué son importantes las PDA: Custodia controlada por programas

La consecuencia de no tener clave privada es que solo el programa propietario puede autorizar transacciones para una PDA. Esto permite una custodia controlada por programas sin confianza: el programa ostenta la autoridad sobre la cuenta sin depender de ningún ser humano para salvaguardar una clave privada.

Compare esto con las cuentas de pares de claves regulares, donde quien posee la clave privada controla la cuenta. Si se pierde la clave, se pierde el acceso. Si la clave es robada, la cuenta se ve comprometida. Las PDA eliminan esta dependencia por completo. La lógica del programa es el custodio, un código auditable en lugar de una persona.

Tres casos de uso de PDA en el mundo real

Las PDA aparecen en tres patrones recurrentes en los programas de Solana.

Cuentas de escrow de DEX: un programa de exchange descentralizado mantiene los tokens en una PDA hasta que ambas partes de un intercambio cumplen las condiciones requeridas. Ningún intermediario de confianza posee una clave privada para el depósito en garantía. La lógica del programa controla la liberación y ningún participante puede retirar los fondos fuera de las reglas del protocolo.

Ningún individuo puede hacer un "Rug Pull" de la autoridad de acuñación de una colección NFT. La autoridad de acuñación NFT funciona haciendo que los programas de Metaplex controlen la acuñación a través de una PDA derivada de la dirección de acuñación. Debido a que no existe una clave privada para esta PDA, las reglas de acuñación de la colección se aplican únicamente mediante el código del programa después del despliegue.

¿Cómo almacena un programa los datos por usuario sin mantener un índice centralizado? El almacenamiento de estado por usuario utiliza una PDA única derivada de [program_id, user_pubkey]. Esto produce una dirección de cuenta determinista y específica del usuario para almacenar su puntuación de juego, posición de préstamo o registro de staking. El programa siempre sabe dónde encontrar los datos de cada usuario.

Las funciones findProgramAddress() y createProgramAddressSync() localizan direcciones válidas fuera de la curva probando direcciones candidatas con una semilla de aumento (bump seed) incremental hasta que una cae fuera de la curva.

¿Cuándo debería usar una PDA?

Utilice una PDA siempre que su programa necesite controlar una cuenta sin depender de la clave privada de un humano. Si la autoridad de la cuenta debe ser la lógica del programa en lugar de una persona, utilice una PDA. Esta regla cubre cuentas de custodia (escrow), bóvedas de protocolos, autoridades de acuñación y cualquier estado que el propio programa deba poseer y gestionar a través de múltiples usuarios.

Solana frente a Ethereum: comparativa de modelos de cuentas

La diferencia fundamental entre los modelos de cuentas de Solana y Ethereum es dónde reside el estado.

En Ethereum, los contratos inteligentes tienen estado: almacenan su propio estado internamente junto a su código. Un contrato de Solidity mantiene sus propios mapeos y variables de estado dentro del almacenamiento del contrato, gestionado por la Máquina Virtual Ethereum (EVM). En Solana, los programas no tienen estado; todo el estado reside en cuentas externas que los programas leen y escriben durante la ejecución. Mientras que Ethereum ejecuta programas en la EVM, Solana utiliza un entorno de ejecución basado en BPF que ejecuta programas contra cuentas declaradas de antemano en la transacción.

Las compensaciones van en ambas direcciones. El modelo con estado de Ethereum conlleva una ventaja genuina en la experiencia del desarrollador: un modelo mental más sencillo, sin gestión explícita de cuentas y una menor carga cognitiva para muchos casos de uso. Un desarrollador puede escribir y desplegar un contrato ERC-20 sin pensar en el tamaño de la cuenta de datos, los Depósitos exentos de renta o la derivación de PDA.

El modelo sin estado de Solana cambia esa simplicidad por el paralelismo de ejecución y la separación de conceptos. Las declaraciones de cuentas requeridas por cada transacción son la entrada para el algoritmo de programación de Sealevel, que ejecuta transacciones no conflictivas simultáneamente. Otras blockchains de Capa 1 como Aptos y Sui adoptan sus propias variantes de separación de estados basada en recursos, cada una con diferentes perfiles de compensación. Ni el enfoque de Ethereum ni el de Solana es categóricamente superior; reflejan diferentes prioridades de diseño para diferentes cargas de trabajo.

Por qué es importante esta arquitectura: Sealevel y ejecución paralela

Los programas sin estado no son una restricción de diseño; son el mecanismo que hace posible la ejecución paralela.

La cadena causal desde el diseño del modelo de cuentas hasta el rendimiento funciona de la siguiente manera. En primer lugar, los programas de Solana no tienen estado. En segundo lugar, debido a que los programas no tienen estado, cada transacción debe declarar todas las cuentas a las que accederá, tanto de lectura como de escritura, antes de que comience la ejecución. En tercer lugar, el motor de ejecución paralela de Solana, Sealevel, analiza estas listas de acceso a cuentas antes de la programación. En cuarto lugar, las transacciones que acceden a conjuntos de cuentas que no se solapan no tienen dependencias de datos entre sí y pueden ejecutarse simultáneamente en múltiples núcleos de procesador. En quinto lugar, el resultado es una red capaz de procesar decenas de miles de transacciones por segundo.

Anatoly Yakovenko diseñó la arquitectura de Solana con el procesamiento de transacciones en paralelo como un objetivo explícito, y la separación de la lógica del programa del estado de la cuenta es lo que lo hace posible. El modelo de cuentas funciona en concierto con las otras innovaciones arquitectónicas de Solana, incluyendo Proof of History (PoH), el mecanismo de reloj criptográfico de Solana. Para entender cómo contribuye PoH a este rendimiento, consulte la explicación de cómo funciona Proof of History en la arquitectura de Solana.

Construir con cuentas: implementación para desarrolladores

Cada cuenta con la que trabaja un programa de Solana debe ser creada, financiada y asignada a un propietario antes de que el programa pueda leer o escribir en ella.

Creación de una cuenta con el Programa de Sistema

Los programas de Solana se escriben en Rust, un lenguaje de programación de sistemas, y se compilan a bytecode BPF antes de su despliegue. La creación de una cuenta en Solana sigue estos pasos, cada uno de los cuales corresponde a un parámetro en la instrucción Create Account del Programa de Sistema:

1. from_pubkey: identifica la cuenta que financia la creación (el pagador)
2. new_account_pubkey: especifica la dirección de la nueva cuenta
3. lamports: calcula la cantidad del Balance exento de renta basada en el tamaño de los datos
4. space: establece el tamaño de los datos en bytes a asignar para la cuenta
5. owner: especifica la clave pública del programa que poseerá y escribirá en esta cuenta

// Create a new data account using the System Program
let create_account_ix = system_instruction::create_account(
    &payer.pubkey(),         // from_pubkey: quién financia esta cuenta
    &new_account.pubkey(),   // new_account_pubkey: la dirección de la cuenta
    rent_exempt_balance,     // lamports: suficiente para estar exento de renta
    data_size as u64,        // space: bytes asignados para los datos de la cuenta
    &program_id,             // owner: el programa que controla esta cuenta
);

Esta instrucción establece la propiedad de la cuenta. Después de ejecutarse, solo el programa en program_id puede escribir en el campo de datos de esta cuenta.

Uso del framework Anchor

Muchos programas de Solana se construyen con el framework Anchor, que proporciona macros estructuradas para definir las restricciones de las cuentas e instrucciones del programa. Consulte la documentación de Anchor para obtener la referencia completa del framework.

// Anchor: define account constraints using the #[derive(Accounts)] macro
#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,                        // create this account if it doesn't exist
        payer = user,                // user pays the rent-exempt deposit
        space = 8 + MyData::LEN,    // 8-byte discriminator + data size
    )]
    pub my_account: Account<'info, MyData>,     // the new data account
    #[account(mut)]
    pub user: Signer<'info>,                    // the transaction signer and payer
    pub system_program: Program<'info, System>, // required for account creation
}

Anchor gestiona automáticamente el código repetitivo de validación de cuentas, verificando la propiedad y el estado del firmante antes de que se ejecute la lógica de tu instrucción. Comprender el modelo de cuenta subyacente sigue siendo necesario al depurar errores de propiedad o diseñar estructuras PDA, ya que las macros de Anchor son abstracciones sobre los mismos mecanismos descritos a lo largo de este artículo.

Recursos relacionados con la arquitectura de Solana

Los desarrolladores que busquen una ruta de implementación más corta pueden utilizar la guía del modelo de cuentas centrada en el desarrollador; las convenciones del programa de tokens se cubren en la descripción general de la Solana Program Library. La página de precios de SOL y el mercado Spot SOL/USDT se refieren al acceso al mercado, no a la propiedad de la cuenta ni a la autoridad del programa.

FAQ: Modelo de cuenta de Solana: Guía técnica

¿Qué es una cuenta en Solana?

Una cuenta de Solana es un contenedor de datos On-Chain identificado por una clave pública única de 256 bits. Cada cuenta almacena un Balance de SOL en lamports, un campo de datos (una matriz de bytes que contiene el estado del programa o el código de bytes), un campo de propietario (la clave pública del programa autorizado para modificar los datos) y una marca de ejecutable que indica si la cuenta almacena código de programa.

¿En qué se diferencia el modelo de cuenta de Solana del de Ethereum?

En Ethereum, los contratos inteligentes almacenan su propio estado internamente junto a su código. En Solana, los programas no tienen estado (stateless); todo el estado reside en cuentas externas que los programas leen y escriben durante la ejecución. Esta separación permite que el tiempo de ejecución Sealevel de Solana detecte patrones de acceso a cuentas que no se solapan y ejecute múltiples transacciones simultáneamente, lo que permite el procesamiento paralelo a escala.

¿Qué es el alquiler (rent) en Solana?

Todas las cuentas de producción de Solana se financian hasta el umbral de exención de alquiler, lo que las hace permanentemente exentas de cargos por almacenamiento. El alquiler es el mecanismo subyacente: las cuentas deben mantener un Balance de SOL mínimo proporcional a su tamaño de datos para permanecer activas On-Chain. Las cuentas exentas de alquiler, aquellas financiadas por encima del umbral, nunca son cerradas automáticamente por el tiempo de ejecución.

¿Qué es una Dirección Derivada del Programa (PDA)?

Una Dirección Derivada del Programa (PDA) es una dirección de cuenta generada de forma determinista a partir de un ID de programa y valores de semilla (seeds) utilizando el hash SHA-256. Las PDA quedan fuera de la curva elíptica ed25519, por lo que no tienen una clave privada correspondiente. Solo el programa propietario puede firmar transacciones para cuentas en direcciones PDA, lo que permite la custodia controlada por el programa sin confianza para cuentas de depósito en garantía (escrow), autoridades de emisión (mint) y almacenamiento de estado por usuario.

¿Se pueden eliminar las cuentas de Solana?

La creación de cuentas actuales generalmente requiere financiación exenta de alquiler. Los desarrolladores deben consultar los requisitos actuales de RPC en lugar de confiar en el comportamiento heredado de recaudación de alquileres. Las cuentas de producción desplegadas correctamente siempre se financian hasta el umbral de exención de alquiler y nunca se eliminan automáticamente. Los programas también pueden cerrar cuentas intencionadamente para reclamar los Depósitos en SOL, un patrón común en los protocolos de OTK_2.

¿Qué son los Lamports?

Los lamports son la denominación más pequeña de SOL en la Blockchain de Solana: 1 SOL equivale a 1.000.000.000 de lamports (10⁹). Nombrados en honor a Leslie Lamport, un pionero de la computación distribuida, los lamports se utilizan para todos los Balances de SOL, las comisiones de transacción y los cálculos de alquiler On-Chain. Denominar las cantidades en lamports evita errores de precisión de punto flotante que surgirían al utilizar valores fraccionarios de SOL en la aritmética On-Chain.

¿Qué es el Programa del Sistema (System Program) en Solana?

El System Program es el programa nativo de Solana responsable de tres operaciones principales: crear nuevas cuentas (asignar espacio de datos On-Chain), asignar la propiedad de la cuenta (establecer el campo del propietario en un programa específico) y transferir SOL entre cuentas del sistema. Cada nueva cuenta de Solana comienza como una cuenta del sistema. Los desarrolladores invocan la instrucción Create Account del System Program para dotar a sus programas de cuentas de datos.

¿Cuántos tipos de cuentas hay en Solana?

Hay tres tipos principales de cuentas de Solana: (1) Cuentas del Sistema, propiedad del System Program y utilizadas para Balances de SOL y carteras de usuarios; (2) Cuentas de Programa, cuentas ejecutables que almacenan código de bytes BPF compilado; (3) Cuentas de Datos/Estado, propiedad de programas y que almacenan el estado específico de la aplicación. Las Cuentas de Token son un subconjunto especializado de cuentas de datos propiedad del SPL Token Program.

Conclusiones clave y próximos pasos

El modelo de cuenta de Solana requiere más reflexión inicial que el modelo con estado de Ethereum, pero esa inversión cognitiva es lo que hace posible la ejecución paralela.

• Cada fragmento de estado en Solana reside en una cuenta; los programas leen y escriben en las cuentas pasadas durante la ejecución, no en el almacenamiento interno.
• Cada cuenta tiene cinco campos: lamports, datos, propietario, ejecutable y el heredado rent_epoch.
• Solo el programa propietario puede modificar el campo de datos de una cuenta; este es el mecanismo principal de control de acceso de Solana.
• Las cuentas de producción se financian hasta el umbral de exención de alquiler y el tiempo de ejecución nunca las recolecta automáticamente como basura.
• Las Direcciones Derivadas del Programa permiten la custodia controlada por el programa sin confianza mediante el uso de direcciones fuera de la curva que no tienen clave privada.
• El tiempo de ejecución Sealevel de Solana paraleliza la ejecución de transacciones analizando las listas de acceso a cuentas declaradas en transacciones que no entran en conflicto.

¿Listo para construir sobre esta base? Continúa con:

• Cómo funcionan los programas de Solana: una guía para desarrolladores sobre la ejecución sin estado.
• Guía del framework Anchor para crear programas de Solana.
• Invocación entre programas (CPI) explicada: cómo los programas de Solana se llaman entre sí.
• Cómo funciona Proof of History en la arquitectura de Solana.

Para obtener las últimas especificaciones del protocolo sobre tamaños de cuenta, cálculos de alquiler y comportamiento del tiempo de ejecución, consulta directamente la documentación oficial de cuentas de Solana.