WO2023124746A1 - 跨子网交互的权限控制 - Google Patents

跨子网交互的权限控制 Download PDF

Info

Publication number
WO2023124746A1
WO2023124746A1 PCT/CN2022/135831 CN2022135831W WO2023124746A1 WO 2023124746 A1 WO2023124746 A1 WO 2023124746A1 CN 2022135831 W CN2022135831 W CN 2022135831W WO 2023124746 A1 WO2023124746 A1 WO 2023124746A1
Authority
WO
WIPO (PCT)
Prior art keywords
subnet
blockchain
node
cross
subnetwork
Prior art date
Application number
PCT/CN2022/135831
Other languages
English (en)
French (fr)
Inventor
陶友贤
Original Assignee
支付宝(杭州)信息技术有限公司
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司, 蚂蚁区块链科技(上海)有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2023124746A1 publication Critical patent/WO2023124746A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD

Definitions

  • One or more embodiments of this specification relate to the technical field of blockchain, and in particular to a cross-subnet interaction authority control method and device, electronic equipment, and storage media.
  • Blockchain technology is built on top of transmission networks such as peer-to-peer networks. Nodes in the blockchain network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data. Different blockchain networks can be formed to store different types of business data. In this scenario, there is a need for interaction between different blockchain networks, so that some complex businesses can be realized through cross-chain interaction.
  • the blockchain network can itself be the main network and dynamically create subnets based on certain rules. Then, there may be requirements for data interaction and cross-subnet writing services between different blockchain subnets.
  • one or more embodiments of this specification provide a cross-subnet interaction permission control method and device, electronic equipment, and a storage medium.
  • a permission control method for cross-subnet interaction is proposed, which is applied to blockchain system, the blockchain system includes a blockchain main network and a blockchain subnet managed by it; the method includes: the destination subnet node in the destination blockchain subnet receives the source subnetwork in the source blockchain subnet
  • the cross-subnet request sent by the node, the cross-subnet request includes the operation information for the write operation of the target block chain subnet; the target subnet node queries each zone managed by the block chain main network block chain subnet for the permission information of the write operation of the destination blockchain subnet, and verify the operation information according to the permission information; the destination subnet node responds to the The above cross-subnet request, and execute the corresponding write operation according to the operation information.
  • a permission control device for cross-subnet interaction including: a receiving unit, which enables the destination subnet node in the destination blockchain subnet of the blockchain main network to receive
  • the cross-subnet request sent by the source subnet node in the source blockchain subnet of the blockchain main network, the cross-subnet request includes the operation information for the write operation of the destination blockchain subnet;
  • the query unit causing the destination subnetwork node to query the permission information of each blockchain subnetwork of the blockchain main network for the write operation of the destination blockchain subnetwork, and perform operations on the operation information according to the permission information
  • the verifying and writing unit is configured to enable the destination subnetwork node to respond to the cross-subnetwork request and execute a corresponding writing operation according to the operation information if the verification is passed.
  • an electronic device including: a processor; a memory for storing processor-executable instructions; wherein, the processor executes the executable instructions In order to realize the method described in any one of the above-mentioned embodiments.
  • a computer-readable storage medium on which computer instructions are stored, and when the instructions are executed by a processor, the methods described in any one of the above-mentioned embodiments are implemented. step.
  • the permission information can be used when other blockchain subnets request to write data to the blockchain subnet Verify the cross-subnet request that requests to write data, and then execute the write operation on the premise that the verification passes, so as to ensure the security of the blockchain subnet data and realize the permission control of the cross-subnet write service. For example, control the blockchain subnets that allow data to be written, and control the type of cross-subnet write operations, etc.
  • Fig. 1 is a schematic diagram of creating a smart contract provided by an exemplary embodiment.
  • Fig. 2 is a schematic diagram of invoking a smart contract provided by an exemplary embodiment.
  • Fig. 3 is a schematic diagram of creating and invoking a smart contract provided by an exemplary embodiment.
  • Fig. 4 is a schematic diagram of building a blockchain subnet based on the blockchain main network provided by an exemplary embodiment.
  • Fig. 5 is a schematic diagram of registering a blockchain network as a blockchain subnet provided by an exemplary embodiment.
  • Fig. 6 is a flow chart of a cross-subnet interaction permission control method provided by an exemplary embodiment.
  • Fig. 7 is a flow chart of an audit method for cross-chain interaction provided by an exemplary embodiment.
  • Fig. 8 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • Fig. 9 is a block diagram of a cross-subnet interaction authority control device provided by an exemplary embodiment.
  • the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification.
  • the method may include more or less steps than those described in this specification.
  • a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.
  • Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
  • the public chain has the highest degree of decentralization.
  • the public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the bookkeeping rights of new blocks. Moreover, each participant (ie node) can freely join and exit the network and perform related operations.
  • the private chain the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization.
  • the private chain can be a weakly centralized system with strict restrictions and few participating nodes.
  • the alliance chain is a blockchain between the public chain and the private chain, which can realize "partial decentralization".
  • Each node in the consortium chain usually has a corresponding entity or organization; participants join the network through authorization and form an alliance of stakeholders to jointly maintain the operation of the blockchain.
  • Smart contracts on the blockchain are contracts that can be triggered by transactions on the blockchain system. Smart contracts can be defined in the form of code.
  • EVM Ethereum Virtual Machine
  • bytecode virtual machine code
  • the EVM of node 1 can execute the transaction and generate a corresponding contract instance.
  • "0x6f8ae93" in Figure 1 represents the address of this contract, the data field of the transaction can store bytecode, and the to field of the transaction is empty.
  • the contract is successfully created and can be called in the subsequent process.
  • a contract account corresponding to the smart contract appears on the blockchain and has a specific address, and the contract code will be saved in the contract account.
  • the behavior of smart contracts is controlled by the contract code.
  • the smart contract makes a virtual account containing contract code and account storage (Storage) generated on the blockchain.
  • the EVM of a certain node can execute this transaction and generate a corresponding contract instance.
  • the from field of the transaction in Figure 2 is the address of the account of the transaction initiator (ie Bob), the "0x6f8ae93" in the to field represents the address of the called smart contract, and the value field in Ethereum is the address of the ether currency Value, the method and parameters of calling the smart contract saved in the data field of the transaction.
  • the value of balance may change.
  • a client can view the current value of balance through a certain blockchain node (such as node 6 in Figure 2).
  • the smart contract is independently executed by each node in the blockchain network in a prescribed manner, and all execution records and data are stored on the blockchain, so when the transaction is completed, the blockchain will store data that cannot be tampered with and will not be tampered with. Lost transaction credentials.
  • FIG. 3 The schematic diagram of creating a smart contract and calling a smart contract is shown in Figure 3.
  • Calling a smart contract in Ethereum is to initiate a transaction pointing to the address of the smart contract, and the code of the smart contract is distributed and runs in the virtual machine of each node in the Ethereum network.
  • smart contracts can also be set by the system in the genesis block. This type of contract is generally called a genesis contract. Generally, some blockchain network data structures, parameters, properties and methods can be set in the genesis contract. In addition, accounts with system administrator privileges can create system-level contracts or modify system-level contracts (referred to as system contracts). In addition to the EVM in Ethereum, different blockchain networks may also use various virtual machines, which are not limited here.
  • Contract execution results can be expressed as events in receipts.
  • the message mechanism can implement message delivery through events in the receipt to trigger blockchain nodes to perform corresponding processing.
  • the structure of an event can be, for example:
  • Blockchain nodes can listen to the topic of the event to perform preset processing when listening to a predefined topic, or read relevant content from the data field of the corresponding event, and can execute preset based on the read content deal with.
  • the monitoring code can be embedded in the blockchain platform code running on the blockchain node, so that the monitoring code can monitor the transaction content of the blockchain transaction, the contract status of the smart contract, the receipt generated by the contract, etc. or multiple types of data, and send the monitored data to a predefined listener.
  • the monitoring code is deployed in the blockchain platform code instead of the client of the listening party, this implementation based on the monitoring code is relatively more active than the event mechanism.
  • the above monitoring code can be added to the blockchain platform code by the developers of the blockchain platform during the development process, or can be embedded by the monitoring party based on its own needs, which is not limited in this manual.
  • a consensus mechanism of transaction granularity can be implemented between blockchain nodes. For example, after a node (such as a unique node) obtains a blockchain transaction, if the blockchain transaction is recognized by other nodes, Each node that approves the blockchain transaction can add the blockchain transaction to the latest block maintained by itself, and finally can ensure that each node generates the same latest block.
  • the consensus mechanism is a mechanism for blockchain nodes to reach a consensus on block information (or block data) in the entire network, 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 Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) ) algorithm, HoneyBadgerBFT algorithm, etc.
  • all nodes in the blockchain network are in an equal position, so that all blockchain nodes in the blockchain network will maintain the same block data, but some nodes sometimes exist Realize the needs of small-scale transactions and prevent other nodes from obtaining these transactions and related data, resulting in the inability to meet the special needs of some nodes.
  • all consortium members that is, node members in the consortium
  • all consortium members can form a blockchain network, and all consortium members have corresponding blockchain nodes in the blockchain network, and can pass the corresponding zone Block chain nodes obtain all transactions and related data that occur on the block chain network.
  • the established blockchain network can be used as the blockchain main network, and a blockchain subnet can be formed on the basis of the blockchain main network.
  • the consortium members can build the required blockchain subnet based on their own needs while already participating in the blockchain main network. Since the blockchain subnet is established on the basis of the blockchain main network, the construction process of the blockchain subnet is compared to the completely independent establishment of a blockchain network, the resources consumed and the time required, etc. Both are greatly reduced, and the flexibility is extremely high. On the one hand, it can meet the small-scale transaction needs among some node members, and on the other hand, it can conveniently realize the management of the blockchain subnet through the blockchain main network.
  • each blockchain node in the blockchain main network obtains the transaction to form a blockchain subnet respectively.
  • the transaction includes the configuration information of the blockchain subnet
  • the configuration information includes the identity information of the node members participating in the formation of the blockchain subnet.
  • each block chain node in the block chain main network respectively executes the above transactions to disclose the configuration information; wherein, when the configuration information contains the identity information of the node member corresponding to the first block chain node, deploying the first block
  • the node device of the chain node generates a genesis block containing configuration information based on the transaction, and starts a second blockchain node belonging to the blockchain subnet based on the genesis block.
  • the transaction to form a blockchain subnet can be initiated by the administrator of the blockchain main network, that is, only the administrator is allowed to establish a blockchain subnet on the basis of the blockchain main network, and avoid opening the blockchain subnet formation authority to normal users to prevent security issues resulting from this.
  • ordinary users of the blockchain main network can also be allowed to initiate the above-mentioned transaction of establishing a blockchain subnet to meet the networking needs of ordinary users, so that ordinary users can still initiate transactions when the administrator is inconvenient. It is possible to quickly form a blockchain subnet.
  • the blockchain main network is subnet0
  • the blockchain nodes contained in subnet0 are nodeA, nodeB, nodeC, nodeD, and nodeE.
  • the node members corresponding to nodeA, nodeB, nodeC and nodeD want to form a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate transactions to form a blockchain subnet, then nodeA can initiate the above-mentioned building blocks to subnet0 Chain subnet transactions; if nodeE is an administrator and only administrators are allowed to initiate the transaction of establishing a blockchain subnet, then nodeA ⁇ nodeD need to make a request to nodeE, so that nodeE initiates the above transaction of establishing a blockchain subnet to subnet0; if nodeE If you are an administrator but allow ordinary users to initiate a transaction to establish a blockchain subnet, then nodeA ⁇ nodeE can initiate the above transaction to subnet0 to establish a blockchain subnet.
  • the node members corresponding to the blockchain nodes that initiate the transaction of establishing a blockchain subnet do not necessarily participate in the established blockchain subnet, for example, although nodeA, nodeB, nodeC and nodeD Corresponding node members build a blockchain subnet, but nodeE can initiate the above-mentioned transaction of building a blockchain subnet to subnet0, and nodeA ⁇ nodeD do not necessarily initiate the transaction of building a blockchain subnet.
  • the blockchain main network in this specification can be the underlying blockchain network, that is, the blockchain main network is not a blockchain subnet formed on the basis of other blockchain networks, such as the subnet0 can be regarded as the blockchain mainnet belonging to the underlying blockchain network type.
  • the blockchain main network in this specification can be a subnet of other blockchain networks.
  • subnet1 can be considered as It is the blockchain main network corresponding to the blockchain subnet, and this does not affect that subnet1 also belongs to the blockchain subnet created on subnet0. It can be seen that the blockchain main network and the blockchain subnet are actually relative concepts. The same blockchain network can be the blockchain main network in some cases and the blockchain subnet in other cases.
  • the consensus nodes in the blockchain main network will conduct consensus, and after the consensus is passed, each blockchain node will execute the transaction to complete the block The formation of the chain subnet.
  • the consensus process depends on the adopted consensus mechanism, such as any consensus mechanism mentioned above, which is not limited in this specification.
  • the configuration information can be used to configure the established blockchain subnet so that the established blockchain subnet meets the networking requirements. For example, by including the identity information of the node members participating in the establishment of the blockchain subnet in the configuration information, it is possible to specify which node members the established blockchain subnet corresponds to.
  • the identity information of a node member may include a public key, or other information capable of characterizing the identity of a node member such as a node ID, which is not limited in this description.
  • a public key as an example, each blockchain node has one or more sets of corresponding public-private key pairs.
  • the blockchain node holds the private key and the public key is public and uniquely corresponds to the private key. Therefore, it can be passed
  • the public key is used to represent the identity of the corresponding blockchain node, and the public key can also be used to represent the identity of the node member corresponding to the blockchain node.
  • the public keys of the blockchain nodes corresponding to these node members on the blockchain main network can be added to the above-mentioned transaction of establishing a blockchain subnet as the above-mentioned nodes. Member's identity information.
  • the above-mentioned public-private key pair can be used in the process of signature verification.
  • nodeA1 in subnet1 uses its own private key to sign the message, and then broadcasts the signed message in subnet1, while nodeB1, nodeC1 and nodeD1 can use the public key of nodeA1 Signature verification is performed on the received message to confirm that the message received by itself is indeed from nodeA1 and has not been tampered with.
  • the first block chain node may be a block chain node corresponding to a node member indicated by the configuration information on the block chain main network.
  • the node device used to deploy the first blockchain node needs to generate a second blockchain node, and The second blockchain node participates in the formation of a blockchain subnet.
  • the first blockchain node and the second blockchain node correspond to the same node member, for example, in the consortium chain scenario, they correspond to the same consortium chain member, but the first blockchain node belongs to the blockchain main network and the second zone
  • the blockchain node belongs to the blockchain subnet, so that the node members can participate in the transactions of the blockchain main network and the blockchain subnet respectively; and, since the blockchain main network and the blockchain subnet belong to two independent Blockchain network, so that the blocks generated by the first blockchain node and the blocks generated by the second blockchain node are respectively stored in different storages on the node device (the storage used can be a database, for example), realizing
  • the storage used by the first blockchain node and the second blockchain node is isolated from each other, so the data generated by the blockchain subnet will only be synchronized between the blockchain nodes in the blockchain subnet, It makes the node members who only participate in the blockchain main network unable to obtain the data generated on the blockchain subnet, realizes the data isolation between the blockchain main network and the blockchain subnet, and satisfies
  • the first blockchain node and the second blockchain node are logically divided blockchain nodes, and from the perspective of physical equipment, it is equivalent to the deployment of the first blockchain node and the second blockchain node
  • the node device of the chain node participates in both the blockchain main network and the blockchain subnet. Since the blockchain main network and the blockchain subnet are independent of each other, the identity systems of the two blockchain networks are also independent of each other, so even if the first blockchain node and the second blockchain node can use exactly the same public key, the two should still be considered as different blockchain nodes.
  • nodeA in subnet0 is equivalent to the first blockchain node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, which is equivalent to the second blockchain node. It can be seen that since the identity systems are independent of each other, even if the public key used by the second blockchain node is different from that of the first blockchain node, it will not affect the implementation of the scheme of this specification.
  • the node members participating in the blockchain subnet are not necessarily only part of the node members participating in the blockchain main network.
  • the node members participating in the blockchain subnet can be completely consistent with the node members participating in the blockchain main network.
  • all node members can obtain the data on the blockchain main network and the blockchain subnet, but The data generated by the blockchain main network and the blockchain subnet can still be isolated from each other.
  • the two types of The business data generated by the business are isolated from each other.
  • the configuration information may also include at least one of the following: the network identifier of the blockchain subnet, the identity information of the administrator of the blockchain subnet, the The attribute configuration of the code, etc., is not limited in this manual.
  • the network identifier is used to uniquely represent the blockchain subnet, so the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets formed on the blockchain main network.
  • the identity information of the administrator of the blockchain subnet can be, for example, the public key of the node member who is the administrator; the administrators of the blockchain main network and the blockchain subnet can be the same or different.
  • One of the advantages of building a blockchain subnet through the blockchain main network is that since the first blockchain node has already been deployed on the node device that generates the second blockchain node, the first blockchain node can be The used blockchain platform code is reused on the second blockchain node, which eliminates the repeated deployment of the blockchain platform code and greatly improves the efficiency of the formation of the blockchain subnet.
  • the second blockchain node can reuse the attribute configuration adopted on the first blockchain node; if the configuration information includes the attribute configuration for the blockchain platform code
  • the attribute configuration of the code the second blockchain node can adopt this attribute configuration, so that the attribute configuration adopted by the second blockchain node is not limited to the attribute configuration of the first blockchain node, and the first blockchain node irrelevant.
  • the attribute configuration for the blockchain platform code can include at least one of the following: code version number, whether consensus is required, consensus algorithm type, block size, etc., which are not limited in this specification.
  • Transactions that form blockchain subnets include transactions that call contracts.
  • the transaction can specify the address of the called smart contract, the method called and the parameters passed in.
  • the invoked contract can be the aforementioned genesis contract or system contract
  • the invoked method can be a method for building a blockchain subnet
  • the incoming parameters can include the above-mentioned configuration information.
  • the structure of the Subnet system contract can contain the following information:
  • subnetId is used to indicate the subnet ID of the blockchain subnet
  • pubkeys is used to indicate the identity information of the subnet node of the blockchain subnet
  • subnetState is used to indicate the operating status of the blockchain subnet (start, stop, invalid, etc.)
  • genesis is used to represent the genesis block information of the blockchain subnet.
  • the above data can be stored in the contract state of the Subnet system contract.
  • Transactions used to form blockchain subnets can contain the following information:
  • the from field is the information of the initiator of the transaction.
  • Administrator indicates that the initiator is an administrator; the to field is the address of the called smart contract.
  • the smart contract can be a Subnet contract, and the to field is specifically the Subnet The address of the contract; the method field is the calling method.
  • the method used to build a blockchain subnet in the Subnet contract can be AddSubnet(string), and string is the parameter in the AddSubnet() method.
  • genesis is used to represent the The value of the parameter, the genesis is specifically the aforementioned configuration information.
  • nodeA ⁇ nodeE Take nodes nodeA ⁇ nodeE on Subnet0 executing a transaction calling the AddSubnet() method in the Subnet contract as an example. After the transaction passes the consensus, nodeA ⁇ nodeE respectively execute the AddSubnet() method and pass in the configuration information to obtain the corresponding execution results.
  • the execution result of the contract may include the configuration information, and the execution result may be included in the above-mentioned receipt, which may include an event related to the execution of the AddSubnet() method, that is, a networking event.
  • the topic of networking events can contain predefined networking event identifiers to distinguish them from other events.
  • the content of the topic is the keyword subnet, and this keyword is different from the topic in the event generated by other methods.
  • nodeA ⁇ nodeE or the node devices 1 ⁇ 5 deploying nodeA ⁇ nodeE can listen to the topic contained in each event in the receipt generated by monitoring, and can determine whether to listen to and execute AddSubnet( ) method-related events, that is, networking events.
  • the event in the receipt is as follows:
  • the content of the data field may include, for example:
  • subnet1 is the network identifier of the blockchain subnet you want to create.
  • Each blockchain node in the blockchain main network can record the network identifiers of all blockchain subnets that have been created on the blockchain main network, or other information related to these blockchain subnets, such information can be maintained in In the above-mentioned Subnet contract, it may specifically correspond to the values of one or more contract states included in the Subnet contract. Then, it can be determined whether the above-mentioned subnet1 already exists according to the recorded network identifiers of all created blockchain subnets; if it does not exist, it means that subnet1 is a new blockchain subnet that needs to be created currently, and if it exists, it means that subnet1 already exists.
  • a predefined new network identifier which indicates that the corresponding networking event is used to form a new blockchain subnet.
  • the above subnet1 can be replaced with newsubnet, which is a predefined new network identifier.
  • nodeA ⁇ nodeE recognizes that the data field contains newsubnet, they can determine that the event containing this newsubnet is a networking event, and a new one needs to be created.
  • Blockchain subnet When nodeA ⁇ nodeE recognizes that the data field contains newsubnet, they can determine that the event containing this newsubnet is a networking event, and a new one needs to be created.
  • the above data field also contains the identity information of each node member participating in the formation of the blockchain subnet.
  • the node device deploying the first blockchain node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event contains the identity information of the node member corresponding to the first blockchain node , the configuration information or genesis block contained in the networking event is acquired by the node device deploying the first blockchain node.
  • the first blockchain node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member, trigger the deployment of the first blockchain node.
  • a node device of a blockchain node obtains the configuration information or the genesis block included in the networking event.
  • node devices can listen for receipts directly. Assuming that nodeA ⁇ nodeE are respectively deployed on node devices 1 ⁇ 5, and node devices 1 ⁇ 5 can monitor the receipts generated by nodeA ⁇ nodeE respectively, then when it is detected that subnet1 is a blockchain subnet that needs to be newly established, node device 1 ⁇ 5 will further identify the identity information of the node members contained in the data field to determine its own processing method.
  • node device 1 Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as nodeA's public key, IP address, and port number, then node device 1 obtains configuration information from the data field based on the above message mechanism , generate a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and the nodeA1 will load the generated genesis block, thus becoming a subnet node of subnet1; similarly, node device 2 can generate nodeB1, node device 3 can generate nodeC1, and node device 4 can generate nodeD1. And, node device 5 will find that the identity information contained in the data field does not match itself, then the node device 5 will not generate a genesis block according to the configuration information in the data field, nor will it generate a blockchain node in subnet1.
  • identity information such as nodeA's public key, IP address, and port number
  • the blockchain nodes in the blockchain main network can monitor receipts and trigger node devices to perform related processing according to the monitoring results.
  • nodeA ⁇ nodeE will further identify the identity information of the node members contained in the data field in order to determine their own processing methods when they determine that subnet1 is a blockchain subnet that needs to be newly established.
  • nodeA ⁇ nodeD will find that the data field contains their own identity information such as their public key, IP address, and port number. Assume that nodeA ⁇ nodeD are deployed on node devices 1 ⁇ 4 respectively.
  • nodeA will Trigger node device 1 so that node device 1 generates a genesis block containing the configuration information when it obtains configuration information from the data field based on the above-mentioned message mechanism, and node device 1 will deploy nodeA1 locally, and nodeA1 will load the generated Genesis block, thus becoming a subnet node of subnet1; similarly, nodeB will trigger node device 2 to generate nodeB1, nodeC will trigger node device 3 to generate nodeC1, and nodeD will trigger node device 4 to generate nodeD1.
  • nodeE will find that the identity information contained in the data field does not match itself, assuming that nodeE is deployed on node device 5, then the node device 5 will not generate a genesis block based on the configuration information in the data field, nor will it generate subnet1 Blockchain nodes in .
  • the data field may contain identity information generated in advance for nodeA1-nodeD1, which is different from the identity information of nodeA-nodeD.
  • nodeA and node device 1 may contain identity information generated in advance for nodeA1-nodeD1, which is different from the identity information of nodeA-nodeD. Still take nodeA and node device 1 as an example: if node device 1 finds the identity information of nodeA1 in the data field, it can generate a genesis block, deploy nodeA1, and nodeA1 loads the genesis block; or, if nodeA is in the data field If the identity information of nodeA1 is found in , then nodeA will trigger node device 1 to generate a genesis block, deploy nodeA1, and nodeA1 will load the genesis block. The processing methods of other blockchain nodes or node devices are similar and will not be repeated here.
  • the execution result of the contract can include the genesis block.
  • the corresponding node devices 1-4 can directly obtain the genesis block from the data field through the message mechanism without generating it by themselves, which can improve the deployment efficiency of nodeA1-nodeD1.
  • the transaction of establishing a blockchain subnet may not be a transaction that calls a smart contract, so that a blockchain network that does not support smart contracts can also implement the technical solution of this specification, so that on the basis of the blockchain main network Quickly create a blockchain subnet.
  • a group of network transaction type identifiers can be pre-defined, and when the transaction contains the network transaction type identifier, it indicates that the transaction is used to form a new blockchain subnet, that is, the transaction is a transaction to form a blockchain subnet.
  • the blockchain platform code can contain relevant processing logic for building a blockchain subnet, so that when the first blockchain node running the blockchain platform code executes a transaction, if it finds that the transaction contains the above-mentioned networking
  • the transaction type is identified, and the identity information of the node members corresponding to the first blockchain node is included in the configuration information in the transaction.
  • the node device deploying the first blockchain node can be triggered to generate The genesis block of the information and start the second blockchain node, and the second blockchain node loads the genesis block to form a blockchain node in the blockchain subnet.
  • the node device implements the deployment of a blockchain node on the node device by creating an instance of running the blockchain platform code in the process.
  • the node device For the first blockchain node, it is formed by the node device creating and running the first instance of the blockchain platform code in the above process.
  • the second blockchain node it is formed by the node device creating and running the second instance of the blockchain platform code in the above process.
  • the node device can first create the first instance in the process to form the first blockchain node in the blockchain main network; In the above process, a second instance is created, which is different from the above-mentioned first instance, and the second instance forms a second blockchain node in the blockchain subnet.
  • the second instance may also be in different processes on the node device from the first instance, which is not limited in this specification.
  • the node device can create a first instance in the first process to form the first blockchain node in the blockchain main network; Start a second process different from the first process, and create a second instance in the second process, the second instance is different from the first instance above, and then form the second instance in the blockchain subnet from the second instance Blockchain nodes.
  • a blockchain subnet can be created on the blockchain mainnet.
  • subnet0 originally included nodeA ⁇ nodeE
  • subnet1 can be built on the basis of subnet0.
  • This subnet1 includes nodeA1 ⁇ nodeD1, and nodeA and nodeA1, nodeB and nodeB1, nodeC and nodeC1, nodeD and nodeD1 are respectively deployed in on the same node device.
  • subnet2 or more blockchain subnets can also be established on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeD and nodeD1, nodeE and nodeE2 are respectively deployed on the same node device.
  • subnet1, subnet2, etc. can be used as the new blockchain main network, and a blockchain subnet can be further formed on this basis. The process is similar to the formation of subnet1 or subnet2, and will not be repeated here.
  • a management relationship can be formed between the blockchain main network and the blockchain subnet, that is, the blockchain main network can manage the blockchain subnet.
  • a multi-layer blockchain system can also be formed based on the registration mechanism, and the management relationship between the blockchain networks can be established without resorting to the establishment process, and the blockchain network can be managed accordingly, so there is no need to Will be limited by how the blockchain network is set up.
  • each blockchain node in the first blockchain network receives the registration transaction, obtains the identity information of the second blockchain network from the registration transaction, and combines the obtained identity information of the second blockchain network with the distribution
  • the subnet identification of the second blockchain network is associated with the certificate, so as to register the second blockchain network as a subnet of the first blockchain network.
  • each blockchain node in the second blockchain network receives the anchor transaction, obtains the identity information of the first blockchain network and the subnet ID assigned to the second blockchain network from the anchor transaction, and sends
  • the acquired identity information of the first blockchain network and the subnet ID assigned to the second blockchain network are updated to the identity information of the second blockchain network to anchor the first blockchain network as the second The mainnet of the blockchain network.
  • the second blockchain network may not be established on the basis of the first blockchain network, so that the establishment of the second blockchain network There will be no management relationship with the first blockchain network.
  • this manual establishes the above-mentioned management relationship between the first blockchain network and the second blockchain network through the registration mechanism, so that the first blockchain network becomes the master of the second blockchain network. network and the second blockchain network become subnets of the first blockchain network.
  • the registration transaction can be initiated by the administrator of the second blockchain network, that is, only the administrator is allowed to register the second blockchain network as a subnet of other blockchain networks, and avoid opening the registration authority to ordinary members to prevent This leads to security issues.
  • ordinary members of the second blockchain network can also be allowed to initiate the above-mentioned registration transactions, so that ordinary members can still quickly complete the registration when it is inconvenient for the administrator to initiate transactions.
  • the first blockchain network is subnet0
  • the blockchain nodes contained in subnet0 are nodeA, nodeB, nodeC, nodeD, and nodeE.
  • corresponding blockchain subnets subnet1 and subnet2 are established to establish management relationships between subnet0 and subnet1, and between subnet0 and subnet2, so that subnet0 can control subnet1 and subnet2 for management.
  • subnet3 which includes blockchain nodes such as nodeK, nodeL, nodeM, and nodeN, and this subnet3 is not formed on the basis of subnet0.
  • nodeK is an administrator and only administrators are allowed to initiate registration transactions
  • nodeK can initiate the above registration transactions to subnet0
  • nodeN is an administrator and only administrators are allowed to initiate registration transactions
  • nodeK ⁇ nodeM need to make a request to nodeN, so that nodeN Initiate the above registration transaction to subnet0
  • nodeN is an administrator but allows ordinary users to initiate registration transactions
  • nodeK ⁇ nodeL can initiate the above registration transactions to subnet0.
  • this specification refers to this mechanism as a dynamic networking mechanism.
  • this mechanism when building blockchain subnets subnet1 and subnet2 on subnet0 as shown in Figure 5, it can be considered that subnet0 is in the first layer, and subnet1 and subnet2 are in the second layer.
  • this specification refers to this mechanism as a registration mechanism. For example, by registering subnet3 with subnet0 as shown in Figure 5, it can be considered that subnet0 is in the first layer and subnet3 is in the second layer.
  • the blockchain main network can be the underlying blockchain network, and the underlying blockchain network is not based on other blockchain networks.
  • network mechanism and the underlying blockchain network has not become a subnet of other blockchain networks through the registration mechanism, that is, the underlying blockchain network does not have a corresponding main network and is not subject to other blockchain networks.
  • Network management for example, subnet0 in Figure 5 can be considered as the blockchain main network of the underlying blockchain network type; or, the blockchain main network can also become the main network of other blockchain networks through a dynamic networking mechanism or a registration mechanism.
  • Subnet for example, on the basis of subnet1 (or subnet2, subnet3) in Figure 5, another blockchain subnet can be further formed through a dynamic networking mechanism, or another blockchain network can be registered as subnet1 (or subnet2, subnet3) At this time, subnet1 (or subnet2, subnet3) can be considered as the blockchain main network corresponding to the blockchain subnet, and this does not affect the subnet1 (or subnet2, subnet3) that also belongs to the blockchain subnet of subnet0 . It can be seen that the blockchain main network and the blockchain subnet are actually relative concepts. The same blockchain network can be the blockchain main network in some cases and the blockchain subnet in other cases.
  • each group of blockchain mainnets and blockchain subnets formed through dynamic networking mechanisms and registration mechanisms can be included at the same time, such as subnet1 and subnet2 in Figure 5 through
  • the dynamic networking mechanism becomes the subnet of subnet0
  • subnet3 becomes the subnet of subnet0 through the registration mechanism.
  • a multi-layer blockchain system may only include each group of blockchain mainnets and blockchain subnets formed through a dynamic networking mechanism, or only include each group of blockchains formed through a registration mechanism. Main network and blockchain subnet.
  • the above-mentioned registration transaction includes the transaction of calling the contract.
  • the transaction can specify the address of the called smart contract, the method called and the parameters passed in.
  • the called contract can be the aforementioned genesis contract or system contract
  • the called method can be a method for registering a blockchain subnet
  • the parameters passed in can include the identity information of the second blockchain network.
  • the transaction may contain the following information:
  • the from field is the information of the initiator of the transaction.
  • Administrator indicates that the initiator is an administrator;
  • the to field is the address of the called smart contract.
  • the smart contract can be a Subnet-M contract, and the to field is specifically The address of the Subnet-M contract;
  • the method field is the calling method.
  • the method used to register the blockchain subnet in the Subnet-M contract can be RegSubnet(string), and string is the parameter in the RegSubnet() method.
  • the value of this parameter is characterized by genesis, which is specifically the aforementioned identity information of the second blockchain network.
  • Each blockchain node in the first blockchain network executes the above-mentioned RegSubnet() method called by the registration transaction according to the received registration transaction, so as to assign the identity information of the second blockchain network to the second zone
  • the subnet identification of the block chain network is associated with the certificate, which is equivalent to the first block chain network registering the second block chain network as its own subnet.
  • the identity information of the second blockchain network may include: information of all blockchain nodes included in the second blockchain network.
  • the information of each blockchain node may include: node public key, node IP, node port number, etc., which is not limited in this specification.
  • the subnet identifier assigned to the second blockchain network that is, the subnet ID of the second blockchain network.
  • the method of generating the subnet ID is not limited in this specification, as long as it is guaranteed to be globally unique.
  • the subnet ID can be temporarily generated for the second blockchain network.
  • the subnet ID can be selected for the second blockchain network from the pre-formed ID pool.
  • the subnet ID can be generated by the second blockchain network itself, and passed to the RegSubnet() method together with the identity information of the second blockchain network via the above-mentioned genesis.
  • each blockchain node in the first blockchain network can generate corresponding execution results.
  • the execution result of the contract can include the above-mentioned subnet ID; especially, when the subnet ID is assigned by the first blockchain network rather than generated by the second blockchain network, it is necessary to use this method to Obtain the subnet ID assigned to the second blockchain network.
  • the execution result of the contract may include the aforementioned receipt, and the receipt may include events related to the execution of the RegSubnet() method, that is, subnet registration events.
  • the topic of the subnet registration event can contain a predefined subnet registration event identifier to distinguish it from other events.
  • the content of the topic is the keyword RegSubnet, and this keyword is different from the topic in the event generated by other methods.
  • the event in the receipt is as follows:
  • the subnetwork registration event may also include the identity information of the second blockchain network, so as to determine that the subnetwork registration event is indeed generated for the second blockchain network.
  • the subnet of the second blockchain network can be known ID. Therefore, the following anchoring transaction can be initiated to the second blockchain network accordingly to complete the anchoring of relevant information.
  • the above-mentioned subnet registration event can be monitored by the initiator of the registration transaction at the blockchain node in the first blockchain network, and then the initiator initiates an anchor transaction to the second blockchain network. It is also possible for objects other than the initiator of the registration transaction to monitor the subnetwork registration event, and then initiate an anchor transaction to the second blockchain network.
  • the initiator of the anchor transaction is not necessarily the same as the object that listens to the above-mentioned subnet registration event; Necessary association, can be selected as the same object or different objects according to the actual situation.
  • the registration transaction may not be a transaction that invokes a smart contract, so that a blockchain network that does not support smart contracts can also implement the technical solution of this specification, so that the identity information and
  • the subnet ID assigned to the second blockchain network is associated with the certificate.
  • a subnet registration transaction type identifier can be pre-defined. When the transaction contains the subnet registration transaction type identifier, it indicates that the transaction is used to register a new blockchain subnet, that is, the transaction is a registration transaction.
  • the blockchain platform code can contain relevant processing logic for registering blockchain subnets, so that when the first blockchain node running the blockchain platform code executes a transaction, if it finds that the transaction contains the above-mentioned subnetwork
  • the identity information of the second blockchain network and the subnet identifier assigned to the second blockchain network can be associated and deposited based on the above processing logic.
  • the subnet identifier assigned to the second blockchain network can be included in the registration transaction; or, the blockchain platform code can also include the logic of assigning the subnet identifier, so that the blockchain platform code can send the registration transaction to The second blockchain network assigns a corresponding subnetwork ID.
  • the consensus nodes in the first blockchain network will carry out a consensus, and after the consensus is passed, each blockchain node will execute the transaction, so that the second blockchain The network is registered as a subnet of itself.
  • the consensus process depends on the adopted consensus mechanism, such as any consensus mechanism mentioned above, which is not limited in this specification.
  • the consensus nodes in the second blockchain network will carry out consensus, and after passing the consensus, each blockchain node will execute the transaction, so as to Anchor the first blockchain network as its own main network.
  • the consensus process depends on the adopted consensus mechanism, such as any consensus mechanism mentioned above, which is not limited in this specification.
  • the identity information of the second blockchain network can be compared to the second blockchain network.
  • the management relationship between a blockchain network and a second blockchain network is anchored. Combined with the identity information of the second blockchain network stored in the first blockchain network and its subnet identification, mutual authentication and cross-validation are realized between the first blockchain network and the second blockchain network, Ensure that the management relationship between the first blockchain network and the second blockchain network is recognized by both parties, and subsequent management operations can be implemented based on this management relationship.
  • the anchor transaction can be initiated by the administrator of the second blockchain network.
  • ordinary members of the second blockchain network can also be allowed to initiate the above-mentioned anchor transaction, so that ordinary members can quickly complete the anchor even if the administrator is inconvenient to initiate the transaction.
  • the above-mentioned anchor transactions include transactions that call contracts.
  • the transaction can specify the address of the called smart contract, the method called and the parameters passed in.
  • the called contract can be the genesis contract or the system contract in the second blockchain network
  • the called method can be the method of anchoring the blockchain main network
  • the parameters passed in can include the first blockchain network’s Identity information and a subnet ID assigned to the second blockchain network.
  • the transaction may contain the following information:
  • the from field is the information of the initiator of the transaction.
  • Administrator indicates that the initiator is an administrator;
  • the to field is the address of the called smart contract.
  • the smart contract can be a Subnet-S contract, and the to field is specifically The address of the Subnet-S contract;
  • the method field is the calling method, for example, the method used to anchor the blockchain mainnet in the Subnet-S contract can be AnchSubnet(string), and string is the parameter in the AnchSubnet() method , in the above example, the value of this parameter is characterized by genesis, which is specifically the aforementioned identity information of the first blockchain network and the subnet ID assigned to the second blockchain network.
  • Each blockchain node in the second blockchain network executes the above-mentioned AnchSubnet() method called by the anchor transaction according to the received anchor transaction, so as to assign the identity information of the first blockchain network to the second blockchain network.
  • the subnet identification of the second blockchain network is updated to the identity information of the second blockchain network, which is equivalent to the second blockchain network registering the first blockchain network as its own main network.
  • the second blockchain network can maintain its own identity information through the world state in the Subnet-S contract, so the above-mentioned update of the identity information of the second blockchain network can actually include calling the Subnet-S contract And update the above-mentioned state of the world that maintains the identity information.
  • the identity information of the first blockchain network may include at least one of the following: information of all blockchain nodes contained in the first blockchain network, a network identifier of the first blockchain network, and the like.
  • the information of each blockchain node may include: node public key, node IP, node port number, etc., which is not limited in this manual.
  • a management relationship mutually recognized by both parties has been established between the first blockchain network and the second blockchain network.
  • This management relationship makes the first blockchain network a second district
  • the main network of the block chain network and the second block chain network become subnets of the first block chain network, then the first block chain network can implement corresponding management operations on the second block chain network based on the management relationship.
  • the management operations described above may include the routing of blockchain messages. For example, if any blockchain node in the first blockchain network receives a blockchain message, and the blockchain message contains the subnet ID assigned to the second blockchain network, then because the first block The chain network has registered the identity information of the second blockchain network and its subnet identifier, so that the blockchain node can query the identity information of the second blockchain network according to the subnet identifier contained in the blockchain message, And forward the block chain message to the second block chain network. It can be seen that based on the establishment of the above-mentioned management relationship, the first blockchain network can route blockchain messages to the second blockchain network, which helps to improve the success rate of blockchain message transmission.
  • the first blockchain network can be used as the object’s
  • the message transmission relay between the second blockchain network helps to improve the transmission rate and success rate of blockchain messages.
  • the above-mentioned blockchain messages may include various types of messages such as blockchain transactions, block data, and consensus messages, which are not limited in this specification.
  • Each blockchain node in the first blockchain network can also record the operating status of the second blockchain network, for example, the operating status can include an available status, a deactivated status, a suspended status, and the like. Then, when any blockchain node in the first blockchain network receives the above blockchain message and determines that the blockchain message contains the subnet ID of the second blockchain network, it can further Query the running status of the second blockchain network, so that the blockchain message is forwarded when the second blockchain network is in an available state, otherwise it may not be forwarded to save network resources.
  • the aforementioned management operations may include direct management of the second blockchain network.
  • the second blockchain network can be managed by initiating a management transaction for the second blockchain network to the first blockchain network.
  • the initiator of the management transaction can be, for example, the administrator of the first blockchain network, and of course it can be other objects.
  • each blockchain node in the first blockchain network can receive a management transaction, obtain the subnet ID and management instruction assigned to the second blockchain network from the management transaction, and send the management instruction to the second blockchain network.
  • Two blockchain networks; specifically, the identity information of the corresponding subnet can be queried based on the subnet ID in the management transaction, for example, when the identity information of the second blockchain network is queried, a management instruction.
  • each blockchain node in the second blockchain network executes the management instruction to complete the corresponding management operation when it is determined that the management instruction is sent by its corresponding main network.
  • management instructions can be transmitted to the second blockchain network in various ways.
  • the management instruction may be included in the subnetwork management event generated by the first blockchain network executing the management transaction, and the subnetwork management event includes the above-mentioned management instruction and the subnetwork identifier included in the management transaction.
  • the second blockchain network monitors the subnetwork management event containing its own subnetwork identifier, it can be determined that the management instruction contained in the subnetwork management event is managed for itself.
  • the node device where any blockchain node in the first blockchain network is located can monitor the above-mentioned subnetwork management event, and according to the subnetwork identification contained in the subnetwork management event, report to the second blockchain network Send management instructions.
  • the first blockchain network may send management instructions to the second blockchain network through a cross-chain mechanism in related technologies during the process of executing the above-mentioned management transaction.
  • the above management instructions can be used to implement at least one of the following: changing the operating status of the second blockchain network, managing the blockchain nodes contained in the second blockchain network, defining business rules for the second blockchain network, Changes to the functional components used by the second blockchain network, etc., are not limited by this specification.
  • the management instruction is used to change the running state of the second blockchain network, for example, the running state of the second blockchain network can be switched among available state, suspended state and deactivated state.
  • the management instruction is used to manage the blockchain nodes included in the second blockchain network, for example, the blockchain nodes included in the second blockchain network may be added or deleted.
  • the management instruction is used to define the business rules of the second blockchain network, the business rules of the second blockchain network can be added, deleted or modified.
  • the business rules here can include, for example, that the second blockchain network supports decoding The data format of the blockchain message, the contract deployment authority, contract call authority, and contract upgrade authority on the second blockchain network, the data that needs to be interacted and stored in the second blockchain network to the first blockchain network, etc. .
  • the management instruction is used to change the functional components used by the second blockchain network
  • the functional components here are formed by each blockchain node in the second blockchain network running the blockchain platform code, for example, it may include consensus components, Privacy protection components, cross-chain components, off-chain confidential computing components, subnet management components, etc.
  • management instructions can be used to add or delete functional components used by the second blockchain network, or change the functional components used by it, such as changing the consensus The consensus algorithm adopted by the components, etc.
  • different blockchain networks can be constructed to store different types of business data.
  • there is a need for interaction between different blockchain networks so that some complex businesses can be realized through cross-chain interaction.
  • a blockchain subnet managed by the blockchain mainnet needs to write data on another blockchain subnet managed by the blockchain mainnet when performing business, such as depositing certificate data or modifying the other subnet
  • the world state of the blockchain subnet when a blockchain subnet managed by the blockchain mainnet needs to write data on another blockchain subnet managed by the blockchain mainnet when performing business, such as depositing certificate data or modifying the other subnet
  • the block chain subnet is used as the source block chain subnet
  • the other block chain subnet is used as the target block chain subnet.
  • a subnet node in the chain subnet (that is, a target subnet node) sends a cross-subnet request for writing data to implement cross-subnet data writing.
  • permission control can be performed on cross-subnet write data, such as controlling the blockchain subnet that allows data to be written, and controlling the type of cross-subnet write operations, etc.
  • the permission control process of cross-subnetwork interaction between the source blockchain subnet and the destination blockchain subnet will be described in detail below in conjunction with FIG. 6 .
  • FIG. 6 is a flow chart of a cross-subnet interaction permission control method provided by an exemplary embodiment. As shown in FIG. 6, the method is applied to a blockchain system, and the blockchain system includes a blockchain main network and a blockchain subnet managed by it; the method may include the following steps.
  • Step 602 the destination subnetwork node in the destination blockchain subnet receives the cross-subnet request sent by the source subnetwork node in the source blockchain subnet, the cross-subnet request includes writing to the destination blockchain subnet Enter the operation information of the operation.
  • Different blockchain subnets are used to perform different business operations, or to store different business data, and some businesses require multiple types of business data or require multiple business operations to be jointly realized, then in the process of completing the business
  • a blockchain subnet may initiate cross-subnet interaction to write data (and possibly read data) in one or more other blockchain subnets.
  • the writing operation may include writing into a smart contract deployed on the target blockchain subnet, or writing into a block of the target blockchain subnet, and the like.
  • the specific form of the writing operation can be flexibly set according to the actual situation, which is not limited in this description.
  • cross-subnet interaction may be initiated through the above-mentioned message mechanism.
  • the source blockchain subnet receives the first blockchain transaction, and the first blockchain transaction is used to call the smart contract deployed on the source blockchain subnet to complete a certain business, and the business needs to Write data on the chain subnet, then the source blockchain subnet responds to the first blockchain transaction submitted to the source blockchain subnet, executes the smart contract invoked by the first blockchain transaction to generate operation information (such as for Parameters indicating how to perform the write operation) event, after the subnet node in the source blockchain subnet listens to the event, it reads the operation information contained in the event to generate a cross-subnet request (that is, a cross-subnet request contains the operational information for the write operation).
  • operation information such as for Parameters indicating how to perform the write operation
  • subnet a and subnet b are blockchain subnets of subnet 0 of the blockchain main network
  • the business contracts deployed on subnet a are used to provide membership services for users
  • subnetb is used to store user membership information.
  • subnet a wants to register a new user as a member
  • the registered member needs to record the user's ID number, and the user's ID number is stored by subnet b.
  • the user can initiate a blockchain transaction calling the business contract to subnet a, and the blockchain transaction includes the contract address of the business contract, the subnet ID of subnet b, ID number and other information.
  • subnet a is used as the source blockchain subnet
  • subnet b is used as the destination blockchain subnet.
  • subnet a executes the business contract to generate an event containing operation information (indicating that the ID number is written on subnet b), and the subnet node in subnet a generates a cross-subnet request containing the operation information after listening to the event And send to the subnet node in subnet b.
  • Step 604 the destination subnetwork node queries the permission information of each blockchain subnetwork managed by the blockchain main network for the write operation of the destination blockchain subnetwork, and according to the permission information The operation information is verified.
  • permission information for write operations on the blockchain subnet can be configured for the blockchain subnet to implement permission control over cross-subnet write services, such as controlling the permission to write data Blockchain subnets, and control the type of cross-subnet write operations, etc.
  • the authority control dimension of the authority information may include at least one of the following: the subnet identifier of the blockchain subnet that initiates the cross-subnet request, the blockchain account of the blockchain subnet that initiates the write operation, the request The blockchain account of the blockchain subnet to be written, and the parameter type of the request to write.
  • the way of configuring permission information for the blockchain subnet it can be through the blockchain main network or the blockchain subnet itself managed by it.
  • the first write control contract for recording permission information can be deployed on each blockchain subnet, that is, the first write control contract on each blockchain subnet records the Permission information for network write permission control.
  • a smart contract is deployed on subnet a to record which subnets can write data on subnet a and the permission information of what kind of data to write.
  • subnet b is deployed to record which subnets can be written on A smart contract for writing data on subnet b and the permission information of what kind of data to write.
  • write permission control is performed by the blockchain subnet itself.
  • the destination subnet node when the destination subnet node queries the permission information of each blockchain subnet of the blockchain main network for the write operation of the destination blockchain subnet, it can query the first write operation deployed on the destination blockchain subnet. Control the permission information recorded by the contract.
  • the destination subnetwork node queries the first write control contract in real time, since the query operation will not affect the world state of the destination blockchain subnetwork, the destination subnetwork node can create a local query transaction (1ocal query transaction) to Query the permission information recorded in the first write control contract in the locally stored world state corresponding to the destination blockchain subnet.
  • a subnet caching strategy can be adopted.
  • the cache may be pre-configured to be specially used to store permission information of the first write control contract record.
  • storage resources can be allocated as the cache on the node device to which the target subnet node belongs; or, the cache can also be set on other devices (for example, a database server is specially set). Then, the destination subnetwork node can query the authority information stored in the preset cache to perform the verification operation.
  • the subnet nodes in each destination subnet can use the above method of creating local query transactions to Query the permission information of the first write control contract record.
  • the administrator of the blockchain system can change the permission information recorded in the first write control contract as needed. For example, the administrator can initiate an update transaction for the authority information to the above-mentioned destination subnet (that is, call the first write control contract to update the authority information, including the corresponding update information), and the first write control contract responds to the update of the authority information
  • an update event (including update information) can be generated, and then the destination subnetwork node can update the predetermined Set cache.
  • a second write control contract for recording permission information can be deployed on the blockchain mainnet that manages the blockchain subnet, that is, it is used to control the permission to write data on each blockchain subnet Information is recorded and maintained in the second write control contract deployed on the blockchain mainnet.
  • the blockchain main network subnet 0 manages the subnet subnet a-subnet c
  • the second writing control contract can be deployed on subnet 0, which respectively records the permission information.
  • the blockchain main network controls the write permission of the blockchain subnet it manages.
  • the target subnetwork node queries the permission information of each blockchain subnetwork of the blockchain mainnet for the write operation of the target blockchain subnetwork, it can query the second write operation deployed on the blockchain mainnet. Control the permission information recorded by the contract.
  • the node equipment that deploys the main network nodes in the blockchain main network is also used for Deploy the subnet node of the blockchain subnet, and the main network node and subnet node deployed on any node device share the blockchain plug-in of any node device, so that the subnet node can query the main network node through the blockchain plug-in Data maintained about the blockchain mainnet.
  • the target subnet node can deploy the block chain plug-in in the target node device of the target subnet node (that is, the node device to which the target subnet node belongs), and the main network node deployed on the target node device locally stores In the world state corresponding to the blockchain main network, query the permission information recorded in the second write control contract.
  • the second writing control contract can be the above-mentioned Subnet system contract (i.e. subnet management contract)
  • the blockchain plug-in can be SubnetPlugin
  • the main network node can call SubnetPlugin to query the information of the blockchain subnet maintained by the Subnet system contract (Node ID, node public key, communication address, etc., are maintained in the contract state of the subnet management contract of the blockchain main network), and stored in the memory as a share between the blockchain main network and the corresponding blockchain subnet section for inquiries.
  • the destination subnet node can call the SubnetPlugin to query the above permission information.
  • the target blockchain subnet can also be a blockchain subnet registered to the blockchain main network through the above registration mechanism.
  • the target subnet node in the target blockchain subnet can submit a query transaction to the blockchain main network, and the query transaction is used to instruct the blockchain main network to query the Subnet system contract (that is, the subnet management contract) The above permission information recorded.
  • the permission information recorded in the first write control contract and the second write control contract will be described with examples below.
  • the write operation controlled by the write control contract includes creating an account (CreateAccount), transferring money (TransferBalance), calling a contract (CallContract), and so on.
  • the form of permission information can be as follows:
  • the subnet ID indicates the id of the source subnet that can be written to the destination subnet;
  • the transaction attribute indicates the attribute of the transaction that the source subnet can create on the destination subnet;
  • the original account indicates that the source subnet can initiate a write operation on the source subnet account;
  • the target account means the account that can be written into the target subnet;
  • the function in the contract means that when the target account is a contract account, it is allowed to control the method in the contract account.
  • the permission information can also be in the form of a white list, which can be flexibly set according to actual needs, which is not limited in this manual.
  • step 606 the destination subnet node responds to the cross-subnet request if the verification is passed, and executes a corresponding write operation according to the operation information.
  • the master node of the target blockchain subnet (for example, the target blockchain subnet uses the PBFT algorithm for consensus, then the master node can be selected through the PBFT consensus algorithm) in response to the cross-subnet request to create the second Second block chain transaction, and initiate the second block chain transaction in the destination block chain subnet.
  • the subnetwork nodes in the target block chain subnet respond to the second block chain transaction and execute corresponding writing operations according to the operation information.
  • the permission information can be used when other blockchain subnets request to write data to the blockchain subnet Verify the cross-subnet request that requests to write data, and then execute the write operation on the premise that the verification passes, so as to ensure the security of the blockchain subnet data and realize the permission control of the cross-subnet write service. For example, control the blockchain subnets that allow data to be written, and control the type of cross-subnet write operations, etc.
  • digital envelopes can be used to encrypt blockchain messages (such as the above-mentioned operation information) transmitted by cross-subnet requests.
  • the encryption method of the digital envelope combines a symmetric encryption algorithm and an asymmetric encryption algorithm.
  • the source subnetwork node encrypts the blockchain message to be transmitted with its own symmetric key, and adds the encrypted blockchain message to the cross-subnetwork request.
  • the source subnet node encrypts the symmetric key with the node public key of the destination node, and adds the encrypted symmetric key to the cross-subnet request.
  • the destination node after receiving the cross-subnet request, the destination node first uses its own node private key to decrypt the symmetric key in ciphertext form contained in the cross-subnet request to obtain the symmetric key in plaintext form, and then passes This symmetric key decrypts blockchain messages included in cross-subnet requests.
  • the source subnetwork nodes in the source blockchain subnet can send cross-subnet requests to each destination node in the destination blockchain subnet, so that each destination node Respond to cross-subnet requests.
  • the destination nodes in the destination blockchain subnet can receive cross-subnet requests to respond, thereby further ensuring that the source zone
  • the block chain subnet can successfully obtain the response result of the target block chain subnet to the cross-subnet request.
  • the source subnet nodes in the source blockchain subnet can use the node public key of each destination node in the destination blockchain subnet to encrypt their own symmetric keys, and encrypt Each obtained symmetric key is added to the cross-subnet request, and then the source subnet node sends the cross-subnet request to each destination node in the destination blockchain subnet.
  • the destination node after the destination node receives the cross-subnet request, it first uses its own node private key to decrypt the symmetric keys in the form of ciphertext contained in the cross-subnet request, and can decrypt the public key of the node using the destination node.
  • the symmetric key encrypted with the key is successfully decrypted, and then the blockchain message contained in the cross-subnet request is decrypted by the successfully decrypted symmetric key.
  • the unified creation method for cross-subnet requests can be guaranteed, the operation of creating cross-subnet requests can be simplified, and the source subnet node can avoid creating cross-subnet requests.
  • differential processing is performed for each destination node, for example, only the node public key of each destination node is used to encrypt the symmetric key, and added to the cross-subnet request to be sent to the corresponding destination node.
  • the blockchain message transmitted by the cross-subnet request can be an event generated by the source blockchain subnet during the execution of the smart contract.
  • the service initiator can initiate the first blockchain transaction to call the smart contract to the source blockchain subnet, and the first blockchain transaction indicates that the target zone The network identifier of the block chain subnet.
  • the target block chain subnet has the pending data of the smart contract.
  • the source subnet node can respond to the first blockchain transaction, execute the smart contract to create a blockchain message and add it to the cross-subnet request, and the blockchain message is used to instruct the destination blockchain subnet to return the smart contract pending data.
  • the source subnet node in subnet a after the source subnet node in subnet a receives the blockchain transaction, it can execute the business contract to generate an event, which contains the following fields:
  • request_id request id
  • src_subnet_id source blockchain subnet ID
  • method the method to call
  • timestamp timestamp.
  • the source subnet node in the source blockchain subnet subnet a listens to the above event, it signs the event by calling the SM message component at the Signature Message layer (message signature layer) to authenticate the identity of the source subnet node.
  • the node_id field is used to store the node ID of the source subnet node
  • the msg field is used to store the above fields included in the monitored event
  • the sign field is used to store the content stored in the mag field by the source subnet node using its own node private key Signature data obtained by signing.
  • the data obtained in the Signature Message layer is encrypted by calling the Envelope message component in the form of a digital envelope.
  • the source subnetwork nodes in the source blockchain subnetwork subnet a can randomly generate their own symmetric key K (each source subnetwork node can use the same or different symmetric keys), and then use the symmetric key K
  • the contents of the above node_id field, msg field and sign field are encrypted and stored in the encry_data field.
  • the node public keys of the subnet nodes in each blockchain subnet are maintained.
  • the source subnet node in the source blockchain subnet subnet a can query the node public key of each subnet node in subnet b maintained in the Subnet system contract through the subnet ID of the destination blockchain subnet b, and then use The public key of each node encrypts the symmetric key used by itself to obtain multiple symmetric keys en_key1, en_key2, en_key3, etc. in the form of ciphertext (in the figure, the target blockchain subnet subnet b contains 3 target subnet nodes as example), and stored in the encrypted_key field.
  • the data obtained by the Envelope Message layer is encapsulated into a cross-subnet request by calling the P2P message component. Specifically, the contents of the encrypted_key field and the encry_data field are stored in the data field.
  • the cross-subnet request also contains the following fields:
  • src_subnet_id Indicates the source blockchain subnet ID
  • dest_subnet_id Indicates the ID of the destination blockchain subnet
  • msg_type Indicates the request type identifier of the cross-subnet request.
  • the source subnet node in the source blockchain subnet subnet a can query the address information of each subnet node in subnet b maintained in the Subnet system contract through the subnet identifier of the destination blockchain subnet b After the subnet request, send a cross-subnet request to each subnet node in the destination blockchain subnet subnet b according to the address information.
  • the cross-subnet request can also be broadcast, and the receiver can judge whether it needs to respond to the received cross-subnet request according to the dest_subnet_id field.
  • the subnet nodes in the destination blockchain subnet subnet b are used as the destination subnet nodes, and the received cross-subnet requests are also processed in the above layers in sequence.
  • the target subnet node uses its own node private key to decrypt the symmetric keys in the form of encrypted text stored in the encrypted_key field, and can successfully decrypt the symmetric key encrypted with the node public key of the target subnet node, and then Then decrypt the blockchain message stored in the encry_data field through the successfully decrypted symmetric key to obtain the contents of the node_id field, msg field, and sign field. At this point, the validity of the source subnet node and the validity of the signature can be verified.
  • the node ID and node public key of each subnet node in the corresponding blockchain subnet maintained in the Subnet system contract can be queried according to the src_subnet_id of the cross-subnet request. Then, it is judged whether the queried node identifier includes the node identifier stored in the node_id field, and when the queried node identifier includes the node identifier stored in the node_id field, it is determined that the validity check of the source subnet node is passed.
  • the content stored in the msg field can be read to respond. For example, perform corresponding operations according to the instructions stored in the method field and args field, read the pending data required by the smart contract, and then return the pending data to the sender of the received cross-subnet request.
  • subnet b is used as the source blockchain subnet
  • subnet a is used as the destination blockchain subnet. The process of cross-subnet interaction is similar to the above, and will not be repeated here.
  • the source subnetwork nodes are controlled by using the hierarchical relationship between the source blockchain subnet and the destination blockchain subnet corresponding to the same blockchain main network.
  • Identity verification does not require the introduction of other additional components (such as using cross-chain relays, notaries, etc. to achieve data interaction between the two subnets, additional configuration components are required), and the verification process makes full use of the above-mentioned hierarchical relationship Features, the destination subnet node only needs to directly query the node identity information of the source subnet node to the blockchain main network, which can make the verification operation easier under the premise of accurately verifying the identity of the source subnet node to ensure data security , lightweight and efficient.
  • the source subnetwork node can receive the cross-subnetwork response returned by the destination subnetwork node (for example, including the result obtained by executing the above write operation), and In this process, the legitimacy and effectiveness of cross-chain interactions between blockchain subnets should be guaranteed, so as to prevent adverse effects caused by nodes doing evil.
  • the process of auditing after the source subnetwork node receives the cross-subnetwork response will be described in detail below.
  • FIG. 7 is a flow chart of an audit method for cross-chain interaction provided by an exemplary embodiment. As shown in Fig. 7, the method may include the following steps.
  • Step 702 the source subnetwork node obtains the cross-subnetwork response returned by each destination subnetwork node in response to the cross-subnetwork request, according to the main network node deployed on the node device where the source subnetwork node is located
  • the target block chain subnet node list maintained by a block height performs signature verification and Byzantine fault tolerance verification on the obtained cross-subnet response, and the standard cross-subnet response and the first A block height is constructed as a reconstruction reply.
  • At least one source subnet node in the source blockchain subnet initiates a cross-chain request to the destination blockchain subnet, including: a source subnet node in the source blockchain subnet sends a request to the destination blockchain subnet A destination subnet node in the network sends a cross-chain request, so that the destination subnet node further broadcasts the cross-chain request in the destination blockchain network so that each destination subnet node in the destination blockchain subnet Obtain the cross-chain request, and the response return party required by the cross-chain request is each source subnetwork node in the source blockchain subnet; or, a source subnetwork node in the source blockchain subnet sends the destination block All destination subnet nodes in the chain subnet send cross-chain requests respectively, and the response return party required by the cross-chain request is each source subnet node in the source blockchain subnet; or, each source subnetwork node in the source blockchain subnet A source subnet node sends a cross-chain request to a destination subnet node in the destination
  • At least one source subnet node in the source blockchain subnet initiates a cross-chain request to the destination blockchain subnet, including: at least one source subnet node in the source blockchain subnet
  • the cross-subnet contract is invoked to send the cross-chain request to the target subnet nodes.
  • the source subnet node can trigger a cross-chain request for the destination blockchain subnet due to a cross-chain demand generated by the business contract, and call the source subnet through a local transaction
  • the cross-subnet contract deployed on the node after receiving the cross-chain request, the cross-subnet contract further encapsulates and calls the communication plug-in deployed on the node device where the source subnet node is located to send the cross-chain request to the target block chain The corresponding source subnetwork node in the network.
  • the local transaction involved in the embodiment of this specification does not participate in the transaction of the blockchain consensus, and is only used as a local internal calling medium of the node; the cross-subnet contract involved in the embodiment of this specification maintains each block managed by the blockchain main network The communication address of the chain subnet, participate in the encapsulation of cross-chain messages and call the local communication plug-in to realize the function of cross-chain interaction.
  • the obtained cross-chain response is performed according to the target block chain subnet node list maintained by the main network node deployed on the node device where the source subnet node is located at the first block height.
  • Signature verification and Byzantine fault-tolerant verification including: according to the public key corresponding to each destination subnet node contained in the destination blockchain subnet node list, perform the response signature information corresponding to the obtained cross-chain response Signature verification; in the case that the cross-chain responses with the same content in the obtained cross-chain responses exceed (greater than) the first preset number and the corresponding response signature information is successfully verified, send the cross-chain responses with the same content One of them is determined to be a standard cross-chain response that has successfully verified the signature and passed the Byzantine fault tolerance check.
  • each destination subnet node After receiving the cross-chain request, each destination subnet node will not only return the cross-chain response for the cross-chain request, but also generate the response signature information corresponding to the cross-chain response based on its own node private key and return it to the source Subnet node, therefore, the source subnet node can determine the validity of any cross-chain response by verifying the response signature information corresponding to any cross-chain response.
  • the target block chain subnet node list involved in the embodiment of this specification includes the node member information of the target block chain subnet, such as node ID, node public key, communication address, etc., and the target block chain subnet node list is maintained in the block In the contract state of the subnet management contract of the chain main network, since the contract state will change with the update of the chain time (block height), the source subnet node is using the destination block chain subnet node list to verify the signature Before checking with Byzantine fault tolerance, it is necessary to specify which block height the destination block chain node list is anchored to.
  • the source subnetwork node can first determine the first block height, and then specify the block chain mainnet at The target block chain subnet node list maintained at the first block height is the target block subnet node list for subsequent signature verification and Byzantine fault tolerance verification.
  • the source subnet node obtains the target blockchain subnet node list maintained on the blockchain main network by accessing the main network node deployed on the node device where it is located.
  • the first preset number is determined by the total number of first nodes corresponding to the target blockchain subnet contained in the target blockchain subnet node list. Specifically, in the Byzantine fault-tolerant check for cross-chain responses, it is assumed that the total number of first nodes corresponding to the destination blockchain subnet, that is, the number of all destination subnet nodes contained in the destination blockchain subnet is 3a( a is a positive integer), then the first preset quantity should be a.
  • the first block height is the block height of the latest block maintained by the main network node when the source subnetwork node performs signature verification and Byzantine fault tolerance check on the obtained cross-chain response ; or, the first block height is the block height of the target block selected by the source sub-network node from the blocks maintained by the main network node according to the preset block selection rules.
  • the source subnet node determines the height of the first block, it can be determined as the latest block maintained by the main network node when the source subnet node performs signature verification and Byzantine fault tolerance check on the obtained cross-chain response.
  • Block height which can ensure that the source subnetwork node uses the latest target blockchain subnetwork node list when performing signature verification and Byzantine fault tolerance verification, but because the source subnetwork node obtains the destination zone maintained on the blockchain main
  • the block chain subnet node list is realized by accessing the main network nodes deployed on the node device where the source subnet nodes are located, and the main network nodes deployed on the node devices where different source subnet nodes are located may have differences in the latest block height , so for different source subnetwork nodes, the target blockchain subnetwork node lists obtained by them may not be consistent, which leads to the Byzantine fault tolerance check of the verification sum of the cross-chain response by the source subnetwork node process is not reliable.
  • the source subnetwork node determines the height of the first block, it can select the block height of the target block from the blocks maintained by the main network node according to the preset block selection rules, such as block
  • the selection rules may include: when the consensus time of the latest block maintained by the main network node exceeds the sending time of the cross-chain request, first select the consensus time from the blocks maintained by the main network node that does not exceed the at least one block at the time of sending, and then select the block with the highest block height from the at least one block as the target block.
  • the sending time of the cross-chain request is a unified parameter known to all source subnetwork nodes in the source block chain subnetwork
  • the consensus time of the latest block maintained by the mainnet node exceeds the cross-chain request.
  • the sending time of the chain request it means that the blocks whose consensus time is before the sending time have been fixed, and other main network nodes in the blockchain main network also maintain these fixed blocks.
  • the target blocks selected based on uniform rules such as selecting the block with the largest block height
  • each source subnetwork node is selected based on the above block selection rules to obtain The target block must be consistent, and the height of the first block is the block height corresponding to the target block, then the height of the first block determined by each source subnetwork node must be consistent, so that it can overcome different source The problem that the target blockchain subnet node lists obtained by the subnet nodes are inconsistent.
  • Step 704 the source subnetwork node broadcasts the reconstruction response in the source blockchain subnetwork, and receives reconstruction responses broadcast by other subnetwork nodes in the source blockchain subnetwork.
  • each source subnetwork node After each source subnetwork node performs signature verification and Byzantine fault tolerance check on the cross-chain response received by itself, it will determine to obtain a standard cross-chain response, and compare the standard cross-chain response with the height of the first block Constructed as a reconstruction response, and then broadcast the reconstruction response in the source blockchain subnet, so that every source subnet node except itself can obtain the reconstruction response, and at the same time, other sources will also be accepted Reconstruction response broadcast by subnetwork nodes. In order for the verifier to confirm the legitimacy of the reconstruction response, each source subnet node will also sign the reconstruction response based on its own node private key to obtain the corresponding consensus signature information after constructing the corresponding reconstruction response , and broadcast the corresponding consensus signature information when broadcasting the reconstruction response. Each reconstruction response can reflect the source subnetwork node that generated it based on which block height the target block chain subnetwork node list is used to perform signature verification and Byzantine fault tolerance check on the cross-chain response.
  • Step 706 the source subnetwork node performs signature verification and Byzantine fault-tolerant verification on the obtained reconstruction response according to the source block chain subnetwork node list, and determines the reconstruction response that has successfully verified the signature and passed the Byzantine fault-tolerant verification as An authentication reply in response to the cross-subnet request.
  • the source subnetwork node After the source subnetwork node receives several reconstruction responses broadcast by other source subnetwork nodes, it will determine the authentication response from the reconstruction responses received by these broadcasts and the reconstruction responses generated by itself. Specifically, the source subnetwork node selects the reconstruction response that passes the Byzantine fault tolerance check from the obtained reconstruction responses, including: , performing signature verification on the consensus signature information corresponding to the obtained reconstruction response; in the obtained reconstruction response, the reconstruction responses with the same content exceed the second preset number and the corresponding consensus signature information is successfully verified Next, one of the reconstruction responses with the same content is determined as the authentication response.
  • the source block chain subnet node list involved in the embodiment of this specification includes the node member information of the source block chain subnet, such as node ID, node public key, communication address, etc., the source block chain subnet node list and the target block subnet
  • the network node list is similar and can also be maintained in the contract status of the subnet management contract of the blockchain main network. Therefore, before the source subnet node uses the source blockchain subnet node list for signature verification and Byzantine fault tolerance verification, it also It is necessary to specify which block height the source blockchain node list is anchored to. For example, the source subnetwork node can first determine the second block height, and then specify the blockchain main network at the second block height.
  • the maintained source block chain subnet node list is the list of source block subnet nodes that will be used for signature verification and Byzantine fault tolerance verification in the future.
  • the source subnetwork node obtains the list of source blockchain subnetwork nodes maintained on the blockchain mainnet by accessing the mainnet node deployed on the node device where it is located.
  • the source blockchain subnet node list can also be maintained in the node member information maintained by the source subnet node itself, and the node membership information will also change with the update of the block height of the source blockchain subnet.
  • the second preset number is determined by the total number of second nodes corresponding to the source blockchain subnet included in the source blockchain subnet node list. Specifically, in the Byzantine fault-tolerant check for the reconstruction response, it is assumed that the total number of second nodes corresponding to the source blockchain subnet, that is, the number of all source subnetwork nodes contained in the source blockchain subnet is 3b( b is a positive integer), then the second preset quantity should be b.
  • the reconstruction response also includes a second block height, which is the value maintained by the source blockchain subnetwork or the main network node when the source subnetwork node constructs the reconstruction response.
  • the block height of the latest block, and the second block height is used to obtain the source blockchain subnet node list during the audit process.
  • the reconstruction response will not only include the first block height used to obtain the node list of the target blockchain subnet, but also include the second block height used to obtain the node list of the source blockchain subnet.
  • the source subnetwork node can directly count the height of the second block in the reconstructed response obtained without signature verification, and determine the height of the second block with the majority and the same content as the final source block The block height of the list of chain subnets.
  • the source subnetwork node In the case that the second block height is the block height of the latest block maintained by the main network node when the source subnetwork node constructs the reconstruction response, the source subnetwork node directly obtains The deployed main network node obtains the list of source blockchain subnet nodes maintained by the main network node at the second block height; when constructing a reconstruction response for the source subnet node at the second block height, the source block In the case of the block height of the latest block maintained by the chain subnetwork, the source subnetwork node obtains the source blockchain subnetwork node list maintained by itself at the second block height.
  • Step 708 the source subnetwork node responds to the cross-subnetwork request, the authentication response, the response signature information corresponding to all cross-subnetwork responses that have successfully verified the signature and passed the Byzantine fault tolerance check, and the signature information that has passed the Byzantine fault tolerance verification and passed the Byzantine fault tolerance
  • the consensus signature information corresponding to all the reconstructed responses verified will be stored as evidence.
  • the source subnetwork node can send the response signature information corresponding to the cross-chain request, the authentication response, all cross-chain responses that have successfully verified the signature and passed the Byzantine fault tolerance verification, and all the reconstructions that have passed the Byzantine fault tolerance verification and have successfully verified the signature
  • the consensus signature information corresponding to the response is stored in the communication plug-in deployed on the node device, the cross-subnet contract maintained by itself, and/or the business contract that triggers the call of the cross-subnet contract for cross-chain interaction, so that it can be provided to other
  • the authenticator verifies the validity of the authentication response of the cross-chain request.
  • the source subnetwork node will perform signature verification and Byzantine verification based on the cross-chain response returned by each destination subnetwork node in response to the cross-chain request, so as to ensure that the cross-chain response is credible.
  • different source subnetwork nodes The list of destination blockchain subnet nodes used for signature verification and Byzantine verification may be different, which makes it impossible for a single source subnet node to ensure the validity of its own signature verification and Byzantine verification.
  • the source subnetwork node will also combine the determined standard cross-chain response and the height of the first block to form a reconstruction response, and perform a consensus check based on the Byzantine fault tolerance principle inside the source subnetwork, so that the source subnetwork can finally determine A reconstruction response jointly approved by all source subnet nodes in the source blockchain subnet is issued as the authentication response of the cross-chain request, thus solving the inconsistency of the target blockchain subnet node lists determined by different source subnet nodes The problem of untrustworthiness has been solved, and reliable and supervised cross-chain communication has been completed while ensuring the decentralization of the blockchain.
  • the response signature information corresponding to the cross-chain request, the authentication response, all cross-chain responses that have successfully verified the signature and passed the Byzantine fault-tolerant verification, and all the reconstruction responses that have successfully verified the signature and passed the Byzantine fault-tolerant verification correspond to
  • the deposit of the consensus signature information also enables the verifier to provide credible verification for a cross-chain request in the future, ensuring that the entire process data in the cross-chain process is traceable, traceable and verifiable.
  • the method further includes: the source subnetwork node calling a callback method in the cross-subnetwork contract, and returning the authentication response to the service contract.
  • the cross-subnet contract is invoked by the business contract and triggers the processing logic of cross-chain interaction
  • the authentication response will be based on the cross-subnet contract
  • the callback method returns to the business contract.
  • the callback method can use the aforementioned local transaction method to return the local transaction carrying the authentication response to the business contract, so that the business contract can obtain the corresponding cross-chain requirements. data.
  • the source subnet node can also call the callback method in the cross-subnet contract, and the response signature information corresponding to all cross-chain responses that have successfully verified the signature and passed the Byzantine fault-tolerant verification and passed the Byzantine fault-tolerant
  • the consensus signature information corresponding to all verified reconstruction responses is returned to the business contract, so that the business contract can verify the legitimacy of the entire process of cross-chain interaction and authentication responses.
  • the cross-chain response returned in response to the cross-chain request includes description information of the cross-chain request, wherein the description information of the cross-chain request includes the request identifier of the cross-chain request or the Cross-chain requests.
  • the destination subnetwork node in order to make the association between the cross-chain response received by the source subnetwork node and the cross-chain request credible, the destination subnetwork node can be made to carry the cross-chain request in the returned cross-chain response. Descriptive information or the cross-chain request itself.
  • the method further includes: the source subnetwork node obtains the The request signature information returned by the cross-chain request, the request signature information is obtained by signing the cross-chain request containing the request identifier by the destination subnetwork nodes respectively; the source subnetwork node according to the destination zone
  • the block chain subnet node list performs signature verification and Byzantine fault-tolerant verification on the request signature information, and determines the association between the cross-chain request and the request identifier when the signature verification is successful and the Byzantine fault-tolerant verification is passed believable.
  • the cross-chain response can include the description information of the cross-chain request.
  • the description information itself has a strong correlation with the cross-chain request, for example, the description information is the cross-chain request or the hash value corresponding to the cross-chain request
  • the correlation between the description information corresponding to the cross-chain request and the cross-chain request does not need additional proof, but if there is only a weak correlation between the description information and the cross-chain request, for example, the description information corresponding to the cross-chain request is the cross-chain request
  • the corresponding request identifier the source subnetwork node allocates and maintains the corresponding relationship between the request identifier and the cross-chain request
  • the correlation between the description information corresponding to the cross-chain request and the cross-chain request is unreliable , you need to provide additional trust credentials.
  • the destination subnetwork node responds to the received cross-chain request containing the request identifier. At this time, the destination subnetwork node will not only return the cross-chain response, but also return the cross-chain request according to its own node private key.
  • the request signature information obtained by signing the request after the source subnetwork node receives several request signature information returned by each destination subnetwork node, it can verify the signature of the several request signature information according to the list of destination blockchain subnetwork nodes, and When it is determined that the decrypted value (the decrypted value obtained by decrypting the request signature information using the node public key of the destination subnet node) with the same content obtained by the signature verification exceeds the first preset number, and the decrypted value is the cross-chain request or In the case of the hash value corresponding to the cross-chain request, it is determined that the signature information of the request is successfully verified and passed the Byzantine fault tolerance check.
  • the cross-chain request containing the corresponding request identifier is recognized by each destination subnet node, therefore In this case, it can be determined that the association between the cross-chain request and the request identifier is credible, so that the verifier can detect based on the request signature information that the source subnetwork node maintains a wrong link between the request identifier and the cross-chain request.
  • the corresponding relationship between them can prevent the problem of dishonesty caused by node mutiny or error in the source blockchain subnet.
  • the source subnetwork node will perform signature verification and Byzantine verification based on the cross-chain response returned by each destination subnetwork node in response to the cross-chain request, so as to ensure that the cross-chain response is credible.
  • different source subnetwork nodes The list of destination blockchain subnet nodes used for signature verification and Byzantine verification may be different, which makes it impossible for a single source subnet node to ensure the validity of its own signature verification and Byzantine verification.
  • the source subnetwork node will also combine the determined standard cross-chain response and the height of the first block to form a reconstruction response, and perform a consensus check based on the Byzantine fault tolerance principle inside the source subnetwork, so that the source subnetwork can finally determine A reconstruction response jointly approved by all source subnet nodes in the source blockchain subnet is issued as the authentication response of the cross-chain request, thus solving the inconsistency of the target blockchain subnet node lists determined by different source subnet nodes The problem of untrustworthiness has been solved, and reliable and supervised cross-chain communication has been realized under the guarantee of the decentralization of the blockchain.
  • the response signature information corresponding to the cross-chain request, the authentication response, all cross-chain responses that have successfully verified the signature and passed the Byzantine fault-tolerant verification, and all the reconstruction responses that have successfully verified the signature and passed the Byzantine fault-tolerant verification correspond to
  • the deposit of the consensus signature information also enables the verifier to provide credible verification for a cross-chain request in the future, ensuring that the entire process data in the cross-chain process is traceable, traceable and verifiable.
  • this specification also provides corresponding device embodiments.
  • Fig. 8 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • the device includes a processor 802 , an internal bus 804 , a network interface 806 , a memory 808 and a non-volatile memory 810 , and of course it may also include hardware required by other services.
  • the processor 802 reads a corresponding computer program from the non-volatile memory 810 into the memory 808 and executes it.
  • one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each A logic unit, which can also be a hardware or logic device.
  • the permission control device for cross-subnet interaction can be applied to the device shown in FIG. 8 to realize the technical solution of this specification.
  • the device may include: a receiving unit 91, so that the destination subnet node in the destination blockchain subnet of the blockchain main network receives the cross-link sent by the source subnet node in the source blockchain subnet of the blockchain main network.
  • the cross-subnet request includes operation information for the write operation of the target block chain subnet; query unit 92 makes the target subnet node query each block of the block chain main network Chain subnet for the permission information of the write operation of the target block chain subnet, and verify the operation information according to the permission information; the writing unit 93 makes the target subnet node pass the verification Under certain circumstances, in response to the cross-subnet request, perform a corresponding write operation according to the operation information.
  • a typical implementing device is a computer, which may take the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control device, etc. desktops, tablets, wearables, or any combination of these.
  • a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory, such as read-only memory (ROM) or flash memory (flashRAM). Memory is an example of computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flashRAM flash memory
  • Computer-readable media including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information.
  • 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 Disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices.
  • computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.
  • first, second, third, etc. may be used in one or more embodiments of the present specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of the present specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word “if” as used herein may be interpreted as “at” or "when” or "in response to a determination.”

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种跨子网交互的权限控制方法及装置、电子设备、存储介质。该方法应用于区块链系统,区块链系统包括区块链主网及其管理的区块链子网,方法包括:目的区块链子网中的目的子网节点接收源区块链子网中的源子网节点发送的跨子网请求,跨子网请求包括针对目的区块链子网的写入操作的操作信息;目的子网节点查询区块链主网所管理的各个区块链子网针对目的区块链子网的写入操作的权限信息,并根据权限信息对操作信息进行校验;目的子网节点在校验通过的情况下响应于跨子网请求,根据操作信息执行相应的写入操作。

Description

跨子网交互的权限控制 技术领域
本说明书一个或多个实施例涉及区块链技术领域,尤其涉及一种跨子网交互的权限控制方法及装置、电子设备、存储介质。
背景技术
区块链技术构建在传输网络(例如点对点网络)之上。区块链网络中的节点利用链式数据结构来验证与存储数据,并采用分布式节点共识算法来生成和更新数据。可组建不同的区块链网络来存证不同类型的业务数据。在该场景下,不同的区块链网络之间存在交互的需求,从而通过跨链交互来实现一些复杂的业务。
尤其是,区块链网络可以自身为主网,基于一定的规则来动态创建子网。那么,不同区块链子网之间可能有数据交互、跨子网写服务的需求。
发明内容
有鉴于此,本说明书一个或多个实施例提供一种跨子网交互的权限控制方法及装置、电子设备、存储介质。
为实现上述目的,本说明书一个或多个实施例提供技术方案如下:根据本说明书一个或多个实施例的第一方面,提出了一种跨子网交互的权限控制方法,应用于区块链系统,所述区块链系统包括区块链主网及其管理的区块链子网;所述方法包括:目的区块链子网中的目的子网节点接收源区块链子网中的源子网节点发送的跨子网请求,所述跨子网请求包括针对所述目的区块链子网的写入操作的操作信息;所述目的子网节点查询所述区块链主网所管理的各个区块链子网针对所述目的区块链子网的写入操作的权限信息,并根据所述权限信息对所述操作信息进行校验;所述目的子网节点在校验通过的情况下响应于所述跨子网请求,根据所述操作信息执行相应的写入操作。
根据本说明书一个或多个实施例的第二方面,提出了一种跨子网交互的权限控制装置,包括:接收单元,使区块链主网的目的区块链子网中目的子网节点接收所述区块链主网的源区块链子网中源子网节点发送的跨子网请求,所述跨子网请求包括针对所述目的区块链子网的写入操作的操作信息;查询单元,使所述目的子网节点查询所述区块链主网的各个区块链子网针对所述目的区块链子网的写入操作的权限信息,并根据所述权限信息对所述操作信息进行校验;写入单元,使所述目的子网节点在校验通过的情况下响应于所述跨子网请求,根据所述操作信息执行相应的写入操作。
根据本说明书一个或多个实施例的第三方面,提出了一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器通过运行所述可执行指令以实现如上述任一实施例中所述的方法。
根据本说明书一个或多个实施例的第四方面,提出了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如上述实施例中任一所述方法的步骤。
由上述实施例可见,在区块链主网管理多个区块链子网的应用场景下,不同区块链子网之间存在跨子网写服务的需求,即某一业务的实现需要一个区块链子网在另一区块链子网上写入数据。对此,通过预先针对区块链子网配置针对该区块链子网的写入操作的权限信息,可在其他区块链子网请求对该区块链子网写入数据的情况下,利用该权限信息对请求写入数据的跨子网请求进行校验,以在校验通过的前提下再执行写入操作,从而保证区块链子网数据的安全性,实现对跨子网写服务的权限控制,比如控制允许写入数据的区块链子网,以及控制跨子网写操作的类型等等。
附图说明
图1是一示例性实施例提供的一种创建智能合约的示意图。
图2是一示例性实施例提供的一种调用智能合约的示意图。
图3是一示例性实施例提供的一种创建和调用智能合约的示意图。
图4是一示例性实施例提供的一种基于区块链主网组建区块链子网的示意图。
图5是一示例性实施例提供的一种将区块链网络注册为区块链子网的示意图。
图6是一示例性实施例提供的一种跨子网交互的权限控制方法的流程图。
图7是一示例性实施例提供的一种跨链交互的审计方法的流程图。
图8是一示例性实施例提供的一种设备的结构示意图。
图9是一示例性实施例提供的一种跨子网交互的权限控制装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是:在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。
区块链一般被划分为三种类型:公有链(Public Blockchain),私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外,还有多种类型的结合,比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表,加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。而且,各参与者(即节点)可自由加入以及退出网络,并进行相关操作。私有链则相反,该网络的写入权限由某个组织或者机构控制,数据读取权限受组织规定。简单来说,私有链可以为一个弱中心化系统,参与节点具有严格限制且少。这种类型的区块链更适合于特定机构内部使用。联盟链则是介于公有链以及私有链之间的区块链,可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织;参与者通过授权加入网络并组成利益相关联盟,共同维护区块链运行。
不论是公有链、私有链还是联盟链,都可能提供智能合约的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。
以以太坊为例,支持用户在以太坊网络中创建并调用一些复杂的逻辑,这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM),每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机,这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上,虚拟机直接运行的是虚拟机代码(虚拟机字节码,下简称“字节码”)。部署在区块链上的智能合约可以是字节码的形式。
例如图1所示,Bob将一个包含创建智能合约信息的交易发送到以太坊网络后,节点1的EVM可以执行这个交易并生成对应的合约实例。图1中的“0x6f8ae93...”代表了这个合约的地址,交易的data字段保存的可以是字节码,交易的to字段为空。节点间通过共识机制达成一致后,这个合约成功创建,并且可以在后续过程中被调用。合约创建后,区块链上出现一个与该智能合约对应的合约账户,并拥有一个特定的地址,合约代码将保存在该合约账户中。智能合约的行为由合约代码控制。换句话说,智能合约使得区块链上产生包含合约代码和账户存储(Storage)的虚拟账户。
如图2所示,仍以以太坊为例,Bob将一个用于调用智能合约的交易发送到以太坊网络后,某一节点的EVM可以执行这个交易并生成对应的合约实例。图2中交易的from字段是交易发起方(即Bob)的账户的地址,to字段中的“0x6f8ae93...”代表了被调用的智能合约的地址,value字段在以太坊中是以太币的值,交易的data字段保存的调用智能合约的方法和参数。调用智能合约后,balance的值可能改变。后续,某个客户端可以通过某一区块链节点(例如图2中的节点6)查看balance的当前值。智能合约以规定的方式在区块链网络中每个节点独立的执行,所有执行记录和数据都保存在区块链上,所以当交易完成后,区块链上就保存了无法篡改、不会丢失的交易凭证。
创建智能合约和调用智能合约的示意图如图3所示。以太坊中要创建一个智能合约,需要经过编写智能合约、编译成字节码、部署到区块链等过程。以太坊中调用智能合约,是发起一笔指向智能合约地址的交易,智能合约代码分布式的运行在以太坊网络中每个节点的虚拟机中。
需要说明的是,除了可以由用户创建智能合约,也可以在创世块中由系统设置智能合约。这类合约一般称为创世合约。一般的,创世合约中可以设置一些区块链网络的数据结构、参数、属性和方法。此外,具有系统管理员权限的账户可以创建系统级的合约,或者修改系统级的合约(简称为系统合约)。另外除了以太坊中的EVM外,不同的区块链网络还可能采用各种的虚拟机,这里并不限定。
区块链网络中的节点在执行调用智能合约的交易后,会生成相应的收据(receipt),以用于记录与执行该智能合约相关的信息。这样,可以通过查询交易的收据来获得合约执行结果的相关信息。合约执行结果可以表现为收据中的事件(event)。消息机制可以通过收据中的事件实现消息传递,以触发区块链节点执行相应的处理。事件的结构譬如可以为:
Event:
[topic][data]
[topic][data]
......
在上述示例中,事件的数量可以为一个或多个;其中,每个事件分别包括主题(topic) 和数据(data)等字段。区块链节点可以通过监听事件的topic,从而在监听到预定义的topic的情况下,执行预设处理,或者从相应事件的data字段读取相关内容,以及可以基于读取的内容执行预设处理。
上述的事件机制中,相当于在监听方(比如存在监听需求的用户)处存在具有监听功能的客户端,譬如该客户端上运行了用于实现监听功能的SDK等,由该客户端对区块链节点产生的事件进行监听,而区块链节点只需要正常生成收据即可。除了上述的事件机制之外,还可以通过其他方式实现交易信息的透出。例如,可以通过在区块链节点运行的区块链平台代码中嵌入监听代码,使得该监听代码可以监听区块链交易的交易内容、智能合约的合约状态、合约产生的收据等其中的一种或多种数据,并将监听到的数据发送至预定义的监听方。由于监听代码部署于区块链平台代码中,而非监听方的客户端处,因而相比于事件机制而言,这种基于监听代码的实现方式相对更加的主动。其中,上述的监听代码可以由区块链平台的开发人员在开发过程中加入区块链平台代码,也可以由监听方基于自身的需求而嵌入,本说明书并不对此进行限制。
区块链技术区别于传统技术的去中心化特点之一,就是在各个节点上进行记账,或者称为分布式记账,而不是传统的集中式记账。区块链系统要成为一个难以攻破的、公开的、不可篡改数据记录的去中心化诚实可信系统,需要在尽可能短的时间内做到分布式数据记录的安全、明确及不可逆。不同类型的区块链网络中,为了在各个记录账本的节点中保持账本的一致,通常采用共识算法来保证,即前述提到的共识机制。例如,区块链节点之间可以实现区块粒度的共识机制,比如在节点(例如某个独特的节点)产生一个区块后,如果产生的这个区块得到其它节点的认可,其它节点记录相同的区块。再例如,区块链节点之间可以实现交易粒度的共识机制,比如在节点(例如某个独特的节点)获取一笔区块链交易后,如果这笔区块链交易得到其他节点的认可,认可该区块链交易的各个节点可以分别将该区块链交易添加至自身维护的最新区块中,并且最终能够确保各个节点产生相同的最新区块。共识机制是区块链节点就区块信息(或称区块数据)达成全网一致共识的机制,可以保证最新区块被准确添加至区块链。当前主流的共识机制包括:工作量证明(Proof of Work,POW)、股权证明(Proof of Stake,POS)、委任权益证明(Delegated Proof of Stake,DPOS)、实用拜占庭容错(Practical Byzantine Fault Tolerance,PBFT)算法,HoneyBadgerBFT算法等。
由于区块链网络的去中心化特性,区块链网络中的所有节点处于对等地位,使得区块链网络中的所有区块链节点均会维护相同的区块数据,但一些节点有时存在实现小范围交易的需求,避免其他节点获得这些交易及其相关数据,导致无法满足部分节点的特殊需求。以联盟链为例,所有联盟成员(即联盟内的节点成员)可以组成一区块链网络,所有联盟成员在该区块链网络中分别存在对应的区块链节点,并可以通过对应的区块链节点获得该区块链网络上发生的所有交易和相关数据。但在一些情况下,可能存在部分联盟成员希望完成一些具有保密需求的交易,这些联盟成员既希望这些交易能够在区块链上存证或借助于区块链技术的其他优势,又能够避免其他联盟成员查看到这些交易和相关数据。虽然这些联盟成员可以额外组建一新的区块链网络,其建立方式与上述包含所有联盟成员的区块链网络类似,但是从头开始建立一条新的区块链网络需要消耗大量的资源,且无论是该区块链网络的建立过程或是建成后的配置过程都非常耗时。联盟成员之间的需求往往是临时的或者具有一定的时效性,使得新建的区块链网络很快就会由于需求消失而失去存在的意义,从而进一步增加了上述区块链网络的建链成本。而联盟成员之间的需求经常会变化,而每一需求所对应的联盟成员也往往不同,因而每当联盟成员发生变化时就可能需要组建一新的区块链网络,从而造成资源和时间的大量浪费。
对此,可以将已组建的区块链网络作为区块链主网,并在该区块链主网的基础上组建区块链子网。那么,在诸如上述的联盟链场景下,联盟成员可以在已经参与区块链主网的情况下,基于自身需求而在区块链主网的基础上组建所需的区块链子网。由于区块链子网是在区块链主网的基础上所建立,使得区块链子网的组建过程相比于完全独立地组建一条区块链网络,所消耗的资源和所需的耗时等都极大地降低,灵活性极高。一方面可满足一些节点成员之间的小范围交易需求,另一方面可以通过区块链主网便捷地实现对区块链子网的管理。
具体而言,区块链主网中的各区块链节点分别获取组建区块链子网的交易。其中,该交易包含区块链子网的配置信息,该配置信息包括参与组建区块链子网的节点成员的身份信息。然后,区块链主网中的各区块链节点分别执行上述交易以透出该配置信息;其中,当配置信息包含第一区块链节点对应的节点成员的身份信息时,部署第一区块链节点的节点设备基于该交易生成包含配置信息的创世块,并基于创世块启动属于区块链子网的第二区块链节点。
组建区块链子网的交易可由区块链主网的管理员发起,即仅允许管理员在区块链主 网的基础上组建区块链子网,而避免将区块链子网的组建权限开放给普通用户,以防止由此导致的安全性问题。在一些情况下,也可以允许区块链主网的普通用户发起上述组建区块链子网的交易,以满足普通用户的组网需求,使得普通用户能够在管理员不便于发起交易的情况下依然能够快捷地组建区块链子网。
以图4所示为例,区块链主网为subnet0,该subnet0包含的区块链节点为nodeA、nodeB、nodeC、nodeD和nodeE等。假定分别对应nodeA、nodeB、nodeC和nodeD的节点成员希望组建一区块链子网:如果nodeA为管理员且仅允许管理员发起组建区块链子网的交易,那么可由nodeA向subnet0发起上述组建区块链子网的交易;如果nodeE为管理员且仅允许管理员发起组建区块链子网的交易,那么nodeA~nodeD需要向nodeE进行请求,使得nodeE向subnet0发起上述组建区块链子网的交易;如果nodeE为管理员但允许普通用户发起组建区块链子网的交易,那么nodeA~nodeE均可以向subnet0发起上述组建区块链子网的交易。当然,不论是管理员或者普通用户,发起组建区块链子网的交易的区块链节点对应的节点成员并不一定参与所组建的区块链子网,比如虽然最终由nodeA、nodeB、nodeC和nodeD分别对应的节点成员组建区块链子网,但可由nodeE向subnet0发起上述组建区块链子网的交易,而并不一定由nodeA~nodeD来发起该组建区块链子网的交易。
在区块链主网的基础上组建区块链子网时,容易理解的是,会使得该区块链子网与区块链主网之间存在逻辑上的层次关系。比如在图4所示的subnet0上组建区块链子网subnet1时,可以认为subnet0处于第一层、subnet1处于第二层。一种情况下,本说明书中的区块链主网可以为底层区块链网络,即区块链主网并非在其他区块链网络的基础上组建的区块链子网,比如图4中的subnet0可以认为属于底层区块链网络类型的区块链主网。另一种情况下,本说明书中的区块链主网可以为其他区块链网络的子网,比如可以在图4中subnet1的基础上进一步组建另一区块链子网,此时可以认为subnet1为该区块链子网对应的区块链主网,而这并不影响该subnet1同时属于subnet0上创建的区块链子网。可见,区块链主网与区块链子网实际上是相对概念,同一区块链网络在一些情况下可以为区块链主网、另一些情况下可以为区块链子网。
上述组建区块链子网的交易在被发送至区块链主网后,由区块链主网内的共识节点进行共识,并在通过共识后由各区块链节点执行该交易,以完成区块链子网的组建。共识过程取决于所采用的共识机制,譬如上文所述的任一共识机制,本说明书并不对此进行限制。
通过在上述组建区块链子网的交易中包含配置信息,该配置信息可以用于对所组建的区块链子网进行配置,使得组建的区块链子网符合组网需求。例如,通过在配置信息中包含参与组建所述区块链子网的节点成员的身份信息,可以指定组建的区块链子网对应于哪些节点成员。
节点成员的身份信息可以包括公钥,或者采用节点ID等其他能够表征节点成员的身份的信息,本说明书并不对此进行限制。以公钥为例,每个区块链节点都存在对应的一组或多组公私钥对,由区块链节点持有私钥而公钥被公开且唯一对应于该私钥,因而可以通过公钥来表征相应区块链节点的身份,也可以通过该公钥来表征该区块链节点对应的节点成员的身份。因此,对于希望参与组建区块链子网的节点成员,可以将这些节点成员在区块链主网上对应的区块链节点的公钥添加至上述组建区块链子网的交易中,以作为上述节点成员的身份信息。上述的公私钥对可以用于签名验证的过程。例如,在采用有签名的共识算法中,譬如subnet1上述的nodeA1采用自身维护的私钥对消息进行签名后,将经过签名的消息在subnet1中广播,而nodeB1、nodeC1和nodeD1可以用nodeA1的公钥对收到的消息进行签名验证,以确认自身收到的消息确实来自nodeA1且没有经过篡改。
第一区块链节点可以为区块链主网上属于配置信息所指示的节点成员对应的区块链节点。在组建区块链子网时,并非由第一区块链节点直接参与组建区块链子网,而是需要由用于部署该第一区块链节点的节点设备生成第二区块链节点,并由第二区块链节点参与组建区块链子网。第一区块链节点和第二区块链节点对应于同一个节点成员,比如在联盟链场景下对应于同一联盟链成员,但第一区块链节点属于区块链主网、第二区块链节点属于区块链子网,使得该节点成员可以分别参与到区块链主网和区块链子网的交易中;并且,由于区块链主网和区块链子网属于相互独立的两个区块链网络,使得第一区块链节点生成的区块与第二区块链节点生成的区块分别存入所述节点设备上的不同存储(采用的存储譬如可以为数据库),实现了第一区块链节点与第二区块链节点分别使用的存储之间的相互隔离,因而区块链子网所产生的数据仅会在区块链子网中的各个区块链节点之间同步,使得仅参与了区块链主网的节点成员无法获得区块链子网上产生的数据,实现了区块链主网与区块链子网之间的数据隔离,满足了部分节点成员(即参 与区块链子网的节点成员)之间的交易需求。
第一区块链节点和第二区块链节点是在逻辑上划分出来的区块链节点,而从物理设备的角度来说,相当于上述部署了第一区块链节点和第二区块链节点的节点设备同时参与了区块链主网和区块链子网。由于区块链主网与区块链子网之间相互独立,使得这两个区块链网络的身份体系也相互独立,因而即便第一区块链节点和第二区块链节点可以采用完全相同的公钥,仍然应当将两者视为不同的区块链节点。譬如在图4中,subnet0中的nodeA相当于第一区块链节点,而部署该nodeA的节点设备生成了属于subnet1的nodeA1,该nodeA1相当于第二区块链节点。可见,由于身份体系相互独立,所以即便第二区块链节点所采用的公钥区别于第一区块链节点,也不影响本说明书方案的实施。
当然,参与区块链子网的节点成员并不一定只是参与区块链主网的节点成员中的一部分。在一些情况下,参与区块链子网的节点成员可以与参与区块链主网的节点成员完全一致,此时所有的节点成员都可以获得区块链主网和区块链子网上的数据,但是区块链主网与区块链子网所产生的数据依然可以相互隔离,比如可以通过在区块链主网上实现一类业务、在区块链子网上实现另一类业务,从而可以使得这两类业务分别产生的业务数据之间相互隔离。
除了上述的节点成员的身份信息之外,配置信息还可以包括下述至少之一:所述区块链子网的网络标识、所述区块链子网的管理员的身份信息、针对区块链平台代码的属性配置等,本说明书并不对此进行限制。网络标识用于唯一表征该区块链子网,因而该区块链子网的网络标识应当区别于区块链主网和该区块链主网上组建的其他区块链子网。区块链子网的管理员的身份信息,譬如可以为作为管理员的节点成员的公钥;其中,区块链主网与区块链子网的管理员可以相同,也可以不同。
通过区块链主网来组建区块链子网的优势之一,就是由于生成第二区块链节点的节点设备上已经部署了第一区块链节点,因而可以将第一区块链节点所使用的区块链平台代码复用在第二区块链节点上,免去了区块链平台代码的重复部署,极大地提高了区块链子网的组建效率。那么,如果配置信息中未包含针对区块链平台代码的属性配置,第二区块链节点可以复用第一区块链节点上采用的属性配置;如果配置信息中包含了针对区块链平台代码的属性配置,第二区块链节点可以采用该属性配置,使得第二区块链节点所采用的属性配置不受限于第一区块链节点的属性配置、与第一区块链节点无关。针对区块链平台代码的属性配置可以包括下述至少之一:代码版本号、是否需要共识、共识算法类型、区块大小等,本说明书并不对此进行限制。
组建区块链子网的交易包括调用合约的交易。该交易中可以指明被调用的智能合约的地址、调用的方法和传入的参数。例如,调用的合约可以为前述的创世合约或系统合约,调用的方法可以为组建区块链子网的方法,传入的参数可以包括上述的配置信息。
举例而言,Subnet系统合约的结构可以包含如下信息:
struct SubnetInfo{
uint subnetId;
bytes[]pubkeys;
SubnetState subnetState;
string genesis;
}
其中,subnetId用于表示区块链子网的子网标识;pubkeys用于表示区块链子网的子网节点的身份信息;subnetState用于表示区块链子网的运行状态(启动、停止、无效等);genesis用于表示区块链子网的创世块信息。上述数据均可存储于Subnet系统合约的合约状态中。
用于组建区块链子网的交易可以包含如下信息:
from:Administrator
to:Subnet
method:AddSubnet(string)
string:genesis
其中,from字段为该交易的发起方的信息,譬如Administrator表明该发起方为管理员;to字段为被调用的智能合约的地址,譬如该智能合约可以为Subnet合约,则to字段具体为该Subnet合约的地址;method字段为调用的方法,譬如在Subnet合约中用于组建区块链子网的方法可以为AddSubnet(string),而string为AddSubnet()方法中的参数,上述示例中通过genesis表征该参数的取值,该genesis具体为前述的配置信息。
以Subnet0上的节点nodeA~nodeE执行调用Subnet合约中AddSubnet()方法的交易为例。在交易通过共识后,nodeA~nodeE分别执行AddSubnet()方法并传入配置信息,得到相应的执行结果。
合约的执行结果可以包括所述配置信息,该执行结果可以处于前文所述的收据中,该收据中可以包含与执行AddSubnet()方法相关的event,即组网事件。组网事件的topic可以包含预定义的组网事件标识,以区别于其他的事件。譬如在与执行AddSubnet()方法相关的event中,topic的内容为关键词subnet,且该关键词区别于其他方法所产生event中的topic。那么,nodeA~nodeE或者部署nodeA~nodeE的节点设备1~5通过监听生成的收据中各个event所含的topic,可以在监听到包含关键词subnet的topic的情况下,确定监听到与执行AddSubnet()方法相关的event,即组网事件。例如,收据中的event如下:
Event:
[topic:other][data]
[topic:subnet][data]
......
那么,在监听到第1条event时,由于所含topic的内容为other,确定该event与AddSubnet()方法无关;以及,在监听到第2条event时,由于所含topic的内容为subnet,确定该event与AddSubnet()方法相关,并进而读取该event对应的data字段,该data字段包含上述的配置信息。以配置信息包括区块链子网的节点成员的公钥为例,data字段的内容例如可以包括:
{subnet1;
nodeA的公钥,nodeA的IP、nodeA的端口号...;
nodeB的公钥,nodeB的IP、nodeB的端口号...;
nodeC的公钥,nodeC的IP、nodeC的端口号...;
nodeD的公钥,nodeD的IP、nodeD的端口号...;
}
其中,subnet1为希望创建的区块链子网的网络标识。区块链主网中的各个区块链节点可以记录该区块链主网上已创建的所有区块链子网的网络标识,或者与这些区块链子网相关的其他信息,这些信息譬如可以维护在上述的Subnet合约中,具体可以对应于该Subnet合约所含的一个或多个合约状态的取值。那么,可以根据记录的已创建的所有区块链子网的网络标识,确定上述的subnet1是否已经存在;如果不存在,说明subnet1是当前需要创建的新区块链子网,如果存在则说明subnet1已经存在。
除了采用希望创建的新的区块链子网的网络标识之外,还可以采用预定义的新建网络标识,该新建网络标识表明相应的组网事件用于组建新的区块链子网。例如,可以将上述的subnet1替换为newsubnet,该newsubnet为预定义的新建网络标识,nodeA~nodeE在识别到data字段包含newsubnet时,即可确定包含该newsubnet的event为组网事件,需要创建新的区块链子网。
除了网络标识subnet1之外,上述data字段中还包含参与组建区块链子网的各个节点成员的身份信息等内容。部署第一区块链节点的节点设备可以监听生成的收据,并在监听到所述组网事件且所述组网事件的内容包含第一区块链节点对应的节点成员的身份信息的情况下,由部署第一区块链节点的节点设备获取所述组网事件包含的配置信息或创世块。或者,第一区块链节点可以监听生成的收据,并在监听到所述组网事件且所述组网事件的内容表明第一区块链节点属于所述节点成员的情况下,触发部署第一区块链节点的节点设备获取所述组网事件包含的所述配置信息或所述创世块。
如前所述,节点设备可以直接监听收据。假定nodeA~nodeE分别部署在节点设备1~5上,节点设备1~5可以监听nodeA~nodeE分别生成的收据,那么在监听到subnet1是需要新组建的区块链子网的情况下,节点设备1~5会进一步识别data字段中包含的节点成员的身份信息,以确定自身的处理方式。以nodeA和节点设备1为例:如果节点设备1发现data字段包含nodeA的公钥、IP地址和端口号等身份信息,那么节点设备1在基于上述的消息机制从data字段获得配置信息的情况下,生成包含该配置信息的创世块,且节点设备1会在本地部署nodeA1,该nodeA1加载生成的创世块,从而成为subnet1的子网节点;类似地,节点设备2可以生成nodeB1、节点设备3可以生成nodeC1、节点设备4可以生成nodeD1。以及,节点设备5会发现data字段包含的身份信息与自身均不匹配,则该节点设备5不会根据data字段中的配置信息生成创世块,也不会生成subnet1中的区块链节点。
如前所述,区块链主网中的区块链节点可以监听收据,并根据监听结果触发节点设备执行相关处理。例如,nodeA~nodeE在确定subnet1是需要新组建的区块链子网的情况下,会进一步识别data字段中包含的节点成员的身份信息,以确定自身的处理方式。比如,nodeA~nodeD会发现在data字段包含自身的公钥、IP地址和端口号等身份信息,假定nodeA~nodeD分别部署在节点设备1~4上,以nodeA和节点设备1为例:nodeA 会触发节点设备1,使得节点设备1在基于上述的消息机制从data字段获得配置信息的情况下,生成包含该配置信息的创世块,且节点设备1会在本地部署nodeA1,该nodeA1加载生成的创世块,从而成为subnet1的子网节点;类似地,nodeB会触发节点设备2生成nodeB1、nodeC会触发节点设备3生成nodeC1、nodeD会触发节点设备4生成nodeD1。以及,nodeE会发现data字段包含的身份信息与自身均不匹配,假定nodeE部署在节点设备5上,那么该节点设备5不会根据data字段中的配置信息生成创世块,也不会生成subnet1中的区块链节点。
如前所述,第一区块链节点与第二区块链节点并不一定采用相同的身份信息。因此,在上述实施例中,data字段中可以包含预先为nodeA1~nodeD1生成的身份信息,且区别于nodeA~nodeD的身份信息。仍以nodeA和节点设备1为例:节点设备1如果在data字段中发现了nodeA1的身份信息,可以生成创世块、部署nodeA1,并由nodeA1加载该创世块;或者,nodeA如果在data字段中发现了nodeA1的身份信息,那么nodeA会触发节点设备1生成创世块、部署nodeA1,并由nodeA1加载该创世块。其他区块链节点或节点设备的处理方式类似,此处不再一一赘述。
除了配置信息之外,合约的执行结果可以包括创世块。换言之,除了可以在data字段中包含配置信息,还可以直接在执行合约调用的过程中生成包含配置信息的创世块,从而将创世块包含于data字段中,那么对于上述的nodeA~nodeD而言,相应的节点设备1~4可以通过消息机制直接从data字段获得创世块,而无需自行生成,可以提升对nodeA1~nodeD1的部署效率。
在本说明书中,组建区块链子网的交易可以并非是调用智能合约的交易,使得不支持智能合约的区块链网络也可以实现本说明书的技术方案,从而在区块链主网的基础上快捷地创建出区块链子网。例如,可以预先定义一组网交易类型标识,当交易包含该组网交易类型标识时,就表明该交易用于组建新的区块链子网,即该交易为组建区块链子网的交易。区块链平台代码可以包含相关的用于组建区块链子网的处理逻辑,使得运行该区块链平台代码的第一区块链节点在执行交易时,如果发现该交易中包含上述的组网交易类型标识,且第一区块链节点对应的节点成员的身份信息被包含于该交易中的配置信息中,可以基于上述处理逻辑来触发部署第一区块链节点的节点设备生成包含该配置信息的创世块并启动第二区块链节点,由第二区块链节点加载该创世块,以形成为区块链子网中的区块链节点。
节点设备通过在进程中创建一个运行区块链平台代码的实例,实现在该节点设备上部署一区块链节点。对于第一区块链节点而言,由节点设备在上述进程中创建运行区块链平台代码的第一实例而形成。类似地,对于第二区块链节点而言,由节点设备在上述进程中创建运行区块链平台代码的第二实例而形成。例如,节点设备可以首先在进程中创建第一实例,以形成区块链主网中的第一区块链节点;而当该节点设备对应的节点成员希望参与组建区块链子网时,可以在上述进程中创建第二实例,该第二实例区别于上述的第一实例,并由该第二实例形成区块链子网中的第二区块链节点。当第一实例与第二实例位于同一进程时,由于不涉及跨进程交互,可以降低对第二区块链节点的部署难度、提高部署效率。当然,第二实例也可能与第一实例分别处于节点设备上的不同进程中,本说明书并不对此进行限制。例如,节点设备可以在第一进程中创建第一实例,以形成区块链主网中的第一区块链节点;而当该节点设备对应的节点成员希望参与组建区块链子网时,可以启动区别于第一进程的第二进程,并在该第二进程中创建第二实例,该第二实例区别于上述的第一实例,进而由该第二实例形成区块链子网中的第二区块链节点。
通过上述方式,可以在区块链主网上创建出区块链子网。以图4为例,subnet0原本包含nodeA~nodeE,而在subnet0的基础上可以组建出subnet1,该subnet1包含nodeA1~nodeD1,且nodeA与nodeA1、nodeB与nodeB1、nodeC与nodeC1、nodeD与nodeD1分别部署在同一节点设备上。类似地,还可以在subnet0上组建出subnet2或更多的区块链子网,其中subnet2包含nodeA2、nodeB2、nodeC2和nodeE2,且nodeA与nodeA1、nodeA2,nodeB与nodeB1、nodeB2,nodeC与nodeC1,nodeD与nodeD1,nodeE与nodeE2分别部署在同一节点设备上。以及,可以将subnet1、subnet2等作为新的区块链主网,并在此基础上进一步组建出区块链子网,其过程与subnet1或subnet2的组建相似,此处不再赘述。
通过上述方式来组建区块链子网,可以在区块链主网与区块链子网之间形成管理关系,即区块链主网可以对区块链子网进行管理。除此之外,还可以基于注册机制形成多层区块链系统,无需借助于组建过程即可建立起区块链网络之间的管理关系,并据此对区块链网络进行管理,因而不会受到区块链网络的建立方式的限制。
具体而言,第一区块链网络中的各区块链节点接收注册交易,从注册交易中获取第 二区块链网络的身份信息,并将获取的第二区块链网络的身份信息与分配至第二区块链网络的子网标识进行关联存证,以将第二区块链网络注册为第一区块链网络的子网。然后,第二区块链网络中的各区块链节点接收锚定交易,从锚定交易中获取第一区块链网络的身份信息和分配至第二区块链网络的子网标识,并将获取的第一区块链网络的身份信息和分配至第二区块链网络的子网标识更新至第二区块链网络的身份信息中,以将第一区块链网络锚定为第二区块链网络的主网。
区别于前述的在区块链主网基础上组建区块链子网的方式,第二区块链网络可以并非在第一区块链网络的基础上所组建,使得第二区块链网络的组建并不会与第一区块链网络之间形成管理关系。在此基础上,本说明书通过注册机制在第一区块链网络与第二区块链网络之间建立起上述的管理关系,从而使得第一区块链网络成为第二区块链网络的主网、第二区块链网络成为第一区块链网络的子网。
注册交易可由第二区块链网络的管理员发起,即仅允许管理员将第二区块链网络注册为其他区块链网络的子网,而避免将注册权限开放给普通成员,以防止由此导致的安全性问题。在一些情况下,也可以允许第二区块链网络的普通成员发起上述注册交易,使得普通成员能够在管理员不便于发起交易的情况下依然能够快捷地完成注册。
以图5所示为例,第一区块链网络为subnet0,该subnet0包含的区块链节点为nodeA、nodeB、nodeC、nodeD和nodeE等。与图4所示实施例类似的,在subnet0的基础上组建相应的区块链子网subnet1和subnet2,以在subnet0与subnet1之间、subnet0与subnet2之间分别建立起管理关系,使得subnet0可以分别对subnet1和subnet2进行管理。进一步地,假定存在一区块链网络为subnet3,该subnet3包含nodeK、nodeL、nodeM和nodeN等区块链节点,且该subnet3并非在subnet0的基础上所组建。如果nodeK为管理员且仅允许管理员发起注册交易,那么可由nodeK向subnet0发起上述注册交易;如果nodeN为管理员且仅允许管理员发起注册交易,那么nodeK~nodeM需要向nodeN进行请求,使得nodeN向subnet0发起上述注册交易;如果nodeN为管理员但允许普通用户发起注册交易,那么nodeK~nodeL均可以向subnet0发起上述注册交易。
如前所述,在区块链主网的基础上组建区块链子网时,会使得该区块链子网与区块链主网之间存在逻辑上的层次关系,从而构成多层区块链系统,本说明书将这种机制称之为动态组网机制。比如,如图5中在subnet0上组建区块链子网subnet1、subnet2时,可以认为subnet0处于第一层、subnet1和subnet2处于第二层。类似地,通过将第二区块链网络注册为第一区块链网络的子网,使得第一区块链网络与第二区块链网络之间形成逻辑上的层次关系,从而构成多层区块链系统,本说明书将这种机制称之为注册机制。比如,如图5中通过将subnet3注册至subnet0,可以认为subnet0处于第一层、subnet3处于第二层。
针对通过动态组网机制和注册机制所形成的多层区块链系统,区块链主网可以为底层区块链网络,底层区块链网络并非在其他区块链网络的基础上基于动态组网机制组建的区块链子网,且底层区块链网络也并未通过注册机制成为其他区块链网络的子网,即底层区块链网络不存在对应的主网、不受其他区块链网络的管理,比如图5中的subnet0可以认为属于底层区块链网络类型的区块链主网;或者,区块链主网也可以通过动态组网机制或注册机制成为其他区块链网络的子网,比如可以在图5中subnet1(或subnet2、subnet3)的基础上进一步通过动态组网机制组建另一区块链子网,或者将另一区块链网络注册为subnet1(或subnet2、subnet3)的子网,此时可以认为subnet1(或subnet2、subnet3)为该区块链子网对应的区块链主网,而这并不影响该subnet1(或subnet2、subnet3)同时属于subnet0的区块链子网。可见,区块链主网与区块链子网实际上是相对概念,同一区块链网络在一些情况下可以为区块链主网、另一些情况下可以为区块链子网。
需要说明的是,在一个多层区块链系统中,可以同时包含通过动态组网机制和注册机制形成的各组区块链主网与区块链子网,比如图5中的subnet1和subnet2通过动态组网机制成为subnet0的子网,而subnet3通过注册机制成为subnet0的子网。当然,一些情况下,一个多层区块链系统也可以仅包含通过动态组网机制形成的各组区块链主网与区块链子网,或者仅包含通过注册机制形成的各组区块链主网与区块链子网。
上述的注册交易包括调用合约的交易。该交易中可以指明被调用的智能合约的地址、调用的方法和传入的参数。例如,调用的合约可以为前述的创世合约或系统合约,调用的方法可以为注册区块链子网的方法,传入的参数可以包括第二区块链网络的身份信息。在一实施例中,该交易可以包含如下信息:
from:Administrator
to:Subnet-M
method:RegSubnet(string)
string:genesis
其中,from字段为该交易的发起方的信息,譬如Administrator表明该发起方为管理员;to字段为被调用的智能合约的地址,譬如该智能合约可以为Subnet-M合约,则to字段具体为该Subnet-M合约的地址;method字段为调用的方法,譬如在Subnet-M合约中用于注册区块链子网的方法可以为RegSubnet(string),而string为RegSubnet()方法中的参数,上述示例中通过genesis表征该参数的取值,该genesis具体为前述的第二区块链网络的身份信息。
第一区块链网络中的各个区块链节点分别根据收到的注册交易,执行该注册交易调用的上述RegSubnet()方法,以将第二区块链网络的身份信息与分配至第二区块链网络的子网标识进行关联存证,从而相当于第一区块链网络将第二区块链网络登记为自身的子网。
第二区块链网络的身份信息可以包括:第二区块链网络包含的所有区块链节点的信息。例如,每个区块链节点的信息可以包括:节点公钥、节点IP、节点端口号等,本说明书并不对此进行限制。
分配至第二区块链网络的子网标识,即第二区块链网络的子网ID。子网ID的生成方式在本说明书中并不受限,只要确保全局唯一即可。例如,可由上述的RegSubnet()方法在被调用后,临时为第二区块链网络生成子网ID。再例如,可由上述的RegSubnet()方法在被调用后,从预先形成的ID池中为第二区块链网络选取子网ID。又例如,可由第二区块链网络自行生成子网ID,并与第二区块链网络的身份信息一并经由上述的genesis传入RegSubnet()方法。
通过执行上述的智能合约,第一区块链网络中的各区块链节点可以生成相应的执行结果。合约的执行结果可以包括上述的子网ID;尤其是,当子网ID是由第一区块链网络所分配、而非第二区块链网络自行生成的情况下,需要通过这种方式来获知分配至第二区块链网络的子网ID。当然,即便子网ID是由第二区块链网络所生成,也可以通过监听合约的执行结果,以确定第一区块链网络是否已经第二区块链网络完成了登记。合约的执行结果可以包括前文所述的收据,该收据中可以包含与执行RegSubnet()方法相关的event,即子网注册事件。子网注册事件的topic可以包含预定义的子网注册事件标识,以区别于其他的事件。譬如在与执行RegSubnet()方法相关的event中,topic的内容为关键词RegSubnet,且该关键词区别于其他方法所产生event中的topic。那么,通过监听第一区块链网络中的任一区块链节点生成的收据中各个event所含的topic,可以在监听到包含关键词RegSubnet的topic的情况下,确定监听到与执行RegSubnet()方法相关的event,即子网注册事件。例如,收据中的event如下:
Event:
[topic:other][data]
[topic:RegSubnet][data]......
那么,在监听到第1条event时,由于所含topic的内容为other,确定该event与RegSubnet()方法无关;以及,在监听到第2条event时,由于所含topic的内容为RegSubnet,确定该event与RegSubnet()方法相关,并进而读取该event对应的data字段,该data字段包含上述的子网ID。另外,子网注册事件中还可以包含第二区块链网络的身份信息,以便于确定该子网注册事件确实是针对第二区块链网络所产生。
基于所监听到的上述子网注册事件,一方面可以确定第一区块链网络已经将第二区块链网络登记为自身的子网,另一方面可以获知第二区块链网络的子网ID。因此,可以据此向第二区块链网络发起下述的锚定交易,以完成对相关信息的锚定。
上述的子网注册事件可由注册交易的发起方在第一区块链网络中的区块链节点处进行监听,并进而由该发起方向第二区块链网络发起锚定交易。也可以由除注册交易的发起方之外的其他对象监听子网注册事件,并进而向第二区块链网络发起锚定交易。当然,锚定交易的发起方并不一定与监听上述子网注册事件的对象相同;实际上,发起注册交易的对象、监听子网注册事件的对象和发起锚定交易的对象之间并不存在必然关联,可以根据实际情况选择为同一对象或不同对象。
注册交易也可以并非是调用智能合约的交易,使得不支持智能合约的区块链网络也可以实现本说明书的技术方案,从而由第一区块链网络对第二区块链网络的身份信息和分配至第二区块链网络的子网标识进行关联存证。例如,可以预先定义一子网注册交易类型标识,当交易包含该子网注册交易类型标识时,就表明该交易用于注册新的区块链子网,即该交易为注册交易。区块链平台代码可以包含相关的用于注册区块链子网的处理逻辑,使得运行该区块链平台代码的第一区块链节点在执行交易时,如果发现该交易中包含上述的子网注册交易类型标识,可以基于上述处理逻辑对第二区块链网络的身份信息和分配至第二区块链网络的子网标识进行关联存证。此时,分配至第二区块链网络 的子网标识可以包含于注册交易中;或者,区块链平台代码也可以包含分配子网标识的逻辑,使得区块链平台代码可以针对注册交易向第二区块链网络分配相应的子网ID。
上述注册交易在被发送至第一区块链网络后,由第一区块链网络内的共识节点进行共识,并在通过共识后由各区块链节点执行该交易,以将第二区块链网络注册为自身的子网。共识过程取决于所采用的共识机制,譬如上文所述的任一共识机制,本说明书并不对此进行限制。类似的,下述的锚定交易在被发送至第二区块链网络后,由第二区块链网络内的共识节点进行共识,并在通过共识后由各区块链节点执行该交易,以将第一区块链网络锚定为自身的主网。共识过程取决于所采用的共识机制,譬如上文所述的任一共识机制,本说明书并不对此进行限制。
通过将第一区块链网络的身份信息和分配至第二区块链网络的子网标识更新至第二区块链网络的身份信息中,使得第二区块链网络的身份信息可以对第一区块链网络与第二区块链网络之间的管理关系进行锚定。结合第一区块链网络中存证的第二区块链网络的身份信息及其子网标识,使得第一区块链网络与第二区块链网络之间实现了相互认证、交叉验证,确保第一区块链网络与第二区块链网络之间的管理关系得到双方认可,并且后续可以基于这种管理关系实现相应的管理操作。
与上述注册交易相类似的,锚定交易可由第二区块链网络的管理员发起。在一些情况下,也可以允许第二区块链网络的普通成员发起上述锚定交易,使得普通成员能够在管理员不便于发起交易的情况下依然能够快捷地完成锚定。
上述的锚定交易包括调用合约的交易。该交易中可以指明被调用的智能合约的地址、调用的方法和传入的参数。例如,调用的合约可以为第二区块链网络中的创世合约或系统合约,调用的方法可以为锚定区块链主网的方法,传入的参数可以包括第一区块链网络的身份信息和分配至第二区块链网络的子网ID。在一实施例中,该交易可以包含如下信息:
from:Administrator
to:Subnet-S
method:AnchSubnet(string)
string:genesis
其中,from字段为该交易的发起方的信息,譬如Administrator表明该发起方为管理员;to字段为被调用的智能合约的地址,譬如该智能合约可以为Subnet-S合约,则to字段具体为该Subnet-S合约的地址;method字段为调用的方法,譬如在Subnet-S合约中用于锚定区块链主网的方法可以为AnchSubnet(string),而string为AnchSubnet()方法中的参数,上述示例中通过genesis表征该参数的取值,该genesis具体为前述的第一区块链网络的身份信息和分配至第二区块链网络的子网ID。
第二区块链网络中的各个区块链节点分别根据收到的锚定交易,执行该锚定交易调用的上述AnchSubnet()方法,以将第一区块链网络的身份信息与分配至第二区块链网络的子网标识更新至第二区块链网络的身份信息中,从而相当于第二区块链网络将第一区块链网络登记为自身的主网。其中,第二区块链网络可以通过Subnet-S合约中的世界状态来维护自身的身份信息,那么上述对于第二区块链网络的身份信息进行更新,实际上可以包括通过调用Subnet-S合约而对上述维护身份信息的世界状态进行更新。
第一区块链网络的身份信息可以包括下述至少之一:第一区块链网络包含的所有区块链节点的信息,第一区块链网络的网络标识等。其中,每个区块链节点的信息可以包括:节点公钥、节点IP、节点端口号等,本说明书并不对此进行限制。通过向第一区块链网络中的区块链节点发起询问交易,可以获得第一区块链网络的身份信息;当然,也可以通过其他方式获得第一区块链网络的身份信息,本说明书并不对此进行限制。
基于上述的注册交易和锚定交易,使得第一区块链网络和第二区块链网络之间建立起了双方相互认可的管理关系,该管理关系使得第一区块链网络成为第二区块链网络的主网、第二区块链网络成为第一区块链网络的子网,那么第一区块链网络可以基于该管理关系对第二区块链网络实施相应的管理操作。
上述的管理操作可以包括对区块链消息的路由。例如,第一区块链网络中的任一区块链节点如果接收到区块链消息,且该区块链消息包含分配至第二区块链网络的子网标识,那么由于第一区块链网络已经注册了第二区块链网络的身份信息及其子网标识,使得该区块链节点可以根据该区块链消息包含的子网标识查询出第二区块链网络的身份信息,并将该区块链消息转发至第二区块链网络。可见,基于上述管理关系的建立,使得第一区块链网络可以将区块链消息路由至第二区块链网络,有助于提升区块链消息的传输成功率。并且,当某一对象与第一区块链网络之间的网络环境较好、与第二区块链网络之间的网络环境较差时,可以实质上将第一区块链网络作为该对象与第二区块链网络之间的消息传输中继,从而有助于提升区块链消息的传输速率和成功率。其中,上述 的区块链消息可以包括区块链交易、区块数据、共识消息等各种类型的消息,本说明书并不对此进行限制。
第一区块链网络中的各区块链节点还可以记录第二区块链网络的运行状态,比如该运行状态可以包括可用状态、停用状态、暂停状态等。那么,第一区块链网络中的任一区块链节点在收到上述的区块链消息,且确定该区块链消息包含第二区块链网络的子网ID的情况下,可以进一步查询第二区块链网络的运行状态,从而在第二区块链网络处于可用状态时转发该区块链消息,否则可以不转发以节省网络资源。
上述的管理操作可以包括针对第二区块链网络的直接管理。例如,可以通过向第一区块链网络发起针对第二区块链网络的管理交易,以针对第二区块链网络进行管理。该管理交易的发起方譬如可以为第一区块链网络的管理员,当然并不排除可以为其他对象。相应地,第一区块链网络中的各区块链节点可以接收管理交易,从该管理交易中获取分配至第二区块链网络的子网标识和管理指令,并将该管理指令发送至第二区块链网络;具体的,可以基于管理交易中的子网标识查询相应子网的身份信息,譬如在查询到第二区块链网络的身份信息时,向第二区块链网络发送管理指令。而第二区块链网络中的各区块链节点在确定该管理指令由自身对应的主网所发送的情况下,执行该管理指令以完成相应的管理操作。
在实际操作过程中,可以通过多种方式将管理指令传递至第二区块链网络。举例而言:管理指令可以被包含于第一区块链网络执行管理交易而生成的子网管理事件中,该子网管理事件包含上述的管理指令和管理交易包含的子网标识。那么,当第二区块链网络监听到包含自身的子网标识的子网管理事件时,可以确定该子网管理事件所含的管理指令是针对自身进行管理。或者,第一区块链网络中的任一区块链节点所处的节点设备可以监听上述的子网管理事件,并根据该子网管理事件包含的子网标识,向第二区块链网络发送管理指令。或者,第一区块链网络在执行上述管理交易的过程中,可以通过相关技术中的跨链机制将管理指令发送至第二区块链网络。
上述的管理指令可以用于实现下述至少之一:改变第二区块链网络的运行状态、管理第二区块链网络包含的区块链节点、定义第二区块链网络的业务规则、改变第二区块链网络使用的功能组件等,本说明书并不对此进行限制。当管理指令用于改变第二区块链网络的运行状态时,譬如可以将第二区块链网络的运行状态在可用状态、暂停状态与停用状态之间进行切换。当管理指令用于管理第二区块链网络包含的区块链节点时,譬如可以对第二区块链网络所含的区块链节点进行增加、删减等。当管理指令用于定义第二区块链网络的业务规则时,可以对第二区块链网络的业务规则进行增加、删除或修改,这里的业务规则譬如可以包括第二区块链网络支持解码的区块链消息的数据格式,第二区块链网络上的合约部署权限、合约调用权限、合约升级权限,第二区块链网络中需要交互并存证至第一区块链网络的数据等。当管理指令用于改变第二区块链网络使用的功能组件时,这里的功能组件由第二区块链网络中的各区块链节点运行区块链平台代码所形成,譬如可以包括共识组件、隐私保护组件、跨链组件、链下机密计算组件、子网管理组件等,管理指令可以用于增加或删除第二区块链网络使用的功能组件,或者更改其使用的功能组件,比如更改共识组件所采用的共识算法等。
基于可通过上述动态组网机制或注册机制来形成多层区块链系统,可构建不同的区块链网络来存证不同类型的业务数据。在该场景下,不同的区块链网络之间存在交互的需求,从而通过跨链交互来实现一些复杂的业务。比如,区块链主网管理的某一区块链子网在执行业务时,需要在该区块链主网管理的另一区块链子网上写入数据,比如存证数据或者修改该另一区块链子网的世界状态。那么此时该区块链子网作为源区块链子网,该另一区块链子网作为目的区块链子网,由源区块链子网的子网节点(即源子网节点)向目的区块链子网中的子网节点(即目的子网节点)发送用于请求写入数据的跨子网请求以实现跨子网写入数据。而为了保证区块链子网数据的安全性,可对跨子网写数据进行权限控制,比如控制允许写入数据的区块链子网,以及控制跨子网写操作的类型等等。下面结合图6对源区块链子网与目的区块链子网之间跨子网交互的权限控制过程进行详细说明。
请参见图6,图6是一示例性实施例提供的一种跨子网交互的权限控制方法的流程图。如图6所示,该方法应用于区块链系统,该区块链系统包括区块链主网及其管理的区块链子网;该方法可以包括以下步骤。
步骤602,目的区块链子网中的目的子网节点接收源区块链子网中的源子网节点发送的跨子网请求,所述跨子网请求包括针对所述目的区块链子网的写入操作的操作信息。
不同的区块链子网用于执行不同的业务操作,或者用于存证不同的业务数据,而有些业务需要多类业务数据或者需要多个业务操作联动来共同实现,那么在完成该业务的过程中需要由某个区块链子网来发起跨子网交互以在其他一个或者多个区块链子网中 写入数据(同时也可能包括读取数据)。其中,写入操作可以包括写入目的区块链子网上部署的智能合约,或者,写入目的区块链子网的区块等等。当然,写入操作的具体形式可根据实际情况灵活设定,本说明书并不对此进行限制。
具体而言,可通过上述消息机制的方式来发起跨子网交互。比如,源区块链子网接收到第一区块链交易,该第一区块链交易用于调用部署于源区块链子网上的智能合约以完成某个业务,而该业务需要在目的区块链子网上写入数据,那么源区块链子网响应于提交至源区块链子网的第一区块链交易,执行第一区块链交易调用的智能合约以生成包含操作信息(比如为用于指示如何执行写入操作的参数)的事件,源区块链子网中的子网节点在监听到该事件后,读取该事件中包含的操作信息以生成跨子网请求(即跨子网请求中包含写入操作的操作信息)。
举例而言,假定subnet a和subnet b均为区块链主网subnet 0的区块链子网,部署于subnet a上的业务合约用于为用户提供会员服务,subnetb用于存储用户的会员信息,假定subnet a要为一位新用户注册会员,注册会员需要记录用户的身份证号码,而用户的身份证号码由subnet b负责存储。那么,用户可向subnet a发起调用业务合约的区块链交易,该区块链交易中包含业务合约的合约地址、subnet b的子网标识、身份证号码等信息。此时,subnet a作为源区块链子网,subnet b作为目的区块链子网。然后,subnet a执行业务合约生成包含操作信息(指示在subnet b上写入身份证号码)的事件,subnet a中的子网节点在监听到该事件后,生成包含该操作信息的跨子网请求并发送至subnet b中的子网节点。
步骤604,所述目的子网节点查询所述区块链主网所管理的各个区块链子网针对所述目的区块链子网的写入操作的权限信息,并根据所述权限信息对所述操作信息进行校验。
为了保证区块链子网数据的安全性,可针对区块链子网配置针对该区块链子网的写入操作的权限信息以实现对跨子网写服务的权限控制,比如控制允许写入数据的区块链子网,以及控制跨子网写操作的类型等等。具体而言,权限信息的权限控制维度可以包括以下至少之一:发起所述跨子网请求的区块链子网的子网标识、发起写入操作的区块链子网的区块链账户、请求写入的区块链子网的区块链账户、请求写入的参数类型。
而针对为区块链子网配置权限信息的方式,可通过对其管理的区块链主网或者区块链子网本身。
在一种情况下,可在各个区块链子网上部署用于记录权限信息的第一写入控制合约,即每个区块链子网上的第一写入控制合约记录有用于对自身所属区块链子网进行写入权限控制的权限信息。比如,子网subnet a上部署有记录哪些子网可在subnet a上写入数据以及写入何种数据的权限信息的智能合约,同理,子网subnet b上部署有记录哪些子网可在subnet b上写入数据以及写入何种数据的权限信息的智能合约。换言之,由区块链子网本身来进行写入权限控制。针对该情况,目的子网节点在查询区块链主网的各个区块链子网针对目的区块链子网的写入操作的权限信息时,可查询部署于目的区块链子网上的第一写入控制合约记录的权限信息。针对上述目的子网节点实时查询第一写入控制合约的情况,由于查询操作并不会影响目的区块链子网的世界状态,目的子网节点可创建本地查询交易(1ocal查询交易),以在本地存储的对应于目的区块链子网的世界状态中查询第一写入控制合约记录的权限信息。其中,由于本地查询交易触发的查询操作不会影响目的区块链子网的世界状态,无需在区块链网络中进行共识,目的子网节点无需向目的区块链子网内的其他子网节点发送该本地查询交易以进行共识,可节约目的区块链子网的处理资源,并提高查询效率。
进一步的,除目的子网节点实时查询权限信息以外,为了提高查询效率,可采用子网缓存策略。具体而言,可预先配置缓存专门用于存储第一写入控制合约记录的权限信息。比如,可在目的子网节点归属的节点设备上分配存储资源作为该缓存;或者,还可在其他设备(比如专门设置一个数据库服务器)上设置该缓存。那么,目的子网节点可查询预设缓存中存储的权限信息以执行校验的操作。而对于将第一写入控制合约记录的权限信息读取至预设缓存的方式,可在目的子网启动时,每个目的子网中的子网节点可采用上述创建local查询交易的方式来查询第一写入控制合约记录的权限信息。而对于目的子网启动之后,区块链系统的管理员可根据需要更改第一写入控制合约记录的权限信息。比如,管理员可向上述目的子网发起针对权限信息的更新交易(即调用第一写入控制合约来更新权限信息,包含相应的更新信息),第一写入控制合约在响应权限信息的更新交易的情况下可生成更新事件(包含更新信息),那么目的子网节点可在监听到第一写入控制合约生成的针对权限信息的更新事件的情况下,根据更新事件记录的更新信息更新预设缓存。
在另一种情况下,可在管理区块链子网的区块链主网上部署用于记录权限信息的第 二写入控制合约,即用于控制在每个区块链子网上写入数据的权限信息均记录和维护于在区块链主网上部署的第二写入控制合约中。比如,区块链主网subnet 0管理子网subnet a-subnet c,那么可在subnet 0上部署第二写入控制合约,该合约分别记录有用于控制在subnet a-subnet c上写入数据的权限信息。换言之,由区块链主网来对其管理的区块链子网进行写入权限控制。针对该情况,目的子网节点在查询区块链主网的各个区块链子网针对目的区块链子网的写入操作的权限信息时,可查询部署于区块链主网上的第二写入控制合约记录的权限信息。
以基于上述基于动态组网机制组建的区块链子网为例,在该情况下,由上述描述动态组网机制的相关内容可知:部署区块链主网中主网节点的节点设备还用于部署区块链子网的子网节点,且部署于任一节点设备的主网节点和子网节点共享任一节点设备的区块链插件,使得子网节点可通过该区块链插件查询主网节点维护的关于区块链主网的数据。那么,目的子网节点可通过部署该目的子网节点的目标节点设备(即该目的子网节点所属的节点设备)中的区块链插件,在目标节点设备部署的主网节点在本地存储的对应于区块链主网的世界状态中,查询第二写入控制合约记录的所述权限信息。
比如,第二写入控制合约可以是上述的Subnet系统合约(即子网管理合约),该区块链插件可以是SubnetPlugin,主网节点可调用SubnetPlugin查询Subnet系统合约维护的区块链子网的信息(节点ID、节点公钥、通讯地址等,被维护在区块链主网的子网管理合约的合约状态中),并存储在内存中作为区块链主网和相应区块链子网的共享部分以供查询。那么,目的子网节点可调用SubnetPlugin查询上述权限信息。
以基于上述注册机制组件组建的区块链子网为例,目的区块链子网还可以为通过上述注册机制注册至区块链主网的区块链子网。在该情况下,目的区块链子网中的目的子网节点可向区块链主网提交查询交易,该查询交易用于指示区块链主网查询Subnet系统合约(即子网管理合约)中记录的上述权限信息。
下面对第一写入控制合约和第二写入控制合约记录的权限信息进行举例说明。
比如写入控制合约控制的写入操作包括创建账户(CreateAccount)、转账(TransferBalance)、调用合约(CallContract)等等。那么权限信息的形式可如下:
Figure PCTCN2022135831-appb-000001
其中,子网标识表示可写入该目的子网的源子网的id;交易属性表示源子网可在目的子网创建的交易的属性;原始账户表示可在源子网发起写入操作的账户;目标账户表示可写入该目的子网中的账户;合约中的函数表示在目标账户为合约账户的情况下,允许控制该合约账户内的方法。
当然,权限信息还可采用白名单的形式,可根据实际需求灵活设定,本说明书并不对此进行限制。
步骤606,所述目的子网节点在校验通过的情况下响应于所述跨子网请求,根据所述操作信息执行相应的写入操作。
在校验通过的情况下,可由目的区块链子网的主节点(比如目的区块链子网采用PBFT算法进行共识,那么可通过PBFT共识算法来选取主节点)响应于跨子网请求而创建第二区块链交易,并在目的区块链子网内发起第二区块链交易。在所述操作信息的第二区块链交易通过共识的情况下,目的区块链子网内的子网节点响应于第二区块链交易,根据该操作信息执行相应的写入操作。
由上述实施例可见,在区块链主网管理多个区块链子网的应用场景下,不同区块链子网之间存在跨子网写服务的需求,即某一业务的实现需要一个区块链子网在另一区块链子网上写入数据。对此,通过预先针对区块链子网配置针对该区块链子网的写入操作的权限信息,可在其他区块链子网请求对该区块链子网写入数据的情况下,利用该权限信息对请求写入数据的跨子网请求进行校验,以在校验通过的前提下再执行写入操作,从而保证区块链子网数据的安全性,实现对跨子网写服务的权限控制,比如控制允许写入数据的区块链子网,以及控制跨子网写操作的类型等等。
除此之外,为了保证跨子网交互过程中的数据隐私,可采用数字信封的方式对跨子网请求所传输的区块链消息(比如上述操作信息)进行加密。该数字信封加密的方式结合了对称加密算法和非对称加密算法。具体而言,源子网节点采用自身的对称密钥对待传输的区块链消息加密,并将加密后的区块链消息添加至跨子网请求中。然后,源子网 节点采用目的节点的节点公钥对该对称密钥加密,并将加密后的对称密钥添加至跨子网请求中。相应的,目的节点在接收到跨子网请求后,先采用自身的节点私钥对跨子网请求中包含的密文形式的对称密钥进行解密,得到明文形式的对称密钥,然后再通过该对称密钥对跨子网请求中包含的区块链消息进行解密。
进一步的,为了保证跨子网请求的可靠传输,源区块链子网中的源子网节点可分别向目的区块链子网中的每个目的节点发送跨子网请求,以由每个目的节点对跨子网请求进行响应。通过上述发送跨子网请求的方式,即便在传输过程中部分跨子网请求丢失,也可保证目的区块链子网中的目的节点可接收到跨子网请求以进行响应,从而进一步保证源区块链子网能够顺利获取到目的区块链子网针对跨子网请求的响应结果。在该传输跨子网请求的方式下,源区块链子网中的源子网节点可分别采用目的区块链子网中每个目的节点的节点公钥对自身的对称密钥加密,并将加密得到的各个对称密钥均添加至跨子网请求中,然后源子网节点分别向目的区块链子网中的每个目的节点发送该跨子网请求。相应的,目的节点在接收到跨子网请求后,先采用自身的节点私钥分别对跨子网请求中包含的各个密文形式的对称密钥进行解密,可对采用该目的节点的节点公钥加密的对称密钥成功解密,然后再通过解密成功的对称密钥对跨子网请求中包含的区块链消息进行解密。通过上述分别采用每个目的节点的节点公钥加密对称密钥的方式,可保证针对跨子网请求的统一创建方式,简化创建跨子网请求的操作,避免源子网节点在创建跨子网请求的过程中分别针对每个目的节点进行差异化处理,比如分别仅采用每个目的节点的节点公钥加密对称密钥,并添加至跨子网请求中以发送至相应的目的节点。
对于跨子网请求所传输的区块链消息,可以为源区块链子网在执行智能合约的过程中生成的事件。具体而言,源区块链子网上部署有智能合约,业务发起方可向源区块链子网发起用于调用该智能合约的第一区块链交易,第一区块链交易中指示有目的区块链子网的网络标识,该目的区块链子网存证有智能合约的待处理数据。那么,源子网节点可响应于第一区块链交易,执行智能合约以创建区块链消息添加至跨子网请求中,该区块链消息用于指示目的区块链子网返回智能合约的待处理数据。
举例而言,在业务层中,subnet a中的源子网节点在接收到区块链交易后,可执行业务合约生成事件,该事件中包含如下字段:
biz id:业务id;
request_id:请求id;
src_subnet_id:源区块链子网标识;
dest_subnet_id:目的区块链子网标识;
method:调用的方法;
args:调用的参数;
timestamp:时间戳。
源区块链子网subnet a内的源子网节点在监听到上述事件后,在Signature Message层(消息签名层)通过调用SM消息组件对该事件进行签名,以认证源子网节点的身份。其中,node_id字段用于存放源子网节点的节点标识,msg字段用于存放监听到的事件包含的上述字段,sign字段用于存放源子网节点采用自身的节点私钥对mag字段存放的内容进行签名得到的签名数据。
在Envelope Message层(消息信封层)通过调用Envelope消息组件对Signature Message层得到的数据采用数字信封的方式进行加密。具体而言,源区块链子网subnet a内的源子网节点可随机生成自身使用的对称密钥K(各源子网节点可使用相同或者不同的对称密钥),然后采用对称密钥K对上述node_id字段、msg字段和sign字段的内容进行加密后存放至encry_data字段。与此同时,在区块链主网subnet 0部署的Subnet系统合约中,维护有各个区块链子网内子网节点的节点公钥。因此,源区块链子网subnet a内的源子网节点可通过目的区块链子网subnet b的子网标识查询Subnet系统合约中维护的subnet b内每个子网节点的节点公钥,然后分别采用每个节点公钥加密自身使用的对称密钥,得到多个密文形式的对称密钥en_key1、en_key2、en_key3等等(图中以目的区块链子网subnet b内包含3个目的子网节点为例),并存放于encryped_key字段中。
在P2P Message层(通讯层)通过调用P2P消息组件将Envelope Message层得到的数据封装成跨子网请求。具体而言,将encryped_key字段和encry_data字段的内容存放至data字段中。同时,跨子网请求还包含以下字段:
src_subnet_id:表示源区块链子网标识;
dest_subnet_id:表示目的区块链子网标识;
msg_type:表示跨子网请求的请求类型标识。
与此同时,在区块链主网subnet 0部署的Subnet系统合约中,维护有各个区块链子网内子网节点的IP地址、端口号等地址信息。因此,源区块链子网subnet a内的源子 网节点可通过目的区块链子网subnet b的子网标识查询Subnet系统合约中维护的subnet b内每个子网节点的地址信息,从而在生成跨子网请求后,根据地址信息向目的区块链子网subnet b内的每个子网节点发送跨子网请求。当然,也可广播跨子网请求,由接收方根据dest_subnet_id字段判断自身是否需要对接收到的跨子网请求进行响应。
类似的,目的区块链子网subnet b内的子网节点作为目的子网节点,同样依次在上述各层对接收到的跨子网请求进行处理。其中,目的子网节点采用自身的节点私钥分别对encryped_key字段存放的各个密文形式的对称密钥进行解密,可对采用该目的子网节点的节点公钥加密的对称密钥成功解密,然后再通过解密成功的对称密钥对encry_data字段存放的区块链消息进行解密,得到node_id字段、msg字段和sign字段的内容。此时,可校验源子网节点的有效性和签名的有效性。比如,可根据跨子网请求的src_subnet_id查询Subnet系统合约中维护的相应区块链子网内各个子网节点的节点标识和节点公钥。然后,判断查询到的节点标识是否包含node_id字段存放的节点标识,当查询到的节点标识包含node_id字段存放的节点标识时,判定源子网节点的有效性校验通过。然后,采用与node_id字段存放的节点标识对应的节点公钥对sign字段存放的签名进行验签,以在验签通过的情况下判定源子网节点的签名校验通过。在校验源子网节点的有效性和签名的有效性通过之后,可读取msg字段存放的内容以进行响应。比如,按照method字段和args字段存放内容的指示执行相应的操作,读取智能合约所需的待处理数据,然后向接收到的跨子网请求的发送方返回待处理数据。需要说明的是,在返回待处理数据的过程中,subnet b作为源区块链子网,subnet a作为目的区块链子网,跨子网交互的过程与上述类似,在此不再赘述。
由此可见,在基于区块链主网的跨子网交互的过程中,通过利用源区块链子网和目的区块链子网对应同一区块链主网的层级关系来对源子网节点进行身份校验,无需引入其他额外的组件(比如利用跨链中继、公证人等方式来实现两子网之间的数据交互,需要额外配置组件),校验过程中充分利用了上述层级关系的特点,目的子网节点仅需直接向区块链主网查询源子网节点的节点身份信息,能够在准确校验源子网节点身份以保证数据安全的前提下,使得校验操作更为简单、轻量和高效。
针对上述区块链主网建立有多个区块链子网的场景,源子网节点可收到目的子网节点返回的跨子网应答(比如,包含执行上述写入操作得到的结果),而在此过程中应当保证区块链子网之间跨链交互的合法性、有效性,从而防止节点作恶所带来的不利影响。下面对源子网节点接收到跨子网应答后进行审计的过程进行详细说明。
请参见图7,图7是一示例性实施例提供的一种跨链交互的审计方法的流程图。如图7所示,该方法可以包括以下步骤。
步骤702,所述源子网节点获取各个目的子网节点分别响应于所述跨子网请求返回的跨子网应答,根据所述源子网节点所处节点设备上部署的主网节点在第一区块高度所维护的目的区块链子网节点列表对获取到的跨子网应答进行验签及拜占庭容错校验,并将验签成功且通过拜占庭容错校验的标准跨子网应答和第一区块高度构造为重构应答。
在本说明书实施例中,源区块链子网中的至少一个源子网节点向目的区块链子网发起跨链请求,包括:源区块链子网中的一个源子网节点向目的区块链子网中的一个目的子网节点发送跨链请求,以使该目的子网节点将所述跨链请求进一步在目的区块链网络中广播从而使目的区块链子网中的各目的子网节点分别获得所述跨链请求,该跨链请求所要求的应答返回方为源区块链子网中的每一个源子网节点;或者,源区块链子网中的一个源子网节点向目的区块链子网中的所有目的子网节点分别发送跨链请求,该跨链请求所要求的应答返回方为源区块链子网中的每一个源子网节点;或者,源区块链子网中的每一个源子网节点向目的区块链子网中的一个目的子网节点发送跨链请求,以使该目的子网节点将所述跨链请求进一步在目的区块链网络中广播从而使目的区块链子网中的各目的子网节点分别获得所述跨链请求,每一跨链请求所要求的应答返回方为发送该跨链请求的源子网节点;或者,源区块链子网中的每一个源子网节点向目的区块链子网中的所有目的子网节点分别发送跨链请求,该跨链请求所要求的应答返回方为发送该跨链请求的源子网节点。
在本说明书实施例中,所述源区块链子网中的至少一个源子网节点向目的区块链子网发起跨链请求,包括:所述源区块链子网中的至少一个源子网节点在其维护的业务合约执行过程中触发生成针对所述目的区块链子网的跨链请求的情况下,调用跨子网合约将所述跨链请求发送至所述各目的子网节点。源子网节点可以在执行业务合约的执行过程中,因业务合约所产生的一个跨链需求,可以触发生成一个针对目的区块链子网的跨链请求,并在通过本地交易调用该源子网节点上部署的跨子网合约,跨子网合约接收到该跨链请求后进行进一步的封装并调用源子网节点所处节点设备上部署的通讯插件将该跨链请求发送至目的区块链子网中相应的源子网节点。
本说明书实施例所涉及的本地交易不参与区块链共识的交易,仅作为节点本地的内部调用媒介;本说明书实施例所涉及的跨子网合约维护有区块链主网所管理的各区块链子网的通讯地址,参与跨链消息的封装以及调用本地的通讯插件,以实现跨链交互的功能。
在本说明书实施例中,所述根据所述源子网节点所处节点设备上部署的主网节点在第一区块高度所维护的目的区块链子网节点列表对获取到的跨链应答进行验签及拜占庭容错校验,包括:根据所述目的区块链子网节点列表中包含的所述各目的子网节点对应的公钥,对所述获取到的跨链应答对应的应答签名信息进行验签;在所述获取到的跨链应答中内容相同的跨链应答超过(大于)第一预设数量且对应的应答签名信息验签成功的情况下,将所述内容相同的跨链应答之一确定为验签成功且通过拜占庭容错校验的标准跨链应答。
各目的子网节点在接收到所述跨链请求后,不仅会返回针对所述跨链请求的跨链应答,还会基于自身的节点私钥生成该跨链应答对应的应答签名信息并返回源子网节点,因此源子网节点可以通过对任一跨链应答对应的应答签名信息进行验签来确定该任一跨链应答的有效性。本说明书实施例所涉及的目的区块链子网节点列表包含目的区块链子网的节点成员信息,例如节点ID、节点公钥、通讯地址等,该目的区块链子网节点列表被维护在区块链主网的子网管理合约的合约状态中,由于合约状态会随着链上时间(区块高度)的更新而发生变化,因此源子网节点在使用目的区块链子网节点列表进行验签和拜占庭容错校验之前,需要指定使用的目的区块链节点列表是哪一区块高度所锚定的,例如源子网节点可以首先确定第一区块高度,然后指定区块链主网于第一区块高度下所维护的目的区块链子网节点列表为后续所需使用进行验签和拜占庭容错校验的目的区块子网节点列表。另外,源子网节点获取区块链主网上维护的目的区块链子网节点列表是通过访问自身所处节点设备上部署的主网节点所实现。
在本说明书实施例中,第一预设数量通过所述目的区块链子网节点列表包含的所述目的区块链子网对应的第一节点总数所确定。具体而言,在针对跨链应答的拜占庭容错校验中,假设所述目的区块链子网对应的第一节点总数,即目的区块链子网中包含的所有目的子网节点的数量为3a(a为正整数),那么第一预设数量应为a。
在本说明书实施例中,第一区块高度为所述源子网节点对获取到的跨链应答进行验签及拜占庭容错校验时所述主网节点所维护的最新区块的区块高度;或者,第一区块高度为所述源子网节点按照预设的区块选取规则从所述主网节点所维护的区块中所选取的目标区块的区块高度。源子网节点在确定第一区块高度时,可以将其确定为源子网节点对获取到的跨链应答进行验签及拜占庭容错校验时所述主网节点所维护的最新区块的区块高度,这样可以确保源子网节点进行验签和拜占庭容错校验时所使用的是最新的目的区块链子网节点列表,但由于源子网节点获取区块链主网上维护的目的区块链子网节点列表的方式是通过访问自身所处节点设备上部署的主网节点所实现,而不同的源子网节点所处节点设备上部署的主网节点可能在最新区块高度上存在差异,因此对于不同的源子网节点而言,其所分别获取到的目的区块链子网节点列表可能并不一致,这导致源子网节点所进行的针对跨链应答的验证和的拜占庭容错校验的过程不可靠。
或者,源子网节点在确定第一区块高度时,可以按照预设的区块选取规则从所述主网节点所维护的区块中所选取的目标区块的区块高度,例如区块选取规则可以包括:在主网节点所维护的最新区块的共识时刻超过所述跨链请求的发送时刻的情况下,在主网节点所维护的区块中先选取出共识时刻不超过所述发送时刻的至少一个区块,再从所述至少一个区块中筛选出区块高度最高的区块作为目标区块。在本说明书实施例中,由于跨链请求的发送时刻是源区块链子网中各源子网节点均知晓的统一参数,而在主网节点所维护的最新区块的共识时刻超过所述跨链请求的发送时刻的情况下,就意味着共识时刻在所述发送时刻之前的区块就已经固定,区块链主网中的其他主网节点也维护有这些固定的区块,此时在这些固定的区块中基于统一的规则(例如选取区块高度最大的区块)所选取的目标区块也必定是一致的,因此,各源子网节点基于上述区块选取规则所选取得到的目标区块必定是一致,而第一区块高度为目标区块对应的区块高度,那么各源子网节点所确定的第一区块高度也就必定是一致的,从而可以克服不同源子网节点分别获取到的目的区块链子网节点列表不一致的问题。
步骤704,所述源子网节点在所述源区块链子网中广播所述重构应答,并接收所述源区块链子网中的其他子网节点广播的重构应答。
每个源子网节点在对自身所接收到的跨链应答进行验签和拜占庭容错校验后,均会确定得到一个标准跨链应答,并将所述标准跨链应答和第一区块高度构造为重构应答,再将所述重构应答在源区块链子网中广播,以使除自身外的每个源子网节点都能获取所述重构应答,同时,也会接受其他源子网节点广播的重构应答。为了使验证方能够确认 重构应答的合法性,每个源子网节点在构造得到对应的重构应答后,还会基于自身的节点私钥对该重构应答进行签名得到对应的共识签名信息,并在广播该重构应答时同时将对应的共识签名信息进行广播。每个重构应答可以反映出生成它的源子网节点在对跨链应答进行验签和拜占庭容错校验是所使用的目的区块链子网节点列表是基于哪个区块高度获取的。
步骤706,所述源子网节点根据源区块链子网节点列表对获取到的重构应答进行验签及拜占庭容错校验,并将验签成功且通过拜占庭容错校验的重构应答确定为响应所述跨子网请求的认证应答。
源子网节点在接收到其他源子网节点广播的若干重构应答后,会在这些广播接受到的重构应答以及自身生成的重构应答中确定出认证应答。具体而言,所述源子网节点从获得的重构应答中选取通过拜占庭容错校验的重构应答,包括:根据源区块链子网节点列表中包含的各源子网节点对应的公钥,对所述获得的重构应答对应的共识签名信息进行验签;在所述获得的重构应答中内容相同的重构应答超过第二预设数量且对应的共识签名信息验签成功的情况下,将所述内容相同的重构应答之一确定为所述认证应答。
本说明书实施例所涉及的源区块链子网节点列表包含源区块链子网的节点成员信息,例如节点ID、节点公钥、通讯地址等,该源区块链子网节点列表与目的区块子网节点列表类似,同样可以被维护在区块链主网的子网管理合约的合约状态中,因此源子网节点在使用源区块链子网节点列表进行验签和拜占庭容错校验之前,也需要指定使用的源区块链节点列表是哪一区块高度所锚定的,例如源子网节点可以首先确定第二区块高度,然后指定区块链主网于第二区块高度下所维护的源区块链子网节点列表为后续所需使用进行验签和拜占庭容错校验的源区块子网节点列表。类似的,源子网节点获取区块链主网上维护的源区块链子网节点列表也是通过访问自身所处节点设备上部署的主网节点所实现。源区块链子网节点列表还可以被维护在源子网节点自身维护的节点成员信息中,该节点成员信息同样会随着源区块链子网区块高度的更新而发生变化。
在本说明书实施例中,第二预设数量通过所述源区块链子网节点列表包含的所述源区块链子网对应的第二节点总数所确定。具体而言,在针对重构应答的拜占庭容错校验中,假设所述源区块链子网对应的第二节点总数,即源区块链子网中包含的所有源子网节点的数量为3b(b为正整数),那么第二预设数量应为b。
可选的,所述重构应答还包含第二区块高度,第二区块高度为所述源子网节点构造重构应答时所述源区块链子网或所述主网节点所维护的最新区块的区块高度,第二区块高度用于在审计过程中获取所述源区块链子网节点列表。在本说明书实施例中,重构应答不仅会包括用于获取目的区块链子网节点列表的第一区块高度,还包括用于获取源区块链子网节点列表的第二区块高度,由此源子网节点可以直接在未验签的情况下对获取得到的重构应答中的第二区块高度进行统计,将占多数且内容相同的第二区块高度确定为最终获取源区块链子网列表的区块高度。在第二区块高度为所述源子网节点构造重构应答时所述主网节点所维护的最新区块的区块高度的情况下,源子网节点就直接从自身所处节点设备上部署的主网节点获取该主网节点在第二区块高度下维护的源区块链子网节点列表;在第二区块高度为所述源子网节点构造重构应答时所述源区块链子网所维护的最新区块的区块高度的情况下,源子网节点获取自身在第二区块高度下维护的源区块链子网节点列表。
步骤708,所述源子网节点对所述跨子网请求、所述认证应答、验签成功且通过拜占庭容错校验的所有跨子网应答对应的应答签名信息以及验签成功且通过拜占庭容错校验的所有重构应答对应的共识签名信息进行存证。
源子网节点可以将所述跨链请求、所述认证应答、验签成功且通过拜占庭容错校验的所有跨链应答对应的应答签名信息以及验签成功且通过拜占庭容错校验的所有重构应答对应的共识签名信息存证至所处节点设备上部署的通讯插件、自身维护的跨子网合约、和/或触发调用跨子网合约进行跨链交互的业务合约中,以便后续提供至其他验证方对所述跨链请求的认证应答进行合法性验证。
在本说明书实施例中,源子网节点会基于各目的子网节点响应跨链请求返回的跨链应答进行验签和拜占庭校验,从而确保跨链应答可信,然而不同的源子网节点在进行验签和拜占庭校验时所使用的目的区块链子网节点列表可能有差异,这使得单个源子网节点无法确保自身进行验签和拜占庭校验的有效性,因此本说明书实施例进一步提出了源子网节点还会将确定得到的标准跨链应答与第一区块高度构成重构应答并在源子网内部进行基于拜占庭容错原则的共识校验,从而使得源子网能够最终确定出一个经过源区块链子网中所有源子网节点所共同认可的重构应答作为所述跨链请求的认证应答,从而解决了不同源子网节点所确定的目标区块链子网节点列表不一致的失信问题,在保障区块链去中心化特性下完成了可靠、可监管的跨链通信。同时,最终对所述跨链请求、所 述认证应答、验签成功且通过拜占庭容错校验的所有跨链应答对应的应答签名信息以及验签成功且通过拜占庭容错校验的所有重构应答对应的共识签名信息进行存证,也使得后续能够向验证方提供针对某跨链请求的可信验证,确保跨链过程中全流程数据的可追踪、可查和可验证。
可选的,还包括:所述源子网节点调用所述跨子网合约中的回调方法,将所述认证应答返回至所述业务合约。在本说明书实施例中,跨子网合约在被业务合约调用并触发跨链交互的处理逻辑后,会在跨链请求对应的认证应答生成后,将所述认证应答基于所述跨子网合约的回调方法返回至所述业务合约,该回调方法可以采用前述的本地交易的方式,将携带有所述认证应答的本地交易返回至所述业务合约,从而使业务合约获取其跨链需求对应的数据。当然,所述源子网节点还可以调用所述跨子网合约中的回调方法,将验签成功且通过拜占庭容错校验的所有跨链应答对应的应答签名信息以及验签成功且通过拜占庭容错校验的所有重构应答对应的共识签名信息返回至所述业务合约,以使业务合约能够对跨链交互的全流程和认证应答进行合法性验证。
可选的,所述响应于所述跨链请求返回的跨链应答包括所述跨链请求的描述信息,其中,所述跨链请求的描述信息包括所述跨链请求的请求标识或所述跨链请求。在本说明书实施例中,为了使源子网节点接收到的跨链应答与跨链请求之间的关联可信,可以使目的子网节点在返回的跨链应答中携带所述跨链请求的描述信息或所述跨链请求本身。
进一步的,在所述跨链请求的描述信息为所述跨链请求的请求标识的情况下,所述方法还包括:所述源子网节点获取所述各目的子网节点分别响应于所述跨链请求返回的请求签名信息,所述请求签名信息由所述各目的子网节点针对包含所述请求标识的所述跨链请求分别进行签名得到;所述源子网节点根据所述目的区块链子网节点列表对所述请求签名信息进行验签及拜占庭容错校验,并在验签成功且通过拜占庭容错校验的情况下,确定所述跨链请求与所述请求标识之间的关联可信。如前所述,跨链应答中可以包括跨链请求的描述信息,在该描述信息本身与跨链请求具有强关联的情况下,例如描述信息即跨链请求或跨链请求对应的哈希值,那么跨链请求对应的描述信息与跨链请求之间的关联性就无需额外证明,但假如描述信息与跨链请求之间只有弱关联,例如跨链请求对应的描述信息为该跨链请求对应的请求标识(由源子网节点自行分配并维护请求标识与跨链请求之间的对应关系),那么此时跨链请求对应的描述信息与跨链请求之间的关联性就是不可靠的,需要额外提供信任凭证。在本说明书实施例中,目的子网节点响应于接收到的跨链请求中包含有请求标识,此时目的子网节点不仅会返回跨链应答,还会返回根据自身节点私钥对该跨链请求进行签名得到的请求签名信息,源子网节点在接收到各目的子网节点返回的若干请求签名信息后,可以根据目的区块链子网节点列表对所述若干请求签名信息进行验签,并在确定验签得到的内容相同的解密值(利用目的子网节点的节点公钥对请求签名信息进行解密得到的解密值)超过第一预设数量、且该解密值为所述跨链请求或所述跨链请求对应的哈希值的情况下,确定所述请求签名信息验签成功且通过拜占庭容错校验,由于包含有对应请求标识的跨链请求被各目的子网节点所认可,因此这种情况下可以确定所述跨链请求与所述请求标识之间的关联可信,从而可以使验证方能够基于请求签名信息检测出源子网节点维护有错误的请求标识与跨链请求之间的对应关系的情况,防止源区块链子网中存在节点叛变或出错所带来的失信问题。
在本说明书实施例中,源子网节点会基于各目的子网节点响应跨链请求返回的跨链应答进行验签和拜占庭校验,从而确保跨链应答可信,然而不同的源子网节点在进行验签和拜占庭校验时所使用的目的区块链子网节点列表可能有差异,这使得单个源子网节点无法确保自身进行验签和拜占庭校验的有效性,因此本说明书实施例进一步提出了源子网节点还会将确定得到的标准跨链应答与第一区块高度构成重构应答并在源子网内部进行基于拜占庭容错原则的共识校验,从而使得源子网能够最终确定出一个经过源区块链子网中所有源子网节点所共同认可的重构应答作为所述跨链请求的认证应答,从而解决了不同源子网节点所确定的目标区块链子网节点列表不一致的失信问题,在保障区块链去中心化特性下实现了可靠、可监管的跨链通信。同时,最终对所述跨链请求、所述认证应答、验签成功且通过拜占庭容错校验的所有跨链应答对应的应答签名信息以及验签成功且通过拜占庭容错校验的所有重构应答对应的共识签名信息进行存证,也使得后续能够向验证方提供针对某跨链请求的可信验证,确保跨链过程中全流程数据的可追踪、可查和可验证。
与上述方法实施例相对应,本说明书还提供了相应的装置实施例。
图8是一示例性实施例提供的一种设备的示意结构图。请参考图8,在硬件层面,该设备包括处理器802、内部总线804、网络接口806、内存808以及非易失性存储器 810,当然还可能包括其他业务所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现,比如由处理器802从非易失性存储器810中读取对应的计算机程序到内存808中然后运行。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
请参考图9,跨子网交互的权限控制装置可以应用于如图8所示的设备中,以实现本说明书的技术方案。其中,该装置可以包括:接收单元91,使区块链主网的目的区块链子网中目的子网节点接收所述区块链主网的源区块链子网中源子网节点发送的跨子网请求,所述跨子网请求包括针对所述目的区块链子网的写入操作的操作信息;查询单元92,使所述目的子网节点查询所述区块链主网的各个区块链子网针对所述目的区块链子网的写入操作的权限信息,并根据所述权限信息对所述操作信息进行校验;写入单元93,使所述目的子网节点在校验通过的情况下响应于所述跨子网请求,根据所述操作信息执行相应的写入操作。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个......”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在......时”或“当......时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (26)

  1. 一种跨子网交互的权限控制方法,应用于区块链系统,所述区块链系统包括区块链主网及其管理的区块链子网;所述方法包括:
    目的区块链子网中的目的子网节点接收源区块链子网中的源子网节点发送的跨子网请求,所述跨子网请求包括针对所述目的区块链子网的写入操作的操作信息;
    所述目的子网节点查询所述区块链主网所管理的各个区块链子网针对所述目的区块链子网的写入操作的权限信息,并根据所述权限信息对所述操作信息进行校验;
    所述目的子网节点在校验通过的情况下响应于所述跨子网请求,根据所述操作信息执行相应的写入操作。
  2. 根据权利要求1所述的方法,所述跨子网请求由所述源区块链子网的源子网节点通过以下方式生成:
    响应于提交至所述源区块链子网的第一区块链交易,执行第一区块链交易调用的智能合约以生成包含所述操作信息的事件;
    在监听到所述事件后,读取所述事件中包含的操作信息以生成所述跨子网请求。
  3. 根据权利要求1所述的方法,所述目的子网节点查询所述区块链主网的各个区块链子网针对所述目的区块链子网的写入操作的权限信息,包括:
    所述目的子网节点查询部署于所述目的区块链子网上的第一写入控制合约记录的所述权限信息;
    或者,所述目的子网节点查询预设缓存中存储的所述权限信息,所述预设缓存用于存储第一写入控制合约记录的权限信息;
    或者,所述目的子网节点查询部署于所述区块链主网上的第二写入控制合约记录的所述权限信息。
  4. 根据权利要求3所述的方法,所述目的子网节点查询部署于所述目的区块链子网上的第一写入控制合约记录的所述权限信息,包括:
    所述目的子网节点创建本地查询交易,以在本地存储的对应于所述目的区块链子网的世界状态中查询第一写入控制合约记录的所述权限信息。
  5. 根据权利要求3所述的方法,所述目的子网节点更新所述预设缓存的操作包括:
    在监听到第一写入控制合约生成的针对所述权限信息的更新事件的情况下,根据所述更新事件记录的更新信息更新所述预设缓存;其中,所述更新事件由第一写入控制合约在响应针对所述权限信息的更新交易的情况下生成。
  6. 根据权利要求3所述的方法,部署所述区块链主网中主网节点的节点设备还用于部署区块链子网的子网节点,且部署于任一节点设备的主网节点和子网节点共享所述任一节点设备的区块链插件;所述目的子网节点查询部署于所述区块链主网上的第二写入控制合约记录的所述权限信息,包括:
    所述目的子网节点通过所述目的子网节点所属的目标节点设备中的区块链插件,在所述目标节点设备部署的主网节点在本地存储的对应于所述区块链主网的世界状态中,查询第二写入控制合约记录的所述权限信息。
  7. 根据权利要求1所述的方法,所述写入操作包括:写入所述目的区块链子网上部署的智能合约,或者,写入所述目的区块链子网的区块。
  8. 根据权利要求1所述的方法,所述权限信息的权限控制维度包括以下至少之一:
    发起所述跨子网请求的区块链子网的子网标识、发起写入操作的区块链子网的区块链账户、请求写入的区块链子网的区块链账户、请求写入的参数类型。
  9. 根据权利要求1所述的方法,所述根据所述操作信息执行相应的写入操作,包括:
    在包含所述操作信息的第二区块链交易通过共识的情况下,响应于第二区块链交易,根据所述操作信息执行相应的写入操作,第二区块链交易由所述目的区块链子网的主节点响应于所述跨子网请求而在所述目的区块链子网内发起。
  10. 根据权利要求1所述的方法,还包括:
    所述源子网节点获取各个目的子网节点分别响应于所述跨子网请求返回的跨子网应答,根据所述源子网节点所处节点设备上部署的主网节点在第一区块高度所维护的目的区块链子网节点列表对获取到的跨子网应答进行验签及拜占庭容错校验,并将验签成功且通过拜占庭容错校验的标准跨子网应答和第一区块高度构造为重构应答;
    所述源子网节点在所述源区块链子网中广播所述重构应答,并接收所述源区块链子网中的其他子网节点广播的重构应答;
    所述源子网节点根据源区块链子网节点列表对获取到的重构应答进行验签及拜占庭容错校验,并将验签成功且通过拜占庭容错校验的重构应答确定为响应所述跨子网请求的认证应答;
    所述源子网节点对所述跨子网请求、所述认证应答、验签成功且通过拜占庭容错校验的所有跨子网应答对应的应答签名信息以及验签成功且通过拜占庭容错校验的所有重构应答对应的共识签名信息进行存证。
  11. 根据权利要求10所述的方法,所述源区块链子网中的至少一个源子网节点向目的区块链子网发起跨子网请求,包括:
    所述源区块链子网中的至少一个源子网节点在其维护的业务合约执行过程中触发生成针对所述目的区块链子网的跨子网请求的情况下,调用跨子网合约将所述跨子网请求发送至所述各个目的子网节点。
  12. 根据权利要求11所述的方法,所述方法还包括:
    调用所述跨子网合约中的回调方法,将所述认证应答返回至所述业务合约。
  13. 根据权利要求10所述的方法,第一区块高度为所述源子网节点对获取到的跨子网应答进行验签及拜占庭容错校验时所述主网节点所维护的最新区块的区块高度;或者,
    第一区块高度为所述源子网节点按照预设的区块选取规则从所述主网节点所维护的区块中所选取的目标区块的区块高度。
  14. 根据权利要求10所述的方法,所述重构应答还包含第二区块高度,第二区块高度为所述源子网节点构造重构应答时所述源区块链子网或所述主网节点所维护的最新区块的区块高度,第二区块高度用于在审计过程中获取所述源区块链子网节点列表。
  15. 根据权利要求10所述的方法,所述响应于所述跨子网请求返回的跨子网应答包括所述跨子网请求的描述信息,其中,所述跨子网请求的描述信息包括所述跨子网请求的请求标识或所述跨子网请求。
  16. 根据权利要求15所述的方法,在所述跨子网请求的描述信息为所述跨子网请求的请求标识的情况下,所述方法还包括:
    所述源子网节点获取所述各个目的子网节点分别响应于所述跨子网请求返回的请求签名信息,所述请求签名信息由所述各个目的子网节点针对包含所述请求标识的所述跨子网请求分别进行签名得到;
    所述源子网节点根据所述目的区块链子网节点列表对所述请求签名信息进行验签及拜占庭容错校验,并在验签成功且通过拜占庭容错校验的情况下,确定所述跨子网请求与所述请求标识之间的关联可信。
  17. 根据权利要求1所述的方法,所述源子网节点存证有所述源区块链子网向所述目的区块链子网中各目的子网节点发送的跨子网请求及其对应的认证应答、验签成功且通过拜占庭容错校验的所有跨子网应答对应的应答签名信息以及验签成功且通过拜占庭容错校验的所有重构应答对应的共识签名信息;其中,所述认证应答为所述源区块链子网中的源子网节点构造的所有重构应答中基于源区块链子网节点列表验签成功且通过拜占庭容错校验的重构应答;其中,任一源子网节点构造的重构应答包括:所述任一源子网节点选取的区块高度以及所述任一源子网节点根据自身所处节点设备上部署的主网节点在选取的区块高度所维护的目的区块链子网节点列表对获取到的跨子网应答进行验签及拜占庭容错校验后得到的验签成功且通过拜占庭容错的标准跨子网应答,所述跨子网应答由所述各目的子网节点分别响应于所述跨子网请求返回至所述任一源子网节点;所述方法还包括:
    所述源子网节点接收针对所述跨子网请求的审计请求;
    响应于所述审计请求获取所述源子网节点存证的所述跨子网请求及其对应的所述认证应答、应答签名信息以及共识签名信息,所述认证应答包括第一区块高度和待验证跨子网应答;
    其中,所述认证应答通过审计的条件包括:根据所述共识签名信息和源区块链子网节点列表确定所述认证应答验签成功且通过拜占庭容错校验,且根据所述应答签名信息和所述区块链主网在第一区块高度下维护的目的区块链子网节点列表确定所述待验证跨子网应答验签成功且通过拜占庭容错校验。
  18. 根据权利要求17所述的方法,所述任一源子网节点选取的区块高度为所述任一源子网节点对获取到的跨子网应答进行验签及拜占庭容错校验时所述主网节点所维护的最新区块的区块高度;或者,
    所述任一源子网节点选取的区块高度为所述任一源子网节点按照预设的区块选取规则从所述主网节点所维护的区块中所选取的目标区块的区块高度。
  19. 根据权利要求17所述的方法,所述任一源子网节点构造的重构应答还包含:所述任一源子网节点构造重构应答时所述任一源子网节点或所述主网节点所维护的最新区块的区块高度;所述认证应答还包含第二区块高度,该第二区块高度用于在针对所述认证应答进行审计的过程中确定所述源区块链子网节点列表。
  20. 根据权利要求17所述的方法,还包括:
    根据获取的所述跨子网请求及其对应的所述认证应答、应答签名信息以及共识签名信息验证所述认证应答的可信情况;或者,
    将获取的所述跨子网请求及其对应的所述认证应答、应答签名信息以及共识签名信息提供给所述审计请求对应的发起方。
  21. 根据权利要求17所述的方法,所述跨子网应答包括所述跨子网请求的描述信息,其中,所述跨子网请求的描述信息包括所述跨子网请求的请求标识或所述跨子网请求。
  22. 根据权利要求21所述的方法,在所述跨子网请求的描述信息为所述跨子网请求的请求标识的情况下,所述跨子网请求包含所述请求标识,所述源子网节点还存证有所述请求标识以及由所述各目的子网节点分别对接收到的所述跨子网请求进行签名并返回至所述源子网节点的请求签名信息;
    所述认证应答通过审计的条件还包括:根据所述请求签名信息和所述源区块链子网节点列表确定所述跨子网请求验签成功且通过拜占庭容错校验。
  23. 根据权利要求17所述的方法,所述源子网节点所处的节点设备上还部署有所述区块链主网中的主网节点,所述方法还包括:
    从所述源子网节点所处的节点设备上部署的主网节点处获取所述目的区块链子网节点列表。
  24. 一种跨子网交互的权限控制装置,包括:
    接收单元,使区块链主网的目的区块链子网中目的子网节点接收所述区块链主网的源区块链子网中源子网节点发送的跨子网请求,所述跨子网请求包括针对所述目的区块链子网的写入操作的操作信息;
    查询单元,使所述目的子网节点查询所述区块链主网的各个区块链子网针对所述目的区块链子网的写入操作的权限信息,并根据所述权限信息对所述操作信息进行校验;
    写入单元,使所述目的子网节点在校验通过的情况下响应于所述跨子网请求,根据所述操作信息执行相应的写入操作。
  25. 一种电子设备,包括:
    处理器;
    用于存储处理器可执行指令的存储器;
    其中,所述处理器通过运行所述可执行指令以实现如权利要求1-23中任一项所述的方法。
  26. 一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如权利要求1-23中任一项所述方法的步骤。
PCT/CN2022/135831 2021-12-31 2022-12-01 跨子网交互的权限控制 WO2023124746A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111663685.4A CN114679274A (zh) 2021-12-31 2021-12-31 跨子网交互的权限控制方法及装置、电子设备、存储介质
CN202111663685.4 2021-12-31

Publications (1)

Publication Number Publication Date
WO2023124746A1 true WO2023124746A1 (zh) 2023-07-06

Family

ID=82070405

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135831 WO2023124746A1 (zh) 2021-12-31 2022-12-01 跨子网交互的权限控制

Country Status (2)

Country Link
CN (1) CN114679274A (zh)
WO (1) WO2023124746A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114679274A (zh) * 2021-12-31 2022-06-28 支付宝(杭州)信息技术有限公司 跨子网交互的权限控制方法及装置、电子设备、存储介质
CN115134075A (zh) * 2022-06-29 2022-09-30 蚂蚁区块链科技(上海)有限公司 跨子网调用方法、装置、电子设备和存储介质
CN115499180A (zh) * 2022-09-05 2022-12-20 深圳拓邦股份有限公司 一种令牌跨区域交换与鉴权方法和系统
WO2024197879A1 (zh) * 2023-03-31 2024-10-03 京东方科技集团股份有限公司 区块链数据处理方法、平台、系统、装置和电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200057860A1 (en) * 2018-08-20 2020-02-20 Cisco Technology, Inc. Blockchain-based auditing, instantiation and maintenance of 5g network slices
CN113626850A (zh) * 2021-10-13 2021-11-09 北京百度网讯科技有限公司 基于联盟链的请求处理方法、装置、设备和存储介质
CN114679274A (zh) * 2021-12-31 2022-06-28 支付宝(杭州)信息技术有限公司 跨子网交互的权限控制方法及装置、电子设备、存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110473096A (zh) * 2019-07-31 2019-11-19 阿里巴巴集团控股有限公司 基于智能合约的数据授权方法及装置
CN111181968B (zh) * 2019-12-30 2021-09-21 北京金山云网络技术有限公司 跨区块链通信方法、装置、跨链服务系统及跨链交易系统
CN113259460B (zh) * 2021-06-02 2021-10-15 支付宝(杭州)信息技术有限公司 跨链交互方法及装置
CN113259463B (zh) * 2021-06-02 2021-11-02 支付宝(杭州)信息技术有限公司 跨链交互方法和区块链系统
CN113259461B (zh) * 2021-06-02 2021-09-28 支付宝(杭州)信息技术有限公司 跨链交互方法和区块链系统
CN113259453B (zh) * 2021-06-02 2021-10-15 支付宝(杭州)信息技术有限公司 跨链交互方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200057860A1 (en) * 2018-08-20 2020-02-20 Cisco Technology, Inc. Blockchain-based auditing, instantiation and maintenance of 5g network slices
CN113626850A (zh) * 2021-10-13 2021-11-09 北京百度网讯科技有限公司 基于联盟链的请求处理方法、装置、设备和存储介质
CN114679274A (zh) * 2021-12-31 2022-06-28 支付宝(杭州)信息技术有限公司 跨子网交互的权限控制方法及装置、电子设备、存储介质

Also Published As

Publication number Publication date
CN114679274A (zh) 2022-06-28

Similar Documents

Publication Publication Date Title
WO2022193985A1 (zh) 一种数据处理方法、装置、设备及存储介质
WO2023124746A1 (zh) 跨子网交互的权限控制
CN113259455B (zh) 跨子网交互方法及装置
CN113922971B (zh) 跨链交互方法及装置
CN113259460B (zh) 跨链交互方法及装置
CN113067902B (zh) 区块链消息的传输方法及装置
CN113259453B (zh) 跨链交互方法及装置
CN113067897B (zh) 跨链交互方法及装置
CN113055190B (zh) 针对客户端的访问控制方法
CN113259457B (zh) 区块链子网的信息同步方法及装置
CN113098982B (zh) 区块链消息的传输方法及装置
WO2024001022A1 (zh) 跨子网调用
CN113067838B (zh) 跨链交互方法及装置
CN113259454B (zh) 跨链交互方法及装置
CN113259464B (zh) 组建区块链子网的方法和区块链系统
CN113326290B (zh) 跨网查询控制方法
CN114363162A (zh) 区块链日志的生成方法及装置、电子设备、存储介质
CN113259463B (zh) 跨链交互方法和区块链系统
CN113259461B (zh) 跨链交互方法和区块链系统
CN113259462B (zh) 区块链消息的分发方法及装置
CN113067903B (zh) 组建区块链子网的方法和区块链系统
CN113098984B (zh) 基于注册机制形成多层区块链系统的方法和区块链系统
CN116743765A (zh) 区块链系统、跨链交互方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22914001

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE