A evolução "em segundos" do Ethereum: da confirmação rápida à compressão de liquidação, como a Interop elimina o tempo de espera?

Se você costuma transitar entre Base, Arbitrum ou Optimism, certamente já sentiu uma sutil sensação de “fragmentação”.

Embora as transações em uma única L2 já sejam praticamente instantâneas, quando você tenta transferir ativos da cadeia A para a cadeia B, muitas vezes é necessário esperar vários minutos ou até mais. Isso não ocorre porque a L2 não é rápida o suficiente, mas sim porque, no processo tradicional, uma transação que envolve múltiplas camadas e cadeias precisa seguir um caminho longo e rigoroso:

Ordenação pelo sequenciador da L2 → envio para a L1 → consenso e finalização (Finality) na L1, em resumo, na arquitetura atual do Ethereum, a finalização na L1 normalmente requer dois Epochs (cerca de 13 minutos). Isso é necessário para a segurança, mas para a interoperabilidade (Interop), acaba sendo lento demais.

Afinal, segundo a grande visão do Ethereum, no futuro existirão centenas ou milhares de L2s, que não devem ser ilhas isoladas de execução, mas sim trabalhar de forma colaborativa como um todo. Assim, a questão central é se é possível reduzir ao máximo esse tempo de espera. 

É nesse contexto que o roteiro de Interop do Ethereum, na fase de aceleração (Acceleration), propõe claramente três melhorias altamente coordenadas: regra de confirmação rápida (Fast L1 Confirmation Rule), redução do tempo de slot da L1 (Shorter L1 Slots), e compressão do ciclo de liquidação das redes de segunda camada (Shorter L2 Settlement). 

Ou seja, não se trata de uma otimização pontual, mas de uma reestruturação sistêmica em torno de “confirmação, ritmo e liquidação”.

1. Regra de Confirmação Rápida: dar ao sistema uma “resposta confiável” antes da Finality

Como é sabido, na arquitetura atual do Ethereum, o intervalo de blocos na mainnet é de cerca de 12 segundos, os validadores votam sobre o estado da cadeia em cada slot, e a finalização (Finality) ocorre vários slots depois.

Resumindo, mesmo que a transação já tenha sido incluída em um bloco, o sistema ainda precisa esperar um tempo considerável para garantir que ela não será reorganizada ou revertida. Atualmente, para que uma transação seja considerada irreversível, são necessários cerca de dois Epochs (aproximadamente 13 minutos), o que é claramente longo demais para a maioria dos cenários financeiros on-chain. 

Então, será que podemos fornecer um sinal de confirmação “rápido e confiável” para aplicações e sistemas cross-chain antes da Finality? É exatamente isso que o Ethereum propõe no Project #4 do roteiro Interop: Fast L1 Confirmation Rule (regra de confirmação rápida).

O objetivo central é direto: permitir que aplicações e sistemas cross-chain recebam um sinal de confirmação “forte e verificável” da L1 em 15–30 segundos, sem precisar esperar os 13 minutos necessários para a Finality completa.

Em termos de mecanismo, a regra de confirmação rápida não introduz um novo processo de consenso, mas reutiliza as votações dos attesters que ocorrem em cada slot no sistema PoS do Ethereum. Quando um bloco acumula votos suficientes e suficientemente distribuídos de validadores nos slots iniciais, mesmo que ainda não tenha atingido a finalização, pode ser considerado “altamente improvável de ser revertido sob um modelo de ataque razoável”.

Em outras palavras, esse nível de confirmação não substitui a Finality, mas fornece uma forte confirmação reconhecida pelo protocolo antes dela. Para a Interop, isso é especialmente importante: sistemas cross-chain, Intent Solvers e carteiras não precisam mais esperar cegamente pela finalização, podendo avançar com segurança para a próxima etapa em 15–30 segundos, baseando-se no sinal de confirmação em nível de protocolo.

Atualmente, a pré-confirmação (Preconfirmation) promovida pela narrativa Based Rollup já desempenha um papel importante como transição de engenharia nessa direção. O conceito é simples, como o próprio nome sugere. Imagine o seguinte: 

Ao comprar uma passagem de trem no 12306, assim que você seleciona a viagem e faz o pedido (assinando a transação), o sistema de reservas fornece uma pré-confirmação, informando que a compra (cada transação) foi aceita e está em processo de confirmação. Nesse momento, já é possível planejar a viagem, arrumar as malas, etc. Só quando a passagem é finalmente confirmada com vagão e assento (transação publicada na L1), a compra está oficialmente concluída.

Resumindo, no Based Rollup, a pré-confirmação é o compromisso de incluir a transação em um bloco antes de ela ser oficialmente submetida à L1 para confirmação, fornecendo ao usuário um sinal inicial de que a transação foi aceita e está em processamento.

“Primeiro te dou uma promessa verbal forte, a confirmação final vem depois.” Com essa lógica de confirmação em camadas, o roteiro Interop do Ethereum, na prática, segmenta cuidadosamente diferentes níveis de confiança entre “segurança” e “velocidade”, criando uma experiência de interoperabilidade o mais fluida possível. 

2. Redução do Slot da L1: acelerando o “batimento cardíaco” do Ethereum

Complementando a regra de confirmação rápida, que é uma “reconstrução lógica do consenso”, há uma mudança ainda mais fundamental e física: a redução do tamanho do Slot.

Se a confirmação rápida é como emitir um “vale” antes do consenso final, reduzir o tempo do Slot da L1 é encurtar diretamente o “ciclo de liquidação” do livro-razão. No roteiro Interop, o objetivo do Project #5 é claro: reduzir o tempo de Slot da mainnet Ethereum de 12 segundos para 6 segundos.

Parece uma simples “divisão pela metade”, mas na verdade desencadeia uma reação em cadeia em toda a rede. Isso é fácil de entender: quanto menor o slot, mais rápido as transações são incluídas em blocos, distribuídas para validação e confirmadas, resultando em menor latência no protocolo.

O impacto na experiência do usuário também é direto: interações na L1 (como transferências de ETH) são confirmadas mais rapidamente, o envio de estados da L2 para a L1 ocorre em ritmo mais acelerado, e a combinação de slots mais curtos com a regra de confirmação rápida cria um “feedback on-chain quase em tempo real”, permitindo que DApps, carteiras e protocolos cross-chain ofereçam experiências de confirmação em segundos.

Para protocolos de interoperabilidade cross-chain, a redução do tempo significa também um salto na eficiência do uso de capital. Atualmente, pontes cross-chain ou market makers, ao gerenciar ativos entre diferentes cadeias, precisam assumir o risco de “capital em trânsito” por vários minutos ou mais. Para se protegerem contra a volatilidade nesse período, acabam cobrando taxas mais altas.

Quando o ciclo de liquidação da L1 é reduzido e a velocidade de rotação do capital dobra, a ocupação desse capital em trânsito diminui significativamente. O resultado é claro: menor custo de fricção, taxas mais baixas para o usuário e menor atraso no recebimento, incentivando desenvolvedores e usuários a retornarem à camada de liquidação segura da L1, em vez de depender de relays de terceiros frágeis.

Obviamente, dobrar a “frequência do batimento cardíaco” não é tarefa fácil. Diversos grupos de trabalho da Ethereum Foundation estão avançando simultaneamente nesse projeto complexo:

• Análise de rede: equipes de pesquisa (incluindo a pesquisadora Maria Silva) estão realizando análises rigorosas de dados para garantir que slots mais curtos não aumentem o risco de reorganizações (Reorg) devido à latência de rede, ou pressionem por centralização nós domésticos com banda limitada;
• Implementação de clientes: trata-se de uma reestruturação profunda que envolve tanto a camada de consenso quanto a de execução. Vale notar que esse trabalho é independente do EIP-7732 (separação nativa de staker-builder, ePBS), ou seja, independentemente do progresso do ePBS, o plano de aceleração do batimento cardíaco pode avançar de forma autônoma;

No geral, quando o slot de 6 segundos se combina com a regra de confirmação rápida, o Ethereum poderá finalmente oferecer “feedback on-chain quase em tempo real”, permitindo que DApps e carteiras criem experiências de confirmação em segundos nunca vistas antes.

3. Redução do ciclo de liquidação da L2: ativos “retirados instantaneamente”

No roteiro Interop, o Project #6: Shorter L2 Settlement é o mais controverso, mas também o mais promissor.

Na arquitetura atual, Optimistic Rollups normalmente dependem de um período de desafio de até 7 dias, e mesmo ZK Rollups estão limitados pelo tempo de geração e verificação das provas. Em termos práticos, esse design é impecável em termos de segurança, mas na camada de interoperabilidade, traz um problema real:

Os ativos e estados ficam “bloqueados no tempo” entre cadeias. Isso não só aumenta o custo do cross-chain, como também sobrecarrega os Solvers com a necessidade de reequilíbrio, resultando em taxas mais altas para os usuários. Por isso, reduzir o ciclo de liquidação é visto como uma das alavancas-chave para a escalabilidade da Interop. As principais direções de engenharia atualmente incluem (leitura complementar: ZK Dawn: O roteiro do fim de jogo do Ethereum está acelerando?):

• Provas ZK em tempo real: com o avanço do hardware e das provas recursivas, o tempo de geração de provas está sendo reduzido de minutos para segundos;
• Mecanismos de liquidação mais rápidos: por exemplo, introdução de modelos seguros de liquidação 2-out-of-3;
• Camada de liquidação compartilhada: permitindo que múltiplas L2s realizem mudanças de estado sob uma semântica de liquidação unificada, em vez do modelo “retirada—espera—depósito”;

Claro, uma dúvida central na discussão sobre Interop é: ao reduzir o período de desafio de liquidação de 7 dias para 1 hora para obter confirmações cross-chain mais rápidas, não estaríamos abrindo espaço para ataques?

Em teoria, essa preocupação não é infundada. Diferente da “censura forte” (validadores agindo maliciosamente em conjunto), o que realmente merece atenção são ataques de censura suave liderados por block builders: o atacante não precisa controlar o consenso, basta suprimir continuamente as ofertas dos defensores, impedindo que transações críticas sejam incluídas na cadeia. 

Curiosamente, a única análise econômica sistemática sobre esse cenário vem do artigo da Offchain Labs publicado em fevereiro de 2025, “Economic Censorship Games in Fraud Proofs”, que constrói três modelos, do mais pessimista ao mais otimista, assumindo: 

• Modelo G¹: o conteúdo do bloco é totalmente decidido pela parte que oferece o maior lance;
• Modelo G¹ₖ: alguns validadores sempre constroem blocos localmente;
• Modelo Gᵐ: múltiplos validadores decidem conjuntamente o conteúdo do bloco, bastando que um deles escolha a transação do defensor.

Na prática, como validadores podem perder slots (miss slots), alguns designs podem até regredir para o cenário mais pessimista G¹, por isso o artigo parte da pior hipótese. 

Com base nisso, os pesquisadores propuseram uma estratégia de defesa altamente pragmática — o mecanismo de defesa por atraso “apostando pouco para ganhar muito”. O núcleo da ideia é que o defensor tem o direito de “adiar com um clique”, ou seja, não precisa concluir todo o processo de verificação em pouco tempo, bastando submeter uma transação crítica com sucesso.

O papel dessa transação é claro: uma vez incluída na cadeia, o período de desafio é automaticamente estendido de 1 hora para os tradicionais 7 dias. Por exemplo, se o defensor detectar um estado anômalo na L2, não precisa concluir toda a verificação em 1 hora, basta enviar uma transação especial para a L1, que funciona como um alarme, estendendo imediatamente o período de desafio para 7 dias.

Isso significa que o atacante é forçado a uma guerra de desgaste extremamente assimétrica: para impedir que essa transação seja incluída, ele precisa pagar taxas prioritárias mais altas do que o defensor em cada bloco, mantendo esse esforço durante todo o período de desafio.

Os resultados quantitativos do artigo são claros: se um atacante poderoso estiver disposto a gastar 100 millions de dólares em um ataque de censura contínuo, então:

• No período de 1 hora, o defensor só precisa de um orçamento de 33 milhões de dólares em Gas para reagir;
• Se conseguir acionar o mecanismo de atraso e estender o período para 7 dias, o custo de defesa cai drasticamente para cerca de 200 mil dólares;

Em outras palavras, trata-se de uma vantagem estrutural crucial: o custo do atacante é cumulativo, enquanto o defensor só precisa de um sucesso para incluir a transação.

É essa enorme diferença entre custo de ataque e custo de defesa (Cost to Attack vs. Cost to Defend) que garante que, mesmo com o ciclo de liquidação drasticamente reduzido, o Ethereum mantenha uma robustez econômica significativa. 

Para a Interop, isso é fundamental: confirmação rápida e ciclos de liquidação mais curtos não precisam necessariamente sacrificar a segurança, e com um design institucional adequado, confirmações cross-chain em segundos e segurança econômica podem coexistir, fornecendo a base mais sólida para a Interop alcançar transferências cross-chain em segundos.

Considerações finais

Talvez alguém se pergunte: por que tanto esforço para otimizar alguns segundos ou minutos de atraso?

Na era geek do Web3, nos acostumamos a esperar, até achando que “esperar” é o preço a pagar pela descentralização. Mas no caminho do Web3 para o público em geral, os usuários não devem, nem precisam, se preocupar com qual cadeia estão operando, muito menos calcular a lógica de finalização da L1.

Confirmação rápida, batimento cardíaco de 6 segundos e mecanismos de defesa assimétricos, no fundo, buscam uma coisa: eliminar a “variável tempo” da percepção do usuário.

Como costumo dizer: a melhor forma da tecnologia é fazer com que a complexidade desapareça completamente em confirmações ultrarrápidas.