Account model Solana: чому дані й програми організовані саме так

Solana організовує дані й програми як єдину систему акаунтів, тому що це дозволяє статично визначити, які транзакції читають і записують які дані, ще до їхнього виконання. Така визначеність є фундаментальною умовою для паралельного виконання транзакцій без консенсусу між валідаторами про порядок доступу до пам’яті. Усе інше — розмір акаунтів, система оренди, PDA (Program Derived Address) — є наслідками цього базового архітектурного рішення.

Цей матеріал пояснює, як саме влаштована модель акаунтів, які компроміси вона створює й де закінчуються наші достовірні знання про її поточний стан.

Технічна рамка цього матеріалу

Головна теза: модель акаунтів Solana — це не спосіб зберігання даних, а механізм розмежування доступу, який робить можливим паралельне виконання. Кожен акаунт має єдиного власника — програму, і лише ця програма може змінювати дані акаунта. Це правило дозволяє валідатору, отримавши транзакцію, одразу визначити набір акаунтів, які будуть записані, і порівняти їх із записами інших транзакцій у поточному слоті.

Межа аналізу: цей матеріал розглядає модель акаунтів як структурний елемент протоколу. Ми не описуємо шлях транзакції від підпису до підтвердження і не заглиблюємося в механіку паралельного виконання. Ці теми мають власні сторінки. Тут фокус виключно на тому, чому акаунти влаштовані саме так і які наслідки це має для розробників й архітектури мережі.

Для контексту: якщо ви тільки знайомитеся з архітектурою Solana, корисно почати з загального опису протоколу. Загальну карту матеріалів розділу можна знайти на головній сторінці «Під капотом».

Що відбувається під капотом

Що таке акаунт у Solana

У Solana акаунт — це запис у стані мережі з фіксованою структурою. Він не є аналогом банківського рахунку чи користувацького профілю. Акаунт — це одиниця адресованого простору пам’яті з метаданими, які визначають, хто має право його змінювати.

Кожен акаунт містить набір полів, які визначають його поведінку в протоколі:

Поле	Призначення	Обмеження
lamports	Баланс у найменшій одиниці SOL	Не може бути від’ємним; акаунт із нульовим балансом може бути видалений
owner	Адреса програми, яка має ексклюзивне право змінювати дані акаунта	Тільки власник може змінювати поле data; зміна самого поля owner також регулюється правилами власника
data	Байтовий масив довільних даних	Має фіксований максимальний розмір; зміна розміру потребує окремої операції реалокації
executable	Прапорець: чи містить акаунт код програми	Булеве значення; якщо true — акаунт є програмою, якщо false — акаунт даних
rent_epoch	Епоха, до якої сплачена оренда пам’яті	Залежить від поточного стану системи оренди в мережі

Ключове архітектурне рішення: програми (smart contracts) і дані зберігаються в однаковій структурі. Програма — це просто акаунт із прапорцем executable = true. Дані — акаунт із executable = false. Немає окремого «сховища контрактів» чи «простору стану», як у деяких інших архітектурах.

Власність як механізм ізоляції

Поле owner є центральним елементом моделі. Коли транзакція надсилає інструкцію програмі, runtime перевіряє: кожен акаунт, який інструкція намагається записати, повинен мати owner, що дорівнює адресі цієї програми. Якщо owner інший — транзакція відхиляється.

Це створює чітку межу: програма A не може безпосередньо змінити дані акаунта, який належить програмі B. Єдиний механізм взаємодії між програмами — CPI (Cross-Program Invocation), коли програма A делегує виконання частини логіки програмі B, передаючи їй права на певні акаунти. Навіть у цьому випадку програма B може записувати лише ті акаунти, де вона є власником.

PDA: програмно-визначені адреси

Окремий клас акаунтів — PDA (Program Derived Address). Це адреси, які детерміновано обчислюються з адреси програми та набору насінних значень (seeds), але не мають відповідного приватного ключа. Такі акаунти належать програмі, яка їх створила, і лише ця програма може підписувати від їхнього імені через runtime.

PDA вирішують конкретну проблему: як програмі безпечно зберігати стан, який вона контролює ексклюзивно. Без PDA розробник мусив би генерувати ключову пару поза мережею, зберігати приватний ключ і передавати його в програму, що створювало б вектор атаки. З PDA програма сама визначає адресу для своїх даних і гарантує, що жоден зовнішній ключ не може підписати транзакцію від імені цього акаунта.

Зв’язок із паралельним виконанням

Модель акаунтів безпосередньо обслуговує потребу паралельного виконання. Коли валідатор отримує транзакцію, він бачить список акаунтів, які транзакція читає (read) і записує (write). Ця інформація відома до виконання, бо вона закодована в самій транзакції. Валідатор може побудувати граф залежностей між транзакціями в поточному слоті й виконувати незалежні гілки паралельно.

Якби стан не був розділений на дискретні акаунти з чіткими власниками, визначити залежності до виконання було б неможливо. Саме тому модель акаунтів не є просто дизайнерським вибором — вона є структурною передумовою всієї архітектури продуктивності Solana. Детальний розбір того, як це працює на рівні runtime, наведено в матеріалі про паралельне виконання.

Де факти, а де інтерпретація

Що є протокольним фактом

Наступні твердження випливають безпосередньо зі специфікації моделі акаунтів і не залежать від поточного стану мережі:

• Акаунт має фіксовану структуру полів (lamports, owner, data, executable, rent_epoch).
• Тільки програма, вказана в полі owner, може змінювати поле data акаунта.
• Програми й дані зберігаються в однаковій структурі акаунтів; різниця — лише в прапорці executable.
• PDA обчислюється детерміновано і не має приватного ключа.
• CPI — єдиний механізм взаємодії між програмами на рівні стану.

Що потребує перевірки за поточним станом

Деякі аспекти моделі акаунтів змінювалися з часом. Щоб стверджувати щось конкретне про поточний стан, потрібна перевірка:

• Максимальний розмір акаунта. Історично існували різні ліміти. Щоб назвати точне значення, потрібна перевірка актуальної версії специфікації або конфігурації кластера.
• Статус системи оренди (rent). Механізм оренди зазнавав змін. Поточні правила — чи оренда повністю скасована, чи змінені пороги звільнення — потребують перевірки по актуальних SIMD (Solana Improvement Document) і стану мережі.
• Ліміти на кількість акаунтів у транзакції. Цей параметр змінювався. Точне поточне значення вимагає перевірки конфігурації runtime.

Редакція не стверджує жодного з цих числових значень, оскільки вони залежать від версії й можуть бути неточними без перевірки проти актуального коду або документації.

Позиції в екосистемі

Серед розробників Solana існує широке, але не універсальне, визнання того, що модель акаунтів дає переваги в продуктивності ціною складності розробки. Основна дискусія зосереджена не навколо самої моделі, а навколо інструментів, які її абстрагують. Фреймворк Anchor значно спростив роботу з акаунтами, але під ним залишається та сама структура з її обмеженнями на розмір, життєвий цикл і правила власності.

Позиція щодо компромісів варіюється: розробники, які приходять з архітектур, де стан контракту є непрозорим об’єктом, часто вважають явну модель акаунтів надмірно деталізованою. Розробники, які працювали з системами, де ізоляція стану була проблемою, зазвичай оцінюють явну власність як перевагу.

Ризики й системні компроміси

Компроміси моделі

Перевага	Ціна
Статична визначеність доступу до стану — умова паралельного виконання	Розробник повинен явно планувати структуру акаунтів до написання логіки
Чітка ізоляція: програма не може знищити чужий стан	Складніша композиція програм: кожна взаємодія через CPI потребує явної передачі прав
PDA усуває потребу зберігати приватні ключі для програмного стану	PDA створює обмеження на глибину вкладених CPI (через обмеження розміру стека викликів)
Єдина структура для програм і даних спрощує runtime	Розробник повинен самостійно управляти життєвим циклом акаунтів: створення, реалокація, закриття

Ризики для розробників

Неправильне управління життєвим циклом. Акаунт не зникає самостійно (за винятком випадків, коли оренда не сплачена). Якщо розробник не реалізує логіку закриття акаунта та повернення lamports, стан накопичується. Це не є вразливістю протоколу, але є поширеною помилкою, яка призводить до втрати коштів користувачів.

Переплутання owner і signer. Акаунт, який підписав транзакцію (signer), не обов’язково є owner інших акаунтів у цій транзакції. Ця плутанина — джерело логічних помилок у програмах, особливо у випадках, коли розробник очікує, що підписант автоматично отримує права на зміну стану.

Реалокація розміру. Зміна розміру поля data акаунта — окрема операція з власними обмеженнями й витратами. Архітектурні рішення, які ігнорують це на етапі проєктування, змушують пізніше мігрувати дані між акаунтами, що ускладнює оновлення програм.

Невизначеність

Довгострокова невизначеність пов’язана з тим, як модель акаунтів буде співіснувати з майбутніми змінами в архітектурі виконання. Зокрема, якщо будуть запроваджені нові форми паралелізму або зміни в моделі пам’яті, це може вплинути на те, які компроміси вважаються прийнятними. Проте на момент написання цього матеріалу така невизначеність є прогнозом, а не фактом, і не повинна впливати на поточні архітектурні рішення.

Висновок без перебільшень

Модель акаунтів Solana — це навмисний компроміс між продуктивністю й складністю. Вона відмовляється від зручності неявного управління станом на користь явної ізоляції, яка робить можливим паралельне виконання. Для розробника це означає, що планування структури акаунтів є не другорядним завданням, а частиною архітектури програми з першого дня.

Зміна в одному компоненті — наприклад, збільшення максимального розміру акаунта або зміна правил оренди — безпосередньо впливає на те, які архітектурні патерни стають доступними для розробників продуктів, описаних у розділі Продукти Solana. І навпаки: вимоги продуктів (наприклад, зберігання великих об’ємів даних на ланцюгу) створюють тиск на зміну параметрів моделі акаунтів.

Безпека моделі акаунтів — окремий вимір, який розглядається в матеріалі про безпеку Solana. Там фокус зміщується від структури до векторів атак і механізмів захисту.

Обмеження цього матеріалу. Текст описує принципову архітектуру моделі акаунтів. Він не містить інструкцій із розробки, не розглядає конкретні фреймворки (зокрема Anchor) і не наводить прикладів коду. Числові параметри (розміри, ліміти, пороги оренди) навмисно не вказані, оскільки їхнє точне значення залежить від версії клієнта й конфігурації кластера й потребує перевірки проти актуальних джерел перед використанням у розробці.

Наступний крок. Якщо ви зрозуміли, чому акаунти влаштовані саме так, логічне продовження — дізнатися, як ця структура використовується для досягнення високої продуктивності: Паралельне виконання: де Solana отримує швидкість і які має обмеження.

Редакція солана.укр

Джерела для перевірки. Ключові технічні твердження звірено з первинними джерелами: документація Solana про обробку транзакцій.