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

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

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

Однослотовая окончательность

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

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

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

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

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

Подтверждения предварительной загрузки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отказ от ответственности:

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