Encaminhar o Título Original: O Hardfork de Praga/Electra (Pectra) Explicado

apresentar

No nosso artigo anterior, analisamos extensivamente o ciclo de vida dos validadores Ethereum, discutindo vários aspectos relacionados à próxima atualização Electra. Agora, é hora de nos concentrarmos nas próximas mudanças tanto nas atualizações Electra quanto em Praga e explicá-las em detalhes.

A história das bifurcações de hardforks Ethereum 2.0 'prova de estaca' é complexa. Começou com a adição da camada de farol à camada de execução existente, lançando o consenso de prova de estaca na camada de farol mantendo ainda a prova de trabalho na camada de execução (os hardforks Phase0 e Altair). O PoS foi então totalmente ativado no hardfork Bellatrix (embora os levantamentos não estivessem ativados). Posteriormente, o hardfork Capella permitiu levantamentos, completando o ciclo de validação. O hardfork mais recente, Deneb (parte da atualização Dencun (Deneb/Cancun)), trouxe revisões menores aos parâmetros da cadeia de farol, como a janela de tempo para inclusão de testemunhos, tratamento de saídas voluntárias e o limite de rotação de validadores. As principais mudanças em Dencun foram na camada de execução, introduzindo inovações como transações de blob, gás de blob, compromissos KZG para blobs e a depreciação da operação SELFDESTRUCT.

Agora, o hardfork de Praga/Electra introduz melhorias significativas tanto nas camadas de execução quanto de consenso. Como auditores do projeto Lido, nosso foco está principalmente nas alterações de consenso e staking neste hardfork. No entanto, não podemos ignorar as alterações na camada de execução em Praga, pois incluem recursos críticos que impactam a rede e validadores do Ethereum. Vamos mergulhar nos detalhes dessas alterações.

Visão Geral de Alto Nível da Pectra

A Electra apresenta inúmeras funcionalidades para a camada de beacon. As principais atualizações incluem:

• Permitindo que os validadores tenham um saldo efetivo variando de 32 a 2048 ETH (em vez de um fixo de 32 ETH).
• Permitindo que validadores iniciem saídas com credenciais secundárias de “saque” (não sendo mais necessário a chave ativa do validador).
• Alterando a forma como os depósitos Eth1 são processados pela camada beacon (afastando-se da análise de eventos do contrato de depósito).
• Adição de um novo framework de propósito geral para lidar com pedidos de contratos Eth1 regulares na camada beacon (semelhante à forma como os depósitos eram geridos antes do Electra).

Entretanto, Praga introduz alterações na camada de execução, tais como:

• Um novo contrato pré-compilado suportando a curva BLS12-381 para verificar provas zkSNARK (além da popular curva BN254).
• Um novo contrato de sistema para armazenar e aceder até 8192 hashes de bloco históricos (útil para clientes sem estado).
• Aumento dos custos de gás de chamada de dados para reduzir o tamanho do bloco e incentivar projetos a mover operações intensivas em chamadas de dados (como rollups) para blobs, que foram introduzidos em Dencun.
• Suporte para um maior número de blocos por bloco Eth1, juntamente com uma API para ler estes números.
• Permitindo que as EOAs (Contas de Propriedade Externa) tenham seu próprio código de conta, expandindo drasticamente o que as EOAs podem fazer, como executar multicamadas ou delegar a execução a outros endereços.

Vamos referenciar as Propostas de Melhoria do Ethereum (EIPs) relevantes para facilitar mais discussão:

• EIP-7251: Aumentar o MAX_EFFECTIVE_BALANCE
• EIP-7002: Saídas acionáveis da camada de execução
• EIP-6110: Fornecer depósitos de validação na cadeia
• EIP-7549: Mover o índice do comité para fora da Attestation
• EIP-7685: Pedidos de camada de execução de propósito geral
• EIP-2537: Pré-compilação para operações de curva BLS12-381
• EIP-2935: Guardar hashes de blocos históricos no estado
• EIP-7623: Aumentar o custo do calldata
• EIP-7691: aumento da taxa de transferência de blob
• EIP-7840: Adicionar programação de blob aos ficheiros de configuração EL
• EIP-7702: Definir o código da conta EOA

Alguns desses EIPs abordam principalmente a camada de consenso (beacon), enquanto outros se referem à camada de execução. Alguns abrangem ambas as camadas, pois certas operações como depósitos e saques exigem alterações sincronizadas em todas as camadas de consenso e execução. Devido a essa interdependência, separar Electra e Prague é impraticável, portanto, revisaremos cada EIP sequencialmente e especificaremos o componente Ethereum afetado em cada caso.

EIP-7251: Aumentar o LIMITE_EFETIVO_MÁXIMO

Referência: EIP-7251

Desde o primeiro hardfork da Fase0, implementado para preparar o Ethereum para o Proof-of-Stake, e até ao Electra, o saldo efetivo máximo de um validador estava fixado em 32 ETH. Ativar um validador requer pelo menos o spec.min_activation_balance (32 ETH). Após a ativação, o validador começa com este saldo efetivo máximo, mas pode reduzir o seu saldo efetivo para o spec.ejection_balance (16 ETH) e é expulso ao atingir esse limite. Esta lógica "mínima" permanece inalterada no Electra, mas agora o spec.max_effective_balance aumentou para 2048 ETH. Como resultado, um validador pode depositar entre 32 e 2048 ETH para ativação, sendo que todos os montantes neste intervalo contribuem para o seu saldo efetivo. Esta mudança marca uma transição de "prova-de-32ETH-stake" para um "proof-of-stake" :)

Este saldo efetivo variável será agora utilizado:

• aumentar a probabilidade de ser um proponente de bloco, proporcional ao saldo efetivo
• aumentar a probabilidade de ser membro do comité de sincronização, proporcional ao saldo efetivo
• como base para calcular os montantes relativos a penalidades por corte e inatividade

As primeiras duas atividades são as ações mais gratificantes para validadores. Consequentemente, após Electra, validadores com maiores participações irão participar com mais frequência na proposição de blocos e comitês de sincronização, proporcionalmente ao seu saldo efetivo.

Outro efeito está relacionado aos cortes. Todas as penalidades de corte são proporcionais ao saldo efetivo do validador:

• As penalidades de redução "imediatas" e "diferidas" são maiores para validadores com apostas mais altas.
• As penalidades de corte "diferido" para validadores cortados ao lado de validadores de grandes estacas também são maiores, à medida que a fração "cortada" da participação total se torna maior.
• Um denunciante que relata um validador com um saldo efetivo mais alto recebe uma fração maior da participação cortada.

Electra também propõe alterações nas quotas de corte, definindo uma fração do saldo dos validadores que é cortada e recebida pelo denunciante.

Os efeitos da inatividade são os seguintes. Quando um validador está offline enquanto ativo (atestando ou propondo), uma pontuação de inatividade se acumula, levando a penalidades por inatividade aplicadas a cada época. Essas penalidades também são proporcionais ao saldo efetivo do validador.

Os limites de "churn" do validador também sofrem alterações devido aos saldos efetivos aumentados. No Ethereum “pré-Electra”, os validadores geralmente têm o mesmo saldo efetivo, e o limite de churn de saída é definido como “não mais do que 1/65536 (spec.churn_limit_quotient) da participação total pode sair em um único período”. Isso cria um número "fixo" de saídas de validadores com a mesma participação. No entanto, no “pós-Electra”, é possível um cenário em que apenas alguns "baleias" saem, pois representam uma parte significativa da participação total.

Outra consideração é a rotação de muitas chaves de validador em uma única instância de validador. Os validadores grandes são atualmente forçados a executar milhares de chaves de validador em uma única instância para acomodar grandes participações, dividindo-os em partes de 32 ETH. Com Electra, este comportamento já não é obrigatório. Financeiramente, esta mudança faz pouca diferença, uma vez que as recompensas e as probabilidades escalam linearmente com o montante apostado. Assim, 100 validadores com 32 ETH cada são equivalentes a um validador com 3200 ETH. Além disso, várias chaves de validador ativas podem ter as mesmas credenciais de levantamento Eth1, permitindo que todas as recompensas sejam levantadas para um único endereço ETH e evitando os custos de gás associados à consolidação de recompensas. No entanto, gerir um grande número de chaves incorre em custos administrativos adicionais.

A capacidade de consolidar saldos de validadores adiciona outro tipo de pedido de camada de execução. Anteriormente, tínhamos depósitos e levantamentos. Agora, haverá outro tipo: um pedido de consolidação. Vai fundir dois validadores em um. Este pedido de operação incluirá o pubkey do validador de origem e o pubkey de destino, e será processado de forma semelhante aos depósitos e levantamentos. As consolidações também terão pedidos pendentes e limites de churn de saldo, tal como os depósitos e levantamentos.

Para resumir:

• Para pequenos validadores individuais, a Electra introduz a capacidade de aumentar automaticamente o seu saldo efetivo (e recompensas). Anteriormente, qualquer excedente acima de 32 ETH só poderia ser levantado, mas após a Electra, esse excedente acabará por contribuir para o seu saldo efetivo. No entanto, o saldo efetivo só pode aumentar em múltiplos de spec.effective_balance_increment (1 ETH), o que significa que o aumento ocorre apenas após atingir o próximo limite de "1 ETH".
• Para validadores solitários de grande porte, o Electra oferece uma simplificação significativa de gestão, permitindo a consolidação de várias chaves de validador ativas em uma só. Embora não seja uma mudança de jogo, operar uma única participação de 1x2048 é indiscutivelmente mais simples do que gerir 64 participações de 32.
• Para os fornecedores de participação líquida, que reúnem pequenas participações dos utilizadores e as distribuem entre os validadores, o Electra adiciona mais flexibilidade nos esquemas de distribuição de participação, mas, ao mesmo tempo, requer uma reestruturação séria da contabilidade do validador, que atualmente se baseia num saldo efetivo fixo de 32 ETH.

Outro tópico importante é a data histórica e a estimativa de lucro para validadores, o que é especialmente relevante para novos participantes que tentam avaliar riscos e retornos. O limite de 32 ETH (tanto mínimo quanto máximo, na prática) antes da Electra (na data da escrita deste artigo) criou uniformidade nos dados históricos. Todos os validadores tinham saldos efetivos iguais, recompensas, penalidades de slashing individuais, frequências de proposta de bloco e outras métricas. Essa uniformidade permitiu que o Ethereum testasse seu mecanismo de consenso com um grande número de validadores sem valores atípicos estatísticos, reunindo dados valiosos sobre o comportamento da rede.

Após a Electra, a distribuição das apostas mudará significativamente. Grandes validadores participarão com mais frequência nas propostas de bloco e no comitê de sincronização, receberão penalidades maiores em eventos de corte e terão maior influência nas filas de corte adiado, filas de ativação e filas de saída. Embora isso possa criar desafios na agregação de dados, o consenso do Ethereum garante que os cálculos não lineares sejam mínimos. O único componente não linear usa sqrt(total_effective_balance) para calcular a recompensa base, que se aplica uniformemente a todos os validadores. Isso significa que as recompensas e penalidades dos validadores ainda podem ser estimadas com base em “por 1 ETH” (ou, mais precisamente, por spec.effective_balance_increment, que pode potencialmente mudar no futuro).

Para mais detalhes, consulte o nosso artigo anterior sobre o comportamento do validador.

EIP-7002: Saídas acionáveis da camada de execução

Referência: EIP-7002

Cada validador no Ethereum possui dois pares de chaves: uma chave ativa e uma chave de retirada. A chave pública ativa BLS serve como a principal identidade do validador na cadeia do beacon, e este par de chaves é usado para assinar blocos, atestações, cortes, agregados do comitê de sincronização e (até este EIP) saídas voluntárias (para iniciar a saída do validador do consenso após um atraso). O segundo par de chaves ("credenciais de retirada") pode ser outro par de chaves BLS ou uma conta Eth1 regular (chave privada e endereço). Agora, retirar para um endereço ETH requer uma mensagem de retirada assinada pela chave privada ativa BLS. Este EIP muda isso.

Na prática, os proprietários destes dois pares de chaves (ativos e de retirada) podem ser diferentes. A chave ativa do validador é responsável pelas tarefas de validação: executar servidores, mantê-los operacionais, etc., enquanto as credenciais de retirada são geralmente controladas pelo proprietário da aposta, que recebe recompensas e é responsável pelos fundos. Atualmente, um proprietário de participação que controla apenas as credenciais de retirada não pode iniciar a saída do validador e só pode retirar recompensas. Essa situação permite que o proprietário da chave ativa do validador mantenha efetivamente o saldo do validador como "refém". Os validadores podem "pré-assinar" mensagens de saída e fornecê-las aos proprietários de estacas, mas essa solução alternativa não é ideal. Além disso, tanto as retiradas quanto as saídas atualmente exigem a interação com o validador de camada beacon usando APIs especializadas.

A solução ideal é permitir que os proprietários de participações realizem tanto operações de saída quanto de retirada usando uma chamada regular de contrato inteligente. Isso envolve uma verificação padrão de assinatura Eth1, simplificando muito as operações.

Este EIP permite aos proprietários de participações desencadear levantamentos e saídas através de uma transação padrão do seu endereço ETH para um contrato inteligente dedicado (semelhante ao processo de depósito existente que utiliza o contrato "Deposit"). O processo de levantamento (ou saída se for removida participação suficiente) funciona da seguinte forma:

• O proprietário da participação envia um pedido de levantamento (pedido "in") para o contrato "Retiradas" do sistema.
• O contrato cobra uma taxa específica (em ETH) para mitigar possíveis ataques de sabotagem e opera de forma semelhante ao EIP-1559, com as taxas aumentando quando a fila de solicitações está ocupada.
• O contrato guarda o pedido de retirada/saída “in” no seu armazenamento.
• Quando um bloco é proposto para a camada de beacon, os pedidos de saída “in” em fila são recuperados do armazenamento.
• A camada do farol processa os pedidos de entrada, interagindo com o saldo do validador ativo, agendando o validador para sair e formando pedidos de retirada de saída.
• Os pedidos de retirada "out" são processados na camada de execução e o proprietário da aposta recebe seus ETH.

Enquanto os depósitos foram operações acionadas em blocos Eth1 e depois "movidos" para a camada Beacon usando a fila de depósitos "pendentes", as retiradas seguiram um esquema diferente. Elas foram acionadas na camada Beacon (via CLI) e depois "movidas" para blocos Eth1. Agora, ambos os esquemas irão operar usando a mesma estrutura genérica (descrita abaixo): criação de solicitações na camada Eth1, processamento da fila de depósitos/retiradas/consolidações "pendentes" e processamento na camada Beacon. Para operações de "saída" como retiradas, a fila de saída também é processada e os resultados são "resolvidos" em blocos Eth1.

Com este EIP, os proprietários de participações podem levantar e sair dos seus validadores usando transações ETH regulares sem necessidade de interagir diretamente com o CLI do validador ou aceder à infraestrutura dos validadores. Isto simplifica grandemente as operações de participação, especialmente para grandes fornecedores de participações. A infraestrutura dos validadores pode agora estar quase totalmente isolada, uma vez que apenas as chaves de validadores ativos precisam ser mantidas, enquanto todas as operações de participação podem ser tratadas noutro local. Isto elimina a necessidade de participantes individuais esperarem por ações de validador ativas e simplifica significativamente as partes fora da cadeia para serviços como o Módulo de Participação da Comunidade do Lido.

Como resultado, este EIP “completa” as operações de staking ao migrá-las totalmente para a camada Eth1, reduz significativamente os riscos de segurança da infraestrutura e melhora a descentralização das iniciativas de staking solo.

EIP-6110: Fornecer depósitos de validador na cadeia

Referência: EIP-6110

Atualmente, os depósitos são implementados através de eventos no contrato “Deposit” do sistema (conforme discutido detalhadamente num artigo anterior). O contrato aceita ETH e credenciais do validador, emite um evento “Deposit()”, e esses eventos são posteriormente analisados e transformados em pedidos de depósito na camada de beacon. Este sistema tem inúmeras desvantagens: requer a votação de eth1data na camada de beacon chain, o que adiciona atrasos significativos. Além disso, a camada de beacon precisa consultar a camada de execução, introduzindo mais complexidade. Estes problemas são discutidos detalhadamente no EIP. Um método mais simples, eliminando muitos destes problemas, envolve incluir diretamente os pedidos de depósito nos blocos Eth1 num local designado. Este mecanismo espelha o processo de tratamento de retirada descrito no EIP anterior.

As alterações propostas neste EIP são promissoras. O processamento eth1data agora pode ser completamente removido, eliminando a necessidade de votação ou longos atrasos entre eventos no lado Eth1 e a inclusão de depósitos na camada beacon (atualmente cerca de 12 horas). Também remove a lógica para snapshots de contrato de depósito. Este EIP simplifica o processamento de depósitos e alinha-o com o esquema de processamento de levantamentos descrito acima.

Tanto para os proprietários de participações como para os validadores, estas mudanças reduzem significativamente o atraso entre um depósito e a ativação do validador. As recargas, que são necessárias quando um validador é penalizado, também serão mais rápidas.

Não há muito mais a dizer sobre este EIP além de que remove lógica desatualizada, simplificando processos e criando melhores resultados para todos os envolvidos.

EIP-7685: Pedidos de camada de execução de propósito geral

Referência: EIP-7685

Este EIP deveria, sem dúvida, ter sido apresentado antes dos três EIPs anteriores relacionados com depósitos/levantamentos/consolidação, uma vez que lança as bases para eles. No entanto, é introduzido aqui para enfatizar a crescente necessidade de mecanismos genéricos para mover consistentemente dados especializados entre os blocos (camadas) da cadeia Eth1 (execução) e Beacon (consenso). Este EIP afeta ambas as camadas, tornando o processamento de pedidos desencadeados por transações ETH regulares mais eficiente. Atualmente, observamos:

• Eventos de depósito em blocos Eth1 sendo "movidos" de Eth1 para blocos Beacon para processamento.
• Pedidos de levantamento em blocos Beacon (usando CLI) sendo "movidos" para blocos Eth1 para processamento.
• A necessidade de lidar com consolidações de validadores, que também são os pedidos Eth1->Beacon.

Estas três operações demonstram a necessidade de um tratamento consistente para os vários tipos de pedidos à medida que transitam entre as camadas de execução e beacon. Além disso, precisamos da capacidade de desencadear essas operações apenas usando a camada Eth1, pois isso nos permitirá isolar a infraestrutura dos validadores da infraestrutura de gestão de participações, aumentando a segurança. Portanto, uma solução genérica para gerir tais pedidos é prática e essencial.

Esta EIP estabelece um framework para pelo menos três casos principais: depósitos, levantamentos e consolidações. É por isso que EIPs anteriores introduziram campos como WITHDRAWAL_REQUEST_TYPE e DEPOSIT_REQUEST_TYPE, e agora as consolidações vão adicionar outro, CONSOLIDATION_REQUEST_TYPE. Além disso, esta EIP provavelmente incluirá mecanismos comuns para lidar com limites para tais pedidos (referência constantes: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

Embora os detalhes de implementação específicos para este framework ainda não estejam disponíveis, certamente incorporará tipos de solicitação chave, mecanismos de integridade (por exemplo, hash e Merkle-izando solicitações) e processamento de fila pendente com limitação de taxa.

Este EIP tem significado arquitetónico, permitindo que o Eth1 acione ações críticas na camada Beacon através de um framework unificado. Para os utilizadores finais e projetos, isto significa que todos os pedidos acionados na camada Eth1 serão entregues e processados na camada Beacon de forma muito mais eficiente.

EIP-2537: Pré-compilação para operações de curva BLS12-381

Referência: EIP-2537

Se não quiser aprofundar muito, pode pensar no precompilado BLS12-381 como uma operação criptográfica complexa de "hashing" que agora pode ser usada em contratos inteligentes. Para aqueles interessados, vamos explorar isso mais a fundo.

As operações matemáticas em curvas elípticas como BLS12-381 (e sua contraparte: BN-254) são atualmente usadas para dois propósitos principais:

• Assinaturas BLS, onde uma operação especial chamada “pairing” é usada para verificar essas assinaturas. As assinaturas BLS são amplamente utilizadas pelos validadores, pois permitem a agregação de múltiplas assinaturas em uma única. Os validadores dependem de assinaturas BLS baseadas na curva BLS12-381 (embora também possam ser implementadas usando qualquer curva que suporte pairings, como a BN254).
• Verificação de provas zkSNARK, onde são utilizados emparelhamentos para validar provas. Além disso, os compromissos KZG para blobs (introduzidos pelo hard fork Dencun) também usam emparelhamentos para verificar os compromissos de blobs.

Se desejar verificar uma assinatura BLS ou uma prova zkSNARK num contrato inteligente, terá de calcular essas "combinações" que são computacionalmente dispendiosas. O Ethereum já possui um contrato pré-compilado para operações na curva BN254 (EIP-196 e EIP-197). No entanto, a curva BLS12-381 (que é agora reconhecida como mais segura e é muito mais amplamente usada hoje) ainda não foi implementada como pré-compilação. Sem essa pré-compilação, a implementação de combinações e outras operações de curva em contratos inteligentes requer cálculos intensivos, conforme mostrado aqui, e consome enormes quantidades de gás (~10^5 a 10^6 gás).

Este EIP abre a porta a muitas aplicações potenciais, especialmente ao permitir a verificação barata de assinaturas BLS com base na curva BLS12-381. Isso torna possível implementar esquemas de limiar para vários fins. Como mencionado anteriormente, os validadores do Ethereum já utilizam assinaturas baseadas em BLS12-381. Com este EIP, contratos inteligentes padrão podem agora realizar verificação eficiente de assinaturas de validadores agregados. Isso pode simplificar as provas de consenso e a ponte de ativos entre redes, já que as assinaturas BLS são amplamente utilizadas em blockchains. As assinaturas BLS de limiar por si só permitem a construção de muitos esquemas de limiar eficientes para votação, geração de números aleatórios descentralizada, multisigs, etc.

A verificação mais barata de provas zkSNARK, por sua vez, desbloqueará inúmeras aplicações. Muitas soluções baseadas em zkSNARK estão atualmente impedidas pelos altos custos de verificação de provas, tornando certos projetos quase impraticáveis. Este EIP tem o potencial de mudar isso.

EIP-2935: Guardar os hashes dos blocos históricos no estado

Referência: EIP-2935

Esta EIP propõe armazenar 8192 (~27.3 horas) hashes de bloco históricos dentro do estado da blockchain, fornecendo um histórico estendido para clientes sem estado (como rollups) e contratos inteligentes. Sugere manter o comportamento atual do opcode BLOCKHASH, mantendo a restrição para 256 blocos, ao mesmo tempo que introduz um novo contrato do sistema projetado especificamente para armazenar e recuperar hashes históricos. Este contrato realiza uma operação set() quando a camada de execução processa um bloco. Seu método get(), acessível a todos, recupera o hash de bloco necessário de um buffer circular.

Atualmente, é possível fazer referência a hashes de blocos históricos dentro do EVM, mas o acesso é limitado aos 256 blocos mais recentes (~50 minutos). No entanto, há casos em que o acesso a dados de bloco mais antigos é essencial, como para aplicativos de cadeia cruzada (que exigem dados de comprovação de blocos anteriores) e clientes sem monitoração de estado, que periodicamente precisam de acesso a hashes de bloco anteriores.

Este EIP estende o horizonte temporal disponível para rollups e aplicações cross-chain, permitindo-lhes aceder diretamente a dados históricos no EVM sem a necessidade de os recolher externamente. Como resultado, estas soluções tornam-se mais robustas e sustentáveis.

EIP-7623: Aumentar o custo de calldata

Referência: EIP-7623

Os custos de dados de chamada regulam o tamanho disponível das cargas de transação, que em alguns casos podem ser bastante grandes (por exemplo, ao passar grandes matrizes ou buffers binários como parâmetros). O uso significativo de calldata é atribuído principalmente aos rollups, que enviam cargas via calldata contendo o estado atual do rollup.

A capacidade de introduzir dados binários grandes e comprováveis na blockchain é essencial para os rollups. A atualização Dencun (Deneb-Cancun) introduziu uma grande inovação para tais casos de uso — transações de blob (EIP-4844). As transações de blob têm suas próprias taxas de gás dedicadas “blob”, e enquanto seus corpos são armazenados temporariamente, suas provas criptográficas (compromissos KZG), juntamente com seus hashes, são integrados na camada de consenso. Os blobs assim fornecem uma solução superior para os rollups em comparação com o uso de calldata para armazenamento de dados.

Incentivar rollups a transicionar seus dados para blobs pode ser alcançado usando uma abordagem de “cenoura e pau”. As taxas de gás reduzidas para blobs servem como a “cenoura”, enquanto este EIP funciona como o “pau” ao aumentar os custos de calldata, desencorajando assim o armazenamento excessivo de dados em transações. Este EIP complementa o próximo EIP-7691 (Aumento do throughput de blobs), que aumenta o número máximo de blobs permitidos por bloco.

EIP-7691: Aumento do rendimento do blob

Referência: EIP-7691

Blobs foram introduzidos no hard fork Dencun anterior, e os valores iniciais para o número máximo e alvo de blobs "por bloco" eram estimativas conservadoras. Isso ocorreu devido à complexidade de prever como a rede p2p lidaria com a propagação de grandes objetos binários entre nós validadores. A configuração inicial provou funcionar bem, tornando este um momento apropriado para testar novos valores. Anteriormente, o número alvo/máximo de blobs por bloco era definido em 3/6. Estes limites estão agora a ser aumentados para 6/9, respetivamente.

Quando combinado com o EIP-7623 anterior (Aumento do custo do calldata), este ajuste motiva ainda mais os rollups a fazer a transição de seus dados do calldata para blobs. A busca por parâmetros de blob ótimos continua.

EIP-7840: Adicionar programação de blob aos arquivos de configuração do EL

Referência: EIP-7840

Esta EIP propõe adicionar o número alvo e máximo de “por bloco” blobs (discutido anteriormente) e os valores baseFeeUpdateFraction nos ficheiros de configuração da Camada de Execução Ethereum (EL). Também permite que os clientes recuperem esses valores através da API do nó. Esta funcionalidade é particularmente útil para tarefas como a estimativa de taxas de gás de blobs.

EIP-7702: Definir código da conta EOA

Referência: EIP-7702

Este é um EIP altamente significativo que trará grandes mudanças para os utilizadores do Ethereum. Como sabemos, uma EOA (Conta Possuída Externamente) não pode ter qualquer código, mas pode fornecer uma assinatura de transação (tx.origin). Em contraste, um contrato inteligente tem bytecode, mas não pode avançar com a sua própria assinatura direta. Qualquer interação de um utilizador que exija lógica adicional, automática e verificável, só pode ser alcançada atualmente chamando um contrato externo para executar as ações necessárias. No entanto, nesses casos, o contrato externo torna-se o msg.sender para contratos subsequentes, tornando a chamada "uma chamada de um contrato, não do utilizador."

Esta EIP introduz um novo tipo de transação SET_CODE_TX_TYPE=0x04 (anteriormente tínhamos as antigas transações 0x1, as transações mais recentes 0x02 das atualizações Berlin e EIP-1559, e as transações de blob 0x03 introduzidas em Dencun). Este novo tipo de transação permite definir código para uma conta EOA. Basicamente, permite que uma EOA execute código externo 'no contexto de sua própria conta EOA'. Do ponto de vista externo, parece que, durante uma transação, a EOA 'empresta' código de um contrato externo e o executa. Tecnicamente, isso é possível adicionando tuplos de dados de autorização especiais ao armazenamento de 'código' do endereço EOA (antes desta EIP, este armazenamento de 'código' estava sempre vazio para as EOAs).

Atualmente, esta EIP propõe que o novo tipo de transação 0x04 inclua uma matriz:

authorization_list = [[chain_id, endereço, nonce, paridade_y, r, s], …]

onde cada elemento permite que a conta use o código do endereço especificado (do último item de autorização válido). O processamento de tal transação define o código do EOA fornecido para um valor especial 0xef0100 || endereço (23 bytes), onde o endereço aponta para um contrato com o código desejado a ser executado, || denota concatenação, e 0xef0100 representa um valor mágico especial que contratos inteligentes regulares não podem conter (conforme EIP-3541). Este valor mágico garante que este EOA não possa ser tratado como um contrato regular ou ter chamadas feitas a ele como tal.

Quando este EOA inicia uma transação, o endereço especificado será usado para chamar o código correspondente no contexto desse EOA. Embora os detalhes completos de implementação deste EIP ainda não sejam conhecidos, é certo que trará mudanças significativas.

Um grande impacto é permitir a capacidade de fazer chamadas múltiplas diretamente de um EOA. Multicalls são uma tendência contínua em DeFi, com muitos protocolos oferecendo esse recurso como uma ferramenta poderosa (exemplos incluem Uniswap V4, Balancer V3 ou Euler V2). Com este PIE, as chamadas múltiplas podem agora ser efetuadas diretamente a partir das EOA.

Por exemplo, esse novo recurso resolve um problema comum no DeFi: a ineficiência de approve() + anything() que requer duas transações separadas. Este EIP permite uma lógica genérica de "pré-aprovação", possibilitando que ações como approve(X) + deposit(X) sejam concluídas em uma única transação.

Outra vantagem introduzida pela capacidade de delegar a execução de transações "em nome" de um EOA é o conceito de patrocínio. Patrocínios são frequentemente discutidos e recursos altamente desejados para integrar novos usuários ao Ethereum.

A lógica programável associada a um EOA desbloqueia inúmeras possibilidades, como implementar restrições de segurança, definir limites de gastos, impor requisitos de KYC e muito mais.

Naturalmente, esta mudança também levanta muitas questões de design. Uma questão é o uso do chain_id, que determina se a mesma assinatura pode ou não ser válida em várias redes com base na sua inclusão ou exclusão na assinatura. Outra questão complexa é se usar o endereço do código alvo versus incorporar o bytecode real. Ambas as abordagens têm características e limitações únicas. Além disso, o uso do nonce desempenha um papel fundamental na definição se as permissões são "multi-uso" ou "único uso". Esses elementos influenciam características e preocupações de segurança, incluindo aspectos como invalidação em massa de assinaturas e facilidade de uso. Vitalik levantou essas questões numa discussão (aqui), que merecem ser exploradas mais a fundo.

É crucial notar que esta mudança terá impacto em um dos mecanismos de segurança do Ethereum, tx.origin. Mais detalhes sobre a implementação deste EIP são necessários, mas parece que o comportamento de require(tx.origin == msg.sender) irá mudar. Esta verificação tem sido a forma mais confiável de garantir que msg.sender é um EOA e NÃO um contrato. Outros métodos, como verificar EXTCODESIZE (para verificar se É um contrato), frequentemente falham e podem ser contornados (por exemplo, chamando de um construtor ou implantando código em um endereço predefinido após uma transação). Estas verificações têm sido usadas para prevenir ataques de reentrância e flashloan, mas estão longe de ser ideais, uma vez que também impedem integrações com protocolos externos. Após este EIP, até mesmo a verificação confiável require(tx.origin == msg.sender) parece tornar-se obsoleta. Os protocolos devem adaptar-se removendo tais verificações, uma vez que a distinção entre “EOA” e “contrato” já não se aplicará — agora, cada endereço pode potencialmente ter código associado.

A separação tradicional entre EOA e contratos inteligentes continua a desvanecer-se. Este EIP aproxima o Ethereum de designs como TON, onde cada conta é essencialmente código executável. Esta evolução é natural à medida que as interações com os protocolos se tornam cada vez mais complexas, tornando necessário o uso de lógica programável para melhorar a UX para os utilizadores finais.

Conclusão

A atualização de Praga/Electra (Pectra) está agendada para março de 2025. Suas mudanças planeadas mais significativas incluem:

• participação efetiva dos validadores variáveis, até 2048 ETH, o que alterará significativamente a distribuição de participações, os cronogramas dos validadores e simplificará o gerenciamento para grandes fornecedores de staking consolidando stakes menores
• melhorou a interação camada de execução para consenso, simplificando a troca de dados entre os blocos de execução Eth1 e os blocos da cadeia Beacon. Isso simplificará muito os depósitos, ativações, retiradas e saídas, agilizando esses processos e lançando as bases para mais interações entre as camadas de consenso e execução
• suporte para verificações de assinatura BLS mais baratas e zkSNARK diretamente em contratos inteligentes através da nova pré-compilação "amigável a emparelhamento" BLS12-381
• continuando a incentivar os rollups a adotar transações de blob em vez de calldata, aumentando os limites de transações de blob e aumentando os custos de calldata
• capacitar EOAs para agir como contas programáveis, dotando-as de funcionalidades como multicamadas, patrocínios e outras funcionalidades avançadas

Como você pode ver, o Pectra terá um impacto significativo tanto nas camadas de staking e consenso, quanto na experiência do usuário na camada de execução. Embora não possamos analisar todas essas mudanças em detalhes através do código nessa fase, já que o desenvolvimento está em andamento, abordaremos essas atualizações em artigos futuros.

Aviso Legal:

1. Este artigo é reproduzido a partir de [ TechFlow [en]]. Encaminhe o Título Original: A Hardfork de Praga/Electra (Pectra) Explicada. Os direitos de autor pertencem ao autor original [MixBytes]. Se tiver alguma objeção à reimpressão, entre em contato Equipe de Aprendizagem da Gate, e a equipe irá lidar com isso o mais rápido possível de acordo com os procedimentos relevantes.
2. Aviso legal: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.
3. As outras versões do artigo são traduzidas pela equipe Learn da gate. A menos que indicado o contrário, o artigo traduzido não pode ser copiado, distribuído ou plagiado.