Новая статья Виталика: возможное будущее протокола Ethereum — The Verge

На самом деле, нам потребуется несколько лет, чтобы получить доказательство валидности консенсуса Ethereum.

Оригинальное название: «Possible futures of the Ethereum protocol, part 4: The Verge»

Автор: Vitalik Buterin

Перевод: Mensh, ChainCatcher

 

Особая благодарность Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams и Uma Roy за отзывы и рецензирование.

Одна из самых мощных функций блокчейна заключается в том, что любой человек может запустить узел на своем компьютере и проверить корректность блокчейна. Даже если 9596 узлов, поддерживающих консенсус сети (PoW, PoS), мгновенно согласятся изменить правила и начнут производить блоки по новым правилам, каждый, кто запускает полностью валидирующий узел, откажется принимать такую цепочку. Минтеры, не входящие в этот сговор, автоматически объединятся вокруг цепи, продолжающей следовать старым правилам, и будут строить ее дальше, а полностью валидирующие пользователи будут следовать именно этой цепи.

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

Дорожная карта The Verge 2023

Изначально «Verge» означал перенос хранения состояния Ethereum на Verkle-деревья — структуру, позволяющую создавать более компактные доказательства и реализовать безстатусную валидацию блоков Ethereum. Узел может валидировать блок Ethereum, не храня на своем диске никакое состояние Ethereum (балансы аккаунтов, код контрактов, хранилище и т.д.), ценой загрузки нескольких сотен КБ доказательных данных и нескольких сотен миллисекунд дополнительного времени на верификацию доказательства. Сегодня Verge представляет собой более широкое видение, нацеленное на максимальную ресурсную эффективность валидации цепи Ethereum, включая не только безстатусные технологии, но и использование SNARK-доказательств для всей исполнительной части Ethereum.

Помимо долгосрочного фокуса на SNARK-доказательства всей цепи, появился еще один новый вопрос — действительно ли Verkle-деревья являются оптимальной технологией. Verkle-деревья уязвимы для атак квантовых компьютеров, поэтому если мы заменим текущие KECCAK Merkle Patricia Trees на Verkle-деревья, в будущем нам, возможно, придется снова менять структуру. Самозаменяемый вариант Merkle-деревьев — это сразу перейти к STARK-доказательствам для Merkle-ветвей, поместив их в бинарное дерево. Исторически этот подход считался невозможным из-за издержек и технической сложности. Однако недавно мы увидели, как Starkware на ноутбуке с помощью ckcle STARKs доказывает 1,7 миллиона Poseidon-хэшей в секунду, и благодаря технологиям вроде GKB время доказательства для более «традиционных» хэшей также быстро сокращается. Поэтому за последний год «Verge» стал более открытым, и теперь у него несколько возможных путей.

The Verge: ключевые цели

• Безстатусный клиент: полностью валидирующий клиент и маркерный узел не должны требовать более нескольких ГБ хранилища.
• (В долгосрочной перспективе) Полная валидация цепи (консенсус и исполнение) на смарт-часах. Скачайте немного данных, проверьте SNARK — готово.

В этой главе

• Безстатусный клиент: Verkle или STARKs
• Доказательство валидности исполнения EVM
• Доказательство валидности консенсуса

Безстатусная валидация: Verkle или STARKs

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

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

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

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

Безстатусная валидация — это технология, позволяющая узлам валидировать блоки без полного состояния. Вместо этого каждый блок сопровождается свидетельством, включающим: (i) значения, код, балансы, хранилище в определенных местах состояния, к которым обращается блок; (ii) криптографические доказательства корректности этих значений.

На практике реализация безстатусной валидации требует изменить структуру дерева состояния Ethereum. Дело в том, что текущее Merkle Patricia Tree крайне неудобно для внедрения любых криптографических схем доказательств, особенно в худшем случае. Это касается как «оригинальных» Merkle-ветвей, так и возможных STARK-оберток. Основные сложности связаны с некоторыми слабыми местами MPT:

1. Это 16-ичное дерево (каждый узел имеет 16 дочерних). Это значит, что в дереве размера N доказательство в среднем требует 32*(16-1)*log16(N) = 120*log2(N) байт, или примерно 3840 байт для дерева с 2^32 элементами. Для бинарного дерева требуется 32*(2-1)*log2(N) = 32*log2(N) байт, или около 1024 байт.

2. Код не мерклизован. Это значит, что чтобы доказать доступ к коду аккаунта, нужно предоставить весь код, максимум 24000 байт.

 

В худшем случае можно посчитать так:

30000000 gas / 2400 (стоимость чтения холодного аккаунта) * (5 * 488 + 24000) = 330000000 байт

Стоимость ветвления немного ниже (используется 5*480 вместо 8*480), потому что при большом числе ветвей их верхняя часть повторяется. Но даже так объем данных, который нужно скачать за один слот, совершенно нереален. Если попытаться обернуть это в STARK, возникнут две проблемы: (i) KECCAK не очень дружелюбен к STARK; (ii) 330MB данных означают, что нужно доказать 5 миллионов вызовов функции KECCAK round, что невозможно для любого оборудования, кроме самого мощного, даже если мы добьемся высокой эффективности доказательства KECCAK через STARK.

Если мы просто заменим 16-ичное дерево на бинарное и отдельно мерклизуем код, то худший случай будет примерно 30000000/2400*32*(32-14+8) = 10400000 байт (14 — это вычитание избыточных бит для 2^14 ветвей, 8 — длина доказательства для входа в лист кода). Важно, что это требует изменения стоимости gas — взимать плату за доступ к каждому отдельному блоку кода; EIP-4762 делает именно это. 10,4 MB — уже лучше, но для многих узлов это все равно слишком много данных за слот. Поэтому нужны более мощные технологии. Здесь есть два лидирующих решения: Verkle-деревья и STARKed бинарные хэш-деревья.

Verkle-деревья

Verkle-деревья используют векторные обязательства на эллиптических кривых для более коротких доказательств. Ключ в том, что независимо от ширины дерева, каждый родитель-дочерний переход в доказательстве занимает только 32 байта. Единственное ограничение ширины дерева — если оно слишком широкое, вычисление доказательства становится неэффективным. Для Ethereum предлагается ширина 256.

Таким образом, размер одной ветви доказательства становится 32 - log256(N) = 4*log2(N) байт. Теоретически максимальный размер доказательства примерно 30000000 / 2400 * 32 * (32-14+8) / 8 = 130000 байт (из-за неравномерного распределения блоков состояния реальные цифры немного отличаются, но как первая аппроксимация это подходит).

Также важно отметить, что во всех этих примерах «худший случай» — не самый худший: еще хуже, если атакующий специально «выкопает» два адреса с длинным общим префиксом в дереве и будет читать данные с одного из них, что может удвоить длину ветви. Но даже тогда худшая длина доказательства для Verkle-дерева — 2,6MB, что сопоставимо с текущими худшими случаями валидации данных.

Мы также используем это замечание для еще одной вещи: делаем стоимость доступа к «смежным» областям хранилища очень низкой — будь то множество блоков кода одного контракта или соседние слоты хранилища. EIP-4762 определяет смежность и взимает за смежный доступ всего 200 gas. В этом случае худший размер доказательства — 30000000 / 200*32 - 4800800 байт, что тоже в пределах нормы. Если для безопасности нужно уменьшить это значение, можно немного повысить стоимость смежного доступа.

STARKed бинарные хэш-деревья

Суть технологии проста: строится бинарное дерево, берется максимум 10,4 MB доказательства, доказываются значения в блоке, а затем само доказательство заменяется STARK-доказательством. Таким образом, само доказательство содержит только доказываемые данные плюс фиксированные 100-300kB от STARK.

Главная проблема здесь — время валидации. Можно провести аналогичные расчеты, только считать не байты, а хэши. 10,4 MB блока — это 330000 хэшей. Если добавить возможность атаки с длинным общим префиксом, то в худшем случае будет около 660000 хэшей. Если можно доказать 200000 хэшей в секунду — проблем нет.

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

1. Быстро провести масштабный аудит безопасности Poseidon и достаточно хорошо его изучить для внедрения на L1
2. Использовать более «консервативные» хэши, такие как SHA256 или BLAKE

Для доказательства консервативных хэшей STARK-круг Starkware на момент написания статьи может доказать только 10-30k хэшей в секунду на ноутбуке. Но технология STARK быстро развивается. Уже сегодня технологии на базе GKR показывают возможность поднять скорость до 100-200k.

Другие случаи использования свидетельств, кроме валидации блоков

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

• Мемпул: когда транзакция транслируется, узлы P2P-сети должны проверить ее валидность до ретрансляции. Сейчас это включает проверку подписи, баланса и правильности nonce. В будущем (например, с нативной абстракцией аккаунтов, как в EIP-7701) это может включать выполнение EVM-кода с доступом к состоянию. Если узел безстатусный, транзакция должна содержать доказательства для соответствующих объектов состояния.
• Списки включения: это предлагаемая функция, позволяющая (возможно, небольшим и простым) валидаторам PoS заставлять следующий блок включать транзакцию, независимо от желания (возможно, более крупных и сложных) строителей блоков. Это ослабит возможность влиятельных участников манипулировать блокчейном путем задержки транзакций. Но для этого валидаторы должны иметь возможность валидировать транзакции из списка включения.
• Легкие клиенты: если мы хотим, чтобы пользователи получали доступ к цепи через кошельки (например, Metamask, Rainbow, Rabby и др.), им нужно запускать легкий клиент (например, Helios). Ядро Helios предоставляет пользователю проверенный корень состояния. Для полностью доверенного опыта пользователь должен получать доказательства для каждого RPC-запроса (например, для eth_call — доказательства всех обращений к состоянию).

У всех этих случаев есть общее: требуется довольно много доказательств, но каждое из них маленькое. Поэтому STARK-доказательства для них нецелесообразны; наиболее реалистично использовать Merkle-ветви напрямую. Еще одно преимущество Merkle-ветвей — обновляемость: имея доказательство для объекта состояния с корнем блока B, при получении дочернего блока B2 и его свидетельства можно обновить доказательство для корня B2. Verkle-доказательства также нативно обновляемы.

Связь с существующими исследованиями:

• Verkle trees
• Оригинальная статья John Kuszmaul о Verkle tree
• Starkware
• Poseidon2 paper
• Ajtai (альтернативные быстрые хэши на основе сложности решетки)
• Verkle.info

Что еще можно сделать?

Оставшаяся основная работа:

1. Больше анализа последствий EIP-4762 (изменения gas для безстатусности)

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

3. Больше аудита безопасности для Poseidon, Ajtai и других «STARK-friendly» хэшей

4. Дальнейшая разработка сверхэффективных STARK-протоколов для «консервативных» (или «традиционных») хэшей, например, на базе Binius или GKR.

Кроме того, скоро нам предстоит выбрать один из трех вариантов: (i) Verkle-деревья, (ii) STARK-friendly хэши, (iii) консервативные хэши. Их свойства можно обобщить в таблице ниже:

Кроме этих «заглавных цифр», есть еще несколько важных соображений:

• Сегодня код Verkle-деревьев уже достаточно зрелый. Любой другой вариант отсрочит внедрение, возможно, на целый хардфорк. Это не страшно, особенно если нам нужно дополнительное время для анализа хэшей или реализации валидатора, или если есть другие важные функции, которые мы хотим внедрить раньше.
• Обновление корня состояния через хэши быстрее, чем через Verkle-деревья. Это значит, что хэш-методы могут снизить время синхронизации полного узла.
• Verkle-деревья имеют интересное свойство обновления свидетельств — они обновляемы. Это полезно для mempool, списков включения и других случаев, а также может повысить эффективность реализации: если объект состояния обновлен, можно обновить свидетельство предпоследнего уровня без чтения последнего уровня.
• Verkle-деревья сложнее доказывать через SNARK. Если мы хотим уменьшить размер доказательства до нескольких килобайт, Verkle-доказательства создают трудности. Это связано с тем, что верификация Verkle-доказательства требует большого числа 256-битных операций, что либо увеличивает издержки, либо требует особой внутренней структуры доказательства с 256-битными частями. Для безстатусности это не проблема, но усложняет дальнейшее развитие.

Если мы хотим получить обновляемость Verkle-свидетельств квантово-безопасным и достаточно эффективным способом, другой путь — Merkle-деревья на основе решеток.

Если в худшем случае эффективность доказательной системы недостаточна, мы можем использовать неожиданный инструмент — многомерный gas: установить отдельные лимиты gas для (i) calldata; (ii) вычислений; (iii) доступа к состоянию и, возможно, других ресурсов. Многомерный gas увеличивает сложность, но взамен жестче ограничивает соотношение между средним и худшим случаем. С ним максимальное число ветвей для доказательства может снизиться с 12500 до, например, 3000. Это позволит даже BLAKE3 быть (едва) достаточным уже сегодня.

Многомерный gas позволяет лимитам ресурсов блока быть ближе к ограничениям аппаратного обеспечения

Еще один неожиданный инструмент — отложить вычисление корня состояния до слота после блока. Тогда у нас есть целых 12 секунд на вычисление корня, и даже в экстремальном случае 60000 хэшей в секунду будет достаточно, что снова делает BLAKE3 (едва) пригодным.

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

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

Решение безстатусной проблемы значительно увеличивает сложность одиночного стейкинга. Если появятся технологии, снижающие минимальный баланс для одиночного стейкинга, такие как Orbit SSF или политики на уровне приложений (например, squad staking), это станет более осуществимо.

Если одновременно внедряется EOF, анализ многомерного gas становится проще. Это потому, что основная сложность исполнения при многомерном gas связана с обработкой дочерних вызовов, не передающих весь gas от родителя, а EOF просто делает такие вызовы незаконными, что упрощает задачу (а нативная абстракция аккаунтов даст протокольную альтернативу текущим основным случаям частичного gas).

Между безстатусной валидацией и истечением истории есть важная синергия. Сегодня клиент должен хранить почти 1TB исторических данных — это в несколько раз больше, чем данных состояния. Даже если клиент безстатусный, мечта о почти безхранилищном клиенте невозможна, пока клиент обязан хранить историю. Первый шаг — EIP-4444, который подразумевает хранение истории в torrents или Portal Network.

Доказательство валидности исполнения EVM

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

Долгосрочная цель валидации блоков Ethereum ясна — нужно иметь возможность валидировать блок Ethereum так: (i) скачать блок или даже только часть данных для проверки доступности; (ii) проверить небольшое доказательство валидности блока. Это должно быть крайне легкой операцией, выполнимой на мобильном клиенте, в браузерном кошельке или даже на другой цепи (без части доступности данных).

Для этого нужны SNARK или STARK-доказательства для (i) консенсусного слоя (т.е. proof-of-stake) и (ii) исполнительного слоя (т.е. EVM). Первое само по себе вызов, который должен решаться по мере улучшения консенсусного слоя (например, для single-slot finality). Второе требует доказательства исполнения EVM.

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

Формально в спецификации Ethereum EVM определен как функция преобразования состояния: есть предыдущее состояние S, блок B, и вычисляется новое состояние S' = STF(S, B). Если пользователь использует легкий клиент, у него нет полного S и S', и даже E; вместо этого у него есть корень предыдущего состояния R, корень нового состояния R' и хэш блока H.

• Публичные входные данные: корень предыдущего состояния R, корень нового состояния R', хэш блока H
• Приватные входные данные: тело блока B, объекты состояния, к которым обращается блок Q, те же объекты после исполнения Q', доказательства состояния (например, Merkle-ветви) P
• Утверждение 1: P — корректное доказательство, что Q содержит части состояния, представленного R
• Утверждение 2: если запустить STF на Q, (i) процесс обращения только к объектам внутри Q, (ii) блок валиден, (iii) результат — Q'
• Утверждение 3: если пересчитать новый корень состояния по Q' и P, получится R'

Если это выполняется, можно иметь полностью валидирующий легкий клиент исполнения EVM. Это уже делает требования к ресурсам клиента очень низкими. Для настоящего полностью валидирующего клиента Ethereum нужно сделать то же самое для консенсуса.

Доказательства валидности исполнения EVM уже существуют и широко используются на L2. Но чтобы сделать их пригодными для L1, еще предстоит много работы.

Связь с существующими исследованиями?

• EFPSE ZK-EVM (устарел из-за появления лучших вариантов)
• Zeth, который компилирует EVM в RISC-0 ZK-VM
• Проект формальной верификации ZK-EVM

Что еще можно сделать?

Сегодня доказательства валидности исполнения имеют два недостатка: безопасность и время валидации.

Безопасное доказательство валидности должно гарантировать, что SNARK действительно проверяет вычисления EVM и не содержит уязвимостей. Два основных подхода к повышению безопасности — мульти-верификаторы и формальная верификация. Мульти-верификаторы — это несколько независимых реализаций доказательств валидности, как несколько клиентов; если блок доказан достаточно большой подгруппой этих реализаций, клиент принимает блок. Формальная верификация — это использование инструментов, обычно применяемых для доказательства математических теорем (например, Lean4), чтобы доказать, что доказательство валидности принимает только корректное исполнение EVM (например, EVM K semantics или python-спецификация EELS).

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

• Параллелизация — сейчас самый быстрый верификатор EVM может доказать блок Ethereum в среднем за 15 секунд, используя сотни GPU и объединяя их работу. Теоретически мы знаем, как сделать верификатор, доказывающий вычисления за O(log(N)) времени: дать каждому шагу отдельный GPU, а потом построить «дерево агрегации»:

Есть сложности реализации. Даже в худшем случае, когда одна большая транзакция занимает весь блок, делить вычисления нужно не по транзакциям, а по операциям (opcode EVM или RISC-V и т.д.). Ключевой вызов — обеспечить согласованность «памяти» виртуальной машины между разными частями доказательства. Но если реализовать такую рекурсивную схему, то, даже без других улучшений, задержка доказателя будет решена.

• Оптимизация доказательных систем — новые системы, такие как Orion, Binius, GRK и другие, скорее всего, еще раз сократят время валидации для универсальных вычислений.
• Изменения стоимости gas в EVM — многое можно оптимизировать для доказателей, особенно в худшем случае. Если атакующий может создать блок, блокирующий доказателя на 10 минут, то 4 секунды для обычного блока недостаточно. Необходимые изменения можно разделить на:
• Изменения стоимости gas — если операция долго доказывается, даже если она быстро вычисляется, ее gas должен быть высоким. EIP-7667 предлагает сильно увеличить gas для (традиционных) хэшей, потому что их opcode и прекомпайлы относительно дешевы. Чтобы компенсировать это, можно снизить gas для операций с низкой стоимостью доказательства, сохраняя среднюю пропускную способность.
• Замена структур данных — помимо замены дерева состояния на более дружелюбное к STARK, нужно заменить список транзакций, дерево квитанций и другие дорогие структуры. EIP Etan Kissling по переходу транзакций и квитанций на SSZ — шаг в этом направлении.

Кроме того, два инструмента из предыдущего раздела (многомерный gas и отложенный корень состояния) также помогут. Но в отличие от безстатусной валидации, здесь даже с этими инструментами для полноценной ZK-EVM валидации потребуется еще много работы — просто работы будет меньше.

Еще один неупомянутый момент — оборудование доказателя: использование GPU, FPGA и ASIC для ускорения генерации доказательств. Fabric Cryptography, Cysic и Accseal — три компании, добившиеся прогресса в этом. Это очень ценно для L2, но вряд ли станет определяющим для L1, потому что важно, чтобы L1 оставался децентрализованным, а значит, генерация доказательств должна быть доступна обычным пользователям Ethereum, а не зависеть от оборудования одной компании. L2 могут делать более агрессивные компромиссы.

В этих областях еще много работы:

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

Возможные компромиссы:

• Безопасность против времени доказателя: более агрессивные хэши, сложные доказательные системы, смелые допущения или другие схемы могут сократить время доказателя.
• Децентрализация против времени доказателя: сообществу нужно договориться о «спецификации» оборудования доказателя. Можно ли требовать, чтобы доказатели были крупными организациями? Хотим ли мы, чтобы топовый ноутбук мог доказать блок Ethereum за 4 секунды? Или что-то между?
• Степень нарушения обратной совместимости: другие недостатки можно компенсировать более агрессивными изменениями стоимости gas, но это, скорее всего, непропорционально увеличит издержки некоторых приложений, заставив разработчиков переписывать и деплоить код заново для сохранения экономической эффективности. Эти инструменты тоже имеют свою сложность и недостатки.

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

Ключевые технологии для доказательства валидности EVM на L1 во многом совпадают с двумя другими областями:

• Доказательства валидности на L2 («ZK rollup»)
• Безстатусный метод «STARK бинарного хэш-доказательства»

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

Кроме того, доказательство валидности EVM на L1 может значительно увеличить лимит gas на L1.

Доказательство валидности консенсуса

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

Если мы хотим полностью валидировать блок Ethereum через SNARK, исполнение EVM — не единственная часть, которую нужно доказать. Нужно также доказать консенсус, то есть часть системы, отвечающую за депозиты, выводы, подписи, обновления балансов валидаторов и другие элементы proof-of-stake Ethereum.

Консенсус намного проще EVM, но у него есть проблема: у нас нет L2 EVM rollup, поэтому большую часть работы все равно придется делать. Любая реализация доказательства консенсуса Ethereum должна быть «с нуля», хотя доказательная система может быть общей.

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

Beacon chain определяется как функция преобразования состояния, как и EVM. Она состоит из трех основных частей:

• ECADD (для проверки BLS-подписей)
• Паринг (для проверки BLS-подписей)
• SHA256-хэши (для чтения и обновления состояния)

В каждом блоке нужно доказать 1-16 BLS12-381 ECADD для каждого валидатора (может быть больше, если подписи входят в несколько наборов). Это можно компенсировать техникой подвыборки, так что на валидатора — одна ECADD. Сейчас на слот приходится 30000 подписей валидаторов. В будущем, с single-slot finality, это число может измениться: если идти «в лоб», число валидаторов на слот может вырасти до 1 миллиона. С Orbit SSF оно останется 32768 или даже снизится до 8192.

Как работает BLS-агрегация: для проверки общей подписи требуется по одной ECADD на участника, а не ECMUL. Но 30000 ECADD — все равно много для доказательства.

Что касается паринга, сейчас на слот максимум 128 доказательств, то есть 128 парингов. С помощью EIP-7549 и других изменений можно снизить до 16. Парингов мало, но они очень дорогие: каждый паринг требует в тысячи раз больше времени, чем ECADD.

Главная сложность доказательства операций BLS12-381 — нет удобной кривой с порядком, равным размеру поля BLS12-381, что увеличивает издержки для любой доказательной системы. Для Verkle-деревьев Ethereum используется кривая Bandersnatch, что делает BLS12-381 сам по себе кривой для SNARK-доказательств Verkle-ветвей. Простой вариант может доказывать 100 G1-сложений в секунду; для нужной скорости почти наверняка потребуется техника вроде GKR.

Для SHA256-хэшей худший случай — блок смены эпохи, когда обновляются все короткие балансы валидаторов и многие балансы. Короткий баланс — 1 байт на валидатора, то есть 1 MB данных нужно перехэшировать. Это 32768 вызовов SHA256. Если тысяча валидаторов меняет баланс выше или ниже порога, нужно обновить записи, что еще 10000 хэшей. Механизм перемешивания требует 90 бит на валидатора (11 MB данных), но это можно вычислять в любой момент эпохи. В случае single-slot finality эти цифры могут меняться. Перемешивание может стать ненужным, хотя Orbit может вернуть его в каком-то виде.

Еще одна проблема — нужно перечитывать все состояния валидаторов, включая публичные ключи, чтобы проверить блок. Для 1 миллиона валидаторов только чтение публичных ключей — 48 миллионов байт плюс Merkle-ветви. Это миллионы хэшей на эпоху. Если нужно доказать валидность PoS, реалистичный путь — некая форма инкрементальных доказуемых вычислений: внутри доказательной системы хранить отдельную структуру данных, оптимизированную для быстрого поиска и доказательства обновлений.

В целом, вызовов много. Для эффективного решения, скорее всего, потребуется глубокий редизайн beacon chain, возможно, одновременно с переходом на single-slot finality. Такой редизайн может включать:

• Смена хэш-функции: сейчас используется «полный» SHA256, из-за паддинга каждый вызов требует двух вызовов компрессии. Если перейти на SHA256 compression, выигрыш в 2 раза. Если на Poseidon — в 100 раз, и проблема хэшей исчезает: при 1,7 миллиона хэшей в секунду (54MB), даже миллион записей валидаторов можно «прочитать» в доказательство за несколько секунд.
• Для Orbit — прямое хранение перемешанных записей валидаторов: если для слота выбирается фиксированное число валидаторов (8192 или 32768), их можно хранить рядом в состоянии, чтобы минимизировать хэши для чтения публичных ключей. Это также ускоряет обновления балансов.
• Агрегация подписей: любая высокопроизводительная схема агрегации требует рекурсивных доказательств, когда разные узлы сети доказывают подписи подмножеств. Это естественно распределяет работу по доказательству между узлами, снижая нагрузку на «финального доказателя».
• Другие схемы подписей: для Lamport+Merkle-подписей нужно 256+32 хэшей на подпись; умножив на 32768 подписантов, получаем 9437184 хэшей. Оптимизация схемы может еще немного улучшить результат. С Poseidon это можно доказать за один слот. Но на практике рекурсивная агрегация будет быстрее.

Связь с существующими исследованиями?

• Succinct Ethereum consensus proofs (только для sync committee)
• Succinct Helios внутри SP1
• Succinct BLS12-381 precompile
• Halo2-based BLS aggregate signature verification

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

На практике нам потребуется несколько лет, чтобы получить доказательство валидности консенсуса Ethereum. Это примерно столько же, сколько потребуется для реализации single-slot finality, Orbit, изменения схемы подписей и аудита безопасности, необходимого для уверенного использования таких «агрессивных» хэшей, как Poseidon. Поэтому разумнее решать эти задачи параллельно, учитывая дружелюбность к STARK.

Главный компромисс, скорее всего, будет в порядке операций — между постепенным реформированием консенсусного слоя Ethereum и более радикальным «много изменений за раз» подходом. Для EVM постепенность разумна, чтобы минимизировать нарушение обратной совместимости. Для консенсуса влияние на обратную совместимость меньше, и более «всеобъемлющий» пересмотр деталей beacon chain для оптимизации под SNARK может быть полезен.

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

При долгосрочном редизайне PoS Ethereum дружелюбность к STARK должна быть приоритетом, особенно для single-slot finality, Orbit, смены схемы подписей и агрегации подписей.