Peera.

探索

连接社区,发现新想法。

Sui.X.Peera.

赚取你的 1000 Sui 份额

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

社区

赏金

  • Xavier.eth.Peera.
    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交易中的适当对象管理有任何见解,将不胜感激!

    2
    4
  • Xavier.eth.Peera.
    SuiJun 17, 2025
    +15

    能力约束如何与异构集合中的动态字段相互作用?

    我正在建立一个需要处理具有不同能力要求的多种资产类型的市场,我遇到了一些关于Move类型系统的基本问题. 我想将不同的资产类型存储在同一个集合中,但它们有不同的能力: -常规 NFT:key + store(可转让) -Soulbound 代币:key 仅限(不可转让) -具有转移限制的自定义资产 public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } 关键问题: -能力要求:使用时dynamic_field::add(),Vstore 编译时是否总是需要的?包装器类型能解决这个问题吗? -异构存储:单个 Bag 能否存储具有不同能力集(key + store + copyvskey + store)的对象,并在运行时以不同的方式处理它们? -类型安全:由于动态字段会执行类型擦除,因此在检索值时如何保持类型安全?存储类型元数据的模式是什么? -见证模式:能力限制如何与幻影类型一起使用?我可以将Asset和存储Asset在同一个集合中并稍后提取类型信息吗? 建立一个系统,在该系统中,NFT、soulbound 代币和受限资产都需要市场功能,但转移语义不同. 我尝试过包装器类型,每个能力集合有多个集合,单独的类型元数据存储. 每种方法都在类型安全性、燃气成本和复杂性之间进行权衡.

    0
    4
  • Peera Admin.Peera.
    SuiMay 29, 2025
    +10

    当 Move 结构有命名字段时,为什么 BCS 需要精确的字段顺序才能进行反序列化?

    当 Move 结构有命名字段时,为什么 BCS 需要精确的字段顺序才能进行反序列化? 我一直在深入研究 Move 中的 BCS 编码/解码,特别是跨链通信和链下数据处理. 在浏览 Sui Move 文档中的示例时,我遇到了一些似乎违反直觉的行为,我正在尝试理解底层的设计决策. 根据BCS规范,“BCS中没有结构(因为没有类型);该结构只是定义了字段序列化的顺序. ”这意味着在反序列化时,我们必须按照与peel_*结构字段定义完全相同的顺序使用函数. 我的具体问题: 设计理由:当 Move 结构具有命名字段时,为什么 BCS 需要精确的字段顺序匹配?像 JSON 或其他自描述格式一样,将字段名称与值一起序列化不是更强大吗? 泛型类型交互:文档提到 “包含泛型类型字段的类型最多可以解析到第一个泛型类型字段. ”考虑一下这个结构: struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } 部分反序列化在这里到底是如何工作的?我可以反序列化到more_metadata并忽略两个泛型字段,还是第一个泛型字段(generic_data)完全阻止了进一步的反序列化? 跨语言一致性:使用 @mysten /bcs JavaScript 库序列化将由 Move 合约使用的数据时,在以下情况下会发生什么: -我不小心重新排序了 JavaScript 对象中的字段? -Move 结构定义会在合约升级中更改字段顺序? -我有带有自己的泛型参数的嵌套结构吗? 实际启示:在生产系统中,团队如何处理 BCS 架构演变?您是否对BCS架构进行了版本控制,还是期望结构字段顺序在部署后不可变?

    5
    3

最新的

  • CarlkawIy.Peera.
    SuiJul 01, 2025

    如何从旧钱包中恢复SUI硬币?

    在设置新的 Slush 账户时,我一直在尝试找到我的 SUI 硬币,但我没有看到它们. 如何验证我是否使用正确的短语来导入我的旧钱包?

    0
    2
  • MiniBob.Peera.
    SuiJul 01, 2025

    掌握动作语言概念 — 课程 #2

    虽然我之前做的课程 #1向你介绍了在Move中编写智能合约和在Sui区块链上构建简单DApp的基础知识,但本课程的重点是加深你对Move语言本身的理解——从其强大的类型系统到泛型、事件、模块和访问控制机制等高级模式. 在本课程结束时,你将能够: -编写模块化、可重复使用且安全的移动代码 -有效使用泛型、技能和资源类型 -使用功能实现精细的访问控制 -发送和监听事件以进行链下集成 -处理复杂的数据结构,例如表格和向量 -了解 Move 与 Solidity 等其他智能合约语言有何不同 让我们深入了解 Move 语言的核心! 第 1 步:了解 Move 的核心语言特性 Move 在设计时充分考虑了安全性和清晰度. 让我们来探索使Move作为智能合约语言独一无二的一些最重要的功能. 1.1 面向资源的编程(重温) Move 的核心是资源的概念,资源是特殊类型,除非明确允许,否则无法复制或删除. 这强制安全处理代币或NFT等数字资产. module examples::token { use sui::object::{Self, UID}; struct MyToken has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext): MyToken { MyToken { id: object::new(ctx), value: 100, } } } 在这个例子中: MyToken-key是资源,因为它有能力. -它可以存储 (store) 并由其唯一标识id. -除非指定,否则无法复制或删除. 这样可以保证每个MyToken实例都是唯一拥有和管理的,从而防止意外复制或删除. 1.2 能力系统 Move 中的每种类型都有一组技能,用于定义其支持的操作: | 能力 | 意义 | | ---------| | copy| 可以复制 | | drop| 可以在不破坏的情况下丢弃 | | store| 可以存储在全局存储中 | | key| 可用作带有 ID 字段(即对象)的结构 | 示例: struct Example has copy, drop { value: u64 } 了解这些能力对于设计安全和可预测的智能合约至关重要. 为什么能力很重要 能力在编译时执行严格的规则. 例如: -仅包含key且store无法复制或删除的结构. -除非已存储或传输,否则您无法从函数中返回不可删除的结构. 这样可以防止诸如双重支出或意外代币丢失之类的错误. 1.3 泛型和类型参数 Move 支持泛型类型,允许开发人员编写灵活且可重用的代码. module examples::storage { use sui::object::{Self, UID}; struct Box has key { id: UID, content: T, } public fun new_box(ctx: &mut TxContext, content: T): Box { Box { id: object::new(ctx), content, } } } 这里`是一个类型参数,可以在Box`安全高效的同时处理任何类型. 注意:phantom关键字表示T不影响结构的运行时表示形式——这对于抽象建模很有用. 步骤 2:模块化开发和包管理 随着您的 Move 项目变得越来越复杂,组织代码变得至关重要. 2.1 创建和发布移动包 Move 包包含一个或多个模块并定义依赖关系. 它是 Move 中的部署和版本控制单元. 目录结构: sources/ place.move user.move Move.toml 在以下位置定义依赖关系Move.toml: [dependencies] Sui = { git = "https://github.com/MystenLabs/sui.git", subdir = "crates/sui-framework" } MyLibrary = { local = "../my-library" } 您可以将包发布到 Sui 网络,并在多个 DApp 中重复使用它们. 2.2 重用现有模块 cointransfertx_contextSui 框架提供经过实战考验的模块,如、和. 在编写自定义逻辑之前,请务必检查可用内容. 例如,要传输对象,请执行以下操作: use sui::transfer; public entry fun send_place(place: Place, recipient: address) { transfer::public_transfer(place, recipient); } 使用标准库可确保更安全、更快的开发和更好的互操作性. 第 3 步:事件和链下通信 要构建现实世界的应用程序,您的Move合约需要与前端或索引器等链下系统进行通信. 3.1 发出事件 移动允许发出可以由外部服务索引的事件. use sui::event; struct PlaceCreated has drop { name: String, } public fun emit_place_created(name: String) { event::emit(PlaceCreated { name }); } 该事件将出现在区块链上,可供探索者或索引工具接收. 3.2 监听事件 使用诸如Suiet Explorer、Subsquid或 Sui JSON-RPC API之类的工具来监听发出的事件并在应用程序中做出相应的反应. 在 JavaScript/TypeScri import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); const events = await provider.getEvents({ MoveEventType: '0x...::example::PlaceCreated' }); 步骤 4:访问控制和安全模式 在处理智能合约时,安全性至关重要. Move 提供了多种工具来实现强大的访问控制. 4.1 对象所有权模型 Sui 在协议层面强制执行所有权. 只有对象的所有者才能对其进行变异或转移. public entry fun update_name(sweet_place: &mut SweetPlace, new_name: String) { sweet_place.name = new_name; } 只有当前所有者才能调用此函数. 4.2 能力模式 要获得更精细的权限,请使用能力模式——创建特殊对象,授予对某些功能的有限访问权限. struct AdminCap has key { id: UID } public entry fun grant_admin_cap(ctx: &mut TxContext) { let cap = AdminCap { id: object::new(ctx) }; transfer::public_transfer(cap, tx_context::sender(ctx)); } public entry fun restricted_action(_: &AdminCap) { // perform admin action } 现在,只有持有该的用户AdminCap才能执行restricted_action. 这种模式广泛用于 DeFi 和 DAO 中,以安全地委托权限. 步骤 5:处理复杂的数据结构 Move 支持结构化数据类型,允许开发人员对复杂的逻辑和关系进行建模. 5.1 向量 向量用于存储相同类型项目的有序集合. let names = vector[String::utf8(b"Alice"), String::utf8(b"Bob")]; 它们对于存储 NFT、用户角色或动态元数据列表很有用. 用法示例: vector::push_back(&mut names, String::utf8(b"Charlie")); 5.2 表(通过 Sui 标准库) 虽然 Move 本身不支持地图或哈希表,但 Sui Table在其标准库中提供了该类型. use sui::table::{Self, Table}; struct Registry has key { id: UID, entries: Table, } public fun add_entry(registry: &mut Registry, key: u64, value: String) { table::add(&mut registry.entries, key, value); } 使用表高效管理大型数据集. 步骤 6:测试和调试合约 测试可确保您的 Move 代码在各种条件下都能按预期运行. 6.1 Move 中的单元测试 使用测试框架直接在 Move 模块中编写单元测试. #[test] public fun test_create_sweet_place() { let ctx = tx_context::dummy(); create_sweet_place(&mut ctx, String::utf8(b"My House")); } 使用以下命令运行测试: sui move test 6.2 使用 Sui Explorer 部署合约后,使用 Sui Explorer 检查交易、查看对象状态和调试问题. 步骤 7:高级动作概念的实际应用 现在您已经了解了核心语言特性,让我们来探索它们如何应用于现实场景. 7.1 NFT 铸币平台 创建一个平台,允许用户利用所有权和资源模型铸造由 Move 资源支持的 NFT. 7.2 DAO 投票系统 使用 Move 实施去中心化自治组织 (DAO) 进行投票、提案和治理,使用事件和功能进行安全操作. 7.3 代币互换和 AMM 使用Move模块构建去中心化交易所(DEX)来表示流动性池和代币互换,使用泛型和表格进行有效的状态管理.

    2
  • Evgeniy CRYPTOCOIN.Peera.
    SuiJun 30, 2025

    什么是动态 NFT,为什么 Sui 在它们方面表现出色?

    NFT 空间正在发展,超越了静态图像和个人资料图片 (PFP). 下一个前沿?动态 NFT(DNFT)——可以根据现实世界的数据、用户互动或链上事件发生变化的代币. 尽管许多区块链都支持NFT,但由于其创新的架构,Sui Network在推动DNFT的未来方面处于独特的地位. 本文探讨了: 是什么让 NFT 变得 “动态”? 为什么 Sui 的技术非常适合 DNFT 当今的真实用例 交互式数字资产的未来 1. 什么是动态 NFT? 与传统 NFT(静态且不可变)不同,动态 NFT 可以更新其: -元数据(例如,根据游戏统计数据而变化的体育 NFT) -外观(例如,随着时间的推移而演变的艺术品) -实用工具(例如,解锁新福利的忠诚度 NFT) 它们是如何工作的? DNFT 使用智能合约逻辑 + 外部数据输入(预言机、用户操作等)来触发更改. 示例: -一件对天气敏感的 NFT 艺术品,可根据实时气候数据改变颜色. -游戏角色NFT,在你玩游戏时会升级. 2. 为什么 Sui 是动态 NFT 的最佳区块链 虽然以太坊和索拉纳也支持 DNFT,但 Sui 的设计具有关键优势: 链上存储(无外部依赖关系) -大多数区块链在链下存储 NFT 元数据(例如 IPFS),这使得动态更新变得笨重. -Sui 将所有内容存储在链上,实现即时、无需信任的修改. 移动语言:安全灵活的升级 -以太坊的 Solidity 需要复杂的代理合约才能升级的 NFT. -Sui 的 Move 语言允许原生可变性,没有笨拙的变通方法. 并行处理(大规模可扩展性) -一次更新数千个 DNFT?以太坊在拥堵中挣扎. -Sui 的并行执行可处理数百万次更新,不会减速. 以对象为中心的模型(粒度控制) -每个 NFT 都是具有可自定义逻辑的独立对象. -启用微调的交互性(例如,只有所有者才能触发更改). 3. Sui 上的 DNFT 的真实用例 游戏和元界 -不断进化的游戏内物品(例如,使用时获得能力的剑 NFT). -跨游戏互操作性(Sui 的对象可以在 dApp 之间移动). 示例:像 Panzerdogs 这样的基于 SUI 的游戏使用 DNFT 来制作可自定义的头像. * 生成式和反应式艺术 -人工智能驱动的 NFT 可根据市场趋势改变风格. -合作艺术,收藏家影响最后一件作品. 示例:*像 Sui Gallery 这样的艺术实验室举办 dnFT 展览. * 真实世界资产 (RWA) 跟踪 -使用财产记录更新的 NFT 契约. -自动过期或续订的认证徽章. 忠诚度和会员计划 -随着客户支出而改善的动态折扣 NFT. -VIP 访问通行证可随着时间的推移解锁新的等级. 示例:*Sui 的零售合作伙伴正在测试 dnFT 忠诚度计划. * 4. Sui 上 DNFT 的未来 期待看到: -集成了人工智能的 DNFT(例如,生活在 NFT 头像中的聊天机器人). -DeFi抵押的DNFT(价值根据市场状况进行调整). -完全链上游戏,每种资产都是可变的 dNFT. 结论:Sui 正在构建 NFT 的未来 虽然静态 NFT 在 2021-2023 年占据主导地位,但动态 NFT 将主导下一轮牛市,而 Sui 的技术使其成为理想的平台. 凭借**链上存储、Move的安全性和无与伦比的可扩展性,Sui有望成为高级 DNFT 的发源地.

    5

未回答

  • Owen.Peera.
    Owen496
    SuiJun 11, 2025

    结构发生变化时如何更新商家在ObjectTable中的密钥?

    大家好,我才刚刚开始写智能合约,我正在做我的第一个项目. 对于我遇到的问题,我很乐意得到一些帮助. 到目前为止,我已经创建了一个Merchant看起来像这样的结构: -id:唯一标识符 (UID) -owner: 商家的地址 -key: 用作唯一密钥的字符串 -balance: 一个 u64 代表他们的余额 我还做了一个MerchantRegistry结构来管理所有商家: -id: 另一个 UID -merchant_to_address:将ObjectTable地址映射到商家 -merchant_to_key:将密ObjectTable钥映射到商家 我希望能够通过卖家的地址或他们的密钥来查找他们. 当用户更新Merchant结构内的密钥时,更改不会自动更新merchant_to_key表中的密钥. 这意味着旧钥匙仍然指向商家,这会破坏事情. 我尝试从表中删除该条目并使用新密钥将其插回去,但我一直遇到错误,例如: “没有掉落能力就无法忽略数值” 我很确定这是一个初学者的错误,但我无法在任何地方找到明确的解释或解决方案. 有没有正确的方法来处理结构和查找表中的密钥更新?

    5
    0
  • 0xduckmove.Peera.
    SuiJun 06, 2025

    上传海象 blob 最简单的前端是什么?

    只是一个可以上传到海象的简单用户界面?(除了毛茸茸的)

    2
    0
  • 0xc348...79f3.Peera.
    FunctionlandApr 14, 2025

    设置 NAS 或 BAS

    在尝试将我的塔式机用作 NAS 时,我按照说明进行操作,但结果是: PS C:\WINDOWS\system32 > ssh pi @fulatower ssh:无法解析主机名 fulatower:主机未知. PS C:\WINDOWS\system32 > ssh pi @192 .168.1.150 ssh:连接到主机 192.168.1.150 端口 22:连接超时

    0
    0

趋势

  • Vens.sui.Peera.
    SuiApr 29, 2025

    Sui 生态系统中的 AMM 机器人

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

    8
    2
  • 0xduckmove.Peera.
    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
  • MarlKey.Peera.
    SuiApr 30, 2025

    是通过 EOA 发布 Move 包的唯一方法吗?

    我认为在Sui链上没有办法,因为链上没有发布软件包的模块.

    7
    3