Кнопка Send в криптокошельке создаёт иллюзию мгновенного перевода: пользователь вводит адрес, сумму, подтверждает операцию и видит transaction hash. Но в этот момент монеты ещё не «полетели» через интернет в другой кошелёк. Кошелёк сформировал и подписал инструкцию, а дальше начинается распределённый процесс: локальная проверка, распространение между узлами, попадание в mempool, конкуренция за место в блоке, исполнение или проверка, включение в каноническую историю и накопление финальности.
Понимание этого lifecycle полезнее любого списка «сколько минут идёт Bitcoin или Ethereum». Время зависит не только от block time. На него влияют fee policy, состояние mempool, nonce или UTXO-зависимости, правила конкретного клиента, загрузка сети, поведение block producer и риск reorg. Две транзакции, отправленные в одну секунду, могут пройти путь до устойчивого расчёта совершенно по-разному.
Транзакция — это подписанная инструкция, а не пакет с монетами внутри
В Bitcoin транзакция потребляет ранее созданные unspent transaction outputs и создаёт новые outputs. Кошелёк не уменьшает число в глобальной таблице балансов; он выбирает подходящие UTXO, формирует новые условия расходования и, если нужно, возвращает сдачу владельцу. Баланс кошелька — это производное представление набора доступных outputs, а не отдельная запись «Alice = 1.3 BTC» в consensus state.
Ethereum использует account-based модель. Транзакция от externally owned account содержит destination, value или calldata, gas-параметры и nonce. Она описывает переход состояния: списать ETH, вызвать контракт, создать контракт или изменить storage через исполнение EVM. В обоих случаях сеть получает не «деньги», а криптографически авторизованную инструкцию, которую каждый валидирующий участник способен проверить по правилам протокола.
Шаг 1. Кошелёк строит транзакцию
Перед подписью кошелёк собирает поля, которые должны однозначно описать намерение пользователя. Для Bitcoin это выбор inputs, outputs, суммы сдачи, fee и дополнительных параметров вроде sequence/locktime. Для Ethereum — nonce аккаунта, destination, value, calldata, gas limit и fee-поля. Кошелёк может часть этих решений скрывать за простым интерфейсом, но они всё равно становятся частью сериализованной транзакции.
Ошибки на этом этапе способны создать проблему ещё до сети. Неправильный адрес, слишком маленький fee, неверный nonce, недостаточный gas limit или попытка потратить уже использованный UTXO могут привести к отказу или длительному pending. Blockchain не исправляет намерение пользователя: криптографическая подпись, наоборот, делает сформированную инструкцию доказуемо авторизованной.
Шаг 2. Private key создаёт подпись
Кошелёк подписывает определённое протоколом представление транзакции private key отправителя. Подпись не раскрывает private key, но позволяет проверяющим убедиться, что авторизованная сторона действительно согласилась с данными транзакции. Если изменить подписываемые поля после подписи, проверка перестанет сходиться.
Это важная граница ответственности. Consensus может выбирать порядок допустимых транзакций, но не может легально «дописать» подпись владельца. Поэтому даже крупный майнер или validator не получает автоматической возможности отправить чужие средства. Он может влиять на inclusion или ordering в рамках threat model, но validity остаётся отдельным слоем.
Шаг 3. Появляется transaction hash
После сериализации подписанной транзакции клиент может вычислить её identifier. Пользователь обычно видит его как txid или transaction hash. Это удобный ключ наблюдения: по нему explorer, node RPC или кошелёк ищет одну и ту же операцию на разных стадиях.
Но наличие hash не доказывает inclusion. Hash можно вычислить локально ещё до успешного broadcast. Поэтому фраза «у меня есть tx hash, значит транзакция в блокчейне» неверна. Сначала нужно понять, видел ли её хотя бы один peer, находится ли она в mempool конкретного узла и появилась ли позже в каноническом блоке.
Шаг 4. Broadcast — это распространение между peers, а не запись в единую очередь
Bitcoin full nodes обмениваются транзакциями через peer-to-peer сеть. Узел, получивший транзакцию, проверяет её и при соблюдении consensus и relay policy может объявить её соседям. Ethereum-клиенты тоже распространяют pending transactions между peers. В результате информация расходится по графу сети, но нет одного центрального сервера, куда обязаны попасть все операции.
Отсюда первый практический сюрприз: разные узлы могут в один момент видеть разные наборы pending transactions. Сетевые задержки, локальные policy, лимиты памяти и topology означают, что «mempool сети» — удобная метафора, а не буквально единая база данных.
Шаг 5. Mempool — локальное мнение узла о кандидатах на inclusion
Bitcoin Developer Guide прямо описывает memory pool как набор непodтверждённых транзакций, которые узел считает пригодными для будущего блока. Bitcoin Core RPC getrawmempool возвращает содержимое mempool именно конкретного узла. Другой node может иметь немного другой набор.
Это различие объясняет странные ситуации в explorers. Один сервис показывает pending, другой не находит tx; один miner видит операцию, другой ещё нет. В Ethereum термин transaction pool играет похожую роль: клиент хранит допустимые pending operations, но локальная policy и состояние account nonces могут различаться.
Consensus rules и mempool policy — не одно и то же
Транзакция может быть допустима правилами блока, но не соответствовать default relay policy конкретного клиента. Mempool защищает ресурсы узла: память, bandwidth и CPU проверки не бесконечны. Клиент имеет правила о минимальной fee, размере, зависимостях, replacement и других параметрах.
Это важно при разборе фразы «сеть отклонила транзакцию». Иногда транзакция действительно consensus-invalid. Иногда она просто не проходит relay policy большинства узлов в текущей конфигурации. Эти ситуации требуют разных действий: в первом случае её нельзя честно включить в валидный блок; во втором теоретически block producer может принять её другим путём, если она всё же соответствует consensus rules.
Почему транзакция остаётся pending
Наиболее очевидная причина — fee недостаточно конкурентоспособен относительно других кандидатов. Block space ограничен, и producers выбирают набор операций с учётом собственной экономической policy. Когда спрос растёт, низкоприоритетная операция может ждать несколько блоков.
Но pending не всегда про fee. В Ethereum транзакция с nonce 105 может зависеть от отсутствующей или застрявшей 104. В Bitcoin child transaction может зависеть от неподтверждённого parent. Узел может потерять транзакцию после restart или eviction. Кошелёк может считать её отправленной, хотя broadcast не получил достаточного распространения. Поэтому troubleshooting начинается не с автоматического «подними комиссию», а с определения реального состояния.
Nonce в Ethereum: почему порядок одного аккаунта имеет значение
Nonce создаёт последовательность операций externally owned account. Если аккаунт уже подтвердил nonce 10, следующая обычная транзакция использует 11. Это предотвращает повторное воспроизведение одной и той же подписанной инструкции как нового платежа и задаёт порядок state changes от одного отправителя.
Если пользователь отправил transaction nonce 11 с низким fee, а затем nonce 12 с высоким, вторая может не исполниться раньше первой: account state ожидает последовательность. Отсюда типичная «очередь» нескольких pending операций. Replacement обычно строится вокруг новой транзакции с тем же nonce и более привлекательными fee-параметрами, но точные правила зависят от клиента и кошелька.
UTXO dependencies в Bitcoin: другая форма порядка
Bitcoin не имеет account nonce, но зависимости создаются через inputs. Нельзя потратить output, который ещё не существует в текущей chain state. Child transaction, использующая output неподтверждённого parent, зависит от его судьбы.
Это даёт другой набор инструментов управления fee и пакетами транзакций. Важно понимать концепт: порядок возникает не из счётчика аккаунта, а из графа расходования outputs. Wallet UX может скрывать это, но mempool и miner policy видят структуру зависимостей напрямую.
Replacement — это не «редактирование старой транзакции»
Когда кошелёк предлагает ускорить pending transfer, технически он обычно не открывает существующий объект и не меняет строку fee внутри него. Изменение подписанных данных создаёт другую транзакцию и другой hash. Новая версия конкурирует с предыдущей по правилам replacement.
В Ethereum replacement обычно использует тот же account nonce, чтобы только одна версия могла окончательно занять эту позицию последовательности. В Bitcoin Replace-by-Fee и связанные policy определяют, когда узлы заменят одну неподтверждённую транзакцию другой. Поэтому после ускорения пользователь может увидеть несколько hashes, хотя экономически ожидал «один перевод».
Шаг 6. Block producer выбирает кандидатов
Майнер Bitcoin или validator Ethereum формирует блок не из абстрактного глобального списка, а из данных, которые доступны его node и соответствуют правилам. Экономика fee важна, но selection может учитывать зависимости транзакций, размер, gas, локальную policy, private order flow и другие ограничения.
Попадание в один mempool не создаёт гарантии inclusion в следующий блок. Даже высокая fee не отменяет validity. Producer может выбрать другой набор, не увидеть операцию вовремя или получить competing block. Поэтому «pending → confirmed» — вероятностный и сетевой переход, а не вызов API с гарантированным SLA.
Шаг 7. Узлы проверяют блок заново
Block producer не является доверенным администратором. Когда новый блок распространяется, валидирующие узлы самостоятельно проверяют его. Bitcoin node проверяет, что inputs допустимы, подписи и scripts удовлетворяют правилам, суммы и структура корректны. Ethereum execution clients переисполняют транзакции и проверяют resulting state относительно protocol rules.
Если producer включил недопустимую операцию, честные validating nodes не должны принять блок только потому, что он «пришёл от майнера» или «подписан валидатором». Именно независимая validation отделяет permissionless consensus от обычной базы данных с привилегированным writer.
Success в Ethereum не означает, что вызов контракта сделал то, что пользователь ожидал
Ethereum transaction может быть включена в валидный блок, но execution внутри EVM завершиться revert. В этом случае network resources уже были использованы, поэтому gas не возвращается полностью как при неотправленной операции. Explorer обычно показывает failed/reverted status, но сама transaction остаётся частью истории блока.
Это отличается от ситуации, когда node вообще отказался принять transaction как protocol-invalid или когда она исчезла из mempool до inclusion. Для диагностики важно разделять broadcast failure, pending, dropped, included-success и included-revert.
Confirmations: блок есть, но история ещё может измениться
После inclusion начинается следующий этап риска. В Bitcoin confirmation count увеличивается по мере появления последующих блоков над блоком с вашей транзакцией. Чем глубже он находится в chain с накопленной работой, тем больше ресурса требуется для reorg этой истории.
Это не магическая лестница, где одна confirmation «опасна», а шесть всегда абсолютны. Threshold выбирает приложение. Небольшой платеж и крупный вывод с биржи имеют разный risk budget. Состояние сети, value at risk и operational policy могут менять требуемую глубину.
Finality в Ethereum — отдельное consensus-состояние
Ethereum.org описывает lifecycle от broadcast к transaction pool, inclusion, а затем к justified и finalized состояниям block history. Finality связана с голосами validator stake за checkpoints. Это не просто альтернативное название числа confirmations.
Поэтому UI, который показывает «12 confirmations» в одной сети и «finalized» в другой, говорит о разных механизмах уверенности. Для cross-chain bridge или exchange integration нельзя копировать одно число между протоколами. Нужно использовать semantics конкретной сети.
Что происходит при reorg
Reorg означает, что node заменяет часть ранее выбранной канонической ветки другой допустимой веткой. Если транзакция была в отброшенном блоке, её судьба зависит от новой истории и локального mempool. В Bitcoin Core transactions из stale blocks могут возвращаться в memory pool, если остаются допустимыми, а затем снова быть включены в replacement chain.
Для пользователя это выглядит странно: сначала explorer показывал одну confirmation, затем снова pending или новый block height. Это не обязательно атака. Короткие reorg могут быть нормальным следствием сетевой конкуренции. Но именно поэтому applications ждут дополнительную глубину или protocol finality перед необратимым внешним действием.
Dropped и evicted: транзакция может исчезнуть из mempool, не став confirmed
Mempool не является архивом обещаний. Узел может удалить операцию из-за ограничений памяти, fee policy, replacement, конфликтующей транзакции или restart. Другие peers ещё могут её хранить, поэтому один explorer способен перестать видеть tx, а другой продолжать показывать.
Если никакие peers больше не распространяют транзакцию и она не попала в блок, blockchain не содержит постоянной записи о том, что пользователь когда-то пытался её отправить. Это полезно помнить при расследовании: wallet history может сохранять локальный факт создания, который никогда не стал on-chain фактом.
Explorer — наблюдатель, а не арбитр
Block explorer агрегирует node data и превращает её в удобный интерфейс. Он может показывать mempool, fee estimate, confirmations, execution status и decoded contract call. Но explorer не создаёт consensus. Если UI ошибся или его backend отстал, сеть не меняется вслед за сайтом.
Для критичной операции полезно сравнить два независимых источника или запросить собственный node. Transaction hash, block hash, height, confirmations/finality status и execution result — это поля, которые стоит проверять отдельно. Особенно опасно ориентироваться только на зелёный значок Success без понимания, что именно он означает в конкретном explorer.
Почему «сколько идёт транзакция?» — плохой вопрос без контекста
Время состоит из нескольких интервалов: создание и подпись, распространение, ожидание inclusion, производство блока, канонизация и достижение нужного уровня finality. Wallet может показать tx почти мгновенно, хотя ни один удалённый peer её ещё не видел. И наоборот, inclusion может произойти быстро, но приложение будет ждать финальности дольше.
Поэтому лучше спрашивать: когда транзакция стала известна peers; когда она вошла в блок; сколько canonical history построено поверх; достигнут ли protocol finality; и какой threshold требует конкретный получатель. Это превращает «медленно» из эмоции в диагностируемое состояние.
Практический алгоритм для pending transaction
Сначала убедитесь, что hash находится хотя бы в одном независимом explorer или node. Затем проверьте, pending ли она или уже included. Для Ethereum сравните nonce с последней подтверждённой операцией аккаунта и убедитесь, что нет gap. Для Bitcoin проверьте parent transactions и fee policy. После этого сравните текущую fee competitiveness, а не только первоначальную настройку кошелька.
Если нужна replacement, используйте функцию кошелька, который понимает правила сети, а не вручную отправляйте случайную вторую операцию. Если transaction уже included, задача меняется: теперь нужно следить за confirmations/finality, а не пытаться «ускорить» то, что уже находится в блоке.
Главный вывод
Криптотранзакция проходит не одну очередь, а последовательность независимых проверок и состояний. Кошелёк формирует intent. Подпись доказывает authorization. P2P relay распространяет данные. Mempool конкретного узла решает, хранить ли их как кандидата. Block producer выбирает inclusion. Validating nodes проверяют блок. Consensus определяет canonical history. Confirmations или finality определяют, насколько безопасно считать результат необратимым.
Если держать эти слои раздельно, большинство загадок исчезает. Pending — не обязательно сбой. Hash — не доказательство inclusion. Inclusion — не всегда finality. Success — не гарантия бизнес-результата smart contract call. И даже confirmed transaction до достаточной глубины может временно оказаться на ветке, которую сеть затем заменит.
FAQ
Почему у транзакции есть hash, но explorer её не видит? Hash можно вычислить локально до успешного broadcast. Кошелёк мог создать и подписать tx, но она ещё не распространилась или уже исчезла из mempool наблюдаемого узла.
Есть ли один общий mempool у Bitcoin? Нет. Каждый full node поддерживает собственный memory pool по своей policy. Наборы обычно сильно пересекаются, но не обязаны быть идентичными.
Почему Ethereum transaction с высокой fee всё равно может ждать? Причиной может быть предыдущий missing/pending nonce, локальная propagation, client policy или другая зависимость. Fee — важный, но не единственный фактор.
Можно ли изменить уже отправленную транзакцию? Подписанные данные нельзя изменить без создания новой подписи и обычно нового hash. Механизмы replacement создают конкурирующую версию, а не редактируют старый объект на месте.
Что будет с транзакцией после reorg? Если её блок выпал из канонической истории, transaction может вернуться в mempool и попасть в новый блок, если остаётся допустимой, либо конфликтовать с новой историей и не вернуться.
Чем confirmation отличается от finality? Confirmation обычно отражает глубину inclusion в текущей канонической истории. Finality — протокольное состояние, после которого обычный reorg этого участка не должен происходить без нарушения ключевых assumptions consensus.
Материал носит образовательный характер и не является финансовой рекомендацией или торговым сигналом.