Camadas 2, sidechains e pontes como fontes de dados

Uma grande parte da atividade em redes do tipo Ethereum agora ocorre em cadeias de camada 2 e sidechains, em vez de na própria cadeia base. Os fundos se movem entre camadas por meio de pontes, e cada camada tem seus próprios blocos, seu próprio explorador e seu próprio ID de cadeia. Um analista que acompanha fundos apenas na camada 1 os vê desaparecer em um contrato de ponte; quem entende como as camadas registram depósitos, saques e mensagens pode acompanhá-los entre as camadas e indicar o grau de certeza de cada vínculo.

Um mapa do território

A distinção que importa como evidência é onde os dados ficam e quem poderia reescrevê-los. Em princípio, o histórico de um rollup pode ser reconstruído a partir de L1; o histórico de uma sidechain é tão confiável quanto seus próprios validadores.

Sequenciadores e finalização em L2

A maioria dos rollups tem um único sequenciador que ordena as transações e produz blocos L2 rapidamente (normalmente a cada 2 segundos nas cadeias OP Stack, e mais rápido em algumas outras). Os usuários recebem uma confirmação "branda" do sequenciador em segundos; a transação fica ancorada quando o sequenciador publica o lote em L1 e liquidada quando esse bloco L1 é finalizado. A maioria dos rollups também permite que os usuários forcem a inclusão de uma transação por L1 caso o sequenciador os censure.

Para fins de análise, isso cria uma finalização em camadas. Os nós OP Stack expõem cabeças unsafe (somente sequenciador), safe (derivadas dos dados publicados em L1) e finalized (derivadas de blocos L1 finalizados), e as tags safe e finalized funcionam em chamadas JSON-RPC padrão. Crie conjuntos de dados a partir de blocos L2 seguros ou finalizados, como faria em L1 (veja a aula Blocos e cabeçalhos como dados). Já ocorreram interrupções de sequenciadores em vários rollups, e a cabeça unsafe pode ser reorganizada.

Disponibilidade de dados: onde ler os dados de L2

Na prática, analistas leem dados de L2 em nós L2, exploradores e data warehouses, exatamente como em L1, com os mesmos recibos, logs e traces. A cópia em L1 é importante para verificação e para entender os custos:

• Até março de 2024, os rollups publicavam lotes como dados de chamada de L1, armazenados para sempre.
• Desde a atualização Dencun (13 de março de 2024), a maioria os publica como blobs (EIP-4844). Os nós de consenso L1 mantêm os dados dos blobs por 4.096 épocas, cerca de 18 dias, e depois os removem; somente um hash com versão permanece na transação L1. Portanto, para reconstruir o histórico antigo de L2 a partir de L1, é necessário um arquivo de blobs.
• Alguns rollups ZK publicam diferenças de estado em vez de transações, então a cópia em L1 comprova os saldos, mas não lista todas as transferências.

Registre, para cada conjunto de dados L2, o ID de cadeia, o intervalo de blocos L2, o nó ou provedor e, quando pertinente, o bloco L1 que o ancorou.

De L1 para L2: depósitos e mensagens

Um depósito transfere valor ou uma mensagem de L1 para L2. Nas cadeias OP Stack, um usuário (ou o contrato de ponte padrão agindo em seu nome) chama o OptimismPortal em L1, que emite TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData). Os nós L2 leem esses eventos e criam uma transação de depósito do tipo 0x7E no início de um bloco L2 posterior. É assim que um nó OP Stack a retorna:

{
  "type": "0x7e",
  "sourceHash": "0x3c9e…a0d4",
  "from": "0xA1b2…9F",
  "to": "0xA1b2…9F",
  "mint": "0x6f05b59d3b20000",
  "value": "0x6f05b59d3b20000",
  "gas": "0x186a0",
  "input": "0x"
}

Uma transação de depósito não tem assinatura: sua autoridade vem do evento L1. mint é o ETH criado em L2 (aqui, 0,5 ETH), espelhado pelo ETH bloqueado no portal em L1. sourceHash identifica de forma única a origem L1, calculado a partir do hash do bloco L1 e do índice de log do evento, o que o torna a chave de junção exata entre o evento L1 e a transação L2. Em um data warehouse que armazena o tipo como um número inteiro, essas linhas têm o tipo 126.

O Arbitrum usa bilhetes resgatáveis: uma chamada L1 para createRetryableTicket no contrato Inbox cria um bilhete que normalmente é resgatado automaticamente em L2. Se o resgate automático falhar, o bilhete aguarda até uma semana por um resgate manual; portanto, um analista pode ver um depósito em L1 cujo efeito em L2 ocorre dias depois.

Ambas as famílias aplicam aliasing de endereço. Quando um contrato L1 envia uma mensagem para L2, seu endereço em L2 é deslocado pela adição de 0x1111000000000000000000000000000000001111, para que não possa se passar por um contrato L2 no mesmo endereço. Portanto, uma mensagem do contrato L1 0x5d3a…7c10 chega em L2 como proveniente de 0x6e4b…8d21. EOA não recebe alias. Um analista que procurar em L2 pelo endereço do contrato L1 não encontrará nada; deve procurar pelo alias.

De L2 para L1: saques

Um saque canônico é um processo de várias etapas que se desenrola em duas cadeias ao longo de vários dias. Nas cadeias OP Stack:

1. Iniciar em L2: o usuário chama o predeploy L2ToL1MessagePasser em 0x4200…0016 (diretamente ou por meio da ponte L2), que emite MessagePassed com um hash de saque.
2. Comprovar em L1: depois que o estado L2 que inclui essa mensagem é proposto em L1, qualquer pessoa envia uma prova ao OptimismPortal, que emite WithdrawalProven(bytes32 indexed withdrawalHash, address indexed from, address indexed to).
3. Finalizar em L1: após a janela de contestação, qualquer pessoa chama finalize; o portal emite WithdrawalFinalized(bytes32 indexed withdrawalHash, bool success) e libera os fundos.

No Arbitrum, o lado L2 chama o precompile ArbSys (endereço 100, 0x…0064) com sendTxToL1, e, cerca de uma semana depois, a mensagem é executada em L1 por meio de executeTransaction do contrato Outbox.

O hash de saque vincula as três etapas. Há duas armadilhas: qualquer pessoa pode comprovar ou finalizar, muitas vezes um retransmissor, e essa pessoa não é necessariamente a proprietária; além disso, as janelas de contestação variam conforme a cadeia e mudam à medida que os sistemas de prova evoluem (algumas cadeias encurtaram suas janelas com sistemas de prova mais recentes), portanto, verifique os parâmetros em vigor na época. Como uma semana é muito tempo, muitos usuários saem por meio de pontes de terceiros ou provedores de liquidez, que pagam em L1 com seus próprios fundos e rompem o vínculo canônico; a correspondência desses fluxos é abordada na aula Rastreamento entre cadeias.

IDs de cadeia e identidades entre camadas

Toda cadeia EVM tem um ID de cadeia (EIP-155), retornado por eth_chainId e incorporado às transações assinadas:

Use sempre o ID de cadeia e o endereço juntos como chave de cada tabela, nunca apenas o endereço. A mesma chave privada controla o mesmo endereço EOA em todas as cadeias EVM, o que facilita a identificação entre cadeias das EOA. Os contratos são diferentes: um endereço pode conter um contrato em uma cadeia e nada, ou o contrato de outra pessoa, em outra. Em junho de 2022, cerca de 20 milhões de tokens OP foram enviados para um endereço na Optimism onde a multisig do destinatário pretendido existia somente na Ethereum; antes que o proprietário pudesse implantá-la ali, um atacante implantou uma multisig diferente nesse endereço na Optimism e tomou os tokens. O mesmo endereço não significa o mesmo proprietário, a menos que o código e a implantação sejam verificados em cada cadeia.

Uma contagem diária de depósitos OP Stack mostra o filtro padrão:

-- Depósitos diários de L1 para L2 em uma cadeia OP Stack (tipo de depósito 0x7E = 126)
SELECT
  CAST(block_timestamp AS DATE)     AS day,
  COUNT(*)                          AS deposits,
  SUM(mint) / 1e18                  AS eth_minted
FROM transactions
WHERE chain_id = 8453
  AND tx_type = 126
  AND block_timestamp >= TIMESTAMP '2026-01-01 00:00:00'
GROUP BY 1
ORDER BY 1;

A consulta filtra uma única cadeia e transações de depósito, e depois soma o ETH criado. Os nomes das colunas variam entre conjuntos de dados (type ou transaction_type; mint pode não estar disponível), e os tipos de timestamp diferem conforme o mecanismo; verifique o esquema antes de confiar em um resultado zero.

Foco no exame: rollups otimistas versus ZK versus sidechains e onde ficam os dados de cada um; sequenciadores e as cabeças unsafe, safe e finalized; blobs desde março de 2024 e sua retenção de cerca de 18 dias; depósitos OP Stack (TransactionDeposited, tipo 0x7E, mint, sourceHash como chave de junção) e bilhetes resgatáveis do Arbitrum; aliasing de endereços de contratos L1 pela adição de 0x1111…1111; as etapas de início, comprovação e finalização de um saque OP Stack e o hash de saque que as vincula; por que os responsáveis pela finalização não são necessariamente os proprietários; IDs de cadeia, uso conjunto do ID de cadeia e do endereço como chave dos dados, e por que o mesmo endereço de contrato em duas cadeias não implica o mesmo proprietário.