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

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

Одним из недостаточно обсуждаемых, но, тем не менее, очень важных предстоящих изменений в способе подтверждения цепочки Ethereum является появление ZK-EVM. СНАРК, доказывающие выполнение EVM, разрабатываются уже несколько лет, и эта технология активно используется в протоколах второго уровня, называемых ZK rollups. Некоторые из этих ZK-роллапов активны в mainnet уже сегодня, а другие появятся в ближайшее время. Но в долгосрочной перспективе ZK-EVM будут использоваться не только для сворачивания; мы хотим использовать их и для проверки выполнения на первом уровне (см. также: The Verge).

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

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

Многоклиентская философия Ethereum - это один из видов децентрализации, и, как <a href="https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274"> децентрализация в целом, можно сосредоточиться либо на технических преимуществах архитектурной децентрализации, либо на социальных преимуществах политической децентрализации. В конечном счете, философия мультиклиентности была продиктована обоими и служит обоим.

Аргументы в пользу технической децентрализации

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

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

Я, конечно же, не согласен с этим анализом. Суть моего несогласия в том, что (i) катастрофические ошибки в стиле 2010 года тоже имеют значение, и (ii) на самом деле у Вас никогда не бывает только одного клиента. Последний момент наиболее наглядно продемонстрировал форк Биткойна в 2013 году: раскол цепочки произошел из-за разногласий между двумя разными версиями клиента Биткойна, одна из которых, как оказалось, случайно и недокументированно ограничивала количество объектов, которые могут быть изменены в одном блоке. Таким образом, один клиент в теории часто оказывается двумя клиентами на практике, а пять клиентов в теории могут оказаться шестью или семью клиентами на практике - поэтому мы должны просто рискнуть и пойти по правой стороне кривой риска, и иметь, по крайней мере, несколько разных клиентов.

Аргументы в пользу политической децентрализации

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

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

Как ZK-EVM будут работать на уровне 1 в будущем?

Сегодня ZK-EVM используются в рулонах. Это увеличивает масштабирование за счет того, что дорогостоящее выполнение EVM происходит всего несколько раз вне цепи, а все остальные просто проверяют SNARK, опубликованные на цепи, которые доказывают, что выполнение EVM было вычислено правильно. Это также позволяет не включать некоторые данные (в частности, подписи) в цепочку, что экономит расходы на газ. Это дает нам большие преимущества в плане масштабируемости, и сочетание масштабируемых вычислений с помощью ZK-EVM и масштабируемых данных с помощью <a href="https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling"> data availability sampling может позволить нам масштабироваться очень далеко.

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

Вариант 1: сузить слой 1, заставить почти всю активность переместиться в слой 2

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

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

• Он де-факто обратно несовместим, в том смысле, что многие существующие приложения на базе L1 становятся экономически нежизнеспособными. Средства пользователей, составляющие сотни или тысячи долларов, могут застрять, так как комиссии станут настолько высокими, что превысят затраты на опустошение этих счетов. Эту проблему можно решить, позволив пользователям подписывать сообщения о согласии на внутрипротокольный массовый переход на L2 по их выбору (см. некоторые ранние идеи реализации здесь), но это усложняет переход, а чтобы сделать его действительно достаточно дешевым, в любом случае потребуется некий SNARK на уровне 1. Я вообще сторонник нарушения обратной совместимости, когда речь идет о <a href="https://hackmd.io/@vbuterin/selfdestruct"> таких вещах, как опкод SELFDESTRUCT, но в данном случае компромисс кажется гораздо менее выгодным.
• Это может сделать верификацию недостаточно дешевой. В идеале, протокол Ethereum должен легко проверяться не только на ноутбуках, но и в телефонах, расширениях для браузеров и даже в других цепочках. Синхронизация цепочки в первый раз или после долгого пребывания в автономном режиме также должна быть простой. Ноутбук может проверить 1 миллион газов за ~20 мс, но даже это означает 54 секунды на синхронизацию после одного дня автономной работы (при условии, что <a href="https://notes.ethereum.org/@vbuterin/single_slot_finality"> single Слот finality увеличивает время работы слота до 32 с), а для телефонов или расширений для браузеров это займет несколько сотен миллисекунд на блок и, возможно, все еще будет несильно разряжать батарею. Эти цифры можно использовать, но они не идеальны.
• Даже в экосистеме, ориентированной на L2, есть свои преимущества в том, чтобы L1 был хотя бы в некоторой степени доступным. Валидиум может выиграть от более надежной модели безопасности, если пользователи смогут вывести свои средства, если заметят, что новые государственные данные больше не предоставляются. Арбитраж становится более эффективным, особенно для небольших токенов, если минимальный размер экономически выгодного прямого кросс-L2 перевода меньше.

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

Вариант 2: SNARK - проверка уровня 1

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

Здесь мы видим пересечение с парадигмой мультиклиента: если мы используем ZK-EVM для проверки уровня 1, какой 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), скорее всего, заключаются в следующем:

• Проблема задержки: злоумышленник может опубликовать блок с опозданием, вместе с доказательством, действительным для одного клиента. В реальности потребуется много времени (даже если, например, 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 и proof aggregation, чтобы сэкономить на стоимости газа. Работа над агрегированием BLS уже началась.

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

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

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

Отказ от ответственности：

1. Эта статья перепечатана с сайта[vitalik], Все авторские права принадлежат автору[vitalik]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.