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

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.