Enterprise Blockchain FAQ — 20 Questions for IT and Operations Teams

Q1: What infrastructure does Hyperledger Fabric require?

Production Fabric network: minimum 3 orderer nodes (Raft consensus requires odd number), 2+ peer nodes per participating organization, certificate authority per organization. Hardware: 4 vCPU / 8GB RAM minimum per node; 8 vCPU / 16GB RAM recommended for production. Storage: 500GB SSD per node (ledger history grows over time). Cloud: AWS, Azure, GCP, or on-premises data center.

Q2: What is the uptime SLA for an enterprise blockchain network?

A properly architected Fabric network (3+ orderers, 2+ peers per org) can achieve 99.9% uptime. The ordering service is the critical path: if the majority of orderer nodes are down, the network stops accepting new transactions. Design for no single point of failure: orderers in different availability zones, peers in different regions.

Q3: How do we back up a blockchain network?

Blockchain data is inherently replicated across all nodes — the ledger is its own backup. For disaster recovery: CouchDB state database should be backed up daily (chaincode state). LevelDB ledger files backed up weekly. Certificate authority data backed up daily (most critical — loss of CA data prevents adding new members). Recovery procedures documented and tested quarterly.

Q4: What monitoring do we need for a Fabric network?

Metrics to monitor: block height consistency across all nodes (divergence indicates problem), peer endorsement failure rate, orderer consensus round duration, disk usage on all nodes, certificate expiry dates (Fabric certs expire — missed renewal causes outages).

Q5: How do we handle Fabric certificate expiration?

Fabric certificates (CA-issued) have configurable expiry (default: 1 year for node certs, 10 years for CA cert). Build a certificate rotation process: alert at 90 days, rotate at 60 days. Automated renewal via Fabric CA REST API. Missing this has caused production outages for major enterprise deployments.

Q6: What is the maximum transaction throughput of Fabric?

Benchmarked at 3,000–15,000 TPS depending on: number of orderer nodes, block size configuration, chaincode complexity, and hardware. Most enterprise use cases require 10–500 TPS — well within Fabric's capacity. Configure block size (max_message_count: 500, absolute_max_bytes: 99MB) for your throughput and latency requirements.

Q7: Can Fabric query historical state?

Yes — Fabric's CouchDB state database supports rich queries on current state. For historical state (what was the value of X at time T): use the history query API (`GetHistoryForKey()`). For complex analytics: mirror the blockchain data to a traditional database (ElasticSearch, PostgreSQL) via the blockchain's event listener.

Q8: How do we handle PII in a blockchain network?

Best practice: never store PII on-chain. Store a hash of the PII document on-chain; store the actual PII in a HIPAA/GDPR-compliant off-chain system. This satisfies 'right to be forgotten' requests (delete the off-chain data; the on-chain hash becomes meaningless) while maintaining tamper-evident audit trail.

Q9: What is the difference between a channel and a network in Fabric?

A Fabric network is the collection of organizations, orderers, and peers. A channel is a private communication subnet within the network. Multiple channels can exist within one network; each channel has its own ledger and chaincode. Organizations not in a channel cannot see that channel's transactions.

Q10: How do we add a new organization to an existing Fabric network?

Adding a new organization requires: (1) new org generates MSP certificates via their CA, (2) existing channel admin creates a channel update transaction adding the new org's MSP, (3) majority of existing channel admins sign the update, (4) channel update committed, (5) new org's peers join the channel, (6) chaincode installed and approved on new org's peers. Timeline: 2–5 days if well-coordinated.

Q11: Can Fabric communicate with Ethereum?

Not natively — Fabric and Ethereum are different ecosystems. Integration patterns: (1) Fabric event listener → middleware → Ethereum transaction (oracle pattern), (2) Zero-knowledge proof of Fabric state submitted on Ethereum, (3) API gateway exposing Fabric data to Ethereum oracle. For production cross-ecosystem integration: Chainlink's CCIP has explored Fabric connectivity.

Q12: How do we test Fabric chaincode?

Unit testing: Go's `testing` package + `shimtest.NewMockStub()` mock — tests chaincode functions without a running network. Integration testing: `fabric-test-env` Docker-based local network. Performance testing: `Hyperledger Caliper` — the standard Fabric benchmarking tool.

Q13: What logging and auditing does Fabric provide?

Fabric logs all transactions to the ledger (immutable). Peer and orderer logs are configurable (info/debug/warning). For compliance auditing: deploy a dedicated audit service that listens to all block events and stores them in a separate, indexed database for regulatory query.

Q14: How do we handle chaincode upgrades in production?

Fabric 2.x lifecycle: (1) package new chaincode, (2) install on all org peers, (3) each org approves new chaincode definition (including version), (4) when majority of channel orgs have approved: commit new definition, (5) all new transactions use new chaincode. Old transactions remain valid under old chaincode version. Zero-downtime upgrade.

Q15: What is the cost of running Fabric in production?

Cloud infrastructure cost (AWS): 3 orderers + 2 peers per org (3 org network) = ~$2,500–$5,000/month. AWS Managed Blockchain: ~$2,000–$4,000/month for the same configuration plus SLA guarantees. CloudHSM for key management: $2,100/month (2 HSMs for HA). Total for a 3-org production network: $5,000–$10,000/month infrastructure.

Q16: How do we handle smart contract bugs in production Fabric?

Fabric chaincode can be upgraded (unlike some public blockchain deployments). The upgrade process (as in Q14) allows bug fixes. Emergency response: (1) identify the bug, (2) develop fix, (3) test on staging environment, (4) coordinate all org approvals for upgrade, (5) commit upgrade. Timeline: 24–72 hours for a critical bug fix if organizations are responsive.

Q17: What is the Fabric SDK and which should we use?

Current standard: Fabric Gateway SDK (Go, Node.js, Java). Deprecated: fabric-client, fabric-network SDKs (Fabric 2.x era). The Gateway SDK provides a clean async/await interface and is optimized for Fabric 2.4+. For new projects: use Gateway SDK. For existing projects using deprecated SDKs: migrate on next major version update.

Q18: How do we integrate Fabric with SAP?

SAP Integration Suite (Cloud Integration) has a Hyperledger Fabric adapter (SAP BTP Integration). For custom integration: Fabric REST API gateway (Fabric REST Sample) accepts HTTP calls and submits chaincode transactions. SAP outbound events → Fabric gateway → chaincode transaction. Fabric block events → REST API → SAP inbound.

Q19: Can Fabric handle high-volume data like IoT sensor readings?

Yes, with appropriate design. Never write every individual IoT reading to the ledger — batch readings every 10–15 minutes and submit the batch hash. The actual readings are stored off-chain (S3, Azure Blob) with the on-chain hash providing tamper-detection. A large IoT deployment (10,000 devices, 1 reading/30 seconds) produces 28M daily readings — batching at device level to 2,800 daily on-chain transactions is manageable.

Q20: What are the most common Fabric production failures?

In order of frequency: (1) certificate expiration — automated renewal is essential, (2) disk full on ledger nodes — monitor disk usage, (3) chaincode container crash — monitor Docker health on peer nodes, (4) orderer consensus failure if majority of orderers go down simultaneously, (5) CouchDB out-of-memory on complex rich queries — tune CouchDB memory limits.