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 duas frentes:
Dados históricos: Todas as transações e contas criadas em qualquer momento da história precisam ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente para sincronizar completamente com a rede. Isso resulta em um aumento constante da carga do cliente e do tempo de sincronização, 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 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 com o tempo. Ao mesmo tempo, precisamos preservar uma das propriedades-chave que tornam a blockchain grandiosa: a persistência. Você pode colocar NFTs, cartas de amor em registros de transações ou contratos inteligentes que contenham 1.000.000 de dólares na cadeia, e 10 anos depois ainda estarão lá esperando por você para ler e interagir. Para que os DApps possam descentralizar-se completamente e remover a chave de atualização com confiança, 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 comprometermos a encontrar um equilíbrio entre essas duas demandas e a minimizar ou reverter a gordura, 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 com o tempo, alguns poucos sortudos não o fazem. Mesmo os sistemas sociais podem ter uma longevidade 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 genérica e caminhar em direção a um resultado final de estabilidade a longo prazo é o desafio supremo para a escalabilidade a longo prazo do Ethereum, a sustentabilidade técnica e até mesmo a segurança.
O objetivo principal da Purge:
Reduzir os requisitos de armazenamento do cliente ao diminuir ou eliminar a necessidade de cada nó armazenar permanentemente todos os históricos e até mesmo os estados finais.
Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias
Expiração da história
Resolve que problema?
Até a 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 precisar 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, o tamanho do nó continuará a crescer em centenas de GB a cada ano.
O que é isso, como funciona?
Uma característica chave da simplificação do problema de armazenamento histórico é que, como cada bloco está ligado ao bloco anterior por meio de hash ( e outras estruturas ), é suficiente que haja consenso sobre o atual para que haja consenso sobre o histórico. Desde que a rede alcance consenso sobre o bloco mais recente, qualquer bloco histórico ou transação ou estado ( saldos de contas, números aleatórios, códigos, armazenamento ) podem ser fornecidos por qualquer participante único e 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.
Isso 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. Essa é a forma como as redes de sementes funcionam há 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, esse método nem sempre reduz 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 de uma rede de 10.000 nós, onde cada nó armazena tudo.
Atualmente, o Ethereum já 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, armazenando apenas cerca de 6 meses. O 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 a longo prazo é estabelecer um período unificado, ), que pode ser cerca de 18 dias, durante o qual cada nó é responsável por armazenar tudo, e depois estabelecer uma rede ponto a ponto composta por nós do Ethereum, armazenando dados antigos de maneira distribuída.
Códigos de apagamento podem ser utilizados para aumentar a robustez, mantendo o fator de replicação o mesmo. De fato, o Blob já foi codificado com códigos de apagamento para suportar amostragem de disponibilidade de dados. A solução mais simples provavelmente será reutilizar esses códigos de apagamento e colocar os dados de execução e de bloco de consenso também dentro do blob.
( tem alguma ligação com a pesquisa existente?
EIP-4444
Torrents e EIP-4444
Rede de portal
Rede portal e EIP-4444
Armazenamento e recuperação distribuídos de objetos SSZ no Portal
Como aumentar o limite de gas ) Paradigm ###
( O que mais precisa ser feito, o que 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 incluindo consenso e blob. A solução mais simples é )i### simplesmente introduzir uma biblioteca torrent existente, bem como (ii) uma solução nativa do Ethereum chamada Portal Network. Assim que introduzirmos qualquer um deles, poderemos ativar 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 ativá-lo simultaneamente para todos os clientes, caso contrário, há o risco de falha do cliente que se conecta a outros nós esperando baixar o histórico completo, mas na verdade não o obtém.
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 depender de nós existentes nós de arquivamento e vários provedores centralizados para replicação. 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 registros de forma distribuída. Aqui, "o quanto nos esforçamos" tem duas dimensões:
Como esforçamo-nos para garantir que o maior conjunto de nós realmente armazena todos os dados?
Quão profunda é a integração do armazenamento histórico no protocolo?
Uma abordagem extremamente paranoica para ( envolveria provas de custódia: na prática, exigiria que cada validador de prova de participação armazenasse uma certa proporção de histórico e verificasse regularmente, de forma criptografada, se o faz. Uma abordagem mais branda seria estabelecer um padrão voluntário para a porcentagem 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 arquivos ERA que contêm toda a história do Ethereum. Uma implementação mais completa envolveria realmente conectá-lo ao processo de sincronização, de modo que, se alguém 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 disponíveis, eles poderiam alcançá-lo através da sincronização direta com a rede do Portal.
) Como interage com outras partes do roteiro?
Se quisermos tornar a execução ou inicialização de nós 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, enquanto os restantes cerca de 800 GB tornaram-se históricos. Só ao alcançar a sem estado e o EIP-4444, será possível 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 é possível remover com segurança muitas linhas de código, uma vez que 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ória, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
Expiração do estado
Resolve que problema?
Mesmo que tenhamos eliminado a necessidade de os clientes armazenarem o histórico, a necessidade de armazenamento dos clientes continuará a crescer, cerca de 50 GB por ano, à medida que o estado continua a aumentar: saldos de contas e números aleatórios, código de contratos e armazenamento de contratos. Os usuários podem pagar uma taxa única, o que irá, para sempre, sobrecarregar os clientes de Ethereum atuais e futuros.
O estado é mais difícil de "expirar" do que a história, porque a EVM é fundamentalmente projetada em torno da suposição de que, uma vez criado um objeto de estado, ele sempre existirá e pode 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 grave: 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á um ponto de vista que argumenta que não queremos depender demais da ausência de estado, e, no final, podemos querer fazer o estado expirar para manter a descentralização do Ethereum.
O que é isso, como funciona?
Hoje, quando você cria um novo objeto de estado, ( pode ocorrer de uma das seguintes três maneiras: ) i ### enviando ETH para uma nova conta, ( ii ( criando uma nova conta com código, ) iii ( configurando 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 requer um grande número de cálculos adicionais 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 ao ETH, ERC20, NFT, posições CDP...
Amizade com 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 satisfazer 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 prolongado queimando ETH, o que pode acontecer automaticamente ao ler ou gravar a qualquer momento ), e há um processo de iteração sobre os estados para remover objetos de estado com datas de expiração. No entanto, isso introduz uma necessidade de computação adicional ) e até mesmo requisitos de armazenamento (, e certamente não pode satisfazer os requisitos de usabilidade. Os desenvolvedores também acham difícil inferir as situações 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 escopo do contrato, isso tecnicamente tornaria a vida dos desenvolvedores mais fácil, mas tornaria 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 arduamente para resolver ao longo dos anos, incluindo propostas como "renda 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 problemáticas":
Solução para alguns estados expirados
Sugestão de expiração de estado baseada no período 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 dentro de cada bloco só serão armazenados se tiverem sido acessados recentemente. Existe um mecanismo de "ressurreição" que se não estiver mais armazenado.
A principal diferença entre essas propostas é: ( i ) como definimos "recente", e ### ii ( como definimos "bloco"? Uma proposta específica é a EIP-7736, que se baseia no design de "folhas" introduzido para a árvore Verkle ) embora seja compatível com qualquer forma de estado sem estado, como a árvore binária (. Neste design, cabeçalhos, códigos e slots de armazenamento adjacentes são armazenados sob o mesmo "tronco". Os dados armazenados sob um tronco podem ter no máximo 256 * 31 = 7.936 bytes. Em muitos casos, todo o cabeçalho e código da conta, assim como muitos slots de armazenamento de chaves, serão armazenados sob o mesmo tronco. Se os dados sob o tronco dado não forem lidos ou escritos em 6 meses, esses dados não serão mais armazenados, mas apenas os 32 bytes desses dados.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
14 gostos
Recompensa
14
6
Partilhar
Comentar
0/400
LadderToolGuy
· 08-01 17:23
Os dados históricos ainda se atrevem a ser apagados.
Ver originalResponder0
Ser_APY_2000
· 08-01 13:46
O V神 realmente sabe como fazer as coisas.
Ver originalResponder0
TrustlessMaximalist
· 07-29 18:30
Vitalik Buterin fala de forma muito sólida.
Ver originalResponder0
ConfusedWhale
· 07-29 18:27
v神 fala ainda de forma tão profunda
Ver originalResponder0
hodl_therapist
· 07-29 18:17
O que o Velho V disse está correto.
Ver originalResponder0
MetaverseLandlord
· 07-29 18:06
O espaço de armazenamento está muito caro, é melhor limpar do que acumular.
Ethereum The Purge: Gota histórico de armazenamento simplificado protocolo aumento da sustentabilidade
O possível futuro do Ethereum: The Purge
Autor: Vitalik Buterin
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 duas frentes:
Dados históricos: Todas as transações e contas criadas em qualquer momento da história precisam ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente para sincronizar completamente com a rede. Isso resulta em um aumento constante da carga do cliente e do tempo de sincronização, 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 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 com o tempo. Ao mesmo tempo, precisamos preservar uma das propriedades-chave que tornam a blockchain grandiosa: a persistência. Você pode colocar NFTs, cartas de amor em registros de transações ou contratos inteligentes que contenham 1.000.000 de dólares na cadeia, e 10 anos depois ainda estarão lá esperando por você para ler e interagir. Para que os DApps possam descentralizar-se completamente e remover a chave de atualização com confiança, 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 comprometermos a encontrar um equilíbrio entre essas duas demandas e a minimizar ou reverter a gordura, 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 com o tempo, alguns poucos sortudos não o fazem. Mesmo os sistemas sociais podem ter uma longevidade 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 genérica e caminhar em direção a um resultado final de estabilidade a longo prazo é o desafio supremo para a escalabilidade a longo prazo do Ethereum, a sustentabilidade técnica e até mesmo a segurança.
O objetivo principal da Purge:
Expiração da história
Resolve que problema?
Até a 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 precisar 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, o tamanho do nó continuará a crescer em centenas de GB a cada ano.
O que é isso, como funciona?
Uma característica chave da simplificação do problema de armazenamento histórico é que, como cada bloco está ligado ao bloco anterior por meio de hash ( e outras estruturas ), é suficiente que haja consenso sobre o atual para que haja consenso sobre o histórico. Desde que a rede alcance consenso sobre o bloco mais recente, qualquer bloco histórico ou transação ou estado ( saldos de contas, números aleatórios, códigos, armazenamento ) podem ser fornecidos por qualquer participante único e 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.
Isso 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. Essa é a forma como as redes de sementes funcionam há 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, esse método nem sempre reduz 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 de uma rede de 10.000 nós, onde cada nó armazena tudo.
Atualmente, o Ethereum já 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, armazenando apenas cerca de 6 meses. O 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 a longo prazo é estabelecer um período unificado, ), que pode ser cerca de 18 dias, durante o qual cada nó é responsável por armazenar tudo, e depois estabelecer uma rede ponto a ponto composta por nós do Ethereum, armazenando dados antigos de maneira distribuída.
Códigos de apagamento podem ser utilizados para aumentar a robustez, mantendo o fator de replicação o mesmo. De fato, o Blob já foi codificado com códigos de apagamento para suportar amostragem de disponibilidade de dados. A solução mais simples provavelmente será reutilizar esses códigos de apagamento e colocar os dados de execução e de bloco de consenso também dentro do blob.
( tem alguma ligação com a pesquisa existente?
( 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 incluindo consenso e blob. A solução mais simples é )i### simplesmente introduzir uma biblioteca torrent existente, bem como (ii) uma solução nativa do Ethereum chamada Portal Network. Assim que introduzirmos qualquer um deles, poderemos ativar 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 ativá-lo simultaneamente para todos os clientes, caso contrário, há o risco de falha do cliente que se conecta a outros nós esperando baixar o histórico completo, mas na verdade não o obtém.
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 depender de nós existentes nós de arquivamento e vários provedores centralizados para replicação. 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 registros de forma distribuída. Aqui, "o quanto nos esforçamos" tem duas dimensões:
Como esforçamo-nos para garantir que o maior conjunto de nós realmente armazena todos os dados?
Quão profunda é a integração do armazenamento histórico no protocolo?
Uma abordagem extremamente paranoica para ( envolveria provas de custódia: na prática, exigiria que cada validador de prova de participação armazenasse uma certa proporção de histórico e verificasse regularmente, de forma criptografada, se o faz. Uma abordagem mais branda seria estabelecer um padrão voluntário para a porcentagem 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 arquivos ERA que contêm toda a história do Ethereum. Uma implementação mais completa envolveria realmente conectá-lo ao processo de sincronização, de modo que, se alguém 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 disponíveis, eles poderiam alcançá-lo através da sincronização direta com a rede do Portal.
) Como interage com outras partes do roteiro?
Se quisermos tornar a execução ou inicialização de nós 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, enquanto os restantes cerca de 800 GB tornaram-se históricos. Só ao alcançar a sem estado e o EIP-4444, será possível 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 é possível remover com segurança muitas linhas de código, uma vez que 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ória, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
Expiração do estado
Resolve que problema?
Mesmo que tenhamos eliminado a necessidade de os clientes armazenarem o histórico, a necessidade de armazenamento dos clientes continuará a crescer, cerca de 50 GB por ano, à medida que o estado continua a aumentar: saldos de contas e números aleatórios, código de contratos e armazenamento de contratos. Os usuários podem pagar uma taxa única, o que irá, para sempre, sobrecarregar os clientes de Ethereum atuais e futuros.
O estado é mais difícil de "expirar" do que a história, porque a EVM é fundamentalmente projetada em torno da suposição de que, uma vez criado um objeto de estado, ele sempre existirá e pode 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 grave: 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á um ponto de vista que argumenta que não queremos depender demais da ausência de estado, e, no final, podemos querer fazer o estado expirar para manter a descentralização do Ethereum.
O que é isso, como funciona?
Hoje, quando você cria um novo objeto de estado, ( pode ocorrer de uma das seguintes três maneiras: ) i ### enviando ETH para uma nova conta, ( ii ( criando uma nova conta com código, ) iii ( configurando 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 requer um grande número de cálculos adicionais 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 ao ETH, ERC20, NFT, posições CDP...
Amizade com 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 satisfazer 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 prolongado queimando ETH, o que pode acontecer automaticamente ao ler ou gravar a qualquer momento ), e há um processo de iteração sobre os estados para remover objetos de estado com datas de expiração. No entanto, isso introduz uma necessidade de computação adicional ) e até mesmo requisitos de armazenamento (, e certamente não pode satisfazer os requisitos de usabilidade. Os desenvolvedores também acham difícil inferir as situações 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 escopo do contrato, isso tecnicamente tornaria a vida dos desenvolvedores mais fácil, mas tornaria 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 arduamente para resolver ao longo dos anos, incluindo propostas como "renda 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 problemáticas":
) 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 dentro de cada bloco só serão armazenados se tiverem sido acessados recentemente. Existe um mecanismo de "ressurreição" que se não estiver mais armazenado.
A principal diferença entre essas propostas é: ( i ) como definimos "recente", e ### ii ( como definimos "bloco"? Uma proposta específica é a EIP-7736, que se baseia no design de "folhas" introduzido para a árvore Verkle ) embora seja compatível com qualquer forma de estado sem estado, como a árvore binária (. Neste design, cabeçalhos, códigos e slots de armazenamento adjacentes são armazenados sob o mesmo "tronco". Os dados armazenados sob um tronco podem ter no máximo 256 * 31 = 7.936 bytes. Em muitos casos, todo o cabeçalho e código da conta, assim como muitos slots de armazenamento de chaves, serão armazenados sob o mesmo tronco. Se os dados sob o tronco dado não forem lidos ou escritos em 6 meses, esses dados não serão mais armazenados, mas apenas os 32 bytes desses dados.