В мае кластер Protocol приветствовал трех новых координаторов и пообещал поделиться новостями.
Спустя месяцы адаптации и согласования усилий с контрибьюторами по всему кластеру, в составе EF и во всей экосистеме Ethereum, мы рады представить приоритеты Protocol: цели Protocol, обязательства, определяющие его работу до 2029 года, и то, чего эти обязательства требуют от хардфорков, попадающих в текущую сферу рассмотрения.
По мере приближения Glamsterdam к мейннету кластер Protocol вступил в сезон формирования состава хардфорка Hegotá. Мы использовали процесс, описанный в публикации от 28 августа: 62 предложенных для включения EIP, несколько ретроспектив по Glamsterdam, 16 шаблонов для контрибьюторов и несколько общекластерных рабочих сессий. Этот процесс помог примерно 60 исследователям и инженерам определить общий набор приоритетов. Эти приоритеты охватывают долгосрочную дорожную карту и сфокусированы через критический путь. Этот путь начинается с того, как мы определяем состав Hegotá.
В этой публикации изложен этот общий набор общекластерных приоритетов. Оценку каждого кандидата в Hegotá вы можете найти в сопутствующем материале: EF Protocol: The Hegotá EIP Opinion Post and Tier List.
I. Полярная звезда
Кластер EF Protocol ставит своей целью достижение квантовой устойчивости Ethereum L1 на всех трех уровнях (исполнения, консенсуса и данных) к декабрю 2029 года. Эта дата совпадает с целевыми сроками миграции на постквантовую криптографию, независимо установленными компаниями Google, Cloudflare и Microsoft. Оценки наступления дня Q будут уточняться по мере приближения этой даты. Сроки его наступления не зависят ни от кого, и именно поэтому мы установили конкретную цель, а не стали ждать полной определенности. На данный момент Ethereum L1 должен планировать наступление дня Q уже в 2030 году. Планирование дня Q на 2030 год является намеренно агрессивным допущением. Большинство заслуживающих доверия оценок относят день Q на более поздний срок, некоторые — значительно позже, а возможно, мы с ним вообще никогда не столкнемся.
Раннее обеспечение постквантовой готовности — это безопасный шаг. Это стратегически ответственный шаг. Это самый четкий сигнал, который мы можем послать: Ethereum намерен существовать через 50, 100 и 1000 лет. Инстинкт Ethereum, и вполне обоснованный, заключается в том, чтобы с осторожностью относиться к ставкам «ва-банк», и мы разделяем этот подход. Однако здесь мы делаем такую ставку осознанно. День Q нельзя назначить на определенную дату, поэтому мы установили для себя жесткий внутренний дедлайн.
Кластер EF Protocol будет относиться к этому внутреннему дедлайну как к не подлежащему обсуждению по крайней мере до января 2027 года, когда прогресс в области квантовых вычислений будет переоценен при участии внешних экспертов.
II. План
Два возможных темпа до декабря 2029 года. Команды разработчиков клиентов могут реалистично начать внедрение Hegotá в конце Q4 2026 года. Согласно июльскому плану Strawmap, полная постквантовая готовность находится в L*, через пять хардфорков после Glamsterdam. Выпуск Glamsterdam в декабре 2026 года и L* в декабре 2029 года требует среднего темпа в 7,2 месяца на один хардфорк. Этот график весьма агрессивен и оставляет мало пространства для ошибок, если реализация какого-то форка займет больше времени, чем предполагалось за год до репорта.
Обновление плана Strawmap от 19 августа добавило этап минимально жизнеспособного постквантового (MV-PQ) уровня L1 на этапе J*. Реестр постквантовых публичных ключей находится в I*. Постквантовый пульс (heartbeat) на уровне консенсуса, сэмплирование leanDA на уровне данных и транзакции leanSPHINCS на уровне исполнения находятся в J*. 12-месячный цикл обновлений, начиная с Glamsterdam, позволяет достичь этого промежуточного этапа к декабрю 2029 года.
MV-PQ — это временная мера защиты. MV-PQ разработан для поддержания работы Ethereum в день Q с пониженными гарантиями. Исследователи все еще уточняют, как именно будет выглядеть это снижение гарантий. Полная устойчивость на уровнях исполнения, консенсуса и данных остается целью на декабрь 2029 года. Оставшаяся работа включает постквантовые аттестации, необходимые для полной экономической финализации при завершении проектирования консенсуса.
Гибкий порядок хардфорков после J*. В Strawmap можно поменять местами K* и L*, перенеся легкий консенсус (lean consensus) на один форк раньше, а обязательные доказательства исполнения — на один форк позже. Достижение полной постквантовой готовности в K* к декабрю 2029 года предполагает 9-месячный цикл. Мы планируем Hegotá, I* и J* как единую последовательность релизов, при этом окончательный порядок будет утвержден только по мере созревания исследований и лучшего понимания возможностей клиентских команд.
Параллельная разработка в масштабах экосистемы. Темпы, которых требуют эти этапы, потребуют невероятного уровня командной работы как внутри Protocol, так и за его пределами. Хардфорки будут пересекаться: внедрение Hegotá будет происходить одновременно с созреванием спецификаций I* и проведением исследований для J*–L* с целью создания тестируемых компонентов. Простой выпуск форков в линейной последовательности не позволит уложиться в график до декабря 2029 года. Для этого потребуется более тесная коммуникация внутри кластера, а также привлечение клиентских команд, получателей грантов, академического сообщества и более широкого круга участников, чтобы конвейер от исследований до мейннета ускорялся с каждым форком.
Достижение постквантовой готовности также потребует больше ресурсов, чем любая предыдущая последовательность хардфорков, включая криптографов, разработчиков клиентов, исследователей, специалистов по проверке безопасности и тестированию как внутри EF, так и далеко за ее пределами. Это будет общеэкосистемное усилие.
III. Пять многофорковых исследовательских направлений
Одновременная работа над несколькими хардфорками позволяет кластеру Protocol выполнять всю взаимосвязанную работу — как краткосрочную, так и долгосрочную, помимо немедленного стремления к достижению минимально жизнеспособного постквантового уровня. Эти усилия организованы вокруг пяти многофорковых исследовательских направлений: быстрая финализация, постквантовая криптография, конфиденциальность, состояние (state) и zkEVM.
Быстрая финализация
Быстрая финализация сокращает время финализации Ethereum с минут до секунд. Текущее направление проектирования отделяет финализацию от производства блоков и перестраивает уровень консенсуса вокруг доступной цепи и гаджета финализации. Ведется разработка спецификаций и прототипов, нацеленная на I*, где разделенный консенсус является главным кандидатом.
Постквантовая криптография
Постквантовое направление (как описано в разделе II «План» выше) реализует обязательство на декабрь 2029 года и охватывает все три уровня: консенсуса, данных и исполнения. Криптографическая гибкость критически важна для уровня исполнения, где нативная абстракция учетных записей позволяет менять схемы подписей без хардфорка для каждой схемы. Фреймворк Frames обеспечивает это свойство благодаря своему подходу к нативной абстракции учетных записей. Однако уровень консенсуса не может полагаться на криптографическую гибкость; его криптография и схемы агрегации могут изменяться только посредством хардфорка. В результате криптография консенсуса обрабатывается противоположным образом. Она проходит боевые испытания и закаляется перед развертыванием, а компоненты консенсуса ждут полной постквантовой архитектуры вместо выпуска по одному элементу за раз.
Конфиденциальность
Направление конфиденциальности работает над обеспечением конфиденциальности на уровне протокола, чтобы пользователи могли совершать транзакции, хранить балансы и взаимодействовать с приложениями без раскрытия своей финансовой истории или необходимости доверять третьим сторонам. Мы считаем, что эту работу следует начать в Hegota для реализации нативных, не требующих доверия и устойчивых к цензуре конфиденциальных транзакций в Ethereum L1. Дальнейшая работа сосредоточена на постквантовой конфиденциальности в масштабном исполнении и зашифрованных мемпулах, которые скрывают содержимое транзакций до их включения в блок.
Состояние
Направление state arc предотвращает превращение роста состояний и доступа к ним в лимитирующий фактор Ethereum. Его работа включает миграцию на новое дерево (trie), устойчивый рост состояния и децентрализованный доступ к текущему и историческому состояниям. Основной объем работ по проектированию и миграции, как ожидается, начнется в I* и продолжится после него.
zkEVM
Направление zkEVM переводит доказательства выполнения (execution proofs) из статуса доступных и опциональных в статус ожидаемых, а затем — обязательных. В конечном итоге валидаторы проверяют сжатое доказательство и прекращают повторное выполнение каждого блока. Согласно текущему порядку в Strawmap, обязательные доказательства появляются в K*. На рассмотрении находится один вариант изменения порядка: поменять местами вехи аттестаций PQ и обязательных доказательств. PQ-аттестации будут перенесены из L* в K*, а обязательные доказательства — из K* в L*, в то время как остальная часть каждого форка останется на прежнем месте. Если это произойдет, обязательные доказательства появятся на один форк позже, зато самый крупный оставшийся элемент консенсуса PQ — на один форк раньше. В любом случае, стремление внедрить L1 zkEVM также стимулирует развитие инструментов формальной верификации, рабочих процессов и верифицированных криптографических компонентов, от которых выигрывают и другие направления, особенно в постквантовой сфере.
IV. Как мы определяем приоритеты и выпускаем обновления
Наша задача, впервые опубликованная в июльском общепротокольном обновлении, остается неизменной:
«Сосредоточить Protocol на том, что может и должен делать только Protocol, и завершить пункты Strawmap, которые позволяют Ethereum выполнять Мандат».
Завершение обновления в Глазго-Амстердаме (Glamsterdam) и обязательства на декабрь 2029 года переводят постквантовую работу из разряда долгосрочных исследований в статус задач для ближайшего форка. Лестница приоритетов после Glamsterdam фиксирует это изменение и позиционирует формальную верификацию в качестве общего инструментария для всех оставшихся исследовательских направлений.
Лестница определяет приоритеты; конвейер зрелости (maturity pipeline) определяет, как работа заслуживает включения в план:
Исследования → EIP → Прототип → Devnet → PFI → CFI → SFI → Mainnet
Каждый шаг должен привносить доказательства, уменьшать неопределенность и делать зоны ответственности видимыми до принятия следующих обязательств. Сеть devnet может вернуть задачу обратно на этап исследований. PFI, CFI и SFI сигнализируют о растущей уверенности среди AllCoreDevs; они не заменяют доказательства реализации. Большая часть того, что Protocol уникальным образом способен сделать, заключается в продвижении идей по всему этому конвейеру.
V. Следующий форк как первое испытание
Этот раздел посвящен конкретно форку Hegotá — взгляду Protocol на форк, объем которого сейчас определяется. В сопутствующей публикации «EF Protocol: The Hegotá EIP Opinion Post and Tier List» подробно описано, как кластер Protocol оценивает каждый EIP, с конкретным объяснением для каждого из них. В этом разделе мы рассматриваем приоритеты, обязательства и границы масштаба, которые сформировали эти оценки.
Hegotá — это не постквантовый форк; это форк, который решает, состоятся ли постквантовые форки вовремя. Его главными пунктами со статусом SFI являются EIP-7805 (списки включения, принудительно применяемые выбором форка, — FOCIL) на уровне консенсуса и EIP-8141 (фреймовая транзакция — Frame Transaction) на уровне выполнения. Они должны быть внедрены безопасно и одновременно, а взаимодействие между включением транзакций и новой моделью транзакций должно быть протестировано в рамках основной инженерной работы над форком.
Интерес к дополнительным задачам на уровне консенсуса невелик. FOCIL — это центральный элемент Hegotá на уровне консенсуса. Наш интерес к чему-либо еще стремится к нулю, если только новое дополнение напрямую не поддерживает постквантовую готовность. Каждый дополнительный элемент уровня консенсуса задействует тех же исследователей и разработчиков клиентов, которые необходимы для спецификации и создания прототипа разделенного консенсуса, а также для подготовки I* и J* после завершения их реализации в Hegotá.
Сохранение CROPS в целом
Мандат определяет работу Protocol через концепцию CROPS: устойчивость к цензуре (Censorship Resistance — CR), открытый исходный код и свобода как таковая (Open Source and Free, as in Freedom — O), конфиденциальность (Privacy — P) и безопасность (Security — S). Эти свойства составляют единый набор гарантий протокола. Разработка с открытым исходным кодом и открытое участие являются базовыми требованиями для каждого форка. В Hegotá берутся конкретные обязательства по остальным трем пунктам.
Устойчивость к цензуре (CR)
Цель FOCIL заключается в улучшении гарантий включения транзакций в Ethereum за счет того, что несколько валидаторов могут налагать ограничения на блоки строителей. Они делают это, определяя набор транзакций, которые должны быть включены с помощью IL (списков включения), чтобы блок считался валидным с точки зрения аттестаторов. EIP-8369 (Профили VOPS для соответствия требованиям FOCIL) определяет, какие транзакции имеют право на включение и что должны проверять валидаторы, чтобы гарантии FOCIL могли распространяться на будущие типы транзакций. Вместе они представляют собой прямые обязательства Hegotá по защите от цензуры и захвата сети.
Конфиденциальность (P)
В Ethereum все еще отсутствует некоторая базовая поддержка протокола, необходимая для приложений с повышенной конфиденциальностью. EIP-8250 (Ключевые нонсы — Keyed Nonces) позволяет многим пользователям использовать одного и того же отправителя для обеспечения лучшей анонимности, предоставляя их транзакциям раздельные нонсы, чтобы они не блокировали друг друга. EIP-8272 (Недавние корни — Recent Roots) позволяет конфиденциальным транзакциям использовать недавнее состояние в цепочке в формате, который FOCIL может проверить, благодаря чему они могут выиграть от гарантий включения. Вместе они устраняют два главных препятствия на пути к не требующей доверия и устойчивой к цензуре конфиденциальной деятельности в L1 и должны быть выпущены вместе с Frames.
Безопасность (S)
Фреймовые транзакции (Frame transactions) делают проверку, выполнение транзакций и оплату газа программируемыми на уровне протокола. Это дает аккаунтам нативный путь ухода от уязвимых ключей secp256k1, поддерживает агрегацию подписей и позволяет внедрять новые схемы подписей без необходимости проведения хардфорка для каждой из них. Это также сохраняет проверку аккаунтов и оплату комиссий не требующими разрешений (permissionless). Ключевые нонсы и недавние корни завершают создание основы Frames, необходимой для Hegotá.
EIP-8365 (Вывод из обращения учетных данных на вывод средств BLS) запускает процесс вывода из обращения учетных данных на вывод средств, которые остаются привязанными к уязвимой криптографии. Эту работу можно начать прямо сейчас, не дожидаясь завершения полного дизайна постквантового консенсуса.
Пакет расширений Frames напрямую укрепляет безопасность аккаунтов. EIP-7906 (Утверждения транзакций через опкод разницы состояний — Transaction Assertions via State Diff Opcode) позволяет транзакциям проверять указанные эффекты перед фиксацией, защищая от атак вроде опустошения кошельков (drainers); EIP-8298 (Инструкция повторного использования кода SETCODEFROM) позволяет делегированным аккаунтам становиться полноценными аккаунтами смарт-контрактов; а EIP-8151 (Ограниченный код аккаунта ecRecover) блокирует аутентификацию по устаревшим ключам после того, как аккаунт получает настоящий код. Последние два формируют путь аккаунтов к отказу от secp256k1 в качестве мастер-ключа.
Ограничивающая пара рассматривает наихудший сценарий формирования блока как задачу безопасности: EIP-8279 (Нижний предел байтов списка доступа блока — Block Access List Byte Floor) и EIP-8131 (Нижний предел содержимого унифицированной транзакции — Unified Transaction Content Floor) устанавливают предсказуемый минимальный уровень газа для враждебного содержимого блока. Любое дальнейшее использование образовавшегося резерва пространства является отдельным решением по определению масштаба.
Безопасная доставка FOCIL и Frames, а также тестирование взаимодействия между ними — это основное инженерное обязательство Hegotá. Любое дополнительное дополнение конкурирует за этот объем тестирования и должно соответствовать критерию необходимости.
VI. Чего ожидать
В сопутствующем посте публикуются список приоритетов (tier list) кластера Protocol для Hegotá и объяснение каждой оценки. Если вы хотите прочитать что-то одно помимо этой публикации, прочтите сопутствующий пост.
Наконец, мы ждем ваших вопросов. Мы проведем AMA-сессию на Reddit в сабреддите r/ethereum 16 сентября в 14:00 по всемирному координированному времени (UTC), чтобы обсудить эти приоритеты, тир-лист Hegotá и любые другие волнующие вас вопросы. Отправляйте вопросы заранее, используя форму здесь. Чем острее вопрос, тем интереснее получится обсуждение.
