Redactable Blockchain Trust Scheme Based on Reputation Consensus for MEC

Blockchain technology can build trust, reduce costs, and accelerate transactions in the mobile edge computing (MEC) and manage computing resources using the smart contract. However, the immutability of blockchain also poses challenges for the MEC, such as the smart contract with bugs cannot be modified or deleted. We propose a redactable blockchain trust scheme based on reputation consensus and a one-way trapdoor function in response to the problem that data on the blockchain, which is an error or invalid needs to be modified or deleted. The scheme calculates each user's reputation based on their currency age and behavior. The SM2 asymmetric cryptography algorithm is used as the one-way trapdoor function to construct a new Merkle tree structure, which guarantees the legitimacy of the modification or deletion after verification and vote. The simulation experiments show that the modification or deletion does not change the existing blockchain structure and the links of blocks. Furthermore, the consensus verification accurately passes after the modification or deletion operations, which indicates the proposed scheme is feasible.


Introduction
e mobile edge computing (MEC) reduces latency and network load by consolidating computing resources that are close to mobile users in edge networks. However, there are problems in system security and resource management. e security and privacy of MEC have been a concern in recent years, and blockchain can provide the best solution. Blockchain technology is one of the revolutionary emerging technologies in recent years. e immutability of blockchain technology facilitates it to establish a consensus in a trustless environment [1]. Furthermore, blockchain has the advantages of decentralization, detrust, anonymity, and data incorruptibility, and makes the transmission of secret information in the MEC more secure [2]. erefore, it has broad development prospects. e smart contract can realize the decentralized resource management and ensure the security of system data. Using the decentralized characteristics of blockchain to perform task allocation and scheduling in mobile edge computing can effectively eliminate the attack behavior to the central server and ensure the correctness of data transmission.
Blockchain brings benefits to the MEC but also challenges. e immutability ensures the information security of the computing devices on the chain. It also means the wrong or invalid information cannot be modified or deleted and will be permanently stored in the blockchain. e smart contract can facilitate the intelligent management of MEC devices. Still, bugs in the smart contract will lead to irreparable damage, as in the well-known DAO attack. However, illegal information has been maliciously uploaded to the blockchain time and again since the creation of blockchain, providing opportunities for criminals to disrupt the order of the blockchain network for benefit. e current research and application of blockchain emphasize the security of storage and transmission of data on the blockchain, while ignoring the security of data contained on the blockchain from the perspective of information regulation [3]. Data on the blockchain can only be appended, not deleted or modified [4]; the storage burden of the entire blockchain increases due to the increasing amount of data on the blockchain, which cannot be deleted or altered, which is not conducive to maintaining.
e General Data Protection Regulation (GDPR) mandated by the European Union in 2018 sets new standards for collecting, storing, protecting, and using users' data. Companies need to ask for each user's permission before collecting their personal data. e user has the right to be forgotten, and the data controllers must ensure that personal data are accurate and kept up to date. It means that users can withdraw their permission at any time and ask companies to modify or delete their personal data. erefore, the blockchain system applied in this context must provide users with a convenient way to modify or delete. e decentralization of blockchain does not mean that the system data cannot be modified, but the data on the blockchain can be modified with the approval of the majority of the system users, and the modification operation is performed by the system users, which does not violate the concept of decentralization. erefore, the study of redactable blockchain technology under specific conditions is of great research significance.
After Satoshi Nakamoto proposed "Bitcoin: A Peer-to-Peer Electronic Cash System" in 2008 [5], blockchain came into the public eye. As the core technology of blockchain, the consensus mechanism determines blockchain's security, scalability, decentralization, and other essential characteristics [6]. It solves the Byzantine problem so that communication between untrustworthy nodes is possible and makes the distributed data of blockchain consistent. A suitable consensus mechanism improves the performance and efficiency of a blockchain system, provides a robust security guarantee, and supports complex application scenarios [7]. e initial Bitcoin blockchain used the Proof-of-Work (PoW) mechanism, which relies highly on the HashRate of nodes, to ensure the consistency of the distributed data. However, PoW proved to be a severe waste of resources and an inefficient transaction.
e Proof-of-Stake (PoS) consensus created by Peercoin solves the problem of waste of resources of PoW. However, it cannot resist the permanent divergence. It may lead to polarization, widening the gap between rich and poor nodes, and a low level of decentralization is detrimental to currency circulation [8]. Liu proposed a new consensus mechanism based on reputation in 2019 (Proof of Reputation, PoR) [9]. It distributes a reputation value to each node and determines who has the right to create a new block according to the reputation value.
e PoR consensus mechanism does not waste the HashRate or power resources; it has a low computational cost and is more efficient compared with the PoW consensus mechanism. e PoR also does not lead to polarization compared with the PoS consensus mechanism. e reputation value is logarithmically proportional to the amount of currency. e reputation value increases with the increasing amount of currency, but the growth rate decreases. It allows moderately wealthy nodes to create a new block for rewards.
Krawczyk H proposed the chameleon hash function in 2000 [10], which has a trapdoor that can construct a hash collision. e Accenture company applied for a patent of redactable blockchain that having a trapdoor can modify the block data without changing the block's hash value. Still, the scheme is not secure because the trapdoor is controlled by only one party, and the scheme is highly centralized. Li proposed a study of redactable blockchain technology based on chameleon hash functions and verifiable secret sharing in 2018 [11]. Li's scheme solves the problem of high centralization, with N nodes cooperating to perform modification operations. Still, most of the blockchains are mainly based on traditional collision-resistant hash functions, so the application value of Li's scheme is low. Ren proposed a redactable blockchain scheme based on Proof-of-Space consensus and collision-resistant hash functions in 2020 [12], using one-way trapdoor functions to modify the data on the blockchain. e blockchain structure of Proof of Space is different from Proof of Work and Proof of Stake, due to the features of Proof-of-Space consensus, and this scheme [13] is only limited to Proof-of-Space consensus, which has substantial limitations; the modification involves the inverse operation of Q users. e more users there are in the blockchain network, the larger the Q is, and the lower the efficiency is. erefore, the Proof of Reputation has many advantages compared with Proof of Space. First, the Proof of Reputation selects a Leader to create a new block according to user's reputation value, and it does not waste the HashRate resources compared with Proof of Space; second, the efficiency of Proof of Space will decrease with the increasing number of Q users in the network, there are Q inverse operations, and the efficiency of Proof of Reputation will not decrease because there is only one inverse operation.
is paper uses a collision-resistant hash function to implement a redactable blockchain scheme based on the Proof of Reputation consensus mechanism (PoR). We propose a new Merkle tree structure using a one-way trapdoor function. As a result, legitimate modification of invalid or error information could be performed after verification without changing the existing blockchain structure; all users can verify the validity of modified data [14].

One-Way Trapdoor Function.
A one-way trapdoor function contains two features: a one-way function and a trapdoor. e one-way function is irreversible. For a one-way function y � f(x), it is easy to calculate y given x but is computationally infeasible to compute x given y. ere exists a z such that we can easily calculate x � f −1 (y) if we have z and y.
e function y � f(x) is called one-way trapdoor function, and z is called the trapdoor. e character of the one-way function determines its computational complexity, and the character of the trapdoor determines that z will be the key to cracking the one-way function.

PoR Consensus-Based Blockchain.
A new consensus mechanism based on Proof of Reputation (PoR) was proposed in [9]. e PoR consensus mechanism has certain merits in energy-saving and computation efficiency compared with PoW. Furthermore, PoR can avoid the waste of resources caused by PoW and create a secure network atmosphere.
As shown in Figure 1 [9], the block structure of the PoR consensus mechanism has three parts: block header, transaction sub-block, and reputation sub-block. Detailed contents of the three parts are as follows: ( (3) Reputation sub-block: contains the vote information.
As shown in Figure 2, the vote information includes explicitly: the voter's public key, reputation value, opinion of agreement or disagreement, signature, and the block hash. e vote information, stored as a Merkle tree, is used to verify the legitimacy of the created block. e Merkle root links to the reputation Merkle root in the block header.
In the PoR consensus mechanism, the highest reputation node can create a new block. e factors that affect a node's reputation are as follows: currency age R s ; transaction activities with other nodes R a ; and contribution to consensus R c . e currency age is the product of currency amount and time; transactions with other honest nodes and participation in consensus validation voting will increase a node's reputation value, and the reputation values of each participating node will change when each block is published, whether the block is approved or rejected by the network. e following equations computing the constituting components, R s , R a , and R c , of the reputation values are formulated in [9].   Computational Intelligence and Neuroscience In (1), the S i denotes the currency amount of the i th node; the t represents the time length that node i has owned this currency, S i t is the currency age, and α is a conversion factor. e PoR consensus mechanism uses the logarithmic formula to calculate reputation value. e reputation value growth rate decreases as the wealth increases; this reduces the gap between the rich and the poor so that people of moderate wealth also have the opportunity to create new blocks for reward of increasing its reputation value. e j in (2) is the number of transactions related to node i. With the appropriate settings of the weighting factor A k and the scaling factor S(k), nodes would prefer to trade with other high reputation nodes to achieve or maintain their high reputation status. e R c in (3) incentivize nodes to frequently make positive contributions to consensus voting to increase their reputation values. e reputation value R i for each node in the network can be calculated using the following (4) from [9], where β 1 , β 2 , and β 3 are weighting parameters. Readers are referred to [9] for a more detailed description of each of the parameters in following equations: ere is also a positive causal connection between the system currency and the reputation values; the high reputation nodes are likely responsible for the system's security because system security is inseparable from their wealth. e process of creating a new block is as follows.
(1) Select a Leader to create a new block. As shown in Figure 3, an initial reputation ranking block is generated during the system initialization. e highest reputation node of the initial reputation ranking block is selected as the Leader to create blocks 0 and 1. en, reputation ranking blocks 0 and 1 are built according to the blocks 0 and 1 created by the Leader. e highest reputation node of block 0 creates block 2, the highest reputation node of block 1 creates block 3, and so on. After creating a new block, the Leader needs to sign and broadcast it to the network and wait for the other nodes in the network to vote on it.
(2) Votes on the new block. e validation group consists of high reputation nodes, and the sum of their reputation values is over 80% of the system's total reputation values. e nodes in the validation group are usually in the top 20% of the highest reputation nodes. All nodes in the network can verify whether the transactions and signature are legitimate and then vote on it. e Leader needs to collect the voting information and store it in the reputation subblock as a Merkle tree. e block will be uploaded to the blockchain when (i) more than 2/3 of the validation group nodes vote in favor; (ii) the sum of the YES voters' reputation values exceeds ½ of the system total reputation value. e block is rejected in the opposite scenario.
(3) e other nodes in the blockchain network verify the new block. Other nodes verify the newly released block and update their local blockchain data for consistency.

Redactable Blockchain
We propose a redactable blockchain based on the blockchain structure of PoR, using a new Merkle tree and a one-way trapdoor function. e specific transaction in the Request can only be legitimately modified when the nodes who agree to perform the requested modification have more than 1/2 of the whole reputation value in the network, so the  amendment represents the system's will. Furthermore, the blocks' link and other data remain unchanged after the amendment. us, the proposed redactable blockchain prevents illegal or malicious modifications. We first introduce the redactable blockchain structure and then analyze the modification principle and security. Figures 4  and 5, the structure of the redactable block uses a new Merkle tree that incorporates the XOR operation H(tx) on the one-way trapdoor function and the hash function. is operation ensures that the transaction Merkle root, the signature, and the hash value of the block header will remain unchanged after the modification, keeping the links of blocks intact. e difference between the traditional Merkle tree and the new Merkle tree is in the hashing of the leaf nodes.

Structure of Redactable Blockchain. As shown in
In the traditional Merkle tree, the value of each leaf node is the SHA256 hash h(tx) of a transaction tx. e parent node's value is the hash of two hash values, h(tx1) and h(tx2), of the two children nodes, and this hashing process is repeated until the transaction Merkle root is generated. erefore, we can detect any tamper of transactions according to the Merkle root to ensure the transaction data's integrity [15]. If a transaction is tampered with, its hash value and the transaction Merkle root will also change; therefore, the transactions on the blockchain cannot be modified without being detected at the Merkle root.
In the new Merkle tree structure, the value of the leaf node is H(tx), which is the XOR of the hash value h(tx) of the    Computational Intelligence and Neuroscience transaction tx and the one-way trapdoor function g(x) (the calculation process of the other nodes remains unchanged): x is the Leader's exclusive random number, automatically generated when the public and private keys are created and recorded as a common parameter. g(x) is the result of encrypting the random number x with the public key. When the transaction tx is modified to tx new , the block Leader can use its private key to compute a new number Although the transaction is modified, with the calculated number x, the transaction Merkle root, the signature, and the other data in the block header remain unchanged; the block header's hash is also intact, therefore maintaining the links of blocks. us, the new Merkle tree can still achieve the functions of the traditional Merkle tree as follows: (1) Providing a Merkle proof. Light nodes can verify whether a transaction exists by Merkle proof with the help of full nodes, even if only the block header is stored (a full node has all transactions in the network, while a light node only has transactions related to itself ). (2) Verifying whether a transaction has been modified.
Suppose an attacker wants to change a transaction maliciously. Because only the Leader owns the trapdoor, an attacker cannot calculate the number x ′ to ensure the transaction Merkle root is unchanged. So, we can judge whether a transaction is modified according to the different transaction Merkle root.

e Principle of Redactable Blockchain.
In a redactable blockchain, the data on the blockchain can be legitimately modified in the interest of the system if nodes with more than 1/2 of the system total reputation value agree the modification. Furthermore, the modification does not break the links between the blocks. e following section describes how to implement modification operation and ensure it is legal.

Implementing Data Modification
(1) Legitimacy Verification of a Modification Request. When a node has a valid reason to modify a transaction, the node can send a modification Request to the network. All nodes in the network could vote on whether the Request is legitimate. e Request is approved if the sum of the yes voters' reputation values is greater than 1/2 of the system's total reputation value; otherwise, the Request is rejected if the voting result is in the opposite. e modification Request information includes the height of the block to be modified, the serial number of transactions, the reason of redaction, and the set after redaction.
Request � Height, ID, Action, data new .
e requirement of high reputation yes voters' sum of reputation values is more than 1/2 of the system's total reputation values ensures the "legality" of the modification Request, and prevent malicious nodes in the network from destroying the modification operation. Higher reputation nodes are more likely honest nodes, so these nodes are entrusted with more decision-making power.
(2) Process of Implementing Data Modification. e Leader needs to calculate a new number x ′ � g − 1 (h(tx) ⊕ g(x) ⊕ h(tx new )), to guarantee that the Merkle root and the data in the block header remain unchanged after the transaction modification. Hence, the links of the blocks are not affected, and there is no need to adjust the data of the subsequent blocks. Furthermore, all nodes in the network can verify the legitimacy of the data at any time.   (x) e voting record to the Request, rt_set All network nodes can verify the modification's legitimacy according to txorg and update their local blockchain data for the consistency of the chain. Figure 6 illustrates the data modification process. First, the node sends a transaction modification Request. Second, all nodes send in the network vote on the legitimacy of the Request. e Request is considered legitimate if the favorable votes come from nodes whose sum of reputation values is more than 1/2 of the system's total reputation values. en, the Leader executes the legitimate modification Request by calculating a new number x ′ so that the links of blocks are not affected after the modification. Otherwise, reject the modification Request and vastly reduce the reputation value of the node sent the Request.
ird, the Leader issues a transaction for traceability, and the nodes of the whole network verify whether the executed modification is legitimate and update their local blockchain data.

Ensuring the Legality of Modification.
e redactable blockchain does not compromise blockchain security while addressing the limitations of immutability. Because only legal changes voted and verified through by the network's nodes can be performed, the "redactable" blockchain can still ensure the data's security, guaranteed by the characteristics of the one-way trapdoor function and our scheme.
We can only adjust the number x ′ to match the modification of transactions, which guarantees that data and the links of the blocks remain unchanged after the modification. e property of the one-way trapdoor function determines that only the node knowing the trapdoor can find the only number x ′ that can match the transaction change to execute the modification. In this paper, the trapdoor is the Leader's private key, so only the Leader can calculate the new number, and only the Leader can execute the modification authorized by the network.
Specifically, we choose the SM2 asymmetric cryptography algorithm as the one-way trapdoor function. In essence, the Leader encrypts its selected random number x with its public key. According to the one-way trapdoor function properties, all nodes can use the Leader's public key to calculate g(x) given x. However, only the Leader can do the reverse calculation, that is, calculate x given g(x), with the corresponding private key. erefore, the Leader's private key is the trapdoor generated by one-way trapdoor function. Furthermore, the blockchain modification request needs to be approved by the nodes in the network before execution and verified by all other nodes after implementation. erefore, the modification operation represents the will of the system and is legitimate.

Security Analysis of Data Modification.
To illustrate the security of the redactable blockchain scheme, we simulate the attacks of a malicious adversary on modifying block transactions. e adversary can take the following methods: (1) Modify the target block data, modify the data of all blocks on the chain from the targeted block up to the latest block, and keep the links of blocks unchanged (2) Calculate a new number for the modification so that the new Merkel tree root is unchanged after modifying the targeted block data Attack scenario 1 is not feasible because only the block Leader can modify the block. Furthermore, the Leader of each block on the path from the targeted block up to the latest block may be different. e Leaders of each block on the block path are all high reputation nodes. A high reputation node is likely trustworthy because its wealth is closely related to the system's security. According to the principle of maximum wealth, high reputation nodes will not damage the system, negatively affecting their wealth. So, the adversary cannot perform all modification operations from the targeted block up to the latest block. erefore, the adversary's attack is not feasible. e attack scenario 2 is also infeasible because only the Leader knows the trapdoor of the new Merkel tree, so only the Leader can calculate the unique number to keep the Merkel root unchanged after the transaction modification. And the Leader with a high reputation is more likely to be honest because blockchain security is closely related to its wealth. However, suppose the Leader does not faithfully execute the modification request in the network. In that case, the unauthorized modification cannot pass the verification of the other nodes, and the modification operation cannot complete. e Leader's reputation value is also significantly reduced as a consequence. In this way, the attacker cannot obtain benefits but loses his wealth, violating the principle of attack. erefore, the scheme is safe. In conclusion, the redactable blockchain scheme is safe and effective.

Experimental Simulation
Smart contracts can be used for computing devices management in MEC. However, if a smart contract with bugs is released in MEC, and the bugs can cause devices to fail to alert potential warning conditions, it can cause irreparable damage. In this scenario, the proposed redactable blockchain scheme can modify the uploaded buggy smart contract to prevent damage that the buggy smart contract can cause. For easier understanding, the information in the buggy smart contract can be treated as transaction data in the system blockchain to implement the modification. Furthermore, the proposed redactable blockchain also facilitates companies' compliance to GDPR, the EU law on data protection and privacy. For example, in a blockchain-based electronic health record system, the medical institute should ensure that customer's personal data are accurate and up to date, and be able to modify customers' personal data or completely erase a customer's health record at the customers' request. In these scenarios, the customers' health records can be treated as transaction data modified or deleted.

Computational Intelligence and Neuroscience
We simulated the data modification on a blockchain under the PoR consensus mechanism. e experiment uses Python as the language, PyCharm, as the compiler and imports the encrypted package of gmssl.sm2 for the encryption, decryption, and signature operations. Table 1 shows the information of the nodes in the initial system. ere are no transactions and validation votes in the initial system, so the reputation values are only related to the nodes' wealth.

Competition of Bookkeeping Rights.
e system converts the amount of currency into a reputation value using the conversion formula in equation (1), that is, R s (S i , t) � α log(S i t), and generates an initial ranking of reputation value, as shown in Table 2. We set the conversion factor α as 1/2. e initial reputation value is only related to currency amount because no transactions have been generated yet. Figure 7 shows the nodes' reputation values. e consensus mechanism selects the highest reputation node as the Leader to create a new block. en, other nodes in the network vote on the legitimacy of the new block, and all nodes can verify the legitimacy of the new block.

Generation of New Blocks.
e system sets each block to pack four transactions. e initial reputation ranking determines that node 1 is the Leader to create blocks 0 and 1.
e Leader collects four transactions in the transaction pool, packs them into a block, and releases it to the network with a signature. All nodes in the network vote on the legitimacy of the transaction and verify the signature. If passing the validation, the block is uploaded as block 0, and a new reputation ranking table 0 is generated. e highest reputation node in reputation ranking table 0 generates block 2. Similarly, the highest reputation node in reputation ranking Table 1 generates block 3, and so on. Figure 8 shows the detailed structure of blocks 0 and 1.
Let's use block 1 as an example to introduce the computation of the transaction Merkle root.
(1) Block 1 contains four transactions, and node 1 is the Leader of block 1. e one-way trapdoor function g(x) can be calculated using SM2 encryption on the Leader's exclusive random number x using the public key of the Leader (node 1). e g(x) is at least 776 bits in length. We calculate the SHA256(tx) of each transaction first and then pass the value of SHA256(tx) * 3 to the first 768 bits of h(tx), and padding the remaining bits of h(tx) with zero to make h(tx) and g(x) equal in length. en, calculate the hash value H(tx) of each leaf node. (2) After calculating the H(tx i ) of each Merkle tree leaf node i, we compute the hash value of the parent node of two leaf nodes by performing SHA256() hashing of the concatenation of their hash values. ese steps  Merkle root � SHA256(SHA256(H(tx1)‖H(tx2))‖SHA256(Ht(x3)‖H(tx4))).   Computational Intelligence and Neuroscience e value of g(x) is as follows: 8990810412e3d215f0083a5df14ec.
(10) Table 3 shows the hash of transactions. We can calculate the Merkle root according to Figure 9: Merkle root: 3d8430dc65c27e587633600426c43feea1b9eae232063ea11001fcb88ff513ec.
e private key of block Leader (node 1) is as follows: e signature of the block Leader (node 1) to the block header is as follows: Sign: 94532e3d3d8afa58838c4f5c2137fa3c3dc7e4eaf290b1d2595e2ad633e7d13e 7aeae4656ff1d317952245b795cff894316e9bad0714be778569be9225e525e9.  e block Leader (node 1) publishes the packaged block and signature to the network. en, all nodes in the network vote on the legitimacy of the transactions and verify the signature in the block. Next, the block Leader (node 1) collects the vote information and stores it in the reputation sub-block. After the nodes finish the validation and vote in agreement for the block, block 1 is officially uploaded. After block 1 Leader (node 1) uploads block 1, the rest nodes in the network verify the legitimacy of block 1 and update their local blockchain data to achieve the consistency of the distributed data if passing the verification.

Modification of Block Data.
Suppose a blockchain-based health record system needs to update a customer's personal data in compliance with GDPR at the customer's request. Under the EU General Data Protection Regulation (GDPR), Bob as a customer is entitled to demand his personal data be accurate, be up to date, or be deleted. For example, Bob can request that his contact information be updated after he has changed a phone number or moved to a new address. For example, Bob informs his hospital that he has moved home. His hospital is obliged to update Bob's personal information, and the hospital can send an "Address change" Request to the medical blockchain system with Bob's ID. Merkle root: 3d8430dc65c27e587633600426c43feea1b9eae232063ea11001fcb88ff513ec   Request � ′ Height : 0 ′ , ′ I D : 2 ′ , ′ Action: customer changed address, Address : 78 some street, zheng zhou . (14) All nodes (participating hospitals) in the blockchainbased health record system validate whether the modification request is legitimate. If they approve the modification request, the Leader of block 1 performs the modification as shown in Figure 10 to update this customer's personal record. Block 1 Leader (node 1) can calculate a new number x ′ to execute the amendment without affecting the transaction Merkle root and the links of blocks. e new number x ′ � g-1 (h(tx) ⊕ g(x) ⊕ h(txnew)) is calculated, which satisfies (6). e hash of tx2 new is as follows: e value of g(x′) is as follows: 4294fcff534c0ad938659f3b310fb7c960664d08424e53a1ff72ee1d6b59976f2a1b11153d6b3ff6414d43f82876aa5df14ec.
(17) Figure 11 shows the result of the program. We can calculate the result of XOR operation. erefore, the transaction Merkle root is the same after updating this customer's health record. e signature and the hash of the block header will not change if the transaction Merkle root does not change after the modification, so the links of blocks are not affected. After completing the modification, block 1 Leader (node 1) generates a new transaction record called txorg and publishes it to the network, as shown in Figure 12, for legitimacy verification by the rest nodes in the network. e other nodes in the network verify whether the modification is legal according to txorg, and update their local blockchain data if the amendment is legitimate, which completes the modification operation.
After the modification, both the transaction Merkle root and the block header's hash are unchanged; the links of blocks are not affected, so the modification operation is feasible.

Conclusion
A redactable blockchain scheme based on the PoR consensus mechanism is put forward in this paper to address the problem of amending or removing erroneous or sensitive data on blockchains of MEC applications. e proposed Merkel tree structure uses the one-way trapdoor function characteristics, which ensures the Merkle root does not change after modifying a transaction, so the links of blocks are not affected. Although only the block Leader node with the trapdoor can legally perform the modification operation, the modification operation also needs to be validated and agreed upon by the nodes of the whole network to ensure the integrity and security of the blockchain.

Data Availability
Our experimental results are available from the corresponding author upon request.

Conflicts of Interest
e authors declare that they have no conflicts of interest.