3. 3
What is Hyperledger Fabric
• Linux Foundation Hyperledger
– A collaborative effort created to advance cross-industry blockchain technologies for business
• Hyperledger Fabric
– An implementation of blockchain technology that is intended as a foundation for developing
blockchain applications
– Key technical features:
– A shared ledger and smart contracts implemented as “chaincode”
– Privacy and permissioning through membership services
– Modular architecture and flexible hosting options
• V1.0 released July 2017: contributions by 159 engineers from 27 organizations
– IBM is one of the contributors to Hyperledger Fabric
4. Hyperledger Fabric Roadmap
March 2017
V1 Alpha
• Docker images
• Tooling to bootstrap network
• Fabric CA or bring your own
• Java and Node.js SDKs
• Ordering Services - Solo and
Kafka
• Endorsement policy
• Level DB and Couch DB
• Block dissemination across
peers via Gossip
V1 GA
• Hardening, usability,
serviceability, load, operability
and stress test
• Chaincode ACL
• Chaincode packaging & LCl
• Pluggable crypto
• HSM support
• Consumability of configuration
• Next gen bootstrap tool (config
update)
• Config transaction lifecycle
• Eventing security
• Cross Channel Query
• Peer management APIs
• Documentation
Q1 2018 Future
V 1.1 *
• Node.js chaincode
• Node.js connection profile
• Provide an encryption library
• Trigger events per channel
• Enhanced CC attribute
access control
• Orderer horizontal scaling
improvements
• Preview of
• Private channel
data
• Finer grained
access control on
channels
• Identity mixer
Connect-a-cloud
• Dynamically connecting OEM
hosted cloud environments to
trade assets
* Dates for content and releases are determined by the Hyperledger community
V Next *
• SBFT
• Archive and pruning
• System Chaincode
extensions
• Application crypto library
• Dynamic service discovery
• REST wrapper
• Python SDK
• Java Chaincode
• Side DB for private data
• Identity Mixer
July 2017
5. 5
Hyperledger Fabric V1 Architecture
Client
Application
SDK
(HFC)
Membership
Services
Peer
Endorser
Ledger
Committer
A
Chaincode B
!Events
Ordering-Service
O
O O
O
Fabric-CA
External-CA
Hyperledger Fabric Network
optionaloptional
6. 6
Overview of Hyperledger Fabric v1 – Design Goals
• Better reflect business processes by specifying who endorses transactions
• Support broader regulatory requirements for privacy and confidentiality
• Scale the number of participants and transaction throughput
• Eliminate non deterministic transactions
• Support rich data queries of the ledger
• Dynamically upgrade the network and chaincode
• Support for multiple credential and cryptographic services for identity
• Support for ”bring your own identity”
8. 8
Recall key blockchain concepts
Blockchain
Developer
D
Blockchain
Operator
O
Peers Consensus
Security
Systems
IntegrationEvents
!
Ledger
…
Traditional
Data Sources
Traditional
Processing
Platforms
f(abc);
Smart
Contract
Application
9. Technical Deep Dive
• [ Network Consensus ]
• Channels and Ordering Service
• Network setup
• Endorsement Policies
• Permissioned ledger access
• Pluggable world-state
10. 10
Nodes and roles
Committing Peer: Maintains ledger and state. Commits transactions.
May hold smart contract (chaincode).
Endorsing Peer: Specialized committing peer that receives a
transaction proposal for endorsement, responds granting or denying
endorsement. Must hold smart contract
Ordering Node: Approves the inclusion of transaction blocks into the
ledger and communicates with committing and endorsing peer nodes.
Does not hold smart contract. Does not hold ledger.
11. 11
Application proposes transaction
Endorsement policy:
• “E0, E1 and E2 must sign”
• (P3, P4 are not part of the policy)
Client application submits a transaction
proposal for Smart Contract A. It must
target the required peers {E0, E1, E2}
Sample transaction: Step 1/7 – Propose transaction
E0
E1
E2
Client
Application
S
D
K
Endorser Ledger
Committing
Peer
Application
Ordering Node
Smart Contract
(Chaincode)
Endorsement
Policy
Key:
Hyperledger Fabric Network
Ordering-Service
O
O O
OP
P4P3
A
B
A
B
A
B
A
D
12. 12
Sample transaction: Step 2/7 – Execute proposal
Endorsers Execute Proposals
E0, E1 & E2 will each execute the
proposed transaction. None of these
executions will update the ledger
Each execution will capture the set of
Read and Written data, called RW sets,
which will now flow in the fabric.
Transactions can be signed & encrypted
Key:
Hyperledger Fabric Network
Ordering-Service
Endorser Ledger
Committing
Peer
Application
Ordering Node
Smart Contract
(Chaincode)
Endorsement
Policy
O
O O
O
E0
E1
E2
P
P4P3
A
B
A
B
A
B
A
D
Client
Application
S
D
K
13. 13
Sample transaction: Step 3/7 – Proposal Response
Application receives responses
RW sets are asynchronously returned to
application
The RW sets are signed by each
endorser, and also includes each record
version number
(This information will be checked much
later in the consensus process)
Key:
Hyperledger Fabric Network
Ordering-Service
Endorser Ledger
Committing
Peer
Application
Ordering Node
Smart Contract
(Chaincode)
Endorsement
Policy
O
O O
O
E0
E1
E2
P
P4P3
A
B
A
B
A
B
A
D
Client
Application
S
D
K
14. 14
Sample transaction: Step 4/7 – Order Transaction
Responses submitted for ordering
Application submits responses as a
transaction to be ordered.
Ordering happens across the fabric in
parallel with transactions submitted by
other applications
(other applications)
Key:
Hyperledger Fabric Network
Ordering-Service
Endorser Ledger
Committing
Peer
Application
Ordering Node
Smart Contract
(Chaincode)
Endorsement
Policy
O
O O
O
E0
E1
E2
P
P4P3
A
B
A
B
A
B
A
D
Client
Application
S
D
K
15. 15
Hyperledger Fabric Network
Ordering-Service
Sample transaction: Step 5/7 – Deliver Transaction
Orderer delivers to committing peers
Ordering service collects transactions
into proposed blocks for distribution to
committing peers. Peers can deliver to
other peers in a hierarchy (not shown)
Different ordering algorithms available:
• SOLO (Single node, development)
• Kafka (Crash fault tolerance)
O
O O
O
*
Key:
Endorser Ledger
Committing
Peer
Application
Ordering Node
Smart Contract
(Chaincode)
Endorsement
Policy
E0
E1
E2
P
P4P3
A
B
A
B
A
B
A
D
Client
Application
S
D
K
16. 16
Hyperledger Fabric Network
Ordering-Service
Sample transaction: Step 6/7 – Validate Transaction
Committing peers validate transactions
Every committing peer validates against
the endorsement policy. Also check RW
sets are still valid for current world state
Validated transactions are applied to the
world state and retained on the ledger
Invalid transactions are also retained on
the ledger but do not update world state
Endorser Ledger
Committing
Peer
Application
Ordering Node
Smart Contract
(Chaincode)
Endorsement
Policy
Key:
O
O O
O
E0
E1
E2
P
P4P3
A
B
A
B
A
B
A
D
Client
Application
S
D
K
* * *
*
*
17. 17
Client
Application
S
D
K
Hyperledger Fabric Network
Ordering-Service
Sample transaction: Step 7/7 – Notify Transaction
Committing peers notify applications
Applications can register to be notified
when transactions succeed or fail, and
when blocks are added to the ledger
Applications will be notified by each peer
to which they are connected!
!
!
!
! !
Key:
Endorser Ledger
Committing
Peer
Application
Ordering Node
Smart Contract
(Chaincode)
Endorsement
Policy
O
O O
O
E0
E1
E2
P
P4P3
A
B
A
B
A
B
A
D
18. Technical Deep Dive
• Network Consensus
• [ Channels and Ordering Service ]
• Network setup
• Endorsement Policies
• Permissioned ledger access
• Pluggable world-state
19. 19
Ordering Service
The ordering service packages transactions into blocks to be delivered to
peers. Communication with the service is via channels.
Different configuration options for the ordering service include:
– SOLO
• Single node for development
– Kafka : Crash fault tolerant consensus
• 3 nodes minimum
• Odd number of nodes recommended
Ordering-Service
O
O O
O
20. 20
Channels
Channels provide privacy between different ledgers
– Ledgers exist in the scope of a channel
• Channels can be shared across an entire network of peers
• Channels can be permissioned for a specific set of participants
– Chaincode is installed on peers to access the worldstate
– Chaincode is instantiated on specific
– Peers can participate in multiple channels
– Concurrent execution for performance and scalability
E0
E1
Ordering-Service
O
O O
O
21. 21
Single Channel Network
• Similar to v0.6 PBFT model
• 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
22. 22
Multi Channel Network
• Peers E0 and E3 connect to the red
channel for chaincodes Y and Z
• Peers E1 and E2 connect to the blue
channel for chaincodes 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
23. Technical Deep Dive
• Network Consensus
• Channels and Ordering Service
• [ Network setup ]
• Endorsement Policies
• Permissioned ledger access
• Pluggable world-state
24. 24
Bootstrap Network (1/6) - Configure & Start Ordering Service
Hyperledger Fabric Network
Ordering-Service
An Ordering Service is configured and started for the network:
$ docker-compose [-f orderer.yml] ...
O
O O
O
25. 25
Hyperledger Fabric Network
Bootstrap Network (2/6) - Configure and Start Peer Nodes
E0
E1
E2
E3
A peer is configured and started for each Endorser or Committer in the network:
$ peer node start ...
Ordering-Service
O
O O
O
26. 26
Hyperledger Fabric Network
E0
E1
E2
E3
Bootstrap Network (3/6) - Install Chaincode
A
BA
B
A
B
Chaincode is installed onto each Endorsing Peer that needs to execute it:
$ peer chaincode install ...
Ordering-Service
O
O O
O
28. 28
Ordering-Service
O
O O
O
Hyperledger Fabric Network
E0
E1
E2
E3
A
B
A
B
A
B
Bootstrap Network (5/6) – Join Channels
Peers that are permissioned can then join the channels they want to transact on:
$ peer channel join ...
29. 29
Ordering-Service
O
O O
O
Bootstrap Network (6/6) – Instantiate Chaincode
Hyperledger Fabric Network
E0
E1
E2
E3
A
B
A
B
A
B
Peers finally instantiate the Chaincode on the channels they want to transact on:
$ peer chaincode instantiate ... –P ‘policy’
An Endorsement Policy is specified and once instantiated chaincode can process transactions.
30. Technical Deep Dive
• Network Consensus
• Channels and Ordering Service
• Network setup
• [ Endorsement Policies ]
• Permissioned ledger access
• Pluggable world-state
31. 31
Endorsement Policies
An endorsement policy describes the conditions by which a transaction can be
endorsed. A transaction can only be considered valid if it has been endorsed
according to its policy.
– Each chaincode is deployed with an Endorsement Policy
– ESCC (Endorsement System ChainCode) signs the proposal response on the endorsing peer
– VSCC (Validation System ChainCode) validates the endorsements
Chaincode ESCC VSCC Ledger
Propose - Execute - Respond
Order - Deliver
Validate - Commit
Sign Policy
Endorsing Peer Committing Peer
P
32. 32
Endorsement Policy Syntax
Policy Syntax: EXPR(E[, E...])
Where EXPR is either AND or OR and E is either a principal or nested EXPR
Principal Syntax: MSP.ROLE
Supported roles are: member and admin
Where MSP is the MSP ID, and ROLE is either “member” or “admin”
$ peer chaincode instantiate
-C mychannel
-n mycc
-v 1.0
-p chaincode_example02
-c '{"Args":["init","a", "100", "b","200"]}'
-P "AND('Org1MSP.member')“
Instantiate the chaincode mycc on
channel mychannel with the policy
AND('Org1MSP.member')
33. 33
Endorsement Policy Examples
Examples of policies:
• Request 1 signature from all three principals
– AND('Org1.member', 'Org2.member', 'Org3.member')
• Request 1 signature from either one of the two principals
– OR('Org1.member', 'Org2.member')
• Request either one signature from a member of the Org1 MSP or (1 signature from a
member of the Org2 MSP and 1 signature from a member of the Org3 MSP)
– OR('Org1.member', AND('Org2.member', 'Org3.member'))
34. Technical Deep Dive
• Network Consensus
• Channels and Ordering Service
• Network setup
• Endorsement Policies
• [ Permissioned ledger access ]
• Pluggable world-state
35. 35
- Enroll
- Request Ecert
Hyperledger Fabric
Blockchain
User A
uses
Ecert
invokes SC txn
(signed with Ecert)
Enrollment certificate (Ecert)
is the long term identity of
the participant on the
blockchain network
Blockchain
User B
Membership Services Overview
U
U
uses
Certificate
Authority
Client
Application
SDK
Client
Application
SDK
invokes SC txn
(signed with Ecert)
Membership
Services
Provider API
36. 36
Transaction and Identity Privacy
• Enrollment Certificates, Ecerts
– Long term identity
– Can be obtained offline, bring-your-own-identity
• Permissioned Interactions
– Users sign with their Ecert
• Membership Services
– Abstract layer to credential providers
37. 37
Membership Services Provider API
Membership Services Provider API
• Pluggable interface supporting a range of
credential architectures
• Default implementation calls Fabric-CA.
• Governs identity for Peers and Users.
• Provides:
• User authentication
• User credential validation
• Signature generation and verification
• Optional credential issuance
• Additional offline enrollment options
possible (eg File System).
External
Certificate Authority
Fabric-CA
Certificate Authority
Implements
Fabric-CA
API
External
CAAPI
Membership
Services
Provider API
Peer /
Client /
Orderer
38. 39
Membership Services Provider (MSP)
• An abstraction to represent a membership authority and its operations on issuing and management of Hyperledger Fabric
membership credentials in a modular & pluggable way
– Allows for the co-existence of a variety of credential management architectures
– Allows for easy organizational separation in credential management/administration operations according to business
rules at a technical level
– Potential to smoothly easily support different standards and membership implementations
– Easy and straight-forward interface that the core can understand
• Described by a generic interface to cover:
– User credential validation
– User (anonymous but traceable) authentication: signature generation and verification
– User attribute authentication: attribute ownership proof generation, and verification
– (optionally) User credential issue
39. 41
Ecert
Fabric-CA Details
Fabric-CA
cluster DB
LDAP
Authenticate
Enroll ID, secret
HSM
Root
Certificate Authority
Fabric-CA
• Default implementation of the
Membership Services Provider
Interface.
• Issues Ecerts (long-term identity
• Supports clustering for HA
characteristics
• Supports LDAP for user authentication
• Supports HSM
Membership
Services
Provider API
Fabric-CA API
40. 42
Fabric-CA
Certificate Authority
• Issues Ecerts and manages renewal and revocation
• Supports:
– Clustering for HA characteristics
– LDAP server for registration and enrollment
– Hardware Security Modules
41. 43
Blockchain
User
New User Registration and Enrollment
U
3. Enroll(Enroll ID, secret)
wallet
Registration and Enrollment
• Admin registers new user with
Enroll ID
• User enrolls and receives
credentials
• Additional offline registration and
enrollment options available
Client
Application
SDK
Operator
O
Client
Application
SDK
1. Register(Enroll ID)
returns( secret)
returns Ecert
Ecert
Fabric-CA
42. 44
World state
Blockchain
block
…
Application Level Encryption
Ledger
Encrypt tx input
Client
Application
SDK
Chaincode
Decrypt tx input
Encrypt world-state data
tx
encryptedencrypted data
Blockchain
User
wallet
Peer
Data Encryption
Handled in the application domain.
Multiple options for encrypting:
• Transaction Data
• Chaincode*
• World-State data
Chaincode optionally deployed with
cryptographic material, or receive it
in the transaction from the client
application using the transient data
field (not stored on the ledger).
*Encryption of application chaincode
requires additional development of
system chaincode.
tx
SDK signs with Ecert
43. Technical Deep Dive
• Network Consensus
• Channels and Ordering Service
• Network setup
• Endorsement Policies
• Permissioned ledger access
• [ Pluggable world-state ]
44. 46
WorldState Database
• Pluggable worldstate database
• Default embedded key/value implementation using LevelDB
– Support for keyed queries, but cannot query on value
• Support for Apache CouchDB
– Full query support on key and value (JSON documents)
– Meets a large range of chaincode, auditing, and reporting requirements
– Will support reporting and analytics via data replication to an analytics engine such as Spark (future)
– Id/document data model compatible with existing chaincode key/value programming model
CouchDBSHIM
LevelDB
Chaincode
45. 47
Summary and Next Steps
• Apply shared ledgers and smart contracts to your Business Network
• Think about your participants, assets and business processes
• Spend time thinking about realistic business use cases
• Get some hands-on experience with the technology
• Start with a First Project
• IBM can help with your journey
This is the technical deep dive on Hyperledger Fabric. Presentations in this series are:
Blockchain Explained: High level introduction to blockchain for business
Blockchain Solutions: Use-cases, references and how IBM can help
Blockchain Composed: A technical introduction to Hyperledger Composer
Blockchain Architected: A technical introduction to the concepts and components of a blockchain solution
Blockchain Explored: A technical deep dive on Hyperledger Fabric
Blockchain Next Steps: How to proceed on a first project
The latest copy of this presentation can be found on the IBM intranet at https://ibm.box.com/v/BlockchainExplored. Feel free to distribute a PDF of this file to clients.
The modular architecture, allows innovation and flexibility allowing components, such as consensus and membership services, to be plug-and-play.
The different style of this chart is because it was taken directly from the project roadmap deck.
Latest version here: https://jira.hyperledger.org/browse/FAB-37 also
https://wiki.hyperledger.org/projects/fabric/proposedv1_1
1.1 Also has
Serviceability enhancements
Performance and scale improvements
Candidate v1.1 items from HL Mailing List:
1151 Side DB - Private Data Channel830 As an application developer I want to have available an application library to offer encryption on transaction data.5363 Common "connection profile" definition for client applications2331 Fabric support for javascript chaincode5225 Expose leadership and membership information3621 As a member of a network who runs a peer, I want to be able to support clients who transact with the network with a limited scope of permissions5346 Support role-based access control (RBAC) with enrollment certificates5308 Documentation on use of Consortium3137 Java SDK Support for PKCS11 HSM crypto interaction5556 Fabric compatibility5695 Channel Service for events
One additional lesson we have learned is that transaction verification does not reflect how business happens today. Today, if I want to do a transaction it's not confirmed by the entire business network, but by a subset of it; for example, a money transfer transaction is confirmed by maybe just the sender's bank and recepient's bank.
These concepts are described in more detail in Blockchain Architected.
Validation role split into 2 independent roles:
Endorsement
Endorsing a transaction verifying that its content obeys a given smart contract. Endorsers “sign” the contract
Ordering
Orders verified transactions for inclusion in the ledger. Controls what goes in the ledger making sure that the ledger is consistent
Introduction of Endorsement Policies and Channels
Overview of sample transaction (slides 1-7):
Separation of simulation (chaincode execution) and block validation/commit
Invocation of chaincode operation (business transaction) carried out in 3 phases:
Chaincode operation execution simulated on ‘endorsing’ peers.
Parallel simulation enabled on endorsers for improved concurrency and scalability since the simulation does not update the blockchain state
Simulation determines business tran-proposal: readset/writeset, and broadcasts this to the ordering service.
Tran-proposal is then ordered w.r.t. other tran-proposals and broadcast to commiting peers (includes endorsing peers).
Commiting peers validate tran-proposal.readset has not been modified since simulation, and applies the tran-proposal.writeset ‘atomically’.
Overview of sample transaction (slides 1-7):
Separation of simulation (chaincode execution) and block validation/commit
Invocation of chaincode operation (business transaction) carried out in 3 phases:
Chaincode operation execution simulated on ‘endorsing’ peers.
Parallel simulation enabled on endorsers for improved concurrency and scalability since the simulation does not update the blockchain state
Simulation determines business tran-proposal: readset/writeset, and broadcasts this to the ordering service.
Tran-proposal is then ordered w.r.t. other tran-proposals and broadcast to commiting peers (includes endorsing peers).
Commiting peers validate tran-proposal.readset has not been modified since simulation, and applies the tran-proposal.writeset ‘atomically’.
Overview of sample transaction (slides 1-7):
Separation of simulation (chaincode execution) and block validation/commit
Invocation of chaincode operation (business transaction) carried out in 3 phases:
Chaincode operation execution simulated on ‘endorsing’ peers.
Parallel simulation enabled on endorsers for improved concurrency and scalability since the simulation does not update the blockchain state
Simulation determines business tran-proposal: readset/writeset, and broadcasts this to the ordering service.
Tran-proposal is then ordered w.r.t. other tran-proposals and broadcast to commiting peers (includes endorsing peers).
Commiting peers validate tran-proposal.readset has not been modified since simulation, and applies the tran-proposal.writeset ‘atomically’.
Overview of sample transaction (slides 1-7):
Separation of simulation (chaincode execution) and block validation/commit
Invocation of chaincode operation (business transaction) carried out in 3 phases:
Chaincode operation execution simulated on ‘endorsing’ peers.
Parallel simulation enabled on endorsers for improved concurrency and scalability since the simulation does not update the blockchain state
Simulation determines business tran-proposal: readset/writeset, and broadcasts this to the ordering service.
Tran-proposal is then ordered w.r.t. other tran-proposals and broadcast to commiting peers (includes endorsing peers).
Commiting peers validate tran-proposal.readset has not been modified since simulation, and applies the tran-proposal.writeset ‘atomically’.
Overview of sample transaction (slides 1-7):
Separation of simulation (chaincode execution) and block validation/commit
Invocation of chaincode operation (business transaction) carried out in 3 phases:
Chaincode operation execution simulated on ‘endorsing’ peers.
Parallel simulation enabled on endorsers for improved concurrency and scalability since the simulation does not update the blockchain state
Simulation determines business tran-proposal: readset/writeset, and broadcasts this to the ordering service.
Tran-proposal is then ordered w.r.t. other tran-proposals and broadcast to commiting peers (includes endorsing peers).
Commiting peers validate tran-proposal.readset has not been modified since simulation, and applies the tran-proposal.writeset ‘atomically’.
Overview of sample transaction (slides 1-7):
Separation of simulation (chaincode execution) and block validation/commit
Invocation of chaincode operation (business transaction) carried out in 3 phases:
Chaincode operation execution simulated on ‘endorsing’ peers.
Parallel simulation enabled on endorsers for improved concurrency and scalability since the simulation does not update the blockchain state
Simulation determines business tran-proposal: readset/writeset, and broadcasts this to the ordering service.
Tran-proposal is then ordered w.r.t. other tran-proposals and broadcast to commiting peers (includes endorsing peers).
Commiting peers validate tran-proposal.readset has not been modified since simulation, and applies the tran-proposal.writeset ‘atomically’.
Overview of sample transaction (slides 1-7):
Separation of simulation (chaincode execution) and block validation/commit
Invocation of chaincode operation (business transaction) carried out in 3 phases:
Chaincode operation execution simulated on ‘endorsing’ peers.
Parallel simulation enabled on endorsers for improved concurrency and scalability since the simulation does not update the blockchain state
Simulation determines business tran-proposal: readset/writeset, and broadcasts this to the ordering service.
Tran-proposal is then ordered w.r.t. other tran-proposals and broadcast to commiting peers (includes endorsing peers).
Commiting peers validate tran-proposal.readset has not been modified since simulation, and applies the tran-proposal.writeset ‘atomically’.
Based on kafka (https://kafka.apache.org).
3 initial consensus protocols expected:
SOLO - single node, maybe running on z or whatever but usually for development. Like No-ops but single node and proper consensus.
Kafka – ordering nodes need to be trusted for confidentiality, ordering-service must not leak across channels. Peers not trusted. Access control on the channel. The ordering-service sees the transactions, unless encrypted by the chaincode. Crash fault tolerant.
Simple BFT (SBFT) - complete code rewrite over v0.6. 97% PBFT. This model can cope with ordering nodes attempting to corrupt data. Need to resort to crypto at the chaincode level in v1, but in the future this will be provided in the fabric. Will include non-deterministic checking of chaincode output. Single channel (see later) supported for V1.
Partitioning for privacy makes sense only with non-BFT ordering-services. BFT ordering-services validate transactions across all validation nodes.
Channels do not need to be connected to by all nodes
Peers are permissioned to connect to a channel via an access control policy
Transactions broadcast to a channel are ordered by the ordering-service.
All peers receive transactions in exactly the same order for a channel.
Transactions are delivered in cryptographically linked blocks.
Each peer validates the delivered blocks and commits them to the ledger.
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.
This slide is an example of a Hyperledger Fabric V1 network with 2 channels.
Full command: docker-compose -f [orderer] up -d
Examples on following slides.
Polish notation is used to specify the policy.
Polish notation is used to specify the policy.
Used as building blocks for building access control frameworks
Membership Service Provider
at the system level (read/write access on system controls, and channel creation)
at the channel level (read/write access),
at the chaincode level (invocation access)
Can represent an organization consortium, an organization, or a subdivision
Hyperledger Fabric leverages it
Setup = {list of root CA certificates, revocation list, admin certificate}
Identity = standard X.509 certificate
SigningIdentity = {standard X.509 certificate with public key PK, private key SK for PK}
Identity Validity Conditions = Contains a valid signature from one of root CAs
Offers no anonymity
No attribute support
Offline issuing
Signature generation/verification = standard public key crypto operation