DEVS ON DEVS: A conversa entre TDOT e BEN JONES

Neste diálogo especial de Devs on Devs, convidamos o desenvolvedor central 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 os desenvolvedores construam sobre o OP Stack, mas não precisam 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 revitalizar o Plasma, a necessidade de introduzir protocolos experimentais em 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 cadeia.

01. 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 cadeia, por isso precisamos de uma solução que suporte essas necessidades e seja econômica. A equipe da Lattice já fez alguns experimentos no OP Stack, como prototipar alguns mundos on-chain e implementar no OP Stack. Descobrimos que o OP Stack já é muito funcional.

Assim, perguntamos a nós mesmos: "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 roda na mainnet pode rodar igualmente no OP Stack, esta é a solução ideal. Mas queremos que seja mais barato.

Na época, o 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 iniciar um L2, uma vez que nosso jogo de cadeia inteira e o mundo MUD exigiam maior throughput. 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 que deveríamos explorar o Alt DA.

Então nos perguntamos: "O que aconteceria se começássemos com DA fora da cadeia?" 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 então encontrar um modelo de segurança eficaz no L1.

É por isso que precisamos reutilizar alguns conceitos antigos do Plasma e colocá-los sobre o rollup. Aqui há 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? Nosso objetivo é fazer o mínimo de alterações no OP Stack, sem impactar o caminho do rollup, pois não queremos afetar a segurança de outras cadeias de rollup que utilizam o OP Stack.

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

Depois, precisamos escrever contratos para criar esses desafios. Existem desafios DA destinados a forçar a inclusão de dados na cadeia. 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 DA fora da cadeia e de um contrato de desafio DA L1, caso os dados sejam submetidos à 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 tentámos reinvenção do que já existe ou mudar todo o OP Stack, mas sim tentar manter as coisas simples num ambiente complexo. Portanto, no geral, esta é uma jornada de engenharia muito legal.

Ben: Eu posso falar sobre isso do ponto de vista da OP. Você mencionou alguns trabalhos iniciais da Lattice. Justamente na mesma época, nós da Optimism reescrevemos quase toda a OP Stack de ponta a ponta, e a publicação que chamamos de Bedrock.

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

Naquela altura, colaboramos convosco num projeto chamado OPCraft, e eu acredito que Biomes é o seu herdeiro espiritual, foi a vez que nos divertimos mais a jogar na cadeia. Ao mesmo tempo, também respiramos de alívio, pois outras pessoas também podem usar o OP Stack para desenvolver. Acredito 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 conseguirem assumir essa biblioteca de código e fazer coisas realmente incríveis é uma grande validação. Depois ver essa situação se expandir para o Plasma na aplicação prática é realmente muito legal. 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. Na altura, a tarefa que assumimos ultrapassava em muito a capacidade da comunidade de escalabilidade. O design que você vê nos primeiros designs do Plasma pode não ter uma relação direta com o Plasma de hoje.

Hoje em dia, o Plasma é muito mais simples. Vamos separar a prova e o desafio da validação de estado do desafio dos dados. No final, percebemos há alguns anos que os Rollups são muito mais simples do que o Plasma. Acho que, na altura, a conclusão da comunidade foi "Plasma está morto". Esta é uma piada da história da escalabilidade do Ethereum desse 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 saídas (exits), agora você pode olhar para trás e dizer "oh, isso foi um desafio de disponibilidade de dados com alguns passos adicionais". Portanto, é realmente impressionante ver que não apenas o OP Stack está sendo utilizado por outras pessoas, mas também evoluiu para algo que tentamos inicialmente, mas de uma maneira muito confusa e imatura. Completamos um ciclo completo, vocês fizeram abstrações incríveis em torno dele e fizeram com que funcionasse 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 gastar até dez anos de tempo? Você entende o que quero dizer? Precisamos alcançar rapidamente uma fase em que possamos entregar resultados.

Esta é a nossa ideia. Já temos muitas aplicações baseadas em MUD que querem ser lançadas imediatamente na mainnet. Precisamos preparar uma mainnet rapidamente para esses jogos. As pessoas já 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 se desenvolver em paralelo enquanto resolvemos os problemas e se tornam melhores. Desde a pesquisa e desenvolvimento até a realização da estabilidade de produção leva muito tempo.

Para colocar algo online na mainnet, de forma que seja sem permissões, robusto e seguro, é necessário um grande investimento de tempo. É impressionante ver todo o processo que nos levou a alcançar esse objetivo. É 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 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 é uma das ideias centrais 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 em si é muito poderoso. 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 condições reais e introduzindo mais oportunidades de erro. Portanto, agradecemos muito todo o seu esforço em impulsionar este 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 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 periodicamente. Do ponto de vista da coordenação, isso realmente não é fácil.

Ben: Sim, de fato ainda há um longo caminho a percorrer. Mas essa é justamente a essência do charme da modularidade. Para mim, sob a perspectiva do OP Stack, isso é uma das coisas mais empolgantes, sem mencionar os jogos e mundos virtuais incríveis que estão sendo construídos agora no Redstone. Puramente do ponto de vista do OP Stack, este é um exemplo muito poderoso que prova que muitos ótimos desenvolvedores centrais já 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 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, foi 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 módulos pequenos e independentes, que podem ser ajustados e ter suas propriedades alteradas. Portanto, estou ansioso para ver quais novas funcionalidades serão integradas. Lembro-me de que estávamos preocupados na época, pois tínhamos um fork que incluía todas as alterações no OP Stack, e precisávamos fundi-lo ao tronco principal. Naquele momento, pensamos: "Meu Deus, revisar tudo isso seria uma loucura."

Tivemos que dividi-lo em partes menores, mas todo o processo decorreu muito bem. A atmosfera de colaboração com a equipe foi muito boa, então o processo de revisão também foi agradável. Foi uma sensação muito natural. E eu acho que, na revisão e na resolução de alguns problemas potenciais, esse 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, sou muito grato pela sua participação nos testes, impulsionando esses processos. Fico feliz que esses processos não tenham sido insuportáveis e que tenhamos alcançado alguns resultados. Falando nisso, 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 na integração com mecanismos de prova de falha. Adotamos uma abordagem progressiva para descentralizar toda a pilha tecnológica e aumentar suas características sem permissão, tendo como objetivo final a implementação de funcionalidades como sem permissão e saída forçada.

Temos esse objetivo final e estamos a realizá-lo gradualmente, mantendo 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 é 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 com frequência. Fazer isso e manter alta disponibilidade é sempre um desafio.

Eu acredito que, após a prova de falha e todas essas partes estarem prontas, haverá muitas atualizações na parte do modo Plasma. Acho que ainda há espaço para algumas otimizações na submissão em lote de compromissos. Agora fazemos de forma bem 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 tão simples quanto possível por enquanto, para que a revisão possa ser simples e rápida, e não há 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 blobs, 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 pela capacidade de interagir entre todas as cadeias. Descobrir 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: