Devs on Devs: разговор с tdot и Беном Джонсом

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

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

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

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

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

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

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

Вот почему мы решили переиспользовать некоторые старые концепции Plasma и разместить их на rollup. Есть несколько отличий. Главный вопрос заключается в том, как реализовать off-chain DA и on-chain данные для вызова на существующем OP Stack? Наша цель - минимально изменить OP Stack, не оказывая никакого влияния на путь rollup, так как мы не хотим влиять на безопасность других rollup-цепей, использующих OP Stack.

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

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

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

Бен: Я могу поговорить с точки зрения OP. Вы упомянули некоторые ранние работы Lattice. Как раз в это же время мы практически переписали весь стек OP с нуля, этот релиз мы называем Bedrock.

В основном, спустя два года после создания rollup, мы сделали шаг назад и задумались: "Хорошо, если мы хотим максимально использовать все полученные знания, как это будет выглядеть?" Это привело к созданию библиотеки кода, которая в конечном итоге была названа Bedrock, что является нашим самым большим обновлением сети.

В то время мы сотрудничали с вами над проектом под названием OPCraft, и я считаю, что Biomes является его духовным наследником. Это было наше самое радостное время игры на цепочке. В то же время мы вздохнули с облегчением, потому что другие тоже могут использовать OP Stack для разработки. Я думаю, что еще одним важным поворотным моментом в расширении в последние несколько лет стало то, что многие люди могут запускать цепочку.

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

Перед созданием известного проекта Layer 2 мы на самом деле исследовали технологию под названием 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, которые необходимо будет объединить с основной веткой. Мы тогда думали: "Боже, проверять все это будет безумие."

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

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

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

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

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

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