Оригинальное название: «OP+ZK, станет ли Hybrid Rollup окончательным будущим расширения Ethereum?» "
Исходное сообщение @kelvinfichter
Оригинальный сборник: Jaleel, BlockBeats
Недавно я убедился, что будущее Ethereum Rollup на самом деле представляет собой гибрид двух основных подходов, ZK и Optimistic. В этом посте я попытаюсь изложить основы того, какой я представляю себе эту архитектуру, и почему я считаю, что это то направление, в котором мы должны двигаться. Обратите внимание, что я провожу большую часть своего времени, работая над Optimism, также известным как Optimistic Rollup, но я не эксперт ZK. Если я допустил какие-либо ошибки в рассказе о ZK, не стесняйтесь обращаться ко мне, и я исправлю это.
В этой статье я не собираюсь подробно описывать принцип работы ZK и Оптимистичных Роллапов, если я буду тратить время на объяснение сути Роллапов, то эта статья будет слишком длинной. Так что эта статья основана на том, что вы уже имеете определенное представление об этих технологиях, конечно, вам не нужно быть экспертом, но вы должны хотя бы знать, что такое ZK и Optimistic Rollups и их общий механизм работы. В любом случае, пожалуйста, наслаждайтесь чтением этой статьи.
Начнем с оптимистического свертывания
Система, которая смешивала ZK и Optimistic Rollup, изначально была основана на Optimistic Rollup, основанной на архитектуре Optimism's Bedrock. Bedrock спроектирован так, чтобы быть максимально совместимым («EVM-эквивалент») с Ethereum за счет запуска почти идентичного клиента исполнения для клиента Ethereum. Bedrock использует грядущую модель разделения клиента консенсуса/исполнения Ethereum, значительно уменьшая отклонение от EVM (конечно, на этом пути всегда будут некоторые изменения, но мы справимся).
![Будет ли смесь ZK и OP будущим Ethereum Rollup? ] (https://img-cdn.gateio.im/social/moments-69a80767fe-6c65d0c13b-dd1a6f-7649e1)
Как и все хорошие роллапы, Optimism извлекает данные о блоках/транзакциях из Ethereum, затем сортирует эти данные каким-то детерминированным образом в клиенте консенсуса и передает эти данные исполняющему клиенту L2 для выполнения. Эта архитектура решает первую половину головоломки «идеальный накопитель» и дает нам L2-эквивалент EVM.
Конечно, проблема, которую нам все еще нужно решить сейчас, состоит в том, чтобы сообщить Ethereum, что произошло внутри Optimism, поддающимся проверке способом. Если эта проблема не решена, смарт-контракты не могут принимать решения на основе состояния Оптимизма. Это будет означать, что пользователи могут вносить депозиты в Optimism, но не могут снимать свои активы. Хотя в некоторых случаях возможна односторонняя свертка, в большинстве случаев двусторонняя свертка более эффективна.
Предоставив какое-то обязательство для этого состояния и доказательство того, что это обязательство правильное, мы можем передать состояние всех роллапов в Ethereum. Другими словами, мы доказываем, что «Программа свертки» была выполнена правильно. Единственная существенная разница между ZK и Optimistic Rollups заключается в форме этого доказательства. В ZK Rollup вам необходимо предоставить явное доказательство с нулевым разглашением, чтобы доказать правильное выполнение программы. В Optimistic Rollup вы можете сделать заявление об обещании, не предоставляя четких доказательств.Оспаривая и подвергая сомнению ваше утверждение, другие пользователи могут заставить вас участвовать в «игре», состоящей из размышлений и споров, чтобы определить, кто в конечном итоге «да».
Я не буду вдаваться в подробности проблем Optimistic Rollup. Стоит отметить, что современный уровень техники на данном этапе заключается в компиляции вашей программы (Geth EVM + некоторые второстепенные биты в случае Optimism) в какую-нибудь простую машинную архитектуру, такую как MIPS. Мы делаем это, потому что нам нужно построить интерпретатор программы в цепочке, а создать интерпретатор MIPS намного проще, чем интерпретатор EVM. EVM также является движущейся целью (у нас есть регулярные вилки обновления) и не полностью покрывает программы, которые мы хотим доказать (там также есть некоторые вещи, не относящиеся к EVM).
После того, как вы создали сетевой интерпретатор для своей простой машинной архитектуры и создали несколько автономных инструментов, у вас должен быть полнофункциональный оптимистичный накопительный пакет.
Перейти к ZK Rollup
В целом, я твердо верю, что в ближайшие несколько лет Оптимистичные свертки будут доминировать. Некоторые думают, что ZK Rollups в конечном итоге превзойдут Optimistic Rollups, но я не согласен с этим мнением. Я чувствую, что нынешняя относительная простота и гибкость оптимистичных накопительных пакетов означает, что их можно постепенно преобразовать в накопительные пакеты ZK. Если мы сможем найти шаблон для этого перехода, то вместо того, чтобы пытаться построить более негибкую и хрупкую экосистему ZK, мы можем просто развернуться в уже существующей экосистеме Optimistic Rollup.
Поэтому моя цель — создать архитектуру и путь миграции, которые позволят существующей современной экосистеме OP (например, 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.
Ваша миссия превращается в время испытаний
Время доказательств с нулевым разглашением масштабируется по двум осям: количеству ограничений и размеру схемы. Сосредоточив внимание на схеме простой машины, такой как MIPS (а не на более сложной машине, такой как EVM), мы смогли значительно уменьшить размер и сложность схемы. Однако количество ограничений зависит от количества выполняемых машинных инструкций. Каждый код операции EVM разбивается на несколько кодов операций MIPS, что означает, что количество ограничений значительно увеличивается, как и общее время проверки.
Однако сокращение времени проверки также является проблемой, глубоко укоренившейся в домене Web2. Учитывая, что архитектура машины MIPS вряд ли изменится в ближайшее время, мы можем значительно оптимизировать схему и прувер независимо от будущих изменений в EVM. Я чувствую себя довольно уверенно, нанимая старшего инженера по оборудованию для оптимизации четко определенной проблемы, возможно, в десять или даже в сто раз больше инженеров, создающих и проверяющих движущуюся цель zkEVM. В такой компании, как Netflix, вероятно, есть большое количество инженеров по аппаратному обеспечению, оптимизирующих чипы транскодирования, и они, вероятно, готовы потратить кучу венчурных фондов, чтобы взять на себя эту интересную задачу ZK.
Первоначальное время проверки для такой схемы может превышать 7-дневный период вывода Optimistic Rollup. Это время доказательства будет только уменьшаться с течением времени. Внедряя ASIC и FPGA, мы можем значительно ускорить время проверки. Со статической целью мы можем построить более оптимальные пруверы.
В конце концов, время проверки для этой схемы будет меньше, чем текущий 7-дневный период снятия оптимизма, и мы можем начать процесс оспаривания, чтобы рассмотреть возможность удаления оптимизма. Запуск прувера в течение 7 дней, вероятно, все еще слишком дорог, поэтому мы могли бы подождать еще немного, но это разумно. Вы даже можете запускать обе системы доказательств одновременно, поэтому мы можем начать использовать доказательства ZK как можно быстрее и вернуться к доказательствам Optimism, если доказательство по какой-либо причине не работает. По готовности доказательства Optimism могут быть удалены полностью прозрачным для приложения способом, поэтому ваш Optimistic Rollup станет ZK Rollup.
Можешь пойти и заняться другими важными делами
Запуск блокчейна — сложная задача, которая включает в себя больше, чем просто написание большого количества внутреннего кода. В Optimism большая часть нашей работы сосредоточена на улучшении взаимодействия с пользователем и разработчиком за счет предоставления полезных клиентских инструментов. Мы также уделяем много времени и энергии «мягким» вопросам: беседам с проектами, пониманию их болевых точек и разработке стимулов. Чем больше времени вы тратите на сетевое программное обеспечение, тем меньше времени у вас остается на эти другие вещи. Хотя вы всегда можете попытаться нанять больше людей, организации не масштабируются линейно, и каждый новый наем увеличивает затраты на внутреннюю коммуникацию.
Поскольку работа схемы с нулевым разглашением может быть непосредственно применена к уже работающей цепочке, вы можете создать базовую платформу и одновременно разработать программное обеспечение для проверки. Поскольку клиент может быть изменен без изменения схемы, вы можете отделить клиента от группы проверки. Таким образом, Optimistic Rollup может на годы опередить конкурентов с нулевым разглашением с точки зрения фактической активности в сети.
в заключение
Откровенно говоря, я не вижу каких-либо существенных недостатков в прувере zkMIPS, если только его нельзя значительно оптимизировать с течением времени. Единственное реальное влияние, которое я вижу на приложение, заключается в том, что стоимость газа для различных кодов операций, возможно, потребуется скорректировать, чтобы отразить увеличенное время проверки для этих кодов операций. Если действительно невозможно оптимизировать этот прувер до разумного уровня, то я признаю, что потерпел неудачу. Но если этот прувер удастся оптимизировать, то подход zkMIPS/zkVM может полностью заменить текущий подход zkEVM. Это может показаться радикальным утверждением, но не так давно одноэтапные оптимистичные доказательства отказа были полностью заменены многоэтапными.
Оригинальная ссылка
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Станет ли смесь ZK и OP будущим Ethereum Rollup?
Оригинальное название: «OP+ZK, станет ли Hybrid Rollup окончательным будущим расширения Ethereum?» "
Исходное сообщение @kelvinfichter
Оригинальный сборник: Jaleel, BlockBeats
Недавно я убедился, что будущее Ethereum Rollup на самом деле представляет собой гибрид двух основных подходов, ZK и Optimistic. В этом посте я попытаюсь изложить основы того, какой я представляю себе эту архитектуру, и почему я считаю, что это то направление, в котором мы должны двигаться. Обратите внимание, что я провожу большую часть своего времени, работая над Optimism, также известным как Optimistic Rollup, но я не эксперт ZK. Если я допустил какие-либо ошибки в рассказе о ZK, не стесняйтесь обращаться ко мне, и я исправлю это.
В этой статье я не собираюсь подробно описывать принцип работы ZK и Оптимистичных Роллапов, если я буду тратить время на объяснение сути Роллапов, то эта статья будет слишком длинной. Так что эта статья основана на том, что вы уже имеете определенное представление об этих технологиях, конечно, вам не нужно быть экспертом, но вы должны хотя бы знать, что такое ZK и Optimistic Rollups и их общий механизм работы. В любом случае, пожалуйста, наслаждайтесь чтением этой статьи.
Начнем с оптимистического свертывания
Система, которая смешивала ZK и Optimistic Rollup, изначально была основана на Optimistic Rollup, основанной на архитектуре Optimism's Bedrock. Bedrock спроектирован так, чтобы быть максимально совместимым («EVM-эквивалент») с Ethereum за счет запуска почти идентичного клиента исполнения для клиента Ethereum. Bedrock использует грядущую модель разделения клиента консенсуса/исполнения Ethereum, значительно уменьшая отклонение от EVM (конечно, на этом пути всегда будут некоторые изменения, но мы справимся).
![Будет ли смесь ZK и OP будущим Ethereum Rollup? ] (https://img-cdn.gateio.im/social/moments-69a80767fe-6c65d0c13b-dd1a6f-7649e1)
Как и все хорошие роллапы, Optimism извлекает данные о блоках/транзакциях из Ethereum, затем сортирует эти данные каким-то детерминированным образом в клиенте консенсуса и передает эти данные исполняющему клиенту L2 для выполнения. Эта архитектура решает первую половину головоломки «идеальный накопитель» и дает нам L2-эквивалент EVM.
Конечно, проблема, которую нам все еще нужно решить сейчас, состоит в том, чтобы сообщить Ethereum, что произошло внутри Optimism, поддающимся проверке способом. Если эта проблема не решена, смарт-контракты не могут принимать решения на основе состояния Оптимизма. Это будет означать, что пользователи могут вносить депозиты в Optimism, но не могут снимать свои активы. Хотя в некоторых случаях возможна односторонняя свертка, в большинстве случаев двусторонняя свертка более эффективна.
Предоставив какое-то обязательство для этого состояния и доказательство того, что это обязательство правильное, мы можем передать состояние всех роллапов в Ethereum. Другими словами, мы доказываем, что «Программа свертки» была выполнена правильно. Единственная существенная разница между ZK и Optimistic Rollups заключается в форме этого доказательства. В ZK Rollup вам необходимо предоставить явное доказательство с нулевым разглашением, чтобы доказать правильное выполнение программы. В Optimistic Rollup вы можете сделать заявление об обещании, не предоставляя четких доказательств.Оспаривая и подвергая сомнению ваше утверждение, другие пользователи могут заставить вас участвовать в «игре», состоящей из размышлений и споров, чтобы определить, кто в конечном итоге «да».
Я не буду вдаваться в подробности проблем Optimistic Rollup. Стоит отметить, что современный уровень техники на данном этапе заключается в компиляции вашей программы (Geth EVM + некоторые второстепенные биты в случае Optimism) в какую-нибудь простую машинную архитектуру, такую как MIPS. Мы делаем это, потому что нам нужно построить интерпретатор программы в цепочке, а создать интерпретатор MIPS намного проще, чем интерпретатор EVM. EVM также является движущейся целью (у нас есть регулярные вилки обновления) и не полностью покрывает программы, которые мы хотим доказать (там также есть некоторые вещи, не относящиеся к EVM).
После того, как вы создали сетевой интерпретатор для своей простой машинной архитектуры и создали несколько автономных инструментов, у вас должен быть полнофункциональный оптимистичный накопительный пакет.
Перейти к ZK Rollup
В целом, я твердо верю, что в ближайшие несколько лет Оптимистичные свертки будут доминировать. Некоторые думают, что ZK Rollups в конечном итоге превзойдут Optimistic Rollups, но я не согласен с этим мнением. Я чувствую, что нынешняя относительная простота и гибкость оптимистичных накопительных пакетов означает, что их можно постепенно преобразовать в накопительные пакеты ZK. Если мы сможем найти шаблон для этого перехода, то вместо того, чтобы пытаться построить более негибкую и хрупкую экосистему ZK, мы можем просто развернуться в уже существующей экосистеме Optimistic Rollup.
Поэтому моя цель — создать архитектуру и путь миграции, которые позволят существующей современной экосистеме OP (например, 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.
Ваша миссия превращается в время испытаний
Время доказательств с нулевым разглашением масштабируется по двум осям: количеству ограничений и размеру схемы. Сосредоточив внимание на схеме простой машины, такой как MIPS (а не на более сложной машине, такой как EVM), мы смогли значительно уменьшить размер и сложность схемы. Однако количество ограничений зависит от количества выполняемых машинных инструкций. Каждый код операции EVM разбивается на несколько кодов операций MIPS, что означает, что количество ограничений значительно увеличивается, как и общее время проверки.
Однако сокращение времени проверки также является проблемой, глубоко укоренившейся в домене Web2. Учитывая, что архитектура машины MIPS вряд ли изменится в ближайшее время, мы можем значительно оптимизировать схему и прувер независимо от будущих изменений в EVM. Я чувствую себя довольно уверенно, нанимая старшего инженера по оборудованию для оптимизации четко определенной проблемы, возможно, в десять или даже в сто раз больше инженеров, создающих и проверяющих движущуюся цель zkEVM. В такой компании, как Netflix, вероятно, есть большое количество инженеров по аппаратному обеспечению, оптимизирующих чипы транскодирования, и они, вероятно, готовы потратить кучу венчурных фондов, чтобы взять на себя эту интересную задачу ZK.
Первоначальное время проверки для такой схемы может превышать 7-дневный период вывода Optimistic Rollup. Это время доказательства будет только уменьшаться с течением времени. Внедряя ASIC и FPGA, мы можем значительно ускорить время проверки. Со статической целью мы можем построить более оптимальные пруверы.
В конце концов, время проверки для этой схемы будет меньше, чем текущий 7-дневный период снятия оптимизма, и мы можем начать процесс оспаривания, чтобы рассмотреть возможность удаления оптимизма. Запуск прувера в течение 7 дней, вероятно, все еще слишком дорог, поэтому мы могли бы подождать еще немного, но это разумно. Вы даже можете запускать обе системы доказательств одновременно, поэтому мы можем начать использовать доказательства ZK как можно быстрее и вернуться к доказательствам Optimism, если доказательство по какой-либо причине не работает. По готовности доказательства Optimism могут быть удалены полностью прозрачным для приложения способом, поэтому ваш Optimistic Rollup станет ZK Rollup.
Можешь пойти и заняться другими важными делами
Запуск блокчейна — сложная задача, которая включает в себя больше, чем просто написание большого количества внутреннего кода. В Optimism большая часть нашей работы сосредоточена на улучшении взаимодействия с пользователем и разработчиком за счет предоставления полезных клиентских инструментов. Мы также уделяем много времени и энергии «мягким» вопросам: беседам с проектами, пониманию их болевых точек и разработке стимулов. Чем больше времени вы тратите на сетевое программное обеспечение, тем меньше времени у вас остается на эти другие вещи. Хотя вы всегда можете попытаться нанять больше людей, организации не масштабируются линейно, и каждый новый наем увеличивает затраты на внутреннюю коммуникацию.
Поскольку работа схемы с нулевым разглашением может быть непосредственно применена к уже работающей цепочке, вы можете создать базовую платформу и одновременно разработать программное обеспечение для проверки. Поскольку клиент может быть изменен без изменения схемы, вы можете отделить клиента от группы проверки. Таким образом, Optimistic Rollup может на годы опередить конкурентов с нулевым разглашением с точки зрения фактической активности в сети.
в заключение
Откровенно говоря, я не вижу каких-либо существенных недостатков в прувере zkMIPS, если только его нельзя значительно оптимизировать с течением времени. Единственное реальное влияние, которое я вижу на приложение, заключается в том, что стоимость газа для различных кодов операций, возможно, потребуется скорректировать, чтобы отразить увеличенное время проверки для этих кодов операций. Если действительно невозможно оптимизировать этот прувер до разумного уровня, то я признаю, что потерпел неудачу. Но если этот прувер удастся оптимизировать, то подход zkMIPS/zkVM может полностью заменить текущий подход zkEVM. Это может показаться радикальным утверждением, но не так давно одноэтапные оптимистичные доказательства отказа были полностью заменены многоэтапными.
Оригинальная ссылка