Neste episódio especial do Devs on Devs, convidamos o desenvolvedor principal do protocolo Plasma Mode, tdot(, que também é desenvolvedor da Redstone ) e cofundador da Optimism, Ben Jones. A Optimism é o principal impulsionador do OP Stack. O Plasma Mode permite que os desenvolvedores construam sobre o OP Stack, mas sem a necessidade de publicar dados na L1, podendo alternar flexivelmente para provedores de dados off-chain, economizando custos e melhorando a escalabilidade. Na conversa, eles discutiram a origem da colaboração entre Redstone e Optimism, a importância de reviver o Plasma, a necessidade de trazer protocolos experimentais para ambientes de produção, o futuro do Plasma Mode e do OP Stack, e sua empolgação com o desenvolvimento no campo dos jogos em toda a cadeia.
Como usar o modo Plasma para melhorar o OP Stack
Ben: Como é o processo de melhoria da OP Stack?
tdot: Juntei-me à Lattice há cerca de um ano, responsável pelo Plasma Mode. O objetivo é bem claro: temos muitas aplicações MUD que consomem uma grande quantidade de gas, enquanto tentamos colocar uma grande quantidade de dados na cadeia, por isso precisamos de uma solução que suporte essas necessidades e seja barata. A equipe da Lattice já fez alguns experimentos no OP Stack, como prototipar alguns mundos na cadeia e implantar no OP Stack. Descobrimos que o OP Stack já está muito bom de usar.
Então nos perguntamos: "Como podemos torná-lo mais barato?" A suposição básica é: "Acreditamos que o OP Stack é a estrutura que mais se alinha com a filosofia do Ethereum e é totalmente compatível com o EVM." O que roda na mainnet pode rodar da mesma forma no OP Stack, essa é a solução ideal. Mas queremos que seja mais barato.
Na época, calldata ainda era a disponibilidade de dados da cadeia OP Stack (DA), o que era muito caro. Portanto, obviamente não podíamos usar calldata para iniciar um L2, porque nosso jogo de cadeia completa e o mundo MUD precisavam de maior throughput. Assim, decidimos começar a tentar outras soluções de disponibilidade de dados (Alt DA). Na verdade, já foi mencionado nos documentos iniciais do OP Stack que deveríamos explorar o Alt DA.
Então nos perguntamos: "O que aconteceria se começássemos com DA fora da cadeia?" Esperamos que todo o modelo de segurança e tudo o mais possa depender do Ethereum L1. Portanto, evitamos outras soluções de Alt DA e decidimos armazenar os dados em armazenamento DA centralizado, e depois encontrar um modelo de segurança eficaz no L1.
É por isso que vamos reutilizar alguns conceitos antigos do Plasma e colocá-los em cima do rollup. Aqui há algumas diferenças. A maior dúvida é: como implementar a DA off-chain e os desafios de dados on-chain sobre o OP Stack existente? O nosso objetivo é fazer o mínimo de alterações no OP Stack, sem afetar o caminho do rollup, pois não queremos impactar a segurança de outras cadeias de rollup que usam o OP Stack.
Ao projetar um rollup, você não pensa: "O que aconteceria se alguém mudasse o processo de geração de dados para armazenar dados de outro lugar?" Mesmo com essas mudanças, o OP Stack ainda é muito robusto e funciona muito bem pronto para uso. Esta é a primeira alteração que fizemos.
Depois, precisamos escrever contratos para criar esses desafios. Há desafios DA para forçar a subida de dados para a blockchain. Este é o segundo passo, integrar o contrato ao processo. Devemos construir todo o sistema de integração no processo de derivação, para que você possa derivar dados de uma fonte DA fora da cadeia e de um contrato de desafio L1 DA, caso os dados sejam submetidos à blockchain durante a resolução do desafio.
Este é o ponto principal. É complicado, porque queremos manter as coisas elegantes e robustas. Ao mesmo tempo, é um conceito relativamente simples. Não estamos a tentar reinventar a roda ou mudar todo o OP Stack, mas sim manter as coisas simples num ambiente complexo. Portanto, no geral, esta é uma jornada de engenharia muito legal.
Ben: Posso falar do ponto de vista da OP. Você mencionou alguns trabalhos iniciais da Lattice. Coincidentemente, ao mesmo tempo, nós da Optimism quase reescrevemos todo o OP Stack de ponta a ponta, e chamamos esta versão de Bedrock.
Basicamente, após dois anos a construir o rollup, damos um passo atrás e refletimos: "Bem, se quisermos levar toda a experiência que aprendemos ao limite, como seria isso?" Isso evoluiu para o que acabou por ser chamado de Bedrock, que é a nossa maior atualização para a rede.
Naquela altura, colaborámos num projeto chamado OPCraft, e eu penso que Biomes é o seu sucessor espiritual, foi a vez em que nos divertimos mais a jogar na cadeia. Ao mesmo tempo, também respiramos aliviados, pois outras pessoas podiam usar o OP Stack para desenvolver. Acredito que outro ponto de viragem importante na escalabilidade nos últimos anos foi que muitas pessoas podiam executar a cadeia.
Não são apenas aqueles que desenvolveram enormes e complexas bibliotecas de código que podem fazer isso. Quando começamos a colaborar, ver outras pessoas conseguirem assumir essa biblioteca de código e fazer coisas incríveis é uma grande validação. E então ver essa situação se expandir na aplicação prática para o Plasma é realmente muito legal. Posso até falar um pouco sobre essa história.
Antes de o Optimism se tornar Optimism, estávamos na verdade a investigar uma tecnologia chamada Plasma. Naquela altura, a tarefa que assumimos ultrapassava em muito a capacidade da comunidade de escalabilidade da época. O design que você vê no design inicial do Plasma pode não ter uma relação direta com o Plasma de hoje.
Hoje, o Plasma é muito mais simples. Vamos separar a prova e o desafio da validação de estado do desafio dos dados. No final, há alguns anos, percebemos que os Rollups são muito mais simples do que o Plasma. Acredito que, na época, a conclusão da comunidade foi que "Plasma está morto". Essa é uma piada na história da escalabilidade do Ethereum daquele período.
Mas sempre acreditamos que "Plasma não está morto, apenas podemos tentar uma tarefa mais simples primeiro". Agora usamos termos diferentes. Por exemplo, na época havia conceitos como (exits), agora você pode olhar para trás e dizer "oh, isso era um desafio de disponibilidade de dados com alguns passos adicionais". Portanto, é incrível ver não apenas que OP Stack está sendo usado por outras pessoas, mas também que evoluiu para algo que tentamos inicialmente, mas de uma maneira muito confusa e imatura. Completamos um ciclo completo, e vocês fizeram abstrações incríveis ao redor disso e fizeram com que funcionasse de uma maneira razoável e sensata. Isso é realmente legal.
O mais importante é entrar rapidamente no ambiente de produção
tdot: O modo Plasma ainda enfrenta alguns desafios e questões não resolvidas que estamos a trabalhar para resolver. A chave é como evitar que leve até dez anos? Você entende o que quero dizer? Precisamos chegar rapidamente a uma fase em que possamos entregar resultados.
Esta é a nossa ideia. Já temos muitas aplicações desenvolvidas com base em MUD que queremos lançar imediatamente na mainnet. Precisamos preparar uma mainnet para esses jogos o mais rápido possível. As pessoas já estão esperando e prontas. Você precisa de uma cadeia que possa ser lançada rapidamente e que funcione para executar todas essas aplicações, assim essas aplicações podem se desenvolver em paralelo enquanto resolvemos os problemas, tornando-se melhores. Desde a pesquisa e desenvolvimento até a implementação da estabilidade de produção leva muito tempo.
Para lançar algo na mainnet, de forma que seja sem permissões, robusto e seguro, é necessário gastar muito tempo. Ver todo o processo que nos levou a alcançar esse objetivo já é impressionante. É por isso que precisamos manter uma alta agilidade, pois há muitas coisas a fazer. Todo o ecossistema está se desenvolvendo muito rapidamente. Acredito que todos estão entregando uma quantidade significativa de inovações. É por isso que você deve se manter atualizado, mas também não pode comprometer a segurança e o desempenho, caso contrário, o sistema não funcionará.
Ben: Ou seja, uma carga técnica. O princípio da mínima alteração que mencionaste, é uma das nossas ideias centrais durante a reescrita do Bedrock. Falei sobre a reescrita completa de ponta a ponta, mas o mais importante é que reduzimos cerca de 50.000 linhas de código, o que é muito significativo. Porque tens razão, estas coisas são realmente difíceis.
Cada linha de código adicionada afasta você mais do ambiente de produção, tornando mais difícil passar por testes práticos e introduzindo mais oportunidades de erro. Portanto, agradecemos muito a todos vocês pelos esforços em impulsionar este processo, especialmente pela contribuição para o novo modo de operação do OP Stack.
tdot： A OP Stack realmente criou uma maneira de você avançar rapidamente em coisas desse tipo. Coordenar todos é muito difícil, pois somos claramente duas empresas diferentes. Na Lattice, estamos construindo um jogo, um motor de jogo e uma cadeia.
E vocês estão construindo centenas e milhares de coisas, e entregando todos esses produtos regularmente. Do ponto de vista da coordenação, isso realmente não é fácil.
Ben: Sim, de facto ainda há um longo caminho a percorrer. Mas essa é precisamente a atração central da modularidade. Para mim, do ponto de vista da OP Stack, esta é uma das coisas mais emocionantes, sem mencionar os jogos e mundos virtuais incríveis que estão a ser construídos agora na Redstone. Apenas do ponto de vista da OP Stack, este é um exemplo muito forte que prova que muitos excelentes desenvolvedores principais já se juntaram e melhoraram esta pilha, o que é realmente notável.
Esta é a primeira vez que você pode alterar significativamente as propriedades do sistema através de um valor booleano chave. Ser capaz de fazer isso completamente, como você disse, ainda há um longo caminho a percorrer. Mas mesmo chegar perto de fazer isso de forma eficaz requer suporte modular, certo? Para nós, ver vocês conseguirem isso sem precisar, por exemplo, reescrever o L2 Geth, é um grande alívio. Para mim, isso prova que a modularidade está funcionando.
tdot: Agora a situação melhorou. A partir deste exemplo, vocês transformaram tudo em pequenos módulos independentes, que podem ser ajustados e ter suas propriedades alteradas. Portanto, estou muito ansioso para ver quais novas funcionalidades ainda serão integradas. Lembro-me de que estávamos preocupados com o fato de termos um fork, que contém todas as alterações no OP Stack, e que precisávamos integrá-lo ao tronco principal. Naquela época, pensamos: "Meu Deus, revisar tudo isso seria uma loucura."
Tivemos que dividir em partes menores, mas todo o processo decorreu muito bem. A atmosfera de colaboração com a equipe foi excelente, então o processo de revisão também foi muito agradável. Isso se sentiu muito natural. E eu acho que o processo foi muito rápido em revisar e resolver alguns problemas potenciais. Tudo correu surpreendentemente bem.
Ben: Isso é realmente ótimo. Este ano, um dos nossos focos é criar um caminho de contribuição para a OP Stack. Portanto, estou muito agradecido por vocês participarem dos testes e impulsionarem esses processos. Fico feliz que esses processos não tenham sido difíceis de lidar e que tenhamos alcançado alguns resultados. Dito isso, estou curioso, na sua perspectiva, como você vê o desenvolvimento desse trabalho a seguir? O que você mais espera desenvolver a seguir?
tdot: Existem muitas direções de trabalho diferentes. O principal é a integração com o mecanismo de prova de falha. Adotamos uma abordagem incremental para descentralizar toda a pilha tecnológica e aumentar suas características sem permissão, com o objetivo final de implementar funções como ausência de permissão e saída forçada.
Temos este objetivo final e estamos a realizá-lo gradualmente, mantendo a segurança. Um desafio é que, às vezes, não lançar na mainnet pode ser mais fácil, pois assim não é necessário realizar um hard fork. Você pode pensar: "Oh, eu só preciso esperar até que tudo esteja completamente pronto para lançar, assim não precisarei fazer um hard fork e não terei carga técnica." No entanto, se você quiser lançar rapidamente na mainnet, terá que lidar com essas atualizações complexas e lançar com frequência. Fazer isso e manter alta disponibilidade é sempre um desafio.
Acredito que, depois que o mecanismo de prova de falhas e todas essas partes estiverem prontas, haverá muitas melhorias na parte do modo Plasma. Acredito que ainda há espaço para otimização na submissão em massa de compromissos. Agora fazemos de forma muito simples, um compromisso por transação. E o compromisso é apenas o valor hash dos dados de entrada armazenados fora da cadeia.
Mantemos as coisas o mais simples possível por enquanto, para que a revisão possa ser simples e rápida, e sem grandes diferenças para a OP Stack. No entanto, agora existem algumas otimizações que podem torná-las mais baratas, como processar os compromissos em lotes ou submetê-los a um blob, ou adotar outras.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Os co-fundadores da Optimism falam com os desenvolvedores do Plasma Mode sobre as melhorias e o futuro da OP Stack
Devs on Devs: tdot e Ben Jones em conversa
Neste episódio especial do Devs on Devs, convidamos o desenvolvedor principal do protocolo Plasma Mode, tdot(, que também é desenvolvedor da Redstone ) e cofundador da Optimism, Ben Jones. A Optimism é o principal impulsionador do OP Stack. O Plasma Mode permite que os desenvolvedores construam sobre o OP Stack, mas sem a necessidade de publicar dados na L1, podendo alternar flexivelmente para provedores de dados off-chain, economizando custos e melhorando a escalabilidade. Na conversa, eles discutiram a origem da colaboração entre Redstone e Optimism, a importância de reviver o Plasma, a necessidade de trazer protocolos experimentais para ambientes de produção, o futuro do Plasma Mode e do OP Stack, e sua empolgação com o desenvolvimento no campo dos jogos em toda a cadeia.
Como usar o modo Plasma para melhorar o OP Stack
Ben: Como é o processo de melhoria da OP Stack?
tdot: Juntei-me à Lattice há cerca de um ano, responsável pelo Plasma Mode. O objetivo é bem claro: temos muitas aplicações MUD que consomem uma grande quantidade de gas, enquanto tentamos colocar uma grande quantidade de dados na cadeia, por isso precisamos de uma solução que suporte essas necessidades e seja barata. A equipe da Lattice já fez alguns experimentos no OP Stack, como prototipar alguns mundos na cadeia e implantar no OP Stack. Descobrimos que o OP Stack já está muito bom de usar.
Então nos perguntamos: "Como podemos torná-lo mais barato?" A suposição básica é: "Acreditamos que o OP Stack é a estrutura que mais se alinha com a filosofia do Ethereum e é totalmente compatível com o EVM." O que roda na mainnet pode rodar da mesma forma no OP Stack, essa é a solução ideal. Mas queremos que seja mais barato.
Na época, calldata ainda era a disponibilidade de dados da cadeia OP Stack (DA), o que era muito caro. Portanto, obviamente não podíamos usar calldata para iniciar um L2, porque nosso jogo de cadeia completa e o mundo MUD precisavam de maior throughput. Assim, decidimos começar a tentar outras soluções de disponibilidade de dados (Alt DA). Na verdade, já foi mencionado nos documentos iniciais do OP Stack que deveríamos explorar o Alt DA.
Então nos perguntamos: "O que aconteceria se começássemos com DA fora da cadeia?" Esperamos que todo o modelo de segurança e tudo o mais possa depender do Ethereum L1. Portanto, evitamos outras soluções de Alt DA e decidimos armazenar os dados em armazenamento DA centralizado, e depois encontrar um modelo de segurança eficaz no L1.
É por isso que vamos reutilizar alguns conceitos antigos do Plasma e colocá-los em cima do rollup. Aqui há algumas diferenças. A maior dúvida é: como implementar a DA off-chain e os desafios de dados on-chain sobre o OP Stack existente? O nosso objetivo é fazer o mínimo de alterações no OP Stack, sem afetar o caminho do rollup, pois não queremos impactar a segurança de outras cadeias de rollup que usam o OP Stack.
Ao projetar um rollup, você não pensa: "O que aconteceria se alguém mudasse o processo de geração de dados para armazenar dados de outro lugar?" Mesmo com essas mudanças, o OP Stack ainda é muito robusto e funciona muito bem pronto para uso. Esta é a primeira alteração que fizemos.
Depois, precisamos escrever contratos para criar esses desafios. Há desafios DA para forçar a subida de dados para a blockchain. Este é o segundo passo, integrar o contrato ao processo. Devemos construir todo o sistema de integração no processo de derivação, para que você possa derivar dados de uma fonte DA fora da cadeia e de um contrato de desafio L1 DA, caso os dados sejam submetidos à blockchain durante a resolução do desafio.
Este é o ponto principal. É complicado, porque queremos manter as coisas elegantes e robustas. Ao mesmo tempo, é um conceito relativamente simples. Não estamos a tentar reinventar a roda ou mudar todo o OP Stack, mas sim manter as coisas simples num ambiente complexo. Portanto, no geral, esta é uma jornada de engenharia muito legal.
Ben: Posso falar do ponto de vista da OP. Você mencionou alguns trabalhos iniciais da Lattice. Coincidentemente, ao mesmo tempo, nós da Optimism quase reescrevemos todo o OP Stack de ponta a ponta, e chamamos esta versão de Bedrock.
Basicamente, após dois anos a construir o rollup, damos um passo atrás e refletimos: "Bem, se quisermos levar toda a experiência que aprendemos ao limite, como seria isso?" Isso evoluiu para o que acabou por ser chamado de Bedrock, que é a nossa maior atualização para a rede.
Naquela altura, colaborámos num projeto chamado OPCraft, e eu penso que Biomes é o seu sucessor espiritual, foi a vez em que nos divertimos mais a jogar na cadeia. Ao mesmo tempo, também respiramos aliviados, pois outras pessoas podiam usar o OP Stack para desenvolver. Acredito que outro ponto de viragem importante na escalabilidade nos últimos anos foi que muitas pessoas podiam executar a cadeia.
Não são apenas aqueles que desenvolveram enormes e complexas bibliotecas de código que podem fazer isso. Quando começamos a colaborar, ver outras pessoas conseguirem assumir essa biblioteca de código e fazer coisas incríveis é uma grande validação. E então ver essa situação se expandir na aplicação prática para o Plasma é realmente muito legal. Posso até falar um pouco sobre essa história.
Antes de o Optimism se tornar Optimism, estávamos na verdade a investigar uma tecnologia chamada Plasma. Naquela altura, a tarefa que assumimos ultrapassava em muito a capacidade da comunidade de escalabilidade da época. O design que você vê no design inicial do Plasma pode não ter uma relação direta com o Plasma de hoje.
Hoje, o Plasma é muito mais simples. Vamos separar a prova e o desafio da validação de estado do desafio dos dados. No final, há alguns anos, percebemos que os Rollups são muito mais simples do que o Plasma. Acredito que, na época, a conclusão da comunidade foi que "Plasma está morto". Essa é uma piada na história da escalabilidade do Ethereum daquele período.
Mas sempre acreditamos que "Plasma não está morto, apenas podemos tentar uma tarefa mais simples primeiro". Agora usamos termos diferentes. Por exemplo, na época havia conceitos como (exits), agora você pode olhar para trás e dizer "oh, isso era um desafio de disponibilidade de dados com alguns passos adicionais". Portanto, é incrível ver não apenas que OP Stack está sendo usado por outras pessoas, mas também que evoluiu para algo que tentamos inicialmente, mas de uma maneira muito confusa e imatura. Completamos um ciclo completo, e vocês fizeram abstrações incríveis ao redor disso e fizeram com que funcionasse de uma maneira razoável e sensata. Isso é realmente legal.
O mais importante é entrar rapidamente no ambiente de produção
tdot: O modo Plasma ainda enfrenta alguns desafios e questões não resolvidas que estamos a trabalhar para resolver. A chave é como evitar que leve até dez anos? Você entende o que quero dizer? Precisamos chegar rapidamente a uma fase em que possamos entregar resultados.
Esta é a nossa ideia. Já temos muitas aplicações desenvolvidas com base em MUD que queremos lançar imediatamente na mainnet. Precisamos preparar uma mainnet para esses jogos o mais rápido possível. As pessoas já estão esperando e prontas. Você precisa de uma cadeia que possa ser lançada rapidamente e que funcione para executar todas essas aplicações, assim essas aplicações podem se desenvolver em paralelo enquanto resolvemos os problemas, tornando-se melhores. Desde a pesquisa e desenvolvimento até a implementação da estabilidade de produção leva muito tempo.
Para lançar algo na mainnet, de forma que seja sem permissões, robusto e seguro, é necessário gastar muito tempo. Ver todo o processo que nos levou a alcançar esse objetivo já é impressionante. É por isso que precisamos manter uma alta agilidade, pois há muitas coisas a fazer. Todo o ecossistema está se desenvolvendo muito rapidamente. Acredito que todos estão entregando uma quantidade significativa de inovações. É por isso que você deve se manter atualizado, mas também não pode comprometer a segurança e o desempenho, caso contrário, o sistema não funcionará.
Ben: Ou seja, uma carga técnica. O princípio da mínima alteração que mencionaste, é uma das nossas ideias centrais durante a reescrita do Bedrock. Falei sobre a reescrita completa de ponta a ponta, mas o mais importante é que reduzimos cerca de 50.000 linhas de código, o que é muito significativo. Porque tens razão, estas coisas são realmente difíceis.
Cada linha de código adicionada afasta você mais do ambiente de produção, tornando mais difícil passar por testes práticos e introduzindo mais oportunidades de erro. Portanto, agradecemos muito a todos vocês pelos esforços em impulsionar este processo, especialmente pela contribuição para o novo modo de operação do OP Stack.
tdot： A OP Stack realmente criou uma maneira de você avançar rapidamente em coisas desse tipo. Coordenar todos é muito difícil, pois somos claramente duas empresas diferentes. Na Lattice, estamos construindo um jogo, um motor de jogo e uma cadeia.
E vocês estão construindo centenas e milhares de coisas, e entregando todos esses produtos regularmente. Do ponto de vista da coordenação, isso realmente não é fácil.
Ben: Sim, de facto ainda há um longo caminho a percorrer. Mas essa é precisamente a atração central da modularidade. Para mim, do ponto de vista da OP Stack, esta é uma das coisas mais emocionantes, sem mencionar os jogos e mundos virtuais incríveis que estão a ser construídos agora na Redstone. Apenas do ponto de vista da OP Stack, este é um exemplo muito forte que prova que muitos excelentes desenvolvedores principais já se juntaram e melhoraram esta pilha, o que é realmente notável.
Esta é a primeira vez que você pode alterar significativamente as propriedades do sistema através de um valor booleano chave. Ser capaz de fazer isso completamente, como você disse, ainda há um longo caminho a percorrer. Mas mesmo chegar perto de fazer isso de forma eficaz requer suporte modular, certo? Para nós, ver vocês conseguirem isso sem precisar, por exemplo, reescrever o L2 Geth, é um grande alívio. Para mim, isso prova que a modularidade está funcionando.
tdot: Agora a situação melhorou. A partir deste exemplo, vocês transformaram tudo em pequenos módulos independentes, que podem ser ajustados e ter suas propriedades alteradas. Portanto, estou muito ansioso para ver quais novas funcionalidades ainda serão integradas. Lembro-me de que estávamos preocupados com o fato de termos um fork, que contém todas as alterações no OP Stack, e que precisávamos integrá-lo ao tronco principal. Naquela época, pensamos: "Meu Deus, revisar tudo isso seria uma loucura."
Tivemos que dividir em partes menores, mas todo o processo decorreu muito bem. A atmosfera de colaboração com a equipe foi excelente, então o processo de revisão também foi muito agradável. Isso se sentiu muito natural. E eu acho que o processo foi muito rápido em revisar e resolver alguns problemas potenciais. Tudo correu surpreendentemente bem.
Ben: Isso é realmente ótimo. Este ano, um dos nossos focos é criar um caminho de contribuição para a OP Stack. Portanto, estou muito agradecido por vocês participarem dos testes e impulsionarem esses processos. Fico feliz que esses processos não tenham sido difíceis de lidar e que tenhamos alcançado alguns resultados. Dito isso, estou curioso, na sua perspectiva, como você vê o desenvolvimento desse trabalho a seguir? O que você mais espera desenvolver a seguir?
tdot: Existem muitas direções de trabalho diferentes. O principal é a integração com o mecanismo de prova de falha. Adotamos uma abordagem incremental para descentralizar toda a pilha tecnológica e aumentar suas características sem permissão, com o objetivo final de implementar funções como ausência de permissão e saída forçada.
Temos este objetivo final e estamos a realizá-lo gradualmente, mantendo a segurança. Um desafio é que, às vezes, não lançar na mainnet pode ser mais fácil, pois assim não é necessário realizar um hard fork. Você pode pensar: "Oh, eu só preciso esperar até que tudo esteja completamente pronto para lançar, assim não precisarei fazer um hard fork e não terei carga técnica." No entanto, se você quiser lançar rapidamente na mainnet, terá que lidar com essas atualizações complexas e lançar com frequência. Fazer isso e manter alta disponibilidade é sempre um desafio.
Acredito que, depois que o mecanismo de prova de falhas e todas essas partes estiverem prontas, haverá muitas melhorias na parte do modo Plasma. Acredito que ainda há espaço para otimização na submissão em massa de compromissos. Agora fazemos de forma muito simples, um compromisso por transação. E o compromisso é apenas o valor hash dos dados de entrada armazenados fora da cadeia.
Mantemos as coisas o mais simples possível por enquanto, para que a revisão possa ser simples e rápida, e sem grandes diferenças para a OP Stack. No entanto, agora existem algumas otimizações que podem torná-las mais baratas, como processar os compromissos em lotes ou submetê-los a um blob, ou adotar outras.