DEVS ON DEVS: A conversa entre TDOT e BEN JONES

Na entrevista especial desta edição do Devs on Devs, convidamos o desenvolvedor principal do protocolo central do Plasma Mode, tdot(, que também é um dos desenvolvedores do Redstone, ), e o cofundador da Optimism, Ben Jones. A Optimism é o principal impulsionador do OP Stack. O Plasma Mode permite que os desenvolvedores construam sobre o OP Stack, mas não precisam publicar dados no L1, podendo, em vez disso, alternar de forma flexível para provedores de dados off-chain, economizando custos e aumentando a escalabilidade. Durante esta conversa, eles discutiram a origem da colaboração entre Redstone e Optimism, a importância de reviver o Plasma, a necessidade de introduzir protocolos experimentais no ambiente de produção, o futuro roadmap do Plasma Mode e do OP Stack, e suas expectativas para o desenvolvimento no campo dos jogos em toda a cadeia.

01. Como melhorar a OP Stack usando o modo Plasma

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

tdot: Eu juntei-me à Lattice há cerca de um ano, responsável pelo Plasma Mode. O objetivo é claro: temos muitas aplicações MUD que consomem uma grande quantidade 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 barata. 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 o OP Stack é a estrutura mais alinhada com a filosofia do Ethereum e totalmente compatível com EVM." O que roda na mainnet pode rodar igualmente no OP Stack, essa é a solução ideal. Mas queremos que seja mais barato.

Na altura, calldata ainda era a 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, uma vez que nosso jogo de cadeia completa e o mundo MUD exigiam uma maior capacidade de processamento. 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 que envolve 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 queremos 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 DA off-chain e desafios de dados on-chain sobre a pilha OP existente? 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 de rollup que utilizam a pilha OP.

Ao projetar o rollup, você não deve pensar: "O que aconteceria se alguém mudasse o processo de geração de dados para armazenar dados de outros lugares?" Mesmo com essas alterações, o OP Stack ainda é muito poderoso e funciona bem logo de cara. Essa é a primeira alteração que fizemos.

Depois, precisamos escrever contratos para criar esses desafios. Existem desafios DA que forçam a colocar dados na cadeia. Este é o segundo passo, integrar o contrato no processo. Devemos construir todo o sistema de integração no 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 cadeia durante o processo de 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 a roda ou mudar todo o OP Stack, mas sim tentar manter as coisas simples em um ambiente complexo. Assim, de um modo geral, esta é uma jornada de engenharia muito legal.

Ben: Posso falar do ponto de vista da OP. Você mencionou alguns trabalhos iniciais da Lattice. Coincidentemente, ao mesmo tempo, nós da Optimism fizemos uma reescrita de ponta a ponta de toda a OP Stack, e a versão que lançamos chamamos de Bedrock.

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

Naquela altura, colaborámos convosco num projeto chamado OPCraft, e eu acredito que os Biomes são o seu sucessor espiritual, foi a vez em que mais nos divertimos a jogar na cadeia. Ao mesmo tempo, também respirámos de alívio, porque outras pessoas também podem usar o OP Stack para desenvolver. Eu acho 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 serem capazes de assumir essa biblioteca de código e fazer algumas coisas realmente incríveis é uma grande validação. E ver essa situação se expandir para o Plasma na aplicação prática é realmente muito legal. Posso até falar um pouco sobre aquela história.

Antes do Optimism se tornar Optimism, na verdade estávamos estudando uma tecnologia chamada Plasma. Naquela época, a tarefa que assumimos estava muito além da capacidade da comunidade de escalabilidade da época. O design que você vê nos primeiros designs do Plasma pode não ter uma correspondência direta com o Plasma de hoje.

Hoje, o Plasma é muito mais simples. Vamos separar a prova e o desafio da validação de estado dos desafios de dados. No final, percebemos há alguns anos que os Rollups são muito mais simples 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 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 olhar para trás e dizer "oh, isso era um desafio de disponibilidade de dados com alguns passos adicionais". Então, ver não apenas o OP Stack sendo usado por outras pessoas, mas também evoluindo para algo que tentamos inicialmente, mas de uma maneira muito confusa e imatura, é realmente impressionante. Nós completamos um ciclo completo, e vocês fizeram abstrações incríveis ao redor dele, fazendo-o 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 questões não resolvidas, e ainda estamos a trabalhar para os resolver. A chave é como evitar levar 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 lançar na mainnet imediatamente. Precisamos preparar uma mainnet para esses jogos o mais rápido possível. As pessoas já estão esperando 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 os problemas, tornando-se melhores. A partir do desenvolvimento até a implementação da estabilidade em produção leva muito tempo.

Para lançar algo na mainnet, tornando-o sem permissão, robusto e seguro, é necessário gastar muito tempo. Ver todo o processo que realizamos para alcançar esse objetivo é realmente impressionante. É por isso que precisamos manter uma alta agilidade, porque há muitas coisas a fazer. Todo o ecossistema está se desenvolvendo muito rapidamente. Eu acho que todos estão entregando uma quantidade enorme de inovações. É por isso que você precisa 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 de mínima alteração que você mencionou, é uma das ideias centrais que seguimos durante a reescrita do Bedrock. Eu 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ó é extremamente poderoso. Porque você está certo, essas 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 as coisas mais difíceis de serem testadas na prática e introduzindo mais oportunidades de erro. Portanto, agradecemos muito por todos os esforços de vocês em impulsionar esse processo, especialmente pela contribuição para o novo modo operacional do OP Stack.

tdot: A OP Stack realmente criou uma maneira de você avançar rapidamente em tais assuntos. Coordenar todos é muito difícil, pois obviamente 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 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 é a verdadeira atração do modularismo. Para mim, do ponto de vista do OP Stack, essa é uma das coisas mais empolgantes, sem mencionar os jogos e mundos virtuais incríveis que estão sendo construídos atualmente no Redstone. Puremente do ponto de vista do OP Stack, este é um exemplo muito poderoso que prova que muitos excelentes desenvolvedores principais já se juntaram e melhoraram esta pilha, o que é extraordinário.

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 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á a funcionar.

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. Estou muito ansioso para ver quais novas funcionalidades serão integradas. Lembro-me de que estávamos preocupados na época, pois tínhamos um fork que continha todas as alterações no OP Stack, que precisava ser fundido na branch principal. Naquele momento, pensamos: "Meu Deus, revisar tudo isso seria uma loucura."

Tivemos que dividir isso em partes menores, mas todo o processo decorreu de forma muito suave. A atmosfera de colaboração com a equipe foi muito boa, então o processo de revisão também foi agradável. Isso pareceu 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 um caminho 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 tenham sido difíceis de suportar e que tenhamos alcançado alguns resultados. Dito isso, estou curioso, do seu ponto de vista, 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. Principalmente relacionadas à 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 a ausência de permissão e a 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 mainnet pode ser mais fácil, pois assim não é necessária uma hard fork. Você pode pensar: "Oh, eu só vou esperar até que tudo esteja completamente pronto para lançar, assim não é necessária uma 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, após o mecanismo de prova de falhas e todas essas partes estarem prontas, haverá muitas atualizações na parte do modelo Plasma. Acho que ainda há espaço para otimizações na submissão em massa 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 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á-lo mais barato, como agrupar os compromissos ou submetê-los a um blob, ou adotar outros métodos diferentes. Por isso, definitivamente iremos investigar isso para reduzir os custos do L1.

Estamos muito empolgados com isso. Claro, também estamos muito ansiosos por todo o conteúdo relacionado à interoperabilidade que está por vir, e por poder interagir entre todas as cadeias. Descobrir isso será um grande avanço para os usuários.

Muitos desses trabalhos certamente terão de 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 sobre isso, será sobre o OP Stack