Bridges: mover valor entre cadenas sin cerrar los ojos

Un cliente deposita en tu plataforma 1.000 unidades de un token que en otra red se llama "ETH". En el explorador aparece un contrato ERC-20 con ese símbolo y buena liquidez. ¿Qué tienes en custodia? No tienes ether de mainnet. Tienes un pasivo emitido por un contrato en otra red, cuyo valor depende de que alguien, en algún lugar, mantenga bloqueado el ETH original y de que nadie pueda emitir más representaciones que las bloqueadas.

Eso es un bridge (puente): un sistema que permite que un evento en una cadena produzca un efecto en otra. Las cadenas no se comunican de forma nativa; cada una tiene sus reglas y su consenso. El bridge agrega un tercer componente que observa una cadena y actúa en la otra. ethereum.org lo resume en una frase: hay que entender qué compromisos hace cada bridge antes de usarlo. [1]

Preguntas guía

• Si el verificador miente, ¿qué puede emitir o liberar?
• ¿Qué impide que el mismo mensaje se procese dos veces?
• ¿Cuánto tarda un retiro y qué lo puede detener?
• ¿Qué parte del riesgo de un token puenteado aparece en su precio y cuál no?

Tres maneras de "mover" un activo, sin moverlo

Ningún token viaja de una cadena a otra. Lo que ocurre es un cambio de estado coordinado en dos libros contables. La documentación para desarrolladores de ethereum.org distingue tres mecanismos: [2]

1. Lock and mint. Se bloquea el activo en un contrato de la cadena de origen y se emite (mint) una representación en la de destino. Para volver, se quema la representación y se libera lo bloqueado.
2. Burn and mint. Se quema el activo en origen y se emite en destino. Lo usa un emisor que controla el token en ambas cadenas.
3. Atomic swaps. Se intercambia el activo de origen por otro que ya existe en destino con una contraparte que tiene liquidez allí.

Los dos primeros crean un pasivo: el token de destino vale porque promete algo en origen. El tercero no emite nada nuevo, pero depende de que existan proveedores de liquidez dispuestos a hacer el intercambio. La misma página clasifica los bridges en nativos (los que construye una red para atraer liquidez, como el de un rollup), basados en validadores u oráculos, de mensajería generalizada y redes de liquidez.

El verificador es el modelo de amenaza

En lock and mint, el contrato de destino emite cuando recibe un mensaje que dice "se bloquearon 1.000 en origen". La pregunta central de seguridad es: ¿quién puede producir un mensaje que el destino acepte? Esa entidad es el verificador, y su diseño define el riesgo.

ethereum.org separa dos familias. Los bridges confiables dependen de un conjunto externo de verificadores: federaciones con multisig, sistemas de cómputo multiparte (MPC) o redes de oráculos. Suelen ser rápidos, baratos y conectar muchas redes, pero el usuario confía en ese conjunto. Los bridges sin confianza adicional se apoyan en las propias cadenas y sus validadores, sin sumar supuestos nuevos. [2]

Entre los segundos hay variantes con costos distintos. Un bridge de light client verifica en destino los encabezados y el consenso de origen, lo que suele limitar cuántas redes conecta. Un bridge optimista acepta mensajes salvo que alguien demuestre fraude en una ventana de tiempo, lo que agrega latencia. Un bridge con pruebas de validez verifica una prueba criptográfica de que la transición ocurrió.

Ethereum ayuda desde la actualización Dencun, activada el 13 de marzo de 2024, con EIP-4788: [3] cada bloque de ejecución compromete la raíz del bloque de la beacon chain y un contrato del sistema la guarda en un buffer de 8.191 entradas. Los autores citan explícitamente los bridges entre los usos: con esas raíces, un contrato puede verificar pruebas sobre el estado de consenso sin depender de un oráculo externo. [4]

Invariante de solvencia: lo emitido contra lo bloqueado

Para un bridge lock and mint hay una invariante que cualquier ingeniero puede escribir como test: la oferta del token envuelto en destino nunca debe superar el saldo bloqueado en origen. Las fallas graves son formas de romperla.

• Mensaje falso. El verificador (o quien robó sus claves) afirma un bloqueo que no ocurrió: se emite sin respaldo.
• Error de verificación. El contrato acepta una prueba o firma inválida: el efecto es el mismo que un mensaje falso.
• Repetición. Un mensaje válido se procesa dos veces: doble emisión o doble liberación.
• Liberación sin quema. En el camino de vuelta, el contrato de origen libera fondos sin un burn real en destino.

Figura 1

Lock and mint: dónde se rompe la invariante de solvencia

Fuentes:

[2]

Cómo leer esta figura

A la izquierda, la cadena de origen con un contrato de bloqueo que guarda un saldo B. En el centro, el verificador, que puede ser un multisig o MPC, un light client, un esquema optimista con ventana de disputa o un verificador de pruebas de validez. A la derecha, la cadena de destino con un contrato que emite el token envuelto con oferta S. Una flecha verde va del evento de bloqueo al verificador y del verificador a la emisión. Debajo, la invariante S menor o igual que B. Tres flechas rojas señalan cómo se rompe: un mensaje falso o claves robadas emiten sin bloqueo, una verificación defectuosa acepta una prueba inválida y un mensaje repetido emite dos veces.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

El riesgo no está repartido de forma pareja. ethereum.org señala que muchos de los mayores robos en blockchains involucraron bridges y cita el caso de Wormhole, donde se robaron 120.000 wETH, unos 325 millones de dólares. [1] La razón estructural es simple: un contrato de bloqueo acumula el colateral de todos los usuarios del bridge en un solo lugar.

El siguiente contrato es ilustrativo. Muestra el lado de destino de un lock and mint con protección contra repetición. Todo lo importante depende de quién es verifier.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
 
interface IMintable {
    function mint(address to, uint256 amount) external;
}
 
/// Ilustrativo: lado destino de un bridge lock-and-mint. Sin pausas, límites ni gobernanza.
contract MintGate {
    IMintable public immutable wrapped;
    address public immutable verifier; // multisig, light client o verificador de pruebas
    uint256 public immutable sourceChainId;
    mapping(bytes32 => bool) public processed;
 
    event Minted(bytes32 indexed messageId, address indexed to, uint256 amount);
 
    constructor(IMintable wrapped_, address verifier_, uint256 sourceChainId_) {
        wrapped = wrapped_;
        verifier = verifier_;
        sourceChainId = sourceChainId_;
    }
 
    function mintFromSource(bytes32 lockId, address to, uint256 amount) external {
        require(msg.sender == verifier, "solo verificador");
        bytes32 messageId = keccak256(abi.encode(sourceChainId, block.chainid, lockId, to, amount));
        require(!processed[messageId], "mensaje ya procesado");
        processed[messageId] = true;
        wrapped.mint(to, amount);
        emit Minted(messageId, to, amount);
    }
}

El mapping processed bloquea la repetición, y los dos chainid dentro del hash impiden reutilizar el mensaje en otro par de redes. Lo que el contrato no puede saber es si el bloqueo existió. Esa afirmación la hace verifier, y si sus claves se comprometen, mintFromSource emite lo que el atacante pida.

Traza de ejecución: un retiro por el bridge canónico de un rollup

El bridge nativo de un rollup es el caso con menos supuestos adicionales, porque el contrato en L1 verifica contra el estado que el propio rollup publica. La especificación de OP Stack describe un retiro en pasos: [5]

1. En L2, la cuenta llama a initiateWithdrawal del contrato predesplegado L2ToL1MessagePasser, que guarda el hash del mensaje.
2. En L1, un relayer envía una transacción de prueba al contrato OptimismPortal con los datos del retiro y una prueba de inclusión contra una raíz de salida (output root) del rollup.
3. Una vez probado, el retiro entra en un periodo de disputa de 7 días, en el que otros participantes pueden impugnar la raíz de salida.
4. Pasado ese plazo, un relayer envía la transacción de finalización, el portal comprueba que el retiro fue probado y que el plazo terminó, y ejecuta la llamada.

La especificación fija propiedades que funcionan como checklist de cualquier bridge: un retiro se prueba una sola vez salvo que cambie la raíz de salida, se finaliza una sola vez y ningún campo (remitente, destino, datos, valor, límite de gas) puede modificarse al retransmitirlo. Si la llamada final falla en el contrato de destino, el portal no ofrece reintento. Y como el portal puede enviar llamadas arbitrarias en L1, los tokens enviados por error a su dirección pueden darse por perdidos.

Para custodia, esta traza define tiempos y estados. Un retiro "iniciado" no es un retiro "disponible"; entre ambos hay una prueba, una semana de disputa y una finalización, cada una con su transacción y su costo de gas.

Riesgo operativo: inventario y reconciliación de activos puenteados

ethereum.org agrupa los riesgos de usar bridges. Todos tienen riesgo de contrato inteligente (un error de código expone los fondos) y de tecnología (fallas de software, errores humanos, spam o ataques). Los bridges confiables agregan riesgo de censura (los operadores pueden impedir transferencias) y de custodia (pueden coludirse para robar). [1] A esa lista hay que sumar el riesgo sistémico: si un token envuelto pierde su respaldo, todos los protocolos que lo aceptan como colateral heredan el agujero.

La guía para desarrolladores advierte además que integrar un solo bridge crea un punto único de falla y que un agregador de bridges suma más contratos y, por tanto, más superficie. [2] La liquidez de un token en un exchange descentralizado tampoco prueba solvencia: mide cuánto se puede vender hoy, no si el colateral existe.

Lab propuesto: romper y defender la invariante

Con dos redes locales y el contrato MintGate de arriba, el lab tiene tres pasos observables. Primero, un bloqueo real seguido de una emisión deja totalSupply igual al saldo bloqueado. Segundo, reenviar el mismo mensaje revierte con "mensaje ya procesado". Tercero, si el test controla la clave del verificador, puede emitir sin bloqueo y la invariante falla: es la demostración de que la seguridad del puente es la seguridad de esa clave. Como teardown basta detener ambas redes. Nada de esto debe desplegarse en mainnet sin pausas, límites y auditoría.

Conexiones dentro de la serie

• Antes: rollups desde cero y optimistic rollups y fraud proofs explican por qué el retiro canónico espera una ventana de disputa.
• Relacionado: EIP-7702, otra forma de autorizar en nombre de una cuenta, y oráculos y price feeds, donde también alguien afirma un hecho externo.
• Después: MEV y PBS, donde la pregunta pasa a ser quién ordena las transacciones.