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 melhorar 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 aumentar 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 desta vez, Electra, corresponde à letra "E".

A atualização Pectra, que pode ser o hard fork com o maior número de Ethereum Improvement Proposals (EIP) da história do Ethereum, não apenas inclui uma série de propostas para melhorar as operações dos validadores e o desempenho da mainnet, mas também introduz 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 e permitindo operações mais complexas; aumentar o limite de staking, o que pode elevar a demanda por ETH; e otimizar os processos dos validadores, melhorando a segurança e eficiência, além de aumentar a velocidade e a capacidade de processamento 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 só, reduzindo a complexidade da verificação. A assinatura BLS é um algoritmo criptográfico que gera assinaturas menores e suporta agregação de assinaturas. Isso ajudará L2s que precisam realizar grande quantidade de verificações de assinaturas e validações de dados a operar melhor.
2. EIP-2935 (armazenamento de hashes de blocos históricos no estado): Armazena os hashes dos últimos 8192 blocos em contratos do sistema, para suportar o modelo de Stateless Clients e fornecer 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 (fornecimento on-chain de depósitos de validadores): 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 das informações de depósito. Isso aumenta a segurança do processo de depósito, reduz atrasos no processamento 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 certificados 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 de validação a terceiros (como provedores de serviços de staking), o detentor do certificado de saque (ou seja, o verdadeiro proprietário dos fundos) não pode controlar autonomamente o ETH em staking. Esta proposta permite que a camada de execução acione operações de saída e saque de ETH, possibilitando que o detentor do certificado 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 possa manter 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 combinar múltiplos validadores, diminuindo a carga de mensagens P2P, agregação de assinaturas e armazenamento.
6. EIP-7549 (remoção do índice de comitê da prova): Ao remover o campo de índice de comitê da mensagem de Attestation (prova), permite uma agregação mais eficiente dos votos de consenso. No mecanismo de consenso atual do Ethereum, cada validador inclui em seu voto: voto LMD GHOST (inclui o root do bloco votado e o slot), voto Casper-FFG (inclui informações de origem e destino) e índice de comitê (número do comitê ao qual o validador pertence). Como o índice de comitê está incluído na mensagem assinada, quando vários validadores votam no mesmo bloco, mesmo que o conteúdo do voto seja igual, as raízes das assinaturas geradas são diferentes, dificultando a agregação desses votos. Ao remover o campo de índice de comitê da mensagem assinada, é possível agregar votos de forma mais eficiente, reduzindo custos de verificaçã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 acionadas 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 do bloco de execução.
8. EIP-7702 (adiciona capacidade de execução de código às EOAs): Adiciona funcionalidade de execução de código às 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 determinadas operações, como transações em lote ou controle de permissões. Isso permite que as EOAs tenham certas funcionalidades de contratos inteligentes sem precisar se transformar em contas de contrato inteligente.

EIPs em consideração prioritária

A seguir estão alguns EIPs que estão sendo ativamente considerados, 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 do custo do calldata pode afetar a quantidade de ETH queimado, aumentando a pressão inflacionária sobre o ETH.

• EIP-7742 (desacoplamento da contagem de blobs entre a camada de consenso e a camada de execução): Desacopla o número de blobs entre a camada de consenso e a camada de execução, simplificando o processo de verificação de blobs, reduzindo complexidade desnecessária e aumentando a escalabilidade e flexibilidade do protocolo. No protocolo atual, tanto a camada de execução quanto a de consenso codificam rigidamente o valor máximo de blobs, levando a verificaçõ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 camada de execução. Assim, é possível ajustar de forma mais flexível os parâmetros de blobs para atender às necessidades futuras de escalabilidade. O EIP-7742 é o EIP menos controverso na lista de propostas 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 Layer Meeting).
• 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 nível de taxa apropriado. Ao aumentar a taxa mínima base para blobs, o tempo de ajuste de preço é reduzido, permitindo alcançar o equilíbrio de mercado mais rapidamente e garantindo que a rede permaneça estável mesmo 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 do bloco e sua variação, garantindo que a rede possa processar transações de forma mais estável. O tamanho máximo atual do bloco é de cerca de 1,79 MB, mas devido à grande quantidade de dados publicados por aplicações como rollups, o tamanho médio dos blocos continua aumentando. Ao aumentar o custo do calldata, principalmente para transações de disponibilidade de dados (DA), o tamanho máximo do bloco é reduzido para cerca de 0,72 MB, liberando espaço para futuros aumentos no limite de Gas do bloco ou para mais blobs. O custo das transações para usuários comuns permanece inalterado; essa mudança afeta principalmente tipos de transações que dependem do Ethereum para armazenamento de dados em larga escala. 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 queimado pelo mecanismo EIP-1559 e, consequentemente, 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 com mais frequência para processar mais transações, sendo uma alternativa ao aumento do número de blobs para aumentar a capacidade de processamento de transações. No entanto, isso pode afetar contratos inteligentes que codificaram rigidamente 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 uma alternativa mais suave ao EIP-7782, ajusta dinamicamente o limite de Gas do bloco, aumentando gradualmente o número de transações que cada bloco pode conter, melhorando a capacidade de processamento da rede. Em comparação com a 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 afetar os dados de estado.

Como a atualização Pectra inclui muitos EIPs, para reduzir a complexidade de uma única 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 atrasos na atualização, então a sugestão não foi considerada seriamente. Em setembro, o pesquisador do Ethereum, Alex Stokes, voltou a sugerir a divisão, e desta vez recebeu apoio dos desenvolvedores, pois essa divisão ajudaria 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á definidos), 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 teste. Essas propostas precisam de mais desenvolvimento, auditoria e testes, especialmente as que envolvem coordenação entre a camada de consenso e a camada de execução.