Автор: Виталик, основатель Ethereum Перевод: 0xjs@金财经;

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

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

Завершение одного слота

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

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

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

Окончательный чертеж конструкции одного резервуара

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

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

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

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

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

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

На основании предварительного подтверждения

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

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

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

Что мы на самом деле здесь видим?

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

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

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

Простая причина — количество узлов. Хотя старый компромисс между линейной децентрализацией, возможным временем и накладными расходами теперь выглядит мягче благодаря ультраоптимизированной агрегации BLS и ZK-STARK в ближайшем будущем, по сути, следующие моменты остаются верными:

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

2. Как только количество узлов превысит определенный масштаб, вам нужно будет потратить больше времени на сбор подписей.

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

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

Что должен делать L2?

По моему мнению, в настоящее время существует три разумные стратегии, которые L2 может принять:

1. Будь то технический уровень или духовный уровень, он должен быть «основан». То есть они оптимизированы как каналы доставки с учетом технических свойств базового уровня Эфириума и его ценности (высокая децентрализация, устойчивость к цензуре и т. д.). В своей простейшей форме вы можете думать об этих накопительных пакетах как о «фирменных осколках», но они также могут быть более амбициозными и включать обширные эксперименты с новыми конструкциями виртуальных машин и другими техническими улучшениями.

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

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

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

1. Собственная архитектура слотов и эпох Эфириума

2. Предварительное подтверждение сервера

3. Предварительное подтверждение комитетом

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

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