Ключ к трансформации Ethereum: будущее рекурсивных доказательств STARK в следующем десятилетии

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

Автор: _deanstef

Ethereum приближается к поворотному моменту.

Его первый десятилетний период подтвердил гипотезу: публичные блокчейны могут в значительной степени поддерживать значимые приложения. Умные контракты, DeFi, стейблкоины, appchains и токенизация превратили Ethereum из экспериментальной платформы децентрализованных вычислений в расчетный уровень растущей цифровой экономики.

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

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

• Противостоять угрозам, которые еще не существуют, особенно связанным с криптографией квантовым компьютерам (CRQC).
• Обеспечить достаточную конфиденциальность для удовлетворения требований реальной экономической деятельности к секретности.
• Достигнуть масштабируемости без отказа от нейтральности, открытости и устойчивости к цензуре, которые изначально сделали его успешным.

Миссия Фонда Ethereum недавно уточнила это видение через CROPS.

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

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

Стратегическая карта Ethereum описывает прогрессивный, многолетний путь эволюции к Lean Ethereum — системе, основанной на лаконичных криптографических доказательствах, которая расширяет сеть до 10K TPS и обновляется до постквантовых примитивов, не отказываясь от децентрализованного протокольного редизайна. Этот стек технологий в значительной степени строится вокруг STARK (Scalable Transparent Argument of Knowledge). STARK — это основанное на хэшах, прозрачное доказательство, которое не требует доверенной настройки; что важно, оно может быть агрегировано, позволяя свести множество различных вычислений в одно доказательство.

На этом пути я вижу три основных исследовательских столпа:

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

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

Безопасность после квантовых вычислений

Переход к постквантовому (PQ) Ethereum должен охватывать каждую уязвимую для квантовых атак часть существующего протокола. Как резюмируют дорожная карта Виталика и недавняя статья Nethermind о квантовых рисках, эти компоненты охватывают подписи ECDSA, доказательства консенсуса BLS, KZG-обещания для blob и SNARK на основе пар для расчетов на L1. Их объединяет сложность задачи дискретного логарифма на эллиптических кривых, которую алгоритм Шора может решить за полиномиальное время на CRQC.

Альтернативные кандидаты распределены по спектру:

• Подписные схемы на основе решеток (например, ML-DSA, Falcon) сохраняют подписи относительно небольшими, но стоимость верификации на цепи высока, превышая миллион Gas, и их теоретическая агрегация все еще не развита.
• Подписные схемы на основе хэшей полагаются только на безопасность базовой хэш-функции, но за счет объема: размер подписи достигает нескольких КБ, а стоимость верификации может достигать сотен тысяч Gas. Они делятся на состояния, такие как XMSS, которые имеют меньший объем, но требуют от подписанта отслеживания состояния ключа; и без состояния, такие как SPHINCS+, которые имеют больший объем и более дорогую верификацию, но не требуют управления состоянием.
• Системы доказательства STARK основаны на модели случайного оракула с использованием хэш-функций. Они прозрачны, изначально постквантовы и не требуют доверенной настройки. Их цена — это объем и стоимость верификации. Один STARK содержит тысячи хэш-путей Меркла, поэтому размер каждого доказательства достигает десятков до сотен КБ; а с использованием современных доказателей стоимость верификации на цепи может достигать миллионов Gas, что на порядок выше, чем стоимость Gas на основе парных SNARK.

В целом, внедрение PQ-примитивов на различных уровнях протокола Ethereum сталкивается с основными вызовами, связанными с большими подписями и доказательствами, более дорогой верификацией и более сложными протоколами:

Консенсус

Размер набора валидаторов Ethereum динамичен, и каждый слот имеет около 1/32 валидаторов, которые делают доказательства (attest). Аггрегация BLS сжимает их голосования на цепи до всего лишь 8 подписей по 96 байт, и именно эта агрегация делает возможным такой масштаб валидаторов. Однако перед CRQC закрытый ключ валидатора может быть выведен из его открытого ключа, поэтому противник, обладающий открытым ключом валидатора, может подделать их доказательства и окончательно завершить недействительную цепь. Естественной постквантовой альтернативой является схема хэширования с состоянием, такая как XMSS, поскольку валидатор может безопасно управлять своим состоянием ключа, подписывая консенсус. Однако XMSS не может агрегировать, как BLS; при примерно 1 миллионе валидаторов каждый слот должен нести около 31,000 PQ подписей. При расчете на каждую подпись около 3 кБ объем данных на каждый слот составит около 90 МБ, что на несколько порядков превышает уровень, который можно достичь с текущей агрегацией. В сценарии окончательности одного слота ситуация будет еще хуже. Чтобы завершить каждый блок в своих слотах, весь набор валидаторов должен делать доказательства в каждом слоте, что приведет к объему данных подписей до уровня гигабайтов.

Учетные записи

Учетные записи пользователей используют ECDSA для аутентификации. Как только учетная запись инициирует транзакцию, ее открытый ключ становится доступным, поэтому CRQC может восстановить закрытый ключ и подписать транзакцию от имени владельца, тем самым произвольно исчерпывая средства. Замена его неизбежна, но внешние учетные записи (EOA) не могут управлять состоянием подписи так, как это делают валидаторы, поэтому им нужны безсостояние схемы, что увеличивает стоимость верификации подписи на уровне исполнения. В настоящее время нет явного победителя. Работа EF сосредоточена на безсостоянии хэш-схемах SPHINCS+, хотя схемы на основе решеток все еще рассматриваются, что в значительной степени зависит от стоимости верификации. Стоимость верификации SPHINCS+ на EVM высока, и именно поэтому некоторые работы направлены на то, чтобы сделать безсостояние схемы более дешевыми: SPHINCS-minus — это проверка, основанная на keccak; а другие работы обходят это, используя абстракцию учетных записей для ротации одноразовых ключей, чтобы каждая подпись могла использовать гораздо более дешевую одноразовую схему.

Rollups

Rollup завершает расчеты, публикуя доказательства действительности на L1. На сегодняшний день самый дешевый способ верификации основан на парных SNARK: доказательства занимают всего несколько сотен байт, а стоимость верификации составляет около 200–500k Gas. CRQC разрушит парные предположения, на которых они основаны, поэтому злоумышленник может подделать доказательства действительности, которые никогда не происходили, и L1 примет их, окончательно завершив мошенническое состояние rollup и его выводы. Это также делает неэффективными многие приемы, на которых rollup полагается для поддержания низких затрат, такие как упаковка крупных STARK в небольшие окончательные SNARK для расчетов, поскольку эта внешняя упаковка также основана на парных. Без этого rollup должен непосредственно проверять STARK на L1, что обойдется в миллионы Gas, что на порядок выше, чем SNARK. Поддержание доступности верификации STARK в настоящее время является открытым исследовательским вопросом.

Доступность данных

Ethereum blob использует KZG-обещания, которые представляют собой схему многочленных обещаний, генерируя 48-байтное обещание для каждого 128 kB blob. KZG упрощает выборку доступности данных, поскольку он предоставляет (i) постоянный размер открытия, поэтому стоимость проверки каждого образца низка, (ii) линейный, поддерживающий 2D выборку, и (iii) возможность восстановления, поврежденные коды могут быть восстановлены на основе одного и того же обещания. К сожалению, KZG также основан на парных, поэтому CRQC может подделать открытия, выдавая недоступные данные за доступные. Альтернатива, безопасная для квантов, должна исходить от хэшированных обещаний, вопрос в том, сколько из гарантий KZG можно сохранить. Существующие постквантовые кандидаты сталкиваются с различными компромиссами в вычислительной и сетевой эффективности, имея больший размер обещания и постоянно растущие затраты на доказательства и верификацию. FRIDA — это прозрачная DAS-схема на основе FRI, построенная на 1D кодах Рида-Соломона, выборка которых тестирует близость к кодовому слову. Ее цена — это пропускная способность: образцы KZG требуют только постоянного размера открытия, в то время как каждый образец FRIDA сопровождается полным доказательством близости, поэтому каждый образец значительно больше. ZODA — это еще одна альтернатива для 2D кодирования, которая делает каждую выборку строки и столбца самоподтвержденной и обеспечивает точную привязку к обещанным данным, но эта гарантия является выборочной и локальной (она охватывает только запрашиваемые узлы), и выборка требует загрузки целых строк и столбцов кодирования. Третий подход заключается в упаковке кодирования в STARK. Идея состоит в том, чтобы доказать в zkVM, что обещанные данные являются действительным кодом Рида-Соломона. Таким образом, одно доказательство может точно подтвердить все кодирование — не близость, а не выборочные образцы — и без необходимости доверенной настройки. Цена — это пропускная способность доказательства. Дизайн и бенчмаркинг EF leanDA исследовали этот метод: на современных высокопроизводительных CPU пропускная способность составляет около 0.9 MiB/s, иногда достигая около 1 MiB/s. Текущее исследование направлено на то, чтобы сделать его достаточно быстрым.

Направления исследований

Сокращение разрыва в принятии PQ-примитивов станет основным направлением исследований в ближайшие годы. Мы можем обобщить соответствующие исследования в три междисциплинарных направления:

Эффективность протокола, в двух аспектах:

• Объединение подписей PQ. Цель состоит в том, чтобы объединить множество крупных подписей PQ в одно доказательство, чтобы они оставались низкозатратными на ключевых путях протокола (особенно в консенсусе). LeanVM от EF уже может агрегировать XMSS со скоростью около 1480 подписей в секунду в доказательства размером менее 200 KiB, и эти доказательства могут рекурсивно комбинироваться, так что подписи могут агрегироваться параллельно и затем объединяться. Открытым вопросом является: можно ли разработать протокол, который будет осуществим на пути к единой окончательности слота (то есть, когда вся группа валидаторов предоставляет доказательства в каждом слоте) и при этом в максимально короткие сроки слота; кроме того, кто будет генерировать эти доказательства и какие будут соответствующие стимулы.
• Проверка транзакций. Frames (EIP-8141) позволяют аккаунтам нести свой собственный код для авторизации транзакций, перемещая проверку подписей из уровня протокола в пользовательскую логику аккаунта. Проверка больше не привязана к фиксированной подписи ECDSA, каждый аккаунт может выбрать свою собственную схему. Направление, которое необходимо исследовать, заключается в том, как эта проверка будет работать: будет ли она осуществляться на цепочке через предопределенные функции для каждой схемы или через постквантовые, агрегируемые доказательства. Последнее исследуется в EIP-8288, который объединяет доказательства подписей множества транзакций в одно, позволяя размеру доказательства блока и пропускной способности mempool оставаться стабильными, даже если количество PQ транзакций увеличивается.

Эффективность криптографии. Сокращение размера и затрат на проверку подписей PQ; например, стоимость проверки SPHINCS-minus на EVM составляет около 94k Gas. В идеале исследовательское сообщество должно разработать дружелюбные к zk подписи, чтобы их можно было эффективно доказывать в zkVM (работа EF над leanSPHINCS движется в этом направлении).

Инфраструктура доказательств. Стоимость доказательства примитивов PQ в основном определяется базовыми хеш-операциями. Стандартные хеш-функции (например, Keccak, SHA) являются не нативными операциями и должны быть арифметически обработаны, что приводит к вычислительным затратам. Исследуются два направления: хеши, дружелюбные к SNARK, такие как Poseidon (быстрые, но с меньшим количеством практических испытаний), и системы доказательства, которые обрабатывают ненативные операции напрямую, так что стандартная криптография может быть доказана без дорогостоящей симуляции полей. Для последнего направление исследований быстро продвигается, недавние работы, такие как Zinc+ и модульные обязательства на целых числах.

Постквантовые примитивы уже существуют, но их объем данных больше, а стоимость проверки выше. Цель исследования состоит в том, чтобы сделать их практичными на текущем уровне протокола. Например, публичный mempool с очень большими подписями приведет к взрывному росту объема данных, которые каждый клиент должен хранить и проверять, а проверка этих подписей будет стоить больше Gas, создавая нагрузку как для пользователей, так и для валидаторов. Ключевые технологии сосредоточены на доказательствах STARK, которые могут быть эффективно агрегированы, снижая объем данных и сложность проверки с O(n) до O(1). Клиент больше не обрабатывает и не проверяет n различных подписей PQ, а просто обрабатывает одно агрегированное доказательство. Именно эти же свойства открывают возможности для масштабирования, что мы обсудим далее.

Программируемая конфиденциальность

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

Пулы конфиденциальности для потребителей, такие как RAILGUN и Privacy Pools, обеспечивают конфиденциальность для обычных кошельков; в то время как платформы для бизнеса, такие как Paladin, обеспечивают программируемую, соответствующую конфиденциальность для учреждений. Но в настоящее время нет решения, которое могло бы одновременно обеспечить уровень институциональной конфиденциальности и простоту использования, как у обычного кошелька; кроме того, использование любого из них все равно означает необходимость обработки состояния вне цепи (например, Merkle-деревья, недействительные и криптографические ключи) и генерации нулевых знаний для каждой операции. Максимально простая дорожная карта конфиденциальности L1 от Виталика и дорожная карта конфиденциальности от pcaversaccio хорошо подводят итоги существующих направлений исследований конфиденциальности в Эфириуме. Эти направления можно обобщить в четыре более высоких уровня:

Доступность

Здесь есть две проблемы. Во-первых, создание конфиденциальной транзакции должно ощущаться так же, как отправка обычной транзакции, но сегодня это требует специально построенной транзакции, отслеживания состояния вне цепи и генерации нулевых знаний. Во-вторых, это должно быть недорого, но конфиденциальный перевод включает в себя SNARK, поэтому он несет больше данных и более высокие затраты на проверку, чем публичный перевод, и как только добавляются постквантовые подписи и доказательства, этот разрыв только увеличивается. Стандартизированные фреймы, такие как Kohaku и Paladin, которые могут скрыть эту сложность, начинают решать первую проблему, хотя оба все еще находятся на ранних стадиях и активно разрабатываются. Ключ к решению второй проблемы заключается в агрегировании доказательств (предложение для EIP-8288), что является экономически эффективным способом объединить доказательства множества транзакций в одно и распределить затраты на проверку.

Безопасность без доверия и антикоррупционность

Сегодня многие протоколы конфиденциальности зависят от релееров (relayers), представляющих пользователей при подаче транзакций, что является доверенным посредником, который может подвергать цензуре, задерживать или анонимизировать. Устранение этой зависимости является целью. Транзакции Frame (EIP-8141) являются основой: они разделяют «кто авторизует транзакцию» и «кто платит Gas, как выполняется», так что плательщик может отличаться от подписанта, а конфиденциальные расходы больше не требуют наличия счета с достаточными средствами, связанным с личностью, чтобы попасть в цепь. Два взаимодополняющих элемента заполняют этот пробел. Случайные числа с ключами EIP-8250 предоставляют независимую область случайных чисел, так что конфиденциальные операции одного и того же отправителя не конфликтуют друг с другом; недавний корень (EIP-8272) позволяет транзакциям заявлять о Merkle-дереве, на основе которого основаны их доказательства, так что по мере продвижения дерева доказательства остаются действительными. Они вместе предоставляют стабильную, внутреннюю в протоколе ссылку для проверки конфиденциальных транзакций, так что их действительность не зависит от быстро меняющегося состояния, и любой может проверять асинхронно. Что касается обязательного списка включения FOCIL (EIP-7805), включатели (includers) могут независимо проверять действительность транзакции и запрашивать ее включение, предоставляя гарантии антикоррупционности, которые не могут быть обеспечены методами, основанными на релеерах.

Извлечение данных

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

Конфиденциальность внутри протокола

Самое амбициозное направление заключается в том, чтобы встроить конфиденциальные переводы в сам протокол, включая ограничения дизайна PQ с самого начала, так что конфиденциальные остатки не будут подвергаться риску «сначала собрать, затем расшифровать». Задачи серьезные — от восстановления всего криптографического стека (обязательства, недействительные, упаковка ключей, подписи) на основе PQ до генерации доказательств на аппаратных кошельках — эти задачи были хорошо изложены на пути к нативному постквантовому приватному ETH.

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

Проблемы и третий столп

Эти два столпа имеют одну общую сложную характеристику: они дорогостоящи с точки зрения криптографии.

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

Если их развернуть на уровне протокола, оба увеличат затраты на проверку для каждого узла в сети.

Один и тот же ответ постоянно возникает. Постквантовые подписи объединяются в рекурсивные STARK, квантовая безопасность доступности данных кодирует их в STARK, конфиденциальные переводы упаковывают свои доказательства в другой STARK, в то время как rollup уже рассчитывается таким образом. Повторяющийся вопрос заключается в том: как мы можем позволить себе более сильную криптографию? Этот вопрос каждый раз сводится к более узкому вопросу:

Как мы можем агрегировать и проверять STARK с минимальными затратами и максимальной эффективностью?

Расширение базового уровня

Дорожная карта, сосредоточенная на rollup, уже переместила выполнение из L1, позволяя Эфириуму сосредоточиться на консенсусе, расчетах и доступности данных. Но масштабирование не может закончиться на уровне 2. Каждый rollup наследует все, что предоставляет базовый уровень: его консенсус, окончательность, проверку и доступность данных, поэтому улучшение базового уровня улучшает все, что построено на нем.

Мы сосредоточены на расширении по двум осям: выполнению и консенсусу *; и на обоих из них решающим рычагом является один и тот же. Рекурсивные доказательства и агрегирование могут представлять большое количество доказательств или множество дорогих криптографических проверок в виде одного лаконичного доказательства. Поскольку STARK может проверять другие STARK, эти агрегаты могут бесконечно комбинироваться; и поскольку рекурсия будет складывать каждый уровень в проверку фиксированного размера, стоимость проверки окончательного доказательства почти не будет расти с увеличением количества его агрегированных доказательств, поэтому каждому узлу нужно проверять только одно доказательство, а не тысячи.

Выполнение

Выполнение — это обработка большего количества транзакций за меньшее время. Агрегация доказательств позволяет клиентам выполнения сжимать проверку множества транзакций в одно STARK, и эти транзакции не обязательно должны принадлежать одному и тому же типу. Проверка постквантовых подписей, конфиденциальные переводы и расчет rollup могут быть объединены в одно агрегированное доказательство. Именно поэтому транзакции Frame — которые позволяют аккаунтам определять свою собственную логику проверки транзакций, а не жестко закодированные подписи — имеют решающее значение для уровня выполнения, когда они объединяются с агрегированием доказательств. Каждая транзакция через Frame заявляет необходимые проверки как обязательство, а строители обрабатывают всю партию в рекурсивном STARK, а не заставляют каждый узел проверять каждую проверку инлайн. Предложенный тип Frame для подписи PQ и агрегирования STARK (EIP-8288) делает это конкретным, стоимость «оплачивается только строителями и mempool, а не всеми узлами проверки»; та же идея также позволяет поддерживать пропускную способность mempool постоянной по мере роста объема доказательств.

Консенсус

Консенсус сам по себе включает несколько вопросов, и STARK помогает с каждым из них.

Пропускная способность

Создание более крупных блоков без увеличения затрат на проверку. Как только валидаторы проверяют доказательства действительности, а не повторно выполняют блоки, строители могут публиковать действительные доказательства, удерживая при этом основные данные, поэтому необходимо явно гарантировать доступность данных. Направление blocks-in-blobs упаковывает транзакции в blob, валидаторы проводят выборку доступности, а не загружают полный объем; STARK предложителя предназначен для доказательства того, что блок был правильно выполнен и закодирован. Таким образом, затраты на проверку увеличиваются с расширением доказательства, а не с увеличением размера блока.

Время слота

Сокращение интервалов между блоками путем декомпозиции доступной цепи и механизма окончательности. Небольшой комитет, выбранный случайным образом, постоянно генерирует блоки на критическом пути, как это представлено в быстром слое LMD-GHOST с несколькими сотнями валидаторов и в дизайне декомпозированного консенсуса; в то время как полный набор валидаторов параллельно завершает окончательность вне критического пути. Меньшее количество валидаторов на каждом этапе означает меньшее количество агрегатов STARK на горячем пути и более короткое время слота.

Окончательность

Сокращение времени окончательности, которое в настоящее время составляет около шестнадцати минут, например, с помощью однораундной окончательности, удаляя один раунд голосования из критического пути.

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

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

Именно здесь рекурсивный STARK становится основой протокола. Объединение этих частей — выполнение агрегации, доказательства blocks-in-blobs и агрегированные постквантовые доказательства — является направлением, в котором необходимо двигаться в следующем исследовании.

* Третья ось — это расширение уровня данных, но это строго связано с работой по PQ DA.

Перспективы

Дорожная карта неопределенна, исследования никогда не являются линейными. Но некоторые зависимости выглядят прочными.

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

Сможет ли агрегация STARK поддерживать Ethereum, зависит от нескольких конкретных и все еще открытых вопросов:

• Агрегация гетерогенных подписей. Доказать и объединить разные PQ подписи в одной агрегации, например, агрегировать основанные на хэшах подписи и основанные на решетках подписи в одном STARK. Уровень учетных записей не выберет единственное решение, поэтому агрегация должна быть независимой от конкретного решения.
• Эффективное доказательство хэша. Затраты на доказательство определяются основным хэшом, пропускная способность все еще далека от требований. Эта компромисс заключается в том, что доказательство проверенных хэшей (таких как Keccak и SHA) на не родных полях приведет к арифметическим затратам; в то время как zk-дружественные хэши (такие как Poseidon2) имеют низкие затраты на доказательство, но подвергаются меньшему криптоанализу.
• Кросс-доменная агрегация. Сложение различных видов STARK в одно рекурсивное доказательство — от проверки подписей PQ, защищенных переводов до переходов состояния rollup — позволяет всему стеку делить одно и то же доказательство.
• Адаптация агрегации к консенсусу. Прямое решение временных требований консенсуса: агрегировать полный набор валидаторов в рамках одного слота и находить оптимальный баланс между размером комитета, длиной слота и окончательностью при постоянно сокращающемся времени слота.
• Готовность протокола. Обеспечить наличие инфраструктуры, поддерживающей эти агрегации, как на уровне mempool (например, с использованием Frame и EIP-8288), так и на уровне консенсуса: на масштабе миллиона валидаторов, доказательства STARK для PQ подписей каждого валидатора также должны быть агрегированы, как это происходит сегодня с подписями BLS.
• Правильные стимулы. Агрегация просто перенесла затраты и не устранила их: затраты на доказательства сосредоточены на строителях блоков, что вызывает реальные вопросы о стимулах и централизации.

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