Cross-chain calling method and device of smart contract

Abstract

The one or more embodiments of the specification provide a cross-chain calling method and device of a smart contract. The method comprises: obtaining calling data of a service user for a user service; wherein a service interface of the user service is bound with contract execution logic contained in a user smart contract deployed on another member blockchain; in response to the calling data, calling cross-chain calling logic contained in the system smart contract, determining target contract execution logic for the service user from the contract execution logic bound with the service interface, and initiating cross-chain calling for the user smart contract containing the target contract execution logic deployed on the other member blockchain.

Description

Technical Field

[0001] Several embodiments in this specification relate to the field of blockchain technology, and in particular to a method and apparatus for cross-chain invocation of smart contracts. Background Technology

[0002] With the development of blockchain technology, more and more blockchains are being established. However, most of these blockchains are independent and cannot communicate with each other. Therefore, in practical applications, in order to make full use of the service resources deployed on each blockchain, these blockchains can be grouped into a blockchain service network as member blockchains. The contract execution logic contained in the smart contracts deployed on each member blockchain can then be made available to users as a user service through the management platform of this blockchain service network, allowing users to call upon it. Summary of the Invention

[0003] According to a first aspect of several embodiments of this specification, a cross-chain invocation method for smart contracts is proposed. The method is applied to a node device in any target member blockchain of a blockchain service network composed of several member blockchains. The contract execution logic contained in user smart contracts deployed on at least some member blockchains of the blockchain service network is open for invocation in the form of user services. System smart contracts are deployed on each member blockchain of the blockchain network. The system smart contracts contain cross-chain invocation logic corresponding to the user services.

[0004] The method includes:

[0005] Obtain call data for the user service initiated by the service user; 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;

[0006] In response to the call data, the cross-chain call logic contained in the system smart contract is invoked. From the contract execution logic bound to the service interface, the target contract execution logic is determined for the service user, and a cross-chain call is initiated against the user smart contract containing the target contract execution logic deployed on the other member blockchain.

[0007] According to a second aspect of several embodiments of this specification, a cross-chain invocation device for smart contracts is also provided. The device is applied to a node device in any target member blockchain of a blockchain service network composed of several member blockchains. The contract execution logic contained in user smart contracts deployed on each member blockchain of the blockchain service network is open for invocation in the form of user services. System smart contracts are deployed on each member blockchain of the blockchain network. The system smart contracts contain cross-chain invocation logic corresponding to the user services.

[0008] The device includes:

[0009] The acquisition module acquires call data for the user service initiated by the service user; 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;

[0010] The calling module, in response to the calling data, calls the cross-chain calling logic contained in the system smart contract, determines the target contract execution logic for the service user from the contract execution logic bound to the service interface, and initiates a cross-chain call to the user smart contract containing the target contract execution logic deployed on the other member blockchains.

[0011] In the embodiments described above, on the one hand, since the blockchain service network supports the service-oriented approach to the contract execution logic contained in user smart contracts deployed on each member blockchain, and exposes them as user services for invocation, and the contract execution logic corresponding to the user service is no longer directly bound to the user service, but rather bound to the service interface corresponding to the user service; therefore, when the user service is exposed to the service user, only the service interface corresponding to the user service needs to be exposed to the service user, while the information related to the contract execution logic bound to the service interface does not need to be exposed to the service user, thereby avoiding privacy leaks caused by directly exposing the information related to the contract execution logic corresponding to the user service to the service user.

[0012] On the other hand, when a service user invokes the contract execution logic bound to the service interface of that user service via a system smart contract across chains, the final invoked contract execution logic is dynamically determined by the system smart contract from the contract execution logic bound to that service interface. Therefore, this method enhances the flexibility of the aforementioned user service when it is invoked. Furthermore, the service user cannot know in advance the smart contract containing the invoked contract execution logic, nor the member blockchain on which that smart contract resides; thus, this method of cross-chain contract invocation offers high privacy and security. Attached Figure Description

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

[0014] Figure 2 This is a flowchart illustrating a method for constructing a blockchain service network according to an exemplary embodiment.

[0015] Figure 3This is a flowchart illustrating a registration process for a target blockchain, as shown in this specification.

[0016] Figure 4 This is a schematic diagram illustrating, according to an exemplary embodiment, how to set up a service interface for a user service and bind contract execution logic to the service interface.

[0017] Figure 5 This is a flowchart illustrating a service registration method according to an exemplary embodiment.

[0018] Figure 6 This is a flowchart illustrating a cross-chain invocation method for a smart contract according to an exemplary embodiment.

[0019] Figure 7 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment.

[0020] Figure 8 This is a block diagram illustrating a cross-chain calling device for a smart contract according to an exemplary embodiment. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

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

[0023] In related technologies, 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 are typically grouped as member blockchains to form a blockchain service network. The contract execution logic contained in the smart contracts deployed on each member blockchain is then service-oriented through the centralized management platform of this blockchain service network, making it available to users as a user service for them to invoke. In practical applications, when service-orientedizing the contract execution logic contained in the smart contracts deployed on each member blockchain, a user-facing service can be registered on the blockchain service network's management platform. This user service is then directly bound to the contract execution logic that needs to be serviced before being made available to users.

[0024] Since the user service that has been registered will eventually need to be made available to users, 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 users, thus facing the risk of privacy exposure.

[0025] In view of this, this specification proposes a smart contract cross-chain calling scheme in application scenarios where the contract execution logic contained in smart contracts deployed on the blockchain is serviced. This scheme binds the contract execution logic that needs to be serviced to the service interface of the user service that is open to users, and dynamically determines the contract execution logic to be called from the contract execution logic bound to the service interface of the user service when calling the user service.

[0026] In implementation, the contract execution logic contained in user smart contracts deployed on the blockchains of at least some members of the blockchain service network can still be made publicly available and invoked as user services. However, the contract execution logic corresponding to this user service does not need to be directly bound to the user service itself, but rather to the service interface corresponding to that user service.

[0027] When a node device in any target member blockchain of the blockchain service network receives a call data initiated by a service user that contains the service interface of that user service, it can respond to the call data, 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 bound to the service interface, and then initiate a cross-chain call to the user smart contract deployed on the aforementioned other member blockchains that contains the target contract execution logic, so as to complete the service call for the individual user service.

[0028] In the above technical solution, on the one hand, since the blockchain service network supports the service-oriented approach to the contract execution logic contained in user smart contracts deployed on each member's blockchain, and exposes it as a user service for invocation, and the contract execution logic corresponding to the user service is no longer directly bound to the user service, but rather bound to the service interface corresponding to the user service; therefore, when the user service is exposed to the service user, only the service interface corresponding to the user service needs to be exposed to the service user, while the information related to the contract execution logic bound to the service interface does not need to be exposed to the service user, thereby avoiding privacy leaks caused by directly exposing the information related to the contract execution logic corresponding to the user service to the service user.

[0029] For example, taking the contract execution logic corresponding to the aforementioned user service as an executable function, if the user service is directly bound to these executable functions, it would be necessary to expose information such as the function names to the user. However, if the user service is bound to a service interface, it is only necessary to expose information such as the service interface and even the functional descriptions of these functions to the user, while the actual content such as the function names does not need to be exposed to the user.

[0030] On the other hand, when a service user calls the contract execution logic bound to the service interface of the user service across chains through the system smart contract, the final contract execution logic 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 aforementioned user service when it is called can be improved.

[0031] For example, in practical applications, this service interface can be bound to multiple contract execution logics with the same service functions. Thus, the system's smart contract can flexibly specify one contract execution logic from the multiple contract execution logics bound to the service interface for the user to call according to specific needs. This calling method obviously has the characteristics of high flexibility.

[0032] Moreover, in this way, the service user cannot know in advance the smart contract in which the execution logic of the invoked contract is located, or the member blockchain in which the smart contract is located; therefore, this method of cross-chain contract invocation will have high privacy and security.

[0033] For example, taking the contract execution logic corresponding to the aforementioned user service as an executable function, the function allocated by the system smart contract from the executable functions bound to the service interface of that user service when the user calls the service is completely uncertain to the user, and the user cannot know this information in advance. Therefore, this calling method obviously has a certain degree of concealment, which can fully ensure the privacy and security when these contract execution logics are called.

[0034] Please see Figure 1 , Figure 1 This is a network architecture diagram of a blockchain service network illustrated in an exemplary embodiment of this specification.

[0035] like Figure 1 As shown, the network architecture of the aforementioned blockchain service network may include a blockchain service network composed of several member blockchains, a target blockchain network to be registered, and a centralized management platform for managing the blockchain service network.

[0036] Specifically, the centralized management platform mentioned above can be a service platform used for centralized management of the aforementioned blockchain service network. The hardware device supporting this centralized management platform can be a server or a server cluster consisting of several servers, without particular limitation in this specification.

[0037] The aforementioned centralized management platform, as a centralized service platform, can manage the members of the aforementioned blockchain service network. For example, it can be responsible for the registration, joining, and leaving of member blockchains within the blockchain service network, and so on.

[0038] In addition, the aforementioned centralized control platform can also be used to enable cross-chain access between member blockchains;

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

[0040] Of course, besides implementing management functions for each member blockchain by issuing and deploying system smart contracts to each member blockchain, the centralized control platform can also be equipped with a cross-chain service component. This cross-chain service component can be specifically used to realize cross-chain data interaction between member blockchains. Each member blockchain that joins the blockchain service network can use the cross-chain service component on the aforementioned centralized control platform to achieve cross-chain data access with other member blockchains.

[0041] Please continue reading Figure 1 It should be noted that, initially, the blockchain service network may not have any member blockchains. The target blockchain can only join the blockchain service network after registering through the centralized management platform.

[0042] in, Figure 1 The first member blockchain, the second member blockchain, and the third member blockchain shown refer to the member blockchains that have joined the aforementioned blockchain service network. Figure 1 The target blockchain networks to be registered shown refer to blockchain networks that have not yet joined the blockchain service network. These target blockchain networks can apply to join the target blockchain network as member blockchains by registering with the centralized management platform.

[0043] Please see Figure 2 , Figure 2 This is a flowchart illustrating a method for constructing a blockchain service network according to an exemplary embodiment, which can be applied to... Figure 1 The centralized control platform shown; the method includes:

[0044] Step 201: Receive the registration request corresponding to the target blockchain;

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

[0046] Specifically, the aforementioned registration request may be initiated by a user with registration permissions for the target blockchain through a user account registered on the aforementioned centralized management platform.

[0047] For example, in practical applications, a user with registration permissions for the target blockchain, registered on the centralized management platform, can specifically include the system administrator account on the centralized management platform, the administrator account registered on the centralized management platform by the administrator of the target blockchain, the user account registered on the centralized management platform by the user deployer of the user smart contract on the target blockchain, and so on. It should be noted that the user account issuing the registration request specifically refers to the centralized account registered on the centralized management platform, and not the blockchain account registered on each member blockchain.

[0048] The registration request may include basic registration information related to the target blockchain to be registered. This basic registration information may specifically include the access address information of the target blockchain, and the blockchain configuration information related to the target blockchain, etc.

[0049] Of course, in practical applications, the registration request may include not only 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 management platform. In practical applications, the access address information may specifically include the domain name information or IP address information corresponding to one or more node devices in the target blockchain, enabling the centralized management platform to establish a communication connection with one or more node devices in the target blockchain based on the aforementioned domain name information or IP address information.

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

[0051] Step 202: In response to the registration request, perform registration processing on the target blockchain to add the target blockchain as a member blockchain to the blockchain service network;

[0052] When a centralized management platform receives a registration request corresponding to a target blockchain, it can respond to the registration request and perform a legality check on the registration request. For example, the legality 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.

[0053] After the centralized management platform completes the legality check on the registration request, if the registration request passes the legality check, the centralized management platform can further process the registration of the target blockchain based on the data content carried in the registration request, so as to add the target blockchain as a member blockchain to the blockchain service network.

[0054] Specifically, the registration process performed by the centralized control platform on the target blockchain may include creating a blockchain account in the target blockchain that corresponds to the centralized control platform.

[0055] For example, in implementation, a public-private key pair can be applied for 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 generated 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.

[0056] It's important to note that in blockchains employing an account model, the types of accounts supported typically include external accounts and contract accounts. External accounts are those directly controlled by the user, also known as user accounts. Contract accounts, on the other hand, are 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, as 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 platform acquires a legitimate user identity within that blockchain. This allows the centralized control platform to initiate contract calls to the user's smart contracts deployed on the target blockchain based on this external account.

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

[0058] For example, in one embodiment shown, the registration process performed by the centralized control platform on the target blockchain 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.

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

[0060] Please see Figure 3 , Figure 3 This specification illustrates a flowchart of a registration process for a target blockchain, including the following execution steps:

[0061] Step 301: The registration party initiates a registration request to the centralized platform corresponding to the target blockchain;

[0062] Upon receiving the registration request, the centralized management platform can respond to the request and begin the registration process for the target blockchain. In this embodiment, the registration process for the target blockchain may include the registration process flow shown in steps 302-306 below.

[0063] Step 302: Save the blockchain configuration information of the target blockchain;

[0064] Step 303: Establish communication connections with at least some of the node devices in the target blockchain based on the access address information of the target blockchain;

[0065] As mentioned above, the registration request may include some blockchain configuration information related to the target blockchain; for example, the blockchain configuration information may include the access address information of the target blockchain, as well as configuration information related to the target blockchain, etc. After receiving the registration request, the centralized control platform can obtain the blockchain configuration information carried in the registration request, and then perform subsequent registration processing procedures for the target blockchain based on the obtained blockchain configuration information.

[0066] Upon receiving the aforementioned registration request, the centralized control platform can store the blockchain configuration information related to the target blockchain, which it reads from the registration request, as the configuration information of the member blockchain in its local database.

[0067] For example, in implementation, the centralized management platform can maintain a database for storing blockchain configuration information related to each member blockchain in the aforementioned blockchain service network. The centralized management platform can read the blockchain configuration information related to the target blockchain from the aforementioned registration request and store it in the database as the blockchain configuration information of the member blockchain.

[0068] After storing the blockchain configuration information related to the target blockchain as the configuration information of the member blockchain in its local database, the centralized control platform can further establish communication connections with at least some of the node devices in the target blockchain based on the access address information of the target blockchain read from the registration request.

[0069] 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 platform can establish communication connections with one or more node devices in the target blockchain based on the aforementioned domain name information or IP address information. In implementation, the centralized management platform can establish communication connections with all node devices in the target blockchain, or it can establish communication connections only with some key node devices in the target blockchain (such as a full node storing the complete blockchain ledger).

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

[0071] After establishing a communication connection with at least some of the node devices in the target blockchain, the centralized 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.

[0072] The blockchain data related to the target blockchain obtained from the node devices in the target blockchain may specifically include any form of data related to the target blockchain, and is not specifically limited in this specification.

[0073] For example, in one instance, the blockchain data related to the target blockchain obtained from the node devices 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.

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

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

[0076] For example, as mentioned earlier, the centralized control platform can maintain a database for storing blockchain configuration information related to each member blockchain in the aforementioned blockchain service network. The centralized control platform can store the blockchain configuration information related to the target blockchain read from the registration request as the blockchain configuration information of the member blockchain in this database. Furthermore, after obtaining blockchain data related to the target blockchain from the node devices in the target blockchain, the centralized control platform can also associate the obtained blockchain data with the blockchain configuration information related to the target blockchain in the aforementioned database.

[0077] Step 305: Create a blockchain account on the target blockchain that corresponds to the centralized control platform.

[0078] After obtaining the relevant blockchain data from the node devices in the target blockchain based on the aforementioned communication connection, the centralized control platform can then create a corresponding blockchain account for itself on the target blockchain. The specific process for creating this blockchain account will not be elaborated further.

[0079] Once a corresponding blockchain account is created for the centralized control platform on the aforementioned target blockchain, the centralized control platform has obtained a legitimate user identity on the target blockchain and has the ability to call the user smart contracts deployed on the target blockchain. Subsequently, the centralized control platform can initiate contract calls for the user smart contracts deployed on the target blockchain based on the blockchain account.

[0080] Specifically, the centralized control platform can maintain a list of blockchain accounts. This list can include blockchain accounts created on various member blockchains corresponding to the centralized control platform. Once a corresponding blockchain account is created for the centralized control platform on the target blockchain, that account can be added to the aforementioned list of blockchain accounts for maintenance.

[0081] 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 scenario, to facilitate account management, the blockchain accounts corresponding to the centralized control platform created on each member blockchain can, by default, use the same preset blockchain account. Alternatively, each member blockchain can pre-reserve a specific blockchain account as the blockchain account corresponding to the centralized control platform.

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

[0083] After creating a corresponding blockchain account for the centralized control platform on the aforementioned target blockchain, the centralized control platform can further deploy at least one system smart contract on that target blockchain. Specifically, the aforementioned at least one system smart contract may include a target system smart contract used for cross-chain communication with other member blockchains.

[0084] In addition to the target system smart contract used for cross-chain communication with other member blockchains, the above-mentioned at least one system smart contract may also include smart contracts for service management of the target blockchain, system smart contracts for network governance of the target blockchain network, system smart contracts for service incentives for users registered on the centralized management platform, etc., which are not specifically limited in this specification.

[0085] Of course, in practical applications, the target system smart contracts mentioned above for cross-chain communication with other member blockchains, smart contracts for service management of the target blockchain, system smart contracts for network governance of the target blockchain network, and system smart contracts for service incentives for users registered on the centralized management platform can be integrated into a single system smart contract.

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

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

[0088] The contract execution logic contained in the smart contracts of the aforementioned system is usually related to the execution logic of some management functions on the centralized control platform.

[0089] For example, the contract execution logic contained in the system smart contract for network governance, as described above, can be the execution logic related to the function of the centralized management platform in governing the aforementioned blockchain service network. Similarly, the contract execution logic contained in the system smart contract for incentivizing users registered on the centralized management platform can be the execution logic related to the function of the centralized management platform incentivizing registered users. 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.

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

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

[0092] Once the centralized management platform has executed the registration processes shown in steps 302-306 for the target blockchain, the target blockchain will successfully join the blockchain service network as a member blockchain.

[0093] In this scenario, the centralized control platform returns a successful registration message corresponding to the target blockchain to the registrant, informing them that the target blockchain has successfully joined the blockchain service network as a member blockchain.

[0094] It should be noted that the order of the registration processes shown in steps 302-306 of the above embodiments is merely illustrative and is not specifically limited in this specification. It is understood that in practical applications, the order of the registration processes shown in steps 302-306 of the above embodiments can be flexibly adjusted and interchanged based on actual registration needs.

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

[0096] For example, in practical 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 that correspond to different service functions.

[0097] The centralized management platform mentioned above can also support the service-oriented functionality of providing the contract execution logic contained in user smart contracts deployed on at least some member blockchains within the aforementioned blockchain service network. Accordingly, service providers can use the aforementioned functionality supported by the centralized management platform to provide the service-oriented functionality of the contract execution logic contained in user smart contracts deployed on at least some member blockchains, and then expose it to service users in the form of a user service for them to call.

[0098] It should be noted that when providing services for the contract execution logic contained in user smart contracts on at least some member blockchains in a blockchain service network, the specific service can be provided for a particular contract execution logic contained in a user smart contract, or multiple contract execution logics can be combined and then provided as a whole.

[0099] In other words, user services generated through service-oriented architecture can specifically refer to a service consisting of a specific contract execution logic contained in a user smart contract deployed on each member blockchain of 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 member blockchains of the blockchain service network.

[0100] For example, suppose a user deploys a user smart contract on a member blockchain. This 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 centralized management platform, and make it available to other users for them to call.

[0101] 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 execution logic of the multiple user smart contracts into a user service, register a user service bound to the execution logic of the multiple contracts on the centralized management platform, and open it to other users for them to call.

[0102] Specifically, when combining the execution logic of multiple contracts mentioned above and then service-making them, the execution logic of user smart contracts distributed on multiple different member blockchains can be combined to generate a user service and then service-made. Alternatively, the execution logic of multiple user smart contracts in the same member blockchain can be combined to generate a service and then service-made. No particular limitation is made in this specification.

[0103] It should be noted that when combining the execution logic of multiple contracts, these execution logics can also be combined in a certain logical order. This logical order typically depends on the specific service requirements of the service user and can be flexibly determined based on actual service needs in practice.

[0104] In this specification, when service-orientedizing the contract execution logic, it is still possible to register user services on the aforementioned centralized management platform and bind the registered user services to the contract execution logic that needs to be service-oriented.

[0105] In other words, service providers can initiate service registration with the centralized management platform to register the corresponding user service for the contract execution logic that needs to be serviced, and then bind the user service to the aforementioned contract execution logic to complete the service-oriented approach for that contract execution logic.

[0106] It should be noted that the specific process of the service provider initiating service registration with the centralized management platform will not be detailed in this specification. Those skilled in the art can refer to the records in related technologies.

[0107] In order to avoid exposing information related to the service-oriented contract execution logic to the service users, when binding the registered user service with the contract execution logic, it is no longer necessary to bind the user service directly to the contract execution logic. Instead, a service interface can be set up for the registered user service on the centralized management platform, and the service interface of the user service can be bound to the contract execution logic.

[0108] It should be noted that the aforementioned service interface can specifically be a service identifier that can uniquely identify the user service. The number of service interfaces set up for the aforementioned user service can be one or more, and this specification does not impose any particular limitation.

[0109] In one embodiment shown, taking the user service as an example of a service generated by combining multiple contract execution logics, when setting up a service interface for the user service, the user service can be specifically divided into multiple sub-services corresponding to different service functions, and a corresponding service interface can be set up for each sub-service, and then the corresponding contract execution logic can be bound to each service interface.

[0110] To improve the service stability of each sub-service, when binding contract execution logic to the service interfaces of each sub-service, multiple contract execution logics with the same service function 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 allocated from the multiple contract execution logics bound to the sub-service based on a certain scheduling strategy, and then the service can be provided to the service caller.

[0111] For example, see Figure 4 , Figure 4 This is a schematic diagram illustrating how to set up a service interface for a user service and bind contract execution logic to the service interface.

[0112] like Figure 4 As shown, Figure 4 The examples shown are contract instances 1-7, which belong to user smart contracts deployed on member blockchains A, B, and C, respectively. A contract instance refers to the contract execution logic contained within a user smart contract; for example, it could be an executable function within the user smart contract.

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

[0114] Figure 4 Service B, as shown, can be divided into sub-services 3, 4, and 5 according to its service functions. The service interface for sub-service 3 is b1, which is bound to only one contract instance 1. The service interface for sub-service 4 is b2, which is bound to two contract instances 4 and 5 with the same service function. The service interface for sub-service 5 is b3, which is bound to two contract instances 3 and 6 with the same service function.

[0115] Figure 4The service C shown can be separated into sub-services without further subdivision. The service interface set for this service C is C1, and this service interface C1 is only bound to one contract instance 7.

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

[0117] In this specification, when a service provider registers a user service on the aforementioned centralized management platform and binds the contract execution logic that needs to be service-oriented to the user service, the centralized management platform can deploy the target user service as a standardized service and make it available for service users to call.

[0118] It should be noted that the centralized management platform can adopt a distributed deployment approach when deploying the aforementioned user services after registration.

[0119] The so-called distributed deployment specifically refers to the distributed deployment of the aforementioned user services on the blockchains of each member in the form of system smart contracts, so that service users can call them.

[0120] On the one hand, since the contract call logic that makes up the above-mentioned user service may include the contract execution logic contained in multiple user smart contracts deployed on multiple member blockchains, the service user may also need to make cross-chain calls to multiple user smart contracts distributed on multiple member blockchains when calling the above-mentioned user service. Therefore, when the above-mentioned centralized control platform deploys the above-mentioned user service, it 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.

[0121] For example, as mentioned earlier, the contract execution logic contained in the aforementioned system smart contracts is typically related to the execution logic of some management functions on the centralized control platform. Therefore, in this way, it is equivalent to deploying the cross-chain call logic developed for the user service, as part of the execution logic related to some management functions on the centralized control platform, in the form of system smart contracts on each member blockchain.

[0122] In addition, when deploying the user service, the binding relationship between the user service's service interface and the contract execution logic can also be stored in the aforementioned system smart contract as the user service's service configuration information, and maintained by the aforementioned system smart contract.

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

[0124] Please see Figure 5 , Figure 5 This is a flowchart illustrating a service registration method according to an exemplary embodiment, which is applied to... Figure 1 The method includes: a node device in any of the target member blockchains shown; wherein, on each member blockchain of the aforementioned blockchain network, the aforementioned system smart contract is deployed; the aforementioned system smart contract contains service registration logic corresponding to the aforementioned user service; the method includes:

[0125] 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;

[0126] Once a service provider registers a user service on the aforementioned centralized management platform and distributes it in the form of a system smart contract across the member blockchains of the aforementioned blockchain service network, the service user can submit the user service registration data to the node device in the target member blockchain to initiate a contract call against the aforementioned system smart contract and obtain the service call permission for that user service.

[0127] It should be noted that the user of the aforementioned service can be a user who has registered a user account on the target member's blockchain, or a user smart contract deployed on the target member's blockchain, without any special limitation in this specification.

[0128] In one embodiment shown, if the user of the service 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 smart contract of the system packaged by the user through the user client that accesses the target member blockchain.

[0129] The user client can submit the packaged smart contract call transaction as the aforementioned call data to the node device in the target member blockchain, initiate a contract call for the cross-chain call logic contained in the aforementioned system smart contract, and trigger the node device in the target member blockchain to perform the aforementioned cross-chain call logic contained in the system smart contract in a distributed manner, thereby obtaining the service call permission of the user service.

[0130] Of course, in practical applications, the user can also submit the smart contract call data for the smart contract of the system to the BaaS platform corresponding to the target member blockchain through the aforementioned user client. The BaaS platform will then package the call data into a contract call transaction for the smart contract of the system and submit it to the node device in the target member blockchain.

[0131] In another implementation shown, if the user of the aforementioned service is a user smart contract deployed on the target member's blockchain, the user smart contract may contain contract execution logic that references the service interface of the aforementioned user service.

[0132] Referencing a user service interface within the contract execution logic typically means referencing that user service interface within the contract code corresponding to the execution logic. This allows the contract code, when invoked by the user, to further invoke the user service corresponding to that interface during execution. Similarly, when a user invokes a contract call targeting the execution logic contained within the user's smart contract, the smart contract can, based on the service interface referenced by the execution logic, further invoke the user service corresponding to that referenced interface.

[0133] Since the aforementioned user services are deployed in a distributed manner in the form of system smart contracts, the process of the user smart contract initiating a service call for the referenced user services is actually a mutual call process between the user smart contract and the aforementioned system smart contract.

[0134] Inter-contract calls typically employ a message-based invocation mechanism. Therefore, in practical applications, the aforementioned invocation data can specifically be a call message generated by the user's smart contract based on the message-based invocation mechanism between smart contracts when the user invokes the execution logic of a contract that references the aforementioned user service.

[0135] In this scenario, when a user initiates a contract call targeting the execution logic contained within their smart contract, the user's smart contract can generate a call message for the aforementioned system smart contract based on the message call mechanism between smart contracts.

[0136] Then, the call message is submitted to the system smart contract as call data for the aforementioned user service, initiating a contract call to the system smart contract to trigger the distributed execution of the aforementioned user registration logic contained in the system smart contract by the node devices in the blockchain, thereby obtaining the service call permission for the aforementioned user service.

[0137] The process of smart contracts calling each other using a message-based mechanism will not be detailed in this specification. Those skilled in the art can refer to relevant technical records when implementing the technical solutions described in this specification.

[0138] It should be noted that the aforementioned call message can be any form of data suitable for transmission between smart contracts, and is not specifically limited in this specification.

[0139] For example, in one instance, the aforementioned call message could specifically be an executable instruction defined based on the development language used by the smart contract, suitable for transmission between smart contracts. For instance, assuming the contract code in the smart contract uses the high-level development language Solidity, the aforementioned call message could specifically be a `call` instruction targeting the aforementioned system's smart contract.

[0140] Step 504: In response to the registration data, the service registration logic contained in the system smart contract is invoked, the target contract execution logic is determined for the service user from the contract execution logic bound to the service interface, and the service invocation permissions related to the target contract execution logic are authorized to the service user.

[0141] In this specification, the service interface corresponding to the aforementioned user service may be included in the aforementioned registration data.

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

[0143] In this scenario, the service user can choose to register for use of one or more sub-services within the user service. Correspondingly, the registration data can also include the service user's selection of one or more service interfaces from among these multiple service interfaces to be registered.

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

[0145] 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, after the node device in the target member blockchain calls the above-mentioned system smart contract containing the above-mentioned user registration logic and obtains the service interface carried in the above-mentioned call data, it can first determine whether the service interface is bound to multiple contract execution logics.

[0146] For example, in one instance, after a service provider registers a user service through a centralized management platform, the centralized management 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 aforementioned system smart contract. Thus, the aforementioned system smart contract can query the maintained binding relationship to determine whether the service interface carried in the user registration data is bound to multiple contract execution logics.

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

[0148] In this way, when a service user requests service access permission by calling the service registration logic contained in the system smart contract, the contract execution logic that ultimately grants the service access permission is dynamically determined by the system smart contract from the contract execution logic bound to the service interface. Therefore, this method can improve the flexibility for users when registering to use the aforementioned user services.

[0149] Moreover, service users cannot know in advance the smart contract in which the service permission they requested is executed, or the member blockchain in which the smart contract is located; therefore, this service registration method will have high privacy and security.

[0150] It should be noted that the aforementioned preset scheduling strategy can be used in any form to dynamically allocate 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 practical applications, specific scheduling strategies can be flexibly set based on specific scheduling requirements.

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

[0152] Scheduling Strategy 1:

[0153] A scheduling strategy is used to randomly assign contract execution logic to service users from multiple contract execution logics bound to the aforementioned service interfaces.

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

[0155] In this way, service users cannot be aware of the contract call logic that provides services to them in advance, thus ensuring privacy to the greatest extent when calling user services.

[0156] Scheduling Strategy 2:

[0157] The scheduling strategy assigns the pre-specified contract execution logic from the multiple contract execution logics bound to the aforementioned service interfaces to the service users.

[0158] Based on this strategy, service providers can flexibly specify the contract execution logic for providing services to service users from multiple contract execution logics bound to the aforementioned service interfaces, thereby improving the service flexibility of the aforementioned user services.

[0159] For example, in practical applications, for certain service users, a fixed contract execution logic can be specified from the above multiple contract execution logics to provide services to that service user.

[0160] Scheduling Strategy 3:

[0161] The scheduling strategy assigns the contract execution logic that meets the preset conditions among the multiple contract execution logics bound to the above service interfaces to the above service users.

[0162] Based on this strategy, the centralized management platform can collect service metrics for each contract execution logic bound to the service interface in real time, and store these service metrics in the system smart contract. The system smart contract maintains these metrics, allowing it to filter out contract execution logics that meet preset conditions and allocate them to service users. This enables refined management of each contract execution logic bound to the service interface.

[0163] For example, based on the service metrics of the various contract execution logics bound to the aforementioned service interfaces, a contract execution logic most suitable for the service user can be selected, and the service can be provided to that user.

[0164] The aforementioned service metrics can specifically include any form of metric that can characterize the usage status of the contract execution logic bound to the aforementioned service interface, and are not specifically limited in this specification. Correspondingly, the aforementioned preset conditions usually depend on the specific type of the aforementioned service metrics, and in practical applications, they can be flexibly set based on specific service requirements.

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

[0166] In this case, when the smart contract of the system dynamically allocates 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 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.

[0167] Since the number of service users provided by each contract execution logic can generally 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.

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

[0169] In addition to the condition that the above preset conditions may include the condition that the number of contract execution logics with the smallest number among the multiple contract execution logics bound to the above service interface, other forms of conditions may also be included in practical applications, which will not be listed one by one in this specification; for example, in one example, the above preset conditions may also include the contract execution logics with a number lower than the threshold.

[0170] In one embodiment shown, after assigning contract execution logic to the service user to provide services to the service user, service registration information for the user service can be generated and stored in the system smart contract so that the system smart contract can maintain the stored service registration information.

[0171] Specifically, the service registration information mentioned above may include information related to the target contract execution logic that the system smart contract allocates to the service user from multiple contract execution logics bound to the service interface based on the scheduling strategy mentioned above; for example, it may be the identification information (such as function name) corresponding to the target contract execution logic.

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

[0173] In one embodiment shown, the user service invocation permission and the contract execution logic invocation permission bound to the service interface of the user service can be authorized as two separate permissions.

[0174] In this case, when authorizing the service user to call the execution logic of the target contract, the service call permission of the user service can be authorized to the target user smart contract first; and then, the service call permission of the execution logic of the target contract can be authorized to the service user.

[0175] In this way, fine-grained management of the aforementioned user services can be achieved. For example, after granting service call permissions to the aforementioned user services to the service users, the target contract execution logic allocated to the service users from the multiple contract execution logics bound to the user service can be granted a separate authorization. This fundamentally avoids the mutual interference between the service call permissions of the aforementioned user services and the call permissions of the contract execution logic bound to the user service.

[0176] In one embodiment shown, if the service user is a user smart contract deployed on the target member blockchain, when authorizing the service call permission of the 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 call permission of the user smart contract can also be correspondingly authorized to the target contract execution logic.

[0177] In this way, on the one hand, since the contract execution logic contained in the user's smart contract may also be bound to the service interface of another user service, by adopting this two-way permission authorization method, the calling permissions related to the other user service can also be synchronously authorized to the target contract execution logic. This avoids the need to repeatedly authorize the target contract execution logic through the authorization method described above when it has a calling requirement for the other user service in the future.

[0178] On the other hand, by adopting this two-way permission authorization method, the execution logic of the target contract can synchronously obtain the calling permission of the contract execution logic contained in the user smart contract. Therefore, for the execution logic of the target contract, the service call result of the user smart contract acting as the service caller can be returned to the user smart contract acting as the service caller in a timely manner by calling back the user smart contract acting as the service user, without the need to use the asynchronous return of service call result, thereby improving the service call efficiency when calling the user service.

[0179] Please see Figure 6 , Figure 6 This is a flowchart illustrating a cross-chain invocation method for a smart contract according to an exemplary embodiment, which is applied to... Figure 1 The method includes: a node device in any of the target member blockchains shown; wherein, on each member blockchain of the blockchain network, the aforementioned system smart contract is deployed; the aforementioned system smart contract contains cross-chain call logic corresponding to the user service; the method includes:

[0180] Step 602: Obtain the call data of the service user 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;

[0181] When a service provider registers a user service on the aforementioned centralized management platform, and the user service is distributed across the member blockchains of the aforementioned blockchain service network in the form of a system smart contract, and the user service provider completes the registration for the user service, the user service provider can initiate a contract call to the aforementioned system smart contract by submitting the call data for the user service to the node device in the target member blockchain to which it is connected, thereby completing the service call for the user service.

[0182] In one embodiment, if the service user is a user who has registered an account on the target member blockchain, the call data can specifically 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 can submit the packaged smart contract call transaction to a node device in the target member blockchain to initiate a contract call for the system smart contract. This triggers the node devices in the target member blockchain to perform distributed execution of the cross-chain call logic contained in the system smart contract, thereby completing the service call for the user.

[0183] Of course, in practical applications, the user can also submit the smart contract call data for the smart contract of the system to the BaaS platform corresponding to the target member blockchain through the aforementioned user client. The BaaS platform will then package the call data into a contract call transaction for the smart contract of the system and submit it to the node device in the target member blockchain.

[0184] In another embodiment shown, if the service user is a user smart contract deployed on the target member's blockchain, the user smart contract may contain contract execution logic that references the service interface of the user service. When a user initiates a contract call to the contract execution logic contained in the user smart contract, the user smart contract may specifically generate a call message to the system smart contract based on the message call mechanism between smart contracts. Then, this call message is submitted to the system smart contract as call data for the user service, initiating a contract call to the system smart contract to trigger the distributed execution of the cross-chain call logic contained in the system smart contract by the nodes in the blockchain, thereby completing the service call to the user service.

[0185] For example, in one instance, the aforementioned call message could specifically be an executable instruction defined based on the development language used by the smart contract, suitable for transmission between smart contracts. For instance, assuming the contract code in the smart contract uses the high-level development language Solidity, the aforementioned call message could specifically be a `call` instruction targeting the aforementioned system's smart contract.

[0186] Step 604: In response to the call data, invoke the cross-chain call logic contained in the system smart contract, determine the target contract execution logic for the service user 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 blockchains.

[0187] In this specification, the aforementioned call data may specifically carry the service interface corresponding to the aforementioned user service.

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

[0189] In this scenario, the service user can choose to invoke one or more sub-services within the user service. Correspondingly, the invocation data can also include the service user's selection of one or more service interfaces from among these multiple service interfaces.

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

[0191] 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, after the node device in the target member blockchain calls the cross-chain call logic contained in the system smart contract and obtains the service interface carried in the call data, it can first determine whether the service interface is bound to multiple contract execution logics.

[0192] For example, in one instance, after a service provider registers a user service through a centralized management platform, the centralized management 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 aforementioned system smart contract. Thus, the aforementioned system smart contract can query the maintained binding relationship to determine whether the service interface carried in the aforementioned call data is bound to multiple contract execution logics.

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

[0194] In this way, when a service user calls the contract execution logic bound to the service interface of the user service across chains through the system smart contract, the final contract execution logic called is dynamically determined by the system smart contract from the contract execution logic bound to the service interface; therefore, this method can improve the flexibility of the aforementioned user service when it is called.

[0195] Moreover, service users cannot know in advance the smart contract in which the execution logic of the invoked contract resides, or the member blockchain in which the smart contract is located; therefore, this method of cross-chain contract invocation will have high privacy and security.

[0196] It should be noted that the aforementioned preset scheduling strategy can be used in any form to dynamically allocate contract execution logic from multiple contract execution logics bound to the service interface to the service user, and is not specifically limited in this specification. In practical applications, the specific scheduling strategy can be flexibly set based on specific scheduling requirements. For example, in this embodiment, the aforementioned scheduling strategy may still include... Figure 5 The combination of any one or more of the scheduling strategies 1, 2, and 3 described in the embodiments shown will not be repeated in this embodiment.

[0197] In one embodiment shown, as described above, since the system smart contract can maintain the service registration information of the service user for the user service in advance, and the service registration information can include information related to the target contract execution logic that provides services to the service user, allocated by the system smart contract to the service user from multiple contract execution logics bound to the service interface corresponding to the user service during the service user's registration stage, based on the aforementioned preset scheduling strategy; therefore, in this case, when the system smart contract determines the target contract execution logic for the service user from the contract execution logic bound to the aforementioned 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 service registration information, and then directly allocate the target contract execution logic to the service user.

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

[0199] In this specification, after the cross-chain call logic contained in the above-mentioned system smart contract is invoked, and the target contract execution logic for providing services to the service user is determined from the contract execution logic bound to the service interface, a cross-chain call can be further initiated against user smart contracts containing the target contract execution logic deployed on other member blockchains.

[0200] In one embodiment shown, as previously described, since the user's access to the user service and access to the contract execution logic bound to the service interface can be granted as two separate permissions during the service registration phase, the user's access to the user service and access to the contract execution logic bound to the service interface can be authorized to the user separately. Therefore, in this case, before calling the cross-chain calling logic contained in the system smart contract to determine the target contract execution logic for the user from the contract execution logic bound to the service interface, the system smart contract can first call the permission verification logic to verify whether the user has access to the user service. If so, the system smart contract can further call the cross-chain calling logic to determine the target contract execution logic for the user from the contract execution logic bound to the service interface.

[0201] In another implementation shown, for 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 a user smart contract containing the contract execution logic deployed on other member blockchains, the system smart contract's permission verification logic can be called first to verify whether the service user has the permission to call the target contract execution logic; if so, then a cross-chain call to the user smart contract containing the target contract execution logic deployed on the other member blockchain is initiated.

[0202] The specific method by which the system's smart contract initiates a cross-chain call to a user smart contract deployed on another member's blockchain that contains the execution logic of the target contract can still be accomplished using a message call mechanism between smart contracts, and will not be detailed in this specification.

[0203] Corresponding to the embodiments of the foregoing methods, this specification also provides embodiments of apparatus, electronic devices, and storage media.

[0204] Figure 7 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Please refer to... Figure 7 At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, memory 708, and non-volatile memory 810, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 702 reading the corresponding computer program from the non-volatile memory 710 into memory 708 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 hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0205] like Figure 8 As shown, Figure 8 This is a block diagram illustrating a cross-chain invocation device for smart contracts according to an exemplary embodiment. This device can be applied to applications such as... Figure 7 The illustrated electronic device is used to implement the technical solution described in this specification. This device can be applied to a node device in any target member blockchain of a blockchain service network composed of several member blockchains; wherein, the contract execution logic contained in user smart contracts deployed on at least some member blockchains of the blockchain service network is open for invocation in the form of user services; system smart contracts are deployed on each member blockchain of the blockchain network; the system smart contracts contain cross-chain invocation logic corresponding to the user services; the device 80 includes:

[0206] The acquisition module 801 acquires the call data for the user service initiated by the service user; 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;

[0207] Module 802, in response to the call data, invokes the cross-chain call logic contained in the system smart contract, determines the target contract execution logic for the service user from the contract execution logic bound to the service interface, and initiates a cross-chain call to the user smart contract containing the target contract execution logic deployed on the other member blockchains.

[0208] The specific details of each module of the aforementioned device 80 have been described in detail in the previously described method flow, so they will not be repeated here.

[0209] Accordingly, this specification also provides an electronic device including a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement all the steps in the previously described method flow.

[0210] Accordingly, this specification also provides a computer-readable storage medium having executable instructions stored thereon; wherein, when executed by a processor, the instructions implement all the steps in the previously described method flow.

[0211] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

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

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

[0214] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0215] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0216] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0217] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0218] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0219] 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 information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, 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," "in response to a determination," or "when," or "in the event of a determination."

[0220] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of 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 should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A method for cross-chain invocation of smart contracts, wherein the method is applied to a node device in any target member blockchain of a blockchain service network composed of several member blockchains; wherein, The contract execution logic contained in user smart contracts deployed on at least some member blockchains of the blockchain service network is open for invocation in the form of user services; each member blockchain of the blockchain network deploys a system smart contract; the system smart contract contains cross-chain invocation logic corresponding to the user service; the user service includes a service generated by combining multiple contract execution logics contained in user smart contracts deployed on at least some member blockchains of the blockchain service network; the user service includes multiple service interfaces; different service interfaces correspond to different service functions; At least some of the service interfaces are bound to multiple contract execution logics with the same service function; The method includes: Obtain the call data of the service user 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; In response to the call data, the cross-chain call logic contained in the system smart contract is invoked. From the contract execution logic bound to the service interface, the target contract execution logic is determined for the service user, and a cross-chain call is initiated against the user smart contract containing the target contract execution logic deployed on the other member blockchain.

2. The method according to claim 1, wherein determining the target contract execution logic for the service user from the contract execution logic bound to the service interface includes: Determine whether the service interface is bound to multiple contract execution logics; If so, based on a preset scheduling strategy, a target contract execution logic for providing services to the service user is allocated from multiple contract execution logics bound to the service interface.

3. The method according to claim 2, wherein the system smart contract maintains the binding relationship between the service interface and the contract execution logic; Determining whether the service interface is bound to multiple contract execution logics includes: The binding relationships maintained by the system's smart contract are queried to determine whether the service interface is bound to multiple contract execution logics. 4.The method of claim 1, wherein the system smart contract maintains service registration information of the service consumer for the user service; and wherein, The service registration information includes the target contract execution logic that the system smart contract allocates to the service user from multiple contract execution logics bound to the service interface corresponding to the user service, based on a preset scheduling strategy. From the contract execution logic bound to the service interface, determine the target contract execution logic for the service user, including: Obtain the target contract execution logic included in the service registration information.

5. The method according to claim 2 or 4, wherein the scheduling strategy comprises any or a combination of the following: A scheduling strategy for randomly assigning contract execution logic to the service user from multiple contract execution logics bound to the service interface; The scheduling strategy for allocating pre-specified contract execution logic from among the multiple contract execution logics bound to the service interface to the service user; The scheduling strategy allocates the contract execution logic that meets the preset conditions among the multiple contract execution logics bound to the service interface to the service user.

6. The method according to claim 5, wherein the service metric includes the number of service users provided by the contract execution logic; and the preset condition includes the contract execution logic with the smallest number among the multiple contract execution logics bound to the service interface.

7. The method according to claim 1, before invoking the cross-chain call logic contained in the system smart contract, the method further includes: The system's smart contract includes permission verification logic to verify whether the service user has permission to call the user service. If so, the cross-chain call logic contained in the system smart contract is further invoked.

8. The method according to claim 1, initiating a cross-chain call to a user smart contract containing the contract execution logic deployed on the other member blockchains, comprising: The system's smart contract includes permission verification logic to verify whether the service user has permission to invoke the execution logic of the target contract. If so, initiate a cross-chain call to the user smart contract containing the execution logic of the target contract deployed on the other member blockchains.

9. The method according to claim 1, wherein the service user includes a user smart contract deployed on the target member blockchain; the user smart contract contains contract execution logic that references the service interface of the user service; and the call data includes a call message generated by the user smart contract for the system smart contract when the user calls the contract execution logic contained in the user smart contract.

10. An apparatus for cross-chain invocation of a smart contract, the apparatus being applied to a node device in any target member blockchain in a blockchain service network composed of a plurality of member blockchains; wherein, The contract execution logic contained in the user smart contracts deployed on each member blockchain of the blockchain service network is open for invocation in the form of user services; each member blockchain of the blockchain network deploys a system smart contract; the system smart contract contains cross-chain invocation logic corresponding to the user service; the user service includes a service generated by combining multiple contract execution logics contained in the user smart contracts deployed on at least some member blockchains of the blockchain service network; the user service includes multiple service interfaces; different service interfaces correspond to different service functions; At least some of the service interfaces are bound to multiple contract execution logics with the same service function; The device includes: The acquisition module acquires call data for the user service initiated by the service user; 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 calling module, in response to the calling data, calls the cross-chain calling logic contained in the system smart contract, determines the target contract execution logic for the service user from the contract execution logic bound to the service interface, and initiates a cross-chain call to the user smart contract containing the target contract execution logic deployed on the other member blockchains.

11. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-9 by executing the executable instructions.

12. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-9.

Images