Виталик: Какие аспекты PoS в Ethereum еще можно улучшить и какими способами?

В этой статье основное внимание уделяется вопросу «слияния» Ethereum: какие аспекты технического дизайна proof-of-stake еще можно улучшить и какими способами можно реализовать эти улучшения?

Автор:Vitalik Buterin

Перевод: Deng Tong, Jinse Finance

Особая благодарность Justin Drake, Hsiao-wei Wang, @antonttc и Francesco за отзывы и рецензирование.

Изначально «слияние» означало самое важное событие в истории протокола Ethereum с момента его запуска: долгожданный и труднодостижимый переход от proof-of-work к proof-of-stake. Сегодня Ethereum уже почти два года стабильно работает как система proof-of-stake, которая показывает отличные результаты по стабильности, производительности и снижению рисков централизации. Тем не менее, в proof-of-stake все еще есть важные области для улучшения.

В моем роадмапе 2023 года это делится на несколько частей: улучшение технических характеристик, таких как стабильность, производительность и доступность для небольших валидаторов, а также экономические изменения для противодействия рискам централизации. Первая часть получила название «слияние», а вторая стала частью «scourge».

В этой статье основное внимание уделяется части «слияния»: какие аспекты технического дизайна proof-of-stake еще можно улучшить и какими способами можно реализовать эти улучшения?

Это не исчерпывающий список возможных улучшений proof-of-stake; скорее, это перечень идей, которые активно рассматриваются.

Финализация за один слот и демократизация стейкинга

Какую проблему мы решаем?

Сегодня для финализации блока требуется 2-3 эпохи (около 15 минут), а чтобы стать стейкером, нужно 32 ETH. Изначально это было компромиссным решением между тремя целями:

• Максимизация числа валидаторов, которые могут участвовать в стейкинге (что напрямую означает минимизацию минимального необходимого ETH для стейкинга)
• Минимизация времени финализации
• Минимизация издержек на запуск ноды

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

Обратите внимание, что все это зависит от одной ключевой цели Ethereum: обеспечить, чтобы даже успешная атака была очень дорогой для атакующего. Именно это и означает термин «экономическая финализация». Если бы у нас не было этой цели, мы могли бы финализировать каждый слот, случайным образом выбирая комитет (например, как это делает Algorand). Но проблема такого подхода в том, что если атакующий действительно контролирует 51% валидаторов, он может атаковать с очень низкими издержками (отменять финализированные блоки, осуществлять цензуру или задерживать финализацию): только часть нод в комитете может быть обнаружена как участвующая в атаке и наказана, будь то через slashing или minority soft fork. Это означает, что атакующий может многократно атаковать цепь. Поэтому, если мы хотим экономической финализации, то простые методы на основе комитетов не подходят, и на первый взгляд нам действительно нужно участие всех валидаторов.

В идеале мы хотим сохранить экономическую финализацию, одновременно улучшив ситуацию по двум направлениям:

• Финализировать блок за один слот (в идеале сохраняя или даже уменьшая текущую длину в 12 секунд), а не за 15 минут
• Позволить валидаторам стейкать с 1 ETH (снизить порог с 32 ETH до 1 ETH)

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

Во-первых, это обеспечивает всем пользователям Ethereum более высокий уровень безопасности, достигаемый механизмом финализации. Сегодня большинство пользователей не могут воспользоваться этим преимуществом, потому что не хотят ждать 15 минут; а с финализацией за один слот пользователь практически сразу после подтверждения транзакции видит ее финализацию. Во-вторых, если пользователям и приложениям не нужно беспокоиться о возможности отката цепи (за исключением относительно редких случаев inactivity leak), это упрощает протокол и сопутствующую инфраструктуру.

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

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

Что это такое и как это работает?

Финализация за один слот предполагает использование алгоритма консенсуса, который финализирует блок в одном слоте. Это само по себе несложно реализовать: многие алгоритмы (например, Tendermint consensus) уже реализуют это с отличными свойствами. Уникальное для Ethereum свойство — inactivity leak, которого нет у Tendermint: даже если более 1/3 валидаторов оффлайн, цепь может продолжать работать и в итоге восстановиться. К счастью, это желание уже реализовано: есть предложения по модификации Tendermint-подобного консенсуса для поддержки inactivity leak.

Ведущие предложения по финализации за один слот

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

Вариант 1: Брутфорс — попытаться реализовать более эффективные протоколы агрегации подписей, возможно с использованием ZK-SNARKs, что позволит обрабатывать подписи миллионов валидаторов в каждом слоте.

Horn — один из дизайнов, предложенных для лучшей агрегации подписей.

Вариант 2: Orbit Committee — новый механизм, позволяющий случайно выбранному среднему комитету отвечать за финализацию цепи, но при этом сохраняющий желаемые свойства стоимости атаки.

Один из способов думать об Orbit SSF — это то, что он открывает пространство компромиссов от x=0 (комитет по типу Algorand, без экономической финализации) до x=1 (текущее состояние Ethereum), создавая промежуточные точки, где Ethereum по-прежнему обладает достаточной экономической финализацией для высокой безопасности, но при этом мы получаем преимущество эффективности за счет участия только случайной средней выборки валидаторов в каждом слоте.

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

Вариант 3: Двухуровневый стейкинг — механизм, при котором стейкеры делятся на два класса: с более высоким и более низким депозитом. Только класс с более высоким депозитом непосредственно участвует в обеспечении экономической финализации. Относительно прав и обязанностей класса с меньшим депозитом есть различные предложения (например, см. посты о Rainbow staking). Распространенные идеи включают:

• Право делегировать stake более высокому уровню
• Случайно выбранные стейкеры низшего уровня подтверждают и должны завершать каждый блок
• Право формировать список включения

Какие есть ссылки на существующие исследования?

• Пути к финализации за один слот (2022):
• Конкретные предложения по протоколу финализации за один слот для Ethereum (2023):
• Orbit SSF:
• Дальнейший анализ механизмов в стиле Orbit:
• Horn, протокол агрегации подписей (2022):
• Агрегация подписей для масштабного консенсуса (2023):
• Протокол агрегации подписей от Khovratovich и др.:
• Агрегация подписей на основе STARK (2022):
• Rainbow staking:

Что еще предстоит сделать? Какие компромиссы?

Есть четыре основных возможных пути (также возможны гибридные варианты):

• Сохранить статус-кво
• Orbit SSF
• Брутфорс SSF
• SSF с двухуровневым стейкингом

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

(2) избегает «высоких технологий» и решает проблему путем переосмысления протокольных допущений: мы смягчаем требование «экономической финализации» так, чтобы стоимость атаки оставалась высокой, но допускаем, что она может быть в 10 раз ниже, чем сейчас (например, стоимость атаки 2.5 миллиардов долларов вместо 25 миллиардов долларов). Считается, что экономическая финализация Ethereum сегодня намного превышает необходимый уровень, а основные риски безопасности лежат в других областях, поэтому это можно считать приемлемой жертвой.

Основная работа — убедиться, что механизм Orbit безопасен и обладает нужными свойствами, затем полностью формализовать и реализовать его. Кроме того, EIP-7251 (увеличение максимального эффективного баланса) позволяет добровольное объединение балансов валидаторов, что сразу снижает издержки на валидацию цепи и служит эффективной начальной фазой для внедрения Orbit.

(3) избегает переосмысления и решает проблему с помощью высоких технологий. Для этого нужно собрать огромное количество подписей (более 1 миллиона) за очень короткое время (5-10 секунд).

(4) избегает и переосмысления, и высоких технологий, но создает двухуровневую систему стейкинга, которая все равно несет риски централизации. Риски во многом зависят от конкретных прав, предоставляемых низшему уровню. Например:

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

Можно комбинировать разные стратегии, например:

• (1 + 2): добавить Orbit без реализации финализации за один слот.
• (1 + 3): использовать брутфорс для снижения минимального депозита без финализации за один слот. Необходимая степень агрегации в 64 раза меньше, чем в чистом случае (3), поэтому задача упрощается.
• (2 + 3): реализовать Orbit SSF с консервативными параметрами (например, комитет из 128k валидаторов вместо 8k или 32k) и использовать брутфорс для повышения эффективности.
• (1 + 4): добавить Rainbow staking без финализации за один слот.

Как это взаимодействует с другими частями роадмапа?

Помимо других преимуществ, финализация за один слот снижает риск некоторых видов MEV-атак на несколько блоков. Кроме того, в мире с финализацией за один слот дизайн разделения prover-proposer и других внутренних протоколов производства блоков должен быть иным.

Слабое место брутфорс-стратегий — они затрудняют сокращение времени слота.

Выбор единственного секретного лидера

Какую проблему мы решаем?

Сегодня заранее известно, какой валидатор предложит следующий блок. Это создает уязвимость: атакующий может мониторить сеть, определять, какие валидаторы соответствуют каким IP-адресам, и запускать DoS-атаки на валидатора, когда тот должен предложить блок.

Что это? Как это работает?

Лучший способ решить проблему DoS — скрыть информацию о том, какой валидатор сгенерирует следующий блок, по крайней мере до момента его генерации. Обратите внимание, что если убрать требование «единственности», это легко: можно разрешить любому создавать следующий блок, но требовать, чтобы randao был меньше 2^256 / N. В среднем только один валидатор сможет это сделать — но иногда два и более, иногда ни одного. Совместить требования «секретности» и «единственности» долгое время было сложно.

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

Протокол Whisk SSLE

Какие есть ссылки на существующие исследования?

• Статья Dan Boneh (2020):
• Whisk (конкретное предложение для Ethereum, 2022):
• Тег единственного секретного выбора лидера на ethresear.ch:
• Упрощенный SSLE на основе кольцевых подписей:

Что еще предстоит сделать? Какие компромиссы?

Фактически осталось найти и реализовать достаточно простой протокол, чтобы его можно было легко внедрить в mainnet. Мы очень ценим относительную простоту протокола Ethereum и не хотим увеличивать сложность. Реализации SSLE, которые мы видели, добавляют сотни строк кода спецификации и вводят новые криптографические предположения. Найти достаточно эффективную квантово-устойчивую реализацию SSLE — тоже нерешенная задача.

Возможно, в итоге получится так, что только когда мы по другим причинам (например, state tree, ZK-EVM) внедрим универсальные zero-knowledge proof на L1 Ethereum, «маржинальная дополнительная сложность» SSLE станет достаточно низкой.

Другой вариант — вообще не внедрять SSLE, а решать проблему DoS с помощью внешних протокольных мер (например, на p2p-уровне).

Как это взаимодействует с другими частями роадмапа?

Если мы добавим механизм разделения prover-proposer (APS), например execution tickets, то execution-блоки (то есть блоки с транзакциями Ethereum) не будут нуждаться в SSLE, потому что можно полагаться на специализированных строителей блоков. Однако для блоков консенсуса (то есть блоков с протокольными сообщениями, например, доказательствами, частями списка включения и т.д.) мы все равно будем получать выгоду от SSLE.

Более быстрое подтверждение транзакций

Какую проблему мы решаем?

Сокращение времени подтверждения транзакций в Ethereum с 12 до 4 секунд было бы очень ценным. Это значительно улучшит пользовательский опыт L1 и rollup-решений, а также повысит эффективность defi-протоколов. Кроме того, это упростит децентрализацию L2, поскольку позволит большому количеству L2-приложений работать на rollup-базе, уменьшая потребность L2 в собственных децентрализованных механизмах сортировки на основе комитетов.

Что это? Как это работает?

Здесь есть две основные техники:

• Сокращение времени слота, например, до 8 или 4 секунд. Это не обязательно означает финализацию за 4 секунды: финализация по сути требует трех раундов коммуникации, поэтому можно сделать каждый раунд отдельным блоком, и через 4 секунды получить хотя бы предварительное подтверждение.
• Разрешить предложителю публиковать предварительные подтверждения в течение слота. В крайнем случае предложитель может в реальном времени включать транзакции в свой блок и сразу публиковать предварительные подтверждения для каждой транзакции («моя первая транзакция — 0×1234...», «моя вторая — 0×5678...»). Если предложитель публикует два конфликтующих подтверждения, это можно обработать двумя способами: (i) через slashing предложителя или (ii) с помощью голосования валидаторов, чтобы определить, какое подтверждение было раньше.

Какие есть ссылки на существующие исследования?

• На основе предварительных подтверждений:
• PEPC (protocol-enforced proposer commitments):
• Interleaved epochs на параллельных цепях (идея для низкой задержки, 2018):

Что еще предстоит сделать? Какие компромиссы?

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

Слабое место метода предварительных подтверждений — он может значительно улучшить среднее время включения, но не улучшает худший случай: если текущий предложитель работает хорошо, ваша транзакция получит предварительное подтверждение за 0.5 секунды вместо (в среднем) 6 секунд, но если предложитель оффлайн или работает плохо, все равно придется ждать все 12 секунд до следующего слота и нового предложителя.

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

С другой стороны, если мы не будем пытаться это реализовать и оставим финализацию на 12 секунд (или дольше), экосистема будет больше полагаться на механизмы предварительного подтверждения на L2, а взаимодействие между L2 будет занимать больше времени.

Как это взаимодействует с другими частями роадмапа?

Предварительные подтверждения на основе предложителя фактически зависят от механизма разделения prover-proposer (APS), например execution tickets. В противном случае давление на валидаторов для предоставления подтверждений в реальном времени может привести к излишней централизации.

Другие направления исследований

Восстановление после 51% атаки

Обычно считается, что если произойдет 51% атака (включая атаки, которые нельзя доказать криптографически, например цензуру), сообщество объединится и реализует minority soft fork, чтобы хорошие победили, а плохие были наказаны через inactivity leak или slashing. Однако такая чрезмерная зависимость от социального слоя может быть нездоровой. Мы можем попытаться уменьшить зависимость от социального слоя и сделать процесс восстановления максимально автоматизированным.

Полная автоматизация невозможна, потому что в этом случае это был бы консенсус-алгоритм с >50% толерантностью к ошибкам, а мы уже знаем строгие математические ограничения таких алгоритмов. Но можно реализовать частичную автоматизацию: например, если клиент видит, что транзакция цензурируется достаточно долго, он может автоматически отказаться принимать такую цепь как финализированную или даже как head для выбора форка. Ключевая цель — не дать атакующим быстро победить.

Увеличение порога кворума

Сегодня блок финализируется, если его поддерживают 67% стейкеров. Некоторые считают это слишком агрессивным. За всю историю Ethereum был только один (очень короткий) случай неудачной финализации. Если увеличить этот процент до 80%, число периодов без финализации вырастет незначительно, но Ethereum получит большую безопасность: в частности, многие спорные ситуации приведут к временному прекращению финализации. Это кажется более здоровым, чем мгновенная победа «неправильной стороны», будь то атакующие или баг в клиенте.

Это также отвечает на вопрос «в чем смысл индивидуального стейкинга». Сегодня большинство стейкеров уже стейкают через пулы, и маловероятно, что индивидуальные стейкеры когда-либо получат 51% ETH. Однако если постараться, достижение индивидуальными стейкерами блокирующего меньшинства, особенно если большинство — 80% (то есть блокирующее меньшинство — 21%), кажется достижимым. Пока индивидуальные стейкеры не участвуют в 51% атаке (будь то откат финализации или цензура), такая атака не приведет к «чистой победе», а индивидуальные стейкеры будут активно помогать организовать minority soft fork.

Квантовая устойчивость

Metaculus сейчас считает, что, несмотря на большую погрешность, квантовые компьютеры, вероятно, начнут взламывать криптографию в 2030-х годах:

Эксперты по квантовым вычислениям, такие как Scott Aaronson, недавно тоже стали серьезнее относиться к возможности появления реально работающих квантовых компьютеров в среднесрочной перспективе. Это влияет на весь роадмап Ethereum: это значит, что каждая часть протокола Ethereum, сегодня зависящая от эллиптических кривых, должна получить альтернативу на основе хэшей или других квантово-устойчивых методов. В частности, это значит, что нельзя рассчитывать на вечную возможность использовать BLS-агрегацию для обработки подписей от большого числа валидаторов. Это доказывает разумность консервативного подхода к производительности proof-of-stake и необходимость более активной разработки квантово-устойчивых альтернатив.