Co-fundador do Ethereum Vitalik Buterin Acredita que a resiliência e escalabilidade de longo prazo da blockchain dependem de simplificar, como o Bitcoin. Em um blog publicar Em 3 de maio, ele descreveu como “a Ethereum daqui a 5 anos pode se tornar tão simples quanto o Bitcoin”. Buterin escreveu:
“Uma das melhores coisas sobre o Bitcoin é o quão lindamente simples o protocolo é.”
Segundo Buterin, o design e a simplicidade minimalistas do Bitcoin o tornam acessível, para que mesmo um aluno do ensino médio possa entender o conceito e a arquitetura do protocolo. A simplicidade, argumentou Buterin, também traz outros benefícios, como reduzir o custo de criar uma nova infraestrutura e manutenção da infraestrutura existente, além de reduzir o risco de bugs.
Atualizações recentes, como a integração de Prova de Estaca (POS) e Conhecimento Zero, sucinto argumento não interativo do conhecimento (ZK-Snark), tornou o Ethereum mais robusto. No entanto, negligenciar a simplicidade do design aumentou os custos do Ethereum. Buterin explicou:
“Historicamente, o Ethereum muitas vezes não faz isso (às vezes por causa de minhas próprias decisões), e isso contribuiu para grande parte de nossas despesas excessivas de desenvolvimento, todos os tipos de risco de segurança e insularidade da cultura de P&D, geralmente em busca de benefícios que se mostraram ilusórios”.
Simplificação da camada de consenso do Ethereum
Em novembro, o pesquisador da Fundação Ethereum, Justin Drake proposto Uma atualização da camada de consenso chamada ‘Cadeia de feixe’. Buterin acredita que a cadeia de feixe está “bem posicionada para ser muito mais simples” do que seu antecessor desatualizado, a atual cadeia de faróis.
Isso ocorre porque a cadeia do feixe permitirá o redesenho da finalidade de 3 slots, o que eliminará conceitos complexos, como slots separados, épocas e comitês de sincronização, observou Buterin. Ele também destacou que uma implementação básica da finalidade de 3 slots pode ser alcançada através de cerca de 200 linhas de código, tornando-a muito mais simples.
A cadeia do feixe também reduzirá o número de validadores ativos por vez, o que tornaria “mais seguro usar implementações mais simples da regra da escolha do garfo”, escreveu Buterin.
A cadeia de feixe também incorporará protocolos de agregação baseados em Stark, o que significa que qualquer um pode ser um agregador. Buterin observou:
“A complexidade da criptografia de agregação em si é significativa, mas é pelo menos uma complexidade altamente encapsulada, que tem um risco sistêmico muito menor em relação ao protocolo”.
Buterin acrescentou que a redução de validadores ativos e a incorporação de agregadores baseados em Stark “provavelmente permitirão uma arquitetura P2P mais simples e mais robusta”. Ele continuou dizendo que há uma oportunidade de repensar e simplificar várias facetas, desde a entrada e saída do validador até o vazamento de inatividade. E isso pode ser alcançado, reduzindo a contagem de linha de código (LOC) e criando “mais garantias mais legíveis”.
Buterin destacou que a camada de consenso está “relativamente desconectada” das execuções do Ethereum Virtual Machine (EVM), que fornece uma “latitude relativamente ampla” para fazer melhorias em comparação com a camada de execução.
Simplificação da camada de execução do Ethereum
No mês passado, Buterin proposto Substituindo a linguagem do contrato EVM pelo RISC-V para aumentar a eficiência em até 100x. Buterin argumentou que a adoção do RISC-V também aumentará a simplicidade, uma vez que a “especificação RISC-V é absurdamente simples em comparação com o EVM”.
No entanto, isso significaria garantir que a compatibilidade com versões anteriores para aplicações existentes seja preservada. Buterin escreveu:
“A primeira coisa que é importante a entender é: não há uma única maneira de delinear o que é a” base de código Ethereum “(mesmo dentro de um único cliente).”
Segundo Buterin, a área laranja não pode ser diminuída. O objetivo, afirmou Buterin, é minimizar a área verde, movendo o código para a área amarela, que indica “o código muito valioso para entender e interpretar a cadeia hoje, ou para a construção ideal de blocos, mas não faz parte do consenso”. Buterin comparou esse processo à maneira como a Apple alcança a compatibilidade com antecedência a longo prazo através de camadas de tradução. Ele escreveu:
“É importante ressaltar que as áreas laranja e amarelo são complexidade encapsulada, qualquer pessoa que queira entender que o protocolo pode ignorá -las, as implementações do Ethereum são livres para pular e quaisquer bugs nessas áreas não representam riscos de consenso”.
É por isso que a complexidade do código nas áreas laranja e amarela tem “muito menos desvantagens” em comparação com a complexidade do código na área verde.
Para reduzir a área verde, Buterin propôs as seguintes etapas:
Fase 1: Novos pré-compilos serão escritos no RISC-V.
Fase 2: Os desenvolvedores terão a opção de escrever contratos no RISC-V.
Fase 3: Todos os pré-compilantes serão substituídos por implementações RISC-V através de um garfo duro.
Fase 4: Implemente um intérprete de EVM no RISC-V e pressione-o como um contrato inteligente.
As etapas acima garantiriam que o consenso do Ethereum “entendesse apenas o RISC-V, afirmou Buterin.
Padrões em todo o protocolo para simplificação
Buterin propôs compartilhar “um padrão em diferentes partes da pilha” como um caminho para a simplificação.
Por exemplo, Buterin sugeriu o uso de um único código de apagamento para amostragem de disponibilidade de dados, transmissão P2P e armazenamento de histórico distribuído. Isso minimizaria o total de linhas de código, aumentaria a eficiência e garantiria a verificabilidade, argumentou.
Da mesma forma, ele propôs ter um único formato de serialização compartilhada nas três camadas do Ethereum: camada de execução, camada de consenso e interface binária de aplicativos de chamada de contrato inteligente (ABI). Buterin sugeriu usar o SSZ, que é fácil de decodificar e amplamente usado.
Por fim, uma vez que o EVM foi substituído por RISC-V ou outro idioma simples, Buterin propõe mudar para uma árvore binária da árvore hexarada Merkle Patricia, tanto para as camadas de consenso quanto de execução. Essa transição pode melhorar a eficiência e reduzir os custos, garantindo que todas as camadas do Ethereum possam ser acessadas e interpretadas usando o mesmo código, escreveu Buterin.
Uma mudança no ethos
Buterin concluiu propondo que o Ethereum, seguindo o exemplo de Tinygrad, adote uma linha máxima explícita de destino de código. O objetivo, Buterin reiterou, é tornar o “código crítico de consenso do Ethereum próximo a Bitcoin”.
Mais importante, porém, o Ethereum precisa adotar um ethos onde a opção mais simples é escolhida sempre que possível. Isso significaria favorecer a complexidade encapsulada em relação à complexidade sistêmica.
Buterin tranquilizou esse código que lida com o processamento das regras históricas do Ethereum continuará a existir com sua última proposta. No entanto, esse código deve ser mantido fora do código crítico de consenso ou da área verde.
