РАЗРАБОТЧИКИ О РАЗРАБОТЧИКАХ: Поговорите с 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." То, что работает в основной сети, может работать и на OP Stack, это идеальное решение. Но мы хотим, чтобы это было дешевле.
В то время calldata все еще была источником доступности данных OP Stack цепи (DA), что было очень дорого. Поэтому мы явно не могли запустить L2 с помощью calldata, так как наша игра на полной цепи и мир MUD требуют более высокой пропускной способности. Поэтому мы решили начать пробовать другие схемы доступности данных (Alt DA). На самом деле, в первоначальных документах OP Stack уже упоминалось о необходимости изучения Alt DA.
Итак, мы спросили себя: "Что будет, если начать с оффчейн DA?" Мы надеемся, что вся модель безопасности и все остальное смогут полагаться на L1 Эфириум. Поэтому мы избегали других альтернативных DA решений и решили хранить данные в централизованном DA хранилище, а затем найти эффективную модель безопасности на L1.
Вот почему мы хотим повторно использовать некоторые старые концепции Plasma и разместить их на rollup. Здесь есть некоторые отличия. Главный вопрос заключается в том, как реализовать оффчейн DA и ончейн вызовы данных на существующем OP Stack? Наша цель заключается в том, чтобы внести как можно меньше изменений в OP Stack, не влияя на путь rollup, поскольку мы не хотим влиять на безопасность других rollup-цепей, использующих OP Stack.
При проектировании rollup вы не думаете: "Что произойдет, если кто-то изменит процесс генерации данных, чтобы хранить данные из других источников?" Даже с этими изменениями OP Stack по-прежнему очень мощен, и работает отлично из коробки. Это первое изменение, которое мы сделали.
Затем нам нужно написать контракт для создания этих вызовов. Существуют DA-вызовы, которые принудительно загружают данные в блокчейн. Это второй шаг — интеграция контракта в процесс. Мы должны построить всю интеграционную систему в процессе деривации, чтобы вы могли извлекать данные как из источника DA вне цепи, так и из контракта DA на L1, на случай если данные будут загружены в блокчейн во время решения вызова.
Вот в чем суть. Это довольно сложно, потому что мы хотим сохранить элегантность и надежность вещей. В то же время это относительно простая концепция. Мы не пытались заново изобретать колесо или менять весь стек OP, а старались сохранить простоту в сложной среде. Так что в целом это очень крутое инженерное путешествие.
Бен: Я могу поговорить с точки зрения OP. Вы упомянули некоторые ранние работы Lattice. В то же время мы в Optimism практически переписали весь стек OP с нуля, и это обновление мы назвали 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 мы строим игру, игровой движок и цепочку.
А вы строите сотни и тысячи вещей и регулярно поставляете все эти продукты. С точки зрения координации это действительно очень сложно.
Бен: Да, действительно, впереди еще долгий путь. Но в этом и заключается основная привлекательность модульности. Для меня, с точки зрения OP Stack, это одна из самых захватывающих вещей, не говоря уже о тех потрясающих играх и виртуальных мирах, которые сейчас строятся на Redstone. Чисто с точки зрения OP Stack, это очень мощный пример того, как многие отличные основные разработчики уже присоединились к этому и улучшили этот стек, что просто поразительно.
Это первый раз, когда вы можете значительно изменить свойства системы с помощью одного ключевого булевого значения. Как вы и сказали, чтобы полностью этого добиться, действительно еще предстоит проделать долгий путь. Но даже для того, чтобы близко к эффективно это реализовать, нужна модульная поддержка, не так ли? Для нас было облегчением видеть, что вы достигли этого без необходимости, например, переписывать L2 Geth. Для меня это доказывает, что модульность работает.
tdot: Сейчас ситуация стала лучше. Судя по этому примеру, вы превратили все в независимые небольшие модули, которые можно настраивать и изменять свойства. Поэтому я с нетерпением жду, какие новые функции будут интегрированы. Я помню, что мы когда-то беспокоились о том, что у нас есть форк, содержащий все изменения для OP Stack, которые нужно будет объединить с основной веткой. Мы тогда думали: "Боже мой, проверять все это будет безумно."
Мы были вынуждены разбить это на более мелкие части, но весь процесс прошел очень гладко. Атмосфера сотрудничества в команде была очень хорошей, поэтому процесс рецензирования также был приятным. Это казалось очень естественным. И я думаю, что процесс рецензирования и решения некоторых потенциальных проблем прошел очень быстро. Все прошло неожиданно гладко.
Бен: Это действительно замечательно. В этом году одним из наших главных приоритетов является создание пути для внесения вклада в OP Stack. Поэтому я очень благодарен вам за участие в тестировании и продвижении этих процессов. Я рад, что эти процессы не оказались слишком сложными, и мы добились некоторых результатов. Говоря об этом, мне любопытно, как, на ваш взгляд, будет развиваться эта работа в дальнейшем? Что вы ожидаете разработать в следующем?
tdot: Существует множество различных направлений работы. Основное внимание уделяется интеграции с механизмом доказательства ошибок. Мы используем прогрессивный подход для децентрализации всего технологического стека и увеличения его безлицензионных характеристик, конечная цель заключается в реализации безлицензионных функций и принудительного выхода.
У нас есть эта окончательная цель, и мы постепенно реализуем её, сохраняя при этом безопасность. Одна из проблем заключается в том, что иногда проще не выходить на основную сеть, так как это избавляет от необходимости проводить хард-форк. Вы можете подумать: "О, я просто подожду, пока всё будет полностью готово для выпуска, так не придется проводить хард-форк и не будет технической нагрузки." Однако, если вы хотите быстро запустить основную сеть, вам придется справляться с этими сложными обновлениями и часто выпускать новые версии. Сделать это и при этом поддерживать высокую доступность всегда является вызовом.
Я считаю, что после того, как механизм доказательства отказа и все эти части будут готовы, в аспектах Plasma-модели будет много обновлений. Я думаю, что в области пакетной подачи обязательств все еще есть пространство для оптимизации. В настоящее время мы делаем это очень просто, каждую транзакцию с одним обязательством. А обязательство — это просто хеш-значение входных данных, хранящихся вне цепи.
Мы временно сохраняем все как можно более простым, чтобы проверки могли быть простыми и быстрыми, и чтобы не было больших различий с OP Stack. Однако сейчас есть некоторые оптимизации, которые могут сделать это дешевле, например, пакетная обработка обязательств или их отправка в blob, или использование других различных методов. Поэтому мы определенно будем изучать этот вопрос, чтобы снизить затраты на L1.
Это то, чему мы очень рады. Конечно, мы также с нетерпением ожидаем всего, что связано с предстоящей совместимостью, и возможности взаимодействовать между всеми цепочками. Понять это будет огромным шагом вперед для пользователей.
Многие из этих задач определенно должны быть выполнены вами. Но мы хотим понять, как это будет выглядеть в режиме Plasma и с различными предположениями о безопасности.
Бен: Говоря об этом, это будет еще одно испытание для модульности OP Stack. Ты упомянул
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
15 Лайков
Награда
15
6
Поделиться
комментарий
0/400
YieldHunter
· 08-04 00:52
технически говоря... не уверен в надежности вне блокчейна данных smh
Посмотреть ОригиналОтветить0
DaoResearcher
· 08-04 00:51
Исходя из треугольника доступности данных, эта идея просто гениальна.
Соучредитель Optimism обсуждает будущее OP Stack с разработчиками Plasma Mode
РАЗРАБОТЧИКИ О РАЗРАБОТЧИКАХ: Поговорите с 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." То, что работает в основной сети, может работать и на OP Stack, это идеальное решение. Но мы хотим, чтобы это было дешевле.
В то время calldata все еще была источником доступности данных OP Stack цепи (DA), что было очень дорого. Поэтому мы явно не могли запустить L2 с помощью calldata, так как наша игра на полной цепи и мир MUD требуют более высокой пропускной способности. Поэтому мы решили начать пробовать другие схемы доступности данных (Alt DA). На самом деле, в первоначальных документах OP Stack уже упоминалось о необходимости изучения Alt DA.
Итак, мы спросили себя: "Что будет, если начать с оффчейн DA?" Мы надеемся, что вся модель безопасности и все остальное смогут полагаться на L1 Эфириум. Поэтому мы избегали других альтернативных DA решений и решили хранить данные в централизованном DA хранилище, а затем найти эффективную модель безопасности на L1.
Вот почему мы хотим повторно использовать некоторые старые концепции Plasma и разместить их на rollup. Здесь есть некоторые отличия. Главный вопрос заключается в том, как реализовать оффчейн DA и ончейн вызовы данных на существующем OP Stack? Наша цель заключается в том, чтобы внести как можно меньше изменений в OP Stack, не влияя на путь rollup, поскольку мы не хотим влиять на безопасность других rollup-цепей, использующих OP Stack.
При проектировании rollup вы не думаете: "Что произойдет, если кто-то изменит процесс генерации данных, чтобы хранить данные из других источников?" Даже с этими изменениями OP Stack по-прежнему очень мощен, и работает отлично из коробки. Это первое изменение, которое мы сделали.
Затем нам нужно написать контракт для создания этих вызовов. Существуют DA-вызовы, которые принудительно загружают данные в блокчейн. Это второй шаг — интеграция контракта в процесс. Мы должны построить всю интеграционную систему в процессе деривации, чтобы вы могли извлекать данные как из источника DA вне цепи, так и из контракта DA на L1, на случай если данные будут загружены в блокчейн во время решения вызова.
Вот в чем суть. Это довольно сложно, потому что мы хотим сохранить элегантность и надежность вещей. В то же время это относительно простая концепция. Мы не пытались заново изобретать колесо или менять весь стек OP, а старались сохранить простоту в сложной среде. Так что в целом это очень крутое инженерное путешествие.
Бен: Я могу поговорить с точки зрения OP. Вы упомянули некоторые ранние работы Lattice. В то же время мы в Optimism практически переписали весь стек OP с нуля, и это обновление мы назвали 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 мы строим игру, игровой движок и цепочку.
А вы строите сотни и тысячи вещей и регулярно поставляете все эти продукты. С точки зрения координации это действительно очень сложно.
Бен: Да, действительно, впереди еще долгий путь. Но в этом и заключается основная привлекательность модульности. Для меня, с точки зрения OP Stack, это одна из самых захватывающих вещей, не говоря уже о тех потрясающих играх и виртуальных мирах, которые сейчас строятся на Redstone. Чисто с точки зрения OP Stack, это очень мощный пример того, как многие отличные основные разработчики уже присоединились к этому и улучшили этот стек, что просто поразительно.
Это первый раз, когда вы можете значительно изменить свойства системы с помощью одного ключевого булевого значения. Как вы и сказали, чтобы полностью этого добиться, действительно еще предстоит проделать долгий путь. Но даже для того, чтобы близко к эффективно это реализовать, нужна модульная поддержка, не так ли? Для нас было облегчением видеть, что вы достигли этого без необходимости, например, переписывать L2 Geth. Для меня это доказывает, что модульность работает.
tdot: Сейчас ситуация стала лучше. Судя по этому примеру, вы превратили все в независимые небольшие модули, которые можно настраивать и изменять свойства. Поэтому я с нетерпением жду, какие новые функции будут интегрированы. Я помню, что мы когда-то беспокоились о том, что у нас есть форк, содержащий все изменения для OP Stack, которые нужно будет объединить с основной веткой. Мы тогда думали: "Боже мой, проверять все это будет безумно."
Мы были вынуждены разбить это на более мелкие части, но весь процесс прошел очень гладко. Атмосфера сотрудничества в команде была очень хорошей, поэтому процесс рецензирования также был приятным. Это казалось очень естественным. И я думаю, что процесс рецензирования и решения некоторых потенциальных проблем прошел очень быстро. Все прошло неожиданно гладко.
Бен: Это действительно замечательно. В этом году одним из наших главных приоритетов является создание пути для внесения вклада в OP Stack. Поэтому я очень благодарен вам за участие в тестировании и продвижении этих процессов. Я рад, что эти процессы не оказались слишком сложными, и мы добились некоторых результатов. Говоря об этом, мне любопытно, как, на ваш взгляд, будет развиваться эта работа в дальнейшем? Что вы ожидаете разработать в следующем?
tdot: Существует множество различных направлений работы. Основное внимание уделяется интеграции с механизмом доказательства ошибок. Мы используем прогрессивный подход для децентрализации всего технологического стека и увеличения его безлицензионных характеристик, конечная цель заключается в реализации безлицензионных функций и принудительного выхода.
У нас есть эта окончательная цель, и мы постепенно реализуем её, сохраняя при этом безопасность. Одна из проблем заключается в том, что иногда проще не выходить на основную сеть, так как это избавляет от необходимости проводить хард-форк. Вы можете подумать: "О, я просто подожду, пока всё будет полностью готово для выпуска, так не придется проводить хард-форк и не будет технической нагрузки." Однако, если вы хотите быстро запустить основную сеть, вам придется справляться с этими сложными обновлениями и часто выпускать новые версии. Сделать это и при этом поддерживать высокую доступность всегда является вызовом.
Я считаю, что после того, как механизм доказательства отказа и все эти части будут готовы, в аспектах Plasma-модели будет много обновлений. Я думаю, что в области пакетной подачи обязательств все еще есть пространство для оптимизации. В настоящее время мы делаем это очень просто, каждую транзакцию с одним обязательством. А обязательство — это просто хеш-значение входных данных, хранящихся вне цепи.
Мы временно сохраняем все как можно более простым, чтобы проверки могли быть простыми и быстрыми, и чтобы не было больших различий с OP Stack. Однако сейчас есть некоторые оптимизации, которые могут сделать это дешевле, например, пакетная обработка обязательств или их отправка в blob, или использование других различных методов. Поэтому мы определенно будем изучать этот вопрос, чтобы снизить затраты на L1.
Это то, чему мы очень рады. Конечно, мы также с нетерпением ожидаем всего, что связано с предстоящей совместимостью, и возможности взаимодействовать между всеми цепочками. Понять это будет огромным шагом вперед для пользователей.
Многие из этих задач определенно должны быть выполнены вами. Но мы хотим понять, как это будет выглядеть в режиме Plasma и с различными предположениями о безопасности.
Бен: Говоря об этом, это будет еще одно испытание для модульности OP Stack. Ты упомянул