No nosso artigo anterior, revisamos em detalhes o ciclo de vida dos validadores do Ethereum e discutimos vários aspectos relacionados ao próximo hard fork Electra. Agora é hora de focar nas mudanças que estão por vir no upgrade Electra e Prague e explicá-las em detalhes.
A história do hard fork do Ethereum 2.0 'Proof of Stake' é complexa. Começou com a adição de uma camada de beacon à camada de execução existente, enquanto a camada de execução ainda mantinha o Proof of Work (fases 0 e Altair do hard fork). Em seguida, no hard fork de Bellatrix, o PoS foi totalmente ativado (embora o saque não tenha sido habilitado). Em seguida, o hard fork de Capella permitiu o saque, completando o ciclo de vida dos validadores. O recente hard fork Deneb (parte da atualização Dencun (Deneb/Cancun)) fez pequenas revisões nos parâmetros da cadeia de beacons, como a janela de tempo das provas, tratamento de saída voluntária e restrições de substituição de validadores. As principais mudanças em Dencun ocorreram na camada de execução, com a introdução de transações de blob, gás de blob, promessas KZG para blob e a remoção da operação SELFDESTRUCT.
Agora, o hard fork Prague/Electra (ou seja, Pectra) introduziu atualizações importantes na camada de execução e consenso. Como auditores do projeto Lido, estamos principalmente focados nas mudanças de consenso e staking neste hard fork. No entanto, não podemos ignorar as mudanças na camada de execução em Prague, uma vez que elas incluem características importantes que afetam a rede Ethereum e os validadores. Vamos aprofundar-nos nos detalhes dessas mudanças.
Visão geral de nível superior da Pectra
Electra introduziu várias funcionalidades para a camada de beacon. As principais atualizações incluem:
O saldo efetivo dos validadores pode variar de 32 a 2048 ETH (em vez de ser fixo em 32 ETH).
Permita que os validadores iniciem a saída com um comprovante de retirada de nível 2 (não é mais necessário a chave do validador ativo).
Alterar a forma como a camada de sinalização lida com os depósitos Eth1 (não mais analisando os eventos do contrato de depósito).
Adicionar um novo framework genérico para lidar com solicitações de contratos Eth1 regulares na camada de sinalização (semelhante ao método de gerenciamento de depósito prévio do Electra).
Ao mesmo tempo, Praga introduziu as seguintes mudanças na equipe de execução:
Um novo contrato pré-compilado que suporta a curva BLS12-381 para verificar provas zkSNARK (exceto a curva BN254 popular).
Um novo contrato de sistema para armazenar e acessar até 8192 hashes de blocos de histórico (útil para clientes sem estado).
Aumentar o custo do gás calldata para reduzir o tamanho do bloco e incentivar os projetos a migrar operações intensivas de calldata (como rollup) para os blobs introduzidos no Dencun.
Suporta mais blobs para cada bloco Eth1 e fornece uma API para ler esses números.
Permite que EOA (endereços de propriedade externa) possuam seu próprio código de conta, o que aumenta significativamente as operações que EOA pode executar, como realizar multicalls ou delegar a execução a outros endereços.
Vamos consultar a proposta de melhoria do Ethereum relacionada (EIP) para discussão adicional:
EIP-7251: Adicionar MAX_EFFECTIVE_BALANCE
EIP-7002: Exiting Triggered by Execution Layer
EIP-6110: Fornecer depósito de validador on-chain
EIP-7549: Remover o índice do comitê do proof
EIP-7685: Pedido de Camada de Execução Genérica
EIP-2537: Pré-compilação de operações de curva BLS12-381
EIP-2935: Manter o hash do bloco histórico no estado
EIP-7623: Aumentar o custo do calldata
EIP-7691: aumento da taxa de transferência do blob
EIP-7840: Adicionar agendamento de blob aos ficheiros de configuração do EL
EIP-7702: Código de configuração da conta EOA
Alguns desses EIPs dizem respeito principalmente à camada de consenso (beacon), enquanto outros estão relacionados à camada de execução. Alguns atravessam as duas camadas, pois certas operações (como depósitos e saques) exigem mudanças sincronizadas entre as camadas de consenso e execução. Devido a essa interdependência, separar Electra e Prague é impraticável, portanto, iremos revisar cada EIP sequencialmente e especificar os componentes do Ethereum afetados em cada caso.
EIP-7251: Adicionar MAX_EFFECTIVE_BALANCE
Referência: EIP-7251
Desde o primeiro hard fork da Fase 0, em preparação para o Proof of Stake do Ethereum, até o Electra, o saldo máximo efetivo dos validadores foi fixado em 32 ETH. A ativação do validador requer pelo menos o spec.min_activation_balance (32 ETH). Após a ativação, os validadores começam com esse saldo máximo efetivo, mas podem reduzi-lo para spec.ejection_balance (16 ETH) e serem expulsos ao atingir esse limite. Esta lógica "mínima" permanece inalterada no Electra, mas agora o spec.max_effective_balance aumentou para 2048 ETH. Portanto, os validadores podem depositar entre 32 e 2048 ETH para ativação, e todos esses montantes contribuirão para o seu saldo efetivo. Esta transição marca a mudança de "32ETH - Proof of Stake" para "Proof of Stake" :)
Este saldo disponível variável será agora utilizado para:
Aumentar a probabilidade de se tornar um proponente de bloco, proporcional ao saldo efetivo
Aumentar a probabilidade de se tornar membro do comitê de sincronização, proporcional ao saldo válido
Como base para calcular os montantes de penalização relativos à redução e inatividade
As duas primeiras atividades são as mais recompensadoras para os validadores. Portanto, após a Electra, os validadores com grandes depósitos participarão com mais frequência das propostas de blocos e do comitê de sincronização, em uma frequência proporcional ao seu saldo efetivo.
Outro impacto está relacionado com a redução. Todas as multas reduzidas são proporcionais ao saldo efetivo dos validadores:
A redução das penalidades para "imediatas" e "atrasadas" é maior para validadores com altos valores de aposta.
A 'atraso' na redução da multa com validadores com alta taxa de apostas reduzidas é maior porque a parte 'reduzida' na aposta total se torna maior.
Os denunciantes que relatam validadores com saldos válidos mais altos recebem uma proporção maior de apostas reduzidas.
Electra também propôs alterações na taxa de corte, definindo uma parte do saldo do validador cortado e recebida pelo denunciante.
A seguir está o impacto da invalidez. Quando um validador está inativo (não prova ou propõe) enquanto está ativo, a pontuação de invalidez se acumula, resultando em penalidades de invalidez aplicadas a cada ciclo. Essas penalidades também estão relacionadas proporcionalmente ao saldo válido do validador.
Devido ao aumento do saldo efetivo, a 'restrição de substituição' do validador também mudou. No Ethereum anterior ao 'Electra', os validadores geralmente tinham saldos efetivos iguais, e a definição de restrição de substituição era 'no máximo 1/65536 (spec.churn_limit_quotient) do total de garantias pode ser retirado em um período'. 'Isso criou uma quantidade fixa de validadores com a mesma garantia saindo. No entanto, após 'Electra', pode haver apenas alguns 'baleias' saindo, pois representam uma parte significativa do total de garantias.
Outra consideração é a rotação de muitas chaves de validadores em uma única instância de validador. Os validadores de grande porte atualmente são forçados a executar milhares de chaves de validação em uma única instância para acomodar grandes quantias empenhadas, dividindo-as em partes de 32 ETH. Com o Electra, esse comportamento não é mais obrigatório. Do ponto de vista financeiro, essa mudança tem pouco impacto, pois as recompensas e a probabilidade são escalonadas linearmente em relação ao valor empenhado. Portanto, 100 validadores de 32 ETH cada equivalem a um validador de 3200 ETH. Além disso, várias chaves de validadores ativas podem ter o mesmo comprovante de saque Eth1, permitindo que todas as recompensas sejam retiradas para um único endereço ETH, evitando os custos de gás associados à fusão de recompensas. No entanto, gerenciar um grande número de chaves resultará em custos adicionais de gerenciamento.
A capacidade de saldo dos validadores agregados foi aumentada com um novo tipo de solicitação de camada de execução. Anteriormente, tínhamos depósitos e levantamentos. Agora, haverá outro tipo: solicitação de agregação. Isso combinará dois validadores em um. A solicitação de operação incluirá as chaves públicas do validador de origem e do validador de destino, e será processada de forma semelhante aos depósitos e levantamentos. A agregação também terá solicitações pendentes e restrições de troca de saldo, assim como os depósitos e levantamentos.
Resumo como se segue:
*Para validadores independentes de pequena escala, o Electra introduziu a capacidade de aumentar automaticamente seu saldo efetivo (e recompensa). Anteriormente, qualquer saldo excedente a 32 ETH só podia ser retirado, mas após o Electra, esse saldo em excesso será finalmente contribuído para seu saldo efetivo. No entanto, o saldo efetivo só pode ser aumentado em múltiplos de spec.effective_balance_increment (1 ETH), o que significa que o aumento ocorre somente após atingir o próximo limite de '1 ETH'.
Para validadores independentes de grande porte, a Electra oferece uma significativa simplificação de gerenciamento ao permitir a integração de várias chaves de validadores ativos em uma única. Embora isso não mude as regras do jogo, gerenciar um depósito de 1x2048 é sem dúvida muito mais simples do que gerenciar 64x32 depósitos.
Para os provedores de liquidez de apostas, eles coletam pequenas apostas dos usuários e as distribuem entre os validadores. A Electra adiciona mais flexibilidade ao esquema de distribuição de apostas, mas requer uma reconstrução séria da contabilidade dos validadores baseada em um saldo efetivo fixo de 32 ETH.
Outro tópico importante é o histórico de dados e estimativas de lucro dos validadores, especialmente relevantes para novos participantes que estão tentando avaliar riscos e retornos. Antes do Electra (no momento em que este artigo foi escrito), o limite de 32 ETH (mínimo ou máximo, na verdade) criou uniformidade nos dados históricos. O saldo efetivo, as recompensas, as penalidades individuais de redução, a frequência de propostas de blocos e outros indicadores são os mesmos para todos os validadores. Essa uniformidade permite que o Ethereum teste seu mecanismo de consenso sem estatísticas de valores atípicos, coletando assim dados de comportamento de rede valiosos.
Depois do Electra, haverá mudanças significativas na distribuição do staking. Grandes validadores participarão com mais frequência de comitês de proposta e sincronização de blocos, enfrentarão maiores penalidades em eventos de corte e terão maior impacto em cortes atrasados, 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 a computação não linear seja mínima. O único componente não linear usa sqrt(total_effective_balance) para calcular a recompensa base, que se aplica a todos os validadores. Isso significa que as recompensas e barras do validador ainda podem ser estimadas "por 1 ETH" (ou, mais precisamente, com base em spec.effective_balance_increment, o que pode mudar no futuro).
Para obter mais informações detalhadas, consulte o nosso artigo anterior sobre o comportamento do validador.
EIP-7002: Camada de Execução Ativável
Referência: EIP-7002
Cada validador no Ethereum possui dois pares de chaves: uma chave ativa e uma chave de saque. A chave pública BLS ativa serve como a identidade principal do validador na cadeia de balizas e é usada para assinar blocos, provas, cortes, agregação do comitê de sincronização e (antes deste EIP) saídas voluntárias do consenso de validadores atrasados. O segundo par de chaves ("comprovante de saque") pode ser outro par de chaves BLS ou uma conta Eth1 regular (chave privada e endereço). Agora, a extração para um endereço ETH requer uma mensagem de saque assinada pela chave privada BLS ativa. Este EIP faz essa alteração.
Na realidade, os proprietários dos dois pares de chaves (ativos e de saque) podem ser diferentes. A chave ativa do validador é responsável pelas responsabilidades de validação: operar o servidor, mantê-lo funcionando normalmente, etc., enquanto o comprovante de saque é normalmente controlado pelo proprietário do depósito, que recebe recompensas e é responsável pelos fundos. Atualmente, apenas o proprietário do comprovante de saque não pode iniciar a saída do validador, apenas retirar as recompensas. Esta situação permite que o proprietário da chave ativa do validador efetivamente mantenha o saldo do validador como um "refém". O validador pode "pré-assinar" a mensagem de saída e entregá-la ao proprietário do depósito, mas este método alternativo não é ideal. Além disso, atualmente, tanto a retirada quanto a saída requerem interação com o validador da camada de sinalização através de uma API especial.
A melhor solução é permitir que os depositantes executem operações de depósito e retirada simultaneamente por meio de contratos inteligentes regulares. Isso envolve verificações de assinatura Eth1 padrão, simplificando significativamente as operações.
Este EIP permite que os detentores de estacas ativem retiradas e saídas, semelhantes ao processo de depósito usando contratos de "depósito", enviando transações padrão do seu endereço ETH para contratos inteligentes dedicados.
Os stakers enviam pedidos de levantamento ('in' requests) para o contrato 'withdraw' do sistema.
A taxa específica é cobrada pelo contrato (calculada em ETH) para mitigar possíveis ataques maliciosos e é semelhante ao EIP-1559, com aumento da taxa quando a fila de solicitações está ocupada.
O contrato irá armazenar o pedido de saque/saída "in" em seu armazenamento.
Quando um bloco é proposto para a camada de beacon, as solicitações de saque / retirada pendentes na fila 'in' serão recuperadas do armazenamento.
A camada de beacon lida com pedidos 'in', interage com os saldos dos validadores ativos, organiza a saída dos validadores e forma pedidos de levantamento 'out'.
O pedido de saque "out" é processado na camada de execução, e o depositante recebe seu ETH.
Embora os depósitos sejam acionados em um bloco Eth1 e depois 'movidos' para a camada de sinalização por meio da fila de depósitos 'pendentes', as retiradas seguem um esquema diferente. Elas são acionadas na camada de sinalização (por meio da CLI) e depois 'movidas' para um bloco Eth1. Agora, ambos os esquemas serão operados por meio de uma estrutura geral (descrita abaixo): criar solicitação na camada Eth1, processar fila de depósitos/retiradas/fusões 'pendentes' e processar na camada de sinalização. Para operações de 'saída', como retiradas, a fila de saída também será processada e os resultados serão 'liquidados' em um bloco Eth1.
Com este EIP, os validadores podem retirar e sair dos seus validadores usando transações ETH convencionais, sem a necessidade de interagir diretamente com o CLI do validador ou acessar a infraestrutura do validador. Isso simplifica significativamente as operações de validação, especialmente para grandes provedores de validação. A infraestrutura do validador agora pode ser isolada quase completamente, uma vez que apenas as chaves dos validadores ativos precisam ser mantidas, e todas as operações de validação podem ser tratadas em outro lugar. Isso elimina a necessidade de validadores independentes aguardarem ações dos validadores ativos e simplifica significativamente a parte off-chain de serviços como o Módulo de Staking da Comunidade, como o serviço Lido.
Portanto, este EIP 'completa' a operação de staking, transferindo-a completamente para a camada Eth1, reduzindo significativamente o risco de segurança da infraestrutura e fortalecendo a descentralização da iniciativa de staking independente.
EIP-6110: Fornecimento de depósitos de validadores on-chain
Referência: EIP-6110
Atualmente, os depósitos são feitos através de eventos no contrato de depósito, como discutido em detalhes em artigos anteriores. O contrato aceita ETH e provas de validação, emitindo o evento "Deposit()", que é então analisado e convertido em pedidos de depósito na camada de beacon. Este sistema tem várias desvantagens: requer votação nos dados eth1 da camada de beacon, o que aumenta significativamente a latência. Além disso, a camada de beacon precisa consultar a camada de execução, o que acrescenta complexidade. Essas questões são discutidas em detalhes no EIP. Uma abordagem mais simples que evita muitos desses problemas é incluir diretamente os pedidos de depósito em blocos Eth1 em locais designados. Esse mecanismo é semelhante ao processo de retirada descrito anteriormente no EIP.
As alterações propostas neste EIP têm um grande potencial. O processamento eth1data pode agora ser completamente removido, eliminando a necessidade de votação ou atrasos significativos entre eventos no lado Eth1 e depósitos incluídos na camada de beacon (atualmente cerca de 12 horas). Também elimina a lógica de snapshot do contrato de depósito. Este EIP simplifica o processamento de depósitos, alinhando-o com o esquema de processamento de retiradas mencionado acima.
Para os apostadores e validadores, estas mudanças reduzem significativamente o atraso entre o depósito e a ativação do validador. Quando um validador é reduzido, as suplementações necessárias também serão mais rápidas.
Não há muito mais a dizer sobre este EIP, exceto que removeu a lógica obsoleta, simplificou o processo e criou melhores resultados para todas as partes interessadas.
EIP-7685: Solicitação de camada de execução comum
Referência: EIP-7685
Este EIP deveria ter sido proposto antes dos três primeiros EIPs relacionados a depósitos/saques/fusões, pois ele estabelece as bases para esses EIPs. No entanto, é apresentado aqui para enfatizar a crescente necessidade de mover dados especializados de forma consistente entre os blocos (camadas) da Eth1 (execução) e da Beacon (consenso). Este EIP afeta as duas camadas, tornando o processamento de solicitações acionadas por transações ETH regulares mais eficiente. Atualmente, observamos:
O evento de depósito no bloco Eth1 é 'movido' para o bloco de referência para processamento.
O pedido de levantamento na âncora (usando CLI) foi 'mudado' para processamento no bloco Eth1.
solicitação de sinalizador.
Essas três operações demonstram a necessidade de um processamento consistente de vários tipos de solicitações ao fazer a transição entre a camada de execução e a camada de sinalização. Além disso, precisamos ter a capacidade de acionar essas operações apenas na camada Eth1, pois isso nos permitirá isolar a infraestrutura do validador da infraestrutura de gerenciamento de apostas, aumentando assim a segurança. Portanto, ter uma solução geral para gerenciar essas solicitações é prático e necessário.
Este EIP estabelece um quadro para pelo menos três casos principais: depósito, retirada e consolidação. É por isso que EIPs anteriores introduziram campos como WITHDRAWAL_REQUEST_TYPE e DEPOSIT_REQUEST_TYPE, e agora a consolidação adicionará outro campo, CONSOLIDATION_REQUEST_TYPE. Além disso, este EIP pode incluir um mecanismo geral para lidar com restrições desse tipo de solicitação (consulte as constantes: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Embora os detalhes da implementação deste framework ainda não estejam disponíveis, certamente incluirá tipos de solicitação chave, mecanismos de integridade (por exemplo, requisições de hash e Merkle) e processamento de fila de espera e limitação de taxa.
Este EIP tem um significado arquitetural, permitindo que o Eth1 acione operações-chave na camada de beacon através 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 de maneira mais eficiente na camada de beacon.
EIP-2537: Pré-compilação de operações de curva BLS12-381
Consulte: EIP-2537
Se não quiseres aprofundar, podes considerar a pré-compilação de BLS12-381 como uma operação de "hash" criptográfico complexo, agora disponível para utilização em contratos inteligentes. Para aqueles interessados, vamos explorar mais a fundo.
As operações matemáticas realizadas em curvas elípticas como BLS12-381 (e sua correspondente BN-254) são atualmente utilizadas para dois propósitos:
A assinatura BLS, na qual um tipo especial de operação chamada de "emparelhamento" é usada para verificar essas assinaturas. As assinaturas BLS são amplamente utilizadas por verificadores, pois permitem a agregação de várias assinaturas em uma única. Os verificadores dependem de assinaturas BLS baseadas na curva BLS12-381 (embora também possam ser implementadas com qualquer curva que suporte emparelhamento, como BN254).
A verificação da prova zkSNARK, em que o emparelhamento é usado para verificar a prova. Além disso, o compromisso KZG para grandes blocos introduzido pelo hard fork Dencun também usa emparelhamento para verificar o compromisso do bloco.
Se você quiser verificar uma assinatura BLS ou uma prova zkSNARK em um contrato inteligente, você deve calcular esses 'pares', o que é muito caro em termos de cálculo. O Ethereum já possui um contrato pré-compilado (EIP-196 e EIP-197) para operações na curva BN254. No entanto, a curva BLS12-381 (agora considerada mais segura e mais amplamente utilizada hoje) ainda não foi implementada como uma pré-compilação. Sem tal pré-compilação, a realização de emparelhamento e outras operações de curva em um contrato inteligente requerem uma grande quantidade de cálculo, como mostrado aqui, e consomem uma enorme quantidade de gás (cerca de ~10^5 a 10^6 gas).
Este EIP abriu muitas portas para aplicações potenciais, especialmente na verificação barata de assinaturas BLS baseadas na curva BLS12-381. Isso torna possível implementar vários esquemas de limiar para diversos fins. Como mencionado anteriormente, os validadores do Ethereum já estão usando assinaturas baseadas em BLS12-381. Através deste EIP, contratos inteligentes padrão agora podem verificar de forma eficiente as assinaturas agregadas dos validadores. Isso pode simplificar a prova de consenso e a ponte de ativos entre redes, uma vez que as assinaturas BLS são amplamente utilizadas em blockchains. As próprias assinaturas BLS de limiar permitem a construção de muitos esquemas eficientes de limiar para votação, geração descentralizada de números aleatórios, multiassinaturas, entre outros.
A verificação de prova zkSNARK mais barata abre caminho para uma ampla gama de aplicações. Atualmente, muitas soluções baseadas em zkSNARK são dificultadas pelos altos custos de verificação de prova, o que torna alguns projetos quase impraticáveis. Esta EIP tem o potencial de mudar isso.
EIP-2935: Salvar o histórico do hash do bloco no estado
Referência: EIP-2935
Esta proposta de EIP sugere armazenar 8192 (aproximadamente 27,3 horas) hashes de bloco históricos no estado da blockchain, a fim de fornecer histórico expandido para clientes sem estado (como rollup) e contratos inteligentes. Ele propõe manter o comportamento atual do opcode BLOCKHASH, mantendo o limite de 256 blocos, ao mesmo tempo que introduz um novo contrato de sistema projetado especificamente para armazenar e recuperar hashes históricos. Este contrato executa a operação set() ao processar os blocos na camada de execução. O método get() está disponível para acesso público, permitindo que qualquer pessoa recupere os hashes de bloco necessários do buffer circular.
Atualmente, é possível referenciar o hash do bloco histórico no EVM, mas o acesso é limitado aos últimos 256 blocos (cerca de 50 minutos). No entanto, em algumas situações, o acesso a dados de blocos mais antigos é crucial, especialmente para aplicativos cross-chain (que precisam provar dados de blocos anteriores) e para clientes sem estado, que precisam acessar regularmente hashes de blocos anteriores.
Este EIP expande o intervalo de tempo disponível para rollup e aplicações cross-chain, permitindo-lhes aceder diretamente aos dados históricos no EVM, sem necessidade de recolha externa. Como resultado, estas soluções tornam-se mais robustas e sustentáveis.
EIP-7623: Aumentar o custo do calldata
Referência: EIP-7623
calldata ajusta o tamanho disponível da carga útil da transação, o que pode ser significativo em algumas situações (por exemplo, ao passar matrizes grandes ou buffers binários como parâmetros). O uso significativo de calldata é principalmente atribuído aos rollups, que enviam a carga útil embalada com o estado atual do rollup.
A introdução de dados binários de grande escala e comprováveis é crucial para o rollup na blockchain. A atualização Dencun (Deneb-Cancun) introduziu uma inovação importante para esse tipo de caso de uso - transações de blob (EIP-4844). As transações de blob têm sua própria taxa de gás especializada 'blob', embora o corpo seja armazenado temporariamente, sua prova de criptografia (compromisso KZG) juntamente com seu hash são integrados à camada de consenso. Portanto, em comparação com o armazenamento de dados usando calldata, o blob fornece uma solução melhor para o rollup.
Incentivar rollup a mover seus dados para blob pode ser alcançado através do “Cenoura e porrete”. A redução das taxas de gas blob atua como “Cenoura”, enquanto este EIP aumenta o custo de calldata como “Porrete” para conter o armazenamento excessivo de dados nas transações. Este EIP complementa o próximo EIP-7691 (Aumento de throughput de blob), que aumenta o número máximo de blobs permitidos por bloco.
EIP-7691: aumento da capacidade de throughput de blobs
Consulte: EIP-7691
Na bifurcação rígida anterior de Dencun, o blob foi introduzido e o valor inicial do número máximo e do alvo de blob por "bloco" é uma estimativa conservadora. Isso se deve à complexidade de prever como a rede p2p lidará com objetos binários grandes que se espalham entre os nós de validação. A configuração anterior provou ser boa, o que torna este o momento certo para testar novos valores. Anteriormente, o número máximo / alvo de blob por bloco era definido como 3/6. Essas restrições agora foram aumentadas para 6/9.
A combinação do EIP-7623 anterior (aumento do custo do calldata) reforçou ainda mais o incentivo para o rollup mover seus dados do calldata para blobs. O trabalho de encontrar os melhores parâmetros de blob continua em andamento.
EIP-7840: Adicionar programação de blob ao ficheiro de configuração EL
Referência: EIP-7840
Esta proposta de EIP adiciona as metas e a quantidade máxima de blocos de blobs por bloco (discutidos anteriormente) e o valor baseFeeUpdateFraction ao arquivo de configuração da camada de execução do Ethereum (EL). Também permite que os clientes recuperem esses valores por meio da API do nó. Essa funcionalidade é particularmente útil para tarefas como estimar o custo do gás do blob.
EIP-7702: Configurar o código da conta EOA
Referência: EIP-7702
Este é um EIP muito importante que trará mudanças significativas aos utilizadores do Ethereum. Como sabemos, um EOA (Endereço de Propriedade Externa) não pode ter nenhum código, mas pode fornecer uma assinatura de transação (tx.origin). Por outro lado, os contratos inteligentes têm bytecode, mas não podem gerar diretamente a sua própria assinatura. Qualquer interação do utilizador que necessite de lógica adicional, automação e verificação só pode ser realizada atualmente através da chamada a contratos externos para executar as operações necessárias. No entanto, nesse cenário, o contrato externo torna-se o msg.sender do contrato subsequente, resultando numa chamada 'de contrato para contrato' em vez de 'do utilizador'.
Esta EIP introduz um novo tipo de transação SET_CODE_TX_TYPE=0x04 (anteriormente tínhamos transações antigas 0x1, novas transações 0x02 da atualização Berlim e EIP-1559, e transações blob 0x03 introduzidas em Dencun). Este novo tipo de transação permite a definição de código para uma conta EOA. Na verdade, permite que uma conta EOA execute código externo "no contexto da sua própria conta EOA". Do ponto de vista externo, durante o processo de transação, a EOA parece "tomar emprestado" o código de um contrato externo e executá-lo. Tecnicamente, isso é alcançado adicionando uma tupla de dados de autorização especial ao armazenamento de "código" do endereço da EOA (antes desta EIP, este armazenamento de "código" para uma EOA sempre estava vazio).
Atualmente, este novo tipo de transação 0x04 proposto pelo EIP contém uma matriz:
Cada elemento permite que a conta use o código do endereço especificado (do último item de autorização válido). Ao processar transações desse tipo, o código do EOA fornecido é definido como um valor especial de 0xef0100 || endereço (23 bytes), onde o endereço aponta para o contrato que possui o código desejado, || indica a concatenação e 0xef0100 representa um valor mágico especial que não pode ser incluído em contratos inteligentes convencionais (de acordo com o EIP-3541). Esse valor mágico garante que esse EOA não possa ser tratado como um contrato convencional e não possa ser chamado como um contrato convencional.
Quando este EOA inicia uma transação, o endereço especificado será usado para invocar o código correspondente no contexto deste EOA. Embora os detalhes completos da implementação deste EIP ainda não estejam claros, é certo que trará mudanças significativas.
Um dos principais impactos é a capacidade de fazer chamadas múltiplas diretamente a partir de EOA (Endereço de Propriedade Externa). As chamadas múltiplas são uma tendência contínua no DeFi, e muitos protocolos oferecem essa funcionalidade como uma ferramenta poderosa (como Uniswap V4, Balancer V3 ou Euler V2). Com este EIP, agora é possível iniciar chamadas múltiplas diretamente a partir de EOA.
Por exemplo, este novo recurso resolve um problema comum no DeFi: a ineficiência de realizar approve() + anything() em transações separadas. Este EIP permite uma lógica de 'pré-autorização' genérica, permitindo que a aprovação de approve(X) + deposit(X) seja feita em uma única transação.
Uma outra vantagem de ser capaz de 'representar' a execução de transações delegadas por EOA é o conceito de patrocínio. O patrocínio é uma característica frequentemente discutida e altamente desejada para ajudar novos utilizadores a entrar no Ethereum.
A lógica programável associada ao EOA desbloqueou muitas possibilidades, como implementar restrições de segurança, definir limites de gastos, exigir KYC e assim por diante.
Claro, essa mudança também levanta muitos problemas de design. Uma questão é o uso do chain_id, que determina se a mesma assinatura é válida em várias redes, dependendo se está incluída ou não na assinatura. Outra questão complexa é a escolha entre o uso de endereços do código de destino e a incorporação do código de bytes real. Ambos os métodos têm características e limitações únicas. Além disso, o uso do nonce desempenha um papel crucial na definição de permissões como 'multiuso' ou 'único uso'. Esses elementos afetam questões de funcionalidade e segurança, incluindo assinaturas inválidas em massa e usabilidade, entre outros. Vitalik levantou essas questões em uma discussão (aqui) que vale a pena explorar mais a fundo.
É importante notar que esta mudança irá afetar um mecanismo 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 sempre foi a maneira 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), geralmente falham e podem ser evitados (por exemplo, chamando o construtor ou implantando código em um endereço predefinido após a transação). Estas verificações são usadas para prevenir ataques de reentrada e empréstimos relâmpago, mas estão longe de ser ideais, pois também dificultam a integração com protocolos externos. Após este EIP, parece que mesmo a verificação confiável require(tx.origin == msg.sender) está obsoleta. Os protocolos precisam se adaptar removendo essas verificações, pois a distinção entre 'EOA' e 'contrato' não será mais relevante - agora, cada endereço pode ter código associado.
A separação entre o tradicional EOA e os contratos inteligentes continua a ficar cada vez mais difusa. Este EIP faz com que o Ethereum se aproxime mais de designs como o TON, onde cada conta é essencialmente código executável. À medida que a interação com protocolos se torna cada vez mais complexa, usar lógica programável para melhorar a experiência do usuário final é um processo natural desta evolução.
Conclusão
A atualização do Praga / Electra (Pectra) está agendada para março de 2025. As mudanças mais significativas no plano incluem:
Os validadores variáveis podem fazer apostas efetivas de até 2048 ETH, o que mudará significativamente a distribuição e o cronograma dos validadores, e simplificará a gestão dos grandes fornecedores de apostas ao integrar as apostas menores.
Melhorar a interação entre a camada de execução e a camada de consenso, simplificando a troca de dados entre os blocos de execução Eth1 e os blocos de corrente de sinal. Isso simplificará muito os processos de depósito, ativação, retirada e saída, acelerando esses processos e estabelecendo uma base para uma interação mais aprofundada entre a camada de consenso e a camada de execução.
Suportar diretamente assinaturas BLS mais baratas e verificações zkSNARK através do novo pré-compilado 'amigável ao emparelhamento' BLS12-381 em contratos inteligentes
Incentivar Rollups a adotar transações de blob, aumentando o limite de transações de blob e aumentando o custo de dados de chamada.
Fazer com que o EOA atue como uma conta programável, concedendo-lhe chamadas múltiplas, patrocínio e outras funcionalidades avançadas
Como pode ver, o Pectra terá um impacto significativo na experiência do utilizador final, tanto no que diz respeito ao staking e ao consenso, como à camada de execução. Embora não possamos neste momento analisar em detalhe todas essas mudanças através de código, uma vez que o desenvolvimento ainda está em andamento, iremos abordar estas atualizações em futuros artigos.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Analise a próxima atualização do Hard Fork - Pectra na ETH Square
Introdução
No nosso artigo anterior, revisamos em detalhes o ciclo de vida dos validadores do Ethereum e discutimos vários aspectos relacionados ao próximo hard fork Electra. Agora é hora de focar nas mudanças que estão por vir no upgrade Electra e Prague e explicá-las em detalhes.
A história do hard fork do Ethereum 2.0 'Proof of Stake' é complexa. Começou com a adição de uma camada de beacon à camada de execução existente, enquanto a camada de execução ainda mantinha o Proof of Work (fases 0 e Altair do hard fork). Em seguida, no hard fork de Bellatrix, o PoS foi totalmente ativado (embora o saque não tenha sido habilitado). Em seguida, o hard fork de Capella permitiu o saque, completando o ciclo de vida dos validadores. O recente hard fork Deneb (parte da atualização Dencun (Deneb/Cancun)) fez pequenas revisões nos parâmetros da cadeia de beacons, como a janela de tempo das provas, tratamento de saída voluntária e restrições de substituição de validadores. As principais mudanças em Dencun ocorreram na camada de execução, com a introdução de transações de blob, gás de blob, promessas KZG para blob e a remoção da operação SELFDESTRUCT.
Agora, o hard fork Prague/Electra (ou seja, Pectra) introduziu atualizações importantes na camada de execução e consenso. Como auditores do projeto Lido, estamos principalmente focados nas mudanças de consenso e staking neste hard fork. No entanto, não podemos ignorar as mudanças na camada de execução em Prague, uma vez que elas incluem características importantes que afetam a rede Ethereum e os validadores. Vamos aprofundar-nos nos detalhes dessas mudanças.
Visão geral de nível superior da Pectra
Electra introduziu várias funcionalidades para a camada de beacon. As principais atualizações incluem:
Ao mesmo tempo, Praga introduziu as seguintes mudanças na equipe de execução:
Vamos consultar a proposta de melhoria do Ethereum relacionada (EIP) para discussão adicional:
Alguns desses EIPs dizem respeito principalmente à camada de consenso (beacon), enquanto outros estão relacionados à camada de execução. Alguns atravessam as duas camadas, pois certas operações (como depósitos e saques) exigem mudanças sincronizadas entre as camadas de consenso e execução. Devido a essa interdependência, separar Electra e Prague é impraticável, portanto, iremos revisar cada EIP sequencialmente e especificar os componentes do Ethereum afetados em cada caso.
EIP-7251: Adicionar MAX_EFFECTIVE_BALANCE
Referência: EIP-7251
Desde o primeiro hard fork da Fase 0, em preparação para o Proof of Stake do Ethereum, até o Electra, o saldo máximo efetivo dos validadores foi fixado em 32 ETH. A ativação do validador requer pelo menos o spec.min_activation_balance (32 ETH). Após a ativação, os validadores começam com esse saldo máximo efetivo, mas podem reduzi-lo para spec.ejection_balance (16 ETH) e serem expulsos ao atingir esse limite. Esta lógica "mínima" permanece inalterada no Electra, mas agora o spec.max_effective_balance aumentou para 2048 ETH. Portanto, os validadores podem depositar entre 32 e 2048 ETH para ativação, e todos esses montantes contribuirão para o seu saldo efetivo. Esta transição marca a mudança de "32ETH - Proof of Stake" para "Proof of Stake" :)
Este saldo disponível variável será agora utilizado para:
As duas primeiras atividades são as mais recompensadoras para os validadores. Portanto, após a Electra, os validadores com grandes depósitos participarão com mais frequência das propostas de blocos e do comitê de sincronização, em uma frequência proporcional ao seu saldo efetivo.
Outro impacto está relacionado com a redução. Todas as multas reduzidas são proporcionais ao saldo efetivo dos validadores:
Electra também propôs alterações na taxa de corte, definindo uma parte do saldo do validador cortado e recebida pelo denunciante.
A seguir está o impacto da invalidez. Quando um validador está inativo (não prova ou propõe) enquanto está ativo, a pontuação de invalidez se acumula, resultando em penalidades de invalidez aplicadas a cada ciclo. Essas penalidades também estão relacionadas proporcionalmente ao saldo válido do validador.
Devido ao aumento do saldo efetivo, a 'restrição de substituição' do validador também mudou. No Ethereum anterior ao 'Electra', os validadores geralmente tinham saldos efetivos iguais, e a definição de restrição de substituição era 'no máximo 1/65536 (spec.churn_limit_quotient) do total de garantias pode ser retirado em um período'. 'Isso criou uma quantidade fixa de validadores com a mesma garantia saindo. No entanto, após 'Electra', pode haver apenas alguns 'baleias' saindo, pois representam uma parte significativa do total de garantias.
Outra consideração é a rotação de muitas chaves de validadores em uma única instância de validador. Os validadores de grande porte atualmente são forçados a executar milhares de chaves de validação em uma única instância para acomodar grandes quantias empenhadas, dividindo-as em partes de 32 ETH. Com o Electra, esse comportamento não é mais obrigatório. Do ponto de vista financeiro, essa mudança tem pouco impacto, pois as recompensas e a probabilidade são escalonadas linearmente em relação ao valor empenhado. Portanto, 100 validadores de 32 ETH cada equivalem a um validador de 3200 ETH. Além disso, várias chaves de validadores ativas podem ter o mesmo comprovante de saque Eth1, permitindo que todas as recompensas sejam retiradas para um único endereço ETH, evitando os custos de gás associados à fusão de recompensas. No entanto, gerenciar um grande número de chaves resultará em custos adicionais de gerenciamento.
A capacidade de saldo dos validadores agregados foi aumentada com um novo tipo de solicitação de camada de execução. Anteriormente, tínhamos depósitos e levantamentos. Agora, haverá outro tipo: solicitação de agregação. Isso combinará dois validadores em um. A solicitação de operação incluirá as chaves públicas do validador de origem e do validador de destino, e será processada de forma semelhante aos depósitos e levantamentos. A agregação também terá solicitações pendentes e restrições de troca de saldo, assim como os depósitos e levantamentos.
Resumo como se segue:
*Para validadores independentes de pequena escala, o Electra introduziu a capacidade de aumentar automaticamente seu saldo efetivo (e recompensa). Anteriormente, qualquer saldo excedente a 32 ETH só podia ser retirado, mas após o Electra, esse saldo em excesso será finalmente contribuído para seu saldo efetivo. No entanto, o saldo efetivo só pode ser aumentado em múltiplos de spec.effective_balance_increment (1 ETH), o que significa que o aumento ocorre somente após atingir o próximo limite de '1 ETH'.
Outro tópico importante é o histórico de dados e estimativas de lucro dos validadores, especialmente relevantes para novos participantes que estão tentando avaliar riscos e retornos. Antes do Electra (no momento em que este artigo foi escrito), o limite de 32 ETH (mínimo ou máximo, na verdade) criou uniformidade nos dados históricos. O saldo efetivo, as recompensas, as penalidades individuais de redução, a frequência de propostas de blocos e outros indicadores são os mesmos para todos os validadores. Essa uniformidade permite que o Ethereum teste seu mecanismo de consenso sem estatísticas de valores atípicos, coletando assim dados de comportamento de rede valiosos.
Depois do Electra, haverá mudanças significativas na distribuição do staking. Grandes validadores participarão com mais frequência de comitês de proposta e sincronização de blocos, enfrentarão maiores penalidades em eventos de corte e terão maior impacto em cortes atrasados, 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 a computação não linear seja mínima. O único componente não linear usa sqrt(total_effective_balance) para calcular a recompensa base, que se aplica a todos os validadores. Isso significa que as recompensas e barras do validador ainda podem ser estimadas "por 1 ETH" (ou, mais precisamente, com base em spec.effective_balance_increment, o que pode mudar no futuro).
Para obter mais informações detalhadas, consulte o nosso artigo anterior sobre o comportamento do validador.
EIP-7002: Camada de Execução Ativável
Referência: EIP-7002
Cada validador no Ethereum possui dois pares de chaves: uma chave ativa e uma chave de saque. A chave pública BLS ativa serve como a identidade principal do validador na cadeia de balizas e é usada para assinar blocos, provas, cortes, agregação do comitê de sincronização e (antes deste EIP) saídas voluntárias do consenso de validadores atrasados. O segundo par de chaves ("comprovante de saque") pode ser outro par de chaves BLS ou uma conta Eth1 regular (chave privada e endereço). Agora, a extração para um endereço ETH requer uma mensagem de saque assinada pela chave privada BLS ativa. Este EIP faz essa alteração.
Na realidade, os proprietários dos dois pares de chaves (ativos e de saque) podem ser diferentes. A chave ativa do validador é responsável pelas responsabilidades de validação: operar o servidor, mantê-lo funcionando normalmente, etc., enquanto o comprovante de saque é normalmente controlado pelo proprietário do depósito, que recebe recompensas e é responsável pelos fundos. Atualmente, apenas o proprietário do comprovante de saque não pode iniciar a saída do validador, apenas retirar as recompensas. Esta situação permite que o proprietário da chave ativa do validador efetivamente mantenha o saldo do validador como um "refém". O validador pode "pré-assinar" a mensagem de saída e entregá-la ao proprietário do depósito, mas este método alternativo não é ideal. Além disso, atualmente, tanto a retirada quanto a saída requerem interação com o validador da camada de sinalização através de uma API especial.
A melhor solução é permitir que os depositantes executem operações de depósito e retirada simultaneamente por meio de contratos inteligentes regulares. Isso envolve verificações de assinatura Eth1 padrão, simplificando significativamente as operações.
Este EIP permite que os detentores de estacas ativem retiradas e saídas, semelhantes ao processo de depósito usando contratos de "depósito", enviando transações padrão do seu endereço ETH para contratos inteligentes dedicados.
Embora os depósitos sejam acionados em um bloco Eth1 e depois 'movidos' para a camada de sinalização por meio da fila de depósitos 'pendentes', as retiradas seguem um esquema diferente. Elas são acionadas na camada de sinalização (por meio da CLI) e depois 'movidas' para um bloco Eth1. Agora, ambos os esquemas serão operados por meio de uma estrutura geral (descrita abaixo): criar solicitação na camada Eth1, processar fila de depósitos/retiradas/fusões 'pendentes' e processar na camada de sinalização. Para operações de 'saída', como retiradas, a fila de saída também será processada e os resultados serão 'liquidados' em um bloco Eth1.
Com este EIP, os validadores podem retirar e sair dos seus validadores usando transações ETH convencionais, sem a necessidade de interagir diretamente com o CLI do validador ou acessar a infraestrutura do validador. Isso simplifica significativamente as operações de validação, especialmente para grandes provedores de validação. A infraestrutura do validador agora pode ser isolada quase completamente, uma vez que apenas as chaves dos validadores ativos precisam ser mantidas, e todas as operações de validação podem ser tratadas em outro lugar. Isso elimina a necessidade de validadores independentes aguardarem ações dos validadores ativos e simplifica significativamente a parte off-chain de serviços como o Módulo de Staking da Comunidade, como o serviço Lido.
Portanto, este EIP 'completa' a operação de staking, transferindo-a completamente para a camada Eth1, reduzindo significativamente o risco de segurança da infraestrutura e fortalecendo a descentralização da iniciativa de staking independente.
EIP-6110: Fornecimento de depósitos de validadores on-chain
Referência: EIP-6110
Atualmente, os depósitos são feitos através de eventos no contrato de depósito, como discutido em detalhes em artigos anteriores. O contrato aceita ETH e provas de validação, emitindo o evento "Deposit()", que é então analisado e convertido em pedidos de depósito na camada de beacon. Este sistema tem várias desvantagens: requer votação nos dados eth1 da camada de beacon, o que aumenta significativamente a latência. Além disso, a camada de beacon precisa consultar a camada de execução, o que acrescenta complexidade. Essas questões são discutidas em detalhes no EIP. Uma abordagem mais simples que evita muitos desses problemas é incluir diretamente os pedidos de depósito em blocos Eth1 em locais designados. Esse mecanismo é semelhante ao processo de retirada descrito anteriormente no EIP.
As alterações propostas neste EIP têm um grande potencial. O processamento eth1data pode agora ser completamente removido, eliminando a necessidade de votação ou atrasos significativos entre eventos no lado Eth1 e depósitos incluídos na camada de beacon (atualmente cerca de 12 horas). Também elimina a lógica de snapshot do contrato de depósito. Este EIP simplifica o processamento de depósitos, alinhando-o com o esquema de processamento de retiradas mencionado acima.
Para os apostadores e validadores, estas mudanças reduzem significativamente o atraso entre o depósito e a ativação do validador. Quando um validador é reduzido, as suplementações necessárias também serão mais rápidas.
Não há muito mais a dizer sobre este EIP, exceto que removeu a lógica obsoleta, simplificou o processo e criou melhores resultados para todas as partes interessadas.
EIP-7685: Solicitação de camada de execução comum
Referência: EIP-7685
Este EIP deveria ter sido proposto antes dos três primeiros EIPs relacionados a depósitos/saques/fusões, pois ele estabelece as bases para esses EIPs. No entanto, é apresentado aqui para enfatizar a crescente necessidade de mover dados especializados de forma consistente entre os blocos (camadas) da Eth1 (execução) e da Beacon (consenso). Este EIP afeta as duas camadas, tornando o processamento de solicitações acionadas por transações ETH regulares mais eficiente. Atualmente, observamos:
Essas três operações demonstram a necessidade de um processamento consistente de vários tipos de solicitações ao fazer a transição entre a camada de execução e a camada de sinalização. Além disso, precisamos ter a capacidade de acionar essas operações apenas na camada Eth1, pois isso nos permitirá isolar a infraestrutura do validador da infraestrutura de gerenciamento de apostas, aumentando assim a segurança. Portanto, ter uma solução geral para gerenciar essas solicitações é prático e necessário.
Este EIP estabelece um quadro para pelo menos três casos principais: depósito, retirada e consolidação. É por isso que EIPs anteriores introduziram campos como WITHDRAWAL_REQUEST_TYPE e DEPOSIT_REQUEST_TYPE, e agora a consolidação adicionará outro campo, CONSOLIDATION_REQUEST_TYPE. Além disso, este EIP pode incluir um mecanismo geral para lidar com restrições desse tipo de solicitação (consulte as constantes: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Embora os detalhes da implementação deste framework ainda não estejam disponíveis, certamente incluirá tipos de solicitação chave, mecanismos de integridade (por exemplo, requisições de hash e Merkle) e processamento de fila de espera e limitação de taxa.
Este EIP tem um significado arquitetural, permitindo que o Eth1 acione operações-chave na camada de beacon através 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 de maneira mais eficiente na camada de beacon.
EIP-2537: Pré-compilação de operações de curva BLS12-381
Consulte: EIP-2537
Se não quiseres aprofundar, podes considerar a pré-compilação de BLS12-381 como uma operação de "hash" criptográfico complexo, agora disponível para utilização em contratos inteligentes. Para aqueles interessados, vamos explorar mais a fundo.
As operações matemáticas realizadas em curvas elípticas como BLS12-381 (e sua correspondente BN-254) são atualmente utilizadas para dois propósitos:
Se você quiser verificar uma assinatura BLS ou uma prova zkSNARK em um contrato inteligente, você deve calcular esses 'pares', o que é muito caro em termos de cálculo. O Ethereum já possui um contrato pré-compilado (EIP-196 e EIP-197) para operações na curva BN254. No entanto, a curva BLS12-381 (agora considerada mais segura e mais amplamente utilizada hoje) ainda não foi implementada como uma pré-compilação. Sem tal pré-compilação, a realização de emparelhamento e outras operações de curva em um contrato inteligente requerem uma grande quantidade de cálculo, como mostrado aqui, e consomem uma enorme quantidade de gás (cerca de ~10^5 a 10^6 gas).
Este EIP abriu muitas portas para aplicações potenciais, especialmente na verificação barata de assinaturas BLS baseadas na curva BLS12-381. Isso torna possível implementar vários esquemas de limiar para diversos fins. Como mencionado anteriormente, os validadores do Ethereum já estão usando assinaturas baseadas em BLS12-381. Através deste EIP, contratos inteligentes padrão agora podem verificar de forma eficiente as assinaturas agregadas dos validadores. Isso pode simplificar a prova de consenso e a ponte de ativos entre redes, uma vez que as assinaturas BLS são amplamente utilizadas em blockchains. As próprias assinaturas BLS de limiar permitem a construção de muitos esquemas eficientes de limiar para votação, geração descentralizada de números aleatórios, multiassinaturas, entre outros.
A verificação de prova zkSNARK mais barata abre caminho para uma ampla gama de aplicações. Atualmente, muitas soluções baseadas em zkSNARK são dificultadas pelos altos custos de verificação de prova, o que torna alguns projetos quase impraticáveis. Esta EIP tem o potencial de mudar isso.
EIP-2935: Salvar o histórico do hash do bloco no estado
Referência: EIP-2935
Esta proposta de EIP sugere armazenar 8192 (aproximadamente 27,3 horas) hashes de bloco históricos no estado da blockchain, a fim de fornecer histórico expandido para clientes sem estado (como rollup) e contratos inteligentes. Ele propõe manter o comportamento atual do opcode BLOCKHASH, mantendo o limite de 256 blocos, ao mesmo tempo que introduz um novo contrato de sistema projetado especificamente para armazenar e recuperar hashes históricos. Este contrato executa a operação set() ao processar os blocos na camada de execução. O método get() está disponível para acesso público, permitindo que qualquer pessoa recupere os hashes de bloco necessários do buffer circular.
Atualmente, é possível referenciar o hash do bloco histórico no EVM, mas o acesso é limitado aos últimos 256 blocos (cerca de 50 minutos). No entanto, em algumas situações, o acesso a dados de blocos mais antigos é crucial, especialmente para aplicativos cross-chain (que precisam provar dados de blocos anteriores) e para clientes sem estado, que precisam acessar regularmente hashes de blocos anteriores.
Este EIP expande o intervalo de tempo disponível para rollup e aplicações cross-chain, permitindo-lhes aceder diretamente aos dados históricos no EVM, sem necessidade de recolha externa. Como resultado, estas soluções tornam-se mais robustas e sustentáveis.
EIP-7623: Aumentar o custo do calldata
Referência: EIP-7623
calldata ajusta o tamanho disponível da carga útil da transação, o que pode ser significativo em algumas situações (por exemplo, ao passar matrizes grandes ou buffers binários como parâmetros). O uso significativo de calldata é principalmente atribuído aos rollups, que enviam a carga útil embalada com o estado atual do rollup.
A introdução de dados binários de grande escala e comprováveis é crucial para o rollup na blockchain. A atualização Dencun (Deneb-Cancun) introduziu uma inovação importante para esse tipo de caso de uso - transações de blob (EIP-4844). As transações de blob têm sua própria taxa de gás especializada 'blob', embora o corpo seja armazenado temporariamente, sua prova de criptografia (compromisso KZG) juntamente com seu hash são integrados à camada de consenso. Portanto, em comparação com o armazenamento de dados usando calldata, o blob fornece uma solução melhor para o rollup.
Incentivar rollup a mover seus dados para blob pode ser alcançado através do “Cenoura e porrete”. A redução das taxas de gas blob atua como “Cenoura”, enquanto este EIP aumenta o custo de calldata como “Porrete” para conter o armazenamento excessivo de dados nas transações. Este EIP complementa o próximo EIP-7691 (Aumento de throughput de blob), que aumenta o número máximo de blobs permitidos por bloco.
EIP-7691: aumento da capacidade de throughput de blobs
Consulte: EIP-7691
Na bifurcação rígida anterior de Dencun, o blob foi introduzido e o valor inicial do número máximo e do alvo de blob por "bloco" é uma estimativa conservadora. Isso se deve à complexidade de prever como a rede p2p lidará com objetos binários grandes que se espalham entre os nós de validação. A configuração anterior provou ser boa, o que torna este o momento certo para testar novos valores. Anteriormente, o número máximo / alvo de blob por bloco era definido como 3/6. Essas restrições agora foram aumentadas para 6/9.
A combinação do EIP-7623 anterior (aumento do custo do calldata) reforçou ainda mais o incentivo para o rollup mover seus dados do calldata para blobs. O trabalho de encontrar os melhores parâmetros de blob continua em andamento.
EIP-7840: Adicionar programação de blob ao ficheiro de configuração EL
Referência: EIP-7840
Esta proposta de EIP adiciona as metas e a quantidade máxima de blocos de blobs por bloco (discutidos anteriormente) e o valor baseFeeUpdateFraction ao arquivo de configuração da camada de execução do Ethereum (EL). Também permite que os clientes recuperem esses valores por meio da API do nó. Essa funcionalidade é particularmente útil para tarefas como estimar o custo do gás do blob.
EIP-7702: Configurar o código da conta EOA
Referência: EIP-7702
Este é um EIP muito importante que trará mudanças significativas aos utilizadores do Ethereum. Como sabemos, um EOA (Endereço de Propriedade Externa) não pode ter nenhum código, mas pode fornecer uma assinatura de transação (tx.origin). Por outro lado, os contratos inteligentes têm bytecode, mas não podem gerar diretamente a sua própria assinatura. Qualquer interação do utilizador que necessite de lógica adicional, automação e verificação só pode ser realizada atualmente através da chamada a contratos externos para executar as operações necessárias. No entanto, nesse cenário, o contrato externo torna-se o msg.sender do contrato subsequente, resultando numa chamada 'de contrato para contrato' em vez de 'do utilizador'.
Esta EIP introduz um novo tipo de transação SET_CODE_TX_TYPE=0x04 (anteriormente tínhamos transações antigas 0x1, novas transações 0x02 da atualização Berlim e EIP-1559, e transações blob 0x03 introduzidas em Dencun). Este novo tipo de transação permite a definição de código para uma conta EOA. Na verdade, permite que uma conta EOA execute código externo "no contexto da sua própria conta EOA". Do ponto de vista externo, durante o processo de transação, a EOA parece "tomar emprestado" o código de um contrato externo e executá-lo. Tecnicamente, isso é alcançado adicionando uma tupla de dados de autorização especial ao armazenamento de "código" do endereço da EOA (antes desta EIP, este armazenamento de "código" para uma EOA sempre estava vazio).
Atualmente, este novo tipo de transação 0x04 proposto pelo EIP contém uma matriz:
authorization_list = [[chain_id, endereço, nonce, y_parity, r, s], ...]
Cada elemento permite que a conta use o código do endereço especificado (do último item de autorização válido). Ao processar transações desse tipo, o código do EOA fornecido é definido como um valor especial de 0xef0100 || endereço (23 bytes), onde o endereço aponta para o contrato que possui o código desejado, || indica a concatenação e 0xef0100 representa um valor mágico especial que não pode ser incluído em contratos inteligentes convencionais (de acordo com o EIP-3541). Esse valor mágico garante que esse EOA não possa ser tratado como um contrato convencional e não possa ser chamado como um contrato convencional.
Quando este EOA inicia uma transação, o endereço especificado será usado para invocar o código correspondente no contexto deste EOA. Embora os detalhes completos da implementação deste EIP ainda não estejam claros, é certo que trará mudanças significativas.
Um dos principais impactos é a capacidade de fazer chamadas múltiplas diretamente a partir de EOA (Endereço de Propriedade Externa). As chamadas múltiplas são uma tendência contínua no DeFi, e muitos protocolos oferecem essa funcionalidade como uma ferramenta poderosa (como Uniswap V4, Balancer V3 ou Euler V2). Com este EIP, agora é possível iniciar chamadas múltiplas diretamente a partir de EOA.
Por exemplo, este novo recurso resolve um problema comum no DeFi: a ineficiência de realizar approve() + anything() em transações separadas. Este EIP permite uma lógica de 'pré-autorização' genérica, permitindo que a aprovação de approve(X) + deposit(X) seja feita em uma única transação.
Uma outra vantagem de ser capaz de 'representar' a execução de transações delegadas por EOA é o conceito de patrocínio. O patrocínio é uma característica frequentemente discutida e altamente desejada para ajudar novos utilizadores a entrar no Ethereum.
A lógica programável associada ao EOA desbloqueou muitas possibilidades, como implementar restrições de segurança, definir limites de gastos, exigir KYC e assim por diante.
Claro, essa mudança também levanta muitos problemas de design. Uma questão é o uso do chain_id, que determina se a mesma assinatura é válida em várias redes, dependendo se está incluída ou não na assinatura. Outra questão complexa é a escolha entre o uso de endereços do código de destino e a incorporação do código de bytes real. Ambos os métodos têm características e limitações únicas. Além disso, o uso do nonce desempenha um papel crucial na definição de permissões como 'multiuso' ou 'único uso'. Esses elementos afetam questões de funcionalidade e segurança, incluindo assinaturas inválidas em massa e usabilidade, entre outros. Vitalik levantou essas questões em uma discussão (aqui) que vale a pena explorar mais a fundo.
É importante notar que esta mudança irá afetar um mecanismo 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 sempre foi a maneira 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), geralmente falham e podem ser evitados (por exemplo, chamando o construtor ou implantando código em um endereço predefinido após a transação). Estas verificações são usadas para prevenir ataques de reentrada e empréstimos relâmpago, mas estão longe de ser ideais, pois também dificultam a integração com protocolos externos. Após este EIP, parece que mesmo a verificação confiável require(tx.origin == msg.sender) está obsoleta. Os protocolos precisam se adaptar removendo essas verificações, pois a distinção entre 'EOA' e 'contrato' não será mais relevante - agora, cada endereço pode ter código associado.
A separação entre o tradicional EOA e os contratos inteligentes continua a ficar cada vez mais difusa. Este EIP faz com que o Ethereum se aproxime mais de designs como o TON, onde cada conta é essencialmente código executável. À medida que a interação com protocolos se torna cada vez mais complexa, usar lógica programável para melhorar a experiência do usuário final é um processo natural desta evolução.
Conclusão
A atualização do Praga / Electra (Pectra) está agendada para março de 2025. As mudanças mais significativas no plano incluem:
Como pode ver, o Pectra terá um impacto significativo na experiência do utilizador final, tanto no que diz respeito ao staking e ao consenso, como à camada de execução. Embora não possamos neste momento analisar em detalhe todas essas mudanças através de código, uma vez que o desenvolvimento ainda está em andamento, iremos abordar estas atualizações em futuros artigos.