Ring-Overlap: A Storage Scaling Mechanism for Hyperledger Fabric
Round 1
Reviewer 1 Report
The paper targets a vital problem for scaling and sharding problems. The paper introduces a new concept to clustering for sharding to achieve efficient storage management in the blockchain. Finally, a detailed experimental analysis shows the feasibility of the proposed model.
In my judgment, the proposed model contributes significantly to the extant literature. However, the mentioned comments must be addressed with a suitable description.
1. The authors mentioned that - Division of accounting nodes into clusters, where each node in some clusters stores only a portion of data instead of the whole. However, this concept is somehow similar to the concept of “Lite Node” in the blockchain. So, the authors may describe how such clustering differs from this concept.
2. Why employ the concept of “Static clustering”? If it is efficient, please describe the detailed analysis for the same.
3. In section 4.3.2, the authors employ “gossip protocol” for the random selection of nodes to send messages. However, there is no description of “gossip protocol” and also about the significance of the random selection of nodes.
4. In section 4.3.1, the authors mentioned that the cluster identity that the newly generated block belongs to which cluster, on the basics of cluster id. However, is it possible to initially define cluster id to block? and How?
5. For security analysis – The authors include detailed security analysis; however, the authors should include the detailed security proofs for some standard – “Gossiping guarantees - guarantees that a message gossiped by any honest node will eventually reach all other honest nodes and the gossiping delay” and “Epoch security – failure probability of each cluster”.
6. For experimental analysis – the authors provide a detailed experimental and performance analysis of the proposed model. The authors may include some on-chain analysis for blockchain performance, such as – “Average Throughput scalability” and “Average latency.” Moreover, the authors should provide a comparative analysis with some existing sharding models, i.e.,
· Zheng, P., Xu, Q., Zheng, Z., Zhou, Z., Yan, Y., & Zhang, H. (2021, April). Meepo: Sharded consortium blockchain. In 2021 IEEE 37th International Conference on Data Engineering (ICDE) (pp. 1847-1852). IEEE.
· Zamani, M., Movahedi, M., & Raykova, M. (2018). RapidChain: A Fast Blockchain Protocol via Full Sharding. IACR Cryptol. ePrint Arch., 2018, 460
Author Response
Dear Reviewer:
We gratefully appreciate the time you have taken to provide positive and constructive comments. These comments are all valuable and helpful for revising and improving our manuscript entitled " Ring-Overlap: A Storage Scaling Mechanism for Consortium Blockchain (ID: applsci-1879380)”, as well as the important guiding significance to our researches. We have studied comments carefully and have made correction which we hope meet with approval. The manuscript was revised using the "Track Changes" function. The summary of corrections and the responses to the reviewer's comments are listed below.
1.Comment: The authors mentioned that - Division of accounting nodes into clusters, where each node in some clusters stores only a portion of data instead of the whole. However, this concept is somehow similar to the concept of “Lite Node” in the blockchain. So, the authors may describe how such clustering differs from this concept.
Reply: Thank you for your comments. In the paper, the accounting nodes are divided into clusters so that each node no longer needs to store the whole network data but only part of it. However, the Lite node does not contain any chain data on it, it is only responsible for executing message signatures and transaction transactions. So it is said that the two are different.
2.Comment: Why employ the concept of “Static clustering”? If it is efficient, please describe the detailed analysis for the same.
Reply: Thank you very much for your question. The manuscript is a proposed scheme for consortium blockchain, where the number of nodes in the consortium blockchain is relatively fixed, so static clustering is used. By static clustering, the peer nodes are divided into m clusters; each cluster consists of n nodes; and each node keeps the cluster number and node numbers. The whole network data is divided into m copies that do not overlap each other, and each cluster stores 1/m of data. And the data is stored overlappingly within a single cluster (the specific storage process is in Section 4.3.1), so that each node no longer needs to store the whole network data, but only part of the data, and the theoretical analysis and experimental results show that the storage space used by a single node tends to be s/(m*n). Therefore, the storage scalability of the blockchain can be greatly improved by this approach.
3.Comment: In section 4.3.2, the authors employ “gossip protocol” for the random selection of nodes to send messages. However, there is no description of “gossip protocol” and also about the significance of the random selection of nodes.
Reply: Thank you for your comments. We added a description of the Gossip protocol in section 4.3.2 using the “Track Changes” function. The reason for the random node selection is that the basic idea of the Gossip protocol is that a node wants to share some information with some other nodes in the network. It is a periodic process of randomly selecting some nodes and passing information to those nodes.
4.Comment: In section 4.3.1, the authors mentioned that the cluster identity that the newly generated block belongs to which cluster, on the basics of cluster id. However, is it possible to initially define cluster id to block? and How?
Reply: Thank you for your comments. The newly generated blocks in the text are determined by the cluster id based on the block id, not by the cluster id. The formula for finding the cluster id in 4.3.1 is bØm=i, b is the block id, m is the number of clusters, and i is the cluster id.
5.Comment: For security analysis – The authors include detailed security analysis; however, the authors should include the detailed security proofs for some standard – “Gossiping guarantees - guarantees that a message gossiped by any honest node will eventually reach all other honest nodes and the gossiping delay” and “Epoch security – failure probability of each cluster”.
Reply: Thank you very much for the question. We added the Gossip proof in section 5.2.2, and for the issue of per-cluster failure probability, we added a related description in section 5.2.3.
6.Comment: For experimental analysis – the authors provide a detailed experimental and performance analysis of the proposed model. The authors may include some on-chain analysis for blockchain performance, such as – “Average Throughput scalability” and “Average latency.” Moreover, the authors should provide a comparative analysis with some existing sharding models, i.e.,
- Zheng, P., Xu, Q., Zheng, Z., Zhou, Z., Yan, Y., & Zhang, H. (2021, April). Meepo: Sharded consortium blockchain. In 2021 IEEE 37th International Conference on Data Engineering (ICDE) (pp. 1847-1852). IEEE.
- Zamani, M., Movahedi, M., & Raykova, M. (2018). RapidChain: A Fast Blockchain Protocol via Full Sharding. IACR Cryptol. ePrint Arch., 2018, 460
Reply: Thank you for your comments. The manuscript proposes a solution that does not change the average throughput. For the average latency issue, we have given specific experimental results in Section 6.3.2. The advantages and disadvantages compared to the existing sharding model are added in section 2.2.
Author Response File: 
Author Response.docx
Reviewer 2 Report
The authors describe a rather interesting "distributed" blockchain model, which aims to optimize the storage space that is required in order to persist the entire blockchain structure and the related ledger (transactional history). The following aspects should be improved or made clearer.
1. The distributed nature of the proposed model may theoretically imply that some data loss or corruption is possible, if some members of the cluster malfunction. Did the authors consider these problematic aspects, what data integrity mechanisms did they design or thought about?
2. The literature review that is included does not contain an analytic presentation of the proposed model's advantages and drawbacks, as compared to similar existing approaches. The authors should include sufficient comparative remarks in this respect.
3. The authors should demonstrate that the positive outcomes of the inherently restrained experimental setup that was considered, are scalable to real big blockchain structures in real-world scenarios.
4. The English language should be proofread and improved.
Author Response
Dear Reviewer:
We gratefully appreciate the time you have taken to provide positive and constructive comments. These comments are all valuable and helpful for revising and improving our manuscript entitled " Ring-Overlap: A Storage Scaling Mechanism for Consortium Blockchain (ID: applsci-1879380)”, as well as the important guiding significance to our researches. We have studied comments carefully and have made correction which we hope meet with approval. The manuscript was revised using the "Track Changes" function. The summary of corrections and the responses to the reviewer's comments are listed below.
1.Comment: The distributed nature of the proposed model may theoretically imply that some data loss or corruption is possible, if some members of the cluster malfunction. Did the authors consider these problematic aspects, what data integrity mechanisms did they design or thought about?
Reply: Thank you for your comments. The issue you raised has been considered, and to ensure data integrity, the block data is stored using overlapping storage. The specific storage structure is shown in Figure 4 in Section 4.3.1. And in the analysis in Section 5.2.1, it is concluded that when the number of failed nodes in a single cluster does not exceed s-1 (s is the number of copies of a single block stored in a single cluster), this mechanism can still ensure the integrity of the block data.
2.Comment: The literature review that is included does not contain an analytic presentation of the proposed model's advantages and drawbacks, as compared to similar existing approaches. The authors should include sufficient comparative remarks in this respect.
Reply: Thank you for your comments. In response to the question, we have added the advantages and disadvantages of the proposed model compared to similar existing methods in Section 2.2.
3.Comment: The authors should demonstrate that the positive outcomes of the inherently restrained experimental setup that was considered, are scalable to real big blockchain structures in real-world scenarios.
Reply: Thank you for your comments. The manuscript is proposed for the federated blockchain Hyperledger Fabric. So it can be scalable to systems with separate ledgers and data.
4.Comment: The English language should be proofread and improved.
Reply: Thank you very much for your comment. In response to the question, we have proofread and improved the English language.
Author Response File: Author Response.docx
Round 2
Reviewer 2 Report
The changes that the authors implemented made the paper clearer, and the presentation of the reported contribution can be followed easier. I suggest that an additional round of English proofreading be conducted, then the paper may be considered for publication.
Author Response
Dear Reviewer:
We greatly appreciate the time you have taken to provide your comments. We have carefully revised and proofread the language of the article and hope that it will be approved. We revised the manuscript using the "Track Changes" function.
Author Response File: 
Author Response.pdf
