Blockchain explored

1. Blockchain Explored A Technical Deep-Dive on Hyperledger Fabric V1 Blockchain Architected Blockchain Explored Blockchain Solutions Blockchain Composed Next Steps Blockchain Explained IBM Blockchain Platform V4.02, 29 November 2017

2. Project Status and Roadmap Technical Deep Dive

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”

7. Project Status and Roadmap Technical Deep Dive

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

27. 27 Hyperledger Fabric Network E0 E1 E2 E3 A BA B Bootstrap Network (4/6) – Create Channels A B Channels are created on the ordering service: $ peer channel create –o [orderer] ... 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

46. Thank you www.ibm.com/blockchain developer.ibm.com/blockchain www.hyperledger.org © Copyright IBM Corporation 2017. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. Any statement of direction represents IBM's current intent, is subject to change or withdrawal, and represents only goals and objectives. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

Blockchain explored

IBM Sverige

Blockchain explored