CN116150260A

CN116150260A - Data processing method, device, medium and electronic equipment of block chain system

Info

Publication number: CN116150260A
Application number: CN202111394528.8A
Authority: CN
Inventors: 朱耿良
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-11-23
Filing date: 2021-11-23
Publication date: 2023-05-23

Abstract

The embodiment of the application provides a data processing method, a device, a medium and electronic equipment of a blockchain system. The blockchain system comprises a main chain and at least one sub-chain, wherein each sub-chain is derived from a block height position in the main chain, a main chain relay contract is arranged in each sub-chain, a main chain block head is stored in the main chain relay contract, and configuration information is contained in the main chain block head, and the data processing method comprises the following steps: acquiring configuration information of a main chain from a main chain relay contract when a new service block is required to be generated for a specified sub-chain; if the configuration information of the main chain is inconsistent with the configuration information of the designated sub-chain, updating the configuration information of the designated sub-chain through the configuration information of the main chain; and if the configuration information of the main chain is consistent with the configuration information of the designated sub-chain, packaging to generate a new service block and carrying out consensus uplink processing. The technical scheme of the embodiment of the application can realize global unified configuration and management of a plurality of blockchains in a scene of the blockchains.

Description

Data processing method, device, medium and electronic equipment of block chain system

Technical Field

The present invention relates to the field of computers and communications technologies, and in particular, to a data processing method, apparatus, medium and electronic device for a blockchain system.

Background

In the related art, a blockchain system generally includes a blockchain, and all transaction information submitted by service nodes in the blockchain system needs to be recorded on the blockchain. Because all transaction information needs to be written into the same blockchain, the blockchain stores transaction information corresponding to different services, and further, different services on the blockchain cannot be effectively distinguished. Based on this, a technical solution for setting a plurality of blockchains is also proposed in the related art, but for a scenario of a plurality of blockchains, how to globally and uniformly configure the plurality of blockchains is a technical problem to be solved.

Disclosure of Invention

The embodiment of the application provides a data processing method, a device, a medium and electronic equipment of a blockchain system, and further, global unified configuration and management of a plurality of blockchains in a scene of the plurality of blockchains can be realized at least to a certain extent.

Other features and advantages of the present application will be apparent from the following detailed description, or may be learned in part by the practice of the application.

According to an aspect of the embodiments of the present application, there is provided a data processing method of a blockchain system, where the blockchain system includes a main chain and at least one sub-chain, each of the sub-chains is derived from a block height in the main chain, a main chain relay contract is disposed in each of the sub-chains, a main chain block header is stored in the main chain relay contract, and configuration information is included in the main chain block header, and the data processing method includes: acquiring configuration information of the main chain from the main chain relay contract when a new service block is required to be generated for a specified sub-chain; if the configuration information of the main chain is inconsistent with the configuration information of the appointed sub-chain, updating the configuration information of the appointed sub-chain through the configuration information of the main chain; and if the configuration information of the main chain is consistent with the configuration information of the appointed sub-chain, packaging to generate a new service block and carrying out consensus uplink processing.

According to an aspect of the embodiments of the present application, there is provided a data processing apparatus of a blockchain system, the blockchain system including a main chain and at least one sub-chain, each of the sub-chains being derived from a blockheight in the main chain, each of the sub-chains having a main chain relay contract disposed therein, the main chain relay contract having a main chain block header stored therein, the main chain block header including configuration information therein, the data processing apparatus comprising: an acquisition unit configured to acquire configuration information of the main chain from the main chain relay contract when a new traffic block needs to be generated for a specified sub-chain; the first processing unit is configured to update the configuration information of the appointed sub-chain through the configuration information of the main chain if the configuration information of the main chain is inconsistent with the configuration information of the appointed sub-chain; and the second processing unit is configured to pack and generate a new service block and perform consensus uplink processing if the configuration information of the main chain is consistent with the configuration information of the designated sub-chain.

In some embodiments of the present application, based on the foregoing solution, the first processing unit is configured to: taking the configuration information of the main chain as configuration transaction information to generate a configuration updating block; and performing consensus uplink processing on the configuration update block to add the configuration update block into the specified sub-chain.

In some embodiments of the present application, based on the foregoing solution, the configuration update block further includes: transaction information for updating the configuration information version number of the designated sub-link in the main link relay contract.

In some embodiments of the present application, based on the foregoing solution, the main chain block header further includes a configuration information version number; the first processing unit is configured to: and if the configuration information version number of the main chain is inconsistent with the configuration information version number of the appointed sub-chain, determining that the configuration information of the main chain is inconsistent with the configuration information of the appointed sub-chain.

In some embodiments of the present application, based on the foregoing scheme, the designated sub-chain runs a backbone relay service at start-up, the backbone relay service is configured to obtain the backbone block header and submit the backbone block header to the backbone relay contract.

In some embodiments of the present application, based on the foregoing solution, the backbone relay contract further includes a latest update time of the backbone block header; the second processing unit is further configured to: and when a new service block needs to be generated for the appointed sub-chain, if the time difference between the local time and the latest updating time exceeds a set threshold value, suspending the common identification processing of the new service block.

In some embodiments of the present application, based on the foregoing solution, the second processing unit is further configured to: after the common-knowledge processing is suspended on the new service block, if the time difference between the local time and the latest updating time is detected to be smaller than the set threshold value and the configuration information of the main chain is consistent with the configuration information of the appointed sub-chain, the common-knowledge uplink processing is carried out on the service block generated by packing.

In some embodiments of the present application, based on the foregoing scheme, the main chain relay contract deployed in each of the sub-chains is deployed in a first block derived on each of the sub-chains.

In some embodiments of the present application, based on the foregoing, the blockchain system includes a billing node network, a service node network, and a proxy node network connected between the billing node network and the service node network; the proxy node network is used for receiving the transaction information to be uplink from the service node network, and forwarding the transaction information to be uplink to the accounting node network for packing and uplink processing; the network of accounting nodes is configured to maintain the backbone and the at least one sub-chain.

In some embodiments of the present application, based on the foregoing, the backbone and the at least one sub-chain are maintained by the same accounting node in the accounting node network; or the main chain and the at least one sub-chain are maintained by different clusters of accounting nodes in the network of accounting nodes, respectively.

In some embodiments of the present application, based on the foregoing solution, the main chain block header further includes a configuration information version number, and the data processing apparatus further includes: the third processing unit is configured to generate a global configuration block and update a configuration information version number in a block header of the global configuration block if the configuration information of the main chain needs to be updated; the global configuration block is subjected to a consensus uplink process to add the global configuration block to the backbone.

According to one aspect of the embodiments of the present application, there is provided a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a data processing method of a blockchain system as described in the above embodiments.

According to an aspect of an embodiment of the present application, there is provided an electronic device including: one or more processors; and a storage means for storing one or more programs that, when executed by the one or more processors, cause the electronic device to implement the data processing method of the blockchain system as described in the above embodiments.

According to an aspect of embodiments of the present application, there is provided a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the data processing method of the blockchain system provided in the various alternative embodiments described above.

In the technical solutions provided in some embodiments of the present application, the blockchain system includes a main chain and at least one sub-chain, where each sub-chain is derived from a block height in the main chain, so that different services can be effectively distinguished by different blockchains, so as to ensure specificity of storing transaction information for each chain. Meanwhile, as the main chain relay contracts are distributed in each sub-chain, the main chain relay contracts store main chain block heads which contain configuration information, when new service blocks are required to be generated for the designated sub-chains, if the configuration information of the main chain acquired from the main chain relay contracts is inconsistent with the configuration information of the designated sub-chains, the configuration information of the designated sub-chains is updated through the configuration information of the main chain, and when the configuration information of the main chain is consistent with the configuration information of the designated sub-chains, the new service blocks are generated in a packing mode and the common uplink processing is carried out, so that the main chain block heads can be stored through the main chain relay contracts, the tracking of main chain data is realized, and the synchronization of the sub-chains to the main chain configuration information is further ensured; meanwhile, as the sub-chains need to carry out dependency verification on the configuration information of the main chain when sharing the uplink, the service control of the main chain on the configuration of each sub-chain is ensured, and the global unified configuration and management of a plurality of block chains in a scene of the plurality of block chains are realized.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application. It is apparent that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art. In the drawings:

fig. 1 shows a schematic diagram of a blockchain network.

FIG. 2 illustrates a schematic diagram of the connection of blocks in a blockchain.

Fig. 3 shows a schematic diagram of a process for generating one block.

Fig. 4 to 6 show architecture diagrams of a blockchain system to which embodiments of the present application are applied.

FIG. 7 shows a schematic diagram of an electronic invoice system according to one embodiment of the application.

Fig. 8 shows a schematic diagram of a multi-chain scenario according to one embodiment of the present application.

FIG. 9 illustrates a flow chart of a data processing method of a blockchain system in accordance with an embodiment of the present application;

FIG. 10 illustrates a schematic diagram of information synchronization of a main chain and a sub-chain according to one embodiment of the present application;

FIG. 11 illustrates a block diagram of a data processing apparatus of a blockchain system in accordance with an embodiment of the present application;

fig. 12 shows a schematic diagram of a computer system suitable for use in implementing the electronic device of the embodiments of the present application.

Detailed Description

Example embodiments are now described in a more complete manner with reference being made to the figures. However, the illustrated embodiments may be embodied in various forms and should not be construed as limited to only these examples; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present application. However, it will be recognized by one skilled in the art that the present application may be practiced without all of the specific details of the embodiments, that one or more specific details may be omitted, or that other methods, components, devices, steps, etc. may be used.

The block diagrams depicted in the figures are merely functional entities and do not necessarily correspond to physically separate entities. That is, the functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the elements and operations/steps, nor must they be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.

It should be noted that: references herein to "a plurality" means two or more. "and/or" describes an association relationship of an association object, meaning that there may be three relationships, e.g., a and/or B may represent: a exists alone, A and B exist together, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship.

Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. Blockchains are essentially a de-centralized database, which is a series of data blocks (i.e., blocks) that are generated in association using cryptographic methods, each of which contains information from a batch of network transactions for verifying the validity (anti-counterfeiting) of the information and generating the next block. The blockchain may include a blockchain underlying platform, a platform product services layer, and an application services layer.

The blockchain underlying platform may include processing modules for user management, basic services, smart contracts, operation monitoring, and the like. The user management module is responsible for identity information management of all blockchain participants, including maintenance of public and private key generation (account management), key management, maintenance of corresponding relation between the real identity of the user and the blockchain address (authority management) and the like, and under the condition of authorization, supervision and audit of transaction conditions of certain real identities, and provision of rule configuration (wind control audit) of risk control; the basic service module is deployed on all block chain node devices, is used for verifying the validity of a service request, recording the service request on a storage after the effective request is identified, for a new service request, the basic service firstly analyzes interface adaptation and authenticates the interface adaptation, encrypts service information (identification management) through an identification algorithm, and transmits the encrypted service information to a shared account book (network communication) in a complete and consistent manner, and records and stores the service information; the intelligent contract module is responsible for registering and issuing contracts, triggering contracts and executing contracts, a developer can define contract logic through a certain programming language, issue the contract logic to a blockchain (contract registering), invoke keys or other event triggering execution according to the logic of contract clauses to complete the contract logic, and simultaneously provide a function of registering contract upgrading; the operation monitoring module is mainly responsible for deployment in the product release process, modification of configuration, contract setting, cloud adaptation and visual output of real-time states in product operation, for example: alarms, monitoring network conditions, monitoring node device health status, etc.

The platform product service layer provides basic capabilities and implementation frameworks of typical applications, and developers can complete the blockchain implementation of business logic based on the basic capabilities and the characteristics of the superposition business. The application service layer provides the application service based on the block chain scheme to the business participants for use.

Referring to the blockchain network shown in fig. 1, a plurality of nodes 101 may be included in the blockchain network, and the plurality of nodes 101 may be individual clients forming the blockchain network. Each node 101 may receive input information while operating normally and maintain shared data within the blockchain network based on the received input information. In order to ensure information intercommunication in the blockchain network, information connection can exist between every two nodes in the blockchain network, and information transmission can be carried out between the nodes through the information connection. For example, when any node in the blockchain network receives input information, other nodes in the blockchain network acquire the input information according to a consensus algorithm, and store the input information as shared data, so that the data stored on all nodes in the blockchain network are consistent.

For each node in the blockchain network, there is a node identification corresponding thereto, and each node in the blockchain network may store the node identifications of other nodes for subsequent broadcasting of the generated blocks to other nodes in the blockchain network based on the node identifications of the other nodes. Each node can maintain a node identification list, and the node names and the node identifications are correspondingly stored in the node identification list. The node identifier may be an IP (Internet Protocol, protocol interconnecting between networks) address, or any other information that can be used to identify the node.

Each node in the blockchain network stores one and the same blockchain. The blockchain is composed of a plurality of blocks, as shown in fig. 2, and the starting block comprises a block head and a block main body, wherein the block head stores an input information characteristic value, a version number, a timestamp, a difficulty value and the like, and the block main body stores input information; the next block of the starting block takes the starting block as a father block, the next block also comprises a block head and a block main body, the block head stores the input information characteristic value of the current block, the block head characteristic value, the version number, the timestamp, the difficulty value and the like of the father block, and the like, so that the block data stored in each block in the block chain are associated with the block data stored in the father block, and the safety of the input information in the block is ensured.

When each block in the blockchain is generated, referring to fig. 3, when the node where the blockchain is located receives input information, checking the input information, after the checking is completed, storing the input information into a memory pool, and updating a hash tree used for recording the input information; and updating the update time stamp to the time of receiving the input information, trying different random numbers, calculating the characteristic value for a plurality of times, and when the random numbers meeting the conditions are calculated, correspondingly storing the information to generate a block head and a block main body to obtain the current block. And then, the node where the blockchain is located sends the newly generated blocks to other nodes in the data sharing system where the newly generated blocks are located according to the node identification of other nodes in the data sharing system, the other nodes verify the newly generated blocks, and the newly generated blocks are added into the blockchain stored by the newly generated blocks after the verification is completed. Wherein, the node can perform consensus verification on the newly generated block through a consensus algorithm, and the consensus algorithm can comprise but is not limited to:

Pow (Proof of Work): workload certification refers to a metric set by a system (such as the blockchain network system described above) to achieve a certain goal. A simple understanding is a proof to confirm the workload. What is essentially who does much more, who has a better chance to get the bonus. In the PoW algorithm, each node provides computing power (abbreviated as computing power) for the whole system, and the node with the most excellent completion of computing work obtains rewards of the system, namely obtains accounting rights through a competition mechanism.

Pos (proof of interest): pos equity proof is an upgrade consensus mechanism for Pow workload proof; specifically, the longer the time it takes to hold an electronic resource (the length of time it takes to hold an electronic resource=the number of electronic resources that the electronic resource is held) the more opportunistically it is to acquire the billing right of the block, wherein an electronic resource may be a resource stored in an electronic account in an electronic form and capable of being circulated through the internet.

DPos (Delegated Proof of Stake, delegated rights proving) share authorization proving mechanism: the DPos share authorization proof mechanism is similar to a board vote, where the object holding the electronic resource selects a certain number of nodes by voting, brokering them for checksum accounting. To motivate more nodes to participate in an auction, the system generates a small amount of electronic resources as rewards. The rights of the selected nodes to each other are exactly equal, and if the selected representatives cannot fulfill their duties (e.g. they turn around, no blocks can be generated), then the representatives will be renamed and the network will select new nodes to replace them, which enables the DPos share authorization proving mechanism to drastically reduce the number of participating checksum accounting nodes, which can reach a second level of consensus check, but the whole consensus mechanism still relies on electronic resources.

PBFT (Practical Byzantine Fault Tolerance, bayer fault tolerance algorithm): the PBFT bayer fault tolerance algorithm is a message transfer based consistency algorithm that agrees with three phases that may be repeated due to failure. Specifically, assuming that the total number of nodes is 3f+1, f is a Bayesian error node, first, when a node finds that a leader (such as a representative node, an accounting node or a super node) is bad, other replicas (nodes) are elected as a leader by an algorithm. Secondly, the leader broadcasts the value it selects to other replying nodes via a pre prepare message, and the other replying nodes send the prepare message if accepted and not if not accepted. Second, once 2f nodes accept the prepare message, the nodes send a commit message. Finally, when 2f+1 nodes accept the commit message, a value representing the value is determined. The process enables the pbft Bayesian and busy-court fault-tolerant algorithm to commonly know that each node is composed of a business party or a supervision party of the business, and the safety and the stability are ensured by a business related party; and the consensus time delay is about 2-5 seconds, so that the requirement of commercial real-time processing is basically met, the consensus efficiency is improved, and the requirement of high-frequency transaction amount can be met.

Paxos (a distributed algorithm) algorithm: the Paxos algorithm is a two-stage algorithm with three main roles, proposer, accept, learner. Proposer issues agreement, acceptance or rejection, and learner obtains the final value after consensus. The Paxos algorithm includes two phases, respectively: (1) the preparation stage: the proposer selects a proposal number n and sends a prepare request to a plurality of groups in the acceptance; after the receiver receives the request, if the number of the proposal is greater than all the requests which it has replied to, the receiver replies the last accepted proposal to the proposer and promises not to reply to the proposal smaller than n. (2) Approval stage: when one Proposer receives replies of a plurality of acceptors to the request, the approval stage is entered; it sends an accept request to the accept that replies to the prepare request, including the number n and value (if there is no value already accepted, it can decide value freely); the receiver receives the accept request without violating its own promise to other proposers. The Paxos algorithm is suitable for a simple fault-tolerant model, namely, only invalid or fault nodes exist in the system, no malicious node exists, and if the number of the invalid nodes is x (x is a positive integer), the normal operation of the system can be maintained only by the number of the non-invalid nodes being x+1.

Raft (a distributed consensus algorithm) algorithm: the Raft algorithm contains three roles, respectively: follower (follower), candidate (leader) and leader (leader). A node can only be one of these three states at a time, and these three roles can be switched over each other with time and changes in conditions. All nodes are in the initial state of a follow, the follow which does not receive a heartbeat packet after overtime changes into a candidiate and broadcasts a voting request, the node which obtains majority votes takes the avatar, the process of voting is who sends out the first, and each node only gives out one vote. The leader node periodically sends heartbeat packets to other nodes, and the failure of the leader node causes a new voting process.

Alternatively, each node in the blockchain network may be a server or a terminal device. The server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a Cloud server providing Cloud services, cloud databases, cloud Computing (Cloud Computing), cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs (Content Delivery Network, content distribution networks), basic Cloud Computing services such as big data and artificial intelligent platforms, and the like. The terminal device may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a smart home, a vehicle-mounted terminal, and the like. The nodes may be directly or indirectly connected through wired or wireless communication, which is not limited herein.

The cloud computing refers to a delivery and use mode of an IT infrastructure, and specifically refers to obtaining required resources in an on-demand and easily-expandable manner through a network; generalized cloud computing refers to the delivery and usage patterns of services, meaning that the required services are obtained in an on-demand, easily scalable manner over a network. Such services may be IT, software, internet related, or other services. Cloud Computing is a product of fusion of traditional computer and network technology developments such as Grid Computing (Grid Computing), distributed Computing (Distributed Computing), parallel Computing (Parallel Computing), utility Computing (Utility Computing), network storage (Network Storage Technologies), virtualization (Virtualization), load balancing (Load balancing), and the like. With the development of the internet, real-time data flow and diversification of connected devices, and the promotion of demands of search services, social networks, mobile commerce, open collaboration and the like, cloud computing is rapidly developed. Unlike the previous parallel distributed computing, the generation of cloud computing will promote the revolutionary transformation of the whole internet mode and enterprise management mode in concept.

Based on the blockchain technology, the embodiment of the application provides an architecture of a blockchain system. As shown in fig. 4, the blockchain system includes a network of accounting nodes 2 and a network of service nodes 1. The accounting node network 2 comprises accounting nodes 21 that agree on the data blocks and record the data blocks onto the blockchain. The service node network 1 comprises a service node 11, which service node 11 may verify the data blocks recorded by the accounting node onto the blockchain or may request corresponding transaction data from the accounting node.

Specifically, the service node 11 may verify the data block recorded by the accounting node onto the blockchain, which may include the following steps: a billing node 21 in the billing node network generates a signature based on transaction information to be included in a data chunk to be added to the blockchain using a key specific to the billing node; accounting node 21 adds the transaction information and the generated signature to the data block, adding to the blockchain; the accounting node 21 sends the signature to a service node in the service node network, which verifies the signature based on a key specific to the accounting node to enable the service node 11 to verify the data blocks recorded by the accounting node onto the blockchain. The accounting nodes in the accounting node network are responsible for recording the data blocks to the blockchain and the service nodes in the service node network are responsible for witnessing the results of the accounting node records. Specifically, the accounting node generates a signature based on transaction information to be included in one data chunk to be added to the blockchain, and then adds the transaction information and the generated signature to the data chunk for uplink. And transmitting the signature to a service node in the service node network, causing the service node to verify the signature based on a key specific to the accounting node. Service nodes in the service node network can witnesse the transaction data of the whole network by verifying the accounting node signature on the block. The accounting node network, while possessing monopolizing accounting rights, is publicly traceable in all acts because the data block has a digital signature representing the identity of the accounting party. If the accounting nodes act in aggregate, then all nodes in the service node network will retain evidence of the particular accounting node acting. Compared with the traditional centralized system and the private chain, the system in the embodiment of the application runs more transparently; compared with the traditional decentralization scheme, the scheme is more controllable and more convenient to monitor.

In one embodiment of the present application, the accounting node network 2 and the service node network 1 may be connected by means of a proxy node 12, the proxy node 12 may be a service node of the service node network 1, which is responsible for transferring information to be transferred by the accounting node 21 to the service node 11. The service node 11 is a terminal of a transaction party generating various transaction data to be uplinked, or a terminal of inquiring transaction data from the accounting node network 2. Transaction data generated by the service node 11 is transmitted to the accounting node 21 through the proxy node 12 and then recorded on the blockchain after being commonly recognized, so that unified processing and supervision of the transaction data are facilitated, and the service node 11 can also conduct uplink supervision and witness of the transaction data through information sent by the accounting node 21 through the proxy node 12, which is of great significance in certain scenes that nodes which need unified supervision and are afraid of supervision are cheated collectively, and therefore supervision is needed.

In the architecture shown in fig. 1, the service node network 1 adopts a P2P (Peer to Peer) network mode. P2P networks are a distributed application architecture that distributes tasks and workloads among peers, a form of networking or network that peer-to-peer computing models form at the application layer, i.e., a "point-to-point" or "end-to-end" network. It can be defined as: participants in the network share a portion of the hardware resources (processing power, storage power, network connectivity, printers, etc.) they own, which provide services and content through the network that can be accessed directly by other peer nodes without going through intermediate entities. The participants in this network are both providers of resources, services and content and acquisitors of resources, services and content. Therefore, in the service node network 1, when the proxy node 12 receives the message transmitted from the accounting node 21, the message propagates to the surrounding service nodes 11, and the surrounding service nodes 11 receive the message and then transmit the message to the surrounding service nodes 11, so that the message propagates between each service node 11 of the service node network 1.

FIG. 5 illustrates an architecture of another blockchain system used in the embodiments of the present application. The architecture differs from the architecture shown in fig. 4 in that: the P2P network mode is not adopted in the service node network 1, but the mode of the broadcast network is adopted. Specifically, the proxy node 12, upon receiving the message delivered from the accounting node 21, broadcasts the message to the other service nodes 11 in the service node network 1. In this way, propagation of the message between each service node 11 of the service node network 1 is also achieved.

FIG. 6 illustrates an architecture of another blockchain system to which embodiments of the present invention are applied. The architecture differs from the architecture shown in fig. 4 in that: the network of accounting nodes 2 is divided into a plurality of branched accounting node networks. Each branch billing node network may be responsible for the recording of some type of transaction information. For example, an enterprise may have a supply chain financial business, and may need to record information such as contract information, credit, etc. generated during the supply and distribution process to the blockchain, and also issue an invoice, and record information such as issue invoice, reimbursement invoice, etc. to the blockchain. At this time, in order to facilitate the need for the accounting node to be administered by the same department, the accounting node that records the supply chain financial business transaction and the accounting node that records the transaction during the invoice flow may be separate departments. For example, the accounting node that records supply chain financial transactions is a bank-set accounting terminal, and the accounting node that records transactions during invoice flows is a national tax office-set accounting terminal. And the supply chain financial business transactions and transactions during the recording invoice flows may also eventually be recorded on a different branch of the billing node network. At this time, the proxy node 12 transmits the transaction information to the branch accounting node network corresponding to the transaction type according to the transaction type carried in the transaction information transmitted from the service node 11.

It should be noted that, in the architecture of the blockchain system shown in fig. 4 to 6, the proxy node 12 is located in the service node network 1, and in other embodiments of the present application, the proxy node 12 may also be located in the consensus node network 2, or be independent from the service node network 1 and the consensus node network 2.

The architecture of the blockchain system shown in fig. 4 to 6 may be applied in the application scenario of electronic invoices, and is described in detail below:

in one embodiment of the present application, the accounting nodes in the accounting node network may be respective tax administration terminals, for example, the accounting node network is formed by tax administration terminals deployed in a plurality of regions as one accounting node respectively. Each service node in the service node network may be a local tax office terminal, an invoicing proxy server terminal, an invoicing enterprise terminal, a personal user terminal, etc.

Specifically, in the electronic invoice system shown in fig. 7, a service layer, a routing agent layer, and a consensus network (i.e., a billing node network, hereinafter, a billing network) layer may be included. The service layer is a service node network, and includes each service node, for example, a local tax office in a tax private network; billing service providers, reimbursement service providers, enterprises, etc. in public cloud; payment facilitators, circulation facilitators, businesses, etc. in the private cloud.

The routing proxy layer comprises proxy nodes, the proxy nodes provide functions of routing service, certificate caching and authentication service, P2P service and the like, and the routing proxy layer plays a role in isolating a service layer and a consensus network layer, and the technical scheme of the embodiment is specifically referred to. Alternatively, the agent nodes in the routing agent layer may be in a tax private network. The consensus network (accounting network) layer is an accounting node network, which includes a plurality of blockchains, although in other embodiments of the present application, the consensus network (accounting network) layer may also include one blockchain.

In one embodiment of the present application, a consensus network (accounting network) in an electronic invoice system may include multiple blockchains that may be time-sequential, such as time-sequential, for example, with the same business being identical for the business participants and both blockchains employing the same CA (Certificate Authority, authentication authority) center as the authentication and authorization party for the invoice business system. Of course, in an embodiment of the present application, the splitting may be performed according to different services, for example, service a corresponds to one blockchain, service B corresponds to one blockchain, and inter-link interaction may also be performed between services.

Alternatively, as shown in fig. 8, in an exemplary embodiment, the consensus network (the consensus network may be the consensus network shown in fig. 4 to 7, or may be a separate consensus network, that is, a consensus network obtained by not dividing a service network and a consensus network) may include a plurality of blockchains, specifically, a main chain 801, and N subchains derived from the main chain 801 at a block height, where N is a positive integer, and each time a new subchain is derived, a new chain identifier needs to be generated for the new subchain. For example, in fig. 8, backbone 801 may derive a sub-chain 802, a sub-chain 803, and a sub-chain 804. One sub-chain can correspond to one service, for example, in the tax service field, so that different transaction services can be effectively distinguished, so that the specificity of data stored by a single service branched chain can be kept, and specific services can be bill service, credit investigation service, import and export service, enterprise qualification service, tax refund service and the like.

In one embodiment of the present application, the main chain 801 in the consensus network may include registration information of a sub-chain corresponding to each service, where the registration information may include a chain identifier of the sub-chain, service configuration information corresponding to the service, a derivative condition corresponding to the chain identifier, and so on. Optionally, after each sub-link is generated, registration is required in a main chain, and an intelligent contract for managing registration of the sub-link is arranged in the main chain, and when the sub-link is registered, a link identifier can be allocated to the sub-link and registration information of the sub-link can be recorded.

Alternatively, the service configuration information corresponding to the service (e.g., ticket service) may include basic information of the service (i.e., description of the ticket service) and node configuration information (including service node configuration information and consensus node configuration information). The service node configuration information may include a node identifier configured by a common node with administrative authority (e.g., node 120a with administrative authority) for a corresponding service branch (e.g., a service branch corresponding to a ticket service), where the node identifier corresponds to a service node that may be used to execute the ticket service. The consensus node configuration information here may include a consensus node having administrative authority configured for the sub-chain for participating in consensus of the sub-chain.

Alternatively, the generation block of each sub-chain may be the block corresponding to the generation of the main chain, for example, as shown in fig. 8, the sub-chain 802 is derived from the block A1 in the main chain 801, where the generation block is A1; the subchain 803 is derived from block A2 in the main chain 801, which creates block A2; the sub-chain 804 is derived from block A3 in the main chain 801, which creates block A3. When verifying the sub-chain blocks, the A chain can be found from the generated blocks of the sub-chain, and then verified to the generated blocks of the A chain (such as the Merker tree), so that the verification reliability is improved. Of course, if the local of the consensus node has synchronized the A-chain, then the verification of the sub-chain block may only verify its creation block on the A-chain.

Alternatively, if the configuration information of the blockchain node system (e.g., tax blockchain system) corresponding to the entire blockchain network changes, the consensus nodes in the consensus network need to be suspended. If the configuration information with information changes is referred to as configuration change information, the configuration change information may refer to regulatory rules for tax domain categories, computing regulatory changes, important block link point changes, chain certificate issuing node rotations, and the like. The common node with the supervision authority in the common network can generate a configuration change block based on the configuration change information, and further uplink the configuration change block to the main chain 801 in the common network and synchronize to all sub-chains, at this time, other common nodes in the common network can resume operation. As shown in fig. 8, assuming that the configuration information is changed, a configuration change block A3 is generated in the main chain 801, and then synchronization is performed in the sub-chain, such as a block B5 in the sub-chain 802, and a block C4 in the sub-chain 803.

Alternatively, for the system architecture shown in fig. 4 to 7, M chain identifiers may be configured for any service node in the service network, where the M chain identifiers belong to the chain identifiers of the N service branches registered in the consensus network. Wherein M is a positive integer less than or equal to N. The number of the chain identifiers configured for each service node may be the same or different, and will not be limited herein.

For example, if the number of sub-links derived from the main chain in the consensus network is 3, and the link identifiers of the 3 sub-links are respectively a link identifier 1s corresponding to a service 1X (e.g., a ticket service), a link identifier 2s corresponding to a service 2X (e.g., a credit sign service), and a link identifier 3s corresponding to a service 3X (e.g., an import/export service), 2 link identifiers (e.g., a link identifier 1s and a link identifier 3 s) may be dynamically configured for one service node in the service network, and 3 link identifiers (e.g., a link identifier 1s, a link identifier 2s, and a link identifier 3 s) may be dynamically configured for another service node in the service network. It can be understood that if a service node is configured with multiple chain identifiers, the service node can participate in executing services corresponding to the sub-chains by the multiple chain identifiers, so that control over the service node can be effectively ensured.

Alternatively, although the backbone chain is derived from different sub-chains, the sub-chains and the backbone chain may still be subjected to a common-knowledge uplink process by the same common-knowledge node, the transaction information may be distinguished according to the chain identity, and the unused sub-chains may be respectively and concurrently common-knowledge.

Of course, some sub-chains may also be configured to be commonly recognized by independent commonly recognized nodes, but these independent commonly recognized nodes must synchronize the data of the backbone. Specifically, for example, the consensus nodes that independently consensus a sub-chain may form a sub-chain independent consensus network, and the consensus nodes that independently consensus a main chain may form a main chain independent consensus network.

Meanwhile, the agent node needs to record the information of the independent consensus network, and if a request for transmitting transaction information or synchronous data to the independent consensus network is met, the information is forwarded to the independent consensus network; otherwise, the request is checked according to the basic configuration and then forwarded to the consensus node of the core network, and the consensus node is independently processed according to the sub-chain ID of the request.

Alternatively, in order to reduce the waste of the storage space of the service node, the service node in the embodiment of the present application may take a lightweight node (Simplified Payment Verification, abbreviated as SPV) as an example, where the service node does not need to store complete transaction data, but obtains the block header data and the block data with visible partial authorization (such as the service transaction associated with the service node itself) from the consensus network through the proxy node. An SPV node may dynamically configure multiple sub-chain IDs to participate in the services of multiple sub-chains, and multiple sub-chains may participate with the same SPV node identifier and address, where the SPV node identifier and address must be registered on the main chain in advance, and block data of each sub-chain may be independently synchronized back to the SPV node and stored independently locally at the SPV node.

Aiming at the multi-link scene introduced in the foregoing embodiment, the embodiment of the present application also provides a technical solution for global unified configuration management, which is specifically introduced as follows:

FIG. 9 is a flow chart illustrating a method of data processing for a blockchain system including a main chain and at least one sub-chain, each sub-chain being derived from a block height in the main chain, each sub-chain having a main chain relay contract deployed therein, the main chain relay contract having a main chain block header stored therein and the main chain block header having configuration information, according to one embodiment of the present application, as specifically shown in FIG. 8. The data processing method of the blockchain system shown in fig. 9 may be performed by a consensus node, and specifically, referring to fig. 9, the data processing method of the blockchain system at least includes steps S910 to S930, which are described in detail as follows:

in step S910, when a new traffic segment needs to be generated for a given sub-chain, configuration information of the main chain is acquired from the main chain relay contract.

Alternatively, generating a new traffic chunk for a given sub-chain means that a chunk needs to be added in the given sub-chain, i.e. transaction information needs to be stored uplink in the given sub-chain. The designated sub-chain may be any one of the sub-chains in the blockchain system.

Alternatively, the backbone relay contract may be deployed in the first block derived on each sub-chain. For example, in the embodiment shown in FIG. 8, the backbone relay contract for sub-chain 802 may be deployed in block B2; the main chain relay contract of the sub-chain 803 may be deployed in the tile C2; the main chain relay contract of the sub-chain 804 may be deployed in block D4.

Alternatively, each sub-chain may run a backbone relay service at startup that is used to obtain the backbone block header and submit the backbone block header into a backbone relay contract.

In step S920, if the configuration information of the main chain is inconsistent with the configuration information of the designated sub-chain, the configuration information of the designated sub-chain is updated by the configuration information of the main chain.

Alternatively, whether the configuration information of the main chain is consistent with the configuration information of the designated sub-chain may be determined by comparing the configuration information of the main chain with the configuration information of the designated sub-chain. If the main chain block header further includes a configuration information version number, whether the configuration information of the main chain is consistent with the configuration information of the designated sub-chain can be determined directly by comparing the configuration information version number of the main chain with the configuration information version number of the designated sub-chain.

In one embodiment of the present application, the process of updating the configuration information of the designated sub-chain by the configuration information of the main chain may be to generate a configuration update block using the configuration information of the main chain as configuration transaction information, and then perform a consensus uplink processing on the configuration update block to add the configuration update block to the designated sub-chain.

Optionally, the configuration update block may further include: transaction information used for updating the configuration information version number of the designated sub-link in the main chain relay contract can further update the configuration information version number of the designated sub-link stored in the main chain relay contract.

In step S930, if the configuration information of the main chain is consistent with the configuration information of the designated sub-chain, a new service block is generated by packing and the consensus uplink processing is performed.

Alternatively, the configuration information of the main chain and the configuration information of the designated sub-chain may be the same after the configuration information of the designated sub-chain is updated by the configuration information of the main chain, or the configuration information of the main chain and the configuration information of the designated sub-chain may be the same when compared.

In one embodiment of the present application, the main link relay contract may further include a latest update time of the main link block header, so when a new service block needs to be generated for a specific sub-link, if a time difference between the local time and the latest update time exceeds a set threshold, the common identification processing on the new service block is suspended. The technical scheme of the embodiment can avoid the situation that the sub-chain cannot or deliberately does not track the main chain configuration information, and further can realize accurate and efficient control of the sub-chain.

Alternatively, suspending the consensus process for the new traffic block may be suspending the proposal process, or the consensus process, after the new traffic block has been generated. Suspending the consensus processing of the new traffic block may also be suspending the packing of the new traffic block if the new traffic block is still in the packing phase.

Optionally, after suspending the consensus processing for the new service block, if the time difference between the local time and the latest update time of the main chain block header is detected to be smaller than a set threshold value, and the configuration information of the main chain is consistent with the configuration information of the designated sub-chain, performing the consensus uplink processing for the service block generated by the packet. The technical scheme of the embodiment ensures that after the time difference between the local time and the latest updating time of the main chain block head is smaller than the set threshold value, the blocks which are paused can be continuously processed in time, and further the continuity of the block processing can be ensured.

In one embodiment of the present application, if the configuration information of the main chain needs to be updated, a global configuration block may be generated, and the configuration information version number in the block header of the global configuration block is updated, and then the global configuration block is subjected to a consensus uplink process to add the global configuration block to the main chain. The implementation of the technical scheme of the embodiment can update the configuration information of the main chain, and the following needs to be described: if the configuration information of the main chain is updated, each sub-chain needs to synchronize the global configuration block. As shown in fig. 8, assuming that the configuration information of the main chain has changed, a global configuration block A3 is generated in the main chain 801, and then synchronization is performed in the sub-chain, such as block B5 in the sub-chain 802, and block C4 in the sub-chain 803.

Alternatively, the solution of the embodiment shown in fig. 9 may be applied in a blockchain system with only a network of accounting nodes, which maintains a plurality of blockchains as shown in fig. 8. Of course, the technical solution of the embodiment shown in fig. 9 may also be applied to the blockchain system shown in fig. 4 to 7, that is, the blockchain system includes an accounting node network, a service node network, and a proxy node network connected between the accounting node network and the service node network, where the proxy node network is configured to receive the transaction information to be uplink from the service node network, and forward the transaction information to be uplink to the accounting node network for performing the packet-packing and uplink processing; the network of accounting nodes is used to maintain the aforementioned backbone and at least one sub-chain.

Alternatively, the backbone and at least one sub-chain in embodiments of the present application may be maintained by the same accounting node in the accounting node network; or the main chain and at least one sub-chain may be maintained separately by different clusters of accounting nodes in the network of accounting nodes.

Implementation details of the technical solution of the embodiment of the present application are described in detail below with reference to fig. 10, and as shown in fig. 10, the blockchain system includes a main chain 801 and a sub-chain 802. The "backbone relay contract" is automatically deployed in the first chunk of each sub-chain (e.g., in chunk B2 of sub-chain 802) and a backbone relay service is initiated at the same time as the sub-chain is started, which is used to track the chunk header height changes of the backbone, and is submitted to the backbone relay contract at regular time after new data (i.e., the backbone chunk header) is obtained.

The backbone relay contract is used to receive the backbone block header submitted by the backbone relay service and store and verify (e.g., verify the pre-block hash, the merck tree root, etc.) within the contract. The "Config Version" field (i.e., configuration Version) may be set in the main chain block header, and if the main chain has a global configuration block uplink, the "Config Version" field value is incremented by 1.

Before the block is identified in the sub-chain, the identified node needs to query the main chain relay contract, and whether the contract version is bad or not is determined according to the sub-chain contract and main chain block head data, so that whether the business transaction can be normally packaged or not is determined. If the current config version of the sub-chain is consistent with the config version data in the latest block header of the main chain, the consensus node can continue to package the sub-chain business transaction and perform consensus.

If the present config version of the sub-chain and the config version data in the latest block header of the main chain have a config version difference, the main chain is indicated to have a new global configuration, and at the moment, the consensus node can not package the business transaction, and the following steps are executed: and taking out the configuration transaction of the main chain block corresponding to the new Config Version from the main chain relay contract, packaging the configuration transaction into the new block, submitting a transaction for updating the local Config Version of the sub-chain to the main chain relay contract, and packaging the transaction into the new block. And after the new block is commonly known, continuing to inquire from the main chain relay contract, and judging whether the local config version is bad with the data in the main chain block head so as to determine whether the transaction information can be submitted.

To solve the problem that the sub-chain cannot or deliberately not track the configuration of the main chain, the main chain relay contract stores the latest update time of the main chain block head data. If the current consensus round is found to exceed the maximum delay switch (namely the maximum delay threshold value) between the local time and the latest updating time of the main chain block head data when the inquiry can execute the service consensus in the consensus round, the current consensus round is paused, and the main chain state is continuously tracked and submitted after waiting for the main chain relay service to resume service.

According to the technical scheme, under the scene that the main chain derives the sub-chain, the cross-chain synchronization scheme of the sub-chain and the main chain configuration is realized. The sub-link is safe, efficient, accurate and unavoidable to track and verify the main-link data through the main-link relay contract, and real-time correct synchronization of the sub-link to the main-link state is ensured. And the sub-link consensus depends on the judgment of the main link relay contract, so that the real-time issuing and service controllability of the main link on the configuration of each sub-link are ensured. Meanwhile, the main chain does not need to wait for the sub-chain to finish configuration synchronization, and the sub-chain executes strict configuration synchronization work by self through built-in contracts, so that the framework is simple, and the main chain operation and other sub-chain operation cannot be influenced if problems occur in the sub-chain.

The following describes an apparatus embodiment of the present application that may be used to perform the data processing method of the blockchain system in the above embodiments of the present application. For details not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the data processing method of the blockchain system described in the present application.

FIG. 11 illustrates a block diagram of a data processing apparatus of a blockchain system including a main chain and at least one sub-chain, each of the sub-chains being derived from a blockheight in the main chain, each of the sub-chains having a main chain relay contract disposed therein having a main chain block header stored therein, the main chain block header including configuration information, the data processing apparatus of the blockchain system illustrated in FIG. 11 being positionable within a common node, according to one embodiment of the present application.

Referring to fig. 11, a data processing apparatus 1100 of a blockchain system according to an embodiment of the present application includes: an acquisition unit 1102, a first processing unit 1104, and a second processing unit 1106.

Wherein the obtaining unit 1102 is configured to obtain configuration information of the main chain from the main chain relay contract when a new service block needs to be generated for a specific sub-chain; the first processing unit 1104 is configured to update the configuration information of the designated sub-chain by the configuration information of the main chain if the configuration information of the main chain is inconsistent with the configuration information of the designated sub-chain; the second processing unit 1106 is configured to, if the configuration information of the main chain is consistent with the configuration information of the designated sub-chain, package to generate a new service block and perform a consensus uplink process.

In some embodiments of the present application, based on the foregoing scheme, the first processing unit 1104 is configured to: taking the configuration information of the main chain as configuration transaction information to generate a configuration updating block; and performing consensus uplink processing on the configuration update block to add the configuration update block into the specified sub-chain.

In some embodiments of the present application, based on the foregoing solution, the main chain block header further includes a configuration information version number; the first processing unit 1104 is configured to: and if the configuration information version number of the main chain is inconsistent with the configuration information version number of the appointed sub-chain, determining that the configuration information of the main chain is inconsistent with the configuration information of the appointed sub-chain.

In some embodiments of the present application, based on the foregoing solution, the backbone relay contract further includes a latest update time of the backbone block header; the second processing unit 1106 is further configured to: and when a new service block needs to be generated for the appointed sub-chain, if the time difference between the local time and the latest updating time exceeds a set threshold value, suspending the common identification processing of the new service block.

In some embodiments of the present application, based on the foregoing scheme, the second processing unit 1106 is further configured to: after the common-knowledge processing is suspended on the new service block, if the time difference between the local time and the latest updating time is detected to be smaller than the set threshold value and the configuration information of the main chain is consistent with the configuration information of the appointed sub-chain, the common-knowledge uplink processing is carried out on the service block generated by packing.

In some embodiments of the present application, based on the foregoing solution, the main-chain block header further includes a configuration information version number, and the data processing apparatus 1100 further includes: the third processing unit is configured to generate a global configuration block and update a configuration information version number in a block header of the global configuration block if the configuration information of the main chain needs to be updated; the global configuration block is subjected to a consensus uplink process to add the global configuration block to the backbone.

It should be noted that, the computer system 1200 of the electronic device shown in fig. 12 is only an example, and should not impose any limitation on the functions and the application scope of the embodiments of the present application.

As shown in fig. 12, the computer system 1200 includes a central processing unit (Central Processing Unit, CPU) 1201 which can perform various appropriate actions and processes, such as performing the methods described in the above embodiments, according to a program stored in a Read-Only Memory (ROM) 1202 or a program loaded from a storage section 1208 into a random access Memory (Random Access Memory, RAM) 1203. In the RAM 1203, various programs and data required for the system operation are also stored. The CPU 1201, ROM 1202, and RAM 1203 are connected to each other through a bus 1204. An Input/Output (I/O) interface 1205 is also connected to bus 1204.

The following components are connected to the I/O interface 1205: an input section 1206 including a keyboard, a mouse, and the like; an output portion 1207 including a Cathode Ray Tube (CRT), a liquid crystal display (Liquid Crystal Display, LCD), and a speaker, etc.; a storage section 1208 including a hard disk or the like; and a communication section 1209 including a network interface card such as a LAN (Local Area Network ) card, a modem, or the like. The communication section 1209 performs communication processing via a network such as the internet. The drive 1210 is also connected to the I/O interface 1205 as needed. A removable medium 1211 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is installed as needed on the drive 1210 so that a computer program read out therefrom is installed into the storage section 1208 as needed.

In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion 1209, and/or installed from the removable media 1211. When executed by a Central Processing Unit (CPU) 1201, performs the various functions defined in the system of the present application.

It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory, EPROM), flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with a computer-readable computer program embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Where each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments of the present application may be implemented by means of software, or may be implemented by means of hardware, and the described units may also be provided in a processor. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.

As another aspect, the present application also provides a computer-readable medium that may be contained in the electronic device described in the above embodiment; or may exist alone without being incorporated into the electronic device. The computer-readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to implement the methods described in the above embodiments.

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functions of two or more modules or units described above may be embodied in one module or unit, in accordance with embodiments of the present application. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a usb disk, a mobile hard disk, etc.) or on a network, and includes several instructions to cause a computing device (may be a personal computer, a server, a touch terminal, or a network device, etc.) to perform the method according to the embodiments of the present application.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains.

It is to be understood that the present application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A data processing method of a blockchain system, wherein the blockchain system includes a main chain and at least one sub-chain, each sub-chain is derived from a block height in the main chain, each sub-chain is configured with a main chain relay contract, a main chain block header is stored in the main chain relay contract, and configuration information is included in the main chain block header, the data processing method comprising:

acquiring configuration information of the main chain from the main chain relay contract when a new service block is required to be generated for a specified sub-chain;

If the configuration information of the main chain is inconsistent with the configuration information of the appointed sub-chain, updating the configuration information of the appointed sub-chain through the configuration information of the main chain;

and if the configuration information of the main chain is consistent with the configuration information of the appointed sub-chain, packaging to generate a new service block and carrying out consensus uplink processing.

2. The data processing method of the blockchain system according to claim 1, wherein updating the configuration information of the designated sub-chain by the configuration information of the main chain includes:

taking the configuration information of the main chain as configuration transaction information to generate a configuration updating block;

and performing consensus uplink processing on the configuration update block to add the configuration update block into the specified sub-chain.

3. The method for processing data in a blockchain system of claim 2, wherein the configuration update block further comprises: transaction information for updating the configuration information version number of the designated sub-link in the main link relay contract.

4. The method for processing data of a blockchain system of claim 1, wherein the main chain block header further includes a configuration information version number;

The data processing method further comprises the following steps:

and if the configuration information version number of the main chain is inconsistent with the configuration information version number of the appointed sub-chain, determining that the configuration information of the main chain is inconsistent with the configuration information of the appointed sub-chain.

5. The data processing method of a blockchain system of claim 1, wherein the data processing method further comprises:

the designated sub-chain runs a main chain relay service when started, and the main chain relay service is used for acquiring the main chain block head and submitting the main chain block head to the main chain relay contract.

6. The method of claim 1, wherein the backbone relay contract further comprises a latest update time of a backbone block header;

the data processing method further comprises the following steps:

and when a new service block needs to be generated for the appointed sub-chain, if the time difference between the local time and the latest updating time exceeds a set threshold value, suspending the common identification processing of the new service block.

7. The data processing method of a blockchain system of claim 6, wherein after suspending the consensus processing for the new traffic block, the data processing method further comprises:

And if the time difference between the local time and the latest updating time is detected to be smaller than the set threshold value and the configuration information of the main chain is consistent with the configuration information of the appointed sub-chain, performing consensus uplink processing on the business block generated by packing.

8. The method of claim 1, wherein a backbone relay contract deployed in each of the sub-chains is deployed in a first block derived on each of the sub-chains.

9. The data processing method of a blockchain system of claim 1, wherein the blockchain system includes a billing node network, a service node network, and a proxy node network connected between the billing node network and the service node network;

the proxy node network is used for receiving the transaction information to be uplink from the service node network, and forwarding the transaction information to be uplink to the accounting node network for packing and uplink processing; the network of accounting nodes is configured to maintain the backbone and the at least one sub-chain.

10. The data processing method of a blockchain system of claim 9, wherein the main chain and the at least one sub-chain are maintained by a same accounting node in the accounting node network; or alternatively

The main chain and the at least one sub-chain are maintained by different clusters of accounting nodes in the network of accounting nodes, respectively.

11. The data processing method of a blockchain system according to any of claims 1 to 10, wherein the main block header further includes a configuration information version number, and the data processing method further includes:

if the configuration information of the main chain needs to be updated, generating a global configuration block, and updating the configuration information version number in the block head of the global configuration block;

the global configuration block is subjected to a consensus uplink process to add the global configuration block to the backbone.

12. A data processing apparatus for a blockchain system, the blockchain system including a main chain and at least one sub-chain, each of the sub-chains being derived from a blockheight in the main chain, each of the sub-chains having a main chain relay contract disposed therein, the main chain relay contract having a main chain block header stored therein, the main chain block header having configuration information contained therein, the data processing apparatus comprising:

an acquisition unit configured to acquire configuration information of the main chain from the main chain relay contract when a new traffic block needs to be generated for a specified sub-chain;

The first processing unit is configured to update the configuration information of the appointed sub-chain through the configuration information of the main chain if the configuration information of the main chain is inconsistent with the configuration information of the appointed sub-chain;

and the second processing unit is configured to pack and generate a new service block and perform consensus uplink processing if the configuration information of the main chain is consistent with the configuration information of the designated sub-chain.

13. A computer readable medium having stored thereon a computer program, which when executed by a processor implements a data processing method of a blockchain system as claimed in any of claims 1 to 11.

14. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs that, when executed by the one or more processors, cause the electronic device to implement the data processing method of the blockchain system of any of claims 1 to 11.

15. A computer program product, characterized in that the computer program product comprises computer instructions stored in a computer readable storage medium, from which computer instructions a processor of a computer device reads and executes, causing the computer device to perform the data processing method of the blockchain system according to any of claims 1 to 11.