# Puentes Optimistas (Optimistic Bridges) By [Connext Español](https://paragraph.com/@connext-espa-ol) · 2022-05-28 --- Un Nuevo Paradigma para la Comunicación Crosschain ![](https://storage.googleapis.com/papyrus_images/547de8a0642d7afd48e3c4d83d8809cd7a23f1e7172cfe524e99c798a3d79fa0.jpg) Hace un par de meses anunciamos [nuestra estrecha colaboración con Nomad](https://blog.connext.network/connext-has-partnered-with-nomad-e20cd8e62e31), un protocolo de comunicación crosschain que utiliza _fraud proofs_ (similar a las [_Optimistic Rollups_](https://ethereum.org/en/developers/docs/scaling/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](https://mirror.xyz/0x0A22560771eA52cE7309450f22f79B5B1d278989/n50zCycC4cb3M7b5k9sJLa3QAsWtA_ztTePcTTvwuoU) 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 cross-chain que existen hoy. ![](https://storage.googleapis.com/papyrus_images/f7fbc98f913db228451d7a40ea73a755d921c8b51ade2455bf4610fcb852a775.png) 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. ![](https://storage.googleapis.com/papyrus_images/bf281f951f48698323589406930c4cdd57ed01172afc0d845736f3c3a9aee39b.png) Así funcionan en rasgos generales: 1. 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. 2. 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. 3. En este punto cualquier sistema repetidor (relayer como [Gelato](http://gelato.network/), [Keep3r](https://keep3r.network/), [Biconomy](https://biconomy.io/), etc.) puede leer esta _root_ en la cadena de origen y postearla a una o varias cadenas de destino. 4. 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). 5. 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._ 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). ![Deja de desconectar mis canales, Bill!](https://storage.googleapis.com/papyrus_images/83ab775e125beaed00e7890c03ee51caa321c4ac15dae0cc16dbbffe58db21f5.gif) Deja de desconectar mis canales, Bill! 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](https://medium.com/offchainlabs/fighting-censorship-attacks-on-smart-contracts-c026a7c0ff02). 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](https://blog.connext.network/connext-has-partnered-with-nomad-e20cd8e62e31?source=collection_home---4------2-----------------------) (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. [https://twitter.com/\_prestwich/status/1508844826359332868?s=20&t=Bcz6K7xDsd94aG4LxQJCSw](https://twitter.com/_prestwich/status/1508844826359332868?s=20&t=Bcz6K7xDsd94aG4LxQJCSw) 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](https://github.com/connext/nxtp)), 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](https://ibcprotocol.org/) 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.](https://eth.wiki/concepts/ethash/design-rationale) * 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. [Website](https://connext.network/) | [Documentation](https://docs.connext.network/) | [Twitter](https://twitter.com/ConnextEspanol) | [Discord](https://discord.gg/raNmNb5) | [Github](https://github.com/connext) | [Blog](https://medium.com/connext) | [Telegram](https://t.co/uCRMCsKyYT) _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!_ --- *Originally published on [Connext Español](https://paragraph.com/@connext-espa-ol/puentes-optimistas-optimistic-bridges)*