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

apresentar

Em nosso artigo anterior, revisamos extensivamente o ciclo de vida dos validadores Ethereum, discutindo vários aspectos relacionados à próxima atualização Electra. Agora, é hora de focar nas mudanças que estão por vir nas atualizações Electra e Prague e explicá-las em detalhes.

A história das atualizações de 'proof-of-stake' do Ethereum 2.0 é complexa. Começou com a adição da camada beacon à camada de execução existente, lançando o consenso de 'proof-of-stake' na camada beacon, mantendo ainda o 'proof-of-work' na camada de execução (as atualizações Phase0 e Altair). O PoS foi então totalmente ativado na atualização Bellatrix (embora os saques não tenham sido habilitados). Posteriormente, a atualização Capella permitiu saques, completando o ciclo de vida do validador. A atualização mais recente, Deneb (parte da atualização Dencun (Deneb/Cancun)), trouxe revisões menores aos parâmetros da cadeia beacon, como a janela de tempo para inclusão de atestações, tratamento de saídas voluntárias e o limite de renovação do validador. As principais mudanças em Dencun foram na camada de execução, introduzindo inovações como transações blob, gás blob, compromissos KZG para blobs e descontinuando a operação SELFDESTRUCT.

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

Visão Geral de Alto Nível da Pectra

Electra introduz 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 fixo em 32 ETH).
• Permitindo que os validadores iniciem saídas com credenciais secundárias de "saque" (não exigindo mais a chave ativa do validador).
• Alterando como os depósitos Eth1 são processados pela camada beacon (afastando-se do parsing de eventos do contrato de depósito).
• Adicionando um novo framework de uso geral para lidar com solicitações de contratos Eth1 regulares na camada beacon (similar à forma como os depósitos eram gerenciados antes do Electra).

Enquanto isso, Praga introduz mudanças na camada de execução, como:

• Um novo contrato pré-compilado que suporta a curva BLS12-381 para verificar provas zkSNARK (além da popular curva BN254).
• Um novo contrato de sistema para armazenar e acessar até 8192 hashes de blocos históricos (útil para clientes sem estado).
• Custos de gás de calldata aumentados para reduzir o tamanho do bloco e incentivar projetos a mover operações intensivas de calldata (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 esses números.
• Permitir 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 chamadas múltiplas ou delegar a execução para outros endereços.

Vamos fazer referência às Propostas de Melhoria do Ethereum (EIPs) relevantes para facilitar uma discussão mais aprofundada:

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

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

EIP-7251: Aumentar o MAX_EFFECTIVE_BALANCE

Referência: EIP-7251

Desde o primeiro hardfork da Fase0, implementado para preparar o Ethereum para a Proof-of-Stake, e até Electra, o saldo efetivo máximo de um validador foi 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 esse saldo efetivo máximo, mas pode reduzir seu saldo efetivo para o spec.ejection_balance (16 ETH) e é expulso ao atingir esse limite. Essa lógica "mínima" permanece inalterada em Electra, mas agora o spec.max_effective_balance aumentou para 2048 ETH. Como resultado, um validador pode depositar qualquer valor entre 32 e 2048 ETH para ativação, com todos os montantes nessa faixa contribuindo para seu saldo efetivo. Essa mudança marca uma transição de "prova-de-32ETH-stake" para uma "prova de participação" :)

Este saldo efetivo da variável será agora utilizado:

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

As duas primeiras atividades são as ações mais gratificantes para os validadores. Consequentemente, após Electra, os validadores com participações maiores participarão 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 por cortes 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 grande participação também são maiores, à medida que a fração "cortada" da aposta 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 mudanças nas cotas de redução, definindo uma fração do saldo dos validadores que está sendo reduzida e recebida pelo delator.

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

Os limites de "rotação de validadores" 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 rotação de saída é definido como "não mais do que 1/65536 (espec.churn_limit_quotient) da participação total pode sair em um 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 obrigados a executar milhares de chaves de validador em uma única instância para acomodar grandes participações, dividindo-as em partes de 32 ETH. Com o Electra, esse comportamento não é mais obrigatório. Financeiramente, essa mudança faz pouca diferença, uma vez que as recompensas e probabilidades aumentam linearmente com o valor 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 retirada Eth1, permitindo que todas as recompensas sejam retiradas para um único endereço ETH e evitando os custos de gás associados à consolidação de recompensas. No entanto, gerenciar um grande número de chaves incorre em custos administrativos extras.

A capacidade de consolidar saldos de validadores adiciona outro tipo de solicitação de camada de execução. Anteriormente, tínhamos depósitos e saques. Agora, haverá outro tipo: uma solicitação de consolidação. Ele irá mesclar dois validadores em um. Esta solicitação de operação incluirá a pubkey do validador de origem e a pubkey de destino, e será processada de forma semelhante a depósitos e saques. As consolidações também terão solicitações pendentes e limites de churn de saldo, assim como depósitos e saques.

Para resumir:

• Para pequenos validadores solos, Electra introduz a capacidade de aumentar automaticamente seu saldo efetivo (e recompensas). Anteriormente, qualquer excedente acima de 32 ETH só poderia ser retirado, mas após o Electra, esse excedente eventualmente contribuirá para 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 "1 ETH bound".
• Para grandes validadores individuais, Electra oferece simplificação significativa na gestão ao permitir a consolidação de múltiplas chaves de validador ativas em uma única. Embora não seja um grande diferencial, operar uma única aposta de 1x2048 é inegavelmente mais simples do que gerenciar 64 apostas de 32.
• Para os provedores de staking líquido, que reúnem pequenas participações dos usuários e as distribuem entre os validadores, a Electra adiciona mais flexibilidade nos esquemas de distribuição de participações, mas, ao mesmo tempo, exige uma séria refatoração da contabilidade do validador, que atualmente é baseada em um saldo efetivo fixo de 32 ETH.

Outro tópico importante é a coleta de dados históricos e a estimativa de lucro para validadores, o que é especialmente relevante para novos participantes tentando avaliar riscos e retornos. O limite de 32 ETH (tanto mínimo quanto máximo, na prática) antes do Electra (na data da escrita deste artigo) criou uniformidade nos dados históricos. Todos os validadores tinham saldos efetivos iguais, recompensas, penalidades individuais de redução, 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 outliers estatísticos, coletando dados valiosos sobre o comportamento da rede.

Após Electra, a distribuição das participações mudará significativamente. Os 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 redução e terão maior influência nas reduções adiadas, 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 as reduções dos validadores ainda podem ser estimadas com base em “por 1 ETH” (ou, mais precisamente, por spec.effective_balance_increment, que poderia 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 tem dois pares de chaves: uma chave ativa e uma chave de saque. A chave pública ativa BLS serve como a identidade principal do validador na cadeia do beacon, e este par de chaves é usado para assinar blocos, atestações, punições, 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 saque") pode ser outro par de chaves BLS ou uma conta Eth1 regular (chave privada e endereço). Agora, sacar para um endereço ETH requer uma mensagem de saque assinada pela chave privada ativa BLS. Este EIP muda isso.

Na prática, os proprietários desses dois pares de chaves (ativo 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 geralmente são controladas pelo proprietário da participação, 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 entregá-las aos proprietários da estaca, 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 da camada de 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 saque usando uma chamada de contrato inteligente regular. Isso envolve uma verificação padrão de assinatura Eth1, simplificando muito as operações.

Este EIP permite que os proprietários de participações acionem saques e saídas via uma transação padrão de seu endereço ETH para um contrato inteligente dedicado (similar ao processo de depósito existente que usa o contrato "Depósito"). O processo de saque (ou saída se uma participação suficiente for removida) funciona da seguinte maneira:

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

Enquanto os depósitos eram 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 operarão usando o mesmo framework genérico (descrito 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 “liquidados” em blocos Eth1.

Com este EIP, os proprietários de participação podem retirar e sair de seus validadores usando transações regulares de ETH sem precisar interagir diretamente com o CLI do validador ou acessar a infraestrutura dos validadores. Isso simplifica muito as operações de participação, especialmente para grandes provedores de participação. A infraestrutura dos validadores agora pode ser quase totalmente isolada, pois apenas chaves de validadores ativos precisam ser mantidas, enquanto todas as operações de participação podem ser tratadas em outro lugar. Isso elimina a necessidade dos participantes individuais esperarem por ações de validadores ativos e simplifica significativamente as partes off-chain 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 completamente para a camada Eth1, reduzindo significativamente os riscos de segurança da infraestrutura e aprimorando a descentralização das iniciativas de staking solo.

EIP-6110: Depositar validador de suprimento na cadeia

Referência: EIP-6110

Atualmente, os depósitos são implementados por meio de eventos no contrato do sistema “Depósito” (conforme discutido em detalhes em um artigo anterior). O contrato aceita ETH e credenciais de validador, emite um evento “Depósito()”, e esses eventos são posteriormente analisados e transformados em solicitações de depósito na camada de beacon. Este sistema tem inúmeras desvantagens: exige a votação para 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. Essas questões são discutidas em detalhes no EIP. Um método mais simples, eliminando muitos desses problemas, envolve incluir diretamente solicitações de depósito em blocos Eth1 em um local designado. Este mecanismo reflete o processo de tratamento de saques descrito no EIP anterior.

As mudanças propostas neste EIP são promissoras. O processamento de 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 em torno de 12 horas). Também remove a lógica para snapshots de contratos de depósito. Este EIP simplifica o processamento de depósitos e alinha-o com o esquema de processamento de retirada descrito acima.

Para os proprietários de participações e validadores, essas mudanças reduzem significativamente o atraso entre um depósito e a ativação do validador. Os reforços, que são necessários quando um validador é penalizado, também serão mais rápidos.

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

EIP-7685: Solicitações 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 a depósitos/saques/consolidação, pois ele estabelece as bases para eles. No entanto, ele é introduzido aqui para enfatizar a crescente necessidade de mecanismos genéricos para mover consistentemente dados especializados entre os blocos (camadas) da Eth1 (execução) e Beacon (consenso) chain. Este EIP afeta ambas as camadas, tornando o processamento de solicitações acionadas 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.
• Os pedidos de retirada nos blocos do Beacon (usando CLI) estão sendo "movidos" para os blocos Eth1 para processamento.
• A necessidade de lidar com consolidações de validadores, que também são as solicitações Eth1->Beacon.

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

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

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

Esta EIP carrega significado arquitetônico, permitindo que Eth1 acione ações críticas na camada Beacon por meio de um framework unificado. Para usuários finais e projetos, isso significa que todas as solicitações acionadas na camada Eth1 serão entregues e processadas 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 você não quiser se aprofundar muito, pode pensar no precompilado BLS12-381 como uma operação criptográfica complexa 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 porque permitem a agregação de várias assinaturas em uma. 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 emparelhamentos são usados 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 blob.

Se você deseja verificar uma assinatura BLS ou uma prova zkSNARK dentro de um contrato inteligente, você deve calcular esses "emparelhamentos" que são computacionalmente caros. Ethereum já possui um contrato precompilado para operações de 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) não foi implementada como um pré-compilado. Sem tal pré-compilado, implementar emparelhamentos e outras operações de curva em contratos inteligentes requer cálculos pesados, como mostrado aqui, e consome enormes quantidades de gás (~10^5 a 10^6 de gás).

Esta EIP abre as portas para muitas aplicações potenciais, especialmente ao permitir a verificação barata de assinaturas BLS baseadas na curva BLS12-381. Isso torna possível implementar esquemas de limiar para diversos fins. Como mencionado anteriormente, os validadores do Ethereum já utilizam assinaturas baseadas em BLS12-381. Com esta EIP, contratos inteligentes padrão agora podem realizar a verificação eficiente de assinaturas de validadores agregados. Isso pode simplificar as provas de consenso e a ponte de ativos entre redes, já que assinaturas BLS são amplamente utilizadas em blockchains. As assinaturas BLS de limiar 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 de prova zkSNARK mais barata, por sua vez, desbloqueará inúmeras aplicações. Muitas soluções baseadas em zkSNARK são atualmente prejudicadas pelos altos custos de verificação de provas, tornando certos projetos quase impraticáveis. Esta PEI tem o potencial de mudar isso.

EIP-2935: Salvar hashes de 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 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 a 256 blocos, enquanto introduz um novo contrato de sistema projetado especificamente para armazenar e recuperar hashes históricos. Este contrato executa uma operação set() quando a camada de execução processa um bloco. Seu método get(), acessível a qualquer pessoa, 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, existem casos em que o acesso a dados de blocos mais antigos é essencial, como em aplicações cross-chain (que requerem a comprovação de dados de blocos anteriores) e em clientes sem estado, que periodicamente precisam acessar hashes de blocos anteriores.

Esse EIP estende o horizonte de tempo disponível para rollups e aplicativos de cadeia cruzada, permitindo que eles acessem dados históricos diretamente no EVM sem a necessidade de recolhê-los externamente. Como resultado, essas soluções se tornam 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 dados de chamada é atribuído principalmente aos rollups, que enviam cargas via dados de chamada contendo o estado atual do rollup.

A capacidade de introduzir dados binários grandes e comprováveis na blockchain é essencial para rollups. O upgrade Dencun (Deneb-Cancun) introduziu uma grande inovação para tais casos de uso - transações de blob (EIP-4844). Transações de blob têm suas próprias taxas de gás dedicadas de "blob" e, embora seus corpos sejam armazenados temporariamente, suas provas criptográficas (compromissos KZG), juntamente com seus hashes, são integrados à camada de consenso. Portanto, blobs proporcionam uma solução superior para rollups em comparação com o uso de calldata para armazenamento de dados.

Incentivar os rollups a fazer a transição de seus dados para blobs pode ser alcançado usando uma abordagem de "cenoura e pau". Taxas reduzidas de gás blob servem como a "cenoura", enquanto este EIP funciona como o "pau", aumentando os custos de calldata, desencorajando assim o armazenamento excessivo de dados nas transações. Esse EIP complementa o próximo EIP-7691 (aumento da taxa de transferência de Blobs), que aumenta o número máximo de blobs permitidos por bloco.

EIP-7691: Aumento da taxa de transferência de blobs

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 bolhas "por bloco" foram 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. Esses limites agora estão sendo aumentados para 6/9, respectivamente.

Quando combinado com o EIP-7623 anterior (Aumentar o custo de dados de chamada), esse ajuste motiva ainda mais os pacotes cumulativos a fazer a transição de seus dados de dados de chamada para blobs. A busca por parâmetros de blob ideais continua.

EIP-7840: Adicionar agendamento de blob a arquivos de configuração EL

Referência: EIP-7840

Esta EIP propõe adicionar o número-alvo e máximo de blobs "por bloco" (discutidos anteriormente) e os valores baseFeeUpdateFraction nos arquivos de configuração da Camada de Execução do Ethereum (EL). Também permite que os clientes obtenham esses valores por meio da API do nó. Essa funcionalidade é particularmente útil para tarefas como estimar taxas de gás de blob.

EIP-7702: Definir código da conta EOA

Referência: EIP-7702

Este é um EIP altamente significativo que trará grandes mudanças para os usuários do Ethereum. Como sabemos, uma EOA (Conta de Propriedade Externa) não pode ter nenhum código, mas pode fornecer uma assinatura de transação (tx.origin). Em contraste, um contrato inteligente tem bytecode, mas não pode apresentar sua própria assinatura direta. Qualquer interação de um usuário que exija lógica adicional, automática e verificável atualmente só pode ser alcançada chamando um contrato externo para realizar as ações necessárias. No entanto, nesses casos, o contrato externo se torna o msg.sender para contratos subsequentes, tornando a chamada 'uma chamada de um contrato, não do usuário.'

Esta EIP introduz um novo tipo de transação SET_CODE_TX_TYPE=0x04 (anteriormente tínhamos as transações antigas 0x1, transações mais recentes 0x02 das atualizações de Berlim e EIP-1559, e 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 tuplas de dados de autorização especial ao armazenamento de "código" do endereço EOA (antes desta EIP, este armazenamento de "código" sempre estava vazio para EOAs).

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

authorization_list = [[chain_id, endereço, nonce, y_parity, 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 os contratos inteligentes regulares não podem conter (conforme EIP-3541). Este valor mágico garante que este EOA não pode 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 dos principais impactos é permitir a capacidade de fazer chamadas múltiplas diretamente de um EOA. As chamadas múltiplas são uma tendência contínua no DeFi, com muitos protocolos oferecendo esse recurso como uma ferramenta poderosa (exemplos incluem Uniswap V4, Balancer V3 ou Euler V2). Com este EIP, as chamadas múltiplas agora podem ser feitas diretamente a partir de EOAs.

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 de "pré-aprovação" genérica, 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. Os 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, essa mudança também levanta muitas questões de design. Uma questão é o uso de chain_id, que determina se a mesma assinatura pode ou não ser válida em várias redes com base em sua inclusão ou exclusão na assinatura. Outra questão complexa é se usar o endereço do código de destino 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 "multiuso" ou "uso único". Esses elementos influenciam recursos e preocupações de segurança, incluindo aspectos como invalidação em massa de assinaturas e facilidade de uso. Vitalik levantou essas questões em uma discussão (aqui), que vale a pena explorar mais.

É crucial notar que essa mudança impactará 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 é uma 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). Essas verificações têm sido utilizadas para prevenir ataques de reentrância e flashloan, mas estão longe de serem ideais, já que também dificultam integrações com protocolos externos. Após este EIP, até mesmo a confiável verificação require(tx.origin == msg.sender) parece se tornar obsoleta. Os protocolos devem se adaptar removendo tais verificações, já que a distinção entre “EOA” e “contrato” não se aplicará mais — agora cada endereço potencialmente pode ter código associado.

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

Conclusão

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

• participação efetiva de validadores variáveis, até 2048 ETH, o que alterará significativamente a distribuição de participação, cronogramas de validadores e simplificará a gestão para provedores de apostas grandes, consolidando apostas menores
• interação aprimorada entre a camada de execução e 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, saques e saídas, acelerando esses processos e estabelecendo as bases para interações adicionais entre as camadas de consenso e execução
• suporte para verificação mais barata de assinatura BLS e zkSNARK diretamente em contratos inteligentes através do novo pré-cálculo “pairing-friendly” BLS12-381
• continuando a incentivar 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
• permitindo que EOAs atuem como contas programáveis, capacitando-as com recursos como multicalls, patrocínios e outras funcionalidades avançadas

Como você pode ver, 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 etapa, já que o desenvolvimento está em andamento, vamos abordar essas atualizações em futuros artigos.

Isenção de responsabilidade:

1. Este artigo é reproduzido de [TechFlow]. Encaminhe o título original: O hardfork Praga/Electra (Pectra) explicado. Os direitos autorais pertencem ao autor original [MixBytes]. Se você tiver alguma objeção à reimpressão, entre em contato Equipe Gate Learn, e a equipe irá cuidar disso 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. Outras versões do artigo são traduzidas pela equipe da Gate Learn. A menos que seja declarado o contrário, o artigo traduzido não pode ser copiado, distribuído ou plagiado.