A evolução "em segundos" do Ethereum: de confirmações rápidas a compressão de liquidação, como o Interop está a eliminar o tempo de espera?

Autor: imToken

Se costuma fazer transferências entre Base, Arbitrum ou Optimism, certamente já sentiu uma sensação subtil de «fragmentação».

Embora uma única transação em L2 quase seja concluída em segundos, ao tentar mover ativos de uma cadeia A para uma cadeia B, muitas vezes é necessário esperar vários minutos ou até mais tempo. Isso não se deve à velocidade insuficiente do L2 em si, mas sim ao fato de que, no processo tradicional, uma transação que envolve múltiplas camadas e múltiplas cadeias deve passar por um percurso longo e rigoroso:

Ordenador L2 → Submissão ao L1 → Concordância e Finalidade no L1, em suma, na arquitetura atual do Ethereum, a confirmação final no L1 geralmente leva dois Epochs (cerca de 13 minutos). Isso é certamente necessário para segurança, mas para interoperabilidade (Interop), é excessivamente lento.

Se considerarmos a visão macro do Ethereum, onde no futuro existirão centenas ou milhares de L2s que não devem ser ilhas isoladas de execução, mas sim trabalhar em harmonia como um todo, a questão central é se é possível reduzir ao máximo esse tempo de espera.

Nesse contexto, o roteiro de interoperabilidade do Ethereum, na fase de aceleração, propôs claramente três direções de melhoria altamente coordenadas: Regras de Confirmação Rápida (Fast L1 Confirmation Rule), Redução do Tempo de Slot do L1 (Shorter L1 Slots), Compressão do Ciclo de Liquidação de Camada Dupla (Shorter L2 Settlement).

Pode-se dizer que isso não são meramente otimizações dispersas, mas uma reconstrução sistêmica centrada em «confirmação, ritmo e liquidação».

1. Regras de Confirmação Rápida: Antes da Finalidade, fornecer uma «resposta confiável» ao sistema

Como é de conhecimento geral, na arquitetura atual do Ethereum, o intervalo entre blocos principais é de aproximadamente 12 segundos. Os validadores votam na condição atual do estado da cadeia em cada slot, e a confirmação final (Finality) ocorre após vários slots.

Resumindo, mesmo que uma transação já esteja incluída em um bloco, o sistema ainda precisa de um tempo considerável para garantir que ela não será reorganizada ou revertida. Atualmente, para que uma transação seja considerada irreversível, leva cerca de dois Epochs (cerca de 13 minutos). Para a maioria dos cenários financeiros na cadeia, 13 minutos é claramente demais.

Podemos então perguntar: é possível, antes da chegada da Finalidade, fornecer às aplicações e sistemas de cross-chain um «sinal de confirmação» que seja «rápido o suficiente e confiável o bastante»? Essa é a meta do Projeto #4 no roteiro de Interoperabilidade do Ethereum: Fast L1 Confirmation Rule (Regras de Confirmação Rápida).

O objetivo principal é simples: permitir que aplicações e sistemas de cross-chain recebam, em 15–30 segundos, um «sinal de confirmação forte e verificável» do L1, sem precisar esperar os 13 minutos completos de Finalidade.

Do ponto de vista mecânico, as regras de confirmação rápida não introduzem um novo processo de consenso, mas reutilizam as votações dos attesters que ocorrem em cada slot na estrutura PoS do Ethereum. Quando um bloco acumula votos suficientes e dispersos de validadores em um slot inicial, mesmo sem estar na fase de confirmação final, ele pode ser considerado «extremamente improvável de ser revertido sob modelos de ataque razoáveis».

Resumindo, esse nível de confirmação não substitui a Finalidade, mas fornece uma confirmação forte, explicitamente reconhecida pelo protocolo, antes dela. Para sistemas de interoperabilidade, isso é especialmente importante: sistemas cross-chain, Intent Solvers e carteiras não precisam mais aguardar a confirmação final, podendo avançar com segurança em 15–30 segundos, baseando-se em sinais de confirmação do protocolo.

Atualmente, a pré-confirmação (Preconfirmation), promovida por narrativas como Based Rollup, desempenha um papel de transição importante nesse sentido. Sua lógica é simples: imagine o seguinte:

Ao comprar uma passagem de trem no 12306, ao selecionar o itinerário e assinar a transação, o sistema fornece uma «pré-confirmação» de que a compra foi aceita e está em processamento. Assim, podemos planejar a viagem, preparar as malas, etc. Somente quando o bilhete é finalmente confirmado com o vagão e assentos (transação publicada no L1), a compra é concluída oficialmente.

De forma semelhante, em Based Rollup, a pré-confirmação significa que, antes de uma transação ser oficialmente submetida ao L1, ela já é prometida para estar incluída no próximo bloco, dando ao usuário um «sinal preliminar» de que sua transação foi aceita e está sendo processada.

Ou seja, «vou te dar uma promessa verbal forte, a confirmação final virá depois». Essa lógica de confirmação em camadas permite que a rota de interoperabilidade do Ethereum equilibre «segurança» e «velocidade», construindo uma experiência de interoperabilidade o mais fluida possível.

2. Redução do L1 Slot: acelerando o «ritmo cardíaco» do Ethereum

Complementar às regras de confirmação rápida, há uma mudança mais fundamental, de caráter físico: reduzir o tamanho do Slot.

Se a confirmação rápida é como um «cheque prévio» antes da confirmação final, reduzir o tempo de Slot do L1 é como encurtar o ciclo de liquidação do livro-razão. No roteiro de Interoperabilidade, o objetivo do Projeto #5 é claro: diminuir o tempo de Slot do Ethereum de 12 segundos para 6 segundos.

Embora pareça uma simples «metade», essa mudança provoca uma reação em cadeia na rede. Quanto menor o Slot, mais rápido os ativos são incluídos em blocos, distribuídos para validação e confirmados, reduzindo a latência geral do protocolo.

Para os usuários, o impacto é direto: confirmações mais rápidas em transferências de ETH, submissão de estados de L2 ao L1 mais ágil, e, quando combinado com as regras de confirmação rápida, quase uma «retorno em tempo real» na cadeia. Isso permite que DApps, carteiras e protocolos cross-chain ofereçam experiências de confirmação em segundos.

Para protocolos de interoperabilidade, essa redução de tempo também aumenta a eficiência do uso de capital: atualmente, pontes e market makers enfrentam riscos de «funds in transit» que duram minutos ou mais, levando a taxas mais altas para compensar essa incerteza. Com ciclos de liquidação mais curtos, esse capital fica ocioso por menos tempo, reduzindo custos, taxas e atrasos, incentivando o retorno ao uso do layer de liquidação seguro do L1, ao invés de confiar em intermediários frágeis.

Claro que aumentar a frequência do «batimento do coração» da rede não é tarefa fácil. Vários grupos de trabalho da Fundação Ethereum estão avançando nesse projeto complexo:

• Análise de rede: equipes de pesquisa (incluindo Maria Silva e outros) estudam dados para garantir que Slots mais curtos não aumentem riscos de reorganizações graves ou sobrecarga de nós domésticos;
• Implementação de clientes: uma reconstrução de baixo nível que envolve tanto a camada de consenso quanto a de execução. Importante notar que esse trabalho é independente do EIP-7732 (separação de stakers nativos e construtores, ePBS), ou seja, o avanço do «heartbeat» pode ocorrer independentemente do progresso do ePBS.

No geral, ao combinar Slots de 6 segundos com regras de confirmação rápida, o Ethereum poderá oferecer uma «retorno quase em tempo real» na cadeia, permitindo que DApps e carteiras construam experiências de confirmação em segundos nunca antes vistas.

3. Redução do ciclo de liquidação em L2: ativos «podem ser retirados e utilizados instantaneamente»

No roteiro de Interoperabilidade, o Projeto #6 — Shorter L2 Settlement — é uma das mais controversas, mas também uma das mais imaginativas.

Hoje, as soluções como Optimistic Rollup dependem de períodos de desafio de até 7 dias, e mesmo ZK Rollups enfrentam limitações na geração e validação de provas. Embora essa abordagem seja segura, ela traz um problema prático: ativos e estados ficam «trancados por tempo» entre cadeias, elevando custos de cross-chain e aumentando a carga de reequilíbrio para os Solvers, refletindo-se em taxas mais altas para os usuários.

Reduzir o ciclo de liquidação é uma alavanca-chave para escalar a interoperabilidade. As principais estratégias incluem:

• Provas ZK em tempo real: com hardware acelerado e provas recursivas, o tempo de geração de provas diminui de minutos para segundos;
• Mecanismos de liquidação mais rápidos: como modelos de liquidação 2-de-3 seguros;
• Camada de liquidação compartilhada: permitindo que múltiplas L2 alterem seus estados sob uma semântica comum, sem precisar de «withdrawal — wait — deposit».

Porém, uma dúvida central na discussão de interoperabilidade é: se encurtarmos o desafio de liquidação de 7 dias para 1 hora, isso abrirá brechas para ataques?

Teoricamente, essa preocupação não é infundada. Diferentemente de «censura forte» (onde validadores se unem para fazer mal), o risco mais real é uma «censura suave» liderada por construtores de blocos: atacantes que não precisam controlar o consenso, apenas pressionar continuamente os validadores para que não incluam certas transações.

Curiosamente, a única análise econômica sistemática sobre esse cenário foi publicada pela Offchain Labs em fevereiro de 2025, no artigo «Economic Censorship Games in Fraud Proofs». O estudo constrói três modelos, do mais pessimista ao mais otimista:

• G¹: conteúdo do bloco decidido pelo maior lance;
• G¹ₖ: alguns validadores sempre constroem blocos localmente;
• Gᵐ: múltiplos validadores decidem conjuntamente, podendo um deles optar por incluir transações de defesa.

Na prática, validadores podem optar por «missar slots» (não criar blocos), levando a uma degeneração do modelo para G¹. Assim, os autores propõem uma defesa realista: uma estratégia de «dano pequeno, ganho grande» — um mecanismo de delay que permite ao validador, ao detectar anomalias, simplesmente enviar uma transação especial que, ao ser incluída, automaticamente estende o desafio de 1 hora para os tradicionais 7 dias.

Isso força o atacante a entrar numa guerra de custos assimétrica: para impedir essa transação, deve pagar taxas altas em cada bloco, mantendo o ataque por toda a duração do desafio.

Segundo as estimativas do artigo, se um atacante com recursos de 10 bilhões de dólares tentar um ataque contínuo, o custo para o defensor seria:

• Em uma janela de 1 hora, cerca de 33 milhões de dólares em gas;
• Se o mecanismo de delay for acionado, estendendo para 7 dias, o custo do atacante cai para aproximadamente 20 mil dólares.

Em outras palavras, essa é uma vantagem estrutural crucial: o custo do ataque cresce linearmente, enquanto o custo de defesa é uma única ação bem-sucedida.

Essa disparidade entre custo de ataque e defesa garante que, mesmo com ciclos de liquidação mais curtos, a segurança econômica do Ethereum permaneça robusta.

Para a interoperabilidade, isso é fundamental: confirmações rápidas e ciclos de liquidação menores não precisam sacrificar segurança. Com um bom desenho de sistema, confirmações em segundos podem coexistir com segurança econômica — uma base sólida para que a interoperabilidade em tempo real seja viável.

Conclusão final

Talvez alguém questione: por que gastar esforço para otimizar alguns segundos ou minutos de atraso?

Na era dos entusiastas do Web3, estamos acostumados a esperar, e até a aceitar que «esperar» é um preço a pagar pela descentralização. Mas, à medida que o Web3 se torna mais acessível ao público, os usuários não deveriam se preocupar com qual cadeia estão operando, nem com a lógica de finalização do L1.

Confirmações rápidas, batimentos de 6 segundos e mecanismos assimétricos de defesa são, na essência, uma única coisa: eliminar a variável «tempo» da percepção do usuário.

Como já mencionei antes, a melhor tecnologia é aquela que faz a complexidade desaparecer na confirmação em alta velocidade.