Recentemente, um post de Vitalik Buterin no X tem causado bastante repercussão. Ele destacou que, para a sobrevivência a longo prazo de protocolos de blockchain como o Ethereum, é necessário revisar fundamentalmente a direção atual de desenvolvimento. Em particular, ele enfatizou que a simplicidade do protocolo é tão importante quanto “não confiabilidade”, “omissão de testes” e “auto-soberania”, aspectos que até agora têm sido subestimados.
Protocolos complexos destroem a confiança
Vitalik apresentou uma hipótese interessante. Mesmo que um protocolo tenha dezenas de milhares de nós, uma tolerância a falhas bizantinas de 49% e todos os nós sejam resistentes à computação quântica, se houver uma falha fatal, tudo se torna inútil. Isso porque o protocolo é uma estrutura enorme e caótica, misturando dezenas de milhares de linhas de código com criptografia de nível de doutorado.
Nesses casos, o protocolo inevitavelmente enfrentará testes de confiabilidade. Os usuários precisam confiar cegamente em um pequeno grupo de especialistas para entender as propriedades do protocolo. Além disso, se a equipe de desenvolvimento original sair, uma nova equipe terá dificuldade em manter a mesma qualidade, falhando no que Vitalik chama de “teste de troca de equipe”. Por mais inteligente que um desenvolvedor seja, ele não consegue inspecionar ou entender completamente esse sistema complexo.
Problemas de adição indiscriminada de funcionalidades no desenvolvimento do Ethereum
O problema fundamental apontado por Vitalik é a tendência de adicionar novas funcionalidades muito rapidamente para atender a requisitos específicos no desenvolvimento do protocolo Ethereum. Cada adição torna o protocolo mais complexo, incorporando novos componentes de interação ou avançadas tecnologias de criptografia como dependências centrais.
No curto prazo, isso permite oferecer funcionalidades desejadas pelos usuários rapidamente. Mas, a longo prazo, causa efeitos colaterais graves. Torna-se cada vez mais difícil construir uma estrutura verdadeiramente descentralizada que transcenda impérios e ideologias. Partes do protocolo, especialmente aquelas altamente interligadas, tornam-se pontos fracos que podem levar ao colapso do sistema como um todo.
A armadilha da compatibilidade retroativa: por que só “adicionar” continua
Se avaliarmos as mudanças no protocolo apenas pelo critério de “quanto modificamos o protocolo existente”, naturalmente surge o desejo de manter compatibilidade retroativa. Como resultado, há muito mais adições do que modificações, e com o tempo, o protocolo inevitavelmente se torna mais pesado. Essa é a questão estrutural que o Ethereum enfrenta hoje.
Vitalik defende que, para quebrar esse ciclo vicioso, o processo de desenvolvimento do Ethereum deve incorporar claramente uma função de “simplificação” ou “coleta de lixo” (garbage collection).
Três critérios para simplificação do protocolo
A estratégia de simplificação proposta por Vitalik inclui três critérios principais.
Primeiro, minimizar o número total de linhas de código do protocolo. Menos código significa manutenção mais fácil, auditorias mais rápidas e menor probabilidade de bugs.
Segundo, eliminar dependências desnecessárias de componentes tecnicamente complexos. Nem todas as tecnologias avançadas são necessárias, e às vezes abordagens simples podem ser mais robustas.
Terceiro, adicionar mais atributos imutáveis. Por exemplo, o EIP-6780 removeu a funcionalidade de auto-destruição (SELFDESTRUCT), o que levou à adição de uma propriedade que limita a alteração de até N slots de armazenamento por bloco, simplificando significativamente o desenvolvimento de clientes. Incorporar regras claras ao protocolo pode reduzir drasticamente a complexidade.
Estratégia de coleta de lixo: abordagem parcial e limpeza em grande escala
A coleta de lixo pode ser feita de duas formas.
Abordagem parcial consiste em redesenhar funcionalidades existentes para torná-las mais simples e lógicas. Pequenas limpezas graduais reduzem a complexidade ao longo do tempo.
Coleta de lixo em grande escala implica mudanças radicais. Um exemplo clássico é a transição do proof-of-work (PoW) para proof-of-stake (PoS). Essa mudança simplificou a estrutura do protocolo e reduziu drasticamente o consumo de energia.
Compatibilidade no estilo Rosetta: consideração para futuros desenvolvedores
A abordagem mais inovadora de Vitalik é a “compatibilidade no estilo Rosetta”. Nesse método, funcionalidades complexas e pouco usadas são removidas do núcleo do protocolo, mas mantidas por meio de “downgrade” no código de contratos inteligentes, garantindo compatibilidade retroativa.
Por exemplo, após uma atualização completa para uma abstração de contas nativa, não será mais necessário manter todos os tipos de transações como funcionalidades essenciais, pois os usuários podem implementá-las via contratos inteligentes. Da mesma forma, códigos pré-compilados podem ser substituídos por novas formas, como EVM ou RISC-V. No futuro, toda a máquina virtual pode migrar do EVM para RISC-V.
Assim, novos desenvolvedores de clientes não precisarão lidar com versões antigas do protocolo Ethereum uma a uma.
Visão de longo prazo: mudanças lentas, fundamentos mais fortes
Por fim, a proposta de Vitalik visa desacelerar a velocidade de mudança do Ethereum a longo prazo. Controlar o desejo de adicionar funcionalidades rapidamente e evitar que complexidades desnecessárias prejudiquem o desenvolvimento do protocolo.
Essa é uma condição essencial para que o Ethereum se torne uma infraestrutura verdadeiramente descentralizada. Quanto mais complexo, mais difícil de entender, mais provável que acabe centralizado por poucos especialistas. A simplicidade é, portanto, a base da verdadeira autonomia e confiança, e esse insight de Vitalik deve ser profundamente discutido na comunidade Ethereum.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Vitalic Buterin alerta para a crise de expansão do protocolo Ethereum: simplificação e coleta de lixo são essenciais
Recentemente, um post de Vitalik Buterin no X tem causado bastante repercussão. Ele destacou que, para a sobrevivência a longo prazo de protocolos de blockchain como o Ethereum, é necessário revisar fundamentalmente a direção atual de desenvolvimento. Em particular, ele enfatizou que a simplicidade do protocolo é tão importante quanto “não confiabilidade”, “omissão de testes” e “auto-soberania”, aspectos que até agora têm sido subestimados.
Protocolos complexos destroem a confiança
Vitalik apresentou uma hipótese interessante. Mesmo que um protocolo tenha dezenas de milhares de nós, uma tolerância a falhas bizantinas de 49% e todos os nós sejam resistentes à computação quântica, se houver uma falha fatal, tudo se torna inútil. Isso porque o protocolo é uma estrutura enorme e caótica, misturando dezenas de milhares de linhas de código com criptografia de nível de doutorado.
Nesses casos, o protocolo inevitavelmente enfrentará testes de confiabilidade. Os usuários precisam confiar cegamente em um pequeno grupo de especialistas para entender as propriedades do protocolo. Além disso, se a equipe de desenvolvimento original sair, uma nova equipe terá dificuldade em manter a mesma qualidade, falhando no que Vitalik chama de “teste de troca de equipe”. Por mais inteligente que um desenvolvedor seja, ele não consegue inspecionar ou entender completamente esse sistema complexo.
Problemas de adição indiscriminada de funcionalidades no desenvolvimento do Ethereum
O problema fundamental apontado por Vitalik é a tendência de adicionar novas funcionalidades muito rapidamente para atender a requisitos específicos no desenvolvimento do protocolo Ethereum. Cada adição torna o protocolo mais complexo, incorporando novos componentes de interação ou avançadas tecnologias de criptografia como dependências centrais.
No curto prazo, isso permite oferecer funcionalidades desejadas pelos usuários rapidamente. Mas, a longo prazo, causa efeitos colaterais graves. Torna-se cada vez mais difícil construir uma estrutura verdadeiramente descentralizada que transcenda impérios e ideologias. Partes do protocolo, especialmente aquelas altamente interligadas, tornam-se pontos fracos que podem levar ao colapso do sistema como um todo.
A armadilha da compatibilidade retroativa: por que só “adicionar” continua
Se avaliarmos as mudanças no protocolo apenas pelo critério de “quanto modificamos o protocolo existente”, naturalmente surge o desejo de manter compatibilidade retroativa. Como resultado, há muito mais adições do que modificações, e com o tempo, o protocolo inevitavelmente se torna mais pesado. Essa é a questão estrutural que o Ethereum enfrenta hoje.
Vitalik defende que, para quebrar esse ciclo vicioso, o processo de desenvolvimento do Ethereum deve incorporar claramente uma função de “simplificação” ou “coleta de lixo” (garbage collection).
Três critérios para simplificação do protocolo
A estratégia de simplificação proposta por Vitalik inclui três critérios principais.
Primeiro, minimizar o número total de linhas de código do protocolo. Menos código significa manutenção mais fácil, auditorias mais rápidas e menor probabilidade de bugs.
Segundo, eliminar dependências desnecessárias de componentes tecnicamente complexos. Nem todas as tecnologias avançadas são necessárias, e às vezes abordagens simples podem ser mais robustas.
Terceiro, adicionar mais atributos imutáveis. Por exemplo, o EIP-6780 removeu a funcionalidade de auto-destruição (SELFDESTRUCT), o que levou à adição de uma propriedade que limita a alteração de até N slots de armazenamento por bloco, simplificando significativamente o desenvolvimento de clientes. Incorporar regras claras ao protocolo pode reduzir drasticamente a complexidade.
Estratégia de coleta de lixo: abordagem parcial e limpeza em grande escala
A coleta de lixo pode ser feita de duas formas.
Abordagem parcial consiste em redesenhar funcionalidades existentes para torná-las mais simples e lógicas. Pequenas limpezas graduais reduzem a complexidade ao longo do tempo.
Coleta de lixo em grande escala implica mudanças radicais. Um exemplo clássico é a transição do proof-of-work (PoW) para proof-of-stake (PoS). Essa mudança simplificou a estrutura do protocolo e reduziu drasticamente o consumo de energia.
Compatibilidade no estilo Rosetta: consideração para futuros desenvolvedores
A abordagem mais inovadora de Vitalik é a “compatibilidade no estilo Rosetta”. Nesse método, funcionalidades complexas e pouco usadas são removidas do núcleo do protocolo, mas mantidas por meio de “downgrade” no código de contratos inteligentes, garantindo compatibilidade retroativa.
Por exemplo, após uma atualização completa para uma abstração de contas nativa, não será mais necessário manter todos os tipos de transações como funcionalidades essenciais, pois os usuários podem implementá-las via contratos inteligentes. Da mesma forma, códigos pré-compilados podem ser substituídos por novas formas, como EVM ou RISC-V. No futuro, toda a máquina virtual pode migrar do EVM para RISC-V.
Assim, novos desenvolvedores de clientes não precisarão lidar com versões antigas do protocolo Ethereum uma a uma.
Visão de longo prazo: mudanças lentas, fundamentos mais fortes
Por fim, a proposta de Vitalik visa desacelerar a velocidade de mudança do Ethereum a longo prazo. Controlar o desejo de adicionar funcionalidades rapidamente e evitar que complexidades desnecessárias prejudiquem o desenvolvimento do protocolo.
Essa é uma condição essencial para que o Ethereum se torne uma infraestrutura verdadeiramente descentralizada. Quanto mais complexo, mais difícil de entender, mais provável que acabe centralizado por poucos especialistas. A simplicidade é, portanto, a base da verdadeira autonomia e confiança, e esse insight de Vitalik deve ser profundamente discutido na comunidade Ethereum.