Обсуждение ZK/Optimistic Hybrid Rollup

Автор: kelvinfichter Составитель: MarsBit, МК

Недавно я убедился, что будущее Ethereum Rollups на самом деле представляет собой гибрид двух основных подходов (ZK и Optimistic). В этом посте я попытаюсь объяснить базовую архитектуру того, что я себе представляю, и объяснить, почему я считаю, что это лучший путь вперед.

Я не собираюсь тратить слишком много времени на обсуждение природы ZK или Optimistic Rollups. Этот пост предполагает, что вы уже хорошо понимаете, как эти вещи работают. Вам не нужно быть экспертом, но вы должны хотя бы знать, что они из себя представляют и как они работают на высоком уровне. Если бы я попытался объяснить вам Rollups, этот пост был бы очень и очень длинным. В общем, приятного чтения!

Начните с Оптимистического накопительного пакета

Гибрид ZK/Optimistic Rollup начинался как Optimistic Rollup, который очень похож на архитектуру Bedrock Optimism. Bedrock стремится к максимальной совместимости с Ethereum («эквивалент EVM») и достигает этого, запуская исполняемый клиент, почти идентичный обычному клиенту Ethereum. Bedrock использует готовящуюся к выпуску модель разделения клиентов консенсуса/исполнения Ethereum, что значительно снижает дисперсию EVM (всегда потребуются некоторые изменения, но мы можем справиться с этим). Когда я пишу это, разница между Bedrock Geth составляет +388 -30 коммитов.

Как и любой хороший Rollup, Optimism берет данные о блоках/транзакциях из Ethereum, сортирует эти данные каким-то детерминированным образом в клиенте консенсуса, а затем передает эти данные в исполняющий клиент L2 для выполнения. Эта архитектура решает первую половину головоломки «идеальный накопитель», давая нам эквивалент EVM L2.

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

Мы можем сообщить Ethereum о состоянии любого Rollup, предоставив обязательство по этому состоянию и доказательство того, что обязательство было сгенерировано правильно. Другими словами, мы доказываем, что «Программа свертки» была выполнена правильно. Единственная реальная разница между ZK и Optimistic Rollups заключается в форме этого доказательства. В ZK Rollup вам нужно дать явное ZK доказательство того, что программа выполняется правильно. В Optimistic Rollup вы заявляете об обещаниях, но не предоставляете явных доказательств. Другие пользователи могут оспаривать ваши утверждения и заставлять вас играть в итеративную игру, в которой вы в конечном итоге выясняете, кто прав.

Я не буду вдаваться в подробности об игре-вызове Optimistic Rollup. Стоит отметить, что современным искусством в этой игре является компиляция вашей программы (Geth EVM + некоторые второстепенные части в случае с Optimism) в какую-нибудь простую машинную архитектуру, такую как MIPS. Мы делаем это, потому что нам нужно создать интерпретатор для нашей программы в цепочке, а создать интерпретатор MIPS намного проще, чем интерпретатор EVM. EVM также является движущейся целью (у нас есть регулярные вилки обновлений) и не совсем охватывает программы, которые мы хотим доказать (там также есть некоторые вещи, не относящиеся к EVM).

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

Конвертировано в ZK Rollup

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

Поэтому моя цель — создать архитектуру и путь миграции, чтобы существующие современные системы Optimistic (такие как Bedrock) можно было легко преобразовать в системы ZK. Вот как я думаю, что это не только возможно, но и выходит за рамки текущего подхода zkEVM.

Начнем с архитектуры в стиле Bedrock, описанной выше. Обратите внимание, что я (вкратце) объяснил, как у Bedrock есть игра-вызов, которая утверждает программу L2 (запуск EVM + некоторые дополнительные вещи, чтобы превратить ее в ZK Rollup).

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

Поэтому моя цель — создать архитектуру и путь миграции, которые позволят существующим современным системам Optimistic (таким как Bedrock) беспрепятственно переходить на системы ZK. Я считаю, что это способ не только осуществить этот переход, но и сделать это таким образом, который выходит за рамки сегодняшнего подхода zkEVM.

Мы начнем с архитектуры в стиле Bedrock, которую я описал ранее. Обратите внимание, что я (вкратце) объяснил, как у Bedrock есть игра-вызов, которая может подтвердить правильность выполнения программы L2 (программа MIPS, работающая с EVM + некоторые дополнения). Один из основных недостатков этого подхода заключается в том, что нам нужно предоставить пользователю определенный период времени, чтобы обнаружить и успешно оспорить ложное предложение результата программы. Это добавляет значительное количество времени к процессу вывода активов (в настоящее время 7 дней в основной сети Optimism).

Однако наш L2 — это всего лишь программа, работающая на простой машине (MIPS). Для такой простой машины вполне возможно построить схему ЗК. Затем мы можем использовать эту схему, чтобы однозначно доказать правильность выполнения программы L2. Не внося никаких изменений в текущую кодовую базу Bedrock, вы можете начать публиковать доказательства достоверности Optimism. Это действительно настолько просто.

Почему этот метод работает так хорошо

Краткое примечание: в этом разделе я упомянул «zkMIPS», но на самом деле я использую его для обозначения любой универсальной «простой» zkVM.

zkMIPS проще, чем zkEVM

Огромным преимуществом создания zkMIPS (или zk[вставьте другое имя машины]) вместо zkEVM является то, что архитектура целевой машины проста и статична. EVM часто меняется. Цены на бензин изменятся, коды операций будут скорректированы, а вещи будут добавлены или удалены. А MIPS-V не менялся с 1996 года. Ориентируясь на zkMIPS, вы работаете с исправленным проблемным пространством. Вам не нужно изменять и, возможно, повторно проверять вашу схему каждый раз, когда обновляется EVM.

zkMIPS более гибок, чем zkEVM

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

Ваш вопрос превращается в доказательство

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

Но сокращение времени проверки — это проблема, глубоко укоренившаяся в пространстве Web2. Учитывая, что архитектура машины MIPS не изменится в ближайшем будущем, мы можем значительно оптимизировать наши схемы и программы проверки, не беспокоясь об изменениях EVM на более позднем этапе. Я почти уверен, что пул найма инженеров по аппаратному обеспечению, которые могут оптимизировать четко определенную программу, по крайней мере в 10 (если не в 100) раз больше, чем пул найма для создания и аудита постоянно меняющейся цели zkEVM. В такой компании, как Netflix, вероятно, есть много инженеров по аппаратному обеспечению, работающих над оптимизацией чипов транскодирования, и они с радостью примут кучу венчурных денег, чтобы решить интересную задачу ZK.

Начальное время проверки для такой схемы может превышать 7-дневный период вывода средств Optimistic Rollup. Это время доказательства будет только уменьшаться с течением времени. Внедряя ASIC и FPGA, мы можем значительно ускорить время проверки. Со статической целью мы можем построить более оптимальные пруверы.

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

Вы можете сосредоточиться на других важных вопросах

Запуск блокчейна — сложная задача, и она требует не только написания большого количества внутреннего кода. Большая часть того, что мы делаем в Optimism, сосредоточена на улучшении взаимодействия с пользователем и разработчиком с помощью полезных клиентских инструментов. Мы также потратили много времени и энергии, занимаясь «мягкими» вещами: обсуждением проектов, пониманием болевых точек, разработкой стимулов. Чем больше времени вы тратите на программное обеспечение блокчейна, тем меньше времени вы тратите на размышления о других вещах. Вы всегда можете попытаться нанять больше людей, но организации не масштабируются линейно, и каждый новый наем увеличивает нагрузку на внутреннюю коммуникацию.

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

** A **** НЕКОТОРЫЕ ВЫВОДЫ **

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