Puentes Optimistas (Optimistic Bridges)

12 min readApr 3, 2022

Un Nuevo Paradigma para la Comunicación Crosschain

Hace un par de meses anunciamos nuestra estrecha colaboración con Nomad, un protocolo de comunicación crosschain que utiliza fraud proofs (similar a las Optimistic Rollups) para transmitir datos cross chain.

En este post profundizaremos en cómo funcionan los optimistic bridges, cuáles son sus concesiones, y por qué los amamos.

Resumen: El Trilema de la Interoperabilidad

El Trilema de la Interoperabilidad es un modelo para explicar el espacio de tradeoffs (concesiones) alrededor del bridging, con una taxonomía de los tipos de protocolos de comunicación crosschain que existen hoy.

Cuando escribimos acerca del trilema el año pasado, clasificamos los puentes en tres tipos, basados en cómo son verificados:

Localmente verificados (atomic swaps y fast liquidity systems)
Externamente verificados (multisig, mpc, threshold, PoS, y puentes validadores)
Nativamente verificados (light client header relays, puentes rollup)

En cada caso el mecanismo de verificación condujo a la concesión de al menos UNA de las tres propiedades deseables:

Trust-minimization (minimización de la confianza): no añadir ninguna asunción de seguridad económica más allá de la cadena subyacente.
Generalizabilidad: soportar pasaje de datos arbitrarios cross chain.
Extensibilidad: permitir la fácil implementación en muchas cadenas heterogéneas con un trabajo personalizado mínimo.

Optimistic Verification (Verificación Optimista)

A diferencia de puentes localmente, externamente, o nativamente verificados, los puentes optimistas exploran una nueva concesión: la latencia.

Así funcionan en rasgos generales:

De manera similar a otros puentes, los datos son posteados en una cadena de origen a una función de un contrato por un usuario o DApp.
Un agente llamado updater (actualizador) firma una merkle root que contiene los datos de (1) y los postea a la cadena de origen. De manera similar a un rollup sequencer, un updater hace bonding de fondos que están sujetos a slashing (penalización) en caso de fraude.
En este punto cualquier sistema repetidor (relayer como Gelato, Keep3r, Biconomy, etc.) puede leer esta root en la cadena de origen y postearla a una o varias cadenas de destino.
Postear los datos a la cadena de destino inicia una ventana de fraud proof de 30 minutos (similar al tiempo de retiro de una optimistic rollup). Durante este tiempo, cualquiera que mire la cadena (un watcher) puede probar el fraude en la cadena de origen y desconectar el canal de comunicación al destino. Si esto sucede, el bond del updater es sujeto a slashing (es decir, los fondos que se le otorgaron son confiscados y dados al watcher que realizó la disputa como recompensa).
Si ninguna prueba de fraude ocurre en esta ventana de 30 minutos, los datos pasados a la cadena de destino pueden ser considerados finalizados y consumidos por una aplicación. Típicamente esto ocurre haciendo que un proveedor de servicio (processor) entregue una merkle proof de los datos para el puente y luego utilice esos datos para llamar una función de un contrato en la cadena de destino.

Ya que los datos transmitidos son completamente arbitrarios, los puentes optimistas nos permiten construir cualquier tipo de aplicaciones/casos de uso crosschain con confianza mínima. Algunos ejemplos:

Bridging con minteo en la red de destino y respaldo en la de origen
Bridging con minteo en la red de destino y burning en la de origen.
Conectar liquidez de DEXes en distintas cadenas en una sola transacción.
Crosschain vault zaps (proveer liquidez y stakear los LP recibidos en una vault en una sola transacción automatizada y de manera crosschain) y administración de estrategias de vaults.
Operaciones de protocolo críticas como replicar/sincronizar constantes globales (por ejemplo, PCV) en distintas cadenas.
Brindar UniV3 TWAPs a todas las cadenas sin introducir oráculos.
Gobernanza agnóstica de veTokens (posibilidad de votar de manera crosschain).
Interoperabilidad entre metaversos.

Modelo de seguridad económica

De manera similar a las optimistic rollups y redes de state channels, los diseños de puentes optimistas dependen de un set de watchers que observen la cadena y reporten fraude. Esto es un modelo de seguridad fundamentalmente diferente de los puentes externamente verificados del mismo modo que las rollups tienen un modelo de seguridad fundamentalmente diferente que las sidechains.

Cryptoeconomía de los Puentes Externamente Verificados

Los puentes externamente verificados (multisig, validadores, PoS, mpc, o threshold) y las sidechains/L1s, utilizan una suposición de mayoría honesta. En otras palabras, m de n participantes en el sistema deben verificar actualizaciones correctamente. En términos criptoeconómicos esto significa:

El costo de atacar a un puente externamente verificado con n verificadores es igual al costo de corromper o hackear m verificadores.

Es importante tener en cuenta que este es un nuevo vector de ataque potencial — a menos que la seguridad económica del puente sea mayor que el costo de realizar un ataque de 51% de la cadena, esto necesariamente significa que el puente externamente verificado añade una (a menudo significativa) asunción de confianza.

La seguridad económica completa para un puente externamente verificado puede ser lograda si el sistema es capaz de (a) demostrar fraude de manera fehaciente, y (b) reembolsar a los usuarios el monto total de todo el valor que podría perderse en un hackeo. En otras palabras, los usuarios y/o los proveedores de liquidez únicamente pueden ser asegurados si el valor de su participación confiscable (slashable stake, por ejemplo, RUNE en Thorchain) es mayor o igual que el TVL del sistema completo. Téngase en cuenta que (a) es una suposición fuerte — probar de manera concluyente el fraude en sí mismo requiere un mecanismo de comunicación crosschain trustless, lo que convierte el problema en una especie de bucle.

Cryptoeconomía de los Puentes Optimistas

El patrón de watcher + fraud proof, por otra parte, utiliza una suposición de único verificador honesto. En otras palabras, los puentes optimistas únicamente requieren de 1 de n partes en el sistema que verifiquen las actualizaciones correctamente.

El costo de atacar a un puente optimista de n verificadores es igual al costo de corromper o hackear n verificadores.

Si los watchers de un sistema optimista (sean rollups, channels, o puentes) son permissionless (y asumimos que la cadena subyacente está activa), entonces el costo económico de atacar el sistema se vuelve ilimitado. Esto es porque no hay manera de asegurar que no haya al menos un único watcher en el mundo operando anónimamente que puede determinar fraude.

Esto tiene una consecuencia interesante:

En un puente optimista, el EV (valor esperado) de un intento de fraude es siempre negativo porque, mientras que las cadenas subyacentes sean seguras, ninguna cantidad de dinero puede garantizar que el ataque será exitoso. Como tal, la cantidad de slashable stake que necesita ser bonded por el updater solo debe ser lo suficientemente alta como para prevenir intentos de fraude (detener griefing).

Es por esto que los sequencers de Optimistic Rollups, por ejemplo, solo necesitan tener un pequeño subconjunto del TVL de la rollup como bond.

Modos de Falla

Quizás la mejora más importante que los puentes optimistas hacen sobre los puentes externamente verificados es intercambiar liveness (actividad) por seguridad. En otras palabras, mientras que la cadena subyacente sea segura, el peor caso teóricamente posible ya no es una pérdida de fondos, sino una parada (detención) del sistema.

Updater DoS

De manera similar a un rollup sequencer, es posible para un updater centralizado detener el sistema maliciosa o accidentalmente si deja de firmar actualizaciones.

Sin embargo, descentralizar el updater de Nomad es una tarea bastante sencilla. Un ejemplo de construcción simple sería tener varios bonded updaters (en lugar de uno solo) y utilizar un enfoque de “turnos” rotativos para firmar actualizaciones, con conmutación por error y slashing si un cierto updater pierde su “turno”.

Fraude de Updater

Cualquier dato que es transmitido entre cadenas en un puente optimista debe ser firmado por el updater, lo que significa que cualquier fraude en el sistema también debe originarse en el updater.

En los puentes optimistas, el fraude siempre es demostrable determinísticamente en la cadena de origen (similar a como el fraude en las optimistic rollups siempre es demostrable en L1). Para hacer esto, el watcher simplemente debe presentar una prueba de una actualización inválida al contrato de la cadena de origen, que resulta en el updater sufriendo slashing. Luego, el watcher presenta un mensaje firmado a la cadena de destino para “desconectar” el canal de comunicación dentro de los 30 minutos y antes de que los datos fraudulentos puedan ser considerados finalizados.

En verdad, no es necesario demostrar fraude en la cadena de destino. Hacerlo en la cadena de origen (home chain) penaliza correctamente al updater, que desincentiva el fraude en primer lugar, y subsecuentemente la desconexión del canal de comunicación mitiga cualquier daño potencial causado. Dicho esto, la habilidad de un watcher para desconectar arbitrariamente el canal de comunicación abre un vector de DoS (Denial of Service), que discutimos abajo.

Watcher DoS

Ya que cualquier watcher puede iniciar la desconexión de un canal de comunicación en un puente optimista, es posible para los watchers hacer griefing/detener permanentemente un canal de comunicación mediante el spam de desconexiones. Nótese que los watchers no ganan nada del sistema por hacer esto (todos los fondos/datos permanecen seguros), y el riesgo de esto es compartimentado por canal de comunicación (es decir, desconectar un canal no tira abajo el sistema entero).

Este tipo de vector de ataque puede ser mitigado en el largo plazo introduciendo el tipo correcto de incentivos para los watchers. Ya que los watchers ganan el slashed bond del updater cuando disputan correctamente, podemos mitigar el watcher griefing introduciendo un impuesto básico para los watchers que inicien una demostración de fraude. Este impuesto debería ser (a) suficientemente alto para desincentivar el spam, así como también (b) suficientemente bajo comparado al updater bond para que los watchers sigan teniendo un fuerte incentivo para iniciar demostraciones de fraude válidas. Otra solución simple sería postear la firma de desconexión generada por el watcher a la cadena de origen y hacerle slashing al watcher si el fraude no fue demostrado.

Por el momento, Nomad maneja este problema mediante un set de watchers autorizados. Esto cambia la seguridad económica del sistema porque ahora hay una cantidad fija/sabida de watchers que podrían ser corrompidos (limitando el costo de ataque). Sin embargo, consideramos que esta es una solución provisoria aceptable porque hay un camino directo y altamente creíble para la minimización de la confianza. Este enfoque también espeja el modo en que otros sistemas fraud proof han sido lanzados:

Redes de state channels han iniciado históricamente con un set de watchers autorizados para mitigar estos vectores de griefing hasta que el tipo correcto de incentivos puedan ser construidos.
Las optimistic rollups están actualmente en la misma etapa, en la que las fraud proofs y las disputas no han sido activadas todavía. Mientras que esto significa que las rollups son más trusted actualmente, la comunidad en general entiende que esto se trata solo de “ruedas de entrenamiento” temporarias hasta que las implementaciones maduren.

Fallas de Actividad de Cadena

La suposición central que hemos discutido arriba es que las cadenas subyacentes son capaces de aceptar transacciones de los watchers. Esta asunción es la misma para cualquier sistema basado en fraud proofs, donde la construcción típica tiene alguna proof window en la cual los watchers deben completar una transacción en la cadena.

Nomad ha parametrizado su latencia de 30 minutos basada una en investigación existente sobre el costo de atacar cadenas con finalidad probabilística. Intentaremos deconstruir los estudios/lógica detrás de esta parametrización en un post futuro.

Comparación a Otros Enfoques

Todo sistema distribuido tiene sus concesiones — las comidas gratuitas no existen en el mundo del bridging. La concesión más evidente de los sistemas optimistas es, con mucho, la adición de los 30 minutos de latencia para transferencias, aunque creemos que esto puede ser mitigado usando un diseño modular que pone a Connext como capa por encima (pronto vendrán más noticias sobre esto!).

Puentes M de N

Como mostramos arriba, los puentes optimistas significan un paso adelante gigantesco en términos de seguridad y minimización de la confianza comparado a los puentes externamente verificados (multisig, set de validadores, PoS, mpc, o threshold). El modelo de seguridad 1 de N de los puentes optimistas puede mitigar vectores ataques devastadores relacionados a la colusión o a las llaves privadas comprometidas.

Por ejemplo, el hackeo al Ronin Bridge de $625m USD no habría sido posible si Ronin hubiese utilizado un puente optimista, incluso si todas las llaves hubieran estado comprometidas.

Una comparación similar puede hacerse con LayerZero, que utiliza dos conjuntos m de n superpuestos que funcionalmente actúan simplemente como un conjunto m de n más grande (donde el tamaño del conjunto de participantes y los vectores de colusión se vuelven más difíciles de razonar a menos que se conozca la identidad de todos los participantes de ambos conjuntos).

Atomic Swaps y Liquidez Rápida

Los sistemas localmente verificados (como la implementación actual de NXTP de Connext), mientras que son trustless y fáciles de implementar como los puentes optimistas, son incapaces de soportar el pasaje de datos arbitrarios entre cadenas.

En este sentido tienen un rendimiento inferior comparado a los puentes optimistas para cualquier cosa más allá de transferencia de fondos o simples ejecuciones de contratos. Dicho esto, es probable que sigan siendo muy útiles como un mecanismo para mitigar otras concesiones de puentes optimistas (latencia).

Header Relays

Light Client Header Relay Systems (sistemas de transmisión de encabezados de cliente ligero) como IBC funcionan validando el consenso de la cadena B dentro de la Virtual Machine de la cadena A. Los Header Relays nos dan los mejores supuestos de confianza teóricos ya que los conjuntos de validadores de cada cadena subyacente se verifican entre sí — no se introducen partes adicionales (como en los puentes externamente verificados) o supuestos de actividad (como puentes optimistas). Tampoco son sujetos a la concesión de latencia que tienen los puentes optimistas.

Dicho esto, los header relays no están exentos de sus propios desafíos:

Un cliente ligero personalizado debe ser construido por cada cadena o mecanismo de consenso nuevo que se incorpore.
Específicamente para Ethereum PoW, el costo de verificar el consenso es prohibitivo debido a altos requisitos de memoria.
Los header relays pueden no funcionar con optimistic rollups debido al riesgo de un rollback.

Puentes ZK (Zero Knowledge)

Si bien aún no existen puentes ZK en producción, es posible construir puentes basados en pruebas Zero Knowledge que utilizan la misma estrategia que los header relays para validar datos entre cadenas.

De modo similar a los header relays, los puentes ZK tienen estupendas consideraciones de confianza y baja latencia. También son probablemente mucho más baratos que los header relays regulares porque ya no es necesario que la prueba del consenso sea en la cadena. Sin embargo, al hacer esto introducen nuevas concesiones:

De modo similar a los light client header relays, una estrategia personalizada debe ser desplegada para validar el consenso de cada cadena, y es posible que esto no funcione para optimistic rollups en absoluto. Para los puentes ZK esto es aún más difícil dado que no todas las cadenas implementan los mismos primitivos criptográficos.
De hecho, no es posible probar todos los modelos de consenso en zero knowledge. En estos casos, algún tipo de artilugio de finalidad es requerido, lo que implica nuevas suposiciones de confianza.

Es probable que existan otros inconvenientes relacionados al costo de prueba y la disponibilidad de datos, aunque estos no han sido investigados en profundidad aún.

El Futuro del Bridging es Optimista

Hasta ahora no hemos tenido mecanismos computacionalmente baratos para transmitir datos arbitrarios entre cadenas que no involucren terceras partes verificadoras en las que se deba confiar. Los puentes optimistas dan un muy alto nivel de seguridad/minimización de la confianza, a la vez que retienen la simplicidad y la facilidad de implementación de los puentes multisig existentes.

Por esta razón estamos increíblemente entusiasmados sobre Nomad y pensamos que representa un gran salto hacia adelante para la comunicación crosschain y crossrollup.

Acerca de Nomad

Nomad es un nuevo diseño para comunicación cross-chain radicalmente más barata sin header verification (verificación de encabezado). Va a formar la capa base de una red de comunicación cross-chain que provee comunicación rápida y barata para todas las cadenas de contratos inteligentes y rollups.

El protocolo de interoperabilidad de Nomad está activo en Ethereum Mainnet, Moonbeam y Milkomeda, y planea implementarse pronto en todas las cadenas principales.

Acerca de Connext

Connext es una red para comunicación rápida y trustless entre cadenas y rollups. Es el único sistema de interoperabilidad de su especie que hace esto de manera barata y veloz sin introducir nuevos supuestos de confianza. Connext está apuntado a desarrolladores que están buscando construir puentes y otras aplicaciones nativamente cross-chain. Hasta la fecha más de $1300 millones de USD en transacciones han cruzado la red.

Muchas gracias a Anna Carroll, James Prestwich, Pranay Mohan, y el resto del equipo de Nomad por las ideas y el feedback que han contribuido a este post!