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 ocorre em duas frentes:
Dados históricos: As transações realizadas e as contas criadas em qualquer momento precisam ser armazenadas permanentemente por todos os clientes e ser baixadas por qualquer novo cliente para se sincronizar completamente com a rede. Isso resulta em um aumento constante na carga dos clientes e no tempo de sincronização, 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 um aumento da complexidade do código ao longo do 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 principais propriedades que tornam a blockchain grandiosa: a persistência. Você pode colocar NFTs, cartas de amor ou contratos inteligentes de 1.000.000 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 se sintam completamente descentralizadas e removam 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 equilibrar essas duas necessidades e minimizar ou reverter a sobrecarga, a complexidade e a decadência, mantendo a continuidade, isso é absolutamente possível. Organismos podem fazer isso: embora a maioria dos organismos envelheça com o tempo, alguns poucos sortudos não o fazem. Mesmo sistemas sociais podem ter uma vida útil muito longa. Em certos casos, Ethereum já teve sucesso: a prova de trabalho desapareceu, o opcode SELFDESTRUCT desapareceu em grande parte, e os nós da Beacon Chain armazenaram dados antigos por até seis meses. Encontrar esse caminho para Ethereum de uma maneira mais genérica e avançar em direção a um resultado final estável a longo prazo é o desafio definitivo para a escalabilidade a longo prazo, sustentabilidade técnica e até mesmo segurança do Ethereum.
The Purge: principal objetivo.
Reduzir os requisitos de armazenamento do cliente, diminuindo ou eliminando a necessidade de cada nó armazenar permanentemente todos os históricos, incluindo o estado final.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Índice do artigo:
Histórico de expiração(registros históricos expirados)
Estado de expiração( estado de expiração)
Limpeza de características(特征清理)
História de expiração
Que problema é resolvido?
Até a redação deste artigo, um nó Ethereum totalmente sincronizado necessita de 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, sendo que a maior parte já 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 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 é vinculado ao bloco anterior por meio de hash ( e outras estruturas ), é suficiente alcançar o consenso sobre o atual para também alcançar o 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 de conta, número aleatório, código, armazenamento ) pode ser fornecido por qualquer participante individual e 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 oferece-nos muitas opções sobre como armazenar registos históricos. Uma escolha natural é uma rede onde cada nó armazena apenas uma pequena parte dos dados. Esta tem sido a forma de operação das redes de sementes durante décadas: embora a rede armazene e distribua milhões de ficheiros, cada participante armazena e distribui apenas alguns desses ficheiros. Talvez, contrariamente à intuição, este método nem sempre diminua a robustez dos dados. Se ao permitir que os nós funcionem de forma mais económica, conseguirmos construir uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% do registo 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 tudo.
Atualmente, o Ethereum começou a se desvincular 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. 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 ) que pode ser de cerca de 18 dias (, durante o qual cada nó é responsável por armazenar tudo, e então estabelecer uma rede peer-to-peer composta por nós Ethereum que armazene dados antigos de forma distribuída.
Códigos de apagamento podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. Na verdade, 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 também colocar os dados de execução e consenso do bloco dentro do blob.
)# Quais são as conexões com a pesquisa existente?
EIP-4444;
Torrents e EIP-4444;
Portal de rede;
Portal Network e EIP-4444;
Armazenamento e recuperação distribuídos de objetos SSZ no Portal;
Como aumentar o limite de gas ### Paradigm (.
)# O que mais precisa ser feito, o que precisa ser ponderado?
O trabalho principal restante inclui a construção e integração de uma solução distribuída concreta para armazenar históricos ------ pelo menos os históricos de execução, mas eventualmente também incluirá consenso e blob. A solução mais simples é ###i( simplesmente introduzir uma biblioteca torrent existente, bem como )ii( uma solução nativa de Ethereum chamada Portal Network. Uma vez que qualquer uma delas seja introduzida, podemos ativar o EIP-4444. O EIP-4444 em si não requer um hard fork, mas requer uma nova versão do protocolo de rede. Portanto, é valioso ativá-lo simultaneamente para todos os clientes, caso contrário, existe o risco de falha do cliente devido à expectativa de conectar-se a outros nós e baixar o histórico completo, mas na verdade não o obter.
As principais considerações envolvem como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar história antiga amanhã e confiar em nós para replicar os 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, "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?
Quão profunda é a integração do armazenamento histórico no protocolo?
Uma abordagem extremamente obsessiva para ) envolveria a 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 periodicamente de forma criptografada se o faz. Uma abordagem mais branda seria estabelecer um padrão voluntário para a porcentagem 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 arquivos ERA que contêm toda a história do Ethereum. Uma implementação mais abrangente 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, eles possam fazê-lo através da sincronização direta da rede do portal.
(# Como ele interage com outras partes do roteiro?
Se quisermos que a execução ou o início de nós se torne 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 800 GB são 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 Ethereum mais viável, suportando apenas a versão mais recente do protocolo, o que os torna mais simples. Por exemplo, agora é seguro remover muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram eliminados. Agora que a transição para a prova de participação se tornou histórica, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
) Expiração estatal
Que problema está a resolver?
Mesmo que eliminemos a necessidade de os clientes armazenarem o histórico, a necessidade de armazenamento dos clientes continuará a crescer, cerca de 50 GB por ano, pois o estado continua a aumentar: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, o que, assim, trará encargos para os clientes do Ethereum agora e no futuro.
O estado é mais difícil de "expirar" do que a história, porque a EVM foi projetada fundamentalmente com a 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 o problema pode não ser tão grave assim: apenas classes especializadas de construtores de blocos precisam realmente armazenar estado, enquanto todos os outros nós ###, até mesmo aqueles que geram listas! ###, podem operar sem estado. No entanto, há uma perspectiva de que não queremos depender excessivamente da ausência de estado, e que, eventualmente, poderemos querer 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 três maneiras a seguir: ### i ( enviar ETH para a nova conta, ( ii ) criar uma nova conta usando código, ( iii ) definir um slot de armazenamento que nunca foi acessado antes (, 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 na caverna por cinco anos e voltar, não deve perder o acesso a ETH, ERC20, NFT, posições de 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 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; ) pode ser estendido queimando ETH, o que pode ocorrer automaticamente a qualquer momento ao ler ou escrever ), e há um processo em loop para percorrer o estado para remover a data de expiração dos objetos de estado. No entanto, isso introduz requisitos adicionais de cálculo ( e até mesmo de armazenamento ), e certamente não pode atender aos requisitos de usabilidade. Os desenvolvedores também têm dificuldade em raciocinar sobre casos de borda que envolvem valores de armazenamento que às vezes são redefinidos para zero. Se você configurar um temporizador de expiração dentro do alcance 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 principais do Ethereum tem trabalhado para resolver ao longo dos anos, incluindo propostas como "renda de blockchain" e "regeneração". No final, combinámos as melhores partes das propostas e concentrámo-nos em duas categorias de "soluções conhecidas como as menos más":
Solução para alguns estados expirados
Sugestões de expiração de estado baseadas no ciclo de endereço.
(# Expiração parcial do estado
Algumas propostas de estado expiram seguindo os mesmos princípios. Dividimos o estado em blocos. Cada um armazena permanentemente o "mapeamento de topo", onde os blocos podem estar vazios ou não. Os dados em cada bloco só são armazenados se os dados foram acessados recentemente. Existe um mecanismo de "ressurreição" que é ativado se não estiver mais armazenado.
As principais diferenças entre essas propostas são: ) i ### como definimos "recente", e ( ii ) como definimos "bloco"? Uma proposta concreta é a EIP-7736, que se baseia no design de "ramo e folha" introduzido para a árvore Verkle (, embora seja compatível com qualquer forma de estado sem estado, como árvores binárias ). Neste design, cabeçalhos, códigos e slots de armazenamento adjacentes são armazenados sob o mesmo "tronco". Os dados armazenados sob um ramo podem ser no máximo 256 * 31 = 7,936.
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.
11 Curtidas
Recompensa
11
7
Compartilhar
Comentário
0/400
NotGonnaMakeIt
· 07-16 18:58
Grande Blockchain deve ter cansado as novas máquinas.
Ver originalResponder0
MysteryBoxBuster
· 07-15 00:26
Esta cadeia está a tornar-se cada vez mais pesada.
Ver originalResponder0
SquidTeacher
· 07-14 03:56
Tem uma ideia, está tudo bem
Ver originalResponder0
GasFeeCrier
· 07-14 03:53
Agora é a altura mais gorda, não é?
Ver originalResponder0
DefiOldTrickster
· 07-14 03:52
Na cadeia, mais uma vez é um grande profeta.
Ver originalResponder0
GasBandit
· 07-14 03:47
Quando é que poderei superar a inflação?
Ver originalResponder0
StablecoinArbitrageur
· 07-14 03:29
*ajusta as folhas de cálculo* com base na minha correlação análise, eficiência de purga = sustentabilidade da rede * -0,89
Ethereum The Purge: criar um ecossistema de Blockchain sustentável a longo prazo
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 ocorre em duas frentes:
Dados históricos: As transações realizadas e as contas criadas em qualquer momento precisam ser armazenadas permanentemente por todos os clientes e ser baixadas por qualquer novo cliente para se sincronizar completamente com a rede. Isso resulta em um aumento constante na carga dos clientes e no tempo de sincronização, 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 um aumento da complexidade do código ao longo do 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 principais propriedades que tornam a blockchain grandiosa: a persistência. Você pode colocar NFTs, cartas de amor ou contratos inteligentes de 1.000.000 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 se sintam completamente descentralizadas e removam 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 equilibrar essas duas necessidades e minimizar ou reverter a sobrecarga, a complexidade e a decadência, mantendo a continuidade, isso é absolutamente possível. Organismos podem fazer isso: embora a maioria dos organismos envelheça com o tempo, alguns poucos sortudos não o fazem. Mesmo sistemas sociais podem ter uma vida útil muito longa. Em certos casos, Ethereum já teve sucesso: a prova de trabalho desapareceu, o opcode SELFDESTRUCT desapareceu em grande parte, e os nós da Beacon Chain armazenaram dados antigos por até seis meses. Encontrar esse caminho para Ethereum de uma maneira mais genérica e avançar em direção a um resultado final estável a longo prazo é o desafio definitivo para a escalabilidade a longo prazo, sustentabilidade técnica e até mesmo segurança do Ethereum.
The Purge: principal objetivo.
Reduzir os requisitos de armazenamento do cliente, diminuindo ou eliminando a necessidade de cada nó armazenar permanentemente todos os históricos, incluindo o estado final.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.
Índice do artigo:
Histórico de expiração(registros históricos expirados) Estado de expiração( estado de expiração) Limpeza de características(特征清理)
História de expiração
Que problema é resolvido?
Até a redação deste artigo, um nó Ethereum totalmente sincronizado necessita de 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, sendo que a maior parte já 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 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 é vinculado ao bloco anterior por meio de hash ( e outras estruturas ), é suficiente alcançar o consenso sobre o atual para também alcançar o 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 de conta, número aleatório, código, armazenamento ) pode ser fornecido por qualquer participante individual e 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 oferece-nos muitas opções sobre como armazenar registos históricos. Uma escolha natural é uma rede onde cada nó armazena apenas uma pequena parte dos dados. Esta tem sido a forma de operação das redes de sementes durante décadas: embora a rede armazene e distribua milhões de ficheiros, cada participante armazena e distribui apenas alguns desses ficheiros. Talvez, contrariamente à intuição, este método nem sempre diminua a robustez dos dados. Se ao permitir que os nós funcionem de forma mais económica, conseguirmos construir uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% do registo 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 tudo.
Atualmente, o Ethereum começou a se desvincular 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. 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 ) que pode ser de cerca de 18 dias (, durante o qual cada nó é responsável por armazenar tudo, e então estabelecer uma rede peer-to-peer composta por nós Ethereum que armazene dados antigos de forma distribuída.
Códigos de apagamento podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. Na verdade, 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 também colocar os dados de execução e consenso do bloco dentro do blob.
)# Quais são as conexões com a pesquisa existente?
EIP-4444;
Torrents e EIP-4444;
Portal de rede;
Portal Network e EIP-4444;
Armazenamento e recuperação distribuídos de objetos SSZ no Portal;
Como aumentar o limite de gas ### Paradigm (.
)# O que mais precisa ser feito, o que precisa ser ponderado?
O trabalho principal restante inclui a construção e integração de uma solução distribuída concreta para armazenar históricos ------ pelo menos os históricos de execução, mas eventualmente também incluirá consenso e blob. A solução mais simples é ###i( simplesmente introduzir uma biblioteca torrent existente, bem como )ii( uma solução nativa de Ethereum chamada Portal Network. Uma vez que qualquer uma delas seja introduzida, podemos ativar o EIP-4444. O EIP-4444 em si não requer um hard fork, mas requer uma nova versão do protocolo de rede. Portanto, é valioso ativá-lo simultaneamente para todos os clientes, caso contrário, existe o risco de falha do cliente devido à expectativa de conectar-se a outros nós e baixar o histórico completo, mas na verdade não o obter.
As principais considerações envolvem como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar história antiga amanhã e confiar em nós para replicar os 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, "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?
Quão profunda é a integração do armazenamento histórico no protocolo?
Uma abordagem extremamente obsessiva para ) envolveria a 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 periodicamente de forma criptografada se o faz. Uma abordagem mais branda seria estabelecer um padrão voluntário para a porcentagem 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 arquivos ERA que contêm toda a história do Ethereum. Uma implementação mais abrangente 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, eles possam fazê-lo através da sincronização direta da rede do portal.
(# Como ele interage com outras partes do roteiro?
Se quisermos que a execução ou o início de nós se torne 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 800 GB são 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 Ethereum mais viável, suportando apenas a versão mais recente do protocolo, o que os torna mais simples. Por exemplo, agora é seguro remover muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram eliminados. Agora que a transição para a prova de participação se tornou histórica, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
) Expiração estatal
Que problema está a resolver?
Mesmo que eliminemos a necessidade de os clientes armazenarem o histórico, a necessidade de armazenamento dos clientes continuará a crescer, cerca de 50 GB por ano, pois o estado continua a aumentar: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, o que, assim, trará encargos para os clientes do Ethereum agora e no futuro.
O estado é mais difícil de "expirar" do que a história, porque a EVM foi projetada fundamentalmente com a 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 o problema pode não ser tão grave assim: apenas classes especializadas de construtores de blocos precisam realmente armazenar estado, enquanto todos os outros nós ###, até mesmo aqueles que geram listas! ###, podem operar sem estado. No entanto, há uma perspectiva de que não queremos depender excessivamente da ausência de estado, e que, eventualmente, poderemos querer 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 três maneiras a seguir: ### i ( enviar ETH para a nova conta, ( ii ) criar uma nova conta usando código, ( iii ) definir um slot de armazenamento que nunca foi acessado antes (, 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 na caverna por cinco anos e voltar, não deve perder o acesso a ETH, ERC20, NFT, posições de 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 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; ) pode ser estendido queimando ETH, o que pode ocorrer automaticamente a qualquer momento ao ler ou escrever ), e há um processo em loop para percorrer o estado para remover a data de expiração dos objetos de estado. No entanto, isso introduz requisitos adicionais de cálculo ( e até mesmo de armazenamento ), e certamente não pode atender aos requisitos de usabilidade. Os desenvolvedores também têm dificuldade em raciocinar sobre casos de borda que envolvem valores de armazenamento que às vezes são redefinidos para zero. Se você configurar um temporizador de expiração dentro do alcance 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 principais do Ethereum tem trabalhado para resolver ao longo dos anos, incluindo propostas como "renda de blockchain" e "regeneração". No final, combinámos as melhores partes das propostas e concentrámo-nos em duas categorias de "soluções conhecidas como as menos más":
(# Expiração parcial do estado
Algumas propostas de estado expiram seguindo os mesmos princípios. Dividimos o estado em blocos. Cada um armazena permanentemente o "mapeamento de topo", onde os blocos podem estar vazios ou não. Os dados em cada bloco só são armazenados se os dados foram acessados recentemente. Existe um mecanismo de "ressurreição" que é ativado se não estiver mais armazenado.
As principais diferenças entre essas propostas são: ) i ### como definimos "recente", e ( ii ) como definimos "bloco"? Uma proposta concreta é a EIP-7736, que se baseia no design de "ramo e folha" introduzido para a árvore Verkle (, embora seja compatível com qualquer forma de estado sem estado, como árvores binárias ). Neste design, cabeçalhos, códigos e slots de armazenamento adjacentes são armazenados sob o mesmo "tronco". Os dados armazenados sob um ramo podem ser no máximo 256 * 31 = 7,936.