Модель аккаунтов Solana: Техническое руководство

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

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

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

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

Обзор модели аккаунтов Solana

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

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

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

Если вы пришли из Ethereum, это различие имеет значение: смарт-контракты Ethereum хранят свое состояние внутри, тогда как программы Solana являются без сохранения состояния. Полное сравнение приведено в отдельном разделе ниже.

Анатомия аккаунта Solana

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

Пять полей каждого аккаунта Solana

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

lamports: баланс SOL для этого аккаунта, выраженный в Lamports (наименьшая дробная единица SOL, объяснение в следующем разделе). В аналогии с картотекой это денежная стоимость, проставленная на обложке папки.

data: необработанный массив байтов (Vec<u8>), который хранит любое состояние, необходимое владеющей программе. Для программного аккаунта это поле содержит скомпилированный байт-код BPF. Для аккаунта данных оно содержит сериализованное состояние приложения. Программы определяют собственный формат сериализации (обычно Borsh) для чтения и записи структурированных данных в это поле. Эквивалент в картотеке — физическое содержимое папки.

owner: публичный ключ программы, уполномоченной изменять поле данных этого аккаунта. Никакая другая программа не может записывать в него. Это метка отдела на обложке папки.

executable: булев флаг. Если установлено значение true, аккаунт хранит программный код и может быть выполнен. Если false, аккаунт является контейнером данных.

rent_epoch: устаревшее поле, которое ранее отслеживало время сбора арендной платы. Это поле выводится из эксплуатации и не несет операционной значимости для аккаунтов, освобожденных от арендной платы, что является производственным стандартом.

Каждый аккаунт Solana идентифицируется уникальным 256-битным публичным ключом, полученным из пары ключей ed25519, который служит как его адресом, так и идентификатором в блокчейне. Максимальный размер поля данных для одного аккаунта составляет 10 МБ после недавних обновлений протокола; проверяйте текущие ограничения в документации Solana по аккаунтам,), так как это значение менялось на протяжении истории Solana.

Lamports: Наименьшая единица Solana

Lamport — это наименьшая дробная единица SOL: 1 SOL равен 1 000 000 000 Lamports (10⁹). Единица названа в честь Лесли Лампорта, ученого-компьютерщика, чьи работы по распределенным системам и отказоустойчивости лежат в основе большей части современной теории распределенных вычислений. Lamports существуют, потому что вся арифметика в блокчейне, включая расчеты арендной платы, комиссии за транзакции и балансы аккаунтов, должна использовать целочисленную арифметику, чтобы избежать ошибок точности чисел с плавающей запятой. Выражение значений в Lamports делает каждый расчет точным.

Является ли аккаунт Solana тем же, что и кошелек?

Аккаунт Solana и кошелек — это не одно и то же. То, что вы считаете своим кошельком, приложение Phantom или Solflare на вашем телефоне, — это офчейн-программное обеспечение, управляющее приватным ключом. Сущность в блокчейне — это системный аккаунт, который хранит ваш баланс SOL. Ваш кошелек управляет системным аккаунтом; сам по себе он не является аккаунтом. Аккаунты токенов, программные аккаунты и аккаунты данных не имеют эквивалента кошелька: они являются чисто ончейн-контейнерами данных, которые ни одно клиентское кошельковое приложение напрямую не представляет.

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

1. Системные аккаунты: принадлежат Системной программе; используются для хранения SOL и кошельков пользователей
2. Программные аккаунты: исполняемые аккаунты, хранящие скомпилированный байт-код BPF
3. Аккаунты данных/состояния: принадлежат программам; хранят специфическое состояние приложения
4. Аккаунты токенов: специализированные аккаунты данных, принадлежащие SPL Token Program (с Associated Token Accounts в качестве канонического подмножества)

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

Системная программа имеет известный адрес: 11111111111111111111111111111111 (32 единицы в base58). См. документацию Системной программы) для полного набора инструкций. Когда разработчик создает аккаунт данных для своей программы, он вызывает инструкцию Create Account Системной программы, указывая размер данных, депозит lamports для освобождения от арендной платы и публичный ключ новой владеющей программы.

Программные аккаунты хранят скомпилированный байт-код BPF, а не состояние. Флаг исполнения (executable) в этих аккаунтах установлен в значение true. Программы не имеют состояния: когда программа запускается, она получает список аккаунтов для чтения или записи через инструкцию транзакции. Она не сохраняет никакого внутреннего состояния между вызовами. Если вы перешли с Ethereum, то можете знать исполняемый ончейн-код как смарт-контракты, но программы Solana работают принципиально иначе, поскольку не несут собственного состояния. Программные аккаунты принадлежат программе BPF Loader. После развертывания программный аккаунт является неизменяемым, если при развертывании не была назначена пара ключей полномочий по обновлению.

Аккаунты данных и состояния

Аккаунты данных содержат состояние приложения, которое программы считывают и записывают во время выполнения. Флаг исполнения в этих аккаунтах имеет значение false. Поле данных хранит определенное программой состояние, сериализованное с помощью Borsh. Примеры включают кредитную позиция пользователя в протоколе DeFi, метаданные NFT или счетчик приложения. Программа-владелец — единственная сущность, которая может записывать данные в поле данных этого аккаунта; это правило подробно описано в разделе о владении.

Токен-аккаунты и ассоциированные токен-аккаунты

Токен-аккаунты — это аккаунты данных, принадлежащие программе SPL Token, каждый из которых хранит баланс одного конкретного токена для одного конкретного кошелька. Один адрес кошелька может содержать несколько токен-аккаунтов, по одному для каждого типа токена, которым он владеет.

Ассоциированный токен-аккаунт (ATA) — это канонический токен-аккаунт для конкретной пары [адрес кошелька, адрес минта]. ATA детерминированно выводятся как программно-производный адрес (PDA), используя адрес кошелька и адрес минта токена в качестве сидов (seeds). Это гарантирует, что у каждого кошелька есть ровно один «официальный» аккаунт для каждого типа токена. ATA являются стандартом, используемым такими кошельками, как Phantom и Solflare, биржами и протоколами: когда вы получаете токен в интерфейсе своего кошелька, он попадает на ваш ATA для этого токена.

Если ATA не существует для данной пары [кошелек, минт], он должен быть создан до того, как токены могут быть получены, а создание стоит аренды в виде внести Lamport. Вот почему некоторые транзакции включают небольшую «комиссию за создание аккаунта» в интерфейсах кошельков. Полную спецификацию ATA см. в документации SPL Associated Token Account.). ATA является токен-аккаунтом, но не каждый токен-аккаунт является ATA, и это различие имеет значение при отладке программ, связанных с токенами.

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

Владение аккаунтом в Solana — это механизм полномочий на запись, а не концепция владения активами.

Правило владения

Только программа-владелец аккаунта может изменять его поле данных. Никакая другая программа не может производить в него запись, независимо от того, что пользователь разрешает на уровне транзакции. Поле владельца в AccountInfo хранит публичный ключ программы, обладающей этими полномочиями. Программы, не являющиеся владельцами, могут свободно читать поле данных, но для записи требуется быть назначенным владельцем.

Системная программа назначает владельца при создании аккаунта. Когда разработчик создает аккаунт данных для своей программы, инструкция Create Account устанавливает в поле владельца публичный ключ их программы. Владение может быть переназначено, но только текущей программой-владельцем с помощью инструкции Assign. Никакая внешняя сторона не может передать владение в одностороннем порядке.

Владелец против полномочий: критическое различие

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

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

Владение на практике: пример DEX

Программа DEX может записывать данные только в те аккаунты, которыми она владеет напрямую. Чтобы перевести токены с токен-аккаунта пользователя (которым владеет программа SPL Token, а не DEX), DEX не может записывать данные в этот аккаунт напрямую. Программы могут вызывать другие программы в рамках одной транзакции — паттерн под названием Cross-Program Invocation (CPI), позволяющий DEX дать инструкцию программе Token переместить токены от имени пользователя. DEX отправляет CPI программе Token, предоставляя подписанную авторизацию пользователя, и программа Token выполняет запись в поле данных токен-аккаунта пользователя. Именно так модель владения программами распространяется на межпрограммные взаимодействия. Полное руководство см. в гайде по Cross-Program Invocation (CPI) для разработчиков Solana.

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

Аренда (rent) в Solana — это механизм стоимости хранения, а не периодическая плата.

Что такое аренда?

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

Освобождение от аренды: практический стандарт

Освобождение от аренды является производственным стандартом для всех развернутых аккаунтов Solana. Минимальный баланс для освобождения от аренды составляет примерно 6 960 лампортов, умноженных на размер данных аккаунта в байтах, плюс базовая сумма примерно в 890 880 лампортов для аккаунта с нулевым размером данных.

Пример расчета: для аккаунта с данными 100 байт требуется примерно 890 880 + (6 960 × 100) = 1 586 880 лампортов, или около 0,00159 SOL. Эти цифры являются приблизительными и могут быть изменены. Проверьте текущие значения с помощью команды Solana CLI solana rent <bytes> или в документации по аренде Solana.). Предлагаемое изменение по конвертации аренды в модель комиссий за транзакции не было активировано на момент написания статьи; обратитесь к текущей документации для уточнения статуса протокола.

Что происходит, когда в аккаунте заканчиваются SOL?

Создание текущего аккаунта обычно требует финансирования, освобождающего от аренды. Разработчикам следует запрашивать текущие требования RPC, а не полагаться на устаревшее поведение по сбору арендной платы. Именно это поведение вызывает опасения по поводу «удаления» аккаунтов.

Аккаунты, освобожденные от аренды, никогда не закрываются средой выполнения автоматически. Производственные аккаунты всегда финансируются до порога освобождения от аренды, поэтому сбор мусора их не затрагивает. Намеренное закрытие аккаунтов — это отдельный, осознанный паттерн: программы могут закрывать аккаунты данных, чтобы вернуть Lamport, внесенные в качестве депозита. Например, в протоколе DeFi закрытие кредитной позиции возвращает SOL, которые финансировали аккаунт данных этой позиции, обратно пользователю. Это распространенный паттерн проектирования протоколов, а не принудительное удаление.

Объяснение программно-производных адресов (PDA)

Программно-производные адреса решают конкретную проблему: как программа может управлять аккаунтом без наличия у кого-либо соответствующего приватного ключа.

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

Программно-производный адрес (PDA) — это детерминированно сгенерированный адрес аккаунта, полученный из ID программы и одного или нескольких значений сидов с использованием хеширования SHA-256. PDA намеренно размещены вне эллиптической кривой ed25519, что означает отсутствие у них соответствующего приватного ключа. Только владеющая программа может подписывать транзакции для аккаунтов по адресам PDA. Полную спецификацию см. в документации по PDA Solana).

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

Почему PDA имеют значение: Управление учетными записями программой

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

Сравните это со стандартными учетными записями на основе пар ключей, где тот, кто владеет приватным ключом, контролирует учетную запись. Если ключ утерян, доступ потерян. Если ключ украден, учетная запись скомпрометирована. PDA полностью устраняют эту зависимость. Логика программы является хранителем, проверяемый код, а не человек.

Три реальных сценария использования PDA

PDA встречаются в трех повторяющихся шаблонах в программах Solana.

DEX эскроу-счета: программа децентрализованной биржи хранит токены в PDA до тех пор, пока обе стороны обмена не выполнят необходимые условия. Ни один доверенный посредник не владеет приватным ключом к эскроу. Логика программы контролирует выпуск, и ни один участник не может вывести средства вне правил протокола.

Ни один человек не может совершить "раг пул" в отношении полномочий на выпуск (NFT) коллекции. NFT полномочия на выпуск работают следующим образом: программы Metaplex контролируют выпуск через PDA, полученный из адреса выпуска. Поскольку для этого PDA не существует приватного ключа, правила выпуска коллекции после развертывания применяются только кодом программы.

Как программа хранит данные для каждого пользователя, не поддерживая централизованный индекс? Хранение состояния для каждого пользователя использует уникальный PDA, полученный из [program_id, user_pubkey]. Это создает детерминированный, специфичный для пользователя адрес учетной записи для хранения счета игры пользователя, его позиции по кредитованию или записи о стейкинге. Программа всегда знает, где найти данные каждого пользователя.

Функции findProgramAddress() и createProgramAddressSync() определяют допустимые адреса вне кривой, тестируя кандидатские адреса с увеличивающимся начальным значением (bump seed) до тех пор, пока один из них не окажется вне кривой.

Когда следует использовать PDA?

Используйте PDA всякий раз, когда вашей программе необходимо управлять учетной записью, не полагаясь на приватный ключ человека. Если полномочия над учетной записью должна осуществлять логика программы, а не человек, используйте PDA. Это правило охватывает эскроу-счета, хранилища протоколов, полномочия на выпуск и любое состояние, которым программа сама должна владеть и управлять для нескольких пользователей.

Solana против Ethereum: Сравнение моделей учетных записей

Основное различие между моделями учетных записей Solana и Ethereum заключается в том, где находится состояние.

В Ethereum смарт-контракты являются типобезопасными: они хранят свое собственное состояние внутри вместе со своим кодом. Контракт Solidity хранит свои собственные отображения (mappings) и переменные состояния в хранилище контракта, управляемом виртуальной машиной Ethereum (EVM). В Solana программы являются без состояний; все состояние находится во внешних учетных записях, которые программы считывают и записывают во время выполнения. В то время как Ethereum выполняет программы в EVM, Solana использует среду выполнения на основе BPF, которая выполняет программы против учетных записей, объявленных заранее в транзакции.

Компромиссы идут в обе стороны. Модель состояний Ethereum имеет реальное преимущество в опыте разработчика: более простая ментальная модель, отсутствие явного управления учетными записями, меньшие когнитивные затраты для многих вариантов использования. Разработчик может написать и развернуть контракт ERC-20, не задумываясь о размере учетной записи данных, освобождении от арендной платы или выводе PDA.

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

Почему эта архитектура важна: Sealevel и параллельное выполнение

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

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

Анатолий Яковенко разработал архитектуру Solana с явной целью параллельной обработки транзакций, и разделение логики программы от состояния учетной записи делает это возможным. Модель учетных записей работает в сочетании с другими архитектурными инновациями Solana, включая Proof of History (PoH), механизм криптографических часов Solana. Чтобы понять, как PoH способствует увеличению пропускной способности, см. объяснение работы Proof of History в архитектуре Solana.

Работа с учетными записями: Реализация для разработчика

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

Создание учетной записи с помощью системной программы

Программы Solana пишутся на Rust, системном языке программирования, и компилируются в байт-код BPF перед развертыванием. Создание учетной записи в Solana включает следующие шаги, каждый из которых соответствует параметру в инструкции Create Account системной программы:

1. from_pubkey: идентификатор учетной записи, финансирующей создание (плательщик)
2. new_account_pubkey: указание адреса новой учетной записи
3. lamports: расчет суммы баланса, освобожденного от аренды, на основе размера данных
4. space: установка размера данных в байтах для выделения учетной записи
5. owner: указание публичного ключа программы, которая будет владеть этой учетной записью и записывать в нее

// Создание новой учетной записи данных с использованием системной программы
let create_account_ix = system_instruction::create_account(
    &payer.pubkey(),         // from_pubkey: кто финансирует эту учетную запись
    &new_account.pubkey(),   // new_account_pubkey: адрес учетной записи
    rent_exempt_balance,     // lamports: достаточно для освобождения от аренды
    data_size as u64,        // space: байты, выделенные для данных учетной записи
    &program_id,             // owner: программа, которая контролирует эту учетную запись
);

Эта инструкция устанавливает право собственности на учетную запись. После ее выполнения только программа по адресу program_id может записывать в поле данных этой учетной записи.

Использование фреймворка Anchor

Многие программы Solana создаются с использованием фреймворка Anchor, который предоставляет структурированные макросы для определения ограничений учетных записей и инструкций программы. Полный справочник по фреймворку см. в документации Anchor.

// Anchor: определяет ограничения учетной записи с помощью макроса #[derive(Accounts)]
#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,                        // создать эту учетную запись, если она не существует
        payer = user,                // пользователь оплачивает депозит, освобожденный от арендной платы
        space = 8 + MyData::LEN,    // 8-байтовый дискриминатор + размер данных
    )]
    pub my_account: Account<'info, MyData>,     // новая учетная запись данных
    #[account(mut)]
    pub user: Signer<'info>,                    // подписант транзакции и плательщик
    pub system_program: Program<'info, System>, // требуется для создания учетной записи
}

Anchor автоматически обрабатывает шаблонные проверки учетных записей, проверяя владение и статус подписанта перед выполнением вашей логики инструкций. Понимание базовой модели учетных записей остается необходимым при отладке ошибок владения или проектировании структур PDA, поскольку макросы Anchor являются абстракциями над теми же механизмами, которые описаны в этой статье.

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

Разработчики, ищущие более короткий путь реализации, могут воспользоваться руководством по модели учетных записей Solana для разработчиков; соглашения по программному обеспечению токенов освещаются в обзоре Solana Program Library. Страница цен SOL) и спот-рынок SOL/USDT) касаются доступа к рынку, а не владения учетной записью или полномочий программы.

FAQ: Модель учетных записей Solana: Техническое руководство

Что такое учетная запись в Solana?

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

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

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

Адрес, производный от программы (PDA), — это детерминированно сгенерированный адрес учетной записи, полученный из идентификатора программы и значений начальных значений с использованием хэширования SHA-256. PDA находятся за пределами эллиптической кривой ed25519, поэтому у них нет соответствующего приватного ключа. Только владеющая программа может подписывать транзакции для учетных записей по адресам PDA, что обеспечивает доверенное хранение, контролируемое программой, для эскроу-счетов, полномочий эмиссии и хранения состояния для каждого пользователя.

Создание текущих учетных записей обычно требует финансирования, освобожденного от арендной платы. Разработчики должны запрашивать текущие требования RPC вместо того, чтобы полагаться на устаревшее поведение сбора арендной платы. Правильно развернутые производственные учетные записи всегда финансируются до порога освобождения от арендной платы и никогда автоматически не удаляются сборщиком мусора. Программы также могут намеренно закрывать учетные записи для возврата депозита SOL, что является распространенным шаблоном в протоколах DeFi.

Лампы — это наименьшая денежная единица SOL на блокчейне Solana: 1 SOL равен 1 000 000 000 Ламп (10⁹). Названные в честь Лесли Лампорта, пионера распределенных вычислений, лампы используются для всех балансов SOL, комиссий за транзакции и расчетов арендной платы ончейн. Деноминирование сумм в лампах позволяет избежать ошибок точности чисел с плавающей запятой, которые возникли бы при использовании дробных значений SOL в ончейн арифметике.

Системная программа — это нативная программа Solana, отвечающая за три основные операции: создание новых учетных записей (выделение места для данных ончейн), назначение владения учетной записью (установка поля владельца на указанную программу) и перевод SOL между системными учетными записями. Каждая новая учетная запись Solana начинается как системная учетная запись. Разработчики вызывают инструкцию Create Account Системной программы для предоставления учетных записей данных для своих программ.

Существует три основных типа учетных записей Solana: (1) Системные учетные записи, принадлежащие Системной программе и используемые для балансов SOL и кошельков пользователей; (2) Программные учетные записи, исполняемые учетные записи, хранящие скомпилированный байт-код BPF; (3) Учетные записи данных/состояния, принадлежащие программам и хранящие состояние, специфичное для приложения. Учетные записи токенов являются специализированным подмножеством учетных записей данных, принадлежащих SPL Token Program.

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

• Каждый фрагмент состояния в Solana находится в учетной записи; программы считывают и записывают данные в учетные записи, переданные во время выполнения, а не во внутреннее хранилище
• Каждая учетная запись имеет пять полей: лампы, данные, владелец, исполняемый флаг и устаревшая эпоха аренды
• Только программа-владелец может изменять поле данных учетной записи; это основной механизм контроля доступа Solana
• Производственные учетные записи финансируются до порога освобождения от арендной платы и никогда автоматически не собираются средой выполнения
• Адреса, производные от программы (PDA), обеспечивают доверенное хранение, контролируемое программой, используя адреса вне кривой, не имеющие приватного ключа
• Среда выполнения Solana Sealevel распараллеливает выполнение транзакций, анализируя объявленные списки доступа к учетным записям в рамках неконфликтующих транзакций

Готовы строить на этой основе? Продолжайте с:

• Как работают программы Solana: руководство для разработчиков по безстатутному выполнению
• Руководство по фреймворку Anchor для создания программ Solana
• Объяснение межпрограммных вызовов (CPI): как программы Solana вызывают друг друга
• Как работает Proof of History в архитектуре Solana

Для получения последних спецификаций протокола по размерам учетных записей, расчетам арендной платы и поведению среды выполнения обратитесь напрямую к официальной документации Solana по учетным записям.