Saltar al contenido principal

7 publicaciones etiquetados con "Criptografía"

Protocolos y técnicas criptográficas

Ver todas las etiquetas

Construyendo Encriptación Descentralizada con @mysten/seal: Tutorial para Desarrolladores

· 14 min de lectura
Dora Noda
Software Engineer

La privacidad se está convirtiendo en infraestructura pública. En 2025, los desarrolladores necesitan herramientas que hagan la encriptación tan fácil como almacenar datos. Seal de Mysten Labs proporciona exactamente eso: gestión de secretos descentralizada con control de acceso onchain. Este tutorial te enseñará cómo construir aplicaciones Web3 seguras usando encriptación basada en identidad, seguridad threshold y políticas de acceso programables.


Introducción: Por Qué Seal Importa para Web3

Las aplicaciones cloud tradicionales dependen de sistemas centralizados de gestión de claves donde un solo proveedor controla el acceso a datos encriptados. Aunque esto es conveniente, crea peligrosos puntos únicos de falla. Si el proveedor se ve comprometido, se desconecta o decide restringir el acceso, tus datos se vuelven inaccesibles o vulnerables.

Seal cambia completamente este paradigma. Construido por Mysten Labs para la blockchain Sui, Seal es un servicio de gestión de secretos descentralizada (DSM) que permite:

  • Encriptación basada en identidad donde el contenido se protege antes de salir de tu entorno
  • Encriptación threshold que distribuye el acceso a claves entre múltiples nodos independientes
  • Control de acceso onchain con bloqueos temporales, token-gating y lógica de autorización personalizada
  • Diseño agnóstico de almacenamiento que funciona con Walrus, IPFS o cualquier solución de almacenamiento

Ya sea que estés construyendo aplicaciones de mensajería segura, plataformas de contenido con acceso restringido o transferencias de activos con bloqueo temporal, Seal proporciona las primitivas criptográficas y la infraestructura de control de acceso que necesitas.


Primeros Pasos

Prerrequisitos

Antes de comenzar, asegúrate de tener:

  • Node.js 18+ instalado
  • Familiaridad básica con TypeScript/JavaScript
  • Una wallet de Sui para pruebas (como Sui Wallet)
  • Comprensión de conceptos blockchain

Instalación

Instala el SDK de Seal vía npm:

npm install @mysten/seal

También querrás el SDK de Sui para interacciones blockchain:

npm install @mysten/sui

Configuración del Proyecto

Crea un nuevo proyecto e inicialízalo:

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

Crea una configuración simple de TypeScript:

// tsconfig.json
{
"compilerOptions": {
"target": "ES2020",
"module": "commonjs",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true
}
}

Conceptos Fundamentales: Cómo Funciona Seal

Antes de escribir código, entendamos la arquitectura de Seal:

1. Encriptación Basada en Identidad (IBE)

A diferencia de la encriptación tradicional donde encriptas a una clave pública, IBE te permite encriptar a una identidad (como una dirección de email o dirección Sui). El destinatario solo puede desencriptar si puede probar que controla esa identidad.

2. Encriptación Threshold

En lugar de confiar en un solo servidor de claves, Seal usa esquemas threshold t-de-n. Podrías configurar 3-de-5 servidores de claves, significando que cualquier 3 servidores pueden cooperar para proporcionar claves de desencriptación, pero 2 o menos no pueden.

3. Control de Acceso Onchain

Las políticas de acceso son aplicadas por smart contracts de Sui. Antes de que un servidor de claves proporcione claves de desencriptación, verifica que el solicitante cumpla con los requisitos de política onchain (propiedad de tokens, restricciones temporales, etc.).

4. Red de Servidores de Claves

Los servidores de claves distribuidos validan políticas de acceso y generan claves de desencriptación. Estos servidores son operados por diferentes partes para asegurar que no haya un punto único de control.


Implementación Básica: Tu Primera Aplicación Seal

Construyamos una aplicación simple que encripte datos sensibles y controle el acceso a través de políticas blockchain de Sui.

Paso 1: Inicializar el Cliente Seal

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
// Inicializar cliente Sui para testnet
const suiClient = new SuiClient({
url: 'https://fullnode.testnet.sui.io'
});

// Configurar cliente Seal con servidores de claves de testnet
const sealClient = new SealClient({
suiClient,
keyServers: [
'https://keyserver1.seal-testnet.com',
'https://keyserver2.seal-testnet.com',
'https://keyserver3.seal-testnet.com'
],
threshold: 2, // threshold 2-de-3
network: 'testnet'
});

return { sealClient, suiClient };
}

Paso 2: Encriptación/Desencriptación Simple

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
const { sealClient } = await createSealClient();

// Datos a encriptar
const sensitiveData = "¡Este es mi mensaje secreto!";
const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

try {
// Encriptar datos para una dirección Sui específica
const encryptedData = await sealClient.encrypt({
data: Buffer.from(sensitiveData, 'utf-8'),
recipientId: recipientAddress,
// Opcional: agregar metadata
metadata: {
contentType: 'text/plain',
timestamp: Date.now()
}
});

console.log('Datos encriptados:', {
ciphertext: encryptedData.ciphertext.toString('base64'),
encryptionId: encryptedData.encryptionId
});

// Más tarde, desencriptar los datos (requiere autorización apropiada)
const decryptedData = await sealClient.decrypt({
ciphertext: encryptedData.ciphertext,
encryptionId: encryptedData.encryptionId,
recipientId: recipientAddress
});

console.log('Datos desencriptados:', decryptedData.toString('utf-8'));

} catch (error) {
console.error('Encriptación/desencriptación falló:', error);
}
}

basicExample();

Control de Acceso con Smart Contracts de Sui

El verdadero poder de Seal viene del control de acceso programable. Creemos un ejemplo de encriptación con bloqueo temporal donde los datos solo pueden ser desencriptados después de un tiempo específico.

Paso 1: Desplegar Contrato de Control de Acceso

Primero, necesitamos un smart contract Move que defina nuestra política de acceso:

// contracts/time_lock.move
module time_lock::policy {
use sui::clock::{Self, Clock};
use sui::object::{Self, UID};
use sui::tx_context::{Self, TxContext};

public struct TimeLockPolicy has key, store {
id: UID,
unlock_time: u64,
authorized_user: address,
}

public fun create_time_lock(
unlock_time: u64,
authorized_user: address,
ctx: &mut TxContext
): TimeLockPolicy {
TimeLockPolicy {
id: object::new(ctx),
unlock_time,
authorized_user,
}
}

public fun can_decrypt(
policy: &TimeLockPolicy,
user: address,
clock: &Clock
): bool {
let current_time = clock::timestamp_ms(clock);
policy.authorized_user == user && current_time >= policy.unlock_time
}
}

Paso 2: Integrar con Seal

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
const { sealClient, suiClient } = await createSealClient();

// Crear política de acceso en Sui
const txb = new TransactionBlock();

const unlockTime = Date.now() + 60000; // Desbloquear en 1 minuto
const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

txb.moveCall({
target: 'time_lock::policy::create_time_lock',
arguments: [
txb.pure(unlockTime),
txb.pure(authorizedUser)
]
});

// Ejecutar transacción para crear política
const result = await suiClient.signAndExecuteTransactionBlock({
transactionBlock: txb,
signer: yourKeypair, // Tu keypair de Sui
});

const policyId = result.objectChanges?.find(
change => change.type === 'created'
)?.objectId;

// Ahora encriptar con esta política
const sensitiveData = "¡Esto se desbloqueará en 1 minuto!";

const encryptedData = await sealClient.encrypt({
data: Buffer.from(sensitiveData, 'utf-8'),
recipientId: authorizedUser,
accessPolicy: {
policyId,
policyType: 'time_lock'
}
});

console.log('Datos con bloqueo temporal creados. Intenta desencriptar después de 1 minuto.');

return {
encryptedData,
policyId,
unlockTime
};
}

Ejemplos Prácticos

Ejemplo 1: Aplicación de Mensajería Segura

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
private sealClient: any;

constructor(sealClient: any) {
this.sealClient = sealClient;
}

async sendMessage(
message: string,
recipientAddress: string,
senderKeypair: any
) {
const messageData = {
content: message,
timestamp: Date.now(),
sender: senderKeypair.toSuiAddress(),
messageId: crypto.randomUUID()
};

const encryptedMessage = await this.sealClient.encrypt({
data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
recipientId: recipientAddress,
metadata: {
type: 'secure_message',
sender: senderKeypair.toSuiAddress()
}
});

// Almacenar mensaje encriptado en almacenamiento descentralizado (Walrus)
return this.storeOnWalrus(encryptedMessage);
}

async readMessage(encryptionId: string, recipientKeypair: any) {
// Recuperar del almacenamiento
const encryptedData = await this.retrieveFromWalrus(encryptionId);

// Desencriptar con Seal
const decryptedData = await this.sealClient.decrypt({
ciphertext: encryptedData.ciphertext,
encryptionId: encryptedData.encryptionId,
recipientId: recipientKeypair.toSuiAddress()
});

return JSON.parse(decryptedData.toString('utf-8'));
}

private async storeOnWalrus(data: any) {
// Integración con almacenamiento Walrus
// Esto subiría los datos encriptados a Walrus
// y devolvería el blob ID para recuperación
}

private async retrieveFromWalrus(blobId: string) {
// Recuperar datos encriptados de Walrus usando blob ID
}
}

Ejemplo 2: Plataforma de Contenido con Token-Gating

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
private sealClient: any;
private suiClient: any;

constructor(sealClient: any, suiClient: any) {
this.sealClient = sealClient;
this.suiClient = suiClient;
}

async createGatedContent(
content: string,
requiredNftCollection: string,
creatorKeypair: any
) {
// Crear política de propiedad NFT
const accessPolicy = await this.createNftPolicy(
requiredNftCollection,
creatorKeypair
);

// Encriptar contenido con requisito de acceso NFT
const encryptedContent = await this.sealClient.encrypt({
data: Buffer.from(content, 'utf-8'),
recipientId: 'nft_holders', // Destinatario especial para holders de NFT
accessPolicy: {
policyId: accessPolicy.policyId,
policyType: 'nft_ownership'
}
});

return {
contentId: encryptedContent.encryptionId,
accessPolicy: accessPolicy.policyId
};
}

async accessGatedContent(
contentId: string,
userAddress: string,
userKeypair: any
) {
// Verificar propiedad NFT primero
const hasAccess = await this.verifyNftOwnership(
userAddress,
contentId
);

if (!hasAccess) {
throw new Error('Acceso denegado: NFT requerido no encontrado');
}

// Desencriptar contenido
const decryptedContent = await this.sealClient.decrypt({
encryptionId: contentId,
recipientId: userAddress
});

return decryptedContent.toString('utf-8');
}

private async createNftPolicy(collection: string, creator: any) {
// Crear contrato Move que verifique propiedad NFT
// Devuelve ID del objeto política
}

private async verifyNftOwnership(user: string, contentId: string) {
// Verificar si el usuario posee NFT requerido
// Consultar Sui por propiedad NFT
}
}

Ejemplo 3: Transferencia de Activos con Bloqueo Temporal

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
assetData: any,
recipientAddress: string,
unlockTimestamp: number,
senderKeypair: any
) {
const { sealClient, suiClient } = await createSealClient();

// Crear política de bloqueo temporal en Sui
const timeLockPolicy = await createTimeLockPolicy(
unlockTimestamp,
recipientAddress,
senderKeypair,
suiClient
);

// Encriptar datos de transferencia de activos
const transferData = {
asset: assetData,
recipient: recipientAddress,
unlockTime: unlockTimestamp,
transferId: crypto.randomUUID()
};

const encryptedTransfer = await sealClient.encrypt({
data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
recipientId: recipientAddress,
accessPolicy: {
policyId: timeLockPolicy.policyId,
policyType: 'time_lock'
}
});

console.log(`Activo bloqueado hasta ${new Date(unlockTimestamp)}`);

return {
transferId: encryptedTransfer.encryptionId,
unlockTime: unlockTimestamp,
policyId: timeLockPolicy.policyId
};
}

async function claimTimeLockTransfer(
transferId: string,
recipientKeypair: any
) {
const { sealClient } = await createSealClient();

try {
const decryptedData = await sealClient.decrypt({
encryptionId: transferId,
recipientId: recipientKeypair.toSuiAddress()
});

const transferData = JSON.parse(decryptedData.toString('utf-8'));

// Procesar la transferencia de activos
console.log('Transferencia de activos desbloqueada:', transferData);

return transferData;
} catch (error) {
console.error('Transferencia aún no desbloqueada o acceso denegado:', error);
throw error;
}
}

Integración con Almacenamiento Descentralizado Walrus

Seal funciona perfectamente con Walrus, la solución de almacenamiento descentralizado de Sui. Aquí te mostramos cómo integrar ambos:

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
private sealClient: any;
private walrusClient: any;

constructor(sealClient: any, walrusClient: any) {
this.sealClient = sealClient;
this.walrusClient = walrusClient;
}

async storeEncryptedData(
data: Buffer,
recipientAddress: string,
accessPolicy?: any
) {
// Encriptar con Seal
const encryptedData = await this.sealClient.encrypt({
data,
recipientId: recipientAddress,
accessPolicy
});

// Almacenar datos encriptados en Walrus
const blobId = await this.walrusClient.store(
encryptedData.ciphertext
);

// Devolver referencia que incluye info tanto de Seal como Walrus
return {
blobId,
encryptionId: encryptedData.encryptionId,
accessPolicy: encryptedData.accessPolicy
};
}

async retrieveAndDecrypt(
blobId: string,
encryptionId: string,
userKeypair: any
) {
// Recuperar de Walrus
const encryptedData = await this.walrusClient.retrieve(blobId);

// Desencriptar con Seal
const decryptedData = await this.sealClient.decrypt({
ciphertext: encryptedData,
encryptionId,
recipientId: userKeypair.toSuiAddress()
});

return decryptedData;
}
}

// Ejemplo de uso
async function walrusExample() {
const { sealClient } = await createSealClient();
const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

const integration = new SealWalrusIntegration(sealClient, walrusClient);

const fileData = Buffer.from('Contenido de documento importante');
const recipientAddress = '0x...';

// Almacenar encriptado
const result = await integration.storeEncryptedData(
fileData,
recipientAddress
);

console.log('Almacenado con Blob ID:', result.blobId);

// Más tarde, recuperar y desencriptar
const decrypted = await integration.retrieveAndDecrypt(
result.blobId,
result.encryptionId,
recipientKeypair
);

console.log('Datos recuperados:', decrypted.toString());
}

Configuración Avanzada de Encriptación Threshold

Para aplicaciones de producción, querrás configurar encriptación threshold personalizada con múltiples servidores de claves:

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
// Configurar con múltiples servidores de claves independientes
const keyServers = [
'https://keyserver-1.your-org.com',
'https://keyserver-2.partner-org.com',
'https://keyserver-3.third-party.com',
'https://keyserver-4.backup-provider.com',
'https://keyserver-5.fallback.com'
];

const sealClient = new SealClient({
keyServers,
threshold: 3, // threshold 3-de-5
network: 'mainnet',
// Opciones avanzadas
retryAttempts: 3,
timeoutMs: 10000,
backupKeyServers: [
'https://backup-1.emergency.com',
'https://backup-2.emergency.com'
]
});

return sealClient;
}

async function robustEncryption() {
const sealClient = await setupProductionSeal();

const criticalData = "Datos encriptados de misión crítica";

// Encriptar con garantías de alta seguridad
const encrypted = await sealClient.encrypt({
data: Buffer.from(criticalData, 'utf-8'),
recipientId: '0x...',
// Requerir todos los 5 servidores para máxima seguridad
customThreshold: 5,
// Agregar redundancia
redundancy: 2,
accessPolicy: {
// Requisitos multi-factor
requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
}
});

return encrypted;
}

Mejores Prácticas de Seguridad

1. Gestión de Claves

// src/security-practices.ts

// BUENO: Usar derivación segura de claves
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// BUENO: Almacenar claves de forma segura (ejemplo con variables de entorno)
const keypair = Ed25519Keypair.fromSecretKey(
process.env.PRIVATE_KEY
);

// MALO: Nunca hardcodear claves
const badKeypair = Ed25519Keypair.fromSecretKey(
"hardcoded-secret-key-12345" // ¡No hagas esto!
);

2. Validación de Políticas de Acceso

// Siempre validar políticas de acceso antes de encriptar
async function secureEncrypt(data: Buffer, recipient: string) {
const { sealClient } = await createSealClient();

// Validar dirección del destinatario
if (!isValidSuiAddress(recipient)) {
throw new Error('Dirección de destinatario inválida');
}

// Verificar que la política existe y es válida
const policy = await validateAccessPolicy(policyId);
if (!policy.isValid) {
throw new Error('Política de acceso inválida');
}

return sealClient.encrypt({
data,
recipientId: recipient,
accessPolicy: policy
});
}

3. Manejo de Errores y Respaldos

// Manejo robusto de errores
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
const { sealClient } = await createSealClient();

try {
return await sealClient.decrypt({
encryptionId,
recipientId: userKeypair.toSuiAddress()
});
} catch (error) {
if (error.code === 'ACCESS_DENIED') {
throw new Error('Acceso denegado: Verifica tus permisos');
} else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
// Intentar con configuración de respaldo
return await retryWithBackupServers(encryptionId, userKeypair);
} else if (error.code === 'THRESHOLD_NOT_MET') {
throw new Error('Servidores de claves insuficientes disponibles');
} else {
throw new Error(`Desencriptación falló: ${error.message}`);
}
}
}

4. Validación de Datos

// Validar datos antes de encriptar
function validateDataForEncryption(data: Buffer): boolean {
// Verificar límites de tamaño
if (data.length > 1024 * 1024) { // límite de 1MB
throw new Error('Datos demasiado grandes para encriptar');
}

// Verificar patrones sensibles (opcional)
const dataStr = data.toString();
if (containsSensitivePatterns(dataStr)) {
console.warn('Advertencia: Los datos contienen patrones potencialmente sensibles');
}

return true;
}

Optimización de Rendimiento

1. Operaciones en Lotes

// Procesar múltiples encriptaciones por lotes para eficiencia
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
const { sealClient } = await createSealClient();

const promises = dataItems.map((data, index) =>
sealClient.encrypt({
data,
recipientId: recipients[index]
})
);

return Promise.all(promises);
}

2. Caché de Respuestas de Servidores de Claves

// Cachear sesiones de servidores de claves para reducir latencia
class OptimizedSealClient {
private sessionCache = new Map();

async encryptWithCaching(data: Buffer, recipient: string) {
let session = this.sessionCache.get(recipient);

if (!session || this.isSessionExpired(session)) {
session = await this.createNewSession(recipient);
this.sessionCache.set(recipient, session);
}

return this.encryptWithSession(data, session);
}
}

Probando tu Integración Seal

Pruebas Unitarias

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Integración Seal', () => {
it('debería encriptar y desencriptar datos exitosamente', async () => {
const { sealClient } = await createSealClient();
const testData = Buffer.from('mensaje de prueba');
const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

const encrypted = await sealClient.encrypt({
data: testData,
recipientId: recipient
});

expect(encrypted.encryptionId).toBeDefined();
expect(encrypted.ciphertext).toBeDefined();

const decrypted = await sealClient.decrypt({
ciphertext: encrypted.ciphertext,
encryptionId: encrypted.encryptionId,
recipientId: recipient
});

expect(decrypted.toString()).toBe('mensaje de prueba');
});

it('debería aplicar políticas de control de acceso', async () => {
// Probar que usuarios no autorizados no pueden desencriptar
const { sealClient } = await createSealClient();

const encrypted = await sealClient.encrypt({
data: Buffer.from('secreto'),
recipientId: 'authorized-user'
});

await expect(
sealClient.decrypt({
ciphertext: encrypted.ciphertext,
encryptionId: encrypted.encryptionId,
recipientId: 'unauthorized-user'
})
).rejects.toThrow('Acceso denegado');
});
});

Despliegue a Producción

Configuración de Entorno

// config/production.ts
export const productionConfig = {
keyServers: [
process.env.KEY_SERVER_1,
process.env.KEY_SERVER_2,
process.env.KEY_SERVER_3,
process.env.KEY_SERVER_4,
process.env.KEY_SERVER_5
],
threshold: 3,
network: 'mainnet',
suiRpc: process.env.SUI_RPC_URL,
walrusGateway: process.env.WALRUS_GATEWAY,
// Configuraciones de seguridad
maxDataSize: 1024 * 1024, // 1MB
sessionTimeout: 3600000, // 1 hora
retryAttempts: 3
};

Monitoreo y Logging

// utils/monitoring.ts
export class SealMonitoring {
static logEncryption(encryptionId: string, recipient: string) {
console.log(`[SEAL] Datos encriptados ${encryptionId} para ${recipient}`);
// Enviar a tu servicio de monitoreo
}

static logDecryption(encryptionId: string, success: boolean) {
console.log(`[SEAL] Desencriptación ${encryptionId}: ${success ? 'ÉXITO' : 'FALLÓ'}`);
}

static logKeyServerHealth(serverUrl: string, status: string) {
console.log(`[SEAL] Servidor de claves ${serverUrl}: ${status}`);
}
}

Recursos y Próximos Pasos

Documentación Oficial

Comunidad y Soporte

  • Discord de Sui: Únete al canal #seal para soporte comunitario
  • GitHub Issues: Reporta bugs y solicita funcionalidades
  • Foros de Desarrolladores: Foros comunitarios de Sui para discusiones

Temas Avanzados para Explorar

  1. Políticas de Acceso Personalizadas: Construir lógica de autorización compleja con contratos Move
  2. Integración Cross-Chain: Usar Seal con otras redes blockchain
  3. Gestión de Claves Empresarial: Configurar tu propia infraestructura de servidores de claves
  4. Auditoría y Cumplimiento: Implementar logging y monitoreo para entornos regulados

Aplicaciones de Ejemplo

  • App de Chat Seguro: Mensajería con encriptación extremo a extremo con Seal
  • Gestión de Documentos: Compartir documentos empresariales con controles de acceso
  • Gestión de Derechos Digitales: Distribución de contenido con políticas de uso
  • Análisis Preservando Privacidad: Flujos de trabajo de procesamiento de datos encriptados

Conclusión

Seal representa un cambio fundamental hacia hacer de la privacidad y la infraestructura de encriptación preocupaciones a nivel de infraestructura en Web3. Al combinar encriptación basada en identidad, seguridad threshold y control de acceso programable, proporciona a los desarrolladores herramientas poderosas para construir aplicaciones verdaderamente seguras y descentralizadas.

Las ventajas clave de construir con Seal incluyen:

  • Sin Punto Único de Falla: Los servidores de claves distribuidos eliminan autoridades centrales
  • Seguridad Programable: Las políticas de acceso basadas en smart contracts proporcionan autorización flexible
  • Amigable para Desarrolladores: El SDK TypeScript se integra perfectamente con herramientas Web3 existentes
  • Agnóstico de Almacenamiento: Funciona con Walrus, IPFS o cualquier solución de almacenamiento
  • Listo para Producción: Construido por Mysten Labs con estándares de seguridad empresarial

Ya sea que estés asegurando datos de usuarios, implementando modelos de suscripción o construyendo aplicaciones complejas multi-party, Seal proporciona las primitivas criptográficas y la infraestructura de control de acceso que necesitas para construir con confianza.

Comienza a construir hoy y únete al creciente ecosistema de desarrolladores haciendo de la privacidad una parte fundamental de la infraestructura pública.


¿Listo para empezar a construir? Instala @mysten/seal y comienza a experimentar con los ejemplos de este tutorial. La web descentralizada está esperando aplicaciones que pongan la privacidad y seguridad primero.

Seal en Sui: una capa programable de secretos con control de acceso on-chain

· 5 min de lectura
Dora Noda
Software Engineer

Las cadenas de bloques públicas dan a cada participante un libro mayor sincronizado y auditable, pero también exponen todos los datos por defecto. Seal, disponible en la red principal de Sui desde el 3 de septiembre de 2025, resuelve este dilema al combinar políticas on-chain con una gestión descentralizada de claves para que los desarrolladores decidan quién puede descifrar cada payload.

Resumen rápido

  • Qué es: Seal es una red de gestión de secretos que permite a los contratos inteligentes de Sui hacer cumplir políticas de descifrado on-chain mientras los clientes cifran datos con cifrado basado en identidades (IBE) y dependen de servidores de claves con umbral para derivar claves.
  • Por qué importa: En lugar de backends personalizados o scripts opacos fuera de la cadena, la privacidad y el control de acceso se convierten en primitivas de Move de primera clase. Los desarrolladores pueden almacenar los cifrados en cualquier lugar—Walrus es el compañero natural—y seguir controlando quién puede leer.
  • Quién se beneficia: Equipos que publican contenidos tokenizados, revelaciones con bloqueo temporal, mensajería privada o agentes de IA conscientes de políticas pueden conectarse al SDK de Seal y centrarse en la lógica del producto, no en el andamiaje criptográfico.

La lógica de políticas vive en Move

Los paquetes de Seal incluyen funciones Move seal_approve* que definen quién puede solicitar claves para una identidad determinada y bajo qué condiciones. Las políticas pueden combinar propiedad de NFT, listas blancas, bloqueos temporales o sistemas de roles personalizados. Cuando un usuario o agente solicita descifrar, los servidores de claves evalúan estas políticas mediante el estado de un nodo completo de Sui y solo aprueban si la cadena está de acuerdo.

Como las reglas de acceso forman parte de tu paquete on-chain, son transparentes, auditables y versionables junto con el resto del código de tus contratos inteligentes. Las actualizaciones de gobernanza se pueden desplegar como cualquier otra actualización de Move, con revisión comunitaria e historial en cadena.

La criptografía umbral gestiona las claves

Seal cifra los datos con identidades definidas por la aplicación. Un comité de servidores de claves independientes—elegido por el desarrollador—comparte el secreto maestro de IBE. Cuando la política aprueba la solicitud, cada servidor deriva una porción de clave para la identidad solicitada. Una vez que responde el quórum de t servidores, el cliente combina las porciones y obtiene una clave de descifrado utilizable.

Puedes ajustar el equilibrio entre disponibilidad y confidencialidad seleccionando a los miembros del comité (Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One o Enoki de Mysten) y el umbral. ¿Necesitas más disponibilidad? Elige un comité más grande con un umbral más bajo. ¿Buscas mayores garantías de privacidad? Reduce el quórum y apóyate en proveedores con permisos.

Experiencia para desarrolladores: SDK y claves de sesión

Seal ofrece un SDK de TypeScript (npm i @mysten/seal) que gestiona los flujos de cifrado y descifrado, el formato de identidades y los lotes de solicitudes. También emite claves de sesión para que las billeteras no reciban solicitudes constantes cuando una aplicación necesita acceso repetido. Para flujos avanzados, los contratos Move pueden solicitar descifrado on-chain mediante modos especializados, lo que permite ejecutar directamente en cadena lógica como liberaciones en custodia o subastas resistentes a MEV.

Como Seal es agnóstico al almacenamiento, los equipos pueden combinarlo con Walrus para blobs verificables, con IPFS o incluso con almacenes centralizados cuando sea necesario. El perímetro de cifrado—y su política de aplicación—viaja con los datos sin importar dónde resida el cifrado.

Diseñar con Seal: buenas prácticas

  • Modela el riesgo de disponibilidad: Umbrales como 2 de 3 o 3 de 5 se traducen directamente en garantías de tiempo activo. Los despliegues en producción deben mezclar proveedores, monitorear telemetría y negociar SLA antes de confiar flujos críticos.
  • Cuidado con la variación de estado: La evaluación de políticas depende de llamadas dry_run en nodos completos. Evita reglas basadas en contadores que cambian rápidamente u ordenamientos dentro del checkpoint para prevenir aprobaciones inconsistentes entre servidores.
  • Planifica la higiene de claves: Las claves derivadas viven en el cliente. Instrumenta registros, rota claves de sesión y considera cifrado envolvente—usa Seal para proteger una clave simétrica que cifra el payload mayor—para limitar el impacto si se compromete un dispositivo.
  • Arquitecta la rotación: El comité de un cifrado queda fijado en el momento del cifrado. Construye rutas de actualización que vuelvan a cifrar los datos con nuevos comités cuando necesites cambiar proveedores o ajustar supuestos de confianza.

Lo que viene

La hoja de ruta de Seal apunta a servidores MPC operados por validadores, herramientas de cliente tipo DRM y opciones KEM poscuánticas. Para los equipos que exploran agentes de IA, contenidos premium o flujos de datos regulados, la versión actual ya ofrece una guía clara: codifica tu política en Move, compón un comité de claves diverso y entrega experiencias cifradas que respeten la privacidad del usuario sin salir del perímetro de confianza de Sui.

Si estás evaluando Seal para tu próximo lanzamiento, comienza con un prototipo sencillo de política con NFT y un comité abierto de 2 de 3, y después itera hasta lograr la mezcla de proveedores y controles operativos que coincidan con el perfil de riesgo de tu aplicación.

Sui Blockchain: Ingeniando el Futuro de la IA, la Robótica y la Computación Cuántica

· 30 min de lectura
Dora Noda
Software Engineer

Sui blockchain ha emergido como la plataforma técnicamente más avanzada para cargas de trabajo computacionales de próxima generación, logrando 297.000 transacciones por segundo con una finalidad de 480 ms mientras integra criptografía resistente a la cuántica e infraestructura robótica construida a propósito. Liderada por el criptógrafo jefe Kostas Chalkias —quien cuenta con más de 50 publicaciones académicas y fue pionero en innovaciones criptográficas en el proyecto Diem de Meta—, Sui representa una ruptura arquitectónica fundamental con las blockchains heredadas, diseñada específicamente para habilitar agentes de IA autónomos, coordinación multi-robot y seguridad post-cuántica.

A diferencia de los competidores que adaptan blockchain para la computación avanzada, el modelo de datos centrado en objetos de Sui, el lenguaje de programación Move y el protocolo de consenso Mysticeti fueron diseñados desde su concepción para operaciones de IA paralelas, control robótico en tiempo real y agilidad criptográfica —capacidades validadas a través de implementaciones en vivo que incluyen más de 50 proyectos de IA, demostraciones de colaboración multi-robot y la primera ruta de actualización cuánticamente segura y retrocompatible del mundo para carteras de blockchain.

La revolucionaria base técnica de Sui hace posible lo imposible

La arquitectura de Sui rompe con los modelos tradicionales de blockchain basados en cuentas a través de tres innovaciones sinérgicas que la posicionan de manera única para aplicaciones de IA, robótica y cuánticas.

El protocolo de consenso Mysticeti logra un rendimiento sin precedentes a través de una arquitectura DAG no certificada, reduciendo la latencia del consenso a 390-650 ms (80% más rápido que su predecesor) mientras soporta un rendimiento sostenido de más de 200.000 TPS. Esto representa un avance fundamental: las blockchains tradicionales como Ethereum requieren de 12 a 15 segundos para la finalidad, mientras que la vía rápida de Sui para transacciones de un solo propietario se completa en solo 250 ms. Los múltiples líderes por ronda del protocolo y el mecanismo de compromiso implícito permiten bucles de decisión de IA en tiempo real y sistemas de control robótico que requieren retroalimentación en menos de un segundo —aplicaciones físicamente imposibles en cadenas de ejecución secuencial.

El modelo de datos centrado en objetos trata cada activo como un objeto direccionable de forma independiente con propiedad y versionado explícitos, lo que permite un análisis estático de dependencias antes de la ejecución. Esta elección arquitectónica elimina la sobrecarga de detección de conflictos retroactiva que afecta a los modelos de ejecución optimista, permitiendo que miles de agentes de IA realicen transacciones simultáneamente sin contención. Los objetos evitan el consenso por completo cuando son propiedad de una sola parte, ahorrando un 70% del tiempo de procesamiento para operaciones comunes. Para la robótica, esto significa que los robots individuales mantienen objetos propios para los datos de los sensores mientras se coordinan a través de objetos compartidos solo cuando es necesario, reflejando con precisión las arquitecturas de sistemas autónomos del mundo real.

El lenguaje de programación Move proporciona una seguridad orientada a recursos imposible en lenguajes basados en cuentas como Solidity. Los activos existen como tipos de primera clase que no pueden copiarse ni destruirse —solo moverse entre contextos—, lo que previene clases enteras de vulnerabilidades, incluidos ataques de reentrada, doble gasto y manipulación no autorizada de activos. El sistema de tipos lineal de Move y el soporte de verificación formal lo hacen particularmente adecuado para agentes de IA que gestionan activos valiosos de forma autónoma. Los Bloques de Transacciones Programables componen hasta 1.024 llamadas a funciones de forma atómica, lo que permite flujos de trabajo de IA complejos de varios pasos con consistencia garantizada.

Kostas Chalkias diseña la resistencia cuántica como ventaja competitiva

Kostas "Kryptos" Chalkias aporta una experiencia criptográfica inigualable a la estrategia de computación cuántica de Sui, habiendo sido autor del algoritmo Blockchained Post-Quantum Signature (BPQS), liderado la criptografía para la blockchain Diem de Meta y publicado más de 50 artículos revisados por pares citados más de 1.374 veces. Su avance de investigación de julio de 2025 demostró la primera ruta de actualización cuánticamente segura y retrocompatible para carteras de blockchain, aplicable a cadenas basadas en EdDSA, incluidas Sui, Solana, Near y Cosmos.

La visión de Chalkias posiciona la resistencia cuántica no como una preocupación lejana, sino como un diferenciador competitivo inmediato. Advirtió en enero de 2025 que "los gobiernos son muy conscientes de los riesgos que plantea la computación cuántica. Las 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 visión técnica: incluso si los usuarios conservan las claves privadas, es posible que no puedan generar pruebas de propiedad post-cuánticas sin exponer las claves a ataques cuánticos. La solución de Sui aprovecha las pruebas STARK de conocimiento cero para probar el conocimiento de las semillas de generación de claves sin revelar datos sensibles, una innovación criptográfica imposible en blockchains que carecen de agilidad incorporada.

El marco de agilidad criptográfica representa la filosofía de diseño distintiva de Chalkias. Sui utiliza banderas de 1 byte para distinguir esquemas de firma (Ed25519, ECDSA Secp256k1/r1, BLS12-381, multifirma, zkLogin), lo que permite el soporte a nivel de protocolo para nuevos algoritmos sin la sobrecarga de los contratos inteligentes o las bifurcaciones duras. Esta arquitectura permite transiciones "con solo pulsar un botón" a algoritmos post-cuánticos estandarizados por el NIST, incluidos CRYSTALS-Dilithium (firmas de 2.420 bytes) y FALCON (firmas de 666 bytes) cuando las amenazas cuánticas se materialicen. Chalkias diseñó múltiples rutas de migración: proactiva (las nuevas cuentas generan claves PQ en el momento de la creación), adaptativa (las pruebas STARK permiten la migración PQ desde semillas existentes) e híbrida (multifirma de tiempo limitado que combina claves clásicas y resistentes a la cuántica).

Su innovación zkLogin demuestra la creatividad criptográfica aplicada a la usabilidad. El sistema permite a los usuarios autenticarse a través de credenciales de Google, Facebook o Twitch utilizando pruebas de conocimiento cero Groth16 sobre curvas BN254, con sal controlada por el usuario que evita la correlación de identidad Web2-Web3. Las direcciones zkLogin incluyen consideraciones cuánticas desde el diseño: las pruebas de conocimiento de semillas basadas en STARK proporcionan seguridad post-cuántica incluso cuando las firmas JWT subyacentes pasan de RSA a alternativas basadas en retículos.

En Sui Basecamp 2025, Chalkias presentó aleatoriedad verificable nativa, túneles zk para lógica fuera de la cadena, transacciones relámpago (cero gas, cero latencia) y cápsulas del tiempo para acceso a datos futuros cifrados. Estas características impulsan simulaciones privadas de agentes de IA, aplicaciones de juegos de azar que requieren aleatoriedad confiable y juegos de póker de conocimiento cero, todo imposible sin primitivas criptográficas a nivel de protocolo. Su visión: "Un objetivo para Sui era convertirse en la primera blockchain en adoptar tecnologías post-cuánticas, mejorando así la seguridad y preparándose para futuros estándares regulatorios."

La infraestructura de agentes de IA alcanza la madurez de producción en Sui

Sui alberga el ecosistema de agentes de IA más completo de la industria blockchain con más de 50 proyectos que abarcan infraestructura, frameworks y aplicaciones, todos aprovechando la ejecución paralela y la finalidad en menos de un segundo de Sui para operaciones autónomas en tiempo real.

Atoma Network se lanzó en la mainnet de Sui en diciembre de 2024 como la primera capa de inferencia de IA totalmente descentralizada, posicionándose como el "hiperescalador descentralizado para IA de código abierto". Todo el procesamiento ocurre en Entornos de Ejecución Confiables (TEEs) asegurando total privacidad y resistencia a la censura mientras mantiene la compatibilidad de API con los endpoints de OpenAI. La aplicación de chat Utopia demuestra una IA lista para producción que preserva la privacidad con un rendimiento que iguala a ChatGPT, liquidando pagos y validación a través de la finalidad en menos de un segundo de Sui. Atoma permite la gestión de carteras DeFi, la moderación de contenido en redes sociales y aplicaciones de asistente personal, casos de uso que requieren tanto inteligencia de IA como liquidación en blockchain, imposibles de lograr en cadenas más lentas.

OpenGraph Labs logró un avance técnico como el primer sistema de inferencia de IA totalmente en cadena diseñado específicamente para agentes de IA. Su SDK TensorflowSui automatiza la implementación de modelos de ML de Web2 (TensorFlow, PyTorch) en la blockchain de Sui, almacenando datos de entrenamiento en el almacenamiento descentralizado Walrus mientras ejecuta inferencias utilizando Bloques de Transacciones Programables. OpenGraph ofrece tres enfoques de inferencia flexibles: inferencia PTB para cálculos críticos que requieren atomicidad, transacciones divididas para optimización de costos y combinaciones híbridas personalizadas por caso de uso. Esta arquitectura elimina los riesgos de IA de "caja negra" a través de procesos de inferencia totalmente verificables y auditables con una propiedad algorítmica claramente definida, algo crítico para industrias reguladas que requieren IA explicable.

Talus Network se lanzó en Sui en febrero de 2025 con el framework Nexus que permite a los desarrolladores construir agentes de IA componibles que ejecutan flujos de trabajo directamente en la cadena. La plataforma Idol.fun de Talus demuestra agentes de IA orientados al consumidor como entidades tokenizadas que operan de forma autónoma 24/7, tomando decisiones en tiempo real aprovechando conjuntos de datos almacenados en Walrus para el sentimiento del mercado, estadísticas DeFi y tendencias sociales. Las aplicaciones de ejemplo incluyen la gestión dinámica de perfiles NFT, agentes de estrategia de liquidez DeFi que cargan modelos en tiempo real y agentes de detección de fraude que analizan patrones de transacciones históricas desde puntos de control inmutables de Sui.

La asociación con Alibaba Cloud anunciada en agosto de 2025 integró asistentes de codificación de IA en la plataforma de desarrollo ChainIDE con soporte multilingüe (inglés, chino, coreano). Las características incluyen la generación de código Move a partir de lenguaje natural, autocompletado inteligente, detección de vulnerabilidades de seguridad en tiempo real y generación automatizada de documentación, lo que reduce las barreras para el 60% del objetivo de desarrolladores de Sui que no hablan inglés. Esta asociación valida el posicionamiento de Sui como la plataforma de desarrollo de IA, no simplemente una plataforma de implementación de IA.

Las transacciones patrocinadas de Sui eliminan la fricción del pago de gas para los agentes de IA: los desarrolladores pueden cubrir las tarifas de transacción, lo que permite a los agentes operar sin tener tokens SUI. La denominación MIST (1 SUI = 1.000 millones de MIST) permite micropagos tan pequeños como fracciones de centavo, perfectos para servicios de IA de pago por inferencia. Con costos de transacción promedio de alrededor de $0,0023, los agentes de IA pueden ejecutar miles de operaciones diarias por centavos, haciendo que las economías de agentes autónomos sean económicamente viables.

La colaboración multi-robot demuestra la ventaja de coordinación en tiempo real de Sui

Sui demostró el primer sistema de colaboración multi-robot de la industria blockchain utilizando el consenso Mysticeti, validado por el análisis exhaustivo de Tiger Research de 2025. El sistema permite a los robots compartir un estado consistente en entornos distribuidos mientras mantiene la Tolerancia a Fallos Bizantinos, asegurando el consenso incluso cuando los robots funcionan mal o son comprometidos por adversarios.

La arquitectura técnica aprovecha el modelo de objetos de Sui, donde los robots existen como objetos programables con metadatos, propiedad y capacidades. Las tareas se asignan a objetos de robot específicos con contratos inteligentes que automatizan las reglas de secuenciación y asignación de recursos. El sistema mantiene la fiabilidad sin servidores centrales, con propuestas de bloques paralelas de múltiples validadores que evitan puntos únicos de fallo. La finalidad de transacción en menos de un segundo permite bucles de ajuste en tiempo real: los robots reciben confirmaciones de tareas y actualizaciones de estado en menos de 400 ms, lo que coincide con los requisitos del sistema de control para una operación autónoma receptiva.

Las pruebas físicas con robots con forma de perro ya demostraron su viabilidad, con equipos de NASA, Meta y Uber desarrollando aplicaciones de robótica basadas en Sui. La capacidad única de "modo sin internet" de Sui —operando a través de ondas de radio sin conectividad a internet estable— proporciona ventajas revolucionarias para implementaciones rurales en África, Asia rural y escenarios de emergencia. Esta capacidad offline existe exclusivamente en Sui entre las principales blockchains, validada por pruebas durante cortes de energía en España/Portugal.

La asociación con 3DOS anunciada en septiembre de 2024 valida las capacidades de robótica de fabricación de Sui a escala. 3DOS integró más de 79.909 impresoras 3D en más de 120 países como socio exclusivo de blockchain de Sui, creando una red de "Uber para impresión 3D" que permite la fabricación peer-to-peer. Entre los clientes notables se incluyen John Deere, Google, MIT, Harvard, Bosch, el Ejército Británico, la Marina de los EE. UU., la Fuerza Aérea de los EE. UU. y la NASA, lo que demuestra la confianza de nivel empresarial en la infraestructura de Sui. El sistema permite a los robots pedir e imprimir piezas de repuesto de forma autónoma a través de la automatización de contratos inteligentes, facilitando la autorreparación de robots con una intervención humana casi nula. Esto aborda el mercado global de fabricación de 15,6 billones de dólares a través de la producción bajo demanda, eliminando inventario, residuos y envíos internacionales.

La Tolerancia a Fallos Bizantinos de Sui resulta crítica para aplicaciones de robótica de seguridad crítica. El mecanismo de consenso tolera hasta f robots defectuosos/maliciosos en un sistema 3f+1, asegurando que las flotas de vehículos autónomos, los robots de almacén y los sistemas de fabricación mantengan la coordinación a pesar de los fallos individuales. Los contratos inteligentes imponen restricciones de seguridad y límites operativos, con registros de auditoría inmutables que proporcionan responsabilidad para las decisiones autónomas, requisitos imposibles de cumplir con servidores de coordinación centralizados vulnerables a puntos únicos de fallo.

La hoja de ruta de resistencia cuántica ofrece superioridad criptográfica

La estrategia de computación cuántica de Sui representa el único enfoque integral y proactivo de la industria blockchain alineado con los mandatos del NIST que exigen la deprecación de algoritmos clásicos para 2030 y la estandarización completa resistente a la cuántica para 2035.

La investigación innovadora de Chalkias de julio de 2025 demostró que las cadenas basadas en EdDSA, incluida Sui, pueden implementar actualizaciones de carteras cuánticamente seguras sin bifurcaciones duras, cambios de dirección o congelación de cuentas a través de pruebas de conocimiento cero que demuestran el conocimiento de la semilla. Esto permite una migración segura incluso para cuentas inactivas, resolviendo la amenaza existencial que enfrentan las blockchains donde millones de carteras "podrían ser vaciadas instantáneamente" una vez que lleguen las computadoras cuánticas. La innovación técnica utiliza pruebas STARK (seguridad basada en hash resistente a la cuántica) para probar el conocimiento de las semillas de generación de claves EdDSA sin exponer datos sensibles, permitiendo a los usuarios establecer la propiedad de claves PQ vinculada a direcciones existentes.

La arquitectura de agilidad criptográfica de Sui permite múltiples estrategias de transición: proactiva (las claves PQ firman claves públicas PreQ en la creación), adaptativa (las pruebas STARK migran direcciones existentes) e híbrida (multifirma de tiempo limitado con claves clásicas y PQ). El protocolo soporta el despliegue inmediato de algoritmos estandarizados por el NIST, incluyendo CRYSTALS-Dilithium (ML-DSA), FALCON (FN-DSA) y SPHINCS+ (SLH-DSA) para seguridad post-cuántica basada en retículos y hash. Las firmas BLS de los validadores transicionan a alternativas basadas en retículos, las funciones hash se actualizan de salidas de 256 bits a 384 bits para resistencia a colisiones resistente a la cuántica, y los circuitos zkLogin migran de Groth16 a pruebas de conocimiento cero basadas en STARK.

El framework Nautilus lanzado en junio de 2025 proporciona computación segura fuera de la cadena utilizando TEEs (Trusted Execution Environments) autogestionados, actualmente compatible con AWS Nitro Enclaves y con futura compatibilidad con Intel TDX y AMD SEV. Para aplicaciones de IA, Nautilus permite la inferencia privada de IA con atestaciones criptográficas verificadas en cadena, resolviendo la tensión entre la eficiencia computacional y la verificabilidad. Los socios de lanzamiento, incluidos Bluefin (emparejamiento de órdenes basado en TEE en <1 ms), TensorBlock (infraestructura de agentes de IA) y OpenGradient, demuestran la preparación para la producción de computación resistente a la cuántica que preserva la privacidad.

El análisis comparativo revela la ventaja cuántica de Sui: Ethereum permanece en fase de planificación, con Vitalik Buterin afirmando que la resistencia cuántica está "al menos a una década de distancia", requiriendo bifurcaciones duras y consenso de la comunidad. Solana lanzó Winternitz Vault en enero de 2025 como una característica opcional de firma basada en hash que requiere la participación del usuario, no una implementación a nivel de protocolo. Otras blockchains importantes (Aptos, Avalanche, Polkadot) permanecen en fase de investigación sin plazos de implementación concretos. Solo Sui diseñó la agilidad criptográfica como un principio fundamental que permite transiciones rápidas de algoritmos sin batallas de gobernanza o divisiones de red.

La síntesis de la arquitectura técnica crea capacidades emergentes

Los componentes arquitectónicos de Sui interactúan sinérgicamente para crear capacidades que superan la suma de las características individuales, una característica que distingue a las plataformas verdaderamente innovadoras de las mejoras incrementales.

El modelo de recursos del lenguaje Move combinado con la ejecución paralela de objetos permite un rendimiento sin precedentes para enjambres de agentes de IA. Las blockchains tradicionales que utilizan modelos basados en cuentas requieren ejecución secuencial para prevenir condiciones de carrera, limitando la coordinación de agentes de IA a cuellos de botella de un solo hilo. La declaración explícita de dependencias de Sui a través de referencias de objetos permite a los validadores identificar operaciones independientes antes de la ejecución, programando miles de transacciones de agentes de IA simultáneamente en los núcleos de la CPU. Esta paralelización del acceso al estado (frente a la ejecución optimista que requiere detección de conflictos) proporciona un rendimiento predecible sin fallos de transacción retroactivos, algo crítico para los sistemas de IA que requieren garantías de fiabilidad.

Los Bloques de Transacciones Programables amplifican la composibilidad de Move al permitir hasta 1.024 llamadas a funciones heterogéneas en transacciones atómicas. Los agentes de IA pueden ejecutar flujos de trabajo complejos —intercambiar tokens, actualizar datos de oráculos, activar inferencia de aprendizaje automático, acuñar NFTs, enviar notificaciones—, todo garantizado para tener éxito o fallar en conjunto. Esta composición heterogénea traslada la lógica de los contratos inteligentes al nivel de la transacción, reduciendo drásticamente los costos de gas y aumentando la flexibilidad. Para la robótica, los PTB permiten operaciones atómicas de varios pasos como "verificar inventario, pedir piezas, autorizar pago, actualizar estado" con garantías criptográficas de consistencia.

La vía rápida de omisión de consenso para objetos de un solo propietario crea un modelo de rendimiento de dos niveles que se adapta perfectamente a los patrones de acceso de IA/robótica. Los robots individuales mantienen el estado privado (lecturas de sensores, parámetros operativos) como objetos propios procesados en 250 ms sin consenso del validador. Los puntos de coordinación (colas de tareas, grupos de recursos) existen como objetos compartidos que requieren un consenso de 390 ms. Esta arquitectura refleja los sistemas autónomos del mundo real donde los agentes mantienen el estado local pero se coordinan a través de recursos compartidos; el modelo de objetos de Sui proporciona primitivas nativas de blockchain que coinciden con estos patrones de forma natural.

zkLogin resuelve la fricción de incorporación que impide la adopción masiva de agentes de IA. La blockchain tradicional requiere que los usuarios gestionen frases semilla y claves privadas, lo que es cognitivamente exigente y propenso a errores. zkLogin permite la autenticación a través de credenciales OAuth familiares (Google, Facebook, Twitch) con sal controlada por el usuario que evita la correlación de identidad Web2-Web3. Los agentes de IA pueden operar bajo autenticación Web2 mientras mantienen la seguridad de la blockchain, reduciendo drásticamente las barreras para las aplicaciones de consumo. Las más de 10 dApps que ya integran zkLogin demuestran la viabilidad práctica para audiencias no nativas de cripto.

El posicionamiento competitivo revela liderazgo técnico y crecimiento del ecosistema

El análisis comparativo entre las principales blockchains (Solana, Ethereum, Aptos, Avalanche, Polkadot) revela la superioridad técnica de Sui para cargas de trabajo de computación avanzada, equilibrada con la madurez del ecosistema de Ethereum y la adopción actual de DePIN de Solana.

Las métricas de rendimiento establecen a Sui como el líder en rendimiento con 297.000 TPS probados en 100 validadores manteniendo una finalidad de 480 ms, frente a los 65.000-107.000 TPS teóricos de Solana (3.000-4.000 sostenidos) y los 15-30 TPS de la capa base de Ethereum. Aptos logra 160.000 TPS teóricos con una arquitectura similar basada en Move pero con diferentes modelos de ejecución. Para cargas de trabajo de IA que requieren decisiones en tiempo real, la finalidad de 480 ms de Sui permite bucles de respuesta inmediatos imposibles con la finalidad de 12-15 minutos de Ethereum o incluso la congestión ocasional de la red de Solana (75% de fallos de transacción en abril de 2024 durante la carga máxima).

El análisis de resistencia cuántica muestra a Sui como la única blockchain con criptografía resistente a la cuántica diseñada en su arquitectura central desde el inicio. Ethereum aborda la cuántica en la fase de hoja de ruta "The Splurge", pero Vitalik Buterin estima un 20% de probabilidad de que la cuántica rompa las criptomonedas para 2030, basándose en planes de "bifurcación de recuperación" de emergencia reactivos en lugar de proactivos. Winternitz Vault de Solana proporciona protección cuántica opcional que requiere la participación del usuario, no seguridad automática en toda la red. Aptos, Avalanche y Polkadot permanecen en fase de investigación sin plazos concretos. La agilidad criptográfica de Sui con múltiples rutas de migración, zkLogin basado en STARK y una hoja de ruta alineada con NIST la posiciona como la única blockchain lista para las transiciones post-cuánticas obligatorias de 2030/2035.

Los ecosistemas de agentes de IA muestran a Solana liderando actualmente la adopción con herramientas maduras (SendAI Agent Kit, ElizaOS) y la comunidad de desarrolladores más grande, pero Sui demuestra una capacidad técnica superior a través de una capacidad de 300.000 TPS, latencia sub-segundo y más de 50 proyectos, incluidas plataformas de producción (mainnet de Atoma, Talus Nexus, inferencia en cadena de OpenGraph). Ethereum se centra en estándares de IA institucionales (ERC-8004 para identidad/confianza de IA), pero la capa base de 15-30 TPS limita las aplicaciones de IA en tiempo real a soluciones de Capa 2. La asociación con Alibaba Cloud que posiciona a Sui como la plataforma de desarrollo de IA (no simplemente una plataforma de implementación) señala una diferenciación estratégica de las blockchains puramente financieras.

Las capacidades robóticas existen exclusivamente en Sui entre las principales blockchains. Ningún competidor demuestra infraestructura de colaboración multi-robot, coordinación tolerante a fallos bizantinos o operación offline en "modo sin internet". El análisis de Tiger Research concluye que "blockchain puede ser una infraestructura más adecuada para robots que para humanos" dada la capacidad de los robots para aprovechar la coordinación descentralizada sin confianza centralizada. Con Morgan Stanley proyectando mil millones de robots humanoides para 2050, la infraestructura robótica construida específicamente para Sui crea una ventaja de primer movimiento en la economía robótica emergente donde los sistemas autónomos requieren identidad, pagos, contratos y coordinación, primitivas que Sui proporciona de forma nativa.

Las ventajas del lenguaje de programación Move posicionan tanto a Sui como a Aptos por encima de las cadenas basadas en Solidity para aplicaciones complejas que requieren seguridad. El modelo orientado a recursos de Move previene clases de vulnerabilidades imposibles de corregir en Solidity, evidenciado por los más de 1.100 millones de dólares perdidos en exploits en 2024 en Ethereum. El soporte de verificación formal, el sistema de tipos lineal y las abstracciones de activos de primera clase hacen que Move sea particularmente adecuado para agentes de IA que gestionan activos valiosos de forma autónoma. La variante centrada en objetos de Sui Move (frente a Diem Move basada en cuentas) permite ventajas de ejecución paralela no disponibles en Aptos a pesar de la herencia del lenguaje compartido.

Implementaciones en el mundo real validan las capacidades técnicas

Las implementaciones en producción de Sui demuestran que la plataforma está pasando del potencial técnico a la utilidad práctica en los dominios de IA, robótica y cuántica.

La madurez de la infraestructura de IA muestra una clara tracción con el lanzamiento de la mainnet de Atoma Network en diciembre de 2024 que sirve inferencia de IA en producción, el despliegue del framework Nexus de Talus en febrero de 2025 que permite flujos de trabajo de agentes componibles, y la ronda de financiación de 13 millones de dólares de Swarm Network respaldada por Kostas Chalkias vendiendo más de 10.000 licencias de agentes de IA en Sui. La asociación con Alibaba Cloud proporciona validación de nivel empresarial con asistentes de codificación de IA integrados en las herramientas de desarrollo, demostrando un compromiso estratégico más allá de las aplicaciones especulativas. OpenGraph Labs ganando el primer lugar en el Sui AI Typhoon Hackathon con inferencia de ML en cadena señala una innovación técnica reconocida por jueces expertos.

La robótica de fabricación alcanzó escala comercial a través de la red de 79.909 impresoras de 3DOS en más de 120 países, sirviendo a la NASA, la Marina de los EE. UU., la Fuerza Aérea de los EE. UU., John Deere y Google. Esto representa la red de fabricación integrada en blockchain más grande a nivel mundial, procesando más de 4,2 millones de piezas con más de 500.000 usuarios. El modelo peer-to-peer que permite a los robots pedir piezas de repuesto de forma autónoma demuestra la automatización de contratos inteligentes, eliminando la sobrecarga de coordinación a escala industrial —prueba de concepto validada por exigentes clientes gubernamentales y aeroespaciales que requieren fiabilidad y seguridad.

Las métricas financieras muestran una creciente adopción con 538 millones de dólares en TVL, 17,6 millones de carteras activas mensuales (pico de febrero de 2025) y una capitalización de mercado del token SUI que supera los 16 mil millones de dólares. Mysten Labs logró una valoración de más de 3 mil millones de dólares respaldada por a16z, Binance Labs, Coinbase Ventures y Jump Crypto, validación institucional del potencial técnico. Los bancos suizos (Sygnum, Amina Bank) que ofrecen custodia y comercio de Sui proporcionan rampas de acceso a las finanzas tradicionales, mientras que los productos institucionales de Grayscale, Franklin Templeton y VanEck señalan un reconocimiento generalizado.

El crecimiento del ecosistema de desarrolladores demuestra sostenibilidad con herramientas completas (SDKs de TypeScript, Rust, Python, Swift, Dart, Golang), asistentes de codificación de IA en ChainIDE y programas de hackatones activos donde el 50% de los ganadores se centraron en aplicaciones de IA. Los 122 validadores activos en la mainnet proporcionan una descentralización adecuada mientras mantienen el rendimiento, equilibrando la seguridad con el rendimiento mejor que las alternativas altamente centralizadas.

La visión estratégica posiciona a Sui para la era de la convergencia

Kostas Chalkias y el liderazgo de Mysten Labs articulan una visión coherente a largo plazo que distingue a Sui de sus competidores centrados en casos de uso estrechos o mejoras iterativas.

La audaz predicción de Chalkias de que "eventualmente, blockchain superará incluso a Visa en velocidad de transacción. Será la norma. No veo cómo podemos escapar de esto" señala confianza en la trayectoria técnica respaldada por decisiones arquitectónicas que habilitan ese futuro. Su afirmación de que Mysten Labs "podría superar lo que Apple es hoy" refleja una ambición basada en construir infraestructura fundamental para la computación de próxima generación en lugar de aplicaciones DeFi incrementales. La decisión de nombrar a su hijo "Kryptos" (griego para "secreto/oculto") simboliza el compromiso personal con la innovación criptográfica como infraestructura civilizatoria.

La estrategia de tres pilares que integra IA, robótica y computación cuántica crea ventajas que se refuerzan mutuamente. La criptografía resistente a la cuántica permite la seguridad de activos a largo plazo para agentes de IA que operan de forma autónoma. La finalidad en menos de un segundo soporta bucles de control robótico en tiempo real. La ejecución paralela permite que miles de agentes de IA se coordinen simultáneamente. El modelo de objetos proporciona una abstracción natural tanto para el estado del agente de IA como para la representación del dispositivo robot. Esta coherencia arquitectónica distingue el diseño de plataforma con propósito de las características añadidas.

Las presentaciones tecnológicas de Sui Basecamp 2025 demuestran innovación continua con aleatoriedad verificable nativa (elimina dependencias de oráculos para inferencia de IA), túneles zk que permiten videollamadas privadas directamente en Sui, transacciones relámpago para operaciones sin gas durante emergencias y cápsulas del tiempo para acceso a datos futuros cifrados. Estas características abordan problemas reales de los usuarios (privacidad, fiabilidad, accesibilidad) en lugar de ejercicios académicos, con aplicaciones claras para agentes de IA que requieren aleatoriedad confiable, sistemas robóticos que necesitan operación offline y cifrado resistente a la cuántica para datos sensibles.

El posicionamiento como "capa de coordinación para una amplia gama de aplicaciones", desde la gestión de datos sanitarios hasta la propiedad de datos personales y la robótica, refleja las ambiciones de la plataforma más allá de la especulación financiera. La identificación de Chalkias de la ineficiencia de los datos sanitarios como un problema que requiere una base de datos común muestra un pensamiento sobre la infraestructura social en lugar de nichos estrechos de entusiastas de blockchain. Esta visión atrae a laboratorios de investigación, startups de hardware y gobiernos, audiencias que buscan infraestructura fiable para proyectos a largo plazo, no la agricultura de rendimiento especulativa.

La hoja de ruta técnica ofrece un cronograma de ejecución accionable

La hoja de ruta de desarrollo de Sui proporciona hitos concretos que demuestran la progresión de la visión a la implementación en los tres dominios de enfoque.

El cronograma de resistencia cuántica se alinea con los mandatos del NIST: 2025-2027 completa la infraestructura y las pruebas de agilidad criptográfica, 2028-2030 introduce actualizaciones de protocolo para firmas Dilithium/FALCON con operación híbrida PreQ-PQ, 2030-2035 logra la transición post-cuántica completa deprecando algoritmos clásicos. Las múltiples rutas de migración (proactiva, adaptativa, híbrida) proporcionan flexibilidad para diferentes segmentos de usuarios sin forzar una única estrategia de adopción. Las actualizaciones de la función hash a salidas de 384 bits y la investigación zkLogin PQ-zkSNARK avanzan en paralelo, asegurando una preparación cuántica integral en lugar de parches fragmentados.

La expansión de la infraestructura de IA muestra hitos claros con el lanzamiento de la mainnet de Walrus (Q1 2025) que proporciona almacenamiento descentralizado para modelos de IA, el framework Talus Nexus que permite flujos de trabajo de agentes componibles (despliegue en febrero de 2025) y el framework Nautilus TEE que se expande a Intel TDX y AMD SEV más allá del soporte actual de AWS Nitro Enclaves. La hoja de ruta de la asociación con Alibaba Cloud incluye soporte de idiomas ampliado, una integración más profunda de ChainIDE y días de demostración en Hong Kong, Singapur y Dubái dirigidos a comunidades de desarrolladores. El explorador de inferencia en cadena de OpenGraph y la maduración del SDK TensorflowSui proporcionan herramientas prácticas para desarrolladores de IA más allá de los frameworks teóricos.

El avance de las capacidades robóticas progresa desde demostraciones de colaboración multi-robot hasta implementaciones de producción con la expansión de la red 3DOS, capacidades de transacción por ondas de radio en "modo sin internet" y zkTunnels que permiten comandos de robot sin gas. La arquitectura técnica que soporta la Tolerancia a Fallos Bizantinos, bucles de coordinación en menos de un segundo y pagos autónomos M2M existe hoy en día; las barreras de adopción son educativas y de construcción de ecosistemas, más que limitaciones técnicas. La participación de exalumnos de NASA, Meta y Uber señala un talento de ingeniería serio que aborda desafíos robóticos del mundo real en lugar de proyectos de investigación académica.

Las mejoras del protocolo incluyen refinamientos del consenso Mysticeti que mantienen una ventaja de reducción de latencia del 80%, escalado horizontal a través de la ejecución multi-máquina Pilotfish y optimización del almacenamiento para un estado creciente. El sistema de puntos de control (cada ~3 segundos) proporciona instantáneas verificables para datos de entrenamiento de IA y registros de auditoría robóticos. La reducción del tamaño de las transacciones a formatos preestablecidos de un solo byte reduce los requisitos de ancho de banda para dispositivos IoT. La expansión de transacciones patrocinadas elimina la fricción del gas para aplicaciones de consumo que requieren una UX fluida similar a la Web2.

La excelencia técnica posiciona a Sui para el dominio de la computación avanzada

El análisis exhaustivo de la arquitectura técnica, la visión de liderazgo, las implementaciones en el mundo real y el posicionamiento competitivo revela a Sui como la plataforma blockchain excepcionalmente preparada para la convergencia de la IA, la robótica y la computación cuántica.

Sui logra superioridad técnica a través de métricas de rendimiento medidas: 297.000 TPS con 480 ms de finalidad supera a todos los principales competidores, permitiendo la coordinación de agentes de IA en tiempo real y el control robótico imposible en cadenas más lentas. El modelo de datos centrado en objetos combinado con la seguridad del lenguaje Move proporciona ventajas en el modelo de programación que previenen clases de vulnerabilidades que afectan a las arquitecturas basadas en cuentas. La agilidad criptográfica diseñada desde el inicio —no adaptada— permite transiciones resistentes a la cuántica sin bifurcaciones duras ni batallas de gobernanza. Estas capacidades existen hoy en producción en la mainnet con 122 validadores, no como whitepapers teóricos o hojas de ruta distantes.

El liderazgo visionario a través de las más de 50 publicaciones de Kostas Chalkias, 8 patentes estadounidenses e innovaciones criptográficas (zkLogin, BPQS, Winterfell STARK, HashWires) proporciona una base intelectual que distingue a Sui de competidores técnicamente competentes pero poco imaginativos. Su investigación innovadora en computación cuántica (julio de 2025), el apoyo a la infraestructura de IA (respaldo de Swarm Network) y la comunicación pública (Token 2049, Korea Blockchain Week, London Real) establecen un liderazgo intelectual que atrae a desarrolladores de primer nivel y socios institucionales. La voluntad de diseñar para plazos de 2030+ en lugar de métricas trimestrales demuestra el pensamiento estratégico a largo plazo requerido para la infraestructura de la plataforma.

La validación del ecosistema a través de implementaciones en producción (inferencia de IA en la mainnet de Atoma, red de 79.909 impresoras de 3DOS, frameworks de agentes de Talus) demuestra que las capacidades técnicas se traducen en utilidad en el mundo real. Las asociaciones institucionales (Alibaba Cloud, custodia de bancos suizos, productos de Grayscale/Franklin Templeton) señalan un reconocimiento generalizado más allá de los entusiastas nativos de blockchain. Las métricas de crecimiento de desarrolladores (50% de los ganadores de hackatones en IA, cobertura completa de SDK, asistentes de codificación de IA) demuestran una expansión sostenible del ecosistema que apoya la adopción a largo plazo.

El posicionamiento estratégico como infraestructura blockchain para la economía robótica, sistemas financieros resistentes a la cuántica y coordinación autónoma de agentes de IA crea una propuesta de valor diferenciada frente a competidores centrados en mejoras incrementales a casos de uso existentes de blockchain. Con Morgan Stanley proyectando mil millones de robots humanoides para 2050, el NIST exigiendo algoritmos resistentes a la cuántica para 2030, y McKinsey pronosticando un 40% de ganancias de productividad de la IA agentica, las capacidades técnicas de Sui se alinean precisamente con las macrotendencias tecnológicas que requieren infraestructura descentralizada.

Para las organizaciones que construyen aplicaciones de computación avanzada en blockchain, Sui ofrece capacidades técnicas inigualables (297K TPS, 480 ms de finalidad), una arquitectura resistente a la cuántica a prueba de futuro (la única blockchain diseñada para la cuántica desde su concepción), infraestructura robótica probada (la única que ha demostrado colaboración multi-robot), un modelo de programación superior (seguridad y expresividad del lenguaje Move) y un rendimiento en tiempo real que permite aplicaciones de IA/robótica físicamente imposibles en cadenas de ejecución secuencial. La plataforma representa no una mejora incremental, sino un replanteamiento arquitectónico fundamental para la próxima década de blockchain.

La base de Sui preparada para la computación cuántica para la inteligencia autónoma

· 33 min de lectura
Dora Noda
Software Engineer

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.

IA verificable en movimiento: cómo los zk-SNARKs dinámicos de Lagrange Labs habilitan la confianza continua

· 7 min de lectura
Dora Noda
Software Engineer

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”.

Red MPC Ika respaldada por Sui – Evaluación técnica y de inversión exhaustiva

· 49 min de lectura

title: Red MPC Ika respaldada por Sui – Evaluación técnica y de inversión exhaustiva keywords:

Ika Network

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.

title: Perspectiva de Negocio e Inversión description: Un análisis profundo del equipo fundador de Ika, sus rondas de financiación, la economía de tokens (tokenomics) y su estrategia de salida al mercado en el ecosistema Sui. image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=Perspectiva%20de%20Negocio%20e%20Inversi%C3%B3n%22%0Akeywords%3A%0A%20%20-%20Ika%0A%20%20-%20infraestructura%20blockchain%0A%20%20-%20red%20MPC%0A%20%20-%20Sui%0A%20%20-%20token%C3%B3mica%0A%20%20-%20inversi%C3%B3n%20Web3%0A%20%20-%20dWallet%20Labs%0Atags%3A%20%5Bblockchain%2C%20web3%5D%0Aauthors%3A%20%5BBlockEden.xyz%20Team%5D%0A%0A%23%23%20Perspectiva%20de%20Negocio%20e%20Inversi%C3%B3n%0A%0A%23%23%23%20Equipo%20Fundador%20y%20Antecedentes%0A%0AIka%20fue%20fundada%20por%20un%20equipo%20de%20especialistas%20veteranos%20en%20criptograf%C3%ADa%20y%20blockchain%2C%20con%20sede%20principal%20en%20Israel.%20El%20creador%20y%20CEO%20del%20proyecto%20es%20**Omer%20Sadika**%2C%20un%20emprendedor%20con%20una%20s%C3%B3lida%20trayectoria%20en%20el%20espacio%20de%20la%20seguridad%20criptogr%C3%A1fica.%20Omer%20cofund%C3%B3%20previamente%20**Odsy%20Network**%2C%20otro%20proyecto%20centrado%20en%20la%20infraestructura%20de%20billeteras%20descentralizadas%2C%20y%20es%20el%20Fundador%20%2F%20CEO%20de%20dWallet%20Labs%2C%20la%20empresa%20detr%C3%A1s%20de%20Ika.%20Su%20formaci%C3%B3n%20incluye%20el%20paso%20por%20Y%20Combinator%20(exalumno%20de%20YC) y un enfoque en ciberseguridad y sistemas distribuidos. La experiencia de Omer con Odsy y dWallet Labs informó directamente la visión de Ika; en esencia, Ika puede verse como una evolución del concepto de "billetera descentralizada dinámica" en el que trabajó Odsy, ahora implementado como una red MPC en Sui.

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 **21millonesenmuˊltiplesrondas.Larondasemillainicialdelproyectoenagostode2022fuede21 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.5millonesenloquepareceserunaSerieAorondaestrateˊgica,supuestamenteconunavaloracioˊncercanaalos7.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 21millonesycimentoˊunaestrechaalineacioˊnconlablockchainSui.AunqueelmontoexactoqueinvirtioˊlaSuiFoundationnofuereveladopuˊblicamente,estaˊclaroquesetratoˊdeunrespaldosignificativo,probablementedelordendevariosmillonesdeUSD.ElapoyodelaSuiFoundationnoessolofinanciero;tambieˊnsignificaqueIkarecibeunasoˊlidaasistenciaparasaliralmercadodentrodelecosistemaSui(alcanceadesarrolladores,soportedeintegracioˊn,marketing,etc.).Seguˊnloscomunicadosdeprensa,"Ika...anuncioˊunainversioˊnestrateˊgicadelaSuiFoundation,elevandosufinanciacioˊntotalamaˊsde21 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 XX, hasta ~ X/3X / 3 de la participación podría ser maliciosa sin romper las garantías de la red). Los stakers (delegadores) son incentivados 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):

AspectoIka (Red MPC Paralela)Lit Protocol (PKI y Computación)Threshold Network (tBTC y TSS)Zama (Red FHE)
Lanzamiento y EstadoFundada 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 UsoInteroperabilidad 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.
ArquitecturaFork 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 Seguridad2PC-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.
RendimientoLatencia 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ónAlta: 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:utilizadoparagobernanzayquizaˊstarifasporserviciosavanzados.LasLitActionssonactualmentegratuitasparalosdesarrolladores(singas);alargoplazopodrıˊaintroducirseunmodelodetarifas.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:stakedporlosnodos,gobiernalatesorerıˊadelaDAOylasactualizacionesdelprotocolo.LosnodosgananenT**: 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 RespaldosFundació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.

Privacidad Programable en Blockchain: Computación Fuera de Cadena con Verificación en Cadena

· 51 min de lectura
Dora Noda
Software Engineer

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:

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

title: "Programmable Privacy in Blockchain: Off‑Chain Compute with On‑Chain Verification" tags: [blockchain, privacy, cryptography, FHE, ZK] keywords: [ programmable privacy, blockchain, off-chain compute, on-chain verification, FHE-VM, ZK coprocessors, ] description: "Explore how programmable privacy in blockchain leverages Fully Homomorphic Encryption and Zero-Knowledge Coprocessors to enable secure off-chain computation with on-chain verification, addressing privacy challenges like MEV attacks and sensitive data exposure." authors: [dora] image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=Programmable%20Privacy%20in%20Blockchain%3A%20Off%E2%80%91Chain%20Compute%20with%20On%E2%80%91Chain%20Verification%22%0A%0A---%0A%0A%23%20Programmable%20Privacy%20in%20Blockchain%3A%20Off%E2%80%91Chain%20Compute%20with%20On%E2%80%91Chain%20Verification%0A%0A!%5B%5D(https%3A%2F%2Fopengraph-image.blockeden.xyz%2Fapi%2Fog-blockeden-xyz%3Ftitle%3DProgrammable%20Privacy%20in%20Blockchain%3A%20Off%E2%80%91Chain%20Compute%20with%20On%E2%80%91Chain%20Verification)

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:

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