Artículos
Materiales educativos y tutoriales sobre Sui
Publicaciones
14- ArtículoApr 13, 2025
Mecánica de recepción y control de acceso a objetos
Esta es la segunda parte de la serie «Objetos entre padres e hijos en movimiento». Puedes leer la primera parte aquí Mecánica de transferencia de control de acceso a objetos: :receive Si has colocado un objetoXdentro de unPprincipal (transfiriendo X al identificador de P), ¿cómo puedes recuperarlo o usarlo? 🤔 Ahí es donde entra en juego el mecanismo de recepción especial de Sui. Cuando un objeto se transfiere a un objeto principal, no aparece automáticamente. Está ahí, propiedad deP. Para usar o eliminar ese objeto secundario en una transacción, debesrecibirlo. Sui proporciona una forma estructurada de hacerlo mediante unticket de recepcióny la función transfer: :receive. ##El billete de recepción Piense en Recibir como un ticket de reclamación para un objeto secundario del tipo T. En una transacción, en lugar de transferir directamente el objeto secundario (que aún no es de su propiedad) a una función, se pasa un Receiving, básicamente una referencia al «objeto con el identificador Y que pertenece al padre X». Esta recepción es una estructura de movimiento especial que contiene el identificador, la versión y el resumen del objeto que se va a recibir. Solo tiene la habilidad de soltar, lo que significa que puede existir de forma efímera pero no se puede almacenar de forma persistente. En otras palabras, es un ticket de un solo uso dentro de una transacción. ¿Cómo se obtiene un recibo? Por lo general, al realizar la transferencia. En un bloque de transacciones programable (PTB), un paso puede transferir el objetoCalPprincipal, lo que produce un ticket de recepción que puede usar el siguiente paso. Si el niño ya estaba en el lugar principal de una transacción anterior, puedes introducir un recibo como entrada para una nueva transacción (el SDK/CLI de Sui te permite especificar un objeto secundario por su identificador y su padre para generar el ticket). Importante: Recibir no es el objeto en sí, sino que aún no te otorga la propiedad. Solo indica que «el objeto de tipo T con este identificador es propiedad de ese progenitor y tengo la intención de quedármelo». Para capturar realmente el objeto, debes llamar a transfer: :receive: module example::toy_box { use sui::transfer::{Self, Receiving}; struct Toy has key { id: UID, name: vector } struct Box has key { id: UID } /// Remove a Toy child from a Box, returning the Toy to the caller. public entry fun take_toy(box: &mut Box, toy_ticket: Receiving): Toy { // Use the parent's UID and the Receiving ticket to get the Toy let toy = transfer::receive(&mut box.id, toy_ticket); // Now toy is an owned value we can return (or transfer to someone). toy } } En take_toy, el toy_ticket: Receiving representa un juguete que pertenece a la caja. Al llamar a transfer: :receive (&mut box.id, toy_ticket), invocamos la lógica nativa de Sui para sacar el objeto Toy de la caja. Esto hace algunas cosas fundamentales: verifica**en tiempo de ejecución que el toy_ticket realmente hace referencia a un objeto que actualmente es propiedad de la caja (utilizando el UID del dispositivo principal). Si algo no coincide (el objeto principal es incorrecto o el objeto no está realmente ahí), se cancelará. A continuación, devuelve el objeto Toy real como un valor propio en la transacción, lo que significa que ahora el Toy está bajo el control de nuestra función. Tenga en cuenta que tuvimos que pasar &mut box.id. Sui exige que tengamos unareferencia mutable al UID del padrepara llamar a receive. Se trata de un control de acceso inteligente: solo el módulo que puede generar un UID &mut del elemento principal puede permitir la recepción. Normalmente, el módulo de definición del tipo principal mostrará una función como take_toy que llama internamente a receive. Si el módulo principal no muestra ninguna función que proporcione un UID de &mut (directa o indirectamente), ningún código externo podrá arrebatar a sus hijos. De esta forma, el módulo principal controla cómo y cuándo se puede acceder a los niños. En el ejemplo, Box tiene un campo id: UID. Como take_toy está en el mismo módulo, puede tomar prestado &mut box.id. Los módulos o transacciones externos pueden llamar a take_toy (box_obj, ticket), pero no pueden llamar por sí mismos a transfer: :receive en Box porque box.id es privado. Este patrón garantiza que solo el código autorizado pueda recuperar a los niños.✅ ¿Qué pasa con los objetos anidados? Si Toy fuera literalmente un campo dentro de Box (por ejemplo, Box {id, toy: Toy}), no necesitaríamos recibirlo: el juguete estaría accesible siempre que tuvieras &mut Box. Pero eso también significa que es más difícil quitarlo o tratarlo por separado (es como si fuera parte de la caja). En el caso de los objetos infantiles, desvinculamos el almacenamiento: el juguete está separado y debe sacarse de forma explícita. Esta es la razón por la que Sui exige la recepción del billete y la recepción de la llamada, lo que convierte la recogida de un niño en una acción autorizada. Requisito de referencia mutable: Quizás te preguntes, ¿por qué &mut UID y no solo &UID? Mutable garantiza que el elemento principal esté bloqueado durante la operación de recepción, lo que evita la modificación simultánea y garantiza que la persona que llama tiene realmente el derecho de modificar ese elemento principal (lo que normalmente implica que es el propietario). Forma parte de las comprobaciones dinámicas de propiedad de Sui: al tomar un préstamo mutable del UID de la madre, Sui garantiza que ninguna otra transacción o acción paralela pueda interferir mientras tú extraes al hijo. Es un poco como cerrar la puerta de los padres antes de retirar el contenido. Ejemplo de uso en un bloque de transacciones: Supongamos que un objeto Box es propiedad de Alicia, y ella tiene un objeto Toy que quiere poner dentro de la caja y, después, quizás Así que sácalo más tarde. Así es como podría verse bien: Fija el juguete a la caja:** Alice llama a transfer: :public_transfer (toy, @); en un PTB. Esto hace que el juguete pase a la parte inferior de la caja (aquí usamos public_transfer porque se trata de un contexto de transacción; hablaremos de esto próximamente). Ahora el juguete es un derivado de la caja. -En la misma transacción o en otra, recupera el juguete: Alicia invoca example: :toy_box: :take_toy (box_obj,) donde ese recibo hace referencia al juguete. Tras el capó, take_toy llama a recibir, verifica la relación y devuelve el juguete. Ahora el Toy sería el resultado de la transacción y normalmente acabaría en la dirección de Alice (ya que lo devolvimos a través de una función de registro). Conclusiones clave: Los objetos infantiles no son accesibles de forma predeterminada; necesitas un ticket de recepción y una función adecuada para sacarlos. El módulo principal decide cómo se puede recuperar (proporcionando una función con el UID &mut). transfer: :receive se usa dentro del módulo de definición del módulo principal para los objetos de ese módulo o de sus amigos. Si el tipo del niño está definido en otro lugar, necesitarás un enfoque diferente (escribe public_receive...). Antes de continuar, un detalle más: si un objeto del tipo T solo tiene la habilidad clave (sin almacenar), Sui la considera un poco más restringida. Estos objetos no pueden recibirse mediante código genérico fuera de su módulo. En la práctica, esto significa que si T solo utiliza una clave y se convierte en un elemento secundario, tendrás que gestionar su recuperación en su propio módulo o en el módulo principal con una regla personalizada. Si T también tiene almacenamiento, tenemos más flexibilidad a través de public_receive. Exploremos eso a continuación.
- Sui
2 - ArtículoApr 12, 2025
✏️ Objetos entre padres e hijos en Sui Move
En Sui Move, los objetos pueden poseer otros objetos al igual que las cuentas poseen objetos. Esto abre nuevos patrones de diseño (y algunos errores) para los desarrolladores. En esta guía, desglosaré los conceptos de objetos entre padres e hijos en Sui Move en cuatro partes: 1.Introducción a los conceptos entre padres e hijos en Sui Move 2.Mecánica de recepción y control de acceso a objetos 3.Gestión infantil entre módulos con public_receive 4.Lógica vinculante y patrón de recibo de devuelta Al final, sabrás cómo anidar objetos, recuperar objetos secundarios mediante transfer: :receive, gestionar objetos secundarios en distintos módulos con public_receive e incluso crear objetos enlazados con el alma que devuelven a su propietario un bumerán. Introducción a los conceptos entre padres e hijos en Sui Move ###* ¿Qué son los objetos para padres e hijos?* En Sui, cada objeto tiene una identificación única y un propietario. Normalmenteel propietario es una dirección(como la cuenta de un usuario), pero el propietario también puede ser otro objeto. Si el objeto A es propietario del objeto B, llamamos a A el padre y a B el hijo. El hijo es propiedad del objeto y no de la dirección. Transferencia a objetos: en realidad, Sui no distingue entre una dirección y un ID de objeto; ambos son solo identificadores de 32 bytes, lo que significa que puedes transferir un objeto al ID de otro objeto de la misma manera que lo harías con la dirección de un usuario. Cuando haces esto, estás anidando un objeto dentro de un objeto principal. El tiempo de ejecución de Sui establece el campo de propietario del niño en el ID del padre (en lugar de una dirección) Entonces, ¿por qué es genial? Porque el niño conserva su propia identificación única y existe de forma independiente en el almacenamiento, pero ahora está vinculado al padre. Es como regalarle a tu amigo un objeto de colección único para que lo guarde en su casillero: el objeto de colección conserva su identidad y se puede rastrear, pero el casillero de tu amigo ahora aparece como propietario. Es importante distinguir entreObjetos únicos y objetos anidados y objetos secundarios: Objeto único (propiedad de la dirección) :**Un objeto normal que pertenece a una dirección (por ejemplo, la cuenta de un usuario). Este es el caso predeterminado: piense en los NFT, las monedas, etc., que se encuentran directamente en la billetera del usuario. Cada uno tiene un identificador único y es de alto nivel de almacenamiento. Objeto anidado (envuelto):* Objeto que se almacena *dentro de los datos de otro objeto (por ejemplo, como un campo de una estructura). En este caso, el objeto interno está envolvido ynoes una entidad de nivel superior independiente. No aparece por su ID en el almacenamiento global porque forma parte del contenido en bytes de la entidad principal. En Sui, si colocas un objeto como un campo en otro sin ningún tratamiento especial, queda envuelto. Objeto secundario (propiedad del objeto) :*Un objeto que pertenece a otro objeto *pero que no está incluido directamente en sus campos. El objeto secundario sigue siendo un objeto de nivel superior independiente almacenado (con su propio identificador y datos), y el identificador del padre se registra como propietario en los metadatos del hijo. Esto significa que puedes consultar o acceder al niño por su ID (con los permisos correctos). No está incrustado físicamente en el contenido de los padres, sino que es de propiedad lógica. Usando nuestra analogía, es como si le hubieras regalado a un amigo tu objeto coleccionable para que lo guardara. Sigue etiquetándolo individualmente y se puede rastrear, solo que lo guarda en su casillero. La ventaja de convertir a un niño en un objeto (por transferencia) en lugar de envolverlo es que el carné de identidad del niño permanece accesible desde el exterior. Por ejemplo, los exploradores o los monederos pueden mostrar un objeto secundario por identificador, mientras que un objeto envuelto es invisible fuera de su objeto principal. Los objetos infantiles también mantienen su identidad estable incluso cuando se mueven de un propietario a otro o se anidan en casas de padres distintos. Esto es ideal para cosas como el inventario en cadena o los patrones de «cartera dentro de otra billetera», en los que quieres que un objeto contenedor contenga muchos objetos a los que otros puedan seguir consultando de forma individual Propiedad y acceso: si un objeto es propiedad de otro objeto, normalmente solo el propietario del objeto principal puede acceder al objeto secundario o usarlo. Se trata de una forma de autorización dinámica. Por ejemplo, si Alicia es propietaria de un objeto principal P y P es propietaria del objeto secundario C, solo Alicia (o las transacciones que ella firme) pueden manipular C. Sui impone esta regla para que ser propietario de un padre sea como tener las llaves de todos sus hijos 🔑. Tal vez sepas: La función de transferencia a objeto de Sui básicamente nos otorga una propiedad de objetos similar a la de un árbol*. Un padre puede tener muchos hijos (y esos hijos pueden tener sus propios hijos, formando una jerarquía). Esto se logra tratando los ID de objetos como direcciones para las transferencias. Tenemos: Objetos propiedad de la dirección**(objetos únicos normales), Objetos propiedad de objetos**(objetos secundarios, que siguen siendo de nivel superior pero están vinculados a un objeto principal), Objetos envolvidos**(anidados dentro de los datos de otro objeto, no de nivel superior). En los próximos artículos, veremos cómo recuperar objetos secundarios o interactuar con ellos (ya que no se puede acceder a ellos directamente como los que pertenecen a una dirección) y cómo hacer cumplir las reglas que los rigen.
- Sui
- Move
3 - ArtículoApr 10, 2025
Creación de una dApp de lotería NFT de próxima generación con Sui Move y una interfaz de usuario moderna
🧩 Creación de una dApp de lotería NFT de próxima generación con Sui Move y una interfaz de usuario moderna Esta es tu guía definitiva para crear una dApp de lotería gamificada e impulsada por NFT utilizandoSui Move, con soporte para múltiples rondas, sistemas de recomendación, gobernanza de DAO y un sistema de diseño que encantará a la generación Z. Desde la arquitectura de contratos hasta el flujo de la interfaz de usuario, hagamos todo lo posible. 📦 Desglose de fases Fase 1: Lotería básica Juego de varias rondas Venta de entradas en NFT Sistema de recompensas por recomendación Votación DAO básica Fase 2: Mercado y gamificación Integración con el mercado de NFT Potenciadores (aumentan las posibilidades de ganar) Sistema de premios Lanzamientos aéreos ocultos Fase 3: DAO y multicadena Compatibilidad entre cadenas DAO con propuestas avanzadas Precios dinámicos Análisis en cadena 🧠 Smart Contract profundiza en Sui Move Estructura del contrato module nft_lottery_x::nft_lottery_x { use sui::object; use sui::balance::{Balance, zero}; use sui::coin::{Self, Coin}; use sui::clock::Clock; use sui::random::Random; use sui::event::emit; use sui::transfer; use sui::tx_context::TxContext; use std::option; use std::signer; const EGameNotStarted: u64 = 1000; const EGameAlreadyFinished: u64 = 1001; const EInvalidPayment: u64 = 1002; const ENoTickets: u64 = 1003; const EWinnerAlreadyChosen: u64 = 1004; const ENotWinner: u64 = 1005; public struct Game has key { id: UID, ticket_price: u64, start_time: u64, end_time: u64, total_tickets: u32, round: u32, winner: Option, balance: Balance, referral_bonus: u64, } public struct Ticket has key { id: UID, game_id: ID, ticket_number: u32, buyer: address, referrer: Option, } public struct GameCreated has copy, drop { game_id: ID, start_time: u64, end_time: u64, ticket_price: u64, } public struct TicketBought has copy, drop { game_id: ID, ticket_number: u32, buyer: address, referrer: Option, } public struct WinnerAnnounced has copy, drop { game_id: ID, winner_ticket: u32, round: u32, } public struct RewardClaimed has copy, drop { game_id: ID, ticket_number: u32, amount: u64, } public fun create_game( start_time: u64, end_time: u64, ticket_price: u64, referral_bonus: u64, ctx: &mut TxContext ) { let game = Game { id: object::new(ctx), ticket_price, start_time, end_time, total_tickets: 0, round: 1, winner: option::none(), balance: zero(), referral_bonus, }; emit(GameCreated { game_id: object::id(&game), start_time, end_time, ticket_price, }); transfer::share_object(game); } public fun buy_ticket( game: &mut Game, coin: Coin, clock: &Clock, referrer: Option, ctx: &mut TxContext ): Ticket { assert!(clock.timestamp_ms() >= game.start_time, EGameNotStarted); assert!(clock.timestamp_ms() (TicketBought { game_id: object::id(game), ticket_number: ticket.ticket_number, buyer: ticket.buyer, referrer: ticket.referrer, }); ticket } public entry fun determine_winner( game: &mut Game, rand: &Random, clock: &Clock, ctx: &mut TxContext ) { assert!(clock.timestamp_ms() >= game.end_time, EGameNotStarted); assert!(game.winner.is_none(), EWinnerAlreadyChosen); assert!(game.total_tickets > 0, ENoTickets); let mut generator = rand.new_generator(ctx); let winning_ticket = generator.generate_u32_in_range(1, game.total_tickets); game.winner = option::some(winning_ticket); emit(WinnerAnnounced { game_id: object::id(game), winner_ticket: winning_ticket, round: game.round, }); } public fun claim_reward( ticket: Ticket, game: Game, ctx: &mut TxContext ): Coin { assert!(object::id(&game) == ticket.game_id, EInvalidPayment); let ticket_num = ticket.ticket_number; assert!(game.winner.contains(&ticket_num), ENotWinner); let amount = game.balance.value(); let reward = game.balance.into_coin(ctx); emit(RewardClaimed { game_id: object::id(&game), ticket_number: ticket.ticket_number, amount, }); object::delete(object::id(&game)); reward } } Conclusiones clave: ✅ Balancegarantiza la seguridad tipográfica y el manejo adecuado de las monedas ✅ Optionindica claramente si se ha elegido un ganador ✅ Los eventos ofrecen trazabilidad para usuarios finales y exploradores 🛠 Comandos de CLI Sui sui client call --package --module nft_lottery_x --function create_game --args --gas-budget 10000000 Para comprar un boleto, determinar el ganador o reclamar una recompensa, siga flujos de CLI similares. 🔮 Futuras incorporaciones Restablecimiento automático de la lógica para la próxima ronda claim_reward Emite más eventos como ReferralRewardDistributed Refactoriza los premios mayores y las referencias en submódulos ¡Avísame si quieres una parte 2 para crear una interfaz de usuario e integrarla en la red de pruebas de Sui!
- Sui
3 - ArtículoApr 09, 2025
Guía de transacciones de SUI: desde la configuración hasta la ejecución y la verificación
Guía de transacciones de Sui: desde la configuración hasta la ejecución y la verificación Si sientes curiosidad por conocer los aspectos básicos de la ejecución de transacciones en la cadena de bloques Sui y quieres una guía práctica y detallada que te guíe paso a paso. En este artículo, analizaremos todo el proceso: desde configurar tu entorno de cliente, comprobar los objetos de tu monedero, calcular las comisiones de gas, hasta firmar y ejecutar una transacción y, por último, verificar sus detalles. Vamos a desglosarlo paso a paso: ¿Qué hace que Sui sea tan especial? 🔥 Sui ofrece una plataforma altamente optimizada para aplicaciones descentralizadas (dApps) y contratos inteligentes. Su elegante diseño para gestionar las tarifas de gas y la lógica de las transacciones lo convierte en un emocionante campo de juego para los desarrolladores que buscan ampliar los límites de la tecnología Web3. #2. Primeros pasos: configuración del entorno y configuración de billetera ⚙️ 2.1. Configuración de su entorno de cliente Sui Antes de sumergirse en las transacciones, asegúrese de que su cliente de Sui esté configurado correctamente. Sui admite múltiples redes (devnet, mainnet, testnet) y puedes comprobar cuál está activa con el siguiente comando: ➜ sui client envs ╭─────────┬─────────────────────────────────────┬────────╮ │ alias │ url │ active │ ├─────────┼─────────────────────────────────────┼────────┤ │ devnet │ https://fullnode.devnet.sui.io:443 │ │ │ mainnet │ https://fullnode.mainnet.sui.io:443 │ │ │ testnet │ https://fullnode.testnet.sui.io:443 │ * │ ╰─────────┴─────────────────────────────────────┴────────╯ Esto confirma que está conectado a la red de prueba. Estar en la red correcta es el primer paso hacia una transacción exitosa. #2.2. Comprobando tu billetera activa A continuación, verifica la dirección de tu monedero activo. Esto es crucial porque cada transacción está vinculada a la identidad de tu monedero: ➜ sui client active-address 0x35370841d2e69b495b1e2f944a3087e4242f314e503691a00b054e0ee2a45a73 #2.3. Consulta de objetos propios Con la API SUIX_GetOwnedObjects, puedes obtener detalles sobre los objetos (como monedas) que posees en la cadena de bloques. Este comando te ayuda a comprobar el saldo de tu cuenta y los activos disponibles para las transacciones: { "jsonrpc": "2.0", "id": 1, "method": "suix_getOwnedObjects", "params": [ "0x35370841d2e69b495b1e2f944a3087e4242f314e503691a00b054e0ee2a45a73", { "filter": { "MatchAll": [ { "StructType": "0x2::coin::Coin" } ] }, "options": { "showType": true, "showOwner": true, "showPreviousTransaction": true } } ] } Este paso es vital para verificar que tu monedero tiene las monedas necesarias (en este caso, monedas SUI) antes de intentar realizar cualquier transacción. #3. Cálculo del gas: presupuestación de los costos de transacción 💸 El gas es el combustible que impulsa las transacciones de la cadena de bloques. Es esencial entender tanto el precio del gas como su presupuesto para evitar errores en las transacciones. 3.1. Buscando el precio de la gasolina El precio actual de la gasolina se puede recuperar mediante la llamada a la API Suix_GetReferenceGasPrice: { "jsonrpc": "2.0", "id": 1, "method": "suix_getReferenceGasPrice", "params": [] } Si la API devuelve «1000", significa que cada unidad de gas cuesta 1000 MIST. Recuerde que 1 SUI equivale a 10^9 MIST, por lo que incluso los números más pequeños en MIST pueden sumar a la hora de presupuestar. 3.2. Establecer el presupuesto de gas Su presupuesto de gas es la cantidad máxima de gas (en términos de cantidad de combustible) que está dispuesto a gastar. Para nuestro ejemplo, supongamos que su presupuesto de gas es de 4964000 MIST. El costo total de una transacción normalmente se calcula de la siguiente manera: Costo total = costo de cálculo más costo de almacenamiento: reembolso de almacenamiento Por ejemplo: • Costo de cálculo: 1 000 000 MIST • Costo de almacenamiento: 2.964.000 MIST • Reembolso por almacenamiento: 978.120 MIST Por lo tanto, el costo neto se convierte en 1 000 000 + 2 964 000 − 978.120 = 2.985.880 MIST. Definir con precisión su presupuesto de gas garantiza que su transacción cuente con fondos suficientes para ejecutarse con éxito. 4. Elaborar la transacción: un simulacro de confianza 🔧 Antes de enviar una transacción real, es mejor realizar un «simulacro» para detectar cualquier posible problema. Esto te permite validar la lógica de la transacción sin gastar gasolina. #4.1. Creación de una transacción simulada Este es un ejemplo de una función de TypeScript que muestra cómo preparar y ejecutar una transacción en seco. Este código describe cómo dividir monedas y preparar las operaciones de transferencia: export const signSuiDryRunTransaction = async (requestParams: SignDryRequestParams): Promise => { const { gasPrice, privateKey, coinRefs, network, recipients } = requestParams; const keypair = Ed25519Keypair.fromSecretKey(privateKey); const tx = newTransaction(); // Configure gas payment, price, and sender tx.setGasPayment(coinRefs); tx.setGasPrice(gasPrice); tx.setSender(keypair.toSuiAddress()); // Split coins based on each recipient's amount const coins = tx.splitCoins(tx.gas, recipients.map((transfer) => transfer.amount)); recipients.forEach((transfer, index) => { tx.transferObjects([coins[index]], transfer.to); }); // Build and sign the transaction with the client const client = newSuiClient({ url: getFullnodeUrl(network) }); const bytes = await tx.build({ client }); const { signature } = await keypair.signTransaction(bytes); await verifyTransactionSignature(bytes, signature, { address: keypair.getPublicKey().toSuiAddress() }); return JSON.stringify([toBase64(bytes), signature]); }; Este paso en seco es crucial para garantizar que todos los detalles sean correctos antes de comprometer fondos reales. #5. Firmar y ejecutar la transacción: juntándolo todo ✍️ Tras un exitoso simulacro, el siguiente paso es firmar y enviar la transacción en la cadena de bloques. #5.1. Firmar la transacción A continuación se muestra un ejemplo refinado de función que firma la transacción con el presupuesto de gas especificado: const signSuiTransaction = async (requestParams: SignRequestParams): Promise => { const { gasBudget, gasPrice, privateKey, coinRefs, network, recipients } = requestParams; const keypair = Ed25519Keypair.fromSecretKey(privateKey); const tx = newTransaction(); // Set up gas parameters, including the gas budget tx.setGasPayment(coinRefs); tx.setGasPrice(gasPrice); tx.setGasBudget(gasBudget); tx.setSender(keypair.toSuiAddress()); // Split coins for each recipient const coins = tx.splitCoins(tx.gas, recipients.map((transfer) => transfer.amount)); recipients.forEach((transfer, index) => { tx.transferObjects([coins[index]], transfer.to); }); // Build the transaction and sign it const client = newSuiClient({ url: getFullnodeUrl(network) }); const bytes = await tx.build({ client }); const { signature } = await keypair.signTransaction(bytes); await verifyTransactionSignature(bytes, signature, { address: keypair.getPublicKey().toSuiAddress() }); return JSON.stringify([toBase64(bytes), signature]); }; Esta función integra todos los parámetros necesarios, incluidos los detalles del gas y los destinatarios, para garantizar que su transacción esté firmada de forma segura y lista para su ejecución. 5.2. Ejecutando la transacción Una vez firmada, la transacción se envía a la cadena de bloques mediante el punto final de la API SUI_ExecuteTransactionBlock: curl --location 'https://fullnode.testnet.sui.io:443' \ --header 'Content-Type: application/json' \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "sui_executeTransactionBlock", "params": [ "", [""], { "showInput": true, "showRawInput": true, "showEffects": true, "showEvents": true, "showObjectChanges": true, "showBalanceChanges": true }, "WaitForLocalExecution" ] }' Esta llamada devuelve una respuesta JSON detallada con información como el resumen de la transacción, el consumo de gas, las modificaciones de objetos y las actualizaciones de saldo. Nº 6. Verificación de su transacción: Cross-Check Everything 🔍 Después de ejecutar la transacción, es esencial verificar que todo se haya ejecutado según lo esperado. #6.1. Verificación del navegador Puedes comprobar tu transacción en un explorador de cadenas de bloques como Suivision Testnet Explorer. El explorador muestra todos los detalles de la transacción en un formato visual intuitivo, lo que facilita la detección de cualquier problema. 6.2. Verificación de línea de comandos Para una auditoría más detallada, utilice la línea de comandos: sui client tx-block -- 3FopuDy5qzKm1kLRFZCdi8Lynadym9j15NaVxzUH6nYD Este comando proporciona un desglose completo de la transacción, incluidos los detalles del remitente, el pago del gas, los cambios en los objetos y el estado de ejecución. 7. Análisis de la respuesta de JSON: comprensión de las capas de una transacción Analicemos la respuesta JSON que recibes después de ejecutar tu transacción: 7.1. Descripción general de la transacción jsonrpc e id: campos estándar para el protocolo JSON-RPC. resumen: el hash único de la transacción (p. ej., «3fopudy5qzkm1klrfzcdi8lynadym9j15navxzuh6nyd»), que se utiliza para el seguimiento. Timestamps y punto de control: proporciona un contexto sobre cuándo se ejecutó la transacción y el punto de control de la cadena de bloques en ese momento. 7.2. Contenido de la transacción Datos del remitente y del gas: incluye la dirección del remitente y todas las configuraciones relacionadas con el gas (pago, precio, presupuesto). Operaciones (transacciones): la lógica de las transacciones incluye operaciones como: SplitCoins: dividir una moneda de gasolina en partes más pequeñas. TransferObjects: mueve segmentos de monedas a las direcciones de los destinatarios especificadas. Firmas: las firmas criptográficas (codificadas en Base64) garantizan la autenticidad de la transacción. 7.3. Efectos de ejecución Estado: el estado de «éxito» confirma que la transacción se procesó sin errores. Consumo de gas: detalla los costos computacionales y de almacenamiento, junto con cualquier reembolso aplicable. Cambios en los objetos: describe qué objetos se modificaron, crearon o actualizaron como resultado de la transacción. Dependencias: muestra los valores hash de las transacciones relacionadas de los que depende esta transacción. Este desglose granular es esencial para depurar y mejorar el rendimiento de su dApp. 8. Perspectivas prácticas para desarrolladores: consejos y conclusiones Comprender cada paso de este proceso le proporciona las habilidades necesarias para crear aplicaciones Web3 seguras y eficientes en Sui. Estos conocimientos no solo lo ayudan a solucionar problemas, sino que también le permiten innovar con confianza dentro del ecosistema de Sui.
- Sui
- SDKs and Developer Tools
- Transaction Processing
3 - Artículo0xduckmove135Apr 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
4 - ArtículoLokie13Mar 16, 2025
Step by step guide to create a Suiet wallet
Step by step guide to create a Suiet wallet: Download suiet extension: https://suiet.app/ After successful installation, click on the Suiet icon in your browser and select "Create New". Set a strong password to protect your wallet. Write down and save your recovery phrase in a safe place. This phrase is needed to recover your wallet if needed Done
- Sui
1 - ArtículoBahador85Mar 15, 2025
Viaje como desarrollador de contratos inteligentes de SUI Move
En el artículo de hoy, quiero profundizar en una sugerencia de hoja de ruta para aquellos a quienes les guste entrar en el camino del desarrollo de SUI Move. 1. Comprenda los fundamentos de la blockchain Conceptos básicos:* Familiarízate con los conceptos clave de la cadena de bloques, como la descentralización, los mecanismos de consenso, las primitivas criptográficas y los contratos inteligentes. Descripción general de la cadena de bloques SUI:* Descubra qué hace que SUI sea única: su modelo de datos centrado en objetos, sus objetivos de rendimiento y la forma en que gestiona la administración del estado. 2. Aprende el lenguaje de los movimientos Conceptos básicos del idioma:* Comience con los fundamentos del lenguaje de programación Move. Concéntrese en: Tipos de recursos:* Cómo funcionan los recursos para garantizar la seguridad y la propiedad. Módulos y estructuras:* Cómo definir los módulos y las estructuras de datos. Funciones de entrada:* Cómo se ejecutan las transacciones a través de los puntos de entrada designados. Recursos recomendados: Utilice los tutoriales, la documentación y los repositorios de código de muestra oficiales del lenguaje Move. 3. Configure su entorno de desarrollo Herramientas y CLI:* Instale la CLI de SUI y configure la cadena de herramientas Move en su máquina local. Entorno de prueba local:* Configure una red local de desarrollo de SUI o utilice las redes de prueba disponibles. Esto le ayuda a experimentar con la implementación y las pruebas de los contratos inteligentes antes de ponerlos en marcha. IDE y depuración:* Elige un entorno de desarrollo integrado (IDE) que sea compatible con Move (por ejemplo, VSCode con extensiones Move) y familiarízate con la depuración y las pruebas de tus contratos. 4. Cree su primer contrato simple Tutoriales prácticos:* Empieza con un proyecto sencillo, como un contrato simbólico. Esto te permitirá aplicar las construcciones básicas de Move. Explora los patrones específicos de la SUI:* Trabaje con el modelo de objetos de SUI y aprenda cómo se procesan las transacciones dentro del ecosistema de SUI. Documentación y ejemplos:* Aproveche la documentación para desarrolladores y los proyectos de muestra de SUI para comprender las mejores prácticas. 5. Sumérjase en las funciones específicas de la SUI Modelo centrado en objetos:* Comprenda cómo SUI trata los objetos de manera diferente a las cadenas de bloques basadas en cuentas, como Ethereum. Modelo de gas y transacciones:* Estudie cómo se calculan las tarifas de gas y cómo se gestiona la ejecución de las transacciones en SUI. Administración estatal:* Conozca el enfoque de SUI para el almacenamiento estatal, las actualizaciones modulares y la administración del ciclo de vida de los objetos. 6. Pruebas, depuración e implementación Pruebas unitarias y de integración:* Escriba pruebas para verificar la lógica y la seguridad de sus contratos inteligentes. Asegúrese de cubrir los casos extremos y las posibles vulnerabilidades. Despliegue local y de red de prueba:* Implemente sus contratos en un entorno controlado para ver cómo funcionan en condiciones reales. Herramientas:* Utiliza las herramientas de depuración y las funciones de registro de SUI para iterar y mejorar tu código. 7. Mejores prácticas de seguridad y auditorías de código Comprenda los errores más comunes:* Estudia las vulnerabilidades de seguridad más comunes en los contratos inteligentes (por ejemplo, el reingreso, los controles de acceso inadecuados) y cómo el diseño de Move las mitiga. Reseñas de código:* Participa en las revisiones de código de la comunidad o colabora con tus compañeros para auditar y mejorar tu código. Verificación formal:* Explore las herramientas de verificación formal disponibles en Move para demostrar matemáticamente la exactitud de sus contratos. 8. Únase a la comunidad de desarrolladores de SUI Canales comunitarios:* Interactúa con otros desarrolladores a través de foros, canales de Discord o llamadas comunitarias. Compartir experiencias y desafíos tiene un valor incalculable. Contribuciones de código abierto:* Contribuya a proyectos de código abierto o repositorios de desarrolladores relacionados con SUI y Move. Manténgase actualizado:* Sigue los blogs, repositorios de GitHub y canales de redes sociales de SUI y Move para mantenerte al tanto de los nuevos desarrollos, actualizaciones y mejores prácticas. 9. Explore temas avanzados Aplicaciones complejas:* A medida que se sienta más cómodo, experimente con diseños de contratos inteligentes más avanzados, como los protocolos de financiación descentralizada (DeFi), los NFT o las carteras con múltiples firmas. Interoperabilidad e integración:* Aprenda a interactuar con otros contratos inteligentes e integrar los módulos SUI Move con sistemas fuera de la cadena. Rendimiento y escalabilidad:* Explore las técnicas para optimizar sus contratos a fin de aumentar la velocidad y la rentabilidad en la cadena de bloques SUI. 10. Crea un portafolio y sigue practicando Muestra proyectos:* Desarrolle y documente una serie de proyectos que demuestren su comprensión y experiencia. Aprendizaje continuo:* Blockchain y Move evolucionan rápidamente. Convierte el aprendizaje continuo en un hábito revisando la documentación, asistiendo a talleres y participando en hackatones. Ciclo de retroalimentación:* Utilice los comentarios de la comunidad para perfeccionar sus habilidades y mantenerse a la vanguardia en el desarrollo de contratos inteligentes. Aunque los elementos anteriores son sugerencias y no son la única forma de convertirse en un desarrollador de SUI, espero que os sean útiles. Feliz programación. ¡Feliz uso!
- Sui
- SDKs and Developer Tools
- Move
2 - Artículo0xduckmove135Mar 12, 2025
Setting Up a Project to Test the SUI Name Service (SuiNS)
The SUI Name Service (SuiNS) is a decentralized naming system on the SUI blockchain that allows users to map human-readable names (e.g., "0xduck.sui") to blockchain addresses or other data, enhancing usability and accessibility. For developers, testing the SuiNS SDK is an essential step to ensure applications can resolve these names correctly. In this article, we’ll walk you through the process of setting up a project to test the SuiNS SDK, from preparing your development environment to querying a name record like "0xduck.sui" and understanding the results. Introduction to SUI Name Service The SUI Name Service (SuiNS) simplifies blockchain interactions by allowing users to register memorable names instead of using complex cryptographic addresses. For example, instead of sending tokens to "0x1234...abcd", you could send them to "0xduck.sui". Testing the SuiNS SDK ensures that your application can correctly interact with this system, retrieving and interpreting name records as needed. In this project, we’ll set up a Node.js environment, connect to the SUI mainnet, and write a script to query the name record for "0xduck.sui". By the end, you’ll have a working setup to explore SuiNS further. Prerequisites Before starting, ensure you have the following: Node.js (version 14 or higher) and npm (version 6 or higher) installed. Download them from nodejs.org if needed. Basic understanding of JavaScript, particularly asynchronous programming (e.g., async/await). A code editor like Visual Studio Code (VS Code) for writing and running scripts. An internet connection to install packages and connect to the SUI. Setting Up the Development Environment Let’s create a new project directory and initialize it as a Node.js project. This will provide a clean workspace for our test. Step-by-Step Instructions: Open your terminal (e.g., Command Prompt, PowerShell, or a Unix shell). Create a new directory: mkdir suins-test-project cd suins-test-project Initialize a Node.js project: Run this command to create a package.json file with default settings: npm init -y Your project is now set up with a basic structure. Installing Dependencies Run the following in your terminal: npm install @mysten/suins @mysten/sui Verify the Installation: Check that the packages are added to package.json under dependencies. You can also confirm the installed versions by running: npm list @mysten/suins @mysten/sui This should output something like: suins-test-project@1.0.0 ├── @mysten/sui@x.x.x └── @mysten/suins@y.y.y Configuring the SUI Client The SUI client connects your project to the SUI blockchain. For testing, we’ll use the mainnet. Create a Script File: In your project directory, create a file named test-suins.js: touch test-suins.js # On Unix/macOS echo. > test-suins.js # On Windows Open test-suins.js in your editor and add the following: import { getFullnodeUrl, SuiClient } from '@mysten/sui/client'; // Create a SUI client connected to the testnet const suiClient = new SuiClient({ url: getFullnodeUrl('testnet') }); Note: If you encounter an error about ES modules (e.g., "Cannot use import statement outside a module"), add "type": "module" to your package.json: { "name": "suins-test-project", "version": "1.0.0", "type": "module", ... } Testing the Name Service Now, let’s write a script to query the name record for "0xduck.sui" and log the result. import { getFullnodeUrl, SuiClient } from '@mysten/sui/client'; import { SuinsClient } from '@mysten/suins'; // Create a SUI client connected to the testnet // const suiClient = new SuiClient({ url: getFullnodeUrl('mainnet') }); const client = new SuiClient({ url: getFullnodeUrl('mainnet') }); // Create a SuiNS client using the SUI client const suinsClient = new SuinsClient({ client, network: 'mainnet', }); // Function to test the name service async function testNameService() { try { // Query the name record for 'demo.sui' const nameRecord = await suinsClient.getNameRecord('0xduck.sui'); // Log the result console.log('Name Record for "0xduck.sui":', nameRecord); } catch (error) { console.error('Error fetching name record:', error.message); } } testNameService(); In your terminal, execute: node test-suins.js
- SDKs and Developer Tools
3 - ArtículoBahador85Mar 11, 2025
Suibase, a great tool to experience the SUI
As I was checking some resources for the SUI development, I faced a tool named, suibase. In my exploration on that, I found it very helpful, especially when using localnet which a local explorer will be set up on our local system. I loved it so much. as there is stated in the official website of Suibase: Suibase makes it easy to create "workdirs", each defining a distinct development environment targeting a network. It seems like virtual env in python programming. As far as I found this tool, there are many usefull functionalities which we can take benefit of: Key functionalities of Suibase include: Workdir Management: Suibase enables the creation of isolated workdirs for each network, ensuring that configurations and dependencies are maintained separately. This isolation facilitates organized and efficient development workflows. Suibase Simplified Command-Line Interface:* The tool provides scripts such as lsui, dsui, tsui, and msui, which serve as frontends to the Mysten Labs sui binaries for localnet, devnet, testnet, and mainnet, respectively. These scripts eliminate the need to manually switch environments, as they automatically execute the appropriate sui client and keystore for the targeted network. Localnet Operations:* Suibase offers commands like localnet start, localnet stop, and localnet status to manage the local network. Additionally, the localnet regen command allows developers to reset the network to its initial state, complete with predefined addresses and aliases, which is particularly useful for testing purposes. Faucet Functionality:* The localnet faucet command enables the distribution of Sui coins to specified addresses or all addresses within the localnet, facilitating testing and development activities. Independent Installation:* Suibase operates independently of other Mysten Labs installations and keystores, ensuring that it does not interfere with existing setups. This design allows Suibase to coexist safely with standard installations on the same system. By providing these features, Suibase enhances the development experience on the Sui network, offering a structured and efficient environment for building and testing applications. I recommend testing it!
- Sui
- SDKs and Developer Tools
3 - ArtículoBahador85Mar 11, 2025
How to fix the SUI installation error?
When I try to install and build the SUI binary on my local system with this command: cargo install --git https://github.com/MystenLabs/sui.git --bin sui --branch devnet I face this error: Please specify a package, e.g. cargo install --git https://github.com/MystenLabs/sui.git anemo-benchmark. After some digging, I found the solution and was able to install and build it error-free and completely using some modification in the above command: For Devnet: cargo install --locked --git https://github.com/MystenLabs/sui.git sui --branch devnet For Testnet: cargo install --locked --git https://github.com/MystenLabs/sui.git sui --branch devnet This way, you can install and build SUI on your local machine and start on your way! Best of luck.
- Sui
- Move
3
Gana tu parte de 1000 Sui
Gana puntos de reputación y obtén recompensas por ayudar a crecer a la comunidad de Sui.
- Sui
- SDKs and Developer Tools
- Architecture
- Move
- NFT Ecosystem
- Transaction Processing
- Security Protocols