O futuro das atualizações do Ethereum, pós-fusão [Parte 2]

A maior atualização de todos os tempos do Ethereum - a mudança para um mecanismo de consenso de prova de participação - está chegando. Mas, embora a mesclagem deva adicionar segurança e sustentabilidade, ela não inclui sharding, o método há muito esperado de dimensionar a rede. 

In Parte I da nossa conversa com o pesquisador da Ethereum Foundation (EF) Danny Ryan, que ajudou a coordenar o processo de atualização, discutimos o que o Merge foi projetado para trazer em termos de segurança e estabilidade.

Na Parte II, Ryan fala sobre atualizações que os usuários podem esperar no futuro, incluindo danksharding, Ethereum sem estado e atualizações de segurança que lidam com o aumento do valor extraível do minerador (MEV). Ele também explica como esse esforço de anos resultou em novos métodos para pesquisar e testar futuras atualizações.

---

Coordenação em uma rede descentralizada

FUTURO: Você aludiu à possibilidade de os mineradores se bifurcarem e continuarem tentando usar a antiga cadeia. Mas, na maioria das vezes, esse processo colocou todos a bordo. Qual é o seu papel nisso como pesquisador da Ethereum Foundation? Como um movimento tão grande é coordenado?

DANI RIAN: Comecei a me envolver em provas de participação por volta de 2017 e, mesmo assim, parecia uma conclusão precipitada. Isso foi há cinco anos. E a comunidade Ethereum tem estado muito disposta a não estagnar e fazer certo, e construir um protocolo que não funcione apenas hoje, mas funcione, espero, por 100 anos ou mais. 

Assim, no início de seu ethos, quando havia um palpite de que a prova de participação poderia ser feita com segurança e melhor do que a prova de trabalho, as pessoas ficaram muito empolgadas com isso. E quando 2016, 2017 chegar, as pessoas não estão apenas animadas com isso, mas também ansioso para que isso aconteça. Parece que é muito profundo no ethos da comunidade Ethereum que isso vai acontecer.

Existem questões mais delicadas. Há menos conclusões precipitadas em que o EF, a equipe de pesquisa e os clientes que estão fora do EF estão todos tentando encontrar soluções para os problemas e manter as coisas em movimento. Às vezes, as soluções estão um pouco mais em uma zona cinzenta – essa é a solução certa? Fazemos agora? Fazemos isso depois? Isso acaba sendo difícil, e a EF tenta ajudar a coordenar esses métodos, ajudar a fazer algumas P&D para ajudar a avaliar soluções, ajudar a facilitar conversas para decidir sobre cronogramas, prioridades e pedidos. 

Mas, no final das contas, na maioria dos itens, a agenda da EF é ajudar a tornar o protocolo mais sustentável, seguro e escalável enquanto é descentralizado – e não enviar um recurso específico sobre o outro. Então, muito do que estamos focados tanto no trabalho técnico quanto na coordenação social é facilitar a boa informação, a boa pesquisa e o bom diálogo para que os muitos participantes envolvidos na P&D, na engenharia e na comunidade possam manter coisas se movendo e chegar a decisões.

Nos últimos cinco anos, muito mais vozes foram adicionadas à comunidade e, após a fusão, teoricamente ela se tornará mais descentralizada. Que pensamentos você tem sobre o processo futuro de atualizações? É possível que estejamos olhando para algum tipo de DAO de camada um para coordenar atualizações?

Pelo que entendi, a comunidade Ethereum não gosta de votação on-chain - ou qualquer tipo de votação e atualizações plutocráticas - e que o protocolo é aquele que os usuários decidem executar. Geralmente, há um amplo consenso. Às vezes há cismas – por exemplo, Ethereum vs. Ethereum clássico. Mas no final das contas é seu direito e direito da comunidade e direitos dos usuários descobrir qual software eles querem executar. Geralmente, concordamos porque as pessoas estão tentando melhorar o Ethereum, e não há muito conflito em algumas das coisas principais. 

Portanto, não espero um mecanismo técnico formal. Espero que o processo continue a crescer, mudar e evoluir nesse tipo de governança flexível, onde há pesquisadores, desenvolvedores, membros da comunidade, dapps e coisas assim. 

Eu diria que – e acho que você fez alusão a isso – há mais e mais pessoas na mesa, e está ficando cada vez mais difícil tomar decisões e enviar coisas. Eu pessoalmente acredito que isso é um recurso. Eu acho que, tanto do ponto de vista da confiabilidade para aplicativos e usuários, quanto para evitar a captura a longo prazo, provavelmente é importante que muito do protocolo Ethereum se ossifique. Portanto, embora seja cada vez mais difícil estar no turbilhão da governança e tentar embarcar, e às vezes parece que estou tentando correr com um colete com pesos e pesos nos tornozelos e agora tenho pesos nos pulsos, acho que temos algumas coisas importantes para fazer nos próximos anos. Mas acho que vai ser cada vez mais difícil fazer as coisas. E eu acho que isso é uma coisa boa.

Vitalik chama isso de “velocidade de escape funcional.” Vamos levar o Ethereum a um lugar onde ele tenha escala e funcionalidade suficientes para que possa ser estendido e utilizado de infinitas maneiras na próxima camada da pilha. Faça com que o EVM tenha funcionalidade mínima suficiente, tenha disponibilidade de dados suficiente para lidar com grandes quantidades de escala e, em seguida, os aplicativos podem estendê-lo em contratos inteligentes. As camadas dois podem experimentar novas VMs dentro de suas construções de camada dois; você pode escalar Ethereum e assim por diante e assim por diante.

Acho que vai ser cada vez mais difícil fazer as coisas. E eu acho que isso é uma coisa boa.

garfos de sombra

Uma das coisas que saíram desse processo de teste específico foram os shadow forks, o processo de copiar dados reais do Ethereum para uma rede de teste para simular um ambiente de teste da rede principal. Isso sempre esteve no plano? E como você acha que isso pode mudar o processo de P&D para futuras atualizações?

Deveríamos estar fazendo forks de sombra nos últimos quatro anos. Êles são ótimos; eles são muito legais. Eu essencialmente pego um número de nós que controlamos - chame como 10, 20, 30 - e eles acham que um fork está chegando, então eles estão na rede principal ou em uma dessas redes de teste e, em seguida, em alguma condição de fork, como altura do bloco, eles todos dizem "Ok, estamos na nova rede". E eles se bifurcam e ficam em sua própria realidade, mas têm o estado do tamanho da rede principal.

E por um tempo você pode canalizar transações da rede principal para essa realidade bifurcada para obter uma quantidade razoável do que parece ser atividade orgânica do usuário, o que é muito bom. Isso nos permite testar o que acabou sendo processos altamente orgânicos e difíceis de simular. E isso tem sido ótimo. Igual [Jayanthi] e outros que trabalham na equipe de DevOps da EF têm orquestrado isso, e aprendemos muito com eles. Acho que se você perguntar a alguém, eles diriam: “Bem, sim, teria sido ótimo se estivéssemos fazendo isso três anos atrás, quatro anos atrás em cada atualização”.

Mas vou dizer outra coisa. Venho dizendo isso [desde] um ano atrás e agora estamos na cauda longa em segurança e testes: está realmente destruindo essa coisa, garantindo que todos os casos de borda estejam corretos, garantindo que, quando vier, aconteça — nós tentamos e funciona. E acontece que, da maneira como o software é construído com clientes da camada de execução de consenso, há muito o que construir em termos de teste. Shadow forks é um deles. Utilizando outros ambientes de simulação que podem testar essas duas coisas juntas, como Curtose, Antítese, E outros. 

Há algumas outras coisas que precisamos fazer, como religar Colméia, que é nossa estrutura de teste de compilação noturna de integração, para que ela possa lidar com esses dois tipos de clientes e para que você possa escrever testes onde diferentes complexidades estão acontecendo em ambos os lados do corredor. Tudo isso tinha que acontecer. Primeiro, os frameworks tiveram que ser desenvolvidos ou modificados. Então muitos dos testes tiveram que ser escritos. Então, o bom do Merge é que nós realmente aprimoramos as ferramentas em nosso conjunto de ferramentas para poder testar atualizações de tal forma que a próxima atualização será muito mais sobre escrever os testes em vez de pensar em como testá-los e escrevendo os frameworks para testá-lo. 

O que vem depois da prova de participação?

Como isso vem acontecendo há muito tempo, inicialmente o sharding viria primeiro. Mas os desenvolvimentos do ecossistema significavam que você poderia primeiro passar para a prova de participação. Houve outros desenvolvimentos do ecossistema que surgiram durante esse processo que podem mudar sua abordagem para atualizações futuras?

Em primeiro lugar, provavelmente há várias razões pelas quais a mudança de prova de participação foi priorizada. Uma era parar de pagar demais por segurança com prova de trabalho. E a outra era que a escala estava começando a surgir através dessas construções da segunda camada. Então, talvez se você tiver uma escala de 10 a 100x a partir disso, você pode se concentrar nessa outra coisa e terminar o trabalho e unificar esses dois sistemas diferentes: a cadeia de beacon e a rede principal atual. 

Há algumas outras coisas que afetaram a forma como pensamos sobre cronogramas e prioridades. Eu mencionei anteriormente que todo o mundo MEV jogou uma chave em algumas coisas. Há centralização e outras preocupações de segurança que surgem quando você começa a pensar para onde o MEV pode ir. E tem havido muita pesquisa nos últimos 12 meses sobre como mitigar algumas dessas preocupações com modificações de camada um. Dependendo da análise das ameaças vindas do mundo MEV, isso pode priorizar determinados recursos de segurança e adições de segurança ao L1 sobre outra coisa que talvez fosse a prioridade. 

Eu acho que algo interessante é o roteiro de fragmentação e a construção atual esperada, que é chamada de danksharding, em homenagem a Dankrad [Feist], nosso pesquisador da EF. Toda a construção é realmente simplificada quando você assume que esses atores MEV altamente incentivados existem. Alguns desses atores externos não apenas alteraram a forma como pensamos sobre segurança, mas também alteraram a forma como podemos pensar sobre a construção desses protocolos. Se você assume que o MEV existe, se você assume que esses atores altamente incentivados estão dispostos a fazer certas coisas por causa do MEV, então, de repente, você tem esse participante terceirizado no consenso de que talvez você possa descarregar as coisas, o que de muitas maneiras pode ser simplificado. Portanto, não há apenas coisas ruins que surgem, mas também novos tipos de designs que se abrem.

Nós realmente aprimoramos as ferramentas em nosso conjunto de ferramentas para poder testar atualizações de tal forma que a próxima atualização será muito mais sobre escrever os testes do que pensar em como testá-los.

O Ethereum sem estado ainda está sendo ativamente discutido e pesquisado? 

Sim. O estado – todas as contas e contratos e saldos e outras coisas – esse é o estado do Ethereum. Dado onde você está no blockchain, há um estado de realidade. Essa coisa cresce com o tempo, cresce linearmente. E se você aumentar o limite de gás, ele cresce ainda mais rápido. Então isso é uma preocupação. Se ele crescer mais rápido do que o espaço de memória e disco rígido das máquinas do consumidor, então você terá problemas para realmente poder executar nós em computadores domésticos e hardware do consumidor, que tem preocupações de segurança e centralização. Além disso, se você falar com alguns dos OBTER membros da equipe [cliente], o fato de o estado continuar crescendo significa que eles precisam continuar otimizando as coisas. Então é difícil.

Ethereum sem estado e coisas nessa direção de pesquisa são um caminho de solução potencial para isso, onde para executar um bloco eu não preciso de todo o estado; há uma espécie de entrada oculta na execução da função de um bloco. Eu preciso do pré-estado, eu preciso do bloco, e então eu pego o pós-estado para saber se o bloco é válido. Enquanto que com o Ethereum sem estado, os requisitos de estado - as contas e outras coisas que você precisa para executar esse bloco específico - estão embutidos no bloco e são provas de que esses são o estado correto. Agora, executar um bloco e verificar a validade do Ethereum se torna apenas [ter] que ter o bloco, o que é muito bom. Agora podemos ter nós completos que não necessariamente têm estado completo. Ele abre todo um espectro de como construir nós. Então, eu posso ter um nó que valida totalmente e não tem o estado, eu posso ter um nó que apenas mantém o estado relevante para mim, ou eu posso ter nós muito completos que têm todo o estado e esse tipo de coisa.

Isso está sendo trabalhado ativamente. Na verdade, acredito que atualmente existe uma rede de teste com todas as outras coisas divertidas que precisam acontecer para que isso aconteça. Minha avaliação atual é que a demanda por sharding e escala L1 é maior do que a ameaça iminente de crescimento do estado. Então, é muito provável que, como um será priorizado em relação ao outro, a escala será priorizada. 

Dito isso, é difícil dizer. Há "protodanksharding”, que é meio que uma maneira gradual de obter um pouco mais de escala. Talvez isso aconteça e, em seguida, o stateless e o sharding completo, dependendo das necessidades e da avaliação do que está acontecendo e das ameaças envolvidas. Acho que o pensamento geral sobre o crescimento do estado é que devemos ter um caminho e devemos consertá-lo, mas [que] os incêndios iminentes foram apagados e que isso não é algo que prejudicará o Ethereum nos próximos dois anos. Mas é uma coisa que deve ser corrigida.

Acompanhe-me pelas atualizações que nós do saber para depois da fusão. Haverá uma atualização de limpeza? Isso é separado da atualização de Xangai? E quando o sharding é introduzido?

Shanghai provavelmente será o nome de qualquer que seja o fork após a fusão. Para realmente retirar seus fundos que você está apostando há quase dois anos - [isso] não é ativado na fusão. Inicialmente, esperava-se que eles fossem feitos, mas, dada a complexidade do Merge, ao longo do tempo, foi decidido realmente reduzi-lo e apenas fazer o Merge e não adicionar a funcionalidade extra de retiradas. Eu esperaria muito, muito, muito, que as retiradas fossem habilitadas em Xangai - então, a primeira atualização após a fusão. Isso foi prometido a muitas, muitas pessoas que têm muito capital em jogo e não espero nenhum problema com isso. Estes são geralmente especificados, há testes escritos e esse tipo de coisa. 

Há uma série de outras melhorias EVM [Ethereum Virtual Machine] que eu acho que entrariam neste sistema – diferentes operações matemáticas, algumas coisas de extensibilidade diferentes, um pouco melhor de versão dentro do EVM e outros recursos. É um pouco uma válvula de liberação de pressão nas melhorias do EVM, que foram colocadas de lado há vários anos para fazer o Merge e outras atualizações. E as pessoas realmente querem ver algum tipo de atualização de escalabilidade menor aqui. Portanto, pode ser proto-danksharding, que estabelece algumas das bases para o sharding completo e ganha um pouco mais de escala, ou potencialmente reduções de preço de gás de calldata, que são muito fáceis, mas não são realmente uma solução sustentável. Então é isso que esperamos, esperançosamente, em Xangai: retiradas e um pouco de escala.

Então a pergunta é: O que vem depois disso? E isso é difícil de dizer. Se conseguirmos um pouco de escala lá, e está complementando muito bem os L2s e as coisas estão muito boas, então talvez haja uma demanda para fazer stateless nesse ponto. Ou se os L2s têm uma necessidade insaciável de mais escala, talvez isso prepare o cenário para o danksharding completo.

Esta entrevista foi editada e condensada. 

Postado em julho 27, 2022