27 篇博文 含有标签「Sui」

当一家纳斯达克上市公司不再将加密货币视为被动储备资产，而是开始围绕其构建一整套收益生成型业务时，会发生什么？Sui Group Holdings (SUIG) 正在实时回答这个问题，并勾勒出一条可能在 2026 年及以后重新定义企业财库管理数字资产方式的路线。

虽然大多数数字资产财库公司 (DATs) 只是简单地买入并持有加密货币以期待价格上涨，但 Sui Group 正在推出原生稳定币，将资本部署到 DeFi 协议中，并设计经常性收入流——而这一切都是在持有 1.08 亿枚价值约 1.6 亿美元的 SUI 代币的基础上实现的。该公司的雄心？成为下一代企业加密财库的蓝图。

DAT 领域正变得拥挤且充满竞争​

自 MicroStrategy 在 2020 年开创该策略以来，企业加密财库模式呈爆发式增长。如今，Strategy（前身为 MicroStrategy）持有超过 687,000 枚 BTC，已有 200 多家美国公司宣布计划采用数字资产财库策略。截至 2025 年底，公开上市的 DATCO（数字资产财库公司）共持有超过 1,000 亿美元的数字资产。

但简单的“买入并持有”模式正出现裂痕。随着加密 ETF 竞争的加剧，数字资产财库公司在 2026 年面临着迫在眉睫的洗牌。随着比特币和以太坊现货 ETF 现在提供受监管的风险敞口——在某些情况下还提供质押收益——投资者越来越倾向于将 ETF 视为比 DAT 公司股票更简单、更安全的替代方案。

行业分析警告称：“完全依赖持有数字资产（尤其是山寨币）的公司可能难以在下一次低迷中幸存。”没有可持续收益或流动性策略的公司在市场波动期间面临被迫出售的风险。

这正是 Sui Group 正在解决的痛点。该公司并没有在简单的风险敞口上与 ETF 竞争，而是建立了一种能产生经常性收益的运营模式——这是被动型 ETF 无法复制的。

从财库公司向收益生成型运营业务转型​

Sui Group 的转型始于 2025 年 10 月，当时它从专业金融公司 Mill City Ventures 更名为由基金会支持、以 SUI 代币为核心的数字资产财库。但该公司的首席投资官 (CIO) Steven Mackintosh 并不满足于被动持有。

公司表示：“我们现在的首要任务很明确：积累 SUI 并构建能为股东产生经常性收益的基础设施。”该公司已经将其每股 SUI 指标从 1.14 提高到 1.34，展示了增值性的资本管理。

该战略建立在三大支柱之上：

1. 大规模 SUI 积累：Sui Group 目前持有约 1.08 亿枚 SUI 代币，占流通供应量的近 3%。近期目标是将持股比例提高到 5%。在 SUI 交易价格接近 4.20 美元时完成的一项 PIPE 交易中，其财库估值约为 4 亿至 4.5 亿美元。

2. 战略资本管理：公司筹集了约 4.5 亿美元，但有意识地保留了约 6,000 万美元以管理市场风险，帮助避免在市场波动期间被迫出售代币。Sui Group 最近回购了其 8.8% 的股份，并保持约 2,200 万美元的现金储备。

3. 积极的 DeFi 部署：除了质押外，Sui Group 正在 Sui 原生 DeFi 协议中部署资本，在赚取收益的同时深化生态系统流动性。

SuiUSDE：改变游戏规则的带息稳定币​

Sui Group 战略的核心是 SuiUSDE——这是一款与 Sui 基金会和 Ethena 合作构建的原生带息稳定币，预计将于 2026 年 2 月上线。

这不仅仅是又一个稳定币的发布。Sui Group 是首批在非以太坊网络上使用 Ethena 技术进行白标定制的公司之一，这使得 Sui 成为第一个托管由 Ethena 基础设施支持的、能产生收入的原生稳定资产的非 EVM 链。

其工作原理如下：

SuiUSDE 将使用 Ethena 现有产品（USDe 和 USDtb）以及德尔塔中性 (delta-neutral) 的 SUI 仓位进行抵押。支持资产由数字资产与相应的空头期货合约组成，创建一种在产生收益的同时保持挂钩的合成美元。

收入模式是其变革性的关键。根据该结构：

• 90% 的费用 由 SuiUSDE 产生并流向 Sui Group Holdings 和 Sui 基金会
• 收入用于在公开市场回购 SUI 或重新部署到 Sui 原生 DeFi 中
• 该稳定币将集成至 DeepBook、Bluefin、Navi 以及像 Cetus 这样的 DEX 中
• SuiUSDE 将在整个生态系统中充当抵押品

这创造了一个飞轮：SuiUSDE 产生费用 → 费用回购 SUI → SUI 价格上涨使 Sui Group 财库受益 → 财库价值增加支持更多的资本部署。

USDi：贝莱德支持的机构级稳定币​

与 SuiUSDE 并行，Sui Group 正在推出 USDi——这是一款由贝莱德 (BlackRock) 的美元机构数字流动性基金 (BUIDL) 支持的稳定币，BUIDL 是一只代币化货币市场基金。

虽然 USDi 不像 SuiUSDE 那样为持有者产生收益，但它服务于不同的目的：提供由传统金融领域最受信赖的机构支持的机构级稳定性。这种双稳定币策略为 Sui 生态系统用户提供了在收益生成和最大稳定性之间的选择。

Ethena 和贝莱德的参与标志着机构对 Sui 基础设施和 Sui Group 执行能力的信心。

Brian Quintenz 加入董事会：大规模的监管公信力​

2026 年 1 月 5 日，Sui Group 宣布了一项董事会任命，发出了一个明确的信号：前 CFTC 委员兼 a16z crypto 前政策全球负责人 Brian Quintenz 加入董事会。

Quintenz 的资历非常出众：

• 由奥巴马和特朗普两位总统提名至 CFTC
• 获美国参议院全票通过
• 在制定衍生品、金融科技和数字资产监管框架方面发挥了核心作用
• 领导了比特币期货市场的早期监管
• 为加密货币领域最具影响力的投资平台之一负责政策战略

他加入 Sui Group 的道路并非一帆风顺。由于 Winklevoss 兄弟对潜在利益冲突的担忧以及对 a16z 游说工作的审查，白宫于 2025 年 9 月撤回了对 Quintenz 担任 CFTC 主席的提名。

对于 Sui Group 而言，Quintenz 的任命在关键时刻增强了监管公信力。随着 DAT 公司面临日益严格的审查——包括如果加密货币持有量超过资产的 40% 可能被归类为未注册投资公司的风险——董事会中拥有一位前监管者，可以为应对合规环境提供战略指导。

随着 Quintenz 的任命，Sui Group 的五人董事会现在包括三名符合纳斯达克规则的独立董事。

关键指标：每股 SUI 和 TNAV​

随着 DAT 公司的成熟，投资者开始要求除了简单的“持有多少加密货币”之外更复杂的指标。

Sui Group 正在顺应这一演变，重点关注：

• 每股 SUI：从 1.14 增长到 1.34，展示了增值的资本管理
• 财库资产净值 (TNAV)：追踪代币持有量与市值之间的关系
• 发行效率：衡量融资是对现有股东增值还是稀释

这些指标至关重要，因为 DAT 模型面临结构性挑战。如果一家公司的交易价格高于其持有的加密货币价值，通过发行新股购买更多加密货币是增值的。但如果交易价格低于其持有的加密货币价值，情况就会反转——管理层可能会损害股东价值。

Sui Group 的方法——产生经常性收益而非仅仅依靠资产增值——提供了一个潜在的解决方案。即使 SUI 价格下跌，稳定币费用和 DeFi 收益也能创造纯持有策略无法企及的基础收入。

MSCI 的决定及机构影响​

对于 DAT 公司来说，一项重大进展是 MSCI 决定不将数字资产财库公司排除在其全球股票指数之外，尽管此前曾提议移除加密货币资产占比超过 50% 的公司。

这一决定维持了追踪 MSCI 基准的被动型基金的流动性，这些基金管理着 18.3 万亿美元的资产。由于 DAT 公司总共持有 1,373 亿美元的数字资产，继续将其纳入指数保留了机构需求的重要来源。

MSCI 将变更推迟至 2026 年 2 月的审查，这让像 Sui Group 这样的公司有时间展示其收益生成模型，证明其与简单的持有工具有所区别。

这对企业加密财库意味着什么​

Sui Group 的战略为企业加密财库的下一次进化提供了模板：

1. 超越“买入并持有”：简单的累积模型面临来自 ETF 的生存竞争。公司必须展示运营专长，而不仅仅是信念。

2. 收益生成是必选项：无论是通过质押、借贷、DeFi 部署还是原生稳定币发行，财库必须产生经常性收入，以证明其相对于 ETF 替代方案的溢价是合理的。

3. 生态系统协同至关重要：Sui Group 与 Sui 基金会的官方关系创造了纯金融持有者无法复制的优势。基金会合作伙伴关系提供技术支持、生态整合和战略协同。

4. 监管定位具有战略意义：像 Quintenz 这样的董事会任命信号表明，成功的 DAT 公司将在合规和监管关系上投入巨资。

5. 指标演变：随着投资者变得更加成熟，每股 SUI、TNAV 和发行效率将日益取代简单的市值对比。

展望未来：100 亿美元 TVL 目标​

专家预计，收益型稳定币的加入可能在 2026 年前推动 Sui 的总锁仓价值 (TVL) 突破 100 亿美元，显著提升其在全球 DeFi 中的排名。截至目前，Sui 的 TVL 约为 15-20 亿美元，这意味着 SuiUSDE 及相关计划需要催生 5-6 倍的增长。

Sui Group 能否成功将取决于执行力：SuiUSDE 能否获得大规模采用？“费用回购”飞轮能否产生实质性收入？公司能否凭借新的治理结构应对监管复杂性？

可以肯定的是，该公司已经超越了简单的 DAT 策略。在一个 ETF 威胁要将加密货币敞口商品化的市场中，Sui Group 押注于主动收益生成、生态系统整合和卓越运营能够获得溢价估值。

对于在场边观察的企业司库来说，信息很明确：持有加密货币已不再足够。下一代数字资产公司将是建设者，而不仅仅是购买者。

在 Sui 网络上构建项目？BlockEden.xyz 为 Sui 以及其他 25 多个区块链网络提供企业级 RPC 服务和 API。探索我们的 Sui API 服务，在专为机构级可靠性设计的架构上进行开发。

2026 年 1 月 14 日，协调世界时 (UTC) 下午 2:52，Sui 网络停止产块。在近 6 个小时的时间里，价值约 100 亿美元的链上资产被冻结——交易无法结算，DeFi 仓位无法调整，游戏应用陷入瘫痪。虽然没有资金损失，但这一事件重新引发了一场关键辩论：高吞吐量区块链能否提供机构化采用所要求的可靠性？

这并不是 Sui 的第一次失误。继 2024 年 11 月验证者崩溃和 2025 年 12 月导致性能下降的 DDoS 攻击之后，这次最新的共识漏洞标志着该网络在短短一年多时间内发生的第三次重大事故。与此同时，曾因停机而声名狼藉的 Solana 在 2025 年 12 月经受住了 6 Tbps 的 DDoS 攻击，实现了零停机。这种对比非常鲜明，它标志着我们评估区块链基础设施的方式发生了根本性转变：速度已不再足够。

共识失败剖析​

技术复盘显示，一个边缘案例凸显了分布式共识的复杂性。特定的垃圾回收条件与优化路径相结合，导致验证者计算出了不同的检查点 (checkpoint) 候选者。当超过三分之一的质押权重签署了相互冲突的检查点摘要时，认证完全陷入停滞。

以下是事件发生的先后顺序：

1. 检测 (下午 2:52 UTC)：区块生产和检查点创建停止。Sui 团队立即标记了该问题。

2. 诊断 (约 9 小时的分析)：工程师们发现，验证者在处理某些冲突交易时得出了不同的结论——这是共识提交处理方式中的一个细微漏洞。

3. 修复开发 (11:37 PST)：团队对提交逻辑实施了补丁。

4. 部署 (12:44 PST)：在 Mysten Labs 验证者成功进行灰度部署后，更广泛的验证者集合进行了升级。

5. 恢复 (下午 8:44 UTC)：服务恢复，距检测到问题约 5 小时 52 分钟。

恢复过程要求验证者删除错误的共识数据，应用修复程序，并从分歧点开始重放链。它起作用了——但在毫秒必争的金融市场中，6 小时是一段极其漫长的时间。

可靠性大考：从 TPS 战争到正常运行时间战争​

多年来，区块链竞争一直围绕着单一指标：每秒交易量 (TPS)。Solana 承诺 65,000 TPS。Sui 声称在测试中达到 297,000 TPS。吞吐量的军备竞赛主导了市场叙事和投资者的注意力。

那个时代正在结束。正如一位分析师所言：“2025 年之后，公链竞争的核心指标将从‘谁更快’转向‘谁更稳定、谁更可预测’。”

原因在于机构资本。当摩根资产管理 (JPMorgan Asset Management) 在以太坊上推出价值 1 亿美元的代币化货币市场基金时，他们优化的不是速度，而是确定性。当贝莱德 (BlackRock)、富达 (Fidelity) 和灰度 (Grayscale) 在比特币和以太坊 ETF 中投入数百亿美元，积累了 310 亿美元的净流入并处理了 8800 亿美元的交易量时，他们选择了经过实战检验、具有可靠性的链，而非理论上的吞吐量优势。

真正的区块链性能现在由三个要素共同定义：吞吐量 (容量)、出块时间 (包含速度) 和最终性 (不可逆转性)。最快的链是那些能平衡这三者的链，但最有价值的链是那些在受到攻击、处于负载之下以及在任何测试网都无法预见的边缘条件下，仍能持续做到这一点的链。

Solana 的可靠性救赎​

与 Solana 的对比具有启发性。在 2021 年至 2022 年间，Solana 遭受了 7 次重大停机，其中最长的一次发生在代币发行期间，由于机器人活动导致验证者过载，停机持续了 17 小时。该网络曾成为笑柄——“Solana 又挂了”是加密货币推特圈子里经久不衰的笑话。

但 Solana 的工程团队通过结构性变革做出了回应。他们实施了 QUIC 协议和权益加权服务质量 (SWQoS)，从根本上重新设计了网络处理交易优先级和抗垃圾邮件的方式。2025 年 12 月的 DDoS 攻击——一场足以与针对全球云巨头的攻击相抗衡的 6 Tbps 袭击——测试了这些改进。结果是：在整个过程中保持了亚秒级的确认时间和稳定的延迟。

这种韧性不仅是技术成就，更是机构信任的基石。Solana 现在引领着 ETF 浪潮，拥有 8 个现货加质押 ETF 申请，且到 2025 年 11 月已有 6 款产品上线，累计成交额超过 46 亿美元。该网络的声誉已从“快而脆弱”转变为“经受火炼”。

Sui 的前行之路需要类似的转变。计划中的变革——提高验证者操作的自动化程度、增加对共识边缘案例的测试以及尽早检测检查点不一致——是必要但渐进的。更深层次的问题在于，Sui 的架构决策是否本身就比成熟的替代方案更容易产生共识失败的风险。

机构可靠性阈值​

机构究竟需要什么？随着传统金融在链上部署，答案已变得愈发清晰：

可预测的结算：大型托管机构和清算代理现在运行着混合模型，将区块链轨道与传统的支付和证券网络连接起来。在监管控制下的当日交易最终性（Settlement Finality）是基准预期。

运营可审计性：2026 年的机构结算基础设施由精确性和可审计性定义。每笔交易必须可追溯，每一次失败必须可解释，每一次恢复必须符合监管标准的记录。

运行时间保证：传统金融基础设施的运行时间预期为 “五个九”（99.999%）—— 即每年停机时间约为 5 分钟。对于传统托管人来说，资产冻结 6 小时将意味着职业生涯的终结。

优雅降级：当故障发生时，机构希望系统能够优雅降级，而不是完全停止。在共识争议期间完全冻结的区块链违反了这一原则。

Sui 的 100 亿美元冻结，即便没有资金损失，在第三点上也代表了类别级的失败。对于散户交易者和 DeFi 玩家来说，6 小时的暂停只是一种不便。但对于在受托责任下管理客户资本的机构配置者来说，除非另有证明，否则这是一个取消资格的事件。

新兴的可靠性等级体系​

根据 2025-2026 年的性能数据，高吞吐量公链中正在形成一个粗略的可靠性等级体系：

第一梯队 - 经证明的机构级：Ethereum（无重大停机，但吞吐量有限）、Solana（经过改革，拥有 18 个月以上的洁净记录）

第二梯队 - 有前景但尚未证实：Base（由 Coinbase 基础设施支持）、Arbitrum / Optimism（继承了 Ethereum 的安全模型）

第三梯队 - 潜力巨大，可靠性存疑：Sui（多次事件）、缺乏长期记录的新兴 L1

这一等级体系并不反映技术上的优劣 —— Sui 以对象为中心的数据模型（Object-centric Data Model）和并行处理能力仍然具有真正的创新性。但没有可靠性的创新所创造出的技术，机构只能远观而无法部署。

Sui 的下一步​

Sui 对此次事件的反应将决定其机构化轨迹。即时的技术修复解决了特定的 Bug，但更广泛的挑战是展示系统性的可靠性提升。

值得关注的关键指标：

事件间隔时间：2024 年 11 月 → 2025 年 12 月 → 2026 年 1 月的进展显示，频率在加快而非降低。扭转这一趋势至关重要。

恢复时间改进：6 小时虽然好于 17 小时（Solana 最糟糕的纪录），但目标应该是分钟级，而非小时级。需要开发自动故障转移（Failover）和更快的共识恢复机制。

验证节点集成熟度：Sui 的验证节点集比 Solana 的规模更小且缺乏实战磨炼。扩大验证节点的地理分布和运营复杂性将提高韧性。

形式化验证：Sui 的 Move 语言已经强调了智能合约的形式化验证（Formal Verification）。将这种严谨性扩展到共识层代码，可以在边缘情况进入生产环境之前将其捕捉。

好消息是：Sui 的生态系统（DeFi、游戏、NFT）展现出了韧性。没有资金损失，社区的反应更多是建设性的而非恐慌性的。SUI 代币在事件期间下跌了 6%，但并未崩盘，这表明市场将这些事件视为成长的烦恼，而非生存威胁。

2026 年市场的可靠性溢价​

这一教训不仅限于 Sui。随着区块链基础设施的成熟，可靠性正成为一种能够带来溢价估值的差异化特征。能够证明机构级运行时间的公链将吸引下一波代币化资产 —— 正如 OKX Ventures 创始人 Jeff Ren 所预测的，黄金、股票、知识产权和 GPU 将在 2026 年迁往链上。

这为老牌公链创造了战略机遇，也为新进入者带来了挑战。Ethereum 相对较低的吞吐量正变得越来越容易被接受，因为其可靠性是毋庸置疑的。Solana 修复后的声誉为其打开了在故障频发时代曾经关闭的大门。

对于 Sui 和类似的高吞吐量公链， 2026 年的竞争格局要求证明创新与可靠性并非鱼与熊掌不可兼得。实现两者的技术已经存在 —— 问题在于各团队能否在机构失去耐心之前将其落地。

被冻结 6 小时的 100 亿美元并未丢失，但教训也同样深刻：在机构化时代，运行时间（Uptime）才是最终的核心功能。

在 Sui、Ethereum 或其他高吞吐量公链上构建可靠的基础设施，需要经过实战检验的 RPC 服务商，在网络面临压力时保持运行。BlockEden.xyz 提供企业级 API 终端，具有冗余和监控功能，专为机构需求而设计。探索我们的基础设施，在保持在线的基石上进行构建。

2025 年，尽管大多数受攻击的协议都经过了审计，甚至有些还审计了多次，DeFi 仍因智能合约漏洞损失了 33 亿美元。2 月份发生的 15 亿美元 Bybit 攻击、4200 万美元的 GMX 漏洞以及无数次重入攻击，证明了一个令人不安的事实：传统的安全审计是必要的，但并不充分。当数学精度至关重要时，仅仅测试极端情况是不够的。你需要证明它们。

这就是 Sui Prover 开源的意义，它远比仅仅在 GitHub 上发布一个项目更重要。Sui Prover 由 Asymptotic 开发，现在免费提供给 Sui 开发者社区。它将形式化验证（Formal Verification）引入到日常的智能合约开发中。这种数学技术同样被用于确保飞行控制系统和处理器设计不会失效。在这样一个哪怕一个被忽视的边缘情况都可能导致数亿美元损失的背景下，通过数学方式证明代码行为正确已不再是一种奢侈，而正成为一种必需。

当 Mysten Labs 宣布其 Walrus 协议于 2025 年 3 月从 Standard Crypto、a16z 和 Franklin Templeton 获得 1.4 亿美元融资时，它发出了一个明确的信号：去中心化存储战争正在进入一个新阶段。但在一个已经充斥着 Filecoin 的企业雄心和 Arweave 永久存储承诺的格局中，是什么让 Walrus 与众不同，足以在运营首日之前支撑起 20 亿美元的估值？

答案在于对去中心化存储运作方式的根本性重新思考。

无人解决的存储难题​

去中心化存储一直是 Web3 长期以来未能解决的难题。用户希望拥有 AWS 的可靠性以及区块链的抗审查性，但现有的解决方案被迫做出了痛苦的权衡。

Filecoin 是最大的参与者，其市值在 2025 年间大幅波动，它要求用户与供应商协商存储协议。当这些协议到期时，你的数据可能会消失。该网络 2025 年第三季度的利用率达到了 36% —— 比上一季度的 32% 有所提高 —— 但在大规模效率方面仍存在疑问。

Arweave 以其“一次付费，永久存储”的模式提供永久存储，但这种永久性是有代价的。在等量容量下，在 Arweave 上存储数据的成本可能是 Filecoin 的 20 倍。对于处理数 TB 用户数据的应用程序来说，这种经济模型根本行不通。

与此同时，IPFS 实际上并不是存储——它是一种协议。如果没有“固定（pinning）”服务来保持你的数据存活，当节点从缓存中丢弃内容时，内容就会消失。这就像是在一个可能会随时搬迁的地基上盖房子。

Walrus 走进了这个碎片化的领域，而它的秘密武器是数学。

RedStuff：工程领域的重大突破​

Walrus 的核心是 RedStuff，这是一种二维纠删码（erasure coding）协议，代表了分布式系统工程领域的真正创新。要理解为什么这很重要，请考虑传统去中心化存储如何处理冗余。

全量复制（在多个节点上存储多个完整的副本）虽然简单但非常浪费。为了防止多达三分之一的节点可能是恶意的拜占庭故障，你需要大量的重复备份，从而推高了成本。

一维纠删码（如 Reed-Solomon 编码）将文件拆分为带有用于重构的校验数据的碎片。这种方式效率更高，但有一个致命弱点：恢复单个丢失的碎片需要下载相当于整个原始文件的数据。在节点变动频繁的动态网络中，这会产生带宽瓶颈，从而严重影响性能。

RedStuff 通过基于矩阵的编码解决了这个问题，它创建了主要的和次要的“切片（slivers）”。当一个节点发生故障时，剩余的节点可以通过仅下载丢失的部分（而不是整个 blob 对象）来重构缺失的数据。恢复带宽的规模为 O(|blob|/n) 而不是 O(|blob|)，这种差异在大规模应用时变得异常巨大。

该协议仅需 4.5 倍的复制即可实现安全性，而原始方法则需要 10-30 倍。根据 Walrus 团队自己的分析，这意味着在同等数据可用性的情况下，存储成本比 Filecoin 低约 80%，比 Arweave 低 99%。

也许最重要的是，RedStuff 是第一个在异步网络中支持存储证明（storage challenges）的协议。这可以防止攻击者利用网络延迟在没有实际存储数据的情况下通过验证——这是困扰早期系统的一个漏洞。

1.4 亿美元的信任票​

2025 年 3 月结束的这轮融资说明了一切。Standard Crypto 领投，a16z 的加密货币部门、Electric Capital 和 Franklin Templeton Digital Assets 参投。Franklin Templeton 的参与尤为引人注目——当全球最大的资产管理公司之一支持区块链基础设施时，这标志着超越典型加密风投领域的机构信心。

代币销售对 Walrus 的 WAL 代币总供应量的估值为 20 亿美元（完全稀释估值）。作为参考，Filecoin 在运行多年并建立了成熟生态系统的情况下，其市值经历了剧烈波动，在 2025 年 10 月大幅下跌后才有所回升。市场正在押注 Walrus 的技术优势将转化为实质性的应用。

WAL 的代币经济学反映了从早期项目中吸取的教训。50 亿的总供应量包括 10% 的用户激励分配，其中初始空投占 4%，6% 留作未来分配。通缩机制通过部分销毁来惩罚短期质押转移，而对性能不佳的存储节点的罚没（slashing）惩罚则保护了网络的完整性。

代币解锁经过精心设计：投资者的份额直到 2026 年 3 月（即主网上线一整年后）才开始解锁，从而减少了关键早期采用阶段的抛售压力。

现实世界的落地应用​

自 2025 年 3 月 27 日主网上线以来，Walrus 已吸引了 120 多个项目，并完全在去中心化基础设施上托管了 11 个网站。这并非虚无缥缈的宣传——而是真正的生产环境应用。

知名的 Web3 媒体机构 Decrypt 已开始在 Walrus 上存储内容。Sui 最大的 NFT 市场 TradePort 则利用该协议处理动态 NFT 元数据，实现了静态存储方案无法做到的可组合、可升级数字资产。

使用场景已超出简单的文件存储。Walrus 可以作为 Rollups 的低成本数据可用性层（DA），排序器上传交易，执行器只需临时重构交易即可进行处理。这使 Walrus 成为主导近期发展的模块化区块链理论的关键基础设施。

AI 应用代表了另一个前沿领域。干净的训练数据集、模型权重和正确训练的证明都可以通过验证溯源进行存储——这对于正在应对数据真实性和模型审计问题的行业来说至关重要。

存储大战格局​

根据 Fundamental Business Insights 的数据，Walrus 进入的市场预计到 2034 年将达到 65.3 亿美元，年增长率超过 21%。这一增长是由日益增长的数据隐私担忧、上升的网络威胁以及推动组织转向中心化云存储替代方案的监管压力所驱动的。

其竞争定位看起来非常有利。Filecoin 凭借其基于交易的模型瞄准企业级工作负载。Arweave 占据了档案、法律文件和文化保存的永久存储市场。Storj 提供 S3 兼容的对象存储，并采用固定定价（截至 2025 年初为每月每 GB 0.004 美元）。

Walrus 为高可用、高性价比的存储开辟了空间，桥接了链上和链下世界。它与 Sui 的集成为开发者提供了自然的流程，但存储层在技术上是链无关的——构建在 Ethereum、Solana 或其他链上的应用程序都可以接入进行链下存储。

去中心化存储的潜在市场总额（TAM）仍仅占更广泛的云存储行业的一小部分，后者在 2025 年的价值为 2550 亿美元，预计到 2032 年将达到 7740 亿美元。即便只捕捉到这一迁移过程中很小的百分比，也将代表巨大的增长。

技术架构深挖​

Walrus 的架构将控制和元数据（运行在 Sui 上）与存储层本身分离。这种划分允许该协议利用 Sui 的快速最终性进行协调，同时保持存储的不可知性。

当用户存储一个 Blob 时，数据会经过 RedStuff 编码，拆分为 slivers（分片），分布在该纪元（epoch）的存储节点中。每个节点都承诺存储并提供分配给它的 slivers。经济激励通过质押对齐——节点必须维持抵押品，如果性能不佳或数据不可用，这些抵押品可能会被罚没（slashed）。

数据弹性非常出色：即使三分之二的存储节点宕机或变为恶意节点，Walrus 仍能恢复信息。这种拜占庭容错能力超过了大多数生产系统的要求。

该协议结合了认证数据结构，以防御企图破坏网络的恶意客户端。结合异步存储挑战系统，这创建了一个强大的安全模型，足以抵御曾令早期去中心化存储系统陷入困境的攻击向量。

潜在挑战​

如果不审视风险，技术分析就不完整。Walrus 面临着多项挑战：

来自现有玩家的竞争：Filecoin 拥有多年的生态系统建设和企业关系。Arweave 在永久存储领域拥有品牌知名度。取代老牌玩家不仅需要更好的技术，还需要更好的分发渠道。

对 Sui 的依赖：虽然存储层在技术上是链无关的，但与 Sui 的紧密集成意味着 Walrus 的命运部分与该生态系统的成功捆绑在一起。如果 Sui 未能实现主流采用，Walrus 将失去其主要的开发者渠道。

实践中的代币经济学：通缩机制和质押惩罚在理论上看起来很好，但现实世界的行为往往偏离理论模型。2026 年 3 月的投资者解锁将是 WAL 价格稳定性的第一次重大考验。

监管不确定性：去中心化存储在各司法管辖区都处于监管灰色地带。监管机构如何对待数据可用性层——尤其是那些可能存储敏感内容的层——仍不明朗。

最终结论​

Walrus 代表了这一迫切需要创新的领域的真正技术突破。RedStuff 的二维纠删码并非营销噱头——它是一项有发表的研究论文支持的重大架构进步。

来自可靠投资者的 1.4 亿美元融资、快速的生态系统采用以及深思熟虑的代币经济学表明，该项目具有超越典型加密货币炒作周期的持久力。它能否从根深蒂固的竞争对手手中夺取显著的市场份额仍有待观察，但发起严峻挑战的各要素已经就位。

对于需要可靠、实惠、去中心化数据存储的开发者来说，Walrus 值得认真评估。存储大战迎来了一位新竞争者，而这位竞争者带着更先进的数学武器。

正在 Sui 上构建应用，或为你的 Web3 应用程序寻找去中心化存储解决方案？BlockEden.xyz 提供企业级 RPC 基础设施和 API 服务，可与新兴生态系统无缝集成。探索我们的 API 市场，使用专为去中心化未来设计的基础设施为你的下一个项目赋能。

隐私正在成为公共基础设施。在 2025 年，开发者需要让加密变得如存储数据一样简单的工具。Mysten Labs 的 Seal 正好提供了这样的解决方案——具有链上访问控制的去中心化密钥管理。本教程将教你如何使用基于身份的加密、门限安全和可编程访问策略构建安全的 Web3 应用程序。

简介：为什么 Seal 对 Web3 很重要​

传统的云应用程序依赖于中心化的密钥管理系统，其中单一提供商控制对加密数据的访问。虽然方便，但这创造了危险的单点故障。如果提供商被攻击、离线或决定限制访问，你的数据将变得无法访问或易受攻击。

Seal 完全改变了这种模式。由 Mysten Labs 为 Sui 区块链构建，Seal 是一个去中心化密钥管理（DSM）服务，支持：

• 基于身份的加密，内容在离开你的环境之前就受到保护
• 门限加密，将密钥访问分布在多个独立节点上
• 链上访问控制，具有时间锁、代币门控和自定义授权逻辑
• 存储无关设计，可与 Walrus、IPFS 或任何存储解决方案配合使用

无论你是在构建安全消息应用程序、门控内容平台还是时间锁定资产转移，Seal 都提供了你需要的加密原语和访问控制基础设施。

开始使用​

前提条件​

在深入学习之前，确保你具有：

• 安装了 Node.js 18+
• 对 TypeScript/JavaScript 的基本了解
• 用于测试的 Sui 钱包（如 Sui Wallet）
• 对区块链概念的理解

安装​

通过 npm 安装 Seal SDK：

npm install @mysten/seal

你还需要 Sui SDK 进行区块链交互：

npm install @mysten/sui

项目设置​

创建一个新项目并初始化它：

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

创建一个简单的 TypeScript 配置：

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

核心概念：Seal 的工作原理​

在编写代码之前，让我们了解 Seal 的架构：

1. 基于身份的加密 (IBE)​

与传统的加密方式不同（你加密到公钥），IBE 让你加密到一个身份（如电子邮件地址或 Sui 地址）。接收者只有在能够证明他们控制该身份时才能解密。

2. 门限加密​

Seal 使用 t-of-n 门限方案，而不是信任单个密钥服务器。你可以配置 3-of-5 密钥服务器，这意味着任何 3 个服务器可以合作提供解密密钥，但 2 个或更少的服务器不能。

3. 链上访问控制​

访问策略由 Sui 智能合约强制执行。在密钥服务器提供解密密钥之前，它会验证请求者是否满足链上策略要求（代币所有权、时间约束等）。

4. 密钥服务器网络​

分布式密钥服务器验证访问策略并生成解密密钥。这些服务器由不同的方运营，以确保没有单一控制点。

基本实现：你的第一个 Seal 应用程序​

让我们构建一个简单的应用程序，它加密敏感数据并通过 Sui 区块链策略控制访问。

步骤 1：初始化 Seal 客户端​

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
  // 为测试网初始化 Sui 客户端
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // 使用测试网密钥服务器配置 Seal 客户端
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // 2-of-3 门限
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

步骤 2：简单加密/解密​

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
  const { sealClient } = await createSealClient();

  // 要加密的数据
  const sensitiveData = "这是我的秘密消息！";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // 为特定的 Sui 地址加密数据
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // 可选：添加元数据
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('加密数据：', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // 稍后，解密数据（需要适当的授权）
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('解密数据：', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('加密/解密失败：', error);
  }
}

basicExample();

使用 Sui 智能合约的访问控制​

Seal 的真正威力来自可编程访问控制。让我们创建一个时间锁定加密示例，其中数据只能在特定时间后解密。

步骤 1：部署访问控制合约​

首先，我们需要一个定义访问策略的 Move 智能合约：

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

步骤 2：与 Seal 集成​

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // 在 Sui 上创建访问策略
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // 1分钟后解锁
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: 'time_lock::policy::create_time_lock',
    arguments: [
      txb.pure(unlockTime),
      txb.pure(authorizedUser)
    ]
  });

  // 执行交易创建策略
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // 你的 Sui 密钥对
  });

  const policyId = result.objectChanges?.find(
    change => change.type === 'created'
  )?.objectId;

  // 现在使用此策略加密
  const sensitiveData = "这将在1分钟后解锁！";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, 'utf-8'),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: 'time_lock'
    }
  });

  console.log('时间锁定数据已创建。请在1分钟后尝试解密。');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

实际示例​

示例 1：安全消息应用程序​

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID()
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
      recipientId: recipientAddress,
      metadata: {
        type: 'secure_message',
        sender: senderKeypair.toSuiAddress()
      }
    });

    // 将加密消息存储在去中心化存储（Walrus）上
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // 从存储中检索
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // 使用 Seal 解密
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    return JSON.parse(decryptedData.toString('utf-8'));
  }

  private async storeOnWalrus(data: any) {
    // 与 Walrus 存储的集成
    // 这将把加密数据上传到 Walrus
    // 并返回用于检索的 blob ID
  }

  private async retrieveFromWalrus(blobId: string) {
    // 使用 blob ID 从 Walrus 检索加密数据
  }
}

示例 2：代币门控内容平台​

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any
  ) {
    // 创建 NFT 所有权策略
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // 使用 NFT 访问要求加密内容
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // NFT 持有者的特殊接收者
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // 首先验证 NFT 所有权
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('访问被拒绝：未找到所需的 NFT');
    }

    // 解密内容
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

    return decryptedContent.toString('utf-8');
  }

  private async createNftPolicy(collection: string, creator: any) {
    // 创建检查 NFT 所有权的 Move 合约
    // 返回策略对象 ID
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // 检查用户是否拥有所需的 NFT
    // 查询 Sui 的 NFT 所有权
  }
}

示例 3：时间锁定资产转移​

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any
) {
  const { sealClient, suiClient } = await createSealClient();

  // 在 Sui 上创建时间锁定策略
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // 加密资产转移数据
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID()
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: 'time_lock'
    }
  });

  console.log(`资产锁定至 ${new Date(unlockTimestamp)}`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    const transferData = JSON.parse(decryptedData.toString('utf-8'));

    // 处理资产转移
    console.log('资产转移已解锁：', transferData);

    return transferData;
  } catch (error) {
    console.error('转移尚未解锁或访问被拒绝：', error);
    throw error;
  }
}

与 Walrus 去中心化存储的集成​

Seal 与 Sui 的去中心化存储解决方案 Walrus 无缝协作。以下是如何集成两者：

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any
  ) {
    // 使用 Seal 加密
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy
    });

    // 在 Walrus 上存储加密数据
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // 返回包含 Seal 和 Walrus 信息的引用
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any
  ) {
    // 从 Walrus 检索
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // 使用 Seal 解密
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });

    return decryptedData;
  }
}

// 使用示例
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from('重要文档内容');
  const recipientAddress = '0x...';

  // 存储加密数据
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('已存储，Blob ID：', result.blobId);

  // 稍后，检索并解密
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('检索到的数据：', decrypted.toString());
}

门限加密高级配置​

对于生产应用程序，你需要配置具有多个密钥服务器的自定义门限加密：

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
  // 配置多个独立的密钥服务器
  const keyServers = [
    'https://keyserver-1.your-org.com',
    'https://keyserver-2.partner-org.com',
    'https://keyserver-3.third-party.com',
    'https://keyserver-4.backup-provider.com',
    'https://keyserver-5.fallback.com'
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // 3-of-5 门限
    network: 'mainnet',
    // 高级选项
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      'https://backup-1.emergency.com',
      'https://backup-2.emergency.com'
    ]
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "关键任务加密数据";

  // 以高安全保证进行加密
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // 要求所有5个服务器以获得最大安全性
    customThreshold: 5,
    // 添加冗余
    redundancy: 2,
    accessPolicy: {
      // 多因子要求
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

安全最佳实践​

1. 密钥管理​

// src/security-practices.ts

// 正确：使用安全的密钥派生
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// 正确：安全地存储密钥（使用环境变量的示例）
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// 错误：永远不要硬编码密钥
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // 不要这样做！
);

2. 访问策略验证​

// 在加密前始终验证访问策略
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // 验证接收者地址
  if (!isValidSuiAddress(recipient)) {
    throw new Error('无效的接收者地址');
  }

  // 检查策略是否存在且有效
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('无效的访问策略');
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy
  });
}

3. 错误处理和回退机制​

// 健壮的错误处理
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });
  } catch (error) {
    if (error.code === 'ACCESS_DENIED') {
      throw new Error('访问被拒绝：请检查你的权限');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // 尝试使用备份配置
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('可用的密钥服务器不足');
    } else {
      throw new Error(`解密失败：${error.message}`);
    }
  }
}

4. 数据验证​

// 在加密前验证数据
function validateDataForEncryption(data: Buffer): boolean {
  // 检查大小限制
  if (data.length > 1024 * 1024) { // 1MB 限制
    throw new Error('数据太大，无法加密');
  }

  // 检查敏感模式（可选）
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('警告：数据包含潜在的敏感模式');
  }

  return true;
}

性能优化​

1. 批处理操作​

// 批量多个加密以提高效率
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index]
    })
  );

  return Promise.all(promises);
}

2. 缓存密钥服务器响应​

// 缓存密钥服务器会话以减少延迟
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

测试你的 Seal 集成​

单元测试​

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Seal 集成', () => {
  it('应该成功加密和解密数据', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('测试消息');
    const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient
    });

    expect(decrypted.toString()).toBe('测试消息');
  });

  it('应该强制执行访问控制策略', async () => {
    // 测试未授权用户无法解密
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from('秘密'),
      recipientId: 'authorized-user'
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('访问被拒绝');
  });
});

部署到生产环境​

环境配置​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5
  ],
  threshold: 3,
  network: 'mainnet',
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // 安全设置
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1小时
  retryAttempts: 3
};

监控和日志记录​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] 为 ${recipient} 加密数据 ${encryptionId}`);
    // 发送到你的监控服务
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] 解密 ${encryptionId}：${success ? '成功' : '失败'}`);
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] 密钥服务器 ${serverUrl}：${status}`);
  }
}

资源和后续步骤​

官方文档​

• Seal 文档: https://seal-docs.wal.app/
• GitHub 仓库: https://github.com/MystenLabs/seal
• Sui 文档: https://docs.sui.io/
• Walrus 文档: https://docs.wal.app/

社区和支持​

• Sui Discord: 加入 #seal 频道获得社区支持
• GitHub Issues: 报告错误和请求功能
• 开发者论坛: Sui 社区论坛进行讨论

要探索的高级主题​

1. 自定义访问策略：使用 Move 合约构建复杂的授权逻辑
2. 跨链集成：将 Seal 与其他区块链网络一起使用
3. 企业密钥管理：设置你自己的密钥服务器基础设施
4. 审计和合规：为受监管环境实施日志记录和监控

示例应用程序​

• 安全聊天应用：使用 Seal 的端到端加密消息传递
• 文档管理：具有访问控制的企业文档共享
• 数字版权管理：具有使用策略的内容分发
• 隐私保护分析：加密数据处理工作流

结论​

Seal 代表了朝着使隐私和加密成为 Web3 中基础设施级关注点的根本转变。通过结合基于身份的加密、门限安全和可编程访问控制，它为开发者提供了构建真正安全和去中心化应用程序的强大工具。

使用 Seal 构建的主要优势包括：

• 无单点故障：分布式密钥服务器消除了中央权威
• 可编程安全：基于智能合约的访问策略提供灵活的授权
• 开发者友好：TypeScript SDK 与现有的 Web3 工具无缝集成
• 存储无关：与 Walrus、IPFS 或任何存储解决方案配合使用
• 生产就绪：由 Mysten Labs 构建，具有企业安全标准

无论你是在保护用户数据、实施订阅模型还是构建复杂的多方应用程序，Seal 都提供了你需要的加密原语和访问控制基础设施，让你可以放心地构建。

今天就开始构建，加入越来越多的开发者生态系统，让隐私成为公共基础设施的基本组成部分。

准备开始构建了吗？ 安装 @mysten/seal 并开始尝试本教程中的示例。去中心化网络正在等待将隐私和安全放在首位的应用程序。

TL;DR​

• Talus 正在推出 Nexus：一个基于 Move 的框架，将链上与链下工具组合成可验证的 DAG（有向无环图）工作流，目前由可信的 "Leader" 服务协调，并计划逐步引入安全执行环境和去中心化。
• 该栈面向新兴的 智能体经济，整合工具注册、支付通道、Gas 预算与市场，使工具构建者和智能体运营者能够在可审计的条件下实现变现。
• 官方公布了迈向专用链 Protochain（Cosmos SDK + Move VM）的路线，但目前仍以 Sui 为主协调层；Sui + Walrus 存储集成为当前生产环境。
• 代币方案仍在演变：公开资料提到早期的 $TAI 概念，以及 2025 年轻白皮书中新引入的生态代币$US，用于支付、质押与优先级机制。
• 核心风险集中在 Leader 去中心化、代币经济定稿以及 Protochain 性能验证，同时还需保证跨 Sui、Walrus 与链下服务的开发体验。

Talus 在做什么，又不做什么​

Talus 将自己定位为自治 AI 智能体的协调与结算层，而非 AI 推理市场。其核心产品 Nexus 允许开发者把工具调用、外部 API 与链上逻辑封装为 Sui Move 编写的 DAG 工作流。设计重点是可验证性、基于能力的权限控制与模式化数据流，让每次工具调用都能在链上被审计。Talus 还配套推出 Tool Marketplace、Agent Marketplace 和 Agent-as-a-Service，帮助发现并变现智能体能力。

另一方面，Talus 并不运营自有大模型或 GPU 网络。它希望工具构建者将现有服务（如 OpenAI、向量检索、交易系统、数据供应等）封装后注册进 Nexus。因此 Talus 与 Ritual、Bittensor 等算力网络互补，可将其接入为 Nexus 工作流中的工具。

架构：链上控制平面，链下执行​

链上（Sui Move）​

链上组件部署在 Sui 上，提供协调平面：

• 工作流引擎 – DAG 语义支持入口组、分支变体与并发检查，并通过静态验证在执行前尽量规避竞争条件。
• 基础原语 – ProofOfUID 支持低耦合的跨包认证消息；OwnerCap/CloneableOwnerCap 提供基于能力的权限；ProvenValue 和 NexusData 定义了数据的内嵌与远程引用传递方式。
• Default TAP（Talus Agent Package） – 参考智能体，展示如何创建工作表（证明对象）、触发工作流执行并确认工具结果，符合 Nexus Interface v1。
• 工具注册与反垃圾 – 工具创建者需抵押时间锁定的资产才能发布定义，以阻止垃圾工具同时保持开放注册。
• Gas 服务 – 共享对象记录工具定价、用户 Gas 预算及带有到期或次数限制的 Gas 票据。事件会追踪每次领取，便于审计工具方与 Leader 的结算。

链下 Leader​

Talus 运营的 Leader 服务监听 Sui 事件，获取工具模式，调度链下执行（LLM、API、计算任务），按声明的模式校验输入输出，并将结果回写链上。Leader 能力以 Sui 对象表示；若交易失败，相关能力会被“损坏”，直到下个 epoch 才能再次使用。Talus 计划通过 TEE、多运营方以及最终的开放参与来强化这一链路。

存储与可验证性​

Mysten Labs 的去中心化存储层 Walrus 用于智能体记忆、模型文件与大数据集。Nexus 将 Sui 作为确定性的控制平面，并将大体量数据卸载至 Walrus。公开资料指出未来可根据场景选择乐观验证、零知识验证或可信执行等多种模式。

开发者体验与早期产品​

Talus 提供基于 Rust 的 SDK、CLI 工具与详细文档（构建 DAG、接入 LLM、保护工具等）。标准工具目录包括 OpenAI 对话、X（Twitter）操作、Walrus 适配器和数学工具，降低原型设计门槛。C 端方面，IDOL.fun（智能体对战预测市场）和 AI Bae（游戏化 AI 伴侣）用于展示价值并拉动流量。无代码构建器 Talus Vision 定位为面向非开发者的可视化工作流和市场入口。

经济设计、代币与 Gas 管理​

在当前 Sui 部署中，用户用 SUI 充值工作流。Gas 服务会把预算换成针对具体工具的票据，设置到期或范围限制，并记录可在链上对账的领取事件。工具方自定价格，Leader 也通过同一套结算流程获得报酬。由于 Leader 目前可在执行完成后领取预算，用户需要信任运营方，但事件日志提供了可审计轨迹。

代币设计仍未定型。三方解读仍提及早期的 $TAI**，而 Talus 2025 年轻白皮书则提出总量 100 亿的生态代币 **$US，用于工具与 Leader 支付、服务质押及优先权。资料还提到执行时多付的 SUI 可能通过市场兑换成 $US。最终代币经济尚未发布前，这些信息都应视为暂定。

融资、团队与合作​

Talus 于 2024 年底宣布完成 600 万美元 战略轮（累计 900 万美元），由 Polychain 领投，对应估值 1.5 亿美元。资金将用于推进 Nexus、孵化 C 端应用并建设面向智能体的专用 L1——Protochain。公开资料显示 Mike Hanono（CEO） 与 Ben Frigon（COO） 为核心高管。与 Sui、Walrus 的集成公告也凸显 Mysten Labs 基础设施是当前执行环境。

竞争格局​

• Ritual 侧重去中心化 AI 计算（Infernet）与 EVM 集成，强调可验证推理而非工作流编排。
• Autonolas（Olas） 通过链上激励协调链下智能体服务，愿景类似，但缺乏 Nexus 提供的 Move DAG 执行层。
• Fetch.ai 提供 Agentverse 与 uAgents 连接自治服务；Talus 的差异在于对每一步骤进行链上验证并内嵌 Gas 结算。
• Bittensor 通过 TAO 子网奖励 ML 模型贡献，是算力市场，可作为工具接入 Nexus，但不提供 Talus 所强调的商业化轨道。

整体来看，Talus 意在承担智能体工作流的 协调与结算平面，而原始算力与推理由可插拔的专业网络提供。

主要风险与未决问题​

1. Leader 信任度 – 在引入 TEE 与多运营方之前，开发者需要信任 Talus Leader 能正确执行并返回结果。
2. 代币不确定性 – 品牌与机制从 $TAI 转向$US，供应计划、分发与质押经济仍待明确。
3. Protochain 落地能力 – 官方称将采用 Cosmos SDK + Move VM，但目前尚无公开代码库、基准测试或安全审计。
4. 工具质量与垃圾风险 – 抵押要求能抑制垃圾工具，但长期成功取决于模式校验、可用性保障以及链下结果的争议处理。
5. 用户体验复杂度 – 同时协调 Sui、Walrus 及多样链下 API 增加运营负担，需靠 SDK 与无代码工具充分抽象以保持开发者采用率。

2025–2026 年值得关注的里程碑​

• 发布 Leader 路线图：TEE 加固、惩罚机制、对外开放更多运营方。
• 扩充 Tool Marketplace：注册工具数量、定价方式、质量指标（可用率、SLA 透明度）。
• 观察 IDOL.fun、AI Bae、Talus Vision 的用户指标，以衡量智能体原生体验的市场需求。
• 跟踪在 Sui + Walrus 上运行大规模工作流的性能数据：延迟、吞吐量、Gas 消耗。
• 公布最终代币经济：发行节奏、质押收益、SUI→$US 转换路径。
• 释出 Protochain 代码库、测试网与互操作计划（如 IBC 支持），验证专用链假设。

构建者与运营方的参与方式​

• 快速原型 – 使用 Default TAP 搭配标准工具（OpenAI、X、Walrus），构建三节点 DAG，实现数据采集、摘要与链上动作自动化。
• 变现专业工具 – 将自有 API（金融数据、合规校验、定制 LLM 等）封装为 Nexus 工具，设定价格，并发行带到期或次数限制的 Gas 票据以管理需求。
• 为成为 Leader 做准备 – 关注质押要求、惩罚逻辑与故障处理文档，以便网络开放时作为新增 Leader 参与。
• 评估 C 端飞轮 – 分析 IDOL.fun 与 AI Bae 的留存与付费，看面向智能体的消费产品能否带动工具需求。

结论​

Talus 通过 Move 可验证工作流、基于能力的工具组合及明确的变现轨道，为链上智能体经济提供了可信蓝图。接下来成败取决于能否摆脱对可信 Leader 的依赖、落地可持续的代币激励，并证明 Protochain 可以将 Sui 阶段的经验延展到专用执行环境。需要透明结算与可组合智能体工作流的构建者，应持续关注 Talus 化解这些悬念的速度，并将 Nexus 纳入尽调名单。

公有链为所有参与者提供同步且可审计的账本，但默认暴露所有数据。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 门控策略做原型，然后迭代出与应用风险画像匹配的服务商组合与运营控制。

我们很高兴宣布 SUI 代币质押 已在 BlockEden.xyz 上正式上线！即日起，你可以直接通过我们的平台质押 SUI 代币，并在支持 SUI 网络安全与去中心化的同时赚取 2.08% APY。

新功能概览：无缝的 SUI 质押体验​

全新的质押功能为所有人提供机构级别的质押服务，界面简洁直观，让奖励获取变得轻而易举。

关键特性​

一键质押 质押 SUI 前所未有的简单。只需连接你的 Suisplash 钱包，输入想要质押的 SUI 数量并批准交易，即可几乎立即开始赚取奖励，无需繁琐步骤。

竞争性奖励 在质押的 SUI 上获得 2.08% APY。我们的 8% 手续费 完全透明，让你清楚了解收益构成。奖励将在每个 epoch（约 24 小时）结束后每日发放。

可信验证者 加入已经在 BlockEden.xyz 验证节点上质押超过 2200 万 SUI 的社区。我们拥有可靠的验证服务记录，企业级基础设施确保 99.9% 正常运行时间。

灵活管理 资产保持灵活。质押即时生效，奖励立即累计。如需取回资金，可随时发起解除质押，SUI 将在标准的 24‑48 小时解锁期后可用。你可以通过仪表盘实时查看质押和奖励情况。

为什么选择 BlockEden.xyz 质押 SUI？​

选择验证者是关键决策，以下是 BlockEden.xyz 成为你可信赖质押伙伴的理由。

可靠性​

自成立以来，BlockEden.xyz 一直是区块链基础设施的基石。我们的验证节点为企业级应用提供动力，在多个网络上保持卓越的正常运行时间，确保奖励持续产出。

透明公平​

我们坚持完全透明。没有隐藏费用，只有明确的 8% 手续费。你可以通过实时报告监控质押表现，并在链上验证我们的验证者活动。

• 公开验证者地址： 0x3b5664bb0f8bb4a8be77f108180a9603e154711ab866de83c8344ae1f3ed4695

无缝集成​

平台设计简洁，无需创建账户，可直接从钱包质押。体验针对 Suisplash 钱包进行优化，界面清爽直观，适合新手和专家。

入门指南​

在 BlockEden.xyz 开始 SUI 质押仅需不到两分钟。

步骤 1：访问质押页面​

前往 blockeden.xyz/dash/stake。无需注册账户，即可立即开始。

步骤 2：连接钱包​

如果尚未安装，请先安装 Suisplash 钱包。在质押页面点击 “Connect Wallet”，在钱包扩展中批准连接，你的 SUI 余额将自动显示。

步骤 3：选择质押数量​

输入想要质押的 SUI 数量（最低 1 SUI）。点击 “MAX” 可一次性质押全部可用余额，仅保留少量用于支付 gas 费用。摘要会显示质押数量和预计年化奖励。

步骤 4：确认并开始赚取​

点击 “Stake SUI”，在钱包中批准最终交易。你的新质押将实时出现在仪表盘上，奖励即刻累计。

质押经济学：你需要了解的要点​

掌握质押机制是有效管理资产的关键。

奖励结构​

• 基础 APY：2.08% 年化
• 奖励频率：每个 epoch（约 24 小时）发放一次
• 手续费：奖励的 8%
• 复利：奖励会自动转入钱包，可再次质押实现复利增长

收益示例​

以下为基于 2.08% APY（扣除 8% 手续费）的简易收益估算。

注：以上为估算值，实际奖励受网络状况影响可能有所不同。

风险考量​

• 解锁期：解除质押后，SUI 将进入 24‑48 小时的解锁期，期间无法使用且不产生奖励。
• 验证者风险：尽管我们保持高标准，任何验证者都存在运营风险。选择像 BlockEden.xyz 这样信誉良好的验证者尤为重要。
• 网络风险：质押本质上是对底层区块链协议的参与，受其固有风险影响。
• 市场风险：SUI 代币的市场价格波动会影响你质押资产的整体价值。

技术卓越​

企业级基础设施​

我们的验证节点基于技术卓越的底层构建，采用跨地域冗余系统确保高可用性。24/7 监控、自动故障转移以及专业运维团队全天候管理，定期进行安全审计与合规检查。

开源与透明​

我们坚持开源原则，质押集成过程透明，可供用户审查。实时指标在 SUI 网络浏览器上公开，费用结构全程公开，无隐藏成本。我们亦积极参与社区治理，助力 SUI 生态发展。

支持 SUI 生态​

通过在 BlockEden.xyz 质押，你不仅获得奖励，还在以下方面为 SUI 网络贡献力量：

• 网络安全：你的质押提升了 SUI 网络的整体安全性。
• 去中心化：支持独立验证者如 BlockEden.xyz，增强网络弹性，防止中心化。
• 生态增长：我们将收取的手续费再投入基础设施维护与研发。
• 创新：收入用于研发新工具和服务，服务整个区块链社区。

安全与最佳实践​

请始终将资产安全放在首位。

钱包安全​

• 永不泄露 私钥或助记词。
• 大额资产建议使用硬件钱包进行存储和质押。
• 在签名交易前务必核对交易细节。
• 保持钱包软件为最新版本。

质押安全​

• 初次质押建议先使用小额熟悉流程。
• 考虑将质押分散到多个信誉良好的验证者，以降低风险。
• 定期监控质押资产和奖励情况。
• 在质押前充分了解解锁期规则。

加入 SUI 质押的未来​

BlockEden.xyz 的 SUI 质押功能不仅是新特性，更是参与去中心化经济的入口。无论你是经验丰富的 DeFi 用户，还是刚踏入区块链世界的新手，我们都提供简洁安全的方式，让你在为 SUI 网络贡献力量的同时赚取奖励。

准备好开始赚取了吗？

访问 blockeden.xyz/dash/stake，立即质押你的首批 SUI 代币！

关于 BlockEden.xyz​

BlockEden.xyz 是领先的区块链基础设施提供商，为开发者、企业和更广泛的 Web3 社区提供可靠、可扩展且安全的服务。从 API 服务到验证节点运营，我们致力于构建去中心化未来的基石。

• 成立时间：2021 年
• 支持网络：15+ 区块链网络
• 企业客户：500+ 家全球公司
• 累计安全资产：超过 1 亿美元，覆盖所有网络

关注我们的 Twitter，加入我们的 Discord，并在 BlockEden.xyz 探索完整服务套件。

免责声明：本文仅供参考，不构成任何金融建议。加密货币质押存在风险，包括本金损失的可能性。请自行研究并根据自身风险承受能力决定是否质押。

引言​

2023 年 5 月 3 日在经过三轮广泛的测试网后正式对公众开放，Sui 区块链推出了一套创新的燃气定价系统，旨在惠及用户和验证者。其核心是 参考燃气价格（RGP），即网络范围内的基准燃气费，验证者在每个 epoch（约 24 小时）开始时共同确定。

该系统旨在为 SUI 代币持有者、验证者和终端用户构建一个互惠的生态系统，提供低且可预测的交易费用，同时奖励表现良好且可靠的验证者。本文深入探讨 RGP 的确定方式、验证者的计算方法、对网络经济的影响、治理下的演进以及与其他区块链燃气模型的比较。

参考燃气价格（RGP）机制​

Sui 的 RGP 不是静态数值，而是通过每个 epoch 的动态、验证者驱动的过程重新设定。

• 燃气价格调查（Gas Price Survey）： 在每个 epoch 开始时，每个验证者提交其“保留价格”——即他们愿意接受的最低燃气价格。协议随后按质押量对这些提交进行排序，并将该 epoch 的 RGP 设为 质押加权的 2/3 分位数。此设计确保代表总质押量至少三分之二的验证者愿意以该价格处理交易，从而保证服务的可靠性。

• 更新频率与要求： 虽然 RGP 每个 epoch 设定一次，但验证者必须主动管理其报价。官方指南要求验证者 至少每周更新一次 燃气价格报价。此外，如果 SUI 代币价值出现 20% 以上的波动，验证者必须立即更新报价，以确保 RGP 准确反映当前市场情况。

• 计分规则与奖励分配： 为确保验证者遵守约定的 RGP，Sui 使用“计分规则”。在整个 epoch 中，验证者相互监控对方的表现，追踪同行是否及时处理 RGP 价格的交易。此监控产生每个验证者的绩效得分。epoch 结束时，这些得分用于计算奖励乘数，以调整每个验证者的质押奖励份额。

  • 表现良好的验证者获得 ≥1 的乘数，提升其奖励。
  • 迟缓、延误或未按 RGP 处理交易的验证者获得 <1 的乘数，等同于削减其部分收益。

这套两部分系统构建了强大的激励结构。它阻止验证者报出他们无法支撑的过低价格，因为绩效不足的财务惩罚将非常严厉。相反，验证者被激励提交他们能够可持续且高效处理的最低价格。

验证者操作：计算燃气价格报价​

从验证者的视角来看，设定 RGP 报价是直接影响盈利能力的关键运营任务。它需要构建数据管道和自动化层，以处理来自链上和链下的多种输入。关键输入包括：

• 每个 epoch 执行的燃气单位数
• 每个 epoch 的质押奖励和补贴
• 存储基金贡献
• SUI 代币的市场价格
• 运营支出（硬件、云托管、维护）

目标是计算一个能够确保净奖励为正的报价。过程涉及以下关键公式：

1. 计算总运营成本：
   确定验证者在给定 epoch 中以法币计的支出。

   $$\text{Cost}_{\text{epoch}} = (\text{Total Gas Units Executed}_{\text{epoch}}) \times (\text{Cost in USD per Gas Unit}_{\text{epoch}})$$

2. 计算总奖励：
   确定验证者以法币计的总收入，来源于协议补贴和交易费用。

   $$\text{USD Rewards}_{\text{epoch}} = (\text{Total Stake Rewards in SUI}_{\text{epoch}}) \times (\text{SUI Token Price})$$

   其中 Total Stake Rewards 为协议提供的 Stake Subsidies 与交易收取的 Gas Fees 之和。

3. 计算净奖励：
   验证者盈利能力的最终衡量指标。

   $$\text{USD Net Rewards}_{\text{epoch}} = \text{USD Rewards}_{\text{epoch}} - \text{USD Cost}_{\text{epoch}}$$

   通过在不同 RGP 水平下建模预期成本和奖励，验证者可以确定一个最优报价提交至燃气价格调查。

主网启动时，Sui 将初始 RGP 固定为 1,000 MIST（1 SUI = 10⁹ MIST），持续一至两周。这为验证者提供了一个稳定的运营期，以收集足够的网络活动数据并在动态调查机制全面生效前建立计算流程。

对 Sui 生态系统的影响​

RGP 机制深刻塑造了整个网络的经济学和用户体验。

• 对用户：可预测且稳定的费用
  RGP 为用户提供了可信的锚点。交易的燃气费遵循简单公式：用户燃气价 = RGP + 小费。在正常情况下无需小费。网络拥堵时，用户可添加小费以获取优先权，从而在不改变 epoch 内稳定基准价的前提下形成费用市场。该模型相较于每个区块都变动基准费的系统，提供了显著更高的费用稳定性。

• 对验证者：效率竞争
  系统鼓励健康竞争。验证者被激励降低运营成本（通过硬件和软件优化），以能够以更低的 RGP 获利。这种“效率竞争”通过压低交易成本惠及整个网络。机制同样迫使验证者保持平衡的利润率；报价过高会被排除在 RGP 计算之外，报价过低则会导致运营亏损并受到绩效惩罚。

• 对网络：去中心化与可持续性
  RGP 机制有助于网络的长期健康。“新进、更高效”验证者的进入威胁防止现有验证者串通抬高价格。此外，验证者根据 SUI 代币的市场价格调整报价，集体确保运营在现实条件下可持续，从而使费用经济不受代币价格波动的直接影响。

治理与系统演进：SIP‑45​

Sui 的燃气机制并非静态，而是通过治理不断演进。一个典型案例是 SIP‑45（优先交易提交），该提案旨在细化基于费用的优先级机制。

• 解决的问题： 分析表明，仅支付高燃气价并不总能保证更快的交易被打包。
• 提案内容： 提案包括提升最高允许燃气价上限，并为显著高于 RGP（例如 ≥5× RGP）的交易引入“放大广播”，确保这些交易在网络中快速传播以获得优先打包。

此举展示了基于实证数据对燃气模型进行迭代的承诺，以提升其有效性。

与其他区块链燃气模型的比较​

Sui 的 RGP 模型独具特色，尤其是与以太坊的 EIP‑1559 相比。

潜在批评与挑战​

尽管设计创新，RGP 机制仍面临若干挑战：

• 复杂性： 调查、计分规则以及链下计算体系较为繁复，可能对新验证者构成学习门槛。
• 对突发需求的响应慢： RGP 在整个 epoch 内固定，无法即时应对突发的需求激增，可能导致短暂拥堵，直至用户开始添加小费。
• 潜在的串通风险： 理论上验证者可合谋设定高 RGP，但开放的验证者集合及竞争压力在很大程度上抑制了此类行为。
• 无燃气费销毁： 与以太坊不同，Sui 将所有燃气费回流至验证者和存储基金，这虽奖励网络运营者，却未对 SUI 代币形成通缩压力，而这点对部分代币持有者而言可能是缺憾。

常见问题（FAQ）​

为什么要质押 SUI？
质押 SUI 可保障网络安全并获取奖励。最初，这些奖励由 Sui 基金会大幅补贴，以弥补网络活动低的情况。补贴每 90 天下降 10%，预期交易费用奖励将逐步成为主要收益来源。质押的 SUI 还能在链上治理中获得投票权。

我的质押 SUI 会被削减吗？
会。虽然参数仍在完善中，但“计分规则削减”已生效。当验证者因低绩效、恶意行为等被其 2/3 同行给出零绩效分时，其奖励将被削减（具体比例待定）。如果所选验证者出现宕机或报价不佳，质押者也可能错失奖励。

质押奖励会自动复投吗？
会。Sui 的质押奖励在每个 epoch 自动分配并重新质押（复投）。若想提取奖励，需要显式进行解除质押操作。

Sui 的解锁期是多久？
初期，质押者可以立即解锁代币。预计未来会引入解锁期，即在解除质押后代币会被锁定一段时间，此规则将通过治理决定。

质押时我仍然持有我的 SUI 吗？
是的。质押 SUI 时，你是将权益委托给验证者，但仍然完全掌控你的代币，永不转移托管权给验证者。