*Пересылайте оригинальный заголовок «Эпохи и слоты на всю глубину: способы обеспечить пользователям Ethereum более быстрые времена подтверждения транзакций»

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

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

Окончательность в одноканальном режиме

Сегодня Эфириум Gasperконсенсус использует архитектуру слота и эпохи. Каждые 12-секундный слот подмножества валидаторов публикуют голос за голову цепи, и в течение 32 слотов (6,4 мин.) каждому валидатору предоставляется возможность проголосовать один раз. Затем эти голоса трактуются как сообщения в неявной форме Похожий на PBFTалгоритм консенсуса, который после двух эпох (12,8 мин) дает очень жесткую экономическую гарантию, называемую финальностью.

За последние несколько лет мы стали все более и более недовольны текущим подходом. Основные причины заключаются в том, что (i) это сложно, и существует множество ошибок взаимодействия между механизмом голосования слот за слотом и механизмом окончательности эпоха за эпохой, и (ii) 12,8 минут - это слишком долго, и никому не хочется ждать так долго.

Однослотовая окончательность заменяет эту архитектуру механизмом, гораздо более похожим наКонсенсус Tendermint, в котором блок N завершается до создания блока N+1. Основное отличие от Tendermint заключается в том, что мы сохраняем «утечка неактивности« механизм, который позволяет цепочке продолжать работу и восстановиться в случае отключения более чем 1/3 валидаторов.»

Диаграмма ведущего предложенногодизайн окончательной финальности с одним слотом_

Основная проблема SSF заключается в том, что на первый взгляд она подразумевает, что каждый владелец Ethereum должен отправлять два сообщения каждые 12 секунд, что было бы слишком большой нагрузкой для сети. Есть умные идеикак смягчить это, включая самые недавниеОрбита SSFпредложение. Но даже в этом случае, хотя это значительно улучшает пользовательский опыт, ускоряя достижение «окончательности», это не меняет того факта, что пользователям все равно придется ждать 5-20 секунд.

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

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

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

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

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

На основе предварительных подтверждений

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

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

Как описано, предварительные подтверждения обеспечивают гарантии для транзакций L1. Если роллапы«основанный», затем все L2 блоки являются L1 транзакциями, и та же самая механика может быть использована для предоставления предварительных подтверждений для любого L2.

На что мы на самом деле смотрим здесь?

Предположим, что мы реализуем окончательность в одном слоте. Мы используем Орбита-подобные методы для уменьшения количества валидаторов, подписывающих слот, но не слишком сильно, чтобы мы также могли добиться прогресса в достижении ключевой цели по снижению минимума стейкинга в 32 ETH. В результате, возможно, время слота ползет вверх, до 16 сек. Затем мы используем либо предварительные подтверждения свертки, либо предварительные подтверждения на их основе, чтобы предоставить пользователям более быстрые гарантии. Что мы имеем сейчас? Эпохальная архитектура.

Мем "they're the same picture" стал довольно избитым на данный момент, поэтому я просто размещу старую схему, которую я нарисовал много лет назад, чтобы описать архитектуру слотов и эпох Гаспера и схему предварительных подтверждений L2 рядом друг с другом, и, надеюсь, это донесет суть.

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

Одна простая причина - количество узлов. В то время как старая линейная @VitalikButerinПараметризация Casper: компромисс между децентрализацией, окончательностью и издержками смотрится теперь более мягко благодаря гипероптимизированной агрегации BLS и, в скором будущем, ZK-STARKs. Однако все еще фундаментально верно, что:

1. «Приблизительное соглашение» требует только нескольких узлов, тогда как экономическая окончательность требует значительной доли всех узлов.
2. Как только количество узлов превысит определенный размер, вам потребуется больше времени, чтобы собрать подписи.

В Ethereum сегодня 12-секундный интервал делится на три подинтервала для (i) публикации и распространения блоков, (ii) аттестации и (iii) агрегации аттестации. Если количество аттестаторов было бы гораздо меньше, мы могли бы перейти к двум подинтервалам и иметь интервал в 8 секунд. Другим, и реалистично более значимым фактором, является «качество» узлов. Если бы мы также могли полагаться на профессионализированный набор узлов для приближенных согласований (и все еще использовать полный набор валидаторов для окончательности), мы могли бы вероятно уменьшить его до ~2 секунд.

Поэтому мне кажется, что (i) архитектуры слотов и эпох очевидно правильны, но также (ii) не все архитектуры слотов и эпох созданы одинаково, и есть ценность в более полном исследовании пространства проектирования. В частности, стоит изучить варианты, которые не так тесно переплетены, как Gasper, и где вместо этого существует более сильное разделение между двумя механизмами.

Что должны делать L2s?

На мой взгляд, в настоящее время есть три разумные стратегии, которые могут применять L2.

1. Быть «основанным» как технологически, так и духовно. То есть, они оптимизируются для того, чтобы быть пропускными каналами для технических свойств базового уровня Ethereum и его ценностей (высокая децентрализация, устойчивость к цензуре и т. д.). В своей простейшей форме вы можете думать об этих rollups как о «брендованных фрагментах», но они также могут быть намного более амбициозными, чем это, и экспериментировать с новыми дизайнами виртуальных машин и другими техническими улучшениями.
2. Гордо быть «сервером с блокчейн-каркасом» и извлекать из этого максимальную пользу. Если начать с сервера, а затем добавить (i) доказательства правильности STARK, чтобы убедиться, что сервер следует правилам, (ii) гарантированные права пользователя на выход или принудительные транзакции, а возможно, (iii) свободу коллективного выбора, либо через координированный массовый выход, либо через возможность голосовать за изменение последователя, то вы уже получили множество преимуществ блокчейна, сохраняя при этом большую часть эффективности сервера.
3. Компромиссный подход: стоузловая быстрая цепочка, где Ethereum обеспечивает дополнительную взаимодействие и безопасность. Это фактическая текущая дорожная карта многих проектов L2.

Для некоторых приложений, (например, ENS, key-хранилища), достаточно 12-секундного времени блока. Для тех приложений, которые не являются таковыми, единственным решением является слотовая архитектура. Во всех трех случаях «эпохи» — это SSF Ethereum (возможно, мы можем изменить эту аббревиатуру на что-то другое, чем «один слот», например, это может быть «Secure Speedy Finality»). Но «слоты» в каждом из трех вышеперечисленных случаев – это нечто свое:

1. Архитектура слотов и эпох, специфичная для Ethereum
2. Предварительные подтверждения сервера
3. Предварительные подтверждения комитета

Ключевой вопрос заключается в том, насколько хорошо мы можем сделать что-то в категории (1)? В частности, если это становится действительно хорошим, то кажется, что категория (3) перестает иметь такой большой смысл. Категория (2) всегда будет существовать, по крайней мере, потому что что угодно "основанное" не подходит для оффчейн-данных L2, таких как плазмы и валидиумы. Но если эфир-нативная архитектура слотов и эпох может сократиться до 1-секундного "слота" (т.е. до момента подтверждения), то пространство для категории (3) становится значительно меньше.

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

Disclaimer：

1. Эта статья перепечатана с [Виталик].Пересылка оригинального заголовка «Эпохи и слоты на протяжении всего пути: способы обеспечения пользователям Ethereum более быстрых времен подтверждения транзакций». Все авторские права принадлежат оригинальному автору [Виталик*]. Если есть возражения против этой публикации, пожалуйста, свяжитесь с Gate Learnкоманда, и они быстро справятся с этим.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.