在聊区块链技术tps这个话题的时候, 大家得面对一个现实的问题, 就是, 绝大多数项目的体验瓶颈在哪里, 它其实不在共识层那边, 而是在共识操作之前和之后那几段数据处理的地方。
区块链tps瓶颈在哪
我遇到过的最大的麻烦情况是, 有一个关于支付的业务场景它要求每秒要处理三千次操作, 但是底下的系统运行能力只达到了两千次。
经过了两个星期的仔细检查和寻找原因, 最后发现交易验证、状态更新以及P2P广播这三部分环节才是真正的阻碍所在, 也就是所谓的瓶颈所在, 而共识机制本身并不是那个最严重拖后腿的因素。
因为网络带宽被完全占满, 导致节点之间的同步延迟变得很高, 每一笔业务都要再多等多几十毫秒, 把这些时间加在一起累积起来, 就会引发非常严重的灾难后果。
分片能缓解但治不了根。切八片理论翻倍，跨片交易还是得全网确认，纸面数字一压测就露馅。
区块链tps怎么提
实际可行的操作路径只有三个方向, 第一个是在底层实现并行化处理, 具体的做法是让独立交易进行并且的验签工作；第二个方向是把rollup技术部署在中间层这种层次上, 核心目的是将计算任务迁移到区块链外部去执行, 然后在链上面仅仅保留数据的摘要信息；第三个选择是直白地承认第二层架构的存在合理性, 规定第一层区块链只负责最最终的结算功能, 而所有的业务流程和规则逻辑全部放置在第二层里面去运行。
我见过那种项目, 它是把三种东西叠起来一起用的, 具体来说是把L1结算、L2跑业务和批量签名压缩这几种方式结合起来用, 它的性能可以稳定在5000tps以上。这就说明了不存在什么银弹一样的神奇解决方案, 要想解决问题, 只能靠打出组合拳这种方式。
tps这种东西, 往简单了说, 它就是指的是用户需要多等那么一秒还是少等那么一秒的情况。大家千万不要把它仅仅当成是一个拿来炫耀技术实力的指标, 而是应该把它当作一个关系到产品体验的实际事项来严格地、细致地去考量和打磨。
