22 publicaciones etiquetados con "Criptografía"

La blockchain Sui se distingue de sus competidores por su agilidad criptográfica fundamental y su arquitectura centrada en objetos, posicionándola como la única blockchain de Capa 1 importante que avanza simultáneamente la integración de IA, la coordinación robótica y la seguridad resistente a la computación cuántica. Esto no es un posicionamiento de marketing, es una realidad arquitectónica. El cofundador y criptógrafo jefe Kostas "Kryptos" Chalkias ha incorporado sistemáticamente estas capacidades en el diseño central de Sui desde su inicio, creando lo que él describe como una infraestructura que "superará incluso a Visa en velocidad" mientras permanece segura contra las amenazas cuánticas que podrían "destruir toda la criptografía moderna" en una década.

La base técnica ya está lista para la producción: la finalidad del consenso de 390 milisegundos permite la coordinación de agentes de IA en tiempo real, la ejecución paralela procesa 297.000 transacciones por segundo en su pico, y los esquemas de firma EdDSA proporcionan una ruta de migración probada a la criptografía post-cuántica sin requerir bifurcaciones duras. Mientras tanto, Bitcoin y Ethereum se enfrentan a amenazas existenciales de la computación cuántica sin una ruta de actualización compatible con versiones anteriores. La visión de Chalkias se centra en tres pilares convergentes: la IA como capa de coordinación, los sistemas robóticos autónomos que requieren una finalidad en menos de un segundo, y los marcos criptográficos que permanecen seguros hasta 2035 y más allá. Sus declaraciones en conferencias, trabajos de investigación e implementaciones técnicas revelan no promesas especulativas, sino una ejecución sistemática de una hoja de ruta establecida en la fundación de Mysten Labs en 2022.

Esto importa más allá del tribalismo de las blockchains. Para 2030, los mandatos del NIST requieren la deprecación de los estándares de cifrado actuales. Los sistemas autónomos, desde robots de fabricación hasta agentes de IA, requerirán una coordinación sin confianza a escala. La arquitectura de Sui aborda ambas inevitabilidades simultáneamente, mientras los competidores se apresuran a adaptar soluciones. La pregunta no es si estas tecnologías convergen, sino qué plataformas sobreviven intactas a la convergencia.

El criptógrafo que llamó a su hijo Kryptos​

Kostas Chalkias aporta una credibilidad poco común a la intersección de la blockchain con las tecnologías emergentes. Antes de cofundar Mysten Labs, se desempeñó como criptógrafo principal para el proyecto Diem de Meta y la billetera Novi, trabajó con Mike Hearn (uno de los primeros desarrolladores de Bitcoin asociados con Satoshi Nakamoto) en la blockchain Corda de R3, y posee un doctorado en Criptografía Basada en Identidad con más de 50 publicaciones científicas, 8 patentes estadounidenses y 1.374 citas académicas. Su dedicación al campo se extiende a nombrar a su hijo Kryptos —"Estoy tan inmerso en la tecnología de la blockchain y la criptografía, que de hecho convencí a mi esposa de tener un hijo que se llama Kryptos", explicó durante una entrevista en el blog de Sui.

Su trayectoria profesional revela un enfoque consistente en la criptografía práctica para una escala masiva. En Facebook, construyó infraestructura de seguridad para WhatsApp y sistemas de autenticación que servían a miles de millones. En R3, fue pionero en pruebas de conocimiento cero y firmas post-cuánticas para blockchains empresariales. Su carrera temprana incluyó la fundación de Betmanager, una plataforma impulsada por IA que predecía resultados de fútbol utilizando técnicas del mercado de valores, experiencia que informa su perspectiva actual sobre la integración blockchain-IA. Esta combinación de exposición a la IA, criptografía de producción e infraestructura blockchain lo posiciona de manera única para diseñar sistemas que unan estos dominios.

La filosofía técnica de Chalkias enfatiza la "agilidad criptográfica": construir flexibilidad en los protocolos fundamentales en lugar de asumir la permanencia. En la Conferencia Emergence en Praga (diciembre de 2024), articuló esta visión del mundo: "Eventualmente, la blockchain superará incluso a Visa en velocidad de transacción. Será la norma. No veo cómo podemos escapar de esto". Pero la velocidad por sí sola no es suficiente. Su trabajo combina consistentemente el rendimiento con la seguridad prospectiva, reconociendo que las computadoras cuánticas plantean amenazas que requieren acción hoy, no cuando el peligro se materialice. Este doble enfoque —rendimiento actual y resiliencia futura— define las decisiones arquitectónicas de Sui en IA, robótica y resistencia cuántica.

Arquitectura construida para agentes inteligentes​

La base técnica de Sui diverge fundamentalmente de las blockchains basadas en cuentas como Ethereum y Solana. Cada entidad existe como un objeto con una ID globalmente única de 32 bytes, un número de versión, un campo de propiedad y contenido tipado. Este modelo centrado en objetos no es una preferencia estética, sino un habilitador de la ejecución paralela a escala. Cuando los agentes de IA operan como objetos propios, evitan el consenso por completo para operaciones de un solo escritor, logrando una finalidad de ~400 ms. Cuando múltiples agentes se coordinan a través de objetos compartidos, el consenso Mysticeti de Sui ofrece una latencia de 390 ms, aún en menos de un segundo, pero a través de un acuerdo tolerante a fallos bizantinos.

El lenguaje de programación Move, desarrollado originalmente en Meta para Diem y mejorado para Sui, impone la seguridad de los recursos a nivel del sistema de tipos. Los activos no pueden copiarse, destruirse o crearse accidentalmente sin permiso. Para aplicaciones de IA que gestionan datos valiosos o pesos de modelos, esto previene clases enteras de vulnerabilidades que afectan a los contratos inteligentes de Solidity. Chalkias destacó esto durante Sui Basecamp 2025 en Dubái: "Introdujimos pruebas de conocimiento cero, tecnologías de preservación de la privacidad, dentro de Sui desde el primer día. Así, alguien ahora puede crear un sistema KYC con tanta privacidad como desee".

La ejecución paralela de transacciones alcanza límites teóricos mediante la declaración explícita de dependencias. A diferencia de la ejecución optimista que requiere verificación retroactiva, el planificador de Sui identifica transacciones no superpuestas de antemano a través de IDs de objeto únicas. Las operaciones independientes se ejecutan concurrentemente en los núcleos de los validadores sin interferencia. Esta arquitectura demostró un rendimiento máximo de 297.000 TPS en pruebas, no máximos teóricos, sino rendimiento medido en hardware de producción. Para aplicaciones de IA, esto significa que miles de solicitudes de inferencia se procesan simultáneamente, múltiples agentes autónomos se coordinan sin bloqueo y la toma de decisiones en tiempo real opera a velocidades perceptibles para los humanos.

El protocolo de consenso Mysticeti, introducido en 2024, logra lo que Chalkias y sus coautores demostraron matemáticamente óptimo: tres rondas de mensajes para la confirmación. Al eliminar la certificación explícita de bloques e implementar estructuras DAG no certificadas, Mysticeti redujo la latencia en un 80% con respecto al consenso Narwhal-Bullshark anterior. El protocolo confirma bloques en cada ronda en lugar de cada dos rondas, utilizando reglas de decisión directas e indirectas derivadas de patrones DAG. Para aplicaciones de robótica que requieren retroalimentación de control en tiempo real, esta finalidad en menos de un segundo se vuelve innegociable. Durante la Korea Blockchain Week 2025, Chalkias posicionó a Sui como "una capa de coordinación para aplicaciones e IA", enfatizando cómo los socios en pagos, juegos e IA aprovechan esta base de rendimiento.

Walrus: resolviendo el problema de datos de la IA​

Las cargas de trabajo de IA exigen almacenamiento a escalas incompatibles con la economía tradicional de las blockchains. Los conjuntos de datos de entrenamiento abarcan terabytes, los pesos de los modelos requieren gigabytes y los registros de inferencia se acumulan rápidamente. Sui aborda esto a través de Walrus, un protocolo de almacenamiento descentralizado que utiliza codificación de borrado para lograr una replicación de 4 a 5 veces en lugar de la replicación de 100 veces típica del almacenamiento en cadena. El algoritmo "Red Stuff" divide los datos en fragmentos distribuidos entre los nodos de almacenamiento, permaneciendo recuperables con 2/3 de los nodos no disponibles. Los metadatos y las pruebas de disponibilidad residen en la blockchain de Sui, mientras que los datos reales residen en Walrus, creando un almacenamiento criptográficamente verificable a escala de exabytes.

Durante el primer mes de la testnet de Walrus, la red almacenó más de 4.343 GB en más de 25 nodos comunitarios, validando la viabilidad de la arquitectura. Proyectos como TradePort, Tusky y Decrypt Media integraron Walrus para el almacenamiento y la recuperación de medios. Para aplicaciones de IA, esto permite escenarios prácticos: conjuntos de datos de entrenamiento tokenizados como activos programables con términos de licencia codificados en contratos inteligentes, pesos de modelos persistidos con control de versiones, resultados de inferencia registrados inmutablemente para pistas de auditoría y contenido generado por IA almacenado de manera rentable. La capa de inferencia de IA de Atoma Network, anunciada como el primer socio de integración de IA de blockchain de Sui, aprovecha esta base de almacenamiento para la generación automatizada de código, la automatización de flujos de trabajo y el análisis de riesgos DeFi.

La integración se extiende más allá del almacenamiento a la orquestación de la computación. Los Bloques de Transacciones Programables (PTB) de Sui agrupan hasta 1.024 operaciones heterogéneas de forma atómica, ejecutándose todo o nada. Un flujo de trabajo de IA podría recuperar datos de entrenamiento de Walrus, actualizar los pesos del modelo en un contrato inteligente, registrar los resultados de la inferencia en cadena y distribuir recompensas a los contribuyentes de datos, todo en una única transacción atómica. Esta componibilidad, combinada con la seguridad de tipos de Move, crea bloques de construcción para sistemas de IA complejos sin la fragilidad de las llamadas entre contratos en otros entornos.

Chalkias enfatizó la capacidad sobre el marketing durante el podcast Just The Metrics (julio de 2025), señalando las "ineficiencias en la gestión de datos sanitarios" como áreas de aplicación práctica. La IA en el sector sanitario requiere coordinación entre instituciones, preservación de la privacidad para datos sensibles y computación verificable para el cumplimiento normativo. La arquitectura de Sui —que combina la coordinación en cadena, el almacenamiento de Walrus y la privacidad de conocimiento cero— aborda estos requisitos de forma técnica en lugar de conceptual. La asociación con Google Cloud anunciada en 2024 reforzó esta dirección, integrando los datos de Sui en BigQuery para análisis y entrenando la plataforma Vertex AI de Google en el lenguaje Move para el desarrollo asistido por IA.

Cuando los robots necesitan liquidación en menos de un segundo​

La visión de la robótica se materializa más concretamente a través de las capacidades técnicas que de las asociaciones anunciadas. El modelo de objetos de Sui representa robots, herramientas y tareas como ciudadanos de primera clase en la cadena con control de acceso granular. A diferencia de los sistemas basados en cuentas donde los robots interactúan a través de permisos a nivel de cuenta, los objetos de Sui permiten sistemas de permisos multinivel, desde la operación básica hasta el control total con requisitos de multifirma. La integración de PassKeys y FaceID admite escenarios con intervención humana, mientras que los zkTunnels permiten la transmisión de comandos sin gas para operaciones remotas en tiempo real.

Durante las discusiones en redes sociales, Chalkias (publicando como "Kostas Kryptos") reveló que ingenieros de Sui con experiencia en NASA, Meta y Uber estaban probando robots cuadrúpedos tipo perro en la red. La arquitectura basada en objetos se adapta a la coordinación robótica: cada robot posee objetos que representan su estado y capacidades, las tareas existen como objetos transferibles con parámetros de ejecución, y la asignación de recursos se realiza a través de la composición de objetos en lugar de una coordinación centralizada. Una instalación de fabricación podría desplegar flotas de robots donde cada unidad acepta tareas de forma autónoma, se coordina con sus pares a través de objetos compartidos, ejecuta operaciones con verificación criptográfica y liquida micropagos por los servicios prestados, todo sin autoridad central ni intervención humana.

El modo de transacción "sin internet", discutido durante Sui Basecamp 2025 y el podcast London Real (abril de 2025), aborda las limitaciones del mundo real de la robótica. Chalkias describió cómo el sistema mantuvo la funcionalidad durante los cortes de energía en España y Portugal, con tamaños de transacción optimizados hacia bytes individuales utilizando formatos preestablecidos. Para sistemas autónomos que operan en zonas de desastre, áreas rurales o entornos con conectividad poco fiable, esta resiliencia se vuelve crítica. Los robots pueden realizar transacciones de igual a igual para una coordinación inmediata, sincronizándose con la red más amplia cuando se restablece la conectividad.

El proyecto 3DOS ejemplifica esta visión en la práctica: una red de impresión 3D basada en blockchain que permite la fabricación bajo demanda donde las máquinas imprimen piezas de forma autónoma. Las futuras iteraciones prevén robots autorreparables que detectan fallos de componentes, solicitan reemplazos a través de contratos inteligentes, identifican impresoras 3D cercanas mediante descubrimiento en cadena, coordinan la impresión y entrega, e instalan componentes, todo de forma autónoma. Esto no es ciencia ficción, sino una extensión lógica de las capacidades existentes: la integración de microcontroladores ESP32 y Arduino ya es compatible con dispositivos IoT básicos, BugDar proporciona auditoría de seguridad para contratos inteligentes robóticos, y las aprobaciones multifirma permiten una autonomía gradual con supervisión humana para operaciones críticas.

El reloj cuántico está en marcha​

El tono de Kostas Chalkias cambia de filosófico a urgente cuando habla de la computación cuántica. En un informe de investigación de julio de 2025, advirtió sin rodeos: "Los gobiernos son muy conscientes de los riesgos que plantea la computación cuántica. Agencias de todo el mundo han emitido mandatos para que los algoritmos clásicos como ECDSA y RSA sean deprecados para 2030 o 2035". Su anuncio en Twitter acompañó la investigación innovadora de Mysten Labs publicada en el Archivo ePrint de la IACR, demostrando cómo las blockchains basadas en EdDSA como Sui, Solana, Near y Cosmos poseen ventajas estructurales para la transición cuántica que no están disponibles para Bitcoin y Ethereum.

La amenaza proviene de las computadoras cuánticas que ejecutan el Algoritmo de Shor, que factoriza eficientemente números grandes, la dificultad matemática subyacente a la criptografía RSA, ECDSA y BLS. El procesador cuántico Willow de Google con 105 qubits señala un progreso acelerado hacia máquinas capaces de romper el cifrado clásico. El ataque de "almacenar ahora, descifrar después" agrava la urgencia: los adversarios recopilan datos cifrados hoy, esperando que las computadoras cuánticas los descifren retroactivamente. Para los activos de blockchain, Chalkias explicó a Decrypt Magazine: "Incluso si alguien todavía posee su clave privada de Bitcoin o Ethereum, es posible que no pueda generar una prueba de propiedad segura post-cuántica, y esto se reduce a cómo se generó originalmente esa clave y cuántos de sus datos asociados han sido expuestos con el tiempo".

La vulnerabilidad particular de Bitcoin se deriva de las billeteras "dormidas" con claves públicas expuestas. Se estima que 1 millón de BTC de Satoshi Nakamoto residen en direcciones tempranas que utilizan el formato de pago a clave pública: la clave pública es visible en la cadena en lugar de estar oculta detrás de direcciones hash. Una vez que las computadoras cuánticas escalen lo suficiente, estas billeteras pueden ser vaciadas instantáneamente. La evaluación de Chalkias: "Una vez que lleguen las computadoras cuánticas, millones de billeteras, incluida la de Satoshi, podrían ser vaciadas instantáneamente. Si su clave pública es visible, eventualmente será descifrada". Ethereum enfrenta desafíos similares, aunque un menor número de claves públicas expuestas mitiga el riesgo inmediato. Ambas cadenas requieren bifurcaciones duras a nivel de toda la comunidad con una coordinación sin precedentes para migrar, asumiendo que se forme un consenso en torno a los algoritmos post-cuánticos.

La base EdDSA de Sui proporciona una elegante vía de escape. A diferencia de las claves privadas aleatorias de ECDSA, EdDSA deriva las claves de forma determinista a partir de una semilla utilizando funciones hash según el RFC 8032. Esta diferencia estructural permite pruebas de conocimiento cero a través de zk-STARKs (que son seguras post-cuánticas) que demuestran el conocimiento de la semilla subyacente sin exponer datos de curva elíptica. Los usuarios construyen pares de claves post-cuánticas a partir de la misma aleatoriedad de la semilla, envían pruebas ZK que demuestran una propiedad idéntica y realizan la transición a esquemas seguros cuánticamente mientras preservan las direcciones, sin necesidad de una bifurcación dura. Chalkias detalló esto durante el AMA de Sui de junio de 2022: "Si estás utilizando algoritmos deterministas, como EdDSA, hay una forma con pruebas Stark de demostrar el conocimiento de las pirámides de tu clave privada en una generación de clave EdDSA, porque utiliza una función hash internamente".

La agilidad criptográfica como foso estratégico​

Sui admite múltiples esquemas de firma simultáneamente a través de alias de tipo unificados en todo el código base: EdDSA (Ed25519), ECDSA (para compatibilidad con Ethereum) y algoritmos post-cuánticos planificados. Chalkias diseñó esta "agilidad criptográfica" reconociendo que la permanencia es una fantasía en criptografía. La arquitectura se asemeja a "cambiar el núcleo de una cerradura" en lugar de reconstruir todo el sistema de seguridad. Cuando se implementen los algoritmos post-cuánticos recomendados por el NIST —CRYSTALS-Dilithium para firmas, FALCON para alternativas compactas, SPHINCS+ para esquemas basados en hash—, Sui los integrará mediante actualizaciones sencillas en lugar de reescrituras fundamentales del protocolo.

Las estrategias de transición equilibran enfoques proactivos y adaptativos. Para las nuevas direcciones, los usuarios pueden generar configuraciones PQ-signs-PreQ donde las claves post-cuánticas firman claves públicas pre-cuánticas en el momento de la creación, lo que permite una migración futura fluida. Para las direcciones existentes, el método de prueba zk-STARK preserva las direcciones al tiempo que demuestra la propiedad segura cuánticamente. La defensa por capas prioriza los datos de alto valor: las claves privadas de las billeteras reciben protección PQ inmediata, mientras que los datos de privacidad transitorios siguen rutas de actualización más lentas. Las salidas de las funciones hash se expanden de 256 bits a 384 bits para la resistencia a colisiones contra el algoritmo de Grover, y las longitudes de las claves de cifrado simétrico se duplican (AES sigue siendo resistente a la computación cuántica con claves más grandes).

Los sistemas de pruebas de conocimiento cero requieren una consideración cuidadosa. Los PCP lineales como Groth16 (que actualmente impulsan zkLogin) se basan en curvas elípticas amigables con el emparejamiento vulnerables a ataques cuánticos. La hoja de ruta de transición de Sui avanza hacia sistemas STARK basados en hash —Winterfell, codesarrollado por Mysten Labs, utiliza solo funciones hash y sigue siendo plausiblemente seguro post-cuántico. La migración de zkLogin mantiene las mismas direcciones mientras actualiza los circuitos internos, lo que requiere coordinación con los proveedores de OpenID a medida que adoptan tokens PQ-JWT. Las balizas de aleatoriedad y los protocolos de generación de claves distribuidas pasan de firmas BLS de umbral a alternativas basadas en retículos como los esquemas HashRand o HERB —cambios de protocolo internos invisibles para las API en cadena.

La experiencia de Chalkias resulta crítica aquí. Como autor de BPQS (Blockchain Post-Quantum Signature), una variante del esquema XMSS basado en hash, aporta experiencia de implementación más allá del conocimiento teórico. Su compromiso de junio de 2022 resultó profético: "Construiremos nuestra cadena de una manera en la que, con solo pulsar un botón, la gente pueda pasar a claves post-cuánticas". Los plazos del NIST —2030 para la deprecación de algoritmos clásicos, 2035 para la adopción completa de PQ— comprimen drásticamente los plazos. La ventaja inicial de Sui la posiciona favorablemente, pero Chalkias enfatiza la urgencia: "Si su blockchain admite activos soberanos, tesorerías nacionales en cripto, ETF o CBDC, pronto se le exigirá que adopte estándares criptográficos post-cuánticos, si su comunidad se preocupa por la credibilidad a largo plazo y la adopción masiva".

Los agentes de IA ya generan $1.8 mil millones en valor​

El ecosistema va más allá de la infraestructura y se adentra en las aplicaciones de producción. Dolphin Agent (DOLA), especializado en seguimiento y análisis de datos de blockchain, alcanzó una capitalización de mercado de más de $1.8 mil millones, validando la demanda de herramientas de blockchain mejoradas con IA. SUI Agents proporciona una implementación de agente de IA con un solo clic con creación de persona de Twitter, tokenización y comercio dentro de ecosistemas descentralizados. Sentient AI recaudó $1.5 millones para chatbots conversacionales que aprovechan la seguridad y escalabilidad de Sui. DeSci Agents promueve compuestos científicos como Epitalon y Rapamicina a través de un compromiso impulsado por IA las 24 horas del día, los 7 días de la semana, uniendo la investigación y la inversión a través del emparejamiento de tokens.

La integración de Atoma Network como el primer socio de inferencia de IA de blockchain de Sui permite capacidades que abarcan la generación y auditoría automatizada de código, la automatización de flujos de trabajo, el análisis de riesgos DeFi, la generación de activos de juegos, la clasificación de contenido de redes sociales y la gestión de DAO. La selección de la asociación reflejó los requisitos técnicos: Atoma necesitaba baja latencia para IA interactiva, alto rendimiento para escala, propiedad segura para activos de IA, computación verificable, almacenamiento rentable y opciones de preservación de la privacidad. Sui entregó las seis. Durante Sui Basecamp 2025, Chalkias destacó proyectos como Aeon, los agentes de IA de Atoma y el trabajo de Nautilus en computación verificable fuera de la cadena como ejemplos de "cómo Sui podría servir como base para la próxima ola de sistemas inteligentes y descentralizados".

La asociación con Google Cloud profundiza la integración a través del acceso a BigQuery para datos de la blockchain Sui para análisis, el entrenamiento de Vertex AI en el lenguaje de programación Move para el desarrollo asistido por IA, el soporte de zkLogin utilizando credenciales OAuth (Google) para un acceso simplificado e infraestructura que respalda el rendimiento y la escalabilidad de la red. La integración de ChainIDE de Alibaba Cloud permite indicaciones en lenguaje natural para la generación de código Move: los desarrolladores escriben "crear un contrato de staking con un 10% de APY" en inglés, chino o coreano, recibiendo código Move sintácticamente correcto, documentado y con verificaciones de seguridad. Este desarrollo asistido por IA democratiza la construcción de blockchains al tiempo que mantiene las garantías de seguridad de Move.

Las ventajas técnicas se acumulan para las aplicaciones de IA. Los modelos de propiedad de objetos se adaptan a agentes autónomos que operan de forma independiente. La ejecución paralela permite miles de operaciones de IA simultáneas sin interferencia. La finalidad en menos de un segundo admite experiencias de usuario interactivas. El almacenamiento de Walrus gestiona los conjuntos de datos de entrenamiento de forma económica. Las transacciones patrocinadas eliminan la fricción del gas para los usuarios. zkLogin elimina las barreras de las frases semilla. Los Bloques de Transacciones Programables orquestan flujos de trabajo complejos de forma atómica. Las opciones de verificación formal demuestran matemáticamente la corrección de los agentes de IA. Estas no son características desconectadas, sino capacidades integradas que forman un entorno de desarrollo coherente.

Comparando a los contendientes​

El pico de 297.000 TPS de Sui y la latencia de consenso de 390 ms superan los 11.3 TPS promedio y la finalidad de 12-13 minutos de Ethereum por órdenes de magnitud. Frente a Solana —su competidor más cercano en rendimiento—, Sui logra una finalidad 32 veces más rápida (0.4 segundos frente a 12.8 segundos) a pesar de los tiempos de slot de 400 ms de Solana, porque Solana requiere múltiples confirmaciones para la finalidad económica. La medición en el mundo real del informe de agosto de 2025 de Phoenix Group mostró a Sui procesando 3.900 TPS frente a los 92.1 TPS de Solana, lo que refleja el rendimiento operativo en lugar del teórico. Los costos de transacción se mantienen predeciblemente bajos en Sui (promedio de ~$0.0087, menos de un centavo) sin los problemas históricos de congestión e interrupciones de Solana.

Las diferencias arquitectónicas explican las brechas de rendimiento. El modelo centrado en objetos de Sui permite una paralelización inherente: 300.000 transferencias simples por segundo no requieren coordinación de consenso. Ethereum y Bitcoin procesan cada transacción secuencialmente a través de un consenso completo. Solana paraleliza a través de Sealevel, pero utiliza una ejecución optimista que requiere verificación retroactiva. Aptos, que también utiliza el lenguaje Move, implementa la ejecución optimista Block-STM en lugar del método de acceso al estado de Sui. Para aplicaciones de IA y robótica que requieren una latencia baja predecible, la declaración explícita de dependencias de Sui proporciona un determinismo que los enfoques optimistas no pueden garantizar.

El posicionamiento cuántico diverge aún más drásticamente. Bitcoin y Ethereum utilizan firmas ECDSA secp256k1 sin una ruta de actualización compatible con versiones anteriores; la transición cuántica requiere bifurcaciones duras, cambios de dirección, migraciones de activos y una gobernanza comunitaria que probablemente cause divisiones en la cadena. Solana comparte la ventaja EdDSA de Sui, lo que permite estrategias de transición zk-STARK similares e introduce firmas de un solo uso basadas en hash Winternitz Vault. Near y Cosmos también se benefician de EdDSA. Aptos utiliza Ed25519, pero tiene una hoja de ruta de preparación cuántica menos desarrollada. El trabajo de investigación de Chalkias de julio de 2025 afirmó explícitamente que los hallazgos "funcionan para Sui, Solana, Near, Cosmos y otras cadenas basadas en EdDSA, pero no para Bitcoin y Ethereum".

La madurez del ecosistema favorece temporalmente a los competidores. Solana se lanzó en 2020 con protocolos DeFi establecidos, mercados de NFT y comunidades de desarrolladores. El lanzamiento de Ethereum en 2015 proporcionó ventajas de primer movimiento en contratos inteligentes, adopción institucional y efectos de red. Sui se lanzó en mayo de 2023 —apenas dos años y medio de antigüedad— con más de $2 mil millones en TVL y 65.900 direcciones activas que crecen rápidamente, pero muy por debajo de los 16.1 millones de Solana. La superioridad técnica crea una oportunidad: los desarrolladores que construyen en Sui hoy se posicionan para el crecimiento del ecosistema en lugar de unirse a plataformas maduras y saturadas. La entrevista de Chalkias en London Real reflejó esta confianza: "Honestamente, no me sorprendería en absoluto si Mysten Labs, y todo lo que toca, supera lo que Apple es hoy".

Sinergias entre visiones aparentemente dispares​

Las narrativas de IA, robótica y resistencia cuántica parecen desconectadas hasta que se reconocen sus interdependencias técnicas. Los agentes de IA requieren baja latencia y alto rendimiento; Sui proporciona ambos. La coordinación robótica exige operaciones en tiempo real sin autoridad central; el modelo de objetos de Sui y la finalidad en menos de un segundo lo ofrecen. La seguridad post-cuántica necesita flexibilidad criptográfica y una arquitectura con visión de futuro; Sui la construyó desde el inicio. Estas no son líneas de productos separadas, sino requisitos técnicos unificados para el panorama tecnológico de 2030-2035.

Considere la fabricación autónoma: los sistemas de IA analizan las previsiones de demanda y la disponibilidad de materiales, determinando los programas de producción óptimos. Los agentes robóticos reciben instrucciones verificadas a través de la coordinación blockchain, asegurando la autenticidad sin control centralizado. Cada robot opera como un objeto propio que procesa tareas en paralelo, coordinándose a través de objetos compartidos cuando es necesario. Los micropagos se liquidan instantáneamente por los servicios prestados: el robot A proporciona materiales al robot B, el robot B procesa componentes para el robot C. El sistema funciona sin internet durante las interrupciones de conectividad, sincronizándose cuando se restablecen las redes. Y, lo que es fundamental, todas las comunicaciones permanecen seguras contra adversarios cuánticos a través de esquemas criptográficos post-cuánticos, protegiendo la propiedad intelectual y los datos operativos de ataques de "almacenar ahora, descifrar después".

La gestión de datos sanitarios ejemplifica otra convergencia. Los modelos de IA se entrenan con conjuntos de datos médicos almacenados en Walrus con pruebas criptográficas de disponibilidad. Las pruebas de conocimiento cero preservan la privacidad del paciente al tiempo que permiten la investigación. Los sistemas quirúrgicos robóticos se coordinan a través de la blockchain para las pistas de auditoría y la documentación de responsabilidad. El cifrado post-cuántico protege los registros médicos sensibles de amenazas a largo plazo. La capa de coordinación (la blockchain de Sui) permite el intercambio de datos institucionales sin confianza, la computación de IA sin comprometer la privacidad y una seguridad a prueba de futuro sin reemplazo periódico de la infraestructura.

La declaración de visión de Chalkias durante Sui Basecamp 2025 captura esta síntesis: posicionar a Sui como "fundamento para la próxima ola de sistemas inteligentes y descentralizados" con una "capacidad creciente para soportar aplicaciones nativas de IA y de computación intensiva". La arquitectura modular —Sui para la computación, Walrus para el almacenamiento, Scion para la conectividad, zkLogin para la identidad— crea lo que los miembros del equipo describen como un "sistema operativo de blockchain" en lugar de un libro mayor financiero estrecho. El modo sin internet, la criptografía cuántica segura y la finalidad en menos de un segundo no son listas de características, sino requisitos previos para sistemas autónomos que operan en entornos adversos con infraestructura poco fiable.

La metodología de innovación detrás del liderazgo técnico​

Comprender el enfoque de Mysten Labs explica la consistencia en la ejecución. Chalkias articuló la filosofía durante su publicación de blog "Build Beyond": "Mysten Labs es realmente bueno para encontrar nuevas teorías en el espacio que nadie ha implementado, donde algunas de las suposiciones pueden no ser precisas. Pero lo estamos uniendo con la tecnología existente que tenemos, y eventualmente, esto nos impulsa a crear un producto novedoso". Esto describe un proceso sistemático: identificar la investigación académica con potencial práctico, desafiar suposiciones no probadas a través del rigor de la ingeniería, integrar con sistemas de producción y validar a través de la implementación.

El protocolo de consenso Mysticeti ejemplifica esto. La investigación académica estableció tres rondas de mensajes como el mínimo teórico para la confirmación del consenso bizantino. Las implementaciones anteriores requerían 1.5 viajes de ida y vuelta con firmas de quórum por bloque. Mysten Labs diseñó estructuras DAG no certificadas que eliminan la certificación explícita, implementó reglas de confirmación óptimas a través de patrones DAG en lugar de mecanismos de votación, y demostró una reducción del 80% en la latencia con respecto al consenso Narwhal-Bullshark anterior. El resultado: un artículo revisado por pares con pruebas formales acompañado de una implementación de producción que procesa miles de millones de transacciones.

Una metodología similar se aplica a la criptografía. BPQS (el esquema de firma post-cuántica de blockchain de Chalkias) adapta las firmas basadas en hash XMSS para las restricciones de blockchain. Winterfell implementa el primer probador STARK de código abierto que utiliza solo funciones hash para la seguridad post-cuántica. zkLogin combina la autenticación OAuth con pruebas de conocimiento cero, eliminando partes confiables adicionales mientras preserva la privacidad. Cada innovación aborda una barrera práctica (seguridad post-cuántica, accesibilidad de pruebas ZK, fricción en la incorporación de usuarios) a través de una construcción criptográfica novedosa respaldada por un análisis formal.

La composición del equipo refuerza esta capacidad. Ingenieros de Meta construyeron autenticación para miles de millones, de la NASA desarrollaron sistemas distribuidos críticos para la seguridad, de Uber escalaron la coordinación en tiempo real a nivel global. Chalkias aporta experiencia criptográfica de Facebook/Diem, R3/Corda e investigación académica. Este no es un equipo de startup tradicional que aprende sobre la marcha, sino veteranos que ejecutan sistemas que han construido antes, ahora sin las limitaciones de las prioridades corporativas. La financiación de $336 millones de a16z, Coinbase Ventures y Binance Labs refleja la confianza de los inversores en la capacidad de ejecución sobre la tecnología especulativa.

Desafíos y consideraciones más allá del bombo​

La superioridad técnica no garantiza la adopción en el mercado, una lección aprendida repetidamente en la historia de la tecnología. Las 65.900 direcciones activas de Sui palidecen frente a los 16.1 millones de Solana a pesar de tener una tecnología posiblemente mejor. Los efectos de red se acumulan: los desarrolladores construyen donde los usuarios se congregan, los usuarios llegan donde existen aplicaciones, creando ventajas de bloqueo para las plataformas establecidas. La blockchain "más lenta y cara" de Ethereum acapara órdenes de magnitud más atención de los desarrolladores que las alternativas técnicamente superiores debido a su mera antigüedad.

El posicionamiento de "sistema operativo de blockchain" corre el riesgo de dilución: intentar sobresalir en finanzas, aplicaciones sociales, juegos, IA, robótica, IoT y almacenamiento descentralizado simultáneamente puede resultar en mediocridad en todos los dominios en lugar de excelencia en uno. Los críticos que señalan esta preocupación apuntan a una implementación limitada de robótica más allá de las pruebas de concepto, proyectos de IA principalmente en fase de especulación en lugar de utilidad de producción, y preparación de seguridad cuántica para amenazas a cinco o diez años de distancia. El contraargumento sostiene que los componentes modulares permiten un desarrollo enfocado: los equipos que construyen aplicaciones de IA utilizan la inferencia de Atoma y el almacenamiento de Walrus sin preocuparse por la integración robótica.

La criptografía post-cuántica introduce sobrecargas no triviales. Las firmas CRYSTALS-Dilithium miden 3.293 bytes en el nivel de seguridad 2 frente a los 64 bytes de Ed25519 —más de 50 veces más grandes. El ancho de banda de la red, los costos de almacenamiento y el tiempo de procesamiento aumentan proporcionalmente. Las mejoras en la verificación por lotes siguen siendo limitadas (aceleración del 20-50% frente a la verificación independiente) en comparación con el procesamiento por lotes eficiente de los esquemas clásicos. Los riesgos de migración incluyen errores del usuario durante la transición, coordinación entre los participantes del ecosistema (billeteras, dApps, exchanges), requisitos de compatibilidad con versiones anteriores y dificultad para realizar pruebas a escala sin computadoras cuánticas reales. La incertidumbre del cronograma agrava los desafíos de planificación: el progreso de la computación cuántica sigue siendo impredecible, los estándares del NIST continúan evolucionando y pueden surgir nuevos ataques criptoanalíticos contra los esquemas PQ.

El momento del mercado presenta quizás el mayor riesgo. Las ventajas de Sui se materializan de forma más dramática en el período 2030-2035: cuando las computadoras cuánticas amenacen la criptografía clásica, cuando proliferen los sistemas autónomos que requieran una coordinación sin confianza, cuando los agentes de IA gestionen un valor económico significativo que necesite una infraestructura segura. Si la adopción de blockchain se estanca antes de esta convergencia, el liderazgo técnico se vuelve irrelevante. Por el contrario, si la adopción explota antes, el ecosistema más nuevo de Sui puede carecer de aplicaciones y liquidez para atraer usuarios a pesar de un rendimiento superior. La tesis de inversión requiere creer no solo en la tecnología de Sui, sino en la alineación temporal entre la maduración de blockchain y la adopción de tecnologías emergentes.

La apuesta de una década por los primeros principios​

Que Kostas Chalkias llamara a su hijo Kryptos no es una anécdota encantadora, sino una señal de la profundidad de su compromiso. Su trayectoria profesional —desde la investigación en IA hasta la criptografía, desde la publicación académica hasta los sistemas de producción en Meta, desde la blockchain empresarial en R3 hasta la arquitectura de Capa 1 en Mysten Labs— demuestra un enfoque constante en las tecnologías fundamentales a escala. El trabajo de resistencia cuántica comenzó antes del anuncio de Willow de Google, cuando la criptografía post-cuántica parecía una preocupación teórica. La integración robótica comenzó antes de que los agentes de IA alcanzaran valoraciones de miles de millones de dólares. Las decisiones arquitectónicas que permiten estas capacidades son anteriores al reconocimiento del mercado de su importancia.

Esta orientación prospectiva contrasta con el desarrollo reactivo común en el mundo de las criptomonedas. Ethereum introduce rollups de Capa 2 para abordar los cuellos de botella de escalado que surgen después de la implementación. Solana implementa la comunicación QUIC y QoS ponderado por participación en respuesta a interrupciones y congestión de la red. Bitcoin debate aumentos del tamaño de bloque y la adopción de Lightning Network a medida que aumentan las tarifas de transacción. Sui diseñó la ejecución paralela, los modelos de datos centrados en objetos y la agilidad criptográfica antes de lanzar la red principal, abordando los requisitos anticipados en lugar de los problemas descubiertos.

La cultura de investigación refuerza este enfoque. Mysten Labs publica artículos académicos con pruebas formales antes de reclamar capacidades. El artículo sobre el consenso Mysticeti apareció en publicaciones revisadas por pares con pruebas de corrección y puntos de referencia de rendimiento. La investigación sobre la transición cuántica presentada en el Archivo ePrint de la IACR demuestra las ventajas de EdDSA a través de la construcción matemática, no de afirmaciones de marketing. El artículo sobre zkLogin (arXiv 2401.11735) detalla la autenticación de conocimiento cero antes de la implementación. Chalkias mantiene contribuciones activas en GitHub (kchalkias), publica información técnica en LinkedIn y Twitter, presenta en talleres PQCSA sobre amenazas cuánticas y se relaciona sustantivamente con la comunidad criptográfica en lugar de promocionar exclusivamente a Sui.

La validación definitiva llegará en 5-10 años, cuando las computadoras cuánticas maduren, los sistemas autónomos proliferen y los agentes de IA gestionen economías de billones de dólares. Si Sui ejecuta consistentemente su hoja de ruta —desplegando firmas post-cuánticas antes de la fecha límite del NIST de 2030, demostrando la coordinación robótica a escala y soportando capas de inferencia de IA que procesan millones de solicitudes— se convertirá en la capa de infraestructura para tecnologías que remodelarán la civilización. Si las computadoras cuánticas llegan más tarde de lo previsto, la adopción autónoma se estanca o los competidores adaptan con éxito soluciones, las inversiones tempranas de Sui pueden resultar prematuras. La apuesta se centra no en la capacidad tecnológica —Sui demuestra el rendimiento prometido— sino en el momento del mercado y la urgencia del problema.

La perspectiva de Chalkias durante la Conferencia Emergence lo enmarca sucintamente: "Eventualmente, la blockchain superará incluso a Visa en velocidad de transacción. Será la norma. No veo cómo podemos escapar de esto". La afirmación de inevitabilidad asume una dirección técnica correcta, una calidad de ejecución suficiente y una sincronización adecuada. Sui se posiciona para capitalizar si estas suposiciones se mantienen. La arquitectura centrada en objetos, la agilidad criptográfica, la finalidad en menos de un segundo y la metodología de investigación sistemática no son adaptaciones, sino elecciones fundamentales diseñadas para el panorama tecnológico que surgirá en la próxima década. Ya sea que Sui capture el liderazgo del mercado o que estas capacidades se conviertan en un requisito básico en todas las blockchains, Kostas Chalkias y Mysten Labs están diseñando la infraestructura para la inteligencia autónoma de la era cuántica, un primitivo criptográfico, un milisegundo de reducción de latencia, un robot de prueba de concepto a la vez.

En los mundos cada vez más convergentes de la inteligencia artificial y la blockchain, la demanda de confianza y transparencia nunca ha sido tan alta. ¿Cómo podemos estar seguros de que la salida de un modelo de IA es precisa y no ha sido manipulada? ¿Cómo podemos realizar cálculos complejos sobre enormes conjuntos de datos on‑chain sin comprometer la seguridad o la escalabilidad? Lagrange Labs está abordando estas preguntas de frente con su suite de infraestructura de conocimiento cero (ZK), con el objetivo de construir un futuro de “IA que puedes probar”. Este artículo ofrece una visión objetiva de su misión, tecnología y avances recientes, culminando con su último paper sobre zk‑SNARKs dinámicos.

1. El equipo y su misión​

Lagrange Labs está construyendo la infraestructura fundamental para generar pruebas criptográficas para cualquier inferencia de IA o aplicación on‑chain. Su objetivo es hacer que el cómputo sea verificable, aportando una nueva capa de confianza al mundo digital. Su ecosistema se sustenta en tres líneas de producto principales:

• Red de Provers ZK: Una red descentralizada de más de 85 nodos de prueba que suministra la potencia computacional necesaria para una amplia gama de tareas de prueba, desde IA y rollups hasta aplicaciones descentralizadas (dApps).
• DeepProve (zkML): Un sistema especializado para generar pruebas ZK de inferencias de redes neuronales. Lagrange afirma que es hasta 158 veces más rápido que las soluciones competidoras, haciendo que la IA verificable sea una realidad práctica.
• ZK Coprocessor 1.0: El primer coprocesador ZK basado en SQL, que permite a los desarrolladores ejecutar consultas personalizadas sobre enormes conjuntos de datos on‑chain y recibir resultados verificablemente precisos.

2. Una hoja de ruta hacia la IA verificable​

Lagrange ha estado ejecutando metódicamente una hoja de ruta diseñada para resolver los desafíos de la verificabilidad de la IA paso a paso.

• Q3 2024: Lanzamiento del ZK Coprocessor 1.0: Esta versión introdujo circuitos recursivos hiper‑paralelos, que entregaron un aumento de velocidad promedio de aproximadamente 2×. Proyectos como Azuki y Gearbox ya están aprovechando el coprocesador para sus necesidades de datos on‑chain.
• Q1 2025: Presentación de DeepProve: Lagrange anunció DeepProve, su solución para Machine Learning de Conocimiento Cero (zkML). Soporta arquitecturas de redes neuronales populares como Perceptrones Multicapa (MLP) y Redes Neuronales Convolucionales (CNN). El sistema logra una aceleración significativa, de orden de magnitud, en las tres etapas críticas: configuración única, generación de pruebas y verificación, con mejoras de velocidad de hasta 158×.
• Q2 2025: Paper sobre zk‑SNARKs dinámicos (último hito): Este paper introduce un algoritmo de “actualización” revolucionario. En lugar de regenerar una prueba desde cero cada vez que los datos o el cómputo subyacente cambian, este método puede parchear una prueba antigua (π) en una nueva prueba (π′). Esta actualización se puede realizar con una complejidad de solo O(√n log³n), una mejora dramática respecto a la recomputación completa. Esta innovación es particularmente adecuada para sistemas dinámicos como modelos de IA que aprenden continuamente, lógica de juegos en tiempo real y contratos inteligentes en evolución.

3. Por qué los zk‑SNARKs dinámicos son importantes​

La introducción de pruebas actualizables representa un cambio fundamental en el modelo de costos de la tecnología de conocimiento cero.

• Un nuevo paradigma de costos: La industria pasa de un modelo de “recomputación total para cada prueba” a “pruebas incrementales basadas en el tamaño del cambio”. Esto reduce drásticamente el costo computacional y financiero para aplicaciones que sufren actualizaciones frecuentes y menores.
• Implicaciones para la IA:
  • Ajuste fino continuo: Cuando se ajusta menos del 1 % de los parámetros de un modelo, el tiempo de generación de la prueba crece casi linealmente con el número de parámetros cambiados (Δ parámetros), en lugar de con el tamaño total del modelo.
  • Inferencia en streaming: Esto permite generar pruebas concurrentemente con el propio proceso de inferencia. Reduce drásticamente la latencia entre que una IA toma una decisión y que esa decisión sea asentada y verificada on‑chain, abriendo casos de uso como servicios de IA on‑chain y pruebas comprimidas para rollups.
• Implicaciones para aplicaciones on‑chain:
  • Los zk‑SNARKs dinámicos ofrecen enormes optimizaciones de gas y tiempo para aplicaciones caracterizadas por cambios de estado frecuentes y pequeños. Esto incluye libros de órdenes de exchanges descentralizados (DEX), estados de juegos en evolución y actualizaciones de libros contables con adiciones o eliminaciones frecuentes.

4. Un vistazo al stack tecnológico​

La poderosa infraestructura de Lagrange se construye sobre un stack tecnológico sofisticado e integrado:

• Diseño de circuitos: El sistema es flexible, soportando la incorporación de modelos ONNX (Open Neural Network Exchange), parsers SQL y operadores personalizados directamente en sus circuitos.
• Recursión y paralelismo: La Red de Provers ZK facilita pruebas recursivas distribuidas, mientras que el ZK Coprocessor aprovecha el sharding de “micro‑circuitos” para ejecutar tareas en paralelo, maximizando la eficiencia.
• Incentivos económicos: Lagrange está planificando lanzar un token nativo, LA, que se integrará en un sistema Double‑Auction‑for‑Recursive‑Auction (DARA). Esto creará un mercado robusto para pujar por el cómputo de los probadores, con incentivos y penalizaciones que aseguren la integridad de la red.

5. Ecosistema y adopción en el mundo real​

Lagrange no está construyendo en un vacío; su tecnología ya está siendo integrada por un número creciente de proyectos en distintos sectores:

• IA y ML: Proyectos como 0G Labs y Story Protocol están usando DeepProve para verificar los resultados de sus modelos de IA, garantizando procedencia y confianza.
• Rollups e infraestructura: Jugadores clave como EigenLayer, Base y Arbitrum participan en la Red de Provers ZK como nodos de validación o socios de integración, contribuyendo a su seguridad y potencia computacional.
• Aplicaciones NFT y DeFi: Marcas como Azuki y protocolos DeFi como Gearbox están utilizando el ZK Coprocessor para mejorar la credibilidad de sus consultas de datos y mecanismos de distribución de recompensas.

6. Desafíos y el camino por delante​

A pesar de su impresionante progreso, Lagrange Labs y el campo más amplio de ZK enfrentan varios obstáculos:

• Cuellos de botella de hardware: Incluso con una red distribuida, los SNARKs actualizables siguen demandando gran ancho de banda y dependen de curvas criptográficas amigables con GPU para operar eficientemente.
• Falta de estandarización: El proceso de mapear frameworks de IA como ONNX y PyTorch a circuitos ZK aún carece de una interfaz universal y estandarizada, creando fricción para los desarrolladores.
• Un panorama competitivo: La carrera por construir zkVMs y plataformas zkCompute generalizadas se está intensificando. Competidores como Risc‑Zero y Succinct también están logrando avances significativos. El ganador final podría ser quien sea el primero en comercializar una cadena de herramientas amigable para desarrolladores y impulsada por la comunidad.

7. Conclusión​

Lagrange Labs está remodelando metódicamente la intersección de IA y blockchain a través del lente de la verificabilidad. Su enfoque ofrece una solución integral:

• DeepProve aborda el desafío de la inferencia confiable.
• El ZK Coprocessor resuelve el problema de los datos confiables.
• Los zk‑SNARKs dinámicos incorporan la necesidad del mundo real de actualizaciones continuas directamente en el sistema de pruebas.

Si Lagrange puede mantener su ventaja de rendimiento, resolver el desafío crítico de la estandarización y seguir ampliando su robusta red, estará bien posicionada para convertirse en un jugador fundamental en el emergente sector de “IA + Infraestructura ZK”.

Arquitectura técnica y características (Perspectiva del 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 multipartita. En términos simples, el proceso de firma siempre involucra a dos partes: (1) el usuario y (2) la red Ika. El usuario conserva una participación de la clave privada y la red – compuesta por muchos nodos independientes – posee la otra participación. 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 una MPC distribuida 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 participación de la firma de la red. Esta estructura de MPC anidada (usuario + red) hace que Ika sea no colusoria: incluso si todos los nodos de Ika coluden, no pueden robar los activos del usuario porque la participación del usuario (su parte de la clave) siempre es requerida criptográficamente. En otras palabras, Ika permite una seguridad de "cero confianza", manteniendo 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 (manteniendo una participación 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, una bifurcación (fork) 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 smart contracts desactivados (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 (broadcast) confiable entre los nodos, reemplazando la compleja malla de mensajes peer-to-peer 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 (batching) y agregación para mantener los costos por nodo casi constantes incluso cuando N crece significativamente. Esto representa un avance importante en la criptografía de umbral: el equipo de Ika reemplazó la comunicación "unicast" punto a punto por una difusión y agregación eficientes, permitiendo que el protocolo soporte cientos o miles de participantes sin ralentizarse.

Integraciones de conocimiento cero: En la actualidad, la seguridad de Ika se logra a través de la criptografía de umbral y el consenso BFT en lugar de pruebas de conocimiento cero explícitas. El sistema no depende de zk-SNARKs o zk-STARKs en su proceso de firma principal. Sin embargo, Ika utiliza pruebas de estado on-chain (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 cabeceras de bloques 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 "cero confianza" (lo que significa que no hay supuestos de confianza) a través del esquema 2PC-MPC, en lugar de sistemas de pruebas de conocimiento cero.

Rendimiento y escalabilidad​

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

Igualmente importante es que Ika logra esto mientras escala el número de firmantes para mejorar la descentralización. Las configuraciones de MPC tradicionales a menudo usaban un comité fijo de quizás 10 a 20 nodos para evitar el colapso del rendimiento. La arquitectura de Ika puede expandirse a cientos o incluso miles de validadores que participan 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 dada, solo un umbral t-de-N de nodos (por ejemplo, el 67% de N) necesita participar activamente; 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 falla típicos con elegancia (similar a las propiedades de vitalidad 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 la diferencia 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 fácil de usar para los desarrolladores, especialmente para aquellos que ya están construyendo sobre Sui. Los desarrolladores no escriben smart contracts 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 en 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 Node.js) que refleja el estilo del SDK de Sui. Este SDK permite a los constructores crear y gestionar dWallets (carteras descentralizadas) y emitir solicitudes de firma a Ika desde sus aplicaciones. Usando el SDK de TS, los desarrolladores pueden generar pares de claves, registrar participaciones de 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, haciendo que sea 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 Ika local o incluso una red de prueba local bifurcando el repositorio de código abierto. Esto es valioso para las pruebas y la 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 red de prueba) 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 participación de la clave del usuario para su custodia y cómo iniciar transacciones entre cadenas. El código de ejemplo cubre casos de uso como la transferencia de BTC a través de una llamada a un smart contract de Sui, o la programación de transacciones futuras (una característica que Ika soporta mediante la cual una transacción puede ser prefirmada bajo ciertas condiciones).

• Integración con Sui (Clientes Ligeros): De serie, Ika está estrechamente integrada con la blockchain Sui. La red Ika ejecuta un cliente ligero de Sui internamente para leer datos on-chain de Sui de forma sin confianza. Esto significa que un smart contract de Sui puede emitir un evento o una llamada que Ika reconocerá (a través de una prueba de estado) como un activador para realizar una acción. Por ejemplo, un contrato de Sui podría instruir a Ika: "cuando ocurra el evento X, firma y difunde una transacción en Ethereum". Los nodos de Ika verificarán el evento de Sui usando la prueba de 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 relayer off-chain 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 multicadena 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 la extensión de Ika para trabajar con rollups en el ecosistema Avail de Polygon (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 virtualmente cualquier esquema de firma de blockchain. Inicialmente soporta ECDSA (el algoritmo de curva elíptica utilizado por Bitcoin, cuentas ECDSA de Ethereum, BNB Chain, etc.). A corto plazo, está previsto soportar 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 cartera, 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 entre cadenas sea "plug-and-play" para los constructores.

Seguridad, descentralización y tolerancia a fallos​

La seguridad es fundamental en el diseño de Ika. El modelo de cero confianza 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 (por ejemplo, una dirección BTC gestionada por Ika), la clave privada de esa dirección nunca la posee ninguna parte individual – ni siquiera el usuario solo. En su lugar, el usuario posee una participación secreta y la red colectivamente posee la otra participación. Ambas son necesarias para firmar cualquier transacción. Por lo tanto, incluso si ocurriera el peor de los casos (por ejemplo, muchos nodos de Ika fueran comprometidos por un atacante), ellos aún no podrían mover fondos sin la participación de la clave secreta del usuario. Esta propiedad aborda un riesgo importante en los puentes convencionales, donde un quórum de validadores podría coludir para robar activos bloqueados. Ika elimina ese riesgo al cambiar fundamentalmente la estructura de acceso (el umbral se establece de tal manera que la red 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 sigue siendo 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 holders del token 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 participación de firma incorrecta o censurar transacciones), el consenso y el protocolo MPC lo detectarán – las participaciones de firma incorrectas pueden identificarse (no se combinarán en una firma válida), y un nodo malicioso puede registrarse y potencialmente ser castigado (slashing) o eliminado en futuras épocas. Mientras tanto, la vitalidad se mantiene siempre que participen suficientes nodos (>67%); el consenso puede continuar finalizando operaciones incluso si muchos nodos fallan o se desconectan inesperadamente. Esta tolerancia a fallos garantiza que el servicio sea robusto – no existe un punto único de falla, ya que participan cientos de operadores independientes en diferentes jurisdicciones. La descentralización se refuerza aún más por el gran número de participantes: Ika no se limita a un comité pequeño y 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 exhaustivo en 2024 detallando el protocolo 2PC-MPC, y han pasado al menos por 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 (garantizando que no haya fallos en el esquema ECDSA de umbral, la generación de claves o la agregación de participaciones) y en comprobar 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. A partir de la etapa de testnet alfa, el equipo también advirtió que el software aún era experimental y no había sido auditado para producción, pero las auditorías continuas y las mejoras de seguridad eran una prioridad máxima 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 los esquemas de umbral) y descentralización de grado blockchain (del consenso PoS y el gran conjunto de validadores), revisada por expertos, para proporcionar fuertes garantías contra atacantes externos y colusiones internas.

Compatibilidad e interoperabilidad del ecosistema​

Ika está diseñada 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 Sui: actúa efectivamente como un módulo adicional de Sui, potenciando a las dApps de Sui con capacidades multicadena. Esta alineación estrecha es intencionada – los contratos Move de Sui y su modelo centrado en objetos la convierten en un buen "controlador" para las dWallets de Ika. Por ejemplo, una aplicación DeFi de Sui puede usar Ika para obtener liquidez de Ethereum o Bitcoin sobre la marcha, convirtiendo a Sui en un centro para la liquidez multicadena. 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 desarrollador de Sui podría crear un contrato Move que, por ejemplo, acepte depósitos de BTC: entre bastidores, 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 simplemente otro activo gestionado dentro de la aplicación de Sui, a pesar de que el BTC permanece nativo en Bitcoin hasta que una transacción válida firmada por umbral lo mueva.

Más allá de Sui, la arquitectura de Ika soporta otras blockchains de Capa-1, Capa-2 e incluso sistemas off-chain. 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 smart contracts en esas cadenas (o sus usuarios) también aprovechen la red MPC de Ika. Si bien tales capacidades podrían desplegarse gradualmente, el objetivo del diseño es ser agnóstico de la cadena. Mientras tanto, incluso sin una integración profunda on-chain, Ika puede usarse de una manera más manual: por ejemplo, una aplicación en Ethereum podría llamar a una API de Ika (vía un oráculo o servicio off-chain) para solicitar una firma para una transacción o un 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 PKP de Lit Protocol (analizaremos Lit más adelante). Ika también ha mostrado casos de uso como el control de Bitcoin en rollups – un ejemplo es la integración con el marco Avail de Polygon para permitir que los usuarios de rollups gestionen 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 realizar operaciones seguras entre cadenas. Al soportar estándares criptográficos comunes (ECDSA, Ed25519, Schnorr) y proporcionar las verificaciones necesarias de clientes ligeros, Ika podría convertirse en una especie de red de "MPC-as-a-service" para toda la Web3, uniendo activos y acciones de una manera minimizada en confianza.

El CTO y cofundador de Ika es Yehonatan Cohen Scaly, un experto en criptografía que fue coautor del protocolo 2PC-MPC. Yehonatan lidera la I + D de los novedosos algoritmos criptográficos de Ika y anteriormente trabajó 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 fáciles de usar 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 (vicepresidente de investigación en dWallet Labs) — ancla el liderazgo de Ika. Colectivamente, las credenciales del equipo incluyen startups anteriores, contribuciones de investigación académica y experiencia en la intersección de las criptomonedas, la seguridad y la tecnología blockchain. Esta profundidad es la razón por la que se describe a Ika como creada por "algunos de los expertos en criptografía líderes en el mundo".

Además de los fundadores, el equipo ampliado 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 e instrumental en el diseño del protocolo. La presencia de tal talento da a los inversores la confianza de que la compleja tecnología de Ika está en manos capaces. Además, contar con 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 talento para la contratación de desarrolladores e investigadores.

Rondas de Financiación y Respaldos Clave​

Ika (y su matriz, dWallet Labs) ha atraído una financiación de riesgo significativa e inversión estratégica desde su creación. Hasta la fecha, ha recaudado más de **$21 millones** en múltiples rondas. La **ronda semilla inicial del proyecto en agosto de 2022** fue de$ 5 millones, lo cual fue notable dadas las condiciones del mercado bajista en ese momento. Esa ronda semilla incluyó una amplia gama de conocidos inversores de criptomonedas y ángeles. Entre los participantes destacados se encuentran 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 destacados inversores individuales, como Naval Ravikant (cofundador de AngelList y destacado inversor tecnológico), Marc Bhargava (cofundador de Tagomi), Rene Reinsberg (cofundador de Celo) y varias otras figuras de la industria. Tal lista de patrocinadores subrayó la fuerte confianza en el enfoque de Ika hacia la custodia descentralizada, incluso en la etapa de idea.

En mayo de 2023, Ika recaudó adicionales ~ $7.5 millones en lo que parece ser una **Serie A o ronda estratégica**, supuestamente con una valoración cercana a los$ 250 millones. 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 $ 250 millones para una red en etapa relativamente temprana reflejaba la expectativa del mercado de que Ika pudiera convertirse en una infraestructura fundamental en la Web3 (a la par de 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 Sui Foundation anunció una inversión estratégica en Ika. Esta asociación con el fondo del ecosistema de Sui impulsó la financiación total de Ika por encima de los $21 millones y cimentó una estrecha alineación con la blockchain Sui. Aunque el monto exacto que invirtió la Sui Foundation no fue revelado públicamente, está claro que se trató de un respaldo significativo, probablemente del orden de varios millones de USD. El apoyo de la Sui Foundation no es solo financiero; también significa que Ika recibe una sólida asistencia para salir al mercado dentro del ecosistema 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 Sui Foundation, 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, resalta que Sui ve a Ika como una infraestructura crítica para el futuro de su blockchain (similar a cómo la Ethereum Foundation podría respaldar directamente un proyecto de Capa 2 o de interoperabilidad que beneficie a Ethereum).

Además de Sui, otros patrocinadores que vale la pena mencionar son Node Capital (un fondo de criptomonedas con sede en China conocido por sus inversiones tempranas en infraestructura), Lemniscap (un VC de criptomonedas centrado en la innovación de protocolos en etapa temprana) y Collider Ventures (VC con sede en Israel, que probablemente brinda apoyo local). El hecho de que Blockchange Ventures liderara la ronda de 2023 es notable; Blockchange es un VC que ha respaldado varios proyectos de infraestructura criptográfica y su liderazgo sugiere que vieron la tecnología de Ika con potencial para definir una categoría. Además, Digital Currency Group (DCG) y Node Capital lideraron una recaudación de fondos de $ 5 millones para dWallet Labs antes del cambio de marca a Ika (según una publicación de LinkedIn de Omer); 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 Sui Foundation destaca especialmente, 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 preferida para la gestión de claves descentralizada y el bridging a través de muchas redes, y han valorado el proyecto en consecuencia.

Tokenómica y Modelo Económico​

Ika tendrá un token de utilidad nativo llamado $IKA, el cual es central para la economía de la red y el modelo de seguridad. De manera única, el token IKA se lanza en la blockchain Sui (como un activo nativo de SUI), a pesar de que la red Ika en sí misma es una cadena separada. Esto significa que IKA existirá como una moneda que se puede poseer 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 tokenómica se puede resumir 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 al ejecutar el protocolo de firma de umbral. El documento técnico establece una analogía entre el papel de IKA y el gas de Sui, confirmando que todas las transacciones cross-chain facilitadas por Ika incurrirán en una pequeña tarifa de IKA. El cronograma de tarifas es probablemente proporcional a la complejidad de la operación (por ejemplo, una sola firma podría costar una tarifa base, mientras que flujos de trabajo de múltiples pasos más complejos podrían costar más).

• Staking y Seguridad: IKA es también un token de staking. A los nodos validadores en la red Ika se les debe delegar una participación de IKA para participar en el consenso y la firma. El consenso sigue un Proof-of-Stake delegado similar al de Sui: los holders de tokens delegan IKA a los validadores, y el peso de cada validador en el consenso (y, por tanto, en los procesos de firma de umbral) se determina por la participación (stake). En cada época (epoch), se eligen los validadores y su poder de voto es una función de la participación, siendo el conjunto global tolerante a fallas bizantinas (lo que significa que si un conjunto de validadores tiene una participación total $X$, hasta ~ $X / 3$ de la participación podría ser maliciosa sin romper las garantías de la red). Los stakers (delegadores) son incentivados mediante 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 parte con sus delegadores como recompensas. Esto refleja el modelo de Sui de recompensar a los proveedores de servicios por el rendimiento (throughput).

• Suministro y Distribución: Hasta ahora (segundo trimestre de 2025), los detalles sobre el suministro total de IKA, la distribución inicial y la inflación no son totalmente públicos. Sin embargo, dadas las rondas de financiación, podemos inferir cierta estructura. Probablemente, una parte de IKA se asigna a los inversores iniciales (rondas semilla y serie) y al equipo, con una gran parte reservada para la comunidad y futuros incentivos. Es posible que haya una venta comunitaria o un airdrop planeado, especialmente porque Ika llevó a cabo una notable campaña de NFT que recaudó 1.4 millones de SUI, como se menciona 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 temprano). 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.

• Cronograma de Lanzamiento del Token: El anuncio de la Sui Foundation de octubre de 2024 indicó que "El token IKA se lanzará de forma nativa en Sui, desbloqueando nueva funcionalidad y utilidad en la seguridad descentralizada". La red principal (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 su distribución a finales de 2024 o principios de 2025. El token comenzaría entonces a usarse para gas en la red Ika y para staking. Antes de eso, en la red de prueba (testnet), se utilizó un token temporal (DWLT en testnet) para el gas, el cual 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 fluyen más transacciones cross-chain 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 el circulante). Por lo tanto, IKA tiene una naturaleza de utilidad más gobernanza: utilidad al pagar por servicios y staking, y probablemente gobernanza al dirigir el futuro del protocolo (aunque la gobernanza aún no se menciona explícitamente, es común que tales redes eventualmente descentralicen el control a través de la votación con tokens). Se puede imaginar a los holders de tokens IKA votando sobre la adición de soporte para nuevas cadenas, el ajuste de parámetros de tarifas u otras actualizaciones del protocolo en el futuro.

En general, la tokenómica de IKA tiene como objetivo equilibrar la seguridad de la red con la usabilidad. Al lanzarse en Sui, facilitan que los usuarios del ecosistema Sui obtengan y usen IKA (sin necesidad de una incorporación a una cadena separada para el token en sí), lo que puede acelerar la adopción. Los inversores observarán métricas como la porción del suministro en staking (que indica seguridad), los ingresos por tarifas (que indican uso) y las asociaciones que impulsan las transacciones (que indican 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 de cara 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 al mantener 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): Desde el principio, 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 reciente, 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, el GTM de Ika se apoya en el crecimiento del 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 dentro del juego que residan en múltiples cadenas; Covault probablemente involucra soluciones de custodia, etc. Al asegurar estas asociaciones temprano, Ika garantiza que tras 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 los comunicados de prensa, destacan una "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 (tal vez 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 propia. 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 seguridad para agentes de IA" (AI Agent guardrails) como un caso de uso. Esto es con visión de futuro, aprovechando la tendencia de la autonomía de la IA (por ejemplo, agentes de IA ejecutando en blockchain). Ika puede asegurar que un agente de IA (por ejemplo, un agente económico autónomo al que se le da el control de algunos fondos) no pueda escapar 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 rieles 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 insinúa un enfoque también en Asia, 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.4 millones de 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 Ika no tiene permisos (permissionless), 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 beneficios al operar algunos de los validadores desde el principio (fase de arranque) y así recaudar parte de las tarifas.

en resumen, el GTM de Ika está fuertemente ligado 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 cabalgar sobre el crecimiento de esa L1. Simultáneamente, se posiciona como una solución generalizada para la coordinación multi-cadena, que luego puede presentarse a proyectos en otras cadenas una vez que se demuestre el éxito en Sui. El respaldo de la Sui Foundation 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 temprana, Ika ha construido una impresionante lista de compromisos en el ecosistema:

• Adopción en el 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" (Impulsado por Ika); por ejemplo, un protocolo de préstamos de Sui que permita a los usuarios depositar BTC, o una DAO en Sui que use 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 Sui Foundation, que es tanto inversor como 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 maneje la autenticación del usuario e Ika maneje las transacciones cross-chain, proporcionando juntos una UX fluida. Además, la mención de Avail (Polygon) en sus blogs sugiere una asociación o piloto en ese ecosistema: tal vez con Polygon Labs o equipos que construyen rollups en Avail para usar Ika para llevar Bitcoin a esos rollups. Otro dominio potencial de asociación es con los custodios; por ejemplo, integrando Ika con proveedores de billeteras como Zengo (notable dado 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 ámbitos; se podría imaginar a Fireblocks aprovechando a Ika para MPC en Sui).

• Compromiso con la Comunidad y los Desarrolladores: Ika gestiona un Discord y probablemente 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 impulso para que los desarrolladores se sientan cómodos con el concepto de dWallets. Cuanto más comprendan los desarrolladores 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 (Roadmap): A partir de 2025, la hoja de ruta de Ika incluyó:

  • Alpha y Testnet (2023–2024): La red de prueba alpha se lanzó en 2024 en Sui, permitiendo a los desarrolladores experimentar con dWallets y proporcionar comentarios. Esta etapa se utilizó para refinar el protocolo, corregir errores y realizar auditorías internas.
  • Lanzamiento de Mainnet (Dic 2024): Ika planeó entrar en funcionamiento en la red principal 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) de entrada, dado que fueron muy mencionadas 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, cliente ligero de Solana, etc.) para ampliar el control sin confianza (trustless). Otro elemento de la hoja de ruta es probablemente la expansión de validadores sin permisos, alentando a más validadores independientes a unirse y descentralizar la red aún más. Dado que el código es una bifurcación de Sui, ejecutar un validador de Ika es similar a ejecutar un nodo de Sui, algo que muchos operadores pueden hacer.
  • Mejoras de Funcionalidad: Dos características interesantes insinuadas en los blogs son las Participaciones de Usuario Encriptadas (Encrypted User Shares) y la Firma de Transacciones Futuras (Future Transaction signing). Las participaciones de usuario encriptadas significan que los usuarios pueden opcionalmente encriptar su participación privada y almacenarla on-chain (tal vez en Ika o en otro lugar) de manera que solo ellos puedan desencriptarla, simplificando la recuperación. La firma de transacciones futuras implica la capacidad de que Ika firme previamente una transacción que se ejecute más tarde cuando se cumplan ciertas condiciones. Estas características aumentan la usabilidad (los usuarios no tendrán que estar en línea para cada acción si aprueban previamente cierta lógica, todo mientras mantienen la seguridad no custodia). Entregar estas funciones en 2025 diferenciaría aún más la oferta de Ika.
  • Crecimiento del Ecosistema: Para finales de 2025, Ika probablemente aspire 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 on-chain aún no existe) o colaboraciones con proyectos intercadena como Wormhole o LayerZero, donde Ika podría servir como el mecanismo de firma para la mensajería segura.

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

Análisis Competitivo: Ika vs. Otras Redes MPC / Threshold​

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

Aspecto	Ika (Red MPC Paralela)	Lit Protocol (PKI y Computación)	Threshold Network (tBTC y TSS)	Zama (Red FHE)
Lanzamiento y Estado	Fundada en 2022; Testnet en 2024; Mainnet lanzada en Sui en diciembre de 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 escalabilidad.	La red entró en funcionamiento en 2022 tras la fusión de Keep / NuCypher. El token $T gobierna la DAO. Lanzamiento de tBTC v2 para el puente de Bitcoin.	En desarrollo (aún no hay red pública a partir de 2025). Recaudó grandes rondas de capital de riesgo para I + D. Sin token aún (herramientas FHE en etapa alfa).
Enfoque Principal / Caso de Uso	Interoperabilidad cross-chain y custodia: firma de umbral (threshold signing) para controlar activos nativos a través de cadenas (p. ej., BTC, ETH) mediante dWallets. Permite DeFi, dApps multicadena, etc.	Gestión de claves descentralizada y控制 de acceso: cifrado / descifrado de umbral y firma condicional a través de PKP (Programmable Key Pairs). Popular para el acceso restringido a contenidos y automatización cross-chain con “Lit Actions” de JavaScript.	Servicios de criptografía de umbral: p. ej., el puente descentralizado Bitcoin-a-Ethereum tBTC; ECDSA de umbral para la custodia de activos digitales; re-cifrado de proxy de umbral (PRE) para la privacidad de datos.	Computación que preserva la privacidad: Cifrado Completamente Homomórfico (FHE) para permitir el procesamiento de datos cifrados y contratos inteligentes privados. Enfoque en la confidencialidad (p. ej., DeFi privado, ML on-chain) en lugar del control cross-chain.
Arquitectura	Fork de la blockchain Sui (consenso DAG Mysticeti) modificado para MPC. Sin contratos inteligentes de usuario en Ika; utiliza el protocolo 2PC-MPC off-chain entre ~N validadores + participación del usuario. Diseño de alto rendimiento (10k TPS).	Red descentralizada + L2: los nodos de Lit ejecutan MPC y también un entorno de ejecución JS basado en TEE. Se utiliza el Rollup de Arbitrum “Chronicle” para anclar el estado y coordinar los nodos. Utiliza un umbral de 2/3 para el consenso en las operaciones clave.	Red descentralizada en Ethereum: los operadores de nodos realizan staking con $T y son seleccionados aleatoriamente en grupos de firma (p. ej., 100 nodos para tBTC). Utiliza protocolos off-chain (GG18, etc.) con contratos de Ethereum on-chain para la coordinación y el manejo de depósitos.	Kits de herramientas FHE sobre cadenas existentes: la tecnología de Zama (p. ej., Concrete, bibliotecas TFHE) permite FHE en Ethereum (fhEVM). Planes para un sistema de gestión de claves de umbral (TKMS) para claves FHE. Probablemente se integrará con L1 o funcionará como Layer-2 para computaciones privadas.
Modelo de Seguridad	2PC-MPC, sin colusión: se requiere la participación de la clave del usuario + el umbral de N validadores (2/3 BFT) para cualquier firma. Ninguna entidad individual tiene nunca la clave completa. El consenso BFT tolera <33% de actores maliciosos. Auditado por Symbolic (2024).	Umbral + TEE: requiere que 2/3 de los nodos de Lit firmen / descifren. Utiliza Entornos de Ejecución Segura (TEE) en cada nodo para ejecutar el 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.	Multipartidista de umbral: p. ej., para tBTC, un grupo seleccionado aleatoriamente de ~100 nodos debe alcanzar un umbral (p. 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 (learning with errors, 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; seguridad bajo revisión académica.
Rendimiento	Latencia inferior al 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 en 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). Chronicle L2 ayuda al 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; está bien para transacciones de puente y control de acceso, no está diseñado para miles de TPS.	Latencia de computación pesada: FHE es actualmente mucho más lento que la computación en texto plano (varios ó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 computaciones complejas donde la privacidad es primordial.
Descentralización	Alta: conjunto de validadores sin permisos, posibilidad de cientos de validadores. El PoS delegado (estilo Sui) garantiza una participación abierta y una gobernanza descentralizada a lo largo del tiempo. El usuario siempre está en el bucle (no puede ser ignorado).	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. Gobernanza aún no totalmente descentralizada (existe Lit DAO pero es incipiente).	Alta: gran grupo de stakers; sin embargo, la firma real se realiza por grupos seleccionados (no por toda la red a la vez). La red es tan descentralizada como su distribución de stake. Gobernada por Threshold DAO (votos de los titulares de tokens); descentralización madura en la gobernanza.	N/A (para la red): Zama es actualmente un proyecto impulsado por la empresa. Si se lanza fhEVM o redes, inicialmente probablemente 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 operar validadores; el token se revaloriza con el uso de la red. El respaldo de la Fundación Sui le otorga valor al ecosistema.	Token **$LIT**: utilizado para gobernanza y quizás tarifas por servicios avanzados. Las Lit Actions son actualmente gratuitas para los desarrolladores (sin gas); a largo plazo podría introducirse un modelo de tarifas.$LIT incentiva la operación de nodos (stakers), pero la economía exacta del token está evolucionando.	Token **$T**: staked por los nodos, 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 utiliza en programas de liquidez para la adopción de tBTC.	Sin token (aún): Zama está financiada por capital de riesgo; podría introducir un token si lanzan un servicio de red (podría usarse para pagar por computación privada o staking para asegurar redes que ejecutan contratos FHE). Actualmente, los desarrolladores usan las herramientas de Zama sin un token.
Principales Respaldos	Fundació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 comunidad de desarrolladores creciente a través de Lit DAO. Asociaciones con Ceramic, proyectos NFT para control de acceso.	Surgió de las comunidades de Keep y NuCypher (respaldadas por a16z, Polychain en el pasado). Threshold es operado por la DAO; sin nueva financiación de VC post-fusión (subvenciones del Ethereum Community Fund, etc.). Asociaciones: trabaja con Curve, Aave (integraciones de tBTC).	Respaldado por a16z, SoftBank, Multicoin Capital (recaudó $73M en Serie A). Vínculos 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 residen 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 juegos) con los que la red de Lit tendría dificultades. Ika tampoco depende de Entornos de Ejecución Segura (TEE), de los cuales algunos desarrolladores desconfían (debido a posibles vulnerabilidades en SGX); en su lugar, Ika logra la ausencia 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 de forma inmediata. Además, el modelo de usuario en el bucle de Ika significa que no requiere sobrecolateralización o seguros 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 apunta a la privacidad, mientras que Ika apunta a la interoperabilidad. Sin embargo, es concebible que en el futuro ambos puedan complementarse (p. ej., utilizando FHE en activos almacenados en Ika). Por ahora, Ika tiene la ventaja de estar operativa antes en un nicho con demanda inmediata (los puentes y las redes MPC son necesarios hoy en día, 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 realizar 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 demostrar la validez de 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 / artículos académicos le otorgan credibilidad.

En conclusión, Ika 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 adopción amplia, podría volverse tan integral para la infraestructura Web3 como los protocolos de mensajería cross-chain o las propias blockchains de Capa 1 principales. El próximo año (2025) será crítico a medida que la mainnet de Ika y los primeros casos de uso entren en funcionamiento, demostrando si esta criptografía de vanguardia puede cumplir sus promesas en condiciones reales de mercado. Las señales tempranas — fundamentos técnicos sólidos, una red activa de integraciones y un apoyo sustancial de los inversores — sugieren que Ika tiene una oportunidad real de redefinir la interoperabilidad 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 la competencia para contexto (informe de Messari sobre Lit Protocol, documentación de Threshold Network y descripciones de FHE de Zama). Toda la información está actualizada a partir de 2025.

Las blockchains públicas ofrecen transparencia e integridad a costa de la privacidad: cada transacción y estado de contrato se expone a todos los participantes. Esta apertura crea problemas como los ataques de MEV (Valor Extraíble por Mineros), el copy-trading y la fuga de lógica de negocio sensible. La privacidad programable tiene como objetivo resolver estos problemas al permitir cálculos 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 Homomórfico Completo (FHE-VM) y los Coprocesadores de Conocimiento Cero (ZK). Estos enfoques permiten la computación fuera de cadena o cifrada con verificación en cadena, preservando la confidencialidad y manteniendo la corrección sin confianza. 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, atención médica, mercados de datos y aprendizaje automático descentralizado.

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

El Cifrado Homomórfico Completo (FHE) permite realizar cálculos arbitrarios sobre datos cifrados sin necesidad de descifrarlos. Una Máquina Virtual FHE integra esta capacidad en los contratos inteligentes de blockchain, habilitando el estado y la 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 cifradas durante toda la ejecución. Esto significa que los validadores pueden procesar transacciones y actualizar el estado sin conocer ningún valor sensible, logrando la ejecución en cadena con confidencialidad de datos.

Arquitectura y Diseño de FHE-VM​

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

Se admite el almacenamiento de estado cifrado 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 utilizando la clave FHE pública antes de enviar transacciones. La clave de cifrado es pública (para cifrado y evaluación), 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. Computación Homomórfica en Cadena: Los mineros/validadores ejecutan el contrato con opcodes cifrados. Realizan las mismas operaciones homomórficas deterministas sobre los textos cifrados, de modo 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 fuera de cadena, una parte autorizada con la clave privada puede descifrar el texto cifrado de salida. De lo contrario, los resultados permanecen cifrados y pueden usarse como entradas para transacciones posteriores (permitiendo cálculos consecutivos sobre un estado cifrado persistente).

Una consideración de diseño importante es la gestión de claves. Un enfoque son las claves por usuario, donde cada usuario posee su clave secreta y solo ellos pueden descifrar los resultados relevantes para ellos. Esto maximiza la privacidad (nadie más puede descifrar sus datos), pero las operaciones homomórficas no pueden mezclar datos cifrados bajo diferentes claves sin complejos protocolos de múltiples claves. 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 en cadena, de modo que cualquiera puede 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 que los descifrados parciales sean seguros. 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 nunca el texto plano, los datos permanecen cifrados en cadena en todo momento.

El control de acceso es otro componente crucial. Las implementaciones de FHE-VM incluyen controles granulares para gestionar quién (si alguien) puede activar descifrados o acceder a ciertos campos cifrados. Por ejemplo, la fhEVM de Cypher admite Listas de Control de Acceso sobre textos cifrados, permitiendo a los desarrolladores especificar qué direcciones o contratos pueden interactuar o volver a cifrar ciertos datos. Algunos frameworks admiten la re-cifrado: 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 los mercados de datos, donde un propietario de datos puede cifrar un conjunto de datos con su clave y, al comprarlo, volver a cifrarlo con la clave del comprador, todo en cadena, sin descifrarlo públicamente.

Garantizando la Corrección y la Privacidad​

Uno podría preguntarse: si todos los datos están cifrados, ¿cómo garantizamos la corrección de la lógica del contrato? ¿Cómo puede la cadena prevenir operaciones inválidas si no puede "ver" los valores? FHE por sí mismo 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 era válida o si se debería tomar una rama condicional, etc., sin descifrar. Las pruebas de conocimiento cero (ZKP) pueden complementar FHE para resolver esta brecha. En una FHE-VM, típicamente los usuarios deben proporcionar una prueba ZK que certifique ciertas condiciones de 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 malintencionado 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 ≥ cantidad de retiro), el usuario puede proporcionar una prueba ZK de que esta condición es verdadera 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 la validación fuera de cadena con ZKP. Fhenix (un rollup L2 que utiliza FHE) opta por un modelo optimista donde un componente de red separado llamado Threshold Service Network puede descifrar o verificar resultados cifrados, y cualquier cálculo incorrecto puede ser impugnado con una prueba de fraude. En general, la combinación de FHE + ZK o pruebas de fraude asegura que la ejecución cifrada permanezca sin confianza. Los validadores, o bien 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 sobre 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 librerías criptográficas optimizadas (como la librería TFHE-rs de Zama para el bootstrapping de puertas binarias) y modificaciones personalizadas de EVM para el rendimiento. Por ejemplo, el cliente Geth modificado de Cypher añade 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álculos FHE. Zama informa que su rendimiento FHE mejoró 100 veces desde 2024 y apunta a miles de TPS con aceleración de GPU/FPGA. Los servidores de coprocesadores FHE dedicados (como el nodo LightLocker de Optalysys) pueden conectarse a los nodos validadores para descargar operaciones cifradas al hardware, soportando más de 100 transferencias ERC-20 cifradas por segundo por nodo. A medida que el hardware y los algoritmos mejoren, la brecha entre FHE y la computación 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 librería para declarar tipos y operaciones cifrados. El resto de la cadena de herramientas de Ethereum (Remix, Hardhat, etc.) aún se puede usar, 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 manejará los detalles específicos del cifrado detrás de escena. Los contratos incluso pueden interoperar con contratos normales, por ejemplo, un contrato cifrado podría generar un resultado descifrado a un contrato estándar si se desea, permitiendo una mezcla de partes privadas y públicas en un mismo ecosistema.

Proyectos actuales de FHE-VM: Varios proyectos son pioneros en este espacio. Zama (una startup de FHE con sede en París) desarrolló el concepto central de FHEVM y sus librerías (TFHE-rs y una librería 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 testnets (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. Optó 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 librería 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 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 crece rápidamente, impulsado por una financiación significativa; por ejemplo, Zama se convirtió en un "unicornio" con más de 130 millones de dólares recaudados para 2025 para avanzar en la tecnología FHE.

En resumen, una FHE-VM habilita contratos inteligentes que preservan la privacidad al ejecutar toda la lógica sobre datos cifrados en cadena. Este paradigma garantiza la máxima confidencialidad (nada sensible se expone en transacciones o estado) mientras aprovecha el consenso existente de la blockchain 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 la computación completamente fuera de cadena y solo utiliza la cadena para la verificación: el coprocesador de conocimiento cero.

Coprocesadores de Conocimiento Cero (ZK-Coprocesadores)​

Un coprocesador ZK es un nuevo patrón de arquitectura de blockchain donde las computaciones costosas se realizan fuera de cadena, y una prueba de conocimiento cero sucinta de su corrección se verifica en cadena. Esto permite que los contratos inteligentes aprovechen una potencia computacional y datos mucho mayores de lo que permitiría la ejecución en cadena, sin sacrificar la falta de confianza. 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 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 en cadena 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 en cadena (por ejemplo, grandes cálculos sobre datos históricos, algoritmos pesados, inferencia de modelos de ML, etc.). Implementan esas partes como un programa fuera de cadena (en un lenguaje de alto nivel o DSL de circuito) que puede producir una prueba de conocimiento cero de su ejecución. El componente en cadena 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 como:

1. Solicitud – El contrato en cadena activa una solicitud para que se realice una determinada computación fuera de cadena. 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 podría llamar a “queryHistoricalData(query)”.
2. Ejecución y Prueba Fuera de Cadena – Un servicio fuera de cadena (que podría ser una red descentralizada de probadores o un servicio de confianza, dependiendo del diseño) recoge la solicitud. Recopila los datos necesarios (estado en cadena, entradas fuera de cadena, etc.) y ejecuta la computación en una Máquina Virtual ZK (ZKVM) o circuito especial. Durante la ejecución, se genera un rastro de prueba. Al final, el servicio produce una prueba sucinta (por ejemplo, un SNARK o STARK) que certifica que “Calcular la función F con la entrada X produce la salida Y” y, opcionalmente, certifica la integridad de los datos (más sobre esto a continuación).
3. Verificación en Cadena – La prueba y el resultado se devuelven a la blockchain (a menudo a través de una función de 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 que la salida Y es correcta. El resultado puede almacenarse en el estado, emitirse como un evento o alimentarse a la lógica del contrato. Si la prueba no es válida o no se proporciona dentro de un tiempo determinado, la solicitud puede considerarse fallida (y potencialmente se activará alguna lógica de respaldo o de tiempo de espera).

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

Críticamente, el costo de gas en cadena para la verificación es constante (o crece muy lentamente) independientemente de la complejidad de la computación fuera de cadena. 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 fuera de cadena. Como bromeó un desarrollador, “¿Quieres probar una firma digital? ~$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 saturar 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 computaciones específicas. 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 utilizan para escribir su lógica fuera de cadena, 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 pueden escribirse en lenguajes estándar (Rust, C, etc.) y probarse automáticamente. Esto sacrifica el rendimiento (simular una CPU en un circuito añade sobrecarga) para una máxima experiencia de desarrollador.

• Acceso e Integridad de Datos: Un desafío único es alimentar la computación fuera de cadena con los datos correctos, especialmente si esos datos residen en la blockchain (bloques pasados, estados de contratos, etc.). Una solución ingenua es hacer que el probador lea de un nodo de archivo y confíe en él, pero eso introduce suposiciones de confianza. Los coprocesadores ZK, en cambio, típicamente prueban que cualquier dato en cadena utilizado fue realmente auténtico al vincularlo a pruebas Merkle o compromisos de estado. Por ejemplo, el programa de consulta podría tomar un número de bloque y una prueba 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: Colocar los datos necesarios en cadena (como entrada para el 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 garantice. Esto es más simple, pero reintroduce la confianza en un tercero.
  3. Probar la Inclusión de Datos a través de 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 del estado) y el historial de transacciones. Al verificar las pruebas Merkle Patricia de los datos dentro del circuito, la prueba de salida asegura al contrato que “esta computación utilizó datos genuinos de la blockchain del bloque N” sin necesidad de confianza adicional.

  El tercer enfoque es el más descentralizado 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 confiable reciente, se puede probar recursivamente la inclusión de datos históricos sin confiar en ninguna parte externa.

• Contrato Verificador: Este contrato en cadena 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 realizar algunos emparejamientos de curvas elípticas; para STARKs, podría realizar algunos cálculos de hash. Las optimizaciones de rendimiento como la agregación y la recursión pueden minimizar la carga en cadena. Por ejemplo, Bonsai de RISC Zero utiliza un envoltorio STARK-a-SNARK: ejecuta una VM basada en STARK fuera de cadena para mayor velocidad, pero luego genera una pequeña prueba SNARK que certifica 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 en cadena sea factible y económica. 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 tipo capa 2 o como servicios puramente fuera de cadena. 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 en cadena. El lema de Axiom era proporcionar a los contratos de Ethereum “acceso sin confianza a todos los datos en cadena y computación expresiva arbitraria sobre ellos”. Actúa efectivamente como un oráculo de consultas donde las respuestas son verificadas por ZKP 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 prueba de Bonsai a través de un contrato de retransmisión. El patrón de retransmisión, como se ilustra en la Figura 1, implica un contrato que media las solicitudes y respuestas: el contrato de la dApp llama al retransmisor para pedir una prueba, el servicio fuera de cadena escucha esto (por ejemplo, a través de un evento o una llamada directa), calcula la prueba, y luego el retransmisor invoca una función de callback en el contrato de la dApp con el resultado y la prueba. Este modelo asíncrono es necesario porque la prueba puede tardar de segundos a minutos dependiendo de la complejidad. Introduce una latencia (y una suposición de vivacidad de que el probador responderá), mientras que las computaciones 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 Oracle) 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 históricos en cadena. 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 una computación sobre todas las transacciones en un rango. Bajo el capó, 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 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 se pruebe 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 no puede hacer de forma nativa, habilitando el acceso sin estado a cualquier dato histórico con integridad criptográfica. También han enfatizado la seguridad, detectando y corrigiendo errores de circuitos subrestringidos 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 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 fuera de cadena), lo sube al servicio Bonsai y despliega un contrato verificador correspondiente. Cuando el contrato necesita esa computación, llama al relé de Bonsai que activa la generación de la prueba y devuelve el resultado a través de una devolución de llamada. Un ejemplo de aplicación demostrado fue la computación de gobernanza fuera de cadena: RISC Zero mostró una DAO utilizando Bonsai para contar votos y calcular métricas de votación complejas fuera de cadena, y luego publicar una prueba para que el contrato de Gobernador en cadena pudiera confiar en el resultado con un costo mínimo de gas. La tecnología de RISC Zero enfatiza que los desarrolladores pueden usar paradigmas de programación familiares (por ejemplo, escribir una función 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 en cadena. En agosto de 2023, verificaron con éxito pruebas de RISC Zero en la testnet Sepolia de Ethereum, con un costo del orden de 300k 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 está listo para producción y utiliza una configuración SNARK temporal sin ceremonia.)

• Otros: Existen numerosos otros actores e iniciativas de investigación. Expansion/Xpansion (como se menciona en un blog) utiliza un enfoque de DSL incrustado, donde los desarrolladores pueden escribir consultas sobre datos en cadena con un lenguaje especializado, y este maneja la generación de pruebas internamente. 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 verificando pruebas dentro de contratos L1. También vemos proyectos en el dominio de ZKML (Aprendizaje Automático con ZK), que actúan efectivamente como coprocesadores para verificar la inferencia de modelos ML o los resultados de entrenamiento en cadena. Por ejemplo, una configuración zkML puede probar que “una inferencia de red neuronal sobre entradas privadas produjo la clasificación X” sin revelar las entradas ni realizar la computación en cadena. Estos son casos especiales del concepto de coprocesador aplicado a la IA.

Supuestos de confianza: Los coprocesadores ZK se basan en la solidez de las pruebas criptográficas. Si el sistema de pruebas es seguro (y cualquier configuración de confianza se realiza honestamente), entonces una prueba aceptada garantiza que la computación fue correcta. No se necesita confianza adicional en el probador, incluso un probador malicioso no puede convencer al verificador de una declaración falsa. Sin embargo, existe un supuesto de vivacidad: alguien debe realizar la computación fuera de cadena y producir la prueba. En la práctica, esto podría ser una red descentralizada (con incentivos o tarifas para realizar el trabajo) o un único operador de servicio. Si nadie proporciona la prueba, la solicitud en cadena podría quedar sin resolver. Otro aspecto sutil de la confianza es la disponibilidad de datos para entradas fuera de cadena que no están en la blockchain. Si la computación 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áculo). Pero para computaciones de datos puramente en cadena, los mecanismos descritos garantizan una falta de confianza equivalente a 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 préstamo” sin revelar la puntuación de crédito real o los datos brutos. El caso de uso de Axiom se centró más en datos públicamente conocidos (historial de blockchain), por lo que la privacidad no fue 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 fuera de cadena y solo el resultado necesario va en cadena. Vale la pena señalar que, a diferencia de 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 completamente privadas, pero la implementación no es trivial; a menudo se utilizan para computaciones únicas donde la entrada o la salida (o ambas) pueden ser privadas según sea necesario.

Experiencia del desarrollador: Usar un coprocesador ZK típicamente requiere aprender nuevas herramientas. Escribir circuitos personalizados (opción (1) anterior) es bastante complejo y generalmente solo se hace para propósitos específicos. Las opciones de nivel superior como los DSL o las zkVM facilitan la vida, pero aún añaden sobrecarga: el desarrollador debe escribir y desplegar código fuera de cadena y gestionar la interacción. A diferencia de FHE-VM, donde el cifrado se maneja en gran medida detrás de escena y el desarrollador escribe código de contrato inteligente normal, aquí el desarrollador necesita dividir su lógica y posiblemente escribir en un lenguaje diferente (Rust, etc.) para la parte fuera de cadena. Sin embargo, iniciativas como los DSL de 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 para que un desarrollador pueda simular su código fuera de cadena localmente (para verificar 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 mediante prueba ZK o en cadena; el compilador o las herramientas podrían decidir basándose en el costo.

FHE-VM vs Coprocesador ZK: Comparación​

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

Aspecto	FHE-VM (Ejecución Cifrada en Cadena)	Coprocesador ZK (Prueba Fuera de Cadena)

Public blockchains provide transparency and integrity at the cost of privacy – every transaction and contract state is exposed to all participants. This openness creates problems like MEV (Miner Extractable Value) attacks, copy-trading, and leakage of sensitive business logic. Programmable privacy aims to solve these issues by allowing computations on private data without revealing the data itself. Two emerging cryptographic paradigms are making this possible: Fully Homomorphic Encryption Virtual Machines (FHE-VM) and Zero-Knowledge (ZK) Coprocessors. These approaches enable off-chain or encrypted computation with on-chain verification, preserving confidentiality while retaining trustless correctness. In this report, we dive deep into FHE-VM and ZK-coprocessor architectures, compare their trade-offs, and explore use cases across finance, identity, healthcare, data markets, and decentralized machine learning.

Fully Homomorphic Encryption Virtual Machine (FHE-VM)​

Fully Homomorphic Encryption (FHE) allows arbitrary computations on encrypted data without ever decrypting it. An FHE Virtual Machine integrates this capability into blockchain smart contracts, enabling encrypted contract state and logic. In an FHE-enabled blockchain (often called an fhEVM for EVM-compatible designs), all inputs, contract storage, and outputs remain encrypted throughout execution. This means validators can process transactions and update state without learning any sensitive values, achieving on-chain execution with data confidentiality.

Architecture and Design of FHE-VM​

A typical FHE-VM extends a standard smart contract runtime (like the Ethereum Virtual Machine) with native support for encrypted data types and operations. For example, Zama’s FHEVM introduces encrypted integers (euint8, euint32, etc.), encrypted booleans (ebool), and even encrypted arrays as first-class types. Smart contract languages like Solidity are augmented via libraries or new opcodes so developers can perform arithmetic (add, mul, etc.), logical operations, and comparisons directly on ciphertexts. Under the hood, these operations invoke FHE primitives (e.g. using the TFHE library) to manipulate encrypted bits and produce encrypted results.

Encrypted state storage is supported so that contract variables remain encrypted in the blockchain state. The execution flow is typically:

1. Client-Side Encryption: Users encrypt their inputs locally using the public FHE key before sending transactions. The encryption key is public (for encryption and evaluation), while the decryption key remains secret. In some designs, each user manages their own key; in others, a single global FHE key is used (discussed below).
2. On-Chain Homomorphic Computation: Miners/validators execute the contract with encrypted opcodes. They perform the same deterministic homomorphic operations on the ciphertexts, so consensus can be reached on the encrypted new state. Crucially, validators never see plaintext data – they just see “gibberish” ciphertext but can still process it consistently.
3. Decryption (Optional): If a result needs to be revealed or used off-chain, an authorized party with the private key can decrypt the output ciphertext. Otherwise, results remain encrypted and can be used as inputs to further transactions (allowing consecutive computations on persistent encrypted state).

A major design consideration is key management. One approach is per-user keys, where each user holds their secret key and only they can decrypt outputs relevant to them. This maximizes privacy (no one else can ever decrypt your data), but homomorphic operations cannot mix data encrypted under different keys without complex multi-key protocols. Another approach, used by Zama’s FHEVM, is a global FHE key: a single public key encrypts all contract data and a distributed set of validators holds shares of the threshold decryption key. The public encryption and evaluation keys are published on-chain, so anyone can encrypt data to the network; the private key is split among validators who can collectively decrypt if needed under a threshold scheme. To prevent validator collusion from compromising privacy, Zama employs a threshold FHE protocol (based on their Noah’s Ark research) with “noise flooding” to make partial decryptions secure. Only if a sufficient quorum of validators cooperates can a plaintext be recovered, for example to serve a read request. In normal operation, however, no single node ever sees plaintext – data remains encrypted on-chain at all times.

Access control is another crucial component. FHE-VM implementations include fine-grained controls to manage who (if anyone) can trigger decryptions or access certain encrypted fields. For instance, Cypher’s fhEVM supports Access Control Lists on ciphertexts, allowing developers to specify which addresses or contracts can interact with or re-encrypt certain data. Some frameworks support re-encryption: the ability to transfer an encrypted value from one user’s key to another’s without exposing plaintext. This is useful for things like data marketplaces, where a data owner can encrypt a dataset with their key, and upon purchase, re-encrypt it to the buyer’s key – all on-chain, without ever decrypting publicly.

Ensuring Correctness and Privacy​

One might ask: if all data is encrypted, how do we enforce correctness of contract logic? How can the chain prevent invalid operations if it can’t “see” the values? FHE by itself doesn’t provide a proof of correctness – validators can perform the homomorphic steps, but they can’t inherently tell if a user’s encrypted input was valid or if a conditional branch should be taken, etc., without decrypting. Zero-knowledge proofs (ZKPs) can complement FHE to solve this gap. In an FHE-VM, typically users must provide a ZK proof attesting to certain plaintext conditions whenever needed. Zama’s design, for example, uses a ZK Proof of Plaintext Knowledge (ZKPoK) to accompany each encrypted input. This proves that the user knows the plaintext corresponding to their ciphertext and that it meets expected criteria, without revealing the plaintext itself. Such “certified ciphertexts” prevent a malicious user from submitting a malformed encryption or an out-of-range value. Similarly, for operations that require a decision (e.g. ensure account balance ≥ withdrawal amount), the user can supply a ZK proof that this condition holds true on the plaintexts before the encrypted operation is executed. In this way, the chain doesn’t decrypt or see the values, but it gains confidence that the encrypted transactions follow the rules.

Another approach in FHE rollups is to perform off-chain validation with ZKPs. Fhenix (an L2 rollup using FHE) opts for an optimistic model where a separate network component called a Threshold Service Network can decrypt or verify encrypted results, and any incorrect computation can be challenged with a fraud-proof. In general, combining FHE + ZK or fraud proofs ensures that encrypted execution remains trustless. Validators either collectively decrypt only when authorized, or they verify proofs that each encrypted state transition was valid without needing to see plaintext.

Performance considerations: FHE operations are computationally heavy – many orders of magnitude slower than normal arithmetic. For example, a simple 64-bit addition on Ethereum costs ~3 gas, whereas an addition on an encrypted 64-bit integer (euint64) under Zama’s FHEVM costs roughly 188,000 gas. Even an 8-bit add can cost ~94k gas. This enormous overhead means a straightforward implementation on existing nodes would be impractically slow and costly. FHE-VM projects tackle this with optimized cryptographic libraries (like Zama’s TFHE-rs library for binary gate bootstrapping) and custom EVM modifications for performance. For instance, Cypher’s modified Geth client adds new opcodes and optimizes homomorphic instruction execution in C++/assembly to minimize overhead. Nevertheless, achieving usable throughput requires acceleration. Ongoing work includes using GPUs, FPGAs, and even specialized photonic chips to speed up FHE computations. Zama reports their FHE performance improved 100× since 2024 and is targeting thousands of TPS with GPU/FPGA acceleration. Dedicated FHE co-processor servers (such as Optalysys’s LightLocker Node) can plug into validator nodes to offload encrypted operations to hardware, supporting >100 encrypted ERC-20 transfers per second per node. As hardware and algorithms improve, the gap between FHE and plain computation will narrow, enabling private contracts to approach more practical speeds.

Compatibility: A key goal of FHE-VM designs is to remain compatible with existing development workflows. Cypher’s and Zama’s fhEVM implementations allow developers to write contracts in Solidity with minimal changes – using a library to declare encrypted types and operations. The rest of the Ethereum toolchain (Remix, Hardhat, etc.) can still be used, as the underlying modifications are mostly at the client/node level. This lowers the barrier to entry: developers don’t need to be cryptography experts to write a confidential smart contract. For example, a simple addition of two numbers can be written as euint32 c = a + b; and the FHEVM will handle the encryption-specific details behind the scenes. The contracts can even interoperate with normal contracts – e.g. an encrypted contract could output a decrypted result to a standard contract if desired, allowing a mix of private and public parts in one ecosystem.

Current FHE-VM Projects: Several projects are pioneering this space. Zama (a Paris-based FHE startup) developed the core FHEVM concept and libraries (TFHE-rs and an fhevm-solidity library). They do not intend to launch their own chain, but rather provide infrastructure to others. Inco is an L1 blockchain (built on Cosmos SDK with Evmos) that integrated Zama’s FHEVM to create a modular confidential chain. Their testnets (named Gentry and Paillier) showcase encrypted ERC-20 transfers and other private DeFi primitives. Fhenix is an Ethereum Layer-2 optimistic rollup using FHE for privacy. It decided on an optimistic (fraud-proof) approach rather than ZK-rollup due to the heavy cost of doing FHE and ZK together for every block. Fhenix uses the same TFHE-rs library (with some modifications) and introduces a Threshold Service Network for handling decryptions in a decentralized way. There are also independent teams like Fhenix (now rebranded) and startups exploring MPC + FHE hybrids. Additionally, Cypher (by Z1 Labs) is building a Layer-3 network focused on AI and privacy, using an fhEVM with features like secret stores and federated learning support. The ecosystem is nascent but growing rapidly, fueled by significant funding – e.g. Zama became a “unicorn” with >$130M raised by 2025 to advance FHE tech.

In summary, an FHE-VM enables privacy-preserving smart contracts by executing all logic on encrypted data on-chain. This paradigm ensures maximum confidentiality – nothing sensitive is ever exposed in transactions or state – while leveraging the existing blockchain consensus for integrity. The cost is increased computational burden on validators and complexity in key management and proof integration. Next, we explore an alternative paradigm that offloads compute entirely off-chain and only uses the chain for verification: the zero-knowledge coprocessor.

Coprocesadores de Conocimiento Cero (ZK-Coprocesadores)​

Un coprocesador ZK es un nuevo patrón de arquitectura de blockchain donde las computaciones costosas se realizan fuera de cadena, y una prueba de conocimiento cero sucinta de su corrección se verifica en cadena. Esto permite que los contratos inteligentes aprovechen una potencia computacional y datos mucho mayores de lo que permitiría la ejecución en cadena, sin sacrificar la falta de confianza. 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 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 en cadena 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 en cadena (por ejemplo, grandes cálculos sobre datos históricos, algoritmos pesados, inferencia de modelos de ML, etc.). Implementan esas partes como un programa fuera de cadena (en un lenguaje de alto nivel o DSL de circuito) que puede producir una prueba de conocimiento cero de su ejecución. El componente en cadena 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 como:

1. Solicitud – El contrato en cadena activa una solicitud para que se realice una determinada computación fuera de cadena. 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 podría llamar a “queryHistoricalData(query)”.
2. Ejecución y Prueba Fuera de Cadena – Un servicio fuera de cadena (que podría ser una red descentralizada de probadores o un servicio de confianza, dependiendo del diseño) recoge la solicitud. Recopila los datos necesarios (estado en cadena, entradas fuera de cadena, etc.) y ejecuta la computación en una Máquina Virtual ZK (ZKVM) o circuito especial. Durante la ejecución, se genera un rastro de prueba. Al final, el servicio produce una prueba sucinta (por ejemplo, un SNARK o STARK) que certifica que “Calcular la función F con la entrada X produce la salida Y” y, opcionalmente, certifica la integridad de los datos (más sobre esto a continuación).
3. Verificación en Cadena – La prueba y el resultado se devuelven a la blockchain (a menudo a través de una función de 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 que la salida Y es correcta. El resultado puede almacenarse en el estado, emitirse como un evento o alimentarse a la lógica del contrato. Si la prueba no es válida o no se proporciona dentro de un tiempo determinado, la solicitud puede considerarse fallida (y potencialmente se activará alguna lógica de respaldo o de tiempo de espera).

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

Críticamente, el costo de gas en cadena para la verificación es constante (o crece muy lentamente) independientemente de la complejidad de la computación fuera de cadena. 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 fuera de cadena. Como bromeó un desarrollador, “¿Quieres probar una firma digital? ~$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 saturar 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 computaciones específicas. 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 utilizan para escribir su lógica fuera de cadena, 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 pueden escribirse en lenguajes estándar (Rust, C, etc.) y probarse automáticamente. Esto sacrifica el rendimiento (simular una CPU en un circuito añade sobrecarga) para una máxima experiencia de desarrollador.

• Acceso e Integridad de Datos: Un desafío único es alimentar la computación fuera de cadena con los datos correctos, especialmente si esos datos residen en la blockchain (bloques pasados, estados de contratos, etc.). Una solución ingenua es hacer que el probador lea de un nodo de archivo y confíe en él, pero eso introduce suposiciones de confianza. Los coprocesadores ZK, en cambio, típicamente prueban que cualquier dato en cadena utilizado fue realmente auténtico al vincularlo a pruebas Merkle o compromisos de estado. Por ejemplo, el programa de consulta podría tomar un número de bloque y una prueba 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: Colocar los datos necesarios en cadena (como entrada para el 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 garantice. Esto es más simple, pero reintroduce la confianza en un tercero.
  3. Probar la Inclusión de Datos a través de 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 del estado) y el historial de transacciones. Al verificar las pruebas Merkle Patricia de los datos dentro del circuito, la prueba de salida asegura al contrato que “esta computación utilizó datos genuinos de la blockchain del bloque N” sin necesidad de confianza adicional.

  El tercer enfoque es el más descentralizado 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 confiable reciente, se puede probar recursivamente la inclusión de datos históricos sin confiar en ninguna parte externa.

• Contrato Verificador: Este contrato en cadena 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 realizar algunos emparejamientos de curvas elípticas; para STARKs, podría realizar algunos cálculos de hash. Las optimizaciones de rendimiento como la agregación y la recursión pueden minimizar la carga en cadena. Por ejemplo, Bonsai de RISC Zero utiliza un envoltorio STARK-a-SNARK: ejecuta una VM basada en STARK fuera de cadena para mayor velocidad, pero luego genera una pequeña prueba SNARK que certifica 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 en cadena sea factible y económica. 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 tipo capa 2 o como servicios puramente fuera de cadena. 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 en cadena. El lema de Axiom era proporcionar a los contratos de Ethereum “acceso sin confianza a todos los datos en cadena y computación expresiva arbitraria sobre ellos”. Actúa efectivamente como un oráculo de consultas donde las respuestas son verificadas por ZKP 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 prueba de Bonsai a través de un contrato de retransmisión. El patrón de retransmisión, como se ilustra en la Figura 1, implica un contrato que media las solicitudes y respuestas: el contrato de la dApp llama al retransmisor para pedir una prueba, el servicio fuera de cadena escucha esto (por ejemplo, a través de un evento o una llamada directa), calcula la prueba, y luego el retransmisor invoca una función de callback en el contrato de la dApp con el resultado y la prueba. Este modelo asíncrono es necesario porque la prueba puede tardar de segundos a minutos dependiendo de la complejidad. Introduce una latencia (y una suposición de vivacidad de que el probador responderá), mientras que las computaciones 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 Oracle) 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 históricos en cadena. 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 una computación sobre todas las transacciones en un rango. Bajo el capó, 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 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 se pruebe 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 no puede hacer de forma nativa, habilitando el acceso sin estado a cualquier dato histórico con integridad criptográfica. También han enfatizado la seguridad, detectando y corrigiendo errores de circuitos subrestringidos 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 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 fuera de cadena), lo sube al servicio Bonsai y despliega un contrato verificador correspondiente. Cuando el contrato necesita esa computación, llama al relé de Bonsai que activa la generación de la prueba y devuelve el resultado a través de una devolución de llamada. Un ejemplo de aplicación demostrado fue la computación de gobernanza fuera de cadena: RISC Zero mostró una DAO utilizando Bonsai para contar votos y calcular métricas de votación complejas fuera de cadena, y luego publicar una prueba para que el contrato de Gobernador en cadena pudiera confiar en el resultado con un costo mínimo de gas. La tecnología de RISC Zero enfatiza que los desarrolladores pueden usar paradigmas de programación familiares (por ejemplo, escribir una función 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 en cadena. En agosto de 2023, verificaron con éxito pruebas de RISC Zero en la testnet Sepolia de Ethereum, con un costo del orden de 300k 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 está listo para producción y utiliza una configuración SNARK temporal sin ceremonia.)

• Otros: Existen numerosos otros actores e iniciativas de investigación. Expansion/Xpansion (como se menciona en un blog) utiliza un enfoque de DSL incrustado, donde los desarrolladores pueden escribir consultas sobre datos en cadena con un lenguaje especializado, y este maneja la generación de pruebas internamente. 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 verificando pruebas dentro de contratos L1. También vemos proyectos en el dominio de ZKML (Aprendizaje Automático con ZK), que actúan efectivamente como coprocesadores para verificar la inferencia de modelos ML o los resultados de entrenamiento en cadena. Por ejemplo, una configuración zkML puede probar que “una inferencia de red neuronal sobre entradas privadas produjo la clasificación X” sin revelar las entradas ni realizar la computación en cadena. Estos son casos especiales del concepto de coprocesador aplicado a la IA.

Supuestos de confianza: Los coprocesadores ZK se basan en la solidez de las pruebas criptográficas. Si el sistema de pruebas es seguro (y cualquier configuración de confianza se realiza honestamente), entonces una prueba aceptada garantiza que la computación fue correcta. No se necesita confianza adicional en el probador, incluso un probador malicioso no puede convencer al verificador de una declaración falsa. Sin embargo, existe un supuesto de vivacidad: alguien debe realizar la computación fuera de cadena y producir la prueba. En la práctica, esto podría ser una red descentralizada (con incentivos o tarifas para realizar el trabajo) o un único operador de servicio. Si nadie proporciona la prueba, la solicitud en cadena podría quedar sin resolver. Otro aspecto sutil de la confianza es la disponibilidad de datos para entradas fuera de cadena que no están en la blockchain. Si la computación 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áculo). Pero para computaciones de datos puramente en cadena, los mecanismos descritos garantizan una falta de confianza equivalente a 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 préstamo” sin revelar la puntuación de crédito real o los datos brutos. El caso de uso de Axiom se centró más en datos públicamente conocidos (historial de blockchain), por lo que la privacidad no fue 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 fuera de cadena y solo el resultado necesario va en cadena. Vale la pena señalar que, a diferencia de 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 completamente privadas, pero la implementación no es trivial; a menudo se utilizan para computaciones únicas donde la entrada o la salida (o ambas) pueden ser privadas según sea necesario.

Experiencia del desarrollador: Usar un coprocesador ZK típicamente requiere aprender nuevas herramientas. Escribir circuitos personalizados (opción (1) anterior) es bastante complejo y generalmente solo se hace para propósitos específicos. Las opciones de nivel superior como los DSL o las zkVM facilitan la vida, pero aún añaden sobrecarga: el desarrollador debe escribir y desplegar código fuera de cadena y gestionar la interacción. A diferencia de FHE-VM, donde el cifrado se maneja en gran medida detrás de escena y el desarrollador escribe código de contrato inteligente normal, aquí el desarrollador necesita dividir su lógica y posiblemente escribir en un lenguaje diferente (Rust, etc.) para la parte fuera de cadena. Sin embargo, iniciativas como los DSL de 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 para que un desarrollador pueda simular su código fuera de cadena localmente (para verificar 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 mediante prueba ZK o en cadena; el compilador o las herramientas podrían decidir basándose en el costo.

FHE-VM vs Coprocesador ZK: Comparación​

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

Aspecto	FHE-VM (Ejecución Cifrada en Cadena)	Coprocesador ZK (Prueba Fuera de Cadena)