hyperledger-fabricdocs Documentation, Release master
Hyperledger Fabric also offers the ability to create channels, allowing a group of participants to create a separate ledger
of transactions. This is an especially important option for networks where some participants might be competitors and
not want every transaction they make - a special price they’re offering to some participants and not others, for example
- known to every participant. If two participants form a channel, then those participants – and no others – have copies
of the ledger for that channel.
Shared Ledger
Hyperledger Fabric has a ledger subsystem comprising two components: the world state and the transaction log.
Each participant has a copy of the ledger to every Hyperledger Fabric network they belong to.
The world state component describes the state of the ledger at a given point in time. It’s the database of the ledger. The
transaction log component records all transactions which have resulted in the current value of the world state; it’s the
update history for the world state. The ledger, then, is a combination of the world state database and the transaction
log history.
The ledger has a replaceable data store for the world state. By default, this is a LevelDB key-value store database.
The transaction log does not need to be pluggable. It simply records the before and after values of the ledger database
being used by the blockchain network.
Smart Contracts
Hyperledger Fabric smart contracts are written in chaincode and are invoked by an application external to the
blockchain when that application needs to interact with the ledger. In most cases, chaincode interacts only with
the database component of the ledger, the world state (querying it, for example), and not the transaction log.
Chaincode can be implemented in several programming languages. The currently supported chaincode language is Go
with support for Java and other languages coming in future releases.
Privacy
Depending on the needs of a network, participants in a Business-to-Business (B2B) network might be extremely
sensitive about how much information they share. For other networks, privacy will not be a top concern.
Hyperledger Fabric supports networks where privacy (using channels) is a key operational requirement as well as
networks that are comparatively open.
Consensus
Transactions must be written to the ledger in the order in which they occur, even though they might be between
different sets of participants within the network. For this to happen, the order of transactions must be established and a
method for rejecting bad transactions that have been inserted into the ledger in error (or maliciously) must be put into
place.
This is a thoroughly researched area of computer science, and there are many ways to achieve it, each with different
trade-offs. For example, PBFT (Practical Byzantine Fault Tolerance) can provide a mechanism for file replicas to
communicate with each other to keep each copy consistent, even in the event of corruption. Alternatively, in Bitcoin,
ordering happens through a process called mining where competing computers race to solve a cryptographic puzzle
which defines the order that all processes subsequently build upon.
Hyperledger Fabric has been designed to allow network starters to choose a consensus mechanism that best represents
the relationships that exist between participants. As with privacy, there is a spectrum of needs; from networks that are
highly structured in their relationships to those that are more peer-to-peer.
We’ll learn more about the Hyperledger Fabric consensus mechanisms, which currently include SOLO, Kafka, and
will soon extend to SBFT (Simplified Byzantine Fault Tolerance), in another document.
Where can I learn more?
Getting Started
2.1. Introduction 15