DEVS ON DEVS: A conversa entre TDOT e BEN JONES

No diálogo especial desta edição do Devs on Devs, convidamos o desenvolvedor principal do protocolo Plasma Mode tdot(, que também é desenvolvedor da Redstone ), e o cofundador da Optimism Ben Jones. A Optimism é o principal impulsionador do OP Stack. O Plasma Mode permite que desenvolvedores construam sobre o OP Stack, mas sem a necessidade de publicar dados na L1, podendo alternar de forma flexível para provedores de dados fora da cadeia, economizando custos e aumentando a escalabilidade. Neste diálogo, eles discutiram as origens 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.

01.Como usar o modo Plasma para melhorar o OP Stack

Ben: Como é o processo de melhoria do OP Stack?

tdot: Eu juntei-me à Lattice há cerca de um ano, sendo responsável pelo Plasma Mode. O objetivo é muito claro: temos muitas aplicações MUD que consomem uma quantidade significativa de gas, enquanto tentamos colocar uma grande quantidade de dados na cadeia, por isso precisamos de uma solução que suporte essas necessidades e que seja barata. A equipe da Lattice já fez alguns testes no OP Stack, como prototipar alguns mundos em 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 a OP Stack é a estrutura mais alinhada com a filosofia do Ethereum e totalmente compatível com EVM." O que funciona na mainnet pode funcionar da mesma forma na OP Stack, essa é a solução ideal. Mas queremos que seja mais barato.

Na altura, 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 completo em cadeia e o mundo MUD precisavam de maior capacidade de processamento. Assim, decidimos começar a explorar outras soluções de disponibilidade de dados (Alt DA). Na verdade, já foi mencionado nos documentos iniciais da OP Stack que seria necessário explorar o Alt DA.

Então nos perguntamos: "E se começássemos com DA off-chain?" 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 queremos reutilizar alguns conceitos antigos de Plasma e colocá-los sobre o rollup. Aqui estão algumas diferenças. A maior dúvida é como implementar a DA off-chain e o desafio de dados on-chain na OP Stack existente? Nosso objetivo é fazer o mínimo de alterações na OP Stack, sem impactar o caminho do rollup, porque não queremos afetar a segurança de outras cadeias de rollup que utilizam a OP Stack.

Ao projetar um rollup, você não pensa: "E se alguém alterar o processo de geração de dados para armazenar dados de outro lugar?" Mesmo com essas alterações, o OP Stack continua muito robusto e funciona muito bem pronto para uso. Esta é a primeira alteração que fizemos.

Depois, precisamos escrever contratos para criar esses desafios. Existem desafios DA que forçam a colocar dados na blockchain. Este é o segundo passo, integrar o contrato no processo. Devemos construir todo o sistema de integração no processo de derivação, de modo que você possa derivar dados de uma fonte DA fora da cadeia e de um contrato de desafio DA L1, caso os dados sejam submetidos na 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 tentamos reinventar tudo ou mudar todo o OP Stack, mas tentamos manter as coisas simples em um ambiente complexo. Portanto, no geral, é uma jornada de engenharia muito legal.

Ben: Eu posso falar do ponto de vista da OP. Você mencionou alguns trabalhos iniciais da Lattice. Coincidentemente, ao mesmo tempo, nós da Optimism reescrevemos praticamente toda a OP Stack de forma end-to-end, e a versão que lançamos chamamos de Bedrock.

Basicamente, após dois anos de construção do rollup, demos um passo atrás e refletimos: "Bem, se quisermos levar toda a experiência que aprendemos ao extremo, como seria isso?" Isso evoluiu para o que acabou por ser chamado de código base Bedrock, que é a nossa maior atualização na rede.

Naquela altura, colaborámos convosco num projeto chamado OPCraft, e eu acredito que os Biomas são o seu sucessor espiritual, foi a vez que mais nos divertimos a jogar na cadeia. Ao mesmo tempo, também respirámos de alívio, pois outras pessoas também podem usar o OP Stack para desenvolver. Eu acredito que, nos últimos anos, outro ponto de viragem importante para a escalabilidade foi que muitas pessoas puderam operar 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 conseguirem assumir essa biblioteca de código e fazer coisas realmente incríveis é uma grande validação. E então, ver essa situação se expandir para o Plasma em aplicações reais é realmente incrível. Eu posso até comentar um pouco sobre aquela história.

Antes de o Optimism se tornar Optimism, na verdade estávamos 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ê 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 de validação de estado dos desafios de dados. No final, reconhecemos 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". Esta é 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, ver não apenas o OP Stack sendo usado por outros, mas também evoluindo para algo que tentamos originalmente, mas de uma maneira muito confusa e imatura, é realmente impressionante. Completamos um ciclo completo, e vocês fizeram abstrações incríveis em torno disso, fazendo com que funcionasse de uma maneira razoável e sensata. Isso é realmente legal.

02.O mais importante é entrar no ambiente de produção o mais rápido possível

tdot: O modo Plasma ainda enfrenta alguns desafios e questões não resolvidas, e estamos trabalhando para solucioná-los. A chave é como evitar gastar até dez anos? Você entende o que quero dizer? Precisamos rapidamente alcançar uma fase em que possamos entregar resultados.

Esta é a nossa ideia. Já temos muitas aplicações baseadas 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 à 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. Leva muito tempo desde o desenvolvimento até a implementação da estabilidade em produção.

Para lançar algo na mainnet, de forma a torná-lo sem permissão, robusto e seguro, é necessário gastar muito tempo. Ver todo o processo pelo qual conseguimos alcançar esse objetivo é realmente impressionante. É por isso que precisamos manter uma alta agilidade, pois há muitas coisas a fazer. Todo o ecossistema está a desenvolver-se muito rapidamente. Acredito que todos estão a entregar 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 conceitos fundamentais 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 é muito significativo. Porque tens razão, estas coisas são realmente difíceis.

Cada linha de código adicionada faz com que você se distancie mais do ambiente de produção, tornando as coisas mais difíceis de serem testadas em situações reais e introduzindo mais oportunidades de erro. Portanto, agradecemos muito todos os seus esforços para impulsionar esse 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 tais questões. 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, ainda temos um longo caminho a percorrer. Mas essa é a verdadeira beleza do modular. Para mim, do ponto de vista da OP Stack, isso é uma das coisas mais empolgantes, sem mencionar os incríveis jogos e mundos virtuais que estão sendo construídos agora na Redstone. Puramente do ponto de vista da OP Stack, este é um exemplo muito poderoso que prova que muitos excelentes desenvolvedores principais 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, realmente ainda há um longo caminho a percorrer. Mas mesmo chegar perto de fazer isso de forma eficaz, requer apoio 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. 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 que tínhamos um fork, que incluía todas as alterações ao OP Stack, e que precisávamos integrá-lo ao tronco principal. Naquele momento, 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 entre nós e a equipe foi excelente, por isso o processo de revisão também foi muito agradável. Sentiu-se muito natural. E eu acho que, na revisão e na resolução de alguns problemas potenciais, esse processo ocorreu muito rapidamente. 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, impulsionando esses processos. Estou feliz que esses processos não foram difíceis de suportar e que conseguimos alguns resultados. A propósito, estou curioso, como você vê o desenvolvimento desse trabalho nos próximos passos? 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 progressiva para descentralizar toda a pilha tecnológica e aumentar suas características sem permissão, com o objetivo final de implementar funcionalidades como sem permissão e saída forçada.

Temos este objetivo final e estamos a realizá-lo gradualmente, mantendo a segurança. Um desafio é que, por vezes, não lançar na rede principal pode ser mais fácil, pois assim não é necessário fazer uma hard fork. Você pode pensar: "Oh, eu só preciso esperar até que tudo esteja completamente pronto antes de lançar, assim não é necessário fazer uma hard fork e não há carga técnica." Mas, se você quiser lançar rapidamente na rede principal, terá que lidar com essas complexas atualizações e fazer lançamentos frequentes. Fazer isso e manter uma alta disponibilidade é sempre um desafio.

Acredito que, após o mecanismo de prova de falhas e todas essas partes estarem prontas, haverá muitas atualizações no modo Plasma. Acredito que ainda há espaço para algumas otimizações na submissão em lote de compromissos. Atualmente, fazemos de forma bastante 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 o mais simples possível por enquanto, para que a revisão possa ser feita de forma simples e rápida, e não haja grandes diferenças em relação ao OP Stack. No entanto, agora existem algumas otimizações que podem torná-lo mais barato, como processar os compromissos em lote ou submetê-los a um blob, ou adotar outras abordagens diferentes. Portanto, com certeza vamos investigar isso para reduzir os custos do L1.

Estamos muito entusiasmados com isso. Claro, também estamos ansiosos por todo o conteúdo relacionado à interoperabilidade que está por vir e por poder interagir entre todas as cadeias. Compreender isso será 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 quais são as diferentes suposições de segurança.

Ben: Falando nisso,