CN112487491A

CN112487491A - Control method and related device for block chain system

Info

Publication number: CN112487491A
Application number: CN202011198958.8A
Authority: CN
Inventors: 程晗蕾; 鲁静; 向智宇; 宋斌; 段焱明; 齐荣
Original assignee: Yuanguang Software Co Ltd
Current assignee: Yuanguang Software Co Ltd
Priority date: 2020-10-31
Filing date: 2020-10-31
Publication date: 2021-03-12

Abstract

The application discloses a control method and a related device of a block chain system, wherein the block chain system comprises at least one alliance chain, the alliance chain comprises a plurality of nodes, the nodes comprise a main node and a standby node, and the method comprises the following steps: the standby node judges whether a main node in the alliance chain has a fault; the main node is used for carrying out preset information processing in a working period, wherein the preset information processing comprises gathering intra-chain information of the alliance chain where the main node is located and/or carrying out interaction of the extra-chain information; if not, judging whether the current working cycle of the main node is finished or not; and if the current work period is judged to be finished, replacing the main node in a new work period. The technical scheme provided by the application can improve the stability of the block chain system.

Description

Control method and related device for block chain system

Technical Field

The present invention relates to the field of blockchain technologies, and in particular, to a method and a related apparatus for controlling a blockchain system.

Background

With the development of the blockchain technology, and due to the characteristics of larger storage capacity and higher fault tolerance of the blockchain, various types of systems or network architectures developed based on the blockchain technology are successively applied. In the process of applying various types of systems, the stability of a system or a network architecture based on a block chain is of great importance, and how to improve the stability of the system or the network architecture based on the block chain and ensure stable interaction of data is a problem which needs to be solved urgently.

Disclosure of Invention

The present application mainly solves the technical problem of providing a method and a related apparatus for controlling a blockchain system, which can improve the stability of the blockchain system.

In order to solve the technical problem, the application adopts a technical scheme that: there is provided a method of controlling a blockchain system comprising at least one federated chain comprising a number of nodes, wherein the number of nodes comprise a primary node and a backup node, the method comprising:

the standby node judges whether the main node in the alliance chain is in failure or not; the main node is used for carrying out preset information processing in a working period, wherein the preset information processing comprises gathering intra-chain information of a located alliance chain and/or carrying out interaction of the extra-chain information;

if not, judging whether the current work period of the main node is finished or not;

and if the current work period is judged to be finished, replacing the main node in the new work period.

In order to solve the above technical problem, another technical solution adopted by the present application is: there is provided an electronic device comprising a memory and a processor coupled, wherein,

the memory includes local storage and stores a computer program;

the processor is adapted to run the computer program to perform the method as described above.

In order to solve the above technical problem, the present application adopts another technical solution: there is provided a computer readable storage medium storing a computer program executable by a processor for implementing a method of block chain network architecture control as described above.

The beneficial effect of this application is: different from the situation of the prior art, according to the technical scheme provided by the application, the standby node further judges whether the current working period of the main node is finished or not by judging whether the main node in the alliance chain fails or not and judging whether the main node fails or not, and if the current working period is finished, the standby node replaces the main node in a new working period, and the main node is switched according to the set period to provide a more stable block chain system, so that the problem that the main node selected all the time cannot provide the stable block chain system for a user due to poor function is avoided.

Drawings

FIG. 1 is a block chain system according to an embodiment of the present invention;

FIG. 2 is a block diagram of a federation chain according to the present application;

FIG. 3 is a flowchart illustrating a control method of a blockchain system according to an embodiment of the present invention;

FIG. 4 is a flowchart illustrating another embodiment of a method for controlling a blockchain system according to the present invention;

FIG. 5 is a schematic flow chart diagram illustrating an embodiment of a method for processing documents according to the present application;

FIG. 6 is a schematic flow chart of another embodiment of a method of document processing according to the present application;

FIG. 7 is a schematic flow chart of a further embodiment of a method of note processing according to the present application;

FIG. 8 is a schematic flow chart diagram illustrating a method of ticket processing according to yet another embodiment of the present application;

FIG. 9 is a schematic flow chart diagram illustrating an embodiment of a method for processing documents according to the present application;

FIG. 10 is a schematic flow chart diagram illustrating an embodiment of a method of document processing according to the present application;

FIG. 11 is a schematic flow chart diagram illustrating an embodiment of a method for processing documents according to the present application;

FIG. 12 is a schematic flow chart diagram of another embodiment of a method of note processing according to the present application;

FIG. 13 is a schematic flow chart diagram illustrating an embodiment of a method for processing documents according to the present application;

FIG. 14 is a schematic flow chart diagram illustrating an embodiment of a method of document processing according to the present application;

FIG. 15 is a schematic flow chart diagram illustrating an embodiment of a method of document processing according to the present application;

FIG. 16 is an interactive schematic of a method of note processing according to the present application;

FIG. 17 is a schematic structural diagram of an embodiment of an electronic device according to the present application;

fig. 18 is a schematic structural diagram of an embodiment of a computer-readable storage medium according to the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. It is to be understood that the specific embodiments described herein are merely illustrative of the application and are not limiting of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

In the description of the present application, "plurality" means at least two, e.g., two, three, etc., unless explicitly specifically limited otherwise. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.

In order to facilitate understanding of the technical solutions provided in the present application, a blockchain system related to the method provided in the present application is first described, and the method provided in the present application is applied to the blockchain system. Referring to fig. 1, fig. 1 is a schematic structural diagram of an embodiment of a blockchain system according to the present application.

In the current embodiment, the blockchain system provided by the present application includes at least one federation chain, each federation chain includes a plurality of nodes, the federation chain has the characteristics of decentralized and consensus mechanisms, and the function performed by each federation chain is determined according to a specific application scenario of the federation chain. Each federation chain includes a number of nodes including a primary node and a backup node.

The master node is a node for performing preset information processing in a work cycle. The preset information processing comprises the step of collecting intra-chain information of the alliance chain where the preset information processing is located and/or the step of performing out-chain information interaction.

The standby node is a node for taking over the operation of the primary node when the primary node fails or when a new operation cycle comes.

Further, the master node and the slave nodes are obtained by election according to preset election rules. See below for details.

Further, in some embodiments, the number of nodes further includes a slave node, the slave node being a node that cannot directly interact with the external federation chain on the chain. In some particular cases, nodes for performing some particular functions may interact under-chain with slave nodes for performing particular functions in other federation chains.

It should be noted that, in some embodiments, some nodes included in a block chain system provided by the present application have a peer-to-peer communication function. For example, one node may interact directly with another node under the blockchain.

Further, each federation chain includes only one master node, one standby node, and several slave nodes. It should be noted that, the number of slave nodes included in each federation chain is not limited herein, and is specifically set according to actual requirements.

With continued reference to fig. 1, if the blockchain system 100 illustrated in fig. 1 is used in an enterprise business process, federation chain a illustrated in fig. 1 may be a first enterprise federation chain, federation chain B a second enterprise federation chain, federation chain C a tax federation chain, and federation D an audit federation chain. A1 in the alliance chain A is a main node, A2 is a standby node, and A2 to A4 are slave nodes; similarly, B1 in federation chain B is the master node, B2 is the standby node, and B2-B5 are the slave nodes; c1 in the alliance chain C is a main node, C2 is a standby node, and C2 to C5 are slave nodes; d1 in federation chain D is the master node, D2 is the standby node, and D2-D4 are the slave nodes. Further, in some embodiments, the master blockchain is constructed among the master nodes of the federation chains included in the same blockchain system, as illustrated in fig. 1, master node a1, master node B1, master node C1, and master node D1 collectively comprise master node E in blockchain system 100.

When the blockchain system comprising a plurality of alliance chains provided by the application is applied to each end point of enterprise production and operation, such as invoicing and bill reimbursement, a large amount of reimbursement business information, business transaction information, reimbursement bill information and fund flow information of each unit can be well guaranteed, and efficient interaction of cross units can be rapidly completed through a cross-chain technology while safe storage in the unit.

The enterprise-side alliance chain (at least comprising a first enterprise alliance chain or a second enterprise alliance chain) is used for constructing an alliance chain applied to an enterprise by applying for reimbursement nodes, financial nodes, a plurality of management nodes at different levels and enterprise (high-level) management nodes inside the enterprise. Meanwhile, sensitive fiscal data are set to only circulate in the alliance chain, and enterprise information safety management is improved.

The tax alliance chain mainly comprises a billing (organization) node, a tax bureau node and a bank node and is used for recording bill information.

In other embodiments, the blockchain system may further include: supply chain end federation chains. The supply chain end federation chain includes core enterprises, upstream providers, etc. on the supply chain.

The alliance chain of the audit end comprises an audit organization node, a government supervision part node and a tax drama node which cooperate with each other.

In one embodiment, the master nodes of the first enterprise federation chain, the second enterprise federation chain, the tax federation chain, and the audit federation chain collectively form a backbone (in some embodiments, the backbone would be defined as a synthetic ticket tax services federation chain, and the master node would be defined as a relay node).

Please refer to fig. 2, fig. 2 is a schematic diagram of a framework of a federation chain according to the present application. Before architecturally setting forth a federation chain, the key terms or technical abbreviations referred to in the specification of the present application are first explained:

the block chain technology is a novel distributed data organization method and an operation mode which are developed along with digital encryption currencies such as bitcoin and the like, an alliance chain is short for an alliance block chain, and the alliance chain is a block chain of which the consensus process is controlled by a preselected node. The block chain is characterized in that: decentralization enables the data to realize distributed collective maintenance, and greatly improves the efficiency of data operation, management and maintenance; and (3) consensus, wherein the nodes are based on a set of consensus mechanism, the whole block chain is maintained together through competition calculation, any node fails, and other nodes can still work normally. Meanwhile, the block chain carrying the asymmetric encryption technology has high safety and traceability, and can effectively prevent data leakage or illegal tampering. A blockchain may also be understood as a decentralized database, with data stored as a series of blocks in chronological order, each block referencing the hash pointer of the preceding block to form an interconnected chain. Each node of the blockchain stores a complete copy, the blockchain can automatically synchronize and verify data on all the nodes, and the blockchain has the characteristics of distribution and synchronization. Some methods provided by the present application are executed based on a block chain technology to implement switching between a storage standby node and a master node for data, or to quickly complete an invoicing process based on the block chain technology, or to implement efficient ticket processing based on the block chain technology, and the like, which will be described in detail in the following related embodiments.

To facilitate a better understanding of the federating blockchain in the present application (hereinafter, referred to as federating chain in some embodiments), the federating blockchain technique employed in the present application is first illustrated. Referring to fig. 2, fig. 2 is a schematic diagram illustrating an architecture of an embodiment of a federation chain according to the present application. In one embodiment, an electronic device runs the blockchain technology to become a node of the federation blockchain, or a plurality of electronic devices run the blockchain technology to become the federation blockchain, and the federation blockchain technology architecture is as shown in fig. 2, and includes, from bottom to top, a base support service layer 21, a blockchain underlying technology platform layer 22, a blockchain digital ticket service layer 23, a blockchain cost reimbursement service layer 24, and an enterprise business application layer 25. It should be noted that, in some embodiments, the alliance chain may be designed to include several or all of the blockchain digital ticket service layer 23, the blockchain expense reimbursement service layer 24 and the enterprise business application layer 25 according to actual requirements. As in one embodiment, the federation chain can be designed to include a blockchain digital ticket service layer 23, and in another embodiment, the federation chain can be designed to include a blockchain digital ticket service layer 23 and a blockchain expense reimbursement service layer 24.

The basic supporting service layer 21 comprises a cloud computing IaaS layer, CA authentication and micro application service. The basic support service layer 21 is further configured to combine resources such as big data and cloud computing, provide a stable background infrastructure for the federation blockchain, and provide extended storage, an efficient network, and sequentially purchase blockchain resources such as nodes with elastic expansion and automatic failure recovery for the federation blockchain.

The blockchain underlying technology platform layer 22 is located on the enterprise-level blockchain underlying platform, with its relevant blockchain core technology components including, but not limited to, such as user identity and rights management, asymmetric encryption, smart contracts, communication and cross-link protocols, privacy protection, digital signatures, consensus mechanisms, and storage mechanisms.

User identity and authority management: and a complete CA certificate management system is supported, and the user is ensured to ensure the identity authentication compliance through a PKI certificate system. The user manages the access authority of the user to the data resources on the alliance chain through the unified identity authentication service.

Asymmetric encryption: each enterprise and user has their own public and private keys. In the process of encrypting the information, the public key of the information sending node is used for encrypting the information, and the receiving node receives the encrypted information and then decrypts the encrypted information by using the private key of the information sending node, so that the information can not be obtained in the plaintext even if being stolen in the transmission, and the data safety is guaranteed.

The intelligent contract supports Java/Go/node.js multi-language compilation, runs in an isolated security Docker container, is monitored by a system in real time whether high-risk function calling and container escape behaviors exist during running of the intelligent contract, and prevents the threat of malicious intelligent contracts to union block chains.

Communication and cross-link protocol: and the nodes in the network carry out state synchronization and data distribution through the Gossip protocol. In some embodiments, the technical solution provided by the present application may be to use a relay protocol to complete data interaction cross-chaining. A relay is a channel from chain to chain, and if the channel itself is a blockchain, then it is a relay chain. In the cross-chain process, the relay plays a role of a data collector, the relay technology does not depend on a trusted third party to carry out transaction verification, the target chain can be verified by itself after the data of the sending chain is taken, and the self-verification mode is different according to different system structures. Wherein, the target chain refers to a federation block chain for receiving data.

Privacy protection: the method supports SM2/SM3/SM4 cryptographic algorithm, addition homomorphic encryption, zero knowledge proof, enterprise user signature strategy diversity, and hardware-based trusted computing environment protection key security and other privacy measures, thereby meeting the requirements of data security transmission, transaction content privacy protection and the like.

Digital signature: the information sender uses the private key of the information sender to encrypt the plaintext information to complete digital signature, and the receiver uses the public key of the sender to decrypt the encrypted information, so that the information source is verified to be reliable.

A consensus mechanism: and supporting a solo mode, Kafka/Zookeper consensus, FBFT, Raft and other consensus mechanisms, thereby completing the effective confirmation of the consistency of the uplink data to be transmitted by the multi-node.

The storage mechanism is as follows: the method supports data storage to a cloud elastic File Service (SFS), and the bottom layer database is levelDB/CouchDB. All metadata will be written into kv (Key-Value ) database, where the blockhash/txHash will be used as an index in the dat file for subsequent query of specific data.

The basic support service layer 21 and the block Chain underlying technology platform layer 22 provide a high-security, high-reliability and high-performance block Chain basic technology service for upper layer applications at low cost and quickly through an SQL and API interface mode, and can also support excellent block Chain underlying frameworks such as superlegergr Fabric, Tencent TBaaS, and Baidu Xuper Chain.

In one embodiment, when the federation blockchain includes a blockchain electronic ticket service layer 23 for supporting reimbursement services, the blockchain electronic ticket service layer 23 may include functions such as billing application, ticket issuing, ticket redemptions, ticket management, ticket authenticity verification, ticket statistics, data monitoring, ticket forewarning, and the like. The application of the ticket is initiated by the business transaction party or reimbursement sponsor. The bill issuing tool can be divided into an upper chain billing mode and an upper chain billing mode according to different types of certificates used by billing agencies. The note is red, which means that when the original invoice is wrongly issued and needs to be correct, the account is adjusted by using the red.

In another embodiment, when a federation blockchain may include a blockchain charge reimbursement service layer 24, the blockchain charge reimbursement service layer 24 includes modules for reimbursement regimes, reimbursement personnel identity settings, reimbursement amount presets, rules management, reimbursement accessory management, reimbursement credential management, reimbursement fund alerting, employee credit analysis, and the like.

In yet another embodiment, when the federation blockchain may include an enterprise business application layer, the enterprise business application layer may include information management systems such as a docking enterprise reimbursement system, a financial system, an ERP system, a marketing system, etc., to provide trusted, secure, and fast blockchain applications for the end enterprise and users.

In the following related embodiments, a software and hardware environment having a blockchain core component and capable of providing basic research and development for building upper-layer applications is defined as a blockchain application service platform. The blockchain node runs on the blockchain application service platform to complete data transmission and service processing. A blockchain application service platform may also be understood in some embodiments to allow users to build, host, and use their own blockchain applications, intelligent contracts, and functionality on blockchains using cloud-based solutions.

The hash value is a function for compressing a message of an arbitrary length to a message digest of a fixed length according to a set calculation rule.

Referring to fig. 3, fig. 3 is a flowchart illustrating a control method of a blockchain system according to an embodiment of the present invention.

The embodiment shown in fig. 3 is applied to a blockchain system, which includes at least one federation chain. As described above, a federation chain includes several nodes, including a primary node and a backup node. In the present embodiment, the method for controlling a blockchain system provided by the present application includes:

s31: and the standby node judges whether the main node in the alliance chain has a fault.

The main node is used for carrying out preset information processing in a working period, and the preset information processing comprises the step of collecting intra-link information of the alliance chain where the main node is located and/or the step of carrying out interaction of the out-link information. Each federation chain includes a primary node and a backup node.

In an embodiment, the standby node may determine whether the primary node fails by determining whether a failure warning sent by the primary node is received. In the current embodiment, if the master node fails, the master node sends a failure warning to the standby node to trigger the standby node to replace the master node. Wherein the failure of the master node at least comprises: power outage, network delay, etc. It is understood that in other embodiments, a master node failure may also include other types of failures, not to be enumerated herein.

In another embodiment, when several slave nodes are included in the federation chain, the standby master node may also obtain the master node failure by jointly judging with other nodes in the federation chain. Specifically, in a federation chain, each node may interact with a master node, and if the master node and the slave nodes used for interaction are normal, the slave nodes may send information to the master node normally, and correspondingly, the slave nodes may also receive a message receipt sent by the master node normally; otherwise, if the slave node and the master node cannot interact, it is determined that one of the two parties has a fault. Because the federation chain includes a plurality of slave nodes, if more than half of the slave nodes cannot interact with the master node but the slave nodes can normally interact with each other, it can be determined that the master node fails at the moment, and a message of the master node failure is sent to the standby node. The standby node can judge whether the main node fails according to the number of the slave nodes of the received message of the failure of the main node. For example, it may be configured that the backup node receives a master node failure sent by a slave node that exceeds a preset ratio, and the backup node determines that the master node failure is obtained. The preset proportion can be set according to actual requirements, for example, the preset proportion can be 50%, 75% and 30%.

S32: and judging whether the current work period of the main node is finished.

And if the standby node judges that the main node in the alliance chain has no fault, further judging whether the current working period of the main node is finished. The working period is a period of master node switching set in advance according to requirements, the time length of the working period is set in advance according to empirical values, and the time length of the working period is not limited herein.

Furthermore, since the master node is used for aggregating the intra-link information of the alliance chain where the master node is located and/or performing interaction of the extra-link information, the total time required for aggregating all the nodes in the alliance chain and/or the time length for performing the extra-link information interaction may be referred to when the work cycle of the master node is set.

S33: and if the current work period is judged to be finished, replacing the main node in a new work period.

If the current duty cycle is determined to be over in step S32, the standby node will replace the primary node in a new duty cycle. The replacement of the master node means that the master node is responsible for processing the preset information. For example, when the master node is used to collect the intra-chain information of the located alliance chain, the standby node can assume the function of collecting the intra-chain information of the located alliance chain in a new work period; if the master node is used for interacting the off-link information, the standby node is used for assuming the function of interacting the off-link information in a new work period.

It should be noted that, after the current work cycle is finished, the standby node replaces the master node in a new work cycle, and then the original master node is changed into the slave node.

Further, in an embodiment, the master node is only used for aggregating intra-chain information of the local federation chain and/or performing interaction of the extra-chain information, and does not participate in the consensus mechanism.

In the method provided in fig. 3 of the present application, the standby node further determines whether the current working period of the main node is finished by determining whether the main node in the alliance chain has a fault or not and determining that the main node has not sent a fault, and if the current working period is finished, the standby node replaces the main node in a new working period.

Further, referring to fig. 3, in an embodiment, if it is determined in step S31 that the master node in the federation chain fails, the method provided in this application further includes step S34.

S34: and directly replacing the main node until the main node is recovered to be normal.

And if the main node in the alliance chain is judged to be failed, the standby node directly replaces the main node until the main node is recovered to be normal.

For example, in an embodiment, the standby node determines whether the main node fails by determining whether the fault warning sent by the main node is received, and the fault warning sent by the main node is received in the current period after monitoring, and then the standby node determines that the main node fails, and directly replaces the main node until the failed main node returns to normal or the current working period ends. It should be noted that the master node does not exit from the federation chain during master node failure.

Further, after the master node is replaced and the standby node becomes a new master node and stably operates, the method provided by the application further includes: one node is selected from the plurality of nodes as a new standby node. In the current embodiment, the nodes for selecting the new standby node include all slave nodes in the federation chain that can operate normally. In another embodiment, the nodes used to select the new backup node include all slave nodes in the federation chain that are capable of operating normally except for the master node that failed.

After the master node is replaced and the standby node becomes a new master node and stably operates, the method provided by the application further comprises the following steps: and selecting one candidate node from at least one candidate node as a new standby node. The candidate nodes are selected from a plurality of nodes, the number of the candidate nodes is at least one, for example, 5, 3, or three, and the specific limitation is not limited herein. The candidate nodes are selected in advance according to a set selection rule and are specially used for candidate selection of standby nodes.

Further, the method provided by the present application further includes: and selecting at least one node as a candidate node based on the storage capacity and/or the performance score of each node in the alliance chain.

Furthermore, the candidate nodes may be selected according to a set time period, that is, a new candidate node is selected every set time period, and the candidate nodes are kept unchanged in the same set time period. In the current embodiment, the workload of selecting the standby node can be reduced to a certain extent by setting to select a new candidate node according to a set time period, and meanwhile, a better node can be selected from the alliance chain to become the standby node and further become a master node, so that the stability of the alliance block chain system is better improved, and the new node to be added in the alliance chain can be better considered by selecting the new candidate node according to the set time period, so that the node to be added newly and having better storage capacity and/or performance score becomes the candidate node.

Further, the length of the set time period may be an integral multiple of the duty cycle. In another city, the set time period can be just ahead of the time point of the working period by a certain time length, so that the situation that the candidate node is not determined to further influence the selection of the standby node when the standby node is switched to a new main node at the end of the working period is avoided. As can be set, the time period is just half a duty cycle time length ahead of the duty cycle time point.

Referring to fig. 4, fig. 4 is a schematic flowchart illustrating another embodiment of a control method of a blockchain system according to the present application. In the current embodiment, the method provided by the present application includes:

s41: and the standby node judges whether the main node in the alliance chain has a fault.

S42: and directly replacing the main node until the main node is recovered to be normal.

In the present embodiment, step S41 is the same as step S31, and step S42 is the same as step S34 illustrated in fig. 3, which may specifically refer to the descriptions of the above corresponding parts, and will not be described again here. In the current embodiment, after the standby node replaces the primary node, the method provided by the present application further includes steps S43 to S45.

S43: and judging whether the current work period is finished or not.

After the standby node replaces the primary node, the standby node will continue to determine whether the current duty cycle has ended. If the current duty cycle is determined not to be ended, executing the following steps S44 and S45; otherwise, if it is determined that the current duty cycle is finished, the following step S46 is executed.

S44: and judging whether the replaced main node is recovered to be normal or not.

If the current working cycle is not finished, the standby node (the standby node currently executing the main node function, which may also be understood as a new main node) further determines whether the replaced main node is recovered to normal. Specifically, the standby node may send information to the replaced main node, and determine whether a receipt message of the replaced main node can be received, if so, determine that the replaced main node is recovered to be normal, otherwise, determine that the replaced main node is not recovered to be normal if no receipt message is received within a set time interval.

In another embodiment, the standby node may determine whether the replaced primary node is back up by monitoring whether a message is received from the replaced primary node.

S45: the replacement master node is stopped. And if the replaced main node is recovered to be normal, the standby node stops replacing the main node.

If the replaced main node is judged to be recovered to be normal, the standby node stops continuously replacing the original main node, so that the main node recovered to be normal continuously executes the function of processing the preset information in the current working period; otherwise, if the replaced main node is judged not to be recovered to be normal, the standby node continues to replace the fault main node until the main node is recovered to be normal in the current working period or the current working period is finished.

And after the standby node stops replacing the main node, the standby node becomes a slave node and continuously participates in the consensus mechanism in the alliance chain.

If the blockchain system includes a plurality of alliance chains and the master node participates in the main chain consensus mechanism, the method provided by the present application further includes: and sending the block information stored when the preset information processing is executed to the main node which recovers to be normal so that the main node which recovers to be normal stores the block information into the block.

In the current embodiment, after the standby node is set to stop replacing the master node, the block information stored when the standby node executes the preset information processing is sent to the master node which is recovered to be normal, so that the block length of the master node can be kept consistent with that of other alliance chains, and the master node can better participate in the main chain consensus mechanism. The main chain is a block chain formed by main nodes of a plurality of alliance chains.

Further, in order to better participate in the backbone consensus mechanism, in an embodiment, in the technical solution provided in the present application, when switching between the standby node and the master node, the stored latest block and block information included in a set number of blocks before the latest block are all sent to the next master node, so that the new master node can better participate in the backbone ear consensus mechanism.

In another embodiment, the master nodes of the respective federation chains do not participate in the backbone consensus mechanism, and the stored chunk information is not sent to the master node returning to normal after the replacement is stopped.

S46: and the current standby node stops being used as the main node, and triggers the new standby node to be switched into a new main node.

If the current duty cycle is determined to be finished in step S43, the new standby node is triggered to switch to the new master node. The new standby node is a node selected from a plurality of nodes or a candidate node selected from at least one candidate node.

In an embodiment, in order to obtain a master node with more stable performance during the process of periodically switching the master node, the technical solution provided by the present application further introduces a step of performing performance scoring on the node. Specifically, after the standby node determines whether the master node in the federation chain in which the standby node is located fails at step S51, the method provided by the present application includes: and if the main node is judged to have a fault, recording the fault of the main node, and updating the performance score of the main node according to the fault record of the main node. Specifically, if the master node sends a fault, the preset score is subtracted from the current performance score, and the obtained difference is used as a new performance score to be updated to the new performance score of the faulty master node. For example, if a node fails once, the performance score integral increases by-5 points (it can also be understood that the performance score is decreased by 5 points on the original basis, the initial score of the performance score is zero, and the total score of the performance score can be lower than zero).

Further, if a certain master node can normally operate for a work cycle, the method provided by the present application further includes: and if the main node is judged to normally execute a working cycle, recording that the operation of the main node is complete, and updating the performance score of the main node according to the normal operation record of the main node. Specifically, when the master node is operating well within a working period, a preset score is added on the basis of the current performance score, and the sum is used as a new performance score and updated to the new performance score of the master node. In the current embodiment, by increasing the performance score of the node, the node with stable performance can be quickly selected as a standby node or a main node according to the performance score.

Further, when a new node is to join the current blockchain system, the method provided by the present application further includes: if the standby node receives the access request of the new node before replacing the main node, the standby node feeds back the address of the main node to the new node so that the new node sends the access request to the main node according to the address of the main node.

In another embodiment, the method provided herein further comprises: and if the standby node receives the access request of the new node after replacing the main node, checking the identity of the new node according to the access request, and broadcasting the public key address of the new node in the alliance chain so that all nodes in the alliance chain can determine whether the access request passes.

For example, the process of adding a new node to a federation chain is as follows:

in one embodiment, when a new node desires to join a federation chain, it sends an access request to any node in the federation chain, and the node receiving the access request returns the address of the master node in the current federation chain to the new node.

After the new node acquires the address of the main node, the new node sends a join application, a public key address of the new node and identity authentication information to the main node according to the address of the main node. After the current master node of the federation chain further checks the identity of the current master node, the public key of the new node is written into a registry at the head of a block of the federation chain, the public key address of the new node is encrypted by using the private key of the current master node of the federation chain, and broadcasting is performed in the federation chain (that is, broadcasting is performed in a federation chain/slave chain in which the new node is ready to apply for joining a service). And decrypting each node on the alliance chain by using the public key of the main chain node to obtain the public key of the new node. The new node encrypts the application information by using the private key of the new node and broadcasts the application information to all nodes on the alliance chain. And decrypting the slave link nodes on the alliance chain by using the obtained public key, and if the decryption is successful, replying the receipt information of the new node. And only when the new node receives the receipt information of all the nodes in the alliance chain, the alliance chain is successfully accessed.

In one embodiment, the switching process of the master node is as follows:

taking the block chain system illustrated in fig. 1 as an example, the master nodes of the respective alliance chains together form a bead curtain, and the respective alliance chains serve as slave chains (all nodes except the master node of the slave chain are slave nodes) to form a master-slave multi-chain block chain system. Meanwhile, each slave node can record the internal data of the enterprises in each belonging alliance chain. The master node (e.g., the enterprise node in fig. 1) is responsible for sending and receiving all information on the belonging federation chain, and the slave node is responsible for uploading and reading information generated by the node. Such as: when the bill reimbursement service is needed, the specific verification information is temporarily stored in the main chain and stored in the slave chain nodes, and the final result after reimbursement is identified by the consistency and permanently stored in the main chain nodes. The main-chain node is an electronic device (some embodiments may also be defined as a server) with mass storage and efficient transmission functions, and other (organization, department, user) nodes in the federation chain are all slave nodes. The verification information refers to business information on the electronic document which is verified and necessary for reimbursement and verification. For example: original voucher (including administrative type charging unified bill, ticket, value added tax invoice, etc.), invoice number, reimbursement amount, approval mail, responsibility center, expenditure item/expense item, value added tax special invoice tax, tax cost after tax, etc.

The block chain system of principal and subordinate multichain that this application designed gets rid of and can realize carrying out better privacy protection to enterprise sensitive data, can also carry out the multichain reposition of redundant personnel processing to a large amount of "operation, industry, property" data of crossing the enterprise, promotes whole block chain system and links up the handling performance to data.

In one embodiment, when the federation chain is for an enterprise, upon selection of candidate nodes, a list of candidate nodes is determined based on whether each enterprise has a server of the type and has the ability to maintain the server, and at least 1 primary node and 1 backup node are selected from the list of candidate nodes when determining the backup node. The principle of selection is that the lower the failure rate of a node during the past functioning as a main chain node, the higher the main chain probability of the node being selected as the next cycle. In some embodiments, when a scoring system is provided for a node, the primary and backup nodes may be determined with reference to the scoring system and system capacity.

When data is only linked up in the circulation of the alliance chain, the slave node and the standby node (note: the standby node only participates in the consensus process when the master node normally operates) in the chain verify the validity of the data to be uploaded through the consensus algorithm, and then the data is packaged into the slave chain block, and the data is linked up, stored and broadcasted in the chain.

When a federation chain (which may also be defined as a slave chain in some embodiments) interacts with the master chain across chains, the slave chain uploads data on its uplink to a master node, which is responsible for aggregating and relaying its information. The master node reads the information of the head of the slave chain block, adds the data in the block body into the master chain block, simultaneously updates the block head part of the master chain block chain, or generates a new master chain block (if the storage capacity of the block is full, no more update information can be added), and broadcasts in the master chain. The slave node packs the data needing interaction into a alliance chain block, and chains and uploads the data to the master node. The master node reads the information of the alliance chain block header and adds the data in its block body to the master chain block while updating the block header portion of the master chain block. When the master node receives a plurality of data to be relayed, the master node can sequentially forward the data to be relayed according to the priority of the data.

If the main node fails in the operation process (i.e. the process of updating the main chain block information), the standby node immediately takes over the main node operation (i.e. updating/generating the main chain block operation) and broadcasts to complete the information collection and relay (the standby main chain node has the inheritance or candidate function, and the purpose is to ensure the stable and normal operation of the block chain system); after the new main chain node normally operates, immediately selecting a standby main chain node; the alternate backbone node broadcasts.

If the main node is not in fault, after the main chain node normally and continuously operates for 1 working period, the standby node takes over the main node to operate and broadcast (during the normal operation of the main node, the standby main chain node is the same as other slave chain link nodes in function), and then the standby main chain node of the next period is selected; the alternate backbone node broadcasts.

The selection method of the main node, the standby node and the like needs to achieve consensus in the alliance chain, a consensus mechanism is formed and written into an intelligent contract of the alliance chain, and when the system detects that the main node fails or normally and continuously works for 1 period, the main chain node can be automatically replaced and the standby node can be randomly selected from the remaining candidate nodes, so that the autonomy and the high efficiency of the block chain based system are guaranteed, and the stability is improved.

In the process of enterprise production and operation or daily life, some business transactions occur in a chain to generate bills, such as corresponding business transactions of signing a purchase contract, signing a service contract, signing a purchase and electricity-selling contract, daily consumption and the like, and in the process of the business transactions, after a buyer pays funds correspondingly, the seller often needs to invoice the buyer. However, the existing billing process often needs the cooperation of multiple mechanisms under a chain, so that the billing efficiency is low, and meanwhile, the reliability cannot be guaranteed.

In order to solve the problem of low billing efficiency in the prior art, the present application provides a method for processing bills based on the block chain system structure provided in any of the above embodiments. First, it should be noted that the blockchain system to which the method provided by the present application is applied at least includes an enterprise alliance chain and a tax alliance chain, and a control method of the blockchain system and an interaction method between the alliance chains in the blockchain system may specifically refer to fig. 1 to 4 and any corresponding embodiment thereof. Correspondingly, the enterprise alliance chain and the tax alliance architecture may refer to the alliance chain architecture described in fig. 1 to 4 and any corresponding embodiment thereof, and the interaction of the nodes in the enterprise alliance chain and the tax alliance chain, or refer to the description of the corresponding parts above.

The bill processing method is applied to a first enterprise alliance chain of a seller, the first enterprise alliance chain comprises a main node and a financial node, the main node is used for performing information interaction between the alliance chain and other alliance chains, and the other alliance chains comprise tax alliance chains where tax authorities are located. The first enterprise alliance chain is an enterprise alliance chain of a seller, and when the blockchain system simultaneously comprises enterprise alliance chains of buyers, the second enterprise alliance chain is used for indicating the enterprise alliance chain of the buyers as described below.

Referring to fig. 5, fig. 5 is a schematic flow chart of an embodiment of a bill processing method according to the present application. In the present embodiment, the technical solution provided by the present application is explained in terms of an enterprise alliance chain in which a seller is located, and the method provided by the present application includes:

s51: and the financial node acquires an invoicing application sent by the purchaser.

When the purchaser completes the fund payment, the purchaser sends an invoicing application to the seller. The invoicing application is a request for applying for invoicing. Further, in one embodiment, the invoicing application may be a request specifically for issuing an electronic invoice. Further, in another embodiment, the invoice application refers to a request to invoice a blockchain.

In one embodiment, when the buyer can directly perform the offline interaction with the seller's financial node, the buyer sends the invoicing application to the seller's financial node directly. Further, the step S51 includes: and acquiring an invoicing application directly sent to the financial node by the purchaser.

In another embodiment, when the purchaser interacts with other nodes in the first enterprise federation chain, the purchaser may send the billing application to other nodes in the first enterprise federation chain, and the other nodes in the first enterprise federation chain may forward the billing application to the financial node within the chain after obtaining the billing application of the purchaser. Accordingly, the step S51 includes: and acquiring the invoicing application forwarded by the service node in the first enterprise alliance chain from the buyer.

Specifically, after receiving the invoicing application, the service node may directly send the invoicing request to the financial node in a linked manner, or forward the invoicing request to the financial node in a linked manner, so that the financial node acquires the invoicing request from the alliance link. The sending under the chain means that two nodes directly carry out point-to-point interaction, and the interactive data does not need other nodes to participate together.

The service node refers to a node which interacts with a purchaser and receives an invoicing application sent by the purchaser. If the nodes on the enterprise federation chain are divided according to the functions of the enterprise departments, the business node can be any one of a sales node, a customer service node, an after-sales service node and the like. It should be noted that, the division of functions of different departments of an enterprise is different, so the service nodes may also include nodes in the enterprise for undertaking other functions, and the division of functions of the enterprise and the setting in the enterprise alliance chain may be specifically the criteria.

Further, it should be noted that the invoicing application at least includes basic information of the purchaser. Wherein the basic information of the purchaser at least includes unique identification information that can be used to identify the identity of the purchaser. If the purchaser is individual, the basic information of the purchaser includes the name and identification number of the purchaser; when the purchaser is a business or an organization, the basic information of the purchaser includes the name of the purchaser and the taxpayer identification. Furthermore, the invoicing application comprises basic information of the purchaser and basic information of the transaction needing invoicing, wherein the basic information of the transaction needing invoicing at least comprises an order number or a contract number and the like.

S52: acquiring billing service information according to the billing application, and generating a billing request based on the billing service information.

And after receiving the invoicing application, the financial node acquires the invoicing service information according to the invoicing application and generates an invoicing request based on the invoicing service information. The billing service information refers to information necessary for billing, and the billing service information may be obtained from a billing application, or may be obtained by performing on-chain access on the first enterprise alliance chain according to the basic information of the buyer and the basic information of the transaction included in the billing application. The information type included in the billing service information is subject to the billing requirement of the tax bureau.

The invoice request is sent to the tax federation chain so that the tax federation chain responds to the invoice request. Specifically, a data format of the billing request may be preset, so that after the financial node acquires the billing service information according to the billing application, the acquired billing service information is directly filled into the format of the billing request to generate the billing request. According to the current invoice type of our state tax affairs, the invoice type required to be issued is set in the invoice request. The invoice type is determined by the declaration of the scale and the operation of the seller enterprise to the tax part. When a seller enterprise can issue invoices of various different types at the same time, the invoice types corresponding to different types of services can be preset in the technical scheme provided by the application, so that the current invoice type required to be issued can be quickly determined after the financial node receives an invoicing application and acquires invoicing service information. For example, when a seller enterprise can sell the detection device and the detection service to the outside simultaneously, and the sales service of the preset detection service corresponds to a value-added tax special invoice, and the sales service of the detection device corresponds to a common invoice, after receiving a billing application of a buyer, the seller enterprise further determines the service type to be billed, and then determines the invoice type according to the determined service type to be billed.

S53: the invoicing request is sent to the master node for forwarding to the tax federation chain.

And the financial node sends the billing request to the main node of the first enterprise alliance, so that the main node of the first enterprise alliance chain forwards the billing request to the tax alliance chain. In one embodiment, the finance node may send the billing request directly to the host node. In another embodiment, the financial node may also chain the invoicing request, so that the primary node obtains the invoicing request through the uplink access and forwards the invoicing request to the primary node of the tax federation chain.

And after receiving the invoicing request, the main node of the first enterprise alliance chain transmits the invoicing request to the main node of the tax alliance chain, and the main node of the tax alliance chain transmits the invoicing request to the invoicing node, so that the invoicing node responds to the invoicing request to invoice. The first enterprise alliance chain and the tax alliance chain are interacted through respective main nodes, wherein the first enterprise alliance chain and the tax alliance chain respectively comprise one main node. In an embodiment, the master node of the first enterprise federation chain may be the master node that directly sends the invoicing request directly to the tax federation chain. In another embodiment, the master node of the first enterprise federation chain may be the master node that broadcasts the invoice request within the backbone, thereby making available the master node of the tax federation chain. In yet another embodiment, the primary node of the first enterprise federation chain may be the primary node that uplinks the invoicing request to the backbone, and the primary node of the tax federation chain is then obtained by accessing the backbone. The main chain is composed of the main nodes of all alliance chains in the block chain system, and in some embodiments, the main chain can be limited to perform data transmission interaction and storage only, and node consensus is not performed.

S54: acquiring invoice chain information generated by the tax alliance chain in response to the invoicing request, filling the invoice chain information into the bill format template to generate an invoice, and feeding the invoice back to the purchaser.

After the main node of the first enterprise alliance chain forwards the invoicing request to the tax alliance chain, the main node further feeds back a successfully forwarded receipt to the financial node. And the tax alliance chain generates invoice chain information after acquiring the invoicing request, and further transmits the invoice chain information to the financial node through the main node of the tax alliance chain and the main node of the first enterprise alliance chain. And after the financial node acquires invoice chain information generated by the tax alliance chain responding to the invoicing request, the invoice chain information is further filled into the bill format template to generate an invoice.

The bill layout template is a template corresponding to the invoice type corresponding to the service applied in the invoicing application. If the service requested in the invoicing request corresponds to a common invoice, the received invoice chain information is backfilled into the invoice template corresponding to the common invoice in step S54. Or, when the service applied in the invoicing application corresponds to the value-added tax special invoice, the received invoice chain information is backfilled into the bill template corresponding to the value-added tax special invoice in the corresponding S54.

The invoice chain information is key information in the invoice, and is key information which must be generated and issued by a tax authority. For example, the invoice chain information includes information such as "two-dimensional code content, invoice code and number, check code, ciphertext area", and the like. It can be understood that when the key information of the invoice changes, the corresponding invoice chain information is correspondingly adjusted, and therefore, the invoice chain information is not particularly limited herein.

Further, after step S53 and before step S54, the method provided by the present application further comprises: and acquiring a bill layout template of an invoice type corresponding to the service applied in the invoicing application. Wherein, the bill layout template can be a template with a seller official seal. In other embodiments, the bill layout template may also be a template without a seller official seal, and only after the invoice chain information is filled, the seller official seal is directly added in the enterprise alliance chain.

Further, before the step S54 of filling the invoice chain information into the bill layout template to generate the invoice, the method provided by the present application further includes: and checking whether the types of the invoices corresponding to the currently acquired bill template and the invoice chain information are consistent, if so, executing the step of filling the invoice chain information into the bill layout template in the step S54 to generate the invoices, otherwise, if the types of the invoices corresponding to the acquired bill template and the invoice chain information are not consistent, suspending generation of the invoices and sending an abnormal prompt to financial staff.

Further, in an embodiment, after the step of filling the invoice chain information into the bill layout template to generate the invoice, the method provided by the present application further includes: and generating a business transaction certificate based on the business certificate and the invoice. The business transaction voucher comprises an invoice, a business voucher and a payment voucher of a seller.

And after the business transaction certificate is generated, the financial node stores the generated business transaction certificate to the first enterprise alliance chain. In the current embodiment, the service transaction certificate is stored in the first enterprise alliance chain (namely, uplink), so that when the service transaction certificate needs to be called subsequently, the service transaction certificate can be quickly acquired only by accessing the first enterprise alliance chain, and meanwhile, resource sharing and management are realized through uplink, and investment of manual management cost is reduced.

Further, when the buyer's enterprise also has an enterprise federation chain deployed, i.e., it can be understood that other federation chains in the blockchain system include a second enterprise federation chain in which the buyer is located, the step of feeding back the invoice to the buyer further comprises: the invoice is sent to the master node for forwarding to the second enterprise federation chain. Namely, the financial node fills the invoice chain information into the bill format template, and sends the generated invoice to the main node after adding the invoice special official seal. After receiving the invoice, the main node further calculates the obtained invoice to obtain a hash value, and then links the hash value of the invoice to the main chain for storage, and the main node of the second enterprise alliance chain can obtain the hash value of the invoice by accessing the main chain, and further can obtain the invoice based on the hash value. It is understood that in other embodiments, the master node of the first enterprise alliance chain may directly send the invoice to the master node of the second enterprise alliance chain, so that the buyer can obtain the invoice.

It will be appreciated that in other embodiments, the financial node may generate the invoice directly to the purchaser by feeding back the invoice to the financial node down the chain.

According to the technical scheme provided in fig. 5, based on the block chain system and the alliance chain included in the block chain system provided in the present application, a financial node in a first enterprise alliance chain acquires an invoicing application sent by a purchaser, acquires invoicing service information required for invoicing according to the invoicing application, generates an invoicing request based on the invoicing service information, and then sends the invoicing request to a host node in the first enterprise alliance chain, so that the host node in the first enterprise alliance chain forwards the invoicing request to a tax alliance chain, so that the tax alliance chain responds to invoice chain information generated by the invoicing request, and the financial node forwards and acquires invoice chain information generated by the tax alliance chain in response to the invoicing request through a relay; after the financial node acquires invoice chain information generated by the tax alliance chain, the financial node further fills the invoice chain information into a bill format template to generate an invoice, and feeds the invoice back to the purchaser to complete invoicing.

Referring to fig. 6, fig. 6 is a schematic flow chart of another embodiment of a bill processing method according to the present application. Specifically, in the present embodiment, it is emphasized that the step S52 includes the steps of acquiring the billing service information according to the billing application, and generating the billing request based on the billing service information. In the current embodiment, the above step S52 further includes steps S61 to S63.

S61: and analyzing the invoicing application to obtain the basic information of the purchaser and the service voucher corresponding to the invoicing application.

The invoicing application comprises at least one kind of basic information capable of identifying the identity of the purchaser.

In an embodiment, after the invoicing application sent by the buyer is acquired, the invoicing application is further analyzed to acquire basic information capable of identifying the identity of the buyer, and then other basic information of the buyer and/or a service certificate corresponding to the invoicing application required for invoicing are acquired on the first enterprise alliance chain based on the basic information capable of identifying the identity of the buyer. For example, after the financial node analyzes the invoicing application, only the name and the taxpayer identification of the buyer enterprise are obtained, the financial node further obtains basic information such as the address, the account number of the issuer, and the item description needing to be invoiced of the buyer enterprise based on the name and/or the taxpayer identification of the buyer enterprise, and the financial node also determines the service needing to be invoiced and the service certificate corresponding to the service needing to be invoiced based on the name and the taxpayer identification of the buyer enterprise.

In another embodiment, the invoicing application is analyzed to obtain all basic information of the buyer required for invoicing, and then the business certificate corresponding to the invoicing application is obtained on the first enterprise alliance chain based on the information which can identify the identity of the buyer in the obtained basic information of the buyer.

In another embodiment, when the invoicing application includes all the basic information of the buyer required for making an invoice and the service voucher corresponding to the invoicing application, step S61 includes parsing the invoicing application to directly obtain all the basic information of the buyer required for making an invoice and the service voucher corresponding to the invoicing application.

The business voucher corresponding to the invoicing application is a voucher when a buyer and a seller perform business transaction, wherein the business voucher can be a voucher added to the invoicing application by the buyer, and a financial node is directly obtained from the invoicing application; the service certificate can also be obtained by the financial node on the first enterprise alliance chain according to the basic information of the buyer included in the invoicing application.

Where the business document includes at least one of a transaction contract and a transaction document, it is understood that in other embodiments, the business document may include other types of documents, not listed herein. In addition, the number of the service certificates is not limited, and the number required for the application of the invoicing is subject to the standard, for example, when the enterprise sets that a seller and a buyer respectively make a contract, and the invoicing is required to be carried out based on the contract copies held by the two parties and the order copy party corresponding to the contract, the service certificates comprise three types.

The trade contract comprises any one of a sale contract and a purchase contract which are signed by two parties, and the trade document comprises any one of a purchase order and a purchase order.

S62: and determining billing service information according to the service certificate.

And after the business voucher is obtained, identifying the business voucher to determine billing business information. The billing service information at least comprises item description, purchase amount and seller basic information. The billing service information is information stored on the first enterprise alliance chain by the financial node and/or the service node according to the service transaction process between the buyer and the seller, and can be maintained and updated by the financial node and/or the service node together. If the subsidiaries of the enterprise corresponding to the first enterprise alliance chain also share the same block chain node, the current seller basic information needs to be determined according to the business certificate, and the ticket issuing error is avoided.

Wherein, the item description includes "goods, or taxable labor, service name", "specification model", "quantity", "unit price", and the purchase amount includes: the basic information of the seller comprises the name of the seller, the taxpayer identification number, the address, the account number of the bank of accounts and the like. If the specification type, the quantity and the unit are not embodied in the business certificate, the operation filling of financial staff can be embodied, default options can be directly selected, for example, the default of the quantity is 1, the default of the unit is 'unit', and the unit price can be automatically calculated according to the sum and the quantity and filled.

Further, determining billing service information according to the service certificate, including: acquiring billing service information according to the service certificate; and checking the billing service information to determine that the service transaction corresponding to the billing service information meets the billing condition. The billing business information is information stored on the first enterprise alliance chain by the financial node and/or the business node according to the business transaction process between the buyer and the seller.

Further, please refer to fig. 7, fig. 7 is a schematic flowchart of a method for processing bills according to another embodiment of the present application. In the present embodiment, the checking the billing service information in the above steps to determine that the service transaction corresponding to the billing service information meets the billing condition, further includes:

s71: and judging whether the purchaser completes the invoicing and applies for the fund payment of the corresponding business transaction.

And determining whether the purchaser completes the fund payment according to the acquired billing service information. Specifically, whether the corresponding money is received or not can be confirmed by uplink inquiry order number and/or contract number, and whether the received money is the same as the amount of money to be received in the service certificate or not is determined.

Furthermore, in other embodiments, the checking the billing service information further includes checking whether the service corresponding to the current billing application is billed, and if the current service is billed through the material loading query, stopping the billing process and feeding back the query result to the purchaser.

S72: it is further determined whether the purchaser basic information and the seller basic information are accurate.

If it is determined in step S71 that the buyer completes the fund payment for the business transaction corresponding to the invoicing application and does not apply for the current business, it is further determined whether the buyer basic information and the seller basic information are ready. The basic information of the purchaser obtained by analyzing the self-invoicing application can be compared with the basic information of the purchaser of the service voucher, and if the basic information of the purchaser is the same as the basic information of the purchaser, the basic information of the purchaser is judged to be accurate. The basic information of the seller can be directly compared with the basic information prestored in the local system, or the seller can be prompted to check in a pop-up window mode.

S73: if the determination is accurate, the business transaction is judged to be in accordance with the invoicing condition, and the verified business information is output.

If the basic information of the buyer and the basic information of the seller are determined to be accurate, the business transaction corresponding to the current invoicing application can be judged to accord with the invoicing condition, and the verified business information is output to generate the invoicing request. In the current embodiment, the basic information of the buyer and the basic information of the seller are verified, so that the information included in the invoicing request sent to the tax alliance chain can be ensured to be accurate and available, the process of invoicing is prevented from being delayed due to inaccuracy of the basic information, and the reliability and the invoicing efficiency can be improved better.

S63: and generating an invoicing request according to the basic information of the buyer, the basic information of the seller and the invoicing service information.

And filling the verified basic information of the buyer, the basic information of the seller and the invoicing service information into an invoicing request template, and packaging the invoicing request template into blocks to generate an invoicing request. Wherein, the invoicing request comprises: basic information of a purchaser, basic information of a seller, description of matters, purchase amount and basic information of the seller.

Referring to fig. 8, fig. 8 is a schematic flow chart of a bill processing method according to another embodiment of the present application. In the current embodiment, the method provided by the present application includes:

s81: and the financial node acquires an invoicing application sent by the purchaser.

S82: and analyzing the invoicing application to obtain the basic information of the purchaser and the service voucher corresponding to the invoicing application.

S83: and acquiring the billing service information according to the service certificate, and checking the billing service information to determine that the service transaction corresponding to the billing service information meets billing conditions.

In the current embodiment, step S81 is the same as step S51, step S82 is the same as step S61, and step S83 is the same as step S52 and steps included in the corresponding embodiment of fig. 7, and in particular, the descriptions of the corresponding parts above may be referred to, and are not repeated here.

S84: and if the business transaction corresponding to the invoicing business information accords with the invoicing condition, acquiring at least one invoice number section according to the invoicing application. Wherein, the invoice number section is a blank invoice number section without issuing. In the current embodiment, the invoice number field may be previously applied by the enterprise to the tax authority. It is understood that in other embodiments, the invoice number field may be issued in real time by the tax authority when the enterprise applies for invoicing.

If it is determined in step S83 that the service transaction corresponding to the invoicing service meets the invoicing condition, the financial node will obtain at least one invoice number segment according to the invoicing application. Further, at least one invoice number segment corresponding to the service is obtained according to the service corresponding to the invoicing application. If the invoice type corresponding to the service corresponding to the invoicing application is the value-added tax special invoice, the step S84 correspondingly acquires the invoice number of the value-added tax special invoice; if the invoice type corresponding to the service corresponding to the invoicing application is the common invoice, step S84 correspondingly obtains the invoice number of the common invoice.

Further, if the invoicing amount corresponding to the current invoicing application is larger than the limit defined by each invoice, the step S84 is preceded by calculating the number of invoices required to be invoiced, and the corresponding step S84 is to obtain the invoice number segment with the calculated number. And the total value of the maximum amount of the obtained invoice number segment is greater than or equal to the required invoicing amount. If the amount of money to be invoiced is 13 ten thousand, but the maximum amount of each invoice of the seller enterprise is limited to 5 ten thousand according to the requirement of the tax authority, 3 invoices are required at this time, and 3 invoice number segments are correspondingly obtained in step S84.

Further, because the number of the invoices declared to the tax authority by the enterprise every month is fixed, if the invoice number section is acquired and the invoice is not enough in the month, a reminder is sent to financial staff to declare a new invoice number section to the tax authority again.

Further, if the invoice number segment is used up in the month and a new invoice number segment is not issued by the tax authority at the moment, the method provided by the application further comprises the steps of suspending the invoicing process and feeding back the invoice that is used up and needs to wait for the invoice to be issued to the buyer. Furthermore, when the waiting time for the invoicing when the invoice is used up is fed back to the buyer, an estimated invoicing completion time can be given, so that the buyer can follow the invoicing process in time.

S85: and generating a billing request according to the acquired invoice number segment, the basic information of the buyer, the basic information of the seller and the billing service information.

And after the invoice number section is obtained, generating a billing request according to the obtained invoice number section, the basic information of the buyer, the basic information of the seller and the billing service information. In the current embodiment, the obtained invoice number field is directly written into the invoicing request and sent to the tax alliance chain.

S86: the invoicing request is sent to the master node for forwarding to the tax federation chain.

S87: acquiring invoice chain information generated by the tax alliance chain in response to the invoicing request, filling the invoice chain information into the bill format template to generate an invoice, and feeding the invoice back to the purchaser.

In the current embodiment, steps S86 and S87 are the same as steps S53 and S54, respectively, and may specifically refer to the explanation of the above corresponding parts, which are not repeated here.

Referring to fig. 9, fig. 9 is a schematic flowchart illustrating a method for processing a bill according to an embodiment of the present application. In the current embodiment, the method provided by the present application is applied to the tax alliance chain where the tax authority is located, and in the current embodiment, the method provided by the present application is described from the perspective of the tax alliance chain.

The tax alliance chain comprises a main node and an invoicing node, wherein the main node is used for collecting information in the alliance chain and also used for carrying out information interaction between the alliance chain and other alliance chains, the invoicing node is used for responding to invoicing requests sent by the enterprise alliance chain and generating invoice chain information, and the invoice chain information is key information in invoices and is information which needs to be generated by a tax authority. Other federation chains include at least enterprise federation chains. In the current embodiment, the method for processing the bill provided by the application comprises the following steps:

s91: the billing node receives a billing request received by the master node from the enterprise federation link.

And the billing node receives a billing request forwarded by the main node of the tax alliance chain. The invoicing request is a request message which is sent by a financial node in a enterprise alliance chain and is used for applying for invoicing.

S92: and analyzing the billing request to acquire the basic information of the seller, the service information and the basic information of the buyer.

And the billing node analyzes the received billing request to further obtain the basic information of the seller, the service information and the basic information of the buyer.

Further, in another embodiment, when the invoice number segment is included in the invoicing request, step S92 further includes parsing the invoicing request to obtain the invoice number segment, the basic information of the seller, the service information and the basic information of the buyer.

S93: and responding to the invoicing request to generate invoice chain information according to the basic information of the seller, the service information and the basic information of the buyer.

And responding to the invoicing request to generate invoice chain information according to the basic information of the seller, the service information and the basic information of the buyer. Wherein, invoice chain information includes at least: the two-dimension code content, the invoice code and number, the check code, the ciphertext area and other information.

Further, the generation rule of the invoice chain information may be generated based on an intelligent contract in the tax alliance chain, where the intelligent contract in the tax alliance chain is a contract set according to the current information generation rule of "two-dimensional code content, invoice code and number, check code, ciphertext area" and the like, and is stored in the tax alliance chain, and details thereof are not described herein.

S94: the invoice chain information is sent to the master node for forwarding to the seller's first enterprise federation chain.

After the invoicing node generates the invoice chain information, the invoice chain information is further sent to the main node to be forwarded to the first enterprise alliance chain of the seller. The billing node may directly send the generated invoice chain information to the tax alliance chain main node, and the tax alliance chain main node then sends the received invoice chain information to the first enterprise alliance chain.

In another embodiment, the invoicing node may also uplink and store the generated invoice chain information into the tax alliance chain, and then the tax alliance chain master node obtains the invoice chain information by accessing the tax alliance chain, and then sends the obtained invoice chain information to the master node of the first enterprise alliance chain. In other embodiments, the tax federation chain master node may also store the acquired invoice chain information to the main chain, and then the first enterprise federation chain accesses the main chain to acquire the invoice chain information and forward the invoice chain information to the financial node in the first enterprise federation chain. The main chain is a blockchain formed by the main nodes of different alliance chains in the blockchain system.

Furthermore, because enterprises in different areas are arranged under one tax alliance chain, in the technical scheme provided by the application, different enterprise alliance chains are divided according to areas in advance, and then the plurality of billing nodes are respectively associated with the enterprise alliance chains in different areas, so that after the tax alliance chain receives a billing request of the enterprise alliance chain, the billing request is directly forwarded to the corresponding billing node or the corresponding billing nodes, and the billing node automatically accepts the billing request.

Furthermore, as the number of invoices required by the enterprise every year is traceable, the estimated number of the current year can be determined specifically according to the past year operating condition of the enterprise, or the required number of invoices in each month is determined, after receiving the invoicing application, the invoicing node in the tax alliance chain further judges whether the number of invoices of the seller in the current month corresponding to the invoicing application reaches a number threshold value, if so, the invoicing of the seller is suspended and a reminder is sent to the seller, so that the seller reappears a new invoice number section, and if not, the invoicing process is continuously executed.

Further, in other embodiments, after receiving the billing request, the billing node further determines whether the amount of the seller in the current month is greater than or equal to an amount threshold based on the billing amount included in the billing application, if so, suspends billing for the seller and sends a reminder to the seller, so that the seller re-applies for the invoice amount, and if not, continues to execute the billing process.

Referring to fig. 10, fig. 10 is a schematic flow chart of an embodiment of a bill processing method according to the present application. In fig. 10, a schematic diagram of the interaction between the alliances of the seller, buyer and tax authority is shown in detail. In the current embodiment, the financial node is a node within the first enterprise federation chain and the billing node is a node within the tax federation chain. The method provided by the application comprises the following steps:

1. and acquiring a billing application directly sent by the buyer to the financial node or acquiring the billing application forwarded by the business node in the first enterprise alliance chain from the buyer.

2. And analyzing the invoicing application to obtain the basic information of the purchaser and the service voucher corresponding to the invoicing application.

3. And determining billing service information according to the service certificate.

4. And generating an invoicing request according to the basic information of the buyer, the basic information of the seller and the invoicing service information.

5. The invoicing request is sent to the master node for forwarding to the tax federation chain.

6. The primary node of the first enterprise federation chain forwards the billing request to the primary node of the tax federation chain.

7. And the tax alliance chain main node forwards the invoicing request to the invoicing node.

8. The billing node receives a billing request received by the master node from the enterprise federation link.

9. And analyzing the billing request to acquire the basic information of the seller, the service information and the basic information of the buyer.

10. And responding to the invoicing request to generate invoice chain information according to the basic information of the seller, the service information and the basic information of the buyer.

11. The invoice chain information is sent to the master node for forwarding to the seller's first enterprise federation chain.

12. And sending the invoice chain information to a main node of the first enterprise alliance chain.

13. And sending the invoice chain information to the main financial node.

14. And filling the invoice chain information into the bill layout template to generate an invoice, and feeding the invoice back to the buyer.

In the production and management of enterprises, bills are required to be reimbursed and posted frequently. In the process of reimbursing and posting a document, the problem of multiple reimbursements of one ticket often occurs, and the reimbursement often needs to be audited by multiple parties, so that the technical problems of complex reimbursement process, low efficiency and the like are caused by the matching of the multiple parties. In order to solve the technical problem, the application also provides a bill processing method.

Referring to fig. 11, fig. 11 is a schematic flowchart illustrating an embodiment of a method for processing a bill according to the present application. The bill processing method is applied to a block chain system comprising at least one alliance chain, wherein each alliance chain comprises an application node and an auditor node. It should be noted that, the reviewer node includes a financial node, and the method provided by the present application is applicable to any federation chain with reimbursement procedures, such as an enterprise federation chain, a utility federation chain, and a tax federation chain. The method provided by the application comprises the following steps:

s111: and the application node acquires the reimbursement service information and generates a reimbursement application based on the reimbursement service information.

Wherein, the application node is a node for lifting reimbursement application. Specifically, when a certain employee needs to complete a certain reimbursement task, the employee can log in a node account number with authority, fill in an reimbursement application form on the node, and lift the reimbursement application. Wherein the node is an application node. After the employee fills in the reimbursement request form and before the application node submits the reimbursement application, the application node firstly acquires reimbursement service information. The reimbursement service information is certificate information corresponding to items needing reimbursement. The credential information may specifically include a hash value of the credential, and may also include an image of the credential and a hash value of the image.

The user fills the reimbursement items and corresponding details in the reimbursement application form, and the reimbursement application form is an electronic application form. When the method is applied to enterprise units, the items required to be reimbursed at least comprise expense items paid for purchasing the enterprises, consumption items generated by public affairs and item reward items. The particulars corresponding to the reimbursement items at least include: when the reimbursement item occurs, if the reimbursement item is a project reward item, the detail corresponding to the reimbursement item correspondingly comprises a project name, a project period, a project type and a project total amount. Further, the details corresponding to the reimbursement items may further include document numbers or item numbers corresponding to the reimbursement items.

In one embodiment, the application node acquires reimbursement service information according to an reimbursement request form filled by an employee, and generates an reimbursement application based on the acquired reimbursement service information. Furthermore, the application node acquires the reimbursement service information on the alliance chain according to the reimbursement request form filled by the employee.

After the reimbursement service information is obtained, generating an reimbursement application by the reimbursement application table and the reimbursement service information, wherein the reimbursement application is a request sent by the application node to the auditor node.

Further, the reimbursement service information at least comprises: purchase voucher information and/or ticket voucher information. Referring to fig. 12, fig. 12 is a schematic flow chart of another embodiment of a bill processing method according to the present application. In the present embodiment, the step S111 of acquiring reimbursement service information by the application node, and generating a reimbursement application based on the reimbursement service information includes steps S121 and S122.

S121: and acquiring the purchasing voucher information and/or the bill voucher information needing reimbursement from the alliance chain.

If the bill is generated, the generated bill is uploaded to the alliance chain for uplink storage. If the purchase voucher and the bill voucher are stored in the alliance chain in advance, the application node can acquire the purchase voucher information and/or the bill voucher information required by reimbursement only by accessing the alliance chain. If the purchase voucher and/or the receipt voucher are made of traditional paper, the method provided by the application further comprises the following steps: the purchase voucher and/or the ticket voucher are processed by the image processing equipment to obtain electronic image data of the purchase voucher and/or the ticket voucher, and the electronic image data is linked and stored. In another embodiment, if the purchase voucher and/or the ticket voucher are stored in other external systems, the method provided by the present application further comprises: through the block chain system integration, the API interface is used for calling the information stored in other external systems.

Further, in other embodiments, when the party issuing the purchase credential or the ticket credential is also deployed in the federation chain, and the federation chain in which the party issuing the purchase credential or the ticket credential is placed and the current federation chain may perform data interaction, the purchase credential or the ticket credential may also be directly transmitted to the current federation chain through the federation chain in which the credential is issued, and the current federation chain is directly subjected to storage and chaining after being acquired.

The information of the purchase voucher at least comprises a hash value of the purchase voucher and an image of the purchase voucher, and the information of the bill voucher at least comprises a hash value of the bill voucher and an image of the bill voucher.

S122: and packaging and signing the purchase voucher information and/or the bill voucher information to generate a reimbursement application.

And packaging and signing the acquired purchase voucher information and/or the bill voucher information to generate a reimbursement application. In some embodiments, the reimbursement application may also be understood as an unsettled reimbursement accounting voucher.

It should be noted that if the reimbursement item only includes the purchase voucher information, the purchase voucher information is only required to be packaged and signed. In another embodiment, when the reimbursement item generates the purchase voucher information and the bill voucher information at the same time, the purchase voucher information and the bill voucher information are packaged and signed to generate the reimbursement application.

S112: and sending the reimbursement application to an auditor node associated with the reimbursement service for auditing.

And the number of the auditor nodes related to the reimbursement service is at least one. For example, if it is preset that the reimbursement application only requires the financial node for auditing, the auditor node associated with the reimbursement service only includes the financial node, so the reimbursement application only needs to be sent to the financial node for auditing.

In another embodiment, if it is determined that the reimbursement application requires the management node to perform a service audit and the financial node to perform a money audit, step S112 further includes sending the reimbursement application to the financial node and the management node for auditing the service. The order of sending the reimbursement application to the financial node and the management node for auditing the business is not limited, and the reimbursement application can be sent to the management node and the financial node for auditing according to actual setting. In other embodiments, the reimbursement application may be sent to the management node, and after the management node passes the application node or the management node, the application node or the management node sends the application node or the management node to the financial node for auditing. The intelligent contracts can be written in advance in the sequence of auditing the reimbursement applications.

S113: and judging whether the audit passing receipt of all the auditor nodes related to the reimbursement service is received.

After the reimbursement application is sent to the auditor nodes associated with the reimbursement service for auditing, the application nodes further monitor and judge whether the audit pass receipt of all the auditor nodes associated with the reimbursement service is received. And the audit passing receipt is sent to the application node to inform the application node that the audit of the reimbursement application is passed after the auditor node audits the reimbursement application.

In order to ensure the accuracy of reimbursement, step S113 needs to determine whether all the audit pass receipts sent by the auditor node associated with reimbursement service are received.

S114: and if so, requesting the financial node to execute the reimbursement application, generating an reimbursement accounting voucher and chaining and storing the reimbursement accounting voucher.

If the application node is judged to have received the audit pass receipt of all the auditor nodes related to the reimbursement service, the application node further requests the financial node to execute the reimbursement application and transfers reimbursement funds to the account of the reimbursement staff.

Further, in other embodiments, after the reimbursement application passes, the finance node automatically executes the reimbursement application without the request of the application node. It can be understood that the finance of the enterprise is the operation of carrying out fund according to the set time, and after the reimbursement application passes, the financial node can also record the fund items to be paid, and wait for the uniform payment of reimbursement amount.

Further, in another embodiment, in some enterprises, the reimbursement is sent directly and overlapping with the payroll when the payroll is sent, and the requesting financial node in the present application executes the reimbursement application including: and adding the checked reimbursement amount to the salary performance of the employee, and waiting for being issued together with the salary.

In the technical scheme provided in fig. 11 of the present application, an application node acquires reimbursement service information, generates an reimbursement application based on the reimbursement service information, and then sends the reimbursement application to an auditor node associated with the reimbursement service for auditing, and determines whether to receive an audit pass receipt of all auditor nodes associated with the reimbursement service; if the audit pass receipt of all the auditor nodes associated with the reimbursement service is judged to be received, the application node further requests the financial node to execute the reimbursement application, generates the reimbursement accounting voucher and links and stores the reimbursement accounting voucher.

Further, please refer to fig. 13, fig. 13 is a schematic flowchart illustrating an embodiment of a method for processing bills according to the present application. In the present embodiment, the step S122 packages and signs the purchase voucher information and/or the ticket voucher information, and the generating the reimbursement application includes:

s131: and identifying the image of the purchase voucher and/or the image of the bill voucher to acquire reimbursement information.

After the image of the purchase voucher and/or the image of the bill voucher are acquired, further identification is carried out to acquire reimbursement information. The algorithm for image recognition is pre-stored in the application node. The reimbursement information includes: the reimbursement amount and the reimbursement items are described.

132: and generating a reimbursement application form based on the reimbursement information and the reimbursement template.

In the current embodiment, the reimbursement application form is generated directly based on reimbursement information, the reimbursement template. Wherein, the reimbursement templates can be different according to different reimbursement types. Wherein, reimbursement type includes: personal reimbursement, project reimbursement, department reimbursement. Correspondingly, the reimbursement templates corresponding to various reimbursements can be obtained in advance.

In the current embodiment, the reimbursement type may be determined directly based on reimbursement information. If the purchase voucher is a voucher for personal payment for buying office supplies, the purchase voucher is determined to be personal reimbursement. If the reimbursement voucher is the prepaid funds required to be applied for the department project activity, the reimbursement type is determined as project reimbursement. It will be appreciated that in other embodiments, the determination of reimbursement type may also be based on other means.

In another embodiment, the reimbursement employee may directly write the reimbursement type, and then the application node obtains the corresponding reimbursement template based on the reimbursement type filled by the employee, and then generates the reimbursement application form.

133: and packaging and signing the reimbursement application form, the hash value of the purchase certificate and the hash value of the bill by using the private key to generate the reimbursement application.

After the reimbursement application form is generated, the application node encapsulates and signs the reimbursement application form, the hash value of the purchase voucher and the hash value of the bill voucher by using the private key, and then generates the reimbursement application. The private key is a key used by the node for encryption, and the receiving node can directly decrypt the reimbursement application by directly using the public key of the node stored by the receiving node.

Further, in other embodiments, when the application node generates the reimbursement application, it needs to synchronously determine an auditor of the reimbursement application. If the employee who submits the reimbursement application is the research and development department, the corresponding reviewer nodes which can be determined to obtain the reimbursement application at least comprise management nodes and financial nodes of the research and development department. It should be noted that, according to the preset, the reimbursement application may not be audited across departments, for example, the reimbursement application of the department a may not be audited by the management node of the department B.

Further, please refer to fig. 14, fig. 14 is a schematic flowchart illustrating an embodiment of a method for processing a bill according to the present application. In the current embodiment, the auditor node further includes at least one management node associated with the reimbursement service, and the method provided by the present application includes:

s141: and the application node acquires the reimbursement service information and generates a reimbursement application based on the reimbursement service information. Step S141 is the same as step S111, and is not repeated here, and the description of the corresponding parts above may be referred to specifically.

In the present embodiment, the step S122 of sending the reimbursement application to the auditor node associated with the reimbursement service for auditing further includes step S142 and step S143.

S142: and sending the reimbursement application to all management nodes associated with the reimbursement service for auditing.

In an embodiment, the auditor node further includes at least one management node associated with the reimbursement service, and step S142 may also be understood as sending the reimbursement application to all management nodes associated with the reimbursement service at the same time for auditing. The management node is at least used for carrying out service auditing on the reimbursement application so as to audit whether reimbursement items corresponding to the reimbursement application can be reimbursed.

In another embodiment, the reimbursement applications are sequentially sent to the management nodes associated with the reimbursement services for auditing according to the sequence set by the management nodes associated with the reimbursement services, and the sending is stopped until all the management nodes associated with the reimbursement services are sent. If the management nodes associated with the reimbursement service include Q, R and P, and the levels of Q, R and P are sequentially lowered, step S142 may be to send the reimbursement application to Q, R and P for auditing at the same time; or sent to P, R and Q for auditing in ascending order of rank.

Further, if the reimbursement application is sent to all management nodes associated with the reimbursement service for auditing, a consensus mechanism can be used among all management nodes associated with the reimbursement service to judge whether the management nodes finally pass the reimbursement application. For example, in an embodiment, when all management nodes associated with the reimbursement service pass the reimbursement application, the reimbursement application passes the audit, otherwise, if all management nodes associated with the reimbursement service do not pass, the application node determines that the reimbursement application does not pass the audit. In another embodiment, the checking result according to the node with the highest level is selected as the criterion, for example, P, R and Q are used, and if the node Q with the highest level passes the reimbursement application, the application node determines that the reimbursement application passes, otherwise, if the node Q with the highest level returns the reimbursement application, the reimbursement application fails.

S143: and if the returned examination passing receipts fed back by all the management nodes are received, the reimbursement application and the returned examination passing receipts fed back by all the management nodes are sent to the financial node for examination.

In the current embodiment, after sending the reimbursement application to all management nodes associated with the reimbursement service for auditing, the method provided by the present application further includes: if the audit passing receipt fed back by all the management nodes is received, the management nodes related to the reimbursement service consider the service of the current reimbursement application, and the management nodes do not disagree on reimbursement items in the reimbursement application. The application node sends the reimbursement application and the audits fed back by all the management nodes to the financial node audits through the receipt. Wherein, in the current embodiment, the financial node essentially audits the reimbursement amount. It is to be understood that in other embodiments, the finance node may also be used to audit the business and issues of the reimbursement application.

Further, in another embodiment, if the reviewer node includes a plurality of management nodes of different levels, and the financial node is a highest-level node among all the reviewer nodes, the corresponding step S112 further includes: and according to the level of the management node associated with the reimbursement service, sequentially sending reimbursement applications to the management nodes of different levels from low to high for auditing.

And when the audit of the low-level management node is passed, the reimbursement application is sent to the high-level management node. In the current embodiment, the low and high levels of a node are relative concepts, i.e., results of only two-by-two level comparisons. For example, although the levels of the management nodes Q, R and P in the above example are higher than those of other common nodes (non-management nodes), in the auditing process for reimbursement applications, the level of the management node Q is higher than that of the management node R, the level of the management node R is higher than that of the management node P, and reimbursement applications are sent to the management nodes Q, R and P for auditing. After each node audits the reimbursement application, signatures are correspondingly carried out so as to track audit records and audit processes.

S144: and if the returned receipt of the audit pass of the financial node is received, requesting the financial node to execute the reimbursement application, generating an reimbursement accounting voucher and uploading and storing the reimbursement accounting voucher.

In the current embodiment, the reimbursement execution is required for the application node to send a request. It is to be understood that in other embodiments, the reimbursement application may be executed directly by the financial node if the reimbursement application is approved.

It should be noted that step S144 is the same as step S114 and its corresponding embodiment, and specifically, it can be described in detail with reference to the above corresponding portions, and is not repeated here.

Further, if after step S143, if a return reimbursement request receipt sent by a management node or a financial node is received, the method provided by the present application further includes: and generating a return reminder to prompt a user to adjust the reimbursement application. If the current reimbursement application cannot pass and return after being checked by a certain management node or financial node, the receiving node generates a return prompt to prompt a user to adjust the reimbursement application. Further, after the application node generates the return reminder, the return reminder is further sent to the application node association terminal.

Further, in an embodiment, if a reimbursement request from the user is received, the reimbursement request from the user is directly sent to the returned node. In the current embodiment, the efficiency of reimbursement auditing can be better improved by directly sending the reimbursement application proposed by the design user to the returned node.

Furthermore, when the auditing party node returns the reimbursement application, the node selected to be resubmitted can be given. Specifically, if the auditor determines that another node needs to be audited again, a corresponding node may be selected for the reimbursement application, and when the reimbursement application is proposed again by a corresponding user, the reimbursement application may be directly forwarded to the returned and reauthorized node selected by the returned node.

Further, in another embodiment, if a reissued reissue application from the user is received, the reissued reissue application from the user is sent to the lowest-level management node for review. In the current embodiment, the reimbursement application newly proposed by the user is sent to the management node of the lowest level for reexamination through design, so that all the management nodes reexamine the reimbursement application after updating and adjusting, and the reliability of reimbursement and audit can be better improved.

Referring to fig. 15, fig. 15 is a schematic flow chart of an embodiment of a bill processing method according to the present application. The method is applied to a block chain system comprising at least one alliance chain, wherein each alliance chain comprises an application node and a verifier node, and the verifier node comprises a financial node, and the method comprises the following steps:

s151: and the financial node receives the reimbursement application sent by the application node.

The financial node can receive the reimbursement application directly sent by the application node. In another embodiment, the financial node may further send the reimbursement application to the alliance chain for uplink, and then the auditor node obtains the reimbursement application through uplink access, thereby auditing the reimbursement application.

S152: and auditing the reimbursement application according to the intelligent contract to judge whether the reimbursement application conforms to a preset reimbursement system.

Wherein, the intelligent contract is a contract preset and stored according to a reimbursement system. Because different enterprises and units have different reimbursement systems, corresponding intelligent contracts are different.

S153: and if so, generating an audit passing receipt, sending the audit passing receipt to the application node, and responding to the reimbursement application.

If the intelligent contract judges that the reimbursement application conforms to the preset reimbursement system, an audit passing receipt is generated and sent to the application node, and the reimbursement application is responded. In one embodiment, responding to the reimbursement application includes paying the reimbursement amount to the reimbursement application employee. In another embodiment, if reimbursement is sent directly and superimposed on payroll at payroll time, the application for reimbursement in response herein includes: and adding the checked reimbursement amount to the salary performance of the employee, and waiting for being issued together with the salary.

Further, after responding to the reimbursement application, the method further comprises: and generating an audited reimbursement certificate corresponding to the reimbursement application, and storing the audited reimbursement certificate to the alliance chain. The audited reimbursement voucher can be used as basic data for compiling financial statement reports and report analysis by the financial department and compiling enterprise budget, so that the enterprise can be helped to execute abnormal expense reimbursement early warning and lean budget management according to historical expense reimbursement financial information. Meanwhile, the financial analysis report can also provide references for business decision and business strategic planning for the high level of the enterprise.

S154: and if not, generating a return reimbursement application receipt.

And if the intelligent contract judges that the reimbursement application does not conform to the preset reimbursement system, generating a return reimbursement application receipt and sending the return receipt to the application node.

Furthermore, the auditor node further includes at least one management node associated with the reimbursement service, and the financial node receives the reimbursement application sent by the application node, and further includes:

and the financial node receives the reimbursement application which is approved by the management node, and the reimbursement application which is approved by the management node is sent to the financial node by the management node or the application node. In the present embodiment, prior to the financial node auditing the reimbursement application, a service audit is also performed on the reimbursement application by at least one management node associated with the reimbursement service.

It is noted that the intelligent contracts mentioned in the above embodiments are for automatic approval of business and audit costs. When the intelligent contract automatically approves the business and the checking cost, the system, the rule and various limiting conditions of cost reimbursement of the enterprise and the unit need to be compiled by using codes and submitted to a alliance chain.

For example, for an office computer with a reimbursement amount of only 7500 yuan for employees on a non-research and development station, the key conditions are "non-research and development station", "reimbursement for the office computer", "no more than 7500", and when the audit process of the intelligent contract is executed, the audit process is responsible for acquiring the service information or the fee amount information included in the reimbursement application after the audit node receives the reimbursement application, then executing the audit process in the contract code, and automatically completing the storage and query work of the service information, the fee amount information and the approval transaction information.

The intelligent contract generation mainly comprises the steps of compiling a preset data structure and a preset association rule into source codes according to a fee reimbursement system and rules, presetting reimbursement personnel basic information, consumption unit related information, tax agency related information and bank related information, automatically deducing contract generation conditions according to the codes by the alliance chain, automatically matching contents such as a reimbursement range and reimbursement standards of related business data according to the codes, and checking and verifying the contents with electronic data signature identities, so that the purpose of automatic verification is achieved. When a expense reimbursement application occurs, data information is uploaded to a management node and a financial node which are related to the reimbursement application in a alliance chain, and then a responsible person of the management node and a responsible person of the financial are automatically completed by the intelligent contract according to the authority of the responsible person and the responsible person of the financial management node. If the automatic audit has problems, submitting the corresponding node for manual audit, after the audit is passed, storing the audit result into the block chain, and adding a timestamp for storage.

In one embodiment, if there is a service to be reimbursed, the application node first obtains reimbursement service information previously stored in the chain, such as Hash value of purchase voucher (including traditional electronic invoice and blockchain electronic invoice), etc., obtains Hash value of traditional electronic invoice from the chain, or obtains transaction Hash value of blockchain electronic invoice from the chain, the application node uses its own private key to package and digitally sign the reimbursement service information and the invoice information packaged together, and generates reimbursement application, and then executes reimbursement application on the alliance chain, and forms an un-credited reimbursement document.

The application for reimbursement is sent to a plurality of department management nodes (namely associated department managers) associated with reimbursement services, the nodes applying for reimbursement from the street to the street decrypt the reimbursement application by using the public keys of the application nodes, hash values in the application nodes are extracted, the hash values are compared with the hash values on the chain for verification, whether the corresponding reimbursement services are reimbursement services or not is verified, and the situation of repeated reimbursement or one ticket with multiple reports is avoided. If the hash value is successfully verified, the business approval is automatically executed through the intelligent contract, and if the business approval passes, the business approval is updated to an approved reimbursement document.

The reimbursement application is synchronously transmitted to the financial node, the node decrypts the reimbursement application by using the public key of the application node to obtain the reimbursement charge amount, and the reimbursement charge amount is compared with the service occurrence amount of the chain deposit certificate (namely the amount of money corresponding to the bill certificate or the purchase certificate stored on the chain); if the verification is successful, the expense audit is automatically executed through the intelligent contract (whether the expense reimbursement amount, reimbursement subjects and expense attribution departments have enough budgets and the like are audited mainly according to the reimbursement system), and the reimbursement application is updated into the audited reimbursement receipt after the audit is passed.

In the current embodiment, the receipt is valid only after the reimbursement application passes the audits of all the auditor nodes and the receipt of the audits of all the auditor nodes is accepted, and the reimbursement application can be executed by the financial node to pay the corresponding reimbursement amount. Wherein, the auditing of the reimbursement application at least comprises: service approval and expense auditing.

Further, the method provided by the present application further includes: depending on the audited reimbursement document, an audited reimbursement voucher can be generated.

Referring to fig. 16, fig. 16 is an interactive schematic diagram of a bill processing method according to the present application. FIG. 16 highlights the interaction between the application node and the audit node for reimbursement.

1. And acquiring the purchasing voucher information and/or the bill voucher information needing reimbursement from the alliance chain.

2. And packaging and signing the purchase voucher information and/or the bill voucher information to generate a reimbursement application.

3. And according to the level of the management node associated with the reimbursement service, sequentially sending reimbursement applications to the management nodes of different levels from low to high for auditing.

4. And when the audit of the low-level management node is passed, sending the reimbursement application to the high-level management node.

5. And if the returned examination passing receipts fed back by all the management nodes are received, the reimbursement application and the returned examination passing receipts fed back by all the management nodes are sent to the financial node for examination.

6. And the financial node receives the reimbursement application sent by the application node.

7. And auditing the reimbursement application according to the intelligent contract to judge whether the reimbursement application conforms to a preset reimbursement system.

8. If the request is in accordance with the request, generating a receipt passing the audit and sending the receipt to the application node, and responding to the reimbursement application, or if the request is not in accordance with the request, generating a return receipt for reimbursement application.

9. And generating the reimbursement accounting voucher and uplink-storing the reimbursement accounting voucher.

Referring to fig. 17, fig. 17 is a schematic structural diagram of an embodiment of an electronic device according to the present application. In the present embodiment, the electronic device 1700 provided herein includes a processor 1701 and a memory 1702 coupled. Electronic device 1700 may be a block chain node that executes the method described in any one of embodiments of fig. 3 to 4 and corresponding embodiments thereof, electronic device 1700 may also be a block chain node that executes the method described in any one of embodiments of fig. 5 to 7 and corresponding embodiments thereof, and electronic device 1700 may also be a block chain node that executes the method described in any one of embodiments of fig. 8 to 13 and corresponding embodiments thereof.

The memory 1702 includes a local storage (not shown) and stores a computer program, and the computer program implements the method described in any one of the embodiments of fig. 1 to 9 and the corresponding embodiments when executed.

A processor 1701 is coupled to the memory 1702, the processor 1701 being configured to execute a computer program to perform the method as described above with respect to any one of the embodiments of fig. 1-16 and their counterparts.

Referring to fig. 18, fig. 18 is a schematic structural diagram of an embodiment of a computer-readable storage medium according to the present application. The computer-readable storage medium 1800 stores a computer program 1801 capable of being executed by a processor, the computer program 1801 being configured to implement the method as described in any one of the embodiments of fig. 1 to 16 and their counterparts above. Specifically, the computer-readable storage medium 1800 may be one of a memory, a personal computer, a server, a network device, or a usb disk, and is not limited herein.

The above description is only for the purpose of illustrating embodiments of the present application and is not intended to limit the scope of the present application, and all modifications of equivalent structures and equivalent processes, which are made by the contents of the specification and the drawings of the present application or are directly or indirectly applied to other related technical fields, are also included in the scope of the present application.

Claims

1. A method for controlling a blockchain system, the blockchain system comprising at least one federated chain comprising a number of nodes, wherein the number of nodes comprise a primary node and a backup node, the method comprising:

2. The method of claim 1, wherein after determining whether the master node has failed, the method further comprises:

and if so, directly replacing the main node until the main node is recovered to be normal.

3. The method of claim 1 or 2, wherein after replacing the master node, the method further comprises:

selecting one node from the plurality of nodes as a new standby node; or

Selecting a candidate node from at least one candidate node as the new standby node, wherein the candidate node is selected from the plurality of nodes.

4. The method of claim 3, further comprising:

and selecting at least one node as a candidate node based on the storage capacity and/or the performance score of each node in the alliance chain.

5. The method of claim 2, wherein after the directly replacing the master node, the method further comprises:

judging whether the replaced main node is recovered to be normal or not;

and if so, stopping replacing the main node.

6. The method of claim 5, wherein the blockchain system comprises a plurality of federation chains, and wherein after ceasing to replace the master node, the method further comprises:

and sending the block information stored when the preset information processing is executed to the main node which recovers to be normal, so that the main node which recovers to be normal stores the block information into a block.

7. The method of claim 1, wherein after determining whether the master node has failed, the method further comprises:

and if the main node is judged to have a fault, recording the fault of the main node, and updating the performance score of the main node according to the fault record of the main node.

8. The method of claim 1, further comprising:

if an access request of a new node is received before the master node is replaced, feeding back the address of the master node to the new node so that the new node sends the access request to the master node according to the address of the master node; or

And if an access request of a new node is received after the master node is replaced, checking the identity of the new node according to the access request, and broadcasting the public key address of the new node in the alliance chain so that all nodes in the alliance chain can determine whether the access request passes through or not.

9. An electronic device, comprising a memory and a processor coupled, wherein,

the memory includes local storage and stores a computer program;

the processor is configured to run the computer program to perform the method of any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that it stores a computer program executable by a processor for implementing the method of any one of claims 1 to 8.