原文标题：《Возможные будущие сценарии протокола Ethereum, часть 4: The Verge》

Оригинальный автор: Виталик Бутерин

Исходный текст: Mensh, ChainCatcher

Особая благодарность Джастину Дрейку, Ся-Вей Ванп, Гийому Балле, Ицинасио, Рошу Рудольфу, Леву Соуканою Райану Шону Адамсу и Уме Рой за обратную связь и рецензирование.

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

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

The Verge 2023 план развития

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

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

The Verge: ключевая цель

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

В этой главе

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

Без состояния проверки: Verkle или STARKs

Что мы должны решить?

В настоящее время клиент ETH нуждается в хранении сотен гигабайт состояний данных для проверки Блока, и это количество увеличивается каждый год. Оригинальные данные состояния увеличиваются примерно на 30 ГБ ежегодно, и для эффективного обновления троек каждому клиенту необходимо хранить некоторые дополнительные данные.

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

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

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

Фактически, для реализации безсостоянийной проверки требуется изменить структуру дерева состояний Ethereum. Это связано с тем, что текущее дерево Меркла-Патриции крайне непригодно для реализации любых схем доказательствашифрования, особенно в худшем случае. Как для "простых" ветвей Merkle, так и для возможности "упаковки" в STARK. Основные трудности возникают из-за некоторых слабых мест в MPT:

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

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

Мы можем рассчитать худший сценарий следующим образом:

30000000 Газ / 2400 (счет чтения стоимости) * (5 * 488 + 24000) = 330000000 байт

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

Если мы заменим шестнадцатеричное дерево на бинарное дерево и выполним дополнительное Merkle-хеширование кода, то в худшем случае размер будет примерно 30000000/2400* 32*( 32-14+ 8) = 10400000 байт (14 - это вычитание избыточных битов для ветвления 2 ^ 14, а 8 - это длина подтверждения в листе блока кода). Следует отметить, что это потребует изменения стоимости Газа, взимаемой за доступ к каждому отдельному блоку кода; EIP-4762 делает именно это. Объем 10.4 МБ будет лучше, но для многих узлов объем загружаемых данных за один временной интервал все еще слишком велик. Поэтому нам нужно внедрить более мощные технологии. В этом отношении есть два ведущих решения: дерево Verkle и STARKed бинарное хеш-дерево.

Дерево Verkle

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

Таким образом, размер отдельной ветки в доказательстве становится 32 - 1 OG 256(N) = 4 * log 2(N) байт. Теоретически максимальный размер доказательства составляет около 130000 байт (из-за неравномерного распределения блоков состояния фактический результат вычисления немного отличается, но это может быть принято как первое приближение).

Еще один важный момент: во всех вышеупомянутых примерах 'наихудший случай' не является наихудшим случаем на самом деле. Худший случай - это когда злоумышленник специально 'выкапывает' два Адреса, чтобы они имели более длинный общий префикс в дереве и считывает данные из одного из них, что может удлинить длину ветви в худшем случае вдвое. Но даже если такое произойдет, длина доказательства худшего случая в Verkle Tree составит 2,6 МБ, что практически совпадает с текущими проверочными данными в наихудшем случае.

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

STARKed бинарное дерево хэшей

Принцип этой технологии является очевидным: вам просто нужно создать двоичное дерево, получить доказательство размером до 10,4 МБ, подтверждающее значение в блоке, затем заменить это доказательство доказательством STARK. Таким образом, само доказательство содержит только подтвержденные данные, плюс фиксированные издержки от реального STARK в размере 100-300 кБ.

Основной вызов здесь - это проверка времени. Мы можем провести вычисления, похожие на те, которые мы проводили выше, за исключением того, что мы вычисляем не количество байтов, а хэш-значение. Блок размером 10,4 МБ означает 330 000 хэш-значений. Если добавить вероятность того, что злоумышленник «добывает» Адреса дерева с длинным общим префиксом, то в худшем случае количество хэш-значений составит около 660 000. Поэтому, если мы сможем доказать, что количество хэшей в секунду составляет 200 000, то проблем не будет.

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

1. Быстро провести обширный анализ безопасности Poseidon и достаточно хорошо знать его, чтобы развернуть на уровне L1
2. Используйте более "консервативную" хэш-функцию, такую как SHA 256 или BLAKE

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

Примеры использования свидетельств за пределами верификационного блока

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

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

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

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

• Деревья Веркля
• Оригинальная статья Джона Кузмаула о дереве Веркле
• Старквар
• Бумага Poseidon 2
• Ajtai (альтернативная быстрая функция хеширования, основанная на решетчатой сложности)
• Verkle.info

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

Оставшаяся основная работа заключается в

1. Дополнительный анализ последствий EIP-4762 (изменения затрат на Газ без состояния)

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

3. Более детальный анализ безопасности функций хэширования Poseidon, Ajtai и других "STARK-friendly"

4. Для дальнейшего развития "консервативного" (или "традиционного") хеша с высокоэффективными функциями STARK Протокола, такими как на основе точек зрения Binius или GKR.

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

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

• В настоящее время код дерева Verkle уже довольно зрелый. Кроме Verkle, использование любого другого кода будет задерживать развертывание и, скорее всего, приведет к хардфорку. Это тоже нормально, особенно если нам нужно дополнительное время для анализа хеш-функций или реализации валидаторов, или у нас есть другие важные функции, которые мы хотим внедрить раньше в сеть Ethereum.
• Использование хэш-значения для обновления корня состояния быстрее, чем использование дерева Verkle. Это означает, что метод, основанный на хэш-значениях, может сократить время синхронизации Полного Узла.
• Дерево Веркла обладает интересным свойством обновления подтверждения - подтверждение дерева Веркла является обновляемым. Это свойство полезно для mempool, списка включений и других случаев использования, а также может помочь повысить эффективность реализации: если объект состояния обновляется, то можно обновить подтверждение предпоследнего уровня, не считывая содержимого последнего уровня.
• Дерево Verkle сложнее подвергаться доказательству SNARK. Если мы хотим уменьшить размер доказательства до нескольких тысяч байтов, то доказательство Verkle будет вызывать некоторые трудности. Это связано с тем, что проверка доказательства Verkle включает большое количество операций с 256 битами, что требует либо больших затрат, либо наличия настраиваемой внутренней структуры доказательства, включающей 256-битную часть доказательства Verkle. Это не является проблемой для самого состояния, но создает больше трудностей.

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

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

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

Другим неожиданным инструментом является вычисление состояния корня с задержкой до временного интервала после Блока. Таким образом, у нас есть целых 12 секунд для вычисления состояния корня, что означает, что даже в самых экстремальных случаях достаточно времени для доказательства 60000 хэшей в секунду, что снова заставляет нас думать, что BLAKE 3 едва ли может удовлетворить требования.

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

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

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

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

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

EVM выполнение доказательство действительности

Что мы должны решить?

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

Для достижения этой цели необходимо предоставить доказательства SNARK или STARK для (i) уровня консенсуса (т.е. доказательства доли собственности) и (ii) уровня исполнения (т.е. EVM). Первое само по себе является вызовом, который должен быть решен в процессе дальнейшего улучшения уровня консенсуса (например, в отношении однократной финальности). Второе требует доказательства выполнения EVM.

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

С формальной точки зрения, в спецификации ETH, 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 ETH. Это делает ресурсы клиента довольно низкими. Для реализации полностью проверенного клиента Ethereum также необходимо проделать ту же работу в отношении соглашения.

Реализация доказательства действительности для вычислений в EVM уже существует и широко используется в L2. Однако для достижения возможности использования доказательства действительности EVM в L1 требуется выполнить еще много работы.

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

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

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

В настоящее время система электронного учета имеет два недостатка в области доказательства действительности: безопасность и время проверки.

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

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

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

Реализация этого вызывает определенные трудности. Даже в самых неблагоприятных условиях, когда очень большая транзакция занимает весь блок, вычисления не могут быть выполнены по порядку, а должны выполняться по операциям (кодам операций Виртуальной машины, таких как EVM или RISC-V). Один из ключевых вызовов при реализации - это обеспечить согласованность "памяти" Виртуальной машины между различными частями доказательства. Однако, если мы сможем решить эту рекурсивную проблему, то мы знаем, что хотя бы проблема задержки проверяющего уже решена, даже если в других аспектах не было никаких улучшений.

• Оптимизация системы подтверждения - новая система подтверждения, такая как Orion, Binius, GRK и другая информация, скорее всего, приведет к еще одному значительному сокращению времени проверки общих вычислений.
• Другие изменения стоимости Газа в EVM - многие вещи в EVM могут быть оптимизированы, чтобы быть более выгодными для проверяющего, особенно в худшем случае. Если злоумышленник может создать Блок, который заблокирует проверяющего на десять минут, то достаточно доказать обычный блок ETH в течение 4 секунд. Требуемые изменения в EVM можно условно разделить на следующие категории:

• Изменение стоимости Газа - если операция требует длительного времени для подтверждения, то даже если скорость ее вычисления относительно быстрая, стоимость Газа должна быть высокой. EIP-7667 - это EIP, предложенный для решения этой самой серьезной проблемы: он значительно увеличивает стоимость Газа для (традиционной) хеш-функции, потому что операции с этими функциями и предварительной компиляцией относительно дешевы. Чтобы компенсировать увеличение стоимости Газа, мы можем снизить стоимость Газа для операций EVM с низкой стоимостью подтверждения, чтобы сохранить среднюю пропускную способность неизменной.

• Замена структуры данных - помимо замены дерева состояний более дружественным способом, мы также должны заменить список транзакций, дерево квитанций и другие структуры, требующие дорогостоящего доказательства. Перенос структуры транзакций и квитанций в EIP SSZ, предложенный Этаном Кисслингом, является шагом в этом направлении.

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

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

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

• Доказательство параллелизма требует доказательства того, что разные части системы могут "разделять память" (например, таблицы поиска). Мы знаем о такой технике, но ее нужно реализовать.
• Нам нужно провести дополнительный анализ, чтобы найти идеальный набор изменений стоимости Газа, чтобы максимально сократить время проверки в худшем случае.
• Нам нужно проделать больше работы в области системы доказательств

Возможная стоимость:

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

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

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

• L2的доказательство действительности（即 "ZK rollup"）
• Метод "STARK двоичного хеш-доказательства" без состояния

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

Кроме того, доказательство действительности EVM на L1 может значительно повысить лимит Газа на L1.

Соглашение доказательства действительности

Что мы должны решить?

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

Соглашение比 EVM гораздо проще, но сталкивается с вызовом, что у нас нет L2 EVM свертки, поэтому большая часть работы все равно должна быть выполнена. Таким образом, любая реализация соглашения Ethereum требует "с нуля", хотя сама система доказательств может быть использована для построения совместной работы на ее основе.

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

блокчейн-маяк определяется как функция перехода состояния, такая же, как и EVM. Функция перехода состояния в основном состоит из трех частей:

• ECADD (для проверки BLS-подписи)
• Пара (используется для проверки BLS-подписи)
• Значение хеш-функции SHA 256 (используется для чтения и обновления состояния)

В каждом Блоке нам нужно доказать 1-16 BLS 12-381 ECADD для каждого валидатора (их может быть больше одного, так как подписи могут содержаться более чем в одном наборе). Это может быть компенсировано техникой предварительного вычисления подмножества, поэтому мы можем сказать, что на валидаторы необходимо доказать только один BLS 12-381 ECADD. В настоящее время на слот приходится 30 000 подписей валидаторов. В будущем это может измениться в двух направлениях по мере достижения однослотовой финализации: если мы пойдем по пути «грубой силы», количество валидаторов на слот может увеличиться до 1 миллиона. При этом, в случае принятия Orbit SSF, количество валидаторов останется на уровне 32 768 или даже уменьшится до 8 192.

Как работает агрегация BLS: Для проверки общей подписи требуется только один ECADD на участника, а не один ECMUL. Но 30 000 ECADDs — это все равно большое доказательство.

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

Одним из главных вызовов для вычислений BLS 12-381 является отсутствие удобной кривой, порядок которой равен размеру поля BLS 12-381, что добавляет значительные затраты для любой системы доказательств. С другой стороны, дерево Verkle, предложенное для ETH-сети, построено на кривой Bandersnatch, что делает саму BLS 12-381 подходящей подсистемой SNARK для доказательства ветвей Verkle. Простая реализация может доказать 100 G1 на секунду, для достаточно быстрой скорости доказательства, почти наверняка потребуется умное использование технологий, таких как GKR.

Для хэш-значения SHA 256 наиболее плохой сценарий включает блок конвертации эпохи, обновление всего дерева короткого баланса валидатора и большого количества сбалансированных валидаторов. Для каждого дерева короткого баланса валидатора требуется всего один байт, поэтому 1 МБ данных будет перехэшировано. Это эквивалентно 32768 вызовам SHA 256. Если баланс тысячи валидаторов выше или ниже порогового значения, необходимо обновить действительный баланс в записи валидаторов, что приводит к тысяче ветвей Merkle и, следовательно, может потребоваться 10000 хэш-значений. Механизм перемешивания требует 90 бит на каждого валидатора (следовательно, требуется 11 МБ данных), но это может быть вычислено в любое время внутри эпохи. В случае завершения одного слота эти цифры могут изменяться в зависимости от конкретных обстоятельств. Перемешивание становится ненужным, хотя Orbit может восстановить эту потребность в определенной степени.

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

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

• Изменение хеш-функции: теперь используется полная хеш-функция SHA 256, поэтому каждый вызов должен соответствовать двум вызовам сжимающей функции на нижнем уровне из-за заполнения. Если использовать сжимающую функцию SHA 256, мы можем получить вдвое больше прибыли. Если использовать Poseidon, мы можем получить прирост в 100 раз, что полностью решит все наши проблемы (по крайней мере, в отношении хеш-значений): при 1,7 миллиона хеш-значений в секунду (54 МБ), даже миллион записей проверки можно прочитать в течение нескольких секунд.
• Если это Orbit, то записи проверяющего, полученные после перемешивания, сохраняются напрямую: если выбрано определенное количество проверяющих (например, 8192 или 32768) в качестве комитета для данного слота, то они помещаются непосредственно в состояние рядом друг с другом, так что наименьший хеш может быть использован для чтения открытого ключа всех проверяющих в доказательстве. Это также позволяет эффективно выполнить все обновления баланса.
• Агрегация подписей: любая высокопроизводительная схема агрегации подписей требует какого-то рекурсивного доказательства, разные Узелы в сети будут выполнять промежуточное доказательство для подмножества подписей. Таким образом, работа по доказательству естественным образом распределяется между несколькими Узлами в сети, что значительно снижает нагрузку на "конечного доказателя ".
• Другие схемы подписи: для подписи Lamport+ Merkle нам нужно 256 + 32 хэш-значения для проверки подписи; умножив на 32768 подписчиков, мы получим 9437184 хэш-значения. Оптимизировав схему подписи, мы можем еще дальше улучшить этот результат с помощью небольшого постоянного множителя. Если мы используем Poseidon, это можно доказать в одном слоте. Но на самом деле, рекурсивная агрегирующая схема будет работать быстрее.

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

• 简洁的ETH坊Соглашение证明（仅限同步委员会）
• Helios в SP 1 внутри краткости
• Предварительная компиляция BLS 12-381
• Проверка сигнатуры BLS с использованием Halo 2

Какие еще задания нужно выполнить, как делать выбор:

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

Основным компромиссом, вероятно, будет порядок действий между более пошаговым подходом к реформированию консенсусного уровня Ethereum и более радикальным подходом "одновременного изменения многих". Для EVM пошаговый подход разумен, поскольку он позволяет минимизировать вмешательство в обратную совместимость. Для уровня консенсуса влияние на обратную совместимость невелико, и пересмотр всех аспектов построения блокчейн-маяка в более "комплексном" ключе с оптимизацией дружелюбности к SNARK в наилучшем виде также имеет свои преимущества.

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

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