来源:隋网

编译:隋世界道

2月28日，隋网发表了隋Testnet Wave 2的总结。在此期间，超过7000个节点连接到41个验证器，处理了3650万笔交易，比Wave 1高出1.6倍。共质押324万无抵押贷款和134万无抵押贷款，已办理质押业务735万笔。

今天隋网发表了隋Testnet Wave 2的总结。在此期间，超过7000个节点连接到41个验证器，处理了3650万笔交易，比Wave 1高出1.6倍。共质押324万无抵押贷款和134万无抵押贷款，已办理质押业务735万笔。

Testnet Wave 2顺利完成，有助于实现在Sui网上打桩作业的目标。Wave 2上的大量活动让隋网对其主网之旅更加有信心。第一篇回顾文章主要介绍在线学习的部分，接下来会重点介绍代币经济学和友敌博弈。

数据快照在wave2的三周许可期内，社区创造了许多新的记录，跨越了33个时代:

1)超过7000个节点连接到41个验证器；

2)169万个地址；

3)3650万笔交易(比wave1高1.6倍)

4)324万非功能性食物

5)发布了118，614个包(比wave1多45倍)。

6)认捐134万隋

7)办理质押操作735万笔。

8)观察到67个峰值TPS。

9)隋钱包DAU在wave2期间增长2.2倍，达到171K(与1月前三周相比)，隋钱包安装量增长超过3倍，达到333K(与1月前三周相比)。

10)Sui Explorer浏览量创历史新高，总浏览量100万，独立访客57.1万。

11)Sui Discord社区拥有超过600，000名成员，是全球最大的web3社区之一。

特别是，四个智能合约在wave2期间收到了超过100万笔交易，占wave2中所有交易的40%:

1)1)穗的系统对象排名第一，处理质押相关交易730多万笔；

2) Frenemeies排名第二，仅5天就完成超过350万笔交易。

3)第三个活动游戏是8192游戏，其对象ID是

0x 137 aebf 47 CD 16956 b 68633 b 6 f 6 f 00 a 992d 87 d9c 6

处理了200多万笔交易。

4)第四个活跃的是隋Capys。

对象ID

0x4c 10b 61966 a 34d 3 bb 5 c 8 a 8 f 063 e6b 7445 fc 41 f 93

交易量160万。

这些新的记录和新的活动水平使我们有机会确定主要的软件改进，并进一步完善我们的操作能力以及我们的验证人员和节点操作员社区。

SUI网络值得注意的网络改进与wave1类似，旨在强调和发现Sui基础设施的改进。

处理太大的消息或事务。

由于Wave 2侧重于质押，网络经历了高额质押和质押解除交易，这有助于我们突破处理大规模网络消息和交易的界限。特别地，每个未决的股权委托和取消交易将在纪元改变期间产生一个交易。这将影响epoch来改变事务的事务大小，因为每个生成的事件都是事务效果的一部分。在Wave 2中，我们看到一个纪元最多23万步操作，所以这个纪元变化的交易效应变得非常大。

这些巨额交易会引发许多问题。如果epoch change的事务效果变得太大而无法下载，epoch change就会失败。如果事务影响大于RPC响应的最大值，则无法检索事务。任何试图加载如此大的事务的应用程序(如Explorer)都有崩溃的风险。如此大的交易也可能太昂贵而无法由网络来处理。在wave2期间，当处理大量事务时，我们的团队不得不应用一些紧急限制来保持网络正常运行。

由于这些发现，我们加快了对对象、包和各种事务数据(输入参数、事务影响、事件)的保护性大小限制的添加。这些限制将有助于确保存储、网络和计算资源不会被主网络上的巨大交换所淹没。

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

2月1日，我们发现了一个BUG。如果在类型参数中将移动模块指定为事务输入，事务处理逻辑将不会验证移动模块的依赖性(即，该类型所属的模块是否已发布)。因为Move包是通过Byzantine uniform broadcast express path发布的，所以一些验证者可能比其他人更早知道发布的Move模块，并且可能不同意在type参数中使用该模块的事务的有效性。这样的事务阻止了系统形成下一个检查点，导致许多完整节点的停止和验证者的分叉。这是2月1日凌晨Testnet Wave 2中断的主要原因。

为了在类型参数中有无效输入模块的提交事务时保持Testnet继续运行，我们的团队进行了一些紧急修复:

1)经常检查类型参数的模块是否已经发布；

2)允许提交的无效交易失败执行；

3)防止提交具有未发布类型参数的进一步交易。

我们发现了第二个BUG，即事务输入检查逻辑并不拒绝在类型参数中插入非移动模块的对象id作为输入。因为type参数必须是Move模块，所以事务永远无法完成，也无法形成下一个检查点。类似地，为了恢复网络，我们的团队不得不添加紧急修复，以迫使有问题的事务由于执行错误而失败。

对这两个错误的长期修复已作为修复输入对象生成#7940添加到Sui存储库中。

改善独角鲸共识延迟

与Wave 1类似，Testnet Wave 2通过41个分散的验证者提供了一个进一步描述Narwhal共识的宝贵机会。在Wave 2期间，我们借此机会做了几次共识延迟降低优化(并行向两个验证器提交共识，并行证书验证，min_header_delay参数，min_header_delay参数一秒)。我们不断迭代性能，并计划很快进行更多的优化。

值得注意的开发者经验和教训虽然保证网络的稳定性迫在眉睫，但我们的长远目标是将Sui打造成智能合约开发者的领先平台，开发者可以从中获得web3的最佳创作体验。为此，我们还监测了Wave 2期间开发者和用户的摩擦点。

令牌管理

在wave2中，有几个因素使用户更容易遇到令牌管理问题。当用户似乎有足够的SUI余额进行交易时，这些问题通常表现为汽油费不足的错误或灰色承诺按钮。

由于网络上活跃的验证者博弈，参考气价可能出现波动，从一个纪元到另一个纪元的涨幅大于正常水平。高气价的波动可能使用户无法用足够高价值的代币支付气费。其次，初始参考气价定得比Devnet高，所以用户不太可能持有更多硬币，更快用完硬币。最后，抵押操作实质上包括用户将其现有的SUI余额委托给一个或多个验证者。然而，用户的SUI余额的代币布局可能不总是与他们预期的抵押操作相匹配。

在wave2期间，进行了一些更改来缓解这种情况:

1)当参考气体的价格高时，我们增加了默认的水龙头数量；

2)我们解决了SDK中的一个错误，就是Sui客户端选择了一个大于gas_budget的GAS对象，而不是gas_budget * gas_price。

Sui钱包质押增加了基础令牌管理，其中对于每一笔质押操作，使用paySui交易构建委托质押令牌和融资委托加油券。

不久我们计划支持可编程事务，这将简化应用程序的令牌管理，敬请关注！

Testnet Wave比较成功。每一次Testnet Wave都是恐惧与兴奋的结合，我们与Sui社区合作，将网络的认捐能力推向极限，本着这种精神，我们在Testnet Wave 2期间成功强化了Sui。

我们非常感谢社区的参与，这有助于生成负载和发现问题。我们的下一个里程碑是为建设社区启动一个永久性的测试网络，这将不再是临时的，我们期待着进一步的合作。

温馨提示：注：内容来源均采集于互联网，不要轻信任何，后果自负，本站不承担任何责任。若本站收录的信息无意侵犯了贵司版权，请给我们来信，我们会及时处理和回复。