Um dos desafios importantes que o Ethereum enfrenta é como reduzir a complexidade e as necessidades de armazenamento a longo prazo, mantendo ao mesmo tempo a persistência e a descentralização da cadeia. Para que o Ethereum possa se manter a longo prazo, precisamos exercer uma forte pressão contrária sobre a complexidade e a expansão, reduzindo a complexidade e a expansão ao longo do tempo. Mas, ao mesmo tempo, precisamos preservar essa propriedade chave da persistência da blockchain.
Os principais objetivos da purificação incluem:
Reduzir os requisitos de armazenamento do cliente ao diminuir ou eliminar a necessidade de cada nó armazenar permanentemente todos os históricos, até mesmo o estado final.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Histórico expirado
resolve que problema?
Até agora, um nó Ethereum totalmente sincronizado requer cerca de 1,1 TB de espaço em disco para executar o cliente, além de várias centenas de GB para o cliente de consenso. A maior parte disso é dados históricos, e mesmo que o tamanho do bloco permaneça o mesmo, o tamanho do nó continuará a aumentar várias centenas de GB a cada ano.
O que é, como funciona?
Uma característica chave da simplificação do problema de armazenamento histórico é que, como cada bloco está vinculado ao bloco anterior através de um hash, alcançar consenso sobre o atual é suficiente para alcançar consenso sobre a história. Isso nos oferece muitas opções sobre como armazenar registros históricos. Uma escolha natural é uma rede onde cada nó armazena apenas uma pequena parte dos dados.
Hoje, o Ethereum começou a se afastar do modelo em que todos os nós armazenam permanentemente todo o histórico. Os blocos de consenso armazenam apenas cerca de 6 meses. Os Blobs armazenam apenas cerca de 18 dias. O EIP-4444 visa introduzir um período de armazenamento de um ano para blocos históricos e recibos. O objetivo de longo prazo é estabelecer um período unificado ( que pode ser de cerca de 18 dias ), durante o qual cada nó é responsável por armazenar tudo, e então estabelecer uma rede ponto a ponto composta por nós do Ethereum, armazenando dados antigos de maneira distribuída.
O que mais precisa ser feito, o que precisa ser ponderado?
O trabalho principal restante inclui construir e integrar uma solução distribuída específica para armazenar históricos. A solução mais simples é introduzir uma biblioteca torrent existente ou a solução nativa do Ethereum chamada Portal Network. A principal consideração envolve como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar históricos antigos amanhã e confiar em nós existentes nós de arquivamento e vários provedores centralizados para replicação. O caminho mais difícil, mas mais seguro, é primeiro construir e integrar uma rede torrent para armazenar históricos de forma distribuída.
como interage com as outras partes do roteiro?
Se quisermos que a execução ou o início de um nó se torne extremamente fácil, então reduzir a necessidade de armazenamento histórico pode ser considerado mais importante do que a ausência de estado. Somente ao alcançar a ausência de estado e o EIP-4444, podemos concretizar a visão de executar um nó Ethereum em um smartwatch e configurá-lo em apenas alguns minutos.
Estado expirado
Resolve que problema?
Mesmo que eliminemos a necessidade de armazenamento de histórico pelo cliente, a demanda de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, uma vez que o estado continua a crescer. Os usuários podem pagar uma taxa única, transferindo assim o fardo para os clientes de Ethereum atuais e futuros.
O que é, como funciona?
Hoje, ao criar um novo objeto de estado, esse objeto de estado permanece sempre nesse estado. Em vez disso, o que queremos é que o objeto expire automaticamente ao longo do tempo. O desafio chave é fazer isso de uma forma que atinja eficiência, facilidade de uso e facilidade para os desenvolvedores.
Atualmente, existem duas categorias de "soluções conhecidas como as menos ruins":
Soluções de expiração parcial
Sugestões de expiração de estado com base no ciclo de endereço
Algumas propostas de estado de expiração dividem o estado em blocos. Cada pessoa armazena permanentemente o "mapeamento de topo", onde os blocos podem estar vazios ou não. Os dados em cada bloco só serão armazenados se esses dados tiverem sido acessados recentemente. Existe um mecanismo de "ressurreição" caso os dados não sejam mais armazenados.
O design baseado no ciclo de endereços utiliza uma lista de árvores de estado em constante crescimento, e qualquer estado lido ou escrito será mantido na árvore de estado mais recente. A cada período (, por exemplo: uma nova árvore de estado vazia é adicionada uma vez por ano ). As árvores antigas ficam congeladas. Nós completos armazenam apenas as duas árvores mais recentes.
O que mais precisa ser feito, o que precisa ser ponderado?
Eu acho que há quatro caminhos viáveis para o futuro:
Nós fazemos sem estado e nunca introduzimos a expiração do estado.
Vamos realizar o vencimento parcial do estado e aceitar uma taxa de crescimento do tamanho do estado permanente que é muito mais baixa, mas ainda assim não zero.
Fazemos a expiração do estado através da expansão do espaço de endereços.
Realizamos a expiração do estado através da contração do espaço de endereços.
Um ponto importante é que, independentemente de implementar ou não um esquema de expiração de estado que dependa de mudanças no formato de endereço, a questão da expansão e contração do espaço de endereços deve ser resolvida.
Limpeza de Funcionalidades
Resolve que problema?
Uma das condições prévias-chave para a segurança, acessibilidade e neutralidade confiável é a simplicidade. Se o protocolo for atraente e simples, reduzirá a probabilidade de erros. Isso aumenta as oportunidades para novos desenvolvedores participarem de qualquer parte. É mais provável que seja justo e também mais fácil de resistir a interesses especiais. Infelizmente, os protocolos, como qualquer sistema social, tendem a tornar-se mais complexos ao longo do tempo por padrão.
O que é, como funciona?
Não há nenhuma correção única significativa que possa reduzir a complexidade do protocolo; a natureza do problema é que existem muitas pequenas soluções. Alguns exemplos-chave incluem:
Conversão de RLP para SSZ
Remover o tipo de transação antigo
LOG Reforma
Remoção final do mecanismo de comissão de sincronização da cadeia de beacon
Formato de dados unificado
Remover o comitê da cadeia de beacon
Remover a ordem de bytes misturada
Simplificação do mecanismo de gás
Remover pré-compilado
Remover a observabilidade do gas
Melhoria da análise estática
O que mais precisa ser feito, o que precisa ser ponderado?
O principal compromisso para simplificar esta funcionalidade é o nível e a velocidade da nossa simplificação em relação à compatibilidade retroativa. A questão social mais ampla é criar um pipeline padronizado para realizar alterações que quebrem a compatibilidade retroativa de forma não urgente.
O formato de objeto EVM ( EOF ) é um conjunto de mudanças principais propostas para o EVM. A sua vantagem é que cria um caminho natural para adicionar novas funcionalidades ao EVM e incentiva a migração para um EVM mais rigoroso, com garantias mais fortes. A sua desvantagem é o aumento significativo da complexidade do protocolo, a menos que consigamos encontrar uma maneira de eventualmente descontinuar e remover o EVM antigo.
Uma estratégia de simplificação mais radical do Ethereum é manter o protocolo inalterado, mas transferir a maior parte de suas funcionalidades do protocolo para o código dos contratos. A versão mais extrema é fazer com que o L1 do Ethereum seja "tecnicamente" apenas a cadeia de beacon, e introduzir uma máquina virtual mínima, permitindo que outros criem seus próprios resumos. Então, a EVM se tornará o primeiro desses resumos.
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.
16 gostos
Recompensa
16
4
Partilhar
Comentar
0/400
SchroedingersFrontrun
· 7h atrás
A otimização de armazenamento é extremamente necessária.
Caminho de purificação do Ethereum: Gota de complexidade e desafio a longo prazo das necessidades de armazenamento
O futuro possível do Ethereum: purificação
Um dos desafios importantes que o Ethereum enfrenta é como reduzir a complexidade e as necessidades de armazenamento a longo prazo, mantendo ao mesmo tempo a persistência e a descentralização da cadeia. Para que o Ethereum possa se manter a longo prazo, precisamos exercer uma forte pressão contrária sobre a complexidade e a expansão, reduzindo a complexidade e a expansão ao longo do tempo. Mas, ao mesmo tempo, precisamos preservar essa propriedade chave da persistência da blockchain.
Os principais objetivos da purificação incluem:
Reduzir os requisitos de armazenamento do cliente ao diminuir ou eliminar a necessidade de cada nó armazenar permanentemente todos os históricos, até mesmo o estado final.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Histórico expirado
resolve que problema?
Até agora, um nó Ethereum totalmente sincronizado requer cerca de 1,1 TB de espaço em disco para executar o cliente, além de várias centenas de GB para o cliente de consenso. A maior parte disso é dados históricos, e mesmo que o tamanho do bloco permaneça o mesmo, o tamanho do nó continuará a aumentar várias centenas de GB a cada ano.
O que é, como funciona?
Uma característica chave da simplificação do problema de armazenamento histórico é que, como cada bloco está vinculado ao bloco anterior através de um hash, alcançar consenso sobre o atual é suficiente para alcançar consenso sobre a história. Isso nos oferece muitas opções sobre como armazenar registros históricos. Uma escolha natural é uma rede onde cada nó armazena apenas uma pequena parte dos dados.
Hoje, o Ethereum começou a se afastar do modelo em que todos os nós armazenam permanentemente todo o histórico. Os blocos de consenso armazenam apenas cerca de 6 meses. Os Blobs armazenam apenas cerca de 18 dias. O EIP-4444 visa introduzir um período de armazenamento de um ano para blocos históricos e recibos. O objetivo de longo prazo é estabelecer um período unificado ( que pode ser de cerca de 18 dias ), durante o qual cada nó é responsável por armazenar tudo, e então estabelecer uma rede ponto a ponto composta por nós do Ethereum, armazenando dados antigos de maneira distribuída.
O que mais precisa ser feito, o que precisa ser ponderado?
O trabalho principal restante inclui construir e integrar uma solução distribuída específica para armazenar históricos. A solução mais simples é introduzir uma biblioteca torrent existente ou a solução nativa do Ethereum chamada Portal Network. A principal consideração envolve como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar históricos antigos amanhã e confiar em nós existentes nós de arquivamento e vários provedores centralizados para replicação. O caminho mais difícil, mas mais seguro, é primeiro construir e integrar uma rede torrent para armazenar históricos de forma distribuída.
como interage com as outras partes do roteiro?
Se quisermos que a execução ou o início de um nó se torne extremamente fácil, então reduzir a necessidade de armazenamento histórico pode ser considerado mais importante do que a ausência de estado. Somente ao alcançar a ausência de estado e o EIP-4444, podemos concretizar a visão de executar um nó Ethereum em um smartwatch e configurá-lo em apenas alguns minutos.
Estado expirado
Resolve que problema?
Mesmo que eliminemos a necessidade de armazenamento de histórico pelo cliente, a demanda de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, uma vez que o estado continua a crescer. Os usuários podem pagar uma taxa única, transferindo assim o fardo para os clientes de Ethereum atuais e futuros.
O que é, como funciona?
Hoje, ao criar um novo objeto de estado, esse objeto de estado permanece sempre nesse estado. Em vez disso, o que queremos é que o objeto expire automaticamente ao longo do tempo. O desafio chave é fazer isso de uma forma que atinja eficiência, facilidade de uso e facilidade para os desenvolvedores.
Atualmente, existem duas categorias de "soluções conhecidas como as menos ruins":
Algumas propostas de estado de expiração dividem o estado em blocos. Cada pessoa armazena permanentemente o "mapeamento de topo", onde os blocos podem estar vazios ou não. Os dados em cada bloco só serão armazenados se esses dados tiverem sido acessados recentemente. Existe um mecanismo de "ressurreição" caso os dados não sejam mais armazenados.
O design baseado no ciclo de endereços utiliza uma lista de árvores de estado em constante crescimento, e qualquer estado lido ou escrito será mantido na árvore de estado mais recente. A cada período (, por exemplo: uma nova árvore de estado vazia é adicionada uma vez por ano ). As árvores antigas ficam congeladas. Nós completos armazenam apenas as duas árvores mais recentes.
O que mais precisa ser feito, o que precisa ser ponderado?
Eu acho que há quatro caminhos viáveis para o futuro:
Um ponto importante é que, independentemente de implementar ou não um esquema de expiração de estado que dependa de mudanças no formato de endereço, a questão da expansão e contração do espaço de endereços deve ser resolvida.
Limpeza de Funcionalidades
Resolve que problema?
Uma das condições prévias-chave para a segurança, acessibilidade e neutralidade confiável é a simplicidade. Se o protocolo for atraente e simples, reduzirá a probabilidade de erros. Isso aumenta as oportunidades para novos desenvolvedores participarem de qualquer parte. É mais provável que seja justo e também mais fácil de resistir a interesses especiais. Infelizmente, os protocolos, como qualquer sistema social, tendem a tornar-se mais complexos ao longo do tempo por padrão.
O que é, como funciona?
Não há nenhuma correção única significativa que possa reduzir a complexidade do protocolo; a natureza do problema é que existem muitas pequenas soluções. Alguns exemplos-chave incluem:
O que mais precisa ser feito, o que precisa ser ponderado?
O principal compromisso para simplificar esta funcionalidade é o nível e a velocidade da nossa simplificação em relação à compatibilidade retroativa. A questão social mais ampla é criar um pipeline padronizado para realizar alterações que quebrem a compatibilidade retroativa de forma não urgente.
O formato de objeto EVM ( EOF ) é um conjunto de mudanças principais propostas para o EVM. A sua vantagem é que cria um caminho natural para adicionar novas funcionalidades ao EVM e incentiva a migração para um EVM mais rigoroso, com garantias mais fortes. A sua desvantagem é o aumento significativo da complexidade do protocolo, a menos que consigamos encontrar uma maneira de eventualmente descontinuar e remover o EVM antigo.
Uma estratégia de simplificação mais radical do Ethereum é manter o protocolo inalterado, mas transferir a maior parte de suas funcionalidades do protocolo para o código dos contratos. A versão mais extrema é fazer com que o L1 do Ethereum seja "tecnicamente" apenas a cadeia de beacon, e introduzir uma máquina virtual mínima, permitindo que outros criem seus próprios resumos. Então, a EVM se tornará o primeiro desses resumos.