Визначення

Account data — це масив байтів, який зберігається в полі data облікового запису Solana. Саме тут програми зчитують стан і записують зміни. Усе решта — баланс у lamports, власник, прапорець executable — є метаданими, що обслуговують доступ до цих байтів.

Як працює

Кожен обліковий запис у Solana містить фіксовану структуру з кількох полів. Поле data — єдине, що зберігає корисне навантаження програми. Його особливості:

  • Розмір виділяється під час створення і фіксується (за винятком процедури reallocation, яка збільшує розмір із додатковою оплатою rent-exempt).
  • Максимальний розмір — 10 МБ на один обліковий запис.
  • Інтерпретація байтів повністю залежить від програми-власника: Solana runtime не знає, чи це серіалізована структура, зображення чи щось інше.
  • Записувати в data може лише програма, зазначена в полі owner. Інші програми отримують помилку ReadonlyViolation або IllegalOwner.
  • Витрати пропорційні розміру: чим більше байтів виділено, тим більше lamports потрібно заблокувати для rent-exempt стану.

На практиці розробники серіалізують дані за допомогою Borsh, bincode або вбудованих механізмів Anchor, а під час виклику програми передають обліковий запис як аргумент інструкції — і runtime автоматично робить його байти доступними для читання чи запису.

Приклад

У програмі на Anchor ви визначаєте структуру стану:

#[account]
pub struct Vault {
  pub authority: Pubkey,
  pub balance: u64,
  pub is_locked: bool,
}

Після серіалізації через Borsh ця структура перетворюється на 41 байт (32 + 8 + 1). Саме ці 41 байт і стануть account data облікового запису, який створюється через init-інструкцію Anchor. Коли програма читає цей обліковий запис, вона десеріалізує ті самі байти назад у структуру Vault.

Типова помилка

Виділяти занадто великий розмір data «на майбутнє». Це призводить до безглуздої блокування великої кількості SOL за rent-exempt і збільшує вартість кожної транзакції, яка зчитує цей обліковий запис. Інша поширена помилка — нехтування порядком полів під час ручної серіалізації: якщо клієнт і програма очікують різний порядок байтів, десеріалізація дасть хибні значення без жодної помилки на рівні runtime.

Пов'язані матеріали

Внутрішні переходи

  • Runtime — середовище виконання, яке керує доступом до account data під час обробки інструкцій.
  • BPF Loader — компонент, який завантажує скомпільовану програму і передає їй посилання на account data під час виклику.

Додаткові ресурси

  • Офіційна документація Solana: розділ Account Model — детальний опис усіх полів облікового запису та механізму rent.
  • Документація Anchor: розділ Accounts — як фреймворк автоматизує серіалізацію та десеріалізацію account data.

Джерела