Solana (SOL): как работают транзакции и валидаторы

Состояние хранится в аккаунтах

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

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

Кошельки, токен-аккаунты и PDA

Адрес кошелька может владеть SOL и авторизовать транзакции, но баланс токена SPL обычно находится в токен-аккаунте, связанном с mint и владельцем. Адрес, производный от программы (Program Derived Address), детерминированно выводится из ID программы и seed; программа может авторизовать его через правила среды выполнения, хотя для этого адреса не существует закрытого ключа.

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

Сообщение, подписи и инструкции

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

Свежесть и подтверждение

Недавний blockhash предотвращает бессрочную действительность обычной транзакции. Если она истекает до обработки, транзакцию необходимо пересобрать и подписать заново; повторная трансляция старой подписи не создает новую транзакцию. Существуют рабочие процессы с постоянным nonce для специализированного офлайн- или отложенного подписания, требующие отдельной обработки.

Клиенты RPC предоставляют уровни подтверждения processed, confirmed и finalized. Быстрый интерфейс может показывать результаты processed до достижения более сильного согласия кластера. Депозиты, мосты и зависимые действия приложений должны ждать уровня, требуемого этой службой, и проверять подпись через актуальный RPC или обозреватель.

Базовая и приоритетная составляющие

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

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

Операционные проверки

Держите достаточно SOL для комиссии, даже если переводимый актив — это токен SPL. Проверяйте инструкции compute-budget, так как они могут изменить запрошенный лимит и приоритетную цену. Также различайте комиссии за транзакции, финансирование аккаунтов, связанные с арендой балансы, влияние цены при обмене и комиссии приложений; это отдельные затраты, даже если один кошелек суммирует их вместе.