Entrevista com desenvolvedores da Optimism e Redstone: O modo Plasma reconfigura a Camada 2

Na edição especial desta entrevista, convidamos o desenvolvedor principal do protocolo Plasma Mode, tdot(, que também é um dos desenvolvedores do Redstone ), e Ben Jones, cofundador do Optimism. O Optimism é o principal impulsionador 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 assim custos e aumentando a escalabilidade. Neste diálogo, eles exploraram 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, assim como a sua empolgação com o desenvolvimento no campo dos jogos em toda a cadeia.

01. Como usar o modo Plasma para melhorar a OP Stack

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

tdot: Há cerca de um ano, juntei-me à Lattice, 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, por isso precisamos de uma solução que suporte essas necessidades e que seja barata. A equipe da Lattice já fez alguns experimentos na OP Stack, como a prototipagem de alguns mundos on-chain e a sua implementação na OP Stack. Descobrimos que a OP Stack já é muito útil.

Então nos perguntamos: "Como podemos torná-lo mais barato?" A suposição básica é: "Acreditamos que a 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 na 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 cadeia OP Stack (DA), o que era muito caro. Portanto, claramente não podíamos iniciar um L2 com calldata, pois nosso jogo de cadeia completa e o mundo MUD precisavam de uma maior taxa de transferência. 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 para explorar 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. Assim, evitamos outras soluções de DA alternativas 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 de 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 na stack OP existente? Nosso objetivo é fazer o mínimo de alterações na stack OP, sem impactar o caminho do rollup, pois não queremos afetar a segurança de outras cadeias rollup que utilizam a stack OP.

Ao projetar o rollup, você não pensa: "E se alguém alterar 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 foi a primeira alteração que fizemos.

Depois, precisamos escrever contratos para criar esses desafios. Existe um desafio DA que força a colocação de dados na blockchain. Este é o segundo passo, integrar o contrato ao processo. Devemos construir todo o sistema de integração no processo derivativo, 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 à 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 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 legal.

Ben: Posso falar da perspectiva da OP. Você mencionou alguns trabalhos iniciais da Lattice. Coincidentemente, na mesma época, nós da Optimism quase completamos uma reescrita de ponta a ponta de toda a OP Stack, e esta versão que lançamos chamamos de Bedrock.

Basicamente, após dois anos de construção do rollup, fizemos 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 sendo chamado de código base Bedrock, que é a nossa maior atualização na rede.

Naquela altura, colaborámos com vocês num projeto chamado OPCraft, e eu acredito que Biomes é o seu sucessor espiritual, foi a vez que nos divertimos mais 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 acredito que outro ponto de viragem importante na escalabilidade nos últimos anos é que muitas pessoas podem executar a cadeia.

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

Antes de o Optimism se tornar o Optimism, na verdade estávamos a estudar 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 em dia, o Plasma é muito mais simples. Vamos separar a prova e o desafio da verificação de estado do desafio de dados. No final, há alguns anos, percebemos que os Rollups são muito mais simples do que o Plasma. Eu acho que a conclusão da comunidade na época foi "Plasma está morto". Este é um meme 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 extras". Portanto, é realmente incrível ver que não apenas a OP Stack está sendo usada por outras pessoas, mas também evoluiu para coisas que tentamos inicialmente, mas de uma forma muito confusa e imatura. Completamos um ciclo completo, e vocês fizeram abstrações incríveis ao redor disso, fazendo 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 problemas não resolvidos, e ainda estamos a trabalhar para os resolver. A chave é como evitar levar até dez anos? Entendes o que quero dizer? Precisamos chegar o mais rápido possível a uma fase em que possamos entregar resultados.

Esta é a nossa ideia. Já temos muitas aplicações baseadas em MUD que queremos lançar imediatamente na mainnet. Precisamos preparar uma mainnet o mais rápido possível 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, para que essas aplicações possam evoluir paralelamente enquanto resolvemos problemas, tornando-se melhores. Leva muito tempo desde a pesquisa e desenvolvimento até a implementação da estabilidade de produção.

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 atingir esse objetivo é realmente impressionante. É por isso que precisamos manter uma alta agilidade, porque há muitas coisas. Todo o ecossistema está se desenvolvendo muito rapidamente. Eu acho 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, uma carga técnica. O princípio da mínima modificação que mencionaste é um dos conceitos centrais na 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ó é muito poderoso. 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 as coisas mais difíceis de serem testadas em condições reais e introduzindo mais oportunidades de erro. Portanto, agradecemos muito por todo o esforço de vocês em impulsionar esse processo, especialmente pela contribuição ao novo modo de operação do OP Stack.

tdot: A OP Stack realmente criou uma maneira de você avançar rapidamente nessas coisas. 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, de fato ainda há um longo caminho a percorrer. Mas essa é a verdadeira atração do modular. 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 agora no Redstone. Apenas do ponto de vista do OP Stack, este é um exemplo muito poderoso que demonstra que muitos excelentes desenvolvedores principais já se juntaram e melhoraram este stack, o que é realmente notável.

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 aproximar-se 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 Geth da Camada 2, é 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 suas propriedades alteradas. 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 para a OP Stack, e que precisávamos integrá-lo à linha 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 excelente, então o processo de revisão também foi agradável. Sentiu-se 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 a OP Stack. Portanto, estou muito agradecido pela sua participação nos testes, impulsionando esses processos. Estou feliz que esses processos não tenham sido insuportáveis e que tenhamos alcançado alguns resultados. Dito isso, estou curioso, do seu ponto de vista, como você vê o desenvolvimento deste trabalho a seguir? O que você mais espera desenvolver a seguir?

tdot: Existem muitas direções de trabalho diferentes. Principalmente integradas com o 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 permissão e saída forçada.

Temos esse objetivo final e o estamos alcançando gradualmente, mantendo a segurança. Um desafio é que, às vezes, é mais fácil não entrar na mainnet, porque assim não é necessário fazer 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 e não há carga técnica." No entanto, se você quer lançar rapidamente na mainnet, deve lidar com essas atualizações complexas e lançar com frequência. Fazer isso e manter alta disponibilidade é sempre um desafio.

Acredito que, uma vez que o mecanismo de prova de falhas e todas essas partes estejam prontos, haverá muitas melhorias no aspecto do modelo Plasma. Penso que ainda há espaço para algumas otimizações na submissão em lote 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.

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 em relação ao OP Stack. Mas agora há algumas otimizações que podem torná-lo mais barato, como agrupar os compromissos ou submetê-los a um blob, ou utilizar outros métodos diferentes. Portanto, certamente vamos 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 se aproxima e por poder interagir entre todas as cadeias. Descobrir como 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: A propósito, isso