# A Redactable Blockchain Scheme Supporting Quantum-Resistance and Trapdoor Updates
## 5 Experiments and Results Analysis
### Performance of HIBCH-RS-Based Redactable Blockchain  
The redactable blockchain scheme based HIBCH-RS, as elaborated in Section 4, boasts compatibility across various chain types, including public, alliance, and private chains.  
In the context of public chains, the scheme necessitates nearly complete decentralization of delegated keys. At this point, editable nodes are added to the hierarchical identity by application in a decentralized way. To establish this dynamic, a reward and punishment mechanism can be instituted, where nodes that adhere to agreed-upon rules can receive rewards, while those that deviate may face penalties.  
Within an alliance chain, the scheme can be overseen by a certificate authority and monitored by the regulator. In a private chain, this delegated management structure can be entrusted to a centralized organization, while concurrently imposing constraints on users possessing edit permissions.  
To concretize these concepts, this paper proceeded to implement the redacting scheme using the Fabric platform, which is an alliance chain framework featuring a pluggable mechanism. In this subsection, we elucidated the integration of the editing scheme, ensuring compatibility within the Fabric ecosystem.  
Redactable Hyperledger Fabric  
Schemes for implementing redactable blockchains based on post-quantum ciphers are in the minority, followed by equally fewer schemes for building editability in practical platforms. Thus, there are almost no practical schemes that we can compare. For the above reasons, in this experiment we demonstrate the performance of this paper's scheme mainly in terms of the processing efficiency of editable requests, the size of editable blocks, and the throughput of editable requests. The parameter \(pg=60\) was chosen for this part of the experiment, and the test was in terms of blocks. The experimental results are shown by Figure 6.  
Redactable blocks cost some extra storage due to storing the editing information associated with them, but as can be seen in Figure 6, this extra cost is small, and in practice, every transaction in the block may not always be allowed to be editable. As a result, block sizes tend to be smaller than shown in the pictures above. Second, in Figure 6, we show  
Figure 6: Redactable blockchain performance. (**a**) Comparison of block size, with the difference between the redactable block and the original block structure shown in detail. (**b**) Showing the performance of transactions per second.  
the throughput of edit request processing. The experiment was tested using the caliper tool, and the choice of the number of transactions stored in the block and the number of transactions sent is shown in Table 5.  
As can be seen from Figure 6b, the redactable transaction throughput is low compared to the normal transaction throughput, but this is sufficient in a redactable blockchain.  
In this paper, in the parameter configuration, the caching time of the edit request was specified as 5 s. Finally, the selected personal and public transaction data were edited and verified. We tested the time of Algorithm 3 and results are displayed in Table 6. When compared to modifying public transaction data, the alteration of private transactions introduced an extra authentication time for the user. Specifically, the time required for editing a block in the quantum-resistant redactable blockchain exceeded 4.66 s, but the maximum time did not exceed 8.29 s.