РАЗРАБОТЧИКИ О РАЗРАБОТЧИКАХ: РАЗГОВОР TDOT И БЕНА ДЖОНСА

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

01. Как использовать режим Plasma для улучшения OP Stack

Ben: Каков процесс начала улучшения 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 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-вызова уровня 1, на случай, если данные будут отправлены в цепь в процессе решения вызова.

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

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 и какие у него разные предположения о безопасности.

Бен: Говоря об этом,