tl;dr

  • Cada diseño de puente tiene una mezcla de compromisos en seguridad, velocidad e implementación.
  • De forma similar al trilema de la escalabilidad para las blockchains, existe un trilema de la interoperabilidad para los puentes.
  • Los puentes entre blockchains son aplicaciones con riesgos; más de 1.500 millones de USD han sido robados en los últimos meses.

Introducción

En el primer artículo sobre puentes entre blockchains, explicamos qué es un puente, para qué sirve y qué tipos de diseños existen. Hoy en día, todavía no existe la elección perfecta, por lo que siempre hay que tomar ciertos compromisos y sacrificar algunas propiedades a cambio de otras. Las aplicaciones de puentes entre blockchains copan los primeros puestos de la lista de hackeos en DeFi; es por ello que antes de realizar una transferencia entre blockchains, hay que tener en cuenta el diseño y las propiedades de cada puente. En este segundo artículo explicamos cómo evaluarlos, los sacrificios que hay que tomar y qué riesgos existen.

Evaluación de puentes

Se puede evaluar de forma simplificada un puente acorde a los siguientes factores:

Seguridad: hace referencia a la suposición de confianza, la tolerancia a actores maliciosos y la seguridad de los fondos de los usuarios. Es decir, cómo de seguro está la blockchain de destino que el mensaje recibido es válido.

Velocidad: latencia para completar una transacción (cuánto tarda en llegar un mensaje entre blockchains) y la garantía de finalidad. Normalmente, hay un sacrificio entre velocidad y seguridad.

Conectividad: se refiere a cómo de difícil es integrar blockchains de destino adicionales.

Eficiencia de capital: la economía para asegurar el sistema de transferencia (cuánto gas se necesita para construir el canal y mantenerlo) y los costes de transacción para transferir activos. Por ejemplo, el mantenimiento de los relayers de block headers desplegados en Ethereum suelen tener un coste alto.

Statefulness: habilidad para transferir activos específicos, estados más complejos y/o la ejecución de llamadas a contratos cross-chain.

De estas propiedades, la seguridad es, quizás, el punto más importante. Existe un espectro de niveles de seguridad que se puede dividir en cuatro categorías (en la figura 1 podemos ver cómo se clasifican algunos de los puentes actuales):

Trustless: la seguridad del puente es igual a la de las blockchains en las que se realiza la transferencia. Más allá de ataques al mecanismo de consenso de las blockchains, los fondos de los usuarios no pueden ser robados. Dicho esto, nada es completamente trustless, ya que todos los sistemas tienen alguna suposición de confianza ya sea de tipo económica, criptográfica, de componentes (p.ej.: códigos sin bugs), etc.

Si se quiere profundizar más en el concepto de trustless en el diseño de puentes, este artículo de LI.FI (un agregador de puentes) ofrece una explicación detallada.

Asegurado: los actores maliciosos pueden robar los fondos de los usuarios, aunque, probablemente, no sea rentable para ellos ya que deben tener un colateral depositado que puede ser parcial o totalmente requisado en caso de error o mal comportamiento. Si los usuarios perdieran sus activos, se les reembolsaría utilizando este valor requisado.

Vinculado: funciona de forma similar al modelo asegurado (es decir, los validadores arriesgan parte de su capital), excepto que en este caso los usuarios no recuperan los activos perdidos ya que el colateral requisado se quema. El tipo de colateral es importante tanto para este modelo como para el modelo asegurado ya que se asume mayor riesgo por parte del usuario si el colateral utilizado es el propio token del protocolo. Si el puente fallara, el valor del token bajaría, y consecuentemente, se reduciría la seguridad de garantía del puente.

Trusted: los actores no depositan ningún colateral y los usuarios no recuperan sus activos en caso de fallo o actividad maliciosa, por lo que los usuarios confían en la reputación y buen hacer del operador del puente. Mustafa Al-Bassam, fundador de Celestia, declaró que “los operadores de los puentes entre blockchains basados en la confianza pueden robar los fondos de los usuarios. Esto se debe a que este tipo de puentes no verifican las transiciones de estado de las blockchains, si no que dependen de un conjunto de validadores para firmar las transacciones. Es el caso del puente Wormhole entre Ethereum y Solana”.

Figura 1. Clasificación de puentes según el tipo de seguridad. Fuente

Al igual que en el diseño de blockchains, cada puente debe elegir qué está dispuesto a sacrificar en beneficio de ciertas propiedades.

Compromisos

Análisis de compromisos

Si tomamos los tres diseños basados en el mecanismo para validar las transacciones (explicado en el primer artículo sobre puentes) y evaluamos de forma conjunta sus propiedades, obtenemos la visualización de la figura 2:

Figura 2. Compromisos de las propiedades de un puente. Fuente

 

¡Alerta, spoiler! No se puede tener todo.

  • Verificación nativa: light clients & relays

En este tipo de puentes los relayers pueden transmitir cualquier tipo de datos así que statefulness es una de sus características más importantes. De igual forma, la seguridad es otro de sus puentos fuertes ya que no necesitan suposiciones de confianza adicionales (pese a que sigue existiendo una confianza en que los relayers mantengan la transmisión de información de forma constante).

Estas fortalezas se dan a cambio de la conectividad; para cada puente entre dos blockchains concretas, se debe desplegar un nuevo smart contract tanto en la blockchain de origen como en la de destino. Además, en ciertas ocasiones, hay un sacrificio en la velocidad de transferencia en los modelos optimistas, ya que dependen de pruebas de fraude (fraud proofs).

  • Externamente: validadores externos y federaciones

La conectividad y statefulness son las propiedades que destacan en este tipo de diseños ya que se pueden realizar transacciones y almacenar datos en varias blockchains de destino. Por el contrario, la seguridad no depende de las blockchains en las que trabaja, si no de la propiedad seguridad del puente. La seguridad de este tipo de puentes suele ser de tipo trusted o asegurada/vinculada. En este último caso, el colateral usado como seguro suele ser el propio token del puente (es decir, la seguridad se ve socavada y altamente dependiente de su precio) o, si se trata de otro token, dependerá del oráculo de precios; así que la seguridad del puente dependerá de la seguridad del oráculo.

  • Localmente: redes de liquidez

Los puentes fuertes de este tipo de diseño son la velocidad y la seguridad ya que, como explicamos en el artículo anterior, son sistemas verificados de forma local. Son más eficientes en capital que los de verificación externa con seguridad asegurada/vinculada porque el capital está ligado al volumen de transacción y no a su seguridad. Su punto más débil es el de statefulness ya que tienen una funcionalidad limitada.

Algunos ejemplos de puentes

IBC utiliza un modelo de verificación nativa:

Tarda pocos segundos en transmitir mensajes entre blockchains y es un puente seguro (siempre que la blockchain de origen sea segura y no se haya visto comprometida o los validadores hayan defraudado). Por el contrario, es un puente complejo y su conectividad se ve afectada. Si bien se puede considerar que es eficiente en capital, existen algunos costes para procesar los block headers. Su statefulness es alta siempre que sea dentro del ecosistema de Cosmos.

Puentes con seguridad trusted, como por ejemplo el de Binance:

Son muy poco seguros ya que el custodio de los activos de los usuarios puede hacer que se reciba cualquier mensaje en la blockchain de destino (podría llevarse nuestros activos o enviar mensajes a smart contracts que, en realidad, no se enviaron). Sus puntos fuertes es que son baratos y muy rápidos. A su vez, se pueden reusar fácilmente ya que se trata de un diseño simple (alguien firmando mensajes), así que puede implementarse en cualquier blockchain.

A tener en cuenta antes de usar un puente

Riesgos y problemas

Los puentes entre blockchains están en una etapa temprana de desarrollo y la interacción con cualquiera de ellos conlleva multitud de riesgos. Existen una serie de riesgos y problemas que el usuario debe tener en cuenta antes de usar el puente:

  • Puede haber un bug en el smart contract del puente y que se pierdan los fondos del usuario.
  • El usuario puede cometer un error al usar el puente. Por ejemplo, enviar fondos a una blockchain en la que no tenga el token nativo para pagar el gas.
  • La blockchain de origen puede ser atacada (ataques económicos o del 51%). Por ejemplo, transferimos 10 ETH desde Ethereum a otra blockchain y obtenemos 10 wETH. Tan pronto la blockchain de destino confirma la transacción, el atacante puede revertir la transacción en Ethereum mediante un ataque del 51% y dejar el wETH sin colateral (este es un ejemplo exagerado, nadie realizaría un ataque del 51% para robar 10 ETH). Este efecto se multiplica conforme haya más blockchains. De ahí que sea más seguro tener tokens nativos de cada blockchain y no mezclarlos.
  • Puede que los operadores del puente sean maliciosos (en el caso de puentes trusted), así que existe riesgo de censura o riesgo en la custodia de los activos del usuario.
  • El puente puede ser hackeado. En la siguiente sección exponemos una lista de hackeos a puentes.
  • En el caso de los puentes que utilizan MPC (uno de los sistemas de validación externa) no sería posible saber quién fue el actor malicioso causante del ataque.
  • Pérdida del peg sobre el token nativo. Por ejemplo, el valor de wBTC podría perder el peg (aunque fuera de forma temporal) con BTC si hubiera algún evento en la blockchain de Ethereum que lo causara.
  • Fragmentación de liquidez. Cada puente tiene su conjunto de smart contracts, lo que hace que un activo esté vinculado al puente. Como vemos en la imagen de la figura 3, dos tokens que se transfieren desde la blockchain A a la blockchain B a través de puentes diferentes son tokens diferentes en la blockchain de destino ya que tienen un contrato ERC20 diferente, y por lo tanto, no son fungibles. Esto crea una experiencia de usuario muy mala y existe el riesgo que un token concreto de un puente tenga muy poca liquidez en la blockchain de destino. La evolución natural para este problema parece ser la especialización de ciertos activos en determinados puentes, de tal forma que el usuario utilice uno u otro puente en función del activo que quiera transferir. Por ejemplo, wBTC es, de facto, el token principal de representación de BTC en la red de Ethereum.

Figura 3. Fragmentación de liquidez. Fuente

El trilema del puente

Todo esto nos lleva al trilema de la interoperabilidad o del puente (vemos una representación gráfica en la figura 4). De forma similar al trilema de la escalabilidad, los puentes entre blockchains deben hacer un compromiso de funcionalidad pudiendo obtener sólo dos de estas tres características:

  • Finalidad instantánea garantizada: garantía de los fondos en la blockchain de destino (siempre que haya liquidez) cuando una transacción se ha realizado de forma exitosa en la blockchain de origen.
  • Liquidez unificada: acceso compartido a un solo pool de liquidez entre varias blockchains.
  • Transacciones de activos nativos: los activos que el usuario prefiera (nativos o el sintético más líquido) en la blockchain de destino.

Recientemente, han surgido algunos puentes como Stargate, construido sobre LayerZero, que afirman haber resuelto el trilema.

Figura 4. Trilema del puente. Fuente

Hackeos

Es importante mencionar que los hackeos más cuantiosos en DeFi se han dado en puentes entre blockchains, lo cual demuestra porque la seguridad es esencial:

Camino a la descentralización

Como hemos mencionado previamente, los puentes entre blockchains todavía están en una etapa inicial y tienen muchos aspectos a mejorar, pero es evidente que hay una necesidad por la interoperabilidad. El desarrollo futuro, probablemente, se centre en mejorar la seguridad (pasando de modelos trusted a trustless o en los que los validadores arriesguen parte de su capital) y en unificar la liquidez en las blockchains de destino.

Auditorías y programas de recompensas a hackers de sombrero blanco son algunas de las medidas preventivas que cualquier protocolo DeFi debe seguir, y de igual forma, los puentes entre blockchains. Pese a que los puentes descentralizados y permissionless son los más complicados de construir, y que no es totalmente descartable que un puente centralizado y con baja seguridad acabe convirtiéndose en el diseño habitual, todavía existen mucho proyectos con la mentalidad de construir puentes seguros y bien diseñados.

 

Referencias