“Rollup” é o termo dado para soluções de escalabilidade que envolvem o agrupamento (“rolling up”) de um lote de transações.
Em vez de diversas transações serem transmitidas à rede principal do Ethereum, são agrupadas e processadas em uma rede secundária (de segunda camada ou L2) e, em seguida, transmitidas de uma só vez ao Ethereum, aliviando a sobrecarga da rede principal e barateando custos.
Arbitrum, Optimism e Loopring são as rollups mais conhecidas.
Entendendo a economia de rollups a partir de princípios básicos
Rollups são um primitivo fascinante. Estão prestes a se tornar a forma preferida do Ethereum de escalar e oferecer um amplo local de desenvolvimento para suas operações no futuro.
Em todos os aspectos, rollups ampliam o protocolo onde são desenvolvidas, preservando grande parte de suas propriedades. Tudo isso é importante para garantir a exatidão de sua execução “off-chain” (fora da blockchain), bem como a disponibilidade dos dados envolvidos na execução. A forma de atingir isso cabe ao desenvolvedor.
Recentemente, fiquei interessado* em entender mais sobre rollups a partir de uma perspectiva econômica. Não é apenas uma preocupação teórica.
Taxas na camada-base (primeira camada ou L1) estão altas e devemos trabalhar agressivamente para fornecer locais onde usuários possam transacionar a uma taxa acessível. Uma economia melhor resulta em uma precificação melhor que resulta em usuários mais felizes.
Então como devemos pensar mais especificamente na economia de rollups? Primeiro, é preciso identificar as partes que interagem no sistema de rollups, quais são seus papéis e suas responsabilidades. Em seguida, precisamos destrinchar os vários custos, as receitas e as taxas que irrigam o sistema de rollups, oferecendo pistas sobre como navegar nesse amplo local de desenvolvimento.
Participantes do jogo das rollups
Para simplificar, vamos idealizar três papéis distintos:
– Os usuários: Enviam suas transações à rede de segunda camada (ou L2), assim como o fariam na L1. Possuem ativos na L2 e interagem com contratos implementados na rollup.
– O operador da rollup: Esse papel agrupa muitos outros. O operador da rollup representa toda a infraestrutura necessária para processar transações recebidas na rede L2. Na realidade, existem sequenciadores que publicam lotes de transações, executores que publicam assertivas, contestadores que informam provas de fraude e comprovadores que computam provas de validade…
– A camada-base: Um protocolo garante a segurança dos dados publicados pelas rollups. É suficiente considerar um protocolo que garante a disponibilidade de dados com uma funcionalidade reduzida para liquidações (como “contratos-modelo” de “bridges” implementados em sua camada de execução), mas também pode ser considerado como um mecanismo de liquidação para fins gerais, como o do Ethereum.
Custos nas rollups
Neste artigo, é adotada uma visão de “sistemas” da rollup, que foca nos custos, nas receitas e nas taxas. Operar um sistema acarreta custos, que são “coletores de energia” — valores que fluem de dentro para fora do sistema.
O sistema também pode receber receitas, que são o oposto, “fontes de energia” — valores que fluem de fora para dentro do sistema. Taxas unem fontes a coletores, transferem valor por todos os componentes do sistema para que cada um desempenhe sua função de forma adequada.
Por exemplo, em outro artigo sobre a EIP-1559 — uma Proposta de Melhoria ao Ethereum que remove moedas de circulação em vez de repassá-las a validadores da rede —, expliquei como analisar a taxa de transação paga pelo usuário:
– Parte da taxa é direcionada ao operador que inclui a transação: no caso da camada-base proof of work (ou PoW), a taxa de mineração compensa mineradores pelo crescente risco “uncle” — em que dois blocos são criados simultaneamente pela rede. Essa taxa recompensa o operador pelo custo de transmitir o bloco. Esse é o 1 ou 2 gwei (a menor unidade da moeda ether) pago no envio de uma transação.
– O restante da taxa paga pelo direito de ser incluído antes dos outros, precificando o congestionamento. Essa taxa compensa a rede e seus usuários que sofrem com o tempo extra de congestionamento. É isso o que a taxa-base da L1 visa ser — quando está em condições normais.
A boa notícia é que a mesma lógica será usada para entender os custos em rollups. Os custos da EIP-1559 envolviam apenas duas partes: o usuário e a camada-base. Com uma arquitetura diferente e o operador estando entre o usuário e a camada-base, é preciso dissociar os custos relacionados ao operador dos custos relacionados à camada-base.
Custos de operadores na L2
Rollups devem encontrar operadores dispostos a aplicar os recursos computacionais para processar os dados da rollup, ou seja, manter um pool de transações, sequenciar lotes, computar “state roots” (responsáveis por armazenar todo o estado do sistema)/diferenças de estado/provas de validade etc.
Esse é um custo tangível, que quantifica os dólares e centavos necessários para operar a infraestrutura responsável por validadores.
Custos para a publicação de dados na L1
É importante analisar o custo para a publicação de dados, pois este realmente é o novo custo na nova economia de rollups. Quando um operador reúne um conjunto grande o suficiente de transações, espera-se que publique um resumo compactado desse conjunto à camada-base.
Hoje, isso não é feito de uma forma muito elegante: dados são publicados simplesmente como “CALLDATA”, um atributo de transação que permite que o remetente acrescente uma sequência arbitrária de bytes.
Geralmente, CALLDATA faz referência ao método de contratos autônomos solicitado pela transação, com os dados desse método.
Pode ser útil pensar em operadores de rollups solicitando algum método para “registrarDadosCompactados” do contrato autônomo da “rollup chain” na L1, em que a mancha dos bytes representa as transações compactadas como seu argumento. Confira um exemplo do contrato “Chain de Transações Canônicas” da Optimism.
O custo para a publicação de dados é pago pela camada-base. Para publicar dados no Ethereum, o atual preço de mercado dos dados é definido pela EIP-1559, onde cada byte superior a zero de CALLDATA consome 16 gas enquanto cada zero byte consome 4 gas.
Com a EIP-1559 multidimensional — conforme apresentado por Vitalik Buterin via “sharding-format blob-carrying transaction” (ou “transação na forma de repartições que carrega uma mancha”, em tradução literal) —, o preço de CALLDATA pode ser encontrado em seu próprio mercado de EIP-1559, precificando o mercado de forma distinta do mercado tradicional de execução.
Neste painel na Dune Analytics, tentei agrupar os dados publicados por algumas das principais rollups. Não tenho certeza se consegui coletar todas, principalmente as rollups de conhecimento zero. Se você notar discrepâncias, favor me avisar! 🙂
Acesse a análise recente de Aditi sobre a precificação de dados do Ethereum e o site L2fees.info.
Custos de congestionamento na L2
Existe um terceiro custo mais intangível. Quando o fornecimento de espaço em blocos em uma rollup não é capaz de atender à demanda existente, recursos escassos devem ser alocados. Usuários são incluídos em detrimento dos usuários que não o são. Em um pequenino mundo esférico de usuários indiferentes ao tempo, estes simplesmente entram em uma fila e esperam sua vez.
Não existe uma perda de valor em um sistema congestionado. Mas quando usuários pagam para esperar, vão tentar minimizar seu atraso o máximo possível. Para usuários que estão no fim da fila, a queda no seu bem-estar é um custo ao sistema da rollup como um todo.
É comum — pelo menos no Ethereum — depender de mercados de taxa para operar essa alocação, tornando esse custo explícito(1).
Sem uma taxa de mercado ou alguma forma de precificação pelo congestionamento, usuários ou “pagam com o tempo” (são incluídos depois), subornando proponentes de blocos fora da blockchain para que sejam incluídos ou repetidamente reenviando suas transações para garantir que uma delas será escolhida no “mempool” — local onde estão as transações pendentes.
Em todos esses três exemplos, usuários expressam sua perda de utilidade por conta do congestionamento ao gastarem recursos para evitarem essa perda.
Receitas em rollups
Agora que já entendemos os custos de uma rollup, vamos tentar raciocinar sobre receitas de sistema. Aqui, distinguimos duas fontes principais: valor de transações e emissão.
Valor de transação
Usuários ganham valor ao transacionarem em uma rollup em vez de em outro lugar e, por isso, estão preparados para pagar taxas pelos serviços que obtêm. Aqui, o “valor” se refere à utilidade que um usuário obtém ao ter sua transação incluída na rollup.
Se eu tiver uma utilidade de US$ 50 para a inclusão, estou disposto a pagar essa quantia para que minha transação seja incluída. Se eu acabar pagando US$ 2, meu superávit equivale a US$ 48.
A receita de quem quer que receba a taxa é de US$ 2 mas, da perspectiva do sistema de rollups, a entrada inicial de capital equivale a US$ 50 do valor.
Em segundo lugar, quando a transação contiver um valor máximo extraível (ou MEV) — a transação for uma conversão barata em alguma corretora descentralizada (ou DEX) —, essa quantidade é acrescentada à nossa noção de valor de transação.
Neste momento, não importa quem recebe esse valor; seja o sequenciador que extrai o valor, seja o usuário que está realizando a transação ou outro elemento. A única coisa que importa aqui é que a nossa transação inicial trouxe mais valor ao sistema como um todo do que o usuário original iria receber:
Valor de transação = valor de usuário + MEV
Emissão
Uma segunda fonte de receita é a emissão. Na camada-base, produtores de bloco recebem receita na forma de moedas recém-criadas — a emissão da criptomoeda nativa da rede que ajudam a manter. Essa receita compensa seus custos de infraestrutura, conforme mais produtores de bloco surgem enquanto a tarefa ainda é lucrativa.
Considere que uma rollup seja capaz de emitir seu próprio token e que este token possui um valor superior a zero. A rollup pode pagar por alguma de suas operações ao emitir novos tokens para cobrir suas obrigações.
Aqui, o modelo é confuso, com diversas formas de despesas dessa fonte de receita dos custos de rollups. Por enquanto, vamos apenas considerar que é possível emitir tokens valiosos e, dessa forma, trazer mais valor ao sistema.
Passando a bola: Edição das rollups
Resumindo, um sistema de rollups inclui três partes: os usuários, os operadores de rollups e a camada-base. A operação do sistema acarreta três tipos de custos: o custo de operações, os custos para a publicação de dados na camada-base e os custos de congestionamento. O sistema recebe receita de duas formas: valor de transação e emissão.
Leia Também
Agora, é simplesmente um jogo de combinar quem paga quando pelo quê. Alguns pares são fáceis de resolver. O operador deve pagar a taxa para a publicação de dados na L1 à camada-base. Devem pagá-la exatamente quando publicam os dados e pela taxa cotada pela camada-base(2).
Quando taxas são dinâmicas, precificadas em um mercado de taxas, os custos de congestionamento da L2 também são imediatos. Usuários observam a atual demanda por espaço de blocos em rollups e ajustam suas taxas dada a oferta disponível.
Por exemplo, rollups podem querer implementar um mecanismo de mercado à la EIP-1559 em sua rede para controlar a inclusão de transações na L2. Na sequência, uma taxa-base da L2 é disponibilizada para permitir que haja uma estimativa fácil dos atuais custos de congestionamento da L2 pelos usuários.
Equilíbrio orçamental: Um limite para passar a bola
Agora, vamos acrescentar um novo limite ao nosso sistema: o equilíbrio orçamental de operadores. Vamos considerar que o operador da rollup não possa operar em prejuízo — devem pelo menos receber uma receita igual ou superior a suas despesas.
Essa hipótese pode não ser sempre sustentada, mas parece fundamental para mim se nos importarmos com um conjunto suficientemente descentralizado e aberto de operadores em um futuro em que operadores são descentralizados. Operadores que agem em prejuízo podem ser incapazes de pagar participantes mais bem-capitalizados e restringir o conjunto de operadores(3).
Um conjunto menor de operadores diminui as garantias de resistência à censura onde, no pior dos cenários, um usuário deve forçar a inclusão de sua transação na camada-base, pagando altas taxas.
A emissão é útil como uma variável básica para garantir o equilíbrio orçamental. Toda vez em que operadores estão recebendo pouquíssima remuneração, deixam o sistema, aumentando a parcela de emissão recebida pelos operadores restantes até que o equilíbrio seja atingido novamente.
Da mesma forma, quando operadores estão recebendo demasiada remuneração, novos participantes competem para obter uma parcela dos lucros até que operadores estejam novamente com o orçamento equilibrado.
Mantendo o equilíbrio orçamental de operadores com pagamentos atrasados
Com a norma do equilíbrio orçamental, devemos considerar como operadores mantêm um saldo não negativo. Sua saída principal de capital (as taxas para a publicação de dados na L1) são variáveis e cobradas separadamente de sua entrada principal de capital (as taxas de transação).
Aqui, a hipótese é que operadores têm total conhecimento de seus custos de operação na L2 e cotam um preço exato para o usuário no momento da transação (assim como sabem das “taxas-uncle” e da taxa de mineração correspondente que irá compensá-los). Mas como devem cotar usuários pelo custo eventual para a publicação de dados na L1 que é definida posteriormente?
Atualmente, rollups implementam heurísticas para se protegerem da variabilidade de custos para a publicação de dados na L1. Em um exemplo, a rollup observa a atual taxa-base da L1 (obrigado, EIP-3198!) e preenche a taxa com uma “fila” (ou “buffer”) extra, sobrecarregando o usuário previamente caso operadores precisem pagar mais para publicar os dados posteriormente.
Em outro exemplo, usuários custeiam uma função da média móvel da taxa-base da L1 para compensar variações no longo prazo.
Ao meu ver, a solução natural é recorrer a derivativos — simples contratos futuros com taxas-base na L1. No momento da transação, o usuário paga uma taxa que custeia o bloqueio de um preço futuro para a publicação dos dados na camada-base. Ao reduzir o excedente pagamento pessimista, poupanças são repassadas aos usuários. Entender o desenvolvimento ideal de tais derivativos continua sendo uma questão em aberto.
O que fazer com as taxas de congestionamento?
Considerando que a rollup precifica perfeitamente o custo de congestionamento quando usuários transacionam, agora existe uma receita disponível na forma de taxas de congestionamento. Atualmente, na camada-base do Ethereum, essas taxas são “queimadas” (removidas de circulação).
O primeiro motivo dessa ação é a compatibilidade de incentivos: caso as taxas de congestionamento voltem ao produtor do bloco, a taxa de base cotada pelo protocolo não é mais vinculativa, destruindo o propósito da EIP-1559. Mas a queima não é a única opção que preserva a compatibilidade de incentivos.
Propõe-se direcionar todas as taxas “exauridas por rollups”, que surgem de externalidades econômicas (como congestionamento ou MEV) para o financiamento de bens públicos(4). Essa não é uma solução ruim.
Geralmente, a precificação de congestionamento em cidades é destinada para melhorias no sistema de transporte público — é o dinheiro gasto para compensar as externalidades negativas que, quando precificadas de acordo, fornecem essa receita.
Perceba que o MEV foi incluído… Por que deveríamos pensar nele da mesma forma em que pensamos nas taxas de negociação? Primeiro porque, assim como o congestionamento, o MEV é uma externalidade.
O simples ato de emitir uma transação com MEV cria uma externalidade positiva àqueles que podem capturá-la(5).
Externalidades são um “valor não combinável” — surgem de alguma atividade econômica original que equilibrou o trabalho útil com o pagamento por esse trabalho (usuários pagam os custos de operação na L2; operadores pagam pelos custos para a publicação na L1), mas produzem ou destroem um pouco de valor extra nesse processo.
Isso é mais bem-articulado no conceito de leilões de MEV. Nesse design, operadores competem pelo direito de criar um bloco com base em quanto valor podem extrair dele. Nessa noção de valor, estão implícitos os custos de congestionamento, que usuários expressam ao ofertar uns contra os outros. Mais explícito é o próprio MEV, pelo qual possíveis operadores competem.
Novamente, considerando que nenhum operador possa agir em prejuízo, seus lances devem refletir sua verdadeira capacidade de extrair valor do bloco — um operador apostaria na soma de taxas de usuários em seu lote além do MEV que extrai do lote.
Enquanto isso, considerando que operadores devem pagar uma quantia exata em custos de operação na L2 e que os custos para a publicação de dados na L1 são cobrados do usuário, obtemos:
– Taxa de usuários = taxa para a publicação de dados na L1 + taxa de operação na L2 + taxa de congestionamento na L2;
– Custo para o operador = custo de operação na L2 + custo para a publicação de dados na L1;
– Lucro do operador = receita do operador – lucro do operador = taxa de congestionamento na L2 + MEV.
Em um mundo onde operadores competem em um mercado eficiente para conseguir o direito de propor um bloco, operadores devem apostar na totalidade de seus lucros — exatamente nas taxas de congestionamento e no MEV disponíveis em seu lote(6).
Esse é o valor que “escorrega” para o sistema: o primeiro, de usuários que se protegem de prejuízos por conta do congestionamento; o segundo, do efeito dominó causado pela transação inicial. Esse valor nunca foi de ninguém, para início de conversa, então por que não deve ser coletado e redistribuído de alguma forma?
Desempacotando
Muitas hipóteses foram feitas neste artigo. Por exemplo, considerei o “equilíbrio orçamental de operadores” como eu acredito que a comunidade deva considerar rollups que operam em prejuízo com um olhar crítico, possivelmente menos prontas para a descentralização.
A emissão ajuda a reestabelecer o equilíbrio orçamental, apesar de depender de um sinal exógeno de preço (o valor do token) para harmonizar incentivos de operadores.
Nessa visão, continua sendo preferível que operadores precifiquem da forma mais precisa possível seus custos de operação na L2 e os custos para a publicação de dados na L1. Isso evita futuras assimetrias na receita, em que um operador espera que um preço mais alto do token cubra suas operações(7).
Mas este não é um pedido de defesa por uma forma específica de economia para rollups. O setor de desenvolvimento continua bastante amplo.
Entender os custos de operadores na L2 revela mais complexidades que não exploramos aqui — as instituições de mercado que apoiam uma infraestrutura descentralizada para gerar provas de validação para zk-rollups.
O foco em tipos específicos de usuários nas rollups — como serviços mais rápidos de saque da L2 para a L1 ou bridges entre blockchains de L2 — também revelaria diferentes facetas de demanda por usuários.
Com ideias transparentes sobre custos, receitas e taxas, agora é possivelmente mais fácil pensar sobre as consequências e os objetivos comerciais que uma rollup deve atingir e os meios de atingi-los.
Outros recursos
– Em “Espera aí… É tudo precificação de recursos?” (slides e vídeo aqui), John Adler fornece mais contexto sobre os custos de operação na L2 e a separabilidade dos custos de disponibilidade de execução e dados.
– “Sistematização do conhecimento (SoK): Validando ‘bridges’ como uma solução de escalabilidade para blockchains”, por Patrick McCorry, Chris Buckland, Bennet Yee e Dawn Song.
Muito obrigado a Anders Elowsson, Vitalik Buterin, Fred Lacs e Alex Obadia por muitos comentários úteis e a Michael Silberling por suas percepções e discussões.
Notas
1 Vitalik também sugeriu que esse custo é um custo de oportunidade para o fornecedor de espaço em blocos. Nessa interpretação, se você for incluído, deve pagar ao fornecedor pelo menos o que ele poderia ganhar ao incluir a transação de outra pessoa.
2 Isso significa que podemos desempacotar ainda mais o nosso modelo. O custo para a publicação de dados é cotado ao avaliar o congestionamento na camada-base e recompensar operadores da camada-base (operadores de bloco)!
3 A centralização do conjunto de operadores de rollup pode não ser tão ruim quanto a centralização do conjunto de produtores de blocos na camada-base, mas a avaliação das compensações de descentralização na rede da rollup pode ser feita em outro artigo.
4 Neste momento, até taxas incompatíveis, como aquelas recebidas de usuários para se protegerem dos custos para a publicação de dados, são direcionadas a alguns financiamentos de bens públicos, no caso da iniciativa retroPGF da Optimism: US$ 1 milhão em doações para contribuidores à comunidade Ethereum.
5 Curiosamente, com leilões de preço de gas, a batalha para capturar essa externalidade positiva cria externalidades negativas para a rede como um todo, que precisa lidar com ainda mais congestionamento!
6 Note que a eficiência de mercado não é mais uma hipótese justa em um mundo em que alguns operadores obtêm um fluxo privado de ordens de transação ou alguns estão envolvidos em MEV entre domínios (obrigado, Alex Obadia!). No caso do MEV entre domínios, a eficiência de mercado entre extratores entre domínios pode restabelecer a eficiência de mercado em leilões de criadores de domínio único.
7 Aliás, esse modelo não é tão ruim! É o modelo com o qual mineradores operaram todo esse tempo. Ainda assim, precisamos levar em consideração que qualquer risco adicional tomado pelo operador é uma nova pressão para centralizar, impedindo a disponibilidade de primitivos para a gestão de risco (derivativos). Mesmo na presença de tais opções para a proteção ao risco, o conhecimento necessário para realizar um bom negócio pode ser alto, impedindo operadores menos sofisticados.
*Texto escrito por Barbané Monnot, que faz parte da equipe de pesquisa Robust Incentives Group da Ethereum Foundation, especialista em análises de incentivos para protocolos. Publicado originalmente no Substack do autor.
**Traduzido por Daniela Pereira do Nascimento com autorização do autor.
