Credit goes to Christopher B Ferris @christo4ferris who put together this presentation which covers the latest developments of Hyperledger Fabric made available in Fabric 1.1 and 1.2 and what can be expected next.
2. 2
Distributed ledger platform
• v1.0.0 released July 2017
• v1.1.0 released March 2018
• v1.2.0-rc1 released June 2018
• Expect ~ quarterly releases
• Over 250 developers
• 37 companies and 87 individuals
• Over 7,000 change sets
http://hyperledger-fabric.readthedocs.io/
3. 3
Characteristics
• Permissioned
• Highly modular
• Smart contracts in general purpose languages
• Pluggable consensus
• Privacy
• No “mining” or native crypto-currency required for consensus
• Execute-order-validate vs order-execute
4. 4
Highly Modular and Configurable
• Pluggable ordering service establishes consensus
• Pluggable membership service provider
• Optional peer-to-peer gossip service
• Ledger can be configured to support a variety of DBMSs
• Pluggable endorsement and validation policy enforcement
5. 5
1.1 Business Values
Confidentiality
• Advanced confidentiality
and permissioning ensure
participants only see
network features based on
their role.
– Capabilities: Granular and
dynamic access controls,
event service access
management, revocation
list, attribute based
access control, and
mutual TLS
Development
• Expanded developer
capabilities through
JavaScript support and
transaction encryption
libraries to grow the Fabric
ecosystem.
– Capabilities: NodeJS
Chaincode and SDK,
encryption library for
chaincode, and chaincode
creator API
Data Query
• Faster and simpler data
query to deliver value of
shared ledger at scale.
– Capabilities: CouchDB,
event service
Performance &
Serviceability
• Performance and scale
improvements
• Rolling upgrade via
configured capabilities to
ensure networks don’t need
to be taken down while
updates are made.
– Capabilities: Rolling
upgrade and CouchDB
6. 6
1.2 Business Values
6
Confidentiality
• Confidential and trusted
transactions without
exposing the transaction to
the rest of the network.
– Capabilities: Side DB to
permit peer to peer
transactions, identity
mixer implementation to
mask participant
identities, and anonymous
identities policies
Development
• Start working with Ethereum
Contracts
• Developers gain new tools
to verify certificates and
simplify smart contract
execution
– Capabilities: Service
discovery, local
collections, and
certificates API
Data Query
• Continued modularity of
endorsement to ensure
granular access rights in a
production network
– Capabilities: Pluggable
endorsement and
verification, and state
based endorsement
9. 9
• All peers connect to the same system
channel (blue).
• All peers have the same chaincode and
maintain the same ledger
• Endorsement by peers E0, E1, E2 and E3
Key:
E1
E2
Client
Application
S
D
K
Hyperledger Fabric Network
Ordering-Service
P
A
B
A
B
A
B
E3
A
B
E0
Endorser Ledger
Committing
Peer
Application
Ordering Node
Smart Contract
(Chaincode)
Endorsement
Policy
O
O O
O
• Channel: Data partitioning mechanism with its own total broadcast mechanism, where transaction ordering
takes place independently in each channel
• Channel creation upon properly authenticated & authorized request
• Channel data restricted to a set of organizations/participants
• Channel access defined & enforced by means of Reader policies, Writer policies, Admin policies
Available todaySingle Channel Network
10. 10
• Peers E0 and E3 connect to the red
channel for chaincode Y and Z
• Peers E1 and E2 connect to the blue
channel for chaincode A and B
Key:
E2
Hyperledger Fabric Network
Ordering-Service
P
Y
Z
A
B
A
B
E3
Y
Z
E0
P
E1
Endorser Ledger
Committing
Peer
Application
Ordering Node
Smart Contract
(Chaincode)
Endorsement
Policy
Client
Application
S
D
K
Client
Application
S
D
K
O
O O
O
Available today
Multi Channel Network
12. 12
Private Transactions
Transaction privacy at a more fine grained level than channels.
Database storing private data updated alongside the public ledger with hashes on
the public ledger serving verifiable proof of the data
• Chaincode is tuned to store state hashes vs.
state (Private Data) to the Ledger
• Private data grouped in collections
• Collections are associated to access policies
• Private data of a collection would stored solely to
peers who satisfy the collection’s access policy
Available today
15. 15
Relevant in multiple use-cases
• Financial asset transfer
• Securities trading
• Virtual payments
Value: Extend automation, trusted
record keeping without the
need for trusted mediators
Import available
assets
IBM : 2 : Bob
IBM : 3 : Lucy
ABC : 5 : Alice
EMC : 8 : Charlie
Transfer 1 IBM
from Bob to Lucy
Transfer 2 ABC
from Alice to Bob
IBM : 1 : Bob
IBM : 4 : Lucy
ABC : 5 : Alice
EMC : 8 : Charlie
IBM : 1 : Bob
IBM : 4 : Lucy
ABC : 3 : Alice
ABC : 2 : Bob
EMC : 8 : Charlie
Import
available assets
IBM : 2 : Bob
IBM : 3 : Lucy
ABC : 5 : Alice
EMC : 8 : Char
IBM tot: 5
ABC tot: 5
…
Transfer 1 IBM
from Bob to Lucy
Transfer 3K ABC
from Alice to Bob
IBM : 2 : Bob
IBM : 3 : Lucy
ABC : 5 : Alice
EMC : 8 : Char
IBM tot: 5
ABC tot: 5
…
IBM : 2 : Bob
IBM : 3 : Lucy
ABC : 5 : Alice
EMC : 8 : Char
IBM tot: 5
ABC tot: 5
…
Authorized
asset
transfer
Anonymity
of asset
owners
Double-
spending
resistance
Security
Transactional
activity
confidentiality
Privacy
Shareholder example:
Public verifiability of ledger
Compatibility
with
standards
In developmentPrivacy-preserving asset management (UTXO)
16. 16
Hyperledger Fabric w/EVM chaincode
O
O O
O
Ordering Service
Web3 proxy Go SDK
Membership
Services
Provider
Peer
Endorser
Ledger
Committer
evmcc
!Events
Web3 client
Blockchain essentially a database, but traditional databases have central admins, which makes using them to house transaction data involving parties that don’t trust one another problematic and expensive. So, each entity maintains their own database, resulting in duplicate data and, if there are mistakes or malicious behavior, results in expensive and time consuming disputes over what the actual state of the truth is. This is particularly true when exchanging assets. And lots of different institutions recording different assets.
A roadmap chart (so usual caveats apply) for Fabric and Composer. Note that the roadmaps are controlled by the Linux Foundation community and not IBM.
Public (in other words, permissionless) blockchain systems like Bitcoin were the first to face privacy challenges. Participation in these systems is open to anyone and, as such, user behavior is shielded behind virtual pseudonyms (or "addresses") that users generate to represent themselves in their transactions. On the other hand, transaction details are in the clear, and available on the public ledger of the system.
In certain enterprise use cases, government regulations require understanding who is involved in the transactions, thus preventing the use of public blockchain systems (such as Bitcoin) where identities are pseudonymous.
Further, the public availability of the content of transactions in such systems can be problematic for numerous business use cases.
Why? Imagine a business obtaining computer parts from a vendor. Given the large volume of computer parts purchased, the supplier provides a discount to the business when trading the asset for currency. For the supplier, the actual discount is sensitive business information, as the supplier may not want to provide the same discount to businesses who purchase lower volumes.
As a response to these challenges, a couple of blockchain systems have been introduced, built on top of Bitcoin. Blockstream’s Confidential Transactions and Assets is a prominent example. It allows pseudonymous transfer of coins and assets without leaking the actual value of the coins or type of assets that are being exchanged. ZeroCash is another example. It's an open network that offers stronger privacy where — in addition to concealing the value of the assets exchanged — it conceals the owner of the coins as well as the actual transaction graph. However, as all these systems target open networks, they offer unconditional privacy.
Permissioned blockchains have emerged as an alternative to public ones to address enterprise needs for having known and identifiable participants. They've achieved the scale, confidentiality, and privacy necessary to enable enterprise applications.
This slide is an example of a Hyperledger Fabric V1 network which is very similar to a v0.6 PBFT network. All peers run the same chaincode and are part of concensus.
Hyperledger Fabric's channel architecture can offer privacy in certain cases.
“A channel is like a virtual blockchain network that sits on top of a physical blockchain network with its own access rules. Channels employ their own transaction ordering mechanism and thus provide scalability, ultimately allowing for effective ordering and partition of huge amounts of data.”
Channels in Hyperledger Fabric are configured with access policies that govern access to the channel’s resources (chaincodes, transactions, and ledger state), thus preserving the privacy and confidentiality of information exclusively within the nodes that are in the channel. Channels achieve better quality of robustness when a node is down given alternate paths to get to the destination, while also providing scalability allowing for effective sharing of huge amounts of data.
From a privacy perspective, channels are useful in cases where a subgroup of the blockchain network’s participants have a lot of transactions in common (enough to justify the creation of a new broadcast order channel), and these transactions can be processed with no dependency on state controlled by entities outside this group.
How CLSNet is using channels
CLSNet is a revolutionary FX product that addresses the wider post-trade processing needs of FX market participants. Built on a distributed ledger technology platform, CLSNet covers trades settling outside core CLS Settlement while introducing standardization and automation for the entire FX market.
CLSNet utilizes key privacy and confidential capabilities in Hyperledger Fabric to achieve their business objective. Learn more in this video.
Bilateral business relationships with a heavy volume of transactions can meet their privacy requirements via channels. Take the example of the computer parts supplier. The supplier could establish a different channel with each business partner to serve their bilateral business relationship. Of course, the rate of transactions should be high enough and the number of business partners (and resulting channels) should be low enough for this use case to also preserve the scalability advantages of the network’s channel architecture. The channel access configurability allows for preserving both the privacy of the supplier and each of its partners through shielding the entire transactions of theirs from parties outside this channel.
Channels can be further used in combination with private transactions and zero-knowledge proof technologies as described below to strengthen privacy and confidentiality.
This slide is an example of a Hyperledger Fabric V1 network with 2 channels.
Public (in other words, permissionless) blockchain systems like Bitcoin were the first to face privacy challenges. Participation in these systems is open to anyone and, as such, user behavior is shielded behind virtual pseudonyms (or "addresses") that users generate to represent themselves in their transactions. On the other hand, transaction details are in the clear, and available on the public ledger of the system.
In certain enterprise use cases, government regulations require understanding who is involved in the transactions, thus preventing the use of public blockchain systems (such as Bitcoin) where identities are pseudonymous.
Further, the public availability of the content of transactions in such systems can be problematic for numerous business use cases.
Why? Imagine a business obtaining computer parts from a vendor. Given the large volume of computer parts purchased, the supplier provides a discount to the business when trading the asset for currency. For the supplier, the actual discount is sensitive business information, as the supplier may not want to provide the same discount to businesses who purchase lower volumes.
As a response to these challenges, a couple of blockchain systems have been introduced, built on top of Bitcoin. Blockstream’s Confidential Transactions and Assets is a prominent example. It allows pseudonymous transfer of coins and assets without leaking the actual value of the coins or type of assets that are being exchanged. ZeroCash is another example. It's an open network that offers stronger privacy where — in addition to concealing the value of the assets exchanged — it conceals the owner of the coins as well as the actual transaction graph. However, as all these systems target open networks, they offer unconditional privacy.
Permissioned blockchains have emerged as an alternative to public ones to address enterprise needs for having known and identifiable participants. They've achieved the scale, confidentiality, and privacy necessary to enable enterprise applications.
Private transactions offer transaction privacy at a more fine-grained level than channels.
The database storing the private data is updated alongside the public ledger as transactions containing references to private data are committed. In fact, the hashes on the public ledger serve as verifiable proof of the data. Private transactions can be combined with anonymous client authentication (see next section) to avoid leaking the connection between the identity of the transaction's creator and the ledger stored (hashed) data.
This feature is especially useful in cases where, for regulatory or legal reasons, private data is not allowed to reside off the premise of the parties involved in the transaction.
Consider an example in the healthcare sector where a patient's health information should be released only for a specified amount of time. For example, a patient's prescription history may be made available to a specialist for a period of time before a specific surgery occurs. Private transactions would ensure data confidentiality in only allowing the patient and the specialist to see the information for a specified amount of time while also recording the hash of the data as evidence that the transaction occurred. Privacy is achieved in that there is control over who can access the actual sensitive data. If anonymous client authentication is used in addition to this (see the next section), stronger privacy would be offered as the identity of the entity that introduced or updated the (hashed) record will also be concealed.
Private transactions should be used with care in cases where the pattern of private data updates is also sensitive information and could be used to derive the actual private data. Although Hyperledger Fabric architecture prevents unauthorized access to the actual private data, shared ledger participants can still see when a private data (hashed) entry is modified. In the previous example, if a private data entry represents the number of visits by a specific patient to a hospital (assuming the patient has regular weekly meetings with his or her doctor), then patterns of updates to this entry could provide information about the reason for that patient’s visit to the doctor (for example, that the patient suffers from chronic disease).
While private transactions protect the actual private data from being directly accessed by unauthorized parties, they do not prevent public ledger participants from detecting when this private data is being modified. Private data hashes occupy key-value entries in the ledger state, whose changes are publicly available.
Also, private transactions do not conceal the parties who are allowed access to the private data. This information is available on the ledger for private data dissemination to take place properly.
Finally, private transactions would need to be accompanied with anonymous client authentication mechanisms (described in the next section) to avoid leaking the connection between the identity of the transaction's creator and the ledger stored (hashed) data.
Public (in other words, permissionless) blockchain systems like Bitcoin were the first to face privacy challenges. Participation in these systems is open to anyone and, as such, user behavior is shielded behind virtual pseudonyms (or "addresses") that users generate to represent themselves in their transactions. On the other hand, transaction details are in the clear, and available on the public ledger of the system.
In certain enterprise use cases, government regulations require understanding who is involved in the transactions, thus preventing the use of public blockchain systems (such as Bitcoin) where identities are pseudonymous.
Further, the public availability of the content of transactions in such systems can be problematic for numerous business use cases.
Why? Imagine a business obtaining computer parts from a vendor. Given the large volume of computer parts purchased, the supplier provides a discount to the business when trading the asset for currency. For the supplier, the actual discount is sensitive business information, as the supplier may not want to provide the same discount to businesses who purchase lower volumes.
As a response to these challenges, a couple of blockchain systems have been introduced, built on top of Bitcoin. Blockstream’s Confidential Transactions and Assets is a prominent example. It allows pseudonymous transfer of coins and assets without leaking the actual value of the coins or type of assets that are being exchanged. ZeroCash is another example. It's an open network that offers stronger privacy where — in addition to concealing the value of the assets exchanged — it conceals the owner of the coins as well as the actual transaction graph. However, as all these systems target open networks, they offer unconditional privacy.
Permissioned blockchains have emerged as an alternative to public ones to address enterprise needs for having known and identifiable participants. They've achieved the scale, confidentiality, and privacy necessary to enable enterprise applications.
Hasini (Shrilanka), Purdue University
Would it help if the user knows the auditor secret key?
Security & Privacy:Publicly verifiable
Authorized asset transfer
Double-spending resistance
Conditional anonymity & unlinkability of transactions
Chaincode executed in SGX enclave
Enables encrypted & securely updatable blockchain state
Execution trust through remote attestation)
Chaincode executed in SGX enclave
Becomes a trusted blackbox
Provisioned with secrets and/or confidential logic
Privacy/Confidentiality (not all parties equally trusted)
Bring your own “identity”
Identity Mixer inclusion for anonymity, privacy
Advanced application ecosystem
Privacy-preserving asset management for permissioned systems
Privacy-preserving supply chain management
Crypto anchors as bindings to the physical world