RACER: A Lightweight Distributed Consensus Algorithm for the IoT with Peer-Assisted Latency-Aware Traffic Optimisation

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors The paper introduces a novel consensus mechanism called Randomised Asynchronous Consensus with Efficient Real- time Sampling (RACER) framework that eliminates the need for synchronized networks and clocks by implementing SPDE algorithm. Below are my comments: ABSTRACT:

• The abstract is well written; however, I’d suggest adding a statement that talks about the efficiency of these models based on their experiments.

INTRODUCTION:

• Overall, the contributions are pretty well framed except the last contribution on how fully implemented Python is actually a contribution of this paper. Does this mean, it cannot be integrated with other frameworks that are written in different programming languages?

RELATED WORK

• This section is well written. A good review of literature sets a strong foundation for proposing a framework that overcomes the limitations of synchronous network and limited transaction throughput.

MATERIALS AND METHODS

• The authors have used Byzantine Broadcast to ensure their framework is suited for low-power IoT devices, however, it is not very clear if it actually helped them achieve stable network conditions. I’d suggest adding more details on how BB helped.
• It is interesting how authors are using a tie-breaker technique on transaction hashes if two transactions end up having same vector clock value. How many times you have faced this situation in your experiments?
• For message batching in RACER, authors have used gossiping as it might reduce congestion and energy consumption, however, gossiping can also add to congestion if random messages are broadcasted. How do you tackle this situation? Are you using transaction aggregation for this?

RESULTS

• To test your algorithm performance, you have used CPU Time, Execution Time, Memory Usage. Why not test on the number of bytes (data)?
• For Network Fault Tolerance, what edge cases have you considered?
• How did you set your benchmarks in Table 1, e.g., why 10s for Target Latency?
•  
• CONCLUSION
• It is always a good idea to highlight the future work in this section. What would be the next steps in your research?

GENERAL COMMENTS

• English proofreading is required. Few grammatical mistakes throughout the manuscript.

Comments on the Quality of English Language

Minor review is required. There are some instances where English language can be improved.

Author Response

Comments attached as PDF file.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

This paper “RACER: A Lightweight Distributed Consensus Algorithm for the

IoT with Peer-assisted Latency-Aware Traffic Optimisation” presents a consensus algorithm for latency optimization in IoT. The authors should revise the article to deal with the following concerns.

 

Concern 1: The keywords are too few. The word consensus as a keyword and its use in abstract is not clear. Is is a blockchain based consensus algorithm? If so, why there is no mention of it in the abstract?

Concern 2: There are very few references in the introduction section.

Concern 3: The first 2 contributions in the introduction are actually assumptions. They need to be re-written as contributions.  

Concern 4: Can the related work be categorized on some parameters?

Concern 5: How can the correctness of the proposed algorithm be proved?

Concern 6: all figures need revision to construct better quality and higher pixel output.

Concern 7 : Recent references can be considered to enhance the references such as

Microservices enabled bidirectional fault-tolerance scheme for healthcare internet of things (cluster computing)

Author Response

Comments attached as PDF file.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

In the manuscript, the authors introduced RACER as a new consensus mechanism for IoT systems designed to address common issues like the need for synchronized networks, centralized coordinators, and low performance. They also developed the Sequenced Probabilistic Double-Echo (SPDE) algorithm for asynchronous operation and a gossip protocol to remove the need for leaders. In addition, they created Peer-assisted Latency-Aware Traffic Optimization (PLATO) to boost network efficiency.

Overall, RACER significantly contributes to the field, tackling key problems found in current IoT consensus protocols. It removes the need for synchronized clocks and central coordinators, which have been limitations in existing systems. The combination of SPDE and PLATO also offers an effective way to improve network performance, resilience, and efficiency. By focusing on IoT sensor networks and minimizing reliance on central authorities and synchronized systems, the approach is effective for real-world IoT applications, addressing critical aspects such as scalability and fault tolerance.

The manuscript is interesting and well-organized, and the concepts are presented clearly, making it accessible to readers with varying levels of expertise in distributed systems and IoT. The authors have done an excellent job with this work.

 

Author Response

Thank you for your encouragement!

Reviewer 4 Report

Comments and Suggestions for Authors

Your paper presents a good contribution to IoT consensus mechanisms through the RACER algorithm and its integration with PLATO for latency-aware traffic optimization. The approach is well-motivated. However, certain areas require improvement in clarity, justification, and technical depth to strengthen the manuscript.

 

The introduction lacks a structured comparison between RACER and existing lightweight IoT consensus mechanisms. While blockchain-based approaches are mentioned, there is no explicit differentiation from state-of-the-art models such as Tangle (IOTA), PoAh, or hybrid consensus frameworks. A short discussion or a comparative table summarizing differences in energy consumption, scalability, and latency performance would improve clarity and emphasize RACER’s novelty.

The methodology section does not justify the selection of simulation parameters such as latency thresholds, network sizes, and traffic loads. It is unclear why specific values were chosen and whether they align with real-world IoT deployments. Providing references to industry benchmarks (e.g., IEEE 802.15.4, 5G URLLC, LPWAN) would enhance the credibility of these parameter choices. Additionally, explaining how RACER adapts to different network densities would provide better insight into its robustness.

The results section presents performance improvements but lacks sufficient discussion on the observed trends. While the figures demonstrate latency reduction and network efficiency, no detailed explanation exists for why RACER performs better under specific conditions. The paper does not analyze the scalability limits of RACER, particularly under high-density IoT networks. Including an additional experiment or a discussion on how RACER behaves as the number of nodes increases would make the results more comprehensive. Furthermore, the impact on energy efficiency is not discussed, which is critical for IoT applications. 

The conclusion does not sufficiently address the real-world applicability of RACER. While the benefits are summarized, there is no discussion of how this approach could be implemented in actual IoT deployments such as smart cities, industrial automation, or healthcare monitoring. A short section outlining deployment challenges, hardware feasibility, and potential optimizations would enhance the practical relevance of the research.

Comments on the Quality of English Language

The writing is technically fine but could be improved in terms of clarity. Some sections, particularly in the Methods and Results, are dense and contain overly complex explanations and better to be clearer.

Author Response

Comments attached in PDF file.

I appreciate your detailed feedback,

~Zac

Author Response File: Author Response.pdf

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

I do not have further comments.

Author Response

Thanks for taking the time to review our work.

Reviewer 4 Report

Comments and Suggestions for Authors

This manuscript presents a technically sound framework, RACER and PLATO, that addresses key challenges in distributed IoT consensus, including centralization, synchronous assumptions, and poor latency control. The integration of SPDE-based consensus and trend-aware traffic optimization shows clear advantages in throughput and robustness, validated through detailed simulations.

To further strengthen the manuscript:

1.

Although scalability is well-demonstrated in simulation, a brief discussion on how RACER might be deployed in real-world, constrained environments (e.g., LoRa, ZigBee) would enhance its applied relevance.

2.

It would be beneficial to provide a more explicit explanation of how trend filter parameters (e.g., smoothing window size) were selected and tuned during experimentation.

3.

Consider reducing the use of repeated abbreviations (e.g., ICMJ/DCMJ) or adding a table of acronyms for improved readability.

4.

Sections describing the SPDE protocol and PLATO algorithms are informative but occasionally dense. Simplifying long sentences and reducing repetition will improve clarity.

Comments on the Quality of English Language

The manuscript is generally well-written but would benefit from improved clarity. Several sections contain long or complex sentences that could be simplified for better readability. A professional language edit is recommended to enhance overall fluency and precision.

Author Response

Thanks again for the comments. Response Attached.

Author Response File: Author Response.pdf