TON 分片优化
架构基础知识
TON 可以并行处理无数个事务。这种功能基于无限分片范式,这意味着一旦一组验证器的负载接近其吞吐量极限,就会被分割(分片)。然后,两组验证器独立并行处理这些负载。这些拆分是确定发生的,交易是否由特定组处理取决于与交易相关的合约地址。彼此相近(共享相同前缀)的地址将在同一个分片中处理。
当信息从一个合约发送到另一个合约时,有两种可能:一种是两个合约都在同一个分片中,另一种是两个合约在不同的分片中。在前一种情况下,当前组已经拥有所有必要的数据,可以立 即处理信息。在后一种情况下,信息必须从一个组路由到另一个组。为避免信息丢失或重复处理,需要进行适当的核算。具体做法是在主链区块中注册发送者分片的传出信息队列,然后接收者分片必须明确确认它已处理了该队列。这样的开销使得跨分片消息传递的速度变慢;在发送消息的区块和接收消息的区块之间至少需要一个主链区块。这种延迟通常约为 12-13 秒。
由于一个账户的交易总是在一个分片中处理,因此单个账户的每秒交易速度(TPS)是有限的。这意味着,在为新的大规模协议开发架构时,应尽量避免中心点。此外,如果一连串的交易遵循相同的路径,也不会因为分片而得到更快的处理速度:链中每个合约的 TPS 限制相同,但由于交付延迟,整个链的处理时间会更长。
在大规模系统中,延迟和吞吐量之间的权衡是区分优秀协议和卓越协议的关键。
要分片还是不要分片
为了改善用户体验和处理时间,协议需要了解其系统中哪些部分可以并行处理,因此应该分片以提高吞吐量,哪些部分是严格按顺序处理的,因此如果放在一个分片中,会降低延迟。
jetton 就是吞吐量优化的一个很好的例子。由于从 A 到 B 和从 C 到 D 的转账互不依赖,因此可以并行处理。通过将所有 Jetton-wallet 随机、均匀地分布在地址空间中,我们可以在区块链上实现负载的完美分布,并在适当延迟的情况下实现每秒数百次(未来可达数千次)的吞吐量。
相反,如果另一个处理 jetton 的智能合约(比方说合约 A)在收到 jetton X 时做了 什么(而 A 的 jetton 钱包合约是 B),将合约 A 及其钱包 B 放在不同的分片中并不会提高吞吐量。事实上,每笔转账都会经过相同的地址链,每个地址都会成为瓶颈。在这种情况下,最好将 A 和 B 放在同一个分片中,从而缩短整个链的时间,以改善延迟。
智能合约开发人员的实用结论
如果你有一个执行业务逻辑的智能合约,可以考虑部署多个这样的合约,以享受 TON 的并行性。如果无法做到这一点,而且您的智能合约与一组预定义的其他智能合约(比方说 jetton-wallets )交互,则可以考虑将它们放在同一个分片中。这通常可以在链外完成(通过暴力破解特定合约地址,使所有需要的 jetton-wallet 都有相邻地址),有时链上暴力破解也是可以接受的。
即将到来的节点和网络性能改进有望提高分片的吞吐量并减少交付延迟,但同时用户数量也会增加。随着越来越多的用户加入,分片优化将变得越来越重要。最终,这将成为大规模应用的一个决定性因素:用户会选择对他们来说最方便的应用,也就是延迟较低的应用。因此,不要再犹豫了,从整体网络改善的角度出发,对应用程序进行分片优化吧。现在就做!在很多情况下,这甚至比 gas 优化更重要。