LBFT: An Asynchronous Committee-Based Blockchain Storage Strategy on Zero Trust Model

Round 1

Reviewer 1 Report

The paper proposes an Asynchronous, committee-based storage mechanism for Blockchain, based on the combination of BFT and Erasure coding.

 

The paper attempts to address some of the score aspects of the mainstream Blockchain architectures, i.e., storage size and content distribution.

 

The paper is well-written, and the methodology is clearly presented and analyzed.

 

Still, to the best of my understanding, the adoption of the proposed methodology in real-life applications will probably encounter a number of significant issues, concerning for instance the load induced by the formation of the “committees” on a per-transaction basis, as well as with the openness of the realm: Generally, nodes should be allowed to join/leave ad-hoc, which may lead to problematic committee formations. On top, having the LBTF running on “any peer node” consensus on the selection of the committees may also pose issues.

In addition, forcing “every node” to maintain “an array to store the credits of all the nodes” (Lines 398-399) introduces the need for additional storage space of O(n^2), and mandates for “closed” realms where everyone knows every other.

 

In section 5. Performance absolute throughput numbers are presented (rank 10^4 TX/s), without some reference to the “reference architecture”  utilized (i.e., the hardware of the nodes, the capacity/speed of the network, as well as the methodology by which the results were extrapolated for up to 64 and 104 nodes respectively).  To the best of my effort, I did not conclude if the experiment took place in physical HW-nodes, in SW simulation or in a combination. In my opinion, an explanatory paragraph on the testbed would be helpful to the reader.

I also noted some minor expression issues, which the authors should take care, as in the conclusions (lines 546-547) where the authors probably mean “complexity” instead of “efficiency”.

 

Author Response

Thanks for your kind suggestions and we list the replies as follows:

1. In LBFT, all the nodes participate in the process of batching transactions into a block, without forming committees, while committee election only occurs when a client requests for some block and the system aims to decode the original block. To maintain decentralization, the committees will re-form in each decoding round(decode a certain block), and in a single decoding round, we assume that no node will leave or join, which will not influence the committee election.
2. In the rank system, we require each node to preserve an array to store the credit of each node to guarantee the authenticity of the credits (to achieve consensus on the credits of nodes and prevent malicious nodes to forge credits). Since the credit is a small int (e.g.: 0 - 100),  we use short to store each credit, whose storage consumption is even small than the aggregate signature.
3. We have added more details of our experiment environment in Section 6 (Line 506 - 513).
4. We have checked and revised expression mistakes.

 

Reviewer 2 Report

The paper requires prior understanding of the earlier algorithms and methods.

The various parameters (mathematical variables) should be cleanly listed either at the start or as they are introduced.

The references should be in order (not jump from 3 to 11 to 34).

 

Author Response

Thank you for your suggestions and our replies are as follows:

1. The introduction of ealier algorithms and methods are improved in section 3.
2. We list the main parameters in table 2 in section 3.
3. We have revise the order of the references.

Reviewer 3 Report

The authors address the problem of blockchain-based storage that is made on top of Byzantine fault tolerance algorithms. The topic is interesting to readers, especially those interested in distributed storage. The paper is well-organized and well-structured, however, there are some shortcomings that need to be addressed.

1-      The abstract should be rewritten to show the importance of this paper and improve its fluency, mostly there is no citation in the abstract.

2-     Motivation is not sufficiently stated in the introduction part. It should be clarified why the author considers this problem and what advantages the proposed model. The authors should revise the introduction and clarify the objective of this paper in detail precisely.

3-     There are many modified versions of Byzantine fault tolerance, it is recommended to explain why authors expand their model based on some decent version of BFT like Aardvark and RBFT which addressed its robustness issues.

 

4-     Currently there are some distributed storage systems such as StorJ, Filecoin, and IPFS, it is recommended to discuss the differences. 

Author Response

We sincerely appreciate your kind suggestions and guidance, and this letter will list the details of the revisions in the paper point by point and my explanation to the comments. 

The details about our revision please see the attachment "CV Letter".

Author Response File: Author Response.docx

Reviewer 4 Report

1.     I suggest to expand cited references to elaborate on the blockchain storage redundancy problem and provide an overview summary of the advantages and shortcomings of the solutions that already exist.

2.     Although this paper presents a detailed comparative experiment on the throughput of blockchain, this paper proposes a storage strategy, and I suggest an experimental analysis related to storage scalability and a comparative analysis with already existing schemes.

Author Response

We sincerely appreciate your kind suggestions and guidance, and this letter will list the details of the revisions in the paper point by point and my explanation to the comments.

The details of our revision please see the attachment "Cover Letter".

Author Response File: Author Response.docx

Reviewer 5 Report

The paper overall reads well. Some comments.

1, The title should better show the feature of LBFT. Note that " Reliable Committee-based" are too common for a blockchain technology.

2, The concept of Committee-based has been used in some recent papers, e.g.,  https://doi.org/10.1109/TPWRS.2021.3086101, https://doi.org/10.1038/s41560-022-01027-4, https://doi.org/10.1016/j.adapen.2021.100029, https://doi.org/10.1109/TII.2019.2955719, https://doi.org/10.1109/ICDH.2018.00029, https://doi.org/10.3390/fi12080122.

Please compare your method with similar methods.

3, Line 8, should be "increase the computational efficiency".

4, The authors give comparison of LBFT and BFT-Store. Can the authors briefly compare LBFT with some strategies other than CFT-store? 

 

Author Response

We sincerely appreciate your kind suggestions and guidance, and this letter will list the details of the revisions in the paper point by point and my explanation to the comments.

The details about our revision please see the attachment "Cover Letter".

Author Response File: Author Response.docx

Round 2

Reviewer 4 Report

The authors have made carefully modifications to the suggestions, expanded cited references to analyze the existed research results within the field of blockchain storage, and presented a detailed comparative experiment of the blockchain storage, as well as a detailed analysis of the experimental results.

The LBFT model effectively reduces the storage capacity and increases the system throughput.

Reviewer 5 Report

My comments are addressed.