Пояснення моделі акаунтів Solana

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

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

Якщо ви перейшли з Ethereum, модель акаунтів Solana спочатку здасться вам перевернутою. Така реакція є правильною відправною точкою. Ментальна модель, яку ви побудували в Ethereum, не переноситься безпосередньо, і спроби нав'язати її створюють плутанину на кожному кроці.

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

Уявіть Solana як глобальну систему картотеки. Кожна частина даних живе в окремому файлі, який називається акаунтом. Програми — це додатки, які читають і записують ці файли, але програма може змінювати лише той файл, яким вона володіє. Середовище виконання (runtime) забезпечує дотримання цих правил власності на рівні протоколу без жодних винятків.

Ця стаття охоплює п'ять полів усередині кожного акаунта Solana, п'ять окремих типів акаунтів, принцип роботи орендної плати та звільнення від неї, що таке програмно-похідні адреси (PDA) і навіщо вони існують, як акаунти створюються та закриваються, і чому ця архітектура робить можливою паралельну обробку транзакцій у Solana. Програми Solana пишуться на Rust (або C/C++), хоча такі фреймворки, як Anchor, абстрагують значну частину шаблонів управління акаунтами. Ця стаття охоплює концептуальну основу, необхідну для обох підходів.

Модель акаунтів Solana: Анатомія акаунта

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

Лампорти — це найменша одиниця SOL, нативного токена мережі. Лампорти для SOL — це як центи для долара, за винятком точності до дев'яти знаків після коми: 1 SOL дорівнює 1 000 000 000 лампортів. Кожен акаунт має баланс у лампортах, який фінансує подальше існування акаунта в мережі та представляє вартість, яку можна передати.

Кожен акаунт Solana містить рівно п'ять полів:

• lamports (u64): Баланс акаунта в лампортах. Це поле фінансує оренду і може бути передане на інші акаунти.
• data (масив байтів): Необроблене бінарне сховище. У виконуваних акаунтах це поле містить скомпільований байт-код BPF/SBF. У акаунтах даних воно містить структурований стан застосунку. Максимальний розмір поля даних становить 10 МБ при поточних параметрах основної мережі.
• owner (Pubkey): 32-байтний відкритий ключ програми, яка має ексклюзивне право запису в поле даних цього акаунта. Це найбільш контрінтуїтивне поле для розробників Ethereum. Адреса вашого гаманця не належить вам на рівні протоколу; вона належить системній програмі (System Program). Повний опис поля власника наведено в розділі про власність та повноваження акаунтів.
• executable (bool): Булевий прапорець. Якщо він має значення true, поле даних містить байт-код програми, і акаунт функціонує як програма. Якщо false, акаунт зберігає стан або утримує баланс.
• rent_epoch (u64): Застаріле поле, яке відстежувало епоху, в якій востаннє збиралася орендна плата. Станом на 2024 рік збір орендної плати скасовано на користь моделі «звільнення від оренди за замовчуванням». Це поле залишається в структурі акаунта, але більше не використовується активно.

Ось як виглядає акаунт гаманця як структура даних:

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

Поле власника (owner) — це концепція рівня протоколу: програма, яка контролює доступ до запису в поле даних. Повноваження (authority) — це окрема конвенція, що зберігається всередині керованих програмою даних, наприклад, поле повноважень на переказ у токен-акаунті. Це не одне й те саме; у розділі про власність це розрізнення пояснюється детально.

П'ять типів акаунтів Solana

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

Акаунти під управлінням системи (Акаунти гаманців)

Акаунт під управлінням системи зберігає баланс SOL користувача і нічого більше. Власником завжди є System Program (11111111111111111111111111111111), прапорець executable встановлено на false, а поле даних порожнє. Коли ви надаєте адресу свого гаманця Phantom або Solflare, ви ділитеся адресою акаунта, що належить системі. Ви контролюєте його, підписуючи транзакції своїм приватним ключем, але System Program є власником на рівні протоколу.

Програмні акаунти (Виконувані акаунти)

Програмний акаунт — це виконуваний акаунт, що містить скомпільований байт-код BPF/SBF. Прапорець executable має значення true, а власником є BPF Loader. Програмні акаунти за дизайном не мають стану (stateless); вони містять лише код, але ніколи не стан. В Ethereum смартконтракт зберігає і свій код, і свій стан за однією адресою контракту. У Solana код живе в програмному акаунті, а стан — в окремих акаунтах даних, які завжди зберігаються нарізно.

Програмні акаунти можуть зберігати виконуваний код із executable = true та байт-кодом BPF/SBF у полі даних. Невиконувані акаунти даних мають executable = false і замість цього зберігають стан.

Акаунт даних — це невиконуваний акаунт, що належить певній програмі та зберігає стан цієї програми у своєму полі даних. Прапорець executable має значення false. Власником є та програма, яка створила акаунт і керує ним. Ваш баланс токенів USDC, позиція кредитування DeFi, запис метаданих NFT: кожен із них живе у своєму власному виділеному акаунті даних, що належить відповідній програмі.

Нативні програмні акаунти — це вбудовані програми, розгорнуті за фіксованими адресами під час генезису мережі. До них належать System Program, BPF Loader, Vote Program та Stake Program. Це базові інфраструктурні програми, які не можуть бути замінені або оновлені користувачами. Їхній прапорець executable має значення true.

Акаунти Sysvar — це акаунти лише для читання, попередньо заповнені середовищем виконання Solana, які дають програмам доступ до поточного стану мережі. Уявіть акаунти sysvar як державну дошку оголошень у будівлі суду: вони загальнодоступні для читання, підтримуються авторитетним джерелом, але жодна приватна особа не може їх змінити. Sysvar Clock за адресою SysvarC1ock11111111111111111111111111111111 надає часову мітку поточного блоку та номер слота. Sysvar Rent надає поточні параметри оренди.

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

Програми проти облікових записів даних: Розділення логіки та стану

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

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

Чотири властивості визначають, як програми Solana взаємодіють з обліковими записами:

• Програми обробляють інструкції та читають або записують дані з облікових записів, переданих їм під час виклику. Вони не зберігають власний стан.
• Програми є незмінними після розгортання, якщо розробник не обрав завантажувач, що оновлюється, під час розгортання.
• Лише програма, яка володіє обліковим записом даних, може змінювати поле даних цього облікового запису. Будь-який користувач може викликати програму, але доступ на запис до будь-якого облікового запису контролюється володінням.
• Прапорець executable застосовує це розмежування на рівні протоколу і не може бути змінений після розгортання.

Програми Solana є без стану, але система Solana загалом є з керованим станом. Стан зберігається; він знаходиться в облікових записах даних. Розмежування полягає в тому, що стан завжди є зовнішнім до програми, ніколи не об'єднаний всередині неї.

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

Володіння обліковими записами та повноваження: Хто чим керує в Solana

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

Поле власника зберігає 32-байтовий відкритий ключ програми. Для облікових записів гаманців власником є Системна програма. Для облікових записів токенів власником є Програма SPL Token. Для користувацьких облікових записів даних власником є програма, яка їх створила. Володіння встановлюється під час створення облікового запису та застосовується середовищем виконання Solana до кожної транзакції.

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

Розмежування між власником та повноваженнями часто спантеличує розробників Ethereum:

• Власник (поле протоколу): Ідентифікатор програми, яка може змінювати поле data облікового запису. Встановлюється під час створення облікового запису. Застосовується середовищем виконання Solana, а не логікою будь-якої програми.
• Повноваження (конвенція даних): Відкритий ключ, що зберігається всередині поля data облікового запису власником програми. Він авторизує конкретні операції в межах логіки програми. Застосовується самою програмою, а не середовищем виконання.

Для облікового запису токена USDC, Програма токенів є власником і може змінювати баланс, що зберігається в полі даних. Ваш гаманець є органом, що видає дозвіл на передачу (transfer authority), відкритий ключ, записаний у полі даних, який Програма токенів перевіряє перед виконанням передачі. Це різні ключі, що виконують різні функції. Змішування їх є однією з найпоширеніших помилок у новій розробці Solana.

Оренда облікових записів Solana та пояснення звільнення від орендної плати

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

Що таке оренда в Solana?

Валідатори повинні зберігати весь активний стан облікових записів у пам'яті. Необмежена кількість облікових записів з нульовим балансом могла б стати вектором відмови в обслуговуванні мережі, тому Solana вимагає, щоб облікові записи мали мінімальний баланс ламп як зобов'язання щодо оплати витрат на зберігання. Оригінальна модель оренди стягувала плату за епоху, пропорційну розміру даних, причому облікові записи нижче мінімуму підлягали збору сміття. Ця модель була застарілою.

Згідно з поточними параметрами основної мережі Solana (офіційно оформленими в SIMD-0084), усі нові облікові записи повинні бути звільнені від орендної плати під час створення. Поле rent_epoch в структурі облікового запису тепер є застарілим полем.

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

• Обліковий запис розміром 0 байтів (гаманець): приблизно 890 880 ламп (~0,00089 SOL)
• Обліковий запис розміром 165 байтів (стандартний обліковий запис токена): приблизно 2 039 280 ламп (~0,00204 SOL)
• Обліковий запис даних розміром 1 024 байти: приблизно 7 180 800 ламп (~0,00718 SOL)

Ці значення є приблизними та можуть змінюватися відповідно до параметрів середовища виконання. Розрахуйте точний поточний мінімум за допомогою Solana CLI або методу RPC getMinimumBalanceForRentExemption:

solana rent 0       # звільнення від орендної плати для облікового запису розміром 0 байтів
solana rent 165     # звільнення від орендної плати для стандартного облікового запису токена

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

Кількість ламп, що використовується в розрахунках орендної плати, визначена в розділі анатомії облікового запису. Щоб зробити обліковий запис даних звільненим від орендної плати під час його створення вашою програмою, викличте getMinimumBalanceForRentExemption(dataSize) на стороні клієнта перед побудовою транзакції створення, а потім включіть цю кількість ламп до інструкції.

Solana проти Ethereum проти Bitcoin: Порівняння моделей облікових записів

Яка різниця між обліковими записами Solana та обліковими записами Ethereum?

В Ethereum смартконтракти об'єднують свій код і стан за однією адресою. Обліковий запис контракту містить як логіку, так і дані, з якими він працює. У Solana код і стан завжди знаходяться в окремих облікових записах: програми (логіка) розміщуються у виконуваних облікових записах, а весь стан знаходиться в окремих облікових записах даних, що належать цим програмам. Це розділення є архітектурною основою всього, чим Solana відрізняється.

Bitcoin застосовує зовсім інший підхід, використовуючи модель UTXO (невитрачений вихід транзакції). UTXO схожі на невитрачені чеки в чековій книжці: кожна транзакція споживає існуючі виходи та створює нові. Немає постійного облікового запису, що зберігає баланс з часом. Ваш баланс — це сума невитрачених виходів, пов'язаних з вашими ключами. Модель Bitcoin передувала концепції програмованого стану, тому її можливості смартконтрактів обмежені Bitcoin Script.

EVM-сумісні мережі, включаючи Ethereum, Polygon, BNB Chain і Avalanche C-Chain, мають ту саму модель акаунтів, від якої відходить Solana. Одне порівняння охоплює їх усі.

В Ethereum гаманці користувачів називаються зовні керованими акаунтами (EOA). У Solana еквівалентом є акаунт, що належить системі та контролюється парою ключів; механізм схожий, але поле власника явно встановлено на системну програму, а не є неявним.

Що розробники Ethereum повинні забути

Перед написанням робочої програми на Solana необхідні три зміни в ментальній моделі:

1. Програми не містять власного стану. Його містять акаунти даних. Припиніть шукати стан за адресою програми.
2. Власником вашого гаманця на рівні протоколу є не ви. Ви контролюєте акаунт за допомогою підпису; Системна програма володіє полем даних.
3. Зберігання не є безкоштовним. Кожен акаунт даних вимагає депозиту в лампортах для звільнення від оренди. Враховуйте цю вартість при проектуванні програм, які створюють акаунти.

Суворе відокремлення коду від стану в Solana є передумовою для паралельного виконання — зв'язок, детально розглянутий у розділі Sealevel та паралельне виконання.

Як модель акаунтів забезпечує швидкість Solana: Sealevel та паралельне виконання

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

Ось причинно-наслідковий ланцюжок крок за кроком:

1. Транзакція Solana включає повний список усіх акаунтів, до яких вона звертатиметься, кожен з яких позначений як «тільки для читання» або «для читання та запису», ще до початку будь-якого виконання.
2. Sealevel перевіряє всі транзакції, що очікують у поточному слоті.
3. Транзакції, які мають принаймні один спільний акаунт для читання та запису, виконуються послідовно. Транзакції, що звертаються до абсолютно різних акаунтів, ідентифікуються як такі, що не конфліктують.
4. Неконфліктні транзакції виконуються одночасно на декількох ядрах процесора.

EVM в Ethereum виконує транзакції послідовно відносно спільного глобального стану. Оскільки стан контракту розміщений разом із кодом контракту, визначення конфліктів читання/запису вимагало б спочатку виконання транзакції, що робить статичне планування перед виконанням неможливим.

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

Доказ історії (PoH), винайдений співзасновником Solana Анатолієм Яковенком, забезпечує криптографічний годинник, який дозволяє валідаторам узгоджувати порядок транзакцій без координації в реальному часі. Solana використовує Proof of Stake (PoS) для консенсусу, де валідатори вносять в стейкінг SOL для участі у створенні блоків, і PoH як часовий рівень. У поєднанні з попереднім декларуванням акаунтів у моделі акаунтів, ця архітектура дозволяє Sealevel обробляти неконфліктні транзакції паралельно, не чекаючи підтвердження всією мережею на кожному етапі.

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

Приклади з реального світу: Акаунти токенів, NFT та DeFi на Solana

Кожен актив на Solana — баланс токенів, NFT, DeFi позиція — це акаунт Solana з певною структурою даних. Описана вище абстрактна архітектура проявляється в трьох паттернах, з якими стикається кожен користувач Solana.

Акаунти токенів SPL

Токени SPL, еквівалент токенів ERC-20 в Ethereum на Solana, керуються програмою SPL Token, якій належать усі акаунти токенів у мережі. Адреса вашого гаманця містить лише SOL (лампорти). Кожен токен, який ви утримуєте, чи то USDC, JTO, BONK, чи будь-який інший, живе у власному виділеному акаунті токенів, що належить програмі SPL Token.

Поле даних акаунта токенів зберігає три фрагменти інформації: адресу мінту токена (який токен утримує цей акаунт), відкритий ключ повноважень власника (адреса вашого гаманця, яка дозволяє перекази) та поточний баланс токенів. В Ethereum усі баланси ERC-20 для певного токена живуть у внутрішньому відображенні (mapping) контракту токена. На Solana кожна пара (користувач, токен) потребує власного виділеного акаунта.

Ось чому гаманці Solana пропонують вам створити акаунт токенів при першому отриманні нового токена. Це створення вимагає депозиту лампортів для звільнення від оренди в розмірі приблизно 0,00204 SOL для стандартного 165-байтового акаунта при поточних параметрах мережі.

Асоційовані акаунти токенів (ATA)

Асоційований акаунт токенів (ATA) — це акаунт токенів, адреса якого є PDA, детерміновано отриманою з адреси вашого гаманця та адреси мінту токена. Оскільки адреса детермінована, будь-який протокол може обчислити, де має бути ваш акаунт USDC, без зберігання таблиці пошуку. ATA є стандартним типом акаунта токенів, який використовується практично всіма гаманцями та протоколами Solana.

ATA — це застосування виведення PDA. Ви можете мати кілька акаунтів токенів для одного мінту, але ваш ATA є канонічним, який протоколи використовують за замовчуванням.

NFT на Solana

NFT на Solana складається щонайменше з двох акаунтів: акаунта мінту (Mint Account), що належить програмі Token, яка визначає пропозицію токена як рівну 1, та акаунта метаданих (Metadata Account), що належить програмі Metaplex Token Metadata, яка зберігає назву NFT, символ, URI зображення та конфігурацію роялті. Зображення NFT не зберігається ончейн; у акаунті метаданих живе лише URI, що вказує на нього. Баланс токена (1 NFT) зберігається в акаунті токенів, ідентичному будь-якому іншому токену SPL.

DeFi протоколи на Solana, включаючи децентралізовані біржі, платформи кредитування та пули ліквідності, зберігають кожну позицію користувача, стан пулу та конфігурацію протоколу у виділених акаунтах даних, причому PDA, що належать програмі, автономно контролюють об'єднані кошти.

Чому модель акаунтів Solana важлива для SOL

Примітка: У цьому розділі пояснюється, як модель акаунтів Solana впливає на технічну корисність SOL. Ніщо в цій статті не є фінансовою порадою або інвестиційною рекомендацією.

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

SOL використовується в моделі акаунтів через три окремі механізми:

Депозити для звільнення від оренди: Кожен акаунт у Solana повинен мати баланс у лампортах для існування в мережі. Оскільки мільйони токен-акаунтів, акаунтів даних програм, записів NFT та акаунтів стану DeFi активні в будь-який момент часу, це створює постійний базовий попит на SOL. Ці лампорти заблоковані в акаунтах і виведені з ліквідного обігу, поки акаунти залишаються відкритими.

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

Стейкінг валідаторів: Валідатори вносять в стейкінг SOL для участі в консенсусі за механізмом Proof of Stake Solana, отримуючи винагороди за валідацію змін стану рахунків у мережі.

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

Ламппорти, заблоковані на рахунках, звільнених від орендної плати, функціонують як заставні депозити, що утримуються мережею: вони не витрачаються, але зобов'язані бути там, доки ці рахунки відкриті. Коли рахунки закриваються, ці ламппорти повертаються їхнім власникам.

Пов'язані ресурси з архітектури Solana

Рахунки токенів легше зрозуміти разом з Solana Program Library, тоді як паралелізм пояснюється в посібнику з паралельної обробки Sealevel. Читачі можуть переглянути сторінку з ціною SOL;), а користувачі, що оцінюють продукти, пов'язані зі стейкінгом, можуть окремо переглянути SOL Earn,), включаючи його поточні умови та ризики.

FAQ: Модель облікових записів Solana

Яка різниця між рахунками Solana та рахунками Ethereum?

В Ethereum смартконтракт зберігає як свій код, так і свій стан за однією адресою. У Solana код і стан завжди знаходяться в окремих рахунках: програми – це безстатусні виконувані рахунки, а весь стан знаходиться на окремих рахунках даних, якими володіють ці програми. Це розділення дозволяє Sealevel паралельно виконувати несумісні транзакції, що неможливо за моделлю спільного стану Ethereum.

Що таке орендна плата (rent) у Solana і як вона працює?

Орендна плата в Solana – це вартість зберігання даних у мережі, що вимірюється в ламппортах. Замість сплати поточних комісій, рахунки повинні внести авансом мінімальний баланс ламппортів, поріг звільнення від орендної плати, щоб уникнути видалення середовищем виконання. Депозит можна отримати назад: при закритті рахунка ламппорти повертаються власнику. Для стандартного рахунку токена розміром 165 байтів депозит становить приблизно 0,00204 SOL за поточними параметрами мережі.

Що таке Program Derived Address (PDA) у Solana?

PDA – це адреса рахунку Solana, детерміновано виведена з ідентифікатора програми та набору значень насіння (seeds). Вона не має відповідного приватного ключа, тому лише програма, яка її вивела, може авторизувати транзакції від її імені через Cross-Program Invocation (CPI). PDA надають програмам автономний, довірчий контроль над рахунками, що є вимогою для DeFi протоколів, NFT ескроу-рахунків та Associated Token Accounts.

Як модель облікових записів Solana забезпечує паралельну обробку?

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

Що таке поле owner (власник) у рахунку Solana?

Поле owner – це 32-байтний відкритий ключ, який ідентифікує програму, що має повноваження змінювати поле даних рахунку. Для гаманцевих рахунків власником є System Program. Для рахунків токенів власником є SPL Token Program. Поле owner є концепцією рівня протоколу, яка примусово застосовується середовищем виконання Solana. Воно відрізняється від поля "authority" (повноваження), яке знаходиться всередині певних керованих програмою рахунків даних, таких як рахунки токенів.

Як SOL використовується в моделі облікових записів?

SOL використовується в моделі облікових записів через три механізми: кожен рахунок повинен мати баланс ламппортів (SOL) для існування в мережі; створення рахунків вимагає SOL для фінансування депозиту звільнення від орендної плати; і валідатори, які обробляють і зберігають стан рахунків, повинні внести SOL в стейкінг для участі в консенсусі. З ростом мережі структурний попит на SOL також зростає.

Що таке Sealevel і як воно пов'язане з рахунками?

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

Яка різниця між гаманцевим рахунком та рахунком програми на Solana?

Гаманцевий рахунок – це рахунок, керований системою, з порожнім полем даних, який містить лише баланс SOL, керований ключовою парою. Рахунок програми – це виконуваний рахунок з executable = true, який містить скомпільований байт-код BPF/SBF; він належить BPF Loader і не містить власного стану. Таблиця типів рахунків у розділі П'ять типів рахунків Solana показує всі п'ять варіантів пліч-о-пліч.

Скільки рахунків може посилатися одна транзакція Solana?

Одна транзакція Solana може посилатися до 64 рахунків за поточними параметрами основної мережі (Mainnet), що збільшено з попередніх 32 через Address Lookup Tables. Кожен рахунок повинен бути оголошений як тільки для читання або для читання/запису перед початком виконання. Це попереднє оголошення дозволяє Sealevel планувати паралельне виконання без запуску транзакцій для виявлення конфліктів.

Чи може один рахунок Solana містити кілька токенів?

Ні. Кожен тип токена SPL вимагає окремого рахунку токена. Адреса гаманця містить лише SOL; кожен додатковий токен вимагає окремого рахунку токена, пов'язаного з гаманцем через його поле повноважень (authority). Ось чому гаманці Solana запитують вас створити новий рахунок токена при отриманні токена, якого ви раніше не мали, і чому це створення коштує невеликий депозит ламппортів, звільнений від орендної плати.

Основні висновки

• Кожен елемент ончейн-стану в Solana знаходиться на рахунку з п'ятьма полями: lamports, data, owner, executable, rent_epoch.
• Програми є безстатусними. Весь стан знаходиться на окремих рахунках даних, якими володіють та контролюють програми.
• Для збереження на мережі рахункам потрібен депозит ламппортів (звільнення від орендної плати). Депозит можна отримати назад при закритті рахунка.
• PDA (Program Derived Addresses) – це адреси без приватного ключа, детерміновано виведені з ідентифікатора програми та насіння (seeds), підписувати які може лише програма, що їх створила, через CPI (Cross-Program Invocation).
• Кожна транзакція заздалегідь оголошує свій список доступу до рахунків. Sealevel використовує ці оголошення для одночасного виконання несумісних транзакцій.

Наступні кроки

• Щоб дізнатися специфіку реалізації, див. документацію Solana по рахунках) на docs.solana.com.
• Розробники, які створюють свою першу програму Solana, можуть почати з фреймворку Anchor,), який абстрагує значну частину стандартного коду управління рахунками (програми пишуться на Rust або C/C++).
• Для практичних рецептів коду та робочих прикладів на JavaScript/TypeScript, Solana Cookbook) надає практичні довідкові матеріали.