Pontes, camadas 2, sidechains e outros modelos de blockchain

Os rastros raramente permanecem na rede principal do Bitcoin ou do Ethereum. Fundos roubados são transferidos por pontes para rollups e sidechains, movimentados como stablecoins na Tron, encaminhados por programas da Solana ou transportados entre blockchains Cosmos. Cada travessia é um ponto em que o rastro se fortalece ou se desfaz. Uma travessia bem documentada deixa um identificador em ambos os registros que vincula o depósito ao pagamento com a mesma firmeza com que uma saída gasta vincula duas transações Bitcoin; uma mal documentada deixa uma suposição baseada em valor e horário. O perito deve encontrar esse identificador, comprovar a correspondência nas duas blockchains, explicar cada diferença de valor, saber onde cada blockchain mantém seus dados e quem poderia reescrevê-los, e saber qual operador detém aquilo que as blockchains não mostram. A Aula 5.3 aborda padrões de movimentação entre blockchains e correspondência por valor e horário; esta aula aborda os mecanismos e as evidências que cada um deixa.

Modelos de pontes e suas chaves de vinculação

Entre os lados há uma camada de verificação: um conjunto de validadores, um cliente leve, uma janela de contestação otimista ou uma prova de conhecimento zero. As pontes para sidechains geralmente têm suas operações assinadas por um pequeno conjunto de validadores, de modo que um vínculo "determinístico" nelas só se sustenta dentro da confiança depositada nesses validadores; o laudo deve declarar isso.

A maioria das pontes opera sobre uma camada de mensagens. A Wormhole identifica cada mensagem pela blockchain emissora, pelo endereço emissor e pela sequência; a LayerZero atribui a cada pacote um endpoint de origem, remetente e nonce, além de um identificador global de 32 bytes (GUID). As aplicações herdam esses identificadores, portanto primeiro determine qual camada a ponte usa. O Cross-Chain Transfer Protocol (CCTP) da Circle para USDC usa queima e emissão: a origem emite DepositForBurn (valor, depositante, destinatário da emissão, domínio de destino), e o destino emite MessageReceived (domínio de origem, nonce). Na versão atual, o emissor atribui nonces fora da blockchain e seu serviço de atestação os retorna para um hash de transação de origem. Parte da chave, portanto, vem do operador: trate essa resposta da API como uma peça de evidência, com a requisição, o horário de obtenção e um hash da resposta.

As pontes também numeram as blockchains à sua própria maneira: a Wormhole tem seus próprios IDs de blockchain de 16 bits, a LayerZero tem IDs de endpoint e o CCTP tem domínios (Ethereum 0, Arbitrum 3, Solana 5, Base 6), enquanto o ID de blockchain EIP-155 da Arbitrum One é 42161. Interpretar destinationDomain = 3 como "blockchain 3" leva você à rede errada. Registre cada mapeamento e sua fonte, a documentação da ponte em uma versão datada.

Correspondência entre um depósito e sua liberação

Uma correspondência defensável passa por sete verificações:

1. Decodifique o evento de origem a partir do recibo, não de um resumo do explorador: contratos, valor, depositante, destinatário, identificador de destino, chave de vinculação.
2. Mapeie o identificador de destino para uma rede e registre o mapeamento.
3. Encontre o evento de destino com a mesma chave (e, nas camadas de mensagens, o mesmo emissor ou remetente).
4. Confira o destinatário em relação ao registrado no evento de origem; explique qualquer diferença antes de prosseguir.
5. Reconcilie o valor: o destino é igual à origem menos a taxa informada, com as casas decimais verificadas em ambos os lados, pois tokens encapsulados nem sempre mantêm as casas decimais do original.
6. Confira a ordem e o status: liberação após o depósito; um depósito sem liberação pode estar pendente, expirado ou reembolsado.
7. Refaça a correspondência usando uma segunda fonte de dados e registre ambas.

Passar pelas sete verificações resulta em um vínculo de fluxo de grau A na escala da Aula 3.2; falhar na verificação do destinatário ou do valor significa que não há correspondência até que isso seja explicado. Em um data warehouse, a correspondência é um LEFT JOIN de depósitos com execuções pelo ID da blockchain de origem e pelo ID do depósito, não uma busca por valor: isso mantém os depósitos não executados para a verificação de reembolso, calcula a taxa implícita e identifica o retransmissor para que ninguém o confunda com o investigado. As execuções dos retransmissores podem ocorrer segundos após o depósito, antes da finalização da blockchain de origem; se o bloco de origem fosse removido por uma reorganização, o retransmissor geralmente arcaria com a perda, mas sua evidência citaria uma transação que não existe mais. Registre o hash do bloco de origem e seu status de finalização (Aula 8.2).

Armadilhas que enfraquecem um vínculo:

• Retransmissores, executores e finalizadores não são proprietários. Um rastreamento ingênuo por uma ponte de liquidez passa a seguir os fundos de uma parte não relacionada.
• O destinatário não é o depositante. O campo de destinatário do evento de origem é a evidência.
• Agregadores podem aparecer como depositantes; leia o rastro de execução para descobrir quem os chamou.
• Mesmo endereço, proprietário diferente. Uma conta de propriedade externa (EOA) tem o mesmo endereço em todas as blockchains EVM, mas um endereço de contrato pode conter código diferente, ou nenhum código, em outra rede. Em junho de 2022, cerca de 20 milhões de tokens OP foram enviados para um endereço na Optimism em que a carteira de múltiplas assinaturas pretendida existia apenas no Ethereum; um atacante implantou outra carteira de múltiplas assinaturas ali e os tomou.
• Tokens pelo contrato, não pelo símbolo: várias versões de um ativo transferidas por pontes podem coexistir.

Reconciliação entre custódia e oferta

A invariante de uma ponte de bloqueio e emissão: a oferta de tokens encapsulados no destino nunca excede o colateral em custódia na origem, exceto por depósitos em trânsito. Compare o balanceOf da custódia com o totalSupply() do token encapsulado em momentos correspondentes, ou mantenha totais acumulados diários das unidades líquidas bloqueadas e emitidas. Uma pequena diferença positiva é normal; uma diferença negativa significa tokens sem lastro. Explorações de vulnerabilidades invertem o rastreamento: fundos aparecem sem um depósito legítimo, portanto comece pela emissão ou liberação (as causas fundamentais estão na Aula 5.5).

Os seis dias da Ronin reforçam a necessidade de monitoramento contínuo. Protocolos de empréstimo precisam da mesma verificação (tokens de oferta contra os ativos subjacentes mantidos mais a dívida), e seus eventos separam quem agiu de quem teve sua posição alterada: um roteador aparece como user, e o proprietário como onBehalfOf. Saldos que rendem juros, como aTokens, crescem sem eventos Transfer, portanto leia-os a partir do estado. O principal de um empréstimo instantâneo entra e sai em uma única transação e deve ser descontado de qualquer perda (Aula 5.5).

Operadores como fontes. A blockchain mostra a transferência; os operadores podem mostrar a pessoa. Um operador de ponte ou uma interface web pode manter logs de API e da web (endereços IP, agentes de usuário, carteiras conectadas), execuções de retransmissores, atestações, chamados de suporte e logs de triagem; emissores por trás de pontes de queima e emissão também podem congelar fundos (Aula 10.1). Uma ponte totalmente descentralizada pode não ter operador, portanto solicite os dados à interface web que o investigado usou. Informe a blockchain, o hash do depósito, o depositante, o destinatário, o intervalo em UTC e os campos, e peça primeiro a preservação (Aula 1.4).

Rollups e sidechains

O histórico de um rollup pode, em princípio, ser reconstruído a partir da L1; o de uma sidechain é tão confiável quanto seus validadores. Para uma sidechain, registre as regras de consenso e finalização, o conjunto de validadores, se publicado, e se você usou o único explorador dela ou seu próprio nó.

Sequenciadores e finalização em camadas. A maioria dos rollups tem um sequenciador que ordena transações, define timestamps da L2 dentro dos limites do protocolo e publica lotes na L1. Os nós OP Stack expõem pontas unsafe (apenas do sequenciador, sujeitas a reorganização), safe (derivadas de dados da L1) e finalized; construa evidências a partir de blocos seguros ou finalizados e registre a transação de ancoragem na L1. Desde a atualização Dencun (13 de março de 2024), a maioria dos rollups publica blobs, que os nós da L1 descartam após 4.096 épocas, cerca de 18 dias, deixando um hash versionado. Para demonstrar que o histórico da L2 pode ser reconstruído de forma independente, preserve os dados dos blobs dentro dessa janela ou identifique o arquivo histórico utilizado. Operadores de sequenciadores e provedores públicos de RPC podem registrar metadados de envio e receber solicitações precisas.

Depósitos. Nas blockchains OP Stack, o OptimismPortal da L1 emite TransactionDeposited e a L2 cria uma transação de depósito não assinada do tipo 0x7E (126 como inteiro), cujo sourceHash, calculado a partir do hash do bloco da L1 e do índice do log, é uma chave de junção exata; seu campo mint é o ETH criado na L2, espelhado por ETH bloqueado na L1. Sem assinatura, a autoridade e a atribuição vêm do remetente na L1. Na Arbitrum, um ticket de nova tentativa cuja execução automática falha aguarda até uma semana, de modo que o efeito na L2 pode demorar dias. Ambas as famílias criam aliases para contratos da L1 somando 0x1111000000000000000000000000000000001111: o contrato 0x5d3a…7c10 da L1 chega à L2 como 0x6e4b…8d21. EOAs não recebem aliases; procure pelo alias.

Saques. Um saque canônico do OP Stack tem três etapas vinculadas por um hash de saque: iniciar na L2 (MessagePassed), comprovar na L1 (WithdrawalProven), finalizar após a janela de contestação (WithdrawalFinalized). A Arbitrum não tem etapa de comprovação (sendTxToL1, depois execução no Outbox cerca de uma semana mais tarde). Assim que a iniciação fica visível, o destinatário na L1 e o horário mais cedo de chegada são conhecidos com dias de antecedência, de modo que uma exchange pode ser alertada antes de os fundos chegarem (Aula 10.1). Comprovadores e finalizadores frequentemente são retransmissores, e as janelas diferem por blockchain e mudam, portanto registre o parâmetro em vigor. Por isso, os infratores geralmente saem por pontes de liquidez.

Use ID da blockchain e endereço como chave de cada tabela: Ethereum 1, OP Mainnet 10, BNB Smart Chain 56, Polygon PoS 137, zkSync Era 324, Base 8453, Arbitrum One 42161, Linea 59144, Scroll 534352.

Outros modelos de blockchain

A Tron é compatível com EVM (o TRC-20 emite o evento Transfer do ERC-20), movimenta uma grande parcela do USDT e produz blocos aproximadamente a cada três segundos. Endereços T… codificam um byte 0x41 mais um corpo de 20 bytes; converta-os para hexadecimal para fazer a junção com dados EVM, mantendo o identificador da blockchain em cada linha. As taxas usam largura de banda e energia, que podem ser delegadas ou alugadas, portanto a conta pagadora pode ser um serviço de aluguel. Um novo endereço geralmente é ativado ao receber TRX pela primeira vez, e o ativador é uma pista. O emissor do USDT pode congelar um endereço (AddedBlackList) e queimar seu saldo (DestroyedBlackFunds); verifique ambos antes de considerar os fundos disponíveis.

A Solana mantém tudo em contas (1 SOL = 1.000.000.000 lamports). Os programas não mantêm estado; uma conta de emissão define um token e os saldos ficam em contas de tokens, normalmente na conta de tokens associada derivada do proprietário, do programa de tokens e da conta de emissão. Os tokens se movem entre contas de tokens, portanto mapeie cada uma para seu proprietário no momento da transferência. Registre a primeira assinatura (o ID da transação), o slot e o blockTime estimado. Comparar preTokenBalances e postTokenBalances é mais eficaz do que decodificar instruções internas: uma conta que cai de 900.000.000 para 650.000.000 unidades básicas com 6 casas decimais enviou 250 tokens. Muitos nós mantêm apenas o histórico recente; identifique a fonte de arquivo histórico.

A Cardano estende o UTXO (eUTXO): as saídas contêm ADA e tokens nativos; saídas de script contêm um datum e são gastas com um redeemer. Endereços de pagamento que compartilham uma credencial de delegação pertencem, na maioria dos casos, a uma única carteira, um forte sinal de agrupamento, mas não uma prova.

As blockchains Cosmos usam endereços Bech32 com prefixos (cosmos1…, osmo1…), e uma chave frequentemente gera endereços correspondentes entre blockchains. O IBC mantém o ativo em custódia na origem e emite um comprovante denominado ibc/ mais um hash SHA-256 do caminho e da denominação base; a porta, o canal e a sequência do pacote aparecem em send_packet, em recv_packet e em acknowledge_packet, formando uma chave de junção exata. Um ativo que chega por dois caminhos tem duas denominações diferentes.

O Monero e o Zcash blindado ocultam as partes e os valores; a análise se concentra nos pontos de entrada e saída (Aula 6.4).

Blockchains sem suporte. Quando suas ferramentas não conseguem decodificar uma blockchain: leia sua documentação em uma versão datada; obtenha dados de duas fontes, salvando as respostas brutas e calculando seus hashes (Aula 8.3); valide com base em algo conhecido, como um depósito cujos registros da exchange você possui; relate apenas campos validados; apoie-se nas pontes e exchanges nas extremidades; e declare todas as limitações (Aula 3.6).

Foco no exame: os quatro modelos de pontes e o que cada um deixa em ambas as blockchains; identificadores da Wormhole, LayerZero e CCTP, nonces do CCTP atribuídos pelo emissor e mapeamento de identificadores de pontes, como domínios do CCTP, para redes; a correspondência em sete etapas; retransmissores, agregadores e finalizadores como não proprietários; a invariante de que a oferta de tokens encapsulados nunca excede a custódia e como Wormhole, Ronin e Nomad aparecem nela; endereço que atua versus onBehalfOf; rollups otimistas e ZK versus sidechains; pontas unsafe, safe e finalized e descarte de blobs após cerca de 18 dias; sourceHash, tickets de nova tentativa e criação de aliases; o saque em três etapas como tempo para alerta; uso de ID da blockchain mais endereço como chave; recursos da Tron, ativação e congelamentos de USDT; contas de tokens da Solana e diferenças de saldo; credenciais de delegação da Cardano; chaves de pacotes IBC.