Skip to main content
Существует два основных способа отправки транзакций в Solana:
  1. Использование стейкинговых подключений (по умолчанию)
  2. Использование специализированных сервисов доставки транзакций, таких как Sender (рекомендуется)
В этой статье описаны рекомендации по оптимизации транзакций при использовании стейкинговых подключений — метода по умолчанию для всех платных тарифов Helius. Стейкинговые подключения лучше всего подходят для сценариев, в которых задержка не критична для вашего бизнеса (например, платежи, кошельки, социальные приложения и т. д.). Если вы опытный трейдер (например, используете propAMM, снайпер-бота, копитрейдинг, ликвидационного бота или арбитраж) и вам нужен специализированный сервис доставки транзакций со сверхнизкой задержкой, ознакомьтесь с нашим руководством по Sender.

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

Стейкинговые подключения Helius гарантируют доставку 100% транзакций с минимальным временем подтверждения. Чтобы повысить долю успешно доставленных транзакций при использовании стейкинговых подключений, следуйте этим рекомендациям:
  • Используйте уровень подтверждения “confirmed” для получения последнего хеша блока
  • Добавляйте комиссии за приоритет и рассчитывайте их динамически
  • Оптимизируйте использование вычислительных единиц (CU)
  • Установите maxRetries равным 0 и реализуйте надежную логику повторных попыток
  • Отправляйте транзакции, задав для skipPreflight значение true (необязательно)
Хотите узнать больше? Все основные сведения приведены в этой публикации в блоге.

Рекомендуемые оптимизации для трейдеров

Для чувствительных к задержке торговых сценариев рекомендуем использовать Sender. Однако если вы используете стейкинговые подключения и хотите добиться минимально возможной задержки, рекомендуем применить следующие оптимизации в дополнение к описанным выше рекомендациям:
  • Ваш клиентский сервер (компьютер, с которого вы отправляете транзакции) должен находиться на востоке США или в Западной Европе.
  • Выберите FRA или PIT, если хотите разместить сервер рядом с серверами Helius, отправляющими транзакции.
  • Не отправляйте транзакции из регионов, удаленных от сети валидаторов (например, из Латинской Америки или Южной Африки).
  • Прогревайте региональные кеши Helius, чтобы минимизировать задержку в хвосте распределения.
  • Для каждого региона достаточно одного потока прогрева — дополнительные потоки не дадут никакого преимущества.
  • Каждую секунду отправляйте RPC-вызов getHealth, используя ту же конечную точку и ключ API, что и для отправки транзакций.
Эти преимущества будут заметны только опытным трейдерам. Разработчикам обычных приложений рекомендуем следовать указаниям из раздела «Отправка умных транзакций» ниже.
Получайте ончейн-данные транзакций максимально быстро с помощью Raw Shreds (UDP). Оформите подписку в панели управления Helius.

Отправка умных транзакций

SDK Helius для TypeScript и Rust поддерживают отправку умных транзакций. Этот новый метод создает и отправляет оптимизированную транзакцию, а также отслеживает состояние ее подтверждения. Пользователи могут настраивать параметры отправки транзакции, например указывать, нужно ли пропускать предварительные проверки. В простейшем случае пользователям достаточно предоставить свою пару ключей и инструкции, которые необходимо выполнить, — остальное мы сделаем сами. Мы выполняем следующие действия:
  • Получаем последний хеш блока
  • Создаем исходную транзакцию
  • Моделируем исходную транзакцию, чтобы определить количество потребленных вычислительных единиц (CU)
  • Задаем лимит CU на основе количества CU, потребленных на предыдущем шаге, с небольшим запасом
  • Получаем рекомендуемую Helius комиссию за приоритет через наш Priority Fee API
  • Устанавливаем комиссию за приоритет (в микролампортах на CU) равной рекомендуемой Helius комиссии
  • Добавляем небольшой запас на случай, если рекомендуемая комиссия изменится в ближайшие несколько секунд
  • Создаем и отправляем оптимизированную транзакцию
  • В случае успеха возвращаем подпись транзакции
Требование использовать рекомендуемое или более высокое значение для наших стейкинговых подключений гарантирует, что Helius отправляет качественные транзакции и валидаторы не применяют к нам ограничение частоты запросов.
Этот метод — самый простой способ создать, отправить и доставить транзакцию в Solana. Если использовать рекомендуемую Helius комиссию, транзакции пользователей Helius на одном из наших стандартных платных тарифов будут направляться через стейкинговые подключения. Это гарантирует почти 100%-ную доставку транзакций и минимальную задержку.

SDK для TypeScript

Метод sendSmartTransaction доступен в нашем SDK Helius для TypeScript в версиях >= 1.3.2. Чтобы обновить SDK до более новой версии, выполните npm update helius-sdk. В этом примере SOL переводятся на выбранный вами счет. Для отправки оптимизированной транзакции без пропуска предварительных проверок используется sendSmartTransaction:

SDK для Rust

Метод send_smart_transaction доступен в нашем SDK для Rust в версиях >= 0.1.5. Чтобы обновить SDK до более новой версии, выполните cargo update helius. В следующем примере 0,01 SOL переводится на выбранный вами счет. Для отправки оптимизированной транзакции с пропуском предварительных проверок и двумя повторными попытками при необходимости используется send_smart_transaction:

Отправка транзакций без SDK

Рекомендуем отправлять умные транзакции с помощью одного из наших SDK, но те же возможности доступны и без SDK. SDK для TypeScript и Rust имеют открытый исходный код, поэтому вы в любое время можете просмотреть код, реализующий отправку умных транзакций.

Подготовка и создание исходной транзакции

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

Оптимизация использования вычислительных единиц (CU) транзакцией

Чтобы оптимизировать использование вычислительных единиц (CU) транзакцией, можно смоделировать транзакцию с помощью RPC-метода simulateTransaction. Моделирование транзакции вернет количество использованных CU. Это значение можно использовать для соответствующей настройки лимита вычислительных единиц. Рекомендуется сначала использовать тестовую транзакцию с нужными инструкциями, а также добавить инструкцию, устанавливающую лимит вычислений равным 1,4 млн CU. Это необходимо для успешного моделирования транзакции. Например:
Также рекомендуется добавить небольшой запас, чтобы транзакция выполнилась без проблем. Для этого задайте следующее:
Затем создайте инструкцию, устанавливающую это значение в качестве лимита вычислительных единиц, и добавьте ее в массив инструкций:

Сериализация и кодирование транзакции

Этот процесс относительно прост. Сначала сериализуйте транзакцию. Типы Transaction и VersionedTransaction имеют для этого метод .serialize(). Затем закодируйте транзакцию с помощью пакета bs58. Ваш код должен выглядеть примерно так: bs58.encode(txt.serialize());

Установка правильной комиссии за приоритет

Сначала получите оценку комиссии за приоритет с помощью Priority Fee API. Передайте транзакцию и получите рекомендуемую Helius комиссию через параметр recommended:
Затем создайте инструкцию, устанавливающую это значение в качестве цены вычислительной единицы, и добавьте ее к предыдущим инструкциям:

Создание и отправка оптимизированной транзакции

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

Опрос состояния транзакции и повторная отправка

Хотя стейкинговые подключения пересылают транзакцию непосредственно лидеру, она все равно может быть отброшена на этапе банковской обработки. Рекомендуем реализовать собственную логику повторной отправки, а не полагаться на RPC при повторных попытках отправки транзакции.
У RPC-метода sendTransaction есть параметр maxRetries. Его можно задать, чтобы переопределить стандартную логику повторных попыток RPC и предоставить разработчикам больше контроля над этим процессом. Распространенный подход — получить текущий хеш блока через getLatestBlockhash, сохранить lastValidBlockHeight и повторять отправку транзакции до истечения срока действия хеша блока. Крайне важно повторно подписывать транзакцию только после того, как хеш блока перестанет быть действительным. В противном случае сеть может принять обе транзакции. После отправки транзакции важно опрашивать состояние ее подтверждения, чтобы перед повторной попыткой узнать, обработала и подтвердила ли ее сеть. Используйте RPC-метод getSignatureStatuses, чтобы проверить состояние подтверждения списка транзакций. В SDK @solana/web3.js класс Connection также содержит метод getSignatureStatuses для получения текущего состояния нескольких подписей.

Как sendSmartTransaction выполняет опрос и повторную отправку

Тайм-аут метода sendSmartTransaction составляет 60 секунд. Поскольку хеш блока действителен в течение 150 слотов, а идеальная продолжительность слота составляет 400 мс, можно обоснованно предположить, что хеш блока транзакции станет недействительным через одну минуту. Метод отправляет транзакцию и опрашивает состояние ее подписи в течение этого периода ожидания:
Для txtSig устанавливается подпись только что отправленной транзакции. Затем метод использует pollTransactionConfirmation() для опроса состояния подтверждения транзакции. Этот метод проверяет состояние транзакции каждые пять секунд, но не более трех раз. Если за это время транзакция не будет подтверждена, возвращается ошибка: