Explorar
Conéctate con comunidades y descubre nuevas ideas.
Gana tu parte de 1000 Sui
Gana puntos de reputación y obtén recompensas por ayudar a crecer a la comunidad de Sui.
Comunidades
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.
Publicaciones principalesMiembros principales- 381
- 380
- 360
Move is an executable bytecode language used to implement custom transactions and smart contracts.
Publicaciones principalesMiembros principales- 271
- 260
- 251
The InterPlanetary File System (IPFS) is a protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system.
Publicaciones principalesMiembros principales- 25
- 20
- 20
Walrus is a decentralized storage and data availability protocol designed specifically for large binary files, or "blobs"
Publicaciones principalesMiembros principales- 35
- 32
- 26
The Graph is a decentralized protocol for indexing and querying blockchain data. The Graph makes it possible to query data that is difficult to query directly.
Publicaciones principalesMiembros principales- 2565
- 10
- 10
Aave is a decentralized non-custodial liquidity protocol where users can participate as depositors or borrowers.
Publicaciones principalesMiembros principales- 148
- 138
- 74
Peera is a decentralized questions and answers protocol for Web3 where users can organize and store their interests and skills, creating a common community platform
Publicaciones principalesMiembros principales- 328
- 286
- 225
Cyfrin Updraft is an education platform specializing on teaching the next generation of smart contract developers
Publicaciones principalesMiembros principales- 1780
- 75
- 60
Web3 (also known as Web 3.0) is an idea for a new iteration of the World Wide Web which incorporates concepts such as decentralization, blockchain technologies, and token-based economics.
Publicaciones principalesMiembros principales- 397
- 193
- 141
Polygon is a decentralised Ethereum scaling platform that enables developers to build scalable user-friendly dApps with low transaction fees without ever sacrificing on security.
Publicaciones principalesAnkr makes accessing Web3 easy for those who want to build and earn on the future web. Ankr is the main infrastructure provider for Polygon, BNB Smart Chain, and Fantom.
Publicaciones principalesMiembros principales- 89
- 43
- 34
Koii is a new way to design communications infrastructure that distributes computing authority across a wider group of personal devices.
Publicaciones principalesMiembros principales- 402
- 188
- 80
Functionland is replacing Cloud Storage and Service Subscription economy by introducing a new category of products, called Blockchain-Attached Storage. It creates value by auto-minting crypto for the users and allocating a share to the developers.
Publicaciones principalesSolidity is an object-oriented, high-level language for implementing smart contracts. It is a curly-bracket language designed to target the Ethereum Virtual Machine (EVM).
Publicaciones principalesMiembros principales- 76
- 50
- 46
Fractal Visions is a builder owned and operated creative web3 NFT project hub and a multifaceted & multidimensional experience. Bridging the gap between the physical and digital world.
Publicaciones principalesMiembros principales- 30
- 27
- 23
- Publicaciones principalesMiembros principales
- 12
- 11
- 10
Vyper is a relatively new, pythonic programming language used to write smart contracts. Vyper targets Ethereum Virtual Machine making it virtually impossible for developers to code misleading programs.
Publicaciones principalesMiembros principales- 40
- 22
- 20
Recompensa
- +10ParaMoveMar 11, 2025
Sui Move vs Aptos Move - What is the difference?
Sui Move and Aptos Move - two prominent implementations of the Move programming language. While both are rooted in the same foundational principles, they have diverged significantly in design, execution, and ecosystem development. To better understand their differences, we need to uncover some of their key aspects: How do their runtimes differ? Both Sui and Aptos implement their own custom Move virtual machines (VMs). How does this impact performance, scalability, and developer experience? For instance: Does Sui's runtime optimize for parallel execution differently than Aptos'? Are there notable differences in transaction lifecycle management or gas models? What are the differences between their standard libraries? The Move standard library is a critical component for building smart contracts. However, Sui and Aptos have forked their implementations, leading to divergence: Are there modules or functions unique to one implementation but absent in the other? How do these differences affect common use cases like token creation, NFTs, or decentralized finance (DeFi)? How does data storage differ between them? One of the most significant distinctions lies in how Sui and Aptos handle data storage: Sui uses an object-centric model, where each object has its own ownership and permissions. Aptos, on the other hand, retains a more traditional account-based model similar to Ethereum. How does this impact state management, composability, and gas efficiency? Is it fair to say that Aptos is closer to EVM while Sui is closer to SVM? Some developers argue that Aptos' account-based architecture resembles Ethereum's EVM, while Sui's object-centric approach aligns more closely with Solana's SVM. Do you agree with this analogy? Why or why not? How does this architectural choice influence developer ergonomics and application design? Are there universal packages working for both Sui Move and Aptos Move? Given their shared origins, it would be ideal if some libraries or tools were interoperable across both ecosystems. Are there any existing universal packages or frameworks that work seamlessly on both platforms? If not, what are the main barriers to achieving compatibility? Can one of them be transpiled into another? If a project is built on Sui Move, could it theoretically be transpiled to run on Aptos Move, or vice versa? What are the technical challenges involved in such a process? Are there tools or compilers currently available to facilitate this kind of migration?
21 - +10ParaSuiMar 05, 2025
«Errores de verificación de múltiples fuentes» en las publicaciones del módulo Sui Move: resolución automática de errores
Los desarrolladores que trabajan con Sui Move encuentran con frecuencia problemas relacionados con la aparición de varios errores de verificación del código fuente cuando intentan publicar o actualizar los módulos. Estos errores se producen debido a la falta de coincidencia entre las dependencias locales y las de la cadena, lo que provoca errores en las publicaciones y problemas de implementación. A continuación se muestra un ejemplo consolidado de los errores a los que se enfrentan los desarrolladores: Failed to publish the Move module(s), reason: [warning] Multiple source verification errors found: Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_set Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_map Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::bit_vector Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::ascii Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::hex Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::zklogin_verified_id Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::prover Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::coin Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::dynamic_field Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer On-chain version of dependency Sui::zklogin_verified_id was not found. On-chain version of dependency Sui::zklogin_verified_issuer was not found. Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::tx_context Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer_policy Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::kiosk Este problema a menudo surge debido a: Las versiones no coinciden entre el entorno de desarrollo local (por ejemplo, la CLI de Sui) y el estado de la cadena. Diferencias en las configuraciones de paquetes entre redes (por ejemplo, Mainnet frente a Testnet). Dependencias faltantes o desactualizadas en el entorno de la cadena. Preguntas clave ¿Cómo podemos automatizar la detección y resolución de estos desajustes de dependencia durante el proceso de publicación? ¿Qué herramientas o scripts se pueden desarrollar para garantizar que las dependencias locales siempre se alineen con sus homólogas de la cadena? ¿Hay alguna forma de agilizar este proceso integrando las comprobaciones de dependencias en las canalizaciones de CI/CD existentes o mejorando el SDK de Sui? Su tarea consiste en proponer una solución que aborde estos desafíos y garantice implementaciones más fluidas y confiables para los desarrolladores de Sui Move. Asegúrese de publicar su solución a continuación.
41
Más reciente
¿Cómo apuesto SUI con una billetera SUI después de la actualización?
Hola amigos, tengo una SUI de sobra y estoy usando la billetera SUI para administrarla. Antes podía asignar mi SUI a un validador específico, pero con la actualización reciente, no encuentro el botón de apuesta por ningún lado. Alguien sugirió cambiarme a Phantom, pero no sé si es necesario o si simplemente me falta algo. ¿Alguien puede ayudarme ahora sobre cómo apostar directamente desde la cartera de SUI?
00How to use Walrus for private file storage and ensure fault tolerance?
I'm running a Walrus publisher daemon on my PC, and I want to store files with private visibility. What are the steps to configure this? Additionally, I am curious about the fault tolerance measures in Walrus, especially if I need to run multiple storage nodes similar to an IPFS cluster.
00¿Por qué no puedo transferir mi NFT a otro monedero?
He intentado transferir mi NFT a otro monedero, pero automáticamente pasa a un quiosco. No estoy seguro de cuál es la causa de este problema. ¿Podría ser una limitación con el tipo de NFT que tengo?
11
Sin respuesta
¿Cómo apuesto SUI con una billetera SUI después de la actualización?
Hola amigos, tengo una SUI de sobra y estoy usando la billetera SUI para administrarla. Antes podía asignar mi SUI a un validador específico, pero con la actualización reciente, no encuentro el botón de apuesta por ningún lado. Alguien sugirió cambiarme a Phantom, pero no sé si es necesario o si simplemente me falta algo. ¿Alguien puede ayudarme ahora sobre cómo apostar directamente desde la cartera de SUI?
00How to use Walrus for private file storage and ensure fault tolerance?
I'm running a Walrus publisher daemon on my PC, and I want to store files with private visibility. What are the steps to configure this? Additionally, I am curious about the fault tolerance measures in Walrus, especially if I need to run multiple storage nodes similar to an IPFS cluster.
00
Tendencia
- 0xduckmove235ParaSuiApr 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
8 - Foksa225ParaPeera MetaJul 25, 2022
How to create an account
To create an account on the Peeranha website you need to log in first. Peeranha supports four wallets you can log in with: Torus, MetaMask, WalletConnect, and Coinbase. Note: If you are new to Web3 we recommend you to use Torus. Log in with Torus Click Log in. Select the checkbox I agree to the Terms and Conditions and Privacy Policy. Choose Torus in the pop-up window. Select any of the suggested ways you want to sign in or enter your email address. You are now logged in and have an account. In your profile section, you can add more detailed information about yourself and track your progress and achievements. To edit your profile, click Profile and select Edit. Enter all the information that you want to be visible in your profile.
5 - loth.broke110ParaPolygonMar 31, 2025
¿Utiliza heimdallcli en una configuración de red local dockerizada?
heimdallcliEstoy intentando usarlo matic-clidentro de mi red dockerizada local que configuré usando. heimdallcli tx gov submit-proposal param-change {pathToProposalJSONFile} --validator-id {validatorID} --chain-id {chainID}Mi objetivo principal es enviar una propuesta usando este comando:. Sin embargo, me aparece un error que dice: «El archivo de configuración «heimdall-config» no se encuentra en «/var/lib/heimdall/config"'. El directorio de configuración no parece existir en el entorno de Docker, aunque puedo ver registros que sugieren que Heimdall está funcionando. heimdallcli¿Cómo puedo resolver esto y hacer que el comando funcione?
54