CN113067902B

CN113067902B - Block chain message transmission method and device

Info

Publication number: CN113067902B
Application number: CN202110611562.XA
Authority: CN
Inventors: 赵博然
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-06-02
Filing date: 2021-06-02
Publication date: 2021-07-30
Anticipated expiration: 2041-06-02
Also published as: CN113067902A

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 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 among the P2P component instances on different node devices, and the method comprises the following steps: 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, determines a second P2P component instance indicated by 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 contains a target session group identifier and service data carried by the message sending request; the second P2P component instance receives the blockchain message and sends the blockchain message to a second service instance specified by the target talkgroup identity on a second node device where it is located.

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, 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 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, determines a second P2P component instance indicated by 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 a target session group identifier and service data carried by the message sending request;

and the second P2P component instance receives the block chain message and sends the block chain message to a second service instance which is specified by the target session group identification and is positioned on a second node device.

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 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 instance to participate in consensus is established between P2P component instances on different node devices, the method includes:

the first P2P component instance receives a message sending request initiated by a first service instance on a first node device, and determines a second P2P component instance indicated by the message sending request;

and 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 a target session group identifier and service data carried by the message sending request, and the target session group identifier is used for designating the second service instance deployed in the second node equipment as a receiver of the blockchain message.

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 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, and the method includes:

the second P2P component instance receives a blockchain message sent by the first P2P component instance deployed in the first node device through a target consensus link between the first P2P component instance and the second P2P component instance, wherein the blockchain message comprises a target session group identification and service data;

the second P2P component instance determines that the target talkgroup identifies the specified second service instance deployed in the second node device and sends the blockchain message to the second service instance.

According to a fourth aspect of one or more embodiments of the present specification, there is provided an apparatus for transmitting a blockchain message, which is applied to a blockchain system including a plurality of node devices, each node device having 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 being established between P2P component instances on different node devices, the apparatus including:

a message sending 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, determine a second P2P component instance indicated by the message sending request, and send a block chain message through a target consensus link between the second P2P component instance and the second P2P component instance, where the block chain message includes a target session group identifier and service data carried in the message sending request;

and the message receiving unit enables the second P2P component instance to receive the blockchain message and send the blockchain message to a second service instance specified by the target session group identifier on a second node device where the second service instance is located.

According to a fifth aspect of one or more embodiments of the present specification, there is provided a device 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 instance to participate in consensus is established between P2P component instances on different node devices, the device including:

a request receiving unit, which enables the first P2P component instance to receive a message sending request initiated by a first service instance on a first node device, and determines a second P2P component instance indicated by the message sending request;

and the message sending unit is used for enabling the first P2P component instance to send 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 a target session group identifier and service data carried by the message sending request, and the target session group identifier is used for designating the second service instance deployed in the second node equipment as a receiver of the blockchain message.

According to a sixth 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 includes:

a message receiving unit, configured to enable a second P2P component instance to receive a blockchain message sent by a first P2P component instance deployed in a first node device through a target consensus link between the first P2P component instance and a second P2P component instance, where the blockchain message includes a target session group identifier and service data;

and the message sending unit enables the second P2P component instance to determine the second service instance which is allocated in the second node device and is specified by the target session group identifier, and sends the blockchain message to the second service instance.

According to a seventh aspect of one or more embodiments of the present specification, 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 or third aspect by executing the executable instructions.

According to an eighth aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first, second or third 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 blockchain 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 schematic structural diagram of an apparatus according to an exemplary embodiment.

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

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

Fig. 12 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 can be divided into processes for sequentially executing a plurality of contract tasks (i.e. executing each contract task in sequence), so that a plurality of contract tasks 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 contract task transmits a corresponding execution result (i.e. service data) to the node device executing the next contract task, so as 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 service data is transmitted by multiplexing the consensus link in the blockchain 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 is transmitted by multiplexing the consensus link, so that the consensus link has the consensus function and can realize part of 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, and the management and operation and maintenance costs of the block chain network are reduced. 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 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, determines a second P2P component instance indicated by 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, where the blockchain message includes a target session group identifier and service data carried by the message sending request.

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. Moreover, the blockchain message referred to in this specification is not a blockchain message to be identified in the process of identifying together, that is, the service data in the blockchain message referred to in this specification is not the data to be identified included in the blockchain message identified by the identifying-together component instance, and the data is used for the blockchain service implemented by the node instance, not only for implementing the identifying together, which is described herein.

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 the block link point instance belonging to a certain block chain network on the intelligent contract deployed in the block chain network), and the number of block link point instances deployed in the node device is not limited by the present disclosure.

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, a message sending request initiated by a certain service instance may indicate that any P2P component instance in the blockchain network serves as a second P2P component instance (i.e., a P2P component instance deployed in a node device where the second service instance serving as a receiver of the blockchain message is located), so that direct transmission of the blockchain message can be achieved between any two P2P component instances in the blockchain network, and the blockchain message does not need to be forwarded by an intermediary party, and therefore routing information in the blockchain network does not need to be maintained, which is helpful for achieving fast transmission of the blockchain message and light weight of the blockchain nodes. 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.

Or, the blockchain network may also be a non-fully-connected structure, that is, a consensus link is established between P2P component instances respectively deployed in some node devices in the blockchain network, and at this time, a message sending request initiated by a certain service instance in a certain node device may indicate, as a second P2P component instance, a certain P2P component instance in the blockchain network that has a consensus link established with the P2P component instance deployed by the node device, so that blockchain messages can be transmitted between blockchain nodes in the blockchain network that have a consensus link 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 initiates a message sending request to a P2P component instance a, where the message sending request carries a target session group identifier and service data to be transmitted, so that after the P2P component instance a receives the request, a second P2P component instance indicated by the request is determined, and then a block chain message containing the target session group identifier and the service data, which is generated in response to the message sending request, is sent to the second P2P component instance through a consensus link between itself and the second P2P component instance.

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 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 invoking interface may include a plurality of specific interfaces, such as a session group registration interface register group, a unicast interface SendMsg, a broadcast interface MulticastMsg, a multicast interface BroadcastMsg, and a session group deregistration interface unregister group, and the specific usage of each interface may be seen in the following embodiments, which will not be described herein again.

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 can 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 for subsequent query.

To transmit blockchain messages to other service instances deployed in other node devices, the first service instance may initiate a session group registration request with the first P2P component instance before initiating a message send request with the first P2P component instance, such that a session group is established by the first P2P component instance that includes a P2P component instance deployed in a node device where at least one other service instance is located. For example, the session group registration request may be generated by the first service instance based on a task allocation event that may include a contract task defined in an intelligent contract executed by the first node instance. Still taking fig. 6 as an example, node instance a may generate a task allocation event that includes a contract task defined in the intelligent contract during execution of the intelligent contract, such that service instance a1 may initiate the session registration request to P2P component instance a if node instance a determines that the contract task needs to be performed by at least one service instance deployed in service instance a1 and another at least one node device. The session registration request may include session group information such as a session group identifier, a component identifier list of a P2P component instance, and the session group information may be obtained by parsing a task allocation event, or may be allocated or determined for a session group to be registered by a first service instance initiating the session registration request, which is not limited in this specification.

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

P2PService::RegisterGroup(GroupId group_id, Set<Peer> peer_list );

wherein, the access in the calling process comprises the session group information: the group _ id is a session group identifier assigned by the first service instance for the session group to be registered, and is used for uniquely identifying the session group; the peer _ list specifies a component identifier list of all P2P component instances that need to join the to-be-registered talkgroup for the first service instance, so as to inform the first P2P component instance of which (P2P component instances located in other node devices) to include in the to-be-registered talkgroup. It will be appreciated that the same P2P component instance may participate in multiple talk groups simultaneously, and thus to avoid talk group confusion, the group _ ids need to be globally unique with respect to the blockchain network. As shown in fig. 4, in the case that the node instance a is a node a in subnet0, the peer _ list may be a component identifier of a P2P component instance in a node device where each node in subnet1 is respectively located, and the group _ id may be a subnet identifier of subnet1, so that P2P component instance a may register a session group including node a1, node B1, node C1, and node D1 in response to the session registration request, and obviously, the session group identifier of the session group is a subnet identifier of subnet 1. Actually, the peer _ list may include one or more peer _ ids, and the entry corresponding to any peer _ id may include information such as a monitoring address of the corresponding P2P component instance, a network port, and a public key used for TLS communication, which is not described in detail again.

In an embodiment, the contract 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. The contract tasks may also include database access tasks, such as that 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 contract task may also include the privacy computation task and the database access task, or may also include a task related to a specific service, and the like, which is not limited in this specification.

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

In an embodiment, the first P2P component instance may, in response to the received session registration request, register a corresponding session group according to the above-mentioned session group information carried in the request, where the process of registering a session group includes a process of creating each mapping relationship corresponding to the session group. For example, the first P2P component instance may create a first mapping relationship according to the session group identification contained in the session group registration request and the component identification of at least one other P2P component instance, such as creating the first mapping relationship between the group _ id and each peer _ id in the peer _ list. Taking the scenarios shown in fig. 4 and fig. 6 as an example, the P2P component instance a may create a first mapping relationship table corresponding to node B, node C, and node D in the blockchain primary network subnet0 in response to a session registration request initiated by the service instance a1, as shown in table 1 below.

In another embodiment, the first P2P component instance may further determine at least one consensus link established between itself and the other P2P component instances according to the component identifier of at least one other P2P component instance included in the session group registration request, and further may create the second mapping relationship based on the component identifiers of the other P2P component instances and the determined consensus link. 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 second mapping relationship. Still taking the scenarios shown in fig. 4 and 6 as an example, the P2P component instance a may create a second mapping relationship corresponding to node B, node C, and node D in the blockchain primary network subnet0 in response to the session registration request initiated by the service instance a1, as shown in table 2 below.

In yet another embodiment, the first P2P component instance may further create a third mapping relationship between the session group identifier and the corresponding clientchannel according to the session group identifier included in the session group registration request and an 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 session registration request initiated by service instance a1, as shown in table 3 below.

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 node device may establish a consensus link with multiple node devices, multiple group _ ids and their corresponding peer _ ids may be recorded in table 1; similarly, because the same service instance may participate in multiple talk groups at the same time, the same clientchanneld in table 3 may correspond to multiple group ids. The first P2P component instance may add a new group _ id and its corresponding peer _ id in table 1 in response to a new session registration request; a group _ id corresponding to a clientchanneld may also be added in table 3. Since the consensus links between the node devices are pre-established, the second mapping relationship may be extracted from the relationship table corresponding to the pre-established consensus links.

In addition, 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 3 are only logical relationships, and the specific storage manner is not limited in this specification. For example, the table 3 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, the first P2P component instance may send the created first mapping relationship to the P2P component instance corresponding to each peer _ id, so that the P2P component instance creates the first mapping relationship according to the mapping relationship and maintains the first mapping relationship locally. Alternatively, the service instance deployed in the node device in which each node instance belonging to the blockchain network is respectively located may initiate the session registration request to the P2P component instance deployed therein, so that each P2P component instance creates a corresponding second mapping relationship and maintains the second mapping relationship locally. In addition, for the first mapping relationship and the third mapping relationship, the first mapping relationship and the third mapping relationship may be created and maintained by each P2P component instance, and the specific process is not described again.

Through the above process, the service instances deployed in the node devices where the node instances belonging to the block chain network are respectively located are locally maintained with corresponding first mapping relationships, second mapping relationships and third mapping relationships. Wherein, two P2P component instances connected by the same consensus link respectively maintain mapping relations corresponding to each other. For example, in the scenario shown in fig. 6, the mapping relationships locally maintained by the P2P component instance a are as described in the foregoing tables, and are not described herein again. Correspondingly, the P2P component instance B locally maintains a first mapping relationship between the talkgroup identifications of the talkgroups in which the P2P component instance a participates in common with the P2P component instance a and the P2P component instance B, and a second mapping relationship between the P2P component instance a and the consensus links between the P2P component instance a and the P2P component instance B, and also maintains a fourth mapping relationship shown in table 4 below.

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

After the session group registration is completed (that is, after the P2P component instances corresponding to each node device 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 that is initiated by the first service instance and carries the target session group identifier and the service data, the second P2P component instance indicated by the target session group identifier, and further send the blockchain message using the common identification link with the second P2P component instance.

Upon receiving the messaging request, the first P2P component instance may construct a blockchain message from the request. If the target session group identifier and the service data can be extracted from the message sending request, and then both 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 the talkgroup indicated by the target talkgroup identity (hereinafter referred to as the target talkgroup). For example, the first P2P component instance may, after receiving the message sending request, query the target talkgroup in the third mapping relationship between the locally maintained talkgroup id and the client link, and then trigger the second P2P component instance that determines the indication of the target talkgroup id in case of query (i.e. indicating that the target talkgroup id is recorded in the third 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. The subsequent operation can be executed only when the initiator of the message sending request is legal, so that the safety of the block chain network is ensured, and the invalid operation is avoided. 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 blockchain message in a variety of ways, such as unicast, multicast, or broadcast. 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, which indicate that the blockchain message needs to be transmitted to a plurality of second P2P component instances indicated by the identifiers; in the broadcast mode, the message send request does not include any second component identifier (but includes the target talkgroup identifier), indicating that the blockchain message needs to be transmitted to all of the second P2P component instance(s) belonging to the talkgroup indicated by the target talkgroup identifier. Thus, the first P2P component instance may first determine the corresponding second component by: in the case that at least one second component identification is included in the message sending request, the first P2P component instance may determine at least one P2P component instance respectively indicated by the at least one second component identification as a second P2P component instance; however, in the case that the message sending request does not include the second component identifier, the first P2P component instance may determine the second component identifier corresponding to the session group identifier according to the first mapping relationship between the locally maintained session group identifier and the component identifier, and determine each P2P component instance corresponding to the determined second component identifier 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 second 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 group_id, PeerId peer_id, Bytes payload);

wherein, the parameter group _ id is a target session group 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 group _ id may be queried through the second 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 2, and then send the 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 group_id, Set<Peer> peer_list ,Bytes payload);

wherein, the parameter group _ id is a target session group 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 2, a channel _ id corresponding to each group _ 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 2, so as to send the blockchain messages to the P2P component instance B and the P2P component instance C through the respectively indicated channels.

③ the service instance a1 may call the broadcast interface BroadcastMsg to implement broadcast transmission of the blockchain message by:

P2PService::BroadcastMsg(GroupId group_id, Bytes payload);

wherein, the parameter group _ id is a target session group identifier, and the payload is service data. It can be seen that the entry parameter of the interface in the broadcast mode does not include any component identifier of the P2P component instance, so that the first P2P component instance may query at least one peer _ id corresponding to the target session group identifier group _ id through a first mapping relationship maintained locally, query a channel _ id corresponding to each peer _ id through a second mapping relationship maintained locally, and send the blockchain message to each second P2P component instance according to the common identification link channel indicated by each channel _ id. As in the case where the target session group identity group _ id is 0xxxx1, P2P component instance a may find its corresponding channel _ B, channel _ C and channel _ D through table 1, so as to send the blockchain messages to P2P component instance B, P2P component instance C and P2P component instance D, respectively, through the respectively indicated channels.

In step 504, the second P2P component instance receives the blockchain message and sends the blockchain message to the second service instance specified by the session group identifier on the second node device where the second P2P component instance is located.

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 talkgroup identifier contained therein, and further 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 fourth mapping relationship between a locally maintained session group identifier and the client link, a second client link corresponding to the session 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 group _ 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 4, that is, it indicates that the service instance B1 is a service instance belonging to the session group of 0xxxx1, so that the P2P component instance B may send the blockchain message to the service instance 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 session group 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.

In an embodiment, after the transmission of the message is completed, or after all messages corresponding to the contract task are transmitted, or after the contract task is completed, the established session group may be cancelled accordingly. For example, any service instance belonging to a session group, or a service instance initiating a session registration request to register the session group, may invoke the session group deregistration interface UnregisterGroup to deregister the session group through the following statements:

P2PService::UnregisterGroup(GroupId group_id);

wherein, the group _ id is the session group identifier of the session group to be logged off. After the statement is executed, the corresponding P2P component instance deletes the mapping associated with the session group, thereby logging out the session group. Therefore, the session group is registered along with the execution of the contract task and is unregistered after the execution of the contract task is finished, so that the session group has the same life cycle as the contract task, and the flexible establishment of the session group is realized. Of course, the session group may also be established according to an intelligent contract instead of a contract task, and the detailed process is not described again.

Through the embodiment, the block chain message containing the service data is transmitted by using the consensus link pre-established between the P2P component instances deployed in the node device where each block chain link point in the same block chain network, that is, the service data is transmitted by multiplexing the consensus 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 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. 7, the method may include:

step 702, a first P2P component instance receives a message sending request initiated by a first service instance on a first node device, and determines a second P2P component instance indicated by the message sending request;

step 704, 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, where the blockchain message includes a target session group identifier and service data carried in the message sending request, and the target session group identifier is used to specify the second service instance deployed in the second node device as the receiver of the blockchain message.

As previously described, the first P2P component instance determining the second P2P component instance indicated by the messaging request includes:

in the case that at least one second component identifier is included in the message sending request, the first P2P component instance determining at least one P2P component instance respectively indicated by the at least one second component identifier as a second P2P component instance;

and under the condition that the message sending request does not contain a second component identifier, the first P2P component instance determines the second component identifier corresponding to the target session group identifier according to the first mapping relation between the locally maintained session group identifier and the component identifier, and determines each P2P component instance corresponding to the determined second component identifier as a second P2P component instance.

As previously described, the first P2P component instance creates the first mapping by:

the first P2P component instance responds to the session group registration request initiated by the first service instance, and creates a first mapping relation according to the session group identification contained in the session group registration request and the component identification of at least one other P2P component instance.

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 second mapping between the locally maintained component identification and the consensus link.

As previously described, the first P2P component instance creates the second mapping by:

a first P2P component instance responds to a session group registration request initiated by a first service instance, and determines at least one consensus link established between the first P2P component instance and at least one other P2P component instance according to component identification of the other P2P component instance contained in the session group registration request;

the first P2P component instance creates a second mapping based on the component identifications of the other P2P component instances and the determined consensus link.

As described above, the session group registration request is generated by the first service instance according to a task allocation event, where the task allocation event includes a contract task defined in an intelligent contract executed by the first node instance.

As described above, the consensus link is established pairwise between the P2P component instances deployed in the node devices where the node instances belonging to the blockchain network are respectively located.

Corresponding to the above embodiments, 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. 8, the method may include:

step 802, the second P2P component instance receives a blockchain message sent by the first P2P component instance deployed in the first node device through the target consensus link between the first P2P component instance and the second P2P component instance, wherein the blockchain message includes the target session group identifier and the service data;

at step 804, the second P2P component instance determines a second service instance deployed in the second node device and specified by the target talkgroup id, and sends the blockchain message to the second service instance.

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 specified by the target session group 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 Session group ID according to a fourth mapping relationship between the locally maintained Session group ID and the client link, where the second client link connects a 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.

As described above, the same blockchain network to which the first node instance and the second node instance belong is a blockchain subnet, the blockchain subnet is managed by the blockchain master network, and the target session group identifier includes:

a subnet identification of the blockchain subnet.

Fig. 9 is a schematic structural diagram of an apparatus according to an exemplary embodiment. Referring to fig. 9, at the hardware level, the apparatus includes a processor 902, an internal bus 904, a network interface 906, a memory 908, and a non-volatile memory 910, but may also include hardware required for other services. One or more embodiments of the present description may be implemented in software, such as by the processor 902 reading a corresponding computer program from the non-volatile storage 910 into the memory 908 and then running. 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. 10 is a block diagram of an apparatus for transmitting a block chain message according to an exemplary embodiment. Referring to fig. 10, the apparatus may be applied to the device shown in fig. 9 to implement the technical solution of the present specification. The apparatus for transmitting a blockchain message 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 instances to participate in consensus is established between P2P component instances on different node devices, and the apparatus may include:

a message sending unit 1001, 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, determine a second P2P component instance indicated by the message sending request, and send a blockchain message through a target consensus link between the second P2P component instance, where the blockchain message includes a target session group identifier and service data carried in the message sending request;

the message receiving unit 1002 enables the second P2P component instance to receive the blockchain message, and send the blockchain message to the second service instance specified by the target talkgroup identifier on the second node device where the second service instance is located.

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

causing the first P2P component instance to determine, as the second P2P component instance, at least one P2P component instance respectively indicated by at least one second component identifier if the at least one second component identifier is included in the message sending request;

and under the condition that the first P2P component instance does not contain the second component identifier in the message sending request, determining the second component identifier corresponding to the target session group identifier according to the first mapping relation between the locally maintained session group identifier and the component identifier, and determining each P2P component instance corresponding to the determined second component identifier as the second P2P component instance.

Optionally, the method further includes:

the first creating unit 1003 causes the first P2P component instance to respond to the session group registration request initiated by the first service instance, and creates a first mapping relationship according to the session group identifier contained in the session group registration request and the component identifier of at least one other P2P component instance.

Optionally, the message sending unit 1001 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 second mapping between the locally maintained component identification and the consensus link.

Optionally, the method further includes the second creating unit 1004:

enabling a first P2P component instance to respond to a session group registration request initiated by a first service instance, and determining at least one consensus link established between the first P2P component instance and at least one other P2P component instance according to component identification of the other P2P component instance contained in the session group registration request;

causing the first P2P component instance to create a second mapping relationship based on the component identifications of the other P2P component instances and the determined 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, the session group registration request is generated by the first service instance according to a task allocation event, where the task allocation event includes a contract task defined in an intelligent contract executed by the first node instance.

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

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 verification triggering unit 1005, 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 session group identifier is recorded in the third mapping relationship between the locally maintained session group identifier and the client link.

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 receiving unit 1002 is further configured to:

causing the second P2P component instance to determine a second client link corresponding to the target talkgroup id according to a fourth mapping relationship between the locally maintained talkgroup id and the client link, the second client link connecting 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, each node device in the block chain system is deployed with at least one node of a block chain network, the block chain networks related to the block chain system 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.

Optionally, the same blockchain network to which the first node instance and the second node instance belong is a blockchain subnet, the blockchain subnet is managed by a blockchain master network, and the target session group identifier includes:

a subnet identification of the blockchain subnet.

Optionally, the blockchain message further includes a first component identifier of the first P2P component instance, and the message receiving unit 1002 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.

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 block diagram of an apparatus for transmitting a blockchain message according to an exemplary embodiment. Referring to fig. 11, the apparatus may also be applied to the device shown in fig. 9 to implement the technical solution of the present specification. The apparatus for transmitting a blockchain message 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 common identification link for the node instance to participate in common identification is established between P2P component instances on different node devices, and the apparatus may include:

a request receiving unit 1101, for enabling the first P2P component instance to receive a message sending request initiated by a first service instance on a first node device, and determining a second P2P component instance indicated by the message sending request;

the message sending unit 1102 is configured to enable the first P2P component instance to send 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 a target session group identifier and service data carried in the message sending request, and the target session group identifier is used to specify the second service instance deployed in the second node device as the recipient of the blockchain message.

Optionally, the request receiving unit 1101 is further configured to:

Optionally, the method further includes:

the first creating unit 1103 causes the first P2P component instance to respond to the session group registration request initiated by the first service instance, and create the first mapping relationship according to the session group identifier included in the session group registration request and the component identifier of at least one other P2P component instance.

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

Optionally, the method further includes:

a second creating unit 1104, for enabling the first P2P component instance to respond to the session group registration request initiated by the first service instance, and determining at least one consensus link established between itself and at least one other P2P component instance according to the component identity of the other P2P component instance contained in the session group registration request;

Fig. 12 is a block diagram of an apparatus for transmitting a blockchain message according to an exemplary embodiment. Referring to fig. 12, the apparatus may also be applied to the device shown in fig. 9 to implement the technical solution of the present specification. The apparatus for transmitting a blockchain message 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 common identification link for the node instance to participate in common identification is established between P2P component instances on different node devices, and the apparatus may include:

a message receiving unit 1201, enabling the second P2P component instance to receive a blockchain message sent by the first P2P component instance deployed in the first node device through the target consensus link between the first P2P component instance and the second P2P component instance, where the blockchain message includes the target session group identifier and the service data;

the message sending unit 1202, causes the second P2P component instance to determine the second service instance deployed in the second node device specified by the target talkgroup identifier, and sends the blockchain message to the second service instance.

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 message sending unit 1202 is further configured to:

a subnet identification of the blockchain subnet.

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, the first P2P component instance determining a second P2P component instance indicated by the messaging request, comprising:

3. The method of claim 2, the first P2P component instance creating the first mapping by:

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

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

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

7. The method of claim 3 or 5, wherein the session group registration request is generated by the first service instance according to a task allocation event, and the task allocation event comprises a contract task defined in an intelligent contract executed by the first node instance.

8. The method of claim 7, the contract tasks including private computing tasks and/or database access tasks.

9. 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:

and after the first P2P component instance receives the message sending request, under the condition that the target session group identification is determined to be recorded in the third mapping relation between the locally maintained session group identification and the client link, triggering and determining a second P2P component instance.

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 its own node device, and the second P2P component instance sends the blockchain message to a second service instance on its own second node device specified by the target talkgroup id, the method comprising:

11. 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.

12. The method of claim 1, wherein the same blockchain network to which the first node instance and the second node instance belong is a blockchain subnet, the blockchain subnet is managed by a blockchain master network, and the target session group identifier comprises:

a subnet identification of the blockchain subnet.

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:

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.

14. 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.

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

16. 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:

17. The method of claim 16, the first P2P component instance determining a second P2P component instance indicated by the messaging request, comprising:

18. The method of claim 17, the first P2P component instance creating the first mapping by:

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

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

21. The method of claim 18 or 20, wherein the session group registration request is generated by the first service instance based on a task allocation event comprising a contract task defined in an intelligent contract executed by the first node instance.

22. The method according to claim 16, wherein the consensus link is established pairwise between P2P component instances deployed in node devices respectively belonging to node instances of the blockchain network.

23. 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:

24. The method of claim 23, 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 specified by the target talkgroup id on its own second node device, comprising:

25. The method of claim 23, wherein the same blockchain network to which the first node instance and the second node instance belong is a blockchain subnet managed by a blockchain master network, and the target session group identifier comprises:

a subnet identification of the blockchain subnet.

26. The method according to claim 23, wherein the consensus link is established pairwise between P2P component instances deployed in node devices respectively belonging to node instances of the blockchain network.

27. A transmission device of 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, 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-26 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 26.