Все об OlaVM и о том, что ждет впереди!

16 ноября 2022 г.

TL;DR

1. Мы работаем над созданием первой ZKVM на основе архитектуры с параллельным выполнением и достижением более высокого показателя TPS за счет улучшения дизайна, дружественного к ZK, и алгоритмов ZK. Технические характеристики следующие:
2. Быстрая генерация доказательств
   • Дружественность к ZK: меньший масштаб схемы и упрощенные блоки нижнего ограничения
   • Fast ZK: дальнейшая оптимизация на Plonky2

3. Быстрое выполнение: использование параллельного выполнения для значительного сокращения времени создания доказательства

   2. Текущий прогресс: * В июле 2022 г. мы выпустили технический документ OlaVM. * Ноябрь 2022 г., завершено проектирование и разработка набора инструкций, а также реализован исполнительный модуль OlaVM виртуальной машины, вы можете проверить ссылку: https:// github.com/Sin7Y/olavm, чтобы просмотреть наш код, который постоянно обновляется. * Для алгоритма ZK с самой быстрой эффективностью выполнения мы завершили разработку схемы и исследование алгоритма plonky2. Вы можете проверить ссылку: https://github.com/Sin7Y/plonky2/tree/main/plonky2/ design чтобы узнать больше о дизайне plonky2, мы оптимизируем и улучшаем его на следующем шаге. Пожалуйста, следите за обновлениями.

Чем мы занимаемся?

OlaVM – это первая ZKVM, в которой реализовано параллельное выполнение виртуальных машин. Она объединяет технические характеристики двух схем для повышения скорости выполнения и подтверждения, что обеспечивает наивысший показатель TPS в системе.

Существуют две основные причины низкой пропускной способности Ethereum:

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

2. Выполнение транзакции: выполнение транзакции является однопоточным. n Чтобы решить нашу первую проблему, сохраняя при этом программируемость, многие проекты проводили исследование ZK(E)VM, то есть транзакции завершались вне цепочки, и в цепочке оставалась только государственная проверка (конечно есть и другие схемы расширения мощностей, но в этом посте мы не будем подробно на них останавливаться). Чтобы повысить пропускную способность системы, доказательства должны создаваться как можно быстрее. Чтобы решить нашу вторую проблему, Aptos, Solona, ​​Sui и другие новые общедоступные сети представили виртуальные машины с параллельным выполнением (PE-VM) (конечно, они также включают более быстрый механизм консенсуса) для улучшения общий TPS системы.

На данном этапе для ZK(E)VM узким местом, влияющим на TPS всей системы, является генерация доказательств. Однако, когда Parallel Prove используется для ускорения пропускной способности, чем быстрее генерируется блок, тем раньше начинается генерация соответствующего доказательства (с развитием алгоритмов ZK и улучшением средств ускорения, тем короче время генерации доказательства и более эффективная и значительное улучшение, обеспечиваемое этим).

Как повысить пропускную способность системы?

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

1. Сведение схемы к минимуму

Как описано выше, стоимость создания доказательства тесно связана с общим размером ограничения n, поэтому, если вы сможете значительно уменьшить размер ограничения, время создания доказательства также значительно сократится. Это достижимо за счет использования различных конструктивных схем, чтобы ваша схема была как можно меньше.

* Мы представляем модуль, который будем называть «Пророк». Существует множество различных определений пророка, но мы сосредоточились на «Предсказать», а затем на «Проверить», цель этого модуля состоит в том, чтобы при некоторых сложных вычислениях нам не нужно было использовать набор инструкций виртуальной машины для выполнения этих вычислений. Почему это так, потому что это может потреблять много инструкций, тем самым увеличивая траекторию выполнения VM и окончательный масштаб ограничений. Вместо этого здесь вступает в действие модуль Prophet, встроенный модуль, который выполняет вычисления за нас, отправляет результаты на виртуальную машину, которая выполняет проверку легитимности и проверяет результат. Prophet — это набор встроенных функций со специфическими вычислительными функциями, такими как деление, квадратный корень, кубический корень и т. д. Мы будем постепенно обогащать библиотеку Prophets на основе реальных сценариев, чтобы максимизировать общий эффект уменьшения ограничений для наиболее сложных вычислительных сценариев. .

* ZK-дружественный

При работе со сложными вычислениями модуль Prophet может помочь нам уменьшить общий размер трассировки выполнения виртуальных машин, однако было бы удобно и предпочтительно, если бы сами фактические вычисления были дружественны к ZK. Поэтому в нашей архитектуре мы решили разработать решение, основанное на операциях, удобных для ZK (выбор алгоритмов хеширования и т. д.), некоторые из этих оптимизаций присутствуют и в других виртуальных машинах ZK(E). Помимо вычислительной логики, которую выполняет сама виртуальная машина, существуют и другие операции, которые также необходимо доказать, например операции с оперативной памятью. Учитывая виртуальную машину на основе стека, операции POP и PUSH должны выполняться при каждом доступе. На уровне верификации по-прежнему необходимо проверять валидность этих операций, они будут формировать независимые таблицы, чтобы потом использовать ограничения для проверки валидности этих операций стека. С другой стороны, виртуальные машины на основе регистров, выполняющие точно такую ​​же логику, приведут к меньшей траектории выполнения и, следовательно, к меньшему масштабу ограничений.

1. Алгоритмы ZK & Эффективность

К настоящему моменту алгоритм ZK добился поразительного прогресса в инженерной осуществимости. Сценарии становятся все более общими и эффективными, от R1CS до Plonkish, из более широкой области (Виртуальная машина Cairo):

в меньшее поле (Plonky2):

ускорение от CPU до реализации GPU/FPGA/ASIC, например Ingonyama ускоренный дизайн FPGA и Semisand дизайн ASIC и т. д.

Из-за потрясающей производительности Plonky2 мы временно используем Plonky2 в качестве серверной части ZK для OlaVM. Мы провели глубокий анализ дизайна Plonky2 Gate, дизайна гаджетов и основных принципов протокола, а также определили области дизайна, в которые мы можем внести свой вклад и повысить эффективность. Посетите наш репозиторий Github: дизайны Plonky2 для получения дополнительной информации.

Более быстрое выполнение транзакций (в настоящее время не является узким местом на данном этапе)

В дизайне OlaVM Prover нелицензирован, и любой может получить к нему доступ, поэтому, когда у вас много Prover, вы можете создавать доказательства для этих блоков параллельно, а затем объединять эти доказательства вместе и отправлять их в цепочку для проверки. Поскольку модуль Prover выполняется параллельно, чем быстрее генерируется блок (чем быстрее выполняются транзакции в соответствующем блоке), соответствующее доказательство может быть сгенерировано заранее, что приводит к значительному сокращению окончательного времени проверки в цепочке.< /p>

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

Что насчет совместимости?

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

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

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

Что дальше?

---

Оригинал