📜 Primeiro zk-rollup com Stage 1 confirmado: O que é e por que isso importa
A
@Scroll_ZKP se torna o primeiro zk-Rollup a alcançar o status de Stage 1.
Embora a Scroll sempre tenha contado com um sistema de provas zk totalmente funcional, os usuários anteriormente precisavam confiar no sequenciador centralizado para evitar censura ou quedas de serviço.
Isso não é mais necessário.
A atualização Euclid, recentemente aprovada através da governança da Scroll, introduz um modo sem permissão para o sequenciador. Isso garante que a rede continue funcionando mesmo se o sequenciador falhar ou agir de forma maliciosa. Mais importante ainda, ela obriga a inclusão de transações de usuários no Layer 1 (L1), tornando a censura pelo sequenciador impossível.
Com o Euclid, a Scroll deixa de ser apenas um tipo-1 zkEVM para se tornar um Stage 1 Rollup — um marco técnico e de descentralização extremamente importante.
Neste artigo, vamos explicar por que construir um zk-Rollup Stage 1 é algo especialmente difícil, como a Scroll superou esses desafios e o que vem pela frente.
Por que o Stage 1 é especialmente difícil para zk-Rollups
Uma exigência fundamental para rollups Stage 1 é a inclusão forçada e permissionless: usuários devem ser capazes de publicar transações em L1 que o sequenciador será obrigado a incluir na cadeia, mesmo que esteja offline ou censurando. Mas isso gera um grande desafio para os zk-Rollups.
Por quê? Provas zk não são infinitas
Diferente dos optimistic rollups, os zk-Rollups precisam gerar uma prova zk para cada bloco. Essa prova é gerada usando um circuito — que tem um tamanho fixo e não consegue comprovar programas de comprimento arbitrário.
Se uma transação forçada for muito grande ou usar muitos "opcodes" pouco amigáveis para zk (como keccak, extcodesize, etc.), pode ultrapassar a capacidade do provador e travar a finalização de toda a rede.
Um sequenciador centralizado pode evitar isso simulando o circuito antes de propor o bloco e descartando transações muito grandes, se necessário. A Scroll fazia isso com um sistema chamado Circuit Capacity Checker (CCC). Mas isso compromete a descentralização — permitindo que um ator centralizado decida o que os usuários podem ou não fazer.
A solução: Continuations + Provas Recursivas
A solução é dividir os blocos em segmentos menores que caibam no circuito, e depois uni-los de forma recursiva através de agregação de provas.
Essa abordagem de continuação permite provar rastros de execução de tamanho arbitrário — o que significa que transações forçadas não conseguem mais “quebrar” o rollup. Em vez de “essa tx não pode ser provada”, agora temos “essa tx apenas demora mais para ser provada”.
Isso é difícil de implementar com circuitos zkEVM rígidos, que codificam muitas células e restrições fixas.
Por isso, migramos para uma arquitetura de zkVM mais geral: mais leve, extensível e ideal para suportar continuidade de provas.
Como a Scroll alcançou o Stage 1
Stage 1 - Limited Training Wheels
Nesta fase, o rollup passa a ser governado por contratos inteligentes. No entanto, ainda pode existir um Security Council para lidar com possíveis falhas. Esta fase se caracteriza por: Um sistema de provas totalmente funcional; Descentralização na submissão de provas de fraude; Garantia de saída de usuários sem depender de operadores.
O Security Council, formado por um conjunto diverso de participantes, serve como uma rede de segurança, embora seu poder também represente um risco potencial.
Tendo em mente os requisitos de Stage 1 definidos pela
@L2BEAT, vamos ver em detalhes como a Scroll atinge o Stage 1 com a recente atualização Euclid.
Um zkVM pronto para produção: OpenVM
Para viabilizar as continuações e permitir extensibilidade futura, co-projetamos e construímos o OpenVM em parceria com a
@axiom_xyz.
É um backend zkVM altamente otimizado: desenvolvido para uso em produção, não apenas para experimentação.
Com o OpenVM, conseguimos:
• Evitar as limitações rígidas dos circuitos zkEVM tradicionais.
• Suportar continuações para blocos grandes e transações forçadas.
• Implementar novas funções da EVM (como o EIP-7702) com facilidade, sem precisar lidar diretamente com lógica de restrições.
• Aproveitar o ecossistema Rust para acelerar o desenvolvimento e os testes.
Essa mudança não é apenas uma troca de backend. É uma transição de um zkEVM codificado à mão, específico por opcode, para um zkVM totalmente programável — e isso é uma razão central pela qual a Scroll agora atende aos requisitos de Stage 1.
Essa transformação posiciona a Scroll para um desenvolvimento rápido de novas funcionalidades, acelerando significativamente a inovação e trazendo grandes melhorias de desempenho via integração com o Reth.
Um verdadeiro Security Council, e não apenas simbólico
Para atender aos padrões de Stage 1, a Scroll estabeleceu um Security Council diverso e tecnicamente qualificado, com poderes reais — e limitações claras:
• 12 membros no total
• Quórum de 75% necessário para agir
• Pelo menos 7 membros independentes para formar o quórum
• Apenas 2 membros são afiliados à Scroll
O conselho pode intervir rapidamente em emergências, mas atua de maneira transparente e dentro de limites bem definidos. Seu papel é ser uma rede de segurança — e não exercer controle centralizado.
Garantias de saída para o usuário: Você sempre no comando
Um recurso crítico do Stage 1 é proteger os usuários contra atualizações indesejadas.
Com o Euclid:
• Todas as atualizações devem passar pela governança.
• Uma vez aprovadas, o Security Council aplica as mudanças após um período de espera de 3 dias.
• A única exceção são correções de segurança urgentes — e mesmo essas são registradas de forma transparente.
Isso significa que os usuários sempre têm tempo para sair da rede antes que qualquer atualização entre em vigor.
A Scroll não pode atualizar o sistema pelas suas costas nem mover seus fundos — uma proteção essencial que muitos outros rollups ainda não oferecem.
Falha no operador? Os usuários assumem o controle
Se o sequenciador ou proponente da Scroll cair — ou começar a censurar: O protocolo automaticamente se abre para qualquer um.
Graças ao Euclid:
• Qualquer pessoa pode enviar blocos e provas zk diretamente em L1.
• As transações postadas pelos usuários em L1 devem ser incluídas ou o sistema entra em modo permissionless.
• Uma vez nesse modo, o operador centralizado é bloqueado até ser reativado pelo Security Council.
Isso garante que o rollup permaneça ativo, comprovável e utilizável — mesmo que a Scroll desapareça.
Próximos passos: Rumo ao Stage 2
O Stage 1 é um marco enorme, mas a Scroll já está de olho no próximo objetivo: o Stage 2.
Para chegar lá, estamos explorando sistemas com múltiplos provedores de provas e a combinação de zk com trusted execution environments (TEE) para reduzir os poderes emergenciais de qualquer grupo, inclusive do Security Council (que só poderá intervir em caso de bugs no sistema).
É uma faca de dois gumes: quanto mais rápido avançamos, mais riscos surgem. Precisamos ser programáticos e sistemáticos em quão agressivos queremos ser ao evoluir para o Stage 2, iterando rapidamente novas funcionalidades.
Conclusão
Com a atualização Euclid e a conquista do Stage 1, a Scroll está pronto para se tornar o zk-Rollup mais seguro e de maior desempenho atualmente disponível.
Continuamos firmes na nossa missão: entregar segurança, escalabilidade e descentralização de nível
@ethereum, sem atalhos.
O que vem pela frente é ainda mais empolgante.
A Scroll está apenas começando.
Seguiremos inovando, trazendo cada vez mais funcionalidades poderosas e uma experiência de usuário impecável.
O melhor ainda está por vir.