{"id":"fadd26ed-5123-40f7-bc53-f11755a6d902","arxiv_id":"2508.10141","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"ShellFT enables selective Byzantine fault tolerance at the granularity of individual protocol micro-replicas, reducing diversification costs to 29-46% of baseline compared with full hybrid approaches.","lead":"This paper presents ShellFT, a framework that lets engineers choose which specific steps of a replicated computer system need protection against malicious faults, while leaving the rest protected only against crashes. It demonstrates three example configurations and reports that this selective approach cuts diversification costs by more than 70% compared with traditional hybrid replication.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Unproven compositionality for non-pattern transformations (Appendix L adapted proposer) leaves the 'freely choose shell selections' safety claim under-specified; no proof or fault-injection test covers a committer-shell selection.","rationale":"The reader's weakest assumption correctly identifies the unproved compositionality of ShellFT's pattern-level transformation as the main load-bearing risk. My review sharpens that concern: it is not merely the absence of a general composition theorem, but the presence of a concrete transformation path—the committer-shell adapted proposer in Appendix L—that is neither proven nor evaluated in any instantiation. Since the paper's headline flexibility claim depends on arbitrary user shell selections being safe, this gap is material. However, the paper does provide two proven pattern properties, three concrete instantiations, and empirical fault-injection experiments for the tested selections, and there is no demonstrated counterexample to the compositionality claim. The concern is therefore a condition for full acceptance rather than a demonstrated error, so the reader's CONDITIONAL verdict remains appropriate. A targeted formal check or fault-injection test of the untested committer-shell path would settle whether the concern lands.","tokens_in":31468,"tokens_out":10947,"duration_ms":126678,"concrete_test":"Model the base protocol and the two pattern transformations in TLA+ (or equivalent) for f=1, including the adapted proposer of Appendix L. First verify the SENTRY shell selection (proposer + executor) under a Byzantine proposer and a Byzantine executor concurrently, checking that BP.1 safety holds. Then configure a committer-shell selection not exercised in the paper (Table II path), inject a Byzantine committer during a view change, and check BP.1. If the second check yields a safety violation or a deadlock not present in the crash-only base protocol, the §III-D compositionality assumption is false and the 'freely choose' claim must be restricted to the three evaluated selections.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central generalization claim is that a user can freely select any subset of base-protocol clusters as shell (§III-A) and that the tailoring process preserves safety because pattern-level replacements leave inter-pattern correctness unaffected (§III-D). This compositionality assumption is load-bearing, and it is not established for all shell selections. Appendix A proves only the two isolated patterns (RDP, RP). For the proposer-shell case used by SENTRY/MINAS+SENTRY, the transformation inserts Mirador's agreement stage and changes the proposer/committer interaction; for a committer-shell selection, Table II triggers the 'adapted proposer' in Appendix L, which replaces the VIEW_CHANGE mode with a HISTORY-based legacy-selection function that has no accompanying correctness proof. If that function or the re-composed agreement stage violates the existing inter-pattern invariants (e.g., during view change the chosen legacy does not correspond to a value acknowledged by enough correct committers), BP.1 safety could fail even though the framework reports a 'valid' configuration. Because the paper's flexibility claim requires arbitrary shell selections to be safe, the missing compositional argument is the weakest load-bearing point.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":31759,"tokens_out":2518,"duration_ms":35257,"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":[{"comment":"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","section":"III-D"},{"comment":"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.","section":"Appendix L"},{"comment":"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.","section":"V-A"},{"comment":"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.","section":"VI-B"}],"minor_comments":[{"comment":"Typo: 'changes the the source-cluster size' should read 'changes the source-cluster size'.","section":"III-D"},{"comment":"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.","section":"V-A"},{"comment":"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.","section":"VI-B"},{"comment":"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.","section":"III-B"}],"recommendation":"major_revision","confidential_remarks":"The core idea is timely and the experimental infrastructure is real, but the paper currently overclaims the safety of arbitrary shell selections. The missing proof for the adapted proposer (Appendix L) is the kind of issue that a careful reader will identify immediately, and it is fixable within the scope of the manuscript: either prove the legacy-selection function and the compositionality lemma, or scale back the 'freely choose' claim to the selections that are actually proved and tested. The unweighted cost metric is a second-order concern, but it feeds the headline result and should be addressed to avoid a post-publication corrigendum. I would not reject: the central approach is novel and the empirical work is appropriate; this is a revision, not a rewrite."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's my read. The core idea is genuinely new: apply micro-replication (Mirador) so that each protocol step is its own fault domain, and let the designer pick which domains are Byzantine-tolerant. That's a real step beyond MinBFT, XFT, UpRight, VFT, and SplitBFT, which either hardwire trusted components or use globally scoped thresholds. The three instantiations (MINAS, SENTRY, MINAS+SENTRY) demonstrate the flexibility, and the diversification-cost numbers in Table IV are simple arithmetic from the cluster counts: 29-46% of baseline functionality vs 100% for monolithic hybrids. That part is solid. The N-version LOC measurements in Table V roughly line up with the component-count estimate, which is a decent cross-check.\n\nThe soft spot is real and it's exactly where the stress-test note points. Section III-D asserts that the tailoring process doesn't change how patterns interleave and therefore preserves inter-pattern correctness, but the appendix only proves properties for two patterns: the reliable-distribution pattern (RDP) and the relay pattern (RP). For a committer-shell selection, Table II triggers an 'adapted proposer' in Appendix L that replaces the VIEW_CHANGE mode with a HISTORY-based legacy-selection function, and there is no correctness proof for that function. The framework's headline claim is that users can freely choose shell subsets; that claim rests on the unproven compositionality assumption, and the committer case is the one that uses non-pattern logic. This isn't a demonstrated bug—the adapted proposer looks like a sensible PBFT-style view-change—but the paper should either prove it or scope the flexibility claim.\n\nMinor points: the performance eval reports averages of three runs with no error bars, and no code or data is shipped. Those are addressable.\n\nOverall, the central contribution—per-cluster selective hybridization—holds up as a systems idea. The cost reduction is real under the stated metric. The missing piece is a correctness argument for the full shell-selection space. I would send this to a serious referee, and I would cite it for the per-cluster fault-domain concept. The authors should be asked to close the compositionality gap before the extended version is accepted.","headline":"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.","tokens_in":32167,"tokens_out":3422,"would_cite":true,"duration_ms":39569,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"ShellFT claims that replicated systems can be made Byzantine-tolerant cluster-by-cluster at more than 70% lower diversification cost than traditional hybrids.","keywords":["Byzantine fault tolerance","crash fault tolerance","hybrid fault models","micro replication","state-machine replication","selective diversification","N-version programming","fault domains"],"falsifier":"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.","tokens_in":31385,"feed_emoji":"🛡️","tokens_out":6285,"duration_ms":65030,"temperature":0.7,"pith_summary":"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.","feed_headline":"Cut Byzantine-protection costs by over 70% with selective hardening","feed_subtitle":"ShellFT hardens only chosen clusters of a crash-tolerant protocol; three examples need just 29-46% diversification.","key_machinery":"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.","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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)."],"supporting_citations":[{"why":"Supplies the micro-replication concept of splitting a replication protocol into single-task clusters, the architectural basis ShellFT builds on.","marker":"[23]"},{"why":"Provides the consensus algorithm on which the base protocol's agreement process is modeled.","marker":"[2]"},{"why":"Presents the Paxos variant used as the baseline for the complexity and diversification-cost comparison.","marker":"[35]"},{"why":"Supplies the Byzantine fault-tolerant agreement mechanisms that are substituted into shell clusters.","marker":"[4]"},{"why":"Represents a traditional hybrid approach that ShellFT compares against, one that trades synchrony assumptions for Byzantine tolerance, a trade-off ShellFT avoids.","marker":"[9]"},{"why":"A representative trusted-component hybrid system that motivates ShellFT's goal of configurable trusted/untrusted partitioning.","marker":"[6]"},{"why":"An approach distinguishing fault classes globally, which ShellFT contrasts with its per-cluster granularity.","marker":"[15]"},{"why":"Defines N-version programming, the diversification technique whose cost ShellFT analyzes in Section V.","marker":"[17]"}],"fun_headline_variants":["ShellFT: Selective Byzantine hardening cuts costs by over 70%","Choose your protective shells: ShellFT slashes Byzantine costs","Micro-replication: selective Byzantine tolerance, 70% lower overhead","ShellFT: Custom Byzantine hardening reduces diversification costs","Tailor Byzantine resilience per step, cut costs by over 70%"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["ShellFT: Selective Byzantine hardening cuts costs by over 70%","Choose your protective shells: ShellFT slashes Byzantine costs","Micro-replication: selective Byzantine tolerance, 70% lower overhead","ShellFT: Custom Byzantine hardening reduces diversification costs","Tailor Byzantine resilience per step, cut costs by over 70%"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000602,"raw_usage":{"total_tokens":2609,"prompt_tokens":669,"completion_tokens":1940,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":413,"completion_tokens_details":{"reasoning_tokens":1854}},"tokens_in":413,"tokens_out":1940,"duration_ms":17001,"temperature":1.0,"reasoning_tokens":1854,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T20:36:49.729243+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Micro replication,","cited_arxiv_id":null,"evidence_quote":"Supplies the micro-replication concept of splitting a replication protocol into single-task clusters, the architectural basis ShellFT builds on."},{"cited_title":"The part-time parliament,","cited_arxiv_id":null,"evidence_quote":"Provides the consensus algorithm on which the base protocol's agreement process is modeled."},{"cited_title":"Paxos for system builders: An overview,","cited_arxiv_id":null,"evidence_quote":"Presents the Paxos variant used as the baseline for the complexity and diversification-cost comparison."},{"cited_title":"Practical Byzantine fault tolerance,","cited_arxiv_id":null,"evidence_quote":"Supplies the Byzantine fault-tolerant agreement mechanisms that are substituted into shell clusters."},{"cited_title":"XFT: Practical fault tolerance beyond crashes,","cited_arxiv_id":null,"evidence_quote":"Represents a traditional hybrid approach that ShellFT compares against, one that trades synchrony assumptions for Byzantine tolerance, a trade-off ShellFT avoids."},{"cited_title":"Efficient Byzantine fault tolerance,","cited_arxiv_id":null,"evidence_quote":"A representative trusted-component hybrid system that motivates ShellFT's goal of configurable trusted/untrusted partitioning."},{"cited_title":"UpRight cluster services,","cited_arxiv_id":null,"evidence_quote":"An approach distinguishing fault classes globally, which ShellFT contrasts with its per-cluster granularity."},{"cited_title":"N-version programming: A fault-tolerance approach to reliability of software operation,","cited_arxiv_id":null,"evidence_quote":"Defines N-version programming, the diversification technique whose cost ShellFT analyzes in Section V."}],"review_version":1}