Hyperledger Fabric Architecture and Smart Contracts of the Open Source Blockchain Ingo Rammer ingo.rammer@thinktecture.com

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

• Why private blockchains, why Fabric? • Building blocks of a Fabric network • Transaction flow in Fabric • Chaincode and Client SDK fundamentals Agenda

• 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

• 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?

Key concepts of a Fabric network

Organizations: Participants in a network Telco 1 Telco 2 Regulator

Telco 1 Telco 2 Regulator Organizations operate peer nodes

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)

Channel 1 Channel 2 Peers can join channels peer1.telco1.com peer1.telco2.de peer1.regulator.com

• 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

• Chaincode == Smart Contracts in Fabric • Deployed to a subset of nodes • Versioned, permissioned Chaincode

Transaction flow and consensus in Fabric

Client app O1 O2 O3 O4 E1 E2 E3 P2 P1 C1 C1 C2 C1 P E O C Endorser Orderer Peer (Committer) Chaincode

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

• 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

Smart Contracts in Fabric

• 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

• 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

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

// 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") { ... }

Fabric Client Development Example: Node.js

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});

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);

Chaincode Lifecycle

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

Chaincode Instantiation peer1.telco1.com peer1.regulator.com numbertransfer, v1 numbertransfer, v1 channel1 peer chaincode instantiate <…> numbertransfer:v1

• 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

• 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

• 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?

Thank you! Slides: https://thinktecture.com/presentations Contact: ingo.rammer@thinktecture.com Twitter: @ingorammer