Возможное будущее ETH (4): The Verge

Предыдущее чтение: «Vitalik о возможном будущем ETH (1): The Merge», «Vitalik о возможном будущем ETH (2): The Surge», «Vitalik о возможном будущем ETH (3): The Scourge».

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

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

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

The Verge 2023 Карта развития

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

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

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

· Безсостоятельный клиент: полностью проверенный клиент и узел токена не должны занимать более нескольких гигабайт свободного места.

· (Долгосрочно) Полная проверка цепочки (Соглашение и исполнение) на умных часах. Загрузка некоторых данных, проверка SNARK, завершение.

В этой главе

· Бесстатусный клиент: Verkle или STARKs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дерево Verkle

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

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

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

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

STARKed двоичное дерево хешей

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

Основным вызовом здесь является проверка времени. Мы можем провести вычисления, аналогичные описанным выше, только вместо количества байтов мы вычисляем хэш-значение. Блок размером 10,4 МБ означает 330000 хэш-значений. Если учесть возможность атакующего лица "выкапывать" возможность наличия длинного общего префикса в дереве адресов, то в худшем случае количество хэш-значений составит около 660000. Таким образом, если мы сможем доказать, что количество хэш-значений в секунду составляет 200,000, то проблем не будет.

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

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

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

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

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

· Пул памяти: когда транзакция транслируется, Узел в P2P-сети должен проверить, действительна ли транзакция, прежде чем повторно транслировать ее. Сегодня эта проверка включает проверку подписи, а также проверку достаточности баланса и правильности префикса. В будущем (например, с использованием абстракции счета, такой как EIP-7701), это может включать выполнение некоторого кода EVM, который выполняет доступ к состоянию. Если Узел является безсостояничным, тогда транзакция должна быть снабжена доказательством состояния объекта.

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

· легкий клиент：Если мы хотим, чтобы пользователи могли получить доступ к цепочке через кошелек (например, Metamask, Rainbow, Rabby и т. д.), для этого им необходимо запустить легкий клиент (например, Helios). Основной модуль Helios предоставляет пользователям проверенное состояние корневого узла. Чтобы обеспечить полностью доверенный опыт, пользователи должны предоставлять доказательства для каждого вызова RPC, который они делают (например, для запроса к сети ETH (пользователи должны доказать, что они имеют доступ ко всем состояниям, к которым они обращаются в процессе вызова)).

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

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

· Verkle деревья

· Оригинальная статья Джона Кузмола о дереве Веркле

· Старквар

· Бумага Poseidon2

· Ajtai (альтернативная быстрая хеш-функция на основе твердости решетки)

· Verkle.info

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

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

Дополнительный анализ последствий EIP-4762 (изменение стоимости Газа без состояния)
Завершите больше работы по разработке и тестированию переходной программы, которая является основной частью сложности реализации любой программы в безгосударственной среде.
Больше анализа безопасности функций хеширования Poseidon, Ajtai и других "STARK-friendly"
Дальнейшая разработка сверхэффективных функций STARK Protocol для «консервативных» (или «традиционных») хеш, например, с точки зрения Binius или GKR.

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

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

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

· Использование значения хеша для обновления корневого состояния быстрее, чем использование дерева Verkle. Это означает, что метод, основанный на значении хеша, может сократить время синхронизации Полного узла.

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

· Доказательство Verkle сложнее поддается SNARK. Если мы хотим уменьшить размер доказательства до нескольких тысяч байтов, доказательство Verkle вызывает некоторые трудности. Это связано с тем, что проверка доказательства Verkle включает в себя большое количество операций с 256 битами, что требует либо значительных затрат на проверку, либо наличия специальной внутренней структуры системы доказательства, которая включает в себя 256-битную часть доказательства Verkle. Это само по себе не является проблемой для состояния, но вызывает больше трудностей.

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

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

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

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

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

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

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

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

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

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

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

Долгосрочная цель проверки Блока ETH очень ясна - Блок 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' и доказательство состояния (например, ветвь Меркля) P

· Довод 1: P является действительным доказательством того, что Q содержит некоторые части состояния, представляемого R.

· Утверждение 2: Если STF работает на Q, (i) процесс выполнения доступен только внутренним объектам Q, (ii) блоки данных действительны, (iii) результат - это Q'

· Утверждение 3: если использовать информацию Q' и P для пересчета нового корневого состояния, то получится R'

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

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

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

· EFPSE ZK-EVM (отключено из-за наличия более лучших вариантов)

· Zeth, его принцип работы заключается в компиляции EVM в RISC-0 ZK-VM

· ZK-EVM проект формальной верификации

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

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

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

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

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

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

· Оптимизация системы доказательств - новая система доказательств, такая как Орион, Биниус, ГРК и многое другое, скорее всего, приведет к значительному сокращению времени проверки общих вычислений.

· Изменения стоимости Газа EVM — многие аспекты EVM могут быть оптимизированы для более выгодного участия верификаторов, особенно в худшем случае. Если злоумышленник может создать блок, заблокировавший верификатора на десять минут, то четыре секунды для верификации обычного ETH блока недостаточно. Изменения в EVM могут быть приблизительно разделены на несколько категорий:

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

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

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

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

· Параллелизация доказательства требует доказательства того, что разные части системы могут "разделять память" (например, таблицы поиска). Мы знаем такую технику, но ее нужно реализовать.

· Нам нужно провести больше анализа, чтобы найти идеальный набор изменений стоимости Газа, чтобы максимально сократить время проверки в худшем случае.

· Нам нужно больше работать над системой доказательств

Возможная цена:

· Безопасность и время проверки: если выбрать более агрессивную хеш-функцию, более сложную систему подтверждения или более агрессивное предположение о безопасности или другие проектные решения, можно сократить время проверки.

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

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

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

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

· Доказательство действительности L2 (также известное как «ZK rollup»)

· Метод бинарного хэш-доказательства STARK без состояния

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

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

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

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

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

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

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

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

· ECADD (для проверки подписи BLS)

· Пара (используется для проверки подписи BLS)

· SHA256 хэш-значение (используется для чтения и обновления состояния)

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

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

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

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

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

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

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

· Изменение хеш-функции: теперь используется полная хеш-функция SHA256, поэтому при каждом вызове необходимо вызывать два вызова базовой сжимающей функции из-за заполнения. Если мы используем сжимающую функцию SHA256, мы можем получить как минимум двукратный выигрыш. Если мы используем Poseidon, мы можем получить увеличение в 100 раз, что полностью решит все наши проблемы (по крайней мере, в отношении значений хеша): при 1700000 хешей в секунду (54 МБ) мы можем «читать» миллион проверочных записей в течение нескольких секунд.

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

· Агрегация подписей: любая высокопроизводительная схема агрегации подписей включает некоторое рекурсивное доказательство, в котором разные узлы в сети предоставляют промежуточные доказательства для подмножества подписей. Это естественным образом распределяет работу по доказательству между несколькими узлами в сети и значительно снижает нагрузку на «окончательного доказывающего».

· Другие схемы подписи: для подписи Лампорта + Меркля нам нужно 256 + 32 хэш-значений для проверки подписи; умножая на 32768 подписантов, мы получаем 9437184 хэш-значений. Оптимизируя схему подписи, можно еще больше улучшить этот результат с помощью небольшого постоянного коэффициента. Если мы используем Позейдон, это можно доказать в одном слоте. Но на самом деле, использование рекурсивной агрегационной схемы будет быстрее.

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

· Простое подтверждение Ethereum Соглашение (только для синхронных комитетов)

· Простой Helios внутри SP1

· Краткий предварительный анализ BLS12-381

· Проверка подписи на основе Halo2 BLS

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

Фактически, нам потребуется несколько лет, чтобы получить доказательство действительности Ethereum Соглашение. Это примерно совпадает со временем, необходимым для достижения одиночной заморозки, Орбита, изменения Алгоритм подписи и проведения достаточного анализа безопасности для использования таких 'радикальных' хэш-функций, как Посейдон. Поэтому самым разумным будет решить эти другие проблемы, учитывая в то же время дружелюбие STARK.

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

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

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

ссылка на оригинал