Anatomía de una cuenta
Cada cuenta de Solana comparte los mismos campos estructurales. Comprender cada campo te dice quién puede escribir, si el código o los datos viven allí y cuántos SOL se bloquean para el alquiler.
Receta
import { createSolanaRpc, address } from "@solana/kit";
const rpc = createSolanaRpc("https://api.devnet.solana.com");
const { value: acct } = await rpc
.getAccountInfo(address("PUBKEY"), { encoding: "base64" })
.send();Cuándo recurrir a esto:
- Depuración de errores de permisos (propietario incorrecto o firmante faltante)
- Determinar si una dirección es un programa o una cuenta de datos
- Cálculo del alquiler a partir de
data.length - Verificación de la existencia de la cuenta antes de construir transacciones
Ejemplo de trabajo
solana account 11111111111111111111111111111111use anchor_lang::prelude::*;
pub fn inspect(ctx: Context<Inspect>) -> Result<()> {
let acct = &ctx.accounts.target;
msg!("lamports: {}", acct.lamports());
msg!("owner: {}", acct.owner);
msg!("data len: {}", acct.data_len());
msg!("executable: {}", acct.executable);
Ok(())
}
#[derive(Accounts)]
pub struct Inspect<'info> {
/// CHECK: raw inspection
pub target: UncheckedAccount<'info>,
}Lo que esto demuestra:
- Todos los cinco campos son legibles por cualquier programa que reciba la cuenta
executabledistingue las cuentas de programa de las cuentas de datosdata_len()devuelve el tamaño del búfer de bytes excluyendo los campos de metadatos
Profundización
Referencia de campos
| Campo | Tipo | Significado |
|---|---|---|
lamports | u64 | Saldo de SOL en lamports |
data | &[u8] | Carga útil de bytes sin procesar |
owner | Pubkey | Programa autorizado a escribir data |
executable | bool | true si la cuenta contiene un programa BPF |
rent_epoch | u64 | Seguimiento heredado; las cuentas exentas de alquiler usan u64::MAX |
Cómo funciona
- Los campos de metadatos (
lamports,owner,executable,rent_epoch) son administrados por el tiempo de ejecución - Solo el
ownerpuede cambiar el tamaño o escribirdata(además del Programa del Sistema para la asignación) - Las cuentas de programa tienen
owner = BPF Loaderyexecutable = true
Trampas
- Confundir lamports con saldo de tokens - Los saldos de SPL viven en los datos de la cuenta de tokens (
data), no enlamports. Solución: leer el diseño de la cuenta de tokens para obtener los saldos. - Asumir que
dataes texto UTF-8 - son bytes sin procesar (Borsh, bincode o personalizado). Solución: deserializar con el esquema correcto. - Ignorar el indicador
executable- pasar una cuenta de programa donde se esperan datos falla. Solución: verificar el indicador antes de la deserialización. - Semántica de
rent_epochcambiada - las cuentas modernas están exentas de alquiler; el campo de época es heredado. Solución: usargetMinimumBalanceForRentExemptionpara la financiación. - Propietario vs. autoridad - el propietario es el programa; la autoridad es a menudo una pubkey dentro de
data. Solución: validar ambos en tus restricciones.
Alternativas
| Alternativa | Usar cuándo | No usar cuándo |
|---|---|---|
RPC getAccountInfo | Inspección fuera de la cadena | Ruta activa en programas (pasar cuentas) |
Anchor Account<T> | Deserialización tipada | Diseños desconocidos o variables |
UncheckedAccount | Lectura de bytes sin procesar con comprobaciones manuales | Opción predeterminada (preferir tipada) |
Preguntas frecuentes
¿Cuáles son los cinco campos de la cuenta?
Lamports, data, owner, executable, rent_epoch. Cada cuenta tiene los cinco.
¿Quién puede cambiar el campo owner?
Solo el programa propietario actual (a través de assign) o el Programa del Sistema durante la creación. No programas arbitrarios.
¿Cuál es el tamaño máximo de datos de la cuenta?
10 MB por cuenta en Agave 4.1.1. Los límites prácticos son más bajos debido a los costos de alquiler y CU.
¿Pueden cambiar los lamports y los datos en la misma instrucción?
Sí. Los programas a menudo deducen lamports mientras actualizan los datos en una instrucción atómica.
¿Qué significa executable=true?
La cuenta contiene bytecode BPF desplegado cargado por un programa cargador BPF.
¿Es owner lo mismo que upgrade authority?
No. La autoridad de actualización son metadatos en la cuenta de datos del programa, separados del campo owner en cuentas individuales.
¿Cómo compruebo si una cuenta existe?
getAccountInfo devuelve null si la cuenta nunca ha sido financiada/creada.
¿Qué hay en los datos de la cuenta de una billetera?
Típicamente vacío (0 bytes). El SOL de la billetera está solo en lamports.
¿Pueden dos programas ser copropietarios de una cuenta?
No. Exactamente un programa propietario por cuenta.
¿Qué codificación debe usar RPC para datos binarios?
base64 o base58 para getAccountInfo. jsonParsed para diseños de programas conocidos como SPL Token.
¿Afecta rent_epoch a la validez de la transacción?
No para las cuentas modernas exentas de alquiler. Es informativo/heredado.
¿Cómo se organizan los datos de la cuenta en Anchor?
Discriminador de 8 bytes + campos de struct serializados con Borsh.
Relacionado
- Conceptos básicos del modelo de cuenta - ejemplos generales
- Alquiler y exención de alquiler - requisitos de lamports
- Cuentas de datos y diseño - diseño de búfer de bytes
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.