Saltar al contenido principal

47 publicaciones etiquetados con "blockchain"

Ver Todas las Etiquetas

Conectando la IA y la Web3 a través de MCP: Un Análisis Panorámico

· 20 min de lectura
Dora Noda
Software Engineer

Introducción

La IA y la Web3 están convergiendo de maneras poderosas, con las interfaces generales de IA ahora concebidas como un tejido conectivo para la web descentralizada. Un concepto clave que emerge de esta convergencia es MCP, que se refiere a “Model Context Protocol” (Protocolo de Contexto de Modelo, introducido por Anthropic) o se describe vagamente como un Protocolo de Conexión del Metaverso en discusiones más amplias. En esencia, MCP es un marco estandarizado que permite a los sistemas de IA interactuar con herramientas y redes externas de una manera natural y segura, potencialmente “conectando” agentes de IA a cada rincón del ecosistema Web3. Este informe proporciona un análisis exhaustivo de cómo las interfaces generales de IA (como los agentes de modelos de lenguaje grandes y los sistemas neuro-simbólicos) podrían conectar todo en el mundo Web3 a través de MCP, cubriendo los antecedentes históricos, la arquitectura técnica, el panorama de la industria, los riesgos y el potencial futuro.

1. Antecedentes del Desarrollo

1.1 La Evolución de la Web3 y sus Promesas Incumplidas

El término “Web3” fue acuñado alrededor de 2014 para describir una web descentralizada impulsada por blockchain. La visión era ambiciosa: una internet sin permisos centrada en la propiedad del usuario. Los entusiastas imaginaron reemplazar la infraestructura centralizada de la Web2 con alternativas basadas en blockchain, como Ethereum Name Service (para DNS), Filecoin o IPFS (para almacenamiento) y DeFi para los rieles financieros. En teoría, esto arrebataría el control a las grandes plataformas tecnológicas y otorgaría a los individuos autosoberanía sobre sus datos, identidad y activos.

La realidad se quedó corta. A pesar de años de desarrollo y expectación, el impacto general de la Web3 siguió siendo marginal. Los usuarios promedio de internet no acudieron en masa a las redes sociales descentralizadas ni comenzaron a gestionar claves privadas. Las razones clave incluyeron una mala experiencia de usuario, transacciones lentas y costosas, estafas de alto perfil e incertidumbre regulatoria. La “web de propiedad” descentralizada en gran medida “no logró materializarse” más allá de una comunidad de nicho. A mediados de la década de 2020, incluso los defensores de las criptomonedas admitieron que la Web3 no había supuesto un cambio de paradigma para el usuario promedio.

Mientras tanto, la IA estaba experimentando una revolución. A medida que el capital y el talento de los desarrolladores se desplazaban de las criptomonedas a la IA, los avances transformadores en el aprendizaje profundo y los modelos fundacionales (GPT-3, GPT-4, etc.) capturaron la imaginación del público. La IA generativa demostró una utilidad clara —produciendo contenido, código y decisiones— de una manera que las aplicaciones cripto habían tenido dificultades para lograr. De hecho, el impacto de los modelos de lenguaje grandes en solo un par de años superó con creces una década de adopción de usuarios de blockchain. Este contraste llevó a algunos a bromear diciendo que “la Web3 se desperdició en las criptomonedas” y que la verdadera Web 3.0 está emergiendo de la ola de la IA.

1.2 El Auge de las Interfaces Generales de IA

A lo largo de décadas, las interfaces de usuario evolucionaron desde páginas web estáticas (Web1.0) hasta aplicaciones interactivas (Web2.0), pero siempre dentro de los confines de hacer clic en botones y rellenar formularios. Con la IA moderna, especialmente los modelos de lenguaje grandes (LLM), ha llegado un nuevo paradigma de interfaz: el lenguaje natural. Los usuarios pueden simplemente expresar su intención en lenguaje sencillo y hacer que los sistemas de IA ejecuten acciones complejas en muchos dominios. Este cambio es tan profundo que algunos sugieren redefinir “Web 3.0” como la era de los agentes impulsados por IA (“la Web Agéntica”) en lugar de la definición anterior centrada en blockchain.

Sin embargo, los primeros experimentos con agentes de IA autónomos expusieron un cuello de botella crítico. Estos agentes —por ejemplo, prototipos como AutoGPT— podían generar texto o código, pero carecían de una forma robusta de comunicarse con sistemas externos y entre sí. No había “un lenguaje común nativo de IA” para la interoperabilidad. Cada integración con una herramienta o fuente de datos era un apaño a medida, y la interacción de IA a IA no tenía un protocolo estándar. En términos prácticos, un agente de IA podría tener una gran capacidad de razonamiento pero fallar en la ejecución de tareas que requerían el uso de aplicaciones web o servicios on-chain, simplemente porque no sabía cómo hablar con esos sistemas. Este desajuste —cerebros potentes, E/S primitiva— era similar a tener un software súper inteligente atrapado detrás de una torpe GUI.

1.3 Convergencia y el Surgimiento de MCP

Para 2024, se hizo evidente que para que la IA alcanzara su máximo potencial (y para que la Web3 cumpliera su promesa), se necesitaba una convergencia: los agentes de IA requieren un acceso fluido a las capacidades de la Web3 (aplicaciones descentralizadas, contratos, datos), y la Web3 necesita más inteligencia y usabilidad, que la IA puede proporcionar. Este es el contexto en el que nació MCP (Model Context Protocol). Introducido por Anthropic a finales de 2024, MCP es un estándar abierto para la comunicación entre IA y herramientas que resulta natural para los LLM. Proporciona una forma estructurada y reconocible para que los “hosts” de IA (como ChatGPT, Claude, etc.) encuentren y utilicen una variedad de herramientas y recursos externos a través de servidores MCP. En otras palabras, MCP es una capa de interfaz común que permite a los agentes de IA conectarse a servicios web, APIs e incluso funciones de blockchain, sin codificar a medida cada integración.

Piense en MCP como “el USB-C de las interfaces de IA”. Así como el USB-C estandarizó cómo se conectan los dispositivos (para que no necesite cables diferentes para cada dispositivo), MCP estandariza cómo los agentes de IA se conectan a herramientas y datos. En lugar de codificar diferentes llamadas a API para cada servicio (Slack vs. Gmail vs. nodo de Ethereum), un desarrollador puede implementar la especificación MCP una vez, y cualquier IA compatible con MCP puede entender cómo usar ese servicio. Los principales actores de la IA vieron rápidamente la importancia: Anthropic hizo de código abierto a MCP, y empresas como OpenAI y Google están desarrollando soporte para él en sus modelos. Este impulso sugiere que MCP (o “Protocolos de Meta Conectividad” similares) podría convertirse en la columna vertebral que finalmente conecte la IA y la Web3 de una manera escalable.

Cabe destacar que algunos tecnólogos argumentan que esta conectividad centrada en la IA es la verdadera realización de la Web3.0. En palabras de Simba Khadder, “MCP tiene como objetivo estandarizar una API entre los LLM y las aplicaciones”, de manera similar a cómo las APIs REST permitieron la Web 2.0, lo que significa que la próxima era de la Web3 podría definirse por interfaces de agentes inteligentes en lugar de solo por blockchains. En lugar de la descentralización por sí misma, la convergencia con la IA podría hacer que la descentralización sea útil, al ocultar la complejidad detrás del lenguaje natural y los agentes autónomos. El resto de este informe profundiza en cómo, técnica y prácticamente, las interfaces generales de IA (a través de protocolos como MCP) pueden conectar todo en el mundo Web3.

2. Arquitectura Técnica: Interfaces de IA Uniendo Tecnologías Web3

Incrustar agentes de IA en la pila de Web3 requiere integración en múltiples niveles: redes de blockchain y contratos inteligentes, almacenamiento descentralizado, sistemas de identidad y economías basadas en tokens. Las interfaces generales de IA —desde grandes modelos fundacionales hasta sistemas híbridos neuro-simbólicos— pueden servir como un “adaptador universal” que conecta estos componentes. A continuación, analizamos la arquitectura de dicha integración:

Figura: Un diagrama conceptual de la arquitectura de MCP, que muestra cómo los hosts de IA (aplicaciones basadas en LLM como Claude o ChatGPT) utilizan un cliente MCP para conectarse a varios servidores MCP. Cada servidor proporciona un puente a alguna herramienta o servicio externo (por ejemplo, Slack, Gmail, calendarios o datos locales), análogo a los periféricos que se conectan a través de un concentrador universal. Esta interfaz MCP estandarizada permite a los agentes de IA acceder a servicios remotos y recursos on-chain a través de un protocolo común.

2.1 Agentes de IA como Clientes Web3 (Integración con Blockchains)

En el núcleo de la Web3 se encuentran las blockchains y los contratos inteligentes, máquinas de estado descentralizadas que pueden hacer cumplir la lógica sin necesidad de confianza. ¿Cómo puede una interfaz de IA interactuar con estos? Hay dos direcciones a considerar:

  • IA leyendo de la blockchain: Un agente de IA puede necesitar datos on-chain (por ejemplo, precios de tokens, saldo de activos de un usuario, propuestas de DAO) como contexto para sus decisiones. Tradicionalmente, recuperar datos de la blockchain requiere interactuar con APIs RPC de nodos o bases de datos de subgrafos. Con un marco como MCP, una IA puede consultar un servidor MCP estandarizado de “datos de blockchain” para obtener información on-chain en tiempo real. Por ejemplo, un agente habilitado para MCP podría solicitar el último volumen de transacciones de un determinado token, o el estado de un contrato inteligente, y el servidor MCP se encargaría de los detalles de bajo nivel para conectarse a la blockchain y devolver los datos en un formato que la IA pueda usar. Esto aumenta la interoperabilidad al desacoplar la IA del formato de API de cualquier blockchain específica.

  • IA escribiendo en la blockchain: De manera más potente, los agentes de IA pueden ejecutar llamadas a contratos inteligentes o transacciones a través de integraciones Web3. Una IA podría, por ejemplo, ejecutar autónomamente una operación en un exchange descentralizado o ajustar parámetros en un contrato inteligente si se cumplen ciertas condiciones. Esto se logra mediante la invocación por parte de la IA de un servidor MCP que encapsula la funcionalidad de transacción de la blockchain. Un ejemplo concreto es el servidor MCP de thirdweb para cadenas EVM, que permite a cualquier cliente de IA compatible con MCP interactuar con Ethereum, Polygon, BSC, etc., abstrayendo la mecánica específica de la cadena. Usando una herramienta así, un agente de IA podría desencadenar acciones on-chain “sin intervención humana”, permitiendo dApps autónomas; por ejemplo, una bóveda DeFi impulsada por IA que se reequilibra a sí misma firmando transacciones cuando cambian las condiciones del mercado.

Bajo el capó, estas interacciones todavía dependen de wallets, claves y tarifas de gas, pero a la interfaz de IA se le puede dar acceso controlado a un wallet (con sandboxes de seguridad adecuados) para realizar las transacciones. Los oráculos y los puentes entre cadenas también entran en juego: redes de oráculos como Chainlink sirven como un puente entre la IA y las blockchains, permitiendo que los resultados de la IA sean introducidos on-chain de manera confiable. El Protocolo de Interoperabilidad entre Cadenas (CCIP) de Chainlink, por ejemplo, podría permitir que un modelo de IA considerado confiable desencadene múltiples contratos en diferentes cadenas simultáneamente en nombre de un usuario. En resumen, las interfaces generales de IA pueden actuar como un nuevo tipo de cliente Web3, uno que puede tanto consumir datos de la blockchain como producir transacciones de la blockchain a través de protocolos estandarizados.

2.2 Sinergia Neuro-Simbólica: Combinando el Razonamiento de la IA con los Contratos Inteligentes

Un aspecto intrigante de la integración IA-Web3 es el potencial de las arquitecturas neuro-simbólicas que combinan la capacidad de aprendizaje de la IA (redes neuronales) con la lógica rigurosa de los contratos inteligentes (reglas simbólicas). En la práctica, esto podría significar que los agentes de IA manejen la toma de decisiones no estructurada y pasen ciertas tareas a los contratos inteligentes para una ejecución verificable. Por ejemplo, una IA podría analizar el sentimiento del mercado (una tarea difusa), pero luego ejecutar operaciones a través de un contrato inteligente determinista que sigue reglas de riesgo preestablecidas. El marco MCP y los estándares relacionados hacen factibles tales transferencias al darle a la IA una interfaz común para llamar a funciones de contrato o para consultar las reglas de una DAO antes de actuar.

Un ejemplo concreto es el AI-DSL (Lenguaje Específico de Dominio de IA) de SingularityNET, que tiene como objetivo estandarizar la comunicación entre agentes de IA en su red descentralizada. Esto puede verse como un paso hacia la integración neuro-simbólica: un lenguaje formal (simbólico) para que los agentes soliciten servicios de IA o datos entre sí. De manera similar, proyectos como AlphaCode de DeepMind u otros podrían eventualmente conectarse para que los contratos inteligentes llamen a modelos de IA para la resolución de problemas on-chain. Aunque ejecutar grandes modelos de IA directamente on-chain es impráctico hoy en día, están surgiendo enfoques híbridos: por ejemplo, ciertas blockchains permiten la verificación de cálculos de ML a través de pruebas de conocimiento cero o ejecución confiable, lo que permite la verificación on-chain de resultados de IA off-chain. En resumen, la arquitectura técnica concibe los sistemas de IA y los contratos inteligentes de blockchain como componentes complementarios, orquestados a través de protocolos comunes: la IA se encarga de la percepción y las tareas abiertas, mientras que las blockchains proporcionan integridad, memoria y el cumplimiento de las reglas acordadas.

2.3 Almacenamiento Descentralizado y Datos para la IA

La IA prospera con los datos, y la Web3 ofrece nuevos paradigmas para el almacenamiento y el intercambio de datos. Las redes de almacenamiento descentralizado (como IPFS/Filecoin, Arweave, Storj, etc.) pueden servir tanto como repositorios para artefactos de modelos de IA como fuentes de datos de entrenamiento, con control de acceso basado en blockchain. Una interfaz general de IA, a través de MCP o similar, podría obtener archivos o conocimiento del almacenamiento descentralizado con la misma facilidad que desde una API de Web2. Por ejemplo, un agente de IA podría extraer un conjunto de datos del mercado de Ocean Protocol o un archivo cifrado de un almacenamiento distribuido, si tiene las claves o los pagos adecuados.

Ocean Protocol en particular se ha posicionado como una plataforma de “economía de datos de IA”, utilizando blockchain para tokenizar datos e incluso servicios de IA. En Ocean, los conjuntos de datos están representados por datatokens que controlan el acceso; un agente de IA podría obtener un datatoken (quizás pagando con criptomonedas o a través de algún derecho de acceso) y luego usar un servidor MCP de Ocean para recuperar los datos reales para su análisis. El objetivo de Ocean es desbloquear “datos inactivos” para la IA, incentivando el intercambio mientras se preserva la privacidad. Por lo tanto, una IA conectada a la Web3 podría acceder a un vasto corpus descentralizado de información —desde bóvedas de datos personales hasta datos gubernamentales abiertos— que antes estaba aislado. La blockchain asegura que el uso de los datos sea transparente y pueda ser recompensado de manera justa, alimentando un ciclo virtuoso donde más datos están disponibles para la IA y más contribuciones de IA (como modelos entrenados) pueden ser monetizadas.

Los sistemas de identidad descentralizada también juegan un papel aquí (discutido más en la siguiente subsección): pueden ayudar a controlar quién o qué tiene permitido acceder a ciertos datos. Por ejemplo, a un agente de IA médico se le podría exigir que presente una credencial verificable (prueba on-chain de cumplimiento con HIPAA o similar) antes de que se le permita descifrar un conjunto de datos médicos del almacenamiento IPFS personal de un paciente. De esta manera, la arquitectura técnica asegura que los datos fluyan hacia la IA cuando sea apropiado, pero con gobernanza y registros de auditoría on-chain para hacer cumplir los permisos.

2.4 Identidad y Gestión de Agentes en un Entorno Descentralizado

Cuando los agentes de IA autónomos operan en un ecosistema abierto como la Web3, la identidad y la confianza se vuelven primordiales. Los marcos de identidad descentralizada (DID) proporcionan una forma de establecer identidades digitales para agentes de IA que pueden ser verificadas criptográficamente. Cada agente (o el humano/organización que lo despliega) puede tener un DID y credenciales verificables asociadas que especifican sus atributos y permisos. Por ejemplo, un bot de trading de IA podría llevar una credencial emitida por un sandbox regulatorio que certifique que puede operar dentro de ciertos límites de riesgo, o un moderador de contenido de IA podría demostrar que fue creado por una organización de confianza y ha sido sometido a pruebas de sesgo.

A través de registros de identidad y sistemas de reputación on-chain, el mundo Web3 puede hacer cumplir la responsabilidad por las acciones de la IA. Cada transacción que realiza un agente de IA puede ser rastreada hasta su ID, y si algo sale mal, las credenciales te dicen quién lo construyó o quién es responsable. Esto aborda un desafío crítico: sin identidad, un actor malicioso podría crear agentes de IA falsos para explotar sistemas o difundir desinformación, y nadie podría distinguir los bots de los servicios legítimos. La identidad descentralizada ayuda a mitigar eso al permitir una autenticación robusta y distinguir los agentes de IA auténticos de las falsificaciones.

En la práctica, una interfaz de IA integrada con la Web3 usaría protocolos de identidad para firmar sus acciones y solicitudes. Por ejemplo, cuando un agente de IA llama a un servidor MCP para usar una herramienta, podría incluir un token o firma vinculada a su identidad descentralizada, para que el servidor pueda verificar que la llamada proviene de un agente autorizado. Los sistemas de identidad basados en blockchain (como el ERC-725 de Ethereum o los DID de W3C anclados en un ledger) aseguran que esta verificación sea sin confianza y verificable globalmente. El concepto emergente de “wallets de IA” se relaciona con esto: esencialmente, dar a los agentes de IA wallets de criptomonedas que están vinculados con su identidad, para que puedan gestionar claves, pagar por servicios o hacer staking de tokens como una fianza (que podría ser recortada por mal comportamiento). ArcBlock, por ejemplo, ha discutido cómo “los agentes de IA necesitan un wallet” y un DID para operar de manera responsable en entornos descentralizados.

En resumen, la arquitectura técnica prevé a los agentes de IA como ciudadanos de primera clase en la Web3, cada uno con una identidad on-chain y posiblemente una participación en el sistema, utilizando protocolos como MCP para interactuar. Esto crea una red de confianza: los contratos inteligentes pueden requerir las credenciales de una IA antes de cooperar, y los usuarios pueden optar por delegar tareas solo a aquellas IA que cumplan con ciertas certificaciones on-chain. Es una mezcla de la capacidad de la IA con las garantías de confianza de la blockchain.

2.5 Economías de Tokens e Incentivos para la IA

La tokenización es un sello distintivo de la Web3, y se extiende también al dominio de la integración de la IA. Al introducir incentivos económicos a través de tokens, las redes pueden fomentar comportamientos deseados tanto de los desarrolladores de IA como de los propios agentes. Están surgiendo varios patrones:

  • Pago por Servicios: Los modelos y servicios de IA pueden ser monetizados on-chain. SingularityNET fue pionero en esto al permitir a los desarrolladores desplegar servicios de IA y cobrar a los usuarios en un token nativo (AGIX) por cada llamada. En un futuro habilitado para MCP, uno podría imaginar cualquier herramienta o modelo de IA como un servicio plug-and-play donde el uso se mide a través de tokens o micropagos. Por ejemplo, si un agente de IA utiliza una API de visión de terceros a través de MCP, podría manejar automáticamente el pago transfiriendo tokens al contrato inteligente del proveedor de servicios. Fetch.ai de manera similar visualiza mercados donde “agentes económicos autónomos” intercambian servicios y datos, con su nuevo LLM de Web3 (ASI-1) presumiblemente integrando transacciones cripto para el intercambio de valor.

  • Staking y Reputación: Para asegurar la calidad y la fiabilidad, algunos proyectos requieren que los desarrolladores o agentes hagan staking de tokens. Por ejemplo, el proyecto DeMCP (un mercado descentralizado de servidores MCP) planea usar incentivos de tokens para recompensar a los desarrolladores por crear servidores MCP útiles, y posiblemente hacer que hagan staking de tokens como señal de compromiso con la seguridad de su servidor. La reputación también podría estar vinculada a los tokens; por ejemplo, un agente que se desempeña consistentemente bien podría acumular tokens de reputación o reseñas positivas on-chain, mientras que uno que se comporta mal podría perder su stake o ganar marcas negativas. Esta reputación tokenizada puede luego retroalimentar el sistema de identidad mencionado anteriormente (los contratos inteligentes o los usuarios verifican la reputación on-chain del agente antes de confiar en él).

  • Tokens de Gobernanza: Cuando los servicios de IA se convierten en parte de plataformas descentralizadas, los tokens de gobernanza permiten a la comunidad dirigir su evolución. Proyectos como SingularityNET y Ocean tienen DAOs donde los poseedores de tokens votan sobre cambios en el protocolo o la financiación de iniciativas de IA. En la Alianza de Superinteligencia Artificial (ASI) combinada —una fusión recientemente anunciada de SingularityNET, Fetch.ai y Ocean Protocol— un token unificado (ASI) está destinado a gobernar la dirección de un ecosistema conjunto de IA+blockchain. Dichos tokens de gobernanza podrían decidir políticas como qué estándares adoptar (por ejemplo, soportar MCP o protocolos A2A), qué proyectos de IA incubar o cómo manejar las directrices éticas para los agentes de IA.

  • Acceso y Utilidad: Los tokens pueden controlar el acceso no solo a los datos (como con los datatokens de Ocean) sino también al uso de modelos de IA. Un escenario posible son los “NFTs de modelos” o similares, donde poseer un token te otorga derechos sobre los resultados de un modelo de IA o una participación en sus ganancias. Esto podría sustentar los mercados de IA descentralizados: imagina un NFT que representa la propiedad parcial de un modelo de alto rendimiento; los propietarios ganan colectivamente cada vez que el modelo se utiliza en tareas de inferencia, y pueden votar sobre su ajuste fino. Aunque experimental, esto se alinea con el ethos de la Web3 de propiedad compartida aplicada a los activos de IA.

En términos técnicos, integrar tokens significa que los agentes de IA necesitan funcionalidad de wallet (como se señaló, muchos tendrán sus propios wallets de criptomonedas). A través de MCP, una IA podría tener una “herramienta de wallet” que le permita verificar saldos, enviar tokens o llamar a protocolos DeFi (quizás para intercambiar un token por otro para pagar un servicio). Por ejemplo, si un agente de IA que se ejecuta en Ethereum necesita algunos tokens de Ocean para comprar un conjunto de datos, podría intercambiar automáticamente algunos ETH por $OCEAN a través de un DEX usando un plugin de MCP, y luego proceder con la compra, todo sin intervención humana, guiado por las políticas establecidas por su propietario.

En general, la economía de tokens proporciona la capa de incentivos en la arquitectura IA-Web3, asegurando que los contribuyentes (ya sea que proporcionen datos, código de modelo, poder de cómputo o auditorías de seguridad) sean recompensados, y que los agentes de IA tengan “algo en juego” que los alinee (hasta cierto punto) con las

Enso Network: El motor de ejecución unificado basado en intenciones

· 43 min de lectura

Arquitectura del Protocolo

Enso Network es una plataforma de desarrollo Web3 construida como un motor de ejecución unificado y basado en intenciones para operaciones en la cadena. Su arquitectura abstrae la complejidad de la blockchain al mapear cada interacción en la cadena a un motor compartido que opera a través de múltiples cadenas. Los desarrolladores y usuarios especifican intenciones de alto nivel (resultados deseados como un intercambio de tokens, provisión de liquidez, estrategia de rendimiento, etc.), y la red de Enso encuentra y ejecuta la secuencia óptima de acciones para cumplir esas intenciones. Esto se logra a través de un diseño modular de "Acciones" y "Atajos".

Las Acciones son abstracciones granulares de contratos inteligentes (por ejemplo, un intercambio en Uniswap, un depósito en Aave) proporcionadas por la comunidad. Múltiples Acciones pueden componerse en Atajos, que son flujos de trabajo reutilizables que representan operaciones comunes de DeFi. Enso mantiene una biblioteca de estos Atajos en contratos inteligentes, por lo que las tareas complejas pueden ejecutarse mediante una sola llamada a la API o transacción. Esta arquitectura basada en intenciones permite a los desarrolladores centrarse en los resultados deseados en lugar de escribir código de integración de bajo nivel para cada protocolo y cadena.

La infraestructura de Enso incluye una red descentralizada (construida sobre el consenso de Tendermint) que sirve como una capa unificadora que conecta diferentes blockchains. La red agrega datos (estado de varias L1, rollups y appchains) en un estado de red compartido o libro mayor, permitiendo la componibilidad entre cadenas y una ejecución precisa en múltiples cadenas. En la práctica, esto significa que Enso puede leer y escribir en cualquier blockchain integrada a través de una única interfaz, actuando como un único punto de acceso para los desarrolladores. Inicialmente centrado en cadenas compatibles con EVM, Enso ha ampliado su soporte a ecosistemas no-EVM; por ejemplo, la hoja de ruta incluye integraciones para Monad (una L1 similar a Ethereum), Solana y Movement (una cadena de lenguaje Move) para el primer trimestre de 2025.

Participantes de la Red: La innovación de Enso radica en su modelo de participantes de tres niveles, que descentraliza cómo se procesan las intenciones:

  • Proveedores de Acciones – Desarrolladores que contribuyen con abstracciones de contratos modulares ("Acciones") que encapsulan interacciones específicas de protocolos. Estos bloques de construcción se comparten en la red para que otros los usen. Los Proveedores de Acciones son recompensados cada vez que su Acción contribuida se utiliza en una ejecución, incentivándolos a publicar módulos seguros y eficientes.

  • Graphers – Solucionadores independientes (algoritmos) que combinan Acciones en Atajos ejecutables para cumplir las intenciones de los usuarios. Múltiples Graphers compiten para encontrar la solución más óptima (la ruta más barata, más rápida o de mayor rendimiento) para cada solicitud, de manera similar a cómo compiten los solucionadores en un agregador de DEX. Solo se selecciona la mejor solución para la ejecución, y el Grapher ganador obtiene una parte de las tarifas. Este mecanismo competitivo fomenta la optimización continua de las rutas y estrategias en la cadena.

  • Validadores – Operadores de nodos que aseguran la red de Enso verificando y finalizando las soluciones de los Graphers. Los Validadores autentican las solicitudes entrantes, verifican la validez y seguridad de las Acciones/Atajos utilizados, simulan transacciones y, en última instancia, confirman la ejecución de la solución seleccionada. Forman la columna vertebral de la integridad de la red, asegurando que los resultados sean correctos y previniendo soluciones maliciosas o ineficientes. Los Validadores ejecutan un consenso basado en Tendermint, lo que significa que se utiliza un proceso de prueba de participación BFT para llegar a un acuerdo sobre el resultado de cada intención y para actualizar el estado de la red.

Cabe destacar que el enfoque de Enso es agnóstico a la cadena y centrado en la API. Los desarrolladores interactúan con Enso a través de una API/SDK unificada en lugar de lidiar con las particularidades de cada cadena. Enso se integra con más de 250 protocolos DeFi en múltiples blockchains, convirtiendo efectivamente ecosistemas dispares en una plataforma componible. Esta arquitectura elimina la necesidad de que los equipos de dApps escriban contratos inteligentes personalizados o manejen la mensajería entre cadenas para cada nueva integración; el motor compartido de Enso y las Acciones proporcionadas por la comunidad se encargan de ese trabajo pesado. A mediados de 2025, Enso ha demostrado su escalabilidad: la red facilitó con éxito 3.1milmillonesdemigracioˊndeliquidezen3dıˊasparaellanzamientodeBerachain(unodelosmayoreseventosdemigracioˊndeDeFi)yhaprocesadomaˊsde3.1 mil millones de migración de liquidez en 3 días** para el lanzamiento de Berachain (uno de los mayores eventos de migración de DeFi) y ha procesado más de **15 mil millones en transacciones en la cadena hasta la fecha. Estas hazañas demuestran la robustez de la infraestructura de Enso en condiciones del mundo real.

En general, la arquitectura del protocolo de Enso ofrece un "middleware de DeFi" o un sistema operativo en la cadena para Web3. Combina elementos de indexación (como The Graph) y ejecución de transacciones (como puentes entre cadenas o agregadores de DEX) en una única red descentralizada. Esta pila única permite que cualquier aplicación, bot o agente lea y escriba en cualquier contrato inteligente en cualquier cadena a través de una sola integración, acelerando el desarrollo y habilitando nuevos casos de uso componibles. Enso se posiciona como una infraestructura crítica para el futuro multicadena: un motor de intenciones que podría potenciar una miríada de aplicaciones sin que cada una necesite reinventar las integraciones de blockchain.

Tokenomics

El modelo económico de Enso se centra en el token ENSO, que es integral para la operación y gobernanza de la red. ENSO es un token de utilidad y gobernanza con un suministro total fijo de 100 millones de tokens. El diseño del token alinea los incentivos para todos los participantes y crea un efecto flywheel de uso y recompensas:

  • Moneda de Tarifa ("Gas"): Todas las solicitudes enviadas a la red de Enso incurren en una tarifa de consulta pagadera en ENSO. Cuando un usuario (o dApp) activa una intención, se incrusta una pequeña tarifa en el bytecode de la transacción generada. Estas tarifas se subastan por tokens ENSO en el mercado abierto y luego se distribuyen a los participantes de la red que procesan la solicitud. En efecto, ENSO es el gas que impulsa la ejecución de intenciones en la cadena a través de la red de Enso. A medida que crece la demanda de los atajos de Enso, la demanda de tokens ENSO puede aumentar para pagar esas tarifas de red, creando un bucle de retroalimentación de oferta y demanda que respalda el valor del token.

  • Reparto de Ingresos y Recompensas por Staking: El ENSO recaudado de las tarifas se distribuye entre los Proveedores de Acciones, Graphers y Validadores como recompensa por sus contribuciones. Este modelo vincula directamente las ganancias de tokens con el uso de la red: más volumen de intenciones significa más tarifas para distribuir. Los Proveedores de Acciones ganan tokens cuando se utilizan sus abstracciones, los Graphers ganan tokens por soluciones ganadoras y los Validadores ganan tokens por validar y asegurar la red. Los tres roles también deben hacer staking de ENSO como garantía para participar (para ser penalizados por mala praxis), alineando sus incentivos con la salud de la red. Los poseedores de tokens también pueden delegar su ENSO a los Validadores, apoyando la seguridad de la red a través de la prueba de participación delegada. Este mecanismo de staking no solo asegura el consenso de Tendermint, sino que también otorga a los stakers de tokens una parte de las tarifas de la red, de manera similar a cómo los mineros/validadores ganan tarifas de gas en otras cadenas.

  • Gobernanza: Los poseedores de tokens ENSO gobernarán la evolución del protocolo. Enso se está lanzando como una red abierta y planea hacer la transición a una toma de decisiones impulsada por la comunidad. La votación ponderada por tokens permitirá a los poseedores influir en las actualizaciones, cambios de parámetros (como los niveles de tarifas o las asignaciones de recompensas) y el uso de la tesorería. Este poder de gobernanza asegura que los contribuyentes principales y los usuarios estén alineados en la dirección de la red. La filosofía del proyecto es poner la propiedad en manos de la comunidad de constructores y usuarios, lo cual fue una razón impulsora para la venta de tokens comunitaria en 2025 (ver más abajo).

  • Flywheel Positivo: La tokenomics de Enso está diseñada para crear un bucle que se auto-refuerza. A medida que más desarrolladores integran Enso y más usuarios ejecutan intenciones, las tarifas de red (pagadas en ENSO) crecen. Esas tarifas recompensan a los contribuyentes (atrayendo más Acciones, mejores Graphers y más Validadores), lo que a su vez mejora las capacidades de la red (ejecución más rápida, más barata y más confiable) y atrae más uso. Este efecto de red está respaldado por el papel del token ENSO como moneda de tarifa e incentivo para la contribución. La intención es que la economía del token escale de manera sostenible con la adopción de la red, en lugar de depender de emisiones insostenibles.

Distribución y Suministro de Tokens: La asignación inicial de tokens está estructurada para equilibrar los incentivos del equipo/inversores con la propiedad de la comunidad. La siguiente tabla resume la distribución de tokens ENSO en su génesis:

AsignaciónPorcentajeTokens (de 100M)
Equipo (Fundadores y Núcleo)25.0%25,000,000
Inversores Tempranos (VCs)31.3%31,300,000
Fundación y Fondo de Crecimiento23.2%23,200,000
Tesorería del Ecosistema (incentivos comunitarios)15.0%15,000,000
Venta Pública (CoinList 2025)4.0%4,000,000
Asesores1.5%1,500,000

Fuente: Tokenomics de Enso.

La venta pública en junio de 2025 ofreció el 5% (4 millones de tokens) a la comunidad, recaudando 5millonesaunpreciode5 millones a un precio de 1.25 por ENSO (lo que implica una valoración totalmente diluida de ~$125 millones). Notablemente, la venta comunitaria no tuvo bloqueo (100% desbloqueado en el TGE), mientras que el equipo y los inversores de capital de riesgo están sujetos a un calendario de vesting lineal de 2 años. Esto significa que los tokens de los insiders se desbloquean gradualmente bloque por bloque durante 24 meses, alineándolos con el crecimiento a largo plazo de la red y mitigando la presión de venta inmediata. La comunidad obtuvo así liquidez y propiedad inmediatas, reflejando el objetivo de Enso de una amplia distribución.

El calendario de emisiones de Enso más allá de la asignación inicial parece estar impulsado principalmente por las tarifas en lugar de ser inflacionario. El suministro total está fijado en 100 millones de tokens, y no hay indicación de inflación perpetua para las recompensas de bloque en este momento (los validadores son compensados con los ingresos de las tarifas). Esto contrasta con muchos protocolos de Capa 1 que inflan el suministro para pagar a los stakers; Enso aspira a ser sostenible a través de las tarifas de uso reales para recompensar a los participantes. Si la actividad de la red es baja en las fases iniciales, las asignaciones de la fundación y la tesorería pueden utilizarse para impulsar incentivos para el uso y subvenciones de desarrollo. Por el contrario, si la demanda es alta, la utilidad del token ENSO (para tarifas y staking) podría crear una presión de demanda orgánica.

En resumen, ENSO es el combustible de la Red Enso. Impulsa las transacciones (tarifas de consulta), asegura la red (staking y slashing) y gobierna la plataforma (votación). El valor del token está directamente ligado a la adopción de la red: a medida que Enso se utilice más ampliamente como la columna vertebral de las aplicaciones DeFi, el volumen de tarifas y staking de ENSO debería reflejar ese crecimiento. La cuidadosa distribución (con solo una pequeña porción circulando inmediatamente después del TGE) y el fuerte respaldo de los principales inversores (a continuación) proporcionan confianza en el soporte del token, mientras que la venta centrada en la comunidad señala un compromiso con la descentralización de la propiedad.

Equipo e Inversores

Enso Network fue fundada en 2021 por Connor Howe (CEO) y Gorazd Ocvirk, quienes trabajaron juntos previamente en Sygnum Bank en el sector de la criptobanca de Suiza. Connor Howe lidera el proyecto como CEO y es la cara pública en comunicaciones y entrevistas. Bajo su liderazgo, Enso se lanzó inicialmente como una plataforma de trading social DeFi y luego pivotó a través de múltiples iteraciones para llegar a la visión actual de infraestructura basada en intenciones. Esta adaptabilidad destaca la resiliencia empresarial del equipo: desde ejecutar un "ataque vampiro" de alto perfil a protocolos de índices en 2021 hasta construir una super-app agregadora de DeFi, y finalmente generalizar sus herramientas en la plataforma para desarrolladores de Enso. El cofundador Gorazd Ocvirk (PhD) aportó una profunda experiencia en finanzas cuantitativas y estrategia de productos Web3, aunque fuentes públicas sugieren que podría haber pasado a otras empresas (fue señalado como cofundador de otra startup de cripto en 2022). El equipo central de Enso hoy incluye ingenieros y operadores con sólidos antecedentes en DeFi. Por ejemplo, Peter Phillips y Ben Wolf están listados como ingenieros de "blockend" (backend de blockchain), y Valentin Meylan lidera la investigación. El equipo está distribuido globalmente pero tiene sus raíces en Zug/Zúrich, Suiza, un conocido centro para proyectos de cripto (Enso Finance AG se registró en 2020 en Suiza).

Más allá de los fundadores, Enso cuenta con asesores y patrocinadores notables que le otorgan una credibilidad significativa. El proyecto está respaldado por fondos de capital de riesgo de cripto de primer nivel y ángeles: cuenta con Polychain Capital y Multicoin Capital como inversores principales, junto con Dialectic y Spartan Group (ambos fondos de cripto prominentes), e IDEO CoLab. Una impresionante lista de inversores ángeles también participó en las rondas: más de 70 individuos de proyectos Web3 líderes han invertido en Enso. Estos incluyen fundadores o ejecutivos de LayerZero, Safe (Gnosis Safe), 1inch, Yearn Finance, Flashbots, Dune Analytics, Pendle, y otros. Incluso el luminario tecnológico Naval Ravikant (cofundador de AngelList) es un inversor y partidario. Tales nombres señalan una fuerte confianza de la industria en la visión de Enso.

Historial de financiación de Enso: el proyecto recaudó una ronda semilla de 5Maprincipiosde2021paraconstruirlaplataformadetradingsocial,ymaˊstardeunarondade5M a principios de 2021 para construir la plataforma de trading social, y más tarde una ronda de 4.2M (estratégica/VC) a medida que evolucionaba el producto (estas primeras rondas probablemente incluyeron a Polychain, Multicoin, Dialectic, etc.). A mediados de 2023, Enso había asegurado suficiente capital para construir su red; notablemente, operó relativamente bajo el radar hasta que su pivote de infraestructura ganó tracción. En el segundo trimestre de 2025, Enso lanzó una venta de tokens comunitaria de $5M en CoinList, que fue sobresuscrita por decenas de miles de participantes. El propósito de esta venta no era solo recaudar fondos (la cantidad era modesta dado el respaldo previo de VC) sino descentralizar la propiedad y dar a su creciente comunidad una participación en el éxito de la red. Según el CEO Connor Howe, "queremos que nuestros primeros partidarios, usuarios y creyentes tengan una propiedad real en Enso... convirtiendo a los usuarios en defensores". Este enfoque centrado en la comunidad es parte de la estrategia de Enso para impulsar el crecimiento de base y los efectos de red a través de incentivos alineados.

Hoy en día, el equipo de Enso es considerado uno de los líderes de opinión en el espacio de "DeFi basado en intenciones". Participan activamente en la educación de desarrolladores (por ejemplo, el Speedrun de Atajos de Enso atrajo a 700k participantes como un evento de aprendizaje gamificado) y colaboran con otros protocolos en integraciones. La combinación de un equipo central fuerte con una capacidad probada para pivotar, inversores de primer nivel y una comunidad entusiasta sugiere que Enso tiene tanto el talento como el respaldo financiero para ejecutar su ambiciosa hoja de ruta.

Métricas de Adopción y Casos de Uso

A pesar de ser una infraestructura relativamente nueva, Enso ha demostrado una tracción significativa en su nicho. Se ha posicionado como la solución de referencia para proyectos que necesitan integraciones complejas en la cadena o capacidades entre cadenas. Algunas métricas de adopción e hitos clave a mediados de 2025:

  • Integración del Ecosistema: Más de 100 aplicaciones en vivo (dApps, billeteras y servicios) están utilizando Enso bajo el capó para potenciar funciones en la cadena. Estas van desde paneles de DeFi hasta optimizadores de rendimiento automatizados. Debido a que Enso abstrae los protocolos, los desarrolladores pueden agregar rápidamente nuevas funciones de DeFi a su producto conectándose a la API de Enso. La red se ha integrado con más de 250 protocolos DeFi (DEXes, plataformas de préstamos, granjas de rendimiento, mercados de NFT, etc.) en las principales cadenas, lo que significa que Enso puede ejecutar prácticamente cualquier acción en la cadena que un usuario pueda desear, desde una operación en Uniswap hasta un depósito en una bóveda de Yearn. Esta amplitud de integraciones reduce significativamente el tiempo de desarrollo para los clientes de Enso: un nuevo proyecto puede soportar, por ejemplo, todos los DEXes en Ethereum, Capas 2 e incluso Solana usando Enso, en lugar de codificar cada integración de forma independiente.

  • Adopción de Desarrolladores: La comunidad de Enso ahora incluye a más de 1,900 desarrolladores que construyen activamente con su conjunto de herramientas. Estos desarrolladores pueden estar creando directamente Atajos/Acciones o incorporando Enso en sus aplicaciones. La cifra destaca que Enso no es solo un sistema cerrado; está habilitando un creciente ecosistema de constructores que utilizan sus atajos o contribuyen a su biblioteca. El enfoque de Enso de simplificar el desarrollo en la cadena (afirmando reducir los tiempos de construcción de más de 6 meses a menos de una semana) ha resonado entre los desarrolladores de Web3. Esto también se evidencia en hackatones y en la biblioteca de Plantillas de Enso, donde los miembros de la comunidad comparten ejemplos de atajos listos para usar.

  • Volumen de Transacciones: Más de 15milmillonesenvolumenacumuladodetransaccionesenlacadenasehanliquidadoatraveˊsdelainfraestructuradeEnso.Estameˊtrica,seguˊnseinformoˊenjuniode2025,subrayaqueEnsonosoloseejecutaenentornosdeprueba,sinoqueprocesavalorrealaescala.UnejemplodealtoperfilfuelamigracioˊndeliquidezdeBerachain:enabrilde2025,Ensoimpulsoˊelmovimientodeliquidezparalacampan~adetestnetdeBerachain("Boyco")yfacilitoˊ15 mil millones** en volumen acumulado de transacciones en la cadena se han liquidado a través de la infraestructura de Enso. Esta métrica, según se informó en junio de 2025, subraya que Enso no solo se ejecuta en entornos de prueba, sino que procesa valor real a escala. Un ejemplo de alto perfil fue la **migración de liquidez de Berachain**: en abril de 2025, Enso impulsó el movimiento de liquidez para la campaña de testnet de Berachain ("Boyco") y facilitó **3.1 mil millones en transacciones ejecutadas durante 3 días, uno de los mayores eventos de liquidez en la historia de DeFi. El motor de Enso manejó con éxito esta carga, demostrando fiabilidad y rendimiento bajo estrés. Otro ejemplo es la asociación de Enso con Uniswap: Enso construyó una herramienta de Migración de Posiciones de Uniswap (en colaboración con Uniswap Labs, LayerZero y Stargate) que ayudó a los usuarios a migrar sin problemas las posiciones de LP de Uniswap v3 de Ethereum a otra cadena. Esta herramienta simplificó un proceso entre cadenas típicamente complejo (con puentes y redespliegue de NFTs) en un atajo de un solo clic, y su lanzamiento mostró la capacidad de Enso para trabajar junto a los principales protocolos de DeFi.

  • Casos de Uso del Mundo Real: La propuesta de valor de Enso se entiende mejor a través de los diversos casos de uso que habilita. Los proyectos han utilizado Enso para ofrecer características que serían muy difíciles de construir por sí solos:

    • Agregación de Rendimiento entre Cadenas: Plume y Sonic utilizaron Enso para impulsar campañas de lanzamiento incentivadas donde los usuarios podían depositar activos en una cadena y desplegarlos en rendimientos en otra. Enso manejó la mensajería entre cadenas y las transacciones de múltiples pasos, permitiendo que estos nuevos protocolos ofrecieran experiencias fluidas entre cadenas a los usuarios durante sus eventos de lanzamiento de tokens.
    • Migración y Fusión de Liquidez: Como se mencionó, Berachain aprovechó Enso para una migración de liquidez similar a un "ataque vampiro" desde otros ecosistemas. De manera similar, otros protocolos podrían usar los Atajos de Enso para automatizar el movimiento de los fondos de los usuarios desde una plataforma competidora a la suya, agrupando aprobaciones, retiros, transferencias y depósitos entre plataformas en una sola intención. Esto demuestra el potencial de Enso en las estrategias de crecimiento de protocolos.
    • Funcionalidad de "Super App" DeFi: Algunas billeteras e interfaces (por ejemplo, el asistente de cripto Eliza OS y la plataforma de trading Infinex) integran Enso para ofrecer acciones DeFi todo en uno. Un usuario puede, con un solo clic, intercambiar activos a la mejor tasa (Enso enrutará a través de DEXes), luego prestar el resultado para ganar rendimiento, y quizás hacer staking de un token LP, todo lo cual Enso puede ejecutar como un solo Atajo. Esto mejora significativamente la experiencia del usuario y la funcionalidad de esas aplicaciones.
    • Automatización y Bots: La presencia de "agentes" e incluso bots impulsados por IA que utilizan Enso está emergiendo. Debido a que Enso expone una API, los traders algorítmicos o los agentes de IA pueden introducir un objetivo de alto nivel (por ejemplo, "maximizar el rendimiento del activo X en cualquier cadena") y dejar que Enso encuentre la estrategia óptima. Esto ha abierto la experimentación en estrategias de DeFi automatizadas sin necesidad de ingeniería de bots personalizada para cada protocolo.
  • Crecimiento de Usuarios: Aunque Enso es principalmente una infraestructura B2B/B2Dev, ha cultivado una comunidad de usuarios finales y entusiastas a través de campañas. El Shortcut Speedrun, una serie de tutoriales gamificados, tuvo más de 700,000 participantes, lo que indica un interés generalizado en las capacidades de Enso. El seguimiento social de Enso ha crecido casi 10 veces en unos pocos meses (248k seguidores en X a mediados de 2025), lo que refleja un fuerte reconocimiento entre los usuarios de cripto. Este crecimiento de la comunidad es importante porque crea una demanda de base: los usuarios conscientes de Enso animarán a sus dApps favoritas a integrarlo o utilizarán productos que aprovechen los atajos de Enso.

En resumen, Enso ha pasado de la teoría a la adopción real. Es confiable para más de 100 proyectos, incluyendo nombres conocidos como Uniswap, SushiSwap, Stargate/LayerZero, Berachain, zkSync, Safe, Pendle, Yearn y más, ya sea como socios de integración o usuarios directos de la tecnología de Enso. Este amplio uso en diferentes verticales (DEXs, puentes, capas 1, dApps) destaca el papel de Enso como infraestructura de propósito general. Su métrica clave de tracción, más de $15 mil millones en transacciones, es especialmente impresionante para un proyecto de infraestructura en esta etapa y valida el ajuste del mercado para un middleware basado en intenciones. Los inversores pueden estar tranquilos de que los efectos de red de Enso parecen estar activándose: más integraciones generan más uso, lo que a su vez genera más integraciones. El desafío por delante será convertir este impulso inicial en un crecimiento sostenido, lo que se relaciona con el posicionamiento de Enso frente a los competidores y su hoja de ruta.

Panorama Competitivo

Enso Network opera en la intersección de la agregación DeFi, la interoperabilidad entre cadenas y la infraestructura para desarrolladores, lo que hace que su panorama competitivo sea multifacético. Aunque ningún competidor único ofrece un producto idéntico, Enso se enfrenta a la competencia de varias categorías de protocolos Web3:

  • Middleware Descentralizado e Indexación: La analogía más directa es The Graph (GRT). The Graph proporciona una red descentralizada para consultar datos de blockchain a través de subgrafos. Enso de manera similar obtiene proveedores de datos de la comunidad (Proveedores de Acciones) pero va un paso más allá al permitir la ejecución de transacciones además de la obtención de datos. Mientras que la capitalización de mercado de ~$924M de The Graph se basa solo en la indexación, el alcance más amplio de Enso (datos + acción) lo posiciona como una herramienta más poderosa para captar la atención de los desarrolladores. Sin embargo, The Graph es una red bien establecida; Enso tendrá que demostrar la fiabilidad y seguridad de su capa de ejecución para lograr una adopción similar. Se podría imaginar que The Graph u otros protocolos de indexación se expandan hacia la ejecución, lo que competiría directamente con el nicho de Enso.

  • Protocolos de Interoperabilidad entre Cadenas: Proyectos como LayerZero, Axelar, Wormhole y Chainlink CCIP proporcionan infraestructura para conectar diferentes blockchains. Se centran en el paso de mensajes y el puenteo de activos entre cadenas. Enso en realidad utiliza algunos de estos bajo el capó (por ejemplo, LayerZero/Stargate para el puenteo en el migrador de Uniswap) y es más una abstracción de nivel superior. En términos de competencia, si estos protocolos de interoperabilidad comienzan a ofrecer APIs de "intención" de nivel superior o SDKs amigables para desarrolladores para componer acciones multicadena, podrían superponerse con Enso. Por ejemplo, Axelar ofrece un SDK para llamadas entre cadenas, y el CCIP de Chainlink podría permitir la ejecución de funciones entre cadenas. El diferenciador de Enso es que no solo envía mensajes entre cadenas; mantiene un motor unificado y una biblioteca de acciones DeFi. Se dirige a los desarrolladores de aplicaciones que desean una solución lista para usar, en lugar de obligarlos a construir sobre primitivas crudas entre cadenas. No obstante, Enso competirá por la cuota de mercado en el segmento más amplio de middleware de blockchain, donde estos proyectos de interoperabilidad están bien financiados e innovando rápidamente.

  • Agregadores de Transacciones y Automatización: En el mundo DeFi, existen agregadores como 1inch, 0x API o CoW Protocol que se centran en encontrar las rutas de intercambio óptimas a través de los exchanges. El mecanismo de Grapher de Enso para las intenciones es conceptualmente similar a la competencia de solucionadores de CoW Protocol, pero Enso lo generaliza más allá de los swaps a cualquier acción. La intención de un usuario de "maximizar el rendimiento" podría implicar intercambiar, prestar, hacer staking, etc., lo cual está fuera del alcance de un agregador de DEX puro. Dicho esto, Enso será comparado con estos servicios en eficiencia para casos de uso superpuestos (por ejemplo, Enso vs. 1inch para una ruta de intercambio de tokens compleja). Si Enso encuentra consistentemente mejores rutas o tarifas más bajas gracias a su red de Graphers, puede superar a los agregadores tradicionales. Gelato Network es otro competidor en automatización: Gelato proporciona una red descentralizada de bots para ejecutar tareas como órdenes límite, auto-compounding o transferencias entre cadenas en nombre de las dApps. Gelato tiene un token GEL y una base de clientes establecida para casos de uso específicos. La ventaja de Enso es su amplitud e interfaz unificada: en lugar de ofrecer productos separados para cada caso de uso (como lo hace Gelato), Enso ofrece una plataforma general donde cualquier lógica puede codificarse como un Atajo. Sin embargo, la ventaja inicial y el enfoque de Gelato en áreas como la automatización podrían atraer a desarrolladores que de otro modo usarían Enso para funcionalidades similares.

  • Plataformas para Desarrolladores (SDKs Web3): También existen plataformas para desarrolladores al estilo Web2 como Moralis, Alchemy, Infura y Tenderly que simplifican la construcción en blockchains. Estas suelen ofrecer acceso a API para leer datos, enviar transacciones y, a veces, puntos finales de nivel superior (por ejemplo, "obtener saldos de tokens" o "enviar tokens a través de la cadena"). Aunque estos son en su mayoría servicios centralizados, compiten por la misma atención de los desarrolladores. El punto de venta de Enso es que es descentralizado y componible: los desarrolladores no solo obtienen datos o una única función, sino que acceden a toda una red de capacidades en la cadena contribuidas por otros. Si tiene éxito, Enso podría convertirse en "el GitHub de las acciones en la cadena", donde los desarrolladores comparten y reutilizan Atajos, de manera muy similar al código de fuente abierta. Competir con empresas de infraestructura como servicio bien financiadas significa que Enso necesitará ofrecer una fiabilidad y facilidad de uso comparables, lo cual está tratando de lograr con una API y documentación extensas.

  • Soluciones Propias: Finalmente, Enso compite con el status quo: equipos que construyen integraciones personalizadas internamente. Tradicionalmente, cualquier proyecto que quisiera funcionalidad multiprotocolo tenía que escribir y mantener contratos inteligentes o scripts para cada integración (por ejemplo, integrar Uniswap, Aave, Compound por separado). Muchos equipos aún podrían elegir esta ruta para tener el máximo control o por consideraciones de seguridad. Enso necesita convencer a los desarrolladores de que externalizar este trabajo a una red compartida es seguro, rentable y está actualizado. Dada la velocidad de la innovación en DeFi, mantener las propias integraciones es una carga (Enso a menudo cita que los equipos gastan más de 6 meses y $500k en auditorías para integrar docenas de protocolos). Si Enso puede demostrar su rigor en seguridad y mantener su biblioteca de acciones actualizada con los últimos protocolos, puede convertir a más equipos para que dejen de construir en silos. Sin embargo, cualquier incidente de seguridad de alto perfil o tiempo de inactividad en Enso podría hacer que los desarrolladores vuelvan a preferir soluciones internas, lo cual es un riesgo competitivo en sí mismo.

Diferenciadores de Enso: La principal ventaja de Enso es ser el primero en el mercado con una red de ejecución centrada en intenciones e impulsada por la comunidad. Combina características que requerirían el uso de múltiples otros servicios: indexación de datos, SDKs de contratos inteligentes, enrutamiento de transacciones y puentes entre cadenas, todo en uno. Su modelo de incentivos (recompensar a desarrolladores de terceros por sus contribuciones) también es único; podría llevar a un ecosistema vibrante donde muchos protocolos de nicho se integren en Enso más rápido de lo que cualquier equipo podría hacerlo, de manera similar a cómo la comunidad de The Graph indexa una larga cola de contratos. Si Enso tiene éxito, podría disfrutar de un fuerte foso de efecto de red: más Acciones y Atajos lo hacen más atractivo para usar Enso en comparación con los competidores, lo que atrae a más usuarios y, por lo tanto, más Acciones contribuidas, y así sucesivamente.

Dicho esto, Enso todavía está en sus primeras etapas. Su análogo más cercano, The Graph, tardó años en descentralizarse y construir un ecosistema de indexadores. Enso necesitará de manera similar nutrir a su comunidad de Graphers y Validadores para garantizar la fiabilidad. Grandes jugadores (como una versión futura de The Graph, o una colaboración de Chainlink y otros) podrían decidir lanzar una capa de ejecución de intenciones competidora, aprovechando sus redes existentes. Enso tendrá que moverse rápidamente para consolidar su posición antes de que tal competencia se materialice.

En conclusión, Enso se encuentra en una encrucijada competitiva de varias verticales importantes de Web3: está creando un nicho como el "middleware de todo". Su éxito dependerá de superar a los competidores especializados en cada caso de uso (o agregarlos) y de continuar ofreciendo una solución integral convincente que justifique que los desarrolladores elijan Enso en lugar de construir desde cero. La presencia de socios e inversores de alto perfil sugiere que Enso tiene un pie en la puerta de muchos ecosistemas, lo que será ventajoso a medida que expanda su cobertura de integración.

Hoja de Ruta y Crecimiento del Ecosistema

La hoja de ruta de desarrollo de Enso (a mediados de 2025) describe un camino claro hacia la descentralización total, el soporte multicadena y el crecimiento impulsado por la comunidad. Los hitos clave e iniciativas planificadas incluyen:

  • Lanzamiento de la Mainnet (T3 2024) – Enso lanzó su red principal en la segunda mitad de 2024. Esto implicó el despliegue de la cadena basada en Tendermint y la inicialización del ecosistema de Validadores. Los primeros validadores probablemente fueron permissionados o socios seleccionados mientras la red se iniciaba. El lanzamiento de la mainnet permitió que las consultas de usuarios reales fueran procesadas por el motor de Enso (antes de esto, los servicios de Enso eran accesibles a través de una API centralizada mientras estaban en beta). Este hito marcó la transición de Enso de una plataforma interna a una red pública descentralizada.

  • Expansión de Participantes de la Red (T4 2024) – Después de la mainnet, el enfoque se desplazó a la descentralización de la participación. A finales de 2024, Enso abrió roles para Proveedores de Acciones y Graphers externos. Esto incluyó el lanzamiento de herramientas y documentación para que los desarrolladores crearan sus propias Acciones (adaptadores de contratos inteligentes) y para que los desarrolladores de algoritmos ejecutaran nodos de Grapher. Podemos inferir que se utilizaron programas de incentivos o competiciones en testnet para atraer a estos participantes. Para finales de 2024, Enso aspiraba a tener un conjunto más amplio de acciones de terceros en su biblioteca y múltiples Graphers compitiendo en intenciones, yendo más allá de los algoritmos internos del equipo central. Este fue un paso crucial para asegurar que Enso no sea un servicio centralizado, sino una verdadera red abierta donde cualquiera puede contribuir y ganar tokens ENSO.

  • Expansión entre Cadenas (T1 2025) – Enso reconoce que soportar muchas blockchains es clave para su propuesta de valor. A principios de 2025, la hoja de ruta apuntaba a la integración con nuevos entornos de blockchain más allá del conjunto inicial de EVM. Específicamente, Enso planeaba dar soporte a Monad, Solana y Movement para el primer trimestre de 2025. Monad es una próxima cadena de alto rendimiento compatible con EVM (respaldada por Dragonfly Capital); apoyarla tempranamente podría posicionar a Enso como el middleware de referencia allí. La integración con Solana es más desafiante (diferente tiempo de ejecución y lenguaje), pero el motor de intenciones de Enso podría funcionar con Solana utilizando graphers fuera de la cadena para formular transacciones de Solana y programas en la cadena que actúen como adaptadores. Movement se refiere a cadenas de lenguaje Move (quizás Aptos/Sui o una específica llamada Movement). Al incorporar cadenas basadas en Move, Enso cubriría un amplio espectro de ecosistemas (Solidity y Move, así como los rollups existentes de Ethereum). Lograr estas integraciones significa desarrollar nuevos módulos de Acción que entiendan las llamadas CPI de Solana o los scripts de transacción de Move, y probablemente colaborar con esos ecosistemas para oráculos/indexación. La mención de Enso en actualizaciones sugiere que estos estaban en camino; por ejemplo, una actualización de la comunidad destacó asociaciones o subvenciones (la mención de "Eclipse mainnet live + Movement grant" en un resultado de búsqueda sugiere que Enso estaba trabajando activamente con L1s novedosas como Eclipse y Movement a principios de 2025).

  • A Corto Plazo (Mediados/Finales de 2025) – Aunque no se detalla explícitamente en la hoja de ruta de una página, para mediados de 2025 el enfoque de Enso está en la madurez y descentralización de la red. La finalización de la venta de tokens en CoinList en junio de 2025 es un evento importante: los siguientes pasos serían la generación y distribución de tokens (esperada alrededor de julio de 2025) y el lanzamiento en exchanges o foros de gobernanza. Anticipamos que Enso implementará su proceso de gobernanza (Propuestas de Mejora de Enso, votación en la cadena) para que la comunidad pueda comenzar a participar en las decisiones utilizando sus tokens recién adquiridos. Además, Enso probablemente pasará de "beta" a un servicio totalmente listo para producción, si no lo ha hecho ya. Parte de esto será el endurecimiento de la seguridad: realizar múltiples auditorías de contratos inteligentes y quizás ejecutar un programa de recompensas por errores, considerando los grandes TVL involucrados.

  • Estrategias de Crecimiento del Ecosistema: Enso está fomentando activamente un ecosistema alrededor de su red. Una estrategia ha sido ejecutar programas educativos y hackatones (por ejemplo, el Shortcut Speedrun y talleres) para incorporar a los desarrolladores a la forma de construir de Enso. Otra estrategia es asociarse con nuevos protocolos en su lanzamiento; lo hemos visto con Berachain, la campaña de zkSync y otros. Es probable que Enso continúe con esto, actuando efectivamente como un "socio de lanzamiento en la cadena" para redes emergentes o proyectos DeFi, manejando sus complejos flujos de onboarding de usuarios. Esto no solo impulsa el volumen de Enso (como se vio con Berachain) sino que también integra a Enso profundamente en esos ecosistemas. Esperamos que Enso anuncie integraciones con más redes de Capa 2 (por ejemplo, Arbitrum, Optimism presumiblemente ya eran compatibles; quizás las más nuevas como Scroll o Starknet a continuación) y otras L1 (Polkadot a través de XCM, Cosmos a través de IBC u Osmosis, etc.). La visión a largo plazo es que Enso se vuelva ubicuo en todas las cadenas: cualquier desarrollador en cualquier cadena puede conectarse. Con ese fin, Enso también puede desarrollar una mejor ejecución entre cadenas sin puentes (utilizando técnicas como swaps atómicos o ejecución optimista de intenciones entre cadenas), lo que podría estar en la hoja de ruta de I+D más allá de 2025.

  • Perspectivas Futuras: Mirando más allá, el equipo de Enso ha insinuado la participación de agentes de IA como participantes de la red. Esto sugiere un futuro donde no solo los desarrolladores humanos, sino también los bots de IA (quizás entrenados para optimizar estrategias de DeFi) se conecten a Enso para proporcionar servicios. Enso podría desarrollar esta visión creando SDKs o marcos para que los agentes de IA interactúen de manera segura con el motor de intenciones, un desarrollo potencialmente innovador que fusiona la IA y la automatización de blockchain. Además, para finales de 2025 o 2026, anticipamos que Enso trabajará en la escalabilidad del rendimiento (quizás fragmentando su red o utilizando pruebas de conocimiento cero para validar la corrección de la ejecución de intenciones a escala) a medida que crezca el uso.

La hoja de ruta es ambiciosa, pero la ejecución hasta ahora ha sido sólida: Enso ha cumplido hitos clave como el lanzamiento de la mainnet y la entrega de casos de uso reales. Un hito importante próximo es la descentralización total de la red. Actualmente, la red está en transición: la documentación señala que la red descentralizada está en testnet y que se estaba utilizando una API centralizada para producción a principios de 2025. A estas alturas, con la mainnet en vivo y el token en circulación, Enso buscará eliminar gradualmente cualquier componente centralizado. Para los inversores, seguir este progreso de descentralización (por ejemplo, el número de validadores independientes, la incorporación de Graphers comunitarios) será clave para evaluar la madurez de Enso.

En resumen, la hoja de ruta de Enso se centra en escalar el alcance de la red (más cadenas, más integraciones) y escalar la comunidad de la red (más participantes de terceros y poseedores de tokens). El objetivo final es consolidar a Enso como infraestructura crítica en Web3, de manera muy similar a cómo Infura se volvió esencial para la conectividad de dApps o cómo The Graph se volvió integral para la consulta de datos. Si Enso puede alcanzar sus hitos, la segunda mitad de 2025 debería ver un ecosistema floreciente alrededor de la Red Enso, impulsando potencialmente un crecimiento exponencial en el uso.

Evaluación de Riesgos

Como cualquier protocolo en etapa inicial, Enso Network enfrenta una serie de riesgos y desafíos que los inversores deben considerar cuidadosamente:

  • Riesgos Técnicos y de Seguridad: El sistema de Enso es inherentemente complejo: interactúa con una miríada de contratos inteligentes en muchas blockchains a través de una red de solucionadores y validadores fuera de la cadena. Esta amplia superficie de ataque introduce un riesgo técnico. Cada nueva Acción (integración) podría tener vulnerabilidades; si la lógica de una Acción es defectuosa o un proveedor malicioso introduce una Acción con una puerta trasera, los fondos de los usuarios podrían estar en riesgo. Asegurar que cada integración sea segura requiere una inversión sustancial (el equipo de Enso gastó más de $500k en auditorías para integrar 15 protocolos en sus primeros días). A medida que la biblioteca crece a cientos de protocolos, mantener auditorías de seguridad rigurosas es un desafío. También existe el riesgo de errores en la lógica de coordinación de Enso; por ejemplo, un fallo en cómo los Graphers componen las transacciones o cómo los Validadores las verifican podría ser explotado. La ejecución entre cadenas, en particular, puede ser arriesgada: si una secuencia de acciones abarca múltiples cadenas y una parte falla o es censurada, podría dejar los fondos de un usuario en el limbo. Aunque Enso probablemente utiliza reintentos o swaps atómicos en algunos casos, la complejidad de las intenciones significa que podrían surgir modos de fallo desconocidos. El modelo basado en intenciones en sí mismo es relativamente poco probado a escala; puede haber casos límite en los que el motor produzca una solución incorrecta o un resultado que diverja de la intención del usuario. Cualquier explotación o fallo de alto perfil podría socavar la confianza en toda la red. La mitigación requiere auditorías de seguridad continuas, un programa robusto de recompensas por errores y quizás mecanismos de seguro para los usuarios (ninguno de los cuales se ha detallado todavía).

  • Riesgos de Descentralización y Operacionales: En la actualidad (mediados de 2025), la red de Enso todavía está en proceso de descentralizar a sus participantes. Esto significa que puede haber una centralización operacional no visible; por ejemplo, la infraestructura del equipo podría estar coordinando todavía gran parte de la actividad, o solo unos pocos validadores/graphers están genuinamente activos. Esto presenta dos riesgos: fiabilidad (si los servidores del equipo central caen, ¿se detendrá la red?) y confianza (si el proceso no es completamente sin confianza todavía, los usuarios deben tener fe en que Enso Inc. no hará front-running ni censurará transacciones). El equipo ha demostrado fiabilidad en grandes eventos (como manejar un volumen de $3B en días), pero a medida que el uso crece, escalar la red a través de más nodos independientes será crucial. También existe el riesgo de que los participantes de la red no aparezcan: si Enso no puede atraer suficientes Proveedores de Acciones o Graphers cualificados, la red podría seguir dependiendo del equipo central, limitando la descentralización. Esto podría ralentizar la innovación y también concentrar demasiado poder (y recompensas de tokens) en un grupo pequeño, lo contrario del diseño previsto.

  • Riesgos de Mercado y Adopción: Aunque Enso tiene una adopción temprana impresionante, todavía se encuentra en un mercado naciente para la infraestructura "basada en intenciones". Existe el riesgo de que la comunidad de desarrolladores en general sea lenta en adoptar este nuevo paradigma. Los desarrolladores arraigados en prácticas de codificación tradicionales pueden dudar en depender de una red externa para la funcionalidad principal, o pueden preferir soluciones alternativas. Además, el éxito de Enso depende del crecimiento continuo de los ecosistemas DeFi y multicadena. Si la tesis multicadena flaquea (por ejemplo, si la mayor parte de la actividad se consolida en una única cadena dominante), la necesidad de las capacidades entre cadenas de Enso podría disminuir. Por otro lado, si surge un nuevo ecosistema que Enso no logra integrar rápidamente, los proyectos en ese ecosistema no usarán Enso. Esencialmente, mantenerse actualizado con cada nueva cadena y protocolo es un desafío interminable: perder o retrasarse en una integración importante (digamos un nuevo DEX popular o una Capa 2) podría empujar a los proyectos hacia competidores o código personalizado. Además, el uso de Enso podría verse afectado por las condiciones macroeconómicas del mercado; en una grave recesión de DeFi, menos usuarios y desarrolladores podrían estar experimentando con nuevas dApps, reduciendo directamente las intenciones enviadas a Enso y, por lo tanto, las tarifas/ingresos de la red. El valor del token podría sufrir en tal escenario, haciendo potencialmente menos atractivo el staking y debilitando la seguridad o participación de la red.

  • Competencia: Como se discutió, Enso enfrenta competencia en múltiples frentes. Un riesgo importante es que un jugador más grande entre en el espacio de ejecución de intenciones. Por ejemplo, si un proyecto bien financiado como Chainlink introdujera un servicio de intenciones similar aprovechando su red de oráculos existente, podrían eclipsar rápidamente a Enso debido a la confianza de la marca y las integraciones. De manera similar, las empresas de infraestructura (Alchemy, Infura) podrían construir SDKs multicadena simplificados que, aunque no descentralizados, capturen el mercado de desarrolladores con conveniencia. También existe el riesgo de imitadores de código abierto: los conceptos centrales de Enso (Acciones, Graphers) podrían ser replicados por otros, quizás incluso como una bifurcación de Enso si el código es público. Si uno de esos proyectos forma una comunidad fuerte o encuentra un mejor incentivo de token, podría desviar a participantes potenciales. Enso necesitará mantener el liderazgo tecnológico (por ejemplo, teniendo la biblioteca más grande de Acciones y los solucionadores más eficientes) para defenderse de la competencia. La presión competitiva también podría afectar el modelo de tarifas de Enso: si un rival ofrece servicios similares más baratos (o gratis, subsidiados por VCs), Enso podría verse obligado a bajar las tarifas o aumentar los incentivos de tokens, lo que podría afectar su tokenomics.

  • Riesgos Regulatorios y de Cumplimiento: Enso opera en el espacio de la infraestructura DeFi, que es un área gris en términos de regulación. Aunque Enso en sí no custodia los fondos de los usuarios (los usuarios ejecutan intenciones desde sus propias billeteras), la red automatiza transacciones financieras complejas a través de protocolos. Existe la posibilidad de que los reguladores puedan ver los motores de composición de intenciones como facilitadores de actividad financiera sin licencia o incluso como ayuda al lavado de dinero si se utilizan para mover fondos entre cadenas de manera oculta. Podrían surgir preocupaciones específicas si Enso permite intercambios entre cadenas que tocan pools de privacidad o jurisdicciones bajo sanciones. Además, el token ENSO y su venta en CoinList reflejan una distribución a una comunidad global; los reguladores (como la SEC en los EE. UU.) podrían examinarlo como una oferta de valores (notablemente, Enso excluyó a EE. UU., Reino Unido, China, etc., de la venta, lo que indica cautela en este frente). Si ENSO fuera considerado un valor en jurisdicciones importantes, podría limitar las cotizaciones en exchanges o el uso por parte de entidades reguladas. La red descentralizada de validadores de Enso también podría enfrentar problemas de cumplimiento: por ejemplo, ¿podría un validador ser obligado a censurar ciertas transacciones debido a órdenes legales? Esto es en gran medida hipotético por ahora, pero a medida que crezca el valor que fluye a través de Enso, la atención regulatoria aumentará. La base del equipo en Suiza podría ofrecer un entorno regulatorio relativamente amigable con las criptomonedas, pero las operaciones globales significan riesgos globales. Mitigar esto probablemente implica asegurar que Enso esté suficientemente descentralizado (para que ninguna entidad sea responsable) y posiblemente geocercar ciertas características si es necesario (aunque eso iría en contra del espíritu del proyecto).

  • Sostenibilidad Económica: El modelo de Enso asume que las tarifas generadas por el uso recompensarán suficientemente a todos los participantes. Existe el riesgo de que los incentivos de las tarifas no sean suficientes para sostener la red, especialmente al principio. Por ejemplo, los Graphers y Validadores incurren en costos (infraestructura, tiempo de desarrollo). Si las tarifas de consulta se establecen demasiado bajas, estos participantes podrían no obtener ganancias, lo que los llevaría a abandonar. Por otro lado, si las tarifas son demasiado altas, las dApps pueden dudar en usar Enso y buscar alternativas más baratas. Lograr un equilibrio es difícil en un mercado de dos lados. La economía del token de Enso también depende en cierta medida del valor del token; por ejemplo, las recompensas por staking son más atractivas cuando el token tiene un alto valor, y los Proveedores de Acciones ganan valor en ENSO. Una fuerte caída en el precio de ENSO podría reducir la participación en la red o provocar más ventas (lo que deprime aún más el precio). Con una gran parte de los tokens en manos de inversores y el equipo (más del 56% combinado, con un vesting de 2 años), existe un riesgo de exceso de oferta: si estos interesados pierden la fe o necesitan liquidez, su venta podría inundar el mercado después del vesting y socavar el precio del token. Enso intentó mitigar la concentración con la venta comunitaria, pero sigue siendo una distribución de tokens relativamente centralizada a corto plazo. La sostenibilidad económica dependerá del crecimiento del uso genuino de la red a un nivel en el que los ingresos por tarifas proporcionen un rendimiento suficiente a los stakers y contribuyentes del token, convirtiendo esencialmente a Enso en un protocolo generador de flujo de caja en lugar de solo un token especulativo. Esto es alcanzable (piense en cómo las tarifas de Ethereum recompensan a los mineros/validadores), pero solo si Enso logra una adopción generalizada. Hasta entonces, existe una dependencia de los fondos de la tesorería (15% asignado) para incentivar y quizás para ajustar los parámetros económicos (la gobernanza de Enso puede introducir inflación u otras recompensas si es necesario, lo que podría diluir a los poseedores).

Resumen de Riesgos: Enso está abriendo nuevos caminos, lo que conlleva un riesgo proporcional. La complejidad tecnológica de unificar todo DeFi en una sola red es enorme: cada blockchain añadida o protocolo integrado es un punto potencial de fallo que debe ser gestionado. La experiencia del equipo navegando contratiempos anteriores (como el éxito limitado del producto inicial de trading social) muestra que son conscientes de los peligros y se adaptan rápidamente. Han mitigado activamente algunos riesgos (por ejemplo, descentralizando la propiedad a través de la ronda comunitaria para evitar una gobernanza excesivamente impulsada por VCs). Los inversores deben observar cómo Enso ejecuta la descentralización y si continúa atrayendo talento técnico de primer nivel para construir y asegurar la red. En el mejor de los casos, Enso podría convertirse en una infraestructura indispensable en todo Web3, generando fuertes efectos de red y acumulación de valor del token. En el peor de los casos, los contratiempos técnicos o de adopción podrían relegarlo a ser una herramienta ambiciosa pero de nicho.

Desde la perspectiva de un inversor, Enso ofrece un perfil de alto potencial, alto riesgo. Su estado actual (mediados de 2025) es el de una red prometedora con uso real y una visión clara, pero ahora debe endurecer su tecnología y superar un panorama competitivo y en evolución. La debida diligencia sobre Enso debe incluir el monitoreo de su historial de seguridad, el crecimiento de los volúmenes/tarifas de consulta a lo largo del tiempo y cuán efectivamente el modelo del token ENSO incentiva un ecosistema autosostenible. Por ahora, el impulso está a favor de Enso, pero una gestión de riesgos prudente y una innovación continua serán clave para convertir este liderazgo temprano en un dominio a largo plazo en el espacio del middleware de Web3.

Fuentes:

  • Documentación Oficial de Enso Network y Materiales de la Venta de Tokens

    • Página de Venta de Tokens de CoinList – Puntos Clave e Inversores
    • Documentos de Enso – Tokenomics y Roles de la Red
  • Entrevistas y Cobertura Mediática

    • Entrevista de CryptoPotato con el CEO de Enso (junio de 2025) – Antecedentes sobre la evolución de Enso y el diseño basado en intenciones
    • DL News (mayo de 2025) – Resumen de los atajos de Enso y el enfoque de estado compartido
  • Análisis de la Comunidad e Inversores

    • Hackernoon (I. Pandey, 2025) – Perspectivas sobre la ronda comunitaria de Enso y la estrategia de distribución de tokens
    • CryptoTotem / CoinLaunch (2025) – Desglose del suministro de tokens y cronograma de la hoja de ruta
  • Métricas del Sitio Oficial de Enso (2025) y Comunicados de Prensa – Cifras de adopción y ejemplos de casos de uso (migración de Berachain, colaboración con Uniswap).

Aptos vs. Sui: Un Análisis Panorámico de Dos Gigantes Basados en Move

· 8 min de lectura
Dora Noda
Software Engineer

Visión General

Aptos y Sui se presentan como la próxima generación de blockchains de capa 1, ambas originadas a partir del lenguaje Move concebido inicialmente por el proyecto Libra/Diem de Meta. Aunque comparten una línea genealógica común, sus antecedentes de equipo, objetivos centrales, estrategias de ecosistema y trayectorias evolutivas han divergido de manera significativa.

Aptos enfatiza la versatilidad y el rendimiento de nivel empresarial, apuntando tanto a casos de uso DeFi como institucionales. En contraste, Sui está centrado en optimizar su modelo de objetos único para impulsar aplicaciones de consumo masivo, particularmente en juegos, NFT y redes sociales. Qué cadena se distinguirá finalmente dependerá de su capacidad para evolucionar su tecnología y satisfacer las demandas de su nicho de mercado elegido, al tiempo que establece una ventaja clara en experiencia de usuario y facilidad para desarrolladores.


1. Trayectoria de Desarrollo

Aptos

Nacida de Aptos Labs — un equipo formado por ex‑empleados de Meta Libra/Diem — Aptos inició pruebas cerradas a finales de 2021 y lanzó su mainnet el 19 de octubre de 2022. El rendimiento temprano del mainnet generó escepticismo en la comunidad con menos de 20 TPS, según WIRED, pero iteraciones posteriores en sus capas de consenso y ejecución han impulsado su rendimiento a decenas de miles de TPS.

Para el segundo trimestre de 2025, Aptos alcanzó un pico de 44,7 millones de transacciones en una sola semana, con direcciones activas semanales que superaron los 4 millones. La red ha crecido a más de 83 millones de cuentas acumuladas, con un volumen diario de trading DeFi que supera consistentemente los 200 millones de dólares (Fuente: Aptos Forum).

Sui

Iniciada por Mysten Labs, cuyos fundadores fueron miembros clave del equipo de la billetera Novi de Meta, Sui lanzó su testnet incentivado en agosto de 2022 y puso en marcha su mainnet el 3 de mayo de 2023. Desde los primeros testnets, el equipo priorizó el perfeccionamiento de su “modelo de objetos”, que trata los activos como objetos con propiedad y controles de acceso específicos para mejorar el procesamiento paralelo de transacciones (Fuente: Ledger).

A mediados de julio de 2025, el Valor Total Bloqueado (TVL) del ecosistema de Sui alcanzó los 2,326 mil millones de dólares. La plataforma ha experimentado un rápido crecimiento en el volumen mensual de transacciones y en el número de ingenieros activos, resultando especialmente popular en los sectores de juegos y NFT (Fuente: AInvest, Tangem).


2. Comparación de Arquitectura Técnica

CaracterísticaAptosSui
LenguajeHereda el diseño original de Move, enfatizando la seguridad de los “recursos” y el control de acceso estricto. El lenguaje es relativamente simplificado. (Fuente: aptos.dev)Extiende Move estándar con un modelo “centrado en objetos”, creando una versión personalizada del lenguaje que soporta transacciones paralelas escalables horizontalmente. (Fuente: docs.sui.io)
ConsensoAptosBFT: Un mecanismo de consenso BFT optimizado que promete finalización en menos de un segundo, con foco principal en seguridad y consistencia. (Fuente: Messari)Narwhal + Tusk: Desacopla el consenso del ordenamiento de transacciones, permitiendo alto rendimiento y baja latencia al priorizar la eficiencia de ejecución paralela.
Modelo de EjecuciónEmplea un modelo de ejecución en pipeline donde las transacciones se procesan en etapas (obtención de datos, ejecución, escritura), soportando transferencias de alta frecuencia y lógica compleja. (Fuente: chorus.one)Utiliza ejecución paralela basada en la propiedad de objetos. Las transacciones que involucran objetos distintos no requieren bloqueos de estado global, lo que incrementa fundamentalmente el rendimiento.
EscalabilidadSe centra en la optimización de una sola instancia mientras investiga sharding. La comunidad está desarrollando activamente la propuesta de sharding AptosCore v2.0.Presenta un motor paralelo nativo diseñado para escalado horizontal, habiendo alcanzado ya picos de TPS en decenas de miles en su testnet.
Herramientas para DesarrolladoresUna cadena de herramientas madura que incluye SDK oficiales, un Devnet, el CLI de Aptos, un Explorer y el framework Hydra para escalabilidad.Un conjunto integral que incluye el SDK de Sui, el IDE Sui Studio, un Explorer, APIs GraphQL y un modelo de consultas orientado a objetos.

3. Ecosistema On‑Chain y Casos de Uso

3.1 Escala y Crecimiento del Ecosistema

Aptos En el primer trimestre de 2025, Aptos registró casi 15 millones de usuarios activos mensuales y se acercó a 1 millón de billeteras activas diarias. Su volumen de trading DeFi se disparó un 1000 % interanual, consolidándose como un hub para stablecoins y derivados de grado financiero (Fuente: Coinspeaker). Movimientos estratégicos clave incluyen la integración de USDT a través de Upbit para impulsar la penetración en mercados asiáticos y la atracción de numerosos DEX, protocolos de préstamo y plataformas de derivados (Fuente: Aptos Forum).

Sui En junio de 2025, el TVL del ecosistema de Sui alcanzó un nuevo máximo de 2,326 mil millones de dólares, impulsado principalmente por proyectos sociales, de juegos y NFT de alta interacción (Fuente: AInvest). El ecosistema se define por proyectos centrales como mercados de objetos, puentes Layer‑2, billeteras sociales y SDKs de motores de juego, que han atraído a un gran número de desarrolladores de juegos Web3 y titulares de IP.

3.2 Casos de Uso Dominantes

  • DeFi e Integración Empresarial (Aptos): Con su finalización BFT madura y una suite rica de herramientas financieras, Aptos se adapta mejor a stablecoins, préstamos y derivados — escenarios que demandan altos niveles de consistencia y seguridad.
  • Juegos y NFT (Sui): La ventaja de ejecución paralela de Sui es clara aquí. Su baja latencia de transacción y tarifas casi nulas son ideales para interacciones de alta concurrencia y bajo valor típicas en juegos, como abrir cajas de botín o transferir ítems dentro del juego.

4. Evolución y Estrategia

Aptos

  • Optimización de Rendimiento: Continuar avanzando en la investigación de sharding, planear liquidez cross‑chain multirregional y actualizar AptosVM para mejorar la eficiencia de acceso al estado.
  • Incentivos al Ecosistema: Se ha creado un fondo de ecosistema de varios cientos de millones de dólares para apoyar infraestructura DeFi, puentes cross‑chain y aplicaciones empresariales compatibles.
  • Interoperabilidad Cross‑Chain: Fortalecer integraciones con puentes como Wormhole y construir conexiones con Cosmos (a través de IBC) y Ethereum.

Sui

  • Iteración del Modelo de Objetos: Extender la sintaxis de Move para soportar tipos de objetos personalizados y gestión de permisos compleja, al tiempo que se optimiza el algoritmo de programación paralela.
  • Impulso a la Adopción del Consumidor: Buscar integraciones profundas con motores de juego principales como Unreal y Unity para reducir la barrera de desarrollo de juegos Web3, y lanzar plugins sociales y SDKs.
  • Gobernanza Comunitaria: Promover SuiDAO para empoderar a las comunidades del proyecto con capacidades de gobernanza, permitiendo iteraciones rápidas en características y modelos de tarifas.

5. Diferencias Clave y Desafíos

  • Seguridad vs. Paralelismo: La semántica estricta de recursos y el consenso consistente de Aptos brindan seguridad de nivel DeFi pero pueden limitar el paralelismo. El modelo de transacciones altamente paralelo de Sui debe demostrar continuamente su resiliencia frente a amenazas de seguridad a gran escala.
  • Profundidad vs. Amplitud del Ecosistema: Aptos ha cultivado raíces profundas en el sector financiero con fuertes lazos institucionales. Sui ha acumulado rápidamente una amplia gama de proyectos orientados al consumidor, pero aún no ha logrado un gran avance en DeFi a gran escala.
  • Rendimiento Teórico vs. Rendimiento Real: Aunque Sui posee un TPS teórico más alto, su rendimiento real sigue estando limitado por la actividad del ecosistema. Aptos también ha experimentado congestión en períodos pico, indicando la necesidad de sharding más efectivo o soluciones Layer‑2.
  • Narrativa de Mercado y Posicionamiento: Aptos se promociona como seguro y estable de grado empresarial, apuntando a finanzas tradicionales e industrias reguladas. Sui utiliza el atractivo de una “experiencia tipo Web2” y “onboarding sin fricción” para atraer a una audiencia de consumidores más amplia.

6. Camino hacia la Adopción Masiva

En última instancia, no se trata de un juego de suma cero.

A medio y largo plazo, si el mercado de consumo (juegos, redes sociales, NFT) continúa su crecimiento explosivo, la ejecución paralela de Sui y su baja barrera de entrada podrían posicionarla para una adopción rápida entre decenas de millones de usuarios mainstream.

A corto y medio plazo, la finalización BFT madura de Aptos, sus bajas tarifas y sus alianzas estratégicas le otorgan una propuesta más atractiva para finanzas institucionales, DeFi enfocado en cumplimiento y pagos transfronterizos.

Lo más probable es que el futuro sea simbiótico, con ambas cadenas coexistiendo y creando un mercado estratificado: Aptos impulsando la infraestructura financiera y empresarial, mientras Sui domina las interacciones de alta frecuencia orientadas al consumidor. La cadena que finalmente logre la adopción masiva será la que optimice incansablemente el rendimiento y la experiencia de usuario dentro de su dominio elegido.

Rollups como Servicio en 2025: OP, ZK, Arbitrum Orbit, Polygon CDK e Hyperchains de zkSync

· 83 min de lectura
Dora Noda
Software Engineer

Introducción

Los Rollups como Servicio (RaaS) y los frameworks de blockchain modulares se han vuelto críticos en 2025 para escalar Ethereum y construir blockchains personalizadas. Los frameworks líderes – OP Stack de Optimism, ZK Stack de zkSync (Hyperchains), Arbitrum Orbit, Chain Development Kit (CDK) de Polygon y soluciones relacionadas – permiten a los desarrolladores lanzar sus propias cadenas de Capa 2 (L2) o Capa 3 (L3) con diferentes enfoques (optimista vs. de conocimiento cero). Estos frameworks comparten una filosofía de modularidad: separan responsabilidades como la ejecución, la liquidación, la disponibilidad de datos y el consenso, permitiendo la personalización de cada componente. Este informe compara los frameworks en dimensiones clave – opciones de disponibilidad de datos, diseño del secuenciador, modelos de tarifas, soporte del ecosistema – y examina su arquitectura, herramientas, experiencia del desarrollador y adopción actual tanto en contextos públicos como empresariales.

Resumen Comparativo

La siguiente tabla resume varias características principales de cada framework:

AspectoOP Stack (Optimism)ZK Stack (zkSync)Arbitrum OrbitPolygon CDK (AggLayer)
Tipo de RollupRollup OptimistaConocimiento Cero (Validez)Rollup OptimistaConocimiento Cero (Validez)
Sistema de PruebaPruebas de fallo (pruebas de fraude)Pruebas de validez ZK-SNARKPruebas de fallo (pruebas de fraude)Pruebas de validez ZK-SNARK
Compatibilidad con EVMEquivalente a EVM (geth)Alta – zkEVM (basado en LLVM)Equivalente a EVM (Arbitrum Nitro) + WASM a través de StylusPolygon zkEVM (Equivalente a EVM)
Disponibilidad de DatosEthereum L1 (en la cadena); módulos Alt-DA conectables (Celestia, etc.)Ethereum L1; también opciones de Validium fuera de la cadena (Celestia, Avail, EigenDA)Ethereum L1 (rollup) o comité AnyTrust (DAC fuera de la cadena); soporta Celestia, AvailEthereum L1 (rollup) o fuera de la cadena (validium a través de Avail o Celestia); híbrido posible
Diseño del SecuenciadorSecuenciador único (por defecto); multi-secuenciador posible con personalización. Visión de secuenciador compartido para Superchain (futuro).Configurable: puede ser centralizado o descentralizado; soporta cola de prioridad L1.Configurable: operador único o validadores descentralizados.Flexible: secuenciador único o múltiples validadores (ej. comité PoS).
Acceso al SecuenciadorCentralizado hoy (el secuenciador de cada cadena OP es operado por su operador); aún no es sin permisos. Planes para una red de secuenciadores compartida y sin permisos entre las Cadenas OP. La cola de respaldo L1 permite el envío de transacciones sin confianza si el secuenciador falla.zkSync Era utiliza un secuenciador centralizado (Matter Labs), pero ZK Stack permite una lógica de secuenciador personalizada (incluso consenso externo). Secuenciación prioritaria L1 soportada para equidad. Opciones de secuenciador descentralizado en desarrollo.Arbitrum One utiliza un secuenciador centralizado (Offchain Labs), con conmutación por error a través del buzón de L1. Las cadenas de Arbitrum Orbit pueden ejecutar su propio secuenciador (inicialmente centralizado) o instituir un conjunto de validadores. La actualización BoLD (2025) permite la validación sin permisos para descentralizar las cadenas Orbit.Polygon zkEVM comenzó con un secuenciador único (Polygon Labs). CDK permite lanzar una cadena con un conjunto de validadores con permisos u otro consenso para la descentralización. Muchas cadenas CDK comienzan centralizadas por simplicidad, con una hoja de ruta para secuenciadores gestionados por la comunidad más adelante.
Token de TarifaETH por defecto en L2s basadas en OP (para facilitar la UX). El token de gas personalizado es técnicamente soportado, pero la mayoría de las Cadenas OP optan por ETH o un token estándar para la interoperabilidad. (La guía reciente de OP Stack favorece tokens comunes en toda la Superchain).Se soportan tokens base personalizados – los desarrolladores pueden elegir ETH o cualquier ERC-20 como el gas nativo. (Esta flexibilidad permite economías específicas de proyecto en cadenas basadas en zkSync).Se soporta token de gas personalizado (actualización a finales de 2023). Las cadenas pueden usar ETH, el ARB de Arbitrum, o su propio token para las tarifas. Ejemplo: Ape Chain usa APE como gas.Se soporta token nativo personalizado. Muchas cadenas de Polygon CDK usan MATIC u otro token como gas. El ecosistema de Polygon fomenta el uso de MATIC para la consistencia entre cadenas, pero no es obligatorio.
Modelo de Tarifas y CostosLos usuarios pagan gas L2 (recolectado por el secuenciador) más los costos de publicación de datos en L1. El secuenciador debe publicar los datos de la transacción (calldata o blobs) en Ethereum, por lo que una parte de las tarifas cubre el gas de L1. Reparto de ingresos: Las Cadenas OP en la Superchain comprometen ~2.5% de los ingresos al Colectivo Optimism (financiando bienes públicos).Los usuarios pagan tarifas (a menudo en ETH o el token elegido) que cubren la verificación de pruebas y los datos en L1. No hay "impuesto" a nivel de protocolo sobre las tarifas – el secuenciador de cada cadena se queda con los ingresos para incentivar a los operadores. Los costos del probador ZK son un factor: los operadores pueden cobrar tarifas ligeramente más altas o usar probadores eficientes para gestionar los costos. La finalidad es rápida (sin demora), por lo que los usuarios no necesitan salidas rápidas de terceros.Los usuarios pagan gas (en ETH o el token de la cadena) que cubre la ejecución en L2 + el costo del lote en L1. Los secuenciadores/validadores retienen los ingresos por tarifas; no hay reparto de ingresos obligatorio a la DAO de Arbitrum o a L1 (aparte de los costos de gas de L1). Para evitar la demora optimista de 7 días, muchas cadenas Orbit integran proveedores de liquidez o puentes oficiales de retiro rápido (Arbitrum soporta salidas rápidas de 15 minutos en algunas cadenas Orbit a través de redes de liquidez).Los usuarios pagan tarifas de gas que cubren los costos de prueba y publicación. Los secuenciadores o validadores ganan esas tarifas; Polygon no impone ninguna renta o impuesto sobre los ingresos de la cadena CDK. Usar DA fuera de la cadena (modo validium) puede reducir las tarifas en >100× (almacenando datos en Celestia o Avail en lugar de Ethereum), a costa de algunas suposiciones de confianza.

Tabla: Comparación de alto nivel de las características técnicas clave de OP Stack, ZK Stack de zkSync, Arbitrum Orbit y Polygon CDK.

Capas de Disponibilidad de Datos

La Disponibilidad de Datos (DA) es donde los rollups almacenan los datos de sus transacciones para que cualquiera pueda reconstruir el estado de la cadena. Todos estos frameworks soportan el uso de Ethereum L1 como DA (publicando calldata o datos de blob en Ethereum para máxima seguridad). Sin embargo, para reducir costos, también permiten soluciones de DA alternativas:

  • OP Stack: Por defecto, las cadenas OP publican datos en Ethereum (como calldata o blobs). Gracias a una interfaz modular "Alt-DA", las cadenas de OP Stack pueden conectarse fácilmente a otras capas de DA. Por ejemplo, una cadena OP podría usar Celestia (una blockchain dedicada a DA) en lugar de Ethereum. En 2023, OP Labs y Celestia lanzaron una beta donde un rollup de OP Stack se liquida en Ethereum pero almacena datos masivos en Celestia. Esto reduce las tarifas mientras hereda las garantías de disponibilidad de datos de Celestia. En general, cualquier cadena EVM o no EVM – incluso Bitcoin o un almacenamiento centralizado – puede configurarse como la capa de DA en OP Stack. (Por supuesto, usar una DA menos segura sacrifica algo de seguridad por costo). Ethereum sigue siendo la opción predominante para las cadenas OP en producción, pero proyectos como la testnet Taro de Caldera han demostrado OP Stack con Celestia DA.

  • ZK Stack (Hyperchains de zkSync): El ZK Stack ofrece modos tanto de rollup como de validium. En modo rollup, todos los datos están en la cadena (Ethereum). En modo validium, los datos se mantienen fuera de la cadena (con solo pruebas de validez en la cadena). Matter Labs está integrando Avail, Celestia y EigenDA como opciones de DA de primera clase para las cadenas de ZK Stack. Esto significa que una Hyperchain de zkSync podría publicar datos de transacciones en Celestia o en una red impulsada por EigenLayer en lugar de L1, aumentando masivamente el rendimiento. Incluso describen la volition, donde una cadena puede decidir por transacción si tratarla como un rollup (datos en la cadena) o validium (fuera de la cadena). Esta flexibilidad permite a los desarrolladores equilibrar seguridad y costo. Por ejemplo, una hyperchain de juegos podría usar Celestia para almacenar datos de forma económica, mientras confía en Ethereum para pruebas periódicas. El diseño de ZK Stack hace que la DA sea conectable a través de un componente cliente/despachador de DA en el software del nodo. En general, Ethereum sigue siendo el predeterminado, pero el ecosistema de zkSync enfatiza fuertemente la DA modular para lograr un rendimiento a "hiperescala".

  • Arbitrum Orbit: Las cadenas Orbit pueden elegir entre los dos modos de datos de Arbitrum: rollup (datos publicados en Ethereum) o AnyTrust (comité de disponibilidad de datos). En la configuración de Rollup, una L3 de Orbit publicará su calldata en la L2 (Arbitrum One o Nova) o en la L1, heredando seguridad completa a un costo mayor. En el modo AnyTrust, los datos son mantenidos fuera de la cadena por un comité (como se usa en Arbitrum Nova, que utiliza un Comité de Disponibilidad de Datos). Esto reduce enormemente las tarifas para aplicaciones de alto volumen (juegos, redes sociales) a costa de confiar en un comité (si todos los miembros del comité se confabulan para retener datos, la cadena podría detenerse). Además de estos, Arbitrum también se está integrando con redes de DA modulares emergentes. Notablemente, Celestia y Polygon Avail son soportados para cadenas Orbit como capas de DA alternativas. Proyectos como AltLayer han trabajado en rollups de Orbit que usan EigenDA (el servicio de DA de EigenLayer) también. En resumen, Arbitrum Orbit ofrece disponibilidad de datos flexible: en la cadena a través de Ethereum, fuera de la cadena a través de DACs o cadenas de DA especializadas, o híbridos. Muchos adoptantes de Orbit eligen AnyTrust por ahorro de costos, especialmente si tienen un conjunto conocido de validadores o socios que aseguran la disponibilidad de los datos.

  • Polygon CDK: El CDK de Polygon es inherentemente modular con respecto a la DA. Una cadena de Polygon CDK puede operar como un rollup (todos los datos en Ethereum) o un validium (datos en una red separada). Polygon tiene su propia solución de DA llamada Avail (una blockchain para disponibilidad de datos), y las cadenas CDK pueden usar Avail o cualquier servicio similar. A finales de 2024, Polygon anunció la integración directa de Celestia en CDK – haciendo de Celestia una opción de DA "fácilmente conectable" en el kit de herramientas. Se espera esta integración a principios de 2024, permitiendo a las cadenas CDK almacenar datos comprimidos en Celestia sin problemas. Polygon cita que usar Celestia podría reducir las tarifas de transacción en >100× en comparación con publicar todos los datos en Ethereum. Por lo tanto, un creador de cadenas CDK puede simplemente cambiar el módulo de DA a Celestia (o Avail) en lugar de Ethereum. Algunas cadenas de Polygon (ej. Polygon zkEVM) actualmente publican todos los datos en Ethereum (para máxima seguridad), mientras que otras (quizás ciertas cadenas empresariales) funcionan como validiums con DA externa. El CDK soporta también modos "híbridos" – por ejemplo, las transacciones críticas podrían ir a Ethereum mientras que otras van a Avail. Este enfoque de DA modular se alinea con la visión más amplia de Polygon 2.0 de múltiples cadenas impulsadas por ZK con liquidez unificada pero diferentes backends de datos.

En resumen, todos los frameworks soportan múltiples capas de DA en diversos grados. Ethereum sigue siendo el estándar de oro para la DA (especialmente con el espacio de blobs de EIP-4844 que hace los datos en la cadena más baratos), pero nuevas redes de DA especializadas (Celestia, Avail) y esquemas (EigenDA de EigenLayer, comités de datos) están siendo adoptados en todos los ámbitos. Esta modularidad permite a los creadores de rollups en 2025 hacer concesiones entre costo y seguridad simplemente configurando un módulo de DA diferente en lugar de construir una nueva cadena desde cero.

Diseño y Descentralización del Secuenciador

El secuenciador es el nodo (o conjunto de nodos) que ordena las transacciones y produce bloques para un rollup. Cómo se diseña el secuenciador – centralizado vs. descentralizado, con permisos vs. sin permisos – afecta el rendimiento y las suposiciones de confianza de la cadena:

  • OP Stack (Optimism): Hoy en día, la mayoría de las cadenas de OP Stack ejecutan un secuenciador único operado por el equipo central o patrocinador de la cadena. Por ejemplo, el secuenciador de Optimism Mainnet es operado por OP Labs, y el secuenciador de Base es operado por Coinbase. Esto produce baja latencia y simplicidad a costa de la centralización (los usuarios deben confiar en que el secuenciador incluirá sus transacciones de manera justa). Sin embargo, Optimism ha incorporado mecanismos para minimizar la confianza: hay un contrato de cola de transacciones L1 donde los usuarios pueden enviar transacciones en Ethereum que el secuenciador debe incluir en la cadena L2. Si el secuenciador se cae o censura transacciones, los usuarios pueden confiar en L1 para que eventualmente se incluyan (aunque con algo de retraso). Esto proporciona una válvula de seguridad contra un secuenciador malicioso o fallido. En términos de descentralización, OP Stack es modular y teóricamente permite múltiples secuenciadores – por ejemplo, se podría implementar un conjunto de proponentes de bloques basado en round-robin o prueba de participación usando el código de OP Stack. En la práctica, esto requiere personalización y no es la configuración predeterminada. La hoja de ruta a largo plazo de la Superchain prevé un secuenciador compartido para todas las Cadenas OP, que sería un conjunto de validadores secuenciando transacciones para muchas cadenas a la vez. Un secuenciador compartido podría permitir la atomicidad entre cadenas y reducir el MEV en toda la Superchain. Todavía está en desarrollo a partir de 2025, pero el diseño de OP Stack no impide conectar tal consenso. Por ahora, las operaciones del secuenciador siguen siendo con permisos (ejecutadas por entidades en lista blanca), pero la gobernanza de Optimism planea descentralizar esto (posiblemente a través de staking o rotación de comités) una vez que la tecnología y la economía estén listas. En resumen: las cadenas de OP Stack comienzan con secuenciación centralizada (con L1 como respaldo), y se traza un camino hacia la descentralización gradual (pasando de la "Etapa 0" a la "Etapa 2" de madurez sin ruedas de entrenamiento).

  • ZK Stack (Hyperchains de zkSync): zkSync Era (la L2) actualmente utiliza un secuenciador centralizado operado por Matter Labs. Sin embargo, el ZK Stack está construido para permitir varios modos de secuenciación para nuevas cadenas. Las opciones incluyen un secuenciador centralizado (inicio fácil), un conjunto de secuenciadores descentralizados (ej. múltiples nodos alcanzando consenso en el orden), una cola de transacciones prioritarias desde L1, o incluso un servicio de secuenciador externo. En la visión de Elastic Chains de Matter Labs, las cadenas permanecen independientes pero la interoperabilidad es manejada por los contratos L1 y un "ZK Router/Gateway" – esto implica que cada cadena puede elegir su propio modelo de secuenciador siempre que cumpla con los protocolos para enviar raíces de estado y pruebas. Debido a que los ZK-rollups no requieren un consenso en L2 para la seguridad (las pruebas de validez aseguran la corrección), descentralizar el secuenciador se trata más de la vitalidad y la resistencia a la censura. Una Hyperchain podría implementar un productor de bloques round-robin o incluso conectarse a un consenso BFT de alto rendimiento para sus secuenciadores si lo desea. Dicho esto, ejecutar un secuenciador único es mucho más simple y sigue siendo la norma inicialmente. La documentación de ZK Stack menciona que una cadena podría usar un "protocolo externo" para la secuenciación – por ejemplo, uno podría imaginar usar el consenso de Tendermint o SU como productor de bloques y luego generar pruebas zk para los bloques. Además, como otros, zkSync tiene un mecanismo de cola de prioridad L1: los usuarios pueden enviar transacciones al contrato de zkSync con una tarifa de prioridad para garantizar la inclusión L1->L2 de manera oportuna (mitigando la censura). En general, la participación sin permisos en la secuenciación aún no se ha realizado en las cadenas de zkSync (no hay subasta pública de slots o selección de secuenciadores basada en staking en producción), pero la arquitectura deja espacio para ello. A medida que maduren las pruebas de validez, podríamos ver cadenas de zkSync con nodos secuenciadores gestionados por la comunidad que decidan colectivamente el orden (una vez que el rendimiento lo permita).

  • Arbitrum Orbit: En Arbitrum One (la L2 principal), el secuenciador es centralizado (operado por Offchain Labs), aunque la progresión del estado de la cadena está gobernada en última instancia por los validadores de Arbitrum y las pruebas de fraude. Arbitrum ha proporcionado de manera similar una cola L1 para los usuarios como respaldo contra problemas del secuenciador. En Orbit (el framework L3), cada cadena Orbit puede tener su propio secuenciador o conjunto de validadores. La tecnología Nitro de Arbitrum incluye la opción de ejecutar un rollup con un secuenciador descentralizado: esencialmente, se podría tener a múltiples partes ejecutando el software del nodo de Arbitrum y usando una elección de líder (posiblemente a través de la futura cadena de prueba de participación sin permisos de Arbitrum, o un mecanismo personalizado). De fábrica, las cadenas Orbit lanzadas hasta la fecha han sido en su mayoría centralizadas (ej. la cadena de juegos Xai es operada por una fundación en colaboración con Offchain Labs) – pero esto es una cuestión de configuración y gobernanza. Un desarrollo notable es la introducción de BoLD (Bounded Liquidity Delay) a principios de 2025, que es un nuevo protocolo para hacer la validación de Arbitrum más sin permisos. BoLD permite a cualquiera convertirse en un validador (probador) para la cadena, resolviendo desafíos de fraude en un marco de tiempo fijo sin una lista blanca. Esto acerca a Arbitrum a una operación sin confianza, aunque el rol del secuenciador (ordenar transacciones día a día) aún podría ser asignado o elegido. Offchain Labs ha expresado su enfoque en avanzar en la descentralización en 2024-2025 para Arbitrum. También vemos esfuerzos de multi-secuenciador: por ejemplo, una cadena Orbit podría usar un pequeño comité de secuenciadores conocidos para obtener algo de tolerancia a fallos (uno se cae, otro continúa). Otro ángulo es la idea de un secuenciador compartido para las cadenas Orbit, aunque Arbitrum no ha enfatizado esto tanto como Optimism. En cambio, la interoperabilidad se logra a través de L3s que se liquidan en la L2 de Arbitrum y usan puentes estándar. En resumen, Arbitrum Orbit ofrece flexibilidad en el diseño del secuenciador (desde una entidad hasta muchas), y la tendencia es hacia abrir el conjunto de validadores/secuenciadores a medida que la tecnología y la gobernanza comunitaria maduran. Hoy en día, es justo decir que las cadenas Orbit comienzan centralizadas pero tienen una hoja de ruta para la validación sin permisos.

  • Polygon CDK: Las cadenas de Polygon CDK (a veces referidas bajo el paraguas de "AggLayer" a finales de 2024) pueden elegir de manera similar su configuración de secuenciador/consenso. La cadena zkEVM de Polygon (operada por Polygon Labs) comenzó con un secuenciador único y un probador centralizado, con planes para descentralizar progresivamente ambos. El CDK, al ser modular, permite que una cadena conecte un módulo de consenso – por ejemplo, se podría lanzar una cadena CDK con un conjunto de validadores de Prueba de Participación produciendo bloques, descentralizando efectivamente la secuenciación desde el primer día. De hecho, el framework anterior de Polygon (Polygon Edge) se usó para cadenas empresariales con permisos usando consenso IBFT; las cadenas CDK podrían adoptar un enfoque híbrido (ejecutar el zkProver de Polygon pero tener un comité de nodos que proponga bloques). Por defecto, muchas cadenas CDK podrían funcionar con un solo operador por simplicidad y luego adoptar un consenso a medida que escalan. Polygon también está explorando un concepto de secuenciador o agregador compartido a través del hub AggLayer, que está destinado a conectar todas las cadenas de Polygon. Si bien AggLayer maneja principalmente la mensajería y la liquidez entre cadenas, podría evolucionar hacia un servicio de secuenciación compartido en el futuro (el cofundador de Polygon ha discutido la descentralización del secuenciador como parte de Polygon 2.0). En general, la falta de permisos aún no está presente – uno no puede convertirse espontáneamente en un secuenciador para la cadena CDK de alguien a menos que ese proyecto lo permita. Pero proyectos como dYdX V4 (que está construyendo una cadena independiente con una forma de consenso descentralizado) y otros muestran el apetito por L2s basadas en validadores. Polygon CDK hace técnicamente factible tener muchos productores de bloques, pero la implementación exacta se deja al desplegador de la cadena. Se espera que Polygon lance más orientación o incluso infraestructura para secuenciadores descentralizados a medida que más empresas y comunidades lancen cadenas CDK.

Para resumir la comparación de secuenciadores: Todos los frameworks actualmente dependen de un modelo de secuenciador relativamente centralizado en sus despliegues en vivo, para garantizar la eficiencia. Sin embargo, cada uno proporciona una ruta hacia la descentralización – ya sea a través de redes de secuenciación compartidas (OP Stack), consenso conectable (CDK, ZK Stack), o validadores sin permisos (BoLD de Arbitrum). La siguiente tabla destaca los diseños de secuenciadores:

Diseño del SecuenciadorOP StackZK Stack (zkSync)Arbitrum OrbitPolygon CDK
Modelo de operador por defectoSecuenciador único (gestionado por el proyecto)Secuenciador único (gestionado por Matter Labs o el proyecto)Secuenciador único (gestionado por el proyecto/Offchain Labs)Secuenciador único (gestionado por el proyecto o Polygon)
Opciones de descentralizaciónSí – se puede personalizar el consenso, ej. múltiples secuenciadores o un futuro conjunto compartidoSí – configurable; puede integrar consenso externo o colas de prioridadSí – configurable; puede usar multi-validador (comité AnyTrust o personalizado)Sí – puede integrar validadores PoS o consenso IBFT (a elección del proyecto)
Participación sin permisosPlaneado: Secuenciador compartido de Superchain (aún no en vivo). Los probadores de fraude son sin permisos en L1 (cualquiera puede desafiar).Aún no (no hay subasta pública de secuenciadores todavía). Las pruebas de validez no necesitan desafiantes. La comunidad puede ejecutar nodos de lectura, pero no producir bloques a menos que sea elegida.Emergente: BoLD permite a cualquiera validar pruebas de fraude. El secuenciador aún es elegido por la cadena (podría ser a través de DAO en el futuro).Aún no. Los secuenciadores son nombrados por los propietarios de la cadena o los validadores tienen permisos/staking. La hoja de ruta de Polygon incluye la validación comunitaria eventualmente.
Resistencia a la censuraCola L1 para que los usuarios aseguren la inclusión. La gobernanza con "ruedas de entrenamiento" puede vetar la mala conducta del secuenciador.Cola de prioridad L1 para la inclusión. El modo Validium necesita confianza en el comité de DA para la disponibilidad de datos.El buzón L1 asegura la inclusión si el secuenciador se detiene. El modo DAC requiere ≥1 miembro honesto del comité para suministrar datos.Depende del consenso de la cadena – ej. si se usa un conjunto de validadores, se necesita ≥2/3 honestos. El respaldo en modo rollup es la inclusión en Ethereum L1.

Como se ve, Optimism y Arbitrum incluyen colas de respaldo en la cadena, lo cual es una fuerte característica de resistencia a la censura. Las cadenas basadas en ZK confían en el hecho de que un secuenciador no puede falsificar el estado (gracias a las pruebas ZK), pero si censura, un nuevo secuenciador podría ser nombrado por la gobernanza – un área que aún se está refinando. La tendencia en 2025 es que probablemente veremos más pools de secuenciadores descentralizados y posiblemente redes de secuenciadores compartidos entrando en funcionamiento, complementando estos frameworks de RaaS. Cada proyecto está investigando activamente esto: por ejemplo, Astria y otros están construyendo servicios generales de secuenciación compartida, y OP Labs, Polygon y Offchain han mencionado planes para descentralizar el rol del secuenciador.

Modelos de Tarifas y Economía

Los modelos de tarifas determinan quién paga qué en estos frameworks de rollup y cómo se alinean los incentivos económicos para los operadores y el ecosistema. Las consideraciones clave incluyen: ¿En qué token se pagan las tarifas? ¿Quién recolecta las tarifas? ¿Qué costos (publicación en L1, pruebas) deben cubrirse? ¿Existen acuerdos de reparto de ingresos o comisiones? ¿Cuán personalizables son los parámetros de las tarifas?

  • Token de Gas y Personalización de Tarifas: Todos los frameworks comparados permiten personalizar el token de gas nativo, lo que significa que una nueva cadena puede decidir en qué moneda los usuarios pagan las tarifas. Por defecto, los rollups en Ethereum a menudo eligen ETH como el token de gas por conveniencia del usuario (los usuarios no necesitan un nuevo token para usar la cadena). Por ejemplo, Base (OP Stack) usa ETH para el gas, al igual que zkSync Era y Polygon zkEVM. OP Stack técnicamente soporta reemplazar ETH con otro ERC-20, pero en el contexto de la OP Superchain, hay un impulso para mantener un estándar (para hacer la interoperabilidad más fluida). De hecho, algunas cadenas de OP Stack que inicialmente consideraron un token personalizado optaron por ETH – por ejemplo, la cadena OP de Worldcoin usa ETH para las tarifas aunque el proyecto tiene su propio token WLD. Por otro lado, Arbitrum Orbit se lanzó sin soporte para tokens personalizados pero lo agregó rápidamente debido a la demanda. Ahora las cadenas Orbit pueden usar ARB o cualquier ERC-20 como gas. La Ape Chain L3 eligió la moneda APE como su moneda de gas, mostrando esta flexibilidad. Polygon CDK también te permite definir el token; muchos proyectos se inclinan por usar MATIC para alinearse con el ecosistema de Polygon (y MATIC se actualizará al token POL bajo Polygon 2.0), pero no es obligatorio. El ZK Stack de zkSync también soporta explícitamente tokens base personalizados (la documentación incluso tiene un tutorial de "Token base personalizado"). Esto es útil para cadenas empresariales que podrían querer, digamos, una stablecoin o su propia moneda para las tarifas. También es crucial para las app-chains que tienen su propia economía de tokens – pueden impulsar la demanda de su token convirtiéndolo en el token de gas. En resumen, el token de tarifa es totalmente configurable en todos los frameworks, aunque usar un token ampliamente poseído como ETH puede reducir la fricción del usuario.

  • Recolección y Distribución de Tarifas: Generalmente, el secuenciador (productor de bloques) recolecta las tarifas de transacción en la L2/L3. Este es un incentivo principal para operar un secuenciador. Por ejemplo, el secuenciador de Optimism gana todas las tarifas de gas que los usuarios pagan en Optimism, pero luego debe pagar por publicar lotes en Ethereum. Usualmente, el secuenciador tomará las tarifas L2 pagadas por el usuario, restará los costos de L1 y se quedará con el resto como ganancia. En una cadena bien administrada, los costos de L1 son una fracción de las tarifas de L2, dejando un margen de ganancia. Para los ZK-rollups, hay un costo adicional: generar la prueba ZK. Esto puede ser significativo (requiriendo hardware especializado o cómputo en la nube). Actualmente, algunos operadores de ZK rollup subsidian los costos de prueba (gastando fondos de capital de riesgo) para mantener bajas las tarifas de los usuarios durante la fase de crecimiento. Con el tiempo, se espera que los costos de prueba disminuyan con mejores algoritmos y hardware. En cuanto a los frameworks: zkSync y Polygon permiten al secuenciador cobrar un poco más para cubrir la prueba – y si una cadena usa un servicio de probador externo, podrían tener un reparto de ingresos con ellos. Notablemente, ningún framework excepto OP Superchain tiene un reparto de ingresos forzado a nivel de protocolo. El esquema de Ingresos de Rollup Estándar del Colectivo Optimism requiere que las Cadenas OP remitan ya sea el 2.5% de las tarifas brutas o el 15% de las ganancias netas (lo que sea mayor) a una tesorería colectiva. Este es un acuerdo voluntario pero esperado bajo la carta de la Superchain, en lugar de una aplicación por contrato inteligente, pero todas las principales cadenas de OP Stack (Base, opBNB, Worldcoin, etc.) lo han aceptado. Esas tarifas (más de 14,000 ETH hasta ahora) financian bienes públicos a través de la gobernanza de Optimism. En contraste, Arbitrum no cobra ninguna tarifa a las cadenas Orbit; Orbit es de uso sin permisos. La DAO de Arbitrum podría potencialmente pedir algún reparto de ingresos en el futuro (para financiar su propio ecosistema), pero no existe ninguno a partir de 2025. Polygon CDK de manera similar no impone un impuesto; el enfoque de Polygon es atraer usuarios a su ecosistema (aumentando así el valor y uso de MATIC) en lugar de cobrar tarifas por cadena. El cofundador de Polygon, Sandeep Nailwal, dijo explícitamente que AggLayer "no busca renta" de las cadenas. zkSync tampoco ha anunciado ningún reparto de tarifas – Matter Labs probablemente se enfoca en hacer crecer el uso de zkSync Era y las hyperchains, lo que indirectamente los beneficia a través de efectos de red y posiblemente el valor futuro del token.

  • Costos de Liquidación en L1: Una gran parte del modelo de tarifas es quién paga por las transacciones de L1 (publicación de datos o pruebas). En todos los casos, en última instancia los usuarios pagan, pero el mecanismo difiere. En los rollups Optimistas, el secuenciador publica periódicamente lotes de transacciones (con calldata) en L1. El costo de gas para esas transacciones de L1 es pagado por el secuenciador usando ETH. Sin embargo, los secuenciadores tienen eso en cuenta en el precio del gas de L2. Optimism y Arbitrum tienen fórmulas de precios de gas que estiman cuánto costará el calldata de una transacción en L1 e incluyen eso en la tarifa de gas de L2 (a menudo llamado el "costo L1 amortizado" por tx). Por ejemplo, una transacción simple en Optimism podría incurrir en 21,000 de gas L2 por ejecución y quizás unos cientos extra por datos de L1 – la tarifa del usuario cubre ambos. Si el precio se estima mal, el secuenciador podría perder dinero en ese lote o ganar si el uso es alto. Los secuenciadores típicamente ajustan las tarifas dinámicamente para coincidir con las condiciones de L1 (aumentando las tarifas de L2 cuando el gas de L1 es caro). En Arbitrum, el mecanismo es similar, aunque Arbitrum tiene componentes separados de "precios L1" y "precios L2". En zkSync/Polygon (ZK), el secuenciador debe publicar una prueba de validez en L1 (costando una cantidad fija de gas para verificar) más ya sea calldata (si es rollup) o la raíz de estado (si es validium). El costo de verificación de la prueba suele ser constante por lote (en zkSync Era es del orden de unos cientos de miles de gas), por lo que el modelo de tarifas de zkSync distribuye ese costo entre las transacciones. Podrían cobrar un ligero sobrecosto en cada tx por la prueba. Notablemente, zkSync introdujo características como diferencias de estado y compresión para minimizar los datos publicados en L1. Polygon zkEVM de manera similar usa pruebas recursivas para agrupar muchas transacciones en una sola prueba, amortizando el costo de verificación. Si una cadena usa una DA alternativa (Celestia/Avail), entonces en lugar de pagar a Ethereum por calldata, pagan a ese proveedor de DA. Celestia, por ejemplo, tiene su propio token de gas (TIA) para pagar por los blobs de datos. Por lo tanto, una cadena podría necesitar convertir parte de las tarifas para pagar a los mineros de Celestia. Los frameworks están abstraendo cada vez más estos costos: por ejemplo, una cadena de OP Stack podría pagar a un nodo de DA de Celestia a través de un adaptador, e incluir ese costo en las tarifas del usuario.

  • Costos para los Usuarios (Finalidad y Retiro): Para los rollups optimistas (OP Stack, Arbitrum Orbit en modo rollup), los usuarios enfrentan el infame período de desafío para los retiros – típicamente 7 días en Ethereum L1. Esto es un golpe a la usabilidad, pero la mayoría de los ecosistemas tienen mitigaciones. Los puentes rápidos (redes de liquidez) permiten a los usuarios intercambiar sus tokens L2 por tokens L1 instantáneamente por una pequeña tarifa, mientras que los arbitrajistas esperan los 7 días. Arbitrum ha ido más allá para las cadenas Orbit, trabajando con equipos para permitir retiros rápidos en tan solo 15 minutos a través de proveedores de liquidez integrados a nivel de protocolo. Esto efectivamente significa que los usuarios no esperan una semana excepto en los peores escenarios. Los ZK-rollups no tienen este retraso – una vez que una prueba de validez es aceptada en L1, el estado es final. Así que los usuarios de zkSync y Polygon obtienen una finalidad más rápida (a menudo de minutos a una hora) dependiendo de la frecuencia con que se envíen las pruebas. La contrapartida es que la prueba podría introducir un poco de retraso entre el momento en que se acepta una transacción en L2 y cuando se incluye en una prueba de L1 (podrían ser unos minutos). Pero en general, los ZK rollups ofrecen retiros de 10 a 30 minutos en 2025, lo cual es una gran mejora sobre los 7 días. Los usuarios pueden pagar una tarifa ligeramente más alta por la finalidad inmediata (para cubrir los costos del probador), pero muchos lo consideran que vale la pena. La Personalización de Tarifas también es digna de mención: los frameworks permiten esquemas de tarifas personalizados (como transacciones gratuitas o subsidios de gas) si los proyectos lo desean. Por ejemplo, una empresa podría subsidiar todas las tarifas de los usuarios en su cadena operando el secuenciador a pérdida (quizás para un juego o una aplicación social). O podrían establecer un modelo de gas diferente (algunos han jugado con no cobrar gas por ciertas acciones, o contabilidad de gas alternativa). Dado que la mayoría de los frameworks apuntan a la equivalencia con Ethereum, tales cambios profundos son raros, pero posibles con modificación del código. El Stylus de Arbitrum podría permitir una medición de tarifas diferente para los contratos WASM (no cobrar por ciertas operaciones para fomentar el uso de WASM, por ejemplo). El Polygon CDK al ser de código abierto y modular significa que si un proyecto quisiera implementar un mecanismo de tarifas novedoso (como quema de tarifas o precios dinámicos), podría hacerlo.

En esencia, todos los frameworks de rollup se esfuerzan por alinear los incentivos económicos: hacer que sea rentable operar un secuenciador (a través de los ingresos por tarifas), mantener las tarifas razonables para los usuarios aprovechando una DA más barata, y (opcionalmente) canalizar algo de valor a su ecosistema más amplio. El modelo de Optimism es único en compartir explícitamente los ingresos para bienes públicos, mientras que otros dependen del crecimiento y la economía de tokens (por ejemplo, más cadenas -> más uso de MATIC/ETH, aumentando el valor de esos tokens).

Arquitectura y Modularidad

Todos estos frameworks se enorgullecen de una arquitectura modular, lo que significa que cada capa de la pila (ejecución, liquidación, consenso, DA, pruebas) es intercambiable o actualizable. Veamos brevemente cada uno:

  • OP Stack: Construido como una serie de módulos correspondientes a las capas de Ethereum – motor de ejecución (OP EVM, derivado de geth), nodo de consenso/rollup (op-node), contratos inteligentes de liquidación, y pronto el probador de fraude. El objetivo de diseño de OP Stack fue la equivalencia con EVM (sin cambios en el cronograma de gas o en los opcodes) y la facilidad de integración con las herramientas de Ethereum. La actualización Bedrock en 2023 modularizó aún más la pila de Optimism, facilitando el intercambio de componentes (por ejemplo, para implementar pruebas ZK en el futuro, o usar una DA diferente). De hecho, OP Stack no se limita a las pruebas de fraude optimistas – el equipo ha dicho que está abierto a integrar pruebas de validez cuando maduren, convirtiendo esencialmente las cadenas de OP Stack en ZK rollups sin cambiar la experiencia del desarrollador. El concepto de Superchain extiende la arquitectura a múltiples cadenas: estandarizando la comunicación entre cadenas, los puentes y quizás la secuenciación compartida. OP Stack viene con un rico conjunto de contratos inteligentes en L1 (para depósitos, retiros, verificación de pruebas de fraude, etc.), que las cadenas heredan de fábrica. Es efectivamente una plantilla de cadena L2 plug-and-play – proyectos como Base se lanzaron bifurcando los repositorios de OP Stack y configurándolos para apuntar a sus propios contratos.

  • ZK Stack: El ZK Stack es el framework subyacente a zkSync Era y futuras "Hyperchains". Arquitectónicamente, incluye el entorno de ejecución zkEVM (una VM basada en LLVM que permite ejecutar código Solidity con cambios mínimos), el sistema de probador (los circuitos y la generación de pruebas para las transacciones), el nodo secuenciador y los contratos L1 (los contratos inteligentes de zkSync que verifican pruebas y gestionan las raíces de estado). La modularidad se ve en cómo separa el circuito de prueba ZK de la ejecución – teóricamente se podría intercambiar un esquema de prueba diferente o incluso una VM diferente (aunque no es trivial). El ZK Stack introduce la Arquitectura de Cadena Elástica con componentes como el ZK Router y el ZK Gateway. Estos actúan como una capa de interoperabilidad que conecta múltiples Cadenas ZK. Es un poco como un concepto de "internet de ZK rollups", donde el Router (en Ethereum) mantiene un registro de cadenas y facilita puentes/liquidez compartidos, y el Gateway maneja mensajes entre cadenas fuera de la cadena. Esto es modular porque una nueva cadena puede conectarse a esa arquitectura simplemente desplegándose con los contratos estándar. ZK Stack también adopta la abstracción de cuentas a nivel de protocolo (contratos como cuentas, meta-transacciones nativas), que es una elección arquitectónica para mejorar la UX. Otro aspecto modular: como se discutió en DA, puede operar en modo rollup o validium – esencialmente cambiando un interruptor en la configuración. Además, la pila tiene una noción de consenso conectable para la secuenciación (como se señaló anteriormente). La capa de liquidación puede ser Ethereum o potencialmente otra cadena: la hoja de ruta de zkSync incluso planteó la liquidación de hyperchains en L2 (por ejemplo, una L3 que publica pruebas en la L2 de zkSync Era en lugar de L1) – de hecho, lanzaron un prototipo llamado "ZK Portal" para la liquidación de L3 en L2. Esto da una modularidad jerárquica (L3->L2->L1). En general, ZK Stack es un poco menos llave en mano para equipos que no son de Matter-Labs a partir de 2025 (ya que ejecutar una cadena ZK implica coordinar probadores, etc.), pero es altamente flexible en manos capaces.

  • Arbitrum Orbit: La arquitectura de Arbitrum se basa en la pila Arbitrum Nitro, que incluye la capa de ejecución ArbOS (la interpretación de Arbitrum de EVM con algunas pequeñas diferencias), el Secuenciador/Relay, el componente AnyTrust para DA alternativa, y la maquinaria de prueba de fraude (pruebas de fraude interactivas). Orbit esencialmente te permite usar esa misma pila pero configurar ciertos parámetros (como el ID de la cadena, el estado de génesis de L2, la elección de rollup vs. AnyTrust). Modularidad: Arbitrum introdujo Stylus, un nuevo motor de contratos inteligentes compatible con WASM que se ejecuta junto con la EVM. Stylus permite escribir contratos en Rust, C, C++ que se compilan a WASM y se ejecutan con una velocidad casi nativa en las cadenas de Arbitrum. Este es un módulo opcional – las cadenas Orbit pueden habilitar Stylus o no. Es un diferenciador para la pila de Arbitrum, haciéndolo atractivo para dApps de alto rendimiento (por ejemplo, aplicaciones de juegos o trading podrían escribir parte de la lógica en Rust para mayor velocidad). El módulo de disponibilidad de datos también es conectable como se discutió (las cadenas de Arbitrum pueden elegir en la cadena o DAC). Otro módulo es la liquidación en L1: las cadenas Orbit pueden publicar sus pruebas ya sea en Ethereum (L1) o en Arbitrum One (L2). Si es lo último, efectivamente son L3s ancladas en la seguridad de Arbitrum One (con suposiciones de confianza ligeramente diferentes). Muchas cadenas Orbit se están lanzando como L3s (para heredar las tarifas más bajas de Arbitrum One y, en última instancia, la seguridad de Ethereum). El código base de Arbitrum es ahora completamente de código abierto, y proyectos como Caldera, Conduit construyen sobre él para proporcionar un despliegue fácil de usar – podrían agregar sus propios módulos (como monitoreo, APIs de gestión de cadenas). Vale la pena señalar que las pruebas de fraude de Arbitrum históricamente no eran sin permisos (solo validadores en lista blanca podían desafiar), pero con BoLD, esa parte de la arquitectura está cambiando para permitir que cualquiera intervenga. Así que el componente de prueba de fraude se está volviendo más descentralizado (lo cual es una actualización modular en cierto sentido). Se podría decir que Arbitrum es menos un "kit de lego" que OP Stack o Polygon CDK, en el sentido de que Offchain Labs no ha lanzado un lanzador de cadenas de un solo clic (aunque sí lanzaron una GUI de despliegue de Orbit en GitHub). Pero funcionalmente, es lo suficientemente modular como para que terceros hayan automatizado los despliegues para él.

  • Polygon CDK (AggLayer): Polygon CDK se describe explícitamente como un "framework modular" para cadenas impulsadas por ZK. Aprovecha la tecnología de prueba ZK de Polygon (de Polygon zkEVM, que se basa en Plonky2 y SNARKs recursivos). La arquitectura separa la capa de ejecución (que es una EVM – específicamente una bifurcación de Geth ajustada para zkEVM) de la capa de probador y los contratos de puente/liquidación. Debido a que es modular, un desarrollador puede elegir diferentes opciones para cada uno: por ejemplo, Ejecución – presumiblemente siempre EVM por ahora (para usar las herramientas existentes), DA – como se discutió (Ethereum u otros), Consenso del Secuenciador – nodo único vs. multi-nodo, Probador – se puede ejecutar el probador Tipo 1 (pruebas de validez publicadas en Ethereum) o un Tipo 2 (pruebas de validium) etc., y Integración con AggLayer – sí o no (AggLayer para interoperabilidad). Polygon incluso proporcionó una interfaz elegante (mostrada a continuación) para visualizar estas opciones:

La interfaz de configuración de Polygon CDK, ilustrando las opciones modulares – ej. Rollups vs. Validium (solución de escalado), secuenciador descentralizado vs. centralizado, DA local/Ethereum/terceros, diferentes tipos de probadores, y si habilitar la interoperabilidad de AggLayer.

Bajo el capó, Polygon CDK utiliza pruebas ZK con recursión para permitir un alto rendimiento y un conjunto de validadores dinámico. El AggLayer es una parte emergente de la arquitectura que conectará cadenas para mensajería sin confianza y liquidez compartida. El CDK está construido de tal manera que las futuras mejoras en la tecnología ZK de Polygon (como pruebas más rápidas, o nuevas características de VM) pueden ser adoptadas por todas las cadenas CDK a través de actualizaciones. Polygon tiene un concepto de zkEVM "Tipo 1 vs. Tipo 2" – el Tipo 1 es totalmente equivalente a Ethereum, el Tipo 2 es casi equivalente con cambios menores para la eficiencia. Una cadena CDK podría elegir una EVM ligeramente modificada para más velocidad (sacrificando algo de equivalencia) – esta es una opción arquitectónica que los proyectos tienen. En general, CDK es muy tipo lego: uno puede ensamblar una cadena eligiendo componentes adecuados para su caso de uso (por ejemplo, una empresa podría elegir validium + secuenciadores con permisos + visibilidad de Tx privada; una cadena DeFi pública podría elegir rollup + secuenciador descentralizado + AggLayer habilitado para liquidez). Esta versatilidad ha atraído a muchos proyectos a considerar CDK para lanzar sus propias redes.

  • Imágenes y diagramas: Los frameworks a menudo proporcionan diagramas visuales de su arquitectura modular. Por ejemplo, la interfaz de usuario de zkSync muestra interruptores para Rollup/Validium, L2/L3, centralizado/descentralizado, etc., destacando la flexibilidad de ZK Stack:

Un ejemplo de configuración para una "Hyperchain" de zkSync. La interfaz de ZK Stack permite seleccionar el modo de la cadena (Rollup vs. Validium vs. Volition), la capa (L2 o L3), la secuenciación de transacciones (descentralizada, centralizada o compartida), la fuente de disponibilidad de datos (Ethereum, red de terceros o personalizada), la visibilidad de los datos (cadena pública o privada) y el token de gas (ETH, personalizado o sin gas). Este enfoque modular está diseñado para soportar una variedad de casos de uso, desde cadenas DeFi públicas hasta cadenas empresariales privadas.

En resumen, todas estas pilas son altamente modulares y actualizables, lo cual es esencial dado el ritmo de la innovación en blockchain. Están convergiendo en cierto sentido: OP Stack agregando pruebas de validez, Polygon agregando secuenciación compartida (ideas de OP Stack), Arbitrum agregando L3s interoperables (como otros), zkSync persiguiendo L3s (como lo hacen Orbit y OPStack). Esta polinización cruzada significa que los frameworks modulares en 2025 son más parecidos que diferentes en filosofía – cada uno quiere ser el kit de herramientas todo en uno para lanzar cadenas escalables sin reinventar la rueda.

Experiencia del Desarrollador y Herramientas

Un factor crítico para la adopción es cuán fáciles y amigables para los desarrolladores son estos frameworks. Esto incluye documentación, SDKs/APIs, CLIs para el despliegue, herramientas de monitoreo y la curva de aprendizaje para los desarrolladores:

  • OP Stack – Experiencia del Desarrollador: El OP Stack de Optimism se beneficia de ser equivalente a EVM, por lo que los desarrolladores de Ethereum pueden usar herramientas familiares (Remix, Hardhat, Truffle, Solidity, Vyper) sin modificación. Los contratos inteligentes desplegados en una cadena OP se comportan exactamente como en L1. Esto reduce drásticamente la curva de aprendizaje. Optimism proporciona una extensa documentación: los documentos oficiales de Optimism tienen secciones sobre el OP Stack, cómo ejecutar un nodo L2, e incluso un tutorial de "OP Stack desde cero". También hay guías escritas por la comunidad (por ejemplo, la guía paso a paso de QuickNode sobre cómo desplegar un rollup L2 de Optimism). En términos de herramientas, OP Labs ha lanzado el cliente op-node (para el nodo del rollup) y op-geth (motor de ejecución). Para lanzar una cadena, un desarrollador típicamente necesita configurar estos y desplegar los contratos L1 (Standard Bridge, etc.). Esto no era trivial pero se está volviendo más fácil con los servicios de proveedores. Despliegue como servicio: empresas como Caldera, Conduit e Infura/Alchemy ofrecen despliegues gestionados de rollups de OP Stack, lo que abstrae gran parte del DevOps. Para el monitoreo, debido a que una cadena de OP Stack es esencialmente una cadena geth más un coordinador de rollup, se pueden usar herramientas de monitoreo estándar de Ethereum (paneles de métricas de ETH, exploradores de bloques como Etherscan/Blockscout). De hecho, Etherscan soporta cadenas de OP Stack como Optimism y Base, proporcionando interfaces de explorador de bloques familiares. Las herramientas de desarrollador específicas para las Cadenas OP incluyen el SDK de Optimism para puentes (facilitando depósitos/retiros en aplicaciones) y la integración de Bedrock con JSON-RPC de Ethereum (por lo que herramientas como MetaMask simplemente funcionan cambiando de red). El código de OP Stack tiene licencia MIT, invitando a los desarrolladores a bifurcar y experimentar. Muchos lo hicieron – por ejemplo, el equipo de BNB Chain usó OP Stack para construir opBNB con sus propias modificaciones al consenso y al token de gas (usan gas BNB en opBNB). La adherencia de OP Stack a los estándares de Ethereum hace que la experiencia del desarrollador sea posiblemente la más fluida entre estos: esencialmente "Ethereum, pero más barato" desde la perspectiva de un desarrollador de contratos. Las principales nuevas habilidades necesarias son en torno a la ejecución de la infraestructura (para aquellos que lanzan una cadena) y la comprensión de los matices de los puentes entre cadenas. La comunidad y el soporte de Optimism (Discord, foros) son activos para ayudar a los nuevos equipos de cadenas. Además, Optimism ha financiado herramientas del ecosistema como Magi (un cliente de rollup alternativo en Rust) para diversificar la pila y hacerla más robusta para los desarrolladores.

  • ZK Stack de zkSync – Experiencia del Desarrollador: En el lado del desarrollo de contratos, el ZK Stack de zkSync ofrece un zkEVM que pretende tener una alta compatibilidad pero actualmente no es 100% equivalente a nivel de bytecode. Soporta contratos de Solidity y Vyper, pero hay diferencias sutiles (por ejemplo, ciertos precompilados o costos de gas). Dicho esto, Matter Labs construyó un compilador LLVM que toma Solidity y produce bytecode de zkEVM, por lo que la mayoría del código Solidity funciona con pocos o ningún cambio. También soportan nativamente la abstracción de cuentas, que los desarrolladores pueden aprovechar para crear transacciones sin gas, billeteras multi-firma, etc., más fácilmente que en Ethereum (sin necesidad de ERC-4337). La documentación para desarrolladores de zkSync es completa (docs.zksync.io) y cubre cómo desplegar contratos, usar la CLI de Hyperchain (si la hay), y configurar una cadena. Sin embargo, ejecutar un ZK rollup es inherentemente más complejo que uno optimista – necesitas una configuración de prueba. El ZK Stack proporciona el software de probador (por ejemplo, los probadores de GPU para los circuitos de zkSync), pero un operador de cadena debe tener acceso a hardware serio o servicios en la nube para generar pruebas continuamente. Este es un nuevo desafío de DevOps; para mitigarlo, están surgiendo algunas empresas que proporcionan servicios de probador o incluso Prueba como Servicio. Si un desarrollador no quiere ejecutar sus propios probadores, podría subcontratarlo (con garantías de confianza o criptoeconómicas). Herramientas: zkSync proporciona un portal de puente y billetera por defecto (el Portal de zkSync) que puede ser bifurcado para una nueva cadena, dando a los usuarios una interfaz de usuario para mover activos y ver cuentas. Para la exploración de bloques, Blockscout ha sido adaptado a zkSync, y Matter Labs construyó su propio explorador de bloques para zkSync Era que probablemente podría usarse para nuevas cadenas. La existencia del ZK Gateway y Router significa que si un desarrollador se conecta a eso, obtiene algo de interoperabilidad lista para usar con otras cadenas – pero necesita seguir los estándares de Matter Labs. En general, para un desarrollador de contratos inteligentes, construir en zkSync no es demasiado difícil (solo Solidity, con quizás diferencias menores como que gasleft() podría comportarse ligeramente diferente debido a no tener el costo de gas real de Ethereum). Pero para un operador de cadena, el ZK Stack tiene una curva de aprendizaje más pronunciada que OP Stack u Orbit. En 2025, Matter Labs se está enfocando en mejorar esto – por ejemplo, simplificando el proceso de lanzamiento de una Hyperchain, posiblemente proporcionando scripts o imágenes en la nube para levantar toda la pila. También hay una comunidad emergente de desarrolladores en torno a ZK Stack; por ejemplo, la Edición Comunitaria de ZKSync es una iniciativa donde los miembros de la comunidad ejecutan cadenas L3 de prueba y comparten consejos. Debemos señalar que el soporte de lenguajes para el ecosistema de zkSync podría expandirse – han hablado de permitir otros lenguajes a través del pipeline de LLVM (por ejemplo, un compilador de Rust a zkEVM en el futuro), pero Solidity es el principal ahora. En resumen, la experiencia de desarrollo de zkSync: excelente para desarrolladores de DApp (casi como Ethereum), moderada para lanzadores de cadenas (necesitan manejar el probador y nuevos conceptos como validiums).

  • Arbitrum Orbit – Experiencia del Desarrollador: Para los desarrolladores de Solidity, Arbitrum Orbit (y Arbitrum One) es totalmente compatible con EVM a nivel de bytecode (Arbitrum Nitro usa ejecución derivada de geth). Por lo tanto, desplegar e interactuar con contratos en una cadena de Arbitrum es como en Ethereum (con algunas pequeñas diferencias como un acceso ligeramente diferente al número de bloque de L1, chainID, etc., pero nada importante). Donde Arbitrum se destaca es en Stylus – los desarrolladores pueden escribir contratos inteligentes en lenguajes como Rust, C, C++ (compilados a WebAssembly) y desplegarlos junto con contratos EVM. Esto abre el desarrollo de blockchain a un grupo más amplio de programadores y permite casos de uso de alto rendimiento. Por ejemplo, una lógica intensiva en algoritmos podría escribirse en C para mayor velocidad. Stylus todavía está en beta en la mainnet de Arbitrum, pero las cadenas Orbit pueden experimentar con él. Este es un beneficio único para la experiencia del desarrollador, aunque aquellos que usen Stylus necesitarán aprender nuevas herramientas (por ejemplo, cadenas de herramientas de Rust, y las bibliotecas de Arbitrum para interactuar WASM con la cadena). La documentación de Arbitrum proporciona orientación sobre el uso de Stylus e incluso sobre cómo escribir contratos inteligentes en Rust. Para lanzar una cadena Orbit, Offchain Labs ha proporcionado scripts de Devnet y una interfaz de usuario de despliegue de Orbit. El proceso es algo técnico: uno debe configurar un nodo de Arbitrum con flags --l3 (si se lanza una L3) y configurar el génesis, los parámetros de la cadena, etc. QuickNode y otros han publicado guías ("Cómo desplegar tu propia cadena Arbitrum Orbit"). Además, las asociaciones de Orbit con Caldera, AltLayer y Conduit significan que estos terceros se encargan de gran parte del trabajo pesado. Un desarrollador puede esencialmente llenar un formulario o ejecutar un asistente con esos servicios para obtener una cadena de Arbitrum personalizada, en lugar de modificar manualmente el código de Nitro. En términos de depuración y monitoreo, las cadenas de Arbitrum pueden usar Arbiscan (para aquellas que lo tienen) o exploradores comunitarios. También hay integraciones de Grafana/Prometheus para métricas de nodos. Una complejidad es el sistema de prueba de fraude – los desarrolladores que lanzan una cadena Orbit deben asegurarse de que haya validadores (quizás ellos mismos u otros de confianza) que ejecuten el software de validador fuera de la cadena para vigilar el fraude. Offchain Labs probablemente proporciona scripts predeterminados para ejecutar dichos validadores. Pero como las pruebas de fraude rara vez se activan, se trata más de tener el proceso de seguridad en su lugar. La gran comunidad de desarrolladores de Arbitrum (proyectos que construyen en Arbitrum One) es un activo – recursos como tutoriales, respuestas en stackexchange, etc., a menudo se aplican también a Orbit. Además, Arbitrum es conocido por sus fuertes esfuerzos de educación para desarrolladores (talleres, hackatones), que presumiblemente se extienden a los interesados en Orbit.

  • Polygon CDK – Experiencia del Desarrollador: Polygon CDK es más nuevo (anunciado a mediados/finales de 2023), pero se basa en componentes familiares. Para los desarrolladores que escriben contratos, las cadenas de Polygon CDK usan un zkEVM que pretende ser equivalente a la EVM de Ethereum (el zkEVM Tipo 2 de Polygon es casi idéntico con algunos casos límite). Por lo tanto, Solidity y Vyper son los lenguajes de referencia, con soporte completo para las herramientas de desarrollo estándar de Ethereum. Si has desplegado en Polygon zkEVM o Ethereum, puedes desplegar en una cadena CDK de manera similar. El desafío está más en el lado de las operaciones de la cadena. El CDK de Polygon es de código abierto en GitHub y viene con documentación sobre cómo configurar una cadena. Probablemente proporciona una herramienta de línea de comandos para andamiar una nueva cadena (similar a cómo se podría usar starport de Cosmos SDK o la plantilla de nodo de Substrate). Polygon Labs ha invertido en hacer la configuración lo más fácil posible – una cita: "lanzar una L2 de Ethereum de alto rendimiento impulsada por ZK tan fácilmente como desplegar un contrato inteligente". Aunque quizás optimista, esto indica que existen herramientas o scripts para simplificar el despliegue. De hecho, ha habido adoptantes tempranos como Immutable (para juegos) y OKX (cadena de exchange) que han trabajado con Polygon para lanzar cadenas CDK, lo que sugiere un proceso bastante fluido con el apoyo del equipo de Polygon. El CDK incluye SDKs y bibliotecas para interactuar con el puente (para depósitos/retiros) y para habilitar AggLayer si se desea. El monitoreo de una cadena CDK puede aprovechar el explorador de bloques de Polygon (Polygonscan) si lo integran, o Blockscout. Polygon también es conocido por sus robustos SDKs para juegos y móviles (por ejemplo, SDKs de Unity) – esos se pueden usar en cualquier cadena basada en Polygon. El soporte para desarrolladores es un gran enfoque: Polygon tiene academias, subvenciones, hackatones regularmente, y su equipo de Relaciones con Desarrolladores ayuda a los proyectos uno a uno. Un ejemplo de experiencia de desarrollador empresarial: Libre, una cadena institucional lanzada con CDK, presumiblemente tenía requisitos personalizados – Polygon pudo acomodar cosas como módulos de identidad o características de cumplimiento en esa cadena. Esto muestra que el CDK puede extenderse para casos de uso específicos por parte de los desarrolladores con la ayuda del framework. En cuanto a materiales de aprendizaje, el sitio de documentación y el blog de Polygon tienen guías sobre el uso de CDK, y debido a que CDK es esencialmente la evolución de su zkEVM, aquellos familiarizados con el diseño de zkEVM de Polygon pueden aprenderlo rápidamente. Un aspecto más de las herramientas: Herramientas entre cadenas – dado que muchas cadenas de Polygon CDK coexistirán, Polygon proporciona el AggLayer para la mensajería, pero también fomenta el uso de mensajería estándar entre cadenas como LayerZero (de hecho, la cadena Orbit de Rarible integró LayerZero para transferencias de NFT y las cadenas de Polygon también pueden hacerlo). Por lo tanto, los desarrolladores tienen opciones para integrar plugins de interoperabilidad fácilmente. En resumen, la experiencia del desarrollador de CDK tiene como objetivo ser llave en mano para lanzar cadenas a nivel de Ethereum con seguridad ZK, beneficiándose de los años de experiencia de Polygon en L2.

En conclusión, la experiencia del desarrollador ha mejorado drásticamente para lanzar cadenas personalizadas: lo que antes requería todo un equipo de ingenieros de protocolo ahora se puede hacer con frameworks guiados y soporte. Las ofertas de Optimism y Arbitrum aprovechan la familiaridad (equivalencia con EVM), zkSync y Polygon ofrecen tecnología de vanguardia con una facilidad de uso creciente, y todos tienen ecosistemas crecientes de herramientas de terceros para simplificar el desarrollo (desde exploradores de bloques hasta paneles de monitoreo y scripts de devops). La calidad de la documentación es generalmente alta – los documentos oficiales más las guías de la comunidad (artículos de Medium, guías de QuickNode/Alchemy) cubren mucho terreno. Todavía hay una curva de aprendizaje no trivial para pasar de desarrollador de contratos inteligentes a "operador de rollup", pero se está volviendo más fácil a medida que surgen las mejores prácticas y se expande la comunidad de constructores de rollups.

Soporte del Ecosistema y Estrategias de Salida al Mercado

Construir una tecnología es una cosa; construir un ecosistema es otra. Cada uno de estos frameworks está respaldado por una organización o comunidad que invierte en el crecimiento a través de subvenciones, financiación, marketing y apoyo de asociaciones. Aquí comparamos sus estrategias de soporte del ecosistema – cómo atraen a desarrolladores y proyectos, y cómo ayudan a esos proyectos a tener éxito:

  • Ecosistema de OP Stack (Optimism): Optimism tiene una estrategia de ecosistema robusta centrada en su Colectivo Optimism y su ethos de financiación de bienes públicos. Fueron pioneros en la Financiación Retroactiva de Bienes Públicos (RPGF) – usando la tesorería del token OP para recompensar a desarrolladores y proyectos que benefician al ecosistema. A través de múltiples rondas de RPGF, Optimism ha distribuido millones en financiación a proyectos de infraestructura, herramientas de desarrollo y aplicaciones en Optimism. Cualquier proyecto que construya con OP Stack (especialmente si se alinea con la visión de la Superchain) es elegible para solicitar subvenciones del Colectivo. Además, la gobernanza de Optimism puede autorizar programas de incentivos (a principios de 2022, tuvieron un airdrop y un fondo de gobernanza que los proyectos podían aprovechar para distribuir recompensas de OP a los usuarios). En 2024, Optimism estableció el modelo de Reparto de Ingresos de la Superchain, donde cada Cadena OP contribuye con una pequeña porción de las tarifas a una tesorería compartida. Esto crea un círculo virtuoso: a medida que más cadenas (como Base, opBNB, la cadena de Worldcoin, etc.) generan uso, financian colectivamente más bienes públicos que mejoran el OP Stack, lo que a su vez atrae a más cadenas. Es un enfoque de suma positiva único de Optimism. En el lado de la salida al mercado, Optimism se ha asociado activamente con entidades importantes: conseguir que Coinbase construyera Base fue una gran validación de OP Stack, y Optimism Labs proporcionó ayuda técnica y soporte a Coinbase durante ese proceso. De manera similar, han trabajado con el equipo de Worldcoin, y la migración de Celo a una L2 de OP Stack se hizo con la consulta de OP Labs. Optimism hace mucho alcance a desarrolladores – desde organizar hackatones (a menudo combinados con eventos de ETHGlobal) hasta mantener un Centro de Desarrolladores con tutoriales. También invierten en herramientas: por ejemplo, financiando equipos para construir clientes alternativos, herramientas de monitoreo, y proporcionando un faucet oficial e integración de explorador de bloques para nuevas cadenas. En cuanto al marketing, Optimism acuñó el término "Superchain" y promueve activamente la visión de muchas cadenas uniéndose bajo un paraguas interoperable, lo que ha atraído a proyectos que quieren ser parte de una narrativa más amplia en lugar de una appchain aislada. También está el atractivo de la liquidez compartida: con el próximo OPCraft (interoperabilidad de la Superchain), las aplicaciones en una Cadena OP pueden interactuar fácilmente con otra, lo que hace atractivo lanzar una cadena que no sea una isla. En esencia, el juego del ecosistema de OP Stack se trata de comunidad y colaboración – únete a la Superchain, obtén acceso a un grupo de usuarios (a través de puentes fáciles), financiación y marca colectiva. Incluso crearon un concepto de "Pasaporte de Rollup" donde los usuarios pueden tener una identidad unificada en todas las Cadenas OP. Todos estos esfuerzos reducen la barrera para que las nuevas cadenas encuentren usuarios y desarrolladores. Finalmente, la propia base de usuarios y reputación de Optimism (siendo una de las principales L2s) significa que cualquier cadena de OP Stack puede aprovechar eso de alguna manera (Base lo hizo, publicitándose como parte del ecosistema de Optimism, por ejemplo).

  • Ecosistema de zkSync (ZK Stack/Hyperchains): Matter Labs (el equipo detrás de zkSync) aseguró grandes rondas de financiación (más de $200M) para impulsar su ecosistema. Han establecido fondos como el Fondo del Ecosistema de zkSync, a menudo en colaboración con VCs, para invertir en proyectos que construyen en zkSync Era. Para el ZK Stack específicamente, han comenzado a promover el concepto de Hyperchains a comunidades que necesitan su propia cadena. Una estrategia es apuntar a verticales específicas: por ejemplo, los juegos. zkSync ha destacado cómo un estudio de juegos podría lanzar su propia Hyperchain para obtener personalización y seguir conectado a Ethereum. Es probable que ofrezcan un apoyo cercano a los socios iniciales (de la manera en que Polygon lo hizo con algunas empresas). La mención en el artículo de Zeeve sobre un "banco suizo; el banco más grande del mundo" interesado en ZK Stack sugiere que Matter Labs está cortejando casos de uso empresariales que necesitan privacidad (las pruebas ZK pueden garantizar la corrección mientras mantienen algunos datos privados, algo importante para las instituciones). Si zkSync consigue una cadena empresarial importante, eso impulsaría su credibilidad. El soporte para desarrolladores en zkSync es bastante fuerte: ejecutan aceleradoras (por ejemplo, se anunció un programa con Blockchain Founders Fund), hackatones (a menudo con temática ZK), y tienen una comunidad activa en su Discord que proporciona ayuda técnica. Si bien zkSync no tiene un token en vivo (a partir de 2025) para la gobernanza o los incentivos, se especula sobre uno, y los proyectos podrían anticipar futuros programas de incentivos. Matter Labs también ha estado trabajando en el soporte de puentes: se asociaron con puentes importantes como Across, LayerZero, Wormhole para garantizar que los activos y los mensajes puedan moverse fácilmente hacia y desde zkSync y cualquier hyperchain. De hecho, Across Protocol integró el ZK Stack de zkSync, presumiendo de soporte en "todos los principales frameworks de L2". Este enfoque en la interoperabilidad significa que un proyecto que lanza una hyperchain puede conectarse fácilmente a la mainnet de Ethereum y otras L2s, crucial para atraer usuarios (nadie quiere estar aislado). En cuanto al marketing, zkSync impulsa el eslogan "Web3 sin compromisos" y enfatiza ser el primero en la mainnet de ZK. Publican hojas de ruta (su blog de hoja de ruta para 2025) para mantener alta la emoción. Si consideramos los fondos del ecosistema: aparte de las subvenciones directas de Matter Labs, también está la Fundación Ethereum y otros fondos centrados en ZK que favorecen el desarrollo de zkSync debido a la importancia general de la tecnología ZK. Otra estrategia: zkSync es de código abierto y neutral (sin tarifas de licencia), lo que atrae a proyectos que podrían ser cautelosos de alinearse con un ecosistema más centralizado. El ZK Stack está tratando de posicionarse como la elección del descentralizador – por ejemplo, destacando la descentralización total y sin ruedas de entrenamiento, mientras que OP Stack y otros todavía tienen algo de centralización en la práctica. El tiempo dirá si eso resuena, pero ciertamente dentro de la comunidad de Ethereum, zkSync tiene partidarios que quieren una pila completamente sin confianza. Finalmente, Matter Labs y Windranger de BitDAO tienen una iniciativa conjunta llamada "ZK DAO" que podría desplegar capital o incentivos para la adopción de ZK Stack. En general, los esfuerzos del ecosistema de zkSync son una mezcla de mensajes de superioridad técnica (ZK es el futuro) y la construcción de puentes prácticos (tanto figurativos como literales) para que los proyectos se incorporen.

  • Ecosistema de Arbitrum Orbit: Arbitrum tiene un enorme ecosistema existente en su L2 (Arbitrum One), con el TVL de DeFi más alto entre las L2s en 2024. Offchain Labs aprovecha esto alentando a las dApps exitosas de Arbitrum a considerar las cadenas Orbit para sub-aplicaciones o expansiones L3. Anunciaron que más de 50 cadenas Orbit estaban en desarrollo a finales de 2023, esperando quizás más de 100 para finales de 2024 – lo que indica un interés sustancial. Para nutrir esto, Offchain Labs adoptó algunas estrategias. Primero, asociaciones con proveedores de RaaS: Se dieron cuenta de que no todos los equipos pueden manejar la infraestructura de rollup, por lo que reclutaron a Caldera, Conduit y AltLayer para simplificarlo. Estos socios a menudo tienen sus propios programas de subvenciones o incentivos (a veces copatrocinados por Arbitrum) para atraer proyectos. Por ejemplo, podría haber una subvención Arbitrum x AltLayer para cadenas de juegos. Segundo, Offchain Labs proporciona soporte técnico directo y co-desarrollo para proyectos clave. El caso de Xai Chain es ilustrativo: es una L3 de juegos donde Offchain Labs co-desarrolló la cadena y proporciona soporte técnico y de marketing continuo. Básicamente ayudaron a incubar Xai para mostrar el potencial de Orbit en los juegos. De manera similar, la cadena RARI NFT de Rarible se integró con muchos socios (Gelato para transacciones sin gas, LayerZero para NFTs entre cadenas, etc.) presumiblemente con la guía de Arbitrum. Offchain Labs también utiliza a veces su cofre de guerra (la DAO de Arbitrum tiene una enorme tesorería de tokens ARB) para financiar iniciativas. Si bien la DAO de Arbitrum es independiente, Offchain Labs puede coordinarse con ella para asuntos del ecosistema. Por ejemplo, si una cadena Orbit usa mucho el token ARB o beneficia a Arbitrum, la DAO podría votar subvenciones. Sin embargo, un enfoque más directo: Offchain Labs lanzó hackatones y premios del Desafío Arbitrum Orbit para alentar a los desarrolladores a intentar crear L3s. En marketing: la marca de Arbitrum está enfocada en los desarrolladores, y promueven las ventajas de Orbit como Stylus (contratos rápidos y multi-lenguaje) y la ausencia de retiro de 7 días (con puentes rápidos). También destacan ejemplos exitosos: por ejemplo, Bridgeworld de Treasure DAO anunció una cadena Orbit, etc. Un ángulo de soporte más: integración de liquidez y DeFi. Arbitrum está trabajando con protocolos para que si lanzas una cadena Orbit, puedas acceder a la liquidez de Arbitrum One fácilmente (a través de puentes nativos o LayerZero). Cuanto más fácil sea mover activos y usuarios a tu nueva cadena, más probable es que tengas éxito. Arbitrum tiene una comunidad muy grande y activa (en Reddit, Discord, etc.), y al extender eso a Orbit, las nuevas cadenas pueden comercializar a los usuarios existentes de Arbitrum (por ejemplo, un usuario de Arbitrum podría recibir un airdrop en una nueva cadena Orbit para probarla). En resumen, la estrategia del ecosistema de Arbitrum para Orbit se trata de aprovechar su dominio en L2 – si construyes una L3, eres efectivamente una extensión de la L2 más grande, por lo que compartes ese efecto de red. Offchain Labs está eliminando activamente los obstáculos (técnicos y de liquidez) e incluso ayudando directamente a construir algunas de las primeras L3s para sentar precedentes para que otros sigan.

  • Ecosistema de Polygon CDK (AggLayer): Polygon ha sido uno de los más agresivos en el desarrollo de ecosistemas y negocios. Tienen un enfoque multifacético:

    • Subvenciones y Fondos: Polygon estableció un Fondo de Ecosistema de $100M hace un tiempo, y ha invertido en cientos de proyectos. También tuvieron fondos verticales específicos (por ejemplo, Fondo de Juegos de Polygon, Fondo DeFi de Polygon). Para las cadenas CDK, Polygon anunció incentivos como cubrir parte del costo de operar una cadena o proporcionar soporte de liquidez. Las estadísticas de CoinLaw mencionan que "Más de 190 dApps están aprovechando Polygon CDK para construir sus propias cadenas" – lo que implica que Polygon ha conseguido una vasta cartera de proyectos (probablemente muchos todavía en desarrollo). Es probable que hayan ofrecido subvenciones o compartido recursos con estos equipos.
    • Incorporación de Empresas e Instituciones: El equipo de BizDev de Polygon ha incorporado a grandes empresas (Starbucks, Reddit, Nike, Disney para NFTs en Polygon POS). Ahora con CDK, proponen a las empresas lanzar cadenas dedicadas. Por ejemplo, Immutable (plataforma de juegos) se asoció para usar CDK para cadenas específicas de juegos, Franklin Templeton lanzó un fondo en Polygon, y la prueba de Walmart de una cadena de suministro en una cadena privada de Polygon. Polygon proporciona soporte de guante blanco a estos socios: consultoría técnica, desarrollo de características personalizadas (privacidad, cumplimiento) y co-marketing. La introducción de Libre (por JP Morgan/Siemens) construida en Polygon CDK muestra cómo atienden a las instituciones financieras con necesidades especializadas.
    • Salida al Mercado e Interoperabilidad: Polygon está creando el AggLayer como un centro de interoperabilidad y liquidez que conecta todas las cadenas de Polygon. Esto significa que si lanzas una cadena CDK, no estás solo – te conviertes en parte de "Polygon 2.0", una constelación de cadenas con liquidez unificada. Prometen cosas como la transferencia de tokens con un solo clic entre cadenas CDK y Ethereum (a través de AggLayer). Tampoco cobran ninguna tarifa de protocolo (sin renta), lo que promocionan como una ventaja competitiva contra, digamos, el reparto de tarifas de Optimism. El marketing de Polygon destaca que lanzar una cadena CDK puede darte "lo mejor de ambos mundos": soberanía y rendimiento personalizados más acceso a la gran base de usuarios y desarrolladores de Polygon/Ethereum. A menudo citan que Polygon (POS+zkEVM) combinado procesó más del 30% de todas las transacciones de L2, para asegurar a los potenciales constructores de cadenas que el flujo de usuarios en Polygon es enorme.
    • Soporte para Desarrolladores: Polygon organiza quizás la mayor cantidad de hackatones y eventos de DevRel en el espacio blockchain. Tienen una Universidad de Polygon dedicada, cursos en línea, y frecuentemente patrocinan ETHGlobal y otros hackatones con desafíos en torno al uso de CDK, zkEVM, etc. Así que los desarrolladores pueden ganar premios construyendo prototipos de cadenas CDK o dapps entre cadenas. También mantienen una fuerte presencia en las comunidades de desarrolladores y proporcionan soporte rápido (el Discord de Polygon tiene canales para preguntas técnicas donde los desarrolladores principales responden).
    • Comunidad y Gobernanza: Polygon está en transición a Polygon 2.0 con un nuevo token POL y una gobernanza comunitaria que abarca todas las cadenas. Esto podría significar tesorerías comunitarias o programas de incentivos que se aplican a las cadenas CDK. Por ejemplo, puede haber un programa de Minería del Ecosistema de Polygon donde se ofrecen recompensas de minería de liquidez a proyectos que se despliegan en nuevas cadenas CDK para impulsar el uso. La idea es asegurar que las nuevas cadenas no sean pueblos fantasmas.
    • Casos de Éxito: Ya, varias cadenas CDK están en vivo o anunciadas: OKB Chain (X Layer) de OKX, la cadena de Gnosis Pay, el zkEVM de Astar, la migración de Palm Network, GameSwift (cadena de juegos), etc. Polygon publicita activamente estos y comparte el conocimiento de ellos con otros.

En general, la estrategia de Polygon es "haremos lo que sea necesario para ayudarte a tener éxito si construyes en nuestra pila". Eso incluye incentivos financieros, mano de obra técnica, exposición de marketing (espacios para hablar en conferencias, comunicados de prensa en CoinTelegraph como vimos), e integración en un ecosistema más grande. Es un enfoque muy impulsado por el desarrollo de negocios además de la comunidad de desarrolladores de base, reflejando el estilo más corporativo de Polygon en relación con los demás.

Para resumir el soporte del ecosistema: Todos estos frameworks entienden que atraer a desarrolladores y proyectos requiere más que tecnología – necesita financiación, acompañamiento e integración en una narrativa más amplia. Optimism impulsa una narrativa colaborativa centrada en bienes públicos con un reparto justo de ingresos. zkSync impulsa el ángulo de la tecnología de vanguardia y probablemente anunciará incentivos alineados con un futuro token. Arbitrum aprovecha su dominio existente y proporciona redes de socios para facilitar el lanzamiento, además de posiblemente la liquidez DeFi más profunda para aprovechar. Polygon posiblemente va más allá en allanar el camino tanto para los jugadores cripto-nativos como para los empresariales, subsidiando y co-mercadeando cadenas de manera efectiva.

Una instantánea comparativa ilustrativa:

FrameworkProgramas Notables del EcosistemaSoporte para Desarrolladores/SociosTamaño del Ecosistema (2025)
OP Stack (Optimism)Subvenciones RetroPGF (token OP); reparto de tarifas de Superchain para bienes públicos; Múltiples olas de subvenciones para herramientas y dapps.OP Labs ofrece soporte técnico directo a nuevas cadenas (ej. Base); fuerte comunidad de desarrolladores; marca e interoperabilidad de Superchain para atraer usuarios. Hackatones regulares (a menudo pistas patrocinadas por Optimism).Mainnet de Optimism ~160+ dapps, Base ganando tracción, 5+ Cadenas OP en vivo (Base, opBNB, Worldcoin, Zora, otras) y más anunciadas (Celo). Ingresos compartidos de +$14k ETH al Colectivo. Gran comunidad a través de los usuarios de Optimism y Coinbase.
ZK Stack de zkSyncFondo del Ecosistema de zkSync (>$200M recaudados para financiación de desarrolladores); posibles futuros airdrops; programas verticales específicos (ej. juegos, agentes de IA en Hyperchains).Matter Labs proporciona incorporación técnica para los primeros pilotos de Hyperchain; documentación detallada y código de fuente abierta. Asociado con protocolos de puente para la conectividad. Incentivos para desarrolladores principalmente a través de hackatones e inversiones de VC (aún no hay incentivos de token).zkSync Era L2 tiene más de 160 protocolos, ~$100M de TVL. Primeras hyperchains en prueba (aún no hay L3 importantes en vivo). El interés empresarial señala un crecimiento futuro (ej. piloto con un gran banco). Fuerte comunidad de desarrolladores ZK y reconocimiento creciente.
Arbitrum OrbitTesorería de ARBdelaDAOdeArbitrum(ARB de la DAO de Arbitrum (3B+) para posibles subvenciones; asociación de Offchain Labs con RaaS (Caldera, AltLayer) subsidiando lanzamientos de cadenas; programas de Aceleradora Orbit.Offchain Labs co-desarrolló cadenas Orbit emblemáticas (Xai, etc.); ayuda con el marketing (Binance Launchpad para el token de Xai). Soporte para desarrolladores a través de la extensa documentación de Arbitrum y ayuda directa de ingeniería para la integración (Stylus, gas personalizado). Soporte de puente rápido para la experiencia del usuario.Arbitrum One: el TVL de L2 más grande (~$5B); ~50 cadenas Orbit en desarrollo a finales de 2023, ~16 lanzadas a principios de 2025. Cadenas en vivo notables: Xai, Rari Chain, Frame, etc. El ecosistema pesado en DeFi en L2 puede extender la liquidez a las L3s. Comunidad grande y leal (el airdrop de Arbitrum tuvo >250k participantes).
Polygon CDK (AggLayer)Fondo del Ecosistema de Polygon y muchos fondos verticales (NFTs, juegos, empresas); Tesorería de Polygon 2.0 para incentivos; oferta para cubrir ciertos costos de infraestructura para nuevas cadenas. Se esperan programas de liquidez/recompensa de AggLayer.El equipo de Polygon Labs trabaja estrechamente con socios (ej. Immutable, empresas) para necesidades personalizadas; extenso devrel (Universidad de Polygon, hackatones, tutoriales). Integración de cadenas CDK con la infraestructura zkEVM y PoS de Polygon (billeteras compartidas, puentes). Marketing a través de grandes asociaciones de marca (casos de estudio públicos de Nike, Reddit en Polygon) para dar credibilidad.Polygon PoS: gran adopción (más de 4B de transacciones); Polygon zkEVM creciendo (más de 100 dapps). CDK: más de 20 cadenas en mainnet o testnet para finales de 2024. ~190 proyectos explorando CDK. Adopción empresarial notable (instituciones financieras, gigantes minoristas). Uno de los ecosistemas de desarrolladores más grandes debido a la historia de Polygon PoS, ahora canalizado hacia CDK.

Como sugiere la tabla, cada ecosistema tiene sus fortalezas – Optimism con un ethos colaborativo y el peso de Coinbase, zkSync con liderazgo en ZK y enfoque en la innovación, Arbitrum con adopción probada y destreza técnica (Stylus), Polygon con conexiones corporativas y soporte integral. Todos están invirtiendo recursos significativos en hacer crecer sus comunidades, porque en última instancia, el éxito de un framework de rollup se mide por las aplicaciones y los usuarios en las cadenas construidas con él.

Despliegues y Adopción en 2025

Finalmente, veamos dónde se encuentran estos frameworks en términos de adopción en el mundo real a partir de 2025 – tanto en el contexto cripto-nativo (redes públicas, proyectos de DeFi/NFT/juegos) como en el uso empresarial o institucional:

  • Adopción de OP Stack: El OP Stack ha impulsado Optimism Mainnet, que en sí misma es una de las principales L2 de Ethereum con un próspero ecosistema DeFi (Uniswap, Aave, etc.) y decenas de miles de usuarios diarios. En 2023–2024, OP Stack fue elegido por Coinbase para su red Base – Base se lanzó en agosto de 2023 y rápidamente incorporó aplicaciones populares (la propia integración de billetera de Coinbase, la aplicación social friend.tech) y alcanzó una alta actividad (a veces incluso superando a Optimism en transacciones). El éxito de Base validó OP Stack para muchos; Base tuvo 800 millones de transacciones en 2024, convirtiéndola en la segunda cadena con mayor número de transacciones ese año. Otro despliegue importante de OP Stack es opBNB – el equipo de BNB Chain de Binance creó una L2 usando OP Stack (pero liquidando en BNB Chain en lugar de Ethereum). opBNB se puso en marcha en 2023, lo que indica la flexibilidad de OP Stack para usar una liquidación no-Ethereum. La cadena World ID de Worldcoin se lanzó en OP Stack (liquidando en Ethereum) en 2023 para manejar sus transacciones de identidad biométrica únicas. Zora Network, una cadena centrada en NFT de Zora, también se lanzó en OP Stack, adaptada para casos de uso de la economía de creadores. Quizás la más ambiciosa es la migración de Celo: Celo votó para pasar de ser una L1 independiente a una L2 de Ethereum construida en OP Stack – a partir de 2025, esta migración está en marcha, trayendo efectivamente todo un ecosistema existente (las aplicaciones DeFi y centradas en teléfonos de Celo) al redil de OP Stack. También tenemos proyectos más pequeños como Mode (la cadena lateral de Bybit), Mantle (la cadena de BitDAO) – en realidad, Mantle también optó por un OP Stack modificado. Y muchos más están rumoreados o en desarrollo, dado el enfoque de código abierto de Optimism (cualquiera puede bifurcar y lanzar sin permiso). En el lado empresarial, no hemos visto mucha cadena empresarial explícita de OP Stack (las empresas parecen más atraídas por Polygon o soluciones personalizadas). Sin embargo, Base es un respaldo empresarial (Coinbase), y eso es significativo. La visión de la Superchain implica que incluso las cadenas empresariales podrían unirse como Cadenas OP para beneficiarse de la gobernanza compartida – por ejemplo, si alguna fintech quisiera lanzar una cadena compatible, usar OP Stack y conectarse a la Superchain podría darle conectividad lista. A partir de 2025, las cadenas de OP Stack colectivamente (Optimism, Base, otras) manejan una porción significativa de la actividad de L2, y el rendimiento agregado de la Superchain se presenta como una métrica (Optimism a menudo publica estadísticas combinadas). Con la actualización Bedrock y mejoras adicionales, las cadenas de OP Stack están demostrando una alta fiabilidad (Optimism tuvo un tiempo de inactividad insignificante). La medida clave de adopción: OP Stack es posiblemente el framework de rollup más bifurcado hasta ahora, dados Base, BNB, Celo, etc., que son de alto perfil. En total, ~5-10 cadenas de OP Stack están en mainnets en vivo, y muchas más en testnets. Si incluimos devnets y próximos lanzamientos, el número crece.

  • Adopción de Hyperchains de zkSync: La mainnet de zkSync Era (L2) se lanzó en marzo de 2023 y para 2025 está entre los principales ZK rollups, con ~$100M de TVL y docenas de proyectos. Aplicaciones notables como Curve, Uniswap, Chainlink se desplegaron o anunciaron su despliegue en zkSync. Ahora, con respecto a las Hyperchains (cadenas L3 o soberanas), esto es muy vanguardista. A finales de 2024, Matter Labs lanzó un programa para que los equipos experimentaran con L3s sobre zkSync. Un ejemplo: el proveedor de Rollup-as-a-Service Decentriq estaba probando una Hyperchain privada para compartir datos. Además, Blockchain Capital (VC) insinuó estar experimentando con una L3. Se menciona que un ecosistema de más de 18 protocolos está aprovechando ZK Stack para cosas como agentes de IA y casos de uso especializados – posiblemente en testnets. Ninguna Hyperchain importante está sirviendo públicamente a los usuarios todavía (hasta donde se sabe a mediados de 2025). Sin embargo, el interés es alto en dominios específicos: los proyectos de juegos han mostrado interés en las hyperchains ZK por su finalidad rápida y personalización, y las cadenas orientadas a la privacidad (una Hyperchain podría incluir cifrado y usar pruebas ZK para ocultar datos – algo que un rollup optimista no puede ofrecer tan fácilmente). El comentario sobre un "banco suizo" sugiere que quizás UBS o un consorcio está probando una cadena privada usando ZK Stack, probablemente atraído por el rendimiento (~10k TPS) y la privacidad. Si eso pasa a producción, sería un caso empresarial emblemático. En resumen, la adopción de Hyperchains de zkSync en 2025 se encuentra en una etapa piloto temprana: la infraestructura para desarrolladores está lista (como lo demuestra la documentación y algunos despliegues de prueba), pero estamos esperando que los primeros en moverse se pongan en marcha. Es comparable a donde estaba Optimism a principios de 2021 – tecnología probada pero apenas comenzando la adopción. Para finales de 2025, podríamos esperar un par de Hyperchains en vivo, posiblemente una impulsada por la comunidad (quizás una Hyperchain de juegos surgida de un juego popular de zkSync) y una impulsada por una empresa. Otro factor: también se habla de Layer3s en zkSync Era – esencialmente L3s sin permisos donde cualquiera puede desplegar una app-chain sobre la L2 de zkSync. Matter Labs ha construido los contratos para permitir eso, por lo que podemos ver L3s impulsadas por los usuarios (como alguien que lanza un mini rollup para su aplicación específica) lo que cuenta como adopción del ZK Stack.

  • Adopción de Arbitrum Orbit: Arbitrum Orbit vio un aumento de interés después de su introducción formal a mediados de 2023. A finales de 2023, alrededor de 18 cadenas Orbit fueron divulgadas públicamente, y Offchain Labs indicó más de 50 en progreso. A partir de 2025, algunas de las más prominentes son:

    • Xai Chain: Una L3 centrada en juegos, ahora en vivo (mainnet lanzada a finales de 2023). Es utilizada por desarrolladores de juegos (como el estudio Ex Populus) y tuvo un lanzamiento de token a través de Binance Launchpad. Esto indica una adopción decente (la participación de Binance Launchpad sugiere mucho interés de los usuarios). Xai usa el modo AnyTrust (para un alto TPS).
    • Rari Chain: Una L3 centrada en NFT de Rarible. Lanzó mainnet en enero de 2024. Se enfoca en mercados de NFT con características como pagos con tarjeta de crédito para el gas (a través de Stripe) y listados sin gas. Esta cadena es un buen escaparate de la personalización de la experiencia del usuario (como se señaló, Gelato proporciona transacciones sin gas, etc. en Rari Chain).
    • Frame: Una L2 centrada en creadores (aunque llamada L2, es probable que sea una cadena Orbit que se liquida en Ethereum o Arbitrum). Se lanzó a principios de 2024 después de recaudar fondos.
    • EduChain (por las comunidades de Camelot/GMX): El artículo de Zeeve menciona una cadena EDU con un gran número de proyectos – posiblemente un ecosistema para la educación en cadena y la IA, construido en Orbit.
    • Ape Chain: No se menciona explícitamente arriba, pero el contexto de Zeeve sugiere que existe una "cadena Ape" (quizás de Yuga Labs o la DAO de ApeCoin) con $9.86M de TVL y usa APE para el gas. Esa podría ser una cadena Orbit en el ecosistema de ApeCoin (esto sería significativo dada la influencia de Yuga en los NFTs).
    • Otras cadenas de juegos: por ejemplo, se anunció la L3 "Muster" de Cometh (una plataforma de juegos asociada con AltLayer). Syndr Chain para un protocolo de trading de opciones está en testnet como L3 de Orbit. Meliora (protocolo de crédito DeFi) construyendo una L3 de Orbit.
    • Muchas de estas están en etapas tempranas (testnet o mainnet recién lanzada), pero colectivamente indican que Orbit está ganando adopción entre dApps especializadas que superaron un entorno L2 compartido o querían su propia gobernanza.
    • En cuanto a empresas: no hay tanto ruido aquí. Arbitrum es más conocido por la adopción en DeFi/juegos. Sin embargo, la tecnología podría atraer a las empresas si quieren una cadena asegurada por Ethereum con confianza flexible (a través de AnyTrust). Es posible que alguna empresa haya usado silenciosamente la tecnología de Arbitrum para una cadena privada, pero no lo ha publicitado.
    • En cifras, el mayor usuario de Arbitrum Orbit hasta ahora podría ser Ape Chain (si se confirma) con ~$10M de TVL y 17 protocolos en ella (según Zeeve). Otro es EDU chain con 1.35M de TVL y más de 30 proyectos.
    • Arbitrum One y Nova son parte de esta narrativa – el hecho de que las cadenas Orbit puedan liquidarse en Nova (cadena social/de juegos ultra barata) o en One significa que la adopción de Orbit también impulsa la actividad a esas redes. Nova ha visto uso para los puntos de Reddit, etc. Si las cadenas Orbit se conectan al comité AnyTrust de Nova, el papel de Nova crece.
    • En resumen, Arbitrum Orbit ha pasado de la teoría a la práctica: docenas de proyectos reales están construyendo sobre él, enfocándose en juegos, redes sociales y DeFi personalizado. El enfoque de Arbitrum de mostrar casos de uso reales (como Xai, Rari) ha dado sus frutos, y podemos esperar que para finales de 2025 haya posiblemente más de 50 cadenas Orbit en vivo, algunas con bases de usuarios significativas (especialmente si una de las cadenas de juegos logra un lanzamiento de juego popular).
  • Adopción de Polygon CDK: Polygon solo anunció CDK en la segunda mitad de 2023, pero se apoya en el éxito de las redes existentes de Polygon. Ya, Polygon zkEVM (beta de mainnet) es esencialmente una cadena CDK operada por Polygon Labs. Ha visto una adopción decente (más de $50M de TVL, protocolos importantes desplegados). Pero más allá de eso, numerosas cadenas independientes están en movimiento:

    • Immutable X (una gran plataforma de juegos Web3) declaró su apoyo a Polygon CDK para permitir que los estudios de juegos creen sus propios zk-rollups que se conectan a la liquidez de Immutable y Polygon. Esta alianza significa posiblemente docenas de juegos usando CDK a través de Immutable en 2025.
    • OKX (exchange) lanzó OKB Chain (también conocida como X Chain) usando Polygon CDK a finales de 2024. Una cadena de exchange puede generar muchas transacciones (flujos de cex a dex, etc.). OKX eligió Polygon presumiblemente por la escalabilidad y porque muchos de sus usuarios ya usan Polygon.
    • Canto (cadena DeFi) y Astar (cadena lateral de Polkadot) se mencionan como migrando o integrándose con Polygon CDK. El movimiento de Canto de Cosmos a la capa de Polygon indica el atractivo de compartir la seguridad con Ethereum a través del ZK de Polygon.
    • Gnosis Pay: lanzó la cadena Gnosis Card con CDK – es una cadena para permitir pagos rápidos con stablecoins conectados a una tarjeta Visa. Esto está en vivo y es un uso fintech innovador.
    • Palm Network: una cadena especializada en NFT originalmente en Ethereum se está moviendo a Polygon CDK (Palm fue cofundada por ConsenSys para NFTs con DC Comics, etc.).
    • dYdX: Esto es interesante – dYdX estaba construyendo su propia cadena Cosmos, pero la información de Zeeve lista a dYdX bajo las cadenas CDK de AggLayer. Si dYdX considerara Polygon en su lugar, sería enorme (aunque según la información conocida, dYdX V4 se basa en Cosmos; quizás planean una cadena cruzada o un pivote futuro).
    • Nubank: uno de los bancos digitales más grandes de Brasil, aparece en la lista de Zeeve. Nubank había lanzado un token en Polygon anteriormente; una cadena CDK para sus recompensas o un programa similar a CBDC podría estar en pruebas.
    • Wirex, IDEX, GameSwift, Aavegotchi, Powerloom, Manta… estos nombres en la lista de Zeeve muestran cuán transversal es el alcance de CDK: por ejemplo, Manta (un proyecto de privacidad de Polkadot) podría usar CDK para una solución ZK orientada a Ethereum; Aavegotchi (un juego NFT originalmente en Polygon POS) podría obtener su propia cadena para la lógica del juego.
    • La integración con Celestia a principios de 2024 probablemente atraerá a proyectos que quieren la tecnología de Polygon pero con Celestia DA – posiblemente algunos proyectos de Cosmos (ya que Celestia se basa en Cosmos) elegirán Polygon CDK para la ejecución y Celestia para la DA.
    • Empresas: Polygon tiene un equipo empresarial dedicado. Aparte de los mencionados (Stripe en stablecoins, el fondo de Franklin Templeton en Polygon, gobiernos de países acuñando sellos, etc.), con CDK pueden prometer a las empresas su propia cadena con reglas personalizadas. Podríamos ver pilotos como la "Cadena Polygon Siemens" o cadenas gubernamentales emergiendo, aunque a menudo comienzan siendo privadas.
    • El enfoque de Polygon de ser agnóstico a la cadena (¡incluso soportan un "modo OP Stack" ahora en CDK según Zeeve!) y no cobrar renta, ha significado una rápida incorporación – afirman que más de 190 proyectos usan o consideran CDK para el primer trimestre de 2025. Si incluso una cuarta parte de ellos se pone en marcha, Polygon tendrá una red expansiva de cadenas. Se visualizan no solo como una cadena, sino como un ecosistema de muchas cadenas (Polygon 2.0), posiblemente la red más grande de este tipo si tiene éxito.
    • En cifras: a principios de 2025, más de 21 cadenas están en mainnet o testnet usando CDK según el sitio de AggLayer. Esto debería acelerarse a lo largo de 2025 a medida que más migren o se lancen.
    • Podemos esperar algunos lanzamientos de alto perfil, por ejemplo, una cadena de Reddit (los avatares de Reddit en Polygon POS fueron enormes; una L2 de Polygon dedicada para Reddit podría suceder). Además, si alguna moneda digital de banco central (CBDC) o proyecto gubernamental elige una solución de escalado, Polygon a menudo está en esas conversaciones – una cadena CDK podría ser su elección para una L2 con permisos con pruebas zk.

En resumen, el estado de adopción en 2025: OP Stack y Arbitrum Orbit tienen múltiples cadenas en vivo con usuarios reales y TVL, las hyperchains de zkSync están a punto de despegar con fuertes pilotos de prueba, y Polygon CDK tiene muchos en fila y algunos éxitos en vivo tanto en el ámbito cripto como empresarial. El espacio está evolucionando rápidamente, y los proyectos a menudo consideran cruzadamente estos frameworks antes de elegir. Tampoco es un juego de suma cero – por ejemplo, una aplicación podría usar una cadena de OP Stack y una cadena de Polygon CDK para diferentes regiones o propósitos. El futuro de la blockchain modular probablemente implica la interoperabilidad entre todos estos frameworks. Es notable que esfuerzos como LayerZero y los agregadores de puentes ahora aseguran que los activos se muevan con relativa libertad entre Optimism, Arbitrum, Polygon, zkSync, etc., por lo que los usuarios podrían ni siquiera darse cuenta de en qué pila está construida una cadena bajo el capó.

Conclusión

Rollups como Servicio en 2025 ofrece un rico menú de opciones. OP Stack proporciona un framework de rollup optimista probado en batalla con alineación con Ethereum y el respaldo de una comunidad colaborativa de Superchain. ZK Stack (Hyperchains) ofrece tecnología de conocimiento cero de vanguardia con validez modular y opciones de datos, apuntando a una escalabilidad masiva y nuevos casos de uso como cadenas privadas o de Capa 3. Arbitrum Orbit extiende una arquitectura de rollup optimista altamente optimizada a los desarrolladores, con flexibilidad en la disponibilidad de datos y la emocionante adición de Stylus para contratos inteligentes multi-lenguaje. Polygon CDK empodera a los proyectos para lanzar cadenas zkEVM con interoperabilidad lista para usar (AggLayer) y el soporte completo del ecosistema y los lazos empresariales de Polygon. Las Hyperchains de zkSync (a través de ZK Stack) prometen desbloquear la Web3 a escala – múltiples hyperchains todas aseguradas por Ethereum, cada una optimizada para su dominio (ya sea juegos, DeFi o social), con conectividad perfecta a través del framework Elástico de zkSync.

Al comparar la disponibilidad de datos, vimos que todos los frameworks adoptan la DA modular – Ethereum por seguridad, y soluciones más nuevas como Celestia, EigenDA o comités por rendimiento. Los diseños de secuenciadores son inicialmente centralizados pero se mueven hacia la descentralización: Optimism y Arbitrum proporcionan colas de respaldo en L1 y están habilitando modelos de multi-secuenciador o validadores sin permisos, mientras que Polygon y zkSync permiten el despliegue de consenso personalizado para las cadenas que lo deseen. Los modelos de tarifas difieren principalmente en la filosofía del ecosistema – el reparto de ingresos de Optimism frente a las economías autónomas de otros – pero todos permiten tokens personalizados y apuntan a minimizar los costos para el usuario aprovechando una DA más barata y una finalidad rápida (especialmente las cadenas ZK).

En cuanto al soporte del ecosistema, Optimism fomenta un colectivo donde cada cadena contribuye a objetivos compartidos (financiación de bienes públicos) y se beneficia de actualizaciones compartidas. Arbitrum aprovecha su próspera comunidad y liquidez, ayudando activamente a los proyectos a lanzar cadenas Orbit e integrándolas con su centro DeFi. Polygon va con todo con recursos, cortejando tanto a proyectos cripto como a corporaciones, proporcionando quizás el soporte más práctico y presumiendo de una extensa red de asociaciones y fondos. Matter Labs (zkSync) impulsa la innovación y atrae a aquellos que quieren la última tecnología ZK, y aunque sus programas de incentivos están menos estructurados públicamente (pendiente de un token), tiene una financiación significativa para desplegar y un fuerte atractivo para los constructores con mentalidad ZK.

Desde la perspectiva de un desarrollador, lanzar un rollup en 2025 es más accesible que nunca. Ya sea que la prioridad de uno sea la equivalencia con EVM y la facilidad (OP Stack, Arbitrum) o el máximo rendimiento y la tecnología a prueba de futuro (ZK Stack, Polygon CDK), las herramientas y la documentación están en su lugar. Incluso el monitoreo y las herramientas de desarrollo han crecido para soportar estas cadenas personalizadas – por ejemplo, las plataformas RaaS de Alchemy y QuickNode soportan las pilas de Optimism, Arbitrum y zkSync de fábrica. Esto significa que los equipos pueden centrarse en su aplicación y dejar gran parte del trabajo pesado a estos frameworks.

Mirando la adopción pública y empresarial, está claro que los rollups modulares están pasando de ser experimentales a ser la corriente principal. Tenemos marcas globales como Coinbase, Binance y OKX ejecutando sus propias cadenas, protocolos DeFi importantes como Uniswap expandiéndose a múltiples L2s y posiblemente sus propios rollups, e incluso gobiernos y bancos explorando estas tecnologías. La competencia (y colaboración) entre OP Stack, ZK Stack, Orbit, CDK, etc., está impulsando una rápida innovación – beneficiando en última instancia a Ethereum al escalarlo para llegar a millones de nuevos usuarios a través de rollups personalizados.

Cada framework tiene su propuesta de valor única:

  • OP Stack: Fácil entrada a L2, efectos de red compartidos de la Superchain y una filosofía de "impacto = beneficio" a través de bienes públicos.
  • ZK Stack: Escalabilidad final con integridad ZK, flexibilidad en el diseño (L2 o L3, rollup o validium) y prevención de la fragmentación de la liquidez a través del modelo de cadena Elástica.
  • Arbitrum Orbit: Tecnología probada (Arbitrum One nunca tuvo una falla importante), alto rendimiento (Nitro + Stylus) y la capacidad de personalizar las suposiciones de confianza (seguridad completa de rollup o AnyTrust más rápido) para diferentes necesidades.
  • Polygon CDK: ZK-rollups llave en mano respaldados por uno de los ecosistemas más grandes, con conectividad inmediata a los activos de Polygon/Ethereum y la promesa de una futura "liquidez unificada" a través de AggLayer – efectivamente una plataforma de lanzamiento no solo para una cadena, sino para toda una economía en esa cadena.
  • Hyperchains de zkSync: Una visión de escalabilidad de Capa 3 donde incluso las aplicaciones pequeñas pueden tener su propia cadena asegurada por Ethereum, con una sobrecarga mínima, permitiendo un rendimiento a nivel de Web2 en un entorno Web3.

A mediados de 2025, estamos viendo materializarse el ecosistema modular multi-cadena: docenas de cadenas específicas de aplicaciones o sectores coexistiendo, muchas construidas con estas pilas. L2Beat y sitios similares ahora rastrean no solo L2s sino L3s y cadenas personalizadas, muchas de las cuales usan OP Stack, Orbit, CDK o ZK Stack. Se están desarrollando estándares de interoperabilidad para que, ya sea que una cadena use la tecnología de Optimism o Polygon, puedan comunicarse entre sí (proyectos como Hyperlane, LayerZero e incluso la colaboración de OP y Polygon en la secuenciación compartida).

En conclusión, Rollups como Servicio en 2025 ha madurado en un panorama competitivo con OP Stack, ZK Stack, Arbitrum Orbit, Polygon CDK e Hyperchains de zkSync, cada uno ofreciendo frameworks de blockchain robustos y modulares. Difieren en el enfoque técnico (Optimista vs. ZK), pero todos tienen como objetivo empoderar a los desarrolladores para lanzar cadenas escalables y seguras adaptadas a sus necesidades. La elección de la pila puede depender de las prioridades específicas de un proyecto – compatibilidad con EVM, velocidad de finalidad, personalización, alineación con la comunidad, etc. – como se describió anteriormente. La buena noticia es que no hay escasez de opciones o soporte. La hoja de ruta centrada en rollups de Ethereum se está realizando a través de estos frameworks, anunciando una era en la que lanzar una nueva cadena no es una hazaña monumental, sino una decisión estratégica similar a elegir un proveedor de nube o una pila tecnológica en Web2. Los frameworks continuarán evolucionando (por ejemplo, anticipamos más convergencia, como OP Stack adoptando pruebas ZK, el AggLayer de Polygon conectándose a cadenas no-Polygon, etc.), pero incluso ahora aseguran colectivamente que la escalabilidad y el crecimiento del ecosistema de Ethereum están limitados solo por la imaginación, no por la infraestructura.

Fuentes:

  • Optimism OP Stack – Documentación y publicaciones en Mirror
  • zkSync ZK Stack – Documentación de zkSync y publicaciones de Matter Labs
  • Arbitrum Orbit – Documentación de Arbitrum, anuncios de Offchain Labs
  • Polygon CDK – Documentación técnica de Polygon, informe de CoinTelegraph
  • Comparación general – Guías de QuickNode (Mar 2025), Zeeve y otros para estadísticas del ecosistema, además de varios blogs de proyectos citados anteriormente.

Entornos de Ejecución Confiables (TEEs) en el Ecosistema Web3: Un Análisis Profundo

· 82 min de lectura

1. Descripción General de la Tecnología TEE

Definición y Arquitectura: Un Entorno de Ejecución Confiable (TEE) es un área segura de un procesador que protege el código y los datos cargados en su interior con respecto a la confidencialidad y la integridad. En términos prácticos, un TEE actúa como un "enclave" aislado dentro de la CPU, una especie de caja negra donde los cálculos sensibles pueden ejecutarse protegidos del resto del sistema. El código que se ejecuta dentro de un enclave TEE está protegido de tal manera que incluso un sistema operativo o hipervisor comprometido no puede leer ni manipular los datos o el código del enclave. Las propiedades clave de seguridad que proporcionan los TEEs incluyen:

  • Aislamiento: La memoria del enclave está aislada de otros procesos e incluso del kernel del sistema operativo. Incluso si un atacante obtiene privilegios de administrador completos en la máquina, no puede inspeccionar o modificar directamente la memoria del enclave.
  • Integridad: El hardware garantiza que el código que se ejecuta en el TEE no pueda ser alterado por ataques externos. Cualquier manipulación del código del enclave o del estado de ejecución será detectada, evitando resultados comprometidos.
  • Confidencialidad: Los datos dentro del enclave permanecen cifrados en la memoria y solo se descifran para su uso dentro de la CPU, por lo que los datos secretos no se exponen en texto plano al mundo exterior.
  • Atestación Remota: El TEE puede producir pruebas criptográficas (atestaciones) para convencer a una parte remota de que es genuino y que un código de confianza específico se está ejecutando en su interior. Esto significa que los usuarios pueden verificar que un enclave se encuentra en un estado confiable (por ejemplo, ejecutando el código esperado en hardware genuino) antes de proporcionarle datos secretos.

Diagrama conceptual de un Entorno de Ejecución Confiable como un enclave seguro tipo "caja negra" para la ejecución de contratos inteligentes. Las entradas cifradas (datos y código del contrato) se descifran y procesan dentro del enclave seguro, y solo los resultados cifrados salen del enclave. Esto garantiza que los datos sensibles del contrato permanezcan confidenciales para todos fuera del TEE.

Bajo el capó, los TEEs son posibles gracias al cifrado de memoria basado en hardware y al control de acceso en la CPU. Por ejemplo, cuando se crea un enclave TEE, la CPU le asigna una región de memoria protegida y utiliza claves dedicadas (grabadas en el hardware o gestionadas por un coprocesador seguro) para cifrar/descifrar datos sobre la marcha. Cualquier intento de software externo de leer la memoria del enclave solo obtiene bytes cifrados. Esta protección única a nivel de CPU permite que incluso el código a nivel de usuario defina regiones de memoria privadas (enclaves) que el malware privilegiado o incluso un administrador de sistema malicioso no puede espiar o modificar. En esencia, un TEE proporciona un nivel de seguridad más alto para las aplicaciones que el entorno operativo normal, al tiempo que es más flexible que los elementos seguros dedicados o los módulos de seguridad de hardware.

Implementaciones Clave de Hardware: Existen varias tecnologías de TEE de hardware, cada una con diferentes arquitecturas pero con el objetivo similar de crear un enclave seguro dentro del sistema:

  • Intel SGX (Software Guard Extensions): Intel SGX es una de las implementaciones de TEE más utilizadas. Permite a las aplicaciones crear enclaves a nivel de proceso, con cifrado de memoria y controles de acceso aplicados por la CPU. Los desarrolladores deben dividir su código en código "confiable" (dentro del enclave) y código "no confiable" (mundo normal), utilizando instrucciones especiales (ECALL/OCALL) para transferir datos dentro y fuera del enclave. SGX proporciona un fuerte aislamiento para los enclaves y admite la atestación remota a través del Servicio de Atestación de Intel (IAS). Muchos proyectos de blockchain, especialmente Secret Network y Oasis Network, construyeron funcionalidades de contratos inteligentes que preservan la privacidad sobre enclaves SGX. Sin embargo, el diseño de SGX en arquitecturas x86 complejas ha llevado a algunas vulnerabilidades (ver §4), y la atestación de Intel introduce una dependencia de confianza centralizada.

  • ARM TrustZone: TrustZone adopta un enfoque diferente al dividir todo el entorno de ejecución del procesador en dos mundos: un Mundo Seguro y un Mundo Normal. El código sensible se ejecuta en el Mundo Seguro, que tiene acceso a cierta memoria y periféricos protegidos, mientras que el Mundo Normal ejecuta el sistema operativo y las aplicaciones regulares. Los cambios entre mundos son controlados por la CPU. TrustZone se utiliza comúnmente en dispositivos móviles e IoT para cosas como una interfaz de usuario segura, procesamiento de pagos o gestión de derechos digitales. En un contexto de blockchain, TrustZone podría habilitar aplicaciones Web3 orientadas a móviles al permitir que las claves privadas o la lógica sensible se ejecuten en el enclave seguro del teléfono. Sin embargo, los enclaves de TrustZone suelen ser de grano más grueso (a nivel de SO o VM) y no son tan comúnmente adoptados en los proyectos Web3 actuales como SGX.

  • AMD SEV (Secure Encrypted Virtualization): La tecnología SEV de AMD se dirige a entornos virtualizados. En lugar de requerir enclaves a nivel de aplicación, SEV puede cifrar la memoria de máquinas virtuales enteras. Utiliza un procesador de seguridad integrado para gestionar claves criptográficas y realizar el cifrado de memoria para que la memoria de una VM permanezca confidencial incluso para el hipervisor anfitrión. Esto hace que SEV sea muy adecuado para casos de uso en la nube o en servidores: por ejemplo, un nodo de blockchain o un trabajador off-chain podría ejecutarse dentro de una VM totalmente cifrada, protegiendo sus datos de un proveedor de nube malicioso. El diseño de SEV significa menos esfuerzo para el desarrollador para particionar el código (se puede ejecutar una aplicación existente o incluso un sistema operativo completo en una VM protegida). Iteraciones más nuevas como SEV-SNP añaden características como la detección de manipulaciones y permiten a los propietarios de VM atestiguar sus VM sin depender de un servicio centralizado. SEV es muy relevante para el uso de TEE en la infraestructura de blockchain basada en la nube.

Otras implementaciones de TEE emergentes o de nicho incluyen Intel TDX (Trust Domain Extensions, para una protección similar a un enclave en VMs en chips Intel más nuevos), TEEs de código abierto como Keystone (RISC-V), y chips de enclave seguro en móviles (como el Secure Enclave de Apple, aunque generalmente no está abierto para código arbitrario). Cada TEE viene con su propio modelo de desarrollo y supuestos de confianza, pero todos comparten la idea central de la ejecución segura aislada por hardware.

2. Aplicaciones de los TEEs en Web3

Los Entornos de Ejecución Confiables se han convertido en una herramienta poderosa para abordar algunos de los desafíos más difíciles de Web3. Al proporcionar una capa de computación segura y privada, los TEEs habilitan nuevas posibilidades para las aplicaciones de blockchain en áreas de privacidad, escalabilidad, seguridad de oráculos e integridad. A continuación, exploramos los principales dominios de aplicación:

Contratos Inteligentes que Preservan la Privacidad

Uno de los usos más prominentes de los TEEs en Web3 es habilitar contratos inteligentes confidenciales, programas que se ejecutan en una blockchain pero que pueden manejar datos privados de forma segura. Las blockchains como Ethereum son transparentes por defecto: todos los datos de las transacciones y el estado de los contratos son públicos. Esta transparencia es problemática para casos de uso que requieren confidencialidad (por ejemplo, transacciones financieras privadas, votaciones secretas, procesamiento de datos personales). Los TEEs proporcionan una solución al actuar como un enclave de computación que preserva la privacidad conectado a la blockchain.

En un sistema de contratos inteligentes impulsado por TEE, las entradas de las transacciones pueden enviarse a un enclave seguro en un nodo validador o trabajador, procesarse dentro del enclave donde permanecen cifradas para el mundo exterior, y luego el enclave puede emitir un resultado cifrado o hasheado de vuelta a la cadena. Solo las partes autorizadas con la clave de descifrado (o la propia lógica del contrato) pueden acceder al resultado en texto plano. Por ejemplo, Secret Network utiliza Intel SGX en sus nodos de consenso para ejecutar contratos inteligentes CosmWasm sobre entradas cifradas, de modo que cosas como los saldos de las cuentas, los montos de las transacciones o el estado del contrato pueden mantenerse ocultos al público mientras siguen siendo utilizables en los cálculos. Esto ha permitido aplicaciones de DeFi secreto, por ejemplo, intercambios de tokens privados donde los montos son confidenciales, o subastas secretas donde las ofertas están cifradas y solo se revelan después del cierre de la subasta. Otro ejemplo es Parcel de Oasis Network y su ParaTime confidencial, que permiten que los datos se tokenicen y se utilicen en contratos inteligentes bajo restricciones de confidencialidad, habilitando casos de uso como la calificación crediticia o los datos médicos en la blockchain con cumplimiento de la privacidad.

Los contratos inteligentes que preservan la privacidad a través de TEEs son atractivos para la adopción empresarial e institucional de la blockchain. Las organizaciones pueden aprovechar los contratos inteligentes mientras mantienen la lógica empresarial y los datos sensibles confidenciales. Por ejemplo, un banco podría usar un contrato habilitado para TEE para manejar solicitudes de préstamos o liquidaciones de operaciones sin exponer los datos de los clientes en la cadena, pero aún así beneficiarse de la transparencia y la integridad de la verificación de la blockchain. Esta capacidad aborda directamente los requisitos de privacidad regulatorios (como GDPR o HIPAA), permitiendo el uso compatible de la blockchain en la atención médica, las finanzas y otras industrias sensibles. De hecho, los TEEs facilitan el cumplimiento de las leyes de protección de datos al garantizar que los datos personales puedan procesarse dentro de un enclave con solo salidas cifradas, satisfaciendo a los reguladores de que los datos están salvaguardados.

Más allá de la confidencialidad, los TEEs también ayudan a hacer cumplir la equidad en los contratos inteligentes. Por ejemplo, un exchange descentralizado podría ejecutar su motor de emparejamiento dentro de un TEE para evitar que los mineros o validadores vean las órdenes pendientes y realicen front-running de manera injusta. En resumen, los TEEs aportan una muy necesaria capa de privacidad a Web3, desbloqueando aplicaciones como DeFi confidencial, votación/gobernanza privada y contratos empresariales que antes eran inviables en los registros públicos.

Escalabilidad y Computación Off-Chain

Otro papel crítico para los TEEs es mejorar la escalabilidad de la blockchain al descargar cálculos pesados fuera de la cadena a un entorno seguro. Las blockchains tienen dificultades con tareas complejas o computacionalmente intensivas debido a los límites de rendimiento y los costos de la ejecución en la cadena. La computación off-chain habilitada por TEE permite que estas tareas se realicen fuera de la cadena principal (por lo tanto, sin consumir gas de bloque ni ralentizar el rendimiento en la cadena) mientras se conservan las garantías de confianza sobre la corrección de los resultados. En efecto, un TEE puede servir como un acelerador de computación off-chain verificable para Web3.

Por ejemplo, la plataforma iExec utiliza TEEs para crear un mercado descentralizado de computación en la nube donde los desarrolladores pueden ejecutar cálculos off-chain y obtener resultados que son confiables para la blockchain. Una dApp puede solicitar que una computación (digamos, una inferencia de un modelo de IA complejo o un análisis de big data) sea realizada por los nodos trabajadores de iExec. Estos nodos trabajadores ejecutan la tarea dentro de un enclave SGX, produciendo un resultado junto con una atestación de que el código correcto se ejecutó en un enclave genuino. El resultado se devuelve luego en la cadena, y el contrato inteligente puede verificar la atestación del enclave antes de aceptar la salida. Esta arquitectura permite que las cargas de trabajo pesadas se manejen off-chain sin sacrificar la confianza, aumentando efectivamente el rendimiento. La integración del Orquestador de iExec con Chainlink demuestra esto: un oráculo de Chainlink obtiene datos externos, luego entrega una computación compleja a los trabajadores TEE de iExec (por ejemplo, agregando o puntuando los datos), y finalmente el resultado seguro se entrega en la cadena. Los casos de uso incluyen cosas como cálculos de seguros descentralizados (como demostró iExec), donde se puede realizar una gran cantidad de procesamiento de datos off-chain y de manera económica, con solo el resultado final yendo a la blockchain.

La computación off-chain basada en TEE también sustenta algunas soluciones de escalado de Capa 2. El prototipo temprano de Oasis Labs, Ekiden (el precursor de Oasis Network), utilizó enclaves SGX para ejecutar transacciones off-chain en paralelo, y luego confirmar solo las raíces de estado en la cadena principal, de manera efectiva similar a las ideas de rollup pero utilizando la confianza del hardware. Al realizar la ejecución de contratos en TEEs, lograron un alto rendimiento mientras dependían de los enclaves para preservar la seguridad. Otro ejemplo es la próxima L2 Op-Succinct de Sanders Network, que combina TEEs y zkSNARKs: los TEEs ejecutan transacciones de forma privada y rápida, y luego se generan pruebas ZK para demostrar la corrección de esas ejecuciones a Ethereum. Este enfoque híbrido aprovecha la velocidad de los TEE y la verificabilidad de ZK para una solución L2 escalable y privada.

En general, los TEEs pueden ejecutar cálculos con un rendimiento casi nativo (ya que utilizan instrucciones reales de la CPU, solo con aislamiento), por lo que son órdenes de magnitud más rápidos que las alternativas puramente criptográficas como el cifrado homomórfico o las pruebas de conocimiento cero para lógica compleja. Al descargar el trabajo a los enclaves, las blockchains pueden manejar aplicaciones más complejas (como aprendizaje automático, procesamiento de imágenes/audio, análisis grandes) que serían imprácticas en la cadena. Los resultados regresan con una atestación, que el contrato en la cadena o los usuarios pueden verificar como originarios de un enclave de confianza, preservando así la integridad de los datos y la corrección. Este modelo a menudo se llama "computación off-chain verificable", y los TEEs son una piedra angular para muchos de estos diseños (por ejemplo, el Trusted Compute Framework de Hyperledger Avalon, desarrollado por Intel, iExec y otros, utiliza TEEs para ejecutar bytecode de EVM off-chain con una prueba de corrección publicada en la cadena).

Oráculos Seguros e Integridad de Datos

Los oráculos conectan las blockchains con datos del mundo real, pero introducen desafíos de confianza: ¿cómo puede un contrato inteligente confiar en que una fuente de datos off-chain es correcta y no ha sido manipulada? Los TEEs proporcionan una solución al servir como un sandbox seguro para los nodos de oráculo. Un nodo de oráculo basado en TEE puede obtener datos de fuentes externas (APIs, servicios web) y procesarlos dentro de un enclave que garantiza que los datos no han sido manipulados por el operador del nodo o un malware en el nodo. El enclave puede luego firmar o atestiguar la veracidad de los datos que proporciona. Esto mejora significativamente la integridad y confiabilidad de los datos del oráculo. Incluso si un operador de oráculo es malicioso, no puede alterar los datos sin romper la atestación del enclave (que la blockchain detectará).

Un ejemplo notable es Town Crier, un sistema de oráculo desarrollado en Cornell que fue uno de los primeros en utilizar enclaves Intel SGX para proporcionar datos autenticados a los contratos de Ethereum. Town Crier recuperaría datos (por ejemplo, de sitios web HTTPS) dentro de un enclave SGX y los entregaría a un contrato junto con una prueba (una firma del enclave) de que los datos provenían directamente de la fuente y no fueron falsificados. Chainlink reconoció el valor de esto y adquirió Town Crier en 2018 para integrar oráculos basados en TEE en su red descentralizada. Hoy en día, Chainlink y otros proveedores de oráculos tienen iniciativas de TEE: por ejemplo, DECO y Fair Sequencing Services de Chainlink involucran TEEs para garantizar la confidencialidad de los datos y el ordenamiento justo. Como se señaló en un análisis, "TEE revolucionó la seguridad de los oráculos al proporcionar un entorno a prueba de manipulaciones para el procesamiento de datos... incluso los propios operadores de nodos no pueden manipular los datos mientras se están procesando". Esto es particularmente crucial para las fuentes de datos financieros de alto valor (como los oráculos de precios para DeFi): un TEE puede prevenir incluso manipulaciones sutiles que podrían llevar a grandes exploits.

Los TEEs también permiten a los oráculos manejar datos sensibles o propietarios que no podrían publicarse en texto plano en una blockchain. Por ejemplo, una red de oráculos podría usar enclaves para agregar datos privados (como libros de órdenes de acciones confidenciales o datos de salud personales) y alimentar solo resultados derivados o pruebas validadas a la blockchain, sin exponer las entradas sensibles en bruto. De esta manera, los TEEs amplían el alcance de los datos que pueden integrarse de forma segura en los contratos inteligentes, lo cual es crítico para la tokenización de activos del mundo real (RWA), la calificación crediticia, los seguros y otros servicios en cadena intensivos en datos.

En el tema de los puentes cross-chain, los TEEs mejoran de manera similar la integridad. Los puentes a menudo dependen de un conjunto de validadores o una multifirma para custodiar activos y validar transferencias entre cadenas, lo que los convierte en objetivos principales para ataques. Al ejecutar la lógica del validador del puente dentro de TEEs, se pueden asegurar las claves privadas y los procesos de verificación del puente contra la manipulación. Incluso si el sistema operativo de un validador está comprometido, el atacante no debería poder extraer claves privadas o falsificar mensajes desde dentro del enclave. Los TEEs pueden hacer cumplir que las transacciones del puente se procesen exactamente de acuerdo con las reglas del protocolo, reduciendo el riesgo de que operadores humanos o malware inyecten transferencias fraudulentas. Además, los TEEs pueden permitir que los atomic swaps y las transacciones cross-chain se manejen en un enclave seguro que completa ambos lados o se aborta limpiamente, evitando escenarios donde los fondos se quedan atascados debido a interferencias. Varios proyectos de puentes y consorcios han explorado la seguridad basada en TEE para mitigar la plaga de hackeos de puentes que han ocurrido en los últimos años.

Integridad de Datos y Verificabilidad Off-Chain

En todos los escenarios anteriores, un tema recurrente es que los TEEs ayudan a mantener la integridad de los datos incluso fuera de la blockchain. Debido a que un TEE puede probar qué código está ejecutando (a través de la atestación) y puede garantizar que el código se ejecute sin interferencias, proporciona una forma de computación verificable. Los usuarios y los contratos inteligentes pueden confiar en los resultados que provienen de un TEE como si se hubieran calculado en la cadena, siempre que la atestación sea válida. Esta garantía de integridad es la razón por la que a veces se hace referencia a los TEEs como un "ancla de confianza" para los datos y la computación off-chain.

Sin embargo, vale la pena señalar que este modelo de confianza traslada algunas suposiciones al hardware (ver §4). La integridad de los datos es tan fuerte como la seguridad del TEE. Si el enclave se ve comprometido o la atestación se falsifica, la integridad podría fallar. No obstante, en la práctica, los TEEs (cuando se mantienen actualizados) hacen que ciertos ataques sean significativamente más difíciles. Por ejemplo, una plataforma de préstamos DeFi podría usar un TEE para calcular puntajes de crédito a partir de los datos privados de un usuario off-chain, y el contrato inteligente aceptaría el puntaje solo si va acompañado de una atestación de enclave válida. De esta manera, el contrato sabe que el puntaje fue calculado por el algoritmo aprobado sobre datos reales, en lugar de confiar ciegamente en el usuario o en un oráculo.

Los TEEs también juegan un papel en los sistemas emergentes de identidad descentralizada (DID) y autenticación. Pueden gestionar de forma segura claves privadas, datos personales y procesos de autenticación de una manera que la información sensible del usuario nunca se exponga a la blockchain o a los proveedores de dApps. Por ejemplo, un TEE en un dispositivo móvil podría manejar la autenticación biométrica y firmar una transacción de blockchain si la verificación biométrica pasa, todo sin revelar los datos biométricos del usuario. Esto proporciona tanto seguridad como privacidad en la gestión de la identidad, un componente esencial si Web3 va a manejar cosas como pasaportes, certificados o datos KYC de una manera soberana para el usuario.

En resumen, los TEEs sirven como una herramienta versátil en Web3: permiten la confidencialidad para la lógica en la cadena, permiten el escalado a través de la computación segura off-chain, protegen la integridad de los oráculos y puentes, y abren nuevos usos (desde la identidad privada hasta el intercambio de datos compatible). A continuación, veremos proyectos específicos que aprovechan estas capacidades.

3. Proyectos Web3 Notables que Aprovechan los TEEs

Varios proyectos líderes de blockchain han construido sus ofertas principales en torno a los Entornos de Ejecución Confiables. A continuación, nos sumergimos en algunos de los más notables, examinando cómo cada uno utiliza la tecnología TEE y qué valor único añade:

Secret Network

Secret Network es una blockchain de capa 1 (construida sobre el SDK de Cosmos) que fue pionera en los contratos inteligentes que preservan la privacidad utilizando TEEs. Todos los nodos validadores en Secret Network ejecutan enclaves Intel SGX, que ejecutan el código del contrato inteligente de modo que el estado del contrato y las entradas/salidas permanecen cifrados incluso para los operadores de los nodos. Esto convierte a Secret en una de las primeras plataformas de contratos inteligentes con privacidad por defecto: la privacidad no es un complemento opcional, sino una característica predeterminada de la red a nivel de protocolo.

En el modelo de Secret Network, los usuarios envían transacciones cifradas, que los validadores cargan en su enclave SGX para su ejecución. El enclave descifra las entradas, ejecuta el contrato (escrito en un tiempo de ejecución CosmWasm modificado) y produce salidas cifradas que se escriben en la blockchain. Solo los usuarios con la clave de visualización correcta (o el propio contrato con su clave interna) pueden descifrar y ver los datos reales. Esto permite que las aplicaciones utilicen datos privados en la cadena sin revelarlos públicamente.

La red ha demostrado varios casos de uso novedosos:

  • DeFi Secreto: por ejemplo, SecretSwap (un AMM) donde los saldos de las cuentas de los usuarios y los montos de las transacciones son privados, mitigando el front-running y protegiendo las estrategias de trading. Los proveedores de liquidez y los traders pueden operar sin transmitir cada uno de sus movimientos a la competencia.
  • Subastas Secretas: Contratos de subasta donde las ofertas se mantienen en secreto hasta que finaliza la subasta, evitando el comportamiento estratégico basado en las ofertas de otros.
  • Votación y Gobernanza Privada: Los poseedores de tokens pueden votar sobre propuestas sin revelar sus opciones de voto, mientras que el recuento aún puede ser verificado, asegurando una gobernanza justa y libre de intimidación.
  • Mercados de datos: Conjuntos de datos sensibles pueden ser transaccionados y utilizados en cálculos sin exponer los datos brutos a compradores o nodos.

Secret Network esencialmente incorpora TEEs a nivel de protocolo para crear una propuesta de valor única: ofrece privacidad programable. Los desafíos que abordan incluyen la coordinación de la atestación de enclaves en un conjunto de validadores descentralizado y la gestión de la distribución de claves para que los contratos puedan descifrar las entradas mientras las mantienen en secreto para los validadores. A todas luces, Secret ha demostrado la viabilidad de la confidencialidad impulsada por TEE en una blockchain pública, estableciéndose como un líder en el espacio.

Oasis Network

Oasis Network es otra capa 1 orientada a la escalabilidad y la privacidad, que utiliza extensivamente TEEs (Intel SGX) en su arquitectura. Oasis introdujo un diseño innovador que separa el consenso de la computación en diferentes capas llamadas la Capa de Consenso y la Capa ParaTime. La Capa de Consenso se encarga del ordenamiento y la finalidad de la blockchain, mientras que cada ParaTime puede ser un entorno de ejecución para contratos inteligentes. Notablemente, el Emerald ParaTime de Oasis es un entorno compatible con EVM, y Sapphire es un EVM confidencial que utiliza TEEs para mantener privado el estado de los contratos inteligentes.

El uso de TEEs por parte de Oasis se centra en la computación confidencial a escala. Al aislar la computación pesada en ParaTimes paralelizables (que pueden ejecutarse en muchos nodos), logran un alto rendimiento, y al usar TEEs dentro de esos nodos ParaTime, aseguran que los cálculos puedan incluir datos sensibles sin revelarlos. Por ejemplo, una institución podría ejecutar un algoritmo de calificación crediticia en Oasis alimentando datos privados en un ParaTime confidencial: los datos permanecen cifrados para el nodo (ya que se procesan en el enclave), y solo sale la puntuación. Mientras tanto, el consenso de Oasis solo registra la prueba de que la computación se realizó correctamente.

Técnicamente, Oasis añadió capas adicionales de seguridad más allá de SGX estándar. Implementaron una "raíz de confianza en capas": utilizando el Enclave de Cotización SGX de Intel y un kernel ligero personalizado para verificar la confiabilidad del hardware y para aislar las llamadas al sistema del enclave. Esto reduce la superficie de ataque (al filtrar qué llamadas al SO pueden hacer los enclaves) y protege contra ciertos ataques conocidos de SGX. Oasis también introdujo características como enclaves duraderos (para que los enclaves puedan persistir el estado a través de reinicios) y registro seguro para mitigar los ataques de reversión (donde un nodo podría intentar reproducir un estado de enclave antiguo). Estas innovaciones se describieron en sus documentos técnicos y son parte de por qué Oasis es visto como un proyecto impulsado por la investigación en la computación de blockchain basada en TEE.

Desde una perspectiva de ecosistema, Oasis se ha posicionado para cosas como DeFi privado (permitiendo que los bancos participen sin filtrar los datos de los clientes) y la tokenización de datos (donde individuos o empresas pueden compartir datos con modelos de IA de manera confidencial y ser compensados, todo a través de la blockchain). También han colaborado con empresas en proyectos piloto (por ejemplo, trabajando con BMW en la privacidad de datos, y otros en el intercambio de datos de investigación médica). En general, Oasis Network muestra cómo la combinación de TEEs con una arquitectura escalable puede abordar tanto la privacidad como el rendimiento, convirtiéndolo en un actor significativo en las soluciones Web3 basadas en TEE.

Sanders Network

Sanders Network es una red de computación en la nube descentralizada en el ecosistema de Polkadot que utiliza TEEs para proporcionar servicios de computación confidenciales y de alto rendimiento. Es una parachain en Polkadot, lo que significa que se beneficia de la seguridad e interoperabilidad de Polkadot, pero introduce su propio tiempo de ejecución novedoso para la computación off-chain en enclaves seguros.

La idea central de Sanders es mantener una gran red de nodos trabajadores (llamados mineros de Sanders) que ejecutan tareas dentro de TEEs (específicamente, Intel SGX hasta ahora) y producen resultados verificables. Estas tareas pueden variar desde ejecutar segmentos de contratos inteligentes hasta computación de propósito general solicitada por los usuarios. Debido a que los trabajadores se ejecutan en SGX, Sanders asegura que los cálculos se realizan con confidencialidad (los datos de entrada están ocultos para el operador del trabajador) e integridad (los resultados vienen con una atestación). Esto crea efectivamente una nube sin confianza donde los usuarios pueden desplegar cargas de trabajo sabiendo que el anfitrión no puede espiar ni manipularlas.

Se puede pensar en Sanders como análogo a Amazon EC2 o AWS Lambda, pero descentralizado: los desarrolladores pueden desplegar código en la red de Sanders y hacer que se ejecute en muchas máquinas habilitadas para SGX en todo el mundo, pagando con el token de Sanders por el servicio. Algunos casos de uso destacados:

  • Análisis e IA en Web3: Un proyecto podría analizar datos de usuarios o ejecutar algoritmos de IA en enclaves de Sanders, de modo que los datos brutos de los usuarios permanezcan cifrados (protegiendo la privacidad) mientras que solo las ideas agregadas salen del enclave.
  • Backends de juegos y Metaverso: Sanders puede manejar lógica de juego intensiva o simulaciones de mundos virtuales off-chain, enviando solo compromisos o hashes a la blockchain, permitiendo una jugabilidad más rica sin confiar en un solo servidor.
  • Servicios en cadena: Sanders ha construido una plataforma de computación off-chain llamada Sanders Cloud. Por ejemplo, puede servir como backend para bots, servicios web descentralizados, o incluso un libro de órdenes off-chain que publica operaciones en un contrato inteligente de DEX con atestación TEE.

Sanders enfatiza que puede escalar la computación confidencial horizontalmente: ¿necesitas más capacidad? Añade más nodos trabajadores TEE. Esto es diferente a una sola blockchain donde la capacidad de cómputo está limitada por el consenso. Así, Sanders abre posibilidades para dApps computacionalmente intensivas que aún desean seguridad sin confianza. Es importante destacar que Sanders no se basa únicamente en la confianza del hardware; se está integrando con el consenso de Polkadot (por ejemplo, staking y slashing por resultados incorrectos) e incluso explorando una combinación de TEE con pruebas de conocimiento cero (como se mencionó, su próxima L2 utiliza TEE para acelerar la ejecución y ZKP para verificarla de manera sucinta en Ethereum). Este enfoque híbrido ayuda a mitigar el riesgo de cualquier compromiso de un solo TEE al agregar verificación criptográfica por encima.

En resumen, Sanders Network aprovecha los TEEs para ofrecer una nube descentralizada y confidencial para Web3, permitiendo la computación off-chain con garantías de seguridad. Esto libera una clase de aplicaciones de blockchain que necesitan tanto cómputo pesado como privacidad de datos, cerrando la brecha entre los mundos on-chain y off-chain.

iExec

iExec es un mercado descentralizado para recursos de computación en la nube construido sobre Ethereum. A diferencia de los tres anteriores (que son sus propias cadenas o parachains), iExec opera como una red de capa 2 o off-chain que se coordina con los contratos inteligentes de Ethereum. Los TEEs (específicamente Intel SGX) son una piedra angular del enfoque de iExec para establecer la confianza en la computación off-chain.

La red iExec consta de nodos trabajadores contribuidos por varios proveedores. Estos trabajadores pueden ejecutar tareas solicitadas por los usuarios (desarrolladores de dApps, proveedores de datos, etc.). Para garantizar que estos cálculos off-chain sean confiables, iExec introdujo un marco de "Computación Off-chain Confiable": las tareas pueden ejecutarse dentro de enclaves SGX, y los resultados vienen con una firma de enclave que prueba que la tarea se ejecutó correctamente en un nodo seguro. iExec se asoció con Intel para lanzar esta función de computación confiable e incluso se unió al Confidential Computing Consortium para avanzar en los estándares. Su protocolo de consenso, llamado Prueba de Contribución (PoCo), agrega votos/atestaciones de múltiples trabajadores cuando es necesario para alcanzar un consenso sobre el resultado correcto. En muchos casos, la atestación de un solo enclave puede ser suficiente si el código es determinista y la confianza en SGX es alta; para una mayor seguridad, iExec puede replicar tareas en varios TEEs y usar un consenso o un voto mayoritario.

La plataforma de iExec permite varios casos de uso interesantes:

  • Computación de Oráculos Descentralizados: Como se mencionó anteriormente, iExec puede trabajar con Chainlink. Un nodo de Chainlink podría obtener datos brutos, luego entregarlos a un trabajador SGX de iExec para realizar un cálculo (por ejemplo, un algoritmo propietario o una inferencia de IA) sobre esos datos, y finalmente devolver un resultado en la cadena. Esto amplía lo que los oráculos pueden hacer más allá de simplemente retransmitir datos: ahora pueden proporcionar servicios computados (como llamar a un modelo de IA o agregar muchas fuentes) con TEE garantizando la honestidad.
  • IA y DePIN (Red de Infraestructura Física Descentralizada): iExec se está posicionando como una capa de confianza para aplicaciones de IA descentralizadas. Por ejemplo, una dApp que utiliza un modelo de aprendizaje automático puede ejecutar el modelo en un enclave para proteger tanto el modelo (si es propietario) como los datos del usuario que se introducen. En el contexto de DePIN (como las redes de IoT distribuidas), los TEEs se pueden utilizar en dispositivos de borde para confiar en las lecturas de los sensores y los cálculos sobre esas lecturas.
  • Monetización Segura de Datos: Los proveedores de datos pueden hacer que sus conjuntos de datos estén disponibles en el mercado de iExec en forma cifrada. Los compradores pueden enviar sus algoritmos para que se ejecuten sobre los datos dentro de un TEE (de modo que los datos brutos del proveedor de datos nunca se revelen, protegiendo su propiedad intelectual, y los detalles del algoritmo también pueden ocultarse). El resultado del cálculo se devuelve al comprador, y el pago apropiado al proveedor de datos se maneja a través de contratos inteligentes. Este esquema, a menudo llamado intercambio seguro de datos, es facilitado por la confidencialidad de los TEEs.

En general, iExec proporciona el pegamento entre los contratos inteligentes de Ethereum y la ejecución segura off-chain. Demuestra cómo los "trabajadores" TEE pueden conectarse en red para formar una nube descentralizada, completa con un mercado (utilizando el token RLC de iExec para el pago) y mecanismos de consenso. Al liderar el grupo de trabajo de Computación Confiable de la Enterprise Ethereum Alliance y contribuir a los estándares (como Hyperledger Avalon), iExec también impulsa una adopción más amplia de los TEEs en escenarios de blockchain empresarial.

Otros Proyectos y Ecosistemas

Más allá de los cuatro anteriores, hay algunos otros proyectos que vale la pena señalar:

  • Integritee – otra parachain de Polkadot similar a Sanders (de hecho, surgió del trabajo de TEE de la Energy Web Foundation). Integritee utiliza TEEs para crear "parachain-como-servicio" para empresas, combinando el procesamiento de enclaves on-chain y off-chain.
  • Automata Network – un protocolo de middleware para la privacidad en Web3 que aprovecha los TEEs para transacciones privadas, votación anónima y procesamiento de transacciones resistente a MEV. Automata funciona como una red off-chain que proporciona servicios como un relé RPC privado y se mencionó que utiliza TEEs para cosas como identidad protegida y transacciones privadas sin gas.
  • Hyperledger Sawtooth (PoET) – en el ámbito empresarial, Sawtooth introdujo un algoritmo de consenso llamado Prueba de Tiempo Transcurrido que se basaba en SGX. Cada validador ejecuta un enclave que espera un tiempo aleatorio y produce una prueba; el que tiene la espera más corta "gana" el bloque, una lotería justa impuesta por SGX. Aunque Sawtooth no es un proyecto Web3 per se (más bien blockchain empresarial), es un uso creativo de los TEEs para el consenso.
  • Cadenas Empresariales/de Consorcio – Muchas soluciones de blockchain empresarial (por ejemplo, ConsenSys Quorum, IBM Blockchain) incorporan TEEs para permitir transacciones de consorcio confidenciales, donde solo los nodos autorizados ven ciertos datos. Por ejemplo, el plan del Trusted Compute Framework (TCF) de la Enterprise Ethereum Alliance utiliza TEEs para ejecutar contratos privados off-chain y entregar pruebas de Merkle en la cadena.

Estos proyectos muestran colectivamente la versatilidad de los TEEs: impulsan L1s enteras centradas en la privacidad, sirven como redes off-chain, aseguran piezas de infraestructura como oráculos y puentes, e incluso sustentan algoritmos de consenso. A continuación, consideramos los beneficios y desafíos más amplios del uso de TEEs en entornos descentralizados.

4. Beneficios y Desafíos de los TEEs en Entornos Descentralizados

La adopción de Entornos de Ejecución Confiables en sistemas de blockchain conlleva importantes beneficios técnicos, así como notables desafíos y compromisos. Examinaremos ambos lados: lo que los TEEs ofrecen a las aplicaciones descentralizadas y qué problemas o riesgos surgen de su uso.

Beneficios y Fortalezas Técnicas

  • Fuerte Seguridad y Privacidad: El principal beneficio son las garantías de confidencialidad e integridad. Los TEEs permiten que el código sensible se ejecute con la seguridad de que no será espiado ni alterado por malware externo. Esto proporciona un nivel de confianza en la computación off-chain que antes no estaba disponible. Para la blockchain, esto significa que se pueden utilizar datos privados (mejorando la funcionalidad de las dApps) sin sacrificar la seguridad. Incluso en entornos no confiables (servidores en la nube, nodos validadores gestionados por terceros), los TEEs mantienen los secretos a salvo. Esto es especialmente beneficioso para gestionar claves privadas, datos de usuario y algoritmos propietarios dentro de los sistemas cripto. Por ejemplo, una billetera de hardware o un servicio de firma en la nube podría usar un TEE para firmar transacciones de blockchain internamente para que la clave privada nunca se exponga en texto plano, combinando conveniencia con seguridad.

  • Rendimiento Casi Nativo: A diferencia de los enfoques puramente criptográficos para la computación segura (como las pruebas ZK o el cifrado homomórfico), la sobrecarga de los TEE es relativamente pequeña. El código se ejecuta directamente en la CPU, por lo que un cálculo dentro de un enclave es aproximadamente tan rápido como ejecutarlo fuera (con cierta sobrecarga por las transiciones del enclave y el cifrado de memoria, típicicamente ralentizaciones de un solo dígito porcentual en SGX). Esto significa que los TEEs pueden manejar tareas computacionalmente intensivas de manera eficiente, permitiendo casos de uso (como fuentes de datos en tiempo real, contratos inteligentes complejos, aprendizaje automático) que serían órdenes de magnitud más lentos si se hicieran con protocolos criptográficos. La baja latencia de los enclaves los hace adecuados donde se necesita una respuesta rápida (por ejemplo, bots de trading de alta frecuencia asegurados por TEEs, o aplicaciones y juegos interactivos donde la experiencia del usuario sufriría con grandes retrasos).

  • Escalabilidad Mejorada (a través de la Descarga): Al permitir que los cálculos pesados se realicen de forma segura off-chain, los TEEs ayudan a aliviar la congestión y los costos de gas en las cadenas principales. Habilitan diseños de Capa 2 y protocolos secundarios donde la blockchain se utiliza solo para verificación o liquidación final, mientras que la mayor parte de la computación ocurre en enclaves paralelos. Esta modularización (lógica computacionalmente intensiva en TEEs, consenso en la cadena) puede mejorar drásticamente el rendimiento y la escalabilidad de las aplicaciones descentralizadas. Por ejemplo, un DEX podría hacer el emparejamiento en un TEE off-chain y solo publicar las operaciones emparejadas en la cadena, aumentando el rendimiento y reduciendo el gas en la cadena.

  • Mejor Experiencia de Usuario y Funcionalidad: Con los TEEs, las dApps pueden ofrecer características como confidencialidad o análisis complejos que atraen a más usuarios (incluidas las instituciones). Los TEEs también permiten transacciones sin gas o meta-transacciones al ejecutarlas de forma segura off-chain y luego enviar los resultados, como se señaló en el uso de TEEs por parte de Automata para reducir el gas en transacciones privadas. Además, almacenar el estado sensible off-chain en un enclave puede reducir los datos publicados en la cadena, lo cual es bueno para la privacidad del usuario y la eficiencia de la red (menos datos en la cadena para almacenar/verificar).

  • Composabilidad con Otras Tecnologías: Curiosamente, los TEEs pueden complementar otras tecnologías (no es estrictamente un beneficio inherente a los TEEs solos, sino en combinación). Pueden servir como el pegamento que une soluciones híbridas: por ejemplo, ejecutar un programa en un enclave y también generar una prueba ZK de su ejecución, donde el enclave ayuda con partes del proceso de prueba para acelerarlo. O usar TEEs en redes MPC para manejar ciertas tareas con menos rondas de comunicación. Discutiremos las comparaciones en el §5, pero muchos proyectos destacan que los TEEs no tienen que reemplazar la criptografía, pueden trabajar junto a ella para reforzar la seguridad (el mantra de Sanders: "La fuerza de los TEEs radica en apoyar a otros, no en reemplazarlos").

Supuestos de Confianza y Vulnerabilidades de Seguridad

A pesar de sus fortalezas, los TEEs introducen supuestos de confianza específicos y no son invulnerables. Es crucial entender estos desafíos:

  • Confianza en el Hardware y Centralización: Al usar TEEs, uno está depositando inherentemente confianza en el proveedor de silicio y en la seguridad de su diseño de hardware y cadena de suministro. Por ejemplo, usar Intel SGX significa confiar en que Intel no tiene puertas traseras, que su fabricación es segura y que el microcódigo de la CPU implementa correctamente el aislamiento del enclave. Este es un modelo de confianza más centralizado en comparación con la criptografía pura (que se basa en supuestos matemáticos distribuidos entre todos los usuarios). Además, la atestación para SGX históricamente depende de contactar al Servicio de Atestación de Intel, lo que significa que si Intel se desconectara o decidiera revocar claves, los enclaves a nivel mundial podrían verse afectados. Esta dependencia de la infraestructura de una sola empresa plantea preocupaciones: podría ser un único punto de fallo o incluso un objetivo de regulación gubernamental (por ejemplo, los controles de exportación de EE. UU. podrían en teoría restringir quién puede usar TEEs fuertes). AMD SEV mitiga esto al permitir una atestación más descentralizada (los propietarios de VM pueden atestiguar sus VM), pero aún así se confía en el chip y el firmware de AMD. El riesgo de centralización a menudo se cita como algo antitético a la descentralización de la blockchain. Proyectos como Keystone (TEE de código abierto) y otros están investigando formas de reducir la dependencia de cajas negras propietarias, pero aún no son de uso generalizado.

  • Canal Lateral y Otras Vulnerabilidades: Un TEE no es una bala de plata; puede ser atacado a través de medios indirectos. Los ataques de canal lateral explotan el hecho de que incluso si el acceso directo a la memoria está bloqueado, la operación de un enclave podría influir sutilmente en el sistema (a través del tiempo, el uso de la caché, el consumo de energía, las emisiones electromagnéticas, etc.). En los últimos años, se han demostrado numerosos ataques académicos a Intel SGX: desde Foreshadow (extracción de secretos del enclave a través de fugas de tiempo de la caché L1) hasta Plundervolt (inyección de fallos de voltaje a través de instrucciones privilegiadas) y SGAxe (extracción de claves de atestación), entre otros. Estos ataques sofisticados muestran que los TEEs pueden ser comprometidos sin necesidad de romper las protecciones criptográficas, sino explotando comportamientos microarquitectónicos o fallos en la implementación. Como resultado, se reconoce que "los investigadores han identificado varios vectores de ataque potenciales que podrían explotar vulnerabilidades de hardware o diferencias de tiempo en las operaciones de TEE". Aunque estos ataques no son triviales y a menudo requieren acceso local o hardware malicioso, son una amenaza real. Los TEEs tampoco protegen generalmente contra ataques físicos si un adversario tiene el chip en sus manos (por ejemplo, decapsular el chip, sondear buses, etc., puede derrotar a la mayoría de los TEEs comerciales).

    Las respuestas de los proveedores a los descubrimientos de canales laterales han sido parches de microcódigo y actualizaciones del SDK del enclave para mitigar las fugas conocidas (a veces a costa del rendimiento). Pero sigue siendo un juego del gato y el ratón. Para Web3, esto significa que si alguien encuentra un nuevo canal lateral en SGX, un contrato DeFi "seguro" que se ejecuta en SGX podría ser explotado (por ejemplo, para filtrar datos secretos o manipular la ejecución). Por lo tanto, depender de los TEEs significa aceptar una superficie de vulnerabilidad potencial a nivel de hardware que está fuera del modelo de amenaza típico de la blockchain. Es un área activa de investigación para fortalecer los TEEs contra estos (por ejemplo, diseñando código de enclave con operaciones de tiempo constante, evitando patrones de acceso a memoria dependientes de secretos y utilizando técnicas como la RAM ajena). Algunos proyectos también aumentan los TEEs con verificaciones secundarias, por ejemplo, combinándolos con pruebas ZK, o haciendo que múltiples enclaves se ejecuten en hardware de diferentes proveedores para reducir el riesgo de un solo chip.

  • Rendimiento y Restricciones de Recursos: Aunque los TEEs se ejecutan a una velocidad casi nativa para tareas ligadas a la CPU, tienen algunas sobrecargas y límites. Entrar en un enclave (un ECALL) y salir (OCALL) tiene un costo, al igual que el cifrado/descifrado de las páginas de memoria. Esto puede afectar el rendimiento en cruces de límites de enclave muy frecuentes. Los enclaves también suelen tener limitaciones de tamaño de memoria. Por ejemplo, los primeros SGX tenían una Caché de Páginas de Enclave limitada y cuando los enclaves usaban más memoria, las páginas tenían que ser intercambiadas (con cifrado), lo que ralentizaba masivamente el rendimiento. Incluso los TEEs más nuevos a menudo no permiten usar toda la RAM del sistema fácilmente; hay una región de memoria segura que podría estar limitada. Esto significa que los cálculos o conjuntos de datos a muy gran escala podrían ser difíciles de manejar por completo dentro de un TEE. En contextos de Web3, esto podría limitar la complejidad de los contratos inteligentes o los modelos de ML que pueden ejecutarse en un enclave. Los desarrolladores tienen que optimizar la memoria y posiblemente dividir las cargas de trabajo.

  • Complejidad de la Atestación y la Gestión de Claves: Usar TEEs en un entorno descentralizado requiere flujos de trabajo de atestación robustos: cada nodo necesita demostrar a los demás que está ejecutando un enclave auténtico con el código esperado. Configurar esta verificación de atestación en la cadena puede ser complejo. Generalmente implica codificar la clave pública de atestación o el certificado del proveedor en el protocolo y escribir la lógica de verificación en contratos inteligentes o clientes off-chain. Esto introduce una sobrecarga en el diseño del protocolo, y cualquier cambio (como que Intel cambie su formato de clave de firma de atestación de EPID a DCAP) puede causar cargas de mantenimiento. Además, la gestión de claves dentro de los TEEs (para descifrar datos o firmar resultados) añade otra capa de complejidad. Los errores en la gestión de claves del enclave podrían socavar la seguridad (por ejemplo, si un enclave expone inadvertidamente una clave de descifrado a través de un error, todas sus promesas de confidencialidad se derrumban). Las mejores prácticas implican el uso de las API de sellado del TEE para almacenar claves de forma segura y rotar las claves si es necesario, pero de nuevo, esto requiere un diseño cuidadoso por parte de los desarrolladores.

  • Denegación de Servicio y Disponibilidad: Un problema quizás menos discutido: los TEEs no ayudan con la disponibilidad e incluso pueden introducir nuevas vías de DoS. Por ejemplo, un atacante podría inundar un servicio basado en TEE con entradas que son costosas de procesar, sabiendo que el enclave no puede ser inspeccionado o interrumpido fácilmente por el operador (ya que está aislado). Además, si se encuentra una vulnerabilidad y un parche requiere actualizaciones de firmware, durante ese ciclo muchos servicios de enclave podrían tener que pausarse (por seguridad) hasta que los nodos estén parcheados, causando tiempo de inactividad. En el consenso de la blockchain, imagina si se encontrara un error crítico en SGX: redes como Secret podrían tener que detenerse hasta que haya una solución, ya que la confianza en los enclaves se rompería. La coordinación de tales respuestas en una red descentralizada es un desafío.

Composabilidad y Limitaciones del Ecosistema

  • Composabilidad Limitada con Otros Contratos: En una plataforma de contratos inteligentes pública como Ethereum, los contratos pueden llamar fácilmente a otros contratos y todo el estado está abierto, lo que permite los legos de dinero de DeFi y una rica composición. En un modelo de contrato basado en TEE, el estado privado no se puede compartir o componer libremente sin romper la confidencialidad. Por ejemplo, si el Contrato A en un enclave necesita interactuar con el Contrato B, y ambos tienen algunos datos secretos, ¿cómo colaboran? O deben realizar un complejo protocolo seguro multipartita (lo que niega parte de la simplicidad de los TEEs) o se combinan en un solo enclave (reduciendo la modularidad). Este es un desafío que Secret Network y otros enfrentan: las llamadas entre contratos con privacidad no son triviales. Algunas soluciones implican tener un solo enclave que maneje la ejecución de múltiples contratos para que pueda gestionar internamente los secretos compartidos, pero eso puede hacer que el sistema sea más monolítico. Por lo tanto, la composabilidad de los contratos privados es más limitada que la de los públicos, o requiere nuevos patrones de diseño. De manera similar, la integración de módulos basados en TEE en dApps de blockchain existentes requiere un diseño de interfaz cuidadoso: a menudo solo el resultado de un enclave se publica en la cadena, que podría ser un snark o un hash, y otros contratos solo pueden usar esa información limitada. Esto es ciertamente un compromiso; proyectos como Secret proporcionan claves de visualización y permiten compartir secretos según sea necesario, pero no es tan fluido como la composabilidad normal en la cadena.

  • Estandarización e Interoperabilidad: El ecosistema TEE actualmente carece de estándares unificados entre los proveedores. Intel SGX, AMD SEV, ARM TrustZone tienen todos diferentes modelos de programación y métodos de atestación. Esta fragmentación significa que una dApp escrita para enclaves SGX no es trivialmente portable a TrustZone, etc. En la blockchain, esto puede atar un proyecto a un hardware específico (por ejemplo, Secret y Oasis están atados a servidores x86 con SGX en este momento). Si en el futuro quisieran admitir nodos ARM (digamos, validadores en móviles), requeriría un desarrollo adicional y quizás una lógica de verificación de atestación diferente. Hay esfuerzos (como el CCC – Confidential Computing Consortium) para estandarizar la atestación y las API de enclaves, pero aún no hemos llegado a ese punto. La falta de estándares también afecta las herramientas para desarrolladores: uno podría encontrar el SDK de SGX maduro pero luego necesitar adaptarse a otro TEE con un SDK diferente. Este desafío de interoperabilidad puede ralentizar la adopción y aumentar los costos.

  • Curva de Aprendizaje para Desarrolladores: Construir aplicaciones que se ejecutan dentro de TEEs requiere un conocimiento especializado que muchos desarrolladores de blockchain pueden no tener. A menudo se necesita programación de bajo nivel en C/C++ (para SGX/TrustZone) o comprensión de la seguridad de la memoria y la codificación resistente a canales laterales. La depuración del código del enclave es notoriamente complicada (¡no se puede ver fácilmente dentro de un enclave mientras se está ejecutando por razones de seguridad!). Aunque existen frameworks y lenguajes de nivel superior (como el uso de Rust por parte de Oasis para su tiempo de ejecución confidencial, o incluso herramientas para ejecutar WebAssembly en enclaves), la experiencia del desarrollador sigue siendo más difícil que el desarrollo típico de contratos inteligentes o el desarrollo web2 off-chain. Esta curva de aprendizaje pronunciada y las herramientas inmaduras pueden disuadir a los desarrolladores o llevar a errores si no se manejan con cuidado. También está el aspecto de necesitar hardware para probar: ejecutar código SGX necesita una CPU habilitada para SGX o un emulador (que es más lento), por lo que la barrera de entrada es más alta. Como resultado, relativamente pocos desarrolladores hoy en día están profundamente familiarizados con el desarrollo de enclaves, lo que hace que las auditorías y el apoyo de la comunidad sean más escasos que en, digamos, la bien transitada comunidad de Solidity.

  • Costos Operativos: Ejecutar una infraestructura basada en TEE puede ser más costoso. El hardware en sí podría ser más caro o escaso (por ejemplo, ciertos proveedores de la nube cobran una prima por las VM con capacidad SGX). También hay una sobrecarga en las operaciones: mantener el firmware actualizado (para parches de seguridad), gestionar la red de atestación, etc., lo que los proyectos pequeños podrían encontrar oneroso. Si cada nodo debe tener una cierta CPU, podría reducir el grupo potencial de validadores (no todos tienen el hardware requerido), afectando así la descentralización y posiblemente llevando a un mayor uso de alojamiento en la nube.

En resumen, aunque los TEEs desbloquean características potentes, también traen compromisos de confianza (confianza en el hardware vs. confianza en las matemáticas), debilidades de seguridad potenciales (especialmente canales laterales) y obstáculos de integración en un contexto descentralizado. Los proyectos que utilizan TEEs deben ingeniárselas cuidadosamente en torno a estos problemas, empleando defensa en profundidad (no asumir que el TEE es inquebrantable), manteniendo la base de computación confiable al mínimo y siendo transparentes sobre los supuestos de confianza para los usuarios (para que quede claro, por ejemplo, que se está confiando en el hardware de Intel además del consenso de la blockchain).

5. TEEs vs. Otras Tecnologías que Preservan la Privacidad (ZKP, FHE, MPC)

Los Entornos de Ejecución Confiables son un enfoque para lograr la privacidad y la seguridad en Web3, pero existen otras técnicas importantes que incluyen las Pruebas de Conocimiento Cero (ZKPs), el Cifrado Totalmente Homomórfico (FHE) y la Computación Segura Multipartita (MPC). Cada una de estas tecnologías tiene un modelo de confianza y un perfil de rendimiento diferentes. En muchos casos, no son mutuamente excluyentes, pueden complementarse entre sí, pero es útil comparar sus compromisos en rendimiento, confianza y usabilidad para el desarrollador:

Para definir brevemente las alternativas:

  • ZKPs: Pruebas criptográficas (como zk-SNARKs, zk-STARKs) que permiten a una parte demostrar a otras que una afirmación es verdadera (por ejemplo, "conozco un secreto que satisface este cálculo") sin revelar por qué es verdadera (ocultando la entrada secreta). En la blockchain, las ZKPs se utilizan para transacciones privadas (por ejemplo, Zcash, Aztec) y para la escalabilidad (rollups que publican pruebas de ejecución correcta). Garantizan una fuerte privacidad (no se filtra ningún dato secreto, solo pruebas) y una integridad garantizada por las matemáticas, pero generar estas pruebas puede ser computacionalmente pesado y los circuitos deben diseñarse cuidadosamente.
  • FHE: Esquema de cifrado que permite la computación arbitraria sobre datos cifrados, de modo que el resultado, al ser descifrado, coincide con el resultado de computar sobre textos planos. En teoría, el FHE proporciona la máxima privacidad: los datos permanecen cifrados en todo momento, y no es necesario confiar en nadie con los datos brutos. Pero el FHE es extremadamente lento para cálculos generales (aunque está mejorando con la investigación); todavía se encuentra principalmente en uso experimental o especializado debido al rendimiento.
  • MPC: Protocolos donde múltiples partes calculan conjuntamente una función sobre sus entradas privadas sin revelar esas entradas entre sí. A menudo implica compartir secretos de los datos entre las partes y realizar operaciones criptográficas para que la salida sea correcta pero las entradas individuales permanezcan ocultas. El MPC puede distribuir la confianza (ningún punto único ve todos los datos) y puede ser eficiente para ciertas operaciones, pero típicamente incurre en una sobrecarga de comunicación y coordinación y puede ser complejo de implementar para redes grandes.

A continuación se presenta una tabla comparativa que resume las diferencias clave:

TecnologíaModelo de ConfianzaRendimientoPrivacidad de DatosUsabilidad para el Desarrollador
TEE (Intel SGX, etc.)Confianza en el fabricante del hardware (servidor de atestación centralizado en algunos casos). Asume que el chip es seguro; si el hardware se ve comprometido, la seguridad se rompe.Velocidad de ejecución casi nativa; sobrecarga mínima. Bueno para computación en tiempo real y grandes cargas de trabajo. La escalabilidad está limitada por la disponibilidad de nodos habilitados para TEE.Los datos están en texto plano dentro del enclave, pero cifrados para el mundo exterior. Fuerte confidencialidad si el hardware se mantiene, pero si el enclave es vulnerado, los secretos quedan expuestos (sin protección matemática adicional).Complejidad moderada. A menudo se puede reutilizar código/lenguajes existentes (C, Rust) y ejecutarlo en un enclave con modificaciones menores. La barrera de entrada más baja entre estos: no es necesario aprender criptografía avanzada, pero requiere programación de sistemas y conocimiento específico del SDK del TEE.
ZKP (zk-SNARK/STARK)Confianza en supuestos matemáticos (por ejemplo, la dureza de los problemas criptográficos) y a veces una configuración confiable (para SNARKs). Sin dependencia de ninguna parte única en tiempo de ejecución.La generación de pruebas es computacionalmente pesada (especialmente para programas complejos), a menudo órdenes de magnitud más lenta que la nativa. La verificación en la cadena es rápida (pocos ms). No es ideal para grandes cálculos de datos debido al tiempo de prueba. Escalabilidad: buena para la verificación sucinta (rollups) pero el probador es el cuello de botella.Privacidad muy fuerte: se puede probar la corrección sin revelar ninguna entrada privada. Solo se filtra información mínima (como el tamaño de la prueba). Ideal para la privacidad financiera, etc.Alta complejidad. Requiere aprender lenguajes especializados (circuitos, zkDSLs como Circom o Noir) y pensar en términos de circuitos aritméticos. La depuración es difícil. Menos expertos disponibles.
FHEConfianza en las matemáticas (problemas de retículos). Sin parte confiable; la seguridad se mantiene mientras el cifrado no se rompa.Muy lento para uso general. Las operaciones sobre datos cifrados son varios órdenes de magnitud más lentas que en texto plano. Mejora algo con avances de hardware y mejores algoritmos, pero actualmente es impráctico para uso en tiempo real en contextos de blockchain.Máxima privacidad: los datos permanecen cifrados todo el tiempo, incluso durante la computación. Esto es ideal para datos sensibles (por ejemplo, médicos, análisis interinstitucionales) si el rendimiento lo permitiera.Muy especializado. Los desarrolladores necesitan conocimientos de criptografía. Existen algunas bibliotecas (como Microsoft SEAL, TFHE), pero escribir programas arbitrarios en FHE es difícil y tortuoso. Aún no es un objetivo de desarrollo rutinario para dApps.
MPCConfianza distribuida entre múltiples partes. Asume que un umbral de partes es honesto (sin colusión más allá de cierto número). No se necesita confianza en el hardware. Falla la confianza si demasiados coluden.Típicamente más lento que el nativo debido a las rondas de comunicación, pero a menudo más rápido que el FHE. El rendimiento varía: operaciones simples (suma, multiplicación) pueden ser eficientes; la lógica compleja puede disparar el costo de comunicación. La latencia es sensible a las velocidades de la red. La escalabilidad puede mejorarse con sharding o supuestos de confianza parcial.Fuerte privacidad si se cumplen los supuestos: ningún nodo ve la entrada completa. Pero algo de información puede filtrarse a través de la salida o si las partes se caen (además, carece de la sucinta de ZK: obtienes el resultado pero no una prueba fácilmente compartible sin ejecutar el protocolo de nuevo).Alta complejidad. Requiere diseñar un protocolo personalizado para cada caso de uso o usar frameworks (como SPDZ, o la oferta de Partisia). Los desarrolladores deben razonar sobre protocolos criptográficos y a menudo coordinar el despliegue de múltiples nodos. La integración en aplicaciones de blockchain puede ser compleja (necesita rondas off-chain).

Citas: La comparación anterior se basa en fuentes como el análisis de Sanders Network y otros, que destacan que los TEEs sobresalen en velocidad y facilidad de uso, mientras que ZK y FHE se centran en la máxima falta de confianza a costa de un cómputo pesado, y MPC distribuye la confianza pero introduce una sobrecarga de red.

De la tabla, algunos compromisos clave se vuelven claros:

  • Rendimiento: Los TEEs tienen una gran ventaja en velocidad bruta y baja latencia. El MPC a menudo puede manejar una complejidad moderada con cierta ralentización, ZK es lento para producir pero rápido para verificar (uso asíncrono), y FHE es actualmente el más lento con diferencia para tareas arbitrarias (aunque está bien para operaciones limitadas como sumas/multiplicaciones simples). Si tu aplicación necesita procesamiento complejo en tiempo real (como aplicaciones interactivas, decisiones de alta frecuencia), los TEEs o quizás el MPC (con pocas partes en buenas conexiones) son las únicas opciones viables hoy en día. ZK y FHE serían demasiado lentos en tales escenarios.

  • Modelo de Confianza: ZKP y FHE son puramente sin confianza (solo confían en las matemáticas). MPC traslada la confianza a supuestos sobre la honestidad de los participantes (que pueden reforzarse teniendo muchas partes o incentivos económicos). TEE deposita la confianza en el hardware y el proveedor. Esta es una diferencia fundamental: los TEEs introducen un tercero de confianza (el chip) en el mundo generalmente sin confianza de la blockchain. En contraste, ZK y FHE a menudo son elogiados por alinearse mejor con el ethos descentralizado: no hay entidades especiales en las que confiar, solo la dureza computacional. MPC se encuentra en el medio: la confianza está descentralizada pero no eliminada (si N de M nodos coluden, la privacidad se rompe). Así que para una máxima falta de confianza (por ejemplo, un sistema verdaderamente resistente a la censura y descentralizado), uno podría inclinarse hacia soluciones criptográficas. Por otro lado, muchos sistemas prácticos se sienten cómodos asumiendo que Intel es honesto o que un conjunto de validadores principales no coludirá, intercambiando un poco de confianza por enormes ganancias en eficiencia.

  • Seguridad/Vulnerabilidades: Los TEEs, como se discutió, pueden ser socavados por errores de hardware o canales laterales. La seguridad de ZK y FHE puede ser socavada si las matemáticas subyacentes (digamos, una curva elíptica o un problema de retículo) se rompen, pero esos son problemas bien estudiados y los ataques probablemente se notarían (además, las elecciones de parámetros pueden mitigar los riesgos conocidos). La seguridad de MPC puede ser rota por adversarios activos si el protocolo no está diseñado para eso (algunos protocolos de MPC asumen participantes "honestos pero curiosos" y podrían fallar si alguien hace trampa abiertamente). En el contexto de la blockchain, una brecha en un TEE podría ser más catastrófica (todos los contratos basados en enclaves podrían estar en riesgo hasta que se parcheen), mientras que una ruptura criptográfica de ZK (como descubrir un fallo en una función hash utilizada por un rollup ZK) también podría ser catastrófica, pero generalmente se considera menos probable dada la suposición más simple. La superficie de ataque es muy diferente: los TEEs tienen que preocuparse por cosas como el análisis de potencia, mientras que ZK tiene que preocuparse por los avances matemáticos.

  • Privacidad de Datos: FHE y ZK ofrecen las garantías de privacidad más fuertes: los datos permanecen protegidos criptográficamente. MPC asegura que los datos se comparten en secreto, por lo que ninguna parte los ve (aunque algo de información podría filtrarse si las salidas son públicas o si los protocolos no están diseñados cuidadosamente). TEE mantiene los datos privados del exterior, pero dentro del enclave los datos se descifran; si alguien de alguna manera obtiene el control del enclave, la confidencialidad de los datos se pierde. Además, los TEEs típicamente permiten que el código haga cualquier cosa con los datos (incluyendo filtrarlos inadvertidamente a través de canales laterales o la red si el código es malicioso). Por lo tanto, los TEEs requieren que también confíes en el código del enclave, no solo en el hardware. En contraste, las ZKPs prueban propiedades del código sin revelar nunca secretos, por lo que ni siquiera tienes que confiar en el código (más allá de que realmente tenga la propiedad probada). Si una aplicación de enclave tuviera un error que filtrara datos a un archivo de registro, el hardware del TEE no lo evitaría, mientras que un sistema de prueba ZK simplemente no revelaría nada excepto la prueba prevista. Este es un matiz: los TEEs protegen contra adversarios externos, pero no necesariamente contra errores lógicos en el propio programa del enclave, mientras que el diseño de ZK fuerza un enfoque más declarativo (pruebas exactamente lo que se pretende y nada más).

  • Composabilidad e Integración: Los TEEs se integran con bastante facilidad en los sistemas existentes: puedes tomar un programa existente, ponerlo en un enclave y obtener algunos beneficios de seguridad sin cambiar demasiado el modelo de programación. ZK y FHE a menudo requieren reescribir el programa en un circuito o forma restrictiva, lo que puede ser un esfuerzo masivo. Por ejemplo, escribir una verificación simple de un modelo de IA en ZK implica transformarlo en una serie de operaciones aritméticas y restricciones, lo que está muy lejos de simplemente ejecutar TensorFlow en un TEE y atestiguar el resultado. De manera similar, MPC puede requerir un protocolo personalizado por caso de uso. Así que desde el punto de vista de la productividad y el costo del desarrollador, los TEEs son atractivos. Hemos visto una adopción más rápida de los TEEs en algunas áreas precisamente porque se pueden aprovechar los ecosistemas de software existentes (muchas bibliotecas se ejecutan en enclaves con pequeños ajustes). ZK/MPC requieren talento de ingeniería especializado que es escaso. Sin embargo, la otra cara de la moneda es que los TEEs producen una solución que a menudo está más aislada (tienes que confiar en ese enclave o en ese conjunto de nodos), mientras que ZK te da una prueba que cualquiera puede verificar en la cadena, lo que la hace altamente componible (cualquier contrato puede verificar una prueba ZK). Así que los resultados de ZK son portátiles: producen una pequeña prueba que cualquier número de otros contratos o usuarios pueden usar para ganar confianza. Los resultados de TEE generalmente vienen en forma de una atestación vinculada a un hardware particular y posiblemente no sucinta; pueden no ser tan fácilmente compartibles o agnósticos a la cadena (aunque puedes publicar una firma del resultado y tener contratos programados para aceptarla si conocen la clave pública del enclave).

En la práctica, estamos viendo enfoques híbridos: por ejemplo, Sanders Network argumenta que TEE, MPC y ZK brillan cada uno en diferentes áreas y pueden complementarse entre sí. Un caso concreto es la identidad descentralizada: se podrían usar pruebas ZK para probar una credencial de identidad sin revelarla, pero esa credencial podría haber sido verificada y emitida por un proceso basado en TEE que verificó tus documentos de forma privada. O considera el escalado: los rollups ZK proporcionan pruebas sucintas para muchas transacciones, pero la generación de esas pruebas podría acelerarse utilizando TEEs para hacer algunos cálculos más rápido (y luego solo probar una afirmación más pequeña). La combinación a veces puede reducir el requisito de confianza en los TEEs (por ejemplo, usar TEEs para el rendimiento, pero aún así verificar la corrección final a través de una prueba ZK o mediante un juego de desafío en la cadena para que un TEE comprometido no pueda hacer trampa sin ser atrapado). Mientras tanto, el MPC se puede combinar con los TEEs haciendo que el nodo de cómputo de cada parte sea un TEE, añadiendo una capa extra para que incluso si algunas partes coluden, todavía no puedan ver los datos de los demás a menos que también rompan la seguridad del hardware.

En resumen, los TEEs ofrecen un camino muy práctico e inmediato hacia la computación segura con supuestos modestos (confianza en el hardware), mientras que ZK y FHE ofrecen un camino más teórico y sin confianza pero a un alto costo computacional, y MPC ofrece un camino de confianza distribuida con costos de red. La elección correcta en Web3 depende de los requisitos de la aplicación:

  • Si necesitas computación rápida y compleja sobre datos privados (como IA, grandes conjuntos de datos), los TEEs (o MPC con pocas partes) son actualmente la única forma factible.
  • Si necesitas máxima descentralización y verificabilidad, las pruebas ZK brillan (por ejemplo, las transacciones de criptomonedas privadas favorecen a ZKP como en Zcash, porque los usuarios no quieren confiar en nada más que en las matemáticas).
  • Si necesitas computación colaborativa entre múltiples partes interesadas, el MPC es naturalmente adecuado (como la gestión de claves multipartita o las subastas).
  • Si tienes datos extremadamente sensibles y la privacidad a largo plazo es una necesidad, el FHE podría ser atractivo si el rendimiento mejora, porque incluso si alguien obtuviera tus textos cifrados años después, sin la clave no aprenderían nada; mientras que un compromiso de enclave podría filtrar secretos retroactivamente si se guardaran registros.

Vale la pena señalar que el espacio de la blockchain está explorando activamente todas estas tecnologías en paralelo. Es probable que veamos combinaciones: por ejemplo, soluciones de Capa 2 que integran TEEs para secuenciar transacciones y luego usan un ZKP para probar que el TEE siguió las reglas (un concepto que se está explorando en algunas investigaciones de Ethereum), o redes MPC que usan TEEs en cada nodo para reducir la complejidad de los protocolos MPC (ya que cada nodo es internamente seguro y puede simular múltiples partes).

En última instancia, TEEs vs ZK vs MPC vs FHE no es una elección de suma cero: cada uno apunta a diferentes puntos en el triángulo de seguridad, rendimiento y falta de confianza. Como dijo un artículo, los cuatro enfrentan un "triángulo imposible" de rendimiento, costo y seguridad; ninguna solución única es superior en todos los aspectos. El diseño óptimo a menudo utiliza la herramienta adecuada para la parte correcta del problema.

6. Adopción en los Principales Ecosistemas de Blockchain

Los Entornos de Ejecución Confiables han visto niveles variables de adopción en diferentes ecosistemas de blockchain, a menudo influenciados por las prioridades de esas comunidades y la facilidad de integración. Aquí evaluamos cómo se están utilizando (o explorando) los TEEs en algunos de los principales ecosistemas: Ethereum, Cosmos y Polkadot, además de tocar otros.

Ethereum (y Capas 1 en General)

En la mainnet de Ethereum misma, los TEEs no son parte del protocolo central, pero se han utilizado en aplicaciones y Capas 2. La filosofía de Ethereum se inclina hacia la seguridad criptográfica (por ejemplo, los emergentes ZK-rollups), pero los TEEs han encontrado roles en oráculos y ejecución off-chain para Ethereum:

  • Servicios de Oráculo: Como se discutió, Chainlink ha incorporado soluciones basadas en TEE como Town Crier. Aunque no todos los nodos de Chainlink usan TEEs por defecto, la tecnología está ahí para fuentes de datos que requieren confianza extra. Además, API3 (otro proyecto de oráculo) ha mencionado el uso de Intel SGX para ejecutar APIs y firmar datos para garantizar la autenticidad. Estos servicios alimentan datos a los contratos de Ethereum con mayores garantías.

  • Capa 2 y Rollups: Hay una investigación y un debate en curso en la comunidad de Ethereum sobre el uso de TEEs en secuenciadores o validadores de rollups. Por ejemplo, el concepto de "ZK-Portal" de ConsenSys y otros han propuesto usar TEEs para hacer cumplir el ordenamiento correcto en rollups optimistas o para proteger al secuenciador de la censura. El artículo de Medium que vimos incluso sugiere que para 2025, los TEE podrían convertirse en una característica predeterminada en algunas L2 para cosas como la protección del trading de alta frecuencia. Proyectos como Catalyst (un DEX de trading de alta frecuencia) y Flashbots (para relés de MEV) han considerado los TEEs para hacer cumplir el ordenamiento justo de las transacciones antes de que lleguen a la blockchain.

  • Ethereum Empresarial: En redes de Ethereum de consorcio o permisionadas, los TEEs son más ampliamente adoptados. El Trusted Compute Framework (TCF) de la Enterprise Ethereum Alliance era básicamente un plan para integrar TEEs en los clientes de Ethereum. Hyperledger Avalon (anteriormente EEA TCF) permite que partes de los contratos inteligentes de Ethereum se ejecuten off-chain en un TEE y luego se verifiquen en la cadena. Varias empresas como IBM, Microsoft e iExec contribuyeron a esto. Aunque en el Ethereum público esto no se ha vuelto común, en despliegues privados (por ejemplo, un grupo de bancos usando Quorum o Besu), los TEEs pueden usarse para que incluso los miembros del consorcio no vean los datos de los demás, solo los resultados autorizados. Esto puede satisfacer los requisitos de privacidad en un entorno empresarial.

  • Proyectos Notables: Aparte de iExec que opera en Ethereum, hubo proyectos como Enigma (que originalmente comenzó como un proyecto de MPC en el MIT, luego pivotó para usar SGX; más tarde se convirtió en Secret Network en Cosmos). Otro fue Decentralized Cloud Services (DCS) en las primeras discusiones de Ethereum. Más recientemente, OAuth (Oasis Ethereum ParaTime) permite que los contratos de Solidity se ejecuten con confidencialidad utilizando el backend TEE de Oasis pero liquidando en Ethereum. Además, algunas dApps basadas en Ethereum como el intercambio de datos médicos o los juegos han experimentado con TEEs al tener un componente de enclave off-chain que interactúa con sus contratos.

Así que la adopción de Ethereum es algo indirecta: no ha cambiado el protocolo para requerir TEEs, pero tiene un rico conjunto de servicios y extensiones opcionales que aprovechan los TEEs para quienes los necesitan. Es importante destacar que los investigadores de Ethereum siguen siendo cautelosos: las propuestas para hacer una "shard solo de TEE" o para integrar profundamente los TEEs han encontrado escepticismo en la comunidad debido a preocupaciones de confianza. En cambio, los TEEs son vistos como "coprocesadores" para Ethereum en lugar de componentes centrales.

Ecosistema Cosmos

El ecosistema de Cosmos es amigable con la experimentación a través de su SDK modular y cadenas soberanas, y Secret Network (cubierto anteriormente) es un excelente ejemplo de la adopción de TEE en Cosmos. Secret Network es en realidad una cadena del SDK de Cosmos con consenso Tendermint, modificada para exigir SGX en sus validadores. Es una de las zonas de Cosmos más prominentes después del Cosmos Hub principal, lo que indica una adopción significativa de la tecnología TEE en esa comunidad. El éxito de Secret en proporcionar privacidad entre cadenas (a través de sus conexiones IBC, Secret puede servir como un centro de privacidad para otras cadenas de Cosmos) es un caso notable de integración de TEE en L1.

Otro proyecto relacionado con Cosmos es Oasis Network (aunque no está construido sobre el SDK de Cosmos, fue diseñado por algunas de las mismas personas que contribuyeron a Tendermint y comparte un ethos similar de arquitectura modular). Oasis es independiente pero puede conectarse a Cosmos a través de puentes, etc. Tanto Secret como Oasis muestran que en el mundo de Cosmos, la idea de "la privacidad como una característica" a través de TEEs ganó suficiente tracción como para justificar redes dedicadas.

Cosmos incluso tiene un concepto de "proveedores de privacidad" para aplicaciones entre cadenas; por ejemplo, una aplicación en una cadena puede llamar a un contrato en Secret Network a través de IBC para realizar un cálculo confidencial y luego recibir el resultado. Esta composabilidad está surgiendo ahora.

Además, el proyecto Anoma (no estrictamente de Cosmos, pero relacionado en el sentido de la interoperabilidad) ha hablado de usar TEEs para arquitecturas centradas en la intención, aunque es más teórico.

En resumen, Cosmos tiene al menos una cadena principal que abraza completamente los TEEs (Secret) y otras que interactúan con ella, lo que ilustra una adopción saludable en esa esfera. La modularidad de Cosmos podría permitir más cadenas de este tipo (por ejemplo, uno podría imaginar una zona de Cosmos especializada en oráculos o identidad basados en TEE).

Polkadot y Substrate

El diseño de Polkadot permite que las parachains se especialicen, y de hecho Polkadot alberga múltiples parachains que utilizan TEEs:

  • Sanders Network: Ya descrito; una parachain que ofrece una nube de cómputo basada en TEE. Sanders ha estado en vivo como parachain, proporcionando servicios a otras cadenas a través de XCMP (paso de mensajes entre cadenas). Por ejemplo, otro proyecto de Polkadot puede descargar una tarea confidencial a los trabajadores de Sanders y recibir una prueba o un resultado de vuelta. La economía de tokens nativa de Sanders incentiva la ejecución de nodos TEE, y tiene una comunidad considerable, lo que indica una fuerte adopción.
  • Integritee: Otra parachain que se centra en soluciones empresariales y de privacidad de datos utilizando TEEs. Integritee permite a los equipos desplegar sus propias side-chains privadas (llamadas Teewasms) donde la ejecución se realiza en enclaves. Se dirige a casos de uso como el procesamiento de datos confidenciales para corporaciones que aún desean anclarse a la seguridad de Polkadot.
  • /Root o Crust?: Hubo ideas sobre el uso de TEEs para almacenamiento descentralizado o balizas aleatorias en algunos proyectos relacionados con Polkadot. Por ejemplo, Crust Network (almacenamiento descentralizado) originalmente planeó una prueba de almacenamiento basada en TEE (aunque luego se movió a otro diseño). Y la parachain aleatoria de Polkadot (Entropy) consideró TEEs vs VRFs.

La dependencia de Polkadot de la gobernanza y las actualizaciones en la cadena significa que las parachains pueden incorporar nueva tecnología rápidamente. Tanto Sanders como Integritee han pasado por actualizaciones para mejorar su integración de TEE (como admitir nuevas características de SGX o refinar los métodos de atestación). La Web3 Foundation también financió esfuerzos anteriores en proyectos TEE basados en Substrate como SubstraTEE (un prototipo temprano que mostraba la ejecución de contratos off-chain en TEEs con verificación en la cadena).

El ecosistema de Polkadot muestra así múltiples equipos independientes apostando por la tecnología TEE, lo que indica una tendencia de adopción positiva. Se está convirtiendo en un punto de venta para Polkadot que "si necesitas contratos inteligentes confidenciales o cómputo off-chain, tenemos parachains para eso".

Otros Ecosistemas y Adopción General

  • Empresas y Consorcios: Fuera de la cripto pública, Hyperledger y las cadenas empresariales han adoptado constantemente los TEEs para entornos permisionados. Por ejemplo, el Comité de Basilea probó una blockchain de finanzas comerciales basada en TEE. El patrón general es: donde la privacidad o la confidencialidad de los datos es una necesidad, y los participantes son conocidos (por lo que incluso podrían invertir colectivamente en módulos de seguridad de hardware), los TEEs encuentran un hogar cómodo. Puede que no aparezcan en las noticias de cripto, pero en sectores como la cadena de suministro, los consorcios bancarios o las redes de intercambio de datos de salud, los TEEs son a menudo la opción preferida (como alternativa a simplemente confiar en un tercero o usar criptografía pesada).

  • Capas 1 fuera de Ethereum: Algunas L1 más nuevas han incursionado con TEEs. NEAR Protocol tuvo un concepto temprano de una shard basada en TEE para contratos privados (aún no implementado). Celo consideró los TEEs para pruebas de clientes ligeros (sus pruebas Plumo ahora se basan en snarks, pero en un momento consideraron SGX para comprimir datos de la cadena para móviles). Concordium, una L1 de privacidad regulada, utiliza ZK para el anonimato pero también explora TEEs para la verificación de identidad. Dfinity/Internet Computer utiliza enclaves seguros en sus máquinas de nodos, pero para el arranque de la confianza (no para la ejecución de contratos, ya que su criptografía "Chain Key" se encarga de eso).

  • Bitcoin: Aunque Bitcoin en sí no utiliza TEEs, ha habido proyectos paralelos. Por ejemplo, soluciones de custodia basadas en TEE (como sistemas de Bóveda) para claves de Bitcoin, o ciertas propuestas en DLC (Contratos de Registro Discreto) para usar oráculos que podrían estar asegurados por TEE. Generalmente, la comunidad de Bitcoin es más conservadora y no confiaría fácilmente en Intel como parte del consenso, pero como tecnología auxiliar (billeteras de hardware con elementos seguros) ya está aceptada.

  • Reguladores y Gobiernos: Una faceta interesante de la adopción: algunas investigaciones sobre CBDC (moneda digital de banco central) han considerado los TEEs para hacer cumplir la privacidad mientras permiten la auditabilidad. Por ejemplo, el Banco de Francia realizó experimentos en los que utilizaron un TEE para manejar ciertas verificaciones de cumplimiento en transacciones que de otro modo serían privadas. Esto muestra que incluso los reguladores ven los TEEs como una forma de equilibrar la privacidad con la supervisión: podrías tener una CBDC donde las transacciones están cifradas para el público pero un enclave regulador puede revisarlas bajo ciertas condiciones (esto es hipotético, pero se discute en círculos de políticas).

  • Métricas de Adopción: Es difícil cuantificar la adopción, pero podemos observar indicadores como: número de proyectos, fondos invertidos, disponibilidad de infraestructura. En ese frente, hoy (2025) tenemos: al menos 3-4 cadenas públicas (Secret, Oasis, Sanders, Integritee, Automata como off-chain) que utilizan explícitamente TEEs; las principales redes de oráculos lo incorporan; grandes empresas tecnológicas respaldan la computación confidencial (Microsoft Azure, Google Cloud ofrecen VMs TEE, y estos servicios están siendo utilizados por nodos de blockchain como opciones). El Confidential Computing Consortium ahora incluye miembros centrados en blockchain (Ethereum Foundation, Chainlink, Fortanix, etc.), lo que muestra una colaboración interindustrial. Todo esto apunta a una adopción creciente pero de nicho: los TEEs aún no son ubicuos en Web3, pero han encontrado nichos importantes donde se requiere privacidad y cómputo seguro off-chain.

7. Consideraciones Empresariales y Regulatorias

El uso de TEEs en aplicaciones de blockchain plantea varios puntos empresariales y regulatorios que las partes interesadas deben considerar:

Cumplimiento de la Privacidad y Adopción Institucional

Uno de los impulsores empresariales para la adopción de TEE es la necesidad de cumplir con las regulaciones de privacidad de datos (como GDPR en Europa, HIPAA en los EE. UU. para datos de salud) mientras se aprovecha la tecnología blockchain. Las blockchains públicas por defecto transmiten datos a nivel mundial, lo que entra en conflicto con las regulaciones que requieren que los datos personales sensibles estén protegidos. Los TEEs ofrecen una forma de mantener los datos confidenciales en la cadena y solo compartirlos de manera controlada, permitiendo así el cumplimiento. Como se señaló, "los TEEs facilitan el cumplimiento de las regulaciones de privacidad de datos al aislar los datos sensibles del usuario y garantizar que se manejen de forma segura". Esta capacidad es crucial para atraer a empresas e instituciones a Web3, ya que no pueden arriesgarse a violar las leyes. Por ejemplo, una dApp de atención médica que procesa información de pacientes podría usar TEEs para garantizar que ningún dato bruto de pacientes se filtre en la cadena, satisfaciendo los requisitos de HIPAA de cifrado y control de acceso. De manera similar, un banco europeo podría usar una cadena basada en TEE para tokenizar y comerciar activos sin exponer los detalles personales de los clientes, alineándose con el GDPR.

Esto tiene un ángulo regulatorio positivo: algunos reguladores han indicado que soluciones como los TEEs (y conceptos relacionados de computación confidencial) son favorables porque proporcionan una aplicación técnica de la privacidad. Hemos visto al Foro Económico Mundial y a otros destacar los TEEs como un medio para construir "privacidad por diseño" en los sistemas de blockchain (esencialmente incorporando el cumplimiento a nivel de protocolo). Por lo tanto, desde una perspectiva empresarial, los TEEs pueden acelerar la adopción institucional al eliminar uno de los bloqueadores clave (la confidencialidad de los datos). Las empresas están más dispuestas a usar o construir sobre blockchain si saben que hay una salvaguarda de hardware para sus datos.

Otro aspecto del cumplimiento es la auditabilidad y la supervisión. Las empresas a menudo necesitan registros de auditoría y la capacidad de demostrar a los auditores que tienen el control de los datos. Los TEEs pueden ayudar aquí al producir informes de atestación y registros seguros de lo que se accedió. Por ejemplo, el "registro duradero" de Oasis en un enclave proporciona un registro resistente a la manipulación de operaciones sensibles. Una empresa puede mostrar ese registro a los reguladores para demostrar que, por ejemplo, solo se ejecutó código autorizado y solo se realizaron ciertas consultas sobre los datos de los clientes. Este tipo de auditoría atestiguada podría satisfacer a los reguladores más que un sistema tradicional donde se confía en los registros del administrador del sistema.

Confianza y Responsabilidad

Por otro lado, la introducción de TEEs cambia la estructura de confianza y, por lo tanto, el modelo de responsabilidad en las soluciones de blockchain. Si una plataforma DeFi utiliza un TEE y algo sale mal debido a un fallo de hardware, ¿quién es responsable? Por ejemplo, considera un escenario en el que un error de Intel SGX conduce a una fuga de detalles de transacciones de intercambio secretas, lo que hace que los usuarios pierdan dinero (front-running, etc.). Los usuarios confiaron en las afirmaciones de seguridad de la plataforma. ¿Es culpa de la plataforma o de Intel? Legalmente, los usuarios podrían ir tras la plataforma (quien a su vez podría tener que ir tras Intel). Esto complica las cosas porque tienes un proveedor de tecnología de terceros (el proveedor de la CPU) profundamente involucrado en el modelo de seguridad. Las empresas que utilizan TEEs deben considerar esto en los contratos y las evaluaciones de riesgos. Algunas podrían buscar garantías o soporte de los proveedores de hardware si utilizan sus TEEs en infraestructura crítica.

También está la preocupación por la centralización: si la seguridad de una blockchain depende del hardware de una sola empresa (Intel o AMD), los reguladores podrían verlo con escepticismo. Por ejemplo, ¿podría un gobierno citar o coaccionar a esa empresa para comprometer ciertos enclaves? Esta no es una preocupación puramente teórica; considera las leyes de control de exportaciones: el hardware de cifrado de alto grado puede estar sujeto a regulación. Si una gran parte de la infraestructura cripto depende de los TEEs, es concebible que los gobiernos puedan intentar insertar puertas traseras (aunque no hay evidencia de ello, la percepción importa). Algunos defensores de la privacidad señalan esto a los reguladores: que los TEEs concentran la confianza y, en todo caso, los reguladores deberían examinarlos cuidadosamente. Por el contrario, los reguladores que desean más control podrían preferir los TEEs sobre la privacidad basada en matemáticas como ZK, porque con los TEEs hay al menos una noción de que las fuerzas del orden podrían acercarse al proveedor de hardware con una orden judicial si fuera absolutamente necesario (por ejemplo, para obtener una clave de atestación maestra o algo así, no es que sea fácil o probable, pero es una vía que no existe con ZK). Así que la recepción regulatoria puede dividirse: los reguladores de privacidad (agencias de protección de datos) están a favor de los TEE para el cumplimiento, mientras que las fuerzas del orden podrían ser cautelosamente optimistas ya que los TEEs no están "a oscuras" de la misma manera que el cifrado fuerte; hay una palanca teórica (el hardware) que podrían intentar usar.

Las empresas necesitan navegar esto posiblemente participando en certificaciones. Existen certificaciones de seguridad como FIPS 140 o Common Criteria para módulos de hardware. Actualmente, SGX y otros tienen algunas certificaciones (por ejemplo, SGX tuvo certificación Common Criteria EAL para ciertos usos). Si una plataforma de blockchain puede señalar que la tecnología del enclave está certificada con un alto estándar, los reguladores y socios podrían sentirse más cómodos. Por ejemplo, un proyecto de CBDC podría requerir que cualquier TEE utilizado esté certificado por FIPS para confiar en su generación de números aleatorios, etc. Esto introduce un proceso adicional y posiblemente restringe a ciertas versiones de hardware.

Consideraciones de Ecosistema y Costo

Desde una perspectiva empresarial, el uso de TEEs podría afectar la estructura de costos de una operación de blockchain. Los nodos deben tener CPUs específicas (que podrían ser más caras o menos eficientes energéticamente). Esto podría significar facturas de alojamiento en la nube más altas o gastos de capital. Por ejemplo, si un proyecto exige Intel Xeon con SGX para todos los validadores, eso es una restricción: los validadores no pueden ser cualquiera con una Raspberry Pi o una computadora portátil vieja; necesitan ese hardware. Esto puede centralizar quién puede participar (posiblemente favoreciendo a aquellos que pueden permitirse servidores de alta gama o que utilizan proveedores de la nube que ofrecen VMs SGX). En casos extremos, podría empujar a la red a ser más permisionada o a depender de proveedores de la nube, lo cual es un compromiso de descentralización y un compromiso empresarial (la red podría tener que subsidiar a los proveedores de nodos).

Por otro lado, algunas empresas podrían encontrar esto aceptable porque quieren validadores conocidos o tienen una lista blanca (especialmente en consorcios empresariales). Pero en las redes cripto públicas, esto ha causado debates; por ejemplo, cuando se requería SGX, la gente preguntaba "¿significa esto que solo los grandes centros de datos ejecutarán nodos?". Es algo que afecta el sentimiento de la comunidad y, por lo tanto, la adopción del mercado. Por ejemplo, algunos puristas de las criptomonedas podrían evitar una cadena que requiere TEEs, etiquetándola como "menos sin confianza" o demasiado centralizada. Por lo tanto, los proyectos tienen que manejar las relaciones públicas y la educación de la comunidad, dejando claro cuáles son los supuestos de confianza y por qué sigue siendo seguro. Vimos a Secret Network abordar el FUD explicando el riguroso monitoreo de las actualizaciones de Intel y que los validadores son penalizados si no actualizan los enclaves, etc., creando básicamente una capa social de confianza sobre la confianza en el hardware.

Otra consideración son las asociaciones y el soporte. El ecosistema empresarial en torno a los TEEs incluye grandes empresas tecnológicas (Intel, AMD, ARM, Microsoft, Google, etc.). Los proyectos de blockchain que utilizan TEEs a menudo se asocian con estas (por ejemplo, iExec asociándose con Intel, Secret Network trabajando con Intel en mejoras de atestación, Oasis con Microsoft en IA confidencial, etc.). Estas asociaciones pueden proporcionar financiación, asistencia técnica y credibilidad. Es un punto estratégico: alinearse con la industria de la computación confidencial puede abrir puertas (para financiación o pilotos empresariales), pero también significa que un proyecto cripto podría alinearse con grandes corporaciones, lo que tiene implicaciones ideológicas en la comunidad.

Incertidumbres Regulatorias

A medida que crecen las aplicaciones de blockchain que utilizan TEEs, pueden surgir nuevas preguntas regulatorias. Por ejemplo:

  • Jurisdicción de Datos: Si los datos se procesan dentro de un TEE en un país determinado, ¿se considera que se "procesan en ese país" o en ninguna parte (ya que están cifrados)? Algunas leyes de privacidad requieren que los datos de los ciudadanos no salgan de ciertas regiones. Los TEEs podrían difuminar las líneas: podrías tener un enclave en una región de la nube, pero solo entran/salen datos cifrados. Es posible que los reguladores necesiten aclarar cómo ven dicho procesamiento.
  • Controles de Exportación: La tecnología de cifrado avanzada puede estar sujeta a restricciones de exportación. Los TEEs implican el cifrado de la memoria; históricamente esto no ha sido un problema (ya que las CPUs con estas características se venden a nivel mundial), pero si eso cambiara, podría afectar el suministro. Además, algunos países podrían prohibir o desalentar el uso de TEEs extranjeros debido a la seguridad nacional (por ejemplo, China tiene su propio equivalente a SGX, ya que no confían en el de Intel, y podrían no permitir SGX para usos sensibles).
  • Compulsión Legal: Un escenario: ¿podría un gobierno citar a un operador de nodo para extraer datos de un enclave? Normalmente no pueden porque incluso el operador no puede ver dentro. Pero, ¿y si citan a Intel por una clave de atestación específica? El diseño de Intel es tal que ni siquiera ellos pueden descifrar la memoria del enclave (emiten claves a la CPU que hace el trabajo). Pero si existiera una puerta trasera o un firmware especial pudiera ser firmado por Intel para volcar la memoria, esa es una hipótesis que preocupa a la gente. Legalmente, una empresa como Intel podría negarse si se le pidiera socavar su seguridad (probablemente lo harían, para no destruir la confianza en su producto). Pero la mera posibilidad podría aparecer en las discusiones regulatorias sobre el acceso legal. Las empresas que utilizan TEEs deben mantenerse al tanto de cualquier desarrollo de este tipo, aunque actualmente no existe un mecanismo público para que Intel/AMD extraigan datos de enclaves; ese es el punto de los TEEs.

Diferenciación de Mercado y Nuevos Servicios

En el lado positivo para los negocios, los TEEs permiten nuevos productos y servicios que pueden ser monetizados. Por ejemplo:

  • Mercados de datos confidenciales: Como han señalado iExec, Ocean Protocol y otros, las empresas tienen datos valiosos que podrían monetizar si tuvieran garantías de que no se filtrarán. Los TEEs permiten el "alquiler de datos" donde los datos nunca salen del enclave, solo las ideas lo hacen. Esto podría desbloquear nuevas fuentes de ingresos y modelos de negocio. Vemos startups en Web3 que ofrecen servicios de computación confidencial a empresas, esencialmente vendiendo la idea de "obtener ideas de la blockchain o de datos entre empresas sin exponer nada".
  • DeFi Empresarial: Las instituciones financieras a menudo citan la falta de privacidad como una razón para no participar en DeFi o en la blockchain pública. Si los TEEs pueden garantizar la privacidad de sus posiciones o transacciones, podrían participar, trayendo más liquidez y negocio al ecosistema. Los proyectos que atienden a esto (como los préstamos secretos de Secret, o el AMM privado de Oasis con controles de cumplimiento) se están posicionando para atraer a usuarios institucionales. Si tienen éxito, eso puede ser un mercado significativo (imagina pools de AMM institucionales donde las identidades y los montos están protegidos pero un enclave asegura que las verificaciones de cumplimiento como AML se realizan internamente; ese es un producto que podría traer mucho dinero a DeFi con comodidad regulatoria).
  • Seguros y Gestión de Riesgos: Con los TEEs reduciendo ciertos riesgos (como la manipulación de oráculos), podríamos ver primas de seguro más bajas o nuevos productos de seguro para plataformas de contratos inteligentes. Por el contrario, los TEEs introducen nuevos riesgos (como el fallo técnico de los enclaves) que podrían ser eventos asegurables. Hay un área incipiente de seguros cripto; cómo tratan los sistemas dependientes de TEE será interesante. Una plataforma podría comercializar que utiliza TEEs para reducir el riesgo de violación de datos, lo que la haría más fácil/barata de asegurar, dándole una ventaja competitiva.

En conclusión, el panorama empresarial y regulatorio de Web3 habilitado por TEE se trata de equilibrar la confianza y la innovación. Los TEEs ofrecen una ruta para cumplir con las leyes y desbloquear casos de uso empresariales (una gran ventaja para la adopción generalizada), pero también traen una dependencia de los proveedores de hardware y complejidades que deben gestionarse de forma transparente. Las partes interesadas deben interactuar tanto con los gigantes tecnológicos (para obtener soporte) como con los reguladores (para obtener claridad y seguridad) para realizar plenamente el potencial de los TEEs en la blockchain. Si se hace bien, los TEEs podrían ser una piedra angular que permita a la blockchain integrarse profundamente con industrias que manejan datos sensibles, expandiendo así el alcance de Web3 a áreas previamente fuera de los límites debido a preocupaciones de privacidad.

Conclusión

Los Entornos de Ejecución Confiables han surgido como un componente poderoso en la caja de herramientas de Web3, permitiendo una nueva clase de aplicaciones descentralizadas que requieren confidencialidad y computación segura off-chain. Hemos visto que los TEEs, como Intel SGX, ARM TrustZone y AMD SEV, proporcionan una "caja fuerte" aislada por hardware para la computación, y esta propiedad ha sido aprovechada para contratos inteligentes que preservan la privacidad, oráculos verificables, procesamiento escalable off-chain y más. Proyectos en todos los ecosistemas, desde los contratos privados de Secret Network en Cosmos, hasta los ParaTimes confidenciales de Oasis, la nube TEE de Sanders en Polkadot y el mercado off-chain de iExec en Ethereum, demuestran las diversas formas en que los TEEs se están integrando en las plataformas de blockchain.

Técnicamente, los TEEs ofrecen beneficios convincentes de velocidad y fuerte confidencialidad de datos, pero vienen con sus propios desafíos: la necesidad de confiar en los proveedores de hardware, posibles vulnerabilidades de canal lateral y obstáculos en la integración y la composabilidad. Comparamos los TEEs con alternativas criptográficas (ZKPs, FHE, MPC) y encontramos que cada uno tiene su nicho: los TEEs brillan en rendimiento y facilidad de uso, mientras que ZK y FHE proporcionan la máxima falta de confianza a un alto costo, y MPC distribuye la confianza entre los participantes. De hecho, muchas soluciones de vanguardia son híbridas, utilizando TEEs junto con métodos criptográficos para obtener lo mejor de ambos mundos.

La adopción de soluciones basadas en TEE está creciendo constantemente. Las dApps de Ethereum aprovechan los TEEs para la seguridad de los oráculos y los cálculos privados, Cosmos y Polkadot tienen soporte nativo a través de cadenas especializadas, y los esfuerzos de blockchain empresarial están adoptando los TEEs para el cumplimiento. Desde el punto de vista empresarial, los TEEs pueden ser un puente entre la tecnología descentralizada y la regulación, permitiendo que los datos sensibles se manejen en la cadena bajo las salvaguardas de la seguridad del hardware, lo que abre la puerta al uso institucional y a nuevos servicios. Al mismo tiempo, usar TEEs significa comprometerse con nuevos paradigmas de confianza y garantizar que el ethos de descentralización de la blockchain no se vea socavado por un silicio opaco.

En resumen, los Entornos de Ejecución Confiables están desempeñando un papel crucial en la evolución de Web3: abordan algunas de las preocupaciones más apremiantes de privacidad y escalabilidad, y aunque no son una panacea (y no están exentos de controversia), expanden significativamente lo que las aplicaciones descentralizadas pueden hacer. A medida que la tecnología madura, con mejoras en la seguridad del hardware y estándares para la atestación, y a medida que más proyectos demuestran su valor, podemos esperar que los TEEs (junto con la tecnología criptográfica complementaria) se conviertan en un componente estándar de las arquitecturas de blockchain destinadas a desbloquear todo el potencial de Web3 de una manera segura y confiable. El futuro probablemente depara soluciones en capas donde el hardware y la criptografía trabajen de la mano para ofrecer sistemas que sean tanto performantes como demostrablemente seguros, satisfaciendo las necesidades de usuarios, desarrolladores y reguladores por igual.

Fuentes: La información de este informe se recopiló de una variedad de fuentes actualizadas, incluyendo documentación y blogs oficiales de proyectos, análisis de la industria e investigación académica, como se cita a lo largo del texto. Las referencias notables incluyen la guía de Metaschool 2025 sobre TEEs en Web3, comparaciones de Sanders Network, conocimientos técnicos de ChainCatcher y otros sobre FHE/TEE/ZKP/MPC, y declaraciones sobre cumplimiento regulatorio de Binance Research, entre muchos otros. Estas fuentes proporcionan más detalles y se recomiendan para los lectores que deseen explorar aspectos específicos con mayor profundidad.

EIP-7702 Después de Pectra: Manual Práctico para Desarrolladores de Aplicaciones Ethereum

· 10 min de lectura
Dora Noda
Software Engineer

El 7 de mayo de 2025, la actualización Pectra de Ethereum (Prague + Electra) llegó a mainnet. Entre sus cambios más visibles para desarrolladores está EIP-7702, que permite a una cuenta de propiedad externa (EOA) "montar" lógica de smart-contract—sin migrar fondos o cambiar direcciones. Si construyes wallets, dapps, o relayers, esto desbloquea un camino más simple hacia la UX de smart-account.

A continuación hay una guía concisa, orientada a implementación: lo que realmente se lanzó, cómo funciona 7702, cuándo elegirlo sobre ERC-4337 puro, y un andamio de copiar y pegar que puedes adaptar hoy.


Lo Que Realmente Se Lanzó

  • EIP-7702 está en el alcance final de Pectra. El meta-EIP para el hard fork Pectra oficialmente lista 7702 entre los cambios incluidos.
  • Detalles de activación: Pectra se activó en mainnet en la época 364032 el 7 de mayo de 2025, siguiendo activaciones exitosas en todas las testnets principales.
  • Nota de toolchain: Solidity v0.8.30 actualizó su objetivo EVM predeterminado a prague para compatibilidad con Pectra. Necesitarás actualizar tus compiladores y pipelines CI, especialmente si fijas versiones específicas.

EIP-7702—Cómo Funciona (Tuercas y Tornillos)

EIP-7702 introduce un nuevo tipo de transacción y un mecanismo para que una EOA delegue su lógica de ejecución a un smart contract.

  • Nuevo Tipo de Transacción (0x04): Una transacción Tipo-4 incluye un nuevo campo llamado authorization_list. Esta lista contiene una o más tuplas de autorización—(chain_id, address, nonce, y_parity, r, s)—cada una firmada por la clave privada de la EOA. Cuando se procesa esta transacción, el protocolo escribe un indicador de delegación al campo de código de la EOA: 0xef0100 || address. A partir de ese momento, cualquier llamada a la EOA se redirige a la address especificada (la implementación), pero ejecutan dentro del contexto de almacenamiento y balance de la EOA. Esta delegación permanece activa hasta que se cambie explícitamente.
  • Alcance de Chain: Una autorización puede ser específica de chain proporcionando un chain_id, o puede aplicar a todas las chains si chain_id se establece en 0. Esto permite desplegar el mismo contrato de implementación en múltiples redes sin requerir que los usuarios firmen una nueva autorización para cada una.
  • Revocación: Para revertir una EOA de vuelta a su comportamiento original no programable, simplemente envías otra transacción 7702 donde la address de implementación se establece a la dirección cero. Esto limpia el indicador de delegación.
  • Auto-Patrocinado vs. Relayed: Una EOA puede enviar la transacción Tipo-4 ella misma, o un relayer de terceros puede enviarla en nombre de la EOA. Esto último es común para crear una experiencia de usuario sin gas. El manejo de nonce difiere ligeramente dependiendo del método, así que es importante usar bibliotecas que manejen correctamente esta distinción.

Cambio de Modelo de Seguridad: Debido a que la clave privada EOA original aún existe, siempre puede anular cualquier regla de smart contract (como recuperación social o límites de gasto) enviando una nueva transacción 7702 para cambiar la delegación. Este es un cambio fundamental. Los contratos que dependen de tx.origin para verificar que una llamada es de una EOA deben ser re-auditados, ya que 7702 puede romper estas suposiciones. Audita tus flujos en consecuencia.


¿7702 o ERC-4337? (Y Cuándo Combinar)

Tanto EIP-7702 como ERC-4337 habilitan la abstracción de cuenta, pero sirven necesidades diferentes.

  • Elige EIP-7702 cuando…
    • Quieres proporcionar UX de smart-account instantánea para EOAs existentes sin forzar a los usuarios a migrar fondos o cambiar direcciones.
    • Necesitas direcciones consistentes entre chains que puedan actualizarse progresivamente con nuevas características.
    • Quieres escalonar tu transición a la abstracción de cuenta, comenzando con características simples y agregando complejidad con el tiempo.
  • Elige ERC-4337 puro cuando…
    • Tu producto requiere programabilidad completa y motores de política complejos (ej. multi-sig, recuperación avanzada) desde el día uno.
    • Estás construyendo para nuevos usuarios que no tienen EOAs existentes, haciendo nuevas direcciones de smart-account y la configuración asociada aceptables.
  • Combínalos: El patrón más poderoso es usar ambos. Una EOA puede usar una transacción 7702 para designar una implementación de wallet ERC-4337 como su lógica. Esto hace que la EOA se comporte como una cuenta 4337, permitiéndole ser empaquetada, patrocinada por paymasters, y procesada por la infraestructura 4337 existente—todo sin que el usuario necesite una nueva dirección. Este es un camino hacia adelante compatible explícitamente alentado por los autores del EIP.

Andamio 7702 Mínimo Que Puedes Adaptar

Aquí hay un ejemplo práctico de un contrato de implementación y el código del lado cliente para activarlo.

1. Un Contrato de Implementación Pequeño y Auditable

Este código de contrato se ejecutará en el contexto de la EOA una vez designado. Manténlo pequeño, auditable, y considera agregar un mecanismo de actualización.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @notice Ejecuta llamadas desde el contexto EOA cuando se designa via EIP-7702.
contract DelegatedAccount {
// Slot de almacenamiento único para evitar colisiones con otros contratos.
bytes32 private constant INIT_SLOT =
0x3fb93b3d3dcd1d1f4b4a1a8db6f4c5d55a1b7f9ac01dfe8e53b1b0f35f0c1a01;

event Initialized(address indexed account);
event Executed(address indexed to, uint256 value, bytes data, bytes result);

modifier onlyEOA() {
// Opcional: agregar verificaciones para restringir quién puede llamar ciertas funciones.
_;
}

function initialize() external payable onlyEOA {
// Establecer una bandera de inicialización única en el almacenamiento de la EOA.
bytes32 slot = INIT_SLOT;
assembly {
if iszero(iszero(sload(slot))) { revert(0, 0) } // Revertir si ya está inicializado
sstore(slot, 1)
}
emit Initialized(address(this));
}

function execute(address to, uint256 value, bytes calldata data)
external
payable
onlyEOA
returns (bytes memory result)
{
(bool ok, bytes memory ret) = to.call{value: value}(data);
require(ok, "CALL_FAILED");
emit Executed(to, value, data, ret);
return ret;
}

function executeBatch(address[] calldata to, uint256[] calldata value, bytes[] calldata data)
external
payable
onlyEOA
{
uint256 n = to.length;
require(n == value.length && n == data.length, "LENGTH_MISMATCH");
for (uint256 i = 0; i < n; i++) {
(bool ok, ) = to[i].call{value: value[i]}(data[i]);
require(ok, "CALL_FAILED");
}
}
}

2. Designar el Contrato en una EOA (tx Tipo-4) con viem

Clientes modernos como viem tienen helpers incorporados para firmar autorizaciones y enviar transacciones Tipo-4. En este ejemplo, una cuenta relayer paga el gas para actualizar una eoa.

import { createWalletClient, http, encodeFunctionData } from "viem";
import { sepolia } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";
import { abi, implementationAddress } from "./DelegatedAccountABI";

// 1. Definir el relayer (patrocina gas) y la EOA a ser actualizada
const relayer = privateKeyToAccount(process.env.RELAYER_PK as `0x${string}`);
const eoa = privateKeyToAccount(process.env.EOA_PK as `0x${string}`);

const client = createWalletClient({
account: relayer,
chain: sepolia,
transport: http(),
});

// 2. La EOA firma la autorización apuntando al contrato de implementación
const authorization = await client.signAuthorization({
account: eoa,
contractAddress: implementationAddress,
// Si la EOA misma fuera a enviar esto, agregarías: executor: 'self'
});

// 3. El relayer envía una transacción Tipo-4 para establecer el código de la EOA y llamar initialize()
const hash = await client.sendTransaction({
to: eoa.address, // El destino es la EOA misma
authorizationList: [authorization], // El nuevo campo EIP-7702
data: encodeFunctionData({ abi, functionName: "initialize" }),
});

// 4. Ahora, la EOA puede ser controlada via su nueva lógica sin más autorizaciones
// Por ejemplo, para ejecutar una transacción:
// await client.sendTransaction({
// to: eoa.address,
// data: encodeFunctionData({ abi, functionName: 'execute', args: [...] })
// });

3. Revocar Delegación (De Vuelta a EOA Simple)

Para deshacer la actualización, haz que la EOA firme una autorización que designe la dirección cero como la implementación y envía otra transacción Tipo-4. Después, una llamada a eth_getCode(eoa.address) debería retornar bytes vacíos.


Patrones de Integración Que Funcionan en Producción

  • Actualizar en Sitio para Usuarios Existentes: En tu dapp, detecta si el usuario está en una red compatible con Pectra. Si es así, muestra un botón opcional "Actualizar Cuenta" que activa la firma de autorización única. Mantén caminos de respaldo (ej. approve + swap clásico) para usuarios con wallets más antiguas.
  • Onboarding Sin Gas: Usa un relayer (ya sea tu backend o un servicio) para patrocinar la transacción Tipo-4 inicial. Para transacciones sin gas continuas, enruta operaciones de usuario a través de un bundler ERC-4337 para aprovechar paymasters existentes y mempools públicas.
  • Despliegues Cross-Chain: Usa una autorización chain_id = 0 para designar el mismo contrato de implementación en todas las chains. Luego puedes habilitar o deshabilitar características por chain dentro de tu lógica de aplicación.
  • Observabilidad: Tu backend debería indexar transacciones Tipo-4 y parsear el authorization_list para rastrear qué EOAs han sido actualizadas. Después de una transacción, verifica el cambio llamando eth_getCode y confirmando que el código de la EOA ahora coincide con el indicador de delegación (0xef0100 || implementationAddress).

Modelo de Amenaza y Gotchas (No Te Saltes Esto)

  • La Delegación es Persistente: Trata los cambios al contrato de implementación de una EOA con la misma gravedad que una actualización estándar de smart contract. Esto requiere auditorías, comunicación clara al usuario, e idealmente, un flujo opt-in. Nunca empujes nueva lógica a los usuarios silenciosamente.
  • Minas Terrestres de tx.origin: Cualquier lógica que usó msg.sender == tx.origin para asegurar que una llamada vino directamente de una EOA ahora es potencialmente vulnerable. Este patrón debe ser reemplazado con verificaciones más robustas, como firmas EIP-712 o listas de permitidos explícitas.
  • Matemáticas de Nonce: Cuando una EOA patrocina su propia transacción 7702 (executor: 'self'), su nonce de autorización y nonce de transacción interactúan de manera específica. Siempre usa una biblioteca que maneje esto correctamente para evitar problemas de replay.
  • Responsabilidad de UX de Wallet: La especificación EIP-7702 advierte que las dapps no deberían pedir a los usuarios que firmen designaciones arbitrarias. Es responsabilidad del wallet verificar las implementaciones propuestas y asegurar que son seguras. Diseña tu UX para alinearse con este principio de seguridad mediada por wallet.

Cuándo 7702 es una Victoria Clara

  • Flujos DEX: Un approve multi-paso y swap puede combinarse en un solo clic usando la función executeBatch.
  • Juegos y Sesiones: Otorga privilegios similares a session-key por tiempo limitado o alcance sin requerir que el usuario cree y financie una nueva wallet.
  • Empresa y Fintech: Habilita transacciones patrocinadas y aplica políticas de gasto personalizadas mientras mantienes la misma dirección corporativa en cada chain para contabilidad e identidad.
  • Puentes L2 e Intents: Crea flujos de meta-transacción más suaves con una identidad EOA consistente en diferentes redes.

Estos casos de uso representan los mismos beneficios centrales prometidos por ERC-4337, pero ahora están disponibles para cada EOA existente con solo una autorización única.


Lista de Verificación de Envío

Protocolo

  • Asegurar que nodos, SDKs, y proveedores de infraestructura soporten transacciones Tipo-4 y EVM "prague" de Pectra.
  • Actualizar indexadores y herramientas de analítica para parsear el campo authorization_list en nuevas transacciones.

Contratos

  • Desarrollar un contrato de implementación mínimo y auditado con características esenciales (ej. batching, revocación).
  • Probar a fondo los flujos de revocar y re-designar en testnets antes de desplegar a mainnet.

Clientes

  • Actualizar bibliotecas del lado cliente (viem, ethers, etc.) y probar las funciones signAuthorization y sendTransaction.
  • Verificar que tanto los caminos de transacción auto-patrocinados como relayed manejen nonces y replays correctamente.

Seguridad

  • Remover todas las suposiciones basadas en tx.origin de tus contratos y reemplazarlas con alternativas más seguras.
  • Implementar monitoreo post-despliegue para detectar cambios de código inesperados en direcciones de usuario y alertar sobre actividad sospechosa.

Línea de fondo: EIP-7702 proporciona una rampa de baja fricción hacia la UX de smart-account para los millones de EOAs ya en uso. Comienza con una implementación pequeña y auditada, usa un camino relayed para configuración sin gas, haz la revocación clara y fácil, y puedes entregar el 90% de los beneficios de la abstracción de cuenta completa—sin el dolor de la rotación de direcciones y migración de activos.

El resurgimiento de la stablecoin de Meta en 2025: planes, estrategia e impacto

· 31 min de lectura

Iniciativa de stablecoin de Meta en 2025 – Anuncios y proyectos

En mayo de 2025, surgieron informes de que Meta (anteriormente Facebook) está volviendo a entrar en el mercado de las stablecoins con nuevas iniciativas centradas en las monedas digitales. Aunque Meta no ha anunciado formalmente una nueva moneda, un informe de Fortune reveló que la compañía está en conversaciones con empresas de criptomonedas sobre el uso de stablecoins para pagos. Estas discusiones aún son preliminares (Meta está en "modo de aprendizaje"), pero marcan el primer movimiento significativo de Meta en el ámbito cripto desde el proyecto Libra/Diem de 2019–2022. Notablemente, Meta tiene como objetivo aprovechar las stablecoins para gestionar los pagos a los creadores de contenido y las transferencias transfronterizas en sus plataformas.

Postura oficial: Meta no ha lanzado ninguna nueva criptomoneda propia a mayo de 2025. Andy Stone, Director de Comunicaciones de Meta, respondió a los rumores aclarando que "Diem está 'muerto'. No hay ninguna stablecoin de Meta". Esto indica que, en lugar de resucitar una moneda interna como Diem, el enfoque de Meta probablemente será integrar stablecoins existentes (posiblemente emitidas por empresas asociadas) en su ecosistema. De hecho, las fuentes sugieren que Meta podría usar múltiples stablecoins en lugar de una única moneda propietaria. En resumen, el proyecto en 2025 no es un relanzamiento de Libra/Diem, sino un nuevo esfuerzo para dar soporte a las stablecoins dentro de los productos de Meta.

Objetivos estratégicos y motivaciones para Meta

La renovada incursión de Meta en el mundo cripto está impulsada por objetivos estratégicos claros. El principal de ellos es reducir la fricción y el costo de los pagos para las transacciones globales de los usuarios. Al usar stablecoins (tokens digitales vinculados 1:1 a una moneda fiduciaria), Meta puede simplificar los pagos transfronterizos y la monetización de creadores para sus más de 3 mil millones de usuarios. Las motivaciones específicas incluyen:

  • Reducción de los costos de pago: Meta realiza innumerables pequeños pagos a colaboradores y creadores en todo el mundo. Los pagos con stablecoins permitirían a Meta pagar a todos en una única moneda vinculada al USD, evitando las altas comisiones de las transferencias bancarias o las conversiones de moneda. Por ejemplo, un creador en India o Nigeria podría recibir una stablecoin en USD en lugar de lidiar con costosas transferencias bancarias internacionales. Esto podría ahorrarle dinero a Meta (menos tarifas de procesamiento) y acelerar los pagos.

  • Micropagos y nuevas fuentes de ingresos: Las stablecoins permiten microtransacciones rápidas y de bajo costo. Meta podría facilitar propinas, compras dentro de la aplicación o reparto de ingresos en incrementos diminutos (centavos o dólares) sin comisiones exorbitantes. Por ejemplo, enviar unos pocos dólares en stablecoin cuesta solo fracciones de centavo en ciertas redes. Esta capacidad es crucial para modelos de negocio como dar propinas a creadores de contenido, el comercio electrónico transfronterizo en Facebook Marketplace o la compra de bienes digitales en el metaverso.

  • Interacción global de usuarios: Una stablecoin integrada en Facebook, Instagram, WhatsApp, etc., funcionaría como una moneda digital universal dentro del ecosistema de Meta. Esto puede mantener a los usuarios y su dinero circulando dentro de las aplicaciones de Meta (similar a cómo WeChat usa WeChat Pay). Meta podría convertirse en una importante plataforma fintech al gestionar remesas, compras y pagos a creadores internamente. Tal movimiento se alinea con el interés de larga data del CEO Mark Zuckerberg en expandir el papel de Meta en los servicios financieros y la economía del metaverso (donde se necesitan monedas digitales para las transacciones).

  • Mantenerse competitivo: La industria tecnológica y financiera en general está adoptando las stablecoins como infraestructura esencial. Rivales y socios financieros están adoptando las stablecoins, desde el lanzamiento de PYUSD de PayPal en 2023 hasta los proyectos de stablecoin de Mastercard, Visa y Stripe. Meta no quiere quedarse atrás en lo que algunos ven como el futuro de los pagos. Volver a entrar en el mundo cripto ahora permite a Meta capitalizar un mercado en evolución (las stablecoins podrían crecer en $2 billones para 2028, según Standard Chartered) y diversificar su negocio más allá de la publicidad.

En resumen, el impulso de Meta hacia las stablecoins se trata de reducir costos, desbloquear nuevas funciones (pagos globales rápidos) y posicionar a Meta como un jugador clave en la economía digital. Estas motivaciones se hacen eco de la visión original de Libra de inclusión financiera, pero con un enfoque más centrado y pragmático en 2025.

Planes de tecnología e infraestructura blockchain

A diferencia del proyecto Libra, que implicaba la creación de una blockchain completamente nueva, la estrategia de Meta para 2025 se inclina hacia el uso de infraestructura blockchain y stablecoins existentes. Según los informes, Meta está considerando la blockchain de Ethereum como una de las bases para estas transacciones de stablecoins. Ethereum es atractiva debido a su madurez y amplia adopción en el ecosistema cripto. De hecho, Meta "planea comenzar a usar stablecoins en la blockchain de Ethereum" para llegar a su masiva base de usuarios. Esto sugiere que Meta podría integrar stablecoins populares basadas en Ethereum (como USDC o USDT) en sus aplicaciones.

Sin embargo, Meta parece abierta a un enfoque multicadena o multimoneda. La compañía "probablemente usará más de un tipo de stablecoin" para diferentes propósitos. Esto podría implicar:

  • Asociación con los principales emisores de stablecoins: Según se informa, Meta ha estado en conversaciones con empresas como Circle (emisor de USDC) y otras. Podría dar soporte a USD Coin (USDC) y Tether (USDT), las dos stablecoins en USD más grandes, para garantizar liquidez y familiaridad para los usuarios. Integrar stablecoins reguladas existentes le ahorraría a Meta el problema de emitir su propio token, al tiempo que proporcionaría una escala inmediata.

  • Utilización de redes eficientes: Meta también parece interesada en redes blockchain de alta velocidad y bajo costo. La contratación de Ginger Baker (más sobre ella a continuación) insinúa esta estrategia. Baker forma parte de la junta de la Stellar Development Foundation, y los analistas señalan que la red de Stellar está diseñada para el cumplimiento normativo y las transacciones baratas. Stellar admite de forma nativa stablecoins reguladas y características como KYC e informes en cadena. Se especula que la billetera de Meta Pay podría aprovechar Stellar para micropagos casi instantáneos (enviar USDC a través de Stellar cuesta una fracción de centavo). En esencia, Meta podría enrutar las transacciones a través de la blockchain que ofrezca la mejor combinación de cumplimiento, velocidad y bajas comisiones (Ethereum para una amplia compatibilidad, Stellar u otras para la eficiencia).

  • Transformación de la billetera Meta Pay: En la parte frontal, es probable que Meta esté actualizando su infraestructura existente de Meta Pay para convertirla en una billetera digital "lista para la descentralización". Meta Pay (anteriormente Facebook Pay) actualmente gestiona pagos tradicionales en las plataformas de Meta. Bajo el liderazgo de Baker, se prevé que admita criptomonedas y stablecoins de manera fluida. Esto significa que los usuarios podrían mantener saldos de stablecoins, enviarlos a sus pares o recibir pagos en la aplicación, con la complejidad de la blockchain gestionada tras bastidores.

Es importante destacar que Meta no está construyendo una nueva moneda o cadena desde cero esta vez. Al utilizar blockchains públicas probadas y monedas emitidas por socios, Meta puede implementar la funcionalidad de stablecoin más rápido y con (esperemos) menos resistencia regulatoria. El plan tecnológico se centra en la integración en lugar de la invención, tejiendo las stablecoins en los productos de Meta de una manera que se sienta natural para los usuarios (por ejemplo, un usuario de WhatsApp podría enviar un pago en USDC tan fácilmente como enviar una foto).

¿Revivir Diem/Novi o empezar de nuevo?

La iniciativa actual de Meta claramente difiere de su esfuerzo pasado con Libra/Diem. Libra (anunciado en 2019) fue un plan ambicioso para una moneda global liderada por Facebook, respaldada por una cesta de activos y gobernada por una asociación de empresas. Más tarde fue rebautizado como Diem (una stablecoin vinculada al USD) pero finalmente fue cerrado a principios de 2022 en medio de una reacción regulatoria adversa. Novi, la billetera de criptomonedas que lo acompañaba, se probó brevemente pero también se descontinuó.

En 2025, Meta no está simplemente reviviendo Diem/Novi. Las diferencias clave en el nuevo enfoque incluyen:

  • Sin una "moneda de Meta" propia (por ahora): Durante Libra, Facebook estaba esencialmente creando su propia moneda. Ahora, los portavoces de Meta enfatizan que "no hay ninguna stablecoin de Meta" en desarrollo. Diem está muerto y no será resucitado. En cambio, el enfoque está en usar stablecoins existentes (emitidas por terceros) como herramientas de pago. Este cambio de emisor a integrador es una lección directa del fracaso de Libra: Meta está evitando la apariencia de acuñar su propio dinero.

  • Estrategia de cumplimiento primero: La amplia visión de Libra asustó a los reguladores que temían que una moneda privada para miles de millones de personas pudiera socavar las monedas nacionales. Hoy, Meta está operando de manera más silenciosa y cooperativa. La compañía está contratando expertos en cumplimiento y fintech (por ejemplo, Ginger Baker) y eligiendo tecnologías conocidas por su cumplimiento regulatorio (por ejemplo, Stellar). Cualquier nueva función de stablecoin probablemente requerirá verificación de identidad y se adherirá a las regulaciones financieras en cada jurisdicción, en contraste con el enfoque inicialmente descentralizado de Libra.

  • Reducción de ambiciones (al menos inicialmente): Libra aspiraba a ser una moneda y un sistema financiero universal. El esfuerzo de Meta en 2025 tiene un alcance inicial más limitado: pagos y transferencias entre pares dentro de las plataformas de Meta. Al apuntar a los pagos de creadores (como micropagos de "hasta $100" en Instagram), Meta está encontrando un caso de uso que es menos probable que alarme a los reguladores que una moneda global a gran escala. Con el tiempo, esto podría expandirse, pero se espera que el despliegue sea gradual y basado en casos de uso, en lugar de un lanzamiento a lo grande de una nueva moneda.

  • Sin asociación pública ni nueva blockchain: Libra fue gestionada por una asociación independiente y requería que los socios ejecutaran nodos en una blockchain completamente nueva. El nuevo enfoque no implica la creación de un consorcio o una red personalizada. Meta está trabajando directamente con empresas de criptomonedas establecidas y aprovechando su infraestructura. Esta colaboración tras bastidores significa menos publicidad y potencialmente menos objetivos regulatorios que la coalición altamente pública de Libra.

En resumen, Meta está empezando de nuevo, utilizando las lecciones de Libra/Diem para trazar un rumbo más pragmático. La compañía esencialmente ha pivotado de "convertirse en un emisor de criptomonedas" a "ser una plataforma amigable con las criptomonedas". Como observó un analista de cripto, si Meta "construye y emite su propia [stablecoin] o se asocia con alguien como Circle está aún por determinarse", pero todas las señales apuntan a asociaciones en lugar de una empresa en solitario como Diem.

Personal clave, asociaciones y colaboraciones

Meta ha realizado contrataciones estratégicas y posibles asociaciones para impulsar esta iniciativa de stablecoin. El movimiento de personal más destacado es la incorporación de Ginger Baker como Vicepresidenta de Producto para pagos y cripto de Meta. Baker se unió a Meta en enero de 2025 específicamente para "ayudar a guiar las exploraciones de stablecoin [de Meta]". Su experiencia es un fuerte indicador de la estrategia de Meta:

  • Ginger Baker – Veterana de Fintech: Baker es una ejecutiva de pagos experimentada. Anteriormente trabajó en Plaid (como Directora de Red), y tiene experiencia en Ripple, Square y Visa, todos actores importantes en pagos/cripto. De manera única, también formó parte de la junta de la Stellar Development Foundation, y fue ejecutiva allí. Al contratar a Baker, Meta gana experiencia tanto en fintech tradicional como en redes blockchain (Ripple y Stellar se centran en transacciones transfronterizas y cumplimiento). Baker ahora está "liderando las renovadas iniciativas de stablecoin de Meta", incluida la transformación de Meta Pay en una billetera lista para cripto. Su liderazgo sugiere que Meta construirá un producto que una los pagos convencionales con las criptomonedas (probablemente asegurando que cosas como integraciones bancarias, una experiencia de usuario fluida, KYC, etc., estén en su lugar junto con los elementos de blockchain).

  • Otros miembros del equipo: Además de Baker, Meta está "agregando personas con experiencia en cripto" a sus equipos para respaldar los planes de stablecoin. Algunos ex miembros del equipo de Libra/Diem pueden estar involucrados tras bastidores, aunque muchos se fueron (por ejemplo, el ex jefe de Novi, David Marcus, se fue para iniciar su propia firma de cripto, y otros pasaron a proyectos como Aptos). El esfuerzo actual parece estar en gran medida bajo la unidad existente de Meta Financial Technologies de Meta (que gestiona Meta Pay). No se han anunciado adquisiciones importantes de empresas de cripto en 2025 hasta ahora; Meta parece depender de contrataciones internas y asociaciones en lugar de comprar una empresa de stablecoin directamente.

  • Posibles asociaciones: Aunque aún no se han nombrado socios oficiales, múltiples empresas de cripto han estado en conversaciones con Meta. Al menos dos ejecutivos de empresas de cripto confirmaron que han tenido discusiones iniciales con Meta sobre los pagos con stablecoins. Es razonable especular que Circle (emisor de USDC) está entre ellos; el informe de Fortune mencionó las actividades de Circle en el mismo contexto. Meta podría asociarse con un emisor de stablecoin regulado (como Circle o Paxos) para gestionar la emisión y custodia de la moneda. Por ejemplo, Meta podría integrar USDC trabajando con Circle, de manera similar a como PayPal se asoció con Paxos para lanzar su propia stablecoin. Otras asociaciones podrían involucrar a proveedores de infraestructura cripto (para seguridad, custodia o integración de blockchain) o empresas fintech en diferentes regiones para el cumplimiento normativo.

  • Asesores/Influencers externos: Vale la pena señalar que el movimiento de Meta se produce mientras otros en el sector tecnológico/financiero intensifican sus esfuerzos con las stablecoins. Empresas como Stripe y Visa hicieron movimientos recientemente (Stripe compró una startup de cripto, Visa se asoció con una plataforma de stablecoin). Meta puede que no se asocie formalmente con estas empresas, pero estas conexiones en la industria (por ejemplo, el pasado de Baker en Visa, o las relaciones comerciales existentes que Meta tiene con Stripe para los pagos) podrían allanar el camino para la adopción de stablecoins. Además, First Digital (emisor de FDUSD) y Tether podrían ver una colaboración indirecta si Meta decide dar soporte a sus monedas para ciertos mercados.

En esencia, la iniciativa de stablecoin de Meta está siendo liderada por expertos de la industria fintech y probablemente implica una estrecha colaboración con actores establecidos del mundo cripto. Vemos un esfuerzo deliberado por incorporar a personas que entienden tanto Silicon Valley como el mundo cripto. Esto es un buen augurio para que Meta navegue los desafíos técnicos y regulatorios con una guía experta.

Estrategia regulatoria y posicionamiento

La regulación es el elefante en la habitación para las ambiciones cripto de Meta. Después de la dura experiencia con Libra (donde los reguladores y legisladores de todo el mundo se opusieron casi unánimemente a la moneda de Facebook), Meta está adoptando una postura muy cautelosa y orientada al cumplimiento en 2025. Los elementos clave del posicionamiento regulatorio de Meta incluyen:

  • Trabajar dentro de los marcos regulatorios: Meta parece tener la intención de trabajar con las autoridades en lugar de intentar eludirlas. Al usar stablecoins reguladas existentes (como USDC, que cumple con las regulaciones estatales de EE. UU. y se somete a auditorías) y al incorporar características de KYC/AML, Meta se está alineando con las normas financieras actuales. Por ejemplo, las características de cumplimiento de Stellar (KYC, detección de sanciones) se señalan explícitamente como alineadas con la necesidad de Meta de mantenerse en buenos términos con los reguladores. Esto sugiere que Meta se asegurará de que los usuarios que realicen transacciones con stablecoins a través de sus aplicaciones estén verificados y que las transacciones puedan ser monitoreadas para detectar actividades ilícitas, de manera similar a cualquier aplicación fintech.

  • Momento político: El clima regulatorio en los EE. UU. ha cambiado desde los días de Libra. A partir de 2025, la administración del presidente Donald Trump se considera más amigable con las criptomonedas que la administración anterior de Biden. Este cambio potencialmente le da a Meta una oportunidad. De hecho, el renovado impulso de Meta llega justo cuando Washington está debatiendo activamente la legislación sobre stablecoins. Un par de proyectos de ley sobre stablecoins están avanzando en el Congreso, y la Ley GENIUS del Senado tiene como objetivo establecer barreras de protección para las stablecoins. Meta podría estar esperando que un marco legal más claro legitime la participación corporativa en la moneda digital. Sin embargo, esto no está exento de oposición: la senadora Elizabeth Warren y otros legisladores han señalado a Meta, instando a que se prohíba a las grandes empresas tecnológicas emitir stablecoins en cualquier nueva ley. Meta tendrá que navegar tales obstáculos políticos, posiblemente enfatizando que no está emitiendo una nueva moneda, sino simplemente usando las existentes (por lo tanto, técnicamente no es la "Moneda de Facebook" que preocupaba al Congreso).

  • Cumplimiento global y local: Más allá de los EE. UU., Meta considerará las regulaciones en cada mercado. Por ejemplo, si introduce pagos con stablecoin en WhatsApp para remesas, podría probarlo en países con reguladores receptivos (similar a cómo se implementó WhatsApp Pay en mercados como Brasil o India con aprobación local). Meta puede colaborar con bancos centrales y reguladores financieros en regiones objetivo para garantizar que su integración de stablecoin cumpla con los requisitos (como estar totalmente respaldada por fiat, ser canjeable y no dañar la estabilidad de la moneda local). El First Digital USD (FDUSD), una de las stablecoins que Meta podría admitir, tiene su sede en Hong Kong y opera bajo las leyes de fideicomiso de esa jurisdicción, lo que sugiere que Meta podría aprovechar regiones con normas favorables a las criptomonedas (por ejemplo, Hong Kong, Singapur) para las fases iniciales.

  • Evitar el "error de Libra": Con Libra, a los reguladores les preocupaba que Meta controlara una moneda global fuera del control gubernamental. La estrategia de Meta ahora es posicionarse como un participante, no como un controlador. Al decir "no hay ninguna stablecoin de Meta", la compañía se distancia de la idea de imprimir dinero. En cambio, Meta puede argumentar que está mejorando la infraestructura de pagos para los usuarios, de manera análoga a ofrecer soporte para PayPal o tarjetas de crédito. Esta narrativa — "solo estamos usando monedas seguras y totalmente reservadas como USDC para ayudar a los usuarios a realizar transacciones" — es probablemente cómo Meta presentará el proyecto a los reguladores para disipar los temores de desestabilizar el sistema monetario.

  • Cumplimiento y licencias: Si Meta decide ofrecer una stablecoin de marca o custodiar las criptomonedas de los usuarios, podría buscar las licencias adecuadas (por ejemplo, convertirse en un transmisor de dinero con licencia, obtener una carta estatal o federal para la emisión de stablecoins a través de una subsidiaria o un banco asociado). Hay precedentes: PayPal obtuvo una carta de fideicomiso de Nueva York (a través de Paxos) para su stablecoin. Meta podría asociarse de manera similar o crear una entidad regulada para cualquier aspecto de custodia. Por ahora, al asociarse con emisores de stablecoins y bancos establecidos, Meta puede confiar en sus aprobaciones regulatorias.

En general, el enfoque de Meta puede verse como una "acomodación regulatoria": está tratando de diseñar el proyecto para que encaje en los marcos legales que los reguladores han construido o están construyendo. Esto incluye un acercamiento proactivo, una expansión lenta y el empleo de expertos que conocen las reglas. Dicho esto, la incertidumbre regulatoria sigue siendo un riesgo. La compañía estará observando de cerca el resultado de los proyectos de ley sobre stablecoins y probablemente participará en discusiones políticas para asegurarse de que pueda avanzar sin obstáculos legales.

Impacto en el mercado y análisis del panorama de las stablecoins

La entrada de Meta en el mundo de las stablecoins podría ser un punto de inflexión para el mercado de las stablecoins, que a principios de 2025 ya está en auge. La capitalización de mercado total de las stablecoins alcanzó un máximo histórico de alrededor de 238238–245 mil millones en abril de 2025, aproximadamente el doble del tamaño del año anterior. Este mercado está actualmente dominado por unos pocos actores clave:

  • Tether (USDT): La stablecoin más grande, con casi el 70% de la cuota de mercado y alrededor de $148 mil millones en circulación a abril. USDT es emitida por Tether Ltd. y es ampliamente utilizada en el trading de criptomonedas y para la liquidez entre exchanges. Es conocida por una menor transparencia en sus reservas, pero ha mantenido su paridad.

  • USD Coin (USDC): La segunda más grande, emitida por Circle (en asociación con Coinbase) con alrededor de $62 mil millones en suministro (≈26% de cuota de mercado). USDC está regulada en EE. UU., totalmente respaldada por efectivo y bonos del tesoro, y es favorecida por las instituciones por su transparencia. Se utiliza tanto en el trading como en un número creciente de aplicaciones fintech convencionales.

  • First Digital USD (FDUSD): Un participante más nuevo (lanzado a mediados de 2023) emitido por First Digital Trust desde Hong Kong. FDUSD creció como una alternativa en plataformas como Binance después de que problemas regulatorios afectaran al propio BUSD de Binance. Para abril de 2025, la capitalización de mercado de FDUSD era de aproximadamente 1.25milmillones.Tuvociertavolatilidad(perdiendobrevementesuparidadde1.25 mil millones. Tuvo cierta volatilidad (perdiendo brevemente su paridad de 1 en abril), pero se promociona por estar basada en un entorno regulatorio más amigable en Asia.

La siguiente tabla compara la integración de stablecoin prevista por Meta con USDT, USDC y FDUSD:

CaracterísticaIniciativa de Stablecoin de Meta (2025)Tether (USDT)USD Coin (USDC)First Digital USD (FDUSD)
Emisor / GestorSin moneda propietaria: Meta se asociará con emisores existentes; la moneda podría ser emitida por un tercero (p. ej., Circle, etc.). Meta integrará stablecoins en sus plataformas, no emitirá las suyas propias (según declaraciones oficiales).Tether Holdings Ltd. (afiliada a iFinex). De propiedad privada; emisor de USDT.Circle Internet Financial (con Coinbase; a través del Centre Consortium). USDC es gobernado por Circle bajo las regulaciones de EE. UU.First Digital Trust, una compañía fiduciaria registrada en Hong Kong, emite FDUSD bajo la Ordenanza de Fideicomisos de HK.
Lanzamiento y estadoNueva iniciativa, en fase de planificación en 2025. Aún no se ha lanzado ninguna moneda (Meta está explorando la integración para comenzar en 2025). Se esperan pruebas internas o pilotos; no disponible públicamente a mayo de 2025.Lanzado en 2014. Establecido con ~$148B en circulación. Ampliamente utilizado en exchanges y cadenas (Ethereum, Tron, etc.).Lanzado en 2018. Establecido con ~$62B en circulación. Usado en trading, DeFi, pagos; disponible en múltiples cadenas (Ethereum, Stellar, otras).Lanzado a mediados de 2023. Jugador emergente con una capitalización de mercado de ~12B(recientemente 1–2B (recientemente ~1.25B). Promovido en exchanges asiáticos (Binance, etc.) como una alternativa regulada de stablecoin en USD.
Tecnología / BlockchainProbablemente soporte multiblockchain. Énfasis en Ethereum para compatibilidad; posiblemente aprovechando Stellar u otras redes para transacciones de bajo costo. La billetera de Meta abstraerá la capa de blockchain para los usuarios.Multicadena: Originalmente en Omni de Bitcoin, ahora principalmente en Tron, Ethereum, etc. USDT existe en más de 10 redes. Rápido en Tron (bajas comisiones); amplia integración en plataformas cripto.Multicadena: Principalmente en Ethereum, con versiones en Stellar, Algorand, Solana, etc. Se enfoca en Ethereum pero se expande para reducir comisiones (también explorando Capa 2).Multicadena: Emitido en Ethereum y BNB Chain (Binance Smart Chain) desde su lanzamiento. Apunta al uso entre cadenas. Se basa en la seguridad de Ethereum y el ecosistema de Binance para la liquidez.
Supervisión regulatoriaMeta se adherirá a las regulaciones a través de socios. Las stablecoins utilizadas estarán totalmente respaldadas (1:1 USD) y los emisores bajo supervisión (p. ej., Circle regulado bajo las leyes estatales de EE. UU.). Meta implementará KYC/AML en sus aplicaciones. La estrategia regulatoria es cooperar y cumplir (especialmente después del fracaso de Diem).Históricamente opaco. Auditorías limitadas; enfrentó prohibiciones regulatorias en NY. Aumentando la transparencia últimamente pero no regulado como un banco. Ha llegado a acuerdos con reguladores por tergiversaciones pasadas. Opera en una zona gris pero es sistémicamente importante debido a su tamaño.Alto cumplimiento. Regulado como valor almacenado bajo las leyes de EE. UU. (Circle tiene una BitLicense de NY, cartas de fideicomiso). Se publican atestaciones de reservas mensuales. Visto como más seguro por las autoridades de EE. UU.; podría buscar una carta federal de stablecoin si se aprueban las leyes.Cumplimiento moderado. Regulado en Hong Kong como un activo mantenido en fideicomiso. Se beneficia de la postura pro-cripto de Hong Kong. Menos escrutinio de los reguladores de EE. UU.; posicionado para servir a mercados donde USDT/USDC enfrentan obstáculos.
Casos de uso e integraciónIntegración en las plataformas de Meta: Usado para pagos a creadores, transferencias P2P, compras en la aplicación a través de Facebook, Instagram, WhatsApp, etc. Dirigido a usuarios convencionales (contexto social/medios) en lugar de traders de cripto. Podría permitir remesas globales (p. ej., enviar dinero a través de WhatsApp) y comercio en el metaverso.Principalmente utilizado en el trading de criptomonedas (como sustituto del dólar en los exchanges). También común en préstamos DeFi y como cobertura contra el dólar en países con inestabilidad monetaria. Menos utilizado en pagos minoristas debido a preocupaciones sobre la volatilidad del emisor.Utilizado tanto en mercados de cripto como en algunas aplicaciones fintech. Popular en DeFi y pares de trading, pero también integrado por procesadores de pago y fintechs (para comercio, remesas). Coinbase y otros permiten USDC para transferencias. Papel creciente en liquidaciones comerciales.Actualmente se utiliza principalmente en exchanges de cripto (Binance) como una opción de liquidez en USD después del declive de BUSD. Cierto potencial para pagos o DeFi con sede en Asia, pero los casos de uso son incipientes. El posicionamiento en el mercado es ser una alternativa compatible para usuarios e instituciones asiáticas.

Impacto proyectado: Si Meta implementa con éxito los pagos con stablecoins, podría expandir significativamente el alcance y el uso de las stablecoins. Las aplicaciones de Meta podrían incorporar a cientos de millones de nuevos usuarios de stablecoins que nunca antes han usado criptomonedas. Esta adopción masiva podría aumentar la capitalización de mercado total de las stablecoins más allá de los líderes actuales. Por ejemplo, si Meta se asocia con Circle para usar USDC a gran escala, la demanda de USDC podría dispararse, desafiando potencialmente el dominio de USDT con el tiempo. Es plausible que Meta pueda ayudar a USDC (o cualquier moneda que adopte) a acercarse al tamaño de Tether, al proporcionar casos de uso fuera del trading (comercio social, remesas, etc.).

Por otro lado, la participación de Meta podría estimular la competencia e innovación entre las stablecoins. Tether y otros incumbentes podrían ajustarse mejorando la transparencia o formando sus propias alianzas con grandes tecnológicas. Podrían surgir nuevas stablecoins diseñadas para redes sociales. Además, el hecho de que Meta admita múltiples stablecoins sugiere que ninguna moneda "monopolizará" el ecosistema de Meta; los usuarios podrían realizar transacciones sin problemas con diferentes tokens de dólar según la región o preferencia. Esto podría llevar a un mercado de stablecoins más diversificado donde el dominio esté más repartido.

También es importante señalar el impulso a la infraestructura que Meta podría proporcionar. Una stablecoin integrada con Meta probablemente necesitará una capacidad robusta para millones de transacciones diarias. Esto podría impulsar mejoras en las blockchains subyacentes (por ejemplo, el escalado de Capa 2 de Ethereum, o un mayor uso de la red Stellar). Ya, los observadores sugieren que el movimiento de Meta podría "aumentar la actividad en [Ethereum] y la demanda de ETH" si muchas transacciones fluyen por allí. De manera similar, si se usa Stellar, su token nativo XLM podría ver una mayor demanda como gas para las transacciones.

Finalmente, la entrada de Meta es un arma de doble filo para la industria cripto: legitima las stablecoins como un mecanismo de pago (potencialmente positivo para la adopción y el crecimiento del mercado), pero también aumenta las apuestas regulatorias. Los gobiernos pueden tratar las stablecoins más como un asunto de importancia nacional si miles de millones de usuarios de redes sociales comienzan a realizar transacciones con ellas. Esto podría acelerar la claridad regulatoria, o las medidas enérgicas, dependiendo de cómo vaya el despliegue de Meta. En cualquier caso, el panorama de las stablecoins para finales de la década de 2020 probablemente será remodelado por la participación de Meta, junto con otros grandes jugadores como PayPal, Visa y los bancos tradicionales que se aventuran en este espacio.

Integración en las plataformas de Meta (Facebook, Instagram, WhatsApp, etc.)

Un aspecto crítico de la estrategia de Meta es la integración fluida de los pagos con stablecoins en su familia de aplicaciones. El objetivo es incorporar la funcionalidad de la moneda digital de una manera fácil de usar en Facebook, Instagram, WhatsApp, Messenger e incluso en nuevas plataformas como Threads. Así es como se espera que se desarrolle la integración en cada servicio:

  • Instagram: Instagram está preparado para ser un campo de pruebas para los pagos con stablecoins. Los creadores en Instagram podrían optar por recibir sus ganancias (por bonos de Reels, ventas de afiliados, etc.) en una stablecoin en lugar de en moneda local. Los informes mencionan específicamente que Meta podría comenzar pagando hasta ~$100 a los creadores a través de stablecoins en Instagram. Esto sugiere un enfoque en pequeños pagos transfronterizos, ideal para influencers en países donde recibir dólares estadounidenses directamente es preferible. Además, Instagram podría permitir dar propinas a los creadores en la aplicación usando stablecoins, o permitir a los usuarios comprar coleccionables digitales y servicios con un saldo de stablecoin. Dado que Instagram ya experimentó con funciones de visualización de NFT (en 2022) y tiene un mercado de creadores, agregar una billetera de stablecoin podría mejorar su ecosistema de creadores.

  • Facebook (Meta): En Facebook propiamente dicho, la integración de stablecoins podría manifestarse en las funciones de Facebook Pay/Meta Pay. Los usuarios de Facebook podrían enviarse dinero en los chats usando stablecoins, o donar a recaudaciones de fondos con criptomonedas. Facebook Marketplace (donde la gente compra/vende bienes) podría admitir transacciones con stablecoins, permitiendo un comercio transfronterizo más fácil al eliminar los problemas de cambio de moneda. Otra área son los juegos y aplicaciones en Facebook: los desarrolladores podrían recibir pagos en stablecoins, o las compras dentro del juego podrían utilizar una stablecoin para una experiencia universal. Dada la amplia base de usuarios de Facebook, integrar una billetera de stablecoin en el perfil o en Messenger podría popularizar rápidamente el concepto de enviar "dólares digitales" a amigos y familiares. Las propias publicaciones de Meta insinúan la monetización de contenido: por ejemplo, pagar bonos a los creadores de contenido de Facebook o que las Estrellas (los tokens de propina de Facebook) estén potencialmente respaldadas por stablecoins en el futuro.

  • WhatsApp: Esta es quizás la integración más transformadora. WhatsApp tiene más de 2 mil millones de usuarios y se utiliza intensamente para la mensajería en regiones donde las remesas son cruciales (India, América Latina, etc.). La stablecoin de Meta podría convertir WhatsApp en una plataforma global de remesas. Los usuarios podrían enviar una stablecoin a un contacto tan fácilmente como enviar un texto, con WhatsApp manejando el cambio de moneda en cada extremo si es necesario. De hecho, WhatsApp probó brevemente la billetera Novi en 2021 para enviar una stablecoin (USDP) en EE. UU. y Guatemala, por lo que el concepto está probado a pequeña escala. Ahora Meta podría incorporar transferencias de stablecoins de forma nativa en la interfaz de usuario de WhatsApp. Por ejemplo, un trabajador indio en EE. UU. podría enviar USDC a través de WhatsApp a su familia en la India, quienes podrían luego retirarlo o gastarlo si existen integraciones con proveedores de pago locales. Esto evita las costosas tarifas de remesas. Además de P2P, las pequeñas empresas en WhatsApp (comunes en mercados emergentes) podrían aceptar pagos con stablecoins por bienes, usándolo como un sistema de pago para comerciantes de bajo costo. El análisis de Altcoin Buzz incluso especula que WhatsApp será uno de los próximos puntos de integración después de los pagos a creadores.

  • Messenger: Similar a WhatsApp, Facebook Messenger podría permitir el envío de dinero en los chats usando stablecoins. Messenger ya tiene pagos fiduciarios entre pares en los EE. UU. Si se extiende a las stablecoins, podría conectar a usuarios internacionalmente. Se podría imaginar chatbots de Messenger o servicio al cliente utilizando transacciones de stablecoin (por ejemplo, pagar una factura o pedir productos a través de una interacción en Messenger y liquidar en stablecoin).

  • Threads y otros: Threads (la plataforma similar a Twitter de Meta lanzada en 2023) y el Meta VR/Metaverso (Reality Labs) en general también podrían aprovechar las stablecoins. En Horizon Worlds u otras experiencias del metaverso, una stablecoin podría servir como la moneda del mundo para comprar bienes virtuales, entradas a eventos, etc., proporcionando un equivalente de dinero real que viaja a través de las experiencias. Aunque la unidad de metaverso de Meta actualmente opera con pérdidas, integrar una moneda aceptada en todos los juegos y mundos podría crear una economía unificada que podría estimular el uso (al igual que Roblox tiene Robux, pero en el caso de Meta sería una stablecoin en USD bajo el capó). Esto se alinearía con la visión de Zuckerberg de la economía del metaverso, sin crear un nuevo token solo para la RV.

Estrategia de integración: Es probable que Meta implemente esto con cuidado. Una secuencia plausible es:

  1. Pilotar pagos a creadores en Instagram (cantidad limitada, regiones seleccionadas) – esto prueba el sistema con valor real saliendo, pero de manera controlada.
  2. Expandir a transferencias P2P en mensajería (WhatsApp/Messenger) una vez que se gane confianza – comenzando con corredores de remesas o dentro de ciertos países.
  3. Pagos y servicios para comerciantes – permitiendo que las empresas en sus plataformas realicen transacciones en stablecoin (esto podría implicar asociaciones con procesadores de pago para permitir una fácil conversión a fiat local).
  4. Integración completa del ecosistema – eventualmente, la billetera Meta Pay de un usuario podría mostrar un saldo de stablecoin que se puede usar en cualquier lugar, desde anuncios de Facebook, compras en Instagram, pagos de WhatsApp, etc.

Vale la pena señalar que la experiencia del usuario será clave. Es probable que Meta abstraiga términos como "USDC" o "Ethereum" del usuario promedio. La billetera podría simplemente mostrar un saldo en "USD" (impulsado por stablecoins en el backend) para hacerlo simple. Solo los usuarios más avanzados podrían interactuar con funciones en cadena (como retirar a una billetera de cripto externa), si se permite. La ventaja de Meta es su enorme base de usuarios; si incluso una fracción adopta la función de stablecoin, podría superar a la población actual de usuarios de cripto.

En conclusión, el plan de Meta para integrar stablecoins en sus plataformas podría difuminar la línea entre los pagos digitales tradicionales y las criptomonedas. Un usuario de Facebook o WhatsApp pronto podría estar usando una stablecoin sin siquiera darse cuenta de que es un activo cripto; simplemente verán una forma más rápida y barata de enviar dinero y realizar transacciones a nivel mundial. Esta profunda integración podría diferenciar las aplicaciones de Meta en mercados donde la infraestructura financiera es costosa o lenta, y posiciona a Meta como un competidor formidable tanto para las empresas fintech como para los exchanges de cripto en el ámbito de los pagos digitales.

Fuentes:

  • Conversaciones exploratorias de Meta sobre stablecoins y contratación de un VP de cripto
  • Intención de Meta de usar stablecoins para pagos transfronterizos a creadores (informe de Fortune)
  • Comentario del director de comunicaciones de Meta ("Diem está muerto, no hay stablecoin de Meta")
  • Análisis de las motivaciones estratégicas de Meta (reducción de costos, moneda única para pagos)
  • Opciones de infraestructura tecnológica – integración de Ethereum y características de cumplimiento de Stellar
  • El papel y la experiencia de Ginger Baker (ex Plaid, Ripple, junta de Stellar)
  • Perspectivas de Fortune/LinkedIn sobre el equipo de cripto de Meta y las asociaciones en discusión
  • Contexto regulatorio: el colapso de Libra en 2022 y el entorno más amigable de 2025 bajo Trump vs. la oposición legislativa (Sen. Warren sobre la prohibición de stablecoins de las grandes tecnológicas)
  • Datos del mercado de stablecoins (Q2 2025): capitalización de mercado de ~238B,USDT 238B, USDT ~148B vs USDC ~$62B, tendencias de crecimiento
  • Información comparativa para USDT, USDC, FDUSD (cuota de mercado, postura regulatoria, emisores)
  • Detalles de integración en los productos de Meta (pagos a creadores de contenido, pagos de WhatsApp).

Red MPC Ika Respaldada por Sui – Evaluación Técnica y de Inversión Exhaustiva

· 47 min de lectura

Introducción

Ika es una red de Computación Multi-Parte (MPC) paralela respaldada estratégicamente por la Fundación Sui. Anteriormente conocida como dWallet Network, Ika está diseñada para permitir la interoperabilidad cross-chain de confianza cero a alta velocidad y escala. Permite que los contratos inteligentes (especialmente en la blockchain de Sui) controlen y coordinen activos de forma segura en otras blockchains sin necesidad de puentes tradicionales. Este informe ofrece un análisis profundo de la arquitectura técnica y el diseño criptográfico de Ika desde la perspectiva de un fundador, así como un análisis de negocio e inversión que abarca el equipo, la financiación, la tokenomía, la adopción y la competencia. También se incluye una tabla comparativa resumida de Ika frente a otras redes basadas en MPC (Lit Protocol, Threshold Network y Zama) para proporcionar contexto.

Red Ika

Arquitectura Técnica y Características (Perspectiva de un Fundador)

Arquitectura y Primitivas Criptográficas

La innovación principal de Ika es un novedoso esquema criptográfico "2PC-MPC": una computación de dos partes dentro de un marco de computación multi-parte. En términos sencillos, el proceso de firma siempre involucra a dos partes: (1) el usuario y (2) la red Ika. El usuario conserva una parte de la clave privada, y la red, compuesta por muchos nodos independientes, posee la otra parte. Una firma solo puede producirse con la participación de ambos, lo que garantiza que la red por sí sola nunca pueda falsificar una firma sin el usuario. El lado de la red no es una entidad única, sino un MPC distribuido entre N validadores que actúan colectivamente como la segunda parte. Un umbral de al menos dos tercios de estos nodos debe estar de acuerdo (similar al consenso de Tolerancia a Fallos Bizantinos) para generar la parte de la firma correspondiente a la red. Esta estructura de MPC anidado (usuario + red) hace que Ika sea no colusorio: incluso si todos los nodos de Ika conspiraran, no podrían robar los activos del usuario porque la participación del usuario (su parte de la clave) siempre es criptográficamente necesaria. En otras palabras, Ika permite una seguridad de "confianza cero", defendiendo los principios de descentralización y propiedad del usuario de la Web3: ninguna entidad única o grupo pequeño puede comprometer unilateralmente los activos.

Figura: Esquema de la arquitectura 2PC-MPC de Ika: el usuario actúa como una parte (poseyendo una parte de la clave privada) y la red Ika de N validadores forma la otra parte a través de un protocolo de umbral MPC (t-de-N). Esto garantiza que tanto el usuario como una supermayoría de nodos descentralizados deben cooperar para producir una firma válida.

Técnicamente, Ika se implementa como una red blockchain independiente bifurcada del código base de Sui. Ejecuta su propia instancia del motor de consenso de alto rendimiento de Sui (Mysticeti, un protocolo BFT basado en DAG) para coordinar los nodos MPC. Cabe destacar que la versión de Sui de Ika tiene los contratos inteligentes deshabilitados (la cadena de Ika existe únicamente para ejecutar el protocolo MPC) e incluye módulos personalizados para el algoritmo de firma 2PC-MPC. Mysticeti proporciona un canal de difusión fiable entre los nodos, reemplazando la compleja malla de mensajes punto a punto que utilizan los protocolos MPC tradicionales. Al aprovechar un consenso basado en DAG para la comunicación, Ika evita la sobrecarga de comunicación exponencial de los esquemas de firma de umbral anteriores, que requerían que cada una de las n partes enviara mensajes a todas las demás. En su lugar, los nodos de Ika difunden mensajes a través del consenso, logrando una complejidad de comunicación lineal O(n) y utilizando técnicas de procesamiento por lotes y agregación para mantener los costos por nodo casi constantes incluso cuando N crece mucho. Esto representa un avance significativo en la criptografía de umbral: el equipo de Ika reemplazó la comunicación punto a punto "unicast" con una difusión y agregación eficientes, permitiendo que el protocolo soporte a cientos o miles de participantes sin ralentizarse.

Integraciones de conocimiento cero: Actualmente, la seguridad de Ika se logra a través de la criptografía de umbral y el consenso BFT en lugar de pruebas explícitas de conocimiento cero. El sistema no depende de zk-SNARKs o zk-STARKs en su proceso de firma principal. Sin embargo, Ika utiliza pruebas de estado en cadena (pruebas de cliente ligero) para verificar eventos de otras cadenas, lo cual es una forma de verificación criptográfica (por ejemplo, verificar pruebas de Merkle de encabezados de bloque o estado). El diseño deja espacio para integrar técnicas de conocimiento cero en el futuro, por ejemplo, para validar el estado o las condiciones entre cadenas sin revelar datos sensibles, pero a partir de 2025 no hay ningún módulo zk-SNARK específico que forme parte de la arquitectura publicada de Ika. El énfasis se pone en el principio de "confianza cero" (es decir, sin suposiciones de confianza) a través del esquema 2PC-MPC, en lugar de en los sistemas de prueba de conocimiento cero.

Rendimiento y Escalabilidad

Un objetivo principal de Ika es superar los cuellos de botella de rendimiento de las redes MPC anteriores. Los protocolos de firma de umbral heredados (como el 2PC ECDSA de Lindell o GG20) tenían dificultades para soportar más de un puñado de participantes, tardando a menudo muchos segundos o minutos en producir una sola firma. En contraste, el protocolo optimizado de Ika logra una latencia por debajo del segundo para la firma y puede manejar un rendimiento muy alto de solicitudes de firma en paralelo. Las afirmaciones de los benchmarks indican que Ika puede escalar hasta alrededor de 10,000 firmas por segundo mientras mantiene la seguridad en un gran clúster de nodos. Esto es posible gracias a la comunicación lineal mencionada anteriormente y al uso intensivo del procesamiento por lotes: la red puede generar muchas firmas simultáneamente en una ronda de protocolo, amortizando drásticamente los costos. Según el equipo, Ika puede ser "10,000 veces más rápido" que las redes MPC existentes bajo carga. En términos prácticos, esto significa que las transacciones de alta frecuencia en tiempo real (como el trading o las operaciones DeFi cross-chain) pueden ser soportadas sin los retrasos habituales de la firma de umbral. La latencia es del orden de finalidad por debajo del segundo, lo que significa que una firma (y la operación cross-chain correspondiente) puede completarse casi instantáneamente después de la solicitud de un usuario.

Igualmente importante, Ika logra esto mientras escala el número de firmantes para mejorar la descentralización. Las configuraciones MPC tradicionales a menudo usaban un comité fijo de quizás 10-20 nodos para evitar el colapso del rendimiento. La arquitectura de Ika puede expandirse a cientos o incluso miles de validadores participando en el proceso de firma sin una ralentización significativa. Esta descentralización masiva mejora la seguridad (es más difícil para un atacante corromper a una mayoría) y la robustez de la red. El consenso subyacente es tolerante a fallos bizantinos, por lo que la red puede tolerar que hasta un tercio de los nodos estén comprometidos o fuera de línea y seguir funcionando correctamente. En cualquier operación de firma, solo se necesita la participación activa de un umbral t-de-N de nodos (por ejemplo, el 67% de N); por diseño, si demasiados nodos están caídos, la firma podría retrasarse, pero el sistema está diseñado para manejar escenarios de fallo típicos con elegancia (similar a las propiedades de liveness y seguridad del consenso de una blockchain). En resumen, Ika logra tanto un alto rendimiento como un alto número de validadores, una combinación que lo distingue de las soluciones MPC anteriores que tenían que sacrificar la descentralización por la velocidad.

Herramientas para Desarrolladores e Integración

La red Ika está construida para ser amigable para los desarrolladores, especialmente para aquellos que ya construyen en Sui. Los desarrolladores no escriben contratos inteligentes en Ika (ya que la cadena de Ika no ejecuta contratos definidos por el usuario), sino que interactúan con Ika desde otras cadenas. Por ejemplo, un contrato Move de Sui puede invocar la funcionalidad de Ika para firmar transacciones en cadenas externas. Para facilitar esto, Ika proporciona herramientas robustas y SDKs:

  • SDK de TypeScript: Ika ofrece un SDK de TypeScript (biblioteca de Node.js) que refleja el estilo del SDK de Sui. Este SDK permite a los constructores crear y gestionar dWallets (billeteras descentralizadas) y emitir solicitudes de firma a Ika desde sus aplicaciones. Usando el SDK de TS, los desarrolladores pueden generar pares de claves, registrar las partes de los usuarios y llamar al RPC de Ika para coordinar firmas de umbral, todo con patrones familiares de la API de Sui. El SDK abstrae la complejidad del protocolo MPC, haciéndolo tan simple como llamar a una función para solicitar (por ejemplo) una firma de transacción de Bitcoin, dado el contexto apropiado y la aprobación del usuario.

  • CLI y Red Local: Para una interacción más directa, está disponible una interfaz de línea de comandos (CLI) llamada dWallet CLI. Los desarrolladores pueden ejecutar un nodo local de Ika o incluso una red de prueba local bifurcando el repositorio de código abierto. Esto es valioso para pruebas e integración en un entorno de desarrollo. La documentación guía a través de la configuración de una devnet local, la obtención de tokens de testnet (DWLT, el token de la testnet) y la creación de una primera dirección dWallet.

  • Documentación y Ejemplos: La documentación de Ika incluye tutoriales paso a paso para escenarios comunes, como "Tu Primera dWallet". Estos muestran cómo establecer una dWallet que corresponde a una dirección en otra cadena (por ejemplo, una dirección de Bitcoin controlada por las claves de Ika), cómo cifrar la parte de la clave del usuario para su custodia segura y cómo iniciar transacciones cross-chain. El código de ejemplo cubre casos de uso como transferir BTC a través de una llamada a un contrato inteligente de Sui, o programar transacciones futuras (una característica que Ika soporta mediante la cual una transacción puede ser pre-firmada bajo ciertas condiciones).

  • Integración con Sui (Clientes Ligeros): De fábrica, Ika está estrechamente integrado con la blockchain de Sui. La red Ika ejecuta un cliente ligero de Sui internamente para leer datos de la cadena de Sui sin necesidad de confianza. Esto significa que un contrato inteligente de Sui puede emitir un evento o llamada que Ika reconocerá (a través de una prueba de estado) como un disparador para realizar una acción. Por ejemplo, un contrato de Sui podría instruir a Ika: "cuando ocurra el evento X, firma y transmite una transacción en Ethereum". Los nodos de Ika verificarán el evento de Sui usando la prueba del cliente ligero y luego producirán colectivamente la firma para la transacción de Ethereum. La carga útil firmada puede ser entregada a la cadena de destino (posiblemente por un retransmisor fuera de la cadena o por el usuario) para ejecutar la acción deseada. Actualmente, Sui es la primera cadena controladora totalmente soportada (dado los orígenes de Ika en Sui), pero la arquitectura es multi-cadena por diseño. El soporte para pruebas de estado e integraciones de otras cadenas está en la hoja de ruta; por ejemplo, el equipo ha mencionado extender Ika para trabajar con rollups en el ecosistema de Polygon Avail (proporcionando capacidades de dWallet en rollups con Avail como capa de datos) y otras Capas 1 en el futuro.

  • Algoritmos Criptográficos Soportados: La red de Ika puede generar claves/firmas para prácticamente cualquier esquema de firma de blockchain. Inicialmente soporta ECDSA (el algoritmo de curva elíptica utilizado por Bitcoin, las cuentas ECDSA de Ethereum, BNB Chain, etc.). A corto plazo, está previsto que soporte EdDSA (Ed25519, utilizado por cadenas como Solana y algunas cadenas de Cosmos) y firmas Schnorr (por ejemplo, las claves Schnorr de Bitcoin Taproot). Este amplio soporte significa que una dWallet de Ika puede tener una dirección en Bitcoin, una dirección en Ethereum, en Solana, y así sucesivamente, todas controladas por la misma clave distribuida subyacente. Los desarrolladores en Sui u otras plataformas pueden así integrar cualquiera de estas cadenas en sus dApps a través de un marco unificado (Ika), en lugar de lidiar con puentes o custodios específicos de cada cadena.

En resumen, Ika ofrece una experiencia de desarrollador similar a interactuar con un nodo de blockchain o una billetera, abstrayendo la criptografía pesada. Ya sea a través del SDK de TypeScript o directamente a través de contratos Move y clientes ligeros, se esfuerza por hacer que la lógica cross-chain sea "plug-and-play" para los constructores.

Seguridad, Descentralización y Tolerancia a Fallos

La seguridad es primordial en el diseño de Ika. El modelo de confianza cero significa que ningún usuario tiene que confiar en la red Ika con el control unilateral de los activos en ningún momento. Si un usuario crea una dWallet (digamos una dirección de BTC gestionada por Ika), la clave privada de esa dirección nunca es poseída por una sola parte, ni siquiera por el propio usuario. En cambio, el usuario posee una parte secreta y la red posee colectivamente la otra parte. Ambas son necesarias para firmar cualquier transacción. Por lo tanto, incluso si ocurriera el peor de los casos (por ejemplo, que muchos nodos de Ika fueran comprometidos por un atacante), aún no podrían mover fondos sin la parte de la clave secreta del usuario. Esta propiedad aborda un riesgo importante en los puentes convencionales, donde un quórum de validadores podría conspirar para robar los activos bloqueados. Ika elimina ese riesgo cambiando fundamentalmente la estructura de acceso (el umbral se establece de tal manera que la red por sí sola nunca es suficiente; el umbral incluye efectivamente al usuario). En la literatura, este es un nuevo paradigma: una red MPC no colusoria donde el propietario del activo permanece como parte del quórum de firma por diseño.

En el lado de la red, Ika utiliza un modelo de Prueba de Participación delegada (heredado del diseño de Sui) para seleccionar e incentivar a los validadores. Los poseedores de tokens IKA pueden delegar su participación a los nodos validadores; los principales validadores (ponderados por participación) se convierten en las autoridades de una época y son tolerantes a fallos bizantinos (2/3 honestos) en cada época. Esto significa que el sistema asume que <33% de la participación es maliciosa para mantener la seguridad. Si un validador se comporta mal (por ejemplo, intenta producir una parte de firma incorrecta o censurar transacciones), el consenso y el protocolo MPC lo detectarán: las partes de firma incorrectas pueden ser identificadas (no se combinarán en una firma válida), y un nodo malicioso puede ser registrado y potencialmente penalizado ("slashed") o eliminado en futuras épocas. Mientras tanto, la liveness se mantiene siempre que participen suficientes nodos (>67%); el consenso puede continuar finalizando operaciones incluso si muchos nodos se caen o se desconectan inesperadamente. Esta tolerancia a fallos garantiza que el servicio sea robusto: no existe un único punto de fallo, ya que cientos de operadores independientes en diferentes jurisdicciones están participando. La descentralización se refuerza aún más por el gran número de participantes: Ika no se limita a un pequeño comité fijo, por lo que puede incorporar más validadores para aumentar la seguridad sin sacrificar mucho rendimiento. De hecho, el protocolo de Ika fue diseñado explícitamente para "trascender el límite de nodos de las redes MPC" y permitir una descentralización masiva.

Finalmente, el equipo de Ika ha sometido su criptografía a una revisión externa. Publicaron un whitepaper completo en 2024 detallando el protocolo 2PC-MPC, y han pasado por al menos una auditoría de seguridad de terceros hasta ahora. Por ejemplo, en junio de 2024, una auditoría de Symbolic Software examinó la implementación en Rust de Ika del protocolo 2PC-MPC y las bibliotecas criptográficas relacionadas. La auditoría se habría centrado en validar la corrección de los protocolos criptográficos (asegurando que no haya fallos en el esquema ECDSA de umbral, la generación de claves o la agregación de partes) y en buscar posibles vulnerabilidades. El código base es de código abierto (bajo el GitHub de dWallet Labs), lo que permite a la comunidad inspeccionar y contribuir a su seguridad. En la etapa de testnet alfa, el equipo también advirtió que el software todavía era experimental y aún no estaba auditado para producción, pero las auditorías continuas y las mejoras de seguridad eran una prioridad principal antes del lanzamiento de la mainnet. En resumen, el modelo de seguridad de Ika es una combinación de garantías criptográficas demostrables (de esquemas de umbral) y descentralización de grado blockchain (del consenso PoS y el gran conjunto de validadores), revisado por expertos, para proporcionar fuertes garantías tanto contra atacantes externos como contra la colusión interna.

Compatibilidad e Interoperabilidad del Ecosistema

Ika está diseñado específicamente para ser una capa de interoperabilidad, inicialmente para Sui pero extensible a muchos ecosistemas. Desde el primer día, su integración más cercana es con la blockchain de Sui: actúa efectivamente como un módulo adicional para Sui, capacitando a las dApps de Sui con capacidades multi-cadena. Esta estrecha alineación es por diseño: los contratos Move y el modelo centrado en objetos de Sui lo convierten en un buen "controlador" para las dWallets de Ika. Por ejemplo, una aplicación DeFi de Sui puede usar Ika para atraer liquidez de Ethereum o Bitcoin sobre la marcha, convirtiendo a Sui en un centro de liquidez multi-cadena. El apoyo de la Fundación Sui a Ika indica una estrategia para posicionar a Sui como "la cadena base para todas las cadenas", aprovechando Ika para conectarse a activos externos. En la práctica, cuando la mainnet de Ika esté activa, un constructor de Sui podría crear un contrato Move que, por ejemplo, acepte depósitos de BTC: detrás de escena, ese contrato crearía una dWallet de Bitcoin (una dirección) a través de Ika y emitiría instrucciones para mover BTC cuando sea necesario. El usuario final experimenta esto como si Bitcoin fuera solo otro activo gestionado dentro de la aplicación de Sui, aunque el BTC permanezca nativo en Bitcoin hasta que una transacción firmada por umbral válida lo mueva.

Más allá de Sui, la arquitectura de Ika soporta otras blockchains de Capa 1, Capas 2 e incluso sistemas fuera de la cadena. La red puede alojar múltiples clientes ligeros simultáneamente, por lo que puede validar el estado de Ethereum, Solana, Avalanche u otros, permitiendo que los contratos inteligentes en esas cadenas (o sus usuarios) también aprovechen la red MPC de Ika. Aunque tales capacidades podrían implementarse gradualmente, el objetivo de diseño es ser agnóstico a la cadena. Mientras tanto, incluso sin una integración profunda en la cadena, Ika puede usarse de una manera más manual: por ejemplo, una aplicación en Ethereum podría llamar a una API de Ika (a través de un Oráculo o un servicio fuera de la cadena) para solicitar una firma para una transacción o mensaje de Ethereum. Debido a que Ika soporta ECDSA, incluso podría usarse para gestionar la clave de una cuenta de Ethereum de forma descentralizada, de manera similar a cómo funcionan los PKPs de Lit Protocol (discutiremos Lit más adelante). Ika también ha mostrado casos de uso como controlar Bitcoin en rollups, un ejemplo es la integración con el marco de Polygon Avail para permitir a los usuarios de rollups gestionar BTC sin confiar en un custodio centralizado. Esto sugiere que Ika puede colaborar con varios ecosistemas (Polygon/Avail, rollups de Celestia, etc.) como proveedor de infraestructura de claves descentralizada.

En resumen, desde un punto de vista técnico, Ika es compatible con cualquier sistema que dependa de firmas digitales, que son esencialmente todas las blockchains. Su despliegue inicial en Sui es solo el comienzo; la visión a largo plazo es una capa MPC universal a la que cualquier cadena o dApp pueda conectarse para operaciones cross-chain seguras. Al soportar estándares criptográficos comunes (ECDSA, Ed25519, Schnorr) y proporcionar las verificaciones de cliente ligero necesarias, Ika podría convertirse en una especie de red de "MPC-como-servicio" para toda la Web3, uniendo activos y acciones de una manera con confianza minimizada.

Perspectiva de Negocio e Inversión

Equipo Fundador y Antecedentes

Ika fue fundada por un equipo de especialistas experimentados en criptografía y blockchain, principalmente con sede en Israel. El creador y CEO del proyecto es Omer Sadika, un emprendedor con una sólida trayectoria en el espacio de la seguridad cripto. Omer cofundó anteriormente la Red Odsy, otro proyecto centrado en la infraestructura de billeteras descentralizadas, y es el Fundador/CEO de dWallet Labs, la empresa detrás de Ika. Su experiencia incluye formación en Y Combinator (exalumno de YC) y un enfoque en ciberseguridad y sistemas distribuidos. La experiencia de Omer con Odsy y dWallet Labs informó directamente la visión de Ika; en esencia, Ika puede verse como una evolución del concepto de "billetera descentralizada dinámica" en el que Odsy trabajó, ahora implementado como una red MPC en Sui.

El CTO y cofundador de Ika es Yehonatan Cohen Scaly, un experto en criptografía que co-escribió el protocolo 2PC-MPC. Yehonatan lidera la I+D de los novedosos algoritmos criptográficos de Ika y había trabajado previamente en ciberseguridad (posiblemente con investigación académica en criptografía). Se le ha citado discutiendo las limitaciones de los esquemas de umbral existentes y cómo el enfoque de Ika las supera, lo que refleja una profunda experiencia en MPC y protocolos criptográficos distribuidos. Otro cofundador es David Lachmish, quien supervisa el desarrollo de productos. El papel de David es traducir la tecnología central en productos amigables para los desarrolladores y casos de uso del mundo real. El trío de Omer, Yehonatan y David, junto con otros investigadores como el Dr. Dolev Mutzari (VP de Investigación en dWallet Labs), ancla el liderazgo de Ika. Colectivamente, las credenciales del equipo incluyen startups anteriores, contribuciones a la investigación académica y experiencia en la intersección de cripto, seguridad y blockchain. Esta profundidad es la razón por la que se describe a Ika como creada por "algunos de los principales expertos en criptografía del mundo".

Además de los fundadores, el equipo más amplio y los asesores de Ika probablemente cuentan con personas con sólidos antecedentes en criptografía. Por ejemplo, Dolev Mutzari (mencionado anteriormente) es coautor del documento técnico y fundamental en el diseño del protocolo. La presencia de tal talento da confianza a los inversores de que la compleja tecnología de Ika está en manos capaces. Además, tener un fundador (Omer) que ya recaudó fondos con éxito y construyó una comunidad en torno a los conceptos de Odsy/dWallet significa que Ika se beneficia de las lecciones aprendidas en iteraciones anteriores de la idea. La base del equipo en Israel, un país conocido por su sector de criptografía y ciberseguridad, también los sitúa en un rico grupo de talentos para contratar desarrolladores e investigadores.

Rondas de Financiación e Inversores Clave

Ika (y su empresa matriz, dWallet Labs) ha atraído una financiación de riesgo significativa e inversión estratégica desde su inicio. Hasta la fecha, ha recaudado más de **21millonesenmuˊltiplesrondas.Larondasemillainicialdelproyectoenagostode2022fuede21 millones** en múltiples rondas. La **ronda semilla inicial del proyecto en agosto de 2022** fue de 5M, lo cual fue notable dadas las condiciones del mercado bajista en ese momento. Esa ronda semilla incluyó una amplia gama de inversores y ángeles cripto bien conocidos. Entre los participantes notables se encontraban Node Capital (líder), Lemniscap, Collider Ventures, Dispersion Capital, Lightshift Capital, Tykhe Block Ventures, Liquid2 Ventures, Zero Knowledge Ventures y otros. También se unieron inversores individuales prominentes, como Naval Ravikant (cofundador de AngelList e inversor tecnológico destacado), Marc Bhargava (cofundador de Tagomi), Rene Reinsberg (cofundador de Celo) y varias otras figuras de la industria. Tal lista de patrocinadores subrayó una fuerte confianza en el enfoque de Ika hacia la custodia descentralizada incluso en la etapa de idea.

En mayo de 2023, Ika recaudó ~7.5MadicionalesenloquepareceserunaSerieAorondaestrateˊgica,seguˊnseinforma,conunavaloracioˊndealrededorde7.5M adicionales en lo que parece ser una **Serie A o ronda estratégica**, según se informa, con una valoración de alrededor de 250M. Esta ronda fue liderada por Blockchange Ventures y Node Capital (nuevamente), con la participación de Insignius Capital, Rubik Ventures y otros. Para este punto, la tesis de las redes MPC escalables había ganado tracción, y el progreso de Ika probablemente atrajo a estos inversores a redoblar su apuesta. La valoración de $250M para una red en una etapa relativamente temprana reflejaba la expectativa del mercado de que Ika podría convertirse en una infraestructura fundamental en la web3 (a la par con las blockchains L1 o los principales protocolos DeFi en términos de valor).

La inversión de más alto perfil llegó en abril de 2025, cuando la Fundación Sui anunció una inversión estratégica en Ika. Esta asociación con el fondo del ecosistema de Sui elevó la financiación total de Ika por encima de los 21MyconsolidoˊunaestrechaalineacioˊnconlablockchaindeSui.AunquelacantidadexactaqueinvirtioˊlaFundacioˊnSuinosereveloˊpuˊblicamente,estaˊclaroquefueunrespaldosignificativo,probablementedelordendevariosmillonesdeUSD.ElapoyodelaFundacioˊnSuinoessolofinanciero;tambieˊnsignificaqueIkaobtieneunafuerteasistenciaparasaliralmercadodentrodelecosistemadeSui(alcanceadesarrolladores,soportedeintegracioˊn,marketing,etc.).Seguˊnloscomunicadosdeprensa,"Ika...anuncioˊunainversioˊnestrateˊgicadelaFundacioˊnSui,elevandosufinanciacioˊntotalamaˊsde21M y consolidó una estrecha alineación con la blockchain de Sui. Aunque la cantidad exacta que invirtió la Fundación Sui no se reveló públicamente, está claro que fue un respaldo significativo, probablemente del orden de varios millones de USD. El apoyo de la Fundación Sui no es solo financiero; también significa que Ika obtiene una fuerte asistencia para salir al mercado dentro del ecosistema de Sui (alcance a desarrolladores, soporte de integración, marketing, etc.). Según los comunicados de prensa, **"Ika... anunció una inversión estratégica de la Fundación Sui, elevando su financiación total a más de 21 millones"**. Esta ronda estratégica, en lugar de una ronda de capital de riesgo tradicional, destaca que Sui ve a Ika como una infraestructura crítica para el futuro de su blockchain (similar a cómo la Fundación Ethereum podría respaldar directamente un proyecto de Capa 2 o de interoperabilidad que beneficie a Ethereum).

Además de Sui, otros patrocinadores dignos de mención son Node Capital (un fondo cripto con sede en China conocido por sus inversiones tempranas en infraestructura), Lemniscap (un VC cripto centrado en la innovación temprana de protocolos) y Collider Ventures (VC con sede en Israel, que probablemente proporciona apoyo local). El liderazgo de Blockchange Ventures en la ronda de 2023 es notable; Blockchange es un VC que ha respaldado varias jugadas de infraestructura cripto y su liderazgo sugiere que vieron la tecnología de Ika como potencialmente definitoria de una categoría. Además, Digital Currency Group (DCG) y Node Capital lideraron una recaudación de fondos de $5M para dWallet Labs antes del cambio de marca de Ika (según una publicación de Omer en LinkedIn); la participación de DCG (a través de una ronda anterior para la empresa) indica aún más apoyo en segundo plano.

En resumen, el viaje de financiación de Ika muestra una mezcla de VCs tradicionales y socios estratégicos. La participación de la Fundación Sui destaca particularmente, ya que no solo proporciona capital sino también un ecosistema integrado para desplegar la tecnología de Ika. Los inversores están apostando esencialmente a que Ika se convertirá en la solución de referencia para la gestión de claves descentralizada y los puentes en muchas redes, y han valorado el proyecto en consecuencia.

Tokenomía y Modelo Económico

Ika tendrá un token de utilidad nativo llamado $IKA, que es central para la economía y el modelo de seguridad de la red. De manera única, el token IKA se está lanzando en la blockchain de Sui (como un activo nativo de SUI), aunque la red Ika en sí es una cadena separada. Esto significa que IKA existirá como una moneda que se puede mantener y transferir en Sui como cualquier otro activo de Sui, y se utilizará de manera dual: dentro de la red Ika para staking y tarifas, y en Sui para gobernanza o acceso en dApps. La tokenomía se puede describir de la siguiente manera:

  • Tarifas de Gas: Así como ETH es el gas en Ethereum o SUI es el gas en Sui, IKA sirve como el gas/pago para las operaciones MPC en la red Ika. Cuando un usuario o una dApp solicita una firma u operación de dWallet, se paga una tarifa en IKA a la red. Estas tarifas compensan a los validadores por el trabajo de computación y comunicación de ejecutar el protocolo de firma de umbral. El whitepaper compara el papel de IKA con el gas de Sui, confirmando que todas las transacciones cross-chain facilitadas por Ika incurrirán en una pequeña tarifa de IKA. Es probable que la estructura de tarifas sea proporcional a la complejidad de la operación (por ejemplo, una sola firma podría costar una tarifa base, mientras que flujos de trabajo más complejos de varios pasos podrían costar más).

  • Staking y Seguridad: IKA también es un token de staking. Los nodos validadores en la red Ika deben tener una participación delegada de IKA para participar en el consenso y la firma. El consenso sigue una prueba de participación delegada similar a la de Sui: los poseedores de tokens delegan IKA a los validadores, y el peso de cada validador en el consenso (y por lo tanto en los procesos de firma de umbral) está determinado por la participación. En cada época, se eligen los validadores y su poder de voto es una función de la participación, siendo el conjunto general tolerante a fallos bizantinos (lo que significa que si un conjunto de validadores tiene una participación total de XX, hasta ~X/3X/3 de la participación podría ser maliciosa sin romper las garantías de la red). Los stakers (delegadores) son incentivados con recompensas de staking: el modelo de Ika probablemente incluye la distribución de las tarifas recaudadas (y posiblemente recompensas inflacionarias) a los validadores y sus delegadores al final de las épocas. De hecho, la documentación señala que todas las tarifas de transacción recaudadas se distribuyen a las autoridades, quienes pueden compartir una porción con sus delegadores como recompensas. Esto refleja el modelo de Sui de recompensar a los proveedores de servicios por el rendimiento.

  • Suministro y Distribución: A partir de ahora (Q2 2025), los detalles sobre el suministro total, la distribución inicial y la inflación de IKA no son completamente públicos. Sin embargo, dadas las rondas de financiación, podemos inferir alguna estructura. Probablemente, una porción de IKA se asigna a los primeros inversores (rondas semilla y de serie) y al equipo, con una gran parte reservada para la comunidad e incentivos futuros. Puede haber una venta comunitaria o un airdrop planeado, especialmente porque Ika realizó una notable campaña de NFT que recaudó 1.4M SUI, como se mencionó en las noticias (esta fue una campaña de arte NFT en Sui que estableció un récord; es posible que los participantes en esa campaña obtengan recompensas de IKA o acceso anticipado). La campaña de NFT sugiere una estrategia para involucrar a la comunidad y arrancar la distribución de tokens a los usuarios, no solo a los VCs.

  • Momento del Lanzamiento del Token: El anuncio de la Fundación Sui en octubre de 2024 indicó que "El token IKA se lanzará nativamente en Sui, desbloqueando nuevas funcionalidades y utilidad en la seguridad descentralizada". La mainnet estaba programada para diciembre de 2024, por lo que presumiblemente el evento de generación de tokens (TGE) coincidiría o seguiría poco después. Si la mainnet se lanzó según lo programado, los tokens IKA podrían haber comenzado a distribuirse a finales de 2024 o principios de 2025. El token comenzaría entonces a usarse para el gas en la red Ika y para el staking. Antes de eso, en la testnet, se usaba un token temporal (DWLT en la testnet) para el gas, que no tenía valor real.

  • Casos de Uso y Acumulación de Valor: El valor de IKA como inversión depende del uso de la red Ika. A medida que más transacciones cross-chain fluyen a través de Ika, se pagan más tarifas en IKA, creando demanda. Además, si muchos quieren ejecutar validadores o asegurar la red, deben adquirir y hacer staking de IKA, lo que bloquea el suministro (reduciendo la flotación). Por lo tanto, IKA tiene una naturaleza de utilidad más gobernanza: utilidad para pagar servicios y staking, y probablemente gobernanza para dirigir el futuro del protocolo (aunque la gobernanza no se menciona explícitamente todavía, es común que tales redes eventualmente descentralicen el control a través de la votación de tokens). Uno puede imaginar a los poseedores de tokens IKA votando sobre la adición de soporte para nuevas cadenas, el ajuste de los parámetros de tarifas u otras actualizaciones del protocolo en el futuro.

En general, la tokenomía de IKA busca equilibrar la seguridad de la red con la usabilidad. Al lanzarse en Sui, facilitan que los usuarios del ecosistema de Sui obtengan y usen IKA (no se necesita un proceso de incorporación a una cadena separada para el token en sí), lo que puede impulsar la adopción. Los inversores observarán métricas como la porción del suministro en staking (indicando seguridad), los ingresos por tarifas (indicando uso) y las asociaciones que impulsan las transacciones (indicando demanda del token).

Modelo de Negocio y Estrategia de Salida al Mercado

El modelo de negocio de Ika es el de un proveedor de infraestructura en el ecosistema blockchain. No ofrece un producto orientado al consumidor; en su lugar, ofrece un servicio de protocolo (gestión de claves descentralizada y ejecución de transacciones) que otros proyectos integran. Como tal, el principal mecanismo de ingresos (o captura de valor) es la tarifa por servicio, es decir, las tarifas de gas en IKA por usar la red. Se puede comparar a Ika con un AWS descentralizado para la firma de claves: cualquier desarrollador puede conectarse y usarlo, pagando por uso. A largo plazo, a medida que la red se descentralice, dWallet Labs (la empresa fundadora) podría capturar valor manteniendo una participación en la red y a través de la apreciación del token en lugar de cobrar tarifas de estilo SaaS fuera de la cadena.

Estrategia de Salida al Mercado (GTM): Inicialmente, Ika se dirige a desarrolladores de blockchain y proyectos que necesitan funcionalidad cross-chain o soluciones de custodia. La alineación con Sui proporciona un grupo listo de tales desarrolladores. Sui, al ser una L1 más nueva, necesita características únicas para atraer usuarios, e Ika ofrece DeFi cross-chain, acceso a Bitcoin y más en Sui, que son características atractivas. Por lo tanto, la GTM de Ika se apoya en el creciente ecosistema de Sui. Notablemente, incluso antes de la mainnet, varios proyectos de Sui anunciaron que están integrando Ika:

  • Proyectos como Full Sail, Rhei, Aeon, Human Tech, Covault, Lucky Kat, Native, Nativerse, Atoma y Ekko (todos constructores en Sui) han "anunciado sus próximos lanzamientos utilizando Ika", cubriendo casos de uso desde DeFi hasta juegos. Por ejemplo, Full Sail podría estar construyendo un exchange que pueda comerciar BTC a través de Ika; Lucky Kat (un estudio de juegos) podría usar Ika para habilitar activos en el juego que residen en múltiples cadenas; Covault probablemente involucra soluciones de custodia, etc. Al asegurar estas asociaciones temprano, Ika garantiza que en el lanzamiento habrá un volumen de transacciones inmediato y aplicaciones reales que muestren sus capacidades.

  • Ika también está enfatizando los casos de uso institucionales, como la custodia descentralizada para instituciones. En comunicados de prensa, destacan la "seguridad inigualable para usuarios institucionales e individuales" en la custodia a través de Ika. Esto sugiere que Ika podría comercializarse para custodios de criptomonedas, exchanges o incluso actores de TradFi que deseen una forma más segura de gestionar claves privadas (quizás como una alternativa o complemento a Fireblocks o Copper, que usan MPC pero en un entorno empresarial centralizado). De hecho, al ser una red descentralizada, Ika podría permitir que los competidores en custodia confíen todos en la misma red de firma robusta en lugar de que cada uno construya la suya. Este modelo cooperativo podría atraer a instituciones que prefieren un custodio neutral y descentralizado para ciertos activos.

  • Otro ángulo son las integraciones de IA: Ika menciona las "barreras de protección para Agentes de IA" como un caso de uso. Esto es visionario, jugando con la tendencia de la autonomía de la IA (por ejemplo, agentes de IA ejecutando en la blockchain). Ika puede asegurar que un agente de IA (digamos un agente económico autónomo al que se le da el control de algunos fondos) no pueda huir con los fondos porque el agente en sí no es el único poseedor de la clave; aún necesitaría la parte del usuario o cumplir con las condiciones en Ika. Comercializar Ika como proveedor de barreras de seguridad para la IA en Web3 es un ángulo novedoso para captar el interés de ese sector.

Geográficamente, la presencia de Node Capital y otros sugiere un enfoque en Asia también, además del mercado occidental. Sui tiene una fuerte comunidad en Asia (especialmente en China). La campaña de NFT de Ika en Sui (la campaña de arte que recaudó 1.4M SUI) indica un esfuerzo de construcción de comunidad, posiblemente involucrando a usuarios chinos que son ávidos en el espacio de NFT de Sui. Al realizar ventas de NFT o airdrops comunitarios, Ika puede cultivar una base de usuarios de base que posean tokens IKA y estén incentivados a promover su adopción.

Con el tiempo, el modelo de negocio podría extenderse a ofrecer características premium o integraciones empresariales. Por ejemplo, mientras que la red pública de Ika no tiene permisos, dWallet Labs podría crear instancias privadas o versiones de consorcio para ciertos clientes, o proporcionar servicios de consultoría a proyectos que integren Ika. También podrían obtener ingresos ejecutando algunos de los validadores al principio (fase de arranque) y así recaudar parte de las tarifas.

En resumen, la GTM de Ika está fuertemente ligada a las asociaciones del ecosistema. Al integrarse profundamente en la hoja de ruta de Sui (donde los objetivos de Sui para 2025 incluyen liquidez cross-chain y casos de uso únicos), Ika se asegura de que aprovechará el crecimiento de esa L1. Simultáneamente, se posiciona como una solución generalizada para la coordinación multi-cadena, que luego puede ser presentada a proyectos en otras cadenas una vez que se demuestre su éxito en Sui. El respaldo de la Fundación Sui y los anuncios de integración temprana le dan a Ika una ventaja significativa en credibilidad y adopción en comparación con si se lanzara de forma aislada.

Adopción del Ecosistema, Asociaciones y Hoja de Ruta

Incluso en su etapa inicial, Ika ha construido una impresionante lista de compromisos con el ecosistema:

  • Adopción del Ecosistema Sui: Como se mencionó, múltiples proyectos basados en Sui están integrando Ika. Esto significa que tras el lanzamiento de la mainnet de Ika, esperamos ver dApps de Sui habilitando características como "Powered by Ika", por ejemplo, un protocolo de préstamos de Sui que permite a los usuarios depositar BTC, o una DAO en Sui que usa Ika para mantener su tesorería en múltiples cadenas. El hecho de que nombres como Rhei, Atoma, Nativerse (probablemente proyectos DeFi) y Lucky Kat (juegos/NFT) estén a bordo muestra que la aplicabilidad de Ika abarca varios verticales.

  • Asociaciones Estratégicas: La asociación más importante de Ika es con la propia Fundación Sui, que es tanto un inversor como un promotor. Los canales oficiales de Sui (blog, etc.) han presentado a Ika de manera prominente, respaldándola efectivamente como la solución de interoperabilidad para Sui. Además, es probable que Ika haya estado trabajando con otros proveedores de infraestructura. Por ejemplo, dada la mención de zkLogin (la función de inicio de sesión Web2 de Sui) junto con Ika, podría haber un caso de uso combinado donde zkLogin maneja la autenticación del usuario e Ika maneja las transacciones cross-chain, proporcionando juntos una experiencia de usuario fluida. Además, la mención de Ika de Avail (Polygon) en sus blogs sugiere una asociación o piloto en ese ecosistema: quizás con Polygon Labs o equipos que construyen rollups en Avail para usar Ika para puentear Bitcoin a esos rollups. Otro dominio de asociación potencial es con custodios, por ejemplo, integrar Ika con proveedores de billeteras como Zengo (notable ya que el cofundador de ZenGo estuvo en el proyecto anterior de Omer) o con tecnología de custodia institucional como Fireblocks. Aunque no está confirmado, estos serían objetivos lógicos (de hecho, Fireblocks se ha asociado con Sui en otros lugares; uno podría imaginar a Fireblocks aprovechando Ika para MPC en Sui).

  • Compromiso con la Comunidad y los Desarrolladores: Ika tiene un Discord y probablemente organiza hackathons para que los desarrolladores construyan con dWallets. La tecnología es novedosa, por lo que evangelizarla a través de la educación es clave. La presencia de secciones de "Casos de uso" y "Constructores" en su sitio, además de publicaciones de blog que explican conceptos básicos, indica un esfuerzo para que los desarrolladores se sientan cómodos con el concepto de dWallets. Cuantos más desarrolladores entiendan que pueden construir lógica cross-chain sin puentes (y sin comprometer la seguridad), más crecerá la adopción orgánica.

  • Hoja de Ruta: A partir de 2025, la hoja de ruta de Ika incluía:

    • Alfa y Testnet (2023–2024): La testnet alfa se lanzó en 2024 en Sui, permitiendo a los desarrolladores experimentar con dWallets y proporcionar retroalimentación. Esta etapa se utilizó para refinar el protocolo, corregir errores y realizar auditorías internas.
    • Lanzamiento de la Mainnet (Dic 2024): Ika planeaba lanzarse en la mainnet para finales de 2024. Si se logró, para ahora (mediados de 2025) la mainnet de Ika debería estar operativa. El lanzamiento probablemente incluyó soporte inicial para un conjunto de cadenas: al menos Bitcoin y Ethereum (cadenas ECDSA) desde el principio, dado que se mencionaron mucho en el marketing.
    • Objetivos Post-Lanzamiento 2025: En 2025, esperamos que el enfoque esté en escalar el uso (a través de aplicaciones de Sui y posiblemente expandiéndose a otras cadenas). El equipo trabajará en agregar soporte para Ed25519 y Schnorr poco después del lanzamiento, permitiendo la integración con Solana, Polkadot y otros ecosistemas. También implementarán más clientes ligeros (quizás un cliente ligero de Ethereum para Ika, un cliente ligero de Solana, etc.) para ampliar el control sin confianza. Otro punto en la hoja de ruta es probablemente la expansión de validadores sin permisos, fomentando que más validadores independientes se unan y descentralizando aún más la red. Dado que el código es una bifurcación de Sui, ejecutar un validador de Ika es similar a ejecutar un nodo de Sui, lo que muchos operadores pueden hacer.
    • Mejoras de Características: Dos características interesantes insinuadas en los blogs son las Partes de Usuario Cifradas y la Firma de Transacciones Futuras. La parte de usuario cifrada significa que los usuarios pueden cifrar opcionalmente su parte privada y almacenarla en la cadena (quizás en Ika o en otro lugar) de una manera que solo ellos puedan descifrar, simplificando la recuperación. La firma de transacciones futuras implica la capacidad de que Ika pre-firme una transacción que se ejecuta más tarde cuando se cumplen las condiciones. Estas características aumentan la usabilidad (los usuarios no tendrán que estar en línea para cada acción si pre-aprueban cierta lógica, todo mientras mantienen la seguridad no custodial). Entregar esto en 2025 diferenciaría aún más la oferta de Ika.
    • Crecimiento del Ecosistema: Para finales de 2025, Ika probablemente apunta a tener múltiples ecosistemas de cadenas usándolo activamente. Podríamos ver, por ejemplo, un proyecto de Ethereum usando Ika a través de un oráculo (si la integración directa en la cadena aún no está disponible) o colaboraciones con proyectos inter-cadena como Wormhole o LayerZero, donde Ika podría servir como el mecanismo de firma para mensajería segura.

El panorama competitivo también dará forma a la estrategia de Ika. No está solo en ofrecer gestión de claves descentralizada, por lo que parte de su hoja de ruta implicará destacar su ventaja de rendimiento y su modelo de seguridad único de dos partes en contraste con otros. En la siguiente sección, comparamos Ika con sus competidores notables: Lit Protocol, Threshold Network y Zama.

Análisis Competitivo: Ika vs. Otras Redes MPC/de Umbral

Ika opera en un campo de vanguardia de redes criptográficas, donde algunos proyectos persiguen objetivos similares con enfoques variados. A continuación se presenta una comparación resumida de Ika con Lit Protocol, Threshold Network y Zama (cada uno un competidor representativo en infraestructura de claves descentralizada o computación de privacidad):

AspectoIka (Red MPC Paralela)Lit Protocol (PKI y Cómputo)Threshold Network (tBTC y TSS)Zama (Red FHE)
Lanzamiento y EstadoFundada en 2022; Testnet en 2024; Mainnet lanzada en Sui en Dic 2024 (principios de 2025). Token $IKA activo en Sui.Lanzado en 2021; red de nodos Lit activa. Token $LIT (lanzado en 2021). Construyendo el rollup "Chronicle" para escalar.Red lanzada en 2022 tras la fusión de Keep/NuCypher. El token $T gobierna la DAO. tBTC v2 lanzado para el puente de Bitcoin.En desarrollo (sin red pública aún en 2025). Recaudó grandes rondas de VC para I+D. Sin token todavía (herramientas FHE en fase alfa).
Enfoque Principal/Caso de UsoInteroperabilidad y custodia cross-chain: firma de umbral para controlar activos nativos en diferentes cadenas (ej. BTC, ETH) a través de dWallets. Habilita DeFi, dApps multi-cadena, etc.Gestión de claves descentralizada y control de acceso: cifrado/descifrado de umbral y firma condicional a través de PKPs (Pares de Claves Programables). Popular para restringir contenido y automatización cross-chain con "Lit Actions" de JavaScript.Servicios de criptografía de umbral: ej. puente descentralizado de Bitcoin a Ethereum tBTC; ECDSA de umbral para custodia de activos digitales; re-cifrado de proxy de umbral (PRE) para privacidad de datos.Computación que preserva la privacidad: Cifrado Totalmente Homomórfico (FHE) para permitir el procesamiento de datos cifrados y contratos inteligentes privados. Enfocado en la confidencialidad (ej. DeFi privado, ML en cadena) en lugar del control cross-chain.
ArquitecturaBifurcación de la blockchain de Sui (consenso DAG Mysticeti) modificada para MPC. Sin contratos inteligentes de usuario en Ika; utiliza un protocolo 2PC-MPC fuera de la cadena entre ~N validadores + la parte del usuario. Diseño de alto rendimiento (10k TPS).Red descentralizada + L2: los nodos de Lit ejecutan MPC y también un tiempo de ejecución de JS basado en TEE. El Rollup de Arbitrum "Chronicle" se usa para anclar el estado y coordinar los nodos. Utiliza un umbral de 2/3 para el consenso en operaciones de clave.Red descentralizada en Ethereum: los operadores de nodos hacen staking con $T y son seleccionados aleatoriamente en grupos de firma (ej. 100 nodos para tBTC). Utiliza protocolos fuera de la cadena (GG18, etc.) con contratos de Ethereum en la cadena para coordinación y manejo de depósitos.Kits de herramientas FHE sobre cadenas existentes: la tecnología de Zama (ej. bibliotecas Concrete, TFHE) habilita FHE en Ethereum (fhEVM). Planes para un sistema de gestión de claves de umbral (TKMS) para claves FHE. Probablemente se integrará con L1s o se ejecutará como Capa 2 para cómputos privados.
Modelo de Seguridad2PC-MPC, no colusorio: se requiere la parte de la clave del usuario + un umbral de N validadores (2/3 BFT) para cualquier firma. Ninguna entidad única tiene la clave completa. El consenso BFT tolera <33% maliciosos. Auditado por Symbolic (2024).Umbral + TEE: requiere 2/3 de los nodos de Lit para firmar/descifrar. Utiliza Entornos de Ejecución Confiable en cada nodo para ejecutar código proporcionado por el usuario (Lit Actions) de forma segura. La seguridad depende de la honestidad de los nodos y la seguridad del hardware.Multi-parte de umbral: ej. para tBTC, un grupo seleccionado al azar de ~100 nodos debe alcanzar un umbral (ej. 51) para firmar transacciones de BTC. Incentivos económicos (staking de $T, slashing) para mantener una mayoría honesta. Gobernado por DAO; los incidentes de seguridad se manejarían a través de la gobernanza.Basado en FHE: la seguridad se basa en la dureza criptográfica de FHE (aprendizaje con errores, etc.): los datos permanecen cifrados en todo momento. El TKMS de Zama indica el uso de criptografía de umbral para gestionar también las claves FHE. Aún no es una red activa; la seguridad está bajo revisión por académicos.
RendimientoLatencia por debajo del segundo, ~10,000 firmas/seg en teoría. Escala a cientos o miles de nodos sin una pérdida importante de rendimiento (enfoque de difusión y procesamiento por lotes). Adecuado para uso de dApps en tiempo real (trading, juegos).Latencia moderada (más pesada debido a la sobrecarga de TEE y consenso). Lit tiene ~50 nodos; utiliza "shadow splicing" para escalar, pero un gran número de nodos puede degradar el rendimiento. Bueno para tareas de frecuencia moderada (abrir acceso, firma ocasional de tx). La L2 Chronicle ayuda con el procesamiento por lotes.Menor rendimiento, mayor latencia: la acuñación de tBTC puede tardar minutos (esperando confirmaciones de Bitcoin + firma de umbral) y utiliza grupos pequeños para firmar. El enfoque de Threshold es la calidad (seguridad) sobre la cantidad, adecuado para transacciones de puente y control de acceso, no diseñado para miles de TPS.Latencia de cómputo pesada: FHE es actualmente mucho más lento que el cómputo en texto plano (órdenes de magnitud). Zama está optimizando, pero ejecutar contratos privados será más lento y costoso que los normales. No está dirigido a tareas de alta frecuencia; se enfoca en cómputos complejos donde la privacidad es primordial.
DescentralizaciónAlta: conjunto de validadores sin permisos, cientos de validadores posibles. PoS delegado (estilo Sui) asegura una participación abierta y una gobernanza descentralizada con el tiempo. El usuario siempre está en el bucle (no puede ser omitido).Media: actualmente ~30-50 nodos principales operados por el equipo de Lit y socios. Planes para descentralizar más. Los nodos realizan tareas pesadas (MPC + TEE), por lo que escalar no es trivial. La gobernanza aún no está completamente descentralizada (existe Lit DAO pero es temprana).Alta: gran grupo de stakers; sin embargo, la firma real la realizan grupos seleccionados (no toda la red a la vez). La red es tan descentralizada como la distribución de su participación. Gobernado por la DAO de Threshold (votos de los poseedores de tokens), una descentralización madura en la gobernanza.N/A (para la red): Zama es más un proyecto impulsado por una empresa ahora. Si se lanzan fhEVM o redes, inicialmente es probable que sean centralizadas o con un conjunto limitado de nodos (dada la complejidad). Con el tiempo podría descentralizar la ejecución de transacciones FHE, pero eso es territorio inexplorado en 2025.
Token e Incentivos$IKA (basado en Sui) para tarifas de gas, staking y potencialmente gobernanza. Incentivo: ganar tarifas por ejecutar validadores; el token se aprecia con el uso de la red. El respaldo de la Fundación Sui le da valor en el ecosistema.Token **LIT:utilizadoparagobernanzayquizaˊstarifasparaserviciosavanzados.LasLitActionssonactualmentegratuitasparalosdesarrolladores(singas);alargoplazopuedenintroducirunmodelodetarifas.LIT**: utilizado para gobernanza y quizás tarifas para servicios avanzados. Las Lit Actions son actualmente gratuitas para los desarrolladores (sin gas); a largo plazo pueden introducir un modelo de tarifas. LIT incentiva la operación de nodos (stakers) pero la tokenomía exacta está evolucionando.Token **T:losnodoshacenstaking,gobiernalatesorerıˊadelaDAOylasactualizacionesdelprotocolo.LosnodosgananenT**: los nodos hacen staking, gobierna la tesorería de la DAO y las actualizaciones del protocolo. Los nodos ganan en T y tarifas (en ETH o tarifas de tBTC). $T asegura la red (slashing por mal comportamiento). También se usa en programas de liquidez para la adopción de tBTC.Sin token (aún): Zama está financiada por VC; podría introducir un token si lanzan un servicio de red (podría usarse para pagar cómputos privados o hacer staking para asegurar redes que ejecutan contratos FHE). Actualmente, los desarrolladores usan las herramientas de Zama sin un token.
Inversores ClaveFundación Sui (inversor estratégico); VCs: Node Capital, Blockchange, Lemniscap, Collider; ángeles como Naval Ravikant. Fuerte apoyo del ecosistema Sui.Respaldado por 1kx, Pantera, Coinbase Ventures, Framework, etc. (Recaudó $13M en 2022). Tiene una creciente comunidad de desarrolladores a través de Lit DAO. Asociaciones con Ceramic, proyectos de NFT para control de acceso.Surgió de las comunidades de Keep y NuCypher (respaldadas por a16z, Polychain en el pasado). Threshold es dirigido por la DAO; sin nueva financiación de VC después de la fusión (subvenciones del Fondo Comunitario de Ethereum, etc.). Asociaciones: trabaja con Curve, Aave (integraciones de tBTC).Respaldado por a16z, SoftBank, Multicoin Capital (recaudó $73M en Serie A). Lazos estrechos con la investigación de la Fundación Ethereum (Rand Hindi, CEO, es un defensor abierto de FHE en Ethereum). Colaborando con proyectos como Optalysys para la aceleración de hardware.

La Ventaja Competitiva de Ika: Los diferenciadores de Ika radican en su rendimiento a escala y su modelo de seguridad único. En comparación con Lit Protocol, Ika puede soportar muchos más firmantes y un rendimiento mucho mayor, lo que lo hace adecuado para casos de uso (como el trading de alto volumen o los juegos) con los que la red de Lit tendría dificultades. Ika tampoco depende de Entornos de Ejecución Confiable, de los que algunos desarrolladores desconfían (debido a posibles exploits en SGX); en cambio, Ika logra la falta de confianza puramente con criptografía y consenso. Frente a Threshold Network, Ika ofrece una plataforma de propósito más general. Threshold se centra en gran medida en el puente Bitcoin↔Ethereum (tBTC) y un par de servicios criptográficos como el re-cifrado de proxy, mientras que Ika es una capa de interoperabilidad flexible que puede funcionar con cualquier cadena y activo desde el principio. Además, el modelo de Ika con el usuario en el bucle significa que no requiere sobre-colateralización o seguro para los depósitos (tBTC v2 utiliza un modelo económico robusto pero complejo para asegurar los depósitos de BTC, mientras que en Ika el usuario nunca cede el control en primer lugar). En comparación con Zama, Ika aborda un problema diferente: Zama se enfoca en la privacidad, mientras que Ika se enfoca en la interoperabilidad. Sin embargo, es concebible que en el futuro los dos puedan complementarse (por ejemplo, usando FHE en activos almacenados en Ika). Por ahora, Ika tiene la ventaja de estar operativo antes en un nicho con demanda inmediata (los puentes y las redes MPC se necesitan hoy, mientras que FHE aún está madurando).

Un desafío potencial para Ika es la educación del mercado y la confianza. Está introduciendo una forma novedosa de hacer interacciones cross-chain (dWallets en lugar de los puentes tradicionales de bloqueo y acuñación). Necesitará demostrar su seguridad en la práctica con el tiempo para ganar el mismo nivel de confianza que, por ejemplo, Threshold Network ha ganado gradualmente (Threshold tuvo que probar tBTC después de que una versión anterior fuera pausada debido a riesgos). Si la tecnología de Ika funciona como se anuncia, efectivamente supera a la competencia al resolver el trilema de descentralización, seguridad y velocidad en el espacio MPC. El fuerte respaldo de Sui y las extensas auditorías/documentos le otorgan credibilidad.

En conclusión, Ika se destaca entre las redes MPC por su ambiciosa escalabilidad y su modelo de seguridad centrado en el usuario. Los inversores lo ven como una apuesta por el futuro de la coordinación cross-chain, uno en el que los usuarios pueden mover valor y lógica sin problemas a través de muchas blockchains sin ceder nunca el control de sus claves. Si Ika logra una amplia adopción, podría volverse tan integral para la infraestructura de Web3 como los protocolos de mensajería cross-chain o las principales blockchains de Capa 1. El próximo año (2025) será crítico a medida que la mainnet de Ika y sus primeros casos de uso se pongan en marcha, demostrando si esta criptografía de vanguardia puede cumplir sus promesas en condiciones reales de mercado. Las primeras señales —fundamentos técnicos sólidos, una cartera activa de integraciones y un apoyo sustancial de los inversores— sugieren que Ika tiene una oportunidad real de redefinir la interoperabilidad de blockchain con MPC.

Fuentes: La información principal se recopiló de la documentación oficial y el whitepaper de Ika, anuncios de la Fundación Sui, comunicados de prensa y noticias de financiación, así como documentos técnicos y análisis de competidores para el contexto (informe de Messari de Lit Protocol, documentación de Threshold Network y descripciones de FHE de Zama). Toda la información está actualizada a 2025.

Privacidad Programable en Blockchain: Cómputo Off‑Chain con Verificación On‑Chain

· 55 min de lectura
Dora Noda
Software Engineer

Las blockchains públicas proporcionan transparencia e integridad a costa de la privacidad: cada transacción y estado de contrato está expuesto a todos los participantes. Esta apertura crea problemas como los ataques de MEV (Valor Extraíble por Mineros), el copy-trading y la filtración de lógica de negocio sensible. La privacidad programable busca resolver estos problemas permitiendo cómputos sobre datos privados sin revelar los datos en sí. Dos paradigmas criptográficos emergentes están haciendo esto posible: las Máquinas Virtuales de Cifrado Totalmente Homomórfico (FHE-VM) y los Coprocesadores de Conocimiento Cero (ZK). Estos enfoques permiten el cómputo off-chain o cifrado con verificación on-chain, preservando la confidencialidad mientras se mantiene la corrección sin confianza (trustless). En este informe, profundizamos en las arquitecturas de FHE-VM y coprocesadores ZK, comparamos sus ventajas y desventajas, y exploramos casos de uso en finanzas, identidad, salud, mercados de datos y aprendizaje automático descentralizado.

Máquina Virtual de Cifrado Totalmente Homomórfico (FHE-VM)

El Cifrado Totalmente Homomórfico (FHE) permite realizar cómputos arbitrarios sobre datos cifrados sin necesidad de descifrarlos. Una Máquina Virtual FHE integra esta capacidad en los contratos inteligentes de la blockchain, permitiendo estado y lógica de contrato cifrados. En una blockchain habilitada para FHE (a menudo llamada fhEVM para diseños compatibles con EVM), todas las entradas, el almacenamiento del contrato y las salidas permanecen cifrados durante toda la ejecución. Esto significa que los validadores pueden procesar transacciones y actualizar el estado sin conocer ningún valor sensible, logrando una ejecución on-chain con confidencialidad de los datos.

Arquitectura y Diseño de FHE-VM

Una FHE-VM típica extiende un tiempo de ejecución de contrato inteligente estándar (como la Máquina Virtual de Ethereum) con soporte nativo para tipos de datos y operaciones cifradas. Por ejemplo, la FHEVM de Zama introduce enteros cifrados (euint8, euint32, etc.), booleanos cifrados (ebool) e incluso arreglos cifrados como tipos de primera clase. Los lenguajes de contratos inteligentes como Solidity se aumentan mediante bibliotecas o nuevos opcodes para que los desarrolladores puedan realizar operaciones aritméticas (add, mul, etc.), lógicas y comparaciones directamente sobre textos cifrados. Por debajo, estas operaciones invocan primitivas FHE (por ejemplo, usando la biblioteca TFHE) para manipular bits cifrados y producir resultados cifrados.

El almacenamiento de estado cifrado es compatible para que las variables del contrato permanezcan cifradas en el estado de la blockchain. El flujo de ejecución es típicamente:

  1. Cifrado del Lado del Cliente: Los usuarios cifran sus entradas localmente usando la clave pública FHE antes de enviar las transacciones. La clave de cifrado es pública (para cifrar y evaluar), mientras que la clave de descifrado permanece secreta. En algunos diseños, cada usuario gestiona su propia clave; en otros, se utiliza una única clave FHE global (discutido a continuación).
  2. Cómputo Homomórfico On-Chain: Los mineros/validadores ejecutan el contrato con opcodes cifrados. Realizan las mismas operaciones homomórficas deterministas sobre los textos cifrados, por lo que se puede alcanzar un consenso sobre el nuevo estado cifrado. Crucialmente, los validadores nunca ven datos en texto plano; solo ven texto cifrado "sin sentido" pero aún pueden procesarlo de manera consistente.
  3. Descifrado (Opcional): Si un resultado necesita ser revelado o utilizado off-chain, una parte autorizada con la clave privada puede descifrar el texto cifrado de salida. De lo contrario, los resultados permanecen cifrados y pueden ser utilizados como entradas para transacciones posteriores (permitiendo cómputos consecutivos sobre un estado cifrado persistente).

Una consideración de diseño importante es la gestión de claves. Un enfoque es el de claves por usuario, donde cada usuario posee su clave secreta y solo ellos pueden descifrar las salidas relevantes para ellos. Esto maximiza la privacidad (nadie más puede descifrar tus datos), pero las operaciones homomórficas no pueden mezclar datos cifrados bajo diferentes claves sin complejos protocolos de claves múltiples. Otro enfoque, utilizado por la FHEVM de Zama, es una clave FHE global: una única clave pública cifra todos los datos del contrato y un conjunto distribuido de validadores posee partes de la clave de descifrado de umbral. Las claves públicas de cifrado y evaluación se publican on-chain, para que cualquiera pueda cifrar datos para la red; la clave privada se divide entre los validadores que pueden descifrar colectivamente si es necesario bajo un esquema de umbral. Para evitar que la colusión de validadores comprometa la privacidad, Zama emplea un protocolo FHE de umbral (basado en su investigación Noah’s Ark) con "inundación de ruido" para hacer seguras las descifraciones parciales. Solo si un quórum suficiente de validadores coopera se puede recuperar un texto plano, por ejemplo, para atender una solicitud de lectura. Sin embargo, en operación normal, ningún nodo individual ve texto plano; los datos permanecen cifrados on-chain en todo momento.

El control de acceso es otro componente crucial. Las implementaciones de FHE-VM incluyen controles detallados para gestionar quién (si es que alguien) puede activar descifrados o acceder a ciertos campos cifrados. Por ejemplo, la fhEVM de Cypher admite Listas de Control de Acceso en textos cifrados, permitiendo a los desarrolladores especificar qué direcciones o contratos pueden interactuar o recifrar ciertos datos. Algunos frameworks admiten el recifrado: la capacidad de transferir un valor cifrado de la clave de un usuario a la de otro sin exponer el texto plano. Esto es útil para cosas como mercados de datos, donde un propietario de datos puede cifrar un conjunto de datos con su clave y, tras la compra, recifrarlo a la clave del comprador, todo on-chain, sin descifrarlo públicamente.

Garantizando la Corrección y la Privacidad

Uno podría preguntarse: si todos los datos están cifrados, ¿cómo hacemos cumplir la corrección de la lógica del contrato? ¿Cómo puede la cadena prevenir operaciones inválidas si no puede "ver" los valores? El FHE por sí solo no proporciona una prueba de corrección: los validadores pueden realizar los pasos homomórficos, pero no pueden saber inherentemente si la entrada cifrada de un usuario fue válida o si se debe tomar una bifurcación condicional, etc., sin descifrar. Las pruebas de conocimiento cero (ZKPs) pueden complementar el FHE para resolver esta brecha. En una FHE-VM, típicamente los usuarios deben proporcionar una prueba ZK que certifique ciertas condiciones del texto plano cuando sea necesario. El diseño de Zama, por ejemplo, utiliza una Prueba ZK de Conocimiento de Texto Plano (ZKPoK) para acompañar cada entrada cifrada. Esto prueba que el usuario conoce el texto plano correspondiente a su texto cifrado y que cumple con los criterios esperados, sin revelar el texto plano en sí. Dichos "textos cifrados certificados" evitan que un usuario malicioso envíe un cifrado mal formado o un valor fuera de rango. De manera similar, para operaciones que requieren una decisión (por ejemplo, asegurar que el saldo de la cuenta ≥ monto del retiro), el usuario puede proporcionar una prueba ZK de que esta condición se cumple en los textos planos antes de que se ejecute la operación cifrada. De esta manera, la cadena no descifra ni ve los valores, pero gana confianza en que las transacciones cifradas siguen las reglas.

Otro enfoque en los rollups FHE es realizar una validación off-chain con ZKPs. Fhenix (un rollup L2 que usa FHE) opta por un modelo optimista donde un componente de red separado llamado Red de Servicio de Umbral puede descifrar o verificar resultados cifrados, y cualquier cómputo incorrecto puede ser desafiado con una prueba de fraude. En general, combinar FHE + ZK o pruebas de fraude asegura que la ejecución cifrada permanezca sin confianza. Los validadores descifran colectivamente solo cuando están autorizados, o verifican pruebas de que cada transición de estado cifrada fue válida sin necesidad de ver el texto plano.

Consideraciones de rendimiento: Las operaciones FHE son computacionalmente pesadas, muchos órdenes de magnitud más lentas que la aritmética normal. Por ejemplo, una simple suma de 64 bits en Ethereum cuesta ~3 gas, mientras que una suma en un entero cifrado de 64 bits (euint64) bajo la FHEVM de Zama cuesta aproximadamente 188,000 gas. Incluso una suma de 8 bits puede costar ~94k gas. Esta enorme sobrecarga significa que una implementación directa en los nodos existentes sería imprácticamente lenta y costosa. Los proyectos de FHE-VM abordan esto con bibliotecas criptográficas optimizadas (como la biblioteca TFHE-rs de Zama para el bootstrapping de compuertas binarias) y modificaciones personalizadas de EVM para el rendimiento. Por ejemplo, el cliente Geth modificado de Cypher agrega nuevos opcodes y optimiza la ejecución de instrucciones homomórficas en C++/ensamblador para minimizar la sobrecarga. Sin embargo, lograr un rendimiento utilizable requiere aceleración. El trabajo en curso incluye el uso de GPUs, FPGAs e incluso chips fotónicos especializados para acelerar los cómputos FHE. Zama informa que su rendimiento FHE mejoró 100 veces desde 2024 y apunta a miles de TPS con aceleración por GPU/FPGA. Servidores coprocesadores FHE dedicados (como el LightLocker Node de Optalysys) pueden conectarse a los nodos validadores para descargar operaciones cifradas al hardware, soportando >100 transferencias ERC-20 cifradas por segundo por nodo. A medida que el hardware y los algoritmos mejoren, la brecha entre el FHE y el cómputo en texto plano se reducirá, permitiendo que los contratos privados se acerquen a velocidades más prácticas.

Compatibilidad: Un objetivo clave de los diseños de FHE-VM es mantener la compatibilidad con los flujos de trabajo de desarrollo existentes. Las implementaciones de fhEVM de Cypher y Zama permiten a los desarrolladores escribir contratos en Solidity con cambios mínimos, utilizando una biblioteca para declarar tipos y operaciones cifradas. El resto de la cadena de herramientas de Ethereum (Remix, Hardhat, etc.) todavía se puede utilizar, ya que las modificaciones subyacentes se encuentran principalmente a nivel de cliente/nodo. Esto reduce la barrera de entrada: los desarrolladores no necesitan ser expertos en criptografía para escribir un contrato inteligente confidencial. Por ejemplo, una simple suma de dos números se puede escribir como euint32 c = a + b; y la FHEVM se encargará de los detalles específicos del cifrado tras bambalinas. Los contratos pueden incluso interoperar con contratos normales; por ejemplo, un contrato cifrado podría generar un resultado descifrado para un contrato estándar si se desea, permitiendo una mezcla de partes privadas y públicas en un ecosistema.

Proyectos FHE-VM Actuales: Varios proyectos son pioneros en este espacio. Zama (una startup de FHE con sede en París) desarrolló el concepto central de FHEVM y las bibliotecas (TFHE-rs y una biblioteca fhevm-solidity). No tienen la intención de lanzar su propia cadena, sino de proporcionar infraestructura a otros. Inco es una blockchain L1 (construida sobre Cosmos SDK con Evmos) que integró la FHEVM de Zama para crear una cadena confidencial modular. Sus redes de prueba (llamadas Gentry y Paillier) muestran transferencias ERC-20 cifradas y otras primitivas DeFi privadas. Fhenix es un rollup optimista de Capa 2 de Ethereum que utiliza FHE para la privacidad. Se decidieron por un enfoque optimista (prueba de fraude) en lugar de un ZK-rollup debido al alto costo de hacer FHE y ZK juntos para cada bloque. Fhenix utiliza la misma biblioteca TFHE-rs (con algunas modificaciones) e introduce una Red de Servicio de Umbral para manejar los descifrados de manera descentralizada. También hay equipos independientes como Fhenix (ahora renombrado) y startups que exploran híbridos de MPC + FHE. Además, Cypher (de Z1 Labs) está construyendo una red de Capa 3 centrada en IA y privacidad, utilizando una fhEVM con características como almacenes secretos y soporte para aprendizaje federado. El ecosistema es incipiente pero está creciendo rápidamente, impulsado por una financiación significativa; por ejemplo, Zama se convirtió en un "unicornio" con más de $130M recaudados para 2025 para avanzar en la tecnología FHE.

En resumen, una FHE-VM permite contratos inteligentes que preservan la privacidad al ejecutar toda la lógica sobre datos cifrados on-chain. Este paradigma garantiza la máxima confidencialidad —nada sensible se expone nunca en las transacciones o el estado— mientras aprovecha el consenso de la blockchain existente para la integridad. El costo es una mayor carga computacional para los validadores y complejidad en la gestión de claves y la integración de pruebas. A continuación, exploramos un paradigma alternativo que descarga el cómputo completamente off-chain y solo utiliza la cadena para la verificación: el coprocesador de conocimiento cero.

Coprocesadores de Conocimiento Cero (Coprocesadores ZK)

Un coprocesador ZK es un nuevo patrón de arquitectura de blockchain donde los cómputos costosos se realizan off-chain, y una prueba de conocimiento cero sucinta de su corrección se verifica on-chain. Esto permite que los contratos inteligentes aprovechen una potencia computacional y datos mucho mayores de lo que permitiría la ejecución on-chain, sin sacrificar la falta de confianza (trustlessness). El término coprocesador se utiliza por analogía con los coprocesadores de hardware (como un coprocesador matemático o una GPU) que manejan tareas especializadas para una CPU. Aquí, la "CPU" de la blockchain (la VM nativa como la EVM) delega ciertas tareas a un sistema de prueba de conocimiento cero que actúa como un coprocesador criptográfico. El coprocesador ZK devuelve un resultado y una prueba de que el resultado se calculó correctamente, que el contrato on-chain puede verificar y luego usar.

Arquitectura y Flujo de Trabajo

En una configuración típica, un desarrollador de dApp identifica partes de la lógica de su aplicación que son demasiado costosas o complejas para la ejecución on-chain (por ejemplo, grandes cómputos sobre datos históricos, algoritmos pesados, inferencia de modelos de ML, etc.). Implementan esas partes como un programa off-chain (en un lenguaje de alto nivel o un DSL de circuito) que puede producir una prueba de conocimiento cero de su ejecución. El componente on-chain es un contrato inteligente verificador que comprueba las pruebas y pone los resultados a disposición del resto del sistema. El flujo se puede resumir en:

  1. Solicitud – El contrato on-chain desencadena una solicitud para que se realice un cierto cómputo off-chain. Esto podría ser iniciado por una transacción de usuario o por un contrato que llama a la interfaz del coprocesador ZK. Por ejemplo, un contrato DeFi podría llamar a “proveInterestRate(currentState)” o un usuario llama a “queryHistoricalData(query)”.
  2. Ejecución y Prueba Off-Chain – Un servicio off-chain (que podría ser una red descentralizada de probadores o un servicio de confianza, dependiendo del diseño) recoge la solicitud. Reúne los datos necesarios (estado on-chain, entradas off-chain, etc.) y ejecuta el cómputo en una Máquina Virtual ZK (ZKVM) o circuito especial. Durante la ejecución, se genera una traza de prueba. Al final, el servicio produce una prueba sucinta (por ejemplo, un SNARK o STARK) que atestigua que “Calcular la función F sobre la entrada X produce la salida Y” y opcionalmente atestigua la integridad de los datos (más sobre esto a continuación).
  3. Verificación On-Chain – La prueba y el resultado se devuelven a la blockchain (a menudo a través de una función de devolución de llamada o callback). El contrato verificador comprueba la validez de la prueba utilizando una verificación criptográfica eficiente (comprobaciones de emparejamiento, etc.). Si es válida, el contrato puede ahora confiar en la salida Y como correcta. El resultado puede almacenarse en el estado, emitirse como un evento o introducirse en la lógica posterior del contrato. Si la prueba es inválida o no se proporciona en un cierto tiempo, la solicitud puede considerarse fallida (y potencialmente se activa alguna lógica de respaldo o de tiempo de espera).

Figura 1: Arquitectura de un Coprocesador ZK (ejemplo de Bonsai de RISC Zero). Off-chain, un programa se ejecuta en una ZKVM con entradas de la llamada al contrato inteligente. Se devuelve una prueba de ejecución on-chain a través de un contrato relay, que invoca una devolución de llamada (callback) con los resultados verificados.

Críticamente, el costo de gas on-chain para la verificación es constante (o crece muy lentamente) independientemente de cuán complejo fue el cómputo off-chain. Verificar una prueba sucinta podría costar del orden de unos cientos de miles de gas (una fracción de un bloque de Ethereum), pero esa prueba podría representar millones de pasos computacionales realizados off-chain. Como bromeó un desarrollador, “¿Quieres probar una firma digital? ~15.¿Quieresprobarunmilloˊndefirmas?Tambieˊn 15. ¿Quieres probar un millón de firmas? También ~15.”. Esta escalabilidad es una gran ventaja: las dApps pueden ofrecer funcionalidades complejas (análisis de big data, modelos financieros elaborados, etc.) sin congestionar la blockchain.

Los componentes principales de un sistema de coprocesador ZK son:

  • Entorno de Generación de Pruebas: Puede ser una ZKVM de propósito general (capaz de ejecutar programas arbitrarios) o circuitos personalizados adaptados a cómputos específicos. Los enfoques varían:

    • Algunos proyectos utilizan circuitos hechos a mano para cada consulta o función soportada (maximizando la eficiencia para esa función).
    • Otros proporcionan un Lenguaje Específico de Dominio (DSL) o un DSL Embebido que los desarrolladores usan para escribir su lógica off-chain, que luego se compila en circuitos (equilibrando la facilidad de uso y el rendimiento).
    • El enfoque más flexible es una zkVM: una máquina virtual (a menudo basada en arquitecturas RISC) donde los programas se pueden escribir en lenguajes estándar (Rust, C, etc.) y probarse automáticamente. Esto sacrifica el rendimiento (simular una CPU en un circuito agrega sobrecarga) por la máxima experiencia del desarrollador.
  • Acceso e Integridad de los Datos: Un desafío único es alimentar el cómputo off-chain con los datos correctos, especialmente si esos datos residen en la blockchain (bloques pasados, estados de contratos, etc.). Una solución ingenua es que el probador lea de un nodo de archivo y confíe en él, pero eso introduce suposiciones de confianza. En cambio, los coprocesadores ZK suelen probar que cualquier dato on-chain utilizado fue auténtico al vincularlo a pruebas de Merkle o compromisos de estado. Por ejemplo, el programa de consulta podría tomar un número de bloque y una prueba de Merkle de una ranura de almacenamiento o transacción, y el circuito verificará esa prueba contra un hash de encabezado de bloque conocido. Existen tres patrones:

    1. Datos en Línea: Poner los datos necesarios on-chain (como entrada al verificador) para que puedan ser verificados directamente. Esto es muy costoso para grandes volúmenes de datos y socava todo el propósito.
    2. Confiar en un Oráculo: Hacer que un servicio de oráculo alimente los datos a la prueba y los certifique. Esto es más simple pero reintroduce la confianza en un tercero.
    3. Probar la Inclusión de Datos vía ZK: Incorporar pruebas de inclusión de datos en el historial de la cadena dentro del propio circuito de conocimiento cero. Esto aprovecha el hecho de que cada encabezado de bloque de Ethereum se compromete con todo el estado anterior (a través de la raíz de estado) y el historial de transacciones. Al verificar las pruebas de Merkle Patricia de los datos dentro del circuito, la prueba de salida asegura al contrato que “este cómputo utilizó datos genuinos de la blockchain del bloque N” sin necesidad de confianza adicional.

    El tercer enfoque es el más trustless y es utilizado por coprocesadores ZK avanzados como Axiom y Xpansion (aumenta el costo de la prueba, pero es preferible por seguridad). Por ejemplo, el sistema de Axiom modela la estructura de bloques de Ethereum, el trie de estado y el trie de transacciones dentro de sus circuitos, por lo que puede probar afirmaciones como “la cuenta X tenía un saldo Y en el bloque N o “una transacción con ciertas propiedades ocurrió en el bloque N”. Aprovecha el hecho de que, dado un hash de bloque reciente de confianza, se puede probar recursivamente la inclusión de datos históricos sin confiar en ninguna parte externa.

  • Contrato Verificador: Este contrato on-chain contiene la clave de verificación y la lógica para aceptar o rechazar pruebas. Para SNARKs como Groth16 o PLONK, el verificador podría hacer algunos emparejamientos de curvas elípticas; para STARKs, podría hacer algunos cómputos de hash. Las optimizaciones de rendimiento como la agregación y la recursión pueden minimizar la carga on-chain. Por ejemplo, Bonsai de RISC Zero utiliza un envoltorio de STARK a SNARK: ejecuta una VM basada en STARK off-chain por velocidad, pero luego genera una pequeña prueba SNARK que atestigua la validez del STARK. Esto reduce el tamaño de la prueba de cientos de kilobytes a unos pocos cientos de bytes, haciendo que la verificación on-chain sea factible y barata. El verificador de Solidity entonces solo comprueba el SNARK (que es una operación de tiempo constante).

En términos de despliegue, los coprocesadores ZK pueden funcionar como redes similares a la capa 2 o como servicios puramente off-chain. Algunos, como Axiom, comenzaron como un servicio especializado para Ethereum (con el respaldo de Paradigm) donde los desarrolladores envían consultas a la red de probadores de Axiom y obtienen pruebas on-chain. El eslogan de Axiom era proporcionar a los contratos de Ethereum “acceso sin confianza a todos los datos on-chain y cómputo expresivo arbitrario sobre ellos”. Actúa efectivamente como un oráculo de consultas donde las respuestas son verificadas por ZKPs en lugar de confianza. Otros, como Bonsai de RISC Zero, ofrecen una plataforma más abierta: cualquier desarrollador puede subir un programa (compilado a una ZKVM compatible con RISC-V) y usar el servicio de pruebas de Bonsai a través de un contrato relay. El patrón de relay, como se ilustra en la Figura 1, implica un contrato que media las solicitudes y respuestas: el contrato de la dApp llama al relay para solicitar una prueba, el servicio off-chain escucha esto (por ejemplo, a través de un evento o una llamada directa), calcula la prueba, y luego el relay invoca una función de devolución de llamada en el contrato de la dApp con el resultado y la prueba. Este modelo asíncrono es necesario porque la prueba puede tardar desde segundos hasta minutos dependiendo de la complejidad. Introduce una latencia (y una suposición de liveness de que el probador responderá), mientras que los cómputos de FHE-VM ocurren sincrónicamente dentro de un bloque. Diseñar la aplicación para manejar este flujo de trabajo asíncrono (posiblemente similar a las respuestas de un Oráculo) es parte del uso de un coprocesador ZK.

Proyectos Notables de Coprocesadores ZK

  • Axiom: Axiom es un coprocesador ZK diseñado para Ethereum, enfocado originalmente en probar consultas de datos on-chain históricos. Utiliza el framework de pruebas Halo2 (un SNARK tipo Plonk) para crear pruebas que incorporan las estructuras criptográficas de Ethereum. En el sistema de Axiom, un desarrollador puede consultar cosas como “¿cuál era el estado del contrato X en el bloque N?” o realizar un cómputo sobre todas las transacciones en un rango. Por debajo, los circuitos de Axiom tuvieron que implementar la lógica de estado/trie de Ethereum, incluso realizando operaciones de curva elíptica y verificación de SNARK dentro del circuito para soportar la recursión. Trail of Bits, en una auditoría, señaló la complejidad de los circuitos Halo2 de Axiom que modelan bloques y estados completos. Después de la auditoría, Axiom generalizó su tecnología en una OpenVM, permitiendo que código Rust arbitrario sea probado con la misma infraestructura basada en Halo2. (Esto refleja la tendencia de pasar de circuitos específicos de dominio a un enfoque de ZKVM más general). El equipo de Axiom demostró consultas ZK que Ethereum nativamente no puede hacer, permitiendo un acceso sin estado a cualquier dato histórico con integridad criptográfica. También han enfatizado la seguridad, detectando y corrigiendo errores de circuitos sub-restringidos y asegurando la solidez. Aunque el producto inicial de Axiom fue cerrado durante su pivote, su enfoque sigue siendo un hito en los coprocesadores ZK.

  • RISC Zero Bonsai: RISC Zero es una ZKVM basada en la arquitectura RISC-V. Su zkVM puede ejecutar programas arbitrarios (escritos en Rust, C++ y otros lenguajes compilados a RISC-V) y producir una prueba STARK de la ejecución. Bonsai es el servicio en la nube de RISC Zero que proporciona esta prueba bajo demanda, actuando como un coprocesador para contratos inteligentes. Para usarlo, un desarrollador escribe un programa (digamos una función que realiza matemáticas complejas o verifica una respuesta de API off-chain), lo sube al servicio Bonsai y despliega un contrato verificador correspondiente. Cuando el contrato necesita ese cómputo, llama al relay de Bonsai que desencadena la generación de la prueba y devuelve el resultado a través de una devolución de llamada. Una aplicación de ejemplo demostrada fue el cómputo de gobernanza off-chain: RISC Zero mostró una DAO usando Bonsai para contar votos y calcular métricas de votación complejas off-chain, y luego publicar una prueba para que el contrato Gobernador on-chain pudiera confiar en el resultado con un costo de gas mínimo. La tecnología de RISC Zero enfatiza que los desarrolladores pueden usar paradigmas de programación familiares —por ejemplo, escribir una función en Rust para calcular algo— y el trabajo pesado de la creación de circuitos es manejado por la zkVM. Sin embargo, las pruebas pueden ser grandes, por lo que, como se señaló anteriormente, implementaron una compresión SNARK para la verificación on-chain. En agosto de 2023, verificaron con éxito pruebas de RISC Zero en la red de prueba Sepolia de Ethereum, con un costo del orden de 300k de gas por prueba. Esto abre la puerta para que las dApps de Ethereum usen Bonsai hoy como una solución de escalado y privacidad. (Bonsai todavía está en alfa, no listo para producción, y utiliza una configuración SNARK temporal sin una ceremonia).

  • Otros: Existen numerosos otros actores e iniciativas de investigación. Expansion/Xpansion (como se menciona en un blog) utiliza un enfoque de DSL embebido, donde los desarrolladores pueden escribir consultas sobre datos on-chain con un lenguaje especializado, y este se encarga internamente de la generación de pruebas. Cairo de StarkWare y zkEVM de Polygon son VMs de ZK-rollup más generales, pero su tecnología podría ser reutilizada para un uso similar a un coprocesador al verificar pruebas dentro de contratos L1. También vemos proyectos en el dominio de ZKML (ZK Machine Learning), que actúan efectivamente como coprocesadores para verificar la inferencia de modelos de ML o los resultados de entrenamiento on-chain. Por ejemplo, una configuración de zkML puede probar que “una inferencia de red neuronal sobre entradas privadas produjo la clasificación X” sin revelar las entradas ni realizar el cómputo on-chain. Estos son casos especiales del concepto de coprocesador aplicado a la IA.

Suposiciones de confianza: Los coprocesadores ZK se basan en la solidez de las pruebas criptográficas. Si el sistema de prueba es seguro (y cualquier configuración de confianza se realiza honestamente), entonces una prueba aceptada garantiza que el cómputo fue correcto. No se necesita confianza adicional en el probador; incluso un probador malicioso no puede convencer al verificador de una afirmación falsa. Sin embargo, existe una suposición de liveness: alguien debe realizar realmente el cómputo off-chain y producir la prueba. En la práctica, esto podría ser una red descentralizada (con incentivos o tarifas para hacer el trabajo) o un único operador de servicio. Si nadie proporciona la prueba, la solicitud on-chain podría quedar sin resolver. Otro aspecto sutil de confianza es la disponibilidad de datos para entradas off-chain que no están en la blockchain. Si el cómputo depende de algunos datos privados o externos, el verificador no puede saber si esos datos se proporcionaron honestamente a menos que se utilicen medidas adicionales (como compromisos de datos o firmas de oráculos). Pero para cómputos de datos puramente on-chain, los mecanismos descritos aseguran una falta de confianza equivalente a la de la propia cadena (Axiom argumentó que sus pruebas ofrecen "seguridad criptográficamente equivalente a Ethereum" para consultas históricas).

Privacidad: Las pruebas de conocimiento cero también soportan inherentemente la privacidad: el probador puede mantener las entradas ocultas mientras prueba afirmaciones sobre ellas. En un contexto de coprocesador, esto significa que una prueba puede permitir que un contrato utilice un resultado que se derivó de datos privados. Por ejemplo, una prueba podría mostrar “la puntuación de crédito del usuario > 700, por lo tanto, aprobar el préstamo” sin revelar la puntuación de crédito real o los datos brutos. El caso de uso de Axiom se centraba más en datos públicamente conocidos (historial de la blockchain), por lo que la privacidad no era el foco allí. Pero la zkVM de RISC Zero podría usarse para probar afirmaciones sobre datos secretos proporcionados por un usuario: los datos permanecen off-chain y solo el resultado necesario va on-chain. Vale la pena señalar que, a diferencia del FHE, una prueba ZK no suele proporcionar confidencialidad continua del estado; es una prueba única. Si un flujo de trabajo necesita mantener un estado secreto a través de transacciones, se podría construir haciendo que el contrato almacene un compromiso con el estado y cada prueba muestre una transición de estado válida del compromiso antiguo al nuevo, con los secretos ocultos. Así es esencialmente como funcionan los zk-rollups para transacciones privadas (como Aztec o Zcash). Por lo tanto, los coprocesadores ZK pueden facilitar máquinas de estado totalmente privadas, pero la implementación no es trivial; a menudo se utilizan para cómputos únicos donde la entrada o la salida (o ambas) pueden ser privadas según sea necesario.

Experiencia del desarrollador: Usar un coprocesador ZK generalmente requiere aprender nuevas herramientas. Escribir circuitos personalizados (opción (1) anterior) es bastante complejo y generalmente solo se hace para propósitos específicos. Opciones de nivel superior como los DSLs o las zkVMs facilitan la vida pero aún agregan sobrecarga: el desarrollador debe escribir y desplegar código off-chain y gestionar la interacción. A diferencia de la FHE-VM, donde el cifrado se maneja principalmente tras bambalinas y el desarrollador escribe código de contrato inteligente normal, aquí el desarrollador necesita particionar su lógica y posiblemente escribir en un lenguaje diferente (Rust, etc.) para la parte off-chain. Sin embargo, iniciativas como los DSLs Noir, Leo, Circom o el enfoque de RISC Zero están mejorando rápidamente la accesibilidad. Por ejemplo, RISC Zero proporciona plantillas e integración con Foundry de tal manera que un desarrollador puede simular su código off-chain localmente (para la corrección) y luego conectarlo sin problemas a las pruebas de Solidity a través de la devolución de llamada de Bonsai. Con el tiempo, podemos esperar frameworks de desarrollo que abstraigan si una pieza de lógica se ejecuta a través de una prueba ZK o on-chain; el compilador o las herramientas podrían decidir en función del costo.

FHE-VM vs Coprocesador ZK: Comparación

Tanto las FHE-VMs como los coprocesadores ZK permiten una forma de “cómputo sobre datos privados con garantía on-chain”, pero difieren fundamentalmente en su arquitectura. La siguiente tabla resume las diferencias clave:

AspectoFHE-VM (Ejecución Cifrada On-Chain)Coprocesador ZK (Prueba Off-Chain)
Dónde ocurre el cómputoDirectamente on-chain (todos los nodos ejecutan operaciones homomórficas sobre textos cifrados).Off-chain (un probador o red ejecuta el programa; solo se verifica una prueba on-chain).
Confidencialidad de los datosCifrado completo: los datos permanecen cifrados en todo momento on-chain; los validadores nunca ven texto plano. Solo los poseedores de las claves de descifrado pueden descifrar las salidas.Conocimiento cero: las entradas privadas del probador nunca se revelan on-chain; la prueba no revela secretos más allá de lo que está en las salidas públicas. Sin embargo, cualquier dato utilizado en el cómputo que deba afectar el estado on-chain debe codificarse en la salida o en un compromiso. Los secretos permanecen off-chain por defecto.
Modelo de confianzaConfianza en la ejecución por consenso y la criptografía: si la mayoría de los validadores sigue el protocolo, la ejecución cifrada es determinista y correcta. No se necesita confianza externa para la corrección del cómputo (todos los nodos lo recalculan). Se debe confiar en la seguridad del esquema FHE (generalmente basado en la dureza de los problemas de retículos) para la privacidad. En algunos diseños, también se confía en que no ocurra una colusión de suficientes validadores para hacer un mal uso de las claves de umbral.Confianza en la seguridad del sistema de prueba (solidez de SNARK/STARK). Si la prueba se verifica, el resultado es correcto con certeza criptográfica. Los probadores off-chain no pueden engañar a las matemáticas. Hay una suposición de liveness sobre los probadores para que realmente hagan el trabajo. Si se utiliza una configuración de confianza (por ejemplo, SRS de SNARK), se debe confiar en que se generó honestamente o usar sistemas transparentes/sin configuración.
Costo on-chain y escalabilidadAlto costo por transacción: Las operaciones homomórficas son extremadamente costosas computacionalmente, y cada nodo debe realizarlas. Los costos de gas son altos (por ejemplo, más de 100k de gas por una sola suma de 8 bits). Los contratos complejos están limitados por lo que cada validador puede calcular en un bloque. El rendimiento es mucho menor que el de los contratos inteligentes normales a menos que se emplee hardware especializado. La escalabilidad se mejora con criptografía más rápida y aceleración por hardware, pero fundamentalmente cada operación aumenta la carga de trabajo de la cadena.Bajo costo de verificación: Verificar una prueba sucinta es eficiente y de tamaño constante, por lo que el gas on-chain es modesto (cientos de miles de gas para cualquier tamaño de cómputo). Esto desacopla la complejidad de los límites de recursos on-chain: los grandes cómputos no tienen un costo on-chain adicional. Por lo tanto, escala en términos de carga on-chain. Off-chain, el tiempo de prueba puede ser significativo (minutos o más para tareas enormes) y podría requerir máquinas potentes, pero esto no ralentiza directamente la blockchain. El rendimiento general puede ser alto siempre que las pruebas se puedan generar a tiempo (potenciales redes de probadores en paralelo).
LatenciaLos resultados están disponibles inmediatamente en la misma transacción/bloque, ya que el cómputo ocurre durante la ejecución. Sin viajes de ida y vuelta adicionales: operación síncrona. Sin embargo, un mayor tiempo de procesamiento de bloques podría aumentar la latencia de la blockchain si las operaciones FHE son lentas.Inherente asíncrono. Típicamente requiere una transacción para solicitar y una transacción posterior (o devolución de llamada) para proporcionar la prueba/resultado. Esto introduce un retraso (posiblemente de segundos a horas dependiendo de la complejidad de la prueba y el hardware de prueba). No es adecuado para la finalidad instantánea de una sola transacción, más bien un modelo de trabajo asíncrono.
Garantías de privacidadFuerte: Todo (entradas, salidas, estado intermedio) puede permanecer cifrado on-chain. Puedes tener un estado cifrado de larga duración que múltiples transacciones actualizan sin revelarlo nunca. Solo las acciones de descifrado autorizadas (si las hay) revelan las salidas, y estas pueden controlarse mediante claves/ACLs. Sin embargo, consideraciones de canal lateral como el uso de gas o los registros de eventos deben gestionarse para que no filtren patrones (los diseños de fhEVM se esfuerzan por una ejecución ajena a los datos con gas constante para las operaciones para evitar fugas).Selectiva: La prueba revela lo que sea que esté en las salidas públicas o sea necesario para verificar (por ejemplo, un compromiso con el estado inicial). Los diseñadores pueden asegurarse de que solo se revele el resultado previsto, y todas las demás entradas permanezcan ocultas con conocimiento cero. Pero a diferencia del FHE, la blockchain típicamente no almacena el estado oculto; la privacidad se logra manteniendo los datos completamente off-chain. Si se necesita un estado privado persistente, el contrato puede almacenar un compromiso criptográfico con él (de modo que las actualizaciones de estado aún revelan un nuevo compromiso cada vez). La privacidad está limitada por lo que eliges probar; tienes flexibilidad para probar, por ejemplo, que se cumplió un umbral sin revelar valores exactos.
Aplicación de la integridadPor diseño, todos los validadores recalculan el siguiente estado homomórficamente, por lo que si un actor malicioso proporciona un resultado de texto cifrado incorrecto, otros detectarán una discrepancia: el consenso falla a menos que todos obtengan el mismo resultado. Por lo tanto, la integridad se aplica mediante la ejecución redundante (como en una blockchain normal, solo que con datos cifrados). A menudo se utilizan pruebas ZK adicionales para hacer cumplir las reglas de negocio (por ejemplo, que un usuario no pudo violar una restricción) porque los validadores no pueden verificar directamente las condiciones del texto plano.La integridad es aplicada por el contrato verificador que comprueba la prueba ZK. Mientras la prueba se verifique, se garantiza que el resultado es consistente con alguna ejecución válida del programa off-chain. No se necesita una suposición de mayoría honesta para la corrección; incluso un solo verificador honesto (el propio código del contrato) es suficiente. El contrato on-chain simplemente rechazará cualquier prueba falsa o faltante (similar a como rechazaría una firma inválida). Una consideración: si el probador aborta o se retrasa, el contrato puede necesitar una lógica de respaldo (o los usuarios pueden necesitar intentarlo de nuevo más tarde), pero no aceptará resultados incorrectos.
Experiencia del desarrolladorPros: Se pueden usar en gran medida lenguajes de contratos inteligentes familiares (Solidity, etc.) con extensiones. La confidencialidad es manejada por la plataforma; los desarrolladores se preocupan principalmente por qué cifrar y quién tiene las claves. La composición de contratos cifrados y normales es posible, manteniendo la componibilidad de DeFi (solo con variables cifradas). Contras: Deben entender las limitaciones de FHE, por ejemplo, no hay saltos condicionales directos sobre datos secretos sin un manejo especial, profundidad de circuito limitada (aunque el bootstrapping en TFHE permite una longitud de cómputo arbitraria a expensas del tiempo). Depurar la lógica cifrada puede ser complicado ya que no se pueden introspeccionar fácilmente los valores en tiempo de ejecución sin la clave. Además, la gestión de claves y los permisos agregan complejidad al diseño del contrato.Pros: Potencialmente se puede usar cualquier lenguaje de programación para la parte off-chain (especialmente con una zkVM). Aprovechar código/bibliotecas existentes en el programa off-chain (con advertencias sobre la compatibilidad con ZK). No se necesita criptografía personalizada por parte del desarrollador si se usa una ZKVM general: escriben código normal y obtienen una prueba. Además, el cómputo pesado puede usar bibliotecas (por ejemplo, código de aprendizaje automático) que nunca se ejecutarían on-chain. Contras: Los desarrolladores deben orquestar la infraestructura off-chain o usar un servicio de prueba. Manejar flujos de trabajo asíncronos e integrarlos con la lógica on-chain requiere más trabajo de diseño (por ejemplo, almacenar un estado pendiente, esperar una devolución de llamada). Escribir circuitos eficientes o código zkVM puede requerir aprender nuevas restricciones (por ejemplo, sin punto flotante, usar punto fijo o primitivas especiales; evitar ramificaciones pesadas que disparan el tiempo de prueba; optimizar para el recuento de restricciones). También existe la carga de lidiar con fallos de prueba, tiempos de espera, etc., que no son preocupaciones en Solidity regular. El ecosistema de herramientas está creciendo, pero es un nuevo paradigma para muchos.

Ambos enfoques están siendo mejorados activamente, e incluso vemos convergencia: como se señaló, las ZKPs se utilizan dentro de las FHE-VMs para ciertas verificaciones, y a la inversa, algunos investigadores proponen usar FHE para mantener privadas las entradas del probador en ZK (para que un probador en la nube no vea tus datos secretos). Es concebible que los sistemas futuros los combinen, por ejemplo, realizando FHE off-chain y luego probando la corrección de eso en la cadena, o usando FHE on-chain pero probando con ZK a los clientes ligeros que las operaciones cifradas se realizaron correctamente. Cada técnica tiene sus fortalezas: la FHE-VM ofrece privacidad continua e interacción en tiempo real a costa de un cómputo pesado, mientras que los coprocesadores ZK ofrecen escalabilidad y flexibilidad a costa de latencia y complejidad.

Casos de Uso e Implicaciones

La llegada de la privacidad programable desbloquea una gran cantidad de nuevas aplicaciones de blockchain en todas las industrias. A continuación, exploramos cómo las FHE-VMs y los coprocesadores ZK (o híbridos) pueden potenciar diversos dominios al permitir contratos inteligentes que preservan la privacidad y una economía de datos segura.

DeFi Confidencial y Finanzas

En las finanzas descentralizadas, la privacidad puede mitigar el front-running, proteger las estrategias de trading y satisfacer el cumplimiento normativo sin sacrificar la transparencia donde sea necesario. El DeFi Confidencial podría permitir a los usuarios interactuar con protocolos sin revelar sus posiciones al mundo.

  • Transacciones Privadas y Saldos Ocultos: Usando FHE, se pueden implementar transferencias de tokens confidenciales (saldos y transacciones ERC-20 cifrados) o pools protegidos en una L1 de blockchain. Ningún observador puede ver cuánto de un token tienes o transferiste, eliminando el riesgo de ataques dirigidos basados en las tenencias. Las pruebas ZK pueden asegurar que los saldos se mantengan sincronizados y que no ocurra un doble gasto (similar a Zcash pero en plataformas de contratos inteligentes). Un ejemplo es un AMM (Creador de Mercado Automatizado) confidencial donde las reservas del pool y las operaciones están cifradas on-chain. Los arbitrajistas o front-runners no pueden explotar el pool porque no pueden observar el deslizamiento de precios hasta después de que la operación se haya liquidado, reduciendo el MEV. Solo después de un cierto retraso o a través de un mecanismo de acceso controlado se podrían revelar algunos datos para auditoría.

  • Subastas y Trading Resistentes al MEV: Los mineros y los bots explotan la transparencia de las transacciones para hacer front-running en las operaciones. Con el cifrado, se podría tener un mempool cifrado o subastas por lotes donde las órdenes se envían en texto cifrado. Solo después de que la subasta se liquida, las operaciones se descifran. Este concepto, a veces llamado Flujo Justo de Órdenes, se puede lograr con descifrado de umbral (múltiples validadores descifran colectivamente el lote) o probando los resultados de la subasta a través de ZK sin revelar las ofertas individuales. Por ejemplo, un coprocesador ZK podría tomar un lote de ofertas selladas off-chain, calcular el precio de liquidación de la subasta y generar solo ese precio y los ganadores con pruebas. Esto preserva la equidad y la privacidad de las ofertas perdedoras.

  • Préstamos y Derivados Confidenciales: En los préstamos DeFi, los usuarios podrían no querer revelar el tamaño de sus préstamos o colateral (puede afectar el sentimiento del mercado o invitar a la explotación). Una FHE-VM puede mantener un libro de préstamos cifrado donde los detalles de cada préstamo están cifrados. La lógica del contrato inteligente aún puede hacer cumplir reglas como las condiciones de liquidación operando sobre factores de salud cifrados. Si el ratio de colateral de un préstamo cae por debajo del umbral, el contrato (con la ayuda de pruebas ZK) puede marcarlo para liquidación sin exponer nunca los valores exactos; podría simplemente producir una bandera de sí/no en texto plano. De manera similar, las posiciones secretas de derivados u opciones podrían gestionarse on-chain, revelando solo métricas de riesgo agregadas. Esto podría prevenir el copy trading y proteger estrategias propietarias, fomentando una mayor participación institucional.

  • Privacidad Conforme a la Normativa: No todos los contextos financieros desean un anonimato total; a veces se necesita una divulgación selectiva para la regulación. Con estas herramientas, podemos lograr una privacidad regulada: por ejemplo, las operaciones son privadas para el público, pero un exchange regulado puede descifrar o recibir pruebas sobre ciertas propiedades. Se podría probar a través de ZK que “esta operación no involucró una dirección en la lista negra y ambas partes están verificadas por KYC” sin revelar las identidades a la cadena. Este equilibrio podría satisfacer las reglas Anti-Lavado de Dinero (AML) mientras se mantienen confidenciales las identidades y posiciones de los usuarios para todos los demás. El FHE podría permitir que un contrato de oficial de cumplimiento on-chain escanee transacciones cifradas en busca de señales de riesgo (con una clave de descifrado accesible solo bajo orden judicial, por ejemplo).

Identidad Digital y Datos Personales

Los sistemas de identidad pueden beneficiarse significativamente de la tecnología de privacidad on-chain. Actualmente, poner credenciales o atributos personales en un registro público es impráctico debido a las leyes de privacidad y la renuencia de los usuarios. Con FHE y ZK, la identidad auto-soberana puede realizarse de una manera que preserve la privacidad:

  • Credenciales de Conocimiento Cero: Usando pruebas ZK (ya comunes en algunos proyectos de identidad), un usuario puede probar afirmaciones como “Soy mayor de 18 años”, “Tengo una licencia de conducir válida” o “Gano más de $50k (para calificación crediticia)” sin revelar ninguna otra información personal. Los coprocesadores ZK pueden mejorar esto manejando verificaciones más complejas off-chain, por ejemplo, probando que la puntuación de crédito de un usuario está por encima de un umbral consultando una base de datos de crédito privada de manera similar a Axiom, y generando solo un sí/no para la blockchain.

  • KYC Confidencial en DeFi: Imagina un protocolo DeFi que por ley debe asegurarse de que los usuarios estén verificados por KYC. Con FHE-VM, las credenciales de un usuario pueden almacenarse cifradas on-chain (o referenciadas a través de DID), y un contrato inteligente puede realizar un cómputo FHE para verificar que la información KYC cumple con los requisitos. Por ejemplo, un contrato podría verificar homomórficamente que el nombre y el SSN en un perfil de usuario cifrado coinciden con una lista de usuarios sancionados (también cifrada), o que el país del usuario no está restringido. El contrato solo obtendría un "aprobado/fallido" cifrado que puede ser descifrado por umbral por los validadores de la red a una bandera booleana. Solo se revela el hecho de que el usuario está permitido o no, preservando la confidencialidad de la PII y alineándose con los principios del GDPR. Esta divulgación selectiva garantiza el cumplimiento y la privacidad.

  • Acceso Basado en Atributos y Divulgación Selectiva: Los usuarios podrían tener un conjunto de credenciales verificables (edad, ciudadanía, habilidades, etc.) como atributos cifrados. Pueden autorizar a ciertas dApps a ejecutar cómputos sobre ellos sin divulgar todo. Por ejemplo, una dApp de reclutamiento descentralizada podría filtrar candidatos realizando búsquedas en currículums cifrados (usando FHE), por ejemplo, contar años de experiencia, verificar una certificación, y solo si se encuentra una coincidencia, contactar al candidato off-chain. Los detalles privados del candidato permanecen cifrados a menos que elijan revelarlos. Las pruebas ZK también pueden permitir a los usuarios probar selectivamente que poseen una combinación de atributos (por ejemplo, mayor de 21 y dentro de un cierto código postal) sin revelar los valores reales.

  • Verificación de Identidad Multipartita: A veces, la identidad de un usuario necesita ser verificada por múltiples partes (digamos, una verificación de antecedentes por la empresa A, una verificación de crédito por la empresa B). Con herramientas homomórficas y ZK, cada verificador podría contribuir con una puntuación o aprobación cifrada, y un contrato inteligente puede agregarlas a una decisión final sin exponer las contribuciones individuales. Por ejemplo, tres agencias proporcionan bits de "aprobado/fallido" cifrados, y el contrato emite una aprobación si las tres son aprobadas; el usuario o la parte que confía solo ve el resultado final, no qué agencia específica podría haberlos reprobado, preservando la privacidad del registro del usuario en cada agencia. Esto puede reducir el sesgo y el estigma asociados con, por ejemplo, una verificación fallida que revela un problema específico.

Salud y Compartición de Datos Sensibles

Los datos de salud son altamente sensibles y regulados, sin embargo, combinar datos de múltiples fuentes puede desbloquear un valor enorme (para investigación, seguros, medicina personalizada). La blockchain podría proporcionar una capa de confianza para el intercambio de datos si se resuelve la privacidad. Los contratos inteligentes confidenciales podrían permitir nuevos ecosistemas de datos de salud:

  • Intercambio Seguro de Datos Médicos: Los pacientes podrían almacenar referencias a sus registros médicos on-chain en forma cifrada. Un contrato habilitado para FHE podría permitir a una institución de investigación ejecutar análisis sobre una cohorte de datos de pacientes sin descifrarlos. Por ejemplo, un contrato podría calcular la eficacia promedio de un medicamento a través de los resultados cifrados de los pacientes. Solo los resultados estadísticos agregados salen descifrados (y quizás solo si se incluye un número mínimo de pacientes, para evitar la reidentificación). Los pacientes podrían recibir micropagos por contribuir con sus datos cifrados a la investigación, sabiendo que su privacidad se preserva porque incluso la blockchain y los investigadores solo ven texto cifrado o pruebas agregadas. Esto fomenta un mercado de datos para la salud que respeta la privacidad.

  • Procesamiento de Reclamaciones de Seguros que Preserva la Privacidad: El procesamiento de reclamaciones de seguros de salud podría automatizarse a través de contratos inteligentes que verifican condiciones sobre datos médicos sin exponer los datos a la aseguradora. Una reclamación podría incluir un código de diagnóstico cifrado y un costo de tratamiento cifrado; el contrato, usando FHE, verifica las reglas de la póliza (por ejemplo, cobertura, deducible) sobre esos datos cifrados. Podría generar una aprobación y un monto de pago sin revelar nunca el diagnóstico real a la blockchain de la aseguradora (solo el paciente y el médico tenían la clave). Las pruebas ZK podrían usarse para demostrar que los datos del paciente provinieron de los registros de un hospital certificado (usando algo como Axiom para verificar la firma de un hospital o la inclusión de un registro) sin revelar el registro en sí. Esto garantiza la privacidad del paciente mientras previene el fraude.

  • Cómputo de Datos Genómicos y Personales: Los datos genómicos son extremadamente sensibles (son literalmente el plano de ADN de una persona). Sin embargo, analizar genomas puede proporcionar valiosos conocimientos sobre la salud. Las empresas podrían usar FHE-VM para realizar cómputos sobre genomas cifrados subidos por los usuarios. Por ejemplo, un contrato inteligente podría ejecutar un modelo de riesgo gen-ambiente sobre datos genómicos cifrados y datos ambientales cifrados (quizás de wearables), generando una puntuación de riesgo que solo el usuario puede descifrar. La lógica (quizás un algoritmo de puntuación de riesgo poligénico) está codificada en el contrato y se ejecuta homomórficamente, por lo que los datos genómicos nunca aparecen en texto plano. De esta manera, los usuarios obtienen conocimientos sin dar a las empresas datos de ADN brutos, mitigando tanto las preocupaciones de privacidad como de propiedad de los datos.

  • Epidemiología y Salud Pública: Durante situaciones como pandemias, compartir datos es vital para modelar la propagación de enfermedades, pero las leyes de privacidad pueden obstaculizar el intercambio de datos. Los coprocesadores ZK podrían permitir a las autoridades de salud pública enviar consultas como “¿Cuántas personas en la región X dieron positivo en las últimas 24h?” a una red de datos de hospitales a través de pruebas. Cada hospital mantiene los registros de pruebas de los pacientes off-chain pero puede probar al contrato de la autoridad el recuento de positivos sin revelar quiénes son. De manera similar, el rastreo de contactos podría hacerse haciendo coincidir rastros de ubicación cifrados: los contratos pueden calcular intersecciones de historiales de ubicación cifrados de pacientes para identificar puntos calientes, generando solo las ubicaciones de los puntos calientes (y quizás una lista cifrada de identificaciones afectadas que solo el departamento de salud puede descifrar). Los rastros de ubicación brutos de los individuos permanecen privados.

Mercados de Datos y Colaboración

La capacidad de computar sobre datos sin revelarlos abre nuevos modelos de negocio en torno al intercambio de datos. Las entidades pueden colaborar en cómputos sabiendo que sus datos propietarios no serán expuestos:

  • Mercados de Datos Seguros: Los vendedores pueden poner datos a disposición en forma cifrada en un mercado de blockchain. Los compradores pueden pagar para ejecutar análisis específicos o modelos de aprendizaje automático sobre el conjunto de datos cifrado a través de un contrato inteligente, obteniendo ya sea el modelo entrenado o resultados agregados. Los datos brutos del vendedor nunca se revelan al comprador ni al público; el comprador podría recibir solo un modelo (que aún podría filtrar algo de información en los pesos, pero técnicas como la privacidad diferencial o el control de la granularidad de la salida pueden mitigar esto). Las pruebas ZK pueden asegurar al comprador que el cómputo se realizó correctamente sobre el conjunto de datos prometido (por ejemplo, el vendedor no puede hacer trampa ejecutando el modelo sobre datos ficticios porque la prueba lo vincula al conjunto de datos cifrado comprometido). Este escenario fomenta el intercambio de datos: por ejemplo, una empresa podría monetizar los datos de comportamiento del usuario permitiendo que algoritmos aprobados se ejecuten sobre ellos bajo cifrado, sin entregar los datos en sí.

  • Aprendizaje Federado e IA Descentralizada: En el aprendizaje automático descentralizado, múltiples partes (por ejemplo, diferentes empresas o dispositivos) quieren entrenar conjuntamente un modelo con sus datos combinados sin compartir datos entre sí. Las FHE-VMs sobresalen aquí: pueden habilitar el aprendizaje federado donde las actualizaciones del modelo de cada parte se agregan homomórficamente por un contrato. Debido a que las actualizaciones están cifradas, ningún participante aprende las contribuciones de los demás. El contrato podría incluso realizar partes del bucle de entrenamiento (como los pasos de descenso de gradiente) on-chain bajo cifrado, produciendo un modelo actualizado que solo las partes autorizadas pueden descifrar. ZK puede complementar esto probando que la actualización de cada parte se calculó siguiendo el algoritmo de entrenamiento (evitando que un participante malicioso envenene el modelo). Esto significa que se puede entrenar un modelo global con total auditabilidad on-chain, pero los datos de entrenamiento de cada contribuyente permanecen privados. Los casos de uso incluyen el entrenamiento conjunto de modelos de detección de fraude entre bancos o la mejora de asistentes de IA utilizando datos de muchos usuarios sin centralizar los datos brutos.

  • Análisis Inter-Organizacional: Considera dos empresas que quieren encontrar su intersección de clientes para una campaña de asociación sin exponer sus listas completas de clientes entre sí. Podrían cifrar cada una sus listas de ID de clientes y subir un compromiso. Un contrato habilitado para FHE puede calcular la intersección en los conjuntos cifrados (usando técnicas como la intersección de conjuntos privados a través de FHE). El resultado podría ser una lista cifrada de IDs de clientes comunes que solo un tercero de confianza mutua (o los propios clientes, a través de algún mecanismo) puede descifrar. Alternativamente, un enfoque ZK: una parte prueba a la otra en conocimiento cero que “tenemos N clientes en común y aquí hay un cifrado de esos IDs” con una prueba de que el cifrado corresponde efectivamente a las entradas comunes. De esta manera, pueden proceder con una campaña para esos N clientes sin intercambiar nunca sus listas completas en texto plano. Escenarios similares: calcular métricas de la cadena de suministro entre competidores sin revelar detalles de proveedores individuales, o bancos que cotejan información crediticia sin compartir datos completos de clientes.

  • Cómputo Seguro Multipartito (MPC) en Blockchain: FHE y ZK esencialmente traen conceptos de MPC on-chain. La lógica de negocio compleja que abarca múltiples organizaciones puede codificarse en un contrato inteligente de tal manera que las entradas de cada organización se compartan en secreto o se cifren. El contrato (como facilitador de MPC) produce salidas como divisiones de ganancias, cálculos de costos o evaluaciones de riesgo conjuntas en las que todos pueden confiar. Por ejemplo, supongamos que varias compañías de energía quieren liquidar un mercado de comercio de energía. Podrían alimentar sus ofertas y demandas cifradas en una subasta de contrato inteligente; el contrato calcula los precios de liquidación y las asignaciones sobre las ofertas cifradas, y genera la asignación y el costo de cada compañía solo para esa compañía (a través de cifrado a su clave pública). Ninguna compañía ve las ofertas de las demás, protegiendo la información competitiva, pero el resultado de la subasta es justo y verificable. Esta combinación de transparencia de blockchain y privacidad de MPC podría revolucionar los consorcios y las alianzas empresariales que actualmente dependen de terceros de confianza.

Aprendizaje Automático Descentralizado (ZKML y FHE-ML)

Llevar el aprendizaje automático a las blockchains de una manera verificable y privada es una frontera emergente:

  • Inferencia de ML Verificable: Usando pruebas ZK, se puede probar que “un modelo de aprendizaje automático f, cuando se le da la entrada x, produce la salida y” sin revelar ni x (si son datos privados) ni el funcionamiento interno de f (si los pesos del modelo son propietarios). Esto es crucial para los servicios de IA en blockchain, por ejemplo, un oráculo de IA descentralizado que proporciona predicciones o clasificaciones. Un coprocesador ZK puede ejecutar el modelo off-chain (ya que los modelos pueden ser grandes y costosos de evaluar) y publicar una prueba del resultado. Por ejemplo, un oráculo podría probar la afirmación “La imagen satelital proporcionada muestra al menos un 50% de cobertura arbórea” para respaldar un contrato de créditos de carbono, sin revelar la imagen satelital o posiblemente incluso el modelo. Esto se conoce como ZKML y hay proyectos trabajando en la optimización de redes neuronales amigables con los circuitos. Asegura la integridad de las salidas de IA utilizadas en los contratos inteligentes (sin trampas ni salidas arbitrarias) y puede preservar la confidencialidad de los datos de entrada y los parámetros del modelo.

  • Entrenamiento con Privacidad y Auditabilidad: Entrenar un modelo de ML es aún más intensivo en cómputo, pero si se logra, permitiría mercados de modelos basados en blockchain. Múltiples proveedores de datos podrían contribuir al entrenamiento de un modelo bajo FHE para que el algoritmo de entrenamiento se ejecute sobre datos cifrados. El resultado podría ser un modelo cifrado que solo el comprador puede descifrar. A lo largo del entrenamiento, se podrían suministrar pruebas ZK periódicamente para probar que el entrenamiento seguía el protocolo (evitando que un entrenador malicioso inserte una puerta trasera, por ejemplo). Si bien el entrenamiento de ML completamente on-chain está lejos dados los costos, un enfoque híbrido podría usar cómputo off-chain con pruebas ZK para partes críticas. Se podría imaginar una competencia descentralizada tipo Kaggle donde los participantes entrenan modelos en conjuntos de datos privados y envían pruebas ZK de la precisión del modelo en datos de prueba cifrados para determinar un ganador, todo sin revelar los conjuntos de datos ni los datos de prueba.

  • IA Personalizada y Propiedad de los Datos: Con estas tecnologías, los usuarios podrían retener la propiedad de sus datos personales y aun así beneficiarse de la IA. Por ejemplo, el dispositivo móvil de un usuario podría usar FHE para cifrar sus datos de uso y enviarlos a un contrato de análisis que calcula un modelo de IA personalizado (como un modelo de recomendación) solo para ellos. El modelo está cifrado y solo el dispositivo del usuario puede descifrarlo y usarlo localmente. La plataforma (quizás una red social) nunca ve los datos brutos ni el modelo, pero el usuario obtiene el beneficio de la IA. Si la plataforma quiere conocimientos agregados, podría solicitar pruebas ZK de ciertos patrones agregados del contrato sin acceder a los datos individuales.

Áreas Adicionales

  • Juegos: Los juegos on-chain a menudo tienen dificultades para ocultar información secreta (por ejemplo, manos de cartas ocultas, niebla de guerra en juegos de estrategia). FHE puede habilitar juegos de estado oculto donde la lógica del juego se ejecuta sobre un estado cifrado. Por ejemplo, un contrato de juego de póker podría barajar y repartir cartas cifradas; los jugadores obtienen descifrados de sus propias cartas, pero el contrato y los demás solo ven texto cifrado. La lógica de apuestas puede usar pruebas ZK para asegurar que un jugador no está mintiendo sobre una acción (o para revelar la mano ganadora al final de una manera verificablemente justa). De manera similar, las semillas aleatorias para la acuñación de NFT o los resultados de los juegos pueden generarse y probarse como justas sin exponer la semilla (evitando la manipulación). Esto puede mejorar enormemente los juegos de blockchain, permitiéndoles soportar la misma dinámica que los juegos tradicionales.

  • Votación y Gobernanza: Las DAOs podrían usar tecnología de privacidad para votaciones secretas on-chain, eliminando la compra de votos y la presión. La FHE-VM podría contar los votos que se emiten en forma cifrada, y solo los totales finales se descifran. Las pruebas ZK pueden asegurar que cada voto fue válido (provino de un votante elegible, que no ha votado dos veces) sin revelar quién votó por qué. Esto proporciona verificabilidad (todos pueden verificar las pruebas y el recuento) mientras se mantienen secretos los votos individuales, lo cual es crucial para una gobernanza imparcial.

  • Cadena de Suministro Segura e IoT: En las cadenas de suministro, los socios podrían querer compartir pruebas de ciertas propiedades (origen, métricas de calidad) sin exponer todos los detalles a los competidores. Por ejemplo, un sensor de IoT en un envío de alimentos podría enviar continuamente datos de temperatura cifrados a una blockchain. Un contrato podría usar FHE para verificar si la temperatura se mantuvo en un rango seguro durante todo el tránsito. Si se excedió un umbral, puede activar una alerta o una penalización, pero no tiene que revelar todo el registro de temperatura públicamente, quizás solo una prueba o un agregado como “temperatura del percentil 90”. Esto genera confianza en la automatización de la cadena de suministro mientras se respeta la confidencialidad de los datos del proceso.

Cada uno de estos casos de uso aprovecha la capacidad central: computar o verificar datos sin revelar los datos. Esta capacidad puede cambiar fundamentalmente la forma en que manejamos la información sensible en los sistemas descentralizados. Reduce el compromiso entre la transparencia y la privacidad que ha limitado la adopción de la blockchain en áreas que tratan con datos privados.

Conclusión

La tecnología blockchain está entrando en una nueva era de privacidad programable, donde la confidencialidad de los datos y la funcionalidad de los contratos inteligentes van de la mano. Los paradigmas de FHE-VM y coprocesadores ZK, aunque técnicamente distintos, ambos se esfuerzan por expandir el alcance de las aplicaciones de blockchain al desacoplar lo que podemos computar de lo que debemos revelar.

Las Máquinas Virtuales de Cifrado Totalmente Homomórfico mantienen los cómputos on-chain y cifrados, preservando la descentralización y la componibilidad, pero exigiendo avances en eficiencia. Los coprocesadores de Conocimiento Cero trasladan el trabajo pesado off-chain, permitiendo un cómputo virtualmente ilimitado bajo garantías criptográficas, y ya están demostrando su valía en el escalado y la mejora de Ethereum. La elección entre ellos (y sus híbridos) dependerá del caso de uso: si se necesita una interacción en tiempo real con un estado privado, un enfoque FHE podría ser más adecuado; si se requiere un cómputo extremadamente complejo o la integración con código existente, un coprocesador ZK podría ser el camino a seguir. En muchos casos, son complementarios; de hecho, vemos pruebas ZK reforzando la integridad de FHE, y FHE potencialmente ayudando a ZK al manejar datos privados para los probadores.

Para los desarrolladores, estas tecnologías introducirán nuevos patrones de diseño. Pensaremos en términos de variables cifradas y verificación de pruebas como elementos de primera clase en la arquitectura de las dApps. Las herramientas están evolucionando rápidamente: lenguajes de alto nivel y SDKs están abstrayendo los detalles criptográficos (por ejemplo, las bibliotecas de Zama que hacen que los tipos FHE sean tan fáciles como los tipos nativos, o las plantillas de RISC Zero para solicitudes de prueba). En unos pocos años, escribir un contrato inteligente confidencial podría sentirse casi tan sencillo como escribir uno regular, solo que con la privacidad "incorporada" por defecto.

Las implicaciones para la economía de datos son profundas. Los individuos y las empresas estarán más dispuestos a poner datos o lógica on-chain cuando puedan controlar su visibilidad. Esto puede desbloquear colaboraciones inter-organizacionales, nuevos productos financieros y modelos de IA que antes eran inviables debido a preocupaciones de privacidad. Los reguladores también pueden llegar a adoptar estas técnicas, ya que permiten verificaciones de cumplimiento y auditorías a través de medios criptográficos (por ejemplo, probar que los impuestos se pagan correctamente on-chain sin exponer todas las transacciones).

Todavía estamos en los primeros días: los prototipos actuales de FHE-VM tienen límites de rendimiento, y las pruebas ZK, aunque mucho más rápidas que antes, todavía pueden ser un cuello de botella para tareas extremadamente complejas. Pero la investigación continua y los esfuerzos de ingeniería (incluido el hardware especializado, como lo demuestran empresas como Optalysys que impulsan la aceleración óptica de FHE) están erosionando rápidamente estas barreras. La financiación que fluye hacia este espacio (por ejemplo, el estatus de unicornio de Zama, la inversión de Paradigm en Axiom) subraya una fuerte creencia de que las características de privacidad serán tan fundamentales para la Web3 como lo fue la transparencia para la Web1/2.

En conclusión, la privacidad programable a través de FHE-VMs y coprocesadores ZK anuncia una nueva clase de dApps que son sin confianza, descentralizadas y confidenciales. Desde operaciones DeFi que no revelan detalles, hasta investigaciones de salud que protegen los datos de los pacientes, pasando por modelos de aprendizaje automático entrenados en todo el mundo sin exponer datos brutos, las posibilidades son vastas. A medida que estas tecnologías maduren, las plataformas de blockchain ya no forzarán el compromiso entre utilidad y privacidad, permitiendo una adopción más amplia en industrias que requieren confidencialidad. El futuro de la Web3 es uno donde los usuarios y las organizaciones pueden transaccionar y computar con confianza datos sensibles on-chain, sabiendo que la blockchain verificará la integridad mientras mantiene sus secretos a salvo.

Fuentes: La información en este informe se extrae de la documentación técnica y blogs de investigación recientes de proyectos líderes en este espacio, incluyendo la documentación de FHEVM de Cypher y Zama, análisis detallados de Trail of Bits sobre los circuitos de Axiom, guías para desarrolladores y publicaciones de blog de RISC Zero, así como artículos de la industria que destacan casos de uso de la tecnología de blockchain confidencial. Estas fuentes y más han sido citadas a lo largo del texto para proporcionar lecturas adicionales y evidencia para las arquitecturas y aplicaciones descritas.