- Tópico
116k Popularidade
26k Popularidade
7k Popularidade
29k Popularidade
17k Popularidade
23k Popularidade
14k Popularidade
3k Popularidade
14k Popularidade
155k Popularidade
- Pino
116k Popularidade
26k Popularidade
7k Popularidade
29k Popularidade
17k Popularidade
23k Popularidade
14k Popularidade
3k Popularidade
14k Popularidade
155k Popularidade
Ethereum futuro desenvolvimento: The Purge visa simplificar o protocolo Gota a necessidade de armazenamento.
O possível futuro do Ethereum: The Purge
Desde 14 de outubro, o fundador do Ethereum, Vitalik Buterin, publicou uma série de artigos de discussão sobre o futuro desenvolvimento do Ethereum, desde "The Merge" até ao mais recente "The Purge", mostrando a sua visão para o desenvolvimento futuro da mainnet do Ethereum e as soluções para os problemas atuais.
O artigo "The Purge" explora como o Ethereum pode reduzir a complexidade e a necessidade de armazenamento a longo prazo, mantendo a persistência e a descentralização da cadeia. As principais medidas incluem a redução da carga de armazenamento dos clientes através de "expiração histórica" e "expiração de estado", e a simplificação do protocolo através da "limpeza de características", para garantir a sustentabilidade e escalabilidade da rede.
Expiração do histórico
Resolve que problema?
Atualmente, um nó Ethereum completamente sincronizado requer cerca de 1,1 TB de espaço em disco para executar o cliente, além de precisar de várias centenas de GB para o cliente de consenso. A maior parte é dados históricos; mesmo que o limite de Gas permaneça o mesmo, o tamanho do nó aumentará centenas de GB a cada ano.
O que é, como funciona?
Uma característica chave do armazenamento histórico é que o consenso atual é suficiente para alcançar consenso sobre o histórico. Isso oferece várias opções para o armazenamento de registros históricos, como redes onde cada nó armazena apenas parte dos dados.
Ethereum já começou a se desvincular do modelo de armazenamento permanente de todo o histórico em todos os nós. Os blocos de consenso armazenam apenas cerca de 6 meses, enquanto os Blobs armazenam apenas cerca de 18 dias. O EIP-4444 visa introduzir um período de armazenamento de um ano para os blocos históricos e recibos. O objetivo a longo prazo é estabelecer um período de armazenamento unificado de cerca de 18 dias e, em seguida, criar uma rede P2P composta por nós do Ethereum para armazenar dados antigos de forma distribuída.
Os códigos de apagamento podem ser usados para aumentar a robustez, mantendo o mesmo fator de replicação. A solução mais simples pode ser reutilizar os códigos de apagamento existentes do Blob e colocar a execução e os dados do bloco de consenso também dentro do blob.
O que mais precisa ser feito, o que precisa ser ponderado?
O trabalho principal inclui a construção e integração de uma solução distribuída específica para armazenar o histórico. A solução mais simples é a introdução de uma biblioteca de torrents existente ou a solução nativa do Ethereum conhecida como Portal Network.
As principais ponderações envolvem como se esforçar para fornecer dados históricos "antigos". A solução mais simples é parar imediatamente de armazenar dados históricos antigos, dependendo dos nós de arquivamento existentes. A solução mais segura, mas mais difícil, é primeiro construir e integrar uma rede torrent.
com a interação com outras partes do roteiro
Reduzir a necessidade de armazenamento histórico é crucial para tornar a execução de nós extremamente fácil. Somente alcançando a sem estado e o EIP-4444 é que se poderá realizar a visão de executar um nó Ethereum em um smartwatch.
A limitação do armazenamento histórico também torna mais viável a implementação de novos nós Ethereum que suportam apenas a versão mais recente do protocolo, simplificando assim o cliente.
State expiry estado de expiração
Resolve que problema?
Mesmo que a necessidade de armazenamento do histórico seja eliminada, a demanda de armazenamento do cliente continuará a aumentar em cerca de 50 GB por ano, pois o saldo da conta do estado (, o código do contrato, etc. ) continuarão a crescer. Os usuários podem pagar uma única vez, trazendo um ônus permanente para os clientes atuais e futuros.
O que é isso, como funciona?
O estado é mais difícil de "expirar" do que o histórico, porque a EVM assume que os objetos de estado existem para sempre uma vez criados. O objetivo é permitir que os objetos expirem automaticamente ao longo do tempo, mantendo a eficiência, a facilidade de uso e a facilidade para os desenvolvedores.
Existem principalmente duas categorias de soluções:
Parte do estado expira: o estado é dividido em blocos, armazenando apenas os dados mais recentemente acessados. A EIP-7736 propõe uma solução baseada em árvores Verkle, onde os dados que não foram acessados por 6 meses armazenam apenas 32 bytes de raiz.
Expiração de estado com base no ciclo de endereços: utiliza uma lista de árvores de estado em constante crescimento, adicionando novas árvores vazias a cada ano. Nós completos mantêm apenas as duas árvores mais recentes. Dados expirados precisam de prova para serem lidos ou escritos.
O que mais precisa ser feito, o que precisa ser ponderado?
Caminhos potenciais para o futuro incluem:
Implementar sem estado, não introduzir o estado de expiração. O estado continua a crescer, mas apenas exige armazenamento de usuários especiais.
Implementar uma parte do estado que expira, aceitando uma taxa de crescimento permanente mais baixa, mas não zero.
Implementar a expiração do estado através da expansão do espaço de endereços. É necessário um processo de anos para garantir que a conversão de formato de endereço seja segura e eficaz.
Através da contração do espaço de endereços para implementar a expiração do estado. É necessário um processo de vários anos para garantir a resolução de todos os riscos de segurança.
Independentemente da solução adotada, é necessário resolver o problema da expansão e contração do espaço de endereços, pois ataques de colisão de endereços se tornarão mais fáceis no futuro.
Limpeza de características
Resolve que problema?
A simplicidade do protocolo é a chave para a segurança, acessibilidade e neutralidade confiável. Mas os protocolos tendem a se tornar mais complexos ao longo do tempo. Precisamos ser capazes de remover funcionalidades e reduzir a complexidade.
O que é, como funciona?
Não há uma única correção significativa que possa reduzir a complexidade do protocolo, mas sim a necessidade de várias pequenas soluções. Alguns exemplos chave incluem:
Exemplos no EVM:
O que mais precisa ser feito, o que precisa ser ponderado?
A principal consideração é o nível de simplificação e velocidade em relação à compatibilidade retroativa. É necessário criar um processo padronizado para realizar alterações que quebrem a compatibilidade retroativa de forma não urgente, incluindo etapas como análise de impacto, descontinuação formal do EIP, exclusão final, entre outras.
O formato do objeto EVM ( EOF ) propôs uma série de alterações ao EVM, com o objetivo de permitir mais atualizações. É necessário pesar a complexidade aumentada contra o objetivo de simplificar todo o EVM.
Uma abordagem mais radical é transformar a maior parte do conteúdo do protocolo em código de contrato, como transformar o EVM em um resumo ou substituir o EVM por uma nova VM. Isso pode simplificar bastante o protocolo, mas exige uma consideração sobre a compatibilidade.