A evolução "em segundos" do Ethereum: de confirmações rápidas à compressão de liquidações, 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 quase instantâneas, quando você tenta transferir ativos da cadeia A para a cadeia B, geralmente precisa 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 diferentes camadas e cadeias precisa passar por um caminho longo e rigoroso:

Ordenação pelo sequenciador da L2 → envio para a L1 → consenso e finalização na L1 (Finality), em resumo, na arquitetura atual do Ethereum, a finalização na L1 geralmente leva 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. O ponto-chave é: será 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 direções de melhoria altamente colaborativas: 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 isolada, mas de uma reconstrução sistêmica em torno de "confirmação, batida 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 entre blocos na mainnet é de cerca de 12 segundos. Os validadores votam no estado atual da cadeia a 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 é muito tempo para a maioria dos cenários financeiros on-chain. 

Então, será que antes da Finality, podemos dar aos aplicativos e sistemas cross-chain um sinal de confirmação "rápido o suficiente e suficientemente confiável"? É exatamente isso que o Ethereum propõe no Interop Roadmap com o Project #4: Fast L1 Confirmation Rule (regra de confirmação rápida).

O objetivo central é muito direto: permitir que aplicativos e sistemas cross-chain recebam um sinal de confirmação L1 "forte e verificável" 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 validadores (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 "praticamente impossí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, antes dela, uma confirmação forte reconhecida pelo protocolo. 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 o próximo passo 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á cumpre um papel importante de transição nessa direção. Sua lógica é simples, como o próprio nome sugere. Imagine o seguinte: 

Ao comprar uma passagem de trem no 12306, assim que você seleciona o trajeto 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á podemos 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 é um compromisso de incluir a transação em um bloco antes de ela ser oficialmente enviada para confirmação na L1, dando ao usuário um sinal inicial de confirmação e informando que a transação foi aceita e está em processamento.

"Eu te dou um compromisso verbal forte agora, a confirmação final vem depois." Com essa lógica de confirmação em camadas, o Interop Roadmap do Ethereum está, na prática, segmentando cuidadosamente diferentes níveis de confiança entre "segurança" e "velocidade", construindo 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 no nível 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 "dar 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 Interop Roadmap, o objetivo do Project #5 é claro: reduzir o tempo do Slot da mainnet do 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 como um todo.

O impacto na experiência do usuário também é direto, incluindo interações na L1 (como transferências de ETH) com confirmações mais rápidas, envios de estado da L2 para a L1 em ritmo mais acelerado e, com slots mais curtos combinados à regra de confirmação rápida, praticamente se obtém "feedback on-chain em tempo quase real", permitindo que DApps, carteiras e protocolos cross-chain construam experiências de confirmação em segundos.

Para protocolos de interoperabilidade cross-chain, a redução do tempo também significa 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 compensar o risco de volatilidade nesse período, cobram taxas mais altas.

Quando o ciclo de liquidação da L1 é reduzido e a velocidade de giro do capital dobra, a ocupação de 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, o que incentiva desenvolvedores e usuários a retornarem à camada de liquidação segura da L1, em vez de depender de relays de terceiros frágeis.

Claro, dobrar a "frequência do batimento cardíaco" não é tarefa fácil. Diversos grupos da Ethereum Foundation estão trabalhando simultaneamente nesse complexo projeto:

• Análise de rede: equipes de pesquisa (incluindo a pesquisadora Maria Silva e outros) estão realizando análises rigorosas de dados para garantir que slots mais curtos não aumentem o risco de reorganização (Reorg) devido à latência de rede, nem pressionem por centralização nós domésticos com banda limitada;
• Implementação de clientes: trata-se de uma reconstrução profunda que envolve tanto a camada de consenso quanto a de execução. Vale notar que esse trabalho é independente do EIP-7732 (Native Staker-Builder Separation, 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á realmente oferecer "feedback on-chain em tempo quase real", permitindo que DApps e carteiras construam experiências de confirmação em segundos como nunca antes.

3. Redução do ciclo de liquidação da L2: ativos "saca e vai embora" instantaneamente

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

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

Ativos e estados ficam "bloqueados no tempo" entre cadeias. Isso não só aumenta o custo do cross-chain, como também eleva significativamente o ônus de rebalanceamento dos Solvers, refletindo-se em taxas mais altas para o usuário. Por isso, encurtar 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 roadmap do endgame do Ethereum está acelerando?):

• Prova ZK em tempo real: com aceleração de hardware e provas recursivas amadurecendo, 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 várias L2s realizem mudanças de estado sob semânticas de liquidação unificadas, em vez do modelo "saque–espera–depósito";

Claro, nas discussões sobre Interop, uma dúvida central é inevitável: se, para obter confirmações cross-chain mais rápidas, o período de desafio da liquidação for reduzido dos tradicionais 7 dias para 1 hora, isso abriria espaço para ataques?

Em teoria, essa preocupação não é infundada. Diferente da "censura forte" (validadores agindo maliciosamente em conjunto), o que mais preocupa na prática é o ataque de censura suave liderado por block builders: o atacante não precisa controlar o consenso, basta suprimir continuamente os lances 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". O artigo constrói três modelos, do mais pessimista ao mais otimista, assumindo: 

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

Na engenharia real, 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 para análise. 

Com base nisso, os pesquisadores propõem uma estratégia de defesa altamente prática — o mecanismo de defesa por atraso "apostando pouco para ganhar muito". O cerne é que o defensor tem o direito de "acionar um atraso com um clique", ou seja, não precisa concluir todo o processo complexo de verificação em pouco tempo, bastando submeter uma transação crítica.

O papel dessa transação é claro: uma vez incluída na cadeia, ela automaticamente estende o período de desafio de 1 hora de volta 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 submeter uma transação especial para a L1. Essa transação funciona como um alarme, estendendo instantaneamente 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, o atacante precisa pagar taxas de prioridade superiores às do defensor em todos os blocos, mantendo esse confronto durante todo o período de desafio.

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

• No período de 1 hora, o defensor precisa de apenas 33 milhões de dólares em orçamento de Gas para contra-atacar;
• Se conseguir acionar o mecanismo de atraso, estendendo o período para 7 dias, o custo de defesa cai para cerca de 200 mil dólares;

Em outras palavras, trata-se de uma vantagem estrutural crucial: o custo do atacante é linearmente acumulado, enquanto o defensor só precisa ter sucesso uma vez.

É essa enorme diferença entre custo de ataque e custo de defesa (Cost to Attack vs. Cost to Defend) que garante que, mesmo com ciclos de liquidação drasticamente reduzidos, o Ethereum mantenha robustez em termos de segurança econômica. 

Para a Interop, isso também é fundamental, pois confirmação rápida e ciclos de liquidação mais curtos não precisam necessariamente sacrificar a segurança, e em um design institucional razoável, confirmações cross-chain em segundos e segurança econômica podem coexistir, ao menos 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" é um prêmio a pagar pela descentralização. Mas no caminho do Web3 para o público em geral, o usuário não deve, nem precisa, se preocupar com qual cadeia está operando, muito menos calcular a lógica de finalização da L1.

Confirmação rápida, batimento 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 recentemente: a melhor forma da tecnologia é fazer com que a complexidade desapareça completamente em uma confirmação ultra-rápida.