WO2024066018A1 - 一种智能合约的跨链调用方法及装置 - Google Patents

一种智能合约的跨链调用方法及装置 Download PDF

Info

Publication number
WO2024066018A1
WO2024066018A1 PCT/CN2022/135448 CN2022135448W WO2024066018A1 WO 2024066018 A1 WO2024066018 A1 WO 2024066018A1 CN 2022135448 W CN2022135448 W CN 2022135448W WO 2024066018 A1 WO2024066018 A1 WO 2024066018A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
user
contract
blockchain
contract execution
Prior art date
Application number
PCT/CN2022/135448
Other languages
English (en)
French (fr)
Inventor
刘勤
黄胜
Original Assignee
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 蚂蚁区块链科技(上海)有限公司 filed Critical 蚂蚁区块链科技(上海)有限公司
Publication of WO2024066018A1 publication Critical patent/WO2024066018A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/141Setup of application sessions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • H04L67/306User profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols

Definitions

  • Multiple embodiments of this specification relate to the field of blockchain technology, and more particularly to a cross-chain calling method and device for a smart contract.
  • a method for registering the use of a service is proposed, the method being applied to a node device in any target member blockchain in a blockchain service network composed of several member blockchains; wherein the contract execution logic contained in the user smart contract deployed on at least some of the member blockchains in the blockchain service network is open for call in the form of user services; system smart contracts are respectively deployed on each member blockchain in the blockchain network; the system smart contract contains service registration logic corresponding to the user service;
  • the method comprises:
  • the service registration logic contained in the system smart contract is called, the target contract execution logic is determined for the service user from the contract execution logic bound to the service interface, and the service call authority related to the target contract execution logic is authorized to the service user.
  • a cross-chain calling device for a smart contract is also provided, and the device is applied to a node device in any target member blockchain in a blockchain service network composed of several member blockchains; wherein the contract execution logic contained in the user smart contract deployed on at least some of the member blockchains in the blockchain service network is open for calling in the form of user services; system smart contracts are respectively deployed on each member blockchain in the blockchain network; the system smart contract contains service registration logic corresponding to the user service;
  • the device comprises:
  • An acquisition module is used to acquire the registration data of the user service used by the service user; wherein the service interface of the user service is bound to the contract execution logic contained in the user smart contract deployed on other member blockchains;
  • the calling module in response to the usage registration data, calls the service registration logic contained in the system smart contract, determines the target contract execution logic for the service user from the contract execution logic bound to the service interface, and authorizes the service calling authority related to the target contract execution logic to the service user.
  • the blockchain service network since the blockchain service network supports the service-oriented contract execution logic contained in the user smart contract deployed on each member blockchain, it is opened for call in the form of user service, and the contract execution logic corresponding to the user service may no longer be directly bound to the user service, but may be bound to the service interface corresponding to the user service; therefore, when the user service is opened to the service user, only the service interface corresponding to the user service may be exposed to the service user, and the information related to the contract execution logic bound to the service interface may no longer be exposed to the service user, thereby avoiding the privacy leakage caused by directly exposing the information related to the contract execution logic corresponding to the user service to the service user.
  • the contract execution logic that ultimately requests the service call permission is dynamically determined by the system smart contract from the contract execution logic bound to the service interface; therefore, in this way, the user's flexibility in registering for the use of the above-mentioned user services can be improved.
  • FIG1 is a network architecture diagram of a blockchain service network shown in an exemplary embodiment of this specification.
  • FIG2 is a flow chart of a method for establishing a blockchain service network according to an exemplary embodiment of the present specification.
  • FIG3 is a flowchart of a registration process for a target blockchain as shown in this specification.
  • FIG4 is a schematic diagram of setting a service interface for a user service and binding a contract execution logic to the service interface according to an exemplary embodiment of the present specification.
  • FIG. 5 is a flow chart of a method for registering use of a service according to an exemplary embodiment of this specification.
  • FIG6 is a flowchart of a cross-chain calling method of a smart contract according to an exemplary embodiment of this specification.
  • FIG. 7 is a schematic structural diagram of an electronic device provided by an exemplary embodiment.
  • FIG. 8 is a block diagram of a device for registering use of a service according to an exemplary embodiment of this specification.
  • the steps of the corresponding method are not necessarily performed in the order shown and described in this specification.
  • the method may include more or fewer steps than those described in this specification.
  • a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may be combined into a single step for description in other embodiments.
  • these blockchains can usually be organized as member blockchains into a blockchain service network, and then the contract execution logic contained in the smart contracts deployed on each member blockchain is serviced through the centralized management platform of the blockchain service network, and is opened to users in the form of user services for users to call.
  • the contract execution logic contained in the smart contracts deployed on each member blockchain when the contract execution logic contained in the smart contracts deployed on each member blockchain is serviced, it can be specifically registered as a user-oriented user service on the management platform of the blockchain service network, and the user service is directly bound to the contract execution logic that needs to be serviced, and then the user service is opened to users.
  • this specification proposes an application scenario in which the contract execution logic contained in the smart contract deployed on the blockchain is serviced, and the contract execution logic that needs to be serviced is bound to the service interface of the user service open to users.
  • the service registration scheme of the contract calling logic for which the service calling permission is requested is dynamically determined from the contract execution logic bound to the service interface of the user service.
  • the contract execution logic contained in the user smart contract deployed on at least some member blockchains in the blockchain service network can still be open for call in the form of user services.
  • the contract execution logic corresponding to the user service can no longer be directly bound to the user service, but to the service interface corresponding to the user service.
  • a node device in any target member blockchain in the blockchain service network When a node device in any target member blockchain in the blockchain service network receives call data initiated by a service user for a service interface containing the user service, it can respond to the call data, and determine a target contract execution logic that can be called for the service user from the contract execution logic contained in the user smart contract deployed on other member blockchains that is bound to the service interface, and then initiate a cross-chain call to the user smart contract containing the target contract execution logic deployed on the above-mentioned other member blockchains to complete the service call for the individual user service.
  • the blockchain service network since the blockchain service network supports the service-oriented contract execution logic contained in the user smart contract deployed on each member blockchain, it is open for call in the form of user service, and the contract execution logic corresponding to the user service may no longer be directly bound to the user service, but may be bound to the service interface corresponding to the user service; therefore, when the user service is opened to the service user, only the service interface corresponding to the user service may be exposed to the service user, and the information related to the contract execution logic bound to the service interface may no longer be exposed to the service user, thereby avoiding the privacy leakage caused by directly exposing the information related to the contract execution logic corresponding to the user service to the service user.
  • the contract execution logic corresponding to the above user service is an executable function
  • the user service is directly bound to these executable functions
  • the function names and other information related to these functions will inevitably need to be exposed to the user.
  • the user service is bound to the service interface, it is only necessary to expose these service interfaces and even the functional descriptions of these functions to the user, and the actual content of these functions, such as the function names, no longer needs to be exposed to the user.
  • the contract execution logic that ultimately requests the service call permission is dynamically determined by the system smart contract from the contract execution logic bound to the service interface; therefore, in this way, the user's flexibility in registering for the use of the above-mentioned user services can be improved.
  • the service interface can be bound to multiple contract execution logics with the same service functions. Therefore, when the service usage policy registers the user service, the system smart contract can flexibly specify a contract execution logic from the multiple contract execution logics bound to the service interface for permission authorization according to specific needs. This registration method is obviously more flexible.
  • Figure 1 is a network architecture diagram of a blockchain service network shown in an exemplary embodiment of this specification.
  • the network architecture of the above-mentioned blockchain service network can include a blockchain service network composed of several member blockchains, a target blockchain network to be registered, and a centralized control platform for managing the blockchain service network.
  • the centralized control platform may be a service platform for centralized management of the blockchain service network.
  • the hardware device that carries the centralized control platform may be a server or a server cluster composed of several servers, which is not particularly limited in this specification.
  • the centralized control platform can manage the members of the blockchain service network. For example, it can be responsible for the registration and joining of member blockchains in the blockchain service network, the exit of the network, etc.
  • the above-mentioned centralized control platform can also be used to achieve cross-chain access between member blockchains;
  • the above-mentioned centralized control platform can usually implement management functions for each member blockchain by issuing and deploying system smart contracts to each member blockchain.
  • Managing cross-chain access between member blockchains is also a common management function of the centralized control platform for each member blockchain. Therefore, in this case, the above-mentioned centralized control platform can also issue and deploy system smart contracts for cross-chain data access to each member blockchain, so that each member blockchain network can implement cross-chain data access with other member blockchains based on the deployed system smart contracts.
  • the centralized control platform can also be equipped with a cross-chain service component, which can be specifically used to implement cross-chain data interaction between member blockchains.
  • a cross-chain service component which can be specifically used to implement cross-chain data interaction between member blockchains.
  • Each member blockchain that joins the blockchain service network can achieve cross-chain data access with other member blockchains through the cross-chain service component on the above centralized control platform.
  • the first member blockchain, the second member blockchain and the third member blockchain shown in Figure 1 refer to the member blockchains that have joined the above-mentioned blockchain service network.
  • the target blockchain network to be registered shown in Figure 1 refers to a blockchain network that has not yet joined the blockchain service network.
  • the above-mentioned target blockchain network can apply to join the above-mentioned target blockchain network as a member blockchain by registering and interacting with the centralized management and control platform.
  • FIG. 2 is a flow chart of a method for establishing a blockchain service network according to an exemplary embodiment of this specification.
  • the method can be applied to the centralized management and control platform shown in FIG. 1 ; the method includes:
  • Step 201 Receive a registration request corresponding to a target blockchain
  • the above-mentioned target blockchain can register and become a member blockchain of the blockchain service network by registering and interacting with the centralized control platform of the blockchain service network and sending a registration request to the above-mentioned centralized control platform.
  • the registration request may be specifically initiated by a user having registration authority for the target blockchain through a user account registered on the centralized management and control platform.
  • users with registration rights for the target blockchain and user accounts registered on the centralized control platform may specifically include system administrator accounts in the centralized control platform, administrator accounts registered on the centralized control platform by managers of the target blockchain, user accounts registered on the centralized control platform by deployers of user smart contracts in the target blockchain, etc.
  • the user account that issues a registration request specifically refers to a centralized account registered on the centralized control platform, rather than a blockchain account registered in each member blockchain.
  • the above registration request may include some basic registration information related to the above target blockchain to be registered.
  • the above basic registration information may specifically include the access address information of the above target blockchain, and the blockchain configuration information related to the above target blockchain, etc.
  • the above registration request may also include other forms of registration information, which are not specifically limited in this specification.
  • the access address information of the target blockchain is specifically used to establish a network connection with the centralized control platform; in actual applications, the access address information may specifically include domain name information or IP address information corresponding to one or more node devices in the target blockchain, so that the centralized control platform can establish a communication connection with one or more node devices in the target blockchain based on the domain name information or IP address information.
  • the above-mentioned blockchain configuration information may specifically include any form of information that can be used to represent the basic configuration of the above-mentioned target blockchain; for example, the above-mentioned blockchain configuration information may specifically include the blockchain type information corresponding to the above-mentioned target blockchain, the protocol type information of the blockchain protocol adopted by the above-mentioned target blockchain, and the algorithm type information of the consensus algorithm adopted by the above-mentioned target blockchain, etc.
  • Step 202 In response to the registration request, register the target blockchain to add the target blockchain to the blockchain service network as a member blockchain;
  • the centralized management and control platform When the centralized management and control platform receives a registration request corresponding to the target blockchain, it can respond to the registration request and perform a legitimacy check on the registration request; for example, the legitimacy check on the registration request may specifically include checking whether the initiator of the registration request has the corresponding registration authority; and whether the data format in the registration request meets the preset rules or format requirements, etc.
  • the centralized control platform After the centralized control platform completes the legitimacy check on the registration request, if the registration request passes the legitimacy check, the centralized control platform can further register the target blockchain based on the data content carried in the registration request to add the target blockchain as a member blockchain to the blockchain service network.
  • the registration processing of the target blockchain by the centralized control platform may specifically include creating a blockchain account corresponding to the centralized control platform in the target blockchain.
  • a public-private key pair for the centralized control platform in the target blockchain
  • the private key held by the management user of the centralized control platform.
  • calculate and generate a corresponding account address for example, the account address can usually be a hash value calculated from the public key
  • the account types supported by the blockchain usually include external accounts and contract accounts.
  • An external account is an account directly controlled by a user, also known as a user account.
  • a contract account is an account created by a user through an external account and contains a contract code (i.e., a smart contract).
  • the blockchain account corresponding to the centralized control platform created in the target blockchain described above can specifically be an external account. After the corresponding blockchain account is created for the centralized control platform in the target blockchain, the centralized control platform has obtained the legal user identity in the target blockchain, so that the centralized control platform can initiate a contract call for the user smart contract deployed in the target blockchain based on the external account.
  • the registration process of the target blockchain performed by the centralized control platform may include, in addition to creating a blockchain account corresponding to the centralized control platform in the target blockchain, other forms of registration processing related to the registration process of the target blockchain.
  • the registration process of the target blockchain by the centralized control platform may further include deploying at least one system smart contract in the target blockchain; wherein the at least one system smart contract may specifically be a target system smart contract for cross-chain communication with other member blockchains.
  • the target system smart contract used for cross-chain communication with other member blockchains can also include system smart contracts for realizing other basic management functions; for example, the above-mentioned at least one system smart contract can also include a smart contract for service management of the target blockchain, a system smart contract for network governance of the target blockchain network, and a smart contract for service incentives for users related to user services or service solutions registered on the centralized management and control platform, etc., which will not be listed one by one in this specification.
  • FIG. 3 is a flowchart of a registration process for a target blockchain shown in this specification, including the following execution steps:
  • Step 301 The registrant initiates a registration request corresponding to the target blockchain to the centralized platform;
  • the centralized management and control platform may respond to the registration request and start the registration process for the target blockchain.
  • the registration process for the target blockchain may include the following registration process flow shown in steps 302 to 306.
  • Step 302 saving the blockchain configuration information of the target blockchain
  • Step 303 establishing a communication connection with at least some of the node devices in the target blockchain based on the access address information of the target blockchain;
  • the registration request may include some blockchain configuration information related to the target blockchain; for example, the blockchain configuration information may include the access address information of the target blockchain and the configuration information related to the target blockchain, etc.
  • the centralized management and control platform may obtain the blockchain configuration information carried in the registration request, and then execute the subsequent registration process for the target blockchain based on the obtained blockchain configuration information.
  • the centralized management and control platform can store the blockchain configuration information related to the target blockchain read from the registration request as the configuration information of the member blockchain in the local database.
  • the centralized management and control platform may maintain an information base for storing blockchain configuration information related to each member blockchain in the above-mentioned blockchain service network.
  • the centralized management and control platform may read the blockchain configuration information related to the target blockchain from the above-mentioned registration request and store it in the information base as the blockchain configuration information of the member blockchain.
  • the centralized management and control platform After the centralized management and control platform stores the blockchain configuration information related to the target blockchain as the configuration information of the member blockchain in the local database, it can further establish a communication connection with at least some of the node devices in the target blockchain based on the access address information of the above-mentioned target blockchain read from the registration request.
  • the access address information may specifically include domain name information or IP address information corresponding to one or more node devices in the target blockchain, and the centralized control platform may establish a communication connection with one or more node devices in the target blockchain based on the domain name information or IP address information.
  • the centralized control platform may establish a communication connection with all node devices in the target blockchain, or may only establish a communication connection with some key node devices in the target blockchain (such as a full node storing a complete blockchain ledger).
  • Step 304 Obtain blockchain data related to the target blockchain from a node device in the target blockchain based on the communication connection.
  • the centralized management and control platform After the centralized management and control platform establishes a communication connection with at least some of the node devices in the target blockchain, it can continue to obtain blockchain data related to the target blockchain from the node devices in the target blockchain based on the communication connection.
  • the blockchain data related to the target blockchain obtained from the node device in the target blockchain may specifically include any form of data related to the target blockchain, which is not particularly limited in this specification;
  • the blockchain data related to the target blockchain obtained from the node device in the target blockchain may specifically include the complete blockchain ledger of the target blockchain, the authentication root data corresponding to the blockchain ledger of the target blockchain, and the public key data of each node device in the target blockchain, etc.
  • the authentication root data corresponding to the blockchain ledger can usually include the genesis block data in the blockchain ledger, the block header data of each block, etc., which can be used to authenticate the data stored in the blockchain ledger.
  • the centralized management and control platform After obtaining blockchain data related to the target blockchain from the node devices in the target blockchain, the centralized management and control platform can store the obtained blockchain data in the database.
  • the centralized control platform can maintain an information base for storing blockchain configuration information related to each member blockchain in the above-mentioned blockchain service network.
  • the centralized control platform can read the blockchain configuration information related to the target blockchain from the above-mentioned registration request and store it in the information base as the blockchain configuration information of the member blockchain.
  • the centralized control platform obtains the blockchain data related to the target blockchain from the node device in the target blockchain, it can also associate the obtained blockchain data with the blockchain configuration information related to the above-mentioned target blockchain in the above-mentioned information base for storage.
  • Step 305 Create a blockchain account corresponding to the centralized management and control platform on the target blockchain.
  • the centralized control platform After the centralized control platform obtains the blockchain data related to the target blockchain from the node device in the target blockchain based on the above communication connection, it can also continue to create a corresponding blockchain account for the centralized control platform on the above target blockchain. The specific process of creating the above blockchain account will not be repeated here.
  • the centralized control platform After a corresponding blockchain account is created for the centralized control platform on the target blockchain, the centralized control platform has obtained the legal user identity in the target blockchain and has the ability to call the user smart contract deployed on the target blockchain. Subsequently, the centralized control platform can initiate a contract call for the user smart contract deployed on the target blockchain based on the blockchain account.
  • a blockchain account list may be maintained on the centralized control platform.
  • the blockchain account list may specifically include blockchain accounts corresponding to the centralized control platform created on each member blockchain. After a corresponding blockchain account is created for the centralized control platform on the target blockchain, the blockchain account may be added to the blockchain account list for maintenance.
  • each member blockchain may be the same or different.
  • the blockchain accounts corresponding to the above-mentioned centralized control platform created on each member blockchain may use the same preset blockchain account by default.
  • each member blockchain may reserve a fixed blockchain account in advance as the blockchain account corresponding to the centralized control platform.
  • Step 306 deploy at least one system smart contract in the target blockchain.
  • the centralized control platform can continue to deploy at least one system smart contract in the target blockchain.
  • the at least one system smart contract can specifically include a target system smart contract for cross-chain communication with other member blockchains.
  • the at least one system smart contract mentioned above may also include a smart contract for service management of the target blockchain, a system smart contract for network governance of the target blockchain network, a system smart contract for service incentives for users related to user services registered on a centralized management and control platform, etc., which are not specifically limited in this specification.
  • the above-mentioned target system smart contract for cross-chain communication with other member blockchains can be integrated into a system smart contract.
  • the cross-chain call logic used for cross-chain communication with other member blockchains can be included in the same system smart contract.
  • the contract execution logic contained in the above-mentioned system smart contract is usually the execution logic related to some management functions on the centralized control platform.
  • the contract execution logic contained in the system smart contract for network governance as described above may be the execution logic related to the centralized control platform’s function of network governance for the above-mentioned blockchain service network; correspondingly, the contract execution logic contained in the system smart contract for providing service incentives to users related to user services registered on the centralized control platform as described above may be the execution logic related to the centralized control platform’s function of providing service incentives to users related to registered user services.
  • the contract execution logic contained in the above-mentioned user smart contract is usually related to the user service logic defined by the user on the member blockchain.
  • users on the target blockchain can also complete some operations related to the management functions on the centralized management and control platform on the target blockchain by calling the system smart contract deployed on the target blockchain.
  • Step 307 Return a successful registration message corresponding to the target blockchain to the registrant.
  • the target blockchain After the centralized management and control platform executes the registration processing procedures shown in steps 302 to 306 for the target blockchain, the target blockchain will be successfully added to the blockchain service network as a member blockchain.
  • the centralized management and control platform returns a successful registration message corresponding to the target blockchain to the registrant to notify the registrant that the target blockchain has been successfully joined to the blockchain service network as a member blockchain.
  • step 302 to step 306 in the above embodiment is only for illustration and is not particularly limited in this specification. It is understandable that in actual applications, the order of the various registration processing flows shown in step 302 to step 306 in the above embodiment can be flexibly adjusted and interchanged based on actual registration requirements.
  • a number of user smart contracts can be deployed on each member blockchain in the above-mentioned blockchain service network.
  • the contract execution logic corresponding to the contract code in these user smart contracts can usually include multiple contract execution logics corresponding to different basic service capabilities.
  • the contract execution logic contained in a smart contract can usually be in the form of a function, and a smart contract can contain multiple functions corresponding to different service functions.
  • the centralized control platform can also support the function of servitizing the contract execution logic contained in the user smart contracts deployed on at least some of the member blockchains in the blockchain service network. Accordingly, the service provider can servitize the contract execution logic contained in the user smart contracts deployed on at least some of the member blockchains through the above functions supported by the centralized control platform, and then open it to the service user in the form of user services for the service user to call.
  • servicing the contract execution logic contained in the user smart contracts on at least some of the member blockchains in the blockchain service network it can be specifically servicing a specific contract execution logic contained in a user smart contract, or it can be servicing a combination of multiple contract execution logics as a whole.
  • the user service generated through service-oriented may specifically refer to a service consisting of a specific contract execution logic contained in a user smart contract deployed on each member blockchain in the blockchain service network, or may refer to a service generated by combining multiple contract execution logics contained in a user smart contract deployed on at least some of the member blockchains in the blockchain service network.
  • the user can choose to service a specific contract execution logic contained in the user smart contract, register a user service bound to the contract execution logic on the above-mentioned centralized management and control platform, and open it to other users for other users to call.
  • the user can choose to combine the multiple contract execution logics contained in the above multiple user smart contracts into a user service, and register a user service bound to the above multiple contract execution logics on the above centralized management and control platform, which is open to other users for other users to call.
  • the contract execution logics contained in the user smart contracts distributed on multiple different member blockchains can be combined to generate a user service and then serviced, or the contract execution logics contained in multiple user smart contracts in the same member blockchain can be combined to generate a service and then serviced, which is not specifically limited in this specification.
  • the multiple contract execution logics can also be combined in a certain logical order.
  • the above logical order usually depends on the specific service requirements of the service user. In actual applications, it can be flexibly determined based on the actual service requirements.
  • the contract execution logic when the contract execution logic is service-oriented, it can still be completed by registering user services on the above-mentioned centralized management and control platform, and binding the registered user services with the contract execution logic that needs to be service-oriented.
  • the service provider can specifically initiate service registration on the centralized management and control platform, register the corresponding user service for the contract execution logic that needs to be serviced, and then bind the user service to the above-mentioned contract execution logic to complete the service-oriented contract execution logic.
  • a service interface can be set for the registered user service on the centralized management and control platform, and the service interface of the user service can be bound to the contract execution logic.
  • the above-mentioned service interface can specifically be a service identifier that can uniquely identify the user service.
  • the number of service interfaces set for the above-mentioned user service can be one or more, and is not specifically limited in this specification.
  • the user service when setting the service interface for the user service, the user service can be specifically split into multiple sub-services corresponding to different service functions, and a corresponding service interface can be set for each sub-service, and then the corresponding contract execution logic is bound to each service interface.
  • a target contract execution logic can be allocated to the service user from the multiple contract execution logics bound to the sub-service to provide services to the service caller.
  • Figure 4 is a schematic diagram of setting a service interface for user services and binding contract execution logic to the service interface as shown in this specification.
  • FIG4 shows that the contract instances 1-7 that need to be serviced are respectively affiliated with the user smart contracts deployed on the member blockchains A, B and C.
  • the contract instance refers to the contract execution logic contained in the user smart contract; for example, it can be an executable function contained in the user smart contract.
  • the service A shown in Figure 4 can be divided into sub-service 1 and sub-service 2 according to the service function.
  • the service interface set for sub-service 1 is a1, and the service interface a1 is bound to two contract instances 1 and 2 with the same service function.
  • the service interface set for sub-service 2 is a2, and the service interface a2 is only bound to one contract instance 3.
  • Service B shown in Figure 4 can be divided into sub-service 3, sub-service 4 and sub-service 5 according to service functions.
  • the service interface set for sub-service 3 is b1, and the service interface b1 is bound to only one contract instance 1.
  • the service interface set for sub-service 4 is b2, and the service interface b2 is bound to two contract instances 4 and 5 with the same service function.
  • the service interface set for sub-service 5 is b3, and the service interface b3 is bound to two contract instances 3 and 6 with the same service function.
  • the service C shown in FIG. 4 may not be split into sub-services, and the service interface set for the service C is C1, and the service interface C1 is only bound to one contract instance 7.
  • multiple service interfaces can be set for the user service, and multiple contract execution logics with the same functions can be bound to at least some of the service interfaces.
  • the centralized management and control platform can deploy the target user service as a standardized service to open it to the service user for calling.
  • the above-mentioned centralized management and control platform can adopt a distributed deployment approach when deploying the above-mentioned user services that have completed registration.
  • the so-called distributed deployment specifically refers to the distributed deployment of the above-mentioned user services in the form of system smart contracts on each member blockchain for service users to call.
  • the contract calling logic that constitutes the above-mentioned user service may include the contract execution logic contained in multiple user smart contracts deployed on multiple member blockchains, when the service user calls the above-mentioned user service, it may also need to cross-chain call multiple user smart contracts distributed on multiple member blockchains; therefore, when deploying the above-mentioned user service, the above-mentioned centralized management and control platform can specifically develop corresponding cross-chain calling logic for the user service, and then deploy the cross-chain calling logic as the contract execution logic in the system smart contract on each member blockchain.
  • the contract execution logic contained in the above system smart contract is usually the execution logic related to some management functions on the centralized control platform. Therefore, in this way, it is equivalent to deploying the cross-chain call logic developed for the user service as part of the execution logic related to some management functions on the centralized control platform in the form of a system smart contract on each member blockchain.
  • the binding relationship between the service interface of the user service and the contract execution logic can also be stored in the above-mentioned system smart contract as the service configuration information of the user service, and maintained by the above-mentioned system smart contract.
  • the centralized management and control platform can also develop corresponding service registration logic for the user service when deploying the user service; then deploy the service registration logic as the contract execution logic in the system smart contract on each member blockchain.
  • the registration logic developed for the user service is also deployed on each member blockchain as part of the execution logic related to some management functions on the centralized management and control platform in the form of a system smart contract.
  • FIG. 5 is a flowchart of a method for registering the use of a service according to an exemplary embodiment of the present specification, which is applied to a node device in any target member blockchain shown in FIG. 1 ; wherein the system smart contract is deployed on each member blockchain in the above blockchain network; the system smart contract includes a service registration logic corresponding to the above user service; the method includes:
  • Step 502 Obtaining the service user's registration data for the user service; wherein the service interface of the user service is bound to the contract execution logic contained in the user smart contract deployed on other member blockchains;
  • the service user can submit the usage registration data for the user service to the node device in the target member blockchain to which it is connected, to initiate a contract call for the above-mentioned system smart contract, and obtain the service call permission for the user service.
  • the above-mentioned service user can be a user who has registered a user account on the target member blockchain, or a user smart contract deployed on the target member blockchain, which is not particularly limited in this specification.
  • the call data may specifically be a smart contract call transaction for the system smart contract packaged by the user through a user client accessing the target member blockchain.
  • the user client can submit the packaged smart contract call transaction as the above-mentioned call data to the node device in the target member blockchain, and initiate a contract call for the above-mentioned cross-chain call logic contained in the above-mentioned system smart contract, so as to trigger the node devices in the target member blockchain to distributely execute the above-mentioned cross-chain call logic contained in the system smart contract to obtain the service call permission of the user service.
  • the user can also submit the call data of the smart contract for the above-mentioned system smart contract to the Baas platform corresponding to the above-mentioned target member blockchain through the above-mentioned user client, and then the Baas platform will package the above-mentioned call data into a contract call transaction for the above-mentioned system smart contract and submit it to the node device in the target member blockchain.
  • the user smart contract may include a contract execution logic that references the service interface of the user service.
  • Referencing the service interface of the user service in the contract execution logic usually refers to referencing the service interface of the user service in the contract code corresponding to the contract execution logic, so that when the user calls the contract code, the contract code can further initiate a service call for the user service corresponding to the service interface based on the referenced service interface during execution.
  • the user smart contract can further initiate a service call for the user service corresponding to the service interface referenced by the contract execution logic based on the service interface referenced by the contract execution logic.
  • the service call process initiated by the user smart contract for the referenced user service is actually a mutual call process initiated by the user smart contract and the above-mentioned system smart contract.
  • the above call data can specifically be a call message for the above system smart contract generated by the user smart contract based on the message call mechanism between smart contracts when the user calls the contract execution logic contained in the user smart contract that references the above user service.
  • the user smart contract can specifically generate a call message for the above-mentioned system smart contract based on the message call mechanism between smart contracts.
  • the call message is submitted to the above-mentioned system smart contract as the call data for the above-mentioned user service, and a contract call for the above-mentioned system smart contract is initiated to trigger the node devices in the blockchain to distribute and execute the above-mentioned usage registration logic contained in the system smart contract to obtain the service call permission for the above-mentioned user service.
  • call message can be any form of data suitable for transmission between smart contracts and is not particularly limited in this specification.
  • the call message may be an executable instruction defined based on the development language used by the smart contract and suitable for transmission between smart contracts.
  • the call message may be a call instruction for the system smart contract.
  • Step 504 In response to the use registration data, the service registration logic included in the system smart contract is called, the target contract execution logic is determined for the service user from the contract execution logic bound to the service interface, and the service call permission related to the target contract execution logic is authorized to the service user;
  • the usage registration data may specifically carry the service interface corresponding to the user service.
  • the user service is a service generated by combining multiple contract execution logics
  • the user service may include multiple service interfaces, and each service interface corresponds to a sub-service in the user service.
  • the service user can choose to register one or more sub-services in the user service.
  • the above registration data can also carry one or more service interfaces selected by the service user from the multiple service interfaces that need to be registered.
  • the node device in the above-mentioned target member blockchain can respond to the usage registration data, further call the above-mentioned service registration logic contained in the above-mentioned system smart contract, obtain the service interface carried in the above-mentioned usage registration data, and determine the target contract execution logic for the service user from the contract execution logic bound to the service interface.
  • the node device in the target member blockchain may first determine whether the service interface is bound to multiple contract execution logics after calling the usage registration logic contained in the system smart contract and obtaining the service interface carried in the call data;
  • the centralized management and control platform can also maintain the binding relationship between the service interface allocated for the user service and the contract execution logic that needs to be serviced in the above-mentioned system smart contract, so that the above-mentioned system smart contract can clarify whether the service interface carried in the above-mentioned registration data is bound to multiple contract execution logics by querying the above-mentioned binding relationship maintained.
  • the system smart contract can dynamically allocate a target contract execution logic for providing services to the service user from the multiple contract execution logics bound to the service interface based on a preset scheduling strategy.
  • the contract execution logic that ultimately requests the service call permission is dynamically determined by the system smart contract from the contract execution logic bound to the service interface; therefore, in this way, the user's flexibility in registering for the use of the above-mentioned user services can be improved.
  • preset scheduling strategy can be any form of strategy for dynamically allocating contract execution logic for service users from multiple contract execution logics bound to the service interface, and is not specifically limited in this specification. In practical applications, specific scheduling strategies can be flexibly set based on specific scheduling requirements.
  • the above scheduling strategy includes any one or more combinations of the following:
  • a scheduling strategy for the contract execution logic is randomly assigned to the service user.
  • the contract execution logic can be randomly assigned to the service user from multiple contract execution logics bound to the above service interface to provide services to the service user.
  • the pre-specified contract execution logic among the multiple contract execution logics bound to the above service interface is allocated to the scheduling strategy of the above service user.
  • the service provider can flexibly specify the contract execution logic for providing services to the service user from multiple contract execution logics bound to the above service interface, thereby improving the service flexibility of the above user service.
  • a fixed contract execution logic can be specified from the above multiple contract execution logics to provide services for the service user.
  • the contract execution logic whose service indicators meet the preset conditions is assigned to the scheduling strategy of the above service user.
  • the centralized management and control platform can count the service indicators of each contract execution logic bound to the service interface in real time, and store the service indicators in the system smart contract, which will be maintained by the system smart contract.
  • the system smart contract can screen out the contract execution logic whose service indicators meet the preset conditions based on the maintained service indicators, and allocate them to the service users, thereby realizing refined management of each contract execution logic bound to the service interface.
  • a contract execution logic that best suits the service user can be screened out for the service user, and services can be provided to the service user.
  • the above service indicators may specifically include any form of indicators that can characterize the usage status of the contract execution logic bound to the above service interface, and are not specifically limited in this specification. Accordingly, the above preset conditions usually depend on the specific type of the above service indicators. In practical applications, they can be flexibly set based on specific service requirements.
  • the service indicator may specifically include the number of service users provided by the contract execution logic.
  • the preset condition may include the contract execution logic with the smallest number among the multiple contract execution logics bound to the service interface.
  • the system smart contract dynamically allocates the contract execution logic providing services to the service user from the multiple contract execution logics bound to the service interface based on the scheduling strategy three described above, the number of service users provided with services by the multiple contract execution logics can be counted separately, and then the contract execution logic with the smallest number can be allocated to the service user as the target contract execution logic.
  • each contract execution logic Since the number of service users provided by each contract execution logic can usually be understood as the service load of each contract execution logic when providing services to service users, load balancing of the above-mentioned multiple contract execution logics can be achieved in this way.
  • the above-mentioned service indicators may also include, in actual applications, the total duration of services provided by the above-mentioned contract execution logic to each service provider, the number of successful calls when providing services, the call success rate, the number of call failures and other service indicators, which will not be listed one by one in this manual.
  • the above-mentioned preset conditions may include the condition that the above-mentioned contract execution logic with the smallest number among the multiple contract execution logics bound to the above-mentioned service interface, and in actual applications, may also include other forms of conditions, which will not be listed one by one in this specification; for example, in one example, the above-mentioned preset conditions may also include the above-mentioned contract execution logic with the smallest number being lower than the threshold.
  • service registration information of the above-mentioned service user for the above-mentioned user service can also be generated, and the service registration information can be stored in the system smart contract so that the stored service registration information can be maintained by the system smart contract.
  • the above-mentioned service registration information may specifically include information related to the target contract execution logic allocated by the system smart contract to the service user based on the above-mentioned scheduling strategy, from multiple contract execution logics bound to the above-mentioned service interface, to provide services to the service user; for example, it may be identification information corresponding to the target contract execution logic (such as function name, etc.).
  • the calling authority related to the target contract execution logic can be further authorized to the service user.
  • the calling permission of the above-mentioned user service and the calling permission of the contract execution logic bound to the service interface of the user service can be authorized separately as two independent permissions.
  • the service call permission of the user service can be first authorized to the target user smart contract; and, the service call permission of the above-mentioned target contract execution logic can be authorized to the service user.
  • the target contract execution logic assigned to the service user from the multiple contract execution logics bound to the user service can be authorized again separately, thereby fundamentally avoiding the mutual influence between the service call permission of the above user service and the call permission of the contract execution logic bound to the user service.
  • the service user is a user smart contract deployed on the target member blockchain
  • a two-way permission authorization method can be adopted.
  • the calling permission of the user smart contract can also be correspondingly authorized to the target contract execution logic.
  • the contract execution logic contained in the user smart contract may also be bound to the service interface of another user service; therefore, by adopting this two-way permission authorization method, the calling permission related to the other user service can also be synchronously authorized to the target contract execution logic, thereby avoiding the subsequent repeated authorization through the authorization method described above when the target contract execution logic has the calling requirements of the above-mentioned other user service.
  • the above-mentioned target contract execution logic can synchronously obtain the calling permission of the contract execution logic contained in the above-mentioned user smart contract; therefore, for the target contract execution logic, it can call back the user smart contract as the service caller to promptly return the service call result of the user smart contract as the service user for the above-mentioned user service to the user smart contract as the service caller, without the need to use the asynchronous return service call result method, thereby improving the service call efficiency when calling the above-mentioned user service.
  • FIG. 6 is a flowchart of a cross-chain calling method of a smart contract according to an exemplary embodiment of the present specification, which is applied to a node device in any target member blockchain shown in FIG. 1 ; wherein the above-mentioned system smart contract is deployed on each member blockchain in the blockchain network; the above-mentioned system smart contract contains a cross-chain calling logic corresponding to the user service; the method includes:
  • Step 602 Obtain the call data of the service user for the user service; wherein the service interface of the user service is bound to the contract execution logic contained in the user smart contract deployed on other member blockchains;
  • the service user can initiate a contract call for the above-mentioned system smart contract by submitting the call data for the user service to the node device in the target member blockchain to which it is connected, so as to complete the service call of the user service.
  • the call data may be a smart contract call transaction for the system smart contract packaged by the user through a user client accessing the target member blockchain.
  • the user client may submit the packaged smart contract call transaction to the node device in the target member blockchain, initiate a contract call for the system smart contract, and trigger the node device in the target member blockchain to execute the cross-chain call logic contained in the system smart contract in a distributed manner to complete the service call for the user service.
  • the user can also submit the call data of the smart contract for the above-mentioned system smart contract to the Baas platform corresponding to the above-mentioned target member blockchain through the above-mentioned user client, and then the Baas platform will package the above-mentioned call data into a contract call transaction for the above-mentioned system smart contract, and submit it to the node device in the target member blockchain.
  • the user smart contract may include a contract execution logic that references the service interface of the user service.
  • the user smart contract may generate a call message for the system smart contract based on the message call mechanism between smart contracts. Then, the call message is submitted to the system smart contract as call data for the user service, and a contract call for the system smart contract is initiated to trigger the node devices in the blockchain to execute the cross-chain call logic contained in the system smart contract in a distributed manner to complete the service call for the user service.
  • the call message may be an executable instruction defined based on the development language used by the smart contract and suitable for transmission between smart contracts.
  • the call message may be a call instruction for the system smart contract.
  • Step 604 in response to the call data, calls the cross-chain call logic contained in the system smart contract, determines the target contract execution logic for the service user from the contract execution logic bound to the service interface, and initiates a cross-chain call to the user smart contract containing the target contract execution logic deployed on the other member blockchains.
  • the above-mentioned calling data may specifically carry the service interface corresponding to the above-mentioned user service.
  • the user service is a service generated by combining multiple contract execution logics
  • the user service may include multiple service interfaces, and each service interface corresponds to a sub-service in the user service.
  • the service user can select one or more sub-services in the user service to call.
  • the above call data can also carry one or more service interfaces selected by the service user from the multiple service interfaces to be called.
  • the node device in the above-mentioned target member blockchain can respond to the call data, further call the above-mentioned cross-chain call logic contained in the above-mentioned system smart contract, obtain the service interface carried in the above-mentioned call data, and determine the target contract execution logic for the service user from the contract execution logic bound to the service interface.
  • the node device in the target member blockchain may first determine whether the service interface is bound to multiple contract execution logics after calling the cross-chain call logic contained in the system smart contract and obtaining the service interface carried in the call data;
  • the centralized management and control platform can maintain the binding relationship between the service interface allocated for the user service and the contract execution logic that needs to be serviced in the above-mentioned system smart contract, so that the above-mentioned system smart contract can clarify whether the service interface carried in the above-mentioned call data is bound to multiple contract execution logics by querying the above-mentioned binding relationship maintained.
  • the system smart contract can dynamically allocate a target contract execution logic for providing services to the service user from the multiple contract execution logics bound to the service interface based on a preset scheduling strategy.
  • the above-mentioned preset scheduling strategy can be any form of strategy for dynamically allocating contract execution logic to the service user from multiple contract execution logics bound to the service interface, and is not specifically limited in this specification.
  • specific scheduling strategies can be flexibly set based on specific scheduling requirements.
  • the above-mentioned scheduling strategy can still include any one or more of the above-mentioned scheduling strategy one, scheduling strategy two, and scheduling strategy three described in the embodiment shown in Figure 5, which will not be repeated in this embodiment.
  • the above-mentioned system smart contract can maintain the service registration information of the service user for the above-mentioned user service in advance, and the service registration information may include the system smart contract at the stage when the service user registers for the use of the user service, based on the above-mentioned preset scheduling strategy, from multiple contract execution logics bound to the service interface corresponding to the user service, information related to the target contract execution logic for providing services to the service user is allocated to the service user; therefore, in this case, when the above-mentioned system smart contract determines the target contract execution logic for the service user from the contract execution logic bound to the above-mentioned service interface, it may no longer perform real-time allocation, but directly obtain the information related to the target contract execution logic included in the above-mentioned service registration information, and then directly allocate the target contract execution logic to the service user.
  • the target contract execution logic allocated to the service user during the registration phase can be preferentially allocated to the service user, thereby avoiding repeated allocation of contract execution logic to the service user when the service user calls the user service.
  • the calling authority of the above-mentioned user service and the calling authority of the contract execution logic bound to the service interface of the user service can be used as two independent authorities and authorized to the service user respectively.
  • the permission verification logic contained in the system smart contract can also be called first to verify whether the service user has the calling authority of the user service; if so, the above-mentioned cross-chain calling logic contained in the system smart contract can be further called to determine the target contract execution logic for the service user from the contract execution logic bound to the service interface.
  • the permission verification logic contained in the system smart contract can also be called first to verify whether the service user has the calling authority for the target contract execution logic; if so, a cross-chain call to the user smart contract containing the target contract execution logic deployed on the other member blockchain is initiated.
  • the specific method in which the system smart contract initiates a cross-chain call to the user smart contract deployed on the other member blockchain that contains the target contract execution logic can still be completed using the message call mechanism between smart contracts, and will not be described in detail in this manual.
  • this specification also provides embodiments of an apparatus, an electronic device, and a storage medium.
  • FIG7 is a schematic diagram of an electronic device provided by an exemplary embodiment. Please refer to FIG7.
  • the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 810, and may also include hardware required for other services.
  • One or more embodiments of this specification may be implemented based on software, such as the processor 702 reading the corresponding computer program from the non-volatile memory 710 into the memory 708 and then running it.
  • one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or logic devices.
  • FIG8 is a block diagram of a service usage registration device shown in this specification according to an exemplary embodiment, and the device can be applied to an electronic device as shown in FIG7 to implement the technical solution of this specification.
  • the device can be applied to a node device in any target member blockchain in a blockchain service network composed of several member blockchains; wherein the contract execution logic contained in the user smart contract deployed on at least some member blockchains in the blockchain service network is open for call in the form of user services; system smart contracts are deployed on each member blockchain in the blockchain network; the system smart contract contains the service registration logic corresponding to the user service; the device 80 includes:
  • Acquisition module 801 acquiring the use registration data of the user service by the service user; wherein the service interface of the user service is bound to the contract execution logic contained in the user smart contract deployed on other member blockchains;
  • the calling module 802 in response to the usage registration data, calls the service registration logic contained in the system smart contract, determines the target contract execution logic for the service user from the contract execution logic bound to the service interface, and authorizes the service calling authority related to the target contract execution logic to the service user.
  • the present specification also provides an electronic device, which includes a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to implement the steps in all the method flows described above.
  • the present specification also provides a computer-readable storage medium on which executable instructions are stored; wherein, when the instructions are executed by a processor, the steps in all the method flows described above are implemented.
  • the relevant parts can refer to the partial description of the method embodiment.
  • the device embodiment described above is only schematic, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. Ordinary technicians in this field can understand and implement it without paying creative work.
  • a typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or a combination of any of these devices.
  • a computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
  • processors CPU
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in a computer-readable medium, in the form of 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.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information.
  • Information can be computer readable instructions, data structures, program modules or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.
  • computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.
  • first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information.
  • the word "if” as used herein may be interpreted as "at the time of” or "when” or "in response to determining”.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Technology Law (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本说明书一个或多个实施例提供一种智能合约的跨链调用方法及装置。所述方法包括:获取服务使用方针对所述用户服务的使用注册数据;其中,所述用户服务的服务接口绑定了部署在其它成员区块链上的用户智能合约所包含的合约执行逻辑;响应于所述使用注册数据,调用所述系统智能合约包含的所述服务注册逻辑,从与所述服务接口绑定的合约执行逻辑中,为所述服务使用方确定目标合约执行逻辑,并将所述目标合约执行逻辑相关的服务调用权限授权给所述服务使用方。

Description

一种智能合约的跨链调用方法及装置
本申请要求于2022年09月27日提交中国专利局、申请号为202211188911.2、发明名称为“一种智能合约的跨链调用方法及装置”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本说明书多个实施例涉及区块链技术领域,尤其涉及一种智能合约的跨链调用方法及装置。
背景技术
随着区块链技术的发展,越来越多的区块链建立起来,然而这些区块链大部分都是独立的,相互之间无法联通。因此,在实际应用中,为了充分利用各个区块链上部署的服务资源,可以将这些区块链作为成员区块链组建成一个区块链服务网络,并将各个成员区块链上部署的智能合约所包含的合约执行逻辑,通过该区块链服务网络的管理平台,以用户服务的形式开放给用户,供用户进行调用。
发明内容
根据本说明书多个实施例的第一方面,提出一种服务的使用注册方法,所述方法应用于由若干成员区块链构成的区块链服务网络中的任一目标成员区块链中的节点设备;其中,所述区块链服务网络中的至少部分成员区块链上部署的用户智能合约所包含的合约执行逻辑,以用户服务的形式开放调用;所述区块链网络中的各成员区块链上,分别部署了系统智能合约;所述系统智能合约包含与所述用户服务对应的服务注册逻辑;
所述方法包括:
获取服务使用方针对所述用户服务的使用注册数据;其中,所述用户服务的服务接口绑定了部署在其它成员区块链上的用户智能合约所包含的合约执行逻辑;
响应于所述使用注册数据,调用所述系统智能合约包含的所述服务注册逻辑,从与所述服务接口绑定的合约执行逻辑中,为所述服务使用方确定目标合约执行逻辑,并将所述目标合约执行逻辑相关的服务调用权限授权给所述服务使用方。
根据本说明书多个实施例的第二方面,还提供一种智能合约的跨链调用装置,所述装置应用于由若干成员区块链构成的区块链服务网络中的任一目标成员区块链中的节点设备;其中,所述区块链服务网络中的至少部分成员区块链上部署的用户智能合约所包含的合约执行逻辑,以用户服务的形式开放调用;所述区块链网络中的各成员区块链上,分别部署了系统智能合约;所述系统智能合约包含与所述用户服务对应的服务注册逻辑;
所述装置包括:
获取模块,获取服务使用方针对所述用户服务的使用注册数据;其中,所述用户服务的服务接口绑定了部署在其它成员区块链上的用户智能合约所包含的合约执行逻辑;
调用模块,响应于所述使用注册数据,调用所述系统智能合约包含的所述服务注册逻辑,从与所述服务接口绑定的合约执行逻辑中,为所述服务使用方确定目标合约执行逻辑,并将所述目标合约执行逻辑相关的服务调用权限授权给所述服务使用方。
在本说明书以上的实施方式中,一方面,由于区块链服务网络支持对各成员区块链上部署的用户智能合约所包含的合约执行逻辑进行服务化,将其以用户服务的形式开放调用,并且与该用户服务对应的合约执行逻辑,可以不再与该用户服务直接进行绑定,而是与该用户服务对应的服务接口进行绑定;因此,在将该用户服务开放给服务使用方时,可以只将该用户服务对应的服务接口暴露给服务使用方即可,而与该服务接口绑定的合约执行逻辑相关的信息,则可以不再暴露给该服务使用方,从而可以避免将与用户服务对应的合约执行逻辑相关的信息,直接暴露给服务使用方而造成的隐私泄露。
另一方面,由于服务使用方在通过调用系统智能合约包含的服务注册逻辑,来请求取得该用户服务的服务调用权限时,最终请求到服务调用权限的合约执行逻辑,是由系统智能合约从与该服务接口绑定的合约执行逻辑中动态确定出的;因此,通过这种方式,可以提升用户在对上述用户服务进行使用注册时的灵活性。
而且,对于服务使用方来说,并不能提前感知到自身请求到服务权限的合约执行逻辑所在的智能合约,以及该智能合约所在的成员区块链;因此,这种服务使用注册的方式,将具有较高的隐私性和安全性。
附图说明
图1是本说明书一示例性实施例示出的区块链服务网络的网络架构图。
图2是本说明书根据一示例性实施例示出的一种区块链服务网络的组建方法的流程图。
图3是本说明书示出的一种对目标区块链进行注册处理的流程图。
图4是本说明书根据一示例性实施例示出的一种为用户服务设置服务接口,并为服务接口绑定合约执行逻辑的示意图。
图5是本说明书根据一示例性实施例示出的一种服务的使用注册方法的流程图。
图6是本说明书根据一示例性实施例示出的一种智能合约的跨链调用方法的流程图。
图7是一示例性实施例提供的一种电子设备的示意结构图。
图8是本说明书根据一示例性实施例示出的一种服务的使用注册装置的框图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本说明书保护的范围。
需要说明的是:在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。
在相关技术中,为了整合不同的区块链上部署的用户智能合约的服务能力,充分利用各个区块链上部署的服务资源,通常可以将这些区块链作为成员区块链组建成一个区块链服务网络,再将各个成员区块链上部署的智能合约所包含的合约执行逻辑,通过该区块链服务网络的中心化管理平台进行服务化,以用户服务的形式开放给用户,供用户进行调用。在实际应用中,在将各个成员区块链上部署的智能合约所包含的合约执行逻辑,进行服务化时,具体可以通过在区块链服务网络的管理平台上注册一个面向用户的用户服务,并将该用户服务与需要服务化的合约执行逻辑直接进行绑定,然后再将该用户服务开 放给用户。
由于注册完成的该用户服务,最终需要开放给用户;因此,如果采用将该用户服务与需要服务化的合约执行逻辑直接进行绑定的方式,则这些与用户服务绑定的合约执行逻辑相关的信息,势必也会暴露给用户从而面临隐私暴露的风险。
有鉴于此,本说明书则提出一种在对区块链上部署的智能合约所包含的合约执行逻辑进行服务化的应用场景中,将需要服务化的合约执行逻辑,与面向用户开放的用户服务的服务接口进行绑定,并且在请求该用户服务的调用权限时,从与该用户服务的服务接口绑定的合约执行逻辑中,来动态确定被请求到服务调用权限的合约调用逻辑的服务注册方案。
在实现时,区块链服务网络中的至少部分成员区块链上部署的用户智能合约所包含的合约执行逻辑,仍然可以以用户服务的形式开放调用。其中,与该用户服务对应的合约执行逻辑,可以不再与该用户服务直接进行绑定,而是与该用户服务对应的服务接口进行绑定。
当区块链服务网络中的任一目标成员区块链中的节点设备,在收到服务使用方发起的针包含该用户服务的服务接口的调用数据时,可以响应该调用数据,从与该服务接口绑定的部署在其它成员区块链上的用户智能合约所包含的合约执行逻辑中,为该服务使用方确定出一个可供调用的目标合约执行逻辑,然后再发起针对上述其它成员区块链上部署的包含该目标合约执行逻辑的用户智能合约的跨链调用,以完成针对个用户服务的服务调用。
在以上技术方案中,一方面,由于区块链服务网络支持对各成员区块链上部署的用户智能合约所包含的合约执行逻辑进行服务化,将其以用户服务的形式开放调用,并且与该用户服务对应的合约执行逻辑,可以不再与该用户服务直接进行绑定,而是与该用户服务对应的服务接口进行绑定;因此,在将该用户服务开放给服务使用方时,可以只将该用户服务对应的服务接口暴露给服务使用方即可,而与该服务接口绑定的合约执行逻辑相关的信息,则可以不再暴露给该服务使用方,从而可以避免将与用户服务对应的合约执行逻辑相关的信息,直接暴露给服务使用方而造成的隐私泄露。
例如,以与上述用户服务对应的合约执行逻辑为可执行的函数为例,如果采用直接将该用户服务与这些可执行的函数进行绑定的方式,势必需要将这些函数相关的函数名等信息暴露给用户。而如果采用将该用户服务与服务接口进行绑定,可以还需要将这些服务接口甚至是这些函数相关的功能描述等信息暴露给用户即可,而这些函数的函数名等实质的内容,则可以不再需要暴露给用户。
另一方面,由于服务使用方在通过调用系统智能合约包含的服务注册逻辑,来请求取得该用户服务的服务调用权限时,最终请求到服务调用权限的合约执行逻辑,是由系统智能合约从与该服务接口绑定的合约执行逻辑中动态确定出的;因此,通过这种方式,可以提升用户在对上述用户服务进行使用注册时的灵活性。
例如,在实际应用中,该服务接口可以绑定多个服务功能相同的合约执行逻辑,从而在服务使用方针对该用户服务进行服务使用注册时,该系统智能合约则可以按照具体的需求,从与该服务接口绑定的多个合约执行逻辑中,灵活的指定出一个合约执行逻辑进行权限授权,这种使用注册方式显然具有灵活性较高的特点。
而且,对于服务使用方来说,并不能提前感知到自身请求到服务权限的合约执行逻辑所在的智能合约,以及该智能合约所在的成员区块链;因此,这种服务使用注册的方式,将具有较高的隐私性和安全性。
例如,仍以与上述用户服务对应的合约执行逻辑为可执行的函数为例,由于用户在针对该用户服务进行服务使用注册时,系统智能合约从与该用户服务的服务接口绑定的可执行的函数中分配的函数,对于用户而言是完全不确定的,用户也无法提前了解到这些信息。因此,这种服务使用注册方式,显然是具有一定的隐蔽性,可以充分确保这些合约执行逻辑在服务使用注册阶段的隐私安全。
请参见图1,图1是本说明书一示例性实施例示出的区块链服务网络的网络架构图。
如图1所示,在上述区块链服务网络的网络架构中,可以包括由若干成员区块链组成的区块链服务 网络、待注册的目标区块链网络以及用于对区块链服务网络进行管理的中心化管控平台。
其中,上述中心化管控平台,具体可以是一个用于对上述区块链服务网络进行中心化管理的服务平台。承载该中心化管控平台的硬件设备,可以是服务器,也可以是基于若干台服务器构成的服务器集群,在本说明书中不进行特别限定。
上述中心化管控平台作为中心化的服务平台,可以对上述区块链服务网络进行成员管理。例如,可以负责区块链服务网络中的成员区块链的注册加入、退出网络,等等。
除此之外,上述中心化管控平台还可以用于实现各成员区块链之间的跨链访问;
例如,在实际应用中,上述中心化管控平台,通常可以通过向各成员区块链下发和部署系统智能合约,来实现针对各个成员区块链的管理功能。而对各成员区块链之间的跨链访问进行管理,也是中心化管控平台针对各成员区块链的一种常见的管理功能。因此,在这种情况下,上述中心化管控平台也可以向各成员区块链下发并部署用于实现跨链数据访问的系统智能合约,使得各成员区块链网络可以基于部署的上述系统智能合约,来实现与其它成员区块链之间的跨链数据访问。
当然,除了通过向各成员区块链下发和部署系统智能合约的方式,来实现针对各个成员区块链的管理功能的以外,中心化管控平台也可以搭载一个跨链服务组件,该跨链服务组件可以具体用于实现各成员区块链之间的跨链数据交互。加入区块链服务网络的各成员区块链,可以通过上述中心化管控平台上的跨链服务组件,来实现与其它成员区块链之间的跨链数据访问。
请继续参见图1,需要说明的是,在初始情况下,区块链服务网络中可以没有成员区块链,目标区块链通过中心化管理平台完成注册后才能加入到区块链服务网络中。
其中,图1中示出的第一成员区块链、第二成员区块链和第三成员区块链,是指已经加入上述区块链服务网络的成员区块链。图1中示出的待注册的目标区块链网络,是指暂未加入区块链服务网络的区块链网络,上述目标区块链网络可以通过与中心化管控平台进行注册交互,来申请作为成员区块链加入到上述目标区块链网络。
请参见图2,图2是本说明书根据一示例性实施例示出的一种区块链服务网络的组建方法的流程图,该方法可以应用于图1所示的中心化管控平台;所述方法包括:
步骤201:接收与目标区块链对应的注册请求;
上述目标区块链可以通过与区块链服务网络的中心化管控平台进行注册交互,向上述中心化管控平台发送注册请求的方式,来注册成为该区块链服务网络的成员区块链。
其中,上述注册请求具体可以是由具有上述目标区块链的注册权限的用户,通过在上述中心化管控平台上所注册的用户账户所发起的。
例如,在实际应用中,具有上述目标区块链的注册权限的用户,在上述中心化管控平台上注册的用户账户,具体可以包括上述中心化管控平台中的系统管理员账户、上述目标区块链的管理者在上述中心化管控平台上注册的管理员账户、目标区块链中的用户智能合约的部署方用户在上述中心化管控平台上注册的用户账户,等等。需要指出的是,发出注册请求的用户账户,具体是指在中心化管控平台中注册的中心化账户,而并不是在各成员区块链中注册的区块链账户。
其中,在上述注册请求中,可以包括与待注册的上述目标区块链相关的一些基础注册信息。上述基础注册信息具体可以包括,上述目标区块链的访问地址信息、以及上述目标区块链相关的区块链配置信息,等等。
当然,在实际应用中,在上述注册请求中,除了可以包括与待注册的上述目标区块链相关的一些基础注册信息以外,还可以包含其它形式的注册信息,在本说明书中不进行特别限定。其中,上述目标区块链的访问地址信息,具体用于与中心化管控平台之间建立网络连接;在实际应用中,上述访问地址信息具体可以包括上述目标区块链中的一个或者多个节点设备对应的域名信息或者IP地址信息,使得中心化管控平台可以基于上述域名信息或者IP地址信息,与上述目标区块链中的一个或者多个节点设备之间建立通信连接。
上述区块链配置信息,具体可以包括任意形式的能够用于表示上述目标区块链的基本配置的信息;例如,上述区块链配置信息,具体可以包括与上述目标区块链对应的区块链类型信息、上述目标区块链所采用的区块链协议的协议类型信息,以及上述目标区块链采用的共识算法的算法类型信息,等等。
步骤202:响应于所述注册请求,针对所述目标区块链进行注册处理,以将所述目标区块链作为成员区块链加入所述区块链服务网络;
中心化管控平台在接收到与目标区块链对应的注册请求时,可以响应该注册请求,对该注册请求进行合法性检查;例如,对该注册请求进行的合法性检查,具体可以包括检查该注册请求的发起者,是否具有相应的注册权限;以及,该注册请求中的数据格式是否满足预设的规则或格式要求,等等。
中心化管控平台在完成针对该注册请求的合法性检查后,如果该注册请求通过了合法性检查,中心化管控平台可以进一步基于该注册请求中携带的数据内容,对该目标区块链进行注册处理,以将该目标区块链作为成员区块链加入到该区块链服务网络。
其中,中心化管控平台对目标区块链进行的注册处理,具体可以包括在该目标区块链中创建与该中心化管控平台对应的区块链账户。
例如,在实现时,可以先在该目标区块链中为该中心化管控平台申请一个公私钥对,私钥由该中心化管控平台的管理用户持有,再基于公钥进行计算生成一个对应的账户地址(比如该账户地址通常可以是公钥计算得到的一个hash值),然后在目标区块链中再创建一个与该账户地址对应的区块链账户。
需要说明的是,在采用账户模型的区块链中,区块链支持的账户类型通常包括外部账户和合约账户。外部账户就是由用户直接控制的账户,也称之为用户账户。而合约账户则是由用户通过外部账户创建的,包含合约代码的账户(即智能合约)。而以上描述的在该目标区块链中创建与该中心化管控平台对应的区块链账户,具体可以是一个外部账户。当在该目标区块链中为该中心化管控平台创建了对应的区块链账户之后,此时该中心化管控平台已取得该目标区块链中合法的用户身份,从而使得中心化管控平台可以基于该外部账户,来发起针对该目标区块链中部署的用户智能合约的合约调用。
中心化管控平台对目标区块链进行的注册处理,除了可以包括在该目标区块链中创建与该中心化管控平台对应的区块链账户之外,还可以包括与该目标区块链的注册过程相关的其它形式的注册处理过程。
例如,在示出的一种实施方式中,中心化管控平台对目标区块链进行的注册处理,具体还可以包括在目标区块链中部署至少一个系统智能合约;其中,上述至少一个系统智能合约具体可以是一个用于与其它成员区块链进行跨链通信的目标系统智能合约。
当然,除了该用于与其它成员区块链进行跨链通信的目标系统智能合约以外,还可以包括用于实现其它的基础管理功能的系统智能合约;例如,上述至少一个系统智能合约还可以包括用于对目标区块链进行服务管理的智能合约,用于对目标区块链网络进行网络治理的系统智能合约,以及用于对中心化管控平台上注册的用户服务或者服务解决方案相关的用户进行服务激励的智能合约等等,在本说明书中不再进行一一列举。
请参见图3,图3为本说明书示出的一种对目标区块链进行注册处理的流程图,包括如下的执行步骤:
步骤301,注册方向中心化平台发起与目标区块链对应的注册请求;
中心化管控平台在收到上述注册请求后,可以响应该注册请求,开始对上述目标区块链进行注册处理。其中,在本实施例中,对上述目标区块链进行的注册处理,可以包括以下的步骤302-步骤306示出的注册处理流程。
步骤302,保存目标区块链的区块链配置信息;
步骤303,基于目标区块链的访问地址信息与目标区块链中的至少部分节点设备建立通信连接;
如前所述,在上述注册请求中,可以包括与上述目标区块链相关的一些区块链配置信息;例如,上述区块链配置信息,可以包括上述目标区块链的访问地址信息,以及上述目标区块链相关的配置信息,等等。中心化管控平台在收到上述注册请求后,可以获取该注册请求中携带的上述区块链配置信息,然 后基于获取到的区块链配置信息针对上述目标区块链执行后续的注册处理流程。
中心化管控平台在收到上述注册请求后,可以将从注册请求中读取到的与目标区块链相关的区块链配置信息,作为成员区块链的配置信息,在本地的数据库中进行存储。
例如,在实现时,中心化管控平台可以维护一个用于存储上述区块链服务网络中的各个成员区块链相关的区块链配置信息的信息库,中心化管控平台可以将从上述注册请求中读取到目标区块链相关的区块链配置信息,作为成员区块链的区块链配置信息存储至该信息库中。
中心化管控平台在将与目标区块链相关的区块链配置信息,作为成员区块链的配置信息,在本地的数据库中进行存储之后,还可以进一步基于从注册请求中读取到的上述目标区块链的访问地址信息,与目标区块链中的至少部分节点设备建立通信连接。
例如,如前所述,上述访问地址信息具体可以包括上述目标区块链中的一个或者多个节点设备对应的域名信息或者IP地址信息,中心化管控平台可以基于上述域名信息或者IP地址信息,与上述目标区块链中的一个或者多个节点设备之间建立通信连接。其中,在实现时,中心化管控平台可以与上述目标区块链中的所有节点设备均建立通信连接,也可以仅与上述目标区块链中的部分关键的节点设备(比如存储完整的区块链账本的全节点)建立通信连接。
步骤304,基于所述通信连接从目标区块链中的节点设备处获取所述目标区块链相关的区块链数据。
中心化管控平台在与目标区块链中的至少部分节点设备建立了通信连接之后,可以继续基于该通信连接,从目标区块链中的节点设备处获取该目标区块链相关的区块链数据。
其中,从目标区块链中的节点设备处获取到的该目标区块链相关的区块链数据,具体可以包括与该目标区块链相关的任意形式的数据,在本说明书中不进行特别限定;
例如,在一个例子中,从目标区块链中的节点设备处获取到的该目标区块链相关的区块链数据,具体可以包括该目标区块链完整的区块链账本、与该目标区块链的区块链账本对应的认证根数据、以及该目标区块链中的各个节点设备的公钥数据,等等。
其中,需要说明的是,在区块链领域,与区块链账本对应的认证根数据,通常可以包括区块链账本中的创世块数据、各个区块的区块头数据等,可以用于对该区块链账本中存储的数据进行认证的数据。
在从目标区块链中的节点设备处获取到该目标区块链相关的区块链数据之后,中心化管控平台可以在数据库中存储获取到的区块链数据。
例如,如前所述,中心化管控平台可以维护一个用于存储上述区块链服务网络中的各个成员区块链相关的区块链配置信息的信息库,中心化管控平台可以将从上述注册请求中读取到目标区块链相关的区块链配置信息,作为成员区块链的区块链配置信息存储至该信息库中。而中心化管控平台在从目标区块链中的节点设备处获取到该目标区块链相关的区块链数据之后,也可以将获取到的区块链数据,在上述信息库中与上述目标区块链相关的区块链配置信息进行关联存储。
步骤305,在所述目标区块链上创建与所述中心化管控平台对应的区块链账户。
中心化管控平台基于上述通信连接从目标区块链中的节点设备处获取所述目标区块链相关的区块链数据之后,还可以继续在上述目标区块链上,为中心化管控平台创建一个对应的区块链账户。其中,创建上述区块链账户的具体过程不再赘述。
当在上述目标区块链上为中心化管控平台创建了对应的区块链账户之后,此时该中心化管控平台已取得该目标区块链中合法的用户身份,并已经具有调用上述目标区块链上部署的用户智能合约的能力,后续中心化管控平台可以基于该区块链账户来发起针对该目标区块链上部署的用户智能合约的合约调用。
其中,在上述中心化管控平台上,具体可以维护一个区块链账户列表。该区块链账户列表中具体可以包含在各个成员区块链上创建的上述中心化管控平台对应的区块链账户。当在上述目标区块链上为中心化管控平台创建了对应的区块链账户之后,可以将该区块链账户添加至上述区块链账户列表中进行维护。
需要说明的是,在各个成员区块链上创建的上述中心化管控平台对应的区块链账户具体可以相同,也可以不相同。例如,在一个例子中,为了便于进行账户管理,在各个成员区块链上创建的上述中心化管控平台对应的区块链账户,默认可以采用同一个预设的区块链账户。比如,在实现时,各个成员区块链均可以将某一个固定的区块链账户提前进行预留,作为与中心化管控平台对应的区块链账户。
步骤306,在目标区块链中部署至少一个系统智能合约。
当在上述目标区块链上,为中心化管控平台创建一个对应的区块链账户之后,中心化管控平台还可以继续在该目标区块链中部署至少一个系统智能合约。上述至少一个系统智能合约具体可以包括用于与其它成员区块链进行跨链通信的目标系统智能合约。
其中,上述至少一个系统智能合约除了可以包括用于与其它成员区块链进行跨链通信的目标系统智能合约之外,还可以包括用于对目标区块链进行服务管理的智能合约,用于对目标区块链网络进行网络治理的系统智能合约、用于对在中心化管控平台上注册的用户服务相关的用户进行服务激励的系统智能合约,等等,在本说明书中不进行特别限定。
当然,在实际应用中,具体也可以将以上提到的用于与其它成员区块链进行跨链通信的目标系统智能合约,用于对目标区块链进行服务管理的智能合约,用于对目标区块链网络进行网络治理的系统智能合约、用于对在中心化管控平台上注册的用户服务相关的用户进行服务激励的系统智能合约等,整合成一个系统智能合约。
例如,在实际应用中,可以将用于与其它成员区块链进行跨链通信的跨链调用逻辑,用于对目标区块链进行服务管理的服务管理逻辑,用于对目标区块链网络进行网络治理的网络治理逻辑,用于对在中心化管控平台上注册的用户服务相关的用户进行服务激励的服务激励逻辑,包含在同一个系统智能合约中。
需要说明的是,上述系统智能合约与上述目标区块链上部署的用户智能合约,是两类完全不同的智能合约。
上述系统智能合约包含的合约执行逻辑,通常是与中心化管控平台上的一些管理功能相关执行逻辑。
例如,如前所述的进行网络治理的系统智能合约所包含的合约执行逻辑,可以是与中心化管控平台对上述区块链服务网络进行网络治理的功能相关的执行逻辑;相应的,如前所述的用于对在中心化管控平台上注册的用户服务相关的用户进行服务激励的系统智能合约所包含的合约执行逻辑,可以是与中心化管控平台对注册的用户服务相关的用户进行服务激励的功能相关的执行逻辑。而上述用户智能合约包含的合约执行逻辑,通常与用户在成员区块链上定义的用户服务逻辑相关。
通过在上述目标区块链上部署至少一个系统智能合约,使得上述目标区块链上的用户,也可以通过调用上述目标区块链上部署的系统智能合约的方式,在上述目标区块链上来完成一些与上述中心化管控平台上的管理功能相关的操作。
步骤307,向所述注册方返回与所述目标区块链对应的成功注册消息。
当中心化管控平台针对上述目标区块链执行了如步骤302-步骤306示出的各项注册处理流程后,此时上述目标区块链将作为成员区块链,成功的加入到上述区块链服务网络。
在这种情况下,上述中心化管控平台向上述注册方返回与上述目标区块链对应的成功注册消息,以通知上述注册方该目标区块链已经作为成员区块链,成功的加入到了上述区块链服务网络。
其中,需要说明的是,以上实施例中步骤302-步骤306示出的各项注册处理流程的先后顺序仅为示意性的,在本说明书中不进行特别的限定。可以理解的是,在实际应用中,以上实施例中步骤302-步骤306示出的各项注册处理流程的先后顺序,可以基于实际的注册需求进行灵活的调整和互换。
在本说明书中,在上述区块链服务网络中的各成员区块链上,均可以部署若干用户智能合约。其中,这些用户智能合约中的合约代码对应的合约执行逻辑,通常可以包括分别对应不同的基础服务能力的多个合约执行逻辑。
例如,在实际应用中,智能合约中包含的合约执行逻辑,通常可以是函数的形式,一个智能合约中 则可以包含分别对应不同的服务功能的多个函数。
而上述中心化管控平台,还可以支持对上述区块链服务网络中的至少部分成员区块链上部署的用户智能合约所包含的合约执行逻辑进行服务化的功能。相应的,服务提供方可以通过上述中心化管控平台支持的上述功能,针对至少部分成员区块链上部署的用户智能合约所包含的合约执行逻辑进行服务化,然后将其以用户服务的形式开放给服务使用方,供服务使用方进行调用。
需要说明的是,在对区块链服务网络中的至少部分成员区块链上的用户智能合约所包含的合约执行逻辑进行服务化时,具体可以针对某一用户智能合约所包含的某一特定的合约执行逻辑进行服务化,也可以针对多个合约执行逻辑进行组合后整体进行服务化。
也即,通过服务化产生的用户服务,具体可以是指部署在区块链服务网络中的各成员区块链上的某一用户智能合约所包含的某一特定的合约执行逻辑构成的服务,也可以是指部署在区块链服务网络中的至少部分成员区块链上的用户智能合约所包含的多个合约执行逻辑进行组合后生成的服务。
例如,在一个例子中,假设某一用户在某一成员区块链上部署了一个用户智能合约,该用户智能合约包含多个合约执行逻辑,在这种情况下,该用户可以选择针对该用户智能合约包含的某一特定的合约执行逻辑进行服务化,在上述中心化管控平台上注册一个与该合约执行逻辑绑定的用户服务,开放给其他用户,供其他用户进行调用。
在另一个例子中,假设某一用户在各成员区块链上部署了多个用户智能合约,或者该用户具有其他用户在各成员区块链上部署的多个用户智能合约的访问权限,在这种情况下,该用户可以选择将上述多个用户智能合约中包含的多个合约执行逻辑组合成用户服务,并在上述中心化管控平台上注册一个与上述多个合约执行逻辑绑定的用户服务,开放给其他用户,供其他用户进行调用。
其中,在将上述多个合约执行逻辑进行组合之后进行服务化时,具体可以将分布在多个不同的成员区块链上的用户智能合约所包含的合约执行逻辑,组合生成一个用户服务之后进行服务化,也可以将同一个成员区块链中的多个用户智能合约所包含的合约执行逻辑;或者,将同一个成员区块链中的同一个用户智能合约所包含的多个合约执行逻辑组合生成一个服务之后进行服务化,在本说明书中不进行特别限定。
需要说明的是,在将多个合约执行逻辑进行组合时,还可以将该多个合约执行逻辑,按照一定的逻辑顺序,进行组合。而上述逻辑顺序,通常取决于服务使用方具体的服务需求,在实际应用中,可以基于实际的服务需求来灵活的确定。
在本说明书中,在对合约执行逻辑进行服务化时,仍然可以采用在上述中心化管控平台上注册用户服务,并将注册的用户服务与需要进行服务化的合约执行逻辑进行绑定的方式来完成。
也即,服务提供方具体可以通过向中心化管控平台发起服务注册,为需要进行服务化的合约执行逻辑注册对应的用户服务,再将该用户服务与上述合约执行逻辑进行绑定,以完成针对该合约执行逻辑的服务化。
需要说明的是,服务提供方向中心化管控平台发起服务注册的具体过程,在本说明书中不再进行详述,本领域技术人员可以参考相关技术中的记载。
其中,为了避免将需要服务化的合约执行逻辑相关的信息暴露给服务使用方,在将注册的该用户服务与合约执行逻辑进行绑定时,可以不再采用将该用户服务直接与该合约执行逻辑进行绑定的方式,而是可以在中心化管控平台上为注册的该用户服务设置服务接口,将该用户服务的服务接口与合约执行逻辑进行绑定。其中,需要说明的是,上述服务接口,具体可以是一个能够唯一标识该用户服务的服务标识。为上述用户服务设置的服务接口的数量,可以是一个也可以是多个,在本说明书中不进行特别限定。
在示出的一种实施方式中,以上述用户服务是由多个合约执行逻辑进行组合后生成的服务为例,在这种情况下,在为该用户服务设置服务接口时,具体可以将该用户服务拆分为分别对应不同服务功能的多个子服务,并为各个每个子服务分别设置对应的服务接口,然后再为每个服务接口绑定相应的合约执行逻辑。
其中,为了提升各个子服务的服务稳定性,在为各个子服务的服务接口绑定合约执行逻辑时,具体还可以为这些服务接口中的至少部分服务接口绑定具有相同的服务功能的多个合约执行逻辑。而服务使用方在调用该子服务时,具体可以基于一定的调度策略,从该子服务绑定的多个合约执行逻辑中,为服务使用方分配一个目标合约执行逻辑,面向该服务调用方提供服务。
例如,请参见图4,图4为本说明书示出的一种为用户服务设置服务接口,并为服务接口绑定合约执行逻辑的示意图。
如图4所示,图4示出的需要进行服务化的为合约实例1-7,这些合约实例分别隶属于成员区块链A、B和C上部署的用户智能合约。其中,合约实例是指用户智能合约中包含的合约执行逻辑;比如,可以是用户智能合约中包含的可执行的函数。
其中,图4示出的服务A,可以按照服务功能拆分为子服务1和子服务2。为子服务1设置的服务接口为a1,该服务接口a1绑定了两个具有相同的服务功能的合约实例1和2。为子服务2设置的服务接口为a2,该服务接口a2只绑定了一个合约实例3。
图4示出的服务B,可以按照服务功能拆分为子服务3、子服4和子服务5。为子服务3设置的服务接口为b1,该服务接口b1只绑定了一个合约实例1。为子服务4设置的服务接口为b2,该服务接口b2绑定了两个具有相同的服务功能的合约实例4和5。为子服务5设置的服务接口为b3,该服务接口b3绑定了两个具有相同的服务功能的合约实例3和6。
图4示出的服务C,可以不进行子服务的拆分,为该服务C设置的服务接口为C1,该服务接口C1只绑定了一个合约实例7。
如图4可知,在实际应用中,对于由多个合约执行逻辑组合生成的用户服务,具体可以为该用户服务,设置多个服务接口,并为至少部分服务接口绑定具有相同功能的多个合约执行逻辑。
在本说明书中,当服务提供方在上述中心化管控平台上注册一个用户服务,并为该用户服务绑定了需要服务化的合约执行逻辑之后,中心化管控平台可以将该目标用户服务作为标准化的服务进行服务部署,以开放给服务使用方进行调用。
需要说明的是,上述中心化管控平台在部署注册完成的上述用户服务时,具体可以采用分布式部署的方式。
其中,所谓分布式的部署,具体是指将上述用户服务以系统智能合约的形式,分布式部署在各成员区块链上,以供服务使用方调用。
一方面,由于组成上述用户服务的合约调用逻辑,可能包括分布于多个成员区块链上部署的多个用户智能合约所包含的合约执行逻辑,则服务使用方在调用上述用户服务时,可能也需要跨链调用分布在多个成员区块链上的多个用户智能合约;因此,上述中心化管控平台在部署上述用户服务时,具体可以为该用户服务开发对应的跨链调用逻辑,然后将该跨链调用逻辑作为系统智能合约中的合约执行逻辑,部署在各成员区块链上。
例如,如前所述,上述系统智能合约包含的合约执行逻辑,通常是与中心化管控平台上的一些管理功能相关执行逻辑。因此,通过这种方式,相当于是将为该用户服务开发的跨链调用逻辑,也作为中心化管控平台上的一些管理功能相关执行逻辑的一部分,以系统智能合约的形式,部署在各成员区块链上。
除之之外,在对该用户服务进行服务部署时,还可以将该用户服务的服务接口与合约执行逻辑的绑定关系,作为该用户服务的服务配置信息,也存储至上述系统智能合约,由上述系统智能合约来进行维护。
另一方面,为了方便将服务提供方注册的用户服务,开放给服务使用方进行服务调用,上述中心化管控平台在部署上述用户服务时,还可以为该用户服务开发对应的服务注册逻辑;然后将该服务注册逻辑作为系统智能合约中的合约执行逻辑,部署在各成员区块链上。通过这种方式,相当于是将为该用户服务开发的使用注册逻辑,也作为中心化管控平台上的一些管理功能相关执行逻辑的一部分,以系统智能合约的形式,部署在各成员区块链上。
请参见图5,图5是本说明书根据一示例性实施例示出的一种服务的使用注册方法的流程图,该方法应用于图1所示的任一目标成员区块链中的节点设备;其中,上述区块链网络中的各成员区块链上,分别部署了上述系统智能合约;上述系统智能合约包含与上述用户服务对应的服务注册逻辑;所述方法包括:
步骤502:获取服务使用方针对所述用户服务的使用注册数据;其中,所述用户服务的服务接口绑定了部署在其它成员区块链上的用户智能合约所包含的合约执行逻辑;
当服务提供方在上述中心化管控平台上注册的用户服务,以系统智能合约的形式分布式的部署在上述区块链服务网络中的各成员区块链之后,服务使用方可以通过向其接入的目标成员区块链中的节点设备,提交针对该用户服务的使用注册数据,来发起针对上述系统智能合约的合约调用,来取得该用户服务的服务调用权限。
其中,需要说明的是,上述服务使用方,具体可以是一个在该目标成员区块链上注册了用户账户的用户,也可以是该目标成员区块链上部署的一个用户智能合约,在本说明书中不进行特别限定。
在示出的一种实施方式中,如果上述服务使用方是一个在该目标成员区块链上注册了用户账户的用户,此时上述调用数据具体可以是该用户通过接入该目标成员区块链的用户客户端,打包的一笔针对上述系统智能合约的智能合约调用交易。
该用户客户端可以将打包完成的该智能合约调用交易,作为上述调用数据提交给该目标成员区块链中的节点设备,发起针对上述系统智能合约包含的上述跨链调用逻辑的合约调用,以触发该目标成员区块链中的节点设备分布式的执行该系统智能合约中包含的上述跨链调用逻辑,来取得该用户服务的服务调用权限。
当然,在实际应用中,该用户也可以通过上述用户客户端将针对上述系统智能合约的智能合约的调用数据,提交至与上述目标成员区块链对应的Baas平台,再由该Baas平台将上述调用数据打包成针对上述系统智能合约的合约调用交易,提交给该目标成员区块链中的节点设备。
在示出的另一种实施方式中,如果上述服务使用方是该目标成员区块链上部署的一个用户智能合约,则该用户智能合约可以包含一个引用了上述用户服务的服务接口的合约执行逻辑。
在合约执行逻辑中引用该用户服务的服务接口,通常是指在该合约执行逻辑对应的合约代码中,引用上述用户服务的服务接口,使得用户在调用该合约代码时,该合约代码在执行的过程中,可以进一步的基于引用的服务接口,发起针对该服务接口对应的用户服务的服务调用。当用户在发起针对该用户智能合约包含的该合约执行逻辑的合约调用时,该用户智能合约可以基于该合约执行逻辑引用的服务接口,进一步发起针对该合约执行逻辑引用的服务接口对应的用户服务的服务调用。
其中,由于上述用户服务是以系统智能合约的形式进行了分布式的部署,因此该用户智能合约发起的针对所引用的上述用户服务的服务调用的过程,实际上是该用户智能合约发起的与上述系统智能合约之间的相互调用过程。
而智能合约之间的相互调用,通常采用的是消息调用的机制。因此,在实际应用中,上述调用数据具体可以是用户在调用该用户智能合约所包含的引用了上述用户服务的合约执行逻辑时,由该用户智能合约基于智能合约之间的消息调用机制,生成的一个针对上述系统智能合约的调用消息。
在这种情况下,当用户在发起针对该用户智能合约包含的该合约执行逻辑的合约调用时,该用户智能合约具体可以基于智能合约之间的消息调用机制,生成一个针对上述系统智能合约的调用消息。
然后,再将该调用消息作为针对上述用户服务的调用数据,提交给上述系统智能合约,发起针对上述系统智能合约的合约调用,以触发区块链中的节点设备分布式的执行该系统智能合约中包含的上述使用注册逻辑,来取得上述用户服务的服务调用权限。
其中,关于智能合约之间采用消息调用的机制来进行相互调用的过程,在本说明书中不再进行详述,本领域技术人员在将本说明书记载的技术方案付诸实现时,可以参考相关技术中的记载。
需要说明的是,上述调用消息,具体可以是适宜在智能合约之间进行传递的任意形式的数据,在本 说明书中不进行特别限定。
例如,在一个例子中,上述调用消息具体可以是基于智能合约采用的开发语言定义的,适宜在智能合约之间进行传递的可执行指令。比如,以智能合约中的合约代码采用高级开发语言solidity为例,上述调用消息具体可以是一条针对上述系统智能合约的call指令。
步骤504:响应于所述使用注册数据,调用所述系统智能合约包含的所述服务注册逻辑,从与所述服务接口绑定的合约执行逻辑中,为所述服务使用方确定目标合约执行逻辑,并将所述目标合约执行逻辑相关的服务调用权限授权给所述服务使用方;
在本说明书中,在上述使用注册数据中,具体可以携带上述用户服务对应的服务接口。
其中,需要说明的是,如果上述用户服务是由多个合约执行逻辑进行组合后生成的服务,该用户服务可能会包括多个服务接口,每一个服务接口都对应该用户服务中的一种子服务。
在这种情况下,服务使用方可以选择对该用户服务中的某一项或者多项子服务进行使用注册。相应的,在上述使用注册数据中,也可以携带服务使用方从该多个服务接口中选择出的需要进行使用注册的某一个或者多个服务接口。
上述目标成员区块链中的节点设备在获取到上述服务使用方提交的上述使用注册数据之后,可以响应该使用注册数据,进一步调用上述系统智能合约包含的上述服务注册逻辑,获取上述使用注册数据中携带的服务接口,并从与该服务接口绑定的合约执行逻辑中,为该服务使用方确定目标合约执行逻辑。
在示出的一种实施方式中,由于该用户服务可能会包括多个服务接口,并且每一个服务接口还可能会绑定多个合约执行逻辑,因此上述目标成员区块链中的节点设备在调用上述系统智能合约包含的上述使用注册逻辑,获取到上述调用数据中携带的服务接口之后,可以先确定该服务接口是否绑定了多个合约执行逻辑;
例如,在一个例子中,服务提供方通过中心化管控平台注册了用户服务之后,中心化管控平台可以将为该用户服务分配的服务接口,与需要进行服务化的合约执行逻辑之间的绑定关系,也维护到上述系统智能合约中,从而上述系统智能合约可以通过查询维护的上述绑定关系,来明确上述使用注册数据中携带的服务接口,是否绑定了多个合约执行逻辑。
如果确定该服务接口绑定了多个合约执行逻辑,此时上述系统智能合约可以基于预设的调度策略,从该服务接口绑定的多个合约执行逻辑中,为上述服务使用方动态分配一个面向该服务使用方提供服务的目标合约执行逻辑。
通过这种方式,由于服务使用方在通过调用系统智能合约包含的服务注册逻辑,来请求取得该用户服务的服务调用权限时,最终请求到服务调用权限的合约执行逻辑,是由系统智能合约从与该服务接口绑定的合约执行逻辑中动态确定出的;因此,通过这种方式,可以提升用户在对上述用户服务进行使用注册时的灵活性。
而且,对于服务使用方来说,并不能提前感知到自身请求到服务权限的合约执行逻辑所在的智能合约,以及该智能合约所在的成员区块链;因此,这种服务使用注册的方式,将具有较高的隐私性和安全性。
其中,需要说明的是,上述预设的调度策略,具体可以任意形式的用于从该服务接口绑定的多个合约执行逻辑中,为服务使用方动态分配合约执行逻辑的策略,在本说明书中不进行特别限定。在实际应用中,可以基于具体的调度需求,来灵活的设置具体的调度策略。
在示出的一种实施方式中,上述调度策略包括以下示出的任一或者多个的组合:
调度策略一:
从与上述服务接口绑定的多个合约执行逻辑中,为服务使用方随机分配合约执行逻辑的调度策略。
基于这种策略,具体可以从与上述服务接口绑定的多个合约执行逻辑中,为服务使用方随机分配合约执行逻辑,来面向该服务使用方提供服务。
通过这种方式,使得服务使用方,无法提前感知到为自身提供服务的合约调用逻辑,从而可以最大 程度的确保在调用用户服务时的隐私性。
调度策略二:
将与上述服务接口绑定的多个合约执行逻辑中,预先指定的合约执行逻辑,分配给上述服务使用方的调度策略。
基于这种策略,使得服务提供方可以灵活的从与上述服务接口绑定的多个合约执行逻辑中,为服务使用方指定面向该服务使用方提供服务的合约执行逻辑,从而可以提升上述用户服务的服务灵活性。
例如,在实际应用中,针对一些具体的服务使用方,可以从上述多个合约执行逻辑中指定一个固定的合约执行逻辑,为该服务使用方提供服务。
调度策略三:
将与上述服务接口绑定的多个合约执行逻辑中,服务指标符合预设条件的合约执行逻辑,分配给上述服务使用方的调度策略。
基于这种策略,上述中心化管控平台可以实时的统计与上述服务接口绑定的各个合约执行逻辑的服务指标,并将该服务指标存储至上述系统智能合约,由上述系统智能合约进行维护,使得上述系统智能合约可以基于维护的该服务指标,来筛选出该服务指标符合预设条件的合约执行逻辑,分配给服务使用方,从而可以实现针对与上述服务接口绑定的各个合约执行逻辑的精细化管理。
例如,可以基于与上述服务接口绑定的各个合约执行逻辑的服务指标,为服务使用方筛选出一个最适合该服务使用方的合约执行逻辑,面向该服务使用方提供服务。
其中,上述服务指标,具体可以包括能够表征与上述服务接口绑定的合约执行逻辑的使用状况的任意形式的指标,在本说明书中不进行特别限定。相应的,上述预设条件,通常取决于上述服务指标的具体类型,在实际应用中,可以基于具体的服务需求,来灵活的设置。
例如,在一个例子中,上述服务指标具体可以包括由上述合约执行逻辑提供服务的服务使用方的数量。相应的,上述预设条件可以包括与上述服务接口绑定的多个合约执行逻辑中,上述数量最小的合约执行逻辑。
在这种情况下,上述系统智能合约在基于以上描述的调度策略三,从上述服务接口绑定的多个合约执行逻辑中,为上述服务使用方动态分配面向该服务使用方提供服务的合约执行逻辑时,具体可以分别统计由上述多个合约执行逻辑提供服务的服务使用方的数量,然后将该数量最小的合约执行逻辑,作为上述目标合约执行逻辑分配给上述服务使用方。
由于由各个合约执行逻辑提供服务的服务使用方的数量,通常可以理解为各个合约执行逻辑在面向服务使用方提供服务时的服务负载,因此通过这种方式,可以实现上述多个合约执行逻辑的负载均衡。
当然,上述服务指标除了可以包括由上述合约执行逻辑提供服务的服务使用方的数量以外,在实际应用中,还可以包括上述合约执行逻辑面向各个服务提供方提供服务的总时长、提供服务时的调用成功次数、调用成功率、调用失败的次数等服务指标,在本说明书中不再进行一一列举。
除此之外,上述预设条件除了可以包括与上述服务接口绑定的多个合约执行逻辑中,上述数量最小的合约执行逻辑这种条件以外,在实际应用中,还可以包括其他形式的条件,在本说明书中也不再进行一一列举;例如,在一个例子中,上述预设条件还可以包括上述数量低于阈值的合约执行逻辑。
在示出的一种实施方式中,在为上述服务使用方分配面了向上述服务使用方提供服务的合约执行逻辑之后,还可以生成上述服务使用方针对上述用户服务的服务注册信息,并将所述服务注册信息在该系统智能合约中进行存储,以由该系统智能合约对存储的该服务注册信息进行维护。
其中,在上述服务注册信息中,具体可以包括系统智能合约基于上述的调度策略,从与上述服务接口绑定的多个合约执行逻辑中,为服务使用方分配的面向该服务使用方提供服务的目标合约执行逻辑相关的信息;例如,可以是该目标合约执行逻辑对应的标识信息(比如函数名等)。
在本说明书中,当调用上述系统智能合约包含的上述服务注册逻辑,从与该服务接口绑定的合约执行逻辑中,为该服务使用方确定出了面向该服务使用方提供服务的目标合约执行逻辑之后,还可以进一 步将该目标合约执行逻辑相关的调用权限授权给该服务使用方。
在示出的一种实施方式中,具体可以将上述用户服务的调用权限,和与该用户服务的服务接口绑定的合约执行逻辑的调用权限,作为两种独立的权限,分别进行授权。
在这种情况下,将该目标合约执行逻辑相关的调用权限授权给该服务使用方时,具体可以先将该用户服务的服务调用权限授权给所述目标用户智能合约;以及,在将上述目标合约执行逻辑的服务调用权限授权给该服务使用方。
通过这种方式,可以实现针对上述用户服务的精细化管理。例如,在将上述用户服务的服务调用权限授权给上述服务使用方之后,可以针对从与该用户服务绑定的多个合约执行逻辑中为该服务使用方分配的目标合约执行逻辑,再单独授权一次,从而从根本上避免了上述用户服务的服务调用权限,和与该用户服务绑定的合约执行逻辑的调用权限之间的相互影响。
在示出的一种实施方式中,如果上述服务使用方为上述目标成员区块链上部署的用户智能合约,此时在将上述目标合约执行逻辑的服务调用权限授权给该服务使用方时,具体可以采用双向的权限授权方式,除了可以将该目标合约执行逻辑的服务调用权限授权给该用户智能合约以外,还可以将该用户智能合约的调用权限,也相应的授权给上述目标合约执行逻辑。
通过这种方式,一方面,由于该用户智能合约中包含的合约执行逻辑,也可能与另一个用户服务的服务接口绑定;因此,通过采用这种双向的权限授权的方式,可以将该另一个用户服务相关的调用权限,也同步的授权给该目标合约执行逻辑,从而可以避免后续该目标合约执行逻辑具有上述另一个用户服务的调用需求时,再通过以上描述的授权方式,来重复的进行授权。
另一方面,由于采用这种双向的权限授权的方式,可以让上述目标合约执行逻辑同步的取得上述该用户智能合约中包含的合约执行逻辑的调用权限;因此,对于该目标合约执行逻辑来说,可以通过回调该作为服务调用方的用户智能合约,及时的将作为服务使用方的该用户智能合约针对上述用户服务的服务调用结果,返回给该作为服务调用方的用户智能合约,而不再需要采用异步返回服务调用结果的方式,从而可以提升针对上述用户服务进行服务调用时的服务调用效率。
请参见图6,图6是本说明书根据一示例性实施例示出的一种智能合约的跨链调用方法的流程图,该方法应用于图1所示的任一目标成员区块链中的节点设备;其中,所述区块链网络中的各成员区块链上,分别部署了上述系统智能合约;上述系统智能合约包含与所述用户服务对应的跨链调用逻辑;所述方法包括:
步骤602:获取服务使用方针对所述用户服务的调用数据;其中,所述用户服务的服务接口绑定了部署在其它成员区块链上的用户智能合约所包含的合约执行逻辑;
当服务提供方在上述中心化管控平台上注册的用户服务,以系统智能合约的形式分布式的部署在上述区块链服务网络中的各成员区块链,并且上述服务使用方完成了针对该用户服务的使用注册之后,该服务使用方可以通过向其接入的目标成员区块链中的节点设备,提交针对该用户服务的调用数据,来发起针对上述系统智能合约的合约调用,以完成该用户服务的服务调用。
在示出的一种实施方式中,如果上述服务使用方是一个在该目标成员区块链上注册了用户账户的用户,此时上述调用数据具体可以是该用户通过接入该目标成员区块链的用户客户端打包的一笔针对上述系统智能合约的智能合约调用交易。该用户客户端可以将打包完成的该智能合约调用交易提交给该目标成员区块链中的节点设备,发起针对上述系统智能合约的合约调用,以触发该目标成员区块链中的节点设备分布式的执行该系统智能合约中包含的上述跨链调用逻辑,来完成针对上述用户服务的服务调用。
当然,在实际应用中,该用户也可以通过上述用户客户端将针对上述系统智能合约的智能合约的调用数据提交至与上述目标成员区块链对应的Baas平台,再由该Baas平台将上述调用数据打包成针对上述系统智能合约的合约调用交易,提交给该目标成员区块链中的节点设备。
在示出的另一种实施方式中,如果上述服务使用方是该目标成员区块链上部署的一个用户智能合约,则该用户智能合约可以包含一个引用了上述用户服务的服务接口的合约执行逻辑。当用户在发起针对该 用户智能合约包含的该合约执行逻辑的合约调用时,该用户智能合约具体可以基于智能合约之间的消息调用机制,生成一个针对上述系统智能合约的调用消息。然后,再将该调用消息作为针对上述用户服务的调用数据,提交给上述系统智能合约,发起针对上述系统智能合约的合约调用,以触发区块链中的节点设备分布式的执行该系统智能合约中包含的上述跨链调用逻辑,来完成针对上述用户服务的服务调用。
例如,在一个例子中,上述调用消息具体可以是基于智能合约采用的开发语言定义的,适宜在智能合约之间进行传递的可执行指令。比如,以智能合约中的合约代码采用高级开发语言solidity为例,上述调用消息具体可以是一条针对上述系统智能合约的call指令。
步骤604,响应于所述调用数据,调用所述系统智能合约包含的所述跨链调用逻辑,从与所述服务接口绑定的合约执行逻辑中,为所述服务使用方确定目标合约执行逻辑,并发起针对所述其它成员区块链上部署的包含所述目标合约执行逻辑的用户智能合约的跨链调用。
在本说明书中,在上述调用数据中,具体可以携带上述用户服务对应的服务接口。
其中,需要说明的是,如果上述用户服务是由多个合约执行逻辑进行组合后生成的服务,该用户服务可能会包括多个服务接口,每一个服务接口都对应该用户服务中的一种子服务。
在这种情况下,服务使用方可以选择对该用户服务中的某一项或者多项子服务进行服务调用。相应的,在上述调用数据中,也可以携带服务使用方从该多个服务接口中选择出的需要调用的某一个或者多个服务接口。
上述目标成员区块链中的节点设备在获取到上述服务使用方提交的上述调用数据之后,可以响应该调用数据,进一步调用上述系统智能合约包含的上述跨链调用逻辑,获取上述调用数据中携带的服务接口,并从与该服务接口绑定的合约执行逻辑中,为该服务使用方确定目标合约执行逻辑。
在示出的一种实施方式中,由于该用户服务可能会包括多个服务接口,并且每一个服务接口还可能会绑定多个合约执行逻辑,因此上述目标成员区块链中的节点设备在调用上述系统智能合约包含的上述跨链调用逻辑,获取到上述调用数据中携带的服务接口之后,可以先确定该服务接口是否绑定了多个合约执行逻辑;
例如,在一个例子中,服务提供方通过中心化管控平台注册了用户服务之后,中心化管控平台可以将为该用户服务分配的服务接口,与需要进行服务化的合约执行逻辑之间的绑定关系,也维护到上述系统智能合约中,从而上述系统智能合约可以通过查询维护的上述绑定关系,来明确上述调用数据中携带的服务接口,是否绑定了多个合约执行逻辑。
,如果确定该服务接口绑定了多个合约执行逻辑,此时上述系统智能合约可以基于预设的调度策略,从该服务接口绑定的多个合约执行逻辑中,为上述服务使用方动态分配一个面向该服务使用方提供服务的目标合约执行逻辑。
通过这种方式,由于服务使用方在通过系统智能合约跨链调用与该用户服务的服务接口绑定的合约执行逻辑时,最终调用的=合约执行逻辑,是由系统智能合约从与该服务接口绑定的合约执行逻辑中动态确定出的;因此,通过这种方式,可以提升上述用户服务在被调用时的灵活性。
而且,对于服务使用方来说,并不能提前感知到被调用的该合约执行逻辑所在的智能合约,以及该智能合约所在的成员区块链;因此,这种跨链调用合约的方式,将具有较高的隐私性和安全性。
其中,需要说明的是,上述预设的调度策略,具体可以任意形式的用于从该服务接口绑定的多个合约执行逻辑中,为服务使用方动态分配合约执行逻辑的策略,在本说明书中不进行特别限定。在实际应用中,可以基于具体的调度需求,来灵活的设置具体的调度策略。例如,在本实施例中,上述调度策略,仍然可以包括图5所示的实施例中描述的上述调度策略一、调度策略二、调度策略三中任一或者多个的组合,在本实施例中不再进行赘述。
在示出的一种实施方式中,如前所述,由于上述系统智能合约预先可以维护该服务使用方针对上述用户服务的服务注册信息,并且该服务注册信息可以包括系统智能合约在服务使用方对该用户服务进行使用注册的阶段,基于上述预设的调度策略,从与该用户服务对应的服务接口绑定的多个合约执行逻辑 中,为该服务使用方分配的面向所述服务使用方提供服务的目标合约执行逻辑相关的信息;因此,在这种情况下,上述系统智能合约在从与上述服务接口绑定的合约执行逻辑中,为该服务使用方确定目标合约执行逻辑时,具体可以不再进行实时分配,而是直接获取上述服务注册信息中包括的目标合约执行逻辑相关的信息,然后直接件该目标合约执行逻辑分配给该服务使用方。
通过这种方式,可以在服务使用方调用该用户服务时,优先将该服务使用方在使用注册阶段,为该服务使用方分配的目标合约执行逻辑,分配给该服务使用方,从而可以避免在服务使用方调用该用户服务时重复的为该服务使用方分配合约执行逻辑。
在本说明书中,当调用上述系统智能合约包含的上述跨链调用逻辑,从与该服务接口绑定的合约执行逻辑中,为该服务使用方确定出了面向该服务使用方提供服务的目标合约执行逻辑之后,还可以进一步发起针对其它成员区块链上部署的包含该目标合约执行逻辑的用户智能合约的跨链调用。
在示出的一种实施方式中,如前所述,由于上述服务使用方在针对上述用户服务进行服务使用注册阶段,上述用户服务的调用权限,和与该用户服务的服务接口绑定的合约执行逻辑的调用权限,可以作为两种独立的权限,分别授权给该服务使用方,因此在这种情况下,在调用该系统智能合约包含的所述跨链调用逻辑,从与该服务接口绑定的合约执行逻辑中,为该服务使用方确定目标合约执行逻辑之前,还可以先调用该系统智能合约包含的权限验证逻辑,验证该服务使用方是否具有该用户服务的调用权限;如果是,可以进一步调用该系统智能合约包含的上述跨链调用逻辑,从与该服务接口绑定的合约执行逻辑中,为该服务使用方确定目标合约执行逻辑。
在示出的另一种实施方式中,基于相似的理由,在从与该服务接口绑定的合约执行逻辑中,为该服务使用方确定目标合约执行逻辑之后,在发起针对其它成员区块链上部署的包含所述合约执行逻辑的用户智能合约的跨链调用之后,具体也可以先调用该系统智能合约包含的权限验证逻辑,验证该服务使用方是否具有该目标合约执行逻辑的调用权限;如果是,再发起针对该其它成员区块链上部署的包含该目标合约执行逻辑的用户智能合约的跨链调用。
其中,该系统智能合约发起针对该其它成员区块链上部署的包含该目标合约执行逻辑的用户智能合约的跨链调用的具体方式,仍然可以采用智能合约之间的消息调用机制来完成,在本说明书不再详述。
与前述方法的实施例相对应,本说明书还提供了装置、电子设备以及存储介质的实施例。
图7是一示例性实施例提供的一种电子设备的示意结构图。请参考图7,在硬件层面,该设备包括处理器702、内部总线704、网络接口706、内存708以及非易失性存储器810,当然还可能包括其他业务所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现,比如由处理器702从非易失性存储器710中读取对应的计算机程序到内存708中然后运行。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
如图8所示,图8是本说明书根据一示例性实施例示出的一种服务的使用注册装置的框图,该装置可以应用于如图7所示的电子设备中,以实现本说明书的技术方案。该装置可以应用于由若干成员区块链构成的区块链服务网络中的任一目标成员区块链中的节点设备;其中,所述区块链服务网络中的至少部分成员区块链上部署的用户智能合约所包含的合约执行逻辑,以用户服务的形式开放调用;所述区块链网络中的各成员区块链上,分别部署了系统智能合约;所述系统智能合约包含与所述用户服务对应的服务注册逻辑;所述装置80包括:
获取模块801,获取服务使用方针对所述用户服务的使用注册数据;其中,所述用户服务的服务接口绑定了部署在其它成员区块链上的用户智能合约所包含的合约执行逻辑;
调用模块802,响应于所述使用注册数据,调用所述系统智能合约包含的所述服务注册逻辑,从与所述服务接口绑定的合约执行逻辑中,为所述服务使用方确定目标合约执行逻辑,并将所述目标合约执行逻辑相关的服务调用权限授权给所述服务使用方。
上述装置80的各个模块的具体细节已经在之前描述的方法流程中进行了详细的描述,因此此处不 再赘述。
相应的,本说明书还提供一种电子设备,所述电子设备包括有处理器;用于存储处理器可执行指令的存储器;其中,所述处理器被配置为实现之前描述的全部的方法流程中的步骤。
相应的,本说明书还提供一种计算机可读存储介质,其上存储有可执行的指令;其中,该指令被处理器执行时,实现之前描述的全部的方法流程中的步骤。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (12)

  1. 一种服务的使用注册方法,所述方法应用于由若干成员区块链构成的区块链服务网络中的任一目标成员区块链中的节点设备;其中,所述区块链服务网络中的至少部分成员区块链上部署的用户智能合约所包含的合约执行逻辑,以用户服务的形式开放调用;所述区块链网络中的各成员区块链上,分别部署了系统智能合约;所述系统智能合约包含与所述用户服务对应的服务注册逻辑;
    所述方法包括:
    获取服务使用方针对所述用户服务的使用注册数据;其中,所述用户服务的服务接口绑定了部署在其它成员区块链上的用户智能合约所包含的合约执行逻辑;
    响应于所述使用注册数据,调用所述系统智能合约包含的所述服务注册逻辑,从与所述服务接口绑定的合约执行逻辑中,为所述服务使用方确定目标合约执行逻辑,并将所述目标合约执行逻辑相关的服务调用权限授权给所述服务使用方。
  2. 根据权利要求1所述的方法,所述用户服务包括由部署在所述区块链服务网络中的至少部分成员区块链上的用户智能合约所包含的合约执行逻辑组合生成的服务;所述用户服务包括多个服务接口;其中,不同的服务接口分别对应不同的服务功能;所述多个服务接口中的至少部分服务接口绑定了具有相同的服务功能的多个合约执行逻辑。
  3. 根据权利要求2所述的方法,从与所述服务接口绑定的合约执行逻辑中,为所述服务使用方确定目标合约执行逻辑,包括:
    确定所述服务接口是否绑定了多个合约执行逻辑;如果是,进一步基于预设的调度策略,从与所述服务接口绑定的多个合约执行逻辑中,为所述服务使用方分配面向所述服务使用方提供服务的目标合约执行逻辑。
  4. 根据权利要求3所述的方法,所述方法还包括:
    在为所述服务使用方分配了面向所述服务使用方提供服务的合约执行逻辑之后,生成所述服务使用方针对所述用户服务的服务注册信息,并将所述服务注册信息在所述系统智能合约中进行存储,以由所述系统智能合约对存储的所述服务注册信息进行维护;其中,所述服务注册信息包括所述系统智能合约基于预设的所述调度策略,从与所述服务接口绑定的多个合约执行逻辑中,为所述服务使用方分配的面向所述服务使用方提供服务的所述目标合约执行逻辑。
  5. 根据权利要求3所述的方法,所述调度策略包括以下示出的任一或者多个的组合:
    从与所述服务接口绑定的多个合约执行逻辑中,为所述服务使用方随机分配合约执行逻辑的调度策略;
    将与所述服务接口绑定的多个合约执行逻辑中,预先指定的合约执行逻辑分配给所述服务使用方的调度策略;
    将与所述服务接口绑定的多个合约执行逻辑中,服务指标符合预设条件的合约执行逻辑,分配给所述服务使用方的调度策略。
  6. 根据权利要求5所述的方法,所述服务指标包括由所述合约执行逻辑提供服务的服务使用方的数量;所述预设条件包括与服务接口绑定的多个合约执行逻辑中,所述数量最小的合约执行逻辑。
  7. 根据权利要求2所述的方法,
    所述将所述目标合约执行逻辑相关的服务调用权限授权给所述服务使用方,包括:
    将所述用户服务的服务调用权限授权给所述服务使用方;以及,
    将所述目标合约执行逻辑的服务调用权限授权给所述服务使用方。
  8. 根据权利要求7所述的方法,所述服务使用方包括所述目标成员区块链上部署的用户智能合约;
    将所述目标合约执行逻辑的服务调用权限授权给所述服务使用方,包括:
    将所述目标合约执行逻辑的服务调用权限授权给所述用户智能合约,以及将所述用户智能合约的调用权限授权给所述目标合约执行逻辑。
  9. 根据权利要求8所述的方法,所述用户智能合约包含引用了所述用户服务的服务接口的合约执行逻辑。
  10. 一种智能合约的跨链调用装置,所述装置应用于由若干成员区块链构成的区块链服务网络中的任一目标成员区块链中的节点设备;其中,所述区块链服务网络中的至少部分成员区块链上部署的用户智能合约所包含的合约执行逻辑,以用户服务的形式开放调用;所述区块链网络中的各成员区块链上,分别部署了系统智能合约;所述系统智能合约包含与所述用户服务对应的服务注册逻辑;
    所述装置包括:
    获取模块,获取服务使用方针对所述用户服务的使用注册数据;其中,所述用户服务的服务接口绑定了部署在其它成员区块链上的用户智能合约所包含的合约执行逻辑;
    调用模块,响应于所述使用注册数据,调用所述系统智能合约包含的所述服务注册逻辑,从与所述服务接口绑定的合约执行逻辑中,为所述服务使用方确定目标合约执行逻辑,并将所述目标合约执行逻辑相关的服务调用权限授权给所述服务使用方。
  11. 一种电子设备,包括:
    处理器;
    用于存储处理器可执行指令的存储器;
    其中,所述处理器通过运行所述可执行指令以实现如权利要求1-9中任一项所述的方法。
  12. 一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如权利要求1-9中任一项所述方法的步骤。
PCT/CN2022/135448 2022-09-27 2022-11-30 一种智能合约的跨链调用方法及装置 WO2024066018A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211188911.2 2022-09-27
CN202211188911.2A CN115664718A (zh) 2022-09-27 2022-09-27 一种智能合约的跨链调用方法及装置

Publications (1)

Publication Number Publication Date
WO2024066018A1 true WO2024066018A1 (zh) 2024-04-04

Family

ID=84985874

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135448 WO2024066018A1 (zh) 2022-09-27 2022-11-30 一种智能合约的跨链调用方法及装置

Country Status (2)

Country Link
CN (1) CN115664718A (zh)
WO (1) WO2024066018A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200177519A1 (en) * 2019-07-15 2020-06-04 Alibaba Group Holding Limited Allocating virtual resource based on block chain
CN113542435A (zh) * 2021-09-15 2021-10-22 支付宝(杭州)信息技术有限公司 一种用户服务使用方法及装置
CN113535335A (zh) * 2021-09-15 2021-10-22 支付宝(杭州)信息技术有限公司 基于区块链的虚拟资源分配方法及装置和电子设备
CN113535691A (zh) * 2021-09-15 2021-10-22 支付宝(杭州)信息技术有限公司 一种用户服务注册方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200177519A1 (en) * 2019-07-15 2020-06-04 Alibaba Group Holding Limited Allocating virtual resource based on block chain
CN113542435A (zh) * 2021-09-15 2021-10-22 支付宝(杭州)信息技术有限公司 一种用户服务使用方法及装置
CN113535335A (zh) * 2021-09-15 2021-10-22 支付宝(杭州)信息技术有限公司 基于区块链的虚拟资源分配方法及装置和电子设备
CN113535691A (zh) * 2021-09-15 2021-10-22 支付宝(杭州)信息技术有限公司 一种用户服务注册方法及装置

Also Published As

Publication number Publication date
CN115664718A (zh) 2023-01-31

Similar Documents

Publication Publication Date Title
CN110941679B (zh) 一种合约数据处理方法、相关设备及介质
US10915552B2 (en) Delegating credentials with a blockchain member service
US10027716B2 (en) System and method for supporting web services in a multitenant application server environment
CN112154468A (zh) 基于安全共识的自监控区块链背书
WO2022161181A1 (zh) 基于区块链的数据处理的方法、装置及电子设备
US8291044B2 (en) Brokering network resources
CN110532025B (zh) 基于微服务架构的数据处理方法、装置、设备及存储介质
CN110049048B (zh) 一种政务公共服务的数据访问方法、设备及可读介质
JP2023524659A (ja) 低信頼の特権アクセス管理
CN113535691B (zh) 一种用户服务注册方法及装置
WO2023040496A1 (zh) 基于区块链的虚拟资源分配
CN112350978A (zh) 一种业务处理方法、系统、设备及存储介质
CN113011974A (zh) 基于区块链的交易信息存证方法及系统
WO2023040498A1 (zh) 用户服务使用
CN109711840A (zh) 一种交易数据处理方法、装置及存储介质
CN111641586A (zh) 一种基于区块链的账户权限管理方法和系统
CN111062057B (zh) 一种中立的数据应用方法、装置以及系统
US11861037B2 (en) Unified data fabric for managing data lifecycles and data flows
WO2024066018A1 (zh) 一种智能合约的跨链调用方法及装置
WO2023040450A1 (zh) 区块链服务网络的组建
CN111339208B (zh) 调用智能合约的方法及装置
KR20200065507A (ko) 블록체인의 개인키 권한 조절 시스템 및 그 방법
CN115018499A (zh) 一种基于区块链的数字凭证发行方法、装置和系统
CN115665141A (zh) 一种智能合约的跨链调用方法及装置
CN116126554A (zh) 智能合约的跨链调用方法及装置

Legal Events

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

Ref document number: 22960614

Country of ref document: EP

Kind code of ref document: A1