A trustless and dependency-free intelligent service implementation method

Abstract

The application discloses a kind of de-trust and de-reliance intelligent service implementation methods, including publishing party based on signature verification in service node publishing and registering service, the service loads dynamic microservice;User party initiates service call, applies for service access right to publishing party, and service access right configuration is carried out by publishing party;User direction service node sends call application, and service node obtains service configuration information according to call application, and authentication and access type confirmation are carried out in sequence to call application;Wherein authority and access confirmation include the identification of dynamic microservice respectively, and in the case of loading dynamic microservice, authority verification or service call is carried out by microservice;Service node feeds back service call result to user party.The application realizes service publishing and using de-trust and de-reliance, so that special service not supporting general protocol can also provide service to the outside, so that anyone can publish and use various general or special services without restriction.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, in particular to a trustless and dependency-free intelligent service implementation method. BACKGROUND

[0002] The network service platform in the prior art includes three types, namely traditional cloud service platform, service network architecture and TEE-based blockchain service platform. Among them, the TEE-based blockchain service platform, such as Huawei Cloud Blockchain Engine, combines blockchain and TEE technology to provide a trusted computing environment, supports the secure execution of smart contracts, and has certain decentralization features, but also has the following problems: application scenario is limited, mainly for blockchain applications, and has insufficient versatility; user experience is complex, still needs complex password management and blockchain interaction, and the registration account system is complex; service release threshold requires smart contract development capability, and the technical threshold is high; the platform cannot access services that do not implement access protocols; authentication and charging depend on the platform and cannot be customized; performance bottleneck, limited by the blockchain consensus mechanism, difficult to support high-frequency service calls. For example, the patent with the patent number 202011529847.0 and the name of service request method and device based on blockchain, but the patent needs to construct an intelligent contract for managing a secure access key, which has the above-mentioned shortcomings, complex password management and high technical threshold. SUMMARY

[0003] The present application mainly solves the problems of high access threshold, complex authentication, custom service access, and platform-dependent authentication and charging in the existing service provision mode, and provides a trustless and dependency-free intelligent service implementation method.

[0004] The above technical problems of the present application are mainly solved by the following technical scheme: a trustless and dependency-free intelligent service implementation method, comprising the following steps:

[0005] The publisher publishes and registers services based on signature verification in the service node, and the service loads dynamic microservices;

[0006] The user initiates service call and applies for service access permission to the publisher, and the publisher configures service access permission;

[0007] The user sends a call application to the service node, and the service node obtains service configuration information according to the call application, authenticates and confirms the access type of the call application in sequence;

[0008] Among them, the permission and access confirmation respectively include the identification of dynamic microservices, and the microservices perform permission verification or service call in the case of loading dynamic microservices;

[0009] The service node feeds back the service call result to the user side.

[0010] The application realizes decentralized and dependency-free intelligent services, realizes trustless and dependency-free service publishing and use, enables special services that do not support general protocols to conveniently provide services through micro-service functions, and enables anyone to publish and use various general or special services without restrictions.

[0011] The application makes service publishing without access threshold, so that anyone can directly publish services to the outside; a decentralized user and authentication system is used to build an access authentication system for published services; dynamic micro-service capabilities are used to enable special services based on private protocols to be quickly published and externally served, and service publishers can define service authentication and billing logic according to service characteristics; ensure the security and reliability of the dynamic micro-service loaded by the service publishing; and enable any user with decentralization to directly access the service after passing the permission.

[0012] As a preferred scheme, the publisher publishes and registers services based on signature verification in the service node, specifically including:

[0013] The publisher sets service configuration information, and signs the service configuration information and the block height with the publisher's private key;

[0014] The publisher sends the service configuration information, the block height, the publisher's public key and the signature data to any connected service node;

[0015] After the service node verifies the signature, it saves the service configuration information and generates a service ID;

[0016] The service node registers the published service on the blockchain, and the publisher publishes the service.

[0017] Any publisher can publish services without platform audit, reducing the service publishing threshold. The service publisher does not need to create an account or perform account authentication, but only needs to send the public key and service configuration information to the service node to publish the service. The service publisher only needs to focus on the core business logic and does not need to build a complex user management and authentication system, simplifying the development process.

[0018] The publisher provides service-related service configuration information, including service topic, service name, service type, interface type, access token, authentication and billing micro-service CID (which can be empty), dynamic service access micro-service CID (which can be empty), and service-specific configuration (such as AI model configuration including model name, temperature parameter, maximum token number, and various sampling parameters).

[0019] Wherein the microservice CID is the CID generated after the microservice code is uploaded to the IPFS network, which can be downloaded from the IPFS network through the IPFS protocol. The code block downloaded from the same CID is exactly the same, ensuring the trustless ability of the code block.

[0020] The publisher signs the service configuration information and the block height obtained from the blockchain associated with the intelligent service platform with the publisher private key. The publisher generates a publication request and sends it to any one of the service nodes that have entered the network under the intelligent service platform. The publication request includes service configuration information, block height, publisher public key, and signature data. The service nodes that have entered the network run in a TEE environment and have passed the TEE remote authentication challenge.

[0021] After receiving the publication request, the service node verifies the signature. After the signature is verified, the service configuration information is saved locally, a service ID is generated, and the original authentication configuration is generated locally. The publisher public key is configured as the manager of the service.

[0022] The service node registers the published service on the blockchain. The registration information includes: service ID, service node access information, service owner, and each microservice CID associated with the service. The service node feeds back the service ID to the publisher.

[0023] After the service publication is successfully registered, the service publisher needs to publish the service information to the outside for users to call. The published service information includes: service ID, service subject, service name, access parameter, and service introduction.

[0024] The service ID is mainly used to quickly locate the service node where the service configuration is located.

[0025] The service subject is mainly used by the service publisher to manage service use. Multiple services can be categorized into one subject, such as all AI model access can be categorized into a model access subject.

[0026] The service name is the actual service name provided to the outside. Together with the publisher public key and service subject, it locates the service configuration information on the service node.

[0027] The access parameter determines the required parameter set for accessing the service, including parameter name, whether it is mandatory, parameter type, etc. The user side provides it in the form of key-value.

[0028] The service introduction is an introduction to the service.

[0029] As an optional solution, the user initiates a service access permission application to the publisher, which includes the user public key.

[0030] In the scheme, the user side needs to apply for service access permission when calling the service. The user side provides the user public key to the publisher to apply for service access permission by obtaining the service configuration information published by the publisher, and the publisher configures the access permission and feeds back the pass information to the user side.

[0031] As a preferred scheme, the publisher signs the access permission configuration containing the user public key to be configured by using the publisher private key;

[0032] According to the service ID, the location information of the service node configuring the service is queried from the block chain;

[0033] The access permission configuration is signed and sent to the service node configuring the service;

[0034] After receiving the information, the service node verifies the signature, and if the verification is passed, the service access permission configuration is saved.

[0035] In the scheme, the publisher signs the parameters of the access permission configuration by using the publisher private key after combining the parameters, and the parameters of the access permission configuration include: the user public key to be configured, the access permission (including management, ordinary calling, calling times, calling frequency of each period, etc.) and the current block height of the block chain associated with the platform. The publisher queries the location information of the service node configuring the service from the block chain according to the service ID, generates a service access permission configuration request including the access permission configuration and the signature, and sends it to the service node. After receiving the request, the service node configuring the service verifies the signature by using the publisher public key, and saves the service access permission configuration information to the local after the verification is passed.

[0036] As a preferred scheme, the service node obtains the service configuration information according to the calling application, specifically including:

[0037] The user side signs the calling parameters containing the service ID by using the user private key;

[0038] The calling parameters, signature and user public key are sent to any service node;

[0039] After the service node verifies the signature, it is judged whether the current service node has expired service configuration information,

[0040] If not, the service node determines the service node where the service configuration information is located according to the service ID, requests the service configuration information from the service node, and caches the service configuration information.

[0041] After gaining service access, users select a pre-built, universal interface call method from the service platform, such as RESTful, API, or gRPC, as the service call protocol. Calls between different services can use the same interface, differing only in parameters. Users combine and sign the call parameters using their private key. These parameters include the service ID, service subject, service name, required service parameters, and block height. Users then send the call parameters, their public key, and the signature to any network-connected service node, which executes the service call. This eliminates the need to submit applications to a centralized platform for review, achieving a decentralized approach. This solution optimizes the user experience, allowing for zero-configuration access without the need for API keys or dedicated account registration; instant authorization allows users to directly call services after gaining permission; and it reduces usage costs and simplifies the service call process.

[0042] After receiving a service access request from a user, the service node first verifies the signature. If the verification is successful, it first checks whether the service configuration information is cached locally and whether the service configuration information has expired. If the service configuration information is cached and has not expired, the subsequent authentication and access confirmation process is carried out. If the service configuration information is not cached or the service configuration information has expired, the service node where the service configuration information is located is determined by querying the blockchain based on the service ID in the call parameters. The service node is then sent a request to retrieve the service configuration information until it is successfully retrieved, and the information is cached for a period of time.

[0043] As a preferred embodiment, the microservices include authentication and accounting microservices and dynamic service access microservices;

[0044] Authentication type confirmation includes the identification of authentication and billing microservices, while access type confirmation includes the identification of dynamic service access services.

[0045] Dynamic microservices are loaded by the publisher as needed, improving system flexibility. There are two types of microservices: authentication and accounting microservices and dynamic service access microservices; these are registered independently and do not interfere with each other.

[0046] In addition to the general authentication and billing modules, publishers can customize dynamic microservices for authentication and billing of services to complete the authentication and billing capabilities for service access users.

[0047] The authentication and billing microservice is primarily responsible for implementing dedicated authentication and billing logic for accessing backend services. This allows publishers to completely replace the platform's threshold authentication module with their own implemented authentication and billing logic, meeting various business needs without being limited by the platform's capabilities.

[0048] In addition to the general service, the access of many services is highly customized based on the general service calling protocol, and the general service calling protocol cannot call these service capabilities. By introducing protocol dynamic processing micro-service capabilities, these special services can also be smoothly accessed to the decentralized general service platform.

[0049] The dynamic service access micro-service mainly converts the user's general service calling protocol into the special protocol of the backend service, completes the service calling, so that even if the published service calling protocol platform is not pre-installed and the publisher cannot modify or adjust the backend service, the service can be provided to the outside through the micro-service, making the platform publishing service unrestricted and achieving the purpose of universality.

[0050] As a preferred solution, the service node detects the service authentication configuration type according to the service configuration information,

[0051] If it is an authentication and charging micro-service, the authentication and charging micro-service CID is obtained from the blockchain, the authentication and charging micro-service code block is obtained, the micro-service is started by the service node, the service calling request calling parameters are transmitted into the micro-service, and the authentication and charging operation is completed by the micro-service;

[0052] If it is a general configuration, the original authentication configuration is called for authentication operation.

[0053] The authentication operation is to obtain the service access permission configuration from the service node of the configuration service, and to judge whether the service access permission is obtained according to the comparison of the user's public key.

[0054] The service node authenticates and confirms the calling application in the service calling process of the user side, which specifically judges whether the service authentication configuration is an authentication and charging micro-service. If the service is a general configuration, the original authentication module is directly called for authentication operation. If the service is configured with an authentication and charging micro-service, the authentication and charging micro-service code block is obtained, the micro-service running environment is started by the service node, the micro-service is started, and the service calling request calling parameters are transmitted into the micro-service, and the authentication and charging operation is completed by the micro-service. The specific authentication operation is that the current service node obtains the service access permission configuration from the service node of the configuration service, obtains the user's public key, compares the user's public key provided by the user who initiates the service calling with the user's public key obtained from the service node of the configuration service one by one, if there is the same user's public key, the authentication is passed, then the subsequent operation is performed, if there is no same user's public key, the authentication fails, returns an error, and ends the service calling process.

[0055] As a preferred solution, the service node detects the service access type according to the service configuration information,

[0056] If it is dynamic service access microservice, the dynamic service access microservice CID is obtained from the blockchain, the dynamic service access microservice code block is obtained, the microservice is started by the service node, the calling parameters of the service calling request and the backend access configuration information are transmitted into the microservice, protocol conversion is performed and the service is called;

[0057] If it is pre-configuration, the pre-configuration module is called to call the service;

[0058] The service node feeds back the calling result to the user side.

[0059] In the service calling process of the user side, after the authentication operation is completed, the service node confirms the access of the calling application. Specifically, it is judged whether the service access type is dynamic service access microservice. If it is pre-configuration mode, the pre-configuration module is directly selected to call the service, and the service calling result is returned to the user side. If it is dynamic service access microservice, the dynamic service access microservice code block is obtained, the microservice is started by the service node, the network underlying agent of the corresponding protocol is registered according to the microservice configuration (registered by the service node program when it is started and run, including tcp, http, websocket, grpc, etc.), the network access ability of the microservice is provided, the calling parameters of the service calling request and the backend access configuration information (including access endpoint, backend service authentication parameters, etc.) are transmitted into the microservice, and the microservice is waited for feedback. The microservice performs protocol conversion and accesses the backend service through the network agent. The microservice returns the service calling result to the service node, and the service node returns the service calling result to the user side.

[0060] As a preferred scheme, the microservice code block obtaining process comprises:

[0061] The service node judges whether the microservice code block corresponding to the microservice CID is cached locally,

[0062] If not, the microservice code block is pulled from the ipfs network through the ipfs protocol.

[0063] This scheme is used to judge whether the microservice code block is cached locally in the service node, and is respectively applicable to the authentication type confirmation of obtaining the authentication charging microservice code block and the access type confirmation of obtaining the dynamic service access microservice code block. If the microservice code block is cached locally, the microservice is directly started according to the code block. If the microservice code block is not cached locally, the microservice code block is pulled from the ipfs network through the ipfs protocol according to the microservice CID, and the pulled code block is ensured to be trustless based on the ipfs pulling code block.

[0064] As a preferred scheme, the service loads the dynamic microservice, specifically comprising:

[0065] The publisher writes a service code segment, uploads the service code segment to the IPFS network, and obtains the microservice CID;

[0066] Based on the service ID to be configured, query the blockchain to determine the service node information for publishing the service;

[0067] A microservice configuration request is sent to the service node. After verifying the signature, the service node audits the microservice code. Once the audit is passed, the microservice configuration information is saved, and a request is sent to the blockchain to change the service configuration information. The microservice CID is then registered and bound to the service.

[0068] The publisher can freely write service code segments based on real business needs using interpreted languages ​​such as JavaScript or Python, and implement a unified entry point method;

[0069] Taking the authentication and accounting microservice as an example, such as the JavaScript function _Auth(userpubkey, repParams, authConfig, authInfo), the parameters are defined as follows:

[0070] userpubkey: The user to be authenticated;

[0071] repParams: Request parameters, which can be freely defined according to business needs, and may include operation type, operation scope, etc.

[0072] authConfig: Service authentication configuration;

[0073] authInfo: The cumulative authentication information of the user to be authenticated in the authentication and billing processing tag;

[0074] Return value: Authentication status, cumulative authentication information indicating the completion of authentication and billing processing.

[0075] Taking dynamic service access to microservices as an example,

[0076] For example, the parameters of JavaScript's _Transform(userpukey, serviceConfig, regParams, callback) are defined as follows:

[0077] userpukey: The user making the request;

[0078] serviceConfig: Service configuration information, including backend service access endpoints, backend service authorization information (such as apikey), and dedicated service configuration information;

[0079] regParams: The generation of the request, which can be freely defined according to the business requirements of calling the service interface;

[0080] callback: The result callback interface, which returns the result of the service call. In JavaScript, it is defined as Callback(state, result), where state represents the state and result represents the result.

[0081] Return value: This is an asynchronous call; the return value indicates that the service call has ended.

[0082] Upload the service code segment to the IPFS network to obtain the microservice CID.

[0083] Based on the service ID to be configured, query the blockchain to determine the service node information for publishing the service;

[0084] Send a microservice configuration request to the service node. For example, for the authentication and accounting microservice, the request content includes: service ID, authentication and accounting microservice CID, and the signature and public key of the information. For the dynamic access microservice, the request content includes: service ID, dynamic scope microservice CID, the underlying network protocol that the microservice needs to register, and the signature and public key of the information.

[0085] Upon receiving a microservice configuration request, the service node verifies the signature and identifies it as a microservice registration request. It then performs a microservice code audit based on the TEE environment. The audit includes:

[0086] Scan the code to ensure it does not access any local files;

[0087] Scan the code to ensure it does not access any network information;

[0088] Scan the code to ensure it does not access any unregistered network protocols;

[0089] Scan the code to ensure it does not access any network addresses (addresses that need to be accessed must be dynamically imported through service configuration information during subsequent operation).

[0090] Once the audit is passed, the microservice configuration information is saved locally, and a request is sent to the blockchain to change the service configuration information, registering and binding the microservice CID with the service.

[0091] Therefore, the advantages of this invention are: it removes entry barriers for service publishing, allowing anyone to directly publish services; it utilizes a decentralized user and authentication system to build an access authentication system for published services; it leverages dynamic microservice capabilities to enable the rapid publication and external service of dedicated services based on private protocols, and allows service publishers to independently define the authentication and billing logic of services according to their characteristics; it ensures the security and reliability of the dynamic microservices loaded during service publication; and it allows any user with decentralized access to directly access services after authorization. Attached Figure Description

[0092] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0093] The technical solution of the present invention will be further described in detail below through embodiments and in conjunction with the accompanying drawings.

[0094] Example:

[0095] This embodiment presents a method for implementing trustless and dependency-free smart services. By utilizing a blockchain network, a TEE environment, and TEE remote authentication, a decentralized service network is built. The division of labor between the blockchain and the TEE service node network is set as follows:

[0096] Customized blockchain node network: responsible for service node onboarding authentication and authorization, service registration, dynamic microservice CID management, etc.

[0097] The service nodes run entirely in a TEE environment, and the code logic is made public and transparent through remote authentication via TEE.

[0098] The private keys used by the service node to interact with the blockchain node are stored in a TEE environment, ensuring that even the owner of the physical machine of the service node cannot access them.

[0099] When the blockchain starts, it pre-configures the service nodes allowed to join the network and the Enclaveid of the node service program (Enclaveid is the hardware identity identifier of the Enclave generated by the TEE environment, and Enclave is an isolated secure execution area in TEE). Core data operations on the blockchain can only be initiated by service nodes that have been authenticated by the blockchain.

[0100] The service node integrates virtual runtime environments for interpreted languages ​​such as JavaScript and Python, as well as corresponding service auditing modules.

[0101] The general service adaptation settings are as follows:

[0102] Service nodes pre-integrate implementations of common protocols into the service platform, such as TCP, HTTP, WebSocket, GPRC, REST / OpenAP, JSON-RPC, MCP, SSE, OpenAI, and Claude-related llms semi-custom communication protocols.

[0103] Service nodes are pre-integrated with commonly used authentication and billing capabilities into the service platform, such as commonly used hierarchical permission management and access count capabilities.

[0104] A method for implementing trustless and dependency-free intelligent services, such as Figure 1 As shown, it includes the following steps:

[0105] The publisher publishes and registers services on the service node based on signature verification, and the services load dynamic microservices.

[0106] When a user initiates a service call, they request service access permissions from the publisher, who then configures the service access permissions.

[0107] The user sends a call request to the service node. The service node obtains the service configuration information based on the call request and performs authentication and access type confirmation on the call request in sequence.

[0108] The permissions and access confirmation include the identification of dynamic microservices, and when dynamic microservices are loaded, the microservices perform permission verification or service calls.

[0109] The service node will then send the service call results back to the user.

[0110] As a preferred embodiment, the publisher publishes and registers services on the service node based on signature verification, and the service loads dynamic microservices, including the following steps:

[0111] The publisher sets up service configuration information and signs the service configuration information and block height using the publisher's private key;

[0112] The publisher sends the service configuration information, block height, publisher public key, and signature data to any service node that is already connected to the network;

[0113] After the service node verifies the signature, it saves the service configuration information and generates a service ID.

[0114] Service nodes register and publish services on the blockchain, and the publisher announces the services.

[0115] Specifically, the publisher sets service configuration information related to the service, including service topic, service name, service type, interface type, access token, authentication and accounting microservice CID (optional), dynamic service access microservice CID (optional), and service-specific configuration (such as AI model configuration including model name, temperature parameters, maximum number of tokens, and various sampling parameters).

[0116] The microservice CID is generated after the microservice code is uploaded to the IPFS network. It can be downloaded from the IPFS network via the IPFS protocol. The code blocks downloaded with the same CID are completely identical, ensuring the trustlessness of the code blocks.

[0117] The publisher uses its private key to sign the service configuration information and the block height obtained from the blockchain associated with the smart service platform. The publisher generates a publishing request and sends it to any service node already connected to the smart service platform. The publishing request includes the service configuration information, block height, publisher's public key, and signature data. The service node already connected to the platform is running in a TEE environment and has passed the TEE remote authentication challenge.

[0118] After receiving a publish request, the service node verifies the signature. If the signature is verified, the service configuration information is saved locally, a service ID is generated, and the original authentication configuration is generated locally, configuring the publisher's public key as the administrator of the service.

[0119] Service nodes register and publish services on the blockchain. Registration information includes: service ID, access information for the node hosting the service, service owner, and CIDs of all associated microservices. The service node then sends the service ID back to the publisher.

[0120] After successful service publication and registration, the service publisher needs to publicly disclose the service information for users to access. The disclosed service information includes: service ID, service entity, service name, access parameters, and service description.

[0121] Among them, the service ID is mainly used to quickly locate the service node where the service configuration is located.

[0122] Service topics: These are mainly used by service publishers to manage service usage. Multiple services can be grouped into one topic, such as grouping all accesses to large AI models into one model access topic.

[0123] Service Name: The actual name of the service provided to the outside world, which, together with the publisher's public key and the service entity, locates the service configuration information on the service node.

[0124] Access parameters: This determines the set of all parameters required to access the service, including parameter name, whether it is required, parameter type, etc., which are provided by the user in key-value format.

[0125] Service Description: An introduction to the service.

[0126] In this embodiment, the service loads dynamic microservices, which mainly include authentication and accounting microservices and dynamic service access microservices. In subsequent steps, authentication type confirmation includes the identification of the authentication and accounting microservices, and access type confirmation includes the identification of the dynamic service access service.

[0127] Dynamic microservices are loaded by the publisher as needed, improving system flexibility. There are two types of microservices: authentication and accounting microservices and dynamic service access microservices; these are registered independently and do not interfere with each other.

[0128] In addition to the general authentication and billing modules, publishers can customize dynamic microservices for authentication and billing of services to complete the authentication and billing capabilities for service access users.

[0129] The authentication and billing microservice is primarily responsible for implementing dedicated authentication and billing logic for accessing backend services. This allows publishers to completely replace the platform's threshold authentication module with their own implemented authentication and billing logic, meeting various business needs without being limited by the platform's capabilities.

[0130] In addition to general services, access to many services is achieved through highly customized approaches based on general service invocation protocols. These general service invocation protocols typically cannot invoke these service capabilities. By introducing dynamic microservice capabilities through protocol processing, these specialized services can also be successfully integrated into the decentralized general service platform.

[0131] Dynamic service access microservices primarily convert the user's general service call protocol into a backend service's dedicated protocol to complete the service call. This way, even if the platform does not have a pre-built service call protocol and the publisher cannot modify or adjust the backend service, the service can still be provided externally through this microservice, making the platform's service publishing unrestricted and achieving the goal of universality.

[0132] The steps to implement microservice loading are as follows:

[0133] The publisher writes a service code segment, uploads the service code segment to the IPFS network, and obtains the microservice CID;

[0134] Based on the service ID to be configured, query the blockchain to determine the service node information for publishing the service;

[0135] A microservice configuration request is sent to the service node. After verifying the signature, the service node audits the microservice code. Once the audit is passed, the microservice configuration information is saved, and a request is sent to the blockchain to change the service configuration information. The microservice CID is then registered and bound to the service.

[0136] This embodiment will be used to specifically illustrate the authentication and accounting microservice and dynamic service access microservice. The loading process of the authentication and accounting microservice includes:

[0137] 1. The publisher uses interpreted languages ​​such as JavaScript or Python to freely write service code snippets according to actual business needs and implements a unified entry point method, such as JavaScript's _Auth(userpubkey, repParams, authConfig, authInfo), with the parameters defined as follows:

[0138] userpubkey: The user to be authenticated;

[0139] repParams: Request parameters, which can be freely defined according to business needs, and may include operation type, operation scope, etc.

[0140] authConfig: Service authentication configuration;

[0141] authInfo: The cumulative authentication information of the user to be authenticated in the authentication and billing processing tag;

[0142] Return value: Authentication status, cumulative authentication information indicating the completion of authentication and billing processing.

[0143] 2. Upload the service code segment to the IPFS network to obtain the microservice CID.

[0144] 3. Based on the service ID to be configured, query the blockchain to determine the service node information for publishing the service.

[0145] 4. Send a microservice configuration request to the service node. The request includes: service ID, authentication and accounting microservice CID, and the signature and public key of the information.

[0146] 5. Upon receiving a microservice configuration request and verifying the signature, the service node identifies it as a registration request for the authentication and accounting microservice. It then performs a microservice code audit based on the TEE environment. The audit includes:

[0147] Scan the code to ensure it does not access any local files;

[0148] Scan the code to ensure it does not access any network information.

[0149] 6. After the audit is passed, the microservice configuration information is saved locally, and a request is sent to the blockchain to change the service configuration information, registering and binding the microservice CID with the service.

[0150] The dynamic service access microservice loading process includes:

[0151] 1. The publisher uses interpreted languages ​​such as JavaScript or Python to freely write service code snippets according to actual business needs and implements a unified entry point method, such as JavaScript's _Transform(userpukey, serviceConfig, regParams, callback), with the parameters defined as follows:

[0152] userpukey: The user making the request;

[0153] serviceConfig: Service configuration information, including backend service access endpoints, backend service authorization information (such as apikey), and dedicated service configuration information;

[0154] regParams: The generation of the request, which can be freely defined according to the business requirements of calling the service interface;

[0155] callback: The result callback interface, which returns the result of the service call. In JavaScript, it is defined as Callback(state, result), where state represents the state and result represents the result.

[0156] Return value: This is an asynchronous call; the return value indicates that the service call has ended.

[0157] 2. Upload the service code segment to the IPFS network to obtain the microservice CID.

[0158] 3. Based on the service ID to be configured, query the blockchain to determine the service node information for publishing the service.

[0159] 4. Send a microservice configuration request to the service node. The request includes: service ID, dynamic-scope microservice CID, and information such as the underlying network protocol that the microservice needs to register, i.e., the signature and public key of the information.

[0160] 5. Upon receiving a microservice configuration request and verifying the signature, the service node identifies it as a dynamic service access microservice registration request. It then performs a microservice code audit based on the TEE environment. The audit content includes:

[0161] Scan the code to ensure it does not access any local files;

[0162] Scan the code to ensure it does not access any unregistered network protocols;

[0163] Scan the code to ensure it does not access any network addresses (addresses that need to be accessed must be dynamically imported through service configuration information during subsequent operation).

[0164] 6. After the audit is passed, the microservice configuration information is saved locally, and a request is sent to the blockchain to change the service configuration information, registering and binding the microservice CID with the service.

[0165] As a preferred embodiment, the user initiates a service call, requests service access permissions from the publisher, and the publisher configures the service access permissions, including the following steps:

[0166] The user initiates a service access permission request to the publisher, which includes the user's public key.

[0167] When a user calls a service, they need to apply for service access permissions from the publisher. The user obtains the service configuration information published by the publisher, provides their public key to the publisher to apply for service access permissions, and the publisher configures the access permissions and sends a notification to the user that the application has been approved.

[0168] The publisher uses its private key to sign the access permission configuration that contains the user's public key that needs to be configured;

[0169] Query the location information of the service node configuring the service from the blockchain based on the service ID;

[0170] Configure and sign the access permissions and send them to the service node of the configuration service.

[0171] After receiving the information, the service node verifies the signature. If the verification is successful, the service access permission configuration is saved.

[0172] Specifically, when the publisher receives an access permission request from the user containing the user's public key, the publisher signs the access permission configuration parameters by combining them with the publisher's private key. The access permission configuration parameters include: the user's public key to be configured, access permissions (including management, normal calls, number of calls, call frequency in each period, etc.), and the current block height of the blockchain associated with the platform.

[0173] The publisher retrieves the service node location information from the blockchain based on the service ID, generates a service access permission configuration request including access permission settings and a signature, and sends it to the service node. Upon receiving the request, the service node verifies the signature using the publisher's public key. If verification is successful, the service access permission configuration information is saved locally. The publisher then processes the service access permission request, configures the service access permissions, and sends a confirmation message to the user.

[0174] As a preferred embodiment, the user sends a call request to the service node. The service node obtains service configuration information based on the call request and sequentially authenticates and confirms the access type of the call request, including the following steps:

[0175] The user uses their private key to sign the call parameters containing the service ID;

[0176] Send the call parameters, signature, and user's public key to any service node;

[0177] After the service node verifies the signature, it checks whether the current service node has any unexpired service configuration information in its cache.

[0178] If not, the service node queries the blockchain based on the service ID to determine the service node where the service configuration information is located, requests the service configuration information from that service node, and obtains and caches the service configuration information.

[0179] Specifically, after obtaining service access permissions from the publisher, the user selects a pre-built common interface call method from the service platform, such as RESTful, API, or gRPC, as the service call protocol. Calls between different services can use the same interface, only the parameters differ. The user combines and signs the call parameters using their private key. The call parameters include the service ID, service subject, service name, required service call parameters, and block height. The user sends the call parameters, their public key, and the signature to any network-connected service node to initiate the service call. This solution eliminates the need to submit applications to a centralized platform for review, achieving a decentralized approach. Furthermore, it optimizes the user experience, allowing for zero-configuration access without applying for an API Key or registering a dedicated account; instant authorization allows users to directly call services after obtaining permissions; and it reduces usage costs and simplifies the service call process.

[0180] After receiving a service access request from a user, the service node first verifies the signature. If the verification is successful, it first checks whether the service configuration information is cached locally and whether the service configuration information has expired. If the service configuration information is cached and has not expired, the subsequent authentication and access confirmation process is carried out. If the service configuration information is not cached or the service configuration information has expired, the service node where the service configuration information is located is determined by querying the blockchain based on the service ID in the call parameters. The service node is then sent a request to retrieve the service configuration information until it is successfully retrieved, and the information is cached for a period of time.

[0181] After obtaining the service configuration information, the call request is authenticated and the access type is confirmed in sequence. The permission and access confirmation include the identification of dynamic microservices. When dynamic microservices are loaded, the microservices perform permission verification or service calls.

[0182] First, confirm the authentication type, including the following steps:

[0183] The service node detects the service authentication configuration type based on the service configuration information.

[0184] If it is an authentication and billing microservice, obtain the authentication and billing microservice CID from the blockchain, obtain the authentication and billing microservice code block, start the microservice by the service node, pass the service call request parameters to the microservice, and the microservice completes the authentication and billing operation.

[0185] If it is a general configuration, the original authentication configuration will be called to perform the authentication operation.

[0186] The authentication process involves obtaining service access permission configurations from the service node of the configuration service and comparing them with the user's public key to determine whether the user has the necessary service access permissions.

[0187] Specifically, during the user's service invocation process, the service node authenticates and confirms the invocation request. To determine whether the service authentication configuration is an authentication and billing microservice, if the service has a general configuration, the original authentication module is directly called for authentication. If the service is configured with an authentication and billing microservice, the authentication and billing microservice code block is obtained. This process includes:

[0188] The service node determines whether the microservice code block corresponding to the microservice CID is cached locally.

[0189] If not, the microservice code block is pulled from the IPFS network via the IPFS protocol.

[0190] This solution determines whether a service node has cached microservice code blocks locally. It applies to retrieving the authentication and accounting microservice code blocks during authentication type confirmation and the dynamic service access microservice code blocks during access type confirmation. If the microservice code blocks are cached locally, the microservice is started directly based on the code blocks. If the microservice code blocks are not cached locally, the microservice code blocks are retrieved from the IPFS network via the IPFS protocol based on the microservice CID, ensuring that the retrieved code blocks are trustless.

[0191] After obtaining the microservice code block, the service node invokes the microservice runtime environment, starts the microservice, and passes the service call request parameters to the microservice. The microservice then completes the authentication and accounting operations. The authentication process involves the current service node obtaining the service access permission configuration from the service node configuring the service, obtaining the user's public key, and comparing the public key provided by the user initiating the service call with the public key obtained from the service node configuring the service. If a matching public key exists, authentication succeeds, and subsequent operations proceed. If no matching public key exists, authentication fails, an error is returned, and the service call process ends.

[0192] After successful authentication, the access type confirmation process is performed, including the following steps:

[0193] The service node detects the service access type based on the service configuration information.

[0194] If it is a dynamic service accessing a microservice, obtain the CID of the dynamic service accessing the microservice from the blockchain, obtain the code block of the dynamic service accessing the microservice, start the microservice by the service node, pass the call parameters of the service call request and the backend access configuration information into the microservice, perform protocol conversion and call the service;

[0195] If it is pre-configured, the pre-configured module is invoked to call the service;

[0196] The service node will then send the call results back to the user.

[0197] Specifically, after authentication, the service node confirms the access request. To determine if the service access type is dynamic service access to a microservice, if it's pre-configured, the pre-configured module is directly selected for service invocation, and the service invocation result is returned to the user. If it's dynamic service access to a microservice, the service node obtains the dynamic service access microservice code block, starts the microservice, and registers the corresponding protocol's underlying network proxy (registered by the service node program at runtime, including TCP, HTTP, WebSocket, gRPC, etc.) according to the microservice configuration, providing external network access capabilities for the microservice. The service invocation request parameters and backend access configuration information are passed to the microservice, and feedback is awaited. The microservice performs protocol conversion and accesses the backend service through the network proxy. The microservice returns the service invocation result to the service node, and the service node returns the service invocation result to the user.

[0198] This invention enables decentralized and dependency-free intelligent services, achieving trustless and dependency-free service publishing and use. It allows specialized services that do not support general protocols to provide services to the outside world through microservice functions, enabling anyone to publish and use various general or specialized services without limitations.

[0199] This invention removes entry barriers for service publishing, allowing anyone to directly publish services; it utilizes a decentralized user and authentication system to build an access authentication system for published services; it leverages dynamic microservice capabilities to enable the rapid publication and external provision of dedicated services based on private protocols, and service publishers can independently define the authentication and billing logic of services according to their characteristics; it ensures the security and reliability of the dynamic microservices loaded during service publication; and it allows any user with decentralized access to directly access services after authorization.

[0200] The specific embodiments described herein are merely illustrative of the spirit of the invention. Those skilled in the art to which this invention pertains may make various modifications or additions to the described specific embodiments or use similar methods to substitute them, without departing from the spirit of the invention or exceeding the scope defined by the appended claims.

Claims

1. A method for implementing a trustless and dependency-less intelligent service, characterized in that, The method comprises the following steps: The publisher verifies the signature and publishes and registers the service on the service node, and the service loads a dynamic microservice; The user initiates a service call and applies for service access permission from the publisher, and the publisher configures the service access permission; comprising: The publisher uses the publisher's private key to sign the access permission configuration containing the user's public key; According to the service ID, the service node location information of the configured service is queried from the blockchain; The access permission configuration is signed and sent to the service node; After receiving the information, the service node verifies the signature, and if the verification is passed, the service access permission configuration is saved; The user sends a call application to the service node, and the service node obtains the service configuration information according to the call application, and authenticates and confirms the access type of the call application in turn; including identifying the dynamic microservice, and when the dynamic microservice is loaded, the microservice performs permission verification or service call; If it is an authentication billing microservice / dynamic service access microservice, the authentication billing / dynamic service access microservice CID is obtained from the blockchain, the corresponding code block is obtained, the microservice is started by the service node, the service call request call parameter / service call request call parameter and the backend access configuration are transmitted into the microservice, and the authentication billing operation is completed / protocol conversion is performed and the service is called; The service node feeds back the service call result to the user.

2. The method of claim 1, wherein, The publisher verifies the signature and publishes and registers the service on the service node, and the service loads a dynamic microservice; The publisher sets the service configuration information, signs the service configuration information and the block height using the publisher's private key; The publisher sends the service configuration information, block height, publisher public key and signature data to any service node that has entered the network; After the service node verifies the signature, the service configuration information is saved and a service ID is generated; The service node registers the published service on the blockchain, and the publisher publishes the service.

3. The trustless and dependency-free intelligent service implementation method according to claim 2, characterized in that: The user initiates a service access permission application including a user public key to the publisher.

4. The method of claim 1, wherein, The service node obtains the service configuration information according to the call application, specifically comprising: The user uses the user's private key to sign the call parameter containing the service ID; The call parameter, signature and user public key are sent to any service node; After the service node verifies the signature, it is determined whether the current service node has buffered expired service configuration information, If not, the service node queries the blockchain according to the service ID to determine the service node where the service configuration information is located, requests the service configuration information from the service node, and obtains and caches the service configuration information.

5. The trustless and dependency-free intelligent service implementation method according to claim 4, characterized in that: The microservice includes an authentication billing microservice and a dynamic service access microservice; The authentication type confirmation includes identifying the authentication billing microservice, and the access type confirmation includes identifying the dynamic service access service.

6. The trustless and dependency-free intelligent service implementation method according to claim 5, characterized in that: The service node detects the service authentication configuration type according to the service configuration information, If it is an authentication and charging microservice, the authentication and charging microservice CID is obtained from the blockchain, the authentication and charging microservice code block is obtained, the microservice is started by the service node, the service calling request calling parameter is transmitted into the microservice, and the authentication and charging operation is completed by the microservice; If it is a general configuration, the original authentication configuration is called to perform an authentication operation; The authentication operation is to obtain service access permission configuration from the service node of the configuration service, and to determine whether the service access permission is obtained according to the user public key comparison.

7. The trustless and dependency-free intelligent service implementation method according to claim 5, characterized in that: The service node detects the service access type according to the service configuration information, If it is a dynamic service access microservice, the dynamic service access microservice CID is obtained from the blockchain, the dynamic service access microservice code block is obtained, the microservice is started by the service node, the service calling request calling parameter and the backend access configuration information are transmitted into the microservice, the protocol is converted, and the service is called; If it is a pre-configuration, the pre-configuration module is called to call the service; The service node feeds back the calling result to the user side.

8. The method of claim 6 or 7, wherein, The microservice code block obtaining process comprises: The service node determines whether the microservice code block corresponding to the microservice CID is in the local buffer, If not, the microservice code block is pulled from the ipfs network through the ipfs protocol.

9. The method of claim 1-7, wherein, The service loads the dynamic microservice, specifically comprising: The publisher writes a service code segment, uploads the service code segment to the ipfs network, and obtains a microservice CID; According to the service ID to be configured, the service node information of the publishing service is determined by querying the blockchain; The microservice configuration request is sent to the service node, the service node verifies the signature, audits the microservice code, saves the microservice configuration information after the audit is passed, requests the blockchain to change the service configuration information, and binds the microservice CID with the service.

Images