OOP 2019: Hyperledger Fabric – Architecture and Smart Contracts of the Open Source Blockchain

In this session at OOP 2019 in Munich, Ingo Rammer presented the originally IBM initiated - and nowadays Linux Foundation hosted - open source blockchain Hyperledger Fabric.

Transcript

1. Hyperledger Fabric Architecture and Smart Contracts of the Open Source Blockchain Ingo Rammer ingo.rammer@thinktecture.com
2. Ingo Rammer Co-Founder of Thinktecture AG, a 20-people technical consulting company helping software architects and developers utilize new and upcoming technologies. My personal focus: B2B use of blockchain technologies, from code details up to ISO TC 307 Slides: https://thinktecture.com/presentations Contact: ingo.rammer@thinktecture.com Twitter: @ingorammer
3. • Why private blockchains, why Fabric? • Building blocks of a Fabric network • Transaction flow in Fabric • Chaincode and Client SDK fundamentals Agenda
4. • Semi-trusted scenarios with known participants • Not “code is law”, but “law is law”; proof-of-work mining not necessary • B2B interactions • Digitalization of paper processes • Distributed ledger as single source of truth, to avoid re-consolidation needs • For example: phone number porting between telcos • Would a replicated database be enough? • Maybe, but: data integrity, neutrality of operator, code execution/versioning, data and code governance • For transaction-private data: necessity for additional point-to-point network with only hashes on blockchain Private and permissioned blockchains
5. • Hyperledger: an umbrella-project of the Linux foundation, for blockchain technologies (Fabric, Sawtooth, Indy, Iroha, …) • Fabric: A platform to create private, permissioned blockchain networks • Created mainly for B2B use • Not ICOs, public cryptocurrencies, … • Permissioning and governance constructs built in: • Authorization: organizations, federated users/groups, … • Governance: majority, m-out-of-n, … • The backend for IBM, SAP, Oracle, ... blockchain offerings What is Hyperledger Fabric?
6. Key concepts of a Fabric network
7. Organizations: Participants in a network Telco 1 Telco 2 Regulator
8. Telco 1 Telco 2 Regulator Organizations operate peer nodes
9. Orgs provide federated identity for users & nodes Telco 1 Telco 2 Regulator Organizations provide membership services (CAs) for users and peer nodes (MSP => Membership Service Provider)
10. Channel 1 Channel 2 Peers can join channels peer1.telco1.com peer1.telco2.de peer1.regulator.com
11. • Channels are independent blockchains • Only the participants of a channel can see its data • Channel access is permissioned and governed • Transient or permanent subsets: private data collections • Smart contracts are managed on channel-by- channel basis Channels are blockchains
12. • Chaincode == Smart Contracts in Fabric • Deployed to a subset of nodes • Versioned, permissioned Chaincode
13. Transaction flow and consensus in Fabric
14. Client app O1 O2 O3 O4 E1 E2 E3 P2 P1 C1 C1 C2 C1 P E O C Endorser Orderer Peer (Committer) Chaincode
15. P E O C Endorser Orderer Peer (Committer) Chaincode Client app O1 O2 O3 O4 E1 E2 E3 P2 P1 C1 C1 C2 C1 Tx 1) Client creates Transaction Proposal and sends it to endorsers 2) Endorsers simulate transaction and sign off Tx 3) Client sends endorsed TX to orderer network 4) Orderers include TX in subsequent block 5) Orderers send block to all peers S D K 6) Peers validate endorsement & concurrency. Incorporate block in their chains and state DBs Other app S D K 7) Peers deliver events to subscribers
16. • Endorsement, Ordering, Validation • Endorsement: subset of peers decides whether a transaction is ok/not ok (according to chaincode) • Ordering: sequencing of transactions & packaging into blocks • Validation: before commit, each peer verifies endorsement policies and concurrency Three Phases of Consensus
17. Smart Contracts in Fabric
18. • Read and write State DB (f.e. CouchDB) on local node to verify ledger changes • Can be written in different programming languages • SDKs available for Go, Node.js, Java Fabric Chaincode Fundamentals
19. • Verify permissions and/or asset ownership • Get state from state DB • Update world state in DB, change asset ownership • Put/Delete state in state DB • Emit events to SDK listeners Main programming tasks in Chaincode
20. const {Contract} = require('fabric-contract-api'); class SimpleContract extends Contract { constructor() { super('com.example.simple'); } async myOperation(ctx, param1, param2) { // ... } } module.exports.contracts = [SimpleContract]; { chaincodeId: 'simplecontract', fcn: 'com.example.simple.myOperation', args: ['10', 'abc'], // ... } Interface to Fabric for interaction with transaction-data and state DB
21. // reading values let someValue = await ctx.stub.getState('myKey'); // query multiple values let result = await ctx.stub.getQueryResult(...); // storing values let newValue = 1234; await ctx.stub.putState('myKey', Buffer.from(newValue.toString())); // setting an event await ctx.stub.setEvent('valuechanged', Buffer.from(newValue.toString())); // access the client's identity (transaction signer) if (ctx.clientIdentity.mspId == "Telco1") { ... }
22. Fabric Client Development Example: Node.js
23. Initializing the client let FabricClient = require('fabric-client'); let client = new FabricClient(); await client.createUser(/* ... supply cryptographic information */); let channel = client.newChannel('demochannel'); let peer = client.newPeer('grpc://localhost:7061'); await channel.initialize({discover: true, target: peer});
24. Invoking Chaincode let txId = client.newTransactionID(); let proposalRequest = { txId: txId chaincodeId: 'simplecontract', fcn: 'com.thinktecture.simplecontract.myOperation', args: ['10', 'abc'], // everything is passed as string }; let result = await channel.sendTransactionProposal(proposalRequest); let request = { proposalResponses: result[0], proposal: result[1] }; let submissionResult = await channel.sendTransaction(request);
25. Chaincode Lifecycle
26. Chaincode Deployment peer1.telco1.com peer1.regulator.com Chaincode package or source code Install (by admin of an organization) peer chaincode install <…> peer chaincode install <…> numbertransfer, v1 numbertransfer, v1
27. Chaincode Instantiation peer1.telco1.com peer1.regulator.com numbertransfer, v1 numbertransfer, v1 channel1 peer chaincode instantiate <…> numbertransfer:v1
28. • Chaincode is packaged and explicitly installed on individual peers • Not all peers need each chaincode • Chaincode can exist in multiple versions on a peer • Chaincode is instantiated for one of more channels • Instantiation == Binding of a particular chaincode version to a channel via a specific endorsement policy • Chaincode can be upgraded for a channel (=> bound to a different existing chaincode version on the peers) Chaincode / Smart Contracts
29. • Nearly every operation in Fabric is permissioned • Configuration changes, channel membership, ... • Chaincode endorsement policies Permissions and Policies AND ('Regulator1.Admin', OutOf(2, 'Telco1.Admin', 'Telco2.Admin', 'Telco3.Admin')) • Any, all, m-out-of, majority (for config changes) • And, Or
30. • Building blocks of a Fabric network • Transaction flow in Fabric • Chaincode basics – Fabric‘s smart contracts • Client SDK overview • Brief glance into permissioning What have we seen today?
31. Thank you! Slides: https://thinktecture.com/presentations Contact: ingo.rammer@thinktecture.com Twitter: @ingorammer