Explicación del modelo de cuentas de Solana

El Modelo de cuentas de Solana almacena saldos, código de programa, tenencias de tokens y estado de aplicaciones en cuentas separadas con reglas de propiedad explícitas. Esta guía en lenguaje claro explica el modelo para lectores generales antes de pasar a los campos, tipos de cuentas, exención de alquiler y ejemplos del mundo real.

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

Si vienes de Ethereum, el modelo de cuentas de Solana te parecerá invertido al principio. Esa reacción es el punto de partida correcto. El modelo mental que construiste en Ethereum no se traslada limpiamente, y tratar de forzarlo crea confusión en cada paso.

El modelo de cuentas de Solana es el sistema arquitectónico por el cual todo el estado on-chain se almacena en unidades de almacenamiento discretas llamadas cuentas. Cada saldo de billetera, programa, tenencia de token y registro de estado de aplicación reside en una cuenta separada con un propietario definido, un saldo de lamports y reglas explícitas que rigen quién puede leer o escribir en él. Nada existe en Solana fuera de una cuenta.

Piensa en Solana como un sistema global de archivo. Cada pieza de datos reside en un archivo separado llamado cuenta. Los programas son las aplicaciones que leen y escriben esos archivos, pero un programa solo puede modificar un archivo que posea. El entorno de ejecución aplica esas reglas de propiedad a nivel de protocolo, sin excepciones.

Este artículo cubre los cinco campos dentro de cada cuenta de Solana, los cinco tipos de cuentas distintos, cómo funcionan el alquiler (rent) y la exención de alquiler, qué son las Direcciones Derivadas de Programa (PDAs) y por qué existen, cómo se crean y cierran las cuentas, y por qué esta arquitectura hace posible el procesamiento paralelo de transacciones de Solana. Los programas de Solana están escritos en Rust (o C/C++), aunque frameworks como Anchor abstraen gran parte del código repetitivo de gestión de cuentas. Este artículo cubre la base conceptual que ambos requieren.

Modelo de cuentas de Solana: Anatomía de una cuenta

Una cuenta de Solana es una ranura de almacenamiento etiquetada en la red que contiene un saldo en lamports, una carga de datos arbitraria y un conjunto de campos de metadatos que definen quién la posee y qué puede hacer. En Solana, todos los datos, desde los saldos de billetera hasta el estado del programa y las tenencias de tokens, se almacenan en cuentas.

Los lamports son la denominación más pequeña de SOL, el token nativo de la red. Los lamports son a SOL lo que los céntimos son a un dólar, excepto con nueve decimales de precisión: 1 SOL equivale a 1.000.000.000 de lamports. Cada cuenta tiene un saldo de lamports que financia la existencia continuada de la cuenta en la red y representa valor transferible.

Cada cuenta de Solana contiene exactamente cinco campos:

• lamports (u64): El saldo de la cuenta en lamports. Este campo financia el alquiler y puede transferirse a otras cuentas.
• data (array de bytes): Almacenamiento binario sin procesar. En las cuentas ejecutables, este campo contiene bytecode compilado de BPF/SBF. En las cuentas de datos, contiene el estado estructurado de la aplicación. El tamaño máximo del campo de datos es de 10 MB según los parámetros actuales de mainnet.
• owner (Pubkey): La clave pública de 32 bytes del programa que tiene la autoridad exclusiva de escritura sobre el campo de datos de esta cuenta. Este es el campo más contraintuitivo para los desarrolladores de Ethereum. Tu dirección de billetera no te pertenece a nivel de protocolo; pertenece al Programa del Sistema. El tratamiento completo del campo propietario aparece en la sección de propiedad y autoridad de la cuenta.
• executable (bool): Un indicador booleano. Cuando es verdadero, el campo de datos contiene el bytecode del programa y la cuenta funciona como un programa. Cuando es falso, la cuenta almacena estado o tiene un saldo.
• rent_epoch (u64): Un campo obsoleto que rastreaba la época en la que se recaudó el alquiler por última vez. A partir de 2024, la recaudación de alquiler está obsoleta a favor del modelo de exención de alquiler por defecto. Este campo persiste en la estructura de la cuenta, pero ya no se utiliza activamente.

Así es como se ve una cuenta de billetera como estructura de datos:

{
  "lamports": 1000000000,
  "data": [],
  "owner": "11111111111111111111111111111111",
  "executable": false,
  "rent_epoch": 0
}

El campo propietario es un concepto a nivel de protocolo: el programa que controla el acceso de escritura al campo de datos. La autoridad es una convención separada almacenada dentro de datos gestionados por programas, como el campo de autoridad de transferencia dentro de una cuenta de token. No son lo mismo; la sección de propiedad establece esta distinción con precisión.

Los Cinco Tipos de Cuentas de Solana

Solana tiene cinco tipos de cuentas distintos, cada uno sirviendo un rol arquitectónico específico determinado por su campo propietario y su indicador ejecutable. El tipo no se almacena como un campo separado; se infiere de quién es el propietario de la cuenta y si contiene código ejecutable.

Cuentas propiedad del Sistema (Cuentas de Billetera)

Una cuenta propiedad del sistema contiene el saldo de SOL de un usuario y nada más. El propietario es siempre el Programa del Sistema (11111111111111111111111111111111), el indicador ejecutable es falso y el campo de datos está vacío. Cuando compartes tu dirección de billetera con Phantom o Solflare, estás compartiendo la dirección de una cuenta propiedad del sistema. La controlas firmando transacciones con tu clave privada, pero el Programa del Sistema es el propietario a nivel de protocolo.

Cuentas de Programa (Cuentas Ejecutables)

Una cuenta de programa es una cuenta ejecutable que contiene bytecode compilado de BPF/SBF. El indicador ejecutable es verdadero y el propietario es el Cargador BPF (BPF Loader). Las cuentas de programa no tienen estado por diseño; solo contienen código, nunca estado. En Ethereum, un contrato inteligente almacena tanto su código como su estado en una única dirección de contrato. En Solana, el código reside en una cuenta de programa y el estado reside en cuentas de datos separadas, siempre almacenadas aparte.

Las cuentas de programa pueden almacenar código ejecutable, con executable = true y bytecode BPF/SBF en el campo de datos. Las cuentas de datos no ejecutables tienen executable = false y almacenan estado en su lugar.

Cuentas de Datos (Cuentas propiedad de programas)

Una cuenta de datos es una cuenta no ejecutable propiedad de un programa específico que almacena el estado del programa en su campo de datos. El indicador ejecutable es falso. El propietario es el programa que creó y gestiona la cuenta. El saldo de tu token USDC, una posición de préstamos DeFi, un registro de metadatos NFT: cada uno reside en su propia cuenta de datos dedicada propiedad del programa relevante.

Las cuentas de programas nativos son programas integrados desplegados en direcciones fijas durante la génesis de la red. Incluyen el Programa del Sistema, el Cargador BPF, el Programa de Votación y el Programa de Participación (Stake Program). Estos son programas de infraestructura central que los usuarios no pueden reemplazar ni actualizar. Su indicador ejecutable es verdadero.

Cuentas Sysvar

Las cuentas Sysvar son cuentas de solo lectura pre-cargadas por el entorno de ejecución de Solana que dan a los programas acceso al estado actual de la red. Piensa en las cuentas sysvar como un tablón de anuncios del gobierno en un juzgado: de lectura pública, mantenido por una fuente autorizada, pero ninguna parte privada puede modificarlas. La sysvar Clock en SysvarC1ock11111111111111111111111111111111 proporciona la marca de tiempo y el número de ranura del bloque actual. La sysvar Rent proporciona los parámetros actuales de alquiler.

Los programas son sin estado en Solana. Todo el estado reside en las cuentas de datos que poseen y controlan. Esta separación de la lógica del estado es la decisión de diseño que hace posible todo lo demás en este artículo.

Programas vs. Cuentas de datos: La separación de la lógica y el estado

Los programas de Solana son sin estado. No contienen datos propios, y cada pieza de estado sobre la que operan reside en cuentas de datos separadas que se les pasan en tiempo de ejecución.

Piensa en un programa de Solana como el software de procesamiento de transacciones de un banco, y en las cuentas de datos como los registros de cuentas individuales de los clientes. El software sabe cómo procesar depósitos y retiros, pero el saldo real vive en el archivo del cliente, no dentro del propio software. En Ethereum, el equivalente es un banco donde el software y el registro de cada cliente comparten la misma sala cerrada, con el programa y su estado inseparables en una única dirección.

Cuatro propiedades definen cómo los programas de Solana interactúan con las cuentas:

• Los programas procesan instrucciones y leen o escriben en cuentas que se les pasan en el momento de la llamada. No tienen estado propio.
• Los programas son inmutables una vez desplegados, a menos que el desarrollador haya elegido el cargador actualizable en el momento del despliegue.
• Solo el programa propietario de una cuenta de datos puede modificar el campo de datos de esa cuenta. Cualquier usuario puede llamar a un programa, pero el acceso de escritura a cualquier cuenta está restringido por la propiedad.
• El indicador executable impone esta distinción a nivel de protocolo y no puede cambiarse después del despliegue.

Los programas de Solana son sin estado, pero el sistema de Solana en su conjunto tiene estado. El estado persiste; reside en las cuentas de datos. La distinción es que el estado siempre es externo al programa, nunca incluido dentro de él.

Esta separación tiene una consecuencia en el rendimiento. Dado que cada transacción debe declarar qué cuentas leerá o escribirá antes de que comience la ejecución, el runtime Sealevel puede identificar transacciones no superpuestas y ejecutarlas simultáneamente. La explicación completa de cómo el modelo de cuentas permite la ejecución paralela se presenta a continuación.

Propiedad y Autoridad de las Cuentas: Quién Controla Qué en Solana

El campo owner (propietario) en una cuenta de Solana identifica el programa que tiene permiso exclusivo para modificar los datos de esa cuenta. Solo ese programa, a nivel de protocolo, puede escribir en el campo de datos.

El campo owner almacena una clave pública de programa de 32 bytes. Para las cuentas de billetera, el propietario es el Programa del Sistema (System Program). Para las cuentas de token, el propietario es el Programa SPL Token (SPL Token Program). Para las cuentas de datos personalizadas, el propietario es el programa que las creó. La propiedad se establece en la creación de la cuenta y es impuesta por el runtime de Solana en cada transacción.

Considera una caja de seguridad en un banco. El banco es el propietario de la caja y es la única entidad que puede abrir y modificar físicamente su contenido. Tú tienes una llave que te permite dar instrucciones al banco sobre qué hacer con tu caja, pero solo el banco toca el contenido. En Solana, el programa es el banco, y tú eres el titular de la cuenta con una llave.

La distinción entre propietario (owner) y autoridad (authority) confunde a muchos desarrolladores de Ethereum:

• Propietario (Owner) (campo de protocolo): El ID del programa que puede modificar el campo data de la cuenta. Se establece en la creación de la cuenta. Impuesto por el runtime de Solana, no por la lógica de ningún programa.
• Autoridad (Authority) (convención de datos): Una clave pública almacenada dentro del campo data de la cuenta por el programa propietario. Autoriza operaciones específicas dentro de la lógica de ese programa. Impuesta por el propio programa, no por el runtime.

Para una cuenta de token USDC, el Programa de Tokens (Token Program) es el propietario y puede modificar el saldo almacenado en el campo de datos. Tu billetera es la autoridad de transferencia (transfer authority), una clave pública registrada dentro del campo de datos que el Programa de Tokens verifica antes de ejecutar una transferencia. Estas son claves diferentes que realizan funciones diferentes. Confundirlas es uno de los errores más comunes en el desarrollo nuevo de Solana.

Alquiler de Cuentas de Solana y Exención de Alquiler Explicados

El alquiler (Rent) en Solana es una tarifa de almacenamiento, denominada en lamports, que se cobra a las cuentas para compensar a los validadores por mantener el estado On-Chain. Las cuentas que mantienen un saldo mínimo de lamports, el umbral de exención de alquiler, están permanentemente exentas de los cargos de alquiler y nunca serán eliminadas por el runtime.

¿Qué es el Alquiler en Solana?

Los validadores deben almacenar todo el estado de cuenta activo en memoria. Un número ilimitado de cuentas con saldo cero sería un vector de denegación de servicio contra la red, por lo que Solana requiere que las cuentas mantengan un saldo mínimo de lamports como compromiso para pagar los costos de almacenamiento. El modelo de alquiler original cobraba tarifas por época proporcionales al tamaño de los datos, con cuentas por debajo del mínimo sujetas a recolección de basura. Ese modelo ha sido obsoleto.

Según los parámetros actuales de la Mainnet de Solana (formalizados en SIMD-0084), todas las cuentas nuevas deben estar exentas de alquiler en el momento de su creación. El campo rent_epoch en la estructura de la cuenta es ahora un campo heredado.

Para que tu cuenta esté exenta de alquiler, finánciala con al menos el saldo mínimo de lamports para su tamaño de datos al enviar la transacción de creación. Con los parámetros de red actuales:

• Una cuenta de 0 bytes (billetera): aproximadamente 890.880 lamports (~0.00089 SOL)
• Una cuenta de 165 bytes (cuenta de token estándar): aproximadamente 2.039.280 lamports (~0.00204 SOL)
• Una cuenta de datos de 1.024 bytes: aproximadamente 7.180.800 lamports (~0.00718 SOL)

Estos valores son aproximados y están sujetos a cambios en los parámetros del runtime. Calcula el mínimo exacto actual utilizando la CLI de Solana o el método RPC getMinimumBalanceForRentExemption:

solana rent 0       # exención de alquiler para una cuenta de 0 bytes
solana rent 165     # exención de alquiler para una cuenta de token estándar

La exención de alquiler funciona como un depósito de garantía en una unidad de almacenamiento. Bloqueas un saldo mínimo de lamports para garantizar la existencia de la cuenta en la red. A diferencia de una tarifa, este depósito es totalmente recuperable. Cuando cierras la cuenta, esos lamports te son devueltos.

La denominación de lamport utilizada en todos los cálculos de alquiler se define en la sección de anatomía de la cuenta. Para hacer que una cuenta de datos esté exenta de alquiler cuando tu programa la crea, llama a getMinimumBalanceForRentExemption(dataSize) en el lado del cliente antes de construir la transacción de creación, y luego incluye esa cantidad de lamports en la instrucción.

Solana vs. Ethereum vs. Bitcoin: Comparación de los modelos de cuentas

¿Cuál es la diferencia entre las cuentas de Solana y las de Ethereum?

En Ethereum, los contratos inteligentes agrupan su código y su estado juntos en una dirección. Una cuenta de contrato contiene tanto la lógica como los datos sobre los que opera. En Solana, el código y el estado están siempre en cuentas separadas: los programas (lógica) residen en cuentas ejecutables, y todo el estado reside en cuentas de datos distintas propiedad de esos programas. Esta separación es la base arquitectónica de todo lo que Solana hace de manera diferente.

Bitcoin adopta un enfoque completamente diferente, utilizando un modelo UTXO (Unspent Transaction Output). Los UTXO son como cheques no gastados en una chequera: cada transacción consume salidas existentes y crea otras nuevas. No hay una cuenta persistente que mantenga un saldo a lo largo del tiempo. Tu saldo es la suma de las salidas no gastadas asociadas a tus claves. El modelo de Bitcoin es anterior al concepto de estado programable, por lo que sus capacidades de Contrato inteligente se limitan a Bitcoin Script.

Las redes compatibles con EVM, incluidas Ethereum, Polygon, BNB Chain y Avalanche C-Chain, comparten el mismo modelo de cuenta del que se desvía Solana. Una comparación cubre todas ellas.

En Ethereum, las billeteras de los usuarios se denominan Cuentas Poseídas Externamente (EOA). En Solana, el equivalente es una cuenta propiedad del sistema controlada por un par de claves; el mecanismo es similar, pero el campo propietario se establece explícitamente en el Programa del Sistema en lugar de ser implícito.

Lo que los desarrolladores de Ethereum deben desaprender

Se requieren tres cambios de modelo mental antes de escribir un programa de Solana que funcione:

1. Los programas no mantienen su propio estado. Las cuentas de datos sí. Deje de buscar el estado en la dirección del programa.
2. El propietario de su billetera no es usted a nivel de protocolo. Usted controla la cuenta firmando; el Programa del Sistema posee el campo de datos.
3. El almacenamiento no es gratuito. Cada cuenta de datos requiere un depósito de lamports para exención de alquiler. Presupueste este coste al diseñar programas que creen cuentas.

La estricta separación de código y estado de Solana es el requisito previo para la ejecución paralela, una conexión explorada en su totalidad en la sección Sealevel y ejecución paralela.

Cómo el Modelo de Cuenta Impulsa la Velocidad de Solana: Sealevel y Ejecución Paralela

El modelo de cuenta de Solana permite el procesamiento paralelo porque cada transacción debe declarar explícitamente la lista completa de cuentas que leerá o escribirá antes de que comience la ejecución. Sealevel, el tiempo de ejecución paralelo de contratos inteligentes de Solana, utiliza esas declaraciones anticipadas para identificar transacciones que tocan diferentes cuentas y ejecutarlas simultáneamente.

Aquí está la cadena causal, paso a paso:

1. Una transacción de Solana incluye una lista completa de todas las cuentas a las que accederá, cada una marcada como solo lectura o lectura/escritura, antes de que ocurra cualquier ejecución.
2. Sealevel inspecciona todas las transacciones pendientes en la ranura actual.
3. Las transacciones que comparten al menos una cuenta de lectura/escritura se secuencian. Las transacciones que acceden a cuentas completamente diferentes se identifican como no conflictivas.
4. Las transacciones no conflictivas se ejecutan simultáneamente en múltiples núcleos de CPU.

El EVM de Ethereum ejecuta transacciones secuencialmente contra un estado global compartido. Dado que el estado del contrato está co-ubicado con el código del contrato, determinar conflictos de lectura/escritura requeriría ejecutar la transacción primero, haciendo imposible la programación estática antes de la ejecución.

Piense en Sealevel como un supermercado con muchos carriles de caja. Cada transacción es un comprador con una lista declarada de artículos. Siempre que dos compradores no busquen el mismo artículo, pasan por caja simultáneamente. Solana sabe de antemano exactamente lo que necesita cada transacción, porque el modelo de cuenta obliga a esa declaración por adelantado.

El Proof of History (PoH), inventado por el cofundador de Solana Anatoly Yakovenko, proporciona un reloj criptográfico que permite a los validadores acordar el orden de las transacciones sin coordinación en tiempo real. Solana utiliza Proof of Stake (PoS) para el consenso, donde los validadores participan en staking de SOL para participar en la producción de bloques, y PoH como capa de temporización. Combinada con las declaraciones anticipadas de cuentas del modelo de cuenta, esta arquitectura permite a Sealevel procesar transacciones no conflictivas en paralelo sin esperar la confirmación a nivel de red en cada paso.

El modelo de cuenta no es un esquema de almacenamiento de forma aislada. Es el requisito previo para el paralelismo, y es la raíz técnica de la ventaja de rendimiento y escalabilidad de Solana.

Ejemplos del Mundo Real: Cuentas de Tokens, NFTs y DeFi en Solana

Cada activo en Solana, un balance de token, un NFT, una posición Largo, es una cuenta de Solana con un diseño de datos específico. La arquitectura abstracta descrita anteriormente se manifiesta en tres patrones que cada usuario de Solana encuentra.

Cuentas de Tokens SPL

Los tokens SPL, el equivalente en Solana de los tokens ERC-20 de Ethereum, son administrados por el Programa de Tokens SPL, que posee todas las cuentas de tokens en la red. Su dirección de billetera solo contiene SOL (lamports). Cada token que posee, ya sea USDC, JTO, BONK o cualquier otro, reside en su propia cuenta de token dedicada propiedad del Programa de Tokens SPL.

El campo de datos de una cuenta de token almacena tres piezas de información: la dirección de emisión del token (qué token contiene esta cuenta), la clave pública de la autoridad propietaria (su dirección de billetera, que autoriza transferencias) y el balance de token actual. En Ethereum, todos los balances ERC-20 para un token dado residen dentro del mapeo interno del contrato del token. En Solana, cada par (usuario, token) requiere su propia cuenta dedicada.

Es por eso que las billeteras de Solana le piden que cree una cuenta de token al recibir un token nuevo por primera vez. Esa creación requiere un depósito de lamports exento de alquiler de aproximadamente 0.00204 SOL para la cuenta estándar de 165 bytes con los parámetros de red actuales.

Una Cuenta de Token Asociada (ATA) es una cuenta de token cuya dirección es un PDA derivado determinísticamente de la dirección de su billetera y la dirección de emisión del token. Debido a que la dirección es determinista, cualquier protocolo puede calcular dónde debería estar su cuenta de USDC sin almacenar una tabla de búsqueda. Las ATAs son el tipo de cuenta de token estándar utilizado por prácticamente todas las billeteras y protocolos de Solana.

Las ATAs son una aplicación de la derivación de PDA. Puede tener múltiples cuentas de token para la misma emisión, pero su ATA es la canónica que los protocolos utilizan por defecto.

Un NFT en Solana consta de al menos dos cuentas: una Cuenta de Emisión propiedad del Programa de Tokens que define el suministro del token como exactamente 1, y una Cuenta de Metadatos propiedad del Programa de Metadatos de Tokens de Metaplex que almacena el nombre, símbolo, URI de imagen y configuración de regalías del NFT. La imagen del NFT no se almacena On-Chain; solo la URI que apunta a ella reside en la cuenta de metadatos. El balance del token (1 NFT) se almacena en una cuenta de token, idéntica a cualquier otro token SPL.

Los protocolos de Criptomoneda en Solana, incluidos los exchanges descentralizados, las plataformas de préstamos y las piscinas de liquidez, almacenan cada posición de usuario, el estado de la piscina y la configuración del protocolo en cuentas de datos dedicadas, con PDAs propiedad del programa controlando los fondos combinados de forma autónoma.

Por qué el Modelo de Cuenta de Solana es Importante para SOL

Nota: Esta sección explica cómo el modelo de cuenta de Solana afecta la utilidad técnica de SOL. Nada en este artículo constituye asesoramiento financiero o una recomendación de inversión.

El modelo de cuenta no es solo una preocupación para los desarrolladores. SOL, disponible en los principales exchanges de Criptomoneda, sirve como el token de utilidad nativo de la red. El modelo de cuenta es el mecanismo principal a través del cual se demanda y utiliza SOL a nivel de red.

SOL se utiliza en el modelo de cuenta a través de tres mecanismos distintos:

Depósitos para exención de alquiler: Cada cuenta en Solana debe mantener un balance de lamports para existir en la red. Con millones de cuentas de tokens, cuentas de datos de programas, registros NFT y cuentas de estado DeFi activas en cualquier momento, esto crea una demanda base persistente de SOL. Estos lamports se bloquean en las cuentas y se eliminan de la circulación líquida mientras las cuentas permanezcan abiertas.

Comisiones de transacción: Cada transacción que crea o modifica cuentas paga una tarifa base en lamports. Una parte de cada comisión se quema según la estructura de comisiones actual, reduciendo el suministro circulante con cada transacción.

Participación en staking de validadores: Los validadores participan en staking de SOL para participar en el consenso bajo el mecanismo de Prueba de Participación de Solana, obteniendo recompensas por validar las transiciones de estado de las cuentas en la red.

A medida que crece la actividad On-Chain, más protocolos DeFi, más colecciones NFT, más lanzamientos de tokens, el número de cuentas crece proporcionalmente. Más cuentas requieren más SOL bloqueados en depósitos de exención de alquiler.

Los lamports bloqueados en cuentas con exención de alquiler funcionan como depósitos de garantía retenidos por la red: no se gastan, pero se comprometen mientras esas cuentas permanezcan abiertas. Cuando las cuentas se cierran, esos lamports regresan a sus propietarios.

Recursos relacionados con la arquitectura de Solana

Las cuentas de tokens son más fáciles de entender junto con la Biblioteca de Programas de Solana (SPL), mientras que la concurrencia se explica en la guía sobre el motor de procesamiento paralelo Sealevel de Solana. Los lectores pueden revisar la página de precios de SOL;) y los usuarios que evalúen productos relacionados con el staking pueden revisar por separado SOL Earn,), incluidos sus términos y riesgos actuales.

Preguntas frecuentes: Modelo de cuentas de Solana

¿Cuál es la diferencia entre las cuentas de Solana y las cuentas de Ethereum?

En Ethereum, un contrato inteligente almacena tanto su código como su estado en una sola dirección. En Solana, el código y el estado siempre están en cuentas separadas: los programas son cuentas ejecutables sin estado, y todo el estado reside en cuentas de datos distintas propiedad de esos programas. Esta separación permite a Sealevel ejecutar transacciones no conflictivas en paralelo, lo cual no es posible con el modelo de estado colocalizado de Ethereum.

¿Qué es el alquiler en Solana y cómo funciona?

El alquiler en Solana es el coste de almacenar datos en la red, denominado en lamports. En lugar de pagar comisiones continuas, las cuentas deben depositar un saldo mínimo de lamports por adelantado, el umbral de exención de alquiler, para evitar ser purgadas por el tiempo de ejecución. El depósito es recuperable: cuando la cuenta se cierra, los lamports regresan al propietario. Para una cuenta de token estándar de 165 bytes, el depósito es de aproximadamente 0.00204 SOL según los parámetros actuales de la red.

¿Qué es una Dirección Derivada de Programa (PDA) en Solana?

Una PDA es una dirección de cuenta de Solana derivada de forma determinista de un ID de programa y un conjunto de valores semilla. No tiene una clave privada correspondiente, por lo que solo el programa que la derivó puede autorizar transacciones en su nombre a través de Invocación entre Programas (CPI). Las PDAs otorgan a los programas control autónomo y sin confianza sobre las cuentas, un requisito para protocolos DeFi, intermediarios NFT y Cuentas de Tokens Asociadas.

¿Cómo habilita el modelo de cuentas de Solana el procesamiento paralelo?

Cada transacción de Solana debe declarar la lista completa de cuentas que leerá o escribirá antes de la ejecución. Sealevel, el tiempo de ejecución de contratos inteligentes paralelos de Solana, utiliza esas declaraciones para identificar transacciones no conflictivas y ejecutarlas simultáneamente en múltiples núcleos de CPU. Esta programación estática solo es posible porque el código y el estado residen en cuentas separadas y explícitamente propiedad, lo que hace que los conflictos de lectura/escritura sean detectables antes de que comience la ejecución.

¿Qué es el campo propietario (owner) en una cuenta de Solana?

El campo propietario es una clave pública de 32 bytes que identifica el programa que tiene autoridad para modificar el campo de datos de la cuenta. Para las cuentas de billetera, el propietario es el Programa del Sistema. Para las cuentas de tokens, el propietario es el Programa de Tokens SPL. El campo propietario es un concepto a nivel de protocolo aplicado por el tiempo de ejecución de Solana. Es distinto del campo "autoridad" que se encuentra dentro de ciertas cuentas de datos gestionadas por programas, como las cuentas de tokens.

¿Cómo se utiliza SOL en el modelo de cuentas?

SOL se utiliza en el modelo de cuentas a través de tres mecanismos: cada cuenta debe mantener un saldo de lamports (SOL) para existir en la red; la creación de cuentas requiere SOL para financiar el depósito de exención de alquiler; y los validadores que procesan y almacenan el estado de las cuentas deben participar en staking de SOL para participar en el consenso. A medida que la red crece, la demanda estructural de SOL crece con ella.

¿Qué es Sealevel y cómo se relaciona con las cuentas?

Sealevel es el tiempo de ejecución de contratos inteligentes paralelos de Solana. Puede ejecutar múltiples transacciones simultáneamente porque el modelo de cuentas de Solana requiere que cada transacción pre-declare qué cuentas leerá o escribirá. Sealevel utiliza esas declaraciones para identificar transacciones no conflictivas y programarlas para ejecutarlas en paralelo. Sin las declaraciones por adelantado del modelo de cuentas, esta programación estática sería imposible.

¿Cuál es la diferencia entre una cuenta de billetera y una cuenta de programa en Solana?

Una cuenta de billetera es una cuenta propiedad del sistema con un campo de datos vacío que solo contiene un saldo de SOL, controlado por un par de claves. Una cuenta de programa es una cuenta ejecutable con executable = true que contiene bytecode BPF/SBF compilado; es propiedad del cargador BPF y no contiene estado propio. La tabla de tipos de cuenta en la sección Cinco tipos de cuentas de Solana muestra las cinco variantes lado a lado.

¿Cuántas cuentas puede referenciar una transacción de Solana?

Una sola transacción de Solana puede referenciar hasta 64 cuentas según los parámetros actuales de la red principal, aumentado desde las 32 originales a través de Tablas de Búsqueda de Direcciones (Address Lookup Tables). Cada cuenta debe declararse de solo lectura o de lectura/escritura antes de que comience la ejecución. Esta declaración por adelantado es lo que permite a Sealevel programar la ejecución en paralelo sin ejecutar transacciones primero para detectar conflictos.

¿Puede una cuenta de Solana contener varios tokens?

No. Cada tipo de token SPL requiere su propia cuenta de token dedicada. Una dirección de billetera solo contiene SOL; cada token adicional requiere una cuenta de token separada vinculada a la billetera a través de su campo de autoridad. Es por eso que las billeteras de Solana te piden que crees una nueva cuenta de token al recibir un token que no has tenido antes, y por qué esa creación cuesta un pequeño depósito de lamports exento de alquiler.

Conclusiones clave

• Todo el estado On-Chain de Solana reside en una cuenta con cinco campos: lamports, data, owner, executable, rent_epoch.
• Los programas no tienen estado. Todo el estado reside en cuentas de datos separadas que los programas poseen y controlan.
• Las cuentas requieren un depósito de lamports (exención de alquiler) para persistir en la red. El depósito es recuperable cuando la cuenta se cierra.
• Las PDA son direcciones sin clave privada, derivadas de forma determinista de un ID de programa y semillas, solo firmables por el programa que las creó a través de CPI.
• Cada transacción declara su lista de acceso a cuentas por adelantado. Sealevel utiliza esas declaraciones para ejecutar transacciones no conflictivas simultáneamente.

Próximos pasos

• Para especificaciones de implementación, consulte la documentación de cuentas de Solana en docs.solana.com.
• Los desarrolladores que creen su primer programa de Solana pueden empezar con el framework Anchor, que abstrae gran parte del código repetitivo de gestión de cuentas (los programas se escriben en Rust o C/C++).
• Para recetas de código prácticas y ejemplos funcionales en JavaScript/TypeScript, el Solana Cookbook proporciona material de referencia práctico.