我们从 Wave 2 中学到了很多,未来将发布一个由三部分组成的博客系列来回顾 Wave 2 中的所有内容。第一篇博客涵盖网络方面,而接下来的文章将更深入地讨论代币经济学和 Frenemies game。
统计快照
在 Wave 2 期间,社区在三周,33 个 epoch 的测试中共同创造了多项新记录。
- 超过 7000 个节点连接到 41 个验证器
- 169 万个地址
- 3650 万笔交易(比 Wave 1 增长 1.6 倍)
- 324 万枚 NFT
- 发布了 118,614 份合约(比 Wave 1 增长了 45 倍)
- 质押 134 万枚 SUI
- 处理了 735 万次质押操作
- 观察到 67 次 TPS 峰值
- 与 1 月份的前三周相比,Sui 钱包 DAU 在 Wave 2 期间增长了 2.2 倍,达到 17.1 万,Sui 钱包的安装量增长了 3 倍以上,达到 33.3 万
- Sui 区块浏览器拥有 100 万页面浏览量和 57.1 万独立访问者,创下历史新高
- Sui Discord社区拥有超过 60 万名成员,使其成为世界上最大的 web3 社区之一
- Sui 的系统对象位居榜首,处理了超过 730 万笔与质押相关的交易。
- Frenemies game位居第二,在短短五天的游戏时间内就完成了超过 350 万笔交易。
- 第三个最活跃的智能合约是 8192 game,合约为 0x137aebf47cd16956b68633b6f6f00a992d87d9c6,处理了超过 200 万笔交易。
- 第四活跃的智能合约是Sui Capys,合约为 0x4c10b61966a34d3bb5c8a8f063e6b7445fc41f93,处理了 160 万笔交易。
这些新记录和网络活动水平使我们可以确定重要的软件更新,并进一步与验证者和节点运营商社区合作提高我们的运营能力。
值得关注的网络更新
与 Wave 1 类似,Wave 2 旨在发现 Sui 基础设施上需要改进的方面。
处理大型消息或交易
由于 Wave 2 专注于质押,网络经历了很多的质押和取消质押交易,这帮助我们提高了处理大型网络消息和交易的能力。特别是,每个未决的质押委托和取消委托交易都会在 epoch change 期间生成一个事件。这会影响 epoch change 交易的交易大小,因为每个生成的事件都是交易效果的一部分。在 Wave 2 中,我们在一个 epoch 中看到了最多 23 万次质押操作,因此该 epoch change 的交易效应变得非常大。
这些超大交易会产生许多问题。如果 epoch change 交易效果变得太大而无法通过网络下载,epoch change 将失败。如果交易影响大于最大 JSON RPC 响应,则无法检索交易。任何尝试加载如此大的交易的应用程序(例如 Explorer)都可能有崩溃的风险。如此大的交易在计算上也可能过于昂贵,以至于网络无法处理。在 Wave 2 期间,我们的团队不得不提升了一些紧急限制,以保持网络在处理大量交易时正常运行。
针对以上情况,我们加快了对对象(object)、包(package)和各种交易数据(输入参数、交易效果、事件)的保护性大小限制的添加。这些限制将有助于确保存储、网络和计算资源不会被主网上的超大交易所淹没。
更稳健地处理交易的类型参数输入
2 月 1 日,我们发现了一个错误,如果将 Move 模块指定为类型参数中的交易输入,则交易处理逻辑无法正确验证 Move 模块的依赖项(即该类型所属的模块是否已发布)。由于 Move 包发布是通过拜占庭一致性广播快速路径进行的,因此某些验证器可能会先于其他验证器了解已发布的 Move 模块,并且可能不同意在类型参数中使用此模块的交易的有效性。一个这样的交易阻止了系统形成下一个检查点,结果导致许多全节点停止以及验证器分叉网络。这是 2 月 1 日凌晨 Wave 2 中断的主要原因。
为了在存在类型参数中输入模块无效的已提交交易的情况下保持测试网运行,我们的团队执行了一些紧急修复:
- 始终检查类型参数的模块是否已发布;
- 允许提交的无效交易通过失败完成执行;
- 防止提交具有未发布类型参数的进一步交易 。
我们在 Sui 的代码库中添加了这两个错误的修复方案:修复输入对象生成 #7940。
Narwhal 共识机制延迟改进
与 Wave 1 类似,测试网 Wave 2 提供了可以进一步测试具有 41 个去中心化验证器的 Narwhal 共识的宝贵机会。在 Wave 2 期间,我们借此机会进行了几项共识的延迟减少优化(向两个验证者并行提交共识、并行证书验证、min_header_delay 参数、一秒的 min_header_delay)。我们不断迭代性能并将很快推出更多优化计划。
值得注意的开发者经验教训
虽然确保网络的稳定性是当务之急,但我们的长期目标是让 Sui 成为首屈一指的智能合约开发者平台,开发者可以基于 Sui 为 Web3.x 创造最佳的体验。为此,我们还在 Wave 2 期间关注了开发人员和用户的摩擦点
代币管理
在 Wave 2 期间,有几个因素使用户有可能遇到代币管理问题。这些问题通常表现为 Gas 费用不足的错误,或者在用户似乎持有足够的 SUI 余额进行交易时出现灰色的质押按钮。
因为 Validator Game 在网络上的活跃,参考 Gas 价格可能会波动,并且在每个 epoch 之间都有比正常情况更大的增长。高 Gas 价格的波动可能会使用户持有的单一代币价值不够用来支付 Gas 费用。其次,初始参考 Gas 价格设置的比 Devnet 更高,这样用户持有多种代币的可能性更小,用完币的速度也更快。最后,质押操作本质上涉及用户将其现有 SUI 余额委托给一个或多个验证器。然而,用户持有的 SUI 的布局可能并不总是与他们预期的质押操作相匹配。
我们在 Wave 2 期间进行了一些更改以缓解这种情况:
- 我们在高参考 Gas 价格期间提高了默认 faucet 数量;
- 我们已解决 Sui 客户端选择大于 gas_budget 而不是 gas_budget * gas_price 的 Gas 对象的 SDK bug;
- 为 Sui 钱包质押添加了基本代币管理。其中,对于每个质押操作,我们使用 paySui 交易构建了分别用于质押和支付 Gas 的模块。
- 我们计划很快支持可编程交易,这将简化应用程序的代币管理。
每个测试网 Wave 都是紧张和兴奋的结合。我们与 Sui 社区的每个人合作,有意将网络的质押能力推向极限,并本着这种精神在测试网 Wave 2 期间成功地加强了 Sui。
我们非常感谢社区的积极参与,这有助于产生高负载并发现问题。我们的下一个里程碑是为开发者社区启动一个永久性测试网,该测试网将不再是临时性的,我们期待届时进一步合作。