A evolução do protocolo Ethereum através de downgrade: a estratégia de simplificação de Vitalik Buterin

Em 18 de janeiro, Vitalik Buterin publicou uma mensagem na plataforma X apresentando uma questão central sobre o protocolo Ethereum. A argumentação é que, por mais que um design tecnicamente avançado seja desejável, a complexidade excessiva pode comprometer os princípios fundamentais de confiabilidade, autonomia e segurança. Essa declaração, reportada pela PANews, levanta questões importantes sobre a direção de desenvolvimento do Ethereum.

A complexidade do protocolo Ethereum: por que é necessário simplificar?

Vitalik Buterin destacou que “falta de confiança”, “omissão de testes” e “auto-soberania” são três características essenciais do protocolo. No entanto, atualmente, o Ethereum enfrenta dificuldades em manter esses princípios básicos.

Com dezenas de milhares de nós operando, uma taxa de tolerância a falhas bizantinas de 49%, e todos os nós verificando via tecnologias de criptografia resistentes a computação quântica como PeerDiver e Stark, o problema reside na complexidade. Uma estrutura composta por dezenas de milhares de linhas de código e criptografia de nível doutoral, se altamente complexa, inevitavelmente falhará nos testes de confiabilidade.

A dependência de um pequeno grupo de especialistas para os usuários é uma ameaça a um sistema verdadeiramente trustless. Além disso, há a questão do “teste de troca de equipe”, onde a substituição do time de desenvolvimento principal pode dificultar a manutenção de uma qualidade equivalente. Mesmo os melhores desenvolvedores não conseguem compreender e gerenciar completamente uma estrutura excessivamente complexa.

O ciclo vicioso do aumento de complexidade do protocolo: adicionar vs modificar

O problema mais fundamental no desenvolvimento do Ethereum é gerado pelo processo de adição de funcionalidades. Para atender a requisitos específicos, novas funções são rapidamente incorporadas, o que torna o protocolo cada vez mais complexo, adicionando novos elementos de interação ou tecnologias criptográficas avançadas como dependências centrais.

Embora essa abordagem possa ajudar na expansão de funcionalidades a curto prazo, a longo prazo ela prejudica a autonomia e impede a construção de uma estrutura verdadeiramente descentralizada que possa durar séculos. A questão central é que, devido ao desejo de manter compatibilidade retroativa, há muito mais adições do que modificações no código. Com o tempo, o protocolo inevitavelmente se tornará mais pesado.

Três estratégias de coleta de lixo (garbage collection)

Vitalik propôs que, para resolver esse problema, o processo de desenvolvimento do Ethereum deve incorporar uma funcionalidade clara de “simplificação” ou “coleta de lixo”.

Três critérios para simplificação:

Primeiro, minimizar o número total de linhas de código do protocolo. Segundo, eliminar dependências desnecessárias de componentes tecnicamente complexos. Terceiro, acrescentar mais atributos imutáveis para definir claramente as propriedades confiáveis do protocolo.

Por exemplo, a EIP-6780 removeu a funcionalidade de auto-destruição e limitou a alteração de até N slots de armazenamento por bloco, simplificando significativamente o desenvolvimento do cliente.

A coleta de lixo pode ocorrer de duas formas:

Uma abordagem parcial consiste em redesenhar funcionalidades existentes de forma concisa e lógica. Um exemplo de abordagem mais abrangente é a atualização “The Merge”, que substituiu completamente a prova de trabalho (PoW) pela prova de participação (PoS).

Gerenciamento de compatibilidade com versões antigas via downgrade

Uma abordagem mais inovadora é a “compatibilidade descendente no estilo Zcash”. Nesse método, funcionalidades complexas, mas pouco utilizadas, são removidas do núcleo do protocolo e degradadas para código de contratos inteligentes. Assim, os novos desenvolvedores de clientes não precisam lidar diretamente com essas funcionalidades.

Na prática, após uma atualização completa com a abstração de contas nativas, por exemplo, todos os tipos de transações existentes podem deixar de ser considerados funcionalidades essenciais. Os códigos pré-compilados podem ser degradados para código EVM ou RISC-V, e, eventualmente, o próprio máquina virtual pode ser alterada de EVM para RISC-V.

A essência dessa estratégia de downgrade é eliminar a complexidade enquanto mantém a compatibilidade com funcionalidades existentes. O objetivo final é que os desenvolvedores de clientes não precisem mais lidar com códigos legados de versões antigas do Ethereum.

Recomendações para a sustentabilidade de longo prazo do Ethereum

A declaração de Vitalik Buterin nesta semana vai além de uma crítica técnica, sendo uma questão crucial para o futuro do Ethereum. É necessário desacelerar o ritmo de mudanças e evitar que complexidades desnecessárias prejudiquem o progresso do protocolo.

Através de uma verdadeira redução de funcionalidades e coleta de lixo, o Ethereum pode evoluir para um protocolo mais simples, transparente e confiável. Essa abordagem também reflete esforços de incorporar valores de imutabilidade e simplicidade, que o Bitcoin sempre buscou. O quanto a simplificação e o downgrade serão ativamente refletidos no roteiro de desenvolvimento do Ethereum terá um papel importante na realização de uma verdadeira descentralização e autonomia na blockchain.