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

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

Что такое неудавшаяся транзакция в Solana?

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

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

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

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

Отклонённые и неудавшиеся транзакции Solana

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

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

Основная причина большинства потерь — истечение blockhash. Каждая транзакция Solana ссылается на недавний blockhash, который остаётся действительным примерно 150 блоков, или около 60–90 секунд в реальном времени. Если не уложиться в это узкое окно, валидаторы отклоняют транзакцию сразу; такое правило существует для защиты от атак повторного воспроизведения.

Пример А (неудачный): Вы делаете обмен USDC на SOL на Meteora, но цена выходит за заданный вами допуск проскальзывания во время выполнения транзакции, и программа её откатывает. Попытка отображается ончейн с явной ошибкой проскальзывания и стоит вам только сетевой комиссии.

Пример B (транзакция отброшена): вы покупаете токен на Pump.fun в разгар ажиотажа вокруг запуска, но ваш RPC-узел отстаёт от вершины цепочки на несколько слотов, и blockhash истекает раньше, чем лидер увидит транзакцию. Ни в одном обозревателе ничего не появляется, комиссия не списывается.

Сколько транзакций Solana на самом деле завершаются неудачей?

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

Научное исследование, опубликованное в 2025 году, наконец ответило на этот вопрос точными цифрами, а не оценками. Рецензируемое исследование 1,5 млрд неудачных транзакций в 72 млн блоков показало, что аккаунты ботов терпят неудачу в 58,43 % случаев, тогда как аккаунты, управляемые людьми, — лишь в 6,22 %.

Эта человеческая цифра очень важна для понимания контекста. Она довольно близка к типичному диапазону Эфириума 1–3 % и заметно ниже показателей отказов 21 % и 15,4 %, зафиксированных в Base и Arbitrum. Это меняет представление о репутации Solana как ненадёжной сети: она во многом оказывается статистическим артефактом, вызванным ботами, а не проблемой пользовательского опыта.

Концентрация подтверждает тот же вывод. Десять программ с наибольшим числом сбоев составляют 77,95 % общего объёма, при этом на Raydium Liquidity Pool V4 в одиночку приходится 21,69 %, поскольку снайперские боты спешат торговать в новых пулах ещё до завершения инициализации.

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

Что показывают данные о причинах сбоев транзакций

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

Типы ошибок, лежащие в основе сбоев транзакций Solana, распределяются следующим образом:

• Цена или прибыль не достигнуты (47,99 %): допустимое проскальзывание было превышено, или арбитражный маршрут перестал быть прибыльным между отправкой и исполнением, что вызвало защитный откат, встроенный в DEX-агрегаторы.
• Недопустимый статус (19,19 %): транзакция была направлена на аккаунт или пул ликвидности в состоянии, не допускающем операцию, часто на неинициализированный пул или замороженный токен-аккаунт.
• Истечение срока действия (17,72 %): Указанный blockhash устарел до того, как валидатор его обработал. Это ончейн-признак перегрузки сети, отстающих RPC-узлов или медленной подписи на стороне клиента.
• Недопустимый входной аккаунт (3,27 %): необходимые адреса аккаунтов отсутствовали, были указаны в неверном порядке или не были авторизованы. Это частая проблема в сложных маршрутах, затрагивающих сразу много программ.
• Недопустимые входные параметры (2,55 %): Аргумент оказался вне диапазона, который принимает программа, например минимальная выходная сумма, равная нулю, в инструкции обмена на Raydium.
• Недостаточно средств (2,16 %): в кошельке не хватило SOL для покрытия перевода, комиссий и платы за аренду; эта ошибка непропорционально чаще затрагивает живых пользователей, а не ботов.
• Нехватка ресурсов (0,49 %): транзакция исчерпала лимит вычислений или превысила ограничения среды выполнения по памяти кучи, что типично для маршрутов с несколькими переходами, затрагивающих десятки аккаунтов.

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

Частые причины сбоев транзакций в Solana

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

Вот наиболее частые причины неудачных транзакций Solana:

• Слишком низкое проскальзывание: если задать допуск ниже того, что требует текущая волатильность, транзакции с токенами с низкой ликвидностью неизбежно будут отклоняться: цены могут измениться на несколько процентов между подписанием и исполнением.
• Низкие приоритетные комиссии: валидаторы упорядочивают транзакции по цене вычислительной единицы, поэтому транзакция с заниженной ставкой проигрывает конкуренцию и уходит глубоко в блоки в периоды высокого спроса.
• Истёкший blockhash: медленная подпись, отстающий RPC или просто промедление с подтверждением могут исчерпать окно действия ещё до того, как транзакция дойдёт до лидера.
• Превышение вычислительного лимита: маршруты с несколькими переходами через пулы нескольких децентрализованных бирж могут превысить стандартный лимит в 200 000 вычислительных единиц на инструкцию и быть прерваны.
• Перегруженный RPC: публичные конечные точки используются огромным числом пользователей и сильно деградируют во время запусков, теряя транзакции ещё до их отправки валидаторам.
• Недостаточный баланс: комиссии, рента за новые токен-аккаунты и приоритетные ставки оплачиваются в SOL, поэтому кошельки, в которых есть только обмениваемый токен, сразу получают ошибку.
• Низкая ликвидность: крупные ордера против неглубоких пулов не могут исполниться по приемлемой цене, что приводит к тем же откатам из-за недостаточной ликвидности, знакомым по другим сетям.
• Замороженные аккаунты: злонамеренные разработчики токенов могут заморозить переводы после привлечения покупателей — схема «медовой ловушки», которая проявляется ошибкой недействительного статуса при попытке продать.

Как исправить сбои транзакций в Solana

Когда вы определили, в чём проблема — в логике исполнения или в доставке по сети, решением обычно становится конкретная настройка, а не общий совет попробовать ещё раз.

Эти изменения устраняют большинство сбоев транзакций Solana:

• Разумно повышайте проскальзывание: для волатильных токенов увеличьте допуск до 1–3 %, соглашаясь на немного худшую цену ради исполнения сделки, а не ещё одной напрасно потраченной комиссии.
• Динамически повышайте приоритетные комиссии: в обычных условиях сделки проходят при 1 000–5 000 микро-ламспортов за вычислительную единицу, а при запусках и ликвидациях может потребоваться 100 000 или больше.
• Точно задавайте вычислительные единицы: сначала выполните симуляцию, затем установите лимит близко к фактическому потреблению: цена покупает приоритет, а завышенный лимит лишь впустую расходует запас.
• Смените RPC-провайдера: выделенные эндпоинты Helius, Triton или QuickNode надёжно передают транзакции при перегрузке, когда стандартные публичные узлы уже насыщены и отбрасывают запросы.
• Обновите перед повторной попыткой: получайте новый blockhash для каждой попытки, а не отправляйте повторно исходный, срок действия которого, вероятно, истёк и который снова незаметно завершится неудачей.
• Держите запас SOL: Solflare советует оставлять не менее 0,05 SOL нетронутыми, чтобы с запасом покрывать базовые комиссии, приоритетные ставки и депозиты за аренду.
• Предпросмотр перед подписанием: симуляция в кошельке бесплатно выявляет транзакции, обречённые на неудачу, тогда как неудача в ончейне всё равно стоит базовой комиссии и любой приоритетной ставки.

Сколько стоит неудавшаяся транзакция в Solana?

Финансовый ущерб от неудавшейся транзакции минимален, и это одно из реальных структурных преимуществ Solana перед сетями с более высокими комиссиями. Каждая транзакция несёт базовую комиссию в 0,000005 SOL за подпись, и она взимается независимо от того, завершится ли выполнение успешно или будет отменено на полпути.

Дополнительные расходы возникают в отдельных случаях, а не всегда. Открытие нового токен-аккаунта требует разового пополнения для аренды примерно в 0,002 SOL, а любая приоритетная комиссия рассчитывается как цена вычислительной единицы, умноженная на лимит вычислительных единиц, и затем делится на миллион.

С февраля 2025 года 100 % приоритетных комиссий поступает напрямую валидаторам, а не сжигается наполовину, после активации изменения управления SIMD-0096. Сама базовая комиссия по-прежнему делится поровну между сжиганием и производителем блока, включившим вашу транзакцию.

Пример: вы открываете позицию SOL с кредитным плечом на площадке бессрочных контрактов, цена выходит за пределы вашего допуска, пока транзакция в пути, и она откатывается. Ваше обеспечение остаётся нетронутым, а вы теряете долю цента. Подробнее см. в нашем руководстве по комиссиям за газ в Solana.

Как Firedancer и Alpenglow меняют картину

Сама сеть меняется так, что это напрямую затрагивает перегрузку, из-за которой пропадают транзакции, поэтому торговля в 2026 году заметно отличается от хаоса вокруг мемкоинов в начале 2024 года, который и сформировал репутацию Solana как ненадёжной сети.

1. Firedancer

Firedancer — независимый клиент валидатора, написанный с нуля на C и C++ компанией Jump Crypto, — вышел в основную сеть в декабре 2025 года после обширного тестирования. К середине 2026 года примерно 14 % стейка сети работало на полноценном Firedancer, ещё 26 % — на гибридном варианте Frankendancer.

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

2. Alpenglow

Alpenglow — значительно более масштабное изменение, которое ещё предстоит внедрить. Он был одобрен валидаторами в сентябре 2025 года при поддержке 98,27 %, полностью заменяет Tower BFT и Proof of History и нацелен на финальность транзакций около 150 миллисекунд против примерно 12,8 секунды в нынешней архитектуре.

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

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

Лучшие практики, помогающие избежать сбоев транзакций в Solana

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

1. Поддерживайте настройку в актуальном состоянии

Устаревшее программное обеспечение и общая публичная инфраструктура вызывают сбои, никак не связанные с выбранными вами параметрами сделки. Сначала устраните эту основу проблем:

• Регулярно обновляйте кошельки: Phantom, Solflare и Backpack часто выпускают улучшения оценки комиссий, а устаревшие версии не получают исправлений совместимости для изменений среды выполнения и валидаторов.
• Используйте приватную конечную точку: выделенный RPC-доступ стоит недорого и устраняет главный источник потерянных транзакций во время запусков и других событий с высокой нагрузкой.
• Сброс зависших сессий: перезапуск расширения или браузера очищает кэшированные состояния соединения, которые незаметно вызывают повторные сбои, даже когда сеть уже восстановилась.

2. Настройте перед подтверждением

Большинство откатов определяется настройками, которые вы выбираете перед подписанием, а не тем, что в этот момент происходит в самой сети:

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

3. Выбирайте время для транзакций

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

• Избегайте периодов запуска: запуски мемкоинов, получение аирдропов и каскады ликвидаций порождают бот-спам, который сильнее всего вытесняет обычных пользователей.
• Разбивайте крупные операции: разделение многошаговых действий в DeFi на отдельные транзакции позволяет уложиться в лимиты вычислений и локализует любой сбой в одном компоненте.

Выводы

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

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

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