Um desafio 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 em dois aspectos:
Dados históricos: Todas as transações realizadas e todas as contas criadas em qualquer momento da história devem ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente, de modo a serem totalmente sincronizadas com a rede. Isso leva a um aumento contínuo da carga do cliente e do 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 sustentar-se a longo prazo, precisamos aplicar uma forte pressão contrária a estas duas tendências, reduzindo a complexidade e a expansão ao longo do tempo. Mas, ao mesmo tempo, precisamos manter 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 as DApps possam descentralizar-se completamente e remover as chaves de atualização, elas 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 firmemente equilibrar essas duas necessidades e minimizar ou reverter a gordura, complexidade e 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 sistemas sociais podem ter uma longevidade extremamente longa. Em certos casos, o Ethereum já teve sucesso: a prova de trabalho desapareceu, o código de operação SELFDESTRUCT desapareceu na sua maior parte, e os nós da cadeia de beacon armazenaram dados antigos por até seis meses. Encontrar esse caminho para o Ethereum de uma maneira mais genérica e caminhar em direção a um resultado final estável a longo prazo é o desafio supremo para a escalabilidade a longo prazo do Ethereum, a sustentabilidade técnica e até mesmo a segurança.
The Purge: Objetivo Principal
Reduzir os requisitos de armazenamento do cliente, eliminando ou diminuindo a necessidade de cada nó armazenar permanentemente todos os históricos ou mesmo o estado final.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Expiração do histórico
resolve que problema?
Até o momento da redação deste artigo, um nó Ethereum totalmente sincronizado precisa de cerca de 1,1 TB de espaço em disco para executar o cliente, além de necessitar 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, transações e recibos históricos, dos quais a maioria já tem vários anos. Isso significa que, mesmo que o limite de Gas não aumente, o tamanho do nó continuará a aumentar em várias centenas de GB a cada ano.
O que é isso, como funciona?
Uma característica chave de simplificação do problema de armazenamento histórico é que, uma vez que cada bloco aponta para o bloco anterior através de links 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 (saldos de contas, números aleatórios, código, armazenamento) pode ser fornecido por qualquer participante individual, juntamente com a prova Merkle, e essa prova permite que qualquer outra pessoa a verifique quanto à 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 durante 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, pudermos construir uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% do histórico, então cada dado será copiado 10.000 vezes - exatamente o mesmo fator de cópia que uma rede de 10.000 nós, onde cada nó armazena tudo.
Atualmente, o Ethereum começou a se afastar do modelo onde 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 construir uma rede ponto a ponto composta por nós do Ethereum, que armazena 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. Na verdade, o Blob já foi codificado com 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 também colocar a execução e os dados do bloco de consenso dentro do blob.
tem alguma relação com as pesquisas existentes?
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 ponderado?
O trabalho principal restante inclui a construção e integração de uma solução distribuída concreta para armazenar registros históricos------pelo menos os registros de execução, mas eventualmente também incluindo consenso e blob. A solução mais simples é (i) simplesmente introduzir bibliotecas torrent existentes, bem como (ii) uma solução nativa da Ethereum chamada Portal Network. Assim que qualquer uma delas for introduzida, podemos 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 habilitá-lo para todos os clientes ao mesmo tempo, caso contrário, há o risco de falha dos clientes por se conectarem a outros nós esperando baixar o histórico completo, mas na verdade não o obtiverem.
O principal compromisso envolve como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar histórico antigo amanhã e confiar em nós de arquivamento existentes e vários provedores centralizados para replicação. É fácil, mas enfraquece a posição do Ethereum como um lugar permanente de registro. Um caminho mais difícil, mas mais seguro, é primeiro construir e integrar uma rede de torrent que armazena o histórico de forma distribuída. Aqui, há duas dimensões para "como trabalhamos duro":
Como nos esforçamos para garantir que o maior conjunto de nós realmente armazene todos os dados?
Quão profunda é a integração do armazenamento histórico no protocolo?
Uma abordagem extremista e obsessiva para (1) envolveria a prova de custódia: exigir efetivamente 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 faz. Uma abordagem mais suave seria estabelecer um padrão voluntário para a percentagem de histórico 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 envolveria realmente conectá-lo ao processo de sincronização, de forma que, se alguém quisesse 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 poderiam fazê-lo através da sincronização direta com a rede do portal.
Como interage com as outras partes do roteiro?
Se quisermos que a execução ou inicialização de nós seja extremamente fácil, então reduzir a necessidade de armazenamento histórico pode ser considerado mais importante do que a sem estado: dos 1,1 TB necessários para o nó, cerca de 300 GB são estado, e os restantes cerca de 800 GB tornaram-se históricos. Apenas com a realização da sem estado e do EIP-4444 será possível alcançar 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 é seguro remover muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram eliminados. Dado que a transição para a prova de participação se tornou histórica, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
Expiração do estado
resolve que problema?
Mesmo que tenhamos eliminado a necessidade de armazenar o histórico no cliente, a demanda de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, devido ao crescimento contínuo do estado: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, que assim traz um fardo permanente para os clientes de Ethereum, tanto no presente quanto no futuro.
O estado é mais difícil de "expirar" do que a história, porque o EVM foi projetado 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 ruim: apenas classes de construtores de bloco especializadas precisam realmente armazenar o estado, enquanto todos os outros nós (até mesmo aqueles que geram listas!) podem funcionar sem estado. No entanto, há uma perspectiva de que não queremos depender demais da ausência de estado; no final, podemos querer tornar o estado obsoleto 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 usando código, (iii) configurando um slot de armazenamento que nunca foi tocado anteriormente), 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 são necessários muitos cálculos adicionais para executar o processo de vencimento.
Facilidade de uso: Se alguém entrar na caverna durante cinco anos e voltar, não deve perder o acesso a posições de ETH, ERC20, NFT e CDP...
Amizade com 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 acontecer automaticamente a qualquer momento durante a leitura ou gravação), 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é requisitos de armazenamento), e com certeza não atenderá aos requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre situações limite 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 tornará a vida do desenvolvedor mais fácil, mas tornará a economia mais difícil: os desenvolvedores devem considerar como "transferir" os custos de armazenamento contínuos para os usuários.
Estes são problemas que a comunidade de desenvolvimento central 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 o estado expirado
Sugestões de expiração de estado baseadas no ciclo de endereços.
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", onde os blocos podem estar vazios ou não. Os dados em cada bloco só são armazenados se foram acessados recentemente. Existe um mecanismo de "ressurreição" que, se não estiver mais armazenado.
A principal diferença entre estas propostas é: (i) como definimos "recente", e (ii) eu
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.
15 Curtidas
Recompensa
15
6
Compartilhar
Comentário
0/400
OnchainGossiper
· 2h atrás
A sincronização do cliente está tão lenta que eu estou prestes a vomitar.
Ver originalResponder0
MidnightSnapHunter
· 07-26 22:22
Vitalik Buterin finalmente vai liquidar?
Ver originalResponder0
PriceOracleFairy
· 07-24 21:24
o bloat do protocolo ngl é real... pesadelos de escalabilidade me mantêm acordado às 3 da manhã fr
Ver originalResponder0
WhaleWatcher
· 07-24 21:14
Vitalik Buterin, ajuda-me a calcular os custos de armazenamento.
Ver originalResponder0
Degen4Breakfast
· 07-24 21:00
Diga adeus ao inchaço do sistema, ok?
Ver originalResponder0
FloorPriceWatcher
· 07-24 20:58
Não amo novas funcionalidades, amo o armazenamento limpo.
Vitalik fala sobre The Purge: o caminho para a sustentabilidade a longo prazo do Ethereum
Vitalik: O possível futuro do Ethereum, The Purge
Um desafio 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 em dois aspectos:
Dados históricos: Todas as transações realizadas e todas as contas criadas em qualquer momento da história devem ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente, de modo a serem totalmente sincronizadas com a rede. Isso leva a um aumento contínuo da carga do cliente e do 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 sustentar-se a longo prazo, precisamos aplicar uma forte pressão contrária a estas duas tendências, reduzindo a complexidade e a expansão ao longo do tempo. Mas, ao mesmo tempo, precisamos manter 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 as DApps possam descentralizar-se completamente e remover as chaves de atualização, elas 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 firmemente equilibrar essas duas necessidades e minimizar ou reverter a gordura, complexidade e 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 sistemas sociais podem ter uma longevidade extremamente longa. Em certos casos, o Ethereum já teve sucesso: a prova de trabalho desapareceu, o código de operação SELFDESTRUCT desapareceu na sua maior parte, e os nós da cadeia de beacon armazenaram dados antigos por até seis meses. Encontrar esse caminho para o Ethereum de uma maneira mais genérica e caminhar em direção a um resultado final estável a longo prazo é o desafio supremo para a escalabilidade a longo prazo do Ethereum, a sustentabilidade técnica e até mesmo a segurança.
The Purge: Objetivo Principal
Reduzir os requisitos de armazenamento do cliente, eliminando ou diminuindo a necessidade de cada nó armazenar permanentemente todos os históricos ou mesmo o estado final.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Expiração do histórico
resolve que problema?
Até o momento da redação deste artigo, um nó Ethereum totalmente sincronizado precisa de cerca de 1,1 TB de espaço em disco para executar o cliente, além de necessitar 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, transações e recibos históricos, dos quais a maioria já tem vários anos. Isso significa que, mesmo que o limite de Gas não aumente, o tamanho do nó continuará a aumentar em várias centenas de GB a cada ano.
O que é isso, como funciona?
Uma característica chave de simplificação do problema de armazenamento histórico é que, uma vez que cada bloco aponta para o bloco anterior através de links 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 (saldos de contas, números aleatórios, código, armazenamento) pode ser fornecido por qualquer participante individual, juntamente com a prova Merkle, e essa prova permite que qualquer outra pessoa a verifique quanto à 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 durante 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, pudermos construir uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% do histórico, então cada dado será copiado 10.000 vezes - exatamente o mesmo fator de cópia que uma rede de 10.000 nós, onde cada nó armazena tudo.
Atualmente, o Ethereum começou a se afastar do modelo onde 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 construir uma rede ponto a ponto composta por nós do Ethereum, que armazena 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. Na verdade, o Blob já foi codificado com 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 também colocar a execução e os dados do bloco de consenso dentro do blob.
tem alguma relação com as pesquisas existentes?
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 registros históricos------pelo menos os registros de execução, mas eventualmente também incluindo consenso e blob. A solução mais simples é (i) simplesmente introduzir bibliotecas torrent existentes, bem como (ii) uma solução nativa da Ethereum chamada Portal Network. Assim que qualquer uma delas for introduzida, podemos 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 habilitá-lo para todos os clientes ao mesmo tempo, caso contrário, há o risco de falha dos clientes por se conectarem a outros nós esperando baixar o histórico completo, mas na verdade não o obtiverem.
O principal compromisso envolve como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar histórico antigo amanhã e confiar em nós de arquivamento existentes e vários provedores centralizados para replicação. É fácil, mas enfraquece a posição do Ethereum como um lugar permanente de registro. Um caminho mais difícil, mas mais seguro, é primeiro construir e integrar uma rede de torrent que armazena o histórico de forma distribuída. Aqui, há duas dimensões para "como trabalhamos duro":
Como nos esforçamos para garantir que o maior conjunto de nós realmente armazene todos os dados?
Quão profunda é a integração do armazenamento histórico no protocolo?
Uma abordagem extremista e obsessiva para (1) envolveria a prova de custódia: exigir efetivamente 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 faz. Uma abordagem mais suave seria estabelecer um padrão voluntário para a percentagem de histórico 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 envolveria realmente conectá-lo ao processo de sincronização, de forma que, se alguém quisesse 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 poderiam fazê-lo através da sincronização direta com a rede do portal.
Como interage com as outras partes do roteiro?
Se quisermos que a execução ou inicialização de nós seja extremamente fácil, então reduzir a necessidade de armazenamento histórico pode ser considerado mais importante do que a sem estado: dos 1,1 TB necessários para o nó, cerca de 300 GB são estado, e os restantes cerca de 800 GB tornaram-se históricos. Apenas com a realização da sem estado e do EIP-4444 será possível alcançar 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 é seguro remover muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram eliminados. Dado que a transição para a prova de participação se tornou histórica, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
Expiração do estado
resolve que problema?
Mesmo que tenhamos eliminado a necessidade de armazenar o histórico no cliente, a demanda de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, devido ao crescimento contínuo do estado: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, que assim traz um fardo permanente para os clientes de Ethereum, tanto no presente quanto no futuro.
O estado é mais difícil de "expirar" do que a história, porque o EVM foi projetado 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 ruim: apenas classes de construtores de bloco especializadas precisam realmente armazenar o estado, enquanto todos os outros nós (até mesmo aqueles que geram listas!) podem funcionar sem estado. No entanto, há uma perspectiva de que não queremos depender demais da ausência de estado; no final, podemos querer tornar o estado obsoleto 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 usando código, (iii) configurando um slot de armazenamento que nunca foi tocado anteriormente), 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 são necessários muitos cálculos adicionais para executar o processo de vencimento.
Facilidade de uso: Se alguém entrar na caverna durante cinco anos e voltar, não deve perder o acesso a posições de ETH, ERC20, NFT e CDP...
Amizade com 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 acontecer automaticamente a qualquer momento durante a leitura ou gravação), 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é requisitos de armazenamento), e com certeza não atenderá aos requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre situações limite 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 tornará a vida do desenvolvedor mais fácil, mas tornará a economia mais difícil: os desenvolvedores devem considerar como "transferir" os custos de armazenamento contínuos para os usuários.
Estes são problemas que a comunidade de desenvolvimento central 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", onde os blocos podem estar vazios ou não. Os dados em cada bloco só são armazenados se foram acessados recentemente. Existe um mecanismo de "ressurreição" que, se não estiver mais armazenado.
A principal diferença entre estas propostas é: (i) como definimos "recente", e (ii) eu