Explorar
Conéctate con comunidades y descubre nuevas ideas.
Gana tu parte de 1000 Sui
Gana puntos de reputación y obtén recompensas por ayudar a crecer a la comunidad de Sui.
Comunidades
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.
Publicaciones principalesMiembros principales- 701
- 618
- 595
Move is an executable bytecode language used to implement custom transactions and smart contracts.
Publicaciones principalesMiembros principales- 271
- 260
- 251
Peera is a decentralized questions and answers protocol for Web3 where users can organize and store their interests and skills, creating a common community platform
Publicaciones principalesMiembros principales- 328
- 286
- 225
The InterPlanetary File System (IPFS) is a protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system.
Publicaciones principalesMiembros principales- 25
- 20
- 20
Walrus is a decentralized storage and data availability protocol designed specifically for large binary files, or "blobs"
Publicaciones principalesMiembros principales- 41
- 40
- 38
Recompensa
- +15Xavier.eth313ParaSuiJun 27, 2025
Fallo en la transacción Sui: objetos reservados para otra transacción
Me encuentro con un problema persistente JsonRpcErroral intentar ejecutar transacciones en Sui. El error indica que los objetos están reservados para otra transacción, aunque he implementado el procesamiento secuencial de las transacciones con retrasos. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 He intentado: Ejecución secuencial de la transacción (esperando a que se complete la transacción anterior) Se agregaron retrasos de 3 segundos entre transacciones Y sigo recibiendo el mismo error de forma constante. Uso de Sui RPC para el envío de transacciones. El mismo ID de objeto aparece varias veces en la lista de objetos bloqueados. El error se produce incluso con una secuenciación cuidadosa de las transacciones. ¿Qué hace que los objetos se «reserven» para otras transacciones? ¿Cómo puedo comprobar correctamente si un objeto está disponible antes de usarlo en una transacción? ¿Existen mejores prácticas para gestionar los bloqueos de objetos en Sui? ¿Podría estar relacionado con el tiempo de finalización de la transacción? ¿Alguien se ha encontrado con este problema antes? ¡Cualquier información sobre la gestión adecuada de objetos en las transacciones de Sui sería muy apreciada!
24 - +15Xavier.eth313ParaSuiJun 17, 2025
¿Cómo interactúan las restricciones de capacidad con los campos dinámicos en colecciones heterogéneas?
Estoy creando un mercado que necesita gestionar varios tipos de activos con diferentes requisitos de capacidad, y me he planteado algunas preguntas fundamentales sobre el sistema de tipos de Move. Quiero almacenar diferentes tipos de activos en la misma colección, pero tienen diferentes capacidades: NFT normales: key + store(transferibles) Tokens Soulbound: key únicamente (no transferibles) Activos personalizados con restricciones de transferencia public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } Preguntas clave: Requisitos de habilidad: Cuando se usadynamic_field::add(), ¿Vsiempre se necesita store en tiempo de compilación? ¿Pueden los tipos de contenedores solucionar esto? Almacenamiento heterogéneo: ¿puede una sola bolsa almacenar objetos con diferentes conjuntos de habilidades (key + store + copycontrakey + store) y manipularlos de forma diferente durante el tiempo de ejecución? Seguridad de tipos: dado que los campos dinámicos eliminan los tipos, ¿cómo puedo mantener la seguridad de los tipos al recuperar los valores? ¿Cuál es el patrón para almacenar los metadatos de tipo? Patrón de testigos: ¿Cómo funcionan las restricciones de habilidad con los tipos de fantasmas? ¿Puedo AssetAssetguardarlos en la misma colección y extraer la información de tipos más adelante? Construir un sistema en el que los NFT, los tokens de soul bound y los activos restringidos requieran funciones de mercado, pero con una semántica de transferencia diferente. He probado los tipos de contenedores, varias colecciones por conjunto de habilidades y el almacenamiento de metadatos de tipos separados. Cada uno tiene sus ventajas y desventajas entre la seguridad del tipo, los costos de la gasolina y la complejidad.
04 - +10ParaSuiMay 29, 2025
¿Por qué BCS requiere un orden de campo exacto para la deserialización cuando las estructuras Move tienen campos con nombre?
¿Por qué BCS requiere un orden exacto de los campos para la deserialización cuando las estructuras de Move tienen campos con nombre? He profundizado en la codificación y decodificación de BCS en Move, especialmente para la comunicación entre cadenas y el procesamiento de datos fuera de la cadena. Mientras estudiaba los ejemplos de la documentación de Sui Move, me encontré con algunos comportamientos que parecen contradictorios y estoy intentando entender las decisiones de diseño subyacentes. Según la especificación de BCS, «no hay estructuras en BCS (ya que no hay tipos); la estructura simplemente define el orden en el que se serializan los campos». Esto significa que, al deserializar, debemos usar peel_*las funciones exactamente en el mismo orden en que se definieron los campos de estructura. Mis preguntas específicas: Justificación del diseño: ¿Por qué BCS exige que los campos coincidan exactamente en el orden de los campos cuando las estructuras de movimiento tienen campos con nombre? ¿No sería más sólido serializar los nombres de los campos junto con los valores, de forma similar a JSON u otros formatos autodescriptivos? Interacción de tipos genéricos: Los documentos mencionan que «los tipos que contienen campos de tipo genérico se pueden analizar hasta el primer campo de tipo genérico». Considera esta estructura: struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } ¿Cómo funciona exactamente la deserialización parcial aquí? ¿Puedo deserializar hasta more_metadata e ignorar ambos campos genéricos, o el primer campo genérico (generic_data) bloquea por completo la deserialización posterior? Coherencia entre idiomas: al utilizar la biblioteca JavaScript @mysten /bcs para serializar los datos que consumirán los contratos de Move, qué ocurre si: ¿Reordeno accidentalmente los campos del objeto de JavaScript? ¿La definición de la estructura Move cambia el orden de los campos en una actualización de contrato? ¿Tengo estructuras anidadas con sus propios parámetros genéricos? Implicaciones prácticas: En los sistemas de producción, ¿cómo gestionan los equipos la evolución del esquema BCS? ¿Versionan sus esquemas de BCS o esperan que el orden de los campos de las estructuras sea inmutable una vez implementados?
53
Más reciente
¿Cómo recuperar monedas SUI de una billetera antigua?
He estado intentando localizar mis monedas SUI al configurar una nueva cuenta de Slush, pero no las veo. ¿Cómo puedo comprobar si estoy usando la frase correcta para importar mi antigua cartera?
02Dominar los conceptos del lenguaje en movimiento — Curso #2
Si bien elCurso #1 que he hecho anteriormente te ha enseñado los conceptos básicos para escribir contratos inteligentes en Move y crear dApps sencillas en la cadena de bloques Sui, este curso se centra enprofundizar tu comprensión del propio lenguaje Move, desde su potente sistema de tipos hasta patrones avanzados como genéricos, eventos, módulos y mecanismos de control de acceso. Al final de este curso, podrás: Escribe código Move modular, reutilizable y seguro Usa genéricos, habilidades y tipos de recursos de manera efectiva Implemente un control de acceso detallado mediante capacidades Emita y escuche eventos para la integración fuera de la cadena Trabaja con estructuras de datos complejas, como tablas y vectores Comprenda en qué se diferencia Move de otros lenguajes de contratos inteligentes como Solidity ¡Sumérjase en el corazón del lenguaje de Move! Paso 1: Entender las principales características lingüísticas de Move Move está diseñado pensando en la seguridad y la claridad. Analicemos algunas de las características más importantes que hacen que Move sea único como lenguaje de contratos inteligentes. 1.1 Programación orientada a los recursos (revisada) La esencia de Move es el concepto derecursos, que son tipos especiales que no se pueden copiar ni eliminar a menos que se permita explícitamente. Esto refuerza el manejo seguro de los activos digitales, como los tokens o los NFT. module examples::token { use sui::object::{Self, UID}; struct MyToken has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext): MyToken { MyToken { id: object::new(ctx), value: 100, } } } En este ejemplo: MyToken- keyes unrecursoporque tiene la capacidad. store- Puede almacenarse (id) e identificarse de forma única por su. No se puede duplicar ni eliminar a menos que se especifique lo contrario. Esto garantiza que cada MyTokeninstancia tenga una propiedad y una administración únicas, lo que evita la duplicación o la eliminación accidental. 1.2 Sistema de habilidades Cada tipo de movimiento tiene un conjunto dehabilidadesque definen las operaciones que admite: | Habilidad | Significado | | --------| ---------| | copy| Se puede duplicar | | drop| Puede desecharse sin destruirse | | store| Se puede almacenar en un almacenamiento global | | key| Se puede usar como una estructura con un campo de identificación (es decir, un objeto) | Ejemplo: struct Example has copy, drop { value: u64 } Comprender estas habilidades es esencial para diseñar contratos inteligentes seguros y predecibles. Por qué son importantes las habilidades Las habilidades imponen reglas estrictas en el momento de la compilación. Por ejemplo: Una estructura que solo tiene keyy storeno se puede copiar ni borrar. No puedes devolver una estructura que no se pueda borrar de una función a menos que esté almacenada o transferida. Esto evita errores como el doble gasto o la pérdida accidental de fichas. 1.3 Parámetros genéricos y de tipo Move admite tipos genéricos, lo que permite a los desarrolladores escribir código flexible y reutilizable. module examples::storage { use sui::object::{Self, UID}; struct Box has key { id: UID, content: T, } public fun new_box(ctx: &mut TxContext, content: T): Box { Box { id: object::new(ctx), content, } } } Aquí `hay unparámetro de tipo, que permite Box`trabajar con cualquier tipo sin dejar de ser seguro y eficiente. Nota: La phantompalabra clave indica que eso Tno afecta a la representación de la estructura en tiempo de ejecución, lo que resulta útil para el modelado abstracto. Paso 2: Desarrollo modular y gestión de paquetes A medida que sus proyectos de Move aumentan en complejidad, la organización del código se vuelve fundamental. 2.1 Creación y publicación de paquetes de Move Unpaquete Movecontiene uno o más módulos y define las dependencias. Es la unidad de implementación y control de versiones en Move. Estructura de directorios: sources/ place.move user.move Move.toml Move.tomlDefina las dependencias en: [dependencies] Sui = { git = "https://github.com/MystenLabs/sui.git", subdir = "crates/sui-framework" } MyLibrary = { local = "../my-library" } Puede publicar paquetes en la red Sui y reutilizarlos en varias dApps. 2.2 Reutilización de los módulos existentes cointransfertx_contextElSui Frameworkproporciona módulos probados en batalla como, y. Comprueba siempre lo que está disponible antes de escribir una lógica personalizada. Por ejemplo, para transferir un objeto: use sui::transfer; public entry fun send_place(place: Place, recipient: address) { transfer::public_transfer(place, recipient); } El uso de bibliotecas estándar garantiza un desarrollo más rápido y seguro y una mejor interoperabilidad. Paso 3: Eventos y comunicación fuera de la cadena Para crear aplicaciones reales, tus contratos de Move deben comunicarse con sistemas fuera de la cadena, como interfaces o indexadores. 3.1 Emisión de eventos Move permite emitireventosque pueden ser indexados por servicios externos. use sui::event; struct PlaceCreated has drop { name: String, } public fun emit_place_created(name: String) { event::emit(PlaceCreated { name }); } Este evento aparecerá en la cadena de bloques y los exploradores o las herramientas de indexación pueden recogerlo. 3.2 Escuchando eventos Usa herramientas comoSuite Explorer,Subsquido la API JSON-RPC de Sui para detectar los eventos emitidos y reaccionar en consecuencia en tu aplicación. En Javascript/TypeScript: import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); const events = await provider.getEvents({ MoveEventType: '0x...::example::PlaceCreated' }); Paso 4: Patrones de control de acceso y seguridad La seguridad es primordial cuando se trata de contratos inteligentes. Move proporciona varias herramientas para implementar un control de acceso sólido. 4.1 Modelo de propiedad de objetos Sui impone la propiedad a nivel de protocolo. Solo el propietario de un objeto puede mutarlo o transferirlo. public entry fun update_name(sweet_place: &mut SweetPlace, new_name: String) { sweet_place.name = new_name; } Solo el propietario actual puede llamar a esta función. 4.2 Patrón de capacidades Para obtener permisos más detallados, usa elpatrón de capacidades: crea objetos especiales que otorguen acceso limitado a ciertas funciones. struct AdminCap has key { id: UID } public entry fun grant_admin_cap(ctx: &mut TxContext) { let cap = AdminCap { id: object::new(ctx) }; transfer::public_transfer(cap, tx_context::sender(ctx)); } public entry fun restricted_action(_: &AdminCap) { // perform admin action } Ahora solo los usuarios que tengan el AdminCappueden ejecutarrestricted_action. Este patrón se usa ampliamente en DeFi y DAoS para delegar la autoridad de forma segura. Paso 5: Trabajar con estructuras de datos complejas Move admite tipos de datos estructurados que permiten a los desarrolladores modelar relaciones y lógicas complejas. 5.1 Vectores Los vectores se utilizan para almacenar colecciones ordenadas de elementos del mismo tipo. let names = vector[String::utf8(b"Alice"), String::utf8(b"Bob")]; Son útiles para almacenar listas de NFT, funciones de usuario o metadatos dinámicos. Ejemplo de uso: vector::push_back(&mut names, String::utf8(b"Charlie")); 5.2 Tablas (a través de la biblioteca estándar Sui) Si bien Move no admite mapas ni tablas hash de forma nativa, Sui proporciona Tableeste tipo en su biblioteca estándar. use sui::table::{Self, Table}; struct Registry has key { id: UID, entries: Table, } public fun add_entry(registry: &mut Registry, key: u64, value: String) { table::add(&mut registry.entries, key, value); } Use tablas para administrar grandes conjuntos de datos de manera eficiente. Paso 6: Probar y depurar sus contratos Las pruebas garantizan que tu código Move se comporte según lo esperado en diversas condiciones. 6.1 Pruebas unitarias en Move Escribe las pruebas unitarias directamente en tus módulos de Move utilizando el marco de pruebas. #[test] public fun test_create_sweet_place() { let ctx = tx_context::dummy(); create_sweet_place(&mut ctx, String::utf8(b"My House")); } Ejecute pruebas con: sui move test 6.2 Uso de Sui Explorer Después de implementar tu contrato, usa el Sui Explorer para inspeccionar las transacciones, ver los estados de los objetos y solucionar problemas. Paso 7: Aplicaciones en el mundo real de los conceptos de movimiento avanzados Ahora que entiendes las principales características del lenguaje, exploremos cómo se aplican a situaciones del mundo real. 7.1 Plataforma de acuñación NFT Cree una plataforma que permita a los usuarios acuñar NFT con el respaldo de los recursos de Move, aprovechando los modelos de propiedad y recursos. 7.2 Sistema de votación DAO Implemente una organización autónoma descentralizada (DAO) con Move para votar, presentar propuestas y gobernar, utilizando eventos y capacidades para llevar a cabo acciones seguras. 7.3 Intercambios de tokens y AMM Cree una bolsa descentralizada (DEX) utilizando los módulos Move para representar los fondos de liquidez y las permutas de tokens, utilizando genéricos y tablas para una gestión estatal eficiente.
2- ParaSuiJun 30, 2025
¿Qué son las NFT dinámicas y por qué Sui sobresale en ellas?
El espacio de las NFT está evolucionando más allá de las imágenes estáticas y las imágenes de perfil (PFP). ¿La próxima frontera? Los NFT dinámicos (DNFT) son tokens que pueden cambiar en función de los datos del mundo real, las interacciones de los usuarios o los eventos en cadena. Si bien muchas cadenas de bloques admiten las NFT, Sui Network se encuentra en una posición única para impulsar el futuro de las DNFT gracias a su arquitectura innovadora. Este artículo explora: ¿Qué hace que una NFT sea «dinámica»? ¿Por qué la tecnología de Sui es perfecta para las DNFT Casos de uso del mundo real en la actualidad El futuro de los activos digitales interactivos #1. ¿Qué son las NFT dinámicas? A diferencia de los NFT tradicionales (que son estáticos e inmutables), los NFT dinámicos pueden actualizar sus: Metadatos (por ejemplo, un NFT deportivo que cambia en función de las estadísticas del juego) Apariencia (p. ej., una obra de arte que evoluciona con el tiempo) Utilidad (p. ej., un NFT de fidelización que desbloquea nuevas ventajas) ¿Cómo funcionan? Los DNFT utilizan una lógica de contrato inteligente y entradas de datos externas (oráculos, acciones de los usuarios, etc.) para activar los cambios. Ejemplo: Una obra de arte NFT sensible a la intemperie que cambia de color en función de los datos climáticos en tiempo real. Un NFT con un personaje de juego que sube de nivel a medida que juegas. #2. Por qué Sui es la mejor cadena de bloques para NFT dinámicas Si bien Ethereum y Solana también admiten las DNFT, el diseño de Sui ofrece ventajas clave: Almacenamiento en cadena (sin dependencias externas) La mayoría de las cadenas de bloques almacenan los metadatos de NFT fuera de la cadena (por ejemplo, IPFS), lo que dificulta las actualizaciones dinámicas. Sui almacena todo en cadena, lo que permite realizar modificaciones instantáneas y sin confianza. Move Language: actualizaciones seguras y flexibles La solidez de Ethereum requiere contratos de proxy complejos para poder actualizar las NFT. El lenguaje Move de Sui permite la mutabilidad nativa, sin soluciones complicadas. Procesamiento paralelo (escalabilidad masiva) ¿Actualizar miles de DNFT a la vez? Ethereum tiene problemas con la congestión. La ejecución paralela de Sui gestiona millones de actualizaciones sin ralentizaciones. Modelo centrado en objetos (control granular) Cada NFT es un objeto independiente con una lógica personalizable. Permite una interactividad precisa (por ejemplo, solo el propietario puede activar los cambios). #3. Casos de uso reales de DNFT en Sui Juegos y metaverso Objetos del juego que evolucionan (p. ej., una espada NFT que adquiere habilidades con el uso). Interoperabilidad entre juegos (los objetos de Sui pueden moverse entre las DApps). Ejemplo: *Los juegos basados en Sui, como Panzerdogs, utilizan DNFT para crear avatares personalizables. * Arte generativo y reactivo NFT impulsados por inteligencia artificial que cambian de estilo en función de las tendencias del mercado. Arte colaborativo en el que los coleccionistas influyen en la pieza final. Ejemplo: *Los laboratorios de arte como la Galería Sui albergan exposiciones de DnFt. * Seguimiento de activos del mundo real (RWA) NFT de escrituras que se actualizan con los registros de la propiedad. Insignias de certificación que caducan o se renuevan automáticamente. Programas de lealtad y membresía NFT de descuentos dinámicos que mejoran con el gasto de los clientes. Pases de acceso VIP que desbloquean nuevos niveles con el tiempo. Ejemplo: *Los socios minoristas de Sui están probando los programas de fidelización de DnFT. * #4. El futuro de los DNFT en Sui Espere ver: Los DNFT integrados en la IA (p. ej., los chatbots que viven en avatares de NFT). Los DNFT están garantizados por DeFi (el valor se ajusta en función de las condiciones del mercado). Juegos totalmente en cadena en los que cada activo es un dNFT mutable. Conclusión: Sui está construyendo el futuro de los NFT Si bien las NFT estáticas dominaron el período 2021-2023, las NFT dinámicas dominarán la próxima tendencia alcista, y la tecnología de Sui la convierte en la plataforma ideal. Con el almacenamiento en cadena, la seguridad de Move y una escalabilidad sin igual, Sui está a punto de convertirse en el hogar de los DNFT avanzados.
5
Sin respuesta
¿Cómo actualizar la clave de un comerciante en ObjectTable cuando cambia en la estructura?
Hola a todos, acabo de empezar a escribir contratos inteligentes y estoy trabajando en mi primer proyecto. Me encantaría recibir ayuda con un problema en el que estoy atrapado. Hasta ahora, he creado una Merchantestructura que se ve así: -id: un identificador único (UID) -owner: la dirección del comerciante -key: una cadena utilizada como clave única -balance: un u64 que representa su saldo También creé una MerchantRegistryestructura para administrar a todos los comerciantes: -id: otro identificador -merchant_to_address: una ObjectTableasignación de direcciones a los comerciantes -merchant_to_key: un ObjectTablemapeo de claves para los comerciantes Quiero poder buscar un comerciante por sudireccióno por suclave. MerchantCuando un usuario actualiza su clave dentro de la merchant_to_keyestructura, el cambio no actualiza automáticamente la clave de la tabla. Esto significa que la llave antigua sigue apuntando al comerciante, lo que descifra las cosas. Intenté eliminar la entrada de la tabla y volver a insertarla con la nueva clave, pero sigo encontrando errores como: «No se pueden ignorar los valores sin la habilidad de soltar» Estoy bastante seguro de que se trata de un error de principiante, pero no he podido encontrar una explicación o solución clara en ninguna parte. ¿Existe una forma adecuada de gestionar la actualización de la clave tanto en la estructura como en la tabla de búsqueda?
50- 0xduckmove618ParaSuiJun 06, 2025
¿Cuál es la interfaz más fácil para subir manchas de morsa?
¿solo una interfaz de usuario simple para subirla a Walrus? (además de Tusky)
20 ¿Qué pasa si no solicito ETH a través del puente Sui?
He estado usando el puente Sui para transferir algunos ETH, pero aún no los he reclamado porque las comisiones son bastante altas. ¿Qué pasará si lo dejo sin reclamar?
00
Tendencia
AMM Bot en el ecosistema Sui
¿Cuáles son las principales características y funcionalidades de los bots AMM dentro del ecosistema de Sui? ¿Cómo mejoran los mecanismos comerciales tradicionales y qué ventajas ofrecen a los usuarios que utilizan los protocolos DeFi en la red Sui? ¿Necesito construir uno o puedo usar Turbos Finance, por ejemplo
82- 0xduckmove618ParaSuiApr 08, 2025
👀 SEAL: creo que la privacidad de los datos de Web3 está a punto de cambiar
👀 SEAL está disponible en Sui Testnet. Creo que la privacidad de los datos de Web3 está a punto de cambiar En la Web3, es común escuchar frases como* «los usuarios son dueños de sus datos»* o* «descentralizado por diseño»*. Sin embargo, si se analiza detenidamente, muchas aplicaciones aún dependen de infraestructuras centralizadas para gestionar los datos confidenciales, y utilizan servicios como AWS o Google Cloud para la administración de claves. Esto introduce una contradicción: descentralización en la superficie, centralización en el fondo. Pero, ¿y si hubiera una forma de gestionar los secretos de forma segura, sin renunciar a la descentralización? Presentamos SEAL: Decentralized Secrets Management (DSM), que ya está disponible en la red de pruebas Sui. SEAL tiene como objetivo corregir una de las mayores hipocresías de Web3: propugnar la descentralización mientras usa AWS en secreto Quizás me preguntes: ¿Qué es SEAL? SEAL es un protocolo que te permite gestionar datos confidenciales de forma segura ydescentralizada, creado específicamente para el mundo de la Web3. Piense en ello como una capa de control de acceso que prioriza la privacidad y que se conecta a su dApp. Puede pensar en SEAL como una especie de bloqueo programable para sus datos. Con Move on Sui no solo bloqueas y desbloqueas archivos manualmente, sino queescribes políticas directamente en tus contratos inteligentes. Supongamos que estás creando una dApp en la que: Solo los titulares de NFT pueden desbloquear un tutorial premium O tal vez un DAO tenga que votar antes de que se revelen los archivos confidenciales O quieres que los metadatos estén bloqueados en el tiempo y que solo se pueda acceder a ellos después de una fecha específica SEAL hace que todo eso sea posible. El control de acceso funciona en cadena, es totalmente automatizado, sin necesidad de que un administrador lo gestione. Solo lógica, integrada directamente en la cadena de bloques. SEAL hace que todo eso sea posible. El control de acceso funciona en cadena, es totalmente automatizado, sin necesidad de que un administrador lo gestione. Solo lógica, integrada directamente en la cadena de bloques. Otra pieza interesante es cómo SEAL maneja elcifrado. Utiliza algo llamadocifrado de umbral, lo que significa que ningún nodo puede descifrar los datos por sí solo. Se necesita un grupo de servidores para trabajar juntos, algo parecido a la firma múltiple, pero para desbloquear secretos. Esto distribuye la confianza y evita el problema habitual de un único punto de fallo. Y para mantener la verdadera privacidad, SEAL cifra y descifra todo lo que esté en el lado del cliente**. Tus datos nunca son visibles para ningún backend. Permanecen en tus manos, literalmente, en tu dispositivo. y a SEAL no le importa dónde guardes tus datos. Ya sea IPFS, Arweave, Walrus o alguna otra plataforma, SEAL no intenta controlar esa parte. Solo se centra enquién puede ver qué, no en dónde se almacenan las cosas. Así que sí, no se trata solo de una biblioteca o API, sino de unacapa que prioriza la cadena, el acceso controlado y la privacidad por defectopara tu DApp. SEAL llena un vacío bastante crítico. Vamos a desglosarlo un poco más. Si estás creando una dApp que tratacualquier tipo de datos confidenciales(contenido cerrado, documentos de usuario, mensajes cifrados e incluso metadatos de NFT bloqueados por tiempo), te encontrarás con el mismo problema: ➡️ ¿Cómo se gestiona el acceso de forma segura, sin depender de un servicio centralizado? Sin algo como SEAL, la mayoría de los equipos tampoco: Utilice herramientas centralizadas como AWS KMS o Firebase, lo que claramente va en contra de la descentralización O trate de arreglar ellos mismos la lógica de cifrado a medias, que por lo general termina siendo frágil y difícil de auditar https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22 Ninguno de los dos se ajusta bien. Especialmente cuando intentas crear aplicaciones confiables en múltiples cadenas o comunidades. SEAL hace que todo ese proceso sea modular y programable. Usted define las reglas de acceso en los contratos inteligentes de Move y SEAL se encarga del resto (generación de claves, aprobación del descifrado y control del acceso), todo ello sin que nadie emita las claves manualmente ni realice comprobaciones de backend. Y lo que es mejor, esas reglas sonauditables e inmutables: una vez que están en cadena, se rigen por el contrato, no por un administrador humano. Así que en lugar de preguntar «¿quién debe gestionar el acceso a estos datos?» solo tienes que preguntar: «¿Qué lógica debería definir el acceso?» > ... y deja que la cadena se encargue. Limpio y escalable. Eso es lo que hace que SEAL sea relevante para algo más que «herramientas de seguridad»: es una capa base para cualquier dApp que se preocupe por la privacidad, el cumplimiento o la lógica de acceso dinámico.** Es un cambio pequeño, pero cambia mucho la forma en que pensamos sobre los datos en la Web3. En lugar de cifrarlos después de la implementación o confiar en servicios externos,se empieza con la privacidad integrada y el acceso se gestiona completamente mediante la lógica de los contratos inteligentes. Y eso es exactamente lo que Web3 necesita ahora mismo. ¿Cómo funciona realmente SEAL? Hemos explicadoqué es SEALypor qué Web3lo necesita**. Veamos cómo se construye realmente bajo el capó. En esta parte es donde las cosas se vuelven más técnicas, pero en el buen sentido. La arquitectura es elegante una vez que ves cómo encajan todas las piezas. En un nivel superior, SEAL combina lalógica de acceso en cadenacon lagestión de claves fuera de la cadena, mediante una técnica denominadaCifrado basado en la identidad (IBE). Esto permite a los desarrolladores cifrar los datos para convertirlos en una identidad y, luego, confiar en contratos inteligentes para definir *quién puede descifrarlos. Paso 1: reglas de acceso en los contratos inteligentes (en Sui) Todo comienza con el contrato inteligente. Cuando utilizas SEAL, defines una función llamada seal_approve en tu contrato de Move; aquí es donde escribes las condiciones para el descifrado. Por ejemplo, esta es una sencilla regla de bloqueo temporal escrita en Move: entry fun seal_approve(id: vector, c: &clock::Clock) { let mut prepared: BCS = bcs::new(id); let t = prepared.peel_u64(); let leftovers = prepared.into_remainder_bytes(); assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess); } Una vez desplegado, este contrato actúa como guardián. Siempre que alguien quiera descifrar datos, su solicitud se comparará con esta lógica. Si se aprueba, la clave se libera. Si no, están bloqueados. Nadie tiene que intervenir. ##Paso 2: Cifrado basado en la identidad (IBE) Aquí es donde ocurre la magia. En lugar de cifrar los datos de una dirección de monedero específica (como en el caso de PGP o RSA), SEAL utilizacadenas de identidad, lo que significa que los cifras de forma similar a: 0 x dirección de monedero dao_vote: proposal_xyz PKGID_2025_05_01 (una regla basada en la marca de tiempo) o incluso game_user_nft_holder Cuando los datos están cifrados, tienen el siguiente aspecto: Encrypt(mpk, identity, message) mpk = clave pública maestra (conocida por todos) identidad = el destinatario definido de forma lógica mensaje = los datos reales Más adelante, si alguien quiere descifrarlos, el servidor de claves comprueba si cumplen con la política (mediante la llamada en cadena seal_approve). Si se aprueba, devuelve una clave privada derivada para esa identidad. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) A continuación, el usuario puede descifrar el contenido localmente. Por lo tanto, el cifrado se realiza sin necesidad de saber con antelación quién lo descifrará. Solo tiene que definir las condiciones y SEAL se encargará del resto más adelante. Es dinámico. ##Paso 3: El servidor de claves: fuera de la cadena, pero no centralizado Quizás te preguntes: ¿quién tiene estas llaves maestras? Aquí es donde entra en juego elservidor de clavede SEAL. Piense en ello como un backend que: Contiene la clave secreta maestra (msk) Controla los contratos en cadena (como tu lógica seal_approve) Solo emite claves derivadas si se cumplen las condiciones Pero, y esto es clave, SEAL no depende solo de un servidor de claves. Puedes ejecutarlo enmodo umbral, donde varios servidores independientes deben ponerse de acuerdo antes de emitir una clave de descifrado. Por ejemplo: 3 de cada 5 servidores de claves deben aprobar la solicitud. Esto evita los puntos centrales de falla y también permite la descentralización en la capa de administración de claves. Aún mejor, en el futuro, SEAL admitiráMPC (computación multipartita) yconfiguraciones basadas en enclaves(como TEE), por lo que puede obtener garantías aún más sólidas sin comprometer la usabilidad. ##Paso 4: Descifrado del lado del cliente Una vez que se devuelve la clave al usuario, el descifrado propiamente dicho se lleva a caboen su dispositivo. Esto significa: El servidor nunca ve tus datos El backend nunca almacena contenido descifrado Solo el usuario puede acceder al mensaje final Es un modelo de privacidad sólido. Incluso si alguien pone en peligro la capa de almacenamiento (IPFS, Arweave, etc.), no podrá leer los datos sin pasar por la lógica de acceso. Este es el modelo mental rápido: Esta estructura facilita la creación de dApps en las que las reglas de acceso no estén codificadas: son dinámicas, auditables y están totalmente integradas en la lógica de la cadena. ##El equipo detrás de SEAL SEAL está dirigido porSamczsun, una figura muy conocida en la comunidad de seguridad de cadenas de bloques. Anteriormente fue socio de investigación en Paradigm, y ha auditado múltiples ecosistemas y los ha salvado de grandes vulnerabilidades. Ahora, se dedica a tiempo completo a convertir a SEAL en una pieza central de la infraestructura de privacidad de Web3. Con su experiencia y credibilidad, SEAL no es solo otra herramienta experimental: es un intento serio de hacer que la privacidad de datos descentralizada sea práctica y escalable. A medida que SEAL se lanza en la red de pruebas Sui, incorpora un nuevo estándar sobre la forma en que las aplicaciones Web3 pueden gestionar los secretos. Al combinar el control de acceso en cadena, el cifrado de umbrales y la privacidad del lado del cliente, SEAL ofrece una base más confiable para el manejo descentralizado de datos. Ya sea que estés creando dApps, DAO o juegos descentralizados, SEAL proporciona un potente conjunto de herramientas para reforzar el control de acceso y proteger los datos de los usuarios sin comprometer la descentralización. Si Web3 quiere avanzar, una infraestructura segura como SEAL no es opcional, es esencial
8 ¿La única forma de publicar los paquetes de Move es a través de una EOA?
Supongo que no hay forma en la cadena Sui, ya que no hay ningún módulo en la cadena que publique paquetes.
73