BECS: A Privacy-Preserving Computing Sharing Mechanism in 6G Computing Power Network

BECS is a generalized architecture that supports various types of computing sharing in 6G CPN, as illustrated in Fig. 1. All computing devices, labeled as $\mathbb{D}=\{D_{1},\ldots,D_{d},\ldots,D_{D}\}$, are classified into three layers: user computing layer, edge computing layer, and cloud computing layer. Specifically, the set of user computing devices, denoted as $\mathbb{U}=\{U_{1},\ldots,U_{u},\ldots,U_{U}\}$, includes smartphones, computers, wearable devices, IoT devices, vehicles, and other devices that directly interact with users. These devices typically possess limited computing power. The set of edge computing devices, denoted as $\mathbb{E}=\{E_{1},\ldots,E_{e},\ldots,E_{E}\}$, includes edge servers, roadside units, cloudlets, and other devices capable of providing time-sensitive computing services to users. The set of cloud computing devices, denoted as $\mathbb{C}=\{C_{1},\ldots,C_{c},\ldots,C_{C}\}$, consists of remote computing centers capable of providing large-scale computing power. The evolutionary algorithm matches computing resource requesters with providers, facilitating a multi-dimensional measurement of the deep reuse of computing resources. Additionally, with the support of permissioned blockchain, BECS enables dynamic management and trading of fine-grained computing resources. The proposed architecture consists of three main components:

1) Computing Resource Providers (CRPs): As large language models become increasingly widespread, devices with abundant computing power will increasingly provide computing support to devices with limited resources. In BECS, all devices within 6G CPN with free computing resources can serve as CRPs.

2) Computing Resource Requesters (CRRs): In general, when a device lacks sufficient computing capability to handle a task’s demands, it needs to request additional resources. In BECS, any device can be a CRR, provided that the requested resources exceed its own computing capacity.

3) 6G Base Stations (6GBSs): As critical components in BECS, 6GBSs provide reliable communication services to devices and serve as blockchain maintenance nodes responsible for transaction bookkeeping and block packaging. Each 6GBS consists of three components:

• •

  Registration and Certification Component (RCC): The RCC is responsible for managing the identities of devices and issuing and verifying certificates.

• •

  Computation Component (CC): The CC is responsible for maintaining the blockchain.

• •

  Storage Component (SC): The SC is responsible for storing data from devices and the blockchain.

This study primarily focuses on efficient computing sharing. Accordingly, the computing device $D_{d}$ is denoted as $D_{d}=\{\varsigma_{d},\psi_{d}\}$, where $\varsigma_{d}$ is usually measured by device’s CPU [16]. Meanwhile, $\mathbb{T}=\{T_{1},\ldots,T_{t},\ldots,T_{T}\}$ denotes the set of all computing tasks. The tuple $T_{t}=\{\varphi_{t},\xi_{t},\tau_{t},d_{t}\}$ describes the computing task $T_{t}$. $\varphi_{t}$ and $\xi_{t}$ can be obtained using methods described in [17], such as graph analysis. Notations that will be used are presented in Table I.

The NOMA-based 6G networks, regarded the most promising future multi-access technology, is considered in BECS. It allows multiple users to transmit on the same frequency band, thereby enhancing spectrum resource utilization [18]. This model primarily addresses the communication latency in wireless communications, thus overlooking the latency in wired connections. Let $g_{u}$ denote the instantaneous channel gain from $U_{u}$ to the offloading computing device. Without loss of generality, the channel gains for all $U$ devices are ordered in descending sequence: $g_{1}<\cdots<g_{u}<\cdots<g_{U}$. Using successive interference cancellation and decoding for the user with the highest received power, the data transmission rate for $U_{u}$ during the computing offloading is calculated via Shannon’s theorem as follows:

If $U_{u}$ offloads $T_{t}$ to $D_{d}$, the data transmission latency can be expressed as follows:

Therefore, the communication energy consumption of $U_{u}$ can be calculated as follows:

In the considered three layers computing sharing structure, the computing tasks of a CRR can be executed in any device of CRP. However, computing devices vary in terms of task transfer and processing capabilities. This intense competition for computing resources at each layer, inevitable in 6G PCN with numerous CRRs and CRPs, necessitates balancing the task load across the system’s layers. Generally, with limited computing resources at each layer, tasks may have to wait for an available processor. Therefore, the M/M/c model [19], which describes task offloading as a Poisson process with an average arrival rate of $\lambda_{t}$, can be used to model task processing delays. Based on the superposition property of the Poisson process and the offloading interactions among the three layers of computing resources, the average task arrival rate for each layer can be calculated as

Therefore, the average time consumption of each task at each layer, encompassing both the queuing and the execution times, can be calculated as

where $\rho_{d}$ can be calculated as $\rho_{d}=\frac{\lambda_{d}}{N_{d}\alpha_{d}\varsigma_{d}}$. $C(N_{d},\rho_{d})$ is known as Erlang’s C Formula, which can be calculated as

At the same time, the energy consumption of $D_{d}$ in each layer during the execution of computing tasks can be calculated as follows [20]:

where $\kappa_{d}$ is depending on the chip architecture.

1) Computing occupancy: As a direct factor of computing utilization, it can be quantified as the number of all devices participating in computing sharing while ensuring the provision of all network services. It is defined as follows:

with

2) Privacy entropy: More applicable computing offloading can be achieved by constructing three layers computing structures. However, the decentralization of computing devices introduces privacy leakage risks during task offloading. Privacy entropy, a method of quantifying privacy security, is used to measure the security of information transmission [21]. Higher privacy entropy indicates more disordered data, preventing attackers from making inferences and thereby ensuring secure information transmission.

The types of offloaded data vary according to the computing tasks. Thus, in BECS, we set the relationship between $T_{t}$ and $p_{d^{\ast}\to d,t}$ to be a one-to-one correspondence, and the privacy entropy of $T_{t}$ in $D_{d}$ can be calculated as

3) Load balancing: As a key metric for evaluating computing device workloads, load balancing aims to equalize each device’s load to the average. Concentrating multiple tasks on a single device diminishes computational efficiency and elevates energy consumption. The standard deviation of the tasks and the computing capabilities of the devices can reflect whether they are load balanced [22]. Therefore, the load balancing of $D_{d}$ can be calculated as

4) Sharing revenue: A suitable revenue can encourage the participation of computing devices in resource sharing, thereby enhancing the overall resource utilization. The logarithmic utility function is used to quantify the sharing revenue of $D_{d}$, which can be calculated as

The assumptions and requirements specified below are applied consistently throughout this article unless otherwise stated.

1) Computing tasks can be offloaded from the outer to the inner layer as depicted in Fig. 1, or within the same layers, provided that the computing capacity of CRP exceeds that of CRR.

2) Each user device is equipped with a single antenna, facilitating real-time communication with the 6GBS.

3) Edge and cloud computing devices are typically connected to the 6GBS through high-speed, reliable wired connections, such as optical fibers. The latency of these connections is significantly lower than that of wireless communication between user devices and the 6GBS, and can be considered negligible.

4) Based on the permissioned blockchain, user registration information is visible only to 6GBSs within the blockchain, whereas the computing resources status is visible to all users.

5) All users securely deliver their keys through a secure channel.

Based on the aforementioned model, total time and energy consumption can serve as metrics for computing cost and green 6G, which can be calculated as follows:

and

In addition, to ensure the user’s service experience, the computing resource utilization the average privacy entropy of the computing tasks, the load balancing of the computing devices, and the total sharing revenue of CRP are considered, which can be calculated as follows:

and

Assigning tasks to free computing devices can effectively improve the resource utilization of the entire system. However, focusing solely on utilization improvement is unscientific. Therefore, it is crucial to analyze the trade-offs among these intertwined and conflicting objectives. In BECS, our objectives include minimizing time and energy consumption, optimizing load balancing to maximize resource utilization, ensuring user experience, and simultaneously maximizing privacy entropy and CRP revenue. The MOOP is formulated as:

subject to:

Constraint (18) states that the actual task processing rate of the computing device must not exceed its service rate. Constraint (19) restricts the maximum transmit power of the user device. Constraint (20) guarantees that the task execution time does not exceed its deadline. Constraint (21) specifies that the computing energy consumption should not exceed the device’s maximum available energy. Constraint (22) differentiates the computing capacities across three layers and specifies task offloading from devices with lower capacity to those with higher capacity. Constraint (23) stipulates that the computing demands of tasks offloaded to executing devices must not exceed their capacities.

NSGA-III, an excellent evolutionary algorithm, can achieve fast global searches with quality assurance, preventing MOOP from settling into local optimality. Additionally, it tackles high-dimensional problems by preserving population diversity through uniformly distributed reference points [23]. In practical MOOP, maximizing population diversity while ensuring convergence is one of the best ways to quickly and effectively obtain the optimal solution. Consequently, NSGA-III-KDR is proposed to balance the aforementioned five objectives.

The performance of Pareto dominance relation-based algorithms often exhibits serious dimensionality implications due to dominance resistance in MOOP with more than three objectives [24]. To address this, Tian et al. [25] proposed a strengthened dominance relation (SDR) to enhance NSGA-II. Considering that NSGA-III builds upon NSGA-II by introducing reference points, we propose a kernel distance-based dominance relation (KDR) in NSGA-III-KDR. It builds on the theoretical foundation of SDR to replace the original Pareto dominance relation in NSGA-III. Specifically, if solution $X_{1}$ dominates solution $X_{2}$ in KDR, then (27) is satisfied.

where $\theta_{X_{1}X_{2}}$ represents the acute angle between the two candidate solutions $X_{1}$ and $X_{2}$, which can be calculated as $\theta_{X_{1}X_{2}}=\operatorname{arccos}\bigl{(}F(X_{1}),F(X_{2})\bigr{)}$, and $\overline{\theta}$ denotes the size of the niche to which each candidate solution belongs.

As the number of objectives increases, neither the Euclidean distance nor the Mahalanobis distance can accurately reflect the crowding degree between individuals [26]. Therefore, NSGA-III-KDR utilizes the kernel distance from the point $X$ to the ideal point $P_{ide}$ to measure the similarity between them in handling high-dimensional problems [27]. It can be calculated as follows:

Evolutionary algorithms utilize the concept of population evolution to tackle practical MOOPs. Here, individuals in a population are represented by a series of numbers, each mapped to potential solutions of a MOOP through specific encoding. Thus, encoding is crucial for implementing population evolution in practical MOOPs.

In BECS, the occupancy status of computing devices is encoded as genes, while the computing resources involved in sharing are encoded as chromosomes, constituting the entire CRP for evolution. As illustrated in Fig. 2, a gene value of 0 indicates a free computing device, whereas a value of 1 signifies that this device is occupied. This method allows BECS to integrate various types of computing resources, thereby building a generalized computing sharing platform. Since the occupancy status of computing devices directly correlates with gene encoding, and chromosomes relate to computing allocation strategies, dynamic and fine-grained updates of computing resources are enabled.

When the CRR requests computing resources, the system executes the computing allocation scheme based on NSGA-III-KDR to match the optimal CRP. NSGA-III-KDR basically follows the algorithmic framework of NSGA-III, as shown in Algorithm 1. During the evolution process, the chromosomes in the initial population $X^{1}$ generate entirely new chromosomes (computing allocation strategies) through crossover and mutation operations. The crossover operation enhances chromosome diversity, while the mutation operation, under specific conditions, modifies individual genes to seek those with higher adaptability. In each iteration, the population generated by crossover and mutation merges with the original, then executing a Non-KDR-dominated sort that replaces the non-dominated sort in NSGA-III, thereby effectively enhancing the diversity of the computing resource population. Subsequently, by associating chromosomes with reference points in the hyper-plane and executing the Niche-Preservation Operation, the next generation population can be generated. After $TI$ iterations of NSGA-III-KDR, the final population $X^{TI}$, containing the ultimate computing allocation strategy, is obtained.

The final population $X^{TI}$ comprises a set of the best feasible solutions for computing allocation, termed Pareto solutions. However, in practical computing allocation problems, the CRR needs to match only a specific CRP. Therefore, the Technique for Order Preference by Similarity to Ideal Solution (TOPSIS), in conjunction with entropy weighting, is utilized to evaluate the most optimal solution among many Pareto solutions. As a method approximating the ideal solution, TOPSIS rapidly identifies the optimal solution by ranking all solutions according to their distance from the positive (negative) ideal solution. Additionally, entropy weighting helps eliminate the arbitrariness of subjectively determined weights. This combination enables an objective and fair determination of the optimal computing allocation from $X^{TI}$. The specific algorithm is detailed in [28].

By executing NSGA-III-KDR in BECS, CRP can set $\psi_{d}$ more reasonably by analyzing the optimal solution. Simultaneously, CRR can select the most appropriate CRP for task offloading based on the optimal solution. Consequently, both parties engaged in resource sharing achieve reliable, dynamic, and secure computing allocation and trading.

In this phase, upon inputting the security parameter $\lambda$, the system administrator selects a secure elliptic curve $\mathcal{E}:y^{2}=x^{3}+ax+b\mod p$. The group $\mathcal{G}$ is an additive elliptic curve group with order $q$ and generator $g$ defined over $\mathcal{E}$, where $p$ and $q$ are two large prime numbers. Subsequently, 6GBS $B_{b}$ chooses a random number $b\in Z_{q}^{*}$ as its private keys and caculates the public keys as $bg$. Additionally, it selects a collision-resistant hash function $\mathcal{H()}:\{0,1\}^{*}\to\{0,1\}^{l}$ and makes $\{\mathcal{E},\mathcal{G},x,p,q,\mathcal{H()}\}$ publicly available in blockchain.

All devices must be registered upon entering the system. $D_{d}$ first selects $d\in Z_{q}^{*}$ as the private key and then calculates the public key as $dg$. Subsequently, it sends its real identity $ID_{d}$ and the public key $dg$ to the nearest $B_{b}$ via a secure channel. After receiving the message from $D_{d}$, $B_{b}$ stores $\mathcal{H}(\mathcal{H}(ID_{d})\parallel dg)$ in SC, while simultaneously generating and sending $D_{d}$’s identity certificate: $Cert_{d}=Sig_{b}(\mathcal{H}(ID_{d})\parallel dg)$.

When $D_{d}$ participates in computing sharing, it must first send its public key $dg$ and identity certificate $Cert_{d}$ to the nearest $B_{b}$. After $B_{b}$ verifies the legitimacy of $D_{d}$’s identity, it generates a pseudonym for $D_{d}$, as detailed in Algorithm 2. Based on the Schnorr protocol [29], $D_{d}$ proves possession of the private key $d$ to $B_{b}$ without revealing it, by utilizing the public parameter $g$ and random numbers. $B_{b}$ verifies the legitimacy of $D_{d}$’s identity by confirming the correctness of $D_{d}$’s proof and response. Utilizing non-interactive zero-knowledge protocol, $D_{d}$ acquires a pseudonym $(x,y)$ for communication from $B_{b}$ while preserving privacy.

The pseudonym $(x,y)=(\gamma g,\gamma dg)$, constructed using $D_{d}$’s public key and random numbers, cannot establish its legitimacy and thus requires $B_{b}$ to issue the corresponding certificate, as shown in Algorithm 3. Using a non-interactive zero-knowledge protocol, $B_{b}$ generates a commitment and a response that include its private key. $D_{d}$ then verifies these to confirm that $B_{b}$, who possesses the private key $b$, generated the certificate. Upon successful verification, $D_{d}$ stores the certificate.

Upon entering the system, CRP synchronizes its computing device information and status within blockchain. CRR sends a computing request, and NSGA-III-KDR is utilized to match the resource-sharing parties. CRP ($D_{2}$) accepts a task offloading request from CRR ($D_{1}$). Initially, both parties must verify the pseudonym and certificate according to Algorithm 4. $D_{1}$ uses transcript $T_{1}$ to prove the authenticity of the pseudonym to $D_{2}$ and uses the certificate $\varpi_{1}$ to prove the legitimacy of the certificate to $D_{2}$. After both verifications succeed, $D_{2}$ confirms $D_{1}$’s identity, and similarly, $D_{1}$ confirms $D_{2}$’s identity. Once confirming their identities, CRR offloads its computing tasks to CRP, which then updates its resource status and delivers the computing results to CRR within the deadline. Following the payment of corresponding fees by CRR, both parties finalize the trading.

After both parties complete the trading in computing sharing, the 6GBS near CRR packages all related information into a new block and adds it to the blockchain. Subsequently, CRP must update its computing resource status. The trading and resource update information of this computing sharing will be broadcast and synchronized throughout the entire blockchain system.

Before re-engaging in computing sharing, CRP and CRR need to request new pseudonyms and certificates from the nearby 6GBS to ensure the user’s identity remains unlinkable. Similarly, the 6GBS verifies the legitimacy of the CRP/CRR identities through Algorithm 4 and then issues CRP/CRR new pseudonyms and certificates.

The system’s security is crucial for the anonymous sharing and trading of computing resources. In BECS, the RCC of 6GBS generates all security parameters, which are then securely synchronized and stored on the permissioned blockchain. Additionally, all 6GBSs maintain the permissioned blockchain, and their security strongly supports the blockchain. Thus, resource status updates, pseudonymous trading, trading records, and block generation within the system are secure. Moreover, as all computing trading are blockchain-recorded, 6GBSs can ensure fairness in computing sharing through audits. Furthermore, user authentication is mandatory for system access, and user identity hashes stored at the 6GBS ensure privacy even if data leaks occur, also safeguarding against whitewashing attacks. Finally, updatable pseudonyms prevent the leakage of users’ public and private keys, ensuring that their information remains unlinked and untraceable, thus securing their privacy. In the proposed service model, privacy entropy is also considered, providing comprehensive protection for user privacy.

The security of the proposed pseudonym scheme is based on the discrete logarithm problem and the Schnorr protocol. During system initialization, the security of key generation depends on the assumption of the discrete logarithm on elliptic curves, and its security is notoriously guaranteed. Additionally, the Schnorr protocol, being simulatable due to its zero-knowledge property [29], ensures that the pseudonym generation is also simulatable, with interacting parties not gaining any information beyond validating the pseudonyms and certificates, so the generation and verification of pseudonyms and certificates is also secure. Moreover, since attackers cannot differentiate between real and simulated interactions, they are unable to acquire any useful information. To analyze security performance from various perspectives, the detailed discussion as follows.

1) Uniqueness: The proposed pseudonym adopts the form $(\gamma g,\gamma dg)$, whereas the user’s public/private key pairs take the form $(d,dg)$. The pseudonym generation can be seen as a knowledge extractor of the Schnorr protocol that produces the private key $d$. Consequently, each user’s pseudonym corresponds to a unique extractable public/private key pairs, ensuring that every authenticated pseudonym uniquely identifies a user.

2) Unforgeability: The user’s pseudonym certificate incorporates the private key of 6GBS, which remain concealed from users due to the zero-knowledge protocol, thereby precluding any possibility of forging the pseudonym certificate. Additionally, user identity verification employs a zero-knowledge protocol based on the 6GBS’s private key. Consequently, without knowing the 6GBS’s private key, users cannot authenticate successfully with a forged pseudonym and certificate.

3) Unlinkability: The mutual verification process between users reveals no information beyond the pseudonym and certificate. The pseudonym is a bit commitment to the user’s private key. Given the robust security of bit commitments, attackers cannot distinguish the identities of different users by observing their pseudonyms. Furthermore, the public keys of both verification parties are not leaked, and no link exists between different pseudonyms of the same user.

4) Traceability: Users request or update their pseudonyms at the 6GBS using their public keys, allowing the 6GBSs to trace all of a user’s pseudonyms and related trading via its public key. As pseudonyms are updated before each computing sharing and remain unlinkable, neither attackers nor other users can trace a user’s pseudonyms or related trading.

The certificate’s security is based on key pairs of the 6GBS. Certificate issuance and verification, conducted through non-interactive zero-knowledge protocols, ensuring the confidentiality of the 6GBS’s key pairs. The private key of the granting 6GBS binds the pseudonym, thereby legitimizing the certificate. Additionally, during certificate issuance, random numbers further improve anonymity, safeguarding against linking of the user’s identity.

In BECS, NSGA-III-KDR uses Non-KDR-dominated sort instead of Non-Dominated Sort from NSGA-III to enhance solution diversity, while maintaining the same computational complexity. Namely, with $L$ optimization objectives and a population size of $X$, NSGA-III-KDR exhibits a computational complexity of $\mathcal{O}(LX^{2})$. Specifically, calculating the kernel distance for each solution and determining the angle between any two solutions each incur a complexity of $\mathcal{O}(L)$. Each solution’s distance to the ideal point is calculated individually, contributing to a complexity of $\mathcal{O}(LX)$. For dominance judgment, each pair of solutions undergoes one angle calculation and comparison, leading to an overall complexity of $\mathcal{O}(LX^{2})$. Thus, the computational complexity of each iteration can be approximated as $\mathcal{O}(LX^{2})$. Furthermore, while maintaining the same complexity, NSGA-III-KDR supports more optimization objectives compared to NSGA-II-based scheme [4], providing a more comprehensive computing allocation strategy. Compared to NSGA-III-based scheme [5], NSGA-III-KDR offers more diverse solutions, improving the probability of superior computing allocation strategies.

In this part, we compare the proposed NSGA-III-KDR with state-of-the-art evolutionary algorithms NSGA-III [4], MOEA/D [5], and NSGA-II-SDR [25], utilizing the PlatEMO platform [32]. The widely used SDTLZ [23], MaF [33], and SMOP [34] test suites are employed as the benchmarks. Meanwhile, IGD [35] and PD [36] are selected as performance evaluation metrics. IGD comprehensively measures the convergence and diversity of the algorithms, where a smaller IGD value indicates better performance. PD primarily reflects the diversity of the algorithms, with a larger PD value indicating greater population diversity. The crossover probability is set to 1, the mutation probability is set to 1/D, and their distribution indicator is set to 20, where D represents the length of the decision variable. All three algorithms are executed 30 times on different test problems, and the average values are taken. The performance of the three algorithms is compared under different numbers of objectives and benchmarks, as shown in Table III, where “$+$”, “$-$”, and “$=$” indicate that the result is significantly better, significantly worse, and statistically similar to that obtained by NSGA-III-KDR, respectively.

It can be concluded from the experimental results that NSGA-III-KDR has the strongest competitiveness, achieving the best IGD and PD numbers of 10 and 15, respectively. This demonstrates that NSGA-III-KDR has better performance compared to the other two algorithms, especially in terms of population diversity, offering a richer set of solutions for computing allocation.

In this part, we compare NSGA-III, MOEA/D, NSGA-II-SDR, and NSGA-III-KDR in optimizing the proposed computing allocation MOOP. We initialize the population with 50% of the computing devices randomly occupied, then perform the optimization using each of the four algorithms separately. We calculate the changes in computing resources between the final and initial populations, while ensuring algorithmic convergence. Due to the uncertainty of the evolutionary process, besides comparing the overall data (represented by a box plot containing five horizontal lines representing the maximum, upper quartile, median, lower quartile, and minimum value from top to bottom) and the optimal data based on TOPSIS (represented by triangles), the average data (represented by squares) are also compared to comprehensively assess the performance of the four algorithms.

The improvement rate (IR) of computing resource utilization under four algorithms is shown in Fig. 8. Overall, except for MOEA/D, the other three algorithms demonstrate positive optimization in computing resource utilization. NSGA-III-KDR shows the most significant overall and average improvements, indicating superior performance and the most substantial enhancement in resource utilization. NSGA-III and NSGA-II-SDR follow, showing notable but lesser improvements. Although MOEA/D achieves the best optimal solution, its overall performance is suboptimal, characterized by some negatively optimized computing allocation strategies. This issue likely stems from MOEA/D’s predefined fixed neighborhood structures, which may restrict its global search capability and lead to local optimality.

As resource utilization improved, Fig. 8 to Fig. 8 illustrate the changes in the other five objectives considered by the computing allocation MOOP. Except for load balancing, improvements in all other objectives are observed with the optimization based on NSGA-III-KDR, attributed to enhanced resource utilization. The superior diversity of NSGA-III-KDR facilitates a more even distribution of computing resources, as particularly evidenced by the significant increase in privacy entropy. Although NSGA-III exhibits similar trends, it is less effective than NSGA-III-KDR. Notably, with NSGA-III-KDR and NSGA-II, increased resource utilization results in higher delays and sharing revenue, while energy consumption decreases as more tasks are offloaded to $\mathbb{U}$, leveraging all available resources within 6G PCN comprehensively. The optimization strategy of NSGA-II-SDR favors offloading tasks to $\mathbb{E}$ and $\mathbb{C}$, significantly reduces delay, but uniquely results in positive growth in load balancing among the four algorithms. The optimal solution of MOEA/D surpasses all other algorithms, achieving the highest resource utilization and substantial improvements in all objectives, except for load balancing, and the decline in load balancing suggests a rational allocation of computing resources. However, the overall data of MOEA/D is the worst, with a negative optimization of 12.99%. Furthermore, although its median or average increase in resource utilization is less than that of NSGA-III-KDR, the more substantial improvement in load balancing suggests a less favorable overall evolution. Since the selection of the optimal solution using TOPSIS is random, not every iteration of MOEA/D yields a solution that outperforms those of other algorithms.

In this part, we evaluate the computational overhead of the proposed pseudonym scheme by comparing it with several existing pseudonymous schemes. Each operation and phase are tested 20 times separately, and the average value is recorded as the experimental data to eliminate the influence of hardware fluctuations during the operation. First, the BN curve [37] with a 128-bit security level is selected to implement the bilinear group. The execution time of basic cryptographic operations are shown in Table IV. Generally, the execution times required for bitwise XOR and modular multiplication are significantly lower compared to other cryptographic operations, and can thus be disregarded. Moreover, we utilize SHA-256 as the hash function. Then, we assess the time costs associated with system initialization and pseudonym generation (SIPG), certificate issuance or message signing(CIMS), and identity or message verification (IDMV) in the pseudonym authentication process, comparing the proposed scheme with those in [38, 39, 40, 41], as shown in Table V.

The proposed scheme, which is based on the Schnorr protocol, primarily involves operations $T_{pm}^{ecc}$, $T_{pa}^{ecc}$, and $T_{ha}$ in the pseudonym authentication process. The total computational overload is $14T_{pm}^{ecc}+4T_{pa}^{ecc}+8T_{ha}=8.664ms$. Conversely, Bagga et al.’s scheme [38] uses $T_{mtp}$ and $T_{bp}$ in the SIPG and IDMV, leading to a higher computational overload. Similarly, Shen et al.’s scheme [39], based on bilinear pairing, also incurs a higher computational overload. Although based on ECC, Yang et al.’s scheme [40] includes 17 times $T_{pm}^{ecc}$ within SIPG, leading to a significant computational overload. Wang et al.’s scheme [41], similar to the proposed scheme, provides the optimal computational overload in both SIPG and IDMV. However, a total of 16 times $T_{pm}^{ecc}$ yields a marginally greater computational overload than ours. Therefore, our scheme achieves the lowest computational overload compared to other related schemes.

Next, considering the diversity of computational devices, we test the portability of the proposed pseudonym scheme. We consider five different devices, including a workstation with an Intel i9-12900k@3.9GHz and 64GB RAM (Intel i9), a computer with an i7-12700@2.1GHz and 32GB RAM (Intel i7), a computer with an i5-8500@3GHz and 8GB RAM (Intel i5), a smartphone with Snapdragon 7+ Gen 2 and 16GB RAM (Snapdragon 7+ Gen 2), and a MacBook with an M1 chip and 16GB RAM (Apple M1). We test the time consumption for each of the five phases of the pseudonym authentication process on these devices: System Initialization (SI), Computing Devices Registration (CR), Pseudonym Generation (PG), Certificate Issuance (CI), and Identity Verification (IV), including the total time consumption (TT) for the entire process, as shown in Fig. 9. Time consumption varies across devices due to differences in CPU performance. Specifically, the MacBook requires the longest total time to complete a pseudonym authentication, only 20.813 ms. The SI is the most time-consuming, as it involves generating system keys and registering user information. However, typically, SI is only performed once, whereas CR, PG, CI, and IV take less than 8 ms across all devices, with PG taking the longest at 7.628 ms on the smartphone. This demonstrates the good portability and lightweight of the proposed pseudonym scheme.