Service interface calling method and device based on block chain, equipment and storage medium

Abstract

The invention discloses a service interface calling method and device based on a block chain, equipment and a storage medium. The method comprises the following steps: in response to a service interface calling request sent by a service interface gateway, carrying out request analysis on the service interface calling request, and determining a DID and a request private key signature of a server calling party; the service interface calling request is initiated by a service interface calling direction to a service interface gateway, and the service interface gateway determines a service interface provider based on the service interface calling request and forwards the service interface provider to the service interface provider; performing signature verification on the request private key signature according to the decentralized identifier of the service interface calling party, and performing authority verification on the query authority of the service interface calling party to generate a verification result; the query permission of the service interface calling party is generated based on common approval verification of multiple approval participants; if the verification result is that the verification is passed, executing the service interface calling request, and generating a request response result; and feeding back a request response result to the service interface calling party.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a service interface invocation method, apparatus, device, and storage medium based on blockchain. Background Technology

[0002] In digital government systems, API (Application Programming Interface) gateways serve as the unified entry point for service calls, undertaking crucial functions such as authentication, authorization, and routing. Traditional API gateways typically employ a centralized architecture, where authentication and authorization for all requests are handled centrally by the gateway, posing risks of single points of failure and performance bottlenecks. Furthermore, authorization for service call relationships is usually managed by the gateway or centralized configuration, which carries the risk of tampering or unauthorized access.

[0003] Therefore, how to achieve decentralized authorization of the call relationship in the service interface call process, thereby improving the security and reliability of the service interface call process, has become an urgent problem to be solved. Summary of the Invention

[0004] This invention provides a service interface invocation method, apparatus, device, and storage medium based on blockchain to improve the security and reliability of the service interface invocation process.

[0005] According to one aspect of the present invention, a service interface invocation method based on blockchain is provided, applied to a service interface provider, the method comprising: In response to a service interface call request sent by the service interface gateway, the service interface call request is parsed to determine the decentralized identifier (DID) and private key signature of the server caller. The service interface call request is initiated by the service interface caller to the service interface gateway, and the service interface gateway determines the service interface provider based on the service interface call request and forwards it to the service interface provider. Based on the decentralized identifier of the service interface caller, the signature of the request private key is verified, and the query permission of the service interface caller is verified, generating a verification result; the query permission of the service interface caller is generated based on the joint approval and verification of multiple approval participants. If the verification result is successful, then the service interface call request is executed, and a request response result is generated; The request response result is fed back to the service interface caller.

[0006] According to another aspect of the present invention, a blockchain-based service interface invocation device is provided, configured on a service interface provider, the device comprising: The request and response module is used to respond to service interface call requests sent by the service interface gateway, parse the service interface call request, and determine the decentralized identifier (DID) and request private key signature of the server caller. The service interface call request is initiated by the service interface caller to the service interface gateway, and the service interface gateway determines the service interface provider based on the service interface call request and forwards it to the service interface provider. The verification module is used to perform signature verification on the private key signature of the request based on the decentralized identifier of the service interface caller, and to perform permission verification on the query permission of the service interface caller, and generate a verification result; the query permission of the service interface caller is generated based on the joint approval and verification of multiple approval participants. The request-response module is used to execute the service interface call request and generate a request-response result if the verification result is successful. The result feedback module is used to send the request response result back to the service interface caller.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to execute the blockchain-based service interface invocation method according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the blockchain-based service interface invocation method described in any embodiment of the present invention.

[0009] The technical solution of this invention parses service interface call requests, verifies the signature of the request private key based on the decentralized identifier of the service interface caller obtained from the parsing, and verifies the query permissions of the service interface caller, generating a verification result. During the verification process, the query permissions of the service interface caller are generated based on the joint approval and verification of multiple approval participants. If the verification result is successful, the service interface call request is executed, and a request response result is generated. This achieves decentralized authorization of the call relationship in the service interface call process, avoiding the risk of tampering or unauthorized access that may occur when the authorization process is managed by a single gateway or centralized configuration. Furthermore, the multi-signature approval method used in the verification process improves the security and reliability of the service interface call process.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart of a service interface invocation method based on blockchain according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a service interface call consortium blockchain network constructed by multiple participants according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating the interaction process of a service interface caller requesting calling permissions, provided by an embodiment of the present invention. Figure 4 This is a flowchart of the interface call interaction of a service interface caller according to an embodiment of the present invention; Figure 5 This is a schematic diagram of a service interface invocation device based on blockchain according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device that implements the blockchain-based service interface calling method of this invention. Detailed Implementation

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

[0014] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0015] Figure 1 This is a flowchart of a blockchain-based service interface invocation method provided in Embodiment 1 of the present invention. This embodiment is applicable to service interface invocation in high-concurrency scenarios. The method can be executed by a blockchain-based service interface invocation device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, this method can be applied to a service interface provider, which can be a pre-deployed on-chain blockchain node. The method includes: S110. In response to the service interface call request sent by the service interface gateway, the service interface call request is parsed to determine the decentralized identifier (DID) and private key signature of the server caller. The service interface call request is initiated by the service interface caller to the service interface gateway, and the service interface gateway determines the service interface provider based on the service interface call request and forwards it to the service interface provider.

[0016] S120. Based on the decentralized identifier of the service interface caller, perform signature verification on the private key signature of the request and permission verification on the query permission of the service interface caller, and generate verification results; the query permission of the service interface caller is generated based on the joint approval and verification of multiple approval participants.

[0017] S130. If the verification result is successful, execute the service interface call request and generate the request response result.

[0018] S140. Feedback the request response result to the service interface caller.

[0019] In this embodiment, all parties involved in the service interface call execution process are deployed as core participants in the blockchain network, i.e., they participate in the service interface call process as blockchain nodes. The blockchain network can be a consortium blockchain, and the core participants in the service interface call process can include the service interface caller, the service interface provider, the service interface gateway, and approvers such as owners. The service interface gateway is pre-deployed as a necessary on-chain blockchain node. The service interface provider and the service interface caller can choose to deploy blockchain nodes or access the blockchain through the interface provided by the service interface gateway. Preferably, see... Figure 2 The diagram illustrates the structure of a multi-participant service interface call consortium blockchain network. This network includes service interface callers, service interface providers, service interface gateways, and approval parties such as owners, all of whom pre-deploy blockchain nodes on the chain and participate in the service interface call execution process. The smart contract layer is used to deploy and execute smart contracts with different functions, such as permission approval smart contracts. The underlying blockchain includes blockchain ledger storage and block consensus mechanisms.

[0020] Taking a digital government service scenario as an example, the service interface caller can be Enterprise A, whose call requirement is to apply for access to the enterprise's business license information query API for handling government approval business; the corresponding service interface provider can be the market supervision bureau's government service center, which can provide the business license information query API and is responsible for interface authentication and authorization; the owner can be the municipal government service data management bureau (government data bureau), which is the main body responsible for government service supervision and can participate in the authorization approval process as one of the approvers to ensure service compliance; the service interface gateway is the municipal government API gateway system, which is used for unified routing and forwarding and should deploy blockchain nodes to provide on-chain data access interfaces.

[0021] When roles are added to the blockchain, DID (Decentralized Identifier) ​​issuance and identity management are performed in advance for different roles. It's important to note that the DID issuance service is not controlled solely by the service interface gateway, but is jointly maintained by consortium members, such as approvers, service callers, and service providers, or implemented using standardized DID methods based on public or consortium blockchains. The service interface gateway should not be the sole DID issuer to avoid creating a new centralized control point.

[0022] When any role (service interface caller, service interface provider, service interface gateway, and approver, etc.) joins the service interface call consortium blockchain or blockchain network for the first time, an asymmetric key pair is generated locally. The private key in the key pair is securely stored locally by the role to avoid network transmission, while the public key of the key pair is stored on the blockchain. Specifically, during role registration, a DID document is constructed based on its own public key and other information. The DID document contains a DID identifier to uniquely identify the role, a public key hash (after hashing its own public key), the service endpoint, and the authentication method. The service endpoint can be a service address that can be queried from a routing table.

[0023] Registration requests are submitted by calling the DID registration smart contract through a blockchain node. This smart contract can be pre-designed by technical personnel and deployed on-chain for easy access, used to register the information of newly added roles. The blockchain node packages the transactions and writes them into a block after consensus confirmation. For example, a consortium blockchain uses the PBFT consensus mechanism to ensure transaction immutability, writing the registration information of different roles into the blockchain ledger. Roles can query on-chain data using their own DID to confirm that their DID document is on-chain and valid. The blockchain can return the DID's valid status and complete DID document information, which is stored locally by the role.

[0024] In the aforementioned DID registration process, when a role joins a consortium blockchain or blockchain network for the first time, it creates its unique DID on the blockchain through the independent DID issuance service. This process is self-generated; the role locally generates an asymmetric key pair and then stores the public key hash, server endpoint, and other information as a DID document on the blockchain through a registration transaction. The blockchain, as a verifiable data registry, ensures the uniqueness of DIDs and the immutability of DID documents. Each role's DID corresponds to a DID document stored on the blockchain. The DID document contains the public key information, authentication method, and server endpoint corresponding to that DID. When it is necessary to verify the signature of a DID holder, the verifier (such as a service provider) can query and retrieve the DID document from the blockchain based on the DID identifier and use the public key published in the document to perform signature verification.

[0025] Furthermore, for entities requiring higher credibility, such as government data bureaus, their DIDs can enhance the credibility of their identities by obtaining verifiable certificates (VCs) issued by authoritative CAs (Certificate Authorities), and their credential status can also be recorded on the blockchain for verification by other participants. Service interface callers, service interface gateways, service interface providers, and other approval parties, such as business entities, all possess their own unique DIDs for identity identification and key management.

[0026] After each role completes the on-chain DID registration, the service interface caller can initiate an interface call permission application through the permission approval smart contract, and the call permission is confirmed after multi-signature confirmation by multiple approval parties.

[0027] In an optional embodiment, before parsing the service interface call request in response to the service interface gateway and determining the decentralized identifier and request private key signature of the server caller, the method further includes: receiving the permission request from the service interface caller through a permission approval smart contract; determining the target call interface called by the service interface caller based on the permission request; determining the sensitivity score of the target call interface based on the interface-related information of the target call interface; determining the number of approval participants and the signature threshold based on the sensitivity score through the permission approval smart contract; generating a permission request record table based on the number of approval participants and the signature threshold; the permission request record table includes the DID of the approval participants and the call request details; uploading the permission request record table to the blockchain, and simultaneously generating and broadcasting a permission approval event on the blockchain.

[0028] The permission request is initiated by the service interface caller to request API call permissions from the service interface provider. Specifically, the service interface caller initiates the permission request through the permission approval smart contract, submitting application information such as the service interface caller's DID, the target API identifier corresponding to the target API of the service interface provider requested by the service interface caller (which can be a combination of the service interface caller's DID and the interface path), and the service interface caller's private key signature for authentication. Optionally, the application information may also include a validity period.

[0029] The permission approval smart contract determines the target API call interface based on the target API identifier in the permission request, and determines the sensitivity score of the target API call interface based on its interface-related information. In one optional embodiment, the interface-related information includes data classification information, business association information, historical API call information, and historical API call behavior. Accordingly, determining the sensitivity score of the target API call interface based on its interface-related information includes: determining the sensitivity score of the target API call interface based on the weight parameters corresponding to the data classification information, business association information, historical API call information, and historical API call behavior.

[0030] Among them, data classification information is used to characterize the business sensitivity category of data. Specifically, it can include public business data, general business data, sensitive business data, and core or confidential business data. For example, public business data can be enterprise name query data, general business data can be enterprise registration information query data, sensitive business data can be tax data or equipment information query data, and core or confidential business data can be internal approval data and confidential data, etc.

[0031] Different business sensitivity categories of data can correspond to different first sensitivity scores. For example, the first sensitivity score for public business data can be 0.1, for general business data it can be 0.3, for sensitive business data it can be 0.7, and for core or classified business data it can be 1.0.

[0032] Among them, business-related information can be business function information based on interface function analysis, such as the target call interface being a query interface with query function, a statistical interface with statistical function, a download or export interface with export function, or a write or modify interface with modification function, etc.

[0033] Specifically, different types of interfaces can correspond to different second sensitivity scores. For example, the second sensitivity score for query interfaces can be 0.1 to 0.3, the second sensitivity score for statistics interfaces can be 0.3 to 0.5, the second sensitivity score for download or export interfaces can be 0.5 to 0.7, and the second sensitivity score for write or modify interfaces can be 0.7 to 1.0.

[0034] The interface history call information may include the caller's historical behavior information, such as historical unauthorized call records, such as unauthorized attempts and malicious calls; it may also include the strength of identity authentication, such as whether real-time authentication is used, whether hardware keys are used, etc.; it may also include the risk level of the department or organization to which it belongs; and it may also include the correlation of security events within the historical time range.

[0035] Specifically, the historical call information of the interface can be input into a pre-trained first scoring prediction model. This model analyzes the historical call information of the target interface and predicts the caller's global risk score. The first scoring prediction model can be trained using historical service interface callers and their historical call information over a historical time period, along with the corresponding historical caller global risk scores. The network model can be a convolutional neural network.

[0036] Among them, the interface historical call behavior can be obtained by analyzing the historical call behavior of the target interface, which may include the frequency distribution of interface calls, historical call success rate, historical call failure rate, cross-department call frequency, and the judgment results of whether there is an abnormal call cluster.

[0037] Specifically, the historical call behavior of the interface can be input into a pre-trained second scoring prediction model. The second scoring prediction model analyzes the historical call behavior of the target interface and predicts the historical call pattern score. The second scoring prediction model can be trained using the historical call behavior of the historical service interface callers and their called historical interfaces within a historical time period, along with the corresponding historical call pattern scores, to train a pre-selected network model.

[0038] Based on the first sensitivity score, the second sensitivity score, the caller's global risk score, and the historical call pattern score, and using weighted parameters corresponding to data classification information, business association information, historical API call information, and historical API call behavior, the scores are weighted and summed to obtain the sensitivity score of the target API. The weighted parameters corresponding to data classification information, business association information, historical API call information, and historical API call behavior can be pre-set by relevant technical personnel according to actual needs.

[0039] The above technical solution improves the accuracy of determining the sensitivity score of the target call interface by comprehensively considering several dimensions such as data classification information, business association information, interface historical call information, and interface historical call behavior when generating the sensitivity score of the target call interface.

[0040] The permission approval smart contract determines the number of approval participants and the signature threshold based on a sensitivity score. The mapping relationship between the number of approval participants and the signature threshold corresponding to different sensitivities can be pre-defined by relevant technical personnel according to actual needs. In an optional embodiment, determining the number of approval participants and the signature threshold based on a sensitivity score via the permission approval smart contract includes: determining the number of approval participants and an initial threshold based on the sensitivity score and a pre-defined score range; obtaining historical call records of service interface callers over historical time periods; and generating a signature threshold based on the historical call records and the initial threshold.

[0041] The score ranges for different sensitivity scores can correspond to different numbers of approval participants and initial thresholds. See Table 1 for details. It also includes the setting of the minimum number of approval participants and examples of applicable scenarios.

[0042] Table 1 Based on the sensitivity score S, the sensitivity score range to which the sensitivity score belongs can be determined, along with the corresponding number of approval participants and the initial threshold. The initial threshold can be directly used as the final signature. To further improve the accuracy of the signature threshold determination, historical call records of service interface callers over historical time periods can be obtained, and a signature threshold can be generated based on these historical call records and the initial threshold.

[0043] The historical call records can include historical violation records, for example, if there are historical violation records, such as unauthorized attempts, the initial threshold will be automatically updated and increased. For example, if the initial threshold is 3 / 4, the initial threshold will be increased to 4 / 4, that is, all four approval participants need to pass in order to confirm the authentication is successful.

[0044] Optionally, if an abnormality is detected in the approval process, such as an excessively short approval time or an abnormal geographical location, or if the caller has a recent record of violations, such as unauthorized attempts, for example, if the interface returns 403 / 404 / 405, or if the interface is currently under high load or security alarm status, the required initial threshold can be automatically increased.

[0045] Optionally, for highly sensitive APIs, not only can the number of approval participants be increased, but a mechanism for differentiating the weights of approval participants can also be introduced. For example, core approvers, such as data owners and business managers, are required to participate in the approval process, and their corresponding weight parameter can be set to 1.0, meaning they must be included in the final signature set. Optional approvers are determined based on availability and random selection, and their weight parameter can be set to 1.0, allowing them to be randomly selected from a pool of candidates to prevent collusion risks caused by fixed combinations. Supervisory approvers are audit or compliance departments, and their weight can be set to 1.5, meaning 1 vote is equivalent to 1.5 votes, allowing them to participate under specific scenarios.

[0046] The above technical solution uses a smart contract for permission approval to determine the number of approval participants and the initial threshold based on a sensitivity score and a preset score range. It also generates a signature threshold based on the historical call records of service interface callers over a historical time period. This achieves automatic adaptation to different protection requirements for APIs with different sensitivity levels, provides a fast approval channel for special scenarios to improve the efficiency of service interface calls, and solves the problem of efficiency and security imbalance caused by "one-size-fits-all" protection. The signature threshold is dynamically set for different scenario modes, taking into account the high efficiency requirements of both normal and special scenarios.

[0047] Based on the number of approval participants and the signature threshold, a permission application record table is generated. This table includes the DID of each approval participant and details of the application. Specifically, the permission approval smart contract automatically associates several approval participants, including service interface gateways, based on the number of participants. For example, in a digital government scenario, the automatically associated approval participants could include the government API gateway system (service interface gateway), the government data bureau, and the market supervision bureau. The DID of each approval participant and the details of the application are recorded in the permission application record table, and the table is stored on the blockchain. The details of the application can include parameters such as the DID of the service interface caller, the call request identifier, the service interface caller's qualification information and the purpose of the interface, the application time, and the signature threshold.

[0048] The permission approval smart contract generates permission approval events and broadcasts them on the blockchain. When a blockchain node hears a permission approval event, it determines whether the permission approval event is related to itself by querying the permission application record table.

[0049] The above technical solution determines the sensitivity score of the target call interface by calling the permission approval smart contract, and dynamically determines the number of approval participants and the signature threshold based on the sensitivity score. Based on the number of approval participants, it determines several approval participants to participate in this approval, as well as the signature threshold for subsequent multi-signature verification. After generating a permission application record table, it broadcasts the permission approval event for blockchain nodes to listen to, realizing the event on-chain and the dynamic determination of approval participants, providing basic information for subsequent multi-signature approval.

[0050] In an optional embodiment, after uploading the permission request record table to the blockchain and generating and broadcasting the permission approval task on the blockchain, the method further includes: When a user detects its own permission approval event through blockchain event monitoring, it queries the on-chain permission application record table based on its own DID to obtain the service interface caller's call application details. Based on these details, it generates a call approval result for the service interface caller. It then broadcasts this approval result to the blockchain and receives approval results from other approval participants (excluding itself). The call permission approval smart contract, based on its own and other participants' approval results, and using a signature threshold, generates a call permission status for the service interface caller. Finally, it stores the service interface caller's call permission status on the blockchain.

[0051] When a service interface provider detects its own permission approval event through blockchain event monitoring, it queries the permission application record table on the chain based on its own DID to obtain the call application details of the service interface caller. It should be noted that other approval participants, including the service interface provider, participate in the approval process as blockchain nodes, and the process is identical. This embodiment only uses the service interface provider as an example to describe the approval process in detail.

[0052] Specifically, the call application details are obtained by querying the on-chain permission application record table based on the user's own DID. These details may include the service interface caller's qualifications and the purpose of the interface. Based on these details, the service interface call request is reviewed, and an approval result is obtained after confirming the request's validity. The approval result is either "agree" (approved) or "reject" (not approved). The approval result is then signed with the user's private key and broadcast on the blockchain. This private key signing ensures the approval is tamper-proof and non-repudiable. If the approval result is "reject" (not approved), a reason for rejection or failure must be provided, such as the company's qualifications not meeting the requirements. The signature data may include the DID of the approval participant, the application identifier, the approval result, and the signature time.

[0053] The smart contract for approving service interface calls iterates through the approval results in real time. Based on its own approval results for service interface callers and those of other approval participants, it determines whether the number of approved results has reached the signature threshold. If so, the service interface caller's access permission status is determined to be authorized; otherwise, the access permission status is determined to be inaccessible. The access permission status of the service interface caller is stored on-chain. A new record is added to the on-chain routing table, including the service interface caller's DID, the target API identifier, access permission status, access validity period, and multi-signature hash, for subsequent verification.

[0054] If the number of approved approvals does not reach the signature threshold, the smart contract for authorization approval records the rejection reason, such as only one approval participant approving the application, thus failing to reach the signature threshold, and records the rejection reasons of other unapproved approval participants. The service interface caller is notified that the application data can be retained on the connection for later traceability.

[0055] When a service interface caller has a service interface call requirement, a service interface call request is generated. This request may include the caller's DID, the API parameters of the target interface to be called, a request timestamp, and a private key signature. A signed service interface call request is then generated and forwarded by the service interface gateway.

[0056] It's important to note that the service interface gateway only performs routing and forwarding and does not participate in authentication or authorization. The service interface gateway can pre-cache a routing registry, which can be retrieved and stored from the blockchain. This routing registry can record the API addresses of several service interface providers. When the service interface gateway's cache matches the target API called by the service interface caller, it forwards the service interface call request to the service interface provider corresponding to the cached target API based on the API address of the target API. When the service interface gateway's cache does not match the target API called by the service interface caller, it queries the latest routing registry on the blockchain, determines the target API called by the service interface caller after the cache is updated, and forwards the service interface call request to the service interface provider corresponding to the cached target API based on the API address of the target API.

[0057] When the service interface provider receives a service interface call request from the service interface gateway, it parses the request, determines the decentralized identifier (DID) of the server caller and the private key signature of the request, and performs signature verification and authorization verification on the private key signature based on the DID of the server caller, and generates a verification result.

[0058] In one optional embodiment, the signature of the request private key is verified based on the decentralized identifier of the service interface caller, and the query permission of the service interface caller is verified to generate a verification result, including: Based on the decentralized identifier of the service interface caller, the target public key of the service interface caller is retrieved from the locally cached public key record table. The public key record table records at least one candidate public key corresponding to each candidate caller. If the target public key of the service interface caller is successfully retrieved from the local cache, the signature validity of the request private key is verified using the target public key to obtain a signature verification result. If the signature verification result is successful, the caller's call permission status is retrieved from the locally cached routing table. If the caller's call permission status is successfully retrieved from the local cache and the call permission status is "existing call permission", a verification result of successful verification is generated. If the caller's call permission status is successfully retrieved from the local cache and the call permission status is "does not exist call permission", a verification result of failed verification is generated.

[0059] Based on the decentralized identifier of the service interface caller, the target public key of the service interface caller is retrieved from the locally cached public key record table. The public key record table pre-caches at least one candidate public key corresponding to a candidate caller from the blockchain. Optionally, if the target public key of the service interface caller is not successfully retrieved from the local cache, the target public key of the service interface caller is retrieved from the blockchain and cached locally.

[0060] The signature validity of the request private key is verified using the target public key, resulting in a signature verification result. This result can be either successful or unsuccessful. If the signature verification is successful, the caller's access permission status is retrieved from the locally cached routing table. This locally cached routing table can record the access permission status of several service interface callers. Optionally, if the service interface caller's access permission status is not successfully retrieved from the local cache, it is retrieved from the blockchain and cached locally.

[0061] If the call permission status is "permitted," a successful verification result is generated; if the call permission status is "no permission," a failed verification result is generated. If the verification result is successful, the service interface call request is executed. The API business logic is executed, a request-response result is generated, and the request-response result is sent back to the service interface caller. If the verification result is "verification failed," an error response is returned to the service interface caller, such as invalid signature or expired permission, and the error log is recorded locally, including the service interface caller's DID, request time, and reason for failure.

[0062] Optionally, the request response can be signed by the service interface provider with its own private key so that the service interface caller can verify the authenticity of the response.

[0063] Optionally, any role can query the entire process of permission application, approval, and access data to ensure traceability and non-repudiation.

[0064] The technical solution of this invention parses service interface call requests, verifies the signature of the request private key based on the decentralized identifier of the service interface caller obtained from the parsing, and verifies the query permissions of the service interface caller, generating a verification result. During the verification process, the query permissions of the service interface caller are generated based on the joint approval and verification of multiple approval participants. If the verification result is successful, the service interface call request is executed, and a request response result is generated. This achieves decentralized authorization of the call relationship in the service interface call process, avoiding the risk of tampering or unauthorized access that may occur when the authorization process is managed by a single gateway or centralized configuration. Furthermore, the multi-signature approval method used in the verification process improves the security and reliability of the service interface call process.

[0065] Based on the above embodiments, this embodiment also provides a method for a service interface caller to apply for calling permissions, such as... Figure 3 The diagram shows the interactive process of a service interface caller requesting access.

[0066] S31. Service interface callers apply for call permissions through the call permission approval smart contract.

[0067] S32. The permission approval smart contract stores relevant information such as the determined approval participants, signature threshold, and DID of the service interface caller as permission application events on the blockchain, which can be stored in the form of a permission application record table.

[0068] S33. The permission approval smart contract generates a multi-signature approval task. The review participants may include service interface providers and service interface gateways.

[0069] S34. The permission approval smart contract generates permission approval events and uploads them to the blockchain for approval participants to listen to.

[0070] S35. After the approval participant listens to its own permission approval event, it approves the permission approval event, generates an approval result after the approval is passed, and signs the approval result with its own private key to obtain the approval signature.

[0071] S36A. After the permission approval smart contract collects the approval signatures that have reached the signature threshold, it updates the call permission status of the service caller and puts it on the chain to update the permission application record table, and generates a permission effective notification to send to the service interface caller.

[0072] S36B: If the permission approval smart contract fails to collect the approval signature that meets the signature threshold, it will generate a permission failure reminder message and send it to the service interface caller.

[0073] Based on the above embodiments, this embodiment also provides an interface invocation method for the service interface caller, such as... Figure 4 The diagram shows the interface call interaction flow of a service interface caller.

[0074] S41. The service interface caller generates a service interface call request and uses its own DID private key to sign the service interface call request, and then sends the signed service interface call request back to the service interface gateway.

[0075] S42. The service interface gateway determines the address information of the service interface provider based on the cached query routing table. If it cannot be found in the local cache, it obtains it on the chain and caches it.

[0076] S43. The service interface gateway sends the signed service interface call request to the service interface provider based on the address information.

[0077] S44. The service interface provider verifies the received service interface call request, queries the public key of the service interface caller according to the local cache, and if it is not found, it obtains and caches it on the chain.

[0078] S45. The service interface provider uses a public key to verify the validity of the signature. If the verification is successful, the service interface caller's calling permission status is queried from the local cache. If the signature is not found in the local cache, it is retrieved from the blockchain and cached.

[0079] S46A. If the verification of the service interface caller's calling permission status is successful, the corresponding API business logic is executed, and a request response result is generated and fed back to the service interface provider.

[0080] S46B. If verifying the calling permission status of the service interface caller fails, a permission verification failure result is generated and fed back to the service interface provider.

[0081] Figure 5 This is a schematic diagram of a blockchain-based service interface invocation device provided in an embodiment of the present invention. The blockchain-based service interface invocation device provided in this embodiment of the present invention is applicable to service interface invocation scenarios with high concurrency. This blockchain-based service interface invocation device can be implemented in hardware and / or software, such as... Figure 5 As shown, the device can be configured on the service interface provider and specifically includes: a call request and response module 501, a verification module 502, a request and response module 503, and a result feedback module 504. Among them, The request response module 501 is used to respond to a service interface call request sent by the service interface gateway, parse the service interface call request, and determine the decentralized identifier (DID) and request private key signature of the server caller. The service interface call request is initiated by the service interface caller to the service interface gateway, and the service interface gateway determines the service interface provider based on the service interface call request and forwards it to the service interface provider. The verification module 502 is used to perform signature verification on the private key signature of the request based on the decentralized identifier of the service interface caller, and to perform permission verification on the query permission of the service interface caller, and generate a verification result; the query permission of the service interface caller is generated based on the joint approval and verification of multiple approval participants. The request-response module 503 is used to execute the service interface call request and generate a request-response result if the verification result is successful. The result feedback module 504 is used to feed back the request response result to the service interface caller.

[0082] The technical solution of this invention parses service interface call requests, verifies the signature of the request private key based on the decentralized identifier of the service interface caller obtained from the parsing, and verifies the query permissions of the service interface caller, generating a verification result. During the verification process, the query permissions of the service interface caller are generated based on the joint approval and verification of multiple approval participants. If the verification result is successful, the service interface call request is executed, and a request response result is generated. This achieves decentralized authorization of the call relationship in the service interface call process, avoiding the risk of tampering or unauthorized access that may occur when the authorization process is managed by a single gateway or centralized configuration. Furthermore, the multi-signature approval method used in the verification process improves the security and reliability of the service interface call process.

[0083] Optional, verification module 502, specifically used for: Based on the decentralized identifier of the service interface caller, the target public key of the service interface caller is retrieved from the locally cached public key record table; the public key record table records at least one candidate public key corresponding to each candidate caller. If the target public key of the service interface caller is successfully retrieved from the local cache, the signature validity of the request private key is verified using the target public key to obtain the signature verification result. If the signature verification result is successful, then the calling permission status of the service interface caller is queried from the locally cached routing table; If the call permission status of the service interface caller is successfully retrieved from the local cache, and the call permission status indicates that call permission exists, then a verification result indicating successful verification is generated; and, If the call permission status of the service interface caller is successfully retrieved from the local cache, and the call permission status is "no call permission", then a verification result indicating that the verification failed is generated.

[0084] Optionally, the verification module 502 is also used for: If the target public key of the service interface caller is not successfully retrieved from the local cache, then the target public key of the service interface caller is retrieved from the blockchain. If the calling permission status of the service interface caller cannot be successfully retrieved from the local cache, then the calling permission status of the service interface caller is retrieved from the blockchain.

[0085] Optionally, the device further includes: The sensitivity score determination module is used to receive the permission request of the service interface caller through the permission approval smart contract before parsing the service interface call request in response to the service interface call request sent by the service interface gateway and determining the decentralized identifier and request private key signature of the server caller. Based on the permission request, the module determines the target call interface called by the service interface caller and determines the sensitivity score of the target call interface based on the interface-related information of the target call interface. The signature threshold determination module is used to determine the number of approval participants and the signature threshold based on the sensitivity score through the permission approval smart contract. The application record generation module is used to generate an authorization application record table based on the number of approval participants and the signature threshold; the authorization application record table includes the DID of the approval participants and the call application details; The event broadcasting module is used to upload the permission application record table to the blockchain and generate and broadcast permission approval events on the blockchain.

[0086] Optionally, the device further includes: The permission approval event listening module is used to query the permission application record table on the chain based on its own DID to obtain the call application details information of the service interface caller after the permission application record table is put on the chain and the permission approval task is generated and broadcast on the chain. The approval result generation module is invoked to generate an approval result for the caller of the service interface based on the details of the call application. The other approval result receiving module is used to broadcast its own approval result for the service interface caller on the blockchain, and at the same time receive the approval results for the service interface caller sent by other approval participants; the other approval participants are approval participants other than itself. The permission status generation module is used to call the permission approval smart contract to generate the call permission status of the service interface caller based on its own call approval results for the service interface caller and the call approval results of other approval participants for the service interface caller, and based on a signature threshold. The permission status on-chain module is used to store the calling permission status of the service interface caller on the blockchain.

[0087] Optionally, the interface-related information includes data classification information, business association information, historical interface call information, and historical interface call behavior; correspondingly, the sensitivity score determination module is specifically used for: Based on the data classification information, business association information, historical interface call information, and historical interface call behavior, and using the weight parameters corresponding to the data classification information, business association information, historical interface call information, and historical interface call behavior, the sensitivity score of the target call interface is determined.

[0088] Optional, a signature threshold determination module, specifically used for: The permission approval smart contract determines the number of approval participants and the initial threshold based on the sensitivity score and a preset score range. Retrieve the historical call records of the service interface callers under the historical time period; A signature threshold is generated based on the historical call records and the initial threshold.

[0089] The blockchain-based service interface calling device provided in this embodiment of the invention can execute the blockchain-based service interface calling method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0090] Figure 6 A schematic diagram of an electronic device 60 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0091] like Figure 6 As shown, the electronic device 60 includes at least one processor 61 and a memory, such as a read-only memory (ROM) 62 and a random access memory (RAM) 63, communicatively connected to the at least one processor 61. The memory stores computer programs executable by the at least one processor. The processor 61 can perform various appropriate actions and processes based on the computer program stored in the ROM 62 or loaded from storage unit 68 into the RAM 63. The RAM 63 can also store various programs and data required for the operation of the electronic device 60. The processor 61, ROM 62, and RAM 63 are interconnected via a bus 64. An input / output (I / O) interface 65 is also connected to the bus 64.

[0092] Multiple components in electronic device 60 are connected to I / O interface 65, including: input unit 66, such as keyboard, mouse, etc.; output unit 67, such as various types of monitors, speakers, etc.; storage unit 68, such as disk, optical disk, etc.; and communication unit 69, such as network card, modem, wireless transceiver, etc. Communication unit 69 allows electronic device 60 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0093] Processor 61 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 61 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 61 executes the various methods and processes described above, such as blockchain-based service interface invocation methods.

[0094] In some embodiments, the blockchain-based service interface invocation method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 68. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 60 via ROM 62 and / or communication unit 69. When the computer program is loaded into RAM 63 and executed by processor 61, one or more steps of the blockchain-based service interface invocation method described above may be performed. Alternatively, in other embodiments, processor 61 may be configured to execute the blockchain-based service interface invocation method by any other suitable means (e.g., by means of firmware).

[0095] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0096] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0097] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0098] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0099] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0100] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0101] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and no limitation is imposed herein.

[0102] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A service interface invocation method based on blockchain, characterized in that, Applied to service interface providers, including: In response to a service interface call request sent by the service interface gateway, the service interface call request is parsed to determine the decentralized identifier (DID) and private key signature of the server caller. The service interface call request is initiated by the service interface caller to the service interface gateway, and the service interface gateway determines the service interface provider based on the service interface call request and forwards it to the service interface provider. Based on the decentralized identifier of the service interface caller, the signature of the request private key is verified, and the query permission of the service interface caller is verified, generating a verification result; the query permission of the service interface caller is generated based on the joint approval and verification of multiple approval participants. If the verification result is successful, then the service interface call request is executed, and a request response result is generated; The request response result is fed back to the service interface caller.

2. The method according to claim 1, characterized in that, The step of performing signature verification on the request private key signature based on the decentralized identifier of the service interface caller, and performing permission verification on the query permission of the service interface caller, and generating a verification result, includes: Based on the decentralized identifier of the service interface caller, the target public key of the service interface caller is retrieved from the locally cached public key record table; the public key record table records at least one candidate public key corresponding to each candidate caller. If the target public key of the service interface caller is successfully retrieved from the local cache, the signature validity of the request private key is verified using the target public key to obtain the signature verification result. If the signature verification result is successful, then the calling permission status of the service interface caller is queried from the locally cached routing table; If the call permission status of the service interface caller is successfully retrieved from the local cache, and the call permission status indicates that call permission exists, then a verification result indicating successful verification is generated; and, If the call permission status of the service interface caller is successfully retrieved from the local cache, and the call permission status is "no call permission", then a verification result indicating that the verification failed is generated.

3. The method according to claim 2, characterized in that, The method further includes: If the target public key of the service interface caller is not successfully retrieved from the local cache, then the target public key of the service interface caller is retrieved from the blockchain. If the calling permission status of the service interface caller cannot be successfully retrieved from the local cache, then the calling permission status of the service interface caller is retrieved from the blockchain.

4. The method according to claim 1, characterized in that, Before responding to the service interface call request sent by the service interface gateway, parsing the service interface call request, and determining the decentralized identifier and request private key signature of the server caller, the method further includes: The smart contract for permission approval receives permission requests from the service interface caller. Based on the permission request, it determines the target call interface to be called by the service interface caller and determines the sensitivity score of the target call interface based on the interface-related information of the target call interface. The permission approval smart contract determines the number of approval participants and the signature threshold based on the sensitivity score. Based on the number of approval participants and the signature threshold, a permission request record table is generated; the permission request record table includes the DID of the approval participants and the details of the call request. The permission application record table is uploaded to the blockchain, and permission approval events are generated and broadcast on the blockchain.

5. The method according to claim 4, characterized in that, After adding the permission request record table to the blockchain and generating and broadcasting the permission approval task on the blockchain, the process further includes: When a user detects its own permission approval event through blockchain event monitoring, it queries the permission application record table on the chain based on its own DID to obtain the call application details of the service interface caller. Based on the details of the call request, generate a call approval result for the service interface caller; The system broadcasts its own approval results for the service interface caller on the blockchain, and simultaneously receives approval results for the service interface caller from other approval participants; these other approval participants are those other than itself. The permission approval smart contract generates the call permission status for the service interface caller based on its own approval result for the caller and the approval results of other approval participants for the caller, and on a signature threshold. The calling permission status of the service interface caller is stored on the blockchain.

6. The method according to claim 4, characterized in that, The interface-related information includes data classification information, business association information, historical interface call information, and historical interface call behavior; correspondingly, determining the sensitivity score of the target interface based on the interface-related information of the target interface includes: Based on the data classification information, business association information, historical interface call information, and historical interface call behavior, and using the weight parameters corresponding to the data classification information, business association information, historical interface call information, and historical interface call behavior, the sensitivity score of the target call interface is determined.

7. The method according to claim 4, characterized in that, The process of determining the number of approval participants and the signature threshold through the permission approval smart contract based on the sensitivity score includes: The permission approval smart contract determines the number of approval participants and the initial threshold based on the sensitivity score and a preset score range. Retrieve the historical call records of the service interface callers under the historical time period; A signature threshold is generated based on the historical call records and the initial threshold.

8. A service interface invocation device based on blockchain, characterized in that, Configuration on the service interface provider, including: The request and response module is used to respond to service interface call requests sent by the service interface gateway, parse the service interface call request, and determine the decentralized identifier (DID) and request private key signature of the server caller. The service interface call request is initiated by the service interface caller to the service interface gateway, and the service interface gateway determines the service interface provider based on the service interface call request and forwards it to the service interface provider. The verification module is used to perform signature verification on the private key signature of the request based on the decentralized identifier of the service interface caller, and to perform permission verification on the query permission of the service interface caller, and generate a verification result; the query permission of the service interface caller is generated based on the joint approval and verification of multiple approval participants. The request-response module is used to execute the service interface call request and generate a request-response result if the verification result is successful. The result feedback module is used to send the request response result back to the service interface caller.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the blockchain-based service interface invocation method according to any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the blockchain-based service interface invocation method as described in any one of claims 1-6.

Images