3.5 财税联盟链的设计

财税联盟链数字票据生态建设框架，致力于以应用区块链技术的企业电子票据账本项目和国际税收合约项目为起点，推进区块链技术在税务领域的应用，并推动与电子票据相关的财会服务、金融结算、商品分类统计与追溯（供应链）、工业互联等各相关区块链应用的跨链协同（交易），逐步朝着实现社会商业活动中业务流、商品流、资金流、税务流、信息流的按需融合而努力，并对将来真正的数字票据、筹划型税务人工智能，以及数字货币视角下的税收管理进行一些前瞻性的研究。

图3-2 电子票据账本层次定位图

1．项目背景

面向当前国税总局和财政部大力推广的电子发票和非税电子票据，应用区块链技术，研发提供起到底层支撑作用的全社会可信的企业电子票据账本，实现电子票据直接入账和智能合约自动报销的私链应用，解决电子票据重复入账的全社会行业担忧的问题，实现电子票据在企业节点之间自动传递，流转过程透明，并且无须再查验、打印、粘贴报销，解决人们在此方面的精力和时间投入，降低全社会成本。企业电子票据账本层次定位如图3-2所示。

按照电子发票和非税电子票据目前的推广政策和管理规定，企业报销入账需要打印后按照纸质票据的入账方式管理。这是因为如果使用电子票据直接入账，缺乏全社会认可的支撑系统，虽然有的ERP厂商已经致力于企业内的解决方案，但因无法解决全社会的查重，所以难以被监管方认可。

2．中心化思路的解决方案

需要全国的大平台和中心数据库，政府建设需要预算，但因要迈入企业财务管理而超出政务管理，故存在跨界的困难。另外一种思路是参考发展电子发票较早的国家和地区的经验，建立几家大平台，电子发票（非税电子票据）开具和入账免费，平台收入从增值的代账等服务中获取。这种思路的技术背景是云计算技术尚未出现、网络能力不是及区块链技术尚未出现。

3．区块链的解决方案

按照全国税务地区划分，可设立36个税局主监管节点和约3000个子节点，与之对应的，还应设立36个财政主监管节点和约3000个子节点，同时设立36个运维节点，各家企业自身为一个节点，受税局及财政节点监管，规模约为3千万个。架构采用fabric、sawtooth、corda和cosmos。其中，fabric主要用于监管业务层；sawtooth主要用于开票权共识层；corda主要用于开票后业务层；cosmos用于前面三个架构遇到无法融合的业务需求难点时跨链，以及跨链交易；与工业互联的延伸采用IOTA；企业内私链应用智能合约自动报销采用fabric。基于全生态设计，企业电子票据账本是其中的一部分，整体架构示意如图3-3所示。

图3-3 财税联盟链整体架构图

架构设计考虑主要从完全的P2P和区块链思维出发，对于每一类参与方，凡是在一个事务圈，具有利害关系，具有同等身份，表态对事务圈状态有影响的，都视为可分配验证节点身份。当然在具体的业务中，可能会有不同的业务和同一方的身份不同的情况，所以架构设计整体上按照业务做了层次划分。这样做的目的是验证和发挥区块链技术的优势，同时也可解决某个节点TPS负荷过高的问题，毕竟当前的区块链技术架构还无法支撑海量的交易和节点数。发起人在设计之初也考虑过，全范围设计10～36个节点来支撑所有业务，但那样做的证，一来架构支持还有些勉强，二来无法把区块链和点对点思维用到位，还不如就用中心化的方式解决，所以没有采用那种架构设计。

关于TPS问题，因为架构采用了整体的业务层次拆分原则，所以大大降低了每一个节点和每一个共识圈的业务负荷。因为税务业务逻辑比较复杂，这里用另外一个场景的例子说明这种设计思想。例如我们在12306订票，从业务需求上来看，购买从北京到上海车票的乘客，与购买从太原到西安车票的乘客没有任何关系；进一步，购买从北京到上海的乘客，不同车次的乘客也没有关系；进一步，同一车次的乘客，选择不同车厢的乘客也没有关系；再进一步，喜好靠窗还是靠过道的乘客也没有关系；而一节车型容量80多人，只选靠窗的又是20多人，这20多人又不能同时购票，按照点对点的设计思维，这种拆解下来，将大大降低TPS的压力，共识也只在我选择的车厢和客运公司之间有关。

企业电子票据账本可能部署在云平台上，也可能分散地由各参与方选择各自的部署位置，例如监管方节点、工业互联节点及经COSMOS对接的其他链节点，其中企业节点可由企业根据预算、网络和设备性能等情况综合考虑自由选择本地部署（0成本）或云部署（云付费）。