Abstract

Translate

With the widespread application of alliance chain technology in diverse scenarios, its immutability has gradually revealed certain limitations in practical use. To address this challenge, a redactable alliance chain innovatively introduces functionalities for data modification, deletion, and updating. However, issues related to redaction permissions, auditing, and security hinder its development. To overcome these challenges, the K-medoids clustering algorithm is first employed to select a redaction center and a consensus committee. The redaction center reviews redaction requests, while the consensus committee groups redaction blocks and reaches block consensus. Next, a dual-hash function scheme is proposed, where a subkey-updatable chameleon hash function collaborates with a standard hash function. The system’s master key can revoke a user’s redaction rights by updating their subkey. Based on this framework, a block redaction strategy comprising four phases and nine execution algorithms is introduced, enabling an auditable, accountable, and subkey-updatable RBAU. Security analysis and experimental results demonstrate that the proposed model excels in correctness, resistance to collision of the original key, resistance to collision of the updated key, user subkey updatability, and master key immutability. Additionally, the algorithm’s execution time, transaction execution time, block size, and redaction time are comparable to those of the pre-improvement alliance chain.

Full text

Turn on search term navigation

Translate

1. Introduction

Since its introduction in 2008, blockchain technology, as a disruptive innovation, has demonstrated immense potential in the field of decentralized data management [1,2]. Blockchain organizes data in a unique “chain-like” structure by segmenting it into blocks and connecting them sequentially [3]. Each block not only records current transaction information but also contains the hash value of the preceding block, ensuring data integrity and tamper resistance [4]. In a decentralized network, all nodes collectively maintain the ledger and rely on consensus algorithms (such as Practical Byzantine Fault Tolerance (PBFT) and Proof of Work (PoW)) to verify and record transactions [5]. This trustless mechanism significantly reduces transaction costs while enhancing system efficiency and security.

With its characteristics of decentralization, immutability, and high transparency, blockchain has become a crucial tool for driving digital transformation [6]. In Blockchain 3.0, the application of alliance chain is continuously expanding. It addresses numerous challenges associated with trust and security in traditional centralized systems and has been widely applied in fields such as fintech, supply chain management, healthcare, elderly care, energy trading, intellectual property protection, and food traceability [7,8,9,10]. By leveraging distributed ledgers and consensus mechanisms, alliance chain ensures data integrity and reliability without the need for third-party intermediaries.

However, as alliance chain evolves rapidly and its application scenarios grow more complex, its core feature of immutability has revealed a series of limitations in practical use, particularly in areas such as data regulation, privacy protection, and dynamic data management.

Firstly, in terms of data regulation, the openness of alliance chain allows users to freely upload data. While this promotes information sharing and transparency, it also introduces potential risks of unverified data. False, malicious, or erroneous data may enter the alliance chain and spread across the network, posing significant threats to public safety or the normal functioning of systems [11]. For instance, in the context of the Internet of Vehicles, inaccurate traffic data could directly endanger driving safety or lead to traffic accidents. Therefore, how to implement the review and removal of inappropriate data on the alliance chain has become a core issue in data management.

Secondly, data privacy protection has emerged as an unavoidable challenge in alliance chain applications. Although alliance chain safeguards the security of data transmission and storage through encryption technologies, its immutability makes it impossible to delete sensitive information stored on the chain, potentially leading to privacy breaches or misuse by malicious actors. Within the framework of personal information protection regulations, such as the General Data Protection Regulation (GDPR), alliance chain systems need to support the deletion of records containing private data to comply with regulatory requirements and enhance user trust [12].

Lastly, regarding data updates, traditional alliance chains lack flexible modification mechanisms, making dynamic management extremely difficult. For example, when a user’s identity is preemptively registered by a malicious attacker or when errors exist in on-chain data, the immutability of traditional alliance chains prevents legitimate users from correcting or updating the relevant information [13]. This limitation significantly reduces the adaptability and efficiency of alliance chain in dynamic, real-world application scenarios.

To this end, redactable blockchain has gradually become a focal point in blockchain technology research and application, providing innovative solutions to address the limitations of flexibility and privacy protection. Redactable blockchain retains the decentralized and highly secure nature of alliance chains while introducing functionalities for data modification, deletion, and updating. By leveraging encryption technologies and optimized consensus mechanisms, it ensures the security and transparency of the data redaction process [14,15]. Compared to traditional alliance chain, redactable alliance chain offers the following advantages:

Enhanced Data Governance: By incorporating mechanisms for reviewing and deleting on-chain data, it prevents the spread of false or illegal information, thereby improving the credibility and security of the system.

Improved Privacy Protection: It allows users to delete or modify on-chain private information under specific conditions, ensuring compliance with relevant laws and regulations while safeguarding user data.

Support for Dynamic Data Updates: Through flexible data redaction functionalities, it enables secure and verified mechanisms for data modification or updates, facilitating dynamic management of on-chain information and effectively overcoming application bottlenecks of traditional alliance chains in data update scenarios.

Operational Flexibility: The ability to update data enhances the adaptability of alliance chain systems to evolving demands, making them more efficient and user-friendly.

Redactable alliance chains allow users to modify, delete, or update on-chain data under specific conditions by a flexible redaction mechanism. The implementation of such technology typically relies on advanced cryptographic tools and multi-party consensus mechanisms, such as chameleon hashes and zero-knowledge proofs, to ensure the security, transparency, and auditability of data redaction. This innovation opens new possibilities for the diverse application of alliance chain technology [16,17].

Redactable alliance chains demonstrate broad application prospects across various fields. It can be used in the IoV to dynamically correct traffic data, ensuring driving safety [18]. It can also be applied in food traceability to eliminate harmful or counterfeit information within the supply chain [19]. Additionally, it can be used in healthcare data management to ensure the effective protection of patient privacy while enabling dynamic updates [20]. However, research on redactable alliance chain also faces numerous challenges, such as how to ensure the allocation and management of redaction rights, how to design an efficient redaction consensus mechanism, and how to achieve privacy protection while maintaining data transparency.

Therefore, this paper implements redactable alliance chains using a dual-hash function and ensures accountability of the redaction process through a hash function that can be updated via sub-keys. In addition, a consensus group partitioning method is employed to establish a multi-center alliance chain, with a redaction center responsible for review. This approach not only addresses the limitations of traditional alliance chains, which cannot redact data, but also effectively improves the redaction efficiency of the alliance chain. The main contributions of this paper are as follows:

The K-medoids clustering algorithm is employed to select the redaction center and consensus committees, and a redaction request verification algorithm is developed. The redaction center utilizes this algorithm to review redaction requests, preventing unreasonable block redaction. Subsequently, the consensus committees can simultaneously perform consensus operations to execute block redaction or block consensus, thereby improving consensus efficiency. Moreover, the consensus committees hold key information, preventing the misuse of redaction rights.

A system master key generation algorithm, a user sub-key generation algorithm, and a key update algorithm are designed. A chameleon hash algorithm with updatable sub-keys is proposed, enabling the system master key to revoke a user’s redaction rights by updating their sub-key. Additionally, a dual-hash function scheme is constructed, wherein standard hash values generated by a conventional hash function are used for redaction transactions, while a chameleon hash function with updatable sub-keys is applied to generate hash values for non-redaction transactions.

A block redaction strategy is designed, which is divided into four phases: initialization, block generation, block redaction, and key update. The execution process of nine algorithms is developed, including the redaction request generation algorithm, collision algorithm, key update algorithm, and others.

2. Related Work

In recent years, redactable blockchain has become an emerging research hotspot. Immutability is regarded as the irreplaceable cornerstone of blockchain technology [21]. However, in practical applications, alliance chain technology has been found to have urgent data redaction needs in areas such as information supervision, privacy protection, data updates, and scalability. To enable the effective redaction of block data, scholars have conducted extensive research. Ateniese et al. [22] proposed the first redactable solution to modify and delete data on the chain. This solution uses the Chameleon hash function, which allows for the determination of valid hash collisions through secret trapdoor information, thereby enabling information redaction. Huang et al. [23] studied a redaction scheme based on time-updatable Chameleon Hash (TUCH) and linkable and redactable ring signature (LRRS) algorithms. This scheme supports anonymous redaction with low modification costs. Pang Jun et al. [24] proposed a redactable blockchain model that reconstructs the underlying structure of the blockchain and adds a temporal-based index to achieve logical blockchain redaction by appending transactions. These schemes, using Chameleon hashes and temporal indexes, achieve effective redaction of block data but overlook the risks of abuse due to the centralization of redaction rights.

To ensure the legality and effectiveness of blockchain redaction, scholars have designed decentralized solutions. Lv Weilang et al. [25] designed a redactable scheme suitable for alliance chain. In this scheme, the trapdoors produced by the Chameleon hash algorithm are managed by multiple nodes, so the solution does not affect the integrity verification of the blockchain and enables multi-party consensus modification of transaction data. Wu et al. [26] addressed the issue of Chameleon Hash functions being vulnerable to quantum attacks by proposing a lattice-based single-trapdoor key-hiding Chameleon Hash function, both with and without lattice trapdoors. In the case without a trapdoor, this solution uses a fully distributed key management mechanism to avoid abuse of redaction rights and implements block redaction using the universal framework of Ateniese et al. [22]. In the case of a trapdoor, the scheme adopts a voting strategy to limit redaction rights. Ma et al. [27] proposed a fine-grained, distributed redactable blockchain. This scheme uses a decentralized policy-based Chameleon Hash (DPCH), where redaction rights are controlled by multiple authoritative agencies, avoiding security issues caused by centralization. Jia et al. [28] proposed an efficient redactable blockchain with traceability in a decentralized environment. This scheme uses a decentralized Chameleon Hash function, requiring that each redaction be approved by multiple blockchain nodes. All block redacts are stored on the block, and the redaction block is encoded into an RSA accumulator [29]. Additionally, the scheme designs a block consistency check protocol based on the RSA accumulator. Li et al. [30] proposed a redactable blockchain model using a non-interactive Chameleon Hash (NITCH), supporting the dynamic distribution of partial trapdoor keys. Users who hold a certain share of the trapdoor keys can obtain valid hash collisions.

To limit malicious user redaction behavior, some scholars have designed accountable or punishable solutions. Tian et al. [31] designed a policy-based Chameleon Hash algorithm with black-box accountability (PCHBA). Black-box accountability allows authoritative agencies to link modified transactions to the responsible party in case of disputes. All users can interact with the black-box and query the modifying party. Jia et al. [32] re-examined the conflict between blockchain immutability and redaction and proposed a fine-grained redactable blockchain with a semi-trusted regulator. This scheme supports content supervision on the blockchain and allows users to manage their own data. Ren Yanli et al. [33] proposed a fair redactable blockchain solution, which allows users to supervise redactors and set corresponding punishment mechanisms for malicious behavior, ensuring the fairness of redaction rights (Table 1).

This paper implements the redaction capability of the alliance chain using dual hash functions, and ensures accountability of the redaction process through a subkey-updatable hash function. Additionally, a consensus group division method is employed to achieve a multi-center redactable alliance chain, with redaction reviews conducted through a redaction center.

3. Redactable Model

3.1. Architecture

This redactable model is composed of user nodes, consensus nodes, the redaction center, and the consensus committee, as shown in Figure 1.

User Node: This entity represents a user of the system, participating in the initiation and verification of various transactions. Transactions initiated by user nodes are primarily categorized into two types: redaction transactions and non-redaction transactions. The redaction transaction requires prior review by the redaction center before being executed by the consensus nodes, rather than being directly processed by the consensus nodes.

Consensus node: This entity acts as the executor of block operations. When a transaction involves block modification, the consensus node performs the corresponding redaction operations. Conversely, the consensus node is responsible for packaging all transactions to generate a new block.

Redaction Center: This entity serves as the reviewer for redaction requests. The Redaction Center is responsible for verifying the validity of redaction requests and assessing the reasonableness of the proposed redaction. Once approved, the Redaction Center generates the corresponding redaction transaction, signs it, and forwards it to the consensus nodes for transaction packaging and block redaction.

Consensus Committee: This entity is composed of all consensus nodes. The Consensus Committee conducts transaction consensus through a consensus algorithm to ensure block consistency across all nodes. In addition, the Consensus Committee maintains the key information of the chameleon hash functions within all blocks, including the system’s master key pair and all users’ subordinate key pairs.

3.2. Model Design

Without loss of generality, we denote sets as uppercase, handwritten, bold letters (e.g., D). The i-th row of W is denoted by Wi, and the element found in the j-th column of i-th row in W is denoted as Wij. To ease reading, we summarize the frequently used notations in Table 2.

3.2.1. Review and Consensus Mechanism

(1). Grouping method of consensus nodes

Definition 1 (Consensus Node).

$V \{v_{1}, v_{2}, \dots, v_{n}\}$ . $V$ is the set of nodes, and $n$ is the number of nodes. $v_{i}$ is the i-th node. Nodes are classified into honest nodes and malicious nodes. Honest nodes maintain the success of the consensus mechanism, while malicious nodes disrupt the consensus mechanism or alter the information within the alliance chain network.

Suppose there be $p$ features for the alliance chain nodes, and let $v_{i} = \{v_{i 1}, v_{i 2}, \dots, v_{i p}\} (i = \{1,2, \dots, n\})$ represent the feature values of the $i$ -th node in the $p$ feature. Then, the feature set $V = \{v_{1}, v_{2}, \dots, v_{n}\}$ for the $n$ nodes can be represented as

(1) $V = [\begin{matrix} v_{1} \\ v_{2} \\ \begin{matrix} ⋮ \\ v_{n} \end{matrix} \end{matrix}] = [\begin{matrix} v_{11} & v_{12} & \begin{matrix} \dots & v_{1 p} \end{matrix} \\ v_{21} & v_{22} & \begin{matrix} \dots & v_{2 p} \end{matrix} \\ \begin{matrix} ⋮ \\ v_{n 1} \end{matrix} & \begin{matrix} ⋮ \\ v_{n 2} \end{matrix} & \begin{matrix} \begin{matrix} \dots \end{matrix} & \begin{matrix} ⋮ \\ v_{n p} \end{matrix} \end{matrix} \end{matrix}]$

Compared to other clustering algorithms, K-medoids offers flexibility in handling arbitrary distance metrics, robustness to outliers, interpretability of medoids, and suitability for mixed or complex data types. These characteristics make it an ideal choice when dealing with the diversity and irregular structure of alliance chain data, ensuring that the resulting clusters reflect meaningful and consistent node groupings while minimizing the impact of noise or outliers. Using the K-medoids algorithm to calculate the similarity between alliance chain redaction nodes, the distance function between two nodes, $v_{i}$ and $v_{n}$ , is represented by Euclidean distance, denoted as

(2) $d (v_{i}, v_{n}) = ‖v_{i} - v_{n}‖ = \sqrt{\sum_{j = 1}^{p} {(v_{i j} - v_{n j})}^{2}}$

The K-medoids algorithm clusters $V$ into $K$ clusters, denoted as $V = {V_{1}, V_{2}, \dots {, V}_{k}}$ . Within each cluster $V_{i}$ , the similarity among nodes $v_{i}$ is high, while their similarity to nodes in other clusters is relatively low. The objective function is calculated in Equation

(3) $M i n (T (c)) = \sum_{i = 1}^{n} \sum_{k = 1}^{K} u_{i k} d (v_{i}, c_{k})$

where,

c_{k}

is the medoid of the k-th cluster, and

u_{i k}

is an indicator variable. For

u_{i k}

value, if

c_{k}

belongs to the k-th cluster, then

u_{i k}

= 1; otherwise,

u_{i k}

= 0.

Definition 2 (Agency).

$A \{A_{1}, A_{2}, \dots, A_{k}\}$ . Each cluster $A_{i}$ consists of nodes with similar characteristics, identified using the K-medoids algorithm. Suppose contains $m$ nodes, then $A_{i}$ can be represented as $A_{i} \{a_{i 1}, a_{i 2}, \dots, a_{i m}\} (1 < m < n - k)$ . Where, $a_{i j}$ denotes the $j$ -th node in the $i$ -th agency.

(2). Methods for Constructing the Redactorial Center and Consensus Committee

Using the Euclidean distance to calculate the similarity between the node $v_{i}$ within a cluster and the center $v_{k}$ of other clusters, the formula for the objective function is

(4) $D (k) = \sum_{i = 1}^{n} \sum_{k = 1}^{K} d (v_{i}, v_{k})$

The institution of $M i n (D (K))$ is referred to as the central institution. In other words, the central institution consists of a collection of nodes with multiple features.

Definition 3 (Redaction Center).

$C \{c_{1}, c_{2}, {\dots, c}_{m}\}$ . $C$ is the central institution of $A$ , meaning $C \in A$ . $c_{i}$ is a node in $A_{i}$ , meaning ${c_{i} \in A}_{i}$ . $C$ possesses the characteristics of any institution $A_{i}$ .

In the consensus process of the alliance chain, the Redaction Center does not have an independent consensus but needs to participate in the consensus of other k-1 institutions. Therefore, the Redaction Center forms a consensus group with the other institutions, consisting of k-1 participants.

Definition 4 (Organization).

$O \{O_{1}, O_{2}, \dots, O_{k - 1}\}$ . Agency $A_{i}$ together with the Redaction Center $C$ , forms the organization $O_{i}$ , that is $O_{i} \{o_{i 1}, o_{i 2}, \dots, o_{i s}\} (1 < s < n - k)$ . Where, $C$ is a member of any group $O_{i}$ and must participate in the consensus of group $O_{i}$ .

There are honest nodes and malicious nodes in the group, with the malicious nodes disrupting the consensus. Additionally, having too many nodes in the group participating in consensus transactions can also increase the consensus time. Therefore, it is necessary to select honest nodes to participate in the consensus, forming a consensus committee.

Definition 5 (Consensus Committee).

$T : \{T_{1}, T_{2}, \dots, T_{k - 1}\}$ . Honest nodes are selected from group $O_{i}$ to form the consensus committee $T_{i}$ , that is $T_{i} : \{t_{i 1}, t_{i 2}, \dots, t_{i s}\} (1 < s < n - k)$ . The consensus committee is responsible for reaching consensus on both non-redaction transactions and block redaction transactions. The consensus algorithm uses the FCBFT consensus mechanism developed by the research team.

Each consensus algorithm of a consensus committee is independent and does not affect others. Therefore, the k-1 group consensus algorithms can proceed simultaneously.

3.2.2. Security Scheme of Double Hash Functions

In alliance blockchains, blocks are typically composed of a block header and a block body. The block body mainly stores transaction information and hash values. The hash functions used in these blocks are collision-resistant. Once the transaction information in a block is altered, the corresponding hash value changes as well, making it difficult to modify the block data. Therefore, this section designs a redactable block structure, as shown in Figure 2.

In the redactable block structure, hash functions are divided into two types: standard hash and subkey-updatable chameleon hash. The subkey-updatable chameleon hash function is an improvement based on the team’s research on the quantum-resistant hash algorithm HIBCH-RS, achieved through the modification of Algorithm 2, Algorithm 3, and Algorithm 8 in the redactable strategy [12]. In the leaf nodes of the block body, there are two methods for generating hash values from transaction information. One method involves transaction information that does not involve block modification, with nodes using the subkey-updatable chameleon hash function for hashing. This is because non-redactable transaction information may be modified by subsequent redaction transactions. In contrast, nodes use the standard hash function for hashing. This is because the information of redaction transactions, as records of block modification, has the characteristic of being immutable. Additionally, in all non-leaf nodes of the block body, the standard hash function is used for hashing.

This block structure allows users with chameleon hash keys to perform redaction operations on block data while ensuring hash consistency of the block. Moreover, the redaction information is stored completely and effectively within the block, ensuring that redaction records are query.

3.2.3. Redactable Strategies

To achieve redaction in blockchain, this paper employs the CHSU instead of the standard hash function. The system first generates a set of public parameters, including public parameters for two foundational chameleon hash functions. Then, the system performs key generation, which includes the system’s master key pair and subkey pairs for individual users. When a blockchain user identifies the need to redact a block, they can initiate a redaction request. Upon receiving the request, the redaction center reviews the legality of the user’s redaction and the rationality of the proposed changes. If the request is approved, the redaction center generates a redaction transaction and sends it to the consensus nodes. The consensus nodes first request the system master key from the consensus committee. They then calculate a hash collision based on the redaction transaction information and update the transaction data in the old block. New verification character combinations and other redaction information are stored as auxiliary data. Finally, the consensus nodes broadcast the redaction results, and other nodes validate these results before performing the corresponding local redaction. The information from the redaction transaction is packaged by the consensus nodes into a newly generated block, serving as a record of the redaction.

Overall, the model’s workflow is divided into four stages: initialization, block generation, block redaction, and key updating, as shown in Figure 3.

(1). Initialization Phase (Algorithms 1–3)

Algorithm 1: Initialization algorithm

{S e t u p}_{C H S U} (λ) \to ({p p}_{C H S U})

The input

λ

is a security parameter, and the output

{p p}_{C H S U}

is a public parameter.The algorithm is constructed based on two fundamental chameleon hash functions,

{C H}_{1}

and

{C H}_{2}

. First, the algorithm runs the initialization algorithms

{S e t u p}_{{C H}_{1}} (λ)

and

{S e t u p}_{{C H}_{2}} (λ)

, respectively, obtaining the public parameters

{p p}_{1}

and

{p p}_{2}

. Then, the algorithm sets the public parameter is

{p p}_{C H S U} = ({p p}_{1} {, p p}_{2})

. Finally, the algorithm output is

{p p}_{C H S U}

Algorithm 2: The master key generation algorithm

{K e y G e n}_{C H S U} ({p p}_{C H S U}) \to ({s k}_{C H S U}, {p k}_{C H S U})

The input

{p p}_{C H S U}

is the public parameter.The algorithm uses the key generation algorithm

{K e y G e n}_{1} ({p p}_{1})

{C H}_{1}

to generate a key pair

({s k}_{1}, {p k}_{1})

. Then, the algorithm sets the system master key pair is

({s k}_{C H S U}, {p k}_{C H S U}) = ({s k}_{1}, {p k}_{1})

. Finally, the algorithm outputs are

({s k}_{C H S U}, {p k}_{C H S U})

Both algorithms are executed only once during the initialization phase. In the output of the system master key pair, the public key ${p k}_{C H S U}$ is publicly accessible to all users. The private key ${s k}_{C H S U}$ , however, is held by the consensus committee and can only be accessed by consensus nodes during block operations.

Algorithm 3: The subkey generation algorithm

{U k e y G e n}_{C H S U} ({p p}_{C H S U}) \to ({s k}_{u i d}, {p k}_{u i d})

The input

{p p}_{C H S U}

is the public parameter.First, the algorithm uses the key generation algorithm

{K e y G e n}_{{C H}_{2}} ({p p}_{2})

{C H}_{2}

to generate a key pair

({s k}_{{C H}_{2}}, {p k}_{{C H}_{2}})

. Then, the algorithm set the user subkey pair is

({s k}_{u i d}, {p k}_{u i d}) = ({s k}_{{C H}_{2}}, {p k}_{{C H}_{2}})

. Finally, the algorithm outputs are

({s k}_{u i d}, {p k}_{u i d})

The subkey generation algorithm is executed once for each user during the initialization phase. In the output subkey pair, the public key ${p k}_{u i d}$ is publicly accessible to all users. In contrast, the private key ${s k}_{u i d}$ is held by the user and is only used as an input during block editing operations.

(2). Block Generation Phase (Algorithms 4 and 5)

Algorithm 4: The hash algorithm

{H a s h}_{C H S U} ({p k}_{C H S U}, {p k}_{u i d}, m) \to (h, r, s t)

The inputs consist of the master public key

{p k}_{C H S U}

, the sub-public key

{p k}_{u i d}

, and the message

m

.First, the algorithm computes a hash value and verification string

(h_{2}, r_{2})

using the hash algorithm

{H a s h}_{{C H}_{2}} ({p k}_{u i d}, m)

of the

{C H}_{2}

. Then, it calculates another hash value and verification string

(h_{1}, r_{1})

using the hash algorithm

{H a s h}_{{C H}_{1}} ({p k}_{C H S U}, h_{2} | | {s t}_{0})

of the

{C H}_{1}

. Where,

h_{2} | | {s t}_{0}

is formed by concatenating the hash value

h_{2}

and the state identifier

{s t}_{0}

, where the state identifier is

{s t}_{0} = {p k}_{u i d}

. The algorithm sets the tuple containing the hash value, verification string, and state identifier is

(h, r, {s t}_{0}) = (h_{1}, (r_{1}, r_{2}, h_{2}), {p k}_{u i d})

. Finally, the algorithm outputs are

(h, r, {s t}_{0})

Whenever a new block is generated in the system, the hash algorithm is executed by consensus nodes. The resulting hash value, verification string, and other related information are publicly accessible.

Algorithm 5: The hash verification algorithm

{V e r i f y}_{C H S U} ({p k}_{C H S U}, h, s t, ({p k}_{u i d}, r, m)) \to b

The inputs consists of the main public key

{p k}_{C H S U}

, hash value

h

, status flag

s t

, subkey public key

{p k}_{u i d}

, verification string combination

r

, and message

m

.First, the algorithm checks if the current

s t

matches

{p k}_{u i d}

. If they do not match, the verification fails, and the algorithm directly sets the verification value

b = 0

and output

b

. Otherwise, the algorithm computes the verification value

b_{2}

using the hash verification algorithm

{V e r i f y}_{{C H}_{2}} ({p k}_{u i d}, (h_{2}, r_{2}, m))

of the

{C H}_{2}

, followed by computing the verification value

b_{1}

using the hash verification algorithm

{V e r i f y}_{{C H}_{1}} ({p k}_{C H S U}, (h_{1}, r_{1}, h_{2} | | s t))

of the

{C H}_{1}

. Finally, the algorithm sets the verification value

b = (b_{1} \cap b_{2})

and output

b

(3). Block Redaction Phase (Algorithms 6–8)

Algorithm 6: The redaction request generation algorithm

{V e r i f y}_{C H S U} ({p k}_{C H S U}, h, s t, ({p k}_{u i d}, r, m)) \to b

The inputs are a message

m

, user key

{s k}_{u i d}

, hash value

h

, checksum combination

r

, status flag

s t

, and new message

m^{'}

.The algorithm sets the redaction request

r e p = ({s k}_{u i d}, (h, r, m, s t), m^{'})

, then outputs

r e p

Algorithm 7: The redaction request verification algorithm

E d i t V e r (r e p) \to (T_{e d i t} o r ⊥)

The input

r e p

is the redaction request.The algorithm is executed by the redaction center. Upon receiving the

r e p

, the algorithm first uses the hash verification algorithm

{V e r i f y}_{C H S U} ({p k}_{C H S U}, h, s t, ({p k}_{u i d}, r, m))

to verify whether the information matches. If it does not match, the algorithm directly output

⊥

. Conversely, if it matches, the algorithm proceeds to review the content of the new message

m^{'}

. If the review is successful, the algorithm sets the redaction transaction

T_{e d i t} = ({s k}_{u i d}, (h, r, m, s t), m^{'}, E_{s})

and outputs

T_{e d i t}

, where the redaction flag

E_{s}

is the signature of the redaction center. Conversely, if the review fails, the algorithm output is

⊥

Algorithm 8: The redaction algorithm

{A d a p t}_{C H S U} (s k, (h, r, m, {p k}_{u i d}), m^{'}) \to r^{'}

The inputs consists of the secret key

s k

, the hash value

h

, the checksum combination

r

, the message

m

, the subkey public key

{p k}_{u i d}

, and the new message

m^{'}

.However, the secret key input

s k

can either be the master key

{s k}_{C H S U}

or the user key

{s k}_{u i d}

. When the user key

{s k}_{u i d}

is provided as input, the algorithm utilizes the collision algorithm

{A d a p t}_{{C H}_{2}} ({s k}_{u i d}, (h_{2}, r_{2}, m), m^{'})

{C H}_{2}

to compute a random value

r_{2}^{'}

. Subsequently, the algorithm sets the verification string combination

r^{'} = (r_{1}, r_{2}^{'}, h_{2})

and outputs

r^{'}

. Conversely, when the master key

{s k}_{C H S U}

is used as input, the algorithm first calculates the hash value and verification string

(h_{2}^{'}, r_{2}^{'})

via the hashing algorithm

{H a s h}_{{C H}_{2}} ({p k}_{u i d}, m^{'})

{C H}_{2}

. The algorithm then employs the collision algorithm

{A d a p t}_{{C H}_{1}} ({s k}_{C H S U}, (h_{1}, r_{1}, h_{2} | | {p k}_{u i d}), h_{2}^{'} | | {p k}_{u i d})

{C H}_{1}

to compute the verification string

r_{1}^{'}

. Finally, it sets the verification string combination

r^{'} = ({r_{1}^{'}, r_{2}^{'}, h}_{2}^{'})

and outputs

r_{1}^{'}

(4). Key Update Phase (Algorithm 9)

Algorithm 9: The key update algorithm

{U p d a t e}_{C H S U} ({s k}_{C H S U}, (h, r, m, {p k}_{u i d}), {s t}_{i}) \to (r^{'}, ({s k}_{u i d}^{'}, {p k}_{u i d}^{'}), {s t}_{i + 1})

The inputs consist of the master key

{s k}_{C H S U}

, hash value

h

, checksum combination

r

, message

m

, user public key

{p k}_{u i d}

, and status flag

{s t}_{i}

, with

h = h_{1}

and

r = ({r_{1}, r_{2}, h}_{2})

.First, the algorithm computes the key pair

({s k}_{2}^{'}, {p k}_{2}^{'})

using the key generation algorithm

{K e y G e n}_{{C H}_{2}} ({p p}_{2})

from

{C H}_{2}

. Then, the algorithm calculates the hash value and checksum

(h_{2}^{'}, r_{2}^{'})

using the hash algorithm

{H a s h}_{{C H}_{2}} ({p k}_{2}^{'}, m)

from

{C H}_{2}

. Next, the algorithm computes the new checksum

r_{1}^{'}

using the collision algorithm

{A d a p t}_{{C H}_{1}} ({s k}_{C H S U}, (h_{1}, r_{1}, h_{2} | | {s t}_{i}), h_{2}^{'} | | {s t}_{i + 1})

from

{C H}_{1}

, where

{s t}_{i + 1} = {p k}_{2}^{'}

. Finally, the algorithm sets the checksum combination

r^{'} = ({r_{1}^{'}, r_{2}^{'}, h}_{2}^{'})

and the new key pair

({s k}_{u i d}^{'}, {p k}_{u i d}^{'}) = ({s k}_{2}^{'}, {p k}_{2}^{'})

, and outputs

(r^{'}, ({s k}_{u i d}^{'}, {p k}_{u i d}^{'}), {s t}_{i + 1})

Note that the key update algorithm does not directly replace the original user key pair with a new one. Instead, the algorithm updates the keys specifically for the hash value $h$ , the verification string $r$ , and the message $m$ . The new private key ${s k}_{u i d}^{'}$ is held by the system, while the user retains the original private key ${s k}_{u i d}$ . Consequently, the user can no longer use ${s k}_{u i d}$ to redact the message.

4. Experiments and Discussion

4.1. Safety Analysis

Explaining the security of RBAU through the following properties and proofs.

Definition (Secure RBAU): If RBAU satisfies correctness, key collision resistance, subkey updatability, and master key non-updatability, it is secure.

Property: If the chameleon hash functions ${C H}_{1}$ and ${C H}_{2}$ are secure, then RBAU is also secure.

Explanation: Since RBAU is constructed from two secure chameleon hash functions ${C H}_{1}$ and ${C H}_{2}$ , their enhanced collision resistance and correctness ensure the security of the RBAU.

Furthermore, the correctness, original key collision resistance, updated key collision resistance, the subkey updatability, and the non-updatability of the master key of RBAU are demonstrated as follows.

4.1.1. Correctness

The correctness requirement in RBAU is that all hash and checksum string combinations correctly generated by ${H a s h}_{C H S U}$ , ${A d a p t}_{C H S U}$ , and ${U p d a t e}_{C H S U}$ must pass the check by ${V e r i f y}_{C H S U}$ . The experiment ${E x p}_{A, C H S U}^{C o r} (λ)$ defines correctness, and the specific process is shown in Figure 4. Formally, if all adversaries $A$ believe $P r [{E x p}_{A, C H S U}^{C o r} (λ) = 1] = 1$ , then RBAU is correct.

In the correctness experiment, variables such as the user’s private key $U s k$ , user’s public key $U p k$ , message hash $h_{m}$ , and state $S t a t e$ can be modified by the oracle $O^{s k A d a p t}$ or $O^{U p d a t e}$ . The adversary $A$ can obtain the $S t a t e$ modified by $O^{U p d a t e}$ . Within polynomial time $p l o y (λ)$ , A can freely make collision queries and update queries by $O^{s k A d a p t}$ or $O^{U p d a t e}$ , respectively. Once all queries are completed, $A$ will set the flag signal $S i g n a l$ to $S t o p$ . Then, ${E x p}_{A, C H S U}^{C o r} (λ)$ will check the validity of $h_{m}$ . If valid, ${E x p}_{A, C H S U}^{C o r} (λ)$ outputs 1; otherwise, it outputs 0.

Clearly, the correctness guarantees of the two underlying Chameleon hashes ensure the correctness of RBAU.

4.1.2. Original Key Collision Resistance

The requirement for the original key’s resistance to collision is that, when the user’s key is $U s k$ and the master key is $M s k$ , an attacker $A$ without any key cannot find any collisions. Experiment ${E x p}_{A, C H S U}^{N s k C R} (λ)$ defines the original key’s collision resistance, with the specific process shown in Figure 5. Formally, if all attackers $A$ believe in $P r [{E x p}_{A, C H S U}^{N s k C R} (λ) = 1] \leq n e g l (λ)$ , then RBAU possess initial key collision resistance, where $n e g l (λ)$ is a negligible probability.

Challenger $A$ holding the public key of $(U p k, M p k)$ can query the oracle $O^{s k A d a p t}$ for collision queries and request different tuples $((h, r, m, s t), m^{'})$ . If $(h, r, m, s t)$ is valid under the public key $(U p k, M p k)$ and state $s t$ , then $A$ will obtain a collision for the hash $h$ corresponding to $U p k$ , meaning $A$ is allowed to generate any hash value $h^{*}$ and ${s t}^{*}$ . After completing all queries, if $A$ can produce a valid collision, ${E x p}_{A, C H S U}^{N s k C R} (λ)$ outputs 1.

If $A$ is an adversary capable of breaking the original key collision resistance of RBAU, then we can construct another adversary $B$ , which can break the enhanced collision resistance of the foundational chameleon hashes ${C H}_{1}$ and ${C H}_{2}$ by $A$ . $B$ receives the public key $M p k$ from challenger $C_{1}$ and the sub-public key $U p k$ from challenger $C_{2}$ as challenge keys, and then sends them to $A$ . $A$ can select $(m, m^{'})$ based on $(U p k, M p k)$ and compute ${H a s h}_{C H S U} (U p k, M p k, m) \to (h, r, s t)$ . Then, $A$ sends $(U p k, (h, r, m, s t), m^{'})$ to $B$ to query the oracle $O^{s k A d a p t}$ .

First, $B$ calculates ${V e r i f y}_{C H S U} (M p k, h, s t, (U p k, r, m))$ . If the result is 0, the call ends. If the result is 1 and $s k$ = $M s k$ , $B$ parses $h$ = $h_{1}$ and $r$ = ( $r_{1}, r_{2}, h_{2})$ , then calculates ${H a s h}_{{C H}_{2}} (U p k, m^{'}) \to (r_{2}^{'}, h_{2}^{'})$ . $B$ sends $((h_{1}, r_{1}, h_{2} | | U p k), h_{2}^{'})$ to $C_{1}$ to query the collision ${A d a p t}_{{C H}_{2}} (M s k, (h_{1}, r_{1}, h_{2} | | U p k), h_{2}^{'} | | U p k) \to r_{1}^{'}$ . After validating the query, $C_{1}$ uses the key $M s k$ to calculate the new collision $r_{1}^{'}$ and returns it to $B$ . Finally, $B$ sends $(r_{1}^{'}, r_{2}^{'}, h_{2}^{'})$ to $A$ . If the result is 1 and $s k$ = $M s k$ , $B$ parses $h$ = $h_{1}$ and $r$ = ( $r_{1}, r_{2}, h_{2}$ ), then $B$ queries ${A d a p t}_{{C H}_{2}} (U s k, (h_{2}, r_{2}, m), m^{'}) \to r_{1}^{''}$ from $C_{2}$ , and finally, $B$ sends $(r_{1}, r_{2}^{'}, h_{2})$ to $A$ .

$A$ returns $(h^{*}, (m^{*}, r^{*}, {s t}^{*}), {(m}^{' *} {, r}^{' *}))$ to $B$ , then $B$ analyzes $r^{*}$ = $(r_{1}^{*}, r_{2}^{*}, h_{2}^{*})$ and $r^{' *}$ = $(r_{1}^{' *}, r_{2}^{' *}, h_{2}^{' *})$ . If the result can be validated through the verification in Figure 4, and $h_{2}^{*}$ = $h_{2}^{' *}$ , $B$ can use it to break $(h^{*}, (m^{*}, r_{2}^{*}), {(m}^{' *}, r_{2}^{' *}))$ and decrypt $C_{2}$ . On the other hand, $h_{2}^{*}$ ≠ $h_{2}^{' *}$ , $B$ can also use $(h^{*}, (h_{2}^{*} | | {s t}^{*}, r_{1}^{*}), (h_{2}^{' *} | | {s t}^{*}, r_{2}^{' *}))$ to break $C_{1}$ . Therefore, the probability that $A$ can break the original key’s collision resistance of RBAU is $p$ = $p_{1} + p_{2}$ , where $p_{1}$ is the probability that $B$ can break the enhanced collision resistance of ${C H}_{1}$ , and $p_{2}$ is the probability that $B$ can break the enhanced collision resistance of ${C H}_{2}$ , both of which can be neglected.

4.1.3. Updated Key Collision Resistance

In RBAU, ${U p d a t e}_{C H S U}$ can update the subkeys involved in the calculation of $(h, r)$ and output the new subkey pair $({s k}_{u i d}^{'}, {p k}_{u i d}^{'})$ . The update key collision resistance requires that, when the subpublic key is ${p k}_{u i d}^{'}$ , the adversary $A$ holding the original subkey ${s k}_{u i d}$ cannot find any collisions. Experiment ${E x p}_{A, C H S U}^{N s k C R} (λ)$ defines the update key collision resistance, and the specific process is shown in Figure 6. Formally, if all adversaries A consider $P r [{E x p}_{A, C H S U}^{N s k C R} (λ) = 1] \leq n e g l (λ)$ , then RBAU has updated key collision resistance.

An adversary $A$ holding the master public key $M p k$ can compute the tuple $(h, r, m, s t)$ using a user’s subkey pair $({s k}_{u i d}, {p k}_{u i d})$ . Then, $A$ can call the oracle $O^{U p d a t e}$ to obtain a new sub-public key ${p k}_{u i d}^{'}$ . Afterward, with the subkey pair $({s k}_{u i d}^{'}, {p k}_{u i d}^{'})$ , $A$ can still call $O^{s k A d a p t}$ to compute a valid collision for $h$ . However, the message $m^{' *}$ cannot be queried. The experiment ${E x p}_{A, C H S U}^{C o r} (λ)$ will maintain the hash state value $s t$ of $h$ . After some time, if $A$ can find a valid collision for $h$ with the new subkey pair $({s k}_{u i d}^{'}, {p k}_{u i d}^{'})$ , then ${E x p}_{A, C H S U}^{C o r} (λ)$ outputs 1.

Opponent $B$ receives public key $M p k$ and sub-public key ${p k}_{u i d}$ as challenge keys from challengers $C_{1}$ and $C_{2}$ , respectively, then sends $M p k$ to $A$ . $A$ selects $(m, m^{'})$ based on $(M p k, {p k}_{u i d})$ and computes ${H a s h}_{C H S U} (M p k, {p k}_{u i d}, m) \to (h, r, s t)$ . Then $A$ sends $({p k}_{u i d}, (h, r, m, s t), m^{'})$ to $B$ , calling the oracle $O^{U p d a t e}$ .

After receiving the tuple $({p k}_{u i d}, (h, r, m, s t))$ , $B$ checks its correctness. If correct, $B$ selects ${p k}_{u i d}^{'}$ as the new sub-public key, parses $h$ = $h_{1}$ and $r$ = ( $r_{1}, r_{2}, h_{2})$ , and then calculates ${H a s h}_{{C H}_{2}} ({p k}_{u i d}^{'}, m) \to (r_{2}^{'}, h_{2}^{'})$ . $B$ sends $((h_{1}, r_{1}, h_{2} | | {p k}_{u i d}), h_{2}^{'} | | {p k}_{u i d}^{'})$ to challenger $C_{1}$ to find a collision. Then, $B$ sets the state of $h$ to ${p k}_{u i d}^{'}$ . After validating the query, challenger $C_{1}$ finds the collision using $M s k$ and returns $r_{1}^{'}$ to $B$ . Finally, $B$ sends $((r_{1}^{'}, r_{2}^{'}, h_{2}^{'}), {p k}_{u i d}^{'})$ to $A$ .

$A$ can select any $m^{''} \in M$ and query $O^{s k A d a p t}$ . $B$ can query $C_{2}$ to get ${A d a p t}_{{C H}_{2}} ({s k}_{u i d}^{'}, (h_{2}^{'}, r_{2}^{'}, m), m^{'}) \to r_{2}^{''}$ to simulate $O^{s k A d a p t}$ . $A$ can query $O^{s k A d a p t}$ multiple times within polynomial time $p l o y (λ)$ . A returns ${(m}^{' *}, r^{' *})$ to $B$ , and $B$ parses $r^{' *}$ = $(r_{1}^{' *}, r_{2}^{' *}, h_{2}^{' *})$ . If the result is validated through the verification in Figure 5, it means ${(h}_{2}^{' *} | | {p k}_{u i d}^{'})$ is the message of $h_{1}$ . If $h_{2}^{' *}$ = $h_{2}^{'}$ , $B$ can use $({(m}^{' *} | | r_{2}^{' *})$ to break $C_{2}$ . Conversely, $B$ can use ${(h}_{2}^{' *} | | {p k}_{u i d}^{'})$ to break $C_{1}$ . Therefore, the possibility that $A$ can break the update key collision resistance of RBAU is $p$ = $p_{1} + p_{2}$ . Similarly, both can be neglected.

4.1.4. The Subkey Updatability

The holder of the master key $M s k$ can limit the collision of a specific hash value $h$ by updating the sub-key pair $({s k}_{u i d}, {p k}_{u i d})$ . The requirement for sub-key updateability is that once the sub-key pair $({s k}_{u i d}, {p k}_{u i d})$ related to the hash value $h$ is updated, its holder will no longer be able to compute any collisions for hash value $h$ . Experiment ${E x p}_{A, C H S U}^{U p d} (λ)$ defines key updatability, and the specific process is shown in Figure 7. Formally, if all adversaries $A$ believe in $P r [{E x p}_{A, C H S U}^{U p d} (λ) = 1] \leq n e g l (λ)$ , RBAU is sub-key updatable. It is worth noting that although the updated user key $({s k}_{u i d}^{'}, {p k}_{u i d}^{'})$ cannot compute a valid collision for $h$ , it can still compute collisions for other hash values.

In the experiment, adversary $A$ holds the public key $M p k$ and selects a user sub-key pair $({s k}_{u i d}, {p k}_{u i d})$ . Then, using ${p k}_{u i d}$ and $M p k$ , they compute the tuple $(h, r, m, s t)$ . $A$ will call the oracle $O^{U p d a t e}$ and obtain a new sub-key pair $({s k}_{u i d}^{'}, {p k}_{u i d}^{'})$ , where $O p k$ represents the original sub-public key ${p k}_{u i d}$ . Experiment ${E x p}_{A, C H S U}^{U p d} (λ)$ will maintain the state st of the hash value $h$ . Then, $A$ uses the new sub-key pair $({s k}_{u i d}^{'}, {p k}_{u i d}^{'})$ and calls the oracle $O^{s k A d a p t}$ to obtain a valid collision for $h$ . The message $m^{' *}$ can be queried. After some time, if $A$ can find a valid collision for the original sub-key pair $({s k}_{u i d}, {p k}_{u i d})$ with respect to $h$ , then ${E x p}_{A, C H S U}^{U p d} (λ)$ outputs 1.

In RBAU, the injective function $f : p k \to s t a t e$ is set as the identity mapping. Therefore, the probability of sub-key updatability being compromised is equivalent to the probability that two key pairs randomly generated from ${U s k G e n}_{C H S U}$ are the same. However, this probability is negligible. Thus, RBAU is sub-key updatable.

4.1.5. The Non-Updatability of the Master Key

The requirement for the non-updatability of the master key is that an adversary $A$ , who does not have the master key $M s k$ , cannot update the user key pair sp. It is formally defined by experiment ${E x p}_{A, C H S U}^{M s k R R} (λ)$ , as shown in Figure 8. Formally, if all adversaries $A$ believe in $P r [{E x p}_{A, C H S U}^{M s k R R} (λ) = 1] \leq n e g l (λ)$ , then RBAU has master key non-updatability.

In the experiment, an adversary $A$ holding the public key $M p k$ can query the oracle $O^{U p d a t e}$ . $A$ can select a user key pair $(s k, p k)$ and compute a tuple $(h, r, m, s t)$ . Then, $A$ selects a new message $m^{'}$ and queries the oracle $O^{U p d a t e}$ for $(p k, (h, r, m, s t))$ . $O^{U p d a t e}$ returns a new verification string $r^{'}$ , a new user public key ${p k}^{'}$ , and a new state ${s t}^{'}$ to $A$ . $A$ can repeat the above process with different inputs within polynomial time $p l o y (λ)$ . ${E x p}_{A, C H S U}^{M s k R R} (λ)$ does not require the maintenance of state, as it allows $A$ to generate arbitrary hash values $h^{*}$ as well as two state values ${s t}^{*}$ and $s t^{' *}$ . After the query, if $A$ can perform a new update related to the selected tuple $(h^{*}, m^{*}, r^{*}, {p k}^{*}, {s t}^{*})$ , ${E x p}_{A, C H S U}^{M s k R R} (λ)$ outputs 1.

Adversary $B$ receives $M p k$ as the challenge key from challenger $C_{1}$ and sends it to $A$ . $A$ can select $({s k}_{u i d}, {p k}_{u i d})$ and $m$ based on $M p k$ and compute ${H a s h}_{C H S U} (M p k, {p k}_{u i d}, m) \to (h, r, s t)$ , then send $({p k}_{u i d}, (h, r, m, s t), m^{'})$ to $B$ for querying the oracle $O^{U p d a t e}$ . After receiving $({p k}_{u i d}, (h, r, m, s t))$ , $B$ checks its correctness. If correct, $B$ first parses $h$ = $h_{1}$ and $r$ = ( $r_{1}, r_{2}, h_{2})$ . Then, $B$ randomly selects a new sub-key pair $({s k}_{u i d}^{'}, {p k}_{u i d}^{'})$ and computes ${H a s h}_{{C H}_{2}} ({p k}_{u i d}^{'}, m) \to (r_{2}^{'}, h_{2}^{'})$ . $B$ sends $((h_{1}, r_{1}, h_{2} | | {p k}_{u i d}), h_{2}^{'} | | {p k}_{u i d}^{'})$ to challenger $C_{1}$ to find a collision. After validating the query, challenger $C_{1}$ will use $M s k$ to find the collision and return $r_{1}^{'}$ to $B$ . Finally, $B$ sends $((r_{1}^{'}, r_{2}^{'}, h_{2}^{'}), {p k}_{u i d}^{'})$ back to $A$ .

A returns $(h^{*}, {({p k}_{u i d}^{*}, m}^{*}, r^{*}, {s t}^{*}), {({p k}_{u i d}^{' *}, m}^{*}, r^{' *}, {s t}^{' *}))$ to $B$ . $B$ parses $r^{*}$ = $(r_{1}^{*}, r_{2}^{*}, h_{2}^{*})$ and $r^{' *}$ = $(r_{1}^{' *}, r_{2}^{' *}, h_{2}^{' *})$ . If the result can be validated through Figure 7, $B$ can use hh to break $C_{1}$ . Therefore, the possibility that $A$ can break RBAU’s master key non-updatability is equal to the possibility that B can break the enhanced collision resistance of ${C H}_{1}$ , which can be considered negligible.

4.2. Experimental Results and Analysis

4.2.1. Experimental Environment

This experiment implements the Chameleon Hash algorithm based on Java 17.0.3 and uses the Type A prime-order elliptic curve from the JPBC 2.0.0 library to perform related bilinear pairings. The default public key length for the algorithm is 1024 bits, and the default private key length is 80 bits. To build a simulation environment for the FISCO BCOS alliance chain, this experiment installs several basic tools on an Ubuntu system, including OpenSSL, cURL, Git, Java, Solidity, and build_chain.sh. Among these, OpenSSL and cURL are dependencies for automated scripts when deploying nodes. Git is used as a version control tool for code development and testing. Java is used to call interfaces and serves as a tool for operations on the alliance chain. Solidity is used to implement specific business logic and develop smart contracts. build_chain.sh is a script tool for quickly setting up the blockchain. The device information for this experiment is shown in Table 3.

4.2.2. Function Comparison

We compared our method with the literature [24,25,31,32,33] in terms of features such as technology, redaction type, decentralization degree, redaction review, personal data management, accountability, and key updatability, as shown in Table 4.

Clearly, this method is more comprehensive in its functionality. It supports redaction review, personal data management and redaction accountability. Moreover, it implements physical redaction and is multi-center. Additionally, it can revoke the redaction rights of malicious users through the update of sub-keys.

4.2.3. Algorithm Performance

To test the performance of this method, simulation experiments were conducted to evaluate the overhead of the sub-algorithms, and the results are shown in Figure 9. In the initialization phase, the execution time of the initialization algorithm (Setup) is negligible, while the execution time of the key generation algorithm (KeyGen) is 13 ms. In the block generation phase, the execution times of the hash generation algorithm (Hash) and the hash verification algorithm (Verify) are 45 ms each. In the block redaction phase, the execution time of the redaction request generation algorithm (RedactReq) is negligible, while the overhead of the redaction request verification algorithm (Redaction Ver) and the redaction algorithm (Adapt) is 55 ms and 23 ms, respectively. In the key update phase, the execution time of the key update algorithm (Update) is 59 ms. Note that the bit lengths of the system key pair and the user key pair are the same, and their generation overhead is roughly the same. In the figure, “Keygen” represents the generation overhead for both. Additionally, the time overhead of the redaction request verification algorithm is unstable and depends on the content of the redaction.

Clearly, the execution time of the Update algorithm is the longest. This is because its computation includes the full operations of the Keygen and Adapt algorithms, as well as part of the Hash algorithm. However, the Update algorithm is only executed when a malicious user is revoked from redaction a specific hash. Therefore, the actual execution frequency of the Update algorithm will be much lower than that of the other sub-algorithms. In conclusion, the execution times of the sub-algorithms in RBAU are acceptable.

The key length is a critical factor determining the security of the Chameleon Hash function. However, increasing the key length also increases the computational overhead and results in longer execution times. To balance algorithm efficiency and security, we tested the performance of each subalgorithm at key lengths of 80 bits, 160 bits, and 256 bits, with the results shown in Figure 9.

From Figure 10, it is evident that the execution time of each subalgorithm exhibits a linear relationship with the key length. Compared to the other two key lengths, the execution time is the longest when the key length is 256 bits. Specifically, the execution time of the Hash algorithm is approximately 137 ms, the Verify algorithm takes around 136 ms, and the Update algorithm has the longest execution time, about 177 ms. At the three key lengths tested, the execution times of the RBAU subalgorithms are all under 200 ms, which can generally meet the needs of food traceability scenarios.

4.2.4. Model Performance

To test the performance of the RBAU, the experiment compared it with the FISCO BCOS, which are networks that were set up. In both cases, the number of nodes was set to 100, with a consensus committee of five nodes.

(1). Execution Time of the Transaction

The experiment tested the execution time of transactions on two blockchains, with the results shown in Figure 11. It can be observed from (a) that the execution time for the RBAU is slightly longer than that of FISCO. As shown in (b), when there are two transactions, the time difference between the two blockchains is smallest, about 0.04 s. However, when there are 18 transactions, the time difference is largest, around 0.08 s. The difference in execution time is mainly due to the RBAU using the Chameleon hash function instead of the standard hash function. The Chameleon hash function is more complex to compute, leading to a longer execution time. However, the time difference does not increase further as the number of transactions increases, remaining stable between 0.04 and 0.08 s. As shown in (c,d), the rate of change in execution time relative to transaction volume is concentrated between 0.04 and 0.05 s, with RBAU showing a more stable performance than FISCO.

(2). Block Size of Transactions

The block size is one of the main indicators of the performance of alliance chains. To investigate this, an experiment was conducted comparing the block sizes of two blockchains with an equal number of transactions, as shown in Figure 12. It can be observed from (a) that the block size of both chains has a linear relationship with the number of transactions contained in the block. When the block contains 100 transactions, the RBAU has a block size of 102.4 KB, while FISCO’s block size is 81.9 KB. Clearly, the block size of the RBAU is slightly larger than that of FISCO. This difference is mainly due to the additional fields, such as extra data, added to the block structure in the RBAU. These fields increase the storage space required for each block. However, adding these extra elements is necessary to ensure that all redactions are recorded and can be held accountable. Moreover, as shown in (b), when each block contains 100 transactions, the block size difference between the two chains is only 20.48 KB.

(3). Execution Time of Redaction

The execution time of redaction transactions and ordinary transactions in the RBAU was tested, and the results are shown in Figure 13. It can be observed from (a) that the execution time of redaction transactions is significantly longer than that of ordinary transactions. The execution time for two redaction transactions is approximately 0.41 s, while that for two ordinary transactions is about 0.22 s. As shown in (b), the average execution time difference per transaction between the two types is around 0.095 s at this stage. When each type of transaction is executed 20 times, the average execution time difference per transaction is approximately 0.026 s. Evidently, as the number of transactions increases, the execution time gap per transaction does not expand but rather decreases further. As shown in (c,d), the variation rate of redaction transaction time with transaction volume falls within the range of 0.03–0.09 s, and the stability of the variation rate for both types of transactions remains relatively consistent.

In summary, RBAU is comparable to FISCO in terms of transaction execution time, block size, and redaction execution time, with both demonstrating similar performance.

5. Conclusions

The alliance chain, with its characteristics of decentralization, immutability, and high transparency, has become a crucial supporting technology for driving digital transformation. However, as the application scenarios of alliance chain technology become increasingly complex, its core feature of immutability has gradually revealed limitations in practical use. To address this issue, RBAU introduces functionalities for data modification, deletion, and updating while maintaining the decentralization and high security of alliance chain technology. This provides an innovative solution to the shortcomings of flexibility and privacy protection in alliance chains. Therefore, this paper conducts an in-depth study on alliance chain redaction review and consensus mechanisms, hash function security schemes, and redaction strategies, proposing new methods for redactable blockchains.

A redaction review and consensus mechanism for alliance chain is proposed. The K-medoids clustering algorithm is used to select the redaction center and multiple consensus committees. The redaction center utilizes a redaction request verification algorithm to conduct redaction reviews, while the consensus committees are grouped to perform block redaction and block consensus.

A chameleon hash algorithm with updatable subkeys is proposed. The system master key enables the revocation of a user’s redaction rights by updating their subkey. Based on this, a dual-hash function scheme is implemented, enabling the chameleon hash function to work in coordination with standard hash functions.

A redaction strategy is proposed to realize an RBAU model that supports redaction review, redaction accountability, personal data management, and subkey updates. Security analysis demonstrates the model’s security, and experimental results indicate that the performance of the RBAU is comparable to that of the FISCO alliance chain.

This model is capable of meeting the current demands of the alliance chain scenario, but as the number of nodes continues to grow on a large scale, the redaction efficiency will decrease. In the future, we will introduce reinforcement learning to optimize the consensus mechanism of the alliance chain. By adjusting the consensus participation weights and reward mechanisms based on the nodes’ response times, contributions, and other performance metrics, we aim to further improve redaction efficiency.

Author Contributions

Conceptualization, T.G. and Y.C.; methodology, Y.C.; software, Y.C., X.C. and Q.R.; validation, T.G., Y.C. and X.Y.; formal analysis, T.G. and F.Z.; investigation, T.G. and F.Z.; resources, Y.C. and S.L.; data curation, T.G. and Y.C.; writing—original draft preparation, Y.C.; writing—review and editing, T.G. and F.Z.; visualization, T.G. and X.C.; supervision, Y.C.; project administration, T.G.; funding acquisition, Y.C. and S.L. All authors have read and agreed to the published version of the manuscript.

Data Availability Statement

Data are contained within the article.

Acknowledgments

This working was supported by “The provincial-level application-oriented characteristic discipline of Business Administration at Hunan Women’s University”, “The provincial-level application-oriented characteristic discipline of Sociology at Hunan Women’s University”.

Conflicts of Interest

The authors declare no conflicts of interest.

Footnotes

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Figures and Tables

Figure 1 Model architecture of redactable blockchain.

Figure 2 Redactable block structure. H is a standard hash function, CH is a chameleon hash function that is updatable by subkeys.

Figure 3 Model’s workflow.

Figure 4 The experiment for correctness.

Figure 5 The experiment for original key collision resistance.

Figure 6 The experiment for updated key collision resistance.

Figure 7 The experiment for subkey updatability.

Figure 8 The experiment for the non-updatability of the master key.

Figure 9 Sub-algorithm execution time.

Figure 10 Sub-algorithm execution time under different key lengths.

Figure 11 Blockchain transaction execution time. (a) Time overhead, (b) the differences in time overhead, (c) rate of change, (d) the range of the rate of change.

Figure 12 Block size of transactions. (a) Block size, (b) the difference between the blocks.

Figure 13 Execution time of redaction. (a) Time overhead, (b) the differences in time overhead, (c) rate of change, (d) the range of the rate of change.

Table 1

Comparison of literature.

Literature	Redaction Function	Redaction Mode	Degree of Decentralization	Redaction Review
[22]	Chameleon hash	Physics	Centralization	Uncensorable
[23]	Chameleon hash	Physics	Centralization	Uncensorable
[24]	Timing indexChameleon hash	Logic	Centralization	Uncensorable
[25]	Chameleon hash	Physics	Multicenter	Uncensorable
[26]	Chameleon hash	Physics	Semi-decentralized	Uncensorable
[27]	Chameleon hash	Physics	Semi-decentralized	Uncensorable
[28]	Chameleon hash	Physics	Semi-decentralized	Uncensorable
[30]	Chameleon hash	Physics	Semi-decentralized	Uncensorable
[31]	Chameleon hash	Physics	Semi-decentralized	Uncensorable
[32]	Chameleon hash	Physics	Semi-decentralized	Review
[33]	Chameleon hash	Physics	Semi-decentralized	Review

Table 2

Summary of the main symbols.

Notation	Definition	Notation	Definition	Notation	Definition
$v_{i}$	node	$h_{i}$	Hash value	${D P K}_{i}$	Data public key
$V_{i}$	cluster	${p p}_{i}$	Common parameter	$m$	message
$A_{i}$	Agency	${s k}_{i}$	Private key	$r_{i}$	Check string
$C_{i}$	Redaction Center	${M S K}_{i}$	System private key	${s t}_{i}$	Status flag
$O_{i}$	Organization	${D S K}_{i}$	Data private key	$b_{i}$	Test value
$T_{i}$	Consensus Committee	${p k}_{i}$	Public key	$r e p$	Redact request
${C H}_{i}$	Chameleon hash algorithmd	${P K}_{i}$	System public key

Table 3

Environment of the experiment platform.

Configuration	Server	Computer
Memory	128 G	32 G
CPU	Intel Xeon Silver 4210(2) (Intel, Santa Clara, CA, USA)	i7-12700
Graphics card	RTX4090	RTX3070
Hard disk	6TSSD	1TSSD + 1THDD
OS	Ubuntu20.04/Win10	Ubuntu20.04
Bandwidth	300 M	300 M

Table 4

Comparison with advanced models.

Models	Blockchain-Based	Redaction Function	Redaction Mode	Degree of Decentralization	Redaction Review	Personal Data Management	Account-Ability	Key Update
Literature24	Alliance chain	Timing index	Logic	Multicenter	N	N	Y	N
Literature25	Alliance chain	Chameleon hash	Physics	Multicenter	N	N	Y	N
Literature31	Public chain	Chameleon hash	Physics	Semi-decentralized	N	N	Y	N
Literature32	Public chain	Chameleon hash	Physics	Semi-decentralized	Y	Y	Y	Y
Literature33	Public chain	Chameleon hash	Physics	Semi-decentralized	Y	N	Y	Y
Ours	Alliance chain	Chameleon hash	Physics	Multicenter	Y	Y	Y	Y

References

1. Kouhizadeh, M.; Saberi, S.; Sarkis, J. Blockchain technology and the sustainable supply chain: Theoretically exploring adoption barriers. Int. J. Prod. Econ.; 2021; 231, 107831. [DOI: https://dx.doi.org/10.1016/j.ijpe.2020.107831]

2. Sanka, A.I.; Cheung, R.C.C. A systematic review of blockchain scalability: Issues, solutions, analysis and future research. J. Netw. Comput. Appl.; 2021; 195, 103232. [DOI: https://dx.doi.org/10.1016/j.jnca.2021.103232]

3. Jiang, Y.; Xu, X.L.; Gao, H.H.; Rajab, A.D.; Xiao, F.; Wang, X.H. LBlockchainE: A Lightweight Blockchain for Edge IoT-Enabled Maritime Transportation Systems. IEEE Trans. Intell. Transp. Syst.; 2023; 24, pp. 2307-2321. [DOI: https://dx.doi.org/10.1109/TITS.2022.3157447]

4. Andola, N.; Raghav,; Yadav, V.K.; Venkatesan, S.; Verma, S. Anonymity on blockchain based e-cash protocols-A survey. Comput. Sci. Rev.; 2021; 40, 100394. [DOI: https://dx.doi.org/10.1016/j.cosrev.2021.100394]

5. Zhou, S.S.; Li, K.C.; Xiao, L.J.; Cai, J.H.; Liang, W.; Castiglione, A. A Systematic Review of Consensus Mechanisms in Blockchain. Mathematics; 2023; 11, 2248. [DOI: https://dx.doi.org/10.3390/math11102248]

6. Zhang, T.; Huang, Z.G. Blockchain and central bank digital currency. Ict Express; 2022; 8, pp. 264-270. [DOI: https://dx.doi.org/10.1016/j.icte.2021.09.014]

7. Chinnasamy, P.; Babu, G.C.; Ayyasamy, R.K.; Amutha, S.; Sinha, K.; Balaram, A. Blockchain 6G-Based Wireless Network Security Management with Optimization Using Machine Learning Techniques. Sensors; 2024; 24, 6143. [DOI: https://dx.doi.org/10.3390/s24186143]

8. Soltanisehat, L.; Alizadeh, R.; Hao, H.J.; Choo, K.K.R. Technical, Temporal, and Spatial Research Challenges and Opportunities in Blockchain-Based Healthcare: A Systematic Literature Review. IEEE Trans. Eng. Manag.; 2023; 70, pp. 353-368. [DOI: https://dx.doi.org/10.1109/TEM.2020.3013507]

9. Chinnasamy, P.; Ayyasamy, R.K.; Tiwari, V.; Dhanasekaran, S.; Santhosh Kumar, B.; Sivaprakasam, T. Blockchain Enabled Privacy-Preserved Supply-Chain Management for Tracing the Food Goods. Proceedings of the 2024 International Conference on Science Technology Engineering and Management (ICSTEM); Coimbatore, India, 26–27 April 2024.

10. Cao, B.; Wang, Z.X.; Zhang, L.; Feng, D.Q.; Peng, M.G.; Zhang, L.; Han, Z. Blockchain Systems, Technologies, and Applications: A Methodology Perspective. IEEE Commun. Surv. Tutor.; 2023; 25, pp. 353-385. [DOI: https://dx.doi.org/10.1109/COMST.2022.3204702]

11. Ressi, D.; Romanello, R.; Piazza, C.; Rossi, S. AI-enhanced blockchain technology: A review of advancements and opportunities. J. Netw. Comput. Appl.; 2024; 225, 103858. [DOI: https://dx.doi.org/10.1016/j.jnca.2024.103858]

12. Wang, X.Y.; Chen, Y.N.; Zhu, X.H.; Li, C.; Fang, K. A Redactable Blockchain Scheme Supporting Quantum-Resistance and Trapdoor Updates. Appl. Sci.; 2024; 14, 832. [DOI: https://dx.doi.org/10.3390/app14020832]

13. Hu, J.W.; Huang, K.Q.; Bian, G.Q.; Cui, Y.P. Redact4Trace: A solution for auditing the data and tracing the users in the redactable blockchain. Comput. Netw.; 2024; 245, 110360. [DOI: https://dx.doi.org/10.1016/j.comnet.2024.110360]

14. Sun, J.X.; Zhao, R.; Yin, H.R.; Cai, W. Incentive Mechanism for Redactable Blockchain Governance: An Evolutionary Game Approach. IEEE Trans. Comput. Soc. Syst.; 2024; 11, pp. 6953-6965. [DOI: https://dx.doi.org/10.1109/TCSS.2024.3398044]

15. Huang, K.; Zhang, X.S.; Mu, Y.; Rezaeibagha, F.; Du, X.J.; Guizani, N. Achieving Intelligent Trust-Layer for Internet-of-Things via Self-Redactable Blockchain. IEEE Trans. Ind. Inform.; 2020; 16, pp. 2677-2686. [DOI: https://dx.doi.org/10.1109/TII.2019.2943331]

16. Ye, T.; Luo, M.; Yang, Y.; Choo, K.K.R.; He, D.B. A Survey on Redactable Blockchain: Challenges and Opportunities. IEEE Trans. Netw. Sci. Eng.; 2023; 10, pp. 1669-1683. [DOI: https://dx.doi.org/10.1109/TNSE.2022.3233448]

17. Wei, J.N.; Zhu, Q.H.; Li, Q.M.; Nie, L.S.; Shen, Z.Y.; Choo, K.K.R.; Yu, K.P. A Redactable Blockchain Framework for Secure Federated Learning in Industrial Internet of Things. IEEE Internet Things J.; 2022; 9, pp. 17901-17911. [DOI: https://dx.doi.org/10.1109/JIOT.2022.3162499]

18. Yang, Y.X.; Chen, Y.L.; Liu, Z.Q.; Tan, C.Y. Verifiable and Redactable Blockchain for Internet of Vehicles Data Sharing. IEEE Internet Things J.; 2025; 12, pp. 4249-4261. [DOI: https://dx.doi.org/10.1109/JIOT.2024.3483809]

19. Yang, S.X.; Li, S.W.; Chen, W.J.; Zhao, Y.W. A Redactable Blockchain-Based Data Management Scheme for Agricultural Product Traceability. Sensors; 2024; 24, 1667. [DOI: https://dx.doi.org/10.3390/s24051667]

20. Zhang, T.S.; Zhang, L.Y.; Wu, Q.; Mu, Y.; Rezaeibagha, F. Redactable Blockchain-Enabled Hierarchical Access Control Framework for Data Sharing in Electronic Medical Records. IEEE Syst. J.; 2023; 17, pp. 1962-1973. [DOI: https://dx.doi.org/10.1109/JSYST.2022.3186145]

21. Yuan, Y.; Wang, F.Y. Editable Blockchain: Models, Techniques and Methods. Acta Autom. Sin.; 2020; 46, pp. 831-846.

22. Ateniese, G.; Magri, B.; Venturi, D. Redactable blockchain–or–rewriting history in bitcoin and friends. Proceedings of the 2017 IEEE European Symposium on Security and Privacy (EuroS&P); Paris, France, 26–28 April 2017; IEEE: Piscataway, NJ, USA, 2017; pp. 111-126.

23. Huang, K.; Zhang, X.; Mu, Y.; Rezaeibagha, F.; Du, X. Scalable and redactable blockchain with update and anonymity. Inf. Sci.; 2021; 546, pp. 25-41. [DOI: https://dx.doi.org/10.1016/j.ins.2020.07.016]

24. Peng, J.; Liu, C.; Hao, K.; Yu, M.H.; Xing, J.C.; Jiang, C.Y. Research on Editable Blockchain Model Based on Temporal Index. J. Front. Comput. Sci. Technol.; 2023; 17, pp. 1180-1188.

25. Lv, W.L.; Wei, S.J.; Yu, M.H.; Li, S.S. Research on Verifiable Blockchain Ledger Redaction Method for Trusted Consortium. Chin. J. Comput.; 2021; 44, pp. 2016-2032.

26. Wu, C.; Ke, L.; Du, Y. Quantum resistant key-exposure free chameleon hash and applications in redactable blockchain. Inf. Sci.; 2021; 548, pp. 438-449. [DOI: https://dx.doi.org/10.1016/j.ins.2020.10.008]

27. Ma, J.; Xu, S.; Ning, J. Redactable blockchain in decentralized setting. IEEE Trans. Inf. Forensics Secur.; 2022; 17, pp. 1227-1242. [DOI: https://dx.doi.org/10.1109/TIFS.2022.3156808]

28. Jia, M.; Chen, J.; He, K. Redactable Blockchain From Decentralized Chameleon Hash Functions. IEEE Trans. Inf. Forensics Secur.; 2022; 17, pp. 2771-2783. [DOI: https://dx.doi.org/10.1109/TIFS.2022.3192716]

29. Rivest, R.L.; Shamir, A.; Adleman, L. A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM; 1978; 21, pp. 120-126. [DOI: https://dx.doi.org/10.1145/359340.359342]

30. Li, J.; Ma, H.; Wang, J. Wolverine: A Scalable and Transaction-Consistent Redactable Permissionless Blockchain. IEEE Trans. Inf. Forensics Secur.; 2023; 18, pp. 1653-1666. [DOI: https://dx.doi.org/10.1109/TIFS.2023.3245406]

31. Tian, Y.; Li, N.; Li, Y. Policy-based chameleon hash for blockchain rewriting with black-box accountability. Proceedings of the Annual Computer Security Applications Conference; Austin, TX, USA, 7 December 2020; pp. 813-828.

32. Jia, Y.; Sun, S.F.; Zhang, Y. Redactable blockchain supporting supervision and self-management. Proceedings of the 2021 ACM Asia Conference on Computer and Communications Security; Hong Kong, China, 4 June 2021; pp. 844-858.

33. Ren, Y.L.; Zhai, M.J.; Hu, M.Q. Fair redactable blockchain supporting malicious punishment. J. Xidian Univ.; 2023; 50, pp. 203-212.

© 2025 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.

RBAU: Noval Redactable Model with Audit Mechanism and Key Update for Alliance Chain

Content area

Abstract

Full text

1. Introduction

2. Related Work

3. Redactable Model

3.1. Architecture

3.2. Model Design

3.2.1. Review and Consensus Mechanism

3.2.2. Security Scheme of Double Hash Functions

3.2.3. Redactable Strategies

4. Experiments and Discussion

4.1. Safety Analysis

4.1.1. Correctness

4.1.2. Original Key Collision Resistance

4.1.3. Updated Key Collision Resistance

4.1.4. The Subkey Updatability

4.1.5. The Non-Updatability of the Master Key

4.2. Experimental Results and Analysis

4.2.1. Experimental Environment

4.2.2. Function Comparison

4.2.3. Algorithm Performance

4.2.4. Model Performance

5. Conclusions