O cofundador do Ethereum, Vitalik Buterin, acredita que a resiliência e a escalabilidade a longo prazo da blockchain dependem de torná-la simples, assim como o Bitcoin. Em uma postagem no blog em 3 de maio, ele descreveu como "o Ethereum daqui a 5 anos pode se tornar quase tão simples quanto o Bitcoin". Buterin escreveu:
"Uma das coisas mais incríveis sobre o Bitcoin é que o protocolo é extremamente simples."
Segundo Buterin, o design minimalista e a simplicidade do Bitcoin tornam-no acessível, de modo que até mesmo um estudante do ensino médio pode compreender o conceito e a arquitetura do protocolo. Buterin argumenta que a simplicidade também traz outros benefícios, como a redução de custos na criação de nova infraestrutura e na manutenção da infraestrutura existente, assim como a diminuição do risco de erros.
As atualizações recentes, como a prova de participação (PoS) e a integração do Argumento de Conhecimento Não Interativo e Succinto de Zero Conhecimento (zk-SNARK), tornaram o Ethereum mais robusto. No entanto, a negligência da simplicidade do design aumentou ainda mais os custos do Ethereum. Buterin explicou:
"Antes, o Ethereum raramente fazia isso ( às vezes devido à minha própria decisão ) e isso contribuiu para muitos custos de desenvolvimento excessivos, todo tipo de risco de segurança e restrições na cultura de P&D, geralmente para perseguir benefícios que se mostraram ilusórios."
Simplificação da camada de consenso do Ethereum
Em novembro, o pesquisador Justin Drake da Ethereum Foundation propôs uma atualização da camada de consenso chamada 'Beam Chain'. Buterin acredita que a Beam Chain "tem uma boa posição para se tornar muito mais simples" em comparação com seu antecessor ultrapassado, a beacon chain atual.
Isto deve-se ao fato de que a cadeia de raios permitirá redesenhar a finalização de 3 slots, o que eliminará conceitos complexos como slots separados, eras e comitês de sincronização, observou Buterin. Ele também destacou que a implementação básica da finalização de 3 slots pode ser alcançada por meio de cerca de 200 linhas de código, simplificando muito.
A cadeia de feixes também reduzirá o número de validadores ativos de uma só vez, o que ajudará a "utilizar implementações mais simples da regra de seleção de ramificação mais segura", escreveu Buterin.
A cadeia de feixes também irá combinar protocolos de agregação baseados em STARK, o que significa que qualquer pessoa pode ser um agregador. Buterin observou:
"A própria complexidade da criptografia de combinação é considerável, mas pelo menos tem uma complexidade bem compacta, com muito menos risco sistêmico para o protocolo."
Buterin acrescentou que a redução do número de validadores ativos e a combinação de agregadores baseados em STARK "pode permitir uma arquitetura P2P mais simples e robusta". Ele continuou dizendo que há uma oportunidade de repensar e simplificar alguns aspectos, desde a entrada e saída dos validadores até vazamentos de inatividade. E isso pode ser alcançado reduzindo o número de linhas de código (LoC) e criando "garantias mais legíveis".
Buterin enfatizou que a camada de consenso está "relativamente separada" das atividades de execução da Máquina Virtual Ethereum (EVM), o que fornece "uma margem relativamente ampla" para implementar melhorias em relação à camada de execução.
Simplificar a camada de execução do Ethereum
No mês passado, Buterin propôs substituir a linguagem de contrato EVM por RISC-V para aumentar a eficiência em até 100 vezes. Buterin argumentou que a adoção do RISC-V também aumentaria a simplicidade, pois "a especificação RISC-V é absurdamente simples em comparação com EVM".
No entanto, isso significa garantir que a compatibilidade retroativa para as aplicações existentes seja mantida. Buterin escreveu:
"A primeira coisa importante a entender é: não há uma única maneira de definir o que é "base de código Ethereum" ( mesmo em um único cliente )."
Segundo Buterin, a área laranja não pode ser reduzida. Buterin afirmou que o objetivo é minimizar a área verde, movendo o código para a área amarela, dizendo "o código é muito valioso para entender e interpretar a cadeia hoje ou para construir um bloco otimizado, mas não faz parte do consenso". Buterin comparou esse processo à maneira como a Apple alcança compatibilidade retroativa a longo prazo através de camadas de compilação. Ele escreveu:
"O importante é que as áreas laranja e amarela são embaladas de forma complexa, qualquer um que queira entender o protocolo pode ignorá-las, a implementação do Ethereum pode ignorá-las e quaisquer erros nessas áreas não representam risco para o consenso."
Esta é a razão pela qual a complexidade do código na zona laranja e amarela tem "muito menos desvantagens" em comparação com a complexidade do código na zona verde.
Para reduzir a área de vegetação, Buterin propôs os seguintes passos:
Fase 1: Os novos programas de compilação serão escritos em RISC-V.
Fase 2: Os desenvolvedores terão a opção de escrever contratos usando RISC-V.
Fase 3: Todas as compilações anteriores serão substituídas por implementações RISC-V através de um hard fork.
Fase 4: Implantar o interpretador EVM no RISC-V e colocá-lo on-chain como um contrato inteligente.
Buterin declarou que os passos acima garantirão que o consenso do Ethereum entenderá "naturalmente" o RISC-V.
Padrão de protocolo para simplificação
Buterin propôs compartilhar "um padrão sobre as diferentes camadas da pilha" como um caminho para simplificar.
Por exemplo, Buterin propôs o uso de um código de exclusão única para amostrar dados disponíveis, transmitir P2P e armazenar um histórico distribuído. Isso minimizaria o número total de linhas de código, aumentaria a eficiência e garantiria a verificabilidade, argumentou ele.
Da mesma forma, ele propôs que houvesse um formato de serialização compartilhado único em três camadas do Ethereum: camada de execução, camada de consenso e um contrato inteligente chamado Interface Binária de Aplicação (ABI). Buterin propôs usar SSZ, que é fácil de decodificar e amplamente utilizado.
Finalmente, após o EVM ser substituído por RISC-V ou outra linguagem simples, Buterin propôs a transição de uma árvore Merkle Patricia hexária para uma árvore binária, tanto para a camada de consenso quanto para a camada de execução. Esta transição pode melhorar a eficiência e reduzir custos, enquanto ainda garante que todas as camadas do Ethereum possam ser acessadas e interpretadas pelo mesmo código, escreveu Buterin.
Uma mudança de personalidade
Buterin concluiu sugerindo que o Ethereum, seguindo o exemplo do Tinygrad, adota claramente o objetivo de um fluxo de código máximo. Buterin reiterou que o objetivo é tornar "o código importante para o consenso do Ethereum quase tão simples quanto o Bitcoin".
Mas, mais importante, o Ethereum precisa adotar um padrão onde opções mais simples sejam escolhidas sempre que possível. Isso significa priorizar a complexidade encapsulada em vez da complexidade sistêmica.
Buterin afirma que o código que processa as regras históricas do Ethereum continuará a existir com a sua mais recente proposta. No entanto, esse código deve ser mantido fora do código crítico do consenso ou da área verde.
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Vitalik Buterin quer tornar o Ethereum 'tão simples quanto o Bitcoin' até 2030
O cofundador do Ethereum, Vitalik Buterin, acredita que a resiliência e a escalabilidade a longo prazo da blockchain dependem de torná-la simples, assim como o Bitcoin. Em uma postagem no blog em 3 de maio, ele descreveu como "o Ethereum daqui a 5 anos pode se tornar quase tão simples quanto o Bitcoin". Buterin escreveu: "Uma das coisas mais incríveis sobre o Bitcoin é que o protocolo é extremamente simples." Segundo Buterin, o design minimalista e a simplicidade do Bitcoin tornam-no acessível, de modo que até mesmo um estudante do ensino médio pode compreender o conceito e a arquitetura do protocolo. Buterin argumenta que a simplicidade também traz outros benefícios, como a redução de custos na criação de nova infraestrutura e na manutenção da infraestrutura existente, assim como a diminuição do risco de erros. As atualizações recentes, como a prova de participação (PoS) e a integração do Argumento de Conhecimento Não Interativo e Succinto de Zero Conhecimento (zk-SNARK), tornaram o Ethereum mais robusto. No entanto, a negligência da simplicidade do design aumentou ainda mais os custos do Ethereum. Buterin explicou: "Antes, o Ethereum raramente fazia isso ( às vezes devido à minha própria decisão ) e isso contribuiu para muitos custos de desenvolvimento excessivos, todo tipo de risco de segurança e restrições na cultura de P&D, geralmente para perseguir benefícios que se mostraram ilusórios." Simplificação da camada de consenso do Ethereum Em novembro, o pesquisador Justin Drake da Ethereum Foundation propôs uma atualização da camada de consenso chamada 'Beam Chain'. Buterin acredita que a Beam Chain "tem uma boa posição para se tornar muito mais simples" em comparação com seu antecessor ultrapassado, a beacon chain atual. Isto deve-se ao fato de que a cadeia de raios permitirá redesenhar a finalização de 3 slots, o que eliminará conceitos complexos como slots separados, eras e comitês de sincronização, observou Buterin. Ele também destacou que a implementação básica da finalização de 3 slots pode ser alcançada por meio de cerca de 200 linhas de código, simplificando muito. A cadeia de feixes também reduzirá o número de validadores ativos de uma só vez, o que ajudará a "utilizar implementações mais simples da regra de seleção de ramificação mais segura", escreveu Buterin. A cadeia de feixes também irá combinar protocolos de agregação baseados em STARK, o que significa que qualquer pessoa pode ser um agregador. Buterin observou: "A própria complexidade da criptografia de combinação é considerável, mas pelo menos tem uma complexidade bem compacta, com muito menos risco sistêmico para o protocolo." Buterin acrescentou que a redução do número de validadores ativos e a combinação de agregadores baseados em STARK "pode permitir uma arquitetura P2P mais simples e robusta". Ele continuou dizendo que há uma oportunidade de repensar e simplificar alguns aspectos, desde a entrada e saída dos validadores até vazamentos de inatividade. E isso pode ser alcançado reduzindo o número de linhas de código (LoC) e criando "garantias mais legíveis". Buterin enfatizou que a camada de consenso está "relativamente separada" das atividades de execução da Máquina Virtual Ethereum (EVM), o que fornece "uma margem relativamente ampla" para implementar melhorias em relação à camada de execução. Simplificar a camada de execução do Ethereum No mês passado, Buterin propôs substituir a linguagem de contrato EVM por RISC-V para aumentar a eficiência em até 100 vezes. Buterin argumentou que a adoção do RISC-V também aumentaria a simplicidade, pois "a especificação RISC-V é absurdamente simples em comparação com EVM". No entanto, isso significa garantir que a compatibilidade retroativa para as aplicações existentes seja mantida. Buterin escreveu: "A primeira coisa importante a entender é: não há uma única maneira de definir o que é "base de código Ethereum" ( mesmo em um único cliente )." Segundo Buterin, a área laranja não pode ser reduzida. Buterin afirmou que o objetivo é minimizar a área verde, movendo o código para a área amarela, dizendo "o código é muito valioso para entender e interpretar a cadeia hoje ou para construir um bloco otimizado, mas não faz parte do consenso". Buterin comparou esse processo à maneira como a Apple alcança compatibilidade retroativa a longo prazo através de camadas de compilação. Ele escreveu: "O importante é que as áreas laranja e amarela são embaladas de forma complexa, qualquer um que queira entender o protocolo pode ignorá-las, a implementação do Ethereum pode ignorá-las e quaisquer erros nessas áreas não representam risco para o consenso." Esta é a razão pela qual a complexidade do código na zona laranja e amarela tem "muito menos desvantagens" em comparação com a complexidade do código na zona verde. Para reduzir a área de vegetação, Buterin propôs os seguintes passos: Fase 1: Os novos programas de compilação serão escritos em RISC-V. Fase 2: Os desenvolvedores terão a opção de escrever contratos usando RISC-V. Fase 3: Todas as compilações anteriores serão substituídas por implementações RISC-V através de um hard fork. Fase 4: Implantar o interpretador EVM no RISC-V e colocá-lo on-chain como um contrato inteligente. Buterin declarou que os passos acima garantirão que o consenso do Ethereum entenderá "naturalmente" o RISC-V. Padrão de protocolo para simplificação Buterin propôs compartilhar "um padrão sobre as diferentes camadas da pilha" como um caminho para simplificar. Por exemplo, Buterin propôs o uso de um código de exclusão única para amostrar dados disponíveis, transmitir P2P e armazenar um histórico distribuído. Isso minimizaria o número total de linhas de código, aumentaria a eficiência e garantiria a verificabilidade, argumentou ele. Da mesma forma, ele propôs que houvesse um formato de serialização compartilhado único em três camadas do Ethereum: camada de execução, camada de consenso e um contrato inteligente chamado Interface Binária de Aplicação (ABI). Buterin propôs usar SSZ, que é fácil de decodificar e amplamente utilizado. Finalmente, após o EVM ser substituído por RISC-V ou outra linguagem simples, Buterin propôs a transição de uma árvore Merkle Patricia hexária para uma árvore binária, tanto para a camada de consenso quanto para a camada de execução. Esta transição pode melhorar a eficiência e reduzir custos, enquanto ainda garante que todas as camadas do Ethereum possam ser acessadas e interpretadas pelo mesmo código, escreveu Buterin. Uma mudança de personalidade Buterin concluiu sugerindo que o Ethereum, seguindo o exemplo do Tinygrad, adota claramente o objetivo de um fluxo de código máximo. Buterin reiterou que o objetivo é tornar "o código importante para o consenso do Ethereum quase tão simples quanto o Bitcoin". Mas, mais importante, o Ethereum precisa adotar um padrão onde opções mais simples sejam escolhidas sempre que possível. Isso significa priorizar a complexidade encapsulada em vez da complexidade sistêmica. Buterin afirma que o código que processa as regras históricas do Ethereum continuará a existir com a sua mais recente proposta. No entanto, esse código deve ser mantido fora do código crítico do consenso ou da área verde.