Интервью с разработчиками Optimism и Redstone: Модель Plasma преображает Уровень 2

В этом специальном интервью мы пригласили ключевого разработчика основного протокола Plasma Mode tdot(, который также является разработчиком Redstone ), и соучредителя Optimism Бена Джонса. Optimism является основным двигателем OP Stack. Plasma Mode позволяет разработчикам строить на OP Stack, но не требует публикации данных на L1, а позволяет гибко переключаться на оффчейн-поставщиков данных, тем самым экономя средства и повышая масштабируемость. В этом разговоре они обсудили происхождение сотрудничества Redstone и Optimism, важность возрождения Plasma, необходимость внедрения экспериментальных протоколов в производственную среду, будущее Plasma Mode и OP Stack, а также их восторг по поводу развития области полного игрового контента.

01. Как улучшить OP Stack с помощью режима Plasma

Бен: Каков процесс начала улучшения OP Stack?

tdot: Я присоединился к Lattice примерно год назад и отвечаю за Plasma Mode. Цель очень ясна: у нас есть множество приложений MUD, которые потребляют большое количество газа, в то время как мы пытаемся разместить большое количество данных в цепочке, поэтому нам нужно решение, которое одновременно поддерживает эти потребности и является дешевым. Команда Lattice уже провела некоторые эксперименты на OP Stack, например, прототипировала некоторые миры на цепочке и развернула их на OP Stack. Мы обнаружили, что OP Stack уже очень удобен в использовании.

Итак, мы задаем себе вопрос: "Как сделать это дешевле?" Основное предположение заключается в том, что "мы считаем, что OP Stack является наиболее соответствующей философии Эфириума и полностью совместимой с EVM платформой." То, что работает в основной сети, может также работать на OP Stack, что является идеальным решением. Но мы хотим, чтобы это было дешевле.

На тот момент calldata все еще была источником доступности данных OP Stack цепи (DA), что было очень дорого. Поэтому мы явно не могли запустить L2 с помощью calldata, поскольку наши игры с полным цепочным взаимодействием и мир MUD требуют более высокой пропускной способности. Таким образом, мы решили начать эксперименты с другими решениями доступности данных (Alt DA). На самом деле, в первоначальной документации OP Stack уже упоминалось о необходимости исследовать Alt DA.

Итак, мы задали себе вопрос: "Что произойдет, если начать с оффчейн DA?" Мы надеемся, что вся безопасность модели и все остальное могут полагаться на L1 Эфириум. Поэтому мы избегали других решений Alt DA и решили хранить данные в централизованном DA-хранилище, а затем найти эффективную модель безопасности на L1.

Вот почему мы решили повторно использовать некоторые старые концепции Plasma и разместить их на rollup. Здесь есть некоторые отличия. Самый большой вопрос заключается в том, как реализовать оффчейн DA и ончейн вызовы данных на существующем OP Stack? Наша цель — минимально изменить OP Stack, не повлияв на путь rollup, потому что мы не хотим влиять на безопасность других цепочек rollup, использующих OP Stack.

При проектировании rollup вы не думаете: "Что произойдет, если кто-то изменит процесс генерации данных для хранения данных из других источников?" Даже с этими изменениями OP Stack по-прежнему очень мощен и отлично работает из коробки. Это первое изменение, которое мы сделали.

После этого нам нужно написать контракт для создания этих вызовов. Существуют DA-вызовы, которые принудительно помещают данные в цепочку. Это второй шаг, интеграция контракта в процесс. Мы должны построить всю интеграционную систему в процессе деривации, чтобы вы могли получать данные из источника DA вне цепи и контракта DA вызова L1, на случай если данные будут отправлены в цепочку в процессе решения вызова.

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

Бен: Я могу поговорить с точки зрения 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 используется другими и эволюционировал в то, что мы изначально пытались сделать, но в очень запутанном и незрелом абстрактном виде. Мы завершили полный цикл, и вы вокруг этого сделали отличную абстракцию, заставив это работать разумным и логичным образом. Это действительно круто.

02. Самое важное - как можно скорее войти в производственную среду

tdot: В Plasma-режиме все еще существуют некоторые проблемы и нерешенные вопросы, над которыми мы продолжаем работать. Ключевым моментом является то, как избежать затраты до десяти лет времени? Ты понимаешь, что я имею в виду? Нам нужно как можно скорее достичь стадии, когда можно будет предоставить результаты.

Вот что мы думаем. У нас уже есть много приложений, разработанных на основе MUD, которые хотят немедленно выйти на основную сеть. Нам нужно как можно скорее подготовить основную сеть для этих игр. Люди уже ждут и готовы. Вам нужна быстрая сеть, которая может запуститься и работать, чтобы управлять всеми этими приложениями, так что эти приложения могут развиваться параллельно, пока мы решаем проблемы, становясь лучше. От разработки до достижения производственной стабильности требуется много времени.

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

Бен: Или это можно назвать техническим бременем. Принцип минимальных изменений, о котором вы упомянули, является одной из основных концепций нашего переписывания Bedrock. Я говорил о полном переписывании от начала до конца, но что более важно, мы сократили примерно 50 000 строк кода, что само по себе очень мощно. Потому что вы правы, эти вещи действительно сложны.

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

tdot: OP Stack действительно создал способ, который позволяет вам быстро продвигаться в таких делах. Координировать всех очень трудно, потому что мы, очевидно, две разные компании. В Lattice мы строим игру, игровой движок и цепочку.

А вы строите сотни и тысячи вещей и регулярно поставляете все эти продукты. С точки зрения координации это действительно очень непросто.

Ben: Да, действительно, впереди еще долгий путь. Но в этом и заключается основное очарование модульности. Для меня это одна из самых захватывающих вещей с точки зрения OP Stack, не говоря уже о тех потрясающих играх и виртуальных мирах, которые сейчас строятся на Redstone. Чисто с точки зрения OP Stack это очень мощный пример того, что много отличных разработчиков ядра уже присоединились и улучшили этот стек, что просто замечательно.

Это первый раз, когда вы можете значительно изменить свойства системы с помощью одного ключевого булевого значения. Как вы и сказали, еще предстоит проделать долгий путь, чтобы сделать это полностью. Но даже близость к эффективному осуществлению этого требует модульной поддержки, не так ли? Для нас было обнадеживающе видеть, что вы достигли этого без необходимости, например, переписывать L2 Geth. Для меня это доказывает, что модульность действительно работает.

tdot: Ситуация теперь стала лучше. Из этого примера видно, что вы превратили все в независимые маленькие модули, которые можно настраивать и изменять их свойства. Поэтому я с нетерпением жду, какие новые функции будут интегрированы. Я помню, что мы когда-то беспокоились о том, что у нас есть ответвление, содержащее все изменения для OP Stack, которые нужно было объединить с основной веткой. Мы тогда думали: "Боже, проверять все это было бы безумно."

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

Ben: Это просто великолепно. В этом году одним из наших приоритетов является создание путей для вклада в OP Stack. Поэтому я очень благодарен вам за участие в тестировании и продвижении этих процессов. Я рад, что эти процессы не были невыносимыми, и мы добились некоторых результатов. Говоря об этом, мне любопытно, как с вашей точки зрения будет развиваться эта работа в дальнейшем? Что вы ждете с нетерпением в следующей разработке?

tdot: Есть много различных направлений работы. Основное направление связано с интеграцией механизма доказательства отказа. Мы используем прогрессивный подход к децентрализации всего технологического стека и увеличению его безлицензионных характеристик, конечная цель - реализовать функции, такие как безлицензионность и принудительный выход.

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

Я считаю, что после того, как механизм доказательства сбоя и все эти части будут готовы, в аспектах модели Plasma будет много обновлений. Я думаю, что в области пакетной подачи обязательств все еще есть возможность для оптимизации. Сейчас мы делаем это очень просто, каждую транзакцию с одним обязательством. А обязательство — это просто хэш-значение входных данных, хранящихся вне цепи.

Мы временно сохраняем максимально простоту, чтобы проверка могла быть простой и быстрой, и при этом не иметь больших отличий от OP Stack. Но сейчас есть некоторые оптимизации, которые могут сделать это дешевле, например, пакетная обработка обязательств или их отправка в blob, или использование других различных методов. Поэтому мы определенно исследуем это, чтобы снизить стоимость L1.

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

Многие из этих задач, безусловно, должны быть выполнены вами. Но мы хотим понять, как это будет выглядеть в режиме Plasma и с различными предположениями о безопасности.

Ben: Говоря об этом, это