Devs on Devs: conversa entre 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 cofundador de um conhecido projeto Layer 2, Ben Jones, para uma conversa. O conhecido projeto Layer 2 é o principal impulsionador do OP Stack. O Plasma Mode permite que os desenvolvedores construam sobre o OP Stack, mas não precisam publicar dados na L1, podendo alternar de forma flexível para provedores de dados off-chain, economizando custos e aumentando a escalabilidade. Neste diálogo, eles exploraram a origem da colaboração entre o Redstone e o projeto Layer 2, a importância de revitalizar o Plasma, a necessidade de introduzir protocolos experimentais em ambientes de produção, o roadmap futuro do Plasma Mode e do OP Stack, bem como sua empolgação com o desenvolvimento no campo dos jogos em blockchain.

Como usar o modo Plasma para melhorar o OP Stack

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

tdot: 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 quantidade significativa de gas, enquanto tentamos colocar uma grande quantidade de dados na blockchain, por isso precisamos de uma solução que suporte essas necessidades e que seja ao mesmo tempo barata. A equipe da Lattice já fez alguns testes no OP Stack, como a prototipagem de alguns mundos na blockchain e a sua implementação 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 o OP Stack é a estrutura que mais se alinha com a filosofia do Ethereum e é totalmente compatível com a EVM." O que funciona na mainnet pode funcionar igualmente no OP Stack, esta é 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, não podíamos claramente iniciar um L2 com calldata, pois nosso jogo em 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: "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 um armazenamento centralizado de DA, e depois encontrar um modelo de segurança eficaz no L1.

É por isso que queremos reutilizar alguns conceitos antigos de Plasma e colocá-los em cima de rollup. Aqui estão algumas diferenças. A maior dúvida é como implementar DA off-chain e desafios de dados on-chain na pilha OP existente? Nosso objetivo é fazer o mínimo de alterações na pilha OP, sem afetar o caminho do rollup, porque não queremos impactar a segurança de outras cadeias de rollup que usam a pilha OP.

Ao projetar um rollup, você não pensa: "O que aconteceria se alguém alterasse o processo de geração de dados para armazenar dados em outro lugar?" Mesmo com essas alterações, o OP Stack continua muito poderoso e funciona bem logo de cara. Esta é a primeira mudança que fizemos.

Depois, precisamos escrever contratos para criar esses desafios. Existem desafios de DA que forçam a colocar dados na cadeia. Este é o segundo passo, integrar o contrato ao 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 enviados para a cadeia durante o processo de resolução do desafio.

Este é o ponto central da questão. É 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 sim manter as coisas simples em um ambiente complexo. Portanto, no geral, esta é uma jornada de engenharia muito interessante.

Ben: Posso falar do ponto de vista da OP. Você mencionou alguns dos trabalhos iniciais do Lattice. Justamente na mesma época, fizemos uma reescrita completa de toda a OP Stack, que chamamos de Bedrock.

Basicamente, após construir o rollup durante dois anos, damos um passo atrás e refletimos: "Bem, se quisermos levar todas as experiências que aprendemos ao extremo, como seria isso?" Isso evoluiu para o que acabou sendo chamado de Bedrock, que é a maior atualização que fizemos para a rede.

Naquela época, colaboramos com vocês em um projeto chamado OPCraft, e eu acredito que Biomes é seu sucessor espiritual, foi a vez que mais nos divertimos jogando na blockchain. Ao mesmo tempo, também respiramos aliviados, pois outras pessoas também podem usar o OP Stack para desenvolver. Eu acho que um outro ponto de virada importante na escalabilidade nos últimos anos é que muitas pessoas podem executar a blockchain.

Não são apenas aqueles que desenvolveram bibliotecas de código enormes e complexas 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 na aplicação prática é realmente incrível. Eu posso até falar um pouco sobre essa história.

Antes da criação de um conhecido projeto Layer 2, estávamos na verdade a investigar uma tecnologia chamada Plasma. Naquela época, 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 as provas e os desafios da validação de estado dos desafios de dados. No final, há alguns anos percebemos 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 da história de 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, 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 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, é realmente surpreendente. Completamos um ciclo completo, e vocês fizeram abstrações incríveis em torno disso, fazendo com que funcionasse de uma forma razoável e sensata. Isso é realmente legal.

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 ainda estamos a trabalhar para os resolver. A chave é como evitar gastar até uma década? Você entende o que quero dizer? Precisamos rapidamente atingir uma fase em que possamos entregar resultados.

Esta é a nossa ideia. Já temos muitas aplicações baseadas em MUD que queremos colocar imediatamente na mainnet. Precisamos preparar uma mainnet para esses jogos o mais rápido possível. As pessoas estão esperando e estão 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 em paralelo enquanto resolvemos os problemas e se tornam melhores. Desde a pesquisa e desenvolvimento até a implementação, a estabilidade de produção leva muito tempo.

Lançar algo na mainnet, tornando-o sem permissão, robusto e seguro, exige muito tempo. É impressionante ver todo o processo que realizamos para alcançar esse objetivo. É por isso que precisamos manter uma alta agilidade, pois há muitas coisas acontecendo. Todo o ecossistema está se desenvolvendo muito rapidamente. Acredito 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, um fardo técnico. O princípio da menor alteração que você mencionou é uma das ideias centrais que seguimos 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 por si só é muito poderoso. Porque você está certo, essas coisas são realmente difíceis.

Cada linha de código adicionada afasta você 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 todo o seu esforço para impulsionar esse processo, especialmente pela contribuição ao novo modelo operacional do OP Stack.

tdot: A OP Stack realmente criou uma maneira de você avançar rapidamente em questões como esta. Coordenar todos é muito difícil, porque 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 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 é exatamente a atração central da modularidade. 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 na Redstone. Apenas 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. Conseguir fazer isso completamente, como você disse, ainda há um longo caminho a percorrer. Mas mesmo se aproximando de fazê-lo 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: Agora a situação melhorou. A partir deste exemplo, vocês transformaram tudo em pequenos módulos independentes, que podem ser ajustados e ter atributos alterados. Portanto, estou muito ansioso para ver quais novas funcionalidades serão integradas. Lembro-me de que estávamos preocupados com o fato de termos um fork que incluía todas as alterações no OP Stack, e que precisávamos fundi-lo na branch 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 ótima, por isso o processo de revisão também foi 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, 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, na sua opinião, como este trabalho irá evoluir a seguir? O que você mais espera desenvolver a seguir?

tdot: Existem muitas direções de trabalho diferentes. Principalmente com a integração do 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 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, é mais fácil não lançar na mainnet, pois assim não é necessário realizar um hard fork. Você pode pensar: "Oh, só preciso esperar até que tudo esteja completamente pronto para lançar, assim não é necessário fazer um hard fork, nem 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 enquanto mantém alta disponibilidade é sempre um desafio.

Acredito que, uma vez que o mecanismo de prova de falhas e todas essas partes estejam prontas, haverá muitas melhorias na parte do modelo Plasma. Acho 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.

Nós mantemos as coisas tão simples quanto possível por enquanto, assim a revisão pode ser simples e rápida, e não há grandes diferenças para a OP Stack. Mas agora há algumas otimizações que podem torná-lo mais barato, como agrupar os compromissos ou submetê-los.