Monetization trust management method in cloud edge collaborative network

Abstract

The invention discloses a monetization trust management method in a cloud edge collaborative network. The method comprises the following steps: firstly, registering equipment accessed to a network by a cloud center, verifying the identity of the equipment, and issuing initial trust assets for the equipment; the device then completes the interaction using the trusted assets. In the specific interaction task, a task applicant submits a task needing to be completed through cooperation of other devices to the management center, the management center evaluates task income, gives a task decomposition method, makes a task contract and notifies candidate devices, and the candidate devices agree to participate in the task and then execute the contract, become service providers and execute services. After the task is completed, a result is transmitted back to the task applicant, the task applicant reports a task result verification report to the cloud center, and the cloud center judges whether to initiate task result arbitration or not based on the content of the verification report and distributes earnings to related equipment based on the result according to the value created by the task. The method does not defend specific network threats, and is suitable for cloud edge collaborative networks of various scales.

Description

Technical Field

[0001] The present invention belongs to the technical field of radio networks, and in particular relates to a monetized trust management method in a cloud-edge collaborative network. Background Art

[0002] The cloud-edge collaborative network is a new computing architecture that combines cloud computing with edge computing. It processes some computing tasks on edge devices close to the data source to achieve layered and distributed data processing, thereby effectively reducing network bandwidth pressure, shortening data processing delays, and improving the overall performance of the system. In the cloud-edge collaborative network, edge servers are usually deployed near the data source or the edge of the network, and are served by devices such as base stations and routers. Mobile devices such as drones also serve as edge servers to increase coverage. These devices have stronger computing, storage, and network capabilities than ordinary mobile devices, and can process and analyze data locally, and then upload part or all of the processing results to the cloud for further analysis or storage. The cloud server undertakes the integration and complex computing tasks of global data, while providing powerful computing resource support for edge nodes. This collaborative model allows a large amount of data to be processed locally at the edge, avoiding the high network overhead and time delay of transmitting all data to the cloud; it also retains the powerful processing and storage capabilities of cloud computing methods.

[0003] However, due to the open environment characteristics of this type of network, any device may be subject to external intrusion or internal malicious tampering. Therefore, the trustworthiness of the device can only be determined in the initial deployment. After a period of operation, the identity status of the device cannot be directly obtained, and it is necessary to judge whether the device is reliable based on specific evidence.

[0004] Since there are many types of cloud-edge collaborative network devices, designing a credibility assessment method for each device is extremely labor-intensive and costly. Therefore, the present invention considers the interactive and collaborative characteristics of the cloud-edge collaborative network, takes the task results as the basis for increasing or decreasing the credibility of the device, and proposes a trust currency management method.

[0005] At present, the relevant research literature on trust management methods for the Internet of Things is as follows:

[0006] 1. In 2022, Vijay Varadharajan et al. proposed a trust model and attribute-based trust authentication mechanism TMANO for 5G network service slices in "Toward a Trust Aware Network Slice-Based Service Provision in Virtualized Infrastructures". After collecting user / provider requests for network slices, the authenticated attributes of VNFs and virtual machines are determined by the authority, and the hash digest of the VNF status is matched with the reference hash digest provided by the VNF manufacturer to evaluate the trust level of the virtual network functions that make up the network slice. This solves some security challenges caused by running different network slices on 5G infrastructure.

[0007] 2. In 2024, José María Jorquera Valero et al. proposed a reputation-based trust management framework in "SLA-Driven Trust and Reputation Management Framework for 5G Distributed Service Marketplaces". The framework simultaneously takes into account the values ​​of the transaction side and the network relationship side to calculate the trust value of an entity. The transaction side parameters refer to the satisfaction of the service object, the transaction background and the degree of certainty. The results show that the framework of this paper has a very high level of defense against reputation attacks in 5G and future network transactions, and helps to build trust relationships between interest communities and help to carry out cooperative interactions.

[0008] 3. In 2023, Bohan Li et al. proposed a decentralized trust management solution embedded in blockchain in "Trust Management Strategy for Digital Twins in Vehicular Ad Hoc Networks" to address the situation where malicious vehicles provide false information to interfere with the digital chaos of the Internet of Vehicles. This solution actively detects data transmitted between vehicles to eliminate malicious entities and maintain the security of the twin network. Summary of the invention

[0009] In response to the above problems, the present invention proposes a monetized trust management method in a cloud-edge collaborative network, which transforms the credibility of network entities into network security assets, manages the credibility of devices based on the interaction results of network entities, and restricts the network activities of low-credibility entities.

[0010] The present invention introduces two trusted key components, the cloud center and the management center, in the cloud-edge collaborative network that can be directly maintained by network managers. The cloud center is the highest-authority security agency in the network, deployed on cloud devices, with a built-in dedicated security capability resource pool, which comprehensively manages the identity information of all devices. It has the highest authority in the entire network and is responsible for evaluating the benefits created by the tasks for the network and the allocation of trust currency. The management center is deployed on fixed base station edge devices to manage the tasks applied for by devices in the subordinate subnets, clarify the task participation costs according to the pricing strategy of the cloud center, estimate the basic benefits of the applied tasks, write and publish task contracts, integrate the security capabilities and resources of the subnet devices under its jurisdiction, analyze the situation, and maintain trust consensus.

[0011] The trust currency issued by the cloud center is used as a credit collateral for the device to participate in network activities. In this management mechanism, credibility is an asset that the entity can use. The benefits created by the device for the network through interaction. The more trust assets a device holds, the higher the credibility of the device. Normal entities earn more trust currency by successfully executing network tasks and increase their credibility. Malicious entities will lose trust assets due to the destruction of interactions and damage to the interests of the network. Eventually, they will be restricted from participating in network activities due to low credibility. Before participating in network activities, the device will be charged a portion of trust currency as a deposit to guarantee that it will complete the task seriously. After the task is completed, the device will receive more trust currency income than this cost. After the task fails, the device needs to be responsible for the losses caused. If the device causes the task to fail, it will not be able to recover the trust currency paid in advance, thus causing its own trust assets to be damaged and credibility to be reduced.

[0012] To achieve the above technical objectives and the above technical effects, the present invention is implemented through the following technical solutions:

[0013] A monetized trust management method in a cloud-edge collaborative network comprises the following steps:

[0014] Step 1: Initial Trust Asset Allocation for Devices

[0015] After the cloud-edge collaborative network is deployed, various devices are allowed to access the network. For new devices accessing the network, the cloud center first registers the device information, discloses the device's public key, and then issues the corresponding initial trust currency based on the device's capability level as credit collateral for the device's subsequent participation in network affairs.

[0016] Step 2: Task Release and Task Acceptance

[0017] In the present invention, any devices can interact with each other, that is, devices with weak processing power can offload tasks with high computing power requirements to upper-layer devices with strong processing power, and the upper-layer devices will return the calculation results after the calculation is completed; or busy devices can offload part of the tasks to idle devices to reduce the time of task processing to improve work efficiency; or high-level network devices can issue management policies to low-level devices. The present invention adopts a hybrid offloading model, and the tasks that the device needs to offload can be completely offloaded to other devices, or only part of the tasks can be offloaded.

[0018] In the cloud-edge collaborative network, the present invention introduces two components: a cloud center and a management center; the cloud center is deployed on cloud devices and serves as the core of network coordination, responsible for analyzing global benefits and adjusting allocation plans; the management center is deployed on fixed base station edge devices to manage tasks applied for by devices in the subordinate subnets, clarify the task participation costs according to the pricing strategy of the cloud center, estimate the basic benefits of the applied tasks, write task contracts and publish them.

[0019] When a device has a need for collaboration, it publishes a task collaboration application to the management center of its subnet, describing the task content, type, time limit, and amount of data to be processed. After receiving the application, the management center evaluates the scale of the task, analyzes the minimum processing resources required to undertake the task, and determines the minimum benefit for completing the task. It then creates a contract for the task and sends it to the candidate device. The candidate receives the contract, confirms its participation in the task, and then contacts the management center to sign the contract and become a service provider. The management center clarifies the task applicant information and service provider information for this task, records the final contract, and charges both parties for the task participation cost.

[0020] In the present invention, the benefits created for the network by a successful task are higher than the amount of trust currency paid for participating in the task, so the task-related equipment will not suffer losses after the task is successfully executed; but the failure of the task will bring losses to the network, that is, negative benefits, and the related equipment needs to bear the responsibility, and the management mechanism includes responsibility identification and tracing.

[0021] Step 3: Task Execution

[0022] In accordance with the contract signed with the management center, the service provider allocates local processing resources to provide corresponding services to the task applicant, including specific projects such as data processing, computing and storage operations. In this process, the service provider needs to record the various resources consumed when executing the task as verification material for subsequent accounting. After the task is processed, the service provider will accurately and promptly transmit the task results to the task applicant through secure data transmission.

[0023] Step 4: Task result verification and feedback

[0024] After the task applicant receives and reviews the task processing results, the review results will be reported to the cloud center. If the task applicant approves the result of the service provider, proceed to step five; if the task applicant does not approve the result of this service, the arbitration mechanism needs to be initiated.

[0025] Step 5: Task Reward Settlement

[0026] After the cloud center receives the task result verification report uploaded by the task applicant or arbitration agency, it evaluates the overall benefit of the task to the network, and then allocates rewards or penalties to each participant based on the degree of contribution, and distributes the benefits to related equipment.

[0027] Step 6: Update device trust assets

[0028] After a mission is completed, all related equipment will increase their assets based on the original assets according to the new currency issued by the cloud center; or lose assets according to the penalty determined by the cloud center.

[0029] The relevant equipment gains or loses trust currency on the basis of its original assets. Since the amount of assets held is directly linked to the credibility of the equipment, the credibility of the equipment is evaluated through the update of trust assets. The initial trust assets of the equipment can only support its participation in tasks within the processing capacity of the device, and it cannot apply to collaborate with other devices to complete tasks with higher computing power requirements. Only by taking over and conscientiously completing the interactive collaboration with other devices and increasing the trust assets it holds can the equipment unlock and participate in more complex tasks. In this process, the cloud-edge collaborative network will continue to gain benefits.

[0030] In step 1 above, the information that needs to be registered when a new device joins the network is represented by the following tuple:

[0031] <μ,D,C>

[0032] Where μ is the device verification code, which is the unique identifier of the device identity information. The network uses this to identify the device and provide service configuration for it. Where D is the DID document that stores the device public key information, which can be used to establish a secure link later. C is the device capability, including the device's hardware configuration, processing power, supported communication protocols, etc.

[0033] In the above step 1, devices can be divided into three levels according to their processing capabilities, from low to high: end device p1, edge server p2 and cloud server p3. The network grants the corresponding initial trust assets to new devices joining the network according to the device's capability level. In the present invention, trust assets refer to certified trust equivalents issued by the cloud center and are used to measure the ability of the entity holding them to complete tasks as expected. The issuance of trust assets is as follows:

[0034] T=f(pn ) = a × p n b +c

[0035] Where p n is the processing capacity of the device. Since the end device has the weakest capacity, it obtains the lowest level of initial trust assets as a guarantee for completing basic interactions. In addition to completing basic interactions, edge devices also need to handle complex tasks, so they obtain more initial currency. Cloud devices have the strongest processing capacity in the network, hold more initial trust assets, and perform tasks with the highest computing power and storage requirements in the network. In the formula, a is the network scale coefficient. The cloud center confirms the order of magnitude weight of the currency issued based on the estimated number of network access devices. b is the marginal benefit coefficient. The present invention believes that when there is a lack of high-processing capacity devices in the entire network, the addition of new edge devices and cloud devices will provide the network with greater processing capacity, thereby granting these devices more initial trust assets. When the high processing capacity reaches a certain number, the newly added devices are no longer considered rare devices, and the initial trust currency obtained is correspondingly less than the devices that have been connected to the network earlier. c is the basic currency constant, and its amount can be used as a credit guarantee for the device to participate in basic tasks.

[0036] In the above step one, the trust currency serves as the credit collateral for the device's subsequent participation in network affairs, which means that the device uses part of its trust assets as a guarantee for completing the tasks it participates in, to ensure that it will complete the tasks normally. This credit collateral is authorized and issued by the security center and serves as the only general equivalent to measure the degree of trust in the entire cloud-edge collaborative network.

[0037] In the above step 2, the task application submitted by the task applicant to the management center is represented by the following tuple:

[0038] <rid,s,f>

[0039] Where rid is the identity information of the task applicant, s is the parameter tuple describing the service being applied for, and f is the purpose of the service being applied for.

[0040] In the above step 2, the contract formulated by the management center according to the received application request is expressed as follows:

[0041] <rid,r,O,S,q,c,p>

[0042] Where rid is the identity information of the task applicant, O is the set of candidates, S is the set of tasks after normalized decomposition, q is the recommended service quality parameter, c is the task participation cost, and p is the minimum benefit that the service provider can obtain after the task is completed.

[0043] In the above step 2, the candidate device contacts the management center and signs a contract. The format of the contract is as follows:

[0044] <rid,sid,r,S,q,c,p>

[0045] The contract specifies the identity information sid of the service provider.

[0046] In the above step three, allocating local processing resources to provide corresponding services to task applicants means that the service provider allocates part of its own CPU cores, or even GPU resources, and spends some time to complete the task requested by the task applicant.

[0047] In step 3 above, the format of the supporting materials recorded by the service provider is as follows:

[0048] <sid,S s ,q s ,r s >

[0049] Where sid is the identity information of the service provider, S s For the services it promises to provide, s The task quality parameter provided for it, r s The resources provided to complete the task include computing power, storage space, network bandwidth, etc.

[0050] In the above step 4, after the task applicant checks the task results performed by the service provider and reports to the cloud center, there are two situations: the applicant approves the results or disapproves them:

[0051] If the result is approved, there is no dispute and step (4) is completed. If the result is not approved, the arbitration mechanism needs to be activated to determine the quality of the task result. At this time, the network will form an arbitration group of corresponding size according to the task level. The task applicant submits the received task result, and the service provider issues a resource expenditure certificate. The arbitration group member devices compare the resource expenditure certificate with the task result based on distributed verification. If it is reasonable to use the resources in the certificate to achieve the current result, it will be reported to the cloud center, and part of the task applicant's share will be deducted when the benefits are distributed. If the resources in the certificate can obviously achieve a better task result than the current one, it will be reported to the cloud center, and the service provider will be ordered to provide a satisfactory service again. Otherwise, the task participation cost of the service provider will be deducted and the participation cost paid by the task applicant will be returned.

[0052] There are three situations when the arbitration mechanism is activated: 1) The service provider is the lowest-level end device: In this case, the task applicant is dissatisfied with the result of the provider's processing. Two unrelated end devices and one edge device are required to determine the quality of this service based on the resource consumption certificate issued by the service provider and the task experience of the arbitrator. The result that exceeds half is regarded as the arbitration result;

[0053] 2) The service provider is a medium-level edge device: In this case, the task applicant is dissatisfied with the result of the provider's processing. Three unrelated end devices and two edge devices are required to determine the quality of this service based on the resource consumption certificate issued by the service provider and the arbitrator's experience in executing tasks. The service provider needs to issue more detailed logs for auditing, and the arbitration needs to go through two rounds of verification, with more than half of the results being the arbitration results.

[0054] 3) The service provider is the most advanced cloud device: In this case, the task applicant is dissatisfied with the result of the provider's processing. Three unrelated end devices and three edge devices are required to randomly select part of the task content for local processing and distributed verification based on the resource consumption certificate issued by the service provider, and combine industry standards, and even request help from other cloud service providers; after three rounds of verification, more than half of the results are used as the arbitration result.

[0055] In the above step 5, there are two situations when allocating benefits:

[0056] 1) If the task applicant approves the processing result of the service provider, the cloud center will issue the reward normally. The share of the task applicant and the service provider needs to be determined according to the contribution of both parties to the task;

[0057] 2) If the task applicant does not agree with the service provider's handling results and initiates the arbitration mechanism, the cloud center will distribute benefits according to the arbitration results. If the arbitration believes that the quality of the service meets the task requirements, the cloud center will normally issue the service provider's reward and the arbitration equipment's remuneration, and deduct some trust currency issued to the task applicant as appropriate, to ensure that the applicant does not suffer any loss at most; if the arbitration believes that the service quality is indeed insufficient, the service provider will be required to provide services that meet the quality requirements again, otherwise the cloud center will not give the service provider monetary rewards, and will withhold the task costs submitted by the service provider, and only return the task costs delivered by the task applicant, and give remuneration for the equipment participating in the arbitration.

[0058] The beneficial effects of the present invention are as follows:

[0059] The present invention discloses a monetized trust management method in a cloud-edge collaborative network, which does not rely on a preset fixed angle to evaluate the trustworthiness of network devices, and is used to optimize the trust management mechanism. The method uses the trust currency uniformly issued by the network security center as a general equivalent to measure the trustworthiness of devices, and no longer needs to design evaluation methods for heterogeneous devices, thereby optimizing the trust management method of multi-level heterogeneous large networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 It is a flow chart of the present invention;

[0061] Figure 2The process of applying for a task for a certain device and the subsequent cloud center issuing trust currency rewards based on the task benefits;

[0062] Figure 3 Arbitration situation for end devices by service providers;

[0063] Figure 4 Arbitration situations for edge devices by service providers;

[0064] Figure 5 The arbitration situation for cloud devices is provided by the service provider. DETAILED DESCRIPTION

[0065] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0066] The purpose of this invention is to optimize the trust management mechanism in the traditional Internet of Things. First, the trust in the network is monetized in combination with the "zero trust" concept. Trust evaluation of each device is no longer performed from the outside based on trust evidence. Instead, trust currency is used as a unified general trusted equivalent. It is considered that all access devices are not truly trustworthy. The trustworthiness of a device is only related to the amount of trust assets it holds. Devices with more trust assets will participate in network affairs without restriction, and devices with fewer trust assets will only be able to participate in tasks with lower costs. In addition, devices can earn trust currency by successfully executing tasks, and will also lose trust assets due to unfinished tasks. Based on this, a monetized trust management method in a cloud-edge collaborative network is proposed. Figure 1 As shown, the specific steps include:

[0067] Step 1: Initial Trust Asset Allocation for Devices

[0068] After the cloud-edge collaborative network is deployed, various devices are allowed to access the network. For new devices accessing the network, the cloud center first registers the device information, discloses the device's public key, and then issues the corresponding initial trust currency based on the device's capability level as a credit collateral for the device's subsequent participation in network transactions. Step 2: Task Release and Task Acceptance

[0069] In the present invention, any devices can interact with each other, that is, devices with weak processing power can offload tasks with high computing power requirements to upper-layer devices with strong processing power, and the upper-layer devices will return the calculation results after the calculation is completed; or busy devices can offload part of the tasks to idle devices to reduce the time of task processing to improve work efficiency; or high-level network devices can issue management policies to low-level devices. The present invention adopts a hybrid offloading model, and the tasks that the device needs to offload can be completely offloaded to other devices, or only part of the tasks can be offloaded.

[0070] In the cloud-edge collaborative network, two components are introduced: the cloud center and the management center; the cloud center is deployed on cloud devices and serves as the core of network coordination, responsible for analyzing global benefits and adjusting allocation plans; the management center is deployed on fixed base station edge devices to manage the tasks applied for by devices in the subordinate subnets, clarify the task participation costs according to the pricing strategy of the cloud center, estimate the basic benefits of the applied tasks, write task contracts and publish them.

[0071] When a device has a need for collaboration, it publishes a task collaboration application to the management center of its subnet, describing the task content, type, time limit, and amount of data to be processed. After receiving the application, the management center evaluates the scale of the task, analyzes the minimum processing resources required to undertake the task, and determines the minimum benefit for completing the task. It then creates a contract for the task and sends it to the candidate device. The candidate receives the contract, confirms its participation in the task, and then contacts the management center to sign the contract and become a service provider. The management center clarifies the task applicant information and service provider information for this task, records the final contract, and charges both parties for the task participation cost.

[0072] In the cloud-edge collaborative network, a device generates a demand, then executes a task application, the requested task is accepted by other devices and services are provided, and finally the trust currency is obtained according to the task results. Figure 2 shown.

[0073] Step 3: Task Execution

[0074] In accordance with the contract signed with the management center, the service provider allocates local processing resources to provide corresponding services to the task applicant, including specific projects such as data processing, computing and storage operations. In this process, the service provider needs to record the various resources consumed when executing the task as verification material for subsequent accounting. After the task is processed, the service provider will accurately and promptly transmit the task results to the task applicant through secure data transmission.

[0075] Step 4: Task result verification and feedback

[0076] After receiving and reviewing the task processing results from the service provider, the task applicant needs to feedback the inspection conclusion to the cloud center. If the task result is recognized by the task applicant, the process will continue to the fifth step; if the task result is not recognized, the arbitration mechanism will be triggered to resolve the dispute.

[0077] Step 5: Task Reward Settlement

[0078] Once the cloud center receives the verification report from the task applicant or the task result arbitration report from the arbitration agency, it will evaluate the overall benefits that the task brings to the network. Based on the evaluation results, the cloud center will distribute the benefits according to the contribution of each relevant device in the task.

[0079] Step 6: Update device trust assets

[0080] After a mission is completed, all related equipment will increase their assets based on the original assets according to the new currency issued by the cloud center; or lose assets according to the penalty determined by the cloud center.

[0081] The relevant equipment gains or loses trust currency on the basis of the original assets. Since the amount of assets held is directly linked to the trustworthiness of the equipment, the trustworthiness of the equipment is evaluated through the update of trust assets. The initial trust assets of the equipment can only support its participation in tasks within the processing capacity of the equipment, and cannot apply for collaboration with other devices to complete tasks with higher computing power requirements. Only by undertaking and conscientiously completing the interactive collaboration with other devices and increasing the trust assets held by itself can the equipment unlock and participate in more complex tasks. In this process, the cloud-edge collaborative network will continue to gain benefits. In the above step one, the registration information sent by the device to the cloud security center includes: 1) the device verification code μ as the unique identifier of the device identity information, which is used by the network to identify the device and provide service configuration for it; the did document D that stores the device public key information, which is used to establish a secure link later; the capabilities of the device, including the device's hardware configuration, processing power, supported communication protocols and other parameter sets C.

[0082] In step 1 above, the security center issues initial trust coins according to the processing capabilities of the devices. In the network setting, the processing capabilities of the devices can be divided into: 1) end devices p1; 2) edge devices p2; 3) cloud devices p3. The initial trust coins issued by the cloud security center are also as follows:

[0083] T=f(p n ) = a × p n b +c

[0084] The cloud center determines constants a, b, and c through historical data or expert experience.

[0085] In the above step 2, the task application format sent by the device to the management center is as follows:

[0086] <rid,s,f>

[0087] Contains the identity information rid of the task applicant, the description tuple s of parameters such as task time limit, data volume and task purpose, and the purpose f of the requested service.

[0088] In the above step 2, the contract formulated by the management center according to the received collaboration request is expressed as follows:

[0089] <rid,r,O,S,q,c,p>

[0090] Based on the task application, the contract also includes: the set of candidates O, the set of tasks S after normalized decomposition, the recommended service quality parameters q, the task participation cost c, and the minimum benefit p that the service provider can obtain after the task is completed.

[0091] After receiving the contract, the interested candidate device contacts the management center to sign the contract and confirm its service provider identity sid. The contract format finally confirmed by the management center is as follows:

[0092] <rid,sid,r,S,q,c,p>

[0093] In step 3 above, the local resources allocated by the service provider are greater than or equal to the lower limit of the resources recommended by the management center in the contract. The processing resources used include both CPU and GPU when possible. The format of the recorded resource proof is as follows:

[0094] <sid,S s ,q s ,r s >

[0095] sid is the identity information of the service provider, S s For the services provided by it, s is the quality parameter of the task it has achieved, r s The resources consumed by the task include computing power, storage space, network bandwidth, etc.

[0096] In the above step 4, disputes arise when the task applicant does not agree with the quality of the task processing results sent back by the service provider. At this time, the cloud center triggers the arbitration mechanism and arranges other devices unrelated to the task to form an arbitration organization to make a group decision on whether the task results are reasonable. The service provider then issues the recorded task resource certificate. The arbitration group is divided into three categories according to the type of service provider: 1) Level 1 arbitration group: such as Figure 3 As shown in the figure, it includes two task-independent end devices and one task-independent edge device. It adjudicates tasks whose service provider type is an end device. It judges whether it is reasonable to use the resources claimed by the service provider to achieve the current result based on the local historical data and task execution experience of the arbitration device. After a round of review, more than half of the results are reported to the cloud center as arbitration results. 2) Secondary arbitration group: Figure 4As shown in the figure, it includes three task-independent end devices and two task-independent edge devices. The task of adjudicating the service provider type as an edge device requires the service provider to provide additional detailed task logs. Based on the local historical data of the arbitration device and the task execution experience, it is judged whether it is reasonable to use the resources claimed by the service provider to achieve the current result. After two rounds of evaluation, more than half of the results are reported to the cloud center as arbitration results; 3) Three-level arbitration group: Figure 5 As shown, it includes three task-independent end devices and three task-independent edge devices. It uses distributed verification to randomly select some tasks for local execution when the service provider type is a cloud device. It also combines cloud computing industry standards and even seeks assistance from other cloud service providers to determine whether it is reasonable to use the resources claimed by the service provider to achieve the current result. After three rounds of review, more than half of the results are reported to the cloud center as arbitration results.

[0097] In the above step five, when the cloud center distributes benefits, if the verification report of the task applicant recognizes the task result, trust currency will be issued to the task applicant and service provider normally to ensure that the benefits of both parties are higher than the paid task cost; if the task applicant does not recognize the task result, he / she shall first pay the arbitration fee for the equipment participating in the arbitration, and then according to the arbitration report, if the report considers that the task result is reasonable, the trust currency of the service provider will be issued to ensure that the service provider’s benefits are higher than the paid task cost, and the trust currency of the task applicant will be issued as appropriate to ensure that the applicant does not suffer any loss at most; if the report considers that the task result is unreasonable, the cloud center will order the service provider to provide services that meet the quality requirements again, otherwise it will only issue trust currency to the task applicant to ensure that it is higher than the paid task cost, and withhold the task cost paid by the service provider.

[0098] According to its geographical location, it chooses to join the subnet of the area. If there is no subnet in the area, a natural distributed management strategy is adopted to form a new subnet. If there is a task that requires the help of other devices, a service application is required. The content of the application will be written into a smart contract. The contract records the goals that need to be completed and the restrictions on completing the task. After the contract is generated, it will be announced to all task candidates; after the candidate decides to participate in the task, he signs the contract to add his information to it and completes the task according to the content of the contract; after the task is completed, the service provider returns the execution result of this application task. If there is a situation where the task applicant does not recognize the result, a group decision is required to determine the result of the task execution. The cloud center issues trust currency to all participating devices based on the determined result.

[0099] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A monetized trust management method in cloud-edge collaborative networks, Its characteristics include the following steps: (1) Initial trusted asset allocation for devices: For devices that join the cloud-edge collaborative network, after the cloud center verifies the identity information of the device, it issues the corresponding level of initial trust currency as the initial trust asset according to the processing power of the device. The processing power of devices in the cloud-edge collaborative network is divided from low to high into: Use the following function to allocate the initial trust asset of the device: T=f(p n )=a×p n b +c Where a is the network scale coefficient. The cloud center determines the order of magnitude weight of the currency issued based on the estimated number of network access devices. b is the marginal benefit coefficient. c is the basic currency constant, and its amount serves as a credit guarantee for the equipment to participate in the basic tasks. (2) Task release and task acceptance: In the cloud-edge collaborative network, two components are introduced: the cloud center and the management center. The cloud center is deployed on cloud devices and serves as the core of network coordination, responsible for analyzing the overall benefits and adjusting the allocation plan. The management center is deployed on fixed base station edge devices to manage the tasks applied for by devices in the subordinate subnets, clarify the task participation cost according to the pricing strategy of the cloud center, estimate the basic benefits of the applied tasks, and write and publish the task contracts. After a device has a need for collaboration, it publishes a task collaboration application to the management center of its subnet, describing the task content, type, time limit, and amount of data to be processed. After receiving the application, the management center evaluates the scale of the task, analyzes the minimum processing resources required to undertake the task, and determines the minimum benefit of completing the task. It then creates a contract for the task and sends it to the candidate device. The candidate receives the contract, confirms its participation in the task, and then contacts the management center to sign the contract and become a service provider. The management center clarifies the task applicant information and service provider information for this task, records the final contract, and charges both parties for the task participation cost. (3) Task Execution: The service provider provides services to the task applicant according to the content of the signed contract, records the resource consumption of processing the task, and returns the task result to the task applicant after the task is completed; (4) Task result verification and feedback: The task applicant checks the task results performed by the service provider and reports to the cloud center. If approved, step (5) is executed. If not approved, the arbitration mechanism is activated. The cloud-edge collaborative network arranges unrelated devices to form an arbitration group. The service provider issues a summary of the recorded task processing. After the arbitration group reaches a consensus, the arbitration result is reported to the cloud center. (5) Mission Reward Settlement: The cloud center evaluates the benefits created by the task for the network based on the task results, and allocates rewards or penalties to each participant based on their contribution. (6) Device Trust Asset Update: After a mission is completed, all related equipment will increase their assets based on the original assets according to the new currency issued by the cloud center; or lose assets according to the penalty determined by the cloud center.

2. A monetized trust management method in a cloud-edge collaborative network according to claim 1, characterized in that The collaboration application issued by the task in step (2) is represented as follows: <rid,s,f> Including the applicant's identity information RID and the description parameters of the task applied for s The purpose of the tuple and the requested task f; the contract content prepared by the management center is as follows: <rid,r,O,S,q,c,p> Provide the minimum processing resources required for the task r , the minimum benefit p that can be obtained by completing the task, the candidate set of service providers O, the tasks S and task quality parameters q that need to be undertaken, and the cost of participating in the task c; after the candidate device decides to accept the task, the contract format finally determined by the management center is as follows: <rid,sid,r,S,q,c,p> The service provider's identity information sid is added.

3. A monetized trust management method in a cloud-edge collaborative network according to claim 2, characterized in that In step (3), the service provider completes the task according to the accepted contract, and with reference to the minimum processing resource amount r recommended by the management center in the contract, may provide more resources as appropriate to complete the task S it has accepted more efficiently; During the task completion, the resource expenditure proof spent by the device on executing this task needs to be recorded in the form of a log, and the result will be returned to the task applicant after the task is completed.

4. A monetized trust management method in a cloud-edge collaborative network according to claim 1, characterized in that In step (4), after the task applicant checks the task results performed by the service provider and reports to the cloud center, there are two situations: the applicant approves the results or disapproves them: If the result is approved, there is no dispute and step (4) is completed. If the result is not approved, the arbitration mechanism needs to be activated to determine the quality of the task result. At this time, the network will form an arbitration group of corresponding size according to the task level. The task applicant submits the received task result, and the service provider issues a resource expenditure certificate. The arbitration group member devices compare the resource expenditure certificate with the task result based on distributed verification. If it is reasonable to use the resources in the certificate to achieve the current result, it will be reported to the cloud center, and part of the task applicant's share will be deducted when the benefits are distributed. If the resources in the certificate can obviously achieve a better task result than the current one, it will be reported to the cloud center, and the service provider will be ordered to provide a satisfactory service again. Otherwise, the task participation cost of the service provider will be deducted and the participation cost paid by the task applicant will be returned.

5. A monetized trust management method in a cloud-edge collaborative network according to claim 4, characterized in that There are three situations in the arbitration mechanism, as follows: 1) The service provider is the lowest-level end device: In this case, the task applicant is dissatisfied with the result of the provider's processing. Two unrelated end devices and one edge device are required to determine the quality of this service based on the resource consumption certificate issued by the service provider and the task experience of the arbitrator. The result that exceeds half is regarded as the arbitration result; 2) The service provider is a medium-level edge device: In this case, the task applicant is not satisfied with the result of the provider's processing, and needs three unrelated end devices and two edge devices to determine the quality of this service based on the resource consumption certificate issued by the service provider and the arbitrator's experience in executing tasks; The service provider needs to produce more detailed logs for auditing, and arbitration needs to go through two rounds of verification, with more than half of the results being considered the arbitration results; 3) The service provider is the most advanced cloud device: In this case, the task applicant is dissatisfied with the result of the provider's processing. Three unrelated end devices and three edge devices are required to randomly select part of the task content for local processing and distributed verification based on the resource consumption certificate issued by the service provider, and combine industry standards, and even request help from other cloud service providers; after three rounds of verification, more than half of the results are used as the arbitration result.

6. A monetized trust management method in a cloud-edge collaborative network according to claim 1, characterized in that In step (5), the cloud center allocates rewards or penalties to each participant based on the degree of contribution, which means that in addition to the income of task applicants and service providers directly related to the task, which depends on the task results, arbitration fees also need to be allocated to the devices participating in the arbitration when the arbitration mechanism is activated.

7. A monetized trust management method in a cloud-edge collaborative network according to claim 1, characterized in that In the step (6), the relevant device gains or loses trust currency on the basis of the original assets. Since the amount of assets held is directly linked to the credibility of the device, the credibility of the device is evaluated through the update of trust assets. The initial trust assets of the device can only support its participation in tasks within the processing capacity of the device, and it cannot apply to collaborate with other devices to complete tasks with higher computing power requirements. Only by undertaking and conscientiously completing the interactive collaboration with other devices and increasing the trust assets held by itself can the device unlock and participate in more complex tasks. In this process, the cloud-edge collaborative network will continue to gain benefits.

Images