Tendencia
Descubre las publicaciones más populares.
Publicaciones
656- Artículo0xduckmove409ParaSuiApr 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 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
- Sui
62Mejor Respuesta- Artículoharry phan458ParaSuiApr 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
5 - Artículo0xduckmove409ParaSuiApr 25, 2025
En resumen, el vídeo puede potenciar tu viaje como desarrollador de Sui
Seamos realistas, si alguna vez has construido sobreSui, es probable que te hayas topado con algunas paredes. Desde identificadores de objetos crípticos hasta hacer malabares con las CLI y poner en marcha redes locales, es como prepararse para una pelea contra un jefe incluso antes de escribir la primera línea de lógica empresarial. Durante un taller reciente como parte de la serie Road to Overflow, Moven, de la Fundación Dubhe, explicó cómo funciona Dubhe Engine, qué problemas resuelve y cómo es más que una simple herramienta: es un movimiento en crecimiento. Enlace de vídeo: https://www.youtube.com/watch?v=CHkOS-TYehM El problema: herramientas fragmentadas, configuración pesada Moven comenzó con una charla sincera sobre el panorama actual de los desarrolladores de Sui: Los recién llegados se enfrentan a una dura curva de aprendizaje: configurar carteras, solicitar fichas de prueba, crear paquetes de andamios, aprender la sintaxis de Move, poner en marcha redes de prueba locales, configurar los SDK y mucho más. Incluso los desarrolladores experimentados pierden tiempo en tareas de configuración repetitivas en lugar de centrarse en la lógica real de las DApps. Las bases de código se vuelven monolíticas rápidamente: archivos.move grandes y desordenados con estructuras de datos, constructores, ayudantes y funciones de entrada agrupados. En resumen: el ecosistema está creciendo rápidamente, pero las herramientas no han estado a la altura hasta ahora. ##La solución: generación de código basada en esquemas En el corazón deDubhe Enginehay una idea clave:el desarrollo centrado en los esquemas. Con un solo archivo de configuración (d.config.ts), los desarrolladores pueden definir: Sus estructuras de datos en cadena Eventos Errores Tipos personalizados (¡incluso vectores 2D de estructuras autodefinidas!) A partir de ahí, un comando (pnpm dub schema:gen) genera automáticamente un paquete Move completamente estructurado y una integración de frontend, que incluye: Estructura de archivos modularizada Composabilidad en cadena (mediante importaciones desde los paquetes publicados por Sui) Soporte de configuración, construcción, implementación y interfaz de usuario de Localnet (compatible con Next.js) Tú escribes la lógica.Dubhese encarga de lo repetitivo. ##* ⏱️ Impacto real: 80% menos de código repetitivo* En experimentos internos, los proyectos generados por Dubb mostraron que solo el* 20% del código*tenía que escribirse manualmente; el resto era un andamiaje generado automáticamente mediante esquemas. Esto se traduce en una creación de prototipos más rápida, menos errores y más tiempo para centrarse en lo que realmente importa: ¡el valor fundamental de tu app ##Un motor de ecosistema de desarrollo Dubb no se detiene en los andamios. Movin lo dejó claro: se trata deinfraestructura para una nueva economía de desarrolladores. Así es como está evolucionando la comunidad de Dubb Engine: Subsidios a la gasolina:** Para los nuevos constructores que estén experimentando con Dubb Task Bounties:** Como los «buenos primeros números» de GitHub, pero con recompensas Nivel de gobierno (D-OS) :**Votación en cadena para priorizar los proyectos Soporte para Launchpad:** Ayudamos a los proyectos maduros a conseguir financiación DApp Staking:** Los usuarios pueden apostar fichas D para apoyar sus dApps favoritas y votar sobre las decisiones de la hoja de ruta Este ciclo de retroalimentación alimenta todo el ecosistema de Sui: más desarrolladores → más aplicaciones → más usuarios → más desarrolladores.
- Architecture
- SDKs and Developer Tools
5 How to access and manage nested structs and dynamic fields in Move?
How to access and manage nested structs and dynamic fields in Move?
- Sui
- Move
56Mejor 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
53Mejor Respuesta+10
P&R expertosParaSuiMay 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?
- Sui
- Move
53Mejor Respuesta
Lenguaje de programación Move: la historia detrás
En el panorama en constante evolución de la tecnología blockchain, los lenguajes de programación de contratos inteligentes se han convertido en la columna vertebral de las aplicaciones descentralizadas (dApps). Entre ellos, Move se ha convertido en una innovación revolucionaria, que ofrece características únicas que lo diferencian de los lenguajes tradicionales como Solidity o Vyper. Diseñado teniendo en cuenta la seguridad y la escalabilidad, Move se creó para abordar muchas de las vulnerabilidades e ineficiencias inherentes a los ecosistemas de cadenas de bloques anteriores. Este artículo profundiza en los orígenes, las características y el impacto del lenguaje de programación Move, y explora su recorrido desde su creación hasta convertirse en una de las herramientas más prometedoras para construir sistemas descentralizados sólidos. Los orígenes de Move: una solución a los desafíos de la cadena de bloques El lenguaje de programación Move fue introducido por primera vez por Meta (anteriormente Facebook) como parte de su ambicioso proyecto Diem (inicialmente llamado Libra). Diem tenía como objetivo crear una moneda digital global y una infraestructura financiera impulsada por la tecnología blockchain. Sin embargo, el equipo se dio cuenta rápidamente de que los lenguajes de contratos inteligentes existentes eran insuficientes para su visión. Los lenguajes tradicionales a menudo carecían de mecanismos para prevenir las vulnerabilidades más comunes, como los ataques de reingreso, los desbordamientos de números enteros y la duplicación no autorizada de activos. Estos problemas ya habían causado daños importantes en otros ecosistemas, sobre todo el infame hackeo de la DAO a Ethereum. Para superar estos desafíos, el equipo de ingeniería de Meta desarrolló Move, un nuevo lenguaje diseñado específicamente para la programación orientada a los recursos. A diferencia de los lenguajes de programación convencionales, Move trata los activos digitales como recursos de primera clase, lo que garantiza que no puedan duplicarse, eliminarse involuntariamente o utilizarse indebidamente. Este enfoque se inspiró en la lógica lineal, un marco matemático que impone reglas estrictas de propiedad de los recursos. Al integrar estos principios en el núcleo del lenguaje, Move introdujo un cambio de paradigma en la forma en que los desarrolladores interactúan con los activos digitales en la cadena de bloques. Aunque el proyecto Diem finalmente se archivó debido al escrutinio regulatorio, Move encontró una nueva vida en proyectos independientes de cadenas de bloques como Aptos y Sui. Estas plataformas adoptaron Move como su principal lenguaje de contratos inteligentes, reconociendo su potencial para revolucionar la forma en que se crean y protegen las aplicaciones descentralizadas. Características clave de Move: por qué se destaca 1. Programación orientada a los recursos Una de las características que definen a Move es su enfoque en la programación orientada a los recursos. En Move, los activos digitales, como los tokens, los NFT o incluso los objetos personalizados, se tratan como recursos que siguen estrictas normas de propiedad. Una vez creado, un recurso no se puede copiar ni destruir a menos que su módulo lo permita explícitamente. Esto garantiza que las operaciones críticas relacionadas con los activos, como las transferencias o las actualizaciones de estado, se realicen de forma segura. Por ejemplo, consideremos una función simple de transferencia de fichas escrita en Move: ejemplos de módulos: :token { usa sui: :object:: {Self, UID}; usa sui: :transfer; struct Token tiene una clave, store { id: UID, valor: u64, } public fun mint (ctx: &mut txContext, valor: u64): Token { Símbolo { id: object: :new (ctx), valor, } } public fun transfer_token (token: token, destinatario: dirección) { transfer: :public_transfer (token, destinatario); } } Aquí, la Token estructura representa un recurso que solo se puede transferir mediante la función public_transfer. Cualquier intento de duplicar o manipular el token fuera de esta función provocaría un error de compilación. Este diseño elimina clases enteras de errores y vulnerabilidades que suelen aparecer en otros lenguajes. 2. Modularidad y encapsulación Move promueve el diseño modular, lo que permite a los desarrolladores encapsular la funcionalidad en módulos independientes. Cada módulo define sus propios tipos, funciones y controles de acceso, lo que garantiza una separación clara entre los diferentes componentes de un contrato inteligente. Por ejemplo, un desarrollador puede crear módulos separados para la creación de tokens, los pares de negociación y la lógica de gobernanza. Esta modularidad mejora la legibilidad, el mantenimiento y la reutilización del código. 3. Soporte de verificación formal Otra característica destacada de Move es su compatibilidad con la verificación formal, un proceso que se utiliza para demostrar matemáticamente la exactitud de un programa. La verificación formal ayuda a identificar errores sutiles y casos extremos que pueden no detectarse con los métodos de prueba tradicionales. Si bien no todos los proyectos basados en Move requieren una verificación formal, la estructura del lenguaje facilita la aplicación de esta técnica cuando es necesaria. 4. Diseño centrado en objetos (mejoras específicas para Sui) En la cadena de bloques Sui, Move se ha mejorado aún más con un modelo centrado en objetos. Cada recurso de Sui Move tiene un identificador único a nivel mundial (UID), que permite la referencia directa y la interacción con los objetos. Este diseño simplifica los flujos de trabajo complejos, como la administración de las NFT o el seguimiento de los datos específicos de los usuarios, a la vez que mantiene un alto rendimiento y escalabilidad. Aplicaciones de Move en el mundo real Desde su adopción por Aptos y Sui, Move se ha utilizado para crear una amplia gama de aplicaciones descentralizadas. Algunos ejemplos notables incluyen: 1. Protocolos de financiación descentralizada (DeFi) El fuerte énfasis de Move en la seguridad lo hace ideal para las aplicaciones de DeFi, donde están en juego activos por valor de miles de millones de dólares. Proyectos como Cetus, una bolsa descentralizada (DEX) basada en SUI, aprovechan la programación orientada a los recursos de Move para implementar funciones de negociación avanzadas y, al mismo tiempo, minimizar los riesgos asociados con la manipulación de activos. 2. Tokens no fungibles (NFT) Los mercados de NFT se benefician enormemente de la capacidad de Move para definir y gestionar activos digitales únicos. Los desarrolladores pueden crear estándares de NFT sofisticados con un control granular sobre la propiedad, las regalías y los metadatos. Además, las mejoras centradas en los objetos de Sui permiten una integración perfecta de las NFT dinámicas, que pueden evolucionar en función de condiciones predefinidas. 3. Plataformas de juegos y metaverso Los juegos basados en la cadena de bloques requieren un manejo eficiente de los activos del juego, las interacciones de los jugadores y las actualizaciones en tiempo real. La arquitectura modular y la ejecución de baja latencia de Move lo hacen ideal para crear experiencias de juego envolventes. Plataformas como Blockus, un ecosistema de juegos de Web3, utilizan Move para impulsar sus economías y juegos descentralizados. Comparando Move con otros lenguajes de contratos inteligentes Si bien Move comparte algunas similitudes con otros lenguajes de contratos inteligentes, sus características únicas le dan una ventaja competitiva: Solidity: Como idioma principal de Ethereum, Solidity es ampliamente adoptado, pero adolece de problemas heredados, como la vulnerabilidad a los ataques de reentrada. Move aborda estas debilidades mediante su modelo orientado a los recursos y una seguridad tipográfica más estricta. Rust (usado en Solana): Rust ofrece un rendimiento y una seguridad de memoria excelentes, pero carece del soporte nativo de Move para la administración de recursos y la verificación formal. Además, la pronunciada curva de aprendizaje de Rust puede disuadir a los recién llegados en comparación con la sintaxis más intuitiva de Move. Clarity (utilizada en Stacks): Clarity hace hincapié en la transparencia y la previsibilidad, pero opera dentro de un ámbito limitado vinculado al ecosistema de Bitcoin. Move, por otro lado, admite casos de uso más amplios en múltiples cadenas de bloques. El futuro de Move: adopción y evolución A medida que la tecnología blockchain siga madurando, la demanda de lenguajes de contratos inteligentes seguros y escalables no hará más que crecer. Move está a punto de desempeñar un papel fundamental en la configuración de la próxima generación de aplicaciones descentralizadas, gracias a su diseño innovador y al creciente apoyo de la comunidad. Proyectos como Aptos y Sui están invirtiendo activamente en educación, herramientas e infraestructura para desarrolladores para acelerar la adopción de Move. Iniciativas como la plataforma Move eLearning ofrecen tutoriales y recursos completos para los aspirantes a desarrolladores, lo que reduce las barreras de acceso. Además, las colaboraciones con instituciones académicas y líderes del sector están impulsando la investigación sobre temas avanzados como la verificación formal y la interoperabilidad entre cadenas. De cara al futuro, cabe esperar que Move vaya más allá de sus casos de uso actuales e impulse todo tipo de aplicaciones, desde soluciones de cadena de suministro de nivel empresarial hasta redes sociales descentralizadas. Su adaptabilidad y solidez garantizan que siga siendo relevante en un ecosistema de cadenas de bloques cada vez más diverso e interconectado.
- Move
4Cómo convertir la clave privada a un nuevo formato a través de CLI
¿Cómo puedo convertir mi antigua clave privada a un nuevo formato y cambiarla de Hex a Bech32 usando la CLI de Sui?
- Sui
- Move
44Mejor RespuestaHow to bypass rate limit on local full node setup?
I've set up a full node locally and I'm sending requests to it, but I run into a 429 rate limit error. I'm trying to fetch object information using the sui_multiGetObjects method, but the server returns an error when I exceed 50 objects. This happens even when running requests on the same machine. Is there a way to get rid of this rate limit, or is it hardcoded in the node setup? Are nodes from the official config supposed to have no rate limits?
- Move CLI
- Move
43Mejor Respuesta
Gana tu parte de 1000 Sui
Gana puntos de reputación y obtén recompensas por ayudar a crecer a la comunidad de Sui.
- 458
- 426
- 409
- 360
- 304
- 301
- 295
- 291
- 271
- 259
- ¿Cómo actualizar la clave de un comerciante en ObjectTable cuando cambia en la estructura?20
- ¿Cuál es la interfaz más fácil para subir manchas de morsa?10
- ¿Qué pasa si no solicito ETH a través del puente Sui?00
- ¿Es fácil aprender Move after solidity?00
- ¿Es rentable crear servicios de dapps (como juegos) en sui?00