O Ethereum já escalou. Essa é a frase que muita gente usa para descrever o estágio atual da rede — como se o problema estivesse resolvido, como se já tivéssemos chegado onde queríamos.

Por muito tempo, a própria Ethereum Foundation abraçou essa ideia. A arquitetura rollup-centric foi aceita como solução padrão, mesmo com todas as suas imperfeições. Não por má fé, mas por falta de maturidade intelectual — palavras deles, não minhas. Era o que dava pra fazer com o conhecimento e as ferramentas que existiam na época.

Só que o ecossistema cresceu. E, com ele, vieram os aprendizados. Vieram os testes reais, os limites, as fricções. E agora, depois de muito estudo, experimentação e debate, a Ethereum está pronta para ajustar o curso.

Está na hora de reescrever o que significa escalar. E de fazer isso sem deixar pra trás o que mais importa: segurança, interoperabilidade e descentralização.

Hoje, o que temos é um ecossistema baseado em rollups — camadas de execução que rodam fora da rede principal, mas que dependem da L1 para segurança e disponibilidade de dados. Funciona, sim. Mas funciona como um quebra-galho elegante. Porque se por um lado a escalabilidade foi conquistada, por outro, surgiram novos pontos de atrito que não dá mais pra ignorar.

A interoperabilidade entre rollups, por exemplo, é quase inexistente. Optimism e Arbitrum são duas redes que compartilham os mesmos princípios básicos, mas que, na prática, vivem em universos paralelos. Aplicações que rodam em uma precisam ser recriadas na outra. Os usuários que estão em uma precisam usar pontes para acessar a outra. A promessa de um Ethereum modular virou uma coleção de pequenos mundos isolados.

E essa fragmentação abriu espaço pra uma série de problemas. Cada rollup é responsável por ordenar suas próprias transações — o que chamamos de sequencer. E hoje, na maioria dos casos, esses sequencers são centralizados. Operados por empresas ou fundações. O que na prática significa que, mesmo rodando em cima de uma rede descentralizada, a execução de transações passa por um ponto único de controle. Isso não é sustentável.

Além disso, cada rollup precisa desenvolver sua própria lógica de validação — a chamada State Transition Function — e criar um sistema de provas compatível com a Ethereum L1. Isso exige tempo, coordenação, governança e, muitas vezes, decisões técnicas difíceis de auditar. E quando algo precisa ser atualizado? A maioria depende de um Security Council — um grupo de pessoas, geralmente multisig, que decide quando e como algo muda. Em outras palavras: segurança por confiança social, e não por garantias criptográficas.

É justamente a partir desses problemas que nasce a proposta dos Native Rollups. E aqui, a mudança é de postura. De mentalidade. Em vez de deixar cada rollup reinventar sua própria base, a Ethereum propõe criar uma estrutura nativa dentro do próprio protocolo para padronizar a validação. Uma precompile — função nativa, embutida — que permite a verificação de uma STF comum a todas as rollups que quiserem aderir a esse modelo.

Com isso, as rollups passam a usar um mesmo mecanismo de validação, atualizado junto com a própria Ethereum. Quando o protocolo evolui, todas as rollups que usam essa precompile evoluem junto. Sem multisig, sem token governance, sem conselho. A segurança, a padronização e a governança são herdadas diretamente da L1.

Mas isso não significa travar a inovação. Cada rollup ainda pode competir por experiência do usuário, pelo sequenciamento, por ferramentas e uso de MEV. O que muda é que a base fica mais segura, mais simples e mais alinhada com os valores originais da rede.

Claro que isso exige ajustes técnicos. A forma mais simples de validar essas execuções seria reexecutar as transações na própria Ethereum — o que não escala por causa do limite de gás. Por isso, a solução real está nas zero knowledge proofs. Ao verificar ZKPs em vez de reexecutar tudo, a Ethereum mantém a segurança e ganha escalabilidade. A L1 só precisa validar a prova. O custo cai. A confiança sobe.

E esse novo modelo também fortalece o ETH. Rollups que quiserem herdar essa segurança e validação da Ethereum precisarão usar ETH para garantir a disponibilidade de dados. Isso significa mais uso do token, mais queima, mais valor capturado pelo próprio protocolo.

A rede deixa de ser apenas uma base de dados imutável e se torna uma infraestrutura de verdade. Um sistema que não só abriga, mas dá forma, direção e segurança aos projetos que constroem sobre ele.

Esse é o reboot. Não um recomeço do zero, mas um redesenho consciente rumo à maturidade. E isso muda a forma como vamos usar a rede daqui pra frente.

O Ethereum já escalou. Essa é a frase que muita gente usa para descrever o estágio atual da rede — como se o problema estivesse resolvido, como se já tivéssemos chegado onde queríamos.

Por muito tempo, a própria Ethereum Foundation abraçou essa ideia. A arquitetura rollup-centric foi aceita como solução padrão, mesmo com todas as suas imperfeições. Não por má fé, mas por falta de maturidade intelectual — palavras deles, não minhas. Era o que dava pra fazer com o conhecimento e as ferramentas que existiam na época.

Só que o ecossistema cresceu. E, com ele, vieram os aprendizados. Vieram os testes reais, os limites, as fricções. E agora, depois de muito estudo, experimentação e debate, a Ethereum está pronta para ajustar o curso.

Está na hora de reescrever o que significa escalar. E de fazer isso sem deixar pra trás o que mais importa: segurança, interoperabilidade e descentralização.

Hoje, o que temos é um ecossistema baseado em rollups — camadas de execução que rodam fora da rede principal, mas que dependem da L1 para segurança e disponibilidade de dados. Funciona, sim. Mas funciona como um quebra-galho elegante. Porque se por um lado a escalabilidade foi conquistada, por outro, surgiram novos pontos de atrito que não dá mais pra ignorar.

A interoperabilidade entre rollups, por exemplo, é quase inexistente. Optimism e Arbitrum são duas redes que compartilham os mesmos princípios básicos, mas que, na prática, vivem em universos paralelos. Aplicações que rodam em uma precisam ser recriadas na outra. Os usuários que estão em uma precisam usar pontes para acessar a outra. A promessa de um Ethereum modular virou uma coleção de pequenos mundos isolados.

E essa fragmentação abriu espaço pra uma série de problemas. Cada rollup é responsável por ordenar suas próprias transações — o que chamamos de sequencer. E hoje, na maioria dos casos, esses sequencers são centralizados. Operados por empresas ou fundações. O que na prática significa que, mesmo rodando em cima de uma rede descentralizada, a execução de transações passa por um ponto único de controle. Isso não é sustentável.

Além disso, cada rollup precisa desenvolver sua própria lógica de validação — a chamada State Transition Function — e criar um sistema de provas compatível com a Ethereum L1. Isso exige tempo, coordenação, governança e, muitas vezes, decisões técnicas difíceis de auditar. E quando algo precisa ser atualizado? A maioria depende de um Security Council — um grupo de pessoas, geralmente multisig, que decide quando e como algo muda. Em outras palavras: segurança por confiança social, e não por garantias criptográficas.

É justamente a partir desses problemas que nasce a proposta dos Native Rollups. E aqui, a mudança é de postura. De mentalidade. Em vez de deixar cada rollup reinventar sua própria base, a Ethereum propõe criar uma estrutura nativa dentro do próprio protocolo para padronizar a validação. Uma precompile — função nativa, embutida — que permite a verificação de uma STF comum a todas as rollups que quiserem aderir a esse modelo.

Com isso, as rollups passam a usar um mesmo mecanismo de validação, atualizado junto com a própria Ethereum. Quando o protocolo evolui, todas as rollups que usam essa precompile evoluem junto. Sem multisig, sem token governance, sem conselho. A segurança, a padronização e a governança são herdadas diretamente da L1.

Mas isso não significa travar a inovação. Cada rollup ainda pode competir por experiência do usuário, pelo sequenciamento, por ferramentas e uso de MEV. O que muda é que a base fica mais segura, mais simples e mais alinhada com os valores originais da rede.

Claro que isso exige ajustes técnicos. A forma mais simples de validar essas execuções seria reexecutar as transações na própria Ethereum — o que não escala por causa do limite de gás. Por isso, a solução real está nas zero knowledge proofs. Ao verificar ZKPs em vez de reexecutar tudo, a Ethereum mantém a segurança e ganha escalabilidade. A L1 só precisa validar a prova. O custo cai. A confiança sobe.

E esse novo modelo também fortalece o ETH. Rollups que quiserem herdar essa segurança e validação da Ethereum precisarão usar ETH para garantir a disponibilidade de dados. Isso significa mais uso do token, mais queima, mais valor capturado pelo próprio protocolo.

A rede deixa de ser apenas uma base de dados imutável e se torna uma infraestrutura de verdade. Um sistema que não só abriga, mas dá forma, direção e segurança aos projetos que constroem sobre ele.

Esse é o reboot. Não um recomeço do zero, mas um redesenho consciente rumo à maturidade. E isso muda a forma como vamos usar a rede daqui pra frente.