Ir al contenido

Wormhole (criptomoneda)

De BitcoinWiki

Wormhole es un protocolo de interoperabilidad para enviar mensajes entre redes de cadenas de bloques que, de otro modo, estarían separadas. Las aplicaciones pueden utilizar estos mensajes para transferencias de tokens, gobernanza entre cadenas, entrega de datos y otras operaciones. Wormhole no es una cadena de bloques y el protocolo es distinto de W, el token presentado para su ecosistema de gobernanza en 2024.[1][2]

Wormhole crypto protocol connecting blockchain networks for asset transfer.
Illustration of the Wormhole protocol bridging blockchains.

El principal mecanismo de seguridad del protocolo es un conjunto de operadores independientes denominados Guardians. Estos observan los mensajes emitidos por los contratos de Wormhole y firman certificaciones llamadas Verifiable Action Approvals (VAA). Una VAA estándar se acepta después de que la hayan firmado 13 de los 19 Guardians.[3] Se trata de un modelo de certificación por umbral, no de una nueva capa de consenso compartida por las cadenas de bloques conectadas.

Historia

Wormhole comenzó en 2020 como un puente de tokens entre Ethereum y Solana. El proyecto recibió financiación parcial mediante una subvención de Solana Foundation. Más adelante evolucionó desde aquel puente original hasta convertirse en un protocolo general de transmisión de mensajes y en un conjunto de productos construidos sobre él.[4]

El modelo de puente original continúa siendo uno de los usos de Wormhole, pero ya no describe todo el sistema. El protocolo puede transportar datos definidos por una aplicación, y el contrato de la aplicación receptora determina qué acción se ejecuta en la cadena de destino.[1][3]

Arquitectura y flujo de mensajes

Un mensaje básico de Wormhole pasa por cuatro etapas:[1]

  1. Un contrato de la cadena de origen llama al Wormhole Core Contract de esa cadena, que registra el mensaje en los registros de transacciones.
  2. Los Guardians observan y firman el mensaje. Cuando se alcanza el umbral requerido, sus firmas y el cuerpo del mensaje se combinan en una VAA.
  3. Un relayer, una aplicación o un usuario obtiene la VAA y la presenta en otra cadena.
  4. Un contrato receptor solicita a su Wormhole Core Contract local que verifique la VAA; después interpreta la carga útil y aplica las reglas de la aplicación.

Una VAA contiene un identificador de la cadena y del contrato emisores, un número de secuencia, un nivel de consistencia y una carga útil definida por la aplicación. No incluye un destino en el nivel del protocolo, por lo que un mismo mensaje aprobado puede presentarse, en principio, en más de una cadena. La aplicación receptora debe comprobar que la VAA procede del emisor esperado y que su carga útil es válida para la acción prevista.[3]

Los relayers transportan mensajes firmados; no deciden si un mensaje es auténtico. El Core Contract receptor rechaza una VAA que no tenga suficientes firmas válidas de Guardians. No obstante, un relayer puede afectar a la disponibilidad retrasando un mensaje o dejando de entregarlo.[5]

Guardians y finalidad

En las cadenas configuradas para observación completa, todos los Guardians ejecutan nodos de forma independiente y vigilan los eventos de los contratos de Wormhole. En las cadenas con observación delegada, un subconjunto configurado observa la cadena de origen e informa a los demás Guardians. La VAA definitiva sigue necesitando 13 firmas del conjunto canónico de 19 Guardians, pero la observación delegada añade un supuesto de confianza específico de cada cadena, porque no todos los firmantes la observaron directamente.[1][5]

Antes de firmar, los Guardians siguen el nivel de consistencia seleccionado para cada mensaje. Un mensaje producido antes de que exista una finalidad sólida puede verse afectado por una reorganización posterior de la cadena. Por tanto, Wormhole no puede proporcionar a un mensaje una finalidad mayor que la ofrecida por la cadena de origen y la política de confirmación elegida.[3]

Transferencias de tokens

La documentación de Wormhole distingue dos métodos para transferir tokens. Wrapped Token Transfers (WTT), denominado Token Bridge en los contratos y en el kit de desarrollo de software, utiliza generalmente un modelo de bloqueo y emisión. Un contrato de la cadena de origen bloquea un token nativo o quema una representación envuelta existente. Los Guardians certifican el evento y el contrato de destino emite una representación envuelta o libera el activo nativo correspondiente. Una transferencia de regreso invierte la operación aplicable.[6]

Native Token Transfers (NTT) es un marco para emisores que desean disponer de representaciones nativas en varias cadenas. El emisor puede utilizar un modelo de quema y emisión o de custodia radial, al tiempo que conserva el control de los contratos y de la configuración de sus tokens. Por ello, NTT no exige que todas las representaciones de destino sean tokens envueltos controlados por Wormhole.[6]

Ambos métodos utilizan mensajes de Wormhole, pero sus supuestos sobre custodia, capacidad de actualización, límites de flujo y confianza en el emisor pueden ser distintos. Una VAA demuestra que el umbral de Guardians aprobó un mensaje; no determina el valor económico de un token, la seguridad de una aplicación integrada ni la legitimidad del nombre de un activo mostrado.

Modelo de seguridad

La regla de verificación estándar de Wormhole presupone que menos de 13 Guardians no aprobarán un mensaje falso. También depende de que los Core Contracts y los contratos de las aplicaciones sean correctos, de la seguridad de las claves de los Guardians, de la finalidad de la cadena de origen y de que la aplicación receptora valide los emisores y las cargas útiles. Las configuraciones con observación delegada añaden a estos supuestos el umbral y el comportamiento del subconjunto de observadores correspondiente.[5]

Históricamente, las actualizaciones y los cambios de configuración de los Core Contracts se han autorizado mediante mensajes de gobernanza firmados por los Guardians. El mismo modelo de umbral permite cambiar el conjunto de Guardians, actualizar contratos y configurar la observación delegada. Por ello, describir Wormhole únicamente como un puente descentralizado oculta límites importantes de gobernanza y confianza.[5]

Wormhole añadió posteriormente salvaguardas para las transferencias de activos. El Global Accountant registra la oferta circulante de los activos transferidos mediante puentes y bloquea las transferencias que incumplirían su invariante contable. El Governor controla el valor que sale de las cadenas compatibles y puede retrasar transferencias que superen los límites configurados.[5] Son mecanismos de defensa en profundidad: pueden limitar ciertos fallos o ralentizar salidas sospechosas, pero no eliminan los errores de contratos, la pérdida de claves, el riesgo de gobernanza, los fallos de la cadena de origen ni los errores de las aplicaciones construidas sobre el protocolo.

Ataque de 2022

El 2 de febrero de 2022, un atacante aprovechó una vulnerabilidad de la implementación del puente de Wormhole en Solana. El programa no validaba correctamente una cuenta del sistema proporcionada durante la verificación de firmas. Como consecuencia, el atacante eludió la comprobación prevista de las firmas de los Guardians y emitió 120 000 ETH envueltos por Wormhole en Solana sin un depósito de ETH correspondiente.[7]

El atacante transfirió 93 750 ETH a Ethereum y conservó o intercambió el resto en Solana. En ese momento, los activos tenían un valor aproximado de 325 millones de dólares estadounidenses.[8] El incidente se debió a una verificación defectuosa del programa de Solana, no a la vulneración de 13 claves de Guardians. Jump Crypto compró y proporcionó posteriormente 120 000 ETH para restablecer el respaldo del puente.[9]

El suceso ilustra una limitación más general de los sistemas entre cadenas: un contrato de destino puede aceptar un mensaje firmado o aparentemente verificado cuando su implementación de verificación es defectuosa. Los operadores por umbral y los controles contables no sustituyen al código correcto en cada entorno de ejecución compatible.

Token W y gobernanza

Wormhole lanzó el token W en abril de 2024. Su oferta máxima declarada es de 10 000 millones, de los cuales 1 800 millones estaban inicialmente en circulación. W se emitió como token SPL de Solana y como representaciones ERC-20 nativas en varias redes EVM, conectadas mediante NTT.[2][10]

W está destinado al staking, la delegación y la participación progresiva en la gobernanza de Wormhole. Esta función es distinta de la gobernanza existente de los Core Contracts por parte de los Guardians. Los materiales sobre la economía del token de Wormhole describen una transferencia paulatina de más responsabilidades a la gobernanza de los titulares, mientras que la documentación actual del protocolo continúa atribuyendo a los Guardians la aprobación de las actualizaciones y configuraciones centrales.[2][5] No es necesario poseer W para limitarse a retransmitir una VAA o utilizar una aplicación que integre Wormhole.

Redes compatibles y límites operativos

La compatibilidad con redes es un estado operativo, no una propiedad permanente del protocolo. Wormhole ha añadido y retirado cadenas, y una interfaz puede dejar de mostrar una cadena con independencia de que sigan existiendo contratos o relayers de terceros.[11] Por tanto, usuarios e integradores necesitan documentación actualizada sobre direcciones de contratos, redes compatibles, finalidad y aplicaciones, en lugar de una lista antigua de nombres de cadenas.

Las operaciones entre cadenas también exigen transacciones en más de una red. Las comisiones, el tiempo de finalización, la finalidad, la representación de tokens, los límites de flujo y los procedimientos de recuperación dependen de la cadena de origen, la cadena de destino, el producto de transferencia, el relayer y la aplicación integrada. Una verificación correcta de Wormhole no garantiza que una ruta sea económica, líquida, reversible o adecuada para el propósito del usuario.

Referencias

  1. 1,0 1,1 1,2 1,3 Architecture, Wormhole documentation, accessed 3 September 2026.
  2. 2,0 2,1 2,2 Wormhole (W) tokenomics, Wormhole, 7 February 2024, accessed 3 September 2026.
  3. 3,0 3,1 3,2 3,3 Verifiable Action Approvals, Wormhole documentation, accessed 3 September 2026.
  4. Wormhole platform roadmap, Wormhole, 14 August 2024, accessed 3 September 2026.
  5. 5,0 5,1 5,2 5,3 5,4 5,5 Security, Wormhole documentation, accessed 3 September 2026.
  6. 6,0 6,1 Token Transfers Overview, Wormhole documentation, accessed 3 September 2026.
  7. Wormhole Bridge Exploit Incident Analysis, CertiK, 1 August 2022, accessed 3 September 2026.
  8. $325 Million Stolen from Wormhole DeFi Service, Elliptic, 2 February 2022, accessed 3 September 2026.
  9. Podcast Summary: Into the Wormhole, Jump Crypto, 11 February 2022, accessed 3 September 2026.
  10. W is now natively multichain on Ethereum and layer-2s, Wormhole, 25 April 2024, accessed 3 September 2026.
  11. Updates to Wormhole's supported networks, Wormhole, updated 7 August 2026, accessed 3 September 2026.