Multi-agent collaborative MCP registration, authorization and execution method based on block chain

Abstract

The invention provides a multi-agent collaborative MCP registration, authorization and execution method based on a block chain, and relates to the technical field of artificial intelligence, the method comprises three parties of an MCP provider, an LLM provider and a terminal user, and MCP registration, joint authorization and trusted execution are realized through an intelligent contract. Comprising the steps of registering MCP metadata uplink, applying for authorization for a user-LLM combination, initiating double-signature calling by the LLM, verifying a contract and triggering execution, and returning a result and updating a state by Oracle. According to the method, decentralization, multi-agent collaboration, verifiability of MCP calling full links and accurate definition of rights and responsibilities are realized, fine-grained authority control and automatic expense settlement are supported, compliance supervision requirements of GDPR, HIPAA and the like are met, bottom support is provided for large-scale and secure calling of external services by a large model, and multi-scene application of SaaS, API markets and the like is adapted.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a blockchain-based method for multi-entity collaborative MCP registration, authorization, and execution. Background Technology

[0002] Currently, extending the capabilities of Large Language Models (LLMs) by calling external tools has become the mainstream paradigm. To this end, the community proposed the Model Context Protocol (MCP), aiming to standardize the interaction interface between LLMs and external services (such as databases, APIs, simulators, and computing engines). Typical implementations include LangChain's ToolRegistry, OpenAI's FunctionCalling, and the open-source MCPServer. However, the current architecture typically integrates MCP-related authentication and other functions within the large model LLM provider platform through configuration. Users then call the model from the large model LLM provider platform, accessing different MCP services; all logging, billing, and access control are handled by the centralized large model LLM.

[0003] If the current architecture is to achieve a more generalized, multi-organizational, and trustworthy interaction method, the current architecture has the following problems: 1) Ambiguous responsibility: It is impossible to distinguish whether the sensitive call was triggered by a user command or by the model's own behavior; 2) Generalized permissions: When the same user uses different LLMs, the permission policies cannot be differentiated; 3) Billing misalignment: The cost may be borne by the LLM provider (such as in a SaaS model), but the system cannot recognize it; 4) Compliance risk: Regulatory agencies cannot trace "which model called which external service at which time". Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a decentralized, multi-entity collaborative, and fully lifecycle verifiable blockchain-based method for multi-entity collaborative MCP registration, authorization, and execution.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: A blockchain-based multi-party collaborative MCP registration, authorization, and execution method includes an MCP provider, an LLM provider, and an end-user. Coordination is achieved through blockchain smart contracts, with an oracle acting as a trusted off-chain agent to facilitate interaction among the three parties. The MCP provider has a blockchain address on the blockchain. The LLM provider owns a blockchain address on the blockchain. End users own blockchain addresses on the blockchain. ; Includes the following steps: S1: Register MCP metadata and upload it to the blockchain; Register the on-chain identity and service information of LLM and MCP providers, and generate registration records; S2: Request authorization for the user-LLM combination; The LLM provider receives end-user requests, submits application parameters to the smart contract, verifies on-chain rules, and approves authorization through front-end or off-chain review. Once approved, it generates an authorization certificate. S3: LLM initiates a double-signature call; The LLM inference engine generates an MCP call request, and based on the authorization credentials, generates an MCP call package containing dual identity signatures to initiate an on-chain call request to the blockchain smart contract. S4: Contract verification and execution triggered; The MCP call package verifies identity and permissions. If the verification is successful, the fee is calculated, the token is locked, and the oracle is triggered to execute the off-chain MCP service call. If the verification fails, the call is terminated directly and an exception is thrown. S5: The oracle returns the result and updates the state; After the oracle completes the off-chain MCP service, it will upload the execution result back to the blockchain, update the on-chain state, settle fees, and generate audit logs.

[0006] Furthermore, step S1 includes: S11: LLM provider registers to generate on-chain state; LLM provides the LLM Registry smart contract to submit LLM registration parameters, generate the decentralized unique identity identifier llm_did of the LLM provider, and generate on-chain state; S12: MCP providers register and obtain registration records; MCP provides the MCPRegistry smart contract on the blockchain to submit MCP registration parameters; it calls the MCPRegistry smart contract to generate a globally unique identifier mcp_id for the MCP service, performs on-chain verification, and finally solidifies the MCP registration parameters and the globally unique identifier mcp_id into an on-chain registration record. .

[0007] Furthermore, specifically including: S111: The LLM provider submits the LLM registration parameters; In response to the registration operation, the LLM provider actively submits the LLM registration parameters to the blockchain LLMRegistry smart contract; S112: On-chain processing generates a decentralized unique identifier llm_id; The LLMRegistry smart contract calls the LLMRegistry.registerLLM() method to obtain the blockchain timestamp at the time of the LLMRegistry smart contract execution, and then compares the blockchain timestamp with the blockchain address. A centralized, unique identifier llm_id with a fixed-length hash value is generated using a hash algorithm; S113: Generate on-chain state ; Obtain the LLM registration parameters and the decentralized unique identifier llm_id, and output them in a fixed format to solidify them into an on-chain state. ; On-chain state This includes the LLM identifier llm_id and the blockchain address of the LLM provider. Model name (model_name), IPFS hash (capability_hash) describing model capabilities, compliance certificate hash (compliance_cert), and billing mode (billing_mode); S121: The MCP provider submits the MCP registration parameters; The MCP provider actively submits the MCP registration parameters to the MCPRegistry smart contract; Registration parameters include: IPFS hash spec_hash from the MCP specification file, authorization mode auth_mode, LLM compliance attribute requirements required_compliance, pricing strategy, resource billing parameters cost_model_params, and charging scheme λ; S122: On-chain verification processing; 1) Generate a globally unique identifier for the MCP, mcp_id; The MCPRegistry smart contract uses the blockchain address of the MCP provider. The blockchain timestamp at the time of execution of the MCPRegistry smart contract is used to generate a fixed-length hash value for the globally unique MCP identifier mcp_id through a hash algorithm; 2) Verify the whitelist; Calling the on-chain state in the LLMRegistry smart contract To obtain the llm_id, the MCPRegistry smart contract, during registration, iterates through all llm_ids in allowed_llm_ids and verifies whether each llm_id in allowed_llm_ids is in the LLMRegistry smart contract; if yes, proceed to the next step; otherwise, filter the llm_id. 3) Filter compliance attributes; If the MCP provider specifies required_compliance, then the LLM provider llm_id that meets the compliance attributes is selected from the LLMRegistry smart contract and updated to the whitelist; 4) Store metadata; The MCPRegistry smart contract stores the verified and compliant MCP registration parameters and the generated mcp_id on the blockchain, and broadcasts MCPRegistered(mcp_id, ...) to the entire blockchain network. )event; S123: Generate registration records on the blockchain; The registration parameters of the metadata and the generated mcp_id are solidified into an on-chain registration record. .

[0008] Furthermore, step S2 includes: S21: Trigger authorization request; The LLM provider receives inference requests from end users, analyzes them to obtain the MCP service to be invoked, obtains the mcp_id, and reads the corresponding registration record from the MCPRegistry smart contract. Obtain the authorization mode auth_mode; S22: Submit an authorization request; The LLM provider, on behalf of itself and the end user, submits application parameters to the MCPAccessControl smart contract; S23: Verify on-chain rules; According to registration records Verify the integrity of the identity and the whitelist separately; S24: Conduct front-end or off-chain audits; If the MCP provider reviews the application, it will return an authorization failure message if the review is rejected, and proceed to the next step if the review is approved. S25: Generate authorization certificate; The MCP provider calls the MCPAccessControl smart contract to generate a unique on-chain authorization certificate. And store.

[0009] Furthermore, S231: Verify the integrity of the identity; According to registration records The authorization mode auth_mode in the system is verified; S232: Verify the whitelist; Registration records If allowed_llm_ids is not empty, then check if the current llm_id is in the whitelist; if not, the application will be rejected directly.

[0010] Furthermore, the application parameters include: mcp_id, llm_id, and the end-user blockchain address. LLM provider blockchain address Maximum number of calls Expiration time Scope of permissions ; Authorization Certificate : ; ;in, This represents the number of times the function has been called; the initial value is 0. This is the authorization effective time, which is the execution start time. The default value is the current timestamp when the authorization certificate was generated. Maximum number of calls; Expiration date; This refers to the scope of permissions.

[0011] Furthermore, step 3 includes: S31: Generate a call request; The LLM inference engine, based on the end user's original request and the scope of permissions granted by authorization credential A, Generate the specific call parameters params for the MCP service, and generate the call package for the MCP service call request; the call package includes the specific call parameters params, the mcp_id of the MCP service to be called, and the LLM identifier llm_id; S32: Perform dual signature; End users use their own private key (SKU) to sign the call packet, generating a user signature. The LLM provider uses its own private key skl to sign the call packet, generating an LLM signature. ; S33: Initiate an on-chain call; The LLM inference engine encapsulates the call parameters and double signatures into a complete call package. Submit a call package to the MCPExecutor smart contract Initiate an MCP service call request.

[0012] Furthermore, step S4 includes: S41: Verify the identity and permissions of the calling package; Verify the identity of the calling package: Invoke the blockchain signature verification algorithm to verify the user's signature. and LLM signature The effectiveness; Verify the authorization credentials: Read the authorization credentials corresponding to the call package Q from the MCPAccessControl smart contract. Verify the authorization credentials respectively If the number of calls is less than the maximum number of calls, the blockchain timestamp during verification is less than the authorization expiration time, and the specific call parameters of the MCP service are within the permission range, then the authorization is deemed valid; otherwise, the authorization is deemed invalid. If the authorization is invalid, the process is terminated and an exception is thrown. S42: Calculate fees and lock tokens; According to the calling package Q Read the corresponding registration record from the MCPRegistry smart contract To obtain the base price for pricing cost_model_params: Resource billing parameters α and β, according to the formula Calculate the total cost of a single call ;in, It counts the number of tokens for the specific call parameters (params). Estimated execution time for MCP services, based on MCP provider statements or historical execution averages on the blockchain; S422: Locked tokens; Obtain the charging scheme λ, and according to the charging scheme λ, deduct funds from the end user's blockchain address. and the blockchain address provided by LLM Locked tokens; The locked amounts are as follows: End user λ· LLM provider (1-λ) ; S43: Trigger an off-chain oracle call to MCP; The oracle monitors the execution of the MCPExecutor smart contract in real time, reads on-chain call requests, and retrieves information from the registration records. The URL of the off-chain call endpoint for the MCP service is parsed out, and the specific call parameters (params) of the call packet Q are used as input parameters to initiate an off-chain MCP service call. The start time of the MCP service execution is recorded. After the off-chain MCP service is completed, the execution result is obtained; The execution results include the execution results of the MCP service. and actual time spent .

[0013] Furthermore, step S5 includes: S51: Execution result is uploaded and sent back to the blockchain; The oracle will execute the results of the MCP service. Generate hash value Write it back to the chain; S52: Update authorization status; The number of times it has been invoked in authorization credential A Atom increments are performed, increasing the value by 1; S53: Settlement Fees: Unlock locked tokens, release tokens, and return the tokens held by the user. Tokens provided by LLM providers From the blockchain address of the end user respectively And LLM provider blockchain address The amount deducted from the blockchain address transferred to the MCP provider is [not specified]. ; S54: Generate audit logs; Generate an on-chain audit log L and store it on the blockchain.

[0014] Furthermore, the on-chain audit log L includes the blockchain address of the end user, the blockchain address of the MCP provider, and the blockchain address of the LLM provider. , The start time, end time, and result of the MCP service execution. The hash value.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) The present invention constructs a decentralized architecture through blockchain, allowing the LLM provider, MCP provider, and end user to complete identity registration on the chain and have a unique blockchain address. Moreover, the MCP call process adopts a dual-signature mechanism between the end user and the LLM provider to initiate the call request, and the signature subject and the call initiator can be clearly traced on the chain. At the same time, the complete link information of all call operations is recorded in the immutable blockchain audit log, clearly distinguishing between MCP calls triggered by user instructions and those triggered by the model's own behavior, realizing the accurate definition of the responsible subject of the call behavior, and avoiding ambiguity of responsibility.

[0016] (2) In this invention, when the MCP provider registers on the chain, it can customize the authorization mode (user-only authorization, LLM provider-only authorization, and joint authorization by both parties), the whitelist of LLMs allowed to be called, and the compliance attribute requirements. In the authorization process, it can customize personalized strategies such as the maximum number of calls, authorization validity period, and specific permission scope for user-LLM combinations. At the same time, different LLM providers have independent trusted llm_id and service capability registration information on the chain. When the same user connects to different LLMs, the permission strategy can be configured and verified differently based on the on-chain smart contract, which completely solves the problem of permission generalization, achieves precise permission control, and realizes fine-grained and customizable MCP access control.

[0017] (3) In the MCP call execution phase of this invention, the blockchain smart contract automatically calculates the total cost of a single call according to the preset billing rules and sharing ratio, and locks tokens proportionally from the blockchain addresses of the user and the LLM provider. After execution, the tokens are automatically transferred to the MCP provider. If the execution fails, the tokens are unlocked and returned. The entire billing process is automatically completed by the on-chain smart contract, which can accurately identify the cost-bearing entity and the sharing ratio, completely solve the billing misalignment problem, realize automated and accurate settlement of fees, and avoid billing misalignment.

[0018] (4) This invention writes all data from the entire process of registration, authorization, invocation, settlement, and execution into the blockchain, generating an immutable on-chain audit log containing the identities of the three parties, time, and results. Regulators can trace the complete MCP call chain on the blockchain using identifiers such as mcp_id and llm_id, clearly querying full information such as "who used which model, when which MCP service was called, and what the call result was," thus meeting the audit and regulatory requirements of GDPR, HIPAA, and other regulations for external calls to automated decision-making, completely resolving the technical risks of compliance traceability, and achieving full-chain regulatory and traceability. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the steps of a blockchain-based multi-entity collaborative MCP registration, authorization, and execution method according to the present invention. Figure 2 This is a flowchart of step S2 of a blockchain-based multi-entity collaborative MCP registration, authorization, and execution method according to the present invention; Figure 3 This is a flowchart of the MCP execution method of a blockchain-based multi-entity collaborative MCP registration, authorization and execution method according to the present invention. Detailed Implementation

[0020] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0021] Example 1

[0022] like Figure 1 , Figure 2 and Figure 3 A blockchain-based multi-entity collaborative MCP registration, authorization, and execution method, including an MCP provider ( ), LLM provider ( ), end users ( Through blockchain smart contracts, the oracle acts as a trusted off-chain agent, enabling collaborative interaction among LLM providers, MCP providers, and end users.

[0023] An MCP provider is a service provider that offers specific functions or data interfaces, encapsulated as a callable tool / resource according to the MCP standard. It is used to define and register MCP services. An MCP provider has a unique identifier on the blockchain as its blockchain address. .

[0024] LLM providers are service providers that offer large language model inference capabilities. They are responsible for invoking appropriate MCP tools based on user intent to deploy large models and generate and initiate MCP calls. LLM providers have an identity identifier on the blockchain, represented by a blockchain address. .

[0025] End users are natural persons or entities that use LLM services to complete specific tasks, inputting instructions into the LLM to trigger MCP calls; end users have an identity identifier on the blockchain as a blockchain address. .

[0026] Blockchain smart contracts serve as coordination and trust anchors for multi-party collaboration, used for storing state, verifying permissions, triggering execution, and recording logs. Blockchain smart contracts include: MCPExecutor smart contracts, LLMRegistry smart contracts, MCPRegistry smart contracts, and MCPAccessControl smart contracts, etc. The MCPExecutor smart contract is the unified entry point and execution gateway for MCP service calls. It is responsible for receiving MCP call requests initiated by LLM providers or oracles, verifying call permissions, triggering MCP service execution, and recording call results for subsequent settlement and auditing.

[0027] The LLMRegistry smart contract (Large Model Service Registry smart contract) is a registration and management center for LLM providers and their service capabilities.

[0028] The MCPRegistry smart contract (MCP Service Registry smart contract) serves as the registration and management center for MCP providers.

[0029] The MCPAccessControl smart contract is a central authority responsible for maintaining the authorization, revocation, and verification of the call relationship between end users and LLM providers and MCP services.

[0030] Oracles are trusted off-chain agents responsible for connecting on-chain smart contracts with the actual off-chain service execution.

[0031] Includes the following steps: S1: Register MCP metadata and upload it to the blockchain; Register the on-chain identity and service information of LLM and MCP providers, generate registration records, and store all registration information on the chain in an immutable manner.

[0032] S11: LLM provider registers to generate on-chain state; The LLM provider submits LLM registration parameters to the LLMRegistry smart contract on the blockchain. The LLMRegistry smart contract calls the LLMRegistry.registerLLM(...) method to generate a decentralized unique identifier, llm_did, for the LLM provider. The LLM registration parameters are then solidified into the on-chain state. .

[0033] S111: The LLM provider submits the LLM registration parameters; In response to the registration operation, the LLM provider actively submits the LLM registration parameters to the blockchain LLMRegistry smart contract.

[0034] LLM registration parameters include: The model name, model_name, includes "MediLLM-v2" and other similar names; it is used to identify a specific large language model.

[0035] The IPFS hash capability_hash describing the model's capabilities: The IPFS storage content is the model's capability description, which includes supported MCP types, input length, security sandbox proof, etc. The hash value is used for fast on-chain verification to ensure that the content cannot be tampered with. Compliance certificate hash compliance_cert: IPFS stores compliance certification files (including GDPR, HIPAA certification, etc.) for the model. Billing mode: includes user-pay, LLM provider-pay, hybrid, etc.; used to declare the basic billing rules of the model.

[0036] Public key public_key: The public key used to verify the signature of the call (if it is not a direct signature using a wallet address).

[0037] Furthermore, it also includes the LLM identifier llm_id, which is customized by the LLM provider or generated by a smart contract.

[0038] S112: On-chain processing generates a decentralized unique identifier llm_id; The LLMRegistry smart contract calls the LLMRegistry.registerLLM(...) method to obtain the blockchain timestamp (timestamp1) at the time of the LLMRegistry smart contract execution, and then compares the blockchain timestamp (timestamp1) with the blockchain address. A centralized, unique identifier llm_id with a fixed-length hash value is generated using a hash algorithm; The generation formula is: llm_did = Hash( ||timestamp), where: This is the blockchain address of the LLM provider, and timestamp1 is the blockchain timestamp when the smart contract call was executed. Hash() is a general blockchain hash algorithm used to generate a fixed-length unique identifier.

[0039] S113: Generate on-chain state ; Obtain the LLM registration parameters and the decentralized unique identifier llm_id, and output them in a fixed format to solidify them into an on-chain state. And store it in the LLMRegistry smart contract. On-chain state This includes the LLM identifier llm_id and the blockchain address of the LLM provider. Model name (model_name), IPFS hash (capability_hash) describing model capabilities, compliance certificate hash (compliance_cert), and billing mode (billing_mode).

[0040] The fixed format is: .

[0041] S12: MCP providers register and obtain registration records; MCP provides the MCPRegistry smart contract on the blockchain to submit MCP registration parameters; it calls the MCPRegistry smart contract to generate a globally unique identifier mcp_id for the MCP service, performs on-chain verification, and finally solidifies the MCP registration parameters and the globally unique identifier mcp_id into an on-chain registration record. .

[0042] S121: The MCP provider submits the MCP registration parameters; The MCP provider actively submits the MCP registration parameters to the MCPRegistry smart contract; MCP registration parameters include: spec_hash: The IPFS hash of the MCP specification file (including input / output schema, calling endpoint URL, and security requirements); Authorization mode auth_mode: The value of auth_mode includes user, llm, joint, etc.; where user is user-only authorization; llm is LLM provider-only authorization; and joint is joint authorization for both user and LLM provider.

[0043] allowed_llm_ids: A whitelist of allowed LLM provider llm_ids for invocation; The required_compliance attribute for LLMs is defined by the MCP provider, including the definition of "only HIPAA-certified LLMs are allowed"; it can be automatically filtered based on the LLM's compliance attribute. Pricing: Pricing strategy, sets the base price for a single call to the MCP service. Basic pricing This refers to the billing base for a single request, which can be a token or something else; cost_model_params: Resource billing parameters (α, β), defined by the MCP provider; λ: Charging scheme (λ∈(0,1), representing the user charging ratio. The higher λ is, the more the user pays and the less the LLM pays).

[0044] S122: On-chain verification processing; 1) Generate a globally unique identifier for the MCP, mcp_id; The MCPRegistry smart contract uses the blockchain address of the MCP provider. The blockchain timestamp timestamp2 used during the execution of the MCPRegistry smart contract generates a fixed-length hash value for the globally unique MCP identifier mcp_id using a hash algorithm. The generation formula is: mcp_id = Hash( ||timestamp2); where, The blockchain address of the MCP provider; timestamp2 is the blockchain timestamp when the MCPRegistry smart contract is executed; Hash() is a common hash algorithm used in blockchain to generate fixed-length unique identifiers. 2) Verify the whitelist; Calling the on-chain state in the LLMRegistry smart contract Upon obtaining the llm_id, the MCPRegistry smart contract, during registration, iterates through all llm_ids in allowed_llm_ids, verifying whether each llm_id in allowed_llm_ids is in the LLMRegistry smart contract. If yes, proceed to the next step; otherwise, filter the llm_id.

[0045] 3) Filter compliance attributes; If the MCP provider specifies required_compliance, then the LLM provider llm_id that meets the compliance attributes is selected from the LLMRegistry smart contract and updated to the whitelist. This ensures that the MCP provider can dynamically set the whitelist based on the LLM's compliance attributes (such as HIPAA certification) to achieve precise access control.

[0046] 4) Store metadata; The MCPRegistry smart contract stores the verified and compliant MCP registration parameters and the generated mcp_id on the blockchain (or hashes off-chain data and uploads it to the blockchain). It then broadcasts `MCPRegistered(mcp_id, ...` to the entire blockchain network. The event announced that the MCP service registration was complete.

[0047] S123: Generate registration records on the blockchain; The registration parameters of the metadata and the generated mcp_id are solidified into an on-chain registration record. ; .

[0048] Output As the strategic basis for the next step (authorization), no information is lost.

[0049] Through two-way identity registration: MCP providers register service metadata (including specifications, pricing, security policies, etc.) on the chain and obtain a globally unique mcp_id, while LLM providers simultaneously register their model identity (including capability declarations, compliance certificates, billing models, etc.) and obtain a trusted llm_id; both are publicly verifiable on the chain in an immutable manner, providing a trusted foundation for subsequent authorization.

[0050] S2: Request authorization for the user-LLM combination; The LLM provider receives requests from end users, submits application parameters to the smart contract, verifies on-chain rules, and approves authorization through front-end or off-chain review. Once approved, it generates an authorization certificate.

[0051] S21: Trigger authorization request; The LLM provider receives inference requests from end users, analyzes them to obtain the MCP service to be invoked, and obtains the mcp_id. Based on the mcp_id, it reads the corresponding registration record from the MCPRegistry smart contract. Obtain the authorization mode auth_mode.

[0052] S22: Submit an authorization request; The LLM provider, on behalf of itself and the end user, submits application parameters to the MCPAccessControl smart contract; Application parameters include: mcp_id (MCP ID): A globally unique identifier for the MCP service.

[0053] llm_id (ID of the large model): LLM identifier.

[0054] : End-user blockchain address; : LLM provider's blockchain address; The maximum number of calls is determined by the LLM provider based on user needs and is applied for from the MCP provider. It represents the maximum number of times the MCP service can be called within the authorized period. The expiration time is the time when the authorization certificate expires, determined by the LLM provider based on user needs. The format is a blockchain timestamp. The scope of permissions is the boundary of calling permissions for MCP services (including the service interfaces that can be called and the range of data that can be accessed) requested by the LLM provider in conjunction with user needs.

[0055] Ensure that the authorization credentials are issued by the end-user address ( ) and LLM providers ( Common index; allows for customization of call count, validity period, data range, and more custom strategies to ensure fine-grained strategy.

[0056] S23: Verify on-chain rules; According to registration records Verify the integrity of the identity and the whitelist separately.

[0057] S231: Verify the integrity of the identity; According to registration records In the authorization mode (auth_mode) verification, if it is joint authorization, then the following must also be provided: and If it is a user or LLM, then provide the corresponding service separately. and .

[0058] S232: Verify the whitelist; Registration records If allowed_llm_ids is not empty, then check if the current llm_id is in the whitelist; if not, the application will be rejected directly.

[0059] S24: Conduct front-end or off-chain audits; MCP provider for the application , as well as The system will review the application. If the review is rejected, an authorization failure message will be returned. If the review is approved, proceed to the next step.

[0060] S25: Generate authorization certificate.

[0061] The MCP provider calls the MCPAccessControl smart contract. Method to generate a unique on-chain authorization credential. : and store; where .in, This represents the number of times the function has been called; the initial value is 0. This is the authorization effective time, which is the execution start time. The default value is the current timestamp when the authorization certificate was generated. Maximum number of calls; Expiration date; This refers to the scope of permissions.

[0062] S3: LLM initiates a double-signature call; The LLM inference engine generates an MCP call request, and based on the authorization credentials, generates an MCP call package containing dual identity signatures, and initiates an on-chain call request to the blockchain MCPExecutor smart contract.

[0063] S31: Generate a call request; The LLM inference engine, based on the end user's original request and the scope of permissions granted by authorization credential A, This process generates the specific call parameters `params` for the MCP service and a call package for the MCP service call request. The call package includes the specific call parameters `params`, the `mcp_id` of the MCP service to be called, and the LLM identifier `llm_id`.

[0064] The specific call parameter params is the input parameter of MCP, which is defined by the business logic and passed in by the caller according to the protocol.

[0065] S32: Perform dual signature; End users use their own private key (SKU) to sign the call packet, generating a user signature. The LLM provider uses its own private key skl to sign the call packet, generating an LLM signature. ; S33: Initiate an on-chain call; The LLM inference engine encapsulates the call parameters and double signatures into a complete call package. Submit a call package to the MCPExecutor smart contract Initiate an MCP service call request.

[0066] .

[0067] in, A signature algorithm for end users, used to verify the user's genuine participation; A signature algorithm for LLM providers, used to verify the genuine participation of LLM providers.

[0068] S4: Contract verification and execution triggered; The MCP call package verifies identity and permissions. If the verification is successful, the fee is calculated, the token is locked, and the oracle is triggered to execute the off-chain MCP service call. If the verification fails, the call is terminated directly and an exception is thrown.

[0069] S41: Verify the identity and permissions of the calling package; Verify the identity of the calling package: Invoke the blockchain signature verification algorithm to verify the user's signature. and Validity of LLM signatures.

[0070] Verify the authorization credential's permissions: Read the authorization credential A corresponding to the call package Q from the MCPAccessControl smart contract, and verify the validity of the authorization using the built-in verification formula. The verification formula is:

[0071] in, It is the number of times it has been invoked in authorization credential A; Maximum number of calls; This refers to the expiration time of the authorization. This refers to the scope of permissions; all of the above parameters can be obtained from authorization credential A.

[0072] The current blockchain timestamp captured during verification; Specific parameters for calling the MCP service.

[0073] By verifying whether the number of calls in authorization credential A is less than the maximum number of calls, whether the blockchain timestamp at the time of verification is less than the authorization expiration time, and whether the specific call parameters of the MCP service are within the permission range, if all of these are less than and within the permission range, the authorization is deemed valid; otherwise, the authorization is deemed invalid. If the authorization is invalid, the process is terminated and an exception is thrown. S42: Calculate fees and lock tokens; S421: Calculate the cost; According to the calling package Q Read the corresponding registration record from the MCPRegistry smart contract To obtain the base price for pricing `cost_model_params`: Resource billing parameters α and β. Calculate the total cost of a single call. The calculation formula is: ;in, This refers to the number of tokens associated with specific call parameters (params), representing the resource consumption of those parameters. A token is the basic unit of counting when a model processes text, used to quantify the amount of text input and output to the model, and is the fundamental unit of measurement for billing, rate limiting, and resource management.

[0074] The estimated execution time for the MCP service is derived from the MCP provider's statement or the historical execution average on the blockchain.

[0075] S422: Locked tokens; Obtain the charging scheme λ, and according to the charging scheme λ, deduct funds from the end user's blockchain address. and the blockchain address provided by LLM Locked tokens, with locked amounts as follows: End user λ· LLM provider (1-λ) The locked tokens will be transferred to the MCP provider upon successful execution; otherwise, they will be unlocked and returned.

[0076] S43: Trigger an off-chain oracle call to MCP.

[0077] The oracle monitors the execution of the MCPExecutor smart contract in real time and reads on-chain call requests. It also checks the registration records. The off-chain call endpoint URL of the MCP service is parsed from the spec_hash in the file. The call parameters params of the call packet Q are used as input parameters to initiate an off-chain MCP service call, and the start time of the MCP service execution is recorded. (Blockchain timestamp at the start of execution) After the off-chain MCP service is completed, the execution result is obtained; The execution results include the execution results of the MCP service. and actual time spent .

[0078] When calling MCP through LLM, dual identity signatures are required; after the smart contract verifies the permissions, the off-chain service is triggered through an oracle (such as an Oracle); the execution result hash and log are uploaded to the chain to form immutable evidence and achieve trusted execution.

[0079] S5: The oracle returns the result and updates the state; After the oracle completes the off-chain MCP service, it sends the execution result back to the blockchain. The MCPExecutor smart contract then updates the on-chain state, settles the fees, and generates audit logs.

[0080] S51: Execution result is uploaded and sent back to the blockchain; The oracle will execute the results of the MCP service. Generate hash value The result is written back to the chain to ensure the verifiability and immutability of the execution result. If the MCP service execution result... For non-sensitive data, the complete results can be directly uploaded to the blockchain.

[0081] S52: Update authorization status; The number of times it has been invoked in authorization credential A Atom increments are performed, increasing the value by 1. The update formula is: Atomic operations guarantee that there will be no duplicate counts or over-calls.

[0082] S53: Settlement Fees: Unlock locked tokens, release tokens, and return the tokens held by the user. Tokens provided by LLM providers From the blockchain address of the end user respectively And LLM provider blockchain address The amount deducted from the blockchain address transferred to the MCP provider is [not specified]. The cost model is consistent with the registration phase, ensuring no parameter breaks. Costs are calculated according to a preset percentage (…). Automatic settlement of fees is achieved between the user and the LLM provider and the MCP provider (the fee between the user and the LLM is not limited at present), ensuring automatic settlement of fees.

[0083] S54: Generate audit logs; Generate an on-chain audit log L and store it on the blockchain. in, , and These are the blockchain addresses of the executing end user, the MCP provider, and the LLM provider, respectively. , The identifier ID for both the MCP provider and the LLM provider; The start time for the MCP service execution. The execution end time, based on the actual time consumed. The result is obtained by summing the execution start time with the time calculated. For service execution results The generated hash value.

[0084] Audit log L includes the identities of the three parties, the time, and the result. This ensures a complete audit chain and facilitates traceability.

[0085] All registration, authorization, invocation, and settlement records for this application are written to the blockchain; regulators can trace the complete invocation chain using mcp_id: who ( Which model to use? What service was called? The audit criteria for external calls to automated decision-making, including when and how they are invoked and the results, must be met to comply with GDPR, HIPAA, and other regulations regarding auditing requirements.

[0086] This invention is the first to incorporate LLM providers into the MCP (Multi-Channel Platform) permission system, realizing a trust model that integrates "user-center" with "user-model-service" three-way collaboration. Leveraging the decentralized, immutable, and programmable characteristics of blockchain, it constructs an open, fair, verifiable, and incentivized MCP infrastructure, providing underlying support for large models to securely, compliantly, and scalably invoke external capabilities. From service registration to result return, all key steps are recorded on the blockchain, ensuring end-to-end verifiability. The responsibilities of users, models, and service providers are clearly defined, with separation of duties among the three parties. It supports various scenarios such as SaaS, API marketplaces, and enterprise internal controls. It meets the regulatory requirements for "transparent external tool invocation" in large model supervision, ensuring compliance friendliness. Through dual identities, quotas, and whitelists, it prevents malicious models or users from abusing services.

[0087] Example 2

[0088] A blockchain-based multi-party collaborative MCP registration, authorization, and execution method is proposed, comprising an MCP provider, an LLM provider, and an end-user, which realize the registration, joint authorization, and trusted execution of MCPs through smart contracts.

[0089] The MCP registration information includes an authorization mode field, which specifies that permission verification must be based on the end user, the LLM provider, or a combination of both.

[0090] The authorization credential is indexed by the end user address, the LLM provider address, and the MCP identifier, and dual identity signature verification is required before the call.

[0091] During the execution phase, the off-chain MCP service is invoked via an oracle, and the call log (including the identities of the third parties, time, and result hash) is written back to the blockchain.

[0092] The cost is shared by the end user and the LLM provider according to a preset ratio at the time of registration, and is settled automatically through a smart contract.

[0093] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A blockchain-based multi-entity collaborative MCP registration, authorization, and execution method, characterized in that: The system comprises three parties: the MCP provider, the LLM provider, and the end user. Coordination is achieved through blockchain smart contracts, with an oracle acting as a trusted off-chain agent to facilitate interaction among the three parties. The MCP provider has a blockchain address on the blockchain. The LLM provider owns a blockchain address on the blockchain. End users own blockchain addresses on the blockchain. ; Includes the following steps: S1: Register MCP metadata and upload it to the blockchain; Register the on-chain identity and service information of LLM and MCP providers, and generate registration records; S2: Request authorization for the user-LLM combination; The LLM provider receives end-user requests, submits application parameters to the smart contract, verifies on-chain rules, and approves authorization through front-end or off-chain review. Once approved, it generates an authorization certificate. S3: LLM initiates a double-signature call; The LLM inference engine generates an MCP call request, and based on the authorization credentials, generates an MCP call package containing dual identity signatures to initiate an on-chain call request to the blockchain smart contract. S4: Contract verification and execution triggered; The MCP call package verifies identity and permissions. If the verification is successful, the fee is calculated, the token is locked, and the oracle is triggered to execute the off-chain MCP service call. If the verification fails, the call is terminated directly and an exception is thrown. S5: The oracle returns the result and updates the state; After the oracle completes the off-chain MCP service, it will upload the execution result back to the blockchain, update the on-chain state, settle fees, and generate audit logs.

2. The blockchain-based multi-entity collaborative MCP registration, authorization, and execution method as described in claim 1, characterized in that: Step S1 includes: S11: LLM provider registers to generate on-chain state; LLM provides the LLM provider to submit LLM registration parameters to the LLMRegistry smart contract on the blockchain, generate the decentralized unique identity identifier llm_did of the LLM provider, and generate on-chain state; S12: MCP providers register and obtain registration records; MCP provides the MCPRegistry smart contract on the blockchain to submit MCP registration parameters; it calls the MCPRegistry smart contract to generate a globally unique identifier mcp_id for the MCP service, performs on-chain verification, and finally solidifies the MCP registration parameters and the globally unique identifier mcp_id into an on-chain registration record. .

3. The blockchain-based multi-entity collaborative MCP registration, authorization, and execution method as described in claim 2, characterized in that: Specifically, it includes: S111: The LLM provider submits the LLM registration parameters; In response to the registration operation, the LLM provider actively submits the LLM registration parameters to the blockchain LLMRegistry smart contract; S112: On-chain processing generates a decentralized unique identifier llm_id; The LLMRegistry smart contract calls the LLMRegistry.registerLLM() method to obtain the blockchain timestamp at the time of the LLMRegistry smart contract execution, and then compares the blockchain timestamp with the blockchain address. A centralized, unique identifier llm_id with a fixed-length hash value is generated using a hash algorithm; S113: Generate on-chain state ; Obtain the LLM registration parameters and the decentralized unique identifier llm_id, and output them in a fixed format to solidify them into an on-chain state. ; On-chain state This includes the LLM identifier llm_id and the blockchain address of the LLM provider. Model name (model_name), IPFS hash (capability_hash) describing model capabilities, compliance certificate hash (compliance_cert), and billing mode (billing_mode); S121: The MCP provider submits the MCP registration parameters; The MCP provider actively submits the MCP registration parameters to the MCPRegistry smart contract; Registration parameters include: IPFS hash spec_hash from the MCP specification file, authorization mode auth_mode, LLM compliance attribute requirements required_compliance, pricing strategy, resource billing parameters cost_model_params, and charging scheme λ; S122: On-chain verification processing; 1) Generate a globally unique identifier for the MCP, mcp_id; The MCPRegistry smart contract uses the blockchain address of the MCP provider. The blockchain timestamp at the time of execution of the MCPRegistry smart contract is used to generate a fixed-length hash value for the globally unique MCP identifier mcp_id through a hash algorithm; 2) Verify the whitelist; Calling the on-chain state in the LLMRegistry smart contract To obtain the llm_id, the MCPRegistry smart contract, during registration, iterates through all llm_ids in allowed_llm_ids and verifies whether each llm_id in allowed_llm_ids is in the LLMRegistry smart contract; if yes, proceed to the next step; otherwise, filter the llm_id. 3) Filter compliance attributes; If the MCP provider specifies required_compliance, then the LLM provider llm_id that meets the compliance attributes is selected from the LLMRegistry smart contract and updated to the whitelist; 4) Store metadata; The MCPRegistry smart contract stores the verified and compliant MCP registration parameters and the generated mcp_id on the blockchain, and broadcasts MCPRegistered(mcp_id, ...) to the entire blockchain network. )event; S123: Generate registration records on the blockchain; The registration parameters of the metadata and the generated mcp_id are solidified into an on-chain registration record. .

4. The blockchain-based multi-entity collaborative MCP registration, authorization, and execution method as described in claim 3, characterized in that: Step S2 includes: S21: Trigger authorization request; The LLM provider receives inference requests from end users, analyzes them to obtain the MCP service to be invoked, obtains the mcp_id, and reads the corresponding registration record from the MCPRegistry smart contract. Obtain the authorization mode auth_mode; S22: Submit an authorization request; The LLM provider, on behalf of itself and the end user, submits application parameters to the MCPAccessControl smart contract; S23: Verify on-chain rules; According to registration records Verify the integrity of the identity and the whitelist separately; S24: Conduct front-end or off-chain audits; If the MCP provider reviews the application and rejects it, it will return an authorization failure message; if the review is successful, it will proceed to the next step. S25: Generate authorization certificate; The MCP provider calls the MCPAccessControl smart contract to generate a unique on-chain authorization certificate. And store.

5. The blockchain-based multi-entity collaborative MCP registration, authorization, and execution method as described in claim 4, characterized in that: S231: Verify the integrity of the identity; According to registration records The authorization mode auth_mode in the system is verified; S232: Verify the whitelist; Registration records If allowed_llm_ids is not empty, then check if the current llm_id is in the whitelist; if not, the application will be rejected directly.

6. The blockchain-based multi-entity collaborative MCP registration, authorization, and execution method as described in claim 4, characterized in that: The application parameters include: mcp_id, llm_id, and the end-user blockchain address. LLM provider blockchain address Maximum number of calls Expiration time Scope of permissions ; Authorization Certificate : ; ;in, This represents the number of times the function has been called; the initial value is 0. This is the authorization effective time, which is the execution start time. The default value is the current timestamp when the authorization certificate is generated. Maximum number of calls; Expiration date; This refers to the scope of permissions.

7. The blockchain-based multi-entity collaborative MCP registration, authorization, and execution method as described in claim 6, characterized in that: Step 3 includes: S31: Generate a call request; The LLM inference engine, based on the end user's original request and the scope of permissions granted by authorization credential A, Generate the specific call parameters params for the MCP service, and generate the call package for the MCP service call request; the call package includes the specific call parameters params, the mcp_id of the MCP service to be called, and the LLM identifier llm_id; S32: Perform dual signature; End users use their own private key (SKU) to sign the call packet, generating a user signature. The LLM provider uses its own private key skl to sign the call packet, generating an LLM signature. ; S33: Initiate an on-chain call; The LLM inference engine encapsulates the call parameters and double signatures into a complete call package. Submit a call package to the MCPExecutor smart contract Initiate an MCP service call request.

8. The blockchain-based multi-entity collaborative MCP registration, authorization, and execution method as described in claim 7, characterized in that: Step S4 includes: S41: Verify the identity and permissions of the calling package; Verify the identity of the calling package: Invoke the blockchain signature verification algorithm to verify the user's signature. and LLM signature Validity; Verify the authorization credentials: Read the authorization credentials corresponding to the call package Q from the MCPAccessControl smart contract. Verify the authorization credentials respectively If the number of calls is less than the maximum number of calls, the blockchain timestamp during verification is less than the authorization expiration time, and the specific call parameters of the MCP service are within the permission range, then the authorization is deemed valid; otherwise, the authorization is deemed invalid. If the authorization is invalid, the process is terminated and an exception is thrown. S42: Calculate fees and lock tokens; According to the calling package Q Read the corresponding registration record from the MCPRegistry smart contract To obtain the base price for pricing cost_model_params: Resource billing parameters α and β, based on the formula Calculate the total cost of a single call ;in, It counts the number of tokens for the specific call parameters (params). Estimated execution time for MCP services, based on MCP provider statements or historical execution averages on the blockchain; S422: Locked tokens; Obtain the charging scheme λ, and according to the charging scheme λ, deduct funds from the end user's blockchain address. and the blockchain address provided by LLM Locked tokens; The locked amounts are as follows: End user λ· LLM provider (1-λ) ; S43: Trigger an off-chain oracle call to MCP; The oracle monitors the execution of the MCPExecutor smart contract in real time, reads on-chain call requests, and retrieves information from the registration records. The URL of the off-chain call endpoint for the MCP service is parsed out, and the specific call parameters (params) of the call packet Q are used as input parameters to initiate an off-chain MCP service call. The start time of the MCP service execution is recorded. After the off-chain MCP service is completed, the execution result is obtained; The execution results include the execution results of the MCP service. and actual time spent .

9. The blockchain-based multi-entity collaborative MCP registration, authorization, and execution method as described in claim 8, characterized in that: Step S5 includes: S51: Execution result is uploaded and sent back to the blockchain; The oracle will execute the results of the MCP service. Generate hash value Write it back to the chain; S52: Update authorization status; The number of times it has been invoked in authorization credential A Atom increments are performed, increasing the value by 1; S53: Settlement Fees: Unlock locked tokens, release tokens, and return the tokens held by the user. Tokens provided by LLM providers From the blockchain address of the end user respectively And LLM provider blockchain address The amount deducted from the blockchain address transferred to the MCP provider is [not specified]. ; S54: Generate audit logs; Generate an on-chain audit log L and store it on the blockchain.

10. The blockchain-based multi-entity collaborative MCP registration, authorization, and execution method as described in claim 9, characterized in that: The on-chain audit log L includes the blockchain address of the end user, the blockchain address of the MCP provider, and the blockchain address of the LLM provider. , The start time, end time, and result of the MCP service execution. The hash value.

Images