“高并发”中的“文昌链”

金色财经 view 70629 2022-7-6 09:29

“高并发”中的“文昌链”

背景：6月的并发高峰

6月29日，中国区块链基础设施BSN官方发布了一则数据，其NFT基础设施BSN-DDC单日链上交易总数接近百万次，超过了以太坊单日链上交易数。

BSN-DDC是由多个开放联盟链组成的NFT基础设施，以适应中国监管合规环境的特性塑造着与以太坊开源生态相似的应用多样性。

由边界智能搭建的的文昌链，是目前支持BSN-DDC运行的四条开放联盟链之一，在6月，BSN链上数据爆发的表现中，文昌链链上数据爆发尤为突出。

据边界智能创始人曹恒描述，截止到2022年6月21日19点18分，文昌链上活跃链账户数为645万，以链上数据估算，上线应用近250个，进行测试对接的应用约300个。

而此时链上NFT技术支持的可信数据对象总数为797万。通过历史数据分析，所有可信数据对象中，55%产生于6月，约为442万个。

（至本文发出时，文昌链活跃账户数已过1061万，NFT技术支持可信数据对象1194万。）

文昌链于2021年2月上线，免费稳定试运行一年后，于2022年3月份开始商业化运行，随后文昌链的业务量已开始快速增长，从月度业务量翻倍到6月实现指数级增长。

（可对比数据：开放联盟链的腾讯至信链，2021年6月上线，截止到2022年5月，总用户数超过300万，发行的数字藏品超过500万。）

而伴随着6月业务量飞涨，618前后在并发高峰期，文昌链出现了卡顿、交易排队的情况，区块打包时间最高达到了30秒，有所影响用户体验。

随后，BSN运维团队红枣科技和文昌链技术支持团队边界智能通力合作，在不停服的前提下对系统进行了紧急升级及优化。

调优后，正在以小于4秒的平均出块时间平稳安全地运行。

问题：上链交易缓慢与优化思路

全球公链上的交易堵塞、等待问题很常见。文昌链在高并发情况下出现的此类问题，是区块链在面对商业化应用中必然要面对的。

在传统互联网应用中，平台方可以通过增加计算资源的水平扩展方式和挑战任务并行分配方式来解决，有多大压力，就用多大的计算资源解决。

而在区块链上，尤其是在与公链同样分布式结构的开放联盟链上，其性能的优化、升级需要经历相对复杂的过程。

性能问题公示

文昌链采用开放应用服务模式，支持多元应用生态。经技术团队进行网络性能分析，其问题和解决方案如下：

问题1：接收用户交易的全节点跟共识节点之间的p2p连接不稳定，造成很多交易不能及时进入共识节点参与出块。

解决方案：优化全节点与共识节点之间p2p连接配置参数，提高连接稳定性。

解决状态：已解决

问题2：全网交易量高峰时段，每个新区块包含交易数很多（2000~3000），共识节点在广播和校验每个区块上耗费时间变长，造成出块间隙时间变长（从3秒左右变为30秒左右）；虽然网络整体吞吐量（TPS）增加，但单个交易的上链延迟变长，用户体验到的上链等待时间变长。

解决方案：优化共识算法各阶段超时时间配置参数，提高出块速度。

解决状态：已改善，还在持续优化参数和垂直扩展共识节点性能。

问题3：EVM相关交易因nonce错误而上链失败，需要用户重试。

解决方案：应用修改上链策略，每个发交易的链账户要串行发送交易，确保前一个交易的上链状态确定后再发送下一个交易；若要提高交易并发性能，则可采用多个链账户并行发送交易。

解决状态：已经发布更新的FAQ和代码示例

分析：为何开放联盟链（OPB）调优更为复杂？

开放联盟链（OPB，Open Permissioned Blockchain 又称开放许可链）是结合了公链、联盟链技术优势，能支持非信任环境下的分布式公共账本服务，其可以很好地支持商业级应用的合规需求和良好的应用开发体验。

因此，OPB的调优比公链、联盟链都要复杂许多。

在传统的互联网中心化应用开发中，应用上线前要对数据库进行规划，包括分区，如何给数据表加读写锁，索引等等。应用上线后，中心化数据库的调优可能需要一个月甚至更长的时间，来监控应用访问数据库的模式，针对应用进行进一步的优化。

而相比中心化数据库的调优，开放联盟链的调优难度近乎是其20倍甚至以上。

区块链应用，又称分布式应用。所以有人说区块链则是分布式数据库，但区块链的难度远远超越了分布式数据库。

原因在于分布式数据库的调优，比中心化数据库增加了数据的同步、多阶段提交以保持数据一致性以及网络通讯优化等多方面的复杂步骤。

而区块链相比分布式数据库，除数据同步、保证数据一致性外，还需要保证网络的安全性。

区块链中以众多节点来共同维护可信数据账本。开放区块链需要假定每一个节点都有作恶的可能性（带入错误账本数据、篡改数据等）。因此需要识别作恶数据，并可以通过共识算法，对合法交易进行排序和正确执行，并将结果分布式可信地写入账本。

在这个过程中：

共识算法可以保证分布式节点以block（数据块）方式组成链式数据，并保证当有恶意请求、网络不可靠或者黑客攻击的情况下，算法依然可以准确无误地运行。

共识协议的执行，会产生相比分布式数据库更多的网络通讯，需要协调更多节点的信息以及本地运算结果的全网同步。

在这样复杂的过程里，也代表着，优化区块链是优化分布式数据库、中心化数据库的难度的10倍、20倍。

在这样的理解基础上再看OPB。兼顾公链和联盟链特性，让开放联盟链带来了创新性，为开发者和用户带来了友好体验，但也让开放联盟链的参数调优比一般的公链或者联盟链更难。

在公有链上，应用开发者管理自己的节点，根据自己的应用特性优化节点。在联盟链上，普通联盟链一般服务封闭生态的1~2个应用，通过统一中心化的API服务支持应用。

而开放联盟链要面对开放多元的应用读写需求，相比公链和联盟链，OPB面对的是更多不确定的应用访问模式，也扩大了其优化的参数范围。并且在保证安全、开放的基础上，还要保证高性能要求。

文昌链基于Cosmos/Tendermint共识技术开发，兼顾开放、安全、合规、高性能等方面，在调优上不只是几个参数的调整，及简单数据索引的变化，要涉及记账节点和全节点的网络拓扑，共识速度，甚至不同节点的读写带宽，不同通讯类型信息的带宽分配等等。

在过去618的应用高峰期，在调优的过程中，文昌链为了保证网络不停服，选择循序渐进的一个节点一个节点地调整。虽然单个节点调整、重启的过程也会影响文昌链暂时的性能。但即使网络体验会有些许延迟，也能保链账本正确、链资产安全以及链安全持续运行。

后续：正在进行的优化迭代

除了上面实施的方案，文昌链经历了此次高并发后，边界智能团队还梳理了多个层次的优化策略，主要包括：

1.节点配置拓扑的优化：在测试网络验证后，正在文昌链上部署，后续还将持续优化；

2.Tendermint共识对于EVM的优化：文昌链支持Cosmos原生NFT也支持以太坊虚拟机（EVM）NFT，已经找到了Tendermint共识对于EVM优化的方式。未来边界智能会验证后协调全球相关开源开发者一起验证，预计需要1个多月的时间；

3.多全节点分级的拓扑结构设计：BSN网络计划下半年向社区开放全节点部署，有能力的厂商可自行部署全节点，边界智能已经开始和红枣科技团队协同，部署BSN环境外的全节点，并已经在支持AVATA API服务；

（未来会发布全节点部署最优实践指导文档，帮助有能力的应用方建立自己的全节点，用来改善应用访问网络的可靠性。）

4.多语言SDK优化以及AVATA服务性能优化：围绕上述几点，边界智能已在SDK和AVATA API服务上进行优化，计划一个月内会在SDK及AVATA中添加包含更多最优实践的实现，提供更多方便的开发接口供应用者使用；

5.节点历史数据压缩：文昌链的数据增长很快，目前已经有节点数据压缩技术，计划两个月内完成其围绕浏览器和相关支持工具（SDK&AVATA等）的开发和测试；

6. 二层网络：边界智能已经在其他大规模网络上实现了二层网络的技术，通过二层网络技术，可满足应用数万级别的TPS需求。未来几个月中会完成其相关支持工具（浏览器、SDK&AVATA等）的开发和测试，同时和BSN一起探索其商业化业务模式，以保证一旦有业务需求，就可以及时上线二层网络。

实践建议：如何开发最优的分布式应用（数藏/元宇宙）

分布式应用又被称为Web3应用，是基于区块链的下一代互联网应用。分布式应用如果希望成为用户体验良好，成本优化的应用，需要基于区块链系统的特性去实现。

区块链系统特性如下：

1.网络状况决定交易处理/上链速度：多个区块链节点根据共识算法对需要上链的事务(transaction，也称为交易)根据请求先后顺序排序，并在各个节点中分布式执行；节点的内存池容量有限，当事务多的时候，可能出现节点忙于其他计算，等待处理的事务无法进入内存池，因此无法得到及时处理并上链的情况，因此应用会需要链外维护队列排队，并对上链失败的事务重试；

2.网络费用：任何涉及链上数据变化的事务(交易)都会产生一定的网络费用（GAS）；

3.计算需求：对于不同类型的交易而言，根据其需要的计算资源，节点处理速度也不同（转账的速度会比铸造快）；

4.多笔交易：每笔交易网络都需要验证，因此对多次请求而言，打包成一笔交易会比多笔交易（需多次验证）的处理速度更快、消耗GAS更少；

5.本地状态：在共识过程中，或因为网络通讯有延迟，区块链各个节点可能出现状态不一致，因此分布式应用自己的状态变量最好采取自己本地维护的方式，而不是每次都到链上获取。分布式应用也不能像中心化应用一样假定你发送的链上事务（交易）一定会在确定时间内完成。例如文昌链网络畅通时一般出块时间在3秒～10秒间，但如果堵塞的时候就会要等待比较多的区块，等待交易被验证打包。

基于这些特性的理解和实践，有以下几点经验之谈：

1.业务流程：一些比较费资源的、计算量大的业务，例如NFT铸造，业务流程上可以设计为提前铸造，这样其他的场景，例如用户领取NFT时，就只有链上转账交易，会快很多；

2.业务设计：可以学习优秀数藏应用（比如幻核、鲸探）的业务设计。例如鲸探近期开始避免秒杀活动，让用户邀请好友助力来获取购买的资格。这样的设计增强了用户的社交性，更有趣，用户不用掐点去抢，体验好了许多，还避免了系统的高并发；

3. 链账户创建：为了用户体验良好，一般都是应用托管用户的链账户，并替用户支付GAS费用。应用则可以提前准备申请好链账户，并完成GAS费代付的链上授权（文昌链原生模块NFT支持GAS代付的功能），这样应用用户注册时，应用只在应用系统中进行分配即可，也就是进行应用的本地计算，不用等待链上响应。

4. 上链时间选择：避免在网络繁忙的时候进行大批量的链上交易（事务）提交，开放联盟链是开放地支持数百个应用。建议提前计划需要大量产生链账户、NFT铸造等链上事务的执行，留出工作时间余量。文昌链提供了非常完善的区块链浏览器，可以通过浏览器非常方便地查看当前网络繁忙情况。出块时间和最近区块包含的交易笔数可以反映网络拥堵程度，可以提前去浏览器了解相关情况，避开链繁忙的高峰时间。

5. 上链方式：把多个事务信息打包在一个交易中，又快又省GAS。可以参考文昌链SDK以及API服务AVATA中的multi-msg方法。

6.本地应用状态维护：上链操作是无法实时返回结果的，因此建议应用自己离线维护sequence/nonce或本地保存operationid。

（更多具体实践，可以在文昌链GitHub FAQ找到样本）