Блокчейн (существительное): Координационная машина, которая позволяет участникам со всего мира сотрудничать в соответствии с общепризнанными правилами без участия какой-либо третьей стороны.

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

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

Хотя Web3 часто описывается как «читай, пиши, владей», мы считаем, что лучшим понятием для третьей итерации интернета является «читай, пиши, проверяй», учитывая, что ключевым преимуществом публичных блокчейнов являетсягарантированные вычисленияи простая проверка того, что эти гарантии были соблюдены. Собственность может быть подмножеством гарантированного вычисления, если мы создадим цифровые артефакты, которые можно купить, продать и контролировать. Однако многие случаи использования блокчейнов выигрывают от гарантированного вычисления, но не вовлекают прямо собственности. Например, если ваше здоровье в полностью он-чейновской игре составляет 77 из 100 - вы владеете этим здоровьем или это просто обязательно к исполнению в рамках согласованных правил? Мы бы утверждали последнее, но Крис Диксонможет не согласиться.

Web3 = Читать, Писать, Проверять

ZK и Модульность - Два Тренда, Которые Ускорят

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

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

• Экспрессивность - На что вы можете создать гарантии? Содержит масштабируемость (стоимость, задержку, пропускную способность и т. д.), конфиденциальность (или управление потоком информации), программирование и комбинируемость.
• Жёсткость - Насколько жёсткие эти гарантии? Включает в себя безопасность, децентрализацию, и безопасность пользователей и кода.

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

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

Мы считаем, что как модульность, так и «ZKfication of everything» - это тенденции, которые будут продолжать ускоряться. Хотя обе они предоставляют интересные ракурсы для изучения пространства индивидуально, - мы особенно заинтересованы в пересечении двух. Два ключевых вопроса, которые нас интересуют, -

1. Какие части модульного стека уже интегрировали ZKPs, а какие еще предстоит исследовать?
2. Какие проблемы можно было бы облегчить с помощью ZKPs?

Однако прежде чем мы перейдем к этим вопросам, нам нужно обновленное представление о том, как будет выглядеть модульный стек в 2024 году.

Модульный стек в 2024

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

Ранее попытки исследования стека web3 включают те, которые сделаны Кайл Самани(Мультикойн) - изначально опубликовано в2018и обновлено в2019. Он охватывает все, начиная от децентрализованного доступа к интернету последней мили (например, Гелий) to end-user key management. While the principles behind it could be recycled, some pieces, like proving and verification, are completely missing.

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

ZK В Модульном Стеке

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

1 - Абстракция операций пользователя

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

• Абстракция учетной записи (AA) позволяет смарт-контрактам выполнять транзакции без необходимости подписи пользователей для каждой операции (“программируемый крипто-счет”). Он может использоваться для определения того, кто может подписать (управление ключами), что подписать (полезная нагрузка tx), как подписать (алгоритм подписи) и когда подписать (условие одобрения транзакции). В совокупности эти функции позволяют такие вещи, как использование социального входа для взаимодействия с dApps, двухфакторная аутентификация, восстановление учетной записи и автоматизация (автоматическое подписание tx). Хотя обсуждение часто сосредотачивается вокруг Ethereum (ERC-4337прошел весной 2023 года), многие другие цепи уже имеют встроенную, внутреннюю абстракцию учетной записи (Aptos, Sui, Близко, ICP, StarknetиzkSync.
• Абстракция цепи позволяет пользователям подписывать транзакции на разных цепях, взаимодействуя только с одним аккаунтом (один интерфейс, несколько цепей). Над этим работают несколько команд, включая Близко, ICP, и dWallet. Эти решения используют MPC и цепочечные подписи, где закрытый ключ другой сети разбивается на несколько маленьких частей и распределяется среди валидаторов на исходной цепочке, которые подписывают транзакции межцепочной. Когда пользователи хотят взаимодействовать с другой цепочкой, достаточное количество валидаторов должно подписать транзакцию, чтобы удовлетворить порог шифрования. Это обеспечивает безопасность, поскольку закрытый ключ нигде полностью не раскрывается. Однако это сталкивается с риском коллузии валидаторов, поэтому криптоэкономическая безопасность и децентрализация валидаторов базовой цепочки по-прежнему остаются важными.
• Намерения, на высоком уровне, позволяют преобразовывать желания и потребности пользователей в операции, которые могут быть выполнены с использованием блокчейна. Для этого требуются решатели намерений - специализированные агенты вне цепи, которые занимаются поиском наилучшего решения для намерений пользователя. Уже существует несколько приложений, которые используют специализированные намерения, такие как DEX-агрегаторы ("лучшая цена") и агрегаторы мостов ("самый дешевый/быстрый мост"). Общие сети по урегулированию намеренийAnoma, Основной, Хитрый) стремимся упростить пользователю выражение более сложных намерений и разработчикам создание приложений, ориентированных на намерения. Однако до сих пор остается много открытых вопросов, включая формализацию процесса, вид языка, ориентированного на намерения, существует ли всегда оптимальное решение и можно ли его найти.

Существующие ZK Интеграции

• Аутентификация с использованием AA x ZK: Один пример этого - Sui’szkВход, что позволяет пользователям входить, используя привычные учетные данные, такие как адрес электронной почты. Он использует ZKPs для предотвращения связывания адреса Sui с соответствующим идентификатором OAuth третьими сторонами.
• Более эффективная проверка подписи для кошельков AA: Проверка транзакций в контрактах AA может быть значительно дороже, чем те, которые инициированы традиционным аккаунтом (EOA).Орбитерпытается справиться с этим с помощью службы упаковщика, которая использует ZKPs для проверки правильности подписей транзакций и поддерживает значение nonce и баланс газа учетной записи AA (через дерево состояния мира Меркла). Благодаря агрегации доказательств и делению стоимости проверки на цепи поровну между всеми пользователями, это может привести к значительным экономиям затрат.

Открытые проблемы, которые могли бы решить ZKPs

• Доказательство лучшего исполнения или выполнение намерений: В то время как намерения и AA могут абстрагировать сложность от пользователей, они также могут действовать как централизующая сила и требовать от нас полагаться на специализированных участников (решатели), чтобы найти оптимальные пути исполнения. Вместо того, чтобы просто доверять доброй воле решателя, ZKPs потенциально могут быть использованы для доказательства того, что оптимальный путь для пользователя был выбран из тех, которые были выбраны решателем.
• Конфиденциальность для урегулирования намерений: Протоколы, такие как Тайгастремится обеспечить полностью защищенное завершение намерений для сохранения конфиденциальности пользователей - часть более широкого движения к добавлению конфиденциальности (или по крайней мере конфиденциальности) к блокчейн-сетям. Он использует ZKPs (Halo2), чтобы скрыть чувствительную информацию о переходах состояния (типы приложений, участвующие стороны и т. д.).
• Восстановление пароля для кошельков AA: Идея заэто предложениепредназначено для того, чтобы пользователи могли восстановить свои кошельки, если потеряют свои личные ключи. Храня хеш (пароль, номер) в кошельке контракта, пользователи могут сгенерировать ZKP с помощью своего пароля, чтобы подтвердить, что это их учетная запись, и запросить изменение личного ключа. Период подтверждения (3 дня или более) служит защитой от несанкционированных попыток доступа.

2 - Последовательность

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

Еще один вопрос - кто получает заказ на транзакции. В модульном мире это могут делать несколько разных сторон, включая секвенсор rollup (централизованный или децентрализованный), L1 sequencing (основанный на rollups) и общую сеть последовательности (децентрализованная сеть секвенсоров, используемая несколькими rollups). Все они имеютразные предположения о доверии и возможности масштабированияНа практике фактическое упорядочение транзакций и их объединение в блок также может выполняться вне протокола специализированными участниками (строителями блоков).

Существующие ZK Интеграции

• Проверка правильного шифрования пула транзакций: Радиусэто сеть совместного сеанса, в которой есть зашифрованный пул транзакций с практическим доказуемым задержанием шифрованияPVDE). Пользователи генерируют ZKP, который используется для доказательства того, что решение временных блокировок приведет к правильному расшифровыванию действительных транзакций, т.е. что транзакция содержит действительную подпись и номер и отправитель имеет достаточный баланс для оплаты комиссии за транзакцию.

Открытые проблемы, которые могли бы решить ZKPs

• Правила проверяемой последовательности (VSR): Подчинение предложителя/последователянабор правил относительно порядка выполненияс дополнительными гарантиями того, что эти правила соблюдаются. Проверка может осуществляться либо с помощью ZKPs, либо с помощью доказательств мошенничества, для чего требуется достаточно большая экономическая обязательство, которая будет сокращена, если предлагающий/последователь ведет себя неправильно.

3 - Выполнение (Масштабирование записей)

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

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

Существующие ZK Интеграции

• zkEVM роллапы: Специальный тип zkVM, оптимизированный для совместимости с Ethereum и доказательства среды выполнения EVM. Чем ближе совместимость с Ethereum, тем больше уступок в производительности. Несколько zkEVMs были запущены в 2023 году, включая Polygon zkEVM, zkSync Эра, Прокрутить, и Linea. Недавно компания Polygon объявила о своемпроверенный zkEVM тип 1, что позволяет доказывать основные блоки Ethereum основной сети за $0.20-$0.50 за блок (с предстоящими оптимизациями для дальнейшего снижения затрат). RiscZero также имеет решениекоторое позволяет доказать блоки Ethereum, но за более высокую цену с ограниченной доступной базой для сравнения.
• Альтернативные zkVM: Некоторые протоколы идут альтернативным путем и оптимизируют производительность/доказуемость (Starknet, Зорп) или дружелюбие к разработчикам, а не попытки быть максимально совместимым с Ethereum. Примеры последнего включают протоколы zkWASM (Свободно, Delphinus Labs) и zkMOVE ( M2иzkmove).
• Фокусирующиеся на конфиденциальности zkVMs: В этом случае ZKP используются для двух вещей: избегания повторного выполнения и достижения конфиденциальности. Хотя конфиденциальность, которую можно достичь только с помощью ZKP, ограничена (только личное конфиденциальное состояние), будущие протоколы добавляют много выразительности и программирования к существующим решениям. Примеры включают в себя Aleo’ssnarkVM, Aztec’sAVM и Polygon’sMidenVM.
• ZK-сопроцессоры: Позволяют проводить вычисления вне цепи на цепных данных (но без состояния). ZKPs используются для доказательства правильного выполнения, обеспечивая более быстрое завершение, чем у оптимистичных сопроцессоров, но существует компромисс в стоимости. Учитывая стоимость и/или сложность создания ZKPs, мы видим некоторые гибридные версии, такие как Краткая coChain, что позволяет разработчикам выбирать между ZK или оптимистичным режимом (компромисс между затратами и сложностью гарантий).

Открытые проблемы, которые могли бы решить ZKPs

• Воплощенный zkVM: Большинство базовых уровней (L1s) по-прежнему используют повторное выполнение для проверки правильных переходов состояний. Воплощение zkVM в базовый уровень позволило бы избежать этого, поскольку валидаторы могли бы проверить доказательство. Это улучшило бы операционную эффективность. Большинство внимания сосредоточено на Ethereum с воплощенным zkEVM, но многие другие экосистемы также полагаются на повторное выполнение.
• zkSVM: В то время как SVM в основном используется в рамках Solana L1 сегодня, команды, такие как Eclipse, пытаются использовать SVM для rollups, которые урегулируются на Ethereum. Eclipse также планирует использовать Risc Zero для доказательств мошенничества ZKдля потенциальных проблем с переходами государств в SVM. Полноценный zkSVM, однако, еще не исследовался - возможно, из-за сложности проблемы и того факта, что SVM оптимизирован для других вещей, чем доказуемость.

4 - Запрос данных (масштабирование чтения)

Запрос данных, или чтение данных с блокчейна, является важной частью большинства приложений. В то время как большая часть обсуждений и усилий в последние годы были сосредоточены на масштабировании записей (исполнение) - масштабирование чтения еще более важно из-за дисбаланса между ними (особенно в децентрализованной среде). Соотношение между чтением/записью различается в зависимости от блокчейна, но одним из важных аспектов являетсяпрогноз Сигаболее 96% всех вызовов к узлам на Solana были вызовами на чтение (на основе 2-летних эмпирических данных) - соотношение чтения/записи 24:1.

Увеличение чтения включает как увеличение производительности (больше чтений в секунду) с помощью выделенных клиентов валидаторов (например, Sig на Solana), так и возможность выполнения более сложных запросов (путем объединения чтения с вычислениями), например, с помощью сопроцессоров.

Другой ракурс - децентрализация методов запроса данных. В настоящее время большинство запросов на получение данных в блокчейнах осуществляются доверенными сторонними лицами (на основе репутации), такими как узлы RPC (Infura) и индексаторы (ДюнаПримеры более децентрализованных вариантов включаютГрафики операторы с доказательством хранения (которые также можно проверить). Существует также несколько попыток создания децентрализованной сети RPC, таких как Infura DINилиСеть Lava(кроме децентрализованного RPC, Lava планирует предложить дополнительные услуги доступа к данным позже).

Существующие ZK Интеграции

• Доказательства хранения: Позволяет запрашивать как исторические, так и текущие данные с блокчейнов без использования доверенных сторонних лиц. Для сжатия и доказательства того, что были извлечены правильные данные, используются ZKP. Примеры проектов, работающих в этой сфере, включаютАксиома, Brevis, Геродот, и Лагранж.

Открытые проблемы, которые могли бы решить ZKP

• Эффективный запрос частного состояния: Проекты по конфиденциальности часто используют вариацию модели UTXO, которая обеспечивает лучшие функции конфиденциальности, чем модель учетной записи, но за счет удобства для разработчика. Частная модель UTXO также может привести к проблемам с синхронизацией - что-то Zcash имел проблемы сс 2022 года после значительного увеличения объема защищенных транзакций. Кошельки должны синхронизироваться с цепочкой перед тем, как можно будет потратить средства, поэтому это довольно фундаментальная проблема для работы сети. В предвидении этой проблемы, Aztec недавно опубликовал RFPдля идей относительно обнаружения заметок, но пока нет четкого решения.

5 - Доказательство

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

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

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

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

Источник: Фигмент Капитал

Существующие ZK Интеграции

• STARK с оберткой SNARK: доказатели STARK быстры и не требуют доверенной настройки, но их недостаток заключается в том, что они производят большие доказательства, которые чрезмерно дорого проверять на Ethereum L1. Обертывание STARK в SNARK в качестве завершающего шага делает его значительно дешевле для проверки на Ethereum. С другой стороны, это добавляет сложности, и безопасность таких «сложенных доказательственных систем» не была достаточно изучена. Примеры существующих реализаций включаютPolygon zkEVM, Boojum в эпоху zkSyncи RISC Zero.
• Общегецельные децентрализованные сети доказательств: Интеграция большего количества приложений в децентрализованную сеть доказательств делает ее более эффективной для доказывающих лиц (более высокая утилизация аппаратного обеспечения) и дешевле для пользователей (не нужно платить за избыточное аппаратное обеспечение). Проекты в этой области включаютGevulotиКраткий.

Открытые проблемы, которые могли бы решить ZKPs

• Доказательства мошенничества ZK: В оптимистических решениях любой может оспорить переход состояния и создать доказательство мошенничества во время периода оспаривания. Однако проверка доказательства мошенничества все еще довольно громоздкая, поскольку происходит через повторное выполнение. Доказательства мошенничества ZK направлены на решение этой проблемы путем создания доказательства перехода состояния, которое оспаривается, что позволяет более эффективную верификацию (не требуется повторное выполнение) и, возможно, более быстрое завершение. Над этим работают, по крайней мере, Оптимизм (в сотрудничестве с O1 Labs и RiscZero), и AltLayer x RiscZero.
• Более эффективная агрегация доказательств: Важная особенность ZKPs заключается в том, что вы можете агрегировать несколько доказательств в одно доказательство, не увеличивая существенно затраты на верификацию. Это позволяет амортизировать затраты на верификацию по нескольким доказательствам или приложениям. Агрегация доказательств также является доказательством, но входными данными являются два доказательства вместо следа выполнения. Примеры проектов в этой области включают NEBRAиGevulot.

Источник: Figment Capital

6 - Публикация данных (доступность)

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

Celestiaбыл первым альтернативным уровнем DP, запустившим свою основную сеть (31 октября), но вскоре появится много альтернатив, из которых можно выбрать, так как Доступ, EigenDA, и Near DAвсе ожидаются к запуску в 2024 году. Кроме того, Ethereum’s EIP 4844обновление масштабных данных публикации на Ethereum (помимо создания отдельного рынка сбора платы за хранение блобов) и подготовка к полному шардингу. DP также расширяется на другие экосистемы - одним из примеров является @nubit_org/riema-secure-ангельская-investment-for-launching-the-first-bitcoin-native-data-availability-layer-49ccf0487380">Nubit который aims to build Native DP on Bitcoin.

Многие решения DP также предлагают услуги за пределами чистой публикации данных, включая общую безопасность для суверенных роллапов (например,СелестияиДоступно) или более плавное взаимодействие между роллапами (например, Avail’sNexusТакже есть проектыДомикониНулевая гравитация) предлагают как публикацию данных, так и долгосрочное хранение состояния, что является привлекательным предложением. Это также пример повторной сборки двух компонентов в модульном стеке, что, вероятно, мы будем видеть больше впереди (эксперименты как с дальнейшим разбиением на составные части, так и с повторной сборкой).

Существующие интеграции ZK

• Доказательство корректности кодирования стирания: Кодирование стирания обеспечивает определенный уровень избыточности, чтобы исходные данные можно было восстановить, даже если часть закодированных данных недоступна. Это также предпосылка для DAS, где легкие узлы выбирают только небольшую часть блока для вероятностного обеспечения наличия данных. Если злонамеренный предложитель неправильно кодирует данные, исходные данные могут быть невосстановимы, даже если легкие узлы выбирают достаточно уникальных фрагментов. Доказательство правильного кодирования стирания можно выполнить с использованием доказательств корректности (ZKPs) или доказательств мошенничества - последние страдают из-за задержки, связанной с периодом вызова. Все другие решения, кроме Celestia, работают с использованием доказательств корректности.
• ZK-легкие клиенты, обеспечивающие передачу данных: Rollups, которые используют внешние слои публикации данных, по-прежнему нуждаются в связи с уровнем расчетов, чтобы данные были опубликованы правильно. Для этого предназначены мосты аттестации данных. Использование ZKPs облегчает верификацию консенсусных подписей исходной цепи более эффективно в сети Ethereum. Оба продукта Avail ( VectorX) и Celestia’s (BlobstreamX) мосты аттестации данных работают на базе ZK световых клиентов, созданных вместе с Succinct.

Открытые проблемы, которые могли бы решить ZKP

• Celestia, включающая доказательства действительности для правильного кодирования стирания: Celestia в настоящее время является выбросом среди сетей публикации данных, так какиспользует доказательства мошенничества для правильного кодирования стирания. Если злонамеренный блок-предложитель неправильно кодирует данные, любой другой полный узел может создать доказательство мошенничества и оспорить это. Хотя этот подход в некоторой степени проще в реализации, он также вносит задержку (блок становится окончательным только после окончания периода доказательств мошенничества) и требует, чтобы легкие узлы доверяли одному честному полному узлу для создания доказательства мошенничества (не могут проверить его сами). Однако, Celestia исследуетсочетание своего текущего кодирования Рида-Соломона с ZKP для доказательства правильного кодирования, что значительно уменьшило бы окончательность. Последнее обсуждение на эту тему можно найти здесь с записями предыдущих рабочих групп (в дополнение к более общим попыткам добавления ZKPs в базовый уровень Celestia).
• ZK-доказательство DAS: Были проведены некоторые исследования на Доступность данных ZK-доказательства, где легкие узлы просто проверяли бы мерклевый корень и ZKP, а не скачивали небольшие фрагменты данных для обычной выборки. Это снизило бы требования к легким узлам еще больше, но, кажется, развитие застопорилось.

7 - Долгосрочное (государственное) хранение

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

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

Существующие интеграции ZK

• Доказательство хранения: Поставщики долгосрочного хранения должны регулярно генерировать ZKPs, чтобы доказать, что они сохранили все данные, которые они утверждают. Примером этого является Доказательство пространства Filecoin (PoSt), где провайдеры хранения зарабатывают блоковые награды каждый раз, когда они успешно отвечают на вызов PoSt.

Открытые проблемы, которые ZKPs могли бы решить

• Доказательство происхождения данных и авторизация для просмотра чувствительных данных: Если две недоверенные стороны хотят обменяться чувствительными данными, ZKPs могут быть использованы для доказательства того, что одна сторона имеет необходимые учетные данные для просмотра данных без необходимости загрузки фактических документов или раскрытия пароля и данных для входа.

8 - Согласование

Учитывая, что блокчейны являются распределенными P2P-системами, здесь нет доверенной третьей стороны, которая определяет глобальную истину. Вместо этого узлы сети соглашаются о том, какова текущая истина (какой блок является правильным) с помощью механизма, называемого консенсусом. Методы консенсуса на основе PoS могут быть классифицированы либо как основанные на BFT (где кворум валидаторов, обладающих устойчивостью к византийским ошибкам, определяет окончательное состояние), либо как основанные на цепи (где окончательное состояние определяется ретроспективно правилом выбора вилки). В то время как большинство существующих реализаций PoS-консенсуса основаны на BFT,Кардано является примером реализации с самой длинной цепочкой. Также растет интерес к механизмам консенсуса на основе DAG, таким как Narwhal-Bullshark, которые реализованы в некоторых вариациях в Aleo, Aptos и Sui.

Согласование является ключевой частью многих различных компонентов модульного стека, включая общий последователь, децентрализованное доказательство и сети публикации данных на основе блокчейна (не на основе комитетов, таких как EigenDA).

Существующие интеграции ZK

• Стейкинг в сетях конфиденциальности на основе ZK: Сети конфиденциальности на основе PoS представляют собой проблему, поскольку держатели токенов для стейкинга должны выбирать между конфиденциальностью и участием в консенсусе (и получением вознаграждения за стейкинг). Penumbra стремится решить этопутем устранения наград за стейкинг вместо этого обрабатывая несвязанные и связанные ставки как отдельные активы. Этот метод сохраняет конфиденциальность отдельных делегирований, в то время как общая сумма, заблокированная у каждого валидатора, все еще является общедоступной.
• Частное управление: Добиться анонимного голосования уже давно является проблемой в криптовалюте, с такими проектами, как Существительные Частное Голосование Пытаюсь продвинуть это вперед. То же самое относится и к управлению, где анонимное голосование по предложениям разрабатывается, по крайней мере, Penumbra. В этом случае ZKP могут быть использованы для доказательства того, что кто-то имеет право голоса (например, через владение токеном) и что определенные критерии голосования выполнены (например, он еще не проголосовал).

Открытые проблемы, которые могли бы решить ZKPs

• Частное избрание лидера: в настоящее время Ethereum выбирает следующих 32 предложителя блоков в начале каждой эпохи, и результаты этого избрания являются общедоступными. Это создает риск того, что злонамеренная сторона запустит атаку DoS против каждого предложителя последовательно, чтобы попытаться отключить Ethereum. В попытке решить эту проблему, Венчик- это предложение о протоколе, обеспечивающем конфиденциальность при выборе блок-предложителей на Ethereum. ZKPs используются валидаторами для доказательства того, что тасование и рандомизация были проведены честно. Существуют и другие подходы для достижения аналогичной конечной цели, некоторые из которых рассмотрены в этомстатья блога от a16z.
• Агрегация подписей: Использование ZKPs для агрегирования подписей может значительно сократить коммуникационные и вычислительные нагрузки при верификации подписей (проверка одного агрегированного доказательства вместо каждой отдельной подписи). Это уже используется в ZK-клиентах, но потенциально может быть расширено и на консенсус.

9 - Расчет

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

Медленная окончательность особенно проблематична в коммуникации между роллапами, где роллапы должны ждать подтверждения от Ethereum, прежде чем смогут утвердить транзакцию (7 дней для оптимистичных роллапов, 12 минут и время доказательства для валидных роллапов). Это приводит к плохому опыту пользователя. Существует несколько усилий по решению этой проблемы с использованием предварительных подтверждений с определенным уровнем безопасности. Примеры включают в себя и экосистемно-специфические решения (Polygon AggLayerилиzkSync HyperBridge) и универсальные решения, такие как Быстрый слой окончательности Nearкоторая стремится соединить несколько различных экосистем rollup, используя экономическую защиту от EigenLayer. Также есть вариантмосты нейтивного роллапа, использующие EigenLayerдля мягких подтверждений, чтобы избежать ожидания полной окончательности.

Существующие ZK Интеграции

• Более быстрая урегулировка с использованием сверток действительности: В отличие от оптимистичных сверток, свертки действительности не требуют периода оспаривания, так как они полагаются на ZKPs для доказательства правильного перехода состояния, независимо от того, оспаривает ли кто-либо (пессимистичные свертки). Это делает урегулировку на базовом уровне намного быстрее (12 минут против 7 дней на Ethereum) и избегает повторного выполнения.

10 - Безопасность

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

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

Протоколы, основанные на принципе общей безопасности, включают в себя:

• EigenLayer нацелен на использование существующей безопасности Ethereum для обеспечения безопасности широкого спектра приложений. Белая книга была выпущена в начале 2023 года, и в настоящее время EigenLayer находится в основной сети альфа-версии, с полной основной сетью, запланированной к запуску позже в этом году.
• Cosmos запустил своюБезопасность межцепочечной (ICS) в мае 2023 года, что позволяет Cosmos Hub - одной из крупнейших цепочек на Cosmos и поддерживаемой ~$2.4 млрд стейкнутых ATOM - сдавать в аренду свою безопасность сетям потребителей. Используя тот же набор валидаторов, который обеспечивает работу космического хаба, для проверки блоков на сети потребителей, он стремится снизить барьеры для запуска новых сетей поверх стека Cosmos. Однако в настоящее время только две цепочки потребителей активны (Neutron and Stride).
• Babylon также пытается сделать так, чтобы BTC можно было использовать для обеспечения общей безопасности. Чтобы противостоять проблемам, связанным с объединенным майнингом (сложно наказать плохое поведение), она создает виртуальный PoS-слой, в котором пользователи могут заблокировать BTC в стейкинг-контракте на Bitcoin (без мостов). Поскольку у Bitcoin нет слоя смарт-контрактов, правила снижения стейкинг-контрактов выражены в виде UTXO-транзакций, записанных в Bitcoin script.
• Рестейкинг на других сетях включают Осьминогна Near и Picasso на Solana. PolkadotПарачейнытакже использует концепцию общей безопасности.

Существующие интеграции ZK

• Смесь между ZK и экономической безопасностью: В то время как гарантии безопасности на основе ZK могут быть более надежными, доказательство по-прежнему является чрезмерно дорогостоящим для некоторых приложений, и создание доказательства занимает слишком много времени. Один пример этого - Brevis coChain, который является сопроцессором, получающим свою экономическую безопасность от рестейкеров ETH и гарантирующим оптимистическую вычислительную мощность (с доказательствами мошенничества ZK). dApps могут выбирать между чистым ZK или режимом coChain в зависимости от своих конкретных потребностей в области безопасности и компромиссов по стоимости.

11 - Взаимодействие

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

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

Пока у нас все еще нет четкого определения различных типов легких клиентов (или узлов), этот пост от Dino(сооснователь Fluent & Modular Media) дает хорошее введение. Большинство легких клиентов сегодня проверяют только согласованность, но в идеале у нас должны быть легкие клиенты, которые могут проверять также выполнение и DA, чтобы сократить доверие к предположениям. Это позволило бы приблизиться к безопасности полного узла без высоких аппаратных требований.

Существующие ZK Интеграции

• ZK легковесные клиенты (проверка согласованности): Большинство текущих легковесных клиентов позволяют проверить согласованность другой цепи - либо полный набор валидаторов (если он достаточно мал) или подмножество общего набора валидаторов (например Синхронизационный комитет Ethereum) ZKPs используются для ускорения и удешевления верификации, поскольку схема подписи, используемая на исходной цепочке, может не поддерживаться нативно на целевой цепочке. В то время как ожидается, что важность ZK light clients в мостах будет расти, текущие препятствия для более широкого принятия включают в себя стоимость доказательства и верификации, а также реализацию ZK light clients для каждой новой цепочки. Примеры протоколов в этой области включают в себя Полиэдры, мосты проверки данных Avail и Celestia, и zkIBC от Electron Labs.
• Доказательства хранения: Как уже упоминалось ранее, доказательства хранения позволяют запрашивать как исторические, так и текущие данные с блокчейнов без использования доверенных сторонних лиц. Это также актуально для межсетевой совместимости, поскольку их можно использовать для межцепных коммуникаций. Например, пользователь может доказать, что у него есть токены на одной цепи и использовать их для управления на другой цепи (без необходимости моста). Также существуют попытки использовать доказательства хранения для создания мостов, таких как это решение разработано LambdaClass.
• ZK Оракулы: Оракулы выступают в качестве посредников и моста между данными реального мира и блокчейном. ZK оракулы улучшают существующие модели оракулов на основе репутации, позволяя доказать происхождение и целостность данных, а также любые вычисления, сделанные на этих данных.

Открытые проблемы, которые могли бы решить ZKPs

• Полные клиенты: Вместо слепого доверия к набору проверяющих другой цепи - полные клиенты также проверяют правильное выполнение и DA. Это снижает доверие к предположениям и приближает к полному узлу, сохраняя при этом низкие аппаратные требования (позволяя большему числу людей запускать легкие клиенты). Тем не менее, верификация чего-либо, кроме консенсуса, до сих пор является чрезмерно дорогостоящей на большинстве цепей, особенно Ethereum. Кроме того, легкие клиенты позволяют только верифицировать информацию (половину проблемы), т.е. они могут определить, что информация ложна, но все еще нужно иметь дополнительный механизм, чтобы что-то с этим сделать.
• Слои агрегации: AggLayer Polygon-ацель - обеспечить плавную взаимодействия между L2 в экосистеме, используя агрегированные доказательства и унифицированный мостовой контракт. Агрегированное доказательство обеспечивает более эффективную верификацию и безопасность - гарантируя, что зависимые состояния цепочек и пакеты согласованы и обеспечивая, что состояние rollup не может быть завершено на Ethereum, если оно зависит от недопустимого состояния другой цепи.Гиперцепи zkSyncиДоступный Nexusберут похожий подход.

Когда ZK съел модульный стек?

Предполагая, что мы можем достичь состояния, когда генерация ZKPs становится очень быстрой (почти со скоростью света) и невероятно дешевой (почти бесплатной), каков конечный результат? Другими словами, когда ZK поглотил модульный стек?

В общем, мы считаем, что в этом состоянии мира две вещи будут верными:

1. Исключается вся ненужная повторная исполнение: Переход к модели исполнения 1/N (а не N/N с повторным исполнением) позволяет существенно сократить общую избыточность сети и обеспечить более эффективное использование базового оборудования. Хотя остается некоторая дополнительная нагрузка, это поможет блокчейнам асимптотически приблизиться к централизованным системам с точки зрения вычислительной эффективности.
2. Большинство приложений полагаются на криптографические гарантии с поддержкой ZK, а не на экономическую безопасность: когда стоимость и время создания доказательств больше не рассматривается как соответствующее обстоятельство, мы считаем, что большинство приложений будут полагаться на ZKPs для более надежных гарантий. Это также требует некоторых улучшений в удобстве использования и дружелюбности к разработчикам для создания ZK-приложений, но это все проблемы, над которыми работают несколько команд.

Третьим условием будет конфиденциальность (или управление потоком информации), но это сложнее. ZKPs могут использоваться для некоторых приложений конфиденциальности с доказательством со стороны клиента, что и делают платформы типа Aleo, Aztec или Polygon Miden, однако достижение масштабной конфиденциальности для всех потенциальных случаев использования зависит от прогресса MPC и FHE - потенциальная тема для будущего блог-поста.

Риски для нашей тезиса

Что, если мы ошибаемся, и будущее не является ни модульным, ни ZK'fied? Некоторые потенциальные риски для нашей тезис включают:

Модульность увеличивает сложность

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

Будет ли ZK когда-нибудь достаточно производительным?

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

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

Ингонямапыталась создать некоторые показатели производительности доказательств через сравнимую метрику, называемую ZK score. Она основана на стоимости выполнения вычислений (OPEX) и отслеживает MMOPS/WATT, где MMOPS означает модулярные умножения операций в секунду. Для дальнейшего чтения по этой теме, мы рекомендуем блоги от @Cysic/BJQcpVbXn?ref=blog.succinct.xyz">Cysic and @ingonyama/revisiting-paradigms-hardware-acceleration-for-zero-knowledge-proofs-5dffacdc24b4">Ingonyama, а также этот разговор от Вэй Дай.

Будет ли полезно ограниченное конфиденциальности, которое могут обеспечить ZKPs?

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

Сводка

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

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

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

Хотя эта статья сосредоточена на ZKPs в частности, мы также все больше интересуемся тем, как современные криптографические решения (ZKPs, MPC, FHE и TEE) будут взаимодействовать вместе - что мы уже наблюдаем.

Спасибо за чтение!

Disclaimer：

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