## 7 Redaction Mechanisms in Blockchain
### Redactable Blockchain-Based Chameleon
#### 7.1.3 Redactable Consortium Blockchain  
[PERSON] et al. [79] demonstrated that [61] blockchain protocol was not optimally applicable to the conventional industrial IoT (IIOT) scenario and, therefore, a redactable consortium blockchain (RCB) was established to increase redacted transaction validity. The RCB concentrates on forfeiting transaction redactions when modifiers are offline while upgrading the CH function as threshold CH (TCH) through linkage with participants' identities (authorized sensors). Authorized sensors with genuine identities could effectively calculate additional randomness assisted by holders with trapdoor keys. By adhering to the hash-and-sign model, the TCH function hashes. The transactions before being endorsed by an accountable-and-santizable chameleon signature (ASCS) algorithm [94] as portrayed in Figure 7. Participants with authentic identities could also assess the same signature to authenticate redacted transactions. Nevertheless, the scalability issue exists owing to the high cost of generating trapdoor key holders' pertinent signatures, which increases proportionally to the number of nodes. Redaction power exploitation could also occur concurrently. [PERSON] et al. [80] developed smart-chained redactions supported by the self-redactable blockchain proposal (SRB), which required no cooperation to perform transaction redaction in the blockchain. The revocable hash function (RCH) optimizes the CH function by linking identities within a cyclic time and being relied on by the revocable chameleon signature (RCS) to generate transactions. Participants are only allowed to perform periodic redactions based on the defined cyclic time in the blockchain. Specifically, private redactions are conducted with trapdoor keys contained, and (X-1) public redaction only if any X transactions are attached beyond the performed redaction. Meanwhile, public reaction is conducted through the signature to facilitate every individual performing transaction authentication. When a trapdoor expiration period is stipulated, the trapdoor will be updated periodically. Nevertheless, due to high cryptographic complexity, the SRB is rarely adopted in IoT devices. In addition, low adoption is due to the SRB and the RCB sharing a fixed expiration period, which renders the trapdoor key management inflexible while allowing the old trapdoor to be continuously utilized. Hence, key exposure would pose security issues. [PERSON] et al. [81] proposed the reusable and redactable blockchain (Re-chain) for the RCB, which was a redactable and reusable blockchain established by the threshold trapdoor CH (TTCH) function to address blockchain storage issues in accounting for information explosion. The proof-of-concept consensus was also realized when Re-chain achieved maximum storage size to rewrite previous blocks with security and authority, while maintaining block connection safety. Consensus guarantees robustness even with the presence of N-node acceptance (N/2-1) faults in the edge nodes. Furthermore, Re-chain is beneficial for the IIOT which frequently encounters serious storage limitations. Past experiments revealed that the rewriting process was efficient when performance achieved a medium scale within the limit of 30 nodes. Nonetheless, the deficiency of scalability due to high computation overhead would not support user accountability and anonymity on the platform. Time could be defined as a physical entity in terms of hours and days, or as a virtual being in terms of the number of blocks in the blockchain. As such, time is the main factor in generating an efficient key to redact and generate transactions. Correspondingly, [PERSON] et al. [82] suggested a decentralized CH function to gain enhanced security, time efficiency, and reduced space overhead in offering higher RCB flexibility. Modifiers would be necessitated to sign redaction requests to be validated by authorized nodes on personal identities by comparing the signatures and redaction requests.