pith. sign in

arxiv: 2606.09101 · v2 · pith:J446QIA6new · submitted 2026-06-08 · 💻 cs.DC

Chimera: Protocol-Aware Recovery for Confidential BFT Consensus

Pith reviewed 2026-06-27 15:05 UTC · model grok-4.3

classification 💻 cs.DC
keywords confidential BFT consensusTEE rollback protectionprotocol-aware recoverymetadata and logs separationstate continuityrollback-resilient recovery
0
0 comments X

The pith

CHIMERA recovers confidential BFT consensus by applying distinct mechanisms to metadata and logs based on their protocol properties.

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

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.

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.

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.

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.

Where Pith is reading between the lines

These are 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.

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.

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.

Figures

Figures reproduced from arXiv: 2606.09101 by Cong Wang, Jianyu Niu, Si Liu, Tong Liu, Xiaoqing Wen, Yinqian Zhang, Ziwei Zhou.

Figure 1
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 alig… view at source ↗
Figure 2
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 seale… view at source ↗
Figure 3
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 ↗
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 recovery time under RC can extend to hours or even days. Braft-DCR’s recovery requires disk loading (≈ 6s) and network synchronization (≈ 18s).… view at source ↗
Figure 5
Figure 5. Figure 5: Overhead profiling of TEE-related execution. [PITH_FULL_IMAGE:figures/full_fig_p013_5.png] view at source ↗
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] view at source ↗
Figure 7
Figure 7. Figure 7: The fault recovery process of Braft-RC. 16 [PITH_FULL_IMAGE:figures/full_fig_p016_7.png] view at source ↗
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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

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

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.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 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.

pith-pipeline@v0.9.1-grok · 5794 in / 1191 out tokens · 28066 ms · 2026-06-27T15:05:43.152075+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

95 extracted references

  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. ...

  9. [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

  10. [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

  11. [11]

    In search of an understandable consensus algorithm,

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

  12. [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

  13. [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

  14. [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

  15. [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

  16. [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

  17. [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

  18. [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

  19. [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

  20. [20]

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

  21. [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

  22. [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

  23. [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

  24. [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

  25. [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.,

  26. [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

  27. [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

  28. [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

  29. [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

  30. [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

  31. [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

  32. [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.”

  33. [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

  34. [34]

    The google file system,

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

  35. [35]

    On designing and deploying internet-scale services,

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

  36. [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

  37. [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

  38. [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

  39. [39]

    Signal Secure Value Recovery,

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

  40. [40]

    Confidential consortium framework,

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

  41. [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

  42. [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

  43. [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

  44. [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

  45. [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

  46. [46]

    Viewstamped replication revisited,

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

  47. [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

  48. [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

  49. [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

  50. [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

  51. [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

  52. [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

  53. [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

  54. [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

  55. [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

  56. [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

  57. [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

  58. [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

  59. [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

  60. [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

  61. [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

  62. [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

  63. [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

  64. [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

  65. [66]

    Practical Byzantine fault tolerance,

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

  66. [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

  67. [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

  68. [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

  69. [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

  70. [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

  71. [72]

    Apache ZooKeeper,

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

  72. [73]

    SGX data center attestation primitives,

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

  73. [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

  74. [75]

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

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

  75. [76]

    Microsoft azure confidential ledger,

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

  76. [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, “Hyperledger Fabric: A distributed operating system for permissioned blockchains,”...

  77. [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

  78. [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

  79. [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

  80. [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

Showing first 80 references.