Эволюция Ethereum на уровне «секунд»: от быстрого подтверждения до сжатия расчетов, как Interop уничтожает время ожидания?

Автор: imToken

Если вы часто осуществляете кроссчейн-пересылки между Base, Arbitrum или Optimism, вы наверняка ощущали тонкое «чувство разрыва».

Хотя отдельная транзакция L2 уже почти мгновенно подтверждается, при попытке перевести активы с цепочки A на цепочку B зачастую приходится ждать несколько минут или даже дольше. Это не связано с недостаточной скоростью L2, а обусловлено традиционным процессом, при котором транзакция, затрагивающая межслойные и межцепочечные операции, должна пройти длинный и строгий путь:

L2 сортировщик → отправка на L1 → достижение консенсуса и окончательное подтверждение (Finality), в целом, в текущей архитектуре Ethereum окончательное подтверждение на L1 обычно занимает два Epoch (около 13 минут). Это безусловно необходимо для безопасности, но для межоперабельности (Interop) кажется слишком медленным.

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

И именно в этом контексте дорожная карта Ethereum по межоперабельности на этапе ускорения (Acceleration) четко обозначила три направления высококоординированных улучшений: правила быстрого подтверждения (Fast L1 Confirmation Rule), сокращение времени Slot на L1 (Shorter L1 Slots), сжатие периода расчетов второго уровня (Shorter L2 Settlement).

Можно сказать, что это не просто набор отдельных оптимизаций, а системная реконструкция, ориентированная на «подтверждение, такт и расчет».

1. Правила быстрого подтверждения: дать системе «доверенный ответ» до достижения Finality

Как известно, в текущей архитектуре Ethereum блоки на основной сети создаются примерно каждые 12 секунд. Валидационные узлы голосуют за состояние цепочки в каждом slot, а окончательное подтверждение (Finality) достигается с задержкой по сравнению с несколькими слотами.

Проще говоря, даже если транзакция уже включена в блок, системе требуется ждать достаточно долго, чтобы убедиться, что она не будет отменена или откатана. В настоящее время для того, чтобы транзакция считалась окончательно необратимой, требуется примерно два Epoch (около 13 минут). Для большинства финансовых сценариев в блокчейне это слишком долго.

Можем ли мы до достижения Finality дать приложениям и межцепочечным системам «достаточно быстрый и надежный» сигнал подтверждения? Это и есть задача, которую ставит перед собой проект #4 в дорожной карте Ethereum: Fast L1 Confirmation Rule (Правила быстрого подтверждения).

Ее основная цель — обеспечить приложениям и системам межоперабельности получение «сильного и проверяемого» сигнала подтверждения на L1 в течение 15–30 секунд, без необходимости ждать 13 минут до финальности.

Механизм этого очень прост: правила быстрого подтверждения не вводят новый механизм консенсуса, а используют существующие attester-голосования в системе PoS Ethereum. Когда в ранних слотах уже собрано достаточно голосов валидаторов, даже если транзакция еще не достигла стадии окончательного подтверждения, она может считаться «подтвержденной в рамках допустимых атаковых моделей, крайне маловероятной для отката».

Проще говоря, этот уровень подтверждения не заменяет Finality, а предоставляет предварительный сильный сигнал, который протокол явно признает. Для межоперабельности это особенно важно: межцепочечные системы, Intent Solver и кошельки больше не должны ждать окончательной финальности, а могут в течение 15–30 секунд безопасно перейти к следующему шагу, основываясь на протокольном сигнале подтверждения.

На сегодняшний день, например, предварительное подтверждение (Preconfirmation), активно продвигаемое в рамках концепции Based Rollup, выполняет именно такую роль переходного этапа. Его логика очень проста: представьте ситуацию, когда вы покупаете билет на поезд на сайте 12306 — после выбора маршрута и подписания транзакции, система сразу дает вам предварительное подтверждение, что ваш заказ принят и переходит в следующий этап обработки. Только после окончательного подтверждения (выдачи билета с номером вагона и места, то есть публикации транзакции в L1) сделка считается завершенной.

Проще говоря, в рамках Based Rollup предварительное подтверждение — это обещание, что транзакция будет включена в блок до ее окончательного подтверждения. Это своего рода предварительный сигнал, позволяющий пользователю понять, что транзакция принята и обрабатывается.

«Я даю вам сильное устное обещание, а окончательное подтверждение будет позже», — так работает эта многоуровневая логика подтверждения. В дорожной карте Ethereum по межоперабельности это помогает балансировать между «безопасностью» и «скоростью», создавая разные уровни доверия и обеспечивая максимально плавный опыт взаимодействия.

2. Сокращение L1 Slot: ускорение «сердцебиения» Ethereum

В дополнение к правилам быстрого подтверждения — это более фундаментальное изменение, связанное с физической реализацией: сокращение размера Slot.

Если быстрый подтверждение — это своего рода «аванс» перед финализацией, то сокращение времени Slot — это уменьшение периода «расчета» в блокчейне. В рамках дорожной карты проект #5 ставит цель — снизить время Slot на Ethereum с текущих 12 секунд до 6 секунд.

Это кажется простым «уменьшением вдвое», но на практике вызывает цепную реакцию: чем короче Slot, тем быстрее транзакции попадают в блок, проходят верификацию и подтверждение, что снижает задержки на уровне протокола.

Для пользователей это означает более быстрые подтверждения при взаимодействии с L1 (например, ETH перевод), более оперативное обновление состояния L2 на L1, а в совокупности — «почти мгновенную обратную связь в цепочке», что позволяет DApps, кошелькам и межцепочечным протоколам строить «секундные» подтверждения.

Для межцепочечных протоколов сокращение времени также означает рост эффективности использования капитала: сейчас мосты и маркет-мейкеры вынуждены учитывать риск «зависания средств» на несколько минут или дольше, что увеличивает комиссии. При сокращении расчетных циклов эти издержки значительно снизятся, что приведет к меньшим издержкам, меньшим комиссиям и меньшей задержке зачислений — и, соответственно, к более активному возвращению разработчиков и пользователей к безопасной L1-расчетной базе, а не к уязвимым сторонним реле.

Конечно, удвоение частоты «сердцебиения» — сложная задача. Команды Ethereum Foundation уже работают над этим:

• Анализ сети: исследовательские группы (включая Maria Silva и др.) проводят тщательный анализ данных, чтобы убедиться, что сокращение Slot не вызовет серьезных рисков реорганизации (Reorg) или централизации из-за пропусков в сети;
• Реализация клиента: это комплексная переработка как уровня консенсуса, так и уровня исполнения. Важно, что эта работа независима от EIP-7732 (разделение валидаторов и строителей ePBS), что позволяет планам ускорения «сердцебиения» развиваться независимо от прогресса ePBS.

В целом, при объединении Slot в 6 секунд и правил быстрого подтверждения Ethereum сможет обеспечить «почти мгновенную обратную связь», что откроет новые возможности для DApps и кошельков в части секундных подтверждений.

3. Сокращение периода расчетов L2: «мгновенный вывод» активов

В рамках дорожной карты проект #6 — Shorter L2 Settlement — вызывает наибольшие споры, но и самые яркие перспективы.

В текущей архитектуре Optimistic Rollup обычно используют 7-дневный период оспаривания, а даже ZK Rollup ограничены скоростью генерации и проверки доказательств. В целом, эта схема обеспечивает безопасность, но создает проблему: активы и состояние «заперты» между цепочками, что увеличивает издержки и нагрузку на Solver, а в итоге — повышает комиссии пользователей. Поэтому сокращение периода расчетов — один из ключевых факторов масштабирования межоперабельности.

Основные направления — это:

• Реальные ZK-доказательства: с развитием аппаратного ускорения и рекурсивных доказательств время генерации сокращается с минут до секунд;
• Более быстрые механизмы расчетов: например, внедрение безопасных моделей 2 из 3 для расчетов;
• Общий слой расчетов: объединение нескольких L2 в единую систему с общими семантиками, без «вывода — ожидания — пополнения».

Однако в дискуссиях возникает вопрос: если для ускорения межцепочечных подтверждений период оспаривания сократить с 7 дней до 1 часа, не откроет ли это возможности для злоумышленников?

Теоретически, опасения оправданы. В отличие от «жесткого цензурирования» (коллективное злоупотребление валидаторами), более опасной является мягкая цензура — атаки, управляемые «поддержкой» со стороны блокстроителей: злоумышленник не обязательно должен контролировать консенсус, достаточно постоянно подавлять защитников, чтобы ключевые транзакции не попадали в цепочку.

Интересно, что единственный системный экономический анализ таких сценариев был опубликован Offchain Labs в феврале 2025 года в статье «Economic Censorship Games in Fraud Proofs». В ней рассмотрены три модели, от пессимистичной до оптимистичной:

• G¹: содержание блока определяется самым высоким ценовым предложением;
• G¹ₖ: часть валидаторов постоянно формирует блоки локально;
• Gᵐ: несколько валидаторов совместно решают содержание блока, и достаточно, чтобы один из них выбрал защитника.

На практике, из-за возможности пропуска слотов (miss slots), некоторые модели могут деградировать до G¹, поэтому исследователи анализируют худший сценарий.

На основе этого предложена стратегия защиты — «игра на слабых местах» с задержкой: защитник может в один клик «отложить» проверку, не выполняя сразу все сложные проверки, а лишь успешно подать специальную транзакцию, которая автоматически продлевает период оспаривания с 1 часа до 7 дней. Например, при обнаружении аномалий он просто отправляет такую транзакцию, которая «зазвонит тревогу» и мгновенно увеличит период.

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

По расчетам, при наличии мощных ресурсов (например, 100 млрд долларов), защитник сможет в течение часа подготовить около 33 млн долларов на Gas для контрмер. А если сработает механизм задержки, и период увеличится до 7 дней, то стоимость защиты снизится примерно до 20 тысяч долларов.

Это — ключевое преимущество: стоимость атаки растет линейно, а защита — достаточно одного успешного «подтверждения» для блокировки злоумышленника.

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

Заключение

Многие могут спросить: зачем тратить усилия на оптимизацию задержек в несколько секунд или минут?

В эпоху Web3-гигантов мы привыкли ждать, считать задержки «естественной ценой» децентрализации. Но на пути массового внедрения Web3 пользователи не должны и не будут заботиться о том, на какой цепочке они работают, и не должны считать финальность L1.

Быстрое подтверждение, 6-секундное «сердцебиение» и асимметричные механизмы защиты — это в первую очередь попытка убрать переменную «время» из восприятия пользователя.

Как я уже говорил, лучшая технология — это та, которая делает сложность полностью невидимой в условиях мгновенного подтверждения.