Что на самом деле происходит, когда вы отправляете транзакцию Ethereum

--> Проблема

Вы нажимаете "Отправить" в вашем кошельке. Интерфейс подтверждает транзакцию.

Но потом... ничего не происходит.

Иногда это подтверждается за секунды.
Иногда это зависает на минуты — или полностью не проходит.

Почему?

Большинство объяснений заканчиваются на "это попадает в блокчейн".

Это не полезно, если вы строите системы на .

Давайте разберем, что на самом деле происходит под капотом.

Ментальная модель (Быстрая ориентация)


Транзакция не исполняется мгновенно.

Это проходит через три разных фазы:

  • Распространение (мемпул)

  • Включение (предложение блока)

  • Исполнение (переход состояния)

Каждая фаза вводит задержки, риски и режимы неудачи.

Шаг 1: Создание транзакции

Когда вы нажимаете «отправить»:


  • Ваш кошелек создает транзакцию:

    • на

    • значение

    • gasLimit

    • maxFeePerGas

    • данные (если взаимодействие с контрактом)

    Он подписывает транзакцию с использованием вашего приватного ключа

На этом этапе:
👉 Транзакция валидна, но еще не известна сети

Шаг 2: Трансляция в сеть

Ваш кошелек отправляет транзакцию узлу.

  • Этот узел:

  • Проверяет подпись

  • Проверяет nonce

  • Обеспечивает базовую валидность

Если валидно → попадает в мемпул

Шаг 3: Мемпул (где все становится интересным)

Мемпул это:

  • Временная зона ожидания

  • Не глобально согласованная

  • Разная между узлами

Это означает:
👉 Ваша транзакция может существовать в некоторых узлах — но не в других

Ключевое поведение:

  • Узлы приоритизируют транзакции по комиссии

  • Высокая maxFeePerGas = высокий приоритет

📊 Диаграмма 1: Поток распространения транзакций


Диаграмма должна показывать:

  • Кошелек пользователя → Узел A → Узел B → Узел C

  • У каждого узла свой мемпул

  • Стрелки, показывающие распространение сплетен

  • Подчеркните: «Не все мемпулы одинаковы»

Шаг 4: Предложение блока

Валидаторы выбирают транзакции из своего мемпула.

Они выбирают:

  • Транзакции с самой высокой комиссией в первую очередь

  • Транзакции, которые укладываются в лимиты газа

Важно:
👉 Ваша транзакция конкурирует с другими


Шаг 5: Исполнение (уровень EVM)


Как только включена в блок

  • Транзакция выполняется внутри EVM

  • Изменения состояния происходят:

    • Обновления баланса

    • Изменения в хранении смарт-контрактов

Если исполнение не удается:

  • Газ все равно расходуется

  • Изменения состояния откатываются

📊 Диаграмма 2: Поток исполнения


Диаграмма должна показывать:

  • Блок → EVM → Переход состояния

  • Входные данные:

    • Транзакция

    • Текущее состояние


  • Выходные данные:

    • Новое состояние

  • Включите «потребление газа» на каждом этапе

Краевые случаи и режимы неудачи

Здесь большинство статей терпят неудачу. Давайте углубимся.

❌ 1. Транзакция застряла в мемпуле

  • Комиссия слишком низкая

  • Никогда не выбрана валидаторами

❌ 2. Упавшая транзакция

  • Узел удаляет это из-за:

    • Низкая комиссия

    • Переполнение мемпула

❌ 3. Замененная транзакция

  • Один и тот же nonce + более высокая комиссия → заменяет оригинал

❌ 4. Исполнение без газа

  • Исполнение останавливается на полпути

  • Состояние откатывается

  • Газ потерян

❌ 5. Реорганизация цепи (Reorg)

  • Блок заменяется

  • Транзакция может временно исчезнуть


Реальные последствия

Для разработчиков:

  • Вы не можете предполагать мгновенную финализацию

  • Необходимо обрабатывать ожидающие состояния

Для UX:

  • Пользователи видят «ожидание» → путаница

  • Оценка комиссии становится критически важной

Для проектирования систем

  • Логика повторных попыток необходима

  • Мониторинг транзакций обязателен

Ключевые выводы

  • Транзакция — это многоступенчатый процесс, а не одно событие

  • Мемпул недетерминированный и фрагментированный

  • Комиссии напрямую влияют на вероятность исполнения

  • Неудача может произойти на нескольких уровнях

  • Системы должны быть спроектированы длянеопределенности и задержек


Если вы строите на Ethereum, понимание этого процесса не опционально — это основа$ETH