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.

IPFS

Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.

Walrus is a decentralized storage and data availability protocol designed specifically for large binary files, or "blobs"

Walrus

Move is an executable bytecode language used to implement custom transactions and smart contracts. 

Move



1. 简介：全球贸易是信任瓶颈

现代供应链跨越数十个国家、数百家供应商和无数文档，其中许多文件是纸质的、容易出错或无法核实的. 

从集装箱追踪到海关申报和原产地证书，全球贸易受到以下问题的困扰：
 • 跨司法管辖区和系统的数据分散
 • 欺诈性文件和伪造
 • 争议解决效率低下
 • 核对费用高昂且缺乏透明度

Sui 提供可编程、透明和可扩展的区块链平台，能够通过安全的自动化、可追溯性和模块化治理对整个全球贸易过程进行建模. 



2. 为什么使用 Sui 进行贸易和供应链？

与许多通用区块链不同，Sui的面向对象架构和并行执行使企业能够：

交易应用程序中的功能优势
基于对象的建模对集装箱、货物、文档等现实世界资产进行建模
水平可扩展性处理大量事件跟踪和更新
zkLogin 身份验证安全地识别用户（海关代理人、供应商）
事件记录和排放追踪跨网络的整个监管链
自定义 Move 模块对合约逻辑进行编码（例如，原产地规则、费率）

Sui 将交易文件转换为可验证的数字资产，并将流程转换为透明、自动执行的工作流程. 



3.用例：使用原产地证书的国际运输

让我们来看一个简化的用例. 

👟 场景：运动鞋从越南运往欧盟

利益相关者：
 • 胡志明市的制造商
 • 货运承运人
 • 海关经纪人
 • 欧盟进口商

基于 SUI 的工作流程：
 1. 制造商创建的装运对象（原产地、批号、内容）
 2. 越南贸易管理局颁发的原产地证书
 3.货运公司在货运转移时更新 TransitStatusObject
 4. 海关人员验证文件并对清关进行数字签名
 5. 欧盟零售商在链上收到可验证的产品 + 元数据

好处：
 • 所有利益相关者都可以访问防篡改的审计记录
 • 没有基于电子邮件的文档共享或 PDF 伪造
 • 立即遵守进出口规则



4. 基于 Sui 的交易协议的架构

每个供应链资产或文件都成为链上的头等公民. 

🔩 核心模块：
 • 装运对象 — 包括物品、重量、原产地、唯一编号
 • CertificateModule — 验证文件真实性和颁发者角色
 • CustomsApprovalModule — 海关人员可以批准/拒绝装运
 • TransiteVentModule — 发出位置更新（例如，端口已扫描、已加载）

🔐 示例：用于证书验证的移动模块

模块交易:: CertificateModule {
 struct 证书有密钥 {
 <u8>origin_country：矢量，
 发行人：地址，
 valid_until: u64，
 }

 <u8>公共娱乐问题证书（发行人：&signer，国家：矢量）{
 let cert = 证书 {
 起源国：国家，
 发行人：签名者:: address_of（发行者），
 有效期直到：1690000000，
 };
 move_to（颁发者，证书）；
 }

 公共基金验证（证书：&证书）：bool {
 时间戳:: now () < cert.valid_until
 }
}

这种逻辑确保只有受信任的机构才能签发和验证贸易文件. 



5. 互操作性：跨境实时协作

Sui 的模块化身份和客体逻辑允许在没有中央控制的情况下进行跨司法管辖区的合作：

利益相关者对 Sui 的行动
港务局将扫描事件附加到 ShipmentObject
国家出口局颁发数字签名证书
承运人更新配送预计送达时间和状况报告
海关代理在链上验证真实性和合规性
零售商检索可验证的产品历史记录 + 二氧化碳元数据

借助基于 Sui 构建的 API 和仪表板，即使是非技术参与者也可以安全地参与该协议. 



6. 欺诈预防和可追溯性

全球贸易欺诈每年导致数十亿美元的收入损失. Sui 用以下方法来对抗这个问题：
 • 通过 zkLogin 与身份关联的数字签名文档
 • 带有时间戳事件的不可变监管链
 • 基于 NFT 的带有关联认证的商品代币
 • 智能触发器可防止篡改或未经授权的传输

示例：防伪

每个奢侈品代币（例如名牌手袋）都可以：
 • 链接到原产地证书 + 工厂批号
 • 包括绑定到链上对象的二维码
 • 除非经过验证的账户进行身份验证，否则禁止转售



7. 碳信用额度和 ESG 整合

企业面临着证明可持续供应链的压力. Sui 可以：
 • 记录每次装运或产品单位的碳排放量
 • 允许第三方（审计师、非政府组织）验证碳分数
 • 将 ESG 报告附加到运输 NFT
 • 启用链上交易或申请碳补偿

示例：集装箱的移动日志用于估算排放，并将 carbonScoreObject 附加到产品代币上. 买家可以在购买前进行验证. 



8. 全球网络的扩展注意事项

Sui 的并行执行和低延迟使其为企业做好准备：

规模要求套装功能
每日 100,000 次更新并行对象处理
每条链 100 多个利益相关者对象级权限
实时 API 需要高吞吐量 RPC + 事件订阅
数据保留对象历史 + 链上日志

随着全球物流需求的增长，Sui 可以快速扩展. 



9. 挑战和部署策略

挑战缓解策略
司法管辖区数据限制使用特定区域的模块 + 对象标签
区块链知识有限构建用户友好的 dApps + Web UI
与传统系统集成中间件 + 链下连接器
安全 + 合规性审计 + 排放日志 + 签名证明

从一条贸易通道或产品线开始，然后逐步扩展协议和集成. 



10. 结论：在Sui上建设全球贸易的未来

Sui 以对象为中心、可编程和可扩展的架构为全球可验证的交易协议提供了基础. 

借助 Sui，企业可以：
 • 减少文书工作、延误和欺诈
 • 自动化多方工作流程
 • 实现全面的可追溯性和 ESG 合规性
 • 无需中央服务器即可构建共享数据层

在信任、透明度和速度决定贸易成功的世界中，Sui 不仅仅是一个区块链，它是未来供应链的信任基础设施. 

⸻

1. Introduction: Global Trade Is a Trust Bottleneck

The modern supply chain spans dozens of countries, hundreds of vendors, and countless documents—many of them paper-based, error-prone, or unverifiable.

From container tracking to customs declarations and certificates of origin, global trade is plagued by:
	•	Data fragmentation across jurisdictions and systems
	•	Fraudulent documentation and counterfeiting
	•	Inefficient dispute resolution
	•	Costly reconciliation and lack of transparency

Sui offers a programmable, transparent, and scalable blockchain platform capable of modeling the entire global trade process—with secure automation, traceability, and modular governance.

⸻

2. Why Use Sui for Trade and Supply Chain?

Unlike many general-purpose blockchains, Sui’s object-oriented architecture and parallel execution allow enterprises to:

Feature	Benefit in Trade Applications
Object-based modeling	Model real-world assets like containers, shipments, docs
Horizontal scalability	Handle high-volume event tracking and updates
zkLogin authentication	Securely identify users (customs agents, suppliers)
Event logging & emissions	Trace the full chain of custody across networks
Custom Move modules	Encode contract logic (e.g., rules of origin, tariffs)

Sui transforms trade documents into verifiable digital assets—and processes into transparent, self-executing workflows.

⸻

3. Use Case: International Shipment with Certificate of Origin

Let’s walk through a simplified use case.

👟 Scenario: Sneaker shipment from Vietnam to the EU

Stakeholders:
	•	Manufacturer in Ho Chi Minh
	•	Freight carrier
	•	Customs brokers
	•	EU importer

Sui-based Workflow:
	1.	ShipmentObject created by manufacturer (origin, batch number, contents)
	2.	CertificateOfOriginObject issued by Vietnam trade authority
	3.	Freight company updates TransitStatusObject as shipment moves
	4.	Customs agent verifies documents and digitally signs clearance
	5.	EU retailer receives verifiable product + metadata on chain

Benefits:
	•	All stakeholders have access to a tamper-proof audit trail
	•	No email-based doc sharing or PDF forgery
	•	Immediate compliance with import/export rules

⸻

4. Architecture of a Sui-Based Trade Protocol

Each supply chain asset or document becomes a first-class citizen on the chain.

🔩 Core Modules:
	•	ShipmentObject – includes items, weight, origin, unique ID
	•	CertificateModule – verifies document authenticity and issuer roles
	•	CustomsApprovalModule – customs agents can approve/reject shipment
	•	TransitEventModule – emits location updates (e.g., port scanned, loaded)

🔐 Example: Move Module for Certificate Verification

module trade::CertificateModule {
    struct Certificate has key {
        origin_country: vector<u8>,
        issuer: address,
        valid_until: u64,
    }

    public fun issue_certificate(issuer: &signer, country: vector<u8>) {
        let cert = Certificate {
            origin_country: country,
            issuer: signer::address_of(issuer),
            valid_until: 1690000000,
        };
        move_to(issuer, cert);
    }

    public fun validate(cert: &Certificate): bool {
        timestamp::now() < cert.valid_until
    }
}

This logic ensures only trusted authorities can issue and validate trade documents.

⸻

5. Interoperability: Real-Time Collaboration Across Borders

Sui’s modular identity and object logic allows cross-jurisdictional cooperation without central control:

Stakeholder	Action on Sui
Port Authority	Appends scan event to ShipmentObject
National Export Office	Issues digitally signed certificate
Freight Carrier	Updates shipment ETA and condition reports
Customs Agent	Verifies authenticity and compliance on-chain
Retailer	Retrieves verifiable product history + CO2 metadata

With APIs and dashboards built on Sui, even non-technical actors can participate securely in the protocol.

⸻

6. Fraud Prevention and Traceability

Global trade fraud results in billions of dollars in lost revenue annually. Sui combats this with:
	•	Digitally signed documents tied to identity via zkLogin
	•	Immutable chain of custody with timestamped events
	•	NFT-based goods tokens with linked certifications
	•	Smart triggers that prevent tampering or unauthorized transfers

Example: Anti-Counterfeit Proof

Each luxury product token (e.g., designer handbag) can:
	•	Link to origin cert + factory batch number
	•	Include QR code tied to on-chain object
	•	Prevent resale unless authenticated by verified account

⸻

7. Carbon Credits and ESG Integration

Enterprises are under pressure to prove sustainable supply chains. Sui can:
	•	Record carbon emissions per shipment or product unit
	•	Allow third parties (auditors, NGOs) to verify carbon scores
	•	Attach ESG reports to shipping NFTs
	•	Enable on-chain trading or claiming of carbon offsets

Example: A shipping container’s movement logs are used to estimate emissions, and a CarbonScoreObject is attached to the product token. Buyers can verify it before purchase.

⸻

8. Scaling Considerations for Global Networks

Sui’s parallelized execution and low latency make it enterprise-ready:

Scale Requirement	Sui Feature
100,000s of daily updates	Parallel object processing
100+ stakeholders per chain	Object-level permissioning
Real-time API needs	High-throughput RPCs + event subscriptions
Data retention	Object history + on-chain logs

Sui can scale as fast as the global logistics demand grows.

⸻

9. Challenges and Deployment Strategies

Challenge	Mitigation Strategy
Jurisdictional data constraints	Use region-specific modules + object tags
Limited blockchain literacy	Build user-friendly dApps + web UIs
Integration with legacy systems	Middleware + off-chain connectors
Security + compliance auditing	Emission logs + signed attestations

Start with one trade lane or product line, then gradually expand protocols and integrations.

⸻

10. Conclusion: Building the Future of Global Trade on Sui

Sui’s object-centric, programmable, and scalable architecture offers the foundation for a global, verifiable trade protocol.

With Sui, enterprises can:
	•	Reduce paperwork, delays, and fraud
	•	Automate multi-party workflows
	•	Achieve full traceability and ESG compliance
	•	Build shared data layers without central servers

In a world where trust, transparency, and speed define trade success, Sui is more than a blockchain—it’s the trust infrastructure for tomorrow’s supply chains.

Sui’s Role in Streamlining Global Trade and Supply Chain Infrastructure

Sui 在简化全球贸易和供应链基础设施中的作用

在 Sui 上构建令人兴奋——其以对象为中心的模型开辟了新的设计模式和更快的并行度. 但是 ⚠️ 新模型 = 新错误. 所有权错误、托管泄露或不慎的管理密钥可能会造成代价高昂的损失. 

本指南为您提供了分步的安全清单 📝 以及一个实用的市场示例，以说明如何避免最常见的陷阱. 

✅ 1) Sui 安全清单
 1. 🔑 最低权限
 • 不要依赖单一的全局 “管理员密钥”. 
 • 使用能力对象获得权限. 
 • 通过多重签名或链上治理保护关键管理权力. 
 2. ⚖️ 原子托管转账
 • 始终将资产托管在专用清单对象内. 
 • 使用可编程交易区块 (PTB) 进行原子交换 → 防止抢先运行和双重支出. 
 3. 🛡️ 验证所有输入
 • 在 “移动” 中，检查矢量长度、边界和约束. 
 • 验证反序列化并拒绝格式错误的对象. 
 • 切勿仅因为对象存在于链上就假设输入安全. 
 4. 🧪 积极测试和模糊
 • 写入负面测试：输入无效、并行更新、气体耗尽. 
 • 为意外交易流添加模糊功能. 
 • 在 CI 中实现自动化，尽早发现回归. 
 5. 🔐 密钥管理
 • 将管理员密钥存储在硬件钱包中. 
 • 使用多重签名进行治理操作. 
 • 团队成员离开时轮换密钥. 
 6. 👀 审计与激励措施
 • 对关键 Move 模块进行审计. 
 • 启动漏洞赏金计划以进行社区测试. 
 • 记住：外眼能捕捉到你错过的东西. 

🏪 2) 实践示例：安全的市场

以下是在市场 DApp 中应用清单的方法：
 • 安全地托管 NFT：
卖方将 NFT 移入清单对象. 未经卖方批准，市场合同不能提取资金. 
 • 正确处理特许权使用费：
在PTB内部计算特许权使用费，确保正确的费用分配（注意四舍五入！）. 
 • 再入境？不在这里：
Move 的资源模型通过设计可以防止复制/重入. 不过，还是要测试所有流程以确保没有逻辑漏洞. 

📚 来源和进一步阅读
 • Sui 文档：概念与交易
 • Sui 白皮书（以对象为中心的模型）
 • Mysten Labs TypeScript S
 • Move Book
 • 适用于 GitHub 存储库

✨ 要点：在 Sui 上，安全性与其说是 EVM 式的重入漏洞，不如说是所有权、权限和原子性. 如果您按照清单进行操作，则可以显著减少攻击面，同时确保用户资产的安全. 

Building on Sui is exciting — its object-centric model opens up new design patterns and faster parallelism. But ⚠️ new models = new mistakes. Ownership bugs, escrow leaks, or careless admin keys can cause costly losses.

This guide gives you a step-by-step security checklist 📝 plus a practical marketplace example to show how to avoid the most common pitfalls.

✅ 1) The Sui Security Checklist
	1.	🔑 Least Privilege
	•	Don’t rely on a single global “admin key.”
	•	Use capability objects for authority.
	•	Guard critical admin powers with multisig or on-chain governance.
	2.	⚖️ Atomic Escrow Transfers
	•	Always escrow assets inside dedicated Listing objects.
	•	Use Programmable Transaction Blocks (PTBs) for atomic swaps → prevents front-running and double spends.
	3.	🛡️ Validate All Inputs
	•	In Move, check vector lengths, bounds, and constraints.
	•	Validate deserialization and reject malformed objects.
	•	Never assume input safety just because the object exists on-chain.
	4.	🧪 Test & Fuzz Aggressively
	•	Write negative tests: invalid inputs, concurrent updates, gas exhaustion.
	•	Add fuzzing for unexpected transaction flows.
	•	Automate in CI to catch regressions early.
	5.	🔐 Key Management
	•	Store admin keys in hardware wallets.
	•	Use multisig for governance actions.
	•	Rotate keys when team members leave.
	6.	👀 Audits & Incentives
	•	Get critical Move modules audited.
	•	Launch a bug bounty program for community testing.
	•	Remember: external eyes catch what you miss.

🏪 2) Example in Practice: A Safe Marketplace

Here’s how to apply the checklist in a marketplace dApp:
	•	Escrow NFTs safely:
Seller moves the NFT into a Listing object. The marketplace contract cannot take funds without seller’s approval.
	•	Handle royalties correctly:
Compute royalties inside the PTB, ensuring correct fee splitting (watch out for rounding!).
	•	Reentrancy? Not here:
Move’s resource model prevents copying/reentrancy by design. Still, test all flows to ensure no logical loopholes.

📚 Sources & Further Reading
	•	Sui Docs: Concepts & Transactions
	•	Sui Whitepaper (object-centric model)
	•	Mysten Labs TypeScript SDK Docs
	•	Move Book
	•	Sui GitHub Repo

✨ Takeaway: On Sui, security is less about EVM-style reentrancy bugs and more about ownership, authority, and atomicity. If you follow the checklist, you’ll reduce your attack surface dramatically while keeping user assets safe.

🔒 Securing Your Sui App: A Practical Security Checklist

🔒 保护您的 Sui 应用程序：实用的安全清单

**首先安装 Sui CLI 和 Move 工具链，这样您就可以构建和发布代码，然后运行 sui 客户端活动地址来确认有效的密钥对，然后使用该模板创建一个新的 Move 包这样您就不会与文件夹结构作斗争，然后编辑单个模块来定义一个带有所有者字段和一些方法（例如初始化、更新和传输）的简单对象，这样您就可以使用 Sui 了快速的对象模型，接下来你使用 sui move 编译并修复编译器显示的所有错误，因为那是你的最快的反馈循环，然后使用 sui 客户端发布 publish--gas-budget <value>并从输出中获取软件包和模块 ID，这样你就可以调用函数，之后你调用初始<id>化入口函数来铸造一个对象并从交易效果中复制对象 ID，然后运行 sui 客户端对象来查看版本、所有者和字段，这样你就可以确认链写了你所期望的内容，如果你遇到 “汽油不足”，则会缩减燃气预算或请求更多测试 SUI 由于每次发布和通话都要花费汽油，如果你得到 “找不到模块”，你可能会使用错误的软件包 ID 或者忘记重建，如果你的传输因能力错误而失败，你很可能会在你打算拥有或忘记传递正确的参数形状时让对象共享，一旦基础知识奏效，你就可以在 shell 或 JavaScript 脚本中编写流程脚本，这样一个命令就可以构建、发布、铸造、更新和传输，这样可以节省时间并防止拼写错误，最后你将这个最小的示例推送到存储库中，这样队友就可以在几分钟内克隆并运行相同的步骤；通过将客体视为思维单位而不是单一的全球合约，你将你的编码方式与 Sui 存储状态的方式保持一致，这样可以保持你的思维模型干净，防止你在其他链上可能遇到的难以调试的重入或全局状态竞争，而且由于 Sui 对自有对象交易进行并行处理，你在迭代时还能看到快速确认，这使得入门过程变得更好. **

**You start by installing the Sui CLI and the Move toolchain so you can build and publish code, then you run sui client active-address to confirm a working keypair and hit the faucet to get test SUI, after which you create a fresh Move package with the template so you don’t fight folder structure, then you edit a single module to define a simple object with an owner field and a few methods like init, update, and transfer so you can exercise Sui’s object model quickly, next you compile with sui move build and fix any errors the compiler shows because that is your fastest feedback loop, then you publish with sui client publish --gas-budget <value> and grab the package and module IDs from the output so you can call functions, after that you call your init entry function to mint an object and copy the object ID from the transaction effects, then you run sui client object <id> to see version, owner and fields so you confirm the chain wrote what you expect, if you run into “insufficient gas” you shrink the gas budget or request more test SUI since every publish and call costs gas, if you get “module not found” you probably used the wrong package ID or forgot to rebuild, if your transfer fails with a capability error you likely made the object shared when you meant owned or you forgot to pass the correct argument shape, once the basics work you script the flow in a shell or JavaScript script so one command builds, publishes, mints, updates and transfers, which saves time and prevents typos, and finally you push this minimal example to a repo so teammates can clone and run the same steps in minutes; by treating the object as the unit of thinking rather than a single global contract you align how you code with how Sui stores state, which keeps your mental model clean and prevents hard-to-debug reentrancy or global-state races that you might meet on other chains, and because Sui parallelizes owned-object transactions you also see fast confirmation while you iterate which makes onboarding much nicer.**

From clean install to your first on-chain object without getting stuck

从全新安装到您的第一个链上对象而不会卡住

答：Move 的线性类型系统在编译时确保资源安全，防止双重支出、重入式错误或资产丢失. 通过将令牌、位置和权限建模为资源（结构<T>有密钥，store>），开发人员确保它们不能被复制或隐式丢弃. 除了防止盗窃外，您还可以将特定域的不变量（例如，“抵押品必须始终超过债务”）直接编码到类型安全的抽象中. 这使得许多运行时检查变得不必要——将执法转移到语言本身. 

A: Move’s linear type system enforces resource safety at compile time, preventing double-spending, reentrancy-style bugs, or lost assets. By modeling tokens, positions, and rights as resources (struct<T> has key, store>), developers ensure they cannot be duplicated or implicitly discarded. Beyond preventing theft, you can encode domain-specific invariants (e.g., “collateral must always exceed debt”) directly into type-safe abstractions. This makes many runtime checks unnecessary — shifting enforcement into the language itself.

How can Move’s type system improve security in financial smart contracts?

Move的类型系统如何提高金融智能合约的安全性？



1. 简介：企业数据共享困境

当今的企业比以往任何时候都更加互联，但组织之间安全共享数据仍然是最艰巨的挑战之一. 无论是供应链、保险网络还是金融联盟，公司都在努力应对以下问题：
 • 缺乏数据互操作性
 • 害怕数据滥用或泄露
 • 冗余审计和合规开销
 • 孤立和过时的信息管道

区块链，尤其是Sui，通过支持可验证、模块化和许可的数据交换，提供了一条前进的道路，其中包含全面的可追溯性和逻辑执行. 



2. 为什么选择 Sui 进行跨企业数据共享？

Sui 因其以对象为中心的架构、可扩展的设计以及对安全身份验证的支持而脱颖而出. 

🔍 Sui 的独特优势：

功能与数据共享的相关性
基于对象的数据模型每个数据包都有唯一的身份、生命周期和所有者
通过 Move Control 进行访问控制，谁可以读取、写入或修改共享数据
zkLogin for Enterprise ID 使用现有云凭据进行安全身份验证
不可变的审计日志共享或访问数据的完全可追溯性
模块化合约逻辑定制数据权限、架构和触发器




3.现实世界用例：制造与物流

让我们研究一下多家制造商和物流提供商需要在不损害隐私或控制的情况下共享运输状态、生产质量数据和库存水平的场景. 

传统问题：
 • 跨系统（例如 SAP、Oracle）的数据孤岛和延迟
 • 对数据准确性不信任
 • 手动对账效率低下

支持 Sui 的解决方案：
 • 每批货件都会成为具有动态状态的 Sui 对象
 • 供应商、物流和零售商拥有限定权限
 • 活动在每个阶段都会发布：包装、运输、交付
 • 所有各方通过链上查询或链下API验证状态

✅ 结果：实时可见性与完整审计记录，减少争议和交付错误. 



4. 架构：在 Sui 上构建跨企业协议

🔧 链上：
 • DataObject：封装共享信息（例如，货件编号、温度日志、证书）
 • AccessControlModule：管理角色和权限（谁可以写入、查看或转让所有权）
 • 审计模块：记录关键事件、状态更改或元数据更新

🔒 移动片段示例：

模块物流:: AccessControl {
 struct 权限有密钥 {
 data_id: ID，
 查看者：地址，
 can_edit：布尔，
 }

 public fun grant_view_permission（数据_ID：ID，查看者：地址）{
 move_to (&viewer，权限 {data_id，查看器，can_edit: false});
 }

 公共趣味更新数据（数据：&mut 共享数据，查看者：&Permission）{
 断言！（viewer.can_edit，“查看者缺乏写入权限”）；
 data.status = “已更新”;
 }
}




5. 数据隐私和零知识身份

并非所有人都应该看到所有数据. Sui 通过以下方式实现选择性数据泄露：
 • zkLogin 无需透露用户身份即可进行身份验证
 • 加密存储在链上的对象字段
 • GDPR 敏感数据的链下存储指针
 • 使用访问令牌或基于 NFT 的凭据授予选择性权限

这确保了企业可以安全地协作，同时保持隐私和对敏感数据的控制. 



6. 共享协议的治理模型

当多个组织共同管理协议时，必须定义：

Sui 的纵横选项
访问管理基于角色的访问权限（管理员、读者、编辑）
合同升级多重签名批准或基于 DAO 的投票
争议解决链上仲裁模块或暂停逻辑
管辖权规则具有法律背景的区域模块

Move 允许您将这些治理规则编码为模块化合约，从而减少歧义并以编程方式强制合规性. 



7. 案例研究：保险联盟共享索赔数据

场景：三家保险公司组成一个财团，通过共享索赔数据来减少欺诈行为. 

问题：
 • 跨公司重复索赔
 • 手动对账需要数周时间
 • 数据交换的法律障碍

基于 Sui 的解决方案：
 • 提交时创建的共享 “ClaimObject”
 • AccessControlModule 向合作伙伴保险公司授予有限的读/写权限
 • 链上跟踪事件和状态变化（例如，已批准、已标记）
 • 仅共享匿名索赔数据（例如，汽车损坏 + 时间戳）

成果：
 • 重复索赔下降了35％
 • 合作伙伴即时验证
 • 完全可审计的索赔审查流程



8. 跨链和链下集成

Sui 数据共享协议可以与以下内容互操作：
 • 使用 API、预言机和安全数据桥的链下系统
 • 通过 Sui 不断演变的互操作性框架的其他链（例如 LayerZero、Wormhole）

例如，能源网可以在 Sui 和 Polygon 之间共享链上碳信用额度，同时在 Sui 的存储中保留审计日志. 



9. 挑战和缓解策略

基于挑战套装的解决方案
数据传输的法律限制使用 zkLogin + 司法管辖区感知模块
合作伙伴的技术成熟度各不相同构建 API 封装和仪表板以实现低代码访问
共享架构的版本控制使用对象版本控制和可升级合同
需要链下验证将预言机与链上事件证明相结合

Sui 让企业能够灵活地围绕现实世界的限制进行设计，而不会影响安全性或控制力. 



10. 结论：Sui 是企业协作的信任层

数据是新石油，但前提是共享、可信且可操作. 借助 Sui，企业可以：
 • 直接在智能合约中对协作逻辑进行编码
 • 控制谁查看和编辑敏感数据
 • 自动跟踪、审计和执行协议规则
 • 构建可扩展、安全且尊重隐私的数据管道

随着越来越多的行业需要最小化信任的可编程数据交换，Sui 为构建共享的、防篡改的生态系统提供了理想的基础设施. 

⸻

1. Introduction: The Enterprise Data Sharing Dilemma

Enterprises today are more interconnected than ever, yet securely sharing data between organizations remains one of the toughest challenges. Whether it’s supply chains, insurance networks, or financial consortia, companies struggle with:
	•	Lack of data interoperability
	•	Fear of data misuse or breaches
	•	Redundant audits and compliance overhead
	•	Siloed and outdated information pipelines

Blockchain, especially Sui, offers a path forward by enabling verifiable, modular, and permissioned data exchange—with full traceability and logic enforcement baked in.

⸻

2. Why Sui for Cross-Enterprise Data Sharing?

Sui stands out due to its object-centric architecture, scalable design, and support for secure identity verification.

🔍 Sui’s Unique Advantages:

Feature	Relevance to Data Sharing
Object-based data model	Each data packet has a unique identity, lifecycle, and owner
Access control via Move	Control who can read, write, or modify shared data
zkLogin for enterprise ID	Authenticate with existing cloud credentials securely
Immutable audit logs	Full traceability of who shared or accessed data
Modular contract logic	Tailor data permissions, schemas, and triggers


⸻

3. Real-World Use Case: Manufacturing & Logistics

Let’s examine a scenario where multiple manufacturers and logistics providers need to share shipping status, production quality data, and inventory levels—without compromising privacy or control.

Traditional Problems:
	•	Data silos and delays across systems (e.g., SAP, Oracle)
	•	Mistrust over data accuracy
	•	Inefficient manual reconciliations

Sui-Enabled Solution:
	•	Each shipment becomes a Sui object with a dynamic status
	•	Suppliers, logistics, and retailers have scoped permissions
	•	Events are emitted at every stage: packaged, shipped, delivered
	•	All parties verify states via on-chain queries or off-chain APIs

✅ Result: Real-time visibility with full audit trail, reducing disputes and delivery errors.

⸻

4. Architecture: Building a Cross-Enterprise Protocol on Sui

🔧 On-Chain:
	•	DataObject: encapsulates the shared information (e.g., shipment ID, temperature logs, certs)
	•	AccessControlModule: manages roles and permissions (who can write, view, or transfer ownership)
	•	AuditModule: logs key events, state changes, or metadata updates

🔒 Example Move Snippet:

module logistics::AccessControl {
    struct Permission has key {
        data_id: ID,
        viewer: address,
        can_edit: bool,
    }

    public fun grant_view_permission(data_id: ID, viewer: address) {
        move_to(&viewer, Permission { data_id, viewer, can_edit: false });
    }

    public fun update_data(data: &mut SharedData, viewer: &Permission) {
        assert!(viewer.can_edit, "Viewer lacks write permission");
        data.status = "Updated";
    }
}


⸻

5. Data Privacy and Zero-Knowledge Identity

Not all data should be visible to everyone. Sui enables selective data exposure through:
	•	zkLogin for authentication without revealing user identity
	•	Encryption of object fields stored on-chain
	•	Off-chain storage pointers for GDPR-sensitive data
	•	Selective permission grants using access tokens or NFT-based credentials

This ensures enterprises can collaborate securely while retaining privacy and control over sensitive data.

⸻

6. Governance Models for Shared Protocols

When multiple organizations co-manage a protocol, it’s essential to define:

Aspect	Options with Sui
Access Governance	Role-based access (admin, reader, editor)
Contract Upgrades	Multi-sig approvals or DAO-based voting
Dispute Resolution	On-chain arbitration modules or pause logic
Jurisdiction Rules	Regional modules with legal context

Move allows you to encode these governance rules as modular contracts, reducing ambiguity and enforcing compliance programmatically.

⸻

7. Case Study: Insurance Consortium Sharing Claims Data

Scenario: Three insurers form a consortium to reduce fraud by sharing claims data.

Problem:
	•	Duplicate claims across companies
	•	Manual reconciliation taking weeks
	•	Legal hurdles for data exchange

Sui-Based Solution:
	•	Shared “ClaimObject” created upon submission
	•	AccessControlModule grants limited read/write access to partner insurers
	•	Events and state changes (e.g., approved, flagged) tracked on-chain
	•	Only anonymized claim data (e.g., car damage + timestamp) is shared

Outcomes:
	•	35% drop in duplicate claims
	•	Instant validation by partners
	•	Fully auditable claims review process

⸻

8. Cross-Chain and Off-Chain Integration

Sui data-sharing protocols can interoperate with:
	•	Off-chain systems using APIs, oracles, and secure data bridges
	•	Other chains via Sui’s evolving interoperability framework (e.g., LayerZero, Wormhole)

For example, an energy grid can share on-chain carbon credits across both Sui and Polygon, while preserving audit logs in Sui’s storage.

⸻

9. Challenges and Mitigation Strategies

Challenge	Sui-Based Solution
Legal restrictions on data transfer	Use zkLogin + jurisdiction-aware modules
Varying tech maturity of partners	Build API wrappers and dashboards for low-code access
Versioning of shared schemas	Use object version control and upgradeable contracts
Need for off-chain validation	Combine oracles with on-chain event proofs

Sui gives enterprises flexibility to design around real-world constraints, without compromising security or control.

⸻

10. Conclusion: Sui as the Trust Layer for Enterprise Collaboration

Data is the new oil—but only when shared, trusted, and actionable. With Sui, enterprises can:
	•	Encode collaboration logic directly in smart contracts
	•	Control who sees and edits sensitive data
	•	Track, audit, and enforce protocol rules automatically
	•	Build scalable, secure, and privacy-respecting data pipelines

As more industries demand trust-minimized, programmable data exchange, Sui provides the ideal infrastructure for building shared, tamper-proof ecosystems.

Building Cross-Enterprise Data Sharing Protocols on Sui

在 Sui 上构建跨企业数据共享协议

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

例如，我需要建造一个还是可以使用 Turbos Finance

What are the key features and functionalities of AMM bots within the Sui ecosystem? How do they improve upon traditional trading mechanisms, and what advantages do they offer to users engaging with DeFi protocols on the Sui network?

Do I need to build one or I can use Turbos Finance for example

AMM Bot in Sui Ecosystem

Sui 生态系统中的 AMM 机器人

# 👀 SEAL 已在 Sui 测试网上线 — 我认为 Web3 数据隐私即将改变

在 Web3 中，经常会听到诸如**“用户拥有自己的数据”**或**“通过设计去中心化”**之类的短语. 但是，仔细观察，许多应用程序仍然依赖集中式基础设施来处理敏感数据——使用 AWS 或 Google Cloud 等服务进行密钥管理. 这就引入了一个矛盾：表面上的去中心化，底层的集中化. 


但是，如果有一种方法可以在不放弃权力下放的情况下安全地管理机密呢？介绍 SEAL — 去中心化机密管理 (DSM)，现已在 Sui 测试网上线. SEAL 旨在修复 Web3 最大的虚伪之处之一：在秘密使用 AWS 的同时大声疾呼去中心化

![](https://ipfs-cdn.peeranha.io/QmcRWFsXzUBecBmZBzVPMdtSS9zqA4yJMysXhPdYhE3bWK)

# 你可能会问我：海豹突击队是什么？

SEAL 是一种协议，可让您安全、**分散地**管理敏感数据——专为 Web3 世界构建. 可以将其视为插入 dApp 的隐私优先访问控制层. 



您可以将 SEAL 视为一种可编程的数据锁. 你不只是手动锁定和解锁，而是使用Move on Sui**将策略直接写入智能合约**. 

假设你正在构建一个 DApp，其中：

-只有 NFT 持有者才能解锁高级教程
-或者，在泄露敏感文件之前，DAO 可能必须进行投票
-或者你想对元数据进行时间锁定并且只能在特定日期之后访问

海豹突击队使所有这些成为可能. 访问控制*在链上* 运行，完全自动化，无需管理员进行管理. 只是逻辑，直接融入区块链. 

海豹突击队使所有这些成为可能. 访问控制*在链上* 运行，完全自动化，无需管理员进行管理. 只是逻辑，直接融入区块链. 

另一个有趣的文章是SEAL如何处理**加密**. 它使用所谓的**阈值加密**，这意味着：没有一个节点可以解密数据. 需要一组服务器才能协同工作——有点像多重签名，但用于解锁机密. 这样可以分配信任，避免常见的单点故障问题. 

为了保证信息的真正私密性，SEAL 会加密和解密**客户端**的所有内容. 任何后端都看不到您的数据. 从字面上看，它会留在你的手中，放在你的设备上. 

而且 SEAL 不在乎你在哪里存储数据. 无论是 IPFS、Arweave、Walrus 还是其他平台，SEAL 都不会试图控制这部分. 它只关注**谁可以看到什么**，而不是*东西的存储位置*. 

>所以是的，它不仅仅是一个库或 API，它是 dApp 的**链上优先、访问控制、默认隐私层**. 


![](https://ipfs-cdn.peeranha.io/QmPTLrU3XXDG3zx92LXhh8GzdRgUG98rPb8ZkX42nUf77S)


**SEAL 填补了一个非常关键的空白**. 让我们再分解一下.  

---

如果你正在构建一个处理**任何形式的敏感数据**（封闭内容、用户文档、加密消息，甚至是锁定时间的 NFT 元数据）的 dApp，你也会遇到同样的问题：

➡️ 如何在不依赖集中服务的情况下安全地管理访问权限？

如果没有像海豹突击队这样的队伍，大多数队伍都会：

1. 使用 AWS KMS 或 Firebase 等集中式工具，这显然与去中心化背道而驰
2. 或者尝试自己修补半生不熟的加密逻辑，这些逻辑通常会变得脆弱且难以审计

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 实际上是如何运作的？
![](https://ipfs-cdn.peeranha.io/QmRsHK6qzzjcQsZcTdgMBiQdn4QZzSaBRSpM5ZdgXrH9gw)

我们已经介绍了**什么是 SEAL**以及**为什么 Web3 需要它**，让我们来看看它在幕后是如何构建的. 这部分是技术性更强的地方，但还是不错的. 一旦你看到所有部分是如何组合在一起的，建筑就会变得很优雅. 

总体而言，SEAL的工作原理是使用一种名为**基于身份的加密（IBE）**的技术，将**链上访问逻辑**与**链下密钥管理**相结合. 这允许开发人员将数据加密为*身份*，然后依靠智能合约来定义*允许谁*对其进行解密. 

## 步骤 1：智能合约中的访问规则（在 Sui 上）

一切都从智能合约开始. 当你使用 SEAL 时，你需要在你的 Move 合约中定义一个名为 seal_approve 的函数，你可以在这里写下解密条件. 

例如，以下是用 Move 编写的简单时间锁定规则：

```rust
entry fun seal_approve(id: vector<u8>, 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

当数据加密后，它看起来像这样：

```rust
Encrypt(mpk, identity, message)
```

-mpk = 主公钥（众所周知）
-身份 = 逻辑定义的收件人
-消息 = 实际数据

之后，如果有人想解密，密钥服务器会检查他们是否符合政策（通过链上的 seal_approve 调用）. 如果获得批准，它将返回该身份的派生私钥. 

```rust
Derive(msk, identity) → sk  
Decrypt(sk, encrypted_data)
```

然后，用户可以在本地解密内容. 

因此，无需提前知道*谁*将解密即可完成加密. 您只需定义*条件*，SEAL 稍后再计算其余部分. 它是动态的. 


##**第 3 步：密钥服务器 — 脱链，但未集中化**

你可能想知道：谁在拿着这些万能钥匙？

这就是 SEAL 的**密钥服务器**的用武之地. 可以把它看作是一个后端：

-持有主密钥 (msk)
-关注链上合约（比如你的 seal_approve 逻辑）
-仅在满足条件时才发出派生密钥

但是——这是关键——海豹突击队不只依赖*一台*密钥服务器. 你可以在**阈值模式**下运行它，在发放解密密钥之前，需要多个独立服务器达成一致. 

例如：五分之三的密钥服务器必须批准请求. 这避免了中心故障点，也允许在密钥管理层进行权力下放. 

更好的是，将来SEAL将支持**MPC（多方计算）**和**基于飞地的设置**（例如TEE），因此您可以在不影响可用性的情况下获得更强的保障. 

##**步骤 4：客户端解密**

将密钥返回给用户后，实际的解密将在用户的设备上进行**. 这意味着：

-服务器永远看不到你的数据
-后端从不存储解密的内容
-只有用户可以访问最后的消息

这是一个可靠的隐私模型. 即使有人破坏了存储层（IPFS、Arweave 等），如果不传递访问逻辑，他们仍然无法读取数据. 

以下是快速思维模型：

![](https://ipfs-cdn.peeranha.io/Qmcni3mRP85eLrfcny1ZgDdeQbe3rj9CdD2y6zHvzyZAS3)

这种结构使您可以轻松构建访问规则不是硬编码的去中心化应用程序，它们是动态的、可审计的，并且完全集成到您的链逻辑中. 

##**SEAL 背后的团队**

SEAL 由区块链安全社区的知名人物**Samczsun**领导. 他曾是Paradigm的研究合伙人，曾审计过多个生态系统并将其从重大漏洞中拯救出来. 现在，他全职致力于将 SEAL 建成 Web3 隐私基础设施的核心部分. 

凭借他的背景和信誉，SEAL 不仅仅是另一个实验工具，它是一次严肃的尝试，旨在使去中心化数据隐私既实用又可扩展. 

随着 SEAL 在 Sui 测试网上线，它为 Web3 应用程序如何管理机密带来了新的标准. 通过结合链上访问控制、阈值加密和客户端隐私，SEAL 为去中心化数据处理提供了更值得信赖的基础. 

无论你是在构建 dApp、DAO 还是去中心化游戏，SEAL 都提供了一个强大的工具包，可以在不影响去中心化的前提下执行访问控制和保护用户数据. 

如果 Web3 要向前发展，像 SEAL 这样的安全基础设施不是可选的——这是必不可少的

# 👀SEAL is Live on Sui Testnet – I Think Web3 Data Privacy Is About to Change

In the Web3, it’s common to hear phrases like **“users own their data”** or **“decentralized by design”**. But when you look closely, many applications still rely on centralized infrastructures to handle sensitive data — using services like AWS or Google Cloud for key management. This introduces a contradiction: decentralization on the surface, centralization underneath.


But what if there was a way to manage secrets securely, without giving up decentralization?Introducing SEAL – Decentralized Secrets Management (DSM), now live on the Sui Testnet. SEAL aims to fix one of Web3’s biggest hypocrisies: shouting decentralization while secretly using AWS

![](https://ipfs-cdn.peeranha.io/QmcRWFsXzUBecBmZBzVPMdtSS9zqA4yJMysXhPdYhE3bWK)

# You maybe ask me: What is SEAL?

SEAL is a protocol that lets you manage sensitive data securely and **decentrally** – built specifically for the Web3 world. Think of it as a privacy-first access control layer that plugs into your dApp.



You can think of SEAL as a kind of programmable lock for your data. You don’t just lock and unlock things manually — you **write policies directly into your smart contracts**, using Move on Sui.

Let’s say you’re building a dApp where:

- Only NFT holders can unlock a premium tutorial
- Or maybe a DAO has to vote before sensitive files are revealed
- Or you want metadata to be time-locked and only accessible after a specific date

SEAL makes all of that possible. The access control lives *onchain*, fully automated, no need for an admin to manage it. Just logic, baked right into the blockchain.

SEAL makes all of that possible. The access control lives *onchain*, fully automated, no need for an admin to manage it. Just logic, baked right into the blockchain.

Another interesting piece is how SEAL handles **encryption**. It uses something called **threshold encryption**, which means: no single node can decrypt the data. It takes a group of servers to work together — kinda like multi-sig, but for unlocking secrets. This distributes trust and avoids the usual single-point-of-failure problem.

And to keep things truly private, SEAL encrypts and decrypts everything **on the client side**. Your data is never visible to any backend. It stays in your hands — literally — on your device.

and SEAL doesn’t care where you store your data. Whether it’s IPFS, Arweave, Walrus, or some other platform, SEAL doesn’t try to control that part. It just focuses on **who’s allowed to see what**, not *where* things are stored.

> So yeah, it’s not just a library or API — it’s an **onchain-first, access-controlled, privacy-by-default layer** for your dApp.


![](https://ipfs-cdn.peeranha.io/QmPTLrU3XXDG3zx92LXhh8GzdRgUG98rPb8ZkX42nUf77S)


**SEAL fills a pretty critical gap**. Let’s break that down a bit more. 

---

If you’re building a dApp that deals with **any form of sensitive data** — gated content, user documents, encrypted messages, even time-locked NFT metadata — you’ll run into the same problem:

➡️ How do you manage access securely, without relying on a centralized service?

Without something like SEAL, most teams either:

1. Use centralized tools like AWS KMS or Firebase, which clearly goes against decentralization
2. Or try to patch together half-baked encryption logic themselves, which usually ends up brittle and hard to audit

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

Neither of those scales well. Especially not when you’re trying to build trustless apps across multiple chains or communities.

**SEAL makes that entire process modular and programmable.**

You define your access rules in Move smart contracts, and SEAL handles the rest — key generation, decryption approvals, and access enforcement — all without anyone manually issuing keys or running backend checks.

Even better, those rules are **auditable and immutable** — once they’re onchain, they follow the contract, not a human admin.

So instead of asking “who should manage access to this data?” you just ask:

> “What logic should define access?”
> 

> …and let the chain handle it. Clean and scalable.

That’s what makes SEAL relevant for more than just “security tools” — it’s a base layer for **any dApp that cares about privacy, compliance, or dynamic access logic.**

It’s a small shift — but it changes a lot about how we think of data in Web3. Instead of encrypting *after* deployment, or relying on external services, **you start with privacy built-in — and access handled entirely by smart contract logic.**

And that’s exactly what Web3 needs right now.

---
# How Does SEAL Actually Work?
![](https://ipfs-cdn.peeranha.io/QmRsHK6qzzjcQsZcTdgMBiQdn4QZzSaBRSpM5ZdgXrH9gw)

We’ve covered **what SEAL is** and **why Web3 needs it**, let’s take a look at how it’s actually built under the hood. This part is where things get more technical — but in a good way. The architecture is elegant once you see how all the pieces fit together.

At a high level, SEAL works by combining **onchain access logic** with **offchain key management**, using a technique called **Identity-Based Encryption (IBE)**. This allows devs to encrypt data *to an identity*, and then rely on smart contracts to define *who is allowed* to decrypt it.

## Step 1: Access Rules in Smart Contracts (on Sui)

Everything starts with the smart contract. When you’re using SEAL, you define a function called seal_approve in your Move contract — this is where you write your conditions for decryption.

For example, here’s a simple time-lock rule written in Move:

```rust
entry fun seal_approve(id: vector<u8>, 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);
}
```

Once deployed, this contract acts as the gatekeeper. Whenever someone wants to decrypt data, their request will get checked against this logic. If it passes, the key gets released. If not, they’re blocked. No one has to intervene.

## **Step 2: Identity-Based Encryption (IBE)**

Here’s where the magic happens.

Instead of encrypting data for a specific wallet address (like with PGP or RSA), SEAL uses **identity strings** — meaning you encrypt to something like:

- 0xwalletaddress
- dao_voted:proposal_xyz
- PkgId_2025_05_01 (a timestamp-based rule)
- or even game_user_nft_holder

When the data is encrypted, it looks like this:

```rust
Encrypt(mpk, identity, message)
```

- mpk = master public key (known to everyone)
- identity = the logic-defined recipient
- message = the actual data

Later, if someone wants to decrypt, the key server checks if they match the policy (via the seal_approve call onchain). If it’s approved, it returns a derived private key for that identity.

```rust
Derive(msk, identity) → sk  
Decrypt(sk, encrypted_data)
```

The user can then decrypt the content locally.

So encryption is done without needing to know *who* will decrypt ahead of time. You just define the *conditions*, and SEAL figures out the rest later. It’s dynamic.


## **Step 3: The Key Server – Offchain, But Not Centralized**

You might wonder: who’s holding these master keys?

This is where SEAL’s **Key Server** comes in. Think of it as a backend that:

- Holds the master secret key (msk)
- Watches onchain contracts (like your seal_approve logic)
- Only issues derived keys if the conditions are satisfied

But — and this is key — SEAL doesn’t rely on just *one* key server. You can run it in **threshold mode**, where multiple independent servers need to agree before a decryption key is issued.

For example: 3-of-5 key servers must approve the request. This avoids central points of failure and allows decentralization at the key management layer too.

Even better, in the future SEAL will support **MPC (multi-party computation)** and **enclave-based setups** (like TEE) — so you can get even stronger guarantees without compromising usability.

## **Step 4: Client-Side Decryption**

Once the key is returned to the user, the actual decryption happens **on their device**. This means:

- The server never sees your data
- The backend never stores decrypted content
- Only the user can access the final message

It’s a solid privacy model. Even if someone compromises the storage layer (IPFS, Arweave, etc.), they still can’t read the data without passing the access logic.

Here’s the quick mental model:

![](https://ipfs-cdn.peeranha.io/Qmcni3mRP85eLrfcny1ZgDdeQbe3rj9CdD2y6zHvzyZAS3)

This structure makes it easy to build dApps where access rules aren’t hardcoded — they’re dynamic, auditable, and fully integrated into your chain logic.

## **The Team Behind SEAL**

SEAL is led by **Samczsun**, a well-known figure in the blockchain security community. Formerly a Research Partner at Paradigm, he has audited and saved multiple ecosystems from major exploits. Now, he’s focused full-time on building SEAL into a core piece of Web3’s privacy infrastructure.

With his background and credibility, SEAL is not just another experimental tool — it’s a serious attempt at making decentralized data privacy both practical and scalable.

As SEAL goes live on the Sui Testnet, it brings a new standard for how Web3 applications can manage secrets. By combining onchain access control, threshold encryption, and client-side privacy, SEAL offers a more trustworthy foundation for decentralized data handling.

Whether you’re building dApps, DAOs, or decentralized games — SEAL provides a powerful toolkit to enforce access control and protect user data without compromising on decentralization.

If Web3 is going to move forward, secure infrastructure like SEAL is not optional — it’s essential

👀 SEAL- I Think Web3 Data Privacy Is About to Change

👀 SEAL-我认为 Web3 数据隐私即将改变

*我想理解 Sui Network 的这一方面，因为我要么构建、调试，要么部署一些涉及这个领域的东西. 我想详细解释这个机制或功能的工作原理，以及相关的 CLI 用法、移动代码结构或架构概念. 我的目标是获得足够的清晰度，将这些知识应用到一个真实的项目中——无论是自定义智能合约、NFT系统、钱包集成还是DeFi工具. 与 EVM 链相比，Sui Network 具有独特的功能，因此我对它的与众不同之处以及它如何影响开发最佳实践特别感兴趣. 有示例代码、命令行示例或典型错误需要注意会有所帮助，尤其是在使用 Sui CLI、SDK 或在本地网络/测试网上部署时. 归根结底，我希望避免常见错误，遵循最佳的安全原则，并确保我正在开发的功能在现实条件下表现出预期. *

*I'm trying to understand this aspect of the Sui Network because I'm either building, debugging, or deploying something that touches this area. I want a detailed explanation of how this mechanism or feature works, along with relevant CLI usage, Move code structure, or architectural concepts. My goal is to gain enough clarity to apply this knowledge in a real project—whether that's a custom smart contract, an NFT system, a wallet integration, or a DeFi tool. The Sui Network has unique features compared to EVM chains, so I'm particularly interested in what sets it apart and how that affects development best practices. It would help to have sample code, command line examples, or typical errors to watch for, especially when using the Sui CLI, SDK, or deploying on localnet/testnet. Ultimately, I want to avoid common mistakes, follow the best security principles, and ensure that the functionality I’m working on behaves as expected under realistic conditions.*

How do I merge two coin object in Move?

如何在 Move 中合并两个硬币对象？

我想理解 Sui Network 的这一方面，因为我要么构建、调试，要么部署涉及这个领域的东西. 我想详细解释这个机制或功能的工作原理，以及相关的 CLI 用法、移动代码结构或架构概念. 我的目标是获得足够的清晰度，将这些知识应用到一个真实的项目中——无论是自定义智能合约、NFT系统、钱包集成还是DeFi工具. 与 EVM 链相比，Sui Network 具有独特的功能，因此我对它的与众不同之处以及它如何影响开发最佳实践特别感兴趣. 有示例代码、命令行示例或典型错误需要注意会有所帮助，尤其是在使用 Sui CLI、SDK 或在本地网络/测试网上部署时. 归根结底，我希望避免常见错误，遵循最佳的安全原则，并确保我正在开发的功能在现实条件下表现出预期. 

I'm trying to understand this aspect of the Sui Network because I'm either building, debugging, or deploying something that touches this area. I want a detailed explanation of how this mechanism or feature works, along with relevant CLI usage, Move code structure, or architectural concepts. My goal is to gain enough clarity to apply this knowledge in a real project—whether that's a custom smart contract, an NFT system, a wallet integration, or a DeFi tool. The Sui Network has unique features compared to EVM chains, so I'm particularly interested in what sets it apart and how that affects development best practices. It would help to have sample code, command line examples, or typical errors to watch for, especially when using the Sui CLI, SDK, or deploying on localnet/testnet. Ultimately, I want to avoid common mistakes, follow the best security principles, and ensure that the functionality I’m working on behaves as expected under realistic conditions.

未回答

分享您的见解和专业知识。

帖子

赚取你的 1000 Sui 份额