Последнее обновление страницы: 23 февраля 2024 г.

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

Для завершения блока Ethereum требуется около 15 минут. Однако мы можем сделать валидацию блоков механизмом консенсуса Ethereum более эффективной и радикально сократить время на завершение. Вместо ожидания по пятнадцать минут блоки могут предлагаться и завершаться в одном слоте. Этот концепт называют завершенностью одного слота (SSF).

Что такое окончательность?

В механизме консенсуса Ethereum, основанном на доказательстве владения, завершенность — это гарантия, что блок не может быть изменен или удален из блокчейна без сжигания по крайней мере 33 % от всех находящихся в стейкинге ETH. Это безопасность, обеспеченная «крипто-экономикой», поскольку уверенность исходит из экстремально высоких расходов, требуемых для изменения порядка содержимого сети (что мешает любому рациональному участнику экономики пытаться сделать это).

Зачем ускорять завершение?

Сейчас завершение занимает слишком много времени. Большинство пользователей не хотят ждать 15 минут для завершения, и это неудобно для приложений и обменников, которые хотели бы ускорить пропускную способность транзакций, а не ждать так долго из утверждения. Задержка между предложением блока и завершением также создает возможность для быстрых реорганизаций, которые атакующий может использовать для цензурирования некоторых блоков или экстракции MEV. Механизм, который используется для обновления блоков по этапам, также довольно сложный и несколько раз исправлялся для закрытия уязвимостей. Это делает его той частью кода Ethereum, где сопутствующих ошибок, вероятно, будет становиться только больше. Эти недостатки могут быть устранены, если время на завершение будет сокращено до одного слота.

Компромисс между децентрализацией, временем и расходами

Гарантия завершенности — это не мгновенно возникающее качество нового блока. Требуется время, чтобы новый блок был завершен. Причина в том, что валидаторы, представляющие по крайней мере 2/3 суммарно поставленных ETH в сети, должны голосовать за блок («подтверждать») по порядку, чтобы завершить его. Каждый узел валидатора в сети должен обработать подтверждения от других узлов по порядку, чтобы узнать, достиг блок или нет порога в 2/3.

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

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

Текущий механизм консенсуса Ethereum балансирует эти три параметра следующим образом:

Минимальная доля составляет 32 ETH. Это устанавливает верхний предел на количество подтверждений от валидаторов, которые будут обрабатываться индивидуальными узлами, и, соответственно, предел на требования к вычислительным мощностям каждого узла.
Время на завершение составляет около 15 минут. Это дает достаточно времени валидаторам, обслуживающим узлы на обычных домашних компьютерах, безопасно обрабатывать подтверждения для каждого блока.

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

Пути к завершенности одного слота

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

Этот процесс обеспечивает достаточную пропускную способность, чтобы каждый валидатор мог голосовать в каждой эпохе, потому что 32 слота 64 комитета 256 валидаторов в комитете = 524 288 валидаторов на эпоху. На момент написания (февраль 2023 г.) всего есть ~513 000 активных валидаторов.

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

С тех пор, как был разработан механизм консенсуса Ethereum, схема агрегации подписей (BLS) была признана более масштабируемой, чем предполагалось изначально. Возможности клиентов по обработке и верификации подписей также были расширены. Это приводит к тому, что обработка подтверждений от огромного количества валидаторов реально возможна в одном слоте. Например, если один миллион валидаторов голосует дважды в каждом слоте, а время слота установлено на 16 секунд, узлам потребуется верифицировать подписи со скоростью как минимум 125 000 агрегаций в секунду, чтобы обработать весь миллион подтверждений в рамках слота. В реальности обычному компьютеру нужно около 500 наносекунд, чтобы произвести одну верификацию подписи. Следовательно, 125 000 могут быть выполнены примерно за 62,5 мс, что сильно меньше порога в одну секунду.

Дальнейший прирост эффективности может быть достигнут за счет создания суперкомитетов, например состоящих из 125 000 случайно выбранных валидаторов на слот. Только эти валидаторы должны голосовать за блок, и потому только этот набор валидаторов решает, будет ли блок завершен. Хороша эта идея или нет, зависит от того, насколько дорогой по мнению сообщества Ethereum должна быть успешная атака на сеть. Все потому, что вместо требуемых 2/3 от всего эфира в стейкинге атакующий мог бы завершить нечестный блок с 2/3 поставленного эфира в своем суперкомитете. Это все еще активная область для исследований, но решение кажется приемлемым, ведь для такого огромного количества валидаторов, находящихся в суперкомитете, атака будет стоить слишком дорого (например, в пересчете на ETH стоимость атаки составит 2/3 * 125 000 * 32 = ~2,6 миллиона ETH). Увеличивая количество валидаторов в наборе, можно регулировать стоимость атаки (например, задать такое количество валидаторов, чтобы атака стоила 1, 4, 10 миллионов эфиров и так далее). Предвраительные опросы(opens in a new tab) сообщества показывают, что 1–2 миллиона эфиров считаются приемлемой стоимостью атаки, что означает примерно от 65 536 до 97 152 валидаторов на суперкомитет.

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

Какова роль у правила выбора ответвления в SSF?

Сегодня механизм консенсуса зависит от тесного сопряжения между устройством завершенности (алгоритм, который определяет, подтвердили ли 2/3 валидаторов определенную цепочку) и правилом выбора ответвления (алгоритм, который решает, какая цепочка верна, когда есть несколько вариантов на выбор). Алгоритм выбора ответвления учитывает только блоки после последнего завершенного блока. При применении SSF правилу выбора ответвления будет не из чего выбирать, потому что завершение происходит в том же слоте, где был предложен блок. Это значит, что при SSF в любой момент будет активен или алгоритм выбора ответвления, или устройство завершения. Устройство завершения будет заверщать блоки, когда 2/3 валидаторов будут онлайн и честно выполнят подтверждение. Если блок не сможет преодолеть порог в 2/3, правило выбора ответвления сработает, чтобы определить, какой цепочке следовать. Это также создает возможность поддерживать механизм утечки неактивности, который восстанавливает сеть, когда более 1/3 валидаторов уходят в офлайн, хотя и с некоторыми дополнительными нюансами.

Нерешенные вопросы

Проблема масштабирования агрегации за счет увеличения количества валидаторов в подсети заключается в том, что при этом увеличивается нагрузка на одноранговую сеть. Проблема с добавлением уровней агрегации в том, что это сложно реализуется в инженерном плане и добавляет задержку (то есть требуется больше времени, чтобы предлагающий блок мог получить данные от всех агрегаторов подсетей). Также непонятно, как справиться с ситуацией, когда активных валидаторов доступно больше, чем сеть может обработать в каждом слоте даже при наличии агрегации подписей BLS. Одно из потенциальных решений: поскольку все валидаторы участвуют в подтверждении в каждом слоте и нет комитетов, а при SSF нет комитетов, ограничение эффективного баланса в 32 ETH может быть полностью снято, позволяя операторам, управляющим несколькими валидаторами, объединять их стейк и запускать меньше узлов, снижая количество сообщений, которые узлы валидаторов должны обработать и учесть во всем наборе валидаторов. Это потребует от крупных дольщиков согласия объединить свои валидаторы. Также возможно установить фиксированный лимит на количество валидаторов и сумму ETH в стейкинге в каждый момент времени. Тем не менее, это требует создания механизма, который будет решать, какие валидаторы могут быть допущены к участию, а какие — нет, что может привести к нежелательным побочным эффектам.

Текущий прогресс

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