# El Trilema de la Interoperabilidad By [Connext Español](https://paragraph.com/@connext-espa-ol) · 2022-05-28 --- También conocido como: Por qué bridgear entre Dominios de Ethereum es tan difícil ![](https://storage.googleapis.com/papyrus_images/547de8a0642d7afd48e3c4d83d8809cd7a23f1e7172cfe524e99c798a3d79fa0.jpg) Hace unos meses lanzamos NXTP, [nuestro protocolo que habilita transferencias y llamadas de contratos entre dominios (dominios = cadenas y L2s) Ethereum-compatibles completamente _trustless_](https://medium.com/connext/nxtp-a-simpler-xchain-protocol-88760697ea04) (que no requieren confiar en nadie más que en los validadores de las cadenas subyacentes). [https://twitter.com/ConnextNetwork/status/1442846763841425410?ref\_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1442846763841425410%7Ctwgr%5E%7Ctwcon%5Es1\_&ref\_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fconnextnetwork%2Fstatus%2F1442846763841425410image%3Dhttps3A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fabs.twimg.com252Ferrors252Flogo46x38.png26key3Da19fcc184b9711e1b4764040d3dc5c07](https://twitter.com/ConnextNetwork/status/1442846763841425410?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1442846763841425410%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fconnextnetwork%2Fstatus%2F1442846763841425410image%3Dhttps3A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fabs.twimg.com252Ferrors252Flogo46x38.png26key3Da19fcc184b9711e1b4764040d3dc5c07) Este post intentará explicar por qué la interoperabilidad entre dominios de Ethereum es difícil, y desde ahí mostrar por qué creemos que NXTP representa el comienzo de una verdadera solución de largo plazo para el ecosistema. La Necesidad de Interoperabilidad Trustless en Ethereum ------------------------------------------------------- Ethereum multicadena/L2 está aquí y llegó para quedarse. Esto ha estimulado la creación de decenas de puentes nuevos y protocolos de interoperabilidad mientras los proyectos se apuran para permitir esta funcionalidad en DeFi. Como es de esperar, también ha traído un número de hackeos y estafas de alto perfil: * Los [múltiples](https://decrypt.co/76117/thorchains-rune-token-slides-following-multi-million-exploit) [hackeos](https://www.coindesk.com/markets/2021/07/23/blockchain-protocol-thorchain-suffers-8m-hack/) de [Thorchain](https://www.theblockcrypto.com/post/111660/thorchain-suffers-5-million-exploit-developers-have-put-out-a-fix). * El [hackeo de PolyNetwork](https://edition.cnn.com/2021/08/11/tech/crypto-hack/index.html). * [Esta joya absoluta](https://twitter.com/dberenzon/status/1431337257873465344?s=20): [https://twitter.com/dberenzon/status/1431337257873465344?s=20&t=sfeendtONrVjdN2\_qbxd6Q](https://twitter.com/dberenzon/status/1431337257873465344?s=20&t=sfeendtONrVjdN2_qbxd6Q) A pesar de estos ejemplos, todos los sistemas de _bridging_ que existen se proclaman a sí mismos como _trustless_, seguros, y descentralizados (incluso si ese no es el caso en absoluto). Esto significa que el gran desafío para los desarrolladores y los usuarios ahora es: “¿cómo puedo descifrar cuáles mecanismos de _bridging_ son en verdad cryptoeconómicamente seguros?” En otras palabras, cómo pueden los usuarios discernir entre distintos tipos de puentes para determinar en quién están confiando cuando mueven fondos entre cadenas? ¿Qué Significa “Trustless” en Cryptoeconomía? ============================================= En la comunidad de investigación, cuando hablamos de seguridad cryptoeconómica y la propiedad de ser _trustless_, en realidad nos hacemos una pregunta muy específica: ¿Quiénes están verificando el sistema y cuánto cuesta corromperlo? ------------------------------------------------------------------ Si nuestro objetivo es construir bienes públicos realmente descentralizados e incensurables, entonces debemos considerar que nuestros sistemas podrían ser atacados por adversarios increíblemente poderosos como naciones soberanas rebeldes, megacorporaciones, o genios malvados megalomaníacos. ![Si tu modelo de amenazas no incluye al inevitable giro de Jeffrey Bezos hacia una malvada mente maestra, ngmi.](https://storage.googleapis.com/papyrus_images/980b7bcae108e57683962658171d289031d4865544b9aa7c691d53a02c3352d9.jpg) Si tu modelo de amenazas no incluye al inevitable giro de Jeffrey Bezos hacia una malvada mente maestra, ngmi. Maximizar la seguridad significa maximizar el número y la diversidad de los verificadores (validadores, mineros, etc.) en tu sistema, y esto típicamente significa hacer tu mejor esfuerzo para tener un sistema que es verificado enteramente por el conjunto de validadores de Ethereum. Esta es la idea central detrás de L2 y el enfoque de escalabilidad de Ethereum. > \*Aparte: la mayoría de las personas no se da cuenta de esto, pero la investigación de escalabilidad es investigación de interoperabilidad. Hemos sabido que podemos escalar moviéndonos a múltiples dominios por mucho tiempo. El problema siempre ha sido cómo habilitar la comunicación hacia estos dominios de manera trustless. Es por eso que el [artículo seminal de John Adler sobre optimistic rollups](https://ethresear.ch/t/trustless-two-way-bridges-with-side-chains-by-halting/5728) se titula **“Puentes bidireccionales trustless con sidechains por detención”**.\* Qué Ocurre si Añadimos Nuevos Verificadores entre Dominios? =========================================================== Tomemos lo que hemos aprendido arriba acerca de la seguridad cryptoeconómica y apliquémoslo a los puentes. ![](https://storage.googleapis.com/papyrus_images/f94be72a7a2a665abd015ff33bdff65da07b7be8e272c654f593a27d5c572a4c.png) Considere un escenario en el que usted tiene sus fondos en Arbitrum. Ha elegido usar este dominio específicamente porque es una _rollup_, lo que significa que (con algunos supuestos razonables) sus fondos están asegurados completamente por los verificadores subyacentes de Ethereum. En otras palabras, sus fondos son lo más cryptoeconómicamente seguros que pueden ser en el ecosistema de blockchain. Ahora imagine que decide usar un puente para mover sus fondos de manera barata y rápida a Optimism. Optimism también es _trustless_, por lo que se siente cómodo teniendo sus fondos allí sabiendo que van a compartir el mismo nivel de seguridad (la seguridad de Ethereum) que en Arbitrum. ![](https://storage.googleapis.com/papyrus_images/f48a4c242d9ab6e5e1e70d2d00c5a9e0a645d643a10bb9b28b6bd59bb859ed16.png) Sin embargo, el protocolo de puente que usted utiliza tiene su propio conjunto de verificadores externos. Mientras que esto inicialmente puede no parecer un gran problema, sus fondos **ya no están asegurados por Ethereum**, sino por los verificadores del puente: 1. Si se trata de un puente _lock/mint_ creando _wrapped assets,_ entonces los verificadores del puente pueden coludir unilateralmente para robar todos sus fondos. 2. Si se trata de un puente que utiliza _liquidity pools_, los verificadores del puente pueden coludir de manera similar para robar todo el capital del _pool_ de los _Liquidity Providers_. A pesar de haber esperado por años por L2s seguras y _trustless_, su situación ahora es la misma que si hubiera usado una _trusted_ _sidechain_ o L1. 😱 La conclusión clave es que los sistemas cryptoeconómicos son solo tan seguros como su eslabón más débil. Cuando utiliza puentes inseguros, ya no importa cuán segura es su cadena o L2. De modo similar a la seguridad de las L1s y L2s, todo se reduce a una pregunta: **¿quién está verificando el sistema?** Una Taxonomía de Protocolos de Interoperabilidad ================================================ Podemos clasificar a todos los protocolos de interoperabilidad en tres tipos generales en función de quién los verifica: Nativamente Verificados ----------------------- Los protocolos nativamente verificados son aquellos en los que todos los validadores de las cadenas subyacentes se encuentran validando completamente los datos que pasan entre las cadenas. Típicamente esto se hace corriendo un cliente ligero de una cadena en la _Virtual Machine_ de la otra y viceversa. ![](https://storage.googleapis.com/papyrus_images/d92ad6ae8487525a952cfa885e444f10aedf4cbdc827f483f89748d2dc215523.png) Ejemplos de éstos incluyen Cosmos IBC y Near RainbowBridge. Las entradas y salidas de _rollups_ también son un tipo especial de puentes nativamente verificados! Ventajas: * Es la forma más _trustless_ de interoperabilidad porque los verificadores subyacentes son directamente responsables por el _bridging_. * Permite la transferencia de mensajes completamente generalizada entre dominios. Desventajas: * Se basa en la confianza subyacente y/o el mecanismo de consenso del dominio para funcionar, por lo que debe ser construido de manera personalizada para cada tipo de dominio. El ecosistema de Ethereum es altamente heterogéneo: tenemos dominios muy distintos desde _ZK/Optimistic rollups, sidechains_ hasta _base chains_ que corren una amplia variedad de algoritmos de consenso: _ETH-PoW (Proof of Work)_, _Nakamoto-PoW_, _Tendermint-PoS (Proof of Stake)_, _Snowball-PoS_, _PoA (Proof of Authority)_, y muchos otros. Cada uno de estos dominios requiere una estrategia única para implementar un sistema de interoperabilidad nativamente verificado. Externamente Verificado ----------------------- Los protocolos externamente verificados son aquellos en los que un conjunto de verificadores externos es usado para transmitir datos entre cadenas. Esto es típicamente representado como un sistema _MPC (Multi Party Computation),_ redes de oráculos, o _threshold multisig_ (_t_odos estos son efectivamente la misma cosa). ![](https://storage.googleapis.com/papyrus_images/f8f3036d07e227b8f5aa494a6394bb9dc942e4b571eb1fd0d4c06a860b8e0a1d.png) Ejemplos de éstos incluyen Thorchain, Multichain (Anyswap), Biconomy, Celer, Synapse, PolyNetwork, EvoDeFi, y muchos, muchos otros. Ventajas: * Permite la transferencia de mensajes completamente generalizada entre dominios. * Puede ser extendido fácilmente a cualquier dominio en el ecosistema de Ethereum. Desventajas: * Los usuarios y/o los proveedores de liquidez confían sus fondos/datos plenamente en los verificadores externos. Esto significa que el modelo es fundamentalmente menos cryptoeconómicamente seguro que los dominios subyacentes (similar al ejemplo de Arbitrum y Optimism de más arriba). En algunos casos, los proyectos usan _staking_ adicional o mecanismos de _bonding_ para intentar añadir seguridad para los usuarios. Sin embargo, esto típicamente no tiene mucho sentido económico. Para que un sistema sea _trustless_, los usuarios deben estar asegurados hasta la máxima cantidad que puede ser robada, y ese seguro **debe** venir de los verificadores mismos. Esto no solo incrementa significativamente el capital requerido en el sistema, sino que también anula todo el propósito de tener _minted assets_ o _liquidity pools_ en primer lugar. Localmente Verificado --------------------- Los protocolos localmente verificados son aquellos en los que únicamente las partes involucradas en una cierta interacción cross-domain verifican esa interacción. Los protocolos localmente verificados convierten la compleja verificación de n partes en un problema mucho más simple de 2 partes, en las que cada una verifica únicamente a su contraparte. Este modelo funciona mientras ambas partes sean adversarios económicos, es decir, que no haya manera en que las dos partes puedan acordar entre ellas para robar fondos de la cadena en general. ![](https://storage.googleapis.com/papyrus_images/7b2f6cfbf9d50ce7bfb1e46d86424dbc835a8939b571678cc941ee899ee87c39.png) Ejemplos de éstos incluyen Connext, Hop, y otros sistemas simples de _atomic swaps_. Ventajas: * Los sistemas localmente verificados son _trustless_ — su seguridad está garantizada por las cadenas subyacentes dadas algunas consideraciones razonables que son compartidas con las _rollups_ (por ejemplo, que las cadenas no puedan ser censuradas por más de X días). * También son muy fáciles de extender a otros dominios. > _Nota: No_ **_todos_** _los sistemas localmente verificados son trustless. Algunos adoptan algunas concesiones de confianza para mejorar la UX (experiencia de usuario) o añadir funcionalidad extra._ > > _Por ejemplo, Hop añade algunos supuestos de confianza a través de su necesidad de un fast arbitrary-messaging-bridge (AMB, Puente de mensajes arbitrarios) en su sistema: el protocolo desbloquea la liquidez de los bonders en 1 día en lugar de esperar los 7 días del período de salida de las rollups. El protocolo también requiere de un puente externamente verificado si no existe ningún AMB para un determinado dominio._ Desventajas: * Los sistemas localmente verificados no pueden soportar transmisión de datos generalizada entre cadenas. Esta última frase tiene una sutileza que se reduce a autorización: es posible para un sistema localmente verificado habilitar llamadas de contratos cross-domain pero solo si la función que se está llamando tiene algún tipo de dueño lógico (_logical owner_). Por ejemplo, es posible llamar de manera _trustless_ a una función de swap de Uniswap entre cadenas porque la función puede ser llamada por cualquiera que tenga tokens que puedan ser intercambiados. Sin embargo, no es posible hacer _lock-and-mint_ (respaldo y minteo) de NFTs de manera _trustless_ entre cadenas. Esto se debe a que el dueño lógico de la función _mint_ en la cadena de destino debería ser el contrato de _lock_ en la cadena de origen, y esto no es posible representarlo en un sistema localmente verificado. El Trilema de la interoperabilidad ---------------------------------- Ahora llegamos a la tesis de este artículo, y el modelo mental que debería impulsar las decisiones de los usuarios y los desarrolladores sobre la selección de puentes. ![](https://storage.googleapis.com/papyrus_images/f7fbc98f913db228451d7a40ea73a755d921c8b51ade2455bf4610fcb852a775.png) De modo similar al [trilema de la escalabilidad](https://vitalik.ca/general/2021/04/07/sharding.html), existe un **trilema de la interoperabilidad** en el ecosistema de Ethereum. Los protocolos de interoperabilidad solo pueden tener dos de las siguientes tres propiedades: * **_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. ¿Cómo Encajan Connext y NXTP en Esto? ------------------------------------- No hay una manera sencilla para obtener las tres propiedades deseables de la interoperabilidad. Sin embargo, nos hemos dado cuenta de que podemos adoptar el mismo enfoque a resolver el trilema de la interoperabilidad que el enfoque de Ethereum para resolver el trilema de la escalabilidad. Ethereum L1 optimiza para lograr seguridad y descentralización, a costo de escalabilidad. La razón de esto es que estas propiedades son probablemente las más importantes para la longevidad y la utilidad de una blockchain. Ethereum añade escalabilidad via L2/_sharding_ como una capa por encima de una red troncal segura y descentralizada existente. En Connext, creemos firmemente que el sistema de interoperabilidad con la mayor longevidad, utilidad, y adoptabilidad en el ecosistema de Ethereum será aquel que es máximamente _trustless_ y extensible. Por esta razón, NXTP es un sistema localmente verificado especialmente diseñado para ser **tan seguro como los dominios subyacentes** mientras que sigue siendo **utilizable en cualquier dominio**. Entonces, ¿qué pasa con la generalizabilidad? De modo similar a la escalabilidad en el ecosistema de Ethereum, podemos agregar generalizabilidad conectando protocolos nativamente verificados encima de NXTP (como una “L2” de nuestra red de interoperabilidad!). De ese modo, los usuarios y los desarrolladores obtienen una interfaz consistente a través de cualquier dominio, y pueden “mejorar” su conexión para ser generalizada en los casos en donde esa funcionalidad está disponible. ![](https://storage.googleapis.com/papyrus_images/e688a09e01a7dcd1445411cd9fbcb8f21137c4f571f225b0b48d1435e35646af.png) Es por esto que decimos que NXTP es el **protocolo base** de nuestra red de interoperabilidad. La red entera estará hecha de un **_stack_** de protocolos que incluirán NXTP, puentes crosschain generalizados específicos para pares de dominios, y protocolos para conectarlos todos en un sistema fluido. 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 James Prestwich, Eli Krenzke, Dmitriy Berenzon, y en general a la comunidad de investigación de L2 por las conversaciones que han contribuido a las ideas de este post durante los últimos años.😄 --- *Originally published on [Connext Español](https://paragraph.com/@connext-espa-ol/el-trilema-de-la-interoperabilidad)*