O que são os based rollups e por que usam os validadores da Ethereum

Que problema estão os based rollups a tentar resolver?

A maioria dos rollups de camada 2 da Ethereum hoje, incluindo redes conhecidas construídas sobre as stacks OP Stack e Arbitrum Orbit, executam o seu próprio sequenciador. O sequenciador é a máquina que decide que transações dos utilizadores entram no próximo bloco e em que ordem. Para os utilizadores, isto é maioritariamente invisível. Carrega em "trocar", o sequenciador inclui a sua transação e, num segundo ou dois, vê uma confirmação.

Por trás dessa experiência fluida está uma premissa de confiança silenciosa: está a confiar que o operador do sequenciador se comporte de forma honesta. Na prática, um sequenciador centralizado pode reordenar transações para lucrar com movimentos de preço (uma forma de MEV, ou "maximal extractable value"), censurar endereços específicos ou simplesmente ficar offline. A narrativa de segurança do próprio rollup inclui normalmente uma "saída de emergência" que permite aos utilizadores forçar transações através da L1 se o sequenciador se comportar mal, mas essa saída é lenta, cara e raramente utilizada.

Os based rollups, por vezes chamados rollups sequenciados pela L1, propõem uma resposta diferente. Em vez de executarem o seu próprio sequenciador, deixam que os proponentes de blocos existentes da Ethereum incluam transações do rollup diretamente nos blocos da L1. Os mesmos validadores que protegem a Ethereum são também os que ordenam a atividade do rollup. Não há um sequenciador separado em quem confiar, porque não há sequer um sequenciador separado.

O que significa "sequenciado pela L1" na prática?

Para perceber a mudança, ajuda imaginar um rollup normal. Um utilizador assina uma transação na L2, envia-a para a mempool do rollup, e o sequenciador do rollup recolhe-a, ordena-a, executa-a e publica um lote de dados comprimidos de volta na Ethereum para segurança. O passo da ordenação é o trabalho do sequenciador, e esse passo é o que determina se obtém uma troca justa, um ataque sandwich ou uma transação falhada.

Num based rollup, o passo da ordenação é entregue aos proponentes de blocos da L1 da Ethereum. Os utilizadores continuam a submeter transações ao rollup, mas o rollup não decide a ordem. Em vez disso, o próximo proponente da Ethereum que está a construir um bloco pode incluir transações do rollup como parte da construção do seu bloco da L1. O rollup herda a ordenação que a L1 produz, que é exatamente a ordenação que protege a própria Ethereum.

Este design tem um nome por uma razão. O proponente da L1 "baseia" o rollup em cima da atividade da L1. A ordenação das transações do rollup já não é um fluxo independente. Acompanha a ordenação que a L1 produz, para o bem e para o mal.

Que compromissos é que esta arquitetura impõe?

Remover um sequenciador não é gratuito. O primeiro custo é a latência. Um sequenciador L2 típico produz blocos a cada 200 milissegundos a 2 segundos, porque controla o seu próprio relógio. Um based rollup está limitado pelo tempo de bloco da Ethereum, que na mainnet é atualmente de 12 segundos. Isto significa que os utilizadores esperam mais tempo por confirmações suaves, e qualquer aplicação que dependa de feedback rápido, como livros de ordens on-chain ou bots de liquidação agressivos, tem de ser redesenhada para ciclos mais lentos.

O segundo custo é a capacidade de processamento. Um proponente L1 tem espaço limitado em cada bloco, e esse espaço é partilhado entre transações regulares da Ethereum e qualquer atividade de based rollup. Se o rollup se tornar popular, compete com swaps, transferências e liquidações DeFi pela inclusão. Num dia movimentado, as transações do rollup podem ficar em fila durante vários blocos.

O terceiro custo é a composabilidade. A maioria das aplicações de rollup atuais conseguem comunicar entre si dentro do mesmo ambiente L2 quase instantaneamente porque partilham um sequenciador. Os based rollups, por conceção, não partilham um sequenciador com ninguém. As interações entre rollups continuam a acontecer através de mensagens assíncronas e provas, que são mais lentas e mais caras do que a experiência fluida a que os utilizadores se habituaram dentro de uma única L2.

Nenhum destes custos é um impedimento absoluto, mas são reais, e explicam por que motivo os based rollups não são simplesmente "melhores rollups". São uma escolha de arquitetura específica com consequências específicas.

Como é que isto altera o MEV e os pressupostos de confiança?

MEV é o valor que pode ser capturado ao reordenar, inserir ou censurar transações. Numa L2 típica, o sequenciador captura a maior parte deste valor, e os detentores do token do rollup ou os operadores beneficiam frequentemente. Os utilizadores cujas operações são reordenadas normalmente não beneficiam. Uma pequena parte do MEV também escapa para os proponentes L1 que incluem os lotes de dados do rollup.

Num based rollup, o cenário muda. Os proponentes L1 passam a controlar a ordenação de ponta a ponta. Podem capturar o MEV que antes pertencia ao sequenciador L2, e esse MEV é pago em ETH, não no token do rollup. Os defensores argumentam que isto é uma vantagem: alinha os incentivos com a Ethereum, elimina uma classe de negociação off-chain, e impede que os operadores do rollup extraiam rendas dos utilizadores.

O contra-argumento honesto é que os proponentes L1 são um conjunto pequeno e especializado, e a captura concentrada de MEV é um problema político por si só. Torna também a economia do rollup dependente da dinâmica de construção de blocos L1, incluindo aspetos como MEV-Boost, mercados de builders e PBS (proposer-builder separation) que estão a evoluir rapidamente.

Do lado da confiança, a simplificação é real. Os utilizadores já não precisam de confiar que um operador de sequenciador separado se comporte corretamente. Confiam no conjunto de validadores da Ethereum, que é a mesma confiança que já aceitam quando usam a L1. A escapatória, a fallback lenta para L1, deixa de ser um último recurso e passa a ser o caminho normal. Isto é uma redução significativa de pressupostos, não apenas um slogan de marketing.

Quais são os riscos dos based rollups?

O maior risco é o oposto do que o marketing afirma. Os based rollups não eliminam a confiança, concentram-na nos proponentes L1 da Ethereum. Se o comportamento dos proponentes L1 se degradar, por exemplo através de censura, extração coordenada de MEV ou centralização da construção de blocos, o rollup herda tudo isso. O rollup não consegue contornar uma L1 doente porque está, por conceção, montado nas costas da L1.

Um segundo risco é o historial operacional em produção. A abordagem ainda é recente. A Taiko tem sido o based rollup mais visível em produção, e a Kraken lançou a Ink usando uma arquitetura relacionada. São implementações reais com dinheiro real, mas ainda não foram testadas em profundidade ao longo de várias atualizações da Ethereum, hard forks ou grandes rotações de validadores L1. Qualquer um desses eventos pode expor bugs de coordenação ou violações de pressupostos que ninguém viu ainda.

Em terceiro lugar, o teto de latência e capacidade de processamento é um risco de produto, não apenas de experiência de utilização. Aplicações que precisam de inclusão rápida e previsível, incluindo bolsas de derivados, certos padrões de oráculos e bots de trading de alta frequência, podem considerar os based rollups inadequados. Se um projeto escolhe uma arquitetura based e depois tenta acrescentar préconfirmações mais rápidas, acaba por recriar a tal camada de sequenciação centralizada que se propunha a remover, apenas com um rótulo diferente.

Em quarto lugar, existe um risco de token e governança. Muitos rollups têm um token, e os detentores esperam que esse token capture valor. Num based rollup, o fluxo principal de valor vai para os validadores L1 em ETH. O token do rollup tem de encontrar um papel diferente, e esse papel não é óbvio. Projetos que prometem aos detentores do token uma parte do MEV da L1 tendem a estar a fazer promessas que o protocolo L1 na verdade não sustenta.

Por fim, o próprio rótulo "based" tornou-se um pouco de um íman de marketing. Nem todos os projetos que usam a palavra são totalmente sequenciados pela L1, e alguns oferecem arquiteturas híbridas onde um sequenciador centralizado ainda faz a maior parte do trabalho e a L1 é uma fallback. Compradores e programadores devem ler a arquitetura real, não o pitch deck.

Quem está a construir based rollups hoje?

A Taiko é o exemplo mais citado. Tem executado uma arquitetura de based rollup na mainnet da Ethereum durante um período prolongado, com foco em ser "based" no sentido estrito: os proponentes L1 incluem as transações da Taiko diretamente. Passou por várias iterações do seu sistema de provas e do seu mercado de taxas à medida que a equipa aprende o que funciona em escala.

A Ink da Kraken é outro exemplo em produção. A Ink, associada ao ecossistema mais amplo da Kraken, usa uma abordagem based ou híbrida e posicionou-se em torno da ideia de remover um sequenciador centralizado do modelo de confiança. A arquitetura exata ainda está a amadurecer, e é uma das arquiteturas a acompanhar para quem quer ver como o modelo se aguenta à escala de consumidores.

Para além destes, vários grupos de investigação e projetos baseados no OP Stack exploraram a adoção parcial, em que os rollups mantêm uma camada de préconfirmação rápida para os utilizadores, mas acabam por entregar a ordenação à L1. Estes híbridos tentam manter os benefícios de latência de um sequenciador e os benefícios de confiança da sequenciação pela L1, embora, como referido anteriormente, a camada de préconfirmação reintroduza confiança em quem a opera.

O que é que isto significa para si enquanto utilizador ou programador?

Se é utilizador, a mudança prática é subtil. Irá ver confirmações ligeiramente mais lentas num rollup based do que num L2 típico, e pode notar que os tempos de ponte e as operações entre rollups parecem diferentes. Em contrapartida, deve esperar que nenhum operador de rollup isolado possa reordenar ou censurar a sua transação da mesma forma que um sequenciador centralizado pode, o que representa uma melhoria real, ainda que discreta, em termos de equidade.

Se é programador, a questão é saber se a sua aplicação consegue tolerar a latência do tempo de bloco do L1 e a concorrência pelo espaço de bloco partilhado. As primitivas DeFi, os mercados de NFT e muitas aplicações sociais conseguem. As DEXs de perpétuos que dependem de atualizações de preço ao nível do milissegundo, certas arquiteturas de oráculos e jogos com ritmos de tick rigorosos podem ter dificuldades. Vale a pena fazer uma auditoria cuidada ao seu orçamento de latência, à sua exposição a MEV e às suas dependências entre rollups antes de assumir uma arquitetura based.

Se é um investidor a avaliar um token de rollup, o modelo based é um sinal de alerta amarelo em vez de um sinal verde. Não destrói a tese de investimento, mas significa que a habitual tese de "o token captura receita do sequenciador" não se aplica. O token tem de justificar o seu valor noutro lugar, e a equipa deve ser capaz de explicá-lo com clareza.

Como acompanhar os rollups based de forma inteligente

Os rollups based são um alvo em movimento, e a leitura honesta muda à medida que o próprio roadmap do Ethereum evolui. Sinais como o comportamento dos proponentes do L1, a dinâmica do MEV-Boost e a latência de inclusão real que os utilizadores experimentam na Taiko e na Ink importam mais do que anúncios de lançamento. O Zippfeed destaca o fluxo de títulos de rollup e Ethereum com pontuação de sentimento, bullish, neutral ou bearish, além de uma classificação de importância, para que possa distinguir verdadeiras mudanças de arquitetura de meras reformulações e marketing. Assim, perde menos tempo a separar o ruído e ganha mais tempo a decidir qual o design de L2, incluindo o tipo based, que realmente se adequa ao que está a construir ou a deter.