测试网2回顾--网络学习

Testnet Wave 2 成功结束，帮助我们实现了在Sui 上进行定注操作的目标。网络上的大量活动让我们更有信心，我们在迈向 Mainnet 的道路上又迈出了关键的一步。我们要向所有参与并帮助我们创建更好的Sui 的人们表示衷心的感谢！

由于从第 2 波中学习到了大量令人难以置信的知识，我们将发表三篇系列博客来回顾第 2 波的所有内容。第一篇博客涉及网络学习，接下来的文章将更深入地讨论代币经济和 "敌人 "游戏。

统计快照

在第二波中，社区在为期三周的活动中共同创造了多个新纪录，跨越了 33 个纪元。

• 7,000 多个节点与 41 个验证器连接
• 169 万个地址
• 3,650 万笔交易（比第 1 波增长 1.6 倍）
• 324 万个 NFT
• 发布了 118 614 个软件包（比第一波增加了 45 倍）
• 134 万SUI 押注
• 处理了 735 万笔定标业务
• 观测到 67 个 TPS 峰值
• Sui 钱包 DAU 在第 2 波期间增长了 2.2 倍，达到 17.1 万（与 1 月份的前三周相比），Sui 钱包安装量增长了 3 倍多，达到 33.3 万（与 1 月份的前三周相比）。
• Sui Explorer 的页面浏览量达到 100 万，独立访客数达到 57.1 万，再创历史新高
• 在 Sui Discord社区，使其成为世界上最大的 web3 社区之一

特别是，在第二波期间，四个智能合约收到的交易远远超过 100 万笔，总共占第二波所有交易的约 40%：

1. Sui其系统对象位居榜首，处理了超过 730 万次与认股相关的交易。
2. 敌人 敌人》游戏排名第二，在短短五天的游戏时间里，交易量超过 350 万。
3. 第三个最活跃的智能合约是 8192 游戏，其对象 ID 为 0x137aebf47cd16956b68633b6f6f00a992d87d9c6，处理的交易量刚刚超过 200 万笔。
4. 第四大活跃智能合约是 Sui 智能合约，对象 ID 0x4c10b61966a34d3bb5c8a8f063e6b7445fc41f93，交易量为 160 万次。

特别祝贺 8192社区项目的交易量突破一百万大关！我们还要感谢 Suiscan 社区项目提供第 2 波分析。

这些新的记录和新的活动水平使我们有机会确定实质性的软件改进措施，并与我们的验证人员和节点操作员社区一起，使我们的操作能力进一步成熟。

值得注意的Sui 网络学习

与第 1 波类似，第 2 波旨在强调和发现Sui基础设施的改进之处。

处理过大的报文或事务

由于第 2 波的重点是定标，网络经历了大量的定标和取消定标交易，这帮助我们突破了处理大型网络信息和交易的极限。特别是，每个悬而未决的股权委托和解除委托事务都会在纪元变更期间产生一个事件。由于每个生成的事件都是交易效果的一部分，这就会影响纪元变更交易的交易规模。在第 2 波中，我们在一个纪元中最多进行了 230,000 次投注操作，因此，这个纪元变化的交易影响变得非常大。

这些超大事务会带来一系列问题。如果时间变更的事务影响太大，无法通过网络下载，时间变更就会失败。如果事务效果大于最大 JSON RPC 响应，则无法检索事务。任何试图加载如此大事务的应用程序（如资源管理器）都可能面临崩溃的风险。对于网络来说，处理如此大的事务也可能会导致计算成本过高。在第 2 次浪潮中，我们的团队不得不多次紧急增加限制，以保证网络在处理大事务时的运行。

有了这些发现，我们加快了为对象、包和各种事务数据（输入参数、事务效果、事件）增加保护性大小限制的步伐。这些限制将有助于确保 Mainnet 的存储、网络和计算资源不会被过大的交易压垮。

更稳健地处理事务的类型参数输入

2 月 1 日，我们发现了一个错误，即如果在类型参数中将Move 模块指定为事务输入，则事务处理逻辑不会正确验证Move 模块的依赖关系（即类型所属模块是否已发布）。由于Move 软件包的发布是通过拜占庭一致广播快速通道进行的，因此一些验证者可能会比其他验证者更早发现已发布的Move 模块，并对在类型参数中使用该模块的事务的有效性产生分歧。有一次，这样的事务阻止了系统形成下一个检查点，结果导致许多全节点停止，验证器分叉（或分歧）。这是 2 月 1 日凌晨 Testnet Wave 2 中断的主要原因。

为了在类型参数中输入模块无效的已提交事务中保持 Testnet 的正常运行，我们的团队进行了一系列紧急修复：

• 始终检查类型参数的模块是否已发布
• 允许已提交的无效事务通过失败来完成执行
• 防止提交更多带有未发布类型参数的事务

我们发现了第二个错误，即事务输入检查逻辑不拒绝将不属于Move 模块的对象 ID 作为输入插入类型参数。由于类型参数必须是Move 模块，因此事务永远无法完成，下一个检查点也无法形成。我们的团队不得不再次添加紧急修复措施，迫使有问题的事务因执行错误而失败，以便恢复网络。

Sui 软件源中添加了对这两个错误的长期修复，具体如下 修复输入对象生成 #7940.

Narwhal 共识延迟改进

与第 1 波类似，Testnet 第 2 波提供了一个宝贵的机会，让我们通过 41 个分散验证器进一步了解 Narwhal 共识的特点。在第 2 轮测试中，我们利用这个机会进行了多项降低共识延迟的优化（例如向两个验证器并行提交共识, 并行证书验证, 最小头文件延迟参数, 一秒 min_header_delay).我们正在不断迭代性能，并有更多的 优化计划。

值得注意的开发人员经验学习

虽然确保网络的稳定性是我们的首要任务，但我们的长期目标是让Sui 成为首屈一指的智能合约开发者平台，让构建者能够为 web3 创造最佳体验。为此，我们还在第 2 波期间监控了开发者和用户的摩擦点。

硬币管理

在第二波中，有几个因素使得用户更容易遇到硬币管理问题。这些问题通常表现为汽油费不足的错误，或者当用户似乎持有足够的SUI 余额进行交易时，出现灰色的定投按钮。

由于 验证器游戏由于网络上的游戏非常活跃，参考天然气价格有可能出现波动，并且在不同的时间段内出现比正常情况下更大的涨幅。高气价的波动会降低用户持有足够高价值的单个硬币来支付气费的可能性。其次，初始参考瓦斯价格被设定为比 Devnet 更高的数字，这使得用户不太可能拥有多个硬币，而更快地耗尽硬币。最后，定投操作的本质是用户将其现有的SUI 余额委托给一个或多个验证者。然而，用户SUI 余额的币种布局可能并不总是与他们打算进行的定投操作相匹配。

在第二波期间进行了一些改革，以缓解这种情况：

• 在参考气价较高期间，我们提高了默认龙头气量
• 我们 解决了SDK 中的一个错误，即Sui 客户端选择的气体对象大于 gas_budget，而不是 gas_budget * gas_price
• 为Sui 钱包委托添加了基本的硬币管理。在该系统中，每次委托操作都会使用 paySui 交易来构建一个用于委托的委托币和一个为委托提供资金的气体币。

我们计划很快支持 可编程交易，这将简化应用程序的硬币管理。敬请期待！

更多 Testnet 成功案例

每一次 Testnet 浪潮都会带来恐惧和兴奋。我们与Sui 社区的每个人合作，有意将网络的投注能力推向极限，并本着这种精神在 Testnet Wave 2 期间成功地加强了Sui 。

我们要衷心感谢社区的积极参与，这有助于产生负载和发现问题。我们的下一个里程碑是为构建者社区推出一个永久性的测试网络，该网络将不再是短暂的，我们期待着届时的进一步合作。

敬请期待另外两篇介绍 Testnet 第二波学习成果的文章！