TL;DR
- Подтверждена означает, что транзакцию содержит корректный блок, который сейчас признается частью канонической цепочки. В Bitcoin содержащий ее блок считается подтверждением номер один. Каждый следующий блок добавляет еще одно подтверждение. В Ethereum включение может дополнительно дозревать через состояния latest, safe и finalized.
- Кошелек формирует и подписывает сообщение по правилам конкретной сети, затем передает его узлу или частному сервису. Получатель проверяет соответствие консенсусу и локальной политике, прежде чем сохранить или ретранслировать транзакцию. Подпись не гарантирует ни принятия, ни распространения, ни включения в блок.
- Мемпулом называют локальный набор корректных неподтвержденных транзакций конкретного узла. Узлы передают многие из этих транзакций пирам, поэтому их мемпулы пересекаются, но идентичность никогда не гарантирована. Частные транзакции могут вообще миновать публичное распространение.
- Комиссии в Bitcoin оплачивают дефицитный вес блока. Кошельки обычно указывают ставку комиссии в сатоши за виртуальный байт, но майнеры могут оценивать связанные транзакции вместе. Небольшая дочерняя транзакция с высокой комиссией способна сделать родительскую транзакцию с низкой комиссией экономически привлекательной, а на включение в блок могут влиять и внесетевые договоренности.
В одном блоке
Рисунок 1. Транзакция проходит несколько разных состояний. «Увидена кошельком», «в мемпуле», «включена в блок», «safe» и «расчет завершен» не являются взаимозаменяемыми понятиями.
Что на самом деле означает «подтверждена»?
Быстрый ответ
Подтверждена означает, что транзакцию содержит корректный блок, который сейчас признается частью канонической цепочки. В Bitcoin содержащий ее блок считается подтверждением номер один. Каждый следующий блок добавляет еще одно подтверждение. В Ethereum включение может дополнительно дозревать через состояния latest, safe и finalized.
Слово «подтверждена» часто звучит как переключатель: сначала ничего, потом полная определенность. В блокчейнах все тоньше. Кошелек может знать, что транзакция подписана, узел может принять ее в локальный мемпул, производитель блока может включить ее в блок, а получатель все еще может ждать дополнительных гарантий, прежде чем считать платеж завершенным. Это отдельные события.
| Состояние | Что это означает | Что еще может произойти |
|---|---|---|
| Создана или подписана | Кошелек сформировал транзакцию и авторизовал ее. | Она может так и не попасть в сеть, либо отправитель может разослать конфликтующую версию. |
| Разослана в сеть | Транзакция отправлена как минимум одному пиру или на частный эндпоинт. | Другие узлы могут ее не увидеть или отклонить по собственной политике. |
| В мемпуле | Конкретный узел хранит ее как корректного неподтвержденного кандидата на включение в блок. | Она может ждать, быть вытесненной, быть замененной или не распространиться широко. |
| Включена в блок / 1 подтверждение | Канонический блок сейчас содержит ее. | Неглубокая реорганизация цепочки может убрать этот блок. |
| Больше подтверждений | Поверх нее строятся дополнительные канонические блоки. | Откат, как правило, становится все более дорогим или менее вероятным. |
| Safe / finalized в Ethereum | Консенсусные клиенты показывают более сильные состояния правила выбора форка и контрольных точек. | Откат финализированного состояния требует тяжелого сбоя консенсуса и социального восстановления, а не обычной работы сети. |
| Расчет завершен для получателя | Собственная риск-политика получателя выполнена. | Это бизнес-решение, а не универсальный флаг протокола. |
Транзакция может исполниться и неудачно. В Ethereum включенная транзакция, вызов контракта в которой откатился, все равно подтверждена как транзакция: она израсходовала газ, изменила nonce отправителя и создала квитанцию со статусом неудачи, хотя задуманные изменения состояния были отменены. Поэтому «подтверждена» не означает автоматически, что «действие в приложении выполнено».
Вывод: задавайте два вопроса, а не один: включена ли транзакция в каноническую цепочку и достигнут ли уровень надежности, необходимый именно для этого платежа?
Что происходит с транзакцией до попадания в мемпул?
Быстрый ответ
Кошелек формирует и подписывает сообщение по правилам конкретной сети, затем передает его узлу или частному сервису. Получатель проверяет соответствие консенсусу и локальной политике, прежде чем сохранить или ретранслировать транзакцию. Подпись не гарантирует ни принятия, ни распространения, ни включения в блок.
Формирование и подпись
Транзакция Bitcoin указывает, какие непотраченные выходы расходуются, создает новые выходы, задает суммы и скрипты и содержит подписи или другие данные свидетеля, удовлетворяющие условиям расходования. Транзакция Ethereum указывает аккаунт, которым управляет отправитель, nonce, получателя, сумму, необязательные данные, лимит газа и потолки комиссии, а затем несет подпись, авторизующую именно эту полезную нагрузку.
Отправка не является глобальной рассылкой
Большинство кошельков передают подписанную транзакцию одному из своих узлов, инфраструктурному провайдеру или подключенному пиру. Первый получатель затем может ретранслировать ее по одноранговой сети. Некоторые транзакции вместо этого идут на частный релей, билдеру блоков, майнинговому сервису или на эндпоинт конкретного приложения. Надпись «отправлено» в кошельке часто означает лишь то, что один эндпоинт принял запрос.
Правила валидности и политика ретрансляции
Правила консенсуса определяют, может ли транзакция законно попасть в блок: корректная авторизация, отсутствие запрещенного перерасхода, правильный переход состояния и другие правила сети. Политика узла определяет, стоит ли хранить и ретранслировать неподтвержденную транзакцию до того, как ее включат в блок. Политика может быть строже консенсуса и различаться в зависимости от версии программы или настроек оператора. Транзакция, отклоненная одним мемпулом, все равно может быть корректной в блоке или принята другим узлом.
| Проверка | Пример Bitcoin | Пример Ethereum |
|---|---|---|
| Авторизация | Условия скрипта или свидетеля выполняются для каждого расходуемого выхода. | Подпись идентифицирует отправителя, а поля транзакции корректны. |
| Возможность расходования | Указанные выходы существуют, не потрачены, и суммы сходятся после вычета комиссии. | Nonce отправителя подходит, а на аккаунте хватает средств на сумму перевода плюс максимально возможные издержки. |
| Соответствие консенсусу | Транзакция соблюдает правила скриптов, locktime, веса и денежной эмиссии. | Тип транзакции, базовая стоимость газа и правила уровня исполнения корректны. |
| Локальная политика | Стандартность, минимальная ставка комиссии для ретрансляции, правила кластеров и замены. | Ограничения пула транзакций клиента, шаг повышения цены, слоты на аккаунт и другие настройки оператора. |
| Экономика включения в блок | При построении шаблона учитываются ожидаемый вклад в комиссии и зависимости. | Соответствие базовой комиссии, приоритетная комиссия, стратегия билдера, частный поток ордеров и MEV. |
Вывод: фраза «сеть отклонила транзакцию» обычно слишком расплывчата. Выясните, какой узел ее отклонил, была ли причина в соответствии консенсусу или в локальной политике и существует ли другая версия или другой маршрут.
Что такое мемпул и почему он не один?
Быстрый ответ
Мемпулом называют локальный набор корректных неподтвержденных транзакций конкретного узла. Узлы передают многие из этих транзакций пирам, поэтому их мемпулы пересекаются, но идентичность никогда не гарантирована. Частные транзакции могут вообще миновать публичное распространение.
Термин происходит от memory pool, то есть «пул в памяти». Это не принадлежащий протоколу зал ожидания, расположенный в одном месте. Каждый участвующий узел сам решает, что принимать, хранить, вытеснять, ретранслировать и заменять, в рамках ограничений реализации и настроек оператора. Узлы подключаются в разное время, имеют разных пиров, используют разные программы и могут выделять разный объем памяти. Поэтому их наборы ожидающих транзакций постоянно расходятся.
Мемпулы Bitcoin
Узлы Bitcoin хранят неподтвержденные транзакции и отслеживают граф их зависимостей, поскольку дочерняя транзакция может тратить неподтвержденный родительский выход. В Bitcoin Core 31 появилась схема кластерного мемпула, которая оценивает связанные транзакции группами и упорядочивает «чанки» по ставке комиссии, с которой их предположительно включат в блок. Это точнее старой упрощенной модели, где каждая транзакция стоит сама по себе в единой очереди, отсортированной по комиссии.
Пулы транзакций Ethereum
Клиенты уровня исполнения Ethereum обычно отделяют исполнимые, или ожидающие, транзакции от транзакций в очереди, то есть с пропуском в нумерации. Транзакция со следующим пригодным nonce может быть исполнимой; транзакция с более поздним nonce может ждать, потому что отсутствуют один или несколько предыдущих. Geth документирует раздельные пулы pending и queued, а также замену транзакции с тем же отправителем и тем же nonce версией с достаточно более высокой ценой.
Публичный мемпул и частный поток ордеров
Отправитель может направить транзакцию напрямую билдеру или специализированному сервису вместо рассылки по публичной сети. Это может снизить публичную уязвимость к фронтраннингу или улучшить обработку бандлов, но добавляет допущения о доступности эндпоинта, цензуре и доверии. В документации самого Ethereum прямо отмечается, что продвинутые пользователи могут отправлять транзакции специализированным билдерам, а не в публичный мемпул.
Вывод: говорите «мемпул такого-то узла» или «публичное распространение транзакций», а не «мемпул» так, будто это глобально согласованная база данных.
Как работают комиссии и отбор транзакций в Bitcoin?
Быстрый ответ
Комиссии в Bitcoin оплачивают дефицитный вес блока. Кошельки обычно указывают ставку комиссии в сатоши за виртуальный байт, но майнеры могут оценивать связанные транзакции вместе. Небольшая дочерняя транзакция с высокой комиссией способна сделать родительскую транзакцию с низкой комиссией экономически привлекательной, а на включение в блок могут влиять и внесетевые договоренности.
Абсолютная комиссия и ставка комиссии
Абсолютная комиссия равна разнице между суммарной стоимостью потраченных входов и суммарной стоимостью новых выходов. Ставка комиссии делит эту сумму на виртуальный размер и обычно выражается в sat/vB. Комиссия в 1000 сатоши может быть конкурентной для небольшой транзакции и недостаточной для гораздо более крупной. Виртуальные байты учитывают весовую скидку SegWit и не равны обычному размеру файла.
Почему зависимости меняют аукцион
Дочерняя транзакция не может подтвердиться раньше своего неподтвержденного родителя, потому что расходуемого ею выхода еще нет в блокчейне. Поэтому рациональное построение блока учитывает суммарный доход и суммарный размер транзакций, которые должны попасть в блок вместе. Логика кластерного мемпула в Bitcoin Core 31 явно упорядочивает связанные транзакции по ожидаемым чанкам для включения в блок, а не по наивному списку с одной строкой на транзакцию.
Что оптимизируют майнеры и пулы
Пул обычно строит корректный шаблон блока, рассчитанный на максимальный доход в рамках ограничений по весу, зависимостям, политике и эксплуатации. Ставка комиссии здесь главный, но не единственный фактор. Операторы могут локально повышать приоритет транзакций, принимать транзакции по частным каналам, включать собственные транзакции, выполнять коммерческие договоренности или не включать транзакции по соображениям собственной политики. Узлы примут любой блок, содержимое которого соответствует консенсусу, независимо от того, совпадает ли оно с мемпулом другого узла.
| Понятие в Bitcoin | Значение | Частая ошибка |
|---|---|---|
| Комиссия | Сколько сатоши будет уплачено, если транзакция подтвердится. | Сравнение абсолютных комиссий без учета размера транзакции. |
| Ставка комиссии | Комиссия, деленная на виртуальный размер, обычно в sat/vB. | Уверенность, что заявленный целевой срок гарантирует попадание в конкретный блок. |
| Пакет / кластер | Связанные неподтвержденные транзакции, которые может потребоваться оценивать вместе. | Уверенность, что высокая ставка комиссии дочерней транзакции не поможет родительской с низкой комиссией. |
| Минимум мемпула | Динамический порог приема у локального узла с учетом его памяти и политики. | Восприятие отказа одного узла как правила консенсуса. |
| Минимум для блока / выбор оператора | Майнер или пул может задать собственную экономическую политику включения. | Уверенность, что все пулы строят одинаковые шаблоны. |
Вывод: Bitcoin работает как аукцион за вес блока, но экономической единицей может быть связанная группа транзакций, а не одна отдельная транзакция.
Как устроены комиссии за газ и порядок nonce в Ethereum?
Быстрый ответ
Ethereum берет плату за исполнение в газе. Транзакция задает лимит газа, максимальную комиссию за единицу газа и максимальную приоритетную комиссию. Протокольная базовая комиссия сжигается; фактическая приоритетная комиссия достается пропозеру или указанному им получателю комиссий. Транзакции одного аккаунта исполняются в порядке nonce.
Израсходованный газ и лимит газа
Газ измеряет ресурсы исполнения, необходимые транзакции Ethereum. Лимит газа задает максимум газа, который отправитель разрешает потратить на эту транзакцию. Отправитель платит только за фактически израсходованный газ в пределах лимита. У простого перевода ETH предсказуемая базовая стоимость; взаимодействие с контрактами может потреблять намного больше газа и зависеть от состояния.
Базовая комиссия, приоритетная комиссия и максимальная комиссия
EIP-1559 задает каждому блоку протокольную базовую комиссию, которая растет, когда предыдущие блоки превышают целевой расход газа, и падает, когда они его не добирают, с максимальным изменением 12,5 процента за блок. Эта базовая комиссия сжигается. Отправитель также задает максимальную приоритетную комиссию и максимальную общую комиссию за единицу газа. Фактическая плата за единицу газа ограничена базовой комиссией, допустимой приоритетной надбавкой и максимальной комиссией отправителя; неиспользованный запас не оплачивается.
Порядок nonce
У внешнего аккаунта (EOA) nonce увеличивается с каждой исполненной транзакцией. Транзакция с более поздним nonce не может исполниться, пока не израсходованы все предыдущие. Именно поэтому одна недооцененная или пропавшая транзакция способна заблокировать очередь из более дорогих последующих транзакций того же аккаунта. Разные клиенты и кошельковые сервисы называют такие состояния pending, queued или транзакциями с пропуском в нумерации.
Откат исполнения все равно стоит газа
Если транзакция Ethereum включена в блок, а исполнение контракта откатывается, протокол отменяет задуманные изменения состояния, но сохраняет увеличение nonce и берет плату за уже выполненные вычисления. Статус в квитанции показывает неудачу. Напротив, транзакция, отклоненная до включения в блок из-за собственной некорректности, газ в сети не расходует.
Комиссии за блобы существуют отдельно
Транзакции с блобами EIP-4844, которые используют в основном роллапы, участвуют в отдельном рынке комиссий за блобы в дополнение к обычному газу за исполнение. Обычный перевод ETH комиссию за блоб не платит. Это различие важно при разборе издержек роллапов, но в стандартный расчет перевода из кошелька оно не входит.
| Поле Ethereum | Назначение | Что это значит для пользователя |
|---|---|---|
| nonce | Упорядочивает транзакции одного отправителя и предотвращает повтор внутри последовательности аккаунта. | Пропущенный или зависший ранний nonce может блокировать последующие транзакции. |
| gasLimit | Ограничивает объем газа, который транзакция может израсходовать. | Слишком низкое значение может привести к неудаче; неиспользованный газ не оплачивается. |
| baseFeePerGas | Протокольный нижний порог цены для блока; сжигается. | Транзакция не может быть включена, если ее максимальная комиссия ниже требуемой базовой. |
| maxPriorityFeePerGas | Ограничивает приоритетную надбавку, стимулирующую включение в блок. | Более высокое значение может улучшить приоритет, но порядок транзакций может отражать также MEV и частный поток ордеров. |
| maxFeePerGas | Ограничивает сумму базовой и фактической приоритетной комиссии. | Защищает от оплаты выше подписанного потолка за единицу газа. |
| статус квитанции | Сообщает, прошло ли исполнение включенной транзакции успешно или откатилось. | Подтвержденная транзакция может иметь неудачное исполнение на уровне приложения. |
Вывод: в Ethereum отделяйте включение транзакции в блок от успеха ее исполнения, а потолок по газу от фактически списанной суммы.
Кто на самом деле строит и предлагает блоки?
Быстрый ответ
В Bitcoin шаблоны блоков-кандидатов обычно строят майнинг-пулы, а майнеры выполняют по ним proof of work. Ethereum назначает на каждый слот валидатора-пропозера, но многие пропозеры отдают построение полезной нагрузки исполнения специализированным билдерам через внепротокольные системы разделения ролей пропозера и билдера. Каждый полный узел при этом проверяет корректность самостоятельно.
Bitcoin: пулы, построение шаблона и proof of work
Майнинг-пул объединяет вычислительную мощность участников и обычно выдает им работу на основе своего шаблона блока. Пул или его инфраструктура выбирают транзакции и формируют coinbase-транзакцию; майнеры ищут корректный заголовок с proof of work. Майнер или пул, нашедший корректный блок, рассылает его по сети. Независимые узлы Bitcoin проверяют блок целиком и отклоняют его при нарушении любого правила консенсуса.
Ethereum: пропозер и билдер могут быть разными участниками
У каждого 12-секундного слота есть выбранный валидатор-пропозер. Пропозер может собрать полезную нагрузку исполнения локально из известных ему транзакций либо воспользоваться рынком билдеров. Внепротокольное разделение ролей пропозера и билдера, которое обычно реализуют через Builder API и экосистему MEV-Boost, позволяет специализированным билдерам бороться за право поставить полезную нагрузку исполнения. Пропозер подписывает выбранный блок; другие узлы заново исполняют и проверяют его. В дорожной карте Ethereum обсуждается закрепление этого разделения в протоколе, но предложения из дорожной карты не следует описывать как уже действующие, пока они не внедрены.
Почему MEV влияет на порядок транзакций
Максимальная извлекаемая ценность означает дополнительную прибыль от выбора, вставки или упорядочивания транзакций. Примеры: арбитраж и ликвидации. Билдер может предпочесть бандл с высокой суммарной ценностью, а не транзакцию с чуть более высокой публичной надбавкой. Поэтому утверждение «самая высокая надбавка всегда идет первой» неточно описывает порядок транзакций в блоках Ethereum.
Компромиссы частного потока ордеров
Частная отправка может снизить публичную уязвимость к фронтраннингу и поддержать бандлы по принципу «все или ничего». Она же может концентрировать видимость и возможность цензуры у билдеров, релеев и операторов эндпоинтов. Пользователям стоит отличать приватность от отсутствия доверия: транзакция, скрытая от публичного мемпула, все равно видна принявшему ее частному сервису.
Вывод: тот, кто предлагает блок, может не быть тем, кто выбрал порядок транзакций в нем, особенно в Ethereum. Включение в блок связано не только с комиссией, но и со структурой рынка.
Почему транзакции зависают, исчезают или показывают противоречивые статусы?
Быстрый ответ
Обычные причины: низкий экономический приоритет, пропуски в nonce или зависимостях, различия локальных политик, нехватка средств, конфликтующая замена, сбой эндпоинта, вытеснение из мемпула или реорганизация цепочки. Сначала определите состояние транзакции, потом выбирайте средство.
| Симптом | Вероятное объяснение | Что проверить в первую очередь |
|---|---|---|
| Кошелек показывает отправку, обозреватель ее не находит | Кошелек отправил транзакцию на один эндпоинт, рассылка не удалась или транзакция пошла по частному маршруту. | Хеш транзакции, сеть, логи кошелька, а также второй независимый узел или обозреватель. |
| Видна, но долго остается в ожидании | Комиссия или надбавка неконкурентны, у родительской транзакции низкая комиссия либо в Ethereum пропущен более ранний nonce. | Текущие условия по комиссиям, зависимости, последовательность nonce и поддержку замены. |
| Видна в одном обозревателе и не видна в другом | Разные мемпулы узлов, разная видимость у пиров или задержка провайдера данных. | Сверьте хеш транзакции и сеть; подождите немного, прежде чем считать транзакцию неудачной. |
| Ожидающая транзакция исчезла | Локальное вытеснение, замена, перезапуск узла или смена его политики, изменение индексации у провайдера. | Остаются ли входы или nonce неизрасходованными и существует ли конфликтующая транзакция. |
| Подтверждена, затем снова в ожидании | Содержавший ее блок выпал при реорганизации. | Хеш блока, каноническую цепочку, конфликтующее расходование и новый статус включения. |
| Квитанция Ethereum показывает статус 0 | Транзакция подтверждена, но исполнение в EVM откатилось. | Израсходованный газ, причину отката, состояние контракта и логи приложения. |
| Транзакция Bitcoin не заменяется в кошельке | Кошелек не поддерживает повышение комиссии, не контролирует нужные входы или выходы либо граф транзакций или политика не позволяют выбранный способ. | Документацию кошелька и возможность применить CPFP. |
Отброшена не значит забыта везде
Узлы вытесняют транзакции из-за нехватки памяти, возраста или политики. Другой узел может сохранить и позже разослать ту же транзакцию заново. Отправителю не стоит считать средства безопасно доступными только потому, что один обозреватель перестал показывать транзакцию; проверьте каноническое состояние UTXO или nonce аккаунта и используйте обработку конфликтов в кошельке.
Низкая комиссия не единственная причина
Транзакция может платить высокую номинальную комиссию и все равно ждать: она зависит от родительской транзакции с низкой комиссией, стоит за пропуском в nonce, не проходит локальное правило ретрансляции, отправлена на частный эндпоинт, который ее придерживает, или проигрывает по предпочтениям билдера более ценному бандлу. Точная диагностика избавляет от ненужных или опасных попыток замены.
Вывод: начинайте с наблюдаемого состояния цепочки и узлов. Не рассылайте раз за разом случайные варианты, пока не поймете, с чем имеете дело: с приоритетом по комиссии, с порядком транзакций, с политикой, с заменой или с реорганизацией.
Как ускорить или заменить ожидающую транзакцию Bitcoin?
Быстрый ответ
Есть два стандартных инструмента: replace-by-fee, когда конфликтующая транзакция платит больше, и child-pays-for-parent, когда расходование неподтвержденного выхода повышает экономическую ценность включения всей связанной группы. Доступность зависит от поддержки в кошельке, структуры транзакции и текущей политики узлов.
Замена с повышением комиссии (replace-by-fee, RBF)
RBF создает новую транзакцию, которая тратит хотя бы один из входов ожидающей транзакции и платит достаточно дополнительной комиссии, чтобы удовлетворить политику замены. В Bitcoin Core 28 полный RBF стал поведением по умолчанию, а в Bitcoin Core 31 оценка замен переработана вокруг диаграмм ставки комиссии кластера. Для простой замены одиночной транзакции по текущей политике Core новая версия должна платить и большую абсолютную комиссию, и большую ставку комиссии, а также покрывать дополнительную комиссию за ретрансляцию. В других реализациях и сервисах правила могут отличаться.
По возможности используйте встроенный в кошелек сценарий «повысить комиссию» или «ускорить». Ручная замена может случайно изменить получателей, изменить выходы, нарушить допущения приложения или создать транзакцию, которая распространяется не так, как ожидалось. Замена не окончательна, пока не подтвердится одна из версий.
Ребенок платит за родителя (child-pays-for-parent, CPFP)
Если отправитель или получатель контролирует один из выходов неподтвержденной транзакции, он может создать дочернюю транзакцию, которая тратит этот выход и платит достаточно комиссии, чтобы вся связанная группа стала привлекательной. Родительскую транзакцию это не меняет: майнеры получают экономическую причину включить родителя и ребенка вместе. Текущая политика пакетов и кластеров в Bitcoin Core тоньше старой формулы «усредним две ставки комиссии», но на уровне пользователя принцип прежний: дочерняя транзакция может субсидировать родительскую, если пакет совместим с политикой.
Сторонние ускорители
Некоторые майнинговые сервисы предлагают ускорение транзакций, иногда бесплатно, иногда за плату. Это не функция протокола, и гарантировать включение в блок майнерами, которых они не контролируют, такие сервисы не могут. Никогда не сообщайте сид-фразу или приватный ключ и считайте мошенничеством любые непрошеные предложения «поддержки ускорителя». Легитимному сервису нужны максимум публичные данные о транзакции и, если услуга платная, обычная схема оплаты.
| Способ | Кто может им воспользоваться | Что он меняет | Главное ограничение |
|---|---|---|---|
| RBF | Обычно отправитель или кошелек, контролирующий исходные входы. | Создает конфликтующее расходование с более высокой комиссией. | Политика и поддержка в кошельке; исходная транзакция может подтвердиться первой. |
| CPFP | Любой, кто контролирует пригодный к расходованию выход ожидающей транзакции. | Добавляет дочернюю транзакцию с высокой комиссией, которую нужно майнить вместе с родительской. | Требует пригодного выхода и совместимого графа зависимостей. |
| Ожидание | Кто угодно. | Ничего; расчет на снижение загрузки сети или на выбор транзакции производителем блока. | Сроки не гарантированы; транзакция может быть локально вытеснена. |
| Ускоритель | Пользователи, принятые конкретным майнинговым сервисом. | Запрашивает приоритет у участвующих операторов. | Внепротокольное доверие и ограниченный охват; мошенничество встречается часто. |
Вывод: повышение комиссии в Bitcoin сводится к работе с конфликтами и пакетами, а не волшебный флаг приоритета. По возможности позволяйте кошельку самому сформировать замену.
Как ускорить или отменить ожидающую транзакцию Ethereum?
Быстрый ответ
Отправьте с того же аккаунта новую транзакцию с тем же nonce и достаточно более высокими параметрами комиссии. Для попытки отмены заменяющая транзакция обычно отправляет ноль ETH на собственный адрес отправителя. Nonce израсходует та корректная транзакция с этим nonce, которая исполнится первой; это гонка, а не гарантированный отзыв.
Замена для ускорения
Ускорение сохраняет исходное действие, но повышает maxFeePerGas и, если нужно, maxPriorityFeePerGas. Замена должна удовлетворять правилам повышения цены в кошельке, клиенте уровня исполнения или у провайдера. Поскольку базовая комиссия может измениться, пока транзакция ждет, повышение одной лишь надбавки не поможет, если максимальная комиссия больше не покрывает базовую комиссию плюс фактическую надбавку.
Попытка отмены
Кошелек может отправить простой перевод самому себе с тем же nonce и более высокими комиссиями. Если такая замена попадет в блок первой, исходная транзакция станет некорректной, потому что nonce уже израсходован. Если первой в блок попадет исходная транзакция, отмена проиграет. Если исходная транзакция была частной, публичный эндпоинт, через который отправляется отмена, может ее не видеть, и это усложняет гонку.
Не перепрыгивайте через заблокированный nonce
Отправка транзакции с более поздним nonce не отменяет и не обходит более раннюю. Обычно она просто встает в очередь за ней. Сначала разберитесь с самым ранним пропущенным или ожидающим nonce, а затем проверьте более поздние транзакции на устаревшие допущения и дублирующие действия в приложениях.
Осторожно с контрактами и разрешениями
Успешная отмена не дает исполниться конкретной транзакции. Она не отзывает выданные разрешения на токены (approvals), не отменяет ранее подтвержденный вызов контракта и не аннулирует офчейн-ордер, отправленный где-то еще. Если ожидающая транзакция важна с точки зрения безопасности, проверьте также состояние кошелька, приложения и разрешений, а не считайте замену по nonce полноценным реагированием на инцидент.
Вывод: «отмена» в Ethereum означает «выиграть гонку с безобидной заменой на тот же nonce». Это не сообщение об отмене, отправленное валидаторам.
Можно ли отменить подтвержденную транзакцию?
Быстрый ответ
Недавно включенная транзакция может покинуть каноническую цепочку при реорганизации. В Bitcoin вероятность отката, как правило, падает по мере накопления proof of work. В Ethereum клиенты показывают состояния latest, safe и finalized; откат финализированного состояния требует тяжелого сбоя консенсуса, при котором не менее трети всего застейканного ETH доказуемо подлежит слэшингу (slashing) и сжигается у ответственных за это валидаторов.
Что такое реорганизация
Узлы могут ненадолго получить конкурирующие корректные блоки у вершины цепочки. Правила выбора форка определяют, какая ветвь становится канонической. Когда ранее принятый блок проигрывает, его отсоединяют, а его место занимает победившая ветвь. Транзакции из отсоединенного блока рассматриваются заново: часть возвращается в мемпулы, часть подтверждается в новой ветви, а часть становится некорректной, потому что победило конфликтующее расходование или nonce аккаунта уже занят.
Bitcoin: вероятностная финальность
Узлы Bitcoin выбирают корректную цепочку с наибольшим накопленным proof of work. Надежность транзакции растет по мере того, как поверх нее добавляются корректные блоки с новой работой, но протокол не объявляет какую-то конкретную глубину математически окончательной. Шесть подтверждений давно стали соглашением для крупных сумм; они не обязательны для каждой транзакции и не дают абсолютной защиты от злоумышленника с достаточной и устойчивой вычислительной мощностью.
Ethereum: latest, safe и finalized
API уровня исполнения Ethereum различают недавние состояния. Latest указывает текущую каноническую вершину цепочки у клиента и может измениться при реорганизации даже при нормальной работе сети. Safe обозначает состояние, для которого реорганизация не ожидается при допущениях о честном большинстве и синхронности. Finalized означает последнюю криптоэкономически защищенную контрольную точку; ее откат требует ручного вмешательства сообщества после сбоя консенсуса и приводит к тому, что не менее трети всего застейканного ETH доказуемо подлежит слэшингу: ответственные валидаторы теряют и сжигают как минимум эту долю стейка, а конкретный размер штрафа зависит от того, сколько валидаторов наказано одновременно.
Финальность не является метафизической невозможностью
«Финализировано» означает сильную гарантию на уровне протокола и экономики, а не утверждение, что программное обеспечение, управление или человеческая координация никогда не смогут изменить историю после катастрофического сбоя. Ethereum описывает социальное восстановление как крайнюю меру после нечестной финализации. Bitcoin тоже полагается на то, что в исключительных обстоятельствах пользователи выбирают программное обеспечение и правила цепочки. Обычным пользователям стоит воспринимать это как крайние системные сценарии, а не как обычный механизм возврата платежа.
Вывод: глубина подтверждений измеряет растущую надежность, а финальность протокола обозначает более сильное состояние. Ни то, ни другое не создает канала возврата средств через службу поддержки для ошибочно авторизованной транзакции.
Сколько времени занимают подтверждения и финальность?
Быстрый ответ
Bitcoin нацелен на средний интервал между блоками в десять минут, но фактически блоки приходят случайно и промежуток может составлять секунды или гораздо больше. Ethereum работает по расписанию из 12-секундных слотов, хотя слоты могут пропускаться. При нормальном участии валидаторов финальность в Ethereum обычно наступает примерно через две эпохи по 32 слота, то есть около 13 минут.
Время в Bitcoin вероятностно
Bitcoin пересчитывает сложность майнинга так, чтобы в среднем блоки выходили примерно раз в десять минут. Это не расписание для следующего блока. Поиск proof of work случаен: следующий корректный блок может появиться сразу или после долгой паузы. Оценка комиссии задает вероятность подтверждения в пределах некоторого числа блоков на основе прошлых наблюдений за мемпулом и майнингом; обещать время по часам она не может.
Время в Ethereum разбито на слоты
Ethereum делит время на 12-секундные слоты и эпохи по 32 слота. На каждый слот выбирается один пропозер, но блок появляется не в каждом слоте. Транзакция, которую видит победивший пропозер или билдер и которая платит достаточную комиссию, может попасть в блок быстро; частная маршрутизация, стратегия билдера, потолки комиссии, порядок nonce или пропущенный слот могут ее задержать.
Финальность может приостановиться
При нормальных условиях голосование по контрольным точкам финализирует историю примерно через две эпохи. Если участие падает ниже необходимого порога в две трети, цепочка может продолжать выпускать блоки без финализации. Механизм утечки при бездействии (inactivity leak) в Ethereum постепенно снижает вес недоступных валидаторов, чтобы находящиеся в сети смогли со временем вернуть финальность, но задержка при этом не фиксирована.
| Сеть / состояние | Обычный ритм | Чего это число не гарантирует |
|---|---|---|
| Первое подтверждение в Bitcoin | Ожидаемый интервал между блоками около 10 минут. | Что следующий блок придет через 10 минут или что транзакцию включат в блок, даже если кошелек называет целевой срок. |
| Шесть подтверждений в Bitcoin | Часто описывается как примерно час в среднем. | Ровно 60 минут или абсолютную необратимость. |
| Включение в ближайший слот Ethereum | Один слот каждые 12 секунд. | Блок в каждом слоте, видимость для билдера, достаточную комиссию или нужный порядок nonce. |
| Финальность в Ethereum | Обычно около двух эпох, примерно 13 минут. | Фиксированный срок, если участие валидаторов или состояние сети ухудшаются. |
| Расчеты во втором уровне | Зависит от устройства роллапа. | Что включение в блок L2, публикация в L1, финальность доказательства и финальность вывода средств являются одним и тем же событием. |
Второй уровень добавляет новые часы
В роллапе Ethereum пользователь может увидеть мгновенное подтверждение от секвенсера, включение в блок L2, публикацию данных в Ethereum, завершение доказательства или периода оспаривания и доступность вывода средств как отдельные стадии. Правильный стандарт расчета зависит от роллапа и приложения. Не переносите цифру финальности основной сети Ethereum примерно в 13 минут на любой пользовательский опыт в L2.
Вывод: ритм выпуска блоков служит исходными данными для расчета времени, а не соглашением об уровне сервиса. Называйте диапазоны и состояния, а не точные обещания.
Сколько подтверждений стоит ждать получателю?
Быстрый ответ
Универсального числа нет. Получателю следует выбирать порог исходя из суммы транзакции, обратимости передаваемого товара, риска контрагента, безопасности сети, текущих сетевых условий и собственной способности отслеживать реорганизации и конфликтующие расходования.
Недорогая цифровая услуга может принимать больший риск реорганизации, чем биржа, зачисляющая крупный депозит, или продавец, отгружающий физический товар без возможности возврата. Получатель с мониторингом двойных трат в реальном времени может выбрать иначе, чем тот, кто полагается на один сторонний обозреватель. Правила зачисления депозитов в сервисах работают как меры контроля риска, а не как прямое отражение правил консенсуса.
| Ситуация | Разумный подход к надежности | Почему |
|---|---|---|
| Недорогая обратимая услуга | Допустимы прием по факту рассылки, меры контроля риска при нуле подтверждений или небольшая глубина, в зависимости от сети и антифрод-контроля. | Издержки редкого отката ограничены, а услугу можно отозвать. |
| Обычный перевод в сети | Дождаться включения в блок и достаточной глубины или статуса safe для суммы под риском. | Баланс между скоростью и обычным риском неглубокой реорганизации. |
| Крупная сумма или необратимая передача | Использовать консервативную глубину, финальность Ethereum или опубликованный порог сервиса. | Откат привел бы к существенным потерям, которые нельзя компенсировать операционно. |
| Депозит на бирже | Следовать правилу зачисления биржи для конкретного актива и сети. | Биржа учитывает безопасность сети, ликвидность и операционный риск по множеству депозитов. |
| Кросс-чейн мост или вывод из роллапа | Следовать явной модели финальности моста или роллапа. | Включение в исходной сети, выпуск в целевой сети и периоды оспаривания или доказательства являются отдельными этапами. |
Почему шесть подтверждений в Bitcoin стали общепринятыми
Шесть подтверждений означают содержащий транзакцию блок плюс пять последующих, то есть примерно час в среднем, и давно используются как консервативное соглашение для крупных сумм. В консенсусе Bitcoin эта величина не закреплена как константа расчета. Одним сервисам достаточно меньшего числа; другие требуют большего, когда суммы велики, безопасность сети ниже или стимулы для атаки необычно высоки.
Почему сервисы в Ethereum могут зачислять средства до финальности
Приложения иногда действуют по состояниям latest или safe, потому что ожидание полной финальности добавило бы задержку. Это осознанный выбор в отношении риска. Надежная система записывает хеш блока, идемпотентно обрабатывает реорганизации и откладывает необратимые последующие действия до достижения нужного состояния.
Вывод: используйте пороги подтверждений как откалиброванные меры контроля риска, а не как ритуальные числа, скопированные из другой сети или другого бизнеса.
Как правильно проверить транзакцию?
Быстрый ответ
Уточните сеть и хеш транзакции, затем проверьте включение в канонический блок, глубину подтверждений или состояние финальности, получателя, актив, сумму, комиссию и статус исполнения. Для крупного перевода используйте больше одного источника данных и не раскрывайте лишнюю информацию об адресах случайным обозревателям.
Для Bitcoin
- Уточните идентификатор транзакции и сеть.
- Проверьте, остается ли транзакция неподтвержденной или уже включена в канонический блок, и запишите хеш блока, а не только его высоту.
- Проверьте каждый значимый выход, а не только первый показанный адрес. У транзакций Bitcoin может быть несколько получателей и выход со сдачей.
- Если разбираетесь с задержкой, проверьте комиссию и виртуальный размер.
- Проверьте, не тратит ли те же входы конфликтующая транзакция и нет ли неподтвержденных родительских транзакций.
- Считайте подтверждения, начиная с содержащего блока как первого.
Для Ethereum
- Уточните хеш транзакции, идентификатор цепочки и сеть.
- Проверьте поля from, to, value, входные данные и события перевода токенов; перевод токена может не отражаться в значении ETH на верхнем уровне.
- Проверьте статус в квитанции. Статус 1 обычно означает успешное исполнение; статус 0 означает, что включенный вызов откатился.
- Смотрите на израсходованный газ и фактическую цену газа, а не считайте, что подписанная максимальная комиссия списана полностью.
- Запишите хеш блока и то, какое состояние сообщает ваш провайдер: latest, safe или finalized.
- Для взаимодействий с контрактами проверяйте вызванную функцию, логи и итоговое состояние, а не только надпись «подтверждено».
Приватность и риски обозревателей
Вставляя адреса и хеши транзакций в сторонний обозреватель, вы раскрываете свой интерес и можете передать этому провайдеру IP-адрес или метаданные, связывающие аккаунты. Публичные данные цепочки и так видны, но ваши запросы дают дополнительную информацию. Для чувствительных или институциональных задач обращайтесь к собственному узлу или доверенному инфраструктурному провайдеру и избегайте ссылок из поисковиков и непрошеных «обозревателей от поддержки».
Вывод: проверка означает изучение конкретного объекта в цепочке и его канонического состояния, а не доверие уведомлению кошелька, скриншоту или скопированной надписи из обозревателя.
Чек-лист диагностики
Быстрый ответ
Прежде чем что-то предпринимать, определите транзакцию, сеть, последовательность транзакций отправителя и текущее каноническое состояние. Затем выберите подходящий для этой сети способ, который поддерживает кошелек.
- Скопируйте хеш транзакции из кошелька. Уточните сеть и идентификатор цепочки.
- Проверьте, видит ли транзакцию доверенный узел или обозреватель. Для крупных сумм используйте второй независимый источник.
- Если транзакция не подтверждена, изучите параметры комиссии, зависимости и то, была ли она разослана публично или отправлена по частному маршруту.
- В Bitcoin проверьте неподтвержденных родителей, текущие условия по sat/vB и то, поддерживает ли кошелек RBF или CPFP.
- В Ethereum определите nonce аккаунта, самый ранний ожидающий nonce, максимальную комиссию, приоритетную комиссию и текущую базовую комиссию.
- Поищите конфликтующую замену: те же входы в Bitcoin или тот же отправитель и nonce в Ethereum.
- Если транзакция была подтверждена, а затем исчезла, сравните хеш ее прежнего блока с канонической цепочкой на предмет реорганизации.
- Если транзакция Ethereum подтверждена, но действие не выполнилось, изучите статус квитанции, логи и информацию об откате.
- Пользуйтесь встроенными в кошелек функциями ускорения или отмены, а не подписывайте произвольные инструкции из сообщений «поддержки».
- Никогда не раскрывайте приватный ключ или фразу восстановления. Для диагностики транзакции нужны публичные хеши и данные из вашего кошелька, а не ключевой материал.
Вывод: методичная проверка состояния быстрее и безопаснее, чем повторные отправки, смена сетей или следование непрошеным инструкциям по «возврату средств».
Часто задаваемые вопросы
Что такое одно подтверждение в криптовалюте?
Одно подтверждение обычно означает, что транзакция включена в канонический блок. В Bitcoin содержащий ее блок является подтверждением номер один. В Ethereum включение соответствует состоянию latest; приложения могут дополнительно ждать статуса safe или finalized.
Гарантирует ли более высокая комиссия попадание в следующий блок?
Нет. Конкурентная комиссия улучшает ожидаемый приоритет, но важны также время выхода блоков, зависимости, порядок nonce, локальная политика, частный поток ордеров, MEV и выбор производителя блока. Оценки комиссий отражают вероятность, а не дают гарантию.
Могут ли подтвердиться обе версии одной транзакции?
Конфликтующие транзакции Bitcoin, которые тратят один и тот же вход, не могут одновременно остаться в одной корректной цепочке. Транзакции одного аккаунта Ethereum с одинаковым nonce не могут обе исполниться в одной цепочке. При этом два неконфликтующих платежа, которые лишь выглядят похоже, могут подтвердиться оба, поэтому ручная повторная отправка опасна.
Можно ли отменить подтвержденную транзакцию Bitcoin?
После подтверждения обычной отмены не существует. Неглубокая реорганизация может убрать недавний блок, но отправитель не может потребовать возврата платежа. До подтверждения кошелек может попробовать RBF или CPFP, в зависимости от транзакции.
Можно ли отменить транзакцию Ethereum?
Только пока она ожидает, попытавшись заменить ее транзакцией с тем же nonce, которая платит достаточно, чтобы выиграть гонку. Если исходная транзакция подтвердится первой, отмена не удастся. Подтвержденную транзакцию нельзя отозвать заменой по nonce.
Почему моя транзакция Ethereum ждет даже с высокой приоритетной надбавкой?
Возможно, пропущен более ранний nonce, максимальная комиссия не покрывает текущую базовую комиссию плюс надбавку, транзакцию видит только один провайдер или билдеры предпочитают другие бандлы. Разберитесь с самым ранним nonce и проверьте все поля комиссии, а не только надбавку.
Что происходит, когда транзакция Bitcoin выпадает из мемпула?
Этот узел перестает ее хранить, но другие узлы могут сохранить ее или разослать заново. Входы остаются непотраченными в цепочке, пока не подтвердится какая-либо версия. Прежде чем снова использовать средства, проверьте конфликты и состояние кошелька.
Почему подтвержденная транзакция снова стала ожидающей?
Скорее всего, ее блок был отсоединен при реорганизации цепочки. Транзакция может вернуться в мемпул и подтвердиться снова, а может стать некорректной, если в новой канонической истории победила конфликтующая транзакция.
Всегда ли достаточно шести подтверждений?
Это широко используемое консервативное соглашение в Bitcoin, а не универсальная гарантия. Подходящая глубина зависит от суммы, стимулов для атаки, состояния сети и политики получателя. В других сетях используются иные модели надежности.
Сколько времени занимает финальность в Ethereum?
При нормальном участии валидаторов примерно две эпохи по 32 слота, то есть около 13 минут. Если участие падает ниже нужного порога, времени может потребоваться больше. Включение в блок обычно происходит раньше и не равно финальности.
Стоят ли дополнительные подтверждения дороже?
Отправитель не платит дополнительную комиссию за то, что поверх транзакции строятся новые блоки. Комиссия за включение платится один раз. Ожидание стоит времени, а вот транзакции замены могут потребовать дополнительных комиссий.
Доказывает ли успешный статус в обозревателе блоков, что получатель получил нужный токен?
Сам по себе нет. Проверьте правильность сети, контракта, получателя и суммы. В Ethereum изучите логи переводов токенов и статус квитанции; в Bitcoin проверьте соответствующие выходы и сдачу.
Короткий тест: что запомнилось?
1. Транзакция Bitcoin находится в каноническом блоке, и следующий блок еще не пришел. Сколько у нее подтверждений?
A. Ноль
B. Одно
C. Два
D. Зависит от кошелька
2. Почему два обозревателя могут расходиться в том, ожидает транзакция или нет?
A. Только один обозреватель подключен к интернету
B. У каждого узла свой мемпул и своя картина данных
C. Хеши транзакций меняются от сайта к сайту
D. Подтверждения приватны
3. Что делает child-pays-for-parent?
A. Удаляет родительскую транзакцию
B. Добавляет дочернюю транзакцию с высокой комиссией, чтобы майнеры оценили связанный пакет выгоднее
C. Меняет подпись родительской транзакции
D. Гарантирует попадание в следующий блок
4. Транзакция отмены в Ethereum использует тот же nonce, что и исходная. Что определяет исход?
A. Слово cancel в поле данных
B. То, какая корректная версия будет включена в блок первой при текущих условиях по комиссиям и маршрутизации
C. Производитель кошелька
D. Выбор получателя
5. У квитанции транзакции Ethereum статус 0. Что это означает?
A. Она все еще ожидает
B. Она включена в блок, но исполнение откатилось
C. Она заплатила нулевой газ
D. Она финализирована
6. Какое утверждение о финальности верно?
A. Шесть подтверждений в Bitcoin являются протокольным флагом финальности
B. Состояния latest и finalized в Ethereum означают одно и то же
C. Надежность в Bitcoin растет с глубиной, а Ethereum показывает явные финализированные контрольные точки
D. Ни одна подтвержденная транзакция никогда не может покинуть цепочку
Ответы
1\. B. Содержащий транзакцию блок является подтверждением номер один.
2\. B. Мемпулы и индексы провайдеров дают локальные, частично пересекающиеся картины, а не единую глобальную очередь.
3\. B. CPFP тратит неподтвержденный выход дочерней транзакцией с высокой комиссией, чтобы родительская и дочерняя стали экономически привлекательными вместе.
4\. B. «Отмена» сводится к гонке замен с одним и тем же nonce; nonce израсходует та версия, которая исполнится первой.
5\. B. Транзакция подтверждена как включенный в блок объект, израсходовала газ и nonce, но задуманные изменения состояния EVM откатились.
6\. C. В Bitcoin глубина дает вероятностную надежность; Ethereum добавляет протокольные состояния safe и finalized.
Источники и дополнительные материалы
Ключевые источники этой статьи, актуальные на июль 2026 года.
- Bitcoin Developer Guide: транзакции. https://developer.bitcoin.org/devguide/transactions.html
- Bitcoin Developer Guide: блокчейн. https://developer.bitcoin.org/devguide/block_chain.html
- Bitcoin Core 31.0, примечания к выпуску. https://bitcoincore.org/en/releases/31.0/
- Bitcoin Core 31.0, RPC bumpfee. https://bitcoincore.org/en/doc/31.0.0/rpc/wallet/bumpfee/
- Bitcoin Core, политика замены транзакций в мемпуле. https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
- Ethereum.org: транзакции. https://ethereum.org/developers/docs/transactions/
- Ethereum.org: газ и комиссии. https://ethereum.org/developers/docs/gas/
- Ethereum.org: proof of stake. https://ethereum.org/developers/docs/consensus-mechanisms/pos/
- Ethereum Execution APIs: теги блоков. https://ethereum.github.io/execution-apis/
- Ethereum.org: максимальная извлекаемая ценность. https://ethereum.org/developers/docs/mev/
- EIP-1559. https://eips.ethereum.org/EIPS/eip-1559
- Документация Geth: параметры командной строки. https://geth.ethereum.org/docs/fundamentals/command-line-options
- Ethereum.org: атака и защита в proof-of-stake. https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/
- Google Search Central: создание полезного и надежного контента, ориентированного на людей. https://developers.google.com/search/docs/fundamentals/creating-helpful-content
Производственные заметки: карта внутренних ссылок
Удалите этот раздел перед публикацией.
| Место якоря в этой статье | Целевая страница ссылки |
|---|---|
| Разделы о консенсусе и финальности | Proof of Work и Proof of Stake: сравнение |
| Разделы о подписании и ключах | Приватные и публичные ключи: объяснение |
| Читателю, которому нужна общая картина | Как на самом деле работает криптовалюта? Ключи, консенсус и транзакции |
| Упоминания проверки и мошеннических адресов | Криптомошенничество и угрозы: как их распознать и избежать |
| Первое употребление терминов мемпул, RBF, nonce, базовая комиссия | Криптоглоссарий: 50 ключевых терминов |
Было ли это полезно?
