Tendencia
Descubre las publicaciones más populares.
Publicaciones
2739Sui’s Big Picture: A Blockchain Operating System for Everything?
Sui isn’t just pushing DeFi. The 10 being worked products in red — Walrus Millionaire (quests), *land (RWA), *human (personhood), updown (prediction markets), SuiSnaps (secret NFTs), CryptoGuard (DeFi security), *pay (new payments), Smash (social network), Drones/Humanoids (robots), RWA (tokenized assets) — show a much broader ambition. When combined with infrastructure projects like Walrus (storage), Scion (fast internet), internetless (low-signal mode), Prog Txn Block, Sponsored Txn, zkLogin, DeepBook, SuiBridge, Sui is positioning itself as a full-stack blockchain computer: handling storage, identity, finance, payments, social, entertainment, and even robotics — potentially able to run apps even in offline or low-connectivity environments. Is Sui truly building the first blockchain operating system that unifies all these layers? Which of these narratives — finance (RWA, CryptoGuard), social (Smash, SuiSnaps), or futuristic (internetless, robots) — will drive adoption first?
- Sui
- Architecture
1414AMM 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
- Sui
96Mejor Respuesta- Artículo0xduckmove2078ParaSuiApr 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
- Sui
- Architecture
- SDKs and Developer Tools
8 ¿Cómo combino dos objetos de monedas en Move?
*Estoy intentando entender este aspecto de la red Sui porque estoy creando, depurando o implementando algo relacionado con esta área. Quiero una explicación detallada de cómo funciona este mecanismo o función, junto con el uso relevante de la CLI, la estructura del código de Move o los conceptos arquitectónicos. Mi objetivo es obtener la suficiente claridad para aplicar este conocimiento en un proyecto real, ya sea un contrato inteligente personalizado, un sistema NFT, una integración de monederos o una herramienta DeFi. La red Sui tiene características únicas en comparación con las cadenas de EVM, por lo que me interesa especialmente saber qué la diferencia y cómo afecta eso a las mejores prácticas de desarrollo. Sería útil tener un código de ejemplo, ejemplos de líneas de comandos o errores típicos a los que prestar atención, especialmente cuando se utiliza la CLI o el SDK de Sui o se implementa en localnet/testnet. En última instancia, quiero evitar errores comunes, seguir los mejores principios de seguridad y asegurarme de que la funcionalidad en la que estoy trabajando se comporte como se espera en condiciones realistas. *
- Sui
- Architecture
- SDKs and Developer Tools
- NFT Ecosystem
715Mejor Respuesta
Sui Passkey Adoption
Sui Introduces Passkey: Seamless Web3 Onboarding and Developer Integration Published: August 7, 2025 | Source: Sui Foundation The Sui ecosystem has unveiled passkey support on Mainnet, a breakthrough designed to make Web3 access as simple as logging into your favorite mobile app. With passkey, users can sign in using familiar methods like Face ID, fingerprint recognition, or a device passcode, eliminating the need for browser extensions, seed phrases, or complicated setup flows. This isn’t just a quality-of-life upgrade. It represents a paradigm shift in blockchain usability, aligning the Sui experience with the same authentication standards that already power billions of daily logins across the internet. What is a Passkey? A passkey is a cryptographic credential that leverages device-native authentication. Instead of managing private keys or recovery phrases, users access applications with biometrics or passwords already supported by their phones, laptops, or hardware devices. Built on open standards:* Passkey follows the *FIDO Alliance* and *W3C WebAuthn** specifications. Widely supported:** Apple, Google, and Microsoft all support passkeys across their platforms. Secure and recoverable:* Because credentials can be *cloud-synced**, users can restore access when switching devices—without awkward recovery phrases. By integrating this model, Sui makes blockchain access feel familiar, intuitive, and as frictionless as signing into a banking or email app. Why Passkey Matters For Users Passkey removes many of the biggest barriers to blockchain adoption: No more seed phrases to memorize. No browser extensions to install. Authentication flows that feel just like Web2 apps. Enhanced recovery thanks to cross-device syncing. Support for advanced setups like multisig wallets or pairing passkeys with zkLogin for layered security. The experience is especially powerful on mobile, where the complexity of traditional wallets has long been a blocker to mainstream adoption. For Developers Passkey also reshapes the developer landscape: Direct integration:** Apps no longer need to depend on third-party wallets for onboarding. Lightweight setup:** Passkey support is built into the Sui TypeScript SDK. Advanced capabilities:** Developers can enable QR-based cross-device login, multisig authentication, and native biometric login. Better retention:** Reducing setup friction lowers user drop-off rates during onboarding. Building with Passkey on Sui The Sui TypeScript SDK introduces the PasskeyKeypair class to make integration straightforward. Developers can create, recover, and use passkeys with just a few lines of code. Importing the PasskeyKeypair import { BrowserPasskeyProvider, BrowserPasswordProviderOptions, PasskeyKeypair, } from '@mysten/sui/keypairs/passkey'; Creating a New Passkey To initialize a passkey wallet tied to your app’s domain: const keypair = await PasskeyKeypair.getPasskeyInstance( new BrowserPasskeyProvider('Sui Passkey Example', { rpName: 'Sui Passkey Example', rpId: window.location.hostname, authenticatorSelection: { authenticatorAttachment: 'cross-platform', // or "platform" }, } as BrowserPasswordProviderOptions), ); cross-platform**: Works with hardware keys and mobile devices. platform**: Uses device-bound authenticators like Touch ID, Face ID, or Windows Hello. It’s recommended to cache the PasskeyKeypair in your frontend so the public key is always available when signing transactions. Recovering a Passkey If the cached keypair is lost or the user switches devices, recovery is possible: let provider = new BrowserPasskeyProvider('Sui Passkey Example', { rpName: 'Sui Passkey Example', rpId: window.location.hostname, } as BrowserPasswordProviderOptions); const testMessage = new TextEncoder().encode('Hello world!'); const possiblePks = await PasskeyKeypair.signAndRecover(provider, testMessage); const testMessage2 = new TextEncoder().encode('Hello world 2!'); const possiblePks2 = await PasskeyKeypair.signAndRecover(provider, testMessage2); const commonPk = findCommonPublicKey(possiblePks, possiblePks2); const keypair = new PasskeyKeypair(commonPk.toRawBytes(), provider); With two signed messages, a unique public key can be reconstructed. Alternatively, apps can prompt users to sign one message and resolve the correct public key by checking on-chain activity. Using PasskeyKeypair Once initialized, usage mirrors any other keypair in the SDK: const publicKey = keypair.getPublicKey(); const address = publicKey.toSuiAddress(); const message = new TextEncoder().encode('hello world'); const { signature } = await keypair.signPersonalMessage(message); const txSignature = await passkey.signTransaction(txBytes); Full implementation examples are available in the MystenLabs passkey repo. Supported Platforms Sui’s passkey implementation works with any device that complies with WebAuthn. That includes most modern browsers and operating systems on both desktop and mobile. Developers and users can reference the Passkeys.dev device support list for a breakdown of compatible platforms and authenticators. Nimora: The First Passkey Wallet The first real-world wallet to support passkeys on Sui is Nimora. It demonstrates how seamless onboarding and transaction signing can feel when blockchain fades into the background, letting users interact as naturally as they would with any modern app. Looking Ahead The launch of passkey is more than a feature—it’s a glimpse of the future. Just as the web moved from clunky logins to biometric and single sign-on systems, Web3 is undergoing its own transformation. By prioritizing both security and simplicity, Sui is setting a new industry standard. If widely adopted, passkeys could finally relegate seed phrases and confusing onboarding flows to blockchain’s early history. For users, it’s effortless access. For developers, it’s a lighter integration path. For Web3, it’s a necessary evolution toward mass adoption.
- Sui
- Architecture
- SDKs and Developer Tools
7¿Cómo cambio entre Testnet y Mainnet mediante la CLI de SUI?
Intento entender este aspecto de la red Sui porque estoy creando, depurando o implementando algo que toca esta área. Quiero una explicación detallada de cómo funciona este mecanismo o función, junto con el uso relevante de la CLI, la estructura del código de Move o los conceptos arquitectónicos. Mi objetivo es obtener la suficiente claridad para aplicar este conocimiento en un proyecto real, ya sea un contrato inteligente personalizado, un sistema NFT, una integración de monederos o una herramienta DeFi. La red Sui tiene características únicas en comparación con las cadenas de EVM, por lo que me interesa especialmente saber qué la diferencia y cómo afecta eso a las mejores prácticas de desarrollo. Sería útil tener un código de ejemplo, ejemplos de líneas de comandos o errores típicos a los que prestar atención, especialmente cuando se utiliza la CLI o el SDK de Sui o se implementa en localnet/testnet. En última instancia, quiero evitar errores comunes, seguir los mejores principios de seguridad y asegurarme de que la funcionalidad en la que estoy trabajando se comporte como se espera en condiciones realistas.
- Sui
- NFT Ecosystem
- Move
717Mejor Respuesta- P&R expertosParaSuiJun 30, 2025
Why can’t I connect my wallet to a Sui dApp?
I’m trying to use a Sui dApp (like Tradeport, SuiSwap, or a custom platform), but my wallet won’t connect properly. Sometimes, I get no error at all—just nothing happens when I click "Connect Wallet." Other times, I see errors like: "Wallet not detected" (even though I have Sui Wallet or another wallet installed) "Connection failed: Invalid account" "Transaction rejected" before I even approve anything What I’ve tried: Refreshing the page Switching browsers (Chrome, Firefox, Brave) Checking wallet extension permissions Trying different networks (Devnet, Testnet, Mainnet) Reinstalling the wallet extension Questions: Why does this happen, and how can I fix it? Are there common mistakes users make when connecting wallets to Sui dApps? If my wallet was working before but suddenly stopped, what could be the cause?
- Sui
- Transaction Processing
71Mejor Respuesta ¿Cómo implementar la serialización personalizada en los objetos Sui Move?
Objetivos: ✔ Optimice la eficiencia del almacenamiento (reduzca la sobrecarga del BCS) ✔ Habilite la compatibilidad entre cadenas (por ejemplo, Ethereum ABI) ✔ Soporta actualizaciones de esquemas versionados ✔ Maneje estructuras complejas de objetos anidados Desafíos actuales: bcs::serializees demasiado rígido para formatos personalizados Problemas de serialización de estructuras recursivas Necesidades de deserialización compatibles con versiones anteriores ###Preguntas clave 1.Rendimiento y costo ¿Cuál es el patrón de serialización más eficiente en cuanto al consumo de gas para los objetos Sui? 2.Control de versiones y actualizaciones ¿Cómo implementar la codificación/decodificación compatibles con versiones anteriores con el control de versiones? 3.Manejo de datos complejos ¿Mejores prácticas para serializar objetos anidados y tipos recursivos? 4.Consideraciones de seguridad ¿Cómo evitar los errores más comunes (por ejemplo, la maleabilidad o la denegación de servicio mediante datos mal formados)?
- Sui
76- P&R expertosParaSuiJul 18, 2025
Implementación de sistemas de regalías para Sui NFT
####Requisitos del proyecto Estoy desarrollando una colección de NFT en Sui con las siguientes necesidades: Regalías en cadena: recortes porcentuales aplicables Flexibilidad: diferentes tarifas por NFT/colección Compatibilidad con el mercado: funciona con las principales plataformas Capacidad de actualización: velocidades ajustables sin dañar las NFT existentes ####Desafíos actuales Las estructuras básicas de regalías funcionan, pero no se aplican ¿Tiene problemas para dividir los pagos entre varios destinatarios ¿No estás seguro de cómo hacer un seguimiento de las ventas secundarias ####Preguntas clave 1.Eficiencia del gas: ¿cuál es la estructura de regalías óptima para minimizar los costos? 2.Cumplimiento: ¿Cómo garantizar que se respeten las regalías en todos los mercados? 3.Divisiones entre múltiples destinatarios: ¿la mejor manera de distribuir los pagos a varias partes? 4.Capacidad de actualización: ¿Cómo modificar las tasas de regalías sin problemas después de la acuñación?
- Sui
72Mejor Respuesta ¿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.
- Sui
- SDKs and Developer Tools
- Move
73Mejor Respuesta
