Quais EIPs foram confirmados para inclusão na atualização Pectra? Isso pode aumentar a inflação do ETH?

Os EIPs já definidos irão aprimorar a programabilidade das contas, a eficiência da validação do Ethereum e a otimização do staking, enquanto os EIPs ainda não definidos focam em como melhorar a escalabilidade do L2.

Autor: 0XNATALIE

A próxima atualização do Ethereum, Pectra, tem seu nome originado da combinação de Prague e Electra.

Prague representa a atualização da camada de execução, nomeada em homenagem à cidade de Praga, onde ocorreu a conferência de desenvolvedores do Ethereum (Devcon 4), enquanto Electra simboliza a atualização da camada de consenso, nomeada em ordem alfabética com nomes de estrelas. O nome da estrela escolhida nesta vez, Electra, corresponde à letra "E".

A atualização Pectra pode ser o hard fork com o maior número de Ethereum Improvement Proposals (EIP) da história do Ethereum, incluindo uma série de propostas para aprimorar as operações dos validadores e o desempenho da mainnet, além de introduzir propostas para otimizar o L2. A testnet Pectra Devnet 4 foi lançada recentemente, e atualmente já há 8 EIPs confirmados para inclusão na atualização Pectra.

EIPs confirmados e seus impactos

Esses 8 EIPs impactam os usuários ao: adicionar capacidade de execução de código às EOAs, aumentando a flexibilidade das contas para executar operações mais complexas; elevar o limite de staking, o que pode aumentar a demanda por ETH; e otimizar o processo dos validadores, melhorando a segurança, eficiência, velocidade e throughput do Ethereum.

1. EIP-2537 (suporte a assinaturas BLS): Ao introduzir uma série de contratos pré-compilados (precompiles), adiciona suporte para operações na curva BLS12-381 no Ethereum, permitindo a verificação de assinaturas BLS e a agregação de múltiplas assinaturas em uma única, reduzindo a complexidade da verificação. A assinatura BLS é um algoritmo criptográfico que gera assinaturas menores e suporta agregação. Isso ajudará L2s que precisam realizar grande volume de validações de assinaturas e dados a operar melhor.
2. EIP-2935 (armazenamento de hashes de blocos históricos no estado): Armazena os hashes dos 8192 blocos mais recentes em um contrato do sistema, suportando o modelo de Stateless Clients e fornecendo consultas mais flexíveis de hashes de blocos históricos. Esses hashes podem ser consultados diretamente por contratos e fornecidos como provas (witness) para clientes sem estado. O cliente não precisa manter todo o histórico da blockchain ou armazenar grandes volumes de dados, bastando confiar nos hashes de blocos armazenados no estado e nas provas relacionadas para validar blocos e transações.
3. EIP-6110 (depósitos de validadores on-chain): Move o processamento dos depósitos dos validadores da camada de consenso para a camada de execução, realizando o processamento e validação on-chain, sem depender de mecanismos de votação adicionais na camada de consenso para confirmar a validade dos depósitos. Isso aumenta a segurança do processo de depósito, reduz atrasos e simplifica o design da camada de consenso e dos clientes.
4. EIP-7002 (saída acionada pela camada de execução): Permite que os detentores de credenciais de saque iniciem saídas de forma independente, sem depender da chave ativa do validador (chave BLS), aumentando a autonomia do usuário. Atualmente, apenas a chave ativa do validador pode acionar a saída, o que significa que, se a chave ativa for perdida ou o validador delegar a tarefa a terceiros (como provedores de staking), o detentor da credencial de saque (ou seja, o verdadeiro dono dos fundos) não pode controlar o ETH em staking de forma autônoma. Esta proposta permite que a camada de execução acione a saída e o saque de ETH, possibilitando que o detentor da credencial de saque inicie a saída sem depender da chave ativa.
5. EIP-7251 (aumento do limite de staking): Aumenta o saldo máximo efetivo dos validadores, permitindo que cada validador mantenha mais de 32 ETH em staking, enquanto o limite mínimo permanece em 32 ETH. O objetivo é permitir que grandes operadores de nós reduzam o número de validadores na rede ao fundir múltiplos validadores, reduzindo a carga de mensagens P2P, agregação de assinaturas e armazenamento.
6. EIP-7549 (remoção do índice do comitê da prova): Ao remover o campo de índice do comitê da mensagem de Attestation (prova), permite uma agregação mais eficiente dos votos de consenso. Atualmente, no mecanismo de consenso do Ethereum, cada validador vota incluindo: voto LMD GHOST (com root do bloco e slot), voto Casper-FFG (com informações de origem e destino) e índice do comitê (número do comitê do validador). Como o índice do comitê está incluído na mensagem assinada, quando múltiplos validadores votam no mesmo bloco, mesmo que o conteúdo do voto seja igual, as raízes das assinaturas são diferentes, dificultando a agregação dos votos. Ao remover o índice do comitê da mensagem assinada, a agregação dos votos se torna mais eficiente, reduzindo custos de validação e carga na rede.
7. EIP-7685 (requisições genéricas da camada de execução): Define uma estrutura genérica para a camada de execução (EL) armazenar e processar requisições disparadas por contratos inteligentes. Essa estrutura suporta mais comportamentos acionados pela camada de execução e permite que diferentes tipos de requisições sejam processados de forma unificada, simplificando a adição de novos tipos de requisições sem modificar a estrutura dos blocos de execução.
8. EIP-7702 (capacidade de execução de código para EOAs): Adiciona funcionalidade de execução de código para contas de propriedade externa (EOA), aumentando a flexibilidade e programabilidade das contas. As EOAs podem, por meio de assinatura autorizada, designar um contrato inteligente para executar certas operações, como transações em lote ou controle de permissões. Assim, sem precisar se transformar em uma conta de contrato inteligente, a EOA adquire algumas funcionalidades típicas de contratos inteligentes.

EIPs em consideração prioritária

A seguir, alguns EIPs em consideração ativa, principalmente otimizando blobs para aumentar a estabilidade dos custos de publicação de dados no L2, aprimorando a capacidade de processamento de transações do L2 e reduzindo efetivamente os custos do L2. Além disso, o ajuste no custo do calldata pode impactar a quantidade de ETH queimada, aumentando a pressão inflacionária sobre o ETH.

• EIP-7742 (desacoplamento da contagem de blobs entre as camadas de consenso e execução): Desacopla a quantidade de blobs entre as camadas de consenso e execução, simplificando o processo de verificação de blobs, reduzindo complexidade desnecessária e aumentando a escalabilidade e flexibilidade do protocolo. Atualmente, ambas as camadas têm o valor máximo de blobs codificado, levando a validações redundantes. Esta proposta elimina a verificação do valor máximo de blobs pela camada de execução, passando a camada de consenso a fornecer dinamicamente o valor-alvo de blobs para a execução. Assim, é possível ajustar de forma mais flexível o parâmetro alvo de blobs para futuras necessidades de escalabilidade. O EIP-7742 é o menos controverso entre os EIPs em consideração para a atualização; segundo a última reunião da camada de consenso, os desenvolvedores concordaram em começar a implementar o EIP-7742 na pectra-devnet 5, mas sua inclusão oficial ainda depende do feedback da camada de execução na ACDE (All Core Devs Execution Call).
• EIP 7762 (taxa mínima base para blobs): Aumenta o MIN_BASE_FEE_PER_BLOB_GAS, com o objetivo de reduzir o tempo necessário para ajustar o preço dos blobs a um nível razoável. Atualmente, a taxa mínima base para blobs é de 1 wei; quando a demanda por blobs excede a oferta, o processo de descoberta de preço (ou seja, determinar o preço adequado do blob Gas) é muito lento, levando muito tempo para atingir um valor adequado. Ao aumentar a taxa mínima base, o ajuste de preço ocorre mais rapidamente, permitindo o equilíbrio de mercado e garantindo a estabilidade da rede em picos de demanda.
• EIP-7623 (aumento do custo do calldata): Aumenta o custo do calldata nas transações para reduzir o tamanho máximo dos blocos e sua variação, garantindo que a rede possa processar transações de forma mais estável. Atualmente, o tamanho máximo do bloco é de cerca de 1,79 MB, mas devido ao grande volume de dados publicados por aplicações como rollups, o tamanho médio dos blocos está aumentando. Ao aumentar o custo do calldata, usado principalmente para transações de disponibilidade de dados (DA), o tamanho máximo do bloco é reduzido para cerca de 0,72 MB, abrindo espaço para futuros aumentos no limite de Gas do bloco ou para mais blobs. O custo das transações comuns para usuários permanece inalterado; a mudança afeta principalmente transações que dependem do Ethereum para armazenamento massivo de dados. No entanto, o aumento do custo do calldata pode reduzir a competitividade do Ethereum no armazenamento de dados. Além disso, com o aumento do custo do calldata, o número de transações pode diminuir, reduzindo a quantidade de ETH queimada pelo mecanismo EIP-1559 e aumentando a pressão inflacionária sobre o ETH.
• EIP 7782 (redução do tempo de slot): Reduz o tempo de slot do Ethereum de 12 segundos para 8 segundos, gerando blocos mais frequentemente para processar mais transações, como alternativa ao aumento do número de blobs para melhorar o throughput. No entanto, isso pode quebrar contratos inteligentes que codificaram o tempo de slot em 12 segundos e acelerar o problema de crescimento do estado do Ethereum, aumentando a carga de armazenamento e computação.
• EIP-7783 (aumento gradual do limite de Gas do bloco): Como alternativa mais suave ao EIP-7782, ajusta dinamicamente o limite de gas do bloco, aumentando gradualmente o número de transações por bloco e, assim, a capacidade de processamento da rede. Comparado à redução direta do tempo de slot, o ajuste gradual do limite de gas permite uma expansão mais estável da rede. Esta proposta não requer hard fork, mas pode impactar os dados de estado.

Como a atualização Pectra inclui muitos EIPs, para reduzir a complexidade de cada atualização e acelerar a implementação de alguns EIPs, em maio, a equipe de engenharia da Ethereum Foundation, EthPandaOps, sugeriu dividir a Pectra em duas partes, mas na época havia preocupação com possíveis atrasos, então a ideia não foi levada adiante. Em setembro, o pesquisador do Ethereum, Alex Stokes, voltou a sugerir a divisão, desta vez recebendo apoio dos desenvolvedores. Essa divisão ajudará a concluir a primeira parte da atualização em seis meses:

• Primeira parte: Inclui os EIPs já em funcionamento na testnet Pectra Devnet (ou seja, os 8 EIPs já confirmados), que são relativamente mais fáceis de implementar e já passaram por muitos testes.
• Segunda parte: Inclui EIPs mais complexos (como PeerDAS, propostas relacionadas ao EOF) e outras propostas que exigem mais tempo de desenvolvimento, auditoria e testes, especialmente aquelas que envolvem coordenação entre as camadas de consenso e execução.