Виталик: как концепция многоклиентности Ethereum будет взаимодействовать с ZK-EVM?

Исходный заголовок：Какмногофункциональнаяфилософия Ethereum будет взаимодействовать с ZK-EVM?

Исходный автор: Виталик Бутерин

Перевод: Цяньвэнь, ChainCatcher

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

Каждый узел Ethereum запускает клиент консенсуса и клиент исполнения. На данный момент ни один клиент консенсуса или исполнения не занимает более 2/3 сети. Если клиент с долей менее 1/3 в своей категории ошибается, сеть будет продолжать нормально работать. Если клиент, занимающий от 1/3 до 2/3 доли в своей категории (например, Prysm, Lighthouse или Geth), ошибается, цепочка продолжит добавлять блоки, но она остановит окончательное подтверждение блоков, давая разработчикам время для вмешательства.

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

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

Каковы были первоначальные мотивы многофункциональной клиентской философии Ethereum?

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

Техническая децентрализация

Основное преимущество технической децентрализации очень простое: оно снижает риск полного краха всей сети из-за одной ошибки в программном обеспечении. Исторический случай, иллюстрирующий этот риск, — это уязвимость переполнения Bitcoin в 2010 году. В то время код клиента Bitcoin не проверял, не переполняется ли сумма выходов транзакций (переполнение, когда сумма превышает максимальное целое число 264-1 и обнуляется), поэтому кто-то провел переполненную транзакцию, получив миллиарды биткойнов. Эта ошибка была обнаружена в течение нескольких часов, и исправление было спешно развернуто по всей сети; если бы тогда существовала зрелая экосистема, эти токены были бы приняты биржами, мостами и другими учреждениями, и злоумышленник мог бы сбежать с деньгами. Но если бы тогда существовало пять разных клиентов Bitcoin, вероятность того, что все они имели бы одну и ту же уязвимость, была бы очень мала, и это привело бы к немедленному расколу, при этом сторона с уязвимостью могла бы потерпеть поражение.

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

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

Конечно, я не согласен с этим анализом, потому что (1) также следует учитывать катастрофическую уязвимость 2010 года, которая была очень серьезной; (2) ситуация с одним клиентом на самом деле никогда не существовала. Это было наиболее очевидно в случае с разветвлением Bitcoin в 2013 году: из-за расхождения между двумя различными версиями клиента Bitcoin одна из версий имела неожиданное, не задокументированное ограничение на количество изменяемых объектов в одном блоке, что привело к расколу цепочки. Таким образом, теоретический "один клиент" на практике часто оказывается двумя клиентами, а теоретические пять клиентов на практике могут быть шестью или семью клиентами — поэтому лучше выбрать правую сторону кривой риска (на рисунке выше) и иметь хотя бы несколько различных клиентов.

Политическая децентрализация

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

Внимание к политике протокола, особенно исходя из войны Bitcoin OP_RETURN 2013-14 годов, когда некоторые участники открыто поддерживали дискриминацию определенных применений цепи, стало важным фактором для раннего принятия Ethereum многофункциональной клиентской философии, чтобы избежать повторения этой ситуации. Внимание к экосистеме Ethereum — то есть избегание концентрации власти в самой Ethereum Foundation — также предоставило дополнительную поддержку в этом направлении. В 2018 году команда решила не позволять фонду реализовывать протокол Ethereum PoS (то есть нынешний "клиент консенсуса"), а полностью оставить эту задачу внешним командам.

Как ZK-EVM появится в первом уровне в будущем?

В настоящее время ZK-EVM используется в rollup: это позволяет дорогостоящему выполнению EVM происходить вне цепи несколько раз, в то время как другие просто проверяют доказательства на цепи, что вычисления EVM выполнены правильно SNARK, тем самым обеспечивая масштабируемость. Это также позволяет некоторым данным (особенно подписям) не включаться в цепь, чтобы сэкономить на комиссиях. Это приносит нам множество преимуществ в области масштабируемости, а сочетание масштабируемых вычислений с ZK-EVM и выбором доступности данных может привести к значительному увеличению масштабируемости.

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

Решение 1: Сократить первый уровень, заставив почти все действия перейти на второй уровень

Мы можем постепенно уменьшить целевую газовую нагрузку первого уровня для каждого блока с 15 миллионов до 1 миллиона, что достаточно, чтобы блок содержал один SNARK и несколько операций по депозитам и выводам, но не слишком много других операций, тем самым заставляя почти все действия пользователей перейти на протокол второго уровня. Такой дизайн все еще может поддерживать отправку множества rollup в каждом блоке: мы можем использовать внешний агрегирующий протокол, управляемый кастомизированными строителями, чтобы собрать и объединить SNARK из нескольких протоколов второго уровня. Таким образом, единственной функцией первого уровня будет служить обменным центром для второго уровня, проверяя доказательства второго уровня, время от времени способствуя крупным денежным переводам между ними.

Этот подход может сработать, но у него есть несколько важных слабостей:

1. Он фактически не может быть обратно совместимым. То есть многие существующие приложения на базе L1 станут экономически нецелесообразными. Из-за того, что комиссии становятся высокими, даже превышающими стоимость очистки этих счетов, средства пользователей могут быть заморожены на сумму до сотен или тысяч долларов. Позволение пользователям подписывать информацию для массовой миграции в протокол L2 может решить эту проблему, но это увеличивает сложность перехода. И если мы хотим добиться действительно низких затрат, необходимо реализовать некоторый SNARK на первом уровне. Когда дело касается таких вещей, как SELFDESTRU, я обычно согласен на разрушение обратной совместимости, но в этом случае я не рекомендую отказываться от обратной совместимости.

2. Затраты на проверку не снизятся значительно. В идеале протокол Ethereum должен быть легко проверяемым, не только на ноутбуках, но и на мобильных телефонах, браузерных плагинах и даже на других цепях. Первоначальная синхронизация цепи или синхронизация после длительного отключения также должна быть легкой. Узел на ноутбуке может проверить 1 миллион газа за примерно 20 миллисекунд, но даже в этом случае это означает, что после дня оффлайна потребуется 54 секунды для синхронизации (при условии, что конечность одного слота увеличивается до 32 секунд), а для мобильного телефона или браузерного плагина каждый блок потребует несколько сотен миллисекунд, что может все еще привести к значительному расходу батареи. Эти цифры хотя и управляемы, но не соответствуют нашим идеальным ожиданиям.

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

Таким образом, использование ZK-SNARK для проверки первого уровня кажется более разумным.

Решение 2: SNARK-проверка первого уровня

ZK-EVM типа 1 (полностью эквивалентный Ethereum) может быть использован для проверки выполнения EVM блоков Ethereum (первый уровень). Мы можем написать больше кода SNARK для проверки консенсуса блока. Это будет сложной инженерной задачей: в настоящее время ZK-EVM требуется от нескольких минут до нескольких часов для проверки блоков Ethereum, а генерация доказательств в реальном времени потребует одного или нескольких (i) улучшений для самого Ethereum, чтобы устранить компоненты, не совместимые с SNARK, (ii) специализированного оборудования для достижения огромных улучшений в эффективности, и (iii) архитектурных улучшений с большим параллелизмом. В настоящее время нет никаких технических причин, чтобы это не было осуществимо — поэтому я надеюсь, что, даже если это займет много лет, мы сможем это реализовать.

Здесь необходимо рассмотреть многофункциональную клиентскую парадигму: если мы хотим использовать ZK-EVM для проверки первого уровня, какой ZK-EVM мы должны использовать? Есть три варианта:

1) Один ZK-EVM: отказаться от многофункциональной модели и выбрать один единственный ZK-EVM для проверки блоков.

2) Закрытая многофункциональная ZK-EVM: достичь консенсуса по определенной группе многофункциональных ZK-EVM и в протоколе консенсуса установить, что для того, чтобы блок считался действительным, требуется доказательство от более чем половины ZK-EVM из этой группы.

3) Открытая многофункциональная ZK-EVM: разные клиенты имеют разные реализации ZK-EVM, и каждый клиент примет блок за действительный только после получения доказательства, совместимого с его реализацией.

Для меня вариант 3 является наиболее идеальным, и эта ситуация не изменится, пока наши технологии не улучшатся до такой степени, что можно будет официально доказать, что все реализации ZK-EVM эквивалентны и можно свободно выбирать наиболее эффективный вариант.

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

Реализовать вариант 3 несложно: мы можем создать p2p подсеть для каждого типа доказательства, клиенты, использующие один тип доказательства, будут слушать в соответствующей подсети и ждать получения доказательства, признанного валидатором действительным.

Два основных вызова для варианта 3 могут быть следующими:

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

2) Низкая эффективность данных: одно из преимуществ ZK-SNARK заключается в том, что данные, относящиеся только к проверке (иногда называемые "свидетельскими данными"), могут быть удалены из блока. Например, как только вы проверили подпись, вам не нужно сохранять эту подпись в блоке, вы можете просто сохранить бит, подтверждающий, что эта подпись действительна, одновременно сохраняя в блоке доказательство, подтверждающее наличие всех действительных подписей. Но если мы хотим сгенерировать несколько типов доказательств для одного блока, то оригинальные подписи должны быть фактически опубликованы.

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

Для решения проблемы эффективности данных необходимо иметь отдельный протокол для агрегирования данных, относящихся к проверке. Для подписей мы можем использовать агрегацию BLS, ERC-4337 уже поддерживает эту функцию. Другой крупной категорией данных, относящихся к проверке, являются ZK-SNARK, используемые для защиты конфиденциальности. Эти данные обычно имеют свои собственные протоколы агрегации.

Также стоит отметить, что SNARK-проверка первого уровня имеет одно важное преимущество: выполнение EVM на цепи больше не требует проверки каждым узлом, что может привести к значительному увеличению объема выполнения EVM, что можно достичь, значительно увеличив лимит газа на первом уровне или введя встроенный rollup, (enshrined rollup), или применив оба подхода.

Заключение

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

• У нас уже есть несколько мощных реализаций ZK-EVM, которые еще не являются 1 типом EVM (полностью эквивалентным Ethereum), но многие из них активно движутся в этом направлении.

• Работа над легкими клиентами (такими как Helios и Succinct) в конечном итоге может привести к более комплексной SNARK-проверке консенсуса цепи Ethereum PoS.

• Клиенты могут начать пытаться использовать ZK-EVM для самостоятельной проверки выполнения блоков Ethereum, особенно когда мы сможем реализовать безстатусные клиенты, которые технически не требуют повторного выполнения каждого блока для поддержания состояния. Мы можем медленно перейти: от проверки блоков Ethereum клиентами через повторное выполнение до проверки блоков Ethereum большинством клиентов через проверку доказательств SNARK.

• Экосистема ERC-4337 и PBS может вскоре начать использовать такие агрегирующие технологии, как BLS и агрегация доказательств, чтобы сэкономить на комиссиях. Что касается агрегации BLS, соответствующая работа также началась.

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

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

В краткосрочной перспективе все это будет непросто. ZK-EVM уже появился, но для того чтобы сделать ZK-EVM действительно жизнеспособным на первом уровне, необходимо, чтобы он стал ZK-EVM типа 1 и обеспечивал быструю, реальную проверку. С достаточной параллельностью это можно сделать, но все еще требуется много работы. Изменения консенсуса, такие как увеличение стоимости предкомпиляции KECCAK, SHA256 и других хеш-функций, также будут важной частью будущего плана. Первый шаг перехода может произойти быстрее, чем мы ожидаем: как только мы перейдем на дерево Вокера и безстатусные клиенты, клиенты могут начать постепенно использовать ZK-EVM, и переход к миру "открытых, многофункциональных ZK-EVM" может произойти автоматически.