Путь к проверяемости

Основное преимущество Web3 - верифицируемость. Пользователи могут проверить, как системы фактически работают. Эта функция объясняет, почему многие внутри и вне криптоиндустрии описывают web3 как шаг к более прозрачному и верифицируемому интернету.

В отличие от платформ Web2, таких как Facebook или Instagram, где алгоритмы и правила остаются непрозрачными, даже если они задокументированы, криптопротоколы разработаны для полной аудитности. Даже если они расшарены, у вас нет возможности проверить, работает ли платформа как ожидается. Это противоположно криптопротоколам, где каждый протокол разработан для максимальной проверяемости, или по крайней мере, ожидается, что он будет таковым.

Сегодня мы рассмотрим «The Verge», раздел из недавно опубликованной Виталикомшестичастная серия о будущем Ethereum, чтобы проанализировать шаги, которые предпринимает Ethereum, чтобы достичь верифицируемости, устойчивости и масштабируемости в будущем. Под заголовком «The Verge» мы обсудим, как можно сделать блокчейн-архитектуры более верифицируемыми, инновации, которые эти изменения принесут на уровне протокола, и как они обеспечат пользователям более безопасную экосистему. Приступим!

Что означает «проверяемость»?

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

«Децентрализуйте то, что можете, проверьте остальное».

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

Сообщество Ethereum, кажется, согласуется с этой перспективой, как дорожная картавключает в себя веху (называемую “The Verge”), направленную на то, чтобы сделать Ethereum более проверяемым. Однако, прежде чем погрузиться в The Verge, нам нужно понять, какие аспекты блокчейнов должны быть проверены, и какие части являются ключевыми с точки зрения пользователей.

Блокчейны, по сути, работают как глобальные часы. В распределенной сети с примерно 10 000 компьютерами, значительное время может потребоваться для распространения транзакции от исходного узла ко всем остальным узлам. По этой причине узлы по всей сети не могут определить точный порядок транзакций - пришла ли одна до или после другой, поскольку у них есть только свое субъективное представление.

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

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

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

Если у вас есть $100 в состоянии, которое мы называем «S», и вы хотите отправить $10 кому-то еще, ваш баланс в следующем состоянии, «S+1», будет $90. Этот процесс применения транзакций для перехода из одного состояния в другое - это то, что мы называем функцией перехода состояния (STF).

В Bitcoin STF в основном ограничивается изменениями баланса, что делает его относительно простым. Однако, в отличие от Bitcoin, STF Ethereum намного сложнее, потому что Ethereum является полностью программируемым блокчейном с исполнительным слоем, способным выполнять код.

В блокчейне есть три основных компонента, которые вам нужно или можете проверить:

1. Состояние: Возможно, вы захотите прочитать кусок данных на блокчейне, но у вас нет доступа к состоянию, так как вы не запускаете полный узел. Поэтому вы запрашиваете данные через поставщика RPC (Remote Procedure Call), такого как Alchemy или Infura. Однако вы должны проверить, что данные не были изменены поставщиком RPC.
2. Выполнение: Как упоминалось ранее, блокчейны используют STF. Вы должны проверить, что переход состояния был выполнен правильно — не на основе отдельной транзакции, а на основе блока.
3. Консенсус: Сторонние сущности, такие как RPC, могут предоставить вам действительные блоки, которые еще не были включены в блокчейн. Таким образом, вы должны проверить, что эти блоки были приняты по консенсусу и добавлены в блокчейн.

Если это кажется запутанным или неясным, не беспокойтесь. Мы рассмотрим каждый из этих аспектов подробно. Давайте начнем с того, как проверить состояние блокчейна!

Как проверить состояние блокчейна?

“Состояние” Ethereum относится к набору данных, хранящихся в блокчейне в любой момент времени. Сюда входят балансы счетов (контрактные счета и счета, принадлежащие внешним участникам или ВУС), код умных контрактов, хранилище контрактов и многое другое. Ethereum является машиной, основанной на состоянии, потому что транзакции, обрабатываемые виртуальной машиной Ethereum (EVM), изменяют предыдущее состояние и создают новое состояние.

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

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

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

1. Детерминизм: одинаковый ввод всегда будет давать одинаковый вывод.
2. Фиксированная длина вывода: Независимо от длины входных данных, длина вывода всегда фиксирована.
3. Одностороннее свойство: Практически невозможно вывести исходный ввод из выходных данных.
4. Уникальность: Даже небольшое изменение ввода приводит к совершенно другому результату. Таким образом, определенный ввод отображается на практически уникальный вывод.

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

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

Поскольку состояние Ethereum имеет размер в терабайтах, непрактично хранить всё состояние на повседневных устройствах, таких как телефоны или персональные компьютеры. По этой причине Ethereum использует структуру дерева Меркля для вычисления stateRoot, сохраняя возможность проверки состояния настолько, насколько это возможно.

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

1. Листовые узлы: Эти узлы содержат хеши отдельных фрагментов данных и находятся на нижнем уровне дерева. Каждый листовой узел представляет собой хеш конкретного фрагмента данных в дереве Меркля.
2. Узлы ветви: Эти узлы содержат объединенные хеши своих дочерних узлов. Например, в бинарном дереве Меркля (где N=2) хеши двух дочерних узлов конкатенируются и снова хешируются для получения хеша узла ветви на более высоком уровне.
3. Корневой узел: корневой узел находится на самом верхнем уровне дерева Меркля и представляет собой криптографическое резюме всего дерева. Этот узел используется для проверки целостности и правильности всех данных внутри дерева.

Если вы задаетесь вопросом, как построить такое дерево, здесь всего лишь два простых шага:

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

• Комбинирование и хеширование: Хеши листовых узлов группируются (например, попарно) и комбинируются, а затем происходит хеширование. Этот процесс создает ветвистые узлы на следующем уровне. Тот же процесс повторяется для ветвистых узлов, пока не останется только один хеш.

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

Как мы используем деревья Меркла для проверки состояния Ethereum?

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

Начиная с конкретной точки данных, Верификатор объединяет ее с каждым «родственным» хешем, предоставленным в доказательстве Меркля, и последовательно хеширует их вверх по дереву. Этот процесс продолжается до тех пор, пока не будет получен один хеш. Если этот вычисленный хеш совпадает с сохраненным Корнем Меркля, данные считаются действительными; в противном случае, Верификатор может определить, что данные не соответствуют заявленному состоянию.

Пример: проверка точки данных с помощью доказательства Меркла

Предположим, что мы получили данные №4 из RPC и хотим проверить их подлинность с помощью доказательства Меркля. Для этого RPC предоставит набор хеш-значений по пути, необходимому для достижения корня Меркля. Для данных 4 эти соседние хеши будут включать Хеш №3, Хеш №12 и Хеш №5678.

1. Начнем с Data 4: Сначала мы хешируем Data #4, чтобы получить Hash #4.
2. Объединяем с родственниками: затем мы объединяем Хэш # 4 с Хэш # 3 (его родственником на уровне листьев) и хэшируем их вместе, чтобы получить Хэш # 34.
3. Поднимаемся по дереву: далее мы берем Хэш №34 и объединяем его с Хэшем №12 (его соседом на следующем уровне вверх) и хешируем их, чтобы получить Хэш №1234.
4. Финальный шаг: Наконец, мы объединяем Хэш #1234 с Хэш #5678 (последний предоставленный sibling) и хешируем их вместе. Полученный хэш должен соответствовать корню Меркля (Хэш #12345678), хранящемуся в заголовке блока.

Если вычисленный корень Меркла совпадает с корнем состояния в блоке, мы подтверждаем, что Data #4 действительно действителен в этом состоянии. Если нет, мы знаем, что данные не принадлежат заявленному состоянию, что указывает на потенциальное вмешательство. Как вы можете видеть, не предоставляя хеши всех данных или требуя от Проверяющего полностью восстановить всё дерево Меркла с нуля, Доказывающий может доказать, что Data #4 существует в состоянии и не был изменен во время своего пути, используя всего лишь три хеша. Вот почему доказательства Меркла считаются эффективными.

Хотя деревья Меркля, безусловно, эффективны в обеспечении безопасной и эффективной верификации данных в больших блокчейн-системах, таких как Ethereum, они действительно достаточно эффективны? Чтобы ответить на этот вопрос, мы должны проанализировать, как производительность и размер дерева Меркля влияют на отношение Доказатель-Проверяющий.

Два ключевых фактора, влияющих на производительность дерева Меркля: ⌛

1. Фактор ветвления: Количество дочерних узлов на одну ветвь.
2. Общий размер данных: Размер набора данных, представленного в дереве.

Влияние коэффициента ветвления:

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

• Малый коэффициент ветвления (например, бинарное дерево Меркля):
  Если используется двоичное дерево Меркла (ветвление 2), размер доказательства очень мал, что делает процесс проверки более эффективным для Проверяющего. При наличии только двух ветвей на каждом узле Проверяющему нужно обрабатывать только один хеш сиблинга на уровне. Это ускоряет проверку и снижает вычислительную нагрузку. Однако уменьшение ветвления увеличивает высоту дерева, требуя больше хеширования во время построения дерева, что может быть обременительным для валидаторов.
• Больший коэффициент ветвления (например, 4):
  Больший коэффициент ветвления (например, 4) уменьшает высоту дерева, создавая более короткую и широкую структуру. Это позволяет Полным Узлам быстрее строить дерево, так как требуется меньше операций хеширования. Однако для Проверяющего это увеличивает количество хэшей-братьев, которые им необходимо обработать на каждом уровне, что приводит к большему размеру доказательства. Большее количество хэшей на каждом шаге верификации также означает более высокие вычислительные и пропускные расходы для Проверяющего, эффективно перекладывая бремя с валидаторов на верификаторов.

Влияние общего объема данных:

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

• Full Nodes должны регулярно обрабатывать и обновлять растущий набор данных, чтобы поддерживать Merkle Tree.
• В свою очередь, верификаторы должны проверять все более длинные и сложные доказательства по мере роста набора данных, что требует дополнительного времени обработки и пропускной способности.
  Увеличение размера данных увеличивает спрос как на полные узлы, так и на верификаторы, что делает более сложной эффективную масштабируемость сети.

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

Глава 2: Революционное изменение проверяемости в Ethereum - The Verge

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

С момента перехода к модели консенсуса Proof-of-Stake с помощью The Merge валидаторам Ethereum было присвоено две основные обязанности:

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

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

Первый шаг верифицируемости: состояние

Переход на деревья Verkle - ключевая часть этого процесса. Изначально The Verge сосредоточился на замене структур деревьев Меркля Ethereum деревьями Verkle. Основная причина принятия деревьев Verkle заключается в том, что деревья Меркля представляют собой значительное препятствие для верификации Ethereum. В то время как деревья Меркля и их доказательства могут эффективно работать в нормальных сценариях, их производительность катастрофически снижается в крайних сценариях.

По расчетам Виталика, средний размер доказательства составляет около 4 КБ, что звучит управляемо. Однако в крайних случаях размер доказательства может вздуться до 330 МБ. Да, вы правильно прочитали — 330 МБ.

Экстремальная неэффективность деревьев Меркля Ethereum в крайних случаях обусловлена двумя основными причинами:

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

1. Немеркелизация кода: Вместо того, чтобы включать код контракта в деревянную структуру, Ethereum просто хеширует код и использует полученное значение в качестве узла. Учитывая, что максимальный размер контракта составляет 24 КБ, такой подход накладывает значительную нагрузку для достижения полной верификации.

Размер доказательства прямо пропорционален ветвящемуся фактору. Уменьшение ветвящего фактора уменьшает размер доказательства. Чтобы решить эти проблемы и улучшить худшие сценарии, Ethereum может перейти от Hexary Trees к Binary Merkle Trees и начать применять Merkle-деревья к кодам контрактов. Если ветвящий фактор в Ethereum будет сокращен с 16 до 2, а коды контрактов также будут применены Merkle-деревья, максимальный размер доказательства может уменьшиться до 10 МБ. Хотя это значительное улучшение, важно отметить, что эта стоимость относится к проверке только одного куска данных. Даже простая транзакция, обращающаяся к нескольким кускам данных, потребует более крупных доказательств. Учитывая количество транзакций в блоке и постоянно растущее состояние Ethereum, это решение, хоть и лучше, все еще не совсем выполнимо.

Поэтому сообщество Ethereum предложило два различных решения для решения этой проблемы:

1. Деревья Веркле
2. Доказательства STARK + Бинарные деревья Меркля

Verkle Trees & Векторные обязательства

Verkle Trees, как следует из названия, являются деревянными структурами, подобными деревьям Меркля. Однако, самая значительная разница заключается в эффективности, которую они предлагают во время процессов верификации. В деревьях Меркля, если ветка содержит 16 кусков данных, и мы хотим проверить только один из них, необходимо также предоставить хеш-цепочку, охватывающую остальные 15 кусков. Это значительно увеличивает вычислительную нагрузку на проверку и приводит к большим размерам доказательств.

В отличие от этого, деревья Verkle используют специализированную структуру, известную как “Векторные обязательства на основе эллиптических кривых”, более конкретно, обязательства на основе аргумента внутреннего произведения (IPA) - векторные обязательства. Вектор - это в основном список элементов данных, организованных в определенной последовательности. Состояние Ethereum можно рассматривать как вектор: структуру, в которой хранится множество данных в определенном порядке, причем каждый элемент является важным. Это состояние включает различные компоненты данных, такие как адреса, коды контрактов и информация о хранении, где порядок этих элементов играет важную роль в доступе и проверке.

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

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

• Векторные обязательства на основе эллиптических кривых устраняют необходимость в деталях элементов, отличных от данных, подлежащих проверке. В деревьях Меркля с коэффициентом ветвления 16 для проверки одной ветви требуется предоставить остальные 15 хэшей. Учитывая огромный размер состояния Ethereum, включающего множество ветвей, это создает значительную неэффективность. Однако векторные обязательства на основе эллиптических кривых устраняют эту сложность, позволяя проводить проверку с меньшим объемом данных и вычислительных усилий.
• Через мульти-доказательства, доказательства, сгенерированные на основе эллиптических кривых векторных обязательств, могут быть сжаты в одно постоянного размера доказательство. Состояние Ethereum не только большое, но и постоянно растущее, что означает, что количество ветвей, которые требуют верификации для доступа к корню Меркля, увеличивается со временем. Однако с помощью деревьев Verkle мы можем ‘сжать’ доказательства для каждой ветви в одно постоянного размера, используя метод, описанный в Статья Dankrad Feist. Это позволяет Проверяющим подтвердить весь дерево с помощью одного небольшого доказательства вместо проверки каждой ветви отдельно. Это также означает, что Деревья Веркле не затрагиваются ростом состояния Ethereum.

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

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

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

Доказательства STARK + Бинарные деревья Меркля

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

В процессе верификации состояния Ethereum ветвящийся фактор деревьев Меркля может быть уменьшен (с 16 до 2) с помощью бинарных деревьев Меркля. Это изменение является критическим шагом для уменьшения размеров доказательств и повышения эффективности процессов верификации. Однако, даже в худшем случае размеры доказательств все еще могут достигать 10 МБ, что является значительным. Здесь на сцену выходят STARK доказательства, сжимающие эти большие бинарные доказательства Меркля до всего лишь 100-300 кБ.

Эта оптимизация особенно важна, если учесть ограничения при работе валидаторов на легких клиентах или устройствах с ограниченным аппаратным обеспечением, особенно если учесть, что средняя скорость загрузки и выгрузки мобильных данных в мире составляет примерно 7,625 МБ/с и 1,5 МБ/с соответственно. Пользователи могут проверять транзакции с помощью маленьких, портативных доказательств, не требуя доступа к полному состоянию, а валидаторы могут выполнять задачи проверки блоков без сохранения полного состояния.

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

Основные проблемы для доказательств STARK:

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

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

Квантовая безопасность имеет свою цену: вычислительная нагрузка со стороны доказателя

Доказательство Меркля блока может содержать примерно 330 000 хэшей, а в крайних случаях это число может достигать 660 000. В таких случаях доказательство STARK должно обрабатывать около 200 000 хэшей в секунду.

Именно здесь в игру вступают zk-дружественные хеш-функции, такие как Poseidon, специально оптимизированные для доказательств STARK, чтобы снизить эту нагрузку. Poseidon разработан для более эффективной работы с ZK-доказательствами по сравнению с традиционными алгоритмами хеширования, такими как SHA256 и Keccak. Основная причина такой совместимости заключается в том, как работают традиционные алгоритмы хеширования: они обрабатывают входные данные в виде двоичных данных (0 и 1). С другой стороны, ZK-доказательства работают с простыми полями, математическими структурами, которые принципиально отличаются. Эта ситуация аналогична компьютерам, работающим в двоичной системе, в то время как люди используют десятичную систему в повседневной жизни. Перевод битовых данных в ZK-совместимые форматы требует значительных вычислительных затрат. Poseidon решает эту проблему, изначально работая в простых полях, что значительно ускоряет его интеграцию с ZK-доказательствами.

Однако, поскольку Poseidon является относительно новой хеш-функцией, требуется более обширный анализ безопасности, чтобы установить тот же уровень доверия, что и у традиционных хеш-функций, таких как SHA256 и Keccak. В этом отношении, инициативы, такие как gate,Инициатива по криптоанализу Посейдона, запущенный Ethereum Foundation, приглашает экспертов для тщательного тестирования и анализа безопасности Poseidon, чтобы убедиться, что он может выдержать состязательную проверку и стать надежным стандартом для криптографических приложений. С другой стороны, более старые функции, такие как SHA256 и Keccak, уже были тщательно протестированы и имеют проверенную репутацию безопасности, но не являются дружественными к ZK, что приводит к падению производительности при использовании с доказательствами STARK.

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

Неэффективность STARKs в доказательстве малых данных

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

1. Проверка транзакции Post-AA: \
   С использованием абстракции учётной записи (AA) кошельки могут ссылаться на код контракта, обходя или настраивая такие этапы, как проверка nonce и подписи, которые в настоящее время являются обязательными в Ethereum. Однако эта гибкость в проверке требует проверки кода контракта или других связанных данных в состоянии для доказательства действительности транзакции.
2. RPC-запросы легкого клиента: \
   Легкие клиенты запрашивают данные состояния из сети (например, во время запроса eth_call) без запуска полной ноды. Чтобы гарантировать правильность этого состояния, доказательства должны поддерживать запрашиваемые данные и подтверждать, что они соответствуют текущему состоянию сети.
3. Списки включения: \
   Меньшие валидаторы могут использовать механизмы списка включений, чтобы гарантировать, что транзакции будут включены в следующий блок, ограничивая влияние мощных блок-продюсеров. Однако для проверки включения этих транзакций требуется проверка их правильности.

В таких случаях доказательства STARK дают мало преимущества. STARKs, акцентируя внимание на масштабируемости (как подчеркивается буквой “S” в их названии), хорошо работают с большими наборами данных, но испытывают затруднения в сценариях с небольшими данными. В отличие от них, SNARKs, разработанные для краткости (как подчеркивается буквой “S” в их названии), фокусируются на минимизации размера доказательства, предлагая очевидные преимущества в условиях с ограничениями по пропускной способности или хранению.

Доказательства STARK обычно имеют размер 40–50 KB, что примерно в 175 раз больше, чем доказательства SNARK, которые занимают всего 288 байт. Это различие в размере увеличивает как время проверки, так и сетевые затраты. Основная причина большего размера доказательств STARK заключается в их зависимости от прозрачности и полиномиальных обязательств для обеспечения масштабируемости, что вводит затраты на производительность в сценариях с малыми данными. В таких случаях более быстрые и экономичные методы, такие как доказательства Меркла, могут быть более практичными. Доказательства Меркла предлагают низкие вычислительные затраты и быстрые обновления, что делает их подходящими для таких ситуаций.

Тем не менее, доказательства STARK остаются важными для безгосударственного будущего Ethereum из-за их квантовой безопасности.

Как указано в таблице, у Ethereum есть четыре потенциальных пути для выбора:

• Деревья Веркла
  1. Verkle Trees получили широкую поддержку со стороны сообщества Ethereum, и для содействия их развитию раз в две недели проводятся встречи. Благодаря этой последовательной работе и тестированию, Verkle Trees выделяется как наиболее зрелое и хорошо изученное решение среди существующих альтернатив. Более того, их аддитивно гомоморфные свойства устраняют необходимость пересчитывать каждую ветвь для обновления корня состояния, в отличие от деревьев Меркла, что делает деревья Веркла более эффективным вариантом. По сравнению с другими решениями, Verkle Trees делает акцент на простоте, придерживаясь инженерных принципов, таких как «не усложняй» или «проще — лучшее». Эта простота облегчает как интеграцию в Ethereum, так и анализ безопасности.
  2. Однако деревья Verkle не обладают квантовой стойкостью, что мешает им стать долгосрочным решением. Если они будут интегрированы в Ethereum, скорее всего, эту технологию потребуется заменить в будущем, когда потребуются устойчивые к квантовым вычислениям решения. Даже Виталик считает, что деревья Verkle - временное решение, чтобы выиграть время для зрелости технологий STARK и других. Кроме того, эллиптические кривые, используемые в деревьях Verkle, накладывают более высокую вычислительную нагрузку по сравнению с простыми хэш-функциями. Подходы на основе хэширования могут предложить более быстрые времена синхронизации для полных узлов. Более того, зависимость от множества 256-битных операций делает деревья Verkle более сложными для доказательства с использованием SNARKs в рамках современных систем доказательств, что усложняет усилия по сокращению размеров доказательств в будущем.

Тем не менее, важно отметить, что деревья Verkle, благодаря отсутствию зависимости от хеширования, значительно более доказуемы, чем деревья Меркла.

• STARKs + Консервативные хэш-функции
  1. Комбинирование STARK с проверенными консервативными хэш-функциями, такими как SHA256 или BLAKE, обеспечивает надежное решение, которое укрепляет инфраструктуру безопасности Ethereum. Эти хэш-функции широко используются и тщательно тестируются как в академической, так и в практической областях. Кроме того, их квантовая стойкость повышает устойчивость Ethereum к будущим угрозам, представляемым квантовыми компьютерами. Для критических сценариев безопасности эта комбинация предлагает надежный фундамент.
  2. Однако использование консервативных хеш-функций в системах STARK вводит существенные ограничения производительности. Вычислительные требования этих хеш-функций приводят к высокой задержке проверяющего, при генерации доказательства занимает более 10 секунд. Это является основным недостатком, особенно в сценариях, требующих низкой задержки, например, при проверке блока. В то время как усилия, направленные на многомерные предложения по газу, пытаются согласовать наихудший и средний случай задержки, результаты ограничены. Кроме того, хотя хеш-функции могут облегчить более быстрые времена синхронизации, их эффективность может не соответствовать широким целям масштабируемости STARKs. Длительное время вычислений традиционных хеш-функций снижает практическую эффективность и ограничивает их применимость.
• STARKs + Относительно новые хэш-функции
  1. STARKs, совмещенные с хэш-функциями нового поколения, дружественными к STARK (например, Poseidon), значительно улучшают производительность этой технологии. Эти хэш-функции разработаны для интеграции без проблем с системами STARK и радикально сокращают задержку доказательства. В отличие от традиционных хэш-функций, они позволяют генерировать доказательства всего за 1-2 секунды. Их эффективность и низкая вычислительная нагрузка улучшают потенциал масштабируемости STARK, делая их очень эффективными для работы с большими наборами данных. Эта возможность делает их особенно привлекательными для приложений, требующих высокой производительности.
  2. Однако относительная новизна этих хеш-функций требует обширного анализа безопасности и тестирования. Отсутствие комплексного тестирования вносит риски при рассмотрении их внедрения в критические экосистемы, такие как Ethereum. Кроме того, поскольку эти хеш-функции еще не получили широкого распространения, необходимые процессы тестирования и проверки могут замедлить достижение целей по верификации Ethereum. Время, необходимое для полной обеспеченности их безопасностью, может сделать этот вариант менее привлекательным в краткосрочной перспективе, что потенциально отложит масштабируемость и амбиции по верификации Ethereum.
• Деревья Меркля на основе решеток
  1. Деревья Меркля на основе решетки предлагают перспективное решение, которое сочетает квантовую безопасность с эффективностью обновления деревьев Verkle. Эти структуры решают слабые места как деревьев Verkle, так и STARKs и считаются многообещающим долгосрочным вариантом. Благодаря своему дизайну на основе решетки, они обеспечивают сильное сопротивление угрозам квантовых вычислений, соответствуя фокусу Ethereum на обеспечение будущего своей экосистемы. Более того, сохраняя преимущества обновляемости деревьев Verkle, они стремятся обеспечить улучшенную безопасность, не жертвуя эффективностью.
  2. Однако исследования, касающиеся деревьев Меркля на основе решеток, все еще находятся на начальных этапах и в основном имеют теоретическую основу. Это создает значительные неопределенности относительно их практической реализации и производительности. Интеграция такого решения в Ethereum потребовала бы обширных исследований и разработки, а также строгого тестирования для подтверждения его потенциальных преимуществ. Эти неопределенности и инфраструктурные сложности делают маловероятным выбор деревьев Меркля на основе решеток для Ethereum в ближайшем будущем, что потенциально замедлит прогресс в направлении целей по верификации сети.

Что насчет выполнения: Доказательства действительности выполнения EVM

Все, что мы обсуждали до сих пор, вращается вокруг устранения необходимости для валидаторов хранить предыдущее состояние, которое они используют для перехода из одного состояния в другое. Цель состоит в том, чтобы создать более децентрализованную среду, в которой валидаторы смогут выполнять свои обязанности, не поддерживая терабайты данных о состоянии. Даже с упомянутыми нами решениями валидаторам не нужно будет хранить все состояние, так как они будут получать все данные, необходимые для выполнения, через следящие серверы, включенные в блок. Тем не менее, чтобы перейти к следующему состоянию и, таким образом, проверить stateRoot поверх блока, валидаторы по-прежнему должны сами выполнять STF. Это требование, в свою очередь, создает еще один вызов для природы и децентрализации Ethereum.

Изначально The Verge задумывался как веха, которая сосредотачивалась исключительно на переходе от Merkle Trees к Verkle Trees для улучшения проверяемости состояния Ethereum. Однако со временем это стало более общей инициативой, направленной на улучшение проверяемости переходов состояния и консенсуса. В мире, где трио Состояние, Выполнение и Консенсус полностью проверяемо, валидаторы Ethereum могут работать на практически любом устройстве с подключением к Интернету, которое можно отнести к Light Client. Это приблизило бы Ethereum к достижению своей цели «истинной децентрализации».

Каково определение проблемы?

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

Высокие требования к системе для становления валидатором в основном обусловлены необходимостью эффективного выполнения этого процесса.

Если вы хотите превратить умный холодильник, да даже обычный холодильник, в валидатор Ethereum с помощью установленного программного обеспечения, вы столкнетесь с двумя основными препятствиями:

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

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

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

Корень состояния в предыдущем блоке = S, Корень состояния в следующем блоке = S + 1, Хэш блока = H

1. Сам блок должен быть действителен, а доказательство состояния внутри него - будь то доказательство Verkle или STARKs - должно точно подтверждать данные, сопровождающие блок.
   Коротко: Проверка блока и сопровождающего доказательства состояния.
2. Когда STF выполняется с использованием требуемых для выполнения данных и включается в блок, соответствующий H, данные, которые должны измениться в состоянии, должны быть правильно обновлены.
   Короче говоря: Подтверждение перехода состояния.
3. Когда новое дерево состояний перестраивается с правильно обновленными данными, его корневое значение должно совпадать с S + 1.
   В двух словах: Проверка процесса построения дерева.

В аналогии доказательства-проверки, на которую мы ранее ссылались, можно сказать, что обычно существует вычислительный баланс между двумя участниками. Возможность предоставления доказательств, необходимых для того, чтобы сделать STF проверяемым и проверить несколько вещей одновременно, предлагает значительные преимущества для Проверяющего, но также указывает на то, что создание таких доказательств для обеспечения корректности выполнения будет относительно сложной задачей для Доказывающего. При текущей скорости Ethereum для доказательства блока Ethereum требуется менее 4 секунд. Однако даже самый быстрый доказыватель EVM сегодня может доказать средний блок примерно за 15 секунд.[1]

Это сказано, что у нас есть три различных пути, которые мы можем выбрать, чтобы преодолеть этот большой вызов:

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

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

1. Использование оптимизированных доказательственных систем: Доказательственные системы нового поколения имеют потенциал сделать вычислительные процессы Ethereum более быстрыми и эффективными. Продвинутые системы, такие как Orion, Binius, и GKRможет значительно сократить время подтверждения для вычислений общего назначения. Эти системы стремятся преодолеть ограничения существующих технологий, увеличивая скорость обработки при потреблении меньших ресурсов. Для сети, ориентированной на масштабируемость и эффективность, такие оптимизации обеспечивают значительное преимущество. Однако полная реализация этих новых систем требует комплексного тестирования и усилий по обеспечению совместимости в экосистеме.
2. Изменения стоимости газа: Исторически стоимость газа для операций на виртуальной машине Ethereum (EVM) обычно определялась на основе их вычислительной сложности. Однако сегодня получила большее значение другая метрика: сложность проверки. В то время как некоторые операции относительно легко поддаются доказательству, другие имеют более сложную структуру и требуют большего времени для проверки. Регулирование стоимости газа не только на основе вычислительных затрат, но и на основе сложности проверки операций является важным для повышения безопасности и эффективности сети.

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

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

С другой стороны, специализированные схемы (например, ASIC, FPGA, GPU), разработанные специально для определенных задач, имеют значительный потенциал для ускорения процесса генерации доказательства. Эти решения обеспечивают гораздо большую эффективность по сравнению с традиционным оборудованием и могут ускорить процессы выполнения. Однако децентрализационные цели Ethereum на уровне Layer 1 мешают доступу к такому оборудованию только определенной группе участников. В результате ожидается, что эти решения будут использоваться более широко в системах Layer 2. Тем не менее, сообщество также должно достичь консенсуса относительно требований к аппаратному обеспечению для генерации доказательства. Возникает ключевой вопрос проектирования: должна ли генерация доказательства работать на оборудовании потребительского класса, таком как ноутбуки высокого уровня, или требовать промышленной инфраструктуры? Ответ формирует всю архитектуру Ethereum, позволяя агрессивную оптимизацию для решений Layer 2, требуя более консервативных подходов для Layer 1.

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

Последний шаг к истинной полной проверяемости: Консенсус

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

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

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

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

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

Протокол легкого клиента Altair: Комитет синхронизации

Комитет синхронизации - это механизм, введенный в рамках обновления Altair, чтобы преодолеть ограничения вероятностного консенсуса Ethereum и улучшить проверяемость цепи для легких клиентов. Комитет состоит из 512 случайно выбранных валидаторов, которые служат в течение 256 эпох (~27 часов). Эти валидаторы производят подпись, представляющую голову цепи, позволяя легким клиентам проверить допустимость цепи без необходимости загрузки исторических данных цепи. Работу Комитета синхронизации можно проиллюстрировать следующим образом:

1. Формирование Комитета:
   Из всех валидаторов в сети случайным образом выбирается 512 валидаторов. Этот выбор регулярно обновляется для поддержания децентрализации и предотвращения зависимости от конкретной группы.
2. Генерация подписи:
   Участники комитета создают подпись, которая представляет последнее состояние цепочки. Эта подпись является коллективной подписью BLS, созданной участниками, и используется для проверки достоверности цепочки.
3. Проверка легкого клиента:
   Легкие клиенты могут проверить правильность цепи, просто проверив подпись от комитета синхронизации. Это позволяет им безопасно отслеживать цепь без загрузки прошлых данных цепи.

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

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

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

Из-за этих ограничений в экосистеме Ethereum продолжаются усилия по переработке механизма консенсуса и внедрению решений, которые обеспечивают детерминированную окончательность в более короткие сроки. Предложения, подобные Orbit-SSFи3SFцель - перестроить структуру консенсуса Ethereum с нуля, создав более эффективную систему для замены вероятностного консенсуса. Такие подходы стремятся не только сократить время окончательного подтверждения цепочки, но и создать более эффективную и проверяемую сетевую структуру. Сообщество Ethereum продолжает активно разрабатывать и готовить эти предложения для будущей реализации.

Снаркификация консенсуса

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

• ECADDs:
  • Назначение: Эта операция используется для агрегации открытых ключей валидаторов и является важной для обеспечения точности и эффективности цепочки. Благодаря возможности агрегации подписей BLS несколько подписей можно объединить в одну структуру. Это снижает накладные расходы на коммуникацию и делает процессы проверки на цепочке более эффективными. Обеспечение более эффективной синхронизации среди больших групп валидаторов делает эту операцию критической.
  • Ограничения: Как уже упоминалось ранее, валидаторы Ethereum голосуют за порядок цепочки во время эпох. На сегодняшний день Ethereum является сетью с примерно 1,1 миллиона валидаторов. Если все валидаторы попытаются одновременно распространить свои голоса, это создаст значительную нагрузку на сеть. Чтобы избежать этого, Ethereum позволяет валидаторам голосовать на основе слотов во время эпохи, где только 1/32 всех валидаторов голосуют за каждый слот. Хотя этот механизм снижает нагрузку на сеть и делает консенсус более эффективным, с учетом текущего количества валидаторов примерно 34 000 валидаторов голосуют в каждом слоте. Это примерно 34 000 операций ECADD на каждый слот.
• Пары:
  • Назначение: Операции сопряжения используются для проверки BLS-подписей, обеспечивая действительность эпох на цепи. Эта операция позволяет проводить пакетную проверку подписей. Однако она не является дружественной к zk, что делает ее использование с zk-proof технологиями чрезвычайно дорогостоящим. Это представляет собой основной вызов при создании интегрированного процесса верификации с технологиями нулевого разглашения.
  • Проблемы: Сопряжение операций в Ethereum ограничено максимумом в 128 утверждений (агрегированных подписей) на слот, что приводит к меньшему количеству сопряжений по сравнению с ECADDs. Однако, отсутствие поддержки zk-дружественности в этих операциях представляет существенную проблему. Доказательство операции сопряжения с zk-доказательствами обходится в тысячи раз дороже, чем доказательство операции ECADD [2]. Это делает адаптацию операций сопряжения для технологий с нулевым разглашением одним из величайших препятствий в процессах проверки консенсуса Ethereum.
• SHA256 Hashes:
  • Цель: Хеш-функции SHA256 используются для чтения и обновления состояния цепи, обеспечивая целостность данных цепи. Однако их незнание zk-дружественности приводит к неэффективности процессов проверки на основе zk-доказательств, что ставит серьезное препятствие перед целями Ethereum по достижению будущей верифицируемости.
  • Проблемы: Функции хеширования SHA256 часто используются для чтения и обновления состояния цепи. Однако их незнакомство с zk-дружелюбием конфликтует с целями верификации на основе zk-доказательств в Ethereum. Например, между двумя эпохами каждый валидатор запускает STF Консенсусного уровня Ethereum для обновления состояния с наградами и штрафами на основе производительности валидатора во время эпохи. Этот процесс сильно зависит от функций хеширования SHA256, что значительно увеличивает затраты в системах на основе zk-доказательств. Это создает существенное препятствие для согласования механизма консенсуса Ethereum с zk-технологиями.

Операции ECADD, Pairing и SHA256, используемые в текущем слое консенсуса, играют критическую роль в целях проверяемости Ethereum. Однако их недостаточная дружественность к zk создает значительные препятствия на пути к достижению этих целей. Операции ECADD создают дорогостоящее бремя из-за большого объема голосов валидаторов, в то время как операции Pairing, несмотря на то, что их количество меньше, тысячу раз дороже доказывать с помощью zk-доказательств. Кроме того, недружественность к zk функций хеширования SHA256 делает крайне сложным доказательство перехода состояния цепочки маяка. Эти проблемы подчеркивают необходимость комплексного преобразования для выравнивания существующей инфраструктуры Ethereum с технологиями нулевого знания.

Решение «Beam Chain»: Переосмысление слоя консенсуса Ethereum

12 ноября 2024 года, во время своей презентации на Devcon, Джастин Дрейк представил предложение под названием «Beam Chain», направленное на фундаментальное и всестороннее преобразование Консенсусного слоя Ethereum. Бикон Чейн является основой сети Ethereum уже почти пять лет. Однако за это время в Бикон Чейн не произошло серьезных структурных изменений. В отличие от этого, технологические достижения продолжают стремительно развиваться, превосходя статичность Бикон Чейна.

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

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

В этом разделе мы подробно рассмотрели Консенсус, Состояние и Шаги выполнения The Verge, и одной из наиболее ярких проблем, выделенных в ходе этого процесса, является использование хэширующей функции SHA256 в Ethereum’s Beacon Chain. В то время как SHA256 играет центральную роль в обеспечении безопасности сети и обработке транзакций, его низкая дружественность к zk представляет собой значительное препятствие для достижения целей верификации Ethereum. Его высокая вычислительная стоимость и несовместимость с zk технологиями делают его критической проблемой, которую необходимо решить в будущих разработках Ethereum.

Дорожная карта Джастина Дрейка, представленная во время его выступления на Devcon, предусматривает замену SHA256 в Beacon Chain на дружественные к zk-функции хеширования, такие как Poseidon. Это предложение направлено на современный слой консенсуса Ethereum, делая его более проверяемым, эффективным и согласованным с технологиями zk-proof.

В этом контексте мы видим, что Ethereum сталкивается не только с вызовами от недружественных zk-хэш-функций, но также нужно переоценить используемые в своем уровне консенсуса цифровые подписи для обеспечения долгосрочной безопасности. С развитием квантовых вычислений алгоритмы цифровой подписи, такие как ECDSA, которые в настоящее время используются, могут столкнуться с серьезными угрозами. Как отмечено в рекомендациях, опубликованных NIST, варианты ECDSA с уровнем безопасности 112 бит будут устаревать к 2030 году и полностью запрещены к 2035 году. Это обуславливает необходимость перехода Ethereum и подобных сетей на более устойчивые альтернативы, такие как квантово-стойкие подписи в будущем.

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

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

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

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

Заключительные заметки и вывод

Путь Ethereum к верифицируемости представляет собой фундаментальный сдвиг в технологии блокчейна. Инициатива Verge решает основные неэффективности через деревья Verkle для проверки состояния и доказательства STARK для масштабируемых переходов.

Один из самых амбициозных предложений - это Beam Chain, всесторонний пересмотр консенсусного слоя Ethereum. Решая ограничения Beacon Chain и включая альтернативы, дружественные zk, такой подход стремится улучшить масштабируемость Ethereum, сохраняя его основные принципы децентрализации и доступности. Однако этот переход также подчеркивает проблемы, с которыми сталкивается Ethereum при балансировке вычислительных требований с целью поддержания сети без разрешения и включения.

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

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

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

То, что отличает Ethereum, не только его технические инновации, но и итерационный подход к решению некоторых сложнейших проблем в блокчейне. Путь вперед, будь то через технологии типа Beam Chain, Verkle Trees или STARK proofs, зависит от совместных усилий разработчиков, исследователей и широкого сообщества. Эти достижения не сводятся к достижению совершенства за одну ночь, а к созданию основы для прозрачного, децентрализованного и верифицируемого интернета.

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

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

1. Эта статья перепечатана из[[](https://research.2077.xyz/the-verge-making-ethereum-verifiable-and-sustainable#the-path-to-verifiability)[2077 Исследование](https://research.2077.xyz/)\]. All copyrights belong to the original author [Koray Akpinarr]. Если у вас есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Переводы статей на другие языки выполняются командой Gate Learn. Копирование, распространение или плагиат переведенных статей запрещены, если не указано иное.