Компания Anagram Build проводит большую часть времени на исследованиях новых криптопримитивов и их применении в конкретных продуктах. Одним из наших недавних исследовательских проектов было изучение области Проверяемых Вычислений (VC); наша команда использовала эти исследования для создания новой системы с открытым исходным кодом под названием BonsolМы выбрали эту сферу исследований, учитывая появление эффективных применений, которые обеспечивает VC, и скоординированные усилия различных L1 для оптимизации стоимости и масштабируемости VC.

В этом блоге у нас две цели.

• Сначала мы хотим убедиться, что вы уйдете с лучшим пониманием VC как концепции и возможных продуктов, которые это позволяет в экосистеме Solana.
• Во-вторых, мы хотим представить вам наше последнее творение, Bonsol.

Что такое Проверяемый Расчет вообще?

Термин 'Verifiable Compute' может не появляться в инвестиционных презентациях стартапов бычьего рынка, но термин 'Zero Knowledge' - да. Итак, что означают эти термины?

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

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

Итак, зачем мы хотим добавить VC или ZK системы поверх платформы типа Solana и Ethereum? Кажется, ответ заключается скорее в безопасности для разработчика. Разработчик системы выступает посредником между доверием конечных пользователей к черному ящику и техническими функциями, которые делают это доверие объективно обоснованным. Используя техники ZK/VC, разработчик может сократить площадь атаки в разрабатываемых им продуктах. VC системы переносят место доверия на систему доказательства и объем вычислительной работы, подтверждаемой. Это аналогичное инверсии доверия, которая происходит при переходе от типичного веб2 подхода клиент/сервер к веб3 блокчейн подходу. Доверие переходит от полагания на обещания компании к доверию открытому исходному коду и криптографическим системам сети. Нет истинных систем нулевого доверия с точки зрения пользователя, и я утверждаю, что для конечных пользователей все это похоже на черный ящик.

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

Хотя существует много многообещающих примеров использования VC и ZK на практике, многие из них в настоящее время зависят от развития на всех уровнях стека криптопрограммного обеспечения, чтобы сделать его достаточно быстрым и эффективным для использования в производстве.

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

Поехали! Как сегодня работают системы VC/ZK?

Функции VC и ZK теперь в основном выполняются на альтернативных вычислительных слоях (так называемых rollups, sidechains, relays, oracles или coprocessors), доступных через обратный вызов к среде выполнения смарт-контрактов. Для обеспечения этого рабочего процесса многие из L1-цепей в настоящее время работают над предоставлением сокращенных путей за пределами среды выполнения смарт-контрактов (например, syscalls или precompiles), которые позволяют выполнять операции, которые в противном случае были бы слишком дорогими на цепи.

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

Полностью ончейн верификация

Для VC и ZK доказательственных систем, которые могут производить небольшие доказательства, такие как Groth16 или некоторые разновидности Plonk, доказательство затем подается на цепочку и проверяется на цепочке с использованием ранее развернутого кода. Такие системы теперь очень распространены, и лучший способ попробовать это - использовать Circom и верификатор Groth16 на Solana или EVM. Недостатком является то, что эти системы доказательств довольно медленные. Они обычно требуют изучения нового языка. Чтобы проверить 256-битный хэш в Circom, вам действительно нужно вручную работать с каждым из этих 256 битов. Существует много библиотек, которые позволяют вам просто вызывать хэш-функции, но за кадром вам нужно повторно реализовать эти функции в вашем коде Circom. Эти системы отлично подходят, когда элемент ZK и VC вашего использования кейса меньше, и вам нужно, чтобы доказательство было действительным до принятия какого-либо другого детерминированного действия. Bonsol в настоящее время относится к этой первой категории.

Проверка вне цепи

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

Сети верификации

Доказательство представляется сети проверки, и эта сеть проверки действует как оракул для вызова смарт-контракта. Вы получаете детерминизм, но вам также нужно доверять сети проверки.

Синхронная верификация на цепочке

Четвёртый и последний режим довольно отличается; в этом случае доказательство и проверка происходят одновременно и полностью on-chain. Именно здесь L1 или смарт-контракт на L1 фактически способен запускать ZK-схему над входными данными пользователя, позволяющую выполнение доказать на основе частных данных. В дикой природе таких примеров не так много, и обычно типы действий, которые вы можете выполнять с этим, ограничены более базовыми математическими операциями.

Резюме

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

Представляем Bonsol!

ВведитеBonsol, новая система VC нативная для Solana, которую мы в Anagram создали и сделали открытой. Bonsol позволяет разработчику создавать подтверждаемый исполняемый файл над частными и общедоступными данными и интегрировать результаты в умные контракты Solana. Обратите внимание, что этот проект зависит от популярной инструментальной цепочки RISC0.

Этот проект был вдохновлен вопросом, заданным многими проектами, с которыми мы работаем еженедельно: "Как я могу сделать это с приватными данными и доказать это на цепи?" Хотя "это" в каждом случае отличалось, основное желание было одинаковым: минимизировать свои централизованные зависимости.

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

Сценарий один

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

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

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

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

Сценарий два

Bonsol позволяет разработчикам создавать примитив, который используется другими системами. Bonsol содержит понятие развертываний, где разработчик может создать некоторую программу ZK и развернуть ее на операторов Bonsol. Операторы сети Bonsol в настоящее время имеют некоторые базовые способы оценить, будет ли выполнение запроса для одной из программ ZK экономически выгодным. Они могут видеть некоторую базовую информацию о том, сколько вычислений потребуется для программы ZK, размеры ввода и чаевые, которые предлагает запросчик. Разработчик может развернуть примитив, который, по его мнению, захотят использовать многие другие Dapps.

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

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

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

Архитектура Bonsol

Эти примеры использования помогают описать, для чего полезен Bonsol, но давайте взглянем на его текущую архитектуру, текущую модель стимулирования и поток выполнения.

На приведенном выше изображении описан поток от пользователя, которому необходимо выполнить какое-либо проверяемое вычисление, обычно это происходит через децентрализованное приложение, которому это нужно, чтобы позволить пользователю выполнить какое-либо действие. Это будет иметь форму запроса на выполнение, который содержит информацию о выполняемой ZK-программе, входных данных или наборах входных данных, времени, в течение которого вычисления должны быть проверены, и чаевых (то есть о том, как ретрансляторы получают оплату). Запрос подхватывают эстафеты, и они должны решить, хотят ли они претендовать на эту казнь и начать доказывать. В зависимости от конкретных возможностей операторов реле, они могут отказаться от этого, потому что чаевые того не стоят, или zkprogram или входы слишком велики. Если они решат, что хотят выполнить это вычисление, они должны выполнить утверждение для него. Если они первыми получат претензию, то их доказательства будут приниматься до определенного времени. Если они не смогут предоставить доказательство вовремя, другие узлы могут потребовать выполнения. Для того, чтобы претендовать на это, Ретранслятор должен поставить некоторую ставку, которая в настоящее время жестко закодирована на tip / 2, которая будет урезана, если они не смогут предоставить правильное доказательство.

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

Это было легко построить? Конечно, нет!

Это не значит, что при создании Bonsol не было проблем. Чтобы взять доказательство Risco0 и проверить его на Solana, нам нужно уменьшить его размер. Но мы не можем просто так сделать, не пожертвовав при этом безопасностью доказательства. Поэтому мы используем Circom и оборачиваем Risc0 Stark, который может быть примерно 200 кб, в доказательство Groth16, которое в конечном итоге всегда составляет 256 байт. К счастью, Risc0 предоставил некоторые начальные инструменты для этого, но это добавляет много накладных расходов и зависимостей к системе.

Когда мы начали создавать Bonsol и использовать существующие инструменты для упаковки Stark в Snark, мы искали способы уменьшить зависимость и увеличить скорость. Circom позволяет компилировать код Circom в C++ или wasm. Сначала мы попытались скомпилировать схему Circom в wasmu-файл, созданный LLVM. Это самый быстрый и эффективный способ сделать инструмент Groth16 портативным и при этом быстрым. Мы выбрали wasm из-за его переносимости, так как код C++ зависел от архитектуры процессора x86, а это означает, что новые Macbook или серверы на базе Arm не смогут использовать его. Но это стало для нас тупиком по срокам, с которыми мы должны были работать. Поскольку большинство наших экспериментов по исследованию продукта ограничены по времени до тех пор, пока они не докажут свою ценность, у нас было 2-4 недели времени на разработку, чтобы проверить эту идею. Компилятор llvm wasm просто не смог обработать сгенерированный wasm код. Приложив больше усилий, мы могли бы обойти это, но мы перепробовали много флагов оптимизации и способов заставить компилятор llvm работать как плагин wasmer для прекомпиляции этого кода в llvm, но нам это не удалось. Поскольку схема Circom составляет около 1,5 миллиона строк кода, вы можете себе представить, что количество Wasm стало огромным. Затем мы обратили свое внимание на попытку просто создать мост между C++ и нашей кодовой базой ретрансляции Rust. Это также потерпело сокрушительное поражение, так как C++ содержал некоторый специфичный для x86 ассемблерный код, с которым мы не хотели возиться. Для того, чтобы сделать систему общедоступной, мы просто запустили систему таким образом, чтобы использовать код C++, но удалить некоторые зависимости. В будущем мы хотели бы расширить еще одно направление оптимизации, над которым мы работали. Это было сделано для того, чтобы взять код C++ и фактически скомпилировать его в граф выполнения. Эти артефакты C++ из компиляции Circom в основном представляют собой просто модульную арифметику над конечные поляс очень большим простым числом в качестве генератора. Это показало некоторые многообещающие результаты для более маленьких и простых артефактов на C++, но для того, чтобы заставить его работать с системой Risc0, требуется еще больше работы. Это связано с тем, что сгенерированный код на C++ составляет около 7 миллионов строк кода, и генератор графиков, кажется, достигает пределов размера стека, а увеличение их кажется приводит к другим ошибкам, которые мы пока не имели времени определить. Несмотря на то, что некоторые из этих путей не привели к результату, мы смогли внести вклад в проекты OSS и надеемся, что в какой-то момент эти вклады будут включены в основную ветку.

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

Еще одно замечание о Bonsol, которое мы еще не видели в других местах, использующих Risc0, заключается в том, что мы принуждаем обязательство (хэш) над входными данными в zk программу. И на самом деле мы проверяем в контракте, что входы, к которым должен был привязаться доказатель, соответствуют тому, что ожидал и отправил пользователь в систему. Это приносит определенные затраты, но без этого доказатель может обмануть и запустить zk программу над входами, которые пользователь не указал. Остальная часть разработки Bonsol вписалась в нормальную разработку Solana, но стоит отметить, что мы намеренно попробовали некоторые новые идеи. В смарт-контракте мы используем flatbuffers как единственную систему сериализации. Это довольно новаторская техника, которую мы хотели бы развивать и превратить в фреймворк, потому что она отлично подходит для автоматической генерации SDK, которые могут работать на различных платформах. Еще одно замечание о Bonsol заключается в том, что в настоящее время для его наиболее эффективной работы требуется предварительная компиляция, которая должна появиться в Solana 1.18, но пока мы работаем, чтобы увидеть, заинтересованы ли команды в этом исследовании и смотрим за пределы Bonsol на другие технологии.

Завершение

За пределами Bonsol команда Anagram глубоко изучает многие места в области венчурного капитала. Проекты, такие как Jolt, zkllvm, spartan 2, Binius, - это проекты, которые мы отслеживаем, наряду с компаниями, работающими в области полностью гомоморфного шифрования (FHE). Если вы не знаете, что это такое, следите за обновлениями, так как мы рассмотрим это в какой-то момент.

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

Если вы работаете над интересными проектами VC, мы настоятельно рекомендуем вамподать заявку здесь на программу Anagram EIRгде вместе с командой Anagram вы сможете проверить свою тезис, создать компанию и решить самые крупные проблемы. Не стесняйтесь вносить свой вклад или задавать любые вопросы.

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

1. Эта статья перепечатана с [Анаграмма], Все авторские права принадлежат оригинальному автору [austbot]. Если у вас есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно разберутся с этим.

2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционными советами.

3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.