Neste artigo, descobrimos o que é o nodo sequencer, um componente essencial do ecossistema dos rollup de Ethereum.
Esta entidade de infraestrutura é responsável por uma série de processos que levam os dados das transações realizadas nos L2 para dentro do L1 principal, agindo como ponto de conexão.
O funcionamento e o grau de descentralização do sequencer afeta diretamente a segurança, a confiabilidade e a resistência à censura dessas soluções.
Vamos ver tudo nos detalhes abaixo.
Summary
O que é o sequencer e qual é o seu papel no mundo EVM
No panorama das soluções de escalabilidade de Ethereum, o sequencer é uma entidade que ordena, executa e agrega transações off-chain antes de publicá-las na blockchain layer-1. O seu papel principal é melhorar a escalabilidade e a eficiência das soluções de layer 2, como os rollup, reduzindo os custos do gás e acelerando a finalização das transações.
Tecnicamente definido como nó, o sequencer processa as transações executadas nos rollups e as encapsula em um “batch” comprimido. Depois, envia esses dados para o Ethereum, onde são oficialmente registrados e adicionados à cadeia primária responsável pela segurança.
Dependendo da arquitetura do layer-2, o sequencer pode ser centralizado ou descentralizado, e pode influenciar aspectos críticos como a ordem das transações, a disponibilidade de dados e a resistência à censura.
No caso dos Optimistic rollup, como por exemplo Arbitrum e Optimism, o sequencer ordena as tx e as publica no Ethereum assumindo que são todas válidas a menos que sejam contestadas. Nos zk-rollup por outro lado, como por exemplo Starknet e ZkSync, o sequencer além de processar as transações também gera provas criptográficas que são então verificadas no Ethereum. Finalmente, nos rollup do tipo Validium como ZkFair e Rhino.fi, ocorre um processo híbrido em que os dados são parcialmente verificados off-chain.
É importante destacar que esta figura é utilizada também por outras blockchains e soluções de escalabilidade, mas para evitar confusão, neste artigo nos focaremos apenas no mundo EVM. Para conhecimento, informamos que existem componentes análogos aos sequenciadores em ecossistemas como Cosmos, Avalanche Subnets, e Celestia.
O fluxo de trabalho dos sequenciadores nos vários rollup de Ethereum
Explorando mais a fundo as diferentes tarefas realizadas pelos sequencer, vemos como eles gerenciam o ciclo de vida de uma transação executada dentro de um rollup.
Podemos agrupar o seu fluxo de trabalho em 3 etapas fundamentais: a coleta e a ordenação das transações, a execução e a publicação no Ethereum.
1) Coleta e ordenação das transações
Os usuários enviam as transações para o sequencer em vez de diretamente para a L1, o qual as ordena em um determinado bloco de acordo com uma estratégia de ordering. Geralmente nos rollup encontramos uma estratégia “Auction-Based”, onde ocorre um leilão para determinar a ordem de execução (quem paga mais fees tem precedência e é ordenado primeiro).
Outras estratégias podem ser do tipo “First Come First Served” em que as transações são aceitas e processadas na ordem em que chegam.
2) Execução e cálculo do estado
Depois de decidir a ordenação das transações, o sequencer executa-as localmente, atualizando o estado do rollup off-chain.
Esta execução é determinística e segue as regras definidas pelo smart contract do rollup em L1, assegurando assim a integridade das operações.
3) Produção de batch e publicação em L1
Neste ponto, as transações são agrupadas em lotes e enviadas para o L1 Ethereum.,
O sequenciador publica apenas os dados essenciais (calldata) para a Disponibilidade de Dados (DA), garantindo que o Ethereum possa sempre reconstruir o estado on-chain. Este passo assegura que seja empregado o mínimo esforço computacional para manter baixas as taxas da rede L2
Com base no tipo de rollup, estes 3 passos podem variar de forma mais ou menos significativa, como mostrado na tabela a seguir.
| Tipo di Rollup | Coleta de Dados | Execução | Publicação em L1 |
| Optimistic Rollup (Arbitrum, Optimism) | O sequenciador coleta as transações enviadas pelos usuários. | O sequenciador ordena e executa as transações, depois as publica em lote. | Os dados são postados on-chain, e as transações são aceitas após o período de challenge |
| ZK-Rollup (Starknet, zkSync) | O sequenciador coleta as transações, criando um lote de dados para o processamento. | O sequenciador executa as transações e gera uma ZK-proof para demonstrar a validade. | A prova criptográfica garante a validade das transações, sem necessidade de challenge |
| Validium (StarkEx) | O sequenciador coleta os dados das transações mas os mantém off-chain. | O sequenciador executa as transações off-chain e atualiza o estado. | Os dados não são completamente on-chain, reduzindo os custos mas com menor segurança em comparação aos rollup on-chain. |
O problema da centralização dos sequencer
No momento, a maioria dos sequenciadores no Ethereum é centralizada, visto que quase todos os rollups apresentam um único nó encarregado de gerir a conexão entre L2 e L1. Esta configuração é essencial nas fases de “Stage 0” dos rollups, onde é necessário um compromisso entre descentralização e escalabilidade para poder tornar funcional e eficiente toda a infraestrutura na sua fase de desenvolvimento inicial.
Avançando com o tempo, os rollup visam descentralizar seus sequenciadores, introduzindo novas soluções de compartilhamento e federação de nós, passando assim para as fases “Stage 1” e “Stage 2”. Entretanto, a excessiva centralização dos sequenciadores, mesmo que por um período de tempo limitado, poderia criar graves problemas estruturais para a rede de segundo nível em questão.
Em primeiro lugar, confiar o controle a um único nó introduz um “single point of failure”: se o sequencer sofrer um ataque, uma falha técnica ou uma manipulação, toda a infraestrutura pode ser comprometida, levando a atrasos nas transações ou até mesmo a interrupções do serviço. Além disso, essa concentração de poder pode facilitar o risco de censura nas transações, uma vez que o único operador teria a possibilidade de excluir ou reordenar as transações de maneira arbitrária, aplicando estratégias MEV.
Outro aspecto crítico diz respeito à confiança: a falta de um mecanismo de validação distribuído torna difícil para os usuários verificarem de forma independente se as transações foram geridas corretamente. Tudo isso compromete o princípio de descentralização que está na base da filosofia do Ethereum.
A centralização dos nós representa uma arma de dois gumes: o exemplo prático do layer-2 Linea.
Uma centralização excessiva dos sequenciadores configura-se como uma arma de dois gumes, capaz de salvar literalmente um ecossistema inteiro do colapso, mas ao mesmo tempo capaz de levar a uma censura fortemente arbitrária da rede.
O que aconteceu com o layer-2 Linea em junho do ano passado, durante o hack e o exploit do protocolo Velocore, é um exemplo claro.
Naquela ocasião, durante o ataque informático ao DEX, a equipe da Consensys (que gerencia o rollup Linea) decidiu parar a produção de blocos, “desligando” seu próprio sequencer. Ao fazer isso, com a chain praticamente congelada, a equipe da Velocare conseguiu conter o incidente, resolvendo a vulnerabilidade de código encontrada. Enquanto isso, a Consensys censurou o endereço do atacante, tornando impossível a comunicação com o sequencer (que, lembramos, valida as transações e as envia para o L1).
Se não tivesse desligado o sequencer, haveria consequências econômicas muito graves, com impactos não apenas na Linea, mas também no Ethereum.
Os hackers poderiam ter drenado mais fundos dos contratos inteligentes vulneráveis, levando à redução a zero do valor dos ativos baseados em Linea. Além disso, o atacante poderia ter alterado o estado da rede, tornando mais difícil detectar e corrigir o problema.
Isso teria repercussões também em outros protocolos DeFi ligados à Linea, levando muitos usuários a sofrer liquidações ou perdas irreversíveis.
O evento do hack de Velocore levou a comunidade de Ethereum a refletir sobre o delicado equilíbrio entre segurança e descentralização. Por um lado, a intervenção rápida da Consensys evitou um desastre financeiro, protegendo usuários e protocolos de perdas significativas. Por outro lado, o desligamento do sequencer e a censura do endereço do atacante levantaram preocupações sobre o excesso de poder centralizado detido pelos operadores de layer-2.
