比特币的tps 百万TPS是神工程？

白话区块链

从入门到精通，看我！

非技术人员不知道TPS是什么不要紧，但是如果把TPS作为投资公链的重要指标之一，却不知道TPS是什么，那就真的很尴尬了！

TPS的定义

TPS，通俗的定义是“系统的吞吐量”，更专业的解释是“系统每秒可以处理的业务数”。 估计大部分人的理解到这里就结束了。 然而，这是非常肤浅的认识。 防止欺骗、证明价值几乎没有意义，甚至有负面作用！

知道了TPS的定义，怎么会有负作用，因为“一瓶不满，半瓶砰！”，与其求深解，不如虔诚一知半解！ 当我们从表面上知道TPS的定义时，我们直观的感觉是TPS越大越好。 这非常合乎逻辑，但事实并非如此！

首先，我必须说，在计算机领域，TPS其实并不是一个原生的概念。 原生概念是什么？ 是底层客观存在的数据指标，比如磁盘速度、网速、CPU赫兹、进程线程数等。TPS其实是一个人为的概念，是几个底层数据的综合计算结果，以及为在宏观层面衡量某些特定系统而创建的概念。

以上解释有点虚构。 我们举一个大家熟悉的例子，比如比特币。

在比特币业务中，TPS的定义可以更具体地解释为：“比特币网络每秒可以处理的交易数量！” 但是，在这个定义中，真正原始的概念只是“交易”，而TPS，是一段时间内的交易总数除以这段时间的总秒数得到的指标，代表平均数每秒可以处理的事务数。 请注意，这是平均数，并非真正处理每一秒交易！

那么问题来了，既然“一段时间”是我们人为截取的，那我们在比特币网络中截取了多少呢？ 一般来说，取最小的模块就是一个区块的打包间隔，大概是10分钟左右。 注意第二个原创概念出来了，就是出块时间“10分钟”！

OK，如果我们以10分钟为标准时间段，每个打包好的区块包含4000条交易数据，那么TPS是多少呢？ 4000 / (10*60) = 6.67，没错，这大概就是比特币网络的TPS，平均每秒约6笔交易，每10分钟才处理一次！

至此可以看到，在比特币商业模型中，TPS其实依赖于三个底层概念：区块生成时间、每个区块包含的交易数量、拦截时间段。

一个极端的例子，如果我们截取1分钟，我们会发现比特币网络的TPS有10次有9次是0，因为这段时间没有出块，但是如果我们只截取第十个包含的块来看出块时间1分钟，我们的TPS高达66.67（4000 / 60），这绝对是不合理的！ 可见，我们人为设置参数的合理性取决于原始参数。 原始参数才是我们真正应该关注的。 人为创造的参数是为人服务的。 如果人性本善，就是合理的，如果人性本恶，这个参数就可能用来骗人！

因此，虽然TPS的定义是“每秒”处理的交易数量，但在现实世界中，无论是比特币还是其他大部分区块链网络，除非每秒都处理交易，否则不可能真正做到秒级处理业务. 每秒都在生成块！

那么问题又来了。 既然我们了解了影响比特币网络TPS的原生参数中，最重要的指标有两个，“一个区块包含的交易数量”和“一个区块的出块时间”，那我们何不增加交易数量？ ，还是减少出块时间来提高TPS？

如何提高TPS

先说增加一个区块的交易数量。 影响这个数字的重要指标会引出另一个重要的原生参数，就是“区块大小”。 在比特币中，一个区块的大小被限制在1M以内，一笔交易数据的大小也是固定的，所以一个区块所能容纳的交易数上限也是固定的。

这里肯定有人会问，增加块大小不就完了吗？ 需要注意的是，增加块的大小意味着增加对硬盘和带宽的需求。 这个问题就像我在公司做程序架构师的时候，老大说，优化系统，然后我直接回答：不用优化。 ，只要买个好一点的服务器，用个好一点的机房和网络就OK了！ 你猜老板听到我的话会有什么反应？

一个优秀的程序员应该思考如何在有限的条件下，通过算法和架构来优化性能，保证可扩展性，而不是一味地寄希望于硬件的性能和数量，除非真的没有别的办法。 还是时间真的太赶了！

那么比特币的TPS优化真的已经到了没有办法的地步，或者是没有时间去研究了？ 明显不是！ 既然从程序员的角度来看增加块大小不是最好的选择，那么减少块生成时间可以吗？ 1秒直接出块岂不妙哉！ ？

没那么简单。 事实上，区块链每个区块所包含的数据不仅是交易数据，还有格式数据。 这些数据一般位于块数据包的头部，用于各种标识和安全验证。 但是如果区块生成的太快，很可能会导致每个区块中的数据都被填满，甚至出现空块。 这些块的头部数据一个字节不多，其实是对系统的一种浪费，IO压力也大。 会太大。 而且爆块速度过快也会影响“共识机制”，会大大增加达成共识的难度，增加系统被攻破的风险。 不过由于我对底层的这部分还没有完全研究和理解，所以暂时不说了。

既然仅靠调整参数很难达到满意的效果，又不想轻易搞砸硬件，破坏长期的可扩展性，作为程序架构师，脑子里只剩下一个词：重构！ 于是比特币的tps，“闪电网络”应运而生！ 关于闪电网络，不是本文的重点，也不在其中。 你只需要知道，这是从底层架构上做的一次大手术，会大大提高TPS，但不会带来我前面提到的调整参数带来的问题。 但是，任何架构都有优点和缺点，闪电网络也有。 问题在此不展开。

基于以上科普，我们来看两个要点：

首先，TPS是一个人为定义的弹性参数，其合理性在于选取原生参数的合理性。 比特币的网络相对简单，参数很少。 但在一个复杂的网络中，比如游戏服务器拓扑，一般包括：账号服务器、各区服务器组、跨服副本或战场服务器、数据库服务器、WEB服务器等。 这些服务器共同组成了一个游戏的完整系统，涉及的参数非常多，任何一个参数都可能影响到整个系统的TPS。 但是在游戏中，我们往往不谈TPS这个概念，为什么呢？ 因为参数太多了，你说提高了系统TPS，但是我不知道你优化到哪里去了，我也不知道你说的是什么！

因此，我们需要在系统整体的TPS上抽象出各个具体子系统的TPS，并规范相应的名词。 在我上面提到的各种游戏服务器中，猜猜哪一组服务器压力最大？ 就是账号服务器，因为账号服务器会面对所有玩家的请求，尤其是服务器刚重启后，瞬间就会涌入大量玩家，直接把你的系统堵死了，那你还得继续重启，然后再挂掉Drop，死循环！ 此时的TPS称为“同时登录”。

我们可以做些什么来解决这个问题？ 当玩家很多的时候，现有的硬件是不可能满足无限并发登录的，所以业界发明了一个方法：“排队登录！” 是的，这就是让很多玩家都心疼的规则！

所谓“排队登录”，就是限制某个时间进入服务器的玩家数量，比如每10分钟只能有4000名玩家进入？ 我的上帝！ 这不就是区块链的出块规则吗？ 当然，在真实情况下，游戏的登录TPS远高于这个数据。 刚才的参数例子只是为了让大家容易联想到比特币网络。

而一个游戏系统的整体TPS是什么概念呢？ 我们可以认为是“每秒支持的在线用户数”。 与比特币相比，这个TPS受影响太大了。 比如刚才说的登录能力，如果玩家连登录都不能登录，TPS就是0！ 然后是每个区的服务器容量，一般是几千人； 数据库IO容量是个大坑； 内存和CPU使用率的高低反映了程序架构的高低等等。 我说这些只是核心参数。 一个参数没做好比特币的tps，系统整体的TPS就会明显下降。

可见，为了最大化所有玩家的体验，目前的商业游戏采用了非常复杂的服务器拓扑结构，相对简单的区块链结构肯定无法满足当前主流游戏的性能需求。

那为什么区块链不让它更复杂，让TPS更高呢？ 一方面是区块链共识机制的局限性。 另一方面，复杂性通常意味着成本和风险。 可以说，市面上的大部分游戏服务器都经不起攻击。 人们往往从游戏规则和法律方面回避它。 这种攻击并不能使攻击者获得多少收益，而且承担着巨大的法律风险。 但是，在区块链的世界里，没有法律保护，直接和钱挂钩。 我们唯一可以依靠的就是程序。 在这种极端情况下，简单就是美，只有简单才能稳定！

第二，在谈到游戏服务器的拓扑结构时，提到了会有各种各样的服务器，它们之间经常需要相互通信。 帐户信息进入数据库服务器以拉取或更新一些角色数据。 跨服战斗时，副本服务器需要与这些玩家所在的区域服务器通信。

以上所有，我们称之为网络拓扑。 而这一切多半是在局域网中完成的，大家几乎没有延迟感。 40毫秒以内人眼是感觉不到延迟的，局域网内的通信时间几乎可以忽略不计。 即使播放器卡顿，也是服务器网络与播放器家庭网络之间的延迟造成的。

比较特别的是跨服对战。 不同地区的服务器可能不在同一个机房​​。 这个时候为了保持战斗实例的流畅，我们需要将不同地区的玩家数据抓取到一个离大家比较近的服务器上。 每个人都在顺利战斗。 战斗结束后，战斗结果会同步回各自区域的服务器。

相信玩过跨服对战的朋友应该都有过等待“匹配”、等待“玩家进入”的经历。 我们甚至会骂那些进的慢的玩家，因为大家要等他加载进去才能开战。 . 这种体验之所以如此“差”，让人觉得“如此缓慢”，是因为它不是简单的局域网通信，而是通过中央服务器实现的点对点或广域网通信。

人眼可以接受40毫秒的延迟，稍微不可靠的广域网通信会大于这个延迟，而且随着业务和网络拓扑的复杂化（比如电信和网通的通信问题），延迟甚至会增加。 以秒、分记录，但即便如此，与区块链以分钟甚至小时记录的延迟相比，仍然是“丝般顺滑”的体验。

好了，现在我们回到区块链世界。 区块链网络是典型的 P2P WAN 拓扑。 一个数据包的确认需要广域网中的多方通信。 在这样的网络拓扑下，就算真的达到了百万TPS，又有什么用呢？ 就算你运气很好，确认区块的节点距离很近，也绝对不可能达到局域网的速度！ 从肉眼来看，你会看到DAPP端的链上操作，从发送请求到接口响应，会远远超过40毫秒，所以还是会“非常非常”卡顿！ 如果是一般的购买转账行为，勉强还能用，但如果是即时对战游戏，那就真的呵呵了。

验证项目方所说的百万TPS是否属实

综上所述，当我们看到一个号称百万 TPS 的项目时，我们应该：

1、项目方的原始参数是什么？ TPS的计算公式是什么？ 区块间隔是多少？

2、要知道以比特币为代表的POW共识算法是无法支持高TPS的，所以要具体看项目方的共识机制。

3、广域网分布式随机通信绝对不可能超过局域网服务器定点通信的效率。 满足我们现有APP的丝滑体验，我们需要的不是百万TPS，而是区块链重构，什么数据上链，什么数据不上链，精心设计，安全和速度，我们需要采取妥协！ 丝滑的体验是TPS、并发、网络拓扑、安全等综合优化的结果！

4. 在求证的严谨态度下，不要限制自己的想象力。 随着硬件性能的逐步提升，量子计算机、5G网络等基础设置的突破，这些设置都是一些意想不到的技术突破。 或许有一天，区块链不需要太多的拓扑结构重构，就可以拥有丝般顺滑的体验。 我们在互联网时代真的没有经历过这个过程吗？

除了“百万TPS”这个模糊的概念，你还被哪些“假大空”名词弄糊涂了？ 欢迎在留言区分享。 如果您有任何不清楚的区块链概念，请告诉大白。 大白后续会一一为您解答。

- 结尾 -