Пользователь отправляет транзакцию в Ethereum и обычно ждёт, пока её включат в блок. Затем появляются подтверждения, а окончательная уверенность приходит с финальностью консенсуса. Preconfirmation добавляет ещё один, более ранний сигнал: участник будущего производства блока заранее обещает включить операцию на оговорённых условиях.
Такое обещание может появиться значительно раньше блока и сделать приложение отзывчивее. Биржа, rollup или платёжный интерфейс способны показать предварительный результат почти сразу. Но preconfirmation не переписывает правила Ethereum и не превращает обещание в финальный блок. Чтобы правильно оценить риск, нужно различать сообщение сервиса, обязательство предложившего блок участника и подтверждение самой сети.
Что именно обещает preconfirmation
В простой модели пользователь передаёт транзакцию или заявку на исполнение. Участник, связанный с будущим proposer, проверяет её и подписывает обязательство: включить операцию в определённый блок, сохранить порядок или выполнить заданное состояние. Формат зависит от протокола. Одни схемы обещают только включение, другие добавляют ограничения по порядку и результату.
Ценность сигнала опирается не на красивую отметку в интерфейсе, а на способность наказать нарушителя или доказать нарушение. Это может быть залог, slashing, репутация или договор между участниками. Если обещание невозможно проверить и за нарушение ничего не происходит, оно остаётся сообщением доверенного посредника.
Транзакция при этом ещё не находится в канонической цепочке. До выпуска блока возможны отказ инфраструктуры, смена ожидаемого proposer, конфликт обещаний или цензура. Пользователь должен знать срок действия обязательства и сценарий возврата к обычной отправке, если оно не выполнено.
Чем обещание отличается от включения и финальности
Есть три последовательных состояния. Preconfirmation сообщает о намерении будущего производителя блока. Включение означает, что транзакция уже записана в конкретный блок. Финальность означает, что консенсус Ethereum завершил экономически значимый выбор цепочки и откат потребовал бы нарушения протокола большим объёмом валидаторского капитала.
Даже включённый блок сразу не равен финальному. Он может остаться частью канонической цепочки, но до финальности приложение всё равно учитывает возможность реорганизации. Подробно уровни уверенности разобраны в статье о подтверждении в L2 и финальности Ethereum. Preconfirmation находится ещё раньше и наследует дополнительные риски своего поставщика.
Поэтому интерфейс не должен называть все три сигнала одним словом «подтверждено». Для оплаты чашки кофе раннего обещания иногда достаточно. Для крупного вывода, ликвидации залога или выпуска актива в другой сети требуется более сильный уровень уверенности. Требование зависит от стоимости ошибки, а не только от скорости.
Кто способен дать надёжное обещание
В Ethereum право предложить блок переходит между валидаторами. Чтобы preconfirmation была связана с реальным будущим слотом, протоколу полезно заранее знать последовательность proposer. Механизм proposer lookahead делает этот график доступным раньше и создаёт основу для схем, где обязательства дают сами будущие proposer или делегированные ими участники.
На практике производство блока разделено между несколькими ролями. Валидатор может передать построение блока builder, подключиться к relay или использовать отдельный sidecar для обязательств. Тогда важно определить, кто подписал обещание и кто контролирует итоговое содержимое блока. Если полномочие делегировано, цепочка ответственности должна быть проверяема.
Для rollup возможна другая модель: sequencer обещает порядок L2-транзакций до публикации данных в Ethereum. Это ускоряет локальный интерфейс, но гарантия зависит от правил rollup. Материал о shared sequencer показывает, как отдельная сеть секвенирования распределяет эту роль, а based rollup связывает упорядочивание с инфраструктурой Ethereum.
Основные риски preconfirmations
Первый риск – equivocation, когда один участник выдаёт несовместимые обещания. Для наказания нужны подписанные доказательства и заранее определённые правила. Второй – liveness: обещавший участник может потерять связь, пропустить слот или не получить право на нужный блок. Компенсация за нарушение не всегда покрывает экономический ущерб пользователя.
Третий риск – централизация. Инфраструктура с быстрым доступом к proposer может превратиться в привилегированный шлюз. Если несколько крупных операторов контролируют рынок обещаний, они получают дополнительную информацию о потоке ордеров и возможность выбирать клиентов. Конкуренция между поставщиками и открытая проверка подписей снижают этот риск, но не устраняют его автоматически.
Четвёртый риск связан с условиями. Обещание «включить транзакцию» ничего не говорит о её успехе. Контракт может вернуть ошибку, цена обмена измениться, а состояние счёта – стать другим. Симуляция помогает увидеть ожидаемый результат, но сама тоже опирается на выбранное состояние. Поэтому полезно понимать, почему симуляция не является гарантией.
Как читать preconfirmation в приложении
Проверьте четыре свойства: кто подписал обязательство, к какому слоту или диапазону оно относится, что именно обещано и как доказать нарушение. Отдельно выясните, что произойдёт после истечения срока: приложение повторно отправит исходную транзакцию, запросит новую подпись или отменит действие.
Посмотрите, может ли пользователь самостоятельно проверить подпись и статус. Закрытая зелёная галочка сервиса требует доверия к его базе данных. Публичный формат обязательства позволяет другому клиенту подтвердить автора, условия и конфликт обещаний. Однако даже проверяемая подпись доказывает факт обещания, а не включение в Ethereum.
Для операций между сетями спросите, какой этап запускается после preconfirmation. Если мост выпускает актив до финальности исходной цепочки, он принимает риск отката или невыполнения обещания. Такой риск должен покрываться собственным обеспечением и правилами разрешения споров, а не переноситься незаметно на пользователя.
Где технология действительно полезна
Preconfirmations подходят приложениям, где важен быстрый отклик: обмену, играм, платежам и последовательности действий между rollup. Пользователь раньше узнаёт вероятный порядок операций и может продолжить сценарий. Для маркет-мейкера это уменьшает неопределённость, а для интерфейса – паузу между подписью и видимым результатом.
Их сила ограничена формулировкой обязательства и стоимостью нарушения. Чем крупнее операция и сложнее межсетевой эффект, тем осторожнее следует относиться к раннему сигналу. Preconfirmation полезна как дополнительный уровень уверенности до блока. Финальность по-прежнему появляется только тогда, когда сработали правила консенсуса Ethereum.
