Tendencia
Descubre las publicaciones más populares.
Publicaciones
2069AMM 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
82Mejor Respuesta- Artículo0xduckmove618ParaSuiApr 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 ¿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
¿Cómo evita Sui los hackeos de contratos inteligentes?
El hackeo de contratos inteligentes ha afectado a la industria de la cadena de bloques, y solo en 2023 se perdieron más de 3 000 millones de dólares debido a vulnerabilidades en plataformas como Ethereum. La red Sui, diseñada con la seguridad como prioridad, presenta varias innovaciones clave para minimizar estos riesgos. Este artículo explora: 🔒 Las funciones de seguridad integradas de Sui 💡 Cómo el lenguaje Move evita las vulnerabilidades más comunes 🛡️ Comparación con las vulnerabilidades de Ethereum 🚀 Por qué Sui podría convertirse en la plataforma de contratos inteligentes más segura 1. El lenguaje de programación Move: un enfoque que prioriza la seguridad Sui usa Move, un lenguaje desarrollado originalmente para la cadena de bloques Diem de Facebook, diseñado específicamente para la gestión segura de activos. Principales beneficios de seguridad de Move: Evita las llamadas externas sin control: evita los ataques de reingreso (como el hackeo de 60 millones de dólares de la DAO a Ethereum). Normas estrictas de escritura y propiedad: eliminan la pérdida accidental de fondos debida a errores de codificación. Soporte de verificación formal: permite probar matemáticamente la exactitud del contrato. Ejemplo: en Ethereum, un simple error tipográfico puede consumir fondos. En Move, el compilador rechaza el código no seguro antes de la implementación. 2. Modelo centrado en objetos: aislamiento de vulnerabilidades A diferencia del modelo de estado compartido de Ethereum (en el que un error puede afectar a muchos contratos), el almacenamiento basado en objetos de Sui limita la propagación de los exploits: Cada activo (moneda, NFT, etc.) es un objeto distinto con reglas de propiedad estrictas. Los contratos no pueden modificar arbitrariamente datos no relacionados. Impacto: Incluso si un contrato se ve comprometido, los daños están contenidos, a diferencia de los riesgos de componibilidad de Ethereum (por ejemplo, el hackeo del puente Wormhole de 325 millones de dólares). 3. Sin ataques de «duelo por gas» En Ethereum, los atacantes pueden enviar contratos de spam con transacciones que consumen mucha gasolina para bloquear a los usuarios legítimos (por ejemplo, ataques de denegación de servicio). La solución de Sui: Transacciones fijas de bajo costo (sin subastas de gas). La ejecución en paralelo evita la congestión en toda la red. 4. Monitoreo de seguridad en cadena Los validadores de Sui supervisan activamente las actividades sospechosas: Verificaciones previas de las transacciones: rechace las solicitudes obviamente maliciosas. Análisis en tiempo real: marca el comportamiento anormal (por ejemplo, grandes retiradas repentinas). 5. Récord de seguridad en el mundo real (hasta ahora) Sui no ha sufrido ningún hackeo importante desde el lanzamiento de la red principal (2023). Ethereum tiene un promedio de 2 a 3 de las principales vulnerabilidades de DeFi al mes. Caso práctico: Un DEX con sede en Sui (Cetus) ha procesado operaciones de más de mil millones de dólares sin incidentes de seguridad, a diferencia de los DEX de Ethereum, que suelen ser víctimas de ataques. 6. Preparada para el futuro: verificación formal y auditorías Sui alienta a: Verificación formal: demostrar matemáticamente que los contratos están libres de errores. Requisitos de auditoría múltiple: los proyectos principales deben superar más de 3 auditorías. Conclusión: ¿Es Sui la plataforma de contratos inteligentes más segura? Si bien ningún sistema es 100% resistente a los ataques informáticos, el lenguaje Move de Sui, el modelo de objetos y la ejecución en paralelo hacen que sea mucho menos vulnerable que Ethereum en la actualidad. El resultado final: Para desarrolladores: Move reduce el riesgo de errores humanos. Para los usuarios: hay menos probabilidades de perder fondos a causa de exploits. Para las instituciones: la seguridad de nivel empresarial genera confianza. **¿Qué sigue? ¿Adoptará Ethereum funciones similares a las de Move? ¿Puede Sui mantener su historial de seguridad limpio a medida que aumenta la adopción?** Comparte tus opiniones a continuación
- Sui
6- Artículoharry phan595ParaSuiApr 24, 2025
Administración de niños entre módulos con public_receive
Esta es la tercera parte de la serie «Objetos entre padres e hijos en movimiento». A veces, los tipos de padre e hijo se definen en diferentes módulos o incluso en paquetes diferentes. Por ejemplo, es posible que tengas un objeto Warehouse genérico que pueda almacenar cualquier tipo de objeto Parcel. El módulo Warehouse quiere extraer un paquete secundario, pero el tipo de paquete se define en otro lugar. En estos casos, utilizamos transfer: :public_receive, que es el primo de receive entre módulos. ###receive vs public_receive Como hemos visto, transfer: :receive solo se puede invocar en el módulo que define T (o a un amigo) porque no requiere T: store. De hecho, el verificador de códigos de bytes Move garantiza que, en cualquier llamada que se reciba, el tipo T provenga del módulo actual. Se trata de una restricción de seguridad para objetos que solo pueden utilizarse con una llave. transfer: :public_receive es una variante que requiere T: key + store, pero permite recibir datos fuera del módulo T. En otras palabras, si el tipo de objeto tiene la capacidad de almacenamiento (lo que significa que puede existir libremente en el almacenamiento global), cualquier módulo (con el UID &mut del elemento principal) puede recibirlo mediante public_receive. Esto es perfecto para los casos en los que el módulo principal es diferente del módulo secundario. ¿Por qué requerir una tienda? Porque almacenar marcas de que el objeto puede conservarse y distribuirse de forma segura fuera de su módulo de definición. Los objetos de solo clave pueden tener invariantes personalizados que el módulo original quiera aplicar al transferirlos o recibirlos; al excluir los de public_receive, Sui obliga a los desarrolladores a gestionarlos dentro del módulo (como veremos con los objetos enlazados al alma). Si un objeto tiene almacenamiento, es más permisivo, y Sui permite una lógica genérica de transferencia/recepción para gestionarlo externamente. ###Ejemplo: módulos separados para padres e hijo Vamos a ilustrarlo con un escenario sencillo: un almacén que almacena objetos de paquetería. El tipo de paquete se define en su propio módulo y el almacén en otro. Mostraremos cómo Warehouse puede recibir un paquete secundario mediante public_receive. module demo::parcel { // Child module use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; /// A parcel object that can be stored in a Warehouse. /// It has both key and store, so it can be transferred across modules. struct Parcel has key, store { id: UID, contents: vector } public entry fun create_parcel(contents: vector, ctx: &mut TxContext): Parcel { Parcel { id: object::new(ctx), contents } } } module demo::warehouse { // Parent module use sui::transfer::{Self, Receiving, public_receive}; use demo::parcel::{Self, Parcel}; use sui::object::{UID}; use sui::tx_context::{Self, TxContext}; struct Warehouse has key { id: UID, location: address } public entry fun create_warehouse(location: address, ctx: &mut TxContext): Warehouse { Warehouse { id: object::new(ctx), location } } /// Receive a Parcel that was sent to this Warehouse. /// Returns the Parcel to the caller (transferred to caller's address). public entry fun withdraw_parcel( warehouse: &mut Warehouse, parcel_ticket: Receiving, ctx: &mut TxContext ): Parcel { // Using public_receive because Parcel is defined in another module and has store let parcel = public_receive(&mut warehouse.id, parcel_ticket) oai_citation_attribution:27‡docs.sui.io oai_citation_attribution:28‡github.com; // Transfer the parcel to the transaction sender (so the caller gets ownership) transfer::transfer(parcel, tx_context::sender(ctx)); // We return nothing because we've transferred the Parcel out to the caller. } } Analicemos lo que está sucediendo en draw_parcel: Llamamos a public_receive (&mut warehouse.id, parcel_ticket). Como Parcel tiene la capacidad de almacenar, esta llamada está permitida aunque no estemos en el módulo de paquetería. En principio, realiza las mismas comprobaciones y extracciones que las de recepción, pero se permite usar varios módulos, ya que la tienda indica que es seguro hacerlo. https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T A continuación, transferimos inmediatamente el paquete recibido a la dirección de la persona que llama (tx_context: :sender (ctx)). Este paso garantiza que el paquete salga del almacén y llegue al usuario que inició la retirada. También podríamos haber devuelto Parcel desde la función y Sui lo trataría como una salida que pertenecería a la dirección de la persona que llama (ya que es una salida de una función de entrada). Hacer una transferencia explícita es más detallado, pero deja claro lo que está sucediendo (y nos permite hacer cualquier comprobación antes de liberar el objeto). ¿Por qué incluir la tienda en Parcel? Si Parcel carecía de la capacidad de almacenar (es decir, solo tenía una clave), la llamada public_receive de demo: :warehouse no se compilaba; Sui exige que T tenga store para public_receive. En ese caso, nos veríamos obligados a recuperar el paquete utilizando la función de recepción dentro del propio módulo de paquetería (o utilizar alguna relación de amistad), lo que complica el diseño de varios módulos. Al añadir store a Parcel, decimos que «este objeto se puede mover y recibir libremente en módulos externos», que es lo que queremos para un patrón de contenedor genérico. Patrón de llamada a una función: Para usarlos en una transacción, el flujo sería: 1.Depósito (transferencia al objeto) :Llama a transfer: :public_transfer (parcel_obj, @warehouse_id) para enviar un paquete a un almacén. Esto marca al propietario del paquete como el almacén. (Aquí utilizamos public_transfer porque está fuera del módulo Parcel y Parcel tiene un almacén. Dentro del módulo del paquete, una simple transferencia también funcionaría). Retirar (recibir de nuevo) :Más tarde, llama a draw_parcel (warehouse_obj, Receiving (parcel_id,...)). El SDK puede obtener la recepción haciendo referencia al identificador del paquete y a la última versión. La función llamará a public_receive y, a continuación, te transferirá el paquete. Tras la llamada a withdrawal _parcel, el propietario del paquete vuelve a su dirección (la suya), por lo que vuelve a ser un objeto propiedad de una dirección normal. El almacén ya no es su propietario. Consideraciones relacionadas con varios módulos: Tenga en cuenta que el módulo de almacén necesitaba conocer el tipo de paquete (utilizamos demo: :parcel: :Parcel). Esto se debe a que escribimos explícitamente la recepción como recepción. Si querías un contenedor verdaderamente genérico que pudiera recibir cualquier tipo de objeto, tendrías que usar genéricos o un enfoque diferente (posiblemente campos dinámicos con borrado de tipos). Sin embargo, en la mayoría de los casos de uso, sabrás qué tipo de niños esperas tener. ¿Por qué public_receive en lugar de simplemente llamar a receive? Si probáramos con transfer: :receive (&mut warehouse.id, parcel_ticket) en el módulo de almacén, el verificador de Move lo rechazaría porque Parcel no está definido en demo: :warehouse. Sui ofrece la opción public_receive como la mejor forma de hacerlo, con una comprobación de habilidad adicional (se requiere almacenar). Del mismo modo, Sui utiliza transfer vs public_transfer, freeze_object vs public_freeze_object, etc., siguiendo el mismo patrón: las versiones public_ son para usarse fuera del módulo de definición y requieren almacenamiento. No olvides el permiso de los padres: Incluso con public_receive, necesitarás ese &mut warehouse.id. Lo tenemos porque draw_parcel está en el módulo de Warehouse y acepta &mut Warehouse. Por lo tanto, solo alguien que pueda llamar a esa persona (el propietario del almacén) puede retirar el paquete. Si el módulo de almacén no proporcionara esta función de forma pública, tampoco se podría invocar externamente a public_receive en sus módulos secundarios. Por lo tanto, los módulos cruzados no eluden el control del padre; solo permiten que el código del padre funcione con elementos secundarios de tipos que no ha definido. Nota sobre la posibilidad de almacenar objetos: Ofrecer un almacén de objetos hace que sea más flexible, pero un poco menos restringido: cualquier módulo que tenga la referencia principal puede extraerla usando public_receive. Si quieresrestringirla forma en que se recupera un objeto (por ejemplo, aplicar una lógica personalizada o impedir que se extraiga fácilmente), puedes hacer que sea solo con clave de forma deliberada. Veremos un ejemplo de ello con objetos ligados al alma. En esos casos, puedes implementar una función de recepción personalizada en lugar de confiar en public_receive. Para resumir esta parte: public_receive es tu mejor opción para administrar objetos secundarios definidos en otros módulos, siempre que esos objetos tengan la capacidad de almacenamiento. Te permite crear sistemas multimodulares (como nuestro almacén/paquetería) sin dejar de respetar la propiedad y el control de acceso. Solo recuerda incluir los tipos secundarios de almacenamiento y usar public_transfer cuando los envíes a un padre desde fuera de su módulo.
- Sui
- Architecture
6 - 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
61Mejor Respuesta 
¿Cómo crear una dApp compleja en Sui Move?
Curso #2: Sumérjase en la programación en movimiento: creación de dApps complejas en Sui Ahora que ha comprendido los conceptos básicos de la programación de Move y ha implementado su primer contrato inteligente, es hora de llevar sus habilidades al siguiente nivel. En este artículo, exploraremos cómo crear aplicaciones descentralizadas (dApps) más complejas utilizando Move on the Sui blockchain. Paso 1: Dominar los conceptos avanzados de movimiento Sui Antes de sumergirnos en la codificación, repasemos algunas funciones avanzadas de Move que lo hacen especialmente adecuado para crear dApps seguras y escalables: ####1. Programación orientada a los recursos Move trata los activos digitales comorecursos, asegurándose de que no puedan duplicarse, eliminarse involuntariamente o utilizarse indebidamente (https://docs.sui.io/learn/resource-oriented-programming). Esto se logra mediante estrictas normas de propiedad y seguridad tipográfica. Por ejemplo: module examples::token { use sui::object::{Self, UID}; use sui::transfer; struct Token has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext, value: u64): Token { Token { id: object::new(ctx), value, } } public fun transfer_token(token: Token, recipient: address) { transfer::public_transfer(token, recipient); } } En este ejemplo, el Tokenrecurso se crea y se transfiere de forma segura. Los recursos de Move son inmutables de forma predeterminada, a menos que se marquen explícitamente como mutables, lo que añade una capa adicional de seguridad. ####2. Módulos y encapsulación Los módulos de Move actúan como unidades de funcionalidad independientes, lo que permite una mejor organización y reutilización. Por ejemplo, puedes separar la lógica de creación de tokens de la lógica de transferencia en distintos módulos (https://examples.sui.io/modules). Esta modularidad garantiza un código más limpio y un mantenimiento más sencillo. ####3. Diseño centrado en objetos UIDSui Move presenta unmodelo centrado en objetos, en el que cada recurso tiene un identificador único a nivel mundial (). Esto permite la referencia directa y la interacción con los objetos, lo que facilita la gestión de transiciones de estado complejas (https://docs.sui.io/objects). Paso 2: Redacción de un contrato inteligente modular Vamos a crear un contrato inteligente más avanzado que demuestre estos conceptos. Crearemos un mercado de NFT sencillo en el que los usuarios puedan acuñar e intercambiar NFT. ####Defina el recurso de NFT Empieza por definir un recurso NFT dentro de un módulo Move: module examples::nft_marketplace { use sui::object::{Self, UID}; use sui::transfer; struct NFT has key, store { id: UID, name: String, price: u64, } public fun mint_nft(ctx: &mut TxContext, name: String, price: u64): NFT { NFT { id: object::new(ctx), name, price, } } public fun list_for_sale(nft: NFT, price: u64, ctx: &mut TxContext) { nft.price = price; transfer::public_transfer(nft, tx_context::sender(ctx)); } } En este caso, el NFTrecurso incluye propiedades como nameyprice. La mint_nftfunción crea un nuevo NFT y list_for_salepermite a los usuarios poner sus NFT a la venta. ####Compilar e implementar Utilice la CLI de Sui para compilar e implementar su contrato. Escriba un script de implementación para automatizar este proceso: sui move build sui client publish --gas-budget 10000 Esto empaquetará e implementará su módulo en Sui Devnet (https://docs.sui.io/cli). Paso 3: Creación de una interfaz de React para su mercado Con tu contrato inteligente implementado, conectémoslo a una interfaz de React. ####Configura el proyecto Inicializa un proyecto de React si aún no lo has hecho: npx create-react-app nft-marketplace cd nft-marketplace npm install @mysten/sui.js ####Intégrese con Sui Wallet Usa la @mysten/sui.jsbiblioteca para interactuar con la cadena de bloques de Sui: import { JsonRpcProvider, SuiClient } from '@mysten/sui.js'; const provider = new SuiClient({ url: 'https://fullnode.devnet.sui.io' }); async function fetchNFTs(ownerAddress) { const objects = await provider.getObjectsOwnedByAddress(ownerAddress); console.log('User NFTs:', objects); } ####Mostrar datos NFT Obtén y muestra datos de NFT en tu aplicación React: function NFTList({ ownerAddress }) { const [nfts, setNFTs] = useState([]); useEffect(() => { async function loadNFTs() { const response = await provider.getObjectsOwnedByAddress(ownerAddress); setNFTs(response.data); } loadNFTs(); }, [ownerAddress]); return ( {nfts.map((nft) => ( {nft.name} Price: {nft.price} SUI ))} ); } Paso 4: Mejorar la seguridad y el rendimiento ####1. Transacciones seguras Asegúrese de que todas las transacciones estén validadas tanto dentro como fuera de la cadena. Utilice bibliotecas como @mysten/sui.jspara verificar los recibos de las transacciones: async function verifyTransaction(txDigest) { const result = await provider.getTransaction({ digest: txDigest }); console.log('Transaction Verified:', result); } 2. Optimice las tarifas de gas* Asóciese con servicios como* Gasolinera Shami* para ofrecer transacciones sin gas y mejorar la experiencia del usuario. También puede agrupar las transacciones para reducir los costos (https://docs.sui.io/gas-optimization). ####3. Aproveche la escalabilidad de Sui La arquitectura de Sui admite un alto rendimiento y una baja latencia, lo que la hace ideal para las dApps con un uso intensivo. Pruebe su aplicación en condiciones de carga simuladas para garantizar que el rendimiento se mantenga constante (https://performance.sui.io). Paso 5: Pruebas y depuración Las pruebas son fundamentales para evitar vulnerabilidades. Usa herramientas como* Sui Explorer* para supervisar las transacciones y solucionar los problemas. Además, escribe pruebas unitarias para tus módulos Move: #[test] fun test_mint_nft() { use sui::test_scenario; let ctx = &mut test_scenario::ctx(); let nft = examples::nft_marketplace::mint_nft(ctx, "Test NFT", 100); assert!(nft.price == 100, 0); } Ejecute sus pruebas con la CLI de Sui: sui move test Paso 6: Interactuar con la comunidad La creación de dApps no se basa solo en la codificación, sino también en la colaboración. Comparte tu progreso en plataformas como* GitHub,* Discord* o* Twitter**. Participa en hackatones y desafíos para desarrolladores organizados por la Fundación Sui para perfeccionar tus habilidades y ganar visibilidad. Conclusión Si dominas los conceptos avanzados de Move, escribes contratos inteligentes modulares y creas interfaces intuitivas, estás en camino de convertirte en un desarrollador de dApps competente en la cadena de bloques Sui. Recuerda priorizar la seguridad, optimizar el rendimiento e interactuar con la comunidad para maximizar tu impacto. ¡Estén atentos al* Curso #3*, donde exploraremos casos de uso reales y técnicas avanzadas para escalar sus DApps en Sui! Si desea más aclaraciones o recursos adicionales, ¡no dude en preguntar!
- Sui
- Architecture
- Move
6
Primeros pasos con Move Learning - Curso #1
Tanto si eres un desarrollador principiante como si tienes experiencia, esta guía paso a paso te ayudará a entender cómo se puede utilizar Move, un lenguaje de programación orientado a los recursos, para crear dApps en la cadena de bloques Sui. ###Paso 1: Entender Move y sus características clave Antes de sumergirnos en la codificación, analicemos brevemente qué esMovey por qué es único. Movees un lenguaje de programación diseñado para escribir contratos inteligentes seguros y eficientes. Introduce laprogramación orientada a los recursos**, en la que los activos digitales se tratan como recursos de primera clase, garantizando que no puedan duplicarse o eliminarse involuntariamente. A diferencia de otros lenguajes,Moveminimiza las vulnerabilidades mediante funciones como laescritura estáticay la sólidagestión de recursos. Si es la primera vez que usasMove, te recomendamos que veas el [vídeo]Introducción a Sui Move(https://www.youtube.com/watch?v=cJwN3IhpLnQ)by) Shayan de la Fundación Sui. Esto proporcionará conocimientos fundamentales sobre la red Sui y el papel de Move dentro de ella. ###Paso 2: configurar su entorno de desarrollo Para empezar, tendrás que instalar las herramientas y los archivos binarios necesarios. Sigue estos pasos: 1.Instalar binarios Sui Comience por instalar losbinarios Suipara asegurarse de que su entorno de desarrollo esté listo. La CLI (interfaz de línea de comandos) de Sui le permitirá interactuar con la cadena de bloques de Sui. Puedes encontrar instrucciones detalladas en los Documentos de Sui. 2.Elige tu platforma Dependiendo de si utilizas Windows, macOS o Linux, sigue las instrucciones de configuración correspondientes que aparecen en la serie de vídeos o en la documentación oficial de Sui. 3.Configurar un VPS (opcional) Si su portátil no es lo suficientemente potente, considere la posibilidad de configurar un servidor privado virtual (VPS) para gestionar la carga computacional. ###Paso 3: Redacta tu primer contrato inteligente Ahora que su entorno está listo, escribamos un simple contrato inteligenteMove. Para este tutorial, puedo recomendar el uso del ejemploSweet Place, que está inspirado enFlash Place. 1.Definir recursos Empieza por definir un recurso en tu módulo Move. Por ejemplo: module examples::sweet_place { use sui::object::{Self, UID}; use sui::transfer; struct SweetPlace has key { id: UID, name: String, } public fun create_sweet_place(ctx: &mut TxContext, name: String) { let sweet_place = SweetPlace { id: object::new(ctx), name, }; transfer::public_transfer(sweet_place, tx_context::sender(ctx)); } } 2.Compilar e implementar Utilice la CLI de Sui para compilar e implementar su contrato. Escriba unscript de implementaciónpara automatizar este proceso y garantizar una integración fluida con su interfaz más adelante. ###Paso 4: Construir la interfaz de React Con tu contrato inteligente implementado, es hora de conectarlo a unainterfaz de React. Este paso supone que tienes alguna experiencia previa con React. Si no es así, consulta elCurso de React para principiantesde FreecodeCamp.org. 1.Configura el proyecto Inicialice un proyecto de React utilizando create-react-appo cualquier marco de su elección. 2.Intégralo con Sui Wallet Usa bibliotecas como @mysten/sui.jspara interactuar con la cadena de bloques Sui. Por ejemplo: import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); 3.Obtenga datos de su contrato Consulta los datos de tu contrato de Move implementado y muéstralos en tu aplicación React. Usa unindexadorpara rastrear las transacciones y los cambios de estado de manera eficiente. ###Paso 5: Mejorar la experiencia del usuario (UX) Una de las características más destacadas de este tutorial es su enfoque en crear una experiencia de usuario perfecta. Así es como puedes mejorar la experiencia de usuario: 1.Integre transacciones sin gas Asóciese con servicios como laGasolinera Shamipara que sus usuarios puedan realizar transacciones sin gas. Esto elimina las barreras para los recién llegados que no están familiarizados con las tarifas de las criptomonedas. 2.Optimice el rendimiento Aproveche el alto rendimiento y la baja latencia de Sui para garantizar que su dApp funcione sin problemas incluso con una carga pesada. ###Paso 6: Probar y depurar Las pruebas son cruciales para garantizar que la aplicación funcione según lo esperado. Usa herramientas como elSui Explorerpara verificar las transacciones y solucionar problemas [[Web Search]]. Además, vuelve a visitar la plataforma**MOVE eLearning para obtener información sobre las mejores prácticas de prueba y medición. ###Paso 7: Interactuar con la comunidad Por último, ¡no olvides interactuar con lacomunidad Sui! Comparta su progreso, haga preguntas y colabore con otros. Como se destaca en la transcripción del vídeo, la creación de redes con otros desarrolladores puede generar oportunidades interesantes.
- Sui
- Architecture
- SDKs and Developer Tools
- Move
6- P&R expertosParaSuiJun 26, 2025
How to Properly Use the Sui SDK for Frontend Integration?
I'm building a frontend (React/Next.js) for a Sui dApp and need to interact with the blockchain—fetching objects, sending transactions, and listening to events. I’ve tried using the @mysten/sui.js SDK, but I’m running into issues: Wallet Connection: Sometimes, the wallet doesn’t return the user’s address after connecting. Transaction Handling: Transactions fail silently or return vague errors. RPC Limits: I get rate-limited or timeouts when fetching large datasets. Real-Time Updates: How can I listen for on-chain events (e.g., NFT mints, balance changes)? What I’ve tried: ✔ Basic SuiClient setup with mainnet and testnet RPCs. ✔ Using useWallet() from @mysten/dapp-kit for wallet integration. ✔ Manual transaction signing with signAndExecuteTransactionBlock. Questions: What’s the recommended way to initialize the Sui SDK in a frontend app? How do I handle errors gracefully (e.g., RPC failures, wallet rejections)? Are there best practices for optimizing queries (batching, caching, etc.)? How can I subscribe to real-time updates (e.g., new transactions, object changes)?
- Sui
- SDKs and Developer Tools
62Mejor Respuesta ¿Cómo mejoran los módulos Sui Move la seguridad de los contratos inteligentes?
¿Cómo permite el sistema de módulos de Sui Move a los desarrolladores definir, organizar e interactuar de forma segura con objetos personalizados en cadena? ¿Cuáles son las características únicas de la identificación de módulos y el almacenamiento de objetos en el ecosistema de Sui en comparación con los lenguajes de contratos inteligentes tradicionales?
- Sui
- Architecture
- Security Protocols
- Move
61Mejor Respuesta
