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.
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.
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.