DEVS ON DEVS: A conversa entre TDOT e BEN JONES

Neste episódio especial da coluna "Desenvolvedor para Desenvolvedor", convidamos o desenvolvedor do protocolo central do Plasma Mode, tdot (que também é desenvolvedor do Redstone), e Ben Jones, cofundador da Optimism. A Optimism é a principal impulsionadora do OP Stack. O Plasma Mode permite que os desenvolvedores construam sobre o OP Stack, mas sem a necessidade de publicar dados no L1, podendo alternar de forma flexível para provedores de dados off-chain, economizando custos e aumentando a escalabilidade. Neste diálogo, 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 roteiro futuro do Plasma Mode e do OP Stack, bem como 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 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 uma grande quantidade de dados na cadeia, então precisamos de uma solução que suporte essas necessidades e seja barata ao mesmo tempo. A equipe da Lattice já fez alguns experimentos no OP Stack, como prototipar alguns mundos em cadeia e implementá-los 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 mais alinhada com a filosofia do Ethereum e totalmente compatível com EVM." O que funciona 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 fonte de disponibilidade de dados (DA) da cadeia OP Stack, o que era muito caro. Portanto, claramente não podíamos usar calldata para iniciar um L2, pois nosso jogo de cadeia completa e o mundo MUD precisavam de uma taxa de transferência mais alta. Assim, decidimos começar a explorar outras soluções de disponibilidade de dados (Alt DA). Na verdade, já foi mencionado nos documentos iniciais do OP Stack a exploração de Alt DA.

Assim, perguntamo-nos: "O que aconteceria se começássemos com a DA off-chain?" Esperamos que todo o modelo de segurança e tudo o mais possa depender do Ethereum L1. Portanto, evitámos outras soluções 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 decidimos reutilizar alguns conceitos antigos do Plasma e colocá-los acima 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 a pilha OP existente? O nosso objetivo é fazer o mínimo de alterações na pilha OP, sem impactar o caminho do rollup, pois não queremos afetar a segurança de outras cadeias rollup que utilizam a pilha OP.

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 em 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 de DA que forçam a colocar dados na blockchain. Este é o segundo passo, integrar o contrato ao processo. Precisamos construir todo o sistema de integração durante o processo de derivação, para que você possa derivar dados de uma fonte de DA fora da cadeia e de um contrato de desafio DA L1, caso os dados sejam enviados para a blockchain durante o processo de resolução do desafio.

Este é o cerne da questão. É complexo, porque queremos manter as coisas elegantes e robustas. Ao mesmo tempo, é um conceito relativamente simples. Não tentamos reinventar a roda ou mudar todo o OP Stack, mas tentamos 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. Na mesma época, nós da Optimism quase reescrevemos toda a OP Stack de ponta a ponta, e chamamos essa versão de Bedrock.

Basicamente, após dois anos a construir o rollup, demos 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 por ser conhecido como a base de código Bedrock, que é a nossa maior atualização na rede.

Naquela época, colaborámos convosco num projeto chamado OPCraft, e eu acredito que Biomes é o seu sucessor espiritual, foi a vez que nos divertimos mais a jogar na blockchain. Ao mesmo tempo, também respiramos aliviados, pois outros 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 blockchain.

Não são apenas aquelas pessoas que desenvolveram grandes e complexas bibliotecas de código que podem fazer isso. Quando começamos a colaborar, ver outras pessoas a conseguir pegar nessa biblioteca de código e a fazer coisas realmente incríveis é uma grande validação. Depois, ver essa situação a expandir-se para o Plasma na aplicação real é realmente fixe. Eu posso até falar um pouco sobre essa 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 estava muito além da 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 verificação de estado do desafio 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". Essa é uma piada na história da escalabilidade do Ethereum daquele período.

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), e agora você pode olhar para trás e dizer "oh, isso era um desafio de disponibilidade de dados com alguns passos extras". Portanto, é realmente impressionante ver que não apenas a OP Stack está sendo usada por outras pessoas, mas também 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 delas, fazendo-as funcionar de uma maneira razoável e sensata. Isso é realmente legal.

02. 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 gastar até dez anos? Você entende o que quero dizer? Precisamos alcançar o estágio em que possamos entregar resultados o mais rápido possível.

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 preparadas. Você precisa de uma cadeia que possa ser rapidamente lançada 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 da estabilidade de 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 estamos a realizar para atingir esse objetivo. É por isso que precisamos manter uma alta agilidade, porque há muitas coisas a acontecer. Todo o ecossistema está a evoluir 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 é uma das ideias centrais da reescrita do Bedrock. Falei sobre a reescrita 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, essas coisas são realmente difíceis.

Cada linha de código adicional afasta você 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 por todos os seus esforços para impulsionar esse 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 questões como esta. 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, ainda há um longo caminho a percorrer. Mas essa é precisamente a verdadeira atração da modularidade. Para mim, do ponto de vista do OP Stack, esta é uma das coisas mais emocionantes, sem mencionar os jogos e mundos virtuais incríveis 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 esta pilha, o que é realmente notável.

Esta é a primeira vez que você pode mudar significativamente as propriedades do sistema através de um valor booleano crucial. 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, é 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 atributos alterados. Portanto, estou muito ansioso para ver que novas funcionalidades 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, que precisavam ser integradas ao tronco principal. Na altura, pensámos: "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. Foi muito natural. E eu acho que, na revisão e 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 um caminho de contribuição para o OP Stack. Portanto, estou muito agradecido por vocês estarem envolvidos nos 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. Falando nisso, 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 foco principal é na integração com o 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 alcançar funcionalidades como sem permissão e saídas forçadas.

Temos este objetivo final e estamos a realizá-lo gradualmente enquanto mantemos 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 haverá carga técnica." Mas, 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, uma vez que o mecanismo de proof of fault e todas essas partes estejam prontas, haverá muitas atualizações no modo Plasma. Acho que ainda há espaço para algumas otimizações na submissão em lote de commitments. Atualmente, fazemos isso de forma bem simples, um commitment por transação. E o commitment é apenas o 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 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á-las mais baratas, como agrupar os compromissos ou submetê-los a um blob, ou adotar outras abordagens diferentes. Portanto, certamente 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 por poder interagir entre todas as cadeias. Descobrir isso será um enorme progresso 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