Hyperledger Fabric’s Chaincode, Practical Byzantine Fault Tolerance, and v1.0
An “Internet of Assets”
Thomas Marckx
“Think of a private blockchain as an Internet of Assets, in which you can send anything contained in a contract anywhere in the world,” said , as a led a recent webinar on Hyperledger Fabric.
Thomas is a blockchain developer at Optis and co-founder of TheLedger, based in the Antwerp area, Belgium. He took attendees through a fairly deep dive into Fabric v0.6—the current version that’s being tested by developers throughout the world.
During the presentation, Thomas provided useful information in several areas:
- A short recap of distributed ledgers and how they compare to centralized systems
- Public permissionless blockchains vs. permissioned enterprise blockchains
- A step-by-step explanation of membership services and their responsibilities in Fabric
- Security, privacy, and multi-encryption in Hyperledger Fabric
- The chaincode structure and how it can be deployed using a CLI, Rest API, or SDK
- How the consensus mechanism works and what is planned for Fabric v1.0
A general Fabric v0.6 overview
Thomas described blockchains in general as “mechanisms to draw fact-based conclusions in an auditable way,” adding that “consensus enhances trust.” He noted advantages of the trusted, private networks that can be built with Hyperledger Fabric, in contrast to a public blockchain, such as Ethereum, in which innate anonymity of users can cause problems with accountability, and in which transaction validation takes a lot of energy.
There are four types of members in a private, permissioned blockchain:
- users
- peers
- validators
- auditors
Membership services provide the specific, unique certificates needed to enable members to execute their tasks. A Certificate Authority (CA) issues all certificates. There is no external registration authority yet, something that will be needed to avoid a single point of failure within the CA.
Practical Byzantine Fault Tolerance
Thomas also mentioned the four key aspects of private blockchains in general and Fabric in particular:
- validating peers
- smart contracts
- membership services
- pluggable consensus
Validating peers approve transactions for the overall ledger, which is known as the “world state.”
Smart contracts are also known as “chaincode” and are the transactions themselves, written in either the Go or Java languages. Smart contracts have three external functions:
- init
- invoke
- query
Consensus in version 0.6 is achieved when all validating peers agree on the validity of a transaction. They use the Practical Byzantine Fault Tolerance method (PBFT) to reach consensus.
This method is widely discussed at various meetings the Hyperledger community. It is in contrast to the proof-of-work validation method used by cryptocurrency blockchains such as Ethereum.
With PBFT, transactions reach the validating peers in version 0.6 (and in version 1.0 when more than one peer is involved) at different times, so they don’t have the same order of transactions. The peers then “vote” for a validating leader, which choose the sequence, Thomas explained. The other peers communicate with one another until they have the same sequence and a consensus. Although it’s unlikely to find a rogue, subversive peer in a trusted network, a rogue peer would nevertheless be overruled by the others and fail to disrupt or corrupt a transaction.
Chaincode
The crux of this webinar featured some code that demonstrated how individuals and companies can get started with Fabric. First, he showed some simple chaincode structure:
Then he showed, and discussed, how to store and call data:
This was followed by some deployment options:
Hyperledger Fabric v1.0 is coming
Thomas provided a caveat that a few things will change with the oncoming Fabric v1.0, its first commercial-grade release, scheduled for sometime in the March to April timeframe. The biggest differences will be the addition of new database capability, and the ability to choose a single peer (or multiple peers as desired) to validate transactions, rather than having to wait for all peers on the network for this crucial step. Read our recent post for more details.
The updated version will incorporate a proof-of-elapsed-time method (PoET), in which trust from a transaction submitter and validator has been established within this private environment. This idea is being incorporated into Hyperledger’s “Sawtooth Lake” incubation, and should facilitate new levels of scalability and performance within Hyperledger Fabric.
Thomas urged attendees to get started with their own blockchain test projects. There are several ways to get started: through a CLI, a REST API, or a Node.js SDK. He noted that the REST API will be removed from Fabric v1.0, but SDKs in Java and Python are in the works.
Individual projects can be run on virtual machines on IBM Bluemix (free of charge with Fabric v0.6), “or you can go with AWS with Docker Compose and Kubernetes,” he said.
“Build a full stack if you start your own blockchain company. You can even use centralized databases if you wish, and you can connect with other blockchains.” —Thomas Marckx
His last point was in reference another change with version 1.0: the world state will be stored at a different level on the chain, enabling users to create sub-channels. Combine that with the ability to use a single validating peer, “and you can have your own little ledger,” he noted.
He sees this proliferation as the future of private blockchain, along with the use of the Interledger Protocol that will allow a lot of work to be done “off chain,” thereby increasing the performance and scalability of any individual blockchain.
Want details? Watch the webinar recording!
Related slides
Related reading
- Hyperledger Fabric Approaches v1.0 with Better Scalability and Security
- How Hyperledger Fabric Delivers Security to Enterprise Blockchain
- Hyperledger Fabric v1.0 to Bring Improved Transactions and a Pluggable Data Store
- Technical Introduction to Hyperledger Fabric
About the speaker
