Ir para o conteúdo
Financial Context Wiki

Como realizar uma transferência entre blockchains com segurança

Procedimento em nível de conta para verificar rota, cotação, autorização, teste, estado da mensagem, nova tentativa ou reembolso, token recebido e resultado econômico de uma transferência entre blockchains.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Uma transferência segura entre blockchains é uma trilha de evidências, não uma única confirmação da carteira. Primeiro defina o ativo exato e o estado final utilizável; verifique a rota e a cotação executável; conceda apenas a autoridade necessária; conclua um teste limitado; envie uma vez; acompanhe separadamente os estados de origem, mensagem e destino; depois concilie o contrato exato recebido, as permissões e o resultado econômico.

A arquitetura do protocolo pertence à análise da ponte. Este checklist transforma a documentação atual de uma rota escolhida em um procedimento no nível da conta. Um débito em exchange custodial seguido de saque em outra rede é outro fluxo de contraparte, não necessariamente uma ponte on-chain. Nenhuma rota, teste pequeno ou designação oficial elimina o risco.

Checklist de transferência entre blockchains
0 / 5
0 itens revisados; 5 itens ainda não resolvidos

A conclusão desta revisão não prova que um ativo, transação ou sistema seja seguro.

Como funciona

  1. Defina a autorização e o estado final utilizável. Registre ativo de origem, ativo e protocolo de destino desejados, destinatário, valor, perda máxima, espera máxima e se o token final deve ser resgatável, negociável ou aceito como garantia. Não comece apenas pelo ticker.
  2. Fixe o snapshot da rota com fontes oficiais independentes: protocolo e versão, chainId ou domínio de origem e destino, gateway, router, mensageiro, proxy, spender, par de tokens, formato do destinatário, decimais, valor bruto, bloco e timestamp. Verifique novamente a chain e conta ativas da carteira após qualquer evento chainChanged do provedor.
  3. Revise as regras de confiança e recuperação específicas da direção. Registre finalidade exigida na origem, verificador ou atestador, controles de administração e upgrade, pausas e limites de taxa, executor no destino, unicidade da mensagem e caminhos de nova tentativa, reivindicação, timeout e reembolso. Vincule isso à arquitetura da ponte, sem inferir segurança pelo nome.
  4. Construa uma cotação executável e um registro de financiamento. Separe principal e taxas de protocolo ou LP denominadas em tokens do gas nativo na origem e no destino, slippage, impacto no preço e custo de espera. Registre timestamp, validade, capacidade, saída mínima e prazo da cotação e confirme que o token recebido serve à próxima etapa pretendida.
  5. Limite a autoridade e execute um teste restrito. Verifique o spender ERC-20 exato e a allowance, permit ou escopo de operador atual; mantenha gas nas duas chains; revise valor e calldata; e teste a mesma rota e destinatário com limite absoluto de perda predefinido. Um teste pequeno bem-sucedido não comprova capacidade para valores grandes nem segurança futura.
  6. Antes da transferência integral, atualize chain, conta, contratos, saldos, nonce, cotação, allowance, estado de pausa e limites. Envie a ação de origem uma vez e guarde recibo, ID ou nonce da mensagem, referência da prova ou atestação e transação de destino. Trate assinado, enviado, incluído, finalizado, pronto, retransmitido, executado, confirmado, falho, expirado e reembolsável como estados distintos.
  7. Diagnostique por estado e concilie o resultado. Repita somente uma etapa idempotente documentada no destino após provar que ação e mensagem de origem existem, que o destinatário não recebeu crédito e que a mensagem não foi consumida; nunca repita cegamente depósito ou queima. Confirme token exato, saldo efetivo e saída no destino, todas as taxas, allowance restante e reivindicações pendentes ou reembolsadas; depois revogue a autoridade excedente e arquive as evidências.

Exemplos resolvidos

  • Controle de identidade em unidades brutas. Uma transferência de 2,500.000000 USDC de um token verificado com 6 decimals codifica 2,500 * 10^6 = 2,500,000,000 raw units. Usar 18 decimals codificaria 2,500,000,000,000,000,000,000, ou 10^12 vezes o valor bruto pretendido. Token e spender de origem, token de destino e endereços do destinatário devem ser verificados antes da assinatura.
  • Registro de saída e custo econômico. O principal é 12,000 units; a taxa do protocolo é 18 units; e a taxa do LP é 24 units, então a saída de tokens no destino é 12,000 - 18 - 24 = 11,958 units. O gas na origem é 0.004 ETH e no destino 0.0015 ETH; a 2,500 USD/ETH, custam $10 e $3.75. Se uma unidade vale $1, o custo econômico total é $18 + $24 + $10 + $3.75 = $55.75 e a riqueza líquida recebida é $11,944.25, enquanto o saldo de tokens continua 11,958 units.
  • Lotes sequenciais alteram apenas a exposição limitada. Transferir 12,000 units de uma vez expõe 12,000 units na operação atual e gera custo fixo hipotético de gas de $9. Três lotes sequenciais de 4,000-unit, conciliados antes do próximo, limitam o principal atual em trânsito a 4,000 units, mas custam 3 * $9 = $27, ou $18 a mais. Representações já recebidas permanecem expostas até serem resgatadas ou vendidas.
  • Nova tentativa no destino específica do produto. Em um exemplo de CCTP, o usuário queima 2,500 USDC sob o nonce de mensagem 41; a atestação termina, mas a primeira emissão no destino reverte após gastar 0.0024 ETH. A 2,500 USD/ETH, isso custa $6. Após confirmar ausência de crédito ao destinatário e nonce não usado, o usuário financia 0.002 ETH e segue a nova tentativa documentada de emissão do CCTP, acrescentando $5; uma única emissão credita 2,500 USDC e o gas total no destino é $11. Esse limite idempotente não deve ser generalizado para outras pontes.

Riscos

  • Selecionar origem, destino, chainId ou domínio incorretos.
  • Usar rota, implantação ou versão de protocolo erradas.
  • Seguir interface, documentação ou conta de suporte de phishing.
  • Aprovar gateway, router, mensageiro, proxy ou spender falsificado.
  • Aceitar mapeamento de tokens ou representação de mesmo símbolo incorretos.
  • Enviar ao destinatário, formato de endereço, memo ou conta de destino errados.
  • Interpretar incorretamente decimais ou unidades brutas.
  • Conceder approval, permit ou autoridade de operador excessivos.
  • Assinar calldata maliciosa ou valor nativo não pretendido.
  • Usar cotação obsoleta, omitir saída mínima ou ultrapassar o prazo.
  • Exceder capacidade, limites de taxa ou slippage aceitável da rota.
  • Não financiar suficientemente o gas na origem.
  • Não financiar suficientemente gas de reivindicação, nova tentativa ou reembolso no destino.
  • Confiar em finalidade insuficiente na origem ou bloco reorganizado.
  • Aguardar prova, atestação, relayer ou executor atrasado.
  • Encontrar reversão no destino ou conta ou hook de token incompatível.
  • Repetir cegamente depósito, queima ou mensagem já consumida.
  • Ignorar pausa, upgrade, troca de administrador ou mudança de configuração.
  • Receber token ilíquido, sem paridade, não resgatável ou incompatível.
  • Tratar mal privacidade, suporte falso, tributação, sanções, custódia ou evidências de recuperação.

Equívocos comuns

  • Uma transação de origem bem-sucedida significa que a transferência terminou.
  • Tokens com o mesmo ticker são o mesmo ativo e direito.
  • Um teste pequeno bem-sucedido prova que uma transferência grande ou futura é segura e líquida.
  • Canônica, oficial, rápida ou auditada significa risco zero.
  • Uma transferência travada deve ser resolvida repetindo o depósito ou contatando um administrador de grupo.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...