Data processing method and device of blockchain system, medium and electronic equipment

Abstract

Embodiments of the present application provide a data processing method and device of a blockchain system, a medium and an electronic device. 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. A main chain relay contract is deployed in each sub-chain. A main chain block header is stored in the main chain relay contract. The main chain block header includes configuration information. The data processing method includes: when a new business block needs to be generated for a specified sub-chain, obtaining the configuration information of the main chain from the main chain relay contract; if the configuration information of the main chain is inconsistent with the configuration information of the specified sub-chain, updating the configuration information of the specified sub-chain by using the configuration information of the main chain; and if the configuration information of the main chain is consistent with the configuration information of the specified sub-chain, packing the new business block and performing consensus and chain processing. The technical solution of the embodiments of the present application can realize global unified configuration and management of multiple blockchains in the scene of multiple blockchains.

Description

Technical Field

[0001] This application relates to the fields of computer and communication technology, and more specifically, to a data processing method, apparatus, medium, and electronic device for a blockchain system. Background Technology

[0002] In related technologies, blockchain systems typically contain a single blockchain on which all transaction information submitted by business nodes within the system needs to be recorded. Because all transaction information must be written to the same blockchain, this blockchain stores transaction information corresponding to different businesses, making it impossible to effectively distinguish between different businesses on that blockchain. Based on this, related technologies have proposed technical solutions involving multiple blockchains. However, for scenarios with multiple blockchains, how to perform globally unified configuration of these blockchains remains a pressing technical problem to be solved. Summary of the Invention

[0003] The embodiments of this application provide a data processing method, apparatus, medium, and electronic device for a blockchain system, thereby enabling, at least to a certain extent, global unified configuration and management of multiple blockchains in a scenario involving multiple blockchains.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a data processing method for a blockchain system is provided. 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. A main chain relay contract is deployed in each sub-chain. The main chain relay contract stores a main chain block header, which contains configuration information. The data processing method includes: when a new business block needs to be generated for a specified sub-chain, obtaining the configuration information of the main chain from the main chain relay contract; if the configuration information of the main chain is inconsistent with the configuration information of the specified sub-chain, updating the configuration information of the specified sub-chain using the configuration information of the main chain; if the configuration information of the main chain is consistent with the configuration information of the specified sub-chain, packaging and generating a new business block and performing consensus on-chain processing.

[0006] According to one aspect of the embodiments of this application, a data processing apparatus for a blockchain system is provided. 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. A main chain relay contract is deployed in each sub-chain. The main chain relay contract stores a main chain block header, and the main chain block header contains configuration information. The data processing apparatus includes: an acquisition unit configured to acquire the configuration information of the main chain from the main chain relay contract when a new business block needs to be generated for a specified sub-chain; a first processing unit configured to update the configuration information of the specified sub-chain using the configuration information of the main chain if the configuration information of the main chain is inconsistent with the configuration information of the specified sub-chain; and a second processing unit configured to package and generate a new business block and perform consensus on-chain processing if the configuration information of the main chain is consistent with the configuration information of the specified sub-chain.

[0007] In some embodiments of this application, based on the foregoing scheme, the first processing unit is configured to: use the configuration information of the main chain as configuration transaction information to generate a configuration update block; and perform consensus on-chain processing on the configuration update block to add the configuration update block to the designated sub-chain.

[0008] In some embodiments of this application, based on the foregoing scheme, the configuration update block further includes: transaction information for updating the configuration information version number of a specified sub-chain in the main chain relay contract.

[0009] In some embodiments of this application, based on the aforementioned scheme, the main chain block header further includes a configuration information version number; the first processing unit is configured to: if the configuration information version number of the main chain is inconsistent with the configuration information version number of the specified sub-chain, then determine that the configuration information of the main chain is inconsistent with the configuration information of the specified sub-chain.

[0010] In some embodiments of this application, based on the aforementioned scheme, the designated subchain runs a main chain relay service upon startup. The main chain relay service is used to obtain the main chain block header and submit the main chain block header to the main chain relay contract.

[0011] In some embodiments of this application, based on the aforementioned scheme, the main chain relay contract also includes the latest update time of the main chain block header; the second processing unit is further configured to: when a new business block needs to be generated for the specified sub-chain, if the time difference between the local time and the latest update time exceeds a set threshold, then the consensus processing of the new business block is suspended.

[0012] In some embodiments of this application, based on the foregoing scheme, the second processing unit is further configured to: after pausing consensus processing for the new business block, if it is detected that the time difference between the local time and the latest update time is less than the set threshold, and the configuration information of the main chain is consistent with the configuration information of the designated sub-chain, then consensus on-chain processing is performed on the packaged business block.

[0013] In some embodiments of this application, based on the aforementioned scheme, the main chain relay contract deployed in each of the sub-chains is deployed in the first block derived from each of the sub-chains.

[0014] In some embodiments of this application, based on the foregoing scheme, the blockchain system includes an accounting node network, a business node network, and a proxy node network connected between the accounting node network and the business node network; wherein, the proxy node network is used to receive transaction information to be uploaded to the blockchain from the business node network, and forward the transaction information to be uploaded to the blockchain to the accounting node network for packaging and uploading; the accounting node network is used to maintain the main chain and the at least one sub-chain.

[0015] In some embodiments of this application, based on the foregoing scheme, the main chain 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 accounting node clusters in the accounting node network.

[0016] In some embodiments of this application, based on the aforementioned scheme, the main chain block header further includes a configuration information version number, and the data processing device further includes: a third processing unit configured to generate a global configuration block and update the configuration information version number in the block header of the global configuration block if the configuration information of the main chain needs to be updated; and to perform consensus on-chain processing on the global configuration block to add the global configuration block to the main chain.

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

[0018] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device enables the data processing method of the blockchain system as described in the above embodiments.

[0019] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the data processing method of the blockchain system provided in the various alternative embodiments described above.

[0020] In some embodiments of this application, the technical solutions provided include a blockchain system comprising a main chain and at least one sub-chain. Each sub-chain is derived from a block height in the main chain, which enables different businesses to be effectively distinguished through different blockchains, thereby ensuring the exclusivity of transaction information stored on each chain. Meanwhile, since each subchain deploys a mainchain relay contract, which stores the mainchain block header containing configuration information, when a new business block needs to be generated for a specific subchain, if the mainchain configuration information obtained from the mainchain relay contract is inconsistent with the configuration information of the specified subchain, the configuration information of the specified subchain is updated using the mainchain configuration information. When the mainchain configuration information and the specified subchain configuration information are consistent, a new business block is packaged and generated and processed for consensus on-chain. This allows the mainchain block header to be stored through the mainchain relay contract, enabling the tracking of mainchain data and ensuring the synchronization of subchain configuration information with the mainchain. Furthermore, since subchains need to perform dependency verification on the mainchain configuration information when on-chaining consensus, it ensures that the mainchain has controllable business configuration for each subchain, achieving globally unified configuration and management of multiple blockchains in a multi-blockchain scenario.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0023] Figure 1 A schematic diagram of the blockchain network structure is shown.

[0024] Figure 2 This diagram illustrates the connection relationships between blocks in a blockchain.

[0025] Figure 3 The diagram illustrates the process of generating a block.

[0026] Figures 4 to 6 The diagram shows the architecture of the blockchain system used in the embodiments of this application.

[0027] Figure 7 A schematic diagram of an electronic invoice system according to an embodiment of this application is shown.

[0028] Figure 8 A schematic diagram of a multi-chain scenario according to an embodiment of this application is shown.

[0029] Figure 9 A flowchart illustrating a data processing method for a blockchain system according to an embodiment of this application is shown;

[0030] Figure 10 A schematic diagram illustrating information synchronization between the main chain and the sub-chain according to an embodiment of this application is shown;

[0031] Figure 11 A block diagram of a data processing apparatus for a blockchain system according to an embodiment of this application is shown;

[0032] Figure 12 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0033] Exemplary embodiments will now be described in a more comprehensive manner with reference to the accompanying drawings. However, the exemplary embodiments can be implemented in various forms and should not be construed as limited to these examples; rather, these embodiments are provided so that this application will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art.

[0034] Furthermore, the features, structures, or characteristics described in this application can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to provide a full understanding of the embodiments of this application. However, those skilled in the art will recognize that when implementing the technical solutions of this application, not all the detailed features in the embodiments may be used, one or more specific details may be omitted, or other methods, elements, devices, steps, etc., may be employed.

[0035] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0036] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0037] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0038] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks (i.e., blocks) linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

[0039] The underlying blockchain platform can include modules for user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user identities and blockchain addresses (access management). Under authorization, it also monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information using a consensus algorithm (consensus management). The encryption process involves transmitting the encrypted data to the shared ledger (network communication) and storing it in a consistent manner. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). Based on the contract terms, the module calls keys or other events to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation and monitoring module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization during product launch, such as alarms, network status monitoring, and node device health status monitoring.

[0040] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0041] See Figure 1 The illustrated blockchain network may include multiple nodes 101, which can be various clients forming the blockchain network. Each node 101, in its normal operation, receives input information and maintains shared data within the blockchain network based on this information. To ensure information exchange within the blockchain network, information connections can exist between each node, allowing for information transmission. For example, when any node in the blockchain network receives input information, other nodes in the network retrieve this input information according to a consensus algorithm and store it as shared data, ensuring data consistency across all nodes in the blockchain network.

[0042] Each node in a blockchain network has a corresponding node identifier, and each node can store the node identifiers of other nodes. This allows for the broadcast of generated blocks to other nodes in the blockchain network based on their node identifiers. Each node can maintain a list of node identifiers, storing the node name and its corresponding node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node.

[0043] Each node in a blockchain network stores the same blockchain. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 2 As shown, a blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information features, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information features of the current block, the block header features of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0044] When generating the individual blocks in the blockchain, see Figure 3As shown, when a node in the blockchain receives input information, it verifies the input information. After verification, it stores the input information in a memory pool and updates its hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers, performing feature value calculations multiple times. When a random number that meets the conditions is obtained, the information is stored accordingly, generating a block header and block body, thus obtaining the current block. Subsequently, the node in the blockchain sends the newly generated block to other nodes in its data sharing system based on the node identifiers of other nodes in the data sharing system. These other nodes verify the newly generated block and, after verification, add it to their stored blockchain. Nodes can use consensus algorithms to verify the newly generated block, and these consensus algorithms may include, but are not limited to:

[0045] Proof-of-Work (PoW): Proof-of-Work refers to a measurement method set up by a system (such as the aforementioned blockchain network system) to achieve a certain goal. Simply put, it's a proof used to confirm the amount of work done. Essentially, whoever does more work has a greater chance of receiving additional rewards. In the PoW algorithm, each node provides computing power (or simply computing power) to the entire system. Through a competitive mechanism, the node that completes the most computational work receives the system's reward, that is, the right to record transactions.

[0046] PoS (Proof-of-Stake): Proof-of-Stake is an upgraded consensus mechanism of Proof-of-Work (PoW); specifically, the longer someone holds electronic resources (the length of time they hold electronic resources = the number of electronic resources they hold), the higher their consensus rate. (The duration of holding electronic resources) Who has a greater chance of obtaining the right to record transactions in the block? Here, electronic resources can refer to resources stored in electronic accounts in electronic form and that can be circulated via the Internet.

[0047] Delegated Proof of Stake (DPoS) is similar to a board of directors vote. Holders of electronic resources vote to elect a certain number of nodes to act as their proxies for verification and record-keeping. To incentivize more nodes to participate, the system generates a small amount of electronic resources as a reward. The elected nodes have equal rights. If elected representatives fail to fulfill their duties (e.g., failing to generate a block when it's their turn), they are removed, and the network elects new nodes to replace them. This allows DPoS to significantly reduce the number of nodes involved in verification and record-keeping, achieving consensus verification in seconds. However, the entire consensus mechanism still relies on electronic resources.

[0048] PBFT (Practical Byzantine Fault Tolerance): The PBFT Byzantine Fault Tolerance algorithm is a message-passing-based consensus algorithm that achieves consensus through three phases, which may be repeated due to failures. Specifically, assuming a total of 3f+1 nodes, where f represents Byzantine faulty nodes, first, when a node discovers that the leader (such as a representative node, ledger node, or supernode) is malicious, it elects another replica node as the new leader. Second, the leader broadcasts its chosen value to other replica nodes via a pre-prepare message. Other replica nodes send a prepare message if they accept it, otherwise they do not. Third, once 2f nodes accept the prepare message, the node sends a commit message. Finally, when 2f+1 nodes accept the commit message, the value is considered finalized. The above process enables the PBFT Byzantine Fault Tolerance algorithm to reach a consensus that each node is composed of business stakeholders or regulators, and that security and stability are guaranteed by the relevant business stakeholders. Furthermore, the consensus latency is approximately 2 to 5 seconds, which basically meets the requirements of commercial real-time processing, improves consensus efficiency, and can meet the needs of high-frequency trading.

[0049] Paxos (a distributed algorithm): The Paxos algorithm is a two-phase algorithm with three main roles: proposer, acceptor, and learner. The proposer proposes a proposal, the acceptor agrees or rejects, and the learner obtains the final value after consensus is reached. The Paxos algorithm consists of two phases: ① Preparation phase: The proposer selects a proposal number n and sends a prepare request to a majority of the acceptors; after receiving the prepare request, if the acceptor's proposal number is greater than all prepare requests it has already responded to, the acceptor replies to the proposer with the proposal it previously accepted and promises not to respond to proposals less than n. ② Approval Phase: Once a proposer receives responses to the prepare request from a majority of acceptors, it enters the approval phase. It sends an accept request, including a number n and a value (if no value has already been accepted, it can freely choose the value). Without violating its commitments to other proposers, an acceptor accepts the request upon receiving it. The Paxos algorithm is suitable for simple fault-tolerant models, where only failed or faulty nodes exist in the system, and malicious nodes are not allowed. If the number of failed nodes is x (where x is a positive integer), then only x+1 non-failed nodes are needed to maintain the normal operation of the system.

[0050] Raft (a distributed consensus algorithm): The Raft algorithm includes three roles: follower, candidate, and leader. A node can only be in one of these three states at any given time, and these roles can transform into each other over time and under changing conditions. All nodes initially start as followers. Followers that do not receive a heartbeat within a timeout period become candidates and broadcast a vote request. The node that receives a majority of votes becomes the leader. In this round of voting, whoever sends the request first has the advantage, and each node only gives one vote. The leader node periodically sends heartbeats to other nodes. Leader node failure triggers a new round of voting.

[0051] Optionally, each node in the blockchain network can be a server or a terminal device. A server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Terminal devices can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart home devices, in-vehicle terminals, etc., but are not limited to these. Nodes can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0052] The aforementioned cloud computing refers to the delivery and usage model of IT infrastructure, specifically the acquisition of required resources through the network in an on-demand and easily scalable manner. In a broader sense, cloud computing refers to the delivery and usage model of services, namely, the acquisition of required services through the network in an on-demand and easily scalable manner. These services can be IT and software-related, internet-related, or other services. Cloud computing is a product of the convergence and development of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing. Driven by the development of the internet, real-time data streams, the diversification of connected devices, and the demands of search services, social networks, mobile commerce, and open collaboration, cloud computing has developed rapidly. Unlike previous parallel and distributed computing, the emergence of cloud computing will, conceptually, drive a revolutionary change in the entire internet model and enterprise management model.

[0053] Based on blockchain technology, embodiments of this application propose an architecture for a blockchain system. For example... Figure 4 As shown, the blockchain system includes a ledger node network 2 and a business node network 1. The ledger node network 2 includes ledger nodes 21 that reach consensus on data blocks and record them on the blockchain. The business node network 1 includes business nodes 11, which can verify the data blocks recorded on the blockchain by the ledger nodes or request corresponding transaction data from the ledger nodes.

[0054] Specifically, the verification of data blocks recorded on the blockchain by the accounting nodes by business node 11 may include the following steps: An accounting node 21 in the accounting node network uses a key specific to that accounting node to generate a signature based on the transaction information to be included in a data block to be added to the blockchain; accounting node 21 adds the transaction information and the generated signature to the data block and adds it to the blockchain; accounting node 21 sends the signature to a business node in the business node network, and the business node verifies the signature using its key specific to that accounting node, thereby enabling business node 11 to verify the data blocks recorded on the blockchain by the accounting nodes. The accounting nodes in the accounting node network are responsible for recording data blocks to the blockchain, and the business nodes in the business node network are responsible for witnessing the results of the accounting node recording. Specifically, the accounting node generates a signature based on the transaction information to be included in a data block to be added to the blockchain, then adds the transaction information and the generated signature to the data block and uploads it to the blockchain. The signature is then sent to a business node in the business node network, allowing the business node to verify the signature using its key specific to that accounting node. In the business node network, business nodes can witness the transaction data of the entire network by verifying the signatures of the ledger nodes on the blocks. Although the ledger node network has a monopoly on the right to record transactions, all actions are publicly traceable because the data blocks have digital signatures representing the identities of the ledger recorders. If the ledger nodes collectively commit malicious acts, then all nodes in the business node network will retain evidence of the specific ledger nodes' malicious actions. Compared to traditional centralized systems and private blockchains, the system in this embodiment operates more transparently; and compared to traditional decentralized solutions, this solution is more controllable and easier to supervise.

[0055] In one embodiment of this application, the ledger node network 2 and the business node network 1 can be connected via a proxy node 12. The proxy node 12 can be a business node in the business node network 1, responsible for transmitting information from the ledger node 21 to the business node 11. The business node 11 is the terminal of the transaction party that generates various transaction data that needs to be uploaded to the blockchain, and can also be a terminal that queries transaction data from the ledger node network 2. The transaction data generated by the business node 11 is transmitted to the ledger node 21 through the proxy node 12, and then recorded on the blockchain after consensus. This facilitates the unified processing and supervision of transaction data. The business node 11 can also supervise and witness the on-chain uploading of transaction data through the information sent by the ledger node 21 via the proxy node 12. This is of great significance in scenarios where unified supervision is needed, but there is also a fear of collective cheating by the monitored nodes.

[0056] exist Figure 1In the structure shown, business node network 1 adopts a P2P (Peer-to-Peer) network model. A P2P network is a distributed application architecture that distributes tasks and workloads among peers. It is a network form or topology of the peer-to-peer computing model at the application layer, i.e., a "point-to-point" or "end-to-end" network. It can be defined as follows: network participants share a portion of their hardware resources (processing power, storage capacity, network connectivity, printers, etc.). These shared resources provide services and content through the network and can be directly accessed by other peer nodes without going through an intermediary entity. Participants in this network are both providers and recipients of resources, services, and content. Therefore, in business node network 1, when agent node 12 receives a message from accounting node 21, it propagates it to surrounding business nodes 11. The surrounding business nodes 11 receive the message and then propagate it to their neighboring business nodes 11, achieving the propagation of the message among all business nodes 11 in business node network 1.

[0057] Figure 5 This illustrates the architecture of another blockchain system used in the embodiments of this application. This architecture is similar to... Figure 4 The difference in the architecture shown is that a P2P network mode is not adopted in business node network 1; instead, a broadcast network mode is used. Specifically, after receiving a message from accounting node 21, agent node 12 broadcasts the message to other business nodes 11 in business node network 1. In this way, the message is also propagated among each business node 11 in business node network 1.

[0058] Figure 6 This illustrates another blockchain system architecture used in embodiments of the present invention. This architecture is similar to... Figure 4The difference in the illustrated architecture lies in that its ledger node network 2 is divided into multiple branch ledger node networks. Each branch ledger node network is responsible for recording a specific type of transaction information. For example, a company may have supply chain finance business and may need to record contract information, outstanding payments, and other information generated during the supply and sales process on the blockchain. Simultaneously, the company also needs to issue invoices and record invoice information and invoice reimbursement information on the blockchain. In this case, to facilitate the supervision of ledger nodes by the same department, the ledger nodes recording supply chain finance transactions and those recording transactions during the invoice circulation process may belong to different departments. For example, the ledger node recording supply chain finance transactions might be a bank-set ledger terminal, while the ledger node recording transactions during the invoice circulation process might be a tax authority-set ledger terminal. Furthermore, supply chain finance transactions and invoice circulation transactions may ultimately be recorded on different branch ledger node networks. In this case, the agent node 12, based on the transaction type carried in the transaction information sent from the business node 11, sends the transaction information to the branch ledger node network corresponding to that transaction type.

[0059] It should be noted that, in Figures 4 to 6 In the architecture of the blockchain system shown, the proxy node 12 is located in the business node network 1. In other embodiments of this application, the proxy node 12 may also be located in the consensus node network 2, or be independent of the business node network 1 and the consensus node network 2.

[0060] Figures 4 to 6 The architecture of the blockchain system shown can be applied to electronic invoice scenarios, which will be elaborated in detail below:

[0061] In one embodiment of this application, the accounting nodes in the accounting node network can be various State Taxation Administration terminals, for example, the accounting node network can be composed of State Taxation Administration terminals deployed in multiple regions, each serving as an accounting node. The business nodes in the business node network can be local tax bureau terminals, invoicing agent service provider terminals, invoicing enterprise terminals, individual user terminals, etc.

[0062] Specifically, in Figure 7 The electronic invoice system shown can include a business layer, a routing proxy layer, and a consensus network (i.e., an accounting node network, hereinafter referred to as the accounting network) layer. The business layer is the business node network, which contains various business nodes, such as local tax bureaus located in a dedicated tax network; invoicing service providers, reimbursement service providers, and enterprises located in a public cloud; and payment service providers, circulation service providers, and enterprises located in a private cloud.

[0063] The routing proxy layer includes proxy nodes that provide routing services, certificate caching and authentication services, P2P services, and other functions. The routing proxy layer isolates the business layer and the consensus network layer, as described in the technical solution of the aforementioned embodiments. Optionally, the proxy nodes in the routing proxy layer can be located within a tax-related private network. The consensus network (ledger network) layer is the ledger node network, which includes multiple blockchains. Of course, in other embodiments of this application, the consensus network (ledger network) layer may also include only one blockchain.

[0064] In one embodiment of this application, the consensus network (ledger network) of the electronic invoice system can include multiple blockchains. These blockchains can be divided into chains according to time sequence, such as chains for the same business transaction based on time, where the business participants are consistent, and both blockchains use the same CA (Certificate Authority) center as the authentication and authorization party for the invoice business system. Of course, in one embodiment of this application, chains can be divided according to different business transactions, such as one blockchain for business A and another for business B, and cross-chain interaction between businesses is also possible.

[0065] Optionally, such as Figure 8 As shown, in one exemplary embodiment, the consensus network (which may be the aforementioned) Figures 4 to 7 The consensus network shown can also be a standalone consensus network (i.e., a consensus network without separating business networks and consensus networks). It can contain multiple blockchains, specifically a main chain 801, and N sub-chains derived from the main chain 801 at a certain block height, where N is a positive integer. Each time a new sub-chain is derived, a new chain identifier needs to be generated for that new sub-chain. For example, in... Figure 8 In this model, main chain 801 can derive sub-chains 802, 803, and 804. Each sub-chain can correspond to a specific business function, such as in the tax business field. This effectively distinguishes different transaction businesses and maintains the exclusivity of the data stored in each business branch chain. Specific businesses could include invoice processing, credit reporting, import and export, enterprise qualification processing, and tax refund processing.

[0066] In one embodiment of this application, the main chain 801 in the consensus network may include registration information for sub-chains corresponding to various services. This registration information may include the sub-chain's chain identifier, service configuration information corresponding to the service, and derivation conditions corresponding to the chain identifier. Optionally, after each sub-chain is generated, it needs to be registered in the main chain. The main chain has a smart contract for managing sub-chain registration. During registration, the main chain can assign a chain identifier to the sub-chain and record its registration information.

[0067] Optionally, the business configuration information corresponding to a business (e.g., a bill transaction) may include basic business information (i.e., a description of the bill transaction) and node configuration information (including business node configuration information and consensus node configuration information). The business node configuration information may include a node identifier configured by a consensus node with regulatory authority (e.g., node 120a with regulatory authority) for the corresponding business branch chain (e.g., the business branch chain corresponding to the bill transaction). The business node corresponding to this node identifier can be used to execute the bill transaction. The consensus node configuration information may include consensus nodes configured by a consensus node with regulatory authority for this sub-chain to participate in the consensus process of that sub-chain.

[0068] Optionally, the genesis block of each subchain can be the block corresponding to the one derived from the main chain, for example... Figure 8 As shown, subchain 802 is derived from block A1 in mainchain 801, and its genesis block is A1; subchain 803 is derived from block A2 in mainchain 801, and its genesis block is A2; subchain 804 is derived from block A3 in mainchain 801, and its genesis block is A3. The mainchain and each subchain can operate independently, and each subchain can process its own transactions. When verifying a subchain block, in addition to verifying the subchain block itself, the genesis block of the subchain can be used to find chain A and then verify the genesis block of chain A (e.g., verifying a Merkle tree) to improve the reliability of the verification. Of course, if the consensus node has already synchronized chain A locally, then the verification of a subchain block can simply be done up to its genesis block on chain A.

[0069] Optionally, if the configuration information of the blockchain node system corresponding to the entire blockchain network (e.g., a tax blockchain system) changes, the consensus nodes in the consensus network need to be suspended. If the configuration information that has changed is referred to as configuration change information, then this configuration change information could refer to changes in regulatory rules within the tax field, changes in computing regulations, changes in important blockchain nodes, rotation of certificate issuing nodes, etc. Consensus nodes with regulatory authority in the consensus network can generate configuration change blocks based on this configuration change information, and then upload these configuration change blocks to the main chain 801 of the consensus network, synchronizing them to all sub-chains. At this time, other consensus nodes in the consensus network can resume operation. Figure 8 As shown, assuming the configuration information changes, a configuration change block A3 is generated in the main chain 801, and then it will be synchronized in the sub-chains, such as block B5 in sub-chain 802 and block C4 in sub-chain 803.

[0070] Optionally, for Figures 4 to 7In the system architecture shown, any business node in the business network can be configured with M chain identifiers. These M chain identifiers belong to the chain identifiers of the N business branch chains registered in the consensus network. Here, M is a positive integer less than or equal to N. The number of chain identifiers configured for each business node can be the same or different; this is not limited here.

[0071] For example, if the main chain in the consensus network derives from three sub-chains, and the chain identifiers of these three sub-chains are chain identifier 1s for business 1X (e.g., bill payment business), chain identifier 2s for business 2X (e.g., credit reporting business), and chain identifier 3s for business 3X (e.g., import / export business), then two chain identifiers (e.g., chain identifier 1s and chain identifier 3s) can be dynamically configured for one business node in the business network, and three chain identifiers (e.g., chain identifier 1s, chain identifier 2s, and chain identifier 3s) can be dynamically configured for another business node in the business network. It can be understood that if a business node is configured with multiple chain identifiers, then that business node can participate in executing the business of the sub-chains corresponding to these multiple chain identifiers, thereby effectively ensuring control over the business nodes.

[0072] Alternatively, although different subchains are derived from the main chain, these subchains and the main chain can still be processed by the same consensus nodes to complete the consensus on-chain processing. Transaction information can be distinguished according to the chain identifier, and different subchains can conduct consensus in parallel.

[0073] Of course, some subchains can also be configured to have independent consensus nodes, but these independent consensus nodes must synchronize with the main chain's data. Specifically, for example, consensus nodes that independently reach consensus on a subchain can form a subchain independent consensus network, and consensus nodes that independently reach consensus on the main chain can form a main chain independent consensus network.

[0074] Meanwhile, the proxy node needs to record information about the independent consensus network. If it encounters a request to send transaction information or synchronize data to the independent consensus network, it forwards it to the independent consensus network; otherwise, it checks the request according to the basic configuration and forwards it to the consensus node of the core network. The consensus node then processes the request independently based on the subchain ID.

[0075] Optionally, to reduce the waste of storage space for business nodes, the business nodes in this embodiment can take a lightweight node (Simplified Payment Verification, or SPV) as an example. This business node does not need to store complete transaction data, but obtains block header data and partially authorized visible block data (such as business transactions associated with the business node itself) from the consensus network through a proxy node. An SPV node can dynamically configure multiple subchain IDs to participate in the business of multiple subchains. Multiple subchains can participate using the same SPV node identifier and address. At the same time, the SPV node identifier and address must be registered on the main chain in advance. The block data of each subchain will be independently synchronized back to the SPV node and stored independently on the SPV node.

[0076] For the multi-chain scenarios described in the foregoing embodiments, this application also proposes a technical solution for globally unified configuration management, which is described in detail below:

[0077] Figure 9 A flowchart illustrating a data processing method for a blockchain system according to an embodiment of this application is shown. The blockchain system includes a main chain and at least one sub-chain, specifically as follows: Figure 8 As shown, each subchain is derived from a block height in the main chain. Each subchain deploys a main chain relay contract, which stores the main chain block header, which contains configuration information. Figure 9 The data processing method of the blockchain system shown can be executed by consensus nodes. Specifically, refer to... Figure 9 As shown, the data processing method of this blockchain system includes at least steps S910 to S930, which are described in detail below:

[0078] In step S910, when it is necessary to generate a new business block for a specified subchain, the configuration information of the main chain is obtained from the main chain relay contract.

[0079] Optionally, generating a new business block for a specified subchain means adding a block to the specified subchain, i.e., storing the transaction information on the specified subchain. The specified subchain can be any subchain in the blockchain system.

[0080] Optionally, the main chain relay contract can be deployed in the first block derived from each sub-chain. For example, in... Figure 8 In the illustrated embodiment, the main chain relay contract of sub-chain 802 can be deployed in block B2; the main chain relay contract of sub-chain 803 can be deployed in block C2; and the main chain relay contract of sub-chain 804 can be deployed in block D4.

[0081] Optionally, each subchain can run a mainchain relay service upon startup, which is used to obtain the mainchain block header and submit the mainchain block header to the mainchain relay contract.

[0082] In step S920, if the configuration information of the main chain is inconsistent with the configuration information of the specified sub-chain, the configuration information of the specified sub-chain is updated using the configuration information of the main chain.

[0083] Optionally, the consistency between the configuration information of the main chain and the specified sub-chain can be determined by comparing their configuration information. If the main chain block header also contains a configuration information version number, then the consistency between the main chain configuration information version number and the specified sub-chain configuration information version number can be determined directly. Specifically, if the main chain configuration information version number and the specified sub-chain configuration information version number are inconsistent, then it can be determined that the main chain configuration information and the specified sub-chain configuration information are inconsistent.

[0084] In one embodiment of this application, the process of updating the configuration information of a specified subchain through the configuration information of the main chain may involve using the configuration information of the main chain as configuration transaction information to generate a configuration update block, and then performing consensus on-chain processing on the configuration update block to add the configuration update block to the specified subchain.

[0085] Optionally, the configuration update block may also include transaction information for updating the configuration information version number of a specified subchain in the main chain relay contract, thereby updating the configuration information version number of the specified subchain stored in the main chain relay contract.

[0086] In step S930, if the configuration information of the main chain is consistent with the configuration information of the specified sub-chain, a new business block is generated and consensus on-chain processing is performed.

[0087] Optionally, the consistency between the configuration information of the main chain and the configuration information of the specified sub-chain can be achieved after updating the configuration information of the specified sub-chain using the configuration information of the main chain, or it can be achieved during the comparison of the configuration information of the main chain and the configuration information of the specified sub-chain.

[0088] In one embodiment of this application, the main chain relay contract may also include the latest update time of the main chain block header. Therefore, when a new business block needs to be generated for a specified sub-chain, if the time difference between the local time and the latest update time exceeds a set threshold, consensus processing for the new business block is suspended. This embodiment's technical solution can prevent sub-chains from failing to follow the main chain configuration information or intentionally not following it, thereby enabling accurate and efficient control over the sub-chain.

[0089] Optionally, pausing consensus processing for a new business block can be done after the new business block has been generated, by pausing proposal processing or consensus processing. If the new business block is still in the packaging stage, pausing consensus processing for the new business block can also mean pausing the packaging process for the new business block.

[0090] Optionally, after pausing consensus processing for new business blocks, if the time difference between the local time and the latest update time of the main chain block header is less than a set threshold, and the configuration information of the main chain is consistent with the configuration information of the specified sub-chain, then the business block generated in the package is subjected to consensus on-chain processing. This embodiment's technical solution allows for the timely resumption of processing of paused blocks after the time difference between the local time and the latest update time of the main chain block header falls below the set threshold, thereby ensuring the continuity of block processing.

[0091] In one embodiment of this application, if the main chain's configuration information needs to be updated, a global configuration block can be generated, and the version number of the configuration information in the block header of the global configuration block can be updated. Then, consensus on-chain processing is performed on the global configuration block to add it to the main chain. This embodiment's technical solution can update the main chain's configuration information. It should be noted that if the main chain's configuration information is updated, then each sub-chain needs to synchronize the global configuration block. Figure 8 As shown, assuming the configuration information of the main chain changes, a global configuration block A3 is generated in the main chain 801, and then it will be synchronized in the sub-chains, such as block B5 in sub-chain 802 and block C4 in sub-chain 803.

[0092] Optionally, Figure 9 The technical solution of the illustrated embodiment can be applied to a blockchain system that only has a network of ledger nodes, which maintains multiple such... Figure 8 The blockchain shown. Of course. Figure 9 The technical solutions of the illustrated embodiments can also be applied to, for example... Figures 4 to 7 The blockchain system shown includes an accounting node network, a business node network, and a proxy node network connecting the accounting node network and the business node network. The proxy node network is used to receive transaction information to be uploaded to the blockchain from the business node network and forward the transaction information to the accounting node network for packaging and uploading. The accounting node network is used to maintain the aforementioned main chain and at least one sub-chain.

[0093] Optionally, in the embodiments of this application, the main chain and at least one sub-chain can be maintained by the same accounting node in the accounting node network; or the main chain and at least one sub-chain can be maintained by different accounting node clusters in the accounting node network.

[0094] The following combination Figure 10 The implementation details of the technical solutions in the embodiments of this application are described in detail, such as... Figure 10 As shown, the blockchain system includes a main chain 801 and a sub-chain 802 for illustration. The first block of each sub-chain (such as block B2 of sub-chain 802) will automatically deploy a "main chain relay contract". At the same time as starting the sub-chain, a main chain relay service will be started. This main chain relay service is used to follow the block header height changes of the main chain and submit new data (i.e., the main chain block header) to the main chain relay contract at regular intervals after obtaining it.

[0095] The main chain relay contract receives main chain block headers submitted by the main chain relay service and stores and verifies them internally (e.g., verifying preceding block hashes, Merkle root, etc.). A "ConfigVersion" field (configuration version) can be set in the main chain block header. If a global configuration block is uploaded to the main chain, the "Config Version" field value is incremented by 1.

[0096] Before consensus is reached and a block is produced in the subchain, the consensus node needs to query the main chain relay contract. Based on the subchain contract and the main chain block header data, it determines whether there is a config version difference, and thus determines whether business transactions can be packaged normally. If the current config version of the subchain is consistent with the config version data in the latest block header of the main chain, the consensus node can continue to package subchain business transactions and proceed with consensus.

[0097] If there is a difference between the current config version of the subchain and the config version data in the latest block header of the main chain, it indicates that there is a new global configuration on the main chain. In this case, the consensus node cannot package business transactions and instead performs the following steps: retrieves the configuration transaction corresponding to the new config version of the main chain block from the main chain relay contract, packages it into the new block, submits a transaction to the main chain relay contract to update the local config version of the subchain, and packages it into the new block. Consensus is reached on the new block, and after consensus is achieved, the node continues to query the main chain relay contract to determine if there is a difference between the local config version and the data in the main chain block header, in order to determine whether the transaction information can be submitted.

[0098] To address the issue of subchains failing to or intentionally not following the main chain's configuration, the main chain relay contract stores the latest update time of the main chain's block header data. If, during a consensus round, a query to see if business consensus can be executed reveals that the local time exceeds the maximum delay threshold (i.e., the maximum delay time), the current consensus round is paused, and the main chain relay service resumes operation before the subchain continues to follow and submit its state to the main chain.

[0099] The technical solution of this application implements a cross-chain synchronization scheme for sub-chain and main chain configurations in the scenario of main chain-derived sub-chains. Through the main chain relay contract, the sub-chain securely, efficiently, accurately, and unavoidably follows and verifies main chain data, ensuring real-time and correct synchronization of the sub-chain's state with the main chain. The sub-chain consensus's reliance on the main chain relay contract ensures real-time distribution of configurations to each sub-chain and controllable business operations. Simultaneously, the main chain does not need to wait for the sub-chain to complete configuration synchronization; the sub-chain itself performs strict configuration synchronization through built-in contracts, ensuring a simple architecture. If a sub-chain encounters a problem, it will not affect the operation of the main chain or other sub-chains.

[0100] The following describes an apparatus embodiment of this application, which can be used to execute the data processing method of the blockchain system in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the data processing method of the blockchain system described above.

[0101] Figure 11 A block diagram of a data processing apparatus for a blockchain system according to an embodiment of this application is shown. The blockchain system includes 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 deploys a main chain relay contract, which stores a main chain block header containing configuration information. Figure 11 The data processing device of the blockchain system shown can be set up within the consensus node.

[0102] Reference Figure 11 As shown, a data processing apparatus 1100 for a blockchain system according to an embodiment of this application includes: an acquisition unit 1102, a first processing unit 1104, and a second processing unit 1106.

[0103] Specifically, the acquisition unit 1102 is configured to acquire the configuration information of the main chain from the main chain relay contract when a new business block needs to be generated for a specified sub-chain; the first processing unit 1104 is configured to update the configuration information of the specified sub-chain using the configuration information of the main chain if the configuration information of the main chain is inconsistent with the configuration information of the specified sub-chain; and the second processing unit 1106 is configured to package and generate a new business block and perform consensus on-chain processing if the configuration information of the main chain is consistent with the configuration information of the specified sub-chain.

[0104] In some embodiments of this application, based on the foregoing scheme, the first processing unit 1104 is configured to: use the configuration information of the main chain as configuration transaction information to generate a configuration update block; and perform consensus on-chain processing on the configuration update block to add the configuration update block to the designated sub-chain.

[0105] In some embodiments of this application, based on the foregoing scheme, the configuration update block further includes: transaction information for updating the configuration information version number of a specified sub-chain in the main chain relay contract.

[0106] In some embodiments of this application, based on the aforementioned scheme, the main chain block header further includes a configuration information version number; the first processing unit 1104 is configured to: if the configuration information version number of the main chain is inconsistent with the configuration information version number of the specified sub-chain, then determine that the configuration information of the main chain is inconsistent with the configuration information of the specified sub-chain.

[0107] In some embodiments of this application, based on the aforementioned scheme, the designated subchain runs a main chain relay service upon startup. The main chain relay service is used to obtain the main chain block header and submit the main chain block header to the main chain relay contract.

[0108] In some embodiments of this application, based on the aforementioned scheme, the main chain relay contract also includes the latest update time of the main chain block header; the second processing unit 1106 is further configured to: when a new business block needs to be generated for the specified sub-chain, if the time difference between the local time and the latest update time exceeds a set threshold, then the consensus processing of the new business block is suspended.

[0109] In some embodiments of this application, based on the foregoing scheme, the second processing unit 1106 is further configured to: after pausing consensus processing for the new business block, if it is detected that the time difference between the local time and the latest update time is less than the set threshold, and the configuration information of the main chain is consistent with the configuration information of the designated sub-chain, then consensus on-chain processing is performed on the packaged business block.

[0110] In some embodiments of this application, based on the aforementioned scheme, the main chain relay contract deployed in each of the sub-chains is deployed in the first block derived from each of the sub-chains.

[0111] In some embodiments of this application, based on the foregoing scheme, the blockchain system includes an accounting node network, a business node network, and a proxy node network connected between the accounting node network and the business node network; wherein, the proxy node network is used to receive transaction information to be uploaded to the blockchain from the business node network, and forward the transaction information to be uploaded to the blockchain to the accounting node network for packaging and uploading; the accounting node network is used to maintain the main chain and the at least one sub-chain.

[0112] In some embodiments of this application, based on the foregoing scheme, the main chain 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 accounting node clusters in the accounting node network.

[0113] In some embodiments of this application, based on the aforementioned scheme, the main chain block header further includes a configuration information version number, and the data processing device 1100 further includes: a third processing unit configured to generate a global configuration block and update the configuration information version number in the block header of the global configuration block if the configuration information of the main chain needs to be updated; and to perform consensus on-chain processing on the global configuration block to add the global configuration block to the main chain.

[0114] Figure 12 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0115] It should be noted that, Figure 12 The computer system 1200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0116] like Figure 12As shown, the computer system 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1202 or programs loaded from storage portion 1208 into Random Access Memory (RAM) 1203, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1203. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via bus 1204. An input / output (I / O) interface 1205 is also connected to bus 1204.

[0117] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0118] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs various functions defined in the system of this application.

[0119] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0120] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0121] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0122] In another aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled 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 perform the methods described in the above embodiments.

[0123] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0124] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0125] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0126] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data processing method for a blockchain system, characterized in that, 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. A main chain relay contract is deployed in each sub-chain. The main chain relay contract stores the main chain block header, which contains configuration information. The data processing method includes: When it is necessary to generate a new business block for a specified subchain, the configuration information of the main chain is obtained from the main chain relay contract; The configuration information of the main chain is compared with the configuration information of the designated sub-chain. 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 using the configuration information of the main chain. The configuration information includes business node configuration information and consensus node configuration information. The business node configuration information includes node identifiers of business nodes configured for the designated sub-chain to execute corresponding business operations, and the consensus node configuration information includes consensus nodes configured for the designated sub-chain to participate in consensus processing. If the configuration information of the main chain is consistent with the configuration information of the designated sub-chain, then a new business block is generated and consensus on-chain processing is performed.

2. The data processing method for a blockchain system according to claim 1, characterized in that, Updating the configuration information of the specified sub-chain using the configuration information of the main chain includes: The configuration information of the main chain is used as configuration transaction information to generate a configuration update block; The configuration update block is processed for consensus on-chain processing to add it to the designated subchain.

3. The data processing method for a blockchain system according to claim 2, characterized in that, The configuration update block also includes transaction information for updating the configuration information version number of a specified subchain in the main chain relay contract.

4. The data processing method for a blockchain system according to claim 1, characterized in that, The main chain block header also contains configuration information version number; The configuration information of the main chain is compared with the configuration information of the designated sub-chain, including: If the configuration information version number of the main chain is inconsistent with the configuration information version number of the specified sub-chain, then it is determined that the configuration information of the main chain is inconsistent with the configuration information of the specified sub-chain.

5. The data processing method for a blockchain system according to claim 1, characterized in that, The data processing method further includes: The designated subchain runs a main chain relay service upon startup. The main chain relay service is used to obtain the main chain block header and submit the main chain block header to the main chain relay contract.

6. The data processing method for a blockchain system according to claim 1, characterized in that, The main chain relay contract also contains the latest update time of the main chain block header; The data processing method further includes: When a new business block needs to be generated for the specified subchain, if the time difference between the local time and the latest update time exceeds a set threshold, the consensus processing for the new business block will be suspended.

7. The data processing method for a blockchain system according to claim 6, characterized in that, After pausing consensus processing for the new business block, the data processing method further includes: If the time difference between the local time and the latest update time is less than the set threshold, and the configuration information of the main chain is consistent with the configuration information of the designated sub-chain, then the business block generated in the package will undergo consensus on-chain processing.

8. The data processing method for a blockchain system according to claim 1, characterized in that, The main chain relay contract deployed in each of the sub-chains is deployed in the first block derived from each of the sub-chains.

9. The data processing method for a blockchain system according to claim 1, characterized in that, The blockchain system includes an accounting node network, a business node network, and a proxy node network connected between the accounting node network and the business node network. The proxy node network is used to receive transaction information to be uploaded to the blockchain from the business node network, and forward the transaction information to the accounting node network for packaging and uploading to the blockchain; the accounting node network is used to maintain the main chain and the at least one sub-chain.

10. The data processing method for a blockchain system according to claim 9, characterized in that, The main chain and the at least one sub-chain are maintained by the same ledger nodes in the ledger node network; or The main chain and the at least one sub-chain are maintained by different clusters of ledger nodes in the ledger node network.

11. The data processing method for a blockchain system according to any one of claims 1 to 10, characterized in that, The main chain block header also contains a configuration information version number, and the data processing method further includes: If the configuration information of the main chain needs to be updated, a global configuration block is generated, and the configuration information version number in the block header of the global configuration block is updated. The global configuration block is processed for consensus on-chain processing to add it to the main chain.

12. A data processing device for a blockchain system, characterized in that, 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. A main chain relay contract is deployed in each sub-chain. The main chain relay contract stores the main chain block header, which contains configuration information. The data processing device includes: The acquisition unit is configured to acquire the configuration information of the main chain from the main chain relay contract when it is necessary to generate a new business block for a specified sub-chain; The first processing unit is configured to compare the configuration information of the main chain with the configuration information of the designated sub-chain. 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 using the configuration information of the main chain. The configuration information includes business node configuration information and consensus node configuration information. The business node configuration information includes node identifiers of business nodes configured for the designated sub-chain to execute corresponding business operations, and the consensus node configuration information includes consensus nodes configured for the designated sub-chain to participate in consensus processing. The second processing unit is configured to, if the configuration information of the main chain is consistent with the configuration information of the designated sub-chain, package and generate a new business block and perform consensus on-chain processing.

13. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the data processing method of the blockchain system as described in any one of claims 1 to 11.

14. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the data processing method of the blockchain system as described in any one of claims 1 to 11.

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

Images