DEVS ON DEVS: TDOT e BEN JONES em diálogo

Este diálogo especial convidou o desenvolvedor do protocolo central do Plasma Mode, tdot(, que também é um dos desenvolvedores do Redstone ) e co-fundador da Optimism, Ben Jones. A Optimism é o principal impulsionador do OP Stack. O Plasma Mode permite que os desenvolvedores construam no OP Stack, mas não precisam publicar dados no L1, podendo alternar de forma flexível para provedores de dados off-chain, economizando assim custos e melhorando a escalabilidade. Eles discutiram a origem da colaboração entre Redstone e Optimism, a importância de reviver o Plasma, a necessidade de introduzir protocolos experimentais em ambientes de produção, o futuro do Plasma Mode e do OP Stack, bem como suas expectativas para o desenvolvimento no campo dos jogos em toda a cadeia.

Como usar o modo Plasma para melhorar o OP Stack

Ben: Como é o processo para começar a melhorar o OP Stack?

tdot: Eu juntei-me à Lattice há cerca de um ano, sendo responsável pelo Plasma Mode. O objetivo era claro: temos muitas aplicações MUD que consomem uma grande quantidade de gas, enquanto tentamos colocar uma grande quantidade de dados na cadeia, portanto, precisamos de uma solução que suporte essas necessidades e seja barata. A equipe da Lattice já realizou alguns experimentos no OP Stack, como a prototipagem de alguns mundos on-chain e a sua implementação no OP Stack. Descobrimos que o OP Stack já é muito utilizável.

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 EVM." O que está em funcionamento na mainnet pode funcionar 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, claramente não conseguimos iniciar um L2 com calldata, pois nosso jogo de cadeia completa e o mundo MUD precisam de maior throughput. Assim, decidimos começar a experimentar 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 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 precisamos 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 sobre o OP Stack existente? O nosso objetivo é fazer o mínimo de alterações no OP Stack, sem afetar o caminho do rollup, porque não queremos impactar a segurança de outras redes rollup que utilizam 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 poderoso e funciona muito bem fora da caixa. Esta é a primeira modificaçã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 durante o processo de derivação, para que você possa derivar dados de uma fonte DA fora da cadeia e de um contrato de desafio DA L1, caso os dados sejam enviados para a 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 tentando reinventar tudo 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 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 quase toda a OP Stack de ponta a ponta, e chamamos este lançamento 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 extremo, como seria isso?" Isso evoluiu para a biblioteca de código que acabou por ser chamada Bedrock, que é a nossa maior atualização à rede.

Naquela altura, colaborámos convosco num projeto chamado OPCraft, e eu considero que Biomes é o seu sucessor espiritual, foi a vez que mais nos divertimos a jogar na blockchain. Ao mesmo tempo, também respirámos de alívio, porque outras pessoas também podiam usar o OP Stack para desenvolver. Eu acho que um outro ponto de viragem importante na escalabilidade nos últimos anos foi que muitas pessoas puderam operar a blockchain.

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 incríveis é uma grande validação. Depois, ver essa situação se expandir para o Plasma em aplicações reais é realmente muito legal. Eu até posso falar um pouco sobre aquela história.

Antes de o Optimism se tornar Optimism, estávamos realmente a investigar uma tecnologia chamada Plasma. Na altura, a tarefa que assumimos ultrapassava em muito a capacidade da comunidade de escalabilidade daquela é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 dos desafios de 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". Esta é 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, na época havia conceitos como saídas (exits), agora você pode olhar para trás e dizer "oh, isso era um desafio de disponibilidade de dados com alguns passos adicionais". Então, é realmente incrível ver não apenas o OP Stack sendo usado por outros, mas também evoluindo 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, tornando-o funcional 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 problemas não resolvidos, e estamos a trabalhar para os resolver. A chave é como evitar um desperdício de tempo de 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 baseadas em MUD que queremos colocar 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 em paralelo enquanto resolvemos os problemas, tornando-se melhores. Desde o desenvolvimento até a implementação, a estabilidade em produção leva muito tempo.

Para lançar algo na mainnet, tornando-o sem permissão, robusto e seguro, é necessário investir 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 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 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 centrais na reescrita do Bedrock. Eu falei sobre a reescrita de ponta a ponta, mas o mais importante é que reduzimos cerca de 50.000 linhas de código, o que é muito poderoso por si só. 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 todos os seus esforços para impulsionar esse processo, especialmente as contribuições para o novo modo de operação da 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 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, realmente ainda há um longo caminho a percorrer. Mas essa é exatamente a atração central da modularidade. Para mim, do ponto de vista do OP Stack, isso é uma das coisas mais emocionantes, sem mencionar os incríveis jogos e mundos virtuais que estão sendo construídos atualmente no Redstone. Apenas do ponto de vista do OP Stack, este é um exemplo muito poderoso que prova que muitos excelentes desenvolvedores principais se juntaram e melhoraram este stack, o que é 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, também 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 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 continha todas as alterações no OP Stack, e que precisávamos fundi-lo na branch principal. Naquele momento, pensamos: "Meu Deus, rever tudo isso seria uma loucura."

Tivemos que dividi-lo em partes menores, mas todo o processo decorreu de forma muito suave. A atmosfera de colaboração com a equipe é excelente, então o processo de revisão também foi muito agradável. Foi muito natural. E eu acho que o processo foi muito rápido na revisão e na resolução de algumas questões potenciais. Tudo ocorreu 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 estarem participando dos testes e impulsionando esses processos. Estou feliz que esses processos não tenham sido difíceis de suportar 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ê está mais ansioso para desenvolver a seguir?

tdot: Existem muitas direções de trabalho diferentes. Principalmente relacionadas à integração do mecanismo de prova de falhas. Adotamos uma abordagem gradual 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 implementá-lo gradualmente, mantendo a segurança. Um desafio é que, às vezes, não lançar na mainnet pode ser mais fácil, porque 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 e não há carga técnica." Mas se você quiser lançar rapidamente na mainnet, terá que lidar com essas atualizações complexas e publicar com frequência. Fazer isso e manter alta disponibilidade é sempre um desafio.

Acredito que, após o mecanismo de prova de falha e todas essas partes estarem prontas, haverá muitas atualizações na parte do modelo Plasma. Acho que ainda há espaço para otimização na submissão em lote de compromissos. Neste momento, 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.

Vamos manter as coisas o mais simples possível por enquanto, para que a revisão possa ser simples e rápida, e não haja grandes diferenças para o OP Stack. No entanto, agora existem algumas otimizações que podem torná-lo mais barato, como agrupar os commitments ou submetê-los em blobs, ou adotar outros métodos diferentes. Portanto, com certeza iremos 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 pela capacidade de interagir entre todas as cadeias. Descobrir isso será um grande avanço para os usuários.

Muitos desses trabalhos têm certeza de que devem 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 sobre isso, será mais um teste para a modularidade do OP Stack. As provas de falha que você mencionou (fault proofs), estamos muito ansiosos por sua implementação no Plasma.