Ethereum & ZK-EVM.
Как мультиклиентская концепция Ethereum будет взаимодействовать с ZK-EVM?
Одним из недооцененных, но тем не менее очень важных способов обеспечения безопасности и децентрализации Ethereum, является концепция мультиклиентности. В Ethereum намеренно нет "референс-клиента", который все используют по умолчанию.
Вместо этого существует совместно управляемая спецификация (в наши дни написанная на очень понятном человеку, но очень медленном языке - Python) и несколько команд, создающих реализации этой спецификации (также называемые "клиентами"), которые, собственно, и запускают пользователи.
На каждой ноде Ethereum работает "клиент консенсуса" и "клиент исполнения". На сегодняшний день ни один клиент консенсуса или исполнения не занимает более 2/3 сети. Если у клиента с долей менее 1/3 в своей категории обнаружится ошибка, сеть просто продолжит работу в обычном режиме.
Если клиент с долей от 1/3 до 2/3 в своей категории (например, Prysm, Lighthouse или Geth) обнаружит ошибку, то цепочка продолжит добавлять блоки, но прекратит завершение блоков, что даст разработчикам время для вмешательства в процесс.
Одним из менее обсуждаемых, но, тем не менее, очень важных предстоящих изменений в способе валидации цепи Ethereum, является появление ZK-EVM. SNARK, подтверждающие выполнение EVM, разрабатываются уже несколько лет, и эта технология активно используется протоколами второго уровня, называемыми ZK-роллапами. Некоторые из этих ZK-роллапов работают в mainnet, и много еще скоро начнут свою работу.
Но в долгосрочной перспективе ZK-EVM будут использоваться не только для роллапов. Мы хотим использовать их для проверки исполнения на первом уровне (L1).
Как только это произойдет, ZK-EVM станут де-факто третьим типом клиента Ethereum, столь же важным для безопасности сети, как сегодня клиенты исполнения и клиенты консенсуса. В связи с этим возникает вопрос: как ZK-EVM будут взаимодействовать с концепцией мультиклиентности? Одна из непростых задач решена - у нас уже есть несколько реализаций ZK-EVM, которые в настоящее время активно разрабатываются.
Но остаются другие важные моменты:
как нам на самом деле создать "мультиклиентскую" экосистему для подтверждения ZK-корректности блоков Ethereum? Этот вопрос порождает ряд интересных технических проблем - и, конечно, назревающий вопрос о том, стоят ли компромиссы того.
Какова была изначальная инициатива создания многоклиентской концепции Ethereum?
Многоклиентская концепция Ethereum - это один из видов децентрализации, и, как и в случае с децентрализацией в целом, можно сосредоточиться либо на технических преимуществах архитектуры децентрализации, либо на социальных преимуществах DeFi. В итоге концепция мультиклиентности была обусловлена и тем, и другим, и служит и тому, и другому.
Аргументы в пользу технической децентрализации.
Основное преимущество технической децентрализации просто: она снижает риск того, что одна ошибка в одной части программного обеспечения приведет к катастрофическому сбою всей сети. Исторической ситуацией, иллюстрирующей этот риск, является ошибка "переполнения" в Биткойне в 2010 году. В то время код клиента Bitcoin не проверял, чтобы сумма выходов транзакции не переполнялась (не обращалась в ноль при суммировании выше максимального целого числа), и вот некто совершил транзакцию, которая сделала именно это, выдав таким образом миллиарды биткоинов. Ошибка была обнаружена в течение нескольких часов, исправление было быстро внедрено в сеть, но если бы в то время существовала развитая экосистема, эти монеты принимались бы биржами, мостами и другими структурами, злоумышленники могли бы остаться с крупной суммой денег.
Если бы существовало пять различных клиентов Bitcoin, было бы очень маловероятно, что все они обладали одной и той же ошибкой, поэтому произошел бы немедленный сплит, и та из сторон, на которой была ошибка, скорее всего, оказалась бы в проигрыше.
В использовании многоклиентского подхода для минимизации риска появления глобальных ошибок есть компромисс: вместо этого вы получаете ошибки, связанные с нарушением консенсуса. То есть, если у вас есть два клиента, есть риск, что клиенты по-разному интерпретируют некоторые правила протокола, и хотя обе интерпретации разумны и не позволяют украсть деньги, разногласия приведут к разделению цепочки на две части. Такой случай серьезного расхождения произошел один раз в истории Ethereum (были и другие, гораздо более мелкие расхождения, когда очень небольшие части сети, работающие на старых версиях кода, разделились на две части).
Сторонники подхода с одним клиентом указывают на сбои консенсуса как на причину отказа от нескольких реализаций: если есть только один клиент, этот клиент не будет расходиться во мнениях с самим собой. Их модель того, как количество клиентов влияет на риск, может выглядеть следующим образом:
Я, конечно, не согласен с этим анализом. Суть моего несогласия в том, что (i) случай катастрофических ошибок в стиле 2010 года тоже имеет значение, и (ii) на самом деле у вас никогда не будет только одного клиента. Последнее наиболее очевидно на примере форка биткойна в 2013 году:
разделение цепочки произошло из-за разногласий между двумя разными версиями клиента биткойна, одна из которых, как оказалось, случайно и недокументированно ограничивала количество объектов, которые могут быть изменены в одном блоке.
Таким образом, один клиент в теории часто оказывается двумя клиентами на практике, а пять клиентов в теории могут оказаться шестью или семью клиентами на практике. Поэтому нам следует просто рискнуть и пойти по верному пути кривой риска, и использовать по крайней мере несколько разных клиентов.
Аргументы в пользу политики децентрализации.
Разработчики монопольных клиентов находятся в позиции с большой долей "политической власти". Если разработчик клиента предлагает изменение, а пользователи не согласны с ним, теоретически они могут отказаться загружать обновленную версию или создать форк без него, но на практике пользователям зачастую трудно это сделать.
Что, если неприятное изменение протокола сопровождается необходимым обновлением безопасности? Что делать, если основная команда угрожает уйти, если они не добьются своего?
Или, более банально, что если команда монопольного клиента окажется единственной группой с наибольшей компетенцией в протоколе, оставляя остальную часть экосистемы в невыгодном положении для восприятия технических аспектов, выдвигаемых командой клиента, и оставляя команде клиента возможность продвигать свои собственные цели и ценности, которые могут не совпадать с мнением более обширного комьюнити?
Обеспокоенность по поводу политики протокола, особенно в контексте войны за OP_RETURN в Биткойне в 2013-14 годах, когда некоторые участники открыто выступали за ограничение отдельных видов использования цепочки, стала весомым стимулом для быстрого принятия Ethereum многоклиентской концепции, которая была направлена на то, чтобы затруднить принятие подобных решений небольшой группой.
Вопросы, характерные для экосистемы Ethereum, а именно недопущение концентрации власти внутри самого Ethereum Foundation, послужили дополнительной поддержкой для этого направления. В 2018 году было принято решение о том, чтобы Фонд сознательно не делал реализацию протокола Ethereum PoS (т.е. того, что сейчас называется "клиент консенсуса"), полностью возложив эту задачу на сторонние команды.
Как будут использоваться ZK-EVM на уровне 1 в будущем?
Сегодня ZK-EVM используются в роллапах, что увеличивает масштабирование. Это позволяет выполнять дорогостоящие EVM всего лишь несколько раз вне цепи, а все остальные просто проверяют SNARK, размещенные на цепи. SNARK подтверждают, что выполнение EVM было вычислено правильно.
Это также позволяет не включать некоторые данные (в частности, подписи) в цепочку, что экономит расходы на газ. Это дает большие преимущества в масштабируемости. Сочетание масштабируемых вычислений с ZK-EVM и масштабируемых данных с выборкой доступности данных может позволить достичь серьезных результатов.
Однако у сегодняшней сети Ethereum есть другая проблема, которую никакое масштабирование второго уровня само по себе не решит: первый уровень сложно верифицировать до такой степени, что мало кто из пользователей запускает собственную ноду.
Вместо этого большинство пользователей просто доверяют сторонним провайдерам. Такие "лёгкие" клиенты, как Helios и Succinct, предпринимают определенные шаги к решению этой проблемы, но "лёгкий" клиент - это далеко не полностью верифицированная нода. "Лёгкий" клиент просто проверяет подписи случайного подмножества валидаторов, называемого комитетом синхронизации, и не проверяет, что цепочка действительно следует правилам протокола. Чтобы привести нас к такому миру, где пользователи действительно могут проверить, что цепочка соответствует установленным правилам, мы должны сделать что-то другое.
Вариант 1:
сузить слой 1, заставить почти всю активность переместиться на слой 2.
Со временем мы могли бы снизить уровень газа 1-го слоя на блок с 15 миллионов до 1 миллиона, что достаточно для того, чтобы блок содержал один SNARK и несколько операций ввода и вывода средств, но не более того. Таким образом практически вся активность пользователей переместилась на протоколы 2-го уровня.
Такая конструкция все еще может поддерживать множество роллапов, совершаемых в каждом блоке. Мы можем использовать внецепочечные агрегационные протоколы, запускаемые специализированными сборщиками, чтобы собрать SNARK из нескольких протоколов второго уровня и объединить их в один SNARK. В таком мире единственной функцией первого уровня будет clearinghouse для протоколов второго уровня.
Он будет проверять их доказательства и время от времени способствовать крупным переводам средств между ними.
Этот подход может сработать, но у него есть несколько существенных недостатков.
Он де-факто обратно несовместим, в том смысле, что многие существующие приложения на основе L1 становятся экономически нежизнеспособными. Средства пользователей, достигающие сотен или тысяч долларов, могут застрять, так как комиссии становятся настолько высокими, что превышают затраты на списание средств с этих счетов.
Эту проблему можно решить, позволив пользователям подписывать сообщения о согласии на внутрипротокольный массовый переход на L2 по их выбору, но это усложняет процесс перехода, а для того, чтобы сделать его действительно достаточно дешевым, в любом случае потребуется некий SNARK на уровне 1.
Я вообще сторонник нарушения обратной совместимости, когда речь идет о таких вещах, как опкод SELFDESTRUCT, но в данном случае компромисс кажется гораздо менее выгодным.
Возможно, это все еще не сделает верификацию достаточно дешевой. В идеале протокол Ethereum должен легко верифицироваться не только на ноутбуках, но и в телефонах, расширениях браузеров и даже в других цепочках. Синхронизация цепи в первый раз или после длительного пребывания в автономном режиме также должна быть легкой.
Нода на ноутбуке может проверить 1 миллион газов за ~20 мс, но даже это означает 54 секунды для синхронизации после одного дня автономной работы (если предположить, что финализация одного слота увеличивает время слота до 32 с), а для телефонов или браузерных расширений это займет несколько сотен миллисекунд на блок и, возможно, еще больше разрядит батарею. С этими цифрами можно работать, но они не идеальны.
Даже в экосистеме, ориентированной на L2, есть польза от того, что L1 хотя бы в некоторой степени доступен. Валидиумы могут выиграть от более сильной модели безопасности, если пользователи смогут вывести свои средства, заметив, что новые данные о состоянии больше не предоставляются.
Арбитраж становится более эффективным, особенно для мелких токенов, если минимальный размер экономически выгодного прямого перевода через L2 меньше.
Следовательно, кажется более разумным попытаться найти способ использовать ZK-SNARK для верификации L1.
ZK-EVM типа 1 (полностью эквивалентный Ethereum) можно использовать для проверки выполнения EVM блока (уровня 1) Ethereum. Мы могли бы написать больше кода SNARK, чтобы также проверить консенсусную сторону блока. Это было бы сложной инженерной задачей.
Сегодня ZK-EVM требуется от нескольких минут до нескольких часов для проверки блоков Ethereum, а для генерации доказательств в реальном времени потребуется одно или несколько из (i) усовершенствований самого Ethereum для удаления компонентов, недружественных к SNARK; (ii) значительного повышения эффективности с помощью специализированного оборудования; и (iii) архитектурных усовершенствований с гораздо большим распараллеливанием.
Однако нет никаких фундаментальных технологических причин, почему это невозможно сделать, и поэтому я ожидаю, что даже если на это уйдет много лет, это будет сделано.
Здесь мы видим пересечение с парадигмой многоклиентности: если мы используем ZK-EVMs для проверки уровня 1, какой ZK-EVM мы используем?
Единый ZK-EVM: отказаться от парадигмы нескольких клиентов и выбрать один ZK-EVM, который мы используем для верификации блоков.
Закрытый мульти ZK-EVM: согласовываем и закрепляем в консенсусе определенный набор из нескольких ZK-EVM, а в протоколе уровня консенсуса устанавливаем правило, что блок должен получить доказательства от более чем половины ZK-EVM из этого набора, чтобы считаться действительным.
Открытый мульти ZK-EVM: разные клиенты имеют разные реализации ZK-EVM, и каждый клиент ожидает доказательства, совместимого с его собственной реализацией, прежде чем принять блок как действительный.
На мой взгляд, (3) кажется идеальным вариантом, по крайней мере, до тех пор, пока наша технология не улучшится настолько, что мы сможем формально доказать, что все реализации ZK-EVM эквивалентны друг другу, и тогда мы сможем просто выбрать ту, которая будет наиболее эффективной. (1) придется пожертвовать преимуществами многоклиентной парадигмы, а (2) закроет возможность разработки новых клиентов и приведет к более централизованной экосистеме. (3) сопряжен с трудностями, но эти трудности кажутся не столь значительными, как трудности двух других вариантов, по крайней мере, в настоящее время.
Реализация (3) не будет слишком сложной: можно создать p2p-подсеть для каждого типа доказательств, а клиент, использующий один тип доказательств, будет обслуживаться в соответствующей подсети и ждать, пока не получит доказательство, которое его верификатор распознает как действительное.
Две основные проблемы, связанные с (3), скорее всего, следующие:
Проблема задержки: злонамеренная атакующая сторона может опубликовать блок с опозданием, вместе с доказательством, действительным для одного клиента. В реальности потребуется много времени (даже если, например, 15 секунд), чтобы сгенерировать доказательства, действительные для других клиентов. Этого времени будет достаточно, чтобы потенциально создать временный форк и прервать работу цепочки на несколько слотов.
Одним из преимуществ ZK-SNARK является то, что данные, имеющие отношение только к верификации (иногда называемые "данными свидетелей"), могут быть удалены из блока.
Например, после проверки подписи вам не нужно хранить подпись в блоке. Вы можете просто хранить один бит, говорящий, что подпись действительна, вместе с одним доказательством в блоке, подтверждающим, что все действительные подписи существуют. Однако, если мы хотим, чтобы для блока можно было генерировать доказательства нескольких типов, исходные подписи должны быть полностью опубликованы.
Проблему задержки можно решить, если тщательно подойти к разработке однослотового финального протокола. Однослотовые финальные протоколы, вероятно, потребуют более двух раундов консенсуса на слот. Поэтому можно потребовать, чтобы первый раунд включал блок, и только в третьем (или последнем) раунде требовать от нод проверки доказательств перед своей подписью.
Это гарантирует, что между крайним сроком публикации блока и временем, когда ожидается, что доказательства будут доступны, всегда будет оставаться достаточно времени.
Проблема эффективности данных должна быть решена путем создания отдельного протокола для агрегирования данных, связанных с проверкой. Для подписей мы могли бы использовать агрегацию BLS, которую уже поддерживает ERC-4337. Другая основная категория данных, связанных с проверкой - это ZK-SNARK, используемые для обеспечения конфиденциальности. К счастью, они обычно обладают собственными протоколами агрегации.
Стоит также отметить, что SNARK-верификация уровня 1 обладает важным преимуществом: тот факт, что выполнение EVM на цепочке больше не нужно проверять на каждой ноде, позволяет значительно увеличить количество исполняемых EVM. Это может произойти либо за счет значительного увеличения лимита газа слоя 1, либо за счет введения закрепленных роллапов, либо за счет обоих вариантов.
Для того, чтобы открытая мультиклиентская экосистема ZK-EVM хорошо работала, потребуется много работы. Но действительно хорошей новостью является то, что большая часть этой работы уже происходит или произойдет в любом случае.
У нас уже есть несколько сильных реализаций ZK-EVM. Эти реализации еще не относятся к типу 1 (полностью эквивалентному Ethereum), но многие из них активно движутся в этом направлении.
Работа над "легкими" клиентами, такими как Helios и Succinct, в конечном итоге может превратиться в более полную SNARK-верификацию консенсуса PoS в цепочке Ethereum.
Клиенты, вероятно, начнут экспериментировать с ZK-EVM для самостоятельного подтверждения выполнения блоков Ethereum, особенно когда у нас появятся клиенты без состояния и отпадет техническая необходимость в прямом повторном выполнении каждого блока для поддержания этого состояния.
Вероятно, мы получим медленный и постепенный переход от клиентов, проверяющих блоки Ethereum путем их повторного исполнения, к большинству клиентов, проверяющих блоки Ethereum путем проверки доказательств SNARK.
Экосистемы ERC-4337 и PBS, вероятно, очень скоро начнут работать с технологиями агрегации, такими как BLS и агрегация доказательств, чтобы сэкономить на стоимости газа. Работа над агрегацией BLS уже началась.
С внедрением этих технологий будущее выглядит очень хорошим. Блоки Ethereum будут меньше, чем сегодня, любой сможет запустить полностью верифицирующий узел на своем ноутбуке или даже телефоне или в расширении браузера, и все это будет происходить при сохранении преимуществ мультиклиентской философии Ethereum.
В долгосрочной перспективе, конечно, может произойти все что угодно. Возможно, искусственный интеллект усовершенствует формальную проверку до такой степени, что сможет легко доказать эквивалентность реализаций ZK-EVM и выявить все ошибки, вызывающие различия между ними.
Такой проект может быть даже чем-то действительно практичным, над чем можно начать работать уже сейчас. Если такой подход, основанный на формальной проверке, окажется успешным, то для обеспечения дальнейшей политической децентрализации протокола необходимо будет внедрить различные механизмы, возможно, в этот момент протокол будет считаться "законченным", а нормы неизменяемости станут более строгими.
Но даже если это долгосрочное будущее, открытый мультиклиентский мир ZK-EVM кажется естественным шагом, который, скорее всего, произойдет в любом случае.
В ближайшей перспективе это все еще долгий путь. ZK-EVM уже здесь, но для того, чтобы ZK-EVM стали действительно жизнеспособными на уровне 1, им необходимо стать типом 1 и сделать процесс проверки достаточно быстрым, чтобы он мог происходить в реальном времени.
При достаточном распараллеливании это вполне осуществимо, но для этого придется потрудиться. Изменения консенсуса, такие как повышение стоимости газа для прекомпиляций KECCAK, SHA256 и других хэш-функций, также будут важной частью картины.
Тем не менее, первые шаги перехода могут произойти раньше, чем мы ожидаем: как только мы перейдем на "деревья Веркле", и клиенты без статических данных постепенно начнут использовать ZK-EVM, и переход к миру "открытых мульти-ZK-EVM" может начаться сам по себе.
Оригинал здесь.
Материал переведен командой: @True_Market_Vision
