Cross-chain calling method and device for smart contracts

Abstract

One or more embodiments of the present specification provide a cross-chain calling method and device for a smart contract, which is applied to a node device in any target member blockchain in a blockchain service network composed of several member blockchains; the method includes: obtaining call data of the contract caller for the contract execution logic contained in the user smart contract deployed on other member blockchains; in response to the call data, calling the identification generation logic contained in the system smart contract deployed on the target member blockchain, generating a global link identification corresponding to the call data, and calling the cross-chain calling logic contained in the system smart contract, and based on the global link identification, initiating a cross-chain call for the user smart contract deployed on the other member blockchain, so as to associate the global link identification with the contract execution result of the user smart contract and store it on the other member blockchain.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method and device for cross-chain calling of smart contracts. Background Art

[0002] With the development of blockchain technology, more and more blockchains have been established. However, most of these blockchains are independent and cannot connect to each other. Therefore, in practical applications, to fully utilize the service resources deployed on each blockchain, these blockchains can be organized as member blockchains into a mutually connected blockchain service network. The contract execution logic contained in the smart contracts deployed on each member blockchain can be made available to users as user services through the management platform of this blockchain service network. However, in this multi-chain and cross-chain interconnection, users and user services are effectively separated. In other words, each cannot perceive the data processing performed on the other blockchain, and mutual trust cannot be achieved. Summary of the Invention

[0003] One or more embodiments of this specification provide the following technical solutions:

[0004] This specification provides a method for cross-chain invocation of a smart contract, the method being applied to a node device in any target member blockchain of a blockchain service network composed of multiple member blockchains; wherein user smart contracts and system smart contracts are deployed on each member blockchain of the blockchain network; the system smart contract includes cross-chain invocation logic corresponding to the contract execution logic included in the user smart contract deployed on at least some of the member blockchains of the blockchain service network;

[0005] The method comprises:

[0006] Obtain the call data of the contract caller for the contract execution logic contained in the user smart contract deployed on other member blockchains;

[0007] In response to the call data, the identifier generation logic contained in the system smart contract deployed on the target member blockchain is called to generate a global link identifier corresponding to the call data, and the cross-chain call logic contained in the system smart contract is called. Based on the global link identifier, a cross-chain call is initiated for the user smart contract deployed on the other member blockchain, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchain.

[0008] This specification also provides a cross-chain call tracing method for a smart contract, the method being applied to an off-chain service end accessing a blockchain service network composed of several member blockchains; wherein user smart contracts and system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract includes cross-chain call logic corresponding to the contract execution logic included in the user smart contract deployed on at least some of the member blockchains in the blockchain service network; the cross-chain call logic is used to initiate a cross-chain call to a user smart contract deployed on other member blockchains based on a global link identifier, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchains;

[0009] The method comprises:

[0010] Obtaining a query request for contract execution results stored on each member blockchain in the blockchain network; wherein the query request includes a global link identifier;

[0011] Based on the global link identifier in the query request, a contract execution result associated with the global link identifier is obtained from each member blockchain in the blockchain network.

[0012] This specification also provides a cross-chain calling device for a smart contract, the device being applied to a node device in any target member blockchain in a blockchain service network composed of several member blockchains; wherein user smart contracts and system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract includes cross-chain calling logic corresponding to the contract execution logic included in the user smart contract deployed on at least some of the member blockchains in the blockchain service network;

[0013] The device comprises:

[0014] The acquisition module obtains the call data of the contract execution logic contained in the user smart contract deployed on other member blockchains by the contract caller;

[0015] The calling module, in response to the calling data, calls the identification generation logic contained in the system smart contract deployed on the target member blockchain, generates a global link identifier corresponding to the calling data, and calls the cross-chain calling logic contained in the system smart contract, and initiates a cross-chain call to the user smart contract deployed on the other member blockchain based on the global link identifier, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchain.

[0016] This specification also provides a cross-chain call tracking device for a smart contract, the device being applied to an off-chain service end accessing a blockchain service network composed of several member blockchains; wherein user smart contracts and system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract includes cross-chain call logic corresponding to the contract execution logic included in the user smart contract deployed on at least some of the member blockchains in the blockchain service network; the cross-chain call logic is used to initiate a cross-chain call to a user smart contract deployed on other member blockchains based on a global link identifier, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchains;

[0017] The device comprises:

[0018] An acquisition module is configured to acquire a query request for a contract execution result stored on each member blockchain in the blockchain network; wherein the query request includes a global link identifier;

[0019] The query module obtains the contract execution result associated with the global link identifier from each member blockchain in the blockchain network based on the global link identifier in the query request.

[0020] This specification also provides an electronic device, including:

[0021] processor;

[0022] a memory for storing processor-executable instructions;

[0023] The processor implements the steps of any of the above methods by running the executable instructions.

[0024] This specification also provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0025] In the above technical solution, the contract caller can call the system smart contract, and the system smart contract can generate a global link identifier corresponding to this call, and based on the global link identifier, initiate a cross-chain call to the user smart contract deployed on other member blockchains, so that the user smart contract deployed on the other member blockchain can associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchain.

[0026] By adopting the above method, in the case of multi-chain cross-chain interconnection, the data associated with the global link identifier stored on all member blockchains in the blockchain service network can be aggregated through the global link identifier, thereby enabling the contract caller and the called user smart contract to perceive the data processing performed by the other party on the corresponding blockchain, thereby achieving mutual trust. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 This is a network architecture diagram of a blockchain service network shown in an exemplary embodiment of this specification.

[0028] Figure 2 This is a flowchart of a method for establishing a blockchain service network shown in an exemplary embodiment of this specification.

[0029] Figure 3 This is a flowchart of a registration process for a target blockchain shown in an exemplary embodiment of this specification.

[0030] Figure 4 This is a schematic diagram of an exemplary embodiment of this specification showing a method of setting a service interface for user services and binding contract execution logic to the service interface.

[0031] Figure 5 The flowchart of a service registration method according to an exemplary embodiment of the present specification is shown.

[0032] Figure 6 This is a flowchart of a cross-chain calling method for a smart contract shown in an exemplary embodiment of this specification.

[0033] Figure 7 This is a flowchart of a cross-chain call tracing method for a smart contract shown in an exemplary embodiment of this specification.

[0034] Figure 8 This is a hardware structure diagram of an electronic device where a cross-chain calling device for a smart contract is located, as shown in an exemplary embodiment of this specification.

[0035] Figure 9 This is a block diagram of a cross-chain calling device for a smart contract shown in an exemplary embodiment of this specification.

[0036] Figure 10 This is a block diagram of a cross-chain call tracking device for a smart contract shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0037] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

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

[0039] To integrate the service capabilities of user smart contracts deployed on different blockchains and fully utilize the service resources deployed on each blockchain, these blockchains can usually be organized into a interconnected blockchain service network as member blockchains. The contract execution logic contained in the smart contracts deployed on each member blockchain is then serviced through the management platform of the blockchain service network and made available to users in the form of user services for them to call. In actual applications, when servitizing the contract execution logic contained in the smart contracts deployed on each member blockchain, this can be done by registering a user-oriented user service on the blockchain service network's management platform, directly binding this user service to the contract execution logic to be serviced, and then making this user service available to users.

[0040] Since the user service that has been registered needs to be opened to users eventually, if the user service is directly bound to the contract execution logic that needs to be serviced, the information related to the contract execution logic bound to the user service will inevitably be exposed to the user, thereby facing the risk of privacy exposure.

[0041] Therefore, in the application scenario of servitizing the contract execution logic contained in the smart contract deployed on the blockchain, the contract execution logic that needs to be serviced can be bound to the service interface of the user service open to users, and when the user service is called, the contract execution logic to be called can be dynamically determined from the contract execution logic bound to the service interface of the user service.

[0042] Specifically, the contract execution logic contained in user smart contracts deployed on at least some member blockchains of the blockchain service network can still be openly invoked as user services. The contract execution logic corresponding to the user service can no longer be directly bound to the user service, but instead can be bound to the service interface corresponding to the user service.

[0043] When a node device in any target member blockchain in the blockchain service network receives call data initiated by a service user for a service interface containing the user service, it can respond to the call data and determine a target contract execution logic that can be called for the service user from the contract execution logic contained in the user smart contract deployed on other member blockchains that is bound to the service interface. It then initiates a cross-chain call to the user smart contract containing the target contract execution logic deployed on the above-mentioned other member blockchains to complete the service call for the user service.

[0044] On the one hand, since the blockchain service network supports the service-oriented contract execution logic contained in the user smart contracts deployed on each member blockchain, it is open for call in the form of user services, and the contract execution logic corresponding to the user service can no longer be directly bound to the user service, but can be bound to the service interface corresponding to the user service; therefore, when the user service is opened to the service user, only the service interface corresponding to the user service can be exposed to the service user, and the information related to the contract execution logic bound to the service interface can no longer be exposed to the service user, thereby avoiding privacy leakage caused by directly exposing the information related to the contract execution logic corresponding to the user service to the service user.

[0045] For example, if the contract execution logic corresponding to the user service is an executable function, if the user service is directly bound to these executable functions, the function names and other related information of these functions will inevitably be exposed to the user. However, if the user service is bound to the service interface, the service interface and even the functional descriptions of these functions need only be exposed to the user, while the actual content of these functions, such as the function names, does not need to be exposed to the user.

[0046] On the other hand, when the service user calls the contract execution logic bound to the service interface of the user service through the system smart contract across the chain, the contract execution logic finally called is dynamically determined by the system smart contract from the contract execution logic bound to the service interface; therefore, in this way, the flexibility of the above-mentioned user service when being called can be improved.

[0047] For example, in actual applications, the service interface can be bound to multiple contract execution logics with the same service functions, so that the system smart contract can flexibly specify a contract execution logic for the user to call from the multiple contract execution logics bound to the service interface according to specific needs. This calling method is obviously more flexible.

[0048] Moreover, in this way, the service user cannot perceive in advance the smart contract where the contract execution logic is called, nor the member blockchain where the smart contract is located; therefore, this cross-chain contract calling method will have higher privacy and security.

[0049] For example, if the contract execution logic corresponding to the user service described above is an executable function, when the user calls the user service, the function assigned by the system smart contract from the executable functions bound to the service interface of the user service is completely uncertain to the user, and the user cannot know this information in advance. Therefore, this calling method clearly has a certain degree of concealment, which can fully ensure the privacy and security of these contract execution logic when it is called.

[0050] However, in the case of multi-chain cross-chain connectivity as mentioned above, users and user services are actually separated, that is, each party cannot perceive the data processing performed by the other party on the corresponding blockchain, and mutual trust cannot be achieved.

[0051] This specification proposes a technical solution for cross-chain smart contract invocation. This solution enables users and user services to perceive the data processing performed by each other on their respective blockchains when multiple chains are interconnected, thereby achieving mutual trust. In this technical solution, a contract caller can invoke a system smart contract, which generates a global link identifier corresponding to the invocation. Based on this global link identifier, the caller can initiate a cross-chain invocation of a user smart contract deployed on another member blockchain. The user smart contract deployed on the other member blockchain then associates the global link identifier with the contract execution result of the user smart contract and stores it on the other member blockchain.

[0052] In specific implementation, the contract caller can initiate a contract call for the above-mentioned system smart contract by submitting the call data of the contract execution logic contained in the user smart contract deployed on other member blockchains to the node device in the target member blockchain to which it is connected, so as to complete the cross-chain call of the user smart contract deployed on other member blockchains.

[0053] After receiving the call data submitted by the contract caller, the node device in the target member blockchain can respond to the call data by invoking the identifier generation logic contained in the system smart contract to generate a global link identifier corresponding to the call data. Furthermore, the node device in the target member blockchain can invoke the cross-chain call logic contained in the system smart contract to initiate a cross-chain call to the user smart contract deployed on the other member blockchain based on the global link identifier. For the user smart contract deployed on the other member blockchain, after being cross-chain called, the user smart contract can perform corresponding data processing based on the contract execution logic contained in the user smart contract, and store the global link identifier in association with the contract execution result of the user smart contract on the other member blockchain.

[0054] By adopting the above method, in the case of multi-chain cross-chain interconnection, the data associated with the global link identifier stored on all member blockchains in the blockchain service network can be aggregated through the global link identifier, thereby enabling the contract caller and the called user smart contract to perceive the data processing performed by the other party on the corresponding blockchain, thereby achieving mutual trust.

[0055] See Figure 1 , Figure 1 This is a network architecture diagram of a blockchain service network shown in an exemplary embodiment of this specification.

[0056] like Figure 1 As shown, in the network architecture of the above-mentioned blockchain service network, it can include a blockchain service network composed of several member blockchains, a target blockchain network to be registered, and a centralized control platform for managing the blockchain service network.

[0057] The centralized control platform can be a service platform for centralized management of the blockchain service network. The hardware device that hosts the centralized control platform can be a server or a server cluster composed of multiple servers, which is not specifically limited in this specification.

[0058] As a centralized service platform, the centralized management and control platform can manage the membership of the blockchain service network. For example, it can be responsible for the registration and joining and exit of member blockchains in the blockchain service network.

[0059] In addition, the aforementioned centralized management and control platform can also be used to achieve cross-chain access between member blockchains;

[0060] For example, in practical applications, the aforementioned centralized control platform can typically implement management functions for each member blockchain by issuing and deploying system smart contracts to each member blockchain. Managing cross-chain access between member blockchains is also a common management function of the centralized control platform for each member blockchain. Therefore, in this case, the aforementioned centralized control platform can also issue and deploy system smart contracts for cross-chain data access to each member blockchain, allowing each member blockchain network to achieve cross-chain data access with other member blockchains based on the deployed system smart contracts.

[0061] Of course, in addition to implementing management functions for each member blockchain by issuing and deploying system smart contracts to each member blockchain, the centralized management and control platform can also be equipped with a cross-chain service component, which can be used specifically to enable cross-chain data exchange between member blockchains. Each member blockchain joining the Blockchain Service Network can achieve cross-chain data access with other member blockchains through the cross-chain service component on the centralized management and control platform.

[0062] Please continue to see Figure 1 It should be noted that, in the initial case, there may be no member blockchains in the blockchain service network. The target blockchain can only join the blockchain service network after completing registration through the centralized management and control platform.

[0063] in, Figure 1 The first member blockchain, the second member blockchain, and the third member blockchain shown in the figure refer to member blockchains that have joined the above-mentioned blockchain service network. Figure 1 The target blockchain network to be registered shown in the figure refers to a blockchain network that has not yet joined the blockchain service network. The target blockchain network can apply to join the target blockchain network as a member blockchain by registering and interacting with the centralized management and control platform.

[0064] See Figure 2 , Figure 2 This is a flowchart of a method for establishing a blockchain service network as shown in an exemplary embodiment of this specification. This method can be applied to Figure 1 The centralized control platform shown; the method includes:

[0065] Step 202: Receive a registration request corresponding to the target blockchain.

[0066] The target blockchain can register as a member blockchain of the blockchain service network by interacting with the centralized control platform of the blockchain service network and sending a registration request to the centralized control platform.

[0067] The registration request may be initiated by a user with registration authority for the target blockchain through a user account registered on the centralized management and control platform.

[0068] For example, in actual applications, users with registration permissions for the target blockchain and user accounts registered on the centralized control platform may specifically include system administrator accounts on the centralized control platform, administrator accounts registered on the centralized control platform by managers of the target blockchain, user accounts registered on the centralized control platform by deployers of user smart contracts on the target blockchain, etc. It should be noted that the user account that issues the registration request specifically refers to the centralized account registered on the centralized control platform, and not the blockchain account registered on each member blockchain.

[0069] The registration request may include some basic registration information related to the target blockchain to be registered. The basic registration information may specifically include the access address information of the target blockchain and the blockchain configuration information related to the target blockchain.

[0070] Of course, in actual applications, the registration request may include not only some basic registration information related to the target blockchain to be registered, but also other forms of registration information, which are not specifically limited in this specification. Specifically, the access address information of the target blockchain is used to establish a network connection with the centralized control platform. In actual applications, the access address information may include domain name information or IP address information corresponding to one or more node devices in the target blockchain, so that the centralized control platform can establish a communication connection with one or more node devices in the target blockchain based on the domain name information or IP address information.

[0071] The above-mentioned blockchain configuration information may specifically include any form of information that can be used to represent the basic configuration of the above-mentioned target blockchain; for example, the above-mentioned blockchain configuration information may specifically include the blockchain type information corresponding to the above-mentioned target blockchain, the protocol type information of the blockchain protocol adopted by the above-mentioned target blockchain, and the algorithm type information of the consensus algorithm adopted by the above-mentioned target blockchain, etc.

[0072] Step 204: In response to the registration request, registration processing is performed on the target blockchain to add the target blockchain as a member blockchain to the blockchain service network.

[0073] When the centralized management and control platform receives a registration request corresponding to the target blockchain, it can respond to the registration request and perform a legitimacy check on the registration request. For example, the legitimacy check on the registration request may specifically include checking whether the initiator of the registration request has the corresponding registration authority; and whether the data format in the registration request meets the preset rules or format requirements, etc.

[0074] After the centralized management and control platform completes the legitimacy check on the registration request, if the registration request passes the legitimacy check, the centralized management and control platform can further register the target blockchain based on the data content carried in the registration request to add the target blockchain as a member blockchain to the blockchain service network.

[0075] The registration process of the target blockchain by the centralized control platform may specifically include creating a blockchain account corresponding to the centralized control platform in the target blockchain.

[0076] For example, during implementation, a public-private key pair can be applied for the centralized control platform in the target blockchain. The private key is held by the management user of the centralized control platform. Then, a corresponding account address is calculated based on the public key (for example, the account address can usually be a hash value calculated from the public key). Then, a blockchain account corresponding to the account address is created in the target blockchain.

[0077] It should be noted that in blockchains that adopt an account model, the account types supported by the blockchain generally include external accounts and contract accounts. External accounts are accounts directly controlled by users, also known as user accounts. Contract accounts, on the other hand, are accounts created by users through external accounts and contain contract code (i.e., smart contracts). The blockchain account created in the target blockchain corresponding to the centralized control platform described above can specifically be an external account. Once a corresponding blockchain account is created for the centralized control platform in the target blockchain, the centralized control platform has obtained the legitimate user identity in the target blockchain, allowing the centralized control platform to initiate contract calls against the user's smart contracts deployed in the target blockchain based on the external account.

[0078] The registration process of the target blockchain performed by the centralized control platform may include, in addition to creating a blockchain account corresponding to the centralized control platform in the target blockchain, other forms of registration processing related to the registration process of the target blockchain.

[0079] For example, in one embodiment shown, the registration processing of the target blockchain by the centralized management and control platform may further include deploying at least one system smart contract in the target blockchain; wherein the at least one system smart contract may specifically be a target system smart contract for cross-chain communication with other member blockchains.

[0080] Of course, in addition to the target system smart contract used for cross-chain communication with other member blockchains, it can also include system smart contracts for implementing other basic management functions; for example, the above-mentioned at least one system smart contract can also include a smart contract for service management of the target blockchain, a system smart contract for network governance of the target blockchain network, and a smart contract for service incentives for users related to user services or service solutions registered on the centralized management and control platform, etc., which will not be listed one by one in this specification.

[0081] See Figure 3 , Figure 3 This is a flowchart of a registration process for a target blockchain shown in an exemplary embodiment of this specification, including the following execution steps:

[0082] Step 301: The registrant initiates a registration request corresponding to the target blockchain to the centralized platform.

[0083] After receiving the registration request, the centralized management and control platform may respond to the registration request and begin the registration process for the target blockchain. In this embodiment, the registration process for the target blockchain may include the following registration process flow shown in steps 302 to 306.

[0084] Step 302: Save the blockchain configuration information of the target blockchain.

[0085] Step 303: Establish a communication connection with at least some node devices in the target blockchain based on the access address information of the target blockchain.

[0086] As previously mentioned, the registration request may include certain blockchain configuration information related to the target blockchain; for example, the blockchain configuration information may include the target blockchain's access address information and configuration information related to the target blockchain. Upon receiving the registration request, the centralized management and control platform may obtain the blockchain configuration information included in the registration request and then execute subsequent registration processing for the target blockchain based on the obtained blockchain configuration information.

[0087] After receiving the above registration request, the centralized management and control platform can store the blockchain configuration information related to the target blockchain read from the registration request as the configuration information of the member blockchain in the local database.

[0088] For example, during implementation, the centralized management and control platform can maintain an information library for storing blockchain configuration information related to each member blockchain in the above-mentioned blockchain service network. The centralized management and control platform can read the blockchain configuration information related to the target blockchain from the above-mentioned registration request and store it in the information library as the blockchain configuration information of the member blockchain.

[0089] After the centralized management and control platform stores the blockchain configuration information related to the target blockchain as the configuration information of the member blockchain in the local database, it can further establish a communication connection with at least some of the node devices in the target blockchain based on the access address information of the above-mentioned target blockchain read from the registration request.

[0090] For example, as mentioned above, the access address information may specifically include domain name information or IP address information corresponding to one or more node devices in the target blockchain. The centralized management and control platform may establish a communication connection with one or more node devices in the target blockchain based on the domain name information or IP address information. During implementation, the centralized management and control platform may establish a communication connection with all node devices in the target blockchain, or may establish a communication connection with only some key node devices in the target blockchain (e.g., a full node that stores a complete blockchain ledger).

[0091] Step 304: Obtain blockchain data related to the target blockchain from a node device in the target blockchain based on the communication connection.

[0092] After establishing a communication connection with at least some of the node devices in the target blockchain, the centralized management and control platform can continue to obtain blockchain data related to the target blockchain from the node devices in the target blockchain based on the communication connection.

[0093] The blockchain data related to the target blockchain obtained from the node device in the target blockchain may include any form of data related to the target blockchain and is not particularly limited in this specification.

[0094] For example, in one example, the blockchain data related to the target blockchain obtained from the node device in the target blockchain may specifically include the complete blockchain ledger of the target blockchain, the authentication root data corresponding to the blockchain ledger of the target blockchain, and the public key data of each node device in the target blockchain, etc.

[0095] It should be noted that in the blockchain field, the authentication root data corresponding to the blockchain ledger can usually include the genesis block data in the blockchain ledger, the block header data of each block, etc., which can be used to authenticate the data stored in the blockchain ledger.

[0096] After obtaining blockchain data related to the target blockchain from the node devices in the target blockchain, the centralized management and control platform can store the obtained blockchain data in the database.

[0097] For example, as previously described, the centralized management and control platform may maintain a database for storing blockchain configuration information related to each member blockchain in the blockchain service network. The centralized management and control platform may read the blockchain configuration information related to the target blockchain from the registration request and store it in the database as the blockchain configuration information of the member blockchain. After obtaining blockchain data related to the target blockchain from the node devices in the target blockchain, the centralized management and control platform may also associate the obtained blockchain data with the blockchain configuration information related to the target blockchain in the database.

[0098] Step 305: Create a blockchain account corresponding to the centralized management and control platform on the target blockchain.

[0099] After the centralized control platform obtains blockchain data related to the target blockchain from the node devices in the target blockchain based on the aforementioned communication connection, it can also create a corresponding blockchain account for the centralized control platform on the target blockchain. The specific process of creating the blockchain account is not further described.

[0100] After a corresponding blockchain account is created for the centralized control platform on the target blockchain, the centralized control platform has obtained the legal user identity in the target blockchain and has the ability to call the user smart contract deployed on the target blockchain. Subsequently, the centralized control platform can initiate contract calls for the user smart contract deployed on the target blockchain based on the blockchain account.

[0101] Specifically, a blockchain account list may be maintained on the centralized control platform. This blockchain account list may include blockchain accounts corresponding to the centralized control platform created on each member blockchain. Once a corresponding blockchain account is created for the centralized control platform on the target blockchain, the blockchain account may be added to the blockchain account list for maintenance.

[0102] It should be noted that the blockchain accounts corresponding to the centralized control platform created on each member blockchain can be the same or different. For example, in one example, to facilitate account management, the blockchain accounts corresponding to the centralized control platform created on each member blockchain can default to the same preset blockchain account. For example, during implementation, each member blockchain can reserve a fixed blockchain account in advance as the blockchain account corresponding to the centralized control platform.

[0103] Step 306: Deploy at least one system smart contract in the target blockchain.

[0104] After creating a corresponding blockchain account for the centralized control platform on the target blockchain, the centralized control platform can also deploy at least one system smart contract on the target blockchain. This at least one system smart contract can specifically include a target system smart contract for cross-chain communication with other member blockchains.

[0105] Among them, in addition to including a target system smart contract for cross-chain communication with other member blockchains, the above-mentioned at least one system smart contract may also include a smart contract for service management of the target blockchain, a system smart contract for network governance of the target blockchain network, a system smart contract for service incentives for users related to user services registered on the centralized management and control platform, etc., which are not specifically limited in this specification.

[0106] Of course, in actual applications, the above-mentioned target system smart contract for cross-chain communication with other member blockchains, the smart contract for service management of the target blockchain, the system smart contract for network governance of the target blockchain network, and the system smart contract for service incentives for users related to user services registered on the centralized management and control platform can be integrated into a system smart contract.

[0107] For example, in actual applications, the cross-chain call logic used for cross-chain communication with other member blockchains, the service management logic for service management of the target blockchain, the network governance logic for network governance of the target blockchain network, and the service incentive logic for service incentives for users related to user services registered on the centralized management and control platform can be included in the same system smart contract.

[0108] It should be noted that the above-mentioned system smart contracts and the user smart contracts deployed on the above-mentioned target blockchain are two completely different types of smart contracts.

[0109] The contract execution logic contained in the above-mentioned system smart contracts is usually related to some management functions on the centralized control platform.

[0110] For example, the contract execution logic contained in the aforementioned system smart contract for network governance may be related to the centralized control platform's function of network governance over the aforementioned blockchain service network. Similarly, the contract execution logic contained in the aforementioned system smart contract for providing service incentives to users associated with user services registered on the centralized control platform may be related to the centralized control platform's function of providing service incentives to users associated with registered user services. The contract execution logic contained in the aforementioned user smart contract is typically related to the user service logic defined by the user on the member blockchain.

[0111] By deploying at least one system smart contract on the target blockchain, users on the target blockchain can also complete some operations related to the management functions on the centralized control platform on the target blockchain by calling the system smart contract deployed on the target blockchain.

[0112] Step 307: Return a successful registration message corresponding to the target blockchain to the registrant.

[0113] After the centralized management and control platform executes the registration processing procedures shown in steps 302 to 306 for the above-mentioned target blockchain, the above-mentioned target blockchain will be successfully added to the above-mentioned blockchain service network as a member blockchain.

[0114] In this case, the centralized management and control platform returns a successful registration message corresponding to the target blockchain to the registrant to notify the registrant that the target blockchain has successfully joined the blockchain service network as a member blockchain.

[0115] It should be noted that the order of the various registration processing procedures shown in steps 302 through 306 in the above embodiment is for illustrative purposes only and is not specifically limited in this specification. It is understood that in actual applications, the order of the various registration processing procedures shown in steps 302 through 306 in the above embodiment can be flexibly adjusted and interchanged based on actual registration requirements.

[0116] In this specification, multiple user smart contracts can be deployed on each member blockchain in the aforementioned blockchain service network. The contract execution logic corresponding to the contract code in these user smart contracts may typically include multiple contract execution logics corresponding to different basic service capabilities.

[0117] For example, in actual applications, the contract execution logic contained in a smart contract can usually be in the form of a function, and a smart contract can contain multiple functions corresponding to different service functions.

[0118] The centralized management and control platform can also support the servitization of the contract execution logic contained in user smart contracts deployed on at least some of the member blockchains of the blockchain service network. Accordingly, service providers can utilize this functionality supported by the centralized management and control platform to servitize the contract execution logic contained in user smart contracts deployed on at least some of the member blockchains, and then make it available to service users as user services for their invocation.

[0119] It should be noted that when servicing the contract execution logic contained in the user smart contracts on at least some of the member blockchains in the blockchain service network, it is possible to servicing a specific contract execution logic contained in a certain user smart contract, or to servicing a combination of multiple contract execution logics as a whole.

[0120] That is, the user service generated through service-oriented development can specifically refer to a service consisting of a specific contract execution logic contained in a user smart contract deployed on each member blockchain in the blockchain service network, or it can refer to a service generated by combining multiple contract execution logics contained in user smart contracts deployed on at least some of the member blockchains in the blockchain service network.

[0121] For example, in one example, suppose a user deploys a user smart contract on a member blockchain. The user smart contract contains multiple contract execution logics. In this case, the user can choose to service a specific contract execution logic contained in the user smart contract, register a user service bound to the contract execution logic on the above-mentioned centralized management and control platform, and open it to other users for other users to call.

[0122] In another example, suppose a user has deployed multiple user smart contracts on each member blockchain, or the user has access to multiple user smart contracts deployed by other users on each member blockchain. In this case, the user can choose to combine the multiple contract execution logics contained in the above multiple user smart contracts into a user service, and register a user service bound to the above multiple contract execution logics on the above centralized management and control platform, and open it to other users for other users to call.

[0123] Among them, when the above-mentioned multiple contract execution logics are combined and then serviced, the contract execution logics contained in the user smart contracts distributed on multiple different member blockchains can be combined to generate a user service and then serviced, or the contract execution logics contained in multiple user smart contracts in the same member blockchain can be combined; or, the multiple contract execution logics contained in the same user smart contract in the same member blockchain can be combined to generate a service and then serviced, which is not specifically limited in this specification.

[0124] It should be noted that when combining multiple contract execution logics, these can also be combined according to a certain logical order. The above logical order usually depends on the specific service requirements of the service user. In actual applications, it can be flexibly determined based on the actual service requirements.

[0125] In this specification, when servitizing the contract execution logic, it can still be done by registering user services on the above-mentioned centralized management and control platform and binding the registered user services with the contract execution logic that needs to be serviced.

[0126] That is, the service provider can specifically initiate service registration on the centralized management and control platform, register the corresponding user service for the contract execution logic that needs to be serviced, and then bind the user service with the above-mentioned contract execution logic to complete the service-oriented contract execution logic.

[0127] It should be noted that the specific process of the service provider initiating service registration to the centralized management and control platform will not be described in detail in this manual. Those skilled in the art can refer to the records in the relevant technology.

[0128] Among them, in order to avoid exposing information related to the contract execution logic that needs to be serviced to the service user, when binding the registered user service with the contract execution logic, it is no longer necessary to directly bind the user service to the contract execution logic. Instead, a service interface can be set for the registered user service on the centralized management and control platform, and the service interface of the user service can be bound to the contract execution logic.

[0129] It should be noted that the service interface may be a service identifier that uniquely identifies the user service. The number of service interfaces provided for the user service may be one or more, which is not specifically limited in this specification.

[0130] In one embodiment shown, taking the above-mentioned user service as an example, which is a service generated by combining multiple contract execution logics, in this case, when setting the service interface for the user service, the user service can be specifically split into multiple sub-services corresponding to different service functions, and a corresponding service interface can be set for each sub-service, and then the corresponding contract execution logic is bound to each service interface.

[0131] To improve the stability of each sub-service, when binding contract execution logic to the service interface of each sub-service, multiple contract execution logics with the same service functionality can be bound to at least some of these service interfaces. When a service user calls a sub-service, a target contract execution logic can be assigned to the user based on a specific scheduling strategy from among the multiple contract execution logics bound to the sub-service, providing services to the service caller.

[0132] For example, see Figure 4 , Figure 4 This is a schematic diagram of an exemplary embodiment of this specification showing a method of setting a service interface for user services and binding contract execution logic to the service interface.

[0133] like Figure 4 As shown, Figure 4 The contract instances 1-7 that need to be serviced are shown. These contract instances belong to user smart contracts deployed on member blockchains A, B, and C. A contract instance refers to the contract execution logic contained in a user smart contract; for example, it can be an executable function contained in a user smart contract.

[0134] in, Figure 4 Service A shown in the figure can be split into sub-service 1 and sub-service 2 according to service functionality. The service interface set for sub-service 1 is a1, which is bound to two contract instances 1 and 2 with the same service functionality. The service interface set for sub-service 2 is a2, which is bound to only one contract instance 3.

[0135] Figure 4 Service B shown can be split into sub-services 3, 4, and 5 based on their service functions. The service interface b1 is set for sub-service 3, and this service interface b1 is bound to only one contract instance 1. The service interface b2 is set for sub-service 4, and this service interface b2 is bound to two contract instances 4 and 5 with the same service function. The service interface b3 is set for sub-service 5, and this service interface b3 is bound to two contract instances 3 and 6 with the same service function.

[0136] Figure 4The service C shown does not need to be split into sub-services. The service interface set for the service C is C1, and the service interface C1 is only bound to one contract instance 7.

[0137] like Figure 4 It can be seen that in actual applications, for user services generated by combining multiple contract execution logics, multiple service interfaces can be set for the user service, and multiple contract execution logics with the same functions can be bound to at least some of the service interfaces.

[0138] In this specification, after a service provider registers a user service on the centralized management and control platform and binds the contract execution logic that needs to be serviced to the user service, the centralized management and control platform can deploy the target user service as a standardized service to open it to service users for calling.

[0139] It should be noted that when deploying the above-mentioned user services that have completed registration, the above-mentioned centralized management and control platform can adopt a distributed deployment method.

[0140] The so-called distributed deployment specifically refers to the distributed deployment of the above-mentioned user services on each member blockchain in the form of system smart contracts for service users to call.

[0141] On the one hand, since the contract call logic that constitutes the above-mentioned user service may include the contract execution logic contained in multiple user smart contracts deployed on multiple member blockchains, when the service user calls the above-mentioned user service, it may also need to cross-chain call multiple user smart contracts distributed on multiple member blockchains; therefore, when deploying the above-mentioned user service, the above-mentioned centralized management and control platform can specifically develop corresponding cross-chain call logic for the user service, and then deploy the cross-chain call logic as the contract execution logic in the system smart contract on each member blockchain.

[0142] For example, as mentioned above, the contract execution logic contained in the system smart contract is typically related to certain management functions on the centralized control platform. Therefore, through this method, the cross-chain call logic developed for this user service is also deployed on each member blockchain as part of the execution logic related to certain management functions on the centralized control platform in the form of a system smart contract.

[0143] In addition, when deploying the user service, the binding relationship between the service interface of the user service and the contract execution logic can also be stored in the above-mentioned system smart contract as the service configuration information of the user service, and maintained by the above-mentioned system smart contract.

[0144] On the other hand, to facilitate the opening of user services registered by service providers to service users for service invocation, the centralized management and control platform can also develop corresponding service registration logic for the user service when deploying the user service. This service registration logic is then deployed on each member blockchain as the contract execution logic in the system smart contract. In this way, the registration logic developed for the user service is also deployed on each member blockchain as part of the execution logic related to some management functions on the centralized management and control platform in the form of a system smart contract.

[0145] See Figure 5 , Figure 5 This is a flowchart of a service registration method shown in an exemplary embodiment of this specification. The method is applied to Figure 1 A node device in any target member blockchain shown; wherein the system smart contract is deployed on each member blockchain in the above blockchain network; the system smart contract includes service registration logic corresponding to the above user service; the method includes:

[0146] Step 502: Obtain the service user's registration data for the user service; wherein the service interface of the user service is bound to the contract execution logic contained in the user smart contract deployed on other member blockchains.

[0147] After the user service registered by the service provider on the above-mentioned centralized management and control platform is distributedly deployed in the form of a system smart contract on each member blockchain in the above-mentioned blockchain service network, the service user can submit the usage registration data for the user service to the node device in the target member blockchain to which it is connected, thereby initiating a contract call to the above-mentioned system smart contract and obtaining the service call permission for the user service.

[0148] It should be noted that the above-mentioned service user can be a user who has registered a user account on the target member blockchain, or a user smart contract deployed on the target member blockchain, which is not specifically limited in this specification.

[0149] In one embodiment shown, if the service user is a user who has registered a user account on the target member blockchain, the call data may specifically be a smart contract call transaction for the system smart contract packaged by the user through a user client accessing the target member blockchain.

[0150] The user client can submit the packaged smart contract call transaction as the above-mentioned call data to the node device in the target member blockchain, initiate a contract call for the above-mentioned cross-chain call logic contained in the above-mentioned system smart contract, so as to trigger the node devices in the target member blockchain to distributely execute the above-mentioned cross-chain call logic contained in the system smart contract to obtain the service call permission of the user service.

[0151] Of course, in actual applications, the user can also submit the smart contract call data for the above-mentioned system smart contract to the Baas platform corresponding to the above-mentioned target member blockchain through the above-mentioned user client, and then the Baas platform will package the above-mentioned call data into a smart contract call transaction for the above-mentioned system smart contract and submit it to the node device in the target member blockchain.

[0152] In another embodiment shown, if the service user is a user smart contract deployed on the target member blockchain, the user smart contract may include a contract execution logic that references the service interface of the user service.

[0153] Referencing the service interface of the user service in the contract execution logic generally refers to referencing the service interface of the user service in the contract code corresponding to the contract execution logic. This allows the contract code to further initiate a service call to the user service corresponding to the service interface based on the referenced service interface when the user calls the contract code. When a user initiates a contract call to the contract execution logic contained in the user smart contract, the user smart contract can further initiate a service call to the user service corresponding to the service interface referenced by the contract execution logic based on the service interface referenced by the contract execution logic.

[0154] Among them, since the above-mentioned user services are distributedly deployed in the form of system smart contracts, the service call process initiated by the user smart contract for the referenced user service is actually a mutual call process initiated by the user smart contract and the above-mentioned system smart contract.

[0155] Smart contracts typically use a message-based invocation mechanism to call each other. Therefore, in practical applications, the invocation data can be a call message generated by a user smart contract, based on the inter-smart contract message invocation mechanism, to the system smart contract when the user invokes the contract execution logic contained in the user smart contract that references the user service.

[0156] In this case, when the user initiates a contract call for the contract execution logic contained in the user smart contract, the user smart contract can specifically generate a call message for the above-mentioned system smart contract based on the message call mechanism between smart contracts.

[0157] Then, the call message is submitted to the above-mentioned system smart contract as the call data for the above-mentioned user service, and a contract call for the above-mentioned system smart contract is initiated to trigger the node devices in the blockchain to distribute the execution of the above-mentioned usage registration logic contained in the system smart contract to obtain the service call permission of the above-mentioned user service.

[0158] Among them, the process of using the message call mechanism between smart contracts to call each other will not be described in detail in this specification. When those skilled in the art implement the technical solutions described in this specification, they can refer to the records in the relevant technology.

[0159] It should be noted that the above-mentioned call message can be any form of data suitable for transmission between smart contracts and is not particularly limited in this specification.

[0160] For example, in one example, the call message can be an executable instruction defined in the development language used by the smart contract and suitable for transmission between smart contracts. For example, if the contract code in the smart contract is developed in the high-level language Solidity, the call message can be a call instruction targeting the system smart contract.

[0161] Step 504: In response to the usage registration data, the service registration logic contained in the system smart contract is called, the target contract execution logic is determined for the service user from the contract execution logic bound to the service interface, and the service call permission related to the target contract execution logic is authorized to the service user.

[0162] In this specification, the above-mentioned usage registration data may specifically carry the service interface corresponding to the above-mentioned user service.

[0163] It should be noted that if the above-mentioned user service is a service generated by combining multiple contract execution logics, the user service may include multiple service interfaces, each of which corresponds to a sub-service in the user service.

[0164] In this case, the service user can choose to register for use of one or more sub-services in the user service. Accordingly, the above registration data can also carry one or more service interfaces selected by the service user from the multiple service interfaces that need to be registered for use.

[0165] After obtaining the above-mentioned usage registration data submitted by the above-mentioned service user, the node device in the above-mentioned target member blockchain can respond to the usage registration data, further call the above-mentioned service registration logic contained in the above-mentioned system smart contract, obtain the service interface carried in the above-mentioned usage registration data, and determine the target contract execution logic for the service user from the contract execution logic bound to the service interface.

[0166] In one embodiment shown, since the user service may include multiple service interfaces, and each service interface may be bound to multiple contract execution logics, the node device in the target member blockchain may first determine whether the service interface is bound to multiple contract execution logics after calling the usage registration logic contained in the system smart contract and obtaining the service interface carried in the call data.

[0167] For example, in one example, after the service provider registers the user service through the centralized management and control platform, the centralized management and control platform can also maintain the binding relationship between the service interface assigned to the user service and the contract execution logic that needs to be serviced in the above-mentioned system smart contract, so that the above-mentioned system smart contract can query the above-mentioned binding relationship to clarify whether the service interface carried in the above-mentioned registration data is bound to multiple contract execution logics.

[0168] If it is determined that the service interface is bound to multiple contract execution logics, the above-mentioned system smart contract can dynamically allocate a target contract execution logic that provides services to the above-mentioned service user from the multiple contract execution logics bound to the service interface based on a preset scheduling strategy.

[0169] In this way, when the service user requests the service call permission of the user service by calling the service registration logic contained in the system smart contract, the contract execution logic that ultimately requests the service call permission is dynamically determined by the system smart contract from the contract execution logic bound to the service interface; therefore, in this way, the user's flexibility in registering for the use of the above-mentioned user services can be improved.

[0170] Moreover, service users cannot perceive in advance the smart contract where the contract execution logic for their request for service permissions is located, nor the member blockchain where the smart contract is located; therefore, this service registration method will have higher privacy and security.

[0171] It should be noted that the aforementioned preset scheduling strategy can be any specific strategy for dynamically allocating contract execution logic to a service user from among multiple contract execution logics bound to the service interface, and is not specifically limited in this specification. In actual applications, specific scheduling strategies can be flexibly set based on specific scheduling requirements.

[0172] In one embodiment, the scheduling strategy includes any one or more combinations of the following:

[0173] Scheduling strategy 1:

[0174] Randomly assign a scheduling strategy for the contract execution logic to the service user from the multiple contract execution logics bound to the above service interface.

[0175] Based on this strategy, the contract execution logic can be randomly assigned to the service user from multiple contract execution logics bound to the above service interface to provide services to the service user.

[0176] In this way, service users cannot perceive the contract call logic for providing services to themselves in advance, thereby ensuring privacy to the greatest extent when calling user services.

[0177] Scheduling strategy 2:

[0178] The pre-specified contract execution logic among the multiple contract execution logics bound to the above service interface is assigned to the scheduling strategy of the above service user.

[0179] Based on this strategy, the service provider can flexibly specify the contract execution logic for providing services to the service user from multiple contract execution logics bound to the above service interface, thereby improving the service flexibility of the above user service.

[0180] For example, in actual applications, for some specific service users, a fixed contract execution logic can be specified from the above multiple contract execution logics to provide services for the service user.

[0181] Scheduling strategy three:

[0182] Among the multiple contract execution logics bound to the above service interface, the contract execution logic whose service indicators meet the preset conditions is assigned to the scheduling strategy of the above service user.

[0183] Based on this strategy, the centralized management and control platform can collect real-time statistics on the service indicators of each contract execution logic bound to the service interface, and store the service indicators in the system smart contract, which is maintained by the system smart contract. The system smart contract can then filter out the contract execution logic whose service indicators meet the preset conditions based on the maintained service indicators, and allocate them to the service users, thereby achieving refined management of the contract execution logic bound to the service interface.

[0184] For example, based on the service indicators of each contract execution logic bound to the above service interface, a contract execution logic that best suits the service user can be screened out for the service user, and services can be provided to the service user.

[0185] The aforementioned service indicators may specifically include any form of indicator that can represent the usage of the contract execution logic bound to the aforementioned service interface, and are not specifically limited in this specification. Accordingly, the aforementioned pre-conditions generally depend on the specific type of the aforementioned service indicator and, in practice, can be flexibly set based on specific service requirements.

[0186] For example, in one example, the service indicator may specifically include the number of service users provided by the contract execution logic. Correspondingly, the preset condition may include the contract execution logic with the smallest number among multiple contract execution logics bound to the service interface.

[0187] In this case, when the system smart contract dynamically allocates the contract execution logic that provides services to the service user from the multiple contract execution logics bound to the service interface based on the scheduling strategy three described above, it can specifically count the number of service users provided with services by the multiple contract execution logics, and then allocate the contract execution logic with the smallest number as the target contract execution logic to the service user.

[0188] Since the number of service users provided by each contract execution logic can usually be understood as the service load of each contract execution logic when providing services to service users, load balancing of the above-mentioned multiple contract execution logics can be achieved in this way.

[0189] Of course, in addition to the number of service users provided by the above-mentioned contract execution logic, the above-mentioned service indicators may also include, in actual applications, the total duration of services provided by the above-mentioned contract execution logic to each service provider, the number of successful calls when providing services, the call success rate, the number of call failures and other service indicators, which will not be listed one by one in this manual.

[0190] In addition, the above-mentioned preset conditions may include the condition that the above-mentioned contract execution logic has the smallest number among the multiple contract execution logics bound to the above-mentioned service interface. In actual applications, they may also include other forms of conditions, which will not be listed one by one in this specification; for example, in one example, the above-mentioned preset conditions may also include the above-mentioned contract execution logic whose number is lower than the threshold.

[0191] In one embodiment shown, after the contract execution logic for providing services to the above-mentioned service user is allocated to the above-mentioned service user, service registration information of the above-mentioned service user for the above-mentioned user service can also be generated, and the service registration information can be stored in the system smart contract so that the stored service registration information can be maintained by the system smart contract.

[0192] Among them, the above-mentioned service registration information may specifically include information related to the target contract execution logic allocated by the system smart contract to the service user based on the above-mentioned scheduling strategy, from multiple contract execution logics bound to the above-mentioned service interface to provide services to the service user; for example, it may be identification information corresponding to the target contract execution logic (such as function name, etc.).

[0193] In this specification, when the above-mentioned service registration logic contained in the above-mentioned system smart contract is called, after the target contract execution logic for providing services to the service user is determined for the service user from the contract execution logic bound to the service interface, the calling authority related to the target contract execution logic can be further authorized to the service user.

[0194] In one embodiment shown, the calling permission of the above-mentioned user service and the calling permission of the contract execution logic bound to the service interface of the user service can be authorized separately as two independent permissions.

[0195] In this case, when authorizing the call permission related to the target contract execution logic to the service user, the service call permission of the user service can be first authorized to the target user smart contract; and the service call permission of the above-mentioned target contract execution logic can be authorized to the service user.

[0196] This approach allows for refined management of the aforementioned user services. For example, after authorizing the service call permission for the aforementioned user service to the aforementioned service user, a separate authorization can be issued for the target contract execution logic assigned to the service user from among the multiple contract execution logics bound to the user service. This fundamentally avoids any interaction between the service call permission for the aforementioned user service and the call permission for the contract execution logic bound to the user service.

[0197] In one embodiment shown, if the above-mentioned service user is a user smart contract deployed on the above-mentioned target member blockchain, when authorizing the service call permission of the above-mentioned target contract execution logic to the service user, a two-way permission authorization method can be adopted. In addition to authorizing the service call permission of the target contract execution logic to the user smart contract, the calling permission of the user smart contract can also be correspondingly authorized to the above-mentioned target contract execution logic.

[0198] In this way, on the one hand, since the contract execution logic contained in the user smart contract may also be bound to the service interface of another user service; therefore, by adopting this two-way permission authorization method, the call permission related to the other user service can also be synchronously authorized to the target contract execution logic, thereby avoiding the subsequent repeated authorization through the authorization method described above when the target contract execution logic has the call requirements of the above-mentioned other user service.

[0199] On the other hand, due to the use of this two-way permission authorization method, the above-mentioned target contract execution logic can synchronously obtain the calling permission of the contract execution logic contained in the above-mentioned user smart contract; therefore, for the target contract execution logic, it can call back the user smart contract as the service caller to promptly return the service call result of the user smart contract as the service user for the above-mentioned user service to the user smart contract as the service caller, without the need to use the asynchronous return service call result method, thereby improving the service call efficiency when making service calls for the above-mentioned user service.

[0200] Please refer to Figure 6 , Figure 6 This is a flowchart of a cross-chain calling method for a smart contract shown in an exemplary embodiment of this specification. The method is applied to a node device in any target member blockchain in a blockchain service network composed of several member blockchains; wherein the above-mentioned user smart contract and the above-mentioned system smart contract are deployed on each member blockchain in the blockchain network.

[0201] It should be noted that if Figure 6 The cross-chain calling method of the smart contract shown is applicable to general cross-chain calling application scenarios, and is also applicable to specific application scenarios of servitizing the contract execution logic contained in the smart contract deployed on the blockchain.

[0202] In the application scenario of general cross-chain calls, the system smart contract may include cross-chain call logic corresponding to the contract execution logic contained in user smart contracts deployed on at least some member blockchains of the blockchain service network. Specifically, in the application scenario of servitizing the contract execution logic contained in smart contracts deployed on blockchains, the system smart contract may include cross-chain call logic corresponding to the user service.

[0203] The method comprises:

[0204] Step 602: Obtain the call data of the contract caller for the contract execution logic contained in the user smart contract deployed on other member blockchains.

[0205] The contract caller can initiate a contract call for the above-mentioned system smart contract by submitting the call data of the contract execution logic contained in the user smart contract deployed on other member blockchains to the node device in the target member blockchain to which it is connected, so as to complete the cross-chain call of the user smart contract deployed on other member blockchains.

[0206] In one embodiment, if the contract caller is a user with a registered user account on the target member blockchain, the call data may be a smart contract call transaction for the system smart contract, packaged by the user through a user client connected to the target member blockchain. The user client may submit the packaged smart contract call transaction to a node device on the target member blockchain, initiating a contract call for the system smart contract. This triggers the node devices on the target member blockchain to execute the cross-chain call logic contained in the system smart contract in a distributed manner, thereby completing the cross-chain call for the user smart contract deployed on other member blockchains.

[0207] Of course, in actual applications, the user can also submit the smart contract call data for the above-mentioned system smart contract to the Baas platform corresponding to the above-mentioned target member blockchain through the above-mentioned user client, and then the Baas platform will package the above-mentioned call data into a smart contract call transaction for the above-mentioned system smart contract and submit it to the node device in the target member blockchain.

[0208] In another embodiment shown, if the contract caller is a user smart contract deployed on the target member blockchain, the contract execution logic contained in the user smart contract references the contract execution logic contained in the user smart contract deployed on other member blockchains. When the user initiates a contract call for the contract execution logic contained in the user smart contract, the user smart contract can specifically generate a call message for the system smart contract based on the message call mechanism between smart contracts. This call message is then submitted to the system smart contract as call data for the contract execution logic contained in the user smart contract deployed on other member blockchains, initiating a contract call for the system smart contract to trigger the distributed execution of the cross-chain call logic contained in the system smart contract by the node devices in the blockchain, thereby completing the cross-chain call for the user smart contract deployed on other member blockchains.

[0209] For example, in one example, the call message can be an executable instruction defined in the development language used by the smart contract and suitable for transmission between smart contracts. For example, if the contract code in the smart contract is developed in the high-level language Solidity, the call message can be a call instruction targeting the system smart contract.

[0210] Specifically, in an application scenario where the contract execution logic contained in a smart contract deployed on a blockchain is service-oriented, the contract caller may be the service user.

[0211] In this case, when the user service registered by the service provider on the above-mentioned centralized management and control platform is distributedly deployed in the form of a system smart contract on each member blockchain in the above-mentioned blockchain service network, and the above-mentioned service user completes the registration for the use of the user service, the service user can submit the call data for the user service to the node device in the target member blockchain to which it is connected, thereby initiating a contract call for the above-mentioned system smart contract to complete the service call of the user service.

[0212] Step 604: In response to the call data, the identifier generation logic contained in the system smart contract deployed on the target member blockchain is called to generate a global link identifier corresponding to the call data, and the cross-chain call logic contained in the system smart contract is called. Based on the global link identifier, a cross-chain call is initiated for the user smart contract deployed on the other member blockchain, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchain.

[0213] After obtaining the call data submitted by the contract caller, the node device in the target member blockchain can, in response to the call data, call the identifier generation logic contained in the system smart contract to generate a global link identifier corresponding to the call data, and further call the cross-chain call logic contained in the system smart contract to initiate a cross-chain call to the user smart contract deployed on the other member blockchain based on the global link identifier. For the user smart contract deployed on the other member blockchain, after being cross-chain called, the user smart contract can perform corresponding data processing based on the contract execution logic contained in the user smart contract, and store the global link identifier in association with the contract execution result of the user smart contract on the other member blockchain.

[0214] Among them, the specific method by which the system smart contract initiates a cross-chain call to the user smart contract deployed on the other member blockchain can still be completed using the message call mechanism between smart contracts, and will not be described in detail in this manual.

[0215] In one embodiment, if the contract caller is a user who is the contract caller, the call data may be a smart contract call transaction submitted by the user for the system smart contract. In this case, the global link identifier may be the global link identifier corresponding to the smart contract call transaction.

[0216] In another embodiment, if the contract caller is a user smart contract deployed on the target member blockchain, the call data may be a call message generated by the user smart contract for the system smart contract when invoking the contract execution logic contained in the user smart contract. In this case, the global link identifier may be the global link identifier corresponding to the smart contract call transaction submitted by the user for the user smart contract.

[0217] In one embodiment, when generating a global link identifier corresponding to the call data, the hash value of the smart contract call transaction and the serial number maintained by the blockchain service network can be obtained. The serial number includes a globally incremented value. Subsequently, the serial number can be updated and the hash value of the smart contract call transaction and the updated serial number are concatenated to obtain the global link identifier.

[0218] Furthermore, in one embodiment, when updating the sequence number and concatenating the hash value with the updated sequence number to obtain the global link identifier, it is first determined whether the sequence number reaches a preset threshold. If so, the sequence number can be reset to a preset initial value, and the hash value and the reset sequence number can be concatenated to obtain the global link identifier. If not, the sequence number can be updated, and the hash value and the updated sequence number can be concatenated to obtain the global link identifier.

[0219] Furthermore, in one embodiment, the timestamp of the current block in the target member blockchain can also be obtained. In this case, when the hash value and the updated sequence number are concatenated to obtain the global link identifier, the hash value, the timestamp, and the updated sequence number can be concatenated to obtain the global link identifier.

[0220] It should be noted that the above-mentioned global link identifier is global data maintained by the above-mentioned blockchain service network, that is, the global link identifier stored on each member blockchain in the blockchain service network remains consistent.

[0221] Specifically, in the application scenario of servitizing the contract execution logic contained in the smart contract deployed on the blockchain, the above-mentioned contract caller can specifically be the above-mentioned service user; in the above-mentioned call data, the service interface corresponding to the above-mentioned user service can specifically be carried.

[0222] It should be noted that if the above-mentioned user service is a service generated by combining multiple contract execution logics, the user service may include multiple service interfaces, each of which corresponds to a sub-service in the user service.

[0223] In this case, the service user can choose to call one or more sub-services in the user service. Correspondingly, the above call data can also carry one or more service interfaces selected by the service user from the multiple service interfaces to be called.

[0224] After obtaining the above-mentioned call data submitted by the above-mentioned service user, the node device in the above-mentioned target member blockchain can respond to the call data, call the identification generation logic contained in the above-mentioned system smart contract, generate a global link identification corresponding to the call data, and further call the above-mentioned cross-chain call logic contained in the system smart contract, obtain the service interface carried in the above-mentioned call data, determine the target contract execution logic for the service user from the contract execution logic bound to the service interface, and based on the global link identification, initiate a cross-chain call to the user smart contract containing the target contract execution logic deployed on the other member blockchains.

[0225] In one embodiment shown, since the user service may include multiple service interfaces, and each service interface may be bound to multiple contract execution logics, the node device in the target member blockchain may first determine whether the service interface is bound to multiple contract execution logics after calling the cross-chain call logic contained in the system smart contract and obtaining the service interface carried in the call data.

[0226] For example, in one example, after the service provider registers a user service through a centralized management and control platform, the centralized management and control platform can also maintain the binding relationship between the service interface assigned to the user service and the contract execution logic that needs to be serviced in the above-mentioned system smart contract. In this way, the above-mentioned system smart contract can query the above-mentioned binding relationship to clarify whether the service interface carried in the above-mentioned call data is bound to multiple contract execution logics.

[0227] If it is determined that the service interface is bound to multiple contract execution logics, the above-mentioned system smart contract can dynamically allocate a target contract execution logic that provides services to the above-mentioned service user from the multiple contract execution logics bound to the service interface based on a preset scheduling strategy.

[0228] In this way, when the service user calls the contract execution logic bound to the service interface of the user service through the system smart contract across the chain, the contract execution logic finally called is dynamically determined by the system smart contract from the contract execution logic bound to the service interface; therefore, in this way, the flexibility of the above-mentioned user service when being called can be improved.

[0229] Moreover, for service users, they cannot perceive in advance the smart contract where the contract execution logic is called, nor the member blockchain where the smart contract is located; therefore, this cross-chain contract calling method will have higher privacy and security.

[0230] It should be noted that the above-mentioned preset scheduling strategy can be any form of strategy for dynamically allocating contract execution logic to the service user from multiple contract execution logics bound to the service interface, and is not specifically limited in this specification. In actual application, specific scheduling strategies can be flexibly set based on specific scheduling requirements. For example, in this embodiment, the above-mentioned scheduling strategy can still include Figure 5 Any one or more combinations of the above-mentioned scheduling strategy 1, scheduling strategy 2, and scheduling strategy 3 described in the illustrated embodiment will not be described in detail in this specification.

[0231] In one embodiment shown, as mentioned above, since the above-mentioned system smart contract can maintain the service registration information of the service user for the above-mentioned user service in advance, and the service registration information may include the system smart contract at the stage when the service user registers to use the user service, based on the above-mentioned preset scheduling strategy, from the multiple contract execution logics bound to the service interface corresponding to the user service, the information related to the target contract execution logic for providing services to the service user is allocated to the service user; therefore, in this case, when the above-mentioned system smart contract determines the target contract execution logic for the service user from the contract execution logic bound to the above-mentioned service interface, it may no longer perform real-time allocation, but directly obtain the information related to the target contract execution logic included in the above-mentioned service registration information, and then directly allocate the target contract execution logic to the service user.

[0232] In this way, when the service user calls the user service, the target contract execution logic allocated to the service user during the registration phase can be preferentially allocated to the service user, thereby avoiding repeated allocation of contract execution logic to the service user when the service user calls the user service.

[0233] In one embodiment shown, as mentioned above, since the above-mentioned service user is in the service registration stage for the above-mentioned user service, the calling permission of the above-mentioned user service and the calling permission of the contract execution logic bound to the service interface of the user service can be two independent permissions and authorized to the service user respectively. Therefore, in this case, before calling the cross-chain calling logic contained in the system smart contract and determining the target contract execution logic for the service user from the contract execution logic bound to the service interface, the permission verification logic contained in the system smart contract can also be called first to verify whether the service user has the calling permission of the user service; if so, the above-mentioned cross-chain calling logic contained in the system smart contract can be further called to determine the target contract execution logic for the service user from the contract execution logic bound to the service interface.

[0234] In another embodiment shown, based on similar reasons, after determining the target contract execution logic for the service user from the contract execution logic bound to the service interface, after initiating a cross-chain call to the user smart contract containing the contract execution logic deployed on other member blockchains, the permission verification logic contained in the system smart contract can also be called first to verify whether the service user has the calling permission for the target contract execution logic; if so, a cross-chain call to the user smart contract containing the target contract execution logic deployed on the other member blockchain is initiated.

[0235] In the above technical solution, the contract caller can call the system smart contract, and the system smart contract can generate a global link identifier corresponding to this call, and based on the global link identifier, initiate a cross-chain call to the user smart contract deployed on other member blockchains, so that the user smart contract deployed on the other member blockchain can associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchain.

[0236] By adopting the above method, in the case of multi-chain cross-chain interconnection, the data associated with the global link identifier stored on all member blockchains in the blockchain service network can be aggregated through the global link identifier, thereby enabling the contract caller and the called user smart contract to perceive the data processing performed by the other party on the corresponding blockchain, thereby achieving mutual trust.

[0237] exist Figure 6 Based on the Figure 7 , Figure 7 This is a flowchart of a cross-chain call tracing method for a smart contract shown in an exemplary embodiment of this specification. The method is applied to an off-chain server that accesses a blockchain service network composed of several member blockchains.

[0238] Like Figure 6 Similar to the cross-chain call method of the smart contract shown, user smart contracts and system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract contains cross-chain call logic corresponding to the contract execution logic contained in the user smart contract deployed on at least some member blockchains in the blockchain service network; the cross-chain call logic is used to initiate a cross-chain call for the user smart contract deployed on other member blockchains based on the global link identifier, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchains.

[0239] The method comprises:

[0240] Step 702: Obtain a query request for the contract execution results stored on each member blockchain in the blockchain network; wherein the query request includes a global link identifier.

[0241] Step 704: Based on the global link identifier in the query request, obtain the contract execution result associated with the global link identifier from each member blockchain in the blockchain network.

[0242] When it is necessary to query the contract execution results stored on each member blockchain in the above-mentioned blockchain network, a query request for the contract execution results stored on each member blockchain in the blockchain network can be submitted to the above-mentioned off-chain server.

[0243] The query request may include a global link identifier associated with the contract execution result to be queried.

[0244] In this case, the above-mentioned off-chain server can obtain the contract execution results associated with the global link identifier from each member blockchain in the above-mentioned blockchain network based on the above-mentioned global link identifier in the above-mentioned query request, so as to achieve the aggregation of the contract execution results associated with the global link identifier stored on all member blockchains in the blockchain service network.

[0245] like Figure 7 The specific implementation of the cross-chain call tracing method of the smart contract shown in the figure can be partially referred to as Figure 6 The cross-chain calling method of the smart contract shown is not repeated here.

[0246] In the above technical solution, the off-chain server can obtain the contract execution results associated with the global link identifier from each member blockchain in the blockchain network based on the global link identifier in the query request for the contract execution results stored on each member blockchain in the blockchain network.

[0247] By adopting the above method, in the case of multi-chain cross-chain interconnection, the data associated with the global link identifier stored on all member blockchains in the blockchain service network can be aggregated through the global link identifier, thereby enabling the contract caller and the called user smart contract to perceive the data processing performed by the other party on the corresponding blockchain, thereby achieving mutual trust.

[0248] Figure 8 This is a schematic structural diagram of a device provided by an exemplary embodiment. Figure 8At the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810, and may also include other required hardware. One or more embodiments of this specification can be implemented based on software, such as the processor 802 reading the corresponding computer program from the non-volatile memory 810 into the memory 808 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic module, but can also be hardware or logic devices.

[0249] Please refer to Figure 9 , Figure 9 This is a block diagram of a cross-chain calling device for a smart contract shown in an exemplary embodiment of this specification.

[0250] The cross-chain calling device of the above smart contract can be applied to Figure 8 The device shown in the figure is used to implement the technical solution of this specification. The device is applied to a node device in any target member blockchain in a blockchain service network composed of multiple member blockchains; wherein user smart contracts and system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract contains cross-chain call logic corresponding to the contract execution logic contained in the user smart contract deployed on at least some member blockchains in the blockchain service network;

[0251] The device comprises:

[0252] Acquisition module 902, acquires the call data of the contract execution logic contained in the user smart contract deployed on other member blockchains by the contract caller;

[0253] The calling module 904, in response to the calling data, calls the identification generation logic contained in the system smart contract deployed on the target member blockchain, generates a global link identifier corresponding to the calling data, and calls the cross-chain calling logic contained in the system smart contract. Based on the global link identifier, it initiates a cross-chain call for the user smart contract deployed on the other member blockchain, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchain.

[0254] Please refer to Figure 10 , Figure 10 This is a block diagram of a cross-chain call tracking device for a smart contract shown in an exemplary embodiment of this specification.

[0255] The cross-chain calling device of the above smart contract can be applied to Figure 8The device shown is used to implement the technical solution of this specification. The device is applied to an off-chain service end of a blockchain service network composed of several member blockchains; wherein user smart contracts and system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract includes cross-chain call logic corresponding to the contract execution logic included in the user smart contract deployed on at least some member blockchains in the blockchain service network; the cross-chain call logic is used to initiate a cross-chain call for the user smart contract deployed on other member blockchains based on a global link identifier, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchains;

[0256] The device comprises:

[0257] An acquisition module 1002 acquires a query request for a contract execution result stored on each member blockchain in the blockchain network; wherein the query request includes a global link identifier;

[0258] The query module 1004 obtains the contract execution result associated with the global link identifier from each member blockchain in the blockchain network based on the global link identifier in the query request.

[0259] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0260] For the device embodiment, it basically corresponds to the method embodiment, so for the relevant parts, please refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this specification. Those of ordinary skill in the art can understand and implement it without paying any creative work.

[0261] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

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

[0263] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0264] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, 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 a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0265] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0266] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0267] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "an," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0268] It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when..." or "when..." or "in response to determining."

[0269] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included in the scope of protection of one or more embodiments of this specification.

Claims

1. A cross-chain calling method for a smart contract, the method being applied to a node device in any target member blockchain in a blockchain service network consisting of several member blockchains; wherein, User smart contracts and system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract includes cross-chain call logic corresponding to the contract execution logic included in the user smart contracts deployed on at least some member blockchains in the blockchain service network; The method comprises: Obtain the call data of the contract caller for the contract execution logic contained in the user smart contract deployed on other member blockchains; In response to the call data, the identifier generation logic contained in the system smart contract deployed on the target member blockchain is called to generate a global link identifier corresponding to the call data, and the cross-chain call logic contained in the system smart contract is called. Based on the global link identifier, a cross-chain call is initiated for the user smart contract deployed on the other member blockchain, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchain.

2. The method according to claim 1, wherein the contract execution logic contained in the user smart contracts deployed on at least some member blockchains of the blockchain service network is open for call in the form of user services; The system smart contract contains the cross-chain call logic corresponding to the user service; The acquisition of the contract caller's call data for the contract execution logic contained in the user smart contract deployed on other member blockchains includes: Obtaining call data for the user service from the contract caller; wherein the service interface of the user service is bound to the contract execution logic contained in the user smart contract deployed on other member blockchains; The initiating a cross-chain call to the user smart contract deployed on the other member blockchain based on the global link identifier includes: Determine the target contract execution logic for the contract caller from the contract execution logic bound to the service interface, and initiate a cross-chain call to the user smart contract containing the target contract execution logic deployed on the other member blockchain based on the global link identifier.

3. The method according to claim 2, wherein the user service comprises a service generated by combining multiple contract execution logics contained in user smart contracts deployed on at least some member blockchains in the blockchain service network; the user service comprises multiple service interfaces; wherein, Different service interfaces correspond to different service functions respectively; at least some of the multiple service interfaces are bound to multiple contract execution logics with the same service functions.

4. According to the method of claim 1, the contract caller includes a user serving as the contract caller; the call data includes a smart contract call transaction submitted by the user for the system smart contract; and the global link identifier is a global link identifier corresponding to the smart contract call transaction.

5. According to the method of claim 1, the contract caller includes a user smart contract deployed on the target member blockchain; the contract execution logic contained in the user smart contract references the contract execution logic contained in the user smart contract deployed on other member blockchains; the call data includes a call message for the system smart contract generated by the user smart contract when calling the contract execution logic contained in the user smart contract; and the global link identifier is a global link identifier corresponding to the smart contract call transaction submitted by the user for the user smart contract.

6. The method according to claim 4 or 5, wherein generating a global link identifier corresponding to the call data comprises: Obtaining a hash value of the smart contract call transaction and a serial number maintained by the blockchain service network; wherein the serial number includes a globally incremented value; The sequence number is updated, and the hash value and the updated sequence number are concatenated to obtain a global link identifier.

7. The method according to claim 6, wherein updating the sequence number and concatenating the hash value and the updated sequence number to obtain a global link identifier comprises: Determining whether the sequence number reaches a preset threshold; If yes, reset the sequence number to an initial value, and concatenate the hash value and the reset sequence number to obtain a global link identifier; if no, update the sequence number, and concatenate the hash value and the updated sequence number to obtain a global link identifier.

8. The method according to claim 6, further comprising: Obtaining the timestamp of the current block in the target member blockchain; The concatenating the hash value and the updated sequence number to obtain a global link identifier includes: The hash value, the timestamp and the updated sequence number are concatenated to obtain a global link identifier.

9. A cross-chain call tracing method for a smart contract, the method being applied to an off-chain server connected to a blockchain service network consisting of several member blockchains; wherein: User smart contracts and system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract includes cross-chain call logic corresponding to the contract execution logic included in the user smart contract deployed on at least some member blockchains in the blockchain service network; the cross-chain call logic is used to initiate a cross-chain call to the user smart contract deployed on other member blockchains based on a global link identifier, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchains; The method comprises: Obtaining a query request for contract execution results stored on each member blockchain in the blockchain network; wherein the query request includes a global link identifier; Based on the global link identifier in the query request, a contract execution result associated with the global link identifier is obtained from each member blockchain in the blockchain network.

10. A cross-chain calling device for a smart contract, the device being applied to a node device in any target member blockchain in a blockchain service network consisting of several member blockchains; wherein, User smart contracts and system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract includes cross-chain call logic corresponding to the contract execution logic included in the user smart contracts deployed on at least some member blockchains in the blockchain service network; The device comprises: The acquisition module obtains the call data of the contract execution logic contained in the user smart contract deployed on other member blockchains by the contract caller; The calling module, in response to the calling data, calls the identification generation logic contained in the system smart contract deployed on the target member blockchain, generates a global link identifier corresponding to the calling data, and calls the cross-chain calling logic contained in the system smart contract, and initiates a cross-chain call to the user smart contract deployed on the other member blockchain based on the global link identifier, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchain.

11. A cross-chain call tracking device for a smart contract, the device being applied to an off-chain server connected to a blockchain service network consisting of several member blockchains; wherein: User smart contracts and system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract includes cross-chain call logic corresponding to the contract execution logic included in the user smart contract deployed on at least some member blockchains in the blockchain service network; the cross-chain call logic is used to initiate a cross-chain call to the user smart contract deployed on other member blockchains based on a global link identifier, so as to associate the global link identifier with the contract execution result of the user smart contract and store it on the other member blockchains; The device comprises: An acquisition module is configured to acquire a query request for a contract execution result stored on each member blockchain in the blockchain network; wherein the query request includes a global link identifier; The query module obtains the contract execution result associated with the global link identifier from each member blockchain in the blockchain network based on the global link identifier in the query request.

12. An electronic device comprising: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 1 to 9 by running the executable instructions.

13. A computer-readable storage medium having computer instructions stored thereon, wherein when the instructions are executed by a processor, the method according to any one of claims 1 to 9 is implemented.

Images