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 em dois lugares:
Dados históricos: Qualquer transação realizada e qualquer conta criada em qualquer momento da história deve ser armazenada permanentemente por todos os clientes e baixada por qualquer novo cliente, de modo a sincronizar completamente com a rede. Isso resultará em 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.
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 ser mantido a longo prazo, precisamos exercer 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 contendo 1 milhão 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 as chaves 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 nos determinarmos a equilibrar essas duas necessidades e a minimizar ou reverter a sobrecarga, a complexidade e o declínio, enquanto mantemos 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 certos 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 forma mais geral 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: principal objetivo.
Reduzir os requisitos de armazenamento do cliente, eliminando ou reduzindo 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 ( histórico de registros expirados )
Estado de expiração( estado de expiração)
Limpeza de recursos( limpeza de características)
Expiração do histórico
Resolve que problema?
Até a data da redação deste artigo, um nó Ethereum completamente sincronizado requer aproximadamente 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 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 crescer 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, como cada bloco está vinculado ao bloco anterior por meio de hashes ( 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 conta, números aleatórios, código, armazenamento ) podem ser fornecidos por qualquer participante único, bem como 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-de-N, enquanto o histórico é um modelo de confiança N-de-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 por décadas: embora a rede armazene e distribua milhões de arquivos, cada participante armazena e distribui apenas alguns deles. Talvez contra a intuição, este método pode até não reduzir a robustez dos dados. Se, ao tornar a execuçã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 - o que é 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 todo o histórico. O bloco de consenso ( está relacionado à parte do consenso de prova de participação que armazena apenas cerca de 6 meses. Blob armazena apenas cerca de 18 dias. O EIP-4444 visa introduzir um período de armazenamento de um ano para blocos históricos e recibos. O objetivo de longo prazo é estabelecer um período unificado que ) pode durar cerca de 18 dias (, durante o qual cada nó é responsável por armazenar todo o conteúdo, e então estabelecer uma rede peer-to-peer composta por nós do Ethereum para armazenar dados antigos de maneira distribuída.
![Vitalik: O possível futuro do Ethereum, The Purge])ian/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg(
Códigos de eliminação podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. De fato, o Blob já utilizou códigos de eliminação para suportar amostragem de disponibilidade de dados. A solução mais simples provavelmente será reutilizar esses códigos de eliminação e também colocar os dados de execução e de consenso em blob.
) tem alguma ligação com a pesquisa atual?
EIP-4444;
Torrents e EIP-4444;
Rede de portal;
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 específica para armazenar o histórico ------ pelo menos o histórico de execução, mas eventualmente também inclui o consenso e blob. A solução mais simples é ###i( simplesmente introduzir uma biblioteca torrent existente, bem como )ii( chamada solução nativa de Ethereum chamada Portal Network. Uma vez que qualquer uma delas é 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 ativá-lo para todos os clientes ao mesmo tempo, caso contrário, existe o risco de falhas nos clientes por se conectarem a outros nós esperando baixar o histórico completo, mas na verdade não obtendo-o.
As principais compensaçõ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 usando nós de arquivo existentes e vários provedores centralizados. Isso é fácil, mas enfraquece 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 o histórico de forma distribuída. Aqui, "quão duro 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 extremista e paranoica para ) envolveria a prova de custódia: exigindo, na prática, que cada validador de prova de participação armazenasse uma certa proporção de histórico e verificasse regularmente, de forma criptográfica, se o faz. Uma abordagem mais branda seria estabelecer um padrão voluntário para a porcentagem 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 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 arquivamento, mesmo que não haja outros nós de arquivamento online, eles possam alcançá-lo diretamente através da sincronização da rede do portal.
( Como interage com as outras partes do roteiro?
Se quisermos tornar a execução ou o arranque de nós 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, enquanto os restantes cerca de 800 GB são 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 relógios inteligentes e configurar em apenas alguns minutos.
A limitação do armazenamento histórico também 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, uma vez que os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram todos removidos. Agora que a transição para a prova de participação se tornou uma história, os clientes podem excluir com segurança todo o código relacionado à prova de trabalho.
![Vitalik: O possível futuro do Ethereum, The Purge])ian/2024/10/27/images/b3e2c5d4e7e1d40234643b84b51b43c1.jpg###
Expiração do estado
( Resolve que problema?
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, 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, transferindo assim um ônus para os clientes de Ethereum atuais e futuros.
O estado é mais difícil de "expirar" do que a história, porque o EVM foi fundamentalmente projetado 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 sem estado, alguns acreditam que esse problema talvez não seja tão ruim: apenas as classes de construtores de blocos especializados precisam realmente armazenar o estado, enquanto todos os outros nós ), incluindo até mesmo a geração de listas! ###, podem operar sem estado. No entanto, há uma opinião de que não queremos depender demais da sem estado, e que, no final, talvez queiramos fazer o estado expirar para manter a descentralização do Ethereum.
( O que é, como funciona?
Hoje, quando você cria um novo objeto de estado, ) pode ocorrer de uma das seguintes três maneiras: ### i ( enviar ETH para uma nova conta, ( ii ) criar uma nova conta usando código, ( iii ) configurar um slot de armazenamento que nunca foi tocado (, e 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 os 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 numa caverna por cinco anos e voltar, não deve perder o acesso às posições de ETH, ERC20, NFT, 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 rigidificadas e não atualizadas devem continuar a funcionar normalmente.
Não satisfazer esses objetivos torna fácil resolver os problemas. Por exemplo, você pode fazer com que cada objeto de estado também armazene um contador de data de expiração. O ) pode ser estendido queimando ETH, o que pode ocorrer automaticamente a qualquer momento durante a leitura ou escrita, e há um processo de percorrer os estados para remover objetos de estado com data de expiração. No entanto, isso introduz requisitos de cálculo e até mesmo de armazenamento adicionais, e com certeza não pode satisfazer os requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre situações limite que envolvem valores de armazenamento que à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 "transmitir" 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, combinamos as melhores partes das propostas e nos concentramos em duas categorias de "soluções conhecidas como as menos ruins":
Solução para estados parcialmente expirados
Sugestão de expiração de estado baseada no ciclo de endereço.
) Expiração parcial do estado
Algumas propostas de estado expirado seguem os mesmos princípios. Dividimos o estado em blocos. Cada um armazena permanentemente o "mapeamento superior", onde os blocos estão 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 for mais armazenado
 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.
10 gostos
Recompensa
10
6
Partilhar
Comentar
0/400
SignatureVerifier
· 16h atrás
tecnicamente falando, bastante preocupado com a insuficiência de verificações de validação neste mecanismo de purga... requer uma auditoria de segurança minuciosa, para ser honesto
Ver originalResponder0
UnluckyLemur
· 08-03 10:23
Imposto sobre a moeda 100 moedas é suficiente
Ver originalResponder0
DegenApeSurfer
· 08-03 10:22
É tão difícil aliviar a carga, não é?
Ver originalResponder0
OldLeekNewSickle
· 08-03 10:20
Reduzir os dados da cadeia, ou são dados de fazer as pessoas de parvas? O velho idiota diz que não entende.
Ver originalResponder0
NonFungibleDegen
· 08-03 10:18
ngmi com esse inchaço ser... purgar ou estamos todos mal fr fr
Ethereum The Purge plano: Gota de requisitos de armazenamento e simplificação da complexidade do protocolo
O possível futuro do Ethereum: A Purga
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 em dois lugares:
Dados históricos: Qualquer transação realizada e qualquer conta criada em qualquer momento da história deve ser armazenada permanentemente por todos os clientes e baixada por qualquer novo cliente, de modo a sincronizar completamente com a rede. Isso resultará em 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.
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 ser mantido a longo prazo, precisamos exercer 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 contendo 1 milhão 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 as chaves 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 nos determinarmos a equilibrar essas duas necessidades e a minimizar ou reverter a sobrecarga, a complexidade e o declínio, enquanto mantemos 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 certos 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 forma mais geral 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: principal objetivo.
Reduzir os requisitos de armazenamento do cliente, eliminando ou reduzindo 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 ( histórico de registros expirados )
Estado de expiração( estado de expiração)
Limpeza de recursos( limpeza de características)
Expiração do histórico
Resolve que problema?
Até a data da redação deste artigo, um nó Ethereum completamente sincronizado requer aproximadamente 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 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 crescer 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, como cada bloco está vinculado ao bloco anterior por meio de hashes ( 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 conta, números aleatórios, código, armazenamento ) podem ser fornecidos por qualquer participante único, bem como 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-de-N, enquanto o histórico é um modelo de confiança N-de-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 por décadas: embora a rede armazene e distribua milhões de arquivos, cada participante armazena e distribui apenas alguns deles. Talvez contra a intuição, este método pode até não reduzir a robustez dos dados. Se, ao tornar a execuçã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 - o que é 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 todo o histórico. O bloco de consenso ( está relacionado à parte do consenso de prova de participação que armazena apenas cerca de 6 meses. Blob armazena apenas cerca de 18 dias. O EIP-4444 visa introduzir um período de armazenamento de um ano para blocos históricos e recibos. O objetivo de longo prazo é estabelecer um período unificado que ) pode durar cerca de 18 dias (, durante o qual cada nó é responsável por armazenar todo o conteúdo, e então estabelecer uma rede peer-to-peer composta por nós do Ethereum para armazenar dados antigos de maneira distribuída.
![Vitalik: O possível futuro do Ethereum, The Purge])ian/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg(
Códigos de eliminação podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. De fato, o Blob já utilizou códigos de eliminação para suportar amostragem de disponibilidade de dados. A solução mais simples provavelmente será reutilizar esses códigos de eliminação e também colocar os dados de execução e de consenso em blob.
) tem alguma ligação com a pesquisa atual?
EIP-4444;
Torrents e EIP-4444;
Rede de portal;
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 específica para armazenar o histórico ------ pelo menos o histórico de execução, mas eventualmente também inclui o consenso e blob. A solução mais simples é ###i( simplesmente introduzir uma biblioteca torrent existente, bem como )ii( chamada solução nativa de Ethereum chamada Portal Network. Uma vez que qualquer uma delas é 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 ativá-lo para todos os clientes ao mesmo tempo, caso contrário, existe o risco de falhas nos clientes por se conectarem a outros nós esperando baixar o histórico completo, mas na verdade não obtendo-o.
As principais compensaçõ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 usando nós de arquivo existentes e vários provedores centralizados. Isso é fácil, mas enfraquece 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 o histórico de forma distribuída. Aqui, "quão duro 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 extremista e paranoica para ) envolveria a prova de custódia: exigindo, na prática, que cada validador de prova de participação armazenasse uma certa proporção de histórico e verificasse regularmente, de forma criptográfica, se o faz. Uma abordagem mais branda seria estabelecer um padrão voluntário para a porcentagem 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 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 arquivamento, mesmo que não haja outros nós de arquivamento online, eles possam alcançá-lo diretamente através da sincronização da rede do portal.
( Como interage com as outras partes do roteiro?
Se quisermos tornar a execução ou o arranque de nós 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, enquanto os restantes cerca de 800 GB são 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 relógios inteligentes e configurar em apenas alguns minutos.
A limitação do armazenamento histórico também 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, uma vez que os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram todos removidos. Agora que a transição para a prova de participação se tornou uma história, os clientes podem excluir com segurança todo o código relacionado à prova de trabalho.
![Vitalik: O possível futuro do Ethereum, The Purge])ian/2024/10/27/images/b3e2c5d4e7e1d40234643b84b51b43c1.jpg###
Expiração do estado
( Resolve que problema?
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, 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, transferindo assim um ônus para os clientes de Ethereum atuais e futuros.
O estado é mais difícil de "expirar" do que a história, porque o EVM foi fundamentalmente projetado 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 sem estado, alguns acreditam que esse problema talvez não seja tão ruim: apenas as classes de construtores de blocos especializados precisam realmente armazenar o estado, enquanto todos os outros nós ), incluindo até mesmo a geração de listas! ###, podem operar sem estado. No entanto, há uma opinião de que não queremos depender demais da sem estado, e que, no final, talvez queiramos fazer o estado expirar para manter a descentralização do Ethereum.
( O que é, como funciona?
Hoje, quando você cria um novo objeto de estado, ) pode ocorrer de uma das seguintes três maneiras: ### i ( enviar ETH para uma nova conta, ( ii ) criar uma nova conta usando código, ( iii ) configurar um slot de armazenamento que nunca foi tocado (, e 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 os 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 numa caverna por cinco anos e voltar, não deve perder o acesso às posições de ETH, ERC20, NFT, 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 rigidificadas e não atualizadas devem continuar a funcionar normalmente.
Não satisfazer esses objetivos torna fácil resolver os problemas. Por exemplo, você pode fazer com que cada objeto de estado também armazene um contador de data de expiração. O ) pode ser estendido queimando ETH, o que pode ocorrer automaticamente a qualquer momento durante a leitura ou escrita, e há um processo de percorrer os estados para remover objetos de estado com data de expiração. No entanto, isso introduz requisitos de cálculo e até mesmo de armazenamento adicionais, e com certeza não pode satisfazer os requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre situações limite que envolvem valores de armazenamento que à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 "transmitir" 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, 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 um armazena permanentemente o "mapeamento superior", onde os blocos estão 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 for mais armazenado
![Vitalik: O possível futuro do Ethereum, The Purge](