Финализация блока Эфириума занимает около 15 минут. Однако мы можем сделать так, чтобы механизм консенсуса Эфириума проверял блоки более эффективно и значительно сократил время до финальности. Вместо того чтобы ждать 15 минут, блоки могли бы предлагаться и финализироваться в одном и том же слоте. Эта концепция известна как однослотовая финализация (SSF).
Что такое финальность?
В механизме консенсуса Эфириума на основе доказательства доли владения (PoS) финальность означает гарантию того, что блок не может быть изменен или удален из блокчейна без сжигания как минимум 33% от общего количества застейканных ETH. Это «криптоэкономическая» безопасность, поскольку уверенность исходит из чрезвычайно высокой стоимости, связанной с изменением порядка или содержимого цепи, что предотвратило бы попытки любого рационального экономического субъекта сделать это.
Зачем стремиться к более быстрой финальности?
Текущее время до финальности оказалось слишком долгим. Большинство пользователей не хотят ждать финальности 15 минут, и для приложений и бирж, которым может потребоваться высокая пропускная способность транзакций, неудобно ждать так долго, чтобы быть уверенными в необратимости своих транзакций. Наличие задержки между предложением блока и его финализацией также создает возможность для коротких реорганизаций, которые злоумышленник может использовать для цензуры определенных блоков или извлечения MEV. Механизм, который занимается поэтапным обновлением блоков, также довольно сложен и несколько раз исправлялся для закрытия уязвимостей в безопасности, что делает его одной из частей кодовой базы Эфириума, где с большей вероятностью могут возникнуть трудноуловимые ошибки. Все эти проблемы можно было бы устранить, сократив время до финальности до одного слота.
Компромисс между децентрализацией, временем и накладными расходами
Гарантия финальности не является немедленным свойством нового блока; для финализации нового блока требуется время. Причина этого заключается в том, что валидаторы, представляющие не менее 2/3 от общего количества застейканных ETH в сети, должны проголосовать за блок («аттестовать»), чтобы он считался финализированным. Каждый проверяющий узел в сети должен обрабатывать аттестации от других узлов, чтобы знать, достиг ли блок порога в 2/3 или нет.
Чем меньше времени отводится на достижение финализации, тем больше вычислительной мощности требуется на каждом узле, поскольку обработка аттестаций должна выполняться быстрее. Кроме того, чем больше проверяющих узлов существует в сети, тем больше аттестаций необходимо обработать для каждого блока, что также увеличивает требуемую вычислительную мощность. Чем больше требуется вычислительной мощности, тем меньше людей могут участвовать, поскольку для запуска каждого проверяющего узла требуется более дорогое оборудование. Увеличение времени между блоками снижает вычислительную мощность, требуемую на каждом узле, но также увеличивает время до финальности, поскольку аттестации обрабатываются медленнее.
Таким образом, существует компромисс между накладными расходами (вычислительной мощностью), децентрализацией (количеством узлов, которые могут участвовать в проверке цепи) и временем до финальности. Идеальная система балансирует между минимальной вычислительной мощностью, максимальной децентрализацией и минимальным временем до финальности.
Текущий механизм консенсуса Эфириума сбалансировал эти три параметра следующим образом:
- Установка минимального стейка в 32 ETH. Это устанавливает верхний предел количества аттестаций валидаторов, которые должны обрабатываться отдельными узлами, и, следовательно, верхний предел вычислительных требований для каждого узла.
- Установка времени до финальности на уровне ~15 минут. Это дает достаточно времени валидаторам, работающим на обычных домашних компьютерах, для безопасной обработки аттестаций для каждого блока.
При текущей конструкции механизма для сокращения времени до финальности необходимо уменьшить количество валидаторов в сети или увеличить требования к оборудованию для каждого узла. Однако существуют улучшения, которые можно внести в способ обработки аттестаций, что позволит учитывать больше аттестаций без увеличения накладных расходов на каждом узле. Более эффективная обработка позволит определять финальность в пределах одного слота, а не двух эпох.
Пути к SSF
Текущий механизм консенсуса объединяет аттестации от нескольких валидаторов, известных как комитеты, чтобы уменьшить количество сообщений, которые каждый валидатор должен обработать для проверки блока. Каждый валидатор имеет возможность аттестовать в каждой эпохе (32 слота), но в каждом слоте аттестует только подмножество валидаторов, известное как «комитет». Они делают это путем разделения на подсети, в которых несколько валидаторов выбираются в качестве «агрегаторов». Каждый из этих агрегаторов объединяет все подписи, которые они видят от других валидаторов в своей подсети, в одну агрегированную подпись. Агрегатор, который включает наибольшее количество индивидуальных вкладов, передает свою агрегированную подпись предлагающему блок, который включает ее в блок вместе с агрегированной подписью от других комитетов.
Этот процесс обеспечивает достаточную пропускную способность для того, чтобы каждый валидатор мог голосовать в каждой эпохе, поскольку 32 slots * 64 committees * 256 validators per committee = 524,288 validators per epoch. На момент написания статьи (февраль 2023 года) насчитывается ~513 000 активных валидаторов.
В этой схеме каждый валидатор может проголосовать за блок только путем распределения своих аттестаций по всей эпохе. Однако потенциально существуют способы улучшить механизм так, чтобы каждый валидатор имел возможность аттестовать в каждом слоте.
С момента разработки механизма консенсуса Эфириума схема агрегации подписей (BLS) оказалась гораздо более масштабируемой, чем предполагалось изначально, в то время как способность клиентов обрабатывать и проверять подписи также улучшилась. Оказывается, обработка аттестаций от огромного количества валидаторов действительно возможна в рамках одного слота. Например, если один миллион валидаторов голосует дважды в каждом слоте, а время слота скорректировано до 16 секунд, узлам потребуется проверять подписи с минимальной скоростью 125 000 агрегаций в секунду, чтобы обработать все 1 миллион аттестаций в течение слота. В реальности обычному компьютеру требуется около 500 наносекунд для выполнения одной проверки подписи, что означает, что 125 000 проверок могут быть выполнены за ~62,5 мс — что намного ниже порога в одну секунду.
Дальнейшее повышение эффективности может быть достигнуто путем создания суперкомитетов, например, из 125 000 случайно выбранных валидаторов на слот. Только эти валидаторы получают право голосовать за блок, и поэтому только это подмножество валидаторов решает, финализирован ли блок. Хорошая ли это идея или нет, сводится к тому, насколько дорогой сообщество предпочло бы видеть успешную атаку на Эфириум. Это связано с тем, что вместо того, чтобы требовать 2/3 от общего количества застейканного эфира, злоумышленник мог бы финализировать нечестный блок с 2/3 застейканного эфира в этом суперкомитете. Это все еще активная область исследований, но кажется правдоподобным, что для набора валидаторов, достаточно большого, чтобы вообще требовать суперкомитетов, стоимость атаки на один из этих подкомитетов будет чрезвычайно высокой (например, стоимость атаки, номинированная в ETH, составит 2/3 * 125,000 * 32 = ~2.6 million 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 находится на стадии исследования. Ожидается, что он не будет выпущен в течение нескольких лет, вероятно, после других существенных обновлений, таких как деревья Веркла и данкшардинг.