Разработчики о разработчиках: tdot и Бен Джонс в разговоре
В этом специальном выпуске Devs on Devs мы пригласили основного разработчика протокола Plasma Mode tdot(, который также является разработчиком Redstone ) и соучредителем Optimism Бена Джонса. Optimism является ключевым двигателем OP Stack. Plasma Mode позволяет разработчикам строить на OP Stack, не публикуя данные в L1, а гибко переключаться на поставщиков данных вне цепи, что позволяет сократить затраты и повысить масштабируемость. В разговоре они обсудили происхождение сотрудничества Redstone и Optimism, важность возрождения Plasma, необходимость внедрения экспериментальных протоколов в производственную среду, будущее Plasma Mode и OP Stack, а также их волнение по поводу развития области игр на блокчейне.
Как использовать режим Plasma для улучшения OP Stack
Бен: Каков процесс улучшения OP Stack?
tdot: Я присоединился к Lattice примерно год назад и отвечаю за Plasma Mode. Цель очень ясна: у нас есть много приложений MUD, которые потребляют огромное количество газа, и в то же время мы пытаемся разместить много данных в блокчейне, поэтому нам нужно решение, которое одновременно поддерживает эти требования и является дешевым. Команда Lattice уже провела некоторые эксперименты с OP Stack, например, прототипирование некоторых онлайновых миров и развертывание их на OP Stack. Мы обнаружили, что OP Stack уже очень удобен в использовании.
Итак, мы задаем себе вопрос: "Как сделать это дешевле?" Основное предположение состоит в том, что "мы считаем, что OP Stack является наиболее соответствующим идеалам Ethereum и полностью совместим с EVM.framework." То, что работает в основной сети, может также работать на OP Stack, это идеальное решение. Но мы хотим, чтобы это было дешевле.
В то время calldata все еще была источником доступности данных OP Stack цепи (DA), что было очень дорого. Поэтому, очевидно, мы не могли запустить L2 с помощью calldata, так как наши игры на полной цепи и миры MUD требуют более высокой пропускной способности. Поэтому мы решили начать пробовать другие решения доступности данных (Alt DA). На самом деле, в первоначальных документах OP Stack уже упоминалось о необходимости исследовать Alt DA.
Таким образом, мы задаем себе вопрос: "Что если начать с оффчейн DA?" Мы надеемся, что вся модель безопасности и все остальное смогут полагаться на L1 Ethereum. Поэтому мы избегали других решений Alt DA и решили хранить данные в централизованном DA-хранилище, а затем найти эффективную модель безопасности на L1.
Вот почему мы решили повторно использовать некоторые старые концепции Plasma и разместить их на rollup. Здесь есть несколько отличий. Главный вопрос заключается в том, как реализовать оффчейн DA и ончейн вызовы данных на существующем OP Stack? Наша цель - минимально изменить OP Stack, не влияя на путь rollup, поскольку мы не хотим повлиять на безопасность других rollup цепей, использующих OP Stack.
При проектировании rollup вы не будете думать: "Что произойдет, если кто-то изменит процесс генерации данных, чтобы хранить данные из других источников?" Даже с этими изменениями OP Stack остается очень мощным и хорошо работает сразу из коробки. Это первое изменение, которое мы сделали.
После этого нам нужно написать контракт для создания этих вызовов. Существуют вызовы DA, которые заставляют данные быть записанными в блокчейн. Это второй шаг, интеграция контракта в процесс. Мы должны построить всю интеграционную систему в процессе наследования, так чтобы вы могли выводить данные как из источника DA вне цепи, так и из контракта вызова L1 DA, на случай если данные будут отправлены в блокчейн во время решения вызова.
Вот в чем суть. Это довольно сложно, потому что мы хотим сохранить элегантность и надежность. В то же время, это относительно простая концепция. Мы не пытались заново изобрести всё или изменить весь OP Stack, а старались сохранить простоту в сложной среде. Так что в целом, это очень крутое инженерное путешествие.
Ben: Я могу поговорить об этом с точки зрения OP. Вы упомянули некоторые ранние работы Lattice. Как раз в то же время мы в Optimism практически полностью переписали весь OP Stack, и это обновление мы назвали Bedrock.
В основном, через два года после создания rollup мы сделали шаг назад и задумались: "Ну что ж, если мы хотим максимально использовать все полученные знания, как это будет выглядеть?" Это эволюция привела к созданию кодовой базы, известной как Bedrock, что является нашим самым большим обновлением для сети.
В то время мы сотрудничали с вами над проектом под названием OPCraft, я думаю, что Biomes является его духовным наследником, это было самое веселое время, которое мы провели в игре на блокчейне. В то же время, мы выдохнули с облегчением, потому что другие тоже могут использовать OP Stack для разработки. Я считаю, что важным поворотным моментом в масштабировании за последние несколько лет стало то, что многие люди могут запускать цепочку.
Не только те, кто разработал большие и сложные кодовые базы, могут это сделать. Когда мы начали сотрудничать, видеть, как другие могут взять на себя эту кодовую базу и сделать что-то действительно замечательное, — это огромная поддержка. А затем увидеть, как это масштабируется на Plasma в реальном применении, было просто здорово. Я даже могу немного рассказать об этой истории.
Прежде чем Optimism стал Optimism, мы на самом деле исследовали технологию под названием Plasma. В то время задачи, которые мы взяли на себя, значительно превышали возможности сообщества по масштабированию. Дизайн, который вы видите в ранних разработках Plasma, возможно, не имеет прямого соответствия с сегодняшним Plasma.
Сегодня Plasma стала намного проще. Мы разделим доказательства и вызовы состояния от вызовов данных. В конечном итоге, несколько лет назад мы осознали, что Rollups гораздо проще, чем Plasma. Я думаю, что тогда сообщество пришло к выводу, что "Plasma мертва". Это была шутка в истории масштабирования Ethereum того времени.
Но мы всегда считали, что "Plasma не мертва, просто мы можем сначала попробовать более простую задачу". Теперь мы используем другие термины. Например, тогда были концепции, такие как выходы (exits) и так далее, а сейчас вы можете вернуться назад и сказать: "О, это была задача по обеспечению доступности данных с некоторыми дополнительными шагами". Так что видеть, как OP Stack используется другими и эволюционирует в то, что мы изначально пытались сделать, но в очень запутанном и незрелом абстрактном виде, действительно удивительно. Мы завершили полный круг, и вы создали вокруг этого потрясающие абстракции и заставили это работать разумным и логичным образом. Это действительно здорово.
Самое важное - как можно скорее войти в производственную среду
tdot: В режиме Plasma все еще существуют некоторые проблемы и нерешенные вопросы, над которыми мы продолжаем работать. Ключевой вопрос в том, как избежать затраты времени в десять лет? Ты понимаешь, о чем я? Нам нужно как можно скорее достичь стадии, на которой можно будет предоставить результаты.
Вот в чем наша идея. У нас уже есть много приложений, разработанных на основе MUD, которые хотят немедленно выйти на основную сеть. Нам нужно как можно быстрее подготовить основную сеть для этих игр. Люди уже ждут и готовы. Вам нужна цепочка, которая может быстро запуститься и работать, чтобы запустить все эти приложения, так чтобы они могли развиваться параллельно, пока мы решаем проблемы и становимся лучше. От исследований и разработок до реализации стабильности в производстве требуется много времени.
Чтобы запустить что-то в основной сети, сделать это без разрешений, надежным и безопасным, требуется много времени. Удивительно видеть весь процесс, который мы прошли для достижения этой цели. Вот почему мы должны оставаться высоко агильными, потому что дел слишком много. Вся экосистема развивается очень быстро. Я думаю, что каждый вносит много инноваций. Вот почему вы должны идти в ногу со временем, но вы также не можете идти на компромисс в вопросах безопасности и производительности, иначе система не будет работать.
Бен: Или, можно сказать, техническое бремя. Принцип минимальных изменений, о котором вы упомянули, является одним из основных принципов нашей переработки Bedrock. Я говорил о полном переписывании от начала до конца, но важнее всего то, что мы уменьшили примерно на 50 000 строк кода, что само по себе очень сильно. Потому что вы правы, такие вещи действительно очень трудны.
Каждая добавленная строка кода отдаляет вас от производственной среды, усложняя возможность практического тестирования и увеличивая количество ошибок. Поэтому мы очень благодарны вам за все усилия, которые вы прикладываете для продвижения этого процесса, особенно за вклад в новую операционную модель OP Stack.
tdot： OP Stack действительно создал способ, который позволяет вам быстро продвигаться в таких делах. Координировать всех очень трудно, потому что мы, очевидно, две разные компании. В Lattice мы строим игру, игровой движок и цепочку.
А вы строите сотни и тысячи вещей и регулярно поставляете все эти продукты. С точки зрения координации это действительно очень нелегко.
Ben: Да, действительно, нам еще предстоит пройти долгий путь. Но именно в этом и заключается основное очарование модульности. Для меня, с точки зрения OP Stack, это одна из самых захватывающих вещей, не говоря уже о тех удивительных играх и виртуальных мирах, которые сейчас строятся на Redstone. Чисто с точки зрения OP Stack, это очень мощный пример того, что множество отличных разработчиков уже присоединились и улучшили этот стек, что просто замечательно.
Это первый раз, когда вы можете значительно изменить свойства системы с помощью одного критического булева значения. Реализовать это полностью, как вы говорите, действительно предстоит еще долгий путь. Но даже близость к эффективной реализации требует поддержки модульности, не так ли? Для нас было облегчением увидеть, что вы достигли этого без необходимости, например, переписывать L2 Geth. Для меня это доказывает, что модульность работает.
tdot: Теперь ситуация стала лучше. Судя по этому примеру, вы превратили все в независимые модули, которые можно настраивать и изменять их свойства. Поэтому я с нетерпением жду, какие новые функции будут интегрированы. Я помню, мы беспокоились о том, что у нас есть ветка, содержащая все изменения для OP Stack, которые нужно будет объединить с основной веткой. Мы тогда подумали: "Боже, проверять все это будет безумие."
Мы вынуждены были разбить это на более мелкие части, но весь процесс прошёл очень гладко. Атмосфера сотрудничества в команде была очень хорошей, поэтому процесс проверки тоже был приятным. Это казалось очень естественным. И я думаю, что в отношении проверки и решения некоторых потенциальных проблем процесс шёл очень быстро. Всё прошло неожиданно гладко.
Бен: Это действительно здорово. В этом году одним из наших приоритетов является создание путей для вкладов в OP Stack. Поэтому я очень благодарен вам за участие в тестировании и продвижении этих процессов. Мне приятно, что эти процессы не оказались слишком сложными, и мы достигли некоторых результатов. Говоря об этом, мне любопытно, как, на ваш взгляд, будет развиваться эта работа в будущем? Что вы ожидаете от следующей разработки?
tdot: Существует множество различных направлений работы. Основное внимание уделяется интеграции механизма доказательства неисправности. Мы применяем прогрессивный подход к децентрализации всего технологического стека и увеличению его безлицензионных характеристик, конечная цель заключается в реализации безлицензионных функций и принудительного выхода.
У нас есть эта конечная цель, и мы постепенно ее достигаем, сохраняя при этом безопасность. Одна из проблем заключается в том, что иногда проще не выходить на основную сеть, потому что это исключает необходимость в жестком форке. Вы можете подумать: "О, я просто подожду, пока все будет полностью готово к выпуску, так что не будет необходимости в жестком форке и никаких технических затрат." Но если вы хотите быстро запустить основную сеть, вам придется справляться с этими сложными обновлениями и часто делать релизы. Сделать это и при этом поддерживать высокую доступность всегда является вызовом.
Я считаю, что после подготовки механизма доказательства сбоев и всех этих частей будет много обновлений в аспекте модели Plasma. Я думаю, что в области пакетной отправки обязательств все еще есть место для оптимизации. Сейчас мы делаем все довольно просто, каждую транзакцию мы оформляем одним обязательством. А обязательство — это лишь хэш-значение входных данных, хранящихся вне цепи.
Мы временно сохраняем простоту, чтобы проверка могла быть простой и быстрой, и не было больших отличий от OP Stack. Но сейчас есть некоторые оптимизации, которые могут сделать это дешевле, например, пакетная обработка commitment или их отправка в blob, или использование других.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Сооснователи Optimism беседуют с разработчиками Plasma Mode о улучшениях OP Stack и будущем.
Разработчики о разработчиках: tdot и Бен Джонс в разговоре
В этом специальном выпуске Devs on Devs мы пригласили основного разработчика протокола Plasma Mode tdot(, который также является разработчиком Redstone ) и соучредителем Optimism Бена Джонса. Optimism является ключевым двигателем OP Stack. Plasma Mode позволяет разработчикам строить на OP Stack, не публикуя данные в L1, а гибко переключаться на поставщиков данных вне цепи, что позволяет сократить затраты и повысить масштабируемость. В разговоре они обсудили происхождение сотрудничества Redstone и Optimism, важность возрождения Plasma, необходимость внедрения экспериментальных протоколов в производственную среду, будущее Plasma Mode и OP Stack, а также их волнение по поводу развития области игр на блокчейне.
Как использовать режим Plasma для улучшения OP Stack
Бен: Каков процесс улучшения OP Stack?
tdot: Я присоединился к Lattice примерно год назад и отвечаю за Plasma Mode. Цель очень ясна: у нас есть много приложений MUD, которые потребляют огромное количество газа, и в то же время мы пытаемся разместить много данных в блокчейне, поэтому нам нужно решение, которое одновременно поддерживает эти требования и является дешевым. Команда Lattice уже провела некоторые эксперименты с OP Stack, например, прототипирование некоторых онлайновых миров и развертывание их на OP Stack. Мы обнаружили, что OP Stack уже очень удобен в использовании.
Итак, мы задаем себе вопрос: "Как сделать это дешевле?" Основное предположение состоит в том, что "мы считаем, что OP Stack является наиболее соответствующим идеалам Ethereum и полностью совместим с EVM.framework." То, что работает в основной сети, может также работать на OP Stack, это идеальное решение. Но мы хотим, чтобы это было дешевле.
В то время calldata все еще была источником доступности данных OP Stack цепи (DA), что было очень дорого. Поэтому, очевидно, мы не могли запустить L2 с помощью calldata, так как наши игры на полной цепи и миры MUD требуют более высокой пропускной способности. Поэтому мы решили начать пробовать другие решения доступности данных (Alt DA). На самом деле, в первоначальных документах OP Stack уже упоминалось о необходимости исследовать Alt DA.
Таким образом, мы задаем себе вопрос: "Что если начать с оффчейн DA?" Мы надеемся, что вся модель безопасности и все остальное смогут полагаться на L1 Ethereum. Поэтому мы избегали других решений Alt DA и решили хранить данные в централизованном DA-хранилище, а затем найти эффективную модель безопасности на L1.
Вот почему мы решили повторно использовать некоторые старые концепции Plasma и разместить их на rollup. Здесь есть несколько отличий. Главный вопрос заключается в том, как реализовать оффчейн DA и ончейн вызовы данных на существующем OP Stack? Наша цель - минимально изменить OP Stack, не влияя на путь rollup, поскольку мы не хотим повлиять на безопасность других rollup цепей, использующих OP Stack.
При проектировании rollup вы не будете думать: "Что произойдет, если кто-то изменит процесс генерации данных, чтобы хранить данные из других источников?" Даже с этими изменениями OP Stack остается очень мощным и хорошо работает сразу из коробки. Это первое изменение, которое мы сделали.
После этого нам нужно написать контракт для создания этих вызовов. Существуют вызовы DA, которые заставляют данные быть записанными в блокчейн. Это второй шаг, интеграция контракта в процесс. Мы должны построить всю интеграционную систему в процессе наследования, так чтобы вы могли выводить данные как из источника DA вне цепи, так и из контракта вызова L1 DA, на случай если данные будут отправлены в блокчейн во время решения вызова.
Вот в чем суть. Это довольно сложно, потому что мы хотим сохранить элегантность и надежность. В то же время, это относительно простая концепция. Мы не пытались заново изобрести всё или изменить весь OP Stack, а старались сохранить простоту в сложной среде. Так что в целом, это очень крутое инженерное путешествие.
Ben: Я могу поговорить об этом с точки зрения OP. Вы упомянули некоторые ранние работы Lattice. Как раз в то же время мы в Optimism практически полностью переписали весь OP Stack, и это обновление мы назвали Bedrock.
В основном, через два года после создания rollup мы сделали шаг назад и задумались: "Ну что ж, если мы хотим максимально использовать все полученные знания, как это будет выглядеть?" Это эволюция привела к созданию кодовой базы, известной как Bedrock, что является нашим самым большим обновлением для сети.
В то время мы сотрудничали с вами над проектом под названием OPCraft, я думаю, что Biomes является его духовным наследником, это было самое веселое время, которое мы провели в игре на блокчейне. В то же время, мы выдохнули с облегчением, потому что другие тоже могут использовать OP Stack для разработки. Я считаю, что важным поворотным моментом в масштабировании за последние несколько лет стало то, что многие люди могут запускать цепочку.
Не только те, кто разработал большие и сложные кодовые базы, могут это сделать. Когда мы начали сотрудничать, видеть, как другие могут взять на себя эту кодовую базу и сделать что-то действительно замечательное, — это огромная поддержка. А затем увидеть, как это масштабируется на Plasma в реальном применении, было просто здорово. Я даже могу немного рассказать об этой истории.
Прежде чем Optimism стал Optimism, мы на самом деле исследовали технологию под названием Plasma. В то время задачи, которые мы взяли на себя, значительно превышали возможности сообщества по масштабированию. Дизайн, который вы видите в ранних разработках Plasma, возможно, не имеет прямого соответствия с сегодняшним Plasma.
Сегодня Plasma стала намного проще. Мы разделим доказательства и вызовы состояния от вызовов данных. В конечном итоге, несколько лет назад мы осознали, что Rollups гораздо проще, чем Plasma. Я думаю, что тогда сообщество пришло к выводу, что "Plasma мертва". Это была шутка в истории масштабирования Ethereum того времени.
Но мы всегда считали, что "Plasma не мертва, просто мы можем сначала попробовать более простую задачу". Теперь мы используем другие термины. Например, тогда были концепции, такие как выходы (exits) и так далее, а сейчас вы можете вернуться назад и сказать: "О, это была задача по обеспечению доступности данных с некоторыми дополнительными шагами". Так что видеть, как OP Stack используется другими и эволюционирует в то, что мы изначально пытались сделать, но в очень запутанном и незрелом абстрактном виде, действительно удивительно. Мы завершили полный круг, и вы создали вокруг этого потрясающие абстракции и заставили это работать разумным и логичным образом. Это действительно здорово.
Самое важное - как можно скорее войти в производственную среду
tdot: В режиме Plasma все еще существуют некоторые проблемы и нерешенные вопросы, над которыми мы продолжаем работать. Ключевой вопрос в том, как избежать затраты времени в десять лет? Ты понимаешь, о чем я? Нам нужно как можно скорее достичь стадии, на которой можно будет предоставить результаты.
Вот в чем наша идея. У нас уже есть много приложений, разработанных на основе MUD, которые хотят немедленно выйти на основную сеть. Нам нужно как можно быстрее подготовить основную сеть для этих игр. Люди уже ждут и готовы. Вам нужна цепочка, которая может быстро запуститься и работать, чтобы запустить все эти приложения, так чтобы они могли развиваться параллельно, пока мы решаем проблемы и становимся лучше. От исследований и разработок до реализации стабильности в производстве требуется много времени.
Чтобы запустить что-то в основной сети, сделать это без разрешений, надежным и безопасным, требуется много времени. Удивительно видеть весь процесс, который мы прошли для достижения этой цели. Вот почему мы должны оставаться высоко агильными, потому что дел слишком много. Вся экосистема развивается очень быстро. Я думаю, что каждый вносит много инноваций. Вот почему вы должны идти в ногу со временем, но вы также не можете идти на компромисс в вопросах безопасности и производительности, иначе система не будет работать.
Бен: Или, можно сказать, техническое бремя. Принцип минимальных изменений, о котором вы упомянули, является одним из основных принципов нашей переработки Bedrock. Я говорил о полном переписывании от начала до конца, но важнее всего то, что мы уменьшили примерно на 50 000 строк кода, что само по себе очень сильно. Потому что вы правы, такие вещи действительно очень трудны.
Каждая добавленная строка кода отдаляет вас от производственной среды, усложняя возможность практического тестирования и увеличивая количество ошибок. Поэтому мы очень благодарны вам за все усилия, которые вы прикладываете для продвижения этого процесса, особенно за вклад в новую операционную модель OP Stack.
tdot： OP Stack действительно создал способ, который позволяет вам быстро продвигаться в таких делах. Координировать всех очень трудно, потому что мы, очевидно, две разные компании. В Lattice мы строим игру, игровой движок и цепочку.
А вы строите сотни и тысячи вещей и регулярно поставляете все эти продукты. С точки зрения координации это действительно очень нелегко.
Ben: Да, действительно, нам еще предстоит пройти долгий путь. Но именно в этом и заключается основное очарование модульности. Для меня, с точки зрения OP Stack, это одна из самых захватывающих вещей, не говоря уже о тех удивительных играх и виртуальных мирах, которые сейчас строятся на Redstone. Чисто с точки зрения OP Stack, это очень мощный пример того, что множество отличных разработчиков уже присоединились и улучшили этот стек, что просто замечательно.
Это первый раз, когда вы можете значительно изменить свойства системы с помощью одного критического булева значения. Реализовать это полностью, как вы говорите, действительно предстоит еще долгий путь. Но даже близость к эффективной реализации требует поддержки модульности, не так ли? Для нас было облегчением увидеть, что вы достигли этого без необходимости, например, переписывать L2 Geth. Для меня это доказывает, что модульность работает.
tdot: Теперь ситуация стала лучше. Судя по этому примеру, вы превратили все в независимые модули, которые можно настраивать и изменять их свойства. Поэтому я с нетерпением жду, какие новые функции будут интегрированы. Я помню, мы беспокоились о том, что у нас есть ветка, содержащая все изменения для OP Stack, которые нужно будет объединить с основной веткой. Мы тогда подумали: "Боже, проверять все это будет безумие."
Мы вынуждены были разбить это на более мелкие части, но весь процесс прошёл очень гладко. Атмосфера сотрудничества в команде была очень хорошей, поэтому процесс проверки тоже был приятным. Это казалось очень естественным. И я думаю, что в отношении проверки и решения некоторых потенциальных проблем процесс шёл очень быстро. Всё прошло неожиданно гладко.
Бен: Это действительно здорово. В этом году одним из наших приоритетов является создание путей для вкладов в OP Stack. Поэтому я очень благодарен вам за участие в тестировании и продвижении этих процессов. Мне приятно, что эти процессы не оказались слишком сложными, и мы достигли некоторых результатов. Говоря об этом, мне любопытно, как, на ваш взгляд, будет развиваться эта работа в будущем? Что вы ожидаете от следующей разработки?
tdot: Существует множество различных направлений работы. Основное внимание уделяется интеграции механизма доказательства неисправности. Мы применяем прогрессивный подход к децентрализации всего технологического стека и увеличению его безлицензионных характеристик, конечная цель заключается в реализации безлицензионных функций и принудительного выхода.
У нас есть эта конечная цель, и мы постепенно ее достигаем, сохраняя при этом безопасность. Одна из проблем заключается в том, что иногда проще не выходить на основную сеть, потому что это исключает необходимость в жестком форке. Вы можете подумать: "О, я просто подожду, пока все будет полностью готово к выпуску, так что не будет необходимости в жестком форке и никаких технических затрат." Но если вы хотите быстро запустить основную сеть, вам придется справляться с этими сложными обновлениями и часто делать релизы. Сделать это и при этом поддерживать высокую доступность всегда является вызовом.
Я считаю, что после подготовки механизма доказательства сбоев и всех этих частей будет много обновлений в аспекте модели Plasma. Я думаю, что в области пакетной отправки обязательств все еще есть место для оптимизации. Сейчас мы делаем все довольно просто, каждую транзакцию мы оформляем одним обязательством. А обязательство — это лишь хэш-значение входных данных, хранящихся вне цепи.
Мы временно сохраняем простоту, чтобы проверка могла быть простой и быстрой, и не было больших отличий от OP Stack. Но сейчас есть некоторые оптимизации, которые могут сделать это дешевле, например, пакетная обработка commitment или их отправка в blob, или использование других.