Как работают транзакции в Solana?

Поскольку комиссия взимается при каждом выполнении транзакции, важно понимать, как транзакции устроены. Транзакция состоит из трёх частей:

одна или несколько инструкций
массив аккаунтов для чтения или записи
одна или несколько подписей
недавний blockhash или nonce

Инструкция — это наименьшая единица логики выполнения в Solana. Инструкции представляют собой вызов для обновления глобального состояния Solana. Инструкции вызывают программы, которые обращаются к среде выполнения Solana для обновления состояния (например, вызов token program для перевода токенов с вашего аккаунта на другой аккаунт). Инструкцию можно представить как вызов функции смарт-контракта Ethereum.

Существенное отличие между Ethereum и Solana заключается в количестве вызовов функций в одной транзакции — за счёт количества инструкций. Наличие нескольких инструкций в одной транзакции выгодно для разработчиков: им не нужно создавать кастомные смарт-контракты для объединения функций в одной транзакции. Каждая инструкция может быть отдельным вызовом функции, выполняемым последовательно в рамках транзакции. Транзакции являются атомарными: если любая из инструкций завершается неудачей, вся транзакция отклоняется, и вы платите только комиссию за транзакцию. Это аналогично провалу транзакции из-за неправильно установленного slippage в Ethereum.

Ещё одно ключевое отличие — использование недавнего blockhash вместо инкрементального nonce для транзакций. Когда кошелёк хочет выполнить транзакцию, из кластера запрашивается недавний blockhash для создания действительной транзакции. Этот недавний blockhash делает транзакцию действительной только в течение 150 блоков после его получения. Это предотвращает выполнение долгоживущих подписей транзакций в значительно более поздний момент времени.

Cross-Program Invocation (CPI)

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

Вызываемая программа наследует только те привилегии подписанта и записи, которые были у вызывающей программы, и расходует вычислительный бюджет той же транзакции. Используйте invoke, когда все необходимые подписанты подписали исходную транзакцию. Используйте invoke_signed, когда вызывающей программе нужно подписать от имени одного из своих Program Derived Address с помощью signer seeds.

Уровни подтверждения

Чтение через RPC, подписки и логика подтверждения транзакций могут выбирать уровень commitment. Это аналог выбора количества подтверждений блоков Ethereum в Solana, однако уровни здесь задаются явно:

processed: актуальное обработанное состояние узла. Используйте только для оптимистичного UI или сценариев, допускающих откат.
confirmed: блок, за который проголосовало сверхбольшинство стейка. Используйте как стандартный уровень для большинства подтверждений в продакшене и отображения статуса транзакций пользователям.
finalized: наивысший уровень подтверждения. Используйте перед необратимыми офчейн-действиями, такими как выплаты в фиате, отгрузка товаров или финальные расчётные записи.

Если метод RPC принимает параметр commitment и вы его не указываете, по умолчанию обычно используется finalized. Продакшен-клиенты должны явно указывать уровень commitment, чтобы задержка UI, поведение индексатора и политика расчётов были осознанными.

Расписание