Detailed Description
Fig. 1 is a schematic diagram of a conventional blockchain system. As shown in fig. 1, in the prior art, a federation chain account may send a transaction through any node, the transaction containing traffic data, and the transaction may be broadcast to the entire network so that each node caches the transaction locally. In the consensus stage, the nodes A to D generate blocks based on a consensus algorithm, a plurality of transactions are packaged in the blocks, each node executes the transactions in the blocks generated by consensus, and writes the blocks into a local alliance chain (which is equivalent to writing each transaction in the blocks into the local alliance chain), so that uplink storage of transaction execution and transactions is realized.
The blockchain system described in fig. 1 would disclose the service data butted by each node in plain text in the federation chain, and all nodes in the federation chain network can check each other for the service data, so that protection of service data privacy cannot be achieved.
The scheme is used for realizing data isolation between nodes (data isolation between node groups, and data isolation between nodes and node groups) in a alliance chain network, so that the service data privacy of the nodes is protected.
The architecture of the blockchain system to which the present solution is applied will be described first. The blockchain system includes a federation chain network, and the federation chain network is composed of a plurality of nodes, and each node is deployed with a blockchain maintained by the federation chain network (for convenience of description, the blockchain maintained by the federation chain network is referred to as a federation chain). Each node in the federation chain network, in addition to maintaining a local federation chain, may also maintain at least one local private blockchain (referred to as a private chain for ease of description).
It should be noted that "private" as used herein refers to the private property of a node group, and does not refer to the private property of a node. Nodes maintaining the same private chain form a node group, and a node may create or join one or more than one node group. If a certain node group only comprises one node, the local private chain of the node is the private chain maintained by the node group; if a node group includes more than one node, then the private chain local to each node in the node group is the same, which is the private chain maintained by the node group.
In the scheme, any node can create or join a node group, nodes in the same node group maintain the same private chain, and the service data plaintext butted by the nodes in the same node group can be only written into the private chain of the node group, so that data isolation between the inside and the outside of the node group is realized.
Fig. 2 is a schematic structural diagram of a block chain system according to an embodiment of the present disclosure. As shown in fig. 2, the federation chain network includes a node a, a node B, a node C, and a node D, where nodes a to D all maintain the same federation chain locally, and the same federation chain is a block chain maintained by the federation chain network. In addition, node a and node D belong to the same node group, maintain the same private chain 1, share service data with each other, node C itself creates a node group, which only includes node C, node C maintains the private chain 2 alone (of course, node A, B, D may be allowed to join the node group later), node B does not create or join any node group, and service data docked by node B is shared to the whole network.
It should be noted that the service data of the node a and the node D are not shared to the node B and the node C, which realizes data isolation between node groups and between nodes. The service data of the node C can not be shared by other nodes, and the data isolation between the nodes is realized.
It can be seen that the architecture of the block chain system in this scheme is actually a two-layer network nested structure, the outer layer is a federation chain network, and a plurality of private chain networks (one private chain network is a node group) can be formed inside the federation chain network.
In addition, several concepts that may appear in the description of the present solution need to be explained.
Trading: refers to a transaction initiated by an account registered in the federation chain network (e.g., a manager account registered in the federation chain network by a manager of a certain node, and a user account registered in the federation network by a common user served by the manager), which is a concept at the federation chain network level, and the transaction is further written into the federation chain after being broadcast to each node in the federation chain network. For example, group creation transactions, group join transactions, business transactions.
Sub-transaction: refers to nested data structures within a transaction, which is a concept at the private chain network level. A child transaction specifies the private chain to which it is written, and all nodes maintaining the private chain write the child transaction to the private chain. For example, group creation sub-transactions, group joining sub-transactions, business sub-transactions.
As is well known, in the field of block chains, transactions are divided into executable transactions and credit-type transactions, and for executable transactions, a node not only needs to write the executable transactions into a block chain, but also needs to execute operations based on some data parameters in the executable transactions to obtain execution results; for the deposit card type transaction, the node does not need to execute, and only writes the deposit card type transaction into the block chain for deposit card.
The transaction on the federation chain level in the scheme is usually an execution type transaction, and the sub-transaction on the private chain level can be a deposit-certificate type transaction or an execution type transaction.
A first node: for convenience of description, a certain node in the federation chain network that creates a node group is referred to as a first node.
The second node: for convenience of description, some other node in the federation chain network that joins the node group created by the first node is referred to as a second node.
In order to make those skilled in the art better understand the technical solutions in the embodiments of the present specification, the technical solutions in the embodiments of the present specification will be described in detail below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all the embodiments. All other embodiments that can be derived by one of ordinary skill in the art from the embodiments given herein are intended to be within the scope of protection.
The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.
Fig. 3 is a flowchart of a method for creating a node group in a federation chain network, provided by an embodiment of the present specification, including the following steps:
s300: the first node receives a group creation transaction constructed by a first administrator account.
The first administrator account is an account registered by an administrator of the first node in the federation chain network. Generally, the administrator of a node is the organization (e.g., a bank) that provides business services to users. Typically, a centralized server on the node's administrator will interface with several users. For a user, a management party of a node provides centralized service, the user initiates a service to a centralized server of the management party of the node, and the centralized server encapsulates corresponding service data into a service transaction through an account of a first management party and submits the service transaction to the first node, so that the alliance-link network processes and stores the service transaction.
However, for the node group creation operation and the node group join operation, the operations are usually initiated by the administrator of the node and are not initiated by the user who the administrator of the node interfaces with.
In this embodiment of the present specification, the group creation transaction includes a creation sub-transaction (of course, other parameters are also included in general), and the creation sub-transaction includes a group public key, which is specified by the administrator of the first node and is used as a public key corresponding to the created node group. It will be appreciated that the administrator of the first node now specifies the group public key and, of course, also the group private key.
It should be noted here that the transaction is a data structure known in the field of blockchain technology, and the transaction usually includes other parameters (such as an account address, a hash value of the transaction, a signature of the transaction from the account initiating the transaction, etc.) in addition to the data (data) to be processed, where the other parameters in the transaction are not important for the present solution, and the other parameters are not emphasized below, and only data included in the transaction is important.
S302: the first node broadcasts the group creation transaction to the alliance-link network.
S304: the first node performs the group creation transaction.
S306: each other node than the first node performs the group creation transaction without creating a private chain.
S308: and each node in the alliance chain network writes the group establishing transaction and the corresponding execution result into a local alliance chain.
From the network level of the alliance chain, after accepting the group creation transaction initiated by the first manager account, the first node broadcasts the group creation transaction to the whole network. Each node in the alliance-link network packages the group creation transaction into a block based on a consensus algorithm (it is understood that there are other transactions in the block, and the other transactions are not necessarily other group creation transactions, and may be group join transactions or business transactions). After the block is generated by this consensus, each node needs to perform each transaction in the block and write the block into the local federation chain. It is noted here that a node will typically execute transactions based on locally deployed smart contracts or firmware.
Because the first node is the main body of the node group created this time, the private chain can be created only when the first node is local, and the private chain cannot be created when other nodes are local. This means that the first node performs the group creation transaction differently than the other nodes.
When the first node executes the group creation transaction, a private chain is created locally, a group creation sub-transaction embedded in the group creation transaction is extracted, written into the local private chain, and the group public key is used for encrypting the first node identifier.
And when executing the group creation transaction, each other node except the first node does not create the private chain, actually executes the group creation transaction without creating the private chain, and encrypts the first node identification by using the group public key. The other nodes may perform the group creation transaction "symbolically" (in addition, as long as it is ensured that the group public key is used to encrypt the first node identifier), in order to implement different manners of performing the group creation transaction by the first node and the other nodes, the following implementation may be specifically adopted:
two groups of creation transaction execution logics can be deployed on each node, and the two groups of creation transaction execution logics respectively correspond to two different logic triggering conditions. The group creation transaction execution logic 1 may be to create a private chain locally, write a group creation sub-transaction into the local private chain, and encrypt the first node identifier using the group public key, where the execution node is a node that accepts and broadcasts the group creation transaction; the group creation transaction execution logic 2 may be any execution logic that does not actually execute the group creation transaction, as long as it is ensured that the first node identification is encrypted using the group public key, and the trigger condition for this is that the execution node is not the node that accepts and broadcasts the group creation transaction. It is worth emphasizing here that the present specification does not specifically define the group creation transaction execution logic 2, as long as "symbolic" execution of the group creation transaction without creating a private chain is satisfied.
It will be appreciated that the results of the execution of the group creation transaction will of course also be written into the federation chain, and the results of the execution written into the federation chain by each node will of course be identical. In a specific implementation, the group creation transaction execution logic 1 and the group creation transaction execution logic 2 may be set to generate a logic of a same execution result, and the execution result corresponding to the group creation transaction may be set to include a group public key and an encrypted first node identifier, so as to store a public key corresponding to a node group created by the group creation transaction and an encrypted identity of a node creating the node group.
It is to be understood that the writing of the execution result into the federation chain (or private chain) herein does not necessarily mean storing the execution result in plaintext into the federation chain (or private chain), and may also mean storing the execution result in plaintext locally and anchoring the hash value of the execution result in plaintext onto the federation chain (private chain).
The above description of "symbolic" execution of a group creation transaction is also applicable to the case of "symbolic" execution of other transactions, and the specific principles will not be described again later when "symbolic" execution is mentioned. It is worth emphasizing that the node identification does not need to be encrypted when symbolically performing anonymous registration transactions and business transactions.
In addition, in practical applications, more than one node group may be created in the federation chain network, in which case, the group public key of the node group may be used as a unique identifier to distinguish different node groups, or a group identifier may be set for the node group.
Specifically, the group creation sub-transaction may further include a group identifier, and accordingly, an execution result corresponding to the group creation transaction may also include the group identifier.
In an embodiment of the present specification, the group creation sub-transaction may further include a signature generated using a group private key, so that the first node may verify the signature before broadcasting the group creation transaction to the whole network, and if the verification is passed, the group creation transaction is authorized to be initiated by the holder of the group private key, and a node group may be created based on the group creation transaction.
In this embodiment, it can be understood that the first node writes the group creation sub-transaction into the locally created private chain, and actually the first node writes the private chain creation block (which usually includes several group join sub-transactions or business transactions accepted after the creation of the private chain) wrapped with the group creation sub-transaction into the locally created private chain.
As can be seen, for a group creation transaction and its embedded group creation sub-transactions, the group creation transaction is packed into a block of a federation chain and written into the federation chain, and the group creation sub-transactions are packed into a creation block of a private chain local to the first node. In order to clarify the association relationship between the federation chain block and the private chain block and facilitate the record lookup, the first node may write a pointer object in the private chain block (which may specifically be in the block header) encapsulating the group creation sub-transaction, for pointing to the federation chain block encapsulating the group creation transaction.
Fig. 4 is a schematic diagram of a first node locally maintaining a federation chain and a private chain according to an embodiment of the present specification. As shown in fig. 4, the private chain creation block (packed with group creation sub-transactions) of the private chain local to the first node points to a federation chain block in the locally maintained federation chain in which the group creation transactions are packed by a pointer object.
The node group in the scheme can only comprise one node, and the node can write the service data butted by the node into a local private chain in a clear text manner. For this reason, a description will be given of how to anonymously register a user and how to transact in the case where only one node is included in the node group.
In practical application, a user interfacing with the first node may not delegate the first node to initiate a service transaction, but the user registers an account in the federation chain network and initiates the service transaction through the federation chain network. In this case, the user has a need for anonymity and does not want to disclose his identity in the federation chain network. To this end, fig. 5 is a flowchart illustrating an anonymous registration method based on a node group according to an embodiment of the present specification, where the method includes the following steps:
s500: the first node receives an anonymous registration transaction constructed from a corresponding user account.
The anonymous registration transaction comprises an anonymous registration sub-transaction, and the anonymous registration sub-transaction comprises an anonymous public key and a signature generated by using a group private key corresponding to the group public key; wherein the user account is an account registered in a federation chain network by a user interfaced by the first node, and the anonymous public key is specified by the user interfaced by the first node.
It will be appreciated that at the federation chain network level, an anonymous registration transaction effectively contains identity information for a user account, since the anonymous registration transaction is initiated by the user account.
S502: and the first node verifies the signature corresponding to the group private key in the anonymous registration sub-transaction by using the group public key, and processes the anonymous registration transaction if the signature passes the verification.
The processing comprises the following steps: reconstructing an anonymous registration transaction comprising the anonymous registration sub-transaction through the first administrator account. The effect of this process is that the first node reconstructs the anonymous registration transaction with its own identity, so that the identity information of the user account can be stripped.
S504: the first node broadcasts the reconstructed anonymous registration transaction to the federation chain network.
Because the identity information of the user account is stripped from the anonymous registration transaction, the first node broadcasts the anonymous registration transaction to the whole network, and the identity information of the user account cannot be leaked.
S506: the first node performs the anonymous registration transaction.
Specifically, the first node writes the anonymous registration sub-transaction to a local private chain. Thus, it is equivalent to anonymously registering the user at the private link network level. The user may subsequently initiate a business sub-transaction using a signature generated by the anonymous private key at the private chain network level.
S508: each other node than the first node performs the reconstructed anonymous registration transaction without creating a private chain.
In particular, each other node than the first node symbolically executes the reconstructed anonymous registration transaction without creating a private chain.
S510: each node in the federation chain network writes the reconstructed anonymous registration transaction to a local federation chain.
In addition, the anonymous registration sub-transaction may further include a signature generated using an anonymous private key corresponding to the anonymous public key to prove that an originator of the anonymous registration sub-transaction holds the anonymous private key.
Correspondingly, the first node may verify the signature corresponding to the anonymous private key in the anonymous registration sub-transaction by using the anonymous public key, and if the signature corresponding to the anonymous private key is verified, the first node processes the anonymous registration sub-transaction.
In addition, although the user is registered anonymously, in order to audit the service transaction initiated by the user in an anonymous identity subsequently, the first node can establish and store the corresponding relation between the anonymous public key and the user account locally, so that only the first node can master the real identity of the user corresponding to the registered anonymous public key.
Further, the first node may write a pointer object in the private chain block that encapsulates the anonymous registration sub-transaction for pointing to the federation chain block that encapsulates the reconstructed anonymous registration transaction.
Fig. 6 is a schematic flowchart of a transaction method based on an anonymous registration method according to an embodiment of the present specification, including the following steps:
s600: and the first node receives the business transaction constructed by the corresponding user account.
The business transaction comprises a business sub-transaction, and the business sub-transaction comprises business data, a signature generated by using the group private key and a signature generated by using an anonymous private key corresponding to the anonymous public key.
The business sub-transaction can be a deposit card type transaction or an execution type transaction. When the business sub-transaction is a credit card type transaction, the business data can be a data result obtained after the management party executes operation according to the business request; when the service sub-transaction is an execution type transaction, the service data may be a service request itself, and the nodes in the node group need to execute the service sub-transaction on the private chain network level to obtain an execution result, and both the service sub-transaction and the execution result are written into the private chain.
The business sub-transaction contains the signature corresponding to the group private key, and the business sub-transaction is proved to have the right to call the nodes in the node group to process the transaction. In addition, when more than one node group exists in the alliance-link network, the service sub-transaction may further include a group identifier for indicating the node group to be invoked by the service sub-transaction. And the first node verifies the signature in the business sub-transaction by using the group public key corresponding to the group identifier.
The effect of the signature corresponding to the anonymous private key contained in the business sub-transaction is to prove that the business sub-transaction is initiated by the authorization of the user account corresponding to the anonymous public key.
S602: and the first node verifies the signature corresponding to the group private key in the business sub-transaction by using the group public key, verifies the signature corresponding to the anonymous private key in the business sub-transaction by using the anonymous public key corresponding to the user account, and processes the business transaction if the verification is passed.
The processing comprises the following steps: and reconstructing the business transaction containing the hash value of the business sub-transaction through the first management party account. On one hand, service data relates to data privacy and cannot be shared to a node group, on the other hand, on the network level of a alliance chain, service transactions including service sub-transactions need to be written into the alliance chain, through the processing, the first node can acquire plaintext of the service sub-transactions, and other nodes can only acquire hash values of the service sub-transactions. Meanwhile, the account information of the user initiating the business transaction cannot be leaked to other nodes except the first node.
In addition, the first node may perform the above-mentioned processing on the service transaction after determining that the anonymous public key has a correspondence with the user account according to a correspondence between the locally stored anonymous public key and the user account.
S604: the first node broadcasts the processed service transaction to the federation network.
S606: the first node performs the business transaction.
When the first node executes the business transaction, if the business sub-transaction is found to be a deposit-certificate type transaction, the business sub-transaction is written into a local private chain, if the business sub-transaction is found to be an execution type transaction, the business sub-transaction is executed, a corresponding execution sub-result is obtained, and the business sub-transaction and the corresponding execution sub-result are written into the local private chain.
S608: and other nodes in the alliance chain network execute the business transaction under the condition that a private chain is not created.
Here, the other nodes actually "symbolically" perform the traffic transaction.
S610: and each node in the alliance chain network writes the service transaction into a local alliance chain.
In addition, the first node may write a pointer object in the private chain block in which the service sub-transaction is encapsulated, for pointing to the federation chain block in which the processed service transaction is encapsulated.
A method of joining a node group is described below. It should be noted that, after the foregoing principle description of creating a node group is referred to, details of the principle communication will not be repeated.
Fig. 7 is a flowchart of a method for joining a node group according to an embodiment of the present specification, where the method includes the following steps:
s700: the second node receives a group join transaction constructed by the second administrator account.
The group join transaction comprises a group join sub-transaction, and the group join sub-transaction comprises a signature generated by using a group private key corresponding to the group public key; the second administrator account is an account registered by an administrator of the second node in the federation chain network.
After the first node creates the node group, the administrator of the second node may enable the second node to join the node group as well, sharing the service data with the first node. The administrator of the first node may provide the group private key to the administrator of the second node online.
S702: and the second node verifies the signature in the group joining sub-transaction by using the group public key, and if the signature passes the verification, the second node broadcasts the group joining transaction to the alliance chain network.
S704: the second node performs the group join transaction.
Specifically, the second node creates a private chain locally, encrypts the second node identity using the group public key, synchronizes private chain history data from other nodes storing the same private chain (e.g., the first node and other nodes that have joined the same group of nodes), and writes the group join sub-transaction into the local private chain.
S706: the other nodes storing the same private chain perform the group join transaction.
Specifically, the other nodes storing the same private chain encrypt the second node identifier by using the group public key, and write the group join sub-transaction into the local private chain.
S708: and other nodes in the alliance chain network, which do not store the same private chain, execute the group join transaction without creating the private chain.
The other nodes in the federation chain network that do not store the same private chain refer to other nodes that join the node group and encrypt the second node identifier using the group public key.
S710: and each node in the alliance chain network writes the group joining transaction and the corresponding execution result into a local alliance chain.
The execution result corresponding to the group join transaction may contain the encrypted second node identification.
Further, the group join transaction further includes a group identifier, and the second node verifies the signature of the group join sub-transaction using the group public key corresponding to the group identifier.
In addition, the second node and other nodes storing the same private chain write a pointer object in the private chain block encapsulating the group join sub transaction, for pointing to the federation chain block encapsulating the group join transaction.
Fig. 8 is a schematic diagram of locally maintaining a federation chain and a private chain by a second node according to an embodiment of the present specification. As shown in fig. 8, the second node requests to join the node group after the first node maintains the private chain for a while, before that, the private chain maintained by the first node stores two private chain blocks, the group join sub-transaction is packaged into a third private chain block, and meanwhile, the third private chain block is also associated with a certain alliance chain block packaged with the group join transaction.
The node group in the scheme can comprise more than one node, and each node in the same node group can share the service data butted by the node. A description is made herein of how to trade in the case where more than one node is included in a node group. It should be noted that, after the foregoing description of the principle of how to perform transactions in the case where only one node is included in the node group is referred to, details of the principle will not be repeated.
Fig. 9 is a flowchart of an anonymous registration method based on a node group according to an embodiment of the present specification, where the method includes the following steps:
s900: the second node receives an anonymous registration transaction constructed from the corresponding user account.
The anonymous registration transaction comprises an anonymous registration sub-transaction, the anonymous registration sub-transaction comprises an anonymous public key and a signature generated by using the group private key; wherein the user account is an account registered in a federation chain network by a user interfaced by the second node, and the anonymous public key is specified by the user corresponding to the second node.
S902: and the second node verifies the signature corresponding to the group private key in the anonymous registration sub-transaction by using the group public key, and processes the anonymous registration transaction if the signature passes the verification.
The processing comprises the following steps: reconstructing, via the second administrator account, an anonymous registration transaction that includes the anonymous registration sub-transaction.
S904: the second node broadcasts the processed anonymous registration transaction to the federation chain network.
S906: the second node performs the anonymous registration transaction with other nodes storing the same private chain.
Specifically, the second node writes the anonymous registration sub-transaction to a local private chain with other nodes storing the same private chain.
S908: and other nodes in the alliance chain network, which do not store the same private chain, execute the reconstructed anonymous registration transaction under the condition that the private chain is not created.
S910: each node in the federation chain network writes the anonymous registration transaction to a local federation chain.
In addition, the anonymous registration sub-transaction may further include a signature generated using an anonymous private key corresponding to the anonymous public key, such that the second node may verify the signature corresponding to the anonymous private key in the anonymous registration sub-transaction using the anonymous public key. Correspondingly, if the signature corresponding to the anonymous private key passes the verification, the second node processes the anonymous registration transaction.
In addition, the second node may establish and store a correspondence between the anonymous public key and the user account locally.
Fig. 10 is a schematic flowchart of a transaction method based on an anonymous registration method, provided by an embodiment of the present specification, and includes:
s1000: and the second node receives the business transaction constructed by the corresponding user account.
The business transaction comprises a business sub-transaction, and the business sub-transaction comprises business data, a signature generated by using the group private key and a signature generated by using an anonymous private key corresponding to the anonymous public key.
S1002: and the second node verifies the signature corresponding to the group private key in the business sub-transaction by using the group public key, verifies the signature corresponding to the anonymous private key in the business sub-transaction by using the anonymous public key, and sends the business sub-transaction to other nodes in the same node group and processes the business transaction if the verification is passed.
Since the node group includes not only the second node but also at least the first node (and possibly more nodes), the second node needs to send the service sub-transaction in the accepted service transaction to other nodes in the same node group on the private link network level.
In addition, the second node needs to reconstruct the business transaction containing the hash value of the business sub-transaction through the second administrator account. In this way, the user account information for initiating the business transaction is not leaked to other nodes except the first node.
In addition, the second node may perform the above-mentioned processing on the service transaction after determining that the anonymous public key has a correspondence with the user account according to a correspondence between the locally stored anonymous public key and the user account.
S1004: and the second node broadcasts the processed service transaction to the alliance chain network.
S1006: and the second node executes the service transaction with other nodes storing the same private chain.
S1008: and executing the processed business transaction by other nodes which do not store the same private chain in the alliance chain network under the condition that the private chain is not created.
S1010: and each node in the alliance chain network writes the processed business transaction into a local alliance chain.
Specifically, if the service sub-transaction is a credit-type transaction, the second node writes the service sub-transaction into a local private chain with other nodes storing the same private chain. And if the business sub-transaction is an execution type transaction, the second node executes the business sub-transaction with other nodes storing the same private chain, and writes the business sub-transaction and a corresponding execution sub-result into the local private chain.
Further, the service sub-transaction further includes a group identifier, and the second node may verify a signature in the service sub-transaction using the group public key corresponding to the group identifier.
Further, the second node and other nodes storing the same private chain write a pointer object in the private chain block encapsulating the service sub-transaction, which is used for pointing to the alliance chain block encapsulating the processed service transaction.
In addition, for each other node storing the same private chain, if the other node determines that the service sub-transaction is received, the other node returns a signature to the second node. In this way, if the second node determines that the number of the received signatures of the other nodes meets the preset distributed fault-tolerant condition, the second node processes the service transaction.
The distributed fault tolerance condition may be that the number of received signatures reaches a specified number. For example, if the number of nodes within the same node group is not less than 4, the specified number may be 2f +1, where f = (N-1)/3, and N is the number of nodes within the node group.
In addition, the embodiments of the present specification also provide a block chain system, including a federation chain network, the federation chain network including a plurality of nodes;
the first node receives a group creation transaction constructed by a first administrator account; the group creation transaction comprises a group creation sub-transaction, the group creation sub-transaction comprising a group public key; the first administrator account is an account registered by an administrator of the first node in the federation chain network; the group public key is specified by a manager of the first node; broadcasting the group creation transaction to the federation chain network; executing the group creation transaction, including: creating a private chain locally, writing the created sub-transaction into the local private chain, and encrypting the first node identifier by using the group public key;
each other node, other than the first node, performing the group creation transaction without creating a private chain, comprising: encrypting the first node identification using the group public key;
each node in the alliance chain network writes the group establishing transaction and the corresponding execution result into a local alliance chain; and the execution result corresponding to the group creation transaction contains the encrypted first node identification.
The first node receives an anonymous registration transaction constructed by a corresponding user account; the anonymous registration transaction comprises an anonymous registration sub-transaction, and the anonymous registration sub-transaction comprises an anonymous public key and a signature generated by using a group private key corresponding to the group public key; wherein the user account is an account registered in a federation chain network by a user interfaced by the first node, the anonymous public key being specified by the user interfaced by the first node; verifying the signature corresponding to the group private key in the anonymous registration sub-transaction by using the group public key, and if the signature passes the verification, processing the anonymous registration transaction, wherein the processing comprises the following steps: reconstructing an anonymous registration transaction comprising the anonymous registration sub-transaction through the first administrator account; broadcasting the reconstructed anonymous registration transaction to the federation chain network; performing the anonymous registration transaction, comprising: writing the anonymous registration sub-transaction to a local private chain;
each other node than the first node, without creating a private chain, performing the reconstructed anonymous registration transaction;
and each node in the alliance chain network writes the anonymous registration transaction into a local alliance chain.
The first node receives a business transaction constructed by a corresponding user account; the business transaction comprises a business sub-transaction, and the business sub-transaction comprises business data, a signature generated by using the group private key and a signature generated by using an anonymous private key corresponding to the anonymous public key; verifying the signature corresponding to the group private key in the business sub-transaction by using the group public key, verifying the signature corresponding to the anonymous private key in the business sub-transaction by using the anonymous public key corresponding to the user account, and processing the business transaction if the verification is passed, wherein the verification comprises the following steps: reconstructing a business transaction containing the hash value of the business sub-transaction through the first manager account; broadcasting the reconstructed business transaction to the federation chain network; performing the business transaction, including: writing the business sub-transaction into a local private chain;
the other nodes except the first node execute the reconstructed business transaction under the condition that a private chain is not created;
and each node in the alliance chain network writes the service transaction into a local alliance chain.
The second node receives a group joining transaction constructed by the account of the second management party; the group join transaction comprises a group join sub-transaction, and the group join sub-transaction comprises a signature generated by using a group private key corresponding to the group public key; the second administrator account is an account registered by an administrator of the second node in the federation chain network; verifying the signature in the group joining sub-transaction by using the group public key, and broadcasting the group joining transaction to the alliance chain network if the signature passes the verification; performing the group join transaction, including: creating a private chain locally, encrypting the second node identification by using the group public key, synchronizing private chain historical data from other nodes storing the same private chain, and writing the group joining sub-transaction into the local private chain;
other nodes storing the same private chain, performing the group join transaction, including: encrypting a second node identification by using the group public key, and writing the group joining sub-transaction into a local private chain;
the other nodes of the same private chain are not stored in the alliance chain network, and the group joining transaction is executed under the condition that the private chain is not created, wherein the group joining transaction comprises the following steps: encrypting a second node identification using the group public key;
each node in the alliance chain network writes the group joining transaction and the corresponding execution result into a local alliance chain; and the execution result corresponding to the group joining transaction comprises the encrypted second node identification.
The second node receives an anonymous registration transaction constructed by a corresponding user account; the anonymous registration transaction comprises an anonymous registration sub-transaction, the anonymous registration sub-transaction comprises an anonymous public key and a signature generated by using the group private key; the user account is an account registered in a alliance chain network by a user connected with the second node, and the anonymous public key is specified by the user corresponding to the second node; verifying the signature corresponding to the group private key in the anonymous registration sub-transaction by using the group public key, and if the signature passes the verification, processing the anonymous registration transaction, wherein the processing comprises the following steps: reconstructing an anonymous registration transaction comprising the anonymous registration sub-transaction through the second administrator account; broadcasting the reconstructed anonymous registration transaction to the federation chain network;
the second node, with other nodes storing the same private chain, performs the anonymous registration transaction, including: writing the anonymous registration sub-transaction to a local private chain;
other nodes of the same private chain are not stored in the alliance chain network, and the reconstructed anonymous registration transaction is executed under the condition that the private chain is not created;
and each node in the alliance chain network writes the anonymous registration transaction into a local alliance chain.
The second node receives a business transaction constructed by a corresponding user account; the business transaction comprises a business sub-transaction, and the business sub-transaction comprises business data, a signature generated by using the group private key and a signature generated by using an anonymous private key corresponding to the anonymous public key; verifying the signature corresponding to the group private key in the business sub-transaction by using a group public key, verifying the signature corresponding to the anonymous private key in the business sub-transaction by using the anonymous public key, if the verification is passed, sending the business sub-transaction to other nodes in the same node group, and processing the business transaction, wherein the verification comprises the following steps: reconstructing a business transaction containing the hash value of the business sub-transaction through the second administrator account; broadcasting the reconstructed business transaction to the federation chain network;
the second node and other nodes storing the same private chain execute the service transaction, including: writing the business sub-transaction into a local private chain;
other nodes of the same private chain are not stored in the alliance chain network, and reconstructed service transaction is executed under the condition that the private chain is not created;
and each node in the alliance chain network writes the reconstructed service transaction into a local alliance chain.
Embodiments of the present specification also provide a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the functions of the node in the embodiments of the present specification when executing the program.
Fig. 11 is a more specific hardware structure diagram of a computing device provided in an embodiment of the present specification, where the device may include: a processor 1110, a memory 1120, an input/output interface 1130, a communication interface 1140, and a bus 1150. Wherein the processor 1110, memory 1120, input/output interface 1130, and communication interface 1040 enable communication connections within the device with each other via bus 1050.
The processor 1110 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.
The Memory 1120 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random access Memory), a static storage device, a dynamic storage device, or the like. The memory 1120 can store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1120 and called by the processor 1110 for execution.
The input/output interface 1130 is used for connecting an input/output module to realize information input and output. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.
The communication interface 1140 is used to connect a communication module (not shown in the figure) to enable the device to interact with other devices. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).
Bus 1150 includes a pathway for communicating information between various components of the device, such as processor 1110, memory 1120, input/output interface 1130, and communication interface 1140.
It should be noted that although the above-mentioned device only shows the processor 1110, the memory 1120, the input/output interface 1130, the communication interface 1140 and the bus 1150, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.
Embodiments of the present specification also provide a computer-readable storage medium on which a computer program is stored, which when executed by a processor, implements the functions of a node in the embodiments of the present specification.
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 tape, magnetic disk storage 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.
From the above description of the embodiments, it is clear to those skilled in the art that the embodiments of the present disclosure can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be embodied in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, or the like, and includes several instructions for enabling a computer device (which may be a personal computer, a service device, or a network device) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The systems, methods, modules or units described 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.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to some descriptions of the method embodiment for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present disclosure. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is only a specific embodiment of the embodiments of the present disclosure, and it should be noted that, for those skilled in the art, a plurality of modifications and decorations can be made without departing from the principle of the embodiments of the present disclosure, and these modifications and decorations should also be regarded as the protection scope of the embodiments of the present disclosure.