Модель аккаунтов Solana: Объяснение

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

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

Если вы пришли из мира Ethereum, модель аккаунтов Solana поначалу покажется вам перевернутой. Такая реакция — правильная отправная точка. Мысленная модель, которую вы построили на Ethereum, не переносится напрямую, и попытка навязать ее создает путаницу на каждом шагу.

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

Представьте Solana как глобальную систему файлов. Каждый фрагмент данных находится в отдельном файле, называемом аккаунтом. Программы — это приложения, которые читают и записывают эти файлы, но программа может изменять только тот файл, которым она владеет. Среда выполнения принудительно применяет эти правила владения на уровне протокола, без исключений.

Эта статья охватывает пять полей внутри каждого аккаунта Solana, пять различных типов аккаунтов, как работают аренда (rent) и освобождение от аренды (rent exemption), что такое адреса, выводимые из программ (Program Derived Addresses, PDAs) и почему они существуют, как создаются и закрываются аккаунты, а также почему эта архитектура делает возможной параллельную обработку транзакций в Solana. Программы Solana написаны на Rust (или C/C++), хотя фреймворки, такие как Anchor, абстрагируют большую часть стандартного кода управления аккаунтами. Эта статья охватывает концептуальную основу, требуемую обоими.

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

Аккаунт Solana — это маркированное хранилище в сети, которое содержит баланс в ламппортах, произвольные данные и набор метаданных, определяющих, кто им владеет и что с ним можно делать. В Solana все данные, от балансов кошельков до состояния программ и владений токенами, хранятся в аккаунтах.

Лампорты — это наименьшая доля SOL, нативного токена сети. Лампорты относятся к SOL так же, как копейки к доллару, но с девятью знаками после запятой: 1 SOL равен 1 000 000 000 лампортов. Каждый аккаунт имеет баланс лампортов, который финансирует его дальнейшее существование в сети и представляет собой передаваемую стоимость.

Каждый аккаунт Solana содержит ровно пять полей:

• lamports (u64): баланс аккаунта в лампортах. Это поле финансирует аренду и может быть переведено на другие аккаунты.
• data (массив байт): необработанное бинарное хранилище. В исполняемых аккаунтах это поле содержит скомпилированный байт-код BPF/SBF. В аккаунтах данных оно содержит структурированное состояние приложения. Максимальный размер поля данных составляет 10 МБ при текущих параметрах мейннета.
• owner (Pubkey): 32-байтный публичный ключ программы, которая имеет исключительное право на запись данных в это поле. Это самое контринтуитивное поле для разработчиков Ethereum. Ваш адрес кошелька на уровне протокола принадлежит не вам; он принадлежит Системной программе (System Program). Полное описание поля owner представлено в разделе владение аккаунтом и полномочия.
• executable (bool): булевый флаг. Если true, поле data содержит байт-код программы, и аккаунт функционирует как программа. Если false, аккаунт хранит состояние или баланс.
• rent_epoch (u64): устаревшее поле, которое отслеживало эпоху, когда в последний раз собиралась аренда. По состоянию на 2024 год сбор аренды устарел в пользу модели освобождения от аренды по умолчанию. Это поле сохраняется в структуре аккаунта, но больше активно не используется.

Вот как выглядит аккаунт кошелька в виде структуры данных:

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

Поле owner — это концепция на уровне протокола: программа, контролирующая доступ на запись к полю data. Полномочия (Authority) — это отдельная конвенция, хранящаяся внутри управляемых програм данных, например, поле transfer authority в аккаунте токена. Это не одно и то же; раздел владения точно определяет это различие.

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

В Solana существует пять различных типов аккаунтов, каждый из которых выполняет определенную архитектурную роль, определяемую полем owner и флагом executable. Тип не хранится как отдельное поле; он выводится из того, кто владеет аккаунтом, и содержит ли он исполняемый код.

Аккаунты, принадлежащие системе (Кошельки)

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

Аккаунты программ (Исполняемые аккаунты)

Аккаунт программы — это исполняемый аккаунт, содержащий скомпилированный байт-код BPF/SBF. Флаг executable установлен в true, а владельцем является BPF Loader. Аккаунты программ по своей сути не имеют состояния; они содержат только код, но никогда не хранят состояние. В Ethereum смарт-контракт хранит как свой код, так и свое состояние по одному адресу контракта. В Solana код находится в аккаунте программы, а состояние — в отдельных аккаунтах данных, всегда хранимых отдельно.

Аккаунты программ могут хранить исполняемый код, при этом executable = true и байт-код BPF/SBF в поле data. Неисполняемые аккаунты данных имеют executable = false и вместо этого хранят состояние.

Аккаунты данных (Аккаунты, принадлежащие программам)

Аккаунт данных — это неисполняемый аккаунт, принадлежащий конкретной программе, который хранит состояние программы в своем поле data. Флаг executable установлен в false. Владельцем является та программа, которая создала и управляет аккаунтом. Ваш баланс токенов USDC, кредитная позиция DeFi, запись метаданных NFT: каждое из них находится в своем собственном аккаунте данных, принадлежащем соответствующей программе.

Нативные аккаунты программ — это встроенные программы, развернутые по фиксированным адресам во время создания сети. К ним относятся Системная программа (System Program), BPF Loader, Vote Program и Stake Program. Это программы основной инфраструктуры, которые пользователи не могут заменить или обновить. Их флаг executable установлен в true.

Sysvar аккаунты

Sysvar аккаунты — это аккаунты только для чтения, предварительно заполненные средой выполнения Solana, которые предоставляют программам доступ к текущему состоянию сети. Думайте о Sysvar аккаунтах как о государственной доске объявлений в суде: общедоступные для чтения, поддерживаемые авторитетным источником, но ни одна частная сторона не может их изменять. Sysvar Clock по адресу SysvarC1ock11111111111111111111111111111111 предоставляет текущее время блока и номер слота. Sysvar Rent предоставляет текущие параметры аренды.

Программы в Solana не имеют состояния (stateless). Все состояние хранится в аккаунтах данных, которыми они владеют и управляют. Это разделение логики и состояния является проектным решением, которое делает возможным все остальное, описанное в этой статье.

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

Программы Solana не имеют собственного состояния. Они не хранят никаких собственных данных, и каждый фрагмент состояния, с которым они работают, живет в отдельных аккаунтах данных, передаваемых программе во время выполнения.

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

Четыре свойства определяют, как программы Solana взаимодействуют с аккаунтами:

• Программы обрабатывают инструкции и читают из аккаунтов или записывают в аккаунты, переданные им во время вызова. Они не хранят собственное состояние.
• Программы являются неизменяемыми после развертывания, если только разработчик не выбрал обновляемый загрузчик (upgradeable loader) во время развертывания.
• Только программа, владеющая аккаунтом данных, может изменять поле данных этого аккаунта. Любой пользователь может вызвать программу, но доступ на запись в любой аккаунт ограничивается владением.
• Флаг executable обеспечивает это различие на уровне протокола и не может быть изменен после развертывания.

Программы Solana не имеют состояния, но система Solana в целом является системой с состоянием. Состояние сохраняется; оно живет в аккаунтах данных. Разница в том, что состояние всегда внешне по отношению к программе и никогда не упаковывается внутри нее.

Это разделение влияет на производительность. Поскольку каждая транзакция должна объявить, какие аккаунты она будет читать или записывать до начала выполнения, среда выполнения Sealevel может идентифицировать непересекающиеся транзакции и запускать их одновременно. Полное объяснение того, как модель аккаунтов обеспечивает параллельное выполнение, приведено ниже.

Владение аккаунтом и полномочия: кто и чем управляет в Solana

Поле владельца (owner) в аккаунте Solana идентифицирует программу, которая имеет исключительное разрешение на изменение данных этого аккаунта. Только эта программа на уровне протокола может записывать данные в поле data.

В поле владельца хранится 32-байтовый публичный ключ программы. Для аккаунтов кошельков владельцем является System Program. Для токен-аккаунтов владельцем является программа SPL Token. Для пользовательских аккаунтов данных владельцем является та программа, которая их создала. Владение устанавливается при создании аккаунта и обеспечивается средой выполнения Solana при каждой транзакции.

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

Различие между владельцем (owner) и полномочным лицом (authority) сбивает с толку многих разработчиков Ethereum:

• Владелец (Owner) (поле протокола): ID программы, которая может изменять поле data аккаунта. Устанавливается при создании аккаунта. Обеспечивается средой выполнения Solana, а не логикой какой-либо программы.
• Полномочное лицо (Authority) (соглашение о данных): публичный ключ, хранящийся внутри поля data аккаунта владеющей программой. Он авторизует определенные операции в рамках логики этой программы. Обеспечивается самой программой, а не средой выполнения.

Для токен-аккаунта USDC владельцем является программа Token Program, и она может изменять баланс, хранящийся в поле данных. Ваш кошелек является полномочным лицом по переводу (transfer authority) — публичным ключом, записанным внутри поля данных, который программа Token Program проверяет перед выполнением перевода. Это разные ключи, выполняющие разные функции. Их смешение — одна из самых распространенных ошибок при разработке на Solana для новичков.

Арендная плата (Rent) и освобождение от аренды в Solana: объяснение

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

Что такое арендная плата (Rent) в Solana?

Валидаторы должны хранить все состояния активных аккаунтов в памяти. Неограниченное количество аккаунтов с нулевым балансом стало бы вектором DoS-атаки на сеть, поэтому Solana требует, чтобы аккаунты имели минимальный баланс в лампортах в качестве обязательства по оплате расходов на хранение. Первоначальная модель аренды взимала плату за каждую эпоху пропорционально размеру данных, при этом аккаунты с балансом ниже минимума подлежали удалению (сбору мусора). Эта модель устарела.

Согласно текущим параметрам мейннета Solana (формализованным в SIMD-0084), все новые аккаунты должны быть освобождены от аренды при создании. Поле rent_epoch в структуре аккаунта теперь является устаревшим полем.

Как работает освобождение от аренды

Чтобы сделать ваш аккаунт освобожденным от аренды, пополните его как минимум на минимальный баланс в лампортах для его размера данных при отправке транзакции на создание. При текущих параметрах сети:

• Аккаунт 0 байт (кошелек): примерно 890 880 лампортов (~0,00089 SOL)
• Аккаунт 165 байт (стандартный токен-аккаунт): примерно 2 039 280 лампортов (~0,00204 SOL)
• Аккаунт данных 1024 байта: примерно 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 (Unspent Transaction Output). UTXO похожи на необналиченные чеки в чековой книжке: каждая транзакция потребляет существующие выходы и создает новые. Не существует постоянного аккаунта, хранящего баланс с течением времени. Ваш баланс — это сумма неизрасходованных выходов, связанных с вашими ключами. Модель Bitcoin предшествовала концепции программируемого состояния, поэтому возможности его смарт-контрактов ограничены языком Bitcoin Script.

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

В Ethereum кошельки пользователей называются Externally Owned Accounts (EOA). В Solana эквивалентом является аккаунт, принадлежащий системе и контролируемый парой ключей; механизм схож, но поле владельца явно установлено в System Program, а не подразумевается.

Что разработчикам Ethereum нужно переосмыслить

Три изменения ментальной модели необходимы перед написанием рабочего кода для Solana:

1. Программы не хранят свое собственное состояние. Его хранят аккаунты данных. Прекратите искать состояние по адресу программы.
2. Владелец вашего кошелька — это не вы на уровне протокола. Вы контролируете аккаунт, подписывая транзакции; System Program владеет полем данных.
3. Хранение не бесплатно. Каждый аккаунт данных требует депозита lamport для освобождения от арендной платы. Заложите эту стоимость в бюджет при разработке программ, создающих аккаунты.

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

Как модель аккаунтов обеспечивает скорость Solana: Sealevel и параллельное выполнение

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

Вот причинно-следственная цепочка, шаг за шагом:

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

EVM Ethereum выполняет транзакции последовательно по отношению к общему состоянию. Поскольку состояние контракта совмещено с кодом контракта, определение конфликтов чтения/записи потребовало бы выполнения транзакции первым, что делает статическое планирование невозможным до выполнения.

Представьте Sealevel как супермаркет со множеством кассовых рядов. Каждая транзакция — это покупатель с заявленным списком товаров. Пока два покупателя не тянутся за одним и тем же товаром, они обслуживаются одновременно. Solana заранее знает, что именно нужно каждой транзакции, поскольку модель аккаунтов принудительно требует такого объявления.

Proof of History (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 Program, которая владеет всеми токен-аккаунтами в сети. Ваш адрес кошелька содержит только SOL (lamports). Каждый токен, который вы держите, будь то USDC, JTO, BONK или любой другой, находится в своем собственном выделенном токен-аккаунте, принадлежащем SPL Token Program.

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

Вот почему кошельки Solana предлагают вам создать токен-аккаунт при получении нового токена впервые. Это создание требует депозита lamport, освобождающего от арендной платы, примерно в 0.00204 SOL для стандартного аккаунта размером 165 байт при текущих параметрах сети.

Associated Token Account (ATA) — это токен-аккаунт, адрес которого является PDA, детерминированно выведенным из адреса вашего кошелька и адреса минта токена. Поскольку адрес детерминирован, любой протокол может вычислить, где должен находиться ваш аккаунт USDC, без хранения таблицы поиска. ATA являются стандартным типом токен-аккаунтов, используемым практически всеми кошельками и протоколами Solana.

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

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

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

Почему модель аккаунтов Solana важна для SOL

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

Модель аккаунтов — это не только забота разработчиков. SOL, доступная на основных криптовалютных биржах, служит нативным служебным токеном сети. Модель аккаунтов является основным механизмом, посредством которого SOL востребован и используется на сетевом уровне.

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

Депозиты для освобождения от арендной платы: Каждый аккаунт в Solana должен поддерживать баланс lamport для существования в сети. При наличии миллионов токен-аккаунтов, аккаунтов данных программ, записей NFT и аккаунтов состояния DeFi, активных в любой момент времени, это создает постоянный базовый спрос на SOL. Эти lamports заблокированы в аккаунтах и выведены из ликвидной циркуляции до тех пор, пока аккаунты остаются открытыми.

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

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

По мере роста ончейн-активности — больше протоколов DeFi, больше коллекций NFT, больше запусков токенов — пропорционально растет и количество аккаунтов. Большее количество аккаунтов требует больше SOL, заблокированных в депозитах для освобождения от аренды.

Лампорты, заблокированные в аккаунтах с освобождением от аренды, функционируют как гарантийные депозиты, удерживаемые сетью: они не расходуются, но остаются заблокированными до тех пор, пока аккаунты открыты. Когда аккаунты закрываются, эти лампорты возвращаются их владельцам.

Связанные ресурсы по архитектуре Solana

Аккаунты токенов проще понять вместе с библиотекой программ Solana (SPL), а концепция параллелизма объясняется в руководстве по параллельной обработке Sealevel. Читатели могут ознакомиться со страницей цены SOL;), а пользователи, оценивающие продукты, связанные со стейкингом, могут отдельно изучить Bybit Earn,), включая текущие условия и риски.

FAQ: Модель аккаунтов Solana

В чем разница между аккаунтами Solana и аккаунтами Ethereum?

В Ethereum смарт-контракт хранит и свой код, и свое состояние по одному адресу. В Solana код и состояние всегда находятся в разных аккаунтах: программы — это исполняемые аккаунты без состояния, а все состояние живет в отдельных аккаунтах данных, принадлежащих этим программам. Это разделение позволяет Sealevel выполнять неконфликтующие транзакции параллельно, что невозможно в модели совмещенного состояния Ethereum.

Что такое аренда в Solana и как она работает?

Аренда в Solana — это стоимость хранения данных в сети, выраженная в лампортах. Вместо выплаты текущих комиссий аккаунты должны заранее внести минимальный баланс в лампортах — порог освобождения от аренды — чтобы избежать удаления средой исполнения. Депозит является возвратным: при закрытии аккаунта лампорты возвращаются владельцу. Для стандартного 165-байтового аккаунта токена депозит составляет примерно 0,00204 SOL при текущих параметрах сети.

Что такое программно-производный адрес (PDA) в Solana?

PDA — это адрес аккаунта Solana, полученный детерминированно из ID программы и набора значений «сидов» (seeds). У него нет соответствующего приватного ключа, поэтому только программа, которая его вывела, может авторизовать транзакции от его имени через кросс-программный вызов (CPI). PDA дают программам автономный, бездоверительный контроль над аккаунтами, что является обязательным требованием для протоколов DeFi, эскроу-сервисов NFT и ассоциированных токен-аккаунтов.

Как модель аккаунтов 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 аккаунта при текущих параметрах мейннета (количество было увеличено с первоначальных 32 с помощью таблиц поиска адресов — Address Lookup Tables). Каждый аккаунт должен быть объявлен как «только для чтения» или «для чтения и записи» до начала выполнения. Именно это предварительное объявление позволяет Sealevel планировать параллельное выполнение без предварительного запуска транзакций для обнаружения конфликтов.

Может ли один аккаунт Solana содержать несколько токенов?

Нет. Для каждого типа токена SPL требуется собственный выделенный аккаунт токена. Адрес кошелька содержит только SOL; для каждого дополнительного токена требуется отдельный аккаунт токена, связанный с кошельком через поле полномочий (authority). Вот почему кошельки Solana предлагают создать новый аккаунт токена при получении токена, который вы раньше не хранили, и почему создание требует небольшого депозита в лампортах для освобождения от аренды.

Основные тезисы

• Каждый фрагмент ончейн-состояния на Solana живет в аккаунте с пятью полями: lamports, data, owner, executable, rent_epoch.
• Программы не имеют состояния. Все состояние хранится в отдельных аккаунтах данных, которыми программы владеют и управляют.
• Для сохранения в сети аккаунтам требуется внести депозит в лампортах (освобождение от аренды). Депозит можно вернуть при закрытии аккаунта.
• PDA — это адреса без приватного ключа, детерминированно полученные из ID программы и «сидов» (seeds); они могут быть подписаны только создавшей их программой через CPI.
• Каждая транзакция заранее объявляет список доступа к аккаунтам. Sealevel использует эти объявления для одновременного выполнения неконфликтующих транзакций.

Следующие шаги

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