CN113098982A

CN113098982A - Block chain message transmission method and device

Info

Publication number: CN113098982A
Application number: CN202110611539.0A
Authority: CN
Inventors: 赵博然
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-06-02
Filing date: 2021-06-02
Publication date: 2021-07-09
Anticipated expiration: 2041-06-02
Also published as: CN113098982B

Abstract

One or more embodiments of the present specification provide a method and an apparatus for transmitting a block chain message. The method is applied to a block chain system comprising a plurality of node devices, and comprises the following steps: a first service instance receives and executes a first subtask contained in a target task generated by a first node instance on first node equipment where the first service instance is located, and initiates a message sending request to a first P2P component instance on the first node equipment according to a target task identifier of the target task, service data obtained by executing the first subtask and a second subtask depending on the first subtask in the target task; the first P2P component instance sends a blockchain message through a target consensus link between the first P2P component instance and the second P2P component instance, wherein the blockchain message comprises target task identification and business data; the second P2P component instance receives the blockchain message and sends it to the second service instance indicated by the target task identification for execution of the second subtask by the second service instance using the service data.

Description

Block chain message transmission method and device

Technical Field

One or more embodiments of the present disclosure relate to the field of block chain technologies, and in particular, to a method and an apparatus for transmitting a block chain message.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the process of implementing the blockchain service function, each blockchain node in the same blockchain network often needs to transmit service data to each other, so that a plurality of blockchain nodes together complete a certain task, and therefore each blockchain node needs to have the capability of transmitting service data between nodes.

In the related art, the problem is solved by establishing a service link, that is, establishing a service link between each blockchain node having a data transmission requirement in the same blockchain network, and transmitting service data based on the service link. However, as the structure of the block chain network becomes more complex or the number of block chain links with data transmission requirements increases, the complexity and difficulty of establishing a service link to be established also increase, so that the data transmission process based on the service link is more complex, the management and operation and maintenance costs of the block chain network are higher, and the service link is greatly updated when the network structure changes. Therefore, the method is difficult to ensure the execution efficiency of related tasks such as intelligent contracts and the like, thereby restricting the development of block chain business functions to a certain extent.

Disclosure of Invention

In view of the above, one or more embodiments of the present disclosure provide a method and an apparatus for transmitting a block chain message.

To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, a method for transmitting a blockchain message is provided, where the method is applied to a blockchain system including a plurality of node devices, each node device has a P2P component instance, a service instance, and a node instance belonging to the same blockchain network deployed thereon, and a consensus link for the node instances to participate in consensus is established between P2P component instances on different node devices, the method includes:

a first service instance receives and executes a first subtask contained in a target task generated by a first node instance on first node equipment where the first service instance is located, and initiates a message sending request to a first P2P component instance on the first node equipment according to a target task identifier of the target task, service data obtained by executing the first subtask and a second subtask dependent on the first subtask in the target task;

the first P2P component instance responding to the message sending request determines a second P2P component instance indicated by the second subtask, and sends a block chain message through a target consensus link between the first P2P component instance and the second P2P component instance, wherein the block chain message comprises the target task identification and the service data;

and the second P2P component instance receives the block chain message and sends the block chain message to a second service instance indicated by the target task identifier on a second node device where the second P2P component instance is located, so that the second service instance executes a second subtask by using the service data.

According to a second aspect of one or more embodiments of the present specification, a method for transmitting a blockchain message is provided, where the method is applied to a first service instance deployed in a first node device, a P2P component instance, a service instance, and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the first node device is located, and a consensus link for the node instance to participate in consensus is established between P2P component instances on different node devices, the method includes:

a first service instance receives and executes a first subtask contained in a target task generated by a first node instance on first node equipment where the first service instance is located;

the first service instance initiates a message sending request to a first P2P component instance on the first node device according to the target task identifier of the target task, the service data obtained by executing the first subtask and a second subtask dependent on the first subtask in the target task, so that the first P2P component instance determines a second P2P component instance indicated by the second subtask in response to the message sending request, and sends a block chain message through a target consensus link between the first P2P component instance and the second P2P component instance, wherein the block chain message comprises the target task identifier and the service data; and sending the received block chain message to a second service instance indicated by the target task identifier on a second node device where the second P2P component instance is located, and executing a second subtask by the second service instance by using the service data.

According to a third aspect of one or more embodiments of the present specification, a method for transmitting a blockchain message is provided, where the method is applied to a first P2P component instance deployed in a first node device, a P2P component instance, a service instance, and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the first node device is located, and a consensus link for the node instance to participate in consensus is established between P2P component instances on different node devices, where the method includes:

a first P2P component instance receives a message sending request initiated by a first service instance on first node equipment where the first P2P component instance is located, wherein the message sending request is initiated to the first P2P component instance according to a target task identifier of a target task, service data obtained by executing the first subtask and a second subtask which is dependent on the first subtask in the target task after the first service instance receives and executes the first subtask contained in the target task generated by the first node instance on the first node equipment;

the first P2P component instance responds to the message sending request to determine a second P2P component instance indicated by the second subtask, and sends a block chain message containing the target task identifier and the service data through a target consensus link between the first P2P component instance, so that the second P2P component instance sends the received block chain message to a second service instance indicated by the target task identifier on a second node device where the second P2P component instance is located, and the second service instance executes the second subtask by using the service data.

According to a fourth aspect of one or more embodiments of the present specification, a method for transmitting a blockchain message is provided, where the method is applied to a second P2P component instance deployed in a second node device, a P2P component instance, a service instance, and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the second node device is located, and a consensus link for the node instance to participate in consensus is established between P2P component instances on different node devices, where the method includes:

the second P2P component instance receives a blockchain message sent by the first P2P component instance on the first node device, wherein the blockchain message is sent by the first P2P component through a target consensus link between the first service instance and the second P2P component instance after determining the second P2P component instance indicated by the second subtask in response to a message sending request, and the message sending request is initiated by the first service instance on the first node device after receiving and executing a first subtask contained in a target task generated by the first node instance on the first node device, according to the target task identification of the target task, the service data obtained by executing the first subtask and a second subtask dependent on the first subtask in the target task;

and the second P2P component instance sends the block chain message to a second service instance indicated by the target task identification on a second node device where the second P2P component instance is located, so that the second service instance executes a second subtask by using the service data.

According to a fifth aspect of one or more embodiments of the present specification, a system for transmitting a blockchain message is provided, where the system includes a first node device and a second node device in a blockchain system, each node device has a P2P component instance, a service instance, and a node instance belonging to the same blockchain network deployed thereon, and a common identification link for the node instances to participate in common identification is established between P2P component instances on different node devices; wherein:

a first service instance in first node equipment receives and executes a first subtask contained in a target task generated by the first node instance on the first node equipment, and initiates a message sending request to a first P2P component instance on the first node equipment according to a target task identifier of the target task, service data obtained by executing the first subtask and a second subtask dependent on the first subtask in the target task;

the first P2P component instance in the first node device responds to the message sending request to determine a second P2P component instance indicated by the second subtask, and sends a block chain message through a target consensus link between the second P2P component instance, wherein the block chain message contains the target task identifier and the service data;

and the second P2P component instance in the second node equipment receives the block chain message and sends the block chain message to a second service instance indicated by the target task identifier on the second node equipment so as to execute a second subtask by the second service instance by using the service data.

According to a sixth aspect of one or more embodiments of the present specification, there is provided an apparatus for transmitting a blockchain message, where the apparatus is applied to a first service instance deployed in a first node device, a P2P component instance, a service instance, and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the first node device is located, and a consensus link for the node instance to participate in consensus is established between P2P component instances on different node devices, the apparatus including:

the subtask execution unit enables the first service instance to receive and execute a first subtask contained in a target task generated by a first node instance on first node equipment where the first service instance is located;

a request initiating unit, configured to enable a first service instance to initiate a message sending request to a first P2P component instance on a first node device according to a target task identifier of the target task, service data obtained by executing the first subtask, and a second subtask dependent on the first subtask in the target task, so that the first P2P component instance determines, in response to the message sending request, a second P2P component instance indicated by the second subtask, and sends a blockchain message through a target consensus link between the first P2P component instance and the second P2P component instance, where the blockchain message includes the target task identifier and the service data; and sending the received block chain message to a second service instance indicated by the target task identifier on a second node device where the second P2P component instance is located, and executing a second subtask by the second service instance by using the service data.

According to a seventh aspect of one or more embodiments of the present specification, there is provided a device for transmitting a blockchain message, where the device is applied to a first P2P component instance deployed in a first node device, a P2P component instance, a service instance, and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the first node device is located, and a consensus link for the node instance to participate in consensus is established between P2P component instances on different node devices, the device including:

a request receiving unit, configured to enable a first P2P component instance to receive a message sending request initiated by a first service instance on a first node device where the first P2P component instance is located, where the message sending request is initiated to the first P2P component instance according to a target task identifier of a target task, service data obtained by executing the first subtask, and a second subtask, which is dependent on the first subtask, in the target task after the first service instance receives and executes a first subtask included in the target task generated by the first node instance on the first node device;

and the message sending unit enables the first P2P component instance to determine a second P2P component instance indicated by the second subtask in response to the message sending request, and sends a block chain message containing the target task identifier and the service data through a target consensus link between the first P2P component instance, so that the second P2P component instance sends the received block chain message to a second service instance indicated by the target task identifier on a second node device where the second P2P component instance is located, and the second service instance executes the second subtask by using the service data.

According to an eighth aspect of one or more embodiments of the present specification, there is provided a device for transmitting a blockchain message, where the device is applied to a second P2P component instance deployed in a second node device, a P2P component instance, a service instance, and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the second node device is located, and a consensus link for the node instance to participate in consensus is established between P2P component instances on different node devices, the device including:

a message receiving unit, which enables the second P2P component instance to receive a blockchain message sent by the first P2P component instance on the first node device, wherein the blockchain message is sent by the first P2P component through a target consensus link between the first service instance and the second P2P component instance after determining the second P2P component instance indicated by the second subtask in response to a message sending request, and the message sending request is initiated by the first service instance on the first node device after receiving and executing a first subtask included in a target task generated by the first node instance on the first node device, according to a target task identifier of the target task, service data obtained by executing the first subtask, and a second subtask dependent on the first subtask in the target task;

and the message sending unit enables the second P2P component instance to send the blockchain message to a second service instance indicated by the target task identifier on a second node device where the second P2P component instance is located, so that the second service instance executes a second subtask by using the service data.

According to a ninth aspect of one or more embodiments herein, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method according to the first, second, third or fourth aspect by executing the executable instructions.

According to a tenth aspect of one or more embodiments of the present specification, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, perform the steps of the method according to the first, second, third or fourth aspect.

Drawings

FIG. 1 is a schematic diagram of creating an intelligent contract, provided by an exemplary embodiment.

FIG. 2 is a schematic diagram of a calling smart contract provided by an exemplary embodiment.

FIG. 3 is a schematic diagram of creating and invoking an intelligent contract according to an exemplary embodiment.

Fig. 4 is a schematic diagram of building a blockchain subnet based on a blockchain master network according to an exemplary embodiment.

Fig. 5 is a flowchart of a method for transmitting a block chain message according to an exemplary embodiment.

Fig. 6 is a diagram illustrating a procedure for transmitting a blockchain message according to an exemplary embodiment.

Fig. 7 is a flowchart of another method for transmitting a blockchain message according to an exemplary embodiment.

Fig. 8 is a flowchart of a method for transmitting a blockchain message according to an exemplary embodiment.

Fig. 9 is a flowchart of a method for transmitting a blockchain message according to another exemplary embodiment.

Fig. 10 is a block diagram of a system for transmitting a blockchain message according to an exemplary embodiment.

Fig. 11 is a schematic diagram of an apparatus according to an exemplary embodiment.

Fig. 12 is a block diagram of an apparatus for transmitting a block chain message according to an exemplary embodiment.

Fig. 13 is a block diagram of another apparatus for transmitting a blockchain message according to an exemplary embodiment.

Fig. 14 is a block diagram of an apparatus for transmitting a blockchain message according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participators joining the public chain can read the data record on the chain, participate in transaction, compete for accounting right of new blocks, and the like. Furthermore, each participant (i.e., node) is free to join and leave the network and perform related operations. Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.

Whether public, private, or alliance, may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking the ethernet as an example, the support user creates and invokes some complex logic in the ethernet network, which is the biggest challenge of ethernet to distinguish from bitcoin blockchain technology. The core of the ethernet plant as a programmable blockchain is the ethernet plant virtual machine (EVM), each ethernet plant node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

For example, as shown in fig. 1, after Bob sends a transaction containing information to create an intelligent contract to the ethernet network, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The "0 x6f8ae93 …" in fig. 1 represents the address of the contract, the data field of the transaction holds the byte code, and the to field of the transaction is empty. After agreement is reached between the nodes through the consensus mechanism, this contract is successfully created and can be invoked in subsequent procedures. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address, and the contract code is stored in the contract account. The behavior of the intelligent contract is controlled by the contract code. In other words, an intelligent contract causes a virtual account to be generated on a blockchain that contains a contract code and an account store (Storage).

As shown in fig. 2, still taking an ethernet house as an example, after Bob sends a transaction for invoking an intelligent contract to the ethernet house network, the EVM of a certain node may execute the transaction and generate a corresponding contract instance. The from field of the transaction in FIG. 2 is the address of the account of the initiator of the transaction (i.e., Bob), the "0 x6f8ae93 …" in the to field represents the address of the smart contract being invoked, and the value field is the value in EtherFang that is kept in the data field of the transaction as the method and parameters for invoking the smart contract. After invoking the smart contract, the value of balance may change. Subsequently, a client can view the current value of balance through a blockchain node (e.g., node 6 in fig. 2). The intelligent contract is independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is completed, transaction certificates which cannot be tampered and cannot be lost are stored on the blockchain.

A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. To create an intelligent contract in an ethernet workshop, the intelligent contract needs to be compiled, compiled into byte codes, deployed to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, and the intelligent contract codes are distributed and run in the virtual machine of each node in the Ethernet workshop network.

It should be noted that, in addition to the creation of the smart contracts by the users, the smart contracts may also be set by the system in the creation block. Such contracts are generally referred to as foundational contracts. In general, the data structure, parameters, attributes and methods of some blockchain networks may be set in the startup contract. Further, an account with system administrator privileges may create a contract at the system level, or modify a contract at the system level (simply referred to as a system contract). In addition to EVM in the ethernet, different blockchain networks may employ various virtual machines, which is not limited herein.

After executing a transaction that invokes a smart contract, a node in the blockchain network generates a corresponding receipt (receipt) for recording information related to executing the smart contract. In this way, information about the contract execution results may be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in the receipt. The message mechanism can implement message passing through events in the receipt to trigger the blockchain node to execute corresponding processing. The structure of the event may be, for example:

Event：

[topic][data]

......

in the above example, the number of events may be one or more; wherein, each event respectively comprises fields of a subject (topic) and data (data). The tile chain node may perform the preset process by listening to topic of the event, in case that predefined topic is listened to, or read the related content from the data field of the corresponding event, and may perform the preset process based on the read content.

In the event mechanism, it is equivalent to that there is a client with a monitoring function at a monitoring party (e.g. a user with a monitoring requirement), for example, an SDK or the like for implementing the monitoring function is run on the client, and the client monitors events generated by the blockchain node, and the blockchain node only needs to generate a receipt normally. The passage of transaction information may be accomplished in other ways than through the event mechanism described above. For example, the monitoring code can be embedded in a blockchain platform code running at blockchain nodes, so that the monitoring code can monitor one or more data of transaction content of blockchain transactions, contract states of intelligent contracts, receipts generated by contracts and the like, and send the monitored data to a predefined monitoring party. Since the snoop code is deployed in the blockchain platform code, rather than at the snooper's client, this implementation based on snoop code is relatively more proactive than the event mechanism. The above monitoring code may be added by a developer of the blockchain platform in the development process, or may be embedded by the monitoring party based on the own requirement, which is not limited in this specification.

The blockchain technology is different from the traditional technology in one of decentralization characteristics, namely accounting is performed on each node, or distributed accounting is performed, and the traditional centralized accounting is not performed. To be a difficult-to-defeat, open, non-falsifiable data record decentralized honest and trusted system, the blockchain system needs to be secure, unambiguous, and irreversible in the shortest possible time for distributed data records. In different types of blockchain networks, in order to keep the ledger consistent among the nodes recording the ledger, a consensus algorithm is generally adopted to ensure that the consensus mechanism is the aforementioned mechanism. For example, a common mechanism of block granularity can be implemented between block nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is recognized by other nodes, other nodes record the same block. For another example, a common mechanism of transaction granularity may be implemented between the blockchain nodes, such as after a node (e.g., a unique node) acquires a blockchain transaction, if the blockchain transaction is approved by other nodes, each node that approves the blockchain transaction may add the blockchain transaction to the latest block maintained by itself, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism for the blockchain node to achieve a global consensus on the block information (or called blockdata), which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: proof of Work (POW), Proof of stock (POS), Proof of commission rights (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, HoneyBadgerBFT algorithm, etc.

Due to the decentralized characteristic of the blockchain network, all blockchain nodes in the blockchain network can maintain the same blockchain data, and the special requirements of part of nodes cannot be met. Taking a federation chain as an example, all federation members (i.e., node members in a federation) may form a blockchain network, and all federation members respectively have corresponding blockchain nodes in the blockchain network, and may obtain all transactions and related data occurring on the blockchain network through the corresponding blockchain nodes. In some cases, however, there may be some security-required transactions that some coalition members wish to complete, which may both wish to be able to verify on the blockchain or to take advantage of other advantages of blockchain technology, and avoid other coalition members from viewing the transactions and associated data. Although the federating members can additionally build a new blockchain network in a manner similar to the blockchain network including all federating members described above, the new blockchain network is built from scratch, which consumes a lot of resources and is time-consuming in both the building process and the post-building configuration process. The demand between the members of the federation is often temporary or has a certain timeliness, so that the newly-built blockchain network can quickly lose significance due to the disappearance of the demand, thereby further increasing the link establishment cost of the blockchain network. The demands among the federation members often change, and the federation members corresponding to each demand often differ, so that a new blockchain network may need to be established whenever a change occurs in a federation member, thereby causing a great waste of resources and time.

For this purpose, the established blockchain network may be used as a blockchain master network, and a blockchain sub-network may be established on the basis of the blockchain master network. Then, in a federation chain scenario such as that described above, federation members can build the required blockchain subnets on a blockchain master basis based on their own needs, already participating in the blockchain master. Because the block chain sub-networks are established on the basis of the block chain main network, compared with the process of completely and independently establishing a block chain network, the block chain sub-networks are greatly reduced in consumed resources, required time consumption and the like, and are extremely high in flexibility.

The process of quickly establishing the block chain sub-network based on the block chain main network comprises the following steps: each main network node in the block chain main network respectively acquires transactions for establishing a block chain sub-network, wherein the transactions comprise configuration information of the block chain sub-network, and the configuration information comprises identity information of node members. Then, each main network node in the block chain main network executes the transaction respectively; when the first main network node belongs to the node member indicated by the configuration information, the node device deploying the first main network node generates an creation block containing the configuration information based on the transaction and starts a first sub-network node belonging to the block chain sub-network.

The transaction for establishing the blockchain sub-network can be initiated by an administrator of the blockchain main network, that is, the administrator is only allowed to establish the blockchain sub-network on the basis of the blockchain main network, and the establishment permission of the blockchain sub-network is prevented from being opened to a common user, so that the security problem caused by the establishment permission can be prevented. In some cases, a common user of the blockchain main network may also be allowed to initiate a transaction for building the blockchain sub-network, so as to meet networking requirements of the common user, and the common user can still quickly build the blockchain sub-network under the condition that an administrator is not convenient to initiate the transaction.

For example, as shown in fig. 4, the main network of the blockchain is subnet0, and the subnet0 includes blockchain link points nodeA, nodeB, nodeC, nodeD, and nodeE. Assume nodeA, nodeB, nodeC, and nodeD wish to build a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to build a blockchain subnet, the transaction to build the blockchain subnet can be initiated by nodeA to subnet 0; if the nodeb is an administrator and only the administrator is allowed to initiate a transaction for building the blockchain subnet, nodeb a to nodeb d need to make a request to nodeb, so that nodeb initiates the transaction for building the blockchain subnet to subnet 0; if the node E is an administrator but allows a common user to initiate the transaction of building the blockchain sub-network, the node A-node E can initiate the transaction of building the blockchain sub-network to the subnet 0. Of course, the blockchain link point initiating the transaction for building the blockchain subnet does not necessarily participate in the built blockchain subnet, regardless of the administrator or the general user, for example, although the blockchain subnet is finally built by nodeA, nodeB, nodeC and nodeD, the transaction for building the blockchain subnet may be initiated by nodeE to subnet0, but the transaction for building the blockchain subnet is not necessarily initiated by nodeA to nodeD.

When the blockchain sub-network is constructed on the basis of the blockchain main network, it is easy to understand that a logical hierarchical relationship exists between the blockchain sub-network and the blockchain main network. For example, when a blockchain subnet1 is established on the subnet0 shown in fig. 4, it can be considered that the subnet0 is at the first layer, the subnet1 is at the second layer, the subnet0 is the parent network of the subnet1, and the subnet1 is the subnet 0. And the blockchain sub-network may also constitute a corresponding blockchain sub-network, for example, another blockchain sub-network bnet3 may be further constituted on the basis of the sub-net 1 in fig. 4, at this time, it may be considered that the sub-net is in the third layer, the sub-net 1 is the parent network corresponding to the sub-net 3, the sub-net 3 is the subnet of the sub-net 1, and the sub-net 3 is the grandchild network of the sub-net 0, similarly, the sub-net 3 may still newly constitute the blockchain sub-network on the basis thereof, so that such a multi-level tree structure is formed between the blockchain networks, and in this specification, any blockchain network is managed by its corresponding parent network, that is, managed by the blockchain network constituting any blockchain network of the blockchain network, so that in the blockchain sub-network as shown in fig. 4, the main level of the blockchain is the root network, and each blockchain sub-network is the corresponding tree node sub-chain sub-network of the other blockchain sub-network, and its corresponding system is represented by any blockchain sub-chain sub-network of the blockchain system, as a specific example, when the block chain master network is a bottom layer block chain network, the block chain master network is managed by the block chain master network itself. The block chain master network in this specification may be a bottom layer block chain network, where the bottom layer block chain network refers to a block chain sub-network that is not established on the basis of other block chain networks, and therefore there is no other block chain network except the block chain master network and the block chain master network can manage the block chain master network, for example, the subnet0 in fig. 4 may be considered as a block chain master network belonging to a bottom layer block chain network type, and the subnet0 manages the subnet0 itself, and of course, the block chain master network may also be a sub-network of another block chain network, which is not limited in this specification. The block chain network tree system realizes layer-by-layer management by managing the corresponding child nodes through the father nodes, reduces the management pressure of the block chain main network, and simultaneously avoids exposing subnet information of an upper network to a lower network, thereby realizing the secret management of networks at all levels.

After the transaction for establishing the blockchain sub-network is sent to the blockchain main network, the consensus nodes in the blockchain main network perform consensus, and after the consensus is passed, each main network node executes the transaction to complete establishment of the blockchain sub-network. The consensus process depends on the consensus mechanism employed, such as any of the consensus mechanisms described above, and is not limited by the present specification.

The configuration information is included in the transaction of the block chain sub-network, and the configuration information can be used for configuring the block chain sub-network, so that the block chain sub-network meets networking requirements. For example, by including the identity information of the node members in the configuration information, it is possible to specify which blockchain nodes the constructed blockchain subnet includes.

The identity information of the node member may include a public key of the node, or other information capable of representing the node identity, such as a node ID, which is not limited in this specification. Taking a public key as an example, each blockchain node has one or more corresponding sets of public-private key pairs, and the private key is held by the blockchain node and the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Therefore, for blockchain nodes that are desired to be node members of a blockchain subnet, the public keys of these blockchain nodes can be added to the transaction of the building blockchain subnet as the identity information of the node members.

The first master network node may be a blockchain node on the blockchain master network that belongs to a node member indicated by the configuration information. When the blockchain subnet is established, the first master network node does not directly join the blockchain subnet to become a node member of the blockchain subnet, but the first subnet node needs to be generated by the node device for deploying the first master network node and becomes a node member of the blockchain subnet. The first main network node and the first sub-network node correspond to the same blockchain member, for example, correspond to the same alliance chain member in an alliance chain scene, but the first main network node belongs to a blockchain main network and the first sub-network node belongs to a blockchain sub-network, so that the blockchain member can participate in the transaction of the blockchain main network and the blockchain sub-network respectively; moreover, because the blockchain main network and the blockchain sub-network belong to two mutually independent blockchain networks, the blocks generated by the first main network node and the blocks generated by the first sub-network node are respectively stored in different storages (the adopted storages can be databases, for example) on the node device, so that mutual isolation between the storages used by the first main network node and the first sub-network node respectively is realized, and thus, data generated by the blockchain sub-network can only be synchronized among the node members of the blockchain sub-network, so that the blockchain members only participating in the blockchain main network cannot obtain the data generated by the blockchain sub-network, the data isolation between the blockchain main network and the blockchain sub-network is realized, and the transaction requirements between partial blockchain members (namely, the blockchain members participating in the blockchain sub-network) are met.

It can be seen that the first master network node and the first sub-network node are logically divided block chain link points, and from the perspective of physical devices, the node devices which are equivalent to the first master network node and the first sub-network node are deployed to participate in both the block chain master network and the block chain sub-network. Since the blockchain main network and the blockchain sub-network are independent from each other, so that the identity systems of the two blockchain networks are also independent from each other, even though the first main network node and the first sub-network node may adopt the same public key, the first main network node and the first sub-network node should be regarded as different blockchain nodes. For example, in fig. 4, the nodeA in subnet0 corresponds to a first master network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to a first sub-network node. It can be seen that, since the identity systems are independent of each other, even if the public key adopted by the first subnet node is different from that of the first master network node, the implementation of the solution in this specification is not affected.

Of course, the node members of the blockchain sub-network are not necessarily only part of the node members of the blockchain main network. In some cases, the node members of the blockchain subnet may be completely consistent with the node members of the blockchain main network, and at this time, all the blockchain members may obtain data on the blockchain main network and the blockchain subnet, but data generated by the blockchain main network and the blockchain subnet may still be isolated from each other, for example, one type of service may be implemented on the blockchain main network, and another type of service may be implemented on the blockchain subnet, so that service data generated by the two types of services may be isolated from each other.

In addition to the identity information of the node members described above, the configuration information may include at least one of: the network identifier of the blockchain subnet, the identity information of an administrator of the blockchain subnet, the attribute configuration for the blockchain platform code, and the like, which are not limited in this specification. The network identifier is used to uniquely characterize the blockchain subnet, and thus the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets established on the blockchain main network. Identity information of an administrator of the blockchain subnet, such as a public key of a node member as the administrator; the administrators of the blockchain main network and the blockchain sub-network may be the same or different.

One of the advantages of building the blockchain subnet by using the blockchain master network is that since the first master network node is already deployed on the node device generating the first subnet node, the blockchain platform code used by the first master network node can be multiplexed on the first subnet node, so that repeated deployment of the blockchain platform code is avoided, and the building efficiency of the blockchain subnet is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node may reuse the attribute configuration adopted on the first master network node; if the configuration information includes the attribute configuration for the blockchain platform code, the first subnet node may adopt the attribute configuration, so that the attribute configuration adopted by the first subnet node is not limited by the attribute configuration of the first main network node and is not related to the first main network node. The attribute configuration for blockchain platform code may include at least one of: code version number, whether consensus is required, type of consensus algorithm, block size, etc., which is not limited in this specification.

The transactions that make up the blockchain subnet include transactions that invoke contracts. The address of the invoked smart contract, the method invoked and the incoming parameters may be specified in the transaction. For example, the contract invoked may be the aforementioned startup contract or system contract, the method invoked may be a method that builds a blockchain subnet, and the incoming parameters may include the configuration information described above. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

the from field is information of the initiator of the transaction, such as administeror indicating that the initiator is an Administrator; the to field is the address of the intelligent contract being called, for example, the intelligent contract may be a Subnet contract, and the to field is specifically the address of the Subnet contract; the method field is a called method, for example, the method used in the Subnet contract to build the blockchain Subnet may be AddSubnet (string), and string is a parameter in the AddSubnet () method, and the value of the parameter is represented by the aforementioned example, which is specifically the aforementioned configuration information.

Take the example that nodes nodeA-nodeS on Subnet0 execute a transaction that invokes the AddSubnet () method in the Subnet contract. After the transaction passes the consensus, nodeA-nodeE respectively execute the AddSubnet () method and transmit configuration information to obtain corresponding execution results.

The execution result of the contract may include the configuration information, and the execution result may be in the receipt as described above, and the receipt may contain the event related to the execution of the adsubnet () method, i.e., the networking event. The topoc of a networking event may contain a predefined networking event identification to distinguish it from other events. For example, in an event related to the execution of the AddSubnet () method, the content of topic is a keyword subnet, and the keyword is distinguished from topic in the event generated by other methods. Then, nodeA to nodeE can determine to monitor the event related to executing the AddSubnet () method, that is, the networking event, when the topic including the keyword subnet is monitored by monitoring topic included in each event in the generated receipt. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

then, when the nodeA-nodeE monitors the 1 st event, the event is determined to be irrelevant to the AddSubnet () method because the contained topic content is other; and when the 2 nd event is monitored by the nodeA to nodeE, determining that the event is related to the AddSubnet () method because the contained topic content is subnet, and further reading a data field corresponding to the event, wherein the data field comprises the configuration information. Taking the example that the configuration information includes the public key of the node member of the blockchain subnet, the content of the data field may include, for example:

{subnet1；

the public key of nodeA, the IP of nodeA, port number … of nodeA;

public key of nodeB, IP of nodeB, port number … of nodeB;

public key of nodeC, IP of nodeC, port number … of nodeC;

the public key of nodeD, the IP of nodeD, port number … of nodeD;

}

where subnet1 is the network identification of the blockchain subnet that one wishes to create. Each blockchain link point in the blockchain master network may record network identifiers of all blockchain subnets that have been created on the blockchain master network, or other information related to the blockchain subnets, which may be maintained in the Subnet contract, for example, and may specifically correspond to values of one or more contract states included in the Subnet contract. Then, nodeA-nodeE can determine whether the subnet1 already exists according to the recorded network identifiers of all the created subnet block chains; if not, subnet1 is the new blockchain subnet that needs to be created currently, and if so, subnet1 is already present.

In addition to the network identifier of the new blockchain subnet that is desired to be created, a predefined new network identifier may be used, which indicates that the corresponding networking event is used to create the new blockchain subnet. For example, the subnet1 may be replaced by newsbnet, where newsbnet is a predefined new network identifier, and when the nodeA to nodeE recognize that the data field includes newsbnet, it may be determined that an event including newsbnet is a networking event and a new blockchain subnet needs to be created.

Besides the network identification subnet1, the data field also contains the identity information of each node member. The node device deploying the first master network node may monitor the generated receipt, and obtain, by the node device deploying the first master network node, configuration information or an innovation block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first master network node belongs to the node member. For example, when determining that subnet1 is a blockchain subnet that needs to be newly built, nodeA to nodeE further identify the identity information of the node members included in the data field to determine their own processing methods. For example, the nodeA to nodeD may find that the data field includes identity information such as their own public key, IP address, and port number, and assume that nodeA to nodeD are respectively deployed on node devices 1 to 4, taking nodeA and node device 1 as an example: the nodeA triggers the node device 1, so that the node device 1 obtains the configuration information from the data field based on the message mechanism and generates a created block containing the configuration information, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated created block, so as to become a subnet node of subnet 1; similarly, nodeB will trigger NodeB1 to be generated by node device 2, nodeC will trigger NodeC1 to be generated by node device 3, and nodeD will trigger NodeD1 to be generated by node device 4. And the nodeE finds that the identity information contained in the data field is not matched with the nodeE, and if the nodeE is deployed on the node device 5, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a node in the subnet 1.

As mentioned above, the first master network node and the first subnet node do not necessarily adopt the same identity information. Therefore, in the above embodiment, the data field may include the identity information previously generated for nodeA 1-nodeD 1, and is different from the identity information of nodeA-nodeD. Still taking nodeA as an example, if identity information of nodeA1 is found in the data field, nodeA triggers node device 1 to generate a birth block, deploy nodeA1, and load the birth block by nodeA 1; the nodeB-nodeD processing modes are similar, and are not described in detail here.

In addition to configuration information, the execution results of the contract may include a foundational block. In other words, in addition to the configuration information contained in the data field, the created block containing the configuration information may be directly generated in the process of executing the contract call, so that the created block is contained in the data field, and for the nodeA to nodeD described above, the corresponding node devices 1 to 4 may directly obtain the created block from the data field through a message mechanism without self-generation, so that the deployment efficiency of nodeA1 to nodeD1 may be improved.

In this specification, the transaction for creating the blockchain subnet may not be a transaction for calling an intelligent contract, so that the blockchain network that does not support the intelligent contract may also implement the technical solution of this specification, thereby quickly creating the blockchain subnet on the basis of the blockchain main network. For example, a group network transaction type identifier may be predefined, and when a transaction includes the group network transaction type identifier, it indicates that the transaction is used for building a new blockchain subnet, that is, the transaction is a transaction for building a blockchain subnet. The blockchain platform code may include related processing logic for constructing a blockchain sub-network, so that when a first master network node running the blockchain platform code performs a transaction, if the transaction is found to include the networking transaction type identifier and the first master network node belongs to a node member indicated by configuration information in the transaction, a node device deploying the first master network node may be triggered to generate an innovation block including the configuration information and start the first sub-network node based on the processing logic, and the innovation block is loaded by the first sub-network node to form the blockchain node in the blockchain sub-network.

The node device is equivalent to deploying a blockchain node on the node device by pulling up a process and creating an instance in the process, and running blockchain platform code by the instance. For the first master network node, a first instance is created by the node device in the above process and formed by the first instance running blockchain platform code. Similarly, for the first subnet node, a second instance different from the first instance is created by the node device in the above process, and is formed by the second instance running the blockchain platform code. When the first instance and the second instance are located in the same process, the deployment difficulty of the first subnet node can be reduced and the deployment efficiency can be improved because cross-process interaction is not involved; of course, the second instance may be in a different process on the node device than the first instance, and this specification does not limit this. In fact, each block link point deployed on any node device referred to in the embodiments of this specification is a different block chain instance running on any node device, blocks generated by each block link point deployed on any node device are respectively stored in different storages (for example, a database) on any node device, and the storages used by each block link point deployed on any node device are isolated from each other.

By the method, the block chain sub-network can be created on the block chain main network. Taking fig. 4 as an example, the subnet0 originally includes nodeA to nodeE, and can construct subnet1 on the basis of subnet0, where subnet1 includes nodeA1 to nodeD1, and nodeA1, nodeB and nodeB1, nodeC and nodeC1, and nodeD1 are respectively disposed on the same node device. Similarly, a subnet2 or more block chain subnets can be constructed on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2, and nodeE2, and nodeA1, nodeA2, nodeB1, nodeB2, nodeC1, nodeD1, and nodeE2 are respectively deployed on the same node device. And, subnet1, subnet2, etc. may be used as a blockchain main network, and a blockchain subnet is further constructed on the basis, for example, a blockchain subnet3 is constructed on the basis of subnet1, the process is similar to the construction of subnet1 or subnet2, only the blockchain is replaced by a main blockchain subnet1, which is not described herein, and finally, the subnet3 includes nodeA3, nodeB3 and nodeC3, so that nodeA and nodeA1, nodeA2, nodeA3, nodeB and nodeB1, nodeB2, nodeB3, nodeC and nodeC1, nodeC2 and nodeC3 are respectively deployed on the same node device.

For any blockchain network established in the manner described above (such as the blockchain main network or the blockchain sub-network described above), service functions such as contract execution, transaction consensus, data storage, and the like can be realized, and in this process, each blockchain node in the blockchain network often needs to transmit a blockchain message to each other, and therefore each blockchain node needs to have the capability of transmitting a blockchain message between nodes. For example, in the case of a contract execution process, an intelligent contract may be deployed in any of the above blockchain networks, that is, a contract code (e.g., bytecode) of the intelligent contract runs in a distributed manner in virtual machines of each blockchain node constituting the blockchain network. The execution process of the intelligent contract is the execution process of the contract task, and the process can be divided into the execution processes of a plurality of subtasks (i.e. the contract task is divided into a plurality of subtasks), so that each subtask can be sequentially executed by service units deployed in node devices where different block chain nodes are located, and the node device executing the previous subtask transmits a corresponding execution result (i.e. service data) to the node device executing the next subtask to serve as a necessary parameter for executing the next contract task.

In order to implement data transmission between each blockchain node in the same blockchain network, a dedicated service link is usually adopted at the present stage, that is, a service link is established between each blockchain node having a data transmission requirement in the same blockchain network, and a blockchain message is transmitted based on the service link. However, as the structure of the blockchain network becomes more complex or the number of blockchain link points having data transmission requirements gradually increases, the complexity and difficulty of establishing a service link to be established also increase, and not only the data transmission process based on the service link is more complex, but also the service link is greatly updated when the network structure changes. Therefore, the method is difficult to ensure the execution efficiency of related tasks such as intelligent contracts and the like, thereby restricting the development of block chain business functions to a certain extent.

In order to solve the problem, the present specification provides a method for transmitting a blockchain message, where a consensus link pre-established between P2P component instances deployed in node devices where each blockchain node is located in the same blockchain network is used to transmit a blockchain message containing service data, that is, the method implements transmission of the service data by multiplexing the consensus link in the blockchain network, so as to execute a target task. Therefore, a special service link does not need to be additionally established, the complexity of the block chain network is effectively reduced, the block chain message is transmitted by multiplexing the consensus link, the consensus link has the consensus function and can realize partial service functions, the reuse of the consensus link is realized, the overall utilization rate of the consensus link serving as a block chain network infrastructure is improved, the management and operation and maintenance cost of the block chain network is reduced, and the efficient execution of each subtask in the target task is facilitated. The transmission scheme of the blockchain message in the present specification is described below with reference to fig. 5.

Referring to fig. 5, fig. 5 is a flowchart illustrating a method for transmitting a blockchain message according to an exemplary embodiment. As shown in fig. 5, the method is applied to a blockchain system including a plurality of node devices, each node device is deployed with a P2P component instance, a service instance, and a node instance belonging to the same blockchain network, and a consensus link for the node instance to participate in consensus is established between P2P component instances on different node devices, and the method may include the following steps:

step 502, a first service instance receives and executes a first subtask included in a target task generated by a first node instance on a first node device where the first service instance is located, and initiates a message sending request to a first P2P component instance on the first node device according to a target task identifier of the target task, service data obtained by executing the first subtask, and a second subtask dependent on the first subtask in the target task.

It should be noted that, in the node device described in this specification, a plurality of function instances may be deployed. For example, a blockchain platform code may be deployed, and the node device may form a blockchain node instance locally during running the platform code. The block chain network to which the block chain link point instance deployed in the node device belongs may be a block chain main network or a block chain sub-network established in the foregoing manner, and of course, the present scheme may also be applied to an independent block chain network (i.e., the block chain network is not established based on other block chain networks, and there is no other block chain network established based on the block chain network). In other words, the method for transmitting the blockchain message described in this specification may be applied to any blockchain network, and the specification does not limit the interrelationship between the blockchain network and other blockchain networks. In addition, a blockchain service code is also deployed in the node device, a service instance is locally formed in the process of running the service code by the node device, and at least one service instance, such as a storage instance for implementing a data read/write function, a calculation instance for implementing a calculation function such as privacy calculation, and an encryption instance for implementing a data encryption function, can be implemented in any node device, and is not described in detail again.

The node equipment is also provided with a block chain consensus code, and a consensus component instance is locally formed in the process of running the consensus code by the node equipment; and the node device is also deployed with P2P component code, and the P2P component instance is formed locally when the node device runs the P2P component code. A consensus link is established between the P2P component instances deployed in the node devices where the node instances belong to the same blockchain network, so that the consensus component instances in the node devices complete a consensus process for messages including data, transactions, and the like through the consensus link. In addition, the specific process of implementing message consensus by any consensus component instance in the blockchain network through the node device established between P2P component instances does not differ essentially from the consensus process described in the related art, and is not described herein again.

In the process of deploying the function instance by any node device, the node device may respectively pull up a plurality of processes, and respectively run the blockchain platform code, the blockchain service code, the blockchain consensus code, and the P2P component code in different processes, so as to respectively deploy each corresponding function instance in different processes. Alternatively, the service instance and other function instances may be deployed in different processes, and other function instances may be deployed in any process. If a plurality of service instances are deployed in the same node device, each service instance may be deployed in different processes, or all service instances may be deployed in the same process, which is not described again. By the method, any service instance deployed in any node device is in different processes with other function instances, so that the service instance and the other function instances are guaranteed to generate less interference in the operation process, fault isolation among the different function instances is realized, and the operation stability of the block chain network is improved. Of course, in order to reduce the delay that may be generated during the above cross-process interaction process to ensure the transmission efficiency of the blockchain message, the node device may also deploy the service instance and the P2P component instance in the same process, which is not limited in this specification.

In addition, only one block link point instance belonging to the above block chain network may be deployed in the node device, multiple block link point instances belonging to the same block chain network may also be deployed at the same time, and multiple block chain node instances belonging to different block chain networks may also be deployed (of course, this scheme only focuses on the execution process of a block link point instance belonging to a certain block chain network on an intelligent contract deployed in the block chain network), and the number of block link point instances deployed in the node device is not limited in this specification.

In an embodiment, each node device in the block chain system may be deployed with at least one node of the block chain network, the block chain networks related to the block chain system form a tree structure with the block chain main network as a root node and each block chain sub-network as other nodes, and any block chain sub-network is managed by the block chain network corresponding to its parent node. As shown in fig. 4, the blockchain main network subnet0 is a root node, each blockchain subnet1, subnet2, and subnet3 are other nodes, and each blockchain network forms a tree structure. As a blockchain subnet constructed on the basis of subnet0, subnet1 and subnet2 are managed by subnet0, and similarly, subnet3 is managed by subnet1, so that a management architecture corresponding to a tree structure is formed between the blockchain networks, and expansion and management of the blockchain are facilitated.

In an embodiment, the blockchain network in which the node apparatus 1 and the node apparatus 2 are located may be a fully-connected structure, that is, a consensus link is established between two P2P component instances deployed in the node apparatuses in which the node instances belonging to the blockchain network are respectively located. At this time, direct transmission of the blockchain message can be realized between any two P2P component instances in the blockchain network, and the blockchain message does not need to be forwarded by an intermediate party, so that routing information in the blockchain network does not need to be maintained, which is beneficial to realizing fast transmission of the blockchain message and light weight of the blockchain node. As shown in fig. 4, the blockchain master network subnet0 is a blockchain network with a fully-connected structure, so that any blockchain node (e.g., node a) in the network can transmit a blockchain message carrying traffic data to the corresponding blockchain node through a consensus link with any other blockchain node (e.g., node B, node C, node D, and/or node E) in the network.

Alternatively, the blockchain network may be a non-fully-connected structure, that is, a shared link is established between P2P component instances respectively deployed in partial node devices in the blockchain network, and at this time, blockchain messages can be transmitted between blockchain nodes in the blockchain network where the shared link is established. As shown in fig. 4, the blockchain subnet2 established based on the blockchain master network subnet0 is a blockchain network with a non-fully-connected structure, so that any blockchain node (e.g., node a 2) in the network can transmit a blockchain message carrying service data to a corresponding blockchain node through a consensus link between other blockchain nodes (e.g., node C2 and/or node E2) that establish a consensus link with itself in the network. However, since no consensus link is established between node a2 and node B2, no data transmission can be achieved between the two nodes using the scheme described herein.

As described above, a node instance in the blockchain network may transmit a blockchain message through a pre-established consensus link between a P2P component instance deployed in the node device where the node instance is located and P2P component instances deployed in other node devices. This process involves the sender of the blockchain message (i.e., the first P2P component instance) and the recipient of the blockchain message (i.e., the second service instance) and their respective node devices. Taking the example of the transmission of the blockchain message between the node a and the node B in the blockchain master network subnet0 shown in fig. 4, the internal structure and connection relationship of the two node devices can be seen in fig. 6.

As shown in fig. 6, a P2P component instance a, a node instance a, and a consensus component instance a are deployed in the node device 1, and at least one service instance is also deployed: service instance A1-service instance Am (wherein m is larger than or equal to 2); similarly, a P2P component instance B, a node instance B, and a consensus component instance B are deployed in the node device 2, and at least one service instance is also deployed: service instance B1-service instance Bn (where n ≧ 2). The following is a detailed description of the example of the service instance a1 transmitting a blockchain message containing service data to the service instance B1 via a consensus link between the P2P component instance a and the P2P component instance B. Obviously, in this process, the first node device, the first node instance, the first P2P component instance, and the first service instance are node device 1, node instance A, P2P component instance a, and service instance a1, respectively; the second node device, the second node instance, the second P2P component instance, and the second service instance are node device 2, node instance B, P2P component instance B, and service instance B1, respectively, and are described herein.

In this specification, a service instance a1 first acquires and executes a first subtask in a target task, and then, after the completion, initiates a message sending request to a P2P component instance a, where the message sending request carries a target task identifier and service data to be transmitted, so that after the P2P component instance a receives the request, first determines a second P2P component instance indicated by a second subtask having a dependency relationship with the first subtask, and then sends, through a consensus link between itself and the second P2P component instance, a block chain message containing the target task identifier and the service data, which is generated in response to the message sending request, to the second P2P component instance.

In this specification, any node instance in the block chain network may participate in a process of processing a target task including multiple subtasks (to be executed), where the target task includes a second subtask that depends on a first subtask, and an executing party (i.e., a service instance that executes the subtask) corresponding to the second subtask may be a different service instance in different node devices, or may be a different service instance in the same node device, and of course, the multiple subtasks may also be executed by the same service instance. The present specification only focuses on a scenario where different service instances in different node devices execute a first subtask and a second subtask, respectively, that is, the first subtask is executed by a first service instance in a first node device, and the second subtask is executed by a second service instance in a second node device. In addition, the second subtask depends on the first subtask, that is, the execution of the second subtask requires the execution result of the first subtask (that is, the service data), so that the second service instance can execute the second subtask by using the service data after acquiring the service data obtained by the first service instance executing the first subtask. The solution of the present specification focuses on the process of delivering the service data from the first service instance to the second service instance.

The above embodiment is adopted, wherein the node instance a may obtain the first subtask in various ways. For example, a target task sent by another node instance (e.g., node instance C) may be received, a target task specified or created by a member of the blockchain corresponding to the target task may be received, and an intelligent contract locally deployed (i.e., deployed in the blockchain network) may be executed to generate the target task. Taking the example of executing an intelligent contract to generate a target task, the target task may be included in a task allocation event generated by executing an intelligent contract, so that the service instance a1 may retrieve a first subtask from the event in the event of listening to the task allocation event. In fact, because the target task also includes a second subtask, the service instance A1 may also determine the second subtask from the event. In addition, because the node instance a may participate in the processing of multiple tasks at the same time, in order to avoid task confusion, the intelligent contract may assign a target task identifier to a target task when the target task is generated, so as to distinguish the target task from other tasks. Therefore, the service instance a1 can obtain the target task identifier of the target task in the task allocation event.

When the target task is included in a task allocation event generated by the first node instance executing the intelligent contract, the target task identifier may be a contract identifier of the intelligent contract, such as a contract number, a contract name, a contract address, a public key corresponding to the contract, a summary of the public key, and the like, so as to ensure one-to-one correspondence between the target task identifier and the intelligent contract. However, it should be noted that it should be ensured that only one target task is generated at the same time during the execution of the intelligent contract. Alternatively, in a case where the same blockchain network to which the first node instance and the second node instance belong is a blockchain subnet managed by a blockchain main network, the target task identifier may be a subnet identifier of the blockchain subnet, and as in a case where the solution in this specification is applied to a blockchain subnet1, the target task identifier may be a subnet identifier of a subnet 1.

Further, where the first node instance executes an intelligent contract to produce the target task, a workflow may be defined in the intelligent contract. For example, the workflow may include a plurality of task nodes, and taking task a corresponding to task node a and task B corresponding to task node B as an example, task B may depend on task a, that is, task a and task B are in a serial relationship, so that the execution of task B needs to use the execution result of task a (that is, task B needs to be executed after task a is completely executed).

The target task may correspond to the workflow defined in the intelligent contract, where the first subtask and the second subtask correspond to adjacent task nodes having a serial relationship in the workflow, respectively. For example, the first subtask may be the task a, the second subtask may be the task B, and of course, other subtasks may also be included in the target task, such as the task C and the task D. Alternatively, the target task may also correspond to any task node in a workflow defined in the intelligent contract, that is, the target task may be a task corresponding to any task node. Taking the target task as the task a, the first sub-task and the second sub-task may be different sub-tasks separated from the task a, such as the sub-task a1 and the sub-task a 2.

The first service instance can execute the first subtask after acquiring the subtask; or to avoid invalid execution, a determination may be made first, for example, when it is determined that the first subtask is allocated to the member of the blockchain to which the first node device belongs, the first subtask is executed; otherwise, the first subtask is abandoned.

In step 504, the first P2P component instance determines a second P2P component instance indicated by the second subtask in response to the message sending request, and sends a blockchain message over the target consensus link with the second P2P component instance, the blockchain message including the target task identity and the service data.

The reason why the first service instance can transmit the blockchain message to the second service instance through the consensus link between the first P2P component instance and the second P2P component instance is that the P2P component instance deployed in the node device provides the calling function of the consensus link for the service instance, that is, the P2P component instance services its P2P communication capability to be provided for each service instance in the blockchain device where it is located.

In one embodiment, the P2P component instance in any node device may implement the servicing of P2P communication capabilities in the following manner. Taking the P2P component instance a shown in fig. 6 as an example, during the startup process of the node device 1, the node device 1 may obtain, from the world state of the blockchain network to which the node instance a belongs, configuration information that the P2P component instance a provides external services, such as a listening address, a network port, and a public key used during TLS (Transport Layer Security protocol) communication, so that the P2P component instance a may start a common identification link with another P2P component instance using the configuration information. In addition, the P2P component instance a may register itself on the service bus inside the node device 1 by using the public key, so that other function instances inside the node device 1 may access the P2P communication service provided by the P2P component instance a inside the node device 1 through the internal bus by using the calling capability provided by the service framework of the node device 1.

The public key of the P2P component instance a may be a node public key of the node instance a in the blockchain network, so that the P2P component instance a may use the public key as its own component identifier; alternatively, the digest of the public key may be identified as its own component. Of course, because each blockchain link point in a blockchain network typically corresponds to a different blockchain member, P2P component instance a may identify as its component identification the member of the blockchain member to which node instance a corresponds. For example, in a federation chain scenario, the P2P component instance a may use member identifiers, such as a member name, a member number, and a member public key, of a block chain member corresponding to the node instance a as its component identifier, which is not described again. It can be understood that the P2P component instances deployed by each node device in the blockchain network can implement the servitization of the communication capability of the own P2P in the above manner.

Further, after the above-mentioned servitization is completed, any P2P component instance may provide a unified call interface for other function instances in the node device where the P2P component instance is located, so that the other function instances call the P2P component instance through the call interface. For example, the call statement of the call interface of any P2P component instance may be:

P2PService p2p_service = ServiceLocator::Locate<P2PService>();

in fact, the calling interface may include a plurality of specific interfaces, such as a task group registration interface register group, a unicast interface SendMsg, a broadcast interface MulticastMsg, and a task group cancellation interface UnregisterGroup, and the specific usage of each interface may be seen in the following embodiments, which are not described herein for brevity.

After any functional component calls the P2P component instance, a logical internal link is established between the functional component and the P2P component instance (as shown by arrows between each functional component in the node device 1 and the P2P component instance a in fig. 6 and between each functional component in the node device 2 and the P2P component instance B), and the internal link between the service component and the P2P component instance is not recorded as a clientchannel, as shown by clientchannel _ a1 between the service instance a1 and the P2P component instance a in fig. 6, clientchannel _ Bn between the service instance Bn and the P2P component instance B, and so on. After the clientchannel is established (i.e. the service component acquires the calling interface), the service component can initiate a corresponding calling request to the P2P service component through the clientchannel. Of course, the P2P component instance may locally maintain the mapping relationship between the instance identifier (such as function number) of each service instance and the internal link identifier of the corresponding clientchannel, so as to directly query when subsequently creating the second mapping relationship, and shorten the creation duration of the mapping relationship.

In order to transmit blockchain messages to other service instances deployed in other node devices, the first service instance may initiate a task group registration request to the first P2P component instance before initiating a message sending request to the first P2P component instance, so that a task group including a P2P component instance deployed in a node device where at least one other service instance is located is established by the first P2P component instance. For example, the task group registration request may be generated by the first service instance based on the aforementioned task allocation event, which may include a target task defined in an intelligent contract executed by the first node instance. Still taking fig. 6 as an example, the node instance a may generate a task allocation event including the target task in the process of executing the intelligent contract, where the task allocation event may include each sub-task in the target task, and record an executing party of each sub-task, so that the service instance a1 may initiate the task group registration request to the P2P component instance a when the node instance a determines that the target task needs to be executed by at least one service instance deployed in the service instance a1 and at least one other node device together (that is, service instances in different node devices execute different sub-tasks with dependency relationships, respectively). The task group registration request may include a target task identifier of the target task, which is obtained by parsing the task allocation event.

Taking the call interface of the first P2P component instance as an example, the first service instance may call the task group registration interface of the first P2P component instance through the following call statement to establish a task group by the first P2P component instance:

P2PService::RegisterGroup(GroupId task_id);

the entry in the calling process includes the target task identifier taskid, that is, the identifier is used as a task group identifier assigned to the task group to be registered as the first service instance and is used for uniquely identifying the task group. It will be appreciated that the same P2P component instance may participate in multiple task groups simultaneously, and thus to avoid task group confusion, the task _ id described above needs to be globally unique with respect to the blockchain network.

In an embodiment, the target tasks included in the task allocation event may include privacy computation tasks, for example, the service instance B1 needs to obtain data to be encrypted from the service instance a1, or obtain a verification result of the service instance a1 that verifies the data to be encrypted, and the like. Database access tasks can also be included, for example, the service instance B1 needs to obtain a login account and a password of the database to be accessed from the service instance a1, or a verification result of the security of the database access link, and the like. Of course, the privacy computation task and the database access task may be included at the same time, or tasks related to specific services may also be included, and the description does not limit this.

As described above, the solution of the present specification may be applied to the blockchain subnet, and therefore the task allocation event may be an event generated by each node of the blockchain subnet, and the target task is a task defined by an intelligent contract deployed in the blockchain subnet. Therefore, after the target task is executed, each node device can submit the corresponding execution result to the blockchain main network through the P2P component instance, so as to store the execution result in the blockchain main network, thereby ensuring that the execution result of the target task is difficult to be tampered by means of the larger-scale blockchain main network, and realizing reliable storage of the execution result.

In the starting process of the blockchain nodes in the blockchain network, the node equipment starts the instances by executing codes corresponding to the instances. In fact, to ensure the normal operation of the blockchain nodes, the node device usually starts each P2P component instance and establishes a consensus link between each blockchain node, and then starts a service instance deployed by itself to participate in processing a specific service. Thus, in one embodiment, the first P2P component instance may create the first mapping relationship after establishing at least one consensus link with other P2P component instances, i.e., based on the component identifications of the other P2P component instances and the established consensus links. It is understood that the first P2P component instance may establish a common link with other P2P component instances, and therefore, to avoid link confusion, a common link identifier (channel _ id) of each established common link (hereinafter referred to as a channel) may be maintained locally, so that each common link may be uniquely characterized in the created second mapping relationship by using the common link identifier, that is, the channel _ id of each common link may be recorded in the first mapping relationship. Still taking the scenarios shown in fig. 4 and 6 as an example, the P2P component instance a may create a first mapping relationship corresponding to node B, node C, and node D in the blockchain primary network subnet0 in response to a task group registration request initiated by the service instance a1, as shown in table 1 below. Of course, the first mapping relationship may also be created by the first P2Pinstance in response to the received task group registration request, and is not described in detail herein.

In another embodiment, the first P2P component instance may create a third mapping relationship between the task group identifier and the corresponding clientchannel according to the target task identifier included in the task group registration request and the internal link clientchannel established between itself and the first service instance that initiated the request. As described above, since the internal link clientchannel may be pre-assigned with the corresponding internal link identifier clientchannel _ id, each internal link may be uniquely characterized by using the internal link identifier in the created third mapping relationship, that is, the clientchannel _ id of each internal link may be recorded in the third mapping relationship. Still taking the scenarios shown in fig. 4 and 6 as an example, the P2P component instance a may create a third mapping corresponding to service instance a1 in response to a task group registration request initiated by service instance a1, as shown in table 2 below. It can be seen that in the case that service instance a1 participates in executing a target task with task identification "0 xxxx 1", P2P component instance a establishes a task group with the identification as the task group identification. Where "0 xxxx 1" is the task group identification for business instance A1 participating in the task group.

For the mapping relationships shown in the above tables, it should be noted that the group _ id, the peer _ id, the channel, the clientchannel _ id, and the like in the tables are only exemplary. In the practice of the solution, the group _ id may be a number, a subnet identifier, or a specific hash value (e.g., MD5 value, SHA1 value, etc.); the peer _ id may be the public key, or an abstract of the public key, a node identity, or the like, or may be a number; the channel _ id may be a number, or a node public key or an identity of a node instance deployed in an opposite-end node device; the clientchannel _ id may be a number, or an instance identifier of each service instance, and is not described in detail again. It can be further understood that, because the same service instance may participate in multiple task groups at the same time, at least one task _ id (i.e., a specific value of a group _ id) corresponding to each of multiple clientchanneldid levels may be recorded in table 2. In response to a new task group registration request, the first P2P component instance may add a new peer _ id and its corresponding channel _ ids in table 1; a task _ id and a clientchanneld corresponding to the task _ id may also be newly added in table 2 (of course, a plurality of task _ ids and clientchannelds corresponding to the task _ ids may be newly added in response to a plurality of task group registration requests). In addition, since the consensus links between the node devices are established between the start service instances, the corresponding table entries may be extracted from the correspondence table between the pre-established consensus links and the identifiers of the P2P component instances of the correspondent node to construct the first mapping relationship.

In order to improve the query efficiency, the mapping relationship tables may be combined into one relationship table. Alternatively, the mapping relationship table may adopt other recording manners, the tables 1 to 2 are only logical relationships, and the specific storage manner is not limited in this specification. For example, the table 2 may be divided into two sub-tables, and one sub-table is stored in a manner that one group _ id corresponds to at least one clientchanneldid, so as to determine the clientchanneldid according to the group _ id; and the other sheet is stored according to a mode that one clientchanneld corresponds to at least one group _ id, so that the group _ id is determined according to the clientchanneldid, and further description is omitted.

In an embodiment, each node instance belonging to the block chain network may respectively obtain a target task corresponding to itself, and then the P2P component instances deployed in the node device where each node instance is located may respectively create the first mapping relationship and the second mapping relationship, so that the P2P component instances in the node devices where each service instance participating in execution of the same target task are located maintain the corresponding first mapping relationship and the second mapping relationship. For example, corresponding to table 3 above, P2P component instance B may locally maintain a mapping between the component identity of P2P component instance a and the consensus link between P2P and P2P component instances a and B, and also maintain a third mapping as shown in table 3 below.

Of course, if the task group identified by 0xxxx1 as the task group further includes service instance B2, table 3 may further include an entry corresponding to clientchannel _ B2 in 0xxxx 1; or, in a case that the service instance Bm further belongs to the task group whose task group identifier is 0xxxx1, table 3 may further include an entry that the clientchannel _ Bm corresponds to 0xxxx1, which is not described again.

After the task group registration is completed (that is, after the P2P component instances corresponding to the node devices participating in executing the target task in the blockchain network have completed creating the corresponding mapping relationships), the first P2P component instance may determine, in response to a message sending request initiated by the first service instance and carrying the target task identifier and the service data obtained by executing the first subtask, a second P2P component instance indicated by the second subtask, and send a blockchain message using a common identification link between itself and the second P2P component instance.

Upon receiving the messaging request, the first P2P component instance may construct a blockchain message from the request. For example, the target task identifier and the service data may be extracted from the message sending request, and then both of them are included in the constructed blockchain message, that is, the blockchain message with the following data structure is constructed:

(group_id, payload)

the service data may be plaintext data or encrypted ciphertext data, which is not limited in this specification.

In one embodiment, the first P2P component instance needs to ensure that the received messaging request is a request sent by a legitimate service instance, i.e., needs to determine whether the first service instance sending the messaging request is a member of a task group indicated by the target task identity (hereinafter referred to as the target task group). For example, the first P2P component instance may, after receiving the message sending request, query the target task group in the second mapping relationship between the locally maintained task group identifier and the client link, and then trigger the second P2P component instance that determines the target task identifier to indicate if the query is received (i.e., indicating that the target task identifier is recorded in the second mapping relationship). Of course, in the case of no query, it may be determined that the sender of the message (and the first service instance) is illegitimate, so that the message sending request may be ignored or discarded, or a record or alarm may be recorded. Therefore, the subsequent operation can be executed under the condition that the initiator of the message sending request is legal, thereby not only ensuring the safety of the block chain network, but also avoiding the invalid operation. Of course, this verification step may be performed before or after the above-described blockchain message is constructed.

In one embodiment, the first P2P component instance may transmit the block chain message in a unicast or multicast manner. In the unicast mode, the message sending request initiated by the first P2P component instance only contains a second component identifier, which indicates that the blockchain message only needs to be transmitted to a second P2P component instance indicated by the identifier; in the multicast mode, the message sending request includes a plurality of second component identifiers, indicating that the blockchain message needs to be transmitted to a plurality of second P2P component instances indicated by the plurality of identifiers. Thus, in the case where at least one second component identification is included in the message transmission request, the first P2P component instance may determine the P2P component instance respectively indicated by the at least one second component identification as the second P2P component instance.

After determining the second P2P component instance, the first P2P component instance may further determine a target consensus link corresponding to the second P2P component instance according to a first mapping relationship between the locally maintained component identifier and the consensus link, so as to send a blockchain message to the second P2P component instance through the target consensus link, which is described in conjunction with the scenario shown in fig. 6.

The service instance a1 may call the unicast interface SendMsg to implement unicast transmission of the blockchain message by:

P2PService::SendMsg(GroupId task_id, PeerId peer_id, Bytes payload);

wherein, the parameter task _ id is a target task identifier, the peer _ id is a component identifier of the second P2P component instance, and the payload is service data. At this time, the first P2P component instance may determine the P2P component instance characterized by the peer _ id as the second P2P component instance, so that the channel _ id corresponding to the task _ id may be queried through the first mapping relationship, and send the blockchain message to the opposite end (i.e., the second P2P component instance) using the common link corresponding to the channel _ id. If the peer _ id is pubkey _ B, the P2P component instance a may find its corresponding channel _ B through table 1, and then send a blockchain message to the P2P component instance B through its indicated channel.

Service instance a1 may invoke multicast interface MulticastMsg to implement multicast transmission of blockchain messages by:

P2PService::MulticastMsg(GroupId task_id, Set<Peer> peer_list ,Bytes payload);

the parameter task _ id is a target task identifier, a plurality of peer _ ids included in the component identifier list peer _ list are component identifiers of a plurality of second P2P component instances, and payload is service data. At this time, the first P2P component instance may determine, as the second P2P component instance, each P2P component instance represented by each peer _ id in the peer _ list, so as to query, through the second mapping relationship shown in table 1, a channel _ id corresponding to each peer _ id, and send the blockchain message to the opposite end (i.e., each second P2P component instance) by using the common identification link corresponding to each channel _ id. As in the case where the peer _ ids included in the peer _ list are pubkey _ B and pubkey _ C, respectively, the P2P component instance a may find its corresponding channel _ B and channel _ C through table 1, so as to send the blockchain messages to the P2P component instance B and the P2P component instance C through the respectively indicated channels.

Step 506, the second P2P component instance receives the blockchain message, and sends the blockchain message to the second service instance indicated by the target task identifier on the second node device where the second P2P component instance is located, so that the second service instance executes the second subtask by using the service data.

As described above, for any of the above message transmission manners, the first P2P component instance constructs a blockchain message with the same data structure, so that after receiving the blockchain message, the second P2P component instance can determine the second service instance specified by the target task identifier contained therein, and then send the blockchain message to the determined second service instance. Of course, the second P2P component instance may also parse the received blockchain message and send only the service data obtained by parsing to the second service instance, so as to reduce the communication data volume of the client link and reduce the data processing pressure of the service instance.

In an embodiment, a client link is established between each P2P component instance deployed on each node device in the blockchain system and a service instance on the node device where the P2P component instance is located, and the second P2P component instance may determine, according to a third mapping relationship between a locally maintained task group identifier and the client link, a second client link corresponding to the task group identifier, where the determined second client link is connected to the second P2P component instance and the second service instance on the second node device where the second P2P component instance is located; in turn, the second P2P component instance may send the blockchain message to the second service instance over the second client link, thereby completing the transmission of the blockchain message. Still taking the scenario shown in fig. 6 as an example, when the task _ id is 0xxxx1, the P2P component instance B may determine that the corresponding clientchannel _ id is clientchannel _ B1 according to the fourth mapping relationship shown in table 3, that is, it indicates that the service instance B1 is a service instance belonging to the task group of 0xxxx1, so that the P2P component instance B may send the blockchain message to the service instance B1 through the client link characterized by clientchannel _ B1.

In an embodiment, the blockchain message may further include a component identifier of the first P2P component instance, and the data structure of the blockchain message may be:

(self_peer_id, group_id, payload)

it will be appreciated that in the transmission of a blockchain message over a consensus link, the first P2P component instance is the sender and the second P2P component instance is the receiver. The self _ peer _ id is a component identifier of the first P2P component instance (i.e., a component identifier of the sender), and the group _ id and payload are a target task identifier and service data carried in the message sending request, respectively.

At this time, the second P2P component instance may perform validity verification on the first P2P component instance according to the first component identifier, and send the blockchain message to the second service instance again when the verification result indicates that the first P2P component instance is valid. The validity verification may include querying the peer _ id column of the first mapping relationship maintained locally for the self _ peer _ id, and if the query indicates that the first P2P component instance is valid, otherwise, the first P2P component instance is illegal.

After the second service instance acquires the service data, the corresponding second subtask can be immediately executed; alternatively, to avoid invalid execution, a determination may be made first, for example, in the case that it is determined that the second subtask is allocated to the member of the blockchain to which the second node device belongs, the second subtask is executed.

Further, when the target task is generated by the first node instance and the second node instance through an intelligent contract, the task allocation event may further record an execution sequence of each sub-task in the target task, so that the second service instance may determine, according to the execution sequence, whether a third sub-task remains to be executed after the second sub-task. Correspondingly, if the second service instance determines that the second subtask is the last subtask in the execution sequence (i.e., the third subtask does not exist), a task Callback (Callback) method in the intelligent contract may be called to return the execution result of the second subtask to the intelligent contract, so that the intelligent contract performs subsequent processing according to the execution result. Otherwise, if the second service instance determines that the second subtask is not the last subtask indicated by the execution sequence, a third subtask located after the second subtask in the execution sequence is determined, and the execution result of the second subtask is provided to the third service instance for executing the third subtask. The third service instance may be a service instance deployed in the second node device, so that the second service instance may send the execution result to the third service instance through an internal bus of the second node device; alternatively, the third service instance may also be a service instance deployed in a location different from the first node device and the second node device, so that the component identifier of the third P2P component in the third node device may be determined according to the task allocation event monitored by the third service instance, and then, by using a method similar to that in the foregoing embodiment, the block chain message including the execution result is sent to the third P2P component instance by using the common identification link between the second P2P component instance and the third P2P component instance, and is further sent to the third service instance for executing the third sub-task, which is not described in detail again.

In an embodiment, after the block chain message is transmitted, or all messages corresponding to the target task are transmitted, or the target task is completed, the task group established in the foregoing process may be logged out accordingly. For example, any service instance belonging to a task group, or initiating a task group registration request to register a service instance of the task group, etc., may invoke the task group logout interface UnregisterGroup to logout the task group through the following statements:

P2PService::UnregisterGroup(GroupId task_id);

wherein, the task _ id is a task group identifier of a task group to be logged off. After the statement is executed, the corresponding P2P component instance deletes the mapping associated with the task group, thereby logging out the task group. Therefore, the task group can be registered as the target task starts to execute, and can be logged out after the target task finishes executing, so that the task group has the same life cycle as the target task. Of course, the task group may also be established according to the aforementioned intelligent contract instead of the target task, and the specific process is not described in detail.

It can be seen that, by registering the task group, a plurality of blockchain nodes participating in executing a target task together in a blockchain network is equivalent to constructing a logically new blockchain network based on an original blockchain network, where the original blockchain network is equivalent to a logically blockchain main network, and the new blockchain network is equivalent to a logically blockchain sub-network. Further, in the case where the block chain network is a block chain subnet (two-tier network) managed by a block chain master network (one-tier network), the new block chain network corresponding to the task group corresponds to a third-tier network constructed on the block chain subnet, and the number of tiers of the block chain network is not limited in this specification. Therefore, the above scheme can complete the execution process of each subtask in the target task by constructing a higher layer of block chain network on the basis of a multi-layer block chain network. In addition, as can be seen from the process of establishing, using and cancelling the task group, the task group can be established according to the target task executed by the blockchain node, and is unrelated to the structure of the original blockchain network (irrespective of the structure of the blockchain subnet or the blockchain main network), so that the service requirement can be more flexibly met, and the realization of more complex and variable service functions by the blockchain is facilitated.

Through the embodiment, when different service instances in a plurality of node devices need to execute different subtasks with dependency relationships in a target task together, a block chain message can be created according to an execution result (namely, service data) of the previous subtask, and the block chain message is transmitted to an executing party of the next subtask by using a common identification link which is pre-established between P2P component instances deployed in the node devices where block chain link points in the same block chain network are located, namely, the service data is transmitted by multiplexing the common identification link in the block chain network. Therefore, a special service link does not need to be additionally established, the complexity of the block chain network is effectively reduced, the block chain message containing service data is transmitted by multiplexing the consensus link, so that the consensus link has the consensus function and can realize part of service functions, the consensus link is recycled, the overall utilization rate of the consensus link serving as the infrastructure of the block chain network is improved, and the management, operation and maintenance costs of the block chain network are reduced.

Corresponding to the above embodiment, the present specification further provides another method for transmitting a blockchain message, which is applied to a first service instance deployed in a first node device, where a P2P component instance, a service instance, and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the first node device is located, and a consensus link for the node instances to participate in consensus is established between P2P component instances on different node devices; as shown in fig. 7, the method may include:

step 702, a first service instance receives and executes a first subtask contained in a target task generated by a first node instance on first node equipment where the first service instance is located;

step 704, the first service instance initiates a message sending request to a first P2P component instance on the first node device according to the target task identifier of the target task, the service data obtained by executing the first subtask, and a second subtask dependent on the first subtask in the target task, so that the first P2P component instance determines a second P2P component instance indicated by the second subtask in response to the message sending request, and sends a blockchain message through a target consensus link between the first P2P component instance and the second P2P component instance, wherein the blockchain message includes the target task identifier and the service data; and sending the received block chain message to a second service instance indicated by the target task identifier on a second node device where the second P2P component instance is located, and executing a second subtask by the second service instance by using the service data.

As described above, the receiving, by the first service instance, the first subtask included in the target task generated by the first node instance on the first node device where the first service instance is located includes: under the condition that a first service instance monitors a task allocation event generated by executing an intelligent contract by a first node instance on first node equipment where the first service instance is located, acquiring a first subtask contained in a target task from the task allocation event;

the method further comprises the following steps: and the first service instance acquires the target task identifier from the task allocation event and determines a second subtask which depends on the first subtask in the target task from the task allocation event.

Corresponding to the above embodiments, the present specification further provides another method for transmitting a blockchain message, which is applied to a first P2P component instance deployed in a first node device, where a P2P component instance, a service instance, and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the first node device is located, and a consensus link for the node instances to participate in consensus is established between P2P component instances on different node devices; as shown in fig. 8, the method may include:

step 802, a first P2P component instance receives a message sending request initiated by a first service instance on a first node device where the first P2P component instance is located, where the message sending request is initiated to the first P2P component instance according to a target task identifier of a target task, service data obtained by executing the first subtask, and a second subtask dependent on the first subtask in the target task after the first service instance receives and executes a first subtask included in the target task generated by the first node instance on the first node device;

step 804, the first P2P component instance determines a second P2P component instance indicated by the second subtask in response to the message sending request, and sends a blockchain message containing the target task identifier and the service data through a target consensus link between the first P2P component instance and the second P2P component instance, so that the second P2P component instance sends the received blockchain message to a second service instance indicated by the target task identifier on a second node device where the second P2P component instance is located, and the second service instance executes the second subtask by using the service data.

As previously described, the first P2P component instance determines a target consensus link, including:

the first P2P component instance determines a target consensus link corresponding to the second P2P component instance based on a first mapping between the locally maintained component identification and the consensus link.

As described above, a client link is established between each P2P component instance deployed on each node device in the blockchain system and a service instance on the node device where the client link is located, and the method further includes:

and after the first P2P component instance receives the message sending request, under the condition that the second mapping relation between the locally maintained task identifier and the client link is determined to record the target task identifier, triggering and determining a second P2P component instance.

Corresponding to the above embodiment, the present specification further provides another method for transmitting a blockchain message, which is applied to a second P2P component instance deployed in a second node device, where a P2P component instance, a service instance, and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the second node device is located, and a consensus link for the node instances to participate in consensus is established between P2P component instances on different node devices; as shown in fig. 9, the method may include:

step 902, the second P2P component instance receives a blockchain message sent by the first P2P component instance on the first node device, where the blockchain message is sent by the first P2P component through a target consensus link between itself and the second P2P component instance after determining the second P2P component instance indicated by the second subtask in response to a message sending request, where the message sending request is initiated by the first service instance on the first node device after receiving and executing a first subtask included in a target task generated by the first node instance on the first node device, according to a target task identifier of the target task, service data obtained by executing the first subtask, and a second subtask of the target task, which is dependent on the first subtask;

step 904, the second P2P component instance sends the blockchain message to the second service instance indicated by the target task identifier on the second node device where the second P2P component instance is located, so that the second service instance executes the second subtask by using the service data.

As described above, a client link is established between each P2P component instance deployed on each node device in the blockchain system and the service instance on the node device where the second P2P component instance is located, and the sending of the blockchain message to the second service instance indicated by the target task identifier on the second node device where the second P2P component instance is located includes:

the second P2P component instance determines a second client link corresponding to the target task identifier according to a third mapping relation between the locally maintained task identifier and the client link, wherein the second client link connects the second P2P component instance and a second service instance on a second node device where the second P2P component instance is located;

the second P2P component instance sends the blockchain message to the second service instance over the second client link.

Fig. 10 is a block diagram of a system for transmitting a blockchain message according to an exemplary embodiment. Referring to fig. 10, the system includes a first node device 1001 and a second node device 1002 in a blockchain system 1000, where each node device has a P2P component instance, a service instance, and a node instance belonging to the same blockchain network deployed thereon, and a consensus link for the node instances to participate in consensus is established between P2P component instances on different node devices; wherein:

a first service instance in a first node device 1001 receives and executes a first subtask included in a target task generated by the first node instance on the first node device 1001, and initiates a message sending request to a first P2P component instance on the first node device 1001 according to a target task identifier of the target task, service data obtained by executing the first subtask, and a second subtask dependent on the first subtask in the target task;

the first P2P component instance in the first node device 1001, in response to the message sending request, determining a second P2P component instance indicated by the second subtask, and sending a blockchain message over a target consensus link with the second P2P component instance, the blockchain message including the target task identity and the traffic data;

the second P2P component instance in the second node device 1002 receives the blockchain message and sends the blockchain message to the second service instance indicated by the target task identifier on the second node device 1002, so that the second service instance executes the second subtask using the service data

Alternatively to this, the first and second parts may,

the first service instance receives a first subtask included in a target task generated by a first node instance on the first node device 1001, and includes: under the condition that a first service instance monitors a task allocation event generated by a first node instance on first node equipment 1001 executing an intelligent contract, acquiring a first subtask contained in a target task from the task allocation event;

Alternatively to this, the first and second parts may,

the target task corresponds to any task node in a workflow defined in the intelligent contract; or,

the target task corresponds to a workflow defined in the intelligent contract, and the first subtask and the second subtask respectively correspond to adjacent task nodes having a serial relationship in the workflow.

Optionally, the task allocation event records an execution sequence of each sub task in the target task, and the method further includes:

if the second business instance determines that the second subtask is the last subtask in the execution sequence, a task callback method in the intelligent contract is called to return the execution result of the second subtask to the intelligent contract;

and if the second service instance determines that the second subtask is not the last subtask indicated by the execution sequence, determining a third subtask located after the second subtask in the execution sequence, and providing an execution result of the second subtask to the third service instance for executing the third subtask.

Optionally, the first service instance executes a first subtask, which includes:

the first service instance executes the first subtask upon determining that the first subtask is assigned to a member of the blockchain to which the first node device 1001 belongs.

Optionally, the message sending request includes at least one second component identifier for executing a second subtask, and the determining, by the first P2P component instance, of the second P2P component instance indicated by the second subtask in response to the message sending request includes:

the first P2P component instance determines the at least one P2P component instance indicated by the at least one second component identification as the second P2P component instance.

Optionally, the determining, by the first P2P component instance, the target consensus link includes:

Optionally, the first P2P component instance creates the first mapping relationship by:

after the first P2P component instance establishes at least one consensus link with other P2P component instances, a first mapping relation is created according to the component identifications of the other P2P component instances and the established consensus links.

Optionally, the component identifier of any P2P component instance deployed in any node device includes any of the following:

a node public key of a node instance deployed in any node device in the block chain network to which the node instance belongs;

a summary of a node public key of a node instance deployed in any node device in the block chain network to which the node instance belongs;

and the member identification of the member of the block chain corresponding to the node instance deployed in any node device.

Optionally, a client link is established between each P2P component instance deployed on each node device in the blockchain system 1000 and a service instance on the node device where the client link is located, and the method further includes:

Optionally, the first P2P component instance creates the second mapping relationship by:

when receiving a task group registration request sent by any service instance deployed in the first node device 1001, the first P2P component instance creates a second mapping relationship according to a task identifier carried in the task group registration request and a client link between itself and the any service instance.

Optionally, a client link is established between each P2P component instance deployed on each node device in the blockchain system 1000 and the service instance on the node device where the second P2P component instance is located, and the sending of the blockchain message to the second service instance indicated by the target task identifier on the second node device 1002 includes:

the second P2P component instance determines a second client link corresponding to the target task identifier according to a third mapping relationship between the locally maintained task identifier and the client link, where the second client link connects the second P2P component instance and a second service instance on the second node device 1002 where the second P2P component instance is located;

Optionally, the blockchain message further includes a first component identifier of a first P2P component instance, and the second P2P component instance sends the blockchain message to the target service instance, where the sending includes:

and the second P2P component instance sends the blockchain message to a second service instance when the verification result obtained by verifying the legality of the first P2P component instance according to the first component identification shows that the first P2P component instance is legal.

Optionally, each node device in the block chain system 1000 is deployed with at least one node of a block chain network, the block chain networks related to the block chain system 1000 form a tree structure with a block chain main network as a root node and each block chain sub-network as other nodes, and any block chain sub-network is managed by the block chain network corresponding to its parent node.

Alternatively to this, the first and second parts may,

in the case that the target task is included in a task allocation event generated by the execution of the intelligent contract by the first node instance, the target task is identified as: contract identification of the intelligent contract; or,

when the same blockchain network to which the first node instance and the second node instance belong is a blockchain subnet managed by a blockchain main network, the target task identifier is as follows: a subnet identification of the blockchain subnet.

Optionally, the target task includes a privacy computation task and/or a database access task.

Optionally, the consensus link is established pairwise between P2P component instances deployed in node devices where node instances belonging to the block chain network are respectively located.

Optionally, any service instance deployed in any node device is in a different process from other instances.

Fig. 11 is a schematic diagram of an apparatus according to an exemplary embodiment. Referring to fig. 11, at the hardware level, the apparatus includes a processor 1102, an internal bus 1104, a network interface 1106, a memory 1108, and a non-volatile storage 1110, although other hardware required for services may be included. One or more embodiments of the present description can be implemented in software, such as by the processor 1102 reading corresponding computer programs from the non-volatile storage 1110 into the memory 1108 and then executing. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Fig. 12 is a block diagram of an apparatus for transmitting a block chain message according to an exemplary embodiment. Referring to fig. 12, the apparatus may also be applied to the device shown in fig. 11 to implement the technical solution of the present specification. The device for transmitting the blockchain message is applied to, and the device may include:

a subtask execution unit 1201, configured to enable the first service instance to receive and execute a first subtask included in a target task generated by a first node instance on a first node device where the first service instance is located;

a request initiating unit 1202, configured to enable a first service instance to initiate a message sending request to a first P2P component instance on a first node device according to a target task identifier of the target task, service data obtained by executing the first subtask, and a second subtask dependent on the first subtask in the target task, so that the first P2P component instance determines, in response to the message sending request, a second P2P component instance indicated by the second subtask, and sends a blockchain message through a target consensus link with the second P2P component instance, where the blockchain message includes the target task identifier and the service data; and sending the received block chain message to a second service instance indicated by the target task identifier on a second node device where the second P2P component instance is located, and executing a second subtask by the second service instance by using the service data.

Optionally, the subtask execution unit 1201 is further configured to: under the condition that a first service instance monitors a task allocation event generated by executing an intelligent contract by a first node instance on first node equipment where the first service instance is located, acquiring a first subtask contained in a target task from the task allocation event;

the apparatus further includes an identification acquisition unit 1203: and enabling the first service instance to acquire the target task identifier from the task allocation event, and determining a second subtask which depends on the first subtask in the target task from the task allocation event.

Fig. 13 is a block diagram of another apparatus for transmitting a blockchain message according to an exemplary embodiment. Referring to fig. 13, the apparatus may also be applied to the device shown in fig. 11 to implement the technical solution of the present specification. The device for transmitting the blockchain message is applied to, and the device may include:

a request receiving unit 1301, configured to enable a first P2P component instance to receive a message sending request initiated by a first service instance on a first node device where the first P2P component instance is located, where the message sending request is initiated to the first P2P component instance according to a target task identifier of a target task, service data obtained by executing the first subtask, and a second subtask, which is dependent on the first subtask, in the target task after the first service instance receives and executes a first subtask included in the target task generated by the first node instance on the first node device;

the message sending unit 1302, causes the first P2P component instance to determine, in response to the message sending request, a second P2P component instance indicated by the second subtask, and send, through a target consensus link with the second P2P component instance, a blockchain message including the target task identifier and the service data, so that the second P2P component instance sends the received blockchain message to a second service instance indicated by the target task identifier on a second node device where the second P2P component instance is located, and the second service instance executes the second subtask by using the service data.

Optionally, the message sending unit 1302 is further configured to:

the first P2P component instance is caused to determine a target consensus link corresponding to the second P2P component instance according to a first mapping between the locally maintained component identification and the consensus link.

Optionally, the message sending unit 1302 is further configured to:

Optionally, a client link is established between each P2P component instance deployed on each node device in the blockchain system and a service instance on the node device where the client link is located, where the apparatus further includes:

the checking unit 1303, after receiving the message sending request, causes the first P2P component instance to trigger and determine a second P2P component instance when determining that the target task identifier is recorded in the second mapping relationship between the locally maintained task identifier and the client link.

Optionally, the message sending unit 1302 is further configured to:

and under the condition that a task group registration request sent by any service instance deployed in the first node equipment is received, the first P2P component instance creates a second mapping relation according to the task identifier carried in the task group registration request and a client link between the first P2P component instance and the any service instance.

Fig. 14 is a block diagram of an apparatus for transmitting a blockchain message according to an exemplary embodiment. Referring to fig. 14, the apparatus may also be applied to the device shown in fig. 11 to implement the technical solution of the present specification. The device for transmitting the blockchain message is applied to, and the device may include:

a message receiving unit 1401, configured to enable the second P2P component instance to receive a blockchain message sent by the first P2P component instance on the first node device, where the blockchain message is sent by the first P2P component through a target consensus link between itself and the second P2P component instance after determining the second P2P component instance indicated by the second subtask in response to a message sending request, where the message sending request is initiated by the first service instance on the first node device after receiving and executing a first subtask included in a target task generated by the first node instance on the first node device, according to a target task identifier of the target task, service data obtained by executing the first subtask, and a second subtask dependent on the first subtask in the target task;

the message sending unit 1402 enables the second P2P component instance to send the blockchain message to the second service instance indicated by the target task identifier on the second node device where the second P2P component instance is located, so that the second service instance executes the second subtask by using the service data.

Optionally, a client link is established between each P2P component instance deployed on each node device in the blockchain system and a service instance on the node device where the client link is located, and the message sending unit 1402 is further configured to:

enabling the second P2P component instance to determine a second client link corresponding to the target task identifier according to a third mapping relationship between the locally maintained task identifier and the client link, wherein the second client link connects the second P2P component instance and a second service instance on a second node device where the second P2P component instance is located;

causing the second P2P component instance to send the blockchain message to the second service instance over the second client link.

Optionally, the blockchain message further includes a first component identifier of the first P2P component instance, and the message sending unit 1402 is further configured to:

and enabling the second P2P component instance to send the blockchain message to a second service instance when the verification result obtained by verifying the legality of the first P2P component instance according to the first component identification shows that the first P2P component instance is legal.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A method for transmitting blockchain messages is applied to a blockchain system comprising a plurality of node devices, wherein each node device is provided with a P2P component instance, a service instance and a node instance belonging to the same blockchain network, and a consensus link for the node instances to participate in consensus is established between the P2P component instances on different node devices, and the method comprises the following steps:

2. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,

the method for receiving the first subtask contained in the target task generated by the first node instance on the first node device where the first service instance is located by the first service instance comprises the following steps: under the condition that a first service instance monitors a task allocation event generated by executing an intelligent contract by a first node instance on first node equipment where the first service instance is located, acquiring a first subtask contained in a target task from the task allocation event;

3. The method of claim 2, wherein the first and second light sources are selected from the group consisting of,

4. The method of claim 2, wherein the task allocation event records an execution sequence of each sub-task in the target task, and the method further comprises:

5. The method of claim 1, the first service instance performing a first subtask, comprising:

the first service instance executes the first subtask upon determining that the first subtask is assigned to a member of the blockchain to which the first node device belongs.

6. The method of claim 1, the messaging request including at least one second component identification for performing a second subtask, the first P2P component instance determining, in response to the messaging request, a second P2P component instance indicated by the second subtask comprising:

7. The method of claim 1, the first P2P component instance determining a target consensus link, comprising:

8. The method of claim 7, the first P2P component instance creating the first mapping by:

9. The method of any of claims 6-8, the component identification of any P2P component instance deployed in any node device, comprising any of:

10. The method of claim 1, wherein each P2P component instance deployed on each node device in the blockchain system establishes a client link with a service instance on a node device where the client instance is located, and the method further comprises:

11. The method of claim 10, the first P2P component instance creating the second mapping by:

and under the condition that a first P2P component instance receives a task group registration request sent by any service instance deployed in first node equipment, creating a second mapping relation according to a task identifier carried in the task group registration request and a client link between the first P2P component instance and the any service instance.

12. The method of claim 1, wherein each P2P component instance deployed on each node device in the blockchain system establishes a client link with a service instance on its own node device, and the second P2P component instance sends the blockchain message to a second service instance indicated by the target task identifier on its own second node device, including:

13. The method of claim 1, the blockchain message further including a first component identification of a first P2P component instance, the second P2P component instance sending the blockchain message to a target service instance, comprising:

14. The method according to claim 1, wherein at least one node of the blockchain network is deployed on each node device in the blockchain system, the blockchain networks involved in the blockchain system form a tree structure with a blockchain main network as a root node and each blockchain sub-network as other nodes, and any blockchain sub-network is managed by the blockchain network corresponding to its parent node.

15. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,

16. The method of claim 1, the target tasks comprising privacy computation tasks and/or database access tasks.

17. The method according to claim 1, wherein the consensus link is established pairwise between P2P component instances deployed in node devices where the node instances belonging to the blockchain network are respectively located.

18. The method of claim 1, wherein any service instance deployed in any node device is in a different process than other instances.

19. A method for transmitting blockchain messages is applied to a first service instance deployed in a first node device, a P2P component instance, a service instance and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the first node device is located, and a consensus link for the node instances to participate in consensus is established between the P2P component instances on different node devices, and the method comprises the following steps:

20. The method of claim 19, wherein the first and second portions are selected from the group consisting of,

the first service instance receives a first subtask contained in a target task generated by a first node instance on first node equipment where the first service instance is located, and the first subtask comprises the following steps: under the condition that a first service instance monitors a task allocation event generated by executing an intelligent contract by a first node instance on first node equipment where the first service instance is located, acquiring a first subtask contained in a target task from the task allocation event;

21. A method for transmitting blockchain messages is applied to a first P2P component instance deployed in a first node device, wherein a P2P component instance, a service instance and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the first node device is located, and a common identification link for the node instance to participate in common identification is established between the P2P component instances on different node devices, and the method comprises the following steps:

22. The method of claim 21, the first P2P component instance determining the target consensus link, comprising:

23. The method of claim 21, wherein each P2P component instance deployed on each node device in the blockchain system establishes a client link with a service instance on a node device where the client instance is located, and the method further comprises:

24. A transmission method of block chain message is applied to a second P2P component instance deployed in a second node device, a P2P component instance, a service instance and a node instance belonging to the same block chain network are deployed on each node device in a block chain system where the second node device is located, and a common identification link for the node instance to participate in common identification is established between the P2P component instances on different node devices, the method comprises the following steps:

25. The method of claim 24, wherein each P2P component instance deployed on each node device in the blockchain system establishes a client link with a service instance on its own node device, and the second P2P component instance sends the blockchain message to a second service instance indicated by the target task identifier on its own second node device, including:

26. A transmission system of blockchain messages comprises a first node device and a second node device in a blockchain system, wherein each node device is provided with a P2P component instance, a service instance and a node instance belonging to the same blockchain network, and a consensus link for the node instances to participate in consensus is established between the P2P component instances on different node devices; wherein:

27. A transmission device of blockchain messages is applied to a first service instance deployed in a first node device, a P2P component instance, a service instance and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the first node device is located, and a consensus link for the node instances to participate in consensus is established between the P2P component instances on different node devices, the device comprises:

28. A transmission device of blockchain messages is applied to a first P2P component instance deployed in a first node device, a P2P component instance, a service instance and a node instance belonging to the same blockchain network are deployed on each node device in a blockchain system where the first node device is located, and a consensus link for the node instance to participate in consensus is established between the P2P component instances on different node devices, the device comprises:

29. A transmission device of block chain message is applied to a second P2P component instance deployed in a second node device, a P2P component instance, a service instance and a node instance belonging to the same block chain network are deployed on each node device in a block chain system where the second node device is located, and a common identification link for the node instance to participate in common identification is established between the P2P component instances on different node devices, the device comprises:

30. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-25 by executing the executable instructions.

31. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 25.