Introdução

O que as blockchains armazenam e referem durante o processamento de 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. O estado, por mais importante que seja para as blockchains, tem um lado negativo; ele cresce 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 igual nos requisitos de hardware para os nós. O limiar de espaço elimina alguns nós ao longo do tempo, levando à centralização.EIP-2935propõe trazer a falta de estado para o Ethereum, aliviando os nós do fardo do tamanho. EIP-2935 é uma proposta de melhoria que tenta alcançar a falta 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. Os hashes em cada bloco são derivados dos dados do bloco em si criptograficamente. Esta inclusão liga as cadeias juntas com hashes, e o agrupamento implica que todos os participantes na rede concordam e sincronizam o estado de uma vez. Além disso, o acordo sobre os blocos agrupados sinaliza o Ethereum para atualizar seu estado global em cada participante na rede como um nó.

Alt: Alteração de estado no Ethereum

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

Um bloco contém vários campos no cabeçalho e no corpo. Por exemplo, o cabeçalho do bloco inclui os campos slot, proposer_index, parent_root, state_root e body. O corpo do bloco inclui randao_reveal, eth1_data, graffiti, proposer_slashings, attester_slashings, attestations, deposits, voluntary_exits, sync_aggregate e execution_payload. Cada campo tem diferentes parâmetros e atende a diferentes necessidades.

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

1. O proponente do bloco seleciona aleatoriamente um validador,
2. O validador agrupa as transações e executa-as para determinar um novo estado global,
3. Incluem esta informação num novo bloco e difundem-na para o resto do conjunto de validadores através 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 verificar o novo bloco como válido, ele o adiciona ao seu armazenamento.

A finalidade de um bloco e transação significa que não pode ser alterado sem uma queima significativa de ETH numa rede distribuída. Ethereum tem uma abordagem de "blocos de verificação" para gerir a finalização. O primeiro bloco em cada época é assumido como a verificação desse slot. Os validadores votam nesta suposição para a tornar uma verificação válida. Se dois terços do ETH total em jogo com votos de validadores elegem um par de verificações, as verificações são atualizadas para justificadas. As verificações justificadas anteriores são atualizadas após a próxima atualização de verificações, e tornam-se finalizadas. Se um ator malicioso quiser reverter um bloco finalizado, precisa comprometer-se a perder pelo menos um terço do fornecimento total de ETH em jogo. Embora exista um mecanismo chamadovazamento de inatividadeexiste para restaurar a finalidade impondo grandes penalizações nos fundos dos validadores e reduzindo as recompensas dos atestadores 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, esta quantidade vem do recálculo dos hashes da Merkle trie até um ponto de verificação. A saída do processo de hash para cada bloco é devolvida 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 utiliza a arquitetura de tentativa de Merkle com diferentes versões, como a Árvore de Patricia de Merkle.

Árvores de Merkle e Merkle Patricia

As estruturas de árvores, especialmente as Árvores de Merkle, são fundamentais para o armazenamento em blockchain. Sem as Árvores de Merkle, as blockchains tornam-se blocos únicos que são difíceis de processar sempre. Com as Árvores de Merkle, ou geralmente arquiteturas de árvore, as blockchains alcançam a completude com fragmentos básicos. Isso permite que elas se tornem participantes da rede com baixos requisitos de hardware.

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

O Ethereum prefere Tries de Merkle Patricia, uma estrutura de árvore de Merkle dual. Usa Tries Binárias para o tratamento de dados básicos, como dados de transação, uma vez que esta abordagem é mais eficiente para tais situações. No entanto, o Ethereum utiliza as Tries de Merkle Patricia mais complexas em casos complexos, como o tratamento de estado.

Num cenário de armazenamento de dados de trie de estado, o Ethereum utiliza um mapa de chave-valor. As chaves representam endereços e os valores representam declarações de conta. As tries de estado são mais dinâmicas do que as tries binárias. Assim, novas contas podem ser frequentemente inseridas, e chaves podem ser frequentemente inseridas e eliminadas. Este processo necessita de 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 alterará a própria raiz.

Alt: Árvore Trie Merkle Binária

Ethereum usa uma árvore de prova de Patricia Merkle modificada, que possui algumas características de PATRICIA (Algoritmo Prático para Recuperar Informações Codificadas em Alfanumérico) e a Merkle Trie com modificações ao longo dela. 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 raiz e os hashes que o originaram.

No final, modificar o estado com valores diferentes é impossível porque resultará num hash de raiz de estado diferente. Todas as estruturas de trie na camada de execução do Ethereum utilizam um Trie Merkle Patricia. A rede tem três tries: State Trie, Storage Trie e Transaction Trie. Além disso, cada bloco tem o seu próprio Receipts Trie. Embora os Tries de Merkle Patricia sejam eficientes de várias maneiras, o Ethereum está motivado a substituí-los por Tries de Verkle para alcançar a falta de estado.

Alt: Árvore de Patricia Merkle

Gas

O gás é a propriedade necessária na EVM para execução. Uma vez que a EVM utiliza e necessita 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

EIP-1559introduziu algumas alterações significativas ao mecanismo de taxas 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 EIP-1559, há um limite mínimo chamado taxa base e uma gorjeta chamada taxa de prioridade introduzida. Os blocos são propostos para começar a partir da transação com a taxa de prioridade mais alta. Após o processo de bloco, a taxa base é queimada e a taxa de prioridade é usada para incentivar os validadores.

Estado

O estado da blockchain pode ser definido como um conjunto de dados (ou variáveis) que descrevem um certo sistema num período específico. A internet tem estado quase desde o início, mas estava armazenada num único servidor. Com o Web3, um estado global mantido numa rede aberta e distribuída, garantida através de métodos descentralizados, foi introduzido. Todos podem visualizar e verificar o estado da rede distribuída sempre que desejarem.

A Ethereum inclui contas, saldos, contratos inteligentes implementados e armazenamento associado no estado global. O estado da Ethereum cresce com as adições e alterações a estes parâmetros. O crescimento do estado torna-se problemático quando o custo de hardware de hospedagem de um nó completo se torna proibitivo. Face a estes desafios, Vitalik Buterin introduzidoo conceito de Ethereum sem estado em 2017. Os métodos propostos para corrigir o crescimento do estado no Ethereum incluem a 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 desnecessários dos clientes após um certo período. Com os "pontos de verificação de subjetividade fraca", os clientes podem encontrar seu caminho para sincronizar desde o início 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 obtidas socialmente. No entanto, os checkpoints de subjetividade fraca implicam que todos os nós na rede responsáveis pelo consenso pertencem à cadeia canônica. Os checkpoints de subjetividade fraca ajudam o Ethereum PoS a ter o estado recente (checkpoint de subjetividade fraca) de uma fonte confiável para sincronizar a partir dela.

EIP-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 Ethereum lidam com os dados de estado; em vez disso, modifica o acesso aos dados históricos.

Expiração do Estado

O State Expiry procura eliminar o estado dos nós individuais se não tiver sido acedido recentemente. A expiração pode ser implementada pela terminação ser um fator de aluguer ou tempo. A expiração por aluguer significa impor uma sobretaxa às 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 como a de Estado são áreas de pesquisa abertas. As abordagens atuais para alcançar esses estados propostos envolvem a passagem por redes/provedores 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 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 para cada bloco consistem em todos os dados necessários para executar as transações contidas nesse bloco.

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

Outro esforço em direção à ausência de estado foi proposto através de EIP-4788. Esta proposta procurou expor as raízes dos blocos da cadeia de beacons na EVM. Semelhante à abordagem do Ponte Eth1-Eth2ligando a cadeia Beacon (camada de consenso) e a camada de execução, esta proposta permite acesso minimizado à confiança entre EVM e a camada de consenso.

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

A falta de estado no Ethereum é possível tanto como falta de estado fraco ou forte.

Estado de fraqueza

A fraqueza do estado sem estado é um estado 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. Coloca a responsabilidade pelo armazenamento de estado nos proponentes de bloco e exige que outros nós verifiquem os blocos sem armazenar os dados completos do estado.

Os proponentes de bloco precisam de armazenar os dados de estado completos. No entanto, os clientes verificadores não precisam de armazenar os dados de estado na rede. Em vez disso, podem armazenar a raiz do estado (um hash de todo o estado). A fragilidade da falta de estado requer Separação Propositor-Construtor (SPC) e Verkle 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.

Forte Ausência de Estado

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 blocos. Os proponentes de blocos armazenam apenas o estado em que estão a trabalhar, gerando testemunhas para contas relevantes. A proposta ainda precisa de mais desenvolvimento e inclui requisitos como Listas de Acesso ou EIP-2930.

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

Introdução ao EIP-2935

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

A EIP-2935 propõe armazenar os últimos 8192 hashes de bloco históricos num contrato de sistema para utilizar como parte da lógica de processamento de bloco. O problema que esta proposta está a tentar 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 stateless.

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. Esta proposta é chamada de especificação pré-Verkle porque pode ser implementada antes da adaptação às tentativas Verkle no protocolo central, e facilita a parcial falta de estado.

A extensão do intervalo de blocos que o blockHash serve para 8192 blocos permitirá uma transição suave para métodos de execução. Rollups podem beneficiar-se desta janela de histórico mais longa consultando diretamente este contrato, uma vez que os dados blockHash são armazenados neste contrato. Além disso, este EIP facilitará a validação de provas relacionadas com a quantidade de 8192 blocos da HISTORY_SERVE_WINDOW em comparação com o estado atual.

Compreensão EIP-2935

EIP-2935 permite aos clientes Ethereum, especialmente os sem estado, aceder facilmente aos hashes de blocos recentes. Para que isto funcione, introduz quatro novos parâmetros:

• BLOCKHASH_SERVE_WINDOW: Indica aos clientes quantos hashes de blocos passados 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 EIP-4788) que atua 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 indicam que os últimos hashes de blocos HISTORY_SERVE_WINDOW devem ser armazenados num armazenamento de buffer em anel com um comprimento de HISTORY_SERVE_WINDOW.

Buffer de Anel

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

Regras de Escolha de Fork e Especificações

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

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

• Deve ser executado até ao fim
• Não conta para o limite de gás do bloco
• Não segue o mecanismo de queima EIP-1559
• Se não existir código em HISTORY_STORAGE_ADDRESS, a chamada deve falhar sem erros fatais.

Este processo deve preencher o período de 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 fork, que serve como um hash de referência e o novo ponto de partida de hash.

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

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

set() aceita 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.numero-1 % HISTORY_SERVE_WINDOW.

O HISTORY_STORAGE_ADDRESS será implementado via EIP-4788, que é referido acima como a forma de aceder aos hashes de bloco diretamente no EVM através da camada de consenso. O HISTORY_STORAGE_ADDRESS terá o valor de nonce como 1 e estará isento do padrão de limpeza de nonce zero do EIP-161.

Lógica de Transição BLOCKHASH

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

• Aguardar HISTORY_SERVE_WINDOW blocos para que todo o histórico relevante persista,
• Armazenar todos os últimos hashes de bloco do HISTORY_SERVE_WINDOW no bloco de ramificação.

Os desenvolvedores escolhem a primeira opção. É mais prático porque não requer quaisquer alterações temporárias.

Qual é a diferença entre EIP-2935 e EIPs semelhantes?

EIPs semelhantes foram propostos anteriormente para permitir e alcançar a execução sem estado. O EIP-2935 difere dessas propostas anteriores porque visa as complexidades destacadas abaixo.

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

Considerações de Segurança

Uma vez que o EIP-2935 utiliza contratos inteligentes, ele corre o risco de ataques de envenenamento de ramificação. No entanto, o tamanho da raiz do estado torna qualquer tentativa de atualização lenta e um ataque de envenenamento consideravelmente mais dispendioso.

O Que Poderia Trazer?

• Tornar os Sistemas de Oráculos Sem Confiança Mais Rápidos: Nos oráculos baseados em Uniswap v2, qualquer pessoa com acesso ao nó Ethereum pode gerar uma prova de armazenamento da Uniswap e submetê-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 EIP-2935, esse processo pode ser melhorado 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 os contratos considerem afirmações de estados anteriores, sem confiança: A melhoria EIP-2935 cria a possibilidade de analisar dados da blockchain de dentro do EVM, sem confiar. Um cliente pode consultar o histórico, obter o hash e verificar com outros nós. A solução poderia tornar os clientes leves eficientes e fáceis de implementar.
• Ponte entre L1 <> L2: Para verificar uma mensagem de L2, L1 precisa de conhecer as raízes de estado e hashes de bloco de L2. No entanto, L1 no seu estado atual não consegue aceder a hashes de bloco arbitrários devido a limites de gas 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 irão melhorar, assim como o desempenho de ponte.

Conclusão

EIP-2935 representa um passo crucial para alcançar o objetivo de longo prazo do Ethereum sem estado. Armazenar os últimos 8192 hashes de bloco num 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 torna-se desatualizada no contexto de execução sem estado, onde os clientes não mantêm mais o estado completo. A EIP-2935 resolve isso introduzindo um mecanismo leve, eficiente e não intrusivo que permite aos clientes sem estado aceder a 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. Aumenta 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. A sua implementação baseia-se num design limpo e eficiente em termos de gás, utilizando armazenamento de buffer de anel e contratos a nível de sistema que evitam a necessidade de codificação rígida no EVM, oferecendo simultaneamente simplicidade e escalabilidade.

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

Aviso Legal:

1. Este artigo é reproduzido a partir de [2077research]. Todos os direitos de autor pertencem ao autor original [Yiğit YektinSe houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles lidarão 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 equipa Gate Learn faz traduções do artigo para outras línguas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que seja mencionado.