23 publicaciones etiquetados con "Sui"

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​

• Documentación Seal: https://seal-docs.wal.app/
• Repositorio GitHub: https://github.com/MystenLabs/seal
• Documentación Sui: https://docs.sui.io/
• Documentación Walrus: https://docs.wal.app/

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.

TL;DR​

• Talus está entregando Nexus, un marco basado en Move que compone herramientas on-chain y off-chain en flujos de trabajo verificables tipo grafo acíclico dirigido (DAG), coordinados hoy por un servicio "Leader" de confianza con planes de enclaves seguros y descentralización.
• La pila apunta a la incipiente economía de agentes integrando registros de herramientas, rieles de pago, presupuestos de gas y marketplaces para que creadores de herramientas y operadores de agentes moneticen el uso con auditoría.
• Existe una hoja de ruta pública hacia una Protochain dedicada (Cosmos SDK + Move VM), aunque Sui sigue siendo la capa de coordinación activa; la integración Sui + Walrus aporta el sustrato operativo actual.
• Los planes de token evolucionan: materiales citan el histórico concepto $TAI y un Litepaper 2025 que introduce el token de ecosistema$US para pagos, staking y mecánicas de priorización.
• El riesgo operativo se concentra en descentralizar el Leader, finalizar la economía del token y demostrar el rendimiento de Protochain manteniendo una buena experiencia de desarrollador entre Sui, Walrus y servicios off-chain.

Qué Está Construyendo Talus (y Qué No)​

Talus se posiciona como una capa de coordinación y monetización para agentes de IA autónomos, no como un mercado bruto de inferencia. Su producto central, Nexus, permite a los desarrolladores empaquetar invocaciones de herramientas, llamadas a APIs externas y lógica on-chain en flujos DAG expresados en Sui Move. El diseño prioriza verificabilidad, acceso basado en capacidades y flujos de datos gobernados por esquemas para que cada invocación pueda auditarse on-chain. Talus complementa esto con marketplaces—Tool Marketplace, Agent Marketplace y Agent-as-a-Service—que ayudan a descubrir y monetizar funciones de agentes.

Por contraste, Talus no opera sus propios modelos de lenguaje ni una red de GPU. Espera que los creadores de herramientas envuelvan APIs o servicios existentes (OpenAI, búsqueda vectorial, sistemas de trading, proveedores de datos) y los registren en Nexus. Así, Talus es complementario a redes de cómputo como Ritual o Bittensor, que podrían aparecer como herramientas dentro de los flujos Nexus.

Arquitectura: Plano de Control On-Chain, Ejecución Off-Chain​

On-Chain (Sui Move)​

Los componentes on-chain viven en Sui y proveen el plano de coordinación:

• Motor de flujos – La semántica de DAG incluye grupos de entrada, variantes ramificadas y verificaciones de concurrencia. La validación estática busca evitar condiciones de carrera antes de ejecutar.
• Primitivos – ProofOfUID habilita mensajería autenticada entre paquetes sin acoplamiento fuerte; OwnerCap/CloneableOwnerCap exponen permisos basados en capacidades; las estructuras ProvenValue y NexusData definen cómo se pasa la data en línea o vía referencias de almacenamiento remoto.
• Default TAP (Talus Agent Package) – Agente de referencia que muestra cómo crear worksheets (objetos de prueba), disparar evaluaciones de flujo y confirmar resultados de herramientas respetando la Nexus Interface v1.
• Registro de herramientas y anti-spam – Los creadores deben depositar colateral bloqueado por tiempo para publicar una definición de herramienta, desincentivando spam sin perder el carácter permissionless.
• Servicio de gas – Objetos compartidos almacenan precios por herramienta, presupuestos de gas de usuarios y tickets de gas con expiración o límites de uso. Los eventos registran cada reclamo para auditar la liquidación de propietarios de herramientas y del Leader.

Leader Off-Chain​

Un Leader operado por Talus escucha eventos de Sui, obtiene esquemas de herramientas, orquesta la ejecución off-chain (LLMs, APIs, trabajos de cómputo), valida entradas y salidas contra los esquemas declarados y escribe los resultados on-chain. Las capacidades del Leader son objetos de Sui; una transacción fallida puede "dañar" una capacidad, impidiendo su reutilización hasta el siguiente epoch. Talus planea reforzar este camino con entornos de ejecución confiables (TEE), múltiples operadores y participación permissionless.

Almacenamiento y Verificabilidad​

Walrus, la capa de almacenamiento descentralizada de Mysten Labs, se integra para memoria de agentes, artefactos de modelos y grandes datasets. Nexus mantiene Sui como plano de control determinista y envía las cargas pesadas a Walrus. Los materiales públicos apuntan a soportar varios modos de verificación—optimista, de conocimiento cero o ejecución confiable—según los requisitos del flujo.

Experiencia de Desarrollador y Productos Iniciales​

Talus mantiene un SDK en Rust, herramientas de CLI y documentación con guías (construir DAGs, integrar LLMs, asegurar herramientas). Un catálogo de herramientas estándar—completions de OpenAI, operaciones en X (Twitter), adaptadores de Walrus, utilidades matemáticas—reduce la fricción para prototipos. En el frente consumidor, experiencias como IDOL.fun (mercados de predicción entre agentes) y AI Bae (compañeros de IA gamificados) sirven como pruebas de concepto y canales de distribución. Talus Vision, un constructor no-code, se plantea como una próxima interfaz de marketplace que abstrae el diseño de flujos para no desarrolladores.

Diseño Económico, Planes de Token y Manejo de Gas​

En el despliegue actual sobre Sui, los usuarios financian flujos con SUI. El Servicio de Gas convierte esos presupuestos en tickets específicos por herramienta, aplica expiraciones o límites de alcance y registra reclamos conciliables on-chain. Los dueños de herramientas definen precios y el Leader cobra a través del mismo flujo. Como el Leader puede reclamar presupuestos una vez que la ejecución concluye, los usuarios deben confiar en el operador, aunque los eventos emitidos facilitan la auditoría.

El diseño del token sigue en transición. Explicadores externos mencionan el antiguo $TAI**, mientras que el Litepaper 2025 propone un token de ecosistema llamado **$US con suministro de 10 mil millones. Sus funciones declaradas incluyen servir como medio de pago para herramientas y Leaders, habilitar staking con garantías de servicio y otorgar privilegios de priorización. Los materiales sugieren que el SUI excedente pagado durante la ejecución podría convertirse a $US mediante intercambios de mercado. Los inversionistas deben tratar estos detalles como provisionales hasta que se finalicen la tokenómica.

Financiamiento, Equipo y Alianzas​

Talus anunció una ronda estratégica de 6 millones de dólares (total 9 millones levantados) liderada por Polychain con una valoración reportada de 150 millones a finales de 2024. Los fondos se destinan a avanzar Nexus, incubar aplicaciones de consumo y construir Protochain, la L1 dedicada propuesta para agentes. Fuentes públicas destacan a Mike Hanono (CEO) y Ben Frigon (COO) como ejecutivos clave. Los anuncios de integración subrayan la colaboración con los ecosistemas de Sui y Walrus, consolidando la infraestructura de Mysten Labs como entorno de ejecución actual.

Lente Competitiva​

• Ritual se enfoca en cómputo de IA descentralizado (Infernet) e integraciones EVM, priorizando inferencia verificable más que orquestación de flujos.
• Autonolas (Olas) coordina servicios de agentes off-chain con incentivos on-chain; comparte la tesis de economía de agentes pero carece de la capa de ejecución DAG en Move que ofrece Nexus.
• Fetch.ai brinda Agentverse y uAgents para conectar servicios autónomos; Talus se diferencia al verificar on-chain cada paso del flujo e incorporar contabilidad de gas integrada.
• Bittensor recompensa la contribución de modelos ML mediante subredes TAO—un mercado de cómputo que podría integrarse en Nexus como herramienta pero que no aporta los rieles de monetización que Talus persigue.

En conjunto, Talus busca ocupar el plano de coordinación y liquidación de los flujos agénticos, dejando el cómputo crudo e inferencia a redes especializadas que pueden conectarse como herramientas.

Principales Riesgos y Preguntas Abiertas​

1. Confianza en el Leader – Hasta que lleguen los TEEs y soporte multioperador, los desarrolladores deben confiar en que el Leader de Talus ejecutará fielmente y devolverá resultados correctos.
2. Incertidumbre del token – La marca y mecánicas cambiaron de $TAI a$US; aún faltan definir cronogramas de suministro, distribución y economía de staking.
3. Ejecución de Protochain – Los materiales públicos describen una cadena con Cosmos SDK y Move VM, pero todavía no hay repositorios, benchmarks ni auditorías disponibles.
4. Calidad de herramientas y spam – El colateral desalienta el spam, pero el éxito a largo plazo depende de validación de esquemas, garantías de disponibilidad y resolución de disputas sobre salidas off-chain.
5. Complejidad de UX – Coordinar Sui, Walrus y APIs diversas introduce sobrecarga operativa; el SDK y las herramientas no-code deben abstraer esto para mantener la adopción.

Hitos a Seguir en 2025–2026​

• Publicación de la hoja de ruta del Leader con refuerzo TEE, reglas de slashing y onboarding abierto para más operadores.
• Expansión del Tool Marketplace: número de herramientas registradas, modelos de precios y métricas de calidad (uptime, transparencia de SLA).
• Métricas de adopción de IDOL.fun, AI Bae y Talus Vision como indicadores de demanda por experiencias nativas de agentes.
• Datos de rendimiento de flujos de gran tamaño en Sui + Walrus: latencia, throughput y consumo de gas.
• Divulgación de la tokenómica final, incluidos calendario de suministro, recompensas de staking y ruta de conversión SUI→$US.
• Lanzamiento de repositorios, testnets e iniciativas de interoperabilidad (p. ej. soporte IBC) de Protochain para validar la tesis de una cadena dedicada.

Cómo Pueden Involucrarse Desarrolladores y Operadores​

• Prototipar rápido – Combinar el Default TAP con herramientas estándar (OpenAI, X, Walrus) en un DAG de tres nodos para automatizar ingestión de datos, resumen y acciones on-chain.
• Monetizar herramientas especializadas – Envolver APIs propietarias (datos financieros, verificaciones de cumplimiento, LLMs a medida) como herramientas Nexus, fijar precios y emitir tickets de gas con expiración o límites de uso para gestionar la demanda.
• Prepararse para operar Leaders – Seguir la documentación sobre requisitos de staking, lógica de slashing y manejo de fallas para que proveedores de infraestructura puedan sumarse como Leaders adicionales cuando la red se abra.
• Evaluar los flywheels de consumo – Analizar retención y gasto en IDOL.fun y AI Bae para valorar si productos consumer centrados en agentes pueden detonar mayor demanda de herramientas.

Conclusión​

Talus ofrece un plano convincente para la economía de agentes on-chain al combinar flujos verificables en Move, composición de herramientas con control de capacidades y rieles explícitos de monetización. El éxito depende ahora de demostrar que el modelo escala más allá de un Leader confiable, de concretar incentivos sostenibles para el token y de probar que Protochain puede extender las lecciones de la etapa en Sui hacia un entorno dedicado. Los constructores que necesiten liquidación transparente y flujos agénticos componibles deberían mantener a Nexus en su lista de diligencia mientras monitorean la velocidad con la que Talus mitiga estas incógnitas.

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.

Imagina un mundo donde los usuarios puedan interactuar con tu dApp de forma fluida, sin necesidad de poseer tokens nativos (SUI). Esto ya no es un sueño lejano. Con la Gas Station de Sui (también conocida como Paymaster), los desarrolladores pueden cubrir las tarifas de gas en nombre de sus usuarios, eliminando por completo una de las mayores barreras para los nuevos participantes en Web3 y habilitando una experiencia verdaderamente sin fricción en cadena.

Este artículo ofrece una guía completa para actualizar tu dApp y hacerla sin gas. Profundizaremos en los conceptos centrales del Sui Paymaster, su arquitectura, patrones de implementación y mejores prácticas.

1. Antecedentes y conceptos clave: ¿Qué es una transacción patrocinada?​

En el mundo de la blockchain, cada transacción requiere una tarifa de red, o “gas”. Para los usuarios acostumbrados a la fluidez de Web2, esto representa un obstáculo cognitivo y operativo significativo. Sui aborda este desafío a nivel de protocolo con Transacciones Patrocinadas.

La idea central es simple: permitir que una parte (el Patrocinador) pague las tarifas de gas en SUI por la transacción de otra parte (el Usuario). De este modo, incluso si un usuario no tiene SUI en su billetera, puede iniciar acciones en cadena con éxito.

Paymaster ≈ Gas Station​

En el ecosistema Sui, la lógica para patrocinar transacciones suele ser manejada por un servicio fuera de cadena o en cadena llamado Gas Station o Paymaster. Sus responsabilidades principales incluyen:

1. Evaluar la transacción: recibe los datos de la transacción sin gas del usuario (GasLessTransactionData).
2. Proveer gas: bloquea y asigna la tarifa de gas necesaria para la transacción. Esto normalmente se gestiona mediante un pool de gas compuesto por muchos objetos SUI Coin.
3. Generar una firma del patrocinador: tras aprobar el patrocinio, la Gas Station firma la transacción con su clave privada (SponsorSig), certificando su disposición a pagar la tarifa.
4. Devolver la transacción firmada: envía de vuelta el TransactionData, que ahora incluye los datos de gas y la firma del patrocinador, a la espera de la firma final del usuario.

En resumen, una Gas Station actúa como un servicio de repostaje para los usuarios de tu dApp, asegurando que sus “vehículos” (transacciones) puedan viajar sin problemas por la red Sui.

2. Arquitectura de alto nivel y flujo de interacción​

Una transacción sin gas típica implica coordinación entre el usuario, el frontend de la dApp, la Gas Station y un nodo completo de Sui. La secuencia de interacción es la siguiente:

Desglose del flujo:

1. El Usuario realiza una acción en la UI de la dApp, que construye un paquete de datos de transacción sin información de gas.
2. La dApp envía estos datos a su Gas Station designada para solicitar patrocinio.
3. La Gas Station verifica la validez de la solicitud (p. ej., comprueba si el usuario es elegible para el patrocinio), luego rellena la transacción con una Gas Coin y su firma, devolviendo la transacción semicompleta a la dApp.
4. El Usuario ve los detalles completos de la transacción en su billetera (p. ej., “Comprar un NFT”) y proporciona la firma final. Este paso es crucial para garantizar que el usuario mantenga su consentimiento y control sobre sus acciones.
5. La dApp difunde la transacción completa, que contiene tanto la firma del usuario como la del patrocinador, a un Nodo Completo de Sui.
6. Tras la finalización en cadena, la Gas Station puede confirmar esto escuchando eventos o recibos en cadena y luego notificar al backend de la dApp mediante un webhook para cerrar el bucle del proceso de negocio.

3. Tres modelos de interacción principales​

Puedes usar los siguientes tres modelos de interacción de forma individual o combinada, según tus necesidades comerciales.

Modelo 1: Iniciado por el usuario → Aprobado por el patrocinador (más común)​

Este es el modelo estándar, adecuado para la gran mayoría de interacciones dentro de la dApp.

1. El usuario construye GasLessTransactionData: el usuario realiza una acción dentro de la dApp.
2. El patrocinador añade GasData y firma: el backend de la dApp envía la transacción a la Gas Station, que la aprueba, adjunta una Gas Coin y añade su firma.
3. El usuario revisa y da la firma final: el usuario confirma los detalles finales en su billetera y firma. La dApp entonces la envía a la red.

Este modelo logra un excelente equilibrio entre seguridad y experiencia de usuario.

Modelo 2: Patrocinador inicia airdrops/incentivos​

Este modelo es perfecto para airdrops, incentivos a usuarios o distribuciones masivas de activos.

1. Patrocinador pre‑llena TransactionData + firma: el patrocinador (normalmente el equipo del proyecto) construye la mayor parte de la transacción (p. ej., airdrop de un NFT a una dirección específica) y adjunta su firma de patrocinio.
2. La segunda firma del usuario la hace efectiva: el usuario solo necesita firmar esta transacción “pre‑aprobada” una vez para que se ejecute.

Esto crea una experiencia de usuario extremadamente fluida. Con un solo clic para confirmar, los usuarios pueden reclamar recompensas o completar tareas, aumentando drásticamente las tasas de conversión de campañas de marketing.

Modelo 3: GasData comodín (modelo de línea de crédito)​

Este es un modelo más flexible y basado en permisos.

1. El patrocinador transfiere un objeto GasData: primero crea uno o varios objetos Gas Coin con un presupuesto específico y transfiere la propiedad directamente al usuario.
2. El usuario gasta libremente dentro del presupuesto: el usuario puede usar esos Gas Coins para pagar cualquier transacción que inicie, siempre que se mantenga dentro de los límites y el periodo de validez del presupuesto.
3. El Gas Coin se devuelve: una vez agotado o expirado, el objeto Gas Coin puede ser diseñado para destruirse automáticamente o volver al patrocinador.

Este modelo equivale a entregar al usuario una “tarjeta de crédito de tarifas de gas” limitada en tiempo y presupuesto, adecuada para escenarios que requieren alta autonomía del usuario, como ofrecer una experiencia free‑to‑play durante una temporada de juego.

4. Escenarios de aplicación típicos​

El poder del Sui Paymaster no solo radica en resolver el problema de las tarifas de gas, sino también en su capacidad de integrarse profundamente con la lógica de negocio para crear nuevas posibilidades.

Escenario 1: Paywalls​

Muchas plataformas de contenido o servicios de dApp requieren que los usuarios cumplan ciertos criterios (p. ej., poseer un NFT VIP, alcanzar un nivel de membresía) para acceder a funcionalidades. El Paymaster puede implementar esta lógica de forma perfecta.

• Flujo: un usuario solicita una acción → el backend de la dApp verifica las calificaciones del usuario (p. ej., propiedad de NFT) → si es elegible, llama al Paymaster para patrocinar la tarifa de gas; si no, simplemente niega la solicitud de firma.
• Ventaja: este modelo es inherentemente resistente a bots y abusos. Dado que la decisión de patrocinio se toma en el backend, los usuarios malintencionados no pueden eludir la verificación de calificaciones para drenar fondos de gas.

Escenario 2: Checkout con un clic​

En e‑commerce o compras dentro de juegos, simplificar el proceso de pago es crítico.

• Flujo: el usuario hace clic en “Comprar ahora” en la página de checkout. La dApp construye una transacción que incluye la lógica de negocio (p. ej., transfer_nft_to_user). El usuario solo necesita firmar para aprobar la transacción de negocio en su billetera, sin preocuparse por el gas. La tarifa de gas la cubre el patrocinador de la dApp.
• Ventaja: puedes codificar parámetros de negocio como un order_id directamente en el ProgrammableTransactionBlock, permitiendo una atribución on‑chain precisa para los pedidos del backend.

Escenario 3: Atribución de datos​

El seguimiento preciso de datos es fundamental para la optimización del negocio.

• Flujo: al construir la transacción, escribe un identificador único (como un order_hash) en los parámetros de la transacción o en un evento que se emitirá al ejecutarse.
• Ventaja: cuando la Gas Station recibe el recibo on‑chain de una transacción exitosa, puede extraer fácilmente ese order_hash analizando el evento o los datos de la transacción. Esto permite mapear con precisión los cambios de estado on‑chain a pedidos o acciones específicas del backend.

5. Esqueleto de código (basado en el SDK de Rust)​

A continuación se muestra un fragmento simplificado que demuestra los pasos centrales de interacción.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

Para una implementación completa, consulta el Tutorial de Gas Station de la documentación oficial de Sui, que ofrece ejemplos de código listos para usar.

6. Riesgos y protecciones​

Aunque potente, desplegar una Gas Station en producción requiere considerar cuidadosamente los siguientes riesgos:

• Equivocación (doble gasto): un usuario malicioso podría intentar usar la misma Gas Coin en múltiples transacciones paralelas, lo que bloquearía la Gas Coin en la red Sui. Esto se mitiga eficazmente asignando una Gas Coin única por usuario o por transacción, manteniendo una lista negra y limitando la tasa de solicitudes de firma.
• Gestión del pool de gas: en escenarios de alta concurrencia, una sola Gas Coin de gran valor puede convertirse en un cuello de botella de rendimiento. El servicio de Gas Station debe ser capaz de dividir automáticamente grandes SUI Coins en muchas Gas Coins de menor valor y recuperarlas eficientemente después de su uso. Proveedores profesionales de Gas Station como Shinami ofrecen soluciones gestionadas y maduras para esto.
• Autorización y limitación de velocidad: es imprescindible establecer políticas estrictas de autorización y limitación de velocidad. Por ejemplo, gestionar límites y frecuencias de patrocinio basados en la IP del usuario, la dirección de la billetera o tokens API para evitar que el servicio sea drenado por actores malintencionados.

7. Herramientas del ecosistema​

El ecosistema Sui ya ofrece un conjunto rico de herramientas para simplificar el desarrollo y despliegue de Paymasters:

• SDK oficiales (Rust/TypeScript): incluyen APIs de alto nivel como sponsor_transaction_block(), reduciendo significativamente la complejidad de integración.
• Shinami Gas Station: proporciona un servicio gestionado todo‑en‑uno, que incluye división/reclamación automática de Gas Coins, métricas detalladas y notificaciones webhook, permitiendo a los desarrolladores centrarse en la lógica de negocio.
• Enoki / Demos de Mysten: la comunidad y Mysten Labs también ofrecen implementaciones de Paymaster de código abierto que pueden usarse como referencia para construir tu propio servicio.

8. Lista de verificación de implementación​

¿Listo para actualizar tu dApp a la era sin gas? Recorre esta lista antes de comenzar:

• Planifica tu flujo de financiación: define la fuente de fondos del patrocinador, el presupuesto y la estrategia de reposición. Configura monitoreo y alertas para métricas clave (p. ej., saldo del pool de gas, tasa de consumo).
• Reserva campos de atribución: al diseñar los parámetros de tu transacción, asegura reservar campos para identificadores de negocio como order_id o user_id.
• Despliega políticas anti‑abuso: implementa autorización estricta, limitación de velocidad y mecanismos de registro antes de lanzar.
• Ensaya en testnet: ya sea construyendo tu propio servicio o integrando una Gas Station de terceros, realiza pruebas exhaustivas de concurrencia y estrés en una testnet o devnet primero.
• Optimiza continuamente: después del lanzamiento, monitorea continuamente las tasas de éxito de transacciones, razones de fallos y costos de gas. Ajusta tu presupuesto y estrategias basándote en los datos.

Conclusión​

El Sui Paymaster (Gas Station) es mucho más que una herramienta para cubrir tarifas de gas de los usuarios. Es un paradigma poderoso que combina elegantemente una experiencia “cero SUI en cadena” para el usuario con la necesidad empresarial de “atribución a nivel de orden on‑chain” dentro de una única transacción atómica. Allana el camino para que usuarios de Web2 ingresen a Web3 y brinda a los desarrolladores una flexibilidad sin precedentes para la personalización de negocios.

Con un ecosistema de herramientas cada vez más maduro y los actuales bajos costos de gas en la red Sui, nunca ha habido un mejor momento para actualizar los flujos de pago e interacción de tu dApp a la era sin gas.

¡Nos complace anunciar el lanzamiento del staking de token SUI en BlockEden.xyz! A partir de hoy, puedes hacer staking de tus tokens SUI directamente a través de nuestra plataforma y ganar un 2.08% APY mientras apoyas la seguridad y descentralización de la red SUI.

Novedades: Una Experiencia de Staking SUI sin Fricciones​

Nuestra nueva función de staking lleva staking de nivel institucional a todos, con una interfaz simple e intuitiva que hace que ganar recompensas sea sin esfuerzo.

Características Clave​

Staking con Un Clic
El staking de SUI nunca ha sido tan fácil. Simplemente conecta tu billetera Suisplash, ingresa la cantidad de SUI que deseas stakear y aprueba la transacción. Comenzarás a ganar recompensas casi de inmediato sin procedimientos complejos.

Recompensas Competitivas
Gana un 2.08% APY competitivo sobre tu SUI stakeado. Nuestra comisión del 8% es transparente, asegurando que sepas exactamente qué esperar. Las recompensas se distribuyen diariamente al completarse cada epoch.

Validador de Confianza
Únete a una comunidad en crecimiento que ya ha stakeado más de 22 millones de SUI con el validador de BlockEden.xyz. Tenemos un historial probado de servicios de validación fiables, respaldados por infraestructura de nivel empresarial que garantiza un tiempo de actividad del 99.9%.

Gestión Flexible
Tus activos siguen siendo flexibles. El staking es instantáneo, lo que significa que tus recompensas comienzan a acumularse de inmediato. Si necesitas acceder a tus fondos, puedes iniciar el proceso de unstaking en cualquier momento. Tu SUI estará disponible después del período estándar de desbloqueo de la red SUI de 24-48 horas. Puedes rastrear tus stakes y recompensas en tiempo real a través de nuestro panel.

¿Por Qué Hacer Staking de SUI con BlockEden.xyz?​

Confiabilidad en la que Puedes Confiar​

BlockEden.xyz ha sido una piedra angular de la infraestructura blockchain desde nuestros inicios. Nuestra infraestructura de validadores impulsa aplicaciones empresariales y ha mantenido un tiempo de actividad excepcional en múltiples redes, garantizando una generación constante de recompensas.

Transparente y Justo​

Creemos en la total transparencia. No hay tarifas ocultas, solo una comisión del 8% clara sobre las recompensas que ganas. Puedes monitorear tu desempeño de staking con reportes en tiempo real y verificar la actividad de nuestro validador en cadena.

• Open Address: 0x0000000000000000000000000000000000000000

Integración Sin Fricciones​

Nuestra plataforma está diseñada para la simplicidad. No es necesario crear una cuenta; puedes hacer staking directamente desde tu billetera. La experiencia está optimizada para la billetera Suisplash, y nuestra interfaz limpia e intuitiva está construida tanto para principiantes como para expertos.

Cómo Empezar​

Paso 1: Visita la Página de Staking​

Visita blockeden.xyz/dash/stake. Puedes iniciar el proceso de inmediato sin necesidad de registrar una cuenta.

Paso 2: Conecta tu Billetera​

Si aún no la tienes, instala la billetera Suisplash. Haz clic en el botón "Conectar Billetera" en nuestra página de staking y aprueba la conexión en la extensión de la billetera. Tu saldo de SUI se mostrará automáticamente.

Paso 3: Elige la Cantidad a Stakear​

Ingresa la cantidad de SUI que deseas stakear (mínimo 1 SUI). Puedes usar el botón "MAX" para stakear convenientemente todo tu saldo disponible, dejando una pequeña cantidad para tarifas de gas. Un resumen mostrará tu cantidad stakeada y las recompensas anuales estimadas.

Paso 4: Confirma y Comienza a Ganar​

Haz clic en "Stake SUI" y aprueba la transacción final en tu billetera. Tu nuevo stake aparecerá en el panel en tiempo real, y comenzarás a acumular recompensas de inmediato.

Economía del Staking: Lo Que Necesitas Saber​

Estructura de Recompensas​

• APY Base: 2.08% anual
• Frecuencia de Recompensas: Distribuida cada epoch (aproximadamente cada 24 horas)
• Comisión: 8% de las recompensas ganadas
• Capitalización: Las recompensas se añaden a tu billetera y pueden ser re‑stakeadas para lograr crecimiento compuesto.

Ejemplo de Ganancias​

Nota: Estas son estimaciones. Las recompensas reales pueden variar según las condiciones de la red.

Consideraciones de Riesgo​

• Período de Desbloqueo: Cuando haces unstake, tu SUI está sujeto a un período de desbloqueo de 24-48 horas en el que no es accesible y no genera recompensas.
• Riesgo del Validador: Aunque mantenemos altos estándares, cualquier validador conlleva riesgos operativos. Elegir un validador reputado como BlockEden.xyz es importante.
• Riesgo de Red: El staking es una forma de participación en la red y está sujeto a los riesgos inherentes al protocolo blockchain subyacente.
• Riesgo de Mercado: El valor de mercado del token SUI puede fluctuar, lo que afectará el valor total de tus activos stakeados.

Excelencia Técnica​

Infraestructura Empresarial​

Nuestros nodos validadores están construidos sobre una base de excelencia técnica. Utilizamos sistemas redundantes distribuidos en múltiples regiones geográficas para garantizar alta disponibilidad. Nuestra infraestructura está bajo monitoreo 24/7 con capacidades de conmutación automática, y un equipo profesional de operaciones gestiona el sistema las 24 horas. También realizamos auditorías de seguridad y verificaciones de cumplimiento de forma regular.

Código Abierto y Transparencia​

Estamos comprometidos con los principios de código abierto. Nuestra integración de staking está construida para ser transparente, permitiendo a los usuarios inspeccionar los procesos subyacentes. Métricas en tiempo real están disponibles públicamente en los exploradores de la red SUI, y nuestra estructura de tarifas es completamente abierta sin costos ocultos. También participamos activamente en la gobernanza comunitaria para apoyar el ecosistema SUI.

Apoyando el Ecosistema SUI​

• Seguridad de la Red: Tu stake se suma al total que asegura la red SUI, haciéndola más robusta contra posibles ataques.
• Descentralización: Apoyar validadores independientes como BlockEden.xyz mejora la resiliencia de la red y previene la centralización.
• Crecimiento del Ecosistema: Las comisiones que ganamos se reinvierten en mantener y desarrollar infraestructura crítica.
• Innovación: Los ingresos respaldan nuestra investigación y desarrollo de nuevas herramientas y servicios para la comunidad blockchain.

Seguridad y Mejores Prácticas​

Seguridad de la Billetera​

• Nunca compartas tus claves privadas o frase semilla con nadie.
• Utiliza una billetera hardware para almacenar y stakear grandes cantidades.
• Siempre verifica los detalles de la transacción en tu billetera antes de firmar.
• Mantén tu software de billetera actualizado a la última versión.

Seguridad del Staking​

• Si eres nuevo en el staking, comienza con una pequeña cantidad para familiarizarte con el proceso.
• Considera diversificar tu stake entre varios validadores reputados para reducir el riesgo.
• Monitorea regularmente tus activos stakeados y recompensas.
• Asegúrate de comprender el período de desbloqueo antes de comprometer tus fondos.

Únete al Futuro del Staking SUI​

El lanzamiento del staking SUI en BlockEden.xyz es más que una nueva función; es una puerta de entrada a la participación activa en la economía descentralizada. Ya seas un usuario experimentado de DeFi o estés comenzando tu camino, nuestra plataforma ofrece una forma simple y segura de ganar recompensas mientras contribuyes al futuro de la red SUI.

¿Listo para comenzar a ganar?
Visita blockeden.xyz/dash/stake y stakea tus primeros tokens SUI hoy!

Acerca de BlockEden.xyz​

BlockEden.xyz es un proveedor líder de infraestructura blockchain que ofrece servicios fiables, escalables y seguros a desarrolladores, empresas y a la comunidad Web3 en general. Desde servicios API hasta operaciones de validadores, estamos comprometidos a construir la base para un futuro descentralizado.

• Fundado: 2021
• Redes Soportadas: más de 15 redes blockchain
• Clientes Empresariales: más de 500 empresas en todo el mundo
• Valor Total Asegurado: más de $100M en todas las redes

Síguenos en Twitter, únete a nuestro Discord y explora nuestra suite completa de servicios en BlockEden.xyz.

Aviso: Esta publicación del blog es solo con fines informativos y no constituye asesoramiento financiero. El staking de criptomonedas implica riesgos, incluida la posible pérdida del capital. Por favor, realiza tu propia investigación y considera tu tolerancia al riesgo antes de hacer staking.

Introducción​

Anunciado para su lanzamiento público el 3 de mayo de 2023, después de una extensa prueba de tres ondas, la cadena de bloques Sui introdujo un sistema de precios de gas innovador diseñado para beneficiar tanto a usuarios como a validadores. En su corazón está el Precio de Gas de Referencia (RGP), una tarifa base de gas a nivel de red que los validadores acuerdan al comienzo de cada época (aproximadamente 24 horas).

Este sistema busca crear un ecosistema mutuamente beneficioso para los poseedores del token SUI, los validadores y los usuarios finales al proporcionar costos de transacción bajos y predecibles mientras recompensa a los validadores por un comportamiento eficiente y fiable. Este informe ofrece un análisis profundo de cómo se determina el RGP, los cálculos que realizan los validadores, su impacto en la economía de la red, su evolución mediante la gobernanza y cómo se compara con otros modelos de gas de blockchain.

El Mecanismo de Precio de Gas de Referencia (RGP)​

El RGP de Sui no es un valor estático, sino que se restablece cada época mediante un proceso dinámico impulsado por los validadores.

• La Encuesta de Precio de Gas: Al inicio de cada época, cada validador envía su “precio de reserva”, es decir, el precio mínimo de gas que está dispuesto a aceptar para procesar transacciones. El protocolo ordena estas presentaciones por participación y fija el RGP de esa época en el percentil ponderado por participación del 2/3. Este diseño asegura que los validadores que representan una supermayoría (al menos dos tercios) del total de participación estén dispuestos a procesar transacciones a ese precio, garantizando un nivel fiable de servicio.

• Cadencia de Actualización y Requisitos: Aunque el RGP se establece cada época, los validadores deben gestionar activamente sus cotizaciones. Según la guía oficial, los validadores deben actualizar su cotización de precio de gas al menos una vez por semana. Además, si hay un cambio significativo en el valor del token SUI, como una fluctuación del 20 % o más, los validadores deben actualizar su cotización de inmediato para que el RGP refleje con precisión las condiciones de mercado actuales.

• Regla de Conteo y Distribución de Recompensas: Para garantizar que los validadores respeten el RGP acordado, Sui emplea una “regla de conteo”. A lo largo de una época, los validadores monitorizan el desempeño de sus pares, verificando si procesan puntualmente las transacciones con precio RGP. Este monitoreo genera una puntuación de desempeño para cada validador. Al final de la época, esas puntuaciones se usan para calcular un multiplicador de recompensa que ajusta la parte de recompensas de participación de cada validador.

  • Los validadores que tuvieron buen desempeño reciben un multiplicador de ≥ 1, aumentando sus recompensas.
  • Los validadores que se retrasaron, demoraron o no procesaron transacciones al precio RGP reciben un multiplicador de < 1, recortando efectivamente una parte de sus ganancias.

Este sistema de dos partes crea una poderosa estructura de incentivos. Disuade a los validadores de cotizar un precio irrealmente bajo que no puedan sostener, ya que la penalización financiera por bajo rendimiento sería severa. En su lugar, los validadores están motivados a presentar el precio más bajo que puedan manejar de forma sostenible y eficiente.

Operaciones de Validadores: Cálculo de la Cotización del Precio de Gas​

Desde la perspectiva de un validador, establecer la cotización del RGP es una tarea operativa crítica que impacta directamente la rentabilidad. Requiere construir pipelines de datos y capas de automatización para procesar una serie de entradas tanto on‑chain como off‑chain. Las entradas clave incluyen:

• Unidades de gas ejecutadas por época
• Recompensas y subsidios de participación por época
• Contribuciones al fondo de almacenamiento
• Precio de mercado del token SUI
• Gastos operativos (hardware, hosting en la nube, mantenimiento)

El objetivo es calcular una cotización que garantice recompensas netas positivas. El proceso implica varias fórmulas clave:

1. Calcular el Costo Operativo Total: Determina los gastos del validador en moneda fiat para una época dada.

   $$\text{Cost}_{\text{epoch}} = (\text{Total Gas Units Executed}_{\text{epoch}}) \times (\text{Cost in \$ per Gas Unit}_{\text{epoch}})$$

2. Calcular las Recompensas Totales: Determina los ingresos totales del validador en moneda fiat, provenientes tanto de subsidios del protocolo como de tarifas de transacción.

   $$\text{\$Rewards}_{\text{epoch}} = (\text{Total Stake Rewards in SUI}_{\text{epoch}}) \times (\text{SUI Token Price})$$

   Donde Total Stake Rewards es la suma de cualquier Stake Subsidies provisto por el protocolo y las Gas Fees recaudadas de las transacciones.

3. Calcular las Recompensas Netas: Medida definitiva de la rentabilidad para un validador.

   $$\text{\$Net Rewards}_{\text{epoch}} = \text{\$Rewards}_{\text{epoch}} - \text{\$Cost}_{\text{epoch}}$$

Al modelar sus costos y recompensas esperados a diferentes niveles de RGP, los validadores pueden determinar una cotización óptima para presentar en la Encuesta de Precio de Gas.

Tras el lanzamiento en mainnet, Sui fijó el RGP inicial en 1 000 MIST (1 SUI = 10⁹ MIST) durante la primera o segunda semana. Esto proporcionó un período operativo estable para que los validadores recopilaran datos suficientes de actividad de red y establecieran sus procesos de cálculo antes de que el mecanismo dinámico de encuesta entrara en pleno efecto.

Impacto en el Ecosistema Sui​

El mecanismo RGP moldea profundamente la economía y la experiencia del usuario en toda la red.

• Para los usuarios: Tarifas predecibles y estables El RGP actúa como una ancla creíble para los usuarios. La tarifa de gas de una transacción sigue una fórmula sencilla: Precio de Gas del Usuario = RGP + Propina. En condiciones normales, no se necesita propina. Durante congestión, los usuarios pueden añadir una propina para obtener prioridad, creando un mercado de tarifas sin alterar el precio base estable dentro de la época. Este modelo brinda una estabilidad de tarifas significativamente mayor que los sistemas donde la tarifa base cambia en cada bloque.

• Para los validadores: Una carrera hacia la eficiencia El sistema fomenta una competencia saludable. Los validadores están incentivados a reducir sus costos operativos (mediante optimización de hardware y software) para poder cotizar un RGP más bajo de forma rentable. Esta “carrera hacia la eficiencia” beneficia a toda la red al disminuir los costos de transacción. El mecanismo también empuja a los validadores a mantener márgenes de beneficio equilibrados; cotizar demasiado alto corre el riesgo de quedar fuera del cálculo del RGP, mientras que cotizar demasiado bajo genera pérdidas operativas y penalizaciones de desempeño.

• Para la red: Descentralización y sostenibilidad El mecanismo RGP ayuda a asegurar la salud a largo plazo de la red. La “amenaza de entrada” de nuevos validadores más eficientes impide que los validadores existentes coludan para mantener precios altos. Además, al ajustar sus cotizaciones según el precio de mercado del token SUI, los validadores garantizan colectivamente que sus operaciones sigan siendo sostenibles en términos reales, aislando la economía de tarifas de la volatilidad del precio del token.

Gobernanza y Evolución del Sistema: SIP‑45​

El mecanismo de gas de Sui no es estático y evoluciona mediante la gobernanza. Un ejemplo destacado es SIP‑45 (Envío Prioritario de Transacciones), propuesto para refinar la priorización basada en tarifas.

• Problema abordado: El análisis mostró que pagar un precio de gas alto no siempre garantizaba una inclusión más rápida de la transacción.
• Cambios propuestos: La propuesta incluye aumentar el precio máximo de gas permitido e introducir una “difusión amplificada” para transacciones que paguen significativamente por encima del RGP (p. ej., ≥ 5× RGP), asegurando que se propaguen rápidamente por la red para una inclusión prioritaria.

Esto demuestra el compromiso de iterar sobre el modelo de gas basándose en datos empíricos para mejorar su efectividad.

Comparación con Otros Modelos de Gas de Blockchain​

El modelo RGP de Sui es único, especialmente al compararlo con el EIP‑1559 de Ethereum.

Críticas Potenciales y Desafíos​

A pesar de su diseño innovador, el mecanismo RGP enfrenta posibles desafíos:

• Complejidad: El sistema de encuestas, reglas de conteo y cálculos off‑chain es intrincado y puede presentar una curva de aprendizaje para nuevos validadores.
• Reacción lenta a picos: El RGP está fijado por una época y no puede reaccionar a aumentos repentinos de demanda a mitad de época, lo que podría generar congestión temporal hasta que los usuarios añadan propinas.
• Potencial de colusión: En teoría, los validadores podrían coludirse para fijar un RGP alto. Este riesgo se mitiga principalmente por la naturaleza competitiva del conjunto de validadores sin permiso.
• Sin quema de tarifas: A diferencia de Ethereum, Sui recicla todas las tarifas de gas a los validadores y al fondo de almacenamiento. Esto recompensa a los operadores de la red pero no crea presión deflacionaria sobre el token SUI, una característica que algunos poseedores valoran.

Preguntas Frecuentes (FAQ)​

¿Por qué hacer staking de SUI? El staking de SUI asegura la red y genera recompensas. Inicialmente, estas recompensas están fuertemente subsidiadas por la Sui Foundation para compensar la baja actividad de la red. Estos subsidios disminuyen un 10 % cada 90 días, con la expectativa de que las recompensas de tarifas de transacción crezcan hasta convertirse en la principal fuente de rendimiento. El SUI en staking también otorga derechos de voto en la gobernanza on‑chain.

¿Puede ser slasheado mi SUI en staking? Sí. Mientras los parámetros aún se finalizan, se aplica el “Tally Rule Slashing”. Un validador que reciba una puntuación de desempeño cero de 2/3 de sus pares (por bajo rendimiento, comportamiento malicioso, etc.) verá sus recompensas slasheadas por una cantidad que se determinará. Los stakers también pueden perder recompensas si su validador elegido sufre tiempo de inactividad o cotiza un RGP subóptimo.

¿Se capitalizan automáticamente las recompensas de staking? Sí, las recompensas de staking en Sui se distribuyen y re‑stakean (capitalizan) automáticamente cada época. Para acceder a las recompensas, debes retirarlas explícitamente.

¿Cuál es el período de desbloqueo de SUI? Inicialmente, los stakers pueden desbloquear sus tokens de inmediato. Se espera implementar un período de desbloqueo en el que los tokens queden bloqueados por un tiempo determinado después del retiro, sujeto a gobernanza.

¿Mantengo la custodia de mis tokens SUI al hacer staking? Sí. Cuando haces staking de SUI, delegas tu participación pero mantienes el control total de tus tokens. Nunca transfieres la custodia al validador.

Cómo eliminar la fricción de la cartera, mantener a los usuarios en flujo y pronosticar el potencial

¿Qué pasaría si tu aplicación Web3 tuviera el mismo flujo de registro sin fricciones que un servicio Web2 moderno? Esa es la promesa central de zkLogin en la blockchain Sui. Funciona como OAuth para Sui, permitiendo a los usuarios iniciar sesión con cuentas familiares de Google, Apple, X y más. Una prueba de conocimiento cero enlaza de forma segura esa identidad Web2 con una dirección Sui en cadena—sin ventanas emergentes de cartera, sin frases semilla, sin abandono de usuarios.

El impacto es real e inmediato. Con cientos de miles de cuentas zkLogin ya activas, los estudios de caso reportan ganancias masivas en la conversión de usuarios, pasando de un desalentador 17 % a un saludable 42 % después de eliminar las barreras tradicionales de la cartera. Analicemos cómo funciona y qué puede hacer por tu proyecto.

Por qué las carteras matan la conversión en el primer uso​

Has creado una dApp revolucionaria, pero tu embudo de adquisición de usuarios está perdiendo gente. El culpable casi siempre es el mismo: el botón “Conectar cartera”. La incorporación estándar en Web3 es un laberinto de instalaciones de extensiones, advertencias de frases semilla y cuestionarios de jerga cripto.

Es una barrera enorme para los recién llegados. Investigadores de UX observaron una caída asombrosa del 87 % en el momento en que apareció el aviso de la cartera. En un experimento revelador, simplemente reencaminar ese aviso a una etapa posterior del proceso de pago elevó la tasa de finalización al 94 %. Incluso para los usuarios curiosos por cripto, el miedo principal es: “Podría perder mis fondos si hago clic en el botón equivocado.” Eliminar ese único paso intimidante es la clave para desbloquear un crecimiento exponencial.

Cómo funciona zkLogin (en lenguaje sencillo)​

zkLogin elude elegantemente el problema de la cartera usando tecnologías en las que todo usuario de internet ya confía. La magia ocurre tras bambalinas en unos pocos pasos rápidos:

1. Par de claves efímero: Cuando un usuario quiere iniciar sesión, se genera localmente en su navegador un par de claves temporal de una sola sesión. Piensa en ello como una llave de paso temporal, válida solo para esa sesión.
2. Danza OAuth: El usuario inicia sesión con su cuenta de Google, Apple u otra red social. Tu aplicación inserta de forma inteligente un valor único (nonce) en esta solicitud de inicio de sesión.
3. Servicio ZKP: Tras un inicio de sesión exitoso, un servicio ZKP (Prueba de Conocimiento Cero) genera una prueba criptográfica. Esta prueba confirma, “Este token OAuth autoriza al propietario de la llave temporal,” sin revelar nunca la identidad personal del usuario en cadena.
4. Derivar dirección: El JWT (JSON Web Token) del proveedor OAuth se combina con una sal única para generar de forma determinista su dirección permanente en Sui. La sal se mantiene privada, ya sea del lado del cliente o en un backend seguro.
5. Enviar transacción: Tu aplicación firma transacciones con la llave temporal y adjunta la prueba ZK. Los validadores de Sui verifican la prueba en cadena, confirmando la legitimidad de la transacción sin que el usuario necesite una cartera tradicional.

Guía de integración paso a paso​

¿Listo para implementarlo? Aquí tienes una guía rápida usando el SDK de TypeScript. Los principios son idénticos para Rust o Python.

1. Instalar SDK​

El paquete @mysten/sui incluye todos los helpers zklogin que necesitarás.

pnpm add @mysten/sui

2. Generar claves y nonce​

Primero, crea un par de claves efímero y un nonce ligado a la época actual en la red Sui.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(
  keypair.getPublicKey(),
  Number(epoch) + 2,
  generateRandomness(),
);

3. Redirigir a OAuth​

Construye la URL de inicio de sesión OAuth adecuada para el proveedor que estés usando (por ejemplo, Google, Facebook, Apple) y redirige al usuario.

4. Decodificar JWT y obtener la sal del usuario​

Después de que el usuario inicie sesión y sea redirigido de vuelta, captura el id_token de la URL. Úsalo para obtener la sal específica del usuario desde tu backend, y luego deriva su dirección Sui.

const jwt = new URLSearchParams(window.location.search).get("id_token")!;
const salt = await fetch("/api/salt?jwt=" + jwt).then((r) => r.text());
const address = jwtToAddress(jwt, salt);

5. Solicitar prueba ZK​

Envía el JWT a un servicio de pruebas para obtener la prueba ZK. Para desarrollo, puedes usar el probador público de Mysten. En producción, deberías alojar el tuyo propio o usar un servicio como Enoki.

const proof = await fetch('/api/prove', {
  method:'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. Firmar y enviar​

Ahora, construye tu transacción, establece al remitente la dirección zkLogin del usuario y ejecútala. El SDK se encarga de adjuntar automáticamente los zkLoginInputs (la prueba). ✨

const tx = new TransactionBlock();
tx.moveCall({ target: "0x2::example::touch_grass" }); // Any Move call
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof, // The magic happens here
});

7. Persistir la sesión​

Para una experiencia de usuario más fluida, cifra y almacena el par de claves y la sal en IndexedDB o local storage. Recuerda rotarlos cada pocas épocas para mejorar la seguridad.

Plantilla de proyección de KPI​

La diferencia que zkLogin genera no es solo cualitativa; es cuantificable. Compara un embudo de incorporación típico con uno potenciado por zkLogin:

👉 Qué significa esto: Para una campaña que atraiga 10 000 visitantes únicos, esa es la diferencia entre 300 acciones en cadena el primer día y más de 2 500.

Buenas prácticas y advertencias​

Para crear una experiencia aún más fluida, ten en cuenta estos consejos profesionales:

• Usa transacciones patrocinadas: Paga las primeras tarifas de transacción de tus usuarios. Esto elimina toda fricción y genera un momento “¡ajá!” increíble.
• Maneja las sales con cuidado: Cambiar la sal de un usuario generará una nueva dirección. Hazlo solo si controlas una ruta de recuperación fiable para él.
• Expón la dirección Sui: Después del registro, muestra a los usuarios su dirección en cadena. Esto empodera a los usuarios avanzados para importarla a una cartera tradicional más adelante, si lo desean.
• Previene bucles de recarga: Cachea el JWT y el par de claves efímero hasta que expiren para evitar pedir al usuario que inicie sesión repetidamente.
• Monitorea la latencia del probador: Vigila el tiempo de ida y vuelta de la generación de pruebas. Si supera los 2 segundos, considera alojar un probador regional para mantener la experiencia ágil.

Dónde BlockEden.xyz aporta valor​

Mientras zkLogin perfecciona el flujo de cara al usuario, escalarlo introduce nuevos retos de backend. Ahí es donde entra BlockEden.xyz.

• Capa API: Nuestros nodos RPC de alta capacidad y enrutamiento geográfico garantizan que tus transacciones zkLogin se procesen con latencia mínima, sin importar la ubicación del usuario.
• Observabilidad: Obtén paneles listos para usar que rastrean métricas clave como latencia de pruebas, ratios de éxito/fracaso y la salud de tu embudo de conversión.
• Cumplimiento: Para apps que conectan con fiat, nuestro módulo opcional de KYC brinda una incorporación regulada directamente desde la identidad verificada del usuario.

¿Listo para lanzar?​

La era de los flujos de cartera torpes e intimidantes ha terminado. Levanta un sandbox zkLogin, conecta el endpoint de nodo completo de BlockEden y observa cómo tu gráfico de registros se curva hacia arriba—mientras tus usuarios ni siquiera escuchan la palabra “cartera”. 😉

1. Liquidez y Crecimiento del DeFi de Sui​

Figura: TVL del DeFi de Sui (línea azul) y volumen de DEX (barras verdes) crecieron dramáticamente durante el Q2 2025.

Aumento del Valor Total Bloqueado (TVL): La liquidez DeFi de la red Sui ha crecido explosivamente durante el último año. De aproximadamente $600 M de TVL a finales de 2024, el TVL de Sui se disparó a más de $2 mil millones a mediados de 2025. De hecho, Sui alcanzó su pico en torno a $2.55 B de TVL el 21 de mayo de 2025 y se mantuvo bien por encima de los $2 B durante gran parte del Q2. Este incremento de más del 300 % (un aumento interanual del 480 % respecto a mayo 2023) posiciona firmemente a Sui entre las top 10 blockchains por TVL DeFi, superando el crecimiento de redes como Solana. Los principales catalizadores incluyeron adopción institucional y la integración del soporte nativo para la stablecoin USDC, que juntos atrajeron grandes flujos de capital. Notablemente, los volúmenes mensuales de trading en DEX de Sui han escalado al nivel superior de todas las cadenas – superando $7–8 mil millones al mes a mediados de 2025 (ranking \ 8.º a nivel de industria). La liquidez circulante de stablecoins en Sui superó los $1 mil millones a mediados de 2025, tras crecer un 180 % desde el inicio del año, lo que indica una profundización de la liquidez on‑chain. El capital cross‑chain también fluye; alrededor de $2.7 B de activos han sido puenteados al ecosistema de Sui, incluyendo liquidez de Bitcoin (detalles más abajo). Esta tendencia de rápido crecimiento subraya un año de entradas netas y expansión de usuarios para el DeFi de Sui.

Principales DEX y Proveedores de Liquidez: Los intercambios descentralizados forman la columna vertebral de la liquidez DeFi de Sui. El protocolo Cetus – un creador de mercado automatizado (AMM) y agregador – ha sido un DEX emblemático, ofreciendo swaps de stablecoins y pools de liquidez concentrada. Cetus lidera consistentemente en volumen (facilitando más de $12.8 B en operaciones durante el Q2 2025 solo) mientras mantiene alrededor de $80 M de TVL. Otro actor clave es Bluefin, un DEX multifacético que opera tanto un AMM spot como un intercambio de futuros perpetuos. A mediados de 2025, Bluefin lanzó Momentum, una funcionalidad institucional de RFQ que permite a los traders obtener precios en tiempo real con abstracción de liquidez. Momentum introdujo Liquidity 2.0, que concentra la liquidez en rangos estrechos, mejorando la eficiencia de capital. Momentum también lanzó Momentum CLMM, que ajusta dinámicamente la liquidez según la demanda. Además, DeepBook (parte de Bluefin) introdujo RFQ para traders institucionales, reduciendo la fricción entre makers y takers. DeepBook también añadió matching de órdenes sin MEV, creando un nuevo primitivo de intercambio. DeepBook y Cetus continúan expandiendo su presencia en Sui, impulsando la profundidad de mercado y la resiliencia contra la extracción de valor máximo (MEV).

Nuevos Primitivos de DEX y HFT: En julio de 2025, Bluefin anunció la incorporación de estrategias de trading de alta frecuencia de grado institucional a su DEX basado en Sui, aprovechando la ejecución paralela de Sui para lograr mejoras de rendimiento y latencia. Esta actualización reduce la brecha con los intercambios centralizados y podría atraer a firmas cuantitativas a proveer liquidez on‑chain. Las mejoras en velocidad de ejecución, bajo deslizamiento y protección contra MEV (la actualización Spot 2.0 de Bluefin destaca por su matching RFQ resistente al MEV) son nuevos primitivos en el diseño de intercambios que Sui está pionando.

Otros DEX y Primitivos: Momentum introdujo su CLMM (Creador de Liquidez Concentrada) que concentra la liquidez en rangos de precios específicos, mejorando la eficiencia de capital. Magma lanzó su ALMM (Creador de Mercado de Alta Liquidez) que ajusta dinámicamente la liquidez según la demanda, reduciendo el deslizamiento. DeepBook añadió matching RFQ sin MEV y protección contra front‑running, creando un nuevo modelo de intercambio para traders institucionales.

Préstamos y Mercados de Crédito: El protocolo Suilend se consolidó como la plataforma de préstamos líder, ofreciendo préstamos colaterales en SUI, BTC, ETH y stablecoins. A mediados de 2025, Suilend gestionó más de $102 M en activos derivados de Bitcoin, superando a cualquier otro prestamista en Sui. Otros prestamistas como Suifin y LendingHub ampliaron sus mercados a activos tokenizados como tBTC y sBTC, impulsando la diversificación de colaterales.

Resumen de Liquidez: En 2025, el DeFi de Sui maneja varios mil millones de dólares en TVL, respaldado por DEX de alto rendimiento y plataformas de préstamo robustas, alimentado por flujos constantes de capital cross‑chain y un crecimiento sostenido de usuarios.

2. Abstracción y Experiencia de Usuario​

Abstracción de Cuenta: Sui implementa abstracción de cuenta que permite a los usuarios interactuar con contratos sin poseer directamente SUI. Los usuarios pueden pagar tarifas de gas con stablecoins o con tokens de utilidad, simplificando la experiencia para nuevos participantes. La abstracción de cuenta también habilita firmas sociales, donde varias partes pueden autorizar una transacción conjunta, reduciendo la fricción para aplicaciones DeFi colaborativas.

Beneficios de la Abstracción:

• On‑boarding sin SUI: Los nuevos usuarios pueden crear una cuenta con una simple firma de email o wallet social, sin necesidad de adquirir SUI primero.
• Pagos de Gas Flexibles: Los contratos pueden pagar gas en USDC, USDT o incluso en tokens de proyecto, eliminando la barrera de poseer SUI para usar DEX o prestar.
• Seguridad Mejorada: Al separar la lógica de autorización del pago de gas, se reducen los vectores de ataque tradicionales asociados al manejo de claves privadas.

3. Primitivos Financieros Nativos​

Stablecoins Nativas​

• AUSD (Agora Finance): La primera stablecoin 100 % respaldada en USD nativa de Sui, lanzada en 2024, que rápidamente añadió liquidez al ecosistema.
• BUCK (Bucket Protocol): Stablecoin sobre‑colateralizada similar a DAI, con suministro de $60–66 M a mediados de 2025.
• USDY (Ondo Finance): Stablecoin generadora de rendimiento que tokeniza rendimientos de bonos del Tesoro de EE. UU., ofreciendo un activo de bajo riesgo con rendimiento integrado.

BTCfi e Integraciones​

• tBTC (Threshold Network): Token descentralizado 1:1 respaldado por Bitcoin, lanzado en julio de 2025, desbloqueando más de $500 M de liquidez BTC para protocolos de Sui.
• sBTC (Stacks): Representación 1:1 de Bitcoin a través de Stacks, que para mayo de 2025 constituía más del 10 % del TVL de Sui.

AMM Avanzados y HFT​

• Bluefin Institutional HFT: Estrategias de trading de alta frecuencia implementadas en Sui, aprovechando la ejecución paralela para lograr latencias sub‑segundo.
• Magma ALMM y Momentum CLMM: Diseños de AMM que concentran y ajustan dinámicamente la liquidez, mejorando la eficiencia de capital.

Plataformas Integradas​

• Graviton: Proyecto modular de trading, préstamo y margen cruzado con una financiación de $50 M (Series A), comparado con dYdX para traders profesionales.
• xMoney/xPortal MasterCard: Tarjeta MasterCard impulsada por cripto que permite gastar activos basados en SUI en comercios cotidianos, creando un puente CeFi‑DeFi.

4. Resumen​

En 2025, el ecosistema DeFi de Sui florece con innovación. La liquidez ha alcanzado niveles multimillonarios, impulsada por DEX de alto rendimiento y plataformas de préstamo robustas, mientras que la abstracción de cuenta y el diseño centrado en el usuario han mejorado drásticamente la experiencia, atrayendo a una audiencia más amplia. La próxima ola de primitivos – desde stablecoins nativas y la integración de Bitcoin hasta AMM avanzados, perps institucionales y tokens respaldados por activos reales – está ampliando lo que es posible en finanzas descentralizadas. Las alianzas estratégicas con proveedores de infraestructura, instituciones TradFi y redes cross‑chain continúan amplificando el impulso de Sui, consolidándola como un hub DeFi líder para 2025.

Fuentes:

• Sui Foundation – Resumen DeFi Q2 2025 de Sui (15 jul 2025)
• Sui Foundation – NEAR Intents trae swaps cross‑chain ultrarrápidos a Sui (17 jul 2025)
• Sui Foundation – Sui soportará sBTC y Stacks (casos de uso BTCfi) (1 may 2025)
• Sui Foundation – Todo sobre la Abstracción de Cuenta (4 oct 2023)
• Ainvest News – El TVL de Sui supera los $1.4 B impulsado por protocolos DeFi (14 jul 2025)
• Ainvest News – El TVL DeFi de Sui sube un 480 % a $1.8 B... (12 jul 2025)
• Suipiens (comunidad Sui) – Integración tBTC lleva liquidez Bitcoin a Sui (17 jul 2025)
• Suipiens – Dentro de Suilend: la plataforma de préstamos líder de Sui (3 jul 2025)
• The Defiant – Ondo lleva stablecoins respaldadas por RWA a Sui (7 feb 2024)
• Documentación oficial de Sui – Introducción a Sui: Experiencia de Usuario (funciones de abstracción de cuenta)

Visión General​

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

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

1. Trayectoria de Desarrollo​

Aptos​

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

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

Sui​

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

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

2. Comparación de Arquitectura Técnica​

3. Ecosistema On‑Chain y Casos de Uso​

3.1 Escala y Crecimiento del Ecosistema​

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

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

3.2 Casos de Uso Dominantes​

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

4. Evolución y Estrategia​

Aptos

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

Sui

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

5. Diferencias Clave y Desafíos​

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

6. Camino hacia la Adopción Masiva​

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

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

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

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