Saltar al contenido principal

7 publicaciones etiquetados con "seguridad"

Ver Todas las Etiquetas

La Revolución de la Infraestructura WaaS: Cómo las Billeteras Integradas Están Remodelando la Adopción de Web3

· 49 min de lectura
Dora Noda
Software Engineer

Wallet-as-a-Service ha surgido como la capa de infraestructura crítica que faltaba para permitir la adopción masiva de Web3. El mercado está experimentando un crecimiento anual compuesto explosivo del 30 % hacia los $50 mil millones para 2033, impulsado por tres fuerzas convergentes: la abstracción de cuentas que elimina las frases semilla, la computación multipartita que resuelve el trilema de la custodia y los patrones de inicio de sesión social que unen Web2 con Web3. Con 103 millones de operaciones de cuentas inteligentes ejecutadas en 2024 —un aumento del 1.140 % desde 2023— y adquisiciones importantes, incluida la compra de Privy por parte de Stripe y la adquisición de Dynamic por $90 millones por parte de Fireblocks, el panorama de la infraestructura ha alcanzado un punto de inflexión. WaaS ahora impulsa todo, desde la economía play-to-earn de Axie Infinity (que atiende a millones en Filipinas) hasta el mercado de $500 millones de NBA Top Shot, mientras que actores institucionales como Fireblocks aseguran más de $10 billones en transferencias de activos digitales anualmente. Esta investigación proporciona inteligencia procesable para los desarrolladores que navegan por el complejo panorama de los modelos de seguridad, los marcos regulatorios, el soporte de blockchain y las innovaciones emergentes que están remodelando la infraestructura de activos digitales.

Arquitectura de seguridad: MPC y TEE emergen como el estándar de oro

La base técnica de WaaS moderno gira en torno a tres paradigmas arquitectónicos, con la computación multipartita combinada con entornos de ejecución confiables que representan el ápice de seguridad actual. El algoritmo MPC-CMP de Fireblocks ofrece mejoras de velocidad 8 veces mayores que los enfoques tradicionales, al tiempo que distribuye las partes de la clave entre múltiples partes; la clave privada completa nunca existe en ningún momento durante la generación, el almacenamiento o la firma. La arquitectura totalmente basada en TEE de Turnkey, que utiliza AWS Nitro Enclaves, va más allá, con cinco aplicaciones de enclave especializadas escritas completamente en Rust que operan bajo un modelo de confianza cero donde incluso la base de datos se considera no confiable.

Las métricas de rendimiento validan este enfoque. Los protocolos MPC modernos logran una latencia de firma de 100-500 milisegundos para firmas de umbral 2 de 3, lo que permite experiencias de grado de consumidor mientras se mantiene la seguridad institucional. Fireblocks procesa millones de operaciones diariamente, mientras que Turnkey garantiza un tiempo de actividad del 99,9 % con firma de transacciones en menos de un segundo. Esto representa un salto cuántico con respecto a los enfoques tradicionales solo con HSM, que crean puntos únicos de falla a pesar de la protección a nivel de hardware.

Las billeteras de contrato inteligente a través de ERC-4337 presentan un paradigma complementario centrado en la programabilidad sobre la gestión distribuida de claves. Los 103 millones de UserOperations ejecutados en 2024 demuestran una tracción real, con un 87 % utilizando Paymasters para patrocinar las tarifas de gas, abordando directamente la fricción de incorporación que ha afectado a Web3. Alchemy implementó el 58 % de las nuevas cuentas inteligentes, mientras que Coinbase procesó más de 30 millones de UserOps, principalmente en Base. El pico de agosto de 2024 de 18,4 millones de operaciones mensuales indica una creciente preparación para la adopción masiva, aunque los 4,3 millones de usuarios recurrentes indican que persisten los desafíos de retención.

Cada arquitectura presenta distintas compensaciones. Las billeteras MPC ofrecen soporte universal de blockchain a través de la firma basada en curvas, apareciendo como firmas únicas estándar en la cadena con una sobrecarga mínima de gas. Las billeteras de contrato inteligente permiten funciones sofisticadas como la recuperación social, las claves de sesión y las transacciones por lotes, pero incurren en mayores costos de gas y requieren implementaciones específicas de la cadena. Los enfoques tradicionales de HSM, como la integración de AWS KMS de Magic, proporcionan una infraestructura de seguridad probada en batalla, pero introducen suposiciones de confianza centralizada incompatibles con los verdaderos requisitos de autocustodia.

La comparación del modelo de seguridad revela por qué las empresas prefieren MPC-TSS combinado con protección TEE. La arquitectura de Turnkey con atestación criptográfica para todo el código de enclave garantiza propiedades de seguridad verificables imposibles con las implementaciones tradicionales en la nube. El enfoque de red distribuida de Web3Auth divide las claves entre los nodos de Torus Network y los dispositivos de los usuarios, logrando una seguridad no custodial a través de la confianza distribuida en lugar del aislamiento de hardware. El TSS-MPC de Dynamic con configuraciones de umbral flexibles permite un ajuste dinámico de 2 de 3 a 3 de 5 sin cambios de dirección, proporcionando la flexibilidad operativa que requieren las empresas.

Los mecanismos de recuperación de claves han evolucionado más allá de las frases semilla hacia sofisticados sistemas de recuperación social y copia de seguridad automatizada. RecoveryHub de Safe implementa la recuperación de guardianes basada en contratos inteligentes con retrasos de tiempo configurables, lo que admite configuraciones de autocustodia con billeteras de hardware o recuperación institucional de terceros a través de socios como Coincover y Sygnum. La recuperación social fuera de la cadena de Web3Auth evita por completo los costos de gas al tiempo que permite la reconstrucción de la parte del dispositivo más la parte del guardián. Las copias de seguridad verificables públicamente de Coinbase utilizan pruebas criptográficas que garantizan la integridad de la copia de seguridad antes de habilitar las transacciones, lo que evita los escenarios de pérdida catastrófica que afectaron a las primeras soluciones de custodia.

Las vulnerabilidades de seguridad en el panorama de amenazas de 2024 subrayan por qué los enfoques de defensa en profundidad no son negociables. Con 44.077 CVEs divulgados en 2024 —un aumento del 33 % desde 2023— y una explotación promedio que ocurre solo 5 días después de la divulgación, la infraestructura WaaS debe anticipar la evolución constante del adversario. Los ataques de compromiso de frontend como el robo de $120 millones de BadgerDAO a través de la inyección de scripts maliciosos demuestran por qué la autenticación basada en TEE de Turnkey elimina por completo la confianza en la capa de la aplicación web. La aplicación falsa de WalletConnect que robó $70.000 a través de la suplantación de Google Play destaca los requisitos de verificación a nivel de protocolo, ahora estándar en las implementaciones líderes.

Panorama del mercado: La consolidación se acelera a medida que entran los gigantes de Web2

El ecosistema de proveedores de WaaS se ha cristalizado en torno a distintas estrategias de posicionamiento, con la adquisición de Privy por parte de Stripe y la compra de Dynamic por $90 millones por parte de Fireblocks señalando la fase de maduración donde los compradores estratégicos consolidan capacidades. El mercado ahora se segmenta claramente entre proveedores centrados en instituciones que enfatizan la seguridad y el cumplimiento, y soluciones orientadas al consumidor que optimizan la incorporación sin problemas y los patrones de integración de Web2.

Fireblocks domina el segmento institucional con una valoración de $8 mil millones y más de $1 billón en activos asegurados anualmente, sirviendo a más de 500 clientes institucionales, incluidos bancos, exchanges y fondos de cobertura. La adquisición de Dynamic por parte de la compañía representa una integración vertical desde la infraestructura de custodia hasta las billeteras integradas orientadas al consumidor, creando una solución de pila completa que abarca desde la gestión de tesorería empresarial hasta las aplicaciones minoristas. La tecnología MPC-CMP de Fireblocks asegura más de 130 millones de billeteras con certificación SOC 2 Tipo II y pólizas de seguro que cubren activos en almacenamiento y tránsito, requisitos críticos para las instituciones financieras reguladas.

La trayectoria de Privy, de $40 millones en financiación a la adquisición por parte de Stripe, ejemplifica el camino de la billetera de consumo. Con soporte para 75 millones de billeteras en más de 1.000 equipos de desarrolladores antes de la adquisición, Privy se destacó en la integración centrada en React con patrones de inicio de sesión por correo electrónico y social familiares para los desarrolladores de Web2. La integración de Stripe sigue a su adquisición de Bridge por $1.1 mil millones para infraestructura de stablecoins, lo que indica una pila completa de pagos criptográficos que combina rampas de entrada fiat, stablecoins y billeteras integradas. Esta integración vertical refleja la estrategia de Coinbase con su L2 Base más la infraestructura de billetera integrada dirigida a "cientos de millones de usuarios".

Turnkey se diferenció a través de una infraestructura de código abierto, primero para desarrolladores, con seguridad AWS Nitro Enclave. Recaudando más de $50 millones, incluida una Serie B de $30 millones de Bain Capital Crypto, Turnkey impulsa Polymarket, Magic Eden, Alchemy y Worldcoin con firma en menos de un segundo y garantías de tiempo de actividad del 99,9 %. El QuorumOS de código abierto y el completo conjunto de SDK atraen a los desarrolladores que crean experiencias personalizadas que requieren control a nivel de infraestructura en lugar de componentes de interfaz de usuario con opiniones.

Web3Auth logra una escala notable con más de 20 millones de usuarios activos mensuales en más de 10.000 aplicaciones, aprovechando una arquitectura agnóstica de blockchain que admite más de 19 proveedores de inicio de sesión social. El enfoque MPC distribuido con claves divididas entre los nodos de Torus Network y los dispositivos de los usuarios permite billeteras verdaderamente no custodiales mientras se mantienen los patrones de UX de Web2. Con un costo de $69 mensuales para el plan Growth frente a los $499 de Magic para características comparables, Web3Auth apunta a la adopción impulsada por los desarrolladores a través de precios agresivos y soporte integral de la plataforma, incluidos Unity y Unreal Engine para juegos.

Dfns representa la estrategia de especialización en fintech, asociándose con Fidelity International, Zodia Custody de Standard Chartered y Tungsten Custody de ADQ. Su Serie A de $16 millones en enero de 2025 de Further Ventures/ADQ valida el enfoque de banca institucional, con alineación regulatoria con DORA de la UE y FISMA de EE. UU., además de la certificación SOC-2 Tipo II. Con soporte para más de 40 blockchains, incluidas las cadenas del ecosistema Cosmos, Dfns procesa más de $1 mil millones de volumen de transacciones mensuales con un crecimiento interanual del 300 % desde 2021.

El enfoque de abstracción de cadena de pila completa de Particle Network se diferencia a través de Cuentas Universales que proporcionan una única dirección en más de 65 blockchains con enrutamiento automático de liquidez entre cadenas. La blockchain modular L1 (Particle Chain) coordina las operaciones multicadena, lo que permite a los usuarios gastar activos en cualquier cadena sin puentes manuales. BTC Connect se lanzó como la primera implementación de abstracción de cuentas de Bitcoin, demostrando innovación técnica más allá de las soluciones centradas en Ethereum.

El panorama de financiación revela la convicción de los inversores en la infraestructura WaaS como bloques de construcción fundamentales de Web3. Fireblocks recaudó $1.04 mil millones en seis rondas, incluida una Serie E de $550 millones con una valoración de $8 mil millones, respaldada por Sequoia Capital, Paradigm y D1 Capital Partners. Turnkey, Privy, Dynamic, Portal y Dfns recaudaron colectivamente más de $150 millones en 2024-2025, con inversores de primer nivel como a16z crypto, Bain Capital Crypto, Ribbit Capital y Coinbase Ventures participando en múltiples acuerdos.

La actividad de asociación indica la maduración del ecosistema. La asociación Digital Asset Haven de IBM con Dfns se enfoca en la gestión del ciclo de vida de las transacciones para bancos y gobiernos en 40 blockchains. La integración de McDonald's con Web3Auth para coleccionables NFT (2.000 NFTs reclamados en 15 minutos) demuestra la adopción de grandes marcas de Web2. El soporte de Biconomy para Dynamic, Particle, Privy, Magic, Dfns, Capsule, Turnkey y Web3Auth muestra que los proveedores de infraestructura de abstracción de cuentas permiten la interoperabilidad entre soluciones de billetera competidoras.

Experiencia del desarrollador: El tiempo de integración se reduce de meses a horas

La revolución de la experiencia del desarrollador en WaaS se manifiesta a través de la disponibilidad integral de SDK, con Web3Auth liderando con soporte para más de 13 frameworks, incluidos JavaScript, React, Next.js, Vue, Angular, Android, iOS, React Native, Flutter, Unity y Unreal Engine. Esta amplitud de plataforma permite experiencias de billetera idénticas en entornos web, móviles nativos y de juegos, algo crítico para aplicaciones que abarcan múltiples superficies. Privy se enfoca más estrechamente en el dominio del ecosistema React con soporte para Next.js y Expo, aceptando limitaciones de framework para una calidad de integración más profunda dentro de esa pila.

Las afirmaciones de tiempo de integración de los principales proveedores sugieren que la infraestructura ha alcanzado la madurez plug-and-play. Web3Auth documenta una integración básica de 15 minutos con 4 líneas de código, validada a través de herramientas de creación de integración que generan código listo para implementar. Privy y Dynamic anuncian plazos similares para aplicaciones basadas en React, mientras que la herramienta de andamiaje npx make-magic de Magic acelera la configuración del proyecto. Solo Fireblocks y Turnkey, centrados en empresas, citan plazos de días a semanas, lo que refleja los requisitos de implementación personalizada para los motores de políticas institucionales y los marcos de cumplimiento en lugar de las limitaciones del SDK.

El diseño de la API convergió en arquitecturas RESTful en lugar de GraphQL, con notificaciones de eventos basadas en webhooks que reemplazan las conexiones persistentes de WebSocket en los principales proveedores. El modelo de API basado en actividades de Turnkey trata todas las acciones como actividades que fluyen a través de un motor de políticas, lo que permite permisos granulares y registros de auditoría completos. Los endpoints RESTful de Web3Auth se integran con Auth0, AWS Cognito y Firebase para la identidad federada, lo que admite la autenticación JWT personalizada para escenarios de "traiga su propia autenticación". La configuración basada en el entorno de Dynamic a través de un panel de desarrollador equilibra la facilidad de uso con la flexibilidad para implementaciones multi-entorno.

La calidad de la documentación separa a los proveedores líderes de la competencia. El constructor de integración de Web3Auth genera código de inicio específico del framework, lo que reduce la carga cognitiva para los desarrolladores no familiarizados con los patrones de Web3. La estructura de documentación lista para IA de Turnkey optimiza la ingesta de LLM, lo que permite a los desarrolladores que usan Cursor o GPT-4 recibir orientación precisa sobre la implementación. Las demostraciones de CodeSandbox de Dynamic y los múltiples ejemplos de frameworks proporcionan referencias de trabajo. Las plantillas de inicio y las aplicaciones de demostración de Privy aceleran la integración de React, aunque son menos completas que las de los competidores agnósticos de blockchain.

Las opciones de flujo de incorporación revelan un posicionamiento estratégico a través del énfasis en el método de autenticación. Los más de 19 proveedores de inicio de sesión social de Web3Auth, incluidos Google, Twitter, Discord, GitHub, Facebook, Apple, LinkedIn y opciones regionales como WeChat, Kakao y Line, se posicionan para un alcance global. La autenticación JWT personalizada permite a las empresas integrar sistemas de identidad existentes. Privy enfatiza el correo electrónico primero con enlaces mágicos, tratando los inicios de sesión sociales como opciones secundarias. Magic fue pionero en el enfoque de enlaces mágicos, pero ahora compite con alternativas más flexibles. La arquitectura de Turnkey, primero con passkeys utilizando estándares WebAuthn, se posiciona para el futuro sin contraseñas, admitiendo la autenticación biométrica a través de Face ID, Touch ID y claves de seguridad de hardware.

Las compensaciones del modelo de seguridad surgen a través de las implementaciones de gestión de claves. El MPC distribuido de Web3Auth con nodos de Torus Network más dispositivos de usuario logra una seguridad no custodial a través de la distribución criptográfica en lugar de la confianza centralizada. El aislamiento de AWS Nitro Enclave de Turnkey garantiza que las claves nunca salgan de entornos protegidos por hardware, con atestación criptográfica que prueba la integridad del código. El enfoque de Shamir Secret Sharing de Privy divide las claves entre el dispositivo y los factores de autenticación, reconstruyéndolas solo en iframes aislados durante la firma de transacciones. El almacenamiento HSM de AWS de Magic con cifrado AES-256 acepta las compensaciones de la gestión centralizada de claves para la simplicidad operativa, adecuado para marcas empresariales de Web2 que priorizan la conveniencia sobre la autocustodia.

Las capacidades de marca blanca determinan la aplicabilidad para aplicaciones de marca. Web3Auth ofrece la personalización más completa a precios accesibles (plan Growth de $69 mensuales), lo que permite opciones de SDK modales y no modales con control total de la interfaz de usuario. El Kit de Billetera Integrada preconstruido de Turnkey equilibra la conveniencia con el acceso a la API de bajo nivel para interfaces personalizadas. Los controles de diseño basados en el panel de Dynamic agilizan la configuración de la apariencia sin cambios de código. La profundidad de la personalización afecta directamente si la infraestructura WaaS permanece visible para los usuarios finales o desaparece detrás de interfaces específicas de la marca.

El análisis de la complejidad del código revela los logros de abstracción. La integración modal de Web3Auth requiere solo cuatro líneas: importar, inicializar con ID de cliente, llamar a initModal y luego conectar. El enfoque de envoltorio de React Provider de Privy se integra naturalmente con los árboles de componentes de React mientras mantiene el aislamiento. La configuración más detallada de Turnkey refleja la priorización de la flexibilidad, con una configuración explícita de ID de organización, clientes de passkey y parámetros de política. Este espectro de complejidad permite al desarrollador elegir entre la simplicidad con opiniones y el control de bajo nivel, según los requisitos del caso de uso.

Los comentarios de la comunidad a través de Stack Overflow, Reddit y testimonios de desarrolladores revelan patrones. Los usuarios de Web3Auth ocasionalmente encuentran cambios importantes durante las actualizaciones de versión, algo típico de la infraestructura en rápida evolución. La dependencia de React de Privy limita la adopción para proyectos que no son de React, aunque reconoce esta compensación conscientemente. Dynamic recibe elogios por su soporte receptivo, con testimonios que describen al equipo como socios en lugar de proveedores. La documentación profesional y la comunidad de Slack de Turnkey atraen a equipos que priorizan la comprensión de la infraestructura sobre los servicios gestionados.

Adopción en el mundo real: Gaming, DeFi y NFTs impulsan el uso a escala

Las aplicaciones de juegos demuestran que WaaS elimina la complejidad de blockchain a una escala masiva. La integración de Axie Infinity con Ramp Network redujo la incorporación de 2 horas y 60 pasos a solo 12 minutos y 19 pasos, una reducción del tiempo del 90 % y una reducción de los pasos del 30 %, lo que permitió a millones de jugadores, particularmente en Filipinas, donde se origina el 28,3 % del tráfico. Esta transformación permitió que funcionara la economía play-to-earn, con los participantes obteniendo ingresos significativos a través de los juegos. NBA Top Shot aprovechó Dapper Wallet para incorporar más de 800.000 cuentas que generaron más de $500 millones en ventas, con compras con tarjeta de crédito e inicio de sesión por correo electrónico que eliminaron la complejidad de las criptomonedas. El diseño personalizado de la blockchain Flow para transacciones NFT a escala de consumidor permite 9.000 transacciones por segundo con tarifas de gas casi nulas, lo que demuestra una infraestructura diseñada específicamente para la economía de los juegos.

Las plataformas DeFi integran billeteras integradas para reducir la fricción de los requisitos de billeteras externas. Los principales exchanges descentralizados como Uniswap, los protocolos de préstamo como Aave y las plataformas de derivados integran cada vez más la funcionalidad de billetera directamente en las interfaces de trading. El WaaS empresarial de Fireblocks sirve a exchanges, mesas de préstamo y fondos de cobertura que requieren custodia institucional combinada con operaciones de mesa de trading. La ola de abstracción de cuentas permite el patrocinio de gas para aplicaciones DeFi, con el 87 % de las UserOperations de ERC-4337 utilizando Paymasters para cubrir $3,4 millones en tarifas de gas durante 2024. Esta abstracción de gas elimina el problema de arranque en el que los nuevos usuarios necesitan tokens para pagar las transacciones que adquieren sus primeros tokens.

Los mercados de NFT fueron pioneros en la adopción de billeteras integradas para reducir el abandono del proceso de compra. La integración de Immutable X con la billetera Magic y MetaMask proporciona cero tarifas de gas a través del escalado de Capa 2, procesando miles de transacciones NFT por segundo para Gods Unchained e Illuvium. Los flujos de conexión de billetera de OpenSea admiten opciones integradas junto con conexiones de billetera externas, reconociendo la diversidad de preferencias del usuario. El enfoque de Dapper Wallet para NBA Top Shot y VIV3 demuestra que las billeteras integradas específicas del mercado pueden capturar más del 95 % de la actividad del mercado secundario cuando la optimización de la UX elimina la fricción competitiva.

La adopción empresarial valida WaaS para casos de uso de instituciones financieras. La integración de Fireblocks de Worldpay ofreció un procesamiento de pagos un 50 % más rápido con liquidaciones T+0 24/7/365, diversificando los ingresos a través de rieles de pago blockchain mientras se mantiene el cumplimiento normativo. Coinbase WaaS se dirige a marcas conocidas, incluidas asociaciones con tokenproof, Floor, Moonray y ENS Domains, posicionando las billeteras integradas como infraestructura que permite a las empresas de Web2 ofrecer capacidades de Web3 sin ingeniería blockchain. La integración de Flipkart con Fireblocks lleva las billeteras integradas a la enorme base de usuarios de comercio electrónico de la India, mientras que Grab en Singapur acepta recargas de criptomonedas en Bitcoin, Ether y stablecoins a través de la infraestructura de Fireblocks.

Las aplicaciones de consumo que buscan la adopción masiva dependen de WaaS para abstraer la complejidad. El programa de fidelización Starbucks Odyssey utiliza billeteras custodiales con una UX simplificada para recompensas basadas en NFT y experiencias con acceso restringido por token, lo que demuestra la experimentación de Web3 de las principales marcas minoristas. La visión de Coinbase de "dar billeteras a literalmente todos los humanos del planeta" a través de la integración de redes sociales representa la jugada masiva definitiva, con la incorporación de nombre de usuario/contraseña y la gestión de claves MPC reemplazando los requisitos de frase semilla. Esto cierra la brecha de adopción donde la complejidad técnica excluye a los usuarios no técnicos.

Los patrones geográficos revelan distintos impulsores de adopción regional. Asia-Pacífico lidera el crecimiento global con la India recibiendo $338 mil millones en valor en cadena durante 2023-2024, impulsado por grandes remesas de la diáspora, demografía joven y familiaridad con la infraestructura fintech UPI existente. El sudeste asiático muestra el crecimiento regional más rápido con un 69 % interanual hasta los $2,36 billones, con Vietnam, Indonesia y Filipinas aprovechando las criptomonedas para remesas, juegos y ahorros. Los 956 millones de usuarios de billeteras digitales de China, con una penetración urbana adulta de más del 90 %, demuestran una infraestructura de pago móvil que prepara a las poblaciones para la integración de criptomonedas. El aumento anual del 50 % en la adopción en América Latina se debe a las preocupaciones por la devaluación de la moneda y las necesidades de remesas, con Brasil y México a la cabeza. El aumento del 35 % en usuarios activos de dinero móvil en África posiciona al continente para superar la infraestructura bancaria tradicional a través de las billeteras de criptomonedas.

América del Norte se centra en la adopción institucional y empresarial con énfasis en la claridad regulatoria. EE. UU. contribuye con el 36,92 % de la cuota de mercado global, con el 70 % de los adultos en línea utilizando pagos digitales, aunque menos del 60 % de las pequeñas empresas aceptan billeteras digitales, una brecha de adopción que los proveedores de WaaS buscan cerrar. Europa muestra que el 52 % de los compradores en línea prefieren las billeteras digitales a los métodos de pago heredados, con las regulaciones MiCA que brindan claridad y permiten la aceleración de la adopción institucional.

Las métricas de adopción validan la trayectoria del mercado. Los usuarios globales de billeteras digitales alcanzaron los 5,6 mil millones en 2025 con proyecciones de 5,8 mil millones para 2029, lo que representa un crecimiento del 35 % desde los 4,3 mil millones en 2024. Las billeteras digitales ahora representan el 49-56 % del valor global de las transacciones de comercio electrónico, con $14-16 billones anualmente. Solo el mercado de seguridad de billeteras Web3 se proyecta que alcanzará los $68,8 mil millones para 2033 con un CAGR del 23,7 %, con 820 millones de direcciones de criptomonedas únicas activas en 2025. Los principales proveedores admiten decenas o cientos de millones de billeteras: Privy con 75 millones, Dynamic con más de 50 millones, Web3Auth con más de 20 millones de usuarios activos mensuales y Fireblocks asegurando más de 130 millones de billeteras.

Soporte de blockchain: Cobertura universal de EVM con ecosistemas no EVM en expansión

El panorama de soporte del ecosistema blockchain se bifurca entre proveedores que buscan cobertura universal a través de arquitecturas basadas en curvas y aquellos que integran cadenas individualmente. Turnkey y Web3Auth logran soporte agnóstico de blockchain a través de la firma de curvas secp256k1 y ed25519, admitiendo automáticamente cualquier nueva blockchain que utilice estas primitivas criptográficas sin intervención del proveedor. Esta arquitectura prepara la infraestructura para el futuro a medida que se lanzan nuevas cadenas: Berachain y Monad reciben soporte de Turnkey desde el primer día a través de la compatibilidad de curvas en lugar de un trabajo de integración explícito.

Fireblocks adopta el enfoque opuesto con integraciones explícitas en más de 80 blockchains, siendo el más rápido en agregar nuevas cadenas a través de un enfoque institucional que requiere soporte integral de características por cadena. Las adiciones recientes incluyen la expansión del ecosistema Cosmos en mayo de 2024, agregando Osmosis, Celestia, dYdX, Axelar, Injective, Kava y Thorchain. Noviembre de 2024 trajo soporte para Unichain inmediatamente en el lanzamiento, mientras que la integración de World Chain siguió en agosto de 2024. Esta velocidad se debe a la arquitectura modular y la demanda de los clientes institucionales de una cobertura integral de cadenas, incluidos staking, protocolos DeFi e integración de WalletConnect por cadena.

Las soluciones de escalado de Capa 2 de EVM logran soporte universal en los principales proveedores. Base, Arbitrum y Optimism reciben soporte unánime de Magic, Web3Auth, Dynamic, Privy, Turnkey, Fireblocks y Particle Network. El crecimiento explosivo de Base como la Capa 2 de mayores ingresos a finales de 2024 valida la apuesta de infraestructura de Coinbase, con los proveedores de WaaS priorizando la integración dado el respaldo institucional y el impulso de los desarrolladores de Base. Arbitrum mantiene el 40 % de la cuota de mercado de Capa 2 con el mayor valor total bloqueado, mientras que Optimism se beneficia de los efectos del ecosistema Superchain a medida que múltiples proyectos implementan rollups OP Stack.

El soporte de ZK-rollup muestra más fragmentación a pesar de las ventajas técnicas. Linea logra el TVL más alto entre los ZK rollups con $450-700 millones respaldados por ConsenSys, con Fireblocks, Particle Network, Web3Auth, Turnkey y Privy brindando soporte. zkSync Era obtiene la integración de Web3Auth, Privy, Turnkey y Particle Network a pesar de los desafíos de cuota de mercado después del controvertido lanzamiento de tokens. Scroll recibe soporte de Web3Auth, Turnkey, Privy y Particle Network, sirviendo a desarrolladores con más de 85 protocolos integrados. Polygon zkEVM se beneficia de la asociación del ecosistema Polygon con el soporte de Fireblocks, Web3Auth, Turnkey y Privy. La fragmentación de ZK-rollup refleja la complejidad técnica y un menor uso en comparación con los rollups Optimistic, aunque las ventajas de escalabilidad a largo plazo sugieren una atención creciente.

El soporte de blockchain no EVM revela diferencias estratégicas de posicionamiento. Solana logra un soporte casi universal a través de la compatibilidad de curvas ed25519 y el impulso del mercado, con Web3Auth, Dynamic, Privy, Turnkey, Fireblocks y Particle Network brindando una integración completa. La integración de Cuentas Universales de Solana de Particle Network demuestra que la abstracción de cadenas se extiende más allá de EVM a alternativas de alto rendimiento. El soporte de Bitcoin aparece en las ofertas de Dynamic, Privy, Turnkey, Fireblocks y Particle Network, con BTC Connect de Particle que representa la primera implementación de abstracción de cuentas de Bitcoin que permite billeteras Bitcoin programables sin la complejidad de Lightning Network.

El soporte del ecosistema Cosmos se concentra en Fireblocks después de su expansión estratégica de mayo de 2024. Con soporte para Cosmos Hub, Osmosis, Celestia, dYdX, Axelar, Kava, Injective y Thorchain, con planes para agregar Sei, Noble y Berachain, Fireblocks se posiciona para el dominio del protocolo de comunicación entre blockchains. Web3Auth proporciona una compatibilidad más amplia con Cosmos a través del soporte de curvas, mientras que otros proveedores ofrecen una integración selectiva basada en la demanda del cliente en lugar de una cobertura de todo el ecosistema.

Las blockchains de capa 1 emergentes reciben una atención variable. Turnkey agregó soporte para Sui y Sei, lo que refleja la compatibilidad con ed25519 y Ethereum, respectivamente. Aptos recibe soporte de Web3Auth, con Privy planeando la integración en el primer trimestre de 2025, posicionándose para el crecimiento del ecosistema del lenguaje Move. Near, Polkadot, Kusama, Flow y Tezos aparecen en el catálogo agnóstico de blockchain de Web3Auth a través de capacidades de exportación de claves privadas. La integración de TON apareció en las ofertas de Fireblocks dirigidas a las oportunidades del ecosistema de Telegram. Algorand y Stellar reciben soporte de Fireblocks para aplicaciones institucionales en casos de uso de pago y tokenización.

Los enfoques de arquitectura entre cadenas determinan la preparación para el futuro. Las Cuentas Universales de Particle Network proporcionan direcciones únicas en más de 65 blockchains con enrutamiento automático de liquidez entre cadenas a través de su capa de coordinación L1 modular. Los usuarios mantienen saldos unificados y gastan activos en cualquier cadena sin puentes manuales, pagando tarifas de gas en cualquier token. La red Newton de Magic, anunciada en noviembre de 2024, se integra con AggLayer de Polygon para la unificación de cadenas centrada en la abstracción a nivel de billetera. El soporte universal basado en curvas de Turnkey logra resultados similares a través de primitivas criptográficas en lugar de infraestructura de coordinación. La autenticación agnóstica de blockchain de Web3Auth con exportación de claves privadas permite a los desarrolladores integrar cualquier cadena a través de bibliotecas estándar.

Las optimizaciones específicas de la cadena aparecen en las implementaciones de los proveedores. Fireblocks admite staking en múltiples cadenas Proof-of-Stake, incluidas Ethereum, cadenas del ecosistema Cosmos, Solana y Algorand, con seguridad de grado institucional. Particle Network optimizó las cargas de trabajo de juegos con claves de sesión, transacciones sin gas y creación rápida de cuentas. El modal plug-and-play de Web3Auth optimiza la generación rápida de billeteras multicadena sin requisitos de personalización. El adaptador de billetera de Dynamic admite más de 500 billeteras externas en todos los ecosistemas, lo que permite a los usuarios conectar billeteras existentes en lugar de crear nuevas cuentas integradas.

Los anuncios de la hoja de ruta indican una expansión continua. Fireblocks se comprometió a admitir Berachain en el lanzamiento de la mainnet, la integración de Sei y Noble para operaciones de Cosmos nativas de USDC. Privy anunció soporte para Aptos y el ecosistema Move para el primer trimestre de 2025, expandiéndose más allá del enfoque de EVM y Solana. El lanzamiento de la mainnet Newton de Magic desde la testnet privada lleva la integración de AggLayer a producción. Particle Network continúa expandiendo las Cuentas Universales a cadenas no EVM adicionales con características mejoradas de liquidez entre cadenas. Los enfoques arquitectónicos sugieren dos caminos a seguir: integraciones individuales completas para características institucionales versus soporte universal basado en curvas para la flexibilidad del desarrollador y la compatibilidad automática con nuevas cadenas.

Panorama regulatorio: MiCA aporta claridad mientras los marcos de EE. UU. evolucionan

El entorno regulatorio para los proveedores de WaaS se transformó sustancialmente en 2024-2025 a través de marcos integrales que surgieron en las principales jurisdicciones. La regulación de Mercados de Criptoactivos (MiCA) de la UE, que entrará en pleno vigor en diciembre de 2024, establece el marco regulatorio de criptomonedas más completo del mundo, requiriendo la autorización de Proveedor de Servicios de Criptoactivos (CASP) para cualquier entidad que ofrezca servicios de custodia, transferencia o intercambio. MiCA introduce requisitos de protección al consumidor, incluidas reservas de capital, estándares de resiliencia operativa, marcos de ciberseguridad y divulgación de conflictos de intereses, al tiempo que proporciona un pasaporte regulatorio que permite a los proveedores autorizados como CASP operar en los 27 estados miembros de la UE.

La determinación del modelo de custodia impulsa la clasificación y las obligaciones regulatorias. Los proveedores de billeteras custodiales califican automáticamente como VASP/CASP/MSB, lo que requiere una licencia completa de servicios financieros, programas KYC/AML, cumplimiento de la Regla de Viaje, requisitos de capital y auditorías regulares. Fireblocks, Coinbase WaaS y los proveedores centrados en empresas aceptan deliberadamente estas obligaciones para servir a clientes institucionales que requieren contrapartes reguladas. Los proveedores de billeteras no custodiales como Turnkey y Web3Auth generalmente evitan la clasificación VASP al demostrar que los usuarios controlan las claves privadas, aunque deben estructurar cuidadosamente sus ofertas para mantener esta distinción. Los modelos híbridos de MPC enfrentan un tratamiento ambiguo dependiendo de si los proveedores controlan la mayoría de las partes de la clave, una decisión arquitectónica crítica con profundas implicaciones regulatorias.

Los requisitos de cumplimiento de KYC/AML varían según la jurisdicción, pero se aplican universalmente a los proveedores custodiales. Las Recomendaciones del GAFI exigen que los VASP implementen la debida diligencia del cliente, el monitoreo de actividades sospechosas y la presentación de informes de transacciones. Los principales proveedores se integran con tecnología de cumplimiento especializada: Chainalysis para el cribado de transacciones y el análisis de billeteras, Elliptic para la puntuación de riesgos y el cribado de sanciones, Sumsub para la verificación de identidad con detección de vivacidad y biometría. TRM Labs, Crystal Intelligence y Merkle Science proporcionan monitoreo de transacciones complementario y detección de comportamiento. Los enfoques de integración van desde el cumplimiento nativo incorporado (Fireblocks con Elliptic/Chainalysis integrados) hasta configuraciones de "traiga su propia clave" que permiten a los clientes usar contratos de proveedores existentes.

El cumplimiento de la Regla de Viaje presenta una complejidad operativa, ya que más de 65 jurisdicciones exigen el intercambio de información VASP a VASP para transacciones por encima de los montos umbral (generalmente el equivalente a $1.000 USD, aunque Singapur requiere $1.500 y Suiza $1.000). El informe del GAFI de junio de 2024 encontró que solo el 26 % de las jurisdicciones implementadoras han tomado medidas de cumplimiento, aunque la adopción del cumplimiento se aceleró con el aumento del volumen de transacciones de activos virtuales que utilizan herramientas de la Regla de Viaje. Los proveedores implementan a través de protocolos que incluyen Global Travel Rule Protocol, Travel Rule Protocol y CODE, con Notabene que proporciona servicios de directorio VASP. Sumsub ofrece soporte multiprotocolo que equilibra el cumplimiento en las variaciones jurisdiccionales.

El panorama regulatorio de los Estados Unidos cambió drásticamente con la postura pro-cripto de la administración Trump a partir de enero de 2025. La carta del grupo de trabajo de criptomonedas de la administración establecida en marzo de 2025 tiene como objetivo aclarar la jurisdicción de la SEC y potencialmente derogar el SAB 121. La Ley Genius para la regulación de stablecoins y FIT21 para productos digitales avanzan en el Congreso con apoyo bipartidista. La complejidad a nivel estatal persiste con la licencia de transmisor de dinero requerida en más de 48 estados, cada uno con requisitos de capital, reglas de fianza y plazos de aprobación distintos que van de 6 a 24 meses. El registro de FinCEN como Negocio de Servicios Monetarios (MSB) proporciona una base federal, complementando en lugar de reemplazar los requisitos estatales.

La Autoridad Monetaria de Singapur mantiene el liderazgo en Asia-Pacífico a través de la licencia de la Ley de Servicios de Pago que distingue las licencias de Institución de Pago Estándar (≤SGD 5 millones mensuales) de las licencias de Institución de Pago Principal (>SGD 5 millones), con un capital base mínimo de SGD 250.000. El marco de stablecoins de agosto de 2023 aborda específicamente las monedas digitales centradas en pagos, lo que permite la integración de recargas de criptomonedas de Grab y asociaciones institucionales como Dfns con proveedores de custodia con sede en Singapur. La Agencia de Servicios Financieros de Japón impone requisitos estrictos, incluida la custodia en frío del 95 %, la segregación de activos y el establecimiento de una subsidiaria japonesa para la mayoría de los proveedores extranjeros. La Comisión de Valores y Futuros de Hong Kong implementa el marco ASPIRe con licencias de operador de plataforma y requisitos de seguro obligatorios.

Las regulaciones de privacidad crean desafíos técnicos para las implementaciones de blockchain. El derecho al olvido del RGPD entra en conflicto con la inmutabilidad de blockchain, con las directrices del CEPD de abril de 2024 que recomiendan el almacenamiento de datos personales fuera de la cadena, el hashing en la cadena para referencias y los estándares de cifrado. La implementación requiere separar la información de identificación personal de las transacciones de blockchain, almacenando datos confidenciales en bases de datos cifradas fuera de la cadena controlables por los usuarios. El 63 % de las plataformas DeFi no cumplen con el derecho al olvido, según las evaluaciones de 2024, lo que indica la deuda técnica que muchos proveedores arrastran. Los requisitos de CCPA/CPRA en California se alinean en gran medida con los principios del RGPD, con el 53 % de las empresas de criptomonedas de EE. UU. ahora sujetas al marco de California.

La comparación de licencias regionales revela una variación sustancial en complejidad y costo. La autorización CASP de MiCA de la UE requiere de 6 a 12 meses con costos que varían según el estado miembro, pero proporciona un pasaporte para 27 países, lo que hace que una única solicitud sea económicamente eficiente para las operaciones europeas. Las licencias de EE. UU. combinan el registro federal de MSB (plazo típico de 6 meses) con más de 48 licencias de transmisor de dinero estatales que requieren de 6 a 24 meses con costos que superan el $1 millón para una cobertura integral. La licencia MAS de Singapur tarda de 6 a 12 meses con un capital de SGD 250.000 para SPI, mientras que el registro CAES de Japón generalmente requiere de 12 a 18 meses con el establecimiento preferido de una subsidiaria japonesa. La licencia VASP de Hong Kong a través de la SFC tarda de 6 a 12 meses con requisitos de seguro, mientras que el registro de la FCA del Reino Unido requiere de 6 a 12 meses con más de £50.000 de capital y cumplimiento de AML/CFT.

Los costos de la tecnología de cumplimiento y los requisitos operativos crean barreras de entrada que favorecen a los proveedores bien financiados. Las tarifas de licencia oscilan entre $100.000 y más de $1 millón en todas las jurisdicciones, mientras que las suscripciones anuales a tecnología de cumplimiento cuestan entre $50.000 y $500.000 para herramientas de KYC, AML y monitoreo de transacciones. Los gastos legales y de consultoría suelen alcanzar entre $200.000 y más de $1.000.000 anualmente para operaciones multijurisdiccionales, con equipos de cumplimiento dedicados que cuestan entre $500.000 y más de $2.000.000 en gastos de personal. Las auditorías y certificaciones regulares (SOC 2 Tipo II, ISO 27001) añaden entre $50.000 y $200.000 anualmente. La infraestructura de cumplimiento total comúnmente supera los $2-5 millones en costos de configuración del primer año para proveedores multijurisdiccionales, creando barreras alrededor de los actores establecidos mientras limita la competencia de nuevos participantes.

Fronteras de innovación: La abstracción de cuentas y la IA remodelan los paradigmas de las billeteras

La abstracción de cuentas representa la innovación de infraestructura más transformadora desde el lanzamiento de Ethereum, con las UserOperations de ERC-4337 aumentando un 1.140 % a 103 millones en 2024 en comparación con 8,3 millones en 2023. El estándar introduce billeteras de contrato inteligente sin requerir cambios de protocolo, lo que permite el patrocinio de gas, transacciones por lotes, recuperación social y claves de sesión a través de un sistema de ejecución de transacciones paralelo. Los Bundlers agregan UserOperations en transacciones únicas enviadas al contrato EntryPoint, con Coinbase procesando más de 30 millones de operaciones principalmente en Base, Alchemy implementando el 58 % de las nuevas cuentas inteligentes, y Pimlico, Biconomy y Particle proporcionando infraestructura complementaria.

La adopción de Paymaster demuestra la viabilidad de la aplicación clave. El 87 % de todas las UserOperations utilizaron Paymasters para patrocinar las tarifas de gas, cubriendo $3,4 millones en costos de transacción durante 2024. Esta abstracción de gas resuelve el problema de arranque en el que los usuarios necesitan tokens para pagar la adquisición de sus primeros tokens, lo que permite una incorporación verdaderamente sin fricciones. Los Paymasters de verificación vinculan la verificación fuera de la cadena con la ejecución en la cadena, mientras que los Paymasters de depósito mantienen saldos en la cadena que cubren las operaciones de usuario por lotes. La validación de múltiples rondas permite políticas de gasto sofisticadas sin que los usuarios gestionen estrategias de gas.

EIP-7702 se lanzó con la actualización de Pectra el 7 de mayo de 2025, introduciendo transacciones de Tipo 4 que permiten a las EOAs delegar la ejecución de código a contratos inteligentes. Esto extiende los beneficios de la abstracción de cuentas a las cuentas de propiedad externa existentes sin requerir migración de activos o generación de nuevas direcciones. Los usuarios mantienen las direcciones originales mientras obtienen capacidades de contrato inteligente de forma selectiva, con MetaMask, Rainbow y Uniswap implementando el soporte inicial. El mecanismo de lista de autorización permite la delegación temporal o permanente, compatible con la infraestructura ERC-4337 al tiempo que resuelve la fricción de adopción de los requisitos de migración de cuentas.

La integración de passkeys elimina las frases semilla como primitivas de autenticación, con la seguridad biométrica del dispositivo reemplazando los requisitos de memorización y copia de seguridad física. Coinbase Smart Wallet fue pionero en la creación de billeteras con passkey a escala utilizando los estándares WebAuthn/FIDO2, aunque las auditorías de seguridad identificaron preocupaciones sobre los requisitos de verificación del usuario y las limitaciones de sincronización en la nube de passkey vinculadas al dispositivo de Windows 11. Web3Auth, Dynamic, Turnkey y Portal implementan sesiones MPC autorizadas por passkey donde la autenticación biométrica controla el acceso a la billetera y la firma de transacciones sin exponer directamente las claves privadas. El soporte de precompilación EIP-7212 para la verificación de firmas P-256 reduce los costos de gas para las transacciones con passkey en Ethereum y cadenas compatibles.

El desafío técnico de la integración de passkey-blockchain se deriva de las incompatibilidades de curvas. WebAuthn utiliza curvas P-256 (secp256r1), mientras que la mayoría de las blockchains esperan secp256k1 (Ethereum, Bitcoin) o ed25519 (Solana). La firma directa con passkey requeriría una verificación costosa en la cadena o modificaciones de protocolo, por lo que la mayoría de las implementaciones utilizan passkeys para autorizar operaciones MPC en lugar de la firma directa de transacciones. Esta arquitectura mantiene las propiedades de seguridad al tiempo que logra la compatibilidad criptográfica en todos los ecosistemas blockchain.

La integración de la IA transforma las billeteras de almacenamiento pasivo de claves en asistentes financieros inteligentes. El mercado de IA en FinTech proyecta un crecimiento de $14,79 mil millones en 2024 a $43,04 mil millones para 2029 con un CAGR del 23,82 %, con las billeteras de criptomonedas representando una adopción sustancial. La detección de fraude aprovecha el aprendizaje automático para la detección de anomalías, el análisis de patrones de comportamiento y la identificación de phishing en tiempo real; la integración de Wallet Guard de MetaMask ejemplifica la prevención de amenazas impulsada por IA. La optimización de transacciones a través de modelos predictivos de tarifas de gas que analizan la congestión de la red, las recomendaciones de tiempo óptimo y la protección MEV ofrece ahorros de costos medibles que promedian entre el 15 y el 30 % en comparación con la sincronización ingenua.

Las características de IA para la gestión de cartera incluyen recomendaciones de asignación de activos, perfilado de tolerancia al riesgo con reequilibrio automático, identificación de oportunidades de yield farming en protocolos DeFi y análisis de rendimiento con predicción de tendencias. Rasper AI se comercializa como la primera billetera de IA autocustodial con funcionalidad de asesor de cartera, alertas de amenazas y volatilidad en tiempo real, y seguimiento de tendencias de comportamiento multidivisa. ASI Wallet de Fetch.ai proporciona experiencias nativas de IA centradas en la privacidad con seguimiento de cartera e información predictiva integrada con interacciones basadas en agentes del ecosistema Cosmos.

Las interfaces de lenguaje natural representan la aplicación clave para la adopción masiva. La IA conversacional permite a los usuarios ejecutar transacciones a través de comandos de voz o texto sin comprender la mecánica de blockchain: "enviar 10 USDC a Alice" resuelve automáticamente nombres, verifica saldos, estima el gas y ejecuta en las cadenas apropiadas. El panel de Zebu Live, con oradores de Base, Rhinestone, Zerion y Askgina.ai, articuló la visión: los futuros usuarios no pensarán en las tarifas de gas o la gestión de claves, ya que la IA maneja la complejidad de forma invisible. Las arquitecturas basadas en intenciones, donde los usuarios especifican los resultados deseados en lugar de la mecánica de la transacción, trasladan la carga cognitiva de los usuarios a la infraestructura del protocolo.

La adopción de pruebas de conocimiento cero se acelera a través de la integración de ZKP de Google anunciada el 2 de mayo de 2025 para la verificación de edad en Google Wallet, con bibliotecas de código abierto lanzadas el 3 de julio de 2025 a través de github.com/google/longfellow-zk. Los usuarios prueban atributos como la edad de más de 18 años sin revelar fechas de nacimiento, con el primer socio Bumble implementando para la verificación de aplicaciones de citas. La regulación eIDAS de la UE que fomenta ZKP en la Billetera de Identidad Digital Europea, planificada para su lanzamiento en 2026, impulsa la estandarización. La expansión se dirige a más de 50 países para la validación de pasaportes, el acceso a servicios de salud y la verificación de atributos, manteniendo la privacidad.

La adopción de ZK rollups de Capa 2 demuestra avances en escalabilidad. El TVL de Polygon zkEVM superó los $312 millones en el primer trimestre de 2025, lo que representa un crecimiento interanual del 240 %, mientras que zkSync Era experimentó un aumento del 276 % en las transacciones diarias. El probador móvil S-two de StarkWare permite la generación local de pruebas en computadoras portátiles y teléfonos, democratizando la creación de pruebas ZK más allá del hardware especializado. Los ZK-rollups agrupan cientos de transacciones en pruebas únicas verificadas en la cadena, lo que ofrece mejoras de escalabilidad de 100 a 1000 veces, al tiempo que mantienen las propiedades de seguridad a través de garantías criptográficas en lugar de suposiciones optimistas de prueba de fraude.

La investigación en criptografía resistente a la computación cuántica se intensifica a medida que se cristalizan los plazos de amenaza. El NIST estandarizó algoritmos post-cuánticos, incluidos CRYSTALS-Kyber para la encapsulación de claves y CRYSTALS-Dilithium para firmas digitales en noviembre de 2024, con el lanzamiento del Elemento Seguro QS7001 de SEALSQ el 21 de mayo de 2025 como la primera billetera de hardware de Bitcoin que implementa criptografía post-cuántica compatible con NIST. El enfoque híbrido que combina firmas ECDSA y Dilithium permite la compatibilidad con versiones anteriores durante los períodos de transición. Bitcoin Quantum de BTQ Technologies se lanzó en octubre de 2025 como la primera implementación de Bitcoin segura cuánticamente compatible con NIST, capaz de más de 1 millón de firmas post-cuánticas por segundo.

Los estándares de identidad descentralizada maduran hacia la adopción masiva. Las especificaciones DID de W3C definen identificadores globalmente únicos y controlados por el usuario, anclados en blockchain para la inmutabilidad sin autoridades centrales. Las Credenciales Verificables permiten credenciales digitales, firmadas criptográficamente, emitidas por entidades confiables, almacenadas en billeteras de usuario y verificadas sin contactar a los emisores. La Billetera de Identidad Digital Europea que se lanzará en 2026 requerirá que los estados miembros de la UE proporcionen una identificación digital transfronteriza interoperable con divulgación selectiva basada en ZKP, lo que podría afectar a más de 450 millones de residentes. Las proyecciones del mercado de identidad digital alcanzan más de $200 mil millones para 2034, con un 25-35 % de las identificaciones digitales que se espera que estén descentralizadas para 2035, ya que el 60 % de los países exploran marcos descentralizados.

Los protocolos de interoperabilidad entre cadenas abordan la fragmentación en más de 300 redes blockchain. Chainlink CCIP integró más de 60 blockchains a partir de 2025, aprovechando las Redes de Oráculos Descentralizadas probadas en batalla que aseguran más de $100 mil millones de TVL para transferencias seguras agnósticas a tokens. Las integraciones recientes incluyen Stellar a través de Chainlink Scale y TON para transferencias entre cadenas de Toncoin. Arcana Chain Abstraction SDK lanzado en enero de 2025 proporciona saldos unificados en Ethereum, Polygon, Arbitrum, Base y Optimism con pagos de gas en stablecoins y enrutamiento automático de liquidez. Las Cuentas Universales de Particle Network ofrecen direcciones únicas en más de 65 cadenas con ejecución de transacciones basada en intenciones, abstraendo por completo la selección de cadenas de las decisiones del usuario.

Comparación de precios

BilleterasTHIRDWEBPRIVYDYNAMICWEB3 AUTHMAGIC LINK
10.000$150 Total
($0,015/billetera)
$499 Total
($0,049/billetera)
$500 Total
($0,05/billetera)
$400 Total
($0,04/billetera)
$500 Total
($0,05/billetera)
100.000$1.485 Total
($0,01485/billetera)
Precios empresariales
(consultar ventas)
$5.000 Total
($0,05/billetera)
$4.000 Total
($0,04/billetera)
$5.000 Total
($0,05/billetera)
1.000.000$10.485 Total
($0,0104/billetera)
Precios empresariales
(consultar ventas)
$50.000 Total
($0,05/billetera)
$40.000 Total
($0,04/billetera)
$50.000 Total
($0,05/billetera)
10.000.000$78.000 Total
($0,0078/billetera)
Precios empresariales
(consultar ventas)
Precios empresariales
(consultar ventas)
$400.000 Total
($0,04/billetera)
Precios empresariales
(consultar ventas)
100.000.000$528.000 Total
($0,00528/billetera)
Precios empresariales
(consultar ventas)
Precios empresariales
(consultar ventas)
$4.000.000 Total
($0,04/billetera)
Precios empresariales
(consultar ventas)

Imperativos estratégicos para desarrolladores y empresas

La selección de la infraestructura WaaS requiere evaluar los modelos de seguridad, el posicionamiento regulatorio, la cobertura de blockchain y la experiencia del desarrollador en función de los requisitos específicos del caso de uso. Las aplicaciones institucionales priorizan Fireblocks o Turnkey por la certificación SOC 2 Tipo II, los registros de auditoría completos, los motores de políticas que permiten flujos de trabajo de aprobación múltiple y las relaciones regulatorias establecidas. La valoración de $8 mil millones de Fireblocks y más de $10 billones en transferencias aseguradas proporcionan credibilidad institucional, mientras que la arquitectura AWS Nitro Enclave de Turnkey y el enfoque de código abierto atraen a equipos que requieren transparencia de infraestructura.

Las aplicaciones de consumo optimizan las tasas de conversión a través de una incorporación sin fricciones. Privy sobresale para equipos centrados en React que requieren una integración rápida con correo electrónico e inicio de sesión social, ahora respaldado por los recursos y la infraestructura de pago de Stripe. Web3Auth proporciona soporte agnóstico de blockchain para equipos que apuntan a múltiples cadenas y frameworks, con más de 19 opciones de inicio de sesión social a $69 mensuales, lo que lo hace económicamente accesible para startups. La adquisición de Dynamic por parte de Fireblocks crea una oferta unificada de custodia a consumidor que combina la seguridad institucional con billeteras integradas fáciles de usar para desarrolladores.

Las aplicaciones de juegos y metaverso se benefician de características especializadas. Los SDK de Unity y Unreal Engine de Web3Auth siguen siendo únicos entre los principales proveedores, algo crítico para los desarrolladores de juegos que trabajan fuera de los frameworks web. Las claves de sesión de Particle Network permiten transacciones sin gas dentro del juego con límites de gasto autorizados por el usuario, mientras que el procesamiento por lotes de abstracción de cuentas permite acciones complejas de juego de varios pasos en transacciones únicas. Considere cuidadosamente los requisitos de patrocinio de gas: las economías de juego con altas frecuencias de transacción requieren una implementación de Capa 2 o presupuestos sustanciales de Paymaster.

Las aplicaciones multicadena deben evaluar los enfoques arquitectónicos. El soporte universal basado en curvas de Turnkey y Web3Auth cubre automáticamente las nuevas cadenas en el lanzamiento sin dependencias de integración del proveedor, lo que prepara la infraestructura para el futuro ante la proliferación de blockchains. Las integraciones individuales completas de Fireblocks proporcionan características más profundas específicas de la cadena, como staking y acceso a protocolos DeFi. Las Cuentas Universales de Particle Network representan la vanguardia con una verdadera abstracción de cadenas a través de la infraestructura de coordinación, adecuada para aplicaciones dispuestas a integrar arquitecturas novedosas para una UX superior.

Los requisitos de cumplimiento normativo varían drásticamente según el modelo de negocio. Los modelos custodiales activan la licencia completa de VASP/CASP en todas las jurisdicciones, lo que requiere una inversión de infraestructura de cumplimiento de $2-5 millones en el primer año y plazos de licencia de 12-24 meses. Los enfoques no custodiales que utilizan MPC o billeteras de contrato inteligente evitan la mayoría de las regulaciones de custodia, pero deben estructurar cuidadosamente el control de claves para mantener la clasificación. Los modelos híbridos requieren un análisis legal para cada jurisdicción, ya que la determinación depende de sutiles detalles de implementación en torno a la recuperación de claves y los procedimientos de copia de seguridad.

Las consideraciones de costos se extienden más allá de los precios transparentes al costo total de propiedad. Los precios basados en transacciones crean costos de escalado impredecibles para aplicaciones de alto volumen, mientras que los precios mensuales de billetera activa penalizan el crecimiento de usuarios. Evalúe los riesgos de bloqueo del proveedor a través de las capacidades de exportación de claves privadas y el soporte de rutas de derivación estándar que permiten la migración sin interrupción del usuario. Los proveedores de infraestructura con bloqueo de proveedor a través de la gestión de claves propietaria crean costos de cambio que dificultan la flexibilidad futura.

Los factores de experiencia del desarrollador se acumulan a lo largo de la vida útil de la aplicación. El tiempo de integración representa un costo único, pero la calidad del SDK, la integridad de la documentación y la capacidad de respuesta del soporte impactan la velocidad de desarrollo continua. Web3Auth, Turnkey y Dynamic reciben elogios constantes por la calidad de la documentación, mientras que algunos proveedores requieren contacto de ventas para preguntas básicas de integración. Las comunidades de desarrolladores activas en GitHub, Discord y Stack Overflow indican la salud del ecosistema y la disponibilidad de la base de conocimientos.

Los requisitos de certificación de seguridad dependen de las expectativas del cliente. La certificación SOC 2 Tipo II tranquiliza a los compradores empresariales sobre los controles operativos y las prácticas de seguridad, a menudo requerida para la aprobación de adquisiciones. Las certificaciones ISO 27001/27017/27018 demuestran el cumplimiento de los estándares internacionales de seguridad. Las auditorías de seguridad periódicas de terceros de empresas de renombre como Trail of Bits, OpenZeppelin o Consensys Diligence validan la seguridad de los contratos inteligentes y la infraestructura. La cobertura de seguro para activos en almacenamiento y tránsito diferencia a los proveedores de grado institucional, con Fireblocks que ofrece pólizas que cubren el ciclo de vida de los activos digitales.

Las estrategias de preparación para el futuro requieren una planificación de preparación cuántica. Si bien las computadoras cuánticas criptográficamente relevantes aún están a 10-20 años de distancia, el modelo de amenaza de "cosechar ahora, descifrar después" hace que la planificación post-cuántica sea urgente para los activos de larga duración. Evalúe las hojas de ruta de resistencia cuántica de los proveedores y las arquitecturas cripto-ágiles que permiten transiciones de algoritmos sin interrupción del usuario. Las integraciones de billeteras de hardware que admiten firmas Dilithium o FALCON preparan la custodia de alto valor para el futuro, mientras que la participación en el protocolo en los procesos de estandarización del NIST señala el compromiso con la preparación cuántica.

El momento de la adopción de la abstracción de cuentas representa una decisión estratégica. ERC-4337 y EIP-7702 proporcionan infraestructura lista para producción para el patrocinio de gas, la recuperación social y las claves de sesión, características que mejoran drásticamente las tasas de conversión y reducen la carga de soporte por pérdida de acceso. Sin embargo, los costos de implementación de cuentas inteligentes y la sobrecarga de transacciones continuas requieren un cuidadoso análisis de costo-beneficio. La implementación de Capa 2 mitiga las preocupaciones sobre el gas mientras mantiene las propiedades de seguridad, con Base, Arbitrum y Optimism que ofrecen una sólida infraestructura de abstracción de cuentas.

El panorama de WaaS continúa su rápida evolución con la consolidación en torno a los actores de la plataforma que construyen soluciones de pila completa. La adquisición de Privy por parte de Stripe y la integración vertical con las stablecoins de Bridge señalan que los gigantes de pagos de Web2 reconocen la criticidad de la infraestructura criptográfica. La adquisición de Dynamic por parte de Fireblocks crea ofertas de custodia a consumidor que compiten con el enfoque integrado de Coinbase. Esta consolidación favorece a los proveedores con un posicionamiento claro (la mejor seguridad institucional de su clase, una experiencia de desarrollador superior o una abstracción de cadenas innovadora) sobre los actores del mercado medio indiferenciados.

Para los desarrolladores que implementan infraestructura WaaS en 2024-2025, prioricen a los proveedores con soporte integral de abstracción de cuentas, hojas de ruta de autenticación sin contraseña, cobertura multicadena a través de arquitecturas basadas en curvas o de abstracción, y marcos de cumplimiento normativo que coincidan con su modelo de negocio. La infraestructura ha madurado de experimental a grado de producción, con implementaciones probadas que impulsan miles de millones en volumen de transacciones en juegos, DeFi, NFTs y aplicaciones empresariales. Los ganadores en la próxima fase de crecimiento de Web3 serán aquellos que aprovechen WaaS para ofrecer experiencias de usuario de Web2 impulsadas por el dinero programable de Web3, los protocolos componibles y los activos digitales controlados por el usuario.

Protocolo de Pagos de Agentes (AP2) de Google

· 41 min de lectura
Dora Noda
Software Engineer

El Protocolo de Pagos de Agentes (AP2) de Google es un estándar abierto recientemente anunciado, diseñado para permitir transacciones seguras y confiables iniciadas por agentes de IA en nombre de los usuarios. Desarrollado en colaboración con más de 60 organizaciones de pagos y tecnología (incluyendo las principales redes de pago, bancos, fintechs y empresas Web3), AP2 establece un lenguaje común para los pagos "agéneticos", es decir, compras y transacciones financieras que un agente autónomo (como un asistente de IA o un agente basado en LLM) puede realizar para un usuario. La creación de AP2 está impulsada por un cambio fundamental: tradicionalmente, los sistemas de pago en línea asumían que un humano hacía clic directamente en "comprar", pero el auge de los agentes de IA que actúan según las instrucciones del usuario rompe esta suposición. AP2 aborda los desafíos resultantes de autorización, autenticidad y rendición de cuentas en el comercio impulsado por IA, al tiempo que sigue siendo compatible con la infraestructura de pago existente. Este informe examina la arquitectura técnica de AP2, su propósito y casos de uso, integraciones con agentes de IA y proveedores de pago, consideraciones de seguridad y cumplimiento, comparaciones con protocolos existentes, implicaciones para Web3/sistemas descentralizados, y la adopción/hoja de ruta de la industria.

Arquitectura Técnica: Cómo Funciona AP2

En su esencia, AP2 introduce un marco de transacciones criptográficamente seguro construido sobre credenciales digitales verificables (VDC), que son esencialmente objetos de datos firmados e inalterables que sirven como "contratos" digitales de lo que el usuario ha autorizado. En la terminología de AP2, estos contratos se denominan Mandatos, y forman una cadena de evidencia auditable para cada transacción. Hay tres tipos principales de mandatos en la arquitectura de AP2:

  • Mandato de Intención: Captura las instrucciones o condiciones iniciales del usuario para una compra, especialmente para escenarios “sin presencia humana” (donde el agente actuará más tarde sin que el usuario esté en línea). Define el alcance de la autoridad que el usuario otorga al agente; por ejemplo, “Comprar entradas para el concierto si bajan de $200, hasta 2 entradas”. Este mandato es firmado criptográficamente por adelantado por el usuario y sirve como prueba verificable de consentimiento dentro de límites específicos.
  • Mandato de Carrito: Representa los detalles finales de la transacción que el usuario ha aprobado, utilizado en escenarios “con presencia humana” o en el momento del pago. Incluye los artículos o servicios exactos, su precio y otros detalles de la compra. Cuando el agente está listo para completar la transacción (por ejemplo, después de llenar un carrito de compras), el comerciante primero firma criptográficamente el contenido del carrito (garantizando los detalles del pedido y el precio), y luego el usuario (a través de su dispositivo o interfaz de agente) aprueba para crear un Mandato de Carrito. Esto asegura lo que ves es lo que pagas, fijando el pedido final exactamente como se le presentó al usuario.
  • Mandato de Pago: Una credencial separada que se envía a la red de pago (por ejemplo, red de tarjetas o banco) para indicar que un agente de IA está involucrado en la transacción. El Mandato de Pago incluye metadatos como si el usuario estuvo presente o no durante la autorización y sirve como una bandera para los sistemas de gestión de riesgos. Al proporcionar a los bancos adquirentes y emisores evidencia criptográficamente verificable de la intención del usuario, este mandato les ayuda a evaluar el contexto (por ejemplo, distinguir una compra iniciada por un agente de un fraude típico) y gestionar el cumplimiento o la responsabilidad en consecuencia.

Todos los mandatos se implementan como credenciales verificables firmadas por las claves de la parte relevante (usuario, comerciante, etc.), lo que produce una pista de auditoría no repudiable para cada transacción dirigida por un agente. En la práctica, AP2 utiliza una arquitectura basada en roles para proteger la información sensible; por ejemplo, un agente podría manejar un Mandato de Intención sin ver nunca los detalles de pago sin procesar, que solo se revelan de forma controlada cuando es necesario, preservando la privacidad. La cadena criptográfica de intención del usuario → compromiso del comerciante → autorización de pago establece la confianza entre todas las partes de que la transacción refleja las verdaderas instrucciones del usuario y de que tanto el agente como el comerciante se adhirieron a esas instrucciones.

Flujo de Transacción: Para ilustrar cómo funciona AP2 de principio a fin, considere un escenario de compra simple con un humano en el bucle:

  1. Solicitud del Usuario: El usuario le pide a su agente de IA que compre un artículo o servicio en particular (por ejemplo, “Pide este par de zapatos en mi talla”).
  2. Construcción del Carrito: El agente se comunica con los sistemas del comerciante (utilizando API estándar o mediante una interacción agente-a-agente) para armar un carrito de compras para el artículo especificado a un precio determinado.
  3. Garantía del Comerciante: Antes de presentar el carrito al usuario, el lado del comerciante firma criptográficamente los detalles del carrito (artículo, cantidad, precio, etc.). Este paso crea una oferta firmada por el comerciante que garantiza los términos exactos (evitando cualquier cambio oculto o manipulación de precios).
  4. Aprobación del Usuario: El agente muestra al usuario el carrito finalizado. El usuario confirma la compra, y esta aprobación desencadena dos firmas criptográficas del lado del usuario: una en el Mandato de Carrito (para aceptar el carrito del comerciante tal cual) y otra en el Mandato de Pago (para autorizar el pago a través del proveedor de pago elegido). Estos mandatos firmados se comparten luego con el comerciante y la red de pago, respectivamente.
  5. Ejecución: Armados con el Mandato de Carrito y el Mandato de Pago, el comerciante y el proveedor de pago proceden a ejecutar la transacción de forma segura. Por ejemplo, el comerciante envía la solicitud de pago junto con la prueba de aprobación del usuario a la red de pago (red de tarjetas, banco, etc.), que puede verificar el Mandato de Pago. El resultado es una transacción de compra completada con una pista de auditoría criptográfica que vincula la intención del usuario con el pago final.

Este flujo demuestra cómo AP2 construye confianza en cada paso de una compra impulsada por IA. El comerciante tiene prueba criptográfica de exactamente lo que el usuario acordó comprar y a qué precio, y el emisor/banco tiene prueba de que el usuario autorizó ese pago, aunque un agente de IA facilitó el proceso. En caso de disputas o errores, los mandatos firmados actúan como evidencia clara, ayudando a determinar la responsabilidad (por ejemplo, si el agente se desvió de las instrucciones o si un cargo no fue lo que el usuario aprobó). En esencia, la arquitectura de AP2 asegura que la intención verificable del usuario – en lugar de la confianza en el comportamiento del agente – sea la base de la transacción, reduciendo en gran medida la ambigüedad.

Propósito y Casos de Uso para AP2

Por qué se necesita AP2: El propósito principal de AP2 es resolver los problemas emergentes de confianza y seguridad que surgen cuando los agentes de IA pueden gastar dinero en nombre de los usuarios. Google y sus socios identificaron varias preguntas clave que la infraestructura de pago actual no puede responder adecuadamente cuando un agente autónomo está involucrado:

  • Autorización: ¿Cómo probar que un usuario realmente le dio permiso al agente para realizar una compra específica? (En otras palabras, asegurar que el agente no esté comprando cosas sin el consentimiento informado del usuario).
  • Autenticidad: ¿Cómo puede un comerciante saber que la solicitud de compra de un agente es genuina y refleja la verdadera intención del usuario, en lugar de un error o una alucinación de la IA?
  • Rendición de Cuentas: Si ocurre una transacción fraudulenta o incorrecta a través de un agente, ¿quién es el responsable: el usuario, el comerciante, el proveedor de pago o el creador del agente de IA?

Sin una solución, estas incertidumbres crean una "crisis de confianza" en torno al comercio dirigido por agentes. La misión de AP2 es proporcionar esa solución estableciendo un protocolo uniforme para transacciones seguras de agentes. Al introducir mandatos estandarizados y pruebas de intención, AP2 evita un ecosistema fragmentado donde cada empresa inventa sus propios métodos de pago de agentes ad-hoc. En cambio, cualquier agente de IA compatible puede interactuar con cualquier comerciante/proveedor de pago compatible bajo un conjunto común de reglas y verificaciones. Esta consistencia no solo evita la confusión del usuario y del comerciante, sino que también brinda a las instituciones financieras una forma clara de gestionar el riesgo para los pagos iniciados por agentes, en lugar de lidiar con un mosaico de enfoques propietarios. En resumen, el propósito de AP2 es ser una capa de confianza fundamental que permita que la "economía de agentes" crezca sin romper el ecosistema de pagos.

Casos de Uso Previstos: Al resolver los problemas anteriores, AP2 abre la puerta a nuevas experiencias comerciales y casos de uso que van más allá de lo que es posible con un humano haciendo clic manualmente en las compras. Algunos ejemplos de comercio habilitado por agentes que AP2 admite incluyen:

  • Compras más Inteligentes: Un cliente puede instruir a su agente: “Quiero esta chaqueta de invierno en verde, y estoy dispuesto a pagar hasta un 20% por encima del precio actual por ella”. Armado con un Mandato de Intención que codifica estas condiciones, el agente monitoreará continuamente los sitios web o bases de datos de los minoristas. En el momento en que la chaqueta esté disponible en verde (y dentro del umbral de precio), el agente ejecuta automáticamente una compra con una transacción segura y firmada, capturando una venta que de otro modo se habría perdido. Toda la interacción, desde la solicitud inicial del usuario hasta el pago automatizado, se rige por los mandatos de AP2, lo que garantiza que el agente solo compre exactamente lo que se autorizó.
  • Ofertas Personalizadas: Un usuario le dice a su agente que está buscando un producto específico (por ejemplo, una bicicleta nueva) de un comerciante en particular para un próximo viaje. El agente puede compartir este interés (dentro de los límites de un Mandato de Intención) con el propio agente de IA del comerciante, incluyendo el contexto relevante como la fecha del viaje. El agente del comerciante, conociendo la intención y el contexto del usuario, podría responder con un paquete o descuento personalizado, por ejemplo, “bicicleta + casco + portaequipajes con un 15% de descuento, disponible durante las próximas 48 horas”. Usando AP2, el agente del usuario puede aceptar y completar esta oferta personalizada de forma segura, convirtiendo una simple consulta en una venta más valiosa para el comerciante.
  • Tareas Coordinadas: Un usuario que planifica una tarea compleja (por ejemplo, un viaje de fin de semana) la delega por completo: “Resérvame un vuelo y un hotel para estas fechas con un presupuesto total de $700”. El agente puede interactuar con los agentes de múltiples proveedores de servicios (aerolíneas, hoteles, plataformas de viaje) para encontrar una combinación que se ajuste al presupuesto. Una vez que se identifica un paquete de vuelo y hotel adecuado, el agente utiliza AP2 para ejecutar múltiples reservas de una sola vez, cada una firmada criptográficamente (por ejemplo, emitiendo Mandatos de Carrito separados para la aerolínea y el hotel, ambos autorizados bajo el Mandato de Intención del usuario). AP2 garantiza que todas las partes de esta transacción coordinada ocurran según lo aprobado, e incluso permite la ejecución simultánea para que los boletos y las reservas se realicen juntos sin riesgo de que una parte falle a mitad de camino.

Estos escenarios ilustran solo algunos de los casos de uso previstos de AP2. De manera más amplia, el diseño flexible de AP2 admite tanto los flujos de comercio electrónico convencionales como modelos de comercio completamente nuevos. Por ejemplo, AP2 puede facilitar servicios tipo suscripción (un agente te mantiene abastecido de elementos esenciales comprando cuando se cumplen las condiciones), compras impulsadas por eventos (comprar entradas o artículos en el instante en que ocurre un evento desencadenante), negociaciones de agentes grupales (agentes de múltiples usuarios agrupando mandatos para negociar un acuerdo grupal), y muchos otros patrones emergentes. En cada caso, el hilo conductor es que AP2 proporciona el marco de confianza – autorización clara del usuario y auditabilidad criptográfica – que permite que estas transacciones impulsadas por agentes se realicen de forma segura. Al manejar la capa de confianza y verificación, AP2 permite a los desarrolladores y empresas centrarse en innovar nuevas experiencias de comercio de IA sin reinventar la seguridad de los pagos desde cero.

Integración con Agentes, LLMs y Proveedores de Pago

AP2 está explícitamente diseñado para integrarse sin problemas con los frameworks de agentes de IA y con los sistemas de pago existentes, actuando como un puente entre ambos. Google ha posicionado AP2 como una extensión de sus estándares de protocolo Agent2Agent (A2A) y Model Context Protocol (MCP). En otras palabras, si A2A proporciona un lenguaje genérico para que los agentes comuniquen tareas y MCP estandariza cómo los modelos de IA incorporan contexto/herramientas, entonces AP2 añade una capa de transacciones encima para el comercio. Los protocolos son complementarios: A2A maneja la comunicación agente-a-agente (permitiendo, por ejemplo, que un agente de compras hable con el agente de un comerciante), mientras que AP2 maneja la autorización de pago agente-a-comerciante dentro de esas interacciones. Debido a que AP2 es abierto y no propietario, está diseñado para ser agnóstico al framework: los desarrolladores pueden usarlo con el propio Kit de Desarrollo de Agentes (ADK) de Google o cualquier biblioteca de agentes de IA, y de manera similar puede funcionar con varios modelos de IA, incluyendo LLMs. Un agente basado en LLM, por ejemplo, podría usar AP2 generando e intercambiando las cargas útiles de mandato requeridas (guiado por la especificación AP2) en lugar de solo texto de forma libre. Al imponer un protocolo estructurado, AP2 ayuda a transformar la intención de alto nivel de un agente de IA (que podría provenir del razonamiento de un LLM) en transacciones concretas y seguras.

En el lado de los pagos, AP2 fue construido en concierto con los proveedores y estándares de pago tradicionales, en lugar de como un sistema de reemplazo. El protocolo es agnóstico al método de pago, lo que significa que puede admitir una variedad de rieles de pago – desde redes de tarjetas de crédito/débito hasta transferencias bancarias y billeteras digitales – como método subyacente para mover fondos. En su versión inicial, AP2 enfatiza la compatibilidad con pagos con tarjeta, ya que son los más comunes en el comercio en línea. El Mandato de Pago de AP2 está diseñado para conectarse al flujo de procesamiento de tarjetas existente: proporciona datos adicionales a la red de pago (por ejemplo, Visa, Mastercard, Amex) y al banco emisor de que un agente de IA está involucrado y si el usuario estuvo presente, complementando así los controles de detección de fraude y autorización existentes. Esencialmente, AP2 no procesa el pago en sí; aumenta la solicitud de pago con prueba criptográfica de la intención del usuario. Esto permite a los proveedores de pago tratar las transacciones iniciadas por agentes con la precaución o velocidad adecuadas (por ejemplo, un emisor podría aprobar una compra de aspecto inusual si ve un mandato AP2 válido que demuestre que el usuario la pre-aprobó). En particular, Google y sus socios planean evolucionar AP2 para admitir también métodos de pago "push" – como transferencias bancarias en tiempo real (como los sistemas UPI de India o PIX de Brasil) – y otros tipos de pagos digitales emergentes. Esto indica que la integración de AP2 se expandirá más allá de las tarjetas, alineándose con las tendencias de pago modernas en todo el mundo.

Para los comerciantes y procesadores de pagos, integrar AP2 significaría admitir los mensajes de protocolo adicionales (mandatos) y verificar las firmas. Muchas grandes plataformas de pago ya están involucradas en la configuración de AP2, por lo que podemos esperar que desarrollen soporte para ello. Por ejemplo, empresas como Adyen, Worldpay, Paypal, Stripe (no mencionadas explícitamente en el blog pero probablemente interesadas) y otras podrían incorporar AP2 en sus API o SDK de pago, permitiendo que un agente inicie un pago de manera estandarizada. Debido a que AP2 es una especificación abierta en GitHub con implementaciones de referencia, los proveedores de pago y las plataformas tecnológicas pueden comenzar a experimentar con ella de inmediato. Google también ha mencionado un Mercado de Agentes de IA donde se pueden listar agentes de terceros; se espera que estos agentes admitan AP2 para cualquier capacidad transaccional. En la práctica, una empresa que construye un asistente de ventas de IA o un agente de adquisiciones podría listarlo en este mercado, y gracias a AP2, ese agente puede realizar compras u pedidos de manera confiable.

Finalmente, la historia de integración de AP2 se beneficia de su amplio respaldo de la industria. Al codesarrollar el protocolo con las principales instituciones financieras y empresas tecnológicas, Google se aseguró de que AP2 se alinee con las reglas y requisitos de cumplimiento existentes de la industria. La colaboración con redes de pago (por ejemplo, Mastercard, UnionPay), emisores (por ejemplo, American Express), fintechs (por ejemplo, Revolut, Paypal), actores de comercio electrónico (por ejemplo, Etsy) e incluso proveedores de identidad/seguridad (por ejemplo, Okta, Cloudflare) sugiere que AP2 está siendo diseñado para encajar en sistemas del mundo real con una fricción mínima. Estos stakeholders aportan experiencia en áreas como KYC (regulaciones Conozca a su Cliente), prevención de fraude y privacidad de datos, lo que ayuda a AP2 a abordar esas necesidades de forma predeterminada. En resumen, AP2 está construido para ser amigable para agentes y amigable para proveedores de pago: extiende los protocolos de agentes de IA existentes para manejar transacciones, y se superpone a las redes de pago existentes para utilizar su infraestructura mientras agrega las garantías de confianza necesarias.

Consideraciones de Seguridad, Cumplimiento e Interoperabilidad

La seguridad y la confianza son el corazón del diseño de AP2. El uso de criptografía por parte del protocolo (firmas digitales en los mandatos) garantiza que cada acción crítica en una transacción agénetica sea verificable y rastreable. Este no repudio es crucial: ni el usuario ni el comerciante pueden negar posteriormente lo que se autorizó y acordó, ya que los mandatos sirven como registros seguros. Un beneficio directo es la prevención de fraude y la resolución de disputas: con AP2, si un agente malicioso o con errores intenta una compra no autorizada, la falta de un mandato válido firmado por el usuario sería evidente, y la transacción puede ser rechazada o revertida. Por el contrario, si un usuario afirma "Nunca aprobé esta compra", pero existe un Mandato de Carrito con su firma criptográfica, el comerciante y el emisor tienen pruebas sólidas para respaldar el cargo. Esta claridad de responsabilidad responde a una importante preocupación de cumplimiento para la industria de pagos.

Autorización y Privacidad: AP2 impone un paso (o pasos) de autorización explícita del usuario para las transacciones dirigidas por agentes, lo que se alinea con las tendencias regulatorias como la autenticación fuerte del cliente. El principio de Control del Usuario incorporado en AP2 significa que un agente no puede gastar fondos a menos que el usuario (o alguien delegado por el usuario) haya proporcionado una instrucción verificable para hacerlo. Incluso en escenarios totalmente autónomos, el usuario predefine las reglas a través de un Mandato de Intención. Este enfoque puede verse como análogo a otorgar un poder notarial al agente para transacciones específicas, pero de una manera digitalmente firmada y granular. Desde una perspectiva de privacidad, AP2 es consciente del intercambio de datos: el protocolo utiliza una arquitectura de datos basada en roles para garantizar que la información sensible (como credenciales de pago o detalles personales) solo se comparta con las partes que la necesitan absolutamente. Por ejemplo, un agente podría enviar un Mandato de Carrito a un comerciante que contenga información de artículos y precios, pero el número de tarjeta real del usuario solo podría compartirse a través del Mandato de Pago con el procesador de pagos, no con el agente o el comerciante. Esto minimiza la exposición innecesaria de datos, lo que ayuda al cumplimiento de las leyes de privacidad y las reglas PCI-DSS para el manejo de datos de pago.

Cumplimiento y Estándares: Debido a que AP2 se desarrolló con la aportación de entidades financieras establecidas, ha sido diseñado para cumplir o complementar los estándares de cumplimiento existentes en los pagos. El protocolo no elude los flujos de autorización de pago habituales; en cambio, los aumenta con evidencia y banderas adicionales. Esto significa que las transacciones de AP2 aún pueden aprovechar los sistemas de detección de fraude, los controles 3-D Secure o cualquier control regulatorio requerido, con los mandatos de AP2 actuando como factores de autenticación adicionales o señales de contexto. Por ejemplo, un banco podría tratar un Mandato de Pago como una firma digital del cliente en una transacción, lo que podría agilizar el cumplimiento de los requisitos de consentimiento del usuario. Además, los diseñadores de AP2 mencionan explícitamente trabajar "en concierto con las reglas y estándares de la industria". Podemos inferir que, a medida que AP2 evolucione, podría ser llevado a organismos de estándares formales (como el W3C, EMVCo o ISO) para garantizar que se alinee con los estándares financieros globales. Google ha declarado su compromiso con una evolución abierta y colaborativa de AP2, posiblemente a través de organizaciones de estándares. Este proceso abierto ayudará a resolver cualquier preocupación regulatoria y a lograr una amplia aceptación, de manera similar a cómo los estándares de pago anteriores (tarjetas con chip EMV, 3-D Secure, etc.) se sometieron a una colaboración a nivel de la industria.

Interoperabilidad: Evitar la fragmentación es un objetivo clave de AP2. Para ello, el protocolo se publica abiertamente y está disponible para que cualquiera lo implemente o integre. No está vinculado a los servicios de Google Cloud; de hecho, AP2 es de código abierto (licencia Apache-2) y la especificación más el código de referencia están en un repositorio público de GitHub. Esto fomenta la interoperabilidad porque múltiples proveedores pueden adoptar AP2 y aún así hacer que sus sistemas funcionen juntos. Ya se destaca el principio de interoperabilidad: AP2 es una extensión de protocolos abiertos existentes (A2A, MCP) y no es propietario, lo que significa que fomenta un ecosistema competitivo de implementaciones en lugar de una solución de un solo proveedor. En términos prácticos, un agente de IA construido por la Compañía A podría iniciar una transacción con un sistema de comerciante de la Compañía B si ambos siguen AP2; ninguna de las partes está bloqueada en una sola plataforma.

Una posible preocupación es asegurar una adopción consistente: si algunos actores importantes eligieran un protocolo diferente o un enfoque cerrado, la fragmentación aún podría ocurrir. Sin embargo, dada la amplia coalición detrás de AP2, parece estar preparado para convertirse en un estándar de facto. La inclusión de muchas empresas centradas en la identidad y la seguridad (por ejemplo, Okta, Cloudflare, Ping Identity) en el ecosistema de AP2 Figura: Más de 60 empresas de finanzas, tecnología y cripto están colaborando en AP2 (lista parcial de socios). sugiere que la interoperabilidad y la seguridad se están abordando conjuntamente. Estos socios pueden ayudar a integrar AP2 en los flujos de trabajo de verificación de identidad y las herramientas de prevención de fraude, asegurando que una transacción de AP2 pueda ser confiable en todos los sistemas.

Desde el punto de vista tecnológico, el uso de técnicas criptográficas ampliamente aceptadas por AP2 (probablemente credenciales verificables basadas en JSON-LD o JWT, firmas de clave pública, etc.) lo hace compatible con la infraestructura de seguridad existente. Las organizaciones pueden usar su PKI (Infraestructura de Clave Pública) existente para administrar claves para firmar mandatos. AP2 también parece anticipar la integración con sistemas de identidad descentralizada: Google menciona que AP2 crea oportunidades para innovar en áreas como la identidad descentralizada para la autorización de agentes. Esto significa que, en el futuro, AP2 podría aprovechar los estándares DID (Identificador Descentralizado) o la verificación de identificadores descentralizados para identificar agentes y usuarios de manera confiable. Tal enfoque mejoraría aún más la interoperabilidad al no depender de ningún proveedor de identidad único. En resumen, AP2 enfatiza la seguridad a través de la criptografía y la responsabilidad clara, tiene como objetivo estar listo para el cumplimiento por diseño y promueve la interoperabilidad a través de su naturaleza de estándar abierto y el amplio apoyo de la industria.

Comparación con Protocolos Existentes

AP2 es un protocolo novedoso que aborda una brecha que los marcos de pago y agentes existentes no han cubierto: permitir que los agentes autónomos realicen pagos de manera segura y estandarizada. En términos de protocolos de comunicación de agentes, AP2 se basa en trabajos anteriores como el protocolo Agent2Agent (A2A). A2A (de código abierto a principios de 2025) permite que diferentes agentes de IA se comuniquen entre sí, independientemente de sus marcos subyacentes. Sin embargo, A2A por sí solo no define cómo los agentes deben realizar transacciones o pagos; se trata más de la negociación de tareas y el intercambio de datos. AP2 amplía este panorama al agregar una capa de transacción que cualquier agente puede usar cuando una conversación conduce a una compra. En esencia, AP2 puede verse como complementario a A2A y MCP, en lugar de superponerse: A2A cubre los aspectos de comunicación y colaboración, MCP cubre el uso de herramientas/API externas, y AP2 cubre pagos y comercio. Juntos, forman una pila de estándares para una futura "economía de agentes". Este enfoque modular es algo análogo a los protocolos de internet: por ejemplo, HTTP para la comunicación de datos y SSL/TLS para la seguridad; aquí A2A podría ser como el HTTP de los agentes, y AP2 la capa transaccional segura encima para el comercio.

Al comparar AP2 con los protocolos y estándares de pago tradicionales, existen tanto paralelismos como diferencias. Los pagos en línea tradicionales (pagos con tarjeta de crédito, transacciones de PayPal, etc.) suelen implicar protocolos como HTTPS para una transmisión segura, y estándares como PCI DSS para el manejo de datos de tarjetas, además de posiblemente 3-D Secure para una autenticación de usuario adicional. Estos asumen un flujo impulsado por el usuario (el usuario hace clic y quizás ingresa un código de un solo uso). AP2, por el contrario, introduce una forma para que un tercero (el agente) participe en el flujo sin socavar la seguridad. Se podría comparar el concepto de mandato de AP2 con una extensión de la autoridad delegada al estilo OAuth, pero aplicada a los pagos. En OAuth, un usuario puede otorgar a una aplicación acceso limitado a una cuenta a través de tokens; de manera similar en AP2, un usuario otorga a un agente autoridad para gastar bajo ciertas condiciones a través de mandatos. La diferencia clave es que los "tokens" de AP2 (mandatos) son instrucciones específicas y firmadas para transacciones financieras, lo que es más granular que las autorizaciones de pago existentes.

Otro punto de comparación es cómo AP2 se relaciona con los flujos de pago de comercio electrónico existentes. Por ejemplo, muchos sitios de comercio electrónico utilizan protocolos como la API de Solicitud de Pago de W3C o SDK específicos de la plataforma para agilizar los pagos. Estos principalmente estandarizan cómo los navegadores o aplicaciones recopilan información de pago de un usuario, mientras que AP2 estandariza cómo un agente probaría la intención del usuario a un comerciante y procesador de pagos. El enfoque de AP2 en la intención verificable y el no repudio lo distingue de las API de pago más simples. Está agregando una capa adicional de confianza sobre las redes de pago. Se podría decir que AP2 no está reemplazando las redes de pago (Visa, ACH, blockchain, etc.), sino que las está aumentando. El protocolo admite explícitamente todo tipo de métodos de pago (incluso cripto), por lo que se trata más de estandarizar la interacción del agente con estos sistemas, no de crear un nuevo riel de pago desde cero.

En el ámbito de los protocolos de seguridad y autenticación, AP2 comparte cierto espíritu con elementos como las firmas digitales en las tarjetas con chip EMV o la notarización en los contratos digitales. Por ejemplo, las transacciones con tarjeta con chip EMV generan criptogramas para probar que la tarjeta estuvo presente; AP2 genera pruebas criptográficas de que el agente del usuario fue autorizado. Ambos tienen como objetivo prevenir el fraude, pero el alcance de AP2 es la relación agente-usuario y la mensajería agente-comerciante, que ningún estándar de pago existente aborda. Otra comparación emergente es con la abstracción de cuentas en cripto (por ejemplo, ERC-4337), donde los usuarios pueden autorizar acciones de billetera preprogramadas. Las billeteras criptográficas se pueden configurar para permitir ciertas transacciones automatizadas (como el pago automático de una suscripción a través de un contrato inteligente), pero estas suelen estar confinadas a un entorno de blockchain. AP2, por otro lado, aspira a ser multiplataforma: puede aprovechar blockchain para algunos pagos (a través de sus extensiones) pero también funciona con bancos tradicionales.

Todavía no existe un protocolo "competidor" directo de AP2 en la industria de pagos convencional; parece ser el primer esfuerzo concertado para un estándar abierto para pagos de agentes de IA. Pueden surgir intentos propietarios (o ya pueden estar en curso dentro de empresas individuales), pero el amplio apoyo de AP2 le da una ventaja para convertirse en el estándar. Vale la pena señalar que IBM y otros tienen un Protocolo de Comunicación de Agentes (ACP) e iniciativas similares para la interoperabilidad de agentes, pero estas no abarcan el aspecto de pago de la manera integral en que lo hace AP2. En todo caso, AP2 podría integrarse o aprovechar esos esfuerzos (por ejemplo, los frameworks de agentes de IBM podrían implementar AP2 para cualquier tarea comercial).

En resumen, AP2 se distingue por apuntar a la intersección única de la IA y los pagos: donde los protocolos de pago más antiguos asumían un usuario humano, AP2 asume un intermediario de IA y llena la brecha de confianza que resulta. Extiende, en lugar de entrar en conflicto con, los procesos de pago existentes, y complementa los protocolos de agentes existentes como A2A. En el futuro, se podría ver a AP2 utilizándose junto con estándares establecidos; por ejemplo, un Mandato de Carrito de AP2 podría funcionar en conjunto con una llamada a la API de una pasarela de pago tradicional, o un Mandato de Pago de AP2 podría adjuntarse a un mensaje ISO 8583 en la banca. La naturaleza abierta de AP2 también significa que si surgen enfoques alternativos, AP2 podría potencialmente absorberlos o alinearse con ellos a través de la colaboración comunitaria. En esta etapa, AP2 está estableciendo una base que no existía antes, siendo efectivamente pionero en una nueva capa de protocolo en la pila de IA y pagos.

Implicaciones para Web3 y Sistemas Descentralizados

Desde el principio, AP2 ha sido diseñado para ser inclusivo de los pagos basados en Web3 y criptomonedas. El protocolo reconoce que el comercio futuro abarcará tanto los canales fiduciarios tradicionales como las redes blockchain descentralizadas. Como se señaló anteriormente, AP2 admite tipos de pago que van desde tarjetas de crédito y transferencias bancarias hasta stablecoins y criptomonedas. De hecho, junto con el lanzamiento de AP2, Google anunció una extensión específica para pagos criptográficos llamada A2A x402. Esta extensión, desarrollada en colaboración con actores de la industria cripto como Coinbase, la Ethereum Foundation y MetaMask, es una "solución lista para producción para pagos criptográficos basados en agentes". El nombre "x402" es un homenaje al código de estado HTTP 402 "Pago Requerido", que nunca fue ampliamente utilizado en la Web; la extensión criptográfica de AP2 efectivamente revive el espíritu de HTTP 402 para agentes descentralizados que desean cobrarse o pagarse entre sí en la cadena. En términos prácticos, la extensión x402 adapta el concepto de mandato de AP2 a las transacciones de blockchain. Por ejemplo, un agente podría tener un Mandato de Intención firmado por un usuario y luego ejecutar un pago en cadena (por ejemplo, enviar una stablecoin) una vez que se cumplan las condiciones, adjuntando la prueba del mandato a esa transacción en cadena. Esto une el marco de confianza fuera de la cadena de AP2 con la naturaleza sin confianza de blockchain, ofreciendo lo mejor de ambos mundos: un pago en cadena que las partes fuera de la cadena (usuarios, comerciantes) pueden confiar que fue autorizado por el usuario.

La sinergia entre AP2 y Web3 es evidente en la lista de colaboradores. Intercambios de criptomonedas (Coinbase), fundaciones de blockchain (Ethereum Foundation), billeteras criptográficas (MetaMask) y startups de Web3 (por ejemplo, Mysten Labs de Sui, Lightspark para Lightning Network) están involucrados en el desarrollo de AP2. Su participación sugiere que AP2 se considera complementario a las finanzas descentralizadas en lugar de competitivo. Al crear una forma estándar para que los agentes de IA interactúen con los pagos criptográficos, AP2 podría impulsar un mayor uso de las criptomonedas en aplicaciones impulsadas por IA. Por ejemplo, un agente de IA podría usar AP2 para cambiar sin problemas entre pagar con tarjeta de crédito o pagar con una stablecoin, dependiendo de la preferencia del usuario o la aceptación del comerciante. La extensión A2A x402 permite específicamente a los agentes monetizar o pagar servicios a través de medios en cadena, lo que podría ser crucial en los mercados descentralizados del futuro. Sugiere que los agentes que posiblemente operen como actores económicos autónomos en blockchain (un concepto al que algunos se refieren como DACs o DAOs) podrán manejar los pagos requeridos para los servicios (como pagar una pequeña tarifa a otro agente por información). AP2 podría proporcionar la lengua franca para tales transacciones, asegurando que incluso en una red descentralizada, el agente tenga un mandato comprobable de lo que está haciendo.

En términos de competencia, uno podría preguntar: ¿las soluciones puramente descentralizadas hacen que AP2 sea innecesario, o viceversa? Es probable que AP2 coexista con las soluciones Web3 en un enfoque por capas. Las finanzas descentralizadas ofrecen ejecución sin confianza (contratos inteligentes, etc.), pero no resuelven inherentemente el problema de "¿Un IA tuvo permiso de un humano para hacer esto?". AP2 aborda ese vínculo de confianza humano-a-IA, que sigue siendo importante incluso si el pago en sí está en la cadena. En lugar de competir con los protocolos de blockchain, AP2 puede verse como un puente entre ellos y el mundo fuera de la cadena. Por ejemplo, un contrato inteligente podría aceptar una determinada transacción solo si incluye una referencia a una firma de mandato AP2 válida, algo que podría implementarse para combinar la prueba de intención fuera de la cadena con la aplicación en cadena. Por el contrario, si existen marcos de agentes cripto-nativos (algunos proyectos de blockchain exploran agentes autónomos que operan con fondos criptográficos), podrían desarrollar sus propios métodos de autorización. Sin embargo, el amplio apoyo de la industria de AP2 podría llevar incluso a esos proyectos a adoptar o integrarse con AP2 para mantener la coherencia.

Otro ángulo es la identidad y credenciales descentralizadas. El uso de credenciales verificables por parte de AP2 está muy en línea con el enfoque de Web3 hacia la identidad (por ejemplo, DIDs y VCs estandarizados por el W3C). Esto significa que AP2 podría conectarse a sistemas de identidad descentralizada; por ejemplo, el DID de un usuario podría usarse para firmar un mandato AP2, que un comerciante podría verificar contra una blockchain o un hub de identidad. La mención de explorar la identidad descentralizada para la autorización de agentes refuerza que AP2 puede aprovechar las innovaciones de identidad de Web3 para verificar las identidades de agentes y usuarios de manera descentralizada, en lugar de depender únicamente de autoridades centralizadas. Este es un punto de sinergia, ya que tanto AP2 como Web3 tienen como objetivo dar a los usuarios más control y pruebas criptográficas de sus acciones.

Posibles conflictos podrían surgir solo si se concibe un ecosistema de comercio totalmente descentralizado sin ningún papel para los grandes intermediarios; en ese escenario, ¿podría AP2 (inicialmente impulsado por Google y sus socios) ser demasiado centralizado o gobernado por actores tradicionales? Es importante señalar que AP2 es de código abierto y está destinado a ser estandarizable, por lo que no es propietario de Google. Esto lo hace más aceptable para la comunidad Web3, que valora los protocolos abiertos. Si AP2 se adopta ampliamente, podría reducir la necesidad de protocolos de pago separados específicos de Web3 para agentes, unificando así los esfuerzos. Por otro lado, algunos proyectos de blockchain podrían preferir mecanismos de autorización puramente en cadena (como billeteras multifirma o lógica de custodia en cadena) para transacciones de agentes, especialmente en entornos sin confianza y sin autoridades centralizadas. Esos podrían verse como enfoques alternativos, pero probablemente seguirían siendo un nicho a menos que puedan interactuar con sistemas fuera de la cadena. AP2, al cubrir ambos mundos, podría en realidad acelerar la adopción de Web3 al hacer de las criptomonedas solo otro método de pago que un agente de IA puede usar sin problemas. De hecho, un socio señaló que “las stablecoins proporcionan una solución obvia a los desafíos de escalado [para] sistemas agéneticos con infraestructura heredada”, destacando que las criptomonedas pueden complementar a AP2 en el manejo de la escala o escenarios transfronterizos. Mientras tanto, el líder de ingeniería de Coinbase comentó que llevar la extensión criptográfica x402 a AP2 “tenía sentido: es un campo de juego natural para los agentes... es emocionante ver que los agentes que se pagan entre sí resuenan en la comunidad de IA”. Esto implica una visión en la que los agentes de IA que realizan transacciones a través de redes criptográficas no es solo una idea teórica, sino un resultado esperado, con AP2 actuando como catalizador.

En resumen, AP2 es muy relevante para Web3: incorpora los pagos criptográficos como un ciudadano de primera clase y se alinea con los estándares de identidad y credenciales descentralizadas. En lugar de competir directamente con los protocolos de pago descentralizados, AP2 probablemente interoperará con ellos, proporcionando la capa de autorización mientras los sistemas descentralizados manejan la transferencia de valor. A medida que la línea entre las finanzas tradicionales y las criptomonedas se difumina (con stablecoins, CBDCs, etc.), un protocolo unificado como AP2 podría servir como un adaptador universal entre agentes de IA y cualquier forma de dinero, centralizada o descentralizada.

Adopción en la Industria, Asociaciones y Hoja de Ruta

Una de las mayores fortalezas de AP2 es el amplio respaldo de la industria que tiene, incluso en esta etapa temprana. Google Cloud anunció que está “colaborando con un grupo diverso de más de 60 organizaciones” en AP2. Estas incluyen las principales redes de tarjetas de crédito (por ejemplo, Mastercard, American Express, JCB, UnionPay), líderes en fintech y procesadores de pagos (PayPal, Worldpay, Adyen, Checkout.com, competidores de Stripe), comercio electrónico y mercados en línea (Etsy, Shopify (a través de socios como Stripe u otros), Lazada, Zalora), empresas de tecnología empresarial (Salesforce, ServiceNow, Oracle posiblemente a través de socios, Dell, Red Hat), empresas de identidad y seguridad (Okta, Ping Identity, Cloudflare), firmas de consultoría (Deloitte, Accenture), y organizaciones de cripto/Web3 (Coinbase, Ethereum Foundation, MetaMask, Mysten Labs, Lightspark), entre otras. Una gama tan amplia de participantes es un fuerte indicador del interés de la industria y la probable adopción. Muchos de estos socios han expresado públicamente su apoyo. Por ejemplo, el Co-CEO de Adyen destacó la necesidad de un "libro de reglas común" para el comercio agénetico y ve a AP2 como una extensión natural de su misión de apoyar a los comerciantes con nuevos bloques de construcción de pago. El vicepresidente ejecutivo de American Express declaró que AP2 es importante para “la próxima generación de pagos digitales” donde la confianza y la rendición de cuentas son primordiales. El equipo de Coinbase, como se señaló, está entusiasmado con la integración de pagos criptográficos en AP2. Este coro de apoyo muestra que muchos en la industria ven a AP2 como el estándar probable para los pagos impulsados por IA, y están ansiosos por darle forma para asegurar que cumpla con sus requisitos.

Desde el punto de vista de la adopción, AP2 se encuentra actualmente en la etapa de especificación e implementación temprana (anunciado en septiembre de 2025). La especificación técnica completa, la documentación y algunas implementaciones de referencia (en lenguajes como Python) están disponibles en el GitHub del proyecto para que los desarrolladores experimenten con ellas. Google también ha indicado que AP2 se incorporará a sus productos y servicios para agentes. Un ejemplo notable es el Mercado de Agentes de IA mencionado anteriormente: esta es una plataforma donde se pueden ofrecer agentes de IA de terceros a los usuarios (probablemente parte del ecosistema de IA generativa de Google). Google dice que muchos socios que construyen agentes los pondrán a disposición en el mercado con "nuevas experiencias transaccionales habilitadas por AP2". Esto implica que a medida que el mercado se lance o crezca, AP2 será la columna vertebral para cualquier agente que necesite realizar una transacción, ya sea comprando software del Google Cloud Marketplace de forma autónoma o un agente comprando bienes/servicios para un usuario. Casos de uso empresariales como la adquisición autónoma (un agente comprando a otro en nombre de una empresa) y el escalado automático de licencias se han mencionado específicamente como áreas que AP2 podría facilitar pronto.

En cuanto a la hoja de ruta, la documentación de AP2 y el anuncio de Google dan algunas indicaciones claras:

  • Corto plazo: Continuar el desarrollo abierto del protocolo con la aportación de la comunidad. El repositorio de GitHub se actualizará con implementaciones de referencia adicionales y mejoras a medida que se realicen pruebas en el mundo real. Podemos esperar que surjan bibliotecas/SDK, lo que facilitará la integración de AP2 en aplicaciones de agentes. Además, las empresas asociadas podrían llevar a cabo programas piloto iniciales o pruebas de concepto. Dado que muchas grandes empresas de pago están involucradas, podrían probar AP2 en entornos controlados (por ejemplo, una opción de pago habilitada para AP2 en una pequeña beta de usuarios).
  • Estándares y Gobernanza: Google ha expresado su compromiso de mover AP2 a un modelo de gobernanza abierta, posiblemente a través de organismos de estándares. Esto podría significar enviar AP2 a organizaciones como la Linux Foundation (como se hizo con el protocolo A2A) o formar un consorcio para mantenerlo. La Linux Foundation, el W3C o incluso organismos como ISO/TC68 (servicios financieros) podrían estar en los planes para formalizar AP2. Una gobernanza abierta tranquilizaría a la industria de que AP2 no está bajo el control de una sola empresa y seguirá siendo neutral e inclusivo.
  • Expansión de Funcionalidades: Técnicamente, la hoja de ruta incluye la expansión del soporte a más tipos de pago y casos de uso. Como se señaló en la especificación, después de las tarjetas, el enfoque se desplazará a los pagos "push" como transferencias bancarias y esquemas de pago locales en tiempo real, y monedas digitales. Esto significa que AP2 describirá cómo funciona un Mandato de Intención/Carrito/Pago para, por ejemplo, una transferencia bancaria directa o una transferencia de billetera criptográfica, donde el flujo es un poco diferente al de los retiros con tarjeta. La extensión A2A x402 es una de esas expansiones para cripto; de manera similar, podríamos ver una extensión para API de banca abierta o una para escenarios de facturación B2B.
  • Mejoras de Seguridad y Cumplimiento: A medida que las transacciones reales comiencen a fluir a través de AP2, habrá un escrutinio por parte de los reguladores e investigadores de seguridad. El proceso abierto probablemente iterará para hacer los mandatos aún más robustos (por ejemplo, asegurando que los formatos de mandato estén estandarizados, posiblemente usando el formato de Credenciales Verificables del W3C, etc.). La integración con soluciones de identidad (quizás aprovechando la biometría para la firma de mandatos por parte del usuario, o vinculando mandatos a billeteras de identidad digital) podría ser parte de la hoja de ruta para mejorar la confianza.
  • Herramientas del Ecosistema: Es probable que surja un ecosistema. Ya, las startups están notando lagunas; por ejemplo, el análisis de Vellum.ai menciona una startup llamada Autumn que está construyendo una "infraestructura de facturación para IA", esencialmente herramientas sobre Stripe para manejar precios complejos para servicios de IA. A medida que AP2 gane tracción, podemos esperar que aparezcan más herramientas como pasarelas de pago centradas en agentes, paneles de control de gestión de mandatos, servicios de verificación de identidad de agentes, etc. La participación de Google significa que AP2 también podría integrarse en sus productos de Cloud; imagine el soporte de AP2 en las herramientas de Dialogflow o Vertex AI Agents, lo que permitiría con un solo clic que un agente maneje transacciones (con todas las claves y certificados necesarios administrados en Google Cloud).

En general, la trayectoria de AP2 recuerda a otros estándares importantes de la industria: un lanzamiento inicial con un patrocinador fuerte (Google), una amplia coalición industrial, código de referencia de código abierto, seguido de mejoras iterativas y adopción gradual en productos reales. El hecho de que AP2 invite a todos los actores "a construir este futuro con nosotros" subraya que la hoja de ruta se trata de colaboración. Si el impulso continúa, AP2 podría volverse tan común en unos años como lo son hoy protocolos como OAuth u OpenID Connect en sus dominios: una capa invisible pero crítica que permite la funcionalidad en todos los servicios.

Conclusión

AP2 (Protocolo de Pagos de Agentes/Agentes) representa un paso significativo hacia un futuro donde los agentes de IA puedan realizar transacciones de manera tan confiable y segura como los humanos. Técnicamente, introduce un mecanismo inteligente de mandatos y credenciales verificables que infunden confianza en las transacciones dirigidas por agentes, asegurando que la intención del usuario sea explícita y aplicable. Su arquitectura abierta y extensible le permite integrarse tanto con los florecientes frameworks de agentes de IA como con la infraestructura financiera establecida. Al abordar las preocupaciones centrales de autorización, autenticidad y rendición de cuentas, AP2 sienta las bases para que el comercio impulsado por IA prospere sin sacrificar la seguridad ni el control del usuario.

La introducción de AP2 puede verse como el establecimiento de una nueva base – al igual que los primeros protocolos de internet habilitaron la web – para lo que algunos llaman la "economía de agentes". Abre el camino a innumerables innovaciones: agentes de compras personales, bots de búsqueda automática de ofertas, agentes autónomos de la cadena de suministro y más, todos operando bajo un marco de confianza común. Es importante destacar que el diseño inclusivo de AP2 (que abarca desde tarjetas de crédito hasta criptomonedas) lo posiciona en la intersección de las finanzas tradicionales y Web3, lo que podría unir estos mundos a través de un protocolo común mediado por agentes.

La respuesta de la industria hasta ahora ha sido muy positiva, con una amplia coalición que señala que AP2 probablemente se convertirá en un estándar ampliamente adoptado. El éxito de AP2 dependerá de la colaboración continua y las pruebas en el mundo real, pero sus perspectivas son sólidas dada la clara necesidad que aborda. En un sentido más amplio, AP2 ejemplifica cómo evoluciona la tecnología: surgió una nueva capacidad (agentes de IA) que rompió viejas suposiciones, y la solución fue desarrollar un nuevo estándar abierto para acomodar esa capacidad. Al invertir ahora en un protocolo abierto y centrado en la seguridad, Google y sus socios están construyendo efectivamente la arquitectura de confianza necesaria para la próxima era del comercio. Como dice el dicho, "la mejor manera de predecir el futuro es construirlo"; AP2 es una apuesta por un futuro en el que los agentes de IA gestionen transacciones por nosotros sin problemas, y está construyendo activamente la confianza y las reglas necesarias para que ese futuro sea viable.

Fuentes:

  • Blog de Google Cloud – “Impulsando el comercio de IA con el nuevo Protocolo de Pagos de Agentes (AP2)” (16 de septiembre de 2025)
  • Documentación de AP2 en GitHub – “Especificación y Resumen del Protocolo de Pagos de Agentes”
  • Blog de Vellum AI – “AP2 de Google: Un nuevo protocolo para pagos de agentes de IA” (Análisis)
  • Artículo de Medium – “Protocolo de Pagos de Agentes (AP2) de Google” (Resumen de Tahir, septiembre de 2025)
  • Citas de Socios sobre AP2 (Blog de Google Cloud)
  • Extensión A2A x402 (extensión de pagos criptográficos de AP2) – README de GitHub

Custodia de Activos Digitales para Ejecución de Operaciones Seguras y de Baja Latencia a Gran Escala

· 12 min de lectura
Dora Noda
Software Engineer

Cómo diseñar una pila de custodia y ejecución que se mueva a la velocidad del mercado sin comprometer el riesgo, la auditoría o el cumplimiento.


Resumen Ejecutivo

La custodia y el trading ya no pueden operar en mundos separados. En los mercados actuales de activos digitales, mantener los activos de los clientes de forma segura es solo la mitad de la batalla. Si no puedes ejecutar operaciones en milisegundos cuando los precios se mueven, estás dejando rendimientos sobre la mesa y exponiendo a los clientes a riesgos evitables como el Valor Máximo Extraíble (MEV), fallas de contrapartes y cuellos de botella operacionales. Una pila moderna de custodia y ejecución debe combinar seguridad de vanguardia con ingeniería de alto rendimiento. Esto implica integrar tecnologías como Computación Multipartita (MPC) y Módulos de Seguridad de Hardware (HSM) para la firma, usar motores de políticas y enrutamiento privado de transacciones para mitigar el front‑running, y aprovechar infraestructura activa/activa con liquidación fuera de intercambio para reducir el riesgo de la sede y mejorar la eficiencia de capital. Crucialmente, el cumplimiento no puede ser un complemento; características como flujos de datos de la Regla de Viaje, registros de auditoría inmutables y controles mapeados a marcos como SOC 2 deben estar construidos directamente en la canalización de transacciones.


Por Qué la “Velocidad de Custodia” Importa Ahora

Históricamente, los custodios de activos digitales se optimizaban para un objetivo principal: no perder las llaves. Aunque eso sigue siendo fundamental, las demandas han evolucionado. Hoy, la mejor ejecución y la integridad del mercado son igualmente innegociables. Cuando tus operaciones viajan por mempools públicos, actores sofisticados pueden verlas, reordenarlas o “sandwicharlas” para extraer beneficio a tu costa. Esto es MEV en acción, y afecta directamente la calidad de ejecución. Mantener el flujo de órdenes sensible fuera de la vista pública mediante relés de transacciones privados es una forma poderosa de reducir esta exposición.

Al mismo tiempo, el riesgo de la sede es una preocupación persistente. Concentrar grandes saldos en un solo intercambio crea un riesgo de contrapartida significativo. Las redes de liquidación fuera de intercambio ofrecen una solución, permitiendo a las firmas operar con crédito provisto por el intercambio mientras sus activos permanecen en custodia segregada y aislada de bancarrota. Este modelo mejora enormemente tanto la seguridad como la eficiencia de capital.

Los reguladores también están cerrando brechas. La aplicación de la Regla de Viaje del Grupo de Acción Financiera (FATF) y las recomendaciones de organismos como IOSCO y el Consejo de Estabilidad Financiera están impulsando a los mercados de activos digitales hacia un marco de “mismo riesgo, mismas reglas”. Esto significa que las plataformas de custodia deben construirse desde cero con flujos de datos compatibles y controles auditables.


Objetivos de Diseño (Cómo Se Ve lo “Bueno”)

Una pila de custodia de alto rendimiento debe construirse alrededor de unos pocos principios de diseño centrales:

  • Latencia que puedas presupuestar: Cada milisegundo desde la intención del cliente hasta la difusión en la red debe medirse, gestionarse y aplicarse con estrictos Objetivos de Nivel de Servicio (SLO).
  • Ejecución resiliente al MEV: Las órdenes sensibles deben enrutarse por canales privados por defecto. La exposición al mempool público debe ser una elección intencional, no un valor predeterminado inevitable.
  • Material de clave con garantías reales: Las llaves privadas nunca deben salir de sus límites protegidos, ya sea que estén distribuidas en fragmentos de MPC, almacenadas en HSM o aisladas en Entornos de Ejecución Confiables (TEE). La rotación de llaves, la imposición de quórum y los procedimientos de recuperación robustos son requisitos básicos.
  • Confiabilidad activa/activa: El sistema debe ser resiliente a fallas. Esto requiere redundancia multirregional y multiproveedor tanto para nodos RPC como para firmantes, complementada con disyuntores automáticos y kill‑switches para incidentes de sede y red.
  • Cumplimiento por construcción: El cumplimiento no puede ser una reflexión tardía. La arquitectura debe tener ganchos incorporados para datos de la Regla de Viaje, verificaciones AML/KYT y rastros de auditoría inmutables, con todos los controles mapeados directamente a marcos reconocidos como los Criterios de Servicios de Confianza SOC 2.

Arquitectura de Referencia

Este diagrama ilustra una arquitectura de alto nivel para una plataforma de custodia y ejecución que cumple con estos objetivos.

  • El Motor de Políticas y Riesgos es el guardián central de cada instrucción. Evalúa todo—cargas útiles de la Regla de Viaje, límites de velocidad, puntuaciones de riesgo de direcciones y requisitos de quórum de firmantes—antes de que se acceda a cualquier material de clave.
  • El Orquestador de Firmantes enruta inteligentemente las solicitudes de firma al plano de control más apropiado para el activo y la política. Esto podría ser:
    • MPC (Computación Multipartita) usando esquemas de firma por umbral (como t‑of‑n ECDSA/EdDSA) para distribuir la confianza entre múltiples partes o dispositivos.
    • HSM (Módulos de Seguridad de Hardware) para custodia de llaves con hardware y políticas de respaldo y rotación determinísticas.
    • Entornos de Ejecución Confiables (p. ej., AWS Nitro Enclaves) para aislar el código de firma y vincular llaves directamente a software atestiguado y medido.
  • El Enrutador de Ejecución envía transacciones por la ruta óptima. Prefiere envío privado de transacciones para órdenes grandes o con información sensible para evitar front‑running. Recurre al envío público cuando sea necesario, usando failover multiproveedor de RPC para mantener alta disponibilidad incluso durante caídas de red.
  • La Capa de Observabilidad brinda una vista en tiempo real del estado del sistema. Observa el mempool y los nuevos bloques mediante suscripciones, reconcilia operaciones ejecutadas contra registros internos y compromete registros de auditoría inmutables para cada decisión, firma y difusión.

Bloques de Seguridad (y Por Qué Importan)

  • Firmas por Umbral (MPC): Esta tecnología distribuye el control sobre una llave privada de modo que ninguna máquina—ni persona—pueda mover fondos de forma unilateral. Los protocolos MPC modernos pueden implementar firmas rápidas y seguras contra adversarios, adecuadas para presupuestos de latencia de producción.
  • HSM y Alineación FIPS: Los HSM imponen límites de llaves con hardware resistente a manipulaciones y políticas de seguridad documentadas. Alinear con estándares como FIPS 140‑3 y NIST SP 800‑57 brinda garantías de seguridad auditables y ampliamente comprendidas.
  • TEE Atestados: Los Entornos de Ejecución Confiables vinculan llaves a código específico y medido que se ejecuta en enclaves aislados. Usando un Servicio de Gestión de Llaves (KMS), puedes crear políticas que solo liberen material de llave a estas cargas de trabajo atestiguadas, asegurando que solo el código aprobado pueda firmar.
  • Relés Privados para Protección MEV: Estos servicios permiten enviar transacciones sensibles directamente a constructores de bloques o validadores, evitando el mempool público. Esto reduce drásticamente el riesgo de front‑running y otras formas de MEV.
  • Liquidación Fuera de Intercambio: Este modelo permite mantener colateral en custodia segregada mientras se opera en venues centralizados. Limita la exposición a contrapartes, acelera la liquidación neta y libera capital.
  • Controles Mapeados a SOC 2/ISO: Documentar y probar tus controles operacionales contra marcos reconocidos permite a clientes, auditores y socios confiar—and verificar independientemente—tu postura de seguridad y cumplimiento.

Manual de Latencia: Dónde Van los Milisegundos

Para lograr una ejecución de baja latencia, debes optimizar cada paso del ciclo de vida de la transacción:

  • Intención → Decisión de Política: Mantén la lógica de evaluación de políticas caliente en memoria. Cachea datos de Know‑Your‑Transaction (KYT) y listas de permitidos con TTL cortos y acotados, y pre‑calcula quórums de firmantes cuando sea posible.
  • Firma: Usa sesiones MPC persistentes y manejadores de llaves HSM para evitar la sobrecarga de arranques en frío. Para TEEs, fija los enclaves, calienta sus rutas de atestiguación y reutiliza llaves de sesión cuando sea seguro hacerlo.
  • Difusión: Prefiere conexiones WebSocket persistentes a nodos RPC sobre HTTP. Co‑ubica tus servicios de ejecución con las regiones de tus proveedores RPC primarios. Cuando la latencia se dispara, reintenta de forma idempotente y cubre difusiones a través de múltiples proveedores.
  • Confirmación: En lugar de sondear el estado de la transacción, suscríbete a recibos y eventos directamente desde la red. Transmite estos cambios de estado a una canalización de reconciliación para retroalimentación inmediata al usuario y contabilidad interna.

Establece SLO estrictos para cada salto (p. ej., verificación de política < 20 ms, firma < 50‑100 ms, difusión < 50 ms bajo carga normal) y hazlos cumplir con presupuestos de error y failover automatizado cuando las latencias p95 o p99 se degraden.


Riesgo y Cumplimiento por Diseño

Una pila moderna de custodia debe tratar el cumplimiento como parte integral del sistema, no como un añadido.

  • Orquestación de la Regla de Viaje: Genera y valida datos de originador y beneficiario en línea con cada instrucción de transferencia. Bloquea o desvía automáticamente transacciones que involucren VASPs (Proveedores de Servicios de Activos Virtuales) desconocidos y registra recibos criptográficos de cada intercambio de datos para fines de auditoría.
  • Riesgo de Dirección y Listas de Permitidos: Integra análisis on‑chain y listas de sanciones directamente en el motor de políticas. Aplica una postura de denegación por defecto, donde las transferencias solo se permiten a direcciones explícitamente permitidas o bajo excepciones de política específicas.
  • Auditoría Inmutable: Hashea cada solicitud, aprobación, firma y difusión en un libro de contabilidad append‑only. Esto crea una cadena de auditoría a prueba de manipulaciones que puede transmitirse a un SIEM para detección de amenazas en tiempo real y entregarse a auditores para pruebas de control.
  • Marco de Control: Mapea cada control técnico y operativo a los Criterios de Servicios de Confianza SOC 2 (Seguridad, Disponibilidad, Integridad del Procesamiento, Confidencialidad y Privacidad) e implementa un programa de pruebas y validaciones continuas.

Liquidación Fuera de Intercambio: Conectividad de Sede Más Segura

Una pila de custodia construida para escala institucional debe minimizar activamente la exposición a exchanges. Las redes de liquidación fuera de intercambio son un habilitador clave de esto. Permiten a una firma mantener activos en su propia custodia segregada mientras el exchange refleja ese colateral para habilitar trading instantáneo. La liquidación final ocurre en una cadencia fija con garantías tipo Delivery versus Payment (DvP).

Este diseño reduce drásticamente la huella de “hot wallet” y el riesgo de contrapartida asociado, al tiempo que preserva la velocidad requerida para trading activo. También mejora la eficiencia de capital, ya que ya no es necesario sobre‑financiar saldos inactivos en múltiples venues, y simplifica la gestión de riesgo operativo al mantener el colateral segregado y totalmente auditado.


Lista de Verificación de Controles (Copiar/Pegar en tu Runbook)

  • Custodia de Llaves
    • MPC usando umbral t‑of‑n a través de dominios de confianza independientes (p. ej., multi‑cloud, on‑prem, HSM).
    • Usa módulos validados FIPS cuando sea factible; mantén planes de rotación de llaves trimestral y re‑keying ante incidentes.
  • Política y Aprobaciones
    • Implementa un motor de políticas dinámico con límites de velocidad, heurísticas de comportamiento y restricciones horarias.
    • Requiere aprobación de cuatro ojos para operaciones de alto riesgo.
    • Aplica listas de permitidos y verificaciones de la Regla de Viaje antes de cualquier operación de firma.
  • Endurecimiento de Ejecución
    • Usa relés de transacciones privados por defecto para órdenes grandes o sensibles.
    • Utiliza proveedores RPC duales con cobertura basada en salud y protección robusta contra re‑replay.
  • Monitoreo y Respuesta
    • Implementa detección de anomalías en tiempo real sobre tasas de intención, outliers de precios de gas y fallos de inclusión de transacciones.
    • Mantén un kill‑switch de un clic para congelar todos los firmantes por activo o por venue.
  • Cumplimiento y Auditoría
    • Mantén un registro de eventos inmutable para todas las acciones del sistema.
    • Realiza pruebas continuas alineadas con SOC 2.
    • Asegura retención robusta de toda evidencia de la Regla de Viaje.

Notas de Implementación

  • Personas y Procesos Primero: La tecnología no puede arreglar políticas de autorización ambiguas o falta de claridad en la propiedad de on‑call. Define claramente quién está autorizado a cambiar políticas, promover código de firmantes, rotar llaves y aprobar excepciones.
  • Minimiza la Complejidad Donde Puedas: Cada nueva blockchain, puente o venue que integres añade riesgo operacional no lineal. Agrégalos deliberadamente, con cobertura de pruebas clara, monitoreo y planes de rollback.
  • Prueba como un Adversario: Realiza regularmente simulacros de ingeniería del caos. Simula pérdida de firmantes, fallas de atestiguación de enclaves, mempools estancados, throttling de APIs de venues y datos de la Regla de Viaje malformados para asegurar que tu sistema sea resiliente.
  • Demuestra los KPIs que Realmente Importan a tus Clientes:
    • Tiempo de difusión y tiempo a la primera confirmación (p95/p99).
    • Porcentaje de transacciones enviadas por rutas seguras contra MEV versus mempool público.
    • Utilización de venues y ganancias de eficiencia de colateral al usar liquidación fuera de intercambio.
    • Métricas de efectividad de controles, como porcentaje de transferencias con datos completos de la Regla de Viaje adjuntos y tasa de cierre de hallazgos de auditoría.

Conclusión

Una plataforma de custodia digna de flujos institucionales ejecuta rápido, prueba sus controles y limita el riesgo de contrapartida e información—todo al mismo tiempo. Esto requiere una pila profundamente integrada construida sobre enrutamiento consciente de MEV, firmas ancladas en hardware o basadas en MPC, infraestructura activa/activa, y liquidación fuera de intercambio que mantiene los activos seguros mientras accede a liquidez global. Al incorporar estos componentes en una única canalización medida, entregas lo que los clientes institucionales más valoran: certeza a velocidad.

Mensajería entre Cadenas y Liquidez Compartida: Modelos de Seguridad de LayerZero v2, Hyperlane e IBC 3.0

· 60 min de lectura
Dora Noda
Software Engineer

Los protocolos de interoperabilidad como LayerZero v2, Hyperlane e IBC 3.0 están emergiendo como infraestructura crítica para un ecosistema DeFi multicadena. Cada uno adopta un enfoque diferente para la mensajería entre cadenas y la liquidez compartida, con modelos de seguridad distintos:

  • LayerZero v2 – un modelo de agregación de pruebas que utiliza Redes de Verificadores Descentralizados (DVNs).
  • Hyperlane – un marco modular que a menudo utiliza un comité de validadores multifirma.
  • IBC 3.0 – un protocolo de cliente ligero con retransmisores de confianza minimizada en el ecosistema de Cosmos.

Este informe analiza los mecanismos de seguridad de cada protocolo, compara los pros y los contras de los clientes ligeros frente a las multifirmas frente a la agregación de pruebas, y examina su impacto en la componibilidad y la liquidez de DeFi. También revisamos las implementaciones actuales, los modelos de amenaza y los niveles de adopción, concluyendo con una perspectiva sobre cómo estas elecciones de diseño afectan la viabilidad a largo plazo de un DeFi multicadena.

Mecanismos de Seguridad de los Principales Protocolos entre Cadenas

LayerZero v2: Agregación de Pruebas con Redes de Verificadores Descentralizados (DVNs)

LayerZero v2 es un protocolo de mensajería omnichain que enfatiza una capa de seguridad modular y configurable por la aplicación. La idea central es permitir que las aplicaciones aseguren los mensajes con una o más Redes de Verificadores Descentralizados (DVNs) independientes, que en conjunto dan fe de los mensajes entre cadenas. En el modelo de agregación de pruebas de LayerZero, cada DVN es esencialmente un conjunto de verificadores que pueden validar un mensaje de forma independiente (por ejemplo, verificando una prueba de bloque o una firma). Una aplicación puede requerir pruebas agregadas de múltiples DVNs antes de aceptar un mensaje, formando una "pila de seguridad" de umbral.

Por defecto, LayerZero proporciona algunas DVNs listas para usar; por ejemplo, una DVN operada por LayerZero Labs que utiliza una validación multifirma de 2 de 3, y una DVN gestionada por Google Cloud. Pero, de manera crucial, los desarrolladores pueden combinar DVNs: por ejemplo, uno podría requerir una configuración de "1 de 3 de 5", lo que significa que una DVN específica debe firmar, además de 2 de otras 5. Esta flexibilidad permite combinar diferentes métodos de verificación (clientes ligeros, zkProofs, oráculos, etc.) en una prueba agregada. En efecto, LayerZero v2 generaliza el modelo de Nodo Ultra Ligero de la v1 (que dependía de un Relayer + un Oráculo) en una agregación multifirma X de Y de N a través de DVNs. El contrato Endpoint de LayerZero de una aplicación en cada cadena solo entregará un mensaje si el quórum de DVN requerido ha escrito atestaciones válidas para ese mensaje.

Características de seguridad: El enfoque de LayerZero tiene una confianza minimizada en la medida en que al menos una DVN en el conjunto requerido sea honesta (o una prueba zk sea válida, etc.). Al permitir que las aplicaciones ejecuten su propia DVN como firmante requerido, LayerZero incluso permite que una aplicación vete cualquier mensaje a menos que sea aprobado por el verificador del equipo de la aplicación. Esto puede endurecer significativamente la seguridad (a costa de la centralización), asegurando que ningún mensaje entre cadenas se ejecute sin la firma de la aplicación. Por otro lado, los desarrolladores pueden elegir un quórum de DVN más descentralizado (por ejemplo, 5 de 15 redes independientes) para una distribución de confianza más fuerte. LayerZero llama a esto "seguridad propiedad de la aplicación": cada aplicación elige el equilibrio entre seguridad, costo y rendimiento al configurar sus DVNs. Todas las atestaciones de DVN se verifican en última instancia en la cadena mediante contratos inmutables de Endpoint de LayerZero, preservando una capa de transporte sin permisos. La desventaja es que la seguridad es tan fuerte como las DVNs elegidas; si las DVNs configuradas conspiran o se ven comprometidas, podrían aprobar un mensaje fraudulento entre cadenas. Por lo tanto, la responsabilidad recae en cada aplicación de seleccionar DVNs robustas o arriesgarse a una seguridad más débil.

Hyperlane: Modelo de Validador Multifirma con ISMs Modulares

Hyperlane es un marco de interoperabilidad centrado en un Módulo de Seguridad Intercadena (ISM) en la cadena que verifica los mensajes antes de que se entreguen en la cadena de destino. En la configuración más simple (y predeterminada), el ISM de Hyperlane utiliza un conjunto de validadores multifirma: un comité de validadores fuera de la cadena firma atestaciones (a menudo una raíz de Merkle de todos los mensajes salientes) desde la cadena de origen, y se requiere un umbral de firmas en el destino. En otras palabras, Hyperlane se basa en un quórum de validadores con permisos para confirmar que "el mensaje X fue emitido en la cadena A", análogo al consenso de una blockchain pero a nivel de puente. Por ejemplo, Wormhole utiliza 19 guardianes con una multifirma de 13 de 19; el enfoque de Hyperlane es similar en espíritu (aunque Hyperlane es distinto de Wormhole).

Una característica clave es que Hyperlane no tiene un único conjunto de validadores consagrado a nivel de protocolo. En cambio, cualquiera puede ejecutar un validador, y diferentes aplicaciones pueden desplegar contratos ISM con diferentes listas de validadores y umbrales. El protocolo Hyperlane proporciona despliegues de ISM predeterminados (con un conjunto de validadores que el equipo inició), pero los desarrolladores son libres de personalizar el conjunto de validadores o incluso el modelo de seguridad para su aplicación. De hecho, Hyperlane admite múltiples tipos de ISMs, incluyendo un ISM de Agregación que combina múltiples métodos de verificación, y un ISM de Enrutamiento que elige un ISM basado en los parámetros del mensaje. Por ejemplo, una aplicación podría requerir que tanto una multifirma de Hyperlane como un puente externo (como Wormhole o Axelar) firmen, logrando un nivel de seguridad más alto a través de la redundancia.

Características de seguridad: La seguridad base del modelo multifirma de Hyperlane proviene de la honestidad de la mayoría de sus validadores. Si el umbral (por ejemplo, 5 de 8) de validadores conspira, podrían firmar un mensaje fraudulento, por lo que la suposición de confianza es aproximadamente una confianza multifirma N de M. Hyperlane está abordando este riesgo integrándose con el restaking de EigenLayer, creando un Módulo de Seguridad Económica (ESM) que requiere que los validadores pongan en juego ETH que puede ser penalizado (slashing) por mal comportamiento. Este "Servicio Validado Activamente (AVS)" significa que si un validador de Hyperlane firma un mensaje inválido (uno que no está realmente en el historial de la cadena de origen), cualquiera puede presentar una prueba en Ethereum para penalizar la participación de ese validador. Esto fortalece significativamente el modelo de seguridad al desincentivar económicamente el fraude: los mensajes entre cadenas de Hyperlane pasan a estar asegurados por el peso económico de Ethereum, no solo por la reputación social de los validadores. Sin embargo, una contrapartida es que depender de Ethereum para el slashing introduce una dependencia de la liveness de Ethereum y asume que las pruebas de fraude son factibles de presentar a tiempo. En términos de liveness, Hyperlane advierte que si no hay suficientes validadores en línea para alcanzar el umbral, la entrega de mensajes puede detenerse. El protocolo mitiga esto permitiendo una configuración de umbral flexible, por ejemplo, utilizando un conjunto de validadores más grande para que el tiempo de inactividad ocasional no detenga la red. En general, el enfoque multifirma modular de Hyperlane proporciona flexibilidad y capacidad de actualización (las aplicaciones eligen su propia seguridad o combinan múltiples fuentes) a costa de añadir confianza en un conjunto de validadores. Este es un modelo de confianza más débil que un verdadero cliente ligero, pero con innovaciones recientes (como colateral en restaking y slashing) puede acercarse a garantías de seguridad similares en la práctica mientras sigue siendo más fácil de desplegar en muchas cadenas.

IBC 3.0: Clientes Ligeros con Retransmisores de Confianza Minimizada

El protocolo de Comunicación entre Cadenas de Bloques (IBC), ampliamente utilizado en el ecosistema de Cosmos, adopta un enfoque fundamentalmente diferente: utiliza clientes ligeros en la cadena para verificar el estado entre cadenas, en lugar de introducir un nuevo conjunto de validadores. En IBC, cada par de cadenas establece una conexión donde la Cadena B mantiene un cliente ligero de la Cadena A (y viceversa). Este cliente ligero es esencialmente una réplica simplificada del consenso de la otra cadena (por ejemplo, rastreando las firmas del conjunto de validadores o los hashes de los bloques). Cuando la Cadena A envía un mensaje (un paquete IBC) a la Cadena B, un retransmisor (un actor fuera de la cadena) lleva una prueba (prueba de Merkle del paquete y la cabecera del último bloque) a la Cadena B. El módulo IBC de la Cadena B utiliza entonces el cliente ligero en la cadena para verificar que la prueba es válida según las reglas de consenso de la Cadena A. Si la prueba se verifica (es decir, el paquete fue comprometido en un bloque finalizado en A), el mensaje es aceptado y entregado al módulo de destino en B. En esencia, la Cadena B confía directamente en el consenso de la Cadena A, no en un intermediario; por eso IBC a menudo se llama interoperabilidad de confianza minimizada.

IBC 3.0 se refiere a la última evolución de este protocolo (alrededor de 2025), que introduce mejoras de rendimiento y características: retransmisión en paralelo para menor latencia, tipos de canales personalizados para casos de uso especializados y Consultas Intercadena para leer el estado remoto. Es importante destacar que ninguna de estas cambia el modelo de seguridad central del cliente ligero; mejoran la velocidad y la funcionalidad. Por ejemplo, la retransmisión en paralelo significa que múltiples retransmisores pueden transportar paquetes simultáneamente para evitar cuellos de botella, mejorando la liveness sin sacrificar la seguridad. Las Consultas Intercadena (ICQ) permiten que un contrato en la Cadena A pida datos a la Cadena B (con una prueba), que luego es verificada por el cliente ligero de B en A. Esto extiende las capacidades de IBC más allá de las transferencias de tokens a un acceso a datos entre cadenas más general, todavía respaldado por pruebas de cliente ligero verificadas.

Características de seguridad: La garantía de seguridad de IBC es tan fuerte como la integridad de la cadena de origen. Si la Cadena A tiene una mayoría honesta (o el umbral de consenso configurado) y el cliente ligero de A en la Cadena B está actualizado, entonces cualquier paquete aceptado debe haber provenido de un bloque válido en A. No hay necesidad de confiar en ningún validador de puente u oráculo; las únicas suposiciones de confianza son el consenso nativo de las dos cadenas y algunos parámetros como el período de confianza del cliente ligero (después del cual las cabeceras antiguas expiran). Los retransmisores en IBC no necesitan ser confiables; no pueden falsificar cabeceras o paquetes válidos porque fallarían la verificación. En el peor de los casos, un retransmisor malicioso o fuera de línea puede censurar o retrasar mensajes, pero cualquiera puede ejecutar un retransmisor, por lo que la liveness se logra eventualmente si existe al menos un retransmisor honesto. Este es un modelo de seguridad muy fuerte: efectivamente descentralizado y sin permisos por defecto, reflejando las propiedades de las propias cadenas. Las contrapartidas vienen en costo y complejidad: ejecutar un cliente ligero (especialmente de una cadena de alto rendimiento) en otra cadena puede ser intensivo en recursos (almacenar cambios en el conjunto de validadores, verificar firmas, etc.). Para las cadenas del SDK de Cosmos que usan Tendermint/BFT, este costo es manejable e IBC es muy eficiente; pero integrar cadenas heterogéneas (como Ethereum o Solana) requiere implementaciones de cliente complejas o nueva criptografía. De hecho, la conexión de cadenas no-Cosmos a través de IBC ha sido más lenta; proyectos como Polymer y Composable están trabajando en clientes ligeros o pruebas zk para extender IBC a Ethereum y otros. Las mejoras de IBC 3.0 (por ejemplo, clientes ligeros optimizados, soporte para diferentes métodos de verificación) tienen como objetivo reducir estos costos. En resumen, el modelo de cliente ligero de IBC ofrece las garantías de confianza más fuertes (sin validadores externos en absoluto) y una sólida liveness (dado que hay múltiples retransmisores), a expensas de una mayor complejidad de implementación y limitaciones de que todas las cadenas participantes deben soportar el protocolo IBC.

Comparando Clientes Ligeros, Multifirmas y Agregación de Pruebas

Cada modelo de seguridad – clientes ligeros (IBC), multifirmas de validadores (Hyperlane) y pruebas agregadas (LayerZero) – viene con pros y contras distintos. A continuación, los comparamos en dimensiones clave:

Garantías de Seguridad

  • Clientes Ligeros (IBC): Ofrece la máxima seguridad al anclar la verificación en la cadena al consenso de la cadena de origen. No hay una nueva capa de confianza; si confías en que la blockchain de origen (por ejemplo, Cosmos Hub o Ethereum) no producirá bloques dobles, confías en los mensajes que envía. Esto minimiza las suposiciones de confianza adicionales y la superficie de ataque. Sin embargo, si el conjunto de validadores de la cadena de origen se corrompe (por ejemplo, >⅓ en Tendermint o >½ en una cadena PoS se vuelven maliciosos), el cliente ligero puede recibir una cabecera fraudulenta. En la práctica, los canales IBC generalmente se establecen entre cadenas económicamente seguras, y los clientes ligeros pueden tener parámetros (como el período de confianza y los requisitos de finalidad del bloque) para mitigar los riesgos. En general, la minimización de la confianza es la ventaja más fuerte del modelo de cliente ligero: hay una prueba criptográfica de validez para cada mensaje.

  • Validadores Multifirma (Hyperlane y puentes similares): La seguridad depende de la honestidad de un conjunto de firmantes fuera de la cadena. Un umbral típico (por ejemplo, ⅔ de los validadores) debe aprobar cada mensaje entre cadenas o punto de control de estado. La ventaja es que esto puede hacerse razonablemente seguro con suficientes validadores de buena reputación o con participación económica. Por ejemplo, los 19 guardianes de Wormhole o el comité predeterminado de Hyperlane tendrían que conspirar colectivamente para comprometer el sistema. La desventaja es que esto introduce una nueva suposición de confianza: los usuarios deben confiar en el comité del puente además de en las cadenas. Esto ha demostrado ser un punto de fallo en algunos hackeos (por ejemplo, si se roban claves privadas o si los insiders conspiran). Iniciativas como el colateral de ETH en restaking de Hyperlane añaden seguridad económica a este modelo: los validadores que firman datos inválidos pueden ser penalizados automáticamente en Ethereum. Esto acerca los puentes multifirma a la seguridad de una blockchain (al castigar financieramente el fraude), pero todavía no es tan minimizado en confianza como un cliente ligero. En resumen, las multifirmas son más débiles en garantías de confianza: uno depende de una mayoría de un grupo pequeño, aunque el slashing y las auditorías pueden reforzar la confianza.

  • Agregación de Pruebas (LayerZero v2): Esto es, en cierto modo, un punto intermedio. Si una aplicación configura su Pila de Seguridad para incluir una DVN de cliente ligero o una DVN de prueba zk, entonces la garantía puede acercarse al nivel de IBC (matemáticas y consenso de la cadena) para esas verificaciones. Si utiliza una DVN basada en un comité (como la predeterminada de 2 de 3 de LayerZero o un adaptador de Axelar), entonces hereda las suposiciones de confianza de esa multifirma. La fortaleza del modelo de LayerZero es que puedes combinar múltiples verificadores independientemente. Por ejemplo, requerir tanto "una prueba zk es válida" como "el oráculo de Chainlink dice que la cabecera del bloque es X" como "nuestro propio validador firma" podría reducir drásticamente las posibilidades de ataque (un atacante necesitaría romper todo a la vez). Además, al permitir que una aplicación exija su propia DVN, LayerZero asegura que ningún mensaje se ejecutará sin el consentimiento de la aplicación, si así se configura. La debilidad es que si los desarrolladores eligen una configuración de seguridad laxa (por tarifas más baratas o velocidad), podrían socavar la seguridad; por ejemplo, usar una única DVN gestionada por una parte desconocida sería similar a confiar en un solo validador. LayerZero en sí mismo es no opinativo y deja estas elecciones a los desarrolladores de aplicaciones, lo que significa que la seguridad es tan buena como las DVNs elegidas. En resumen, la agregación de pruebas puede proporcionar una seguridad muy fuerte (incluso mayor que un solo cliente ligero, al requerir múltiples pruebas independientes) pero también permite configuraciones débiles si se configura incorrectamente. Es flexible: una aplicación puede aumentar la seguridad para transacciones de alto valor (por ejemplo, requerir múltiples DVNs grandes) y disminuirla para las de bajo valor.

Liveness y Disponibilidad

  • Clientes Ligeros (IBC): La liveness depende de los retransmisores y de que el cliente ligero se mantenga actualizado. El lado positivo es que cualquiera puede ejecutar un retransmisor, por lo que el sistema no depende de un conjunto específico de nodos; si un retransmisor se detiene, otro puede tomar el relevo. La retransmisión en paralelo de IBC 3.0 mejora aún más la disponibilidad al no serializar todos los paquetes a través de una sola ruta. En la práctica, las conexiones IBC han sido muy fiables, pero hay escenarios donde la liveness puede sufrir: por ejemplo, si ningún retransmisor publica una actualización durante mucho tiempo, un cliente ligero podría expirar (por ejemplo, si el período de confianza pasa sin renovación) y entonces el canal se cierra por seguridad. Sin embargo, tales casos son raros y se mitigan con redes de retransmisores activas. Otra consideración de liveness: los paquetes IBC están sujetos a la finalidad de la cadena de origen; por ejemplo, esperar 1-2 bloques en Tendermint (unos pocos segundos) es estándar. En general, IBC proporciona una alta disponibilidad siempre que haya al menos un retransmisor activo, y la latencia suele ser baja (segundos) para bloques finalizados. No existe el concepto de un quórum de validadores que se desconecte como en la multifirma; la propia finalidad del consenso de la blockchain es el principal factor de latencia.

  • Validadores Multifirma (Hyperlane): La liveness puede ser una debilidad si el conjunto de validadores es pequeño. Por ejemplo, si un puente tiene una multifirma de 5 de 8 y 4 validadores están fuera de línea o inaccesibles, la mensajería entre cadenas se detiene porque no se puede alcanzar el umbral. La documentación de Hyperlane señala que el tiempo de inactividad de los validadores puede detener la entrega de mensajes, dependiendo del umbral configurado. Esto es en parte por lo que se podría elegir tener un comité más grande o un umbral más bajo (con una contrapartida de seguridad) para mejorar el tiempo de actividad. El diseño de Hyperlane permite desplegar nuevos validadores o cambiar de ISM si es necesario, pero tales cambios pueden requerir coordinación/gobernanza. La ventaja que tienen los puentes multifirma es típicamente una confirmación rápida una vez que se recogen las firmas del umbral; no es necesario esperar la finalidad del bloque de una cadena de origen en la cadena de destino, ya que la atestación multifirma es la finalidad. En la práctica, muchos puentes multifirma firman y retransmiten mensajes en segundos. Por lo tanto, la latencia puede ser comparable o incluso menor que la de los clientes ligeros para algunas cadenas. El cuello de botella es si los validadores son lentos o están distribuidos geográficamente, o si hay pasos manuales involucrados. En resumen, los modelos multifirma pueden tener una alta liveness y baja latencia la mayor parte del tiempo, pero tienen un riesgo de liveness concentrado en el conjunto de validadores: si demasiados validadores fallan o se produce una partición de red entre ellos, el puente está efectivamente caído.

  • Agregación de Pruebas (LayerZero): La liveness aquí depende de la disponibilidad de cada DVN y el retransmisor. Un mensaje debe reunir firmas/pruebas de las DVNs requeridas y luego ser retransmitido a la cadena de destino. El aspecto positivo es que las DVNs operan de forma independiente: si una DVN (de un conjunto) está caída y no es requerida (solo parte de un "M de N"), el mensaje aún puede proceder siempre que se cumpla el umbral. El modelo de LayerZero permite explícitamente configurar quórums para tolerar algunos fallos de DVN. Por ejemplo, un conjunto de DVN "2 de 5" puede manejar 3 DVNs fuera de línea sin detener el protocolo. Además, debido a que cualquiera puede ejecutar el rol final de Ejecutor/Retransmisor, no hay un único punto de fallo para la entrega de mensajes; si el retransmisor principal falla, un usuario u otra parte puede llamar al contrato con las pruebas (esto es análogo al concepto de retransmisor sin permisos en IBC). Por lo tanto, LayerZero v2 se esfuerza por la resistencia a la censura y la liveness al no vincular el sistema a un solo intermediario. Sin embargo, si las DVNs requeridas son parte de la pila de seguridad (digamos que una aplicación requiere que su propia DVN siempre firme), entonces esa DVN es una dependencia de liveness: si se desconecta, los mensajes se pausarán hasta que vuelva o se cambie la política de seguridad. En general, la agregación de pruebas se puede configurar para ser robusta (con DVNs redundantes y retransmisión por cualquier parte) de modo que sea poco probable que todos los verificadores estén caídos a la vez. La contrapartida es que contactar con múltiples DVNs podría introducir un poco más de latencia (por ejemplo, esperar varias firmas) en comparación con una única multifirma más rápida. Pero esas DVNs podrían ejecutarse en paralelo, y muchas DVNs (como una red de oráculos o un cliente ligero) pueden responder rápidamente. Por lo tanto, LayerZero puede lograr una alta liveness y baja latencia, pero el rendimiento exacto depende de cómo se configuren las DVNs (algunas podrían esperar algunas confirmaciones de bloque en la cadena de origen, etc., lo que podría añadir retraso por seguridad).

Costo y Complejidad

  • Clientes Ligeros (IBC): Este enfoque tiende a ser complejo de implementar pero barato de usar una vez configurado en cadenas compatibles. La complejidad radica en escribir una implementación correcta de cliente ligero para cada tipo de blockchain; esencialmente, estás codificando las reglas de consenso de la Cadena A en un contrato inteligente en la Cadena B. Para las cadenas del SDK de Cosmos con un consenso similar, esto fue sencillo, pero extender IBC más allá de Cosmos ha requerido una ingeniería pesada (por ejemplo, construir un cliente ligero para la finalidad GRANDPA de Polkadot, o planes para clientes ligeros de Ethereum con pruebas zk). Estas implementaciones no son triviales y deben ser altamente seguras. También hay una sobrecarga de almacenamiento en la cadena: el cliente ligero necesita almacenar información reciente del conjunto de validadores o de la raíz de estado de la otra cadena. Esto puede aumentar el tamaño del estado y el costo de verificación de pruebas en la cadena. Como resultado, ejecutar IBC en, digamos, la red principal de Ethereum directamente (verificando cabeceras de Cosmos) sería costoso en términos de gas; una razón por la cual proyectos como Polymer están creando un rollup de Ethereum para alojar estos clientes ligeros fuera de la red principal. Dentro del ecosistema de Cosmos, las transacciones IBC son muy eficientes (a menudo solo unos pocos céntimos de dólar en gas) porque la verificación del cliente ligero (firmas ed25519, pruebas de Merkle) está bien optimizada a nivel de protocolo. Usar IBC es relativamente de bajo costo para los usuarios, y los retransmisores solo pagan las tarifas de transacción normales en las cadenas de destino (pueden ser incentivados con tarifas a través del middleware ICS-29). En resumen, el costo de IBC se concentra en la complejidad del desarrollo, pero una vez en funcionamiento, proporciona un transporte nativo y eficiente en tarifas. Las muchas cadenas de Cosmos conectadas (más de 100 zonas) comparten una implementación común, lo que ayuda a gestionar la complejidad mediante la estandarización.

  • Puentes Multifirma (Hyperlane/Wormhole/etc.): La complejidad de implementación aquí suele ser menor: los contratos de puente principales necesitan principalmente verificar un conjunto de firmas contra claves públicas almacenadas. Esta lógica es más simple que un cliente ligero completo. El software de validador fuera de la cadena introduce complejidad operativa (servidores que observan eventos de la cadena, mantienen un árbol de Merkle de mensajes, coordinan la recolección de firmas, etc.), pero esto es gestionado por los operadores del puente y se mantiene fuera de la cadena. Costo en la cadena: verificar unas pocas firmas (digamos 2 o 5 firmas ECDSA) no es demasiado caro, pero ciertamente es más gas que una única firma de umbral o una verificación de hash. Algunos puentes utilizan esquemas de firma agregada (por ejemplo, BLS) para reducir el costo en la cadena a la verificación de 1 firma. En general, la verificación multifirma en Ethereum o cadenas similares es moderadamente costosa (cada verificación de firma ECDSA cuesta ~3000 gas). Si un puente requiere 10 firmas, eso es ~30k de gas solo para la verificación, más cualquier almacenamiento de una nueva raíz de Merkle, etc. Esto suele ser aceptable dado que las transferencias entre cadenas son operaciones de alto valor, pero puede acumularse. Desde la perspectiva del desarrollador/usuario, interactuar con un puente multifirma es sencillo: depositas o llamas a una función de envío, y el resto es manejado fuera de la cadena por los validadores/retransmisores, luego se envía una prueba. Hay una complejidad mínima para los desarrolladores de aplicaciones, ya que solo integran la API/contrato del puente. Una consideración de complejidad es añadir nuevas cadenas: cada validador debe ejecutar un nodo o indexador para cada nueva cadena para observar los mensajes, lo que puede ser un dolor de cabeza de coordinación (esto se ha señalado como un cuello de botella para la expansión en algunos diseños multifirma). La respuesta de Hyperlane son los validadores sin permisos (cualquiera puede unirse para una cadena si el ISM los incluye), pero la aplicación que despliega el ISM todavía tiene que configurar esas claves inicialmente. En general, los modelos multifirma son más fáciles de iniciar en cadenas heterogéneas (no se necesita un cliente ligero a medida por cadena), lo que los hace más rápidos de lanzar al mercado, pero incurren en complejidad operativa fuera de la cadena y costos moderados de verificación en la cadena.

  • Agregación de Pruebas (LayerZero): La complejidad aquí está en la coordinación de muchos métodos de verificación posibles. LayerZero proporciona una interfaz estandarizada (los contratos Endpoint y MessageLib) y espera que las DVNs se adhieran a una cierta API de verificación. Desde la perspectiva de una aplicación, usar LayerZero es bastante simple (solo llamar a lzSend e implementar callbacks de lzReceive), pero por debajo, hay mucho en juego. Cada DVN puede tener su propia infraestructura fuera de la cadena (algunas DVNs son esencialmente mini-puentes en sí mismas, como una red de Axelar o un servicio de oráculo de Chainlink). El protocolo en sí es complejo porque debe agregar de forma segura tipos de prueba dispares; por ejemplo, una DVN podría proporcionar una prueba de bloque EVM, otra un SNARK, otra una firma, etc., y el contrato tiene que verificar cada una por turno. La ventaja es que gran parte de esta complejidad es abstraída por el marco de LayerZero. El costo depende de cuántas y qué tipo de pruebas se requieren: verificar un snark podría ser caro (la verificación de pruebas zk en la cadena puede costar cientos de miles de gas), mientras que verificar un par de firmas es más barato. LayerZero permite que la aplicación decida cuánto quiere pagar por seguridad por mensaje. También existe el concepto de pagar a las DVNs por su trabajo: la carga útil del mensaje incluye una tarifa por los servicios de DVN. Por ejemplo, una aplicación puede adjuntar tarifas que incentiven a las DVNs y a los Ejecutores a procesar el mensaje rápidamente. Esto añade una dimensión de costo: una configuración más segura (usando muchas DVNs o pruebas costosas) costará más en tarifas, mientras que una DVN simple de 1 de 1 (como un solo retransmisor) podría ser muy barata pero menos segura. La capacidad de actualización y la gobernanza también son parte de la complejidad: como las aplicaciones pueden cambiar su pila de seguridad, debe haber un proceso de gobernanza o una clave de administrador para hacerlo, lo que en sí mismo es un punto de confianza/complejidad a gestionar. En resumen, la agregación de pruebas a través de LayerZero es altamente flexible pero compleja por debajo. El costo por mensaje se puede optimizar eligiendo DVNs eficientes (por ejemplo, usando un cliente ultra-ligero optimizado, o aprovechando las economías de escala de una red de oráculos existente). Muchos desarrolladores encontrarán atractiva la naturaleza plug-and-play (con valores predeterminados proporcionados), por ejemplo, simplemente usar el conjunto de DVN predeterminado por facilidad, pero eso de nuevo puede llevar a suposiciones de confianza subóptimas si no se entiende.

Capacidad de Actualización y Gobernanza

  • Clientes Ligeros (IBC): Las conexiones y clientes IBC pueden ser actualizados a través de propuestas de gobernanza en la cadena en las cadenas participantes (particularmente si el cliente ligero necesita una corrección o una actualización para un hardfork en la cadena de origen). Actualizar el protocolo IBC en sí (digamos de las características de IBC 2.0 a 3.0) también requiere que la gobernanza de la cadena adopte nuevas versiones del software. Esto significa que IBC tiene una ruta de actualización deliberada: los cambios son lentos y requieren consenso, pero eso está alineado con su enfoque de seguridad primero. No hay una sola entidad que pueda cambiar algo; la gobernanza de cada cadena debe aprobar los cambios en los clientes o parámetros. Lo positivo es que esto previene cambios unilaterales que podrían introducir vulnerabilidades. Lo negativo es una menor agilidad; por ejemplo, si se encuentra un error en un cliente ligero, podría llevar votos de gobernanza coordinados en muchas cadenas para parchearlo (aunque existen mecanismos de coordinación de emergencia). Desde la perspectiva de una dApp, IBC realmente no tiene una "gobernanza a nivel de aplicación"; es infraestructura proporcionada por la cadena. Las aplicaciones simplemente usan módulos IBC (como transferencia de tokens o cuentas intercadena) y confían en la seguridad de la cadena. Por lo tanto, la gobernanza y las actualizaciones ocurren a nivel de blockchain (gobernanza del Hub y de la Zona). Una nueva característica interesante de IBC son los canales personalizados y el enrutamiento (por ejemplo, hubs como Polymer o Nexus) que pueden permitir cambiar los métodos de verificación subyacentes sin interrumpir las aplicaciones. Pero en general, IBC es estable y estandarizado: la capacidad de actualización es posible pero infrecuente, lo que contribuye a su fiabilidad.

  • Puentes Multifirma (Hyperlane/Wormhole): Estos sistemas a menudo tienen un mecanismo de administración o gobernanza para actualizar contratos, cambiar conjuntos de validadores o modificar parámetros. Por ejemplo, agregar un nuevo validador al conjunto o rotar claves podría requerir una multifirma del propietario del puente o un voto de DAO. El hecho de que Hyperlane sea sin permisos significa que cualquier usuario podría desplegar su propio ISM con un conjunto de validadores personalizado, pero si se usa el predeterminado, el equipo de Hyperlane o la comunidad probablemente controlan las actualizaciones. La capacidad de actualización es un arma de doble filo: por un lado, es fácil de actualizar/mejorar, por otro, puede ser un riesgo de centralización (si una clave privilegiada puede actualizar los contratos del puente, esa clave teóricamente podría robar los fondos del puente). Un protocolo bien gobernado limitará esto (por ejemplo, con actualizaciones con bloqueo de tiempo, o usando una gobernanza descentralizada). La filosofía de Hyperlane es la modularidad, por lo que una aplicación podría incluso enrutar alrededor de un componente que falla cambiando de ISM, etc. Esto da a los desarrolladores el poder de responder a las amenazas (por ejemplo, si se sospecha que un conjunto de validadores está comprometido, una aplicación podría cambiar a un modelo de seguridad diferente rápidamente). La carga de gobernanza es que las aplicaciones necesitan decidir su modelo de seguridad y potencialmente gestionar claves para sus propios validadores o prestar atención a las actualizaciones del protocolo central de Hyperlane. En resumen, los sistemas basados en multifirma son más actualizables (los contratos suelen ser actualizables y los comités configurables), lo cual es bueno para una mejora rápida y para agregar nuevas cadenas, pero requiere confianza en el proceso de gobernanza. Muchos exploits de puentes en el pasado han ocurrido a través de claves de actualización comprometidas o gobernanza defectuosa, por lo que esta área debe tratarse con cuidado. En el lado positivo, agregar soporte para una nueva cadena podría ser tan simple como desplegar los contratos y hacer que los validadores ejecuten nodos para ella, sin necesidad de un cambio fundamental en el protocolo.

  • Agregación de Pruebas (LayerZero): LayerZero promociona una capa de transporte inmutable (los contratos de endpoint no son actualizables), pero los módulos de verificación (Bibliotecas de Mensajes y adaptadores de DVN) son de solo adición y configurables. En la práctica, esto significa que el contrato central de LayerZero en cada cadena permanece fijo (proporcionando una interfaz estable), mientras que se pueden agregar nuevas DVNs u opciones de verificación con el tiempo sin alterar el núcleo. Los desarrolladores de aplicaciones tienen el control sobre su Pila de Seguridad: pueden agregar o eliminar DVNs, cambiar la profundidad de los bloques de confirmación, etc. Esta es una forma de capacidad de actualización a nivel de aplicación. Por ejemplo, si una DVN en particular se deprecia o surge una nueva y mejor (como un cliente zk más rápido), el equipo de la aplicación puede integrarla en su configuración, preparando la dApp para el futuro. El beneficio es evidente: las aplicaciones no están atascadas con la tecnología de seguridad de ayer; pueden adaptarse (con la debida precaución) a los nuevos desarrollos. Sin embargo, esto plantea preguntas de gobernanza: ¿quién dentro de la aplicación decide cambiar el conjunto de DVN? Idealmente, si la aplicación es descentralizada, los cambios pasarían por la gobernanza o estarían codificados si se desea inmutabilidad. Si un solo administrador puede alterar la pila de seguridad, eso es un punto de confianza (podrían reducir los requisitos de seguridad en una actualización maliciosa). La propia guía de LayerZero alienta a establecer una gobernanza robusta para tales cambios o incluso a hacer ciertos aspectos inmutables si es necesario. Otro aspecto de la gobernanza es la gestión de tarifas: el pago a las DVNs y retransmisores podría ajustarse, y los incentivos desalineados podrían afectar el rendimiento (aunque por defecto las fuerzas del mercado deberían ajustar las tarifas). En resumen, el modelo de LayerZero es altamente extensible y actualizable en términos de agregar nuevos métodos de verificación (lo cual es excelente para la interoperabilidad a largo plazo), pero la responsabilidad recae en cada aplicación de gobernar esas actualizaciones de manera responsable. Los contratos base de LayerZero son inmutables para garantizar que la capa de transporte no pueda ser objeto de un "rug-pull" o censura, lo que inspira confianza en que el canal de mensajería en sí permanece intacto a través de las actualizaciones.

Para resumir la comparación, la siguiente tabla destaca las diferencias clave:

AspectoIBC (Clientes Ligeros)Hyperlane (Multifirma)LayerZero v2 (Agregación)
Modelo de ConfianzaConfiar en el consenso de la cadena de origen (sin confianza adicional).Confiar en un comité de validadores de puente (por ejemplo, umbral multifirma). El slashing puede mitigar el riesgo.La confianza depende de las DVNs elegidas. Puede emular un cliente ligero o multifirma, o mezclarlos (confiar en al menos uno de los verificadores elegidos).
SeguridadLa más alta: prueba criptográfica de validez a través de un cliente ligero. Los ataques requieren comprometer la cadena de origen o el cliente ligero.Fuerte si el comité es una mayoría honesta, pero más débil que un cliente ligero. La colusión del comité o el compromiso de claves es la principal amenaza.Potencialmente muy alta: puede requerir múltiples pruebas independientes (por ejemplo, zk + multifirma + oráculo). Pero la seguridad configurable significa que solo es tan fuerte como las DVNs más débiles elegidas.
LivenessMuy buena siempre que al menos un retransmisor esté activo. Retransmisores en paralelo y cadenas de finalidad rápida ofrecen entrega casi en tiempo real.Buena en condiciones normales (firmas rápidas). Pero depende del tiempo de actividad de los validadores. El tiempo de inactividad del quórum de umbral = detención. La expansión a nuevas cadenas requiere el apoyo del comité.Muy buena; múltiples DVNs proporcionan redundancia, y cualquier usuario puede retransmitir transacciones. Las DVNs requeridas pueden ser puntos únicos de fallo si se configuran incorrectamente. La latencia se puede ajustar (por ejemplo, esperar confirmaciones vs. velocidad).
CostoComplejidad inicial para implementar clientes. Verificación en cadena del consenso (firmas, pruebas de Merkle) pero optimizada en Cosmos. Bajo costo por mensaje en entornos nativos de IBC; potencialmente caro en cadenas no nativas sin soluciones especiales.Menor complejidad de desarrollo para los contratos principales. El costo en la cadena escala con el número de firmas por mensaje. Costo de operaciones fuera de la cadena para los validadores (nodos en cada cadena). Posiblemente más gas que un cliente ligero si hay muchas firmas, pero a menudo manejable.Complejidad de moderada a alta. El costo por mensaje varía: cada prueba de DVN (firma o SNARK) agrega gas de verificación. Las aplicaciones pagan tarifas de DVN por el servicio. Se pueden optimizar los costos eligiendo menos o pruebas más baratas para mensajes de bajo valor.
Capacidad de ActualizaciónEl protocolo evoluciona a través de la gobernanza de la cadena (lento, conservador). Las actualizaciones del cliente ligero requieren coordinación, pero la estandarización lo mantiene estable. Agregar nuevas cadenas requiere construir/aprobar nuevos tipos de clientes.Flexible: los conjuntos de validadores y los ISMs se pueden cambiar a través de la gobernanza o un administrador. Más fácil de integrar nuevas cadenas rápidamente. Riesgo si las claves de actualización o la gobernanza se ven comprometidas. Típicamente contratos actualizables (necesita confianza en los administradores).Altamente modular: se pueden agregar nuevas DVNs/métodos de verificación sin alterar el núcleo. Las aplicaciones pueden cambiar la configuración de seguridad según sea necesario. Los endpoints centrales son inmutables (sin actualizaciones centrales), pero se necesita gobernanza a nivel de aplicación para los cambios de seguridad para evitar el mal uso.

Impacto en la Componibilidad y la Liquidez Compartida en DeFi

La mensajería entre cadenas desbloquea nuevos y potentes patrones para la componibilidad – la capacidad de los contratos DeFi en diferentes cadenas para interactuar – y permite la liquidez compartida – agrupar activos a través de cadenas como si estuvieran en un solo mercado. Los modelos de seguridad discutidos anteriormente influyen en la confianza y la fluidez con la que los protocolos pueden utilizar las características entre cadenas. A continuación, exploramos cómo cada enfoque apoya el DeFi multicadena, con ejemplos reales:

  • DeFi Omnichain a través de LayerZero (Stargate, Radiant, Tapioca): La mensajería genérica de LayerZero y el estándar de Token Fungible Omnichain (OFT) están diseñados para romper los silos de liquidez. Por ejemplo, Stargate Finance utiliza LayerZero para implementar un fondo de liquidez unificado para el puenteo de activos nativos; en lugar de fondos fragmentados en cada cadena, los contratos de Stargate en todas las cadenas acceden a un fondo común, y los mensajes de LayerZero manejan la lógica de bloqueo/liberación a través de las cadenas. Esto llevó a un volumen mensual de más de $800 millones en los puentes de Stargate, demostrando una liquidez compartida significativa. Al confiar en la seguridad de LayerZero (con Stargate presumiblemente usando un conjunto robusto de DVN), los usuarios pueden transferir activos con alta confianza en la autenticidad del mensaje. Radiant Capital es otro ejemplo: un protocolo de préstamos entre cadenas donde los usuarios pueden depositar en una cadena y pedir prestado en otra. Aprovecha los mensajes de LayerZero para coordinar el estado de la cuenta a través de las cadenas, creando efectivamente un mercado de préstamos único a través de múltiples redes. De manera similar, Tapioca (un mercado monetario omnichain) utiliza LayerZero v2 e incluso ejecuta su propia DVN como verificador requerido para asegurar sus mensajes. Estos ejemplos muestran que con seguridad flexible, LayerZero puede soportar operaciones complejas entre cadenas como verificaciones de crédito, movimientos de colateral y liquidaciones a través de cadenas. La componibilidad proviene del estándar "OApp" de LayerZero (Aplicación Omnichain), que permite a los desarrolladores desplegar el mismo contrato en muchas cadenas y hacer que se coordinen a través de la mensajería. Un usuario interactúa con la instancia de cualquier cadena y experimenta la aplicación como un sistema unificado. El modelo de seguridad permite un ajuste fino: por ejemplo, las transferencias grandes o las liquidaciones podrían requerir más firmas de DVN (por seguridad), mientras que las acciones pequeñas pasan por rutas más rápidas/baratas. Esta flexibilidad asegura que ni la seguridad ni la experiencia de usuario tengan que ser de talla única. En la práctica, el modelo de LayerZero ha mejorado enormemente la liquidez compartida, evidenciado por docenas de proyectos que adoptan OFT para sus tokens (para que un token pueda existir "omnichain" en lugar de como activos envueltos separados). Por ejemplo, las stablecoins y los tokens de gobernanza pueden usar OFT para mantener un único suministro total en todas las cadenas, evitando la fragmentación de la liquidez y los problemas de arbitraje que plagaron a los tokens envueltos anteriores. En general, al proporcionar una capa de mensajería fiable y permitir que las aplicaciones controlen el modelo de confianza, LayerZero ha catalizado nuevos diseños de DeFi multicadena que tratan a múltiples cadenas como un solo ecosistema. La contrapartida es que los usuarios y los proyectos deben entender la suposición de confianza de cada aplicación omnichain (ya que pueden diferir). Pero estándares como OFT y las DVNs predeterminadas ampliamente utilizadas ayudan a que esto sea más uniforme.

  • Cuentas y Servicios Intercadena en IBC (DeFi de Cosmos): En el mundo de Cosmos, IBC ha permitido un rico tapiz de funcionalidades entre cadenas que van más allá de las transferencias de tokens. Una característica insignia son las Cuentas Intercadena (ICA), que permiten que una blockchain (o un usuario en la cadena A) controle una cuenta en la cadena B como si fuera local. Esto se hace a través de paquetes IBC que transportan transacciones. Por ejemplo, el Cosmos Hub puede usar una cuenta intercadena en Osmosis para hacer staking o intercambiar tokens en nombre de un usuario, todo iniciado desde el Hub. Un caso de uso concreto de DeFi es el protocolo de staking líquido de Stride: Stride (una cadena) recibe tokens como ATOM de los usuarios y, usando ICA, hace staking de forma remota de esos ATOM en el Cosmos Hub y luego emite stATOM (ATOM en staking líquido) de vuelta a los usuarios. Todo el flujo es sin confianza y automatizado a través de IBC: el módulo de Stride controla una cuenta en el Hub que ejecuta transacciones de delegación y desdelegación, con acuses de recibo y tiempos de espera que garantizan la seguridad. Esto demuestra la componibilidad entre cadenas: dos cadenas soberanas realizando un flujo de trabajo conjunto (hacer staking aquí, acuñar un token allá) sin problemas. Otro ejemplo es Osmosis (una cadena DEX) que utiliza IBC para atraer activos de más de 95 cadenas conectadas. Los usuarios de cualquier zona pueden intercambiar en Osmosis enviando sus tokens a través de IBC. Gracias a la alta seguridad de IBC, Osmosis y otros tratan con confianza los tokens IBC como genuinos (sin necesidad de custodios de confianza). Esto ha llevado a Osmosis a convertirse en uno de los mayores DEX intercadena, con un volumen diario de transferencias IBC que, según se informa, supera al de muchos sistemas con puentes. Además, con las Consultas Intercadena (ICQ) en IBC 3.0, un contrato inteligente en una cadena puede obtener datos (como precios, tasas de interés o posiciones) de otra cadena de una manera con confianza minimizada. Esto podría permitir, por ejemplo, un agregador de rendimiento intercadena que consulta las tasas de rendimiento en múltiples zonas y reasigna los activos en consecuencia, todo a través de mensajes IBC. El impacto clave del modelo de cliente ligero de IBC en la componibilidad es la confianza y la neutralidad: las cadenas permanecen soberanas pero pueden interactuar sin temor a un riesgo de puente de terceros. Proyectos como Composable Finance y Polymer incluso están extendiendo IBC a ecosistemas no-Cosmos (Polkadot, Ethereum) para aprovechar estas capacidades. El resultado podría ser un futuro donde cualquier cadena que adopte un estándar de cliente IBC pueda conectarse a un "internet universal de blockchains". La liquidez compartida en Cosmos ya es significativa; por ejemplo, el DEX nativo del Cosmos Hub (Gravity DEX) y otros dependen de IBC para agrupar la liquidez de varias zonas. Sin embargo, una limitación hasta ahora es que el DeFi de Cosmos es mayormente asíncrono: inicias en una cadena, el resultado ocurre en otra con un ligero retraso (segundos). Esto está bien para cosas como intercambios y staking, pero una componibilidad síncrona más compleja (como préstamos flash entre cadenas) permanece fuera de alcance debido a la latencia fundamental. Aún así, el espectro de DeFi entre cadenas habilitado por IBC es amplio: agricultura de rendimiento multicadena (mover fondos donde el rendimiento es más alto), gobernanza entre cadenas (una cadena votando para ejecutar acciones en otra a través de paquetes de gobernanza), e incluso la Seguridad Intercadena donde una cadena consumidora aprovecha el conjunto de validadores de una cadena proveedora (a través de paquetes de validación IBC). En resumen, los canales seguros de IBC han fomentado una economía intercadena en Cosmos, una donde los proyectos pueden especializarse en cadenas separadas pero trabajar juntos de manera fluida a través de mensajes con confianza minimizada. La liquidez compartida es evidente en cosas como el flujo de activos hacia Osmosis y el auge de las stablecoins nativas de Cosmos que se mueven libremente entre zonas.

  • Enfoques Híbridos y Otros Multicadena (Hyperlane y más allá): La visión de Hyperlane de conectividad sin permisos ha llevado a conceptos como las Rutas Warp para el puenteo de activos y dapps intercadena que abarcan varios ecosistemas. Por ejemplo, una Ruta Warp podría permitir que un token ERC-20 en Ethereum sea teletransportado a un programa de Solana, utilizando la capa de mensajería de Hyperlane por debajo. Una implementación concreta orientada al usuario es el puente Nexus de Hyperlane, que proporciona una interfaz de usuario para transferir activos entre muchas cadenas a través de la infraestructura de Hyperlane. Al usar un modelo de seguridad modular, Hyperlane puede adaptar la seguridad por ruta: una transferencia pequeña podría pasar por una ruta rápida y simple (solo los validadores de Hyperlane firmando), mientras que una transferencia grande podría requerir un ISM agregado (Hyperlane + Wormhole + Axelar, todos atestiguando). Esto asegura que el movimiento de liquidez de alto valor esté asegurado por múltiples puentes, aumentando la confianza para, digamos, mover $10M de un activo entre cadenas (se necesitaría comprometer múltiples redes para robarlo) a costa de una mayor complejidad/tarifas. En términos de componibilidad, Hyperlane permite lo que llaman "interoperabilidad de contratos": un contrato inteligente en la cadena A puede llamar a una función en la cadena B como si fuera local, una vez que se entregan los mensajes. Los desarrolladores integran el SDK de Hyperlane para despachar estas llamadas entre cadenas fácilmente. Un ejemplo podría ser un agregador de DEX entre cadenas que vive en parte en Ethereum y en parte en BNB Chain, usando mensajes de Hyperlane para arbitrar entre los dos. Debido a que Hyperlane admite cadenas EVM y no-EVM (incluso trabajos tempranos en la integración de CosmWasm y MoveVM), aspira a conectar "cualquier cadena, cualquier VM". Este amplio alcance puede aumentar la liquidez compartida al conectar ecosistemas que de otro modo no se conectarían fácilmente. Sin embargo, la adopción real de Hyperlane en el DeFi a gran escala todavía está creciendo. Aún no tiene el volumen de Wormhole o LayerZero en el puenteo, pero su naturaleza sin permisos ha atraído la experimentación. Por ejemplo, algunos proyectos han utilizado Hyperlane para conectar rápidamente rollups específicos de aplicaciones a Ethereum, porque podían configurar su propio conjunto de validadores y no esperar soluciones complejas de cliente ligero. A medida que el restaking (EigenLayer) crece, Hyperlane podría ver más adopción al ofrecer seguridad de grado Ethereum a cualquier rollup con una latencia relativamente baja. Esto podría acelerar nuevas composiciones multicadena; por ejemplo, un rollup de Optimism y un zk-rollup de Polygon intercambiando mensajes a través de Hyperlane AVS, cada mensaje respaldado por ETH penalizable si es fraudulento. El impacto en la componibilidad es que incluso los ecosistemas sin un estándar compartido (como Ethereum y un L2 arbitrario) pueden obtener un contrato de puente en el que ambas partes confían (porque está asegurado económicamente). Con el tiempo, esto puede producir una red de aplicaciones DeFi interconectadas donde la componibilidad es "ajustada" por el desarrollador (eligiendo qué módulos de seguridad usar para qué llamadas).

En todos estos casos, la interacción entre el modelo de seguridad y la componibilidad es evidente. Los proyectos solo confiarán grandes fondos de liquidez a sistemas entre cadenas si la seguridad es sólida como una roca, de ahí el impulso hacia diseños con confianza minimizada o asegurados económicamente. Al mismo tiempo, la facilidad de integración (experiencia del desarrollador) y la flexibilidad influyen en cuán creativos pueden ser los equipos al aprovechar múltiples cadenas. LayerZero e Hyperlane se centran en la simplicidad para los desarrolladores (solo importar un SDK y usar llamadas familiares de envío/recepción), mientras que IBC, al ser de más bajo nivel, requiere una mayor comprensión de los módulos y podría ser manejado por los desarrolladores de la cadena en lugar de los desarrolladores de aplicaciones. No obstante, los tres están impulsando un futuro donde los usuarios interactúan con dApps multicadena sin necesidad de saber en qué cadena están: la aplicación aprovecha sin problemas la liquidez y la funcionalidad de cualquier lugar. Por ejemplo, un usuario de una aplicación de préstamos podría depositar en la Cadena A y ni siquiera darse cuenta de que el préstamo se realizó desde un fondo en la Cadena B, todo cubierto por mensajes entre cadenas y una validación adecuada.

Implementaciones, Modelos de Amenaza y Adopción en la Práctica

Es importante evaluar cómo les está yendo a estos protocolos en condiciones del mundo real: sus implementaciones actuales, vectores de amenaza conocidos y niveles de adopción:

  • LayerZero v2 en Producción: LayerZero v1 (con el modelo de 2 entidades Oráculo+Retransmisor) obtuvo una adopción significativa, asegurando más de $50 mil millones en volumen de transferencia y más de 134 millones de mensajes entre cadenas a mediados de 2024. Está integrado con más de 60 blockchains, principalmente cadenas EVM pero también no-EVM como Aptos, y el soporte experimental para Solana está en el horizonte. LayerZero v2 se lanzó a principios de 2024, introduciendo las DVNs y la seguridad modular. Ya, plataformas importantes como Radiant Capital, SushiXSwap, Stargate, PancakeSwap y otras han comenzado a migrar o construir sobre v2 para aprovechar su flexibilidad. Una integración notable es la Red Flare (una Capa 1 centrada en datos), que adoptó LayerZero v2 para conectarse con 75 cadenas a la vez. Flare se sintió atraída por la capacidad de personalizar la seguridad: por ejemplo, usando una única DVN rápida para mensajes de bajo valor y requiriendo múltiples DVNs para los de alto valor. Esto muestra que en producción, las aplicaciones realmente están utilizando el enfoque de seguridad de "mezclar y combinar" como un punto de venta. Seguridad y auditorías: Los contratos de LayerZero son inmutables y han sido auditados (v1 tuvo múltiples auditorías, v2 también). La principal amenaza en v1 era la colusión Oráculo-Retransmisor: si las dos partes fuera de la cadena conspiraban, podían falsificar un mensaje. En v2, esa amenaza se generaliza a la colusión de DVNs. Si todas las DVNs en las que una aplicación confía son comprometidas por una sola entidad, un mensaje falso podría pasar. La respuesta de LayerZero es fomentar las DVNs específicas de la aplicación (para que un atacante también tenga que comprometer al equipo de la aplicación) y la diversidad de verificadores (haciendo la colusión más difícil). Otro problema potencial es la mala configuración o el mal uso de la actualización: si el propietario de una aplicación cambia maliciosamente a una Pila de Seguridad trivial (como una DVN 1 de 1 controlada por ellos mismos), podrían eludir la seguridad para explotar a sus propios usuarios. Esto es más un riesgo de gobernanza que un error de protocolo, y las comunidades deben estar vigilantes sobre cómo se establece la seguridad de una aplicación omnichain (preferiblemente requiriendo una multifirma o aprobación de la comunidad para los cambios). En términos de adopción, LayerZero tiene posiblemente el mayor uso entre los protocolos de mensajería en DeFi actualmente: impulsa el puenteo para Stargate, la integración CCTP de Circle (para transferencias de USDC), el intercambio entre cadenas de Sushi, muchos puentes de NFT e innumerables tokens OFT (proyectos que eligen LayerZero para hacer que su token esté disponible en múltiples cadenas). Los efectos de red son fuertes: a medida que más cadenas integran los endpoints de LayerZero, se vuelve más fácil para las nuevas cadenas unirse a la red "omnichain". LayerZero Labs mismo ejecuta una DVN y la comunidad (incluidos proveedores como Google Cloud, Polyhedra para pruebas zk, etc.) ha lanzado más de 15 DVNs para 2024. No ha ocurrido ningún exploit importante del protocolo central de LayerZero hasta la fecha, lo cual es una señal positiva (aunque han ocurrido algunos hackeos a nivel de aplicación o errores de usuario, como con cualquier tecnología). El diseño del protocolo de mantener la capa de transporte simple (esencialmente solo almacenando mensajes y requiriendo pruebas) minimiza las vulnerabilidades en la cadena, trasladando la mayor parte de la complejidad fuera de la cadena a las DVNs.

  • Hyperlane en Producción: Hyperlane (anteriormente Abacus) está activo en numerosas cadenas, incluyendo Ethereum, múltiples L2s (Optimism, Arbitrum, zkSync, etc.), cadenas de Cosmos como Osmosis a través de un módulo Cosmos-SDK, e incluso cadenas MoveVM (es bastante amplio en soporte). Sin embargo, su adopción está por detrás de incumbentes como LayerZero y Wormhole en términos de volumen. Hyperlane a menudo se menciona en el contexto de ser una solución de "puente soberano", es decir, un proyecto puede desplegar Hyperlane para tener su propio puente con seguridad personalizada. Por ejemplo, algunos equipos de appchains han utilizado Hyperlane para conectar su cadena a Ethereum sin depender de un puente compartido. Un desarrollo notable es el Servicio de Validación Activa (AVS) de Hyperlane lanzado a mediados de 2024, que es una de las primeras aplicaciones del restaking de Ethereum. Tiene validadores (muchos de los cuales son operadores de EigenLayer de primer nivel) que hacen restaking de ETH para asegurar los mensajes de Hyperlane, centrándose inicialmente en la mensajería rápida entre rollups. Actualmente está asegurando la interoperabilidad entre los rollups L2 de Ethereum con buenos resultados, esencialmente proporcionando un paso de mensajes casi instantáneo (más rápido que esperar las salidas de 7 días de los rollups optimistas) con seguridad económica vinculada a Ethereum. En términos de modelo de amenaza, el enfoque multifirma original de Hyperlane podría ser atacado si se comprometen suficientes claves de validadores (como con cualquier puente multifirma). Hyperlane ha tenido un incidente de seguridad pasado: en agosto de 2022, durante una testnet o lanzamiento temprano, hubo un exploit donde un atacante pudo secuestrar la clave de despliegue de un puente de tokens de Hyperlane en una cadena y acuñar tokens (una pérdida de alrededor de $700k). Esto no fue un fallo de la multifirma en sí, sino de la seguridad operativa en torno al despliegue; destacó los riesgos de la capacidad de actualización y la gestión de claves. El equipo reembolsó las pérdidas y mejoró los procesos. Esto subraya que las claves de gobernanza son parte del modelo de amenaza: asegurar los controles de administrador es tan importante como los validadores. Con AVS, el modelo de amenaza se traslada a un contexto de EigenLayer: si alguien pudiera causar un falso slashing o evitar ser penalizado a pesar de un mal comportamiento, eso sería un problema; pero el protocolo de EigenLayer maneja la lógica de slashing en Ethereum, que es robusta asumiendo una correcta presentación de pruebas de fraude. La adopción actual de Hyperlane está creciendo en el espacio de los rollups y entre algunas cadenas específicas de aplicaciones. Puede que aún no maneje los flujos multimillonarios de algunos competidores, pero está creando un nicho donde los desarrolladores quieren control total y fácil extensibilidad. El diseño modular de ISM significa que podríamos ver configuraciones de seguridad creativas: por ejemplo, una DAO podría requerir no solo firmas de Hyperlane sino también un bloqueo de tiempo o una segunda firma de puente para cualquier mensaje de administrador, etc. El ethos sin permisos de Hyperlane (cualquiera puede ejecutar un validador o desplegar en una nueva cadena) podría resultar poderoso a largo plazo, pero también significa que el ecosistema necesita madurar (por ejemplo, más validadores de terceros uniéndose para descentralizar el conjunto predeterminado; a partir de 2025 no está claro cuán descentralizado es el conjunto de validadores activos en la práctica). En general, la trayectoria de Hyperlane es una de mejora de la seguridad (con restaking) y facilidad de uso, pero necesitará demostrar resiliencia y atraer una liquidez importante para ganar el mismo nivel de confianza de la comunidad que IBC o incluso LayerZero.

  • IBC 3.0 e Interoperabilidad de Cosmos en Producción: IBC ha estado activo desde 2021 y está extremadamente probado en batalla dentro de Cosmos. Para 2025, conecta más de 115 zonas (incluyendo Cosmos Hub, Osmosis, Juno, Cronos, Axelar, Kujira, etc.) con millones de transacciones por mes y flujos de tokens de miles de millones de dólares. Impresionantemente, ha tenido ningún fallo de seguridad importante a nivel de protocolo. Ha habido un incidente notable relacionado con IBC: en octubre de 2022, se descubrió una vulnerabilidad crítica en el código de IBC (que afectaba a todas las implementaciones v2.0) que podría haber permitido a un atacante drenar valor de muchas cadenas conectadas a IBC. Sin embargo, se solucionó de forma encubierta a través de actualizaciones coordinadas antes de que se divulgara públicamente, y no ocurrió ningún exploit. Esto fue una llamada de atención de que incluso los protocolos formalmente verificados pueden tener errores. Desde entonces, IBC ha visto más auditorías y endurecimiento. El modelo de amenaza para IBC se refiere principalmente a la seguridad de la cadena: si una cadena conectada es hostil o sufre un ataque del 51%, podría intentar alimentar datos inválidos al cliente ligero de una contraparte. Las mitigaciones incluyen el uso de la gobernanza para detener o cerrar conexiones a cadenas que son inseguras (la gobernanza del Cosmos Hub, por ejemplo, puede votar para desactivar las actualizaciones de cliente para una cadena en particular si se detecta que está rota). Además, los clientes IBC a menudo tienen alineación del período de desvinculación o del período de confianza; por ejemplo, un cliente ligero de Tendermint no aceptará una actualización del conjunto de validadores más antigua que el período de desvinculación (para prevenir ataques de largo alcance). Otro posible problema es la censura de retransmisores: si ningún retransmisor entrega paquetes, los fondos podrían quedar atascados en tiempos de espera; pero como la retransmisión es sin permisos y a menudo incentivada, esto suele ser transitorio. Con las Consultas Intercadena y las nuevas características de IBC 3.0 implementándose, vemos adopción en cosas como agregadores de DeX entre cadenas (por ejemplo, Skip Protocol usando ICQ para recopilar datos de precios a través de cadenas) y gobernanza entre cadenas (por ejemplo, Cosmos Hub usando cuentas intercadena para gestionar Neutron, una cadena consumidora). La adopción más allá de Cosmos también es una historia: proyectos como Polymer y Astria (un hub de interoperabilidad para rollups) están llevando efectivamente IBC a los rollups de Ethereum a través de un modelo hub/spoke, y las parachains de Polkadot han utilizado con éxito IBC para conectarse con cadenas de Cosmos (por ejemplo, el puente Centauri entre Cosmos y Polkadot, construido por Composable Finance, utiliza IBC por debajo con un cliente ligero GRANDPA en el lado de Cosmos). Incluso hay una implementación de IBC-Solidity en progreso por Polymer y DataChain que permitiría a los contratos inteligentes de Ethereum verificar paquetes IBC (usando un cliente ligero o pruebas de validez). Si estos esfuerzos tienen éxito, podría ampliar drásticamente el uso de IBC más allá de Cosmos, llevando su modelo de confianza minimizada a la competencia directa con los puentes más centralizados en esas cadenas. En términos de liquidez compartida, la mayor limitación de Cosmos fue la ausencia de una stablecoin nativa o una liquidez DEX profunda a la par de la de Ethereum; eso está cambiando con el auge de las stablecoins nativas de Cosmos (como IST, CMST) y la conexión de activos como USDC (Axelar y Gravity bridge trajeron USDC, y ahora Circle está lanzando USDC nativo en Cosmos a través de Noble). A medida que la liquidez se profundiza, la combinación de alta seguridad y transferencias IBC fluidas podría hacer de Cosmos un nexo para el comercio DeFi multicadena; de hecho, el informe de Blockchain Capital señaló que IBC ya manejaba más volumen que LayerZero o Wormhole a principios de 2024, aunque eso se debe principalmente a la fuerza del tráfico de Cosmos a Cosmos (lo que sugiere una economía intercadena muy activa). En el futuro, el principal desafío y oportunidad de IBC es expandirse a cadenas heterogéneas sin sacrificar su ethos de seguridad.

En resumen, cada protocolo está avanzando: LayerZero se está integrando rápidamente con muchas cadenas y aplicaciones, priorizando la flexibilidad y la adopción por parte de los desarrolladores, y mitigando los riesgos al permitir que las aplicaciones sean parte de su propia seguridad. Hyperlane está innovando con el restaking y la modularidad, con el objetivo de ser la forma más fácil de conectar nuevas cadenas con seguridad configurable, aunque todavía está construyendo confianza y uso. IBC es el estándar de oro en la falta de confianza dentro de su dominio, ahora evolucionando para ser más rápido (IBC 3.0) y esperando extender su dominio más allá de Cosmos, respaldado por un sólido historial. Los usuarios y proyectos son sabios al considerar la madurez y los incidentes de seguridad de cada uno: IBC tiene años de operación estable (y un volumen enorme) pero limitado a ciertos ecosistemas; LayerZero ha acumulado rápidamente uso pero requiere comprender configuraciones de seguridad personalizadas; Hyperlane es más nuevo en ejecución pero prometedor en visión, con pasos cuidadosos hacia la seguridad económica.

Conclusión y Perspectivas: Arquitectura de Interoperabilidad para el Futuro Multicadena

La viabilidad a largo plazo y la interoperabilidad del panorama DeFi multicadena probablemente serán moldeadas por los tres modelos de seguridad coexistiendo e incluso complementándose entre sí. Cada enfoque tiene fortalezas claras, y en lugar de una solución única para todos, podemos ver una pila donde el modelo de cliente ligero (IBC) proporciona la base de mayor seguridad para rutas clave (especialmente entre cadenas principales), mientras que los sistemas de agregación de pruebas (LayerZero) proporcionan conectividad universal con confianza personalizable, y los modelos multifirma (Hyperlane y otros) sirven a necesidades de nicho o inician nuevos ecosistemas rápidamente.

Compromiso entre Seguridad y Conectividad: Los clientes ligeros como IBC ofrecen lo más parecido a un "internet de blockchains": una capa de transporte neutral y estandarizada similar a TCP/IP. Aseguran que la interoperabilidad no introduzca nuevas debilidades, lo cual es crítico para la sostenibilidad a largo plazo. Sin embargo, requieren un amplio acuerdo sobre estándares y una ingeniería significativa por cadena, lo que ralentiza la velocidad a la que se pueden formar nuevas conexiones. LayerZero e Hyperlane, por otro lado, priorizan la conectividad inmediata y la flexibilidad, reconociendo que no todas las cadenas implementarán el mismo protocolo. Su objetivo es conectar "cualquiera con cualquiera", incluso si eso significa aceptar un poco más de confianza en el ínterin. Con el tiempo, podemos esperar que la brecha se reduzca: LayerZero puede incorporar más DVNs con confianza minimizada (incluso IBC mismo podría ser envuelto en una DVN), e Hyperlane puede usar mecanismos económicos para acercarse a la seguridad de la verificación nativa. De hecho, el proyecto Polymer prevé que IBC y LayerZero no necesitan ser competidores, sino que pueden superponerse: por ejemplo, LayerZero podría usar un cliente ligero de IBC como una de sus DVNs cuando esté disponible. Tal polinización cruzada es probable a medida que el espacio madure.

Componibilidad y Liquidez Unificada: Desde la perspectiva de un usuario de DeFi, el objetivo final es que la liquidez se vuelva agnóstica a la cadena. Ya estamos viendo pasos: con los tokens omnichain (OFTs) no te preocupas en qué cadena está tu versión del token, y con los mercados monetarios entre cadenas puedes pedir prestado en cualquier cadena contra colateral en otra. Las elecciones arquitectónicas afectan directamente la confianza del usuario en estos sistemas. Si ocurre un hackeo de puente (como sucedió con algunos puentes multifirma históricamente), fractura la confianza y, por lo tanto, la liquidez: los usuarios se retiran a lugares más seguros o exigen primas de riesgo. Por lo tanto, los protocolos que demuestren seguridad de manera consistente sustentarán los mayores fondos de liquidez. La seguridad intercadena de Cosmos e IBC han mostrado un camino: múltiples libros de órdenes y AMMs a través de zonas se componen esencialmente en un gran mercado porque las transferencias son sin confianza y rápidas. Stargate de LayerZero mostró otro: un fondo de liquidez unificado puede servir a las transferencias de muchas cadenas, pero requería que los usuarios confiaran en la suposición de seguridad de LayerZero (Oráculo+Retransmisor o DVNs). A medida que LayerZero v2 permite que cada fondo establezca una seguridad aún mayor (por ejemplo, usar múltiples redes de validadores de renombre para verificar cada transferencia), está reduciendo la brecha de confianza. La viabilidad a largo plazo del DeFi multicadena probablemente dependa de que los protocolos de interoperabilidad sean invisibles pero fiables, al igual que los usuarios de internet no piensan en TCP/IP, los usuarios de cripto no deberían tener que preocuparse por qué puente o sistema de mensajería utiliza una dApp. Eso sucederá cuando los modelos de seguridad sean lo suficientemente robustos como para que los fallos sean extremadamente raros y cuando haya alguna convergencia o componibilidad entre estas redes de interoperabilidad.

Interoperabilidad de la Interoperabilidad: Es concebible que en unos pocos años, no hablemos de LayerZero vs Hyperlane vs IBC como reinos separados, sino más bien como un sistema en capas. Por ejemplo, un rollup de Ethereum podría tener una conexión IBC a un hub de Cosmos a través de Polymer, y ese hub de Cosmos podría tener también un endpoint de LayerZero, permitiendo que los mensajes transiten desde el rollup a la red de LayerZero a través de un canal IBC seguro. Hyperlane podría incluso funcionar como un respaldo o agregación: una aplicación podría requerir tanto una prueba de IBC como una firma de Hyperlane AVS para una seguridad máxima. Este tipo de agregación de seguridad entre protocolos podría abordar incluso los modelos de amenaza más avanzados (es mucho más difícil subvertir simultáneamente un cliente ligero de IBC y una multifirma independiente con restaking, etc.). Tales combinaciones, por supuesto, agregarán complejidad y costo, por lo que se reservarían para contextos de alto valor.

Gobernanza y Descentralización: Cada modelo pone un poder diferente en manos de diferentes actores: IBC en manos de la gobernanza de la cadena, LayerZero en manos de los desarrolladores de aplicaciones (e indirectamente, los operadores de DVN que eligen), e Hyperlane en manos de los validadores del puente y posiblemente los restakers. El panorama interoperable a largo plazo necesitará asegurar que ninguna parte o cártel pueda dominar las transacciones entre cadenas. Este es un riesgo, por ejemplo, si un protocolo se vuelve ubicuo pero es controlado por un pequeño conjunto de actores; podría convertirse en un punto de estrangulamiento (análogo a los proveedores de servicios de internet centralizados). La forma de mitigar eso es descentralizando las propias redes de mensajería (más retransmisores, más DVNs, más validadores, todos con permiso para unirse) y teniendo rutas alternativas. En este frente, IBC tiene la ventaja de ser un estándar abierto con muchos equipos independientes, y tanto LayerZero como Hyperlane se están moviendo para aumentar la participación de terceros (por ejemplo, cualquiera puede ejecutar una DVN de LayerZero o un validador de Hyperlane). Es probable que la competencia y la participación abierta mantengan estos servicios honestos, al igual que los mineros/validadores en las L1s mantienen la capa base descentralizada. El mercado también votará con sus pies: si una solución demuestra ser insegura o demasiado centralizada, los desarrolladores pueden migrar a otra (especialmente a medida que los estándares de puenteo se vuelven más interoperables entre sí).

En conclusión, las arquitecturas de seguridad de LayerZero v2, Hyperlane e IBC 3.0 contribuyen cada una a hacer realidad la visión de un DeFi multicadena, pero con diferentes filosofías. Los clientes ligeros priorizan la falta de confianza y la neutralidad, las multifirmas priorizan el pragmatismo y la facilidad de integración, y los enfoques agregados priorizan la personalización y la adaptabilidad. El panorama DeFi multicadena del futuro probablemente utilizará una combinación de estos: infraestructura crítica y transferencias de alto valor aseguradas por métodos con confianza minimizada o asegurados económicamente, y middleware flexible para conectarse a la larga cola de nuevas cadenas y aplicaciones. Con esto en su lugar, los usuarios disfrutarán de una liquidez unificada y una componibilidad entre cadenas con la misma confianza y facilidad que al usar una sola cadena. El camino a seguir es uno de convergencia, no necesariamente de los protocolos en sí, sino de los resultados: un mundo donde la interoperabilidad es segura, fluida y estándar. Lograr eso requerirá una ingeniería rigurosa continua (para evitar exploits), una gobernanza colaborativa (para establecer estándares como IBC o interfaces de contrato universales), y quizás lo más importante, un enfoque iterativo de la seguridad que combine lo mejor de todos los mundos: matemáticas, incentivos económicos y diseño inteligente. El estado final podría cumplir verdaderamente la analogía a menudo citada: blockchains interconectadas como redes en internet, con protocolos como LayerZero, Hyperlane e IBC formando la autopista omnichain sobre la que DeFi viajará en el futuro previsible.

Fuentes:

  • Arquitectura de LayerZero v2 y seguridad de DVN – LayerZero V2 Deep Dive; Anuncio de Flare x LayerZero V2
  • Multifirma de Hyperlane e ISM modular – Documentación de Hyperlane: Validadores; Investigación de Tiger sobre Hyperlane; Anuncio de restaking (AVS) de Hyperlane
  • Clientes ligeros y características de IBC 3.0 – Visión general del protocolo IBC; 3Commas Cosmos 2025 (IBC 3.0)
  • Comparación de suposiciones de confianza – Nosleepjohn (Hyperlane) sobre los compromisos de los puentes; IBC vs puentes (blog de Polymer)
  • Ejemplos de DeFi (Stargate, ICA, etc.) – Blog de Flare sobre LayerZero (volumen de Stargate); Casos de uso de IBC (staking líquido de Stride); Medium de LayerZero (estándares OFT y OApp); Casos de uso de Hyperlane
  • Adopción y estadísticas – Flare x LayerZero (mensajes entre cadenas, volumen); Range.org sobre el volumen de IBC; Blockchain Capital sobre IBC vs puentes; Blog de LayerZero (más de 15 DVNs); Testimonios de IBC (Osmosis, etc.).

El crimen de copiar y pegar: cómo un hábito simple está drenando millones de carteras cripto

· 5 min de lectura
Dora Noda
Software Engineer

Cuando envías cripto, ¿cuál es tu rutina? Para la mayoría, implica copiar la dirección del destinatario de nuestro historial de transacciones. Después de todo, nadie puede memorizar una cadena de 40 caracteres como 0x1A2b...8f9E. Es un atajo conveniente que todos usamos.

¿Pero qué pasa si esa comodidad es una trampa cuidadosamente tendida?

Una estafa devastadoramente eficaz llamada Blockchain Address Poisoning está explotando este hábito exacto. Investigaciones recientes de la Universidad Carnegie Mellon han revelado la escala impactante de esta amenaza. En solo dos años, en las redes Ethereum y Binance Smart Chain (BSC) únicamente, los estafadores han realizado más de 270 millones de intentos de ataque, apuntando a 17 millones de víctimas y robando con éxito al menos $83.8 millones.

Esto no es una amenaza de nicho; es una de las estafas de phishing cripto más grandes y exitosas que operan hoy. Aquí tienes cómo funciona y qué puedes hacer para protegerte.

Cómo funciona el engaño 🤔

El envenenamiento de direcciones es un juego de engaño visual. La estrategia del atacante es simple pero brillante:

  1. Generar una dirección similar: El atacante identifica una dirección frecuente a la que envías fondos. Luego utiliza ordenadores potentes para generar una nueva dirección cripto que tenga los exactos mismos caracteres iniciales y finales. Dado que la mayoría de carteras y exploradores de bloques acortan las direcciones para mostrarlas (p. ej., 0x1A2b...8f9E), su dirección fraudulenta se ve idéntica a la real de un vistazo.

  2. "Envenenar" tu historial de transacciones: Luego, el atacante necesita introducir su dirección similar en el historial de tu cartera. Lo hace enviando una transacción de "veneno". Esto puede ser:

    • Una transferencia diminuta: Te envía una cantidad minúscula de cripto (como $0.001) desde su dirección similar. Ahora aparece en tu lista de transacciones recientes.
    • Una transferencia de valor cero: En un movimiento más astuto, explotan una función en muchos contratos de tokens para crear una transferencia falsa de cero dólares que parece haber venido de ti a su dirección similar. Esto hace que la dirección falsa parezca aún más legítima, ya que parece que ya has enviado fondos allí antes.
    • Una transferencia de token falsificado: Crean un token sin valor, falso (p. ej., "USDTT" en lugar de USDT) y falsifican una transacción a su dirección similar, a menudo imitando la cantidad de una transacción real previa que realizaste.
  3. Esperar al error: La trampa ya está puesta. La próxima vez que vayas a pagar a un contacto legítimo, revisas tu historial de transacciones, ves lo que crees que es la dirección correcta, la copias y envías. Cuando te das cuenta del error, los fondos ya se han ido. Y gracias a la naturaleza irreversible de la blockchain, no hay banco al que llamar ni forma de recuperarlos.

Una mirada a una empresa criminal 🕵️‍♂️

Esto no es obra de hackers solitarios. La investigación revela que estos ataques son llevados a cabo por grandes grupos criminales, organizados y altamente rentables.

A quiénes apuntan

Los atacantes no pierden tiempo en cuentas pequeñas. Apuntan sistemáticamente a usuarios que son:

  • Ricos: Con saldos significativos en stablecoins.
  • Activos: Realizando transacciones frecuentes.
  • Transactores de alto valor: Moviendo grandes sumas de dinero.

Una carrera armamentista de hardware

Generar una dirección similar es una tarea computacional de fuerza bruta. Cuantos más caracteres quieras coincidir, más exponencialmente difícil se vuelve. Los investigadores descubrieron que, aunque la mayoría de los atacantes usan CPUs estándar para crear falsificaciones moderadamente convincentes, el grupo criminal más sofisticado lo ha llevado a otro nivel.

Este grupo de primer nivel ha logrado generar direcciones que coinciden con hasta 20 caracteres de la dirección de un objetivo. Esta hazaña es casi imposible con ordenadores estándar, lo que lleva a los investigadores a concluir que están usando enormes granjas de GPU — el mismo tipo de hardware potente usado para juegos de alta gama o investigación de IA. Esto muestra una inversión financiera significativa, que recuperan fácilmente de sus víctimas. Estos grupos organizados están manejando un negocio, y el negocio está, desafortunadamente, en auge.

Cómo proteger tus fondos 🛡️

Aunque la amenaza es sofisticada, las defensas son sencillas. Todo se reduce a romper malos hábitos y adoptar una mentalidad más vigilante.

  1. Para cada usuario (Esta es la parte más importante):

    • VERIFICA LA DIRECCIÓN COMPLETA. Antes de hacer clic en "Confirmar", tómate cinco segundos extra para revisar manualmente la dirección completa, carácter por carácter. No te limites a mirar los primeros y últimos dígitos.
    • UTILIZA UNA LIBRERÍA DE DIRECCIONES. Guarda direcciones confiables y verificadas en la libreta de direcciones o lista de contactos de tu cartera. Al enviar fondos, siempre selecciona al destinatario de esta lista guardada, no de tu historial de transacciones dinámico.
    • ENVÍA UNA TRANSACCIÓN DE PRUEBA. Para pagos grandes o importantes, envía primero una cantidad mínima. Confirma con el destinatario que la ha recibido antes de enviar la suma completa.
  2. Un llamado a mejores carteras: Los desarrolladores de carteras pueden ayudar mejorando las interfaces de usuario. Esto incluye mostrar más de la dirección por defecto o añadir advertencias fuertes y explícitas cuando un usuario está a punto de enviar fondos a una dirección con la que solo ha interactuado mediante una transferencia diminuta o de valor cero.

  3. La solución a largo plazo: Sistemas como el Ethereum Name Service (ENS), que permiten mapear un nombre legible por humanos como yourname.eth a tu dirección, pueden eliminar este problema por completo. Una adopción más amplia es clave.

En el mundo descentralizado, eres tu propio banco, lo que también significa que eres tu propio jefe de seguridad. El envenenamiento de direcciones es una amenaza silenciosa pero poderosa que se aprovecha de la comodidad y la falta de atención. Si actúas con deliberación y verificas dos veces tu trabajo, puedes asegurarte de que tus activos ganados con esfuerzo no terminen en la trampa de un estafador.

El mito de la anonimidad de Ethereum: cómo los investigadores desenmascararon al 15 % de los validadores

· 6 min de lectura
Dora Noda
Software Engineer

Una de las promesas centrales de la tecnología blockchain como Ethereum es un grado de anonimato. Los participantes, conocidos como validadores, se supone que operan detrás de un velo de seudónimos criptográficos, protegiendo su identidad en el mundo real y, por extensión, su seguridad.

Sin embargo, un artículo de investigación reciente titulado “Desanonimizando a los validadores de Ethereum: la red P2P tiene un problema de privacidad”, elaborado por investigadores de ETH Zurich y otras instituciones, revela una falla crítica en esta suposición. Demuestran un método simple y de bajo costo para vincular el identificador público de un validador directamente con la dirección IP de la máquina en la que se ejecuta.

En resumen, los validadores de Ethereum no son tan anónimos como muchos creen. Los hallazgos fueron lo suficientemente significativos como para que los investigadores recibieran una recompensa por errores de la Ethereum Foundation, reconociendo la gravedad de la fuga de privacidad.

Cómo funciona la vulnerabilidad: una falla en el gossip

Para entender la vulnerabilidad, primero necesitamos una visión básica de cómo se comunican los validadores de Ethereum. La red está compuesta por más de un millón de validadores que constantemente “votan” sobre el estado de la cadena. Estas votaciones se denominan attestations y se difunden a través de una red peer‑to‑peer (P2PP2P) a todos los demás nodos.

Con tantos validadores, hacer que todos difundan cada voto a todos los demás saturaría la red al instante. Para resolver esto, los diseñadores de Ethereum implementaron una solución de escalado ingeniosa: la red se divide en 64 canales de comunicación distintos, conocidos como subnets.

  • Por defecto, cada nodo (la computadora que ejecuta el software del validador) se suscribe a solo dos de esos 64 subnets. Su tarea principal es retransmitir diligentemente todos los mensajes que vea en esos dos canales.
  • Cuando un validador necesita emitir un voto, su attestation se asigna aleatoriamente a uno de los 64 subnets para su difusión.

Aquí es donde reside la vulnerabilidad. Imagina un nodo cuya tarea es gestionar el tráfico de los canales 12 y 13. Todo el día, reenvía fielmente los mensajes de esos dos canales. Pero de repente, te envía un mensaje que pertenece al canal 45.

Esto es una pista poderosa. ¿Por qué un nodo manejaría un mensaje de un canal del que no es responsable? La conclusión más lógica es que el propio nodo generó ese mensaje. Esto implica que el validador que creó la attestation para el canal 45 está ejecutándose en esa misma máquina.

Los investigadores explotaron este principio exacto. Configurando sus propios nodos de escucha, monitorizaron los subnets desde los que sus pares enviaban attestations. Cuando un par enviaba un mensaje desde un subnet al que no estaba oficialmente suscrito, podían inferir con alta confianza que ese par alojaba al validador origen.

El método resultó sorprendentemente efectivo. Usando solo cuatro nodos durante tres días, el equipo localizó con éxito las direcciones IP de más de 161 000 validadores, lo que representa más del 15 % de toda la red de Ethereum.

Por qué importa: los riesgos de la desanonimización

Exponer la dirección IP de un validador no es un asunto trivial. Abre la puerta a ataques dirigidos que amenazan tanto a operadores individuales como a la salud de la red Ethereum en su conjunto.

1. Ataques dirigidos y robo de recompensas Ethereum anuncia qué validador está programado para proponer el próximo bloque con unos minutos de antelación. Un atacante que conozca la dirección IP de ese validador puede lanzar un Denial‑of‑Service (DDoS), inundándolo con tráfico y dejándolo fuera de línea. Si el validador pierde su ventana de cuatro segundos para proponer el bloque, la oportunidad pasa al siguiente validador en la fila. Si el atacante es ese siguiente validador, puede reclamar las recompensas del bloque y las tarifas de transacción (MEV) que deberían haber ido a la víctima.

2. Amenazas a la vivacidad y seguridad de la red Un atacante con recursos suficientes podría realizar estos ataques de “sniping” de forma repetida, ralentizando o incluso deteniendo toda la blockchain (un ataque de vivacidad). En un escenario más grave, el atacante podría usar esta información para lanzar ataques sofisticados de partición de red, provocando que diferentes partes de la red discrepen sobre la historia de la cadena y comprometiendo su integridad (un ataque de seguridad).

3. Revelación de una realidad centralizada La investigación también sacó a la luz algunas verdades incómodas sobre la descentralización de la red:

  • Concentración extrema: El equipo encontró pares que alojaban una cantidad asombrosa de validadores, incluido un IP que ejecutaba más de 19 000. La falla de una sola máquina podría tener un impacto desproporcionado en la red.
  • Dependencia de servicios en la nube: Aproximadamente 90 % de los validadores localizados operan en proveedores de nube como AWS y Hetzner, no en los equipos de stakers domésticos. Esto representa un punto significativo de centralización.
  • Dependencias ocultas: Muchos pools de staking grandes afirman que sus operadores son independientes. Sin embargo, la investigación halló casos en los que validadores de diferentes pools competidores estaban ejecutándose en la misma máquina física, creando riesgos sistémicos ocultos.

Mitigaciones: ¿Cómo pueden protegerse los validadores?

Afortunadamente, existen formas de defenderse contra esta técnica de desanonimización. Los investigadores propusieron varias mitigaciones:

  • Crear más ruido: Un validador puede optar por suscribirse a más de dos subnets —incluso a los 64 completos—. Esto dificulta mucho que un observador distinga entre mensajes retransmitidos y los generados por el propio nodo.
  • Usar múltiples nodos: Un operador puede separar las funciones del validador en diferentes máquinas con distintas IPs. Por ejemplo, un nodo podría manejar attestations mientras que otro nodo privado se use solo para proponer bloques de alto valor.
  • Peering privado: Los validadores pueden establecer conexiones privadas y de confianza con otros nodos para retransmitir sus mensajes, ocultando su origen real dentro de un pequeño grupo confiable.
  • Protocolos de difusión anónima: Soluciones más avanzadas como Dandelion, que ofuscan el origen de un mensaje al pasarlo por un “stem” aleatorio antes de difundirlo ampliamente, podrían implementarse.

Conclusión

Esta investigación ilustra de manera contundente la compensación inherente entre rendimiento y privacidad en los sistemas distribuidos. En su afán por escalar, la red P2PP2P de Ethereum adoptó un diseño que comprometió el anonimato de sus participantes más críticos.

Al sacar a la luz esta vulnerabilidad, los investigadores han proporcionado a la comunidad de Ethereum el conocimiento y las herramientas necesarias para abordarla. Su trabajo constituye un paso crucial hacia la construcción de una red más robusta, segura y verdaderamente descentralizada para el futuro.

Despliegue Seguro con Docker Compose + Ubuntu

· 7 min de lectura

En las startups del Silicon Valley, Docker Compose es una de las herramientas preferidas para desplegar y gestionar rápidamente aplicaciones contenerizadas. Sin embargo, la comodidad a menudo viene acompañada de riesgos de seguridad. Como Ingeniero de Fiabilidad del Sitio (SRE), soy plenamente consciente de que las vulnerabilidades de seguridad pueden provocar consecuencias catastróficas. Este artículo compartirá las mejores prácticas de seguridad que he resumido en mi trabajo real combinando Docker Compose con sistemas Ubuntu, ayudándote a disfrutar de la comodidad de Docker Compose mientras garantizas la seguridad del sistema.

Despliegue Seguro con Docker Compose + Ubuntu

I. Reforzando la Seguridad del Sistema Ubuntu

Antes de desplegar contenedores, es crucial asegurar la seguridad del host Ubuntu en sí. Aquí hay algunos pasos clave:

1. Actualizar Ubuntu y Docker regularmente

Asegúrate de que tanto el sistema como Docker estén actualizados para corregir vulnerabilidades conocidas:

sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin

2. Restringir los permisos de gestión de Docker

Controla estrictamente los permisos de gestión de Docker para prevenir ataques de escalada de privilegios:

sudo usermod -aG docker deployuser
# Prevent regular users from easily obtaining docker management permissions

3. Configurar el firewall de Ubuntu (UFW)

Restringe razonablemente el acceso a la red para prevenir accesos no autorizados:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

4. Configurar correctamente la interacción entre Docker y UFW

Por defecto, Docker elude UFW para configurar iptables, por lo que se recomienda un control manual:

Modificar el archivo de configuración de Docker:

sudo nano /etc/docker/daemon.json

Agregar el siguiente contenido:

{
"iptables": false,
"ip-forward": true,
"userland-proxy": false
}

Reiniciar el servicio Docker:

sudo systemctl restart docker

Vincula explícitamente direcciones en Docker Compose:

services:
webapp:
ports:
- "127.0.0.1:8080:8080"

II. Mejores Prácticas de Seguridad en Docker Compose

Las siguientes configuraciones se aplican a Docker Compose v2.4 y superiores. Observa las diferencias entre los modos no Swarm y Swarm.

1. Restringir los permisos de los contenedores

Los contenedores que se ejecutan como root por defecto representan altos riesgos; cámbialos a usuarios no root:

services:
app:
image: your-app:v1.2.3
user: "1000:1000" # Non-root user
read_only: true # Read-only filesystem
volumes:
- /tmp/app:/tmp # Mount specific directories if write access is needed
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE
  • Un sistema de archivos de solo lectura evita la manipulación dentro del contenedor.
  • Asegúrate de que los volúmenes montados estén limitados a los directorios necesarios.

2. Aislamiento de red y gestión de puertos

Divide de manera precisa las redes internas y externas para evitar exponer servicios sensibles al público:

networks:
frontend:
internal: false
backend:
internal: true

services:
nginx:
networks: [frontend, backend]
database:
networks:
- backend
  • Red frontal: Puede estar abierta al público.
  • Red trasera: Estrictamente restringida, solo comunicación interna.

3. Gestión segura de secretos

Los datos sensibles nunca deben colocarse directamente en los archivos Compose:

En modo de máquina única:

services:
webapp:
environment:
- DB_PASSWORD_FILE=/run/secrets/db_password
volumes:
- ./secrets/db_password.txt:/run/secrets/db_password:ro

En modo Swarm:

services:
webapp:
secrets:
- db_password
environment:
DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
db_password:
external: true # Managed through Swarm's built-in management
  • Los secretos nativos de Swarm de Docker no pueden usar directamente herramientas externas como Vault o AWS Secrets Manager.
  • Si se necesita almacenamiento externo de secretos, integra tú mismo el proceso de lectura.

4. Limitación de recursos (adaptar a la versión de Docker Compose)

Los límites de recursos de los contenedores evitan que un solo contenedor agote los recursos del host.

Docker Compose modo de máquina única (v2.4 recomendado):

version: "2.4"

services:
api:
image: your-image:1.4.0
mem_limit: 512m
cpus: 0.5

Docker Compose modo Swarm (v3 y superior):

services:
api:
deploy:
resources:
limits:
cpus: "0.5"
memory: 512M
reservations:
cpus: "0.25"
memory: 256M

Nota: En entornos no Swarm, los límites de recursos de la sección deploy no tienen efecto, asegúrate de prestar atención a la versión del archivo Compose.

5. Comprobaciones de salud de los contenedores

Configura comprobaciones de salud para detectar proactivamente problemas y reducir el tiempo de inactividad del servicio:

services:
webapp:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 20s

6. Evitar usar la etiqueta latest

Evita la incertidumbre que trae la etiqueta latest en entornos de producción, impón versiones específicas de imágenes:

services:
api:
image: your-image:1.4.0

7. Gestión adecuada de logs

Evita que los logs de los contenedores agoten el espacio en disco:

services:
web:
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "5"

8. Configuración de AppArmor en Ubuntu

Por defecto, Ubuntu habilita AppArmor, y se recomienda verificar el estado del perfil Docker:

sudo systemctl enable --now apparmor
sudo aa-status

Docker en Ubuntu habilita AppArmor por defecto sin configuración adicional. Generalmente no se recomienda habilitar SELinux en Ubuntu al mismo tiempo para evitar conflictos.

9. Actualizaciones continuas y escaneos de seguridad

  • Escaneo de vulnerabilidades de imágenes: Se recomienda integrar herramientas como Trivy, Clair o Snyk en el proceso CI/CD:
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
aquasec/trivy image your-image:v1.2.3
  • Proceso automatizado de actualización de seguridad: Reconstruye imágenes al menos semanalmente para corregir vulnerabilidades conocidas.

III. Estudio de caso: Lecciones de errores de configuración en Docker Compose

En julio de 2019, Capital One sufrió una importante brecha de datos que afectó la información personal de más de 100 millones de clientes [1][2]. Aunque la causa principal de este ataque fueron errores de configuración en AWS, también involucró problemas de seguridad en contenedores similares a los descritos en tu situación:

  1. Problemas de permisos en contenedores: El atacante explotó una vulnerabilidad en un firewall de aplicaciones web (WAF) que se ejecutaba en un contenedor con permisos excesivos.
  2. Aislamiento de red insuficiente: El atacante pudo acceder a otros recursos de AWS desde el contenedor comprometido, lo que indica una falta de medidas de aislamiento de red.
  3. Exposición de datos sensibles: Debido a errores de configuración, el atacante pudo acceder y robar una gran cantidad de datos sensibles de clientes.
  4. Errores de configuración de seguridad: La causa raíz del incidente fue la acumulación de múltiples errores de configuración de seguridad, incluidos problemas de configuración de contenedores y servicios en la nube.

Este incidente resultó en pérdidas financieras significativas y daño reputacional para Capital One. Se informó que la empresa enfrentó multas de hasta 150 millones de dólares, además de una crisis de confianza a largo plazo. Este caso destaca la importancia de la configuración de seguridad en entornos de contenedores y nube, especialmente en la gestión de permisos, aislamiento de red y protección de datos sensibles. Nos recuerda que incluso errores de configuración aparentemente menores pueden ser explotados por atacantes, provocando consecuencias desastrosas.

IV. Conclusión y recomendaciones

Docker Compose combinado con Ubuntu es una forma cómoda de desplegar rápidamente aplicaciones en contenedores, pero la seguridad debe integrarse a lo largo de todo el proceso:

  • Controla estrictamente los permisos de los contenedores y el aislamiento de red.
  • Evita fugas de datos sensibles.
  • Escaneos de seguridad y actualizaciones regulares.
  • Se recomienda migrar a sistemas de orquestación avanzados como Kubernetes para obtener una mayor garantía de seguridad a medida que la empresa escala.

La seguridad es una práctica continua sin un punto final. Espero que este artículo te ayude a proteger mejor tu entorno de despliegue Docker Compose + Ubuntu.