Um dos desafios que o Ethereum enfrenta é que, por padrão, a expansão e a complexidade de qualquer protocolo de blockchain tendem a aumentar com o tempo. Isso acontece de duas maneiras:
Dados históricos: Qualquer transação realizada em qualquer momento da história e qualquer conta criada deve ser armazenada permanentemente por todos os clientes e ser baixada por qualquer novo cliente, de forma a sincronizar completamente com a rede. Isso resultará em um aumento contínuo na carga dos clientes e no tempo de sincronização ao longo do tempo, mesmo que a capacidade da cadeia permaneça inalterada.
Funcionalidade do protocolo: adicionar novas funcionalidades é muito mais fácil do que remover funcionalidades antigas, resultando em uma complexidade de código que aumenta ao longo do tempo.
Para que o Ethereum possa se manter a longo prazo, precisamos aplicar uma forte pressão contrária a 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 chamada de transação, ou um contrato inteligente que contenha 1.000.000 de dólares na cadeia, entrar em uma caverna por dez anos e, ao sair, descobrir que ele 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 destrua - especialmente o L1 em si.
Se decidirmos firmemente equilibrar essas duas demandas e minimizar ou reverter a obesidade, a complexidade e a degradação enquanto mantemos a continuidade, isso é absolutamente possível. Os organismos podem fazer isso: embora a maioria dos organismos envelheça ao longo do tempo, alguns poucos sortudos não o fazem. Mesmo os sistemas sociais podem ter uma longevidade 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 cadeia de beacon armazenaram dados antigos por até seis meses. Encontrar este 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 final para a escalabilidade a longo prazo do Ethereum, a sustentabilidade técnica e até mesmo a segurança.
The Purge: Principal objetivo.
Reduzir os requisitos de armazenamento do cliente, reduzindo ou eliminando 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 de expiração
Estado de expiração
Limpeza de recursos
Histórico de expiração
Que problema resolve?
Até a data da redação deste artigo, um nó Ethereum totalmente sincronizado requer aproximadamente 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 de forma alguma, o tamanho do nó continuará a aumentar em centenas de GB a cada ano.
O que é, como funciona?
Uma característica chave de simplificação do problema de armazenamento histórico é que, como cada bloco aponta para o bloco anterior através de ligações 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 histórico ou transação ou estado (saldo da conta, número aleatório, código, armazenamento) pode ser fornecido por qualquer participante individual, bem como a 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 têm funcionado ao longo das 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 de uma rede de 10.000 nós, onde cada nó armazena todo o conteúdo.
Atualmente, o Ethereum já começou a se afastar 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 de longo prazo é estabelecer um período unificado (possivelmente cerca de 18 dias), durante o qual cada nó é responsável por armazenar todo o conteúdo, e depois estabelecer uma rede ponto a ponto composta por nós do Ethereum, que armazena dados antigos de forma distribuída.
Os códigos de eliminação podem ser usados para aumentar a robustez, mantendo o mesmo fator de replicação. De fato, o Blob já foi codificado para suportar amostragem de disponibilidade de dados. A solução mais simples provavelmente será reutilizar esses códigos de eliminação e colocar os dados de execução e consenso do bloco também dentro do blob.
Qual é a relação com as pesquisas existentes?
EIP-4444；
Torrents e EIP-4444；
Portal Network;
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 ponderado?
O trabalho principal restante inclui a construção e integração de uma solução distribuída concreta 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 bibliotecas torrent existentes, assim como (ii) uma solução nativa do Ethereum chamada Portal Network. Uma vez que qualquer um deles seja introduzido, podemos 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 os clientes falharem ao se conectar a outros nós, esperando baixar o histórico completo, mas na verdade não o obtendo.
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 confiar em nós para replicar com nós de arquivamento existentes e vários provedores centralizados. Isso é fácil, mas compromete a posição do Ethereum como um local de registro permanente. Um caminho mais difícil, mas mais seguro, é primeiro construir e integrar uma rede torrent para armazenar registros 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 armazena todos os dados?
Qual é a profundidade da integração do armazenamento histórico no protocolo?
Um método extremamente obsessivo para (1) envolveria prova de custódia: na prática, exigindo que cada validador de prova de participação armazenasse uma certa proporção de registros históricos e verificasse regularmente de forma criptográfica se o faziam. Um método mais brando seria estabelecer um padrão voluntário para a percentagem histórica armazenada por cada cliente.
Para (2), a implementação básica envolve apenas o trabalho que já foi concluído hoje: o Portal já armazenou um arquivo ERA que contém toda a história do Ethereum. Uma implementação mais completa envolverá 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 que a execução ou o início de nós seja extremamente fácil, então reduzir os requisitos 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, e os restantes 800 GB tornaram-se históricos. Apenas alcançando a ausência de estado e o EIP-4444 é que se pode 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 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 é possível excluir 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 história, os clientes podem excluir com segurança todo o código relacionado à prova de trabalho.
Estado de expiração
Que problema resolve?
Mesmo que tenhamos eliminado a necessidade de armazenamento de histórico no cliente, a necessidade de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, uma vez que o estado continua a crescer: saldos de contas e números aleatórios, códigos de contratos e armazenamento de contratos. Os usuários podem pagar uma taxa única, assim, trazendo uma carga para os clientes de Ethereum atuais e futuros.
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, alguns argumentam que este problema pode não ser tão ruim: apenas classes de construtores de blocos especializados 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, podemos desejar que o estado expire para manter a descentralização do Ethereum.
O que é, como funciona
Hoje, quando você cria um novo objeto de estado (o que pode acontecer de uma das três maneiras: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta com código, (iii) definindo 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 é necessário um grande volume 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 ao ETH, ERC20, NFT, posições de CDP...
Amigabilidade para desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento totalmente desconhecido. Além disso, as aplicações que estão atualmente 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 de leitura ou gravação), e ter um processo que percorre o estado para remover objetos de estado com data de expiração. No entanto, isso introduz cálculos adicionais (mesmo exigências de armazenamento), e com certeza não atenderá aos requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre casos extremos que envolvem valores de armazenamento que às vezes são redefinidos para zero. Se você definir 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 de armazenamento contínuo para os usuários.
Estes são problemas que a comunidade central de desenvolvedores do Ethereum tem trabalhado para resolver ao longo dos anos, incluindo propostas como "renda da 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 piores":
Solução para estados parcialmente expirados
Recomendações de expiração de estado com base no ciclo de endereço.
Expiração parcial do estado
Algumas propostas de estado de expiração 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ó serão armazenados se esses dados tiverem sido acessados recentemente. Existe um mecanismo de "ressurreição" que se não forem mais armazenados.
A principal diferença entre essas propostas é: (i) como definimos "recente" e (ii) como nós
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) 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.
9 Curtidas
Recompensa
9
3
Repostar
Compartilhar
Comentário
0/400
NoodlesOrTokens
· 16h atrás
na cadeia塞的太满啦 赶紧清理
Ver originalResponder0
PumpDetector
· 17h atrás
dinheiro inteligente tem acompanhado essa coisa de purgação... exatamente o que avisámos em 2017, para ser sincero.
Ver originalResponder0
LiquidatorFlash
· 17h atrás
na cadeia histórico de dados +3.47T, risco bombear, faça a cobertura antes de zerar
Ethereum O plano Purge: expiração histórica e simplificação de estado contra a expansão da complexidade
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 tendem a aumentar com o tempo. Isso acontece de duas maneiras:
Dados históricos: Qualquer transação realizada em qualquer momento da história e qualquer conta criada deve ser armazenada permanentemente por todos os clientes e ser baixada por qualquer novo cliente, de forma a sincronizar completamente com a rede. Isso resultará em um aumento contínuo na carga dos clientes e no tempo de sincronização ao longo do tempo, mesmo que a capacidade da cadeia permaneça inalterada.
Funcionalidade do protocolo: adicionar novas funcionalidades é muito mais fácil do que remover funcionalidades antigas, resultando em uma complexidade de código que aumenta ao longo do tempo.
Para que o Ethereum possa se manter a longo prazo, precisamos aplicar uma forte pressão contrária a 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 chamada de transação, ou um contrato inteligente que contenha 1.000.000 de dólares na cadeia, entrar em uma caverna por dez anos e, ao sair, descobrir que ele 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 destrua - especialmente o L1 em si.
Se decidirmos firmemente equilibrar essas duas demandas e minimizar ou reverter a obesidade, a complexidade e a degradação enquanto mantemos a continuidade, isso é absolutamente possível. Os organismos podem fazer isso: embora a maioria dos organismos envelheça ao longo do tempo, alguns poucos sortudos não o fazem. Mesmo os sistemas sociais podem ter uma longevidade 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 cadeia de beacon armazenaram dados antigos por até seis meses. Encontrar este 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 final para a escalabilidade a longo prazo do Ethereum, a sustentabilidade técnica e até mesmo a segurança.
The Purge: Principal objetivo.
Reduzir os requisitos de armazenamento do cliente, reduzindo ou eliminando 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 de expiração
Estado de expiração
Limpeza de recursos
Histórico de expiração
Que problema resolve?
Até a data da redação deste artigo, um nó Ethereum totalmente sincronizado requer aproximadamente 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 de forma alguma, o tamanho do nó continuará a aumentar em centenas de GB a cada ano.
O que é, como funciona?
Uma característica chave de simplificação do problema de armazenamento histórico é que, como cada bloco aponta para o bloco anterior através de ligações 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 histórico ou transação ou estado (saldo da conta, número aleatório, código, armazenamento) pode ser fornecido por qualquer participante individual, bem como a 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 têm funcionado ao longo das 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 de uma rede de 10.000 nós, onde cada nó armazena todo o conteúdo.
Atualmente, o Ethereum já começou a se afastar 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 de longo prazo é estabelecer um período unificado (possivelmente cerca de 18 dias), durante o qual cada nó é responsável por armazenar todo o conteúdo, e depois estabelecer uma rede ponto a ponto composta por nós do Ethereum, que armazena dados antigos de forma distribuída.
Os códigos de eliminação podem ser usados para aumentar a robustez, mantendo o mesmo fator de replicação. De fato, o Blob já foi codificado para suportar amostragem de disponibilidade de dados. A solução mais simples provavelmente será reutilizar esses códigos de eliminação e colocar os dados de execução e consenso do bloco também dentro do blob.
Qual é a relação com as pesquisas existentes?
EIP-4444；
Torrents e EIP-4444；
Portal Network;
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 ponderado?
O trabalho principal restante inclui a construção e integração de uma solução distribuída concreta 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 bibliotecas torrent existentes, assim como (ii) uma solução nativa do Ethereum chamada Portal Network. Uma vez que qualquer um deles seja introduzido, podemos 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 os clientes falharem ao se conectar a outros nós, esperando baixar o histórico completo, mas na verdade não o obtendo.
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 confiar em nós para replicar com nós de arquivamento existentes e vários provedores centralizados. Isso é fácil, mas compromete a posição do Ethereum como um local de registro permanente. Um caminho mais difícil, mas mais seguro, é primeiro construir e integrar uma rede torrent para armazenar registros 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 armazena todos os dados?
Qual é a profundidade da integração do armazenamento histórico no protocolo?
Um método extremamente obsessivo para (1) envolveria prova de custódia: na prática, exigindo que cada validador de prova de participação armazenasse uma certa proporção de registros históricos e verificasse regularmente de forma criptográfica se o faziam. Um método mais brando seria estabelecer um padrão voluntário para a percentagem histórica armazenada por cada cliente.
Para (2), a implementação básica envolve apenas o trabalho que já foi concluído hoje: o Portal já armazenou um arquivo ERA que contém toda a história do Ethereum. Uma implementação mais completa envolverá 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 que a execução ou o início de nós seja extremamente fácil, então reduzir os requisitos 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, e os restantes 800 GB tornaram-se históricos. Apenas alcançando a ausência de estado e o EIP-4444 é que se pode 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 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 é possível excluir 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 história, os clientes podem excluir com segurança todo o código relacionado à prova de trabalho.
Estado de expiração
Que problema resolve?
Mesmo que tenhamos eliminado a necessidade de armazenamento de histórico no cliente, a necessidade de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, uma vez que o estado continua a crescer: saldos de contas e números aleatórios, códigos de contratos e armazenamento de contratos. Os usuários podem pagar uma taxa única, assim, trazendo uma carga para os clientes de Ethereum atuais e futuros.
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, alguns argumentam que este problema pode não ser tão ruim: apenas classes de construtores de blocos especializados 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, podemos desejar que o estado expire para manter a descentralização do Ethereum.
O que é, como funciona
Hoje, quando você cria um novo objeto de estado (o que pode acontecer de uma das três maneiras: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta com código, (iii) definindo 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 é necessário um grande volume 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 ao ETH, ERC20, NFT, posições de CDP...
Amigabilidade para desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento totalmente desconhecido. Além disso, as aplicações que estão atualmente 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 de leitura ou gravação), e ter um processo que percorre o estado para remover objetos de estado com data de expiração. No entanto, isso introduz cálculos adicionais (mesmo exigências de armazenamento), e com certeza não atenderá aos requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre casos extremos que envolvem valores de armazenamento que às vezes são redefinidos para zero. Se você definir 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 de armazenamento contínuo para os usuários.
Estes são problemas que a comunidade central de desenvolvedores do Ethereum tem trabalhado para resolver ao longo dos anos, incluindo propostas como "renda da 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 piores":
Expiração parcial do estado
Algumas propostas de estado de expiração 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ó serão armazenados se esses dados tiverem sido acessados recentemente. Existe um mecanismo de "ressurreição" que se não forem mais armazenados.
A principal diferença entre essas propostas é: (i) como definimos "recente" e (ii) como nós