趋势
发现最热门的帖子。
帖子
2730Sui’s Big Picture: A Blockchain Operating System for Everything?
Sui isn’t just pushing DeFi. The 10 being worked products in red — Walrus Millionaire (quests), *land (RWA), *human (personhood), updown (prediction markets), SuiSnaps (secret NFTs), CryptoGuard (DeFi security), *pay (new payments), Smash (social network), Drones/Humanoids (robots), RWA (tokenized assets) — show a much broader ambition. When combined with infrastructure projects like Walrus (storage), Scion (fast internet), internetless (low-signal mode), Prog Txn Block, Sponsored Txn, zkLogin, DeepBook, SuiBridge, Sui is positioning itself as a full-stack blockchain computer: handling storage, identity, finance, payments, social, entertainment, and even robotics — potentially able to run apps even in offline or low-connectivity environments. Is Sui truly building the first blockchain operating system that unifies all these layers? Which of these narratives — finance (RWA, CryptoGuard), social (Smash, SuiSnaps), or futuristic (internetless, robots) — will drive adoption first?
- Sui
- Architecture
140Sui 生态系统中的 AMM 机器人
Sui 生态系统中 AMM 机器人的主要特征和功能是什么？他们如何改进传统的交易机制，以及它们为在Sui网络上使用DeFi协议的用户提供了哪些优势？ 例如，我需要建造一个还是可以使用 Turbos Finance
- Sui
96最佳答案- 文章0xduckmove2078为SuiApr 08, 2025
👀 SEAL-我认为 Web3 数据隐私即将改变
👀 SEAL 已在 Sui 测试网上线 — 我认为 Web3 数据隐私即将改变 在 Web3 中，经常会听到诸如“用户拥有自己的数据”或“通过设计去中心化”之类的短语. 但是，仔细观察，许多应用程序仍然依赖集中式基础设施来处理敏感数据——使用 AWS 或 Google Cloud 等服务进行密钥管理. 这就引入了一个矛盾：表面上的去中心化，底层的集中化. 但是，如果有一种方法可以在不放弃权力下放的情况下安全地管理机密呢？介绍 SEAL — 去中心化机密管理 (DSM)，现已在 Sui 测试网上线. SEAL 旨在修复 Web3 最大的虚伪之处之一：在秘密使用 AWS 的同时大声疾呼去中心化 你可能会问我：海豹突击队是什么？ SEAL 是一种协议，可让您安全、分散地管理敏感数据——专为 Web3 世界构建. 可以将其视为插入 dApp 的隐私优先访问控制层. 您可以将 SEAL 视为一种可编程的数据锁. 你不只是手动锁定和解锁，而是使用Move on Sui将策略直接写入智能合约. 假设你正在构建一个 DApp，其中： -只有 NFT 持有者才能解锁高级教程 -或者，在泄露敏感文件之前，DAO 可能必须进行投票 -或者你想对元数据进行时间锁定并且只能在特定日期之后访问 海豹突击队使所有这些成为可能. 访问控制在链上 运行，完全自动化，无需管理员进行管理. 只是逻辑，直接融入区块链. 海豹突击队使所有这些成为可能. 访问控制在链上 运行，完全自动化，无需管理员进行管理. 只是逻辑，直接融入区块链. 另一个有趣的文章是SEAL如何处理加密. 它使用所谓的阈值加密，这意味着：没有一个节点可以解密数据. 需要一组服务器才能协同工作——有点像多重签名，但用于解锁机密. 这样可以分配信任，避免常见的单点故障问题. 为了保证信息的真正私密性，SEAL 会加密和解密客户端的所有内容. 任何后端都看不到您的数据. 从字面上看，它会留在你的手中，放在你的设备上. 而且 SEAL 不在乎你在哪里存储数据. 无论是 IPFS、Arweave、Walrus 还是其他平台，SEAL 都不会试图控制这部分. 它只关注谁可以看到什么，而不是东西的存储位置. 所以是的，它不仅仅是一个库或 API，它是 dApp 的链上优先、访问控制、默认隐私层. SEAL 填补了一个非常关键的空白. 让我们再分解一下. 如果你正在构建一个处理任何形式的敏感数据（封闭内容、用户文档、加密消息，甚至是锁定时间的 NFT 元数据）的 dApp，你也会遇到同样的问题： ➡️ 如何在不依赖集中服务的情况下安全地管理访问权限？ 如果没有像海豹突击队这样的队伍，大多数队伍都会： 使用 AWS KMS 或 Firebase 等集中式工具，这显然与去中心化背道而驰 或者尝试自己修补半生不熟的加密逻辑，这些逻辑通常会变得脆弱且难以审计 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 这两个比例都不好. 尤其是在你尝试跨多个链或社区构建无需信任的应用程序时. *SEAL 使整个过程模块化和可编程. * 您可以在Move智能合约中定义访问规则，SEAL会处理其余的——密钥生成、解密批准和访问强制执行——所有这些都无需任何人手动颁发密钥或进行后端检查. 更好的是，这些规则是可审计和不可改变的——一旦上链，它们就会遵循合同，而不是人工管理员. 因此，与其问 “谁应该管理对这些数据的访问权限？”你只要问： “应该用什么逻辑来定义访问权限？” >... 然后让链条来处理. 简洁且可扩展. 这就是SEAL不仅仅涉及 “安全工具” 的原因——它是*任何关心隐私、合规性或动态访问逻辑的DApp的基础层. * 这是一个很小的转变——但它改变了我们对 Web3 中数据的看法. *与其在部署后进行加密，或依赖外部服务，不如从内置隐私开始——访问权限完全由智能合约逻辑处理. * 而这正是 Web3 现在需要的. SEAL 实际上是如何运作的？ 我们已经介绍了什么是 SEAL以及为什么 Web3 需要它，让我们来看看它在幕后是如何构建的. 这部分是技术性更强的地方，但还是不错的. 一旦你看到所有部分是如何组合在一起的，建筑就会变得很优雅. 总体而言，SEAL的工作原理是使用一种名为基于身份的加密（IBE）的技术，将链上访问逻辑与链下密钥管理相结合. 这允许开发人员将数据加密为身份，然后依靠智能合约来定义允许谁对其进行解密. 步骤 1：智能合约中的访问规则（在 Sui 上） 一切都从智能合约开始. 当你使用 SEAL 时，你需要在你的 Move 合约中定义一个名为 seal_approve 的函数，你可以在这里写下解密条件. 例如，以下是用 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); } 一旦部署，该合约将充当看门人. 每当有人想要解密数据时，他们的请求都会被根据这个逻辑进行检查. 如果通过，密钥将被释放. 如果没有，他们就会被封锁. 没有人需要干预. ##步骤 2：基于身份的加密 (IBE) 这就是魔法发生的地方. SEAL 没有加密特定钱包地址（如 PGP 或 RSA）的数据，而是使用身份字符串——这意味着你可以加密成类似的内容： -0x 钱包地址 -dao_voted: proposal_xyz -pkgid_2025_05_01（基于时间戳的规则） -甚至是 game_user_nft_holder 当数据加密后，它看起来像这样： Encrypt(mpk, identity, message) -mpk = 主公钥（众所周知） -身份 = 逻辑定义的收件人 -消息 = 实际数据 之后，如果有人想解密，密钥服务器会检查他们是否符合政策（通过链上的 seal_approve 调用）. 如果获得批准，它将返回该身份的派生私钥. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) 然后，用户可以在本地解密内容. 因此，无需提前知道谁将解密即可完成加密. 您只需定义条件，SEAL 稍后再计算其余部分. 它是动态的. ##第 3 步：密钥服务器 — 脱链，但未集中化 你可能想知道：谁在拿着这些万能钥匙？ 这就是 SEAL 的密钥服务器的用武之地. 可以把它看作是一个后端： -持有主密钥 (msk) -关注链上合约（比如你的 seal_approve 逻辑） -仅在满足条件时才发出派生密钥 但是——这是关键——海豹突击队不只依赖一台密钥服务器. 你可以在阈值模式下运行它，在发放解密密钥之前，需要多个独立服务器达成一致. 例如：五分之三的密钥服务器必须批准请求. 这避免了中心故障点，也允许在密钥管理层进行权力下放. 更好的是，将来SEAL将支持MPC（多方计算）和基于飞地的设置（例如TEE），因此您可以在不影响可用性的情况下获得更强的保障. ##步骤 4：客户端解密 将密钥返回给用户后，实际的解密将在用户的设备上进行**. 这意味着： -服务器永远看不到你的数据 -后端从不存储解密的内容 -只有用户可以访问最后的消息 这是一个可靠的隐私模型. 即使有人破坏了存储层（IPFS、Arweave 等），如果不传递访问逻辑，他们仍然无法读取数据. 以下是快速思维模型： 这种结构使您可以轻松构建访问规则不是硬编码的去中心化应用程序，它们是动态的、可审计的，并且完全集成到您的链逻辑中. ##SEAL 背后的团队 SEAL 由区块链安全社区的知名人物Samczsun领导. 他曾是Paradigm的研究合伙人，曾审计过多个生态系统并将其从重大漏洞中拯救出来. 现在，他全职致力于将 SEAL 建成 Web3 隐私基础设施的核心部分. 凭借他的背景和信誉，SEAL 不仅仅是另一个实验工具，它是一次严肃的尝试，旨在使去中心化数据隐私既实用又可扩展. 随着 SEAL 在 Sui 测试网上线，它为 Web3 应用程序如何管理机密带来了新的标准. 通过结合链上访问控制、阈值加密和客户端隐私，SEAL 为去中心化数据处理提供了更值得信赖的基础. 无论你是在构建 dApp、DAO 还是去中心化游戏，SEAL 都提供了一个强大的工具包，可以在不影响去中心化的前提下执行访问控制和保护用户数据. 如果 Web3 要向前发展，像 SEAL 这样的安全基础设施不是可选的——这是必不可少的
- Sui
- Architecture
- SDKs and Developer Tools
8 如何在 Move 中合并两个硬币对象？
*我想理解 Sui Network 的这一方面，因为我要么构建、调试，要么部署一些涉及这个领域的东西. 我想详细解释这个机制或功能的工作原理，以及相关的 CLI 用法、移动代码结构或架构概念. 我的目标是获得足够的清晰度，将这些知识应用到一个真实的项目中——无论是自定义智能合约、NFT系统、钱包集成还是DeFi工具. 与 EVM 链相比，Sui Network 具有独特的功能，因此我对它的与众不同之处以及它如何影响开发最佳实践特别感兴趣. 有示例代码、命令行示例或典型错误需要注意会有所帮助，尤其是在使用 Sui CLI、SDK 或在本地网络/测试网上部署时. 归根结底，我希望避免常见错误，遵循最佳的安全原则，并确保我正在开发的功能在现实条件下表现出预期. *
- Sui
- Architecture
- SDKs and Developer Tools
- NFT Ecosystem
715最佳答案
Sui Passkey Adoption
Sui Introduces Passkey: Seamless Web3 Onboarding and Developer Integration Published: August 7, 2025 | Source: Sui Foundation The Sui ecosystem has unveiled passkey support on Mainnet, a breakthrough designed to make Web3 access as simple as logging into your favorite mobile app. With passkey, users can sign in using familiar methods like Face ID, fingerprint recognition, or a device passcode, eliminating the need for browser extensions, seed phrases, or complicated setup flows. This isn’t just a quality-of-life upgrade. It represents a paradigm shift in blockchain usability, aligning the Sui experience with the same authentication standards that already power billions of daily logins across the internet. What is a Passkey? A passkey is a cryptographic credential that leverages device-native authentication. Instead of managing private keys or recovery phrases, users access applications with biometrics or passwords already supported by their phones, laptops, or hardware devices. Built on open standards:* Passkey follows the *FIDO Alliance* and *W3C WebAuthn** specifications. Widely supported:** Apple, Google, and Microsoft all support passkeys across their platforms. Secure and recoverable:* Because credentials can be *cloud-synced**, users can restore access when switching devices—without awkward recovery phrases. By integrating this model, Sui makes blockchain access feel familiar, intuitive, and as frictionless as signing into a banking or email app. Why Passkey Matters For Users Passkey removes many of the biggest barriers to blockchain adoption: No more seed phrases to memorize. No browser extensions to install. Authentication flows that feel just like Web2 apps. Enhanced recovery thanks to cross-device syncing. Support for advanced setups like multisig wallets or pairing passkeys with zkLogin for layered security. The experience is especially powerful on mobile, where the complexity of traditional wallets has long been a blocker to mainstream adoption. For Developers Passkey also reshapes the developer landscape: Direct integration:** Apps no longer need to depend on third-party wallets for onboarding. Lightweight setup:** Passkey support is built into the Sui TypeScript SDK. Advanced capabilities:** Developers can enable QR-based cross-device login, multisig authentication, and native biometric login. Better retention:** Reducing setup friction lowers user drop-off rates during onboarding. Building with Passkey on Sui The Sui TypeScript SDK introduces the PasskeyKeypair class to make integration straightforward. Developers can create, recover, and use passkeys with just a few lines of code. Importing the PasskeyKeypair import { BrowserPasskeyProvider, BrowserPasswordProviderOptions, PasskeyKeypair, } from '@mysten/sui/keypairs/passkey'; Creating a New Passkey To initialize a passkey wallet tied to your app’s domain: const keypair = await PasskeyKeypair.getPasskeyInstance( new BrowserPasskeyProvider('Sui Passkey Example', { rpName: 'Sui Passkey Example', rpId: window.location.hostname, authenticatorSelection: { authenticatorAttachment: 'cross-platform', // or "platform" }, } as BrowserPasswordProviderOptions), ); cross-platform**: Works with hardware keys and mobile devices. platform**: Uses device-bound authenticators like Touch ID, Face ID, or Windows Hello. It’s recommended to cache the PasskeyKeypair in your frontend so the public key is always available when signing transactions. Recovering a Passkey If the cached keypair is lost or the user switches devices, recovery is possible: let provider = new BrowserPasskeyProvider('Sui Passkey Example', { rpName: 'Sui Passkey Example', rpId: window.location.hostname, } as BrowserPasswordProviderOptions); const testMessage = new TextEncoder().encode('Hello world!'); const possiblePks = await PasskeyKeypair.signAndRecover(provider, testMessage); const testMessage2 = new TextEncoder().encode('Hello world 2!'); const possiblePks2 = await PasskeyKeypair.signAndRecover(provider, testMessage2); const commonPk = findCommonPublicKey(possiblePks, possiblePks2); const keypair = new PasskeyKeypair(commonPk.toRawBytes(), provider); With two signed messages, a unique public key can be reconstructed. Alternatively, apps can prompt users to sign one message and resolve the correct public key by checking on-chain activity. Using PasskeyKeypair Once initialized, usage mirrors any other keypair in the SDK: const publicKey = keypair.getPublicKey(); const address = publicKey.toSuiAddress(); const message = new TextEncoder().encode('hello world'); const { signature } = await keypair.signPersonalMessage(message); const txSignature = await passkey.signTransaction(txBytes); Full implementation examples are available in the MystenLabs passkey repo. Supported Platforms Sui’s passkey implementation works with any device that complies with WebAuthn. That includes most modern browsers and operating systems on both desktop and mobile. Developers and users can reference the Passkeys.dev device support list for a breakdown of compatible platforms and authenticators. Nimora: The First Passkey Wallet The first real-world wallet to support passkeys on Sui is Nimora. It demonstrates how seamless onboarding and transaction signing can feel when blockchain fades into the background, letting users interact as naturally as they would with any modern app. Looking Ahead The launch of passkey is more than a feature—it’s a glimpse of the future. Just as the web moved from clunky logins to biometric and single sign-on systems, Web3 is undergoing its own transformation. By prioritizing both security and simplicity, Sui is setting a new industry standard. If widely adopted, passkeys could finally relegate seed phrases and confusing onboarding flows to blockchain’s early history. For users, it’s effortless access. For developers, it’s a lighter integration path. For Web3, it’s a necessary evolution toward mass adoption.
- Sui
- Architecture
- SDKs and Developer Tools
7如何使用 SUI CLI 在测试网和主网之间切换？
我想理解 Sui Network 的这一方面，因为我要么构建、调试，要么部署涉及这个领域的东西. 我想详细解释这个机制或功能的工作原理，以及相关的 CLI 用法、移动代码结构或架构概念. 我的目标是获得足够的清晰度，将这些知识应用到一个真实的项目中——无论是自定义智能合约、NFT系统、钱包集成还是DeFi工具. 与 EVM 链相比，Sui Network 具有独特的功能，因此我对它的与众不同之处以及它如何影响开发最佳实践特别感兴趣. 有示例代码、命令行示例或典型错误需要注意会有所帮助，尤其是在使用 Sui CLI、SDK 或在本地网络/测试网上部署时. 归根结底，我希望避免常见错误，遵循最佳的安全原则，并确保我正在开发的功能在现实条件下表现出预期.
- Sui
- NFT Ecosystem
- Move
717最佳答案- 专家问答为SuiJun 30, 2025
Why can’t I connect my wallet to a Sui dApp?
I’m trying to use a Sui dApp (like Tradeport, SuiSwap, or a custom platform), but my wallet won’t connect properly. Sometimes, I get no error at all—just nothing happens when I click "Connect Wallet." Other times, I see errors like: "Wallet not detected" (even though I have Sui Wallet or another wallet installed) "Connection failed: Invalid account" "Transaction rejected" before I even approve anything What I’ve tried: Refreshing the page Switching browsers (Chrome, Firefox, Brave) Checking wallet extension permissions Trying different networks (Devnet, Testnet, Mainnet) Reinstalling the wallet extension Questions: Why does this happen, and how can I fix it? Are there common mistakes users make when connecting wallets to Sui dApps? If my wallet was working before but suddenly stopped, what could be the cause?
- Sui
- Transaction Processing
71最佳答案 如何在Sui Move对象中实现自定义序列化？
目标： ✔ 优化存储效率（降低 BCS 开销） ✔ 启用跨链兼容性（例如，以太坊 ABI） ✔ 支持版本化架构升级 ✔ 处理复杂的嵌套对象结构 当前的挑战： -bcs::serialize对于自定义格式来说太严格了 -递归结构序列化问题 -向后兼容的反序列化需求 ###关键问题 性能和成本 -Sui 对象最省气的序列化模式是什么？ 版本控制和升级 -如何通过版本控制实现向后兼容的编码/解码？ 3.复杂的数据处理 -序列化嵌套对象和递归类型的最佳做法？ 安全注意事项 -如何避免常见的陷阱（例如，可延展性、通过格式错误的数据造成的 DoS）？
- Sui
76- 专家问答为SuiJul 18, 2025
为 Sui NFT 实施特许权使用费制度
####项目要求 我正在Sui上开发一个具有以下需求的NFT系列： 链上特许权使用费— 可强制执行的削减百分比 灵活性— 每个 NFT/收藏的费率不同 商城兼容性— 适用于主要平台 可升级性— 在不破坏现有 NFT 的情况下可调整费率 ####当前的挑战 基本的特许权使用费结构行之有效，但缺乏执法 在多个收款人之间分期付款方面苦苦挣扎 不确定如何追踪二次销售 ####关键问题 天然气效率— 将成本降至最低的最佳特许权使用费结构是什么？ 执法— 如何确保所有市场都兑现特许权使用费？ 3.多收款人拆分— 向多方分发付款的最佳方式？ 可升级性— 如何在铸造后毫无问题地修改特许权使用费率？
- Sui
72最佳答案
- Sui’s Big Picture: A Blockchain Operating System for Everything?140
- How to add a token to Suiet and Slush wallets?02
- How does Sui's object-centric data model enable parallel transaction processing03
- How can I design a scalable event logging system in Move for real-time dApp analytics?01
- How to build a replayable event-checkpoint indexer in Move12
- 4652
- 4310
- 4168
- 3036
- 2982
- 2773
- 2565
- 2478
- 2372
- 2339