El Trilema de la Interoperabilidad
También conocido como: Por qué bridgear entre Dominios de Ethereum es tan difícil
Hace unos meses lanzamos NXTP, nuestro protocolo que habilita transferencias y llamadas de contratos entre dominios (dominios = cadenas y L2s) Ethereum-compatibles completamente trustless (que no requieren confiar en nadie más que en los validadores de las cadenas subyacentes).
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:
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.
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 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.
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.
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:
- Si se trata de un puente lock/mint creando wrapped assets, entonces los verificadores del puente pueden coludir unilateralmente para robar todos sus fondos.
- 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.
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 (todos estos son efectivamente la misma cosa).
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.
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.
De modo similar al trilema de la escalabilidad, 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.
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 | Documentation | Twitter | Discord | Github | Blog | Telegram
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.😄
