Быстрое подтверждение транзакций: новое направление для улучшения опыта пользователей Ethereum

Одним из важных аспектов пользовательского опыта в блокчейне является скорость подтверждения транзакций. В последние годы Ethereum добился значительного прогресса в этой области. Благодаря EIP-1559 и стабильному времени блока после перехода на PoS, транзакции, отправленные пользователями на L1, обычно подтверждаются в течение 5-20 секунд, что примерно соответствует опыту оплаты кредитной картой. Тем не менее, дальнейшее сокращение времени подтверждения все еще имеет значение, некоторые приложения даже требуют задержки менее одной секунды. В этой статье будут рассмотрены несколько жизнеспособных решений для повышения скорости подтверждения транзакций Ethereum.

Обзор существующих технологий

Однослотовая финальность

В настоящее время консенсус Gasper Ethereum использует архитектуру слота (Slot) и эпохи (Epoch). Каждый слот длится 12 секунд, часть валидаторов голосует за голову цепочки, 32 слота (6.4 минуты ) все валидаторы поочередно голосуют один раз. Эти голоса интерпретируются как сообщения в алгоритме консенсуса, подобном PBFT, и два эпохи (12.8 минуты ) обеспечивают сильные экономические гарантии окончательности.

В последние годы этот метод постепенно выявляет свои недостатки: во-первых, высокая сложность, взаимодействие между механизмами уровня слота и уровня эпохи легко может привести к ошибкам; во-вторых, время ожидания в 12,8 минуты слишком долго. Однослотовая финализация (Single Slot Finality, SSF) заменяет эту архитектуру с помощью механизма, аналогичного Tendermint, позволяя окончательно подтвердить блок N до его генерации N+1. SSF сохраняет механизм "неактивной утечки", который позволяет сети продолжать функционировать и восстанавливаться, даже если более 1/3 валидаторов находятся в оффлайне.

Основная проблема SSF заключается в том, что каждый стейкер должен отправлять два сообщения каждые 12 секунд, что создает большую нагрузку на цепочку. Хотя существуют некоторые решения, такие как недавнее предложение Orbit SSF, пользователи все равно должны ждать от 5 до 20 секунд для подтверждения транзакции.

Предварительное подтверждение Rollup

В последние годы Ethereum придерживается дорожной карты, сосредоточенной на rollup, разрабатывая L1 для поддержки таких основных функций, как доступность данных, для использования L2 протоколами (, такими как rollups, validiums и plasmas ), обеспечивая пользователям аналогичную безопасность на большем масштабе.

Это привело к разделению труда внутри экосистемы Ethereum: L1 сосредоточен на антицензуре, надежности и улучшении основных функций, в то время как L2 более непосредственно обслуживает потребности пользователей. Однако L2 стремится предоставить пользователям подтверждение быстрее, чем за 5-20 секунд.

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

Но группа L2 валидаторов может злоупотреблять: сначала подписать блок B1, а затем подписать противоречащий B2 и заранее его подать. Как только это будет обнаружено, они потеряют свои залоговые активы. В настоящее время уже есть примеры централизованных версий, но разработка децентрализованных сортировочных сетей для rollup идет медленно. Требовать от всех L2 реализации децентрализованной сортировки кажется довольно несправедливым, это почти равносильно созданию совершенно нового L1. Поэтому было предложено, чтобы все L2( и L1) использовали один механизм предварительного подтверждения в рамках Ethereum: базовое предварительное подтверждение.

Базовое предварительное подтверждение

Базовое предположение предварительного подтверждения заключается в том, что предложители Ethereum являются высоко сложными участниками, связанными с MEV, которые используют эту сложность путем стимулирования их к принятию на себя ответственности за услуги предварительного подтверждения.

Основная идея заключается в создании стандартизированного протокола, позволяющего пользователям платить дополнительную плату за мгновенную гарантию включения транзакции в следующий блок и получение декларации о результате транзакции. В случае нарушения обязательств предложителем, он будет подвергнут штрафу.

Эта механика может использоваться как для L1 транзакций, так и для L2 блоков, основанных на rollups.

Будущее

Предположим, мы реализовали окончательность с одним слотом, используя технологию, подобную Orbit, чтобы уменьшить количество валидаторов подписи на слот, одновременно продвигая цель по снижению порога ставки до 32 ETH. Длительность слота может увеличиться до 16 секунд, после чего мы будем использовать предварительное подтверждение rollup или базовое предварительное подтверждение, чтобы предоставить пользователям более быстрое подтверждение. В конце концов, мы получаем новую эпоху - архитектура слота.

Глубокая причина, по которой такая структура трудноизбежна, заключается в том, что время, необходимое для достижения общего согласия по какому-либо вопросу, значительно меньше времени, необходимого для достижения максимальной "экономической окончательности".

Основные причины включают количество узлов и "качество" узлов. "Приблизительное согласие" требует лишь небольшого числа узлов, в то время как экономическая окончательность требует участия большинства узлов. Специализированный подмножество узлов может снизить время протокола приблизительного согласия до примерно 2 секунд.

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

Выбор L2

В настоящее время существует три разумные стратегии L2:

1. Технически и концептуально "основано" на Ethereum, оптимизируя его базовые свойства и ценности. Можете рассматривать это как "брендированный шард", а также смело экспериментировать в таких областях, как новый дизайн VM.

2. Стать "сервером с блокчейн-скелетом", полностью используя преимущества централизованности, в то же время обеспечивая безопасность через доказательства эффективности, механизмы выхода и т. д.

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

Для некоторых приложений (, таких как ENS, хранение ключей, некоторые платежные протоколы ), время создания блока в 12 секунд уже достаточно. В других случаях требуется архитектура эпоха-слот, где "эпоха" является SSF Эфира, а "слот" варьируется в зависимости от приложения.

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

На данный момент мы далеки от окончательных ответов на эти вопросы. Эволюция сложности предложений блоков все еще остается довольно неопределенной. Новые разработки, такие как Orbit SSF, предоставляют широкие возможности для исследований. Чем больше вариантов, тем лучше мы можем предоставить пользователям L1 и L2 опыт, а также упростить работу разработчиков L2.