1 篇博文 含有标签「加密」

公有链为所有参与者提供同步且可审计的账本，但默认暴露所有数据。2025 年 9 月 3 日正式登陆 Sui 主网的 Seal，通过将链上策略逻辑与去中心化密钥管理结合，让 Web3 构建者能够精确控制谁能解密哪些载荷。

摘要​

• 产品定位： Seal 是一个秘密管理网络，使 Sui 智能合约可以在链上强制执行解密策略，同时客户端使用基于身份的加密（IBE）保护数据，并依赖阈值密钥服务器派生密钥。
• 价值所在： 无需自建后端或依赖不透明的链下脚本，隐私与访问控制直接成为 Move 的一等公民。开发者可以将密文存储在任意位置（Walrus 是理想搭档），并持续控制读取权限。
• 适用人群： 推出代币门控内容、定时解锁、私密消息或遵循策略的 AI 代理的团队，可以接入 Seal SDK，将精力集中在产品逻辑而非复杂的密码基础设施上。

策略逻辑写在 Move 里​

Seal 包含 seal_approve* Move 函数，用于定义某个身份字符串在何种条件下、由谁请求密钥。策略可以组合 NFT 持有、白名单、时间锁或自定义角色体系。用户或代理发起解密请求时，密钥服务器会通过 Sui 全节点状态评估策略，仅在链上判断通过时才会批准。

由于访问规则属于你的链上包的一部分，因此它们是透明、可审计的，并可以与其他智能合约代码一起进行版本管理。治理更新也能像其他 Move 升级一样发布，具备社区审查和链上历史。

阈值密码学负责密钥管理​

Seal 按照应用自定义的身份来加密数据。由开发者挑选的独立密钥服务器委员会共享 IBE 主密钥。当策略校验通过后，各服务器会为请求的身份导出密钥份额。当 t 台服务器响应后，客户端就能组合出可用的解密密钥。

你可以通过选择委员会成员（Ruby Nodes、NodeInfra、Overclock、Studio Mirai、H2O Nodes、Triton One 或 Mysten 的 Enoki 服务）以及设置阈值，在活性与机密性之间做权衡。想要更强的可用性？选择更大的委员会和更低的阈值。需要更高的隐私保障？提高法定人数，更多使用许可制服务商。

开发者体验：SDK 与会话密钥​

Seal 提供 TypeScript SDK（npm i @mysten/seal），负责加解密流程、身份格式化与批量请求处理，还可以签发会话密钥，避免应用频繁访问时钱包不断弹窗。对于高级场景，Move 合约可以通过特殊模式请求链上解密，使得托管释放或抗 MEV 拍卖等逻辑能够直接在合约中执行。

Seal 与存储层无关，因此团队可以将其与 Walrus 组合实现可验证的 Blob 存储，或根据运营需求使用 IPFS 甚至中心化存储。无论密文存在哪里，加密边界及其策略执行都会伴随数据移动。

使用 Seal 的最佳实践​

• 建模可用性风险： 2-of-3 或 3-of-5 等阈值直接映射为可用性保障。生产部署应混合不同服务商、监测遥测数据，并在托管关键流程前签订 SLA。
• 注意状态差异： 策略评估依赖全节点执行 dry_run 调用。避免依赖快速变化计数器或同一检查点内排序的规则，以免服务器之间出现临时不一致的审批结果。
• 规划密钥卫生： 派生密钥保存在客户端。请做好日志、轮换会话密钥，并考虑包裹加密——用 Seal 保护加密大载荷的对称密钥——以减小设备泄露时的影响范围。
• 为轮换做设计： 某次加密所使用的委员会在加密时就已固定。需要替换服务商或调整信任假设时，请预留通过重新加密迁移到新委员会的升级路径。

未来展望​

Seal 的路线图包括验证者运营的 MPC 服务器、类似 DRM 的客户端工具以及抗量子 KEM 选项。对于正在探索 AI 代理、高价值内容或受监管数据流的团队而言，本次发布已经给出了清晰蓝图：在 Move 中编写策略，组合多元化的密钥委员会，并在 Sui 的信任边界内交付尊重用户隐私的加密体验。

如果你打算在下一次发布中采用 Seal，可先用 2-of-3 的开放式委员会和简单的 NFT 门控策略做原型，然后迭代出与应用风险画像匹配的服务商组合与运营控制。