Um dos desafios enfrentados pelo Ethereum é que, por padrão, a expansão e a complexidade de qualquer protocolo de blockchain aumentam com o tempo. Isso acontece em dois lugares:
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 forma a sincronizar completamente com a rede. Isso resulta em uma carga e tempo de sincronização dos clientes que aumentam continuamente ao longo do 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, resultando em uma complexidade de código que aumenta com o tempo.
Para que o Ethereum possa se manter 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 características-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 contendo 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 se descentralizar completamente e remover a chave de atualização, eles precisam ter certeza de que suas dependências não serão atualizadas de uma maneira que as prejudique - especialmente o L1 em si.
Se decidirmos equilibrar essas duas demandas e minimizar ou reverter a gordura, complexidade e decadência, mantendo a continuidade, isso é absolutamente possível. Os organismos podem fazer isso: embora a maioria dos organismos envelheça com o tempo, alguns poucos sortudos não o fazem. Mesmo os sistemas sociais podem ter uma vida útil muito longa. Em alguns casos, o Ethereum já teve sucesso: a prova de trabalho desapareceu, o código de operação SELFDESTRUCT desapareceu na maior parte, e os nós da cadeia Beacon já armazenaram dados antigos por até seis meses. Descobrir esse caminho para o Ethereum de uma maneira mais geral e caminhar em direção a um resultado final de estabilidade a longo prazo é o desafio supremo para a escalabilidade a longo prazo do Ethereum, sustentabilidade técnica e até mesmo segurança.
A Purga: Objetivo principal.
Reduzir os requisitos de armazenamento do cliente ao reduzir ou eliminar a necessidade de cada nó armazenar permanentemente todos os registros históricos ou até mesmo o estado final.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Índice do artigo:
Histórico de expiração
Estado de expiração
Limpeza de características
Expiração do histórico
Resolve que problema?
Até o momento 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 várias 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 maioria 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 centenas de GB a cada ano.
O que é isso e como funciona?
Uma característica chave da simplificação do problema de armazenamento histórico é que, como cada bloco aponta para o bloco anterior através de links de hash (e outras estruturas), é suficiente que haja consenso sobre o atual para que haja consenso sobre o histórico. Desde que a rede alcance consenso sobre o bloco mais recente, qualquer bloco histórico, transação ou estado (saldo da conta, número aleatório, código, armazenamento) pode ser fornecido por qualquer participante individual, juntamente com uma prova 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 o histórico. Uma escolha natural é uma rede onde cada nó armazena apenas uma pequena parte dos dados. Esta é a forma como as redes de sementes operam há décadas: embora a rede armazene e distribua milhões de arquivos no total, cada participante armazena e distribui apenas alguns desses arquivos. Talvez contra a intuição, este método pode até não 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% do histórico, então cada dado será replicado 10.000 vezes - exatamente o mesmo fator de replicação que uma rede de 10.000 nós, onde cada nó armazena tudo.
Hoje, o Ethereum começou a se desvincular do modelo em que todos os nós armazenam permanentemente todo o histórico. Os blocos de consenso (ou seja, a parte relacionada ao consenso de prova de participação) 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 a longo prazo é estabelecer um período unificado (possivelmente 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, onde os dados antigos são armazenados de forma distribuída.
Códigos de apagamento podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. De fato, o Blob já implementou códigos de apagamento para suportar a amostragem de disponibilidade de dados. A solução mais simples provavelmente 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;
Rede de portal 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 deve ser ponderado?
O trabalho principal restante inclui a construção e integração de uma solução distribuída específica para armazenar históricos ----- pelo menos o histórico de execução, mas eventualmente incluindo consenso e blob. A solução mais simples é (i) simplesmente introduzir bibliotecas torrent existentes, bem como (ii) chamada solução nativa do Ethereum, a rede Portal. Assim que introduzirmos qualquer uma delas, poderemos abrir o EIP-4444. O EIP-4444 em si não requer um hard fork, mas realmente necessita de uma nova versão do protocolo de rede. Portanto, é valioso habilitá-lo para todos os clientes ao mesmo tempo, caso contrário, há o risco de que clientes falhem ao se conectar a outros nós, esperando baixar o histórico completo, mas na verdade não o obtendo.
A principal negociação envolve como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar dados históricos antigos amanhã e confiar em nós para replicar através de nós de arquivamento existentes e vários provedores centralizados. Isso é fácil, mas enfraquece a posição do Ethereum como um local de registro permanente. Uma abordagem mais difícil, mas mais segura, é primeiro construir e integrar uma rede torrent para armazenar o histórico de forma distribuída. Aqui, "o quanto nos esforçamos" tem duas dimensões:
Como nos esforçamos para garantir que o maior conjunto de nós realmente armazene todos os dados?
Qual é a profundidade da integração do armazenamento histórico no protocolo?
Uma abordagem extremamente paranoica para (1) envolveria a prova de custódia: exigir que cada validador de prova de participação armazenasse uma certa proporção de registros históricos e verificasse periodicamente, 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 o arquivo ERA que contém toda a história do Ethereum. Uma implementação mais completa envolveria realmente conectá-lo 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 disponíveis, eles possam fazê-lo através da sincronização direta da rede do portal.
Como interage com as outras partes do roteiro?
Se quisermos tornar a execução ou o início 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 aproximadamente 800 GB tornaram-se históricos. Apenas alcançando a ausência de estado e o EIP-4444 poderemos realizar a visão de executar um nó Ethereum em um smartwatch e configurá-lo em apenas alguns minutos.
A limitação do armazenamento histórico também torna a implementação de nós mais recentes do Ethereum mais viável, suportando apenas a versão mais recente do protocolo, o que os torna mais simples. Por exemplo, agora é possível remover com segurança muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram removidos. Agora que a transição para a prova de participação se tornou parte da história, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
Expiração do estado
Resolve que problema?
Mesmo que eliminemos a necessidade de armazenamento de histórico no cliente, a demanda de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, à medida que o estado continua a crescer: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, o que sobrecarregará para sempre os clientes Ethereum atuais e futuros.
O estado é "mais difícil" de "expirar" do que a história, porque a EVM foi fundamentalmente projetada 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, alguns acreditam que esse problema talvez não seja tão ruim assim: apenas classes de construtores de blocos dedicados precisam realmente armazenar estado, enquanto todos os outros nós (até mesmo aqueles que geram listas!) podem operar sem estado. No entanto, há uma opinião de que não queremos depender excessivamente da ausência de estado, e no final, poderemos querer permitir que o estado expire para manter a descentralização do Ethereum.
O que é, como funciona
Hoje, quando você cria um novo objeto de estado (isso pode acontecer de uma das três maneiras a seguir: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta usando código, (iii) configurando um slot de armazenamento que não foi tocado anteriormente), esse objeto de estado permanece nesse estado para sempre. Em vez disso, o que desejamos é que o objeto expire automaticamente ao longo do tempo. O desafio fundamental é fazer isso de uma forma que atinja três objetivos:
Eficiência: não é necessário um grande cálculo adicional para executar o processo de vencimento.
Facilidade de uso: se alguém entrar na caverna por 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, as aplicações que atualmente estão rígidas e não atualizadas devem continuar a funcionar normalmente.
Não atender a 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 escrita) e ter um processo que percorre os estados para remover objetos de estado com data de expiração. No entanto, isso introduz cálculos adicionais (e 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 situações limites onde os valores armazenados às vezes são redefinidos para zero. Se você configurar um temporizador de expiração dentro do escopo do contrato, isso tecnicamente tornará a vida dos desenvolvedores mais fácil, mas tornará a economia mais difícil: 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 para resolver ao longo dos anos, incluindo propostas como "aluguel de blockchain" e "renovação". No final, combinámos as melhores partes das propostas e concentrámo-nos em duas categorias de "soluções conhecidas como as menos piores":
Solução para estados parcialmente expirados
Sugestões de expiração de estado baseadas no ciclo de endereço.
Expiração parcial de estado
Algumas propostas de estado expiradas seguem os mesmos princípios. Dividimos o estado em blocos. Todos armazenam permanentemente o "mapeamento de topo".
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.
13 gostos
Recompensa
13
7
Republicar
Partilhar
Comentar
0/400
Hash_Bandit
· 08-06 19:58
vi isto antes... como nos velhos tempos da mineração, quando otimizamos a sincronização do nó. o eth precisa de mais eficiência ao estilo da taxa de hash, para ser sincero
Ver originalResponder0
ILCollector
· 08-04 07:11
Sugere-se empacotar os dados com L2.
Ver originalResponder0
TokenomicsTrapper
· 08-03 21:09
chamei a atenção para este problema de inchaço há meses... espiral de morte clássica da dívida técnica a caminho
Ver originalResponder0
HackerWhoCares
· 08-03 21:09
O armazenamento em expansão ainda é um grande problema
Ver originalResponder0
DefiPlaybook
· 08-03 21:07
Analisando os dados, o problema da explosão de estado já afetou 87% dos nós na cadeia.
Vitalik analisa o futuro do desenvolvimento do Ethereum: Análise do plano The Purge
Vitalik: O possível futuro do Ethereum, The Purge
Um dos desafios enfrentados pelo Ethereum é que, por padrão, a expansão e a complexidade de qualquer protocolo de blockchain aumentam com o tempo. Isso acontece em dois lugares:
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 forma a sincronizar completamente com a rede. Isso resulta em uma carga e tempo de sincronização dos clientes que aumentam continuamente ao longo do 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, resultando em uma complexidade de código que aumenta com o tempo.
Para que o Ethereum possa se manter 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 características-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 contendo 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 se descentralizar completamente e remover a chave de atualização, eles precisam ter certeza de que suas dependências não serão atualizadas de uma maneira que as prejudique - especialmente o L1 em si.
Se decidirmos equilibrar essas duas demandas e minimizar ou reverter a gordura, complexidade e decadência, mantendo a continuidade, isso é absolutamente possível. Os organismos podem fazer isso: embora a maioria dos organismos envelheça com o tempo, alguns poucos sortudos não o fazem. Mesmo os sistemas sociais podem ter uma vida útil muito longa. Em alguns casos, o Ethereum já teve sucesso: a prova de trabalho desapareceu, o código de operação SELFDESTRUCT desapareceu na maior parte, e os nós da cadeia Beacon já armazenaram dados antigos por até seis meses. Descobrir esse caminho para o Ethereum de uma maneira mais geral e caminhar em direção a um resultado final de estabilidade a longo prazo é o desafio supremo para a escalabilidade a longo prazo do Ethereum, sustentabilidade técnica e até mesmo segurança.
A Purga: Objetivo principal.
Reduzir os requisitos de armazenamento do cliente ao reduzir ou eliminar a necessidade de cada nó armazenar permanentemente todos os registros históricos ou até mesmo o estado final.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Índice do artigo:
Histórico de expiração
Estado de expiração
Limpeza de características
Expiração do histórico
Resolve que problema?
Até o momento 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 várias 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 maioria 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 centenas de GB a cada ano.
O que é isso e como funciona?
Uma característica chave da simplificação do problema de armazenamento histórico é que, como cada bloco aponta para o bloco anterior através de links de hash (e outras estruturas), é suficiente que haja consenso sobre o atual para que haja consenso sobre o histórico. Desde que a rede alcance consenso sobre o bloco mais recente, qualquer bloco histórico, transação ou estado (saldo da conta, número aleatório, código, armazenamento) pode ser fornecido por qualquer participante individual, juntamente com uma prova 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 o histórico. Uma escolha natural é uma rede onde cada nó armazena apenas uma pequena parte dos dados. Esta é a forma como as redes de sementes operam há décadas: embora a rede armazene e distribua milhões de arquivos no total, cada participante armazena e distribui apenas alguns desses arquivos. Talvez contra a intuição, este método pode até não 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% do histórico, então cada dado será replicado 10.000 vezes - exatamente o mesmo fator de replicação que uma rede de 10.000 nós, onde cada nó armazena tudo.
Hoje, o Ethereum começou a se desvincular do modelo em que todos os nós armazenam permanentemente todo o histórico. Os blocos de consenso (ou seja, a parte relacionada ao consenso de prova de participação) 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 a longo prazo é estabelecer um período unificado (possivelmente 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, onde os dados antigos são armazenados de forma distribuída.
Códigos de apagamento podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. De fato, o Blob já implementou códigos de apagamento para suportar a amostragem de disponibilidade de dados. A solução mais simples provavelmente 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;
Rede de portal 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 deve ser ponderado?
O trabalho principal restante inclui a construção e integração de uma solução distribuída específica para armazenar históricos ----- pelo menos o histórico de execução, mas eventualmente incluindo consenso e blob. A solução mais simples é (i) simplesmente introduzir bibliotecas torrent existentes, bem como (ii) chamada solução nativa do Ethereum, a rede Portal. Assim que introduzirmos qualquer uma delas, poderemos abrir o EIP-4444. O EIP-4444 em si não requer um hard fork, mas realmente necessita de uma nova versão do protocolo de rede. Portanto, é valioso habilitá-lo para todos os clientes ao mesmo tempo, caso contrário, há o risco de que clientes falhem ao se conectar a outros nós, esperando baixar o histórico completo, mas na verdade não o obtendo.
A principal negociação envolve como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar dados históricos antigos amanhã e confiar em nós para replicar através de nós de arquivamento existentes e vários provedores centralizados. Isso é fácil, mas enfraquece a posição do Ethereum como um local de registro permanente. Uma abordagem mais difícil, mas mais segura, é primeiro construir e integrar uma rede torrent para armazenar o histórico de forma distribuída. Aqui, "o quanto nos esforçamos" tem duas dimensões:
Como nos esforçamos para garantir que o maior conjunto de nós realmente armazene todos os dados?
Qual é a profundidade da integração do armazenamento histórico no protocolo?
Uma abordagem extremamente paranoica para (1) envolveria a prova de custódia: exigir que cada validador de prova de participação armazenasse uma certa proporção de registros históricos e verificasse periodicamente, 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 o arquivo ERA que contém toda a história do Ethereum. Uma implementação mais completa envolveria realmente conectá-lo 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 disponíveis, eles possam fazê-lo através da sincronização direta da rede do portal.
Como interage com as outras partes do roteiro?
Se quisermos tornar a execução ou o início 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 aproximadamente 800 GB tornaram-se históricos. Apenas alcançando a ausência de estado e o EIP-4444 poderemos realizar a visão de executar um nó Ethereum em um smartwatch e configurá-lo em apenas alguns minutos.
A limitação do armazenamento histórico também torna a implementação de nós mais recentes do Ethereum mais viável, suportando apenas a versão mais recente do protocolo, o que os torna mais simples. Por exemplo, agora é possível remover com segurança muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram removidos. Agora que a transição para a prova de participação se tornou parte da história, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
Expiração do estado
Resolve que problema?
Mesmo que eliminemos a necessidade de armazenamento de histórico no cliente, a demanda de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, à medida que o estado continua a crescer: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, o que sobrecarregará para sempre os clientes Ethereum atuais e futuros.
O estado é "mais difícil" de "expirar" do que a história, porque a EVM foi fundamentalmente projetada 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, alguns acreditam que esse problema talvez não seja tão ruim assim: apenas classes de construtores de blocos dedicados precisam realmente armazenar estado, enquanto todos os outros nós (até mesmo aqueles que geram listas!) podem operar sem estado. No entanto, há uma opinião de que não queremos depender excessivamente da ausência de estado, e no final, poderemos querer permitir que o estado expire para manter a descentralização do Ethereum.
O que é, como funciona
Hoje, quando você cria um novo objeto de estado (isso pode acontecer de uma das três maneiras a seguir: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta usando código, (iii) configurando um slot de armazenamento que não foi tocado anteriormente), esse objeto de estado permanece nesse estado para sempre. Em vez disso, o que desejamos é que o objeto expire automaticamente ao longo do tempo. O desafio fundamental é fazer isso de uma forma que atinja três objetivos:
Eficiência: não é necessário um grande cálculo adicional para executar o processo de vencimento.
Facilidade de uso: se alguém entrar na caverna por 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, as aplicações que atualmente estão rígidas e não atualizadas devem continuar a funcionar normalmente.
Não atender a 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 escrita) e ter um processo que percorre os estados para remover objetos de estado com data de expiração. No entanto, isso introduz cálculos adicionais (e 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 situações limites onde os valores armazenados às vezes são redefinidos para zero. Se você configurar um temporizador de expiração dentro do escopo do contrato, isso tecnicamente tornará a vida dos desenvolvedores mais fácil, mas tornará a economia mais difícil: 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 para resolver ao longo dos anos, incluindo propostas como "aluguel de blockchain" e "renovação". No final, combinámos as melhores partes das propostas e concentrámo-nos em duas categorias de "soluções conhecidas como as menos piores":
Expiração parcial de estado
Algumas propostas de estado expiradas seguem os mesmos princípios. Dividimos o estado em blocos. Todos armazenam permanentemente o "mapeamento de topo".