#Walrus $WAL @Walrus 🦭/acc 拿数据说话：Walrus 测试网性能实测深度解读

#Performance #Testnet #Latency #Throughput
⏱ 阅读时间：5 分钟
📖 核心参考：Section 7, Figure 8, Figure 11

引言
白皮书吹得再好，不如实测跑一跑。Mysten Labs 团队在白皮书第 7 章披露了 Walrus 测试网（Testnet）的真实性能数据。这些数据是在 105 个全球分布的节点上测得的，具有很高的参考价值。我们来逐一解读这些关键指标。

1. 延迟（Latency）：读取快于写入
对于用户体验来说，读取速度至关重要。测试数据显示，Walrus 的读取延迟极低。
对于小于 100MB 的文件，读取通常在几秒内完成。而写入延迟相对较高，这是因为写入需要经过编码、分发、收集签名并提交到 Sui 链上。

"The graph shows that read latency remains low, even for large blobs. For small blobs (less than 20 MB), the latency stays below 15 seconds."

对于大文件（如 130MB），延迟主要受限于网络带宽，呈现线性增长。这说明系统的瓶颈在于物理网络，而非协议本身的计算开销，这是一个积极的信号。

2. 吞吐量（Throughput）：单客户端的极限
测试显示，单个客户端的写入吞吐量在大约 18 MB/s 处达到瓶颈。
为什么是 18 MB/s？白皮书解释说，这并非 Sui 的限制，而是单次上传交互的开销。

"Write throughput plateaus around 18 MB/s because of the need to interact with the blockchain and the storage nodes multiple times."

但这并不意味着系统总吞吐量低。用户可以通过并行上传（Fan-out pattern）来轻松突破这一限制。这意味着 Walrus 支持高并发的大规模数据吞吐。

3. 可扩展性（Scalability）：节点越多，容量越大
最令人兴奋的数据是关于系统容量的扩展性。图 12 显示，随着节点数量增加，系统总容量呈线性增长。在测试网阶段，仅 105 个节点就实现了超过 5 PB 的存储能力。

"Figure 12 illustrates how Walrus’s total storage capacity scales with the committee size. This result supports our final claim C5: the system’s capacity grows proportionally with the number of storage nodes."

结语
实测数据证明，Walrus 不是“PPT 项目”。它在真实的、去中心化的广域网环境中表现出了工业级的性能。对于想要构建去中心化 YouTube 或 Instagram 的开发者来说，这些数据是一剂强心针。

互动提问： 18 MB/s 的单线程写入速度对于目前的 Web3 应用够用吗？你认为瓶颈主要会在哪里？