Next Article in Journal
FakeNewsLab: Experimental Study on Biases and Pitfalls Preventing Us from Distinguishing True from False News
Next Article in Special Issue
QuickFaaS: Providing Portability and Interoperability between FaaS Platforms
Previous Article in Journal
Improving Quality Indicators of the Cloud-Based IoT Networks Using an Improved Form of Seagull Optimization Algorithm
Previous Article in Special Issue
Research on Progress of Blockchain Consensus Algorithm: A Review on Recent Progress of Blockchain Consensus Algorithms
 
 
Article
Peer-Review Record

Latency Analysis of Blockchain-Based SSI Applications

Future Internet 2022, 14(10), 282; https://doi.org/10.3390/fi14100282
by Tamas Pflanzner, Hamza Baniata and Attila Kertesz *
Reviewer 1:
Reviewer 2: Anonymous
Reviewer 3: Anonymous
Future Internet 2022, 14(10), 282; https://doi.org/10.3390/fi14100282
Submission received: 31 August 2022 / Revised: 26 September 2022 / Accepted: 27 September 2022 / Published: 29 September 2022
(This article belongs to the Special Issue Distributed Systems for Emerging Computing: Platform and Application)

Round 1

Reviewer 1 Report

In this paper, the authors proposed a deployment architecture for Self Sovereign Identity (SSI) applications, and developed a Python application with containerized components to realize it.The proposed work is evaluated under different metrics including Latency. This paper is well organized and the contributions are good fit for this journal. However, there are some comments to be addressed before consider this paper for publication.

1. The related works are not highlighted limitations, whereas the authors studied the existing approaches. It is recommended to the authors to provide the limitations of the existing ones and which of these limitations are addressed in the proposed work.

2. The motivation of the paper is not clear. It is recommended to provide the motivation of the paper in the Introduction using an illustrative example. It is also recommended to highlight the contributions in the Introduction.

3. Compare the proposed algorithm using most recent works, whereas the comparisons are old.

4. The limitations of the proposed work to be highlighted, and also provide the possible solutions to extend this work in the near future.

 

Author Response

  1. The related works are not highlighted limitations, whereas the authors studied the existing approaches. It is recommended to the authors to provide the limitations of the existing ones and which of these limitations are addressed in the proposed work.

ANSWER:

We have highlighted the limitations in the related works section in our revision. We mostly addressed measurements concerning the write and read latency in this paper.

 

  1. The motivation of the paper is not clear. It is recommended to provide the motivation of the paper in the Introduction using an illustrative example. It is also recommended to highlight the contributions in the Introduction.

ANSWER:

We clarified the motivation of the paper, and provided an example in the revision.

 

  1. Compare the proposed algorithm using most recent works, whereas the comparisons are old.

ANSWER:

We have updated the related work with a more recent work, but there is no similar work in the literature using Hyperledger Indy for the same purpose.

 

  1. The limitations of the proposed work to be highlighted, and also provide the possible solutions to extend this work in the near future.

ANSWER:

We mentioned our planned future works, and since we are currently working on a possible extension, we referenced the corresponding paper.

Reviewer 2 Report

The paper describes an interesting topic. The authors evaluated and compared the performance with metrics of reading and writing response latency. The conclusions and potential impacts of the paper are made clear.

Author Response

Thank you for your review.

Reviewer 3 Report

Dear authors,

After reading your paper I recognize the work and effort of setting up a blockchain platform in two environments, I know that it is not always easy to "follow the instructions" and I also believe that the subject you are dealing with, the latency at the time of certifying Identity in a blockchain network is important.

Having said that, there are several comments, some questions and suggestions that I would like to make to you.

Regarding the format:

1) There are sentences that are missing a verb. i.e. line 20 "The technology utilized...... Line 191 "The details read and write latency measures privated in Table 1". The same in line 200.

 

2) figures 4,5,7 and 9 are not referenced in the text and I also think that in line 246 you mean Figure 9 instead of the second Figure 8.

3) Numbers in the Tables use comma for decimal separator instead of periods as in the text.

4) The acronyms VC and DID are defined on page 3 at the end, but are used before. And TTP is missing.

Regarding the content:

1) the results obtained seem obvious, but they are still valuable, the interesting thing would have been to find a relationship or a model that predicts what number of nodes it pays to mount a local blockchain, for example.

 

2) In the discussion section on lines 234 and 235 you also refer to the size of the buffer. Have you tried with different sizes to be able to conclude that it is an element that affects latency? if you have done it, it would be nice to see the results and give an optimum value.

3) I also miss how you measure the latency, Itt would be interesting to present your measurement benchmark.

And now some questions. I miss in the related work section references to latency measurements in other environments. If I have no misunderstanding, it seems that the trend is to implement SSI management in the same technology in which the blockchain is going to be deployed. Would it be possible, for instance, to implement identity management with Hyperledger Indy and then use Ethereum for network deployment?

In general, I think the work and the topic are good, but in my opinion the results need to be better justified.

Author Response

Regarding the format:

1) There are sentences that are missing a verb. i.e. line 20 "The technology utilized...... Line 191 "The details read and write latency measures privated in Table 1". The same in line 200.

ANSWER:

We have corrected the mentioned sentences.

 

 

2) figures 4,5,7 and 9 are not referenced in the text and I also think that in line 246 you mean Figure 9 instead of the second Figure 8.

ANSWER:

We have corrected the figure references.

 

3) Numbers in the Tables use comma for decimal separator instead of periods as in the text.

ANSWER:

We have changed the decimal separators in the text.

 

4) The acronyms VC and DID are defined on page 3 at the end, but are used before. And TTP is missing.

ANSWER:

We have defined the acronyms on the first appearance.

 

Regarding the content:

 

1) the results obtained seem obvious, but they are still valuable, the interesting thing would have been to find a relationship or a model that predicts what number of nodes it pays to mount a local blockchain, for example.

ANSWER:

We provided the considered measurements, because the acceptable performance depends on the requirements of the application. Also, we extended our local experiments performed with 8 nodes.

 

2) In the discussion section on lines 234 and 235 you also refer to the size of the buffer. Have you tried with different sizes to be able to conclude that it is an element that affects latency? if you have done it, it would be nice to see the results and give an optimum value.

ANSWER:

Thank you for the suggestion. We have not tried this method, but in the future we would like to go this direction as well.

 

3) I also miss how you measure the latency, It would be interesting to present your measurement benchmark.

ANSWER:

We have clarified the measurement method by adding the specific python SDK calls used.

 

And now some questions. I miss in the related work section references to latency measurements in other environments. If I have no misunderstanding, it seems that the trend is to implement SSI management in the same technology in which the blockchain is going to be deployed. Would it be possible, for instance, to implement identity management with Hyperledger Indy and then use Ethereum for network deployment?

ANSWER:

We have extended the related work. Hyperledger Indy uses Fabric as an underlying blockchain, but we referenced our other work designed for an SSI system.

Back to TopTop