3.5 財稅聯盟鏈的設計

財稅聯盟鏈數字票據生態建設框架，致力于以應用區塊鏈技術的企業電子票據賬本項目和國際稅收合約項目為起點，推進區塊鏈技術在稅務領域的應用，并推動與電子票據相關的財會服務、金融結算、商品分類統計與追溯（供應鏈）、工業互聯等各相關區塊鏈應用的跨鏈協同（交易），逐步朝著實現社會商業活動中業務流、商品流、資金流、稅務流、信息流的按需融合而努力，并對將來真正的數字票據、籌劃型稅務人工智能，以及數字貨幣視角下的稅收管理進行一些前瞻性的研究。

1．項目背景

面向當前國稅總局和財政部大力推廣的電子發票和非稅電子票據，應用區塊鏈技術，研發提供起到底層支撐作用的全社會可信的企業電子票據賬本，實現電子票據直接入賬和智能合約自動報銷的私鏈應用，解決電子票據重復入賬的全社會行業擔憂的問題，實現電子票據在企業節點之間自動傳遞，流轉過程透明，并且無須再查驗、打印、粘貼報銷，解決人們在此方面的精力和時間投入，降低全社會成本。企業電子票據賬本層次定位如圖3-2所示。

按照電子發票和非稅電子票據目前的推廣政策和管理規定，企業報銷入賬需要打印后按照紙質票據的入賬方式管理。這是因為如果使用電子票據直接入賬，缺乏全社會認可的支撐系統，雖然有的ERP廠商已經致力于企業內的解決方案，但因無法解決全社會的查重，所以難以被監管方認可。

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

需要全國的大平臺和中心數據庫，政府建設需要預算，但因要邁入企業財務管理而超出政務管理，故存在跨界的困難。另外一種思路是參考發展電子發票較早的國家和地區的經驗，建立幾家大平臺，電子發票（非稅電子票據）開具和入賬免費，平臺收入從增值的代賬等服務中獲取。這種思路的技術背景是云計算技術尚未出現、網絡能力不是及區塊鏈技術尚未出現。

3．區塊鏈的解決方案

按照全國稅務地區劃分，可設立36個稅局主監管節點和約3000個子節點，與之對應的，還應設立36個財政主監管節點和約3000個子節點，同時設立36個運維節點，各家企業自身為一個節點，受稅局及財政節點監管，規模約為3千萬個。架構采用fabric、sawtooth、corda和cosmos。其中，fabric主要用于監管業務層；sawtooth主要用于開票權共識層；corda主要用于開票后業務層；cosmos用于前面三個架構遇到無法融合的業務需求難點時跨鏈，以及跨鏈交易；與工業互聯的延伸采用IOTA；企業內私鏈應用智能合約自動報銷采用fabric。基于全生態設計，企業電子票據賬本是其中的一部分，整體架構示意如圖3-3所示。

架構設計考慮主要從完全的P2P和區塊鏈思維出發，對于每一類參與方，凡是在一個事務圈，具有利害關系，具有同等身份，表態對事務圈狀態有影響的，都視為可分配驗證節點身份。當然在具體的業務中，可能會有不同的業務和同一方的身份不同的情況，所以架構設計整體上按照業務做了層次劃分。這樣做的目的是驗證和發揮區塊鏈技術的優勢，同時也可解決某個節點TPS負荷過高的問題，畢竟當前的區塊鏈技術架構還無法支撐海量的交易和節點數。發起人在設計之初也考慮過，全范圍設計10～36個節點來支撐所有業務，但那樣做的證，一來架構支持還有些勉強，二來無法把區塊鏈和點對點思維用到位，還不如就用中心化的方式解決，所以沒有采用那種架構設計。

關于TPS問題，因為架構采用了整體的業務層次拆分原則，所以大大降低了每一個節點和每一個共識圈的業務負荷。因為稅務業務邏輯比較復雜，這里用另外一個場景的例子說明這種設計思想。例如我們在12306訂票，從業務需求上來看，購買從北京到上海車票的乘客，與購買從太原到西安車票的乘客沒有任何關系；進一步，購買從北京到上海的乘客，不同車次的乘客也沒有關系；進一步，同一車次的乘客，選擇不同車廂的乘客也沒有關系；再進一步，喜好靠窗還是靠過道的乘客也沒有關系；而一節車型容量80多人，只選靠窗的又是20多人，這20多人又不能同時購票，按照點對點的設計思維，這種拆解下來，將大大降低TPS的壓力，共識也只在我選擇的車廂和客運公司之間有關。

企業電子票據賬本可能部署在云平臺上，也可能分散地由各參與方選擇各自的部署位置，例如監管方節點、工業互聯節點及經COSMOS對接的其他鏈節點，其中企業節點可由企業根據預算、網絡和設備性能等情況綜合考慮自由選擇本地部署（0成本）或云部署（云付費）。