Evaluation of an Efficient Ring-Based Total Order Protocol in a Fairness-Controlled Environment
Round 1
Reviewer 1 Report
Comments and Suggestions for AuthorsThe paper entitled "Evaluation of an efficient Ring-Based Total Order Protocol in a Fairness-Controlled Environment" presents the Daisy Chain Total Order Protocol (DCTOP), a novel leaderless ring-based protocol that aims to reduce latency and improve fairness in distributed systems. The approach builds on weaknesses identified in the LCR protocol by introducing Lamport timestamps, a dynamically assigned “last” process for message ordering, and a relaxed fault tolerance assumption. In general, the topic is of clear relevance to distributed systems and potentially has practical implications. However, the manuscript requires substantial improvements before it can be considered for publication. Below are my suggestions and comments for improvements:
- While the theoretical contributions are articulated in detail, the practical applicability of DCTOP remains underdeveloped. The authors mention that real-world deployment is "ongoing" (Section 1.1) but offer no insights into how DCTOP can be integrated into existing systems, what real-world constraints it may face, or how it compares to established systems like Raft or Paxos in actual deployments. A clear use case or application scenario (e.g., cloud infrastructure, distributed databases, consensus mechanisms) would strengthen the contribution significantly.
- The related work section is notably lacking in depth. Although some protocols (LCR, FSR, Raft, Paxos) are mentioned, the literature lacks comprehensive comparison with recent advances in total order broadcast, distributed fault-tolerant consensus, and ring-based systems. For instance, recent variants of Fast Paxos or practical Byzantine fault-tolerant protocols are not discussed. The authors are encouraged to extend the literature review with at least 10–15 additional and recent references from high-impact journals/conferences to show where DCTOP stands in the current research landscape.
- The simulation setup, assumptions (e.g., failure detector model), and fault model are only briefly described and lack rigorous justification. There is no explanation of parameter tuning, message loss, network delay modeling, or scalability testing beyond a small cluster (N ≤ 9). For a protocol to be considered robust and efficient, it needs evaluation under diverse, realistic failure and performance scenarios.
- The work relies heavily on simulations and theoretical proofs. However, no real implementation, prototype, or benchmarking is provided. Without even a basic performance comparison on real or emulated networks (e.g., Mininet, Docker-based distributed testbeds), the claims of reduced latency and improved fairness remain largely theoretical.
- The manuscript is difficult to follow at times. The pseudocode and algorithm figures are extensive but not always easy to interpret due to dense text blocks, unclear variable naming, and lack of visual aids. Consider restructuring the technical sections with tables, visual diagrams, and step-by-step examples. Moreover, many sections repeat ideas (e.g., definitions of stability, crashproofing), which could be condensed.
- Finally, while the English is mostly readable but would benefit from thorough proofreading by a native speaker or a professional editor. Issues include repetitive phrasing, run-on sentences, and inconsistent terminology (e.g., "utoDeliver", “obeect” instead of “object”). In addition, the section numbering and figure placement should be checked for consistence.
The English in the paper is mostly readable but would nevertheless benefit from thorough proofreading by a native speaker or a professional English editor.
Author Response
Comment 1:
While the theoretical contributions are articulated in detail, the practical applicability of DCTOP remains underdeveloped. The authors mention that real-world deployment is "ongoing" (Section 1.1) but offer no insights into how DCTOP can be integrated into existing systems, what real-world constraints it may face, or how it compares to established systems like Raft or Paxos in actual deployments. A clear use case or application scenario (e.g., cloud infrastructure, distributed databases, consensus mechanisms) would strengthen the contribution significantly.
Response 1
Thank you for highlighting the need for practical deployment examples for DCTOP. We have revised Section 1.1 (iii) and added Section 1.2 to detail real-world integration and application scenarios.
Comment 2:
The related work section is notably lacking in depth. Although some protocols (LCR, FSR, Raft, Paxos) are mentioned, the literature lacks comprehensive comparison with recent advances in total order broadcast, distributed fault-tolerant consensus, and ring-based systems. For instance, recent variants of Fast Paxos or practical Byzantine fault-tolerant protocols are not discussed. The authors are encouraged to extend the literature review with at least 10–15 additional and recent references from high-impact journals/conferences to show where DCTOP stands in the current research landscape
Response 2:
We sincerely thank the reviewer for their thoughtful and constructive feedback. We fully agree that the original related work section did not provide sufficient depth, particularly in positioning DCTOP within the broader landscape of recent developments in total-order broadcast, ring-based architectures, and fault-tolerant consensus protocols. In response, we have significantly expanded the literature review section, incorporating 10–15 additional references to contemporary protocols. These include leaderless and Byzantine fault-tolerant systems, fast consensus variants, and modern ring-based ordering mechanisms. Ref: Lines 57-95
Comment 3
The simulation setup, assumptions (e.g., failure detector model), and fault model are only briefly described and lack rigorous justification. There is no explanation of parameter tuning, message loss, network delay modeling, or scalability testing beyond a small cluster (N ≤ 9). For a protocol to be considered robust and efficient, it needs evaluation under diverse, realistic failure and performance scenarios.
Response 3
We thank the reviewer for this insightful comment. We acknowledge that the current version of the simulation does not incorporate a failure or fault model. This omission was intentional, as the focus of this study is on verifying the algorithmic correctness and functional behaviour of the proposed Daisy Chain Total Order Protocol (DCTOP) under controlled asynchronous communication conditions. At this initial stage, our goal was to demonstrate that DCTOP can maintain total message ordering, stability convergence, and process synchronization in a purely logical environment before introducing the complexities of fault scenarios. To this end, we employed a Discrete Event Simulation (DES) framework, which provides precise control over event scheduling and message sequencing, allowing for systematic validation of the protocol’s core mechanisms (e.g., timestamping, stability clock updates, and hop-based message propagation). The failure detector and fault tolerance mechanisms are part of our planned follow-up work, where DCTOP will be deployed in a cloud-based experimental environment to evaluate its robustness against node crashes, message loss, and network delay variability. This staged approach first confirming the algorithm’s logical soundness and then extending to fault-tolerant deployment ensures methodological clarity and reduces confounding factors during initial validation. We have revised the last paragraph of the Simulation section to explicitly state this design decision and to clarify the rationale for isolating failure-free conditions in the current evaluation.
Comment 4
The work relies heavily on simulations and theoretical proofs. However, no real implementation, prototype, or benchmarking is provided. Without even a basic performance comparison on real or emulated networks (e.g., Mininet, Docker-based distributed testbeds), the claims of reduced latency and improved fairness remain largely theoretical.
Response 4
We thank the reviewer for this constructive observation. We acknowledge that the current study focuses primarily on theoretical analysis and discrete event simulation. This was a deliberate design choice to first validate DCTOP’s algorithmic correctness, message ordering guarantees, and latency behaviour under controlled asynchronous conditions before introducing system-level complexities.
The simulation-based approach allows precise tracking of event timing, stability clock updates, and logical message propagation confirming the theoretical properties of reduced ordering latency and improved fairness. While no real prototype is presented in this version, a cloud-based, containerized implementation of DCTOP is currently under development. This upcoming stage will evaluate the protocol’s performance on real and emulated infrastructures (e.g., Docker-based clusters) to benchmark throughput, latency, and fault resilience against established protocols such as Raft and Paxos.
We have clarified this staged research plan in Section 1.1 (iii) and in the Simulation Setup section to make the intended progression from theoretical validation to practical benchmarking explicit.
Comment 5
The manuscript is difficult to follow at times. The pseudocode and algorithm figures are extensive but not always easy to interpret due to dense text blocks, unclear variable naming, and lack of visual aids. Consider restructuring the technical sections with tables, visual diagrams, and step-by-step examples. Moreover, many sections repeat ideas (e.g., definitions of stability, crashproofing), which could be condensed.
Response 5
We appreciate the reviewer’s suggestion and have improved readability by adding a comprehensive table (Table 1) defining all notations used in the membership changes pseudocode which was not previously defined. The full algorithms are retained to preserve technical rigor and reproducibility.
Comment 6
Finally, while the English is mostly readable but would benefit from thorough proofreading by a native speaker or a professional editor. Issues include repetitive phrasing, run-on sentences, and inconsistent terminology (e.g., "utoDeliver", “obeect” instead of “object”). In addition, the section numbering and figure placement should be checked for consistence.
Response 6
We appreciate the reviewer’s comment and have carefully proofread the manuscript for grammar, terminology consistency, and layout issues. All typographical errors and inconsistencies (e.g., “obeect”, section numbering, figure references) have been corrected, and the terminology has been standardized across algorithms and text.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
Comments and Suggestions for AuthorsIn this work, the authors studies the server replication problem. Logical Clock and Ring (LCR) protocol is not optimal in latency under high message concurrency due to its use of vector clocks as timestamps for sequencing messages and a fixed "last" process for ordering concurrent messages. To improve latency, the authors propose using Lamport's logical clock as a message timestamp for sequencing messages and redefining the "last" process as the nearest process in the opposite direction of message flow, ensuring a unique last process for each message sender. Fairness is preserved using a modified fairness control algorithm from the Fixed Sequencer and Ring (FSR) protocol. They performed numerical evaluation to show the proposed protocol offers better latency improvement than LCR across all considered configurations. Additionally, fairness among process replicas was maintained, evidenced by an even distribution of message sending responsibilities, with each process contributing approximately equally to total message output. It offers deep insights into an interesting problem that connects many subfields of research. It can be accepted after minor revision.
The paper is well-written. It is generally related to resouce management in a network. Some related references maybe considered. In particular, the kind of problem is attracting attention in quantum network. It will be beneficial to the readers if this can be briefly mentioned.
Author Response
Comments
In this work, the authors studies the server replication problem. Logical Clock and Ring (LCR) protocol is not optimal in latency under high message concurrency due to its use of vector clocks as timestamps for sequencing messages and a fixed "last" process for ordering concurrent messages. To improve latency, the authors propose using Lamport's logical clock as a message timestamp for sequencing messages and redefining the "last" process as the nearest process in the opposite direction of message flow, ensuring a unique last process for each message sender. Fairness is preserved using a modified fairness control algorithm from the Fixed Sequencer and Ring (FSR) protocol. They performed numerical evaluation to show the proposed protocol offers better latency improvement than LCR across all considered configurations. Additionally, fairness among process replicas was maintained, evidenced by an even distribution of message sending responsibilities, with each process contributing approximately equally to total message output. It offers deep insights into an interesting problem that connects many subfields of research. It can be accepted after minor revision.
The paper is well-written. It is generally related to resouce management in a network. Some related references maybe considered. In particular, the kind of problem is attracting attention in quantum network. It will be beneficial to the readers if this can be briefly mentioned.
Response
We sincerely thank the reviewer for their positive feedback and constructive comments. We acknowledge that emerging paradigms such as quantum networking explore related challenges in distributed synchronization and resource management. However, as these technologies are still largely theoretical and not yet standardized for practical or commercial deployment, our work focuses on classical distributed systems where replication and total order protocols are already deployable and widely studied.
The proposed DCTOP framework therefore remains grounded in the current operational context of distributed servers and message ordering protocols, which aligns with the practical scope of this paper. Future work may consider exploring its conceptual extension to emerging computing paradigms, including quantum networks, once stable communication and consensus models are established.
Author Response File: Author Response.pdf
Reviewer 3 Report
Comments and Suggestions for AuthorsI had the opportunity to read "Evaluation of an efficient Ring-Based Total Order Protocol in a Fairness-Controlled Environment" manuscript submitted to Digital journal.
Also I had the opportunity to inspect the supplementary material which contains a java code developed by the first author of this manuscript (Agbaeze Ejem) as part of its phd thesis.
I have inspected the references list as well. For for some of the references the information provided is incomplete; for instance at ref. 3 (a conference paper), year is missing. Same omission of year is other refs. too: 1, 5, 7, 12, etc.
Looking at the references list I was unable to find the aforementioned phd thesis cited. Some of the Instead, other secondary papers of the first author are given. In my opinion, self citation rate is high and it should be reduced by eliminating the secondary sources and make the references to the primary source, phd thesis, instead.
Other irregularities with references are in text: references are cited in bulk (ex.: ref. 1-4 in line 36), not in order (ex.: ref. 25 in line 63 between ref. 15 and ref. 16).
The manuscript body contains numerous indents and/or tabs in middle of sentences (ex.: l. 467, 477, 448, 443 - too many to list all).
Y axis numbers on fig. 8 (latency times) are given in milli-seconds and as effect resulting very big numbers, all of them having last 4 digits zeros. It is no justification to load the graphical representation in this way. Units must be changed to seconds. The same applies for the number of messages send on the other axis there again all numbers have at lest 3 zeros at the end and the units must be changed to upper multiplier (from kilo to mega).
Figure caption is also meaningless (" Figure 8. Latency Comparison ") and details must be added.
The same applies for fig. 9
Fig. 9 is not referred in the main text and it must be (and discussed too).
At fig. 1 bottom part of the figure legend has been chopped (for g and p dots are missing).
Fig. 4 and Fig. 5 are text based figures and the pictorial representation must be replaced with text or resolution must be increased (low looks like at 75-150 dpi while publication standard is at 600 dpi).
There is no convention for the names of the math variables. Also style for the name of variables is changed in the same paragraph (ex. for t_0 and t_1 in lines 598-600.
Resolution for all figures should be increased too (now its at most 300 dpi and it should be increased at at least 600 dpi).
Document type is Article but no clear paragraph stating the research aim is given.
Something resembling author's contribution is spread in the last part of section 1 and before section 1.1. And the figure referred in this part is to be found somewhere later, on another page.
Conclusions are actually summary and discussions.
All above mentioned issues must be addressed before passing to camera-ready.
Author Response
Comment 1
I had the opportunity to read "Evaluation of an efficient Ring-Based Total Order Protocol in a Fairness-Controlled Environment" manuscript submitted to Digital journal.
Also I had the opportunity to inspect the supplementary material which contains a java code developed by the first author of this manuscript (Agbaeze Ejem) as part of its phd thesis.
Author Response 1
We thank the reviewer for taking the time to review both the manuscript and the accompanying supplementary material. The supplementary Java implementation indeed corresponds to the algorithm described in the paper and was developed by the first author as part of his Ph.D. thesis. It is included solely to provide reproducibility and a transparent verification of DCTOP’s core mechanisms.
Comment 2
I have inspected the references list as well. For for some of the references the information provided is incomplete; for instance at ref. 3 (a conference paper), year is missing. Same omission of year is other refs. too: 1, 5, 7, 12, etc.
Response 2
We thank the reviewer for carefully examining the reference list. We have reviewed all references and completed any missing bibliographic information, including publication year, conference or journal details, page numbers, and DOIs where available.
Comment 3
Looking at the references list I was unable to find the aforementioned phd thesis cited. Some of the Instead, other secondary papers of the first author are given. In my opinion, self citation rate is high and it should be reduced by eliminating the secondary sources and make the references to the primary source, phd thesis, instead.
Response 3
We thank the reviewer for suggesting a citation of the primary Ph.D. thesis. As the thesis is under institutional embargo and not publicly available, we have cited the related conference publications that formally present this work. These papers provide the same methodological and experimental foundations and serve as verifiable sources for our findings. We have also reviewed our references to ensure only relevant self-citations remain.
Comment 4
Other irregularities with references are in text: references are cited in bulk (ex.: ref. 1-4 in line 36), not in order (ex.: ref. 25 in line 63 between ref. 15 and ref. 16).
Author Response 4
We thank the reviewer for the observation. While the reference numbering is not fully sequential due to several stages of manuscript revision and restructuring, we have verified that only cited references appear in the reference list and that all in-text citations correspond accurately to the listed sources.
Comment 5
The manuscript body contains numerous indents and/or tabs in middle of sentences (ex.: l. 467, 477, 448, 443 - too many to list all).
Author Response 5
We thank the reviewer for noting the formatting inconsistencies. All unintended indents and tab spaces that appeared within sentences throughout the manuscript have now been carefully reviewed and corrected to ensure consistent formatting and readability.
Comment 6
Y axis numbers on fig. 8 (latency times) are given in milli-seconds and as effect resulting very big numbers, all of them having last 4 digits zeros. It is no justification to load the graphical representation in this way. Units must be changed to seconds. The same applies for the number of messages send on the other axis there again all numbers have at least 3 zeros at the end and the units must be changed to upper multiplier (from kilo to mega).
Response 6
We thank the reviewer for this valuable observation. The Y-axis values in Figure 8 (latency times) and the corresponding axis for the number of messages have been rescaled for clarity. Latency values are now expressed in seconds instead of milliseconds, and message counts are represented in mega (×10⁶) units instead of kilo. These adjustments improve visual readability and prevent unnecessary large numerical labels while preserving the accuracy of the data.
Comment 7
Figure caption is also meaningless ("Figure 8. Latency Comparison") and details must be added. The same applies for Fig. 9. Fig. 9 is not referred in the main text and it must be (and discussed too).
Response 7
We thank the reviewer for this helpful observation. The captions for Figures 8 and 9 have been revised to include detailed descriptions of the experimental setup, parameters, and key observations. Additionally, Figure 9 has now been explicitly referenced and discussed in the main text to clarify its significance and findings.
Comment 8
At Fig. 1 bottom part of the figure legend has been chopped (for g and p dots are missing).
Response 8
We appreciate the reviewer’s observation. However, this comment is not applicable to the current version of the manuscript, as Figure 1 in our submission does not contain any cropped or truncated legend elements.
Comment 9
Fig. 4 and Fig. 5 are text based figures and the pictorial representation must be replaced with text or resolution must be increased (low looks like at 75-150 dpi while publication standard is at 600 dpi).
Resolution for all figures should be increased too (now its at most 300 dpi and it should be increased at at least 600 dpi).
Response 9
We thank the reviewer for this valuable comment. The resolution of Figures 4 and 5 has been enhanced to 600 DPI to meet publication standards and ensure clarity in all textual and graphical elements. Both figures have been carefully reviewed to confirm that all text and symbols are now clearly legible and publication ready. Also, all other figures resolution has been enhanced to 600 dpi.
Comment 10
There is no convention for the names of the math variables. Also, style for the name of variables is changed in the same paragraph (ex. for t₀ and t₁ in lines 598–600).
Response 10
We thank the reviewer for this observation. The variables t₀ and t₁ were introduced only as illustrative examples to explain how latency is measured between the initial message transmission and its final total-order delivery within the cluster. They are not part of the paper’s formal notation system. Nevertheless, the paragraph has been reviewed and edited to ensure consistent formatting and clarity of all variable names throughout the section.
Comment 11
Document type is Article but no clear paragraph stating the research aim is given.
Response 11
We thank the reviewer for this helpful observation. A clear statement of the research aim has now been added at the end of the Introduction section to explicitly highlight the purpose and focus of the study. This paragraph clearly outlines the motivation, problem addressed (Line 93 to 121), and the main contributions of the work in alignment with the journal’s article format.
Comment 12
Something resembling author's contribution is spread in the last part of section 1 and before section 1.1. And the figure referred in this part is to be found somewhere later, on another page.
Response 12
We thank the reviewer for this observation. The figure referenced in this section has now been relocated closer to the corresponding text, ensuring that it appears within view of its first mention. This adjustment improves the logical flow and readability between the contribution discussion and the visual reference.
Comment 13
Conclusions are actually summary and discussions.
Response 13
The Conclusion section has been updated to distinguish the final takeaways of the study from the general discussion of results. The revised conclusion now presents the main findings, contributions, and future research directions in a concise and focused way, in line with the journal’s requirements for article conclusions.
Author Response File: Author Response.pdf
Reviewer 4 Report
Comments and Suggestions for AuthorsThe paper presents a leaderless ring-based total order protocol, termed DCTOP, as an improvement upon the widely studied LCR protocol. The proposed modifications (i) Lamport logical clocks, (ii) dynamically determined "last" processes, and (iii) reduced failure assumptions are well-motivated and convincingly argued. The authors provide simulation-based performance evaluation against both LCR and Raft, showing lower latency and competitive throughput under various workloads.
The abstract could be shortened and made more accessible by focusing on key contributions rather than implementation details.
Abbreviations (UTO, CN, ACN) are used extensively; a consolidated notation table early in the paper would improve readability.
Section 2 (System Model) repeats some information already given in the Introduction; consider condensing.
Simulations are restricted to small group sizes (N ≤ 9) and assume no failures or message loss. While the paper acknowledges this as a limitation, it weakens claims about crash tolerance.
Real-world distributed systems often operate at far larger scales, with heterogeneity and partial failures. The practical applicability of DCTOP remains uncertain until such cases are tested.
The paper is dense and occasionally repetitive. Sections 3.2–3.4 (principles, algorithm, delivery requirements) could be streamlined to improve readability.
Figures (such as Figures 3–6) are referenced but not fully explained in the narrative. Some diagrams are difficult to interpret without extended captions.
The related work section references Paxos, Raft, and others but does not situate DCTOP against more recent leaderless protocols (EPaxos, BPaxos, Multi-Ring Paxos).
Without these comparisons, the paper risks overstating the novelty of its approach.
The discussion on "relaxed failure assumptions" would benefit from explicit comparison to the theoretical lower bounds on consensus/fault tolerance.
Lemmas 1–4 are stated and sketched but not fully formalised. The arguments mix intuitive explanations with partial proof outlines. This may not be sufficient for readers expecting rigorous formal verification.
While fairness control is described, the experimental results focus almost entirely on latency and throughput. Quantitative results (fairness indices, distribution of sending responsibilities) would strengthen the claim.
Comments on the Quality of English LanguageSome grammatical and typographical errors remain. Careful proofreading is needed.
Author Response
Comment 1
The abstract could be shortened and made more accessible by focusing on key contributions rather than implementation details.
Response 1
We thank the reviewer for this constructive suggestion. The abstract has been revised to focus on the key contributions and main findings rather than implementation details. The revised version emphasizes DCTOP’s core innovations, performance outcomes, and impact in a concise and accessible manner.
Comment 2
Abbreviations (UTO, CN, ACN) are used extensively; a consolidated notation table early in the paper would improve readability.
Response 2
We thank the reviewer for this observation. The abbreviations CN and ACN are defined within Section 2 prior to their first usage, while UTO is introduced and defined in Line 359 and Section 3.6 before being used in formal proofs. Given that each term is explained contextually upon introduction, we believe this approach maintains clarity without requiring a separate notation table.
Comment 3
Section 2 (System Model) repeats some information already given in the Introduction; consider condensing.
Response 3
We thank the reviewer for this observation. The System Model section has been reviewed to ensure that only essential definitions and formal descriptions remain. While some overlap with the Introduction is intentional to maintain the paper’s self-containment and support formal reasoning in later sections, redundant explanatory text has been minimized for conciseness and improved readability. Ref: Section 2
Comments 4
Simulations are restricted to small group sizes (N ≤ 9) and assume no failures or message loss. While the paper acknowledges this as a limitation, it weakens claims about crash tolerance. Real-world distributed systems often operate at far larger scales, with heterogeneity and partial failures. The practical applicability of DCTOP remains uncertain until such cases are tested.
Response 4
We appreciate the reviewer’s insightful observation. The simulation was intentionally limited to small group sizes (N ≤ 9) and a failure-free environment to isolate and verify DCTOP’s core ordering and latency mechanisms under controlled conditions before introducing additional system complexities. This approach aligns with standard protocol validation practice, where correctness and baseline performance are first established through discrete-event simulation. We have clearly stated these constraints in the manuscript and clarified that the evaluation of crash tolerance, scalability, and heterogeneity is part of our ongoing and future work, which involves a cloud-based, fault-tolerant implementation of DCTOP. This phased validation approach ensures conceptual soundness prior to full-scale deployment testing. Ref: Lines 697-699
Comment 5
The paper is dense and occasionally repetitive. Sections 3.2–3.4 (principles, algorithm, delivery requirements) could be streamlined to improve readability.
Response 5
We thank the reviewer for this valuable feedback. Sections 3.2–3.4 have been reviewed and revised to improve readability and reduce overlap among related explanations of message flow, stability, and delivery. Repeated procedural descriptions have been merged where appropriate( Section 3.4 was collapse into Section 3.3), and transitions between subsections have been refined to ensure a clearer logical flow. These revisions preserve the algorithm’s completeness and technical precision while improving narrative conciseness.
Comment 6
Figures (such as Figures 3–6) are referenced but not fully explained in the narrative. Some diagrams are difficult to interpret without extended captions.
Response 6
We appreciate the reviewer’s observation. In the revised manuscript, we have enhanced the explanations of Figures 3–6 by explicitly describing their roles and how they relate to the discussed algorithmic steps within the main text. Additionally, we expanded the figure captions to provide clearer context and ensure that each diagram can be understood independently. These improvements make the figures easier to interpret and strengthen their connection to the narrative. Ref: L 355-362
Comment 7
The related work section references Paxos, Raft, and others but does not situate DCTOP against more recent leaderless protocols (EPaxos, BPaxos, Multi-Ring Paxos).Without these comparisons, the paper risks overstating the novelty of its approach.
Response 7
We thank the reviewer for this insightful comment. The Related Work section has been updated to include some of these protocols as also recommended by other reviewers. These protocols are now discussed in relation to DCTOP. The discussion now better situates DCTOP within the evolution of modern leaderless total order and consensus protocols. Ref: Lines 57-93
Comment 8
The discussion on "relaxed failure assumptions" would benefit from explicit comparison to the theoretical lower bounds on consensus/fault tolerance.
Response 8
We appreciate the reviewer’s insightful comment. In the revised manuscript, we have clarified that DCTOP’s relaxed failure assumption (from N = f + 1 to N = 2f + 1) is consistent with the theoretical lower bounds required for consensus in asynchronous systems, as established by classical results such as the FLP impossibility and quorum-based models [37]. The revision explicitly discusses how DCTOP’s approach maintains safety while improving delivery latency within these theoretical limits. This clarification strengthens the conceptual grounding of DCTOP’s fault tolerance model and aligns it with established consensus theory.
Comment 9
Lemmas 1–4 are stated and sketched but not fully formalised. The arguments mix intuitive explanations with partial proof outlines. This may not be sufficient for readers expecting rigorous formal verification.
Response 9
We appreciate the reviewer’s insightful comments. The proof structure for Lemmas 1–4 was deliberately modelled on the semi-formal reasoning approach established in the original Logical Clock and Ring (LCR) protocol [17], ensuring methodological consistency and facilitating direct comparison between DCTOP's correctness arguments and the established framework. These proofs emphasize logical soundness and message delivery properties such as Integrity and Stability, deliberately avoiding excessive formalism since the underlying correctness intuition aligns closely with that of LCR. Furthermore, line references to specific algorithmic steps are included to support clear traceability from theory to implementation.
Comment 10
While fairness control is described, the experimental results focus almost entirely on latency and throughput. Quantitative results (fairness indices, distribution of sending responsibilities) would strengthen the claim.
Response 10
We appreciate the reviewer’s insightful comment. In the current simulation setup, fairness was ensured by configuring each process to send and receive an equal number of messages under uniform transmission intervals (Lines 631-634). This setup guarantees balanced message distribution and equal participation among processes, thereby upholding the fairness control principle described in the protocol. While explicit fairness indices were not plotted, the even message distribution was verified during simulation execution and confirmed through identical send/receive counts across all processes. Future evaluations will include explicit fairness metrics to quantitatively illustrate this property.
Author Response File: Author Response.pdf
Round 2
Reviewer 1 Report
Comments and Suggestions for AuthorsThe paper has been revised by the authors and looks much better now. Most of the issues have been resolved and the overall quality of the paper has been improved but some minor issues are still there - for example, limited literature review/references to prior relevant studies that could contribute to the analysis presented in this research (the list of references is still too short and might need to get extended).
Comments on the Quality of English LanguageEnglish looks fine but a final thorough proofreading of the last version of the manuscript is still recommended.
Author Response
Comment:
The paper has been revised by the authors and looks much better now. Most of the issues have been resolved and the overall quality of the paper has been improved but some minor issues are still there - for example, limited literature review/references to prior relevant studies that could contribute to the analysis presented in this research (the list of references is still too short and might need to get extended).
Response:
We appreciate the kind comments and feedback from the reviewer. Their reviews helped shape the final version of the work making it more acceptable for publication. To answer the question of additional references, we have added four (4) more references considered to be relevant to the topic of discussion. We strongly believe that a total of 42 references in a paper is sufficient and justified to support our claim. In addition, in section 5, we have provided a detailed comparison of our DCTOP to LCR and Raft. We once again appreciate your kind comments and review of our work.
Author Response File: 
Author Response.docx
Reviewer 4 Report
Comments and Suggestions for AuthorsThere is clear evidence that the authors have made a genuine effort to address the reviewers’ comments. As a result, the overall quality of the paper has improved significantly and it is now of publishable standard. I am happy to approve its acceptance, subject to the editor’s final approval.
Author Response
Comment:
There is clear evidence that the authors have made a genuine effort to address the reviewers’ comments. As a result, the overall quality of the paper has improved significantly and it is now of publishable standard. I am happy to approve its acceptance, subject to the editor’s final approval.
Response
We sincerely thank the reviewer for the positive feedback and for recognizing our efforts to improve the manuscript. We are pleased to hear that the revisions have enhanced the quality of the paper and appreciate the reviewer’s recommendation for acceptance.
Author Response File: Author Response.docx
