En Solana, casi todo el estado en cadena se representa a través de cuentas. A diferencia de las arquitecturas de blockchain tradicionales que acoplan estrechamente el código y el almacenamiento, Solana separa los programas ejecutables del almacenamiento de estado. Este diseño hace que el modelo de cuenta de Solana sea uno de los conceptos más importantes para los desarrolladores que construyen en la red.
Entender los campos de cuenta es esencial al trabajar con billeteras, tokens SPL, NFTs, PDAs o protocolos DeFi.
La Estructura Principal de una Cuenta de Solana
Una cuenta de Solana se representa típicamente de forma interna como:
pub struct Account {
pub lamports: u64,
pub data: Vec<u8>,
pub owner: Pubkey,
pub ejecutable: bool,
pub rent_epoch: Epoch,
}
Cada campo tiene un propósito diferente dentro del tiempo de ejecución de Solana.
Lamports
El campo
lamports
almacena el saldo de SOL asociado con la cuenta.
pub lamports: u64
Los lamports son la unidad más pequeña de SOL.
1 SOL = 1,000,000,000 lamports
Esto es conceptualmente similar a:
- Wei en Ethereum
- Satoshi en Bitcoin
Los lamports se utilizan para:
- Comisiones de transacción
- Exención de alquiler
- Mantener saldos de SOL
- Financiar nuevas cuentas
Por ejemplo:
5 SOL = 5,000,000,000 lamports
Cada cuenta en Solana debe mantener un cierto saldo para permanecer activa en la cadena.
Datos
El campo
data
almacena datos binarios arbitrarios.
pub data: Vec<u8>
Aquí es donde se almacena el estado de la aplicación.
En Solana, los programas son ejecutables sin estado, mientras que las cuentas de datos mantienen el estado mutable por separado. Debido a esta arquitectura, casi cada aplicación descentralizada depende en gran medida de los diseños de datos de las cuentas.
Ejemplos de datos almacenados incluyen:
Cuentas de Token SPL
Una cuenta de token típicamente almacena:
- Dirección del mint
- Dirección del propietario
- Cantidad de tokens
- Delegación
Metadatos de NFT
Las cuentas de metadatos de NFT pueden contener:
- Nombre
- Símbolo
- URI de metadatos
- Configuración de regalías
- Direcciones del creador
Protocolos DeFi
Los grupos de liquidez y AMMs a menudo almacenan:
- Reservas del grupo
- Estructuras de tarifas
- Oferta de LP
- Configuraciones administrativas
La mayoría de los programas de Solana serializan los datos de la cuenta utilizando formatos como:
- Borsh
- Serialización de Anchor
- Diseños de bytes crudos
Propietario
El campo
owner
especifica qué programa controla la cuenta.
pub owner: Pubkey
Este es uno
de los mecanismos de seguridad más importantes en Solana.
Solo el programa propietario puede modificar el campo de datos de la cuenta.
Por ejemplo:
Programa del Sistema
11111111111111111111111111111111
El Programa del Sistema posee cuentas estándar de billetera SOL.
Programa de Token SPL
El Programa de Token SPL posee:
- Cuentas de tokens
- Cuentas de mint
Programas Personalizados
Si un desarrollador crea una cuenta PDA para un protocolo personalizado, el campo de propietario generalmente se establece en el ID del programa del proyecto.
Este modelo de propiedad crea límites estrictos de ejecución entre programas y previene modificaciones no autorizadas del estado.
Ejecutable
El campo
executable
determina si la cuenta contiene código de programa ejecutable.
pub executable: bool
Si el valor es:
true
la cuenta se considera una cuenta de programa.
Las cuentas de programa almacenan bytecode BPF compilado que puede ser ejecutado por el tiempo de ejecución de Solana.
Ejemplos típicos incluyen:
Tipo de CuentaexecutableCuenta de WalletfalseCuenta de TokenfalseCuenta PDAfalseCuenta de Programa true
La mayoría de las cuentas en Solana son cuentas de datos no ejecutables.
Época de Alquiler
El campo
rent_epoch
está relacionado con el sistema de alquiler de Solana.
pub rent_epoch: Epoch
Debido a que el almacenamiento en la cadena consume recursos de los validadores, Solana introdujo originalmente el alquiler para prevenir el crecimiento ilimitado del almacenamiento.
Las cuentas con saldos insuficientes podrían eventualmente ser reclamadas por la red.
Hoy en día, la mayoría de las aplicaciones evitan completamente la recolección de alquiler al hacer que las cuentas estén exentas de alquiler.
Los desarrolladores suelen calcular el saldo mínimo requerido utilizando:
getMinimumBalanceForRentExemption(space)
Una vez que una cuenta tiene suficientes lamports para satisfacer los requerimientos de exención de alquiler, puede mantenerse activa permanentemente.
Direcciones de Cuenta y Claves Públicas
Al utilizar las API RPC, los desarrolladores comúnmente ven un adicional
campo:
{
"pubkey": "...",
"account": {
"lamports": 123,
"owner": "...",
"data": "...",
"executable": false,
"rentEpoch": 123
}
}
La
pubkey
es la dirección de la cuenta.
Curiosamente, la clave pública no se almacena dentro de la estructura de la cuenta en sí. En cambio, Solana asigna internamente las direcciones a las estructuras de datos de la cuenta.
Conceptualmente, esto se asemeja a:
HashMap<Pubkey, Account>
Por qué Solana utiliza esta arquitectura
El modelo de cuenta es una de las razones por las que Solana logra un rendimiento extremadamente alto.
Antes de ejecutar una transacción, Solana requiere que la transacción sea
declara qué cuentas serán leídas o escritas.
Esto permite que el tiempo de ejecución determine:
- Qué transacciones entran en conflicto
- Qué transacciones pueden ejecutarse en paralelo
- Qué accesos al estado están aislados
Como resultado, Solana puede procesar muchas transacciones independientes simultáneamente en lugar de ejecutar todo secuencialmente.
Este modelo de ejecución paralela es fundamentalmente diferente de muchas cadenas de bloques tradicionales.
