В этом специальном диалоге приглашены ключевые разработчики протокола Plasma Mode tdot(, а также разработчик Redstone ) и соучредитель Optimism Бен Джонс. Optimism является ключевым двигателем OP Stack. Plasma Mode позволяет разработчикам строить на OP Stack, но не требует публикации данных в L1, а вместо этого может гибко переключаться на внешние поставщики данных, что экономит затраты и повышает масштабируемость. Они обсудили истоки сотрудничества Redstone и Optimism, важность возрождения Plasma, необходимость внедрения экспериментальных протоколов в производственные условия, будущее Plasma Mode и OP Stack, а также свои ожидания относительно развития области игр на полных цепях.
Как улучшить OP Stack с помощью режима Plasma
Ben: Каков процесс начала улучшения OP Stack?
tdot: Я присоединился к Lattice примерно год назад, отвечая за Plasma Mode. Цель была ясна: у нас есть много приложений MUD, которые потребляют огромное количество газа, и в то же время мы пытаемся разместить большое количество данных в цепочке, поэтому нам нужно решение, которое поддерживает эти требования и является дешевым. Команда Lattice уже провела некоторые эксперименты на OP Stack, например, прототипировала некоторые онлайновые миры и развернула их на OP Stack. Мы обнаружили, что OP Stack уже очень хорошо работает.
Итак, мы спросили себя: "Как сделать это дешевле?" Основное предположение заключается в том, что "мы считаем, что OP Stack является наиболее соответствующим философии Ethereum и полностью совместим с 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-вызова L1, на случай если данные будут загружены в цепь в процессе решения вызова.
Вот в чем суть. Это довольно сложно, потому что мы хотим сохранить элегантность и устойчивость. В то же время, это относительно простая концепция. Мы не пытались переизобрести колесо или изменить всю 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, которые хотят немедленно запуститься в основной сети. Нам нужно как можно быстрее подготовить основную сеть для этих игр. Люди уже ждут и готовы. Вам нужна цепочка, которая может быстро запуститься и работать, чтобы запустить все эти приложения, так что эти приложения могут развиваться параллельно, пока мы решаем проблемы и становимся лучше. От разработки до достижения стабильности в производстве требуется много времени.
Чтобы вывести что-то на основную сеть, сделать его без разрешений, надежным и безопасным, требуется много времени. Видеть весь процесс достижения этой цели уже впечатляет. Вот почему нам нужно поддерживать высокую степень гибкости, потому что слишком много дел. Вся экосистема развивается очень быстро. Я думаю, что все предоставляют множество инноваций. Вот почему вы должны успевать, но вы также не можете идти на компромисс по безопасности и производительности, иначе система не сможет функционировать.
Ben: Или это техническая нагрузка. Принцип минимальных изменений, который вы упомянули, является одной из наших основных идей при переписывании 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: Говоря об этом, это будет еще одно испытание для модульности OP Stack. Мы с нетерпением ждем доказательства ошибок (fault proofs), о которых вы упомянули, в Plasma.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Соучредитель Optimism обсуждает будущее OP Stack с разработчиком Plasma Mode
DEVS ON DEVS: ТДОТ и БЕН ДЖОНС в диалоге
В этом специальном диалоге приглашены ключевые разработчики протокола Plasma Mode tdot(, а также разработчик Redstone ) и соучредитель Optimism Бен Джонс. Optimism является ключевым двигателем OP Stack. Plasma Mode позволяет разработчикам строить на OP Stack, но не требует публикации данных в L1, а вместо этого может гибко переключаться на внешние поставщики данных, что экономит затраты и повышает масштабируемость. Они обсудили истоки сотрудничества Redstone и Optimism, важность возрождения Plasma, необходимость внедрения экспериментальных протоколов в производственные условия, будущее Plasma Mode и OP Stack, а также свои ожидания относительно развития области игр на полных цепях.
Как улучшить OP Stack с помощью режима Plasma
Ben: Каков процесс начала улучшения OP Stack?
tdot: Я присоединился к Lattice примерно год назад, отвечая за Plasma Mode. Цель была ясна: у нас есть много приложений MUD, которые потребляют огромное количество газа, и в то же время мы пытаемся разместить большое количество данных в цепочке, поэтому нам нужно решение, которое поддерживает эти требования и является дешевым. Команда Lattice уже провела некоторые эксперименты на OP Stack, например, прототипировала некоторые онлайновые миры и развернула их на OP Stack. Мы обнаружили, что OP Stack уже очень хорошо работает.
Итак, мы спросили себя: "Как сделать это дешевле?" Основное предположение заключается в том, что "мы считаем, что OP Stack является наиболее соответствующим философии Ethereum и полностью совместим с 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-вызова L1, на случай если данные будут загружены в цепь в процессе решения вызова.
Вот в чем суть. Это довольно сложно, потому что мы хотим сохранить элегантность и устойчивость. В то же время, это относительно простая концепция. Мы не пытались переизобрести колесо или изменить всю 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, которые хотят немедленно запуститься в основной сети. Нам нужно как можно быстрее подготовить основную сеть для этих игр. Люди уже ждут и готовы. Вам нужна цепочка, которая может быстро запуститься и работать, чтобы запустить все эти приложения, так что эти приложения могут развиваться параллельно, пока мы решаем проблемы и становимся лучше. От разработки до достижения стабильности в производстве требуется много времени.
Чтобы вывести что-то на основную сеть, сделать его без разрешений, надежным и безопасным, требуется много времени. Видеть весь процесс достижения этой цели уже впечатляет. Вот почему нам нужно поддерживать высокую степень гибкости, потому что слишком много дел. Вся экосистема развивается очень быстро. Я думаю, что все предоставляют множество инноваций. Вот почему вы должны успевать, но вы также не можете идти на компромисс по безопасности и производительности, иначе система не сможет функционировать.
Ben: Или это техническая нагрузка. Принцип минимальных изменений, который вы упомянули, является одной из наших основных идей при переписывании 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: Говоря об этом, это будет еще одно испытание для модульности OP Stack. Мы с нетерпением ждем доказательства ошибок (fault proofs), о которых вы упомянули, в Plasma.