РАЗРАБОТЧИКИ О РАЗРАБОТЧИКАХ: РАЗГОВОР 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 является самым подходящим для идеи 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. Здесь есть некоторые отличия. Самый большой вопрос заключается в том, как реализовать оффчейн DA и ончейн вызовы данных на существующем 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 используется другими, но и эволюционирует в то, что мы изначально пытались сделать, но в очень запутанной и незрелой абстрактной форме. Мы завершили полный цикл, и вы сделали вокруг этого отличные абстракции и заставили это работать разумным и рациональным образом. Это действительно круто.
02. Самое важное - как можно скорее войти в производственную среду
tdot: В режиме Plasma все еще есть некоторые проблемы и нерешенные вопросы, над которыми мы продолжаем работать. Ключевой момент заключается в том, как избежать затраты времени до десяти лет? Ты понимаешь, о чем я? Нам нужно как можно быстрее достичь стадии, на которой можно будет предоставить результаты.
Вот наши мысли. У нас уже есть много приложений, разработанных на основе MUD, которые мы хотим немедленно запустить в основной сети. Нам нужно как можно скорее подготовить основную сеть для этих игр. Люди уже ждут и готовы. Вам нужна цепочка, которая быстро запустится и будет работать, чтобы запустить все эти приложения, так чтобы они могли параллельно развиваться и становиться лучше, пока мы решаем проблемы. От разработки до достижения стабильности в производстве требуется много времени.
Чтобы запустить что-то в основной сети, сделать его без разрешений, устойчивым и безопасным, требуется много времени. Увидеть весь процесс, который мы прошли для достижения этой цели, уже удивительно. Вот почему нам нужно сохранять высокую гибкость, потому что дел слишком много. Вся экосистема развивается очень быстро. Я считаю, что каждый приносит много инноваций. Вот почему вы должны идти в ногу со временем, но при этом не можете идти на компромисс в вопросах безопасности и производительности, иначе система не сможет работать.
Ben: Или, скорее, техническое бремя. Принцип минимальных изменений, который вы упомянули, является одним из ключевых принципов, когда мы переписывали Bedrock. Я говорил о полном переписывании от начала до конца, но более важно то, что мы сократили примерно на 50,000 строк кода, что само по себе очень мощно. Потому что вы правы, такие вещи действительно сложны.
Каждая добавленная строка кода уводит вас дальше от производственной среды, делает вещи труднее для практического тестирования и вводит больше возможностей для ошибок. Поэтому мы очень благодарны вам за все усилия, вложенные в продвижение этого процесса, особенно за вклад в новый операционный режим OP Stack.
tdot: OP Stack действительно создал способ, который позволяет вам быстро продвигаться в таких делах. Координировать всех очень сложно, потому что мы, очевидно, две разные компании. В Lattice мы создаем игру, игровой движок и цепочку.
А вы строите сотни и тысячи вещей и регулярно поставляете все эти продукты. С точки зрения координации это действительно очень непросто.
Бен: Да, действительно, еще есть долгий путь впереди. Но именно в этом заключается основное очарование модульности. Для меня, с точки зрения OP Stack, это одна из самых захватывающих вещей, не говоря уже о тех удивительных играх и виртуальных мирах, которые сейчас строятся на Redstone. Чисто с точки зрения OP Stack это очень сильный пример того, что многие отличные разработчики ядра уже присоединились и улучшили этот стек, что просто потрясающе.
Это первый раз, когда вы можете значительно изменить свойства системы с помощью одного ключевого булева значения. Как вы и сказали, чтобы полностью это сделать, действительно еще предстоит долгий путь. Но даже для того, чтобы приблизиться к эффективному осуществлению этого, нужна поддержка модульности, не так ли? Для нас было настоящим облегчением видеть, что вы достигли этого без необходимости, например, переписывать L2 Geth. Для меня это доказывает, что модульность работает.
tdot: Ситуация сейчас стала лучше. Судя по этому примеру, вы превратили все в независимые небольшие модули, которые можно настраивать и изменять свойства. Поэтому я очень ожидаю увидеть, какие новые функции будут интегрированы. Я помню, что мы беспокоились, что у нас есть ответвление, включающее все изменения для OP Stack, которое нужно будет объединить с основной веткой. Мы тогда думали: "Боже, проверка всего этого будет безумной."
Мы были вынуждены разбить это на более мелкие части, но весь процесс проходил очень гладко. Атмосфера сотрудничества в команде была отличной, поэтому процесс рецензирования также был приятным. Это казалось очень естественным. И я думаю, что процесс рецензирования и решения некоторых потенциальных проблем проходил очень быстро. Все прошло неожиданно гладко.
Ben: Это действительно здорово. В этом году одним из наших приоритетов является создание пути для внесения вкладов в OP Stack. Поэтому я очень благодарен вам за участие в тестировании и продвижении этих процессов. Мне приятно видеть, что эти процессы не были слишком трудными, и мы достигли некоторых результатов. Говоря об этом, мне любопытно, как, по вашему мнению, будет развиваться эта работа дальше? Что вы больше всего ожидаете в следующей разработке?
tdot: Есть много различных направлений работы. Основное направление связано с интеграцией механизма доказательства неисправности. Мы используем прогрессивный подход для децентрализации всего технологического стека и увеличения его безлицензионных характеристик, конечная цель - реализовать такие функции, как безлицензионность и принудительный выход.
У нас есть эта конечная цель, и мы постепенно достигаем её, сохраняя при этом безопасность. Одной из проблем является то, что иногда проще не выходить на основную сеть, поскольку это избавляет от необходимости проводить хард-форк. Вы можете подумать: "О, я просто подожду, пока всё будет полностью готово к выпуску, тогда не нужно будет проводить хард-форк и не будет технической нагрузки." Но если вы хотите быстро запустить основную сеть, вам придется справляться с этими сложными обновлениями и часто выпускать обновления. Сделать это и при этом поддерживать высокую доступность всегда является вызовом.
Я считаю, что после готовности механизма доказательства сбоев и всех этих частей в Plasma-модели будет много обновлений. Я думаю, что в области массовой отправки обязательств все еще есть место для оптимизации. В настоящее время мы делаем это очень просто: каждую транзакцию мы обрабатываем с одним обязательством. А обязательство — это просто хеш-значение входных данных, хранящихся вне цепи.
Мы временно сохраняем как можно больше простоты, чтобы проверка могла быть простой и быстрой, и при этом не было больших различий с OP Stack. Но сейчас есть некоторые оптимизации, которые могут сделать это дешевле, например, пакетная обработка обязательств или их отправка в blob, или использование других различных методов. Поэтому мы определенно будем исследовать этот вопрос, чтобы снизить затраты на L1.
Это очень захватывающее событие для нас. Конечно, мы также с нетерпением ждем всего, что связано с межоперабельностью, и возможности взаимодействовать между всеми цепочками. Понять это будет огромным шагом вперед для пользователей.
Много из этих работ определенно должны быть выполнены вами. Но мы хотим понять, как это выглядит в режиме Plasma и с различными предположениями о безопасности.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
16 Лайков
Награда
16
6
Поделиться
комментарий
0/400
GateUser-0717ab66
· 5ч назад
Сколько это стоит?
Посмотреть ОригиналОтветить0
ImpermanentPhobia
· 19ч назад
Атмосферная группа пришла смотреть спектакль.
Посмотреть ОригиналОтветить0
just_another_wallet
· 19ч назад
плазма всё ещё может спасти?
Посмотреть ОригиналОтветить0
BlockchainDecoder
· 19ч назад
С технической точки зрения, действительно ли разумно выбирать селективную публикацию данных L1 в качестве компромиссного решения?
Посмотреть ОригиналОтветить0
GetRichLeek
· 19ч назад
сидеть в засаде. op半年了 到底能不能爆呀
Посмотреть ОригиналОтветить0
SchrodingerGas
· 19ч назад
Кто-нибудь посчитай, сколько газа сэкономит эта штука, подожду, пока нарисую модель.
Диалог Innovators 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, а также их восторг по поводу развития области игр на блокчейне.
01. Как использовать режим Plasma для улучшения OP Stack
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), что было очень дорого. Поэтому мы явно не могли использовать calldata для запуска L2, поскольку наши полные цепочные игры и миры MUD требуют более высокой пропускной способности. Таким образом, мы решили начать пробовать другие решения доступности данных (Alt DA). На самом деле, в первоначальной документации OP Stack уже упоминалось о необходимости изучения Alt DA.
Итак, мы задали себе вопрос: "Что будет, если начать с оффчейн DA?" Мы надеемся, что вся безопасность модели и все остальное смогут полагаться на L1 Ethereum. Поэтому мы избегали других решений Alt DA и решили хранить данные в централизованном DA хранилище, а затем найти эффективную модель безопасности на L1.
Вот почему мы хотим заново использовать некоторые старые концепции Plasma и поместить их на rollup. Здесь есть некоторые отличия. Самый большой вопрос заключается в том, как реализовать оффчейн DA и ончейн вызовы данных на существующем 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 используется другими, но и эволюционирует в то, что мы изначально пытались сделать, но в очень запутанной и незрелой абстрактной форме. Мы завершили полный цикл, и вы сделали вокруг этого отличные абстракции и заставили это работать разумным и рациональным образом. Это действительно круто.
02. Самое важное - как можно скорее войти в производственную среду
tdot: В режиме Plasma все еще есть некоторые проблемы и нерешенные вопросы, над которыми мы продолжаем работать. Ключевой момент заключается в том, как избежать затраты времени до десяти лет? Ты понимаешь, о чем я? Нам нужно как можно быстрее достичь стадии, на которой можно будет предоставить результаты.
Вот наши мысли. У нас уже есть много приложений, разработанных на основе MUD, которые мы хотим немедленно запустить в основной сети. Нам нужно как можно скорее подготовить основную сеть для этих игр. Люди уже ждут и готовы. Вам нужна цепочка, которая быстро запустится и будет работать, чтобы запустить все эти приложения, так чтобы они могли параллельно развиваться и становиться лучше, пока мы решаем проблемы. От разработки до достижения стабильности в производстве требуется много времени.
Чтобы запустить что-то в основной сети, сделать его без разрешений, устойчивым и безопасным, требуется много времени. Увидеть весь процесс, который мы прошли для достижения этой цели, уже удивительно. Вот почему нам нужно сохранять высокую гибкость, потому что дел слишком много. Вся экосистема развивается очень быстро. Я считаю, что каждый приносит много инноваций. Вот почему вы должны идти в ногу со временем, но при этом не можете идти на компромисс в вопросах безопасности и производительности, иначе система не сможет работать.
Ben: Или, скорее, техническое бремя. Принцип минимальных изменений, который вы упомянули, является одним из ключевых принципов, когда мы переписывали Bedrock. Я говорил о полном переписывании от начала до конца, но более важно то, что мы сократили примерно на 50,000 строк кода, что само по себе очень мощно. Потому что вы правы, такие вещи действительно сложны.
Каждая добавленная строка кода уводит вас дальше от производственной среды, делает вещи труднее для практического тестирования и вводит больше возможностей для ошибок. Поэтому мы очень благодарны вам за все усилия, вложенные в продвижение этого процесса, особенно за вклад в новый операционный режим OP Stack.
tdot: OP Stack действительно создал способ, который позволяет вам быстро продвигаться в таких делах. Координировать всех очень сложно, потому что мы, очевидно, две разные компании. В Lattice мы создаем игру, игровой движок и цепочку.
А вы строите сотни и тысячи вещей и регулярно поставляете все эти продукты. С точки зрения координации это действительно очень непросто.
Бен: Да, действительно, еще есть долгий путь впереди. Но именно в этом заключается основное очарование модульности. Для меня, с точки зрения OP Stack, это одна из самых захватывающих вещей, не говоря уже о тех удивительных играх и виртуальных мирах, которые сейчас строятся на Redstone. Чисто с точки зрения OP Stack это очень сильный пример того, что многие отличные разработчики ядра уже присоединились и улучшили этот стек, что просто потрясающе.
Это первый раз, когда вы можете значительно изменить свойства системы с помощью одного ключевого булева значения. Как вы и сказали, чтобы полностью это сделать, действительно еще предстоит долгий путь. Но даже для того, чтобы приблизиться к эффективному осуществлению этого, нужна поддержка модульности, не так ли? Для нас было настоящим облегчением видеть, что вы достигли этого без необходимости, например, переписывать L2 Geth. Для меня это доказывает, что модульность работает.
tdot: Ситуация сейчас стала лучше. Судя по этому примеру, вы превратили все в независимые небольшие модули, которые можно настраивать и изменять свойства. Поэтому я очень ожидаю увидеть, какие новые функции будут интегрированы. Я помню, что мы беспокоились, что у нас есть ответвление, включающее все изменения для OP Stack, которое нужно будет объединить с основной веткой. Мы тогда думали: "Боже, проверка всего этого будет безумной."
Мы были вынуждены разбить это на более мелкие части, но весь процесс проходил очень гладко. Атмосфера сотрудничества в команде была отличной, поэтому процесс рецензирования также был приятным. Это казалось очень естественным. И я думаю, что процесс рецензирования и решения некоторых потенциальных проблем проходил очень быстро. Все прошло неожиданно гладко.
Ben: Это действительно здорово. В этом году одним из наших приоритетов является создание пути для внесения вкладов в OP Stack. Поэтому я очень благодарен вам за участие в тестировании и продвижении этих процессов. Мне приятно видеть, что эти процессы не были слишком трудными, и мы достигли некоторых результатов. Говоря об этом, мне любопытно, как, по вашему мнению, будет развиваться эта работа дальше? Что вы больше всего ожидаете в следующей разработке?
tdot: Есть много различных направлений работы. Основное направление связано с интеграцией механизма доказательства неисправности. Мы используем прогрессивный подход для децентрализации всего технологического стека и увеличения его безлицензионных характеристик, конечная цель - реализовать такие функции, как безлицензионность и принудительный выход.
У нас есть эта конечная цель, и мы постепенно достигаем её, сохраняя при этом безопасность. Одной из проблем является то, что иногда проще не выходить на основную сеть, поскольку это избавляет от необходимости проводить хард-форк. Вы можете подумать: "О, я просто подожду, пока всё будет полностью готово к выпуску, тогда не нужно будет проводить хард-форк и не будет технической нагрузки." Но если вы хотите быстро запустить основную сеть, вам придется справляться с этими сложными обновлениями и часто выпускать обновления. Сделать это и при этом поддерживать высокую доступность всегда является вызовом.
Я считаю, что после готовности механизма доказательства сбоев и всех этих частей в Plasma-модели будет много обновлений. Я думаю, что в области массовой отправки обязательств все еще есть место для оптимизации. В настоящее время мы делаем это очень просто: каждую транзакцию мы обрабатываем с одним обязательством. А обязательство — это просто хеш-значение входных данных, хранящихся вне цепи.
Мы временно сохраняем как можно больше простоты, чтобы проверка могла быть простой и быстрой, и при этом не было больших различий с OP Stack. Но сейчас есть некоторые оптимизации, которые могут сделать это дешевле, например, пакетная обработка обязательств или их отправка в blob, или использование других различных методов. Поэтому мы определенно будем исследовать этот вопрос, чтобы снизить затраты на L1.
Это очень захватывающее событие для нас. Конечно, мы также с нетерпением ждем всего, что связано с межоперабельностью, и возможности взаимодействовать между всеми цепочками. Понять это будет огромным шагом вперед для пользователей.
Много из этих работ определенно должны быть выполнены вами. Но мы хотим понять, как это выглядит в режиме Plasma и с различными предположениями о безопасности.
Бен: