Валидиум
Валидиум — это решение для масштабирования, которое обеспечивает целостность транзакций с помощью доказательств достоверности, как и ZK-роллапы, но не хранит данные транзакций в основной сети Ethereum. Хотя доступность данных офчейн и влечет за собой компромиссы, она может привести к значительному улучшению масштабируемости (валидиумы могут обрабатывать ~9000 транзакций или более в секунду (opens in a new tab)).
Предварительные требования
Вы должны прочитать и понять наши страницы о масштабировании Эфириума и уровне 2 (l2).
Что такое валидиум?
Валидиумы — это решения для масштабирования, которые используют доступность данных и вычисления офчейн, предназначенные для повышения пропускной способности за счет обработки транзакций вне основной сети Ethereum. Как и роллапы с нулевым разглашением (ZK-роллапы), валидиумы публикуют для проверки офчейн-транзакций в Эфириуме. Это предотвращает недействительные переходы состояний и повышает гарантии безопасности цепи валидиума.
Эти «доказательства достоверности» могут быть представлены в виде ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) или ZK-STARKs (Zero-Knowledge Scalable Transparent ARgument of Knowledge). Подробнее о доказательствах с нулевым разглашением (opens in a new tab).
Средства, принадлежащие пользователям валидиума, контролируются смарт-контрактом в Эфириуме. Валидиумы предлагают почти мгновенный вывод средств, как и ZK-роллапы; как только доказательство достоверности для запроса на вывод будет проверено в Мейннете, пользователи могут вывести средства, предоставив доказательства Меркла. Доказательство Меркла подтверждает включение транзакции вывода пользователя в проверенный пакет транзакций, позволяя ончейн-контракту обработать вывод.
Однако средства пользователей валидиума могут быть заморожены, а вывод средств ограничен. Это может произойти, если менеджеры доступности данных в цепи валидиума утаивают данные состояния офчейн от пользователей. Без доступа к данным транзакций пользователи не могут вычислить доказательство Меркла, необходимое для подтверждения владения средствами и выполнения вывода.
В этом заключается главное отличие валидиумов от ZK-роллапов — их положение в спектре доступности данных. Оба решения по-разному подходят к хранению данных, что имеет последствия для безопасности и отсутствия необходимости в доверии.
Как валидиумы взаимодействуют с Эфириумом?
Валидиумы — это протоколы масштабирования, созданные поверх существующей цепи Эфириума. Хотя транзакции выполняются офчейн, цепь валидиума управляется набором смарт-контрактов, развернутых в Мейннете, включая:
-
Контракт верификатора: Контракт верификатора проверяет достоверность доказательств, представленных оператором валидиума при обновлении состояния. Сюда входят доказательства достоверности, подтверждающие правильность офчейн-транзакций, и доказательства доступности данных, подтверждающие существование данных офчейн-транзакций.
-
Главный контракт: Главный контракт хранит коммитменты состояния (корни Меркла), представленные производителями блоков, и обновляет состояние валидиума после того, как доказательство достоверности будет проверено ончейн. Этот контракт также обрабатывает депозиты и вывод средств из цепи валидиума.
Валидиумы также полагаются на основную цепь Эфириума в следующем:
Финализация расчетов
Транзакции, выполненные в валидиуме, не могут быть полностью подтверждены до тех пор, пока родительская цепь не проверит их достоверность. Все операции, проводимые в валидиуме, в конечном итоге должны пройти финализацию расчетов в Мейннете. Блокчейн Эфириума также предоставляет «гарантии финализации расчетов» для пользователей валидиума, что означает, что офчейн-транзакции не могут быть отменены или изменены после их фиксации ончейн.
Безопасность
Эфириум, выступая в качестве уровня финализации расчетов, также гарантирует достоверность переходов состояний в валидиуме. Офчейн-транзакции, выполненные в цепи валидиума, проверяются с помощью смарт-контракта на базовом уровне Эфириума.
Если ончейн-контракт верификатора сочтет доказательство недействительным, транзакции отклоняются. Это означает, что операторы должны выполнить условия достоверности, установленные протоколом Эфириума, прежде чем обновлять состояние валидиума.
Как работает валидиум?
Транзакции
Пользователи отправляют транзакции оператору — узлу, ответственному за выполнение транзакций в цепи валидиума. Некоторые валидиумы могут использовать единственного оператора для выполнения цепи или полагаться на механизм доказательства доли владения (PoS) для ротации операторов.
Оператор объединяет транзакции в пакет и отправляет его в схему доказательства для проверки. Схема доказательства принимает пакет транзакций (и другие соответствующие данные) в качестве входных данных и выдает доказательство достоверности, подтверждающее, что операции были выполнены правильно.
Коммитменты состояния
Состояние валидиума хешируется в виде дерева Меркла, корень которого хранится в главном контракте в Эфириуме. Корень Меркла, также известный как корень состояния, действует как криптографический коммитмент текущего состояния аккаунтов и балансов в валидиуме.
Для выполнения обновления состояния оператор должен вычислить новый корень состояния (после выполнения транзакций) и отправить его в ончейн-контракт. Если доказательство достоверности проходит проверку, предложенное состояние принимается, и валидиум переключается на новый корень состояния.
Депозиты и вывод средств
Пользователи переводят средства из Эфириума в валидиум, внося ETH (или любой ERC-совместимый токен) в ончейн-контракт. Контракт передает события депозита в валидиум офчейн, где на адрес пользователя зачисляется сумма, равная его депозиту. Оператор также включает эту транзакцию депозита в новый пакет.
Чтобы перевести средства обратно в Мейннет, пользователь валидиума инициирует транзакцию вывода и отправляет ее оператору, который проверяет запрос на вывод и включает его в пакет. Активы пользователя в цепи валидиума также уничтожаются, прежде чем они смогут совершить выход из системы. Как только доказательство достоверности, связанное с пакетом, будет проверено, пользователь может вызвать главный контракт, чтобы вывести остаток своего первоначального депозита.
В качестве механизма защиты от цензуры протокол валидиума позволяет пользователям выводить средства напрямую из контракта валидиума, минуя оператора. В этом случае пользователям необходимо предоставить доказательство Меркла контракту верификатора, показывающее включение аккаунта в корень состояния. Если доказательство принимается, пользователь может вызвать функцию вывода главного контракта, чтобы вывести свои средства из валидиума.
Отправка пакета
После выполнения пакета транзакций оператор отправляет соответствующее доказательство достоверности контракту верификатора и предлагает новый корень состояния главному контракту. Если доказательство действительно, главный контракт обновляет состояние валидиума и финализирует результаты транзакций в пакете.
В отличие от ZK-роллапа, производители блоков в валидиуме не обязаны публиковать данные транзакций для пакетов транзакций (только заголовки блоков). Это делает валидиум чисто офчейн-протоколом масштабирования, в отличие от «гибридных» протоколов масштабирования (т. е. уровня 2 (l2)), которые публикуют данные состояния в основной цепи Эфириума, используя данные блобов, calldata или их комбинацию.
Доступность данных
Как уже упоминалось, валидиумы используют модель доступности данных офчейн, при которой операторы хранят все данные транзакций вне основной сети Ethereum. Низкий объем ончейн-данных валидиума улучшает масштабируемость (пропускная способность не ограничена возможностями обработки данных Эфириума) и снижает комиссии для пользователей (стоимость публикации данных ончейн ниже).
Однако доступность данных офчейн представляет собой проблему: данные, необходимые для создания или проверки доказательств Меркла, могут быть недоступны. Это означает, что пользователи могут оказаться не в состоянии вывести средства из ончейн-контракта, если операторы будут действовать злонамеренно.
Различные решения валидиума пытаются решить эту проблему путем децентрализации хранения данных состояния. Это включает в себя принуждение производителей блоков отправлять базовые данные «менеджерам доступности данных», ответственным за хранение данных офчейн и предоставление их пользователям по запросу.
Менеджеры доступности данных в валидиуме подтверждают доступность данных для офчейн-транзакций путем подписания каждого пакета валидиума. Эти подписи представляют собой форму «доказательства доступности», которую ончейн-контракт верификатора проверяет перед утверждением обновлений состояния.
Валидиумы различаются по своему подходу к управлению доступностью данных. Некоторые полагаются на доверенные стороны для хранения данных состояния, в то время как другие используют для этой задачи случайно назначенных валидаторов.
Комитет доступности данных (DAC)
Чтобы гарантировать доступность данных офчейн, некоторые решения валидиума назначают группу доверенных лиц, совместно известных как комитет доступности данных (DAC), для хранения копий состояния и предоставления доказательств доступности данных. DAC проще реализовать и они требуют меньше координации, поскольку количество участников невелико.
Однако пользователи должны доверять DAC в том, что они предоставят данные, когда это необходимо (например, для генерации доказательств Меркла). Существует вероятность того, что члены комитетов доступности данных будут скомпрометированы злоумышленником (opens in a new tab), который затем сможет утаивать данные офчейн.
Подробнее о комитетах доступности данных в валидиумах (opens in a new tab).
Доступность данных с залогом
Другие валидиумы требуют от участников, которым поручено хранение офлайн-данных, стейкать (т. е. блокировать) токены в смарт-контракте, прежде чем приступить к своим обязанностям. Этот стейк служит «залогом» для гарантии честного поведения среди менеджеров доступности данных и снижает допущения о доверии. Если эти участники не смогут доказать доступность данных, залог подвергается слэшингу.
В схеме доступности данных с залогом любой может быть назначен для хранения данных офчейн после предоставления необходимого стейка. Это расширяет пул подходящих менеджеров доступности данных, уменьшая централизацию, которая влияет на комитеты доступности данных (DAC). Что еще более важно, этот подход опирается на криптоэкономические стимулы для предотвращения злонамеренной активности, что значительно безопаснее, чем назначение доверенных сторон для защиты офлайн-данных в валидиуме.
Подробнее о доступности данных с залогом в валидиумах (opens in a new tab).
Волишены и валидиум
Валидиумы предлагают множество преимуществ, но сопряжены с компромиссами (в первую очередь, с доступностью данных). Но, как и многие решения для масштабирования, валидиумы подходят для конкретных сценариев использования — именно поэтому были созданы волишены (volitions).
Волишены объединяют ZK-роллап и цепь валидиума и позволяют пользователям переключаться между двумя решениями для масштабирования. С помощью волишенов пользователи могут воспользоваться преимуществами доступности данных офчейн валидиума для определенных транзакций, сохраняя при этом свободу переключения на решение с доступностью данных ончейн (ZK-роллап) при необходимости. По сути, это дает пользователям свободу выбора компромиссов в зависимости от их уникальных обстоятельств.
Децентрализованная биржа (DEX) может предпочесть использование масштабируемой и приватной инфраструктуры валидиума для крупных сделок. Она также может использовать ZK-роллап для пользователей, которым нужны более высокие гарантии безопасности и отсутствие необходимости в доверии ZK-роллапа.
Валидиумы и совместимость с EVM
Как и ZK-роллапы, валидиумы в основном подходят для простых приложений, таких как обмен токенов и платежи. Поддержку общих вычислений и выполнения смарт-контрактов в валидиумах сложно реализовать, учитывая значительные накладные расходы на доказательство инструкций EVM в схеме доказательства с нулевым разглашением.
Некоторые проекты валидиумов пытаются обойти эту проблему путем компиляции EVM-совместимых языков (например, Solidity, Vyper) для создания пользовательского байт-кода, оптимизированного для эффективного доказательства. Недостатком этого подхода является то, что новые виртуальные машины, дружественные к доказательствам с нулевым разглашением, могут не поддерживать важные коды операций EVM, и разработчикам приходится писать непосредственно на языке высокого уровня для достижения оптимального результата. Это создает еще больше проблем: это заставляет разработчиков создавать децентрализованные приложения (dapp) с использованием совершенно нового стека разработки и нарушает совместимость с текущей инфраструктурой Эфириума.
Однако некоторые команды пытаются оптимизировать существующие коды операций EVM для схем ZK-доказательств. Это приведет к разработке виртуальной машины Эфириума с нулевым разглашением (zkEVM), EVM-совместимой виртуальной машины, которая создает доказательства для проверки правильности выполнения программы. С помощью zkEVM цепи валидиума могут выполнять смарт-контракты офчейн и отправлять доказательства достоверности для проверки офчейн-вычислений (без необходимости их повторного выполнения) в Эфириуме.
Подробнее о zkEVM (opens in a new tab).
Как валидиумы масштабируют Эфириум?
1. Хранение данных офчейн
Проекты масштабирования уровня 2 (l2), такие как оптимистичные роллапы и ZK-роллапы, обменивают бесконечную масштабируемость чистых офчейн-протоколов масштабирования (например, Плазмы) на безопасность, публикуя часть данных транзакций на уровне 1 (l1). Но это означает, что свойства масштабируемости роллапов ограничены пропускной способностью данных в основной сети Ethereum (по этой причине шардинг данных предлагает улучшить емкость хранения данных Эфириума).
Валидиумы достигают масштабируемости за счет хранения всех данных транзакций офчейн и публикуют только коммитменты состояния (и доказательства достоверности) при передаче обновлений состояния в основную цепь Эфириума. Однако наличие доказательств достоверности дает валидиумам более высокие гарантии безопасности, чем другие чистые офчейн-решения для масштабирования, включая Плазму и сайдчейны. Уменьшая объем данных, которые Эфириум должен обработать перед проверкой офчейн-транзакций, архитектура валидиума значительно увеличивает пропускную способность в Мейннете.
2. Рекурсивные доказательства
Рекурсивное доказательство — это доказательство достоверности, которое проверяет достоверность других доказательств. Эти «доказательства доказательств» генерируются путем рекурсивного агрегирования нескольких доказательств до тех пор, пока не будет создано одно окончательное доказательство, проверяющее все предыдущие доказательства. Рекурсивные доказательства масштабируют скорость обработки блокчейна за счет увеличения количества транзакций, которые могут быть проверены с помощью одного доказательства достоверности.
Обычно каждое доказательство достоверности, которое оператор валидиума отправляет в Эфириум для проверки, подтверждает целостность одного блока. В то время как одно рекурсивное доказательство может использоваться для подтверждения достоверности нескольких блоков валидиума одновременно — это возможно, поскольку схема доказательства может рекурсивно агрегировать несколько доказательств блоков в одно окончательное доказательство. Если ончейн-контракт верификатора принимает рекурсивное доказательство, все базовые блоки финализируются немедленно.
Плюсы и минусы валидиума
| Плюсы | Минусы |
|---|---|
| Доказательства достоверности обеспечивают целостность офчейн-транзакций и не позволяют операторам финализировать недействительные обновления состояния. | Создание доказательств достоверности требует специального оборудования, что создает риск централизации. |
| Повышает эффективность использования капитала для пользователей (нет задержек при выводе средств обратно в Эфириум). | Ограниченная поддержка общих вычислений/смарт-контрактов; для разработки требуются специализированные языки. |
| Не уязвимы для определенных экономических атак, с которыми сталкиваются системы на основе доказательств мошенничества в приложениях с высокой стоимостью. | Для генерации ZK-доказательств требуется высокая вычислительная мощность; нерентабельно для приложений с низкой пропускной способностью. |
| Снижает комиссии за газ для пользователей за счет того, что данные вызова не публикуются в основной сети Ethereum. | Более медленное время субъективной финальности (10-30 минут для генерации ZK-доказательства), но более быстрое достижение полной финальности, поскольку нет задержки на время оспаривания. |
| Подходит для конкретных сценариев использования, таких как торговля или блокчейн-игры, в которых приоритет отдается приватности транзакций и масштабируемости. | Пользователям может быть отказано в выводе средств, поскольку для генерации доказательств Меркла о праве собственности требуется, чтобы данные офчейн были доступны в любое время. |
| Доступность данных офчейн обеспечивает более высокий уровень пропускной способности и увеличивает масштабируемость. | Модель безопасности опирается на допущения о доверии и криптоэкономические стимулы, в отличие от ZK-роллапов, которые полагаются исключительно на криптографические механизмы безопасности. |
Использование валидиума/волишенов
Несколько проектов предоставляют реализации валидиума и волишенов, которые вы можете интегрировать в свои децентрализованные приложения (dapp):
StarkWare StarkEx — StarkEx — это решение для масштабирования уровня 2 (l2) Эфириума, основанное на доказательствах достоверности. Оно может работать в режимах доступности данных ZK-роллапа или валидиума.
Matter Labs zkPorter — zkPorter — это протокол масштабирования уровня 2 (l2), решающий проблему доступности данных с помощью гибридного подхода, объединяющего идеи ZK-роллапа и шардинга. Он может поддерживать произвольное количество шардов, каждый из которых имеет свою собственную политику доступности данных.