Walrus 2025技术复盘：Sui生态去中心化存储的演进与实践

2025 年如果只让我选一个被行业低估的技术变量我会选 Walrus。这不是因为它涨了多少倍而是因为这个项目把去中心化存储从冷备份机器变成了可以拿来写应用的基础设施——过去几年 Filecoin 和 Arweave 各自定义了归档和永久存储而 Walrus 在 Sui 生态里跑出了一条兼顾低延迟、高可用性和低成本的新路线。这篇文章不是什么投资分析而是一个长期关注存储赛道的技术从业者按自己的视角对 Walrus 2025 年做的一次完整复盘测试网到主网的关键节点、存储机制的核心设计、生态落地现状、节点运营的实际账本以及给开发者的接入体验。1. 从测试网到主网Walrus 的 2025 关键节点1.1 测试网阶段把节点故障当作默认状态来设计Walrus 的公共测试网其实在 2024 年就已经跑起来了但真正进入我视野的是 2025 年初的那段时间。当时 Sui 生态里好几个项目开始把 NFT 元数据、前端资源这类原本放在 IPFS 或中心化 CDN 上的文件往测试网上搬存储量增长很快。测试网阶段最有价值的一件事是让整个网络在节点大规模掉线这个最极端的情况下做了充分演练——分布式存储最怕的从来不是数据写不进去而是写了之后读不出来尤其是当大量节点同时离线的时候。Walrus 的设计思路和大部分存储项目不一样它没有要求每个节点都保存完整副本而是把文件切片后用纠删码分散到很多节点上。官方文档里给的容错模型是少于 1/3 节点可用时仍能恢复数据这在测试网期间被验证过多次。我记得有一次 Sui 测试网重启连带 Walrus 测试网也出现了大面积节点失联但已经写入的 blob 仍然可以通过任意一个可用的存储节点组合找回。这种默认节点会挂的假设比那些假设节点永远在线、然后出了问题再补 proof 的项目要务实得多。测试网还给开发者提供了一套完整的 SDKputBlob、getBlob这种接口在 2024 年年底就已经比较稳定了。我身边的人基本都是先在测试网上把业务逻辑调通等到主网上线之后直接改一个网络参数就切过去迁移成本很低。这个铺垫工作2025 年上半年做得很扎实。1.2 主网上线与 WAL 代币启动预期内与预期外的变化主网上线的时间大概在 2025 年第一季度末具体日期我记不太清了但那天最让我印象深刻的是 WAL 代币的同步启动。WAL 这个代币不是像很多老项目那样先上线、再慢慢补经济模型而是在主网启动的同时就把质押、存储付费、治理投票三条线全部打通了。也就是说从第一天起网络上的每个存储节点都有真金白银的质押每个上传的文件都要真金白银地付存储费用这个比单纯先把网络跑起来、经济系统以后再说的做法要健康得多。上线之后出现了两个超出我预期的变化。第一个是存储节点的竞争比想象中激烈。主网刚开的时候有段时间存储节点名额一度非常紧张官方文档里写的是开放准入但实际的委托量很快就把节点能承接的存储量推到了高位。第二个是 WAL 的价格波动没有影响实际存储成本因为存储费用是用 WAL 计价的但价格参照的是链上 oracle 和存储市场的供需关系而不是币价本身。这一点对开发者很友好至少你不会因为今天 WAL 跌了 10% 就发现自己的存储成本暴涨。另一个预期内的变化是Sui 生态里几个头部 DeFi 协议在第一批就接入了 Walrus但它们当时用的还都是把静态文件放上去这种比较初级的用法。真正让生态活跃起来的其实是后面几个月初创团队做出来的应用这个我在第三章会展开讲。1.3 下半年版本节奏、存储量增长与网络稳定性下半年 Walrus 的迭代节奏明显加快了。我记得有几个重要的版本升级把存储节点的可用性证明机制做了优化降低了链上验证的 gas 开销同时把单次 blob 的上限调高了不少。还有一次升级引入了更灵活的存储续期方式不再是必须一次性买断默认周期而是允许用户按需延长——这个改动对生产环境特别重要后面讲开发者体验时我会详细说。从网络数据来看2025 年年底的时候Walrus 存储的 blob 总量已经比主网上线初期高了一个量级。虽然我没有保存精确的数字但官方 dashboard 上的增长曲线是非常可观的。更重要的是网络整体稳定性表现很好全年没有出现长时间的数据不可用事故。对于一个去中心化存储项目来说没有事故本身就是最大的亮点。2. 存储架构拆解Walrus 解决的是哪个最后一公里问题2.1 Blob 存储模型内容寻址、不可变性与续期逻辑要理解 Walrus 和传统存储的区别先要看它的存储对象模型。Walrus 存储的基本单位叫 blob就是一段二进制数据最大可以到很大升级之后单 blob 的容量已经覆盖绝大多数业务场景。每个 blob 有一个全局唯一的 blob ID这个 ID 是根据内容哈希计算出来的也就是说相同的内容只会对应同一个 ID——去重是天然的这一点和 IPFS 有点像。但和 IPFS 很不一样的是Walrus 的 blob 默认是不可变的。你上传一个文件这个文件在存储周期内不会被修改也没有人能在链上提交一个更新操作去改变它的内容。这听起来像是个限制但实际构建应用的时候这种不可变性反而是一种资产。例如一个 NFT 的元数据或者一个应用的版本清单一旦写进去就可以被完整地信任因为它不可能被篡改。需要更新的时候开发者通常的做法是在 Sui 上存一个注册表对象把当前版本的 blob ID 映射存在链上新版本上传后改一下映射就行。存储周期是一个绕不开的话题。Walrus 的存储不是永久的而是按epoch计费这个周期可以简单理解成网络内部的时间片。上传文件的时候你需要指定存多少个 epoch并支付对应的费用到期之后如果没有续期存储节点就没有义务继续保留数据。这个设计和 Arweave 的一次性永久存储形成了鲜明对比也是很多第一次接触 Walrus 的人最纠结的地方。但说实话对于绝大多数应用场景来说2 年的默认存储期已经完全够用了而且你还可以随时续期。2.2 纠删码与可用性证明存储节点怎么证明我还在Walrus 的核心机制是建立在两个支柱上的纠删码和可用性证明。先说纠删码。假设网络里有 100 个存储节点文件上传时会被切分成一定数量的数据片然后根据纠删码算法生成额外的校验片这些数据片和校验片会被分散到不同的节点上。因为纠删码天然有冗余即使有相当一部分节点离线只要你能凑够足够数量的分片就可以无损还原出原始文件。相比每个节点存完整副本的方案这种做法的存储开销要低得多同时又把容错率维持在一个很高的水平。然后是可用性证明。光把分片发出去还不够存储节点必须持续向链上证明我确实还保留着这块数据。Walrus 的节点需要定期提交一种基于 Merkle 树和随机挑战的证明这个证明会被 Sui 链上的合约验证。如果节点交不上证明或者证明验证失败就会被视为失职质押的 WAL 会被罚没一部分。这套机制保证了存储这件事不是节点拍胸脯口头承诺的而是经济上真金白银在担保的。从我的经验看这套机制的实际运行相当硬核真有节点因为离线时间过长被罚社区里因此还展开过几轮关于到底该留多少质押量才安全的讨论。2.3 和 Sui 的分工链上计算与链下存储的接力关系Walrus 给人的第一印象是又一个去中心化存储但它的架构里最关键的一步棋是和 Sui 区块链的深度绑定。Sui 负责的是轻量级的状态管理比如用户账户、资产余额、订单状态、注册表映射这些数据量小、更新频繁而 Walrus 负责的是重量级的静态内容比如图片、视频、HTML、游戏地图、元数据文件这些数据量大、不需要频繁更新。这个分工在实践里非常自然。一个链上游戏如果想把角色头像和皮肤资源存在链上成本高得吓人如果存在中心化服务器用户和资源都有审查风险。用 Walrus资源文件用 blob 存角色对象和资源引用放在 Sui 上前端从 Sui 拿到 blob ID滑块去 Walrus 读取文件整个链路都是去中心化的而且读取速度几乎和传统 CDN 无异。这个链上状态 链下大文件的架构几乎可以说是 2025 年去中心化应用在存储层的主流答案了。3. 生态落地盘点2025 年真正跑起来的应用场景3.1 NFT 与链上游戏高频小对象存储的主战场2025 年 Walrus 生态里最活跃的细分领域毫无疑问是 NFT 和链上游戏。这两个场景对存储的核心需求高度一致资源文件要小、读取要快、内容不可篡改、能扛住突发流量。NFT 项目用 Walrus 的好处很直观。之前很多 NFT 的元数据和图片放在 IPFS 的公共网关上经常出现打开一个页面等三秒、图还在转圈的体验项目方的付费网关又经常带宽不够。Walrus 这边是存储节点并行提供读取服务天然有分布式 CDN 的效应图片加载速度明显比 IPFS 网关快。而且因为 blob 不可变元数据里指向的图片只要写进去了就不可能被换掉防止了项目方跑路后把图片换成垃圾内容这类问题对收藏者来说是一个很实在的安全保障。链上游戏把这套用得更深。我见过一个比较极端的案例一个 MMO 类型的链游把地图切片、技能特效、NPC 对话文本全部封装成 blob 包玩家进入新地图时才动态加载对应区域的数据。虽然它肯定还不算无缝大世界但在去中心化基础上能达到这个体验2023 年我是不敢想的。游戏资源的特点是文件多、单个不大、访问分布不均高峰期集中在晚上和周末Walrus 的多节点读取机制天然能摊掉这部分压力。加上 Sui 的高吞吐链上结算这类对存储和计算要求都高的应用在 2025 年确实找到了可以落地的底座。3.2 Walrus Sites 与前端托管去中心化网页的形态第二个比较亮眼的方向是 Walrus Sites本质上是把整个前端网站存进 Walrus。传统的 DApp 前端要么托管在 Vercel、AWS 上要么用 IPFS 的固定网关前者的部署和访问完全依赖一家公司后者则要忍受网速和可用性的波动。Walrus Sites 的做法是把静态资源打包上传成 blob然后在 Sui 上注册一个站点对象用户通过特殊的域名后缀类似 walrus.site访问解析时先到 Sui 读取站点对象再根据里面的 blob ID 去 Walrus 拉取页面。这个方案 2025 年的成熟度已经相当高了。我自己试过把一个纯前端的小工具站部署上去从打包到上传、再到绑定域名访问差不多花了不到半小时而且访问速度非常接近传统 CDN。很多 DeFi 项目已经把自己的官网和 DApp 前端迁到了 Walrus Sites 上。对于前端不可被攻击这个诉求来说这是一个很大的进步——至少搜索下你用的 DeFi 协议前几个月有没有被 DNS 劫持或者界面被篡改的新闻就能理解把静态资源从中心化托管里挪出来的价值。当然Walrus Sites 目前的适配还有边界动态 SSR 这种依赖后端渲染的场景暂时支持不了但作为 DApp 前端和品牌官网的托管层2025 年已经可以算是生产可用的状态了。3.3 DeFi 与社交应用从存得下到读得快DeFi 协议接入 Walrus 的场景上半年还集中在存设计文档、存前端资源这类辅助内容下半年开始有一些更重度的用法出现。一个很有代表性的方向是把复杂的财务数据、清算参数、提案投票的说明材料这些需要长期留痕的文件放上去配合 Sui 链上的对象引用形成完整的审计线索。这类数据不要求频繁更新但必须不能被篡改、要能在任何时候被公开抽取出来核对Walrus 的不可变 blob 正好兜底。社交应用则是另一个值得关注的新增量。2025 年下半年我肉眼可见地看到 Sui 生态里冒出了一批做链上社交图谱、内容社区的项目它们把用户发的帖子内容、图片、短视频存在 Walrus 上把关注关系、点赞、评论这类高频状态放在链上。这个做法的原因很简单内容数据没有频繁更新需求存链上成本不划算但内容又是用户的核心资产放中心化服务器上随时可能被下架。Walrus 提供的低成本 内容寻址 不可篡改组合恰好契合了内容类应用对持久性和自主性的双重需求。这类应用目前还处于早期阶段但内容本身存 Walrus、社交关系跑在链上这个分层我认为大概率会成为下一个周期社交赛道的标准范式。4. 节点运营与代币账本运行一个 Walrus 存储节点要算清哪些账4.1 硬件配置与网络要求比 Filecoin 挖矿门槛低一个量级先说结论如果你跑过 Filecoin 节点再来看 Walrus 的节点要求会有一种终于不用烧钱堆机器的释然。2025 年 Walrus 存储节点并没有要求你必须要专用的高性能 GPU 或者巨型存储阵列一台配置尚可的服务器、加上足够大的磁盘空间和稳定的公网带宽基本就能参与。和 Filecoin 早期那种需要大规模集群、专业机房、动辄几十万硬件投入的矿场模式相比Walrus 的硬件门槛低了不止一个量级。从 network 配置角度我建议至少备份磁盘容量是节点承诺存储量的两倍以上。因为 Walrus 节点会不断接收新的分片、偶尔还需要参与数据恢复预留空间不够的话很容易在某个存储高峰期被打到磁盘写满进而导致可用性证明失败。公网带宽建议最好有独立的公网 IP 和足够的上行带宽读取请求都是从用户侧发起的如果你的上行带宽太小存储利用率一直上不去后面接单多了一样会被惩罚。4.2 质押、奖励与被罚没风险收益模型里的隐性门槛Walrus 节点的收益模型分成几个部分第一部分是存储费用的分成用户付的 WAL 会按比例分配给实际存储了这份数据的节点第二部分是系统层面的代币奖励用于激励节点参与存储和提供可用性证明第三部分是质押相关的委托收益如果你的节点质押量不够可以接受其他持有者的委托然后给委托人分成。这里有一个重要的隐性门槛也是很多新手容易踩坑的地方可用性证明的罚没机制是真实存在的。节点如果离线太久、连续多个 epoch 没有提交有效证明质押的 WAL 会被扣掉严重的情况下可能直接把节点的质押罚穿。群里有个朋友讲过他的经验有一次机房网络维护他以为只是一两个小时的事结果错过了整个证明窗口最后被罚的金额差不多顶得上半个月收益。所以我的建议是跑节点一定要有监控告警别指望偶尔掉线没事经济模型设计得越严格对节点运营方的运维能力要求就越高。另外质押量的设计也要算清楚。质押太多会占用资金、拉低收益率质押太少又可能影响节点被委托的权重让存储量上不去。一个相对稳妥的做法是参考网络上同类节点的质押量和承接存储量保持一个中位数水平然后根据实际利用率再慢慢调整。我把参与前一定要算清楚的几项列在下面项目说明建议硬件投入服务器、磁盘、带宽按承诺存储量的 2 倍预留磁盘质押资金启动所需 WAL先小额测试稳定后再加码运维成本监控、告警、故障响应必须配置节点状态监控和证明提交告警罚没风险离线或证明失败预留一定 WAL 作为风险缓冲收益预期存储分成 系统奖励 委托收入保守估算不要按最优情况规划4.3 存储定价与补贴经济模型的可持续性考验Walrus 的存储费用不是官方定死的而是由存储节点在市场上竞争报价形成的。我理解这套机制的核心是存储成本应该接近真实的市场化价格而不是靠补贴制造一个看起来很便宜、但其实没人愿意长期服务的价格。2025 年全年的存储价格整体是下行的这跟更多存储节点加入、网络整体存储容量增加有直接关系。对用户来说这当然是好事对节点运营者来说就要求你能控制好自身成本否则利润率会被压得很薄。不过也要泼一盆冷水目前 Walrus 存储定价的可持续性还没有经过完整的周期检验。现在网络里有一部分存储需求来自 Sui 生态的原生项目这些项目对成本相对不敏感更看重速度和可靠性。如果未来生态扩展变得平缓而节点的供给继续快速增长存储价格可能会进一步下行到那时一部分成本控制能力差的节点会被自然淘汰。这个动态过程和早期 CDN 行业的洗牌很像不能只看一两个月的收益曲线。从经济模型的长期健康角度我会更关注几个指标blob 的续期率、存储节点的实际利用率、以及 WAL 质押总量的变化。如果续期率长期偏低说明大量用户只是一次性写入而没有长期存储需求那存储节点的可持续性就会打折扣利用率则是价格之外最能反映真实供需的指标一个存储节点如果长期只有很低的存储使用率那么它贡献给网络的价值就非常有限对应的收益自然也会比较难看。5. 横向对比 Filecoin 与 ArweaveWalrus 的位置到底在哪里5.1 三种存储范式的适用边界谈 Walrus 就绕不开和 Filecoin、Arweave 的对比。2025 年这三个项目已经在事实上形成了三种差异明显的存储范式彼此的适用边界非常清晰。Filecoin 本质上是为冷归档设计的。它用复杂的时空证明机制保证数据在很长的周期内被物理保存但写入和读取的体验都不适合实时应用——你要等封装、等证明、等检索市场撮合。所以 Filecoin 的典型场景是合规备份、科研数据归档、大体积文件的长期留存。它不是在和 Walrus 抢同一个市场。Arweave 更激进一次付费永久存储靠的是区块网络本身的共识机制。它的优势是一次写入永远存在这个承诺极其简单粗暴非常适合法律文书、时间戳验证、历史档案这类要留几百年的数据。代价是写入费用相对较高而且数据一旦写进去想删也删不掉——对某些业务来说这未必是好事。Walrus 的定位明显更偏暖存储和热存储它服务的是需要高频读取、快速响应、还要有一定持久性保证的应用数据。NFT 图片、游戏资源、前端页面、社交内容这些数据不需要永久保存大多数需求 2 年、5 年之后大概率都已经迭代掉了但它们在业务的生命周期内必须随时可以快速取用。Walrus 在设计上允许你只按需要的存储时长付费而不是强制你永久存储这是一种更务实的产品思维。三者的关系完全可以是一个应用同时使用多种存储大体积的冷数据扔到 Filecoin 或 Arweave热数据和高频访问资源放 Walrus。5.2 成本、延迟、持久性算一笔真实应用的账具体到技术和成本数据上2025 年三种方案的实际表现差异很大。延迟方面Walrus 的读取接近传统 HTTP 服务的体验因为它本质上就是一个内容寻址的分布式对象存储前端直接请求存储节点的 HTTP 端点就能拿到数据。Arweave 的读取路径依赖网关首次访问会比较慢但缓存命中后也还行。Filecoin 的常规读取链路则要经历链上验证和检索市场匹配延迟基本是分钟级别所以它从来就不适合做实时数据源。成本方面需要分开算。Walrus 是按存储周期付费单位成本在三个方案里属于中间水平但因为它不要求你永久存储所以短期项目的总成本其实是最低的。Arweave 看起来是一次买断但单价较高而且如果需要频繁更新每次新增版本都要再付一次永久存储费用累积下来并不便宜。Filecoin 的单价最低但加上封装、gas、检索的成本小文件场景的实际成本并没有比 Walrus 有明显优势。持久性方面Arweave 的承诺最彻底Filecoin 靠长时间证明堆积Walrus 默认提供 2 年周期加上可续期机制已经能覆盖绝大多数业务需求。当然Walrus 的持久性依赖于协议层面的续期机制和代币经济长期健康运转这需要一段更长的时间来检验但至少从 2025 年的运行状态来看还没有出现过因为节点大规模退出去导致用户数据无法恢复的记录。6. 开发者接入体验从 demo 到生产的真实反馈6.1 从一段最小示例看接入流程Walrus 的 TS SDK 用起来非常接近传统对象存储的体验一个最小示例大概长这样先安装依赖官方主网环境可以直接用mysten/walrus这个包具体包名要以当下文档为准SDK 迭代得比较快npm install mysten/walrus mysten/sui然后写一个上传和读取的最小脚本import { SuiClient } from mysten/sui/client; import { WalrusClient } from mysten/walrus; const suiClient new SuiClient({ url: https://fullnode.mainnet.sui.io, }); const walrusClient new WalrusClient({ network: mainnet, suiClient, }); async function main() { // 上传一段 JSON 数据存储两个存储周期 const blob await walrusClient.putBlob({ bytes: new TextEncoder().encode(JSON.stringify({ hello: walrus })), epochs: 1, }); console.log(blobId:, blob.blobId); // 通过 blobId 读取 const bytes await walrusClient.getBlob({ blobId: blob.blobId, }); console.log(content:, new TextDecoder().decode(bytes)); } main().catch(console.error);这个流程里你需要理解两个关键概念blob ID 是你在链上其他地方引用的句柄epochs 则是存储时长的计费单位。上传完成后SDK 会返回 blob ID读取时只要用这个 ID 去请求 Walrus 的存储节点网关即可。后端服务可以用支持的 API 接口走 HTTP 上传比 SDK 更轻量。6.2 生产环境中的性能表现从机上测试到真实生产的最大区别在于要面对并发的访问和大量的文件版本更新。在这方面Walrus 的表现比我预想的要好。2025 年我自己做的一个项目把超过 10 万个图片文件传了上去单个文件大小从几十 KB 到几 MB 不等并发的读取请求峰值大概在每分钟 200 次左右。整个高峰期没有出现读取超时或者数据丢失的情况blob 的平均读取耗时维持在 200ms 以下考虑到文件的平均大小这个速度已经接近国内普通 CDN 的水平了。上传端的体感也还可以小文件的上传基本是秒级完成大文件比如上百 MB 的视频包会慢一些但可以在后台异步处理不影响用户交互。还要提一下性能的一个埋伏点读取速度很大程度上取决于文件本身在存储节点上的分片布局。如果某些分片被集中调度到了网络质量较差的节点上读取时的最大耗时会被拉高。Walrus 的读取机制会做不少优化但开发者还是应该在大规模发布前先做一次全链路的压力测试。我们测试时就发现部分冷门文件的首次读取要比热门文件慢很多这是分片分布和缓存共同导致的结果解决办法就是对高频读取的 blob 做一次预热让分片在多个节点上都有缓存。6.3 值得注意的坑与资源管理建议最后总结一下这一年在 Walrus 上做开发踩过的坑和管理资源的经验这些内容在官方文档里不一定写得那么直接第一不要试图在链上拿到大文件的内容。Walrus 的 blob 是存在链下存储节点上的Sui 链上只保存它的元数据、所有权关系和注册信息。你的后端服务如果需要一个本地的内容缓存建议自己加一层避免每次用户请求都穿透到 Walrus 的存储节点。虽然读取速度已经不错了但毕竟每次请求都涉及到寻址、分片定位和网络传输自己架一层缓存能把延迟和带宽成本都降下来。第二文件更新要设计好版本映射。因为 blob 不可变应用每次生成新版本内容实际上就是产生一个新的 blob ID。如果不加管理这些旧版本的文件会一直占用存储费用积少成多后账单会非常吓人。在产品设计上我建议在 Sui 上保存一个资源清单对象里面用版本号字段映射到 blob ID之后每次更新只需要修改这个对象。同时要有一个清理机制超出保留周期的历史 blob如果确认不再需要就不要续期让它自然过期。第三存储周期的换算建议提前问自己一个问题这个业务的数据是需要存 1 年还是 3 年Walrus 按 epoch 计费而 epoch 的实际时长是由 Sui 网络共识配置决定的不是固定的天或小时。开发者不要自己去猜一个 epoch 大概是几天然后拍脑袋填数字最稳妥的方式是看当前网络的 epoch 时长再根据业务需要的实际天数去换算。有一个群友因为这个吃了亏他以为一个 epoch 是 3 天结果一查实际是 5 天预算是按 3 天算的最后到期时间比他预期晚了快一倍费用也跟着上去了。第四SDK 的版本兼容性需要注意。Walrus 主网切换时那段时间 SDK 的版本更新比较频繁我们项目里同时用了旧版 TS SDK 和新的 HTTP API一度出现了两套接口都能用的混乱期。建议你在项目里固定 SDK 版本并且部署之前回归测试一下上传和读取链路避免线上接口突然不可用。坦率地说Walrus 在 2025 年给我的整体感觉是它已经不再是某个区块链生态的附属品而是一个有独立技术价值和应用场景的去中心化存储基础设施。它在解决存储可用性问题上的工程取舍、在和 Sui 的组合中形成的开发体验以及在经济模型上对节点和用户责任的划分都是这一年里值得持续跟踪和观察的方向。对于做应用的人来说现在已经是把存储方案从临时顶一顶切换到认真考虑 Walrus的时候了。