Peera.

Más reciente

Mantente actualizado con las últimas publicaciones.

Publicaciones

1677
  • Forever_A-gator.Peera.
    ParaSuiMar 08, 2025
    Discusión

    Se retiró por error a SUI en lugar de a APTOS, ¿alguna opción de recuperación?

    Hola amigos, recientemente me retiré de Bybit y usé por error la red SUI en lugar de APTOS. He transferido el USDT a un monedero SUI, pero no es compatible con el USDT. Ya lo comprobé y no hay actividad reciente. También confirmé que Bybit procesó la retirada, pero el hash de la transacción que tengo no es válido en la red SUI. Lamentablemente, esto significa que es posible que pierdan mis activos. ¿Hay alguna forma de recuperar mis fondos o no tengo suerte?

    • Sui
    • Architecture
    0
    0
  • Elvin CLONE .Peera.
    ParaSuiMar 08, 2025
    Discusión

    ¿Dónde comprar $SUI en el estado de Nueva York?

    Estoy intentando averiguar dónde puedo comprar $SUI mientras esté en el estado de Nueva York. ¿Alguien podría ayudarme con las plataformas o bolsas disponibles para comprar $SUI aquí?

    • Sui
    0
    0
  • article banner.
    Ed.CyptoFi.Peera.
    ParaSuiMar 08, 2025
    Artículo

    Oficial de Sui Fam - 7 de marzo de 2025

    Sup Sui Fam, im Ed (analista e investigador de criptomonedas) Colaboro en la Fundación Sui como editor de vídeo para la comunidad oficial de Sui en X ¡Disfruta de las noticias y los alfas de esta semana en Sui! Sigue el canal oficial de Sui Fam en X: https://x.com/SuiFamOfficial Mi perfil X: https://x.com/EdCryptoFi

    • Sui
    0
  • jonamith.Peera.
    ParaPolygonMar 08, 2025
    Discusión

    ¿La retirada de llamadas en MaticWeth activa pasos automáticos?

    Estoy intentando entender el proceso dentro de la red Polygon para transferir los tokens de MaticWeth a la red Ethereum. Cuando llamo a la función de retirada de un token como MaticWeth, parece que se desencadena un evento de transferencia a la dirección cero. ¿Este evento inicia automáticamente los primeros pasos necesarios para devolver el token a Ethereum, simplemente porque el token ya está mapeado?

    • MATIC
    0
    0
  • kryptoschain.Peera.
    ParaSuiMar 08, 2025
    Discusión

    El USDT no aparece después de pasar de Sui a Ethereum

    Hace poco pasé algunos USDT de mi monedero Sui a Ethereum. Aunque no confirmé la transacción desde mi monedero EVM, los USDT fueron retirados de Sui, pero no aparecieron en mi monedero EVM. ¿Me pueden ayudar a resolver este problema?

    • Sui
    • Architecture
    0
    2
  • article banner.
    0xduckmove.Peera.
    ParaSuiMar 08, 2025
    Artículo

    Este artículo tiene como objetivo aprender y comprender el modelo #UTXO de $ BTC a $ SUI

    Este artículo tiene como objetivo aprender y comprender el modelo UTXO. Utiliza una forma fácil de entender de forma sencilla para clasificar los modelos y métodos de implementación de UTXO desde $ BTC hasta $ SUI. Proporcionaré una visión general completa, que ampliamos aquí para mayor claridad y profundidad, garantizando un análisis profesional y exhaustivo. Como uno de los principios básicos de diseño de Bitcoin, el modelo UTXO se ha convertido en un importante paradigma técnico en el campo de la cadena de bloques desde su nacimiento. Desempeña un papel importante a la hora de garantizar la seguridad y la trazabilidad de las transacciones, y proporciona otro camino además del modelo tradicional de saldo de cuentas. Como la tecnología blockchain se ha actualizado e iterado continuamente en los últimos años, el modelo UTXO en sí mismo también ha estado evolucionando y expandiéndose constantemente. Introducción a UTXO y sus orígenes El modelo UTXO, o resultado de transacción no gastado, es un concepto fundamental en Bitcoin, según el cual cada resultado de transacción que no se ha gastado se rastrea como un UTXO. Este modelo trata las transacciones como el dinero en efectivo, en el que el gasto implica seleccionar UTXO específicas para cubrir el importe, en lugar de modificar un único saldo. El ejemplo: Alice y Bob comienzan con 5 dólares cada uno. En el modelo de cuenta, si Bob le roba 2 dólares a Alicia, el saldo de Alicia pasa a ser de 3 y el de Bob de 7. En el modelo UTXO, los 5 dólares de Alice se gastan en crear dos nuevos UTXO: 2 dólares para Bob y 3 dólares para Alice. Bob ahora tiene su UTXO original de 5 dólares y el nuevo de 2 dólares, lo que suma un total de 7 dólares. Este enfoque, tal como se detalla en Understanding UTXO: A Comprehensive Guide, garantiza la transparencia y evita el doble gasto, ya que cada UTXO es rastreado públicamente en cadena y, al mismo tiempo, preserva la privacidad mediante direcciones anónimas. No es difícil ver que Alicia se queda con 3 dólares y Bob se queda con 7 dólares. Este método de contabilidad, que es similar al de sumar y restar en las escuelas primarias, aparece con frecuencia en el sistema bancario y se denomina modelo de cuenta/saldo. En él, el saldo de una cuenta existe como un valor único. Si se utiliza un enfoque diferente al del modelo de cuenta, como UTXO para representar la transferencia de patrimonio entre Alicia y Bob, el diagrama tendrá un aspecto diferente: Comparación con el modelo de cuenta/saldo El modelo de cuenta/saldo, habitual en la banca, mantiene un único saldo por cuenta, que se actualiza con cada transacción. Es sencillo, pero señala los problemas que surgen cuando varias transacciones modifican la misma cuenta, lo que a menudo requiere bloqueos y provoca cuellos de botella en el rendimiento, especialmente en caso de grandes volúmenes de transacciones. Por el contrario, el modelo UTXO, como se explica en Explorando el modelo UTXO: ¿qué lo diferencia en el mundo de la cadena de bloques?, evita esto al procesar las transacciones en UTXO independientes, lo que permite la ejecución en paralelo sin bloqueos, lo que mejora el rendimiento y la concurrencia. La privacidad es otra ventaja, ya que las carteras criptográficas generan nuevas direcciones por transacción, lo que dificulta la vinculación con personas, a diferencia de las direcciones fijas del modelo de cuentas, que son más susceptibles al análisis de correlación. Sin embargo, las limitaciones de las UTXO a la hora de gestionar una lógica empresarial compleja, como los contratos de varias etapas, dieron lugar a que Ethereum adoptara un modelo basado en cuentas, como se menciona en ¿Qué es una UTXO? Explicación del resultado de las transacciones no utilizadas. El modelo de objetos de SUI: uniendo los modelos UTXO y de cuentas El SUI, tal y como se detalla en el artículo X y está respaldado por Object Model | Sui Documentation, centra el almacenamiento en objetos, no en cuentas, con dos tipos de claves:OwnedObject (propiedad de la dirección) y SharedObject. La versión mejorada de UTXO, de OwnedObject, solo el propietario puede utilizarla y cada versión se utiliza una vez, de acuerdo con los principios de UTXO. Por ejemplo, un objeto propiedad de una dirección solo puede ser modificado por su propietario, lo que equivale a gastar un UTXO. SharedObject, por el contrario, es accesible para todos, al igual que el modelo de cuentas, pero requiere consenso para ordenar la lectura y la escritura, lo que resuelve las controversias estatales, como se indica en Sui Components | Sui Documentation. Esto se gestiona mediante procesos especiales, como la clasificación local. El enfoque orientado a objetos de Sui destaca cómo el modelo de SUI afecta a la escalabilidad, la seguridad y la experiencia del usuario. Tipos de propiedad en SUI | Tipo de propiedad | Descripción | Accesibilidad | --------| --------| -------- | Propiedad de la dirección | Propiedad de una dirección específica de 32 bytes (dirección de cuenta o ID de objeto) | Solo accesible para su propietario | Inmutable | No se puede mutar, transferir ni eliminar; no hay propietario | Accesible a todo el mundo | Compartido | 0x2::transfer::share_objectFunción de uso compartido | Accesible para todos | Envuelto | Organiza las estructuras de datos colocando un campo de structtipo en otro | No especificado Los objetos propios incluyen los que pertenecen a la dirección, lo que se alinea con UTXO, mientras que los objetos compartidos son accesibles de forma explícita para todos, lo que se ajusta al acceso más amplio del modelo de cuentas. Mi conclusión y consideraciones futuras La transición del modelo UTXO de Bitcoin al modelo de objetos de SUI representa una evolución significativa, ya que ofrece flexibilidad y aborda las limitaciones de UTXO en la lógica compleja a través de SharedObject, al tiempo que conserva las ventajas de simultaneidad de UTXO a través de OwnedObject. Este enfoque dual, analizado en Exploring Object-Centric Mode de Sui y en el lenguaje de programación Move, posiciona a la SUI como una plataforma versátil, que podría establecer un nuevo estándar para los modelos de datos de cadenas de bloques.

    • Sui
    • Architecture
    • SDKs and Developer Tools
    • Move
    0
  • Forever_A-gator.Peera.
    ParaSuiMar 07, 2025
    Discusión

    ¿Puedes transferir monedas SUI directamente a Ledger Stax?

    Estoy interesado en almacenar mis monedas SUI en un Ledger Stax. Me gustaría saber si es posible transferir directamente la SUI de una bolsa o monedero SUI a un Ledger Stax. Si es así, tengo la intención de hacer una transferencia. ¿Alguien tiene información sobre el apoyo actual a este proceso?

    • Sui
    0
    1
  • article banner.
    0xduckmove.Peera.
    ParaSuiMar 07, 2025
    Artículo

    Desarrollo de un contrato de juego de dados en Sui Move

    En este tutorial, te guiaré a través del proceso de creación de uncontrato inteligente para un juego de didoscon Sui Move. Este contrato permite a los jugadores apostar alresultado de una tirada de dados, y un administrador gestiona la bolsa de premios. Al final, tendrás un contrato totalmente funcional y un conocimiento sólido de varios conceptos clave de Sui Move. Introducción El contrato de juego de dados que crearemos permite las siguientes funcionalidades: Inicialización: el creador del contrato configura el juego. Gestión administrativa: un administrador puede depositar fichas en la bolsa de premios y retirarlas según sea necesario. Interacción con los jugadores: los jugadores participan adivinando el resultado de la tirada de dados y haciendo apuestas. Este tutorial asume que tienes un conocimiento básico de Sui Move y se centra en la introducción de nuevos conceptos a través de la implementación práctica. Antes de profundizar en el código, exploremos los conceptos clave que encontrarás: 1.1 Añadir dependencias: Para usar los tokens de otro contrato (por ejemplo, un contrato de token de grifo), debes añadirlos como una dependencia en tu proyecto. Esto se hace actualizando el Move.tomlarchivo de tu contrato: [dependencies] coin_duck = { local = "../coin_duck"”} Aquí, coin_duck es el contrato de token del grifo ubicado en la ruta especificada. El contrato dependiente también debe especificar su campo published-at en su propio Move.toml con el ID del paquete obtenido en el momento de la publicación, de la siguiente manera: óxido published-at = "packageId_from_publication" 1.2 Uso de aserciones Las afirmaciones garantizan que se cumplan ciertas condiciones durante la ejecución del contrato. La assert!macro comprueba una condición y, si falla, arroja un error y detiene la ejecución. Esto es útil para evitar estados inválidos, como apostar más que el saldo de un jugador. 1.3 Generar números aleatorios La equidad en el juego de dados se basa en la generación de números aleatorios. Sui Move proporciona el randommódulo para este propósito. Crearás un RandomGeneratorobjeto y lo usarás para generar un número aleatorio entre 1 y 6, simulando una tirada de dados. 1.4 Trabajando con monedas y balanzas En Sui Move, lostokensse gestionan mediante los módulos de monedas y saldo: Moneda: forma que envuelve el saldo y que se usa para transferir fichas. Saldo: representa el importe real del token, lo que permite realizar operaciones como dividir y fusionar. Los métodos clave incluyen: coin: :value (in_coin): devuelve el valor total de un objeto Coin. coin: :take (&mut balance, amount, ctx): extrae una cantidad específica de un saldo para crear una moneda. in_coin.balance_mut () .split (amount): divide una cantidad específica del saldo de una moneda. balance.join (balance): fusiona un saldo con otro. Estas operaciones se utilizarán para gestionar la bolsa de premios del juego y las apuestas de los jugadores. El contrato del juego de dados Este es el código completo del contrato del juego de dados, seguido de explicaciones detalladas: /// Game: Dice rolling. Players bet and guess the number. If correct, they win an amount equal to their bet; if incorrect, the bet goes to the game pool. module game_duck:game_duck; use sui::balance::{Self, Balance}; use sui::coin::{Self, Coin}; use sui::random::{Random, new_generator, generate_u8_in_range}; use coin_duck::duckfaucet::DUCKFAUCET; const ErrorUserInsufficient: u64 = 0x101; const ErrorGameInsufficient: u64 = 0x102; public struct Game has key { id: UID, pool_amount: Balance, } public struct Admin has key { id: UID, } fun init(ctx: &mut TxContext) { let game = Game { id: object::new(ctx), pool_amount: balance::zero() }; transfer::share_object(game); let admin = Admin { id: object::new(ctx) }; transfer::transfer(admin, ctx.sender()); } public entry fun addCoinToGamePool(game: &mut Game, in_coin: &mut Coin, amount: u64, _: &mut TxContext) { let value = coin::value(in_coin); assert!(amount = amount, ErrorGameInsufficient); let coin = coin::take(&mut game.pool_amount, amount, ctx); transfer::public_transfer(coin, ctx.sender()); } entry fun play(game: &mut Game, random: &Random, guess_num: u8, in_coin: &mut Coin, amount: u64, ctx: &mut TxContext) { assert!(game.pool_amount.value() >= (amount * 3), ErrorGameInsufficient); assert!(in_coin.balance().value() >= amount, ErrorUserInsufficient); let mut g = new_generator(random, ctx); let win_num = generate_u8_in_range(&mut g, 1, 6); if (win_num == guess_num) { let reward_coin = coin::take(&mut game.pool_amount, amount, ctx); in_coin.join(reward_coin); } else { addCoinToGamePool(game, in_coin, amount, ctx); } } Estructura de desglose del código Juego: un objeto compartido con un identificador único y un pool_amount (saldo) para almacenar la bolsa de premios. Administrador: objeto clave que pertenece al administrador para que Initialization (init) gestione el pool. Inicialización (init): Crea un objeto de juego con un bote de premios vacío y lo comparte públicamente. Crea un objeto de administrador y lo transfiere al creador del contrato. Añadir al pool (AddCoinToGamePool) Toma una cantidad específica de la in_coin del administrador. Usa assert! para garantizar que la moneda tenga un valor suficiente. Divide el importe del saldo de in_coin y lo fusiona en el pool_amount del juego. Resultado: Ganancia: si la apuesta coincide con la tirada, se saca del pozo una recompensa igual a la apuesta y se fusiona con el in_coin del jugador. Perder: si es incorrecta, la apuesta se deduce de in_coin y se añade a la bolsa a través de AddCoinToGamePool.

    • Sui
    • Move
    1
  • Caplec.Peera.
    ParaSuiMar 06, 2025
    Discusión

    ¿Cómo transferir Wormhole, con sede en Sui, a un intercambio?

    Estoy intentando transferir un Wormhole basado en Sui de mi monedero de Sui a otro intercambio. He intentado hacer el cambio a través de Suivision, pero el margen de error es demasiado alto ahora mismo. ¿Hay alguna alternativa para convertir o transferir sin utilizar el proceso de intercambio de Suivision?

    • Sui
    • Architecture
    0
    2
  • 0xfbbe...7709.Peera.
    ParaPeera MetaMar 06, 2025
    P&R expertos

    Counter.sol no se encuentra en los contratos de Openzeppelin

    lib/openzeppelin-contracts/contracts/utils/Counters.sol": No such file or directory (os error 2)

    • discussion
    • expert q&a
    0
    2
Usamos cookies para asegurarnos de que obtenga la mejor experiencia en nuestro sitio web.
Más información