A Próxima Fase do Ethereum: Conectando L1 e L2, Aprimorando a Privacidade e Melhorando a UX

Se você conectar as atualizações do Ethereum dos últimos anos em uma linha, a palavra-chave é inegavelmente "escalabilidade".

Da introdução de blobs pelo Dencun para reduzir significativamente os custos dos Rollups, até a Pectra ajustar a eficiência dos validadores e o mecanismo de staking, e depois a Fusaka implementar o PeerDAS para reduzir a carga de distribuição de dados, a camada de protocolo dedicou quase toda a sua energia a uma única coisa: permitir que o Ethereum processe mais dados sem elevar excessivamente o nível de entrada para os nós.

Este conjunto de estratégias realmente funcionou; os custos de dados do Rollup foram reduzidos e o limite de Gas da mainnet está aumentando steadymente, de modo que a Ethereum já não é mais tão cara como na última bolha, com taxas de dezenas de dólares que desencorajavam os usuários.

Mas a estrada ficou mais larga, e como dirigir ainda é muito incômodo:

• Ainda precisamos transferir ativos entre duas ou três L2s; um pequeno erro e podemos retirar para a cadeia errada;
• Uma transferência claramente foi incluída em um bloco em poucos segundos, mas a ponte e a exchange insistem em fazer você esperar dezenas de minutos para confirmar;
• Professionals Builders quase monopolizam a compactação de blocos; se você quiser enviar uma transação sensível, ela pode ser rejeitada a qualquer momento por regras não oficiais fora do protocolo;
• Para não mencionar que, até hoje, um usuário novo que apenas deseja transferir algumas centenas de dólares em USDC ainda precisa entender por que é necessário ter ETH na carteira, o que é Nonce e o que é Gas;

Essas questões parecem ser meramente fricções na experiência do usuário, mas por trás delas estão mecanismos de protocolo mais fundamentais, como regras de confirmação, construção de blocos, resistência à censura e modelo de conta.

E também é exatamente esse o novo problema que a Ethereum começa a tratar centralmente, de Glamsterdam a Hegotá, do Q4 de 2026 a 2027.

Of course, scaling won't hit the brakes.

Glamsterdam ainda possui uma forte orientação de desempenho, sendo os dois aspectos mais destacados o ePBS (EIP-7732) e o BAL (Block-level Access Lists, EIP-7928); em termos simples:

• ePBS consiste em formalizar oficialmente no protocolo a divisão entre Proposers e Builders que já existe em grande escala fora do protocolo hoje, além de dividir de forma mais científica as janelas de tempo para proposição e validação, proporcionando margem suficiente para blocos maiores no futuro;
• BAL equivale a listar, no início do bloco, uma "lista de acesso", permitindo que os nós antecipem a recuperação de dados e até processem em paralelo, resolvendo diretamente gargalos de I/O de armazenamento;

Além da escalabilidade, a dor real da maioria das pessoas hoje não é se a TPS da Ethereum é suficientemente alta, mas sim "há muitas cadeias".

Por exemplo, o ETH está na rede principal, os memes estão na Robinhood Chain, o USDC usado para pagamento e liquidação pode estar no Arbitrum, e o USDC que você quer comprar na baixa está no Base.....

Para a Ethereum Foundation, os Rollups são todos parte do ecossistema Ethereum, mas para os usuários, é como trocar moeda internacionalmente ou solicitar um visto.

Portanto, para costurar de volta os pedaços espalhados do quebra-cabeça em uma rede, além dos protocolos cross-chain mostrando suas soluções, um mecanismo fundamental recentemente impulsionado pelo protocolo merece atenção: o FCR (Fast Confirmation Rule, Regra de Confirmação Rápida).

Muitas pessoas acreditam que uma transação é considerada concluída assim que é incluída em um bloco, mas do ponto de vista criptográfico e de consenso, um bloco recém-gerado pode sofrer pequenas reorganizações. A "finalidade" verdadeiramente irreversível requer que a Ethereum complete dois Epochs, o que leva aproximadamente 13 minutos.

Normalmente, transferências cotidianas não são um problema, mas para pontes intercadeia, liquidações de grande valor e exchanges centralizadas, é um verdadeiro tormento; para evitar o risco de reorganização, elas só podem fazer você esperar pacientemente.

A ideia por trás do FCR é que, em vez de aguardar passivamente os vários minutos de Finality completa, utiliza-se as Attestation que os validadores já produzem continuamente, permitindo uma avaliação mais precoce de se um bloco já possui suporte de consenso suficientemente forte com base no peso dos votos acumulados.

De acordo com os objetivos da Ethereum Foundation, em condições de sincronização normal da rede, o FCR tem potencial para antecipar essa "confirmação forte" para cerca de 15 a 30 segundos. Embora não seja equivalente à finalidade completa, já é suficiente para fornecer um sinal de confirmação mais precoce, com um modelo de segurança claro, para muitas pontes, comunicações intercadeias e infraestruturas que atualmente precisam aguardar a finalidade.

Mais especificamente, o FCR não precisa esperar por um hard fork específico para ser ativado; ele é mais semelhante a um conjunto de regras de confirmação que podem ser adotadas gradualmente pelos clientes de consenso e pela infraestrutura.

Assim que diversos L2, pontes intercadeias e carteiras começarem a usar este sinal, os atrasos intercamadas causados hoje por "esperar pela finalidade da L1" poderão ser reduzidos de vários minutos para segundos.

Isso também significa que, no futuro, ao transferir um ativo, o sistema pode silenciosamente cruzar duas ou mais cadeias, mas na interface, você precisará apenas clicar em confirmar e o valor será creditado rapidamente.

No entanto, à medida que os blocos ficam maiores e os Builder se tornam mais profissionais, a Ethereum enfrenta outro problema clássico de dilema.

Como os construtores profissionais alcançaram a eficiência máxima na construção de blocos com poder computacional de ponta e fluxo de ordens, o controle sobre a maioria dos blocos naturalmente acabou nas mãos de poucas grandes instituições.

Isso traz um risco extremamente perigoso: a censura.

Se certos Builders, por pressões regulatórias, concorrência comercial ou simplesmente por desaprovação de certos acordos de privacidade, deliberadamente ignorarem e recusarem incluir sua transação legítima no mempool, mesmo que você possua a chave privada e tenha fornecido gas suficiente, sua transação pode ficar presa fora da cadeia (leia mais em “Escrevendo a censura resistente no protocolo: quem decide se uma transação Ethereum pode ser incluída na cadeia?”).

Se a descentralização não conseguir manter o básico da "acesso a transações resistentes à censura", qualquer taxa de throughput mais alta será um castelo no ar.

É por isso que, no planejamento de Hegotá, o FOCIL (Fork-choice Enforced Inclusion Lists, EIP-7805) ocupa uma posição tão crucial.

Sua lógica é extremamente simples e direta: colocar um anel de contenção no Builder.

Para cada Slot, o protocolo seleciona aleatoriamente um grupo de validadores independentes comuns para incluir as transações válidas pendentes que viram na mempool em uma «Lista de Inclusão», mas você, como Builder, ainda pode organizar livremente a ordem das transações para ganhar seu MEV; no entanto, o bloco que você enviar deve conter fielmente todas as transações da lista.

Se o Builder ousar ignorar intencionalmente esta lista, todos os validadores da rede eliminarão diretamente este bloco nas regras de escolha de fork. Em outras palavras, você pode ganhar dinheiro com mérito, mas não pode decidir por toda a rede quem tem direito de usar a Ethereum.

Com a implementação desse mecanismo, finalmente encontrou-se um ponto de apoio para outra lacuna há muito reclamada, mas nunca impulsionada no Ethereum: a privacidade tão aguardada por todos.

Sabe-se que, no passado, quando as pessoas discutiam privacidade, falavam constantemente em provas de conhecimento zero, endereços ocultos e pools de mistura; mas assim que o Builder reconhecer “esta é uma chamada enviada para um contrato de privacidade”, ele simplesmente a rejeitará, e sua magia matemática imediatamente paralisará.

E atualmente, na rota de privacidade da Ethereum, o que o FOCIL preenche é exatamente o ponto mais vulnerável a ser bloqueado, pois, desde que o nível do protocolo garanta incondicionalmente o direito de acesso a cada transação legítima, as investigações de privacidade na camada superior terão espaço para prosperar.

Atualmente, propostas de privacidade mais ousadas, como a EIP-8182 (que tenta introduzir um Pool Nativo ao nível do protocolo), ainda estão na fase de proposta, mas a tendência já é clara: a privacidade não pode mais ser tratada como uma função secundária de um dapp de terceiros — ela precisa gradualmente se tornar um serviço básico da camada subjacente da Ethereum.

A estrutura discutida anteriormente sofreu mais alterações abaixo da superfície, enquanto o terceiro ponto estará diretamente relacionado à experiência de uso dos usuários comuns.

É isso mesmo, a Ethereum finalmente decidiu fazer uma grande reforma no modelo de conta EOA, que persiste há mais de dez anos.

Para ser honesto, o modelo de assinatura de chave privada ainda utilizado pelo Ethereum é extremamente antiético para usuários comuns da internet:

Perder a chave privada é um destino irreversível; mesmo com milhares de stablecoins na carteira, os ativos ficam temporariamente bloqueados por falta de apenas 0,001 ETH para taxas de transação; jogar DeFi exige primeiro aprovar e depois trocar, com três assinaturas necessárias para concluir uma única ação; o nonce da transação deve seguir uma ordem rigorosa — se uma transação travar, todas as outras também param.

Nas duas primeiras atualizações, a comunidade fez vários compromissos. Por exemplo, criou-se o ERC-4337, usando carteiras de contrato fora do protocolo para contornar problemas; e, também, introduziu-se o EIP-7702 na Pectra, permitindo que endereços comuns temporariamente anexassem lógica de contrato para ganhar flexibilidade.

Mas 7702 é, afinal de contas, apenas uma ponte temporária; o verdadeiro foco do Hegotá é o EIP-8141 nativo de abstração de conta (Frame Transactions, transações de quadro).

Pode-se entender simplesmente que, anteriormente, uma transação na Ethereum vinculava rigidamente três coisas: quem prova que é você (verificação) + quem paga essa transação (paga o Gas) + o que exatamente será feito (execução), enquanto o EIP-8141 divide essas três tarefas em diferentes “quadros” na camada de protocolo (leitura complementar: Account Abstraction Nativa + Ameaça Pós-Quântica: Por que o EIP-8141 ainda não se tornou o principal da Ethereum Hegotá?):

• Verificação de quadro: Não está mais limitada a assinaturas de curva elíptica ECDSA fixas, podendo suportar métodos de verificação mais flexíveis, como Passkey, e integrar-se ainda mais com recursos como impressão digital no celular e Face ID, tornando a rotação de chaves e a recuperação de conta mais naturais;
• Quadro de pagamento: Gas patrocinado nativamente. As aplicações podem pagar diretamente o gas para novos usuários, ou você pode especificar no quadro de pagamento que o USDC da transferência seja debitado diretamente, eliminando a necessidade de relés comprando e vendendo off-chain;
• Frame de execução: suporte nativo a lotes atômicos, autorização e troca em um único passo; se bem-sucedido, todos os resultados são aplicados juntos; se falhar, todos são revertidos de forma limpa e definitiva;

Se adicionarmos também o EIP-8250 (Keyed Nonces) atualmente em discussão na fila, as contas futuras poderão ter múltiplas trilhas paralelas de Nonce.

Quando essas funcionalidades forem naturalmente incorporadas ao protocolo, os produtos de carteiras como imToken experimentarão uma liberação qualitativa.

Sabe-se que grande parte do esforço do carteiro passado foi gasto em lembrar os usuários de prepararem o Gas, explicar por que essa transação estava travada, educar os usuários sobre como copiar a frase de recuperação e ajudar os usuários a alternar entre RPCs em diferentes cadeias.

No futuro, quando algoritmos de assinatura, pagamento de Gas, controle de permissões e roteamento de transações puderem ser programados, as carteiras finalmente poderão retornar ao seu lugar adequado, como uma camada silenciosa de sistema operacional entre o usuário e o mundo descentralizado.

It remains fully under the user's control, just like before, but will feel as natural as scanning a payment code on Alipay or unlocking with a fingerprint.

Olhando para trás nas atualizações do Ethereum nos últimos anos, o caminho é na verdade extremamente claro.

Dencun resolve blobs; Pectra continua a escalar enquanto melhora a capacidade dos validadores e contas; Fusaka prepara o caminho para maior throughput de dados com PeerDAS; o próximo Glamsterdam estabelecerá as bases para limites de Gas mais altos e execução paralela por meio de mudanças estruturais como ePBS e BAL.

A expansão ainda não terminou, mas já não é mais o único problema.

O Ethereum finalmente tem tempo para enfrentar os problemas mais fundamentais e mais complicados, o que explica por que a EF reorganizou as diretrizes de desenvolvimento do protocolo em 2026, resumindo-as em três objetivos muito simples:

Escala, melhore a UX e fortaleça a L1.

Ethereum já provou ao mundo que pode se tornar um computador mundial ininterrupto; agora, é torná-lo acessível de forma fluida para o público geral.