"Neste episódio especial de Devs on Devs, convidamos o desenvolvedor do protocolo central do Plasma Mode tdot(, que também é desenvolvedor do Redstone ), e o co-fundador da Optimism, Ben Jones. A Optimism é a principal impulsionadora do OP Stack. O Plasma Mode permite que os desenvolvedores construam sobre o OP Stack, mas não precisam publicar dados no L1, podendo alternar de forma flexível para provedores de dados off-chain, economizando custos e aumentando a escalabilidade. Na conversa, eles exploraram a origem da colaboração entre Redstone e Optimism, a importância de revitalizar o Plasma, a necessidade de trazer protocolos experimentais para o ambiente de produção, o futuro do Plasma Mode e do OP Stack, e sua empolgação com o desenvolvimento no campo dos jogos de blockchain."
Como usar o modo Plasma para melhorar a OP Stack
Ben: Como é o processo de melhoria da OP Stack?
tdot: Eu juntei-me à Lattice há cerca de um ano, responsável pelo Plasma Mode. O objetivo é muito claro: temos muitas aplicações MUD que consomem uma grande quantidade de gas, enquanto tentamos colocar muitos dados na blockchain, portanto, precisamos de uma solução que suporte essas necessidades e que seja económica. A equipe da Lattice já fez alguns experimentos no OP Stack, como prototipar alguns mundos na blockchain e implantá-los no OP Stack. Descobrimos que o OP Stack já é muito útil.
Então nos perguntamos: "Como podemos torná-lo mais barato?" A suposição básica é: "Acreditamos que a OP Stack é a estrutura que mais se alinha com a filosofia do Ethereum e é totalmente compatível com EVM." O que funciona na mainnet pode funcionar igualmente na OP Stack, essa é a solução ideal. Mas queremos que seja mais barato.
Na época, calldata ainda era a fonte de disponibilidade de dados da cadeia OP Stack (DA), o que era muito caro. Portanto, claramente não podíamos usar calldata para lançar um L2, pois nosso jogo de cadeia completa e o mundo MUD precisavam de maior capacidade de processamento. Assim, decidimos começar a tentar outras opções de disponibilidade de dados (Alt DA). Na verdade, já foi mencionado nos documentos iniciais do OP Stack a exploração de Alt DA.
Então nos perguntamos: "O que aconteceria se começássemos com DA off-chain?" Esperamos que todo o modelo de segurança e tudo mais possa depender do Ethereum L1. Portanto, evitamos outras soluções de Alt DA e decidimos armazenar os dados em um armazenamento DA centralizado, e depois encontrar um modelo de segurança eficaz no L1.
É por isso que decidimos reutilizar alguns conceitos antigos do Plasma e colocá-los em cima do rollup. Aqui estão algumas diferenças. A maior dúvida é como implementar a DA off-chain e os desafios de dados on-chain na pilha OP existente? O nosso objetivo é alterar o mínimo possível a pilha OP, sem afetar o caminho do rollup, pois não queremos comprometer a segurança de outras cadeias de rollup que utilizam a pilha OP.
Ao projetar um rollup, você não pensa: "E se alguém mudar o processo de geração de dados para armazenar dados de outro lugar?" Mesmo com essas alterações, o OP Stack ainda é muito robusto e funciona bem pronto para uso. Esta é a primeira alteração que fizemos.
Depois, precisamos escrever um contrato para criar esses desafios. Existem desafios de DA que forçam a colocar os dados na cadeia. Este é o segundo passo, integrar o contrato no processo. Precisamos construir todo o sistema de integração no processo de derivação, para que você possa derivar dados de uma fonte de DA fora da cadeia e de um contrato de desafio de DA L1, caso os dados sejam submetidos à cadeia 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 tentando reinventar a roda ou mudar todo o OP Stack, mas sim tentar manter as coisas simples em um ambiente complexo. Portanto, no geral, esta é uma jornada de engenharia muito fixe.
Ben: Eu posso falar do ponto de vista da OP. Você mencionou alguns dos trabalhos iniciais da Lattice. Coincidentemente, ao mesmo tempo, nós da Optimism quase refizemos toda a OP Stack de ponta a ponta, e a versão que lançamos chamamos de Bedrock.
Basicamente, após construir o rollup durante dois anos, demos um passo atrás e refletimos: "Bem, se quisermos aplicar toda a experiência adquirida ao máximo, como seria isso?" Isso evoluiu para o que acabou sendo chamado de Bedrock, que é o nosso maior upgrade na rede.
Naquela altura, colaborámos convosco num projeto chamado OPCraft, e eu considero que Biomes é o seu sucessor espiritual, foi a vez em que nos divertimos mais a jogar na cadeia. Ao mesmo tempo, também respirámos de alívio, pois outras pessoas também podem utilizar o OP Stack para desenvolver. Acredito que, nos últimos anos, outro ponto de viragem importante na escalabilidade foi que muitas pessoas puderam executar a cadeia.
Não são apenas aqueles que desenvolveram grandes e complexas bibliotecas de código que podem fazer isso. Quando começamos a colaborar, ver outras pessoas conseguindo assumir essa biblioteca de código e fazer coisas realmente incríveis é uma grande validação. Depois, ver essa situação se expandir para o Plasma na aplicação real é realmente legal. Eu posso até comentar um pouco sobre aquela história.
Antes de o Optimism se tornar Optimism, estávamos na verdade a pesquisar uma tecnologia chamada Plasma. Naquela altura, a tarefa que assumimos superava de longe a capacidade da comunidade de escalabilidade na época. O design que você vê nos primeiros designs 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 verificação de estado do desafio dos dados. No final, percebemos há alguns anos que os Rollups são muito mais simples do que o Plasma. Eu acho que, na época, a conclusão da comunidade foi "Plasma está morto". Essa é uma piada na história da escalabilidade do Ethereum daquela época.
Mas sempre acreditamos que "Plasma não morreu, apenas podemos tentar uma tarefa mais simples primeiro". Agora usamos termos diferentes. Por exemplo, naquela época havia conceitos como saídas (exits), agora você pode voltar e dizer "oh, isso foi um desafio de disponibilidade de dados com alguns passos adicionais". Portanto, é impressionante ver que não apenas o OP Stack está sendo usado por outras pessoas, mas também evoluiu para algo que tentamos inicialmente, mas de uma maneira muito confusa e imatura. Completamos um ciclo completo, vocês fizeram abstrações incríveis em torno disso e fizeram funcionar 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, e ainda estamos a trabalhar para os resolver. A chave é como evitar gastar 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 querem ser lançadas na mainnet imediatamente. Precisamos preparar uma mainnet para esses jogos o mais rápido possível. As pessoas já estão à espera 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 evoluir paralelamente enquanto resolvemos problemas, tornando-se melhores. Desde o desenvolvimento até a implementação, a estabilidade da produção leva muito tempo.
Para colocar algo em uma mainnet, tornando-o sem permissão, robusto e seguro, é necessário gastar muito tempo. Ver todo o processo que realizamos para atingir esse objetivo já é impressionante. É por isso que precisamos manter uma alta agilidade, porque há muitas coisas. Todo o ecossistema está se desenvolvendo muito rapidamente. Eu acho que todos estão entregando uma grande quantidade de inovações. É por isso que você deve acompanhar, 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 é um dos nossos conceitos centrais na 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 por si só é muito poderoso. Porque tens razão, estas coisas são realmente difíceis.
Cada linha de código adicionada faz com que você se afaste mais do ambiente de produção, tornando mais difícil passar por testes práticos e introduzindo mais oportunidades de erro. Portanto, agradecemos muito todos os esforços de vocês na promoção desse processo, especialmente as contribuições 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, porque claramente somos 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 regularmente todos esses produtos. Do ponto de vista da coordenação, isso realmente não é fácil.
Ben: Sim, realmente ainda temos um longo caminho pela frente. Mas essa é a verdadeira essência do modular. Para mim, do ponto de vista do OP Stack, isso é uma das coisas mais empolgantes, sem mencionar os incríveis jogos e mundos virtuais que estão sendo construídos atualmente na Redstone. Puramente do ponto de vista do OP Stack, este é um exemplo muito forte que prova que muitos excelentes desenvolvedores centrais já se juntaram e melhoraram essa pilha, o que é realmente impressionante.
Esta é a primeira vez, você pode mudar 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 se aproximar de fazer isso de forma eficaz, também requer suporte modular, certo? Para nós, ver vocês conseguirem isso, sem precisar por exemplo reescrever o L2 Geth, é realmente um alívio. Para mim, isso prova que a modularidade está funcionando.
tdot: A situação agora melhorou. Com base neste 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 que estávamos preocupados com o fato de termos um fork, que inclui todas as mudanças no OP Stack, e que precisamos fundi-lo no tronco principal. Naquela época, pensamos: "Meu Deus, revisar tudo isso seria uma loucura."
Tivemos que dividi-lo em partes menores, mas todo o processo decorreu muito bem. A atmosfera de cooperação com a equipe foi excelente, portanto, o processo de revisão também foi muito agradável. Isso se sentiu muito natural. E eu acho que, na revisão e na resolução de alguns problemas potenciais, o processo foi muito rápido. Tudo correu surpreendentemente bem.
Ben: Isso é realmente ótimo. Este ano, um dos nossos focos é criar caminhos de contribuição para o OP Stack. Portanto, estou muito agradecido pela sua participação nos testes, ajudando a impulsionar esses processos. Estou feliz que esses processos não tenham sido insuportáveis e que tenhamos alcançado alguns resultados. A propósito, estou curioso, na sua perspectiva, como você acha que esse trabalho vai se desenvolver a seguir? O que você mais espera desenvolver a seguir?
tdot: Existem muitas direções de trabalho diferentes. O principal envolve a integração com o mecanismo de prova de falhas. Adotamos uma abordagem progressiva para descentralizar toda a pilha tecnológica e aumentar suas características sem permissão, com o objetivo final de implementar funcionalidades como autorização sem permissão e saída forçada.
Temos este objetivo final e, ao mesmo tempo, queremos alcançá-lo gradualmente, mantendo a segurança. Um desafio é que, às vezes, é mais fácil não lançar na mainnet, pois assim não é necessário realizar um hard fork. Você pode pensar: "Oh, eu só quero esperar até que tudo esteja completamente pronto para lançar, assim não preciso fazer um hard fork e não há carga técnica." No entanto, se você quiser lançar rapidamente na mainnet, terá que lidar com essas atualizações complexas e lançar frequentemente. 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 atualizações na parte do modelo Plasma. Acho que ainda há espaço para algumas otimizações na submissão em lote 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.
Estamos a manter as coisas tão simples quanto possível por enquanto, para que a revisão possa ser simples e rápida, e não há grandes diferenças para o OP Stack. No entanto, agora há algumas otimizações que podem torná-lo mais barato, como agrupar os compromissos ou submetê-los ao blob, ou adotar outros métodos diferentes. Portanto, com certeza iremos investigar isso para reduzir os custos do L1.
Estamos muito empolgados com isso. Claro, também estamos ansiosos pelo conteúdo relacionado à interoperabilidade que está por vir e pela capacidade de interagir entre todas as cadeias. Entender isso representará um grande avanço para os usuários.
Muitos desses trabalhos certamente terão que ser realizados por vocês. Mas queremos entender como isso se parece no modo Plasma, e com diferentes hipóteses de segurança.
Ben: Falando nisso, será mais um teste para a modularidade do OP Stack. Você mencionou
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
15 gostos
Recompensa
15
6
Partilhar
Comentar
0/400
YieldHunter
· 08-04 00:52
tecnicamente falando... não estou convencido sobre a fiabilidade dos dados fora da cadeia smh
Ver originalResponder0
DaoResearcher
· 08-04 00:51
A partir do triângulo de disponibilidade de dados, essa ideia é brilhante.
Os cofundadores da Optimism discutem o futuro do OP Stack com os desenvolvedores do Plasma Mode
DEVS ON DEVS: Conversa com tdot e Ben Jones
"Neste episódio especial de Devs on Devs, convidamos o desenvolvedor do protocolo central do Plasma Mode tdot(, que também é desenvolvedor do Redstone ), e o co-fundador da Optimism, Ben Jones. A Optimism é a principal impulsionadora do OP Stack. O Plasma Mode permite que os desenvolvedores construam sobre o OP Stack, mas não precisam publicar dados no L1, podendo alternar de forma flexível para provedores de dados off-chain, economizando custos e aumentando a escalabilidade. Na conversa, eles exploraram a origem da colaboração entre Redstone e Optimism, a importância de revitalizar o Plasma, a necessidade de trazer protocolos experimentais para o ambiente de produção, o futuro do Plasma Mode e do OP Stack, e sua empolgação com o desenvolvimento no campo dos jogos de blockchain."
Como usar o modo Plasma para melhorar a OP Stack
Ben: Como é o processo de melhoria da OP Stack?
tdot: Eu juntei-me à Lattice há cerca de um ano, responsável pelo Plasma Mode. O objetivo é muito claro: temos muitas aplicações MUD que consomem uma grande quantidade de gas, enquanto tentamos colocar muitos dados na blockchain, portanto, precisamos de uma solução que suporte essas necessidades e que seja económica. A equipe da Lattice já fez alguns experimentos no OP Stack, como prototipar alguns mundos na blockchain e implantá-los no OP Stack. Descobrimos que o OP Stack já é muito útil.
Então nos perguntamos: "Como podemos torná-lo mais barato?" A suposição básica é: "Acreditamos que a OP Stack é a estrutura que mais se alinha com a filosofia do Ethereum e é totalmente compatível com EVM." O que funciona na mainnet pode funcionar igualmente na OP Stack, essa é a solução ideal. Mas queremos que seja mais barato.
Na época, calldata ainda era a fonte de disponibilidade de dados da cadeia OP Stack (DA), o que era muito caro. Portanto, claramente não podíamos usar calldata para lançar um L2, pois nosso jogo de cadeia completa e o mundo MUD precisavam de maior capacidade de processamento. Assim, decidimos começar a tentar outras opções de disponibilidade de dados (Alt DA). Na verdade, já foi mencionado nos documentos iniciais do OP Stack a exploração de Alt DA.
Então nos perguntamos: "O que aconteceria se começássemos com DA off-chain?" Esperamos que todo o modelo de segurança e tudo mais possa depender do Ethereum L1. Portanto, evitamos outras soluções de Alt DA e decidimos armazenar os dados em um armazenamento DA centralizado, e depois encontrar um modelo de segurança eficaz no L1.
É por isso que decidimos reutilizar alguns conceitos antigos do Plasma e colocá-los em cima do rollup. Aqui estão algumas diferenças. A maior dúvida é como implementar a DA off-chain e os desafios de dados on-chain na pilha OP existente? O nosso objetivo é alterar o mínimo possível a pilha OP, sem afetar o caminho do rollup, pois não queremos comprometer a segurança de outras cadeias de rollup que utilizam a pilha OP.
Ao projetar um rollup, você não pensa: "E se alguém mudar o processo de geração de dados para armazenar dados de outro lugar?" Mesmo com essas alterações, o OP Stack ainda é muito robusto e funciona bem pronto para uso. Esta é a primeira alteração que fizemos.
Depois, precisamos escrever um contrato para criar esses desafios. Existem desafios de DA que forçam a colocar os dados na cadeia. Este é o segundo passo, integrar o contrato no processo. Precisamos construir todo o sistema de integração no processo de derivação, para que você possa derivar dados de uma fonte de DA fora da cadeia e de um contrato de desafio de DA L1, caso os dados sejam submetidos à cadeia 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 tentando reinventar a roda ou mudar todo o OP Stack, mas sim tentar manter as coisas simples em um ambiente complexo. Portanto, no geral, esta é uma jornada de engenharia muito fixe.
Ben: Eu posso falar do ponto de vista da OP. Você mencionou alguns dos trabalhos iniciais da Lattice. Coincidentemente, ao mesmo tempo, nós da Optimism quase refizemos toda a OP Stack de ponta a ponta, e a versão que lançamos chamamos de Bedrock.
Basicamente, após construir o rollup durante dois anos, demos um passo atrás e refletimos: "Bem, se quisermos aplicar toda a experiência adquirida ao máximo, como seria isso?" Isso evoluiu para o que acabou sendo chamado de Bedrock, que é o nosso maior upgrade na rede.
Naquela altura, colaborámos convosco num projeto chamado OPCraft, e eu considero que Biomes é o seu sucessor espiritual, foi a vez em que nos divertimos mais a jogar na cadeia. Ao mesmo tempo, também respirámos de alívio, pois outras pessoas também podem utilizar o OP Stack para desenvolver. Acredito que, nos últimos anos, outro ponto de viragem importante na escalabilidade foi que muitas pessoas puderam executar a cadeia.
Não são apenas aqueles que desenvolveram grandes e complexas bibliotecas de código que podem fazer isso. Quando começamos a colaborar, ver outras pessoas conseguindo assumir essa biblioteca de código e fazer coisas realmente incríveis é uma grande validação. Depois, ver essa situação se expandir para o Plasma na aplicação real é realmente legal. Eu posso até comentar um pouco sobre aquela história.
Antes de o Optimism se tornar Optimism, estávamos na verdade a pesquisar uma tecnologia chamada Plasma. Naquela altura, a tarefa que assumimos superava de longe a capacidade da comunidade de escalabilidade na época. O design que você vê nos primeiros designs 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 verificação de estado do desafio dos dados. No final, percebemos há alguns anos que os Rollups são muito mais simples do que o Plasma. Eu acho que, na época, a conclusão da comunidade foi "Plasma está morto". Essa é uma piada na história da escalabilidade do Ethereum daquela época.
Mas sempre acreditamos que "Plasma não morreu, apenas podemos tentar uma tarefa mais simples primeiro". Agora usamos termos diferentes. Por exemplo, naquela época havia conceitos como saídas (exits), agora você pode voltar e dizer "oh, isso foi um desafio de disponibilidade de dados com alguns passos adicionais". Portanto, é impressionante ver que não apenas o OP Stack está sendo usado por outras pessoas, mas também evoluiu para algo que tentamos inicialmente, mas de uma maneira muito confusa e imatura. Completamos um ciclo completo, vocês fizeram abstrações incríveis em torno disso e fizeram funcionar 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, e ainda estamos a trabalhar para os resolver. A chave é como evitar gastar 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 querem ser lançadas na mainnet imediatamente. Precisamos preparar uma mainnet para esses jogos o mais rápido possível. As pessoas já estão à espera 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 evoluir paralelamente enquanto resolvemos problemas, tornando-se melhores. Desde o desenvolvimento até a implementação, a estabilidade da produção leva muito tempo.
Para colocar algo em uma mainnet, tornando-o sem permissão, robusto e seguro, é necessário gastar muito tempo. Ver todo o processo que realizamos para atingir esse objetivo já é impressionante. É por isso que precisamos manter uma alta agilidade, porque há muitas coisas. Todo o ecossistema está se desenvolvendo muito rapidamente. Eu acho que todos estão entregando uma grande quantidade de inovações. É por isso que você deve acompanhar, 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 é um dos nossos conceitos centrais na 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 por si só é muito poderoso. Porque tens razão, estas coisas são realmente difíceis.
Cada linha de código adicionada faz com que você se afaste mais do ambiente de produção, tornando mais difícil passar por testes práticos e introduzindo mais oportunidades de erro. Portanto, agradecemos muito todos os esforços de vocês na promoção desse processo, especialmente as contribuições 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, porque claramente somos 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 regularmente todos esses produtos. Do ponto de vista da coordenação, isso realmente não é fácil.
Ben: Sim, realmente ainda temos um longo caminho pela frente. Mas essa é a verdadeira essência do modular. Para mim, do ponto de vista do OP Stack, isso é uma das coisas mais empolgantes, sem mencionar os incríveis jogos e mundos virtuais que estão sendo construídos atualmente na Redstone. Puramente do ponto de vista do OP Stack, este é um exemplo muito forte que prova que muitos excelentes desenvolvedores centrais já se juntaram e melhoraram essa pilha, o que é realmente impressionante.
Esta é a primeira vez, você pode mudar 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 se aproximar de fazer isso de forma eficaz, também requer suporte modular, certo? Para nós, ver vocês conseguirem isso, sem precisar por exemplo reescrever o L2 Geth, é realmente um alívio. Para mim, isso prova que a modularidade está funcionando.
tdot: A situação agora melhorou. Com base neste 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 que estávamos preocupados com o fato de termos um fork, que inclui todas as mudanças no OP Stack, e que precisamos fundi-lo no tronco principal. Naquela época, pensamos: "Meu Deus, revisar tudo isso seria uma loucura."
Tivemos que dividi-lo em partes menores, mas todo o processo decorreu muito bem. A atmosfera de cooperação com a equipe foi excelente, portanto, o processo de revisão também foi muito agradável. Isso se sentiu muito natural. E eu acho que, na revisão e na resolução de alguns problemas potenciais, o processo foi muito rápido. Tudo correu surpreendentemente bem.
Ben: Isso é realmente ótimo. Este ano, um dos nossos focos é criar caminhos de contribuição para o OP Stack. Portanto, estou muito agradecido pela sua participação nos testes, ajudando a impulsionar esses processos. Estou feliz que esses processos não tenham sido insuportáveis e que tenhamos alcançado alguns resultados. A propósito, estou curioso, na sua perspectiva, como você acha que esse trabalho vai se desenvolver a seguir? O que você mais espera desenvolver a seguir?
tdot: Existem muitas direções de trabalho diferentes. O principal envolve a integração com o mecanismo de prova de falhas. Adotamos uma abordagem progressiva para descentralizar toda a pilha tecnológica e aumentar suas características sem permissão, com o objetivo final de implementar funcionalidades como autorização sem permissão e saída forçada.
Temos este objetivo final e, ao mesmo tempo, queremos alcançá-lo gradualmente, mantendo a segurança. Um desafio é que, às vezes, é mais fácil não lançar na mainnet, pois assim não é necessário realizar um hard fork. Você pode pensar: "Oh, eu só quero esperar até que tudo esteja completamente pronto para lançar, assim não preciso fazer um hard fork e não há carga técnica." No entanto, se você quiser lançar rapidamente na mainnet, terá que lidar com essas atualizações complexas e lançar frequentemente. 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 atualizações na parte do modelo Plasma. Acho que ainda há espaço para algumas otimizações na submissão em lote 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.
Estamos a manter as coisas tão simples quanto possível por enquanto, para que a revisão possa ser simples e rápida, e não há grandes diferenças para o OP Stack. No entanto, agora há algumas otimizações que podem torná-lo mais barato, como agrupar os compromissos ou submetê-los ao blob, ou adotar outros métodos diferentes. Portanto, com certeza iremos investigar isso para reduzir os custos do L1.
Estamos muito empolgados com isso. Claro, também estamos ansiosos pelo conteúdo relacionado à interoperabilidade que está por vir e pela capacidade de interagir entre todas as cadeias. Entender isso representará um grande avanço para os usuários.
Muitos desses trabalhos certamente terão que ser realizados por vocês. Mas queremos entender como isso se parece no modo Plasma, e com diferentes hipóteses de segurança.
Ben: Falando nisso, será mais um teste para a modularidade do OP Stack. Você mencionou