Desplácese para leer más

Artículo original escrito por Dmitriy Berenzon, traducido y editado por CryptoChica

 

Después de años de investigación y desarrollo, por fin estamos en una estructura de mercado multichain. Hay más de 100 blockchains públicas activas, muchas de las cuales tienen sus propias aplicaciones, usuarios, geografías, modelos de seguridad y compensaciones de diseño. A pesar de lo que creen las comunidades individuales, la realidad es que el universo tiende a la entropía, y el número de estas redes probablemente seguirá aumentando en el futuro.

 

Este tipo de estructura de mercado hace necesaria la interoperabilidad entre estas distintas redes. Muchos desarrolladores se han dado cuenta de ello, y en el último año se ha producido una explosión de bridges (De ahora en más, bridges, por su término original en inglés) de blockchain que intentan unificar un panorama cada vez más fragmentado. En el momento de escribir este artículo, hay más de 40 proyectos de bridges diferentes.

 

 

En este artículo voy a:

  • Explicar por qué los bridges son importantes.
  • Describir los distintos tipos de bridges, sus fortalezas y debilidades.
  • Proporcionar una visión general del panorama actual de los bridges.
  • Describir cómo podría ser el futuro de los bridges. 

 

La interoperabilidad desbloquea la innovación

A medida que los ecosistemas individuales crecen, desarrollan sus propios puntos fuertes, como una mayor seguridad, un rendimiento más rápido, transacciones más baratas, mejor privacidad, provisión de recursos específicos (por ejemplo, almacenamiento, cómputo, ancho de banda) y comunidades regionales de desarrolladores y usuarios. Los bridges son importantes porque permiten a los usuarios acceder a nuevas plataformas, a los protocolos interoperar entre sí y a los desarrolladores colaborar en la creación de nuevos productos. Más concretamente, permiten:

 

Mayor productividad y utilidad para los criptoactivos existentes

Los bridges permiten a las criptoactivos existentes viajar a nuevos lugares y hacer nuevas cosas. Por ejemplo:

  • Enviar DAI a Terra para comprar un activo sintético en Mirror o ganar rendimientos en Anchor.
  • Enviar un TopShot de Flow a Ethereum para utilizarlo como garantía en NFTfi.
  • Utilizar DOT y ATOM como garantía para obtener un préstamo DAI en Maker.

 

Mayores capacidades de producto para los protocolos existentes

Los bridges amplían el espacio de diseño que los protocolos podrían lograr. Por ejemplo:

 

  • Vaults de Yearn para yield farming en Solana y Avalanche.
  • Libros de órdenes cross-chain compartidos para NFT en Ethereum y Flow, para el protocolo Rarible.
  • Índices Proof-of-Stake para Index Coop.

 

Nuevas posibilidades para usuarios y desarrolladores

Los bridges ofrecen a los usuarios y desarrolladores más opciones. Por ejemplo:

  • Arbitraje de precios SUSHI a través de DEXs en Optimism, Arbitrum y Polygon.
  • Pagar por el almacenamiento en Arweave utilizando Bitcoin.
  • Participar en una PartyBid para una NFT en Tezos.

 

Bridges 101

En un nivel abstracto, se podría definir un bridge como un sistema que transfiere información entre dos o más blockchains. En este contexto, “información” podría referirse a activos, llamadas a contratos, pruebas o estado. La mayoría de los diseños de bridges tienen varios componentes:

 

  • Control: Suele haber un actor, ya sea un “oráculo”, un “validador” o un “transmisor”, que supervisa el estado de la cadena de origen.
  • Paso de mensajes/relaying: Después de que un actor capte un evento, tiene que transmitir información de la cadena de origen a la de destino.
  • Consenso: En algunos modelos, se requiere un consenso entre los actores que supervisan la cadena de origen para transmitir esa información a la cadena de destino.
  • Firma: Los actores necesitan firmar criptográficamente, ya sea individualmente o como parte de un esquema de firma de umbral, la información enviada a la cadena de destino.

 

Existen a grandes rasgos cuatro tipos de bridges, cada uno con sus propias ventajas e inconvenientes:

 

  • Específicos de los activos: Un bridge con el único propósito de proporcionar acceso a un activo específico desde una cadena externa. Estos activos suelen ser activos “envueltos” (wrapped) que están totalmente colateralizado por el subyacente, ya sea de forma custodiada o no custodiada. Bitcoin es el activo más común que se puentea con otras cadenas, con siete bridges diferentes sólo en Ethereum. Estos bridges son los más sencillos de implementar y gozan de un volante de liquidez, pero tienen una funcionalidad limitada y necesitan ser re-implementados en cada cadena de destino. Algunos ejemplos son wBTC y Arweave envuelto.

 

  • Específicos de la cadena: Un bridge entre dos blockchains que normalmente soporta operaciones sencillas en torno al bloqueo y desbloqueo de tokens en la cadena de origen, y el minteo de cualquier activo envuelto en la cadena de destino. Estos bridges suelen tener un tiempo de comercialización más rápido debido a su limitada complejidad, pero no escalan fácilmente al ecosistema más amplio. Un ejemplo es el bridge PoS de Polygon, que permite a los usuarios transferir activos de Ethereum a Polygon y viceversa, pero está limitado a esas dos cadenas.

 

  • Específicos de la aplicación: Una aplicación que proporciona acceso a dos o más blockchains, pero únicamente para su uso dentro de esa aplicación. La aplicación en sí se beneficia de una base de código más pequeña; en lugar de tener instancias separadas de toda la aplicación en cada blockchain, suele tener “adaptadores” más ligeros y modulares en cada una de esas blockchains. Una blockchain que implementa un adaptador obtiene acceso a todas las demás a las que está conectada, por lo que existe un efecto de red. El inconveniente es que es difícil ampliar esa funcionalidad a otras aplicaciones (por ejemplo, de préstamo a exchange). Algunos ejemplos son Compound Chain y Thorchain, que están construyendo blockchains separadas específicamente para el préstamo y exchange cross-chain, respectivamente.

 

  • Generalizados: un protocolo diseñado específicamente para transferir información a través de múltiples blockchains. Este diseño goza de fuertes efectos de red debido a la complejidad O(1): una sola integración para un proyecto le da acceso a todo el ecosistema dentro del bridge. El inconveniente es que algunos diseños suelen sacrificar la seguridad y la descentralización para conseguir este efecto escalable, lo que podría tener complejas consecuencias no deseadas para el ecosistema. Un ejemplo es el IBC, que se utiliza para enviar mensajes entre dos cadenas heterogéneas (que tienen garantías de finalidad).

A partir del 14 de septiembre de 2021

 

Además, existen aproximadamente tres tipos de diseños de bridges, que pueden clasificarse en función del mecanismo que se utiliza para validar las transacciones cross-chain:

 

Validadores externos y federaciones

Suele haber un grupo de validadores que supervisan una dirección de “buzón” en la cadena de origen y, tras el consenso, realizan una acción en la cadena de destino. Una transferencia de activos suele realizarse bloqueando el activo en el buzón y minteando la cantidad equivalente de ese activo en la cadena de destino. A menudo se trata de validadores vinculados con un token independiente como modelo de seguridad.

Una ilustración de alto nivel de un validador externo o sistema federado

 

Clientes ligeros y Relays

Los actores supervisan los eventos en la cadena de origen y generan pruebas de inclusión criptográficas sobre los eventos pasados que se registraron en esa cadena. Estas pruebas se envían, junto con las cabeceras de bloques, a los contratos (es decir, el “cliente ligero”) en la cadena de destino, que entonces verifica que un determinado evento fue registrado y ejecuta una acción después de esa verificación. Es necesario que algún actor realice el “retransmita” (relay) las cabeceras de bloque y las pruebas. Aunque es posible que un usuario se “autorremita” (self-relay) las transacciones, existe la suposición de que los relayers reenviarán continuamente los datos. Este es un diseño de bridge relativamente seguro porque garantiza una entrega válida y sin confianza (trustless) en las entidades intermediarias, pero también requiere muchos recursos porque los desarrolladores deben construir un nuevo contrato inteligente en cada nueva cadena de destino que analice las pruebas de estado de la cadena de origen, y la validación en sí misma consume muchos recursos.

 

Una ilustración de alto nivel de un sistema de cliente ligero y/o relay

 

Liquidity Networks

Se trata de una red entre pares en la que cada nodo actúa como un “enrutador” que mantiene un “inventario” de activos tanto de la cadena de origen como de la de destino. Estas redes suelen aprovechar la seguridad de la blockchain subyacente; mediante el uso de mecanismos de bloqueo y disputa, los usuarios tienen la garantía de que los enrutadores no pueden huir con los fondos de los usuarios. Por ello, las redes de liquidez como Connext son probablemente una opción más segura para los usuarios que transfieren grandes cantidades de valor. Además, este tipo de bridge es probablemente el más adecuado para la transferencia de activos a través de la cadena porque los activos proporcionados por los enrutadores son nativos de la cadena de destino en lugar de activos derivados, que no son totalmente fungibles entre sí.

 

Una ilustración de alto nivel de una liquidity network

 

El panorama actual de los bridges podría verse también desde esta perspectiva:

A partir del 14 de septiembre de 2021

Es importante tener en cuenta que cualquier bridge es un canal de comunicación bidireccional que puede tener modelos separados en cada canal y que esta categorización no representa con exactitud modelos híbridos como Gravity, Interlay y tBTC, ya que todos ellos tienen clientes ligeros en una dirección y validadores en otra.

 

Además, se podría evaluar a grandes rasgos el diseño de un bridge según los siguientes factores:

 

    • Seguridad: Supuestos de confianza y liveness, tolerancia a los actores maliciosos, la seguridad de los fondos de los usuarios y la reflexividad.
    • Velocidad: La latencia para completar una transacción, así como las garantías de finalidad. A menudo hay un compromiso entre la velocidad y la seguridad.
  • Conectividad: Selección de cadenas de destino tanto para los usuarios como para los desarrolladores, así como diferentes niveles de dificultad para integrar una cadena de destino adicional.
  • Eficiencia del capital: Economía en torno al capital necesario para asegurar el sistema y los costes de transacción para transferir activos.
  • Capacidad de transferencia de activos: Capacidad de transferir activos específicos, estados más complejos y/o ejecutar llamadas de contratos entre cadenas.

 

En conjunto, se podrían considerar las compensaciones de estos tres diseños desde la siguiente perspectiva:

 

Además, la seguridad se encuentra en un espectro y se podría clasificar a grandes rasgos como:

 

  • Trustless: La seguridad del bridge es igual a la de la(s) cadena(s) de bloques subyacente(s) que puentea. Fuera de los ataques a nivel de consenso en la blockchain subyacente, los fondos de los usuarios no pueden perderse o ser robados. Dicho esto, no hay nada que no sea de confianza porque todos estos sistemas tienen supuestos de confianza en sus componentes económicos, de ingeniería y criptográficos (por ejemplo, no hay errores de código).
  • Asegurado: Los actores maliciosos pueden robar los fondos de los usuarios, pero es probable que no les resulte rentable hacerlo porque se les exige que depositen un colateral y que sean slasheados en caso de error o mal comportamiento. Si los fondos de los usuarios se pierden, se les reembolsará a través de la colateral slasheado.
  • Vinculado: Similar al modelo asegurado (es decir, los actores tienen una participación económica), excepto que los usuarios no recuperan los fondos en caso de error o mal comportamiento porque el colateral slasheado probablemente se queme. El tipo de colateral es importante tanto para el modelo asegurado como para el vinculado; el colateral endógeno (es decir, el colateral es el propio token del protocolo) es más arriesgado porque el valor del token probablemente se desplome si el bridge falla, lo que reduce aún más las garantías de seguridad del bridge.
  • De confianza: Los actores no depositan colaterales y los usuarios no recuperan los fondos en caso de fallo del sistema o de actividad maliciosa, por lo que los usuarios confían principalmente en la reputación del operador del bridge.

 

Resumiendo las ventajas y debilidades de cada diseño

 

Los validadores externos y las federaciones suelen ser excelentes en cuanto a estado y conectividad porque pueden activar transacciones, almacenar datos y permitir interacciones con esos datos en un número arbitrario de cadenas de destino. Sin embargo, esto tiene el coste de la seguridad, ya que los usuarios confían, por definición, en la seguridad del bridge y no en la de las cadenas de origen o destino. Aunque la mayoría de los validadores externos actuales son modelos de confianza, algunos son colateralizados, de los cuales un subconjunto se utiliza para asegurar a los usuarios finales. Desgraciadamente, sus mecanismos de aseguramiento suelen ser reflexivos; si se utiliza un token de protocolo como colateral, se asume que el valor en dólares de ese token será lo suficientemente alto como para que los usuarios queden satisfechos. Además, si el activo colateral es diferente del activo asegurado, también hay una dependencia de la alimentación del precio del oráculo, por lo que la seguridad del bridge podría degradarse a la seguridad del oráculo. 

 

Si no se confía en ellos, estos bridges son también los menos eficientes desde el punto de vista del capital, ya que necesitan escalar las garantías de forma proporcional al rendimiento económico que facilitan.

 

Los clientes y relays también son fuertes con el estado (Statefulness) porque los sistemas de relay de cabecera podrían pasar por cualquier tipo de datos. También son fuertes en cuanto a la seguridad porque no requieren suposiciones adicionales de confianza, aunque hay una suposición de liveness porque todavía se requiere un relayer para transmitir la información. También son los bridges más eficientes desde el punto de vista del capital porque no requieren ningún tipo de bloqueo. Estos puntos fuertes tienen el coste de la conectividad. Para cada par de cadenas, los desarrolladores deben desplegar un nuevo contrato inteligente de cliente ligero tanto en la cadena de origen como en la de destino, lo que tiene una complejidad entre O(LogN) y O(N) (está dentro de este rango porque añadir soporte con cadenas con el mismo algoritmo de consenso es relativamente fácil). También hay importantes inconvenientes de velocidad en los modelos optimistas que dependen de las pruebas de fraude, que podrían aumentar la latencia hasta 4 horas.

Las Liquidity networks brillan por su velocidad y seguridad porque son sistemas verificados localmente (es decir, no requieren un consenso global). También son más eficientes en términos de capital que los validadores externos asegurados, porque la eficiencia del capital está ligada al flujo/volumen de las transacciones más que a la seguridad. Por ejemplo, con flujos algo iguales entre dos cadenas y un mecanismo de reequilibrio incorporado, las redes de liquidez podrían facilitar una cantidad arbitraria de rendimiento económico. La contrapartida está en la maleabilidad, ya que, si bien pueden pasar datos de llamada, su funcionalidad es limitada. Por ejemplo, podrían interactuar con datos a través de cadenas en las que el receptor tiene permiso para realizar la interacción basándose en los datos proporcionados (por ejemplo, llamar a un contrato con un mensaje firmado por el remitente), pero no ayudan a pasar datos que no tienen un “propietario” o que forman parte de un estado generalizado (por ejemplo, acuñar fichas de representación).

 

Cuestiones pendientes

 

Construir bridges robustos entre cadenas es un problema increíblemente difícil en los sistemas distribuidos. Aunque hay mucha actividad en este ámbito, todavía hay varias preguntas sin respuesta:

 

  • Finalidad y retrocesos: ¿Cómo pueden los bridges tener en cuenta los cambios de bloque y los cyber ataques en cadenas con finalidad probabilística? Por ejemplo, ¿Qué le ocurre a un usuario que envió fondos de Polkadot a Ethereum si cualquiera de las dos cadenas experimenta un retroceso de estado?
  • Transferencias NFT y procedencia: ¿Cómo preservan los bridges la procedencia de los NFTs que se transfieren a través de múltiples cadenas? Por ejemplo, si hay un NFT que se compra y se vende a través de mercados en Ethereum, Flow y Solana, ¿Cómo se contabiliza el registro de propiedad de todas esas transacciones y propietarios?
  • Pruebas de estrés: ¿Cómo funcionarán los distintos diseños de bridges en momentos de congestión de la cadena o de ataques a nivel de protocolo y de red?

 

El futuro de los bridges de blockchain

 

Si bien los bridges abren la puerta a la innovación en el ecosistema de la blockchain, también suponen un grave riesgo si los equipos toman atajos en la investigación y el desarrollo. El hackeo de Poly Network ha demostrado la magnitud económica potencial de las vulnerabilidades y los ataques, y probablemente vaya empeorando. Aunque el panorama para los constructores de bridges está muy fragmentado y es muy competitivo, los equipos deben seguir siendo disciplinados a la hora de priorizar la seguridad sobre el tiempo de comercialización.

 

Aunque lo ideal hubiera sido un bridge homogéneo para todo, es probable que no exista un único “mejor” diseño de bridge y que diferentes tipos de bridges sean los más adecuados para aplicaciones específicas (por ejemplo, transferencia de activos, llamadas a contratos, acuñación de tokens).

 

Además, los mejores bridges serán los más seguros, interconectados, rápidos, eficientes en términos de capital, rentables y resistentes a la censura. Estas son las propiedades que hay que maximizar si queremos hacer realidad la visión de una “Internet de blockchain”.

 

Todavía es pronto y es probable que aún no se hayan descubierto los diseños óptimos. La investigación y el desarrollo en todos los tipos de bridges pueden tomar direcciones interesantes:

 

  • Disminución de los costes de verificación de cabeceras: La verificación de las cabeceras de los bloques para los clientes ligeros es costosa, y encontrar formas de reducir esos costes podría acercarnos a una interoperabilidad totalmente generalizada y sin confianza. Un diseño interesante podría ser hacer un bridge a un L2 para disminuir esos costes. Por ejemplo, implementar un cliente ligero Tendermint en zkSync.
  • Pasar de los modelos de confianza a los de enlace: Mientras que los validadores de bonos son mucho menos eficientes en términos de capital, los “contratos sociales” son un mecanismo peligroso para asegurar miles de millones de dólares de fondos de usuarios. Además, los extravagantes esquemas de firma con Umbral no reducen significativamente la confianza en estos sistemas; el hecho de que sea un grupo de firmantes no elimina el hecho de que siga siendo un tercero de confianza. Sin garantías, los usuarios están entregando sus activos a custodios externos.
  • Pasar de los modelos garantizados a los asegurados: Perder dinero es una mala experiencia. Mientras que los validadores y retransmisores con fianza desincentivan los comportamientos maliciosos, los protocolos deberían ir un paso más allá y reembolsar a los usuarios directamente utilizando los fondos recortados.
  • Escalar la liquidez para las redes Liquidity: Podría decirse que son los bridges más rápidos para la transferencia de activos, y hay interesantes compensaciones de diseño entre la confianza y la liquidez. Por ejemplo, es posible permitir que las redes de liquidez externalicen el aprovisionamiento de capital con un modelo de estilo de validador vinculado en el que el enrutador también puede ser un multisig con liquidez vinculada.
  • Agregación de bridges: Aunque el uso de bridges probablemente seguirá una ley de potencia para activos y corredores específicos, los agregadores como Li Finance podrían mejorar la UX tanto para los desarrolladores como para los usuarios finales.

 

Si estás construyendo un bridge cross-chain, ponete en contacto con nosotros.

Autor
CryptoChica

CryptoChica

DeFi Entusiasta Ex Buenbit MasterShiller en DeFi_LATAM