Puentes: bloqueo y acuñación, quema y liberación, y puentes de liquidez

Los puentes son donde la mayoría de los rastros entre cadenas se consolidan o se desmoronan. Una transferencia a través de un puente bien documentada deja un identificador en ambas cadenas que vincula el depósito con el pago con tanta firmeza como una salida gastada vincula dos transacciones de Bitcoin; una transferencia mal documentada deja solo una conjetura basada en el importe y la hora. La tarea del examinador es encontrar el identificador, demostrar la coincidencia en ambos libros mayores, explicar todas las diferencias de importe y saber qué operador puede aportar lo que las cadenas no muestran.

Cuatro diseños y lo que cada uno deja en la cadena

Las lecciones de IDFE-BA Las capas 2, las cadenas laterales y los puentes como fuentes de datos, Rastreo entre cadenas y Préstamos, puentes y contabilidad de protocolos explican cómo funcionan los puentes. Para las pruebas, lo que importa es lo que aparece en cada lado y quién realiza el pago.

La mayoría de estos funcionan sobre una capa de mensajería que transporta un mensaje firmado de una cadena a otra. Wormhole identifica cada mensaje mediante la cadena de origen del emisor, la dirección del emisor y un número de secuencia; LayerZero asigna a cada paquete un punto de conexión de origen, un remitente y un nonce, además de un identificador global de 32 bytes (GUID). Las aplicaciones construidas sobre estas capas heredan sus identificadores, por lo que la primera tarea siempre es averiguar qué capa usa un puente.

El Cross-Chain Transfer Protocol (CCTP) de Circle para USDC es un ejemplo útil de quema y acuñación. El contrato de origen emite DepositForBurn con el importe, el depositante, el destinatario de la acuñación y el dominio de destino; el de destino emite MessageReceived con el dominio de origen y el nonce. En la versión actual del protocolo, el emisor asigna los nonces fuera de la cadena, y su servicio de atestación devuelve el nonce y la atestación correspondientes al hash de una transacción de origen. Por lo tanto, parte de la clave de enlace proviene del operador, no de la cadena: trate esa respuesta de la API como una prueba documental, con la hora de recuperación, la solicitud y un hash de la respuesta.

Los identificadores de cadena de los puentes no son IDs de cadena

Los puentes suelen usar su propia numeración. Wormhole usa sus propios IDs de cadena de 16 bits; CCTP usa dominios (Ethereum es el dominio 0, Arbitrum el dominio 3, Solana el dominio 5, Base el dominio 6), mientras que el ID de cadena EIP-155 de Arbitrum One es 42161. LayerZero usa IDs de punto de conexión. Un examinador que interprete destinationDomain = 3 como «cadena 3» buscará en la red equivocada. Registre la correspondencia que utilizó y de dónde proviene (la documentación del puente, con una versión fechada), del mismo modo que registra las fuentes de las etiquetas.

Vincular depósitos con liberaciones

Una coincidencia defendible sigue siempre los mismos pasos:

1. Decodifique el evento de origen a partir del recibo de la transacción de depósito, no del resumen de un explorador. Anote el contrato del puente, el contrato del token, el importe, el depositante, el destinatario, el identificador de destino y la clave de enlace.
2. Asigne la red de destino: convierta el identificador de cadena del puente en la red correspondiente y registre la correspondencia.
3. Encuentre el evento de destino que contenga la misma clave (y, en el caso de las capas de mensajería, el mismo emisor o remitente).
4. Compruebe el destinatario: el destinatario del evento de destino debe coincidir con el destinatario indicado en el evento de origen. Si difiere, averigüe por qué antes de continuar.
5. Reconcilie el importe: el importe de destino debe ser igual al importe de origen menos la comisión indicada en el evento o en las reglas de comisiones del puente; compruebe los decimales del token en ambos lados.
6. Compruebe el orden y el estado: la liberación debe producirse después del depósito; un depósito sin liberación puede estar pendiente, haber vencido o haberse reembolsado al depositante en la cadena de origen.
7. Repita la verificación de la coincidencia a partir de una segunda fuente de datos (su propio nodo, un segundo proveedor o la API pública del puente) y registre ambas fuentes.

Una coincidencia que supera las siete comprobaciones es un vínculo de flujo de grado A según la escala de la lección Rastreo hasta un estándar probatorio. Si no supera la comprobación del destinatario o del importe, no constituye una coincidencia hasta que se explique la diferencia.

En los puentes de relayer, un pago puede llegar segundos después del depósito, antes de que el bloque de origen alcance la finalidad. Si más tarde se reorganizara y eliminara el bloque de origen, normalmente el relayer, no el depositante, asumiría la pérdida, pero sus pruebas señalarían una transacción que ya no existe. Registre el hash del bloque de origen y su estado de finalidad en el momento del análisis (consulte la lección Preservación de pruebas en cadena).

Cuando ambos lados están en un almacén de datos, la coincidencia se obtiene mediante una unión por la clave de enlace, no mediante una búsqueda por importe:

-- Vincular los depósitos de puentes de relayer con los pagos de destino mediante la cadena de origen y el ID de depósito
SELECT d.txid AS deposit_tx, d.block_time AS deposit_time, d.input_amount,
       f.txid AS fill_tx,    f.block_time AS fill_time,    f.output_amount,
       d.input_amount - f.output_amount       AS fee_taken,
       (d.recipient = f.recipient)            AS recipient_matches,
       f.relayer
FROM bridge_deposits d
LEFT JOIN bridge_fills f
  ON  f.origin_chain_id = d.origin_chain_id
  AND f.deposit_id      = d.deposit_id
WHERE d.depositor = '0x3f9c…a1d7'                 -- dirección del sujeto
  AND d.origin_chain_id = 1;

LEFT JOIN conserva los depósitos sin pago, que son precisamente los que deben revisarse para comprobar si hubo reembolsos o vencimientos. La consulta informa la comisión implícita en los dos importes y si coincide el destinatario; también identifica al relayer para que nadie lo confunda con el sujeto. Ambas tablas deben contener importes ya convertidos a las mismas unidades; si los tokens de entrada y salida son distintos, conviértalos usando una tasa registrada antes de compararlos.

Errores que debilitan un vínculo de puente

• Los relayers, ejecutores y finalizadores no son propietarios. La dirección que envía la liberación o paga el importe suele pertenecer a un servicio. En los puentes de liquidez, el pago proviene de la dirección del relayer, por lo que un rastreo ingenuo «salta» a los fondos de una parte no relacionada.
• El destinatario no es el depositante. Muchos puentes permiten que el depositante indique cualquier destinatario. El campo del destinatario en el evento de origen es la prueba; no dé por sentado que se utiliza la misma dirección en la cadena de destino.
• Los agregadores se ubican delante de los puentes. Cuando una ruta pasa por un contrato agregador, el evento del puente puede mostrar al agregador como depositante. Siga el rastreo para averiguar quién lo llamó.
• La misma dirección no significa el mismo propietario. Una cuenta de propiedad externa tiene la misma dirección en todas las cadenas EVM, pero una dirección de contrato puede contener código distinto o no contener nada en otra cadena (consulte la lección de IDFE-BA Las capas 2, las cadenas laterales y los puentes como fuentes de datos).
• Los tokens se identifican por contrato, no por símbolo. En una cadena pueden coexistir varias versiones puenteadas de un mismo activo, y los tokens envueltos no siempre conservan la cantidad de decimales del original.

Los operadores de puentes como fuentes de información

Las cadenas muestran la transferencia; los operadores pueden mostrar a la persona. Según el diseño y las políticas, un operador del puente o el operador de su interfaz puede conservar registros web y de API de solicitudes de cotización y transacción (direcciones IP, agentes de usuario, marcas de tiempo y direcciones de billeteras conectadas), registros de pagos de relayer, registros de atestación, solicitudes de soporte y registros de análisis. Los emisores de tokens que operan detrás de puentes de quema y acuñación conservan sus propios registros de mensajes y pueden congelar tokens (consulte la lección Opciones de congelamiento y incautación). Los puentes totalmente descentralizados quizá no tengan ningún operador; en ese caso, los datos públicos constituyen todo el registro, y la solicitud se dirige a la interfaz que utilizó el sujeto, si es posible identificarla.

Una solicitud precisa indica la cadena, el hash de la transacción de depósito, las direcciones del depositante y del destinatario, el intervalo UTC y los campos solicitados, y pide primero que se conserven los datos (consulte la lección Colaboración con proveedores de servicios).

Los exploits de puentes como contexto

Los exploits invierten el problema habitual: aparecen fondos en un lado sin que haya un depósito legítimo en el otro, por lo que el rastreo comienza desde la liberación o la acuñación.

Enfoque del examen: puentes de bloqueo y acuñación, quema y liberación, quema y acuñación del emisor, y puentes de relayer, así como lo que cada uno deja en las cadenas de origen y destino; identificadores de capas de mensajería (cadena, dirección y secuencia del emisor de Wormhole; nonce y GUID de LayerZero; nonce y dominio de origen de CCTP, con el nonce asignado por el emisor); correspondencia entre los identificadores de cadena de los puentes y las redes, y registro de esa correspondencia; los siete pasos de la vinculación (decodificar, asignar, encontrar, destinatario, importe, orden y estado, repetir la verificación); reembolsos y depósitos sin pago; relayers y agregadores como partes que no son propietarias; qué información pueden conservar los operadores de puentes y las interfaces; Wormhole, Ronin y Nomad como contexto para el rastreo de liberaciones y la reconciliación.