В этом специальном выпуске рубрики "Разработчик для разработчиков" мы пригласили основного разработчика протокола 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 все еще оставался источником доступности данных (DA) для цепочки OP Stack, что было очень дорого. Поэтому мы явно не могли использовать 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, а также из контракта L1 DA-вызова, на случай если данные будут отправлены в блокчейн в процессе решения вызова.
Вот в чем суть. Это довольно сложно, потому что мы хотим сохранить элегантность и надежность. В то же время это относительно простая концепция. Мы не пытались изобрести все заново или изменить весь 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, и
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
17 Лайков
Награда
17
7
Репост
Поделиться
комментарий
0/400
BlockchainGriller
· 08-08 01:09
plasma и op, оказывается, объединились.
Посмотреть ОригиналОтветить0
ReverseFOMOguy
· 08-07 07:16
Плазма снова начинает набирать популярность?
Посмотреть ОригиналОтветить0
GweiWatcher
· 08-07 07:15
вне блокчейна данные тоже все еще эта ловушка?
Посмотреть ОригиналОтветить0
RugPullAlarm
· 08-07 07:09
Снова обманывают пользователей концептуальными проектами, да?
Синергетические инновации Plasma-режима и OP Stack: диалог между разработчиками Redstone и Optimism
DEVS ON DEVS: Диалог TDOT и Бена Джонса
В этом специальном выпуске рубрики "Разработчик для разработчиков" мы пригласили основного разработчика протокола 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 все еще оставался источником доступности данных (DA) для цепочки OP Stack, что было очень дорого. Поэтому мы явно не могли использовать 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, а также из контракта L1 DA-вызова, на случай если данные будут отправлены в блокчейн в процессе решения вызова.
Вот в чем суть. Это довольно сложно, потому что мы хотим сохранить элегантность и надежность. В то же время это относительно простая концепция. Мы не пытались изобрести все заново или изменить весь 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, и