CN115664718A

CN115664718A - Cross-chain calling method and device for intelligent contract

Info

Publication number: CN115664718A
Application number: CN202211188911.2A
Authority: CN
Inventors: 刘勤; 黄胜
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-09-27
Filing date: 2022-09-27
Publication date: 2023-01-31
Also published as: WO2024066018A1

Abstract

One or more embodiments of the present specification provide a method and an apparatus for cross-chain calling of an intelligent contract. The method comprises the following steps: acquiring the use registration data of a service user aiming at the user service; the service interface of the user service is bound with contract execution logic contained in user intelligent contracts deployed on other member blockchains; in response to the usage registration data, invoking the service registration logic contained in the system intelligent contract, determining target contract execution logic for the service user from the contract execution logic bound with the service interface, and authorizing the service usage rights related to the target contract execution logic.

Description

Cross-chain calling method and device for intelligent contract

Technical Field

Embodiments of the present disclosure relate to the field of block chaining technology, and in particular, to a method and an apparatus for cross-chaining call of intelligent contracts.

Background

As blockchain technology develops, more and more blockchains are built, but most of the blockchains are independent and cannot be communicated with each other. Therefore, in practical applications, in order to fully utilize the service resources deployed on each block chain, the block chains can be used as member block chains to build a block chain service network, and contract execution logic included in intelligent contracts deployed on each member block chain is opened to a user in the form of user service through a management platform of the block chain service network for the user to call.

Disclosure of Invention

According to a first aspect of various embodiments of the present specification, a service usage registration method is provided, which is applied to a node device in any target member blockchain in a blockchain service network composed of a plurality of member blockchains; contract execution logic contained in user intelligent contracts deployed on at least part of member block chains in the block chain service network is called in an open mode in a user service mode; each member block chain in the block chain network is respectively provided with a system intelligent contract; the system intelligent contract comprises service registration logic corresponding to the user service;

the method comprises the following steps:

acquiring the use registration data of a service user aiming at the user service; the service interface of the user service is bound with contract execution logic contained in user intelligent contracts deployed on other member blockchains;

in response to the usage registration data, invoking the service registration logic contained in the system intelligent contract, determining target contract execution logic for the service user from the contract execution logic bound with the service interface, and authorizing the service usage rights related to the target contract execution logic.

According to a second aspect of various embodiments of the present specification, there is further provided a cross-link invoking apparatus for an intelligent 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; contract execution logic contained in a user intelligent contract deployed on at least part of member blockchains in the blockchain service network is called in an open mode in the form of user service; each member block chain in the block chain network is respectively provided with a system intelligent contract; the system intelligence contract contains service registration logic corresponding to the user service;

the device comprises:

the acquisition module is used for acquiring the use registration data of a service user aiming at the user service; the service interface of the user service is bound with contract execution logic contained in user intelligent contracts deployed on other member blockchains;

and the calling module is used for responding to the use registration data, calling the service registration logic contained in the system intelligent contract, determining target contract execution logic for the service user from the contract execution logic bound with the service interface, and authorizing the service calling authority related to the target contract execution logic to the service user.

In the above embodiments of the present specification, on one hand, since the blockchain service network supports the service of contract execution logic included in a user intelligent contract deployed on each member blockchain, the contract execution logic is called in the form of user service, and the contract execution logic corresponding to the user service can be bound with a service interface corresponding to the user service instead of being bound with the user service directly; therefore, when the user service is opened to the service user, only the service interface corresponding to the user service can be exposed to the service user, and the information related to the contract execution logic bound to the service interface can not be exposed to the service user any more, so that the privacy disclosure caused by directly exposing the information related to the contract execution logic corresponding to the user service to the service user can be avoided.

On the other hand, when the service user requests to obtain the service invocation authority of the user service by invoking the service registration logic contained in the system intelligent contract, the contract execution logic which finally requests the service invocation authority is dynamically determined by the system intelligent contract from the contract execution logic bound with the service interface; therefore, by the method, the flexibility of the user in using and registering the user service can be improved.

Moreover, for a service user, the intelligent contract where the contract execution logic requesting the service authority is located and the member block chain where the intelligent contract is located cannot be sensed in advance; therefore, the service uses a registration mode and has higher privacy and security.

Drawings

Fig. 1 is a network architecture diagram of a block chain service network according to an exemplary embodiment of the present disclosure.

Fig. 2 is a flow chart illustrating a method for building a blockchain service network according to an exemplary embodiment.

Fig. 3 is a flowchart illustrating a process of registering a target blockchain according to the present specification.

FIG. 4 is a diagram illustrating a method for setting up a service interface for a user service and binding contract execution logic for the service interface according to an example embodiment.

Fig. 5 is a flow chart illustrating a method for use registration of a service according to an example embodiment.

FIG. 6 is a flowchart illustrating a method for cross-chain invocation of an intelligent contract according to an exemplary embodiment.

Fig. 7 is a schematic block diagram of an electronic device according to an exemplary embodiment.

Fig. 8 is a block diagram of a usage registration apparatus for a service shown in the present specification according to an example embodiment.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without making any creative effort shall fall within the protection scope of the present specification.

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

In the related art, in order to integrate the service capabilities of the user intelligent contracts deployed on different blockchains and fully utilize the service resources deployed on each blockchain, the blockchains can be generally used as member blockchains to build a blockchain service network, and then contract execution logic included in the intelligent contracts deployed on each member blockchain is serviced through a centralized management platform of the blockchain service network, and is opened to users in the form of user services for the users to call. In practical application, when the contract execution logic included in the intelligent contract deployed on each member blockchain is served, a user service facing a user is registered on a management platform of a blockchain service network, the user service is directly bound with the contract execution logic needing to be served, and then the user service is opened to the user.

The user service which is registered is required to be opened to the user finally; therefore, if the user service is directly bound to the contract execution logic to be serviced, the information related to the contract execution logic bound to the user service is exposed to the user and risks privacy exposure.

In view of this, the present specification proposes a service registration scheme, in an application scenario in which a contract execution logic included in an intelligent contract deployed on a blockchain is serviced, in which the contract execution logic to be serviced is bound to a service interface of a user service open to a user, and when a call right of the user service is requested, the contract call logic requested to the service call right is dynamically determined from the contract execution logic bound to the service interface of the user service.

In implementation, contract execution logic included in a user intelligent contract deployed on at least part of member blockchains in a blockchain service network can still be called in an open mode in the form of user services. The contract execution logic corresponding to the user service may not be directly bound to the user service any more, but may be bound to a service interface corresponding to the user service.

When receiving call data initiated by a service user and directed to a service interface containing the user service, a node device in any target member blockchain in the blockchain service network may determine, in response to the call data, a target contract execution logic for the service user, from contract execution logics included in user intelligent contracts, bound to the service interface and deployed on other member blockchains, and then initiate a cross-chain call for the user intelligent contracts, deployed on the other member blockchains and containing the target contract execution logics, to complete the service call for the user service.

In the above technical solution, on one hand, the blockchain service network supports the service of contract execution logic included in a user intelligent contract deployed on each member blockchain, the contract execution logic is called in an open manner in the form of a user service, and the contract execution logic corresponding to the user service may not be directly bound to the user service but bound to a service interface corresponding to the user service; therefore, when the user service is opened to the service user, only the service interface corresponding to the user service can be exposed to the service user, and the information related to the contract execution logic bound to the service interface can not be exposed to the service user any more, so that the privacy disclosure caused by directly exposing the information related to the contract execution logic corresponding to the user service to the service user can be avoided.

For example, taking the contract execution logic corresponding to the user service as an executable function as an example, if a manner of directly binding the user service and the executable function is adopted, information such as a function name related to the function is necessarily exposed to the user. If the user service and the service interface are bound, the service interfaces and even the information such as the function description related to the functions may need to be exposed to the user, and the essential contents such as the function names of the functions may not need to be exposed to the user.

On the other hand, when the service user requests to obtain the service invocation authority of the user service by invoking the service registration logic contained in the system intelligent contract, the contract execution logic which finally requests the service invocation authority is dynamically determined by the system intelligent contract from the contract execution logic bound with the service interface; therefore, in this way, the flexibility of the user in registering the use of the user service can be improved.

For example, in practical application, the service interface may bind a plurality of contract execution logics with the same service function, so that when a service user performs service use registration for the user service, the system intelligent contract may flexibly specify one contract execution logic from the plurality of contract execution logics bound to the service interface for authority authorization according to specific requirements, and this use registration mode obviously has a characteristic of higher flexibility.

Moreover, for a service user, the intelligent contract where the contract execution logic requesting the service authority of the service user is located and the member block chain where the intelligent contract is located cannot be sensed in advance; therefore, the service uses a registration mode and has higher privacy and security.

For example, taking the contract execution logic corresponding to the user service as an executable function as an example, since the function allocated by the system intelligent contract from the executable functions bound to the service interface of the user service is completely uncertain for the user when the user registers the service usage for the user service, the user cannot know the information in advance. Therefore, the service use registration mode obviously has certain concealment, and the privacy security of the contract execution logics in the service use registration stage can be fully ensured.

Referring to fig. 1, fig. 1 is a network architecture diagram of a block chain service network according to an exemplary embodiment of the present disclosure.

As shown in fig. 1, in the network architecture of the above-mentioned blockchain service network, a blockchain service network composed of a plurality of member blockchains, a target blockchain network to be registered, and a centralized management and control platform for managing the blockchain service network may be included.

The centralized management and control platform may be a service platform for performing centralized management on the blockchain service network. The hardware device bearing the centralized management and control platform may be a server, or a server cluster formed by a plurality of servers, and is not particularly limited in this specification.

The centralized management and control platform is used as a centralized service platform and can manage members of the block chain service network. For example, it may be responsible for registration of member blockchains in a blockchain services network into the network, for exiting the network, and so on.

In addition, the centralized management and control platform can be used for realizing cross-link access among member block chains;

for example, in practical applications, the centralized management and control platform may generally implement a management function for each member blockchain by issuing and deploying a system intelligence contract to each member blockchain. The management of cross-link access among the member block chains is also a common management function of the centralized management and control platform for the member block chains. Therefore, in this case, the centralized management and control platform may also issue and deploy a system intelligent contract for implementing cross-chain data access to each member blockchain, so that each member blockchain network may implement cross-chain data access with other member blockchains based on the deployed system intelligent contract.

Of course, in addition to the management function for each member blockchain being realized by issuing and deploying a system intelligent contract to each member blockchain, the centralized management and control platform may also carry a cross-chain service component, which may be specifically used to realize cross-chain data interaction between each member blockchain. Each member block chain joining the block chain service network can realize cross-chain data access with other member block chains through the cross-chain service component on the centralized control platform.

With continued reference to fig. 1, it should be noted that, in the initial situation, there may be no member blockchain in the blockchain service network, and the target blockchain cannot join the blockchain service network until the target blockchain is registered by the centralized management platform.

The first member block chain, the second member block chain, and the third member block chain shown in fig. 1 refer to member block chains that have joined the block chain service network. The target blockchain network to be registered shown in fig. 1 refers to a blockchain network that is not temporarily added to the blockchain service network, and the target blockchain network may perform registration interaction with the centralized management and control platform to apply for adding as a member blockchain to the target blockchain network.

Referring to fig. 2, fig. 2 is a flowchart illustrating a method for building a blockchain service network according to an exemplary embodiment of the present disclosure, where the method may be applied to the centralized management and control platform shown in fig. 1; the method comprises the following steps:

step 201: receiving a registration request corresponding to a target block chain;

the target blockchain can be registered to become a member blockchain of the blockchain service network by means of registering interaction with a centralized control platform of the blockchain service network and sending a registration request to the centralized control platform.

The registration request may be specifically initiated by a user having a registration authority of the target block chain through a user account registered on the centralized management and control platform.

For example, in practical applications, the user having the registration authority of the target block chain, the user account registered on the centralized management and control platform may specifically include a system administrator account in the centralized management and control platform, an administrator account registered on the centralized management and control platform by an administrator of the target block chain, a user account registered on the centralized management and control platform by a deployer user of a user intelligent contract in the target block chain, and the like. It should be noted that the user account issuing the registration request specifically refers to a centralized account registered in the centralized management and control platform, and is not a blockchain account registered in each member blockchain.

In the registration request, some basic registration information related to the target block chain to be registered may be included. The basic registration information may specifically include access address information of the target block chain, and block chain configuration information related to the target block chain, and the like.

Of course, in practical applications, in the above registration request, besides some basic registration information related to the above target block chain to be registered, other forms of registration information may be included, and are not particularly limited in this specification. The access address information of the target block chain is specifically used for establishing network connection with a centralized management and control platform; in practical application, the access address information may specifically include domain name information or IP address information corresponding to one or more node devices in the target block chain, so that the centralized management and control platform may establish communication connection with the one or more node devices in the target block chain based on the domain name information or the IP address information.

The block chain configuration information may specifically include any form of information that can be used to indicate the basic configuration of the target block chain; for example, the block chain configuration information may specifically include block chain type information corresponding to the target block chain, protocol type information of a block chain protocol used by the target block chain, and algorithm type information of a consensus algorithm used by the target block chain, and so on.

Step 202: responding to the registration request, and performing registration processing on the target block chain so as to take the target block chain as a member block chain to join the block chain service network;

when receiving a registration request corresponding to a target block chain, the centralized management and control platform may respond to the registration request and perform validity check on the registration request; for example, the validity check of the registration request may specifically include checking whether an initiator of the registration request has a corresponding registration right; and whether the data format in the registration request meets preset rules or format requirements, and so on.

After the centralized management and control platform completes the validity check on the registration request, if the registration request passes the validity check, the centralized management and control platform may further perform registration processing on the target block chain based on the data content carried in the registration request, so as to add the target block chain as a member block chain to the block chain service network.

The registration processing performed by the centralized management and control platform on the target blockchain may specifically include creating a blockchain account corresponding to the centralized management and control platform in the target blockchain.

For example, in implementation, a public-private key pair may be applied to the centralized management and control platform in the target blockchain, the private key is held by a management user of the centralized management and control platform, a corresponding account address is generated by calculation based on the public key (for example, the account address may be a hash value calculated by the public key), and then a blockchain account corresponding to the account address is created in the target blockchain.

It should be noted that, in a blockchain adopting an account model, the types of accounts supported by the blockchain generally include an external account and a contract account. An external account is an account directly controlled by the user, also referred to as a user account. And the contract account is created by the user through an external account, the account containing the contract code (i.e. the smart contract). The creation of the blockchain account corresponding to the centralized management and control platform in the target blockchain described above may be specifically an external account. After the corresponding blockchain account is created for the centralized management and control platform in the target blockchain, the centralized management and control platform obtains the legal user identity in the target blockchain, so that the centralized management and control platform can initiate contract invocation for the user intelligent contract deployed in the target blockchain based on the external account.

The registration process performed by the centralized management and control platform on the target blockchain may include other forms of registration process procedures related to the registration process of the target blockchain, besides creating a blockchain account corresponding to the centralized management and control platform in the target blockchain.

For example, in an illustrated embodiment, the registration processing performed on the target blockchain by the centralized management and control platform may specifically further include deploying at least one system intelligence contract in the target blockchain; the at least one system intelligent contract may be a target system intelligent contract for performing cross-chain communication with other member blockchains.

Of course, in addition to the target system intelligence contract for cross-chain communication with other member blockchains, a system intelligence contract for implementing other basic management functions may be included; for example, the at least one system intelligent contract may further include an intelligent contract for performing service management on the target blockchain, a system intelligent contract for performing network administration on the target blockchain network, an intelligent contract for performing service incentive on a user service or a user related to a service solution registered on the centralized management and control platform, and the like, which are not listed in this specification.

Referring to fig. 3, fig. 3 is a flowchart illustrating a process of registering a target blockchain according to the present disclosure, which includes the following steps:

step 301, a registration request corresponding to a target block chain is initiated by a registration direction centralized platform;

after receiving the registration request, the centralized management and control platform may respond to the registration request and start to perform registration processing on the target block chain. In this embodiment, the registration process performed on the target block chain may include the following registration process flow shown in step 302 to step 306.

Step 302, saving the block chain configuration information of the target block chain;

step 303, establishing communication connection with at least part of node devices in the target block chain based on the access address information of the target block chain;

as mentioned above, some block chain configuration information related to the target block chain may be included in the registration request; for example, the block chain configuration information may include access address information of the target block chain, configuration information related to the target block chain, and the like. After receiving the registration request, the centralized management and control platform may acquire the block chain configuration information carried in the registration request, and then perform a subsequent registration processing procedure for the target block chain based on the acquired block chain configuration information.

After receiving the registration request, the centralized management and control platform may store the configuration information of the blockchain related to the target blockchain, which is read from the registration request, as the configuration information of the member blockchain in a local database.

For example, in implementation, the centralized management and control platform may maintain an information base for storing the blockchain configuration information related to each member blockchain in the blockchain service network, and the centralized management and control platform may read the blockchain configuration information related to the target blockchain from the registration request, and store the read blockchain configuration information as the blockchain configuration information of the member blockchain into the information base.

After the centralized management and control platform stores the configuration information of the blockchain related to the target blockchain as the configuration information of the member blockchain in a local database, the centralized management and control platform can further establish communication connection with at least part of node equipment in the target blockchain based on the access address information of the target blockchain read from the registration request.

For example, as described 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 block chain, and the centralized management and control platform may establish a communication connection with one or more node devices in the target block chain based on the domain name information or the IP address information. In implementation, the centralized management and control platform may establish communication connection with all node devices in the target block chain, or may establish communication connection with only some key node devices in the target block chain (for example, all nodes storing a complete block chain account book).

Step 304, obtaining the blockchain data related to the target blockchain from the node device in the target blockchain based on the communication connection.

After establishing a communication connection with at least part of the node devices in the target blockchain, the centralized management and control platform may continue to acquire blockchain data related to the target blockchain from the node devices in the target blockchain based on the communication connection.

The block chain data related to the target block chain acquired from the node device in the target block chain may specifically include any form of data related to the target block chain, and is not particularly limited in this specification;

for example, in an example, the blockchain data related to the target blockchain acquired from the node device in the target blockchain may specifically include a complete blockchain ledger of the target blockchain, authentication root data corresponding to the blockchain ledger of the target blockchain, and public key data of each node device in the target blockchain, and the like.

In the field of blockchain, the authentication root data corresponding to the blockchain account may generally include created block data in the blockchain account, block header data of each block, and the like, and may be data used for authenticating data stored in the blockchain account.

After acquiring the blockchain data related to the target blockchain from the node device in the target blockchain, the centralized management and control platform may store the acquired blockchain data in the database.

For example, as described above, the centralized management and control platform may maintain an information base for storing the blockchain configuration information related to each member blockchain in the blockchain service network, and the centralized management and control platform may read the blockchain configuration information related to the target blockchain from the registration request, and store the read blockchain configuration information as the blockchain configuration information of the member blockchain into the information base. After acquiring the blockchain data related to the target blockchain from the node device in the target blockchain, the centralized management and control platform may also perform associated storage on the acquired blockchain data and the blockchain configuration information related to the target blockchain in the information base.

And 305, creating a blockchain account corresponding to the centralized management and control platform on the target blockchain.

After the centralized control platform acquires the blockchain data related to the target blockchain from the node device in the target blockchain based on the communication connection, the centralized control platform may also continue to create a corresponding blockchain account for the centralized control platform on the target blockchain. The specific process of creating the above blockchain account is not described in detail.

After a corresponding blockchain account is created for the centralized management and control platform on the target blockchain, at this time, the centralized management and control platform has obtained a legal user identity in the target blockchain and has the capability of invoking a user intelligent contract deployed on the target blockchain, and a subsequent centralized management and control platform may initiate a contract invocation for the user intelligent contract deployed on the target blockchain based on the blockchain account.

In the centralized management and control platform, a list of blockchain accounts may be maintained. The blockchain account list may specifically include blockchain accounts corresponding to the centralized management and control platform created on each member blockchain. After a corresponding blockchain account is created for the centralized management and control platform on the target blockchain, the blockchain account may be added to the blockchain account list for maintenance.

It should be noted that the blockchain accounts corresponding to the centralized management and control platform created on each member blockchain may be specifically the same or different. For example, in an example, in order to facilitate account management, the blockchain accounts corresponding to the centralized management and control platform created on each member blockchain may be used as default for the same preset blockchain account. For example, in implementation, each member blockchain may reserve a certain fixed blockchain account in advance, and the certain fixed blockchain account is used as a blockchain account corresponding to the centralized management and control platform.

At step 306, at least one system intelligence contract is deployed in the target blockchain.

After a corresponding blockchain account is created for the centralized management and control platform on the target blockchain, the centralized management and control platform may further continue to deploy at least one system intelligence contract in the target blockchain. The at least one system intelligence contract may specifically include a target system intelligence contract for cross-chain communication with other member blockchains.

The at least one system intelligent contract may include, in addition to a target system intelligent contract for performing cross-chain communication with other member blockchains, an intelligent contract for performing service management on a target blockchain, a system intelligent contract for performing network administration on a target blockchain network, a system intelligent contract for performing service incentive on a user related to a user service registered on a centralized management and control platform, and the like, which are not particularly limited in this specification.

Of course, in practical application, the above-mentioned target system intelligent contract for performing cross-link communication with other member blockchains, the intelligent contract for performing service management on the target blockchain, the system intelligent contract for performing network administration on the target blockchain network, the system intelligent contract for performing service excitation on the user related to the user service registered on the centralized management and control platform, and the like may be specifically integrated into one system intelligent contract.

For example, in practical applications, a cross-chain call logic for performing cross-chain communication with other member blockchains, a service management logic for performing service management on a target blockchain, a network administration logic for performing network administration on a target blockchain network, and a service excitation logic for performing service excitation on a user related to a user service registered on a centralized administration and control platform may be included in the same system intelligent contract.

It should be noted that the system intelligent contract and the user intelligent contract deployed on the target blockchain are two types of completely different intelligent contracts.

The system intelligent contract comprises contract execution logic, which is usually execution logic related to some management functions on a centralized management and control platform.

For example, the contract execution logic included in the system intelligent contract for network administration as described above may be the execution logic related to the function of the centralized management and control platform for network administration on the block chain service network; accordingly, the contract execution logic included in the system intelligent contract for service incentive of the user related to the user service registered on the centralized management and control platform may be the execution logic related to the function of service incentive of the user related to the registered user service by the centralized management and control platform. The user intelligent contract includes contract execution logic, which is usually related to user service logic defined by the user on the member block chain.

By deploying at least one system intelligent contract on the target blockchain, a user on the target blockchain can also complete some operations related to management functions on the centralized management and control platform on the target blockchain by calling the system intelligent contract deployed on the target blockchain.

Step 307, a successful registration message corresponding to the target block chain is returned to the registrar.

After the centralized management and control platform performs the registration processing procedures shown in steps 302 to 306 for the target block chain, the target block chain is used as a member block chain and successfully joins the member block chain to the block chain service network.

In this case, the centralized management and control platform returns a successful registration message corresponding to the target block chain to the registrar, so as to notify the registrar that the target block chain has been used as a member block chain and successfully joined to the block chain service network.

It should be noted that, in the above embodiment, the sequence of each registration processing flow shown in steps 302 to 306 is only illustrative, and is not particularly limited in this specification. It is understood that, in practical applications, the sequence of the registration processing flows shown in steps 302 to 306 in the above embodiments may be flexibly adjusted and interchanged based on actual registration requirements.

In this specification, a plurality of user intelligent contracts may be deployed on each member blockchain in the blockchain service network. The contract execution logic corresponding to the contract code in the user intelligent contracts may generally include a plurality of contract execution logics respectively corresponding to different basic service capabilities.

For example, in practical applications, the contract execution logic included in an intelligent contract may be generally in the form of a function, and one intelligent contract may include a plurality of functions respectively corresponding to different service functions.

The centralized management and control platform can also support the function of serving contract execution logic contained in user intelligent contracts deployed on at least part of member blockchains in the blockchain service network. Correspondingly, the service provider can perform servitization on contract execution logic contained in a user intelligent contract deployed on at least part of the member blockchains through the functions supported by the centralized management and control platform, and then open the contract execution logic to the service user in the form of user service for the service user to call.

When the contract execution logic included in the user intelligent contract on at least part of the member blockchains in the blockchain service network is serviced, the contract execution logic may be serviced specifically for a specific contract execution logic included in a certain user intelligent contract, or may be serviced as a whole by combining a plurality of contract execution logics.

That is, the user service generated by the service may specifically be a service formed by a specific contract execution logic included in a certain user intelligent contract deployed on each member blockchain in the blockchain service network, or may also be a service generated by combining a plurality of contract execution logics included in at least some member blockchains in the blockchain service network.

For example, in an example, it is assumed that a user deploys a user intelligent contract on a member block chain, where the user intelligent contract includes multiple contract execution logics, in this case, the user may select to serve a specific contract execution logic included in the user intelligent contract, register a user service bound with the contract execution logic on the centralized management and control platform, and open the user service to other users for invocation by other users.

In another example, assuming that a user deploys a plurality of user intelligent contracts on each member blockchain, or the user has access rights of a plurality of user intelligent contracts deployed on each member blockchain by other users, in this case, the user may select to combine a plurality of contract execution logics included in the plurality of user intelligent contracts into a user service, register a user service logically bound with the plurality of contract execution logics on the centralized management and control platform, and open the user service to other users for being called by other users.

When the plurality of contract execution logics are combined and then serviced, the contract execution logics included in the user intelligent contracts distributed on a plurality of different member block chains may be combined to generate one user service and then serviced, or the contract execution logics included in a plurality of user intelligent contracts in the same member block chain may be serviced; alternatively, a plurality of contract execution logics included in the same user intelligent contract in the same member block chain are combined to generate one service and then the service is performed, which is not particularly limited in this specification.

When a plurality of contract execution logics are combined, the plurality of contract execution logics may be combined in a certain logical order. The above logic sequence generally depends on the specific service requirement of the service user, and in practical applications, the logic sequence can be flexibly determined based on the actual service requirement.

In this specification, when the contract execution logic is serviced, the user service may still be registered on the centralized management and control platform, and the registered user service may still be bound to the contract execution logic that needs to be serviced.

That is, the service provider may specifically initiate service registration to the centralized management and control platform, register a corresponding user service for the contract execution logic that needs to be serviced, and then bind the user service with the contract execution logic, so as to complete the servicing of the contract execution logic.

It should be noted that, the specific process of initiating the service registration to the centralized management and control platform by the service provider is not detailed in this specification, and those skilled in the art may refer to the description in the related art.

When the registered user service is bound with the contract execution logic, a mode of directly binding the user service with the contract execution logic is not adopted, but a service interface is set for the registered user service on a centralized management and control platform, and the service interface of the user service is bound with the contract execution logic. It should be noted that, the service interface may specifically be a service identifier capable of uniquely identifying the user service. The number of service interfaces provided for the user service may be one or more, and is not particularly limited in this specification.

In an embodiment shown, for example, the user service is a service generated by combining multiple contract execution logics, in this case, when a service interface is set for the user service, the user service may be specifically split into multiple sub-services respectively corresponding to different service functions, a corresponding service interface is set for each sub-service respectively, and then a corresponding contract execution logic is bound for each service interface.

In order to improve the service stability of each sub-service, when binding contract execution logic for the service interface of each sub-service, a plurality of contract execution logic having the same service function may be specifically bound for at least some of the service interfaces. When the service user invokes the sub-service, the service user may be specifically allocated a target contract execution logic from a plurality of contract execution logics bound to the sub-service based on a certain scheduling policy, and provide a service to the service user.

For example, referring to fig. 4, fig. 4 is a schematic diagram illustrating a method for setting a service interface for a user service and binding contract execution logic for the service interface.

As shown in FIG. 4, what FIG. 4 illustrates needs to be serviced are contract instances 1-7 that are affiliated with user intelligent contracts deployed on member blockchains A, B, and C, respectively. The contract instance refers to contract execution logic contained in the user intelligent contract; for example, it may be an executable function contained in a user smart contract.

The service a shown in fig. 4 may be split into a sub-service 1 and a sub-service 2 according to the service function. The service interface set for the sub-service 1 is a1, and the service interface a1 binds two contract instances 1 and 2 having the same service function. The service interface set for the sub-service 2 is a2, and only one contract instance 3 is bound to the service interface a 2.

The service B shown in fig. 4 may be split into a sub-service 3, a sub-service 4, and a sub-service 5 according to the service function. The service interface set for the sub-service 3 is b1, and only one contract instance 1 is bound to the service interface b 1. The service interface set for the sub-service 4 is b2, and the service interface b2 binds two contract instances 4 and 5 having the same service function. The service interface set for the sub-service 5 is b3, and the service interface b3 binds two contract instances 3 and 6 having the same service function.

The service C shown in fig. 4 may not split the sub-service, and the service interface set for the service C is C1, and only one contract instance 7 is bound to the service interface C1.

As can be seen from fig. 4, in practical applications, for a user service generated by combining a plurality of contract execution logics, specifically, a plurality of service interfaces may be set for the user service, and a plurality of contract execution logics having the same function may be bound for at least part of the service interfaces.

In this specification, after a service provider registers a user service on the centralized management and control platform and binds a contract execution logic that needs to be serviced for the user service, the centralized management and control platform may deploy the target user service as a standardized service to be opened to a service user for invocation.

It should be noted that, when the centralized management and control platform deploys the user service after the registration is completed, a distributed deployment mode may be specifically adopted.

The distributed deployment specifically means that the user service is deployed on each member block chain in a distributed manner in the form of a system intelligent contract so as to be called by a service user.

On one hand, since the contract invoking logic constituting the user service may include contract execution logic included in a plurality of user intelligent contracts distributed on a plurality of member blockchains, when invoking the user service, a service user may also need to invoke the plurality of user intelligent contracts distributed on the plurality of member blockchains across chains; therefore, when the centralized management and control platform deploys the user service, a corresponding cross-chain calling logic may be specifically developed for the user service, and then the cross-chain calling logic is deployed on each member block chain as a contract execution logic in a system intelligent contract.

For example, as mentioned above, the system intelligence contract includes contract execution logic, which is typically execution logic associated with some management functions on a centralized management platform. Therefore, in this way, the cross-chain call logic developed for the user service is equivalent to that which is also deployed on each member block chain in the form of a system intelligence contract as part of some management function related execution logic on the centralized management and control platform.

In addition, when the user service is deployed, the binding relationship between the service interface of the user service and the contract execution logic can be used as the service configuration information of the user service, and also stored into the system intelligent contract, and maintained by the system intelligent contract.

On the other hand, in order to conveniently open the user service registered by the service provider to the service user for service call, when the centralized management and control platform deploys the user service, the centralized management and control platform can also develop corresponding service registration logic for the user service; the service registration logic is then deployed on each member blockchain as contract execution logic in a system intelligence contract. In this way, the usage registration logic which is equivalent to be developed for the user service is also taken as a part of some management function related execution logic on the centralized management and control platform and is deployed on each member block chain in the form of a system intelligent contract.

Referring to fig. 5, fig. 5 is a flowchart illustrating a service usage registration method applied to a node device in any one of the target member blockchains shown in fig. 1 according to an exemplary embodiment of the present specification; wherein, each member block chain in the block chain network is respectively deployed with the system intelligent contract; the system intelligent contract comprises service registration logic corresponding to the user service; the method comprises the following steps:

step 502: acquiring the use registration data of a service user for the user service; the service interface of the user service is bound with contract execution logic contained in user intelligent contracts deployed on other member blockchains;

after the user service registered by the service provider on the centralized management and control platform is distributed and deployed in each member blockchain in the blockchain service network in the form of a system intelligent contract, the service user can submit the use registration data for the user service through the node device in the target member blockchain accessed by the service user to initiate contract calling for the system intelligent contract so as to acquire the service calling authority of the user service.

It should be noted that, the service user may specifically be a user who registers a user account on the target member blockchain, or may also be a user intelligent contract deployed on the target member blockchain, which is not particularly limited in this specification.

In an embodiment shown, if the service user is a user who has registered a user account on the target member blockchain, the invoking data may be specifically a packaged intelligent contract invoking transaction for the system intelligent contract by the user through a user client accessing the target member blockchain.

The user client may submit the packaged intelligent contract call transaction as the call data to the node device in the target member block chain, and initiate a contract call for the cross-chain call logic included in the system intelligent contract, so as to trigger the node device in the target member block chain to execute the cross-chain call logic included in the system intelligent contract in a distributed manner, so as to obtain the service call permission of the user service.

Certainly, in practical applications, the user may also submit the invocation data of the intelligent contract for the system intelligent contract to the Baas platform corresponding to the target member blockchain through the user client, and then the Baas platform packages the invocation data into a contract invocation transaction for the system intelligent contract, and submits the contract invocation transaction to the node device in the target member blockchain.

In another illustrated embodiment, if the service consumer is a customer intelligence contract deployed on the target member blockchain, the customer intelligence contract may contain contract execution logic that references a service interface of the customer service.

The reference to the service interface of the user service in the contract execution logic generally refers to that the service interface of the user service is referenced in the contract code corresponding to the contract execution logic, so that when the contract code is called by a user, the contract code can further initiate a service call for the user service corresponding to the service interface based on the referenced service interface in the execution process. When a user initiates a contract invocation of the contract execution logic contained in the user intelligent contract, the user intelligent contract can further initiate a service invocation of a user service corresponding to the service interface referenced by the contract execution logic based on the service interface referenced by the contract execution logic.

The user service is distributed deployed in the form of a system intelligent contract, so that the service invocation process initiated by the user intelligent contract and aiming at the referenced user service is actually an inter-invocation process between the user intelligent contract and the system intelligent contract.

The mutual calling between intelligent contracts usually adopts a message calling mechanism. Therefore, in practical applications, the invoking data may be specifically an invoking message generated by the user intelligent contract for the system intelligent contract based on a message invoking mechanism between intelligent contracts when the user invokes contract execution logic included in the user intelligent contract and referring to the user service.

In this case, when a user initiates a contract call to the contract execution logic included in the user intelligent contract, the user intelligent contract may specifically generate a call message to the system intelligent contract based on a message call mechanism between intelligent contracts.

Then, the calling message is used as calling data for the user service, submitted to the system intelligent contract, and launched to the contract calling of the system intelligent contract, so as to trigger the node device in the block chain to execute the use registration logic included in the system intelligent contract in a distributed manner, and obtain the service calling authority of the user service.

The process of mutual invocation between intelligent contracts by using a message invocation mechanism is not described in detail in this specification, and those skilled in the art may refer to the description in the related art when implementing the technical solution described in this specification.

The call message may be any type of data suitable for passing between intelligent contracts, and is not particularly limited in this specification.

For example, in one example, the invoking message may be specifically defined based on a development language adopted by the intelligent contract, and is an executable instruction suitable for being transmitted between the intelligent contracts. For example, taking the example that the contract code in the intelligent contract adopts the high-level development language property, the call message may specifically be a call instruction for the system intelligent contract.

Step 504: in response to the use registration data, invoking the service registration logic contained in the system intelligent contract, determining target contract execution logic for the service user from contract execution logic bound with the service interface, and authorizing service invocation authority related to the target contract execution logic to the service user;

in this specification, the usage registration data may specifically carry a service interface corresponding to the user service.

It should be noted that, if the user service is a service generated by combining a plurality of contract execution logics, the user service may include a plurality of service interfaces, and each service interface corresponds to a sub-service in the user service.

In this case, the service user may select to register the use of one or more sub-services in the user service. Accordingly, the use registration data may carry one or more service interfaces selected by the service user from the plurality of service interfaces and required to be used and registered.

After obtaining the usage registration data submitted by the service user, the node device in the target member block chain may further invoke the service registration logic included in the system intelligent contract to obtain a service interface carried in the usage registration data in response to the usage registration data, and determine a target contract execution logic for the service user from a contract execution logic bound to the service interface.

In an illustrated embodiment, since the user service may include a plurality of service interfaces, and each service interface may further bind to a plurality of contract execution logics, after the node device in the target member block chain invokes the use registration logic included in the system intelligent contract and acquires the service interface carried in the invocation data, it may first determine whether the service interface binds to a plurality of contract execution logics;

for example, in an example, after a service provider registers a user service through a centralized management and control platform, the centralized management and control platform may also maintain a binding relationship between a service interface allocated to the user service and contract execution logic that needs to be serviced, in the system intelligent contract, so that the system intelligent contract may determine whether a plurality of contract execution logic are bound by using the service interface carried in the registration data by querying the maintained binding relationship.

If it is determined that the service interface is bound with a plurality of contract execution logics, the system intelligent contract may dynamically allocate a target contract execution logic for providing services to the service user from the plurality of contract execution logics bound with the service interface based on a preset scheduling policy.

In this way, when a service user requests to obtain the service invocation authority of the user service by invoking the service registration logic contained in the system intelligent contract, the contract execution logic which finally requests the service invocation authority is dynamically determined by the system intelligent contract from the contract execution logic bound with the service interface; therefore, by the method, the flexibility of the user in using and registering the user service can be improved.

It should be noted that, the preset scheduling policy may specifically be any policy for dynamically allocating the contract execution logic for the service user among a plurality of contract execution logics bound from the service interface, and is not particularly limited in this specification. In practical application, a specific scheduling policy can be flexibly set based on specific scheduling requirements.

In one embodiment, the scheduling policy includes any one or a combination of the following:

scheduling strategy one:

and randomly distributing the scheduling policy of the contract execution logic for the service user from a plurality of contract execution logics bound with the service interface.

Based on such a policy, the contract execution logic may be randomly allocated to the service user from a plurality of contract execution logics bound to the service interface, so as to provide the service to the service user.

By the method, a service user can not sense contract calling logic for providing services for the service user in advance, so that the privacy when the user service is called can be ensured to the maximum extent.

And (2) scheduling policy two:

and allocating a pre-specified contract execution logic among the plurality of contract execution logics bound with the service interface to the scheduling policy of the service user.

Based on the strategy, the service provider can flexibly specify the contract execution logic for providing the service for the service user from a plurality of contract execution logics bound with the service interface, thereby improving the service flexibility of the user service.

For example, in practical applications, for some specific service users, a fixed contract execution logic may be specified from the plurality of contract execution logics to provide services for the service users.

And (3) scheduling strategy three:

and distributing the contract execution logic of which the service index accords with a preset condition in a plurality of contract execution logics bound with the service interface to the scheduling strategy of the service user.

Based on the strategy, the centralized management and control platform can count the service indexes of each contract execution logic bound with the service interface in real time, store the service indexes into the system intelligent contract, and maintain the system intelligent contract, so that the system intelligent contract can screen out the contract execution logic with the service indexes meeting preset conditions based on the maintained service indexes and distribute the contract execution logic to service users, and therefore fine management of each contract execution logic bound with the service interface can be achieved.

For example, based on the service index of each contract execution logic bound with the service interface, a contract execution logic most suitable for the service user is screened for the service user, and the service is provided for the service user.

The service index may specifically include any type of index that can represent a use status of the contract execution logic bound to the service interface, and is not particularly limited in this specification. Accordingly, the preset condition generally depends on the specific type of the service indicator, and in practical applications, the preset condition can be flexibly set based on specific service requirements.

For example, in one example, the service indicator may specifically include the number of service users serviced by the contract execution logic. Accordingly, the preset condition may include the minimum contract execution logic among the plurality of contract execution logics bound to the service interface.

In this case, when dynamically allocating the contract execution logic for providing the service to the service user from the plurality of contract execution logics bound to the service interface based on the scheduling policy three described above, the system intelligent contract may specifically count the number of service users provided with the service by the plurality of contract execution logics, and allocate the contract execution logic with the smallest number to the service user as the target contract execution logic.

Since the number of service users serviced by each contract execution logic can be generally understood as the service load of each contract execution logic in servicing service users, in this way, load balancing of the plurality of contract execution logics can be achieved.

Of course, the service indexes may include, in addition to the number of service users provided with services by the contract execution logic, in practical applications, service indexes such as the total duration of the contract execution logic providing services to each service provider, the number of times of successful call, the success rate of call, and the number of times of failed call when providing services, which are not listed in this specification.

Besides, the preset condition may include a condition of the contract execution logic with the smallest number among the plurality of contract execution logics bound to the service interface, and in practical applications, the preset condition may also include other forms of conditions, which are not listed in this specification; for example, in one example, the preset condition may further include contract execution logic that the number is lower than a threshold value.

In one embodiment, after allocating the contract execution logic for providing the service to the service user, the service user may further generate service registration information for the user service, and store the service registration information in the system intelligent contract, so that the stored service registration information is maintained by the system intelligent contract.

The service registration information may specifically include information related to a target contract execution logic, which is distributed to the service user and provides services for the service user, from a plurality of contract execution logics bound to the service interface by a system intelligent contract based on the scheduling policy; for example, the identification information (such as function name, etc.) corresponding to the target contract execution logic may be used.

In this specification, when the service registration logic included in the system intelligent contract is invoked, and after a target contract execution logic that provides a service to the service user is determined for the service user from the contract execution logic bound to the service interface, the invocation authority associated with the target contract execution logic may be further authorized to the service user.

In an illustrated embodiment, specifically, the invocation permission of the user service and the invocation permission of the contract execution logic bound to the service interface of the user service may be authorized as two independent permissions, respectively.

In this case, when the invocation authority related to the target contract execution logic is authorized to the service user, the service invocation authority of the user service may be specifically authorized to the target user intelligent contract; and authorizing the service calling authority of the target contract execution logic to the service user.

In this way, fine management of the user services can be achieved. For example, after the service invocation authority of the user service is authorized to the service user, the service user can execute logic for a target contract distributed to the service user from a plurality of contract execution logics bound with the user service, and then the service user can authorize the logic once, so that the mutual influence between the service invocation authority of the user service and the invocation authority of the contract execution logic bound with the user service is fundamentally avoided.

In an illustrated embodiment, if the service user is a user intelligent contract deployed on the target member blockchain, when the service invocation authority of the target contract execution logic is authorized to the service user, a bidirectional authority authorization manner may be specifically used, and in addition to authorizing the service invocation authority of the target contract execution logic to the user intelligent contract, the invocation authority of the user intelligent contract may also be correspondingly authorized to the target contract execution logic.

In this way, on the one hand, due to the contract execution logic contained in the user intelligent contract, it is also possible to bind with a service interface of another user service; therefore, by adopting the bidirectional authority authorization mode, the related calling authority of the other user service can be synchronously authorized to the target contract execution logic, so that repeated authorization can be avoided through the authorization mode described above when the target contract execution logic has the calling requirement of the other user service.

On the other hand, due to the adoption of the bidirectional authority authorization mode, the target contract execution logic can synchronously acquire the calling authority of the contract execution logic contained in the user intelligent contract; therefore, for the target contract execution logic, the user intelligent contract serving as the service calling party can be called back, the service calling result of the user intelligent contract serving as the service using party for the user service can be timely returned to the user intelligent contract serving as the service calling party, and a mode of asynchronously returning the service calling result is not required any more, so that the service calling efficiency when the service is called for the user service can be improved.

Referring to FIG. 6, FIG. 6 is a flowchart illustrating a method for cross-chain invocation of an intelligent contract as applied to a node device in any of the target member blockchains illustrated in FIG. 1 in accordance with an exemplary embodiment of the present specification; wherein, each member block chain in the block chain network is respectively deployed with the system intelligent contract; the system intelligent contract comprises a cross-chain calling logic corresponding to the user service; the method comprises the following steps:

step 602: acquiring call data of a service user for the user service; the service interface of the user service is bound with contract execution logic contained in user intelligent contracts deployed on other member blockchains;

when a service provider registers user services on the centralized management and control platform, the user services are distributed and deployed in each member blockchain in the blockchain service network in the form of a system intelligent contract, and the service user completes the use registration of the user services, the service user can submit call data for the user services through a node device in a target member blockchain accessed by the service user, so as to initiate contract call for the system intelligent contract, and complete service call of the user services.

In an embodiment shown, if the service user is a user who has registered a user account on the target member blockchain, the invoking data may be specifically an intelligent contract invoking transaction for the system intelligent contract that is packaged by a user client accessing the target member blockchain. The user client may submit the packaged intelligent contract call transaction to the node device in the target member blockchain, and initiate a contract call for the system intelligent contract, so as to trigger the node device in the target member blockchain to execute the cross-chain call logic included in the system intelligent contract in a distributed manner, so as to complete service call for the user service.

In practical application, the user may also submit the invocation data of the intelligent contract for the system intelligent contract to the bas platform corresponding to the target member blockchain through the user client, and then the bas platform packages the invocation data into a contract invocation transaction for the system intelligent contract, and submits the contract invocation transaction to the node device in the target member blockchain.

In another illustrated embodiment, if the service consumer is a customer intelligence contract deployed on the target member blockchain, the customer intelligence contract may include a contract execution logic that references a service interface of the customer service. When a user initiates a contract invocation aiming at the contract execution logic contained in the user intelligent contract, the user intelligent contract can specifically generate an invocation message aiming at the system intelligent contract based on a message invocation mechanism between intelligent contracts. Then, the calling message is used as calling data for the user service, submitted to the system intelligent contract, and launched to the contract calling of the system intelligent contract, so as to trigger the node device in the block chain to execute the cross-chain calling logic included in the system intelligent contract in a distributed manner, thereby completing the service calling for the user service.

For example, in one example, the call message may be specifically defined based on a development language adopted by the intelligent contract, and is an executable instruction suitable for being passed between the intelligent contracts. For example, taking the example that the contract code in the intelligent contract adopts the high-level development language entity, the call message may specifically be a call instruction for the system intelligent contract.

Step 604, responding to the calling data, calling the cross-chain calling logic contained in the system intelligent 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 of the user intelligent contract containing the target contract execution logic and deployed on the other member blockchain.

In this specification, the call data may specifically carry a service interface corresponding to the user service.

In this case, the service user may choose to make a service call to one or more sub-services in the user service. Accordingly, the call data may also carry one or more service interfaces selected by the service user from the plurality of service interfaces and required to be called.

After obtaining the call data submitted by the service user, the node device in the target member block chain may respond to the call data, further call the cross-chain call logic included in the system intelligent contract, obtain a service interface carried in the call data, and determine a target contract execution logic for the service user from a contract execution logic bound to the service interface.

In an illustrated embodiment, since the user service may include a plurality of service interfaces, and each service interface may further bind to a plurality of contract execution logics, after the node device in the target member block chain invokes the cross-chain invocation logic included in the system intelligent contract, and acquires the service interface carried in the invocation data, it may first determine whether the service interface binds to a plurality of contract execution logics;

for example, in an example, after a service provider registers a user service through a centralized management and control platform, the centralized management and control platform may also maintain a binding relationship between a service interface allocated to the user service and a contract execution logic that needs to be serviced, in the system intelligent contract, so that the system intelligent contract may determine whether a plurality of contract execution logics are bound to the service interface carried in the invocation data by querying the maintained binding relationship.

In this way, when the service user invokes the contract execution logic bound with the service interface of the user service through the system intelligent contract in a cross-chain manner, the = contract execution logic that is finally invoked is dynamically determined by the system intelligent contract from the contract execution logic bound with the service interface; therefore, in this way, the flexibility of the user service when being invoked can be improved.

Moreover, for a service user, the intelligent contract where the called contract execution logic is located and the member block chain where the intelligent contract is located cannot be sensed in advance; therefore, the mode of calling contracts across chains has higher privacy and security.

It should be noted that, the preset scheduling policy may specifically be any policy for dynamically allocating the contract execution logic for the service user among a plurality of contract execution logics bound from the service interface, and is not particularly limited in this specification. In practical application, a specific scheduling policy can be flexibly set based on specific scheduling requirements. For example, in this embodiment, the scheduling policy may still include any one or a combination of multiple scheduling policies, i.e., the scheduling policy one, the scheduling policy two, and the scheduling policy three, which are described in the embodiment shown in fig. 5, and details are not repeated in this embodiment.

In an embodiment shown, as described above, since the system intelligent contract may previously maintain service registration information of the service user for the user service, and the service registration information may include information related to a target contract execution logic, which is allocated to the service user from a plurality of contract execution logics bound to a service interface corresponding to the user service and provides a service to the service user, of the system intelligent contract during a stage of registering the service user for using the user service; therefore, in this case, when determining the target contract execution logic for the service user from the contract execution logic bound to the service interface, the system may specifically obtain information related to the target contract execution logic included in the service registration information directly without performing real-time distribution, and then directly distribute the target contract execution logic to the service user.

In this way, when the service user invokes the user service, the target contract execution logic allocated to the service user in the use registration phase by the service user can be preferentially allocated to the service user, so that the repeated allocation of contract execution logic to the service user when the service user invokes the user service can be avoided.

In this specification, when the cross-chain call logic included in the system intelligent contract is called, and after a target contract execution logic that provides a service to the service user is determined for the service user from the contract execution logic bound to the service interface, a cross-chain call to a user intelligent contract that includes the target contract execution logic and is deployed on another member blockchain may be further initiated.

In an embodiment shown, as mentioned above, since the service user may authorize the service user as two independent authorities respectively at the stage of registering service usage for the user service, the invocation authority of the user service and the invocation authority of the contract execution logic bound to the service interface of the user service, in this case, before the cross-chain invocation logic included in the system intelligent contract is invoked to determine the target contract execution logic for the service user, the authority verification logic included in the system intelligent contract may be invoked to verify whether the service user has the invocation authority of the user service; if yes, the cross-chain calling logic contained in the system intelligent contract can be further called, and target contract execution logic is determined for the service user from the contract execution logic bound with the service interface.

In another illustrated embodiment, after determining a target contract execution logic for the service user from the contract execution logic bound with the service interface, after initiating a cross-chain call for a user intelligent contract deployed on other member blockchains and including the contract execution logic, specifically, the authority verification logic included in the system intelligent contract may be called first to verify whether the service user has the call authority of the target contract execution logic; if so, a cross-chain call is re-initiated to the user intelligent contract deployed on the other member blockchain that contains the target contract execution logic.

The specific manner of the system intelligent contract initiating the cross-chain call of the user intelligent contract which is deployed on the other member blockchain and contains the target contract execution logic can still be completed by adopting a message call mechanism between intelligent contracts, and details are not described in this specification.

The present specification also provides embodiments of an apparatus, an electronic device, and a storage medium, corresponding to embodiments of the foregoing method.

Fig. 7 is a schematic block diagram of an electronic device according to an exemplary embodiment. Referring to fig. 7, at the hardware level, the apparatus includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a nonvolatile storage 810, but may include hardware required for other services. One or more embodiments of the present description may be implemented in software, for example, by the processor 702 reading a corresponding computer program from the non-volatile storage 710 into the memory 708 and then running. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Fig. 8 is a block diagram of a service usage registration apparatus shown in this specification according to an exemplary embodiment, which may be applied to the electronic device shown in fig. 7 to implement the technical solution of this specification. The device can be applied to the node equipment in any target member block chain in a block chain service network consisting of a plurality of member block chains; contract execution logic contained in user intelligent contracts deployed on at least part of member block chains in the block chain service network is called in an open mode in a user service mode; each member block chain in the block chain network is respectively provided with a system intelligent contract; the system intelligent contract comprises service registration logic corresponding to the user service; the apparatus 80 comprises:

an obtaining module 801, which obtains the use registration data of the service user for the user service; the service interface of the user service is bound with contract execution logic contained in user intelligent contracts deployed on other member blockchains;

the invoking module 802, in response to the usage registration data, invokes the service registration logic included in the system intelligent contract, determines a target contract execution logic for the service user from the contract execution logic bound to the service interface, and authorizes the service invocation authority associated with the target contract execution logic to the service user.

The details of the modules of the apparatus 80 are described in detail in the method flow described above, and therefore will not be described herein again.

Correspondingly, the specification also provides an electronic device, which comprises a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement the steps of all of the method flows described previously.

Accordingly, the present specification also provides a computer readable storage medium having executable instructions stored thereon; wherein the instructions, when executed by a processor, implement steps of all of the method flows previously described.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

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

The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, may implement the information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium, that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising one of 8230; \8230;" 8230; "does not exclude the presence of additional like elements in a process, method, article, or apparatus that comprises that element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at" \8230; "or" when 8230; \8230; "or" in response to a determination ", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A service use registration method is applied to a node device in any target member blockchain in a blockchain service network formed by a plurality of member blockchains; contract execution logic contained in user intelligent contracts deployed on at least part of member block chains in the block chain service network is called in an open mode in a user service mode; each member block chain in the block chain network is respectively provided with a system intelligent contract; the system intelligence contract contains service registration logic corresponding to the user service;

the method comprises the following steps:

acquiring the use registration data of a service user for the user service; the service interface of the user service is bound with contract execution logic contained in user intelligent contracts deployed on other member blockchains;

2. The method of claim 1, the customer services comprising services generated by executing logical combinations of contracts comprised by customer intelligence contracts deployed on at least a portion of member blockchains in the blockchain services network; the user service comprises a plurality of service interfaces; wherein, different service interfaces respectively correspond to different service functions; at least some of the plurality of service interfaces bind a plurality of contract execution logic having the same service functionality.

3. The method of claim 2, determining target contract execution logic for the service consumer from contract execution logic bound to the service interface, comprising:

determining whether the service interface has bound thereto a plurality of contract execution logics; if yes, further based on a preset scheduling policy, distributing target contract execution logic for providing services for the service user from a plurality of contract execution logics bound with the service interface.

4. The method of claim 3, further comprising:

after contract execution logic for providing services to the service user is allocated to the service user, generating service registration information of the service user for the user service, and storing the service registration information in the system intelligence contract so as to maintain the stored service registration information by the system intelligence contract; the service registration information comprises target contract execution logic which is distributed for the service user and provides services for the service user from a plurality of contract execution logic bound with the service interface based on the preset scheduling policy.

5. The method of claim 3, the scheduling policy comprising any one or a combination of more of the following:

randomly allocating a scheduling policy of contract execution logic for the service user from a plurality of contract execution logic bound with the service interface;

allocating a pre-specified contract execution logic to the scheduling policy of the service user in a plurality of contract execution logics bound with the service interface;

and distributing the contract execution logic of which the service index meets a preset condition in the plurality of contract execution logics bound with the service interface to the scheduling strategy of the service user.

6. The method of claim 5, the service indicator comprising a number of service consumers serviced by the contract execution logic; the preset condition comprises the minimum contract execution logic in a plurality of contract execution logics bound with the service interface.

7. The method as set forth in claim 2, wherein,

the authorizing the service invocation authority related to the target contract execution logic to the service user comprises:

authorizing the service calling authority of the user service to the service user; and the number of the first and second groups,

and authorizing the service calling authority of the target contract execution logic to the service user.

8. The method of claim 7, the service consumer comprising a user intelligence contract deployed on the target member blockchain;

authorizing a service invocation authority of the target contract execution logic to the service user, including:

and authorizing the service invoking authority of the target contract execution logic to the user intelligent contract, and authorizing the invoking authority of the user intelligent contract to the target contract execution logic.

9. The method of claim 8, the user intelligence contract comprising contract execution logic that references a service interface of the user service.

10. A cross-chain calling device of an intelligent contract is applied to a node device in any target member blockchain in a blockchain service network formed by a plurality of member blockchains; contract execution logic contained in user intelligent contracts deployed on at least part of member block chains in the block chain service network is called in an open mode in a user service mode; each member block chain in the block chain network is respectively provided with a system intelligent contract; the system intelligent contract comprises service registration logic corresponding to the user service;

the device comprises:

11. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-9 by executing the executable instructions.

12. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 9.