Pith. sign in

REVIEW 4 major objections 4 minor 63 references

Hard Shell, Reliable Core: Improving Resilience in Replicated Systems with Selective Hybridization

T0 review · 4 major / 4 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read ShellFT claims that replicated systems can be made Byzantine-tolerant cluster-by-cluster at more than 70% lower diversification cost than traditional hybrids.

desk verdict Genuinely new per-cluster hybridization idea with a solid cost model, but the 'free shell choice' safety claim needs a correctness argument for the committer-shell case. read the letter →

arxiv 2508.10141 v1 pith:VIWNN7ZU submitted 2025-08-13 cs.DC

Laura Lawniczak , Tobias Distler This is my paper · ORCID
classification cs.DC
keywords Byzantinefaulttolerancecrashhybridmodelsmicroreplicationstate-machineselectivediversificationN-versionprogrammingdomains
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

ShellFT claims that a replicated system's resilience can be selectively hardened by decomposing a crash-tolerant consensus protocol into small clusters, each handling a single protocol step, and converting only chosen clusters to Byzantine fault tolerance. The paper argues that this selective hybridization cuts the cost of diversification (e.g., N-version programming) by more than 70% compared with traditional hybrid systems that harden whole replicas or whole stages. Three example protocols show the range of choices, requiring diversification of only 29%, 33%, and 46% of baseline functionality respectively. If correct, ShellFT gives system designers a configurable trade-off between crash tolerance and Byzantine resilience at near-crash-tolerant resource costs.

What carries the argument

The central machinery is the pattern-based transformation of micro-replicated protocols, specifically the reliable distribution pattern and the relay pattern. A pattern is a small architectural unit with proven safety and liveness properties; ShellFT swaps a crash-tolerant pattern for a Byzantine-tolerant one (e.g., inserting a witness cluster and raising acceptance thresholds) while preserving how patterns are interwoven. This, plus the three-way domain classification of clusters (shell, filter, core) and the automated adjustment of replica counts and thresholds, is what lets selective hybridization be configured without re-deriving protocol correctness from scratch.

What would settle it

Construct a shell selection outside the three presented examples (e.g., select the view-monitor cluster as the only shell) and check by formal verification or fault injection whether a Byzantine view monitor can make correct replicas diverge or cause liveness failure. Alternatively, independently re-implement the base protocol and the three instantiations and verify that a Byzantine fault in any cluster left in the core domain does not violate safety.

Watch

Extended reading notes

Core claim

The paper's central claim is that the level of Byzantine fault tolerance in a replicated protocol can be chosen per protocol step, not per replica or per system. Using micro replication, a crash-tolerant base protocol is split into clusters, each handling a single task; the ShellFT framework lets a designer mark some clusters as 'shell' (Byzantine-tolerant), automatically labels their successors as 'filter' (crash-tolerant but input-checking), and keeps the rest as 'core'. The transformation replaces crash-tolerant design patterns with Byzantine-tolerant counterparts—for example, a reliable distribution pattern gains a witness cluster and a $2f+1$ acceptance threshold—while leaving the inter

Load-bearing premise

The load-bearing premise is that replacing individual patterns does not change how those patterns are interwoven, so the whole protocol's safety and liveness remain intact; the paper proves this for two specific patterns but does not prove compositionality for arbitrary shell selections.

Editorial extensions

If this is right

  • Designers can tailor a replicated system's threat model per cluster, for example protecting only client-facing clusters, and still obtain Byzantine resilience at those entry points.
  • The diversification cost stays roughly constant as the tolerated fault count grows: the percentage of functionality needing diversification changes only slightly from $f=1$ to large $f$.
  • ShellFT protocols remain safe during network partitions because they do not trade away asynchrony tolerance, unlike approaches that relax synchrony assumptions.
  • The three instantiations confirm that different shell-selection criteria (perimeter exposure and safety-criticality) can be combined in one protocol without architectural change.
  • The cost-reduction claim is confirmed both analytically (by counting diversified micro-replica components) and empirically (by measuring the code size of N-version implementations of shell clusters).

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the pattern-level transformation composes correctly for arbitrary shell selections, the same recipe (witness insertion, threshold bumps) could be applied to other micro-replicated base protocols, making selective hybridization a general design pattern rather than a one-off mechanism.
  • The cost model treats every cluster as equally complex; in practice, shell clusters may be among the most complex parts of a protocol, so the actual monetary savings from N-version programming could differ from the reported 70% depending on which clusters are placed in the shell.
  • The safety argument currently rests on proofs for two specific patterns plus an unproven compositionality assumption, so any new shell selection should be validated independently; a formal composition theorem would close this gap.
  • The physical isolation of the shell group creates a trust boundary that could be combined with geographic separation, potentially extending ShellFT to geo-replicated deployments.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper presents ShellFT, a framework for selectively hybridizing replicated systems at the granularity of micro-replica clusters. The base protocol is a crash-tolerant Paxos-style protocol decomposed into eight clusters; the user designates some clusters as Byzantine-tolerant 'shell' domains, and the framework automatically classifies remaining clusters as filters or cores, adjusts cluster sizes and acceptance thresholds, and substitutes selected protocol mechanisms with counterparts from the Byzantine-tolerant Mirador protocol. The paper claims that this enables system designers to freely choose which protocol parts require Byzantine resilience, and that the resulting diversification cost is reduced by more than 70% compared with traditional hybridization. Three instantiations are presented (MINAS, SENTRY, MINAS+SENTRY), together with a complexity analysis, N-version programming code-size measurements, and a performance/fault-handling evaluation against base protocol, Mirador, and BFT-SMaRt.

Significance. If the central correctness claim holds, ShellFT is a genuinely useful contribution: it moves hybridization from hardwired trusted components or global fault-class thresholds to a per-protocol-task, user-configurable choice, and it quantifies a large reduction in the code that must be diversified. The three instantiations are well chosen and demonstrate that the framework can express meaningfully different threat models. The paper also ships concrete prototype implementations and reports both performance and fault-injection results, which support the feasibility of the approach. The main weakness is that the central safety claim rests on an unproven compositionality assumption for arbitrary shell selections, and one of the Table II transformations (the 'adapted proposer' for a shell committer) is presented without a correctness proof or experimental validation. The cost-reduction claim is also based on an unweighted component-count metric, though the LOC-based second analysis provides partial corroboration.

major comments (4)
  1. [III-D] The load-bearing compositionality assumption is stated but not proved. The paper asserts that pattern-level substitutions 'do not change how individual patterns are interweaved' and therefore leave 'inter-pattern correctness arguments unaffected,' but Appendix A proves properties only for the two isolated patterns (RDP and RP). Since the user is promised freedom to select any subset of clusters as shell (Table II includes front end, proposer, committer, executor, all three monitors, controller), the safety of arbitrary combinations is not established. In particular, a committer-shell selection changes the proposer/committer interaction in a non-local way (Appendix L), so the compositionality claim is not self-evident. The paper should either prove compositionality for the full set of Table II transformations or explicitly restrict the flexibility claim to the selections that are proved/f
  2. [Appendix L] The adapted proposer for a shell committer has no correctness argument. The HISTORY.legacy() function replaces the VIEW_CHANGE mode and selects a legacy value by sorting committer reports by view and counting acknowledgments; it is not shown that this selection matches the value that Mirador's curator/auditor would certify, nor that it preserves BP.1 when some committers are Byzantine. If the selected legacy does not correspond to a value accepted by f+1 correct committers, or if the function returns a value before enough reports are available, the system could violate safety during view change even though the framework reports a valid configuration. A proof or, at minimum, fault-injection coverage of a committer-shell configuration is needed before the 'freely choose' claim can be accepted.
  3. [V-A] The headline reduction of 'more than 70%' is computed from an unweighted component-count metric that treats all eight protocol tasks as equally complex. The authors acknowledge this simplification, but Table IV's percentages (29%, 33%, 46%) are the quantitative basis of the central cost claim. The LOC study in Section V-B supports the conclusion for the specific clusters diversified in MINAS and SENTRY, but it does not validate the general metric for all shell selections, nor does it weight tasks such as the adapted proposer or the agreement-stage substitutions. The paper should either justify the equal-complexity assumption more rigorously, provide a sensitivity analysis, or present the cost reduction as conditional on that assumption.
  4. [VI-B] The fault-handling evaluation covers proposer crash, Byzantine proposer, and Byzantine executor scenarios, but it does not exercise a committer-shell configuration or any arbitrary combination beyond the three presented instances. Since the framework's flexibility claim extends to all Table II selections, the absence of any test for the committer-shell case (which triggers the unproved Appendix L transformation) leaves the most safety-critical configuration empirically unvalidated. Adding at least one fault-injection scenario for a committer-shell or a monitor-shell selection would substantially strengthen the paper.
minor comments (4)
  1. [III-D] Typo: 'changes the the source-cluster size' should read 'changes the source-cluster size'.
  2. [V-A] The baseline row of Table IV labels the base protocol as 'Baseline' and reports 16f+8 components. The percentage for Mirador (192% at f=1) may surprise readers because it exceeds 100%; a sentence explaining that the denominator is the crash-tolerant baseline, not the BFT protocol, would help.
  3. [VI-B] Figure 9 shows a 'Byzantine-faulty Proposer' panel for the base protocol and MINAS, but the text says these protocols diverge; the figure would be clearer if the diverging state or the recovery mechanism were explicitly annotated, rather than only showing throughput.
  4. [III-B] The statement that micro replication 'has only been investigated in the context of improving debuggability' (Section VII) is slightly inconsistent with the earlier citation of Mirador as an existing micro-replicated BFT protocol; consider clarifying that Mirador is the prior work in this space, and ShellFT is the first to use it for selective hybridization.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the headline cost reduction is arithmetic from component counts, and the Mirador dependency is component reuse rather than a fitted input or self-justifying uniqueness claim.

full rationale

The paper's central quantitative claim—that ShellFT decreases diversification costs by more than 70% compared with traditional hybridization—is not circular. It is computed directly from the component counts in Table IV: for MINAS, the shell contains 5f+2 micro-replicas out of a baseline of 16f+8, giving 29%; the other protocols are analogous ratios. There are no fitted parameters, no calibrated thresholds, and no prediction that is tuned to match an observed outcome. The reliance on Mirador is a real self-citation (Mirador is prior work by overlapping authors, and ShellFT uses Mirador's agreement stage and cluster patterns), but it is not circular in the derivation sense: the crash-tolerant base protocol is fully specified in Appendix B, the tailoring actions for each shell selection are enumerated in Table II, and Appendix A supplies proofs for the two principal pattern transformations. The paper does not invoke Mirador as a uniqueness theorem or as an unexamined premise that makes the conclusion true by definition. The more substantive weakness is that Section III-D asserts that pattern-level substitutions preserve inter-pattern correctness for arbitrary shell selections, while Appendix A proves only the two isolated patterns and Appendix L's adapted proposer for a shell committer has no dedicated correctness proof. That is a completeness/soundness concern, not circularity: no equation or constructed quantity reduces to its own input, and no fitted value is renamed as a prediction. The self-citation is present but not load-bearing in the circularity sense, so the appropriate score is at the low end of the scale.

Assumptions & free parameters 0 free parameters · 6 assumptions · 0 invented entities

The central claims rest on standard distributed-systems assumptions (partial synchrony, authenticated channels), on the previously published Mirador protocol, and on the paper-specific assumption that pattern-level transformations compose safely. The diversification-cost reduction additionally relies on an equal-complexity approximation. No fitted free parameters or newly invented physical entities are used.

assumptions (6)
  • domain assumption Partial synchrony for liveness (Dwork et al. [63])
    Invoked in Appendix B-A: liveness of the base protocol and thus of ShellFT protocols depends on sufficiently long synchronous periods; safety holds regardless.
  • domain assumption Correctness of Mirador as a Byzantine-fault-tolerant micro-replicated protocol
    Used in Section III-C and Table II: ShellFT substitutes Mirador counterparts for shell clusters; if Mirador's correctness does not hold, transformed ShellFT protocols inherit the flaw. Mirador is prior work by the same group.
  • ad hoc to paper Pattern-level substitution preserves inter-pattern correctness
    Section III-D asserts that replacing patterns without changing interweaving leaves correctness arguments unaffected; no proof is provided beyond the two individual pattern proofs in Appendix A.
  • domain assumption Authenticated communication in the base protocol
    Section III-B: the base protocol uses authenticated messages to prevent impersonation by Byzantine replicas; this assumes cryptographic authentication is available.
  • ad hoc to paper Equal complexity of protocol tasks for the diversification-cost metric
    Section V-A states simplifying assumption (1): all protocol tasks are treated as similarly complex when counting diversification cost; the LOC study partially checks this.
  • domain assumption Physical isolation of shell machines prevents cross-domain compromise
    Section III-A deployment: shell clusters run on a separate machine group; if an adversary compromises a shell machine, filter and core replicas remain unaffected. This assumes no escape from the machine boundary.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Hard Shell, Reliable Core: Improving Resilience in Replicated Systems with Selective Hybridization." pith.science (2026). https://pith.science/paper/VIWNN7ZU

@misc{pith2026250810141,
  author       = {Pith},
  title        = {Pith review of: Hard Shell, Reliable Core: Improving Resilience in Replicated Systems with Selective Hybridization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VIWNN7ZU}},
  note         = {Machine review of arXiv:2508.10141}
}
read the original abstract

Hybrid fault models are known to be an effective means for enhancing the robustness of consensus-based replicated systems. However, existing hybridization approaches suffer from limited flexibility with regard to the composition of crash-tolerant and Byzantine fault-tolerant system parts and/or are associated with a significant diversification overhead. In this paper we address these issues with ShellFT, a framework that leverages the concept of micro replication to allow system designers to freely choose the parts of the replication logic that need to be resilient against Byzantine faults. As a key benefit, such a selective hybridization makes it possible to develop hybrid solutions that are tailored to the specific characteristics and requirements of individual use cases. To illustrate this flexibility, we present three custom ShellFT protocols and analyze the complexity of their implementations. Our evaluation shows that compared with traditional hybridization approaches, ShellFT is able to decrease diversification costs by more than 70%.

Figures

Figures reproduced from arXiv: 2508.10141 by the authors.

Figure 1
Figure 1. State-machine replication architectures. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. Base protocol. Although the base protocol is executable on its own, we did not concentrate on optimizing for such a scenario. Instead, our primary focus was to create a parameterized template protocol that the SHELLFT framework can use to support selective hybridization. With the resulting tailored protocol later potentially being subject to Byzantine faults, this for example means that replicas in the base protocol… view at source ↗
Figure 2
Figure 2. Overview of the SHELLFT tailoring process. Client f+1 replicas 2f+1 replicas Front End Proposer Committer Executor Agreement Monitor Completion Monitor Controller View Monitor [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Group-based deployment on separate sets of machines. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Transformation based on design patterns. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Overview of the MINAS system architecture; some cluster dependencies have been omitted for better readability [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Overview of the SENTRY system architecture; some cluster dependencies have been omitted for better readability. To summarize, in SENTRY’s architecture the base protocol’s proposer functionality is divided among two clusters, with the SENTRY proposer handling the main r…
Figure 8
Figure 8. Figure 8: Performance comparison [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Impact of different fault scenarios. Leader Crash. As the consequence of a crash of the cur￾rent proposer, all three SHELLFT protocols experience the expected downtime of 1–2 s and resume a stable performance after the successful view change. The view change in MINAS i…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

63 extracted references · 61 canonical work pages

  1. [1]

    Hard shell, reliable core: Improving resilience in replicated systems with selective hybridization,

    L. Lawniczak and T. Distler, “Hard shell, reliable core: Improving resilience in replicated systems with selective hybridization,” in Pro- ceedings of the 44th International Symposium on Reliable Distributed Systems (SRDS ’25) , 2025

    work page 2025

  2. [2]

    The part-time parliament,

    L. Lamport, “The part-time parliament,” ACM Transactions on Computer Systems, vol. 16, no. 2, pp. 133–169, 1998

    work page 1998

  3. [3]

    In search of an understandable consensus algorithm,

    D. Ongaro and J. Ousterhout, “In search of an understandable consensus algorithm,” in Proceedings of the 2014 USENIX Annual Technical Conference (USENIX ATC ’14), 2014, pp. 305–320

    work page 2014

  4. [4]

    Practical Byzantine fault tolerance,

    M. Castro and B. Liskov, “Practical Byzantine fault tolerance,” in Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI ’99), 1999, pp. 173–186

    work page 1999

  5. [5]

    Byzantine fault-tolerant state-machine replication from a systems perspective,

    T. Distler, “Byzantine fault-tolerant state-machine replication from a systems perspective,” ACM Computing Surveys , vol. 54, no. 1, 2021

    work page 2021

  6. [6]

    Efficient Byzantine fault tolerance,

    G. S. Veronese, M. Correia, A. N. Bessani, L. C. Lung, and P. Ver´ıssimo, “Efficient Byzantine fault tolerance,” IEEE Transactions on Computers , vol. 62, no. 1, pp. 16–30, 2011

    work page 2011

  7. [7]

    CheapBFT: Resource-efficient Byzantine fault tolerance,

    R. Kapitza, J. Behl, C. Cachin, T. Distler, S. Kuhnle, S. V . Mohammadi, W. Schr¨oder-Preikschat, and K. Stengel, “CheapBFT: Resource-efficient Byzantine fault tolerance,” in Proceedings of the 7th European Confer- ence on Computer Systems (EuroSys ’12) , 2012, pp. 295–308

    work page 2012

  8. [8]

    Resource-efficient Byzantine fault tolerance,

    T. Distler, C. Cachin, and R. Kapitza, “Resource-efficient Byzantine fault tolerance,” IEEE Transactions on Computers , vol. 65, no. 9, pp. 2807–2819, 2016

    work page 2016

Show all 63 references
  1. [9]

    XFT: Practical fault tolerance beyond crashes,

    S. Liu, P. Viotti, C. Cachin, V . Quema, and M. Vukoli ´c, “XFT: Practical fault tolerance beyond crashes,” in Proceedings of the 12th Symposium on Operating Systems Design and Implementation (OSDI ’16), 2016, pp. 485–500

    2016

  2. [10]

    Hybrids on steroids: SGX-based high performance BFT,

    J. Behl, T. Distler, and R. Kapitza, “Hybrids on steroids: SGX-based high performance BFT,” in Proceedings of the 12th European Conference on Computer Systems (EuroSys ’17), 2017, pp. 222–237

    2017

  3. [11]

    DAMYSUS: Stream- lined BFT consensus leveraging trusted components,

    J. Decouchant, D. Kozhaya, V . Rahli, and J. Yu, “DAMYSUS: Stream- lined BFT consensus leveraging trusted components,” in Proceedings of the 17th European Conference on Computer Systems (EuroSys ’22) , 2022, pp. 1–16

    2022

  4. [12]

    SplitBFT: Improving Byzantine fault tolerance safety using trusted compartments,

    I. Messadi, M. H. Becker, K. Bleeke, L. Jehl, S. B. Mokhtar, and R. Kapitza, “SplitBFT: Improving Byzantine fault tolerance safety using trusted compartments,” in Proceedings of the 23rd Middleware Conference (Middleware ’22), 2022, pp. 56–68

    2022

  5. [13]

    Low complexity Byzantine-resilient consensus,

    M. Correia, N. F. Neves, L. C. Lung, and P. Ver ´ıssimo, “Low complexity Byzantine-resilient consensus,” Distributed Computing , vol. 17, no. 3, pp. 237–249, 2005

    2005

  6. [14]

    Attested append-only memory: Making adversaries stick to their word,

    B.-G. Chun, P. Maniatis, S. Shenker, and J. Kubiatowicz, “Attested append-only memory: Making adversaries stick to their word,” in Proceedings of the 21st Symposium on Operating Systems Princi- ples (SOSP ’07), 2007, pp. 189–204

    2007

  7. [15]

    UpRight cluster services,

    A. Clement, M. Kapritsos, S. Lee, Y . Wang, L. Alvisi, M. Dahlin, and T. Riche, “UpRight cluster services,” in Proceedings of the 22nd Symposium on Operating Systems Principles (SOSP ’09), 2009, pp. 277– 290

    2009

  8. [16]

    Visigoth fault tolerance,

    D. Porto, J. Leit ˜ao, C. Li, A. Clement, A. Kate, F. Junqueira, and R. Rodrigues, “Visigoth fault tolerance,” in Proceedings of the 10th European Conference on Computer Systems (EuroSys ’15) , 2015, pp. 8:1–8:14

    2015

  9. [17]

    N-version programming: A fault-tolerance approach to reliability of software operation,

    L. Chen and A. Avi ˇzienis, “N-version programming: A fault-tolerance approach to reliability of software operation,” in Proceedings of 8th International Symposium on Fault-Tolerant Computing (FTCS-8), 1978, pp. 3–9

    1978

  10. [18]

    Making Byzantine fault tolerant systems tolerate Byzantine faults,

    A. Clement, E. Wong, L. Alvisi, M. Dahlin, and M. Marchetti, “Making Byzantine fault tolerant systems tolerate Byzantine faults,” in Pro- ceedings of the 6th Symposium on Networked Systems Design and Implementation (NSDI ’09), 2009, pp. 153–168

    2009

  11. [19]

    Implementing fault-tolerant services using the state machine approach: A tutorial,

    F. B. Schneider, “Implementing fault-tolerant services using the state machine approach: A tutorial,” ACM Computer Survey , vol. 22, no. 4, pp. 299–319, 1990

    1990

  12. [20]

    Separating agreement from execution for Byzantine fault tolerant services,

    J. Yin, J.-P. Martin, A. Venkataramani, L. Alvisi, and M. Dahlin, “Separating agreement from execution for Byzantine fault tolerant services,” in Proceedings of the 19th Symposium on Operating Systems Principles (SOSP ’03), 2003, pp. 253–267

    2003

  13. [21]

    Resilient cloud-based replication with low latency,

    M. Eischer and T. Distler, “Resilient cloud-based replication with low latency,” in Proceedings of the 21st Middleware Conference (Middle- ware ’20), 2020, pp. 14–28

    2020

  14. [22]

    Scaling replicated state machines with compartmentalization,

    M. Whittaker, A. Ailijiang, A. Charapko, M. Demirbas, N. Giridharan, J. M. Hellerstein, H. Howard, I. Stoica, and A. Szekeres, “Scaling replicated state machines with compartmentalization,” Proceedings of the VLDB Endowment , vol. 14, no. 11, pp. 2203–2215, 2021

    2021

  15. [23]

    Micro replication,

    T. Distler, M. Eischer, and L. Lawniczak, “Micro replication,” in Pro- ceedings of the 53rd International Conference on Dependable Systems and Networks (DSN ’23), 2023, pp. 123–137

    2023

  16. [24]

    BFTW³: Why? When? Where? Work- shop on the theory and practice of Byzantine fault tolerance,

    P. Kuznetsov and R. Rodrigues, “BFTW³: Why? When? Where? Work- shop on the theory and practice of Byzantine fault tolerance,” SIGACT News, vol. 40, no. 4, pp. 82–86, 2009

    2009

  17. [25]

    HQ replication: A hybrid quorum protocol for Byzantine fault tolerance,

    J. Cowling, D. Myers, B. Liskov, R. Rodrigues, and L. Shrira, “HQ replication: A hybrid quorum protocol for Byzantine fault tolerance,” in Proceedings of the 7th Symposium on Operating Systems Design and Implementation (OSDI ’06), 2006, pp. 177–190

    2006

  18. [26]

    Hybrid consensus: Efficient consensus in the per- missionless model,

    R. Pass and E. Shi, “Hybrid consensus: Efficient consensus in the per- missionless model,” in Proceedings of the 31st International Symposium on Distributed Computing (DISC ’17) , 2017, pp. 39:1–39:16

    2017

  19. [27]

    Making intrusion tolerance accessible: A cloud-based hybrid management approach to deploying resilient sys- tems,

    M. Khan and A. Babay, “Making intrusion tolerance accessible: A cloud-based hybrid management approach to deploying resilient sys- tems,” in Proceedings of the 42nd International Symposium on Reliable Distributed Systems (SRDS ’23), 2023, pp. 254–267

    2023

  20. [28]

    Failure detection and randomization: A hybrid approach to solve consensus,

    M. K. Aguilera and S. Toueg, “Failure detection and randomization: A hybrid approach to solve consensus,” SIAM Journal on Computing , vol. 28, no. 3, pp. 890–903, 1998

    1998

  21. [29]

    Hypervisor-based efficient proactive recovery,

    H. P. Reiser and R. Kapitza, “Hypervisor-based efficient proactive recovery,” in Proceedings of the 26th International Symposium on Reliable Distributed Systems (SRDS ’07) , 2007, pp. 83–92

    2007

  22. [30]

    SPARE: Replicas on hold,

    T. Distler, R. Kapitza, I. Popov, H. P. Reiser, and W. Schr¨oder-Preikschat, “SPARE: Replicas on hold,” in Proceedings of the 18th Network and Distributed System Security Symposium (NDSS ’11), 2011, pp. 407–420

    2011

  23. [31]

    TrInc: Small trusted hardware for large distributed systems,

    D. Levin, J. R. Douceur, J. R. Lorch, and T. Moscibroda, “TrInc: Small trusted hardware for large distributed systems,” in Proceedings of the 6th Symposium on Networked Systems Design and Implementa- tion (NSDI ’09), 2009, pp. 1–14

    2009

  24. [32]

    Vivisecting the dissection: On the role of trusted components in BFT protocols,

    A. Bessani, M. Correia, T. Distler, R. Kapitza, P. Esteves-Ver ´ıssimo, and J. Yu, “Vivisecting the dissection: On the role of trusted components in BFT protocols,” CoRR, vol. abs/2312.05714, 2023

    2023 arXiv

  25. [33]

    Highly available intrusion-tolerant services with proactive-reactive re- covery,

    P. Sousa, A. N. Bessani, M. Correia, N. F. Neves, and P. Ver ´ıssimo, “Highly available intrusion-tolerant services with proactive-reactive re- covery,”IEEE Transactions on Parallel and Distributed Systems, vol. 21, no. 4, pp. 452–465, 2010

    2010

  26. [34]

    Interactive consistency with multiple failure modes,

    P. Thambidurai and Y .-K. Park, “Interactive consistency with multiple failure modes,” in Proceedings of the 7th International Symposium on Reliable Distributed Systems (SRDS ’88) , 1988, pp. 93–100

    1988

  27. [35]

    Paxos for system builders: An overview,

    J. Kirsch and Y . Amir, “Paxos for system builders: An overview,” in Proceedings of the 2nd Workshop on Large-Scale Distributed Systems and Middleware (LADIS ’08), 2008, pp. 14–18

    2008

  28. [36]

    On designing depend- able services with diverse off-the-shelf SQL servers,

    I. Gashi, P. Popov, V . Stankovic, and L. Strigini, “On designing depend- able services with diverse off-the-shelf SQL servers,” in Architecting Dependable Systems II , 2004, pp. 191–214

    2004

  29. [37]

    Anal- ysis of operating system diversity for intrusion tolerance,

    M. Garcia, A. Bessani, I. Gashi, N. Neves, and R. Obelheiro, “Anal- ysis of operating system diversity for intrusion tolerance,” Software— Practice & Experience , vol. 44, no. 6, pp. 735–770, 2014

    2014

  30. [38]

    Lazarus: Automatic management of diversity in BFT systems,

    M. Garcia, A. Bessani, and N. Neves, “Lazarus: Automatic management of diversity in BFT systems,” in Proceedings of the 20th International Middleware Conference (Middleware ’19), 2019, pp. 241–254

    2019

  31. [39]

    Gal´apagos: Automated N-version programming with LLMs,

    J. Ron, D. Gaspar, J. Cabrera-Arteaga, B. Baudry, and M. Monperrus, “Gal´apagos: Automated N-version programming with LLMs,” arXiv preprint arXiv:2408.09536, 2024

    2024

  32. [40]

    A network perimeter with secure external access,

    F. M. Avolio, M. J. Ranum, and M. Glenwood, “A network perimeter with secure external access,” in Proceedings of the 1st Network and Distributed System Security Symposium (NDSS ’94), 1994, pp. 109–119

    1994

  33. [41]

    Software-defined perimeter (SDP): State of the art secure solution for modern networks,

    A. Moubayed, A. Refaey, and A. Shami, “Software-defined perimeter (SDP): State of the art secure solution for modern networks,” IEEE Network, vol. 33, no. 5, pp. 226–233, 2019

    2019

  34. [42]

    Steward: Scaling Byzantine fault-tolerant replication to wide area networks,

    Y . Amir, C. Danilov, D. Dolev, J. Kirsch, J. Lane, C. Nita-Rotaru, J. Olsen, and D. Zage, “Steward: Scaling Byzantine fault-tolerant replication to wide area networks,” IEEE Transactions on Dependable and Secure Computing , vol. 7, no. 1, pp. 80–93, 2010

    2010

  35. [43]

    Windows Azure Storage: A highly available cloud storage service with strong consistency,

    B. Calder, J. Wang, A. Ogus, N. Nilakantan, A. Skjolsvold, S. McKelvie, Y . Xu, S. Srivastav, J. Wu, H. Simitci, J. Haridas, C. Uddaraju, H. Khatri, A. Edwards, V . Bedekar, S. Mainali, R. Abbasi, A. Agarwal, M. F. ul Haq, M. I. ul Haq, D. Bhardwaj, S. Dayanand, A. Adusumilli,...

    2011

  36. [44]

    A formal approach to network segmentation,

    N. Mhaskar, M. Alabbad, and R. Khedri, “A formal approach to network segmentation,” Computers & Security , vol. 103, 2021

    2021

  37. [45]

    Software- defined networking (SDN): A survey,

    K. Benzekki, A. El Fergougui, and A. Elbelrhiti Elalaoui, “Software- defined networking (SDN): A survey,” Security and Communication Networks, vol. 9, no. 18, pp. 5803–5833, 2016

    2016

  38. [46]

    Network intrusion detection,

    B. Mukherjee, L. T. Heberlein, and K. N. Levitt, “Network intrusion detection,” IEEE Network, vol. 8, no. 3, pp. 26–41, 1994

    1994

  39. [47]

    Quantitative comparison of unsupervised anomaly detection algorithms for intrusion detection,

    F. Falc ˜ao, T. Zoppi, C. B. V . Silva, A. Santos, B. Fonseca, A. Ceccarelli, and A. Bondavalli, “Quantitative comparison of unsupervised anomaly detection algorithms for intrusion detection,” in Proceedings of the 34th Symposium on Applied Computing (SAC ’19) , 2019, pp. 318–327

    2019

  40. [48]

    Establishing a zero trust strategy in cloud computing environment,

    S. Mehraj and M. T. Banday, “Establishing a zero trust strategy in cloud computing environment,” in Proceedings of the 12th International Conference on Computer Communication and Informatics (ICCCI ’20) , 2020, pp. 1–6

    2020

  41. [49]

    Insider threats to cloud computing: Directions for new research challenges,

    W. R. Claycomb and A. Nicoll, “Insider threats to cloud computing: Directions for new research challenges,” in Proceedings of the 36th An- nual Computer Software and Applications Conference (COMPSAC ’12), 2012, pp. 387–394

    2012

  42. [50]

    Elixir, https://elixir-lang.org/, last accessed November 2024

    2024

  43. [51]

    cloc – count lines of code,

    A. Danial, “cloc – count lines of code,” https://github.com/AlDanial/cloc, last accessed November 2024

    2024

  44. [52]

    State machine replication for the masses with BFT-SMaRt,

    A. Bessani, J. Sousa, and E. E. P. Alchieri, “State machine replication for the masses with BFT-SMaRt,” in Proceedings of the 44th International Conference on Dependable Systems and Networks (DSN ’14) , 2014, pp. 355–362

    2014

  45. [53]

    Benchmarking cloud serving systems with YCSB,

    B. F. Cooper, A. Silberstein, E. Tam, R. Ramakrishnan, and R. Sears, “Benchmarking cloud serving systems with YCSB,” in Proceedings of the 1st Symposium on Cloud Computing (SoCC ’10), 2010, pp. 143–154

    2010

  46. [54]

    PigPaxos: Devouring the communication bottlenecks in distributed consensus,

    A. Charapko, A. Ailijiang, and M. Demirbas, “PigPaxos: Devouring the communication bottlenecks in distributed consensus,” in Proceedings of the 2021 International Conference on Management of Data (SIG- MOD ’21), 2021, pp. 235–247

    2021

  47. [55]

    FlexCast: Genuine overlay-based atomic multicast,

    E. Batista, P. Coelho, E. Alchieri, F. Dotti, and F. Pedone, “FlexCast: Genuine overlay-based atomic multicast,” in Proceedings of the 24th Middleware Conference (Middleware ’23), 2023, pp. 288––300

    2023

  48. [56]

    Back to the future: N-Versioning of microservices,

    A. M. Espinoza, R. Wood, S. Forrest, and M. Tiwari, “Back to the future: N-Versioning of microservices,” in Proceedings of the 52nd In- ternational Conference on Dependable Systems and Networks (DSN ’22), 2022, pp. 415–427

    2022

  49. [57]

    Geographic state machine replication,

    P. Coelho and F. Pedone, “Geographic state machine replication,” in Pro- ceedings of the 37th International Symposium on Reliable Distributed Systems (SRDS ’18), 2018, pp. 221–230

    2018

  50. [58]

    GeoPaxos+: Practical geographical state ma- chine replication,

    P. Coelho and F. Pedone, “GeoPaxos+: Practical geographical state ma- chine replication,” in Proceedings of the 40th International Symposium on Reliable Distributed Systems (SRDS ’21) , 2021, pp. 233–243

    2021

  51. [59]

    State-machine replication for planet-scale systems,

    V . Enes, C. Baquero, T. F. Rezende, A. Gotsman, M. Perrin, and P. Sutra, “State-machine replication for planet-scale systems,” in Proceedings of the 15th European Conference on Computer Systems (EuroSys ’20) , 2020, pp. 1–15

    2020

  52. [60]

    Threat adaptive Byzantine fault tolerant state-machine repli- cation,

    D. S. Silva, R. Graczyk, J. Decouchant, M. V ¨olp, and P. Esteves- Verissimo, “Threat adaptive Byzantine fault tolerant state-machine repli- cation,” in Proceedings of the 40th International Symposium on Reliable Distributed Systems (SRDS ’21), 2021, pp. 78–87

    2021

  53. [61]

    Practical hard- ening of crash-tolerant systems,

    M. Correia, D. G. Ferro, F. P. Junqueira, and M. Serafini, “Practical hard- ening of crash-tolerant systems,” in Proceedings of the 2012 USENIX Annual Technical Conference (USENIX ATC ’12) , 2012, pp. 453–466

    2012

  54. [62]

    HardPaxos: Replication hard- ened against hardware errors,

    D. Behrens, D. Kuvaiskii, and C. Fetzer, “HardPaxos: Replication hard- ened against hardware errors,” in Proceedings of the 33rd International Symposium on Reliable Distributed Systems (SRDS ’14) , 2014, pp. 232– 241

    2014

  55. [63]

    Consensus in the presence of partial synchrony,

    C. Dwork, N. Lynch, and L. Stockmeyer, “Consensus in the presence of partial synchrony,” Journal of the ACM , vol. 35, no. 2, 1988. APPENDIX A PROOFS As explained in Section III-D, S HELL FT’s protocol trans- formation process exchanges architectural patterns from the crash-to...

    1988

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.