Saltar al contenido
Financial Context Wiki

Puente canónico

Una guía de verificación de puentes designados por el protocolo, respaldo de activos, estados de mensajes entre dominios, retiros optimistas y con pruebas de validez, controles de actualización, comisiones y comparación con puentes rápidos.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Un puente canónico es la ruta de activos o mensajes designada por un rollup o ecosistema de cadena concreto. Suele conectar contratos que bloquean en escrow o queman un activo en una cadena, transmiten un mensaje reconocido por el protocolo y acuñan, desbloquean o liberan el activo correspondiente en la otra. La palabra canónico es una etiqueta del ecosistema, no una norma universal, garantía criptográfica ni prueba de autenticidad de un sitio y una dirección.

Su seguridad no es una fórmula aditiva. Depende conjuntamente de la finalidad de la cadena de origen, disponibilidad de datos, verificación de estados o mensajes, contabilidad del puente, ejecución en destino, protección contra replay, poderes de actualización y pausa, y una vía de salida utilizable. Un puente rápido puede pagar antes al usuario con liquidez y liquidar después por la ruta canónica, pero esto añade supuestos sobre proveedor de liquidez, solver, verificador y ejecución, en vez de acelerar gratis la misma máquina de estados.

1
Bloquear o quemar

El contrato de la cadena de origen custodia o destruye la representación de origen.

Cómo funciona

  1. Fija la instantánea de la ruta: chainId de origen y destino, dirección, stack y versión del rollup, direcciones de bridge, portal, messenger, inbox o gateway, direcciones de tokens, destinatario, importe, referencias de bloque y documentación oficial. Nunca dependas solo de un resultado de búsqueda o de la etiqueta oficial.
  2. Resuelve el modelo de seguridad y control. Registra reglas de fault proof optimista o validity proof, modo de disponibilidad de datos, sequencer y ruta forzada, implementación del proxy, administrador o consejo de seguridad, timelock, estado de pausa, límites de tasa y retraso de actualización. Canónico no significa inmutable.
  3. Clasifica el registro del activo. Distingue valor nativo de tokens ERC-20 e identifica el mecanismo lock-and-mint, burn-and-release o burn-and-mint. Verifica el par registrado de tokens, unidades brutas, decimales, gateway personalizado y compatibilidad con activos fee-on-transfer, rebasing o sujetos a listas de bloqueo.
  4. Construye la máquina de estados de mensajes específica de la dirección. Un depósito puede pasar por aprobación, escrow o quema en origen, finalidad de origen, derivación o relay y acuñación o desbloqueo en destino. Un retiro puede exigir quema o escrow en destino, inclusión del mensaje, compromiso de estado, prueba, impugnación o aceptación de la prueba, finalización y liberación en origen.
  5. Sigue por separado tres relojes: inclusión de la transacción, liquidación del protocolo o finalidad del estado, y disponibilidad del activo para usarlo o retirarlo. Registra hash de la transacción de origen, hash del mensaje o retiro, referencia de output o prueba y cada transacción de relay, prove, finalize, claim, retry o refund.
  6. Construye el registro económico. Separa principal transferido, gas en origen y destino, gas de prueba o finalización, comisión del protocolo o relayer, comisión del proveedor de liquidez, slippage y coste de oportunidad de la espera. Compara un puente rápido con la ruta canónica como derechos y modelos de confianza diferentes.
  7. Concilia la ruta terminada con recibos, eventos, saldos en escrow, oferta de la representación, derechos pendientes, saldos del destinatario y allowances restantes. Espera la finalidad exigida, conserva gas de emergencia, prueba las rutas permissionless o forzadas cuando proceda y detente en vez de repetir un depósito cuyo estado de mensaje no puedas explicar.

Ejemplos desarrollados

  • Registro de depósito de activo nativo. Un usuario empieza con 5.0000 ETH, deposita 2.5000 ETH y paga 0.0042 ETH de gas en origen. La wallet de origen termina con 5.0000 - 2.5000 - 0.0042 = 2.4958 ETH; el escrow aumenta en 2.5000 ETH; y, tras un relay correcto uno a uno, la representación en destino aumenta en 2.5000 ETH. La razón de respaldo es 2.5000 / 2.5000 = 100%. El escrow y la representación son respaldo y derecho, no 5 ETH de nuevo valor económico.
  • Unidades brutas y mapeo del token. Un usuario deposita 1,250.000000 USDC. El contrato de origen verificado usa 6 decimals, por lo que el importe bruto es 1,250 * 10^6 = 1,250,000,000. Con un mapeo verificado uno a uno y sin comisión del token, el escrow de origen y la acuñación en destino varían cada uno en 1,250,000,000 raw units, que se muestran como 1,250.000000 USDC remotamente. Un token con el mismo símbolo en otra dirección no es evidencia intercambiable.
  • Los relojes de retiro son distintos. Supón que un deployment registra un retiro en 2026-08-01 12:00:00 UTC y aplica un periodo de impugnación de 604,800-second = 7-day desde ese inicio definido por el protocolo. El umbral temporal es 2026-08-08 12:00:00 UTC; una transacción de prove o finalize, el gas y la política elegida de confirmación de la cadena de origen pueden añadir más tiempo. Este ejemplo parametrizado no afirma que todos los puentes esperen siete días, y la finalidad de la transacción de destino no libera por sí sola los fondos de origen.
  • Cotización de ruta rápida frente al coste de espera. Para 10,000 USDC, un puente rápido cobra 0.08% más 3 USDC, sin contar gas ni slippage. El coste es 10,000 * 0.0008 + 3 = 11 USDC y los ingresos inmediatos son 9,989 USDC. Frente a una espera canónica hipotética de 7-day, el precio anualizado simple del acceso anticipado es (11 / 9,989) * (365 / 7) = 5.7420305193%. La comparación no es una rentabilidad ni una tasa libre de riesgo y excluye riesgos de solver, liquidez, impago y liquidación.

Riesgos

  • Usar una interfaz de phishing o un dominio de documentación sin verificar.
  • Seleccionar la cadena de origen o destino y el chainId incorrectos.
  • Enviar a un bridge, portal, messenger, gateway o destinatario falsificados.
  • Aceptar un token con el mismo símbolo pero con un mapeo de contraparte registrado distinto.
  • Interpretar mal decimales, unidades brutas o comportamiento no estándar del token al transferir.
  • Confundir activos nativos, tokens de gas envueltos y representaciones transferidas por puente.
  • Exponer una allowance excesiva o aprobar al spender incorrecto.
  • No detectar una actualización de proxy, compromiso del administrador, actuación del consejo de seguridad o cambio del timelock.
  • Encontrar una pausa, denylist, límite de tasa o ruta de retiro congelada.
  • Tratar un recibo de origen como prueba de ejecución correcta en destino.
  • No financiar suficientemente el gas de ejecución, retry, prove, claim o refund en destino.
  • Perder un mensaje por caducidad del retry, gestión incorrecta del refund o aliasing de direcciones.
  • Ignorar una reorganización de la cadena de origen o una finalidad insuficiente.
  • Depender de un sequencer que censura o no está disponible sin una ruta forzada operativa.
  • Perder la disponibilidad de datos necesaria para probar, reconstruir o abandonar el estado.
  • Aceptar una raíz de estado, prueba de mensaje, nullifier o condición de replay inválidos.
  • Depender de proposers, provers, challengers o finalizers permissioned que no están disponibles.
  • Interpretar mal un parámetro de impugnación, vencimiento o aceptación de prueba tras una actualización.
  • Sufrir insolvencia del escrow, desviación contable, depeg del token o iliquidez en destino.
  • Añadir riesgos de puente rápido, agregador, verificador, LP, solver, slippage, impuestos y sanciones.

Errores comunes

  • Canónico es una norma universal y significa automáticamente trustless o libre de riesgo.
  • Una transacción correcta en origen o un saldo mostrado en la UI demuestran liquidación definitiva.
  • Todos los retiros de rollups tienen el mismo periodo de espera de siete días.
  • El escrow de origen y las representaciones de destino pueden sumarse como TVL independiente.
  • Un puente rápido es simplemente el mismo puente canónico con un ajuste de velocidad.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...