PaperlayerView exact revision on arXiv

Source-linked AI summary

Blockchain and Trusted Computing: Problems, Pitfalls, and a Solution for Hyperledger Fabric

Marcus Brandenburger, Christian Cachin, Rüdiger Kapitza, Alessandro Sorniotti

arXiv:1805.08541v1cs.DCcs.CR

TL;DR

Blockchain replication conflicts with smart-contract confidentiality, motivating TEEs such as Intel SGX. The paper analyzes rollback and consensus pitfalls, then builds an SGX-based Hyperledger Fabric design that addresses Fabric’s speculative execution and achieves 0.80x–0.90x throughput of unprotected execution.

  • Problem

    Replicated blockchain state conflicts with application confidentiality, while TEE-based execution faces rollback attacks and non-final consensus that can undermine privacy.

  • Method

    The paper designs and prototypes per-application Intel SGX enclaves for Hyperledger Fabric, adapting execution to Fabric’s execute-order-validate architecture.

  • Results

    0.80x–0.90x throughput is achieved relative to unprotected execution for the auction prototype.

  • Takeaways & Limitations

    TEE-based smart-contract confidentiality is supported when consensus decisions are final and execution handles Fabric’s speculative model.

  • Takeaways & Limitations

    The trusted computing base includes approximately 5,000 lines of trusted C/C++ code, and the approach is evaluated on a sealed-bid auction application.

Abstract

from arXiv · show

A smart contract on a blockchain cannot keep a secret because its data is replicated on all nodes in a network. To remedy this problem, it has been suggested to combine blockchains with trusted execution environments (TEEs), such as Intel SGX, for executing applications that demand privacy. Untrusted blockchain nodes cannot get access to the data and computations inside the TEE. This paper first explores some pitfalls that arise from the combination of TEEs with blockchains. Since TEEs are, in principle, stateless they are susceptible to rollback attacks, which should be prevented to maintain privacy for the application. However, in blockchains with non-final consensus protocols, such as the proof-of-work in Ethereum and others, the contract execution must handle rollbacks by design. This implies that TEEs for securing blockchain execution cannot be directly used for such blockchains; this approach works only when the consensus decisions are final. Second, this work introduces an architecture and a prototype for smart-contract execution within Intel SGX technology for Hyperledger Fabric, a prominent platform for enterprise blockchain applications. Our system resolves difficulties posed by the execute-order-validate architecture of Fabric and prevents rollback attacks on TEE-based execution as far as possible. For increasing security, our design encapsulates each application on the blockchain within its own enclave that shields it from the host system. An evaluation shows that the overhead moving execution into SGX is within 10%-20% for a sealed-bid auction application.

1 INTRODUCTION

The paper examines how TEEs can protect blockchain application privacy while addressing rollback attacks and consensus integration. It proposes an Intel SGX solution for Hyperledger Fabric, whose final consensus and modular architecture support protected smart-contract execution with modest overhead.

  • Blockchain transparency and replicated data support integrity but conflict with confidentiality and user privacy.
  • TEEs isolate blockchain applications from untrusted hosts, but rollback attacks can manipulate execution order and expose confidential application data.
  • Consensus finality is required because non-final protocols may roll back execution by design, undermining TEE-based confidentiality.
  • The paper designs Intel SGX smart-contract execution for Hyperledger Fabric, whose modular consensus produces final outputs.
  • 0.80x–0.90x throughput is achieved relative to unprotected execution for the evaluated auction prototype.

2 CONSENSUS WITH NON-FINAL DECISIONS

Non-final consensus protocols can replace valid blockchain histories with longer forks, requiring nodes to revert transactions during normal operation. Consequently, TEEs cannot securely protect transaction execution there; final consensus is needed for confidentiality.

  • Non-final consensus can force nodes to revert valid transactions when a longer chain arrives, so blockchain state is never permanently decided.
  • TEEs cannot secure transaction execution under non-final consensus because enclave state may be rolled back during ordinary protocol operation.
  • Rollback-driven execution can reveal application secrets, as illustrated by the auction example.
  • Consensus with finality is presented as a necessary prerequisite for using TEEs to keep transaction data secret.

3 TECHNOLOGIES

Hyperledger Fabric is a permissioned blockchain whose execute-order-validate workflow separates transaction execution, ordering, and validation. Intel SGX protects chaincode in hardware-isolated enclaves, with attestation and sealing supporting trusted execution but not preventing stale-state rollback.

  • 3.1 Hyperledger Fabric: Fabric is a permissioned consortium blockchain in which clients invoke chaincode through peers, an ordering service, and ledger-maintaining validation.The transaction flow includes proposal execution and endorsement, ordering, and validation with state updates.
  • 3.1 Hyperledger Fabric: Fabric uses execute-order-validate: peers execute transactions and create endorsements before the ordering service establishes their total order.This differs from systems that order transactions before execution.
  • 3.2 Trusted execution with Intel SGX: SGX creates hardware-isolated enclaves that protect chaincode data and programs from a compromised host while preserving correct outputs.Enclaves can be verified through remote attestation, which confirms that intended code runs on genuine SGX hardware.
  • 3.2 Trusted execution with Intel SGX: Remote attestation lets clients or peers verify that a specific application runs inside an SGX enclave and supports key exchange through enclave-generated proof data.The proof is checked by Intel’s Attestation Service.
  • 3.2 Trusted execution with Intel SGX: SGX sealing encrypts and authenticates enclave state for external storage, but stale sealed data can still be replayed as a rollback attack.Enclave state is volatile across stops, restarts, and crashes, making rollback protection important for stateful applications.

4 PROBLEM DESCRIPTION

The paper analyzes how malicious peers can exploit rollback and speculative execution to leak blockchain secrets, then develops a modular SGX design for Fabric’s final-consensus setting. The design separates chaincode execution from peer logic, authenticates ordered inputs, tracks history, and adapts applications to Fabric’s execute-order-validate semantics.

  • 4.2 Threats: A malicious peer can invoke the enclave with reordered, replayed, or arbitrary blockchain states, allowing incorrect execution order to compromise confidentiality.In the auction example, resetting to an earlier state and adding a competing bid can reveal how bids compare.
  • 4 PROBLEM DESCRIPTION: Final consensus prevents rollback attacks by ensuring that enclave inputs correspond to a uniquely committed transaction state, whereas non-final consensus cannot provide this guarantee.The paper therefore limits its secure execution design to Fabric’s final-consensus setting.
  • 4.3 Strawman approach: The strawman design places the entire Fabric peer inside SGX, but its large trusted computing base increases attack surface and exceeds the enclave’s 128 MB protected-memory limit as the ledger grows.The authors emphasize minimizing enclave code and avoiding full-ledger encapsulation.
  • 4.4 Approach for Hyperledger Fabric: The proposed architecture separates chaincode execution from the peer and uses a trusted ordering service to provide signed transaction sequences that enclaves verify and record.Enclave history detects ordering violations and replayed transactions, although host resets remain possible.
  • 4.4 Approach for Hyperledger Fabric: Because Fabric executes speculatively before ordering, applications must respect that semantics; the auction uses a ledger barrier so evaluation occurs only after bidding closes.The barrier prevents a malicious peer from submitting new bids after the auction is closed.

5 SECURE CHAINCODE EXECUTION

The system extends Hyperledger Fabric with SGX enclaves that isolate chaincode, verify blockchain state integrity, and support confidential execution. It uses registration, attestation, ledger validation, and enclave binding to integrate protected execution with Fabric.

  • 5.1 System architecture: The architecture adds chaincode and ledger enclaves, an enclave registry, and an enclave transaction validator to a Fabric peer.Chaincode enclaves execute applications, while the ledger enclave supports state-integrity verification; the registry and validator operate in the untrusted peer component.
  • 5.1 System architecture: Each chaincode enclave isolates one chaincode from the peer and from other chaincodes while extending the Fabric interface with encryption, attestation, and secure state access.
  • 5.1 System architecture: The ledger enclave maintains integrity metadata for the latest blockchain state, and the registry records attestation results so peers and clients can inspect enclave authenticity.
  • 5.3 Chaincode enclave bootstrapping: Chaincode enclave initialization creates an enclave, registers it through remote attestation, provisions optional secrets, and binds it to the ledger enclave through local attestation.
  • 5.5 Accessing the blockchain state: Blockchain data can later be retrieved without enclave support when client- or chaincode-based key management is used.
  • 5.7 Extensions: The design supports confidential chaincode by dynamically loading encrypted code and adapting attestation to verify the encrypted binary executed by the enclave.

6 SECURITY

The security argument claims that the system preserves security up to resets. It links authenticated enclave outputs and ordered ledger state to confidentiality for transactions executed on valid state prefixes.

  • 6 SECURITY: The system claims security up to resets: malicious peers cannot infer more than transaction outputs reveal on states produced by the trusted ordering service.
  • 6 SECURITY: Accepted state updates originate from chaincode enclaves whose attestation reports and public keys are registered on the ledger.
  • 6 SECURITY: Ledger entries accessed by chaincode represent a prefix of valid state updates ordered by the trusted ordering service.
  • 6 SECURITY: Chaincode state remains confidential except for information revealed by transactions executed on prefixes of the valid ordered updates.

7 EVALUATION

The evaluation implements and benchmarks SGX-protected Hyperledger Fabric chaincode using a sealed-bid auction, comparing it with unprotected execution. Across workloads, SGX incurs modest overhead, including 0.80x–0.95x end-to-end throughput relative to native execution.

  • Implementation: The prototype integrates SGX chaincode, ledger protection, attestation, and validation components into Hyperledger Fabric 1.0.The implementation includes enclave and untrusted components, with the ledger enclave integrated as system chaincode.
  • Experimental setup: The auction benchmark encrypts bids and compares enclave execution against an unprotected Fabric peer using the same auction chaincode.The deployment uses three peers, a solo ordering service, and increasing numbers of clients.
  • Transaction endorsement: SGX and native execution show almost identical noop throughput and latency while scaling nearly linearly until saturation.The comparison uses increasing client counts for endorsement workloads.
  • Auction evaluation: 10% overhead for large bid sets and about 20% for small bid sets remain in SGX auction evaluation latency.Latency increases with the number of submitted bids, while range queries reduce cc2cc invocations and improve performance.
  • End-to-End performance: 0.80x–0.95x of native throughput is achieved by SGX execution in the end-to-end auction workload.This measurement includes endorsement, ordering, and validation.

8 RELATED WORK

Related work applies trusted execution to smart-contract privacy, consensus, transaction validation, and off-chain data. The paper distinguishes its Fabric design by isolating each application in a minimal enclave rather than placing the entire blockchain node inside trusted hardware.

  • Smart-contract execution with Intel SGX: Coco integrates consensus, ledger state, and smart-contract execution in SGX, whereas this work isolates each application in its own minimal enclave.The paper identifies Coco’s larger trusted computing base as a security concern.
  • Related TEE applications: Other systems use SGX for transaction-validation privacy, secure containers, smart-contract execution, trusted oracles, and off-chain payment channels.These approaches address related privacy, trust, or scalability goals across different blockchain platforms.
  • Consensus protocols: TEE-assisted consensus systems enhance BFT replication, introduce trusted-hardware consensus mechanisms, or replace proof-of-work leader election with SGX-based waiting.Examples include TrInc, CheapBFT, Hybster, REM, and Sawtooth PoET.
  • State continuity and TEEs: A generic state-continuity protocol detects rollback attacks under the assumption that a processor always receives the latest ledger state.The cited approach relies on an idealized trusted ledger that cannot itself be rolled back.

9 CONCLUSION

The paper identifies rollback attacks as a confidentiality risk when combining blockchains with SGX and presents a selective, minimal-TCB solution for Hyperledger Fabric. Its sealed-bid auction evaluation reports 10%–20% overhead.

  • Conclusion: 10%–20% overhead is reported for the SGX approach in the sealed-bid auction evaluation.The conclusion presents this as the measured overhead of the proposed approach.
  • Conclusion: A malicious blockchain peer may break confidentiality by resetting an enclave and manipulating the order of operation invocations.The paper frames rollback resistance as central to protecting stateful smart-contract execution.
  • Conclusion: The proposed Fabric solution selectively uses SGX, minimizes the trusted computing base, and handles rollbacks for the platform.The contribution combines a design response to rollback risks with an evaluated prototype.
Loading 1805.08541v1…