Um dos problemas do Ethereum, ou de qualquer blockchain, é que ele cresce de tamanho com o tempo. Isso significa um aumento na complexidade de seu código e nos requisitos de armazenamento.
Um blockchain deve reter todos os dados ao longo de seu histórico que precisam ser armazenados por todos os clientes e baixados por novos clientes. Isso leva a um aumento constante na carga do cliente e no tempo de sincronização.
Além disso, a complexidade do código aumenta com o tempo porque é “mais fácil adicionar um novo recurso do que remover um antigo”, escreveu Vitalik Buterin em seu blog.
Portanto, Buterin acredita que os desenvolvedores devem trabalhar ativamente para conter essas tendências crescentes e, ao mesmo tempo, preservar a permanência do Ethereum. Buterin apresentou, portanto, The Purge – um plano com três partes que visa simplificar o blockchain e reduzir sua carga de dados.
Parte 1: Expiração do histórico
Um nó Ethereum totalmente sincronizado requer atualmente cerca de 1,1 TB de espaço de armazenamento para o cliente de execução. São necessárias mais algumas centenas de gigabytes para o cliente de consenso. Segundo Buterin, a maior parte desses dados são históricos, como dados sobre blocos históricos, transações e recebimentos, muitos dos quais têm vários anos. Para armazenar todo esse histórico, o espaço em disco necessário continua aumentando centenas de gigabytes a cada ano.
Buterin acredita que o problema pode ser resolvido por algo chamado Expiração do Histórico.
Cada bloco em uma blockchain aponta para o anterior por meio de um link hash. Isto significa que o consenso sobre o bloco actual indica consenso sobre a história.
Segundo Buterin, desde que a rede tenha consenso sobre o bloco atual, quaisquer dados históricos relacionados podem ser fornecidos por um único ator através de uma prova Merkle, que permite a qualquer pessoa verificar a sua integridade. Isso significa que, em vez de cada nó armazenar todos os dados, cada nó poderia armazenar uma pequena porcentagem dos dados, reduzindo os requisitos de armazenamento.
Buterin sugere basicamente a adoção do modelo de funcionamento das redes torrent, onde cada participante armazena e distribui apenas uma pequena parte dos dados armazenados e distribuídos pela rede.
A Ethereum já tomou medidas para reduzir os requisitos de armazenamento – certas informações agora têm prazo de validade. Por exemplo, os blocos de consenso são armazenados por seis meses e os blobs são armazenados por 18 dias.
O EIP-4444 é mais um passo nessa direção – seu objetivo é limitar em um ano o período de armazenamento de blocos históricos e recibos. O objetivo a longo prazo, no entanto, é ter um período fixo, como 18 dias, durante o qual cada nó tem de armazenar tudo e depois os dados mais antigos são armazenados de forma distribuída numa rede peer-to-peer.
Parte 2: Expiração do Estado
De acordo com Buterin, eliminar a necessidade de os clientes armazenarem todo o histórico não resolve completamente o problema do aumento dos requisitos de armazenamento. Isso ocorre porque um cliente precisa aumentar sua capacidade de armazenamento em cerca de 50 GB todos os anos devido ao “crescimento contínuo do estado: saldos de contas e nonces, código de contrato e armazenamento de contrato”.
Um novo objeto de estado pode ser criado de três maneiras: criando uma nova conta, enviando ETH para uma nova conta e definindo um slot de armazenamento anteriormente inativo. Depois que um objeto de estado é criado, ele permanece no estado para sempre.
Buterin acredita que a solução para expirar objetos de estado automaticamente ao longo do tempo precisa ser eficiente, fácil de usar e amigável ao desenvolvedor. Isso significa que a solução não deve exigir grandes quantidades de computação, que os usuários não devem perder o acesso aos seus tokens se os deixarem intocados durante anos e que os desenvolvedores não serão muito incomodados no processo.
Buterin sugere dois tipos de “soluções menos ruins conhecidas”:
- Soluções parciais de expiração de estado
- Propostas de expiração de estado com base no período de endereço.
Expiração parcial do estado
As propostas de expiração parcial do estado funcionam com base no princípio de dividir o estado em “pedaços”. Isso exigiria que todos armazenassem o “mapa de nível superior” cujos pedaços estão vazios ou não estão vazios para sempre. Os dados dentro dos pedaços são armazenados apenas se tiverem sido acessados recentemente. O mecanismo de “ressurreição” permite que qualquer pessoa recupere os dados em um bloco, se eles não estiverem armazenados, fornecendo provas de quais eram os dados.
Expiração do estado com base no período de endereço
A expiração do estado baseada no período de endereço propõe ter uma lista crescente de árvores de estado em vez de apenas uma armazenando o estado inteiro. Qualquer estado lido ou gravado é atualizado na árvore de estado mais recente. Uma nova árvore de estado vazia é adicionada uma vez por período, que pode durar um ano.
Neste cenário, as árvores de estado mais antigas são congeladas e os nós completos precisam armazenar apenas as duas árvores mais recentes. Se um objeto de estado se tornar parte de uma árvore expirada, ele poderá ser lido ou escrito, mas a transação exigiria uma prova Merkle para isso. Após a transação, ela será adicionada novamente à árvore mais recente.
Limpeza de recursos
Com o tempo, todos os protocolos se tornam complexos, não importa quão simples tenham sido no início.
Buterin escreveu:
“Se não queremos que o Ethereum entre em um buraco negro de complexidade cada vez maior, precisamos fazer uma de duas coisas: (i) parar de fazer mudanças e ossificar o protocolo(ii) ser capaz de realmente remover recursos e reduzir complexidade.”
De acordo com Buterin, limpar a complexidade do Ethereum requer várias pequenas correções, como a remoção do opcode SELFDESTRUCT, a remoção de tipos de transações antigos e comitês de cadeia de beacon, a reforma do LOG e muito mais. Buterin também sugeriu simplificar a mecânica dos gases, remover a observabilidade dos gases e melhorar a análise estática.
Mencionado neste artigo
source – cryptoslate.com
