Um dos desafios que o Ethereum enfrenta é que, por padrão, a expansão e a complexidade de qualquer protocolo de blockchain tendem a aumentar com o tempo. Isso acontece de duas maneiras:
Dados históricos: Todas as transações realizadas e todas as contas criadas em qualquer momento da história precisam ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente, de modo a serem completamente sincronizadas com a rede. Isso resulta em uma carga de cliente e um tempo de sincronização que aumentam continuamente 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, o que resulta em um aumento da complexidade do código ao longo do tempo.
Para garantir que o Ethereum possa se manter a longo prazo, precisamos impor 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 principais características 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 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 a certeza de que suas dependências não serão atualizadas de uma maneira que as prejudique - especialmente o L1 em si.
Se tivermos determinação para equilibrar essas duas demandas e minimizar ou reverter a bulimia, a complexidade e o declínio, mantendo a continuidade, isso é absolutamente possível. Os organismos podem fazer isso: embora a maioria dos organismos envelheça com o tempo, alguns poucos afortunados não o fazem. Mesmo os sistemas sociais podem ter uma vida muito longa. Em alguns casos, 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 Ethereum de forma mais genérica e caminhar em direção a um resultado final estável a longo prazo é o desafio supremo para a escalabilidade de longo prazo do Ethereum, a sustentabilidade técnica e até a segurança.
The Purge: objetivo principal.
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
State expiry（状态到期）
Limpeza de características
História de expiração
Que problema resolve?
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 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, a maior parte dos quais 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 em centenas de GB a cada ano.
O que é, como funciona?
Uma característica chave que simplifica o problema de armazenamento histórico é que, como 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 chegue a um consenso sobre o bloco mais recente, qualquer bloco, transação ou estado histórico (saldos de contas, números aleatórios, código, armazenamento) pode ser fornecido por qualquer participante individual juntamente com uma prova Merkle, e essa prova permite que qualquer outra pessoa valide 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 os registros históricos. 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 no total, cada participante armazena e distribui apenas alguns deles. Talvez contra a intuição, este método nem sempre reduz a robustez dos dados. Se conseguirmos tornar a operação dos nós mais económica, podemos construir uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% dos registros históricos, então cada dado será copiado 10.000 vezes - o mesmo fator de cópia de uma rede de 10.000 nós, onde cada nó armazena todo o conteúdo.
Atualmente, o Ethereum começou a se afastar do modelo em que todos os nós armazenam permanentemente todo o histórico. Os blocos de consenso (ou seja, a parte relacionada ao consenso de prova de participação) armazenam apenas cerca de 6 meses. Os Blobs armazenam apenas cerca de 18 dias. O EIP-4444 visa introduzir um período de armazenamento de um ano para blocos históricos e recibos. O objetivo a longo prazo é estabelecer um período unificado (possivelmente cerca de 18 dias), durante o qual cada nó é responsável por armazenar todo o conteúdo, e então construir uma rede ponto a ponto composta por nós do Ethereum, que armazena 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á utilizou 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 também colocar a execução e os dados do bloco de consenso dentro do blob.
Quais são as ligações com a pesquisa existente?
EIP-4444；
Torrents e EIP-4444；
Portal de rede;
Rede de 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 específica para armazenar histórico - pelo menos o histórico de execução, mas eventualmente também inclui consenso e blob. A solução mais simples é (i) simplesmente introduzir uma biblioteca torrent existente, bem como (ii) chamada solução nativa do Ethereum conhecida como Portal Network. Uma vez introduzida qualquer uma delas, 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 ao mesmo tempo para todos os clientes, caso contrário, há o risco de que os clientes falhem ao se conectar 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, nós de arquivos existentes e de vários provedores centralizados para a 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 historicamente 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 armazene realmente todos os dados?
Qual é a profundidade da integração do armazenamento histórico no protocolo?
Um método extremamente obsessivo para (1) 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. Um método mais brando seria definir 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 envolveria 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 fazê-lo através da sincronização direta 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 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 cerca de 800 GB tornaram-se históricos. Apenas alcançando a ausência de estado e o EIP-4444 é que se poderá realizar a visão de executar um nó Ethereum em um relógio inteligente e configurá-lo em apenas alguns minutos.
A limitação do armazenamento histórico torna a implementação de nós Ethereum mais viável, suportando apenas a versão mais recente do protocolo, o que os torna mais simples. Por exemplo, agora é possível remover com segurança muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram removidos. Agora que a transição para a prova de participação se tornou história, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
Expiração do estado
Que problema resolve?
Mesmo que eliminemos a necessidade de armazenamento de histórico no cliente, a necessidade de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, à medida que o estado continua a aumentar: saldos de contas, números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, que trará um fardo para os clientes de Ethereum atuais e futuros.
O estado é mais difícil de "expirar" do que a história, porque a EVM foi projetada fundamentalmente 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 argumentam que esse problema pode não ser tão ruim assim: apenas classes de construtores de blocos especializados precisariam armazenar efetivamente o estado, enquanto todos os outros nós (incluindo a geração de listas!) poderiam operar sem estado. No entanto, há uma opinião de que não queremos depender demais da ausência de estado, e que, em última análise, poderíamos 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 (o que pode ocorrer de uma das seguintes três maneiras: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta usando código, (iii) configurando um slot de armazenamento que não 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 forma que realize 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 deveria perder o acesso às posições de ETH, ERC20, NFT e CDP...
Amigável para desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento totalmente 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 armazene também um contador de data de expiração (que pode ser estendido queimando ETH, o que pode ocorrer automaticamente a qualquer momento durante a leitura ou gravação), e ter um processo que percorre o estado para remover os objetos de estado com datas de expiração. No entanto, isso introduz cálculos adicionais (e até requisitos de armazenamento), e definitivamente não pode atender aos requisitos de usabilidade. Os desenvolvedores também têm dificuldade em raciocinar sobre casos extremos em que os valores armazenados à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 "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 "aluguel de blockchain" e "renovação". No final, combinamos as melhores partes das propostas e 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ços.
Expiração parcial do estado
Algumas propostas de estado expiradas seguem os mesmos princípios. Nós dividimos o estado em blocos. Cada um armazena permanentemente o "mapeamento de topo", onde os blocos estão vazios.
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.
Ethereum The Purge: reduzir a complexidade, aumentar a sustentabilidade e a segurança
O futuro possível do Ethereum: The Purge
Um dos desafios que o Ethereum enfrenta é que, por padrão, a expansão e a complexidade de qualquer protocolo de blockchain tendem a aumentar com o tempo. Isso acontece de duas maneiras:
Dados históricos: Todas as transações realizadas e todas as contas criadas em qualquer momento da história precisam ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente, de modo a serem completamente sincronizadas com a rede. Isso resulta em uma carga de cliente e um tempo de sincronização que aumentam continuamente 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, o que resulta em um aumento da complexidade do código ao longo do tempo.
Para garantir que o Ethereum possa se manter a longo prazo, precisamos impor 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 principais características 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 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 a certeza de que suas dependências não serão atualizadas de uma maneira que as prejudique - especialmente o L1 em si.
Se tivermos determinação para equilibrar essas duas demandas e minimizar ou reverter a bulimia, a complexidade e o declínio, mantendo a continuidade, isso é absolutamente possível. Os organismos podem fazer isso: embora a maioria dos organismos envelheça com o tempo, alguns poucos afortunados não o fazem. Mesmo os sistemas sociais podem ter uma vida muito longa. Em alguns casos, 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 Ethereum de forma mais genérica e caminhar em direção a um resultado final estável a longo prazo é o desafio supremo para a escalabilidade de longo prazo do Ethereum, a sustentabilidade técnica e até a segurança.
The Purge: objetivo principal.
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
State expiry（状态到期）
Limpeza de características
História de expiração
Que problema resolve?
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 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, a maior parte dos quais 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 em centenas de GB a cada ano.
O que é, como funciona?
Uma característica chave que simplifica o problema de armazenamento histórico é que, como 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 chegue a um consenso sobre o bloco mais recente, qualquer bloco, transação ou estado histórico (saldos de contas, números aleatórios, código, armazenamento) pode ser fornecido por qualquer participante individual juntamente com uma prova Merkle, e essa prova permite que qualquer outra pessoa valide 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 os registros históricos. 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 no total, cada participante armazena e distribui apenas alguns deles. Talvez contra a intuição, este método nem sempre reduz a robustez dos dados. Se conseguirmos tornar a operação dos nós mais económica, podemos construir uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% dos registros históricos, então cada dado será copiado 10.000 vezes - o mesmo fator de cópia de uma rede de 10.000 nós, onde cada nó armazena todo o conteúdo.
Atualmente, o Ethereum começou a se afastar do modelo em que todos os nós armazenam permanentemente todo o histórico. Os blocos de consenso (ou seja, a parte relacionada ao consenso de prova de participação) armazenam apenas cerca de 6 meses. Os Blobs armazenam apenas cerca de 18 dias. O EIP-4444 visa introduzir um período de armazenamento de um ano para blocos históricos e recibos. O objetivo a longo prazo é estabelecer um período unificado (possivelmente cerca de 18 dias), durante o qual cada nó é responsável por armazenar todo o conteúdo, e então construir uma rede ponto a ponto composta por nós do Ethereum, que armazena 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á utilizou 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 também colocar a execução e os dados do bloco de consenso dentro do blob.
Quais são as ligações com a pesquisa existente?
EIP-4444；
Torrents e EIP-4444；
Portal de rede;
Rede de 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 específica para armazenar histórico - pelo menos o histórico de execução, mas eventualmente também inclui consenso e blob. A solução mais simples é (i) simplesmente introduzir uma biblioteca torrent existente, bem como (ii) chamada solução nativa do Ethereum conhecida como Portal Network. Uma vez introduzida qualquer uma delas, 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 ao mesmo tempo para todos os clientes, caso contrário, há o risco de que os clientes falhem ao se conectar 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, nós de arquivos existentes e de vários provedores centralizados para a 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 historicamente 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 armazene realmente todos os dados?
Qual é a profundidade da integração do armazenamento histórico no protocolo?
Um método extremamente obsessivo para (1) 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. Um método mais brando seria definir 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 envolveria 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 fazê-lo através da sincronização direta 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 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 cerca de 800 GB tornaram-se históricos. Apenas alcançando a ausência de estado e o EIP-4444 é que se poderá realizar a visão de executar um nó Ethereum em um relógio inteligente e configurá-lo em apenas alguns minutos.
A limitação do armazenamento histórico torna a implementação de nós Ethereum mais viável, suportando apenas a versão mais recente do protocolo, o que os torna mais simples. Por exemplo, agora é possível remover com segurança muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram removidos. Agora que a transição para a prova de participação se tornou história, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.
Expiração do estado
Que problema resolve?
Mesmo que eliminemos a necessidade de armazenamento de histórico no cliente, a necessidade de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, à medida que o estado continua a aumentar: saldos de contas, números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, que trará um fardo para os clientes de Ethereum atuais e futuros.
O estado é mais difícil de "expirar" do que a história, porque a EVM foi projetada fundamentalmente 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 argumentam que esse problema pode não ser tão ruim assim: apenas classes de construtores de blocos especializados precisariam armazenar efetivamente o estado, enquanto todos os outros nós (incluindo a geração de listas!) poderiam operar sem estado. No entanto, há uma opinião de que não queremos depender demais da ausência de estado, e que, em última análise, poderíamos 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 (o que pode ocorrer de uma das seguintes três maneiras: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta usando código, (iii) configurando um slot de armazenamento que não 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 forma que realize 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 deveria perder o acesso às posições de ETH, ERC20, NFT e CDP...
Amigável para desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento totalmente 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 armazene também um contador de data de expiração (que pode ser estendido queimando ETH, o que pode ocorrer automaticamente a qualquer momento durante a leitura ou gravação), e ter um processo que percorre o estado para remover os objetos de estado com datas de expiração. No entanto, isso introduz cálculos adicionais (e até requisitos de armazenamento), e definitivamente não pode atender aos requisitos de usabilidade. Os desenvolvedores também têm dificuldade em raciocinar sobre casos extremos em que os valores armazenados à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 "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 "aluguel de blockchain" e "renovação". No final, combinamos as melhores partes das propostas e concentramos em duas categorias de "soluções conhecidas como as menos ruins":
Expiração parcial do estado
Algumas propostas de estado expiradas seguem os mesmos princípios. Nós dividimos o estado em blocos. Cada um armazena permanentemente o "mapeamento de topo", onde os blocos estão vazios.