O que é “apátrida” que Vitalik mencionou frequentemente nos seus discursos recentes?

Compilado por: GaryMa Wu Shuo Blockchain

Vitalik mencionou conjuntamente um tópico na recente Korean Blockchain Week, discurso em Cingapura e até mesmo na Ethereum Executive Core Developer Conference (ACDE): estado, e o que se segue está relacionado a ele. Vários conceitos de solução, como sem estado, expiração de estado (StateExpiry). , expiração de dados históricos (HistoryExpiry, EIP-4444), árvore Verkle e até expansão/compressão do espaço de endereço (Address Space Expand\Compression). Claro, este não é realmente um novo plano de ajuste de roteiro.No último roteiro de Ethereum lançado por Vitalik em novembro do ano passado, estes pertencem principalmente às principais rotas de TheVerge e ThePurge.

Este artigo combina estas duas rotas principais e alguns novos desafios de pensamento para rever a rota da solução estatal de Vitalik.

Estado

Estado em Ethereum refere-se a um livro-razão abrangente que inclui todas as contas de propriedade externa (EOAs), seus saldos, implantações de contratos inteligentes e armazenamento associado. Este estado não é estático; continua a expandir-se à medida que novos utilizadores são adicionados e novos contratos inteligentes são implementados.

Atualmente, os nós completos devem armazenar esse conjunto de dados cada vez maior para validar adequadamente os blocos e garantir transições de estado corretas, tornando o processo de validação de natureza estável. Este crescente requisito de armazenamento, aumentando assim os requisitos de hardware para a execução de nós completos, levará a validadores cada vez mais centralizados.

De acordo com etherscan.io/data, atualmente a execução de um nó completo de sincronização rápida requer pelo menos 1200 Gb (tomando o cliente Geth como exemplo).Isso ocorre após a remoção do estado ter sido realizada, excluindo dados de estado anteriores e mantendo apenas o estado mais recente A premissa. Se for um nó de arquivo, ou seja, o nó completo reterá todos os estados históricos, incluindo o estado de cada bloco, então a capacidade necessária será de cerca de 15.400 Gb, e continuará a crescer no futuro, que é o que o comunidade muitas vezes chama de “explosão de estado”.

Isto é o que Vitalik enfatizou na Korea Blockchain Week: a centralização dos nós é um dos maiores problemas enfrentados pela rede Ethereum e deve ser resolvido tornando os nós mais baratos e mais fáceis de operar.

Para lidar com esta série de desafios, a comunidade Ethereum tem trabalhado arduamente para encontrar formas de melhorar e otimizar, ou seja, os diversos conceitos de soluções que exemplificamos no início.

Solução de status

Apatridia

O conceito central do stateless é externalizar os dados do estado, eliminando a necessidade de cada nó armazenar o estado completo. Neste modo, os nós só precisam manter cabeçalhos de bloco e informações de transação relacionadas, e verificar e reconstruir o estado por meio de provas de estado (State Proofs).

O principal papel e significado da apatridia é reduzir a carga de armazenamento dos nós, melhorar a escalabilidade da rede e permitir que mais nós participem facilmente na verificação, ao mesmo tempo que mantém a natureza descentralizada do Ethereum.

Árvore Verkle

Atualmente, o Ethereum depende das árvores Merkle-Patricia para fazer hash e compactar seus dados de estado. No entanto, o tamanho das provas Merkle em tais estruturas em árvore pode tornar-se muito grande, tornando-as menos adequadas para as testemunhas exigidas pelos modelos sem estado.

Para resolver este problema, a Ethereum planeja fazer a transição para árvores Verkle, uma estrutura de dados mais eficiente. As árvores Merkle-Patricia e as árvores Verkle compartilham uma habilidade importante, que é gerar testemunhas – provas criptográficas que permitem a qualquer pessoa confirmar facilmente a existência e a disponibilidade pública de informações específicas na raiz do estado.

A vantagem das árvores Verkle é que elas são mais eficientes na geração de tamanhos de prova menores.

Os dados do histórico expiraram (HistoryExpiry, EIP-4444)

O EIP-4444 visa implementar a expiração de dados históricos, uma atualização que exige que os nós parem de hospedar blocos históricos com mais de um ano na rede ponto a ponto. A remoção de dados históricos alivia significativamente os requisitos de espaço em disco para operadores de nós. Ao mesmo tempo, também simplifica o software cliente, eliminando a necessidade de adaptar código para diferentes versões de blocos históricos. Além disso, a combinação de EIP-4444 e PDS (Proto-danksharding) garante a remoção regular de dados; o EIP-4444 remove uma vez por ano, enquanto o PDS remove blocos de dados uma vez por mês. Embora isto ajude a reduzir as necessidades de armazenamento de dados dos nós, também levanta preocupações sobre a preservação e recuperação de dados históricos.

Expiração do estado (StateExpiry)

A apatridia elimina a necessidade de os validadores manterem o estado completo ao validar blocos. Mas o Estado não vai desaparecer; o seu crescimento contínuo continua a ser um desafio a longo prazo para a web.

Para resolver este problema fundamental, a comunidade propôs a solução State Expiry.

A expiração do estado removerá automaticamente as partes do estado que permanecem inalteradas por, digamos, um ano, movendo-as para uma estrutura de árvore separada e removendo-as do protocolo Ethereum principal.

Vale ressaltar que a expiração do estado só se torna viável após a migração para as árvores Verkle. Além disso, Vitalik disse na Semana Coreana de Blockchain KBW2023: Se houver apatridia e PBS, a expiração do estado pode ser de baixa prioridade.

Porque se a Separação Proponente-Construtor (PBS) for implementada até então, no estado sem estado, embora o construtor de bloco ainda precise acessar o estado para criar o bloco, o construtor de bloco naquele momento já era esperado. lidar com o crescimento do estado, porque esta área permite um certo grau de centralização, o desempenho do nó dos construtores pode naturalmente atender às necessidades.

Embora o PBS em nível de protocolo ainda não tenha sido incluído na rede principal Ethereum, podemos entender aproximadamente a tendência futura da rede principal, compreendendo a distribuição atual do mercado do Mev-Boost PBS. As estatísticas de dados de mevboost.pics são as seguintes:

Além disso, a implementação do State Expiry envolve mudanças no formato de endereço Ethereum.Existem atualmente duas soluções: extensão do espaço de endereço vs. compressão do espaço de endereço. O primeiro aumenta o comprimento do endereço para 32 bytes (o formato de endereço atual é de 20 bytes), mas requer lógica complexa para compatibilidade com versões anteriores e o contrato existente também deve ser atualizado; o último mantém o formato de 20 bytes, mas altera os antigos 6 bytes são usados para identificar o prefixo e o ciclo de endereço. Embora isso reduza muito o problema de compatibilidade, também leva a outro problema. O comprimento do endereço é de apenas 14 bytes e não tem mais a capacidade de resistir a colisões, introduzindo assim alguns endereços. O potencial as questões de segurança criadas também são um grande desafio enfrentado atualmente pela comunidade.

Resumir

Agora, podemos eliminar aproximadamente as prioridades antes e depois com base nas dificuldades e prioridades de implementação das soluções técnicas acima (2\3\4 podem ser iguais):

1. Árvore verde

2. PBS

3. Apátrida

4. Dados históricos expirados (EIP-4444)

5. Mudanças no formato do endereço Ethereum (compressão/expansão)

6. Expiração do status

Em resumo, o limite de operação do nó pode ser reduzido, a descentralização do nó e os problemas potenciais de explosão de estado podem ser mantidos e o crescimento do estado pode ser reduzido para otimizar a carga de comunicação da rede.

Claro, ainda há um longo caminho a percorrer.

Links de referência: