Pith. sign in

REVIEW 2 major objections 2 minor 95 references

Chimera: Protocol-Aware Recovery for Confidential BFT Consensus

T0 review · 2 major / 2 minor · reviewed 2026-06-27 · grok-4.3

Pith's one-line read CHIMERA recovers confidential BFT consensus by applying distinct mechanisms to metadata and logs based on their protocol properties.

desk verdict Chimera's metadata/log split gives measurable gains on the rollback tradeoff in TEE BFT, but the safety case rests on whether the Maude model actually captures cross-dependencies. read the letter →

arxiv 2606.09101 v2 pith:J446QIA6 submitted 2026-06-08 cs.DC

classification cs.DC
keywords confidentialBFTconsensusTEErollbackprotectionprotocol-awarerecoverymetadataandlogsseparationstatecontinuityrollback-resilient
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

The paper establishes that uniform rollback protection creates a performance-availability tradeoff in TEE-based confidential BFT consensus. It shows that persistent states differ fundamentally in distribution, update behavior, and representation form, so a single recovery method is not optimal. CHIMERA therefore separates states into metadata and logs and applies tailored recovery to each category. The approach is formally modeled and verified for safety and liveness, then implemented on Braft and ZooKeeper with Intel TDX. Evaluation in LAN and WAN settings demonstrates higher throughput, lower recovery latency, and better availability than prior rollback-resilient methods.

What carries the argument

Separation of persistent state into metadata and logs, with distinct recovery mechanisms applied according to protocol-level properties of distribution, update behavior, and representation.

What would settle it

A concrete rollback attack that succeeds on the separated states and violates consensus safety, or a performance measurement in the evaluated Braft and ZooKeeper implementations showing no improvement in throughput or recovery latency over the uniform baselines.

Watch

Extended reading notes

Core claim

CHIMERA is a protocol-aware recovery framework that separates persistent state into metadata and logs according to their differing state distribution, update behavior, and representation form, then applies distinct recovery mechanisms to each type, thereby breaking the tradeoff between overhead on the critical path and prolonged recovery delays while preserving safety and liveness.

Load-bearing premise

Persistent states in confidential BFT consensus can be cleanly separated into metadata and logs whose differing properties allow distinct recovery mechanisms without introducing new safety violations.

Editorial extensions

If this is right

  • Throughput on the critical consensus path increases because only metadata receives the heavier protection.
  • Recovery latency after enclave crashes decreases because logs use a lighter mechanism.
  • Availability improves because the system returns to operation faster without sacrificing safety or liveness.
  • The same separation principle applies across different consensus libraries once states are classified by protocol properties.

Reading between the lines

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

  • The classification of states by distribution and update frequency may apply to other TEE-protected distributed protocols beyond BFT consensus.
  • Implementations could test whether the metadata-log split remains valid when new consensus features such as dynamic membership are added.
  • If the separation holds, similar differentiated recovery could reduce overhead in non-TEE settings where partial state persistence is also a concern.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

2 major / 2 minor

Summary. The paper presents the first systematic taxonomy of rollback-resilient recovery mechanisms for confidential BFT consensus under TEEs, categorizing prior work into four types and exposing their tradeoffs between critical-path overhead and recovery latency. It introduces Chimera, which separates persistent state into metadata and logs according to differences in distribution, update behavior, and representation, applying distinct recovery mechanisms to each; the design is formally modeled in Maude to verify safety and liveness, implemented on Braft and ZooKeeper with Intel TDX, and evaluated in LAN/WAN settings to claim higher throughput, lower recovery latency, and improved availability versus state-of-the-art baselines.

Significance. If the separability assumption holds without introducing new safety violations, Chimera would meaningfully advance confidential BFT by resolving the overhead-availability tradeoff. The formal Maude modeling for safety/liveness and the concrete implementation/evaluation on production systems (Braft, ZooKeeper, TDX) are clear strengths that would support adoption if the cross-dependency concern is resolved.

major comments (2)
  1. [Design section] Design section (and Maude model): the central claim that metadata/logs can be recovered independently without new safety violations rests on clean separability; if the model encodes them as independent modules without explicit rules capturing protocol-level references (e.g., log entries depending on metadata versions or quorum states), a host rollback of one type could produce inconsistent states accepted by the other path, undermining the "no new violations" guarantee.
  2. [Evaluation section] Evaluation section: performance claims (higher throughput, lower latency, better availability) are load-bearing for the practical contribution, yet the abstract and reported results provide no details on experimental setup, exact baselines, number of runs, or error bars, preventing verification that gains are not due to unstated implementation choices.
minor comments (2)
  1. The taxonomy could include a table summarizing the four categories with their overhead and latency characteristics for easier comparison.
  2. Notation for state types (metadata vs. logs) should be defined once early and used consistently in the model description.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. We address each major comment below, providing clarifications on the design and committing to improvements in the evaluation.

read point-by-point responses
  1. Referee: [Design section] Design section (and Maude model): the central claim that metadata/logs can be recovered independently without new safety violations rests on clean separability; if the model encodes them as independent modules without explicit rules capturing protocol-level references (e.g., log entries depending on metadata versions or quorum states), a host rollback of one type could produce inconsistent states accepted by the other path, undermining the "no new violations" guarantee.

    Authors: Our Maude model explicitly encodes protocol-level dependencies rather than treating metadata and logs as fully independent modules. Transition rules capture references such as log entries depending on metadata versions, quorum state consistency, and cross-component checks during recovery. The verified safety and liveness properties therefore account for these interactions, ensuring that a rollback on one path cannot produce states accepted by the other. We will add a dedicated subsection in the revised manuscript excerpting the relevant Maude rules to make these dependencies more prominent. revision: partial

  2. Referee: [Evaluation section] Evaluation section: performance claims (higher throughput, lower latency, better availability) are load-bearing for the practical contribution, yet the abstract and reported results provide no details on experimental setup, exact baselines, number of runs, or error bars, preventing verification that gains are not due to unstated implementation choices.

    Authors: We agree that the current manuscript lacks sufficient experimental details. In the revised version we will expand the Evaluation section with: (1) complete hardware and network specifications for both LAN and WAN settings, (2) precise descriptions and versions of all baselines, (3) the number of runs per experiment, and (4) error bars or standard deviations for all throughput, latency, and availability metrics. revision: yes

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: claims rest on independent taxonomy, Maude verification, and empirical evaluation

full rationale

The provided abstract and description contain no equations, fitted parameters presented as predictions, or self-citations that bear the central load. The taxonomy is explicitly 'distilled' from prior approaches; the CHIMERA design is motivated by stated protocol-level differences in state properties; safety/liveness is verified via external Maude modeling (not shown to encode the target result by construction); and performance results are measured against baselines. No step reduces the claimed separation, recovery mechanisms, or guarantees to inputs by definition or self-reference. This is the expected non-finding for a design+verification+evaluation paper whose core argument is not tautological.

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

Based on abstract only; the central claim rests on standard assumptions about TEE rollback threats and BFT state continuity plus the new claim that state types differ sufficiently to allow differentiated recovery. No free parameters, axioms, or invented entities are identifiable from the abstract.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Chimera: Protocol-Aware Recovery for Confidential BFT Consensus." pith.science (2026). https://pith.science/paper/J446QIA6

@misc{pith2026260609101,
  author       = {Pith},
  title        = {Pith review of: Chimera: Protocol-Aware Recovery for Confidential BFT Consensus},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/J446QIA6}},
  note         = {Machine review of arXiv:2606.09101}
}
read the original abstract

Trusted Execution Environments (TEEs) have enabled confidential Byzantine Fault-Tolerant (BFT) consensus systems with confidentiality and improved scalability. However, TEEs do not provide state continuity: during recovery, a compromised host can roll back a crashed enclave to a stale persistent state, significantly threatening both safety and availability. Existing defenses face a fundamental tradeoff: they either impose substantial overhead on critical consensus paths, reducing throughput and increasing latency, or incur prolonged recovery delays, hurting availability. We present the first systematic taxonomy of rollback-resilient recovery for confidential BFT consensus, distilling prior approaches into four categories. We further expose their inherent limitations. Guided by this detailed analysis, we design CHIMERA, a protocol-aware recovery framework that breaks this tradeoff. Our key insight is that rollback protection in consensus systems should not be uniform. Different types of persistent states differ fundamentally in their state distribution, update behavior, and representation form. CHIMERA separates persistent state into metadata and logs according to these protocol-level properties and applies distinct recovery mechanisms to each type. We formally model CHIMERA in Maude and verify its safety and liveness properties. We implement it on Braft and ZooKeeper using Intel TDX, and evaluate it in both LAN and WAN settings. Results show that CHIMERA achieves higher throughput, lower recovery latency, and better availability than state-of-the-art rollback-resilient baselines.

Figures

Figures reproduced from arXiv: 2606.09101 by the authors.

Figure 1
Figure 1. Architecture of CHIMERA. metadata preserves election safety, but entering a higher epoch may temporarily reduce availability. This trade-off makes metadata well-suited for TC-based local freshness protection, which enables precise, node-local recovery. Second, metadata is scalar and can be stored in a register-like form. In particular, the epoch increases monotonically during leader transitions, which aligns natural… view at source ↗
Figure 2
Figure 2. Recovery design of metadata. • E2 Crash. At E2, T Cmd has advanced by one epoch, but the corresponding metadata has not yet been sealed. This creates a mismatch between the counter and the sealed metadata. This mismatch is indistinguishable from an actual rollback, rendering detection unreliable. The binding update design resolves this issue by using the counter value as the recovered epoch. Since no sealed metadata… view at source ↗
Figure 3
Figure 3. Throughput and latency comparisons with varying nodes in WAN and LAN. [PITH_FULL_IMAGE:figures/full_fig_p012_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: The fault recovery process of CHIMERA-B. the node must reconstruct its state from scratch, which takes about 110–120 seconds for 5 GB of data. For data-intensive applications such as blockchains, where the state can reach several terabytes (e.g., Bitcoin [74]), the rec…
Figure 5
Figure 5. Figure 5: Overhead profiling of TEE-related execution. [PITH_FULL_IMAGE:figures/full_fig_p013_5.png]
Figure 6
Figure 6. Figure 6: Throughput vs. Latency of CHIMERA-B and its coun￾terparts. Throughput of Braft-RC under Recovering Faults [PITH_FULL_IMAGE:figures/full_fig_p016_6.png]
Figure 7
Figure 7. Figure 7: The fault recovery process of Braft-RC. 16 [PITH_FULL_IMAGE:figures/full_fig_p016_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

95 extracted references · 1 canonical work pages

  1. [1]

    LSKV: A confidential distributed datastore to protect critical data in the cloud,

    A. Jeffery, J. Maffre, H. Howard, and R. Mortier, “LSKV: A confidential distributed datastore to protect critical data in the cloud,”arXiv preprint, 2024

  2. [2]

    SecureKeeper: Confidential ZooKeeper using Intel SGX,

    S. Brenner, C. Wulf, D. Goltzsche, N. Weichbrodt, M. Lorenz, C. Fetzer, P. Pietzuch, and R. Kapitza, “SecureKeeper: Confidential ZooKeeper using Intel SGX,” inProc. of Middleware, 2016

  3. [3]

    Secret key recovery in a global-scale end-to-end encryption system,

    G. Connell, V . Fang, R. Schmidt, E. Dauterman, and R. A. Popa, “Secret key recovery in a global-scale end-to-end encryption system,” inProc. of OSDI, 2024

  4. [4]

    Engraft: Enclave-guarded raft on Byzantine faulty nodes,

    W. Wang, S. Deng, J. Niu, M. K. Reiter, and Y . Zhang, “Engraft: Enclave-guarded raft on Byzantine faulty nodes,” inProc. of CCS, 2022

  5. [5]

    Confidentiality support over financial grade consortium blockchain,

    Y . Yan, C. Wei, X. Guo, X. Lu, X. Zheng, Q. Liu, C. Zhou, X. Song, B. Zhao, H. Zhanget al., “Confidentiality support over financial grade consortium blockchain,” inProc. of ACM SIGMOD, 2020

  6. [6]

    The oasis blockchain platform,

    “The oasis blockchain platform,” https://assets.website-files.com/ 5f59478e350b91447863f593/628ba74a9aee37587419cf65 20200623% 20The%20Oasis%20Blockchain%20Platform.pdf, retrieved September 2025

  7. [7]

    CCF: A framework for building confidential verifiable replicated services,

    M. Russinovich, E. Ashton, C. Avanessians, M. Castro, A. Chamayou, S. Clebsch, M. Costa, C. Fournet, M. Kerner, S. Krishnaet al., “CCF: A framework for building confidential verifiable replicated services,” Microsoft Research and Microsoft Azure, Tech. Rep., 2019

  8. [8]

    Con- fidential consortium framework: Secure multiparty applications with confidentiality, integrity, and high availability,

    H. Howard, F. Alder, E. Ashton, A. Chamayou, S. Clebsch, M. Costa, A. Delignat-Lavaud, C. Fournet, A. Jeffery, M. Kerner, F. Kounelis, M. A. Kuppe, J. Maffre, M. Russinovich, and C. M. Wintersteiger, “Con- fidential consortium framework: Secure multiparty applications with confidentiality, integrity, and high availability,”Proc. VLDB Endow., vol. 17, no. ...

Show all 95 references
  1. [9]

    Smart casual verification of the confidential consortium framework,

    H. Howard, M. A. Kuppe, E. Ashton, A. Chamayou, and N. Crooks, “Smart casual verification of the confidential consortium framework,” inProc. of NSDI, 2025

  2. [10]

    TEEKAP: Self-expiring data capsule using Trusted Execution Environment,

    M. Gao, H. Dang, and E.-C. Chang, “TEEKAP: Self-expiring data capsule using Trusted Execution Environment,” inProc. of ACSAC, 2021

  3. [11]

    In search of an understandable consensus algorithm,

    D. Ongaro and J. Ousterhout, “In search of an understandable consensus algorithm,” inProc. of ATC, 2014

  4. [12]

    ROTE: Rollback protection for trusted execution,

    S. Matetic, M. Ahmed, K. Kostiainen, A. Dhar, D. Sommer, A. Gervais, A. Juels, and S. Capkun, “ROTE: Rollback protection for trusted execution,” inProc. of USENIX Security, 2017

  5. [13]

    Narrator: Secure and practical state continuity for trusted execution in the cloud,

    J. Niu, W. Peng, X. Zhang, and Y . Zhang, “Narrator: Secure and practical state continuity for trusted execution in the cloud,” inProc. of CCS, 2022

  6. [14]

    Ariadne: A minimal approach to state continuity,

    R. Strackx and F. Piessens, “Ariadne: A minimal approach to state continuity,” inProc. of USENIX Security, 2016

  7. [15]

    Memoir: Practical state continuity for protected modules,

    B. Parno, J. R. Lorch, J. R. Douceur, J. Mickens, and J. M. McCune, “Memoir: Practical state continuity for protected modules,” inProc. of S&P, 2011

  8. [16]

    Dis- secting BFT consensus: In trusted components we trust!

    S. Gupta, S. Rahnama, S. Pandey, N. Crooks, and M. Sadoghi, “Dis- secting BFT consensus: In trusted components we trust!” inProc. of EuroSys, 2023

  9. [17]

    RR: A fault model for efficient TEE replication,

    B. Dinis, P. Druschel, and R. Rodrigues, “RR: A fault model for efficient TEE replication,” inProc. of NDSS, 2023

  10. [18]

    Achilles: Efficient TEE-assisted BFT consensus via rollback resilient recovery,

    J. Niu, X. Wen, G. Wu, S. Liu, J. Yu, and Y . Zhang, “Achilles: Efficient TEE-assisted BFT consensus via rollback resilient recovery,” inProc. of EuroSys, 2025

  11. [19]

    Nimble: Rollback protection for confidential cloud services,

    S. Angel, A. Basu, W. Cui, T. Jaeger, S. Lau, S. Setty, and S. Singana- malla, “Nimble: Rollback protection for confidential cloud services,” in Proc. of OSDI, 2023

  12. [20]

    “Braft,” https://github.com/baidu/braft, retrieved September 2025

  13. [21]

    ZooKeeper: Wait-free coordination for internet-scale systems,

    P. Hunt, M. Konar, F. P. Junqueira, and B. Reed, “ZooKeeper: Wait-free coordination for internet-scale systems,” inProc. of ATC, 2010

  14. [22]

    Zab: High-performance broadcast for primary-backup systems,

    F. P. Junqueira, B. C. Reed, and M. Serafini, “Zab: High-performance broadcast for primary-backup systems,” inProc. of DSN, 2011

  15. [23]

    Intel Trust Domain Extensions,

    “Intel Trust Domain Extensions,” https://www.intel.com/content/ dam/develop/external/us/en/documents/tdx-whitepaper-final9-17.pdf, retrieved September 2025

  16. [24]

    Using innovative instructions to create trustworthy software solutions,

    M. Hoekstra, R. Lal, P. Pappachan, V . Phegade, and J. Del Cuvillo, “Using innovative instructions to create trustworthy software solutions,” inProc. of HASP, 2013

  17. [25]

    AMD SEV-SNP: Strengthening VM isolation with integrity protection and more,

    D. Kaplan, J. Powell, and T. Woller, “AMD SEV-SNP: Strengthening VM isolation with integrity protection and more,” AMD, Tech. Rep.,

  18. [26]

    Available: https://www.amd.com/system/files/TechDocs/ SEV-SNP-strengthening-vm-isolation-with-integrity-protection.pdf

    [Online]. Available: https://www.amd.com/system/files/TechDocs/ SEV-SNP-strengthening-vm-isolation-with-integrity-protection.pdf

  19. [27]

    Building a secure system using TrustZone technology,

    “Building a secure system using TrustZone technology,” https:// documentation-service.arm.com/static/5f212796500e883ab8e74531, re- trieved September 2025

  20. [28]

    Ekiden: A platform for confidentiality- preserving, trustworthy, and performant smart contracts,

    R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. Johnson, A. Juels, A. Miller, and D. Song, “Ekiden: A platform for confidentiality- preserving, trustworthy, and performant smart contracts,” inProc. of EuroS&P, 2019

  21. [29]

    Teechain: A secure payment network with asynchronous blockchain access,

    J. Lind, O. Naor, I. Eyal, F. Kelbert, E. G. Sirer, and P. Pietzuch, “Teechain: A secure payment network with asynchronous blockchain access,” inProc. of SOSP, 2019

  22. [30]

    TeeRollup: Efficient rollup design using heterogeneous TEE,

    X. Wen, Q. Feng, H. Lyu, J. Niu, Y . Zhang, and C. Feng, “TeeRollup: Efficient rollup design using heterogeneous TEE,” inIEEE Transactions on Computers, 2025

  23. [31]

    Mercury: Practical cross-chain exchange via trusted hardware,

    X. Wen, Q. Feng, J. Niu, Y . Zhang, and C. Feng, “Mercury: Practical cross-chain exchange via trusted hardware,”IEEE Transactions on Dependable and Secure Computing, vol. 23, no. 2, pp. 2949–2961, 2026

  24. [32]

    Fides: Scalable censorship-resistant DAG consensus via trusted components

    S. Xie, D. Kang, H. Lyu, J. Niu, and M. Sadoghi, “Fides: Scalable censorship-resistant DAG consensus via trusted components.”

  25. [33]

    Integrity checking in cryptographic file systems with constant trusted storage

    A. Oprea and M. K. Reiter, “Integrity checking in cryptographic file systems with constant trusted storage.” inProc. of USENIX Security, 2007

  26. [34]

    The google file system,

    S. Ghemawat, H. Gobioff, and S.-T. Leung, “The google file system,” inProc. of SOSP, 2003

  27. [35]

    On designing and deploying internet-scale services,

    J. Hamilton, “On designing and deploying internet-scale services,” in Proc. of LISA, 2007

  28. [36]

    Experience with grapevine: the growth of a distributed system,

    M. D. Schroeder, A. D. Birrell, and R. M. Needham, “Experience with grapevine: the growth of a distributed system,”ACM Trans. Comput. Syst., vol. 2, no. 1, p. 3–23, 1984

  29. [37]

    EnclaveDB: A secure database using SGX,

    C. Priebe, K. Vaswani, and M. Costa, “EnclaveDB: A secure database using SGX,” inProc. of S&P. IEEE, 2018

  30. [38]

    The forking way: When tees meet consensus,

    A. Wilde, T. N. Gruel, C. Soriente, and G. Karame, “The forking way: When tees meet consensus,”arXiv preprint, 2024

  31. [39]

    Signal Secure Value Recovery,

    “Signal Secure Value Recovery,” https://signal.org/blog/ secure-value-recovery, retrieved September 2025

  32. [40]

    Confidential consortium framework,

    M. Azure., “Confidential consortium framework,” https://www.microsoft.com/en-us/research/project/ confidential-consortium-framework/, retrieved September 2025

  33. [41]

    Trusted computing meets blockchain: Rollback attacks and a solution for Hy- perledger Fabric,

    M. Brandenburger, C. Cachin, R. Kapitza, and A. Sorniotti, “Trusted computing meets blockchain: Rollback attacks and a solution for Hy- perledger Fabric,” inProc. of SRDS, 2019

  34. [42]

    Virtual monotonic counters and count-limited objects using a TPM without a trusted OS,

    L. F. G. Sarmenta, M. van Dijk, C. W. O’Donnell, J. Rhodes, and S. Devadas, “Virtual monotonic counters and count-limited objects using a TPM without a trusted OS,” inProc. of STC, 2006

  35. [43]

    Trusted time and monotonic counters with intel software guard extensions platform services,

    “Trusted time and monotonic counters with intel software guard extensions platform services,” https: //www.intel.com/content/www/us/en/content-details/671564/ trusted-time-and-/monotonic-counters-with-intel-software-/ guard-extensions-platform-services.html, retrieved September 2025

  36. [44]

    Ensuring state continuity for confidential computing: A blockchain-based approach,

    W. Peng, X. Li, J. Niu, X. Zhang, and Y . Zhang, “Ensuring state continuity for confidential computing: A blockchain-based approach,” IEEE Trans. Dependable Secure Comput., vol. 21, no. 6, pp. 5635–5649, 2024

  37. [45]

    Providing stable storage for the diskless crash-recovery failure model,

    E. Michael, D. R. K. Ports, N. K. Sharma, and A. Szekeres, “Providing stable storage for the diskless crash-recovery failure model,” University of Washington, Tech. Rep. UW-CSE-16-08-02, 2016

  38. [46]

    Viewstamped replication revisited,

    B. Liskov and J. Cowling, “Viewstamped replication revisited,” MIT CSAIL, Tech. Rep. MIT-CSAIL-TR-2012-021, 2012

  39. [47]

    Paxos made live: An engineering perspective,

    T. D. Chandra, R. Griesemer, and J. Redstone, “Paxos made live: An engineering perspective,” inProc. of PODC, 2007

  40. [48]

    Jpaxos: State machine replication based on the paxos 14 protocol,

    J. Ko ´nczak, N. Santos, T. ˙Zurkowski, P. T. Wojciechowski, and A. Schiper, “Jpaxos: State machine replication based on the paxos 14 protocol,” EPFL, Tech. Rep. 167765, 2011. [Online]. Available: https://infoscience.epfl.ch/handle/20.500.14299/69874

  41. [49]

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

    A. Bessani, M. Correia, T. Distler, R. Kapitza, P. Esteves-Verissimo, and J. Yu, “Vivisecting the dissection: On the role of trusted components in BFT protocols,”arXiv preprint arXiv:2312.05714, 2023

  42. [50]

    On the (limited) power of non-equivocation,

    A. Clement, F. Junqueira, A. Kate, and R. Rodrigues, “On the (limited) power of non-equivocation,” inProc. of PODC, 2012

  43. [51]

    Recipe: Hardware-accelerated replication protocols,

    D. Giantsidi, E. Giortamis, J. Pritzi, M. Bailleu, M. Kapritsos, and P. Bhatotia, “Recipe: Hardware-accelerated replication protocols,”arXiv preprint, 2025

  44. [52]

    Ethanos: efficient bootstrapping for full nodes on account-based blockchain,

    J.-Y . Kim, J. Lee, Y . Koo, S. Park, and S.-M. Moon, “Ethanos: efficient bootstrapping for full nodes on account-based blockchain,” inProc. of EuroSys, 2021

  45. [53]

    Sli- mArchive: A lightweight architecture for ethereum archive nodes,

    H. Feng, Y . Hu, Y . Kou, R. Li, J. Zhu, L. Wu, and Y . Zhou, “Sli- mArchive: A lightweight architecture for ethereum archive nodes,” in Proc. of USENIX ATC, 2024

  46. [54]

    Offline un- trusted storage with immediate detection of forking and replay attacks,

    M. van Dijk, J. Rhodes, L. F. G. Sarmenta, and S. Devadas, “Offline un- trusted storage with immediate detection of forking and replay attacks,” inProc. of STC, 2007

  47. [55]

    ICE: A passive, high-speed, state-continuity scheme,

    R. Strackx, B. Jacobs, and F. Piessens, “ICE: A passive, high-speed, state-continuity scheme,” inProc. of ACSAC, 2014

  48. [56]

    ZombieLoad: Cross-privilege-boundary data sampling,

    M. Schwarz, M. Lipp, D. Moghimi, J. Van Bulck, J. Stecklina, T. Prescher, and D. Gruss, “ZombieLoad: Cross-privilege-boundary data sampling,” inProc. of CCS, 2019

  49. [57]

    RIDL: Rogue in-flight data load,

    S. Van Schaik, A. Milburn, S. ¨Osterlund, P. Frigo, G. Maisuradze, K. Razavi, H. Bos, and C. Giuffrida, “RIDL: Rogue in-flight data load,” inProc. of S&P. IEEE, 2019

  50. [58]

    Sgxpectre: Stealing Intel secrets from SGX enclaves via speculative execution,

    G. Chen, S. Chen, Y . Xiao, Y . Zhang, Z. Lin, and T. H. Lai, “Sgxpectre: Stealing Intel secrets from SGX enclaves via speculative execution,” in Proc. of EuroS&P, 2019

  51. [59]

    T-sgx: Eradicating controlled-channel attacks against enclave programs,

    M.-W. Shih, S. Lee, T. Kim, and M. Peinado, “T-sgx: Eradicating controlled-channel attacks against enclave programs,” inProc. of NDSS, 2017

  52. [60]

    Varys: Protecting SGX enclaves from practical Side-Channel attacks,

    O. Oleksenko, B. Trach, R. Krahn, M. Silberstein, and C. Fetzer, “Varys: Protecting SGX enclaves from practical Side-Channel attacks,” inProc. of USENIX ATC, 2018

  53. [61]

    Consensus in the presence of partial synchrony,

    C. Dwork, N. Lynch, and L. Stockmeyer, “Consensus in the presence of partial synchrony,”J. ACM, vol. 35, no. 2, pp. 288–323, 1988

  54. [63]

    HotStuff: BFT consensus with linearity and responsiveness,

    M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, “HotStuff: BFT consensus with linearity and responsiveness,” inProc. of PODC, 2019

  55. [64]

    Fast-HotStuff: A fast and robust BFT protocol for blockchains,

    M. M. Jalalzai, J. Niu, C. Feng, and F. Gai, “Fast-HotStuff: A fast and robust BFT protocol for blockchains,”IEEE Trans. Dependable Secure Comput., vol. 21, no. 4, pp. 2478–2493, 2024

  56. [65]

    Scaling blockchain consensus via a robust shared mempool,

    F. Gai, J. Niu, I. Beschastnikh, C. Feng, and S. Wang, “Scaling blockchain consensus via a robust shared mempool,” inProc. of ICDE, 2023

  57. [66]

    Practical Byzantine fault tolerance,

    M. Castro and B. Liskov, “Practical Byzantine fault tolerance,” inProc. of OSDI, 1999

  58. [67]

    Clavel, F

    M. Clavel, F. Dur ´an, S. Eker, P. Lincoln, N. Mart´ı-Oliet, J. Meseguer, and C. Talcott,All About Maude: A High-Performance Logical Framework: How to Specify, Program and Verify Systems in Rewriting Logic. Springer, 2007

  59. [68]

    Survivability: design, formal modeling, and validation of cloud storage systems using maude,

    R. Bobba, J. Grov, I. Gupta, S. Liu, J. Meseguer, P. C. ¨Olveczky, and S. Skeirik, “Survivability: design, formal modeling, and validation of cloud storage systems using maude,”Assured cloud computing, pp. 10– 48, 2018

  60. [69]

    A formal framework for end-to-end dns resolution,

    S. Liu, H. Duan, L. Heimes, M. Bearzi, J. Vieli, D. Basin, and A. Perrig, “A formal framework for end-to-end dns resolution,” inSIGCOMM ’23. ACM, 2023, p. 932–949

  61. [70]

    Chuat, M

    L. Chuat, M. Legner, D. A. Basin, D. Hausheer, S. Hitz, P. M ¨uller, and A. Perrig,The Complete Guide to SCION - From Design Principles to Formal Verification, ser. Information Security and Cryptography. Springer, 2022

  62. [71]

    Bridg- ing the semantic gap between qualitative and quantitative models of distributed systems,

    S. Liu, J. Meseguer, P. C. ¨Olveczky, M. Zhang, and D. A. Basin, “Bridg- ing the semantic gap between qualitative and quantitative models of distributed systems,”Proc. ACM Program. Lang., vol. 6, no. OOPSLA2, pp. 315–344, 2022

  63. [72]

    Apache ZooKeeper,

    “Apache ZooKeeper,” https://zookeeper.apache.org/, retrieved Septem- ber 2025

  64. [73]

    SGX data center attestation primitives,

    “SGX data center attestation primitives,” https://github.com/intel/ SGXDataCenterAttestationPrimitives, retrieved September 2025

  65. [74]

    Dissecting the performance of chained-BFT,

    F. Gai, A. Farahbakhsh, J. Niu, C. Feng, I. Beschastnikh, and H. Duan, “Dissecting the performance of chained-BFT,” inProc. of ICDCS, 2021

  66. [75]

    Bitcoin: A peer-to-peer electronic cash system,

    S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,”Working Paper, 2008

  67. [76]

    Microsoft azure confidential ledger,

    “Microsoft azure confidential ledger,” https://learn.microsoft.com/en-us/ azure/confidential-ledger/overview, retrieved September 2025

  68. [77]

    Hyperledger Fabric: A distributed operating system for permissioned blockchains,

    E. Androulaki, A. Barger, V . Bortnikov, C. Cachin, K. Christidis, A. D. Caro, D. Enyeart, C. Ferris, G. Laventman, Y . Manevich, S. Mu- ralidharan, C. Murthy, B. Nguyen, M. Sethi, G. Singh, K. Smith, A. Sorniotti, C. Stathakopoulou, M. Vukolic, S. W. Cocco, and J. Yellick, “H...

  69. [78]

    Hybrids on Steroids: SGX-based high performance BFT,

    J. Behl, T. Distler, and R. Kapitza, “Hybrids on Steroids: SGX-based high performance BFT,” inProc. of EuroSys, 2017

  70. [79]

    Scalable Byzantine consensus via hardware-assisted secret sharing,

    J. Liu, W. Li, G. O. Karame, and N. Asokan, “Scalable Byzantine consensus via hardware-assisted secret sharing,”IEEE Transactions on Computers, vol. 68, pp. 139–151, 2019

  71. [80]

    TBFT: Efficient Byzantine fault tolerance using Trusted Execution Environment,

    J. Zhang, J. Gao, K. Wang, Z. Wu, Y . Li, Z. Guan, and Z. Chen, “TBFT: Efficient Byzantine fault tolerance using Trusted Execution Environment,” inProc. of ICC, 2022

  72. [81]

    Damysus: Streamlined BFT consensus leveraging trusted components,

    J. Decouchant, D. Kozhaya, V . Rahli, and J. Yu, “Damysus: Streamlined BFT consensus leveraging trusted components,” inProc. of EuroSys, 2022

  73. [82]

    Oneshot: View-adapting streamlined BFT protocols with Trusted Execution Environments,

    ——, “Oneshot: View-adapting streamlined BFT protocols with Trusted Execution Environments,” inProc. of IPDPS, 2024

  74. [83]

    VC3: Trustworthy data analytics in the cloud using sgx,

    F. Schuster, M. Costa, C. Fournet, C. Gkantsidis, M. Peinado, G. Mainar- Ruiz, and M. Russinovich, “VC3: Trustworthy data analytics in the cloud using sgx,” inProc. of S&P, 2015

  75. [84]

    SecFL: Confidential federated learning using TEEs,

    D. L. Quoc and C. Fetzer, “SecFL: Confidential federated learning using TEEs,”arXiv preprint, 2021

  76. [85]

    ADAM-CS: Advanced asynchronous monotonic counter service,

    A. Martin, C. Lian, F. Gregor, R. Krahn, V . Schiavoni, P. Felber, and C. Fetzer, “ADAM-CS: Advanced asynchronous monotonic counter service,” inProc. of DSN, 2021

  77. [86]

    Formally verifying a rollback-prevention protocol for TEEs,

    W. Wang, J. Niu, M. K. Reiter, and Y . Zhang, “Formally verifying a rollback-prevention protocol for TEEs,” inProc. of FORTE, 2024

  78. [87]

    Giving state to the stateless: Augmenting trustworthy computation with ledgers,

    G. Kaptchuk, I. Miers, and M. Green, “Giving state to the stateless: Augmenting trustworthy computation with ledgers,” inProc. of NDSS, 2019

  79. [88]

    G. A. Agha,ACTORS - a model of concurrent computation in distributed systems, ser. MIT Press series in artificial intelligence. MIT Press, 1990

  80. [89]

    Automatic analysis of consistency properties of distributed transaction systems in maude,

    S. Liu, P. C. ¨Olveczky, M. Zhang, Q. Wang, and J. Meseguer, “Automatic analysis of consistency properties of distributed transaction systems in maude,” inTACAS 2019, ser. LNCS, vol. 11428. Springer, 2019, pp. 40–57

  81. [90]

    Multi-grained specifications for distributed system model checking and verification,

    L. Ouyang, X. Sun, R. Tang, Y . Huang, M. Jivrajani, X. Ma, and T. Xu, “Multi-grained specifications for distributed system model checking and verification,” inProceedings of the Twentieth European Conference on Computer Systems, ser. EuroSys ’25. ACM, 2025, p. 379–395

  82. [91]

    Formal modeling and analysis of cassandra in maude,

    S. Liu, M. R. Rahman, S. Skeirik, I. Gupta, and J. Meseguer, “Formal modeling and analysis of cassandra in maude,” inICFEM 2014, ser. LNCS, vol. 8829. Springer, 2014, pp. 332–347

  83. [92]

    extreme modelling in practice,

    J. Schvimer, A. J. J. Davis, and M. Hirschhorn, “extreme modelling in practice,”Proc. VLDB Endow., vol. 13, no. 9, pp. 1346–1358, 2020

  84. [93]

    Veriso: Verifiable isolation guarantees for database transactions,

    S. Ghasemirad, S. Liu, C. Sprenger, L. Multazzu, and D. Basin, “Veriso: Verifiable isolation guarantees for database transactions,”Proc. VLDB Endow., vol. 18, no. 5, p. 1362–1375, Aug. 2025. APPENDIX A. Supplementary Background

  85. [94]

    Generally, there are two types of counters: hardware-based and software-based

    Trusted Counter and Extensions:Trusted counter is the most representative and common method for rollback prevention. Generally, there are two types of counters: hardware-based and software-based. The first includes SGX counter [42], TPM counter [84], and TPM NVRAM [14], [54], ...

  86. [95]

    Without this assumption, the system may gradually lose liveness as no recovering leader can recover its log from collectingf+1replies

    Restricted Faults:CHIMERAassumes at mostfnodes may fail concurrently. Without this assumption, the system may gradually lose liveness as no recovering leader can recover its log from collectingf+1replies. Yet this limitation is not unique to our work. Diskless CFT protocols wi...

  87. [96]

    To address these violations, Wanget al.propose several countermeasures, including file encryption, network encryp- tion and authentication, and malicious leader detection

    Customized CFT Consensus Protocols:Except for roll- back issues, Wanget al.[4] also identify several safety and liveness violations of directly porting the Raft protocol into TEEs. To address these violations, Wanget al.propose several countermeasures, including file encryptio...

Pith tools

Reviewed June 27, 2026 · model on record in the stance chip above.