Vitalik Buterin recentemente publicou uma série de artigos de discussão sobre o futuro do Ethereum, explorando desde a fusão, surto, chicotada, margem até a mais recente fase de purificação. Estes artigos mostram a visão de Vitalik sobre o futuro do mainnet do Ethereum e como resolver os problemas atuais que enfrenta.
O principal objetivo da fase de purificação é reduzir os requisitos de armazenamento do cliente, diminuindo ou eliminando a necessidade de cada nó armazenar permanentemente todos os registros históricos ou mesmo o estado final, e reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Histórico expirado
O histórico expirado visa resolver o problema de que os nós Ethereum totalmente sincronizados precisam de um grande espaço em disco. Atualmente, um cliente de execução requer cerca de 1,1 TB de espaço em disco, enquanto um cliente de consenso também precisa de centenas de GB. A maior parte disso é dados históricos de muitos anos atrás.
A chave para a expiração histórica é aproveitar as características do mecanismo de consenso; basta alcançar consenso sobre o bloco mais recente para validar a correção dos dados históricos. Isso oferece várias opções para armazenar registros históricos, como cada nó armazenar apenas uma parte dos dados.
Atualmente, o Ethereum começou a se desvincular gradualmente do modelo onde todos os nós armazenam permanentemente todo o histórico. Os blocos de consenso armazenam apenas cerca de 6 meses, enquanto os Blobs armazenam apenas cerca de 18 dias. O objetivo futuro é estabelecer um período de armazenamento unificado ( que pode ser de cerca de 18 dias ), e então armazenar dados antigos através de uma rede distribuída.
A implementação da expiração histórica ainda requer a construção e integração de soluções específicas de armazenamento distribuído, como a introdução de bibliotecas torrent existentes ou da rede Portal nativa do Ethereum. O principal compromisso está em como esforçar-se para fornecer dados históricos "antigos" e a profundidade da integração do armazenamento histórico no protocolo.
A expiração histórica é crucial para a operação e inicialização simplificadas dos nós, ajudando a realizar a visão de executar nós Ethereum em smartwatches. Isso também torna a implementação de nós Ethereum mais recente mais viável, suportando apenas a versão mais recente do protocolo.
Estado expirado
O estado expiração destina-se a resolver o problema de que, mesmo eliminando a necessidade de armazenar o histórico, a necessidade de armazenamento dos clientes continuará a crescer. Isso ocorre porque o saldo da conta do estado (, o número aleatório, o código do contrato e o armazenamento ) continuarão a crescer, e os usuários só precisam pagar uma taxa única para sobrecarregar permanentemente o armazenamento do cliente.
O estado expirado é mais difícil de ser alcançado do que o estado histórico expirado, pois o design do EVM assume que os objetos de estado, uma vez criados, existirão para sempre. Atualmente, existem duas principais soluções: expiração parcial do estado e expiração do estado baseada em ciclos de endereço.
Parte do estado expira, dividindo o estado em blocos, e apenas os dados acessados recentemente serão armazenados. O EIP-7736 é uma proposta concreta baseada no design de "folhas" introduzido para a árvore Verkle.
O design baseado no ciclo de endereços resolve o problema de conflito de ressurgimento através de uma lista de árvore de estado em constante crescimento. A cada período (, como 1 ano ), uma nova árvore de estado vazia é adicionada, e os nós completos armazenam apenas as duas árvores mais recentes.
O principal desafio da expiração de estado é a expansão ou contração do espaço de endereços, o que requer a resolução de problemas complexos de compatibilidade e segurança. Independentemente de a expiração de estado ser implementada ou não, a questão do espaço de endereços deve, em última análise, ser resolvida.
Limpeza de Funcionalidades
A limpeza de funcionalidades visa reduzir a complexidade do protocolo, melhorando a segurança, acessibilidade e neutralidade confiável. Os principais métodos incluem a remoção de funcionalidades desnecessárias, simplificação de mecanismos existentes e unificação de formatos de dados, entre outros.
Algumas oportunidades de simplificação específicas incluem:
Converter RLP para SSZ
Remover tipos de transação antigos
Reformar o mecanismo LOG
Remover o mecanismo de comissão de sincronização da cadeia de beacon
Formato de dados unificado
Remover o comitê da cadeia de beacon
Remover a mistura de endianness
Simplificação do mecanismo Gas
Remover pré-compilado
Remover a observabilidade do gas
Melhorar a análise estática
A principal consideração na simplificação de funcionalidades é o grau de simplificação e a velocidade em relação à compatibilidade retroativa. É necessário estabelecer um pipeline padronizado para realizar alterações que não sejam urgentes, que quebrem a compatibilidade retroativa, buscando um equilíbrio entre a remoção de características e a conservação.
O formato de objeto EVM ( EOF ) é um conjunto de principais alterações propostas para o EVM, destinado a permitir que o EVM seja atualizado de uma maneira com propriedades mais robustas. Sua vantagem é que cria um caminho natural para adicionar novas funcionalidades ao EVM, mas também aumenta significativamente a complexidade do protocolo.
Uma estratégia de simplificação mais radical é transformar a maior parte do conteúdo do protocolo em código de contrato, como transformar o L1 do Ethereum em apenas uma cadeia de beacon, introduzindo uma máquina virtual mínima que permite a criação de resumos. Ou realizar uma troca no local da EVM, escolhendo uma nova "EVM oficial do Ethereum".
De um modo geral, a fase de purificação visa reduzir a necessidade de armazenamento e a complexidade do protocolo através do expurgo de históricos, expurgo de estados e limpeza de funcionalidades, estabelecendo assim uma base para a escalabilidade e sustentabilidade a longo prazo do Ethereum. Isso requer buscar um equilíbrio entre simplificação e compatibilidade, e pode envolver transformações profundas no protocolo.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
9 gostos
Recompensa
9
7
Partilhar
Comentar
0/400
NFTragedy
· 11h atrás
Vender o antigo para poder avançar!
Ver originalResponder0
CryptoCross-TalkClub
· 11h atrás
又搞更新，idiotas被fazer as pessoas de parvas矿工
Ver originalResponder0
TokenomicsTrapper
· 11h atrás
ngmi apenas mais uma história de cope com eth para ser sincero...
Ver originalResponder0
DegenDreamer
· 11h atrás
Outra vez a falar de simplificação, mas não está a subir.
Ver originalResponder0
DaisyUnicorn
· 11h atrás
Vitalik Buterin vai aparar o jardim de Ethereum~
Ver originalResponder0
DogeBachelor
· 11h atrás
Após meio dia de atualizações, ainda não subiu o preço.
Ver originalResponder0
AlwaysMissingTops
· 12h atrás
Cowhide finalmente esperou para fazer esses dados antigos
Caminho de purificação do Ethereum: Gota de requisitos de armazenamento e simplificação da complexidade do protocolo
Ethereum: Purificação
Vitalik Buterin recentemente publicou uma série de artigos de discussão sobre o futuro do Ethereum, explorando desde a fusão, surto, chicotada, margem até a mais recente fase de purificação. Estes artigos mostram a visão de Vitalik sobre o futuro do mainnet do Ethereum e como resolver os problemas atuais que enfrenta.
O principal objetivo da fase de purificação é reduzir os requisitos de armazenamento do cliente, diminuindo ou eliminando a necessidade de cada nó armazenar permanentemente todos os registros históricos ou mesmo o estado final, e reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Histórico expirado
O histórico expirado visa resolver o problema de que os nós Ethereum totalmente sincronizados precisam de um grande espaço em disco. Atualmente, um cliente de execução requer cerca de 1,1 TB de espaço em disco, enquanto um cliente de consenso também precisa de centenas de GB. A maior parte disso é dados históricos de muitos anos atrás.
A chave para a expiração histórica é aproveitar as características do mecanismo de consenso; basta alcançar consenso sobre o bloco mais recente para validar a correção dos dados históricos. Isso oferece várias opções para armazenar registros históricos, como cada nó armazenar apenas uma parte dos dados.
Atualmente, o Ethereum começou a se desvincular gradualmente do modelo onde todos os nós armazenam permanentemente todo o histórico. Os blocos de consenso armazenam apenas cerca de 6 meses, enquanto os Blobs armazenam apenas cerca de 18 dias. O objetivo futuro é estabelecer um período de armazenamento unificado ( que pode ser de cerca de 18 dias ), e então armazenar dados antigos através de uma rede distribuída.
A implementação da expiração histórica ainda requer a construção e integração de soluções específicas de armazenamento distribuído, como a introdução de bibliotecas torrent existentes ou da rede Portal nativa do Ethereum. O principal compromisso está em como esforçar-se para fornecer dados históricos "antigos" e a profundidade da integração do armazenamento histórico no protocolo.
A expiração histórica é crucial para a operação e inicialização simplificadas dos nós, ajudando a realizar a visão de executar nós Ethereum em smartwatches. Isso também torna a implementação de nós Ethereum mais recente mais viável, suportando apenas a versão mais recente do protocolo.
Estado expirado
O estado expiração destina-se a resolver o problema de que, mesmo eliminando a necessidade de armazenar o histórico, a necessidade de armazenamento dos clientes continuará a crescer. Isso ocorre porque o saldo da conta do estado (, o número aleatório, o código do contrato e o armazenamento ) continuarão a crescer, e os usuários só precisam pagar uma taxa única para sobrecarregar permanentemente o armazenamento do cliente.
O estado expirado é mais difícil de ser alcançado do que o estado histórico expirado, pois o design do EVM assume que os objetos de estado, uma vez criados, existirão para sempre. Atualmente, existem duas principais soluções: expiração parcial do estado e expiração do estado baseada em ciclos de endereço.
Parte do estado expira, dividindo o estado em blocos, e apenas os dados acessados recentemente serão armazenados. O EIP-7736 é uma proposta concreta baseada no design de "folhas" introduzido para a árvore Verkle.
O design baseado no ciclo de endereços resolve o problema de conflito de ressurgimento através de uma lista de árvore de estado em constante crescimento. A cada período (, como 1 ano ), uma nova árvore de estado vazia é adicionada, e os nós completos armazenam apenas as duas árvores mais recentes.
O principal desafio da expiração de estado é a expansão ou contração do espaço de endereços, o que requer a resolução de problemas complexos de compatibilidade e segurança. Independentemente de a expiração de estado ser implementada ou não, a questão do espaço de endereços deve, em última análise, ser resolvida.
Limpeza de Funcionalidades
A limpeza de funcionalidades visa reduzir a complexidade do protocolo, melhorando a segurança, acessibilidade e neutralidade confiável. Os principais métodos incluem a remoção de funcionalidades desnecessárias, simplificação de mecanismos existentes e unificação de formatos de dados, entre outros.
Algumas oportunidades de simplificação específicas incluem:
A principal consideração na simplificação de funcionalidades é o grau de simplificação e a velocidade em relação à compatibilidade retroativa. É necessário estabelecer um pipeline padronizado para realizar alterações que não sejam urgentes, que quebrem a compatibilidade retroativa, buscando um equilíbrio entre a remoção de características e a conservação.
O formato de objeto EVM ( EOF ) é um conjunto de principais alterações propostas para o EVM, destinado a permitir que o EVM seja atualizado de uma maneira com propriedades mais robustas. Sua vantagem é que cria um caminho natural para adicionar novas funcionalidades ao EVM, mas também aumenta significativamente a complexidade do protocolo.
Uma estratégia de simplificação mais radical é transformar a maior parte do conteúdo do protocolo em código de contrato, como transformar o L1 do Ethereum em apenas uma cadeia de beacon, introduzindo uma máquina virtual mínima que permite a criação de resumos. Ou realizar uma troca no local da EVM, escolhendo uma nova "EVM oficial do Ethereum".
De um modo geral, a fase de purificação visa reduzir a necessidade de armazenamento e a complexidade do protocolo através do expurgo de históricos, expurgo de estados e limpeza de funcionalidades, estabelecendo assim uma base para a escalabilidade e sustentabilidade a longo prazo do Ethereum. Isso requer buscar um equilíbrio entre simplificação e compatibilidade, e pode envolver transformações profundas no protocolo.