Publicado: 01 de abril de 2024 às 7h44 Atualizado: 01 de abril de 2024 às 7h48
Editado e verificado: 01 de abril de 2024 às 7h44
em resumo
Vitalik Buterin lançou diretrizes “Purge” descrevendo etapas para agilizar o protocolo Ethereum e aliviar a carga nos recursos do nó.
O cofundador do blockchain Ethereum, Vitalik Buterin, lançou diretrizes “Purge” descrevendo etapas para simplificar o protocolo Ethereum e aliviar a carga nos recursos do nó.
De acordo com o artigo do blog, durante o hard fork Ethereum Dencun, o EIP-6780 eliminou uma parte significativa da funcionalidade associada ao opcode SELFDESTRUCT. Esta ação teve como objetivo agilizar o protocolo, reduzindo a complexidade e introduzindo garantias adicionais de segurança. Vitalik Buterin identificou-o como um aspecto central do “Expurgo”.
Em relação a outros “Expurgos” em curso, Vitalik Buterin forneceu três exemplos. Isso inclui Geth, que recentemente interrompeu o suporte à rede de pré-fusão (PoW), removendo milhares de linhas de código. Além disso, o EIP-161 formaliza a eliminação de preocupações relativas a “contas vazias”, introduzidas como parte da abordagem ao ataque DoS de Xangai. Além disso, a implementação de uma janela de armazenamento de 18 dias para blobs em Dencun garante que os nós Ethereum precisarão de aproximadamente 50 GB para armazenar dados de blob, sem nenhum aumento previsto neste requisito ao longo do tempo.
Os dois pontos iniciais representam melhorias substanciais para os desenvolvedores de clientes, enquanto o último ponto significa uma melhoria notável para os operadores de nós.
Quatro áreas principais para melhoria: pré-compilações, EIP-4444, reforma do LOG e SSZ
Concentrando-se em outros aspectos que podem exigir “expurgação”, Vitalik Buterin listou pré-compilações, registro de histórico (EIP-4444), reforma de LOG e transição para Simple Serialize (SSZ).
De acordo com Vitalik Buterin, a demanda por pré-compilação parcial é menor do que o previsto, e as funções pré-compiladas representam uma fonte significativa de erros de consenso e desafios para novas implementações de Máquina Virtual Ethereum (EVM). No entanto, existem duas abordagens para resolver esse problema: apenas remover a pré-compilação, como visto no EIP-7266, que elimina o BLAKE2, e substituir a pré-compilação por um segmento de código EVM que executa a mesma operação.
Em relação ao histórico (EIP-4444), Vitalik Buterin destacou uma questão fundamental: se o histórico antigo não for armazenado por todos os nós, quais entidades irão armazená-lo? Ele observou que entidades de grande escala, como exploradores de blocos, são prováveis candidatas. No entanto, também é viável e não excessivamente complexo desenvolver protocolos peer-to-peer (P2P) para armazenar e distribuir esta informação, que podem ser mais adaptados à tarefa. Ele sugeriu ainda que a antiga rede de torrents P2P e os protocolos explicitamente otimizados para uso do Ethereum são opções viáveis.
Outro protocolo explicitamente otimizado para uso do Ethereum também está sendo considerado – o EIP-4444 tem o potencial de melhorar significativamente a descentralização dos nós do Ethereum.
Em relação à reforma do LOG, Vitalik Buterin sugeriu eliminar os filtros de bloom e simplificar o opcode do LOG para gerar apenas um valor com hash no estado. A próxima etapa envolveria o desenvolvimento de protocolos separados utilizando ZK-SNARKs e computação verificável incrementalmente (IVC) para criar ‘árvores de toras’ comprovadamente corretas. “Essas árvores de log funcionariam como uma tabela pesquisável contendo todos os logs de um determinado tópico, fornecendo aos aplicativos descentralizados que exigem logs a capacidade de utilizar esses protocolos separados”, disse ele no artigo.
Ele também observou que a transição do Ethereum para SSZ está em andamento e que a camada de execução precisa ser migrada para a mesma estrutura. Atualmente, três estruturas de dados criptografadas estão em uso, incluindo árvores binárias SHA256, listas de hash SHA3 RLP e árvores hexárias Patricia. Assim que a transição para SSZ for concluída, apenas duas árvores binárias SHA256 e árvores Verkle permanecerão.
Assim que a transição para SSZ for finalizada, o sistema ficará com apenas duas estruturas: árvores binárias SHA256 e árvores Verkle. À medida que os avanços são feitos nos “hashes SNARKing”, existe a possibilidade de substituir as árvores binárias SHA256 e as árvores Verkle por árvores Merkle binárias que utilizam um algoritmo de hash compatível com SNARKs.
Isenção de responsabilidade
De acordo com as diretrizes do Trust Project, observe que as informações fornecidas nesta página não se destinam e não devem ser interpretadas como aconselhamento jurídico, tributário, de investimento, financeiro ou qualquer outra forma. É importante investir apenas o que você pode perder e procurar aconselhamento financeiro independente se tiver alguma dúvida. Para mais informações, sugerimos consultar os termos e condições, bem como as páginas de ajuda e suporte fornecidas pelo emissor ou anunciante. MetaversePost está comprometido com relatórios precisos e imparciais, mas as condições de mercado estão sujeitas a alterações sem aviso prévio.
Sobre o autor
Alisa é repórter do Metaverse Post. Ela se concentra em investimentos, IA, metaverso e tudo relacionado à Web3. Alisa é formada em Negócios de Arte e tem experiência em Arte e Tecnologia. Ela desenvolveu sua paixão pelo jornalismo escrevendo para VCs, projetos criptográficos notáveis e redação científica. Você pode contatá-la em [email protected]
Mais artigos
Alice Davidson
Alisa é repórter do Metaverse Post. Ela se concentra em investimentos, IA, metaverso e tudo relacionado à Web3. Alisa é formada em Negócios de Arte e tem experiência em Arte e Tecnologia. Ela desenvolveu sua paixão pelo jornalismo escrevendo para VCs, projetos criptográficos notáveis e redação científica. Você pode contatá-la em [email protected]
Mais artigos
source – mpost.io
