El Blueprint de Cuentas
Las cuentas son la única abstracción de almacenamiento de Solana: cada billetera, binario de programa, cuenta de token y registro de aplicación es el mismo objeto en la cadena. Una vez que se ve esa uniformidad (cinco campos, un propietario, bloqueos explícitos), el alquiler, las CPI, los PDA y Sealevel se entienden como consecuencias de una única decisión de diseño, no como casos especiales.
Fundamentos del Modelo de Cuentas es la entrada práctica; Anatomía de una Cuenta, Alquiler y Exención de Alquiler, Propiedad y Permisos de Cuentas, Estado Propiedad del Programa y Cuentas del Sistema vs. Cuentas de Programa se centran en un mecanismo cada uno. Esta página se sitúa debajo: por qué existe un solo tipo de cuenta y cómo eso permite la ejecución en paralelo.
Resumen
- Solana almacena todo el valor y estado en la cadena como cuentas, registros de forma fija con
lamports,data,owner,executableyrent_epoch, y solo el programa propietario puede mutardata. - Por Qué Importa: Una abstracción significa un modelo de permisos, una regla de financiación (alquiler) y una lista de bloqueos; esa lista es lo que permite a Sealevel ejecutar transacciones no superpuestas en paralelo.
- Conceptos Clave: abstracción de cuenta única, escrituras del propietario, propiedad del sistema vs. propiedad del programa, cuentas ejecutables, exención de alquiler, creación de cuenta (asignar + asignar propietario + financiar), PDA, listas explícitas de cuentas.
- Cuándo Usar: Al diseñar dónde vive el estado, depurar errores de propietario incorrecto o cuenta faltante, dimensionar el alquiler, explicar Solana a compañeros nativos de EVM, o razonar sobre qué transacciones pueden ejecutarse una al lado de la otra.
- Limitaciones / Compensaciones: Debe dimensionar y financiar las cuentas por adelantado, declarar cada cuenta que una transacción toca y dividir el estado "caliente" entre direcciones para el paralelismo; no hay una bolsa de almacenamiento global oculta dentro de un programa.
- Temas Relacionados: anatomía de cuentas, alquiler, permisos de propiedad, estado propiedad del programa, cuentas del sistema vs. cuentas de programa, programación de Sealevel.
Fundamentos
Solana no da un tipo a las billeteras, otro a los contratos y un tercero al almacenamiento. Le da un solo tipo de cuenta en una dirección de clave pública, interpretada por cuántos lamports contiene, qué programa la posee, si es ejecutable y qué bytes residen en su búfer de datos.
Esa elección es deliberada. Un registro uniforme mantiene AccountsDB simple, hace que las comprobaciones de permisos sean locales a una única clave pública de owner, y convierte "¿qué puede tocar esta transacción?" en una lista finita de direcciones que el cliente debe declarar. La programación paralela se convierte en un problema de grafos sobre esas direcciones, no en una suposición sobre lo que un programa podría leer más tarde.
Cada cuenta expone los mismos cinco campos principales:
| Campo | Rol |
|---|---|
lamports | Saldo de SOL en lamports (financiación + tarifas + depósito de alquiler) |
data | Búfer de bytes opaco (vacío para muchas billeteras; estructurado para estado de aplicaciones) |
owner | Programa ID permitido para escribir data y aplicar reglas del lado del propietario |
executable | true si esta cuenta es código de programa cargable |
rent_epoch | Campo heredado para el seguimiento del alquiler; las cuentas exentas de alquiler se sientan efectivamente en la época máxima |
Piense en el estado global como un mapa de dirección a este registro, no como especies separadas para "contratos con almacenamiento" y "EOA con saldos":
Dirección (Pubkey)
|
v
+------------------+
| lamports | <- saldo / depósito de alquiler
| data: [u8] | <- vacío, diseño Borsh, o bytes del programa
| owner: Pubkey | <- quién puede escribir datos
| executable: bool | <- programa vs datos
| rent_epoch | <- marcador heredado / exento
+------------------+Escrituras del propietario es la regla de seguridad central: solo el programa nombrado en owner puede mutar los data de esa cuenta. Otros programas pueden leer una cuenta si se les pasa, y pueden mover lamports bajo reglas específicas, pero no pueden reescribir los bytes de otro programa. Los firmantes demuestran "quién solicitó esto"; el campo propietario demuestra "qué programa puede cambiar este almacenamiento".
Las billeteras ordinarias son típicamente propiedad del sistema: el Programa del Sistema como propietario, executable falso, y generalmente data vacío. El estado útil de la billetera es el saldo de lamports (los saldos de tokens viven en otras cuentas). El estado de la aplicación vive en cuentas propiedad del programa cuyo propietario es su ID de programa y cuyo búfer contiene un diseño que el programa entiende. Los programas en sí mismos son cuentas con executable: true, propiedad de un cargador, que contienen bytecode en lugar de campos de aplicación.
Esa división (código en cuentas ejecutables, estado duradero en cuentas de datos) es por qué los programas de Solana se llaman sin estado: el ejecutable no tiene un mapa de almacenamiento privado; cada campo duradero vive en otra dirección que su instrucción debe nombrar.
Mecánicas e Interacciones
Crear una cuenta son tres trabajos en un solo flujo
Nada útil existe en una dirección no utilizada hasta que algo asigna espacio, asigna un propietario y financia el mínimo exento de alquiler para ese tamaño. El Programa del Sistema generalmente realiza el trabajo del ciclo de vida; su programa (u otro propietario) luego interpreta el búfer.
Conceptualmente:
pagador (propiedad del sistema) nueva cuenta
+----------------+ +------------------+
| lamports: $$$ | --financiar alquiler--> | lamports: min |
| data: [] | | data: [0; N] |
| owner: Sistema | --asignar N-----> | owner: TuProg |
+----------------+ --asignar propietario--> | executable: false|
+------------------+La exención de alquiler es un depósito de lamports escalado por tamaño: un data más grande bloquea más SOL en la cuenta. La práctica de producción financia ese depósito una vez para que la cuenta permanezca activa; cerrar bajo las instrucciones correctas devuelve esos lamports a un destinatario. La falta de financiación no es una advertencia leve: las cuentas no exentas no persisten como requiere el estado de producción.
Propiedad del sistema vs. propiedad del programa vs. ejecutable
Tres roles cotidianos comparten la misma estructura:
- Billetera propiedad del sistema / pagador de tarifas - contiene SOL; el Programa del Sistema transfiere y crea; no hay esquema de aplicación en
data. - Cuenta de datos propiedad del programa - contiene estado estructurado; solo su programa escribe
data; a menudo un PDA para direccionamiento determinista. - Cuenta de programa ejecutable - propiedad del cargador,
executable: true; contiene o apunta a bytecode del programa (los cargadores actualizables a menudo separan la identidad del programa de una cuenta ProgramData que almacena los bytes).
El modelo mental es: la identidad es la dirección, el permiso es el propietario, el significado es el diseño de data, y "¿es esto código?" es el indicador executable. El propietario es siempre un ID de programa; una clave pública de administrador suele ser un campo dentro del búfer que su programa comprueba por sí mismo.
PDA: direcciones controladas por programa sin claves privadas
Una dirección derivada de programa (PDA) sigue siendo solo una dirección de cuenta. Se deriva de semillas y un ID de programa para que ninguna clave privada ordinaria pueda firmar por ella; el programa propietario puede autorizarla a través de semillas en CPI. Los PDA responden cómo un programa mantiene bóvedas, configuraciones y estado por usuario sin una clave secreta en cadena. Los detalles de semillas y "bump" pertenecen a otra parte; aquí, un PDA no es un segundo tipo de cuenta, solo una convención de dirección y firma sobre el mismo registro.
Listas explícitas de cuentas y Sealevel
Los clientes deben declarar cada cuenta que una instrucción leerá o escribirá. El tiempo de ejecución utiliza esa lista para cargar cuentas de AccountsDB, marcar cada una como de solo lectura o escribible, bloquear cuentas escribibles superpuestas para que los conflictos no se intercalen, y programar trabajo no superpuesto concurrentemente (Sealevel).
Cuentas de Tx A: [User1, VaultA, TokenProg] (escribible: User1, VaultA)
Cuentas de Tx B: [User2, VaultB, TokenProg] (escribible: User2, VaultB)
|
v
Sin cuentas escribibles compartidas -> pueden ejecutarse en paralelo
Cuentas de Tx C: [User1, VaultA, ...]
Conflicto con Tx A en VaultA escribible -> debe serializarseSi el programa necesita una cuenta no declarada, la ejecución falla; no hay una ruta ambiental "cargar lo que sea que hashee más tarde" para la mutación. Esa fricción es intencional: el paralelismo necesita un mundo cerrado de direcciones antes de que comience la ejecución. Muchas cuentas de estado pequeñas y no superpuestas (por ejemplo, un PDA por usuario) no son solo un estilo de API, son la forma de dejar espacio libre para el rendimiento concurrente.
Cómo interactúan las piezas en una sola instrucción
Una ruta típica de "actualizar mi perfil":
- El cliente lista el firmante del usuario, el PDA del perfil (escribible), el Programa del Sistema si se crea, y su programa.
- El tiempo de ejecución bloquea esas cuentas por indicadores de solo lectura/escribible.
- Su programa se ejecuta; solo las cuentas que posee pueden tener
datareescrito por su lógica. - Deserializa
data, verifica la autoridad contra el firmante, escribe nuevos bytes y regresa. - El éxito confirma el registro; el fracaso aborta toda la transacción.
El alquiler se estableció en la creación. La propiedad se estableció en la asignación. El paralelismo se estableció por las direcciones que aterrizaron en el mensaje. El cuerpo de la instrucción solo proporciona la lógica de negocio.
Consideraciones Avanzadas y Aplicaciones
La abstracción de cuenta única fuerza compensaciones que parecen extrañas si espera "un contrato, almacenamiento interno infinito". Paga en dimensionamiento por adelantado, cableado explícito y expansión de cuentas; gana propiedad clara, alquiler recuperable y conjuntos de conflictos visibles para el programador.
| Rol de la cuenta | Fortaleza | Debilidad | Mejor ajuste |
|---|---|---|---|
| Billetera propiedad del sistema | Simple portador de SOL; pagador de tarifas natural | Datos vacíos/sin tipo; no para esquemas de aplicaciones | Usuarios, tesorerías de SOL, pagadores de instrucciones |
| Cuenta de datos propiedad del programa | Estado tipado bajo escrituras del propietario; alquiler cerrable | Asignar, financiar y pasar cada vez | Configuración, fideicomisos, registros por usuario, bóvedas |
| Cuenta de programa ejecutable | Lógica compartida; patrones de cargador actualizables | No es estado de aplicación; las actualizaciones requieren cuidado con la autoridad | Solo código de programa en cadena |
La granularidad es la principal palanca de rendimiento. Una cuenta de estado global gigante serializa a cada escritor. Muchas cuentas por entidad permiten que usuarios no superpuestos se ejecuten en paralelo, a costa de más direcciones, más alquiler y listas de cuentas más largas. La compresión y los índices ayudan a escala, pero la cadena todavía piensa en cuentas y bloqueos declarados.
La CPI y la propiedad se componen porque la propiedad es absoluta. Para cambiar una cuenta de token, haces CPI al Programa de Token; no puedes manipular sus bytes tú mismo. "¿Quién puede mutar esto?" es un hecho del tiempo de ejecución, y el límite de confianza de Sealevel coincide con el mismo campo owner que usas para las cuentas de aplicaciones.
La actualización también tiene forma de cuenta. Con el cargador actualizable, la identidad y los bytes del programa pueden vivir en cuentas relacionadas (programa + ProgramData). Cerrar, reasignar o migrar el estado es siempre "mover o reescribir bajo las reglas del propietario", no "editar un trie de almacenamiento oculto".
Para revisiones de diseño, responda primero: dónde vive cada campo, qué programa lo posee, qué autoridad se encuentra dentro de data, el costo de espacio y alquiler, qué direcciones debe pasar cada cliente y qué pares de transacciones compiten por la misma cuenta escribible. Respuestas claras reducen los errores de propiedad y la serialización accidental de rutas críticas.
Conceptos erróneos comunes
- "Las billeteras, los programas y el estado son tipos de objetos en cadena diferentes." Son la misma estructura de cuenta; los roles difieren por
owner,executabley cómo se interpretadata. - "Mi programa almacena campos dentro del binario del programa." Los ejecutables contienen código (a través de cargadores); los campos de aplicación duraderos viven en cuentas separadas propiedad del programa que usted crea y pasa.
- "Propietario significa la clave pública de la billetera del usuario." El propietario es siempre un ID de programa. El control del usuario suele ser una verificación de firmante contra un campo de autoridad almacenado en
data, o reglas del Programa del Sistema para cuentas propiedad del sistema. - "Si conozco una dirección, el tiempo de ejecución recuperará lo que necesite." Las rutas de mutación requieren que la cuenta aparezca en la lista de cuentas de la transacción con el indicador correcto de escribible; las cuentas no declaradas no están disponibles de forma ambiental.
- "El alquiler es una suscripción mensual para siempre." La práctica de producción es la financiación exenta de alquiler en la creación; el depósito escala con el tamaño y es recuperable cuando la cuenta se cierra correctamente.
- "Una cuenta grande es más simple y está bien a escala." Es más simple de codificar al principio, pero cada escritor se serializa en esa dirección; Sealevel no puede paralelizar bloqueos escribibles conflictivos.
Preguntas frecuentes
¿Cuál es la idea más importante en el modelo de cuentas?
Todo en la cadena es una cuenta con los mismos campos, y solo el programa propietario puede escribir los datos de esa cuenta, por lo que los permisos, el alquiler y los bloqueos paralelos forman un sistema coherente.
¿Cuáles son los cinco campos principales de la cuenta?
lamports (saldo), data (búfer de bytes), owner (programa permitido para escribir datos), executable (si la cuenta es código de programa) y rent_epoch (seguimiento de alquiler heredado; las cuentas exentas usan la convención de época máxima).
¿Qué aplica realmente la regla de escrituras del propietario?
El tiempo de ejecución rechaza las mutaciones de datos de cualquier programa que no sea el owner de la cuenta. Su programa solo puede reescribir cuentas que posee; para cambiar el diseño de otra persona, debe hacer CPI al programa propietario.
¿Por qué las billeteras ordinarias son propiedad del sistema?
El Programa del Sistema las posee para poder crear cuentas, asignar propietarios y transferir SOL bajo reglas de firma. Las billeteras típicamente tienen datos vacíos y no se usan como almacenamiento de aplicaciones estructurado.
¿Dónde debe vivir el estado estructurado de mi aplicación?
En cuentas propiedad de su programa: asigne espacio, asigne su ID de programa como propietario, financie lamports exentos de alquiler, y luego serialice su diseño en data en cada actualización.
¿Cómo difieren las cuentas de programas ejecutables de las cuentas de datos?
Tienen executable: true y son propiedad de un cargador; su carga útil es bytecode o contabilidad del cargador, no su esquema de aplicación. Las invoca como programas, no como bolsas de estado mutables ordinarias.
¿Qué significa "exento de alquiler" en la práctica?
La cuenta contiene suficientes lamports para el tamaño de sus datos, de modo que no está sujeta a la recolección continua de alquiler. El depósito requerido crece con el espacio asignado; cerrar la cuenta es la forma de recuperar esos lamports.
¿Qué pasos crean una cuenta de datos utilizable?
Asigne un búfer de datos del tamaño correcto, asigne el programa propietario previsto y financie al menos el mínimo exento de alquiler, generalmente pagado por un pagador de tarifas propiedad del sistema en la misma transacción que inicializa los campos.
¿Son los PDA un tipo diferente de cuenta?
No. Un PDA es una dirección derivada para que un programa pueda controlarla sin una clave privada. Una vez creada, sigue siendo una cuenta normal con los mismos cinco campos.
¿Por qué los clientes deben declarar todas las cuentas en la transacción?
Para que el tiempo de ejecución pueda cargar, bloquear y programar cuentas antes de la ejecución. Sealevel utiliza esas listas para ejecutar transacciones no superpuestas en paralelo y para evitar el acceso a estado no declarado.
¿Cómo permite el modelo de cuentas el paralelismo de Sealevel?
Las transacciones que no comparten cuentas escribibles conflictivas pueden ejecutarse concurrentemente porque sus conjuntos de bloqueos no se cruzan. Las listas explícitas de cuentas hacen que esos conjuntos de bloqueos se conozcan de antemano.
¿Cuál es la diferencia entre el propietario de la cuenta y la autoridad de la cuenta?
El propietario es el ID del programa en los metadatos de la cuenta. La autoridad es generalmente una clave pública a nivel de aplicación almacenada dentro de data que su programa verifica contra un firmante de transacción.
¿Pueden dos programas poseer la misma cuenta?
No. Hay un único campo owner. El comportamiento compartido requiere CPI al programa propietario o rediseñar qué programa debe poseer el estado.
¿Qué sucede cuando cierro una cuenta?
Bajo las reglas del programa propietario, los datos se ponen a cero o la cuenta se reasigna, y los lamports restantes (incluido el depósito de alquiler) se transfieren a un destinatario, recuperando el capital bloqueado para ese estado.
¿Cómo debo pensar en los saldos de tokens en este modelo?
Los saldos de SPL viven en cuentas de token propiedad del Programa de Token, no en los datos vacíos de la cuenta del sistema de la billetera. La billetera sigue siendo una cuenta; cada saldo de token es otra cuenta con su propio propietario y diseño.
Relacionado
- Fundamentos del Modelo de Cuentas - ejemplos prácticos del modelo de cuentas
- Anatomía de una Cuenta - desglose campo por campo del registro de cuenta
- Alquiler y Exención de Alquiler - depósitos basados en tamaño y recuperación al cerrar
- Propiedad y Permisos de Cuentas - escrituras del propietario y verificaciones de firmante
- Estado Propiedad del Programa - programas sin estado y cuentas de datos
- Cuentas del Sistema vs. Cuentas de Programa - roles de billetera, datos y ejecutables
Versiones de Stack: 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.