To understand the security of Hyperledger Fabric, it is important to state the key design goals that impact security:

• Existing members should determine how to add new members in the network: The admission of new entities in the network must be agreed upon by existing entities in the network. This principle is at the foundation of creating a permissioned blockchain. Instead of allowing any entity to download software and connect to the network, network members must agree upon a policy to admit new members (e.g., by majority vote), which is then enforced by Hyperledger Fabric. Upon a successful vote, the digital credentials of a new member can be added to an existing network.
• Existing members should determine how to update configuration/smart contract: Similar to the first item, any change in the configuration of the network or deploying or instantiating a smart contract has to be agreed upon by the network members. Taken together, the first and second points give Hyperledger Fabric the capability to perform a permissioned blockchain.
• The ledger and its associated smart contracts (chaincode) may be scoped to relevant peers to meet broader privacy and confidentiality requirements: In public blockchain networks, all nodes have a copy of the blockchain ledger and execute smart contracts. To maintain confidentiality and scoping, it is necessary to create groups of peers that store the ledger associated with their transactions (channels and channel private data in Hyperledger Fabric). The smart contracts (chaincode in Hyperledger Fabric) that update such a ledger will be scoped to the members of such a group.

• Smart contracts can be written in a general purpose language: One of the main design goals of Hyperledger Fabric is to allow smart contracts to be written in general purpose languages such as Go and JavaScript. Obviously, allowing general purpose languages for smart contract execution exposes the system to a variety of security issues if there is no governance and process in place to verify and deploy smart contracts before execution. Even then, smart contracts written in a general purpose language should be reasonably isolated to limit the harm they may inadvertently cause.
• Transaction integrity must be ensured: A transaction is an execution of smart contract. The transactions must be created and stored in a way which will prevent them from being tampered with by other peers or will make it easy to detect any tampering. Typically, ensuring transaction integrity requires the use of cryptographic primitives.
• Industry standards should be leveraged: The system should leverage industry standards for asserting digital identities (for example, X.509 certificates), as well as for communication among peers (for example, TLS and gRPC).
• Consensus separation from transaction execution and validation: Existing blockchain networks combine transaction execution and validation with achieving consensus among nodes of a blockchain network. This tight coupling makes it difficult to achieve pluggability of the consensus algorithm.
• Pluggability everywhere: The system should have a modular design, and each module should be pluggable through standard interfaces. The ability to plug in modules specific to a network gives Hyperledger Fabric the flexibility to be used in a variety of settings. However, this pluggability also implies that two different instantiations of blockchain networks based on Hyperledger Fabric may possess different security properties.

To understand how these principles impact the security of Hyperledger Fabric, we will briefly explain the architecture of Hyperledger Fabric. Refer to earlier chapters for an in-depth architecture.