CN114500119B - Method and device for calling block chain service - Google Patents

Method and device for calling block chain service Download PDF

Info

Publication number
CN114500119B
CN114500119B CN202210395271.6A CN202210395271A CN114500119B CN 114500119 B CN114500119 B CN 114500119B CN 202210395271 A CN202210395271 A CN 202210395271A CN 114500119 B CN114500119 B CN 114500119B
Authority
CN
China
Prior art keywords
calling
data
key
service
block chain
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN202210395271.6A
Other languages
Chinese (zh)
Other versions
CN114500119A (en
Inventor
胡慧潘
朱亮亮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hundsun Technologies Inc
Original Assignee
Hundsun Technologies Inc
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 Hundsun Technologies Inc filed Critical Hundsun Technologies Inc
Priority to CN202210395271.6A priority Critical patent/CN114500119B/en
Publication of CN114500119A publication Critical patent/CN114500119A/en
Application granted granted Critical
Publication of CN114500119B publication Critical patent/CN114500119B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Abstract

One or more embodiments of the present specification provide a method and an apparatus for calling a blockchain service, where the method and apparatus are applied to a server corresponding to a blockchain service deployed on a blockchain; the block chain is also provided with an intelligent contract for managing the calling of the block chain service; the block chain maintains the residual calling times of the user for the block chain service; the method comprises the following steps: receiving calling data aiming at the block chain service, which is sent by a client corresponding to a user; responding to the calling data, calling a verification logic in the intelligent contract, verifying whether the user has the calling authority aiming at the block chain service, and determining whether the residual calling times of the user aiming at the block chain service reaches a preset threshold value; and if the user has the calling authority aiming at the block chain service and the residual calling times do not reach the threshold value, calling the block chain service based on the calling data.

Description

Block chain service calling method and device
Technical Field
One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for invoking blockchain services.
Background
The block chain technology, also called distributed ledger technology, is an emerging technology in which several computing devices participate in "accounting" together, and a complete distributed intelligent database is maintained together. The blockchain technology has been widely applied in many fields due to characteristics of decentralization, openness and transparency, participation of each computing device in database recording, rapid data synchronization between different computing devices, and support of consistent execution of distributed programs.
Disclosure of Invention
One or more embodiments of the present disclosure provide the following:
the present specification provides a method for calling blockchain services, where the method is applied to a server corresponding to a blockchain service deployed on a blockchain; wherein, the blockchain is also deployed with an intelligent contract for managing the calling of the blockchain service; the block chain maintains the residual calling times of the user for the block chain service; the method comprises the following steps:
receiving call data aiming at the block chain service, which is sent by a client corresponding to a user;
responding to the calling data, calling a verification logic in the intelligent contract, verifying whether the user has a calling authority for the block chain service, and determining whether the residual calling times of the user for the block chain service reach a preset threshold value;
and if the user has the calling authority aiming at the block chain service and the residual calling times do not reach the threshold value, calling the block chain service based on the calling data.
The present specification also provides a method for calling a blockchain service, where the method is applied to a user client corresponding to a user; the system comprises a blockchain, a service module and a service module, wherein the blockchain is provided with a blockchain service and an intelligent contract for managing the calling of the blockchain service; the block chain maintains the residual calling times of the user for the block chain service; the method comprises the following steps:
acquiring call data aiming at the block chain service;
sending the calling data to a server corresponding to the block chain service, so that the server responds to the calling data, calls a verification logic in the intelligent contract, verifies whether the user has a calling authority aiming at the block chain service, determines whether the residual calling times of the user aiming at the block chain service reach a preset threshold value, and calls the block chain service based on the calling data if the user has the calling authority aiming at the block chain service and the residual calling times do not reach the threshold value.
The present specification also provides a device for calling blockchain services, where the device is applied to a server corresponding to a blockchain service deployed on a blockchain; wherein, the blockchain is also deployed with an intelligent contract for managing the calling of the blockchain service; the block chain maintains the residual calling times of the user for the block chain service; the device comprises:
the receiving module is used for receiving call data aiming at the block chain service, which is sent by a client corresponding to a user;
the verification module is used for responding to the calling data, calling a verification logic in the intelligent contract, verifying whether the user has the calling authority for the block chain service, and determining whether the residual calling times of the user for the block chain service reach a preset threshold value;
and the calling module is used for calling the block chain service based on the calling data when the user has the calling authority aiming at the block chain service and the residual calling times do not reach the threshold value.
The present specification also provides a device for calling a blockchain service, where the device is applied to a user client corresponding to a user; the block chain is deployed with a block chain service and an intelligent contract for managing the calling of the block chain service; the block chain maintains the residual calling times of the user for the block chain service; the device comprises:
an obtaining module, configured to obtain call data for the blockchain service;
and the calling module is used for sending the calling data to a server corresponding to the block chain service so as to enable the server to respond to the calling data, call a verification logic in the intelligent contract, verify whether the user has the calling authority aiming at the block chain service, determine whether the residual calling frequency of the user aiming at the block chain service reaches a preset threshold value, and call the block chain service based on the calling data if the user has the calling authority aiming at the block chain service and the residual calling frequency does not reach the threshold value.
The present specification also provides an electronic device comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the steps of the method as described in any one of the above by executing the executable instructions.
The present specification also provides a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of the preceding claims.
In the above technical solution, the server corresponding to the blockchain service may invoke a verification logic in the intelligent contract in response to the received invocation data for the blockchain service sent by the client corresponding to the user, verify whether the user has an invocation authority for the blockchain service, and determine whether the remaining invocation frequency of the user for the blockchain service reaches a preset threshold value, and if the user has the invocation authority for the blockchain service and the remaining invocation frequency does not reach the threshold value, the blockchain service may be invoked based on the invocation data.
By adopting the mode, when the user calls the blockchain service each time, the calling authority and the residual calling times of the user for the blockchain service are verified, and the user is allowed to call the blockchain service this time under the condition that the verification is passed, so that a service provider of the blockchain service can charge the user according to the condition that the user actually calls the blockchain service, and the user experience is improved. In addition, the verification of the calling authority and the residual calling times of the user for the blockchain service does not relate to the user identity, so that the service provider can charge the user no matter whether the user anonymously calls the blockchain service, and the benefit of the service provider is guaranteed.
Drawings
Fig. 1 is a schematic diagram of a network environment associated with a blockchain according to an exemplary embodiment of the present disclosure.
Fig. 2 is a flowchart illustrating a method for invoking a blockchain service according to an exemplary embodiment of the present disclosure.
Fig. 3 is a flowchart illustrating a method for call authorization of a blockchain service according to an exemplary embodiment of the present disclosure.
Fig. 4 is a diagram illustrating data interaction in an authorization process according to an exemplary embodiment of the present specification.
Fig. 5 is a flowchart illustrating a call verification method for a blockchain service according to an exemplary embodiment of the present disclosure.
FIG. 6 is a diagram illustrating data interaction during a verification process, according to an exemplary embodiment of the present description.
Fig. 7 is a diagram illustrating another method for calling a blockchain service according to an exemplary embodiment of the present specification.
Fig. 8 is a hardware structure diagram of an electronic device where a calling apparatus of a blockchain service is located according to an exemplary embodiment of the present specification.
Fig. 9 is a block diagram illustrating an apparatus for invoking a blockchain service according to an exemplary embodiment of the present disclosure.
Fig. 10 is a block diagram illustrating another apparatus for invoking a blockchain service according to an exemplary embodiment of the present disclosure.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.
It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the methods may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.
Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain), and federation chain (Consortium Blockchain). In addition, there may be various combinations of the above, such as a combination of a private chain and a federation chain, a combination of a federation chain and a public chain, and so on.
Of the three types of blockchains described above, the most decentralized is the public chain. A party joining the public chain (which may also be referred to as a node in the blockchain) may read the data records on the chain, participate in transactions, compete for accounting rights for new blocks, etc. Moreover, each node can freely join or leave the network and perform related operations.
Private chains are the opposite, with the network's write rights being controlled by an organization or organization and the data read rights being specified by the organization. That is, the private chain can be viewed as a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a particular establishment.
The alliance chain is between the public chain and the private chain, and partial decentralization can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; the nodes are authorized to join the network and form a benefit-related alliance, and the operation of the block chain is maintained together.
In a blockchain network, nodes are logical communication entities; the different types of block chain nodes can run on the same physical server or different physical servers.
Referring to fig. 1, fig. 1 is a schematic diagram illustrating a network environment associated with a blockchain according to an exemplary embodiment of the present disclosure.
In the network environment as shown in fig. 1, a user-side computing device 101, a server-side 102, and at least one blockchain system may be included; such as blockchain system 103, blockchain system 104, and blockchain system 105.
In one embodiment shown, the user-side computing device 101, may include a variety of different types of user-side computing devices; for example, the user-side computing device may include devices such as PC computing devices, mobile computing devices, internet of things devices, and other forms of smart devices with certain computing capabilities, among others.
It should be noted that the user-side computing device 101 does not mean that all the user-side computing devices are in the same communication network, but is merely a general term for the user-side computing devices.
In one embodiment shown, some of the user-side computing devices 101 may be coupled to the server-side 102 through various communication networks; for example, device 1 and device 2 are coupled to server side 102.
Some of the user-side computing devices 101 may also be not coupled to the server 102, but directly coupled to the blockchain system as blockchain link points; for example, the device 3 may be directly coupled to the blockchain system 103 as a blockchain link point.
In one embodiment shown, the user-side computing device 101, may also include one or more user-side servers; for example, device 4 and device 5. Some of the user-side computing devices 101 may be coupled to the user-side server; for example, device 1 is coupled to device 4 and device 2 is coupled to device 5. The user-side server may be further coupled to the blockchain system as a blockchain link point, or may be further coupled to the server 102 through various communication networks; for example, the device 4 may be further coupled directly to the blockchain system as blockchain link points, and the device 5 is further coupled to the server side 102.
In an embodiment shown, the user-side server may be implemented by a service entity that builds a user account system; the service entities may include an operator entity that provides service bearers for various online and/or offline services to the user. Correspondingly, the operation entity may include an operator corresponding to the service bearer; for example, the operation entity may include an individual, an organization, a company, an enterprise, and the like that operate and manage the service carrier.
In one embodiment shown, the server side 102 may also be coupled to one or more blockchain systems through various communication networks; for example, the server side 102 is respectively coupled to the blockchain system 103, the blockchain system 104, and the blockchain system 105, and so on.
In one illustrated embodiment, the communication network may include wired and/or wireless communication networks; for example, it may be a Local Area Network (LAN), Wide Area Network (WAN), internet or a combination thereof implemented based on a wired access Network or a wireless access Network provided by an operator, such as a mobile cellular Network.
In one embodiment, each blockchain system may maintain one or more blockchains (e.g., public blockchains, private blockchains, federation blockchains, etc.) and include a plurality of blockchain nodes for carrying the one or more blockchains; for example, a block chain node 1, a block link point 2, a block link point 3, a block link point 4, a block link point i, etc., as shown in fig. 1, may collectively carry one or more block chains. And cross-chain data access can be performed among the blockchains contained in each blockchain system and among the blockchain systems.
In one embodiment shown, the block link points may be physical devices, or may be virtual devices implemented in a server or a server cluster; for example, the block link point may be one physical host in the server cluster, or may be a virtual machine created by virtualizing hardware resources mounted on the server or the server cluster based on a virtualization technology. Each blockchain node may be coupled together by various types of communication methods (e.g., TCP/IP, etc.) to form a network to carry one or more blockchains.
In one illustrated embodiment, the server 102 may include a BaaS platform (also referred to as a BaaS cloud) for providing a Blockchain Service (BaaS).
The BaaS platform may provide blockchain services to user-side computing devices coupled to the BaaS platform by providing pre-written software for activities that occur on the blockchain (such as subscriptions and notifications, user authentication, database management, and remote updates).
For example, a BaaS platform may provide software such as MQ (Message Queue) services; the user side computing equipment coupled with the BaaS platform can subscribe an intelligent contract deployed on a certain blockchain in a blockchain system coupled with the BaaS platform and generate a contract event on the blockchain after triggering execution; and the BaaS platform can monitor the event generated on the block chain after the intelligent contract is triggered to be executed, and then based on software related to MQ service, the contract event is added to the message queue in the form of notification message, so that the user side computing equipment subscribing the message queue can obtain the notification related to the contract event.
For data generated outside the blockchain, it can be constructed into a standard transaction (transaction) format supported by the blockchain and then published to the blockchain, with all nodes in the blockchain network agreeing on the transaction. After the consensus is reached, the transaction can be persisted in the blockchain by a node in the blockchain network as an accounting node.
In practical applications, whether public, private, or alliance, may provide the functionality of a smart contract (smart contract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.
The intelligent contracts may be executed independently by each node in the blockchain network in a prescribed manner, and all execution records and associated data may be saved on the blockchain. Taking a certain blockchain based on an account model as an example, an intelligent contract deployed on the blockchain is a type of blockchain account, and after a certain intelligent contract is executed, an execution record and related data can be saved in an account storage space (usually, a storage field) of the intelligent contract.
The event mechanism of the intelligent contract is a mode for the interaction between the intelligent contract and the out-of-chain entity. For intelligent contracts deployed on blockchains, direct interaction with out-of-chain entities is generally not possible; for example, the intelligent contract cannot generally send the invocation result of the intelligent contract to the invocation initiator of the intelligent contract point-to-point after the invocation is completed.
The call results (including intermediate results and final call results) generated by the intelligent contract during the call are usually recorded in the form of events (events) to the transaction log (transaction logs) of the transaction that called the intelligent contract, and stored in the memory space of the block link point. And the entity outside the chain which needs to interact with the intelligent contract can acquire the calling result of the intelligent contract by monitoring the transaction log stored in the storage space of the block chain node.
In addition, the service entity can deploy services supporting various functions and available for users to call on the blockchain, so that various functions based on the blockchain can be provided for the users through the services. Such service entities may be referred to as service providers; such services may be referred to as blockchain services. The block chain service can be in the form of an intelligent contract or chain native code; alternatively, the blockchain service may be an integration of intelligent contracts or chain native code on the blockchain, with code deployed on a centralized computing device outside the blockchain; this is not limited by the present description.
Taking a certain blockchain service as an example, the service provider may deploy the blockchain service on the blockchain through the server. The user may invoke the blockchain service through the client, so that the code corresponding to the blockchain service is executed, thereby implementing the function corresponding to the blockchain service based on the blockchain.
Typically, each service provider wishes to be able to charge a certain amount of money to the user who invokes the blockchain service it provides. The charges received may be used to offset the costs of maintaining, upgrading, etc. the blockchain service to ensure that the service provider can provide the blockchain service to the user for a long time.
In the related art, for a blockchain service deployed on a public chain, the public chain provides a function of virtual money, so that a user can further transfer a certain amount of virtual money from a blockchain account of the user to a blockchain account of a service provider of the blockchain service through a client as a charge for calling the blockchain service each time the blockchain service is called through the client. However, virtual currency is not recognized in many cases today, and cannot be equated with real currency, which does not offset the cost of service providers for blockchain services.
For the blockchain service deployed on the federation chain, different from the situation that each node in a public chain can freely join or leave the network, the node in the federation chain can join the network only after authorization, so that in the public chain, a user can join a client as a node in the public chain and call the blockchain service deployed on the public chain with the identity of an anonymous user, and in the federation chain, the user cannot anonymously join the client as a node in the federation chain but can call the blockchain service anonymously based on the confused identity. However, in the case where the user anonymously invokes the blockchain service, the service provider cannot charge for the case where the user actually invokes the blockchain service because the actual identity of the user cannot be known.
In order to solve the above problem, a service provider may reasonably charge a user according to a situation that the user actually calls a blockchain service, so as to improve user experience, the present specification provides a technical scheme for calling a blockchain service.
In the above technical solution, the server corresponding to the blockchain service may invoke a verification logic in the intelligent contract in response to the received invocation data for the blockchain service sent by the client corresponding to the user, verify whether the user has an invocation authority for the blockchain service, and determine whether the remaining invocation frequency of the user for the blockchain service reaches a preset threshold value, and if the user has the invocation authority for the blockchain service and the remaining invocation frequency does not reach the threshold value, the blockchain service may be invoked based on the invocation data.
By adopting the mode, when the user calls the blockchain service each time, the calling authority and the residual calling times of the user for the blockchain service are verified, and the user is allowed to call the blockchain service this time under the condition that the verification is passed, so that a service provider of the blockchain service can charge the user according to the condition that the user actually calls the blockchain service, and the user experience is improved. In addition, the verification of the calling authority and the residual calling times of the user for the blockchain service does not relate to the user identity, so that the service provider can charge the user no matter whether the user anonymously calls the blockchain service, and the benefit of the service provider is guaranteed.
Referring to fig. 2, fig. 2 is a schematic diagram illustrating a method for calling a blockchain service according to an exemplary embodiment of the present disclosure.
In this embodiment, the method for calling the blockchain service may be applied to a server corresponding to any blockchain service deployed on the blockchain.
In one embodiment shown, the block chain may be a federation chain. In practical application, the blockchain may be a federation chain for judicial evidence preservation, so as to ensure that the data preserved in the federation chain is real and credible; for example, the entity organization or organization corresponding to a node in the federation chain may include a notary or market regulation.
For the blockchain service, on one hand, a user can purchase the calling times of the blockchain service from a service provider of the blockchain service, and the service provider authorizes the calling times to the user, so that the user can call the blockchain service within the calling times. On the other hand, when the user invokes the blockchain service, the user may be verified first to determine whether to subsequently allow the user to invoke the blockchain service.
For the server, the server may include a centralized platform outside the blockchain and a node joining the blockchain; the centralized platform and the block chain node can interact with each other, so that the block chain node calls an intelligent contract deployed on the block chain to realize an authorization process and/or a verification process. Or, the server may directly join the blockchain as a blockchain link point, and implement an authorization process and/or an authentication process by calling an intelligent contract deployed on the blockchain. Furthermore, the server may be coupled to nodes in the blockchain through various communication networks, and interact with the blockchain nodes, so that the blockchain nodes invoke intelligent contracts deployed on the blockchain to implement an authorization process and/or an authentication process.
It should be noted that the authorization process and the verification process may be executed in the same server or in different servers; for example, the authorization process may be performed by a server corresponding to the service provider (i.e., a server controlled by the service provider), and the authentication process may be performed by any server through interaction with the tile link node.
In conjunction with the network environment shown in fig. 1, the server may run on the device 4, the device 5, or the server 102; alternatively, the server may run on the whole formed by the server 102 and the device 5; this is not limited by the present description.
In addition to the blockchain service, an intelligent contract for managing the invocation of the blockchain service may be deployed on the blockchain. Accordingly, the blockchain may also maintain the remaining number of calls the user has made to the blockchain service.
As shown in fig. 2, the method for calling the blockchain service may include the following steps:
step 201: and receiving call data which is sent by a client corresponding to a user and aims at the blockchain service.
In this embodiment, when a user needs to invoke the blockchain service, the user may submit invocation data for the blockchain service to the server through a client corresponding to the user.
In practical applications, the invoking data may include parameters required for invoking the blockchain service, such as: the calling address of the blockchain service, the value of a variable included in the code of the blockchain service, and the like.
Step 202: responding to the calling data, calling a verification logic in the intelligent contract, verifying whether the user has the calling authority for the block chain service, and determining whether the residual calling times of the user for the block chain service reach a preset threshold value.
In this embodiment, the server may respond to the call data to call the intelligent contract when receiving the call data.
It should be noted that, in a case that the server includes a blockchain node or the server serves as a blockchain node, the client may construct the invocation data into a standard transaction format supported by a blockchain, so that the blockchain node may invoke the intelligent contract in response to the invocation data in the transaction format. Alternatively, in the case that the server is coupled to a node in the blockchain, the server may construct the received call data into a standard transaction format supported by the blockchain, so that the blockchain node may call the intelligent contract in response to the call data in the transaction format.
Specifically, a verification logic in the intelligent contract may be invoked to verify whether the user has an invocation authority for the block chain service, and determine whether the remaining invocation frequency of the user for the block chain service reaches a preset threshold; the threshold value may be preset by a technician according to actual needs, or may be a default value (usually 0) by default.
Step 203: and if the user has the calling authority aiming at the block chain service and the residual calling times do not reach the threshold value, calling the block chain service based on the calling data.
In this embodiment, when it is verified that the user has the right to invoke the blockchain service and it is determined that the remaining number of times of invoking the blockchain service by the user does not reach the threshold, the user may be allowed to invoke the blockchain service.
In this case, the above block chain service may be called based on the above call data.
In one embodiment, the user may be rejected from invoking the blockchain service when it is determined that the remaining number of invocations of the user for the blockchain service reaches the threshold.
In this case, data indicating that the remaining number of calls is insufficient may be returned to the client, so that the client may prompt the user that the remaining number of calls for the blockchain service is insufficient based on the data.
In an embodiment shown, in order to avoid the number of times that a user calls a blockchain service from exceeding a limit and guarantee the rights of a service provider, the server may update the remaining number of times that the user maintains the blockchain for the blockchain service when the service end completes the call of the blockchain service based on the call data this time; for example, a preset threshold (typically 1) may be subtracted from the remaining number of calls maintained by the blockchain.
According to the technical scheme provided by one or more embodiments of the present specification, a server corresponding to a blockchain service may respond to received call data for the blockchain service sent by a client corresponding to a user, call a verification logic in an intelligent contract, verify whether the user has a call authority for the blockchain service, and determine whether the remaining number of calls of the user for the blockchain service reaches a preset threshold, and if the user has the call authority for the blockchain service and the remaining number of calls does not reach the threshold, call the blockchain service based on the call data.
By adopting the mode, when the user calls the blockchain service each time, the calling authority and the residual calling times of the user for the blockchain service are verified, and the user is allowed to call the blockchain service this time under the condition that the verification is passed, so that a service provider of the blockchain service can charge the user according to the condition that the user actually calls the blockchain service, and the user experience is improved. In addition, the verification of the calling authority and the residual calling times of the user for the block chain service does not relate to the user identity, so that the service provider can charge the user no matter whether the user anonymously calls the block chain service, and the benefit of the service provider is guaranteed.
The embodiment shown in fig. 2 will be described in detail below in terms of the above-described authorization process and the above-described authentication process.
(1) Authorization procedure
Referring to fig. 3, corresponding to the embodiment shown in fig. 2, fig. 3 is a flowchart illustrating a method for authorizing a call of a blockchain service according to an exemplary embodiment of the present disclosure.
In this embodiment, the method for authorizing call of blockchain service may also be applied to the server.
As shown in fig. 3, the method for authorizing call of blockchain service may include the following steps:
step 301: receiving authorization data sent by the client for the blockchain service; wherein the authorization data comprises verification data of a third key generated by the client for the first invocation.
In this embodiment, when a user needs to be authorized to invoke the permission of the blockchain service, authorization data for the blockchain service may be submitted to the server through the client; the authorization data may include verification data of the key generated by the client (hereinafter referred to as a third key).
The third key may be a key corresponding to a first call of the user to the blockchain service.
Step 302: responding to the authorization data, when the user holds the authorization call times for the block chain service, signing the verification data of the third key based on a private key corresponding to the authorization call times to obtain signature data, so that the client side can obtain the signature data.
In this embodiment, the service provider may set multiple authorized call times (for example, 10 times, 100 times, 200 times, etc.) for the blockchain service, so that the user may purchase the authorized call times from the service provider according to actual needs; wherein the authorized number of invocations may indicate a number of times the service provider allows the user to invoke the blockchain service.
Correspondingly, the server side can generate a pair of public key and private key for each authorized calling number, and the public key and the private key are used for encrypting and decrypting data or signing and verifying the data. And the public and private key pairs corresponding to different authorized calling times are different. The public key may be certified in the blockchain and the private key may be maintained by the service provider itself.
In this case, the server may respond to the authorization data when receiving the authorization data, and when the user holds the authorized number of calls for the blockchain service, sign the verification data of the third key based on a private key corresponding to the authorized number of calls to obtain signature data. The client may obtain the signature data for subsequently invoking the blockchain service.
In practical applications, the service provider may maintain a purchase record of the authorized number of calls for the blockchain service. To avoid repeated authorizations, only the number of authorized invocations that have not been used by the user may be recorded in the purchase record, for example: the number of authorized uses that the user has purchased but has not yet acquired the corresponding signature data. The server may determine that the user holds the authorization invocation record when the purchase record records that the user purchased the authorization invocation times. The purchase record may be stored locally at the server or in the blockchain, or may be stored in a server corresponding to a trusted third party.
In an embodiment shown, if the authorization process is implemented by a centralized platform outside the blockchain in the server by calling a code deployed outside the blockchain, the authorization data may be an authorization request. The centralized platform may respond to the authorization request, and when the user holds the authorized call times for the blockchain service, sign the verification data of the third key based on a private key corresponding to the authorized call times to obtain signature data.
In this case, the centralized platform may directly send the signature data to the client, so that the client may obtain the signature data.
Alternatively, the authorization data may be an authorization request if the server is coupled to nodes in the blockchain through various communication networks. The server may respond to the authorization request, and when the user holds the authorized call times for the blockchain service, sign the verification data of the third key based on a private key corresponding to the authorized call times to obtain signature data.
In this case, the server may directly send the signature data to the client, so that the client may obtain the signature data.
In an embodiment, the client may perform a blinding process (blinding) on the verification data of the third key, and generate the authorization data based on the blinded verification data of the third key. That is, the authorization data is the blinded verification data of the third key.
In this case, the server may perform blind signature on the blinded verification data of the third key based on the private key to obtain the blinded signature data. The client may obtain the blinded signature data, and perform un-blinding (unblinding) on the blinded signature data to obtain the signature data. The signature data obtained by the blinding processing is the same as signature data obtained by signing the verification data of the third key based on the private key.
By adopting a Blind Signature (Blind Signature), the server can sign the verification data of the third key without acquiring the verification data of the third key. In this way, the data security of the third key itself and the authentication data of the third key can be improved.
In an embodiment shown, the server may be a distributed server, and includes a plurality of sub-servers; for example, the server may operate on a cluster of physical hosts, where each physical host may act as a child.
Because the private key is maintained by the service provider, in order to improve the data security of the private key and avoid the leakage of the private key, the private key can be divided into a plurality of private key fragments, and the private key fragments are stored in the plurality of sub-terminals respectively. That is, different child peers may locally store different private key fragments.
In this case, for any of the child terminals, the child terminal may sign the verification data of the third key based on the private key shard maintained by the child terminal.
The server side can collect the signature of the verification data of the third key by each sub-side based on the private key fragment maintained by the sub-side, obtain signature fragment data and determine whether the number of the collected signature fragment data reaches a preset threshold value; the threshold value may be preset by a technician according to actual needs, or may be a default value by default.
The server side can recover the signature data based on the collected signature fragment data under the condition that the number of the collected signature fragment data is determined to reach the threshold value; at this time, the signature data is signature data obtained by signing the verification data of the third key based on the private key.
For example, the threshold n may be set in advance. In this case, if the private key is divided into m (m is greater than or equal to n) private key fragments, at least n private key fragments based on the m private key fragments need to be collected, the verification data of the third key is signed respectively, and the obtained n signature fragment data can be recovered based on the collected n signature fragment data; if only less than n signature fragment data are collected, the signature data cannot be recovered.
The authorization process described above is exemplified below. Referring to fig. 4, fig. 4 is a schematic diagram illustrating data interaction in an authorization process according to an exemplary embodiment of the present disclosure.
As shown in fig. 4, the client may generate the key1 first, and then calculate the hash value key1hash of the key 1. Subsequently, the client may perform blinding processing on the hash value key1hash to obtain a blinded hash value key1hash0, and send the blinded hash value key1hash0 to the server. The server performs blind signature on the blinded hash value key1hash0 based on a private key corresponding to the authorized calling times of the user for the block chain service to obtain blinded signature data sigedkey 1hash0, and enables the client to obtain the blinded signature data sigedkey 1hash 0. The client side can perform blind removing processing on the blinded signature data signedkey1hash0 to obtain the signature data signedkey1 hash.
(2) Verification process
Referring to fig. 5, corresponding to the embodiment shown in fig. 2, fig. 5 is a flowchart illustrating a call verification method for a blockchain service according to an exemplary embodiment of the present disclosure.
In this embodiment, the call verification method of the blockchain service may also be applied to the server. The call verification method of the blockchain service can be regarded as a specific implementation of step 202 in the embodiment shown in fig. 2.
In conjunction with the embodiment shown in fig. 2, the invocation data may include verification data of a key (hereinafter referred to as a first key) generated by the client for the invocation, and a key (hereinafter referred to as a second key) generated for the previous invocation. Accordingly, the chain of blocks may have authentication data for the second key stored therein.
It should be noted that, for the second key, when the current call is the second call, the last call is the first call; at this time, the second key may also be the third key.
In an embodiment shown, the key generated by the client for each invocation may be randomly generated by the client, so as to avoid long-term use of the same key or a key with a certain rule, and improve data security of the key.
In one embodiment shown, the validation data for any key may be a hash of that key.
Specifically, hash calculation may be performed on the key based on a preset hash algorithm to obtain a hash value of the key, which is used as verification data of the key; the hash algorithm can be preset by a technician according to actual requirements.
Typically, the hash values are different for different data. If the two different keys are respectively subjected to hash calculation based on the same hash algorithm, the two obtained hash values are also different. Thus, it is possible to verify whether the two keys are identical by the hash value.
In order to reduce the probability of the hash value of the key being cracked and avoid the key being leaked, the salted hash value of the key can be calculated by adopting a hash salting mode.
Specifically, a preset salt (salt) may be mixed into the key, and then hash calculation may be performed on the salted key to obtain a salted hash value, which is used as verification data of the key; the salt value can be preset by a technician according to actual requirements, and can also be a default value by default.
As shown in fig. 5, the method for authorizing call of blockchain service may include the following steps:
step 501: and calculating based on the second key to obtain verification data of the second key.
In this embodiment, when verifying whether the user has the right to invoke the blockchain service, the smart contract may specifically perform calculation based on the second key in the invocation data to obtain verification data of the second key.
Step 502: and determining whether the calculated verification data of the second key is matched with the verification data of the second key stored in the block chain.
In this embodiment, the calculated verification data of the second key may be subsequently matched with the verification data of the second key stored in the block chain.
Step 503: and if the two are matched, determining that the user has the calling authority for the blockchain service.
In this embodiment, if the calculated verification data of the second key matches the verification data of the second key certified in the blockchain, it may be determined that the user has a call authority for the blockchain service.
Step 504: and storing the verification data of the first key in the block chain.
In this embodiment, the verification data of the first key in the call data may be stored in the block chain for verification at the next call.
In an illustrated embodiment, in combination with the embodiment shown in fig. 3, for the first call, there is no last call corresponding to the first call, so that when the user calls the blockchain service for the first time, the call data may include the verification data of the third key and the signature data.
In addition, the block chain can also store and prove that the server generates a public key for each authorized calling number.
In this case, when verifying whether the user has the right to invoke the blockchain service, the intelligent contract may specifically acquire the public key corresponding to the number of times of authorized invocations of the user for the blockchain service. Subsequently, the signature data can be verified based on the public key. If the verification passes, it may be determined that the user has invocation authority for the blockchain service. At this time, the remaining number of calls of the user for the blockchain service can be determined based on the authorized number of calls; for example, the authorized call times may be determined as the remaining call times, and then the remaining call times are updated when the calling of the blockchain service based on the call data is completed for the first time; and, the verification data of the third key can also be stored in the block chain.
In practical applications, the calling data may further include the public key, so that the intelligent contract may directly obtain the public key from the calling data. Or, the intelligent contract may attempt to verify the signature data based on each public key stored in the block chain to obtain a public key capable of verifying the signature data, where the authorization call frequency corresponding to the public key is the authorization call frequency of the user for the block chain service.
The above authentication process is exemplified below. Referring to fig. 6 in conjunction with fig. 4, fig. 6 is a schematic diagram illustrating data interaction in a verification process according to an exemplary embodiment of the present disclosure.
As shown in fig. 6, when the user calls the blockchain service for the first time, the client may send a hash value key1hash and signature data signedkey1hash to the server. The server side can verify the signature data signedkey1hash based on a public key corresponding to the authorized calling times of the user for the block chain service by calling an intelligent contract, if the verification is passed, the hash value key1hash can be stored in the block chain, and after the first calling is completed, the rest calling times (which can be n-1 times) which are determined based on the authorized calling times (assumed to be n times) and are updated are stored in the block chain.
When the user calls the blockchain service for the second time, the client may generate the key2 first, and then calculate the hash value key2hash of the key 2. Subsequently, the client may send the key1 and the hash value key2hash to the server. The server side can calculate the hash value of the key1 by calling the intelligent contract, determine whether the calculated hash value is matched with the hash value key1hash, determine whether n-1 reaches a preset threshold value (which can be 0), and if the two are matched and n-1 is larger than 0, store the hash value key2hash in the block chain, and update the residual calling times of the certificate stored in the block chain to n-2 times after the second calling is completed.
When the user calls the blockchain service for the third time, the client may generate the key3 first, and then calculate the hash value key3hash of the key 3. Subsequently, the client may send the key2 and the hash value key3hash to the server. The server side can calculate the hash value of the key2 by calling the intelligent contract, determine whether the calculated hash value is matched with the hash value key2hash, determine whether n-2 reaches 0, if the two are matched and n-2 is larger than 0, store the certificate of the hash value key3hash in the block chain, and update the residual calling times of the certificate stored in the block chain to n-3 times after the second calling is completed. And so on.
Referring to fig. 7, fig. 7 is a schematic diagram illustrating another method for calling a blockchain service according to an exemplary embodiment of the present disclosure.
In this embodiment, the method for calling the blockchain service may be applied to a client corresponding to a user.
The blockchain is provided with blockchain services and intelligent contracts used for managing the calling of the blockchain services; the blockchain maintains the remaining number of calls the user has to service for the blockchain.
As shown in fig. 7, the method for calling the blockchain service may include the following steps:
step 701: obtaining call data for the blockchain service.
Step 702: sending the calling data to a server corresponding to the block chain service, so that the server responds to the calling data, calls a verification logic in the intelligent contract, verifies whether the user has a calling authority aiming at the block chain service, determines whether the residual calling times of the user aiming at the block chain service reach a preset threshold value, and calls the block chain service based on the calling data if the user has the calling authority aiming at the block chain service and the residual calling times do not reach the threshold value.
Optionally, the method further comprises:
obtaining authorization data for the blockchain service; the authorization data comprises verification data of a third key generated by the client for the first call;
sending the authorization data to the server, so that the server responds to the authorization data, and when the user holds the authorized calling times for the block chain service, signing the verification data of the third key based on a private key corresponding to the authorized calling times to obtain signature data;
and acquiring the signature data.
Optionally, the obtaining authorization data for the blockchain service includes:
blinding the verification data of the third key, and generating the authorization data based on the blinded verification data of the third key;
the sending the authorization data to the server, so that the server responds to the authorization data, and when the user holds the authorized call times for the blockchain service, signs the verification data of the third key based on a private key corresponding to the authorized call times, to obtain signature data, includes:
sending the authorization data to the server, so that the server responds to the authorization data, and when the user holds the authorization calling times for the block chain service, blind signing is performed on the verification data of the third key after blinding based on the private key, and blinded signature data is obtained;
the acquiring the signature data includes:
and acquiring the blinded signature data, and performing blind removing processing on the blinded signature data to obtain the signature data.
Optionally, the key is randomly generated by the client.
Optionally, the verification data of the key comprises a hash value of the key.
Optionally, the blockchain is a federation chain.
Specific implementation of the embodiment shown in fig. 7 may refer to the embodiments shown in fig. 2 to fig. 6, which are not described in detail herein.
Corresponding to the foregoing embodiments of the method for calling a blockchain service, the present specification further provides embodiments of a device for calling a blockchain service.
The calling device of the blockchain service in the specification can be applied to electronic equipment. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation. From a hardware aspect, as shown in fig. 8, a hardware structure diagram of an electronic device where a device for calling a blockchain service in this specification is located is shown, where in addition to the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 8, the electronic device where the device is located in the embodiment may also include other hardware according to an actual function called by the blockchain service, which is not described again.
Referring to fig. 9, fig. 9 is a block diagram illustrating an invoking device of a blockchain service according to an exemplary embodiment of the present disclosure.
The calling device of the block chain service may be applied to the electronic device shown in fig. 8; the electronic device may act as a server corresponding to a blockchain service deployed on a blockchain.
The blockchain is also provided with an intelligent contract used for managing the calling of the blockchain service; the blockchain maintains the remaining number of calls the user has to service for the blockchain.
The device comprises:
a receiving module 901, configured to receive call data for the blockchain service sent by a client corresponding to a user;
a verification module 902, configured to invoke, in response to the invocation data, verification logic in the intelligent contract, verify whether the user has an invocation permission for the blockchain service, and determine whether the remaining invocation frequency of the user for the blockchain service reaches a preset threshold;
and the calling module 903 is configured to call the blockchain service based on the calling data when the user has a calling authority for the blockchain service and the remaining number of calling times does not reach the threshold.
Referring to fig. 10, fig. 10 is a block diagram illustrating another calling apparatus of a blockchain service according to an exemplary embodiment of the present disclosure.
The above calling device of the blockchain service may be applied to the electronic device shown in fig. 8; the electronic device may act as a user client corresponding to a user.
The blockchain is provided with blockchain services and intelligent contracts used for managing the calling of the blockchain services; the blockchain maintains the remaining number of calls the user has to service for the blockchain.
The device comprises:
an obtaining module 1001, configured to obtain call data for the blockchain service;
the invoking module 1002 is configured to send the invoking data to a server corresponding to the blockchain service, so that the server invokes a verification logic in the intelligent contract in response to the invoking data, verifies whether the user has an invoking right for the blockchain service, and determines whether the remaining invoking number of times of the user for the blockchain service reaches a preset threshold, and if the user has the invoking right for the blockchain service and the remaining invoking number of times does not reach the threshold, invokes the blockchain service based on the invoking data.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points.
The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the technical solution of the present specification.
The systems, apparatuses, modules or units described in the above embodiments may be specifically implemented by a computer chip or an entity, or implemented by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium, that may be used to store information that may be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The above description is intended only to be exemplary of the one or more embodiments of the present disclosure, and should not be taken as limiting the one or more embodiments of the present disclosure, as any modifications, equivalents, improvements, etc. that come within the spirit and scope of the one or more embodiments of the present disclosure are intended to be included within the scope of the one or more embodiments of the present disclosure.

Claims (15)

1. A method for calling blockchain service is applied to a server corresponding to blockchain service deployed on a blockchain; wherein, the blockchain is also deployed with an intelligent contract for managing the calling of the blockchain service; the block chain maintains the residual calling times of the user for the block chain service; the block chain stores and verifies the corresponding relation between the public key and the authorized calling times; the method comprises the following steps:
receiving call data aiming at the block chain service, which is sent by a client corresponding to a user; the calling data comprise verification data of a third key generated by the client for the first calling, signature data obtained by signing the verification data of the third key based on a private key corresponding to the authorized calling times of the user for the block chain service, verification data of a first key generated by the client for the current calling and a second key generated for the last calling when the calling data are not called for the first time; the block chain stores verification data of the second secret key;
responding to the calling data, calling a verification logic in the intelligent contract, verifying whether the user has a calling authority for the block chain service, and determining whether the residual calling times of the user for the block chain service reach a preset threshold value;
if the user has the calling authority aiming at the block chain service and the residual calling times do not reach the threshold value, calling the block chain service based on the calling data;
the verifying whether the user has the call authority for the blockchain service comprises:
acquiring a public key corresponding to the authorized calling times of the user for the block chain service; verifying the signature data based on the public key; if the verification is passed, determining that the user has the calling authority for the blockchain service; determining the residual calling times based on the authorized calling times, and storing the verification data of the third key in the block chain; alternatively, the first and second electrodes may be,
calculating based on the second key to obtain verification data of the second key; determining whether the calculated verification data of the second key is matched with the verification data of the second key stored in the block chain; if the two are matched, determining that the user has the calling authority aiming at the block chain service; and storing the verification data of the first key in the block chain.
2. The method of claim 1, further comprising:
receiving authorization data sent by the client aiming at the block chain service; wherein the authorisation data comprises verification data for the third key;
and responding to the authorization data, and when the user holds the authorization calling times, signing the verification data of the third secret key based on the private key to obtain signature data so that the client side can obtain the signature data.
3. The method of claim 2, the authentication data of the third key in the authorization data is blinded;
the signing the verification data of the third key based on the private key to obtain signature data so that the client side obtains the signature data includes:
and blind signing the blinded verification data of the third key based on the private key to obtain the blinded signature data, so that the client side obtains the blinded signature data and performs blind removing processing on the blinded signature data to obtain the signature data.
4. The method of claim 2, wherein the server is a distributed server comprising a plurality of sub-servers; the private key is divided into a plurality of private key fragments which are respectively stored in the plurality of sub-terminals;
the signing the verification data of the third key based on the private key to obtain signature data comprises:
collecting signature fragment data obtained by signing the verification data of the third key based on each private key fragment;
determining whether the number of the collected signature fragment data reaches a preset threshold value;
and if the number of the collected signature fragment data reaches the threshold value, recovering the signature data based on the collected signature fragment data.
5. The method according to any one of claims 1-4, further comprising:
and updating the residual calling times after the calling of the block chain service based on the calling data is completed.
6. The method of claim 1, further comprising:
and if the residual calling times reach the threshold value, returning data for indicating that the residual calling times are insufficient to the client.
7. The method of claim 1, the first key and the second key being randomly generated by the client; alternatively, the third key is randomly generated by the client.
8. A method for calling blockchain service is applied to a user client corresponding to a user; the system comprises a blockchain, a service module and a service module, wherein the blockchain is provided with a blockchain service and an intelligent contract for managing the calling of the blockchain service; the block chain maintains the residual calling times of the user for the block chain service; the block chain stores and verifies the corresponding relation between the public key and the authorized calling times; the method comprises the following steps:
acquiring call data aiming at the blockchain service; the calling data comprise verification data of a third key generated by the client for the first calling, signature data obtained by signing the verification data of the third key based on a private key corresponding to the authorized calling times of the user for the block chain service, verification data of a first key generated by the client for the current calling and a second key generated for the last calling when the calling data are not called for the first time; the block chain stores verification data for certifying the second key;
sending the calling data to a server corresponding to the blockchain service, so that the server responds to the calling data, calls a verification logic in the intelligent contract, verifies whether the user has a calling authority for the blockchain service, determines whether the remaining calling times of the user for the blockchain service reach a preset threshold value, and calls the blockchain service based on the calling data if the user has the calling authority for the blockchain service and the remaining calling times do not reach the threshold value;
the verifying whether the user has the call authority for the blockchain service comprises:
acquiring a public key corresponding to the authorized calling times of the user for the block chain service; verifying the signature data based on the public key; if the verification is passed, determining that the user has the calling authority for the blockchain service; determining the residual calling times based on the authorized calling times, and storing the verification data of the third key in the block chain; alternatively, the first and second liquid crystal display panels may be,
calculating based on the second key to obtain verification data of the second key; determining whether the calculated verification data of the second key is matched with the verification data of the second key stored in the block chain; if the two are matched, determining that the user has the calling authority aiming at the block chain service; and storing the verification data of the first key in the block chain.
9. The method of claim 8, further comprising:
obtaining authorization data for the blockchain service; the authorization data comprises verification data of a third key generated by the client for the first call;
sending the authorization data to the server, so that the server responds to the authorization data, and when the user holds authorization calling times for the block chain service, signing verification data of the third secret key based on a private key corresponding to the authorization calling times to obtain signature data;
and acquiring the signature data.
10. The method of claim 9, the obtaining authorization data for the blockchain service, comprising:
blinding the verification data of the third key, and generating the authorization data based on the blinded verification data of the third key;
the sending the authorization data to the server, so that the server responds to the authorization data, and when the user holds the authorized call times for the blockchain service, signs the verification data of the third key based on a private key corresponding to the authorized call times, to obtain signature data, includes:
sending the authorization data to the server, so that the server responds to the authorization data, and when the user holds the authorization call times for the block chain service, blindly signing the verification data of the third blinded key based on the private key to obtain blinded signature data;
the acquiring the signature data includes:
and acquiring the blinded signature data, and performing blind removing processing on the blinded signature data to obtain the signature data.
11. The method of claim 9, the third key being randomly generated by the client.
12. A calling device of a blockchain service is applied to a server corresponding to the blockchain service deployed on a blockchain; wherein, the blockchain is also deployed with an intelligent contract for managing the calling of the blockchain service; the block chain maintains the residual calling times of the user for the block chain service; the block chain stores and verifies the corresponding relation between the public key and the authorized calling times; the device comprises:
the receiving module is used for receiving calling data aiming at the block chain service, which is sent by a client corresponding to a user; the calling data comprise verification data of a third secret key generated by the client for the first calling and signature data obtained by signing the verification data of the third secret key based on a private key corresponding to the authorized calling times of the user for the block chain service during the first calling, and comprise the verification data of a first secret key generated by the client for the calling and a second secret key generated for the last calling during non-first calling; the block chain stores verification data for certifying the second key;
the verification module is used for responding to the calling data, calling a verification logic in the intelligent contract, verifying whether the user has the calling authority for the block chain service, and determining whether the residual calling times of the user for the block chain service reach a preset threshold value;
the calling module is used for calling the blockchain service based on the calling data when the user has the calling authority aiming at the blockchain service and the residual calling times do not reach the threshold value;
the verifying whether the user has the call authority for the blockchain service comprises:
acquiring a public key corresponding to the authorized calling times of the user for the block chain service; verifying the signature data based on the public key; if the verification is passed, determining that the user has the calling authority for the blockchain service; determining the residual calling times based on the authorized calling times, and storing the verification data of the third key in the block chain; alternatively, the first and second electrodes may be,
calculating based on the second key to obtain verification data of the second key; determining whether the calculated verification data of the second key is matched with the verification data of the second key stored in the block chain; if the two are matched, determining that the user has the calling authority aiming at the block chain service; and storing the verification data of the first key in the block chain.
13. A calling device of a block chain service is applied to a user client corresponding to a user; the system comprises a blockchain, a service module and a service module, wherein the blockchain is provided with a blockchain service and an intelligent contract for managing the calling of the blockchain service; the block chain maintains the residual calling times of the user for the block chain service; the block chain stores and verifies the corresponding relation between the public key and the authorized calling times; the device comprises:
an obtaining module, configured to obtain call data for the blockchain service; the calling data comprise verification data of a third key generated by the client for the first calling, signature data obtained by signing the verification data of the third key based on a private key corresponding to the authorized calling times of the user for the block chain service, verification data of a first key generated by the client for the current calling and a second key generated for the last calling when the calling data are not called for the first time; the block chain stores verification data of the second secret key;
the calling module is used for sending the calling data to a server corresponding to the block chain service so that the server responds to the calling data, calls a verification logic in the intelligent contract, verifies whether the user has a calling authority for the block chain service, determines whether the residual calling times of the user for the block chain service reach a preset threshold value, and calls the block chain service based on the calling data if the user has the calling authority for the block chain service and the residual calling times do not reach the threshold value;
the verifying whether the user has the call authority for the blockchain service comprises the following steps:
acquiring a public key corresponding to the authorized calling times of the user for the block chain service; verifying the signature data based on the public key; if the verification is passed, determining that the user has the calling authority for the blockchain service; determining the residual calling times based on the authorized calling times, and storing the verification data of the third key in the block chain; alternatively, the first and second electrodes may be,
calculating based on the second key to obtain verification data of the second key; determining whether the calculated verification data of the second key is matched with the verification data of the second key stored in the block chain; if the two are matched, determining that the user has the calling authority aiming at the block chain service; and storing the verification data of the first key in the block chain.
14. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of any of claims 1-7 or 8-11 by executing the executable instructions.
15. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the method of any one of claims 1-7 or 8-11.
CN202210395271.6A 2022-04-15 2022-04-15 Method and device for calling block chain service Active CN114500119B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210395271.6A CN114500119B (en) 2022-04-15 2022-04-15 Method and device for calling block chain service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210395271.6A CN114500119B (en) 2022-04-15 2022-04-15 Method and device for calling block chain service

Publications (2)

Publication Number Publication Date
CN114500119A CN114500119A (en) 2022-05-13
CN114500119B true CN114500119B (en) 2022-08-26

Family

ID=81489442

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210395271.6A Active CN114500119B (en) 2022-04-15 2022-04-15 Method and device for calling block chain service

Country Status (1)

Country Link
CN (1) CN114500119B (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114448694B (en) * 2022-01-24 2024-04-09 蚂蚁区块链科技(上海)有限公司 Service calling method and device based on block chain
CN114781004B (en) * 2022-06-15 2022-09-30 恒生电子股份有限公司 Block chain-based data evidence storage method and device, electronic equipment and storage medium

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021170049A1 (en) * 2020-02-29 2021-09-02 华为技术有限公司 Method and apparatus for recording access behavior

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7827104B2 (en) * 2004-03-25 2010-11-02 International Business Machines Corporation Method and system for efficiently billing on-demand service exploitation in computer networks
JP6509775B2 (en) * 2016-05-12 2019-05-08 日本電信電話株式会社 Ad access count measurement method, ad delivery server, program
CN109117629A (en) * 2018-09-06 2019-01-01 上海点融信息科技有限责任公司 Method and apparatus for the counting user intelligence contract in block chain network
CN109508985A (en) * 2018-11-26 2019-03-22 平安科技（深圳）有限公司 Interface calls bookkeeping methods, device, computer equipment and storage medium
CN111160911B (en) * 2019-12-31 2023-10-24 杭州趣链科技有限公司 Intelligent contract calling frequency control method for block chain
CN111586065A (en) * 2020-05-12 2020-08-25 山东浪潮商用系统有限公司 Data authorization method based on block chain
CN112749968B (en) * 2021-01-29 2022-09-06 支付宝实验室(新加坡)有限公司 Service data recording method and device based on block chain

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021170049A1 (en) * 2020-02-29 2021-09-02 华为技术有限公司 Method and apparatus for recording access behavior

Also Published As

Publication number Publication date
CN114500119A (en) 2022-05-13

Similar Documents

Publication Publication Date Title
US11610019B2 (en) Information management method, apparatus, and information management system
US10790976B1 (en) System and method of blockchain wallet recovery
KR102002509B1 (en) Privite blockchain system including notarizing center and notarial method thereof
KR20200084009A (en) Asset management method and apparatus, and electronic device
CN114500119B (en) Method and device for calling block chain service
CN111492634A (en) Secure and confidential custody transaction systems, methods, and apparatus using zero-knowledge protocols
CN111753335B (en) Editing method and device for block content
CN110177124B (en) Identity authentication method based on block chain and related equipment
CN107135085B (en) Orient statistical control method, the system of flow
CN112688773A (en) Token generation and verification method and device
US20210241270A1 (en) System and method of blockchain transaction verification
CN111522809A (en) Data processing method, system and equipment
JP2023542681A (en) Integrating device identity into blockchain permission frameworks
US20090083739A1 (en) Network resource access control methods and systems using transactional artifacts
US10931650B1 (en) Apparatus and method for building, extending and managing interactions between digital identities and digital identity applications
CN115296794A (en) Key management method and device based on block chain
CN115130075A (en) Digital signature method and device, electronic equipment and storage medium
CN112990925B (en) Asset certificate management method and device
CN112822267A (en) Data processing method and device based on block chain
CN115131029A (en) Block chain-based digital file signing method and device
CN116451280A (en) Asset management method and device based on blockchain
CN115118434A (en) Key management method and device based on block chain
CN113765674B (en) Cross-platform registration method and device based on blockchain
CN113327169B (en) Claims settlement method and device based on block chain and electronic equipment
US20230169204A1 (en) Secure sharing of personal data in distributed computing zones

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant