Introdução

O que as blockchains armazenam e se referem ao processar transações é chamado de estado. No Ethereum, o estado é a propriedade que facilita o consenso dos nós. Cada nó completo precisa armazenar e atualizar este estado durante cada período de blocos válidos. Os estados, por mais importantes que sejam para as blockchains, têm um lado negativo; eles crescem com o tempo. Eles são um grande problema nas blockchains, como Bitcoin e Ethereum, porque o aumento de tamanho vem acompanhado de um aumento equivalente nos requisitos de hardware para os nós. O limiar de espaço elimina alguns nós ao longo do tempo, levando à centralização.PEI-2935propõe trazer a ausência de estado para o Ethereum, aliviando os nós do fardo do tamanho. O EIP-2935 é uma proposta de melhoria que tenta alcançar a ausência de estado armazenando e servindo os últimos 8192 hashes de bloco do estado para execução sem estado no Ethereum.

Breve Visão Geral da Estrutura Atual do Ethereum

Blocos

Blocos são lotes de transações com uma referência (hash) do bloco anterior incluída na cadeia. Hashes em cada bloco são derivados dos dados do bloco criptograficamente. Esta inclusão conecta as cadeias com hashes, e a formação de lotes implica que todos os participantes na rede concordam e sincronizam o estado de uma vez. Além disso, o acordo sobre blocos agrupados sinaliza o Ethereum para atualizar seu estado global em cada participante na rede como um nó.

Alt: Mudança de estado no Ethereum

Uma vez que um novo bloco é tratado e transmitido com um validador na rede, o restante dos participantes o adicionam ao seu armazenamento e atualizam seu estado global. O validador de cada bloco é selecionado aleatoriamente pelo Organização Autônoma Descentralizada de Randomização (RANDAO) parâmetro. A estrutura do bloco é estritamente ordenada, e a criação de blocos e os processos de consenso são especificados sob o protocolo de prova de participação do Ethereum.

Um bloco contém vários campos em seu cabeçalho e corpo. Por exemplo, o cabeçalho do bloco inclui os campos de slot, proposer_index, parent_root, state_root e corpo. O corpo do bloco inclui randao_reveal, eth1_data, graffiti, proposer_slashings, attester_slashings, atestações, depósitos, saídas voluntárias, agregado de sincronização e carga de execução. Cada campo possui diferentes parâmetros e atende a diferentes necessidades.

Ethereum’s 12 segundosO período de criação de blocos, também chamado de 'slot', deriva do tempo suficiente para os participantes da rede sincronizarem com os novos blocos e concordarem com o consenso. Durante este período:

1. O proponente de bloco seleciona aleatoriamente um validador,
2. O validador agrupa as transações e as executa para determinar um novo estado global.
3. Eles incluem essas informações em um novo bloco e as transmitem para o restante do conjunto de validadores por meio de um protocolo de fofocas,
4. Outros validadores reexecutam as transações para garantir a validade e concordar com a mudança de estado global como um consenso,
5. Se o validador verifica o novo bloco como válido, eles o adicionam ao seu armazenamento.

A finalidade de um bloco e transação significa que não pode ser alterado sem uma queima significativa de ETH em uma rede distribuída. Ethereum tem uma abordagem de "blocos de checkpoint" para gerenciar a finalização. O primeiro bloco em cada época é assumido como o checkpoint desse slot. Os validadores votam nessa suposição para torná-la um checkpoint válido. Se dois terços do total de ETH apostado com votos de validadores elegem um par de checkpoints, os checkpoints são atualizados para justificados. Os checkpoints justificados anteriores são atualizados após a próxima atualização de checkpoints, e eles se tornam finalizados. Se um ator malicioso deseja reverter um bloco finalizado, ele precisa se comprometer a perder pelo menos um terço do fornecimento total de ETH apostado. Embora exista um mecanismo chamado vazamento de inatividadeexiste para restaurar a finalidade impondo grandes penalidades aos fundos dos validadores e reduzindo as recompensas dos atestantes no caso de uma falha permanente de um grande número de validadores.

Ao processar o bloco, o Ethereum aplica uma função de hash para pegar os dados dos blocos e reduzi-los a strings únicas. Na função de hash, cada entrada produz uma saída única. Os valores de hash nos blocos são a única parte imutável. É alterável com um terço do total de ETH apostado queimado. No entanto, esse valor vem da recálculo dos hashes da trie de Merkle até um ponto de verificação. A saída do processo de hash para cada bloco é retornada com o parâmetro blockHash. O parâmetro blockHash inclui todos os dados no bloco.

Os valores de hash dos blocos e outros parâmetros necessários são armazenados em tentativas de Merkle. O Ethereum usa a arquitetura de tentativa de Merkle com diferentes versões, como a Trie de Merkle Patricia.

Árvores de Merkle e Merkle Patricia

Estruturas de árvore, especialmente Árvores de Merkle, são fundamentais para o armazenamento de blockchain. Sem Árvores de Merkle, as blockchains se tornam blocos únicos que são difíceis de processar toda vez. Com Árvores de Merkle, ou geralmente arquiteturas de árvore, as blockchains alcançam completude com fragmentos básicos. Isso lhes permite se tornar participantes de rede com baixos requisitos de hardware.

As árvores de Merkle são uma forma estruturada de fazer hash de grandes quantidades de fragmentos e dividi-los em partes. Com a Merkleização, os dados são organizados em pares; cada um é hash junto. O processo de Merkleização se repete até que uma única raiz de Merkle seja obtida.

O Ethereum prefere tentativas de Merkle Patricia, uma estrutura de tentativa de Merkle dupla. Ele usa tentativas binárias para manipulação de dados básicos, como dados de transação, pois essa abordagem é mais eficiente para tais situações. No entanto, o Ethereum utiliza as tentativas de Merkle Patricia mais complexas em casos complexos, como o tratamento de estado.

Em um cenário de armazenamento de dados de árvore de estado, o Ethereum utiliza um mapa de chave-valor. As chaves representam endereços e os valores representam declarações de conta. As árvores de estado são mais dinâmicas do que as árvores binárias. Assim, novas contas podem ser inseridas com frequência, e chaves podem ser inseridas e excluídas com frequência. Esse processo requer uma estrutura de dados rapidamente atualizável que não exija recalcular todo o conjunto de dados.

A raiz da trie depende apenas dos dados, não da ordem. Fazer atualizações nos dados em ordens diferentes não mudará a raiz em si.

Alt: Árvore Trie Merkle Binária

Ethereum usa uma árvore Patricia Merkle modificada, que tem algumas características de PATRICIA (Algoritmo Prático para Recuperar Informações Codificadas em Alfanumérico)e Merkle Trie com modificações ao longo dele. Esta arquitetura é determinística e criptograficamente verificável. A única maneira de gerar uma raiz de estado nesta estrutura é calculando-a a partir de cada pedaço individual de estado. Dois estados idênticos podem ser facilmente comprovados comparando o hash da raiz e os hashes que o levaram a ela.

Por fim, modificar o estado com valores diferentes é impossível porque resultará em um hash de raiz de estado diferente. Todas as estruturas de árvore no nível de execução do Ethereum usam uma Árvore Patricia Merkle. A rede tem três tentativas: State Trie, Storage Trie e Transaction Trie. Além disso, cada bloco tem sua própria Receipts Trie. Embora as Árvores Patricia Merkle sejam eficientes de muitas maneiras, o Ethereum está motivado a substituí-las por Verkle Tries para alcançar a falta de estado.

Alt: Árvore de Índice de Posição de Merkle Patricia

Gás

O gás é a propriedade necessária na EVM para a execução. Como a EVM usa e precisa de recursos computacionais para executar, o retorno desses esforços é pago com gás para garantir a segurança da EVM. A taxa de gás é calculada como a quantidade necessária de gás multiplicada pelo custo por unidade. É um valor dinâmico e depende do tipo de operação.

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

PEI-1559introduziu algumas mudanças significativas no mecanismo de taxa de transação. Pagar pelo gás para incluir transações nos blocos funcionava com um método semelhante a um leilão no passado. Com o PEI-1559, há um limite mínimo chamado de taxa base e uma gorjeta chamada de taxa prioritária introduzida. Os blocos são propostos a começar pela transação com a taxa prioritária mais alta. Após o processo do bloco, a taxa base é queimada, e a taxa prioritária é usada para incentivar os validadores.

Estado

O estado da blockchain pode ser definido como um conjunto de dados (ou variáveis) que descrevem um determinado sistema em um período específico. A internet tem estado desde quase o início, mas era armazenada em um único servidor. Com o Web3, um estado global mantido em uma rede aberta e distribuída, assegurada por métodos descentralizados, foi introduzido. Todos podem visualizar e verificar o estado da rede distribuída a qualquer momento que desejarem.

O Ethereum inclui contas, saldos, contratos inteligentes implantados e armazenamento associado no estado global. O estado do Ethereum cresce com as adições e mudanças nesses parâmetros. O crescimento do estado se torna problemático quando o custo de hardware para hospedar um nó completo se torna proibitivo. Diante desses desafios, Vitalik Buterin apresentadoo conceito de Ethereum sem estado em 2017. Os métodos propostos para corrigir o crescimento do estado no Ethereum incluem expiração de dados e estado.

Diferenças entre a Expiração de Dados e a Expiração de Estado

Expiração de dados

A expiração de dados ou histórico significa podar os dados não necessários dos clientes após um certo período. Com os "pontos de verificação de subjetividade fraca", os clientes podem encontrar seu caminho na sincronização a partir do genesis e podar dados históricos desnecessários.

A subjetividade refere-se aos nós de uma rede que dependem de informações sociais para chegar a um consenso sobre o estado atual. Nesse sentido, a subjetividade fraca refere-se a uma cadeia que pode progredir objetivamente com alguma semente inicial de informações recuperadas socialmente. No entanto, os pontos de verificação de subjetividade fraca implicam que todos os nós na rede responsáveis pelo consenso pertencem à cadeia canônica. Os pontos de verificação de subjetividade fraca ajudam o Ethereum PoS a ter o estado recente (ponto de verificação de subjetividade fraca) de uma fonte confiável para sincronizar a partir dela.

PEI-4444fornece o caminho prático para@hBXHLw_9Qq2va4pRtI4bIA/ryzBaf7fJx?ref=ghost-2077.arvensis.systems">alcançar a expiração de dados através da fraqueza-subjetividade. A proposta não tem como objetivo alterar a forma como os nós do Ethereum lidam com os dados de estado; em vez disso, modifica o acesso aos dados históricos.

Expiração de Estado

O State Expiry busca eliminar o estado dos nós individuais se não tiver sido acessado recentemente. A expiração pode ser implementada pela terminação sendo um fator de aluguel ou tempo. A expiração por aluguel significa impor uma sobretaxa nas contas para armazenar o estado. Por outro lado, a expiração por tempo significa tornar as contas inativas se permanecerem inativas por um certo período.

Tanto a Expiração de Dados quanto a Expiração de Estado são áreas de pesquisa abertas. As abordagens atuais para alcançar esses status propostos envolvem passá-los por redes/fornecedores centralizados. Até agora, a falta de estado e a expiração de estado foram parcialmente alcançadas no Ethereum.

Ethereum sem estado

Introdução à Ausência de Estado e ao Ethereum Sem Estado

O Ethereum sem estado introduz novos conceitos no protocolo central. Idealmente, a falta de estado não implica que o estado não exista. Em vez disso, significa que os clientes podem escolher o estado que desejam manter. Quando os clientes recebem blocos validados, também recebem a testemunha correspondente a esse bloco. As testemunhas de cada bloco consistem em todos os dados necessários para executar as transações contidas nesse bloco.

PEI-161introduziu a primeira abordagem de redução de estado. Ethereum sofreu um ataque DoS (Negação de Serviço), e essa vulnerabilidade permitiu criar contas vazias que aumentaram o estado global do Ethereum. O EIP-161 propôs remover contas vazias com valor zero (0) no nonce que surgiram desse ataque, com baixos custos. A proposta foi executada, resultando em um reverter de estado.

Outro esforço em direção à ausência de estado foi proposto via PEI-4788. Esta proposta buscou expor as raízes dos blocos da corrente do farol no EVM. Similar à abordagem do Ponte Eth1-Eth2conectando a cadeia Beacon (camada de consenso) e a camada de execução, esta proposta permite acesso com minimização de confiança entre o EVM e a camada de consenso.

Porque cada bloco de execução contém a raiz do bloco beacon pai, os eventos de slots perdidos não precisariam alterar a raiz do bloco anterior. Portanto, os pré-requisitos da execução se limitam a reservar um pequeno espaço para um oráculo minimizado de confiança em cada bloco de execução. A proposta sugere armazenar um pequeno histórico de raízes de bloco em um contrato de raiz para melhorar a eficiência do oráculo.

A apatridia no Ethereum é possível tanto como apatridia fraca quanto forte.

Fragilidade da Falta de Estado

A fragilidade do estado sem estado é um status que não elimina a necessidade de armazenamento de estado em todos os nós. Em vez disso, difere na forma como os nós verificam as alterações no estado do Ethereum. Ele coloca a responsabilidade pelo armazenamento de estado nos proponentes de bloco e requer que outros nós verifiquem os blocos sem armazenar os dados de estado completos.

Os proponentes de bloco precisam armazenar dados de estado completos. No entanto, os clientes verificadores não precisam armazenar os dados de estado na rede. Em vez disso, eles podem armazenar a raiz do estado (um hash de todo o estado). A Fraqueza da Falta de Estado requer Separação Propositor-Construtor (PBS)eVerkle tentaimplementação.

Os proponentes criam testemunhas usando os dados do estado para provar as mudanças de estado, e os validadores verificam as provas contra o hash da raiz do estado.

Fortaleza da Desestatização

A forte ausência de estado elimina a necessidade de qualquer nó armazenar os dados do estado. Funciona incorporando transações enviadas e testemunhas agregadas pelos proponentes de bloco. Os proponentes de bloco armazenam o único estado em que estão trabalhando, gerando testemunhas para contas relevantes. A proposta ainda precisa de mais desenvolvimento e inclui requisitos como Listas de Acesso ou PEI-2930.

No entanto, algumas alterações e propriedades podem ser usadas para alcançar a falta de estado. PEI-2935 propõe servir hashes de bloco históricos do estado para permitir a execução sem estado.

Introdução ao PEI-2935

PEI-2935 tem como objetivo salvar hashes de blocos históricos no estado da blockchain em slots de armazenamento especiais chamados HISTORY_STORAGE_ADDRESS. Esse processo permitirá a execução sem estado, facilitando o acesso fácil às informações históricas necessárias em clientes sem estado.

PEI-2935 propõe armazenar os últimos 8192 hashes de bloco históricos em um contrato de sistema para usar como parte da lógica de processamento de bloco. O problema que esta proposta está tentando resolver é a suposição do EVM de que o cliente tem o hash de bloco recente. Esta abordagem baseada em suposições não se aplica ao futuro Ethereum e especialmente aos clientes sem estado.

Incluir os hashes dos blocos anteriores no estado permitirá agrupar esses hashes com funções de hash à vista de uma testemunha. Mais tarde, uma testemunha será fornecida ao cliente sem estado para verificar a execução e alcançar a execução sem estado. Essa proposta é chamada de especiação pré-PEI porque pode ser implementada antes da adaptação às tentativas de Verkle no protocolo principal e facilita a falta de estado parcial.

Estender o intervalo de blocos que blockHash serve para 8192 blocos permitirá uma transição suave para métodos de execução. Rollups podem se beneficiar desta janela de histórico mais longa consultando diretamente este contrato porque os dados de blockHash são armazenados neste contrato. Além disso, este PEI facilitará a validação de provas relacionadas à quantidade de 8192 blocos de HISTORY_SERVE_WINDOW contra o estado atual.

Compreendendo PEI-2935

O EIP-2935 permite que clientes Ethereum, especialmente os sem estado, acessem facilmente os hashes recentes de blocos. Para que isso funcione, ele introduz quatro novos parâmetros:

• BLOCKHASH_SERVE_WINDOW: Informa aos clientes quantos hashes de bloco passados eles devem manter. O valor padrão é 256.
• HISTORY_SERVE_WINDOW: Este parâmetro define quantos blocos de hashes são armazenados. O valor padrão é 8191.
• SYSTEM_ADDRESS: Um endereço especial (originalmente introduzido no PEI-4788) que age como o "chamador" para escrever hashes de bloco no armazenamento.
• HISTORY_STORAGE_ADDRESS: O endereço do contrato onde esses hashes de bloco são armazenados.

As especificações da proposta direcionam os últimos hashes de bloco do HISTORY_SERVE_WINDOW a serem armazenados em um armazenamento de buffer de anel com um comprimento de HISTORY_SERVE_WINDOW.

Buffer Circular

O EIP-2935 utiliza um recurso adicional chamado de buffer circular para armazenamento temporário. Um buffer circular é uma propriedade que permite a uma rede reutilizar o mesmo armazenamento para dados diferentes. O armazenamento no buffer circular é limitado à mesma localização de armazenamento a cada vez. O buffer circular no EIP-2935 é usado apenas para atender à janela de serviço de histórico necessária, já que o EIP-4788 e os acumuladores de estado de beacon permitem prova contra qualquer ancestral.

Regras e Especificações de Escolha de Fork

Após o fork, quando a rede iniciar com essas considerações PEI, o parâmetro HISTORY_STORAGE_ADDRESS será referido como SYSTEM_ADDRESS com entrada de block.parent.hash (padrão 32 bytes), limite de gás de 30.000.000 e valor 0. Esse processo acionará a função set() do contrato de histórico.

O processo de fork pós-proposta difere do processo de fork regular. Essa operação set() é uma operação de sistema geral, mas a chamada segue essas convenções:

• Deve executar até a conclusão
• Não conta contra o limite de gás do bloco
• Não segue o mecanismo de queima EIP-1559
• Se não houver código em HISTORY_STORAGE_ADDRESS, a chamada deve falhar sem erros fatais.

Este processo deve preencher o período de serviço de histórico do bloco HISTORY_SERVE_WINDOW para atender ao período de acionamento do buffer de anel. O contrato de histórico conterá apenas o hash pai do bloco de bifurcação, que serve como um hash de referência e o novo ponto de partida do hash.

Um contrato de histórico de hash de bloco terá duas operações: get() e set(). A operação set() é ativada se o chamador do contrato em uma transação for igual ao ENDEREÇO_DO_SISTEMA que foi introduzido com PEI-4788. Se o chamador e o ENDEREÇO_DO_SISTEMA não forem iguais ou não cumprirem as condições, a operação get() é ativada.

A operação get() é usada no EVM para localizar os hashes de bloco. Permite que os chamadores forneçam o número do bloco que estão consultando, se a entrada do calldata não for de 32 bytes (o que significa que é um hash de bloco.parent.hash válido) e se a solicitação estiver fora do intervalo ([block.number-HISTORY_SERVE_WINDOW, block.number-1]), reverte a transação.

set() leva block.parent.hash como calldata quando um chamador chama o contrato com uma transação. Ele também define o valor de armazenamento como calldata[0:32] no bloco.número-1 % HISTORY_SERVE_WINDOW.

O endereço de armazenamento do histórico será implantado via PEI-4788, que é referido acima como o modo de acessar hashes de bloco no EVM diretamente através da camada de consenso. O endereço de armazenamento do histórico terá o valor de nonce como 1 e estará isento do padrão de limpeza de nonce zero do PEI-161.

Lógica de Transição BLOCKHASH

Uma preocupação sobre este PEI é como fazer a transição da lógica de resolução BLOCKHASH após o fork. Duas abordagens principais estão sendo consideradas:

• Aguarde HISTORY_SERVE_WINDOW blocos para que todo o histórico relevante persista,
• Armazene todos os últimos hashes de blocos HISTORY_SERVE_WINDOW no bloco de bifurcação.

Desenvolvedores escolhem a primeira opção. É mais prático porque não requer nenhuma mudança temporária.

Qual é a diferença entre PEI-2935 e PEIs similares?

Propostas semelhantes de PEI foram feitas anteriormente para permitir e conseguir execução sem estado. O PEI-2935 difere dessas propostas anteriores porque visa as complexidades destacadas abaixo.

• Abordagem da Estrutura Trie: EIP-2935 não utiliza uma estrutura semelhante a um trie com várias camadas e, em vez disso, opta por uma única lista. Pelo contrário, o EIP-4444 propôs a poda de dados históricos em clientes de execução com mais de um ano. Outros EIPs com ambições semelhantes têm tries Verkle como requisitos.
• Escrever o PEI no código EVM: o PEI-2935 não requer uma mudança no EVM.
• Armazenamento Serial Ilimitado de Hashes: O armazenamento serial ilimitado de hash é ineficiente. Este PEI supera esse problema agrupando os hashes.

Considerações de segurança

Uma vez que o EIP-2935 utiliza contratos inteligentes, está sujeito a ataques de envenenamento de branch. No entanto, o tamanho da raiz do estado torna qualquer tentativa de atualização lenta e um ataque de envenenamento consideravelmente mais custoso.

O Que Poderia Trazer?

• Tornando os Sistemas de Oráculo sem Confiança Mais Rápidos: Nos oráculos baseados em Uniswap v2, qualquer pessoa com acesso ao nó Ethereum pode gerar uma prova do armazenamento do Uniswap e enviá-la para validação on-chain. O preço médio é determinado entre o bloco atual e o bloco da prova fornecida, com prova validada de até 256 blocos, uma vez que o blockHash suporta até 256 blocos. Beneficiando-se do PEI-2935, esse processo pode ser aprimorado permitindo o acesso a hashes de blocos mais antigos, o que significa que as provas podem ser validadas por um período mais longo.
• Permitir que contratos considerem afirmações de estados passados, sem a necessidade de confiança: a melhoria EIP-2935 cria a possibilidade de analisar dados de blockchain de dentro do EVM, sem a necessidade de confiança. Um cliente pode consultar o histórico, obter o hash e verificá-lo com outros nós. A solução pode tornar os clientes leves eficientes e fáceis de implementar.
• Conexão entre L1 <> L2: Para verificar uma mensagem de L2, L1 precisa saber sobre as raízes de estado e hashes de bloco de L2. No entanto, L1 em seu estado atual não pode acessar hashes de bloco arbitrários devido a limites de gás e restrições arquiteturais. A EIP-2935 permite que L1 verifique os dados históricos arbitrários com a capacidade de sondar provas de inclusão para eventos antigos. O acesso e o poder de verificação melhorarão, e o desempenho da conexão também.

Conclusão

PEI-2935 representa um passo crucial em direção ao objetivo de longo prazo de um Ethereum sem estado. Armazenar os últimos 8192 hashes de bloco em um contrato dedicado dentro dos endereços de estado aborda uma limitação fundamental no design atual. A suposição do Ethereum de que os clientes têm acesso inerente aos hashes de bloco recentes. No contexto da execução sem estado, onde os clientes não mantêm mais o estado completo, essa suposição torna-se desatualizada. O PEI-2935 resolve isso introduzindo um mecanismo leve, eficiente e não intrusivo que permite aos clientes sem estado acessar os dados históricos necessários sem modificar o EVM ou depender de estruturas de dados complexas como as tentativas Verkle.

Além da execução sem estado, esta proposta desbloqueia benefícios mais amplos em todo o ecossistema Ethereum. Ele aprimora as capacidades de oráculos sem confiança, estende a usabilidade de clientes leves e fortalece a interoperabilidade entre soluções de Camada 1 e Camada 2, permitindo a verificação confiável de dados de estado mais antigos. Sua implementação depende de um design limpo e eficiente em termos de gás, usando armazenamento de buffer circular e contratos de nível de sistema que evitam a necessidade de codificação rígida no EVM, oferecendo ao mesmo tempo simplicidade e escalabilidade.

À medida que o Ethereum continua sua evolução em direção a uma maior descentralização, escalabilidade e acessibilidade, o PEI-2935 serve como uma melhoria fundamental. Ele preenche a lacuna entre a arquitetura atual baseada em estado e o futuro sem estado idealizado e lança as bases para uma infraestrutura mais robusta, eficiente e sem permissão em todo o ecossistema blockchain.

Aviso Legal:

1. Este artigo é reproduzido a partir de [2077research]. Todos os direitos autorais pertencem ao autor original [Yiğit Yektin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipe do Gate Learn faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que seja mencionado.