A Federated Cloud Service Method and System Based on Consortium Blockchain

Abstract

This disclosure relates to the field of cloud computing and discloses a method and system for federated cloud services based on a consortium blockchain. Specifically, it includes: initializing a first regional peer node, generating a public key and private key pair, and exchanging public keys, regional management service URLs, and regional identifier codes with other regional peer nodes of the cloud federated consortium blockchain; the first regional peer node calling the regional management service URLs of other regional peer nodes to obtain a list of available cloud resources; users of the first regional peer node submit cloud resource requests, and the administrator of the second regional peer node verifies the identity authentication identifier of the requesting user and releases the cloud resources. In this invention, each user of a regional peer node possesses an identity authentication identifier associated with the regional node identifier, which is unique throughout the entire federated cloud service, ensuring confidentiality and trustworthiness of transactions within the cloud federated consortium blockchain.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing and discloses a federated cloud service method and system based on consortium blockchain. Background Technology

[0002] Some countries / regions have established their own federated cloud service platforms for scientific research, such as the China Science and Technology Cloud, the European EGI, and the African Open Science Platform (AOSP). In September 2019, during the CODATA Beijing conference, the China Science and Technology Cloud team pioneered the initiative to jointly build the "Global Open Science Cloud" (GOSC). The "Global Open Science Cloud" is based on existing open science clouds or scientific research information infrastructure and platforms under construction or about to be built in various countries and regions. Following the universally accepted principles of equal exchange and sharing of resources and services, and adopting common technical specifications and interface standards, it aims to achieve intercontinental cloud service interoperability and federated services, enabling network interconnection, resource exchange, data and information sharing, and the sharing of algorithms and software tools, thus comprehensively supporting major global scientific and technological innovations.

[0003] Based on the public accessibility of data, blockchains are categorized into public blockchains, consortium blockchains, and private blockchains. Public blockchains offer completely open data, accessible to anyone, such as blockchains, aiming to achieve global value transfer and information sharing. Private blockchains restrict data use to internal purposes, often used for internal enterprise management to ensure data security and efficient processing, meeting specific business needs. Consortium blockchains fall between public and private blockchains, jointly managed by multiple organizations or institutions, allowing for the setting of management and read / write permissions for each organization or institution. Nodes in a consortium blockchain can only join or leave the network after authorization, typically corresponding to a physical entity. Mature open-source consortium blockchains include Hyperledger Fabric and FISCO BCOS. Inter-node recognition is generally achieved through digital certificates. Typically, a CA node collects user personal identification information and issues digital certificates. User personal identification information is recorded in a state database; when a user logs out, the digital certificate is revoked, and the associated personal identification information is deleted.

[0004] Each country / region, when establishing its own federal system, operates its own unified identity authentication and authorization system and IaaS cloud resource management system. Therefore, when building a global cloud resource federation management and trusted service using peer-to-peer nodes, it is crucial to consider the application of regionally self-built unified identity authentication within a consortium blockchain. This involves maintaining the unified identity authentication and authorization system of each country and region while ensuring peer-to-peer management among nodes, thereby achieving mutual recognition of user identities and interoperability of cloud resources across different countries and regions. Therefore, a federated cloud service methodology based on a consortium blockchain is needed to address the interoperability issues between different resource providers and users. Summary of the Invention

[0005] To address the interoperability issue between different resource providers and users, this invention discloses a federated cloud service method based on consortium blockchain, the method comprising:

[0006] When a member of the Cloud Federation Alliance Blockchain invites a peer node in the first region to join, and after obtaining permission, a new peer node in the first region is added.

[0007] The first regional peer node is initialized, generates a pair of public and private keys, and exchanges the public key, regional management service URL, and regional identification code with other regional peer nodes of the cloud federation blockchain;

[0008] The first regional peer node calls the regional management service URL of other regional peer nodes to obtain a list of available cloud resources;

[0009] The first regional peer node generates an identity authentication identifier for the users of the first regional peer node; the identity authentication identifier includes the regional identifier code information of the first regional peer node and the UUID returned by the unified identity authentication authorization service;

[0010] Users of the first regional peer node submit cloud resource applications. The first regional peer node generates and signs the cloud resource application transaction and packages the cloud resource application transaction information into a block for on-chain storage. The cloud resource application transaction includes user information and cloud resource configuration information. The user information is encrypted using the public key of the second regional peer node, which is the regional peer node of the cloud resource being applied for.

[0011] The second regional peer node periodically pulls cloud resource transaction requests from the cloud federation blockchain, decrypts and parses them using the private key of the regional peer node, converts them into relational data, and stores the user application records in the local database.

[0012] The administrator of the second-region peer node obtains the application record from the local database through the front-end page, verifies the identity authentication identifier of the applicant user, and after successful verification, the second-region peer node generates and signs the audit cloud resource transaction, and packages the audit cloud resource transaction information into a block for on-chain storage; the audit cloud resource transaction information includes applicant user information, application cloud resource configuration information, audit result information, and audit user information, wherein the applicant user information and audit user information are encrypted using the public key of the first-region peer node;

[0013] The cloud resource center of the peer node in the second region releases cloud resources and updates the used cloud resource table and available cloud resource table in the local database.

[0014] The first regional peer node periodically pulls the review results of user cloud resource applications from the cloud federation alliance blockchain, decrypts and parses them using the private key of the regional peer node, converts them into relational data, and stores the review results in the local database.

[0015] Users of the peer nodes in the first region use the cloud resources they have applied for.

[0016] When a member of the Cloud Federation Alliance Blockchain invites a peer node in the first region to join, the peer node in the first region joins the Cloud Federation Alliance Blockchain when the pass rate is reached or higher.

[0017] When a peer node in the first region leaves the Cloud Federation Alliance blockchain, it must reach a pass rate of 1 or higher.

[0018] The formula for calculating the throughput ratio is:

[0019]

[0020] Where n represents the number of members who agree, and m represents the total number of members in the cloud federation blockchain;

[0021] The withdrawal of peer nodes from the first region's cloud federation blockchain has no impact on users currently using cloud resources.

[0022] The second-region peer node's regional management service performs cloud resource expiration detection. If a cloud resource that expires in one week is detected, the user is prompted to renew it.

[0023] If expired cloud resources are detected, the relevant cloud resources will be deleted and the cloud resources will be reclaimed.

[0024] The first region peer node initialization step further includes:

[0025] Deploy and run the consortium blockchain software. The software version must be consistent with the cloud federation consortium blockchain and the relevant ledgers must be synchronized.

[0026] The deployment and operation of the regional management service is responsible for calling the relevant management and operation interfaces of the cloud resource center and calling the regional management services of peer nodes in other regions across domains.

[0027] Deploy and run front-end services to provide users in this region with unified cloud resource management and access points;

[0028] Deploy and run a unified identity authentication and authorization service to provide identity authentication and authorization for users in this region, generate identity authentication identifiers for users, and provide identity authentication identifier authentication services;

[0029] Deploy cloud resource center related software; if the peer nodes in this region do not provide cloud resource services, then deployment is not required.

[0030] Deploy and run the local database, and initialize the relevant data tables;

[0031] Exchange public keys, zone management service URLs, and zone identifier codes with other members of the Cloud Federation Consortium blockchain.

[0032] The application record table of the local database includes: application record ID, user identity authentication identifier, cloud resource configuration applied for by the user, application duration, regional peer node and cloud resource center of the applied resource, reviewer, and application status; wherein the cloud resource configuration applied for by the user can be either cloud host or object storage.

[0033] The steps for the administrator of the second-region peer node to verify the identity authentication identifier of the requesting user specifically include:

[0034] The second region peer node generates an identity authentication identifier for the users of the second region peer node, that is, it generates an identity authentication identifier for the administrator;

[0035] The administrator reviews cloud resource applications by sending a cloud resource review request from the front-end page. The cloud resource review request includes: the identity authentication identifier of the applicant user, the content of the cloud resource application, and the review result.

[0036] Upon receiving the request, the regional management service of the second regional peer node determines the regional peer node where the user is located based on the user's identity authentication identifier.

[0037] The second region peer node requests the region management service of the first region peer node to verify the identity authentication identifier of the applicant user;

[0038] The regional management service of the first regional peer node requests the unified authentication and authorization service of the regional peer node to verify the identity authentication identifier of the applicant user, and returns the result to the regional management service of the regional peer node;

[0039] The region management service of the first region peer node returns the authentication result to the front end;

[0040] After verifying the applicant's identity, the regional management service of the second-region peer node updates the application record table in the local database, changes the application status to "approved," and updates the reviewer to the administrator's identity authentication identifier.

[0041] Secondly, the present invention also provides a federated cloud service system based on consortium blockchain, characterized in that, for implementing the above method, it includes:

[0042] The cloud federation alliance blockchain is run by consortium blockchain software of multiple regional peer nodes. It consists of modules such as consensus algorithm and ledger. Peer nodes trust each other through public / private keys to achieve consensus among peer nodes and ensure trusted services across the federation.

[0043] Regional peer nodes, including consortium blockchain software, local databases, regional management services, front-end services, and unified identity authentication and authorization services, are used to interact with the cloud federation consortium blockchain via APIs. This enables functions such as user authentication and authorization within the region, cross-regional peer node user authentication, cloud resource management, user management, and service management. It also facilitates cloud resource application, review, and transaction data uploading to the blockchain, and provides a unified front-end access point. The cloud resource center provides cloud resource services, including cloud hosts and object storage. The cloud hosts are managed by a private cloud management system that virtualizes computing, storage, and network resources, while the object storage is managed by an object storage system that pools storage resources.

[0044] This invention proposes a federated cloud service method based on a consortium blockchain. Its advantage lies in the fact that each user on a regional peer node possesses an identity authentication identifier associated with the regional node identifier, ensuring uniqueness throughout the federated cloud service. When a transaction begins, the user's identity information within the transaction is encrypted, and user identity is authenticated through cross-domain access. This ensures that the applicant and reviewer information is only visible to the applicant and reviewer; other regional peer nodes can only read the transaction content and cannot access the user information, thus achieving confidentiality and trustworthiness of transactions within the cloud federated blockchain. Attached Figure Description

[0045] Figure 1 This is a diagram of a federated cloud service system based on consortium blockchain according to an embodiment of the present invention;

[0046] Figure 2 This is a flowchart illustrating a federated cloud service method based on consortium blockchain according to an embodiment of the present invention.

[0047] Figure 3This is an embodiment of the "join blockchain transaction" block structure of a federated cloud service based on a consortium blockchain according to the present invention;

[0048] Figure 4 This is a block structure for "application for cloud resource transaction" in a federated cloud service based on consortium blockchain, according to an embodiment of the present invention.

[0049] Figure 5 This is an embodiment of the "auditing cloud resource transactions" block structure of a federated cloud service based on a consortium blockchain according to the present invention;

[0050] Figure 6 This is an embodiment of the "exit blockchain transaction" block structure of a federated cloud service based on a consortium blockchain according to the present invention. Detailed Implementation

[0051] The preferred embodiments of the present invention are described below through examples. It should be understood that the specific embodiments described herein are for detailed explanation of the present invention and should not be construed as limiting the present invention. It should be noted that various changes and modifications can be made while adhering to the principles and core scope of the present invention, and these changes should all be considered to fall within the protection scope of the present invention. The specific implementation steps of the present invention will be described in detail with reference to the accompanying drawings.

[0052] Figure 1 This specification illustrates a federated cloud service system based on a consortium blockchain, which mainly includes a cloud federation consortium blockchain, regional peer nodes, and a cloud resource center.

[0053] The Cloud Federation Consortium Blockchain is run by consortium blockchain software from multiple regional peer nodes. It is used to achieve consensus among peer nodes and ensure trusted services across the federation.

[0054] In a specific embodiment, the cloud federation blockchain consists of modules such as a consensus algorithm and a ledger. The consensus algorithm can be implemented using PBFT, PoW, PoS, DPoS, RAFT, etc.; the ledger is based on a Merkle tree for distributed storage. Peer nodes establish mutual trust through public / private keys, for example, using asymmetric key encryption algorithms such as RSA, DSA, ECC, DH, etc. The consortium blockchain software can be implemented using Hyperledger Fabric, FISCO BCOS, etc.

[0055] Regional peer nodes interact with the Cloud Federation Alliance blockchain via API to implement functions such as user authentication and authorization within the region, user authentication across regions, cloud resource management, user management, and service management. It also enables cloud resource application, review, and transaction data to be uploaded to the blockchain, and provides a unified front-end access point.

[0056] In specific embodiments, regional peer nodes include software or services such as consortium blockchain software, local database, regional management service, front-end service, and unified identity authentication and authorization service.

[0057] Among them, the unified identity authentication and authorization service is used to realize user authentication and authorization of peer nodes in this region; the front-end service is used to provide users with a unified access point; the regional management service is used to provide interfaces related to cloud resource management, user management, and service management in this region; the consortium blockchain software is used to encapsulate user requests into transactions and sign them, and store the transaction results on the blockchain; the local database is a relational database used to record local business data, including user information, cloud resource information, regional peer node information, and resource application information.

[0058] The cloud resource center, invoked by the regional management service, is used to provide cloud resource services and is authenticated through a unified identity authentication and authorization service.

[0059] In a specific embodiment, the cloud service types provided by the cloud resource center include cloud hosts and object storage. The cloud hosts are managed by a private cloud management system to achieve virtualization of computing, storage, and network resources, while the object storage is managed by an object storage system to achieve pooled management of storage resources.

[0060] Figure 2 A flowchart illustrating a federated cloud service method based on consortium blockchain according to an embodiment of the present invention is provided, as shown in the example. Figure 2 As shown, the method of the present invention includes the following steps:

[0061] S101: Members of the Cloud Federation Alliance Blockchain invite the first regional peer node to join. When the pass rate is reached or higher, the "new regional peer node" joins the Cloud Federation Alliance Blockchain. For better description of the method of the present invention, it is referred to as the first regional peer node below.

[0062] Specifically, step S101 includes the following steps:

[0063] S1011: One of the members of the Cloud Federation Consortium Blockchain sends an invitation to the peer node in the first region to join the Cloud Federation Consortium Blockchain. The invitation request includes information about the peer node in the first region, such as whether it provides unified identity authentication and authorization services, and whether it provides cloud resource services. The request is packaged into a "join blockchain transaction," signed, and stored on the blockchain.

[0064] In a specific embodiment, the block structure is as follows: Figure 3As shown, the block body includes a transaction header, a transaction subject, and transaction content. The transaction header includes the transaction time, transaction hash, and version number. The transaction subject is the peer node of the first region. The transaction content includes a brief introduction of the peer node of the first region, information on whether the peer node of the first region provides unified identity authentication and authorization services, and information on whether the peer node of the first region provides cloud resource services.

[0065] S1012: All members of the Cloud Federation Consortium blockchain vote on the invitation to join the first-region peer node, replying with either "agree" or "disagree" and signing. If the approval rate reaches or exceeds the threshold, the first-region peer node joins, and the process proceeds to S1013; otherwise, it cannot join, and the process terminates.

[0066] The formula for calculating the pass rate is:

[0067]

[0068] Where n represents the number of members who agree; m represents the total number of members in the cloud federation blockchain.

[0069] S1013: Initialization of peer nodes in the first region.

[0070] The initialization process includes the following steps:

[0071] ① Generate a public / private key pair.

[0072] ② Deploy and run the consortium blockchain software. The software version must be consistent with the cloud federation consortium blockchain and synchronize the relevant ledgers.

[0073] ③ Deploy and run the regional management service, whose responsibility is to call the relevant management and operation interfaces of the cloud resource center and to call the regional management services of other regional peer nodes across domains.

[0074] ④ Deploy and run front-end services to provide users in this region with a unified cloud resource management and access portal.

[0075] ⑤ Deploy and run a unified identity authentication and authorization service to provide identity authentication and authorization for users in this region, generate a RegionCode-uuid identity authentication identifier for users, and provide identity authentication identifier authentication service. The identity authentication identifier includes the region identifier code information of the peer node in the first region and the uuid returned by the unified identity authentication and authorization service.

[0076] ⑥ Deploy cloud resource center related software. If the peer nodes in this region do not provide cloud resource services, then deployment is not required.

[0077] ⑦ Deploy and run the local database, and initialize the relevant data tables.

[0078] The "Available Cloud Resources Table" is written in batches based on the cloud resources provided by the cloud resource centers of the peer nodes in this region; if no cloud resources are provided, it is initialized to empty.

[0079] The "Used Cloud Resources Table" is initialized to empty and updated based on application and approval transactions.

[0080] The "User Table" is updated based on user registration information.

[0081] The "Regional Peer Node Information Table" is updated in item ⑧.

[0082] The "Application Record Form" is updated based on the user's cloud resource application.

[0083] ⑧ Exchange public keys, region management service URLs, and region codes with other members of the Cloud Federation Consortium blockchain.

[0084] S102: Users of the first region's peer nodes apply for cloud resources.

[0085] Specifically, step S102 includes the following steps:

[0086] S1021: Users of the first region peer node log in to the front-end page through the unified authentication and authorization service; the unified authentication and authorization service returns relevant information to the user, including: user email, username, peer node of the region, identity authentication identifier RegionCode-uuid and JWT token.

[0087] JSON Web Token (JWT) is an open standard based on JSON for transmitting claims between web application environments. JWT claims can be used to transmit authenticated user identity information between identity providers and service providers to facilitate resource retrieval from resource servers. The token can also be used directly for authentication or can be encrypted.

[0088] S1022: The front end automatically polls and calls the regional management service URLs of other regional peer nodes to obtain a list of available cloud resources.

[0089] S1023: When a user applies for cloud resources, the front-end page sends a cloud resource application request. The request header carries a JWT token, and the request content includes: user information (user email, username, and authentication identifier RegionCode-uuid) and cloud resource application information (cloud resource configuration, duration, and the cloud resource center of the applied resource).

[0090] To better describe the method of the present invention, the regional peer node for which the resource is applied will be referred to as the second regional peer node.

[0091] S1024: The regional management service writes user application records to the "Application Record Table" in the local database.

[0092] In a specific embodiment, the database definition of the "Application Record Table" in the local database is as follows:

[0093]

[0094]

[0095] S1025: Trigger the consortium blockchain software, call the relevant interface to read the "application record table" in the local database, generate "application for cloud resource transaction" and sign it, and package the "application for cloud resource transaction" information into a block for on-chain storage.

[0096] In a specific embodiment, the block structure is as follows: Figure 4 As shown, the block body includes a transaction header, a transaction subject, and transaction content. The transaction header includes the transaction time, transaction hash, and version number. The transaction subject consists of the applicant and the reviewer. The transaction content includes the applicant user and the requested cloud resource configuration information.

[0097] The specific details of "Applying for Cloud Resource Transactions" are as follows:

[0098] Requesting user information: This includes the user's identity authentication identifier. The requesting user information is encrypted using the public key of the peer node in the second region.

[0099] Request cloud resource configuration information: including cloud resource configuration, the name of the cloud resource center of the second region peer node, cloud resource usage duration, etc.

[0100] S103: The second-region peer nodes periodically pull, parse, and store the "Application for Cloud Resource Transactions" from the Cloud Federation Alliance blockchain.

[0101] In a specific embodiment, S103 includes the following steps:

[0102] S1031: The consortium blockchain software of the second region peer node calls the relevant interface to periodically pull the "Application for Cloud Resource Transactions" of the peer node in this region from the cloud federation consortium blockchain, decrypts and parses them using its own private key, and converts them into relational data.

[0103] S1032: Store user application records in the "Application Record Table" of the local database.

[0104] In a specific embodiment, the database definition of the "application record table" in the local database is the same as the database table definition in step S1024.

[0105] S104: The administrator of the peer node in the second region reviews the cloud resource application.

[0106] In a specific embodiment, S104 includes the following steps:

[0107] S1041: The administrator of the second region peer node logs in to the front-end page through the unified authentication and authorization service; the unified authentication and authorization service returns relevant information to the administrator, including the user's email address, username, the peer node of the applicant's region (i.e., the first region peer node), the identity authentication identifier RegionCode-uuid, and the JWT token.

[0108] S1042: The administrator of the peer node in the second region reviews the cloud resource application. The front-end page sends a cloud resource review request. The request header carries a JWT token, and the request content includes: the identity authentication identifier of the applicant, the content of the cloud resource application, and the review result.

[0109] S1043: The regional management service of the second region peer node receives the request, performs the following processing, and then returns a successful review response to the administrator.

[0110] In a specific embodiment, S1043 includes the following processing:

[0111] ① Based on the user's identity authentication identifier, determine the user's regional peer node, i.e., the first regional peer node;

[0112] ② Request the regional management service of the peer node in the first region to verify the identity authentication identifier of the applicant user;

[0113] ③ The regional management service of the first region peer node requests the unified authentication and authorization service of the peer node in this region to verify the identity authentication identifier of the applicant user and return the result to the regional management service of the peer node in this region;

[0114] ④ The regional management service of the peer node in the first region will return the authentication result;

[0115] ⑤ After verifying the applicant's identity, the regional management service of the second region peer node updates the "Application Record Table" in the local database, updating the "apply_status" field to "Approved" and the "reviewer" field to the administrator's identity authentication identifier.

[0116] S1044: Trigger the consortium blockchain software. The second-region peer node reads the "Application Record Table" in the local database, generates and signs the "Review Cloud Resource Transaction", and packages the "Review Cloud Resource Transaction" information into a block for on-chain storage.

[0117] In a specific embodiment, the block structure is as follows: Figure 5 As shown, the "Review Cloud Resource Transaction" content includes applicant user information, application cloud resource configuration information, review result information, and review user. Among them, the applicant user information and the review user information are encrypted using the public key of the peer node in the first region.

[0118] The specific details of "Reviewing Cloud Resource Transactions" are as follows:

[0119] User information: User identity verification identifier.

[0120] Request cloud resource configuration information: including cloud resource configuration, cloud resource center of the second region peer node, cloud resource usage duration, etc.

[0121] Review result information: approved or not approved.

[0122] Verify user information: Verify the user's identity authentication identifier.

[0123] S1045: The cloud resource center of the second-region peer node releases cloud resources and updates the "Used Cloud Resources Table" and "Available Cloud Resources Table" in its local database. At this time, users who applied for cloud resources on the first-region peer node can begin using them.

[0124] S105: The peer nodes in the first region periodically pull, parse, and store the review results of user applications for cloud resources from the cloud federation alliance blockchain, i.e., "review cloud resource transactions".

[0125] In a specific embodiment, S105 includes the following steps:

[0126] S1051: The consortium blockchain software of the first region peer node calls the relevant interface to periodically pull the review results of user applications for cloud resources from the cloud federation consortium blockchain, decrypts and parses them using its own private key, and converts them into relational data.

[0127] S1052: Store the relevant review results (reviewer, apply_status) in the "Application Record Table" of the local database.

[0128] S106: The regional management service of the regional peer node performs cloud resource expiration detection.

[0129] In a specific implementation, the regional management service of the regional peer node performs cloud resource expiration detection. If a cloud resource that expires in one week is detected, the user is prompted to renew it.

[0130] If expired cloud resources are detected, the relevant cloud resources will be deleted directly to reclaim them.

[0131] S107: When a peer node in the first region leaves the Cloud Federation Alliance Blockchain, the first peer node leaves the Cloud Federation Alliance Blockchain when the pass rate is reached or above.

[0132] In a specific embodiment, S107 includes the following steps:

[0133] S1071: The first peer node of the Cloud Federation Alliance Blockchain initiates an exit request, packages the request into an "exit blockchain transaction", signs it, and stores it on the chain.

[0134] In a specific embodiment, the block structure is as follows: Figure 6 As shown, the block body includes a transaction header, a transaction subject, and transaction content. The transaction header includes the transaction time, transaction hash, and version number. The transaction subject is the peer node that left the region, and the transaction content is the peer node that left the region.

[0135] S1072: All members of the Cloud Federation Consortium blockchain vote on the withdrawal request of the first-zone peer node, responding with either "agree" or "disagree" and signing their names. If the approval rate reaches or exceeds a certain threshold, the first-zone peer node withdraws; otherwise, it cannot withdraw, and the process terminates.

[0136] The formula for calculating the pass rate is:

[0137]

[0138] Where n represents the number of members who agree; m represents the total number of members of the cloud federation blockchain. In a specific embodiment, the total number of members of the cloud federation blockchain includes members who have applied to withdraw.

[0139] In a specific embodiment, the exit of the first region peer node from the cloud federation blockchain has no impact on users who are using cloud resources.

Claims

1. A federated cloud service method based on consortium blockchain, characterized in that, include: When a member of the Cloud Federation Alliance Blockchain invites a peer node in the first region to join, and after obtaining permission, a new peer node in the first region is added. The first regional peer node is initialized, generates a pair of public and private keys, and exchanges the public key, regional management service URL, and regional identification code with other regional peer nodes of the cloud federation blockchain; The first regional peer node calls the regional management service URL of other regional peer nodes to obtain a list of available cloud resources; The first regional peer node generates an identity authentication identifier for the users of the first regional peer node; the identity authentication identifier includes the regional identifier code information of the first regional peer node and the UUID returned by the unified identity authentication authorization service; Users of the first regional peer node submit cloud resource applications. The first regional peer node generates and signs the cloud resource application transaction and packages the cloud resource application transaction information into a block for on-chain storage. The cloud resource application transaction includes user information and cloud resource configuration information. The user information is encrypted using the public key of the second regional peer node, which is the peer node of the requested resource among the other regional peer nodes of the cloud federation blockchain. The second regional peer node periodically pulls cloud resource transaction requests from the cloud federation blockchain, decrypts and parses them using the private key of the regional peer node, converts them into relational data, and stores the user application records in the local database. The administrator of the second-region peer node retrieves the application records from the local database via the front-end page, verifies the identity authentication identifier of the applicant user, and upon successful verification, the second-region peer node generates and signs the audit cloud resource transaction, and packages the audit cloud resource transaction information into a block for on-chain storage; the audit cloud resource transaction information includes applicant user information, application cloud resource configuration information, audit result information, and audit user information, wherein the applicant user information and audit user information are encrypted using the public key of the first-region peer node; The cloud resource center of the peer node in the second region releases cloud resources and updates the used cloud resource table and available cloud resource table in the local database. The first regional peer node periodically pulls the review results of user cloud resource applications from the cloud federation alliance blockchain, decrypts and parses them using the private key of the regional peer node, converts them into relational data, and stores the review results in the local database. Users of the peer nodes in the first region use the cloud resources they have applied for. The steps for the administrator of the second-region peer node to verify the identity authentication identifier of the requesting user specifically include: The second region peer node generates an identity authentication identifier for the users of the second region peer node, that is, it generates an identity authentication identifier for the administrator; The administrator reviews cloud resource applications by sending a cloud resource review request from the front-end page. The cloud resource review request includes: the identity authentication identifier of the applicant user, the content of the cloud resource application, and the review result. Upon receiving the request, the regional management service of the second regional peer node determines the regional peer node where the user is located based on the user's identity authentication identifier. The second region peer node requests the region management service of the first region peer node to verify the identity authentication identifier of the applicant user; The regional management service of the first regional peer node requests the unified authentication and authorization service of the regional peer node to verify the identity authentication identifier of the applicant user, and returns the result to the regional management service of the regional peer node; The region management service of the first region peer node returns the authentication result to the front end; After verifying the applicant's identity, the regional management service of the second region peer node updates the application record table in the local database, changes the application status to "approved," and updates the reviewer to the administrator's identity authentication identifier.

2. The method according to claim 1, characterized in that, Also includes: When a member of the Cloud Federation Alliance Blockchain invites a peer node in the first region to join, the peer node in the first region joins the Cloud Federation Alliance Blockchain when the pass rate is reached or higher. When a peer node in the first region leaves the Cloud Federation Alliance blockchain, it must reach a pass rate of 1 or higher. The formula for calculating the throughput ratio is: Where n represents the number of members who agree; m represents the total number of members in the cloud federation blockchain; The withdrawal of peer nodes from the first region's cloud federation blockchain has no impact on users currently using cloud resources.

3. The method according to claim 1, characterized in that, Also includes: The second-region peer node's regional management service performs cloud resource expiration detection. If a cloud resource that expires in one week is detected, the user is prompted to renew it. If expired cloud resources are detected, the relevant cloud resources will be deleted and the cloud resources will be reclaimed.

4. The method according to claim 1, characterized in that, The first region peer node initialization step further includes: Deploy and run the consortium blockchain software. The software version must be consistent with the cloud federation consortium blockchain and the relevant ledgers must be synchronized. The deployment and operation of the regional management service is responsible for calling the relevant management and operation interfaces of the cloud resource center and calling the regional management services of peer nodes in other regions across domains. Deploy and run front-end services to provide users in this region with unified cloud resource management and access points; Deploy and run a unified identity authentication and authorization service to provide identity authentication and authorization for users in this region, generate identity authentication identifiers for users, and provide identity authentication identifier authentication services; Deploy cloud resource center related software; if the peer nodes in this region do not provide cloud resource services, then deployment is not required. Deploy and run the local database, and initialize the relevant data tables; Exchange public keys, zone management service URLs, and zone identifier codes with other members of the Cloud Federation Consortium blockchain.

5. The method according to claim 1, characterized in that, The application record table of the local database includes: application record ID, user identity authentication identifier, cloud resource configuration applied for by the user, application duration, second regional peer node and cloud resource center, reviewer, and application status; wherein the cloud resource configuration applied for by the user can be either cloud host or object storage.

Images