Um dos desafios que o Ethereum enfrenta é que, por padrão, a expansão e a complexidade de qualquer protocolo de blockchain aumentam com o tempo. Isso acontece de duas maneiras:
Dados históricos: Todas as transações realizadas e todas as contas criadas em qualquer momento da história precisam ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente, de modo a serem totalmente sincronizadas com a rede. Isso fará com que a carga do cliente e o tempo de sincronização aumentem com o tempo, mesmo que a capacidade da cadeia permaneça inalterada.
Função do protocolo: adicionar novas funcionalidades é muito mais fácil do que remover funcionalidades antigas, levando a um aumento da complexidade do código ao longo do tempo.
Para que o Ethereum possa manter-se a longo prazo, precisamos exercer uma forte pressão contrária sobre essas duas tendências, reduzindo a complexidade e a expansão ao longo do tempo. Mas, ao mesmo tempo, precisamos preservar uma das propriedades-chave que tornam a blockchain grandiosa: a persistência. Você pode colocar um NFT, uma carta de amor em dados de chamadas de transação, ou um contrato inteligente que contenha 1 milhão de dólares na cadeia, entrar em uma caverna por dez anos e, ao sair, descobrir que ainda está lá, esperando por você para ler e interagir. Para que os DApps possam descentralizar-se completamente e remover as chaves de atualização com tranquilidade, eles precisam ter certeza de que suas dependências não serão atualizadas de maneiras que possam prejudicá-las - especialmente o L1 em si.
Se decidirmos equilibrar essas duas demandas e minimizar ou reverter a sobrecarga, complexidade e degradação enquanto mantemos a continuidade, isso é absolutamente possível. Os organismos podem fazer isso: enquanto a maioria dos organismos envelhece ao longo do tempo, alguns poucos afortunados não o fazem. Mesmo os sistemas sociais podem ter uma vida muito longa. Em alguns casos, o Ethereum já teve sucesso: a prova de trabalho desapareceu, o opcode SELFDESTRUCT desapareceu na maior parte, e os nós da beacon chain armazenaram dados antigos por até seis meses. Encontrar esse caminho para o Ethereum de uma maneira mais geral e avançar em direção a um resultado final estável a longo prazo é o desafio supremo para a escalabilidade a longo prazo do Ethereum, sustentabilidade técnica e até mesmo segurança.
The Purge: principal objetivo.
Reduzir os requisitos de armazenamento do cliente ao diminuir ou eliminar a necessidade de cada nó armazenar permanentemente todos os históricos e até mesmo o estado final.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Índice do artigo:
Histórico expiração
Estado de expiração（状态到期）
Limpeza de características
Expiração da história
Que problema resolve?
Até a data da redação deste artigo, um nó Ethereum completamente sincronizado requer cerca de 1,1 TB de espaço em disco para executar o cliente, além de centenas de GB de espaço em disco para o cliente de consenso. A maior parte disso é histórica: dados sobre blocos históricos, transações e recibos, a maior parte dos quais tem vários anos. Isso significa que, mesmo que o limite de Gas não aumente, o tamanho do nó continuará a aumentar em centenas de GB a cada ano.
O que é isso, como funciona?
Uma característica chave que simplifica o problema do armazenamento histórico é que, como cada bloco é vinculado ao bloco anterior através de hash (e outras estruturas), é suficiente alcançar consenso sobre o atual para alcançar consenso sobre o histórico. Desde que a rede alcance consenso sobre o bloco mais recente, qualquer bloco, transação ou estado histórico (saldo de conta, número aleatório, código, armazenamento) pode ser fornecido por qualquer participante individual, juntamente com a prova de Merkle, e essa prova permite que qualquer outra pessoa verifique sua correção. O consenso é um modelo de confiança N/2-of-N, enquanto o histórico é um modelo de confiança N-of-N.
Isto 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. Esta tem sido a forma de operação das redes de sementes ao longo de décadas: embora a rede armazene e distribua milhões de arquivos, cada participante armazena e distribui apenas alguns desses arquivos. Talvez contra a intuição, este método nem sequer precisa reduzir a robustez dos dados. Se, ao tornar a operação dos nós mais econômica, conseguirmos estabelecer uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% dos registros históricos, então cada dado será copiado 10.000 vezes - exatamente o mesmo fator de cópia de uma rede de 10.000 nós, onde cada nó armazena tudo.
Hoje, o Ethereum começou a se afastar do modelo em que todos os nós armazenam permanentemente toda a história. Os blocos de consenso (ou seja, a parte relacionada ao consenso de prova de participação) armazenam apenas cerca de 6 meses. 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 a longo prazo é estabelecer um período unificado (possivelmente em torno de 18 dias), durante o qual cada nó é responsável por armazenar todo o conteúdo, e então construir uma rede ponto a ponto composta por nós do Ethereum, armazenando dados antigos de forma distribuída.
Os códigos de apagamento podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. De fato, o Blob já foi codificado com códigos de apagamento para suportar a amostragem de disponibilidade de dados. A solução mais simples pode ser reutilizar esses códigos de apagamento e colocar os dados de execução e consenso do bloco também dentro do blob.
tem alguma relação com a pesquisa existente?
EIP-4444；
Torrents e EIP-4444；
Portal de rede;
Portal Network e EIP-4444;
Armazenamento e recuperação distribuídos de objetos SSZ no Portal;
Como aumentar o limite de gas (Paradigm).
O que mais precisa ser feito, o que precisa ser considerado?
O trabalho principal restante inclui a construção e integração de uma solução distribuída específica para armazenar o histórico ------ pelo menos o histórico de execução, mas eventualmente também incluirá consenso e blob. A solução mais simples é (i) simplesmente introduzir uma biblioteca torrent existente, bem como (ii) chamada de solução nativa do Ethereum conhecida como Portal Network. Assim que qualquer uma delas for introduzida, poderemos abrir o EIP-4444. O EIP-4444 em si não requer um hard fork, mas realmente precisa de uma nova versão do protocolo de rede. Portanto, é valioso ativá-lo para todos os clientes ao mesmo tempo, caso contrário, existe o risco de que os clientes falhem devido à conexão com outros nós que esperam baixar o histórico completo, mas na verdade não o obtêm.
As principais considerações envolvem como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar dados históricos antigos amanhã e depender de nós de nós existentes e de vários provedores centralizados para replicação. Isso é fácil, mas enfraquece a posição do Ethereum como um local de registro permanente. O caminho mais difícil, mas mais seguro, é primeiro construir e integrar uma rede torrent para armazenar registros de forma distribuída. Aqui, "quanto nos esforçamos" tem duas dimensões:
Como nos esforçamos para garantir que o maior conjunto de nós realmente armazena todos os dados?
Quão profunda é a integração do armazenamento histórico no protocolo?
Uma abordagem extremista e paranoica para (1) envolveria a prova de custódia: na prática, exigindo que cada validador de prova de participação armazenasse uma certa proporção de registos históricos e verificasse regularmente, de forma criptográfica, se o faz. Uma abordagem mais suave seria estabelecer um padrão voluntário para a percentagem de histórico armazenado por cada cliente.
Para (2), a implementação básica envolve apenas o trabalho que já foi concluído hoje: o Portal já armazenou arquivos ERA que contêm toda a história do Ethereum. Uma implementação mais completa envolveria a conexão real ao processo de sincronização, de modo que, se alguém quiser sincronizar um nó de armazenamento de histórico completo ou um nó de arquivo, mesmo que não haja outros nós de arquivo online, eles possam fazê-lo através da sincronização direta da rede do Portal.
Como interage com outras partes do roteiro?
Se quisermos tornar a execução ou o arranque de nós extremamente fácil, então reduzir a necessidade de armazenamento histórico pode ser considerado mais importante do que a ausência de estado: dos 1,1 TB necessários para o nó, cerca de 300 GB são estado, enquanto os restantes cerca de 800 GB se tornaram históricos. Apenas alcançando a ausência de estado e o EIP-4444 podemos realizar a visão de executar nós Ethereum em um relógio inteligente e configurá-los em apenas alguns minutos.
A limitação do armazenamento histórico torna a implementação de nós Ethereum mais viável, suportando apenas a versão mais recente do protocolo, o que os torna mais simples. Por exemplo, agora é seguro remover muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram eliminados. Agora que a transição para a prova de participação se tornou história, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
Expiração do estado
Que problema resolve?
Mesmo que eliminemos a necessidade de os clientes armazenarem o histórico, a necessidade de armazenamento dos clientes continuará a crescer, cerca de 50 GB por ano, à medida que o estado continua a aumentar: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, transferindo assim um encargo permanente para os clientes atuais e futuros do Ethereum.
O estado é mais difícil de "expirar" do que a história, porque a EVM foi projetada fundamentalmente em torno da suposição de que, uma vez criado um objeto de estado, ele sempre existirá e poderá ser lido a qualquer momento por qualquer transação. Se introduzirmos a ausência de estado, algumas pessoas acreditam que esse problema talvez não seja tão grave: apenas classes de construtores de blocos dedicados precisariam realmente armazenar estado, enquanto todos os outros nós (mesmo aqueles que geram listas!) poderiam operar de forma sem estado. No entanto, há uma opinião de que não queremos depender excessivamente da ausência de estado, e que, no final, podemos querer permitir que o estado expire para manter a descentralização do Ethereum.
O que é isso e como funciona?
Hoje, quando você cria um novo objeto de estado (o que pode ocorrer de uma das três maneiras a seguir: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta com código, (iii) configurando um slot de armazenamento que nunca foi tocado antes), esse objeto de estado permanece nesse estado para sempre. Em vez disso, o que queremos é que o objeto expire automaticamente ao longo do tempo. O desafio chave é fazer isso de uma maneira que atinja três objetivos:
Eficiência: não requer uma grande quantidade de cálculos adicionais para executar o processo de vencimento.
Facilidade de uso: se alguém entrar numa caverna durante cinco anos e voltar, não deve perder o acesso às posições de ETH, ERC20, NFT e CDP...
Amigável para desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento completamente desconhecido. Além disso, aplicativos que estão atualmente rígidos e não atualizados devem continuar a funcionar normalmente.
Não satisfazer esses objetivos torna fácil resolver problemas. Por exemplo, você pode fazer com que cada objeto de estado também armazene um contador de data de expiração (que pode ser estendido queimando ETH, o que pode ocorrer automaticamente a qualquer momento durante a leitura ou gravação), e ter um processo que percorre o estado para remover objetos de estado com datas de expiração. No entanto, isso introduz cálculos adicionais (até mesmo requisitos de armazenamento), e definitivamente não pode atender aos requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre casos extremos em que os valores armazenados às vezes são redefinidos para zero. Se você definir um temporizador de expiração dentro do escopo do contrato, isso tecnicamente tornaria a vida dos desenvolvedores mais fácil, mas tornaria a economia mais complicada: os desenvolvedores devem considerar como "transferir" o custo contínuo de armazenamento para os usuários.
Estes são problemas que a comunidade de desenvolvedores centrais do Ethereum tem trabalhado arduamente para resolver ao longo dos anos, incluindo propostas como "renda de blockchain" e "regeneração". No final, combinamos as melhores partes das propostas e nos concentramos em duas categorias de "soluções conhecidas como as menos ruins":
Solução para parte do estado expirado
Sugestão de expiração de estado baseada no ciclo de endereços.
Expiração parcial do estado
Algumas propostas de estado expirado seguem os mesmos princípios. Dividimos 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ão armazenados apenas se foram acessados recentemente. Há um mecanismo de "ressurreição" que, se não estiver mais armazenado.
 e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
10 Curtidas
Recompensa
10
3
Repostar
Compartilhar
Comentário
0/400
GasWaster
· 2h atrás
Exceto o grosso, pegou o fino.
Ver originalResponder0
ChainSherlockGirl
· 2h atrás
Acelera a perda de peso, Vitalik Buterin! O que tens na tua cadeia está quase a ser liquidado.
Vitalik propôs a visão do Ethereum The Purge: Gota de complexidade para alcançar um desenvolvimento sustentável a longo prazo.
Vitalik: O possível futuro do Ethereum, The Purge
Um dos desafios que o Ethereum enfrenta é que, por padrão, a expansão e a complexidade de qualquer protocolo de blockchain aumentam com o tempo. Isso acontece de duas maneiras:
Dados históricos: Todas as transações realizadas e todas as contas criadas em qualquer momento da história precisam ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente, de modo a serem totalmente sincronizadas com a rede. Isso fará com que a carga do cliente e o tempo de sincronização aumentem com o tempo, mesmo que a capacidade da cadeia permaneça inalterada.
Função do protocolo: adicionar novas funcionalidades é muito mais fácil do que remover funcionalidades antigas, levando a um aumento da complexidade do código ao longo do tempo.
Para que o Ethereum possa manter-se a longo prazo, precisamos exercer uma forte pressão contrária sobre essas duas tendências, reduzindo a complexidade e a expansão ao longo do tempo. Mas, ao mesmo tempo, precisamos preservar uma das propriedades-chave que tornam a blockchain grandiosa: a persistência. Você pode colocar um NFT, uma carta de amor em dados de chamadas de transação, ou um contrato inteligente que contenha 1 milhão de dólares na cadeia, entrar em uma caverna por dez anos e, ao sair, descobrir que ainda está lá, esperando por você para ler e interagir. Para que os DApps possam descentralizar-se completamente e remover as chaves de atualização com tranquilidade, eles precisam ter certeza de que suas dependências não serão atualizadas de maneiras que possam prejudicá-las - especialmente o L1 em si.
Se decidirmos equilibrar essas duas demandas e minimizar ou reverter a sobrecarga, complexidade e degradação enquanto mantemos a continuidade, isso é absolutamente possível. Os organismos podem fazer isso: enquanto a maioria dos organismos envelhece ao longo do tempo, alguns poucos afortunados não o fazem. Mesmo os sistemas sociais podem ter uma vida muito longa. Em alguns casos, o Ethereum já teve sucesso: a prova de trabalho desapareceu, o opcode SELFDESTRUCT desapareceu na maior parte, e os nós da beacon chain armazenaram dados antigos por até seis meses. Encontrar esse caminho para o Ethereum de uma maneira mais geral e avançar em direção a um resultado final estável a longo prazo é o desafio supremo para a escalabilidade a longo prazo do Ethereum, sustentabilidade técnica e até mesmo segurança.
The Purge: principal objetivo.
Reduzir os requisitos de armazenamento do cliente ao diminuir ou eliminar a necessidade de cada nó armazenar permanentemente todos os históricos e até mesmo o estado final.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Índice do artigo:
Histórico expiração
Estado de expiração（状态到期）
Limpeza de características
Expiração da história
Que problema resolve?
Até a data da redação deste artigo, um nó Ethereum completamente sincronizado requer cerca de 1,1 TB de espaço em disco para executar o cliente, além de centenas de GB de espaço em disco para o cliente de consenso. A maior parte disso é histórica: dados sobre blocos históricos, transações e recibos, a maior parte dos quais tem vários anos. Isso significa que, mesmo que o limite de Gas não aumente, o tamanho do nó continuará a aumentar em centenas de GB a cada ano.
O que é isso, como funciona?
Uma característica chave que simplifica o problema do armazenamento histórico é que, como cada bloco é vinculado ao bloco anterior através de hash (e outras estruturas), é suficiente alcançar consenso sobre o atual para alcançar consenso sobre o histórico. Desde que a rede alcance consenso sobre o bloco mais recente, qualquer bloco, transação ou estado histórico (saldo de conta, número aleatório, código, armazenamento) pode ser fornecido por qualquer participante individual, juntamente com a prova de Merkle, e essa prova permite que qualquer outra pessoa verifique sua correção. O consenso é um modelo de confiança N/2-of-N, enquanto o histórico é um modelo de confiança N-of-N.
Isto 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. Esta tem sido a forma de operação das redes de sementes ao longo de décadas: embora a rede armazene e distribua milhões de arquivos, cada participante armazena e distribui apenas alguns desses arquivos. Talvez contra a intuição, este método nem sequer precisa reduzir a robustez dos dados. Se, ao tornar a operação dos nós mais econômica, conseguirmos estabelecer uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% dos registros históricos, então cada dado será copiado 10.000 vezes - exatamente o mesmo fator de cópia de uma rede de 10.000 nós, onde cada nó armazena tudo.
Hoje, o Ethereum começou a se afastar do modelo em que todos os nós armazenam permanentemente toda a história. Os blocos de consenso (ou seja, a parte relacionada ao consenso de prova de participação) armazenam apenas cerca de 6 meses. 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 a longo prazo é estabelecer um período unificado (possivelmente em torno de 18 dias), durante o qual cada nó é responsável por armazenar todo o conteúdo, e então construir uma rede ponto a ponto composta por nós do Ethereum, armazenando dados antigos de forma distribuída.
Os códigos de apagamento podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. De fato, o Blob já foi codificado com códigos de apagamento para suportar a amostragem de disponibilidade de dados. A solução mais simples pode ser reutilizar esses códigos de apagamento e colocar os dados de execução e consenso do bloco também dentro do blob.
tem alguma relação com a pesquisa existente?
EIP-4444；
Torrents e EIP-4444；
Portal de rede;
Portal Network e EIP-4444;
Armazenamento e recuperação distribuídos de objetos SSZ no Portal;
Como aumentar o limite de gas (Paradigm).
O que mais precisa ser feito, o que precisa ser considerado?
O trabalho principal restante inclui a construção e integração de uma solução distribuída específica para armazenar o histórico ------ pelo menos o histórico de execução, mas eventualmente também incluirá consenso e blob. A solução mais simples é (i) simplesmente introduzir uma biblioteca torrent existente, bem como (ii) chamada de solução nativa do Ethereum conhecida como Portal Network. Assim que qualquer uma delas for introduzida, poderemos abrir o EIP-4444. O EIP-4444 em si não requer um hard fork, mas realmente precisa de uma nova versão do protocolo de rede. Portanto, é valioso ativá-lo para todos os clientes ao mesmo tempo, caso contrário, existe o risco de que os clientes falhem devido à conexão com outros nós que esperam baixar o histórico completo, mas na verdade não o obtêm.
As principais considerações envolvem como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar dados históricos antigos amanhã e depender de nós de nós existentes e de vários provedores centralizados para replicação. Isso é fácil, mas enfraquece a posição do Ethereum como um local de registro permanente. O caminho mais difícil, mas mais seguro, é primeiro construir e integrar uma rede torrent para armazenar registros de forma distribuída. Aqui, "quanto nos esforçamos" tem duas dimensões:
Como nos esforçamos para garantir que o maior conjunto de nós realmente armazena todos os dados?
Quão profunda é a integração do armazenamento histórico no protocolo?
Uma abordagem extremista e paranoica para (1) envolveria a prova de custódia: na prática, exigindo que cada validador de prova de participação armazenasse uma certa proporção de registos históricos e verificasse regularmente, de forma criptográfica, se o faz. Uma abordagem mais suave seria estabelecer um padrão voluntário para a percentagem de histórico armazenado por cada cliente.
Para (2), a implementação básica envolve apenas o trabalho que já foi concluído hoje: o Portal já armazenou arquivos ERA que contêm toda a história do Ethereum. Uma implementação mais completa envolveria a conexão real ao processo de sincronização, de modo que, se alguém quiser sincronizar um nó de armazenamento de histórico completo ou um nó de arquivo, mesmo que não haja outros nós de arquivo online, eles possam fazê-lo através da sincronização direta da rede do Portal.
Como interage com outras partes do roteiro?
Se quisermos tornar a execução ou o arranque de nós extremamente fácil, então reduzir a necessidade de armazenamento histórico pode ser considerado mais importante do que a ausência de estado: dos 1,1 TB necessários para o nó, cerca de 300 GB são estado, enquanto os restantes cerca de 800 GB se tornaram históricos. Apenas alcançando a ausência de estado e o EIP-4444 podemos realizar a visão de executar nós Ethereum em um relógio inteligente e configurá-los em apenas alguns minutos.
A limitação do armazenamento histórico torna a implementação de nós Ethereum mais viável, suportando apenas a versão mais recente do protocolo, o que os torna mais simples. Por exemplo, agora é seguro remover muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram eliminados. Agora que a transição para a prova de participação se tornou história, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
Expiração do estado
Que problema resolve?
Mesmo que eliminemos a necessidade de os clientes armazenarem o histórico, a necessidade de armazenamento dos clientes continuará a crescer, cerca de 50 GB por ano, à medida que o estado continua a aumentar: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, transferindo assim um encargo permanente para os clientes atuais e futuros do Ethereum.
O estado é mais difícil de "expirar" do que a história, porque a EVM foi projetada fundamentalmente em torno da suposição de que, uma vez criado um objeto de estado, ele sempre existirá e poderá ser lido a qualquer momento por qualquer transação. Se introduzirmos a ausência de estado, algumas pessoas acreditam que esse problema talvez não seja tão grave: apenas classes de construtores de blocos dedicados precisariam realmente armazenar estado, enquanto todos os outros nós (mesmo aqueles que geram listas!) poderiam operar de forma sem estado. No entanto, há uma opinião de que não queremos depender excessivamente da ausência de estado, e que, no final, podemos querer permitir que o estado expire para manter a descentralização do Ethereum.
O que é isso e como funciona?
Hoje, quando você cria um novo objeto de estado (o que pode ocorrer de uma das três maneiras a seguir: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta com código, (iii) configurando um slot de armazenamento que nunca foi tocado antes), esse objeto de estado permanece nesse estado para sempre. Em vez disso, o que queremos é que o objeto expire automaticamente ao longo do tempo. O desafio chave é fazer isso de uma maneira que atinja três objetivos:
Eficiência: não requer uma grande quantidade de cálculos adicionais para executar o processo de vencimento.
Facilidade de uso: se alguém entrar numa caverna durante cinco anos e voltar, não deve perder o acesso às posições de ETH, ERC20, NFT e CDP...
Amigável para desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento completamente desconhecido. Além disso, aplicativos que estão atualmente rígidos e não atualizados devem continuar a funcionar normalmente.
Não satisfazer esses objetivos torna fácil resolver problemas. Por exemplo, você pode fazer com que cada objeto de estado também armazene um contador de data de expiração (que pode ser estendido queimando ETH, o que pode ocorrer automaticamente a qualquer momento durante a leitura ou gravação), e ter um processo que percorre o estado para remover objetos de estado com datas de expiração. No entanto, isso introduz cálculos adicionais (até mesmo requisitos de armazenamento), e definitivamente não pode atender aos requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre casos extremos em que os valores armazenados às vezes são redefinidos para zero. Se você definir um temporizador de expiração dentro do escopo do contrato, isso tecnicamente tornaria a vida dos desenvolvedores mais fácil, mas tornaria a economia mais complicada: os desenvolvedores devem considerar como "transferir" o custo contínuo de armazenamento para os usuários.
Estes são problemas que a comunidade de desenvolvedores centrais do Ethereum tem trabalhado arduamente para resolver ao longo dos anos, incluindo propostas como "renda de blockchain" e "regeneração". No final, combinamos as melhores partes das propostas e nos concentramos em duas categorias de "soluções conhecidas como as menos ruins":
Expiração parcial do estado
Algumas propostas de estado expirado seguem os mesmos princípios. Dividimos 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ão armazenados apenas se foram acessados recentemente. Há um mecanismo de "ressurreição" que, se não estiver mais armazenado.
![Vitalik: O possível futuro do Ethereum, The Purge](https://