Peera.

探索

连接社区，发现新想法。

Sui.X.Peera.

赚取你的 1000 Sui 份额

获取声誉积分，并因帮助 Sui 社区成长而获得奖励。

社区

过滤：所有区块链

赏金

  • Bolke .Peera.
    Bolke 237
    为SuiAug 22, 2025
    +50

    如何最大化利润持有 SUI：Sui Staking vs Liquid Staking

    我正在寻找全面的答案，以帮助社区了解使用SUI代币赚钱的最佳策略. 该赏金用于提供详细、经过充分研究的回复，涵盖SUI代币赚取机会的各个方面. 寻求详细答案的问题： Sui Staking 与 Liquid Staking -在 Sui 上进行传统质押和液体质押之间的主要区别是什么？ -哪些验证者提供最好的奖励，为什么？ -每种方法的风险和收益是什么？ -锁定期相比如何？ -天然气成本和运营差异？ 持有SUI的最佳赚钱方式是什么？ -SUI 持有者有哪些可用的赚钱方式？ -DeFi 协议提供 SUI 的收益挖矿机会 -接受 SUI 的贷款平台 -LP 供应策略和最佳配对 -还有其他被动收入方法吗？ 3.如何最大限度地提高SUI控股的利润？ -针对不同投资组合规模（小型、中型、大型持有者）的分步策略 -风险管理技巧 -进入/退出仓位的时机策略 -税收考虑和优化 -用于跟踪性能的工具和平台

    4
    14
  • Bolke .Peera.
    Bolke 237
    为SuiAug 12, 2025
    +15

    Sui Move 错误-无法处理交易未找到用于交易的有效汽油币

    当我这样做时： //从主币中拆分付款 const [PaymentCoin] = tx.SplitCoins ( tx.object (primaryCoin.coinObjectID)， [tx.pure.u64（所需付款金额）] ); //使用原始硬币支付汽油 tx.setGasPayment ([{ ObjectID：primarycoin.coinObjectID， 版本：PrimaryCoin.Version， 摘要：Primarycoin.digest }]); tx.setgasBudget (10_000_000)； 它抱怨可变对象在一次交易中不能出现多个对象. 当我取消汽油付款时，它会抱怨 “无法处理交易 未找到用于交易的有效汽油币. ”.我的合约函数接受 .01 sui 来换取 NFT

    3
    16
  • Xavier.eth.Peera.
    Xavier.eth318
    为SuiJun 27, 2025
    +15

    Sui 事务失败：为另一笔交易保留的对象

    我在JsonRpcError尝试在 Sui 上执行交易时遇到了持久问题. 该错误表明对象是为另一个事务保留的，尽管我已经实现了延迟的顺序事务处理. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 我试过了： -顺序事务执行（等待前一笔交易完成） -增加了交易之间的 3 秒延迟 而且仍然会持续出现同样的错误. 使用 Sui RPC 提交交易. 同一个对象 ID 在锁定列表中多次出现. 即使仔细安排交易顺序，也会出现错误. 是什么导致对象被 “保留” 用于其他交易？ 在交易中使用对象之前，如何正确检查对象是否可用？ 3.是否有在 Sui 中处理对象锁的最佳实践？ 这可能与交易终结时间有关吗？ 以前有人遇到过这个问题吗？如果您对Sui交易中的适当对象管理有任何见解，将不胜感激！

    4
    9

最新的

未回答

趋势

  • Gon.Peera.
    Gon58
    为SuiAug 31, 2025

    Sui’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?

    14
    14
  • Vens.sui.Peera.
    Vens.sui213
    为SuiApr 29, 2025

    Sui 生态系统中的 AMM 机器人

    Sui 生态系统中 AMM 机器人的主要特征和功能是什么？他们如何改进传统的交易机制，以及它们为在Sui网络上使用DeFi协议的用户提供了哪些优势？ 例如，我需要建造一个还是可以使用 Turbos Finance

    9
    6
  • 0xduckmove.Peera.
    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 这样的安全基础设施不是可选的——这是必不可少的

    8