Slide 1

Slide 1 text

From 0 to 100: Permissioned blockchains with Hyperledger Fabric and Node Part 1 - Blockchain Ingo Rammer [email protected]

Slide 2

Slide 2 text

Ingo Rammer Co-Founder of Thinktecture AG Focus: B2B use of blockchain technologies, from code details up to ISO TC 307, Enterprise Ethereum Alliance and Hyperledger Foundation Manuel Rauber Consultant at Thinktecture AG Focus: cross-plattform frontends, .NET Core backends, technical prototyping, lead developer of .NET Chaincode layer for Fabric

Slide 3

Slide 3 text

Slides and Demo-Download Slides: within 24h at https://speakerdeck.com/ingorammer Code/demos: https://bit.ly/Fabric-Workshop-BTC2018 Reach us at @ingorammer - [email protected] @manuelrauber - [email protected]

Slide 4

Slide 4 text

• Blockchain fundamentals • Blocks, transactions, consensus, mining, smart contracts, … • Building blocks of a Fabric network • Transaction flow in Fabric • Chaincode basics – Fabric‘s smart contracts • Chaincode development end-to-end • Typical network configuration for Fabric Agenda

Slide 5

Slide 5 text

• Technology, not magic

Slide 6

Slide 6 text

Blockchain-Fundamentals with Phone Number Porting

Slide 7

Slide 7 text

Telco A Telco B 0151-123 123 123 John Doe 1/1/1960 0151-123 123 123 John Doe 1/1/1960 Fax, email, letter, ... SMS, email, letter, ...

Slide 8

Slide 8 text

Telco A Telco B 0151-123 123 123 John Doe 1/1/1960 0151-123 123 123 John Doe 1/1/1960 Fax, email, letter, ... SMS, email, letter, ... Well, for us everything seems ok. Please ask the others. ? Well, for us everything seems ok. Please ask the others.

Slide 9

Slide 9 text

• 3,437 registered telecom companies • 31% of all requests at regulator (19,000 cases, 3,000 escalations) • 300,000 EUR fines in 2016 Source: Yearly report 2016 of German network regulator, page 62 ff. (https://goo.gl/cPQcXV) Size of the problem (in Germany)

Slide 10

Slide 10 text

• Independent actors • Varying levels of trust between actors • Need for transparency (for example by trusted replica sets of data) • Without introducing central authorities Our Scenario

Slide 11

Slide 11 text

Blockchain Basics

Slide 12

Slide 12 text

"A blockchain [...] is a continuously growing list of records, called blocks, which are linked and secured using cryptography. Each block typically contains a cryptographic hash of the previous block, a timestamp and transaction data" Wikipedia, March 26, 2018 Blockchain – What is this?

Slide 13

Slide 13 text

Blockchain Genesis Block Block 1 Random Content Genesis Hash Content Genesis Hash Block 1 Hash Block 2 Content Block 1 Hash Block 2 Hash Block 3 Content Block 2 Hash Block 3 Hash Config

Slide 14

Slide 14 text

Node 1 Peer-to-Peer Replication Genesis Block Block 1 Block 2 Block 3 Node 2 Genesis Block Block 1 Block 2 Block 3 Node n Genesis Block Block 1 Block 2 Block 3 Block 4 Block 4 Block 4 Block 5 Block 5 Block 5

Slide 15

Slide 15 text

Node 1 Nodes are independent, without central authority Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Node 8 Node 9

Slide 16

Slide 16 text

Two main models of operation Public blockchains Ethereum, Bitcoin, ... Private blockchains Telco E Telco C Telco A Telco F Telco G Telco B Telco D BNA Telco X Consortiums, governments, ... ? ! Telco X

Slide 17

Slide 17 text

Public Blockchains • Identities of participants are unknown • Therefore: mining to secure the network's integrity (proof-of-work, Nakamoto consensus) • Typically, all data is public • Low transaction counts: <= 20 per seconds globally (Bitcoin, Ethereum)

Slide 18

Slide 18 text

Private Blockchains • Participants are known, access protected • Therefore: No mining necessary (proof-of-authority instead of proof-of-Work) E C A F G B D BNA X G #1 #2 #3 G #1 #2 #3 G #1 #2 #3 #4 • Transactions can be public or private (direct point-to-point exchange between two participants) • Massively higher transaction counts (hundreds, thousands or tens of thousand per second) • Technologies like Hyperledger Fabric

Slide 19

Slide 19 text

Blocks and Transactions

Slide 20

Slide 20 text

• Signed statements, which are immutable and can't be deleted ("transactions") What's in a Block? In practice: machine readable, for example as transaction records Our verified customer John Doe, born on 1/1/1911 wants to transfer his phone number 0151-123 123 123 from Telco A to us Signed: Telco B We're ok with this transfer Signed: Telco A

Slide 21

Slide 21 text

• Transactions are recorded in definitive sequence Properties of Transactions Block 1 Tx #1 Tx #2 Tx #3 Block 2 Tx #4 Tx #5 Block 3 Tx #6 Tx #7 Tx #8 Block 4 Tx #9 Block 5 Tx #10 ...

Slide 22

Slide 22 text

• Parts of transactions can be encrypted Properties of Transactions {"tx":"requestTransfer", "phone":"0151-123123123", owner: "TelcoA", encryptedCustomerData: "0xe2cbcf5f890afabc4dbd236d19f949db 05fcec2155..."} Signed: Telco B Encrypted with public key of Telco A

Slide 23

Slide 23 text

• Content can be hashes of external data Properties of Transactions {"tx":"requestTransfer", "phone":"0151-123123123", owner: "TelcoA", signedScannedContractHash: "0x80ebe76679b4812cde61d555c9026...", encryptedCustomerData: "..."} Signed: Telco B "I've got a PDF here (which I won't share) which has this hash" • To later prove the existance (at the time of block creation) and integrity of external data

Slide 24

Slide 24 text

• Data which has been transferred point-to-point can be referenced Properties of Transactions {"tx":"requestTransfer", "phone":"0151-123123123", owner: "TelcoA", externalDataHash: "0x5489b348f7a433...", } Signed: Telco B Hash-reference to a piece of data which has been sent directly • To ensure transaction privacy, only parties of the transactions will get access to its data (f.e. Fabric's private data collections)

Slide 25

Slide 25 text

Blockchain: replicated, immutable* sequence of transactions * Within clearly defined conditions. More about these later. Interium conclusion

Slide 26

Slide 26 text

Blockchains and Code

Slide 27

Slide 27 text

• How does the system check, whether or not a transation is valid? Validity of Transactions? We're ok with the transfer of phone number 0151-123 123 123 Signed: Telco B Telco C 0151-123 123 123 is not with Telco B, but belongs to us! • Solved by laws, contracts & penalties (post-fact) • Or by technology (pre-fact)

Slide 28

Slide 28 text

• Rules that define if a transaction is valid • Read and write "World State": the actual information in the blockchain Smart Contracts Number Owner 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z

Slide 29

Slide 29 text

Node 1 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z We are ok with the transfer of 0151-123 123 123 to Telco A. Signed: Telco B function confirmTransfer(number, transferTarget) { if (owner[number] == msg.sender) { owner[number] = transferTarget; } else throw; } owner[number] == msg.sender Cryptographic verification throw Transaction flagged as invalid Failed

Slide 30

Slide 30 text

Node 1 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z We are ok with the transfer of 0151-123 123 123 to Telco A. Signed: Telco C function confirmTransfer(number, transferTarget) { if (owner[number] == msg.sender) { owner[number] = transferTarget; } else throw; } owner[number] == msg.sender Cryptographic verification owner[number] = transferTarget; Changes World State Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z OK

Slide 31

Slide 31 text

All nodes need the same version of smart contracts to work correctly!

Slide 32

Slide 32 text

Docker-Container (managed) How are smart contracts executed? Ethereum Node Inside a node Configured Process Smart Contract Execution Environment Tendermint Node Server-Code (Interface- convention: ABCI) Contract Creation Transaction Process start & config GRPC/Socket Managed Container Hyperledger Fabric Node Chaincode (Go, JS via Go-Bridge) Socket peer chaincode install

Slide 33

Slide 33 text

Collisions in most classic blockchains (NB: Fabric is different!)

Slide 34

Slide 34 text

Node 1 17 ... 18 19 20 Node 3 17 ... 18 19 20 Node 2 17 ... 18 19 20 Node 4 17 ... 18 19 20 21a 21a 21a 21b 21b 21b 21a 21a 21b 21b

Slide 35

Slide 35 text

Node 1 17 ... 18 19 20 Node 3 17 ... 18 19 20 Node 2 17 ... 18 19 20 Node 4 17 ... 18 19 20 21a 21a 21b 21b 21a 21a 21b 21b

Slide 36

Slide 36 text

Node 1 17 ... 18 19 20 Node 3 17 ... 18 19 20 Node 2 17 ... 18 19 20 Node 4 17 ... 18 19 20 21a 21a 21b 21b 21a 21a 21b 21b 22 22 22 22 23 22 22 22 22 23 23 23

Slide 37

Slide 37 text

• Usually, only one node creates a new block (algorithmic selection for each block) • Especially in proof-of-work blockchains: • Collisions: Protocol-specific definition of correct chain • Number of confirmations! • In Proof-of-Authority: during network disconnect

Slide 38

Slide 38 text

• Smart Contracts - or rather their side effects - have to be deterministic for all relevant nodes • Communication with off-chain services: asynchronous (events) with signed answer- transaction to original requester • This concept is called "oracle" Smart Contracts & external data

Slide 39

Slide 39 text

Blockchain: replicated, immutable sequence of transactions, confirming to certain rules Conclusion

Slide 40

Slide 40 text

Blockchains are replicated databases which use decentralized code execution (smart contracts) to achieve early and shared consensus about their data (instead of later re-conciliation)

Slide 41

Slide 41 text

Part 2 – Hyperledger Fabric

Slide 42

Slide 42 text

• Hyperledger itself is not a technology, but a project of the Linux Foundation • An umbrella for blockchain technologies • For example Fabric, Sawtooth, Iroha, Indy, … • Additional tools • Cello, Explorer, Composer What is Hyperledger?

Slide 43

Slide 43 text

• A platform to create private, permissioned blockchains • Created mainly for B2B use • Not ICOs, public cryptocurrencies, … • Original creators and main drivers: IBM • Governance-constructs built in • The backend for IBM, Oracle, SAP, ... Blockchain offerings What is Fabric?

Slide 44

Slide 44 text

• Organizations • Peers & Orderer • Chaincode & State-DB (f.e. CouchDB) • Endorsement & Policies • Channels and Private Data Collections Key Concepts

Slide 45

Slide 45 text

A Fabric Network

Slide 46

Slide 46 text

Organizations: Participants in a network Telco 1 Telco 2 Regulator

Slide 47

Slide 47 text

Organizations: provide certs for their users Telco 1 Telco 2 Regulator Provide membership services (CAs) for peer nodes and users (MSP => Membership Service Provider)

Slide 48

Slide 48 text

Organizations: Can operate peers Telco 1 Telco 2 Regulator

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

• A Fabric network consists of multiple peers • Peers can join channels • Channels are independent blockchains • Only the participants of a channel can see its data • Channels are permissioned! • Transient or permanent subsets: private data collections Channels are blockchains!

Slide 51

Slide 51 text

Smart Contracts and Fabric

Slide 52

Slide 52 text

• Can theoretically be written in any programming language which understands GRPC • SDKs available for Go, Node.js, Java; .NET in progress • Can interact (read/write) with the ledger's data • Run in separate docker container Chaincode == Smart Contracts

Slide 53

Slide 53 text

Chaincode Deployment peer1.telco1.com peer1.regulator.com Node.js sources Chaincode Package (name & version) Install (by admin of organization) peer chaincode package <…> peer chaincode install <…> peer chaincode install <…> numbertransfer, v1 numbertransfer, v1 Note: Packaging is optional, both admins could install from source.

Slide 54

Slide 54 text

Chaincode Instantiation peer1.telco1.com peer1.regulator.com numbertransfer, v1 numbertransfer, v1 channel1 peer chaincode instantiate -n numbertransfer -v v1 -C channel1 -P numbertransfer:v1

Slide 55

Slide 55 text

Deployment of Version 2 peer1.telco1.com peer1.regulator.com Node.js sources for v2 peer chaincode install <…> peer chaincode install <…> numbertransfer, v1 numbertransfer, v1 Note: We could have installed using a package as well. (Like before) numbertransfer, v2 numbertransfer, v2

Slide 56

Slide 56 text

peer1.telco1.com peer1.regulator.com numbertransfer, v1 numbertransfer, v1 numbertransfer, v2 numbertransfer, v2 Chaincode Upgrade channel1 peer chaincode upgrade -n numbertransfer -v v2 -C channel1 -P numbertransfer:v1 numbertransfer:v2

Slide 57

Slide 57 text

• 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

Slide 58

Slide 58 text

• How is the chaincode executed? • Upon the first transaction (or instantiation for the initial node), a docker image (and container) is created and started • Can you stop/remove chaincode? • Only manually by stopping the container, removing the image and deleting the directory on the host (http://bit.ly/CC_for_ops_1_3) • Do I need to keep all versions around? • No: because of how endorsement works with Fabric • Does every node need access to the chaincode? • No: because of how endorsement works with Fabric Chaincode FAQs

Slide 59

Slide 59 text

Endorsement Policies numbertransfer version: v1 endorsementpolicy: AND( 'Regulator.member', OutOf( 2, 'Telco1.member', 'Telco2.member', 'Telco3.member' ) ) channel1 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49151123456'] } peer1.telco1.com numbertransfer, v1 peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1 Important: Nodes outside of current organization only see public "anchor nodes" for other organizations (configured channel by channel)

Slide 60

Slide 60 text

numbertransfer version: v1 endorsementpolicy: AND( 'Regulator.member', OutOf( 2, 'Telco1.member', 'Telco2.member', 'Telco3.member' ) ) channel1 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49151123456'] } peer1.telco1.com numbertransfer, v1 peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1 Endorsement Policies

Slide 61

Slide 61 text

Endorsement Policies numbertransfer version: v1 endorsementpolicy: AND( 'Regulator.member', OutOf( 2, 'Telco1.member', 'Telco2.member', 'Telco3.member' ) ) channel1 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49151123456'] } peer1.telco1.com numbertransfer, v1 peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1

Slide 62

Slide 62 text

Endorsement Policies numbertransfer version: v1 endorsementpolicy: AND( 'Regulator.member', OutOf( 2, 'Telco1.member', 'Telco2.member', 'Telco3.member' ) ) channel1 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49151123456'] } peer1.telco1.com numbertransfer, v1 peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1

Slide 63

Slide 63 text

• Every operation in Fabric is permissioned • https://hyperledger-fabric.readthedocs.io/en/release-1.3/policies.html • https://hyperledger-fabric.readthedocs.io/en/release-1.3/endorsement-policies.html • Configurable policies • Any, all, m-out-of, majority (for config changes) • And, Or Permissions and Policies AND ('Regulator1.Admin', OutOf(2, 'Telco1.Admin', 'Telco2.Admin', 'Telco3.Admin'))

Slide 64

Slide 64 text

• Essential for Fabric transaction flow • Orderers are ... • ... consensus-forming nodes • ... block creators • Orderers transfer blocks to peers; no direct peer- to-peer sync of the blockchain Orderers

Slide 65

Slide 65 text

Fabric Transaction Flow

Slide 66

Slide 66 text

• Proposal, Endorsement & Simulation • Ordering & distribution • Ledger updates Three Phases

Slide 67

Slide 67 text

Proposal & Endorsement - Client's View { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49123123123', 'Telco2'] } peer1.telco1.com numbertransfer, v1 peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1 2) Determine policy (Static or discovery) 3) Select endorsers (peer URLs) peer1.telco2.com numbertransfer, v1 peer1.telco3.com numbertransfer, v1 peer1.regulator.com numbertransfer, v1 4) Send proposal directly to endorsers 5) Endorsers simulate transactions 6) Collect endorsements and verify 1) Create and sign proposal

Slide 68

Slide 68 text

peer1.telco2.com Simulation & Endorsement - Peer's View Key Value Version 49123123123 Telco1 B1/Tx0 491111111111 Telco2 B23/Tx1 491111111112 Telco3 B4/Tx0 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49123123123', 'Telco2'] } Signed: Telco1 // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } Update state Verification of rules

Slide 69

Slide 69 text

peer1.telco2.com Simulation & Endorsement - Peer's View Key Value Version 49123123123 Telco1 B9/Tx0 491111111111 Telco2 B23/Tx1 491111111112 Telco3 B4/Tx0 { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49123123123', 'Telco2'] } Signed: Telco1 // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } // still simplified pseudocode! function confirmTransfer(number, transferTarget) { if (ctx.clientIdentity.mspId == await getState(number)) { await putState (number, transferTarget); } else throw; } Endorsement Read Set Write Set Read Set Key: '49123123123': Version: {Block: 9, Transaction: 0} Write Set Key: '49123123123': New Value: 'Telco2' Signed: peer1.telco2.com

Slide 70

Slide 70 text

• Transactions are processed on a client-selected subset of peers • Policy is defined during instantiation or upgrade of a chaincode • “Regulator AND two of Telco A, Telco B, or Telco B“ • Endorsers sign off on transactions after chaincode simulation (no ledger changes, only simulation!) Endorsement

Slide 71

Slide 71 text

Transaction Request Collecting all endorsements on the client Proposal { chaincodeId: 'numbertransfer', fcn: 'confirmTransfer', args: ['49123123123', 'Telco2'] } Read Set Key: '49123123123': Version: {Block: 9, Transaction: 0} Write Set Key: '49123123123': New Value: 'Telco2' Signed: peer1.telco1.com, creator Signed: peer1.telco2.com, endorser Signed: peer1.telco3.com, endorser Signed: peer1.regulator.com, endorser

Slide 72

Slide 72 text

Orderer Ordering, distribution and incorporation Transaction Message Proposal Read Set Write Set peer1.telco1.com peer1.telco2.com peer1.telco3.com peer1.regulator.com channel1 channel2 channel1 channel1 channel1 channel1 2) Orderers forms consensus and create a new block 3) New block is distributed to peers 4) Peers check that block comes from valid orderer 5) Peers add the block to their chains and process transactions 1) Client sends TX message to one orderer

Slide 73

Slide 73 text

• Responsibility of orderers: • Form consensus about the sequence of transactions • Create blocks consisting of individual transactions • Distribute the resulting blocks • NOT: check if transactions are valid/endorsed! • Today, there are two completed consensus options: "Solo" and "Kafka" • CFT (etcd/raft) and BFT are work in progress Orderers create blocks

Slide 74

Slide 74 text

peer1.telco2.com Transaction handling at peers - Scenario: block #71 Key Value Version 49123123123 Telco1 B9/Tx0 491111111111 Telco2 B23/Tx1 491111111112 Telco3 B4/Tx0 Endorsement Read Set Key: '49123123123': Version: {Block: 9, Transaction: 0} Write Set Key: '49123123123': New Value: 'Telco2' 2) Verify endorsement, else flag as ENDORSEMENT_POLICY_FAILURE and stop 3) Compare the read-sets, else flag as MVCC_READ_CONFLICT and stop 4) Update state (and version!) and flag as VALID 1) Take each transaction from the block IMPORTANT: No chaincode execution at this stage! Key Value Version 49123123123 Telco2 B71/Tx0 491111111111 Telco2 B23/Tx1 491111111112 Telco3 B4/Tx0

Slide 75

Slide 75 text

• Client uses SDK to create a proposal and send it to endorsers • Endorsers simulate chaincode execution; sign read-set and write-set • Client uses SDK to verify endorsement (optional) • Client sends transaction (proposal + endorsement) to orderer • Orderers create a block (for one channel) and broadcast to peers • Peer verifies endorsement and read-set against its copy of the ledger • If ok, the peer incorporates the write-set in its copy of the ledger • Erroneous transactions remain in the blockchain but will be flagged Complete Fabric Transaction Flow

Slide 76

Slide 76 text

Let's look at this in context & code

Slide 77

Slide 77 text

• Organizations: Regulator, Telco1, Telco2, Telco3 • Each with one peer and a CouchDB state database • One orderer (Solo) • In Docker: also CLI nodes for each org, which contain tools Our Demo Network

Slide 78

Slide 78 text

• https://github.com/hyperledger/fabric-chaincode-node • New API: https://www.npmjs.com/package/fabric-contract- api • Currently doc bug: "startchaincode" vs "chaincodestart" in package.json Chaincode with Node.js

Slide 79

Slide 79 text

• Tip: use a single-peer endorsement policy • Start peer with --peer-chaincodedev=true • Start chaincode to connect to peer: Debugging Chaincode export CORE_CHAINCODE_ID_NAME=simplecontract:v0 # : node node_modules/fabric-shim/bin/chaincodestart --peer.address grpc://localhost:7052

Slide 80

Slide 80 text

• Install – physical deployment to a peer • Instantiate – logical binding to a channel; specifies endorsement policies and private data collections • Invoke – send a TX to chaincode (Docker container started on demand!) • Query – retrieve read-only data • Upgrade – binding of a different chaincode to a channel (incl. new policies) Chaincode Lifecycle

Slide 81

Slide 81 text

Fabric Network Setup

Slide 82

Slide 82 text

• http://hyperledger-fabric.readthedocs.io/en/latest/install.html • https://github.com/hyperledger/fabric-samples • Deployment: typically as Docker images to start containers for peers and chaincode Installing Fabric

Slide 83

Slide 83 text

• In Docker image hyperledger/fabric-tools • cryptogen – generate certificates if not using a CA • configtxgen – create configuration transactions • configtxlater – translator between different config representations Base Fabric tools

Slide 84

Slide 84 text

Please note: The step numbers on the following slides refer to the scripts/node sources in the demo download

Slide 85

Slide 85 text

• Create an initial network with DemoOrg1 and DemoOrg2 and one application channel (#001 to #004) • Deploy and instantiate chaincode #005 to #007 (#006 is optional for debugging) • Interact with chaincode (in ./nodejs): #008 to #011 • Examine chaincode events #100/#101 (in ./nodejs) • Query peers and discovery #102/#103 Initial Scenario Overview

Slide 86

Slide 86 text

• Cryptogen reads cryptoconfig.yaml • Creates root CAs (for each organization), private keys and certificates for peers, Admins and users • Output in ./crypto-config • Important: in real life, each organization would generate its part independently and only share the public certificate, but not the private keys Step 001 – Generate base cryptographic material

Slide 87

Slide 87 text

• Configtxgen reads different profiles in configtx.yaml (in demo download) • Generates genesis block for network itself • Generates genesis block for demochannel • Generates anchor peer update for DemoOrg1 • Generates anchor peer update for DemoOrg2 Step 002 – Create transactions for initial network

Slide 88

Slide 88 text

• Docker containers are started using the configuration in docker- compose.yaml • The CORE_* environment variables in docker-compose.yaml refer to entries in core.yaml • CORE_PEER_LOCALMSPID for example overrides core.peer.localMspId • FABRIC_CFG_PATH is set to /etc/hyperledger/fabric in the docker images. This directory contains core.yaml. • Important: if you want to debug chaincode, you should configure one of the peers to start with --peer-chaincodedev Step 003 – Start containers

Slide 89

Slide 89 text

• Wait 5-10 seconds after starting the containers to allow the nodes to fully start up before running 004! • In #004, the transactions from #002 are sent to the network (using docker –exec on the fabric-tools nodes) • A channel is created, both DemoOrg1 and DemoOrg2 join the channel and Step 004 – Create Channels

Slide 90

Slide 90 text

• Chaincode is installed on either one node only, or also on a second node • peer chaincode install is executed in the cli container (based on the image fabric-tools) • If you want to debug your code, you can use 006 to start the chaincode process Steps 005 and 006 – Installing Chaincode

Slide 91

Slide 91 text

• Chaincode is instantiated for the channel 'demochannel' • Depending on the script you choose at this step, the endorsement policy will be one of: • DemoOrg1 • DemoOrg1 AND DemoOrg2 Step 007 – Instantiating Chaincode

Slide 92

Slide 92 text

• In steps 008 to 011 (in ./nodejs), you will see different ways to interact with the chaincode • With or without discovery • With or without waiting for TX completion • Finally with a "nicer" code structure Steps 008 to 011 – Interact with Chaincode

Slide 93

Slide 93 text

• 200-208 (203 & 208 are node.js): Adding a member to the network • Generate cryptographic assets, start containers • Pull current config block (genesis or latest config update) • Create a "target" configuration and use configtxlator to calculate difference update from current config • Have majority of existing member sign the config update • Submit it to the orderer Additional scripts for your networks

Slide 94

Slide 94 text

• 300-303: upgrade and downgrade channel chaincode versions • Including change of endorsement policy • Documentation (architecture overview) states that multiple signatures can be required for chaincode instantiation; this is however not yet implemented Additional scripts for your networks

Slide 95

Slide 95 text

• Blockchain fundamentals • Blocks, transactions, consensus, mining, smart contracts, … • Building blocks of a Fabric network • Transaction flow in Fabric • Chaincode basics – Fabric‘s smart contracts • Chaincode development end-to-end • Typical network configuration for Fabric What have we seen today?

Slide 96

Slide 96 text

Slides and Demo-Download Slides: within 24h at https://speakerdeck.com/ingorammer Code/demos: https://bit.ly/Fabric-Workshop-BTC2018 Reach us at @ingorammer - [email protected] @manuelrauber - [email protected]

Slide 97

Slide 97 text

EXTRA CONTENT

Slide 98

Slide 98 text

a) Do you have independent participants? • No central authority? • No asymmetric power concentration? • Is everyone participating voluntarily? b) Do you need transparent and immutable shared data? c) Do you need trusted shared code execution? Can blockchains support my use case?

Slide 99

Slide 99 text

Your business model should be decentralized to use decentralized technology. If your business model is a database, use a database. Put an API in front. It's much simpler.

Slide 100

Slide 100 text

Three main classes of use cases for blockchains

Slide 101

Slide 101 text

Documenting Collaborating Transforming • „Timestamping“ • Put a hash of your private documents or data on a blockchain • Technical proof of integrity and existence of documents and data at a certain point in time • Relatively easy to implement, quick ROI • No – or only small – focus on smart contracts

Slide 102

Slide 102 text

Documenting Collaborating Transforming • Data exchange and process transparency • States of processes managed via blockchain • Digitization of paper processes between companies • Phone number porting • „Loi Hamon“ in France

Slide 103

Slide 103 text

Documenting Collaborating Transforming • Create new business opportunities and markets • Reality check: Increased complexity due to the number of stakeholders

Slide 104

Slide 104 text

• Problem with car insurance • Risk assessment (and policy pricing) based on number of years of accident-free car ownership • But what about car sharing users? (2M+ users in Germany) • Challenges • GDPR-conforming data processing • Scaling to lots of parties on all sides (no point-to-point interfaces) • Data should survive bankruptcy of a party (no on-demand generation) Case: Accident-free carsharing kms per year

Slide 105

Slide 105 text

Customer generates digital ID (in browser or on a membership card, …) Carsharing provider • Connect digital ID with provider's customer ID • Opt-in on web site Insurer Blockchain May 2018 Cust 1122 – 97 km May 2018 Cust 5745 – 34 km June 2018 Cust 1122 – 535 km June 2018 Cust 5745 – 16 km Customer Periodic publication of data

Slide 106

Slide 106 text

Carsharing provider Insurer Blockchain 239587030 4957443873 459089845 3458999… 947989834 5345534524 958458205 755345… 9447757234 2349348572 345580923 84949283… 209389084 923840982 342394820 9348934… Customer Publication of signed data, encrypted with the public key of each customer Customer can decrypt her data at any time. Nobody else can. May 2018 Cust 1122 – 97 km - Provider1 June 2018 Cust 1122 – 535 km - Provider1 Customer can pass data to third parties after decryption. Even if the creator of the data does not exist anymore. (Ultimate data sovereignty)

Slide 107

Slide 107 text

Carsharing provider #1 Insurer 1 Blockchain Customer Carsharing provider #2 Rental car provider Insurer 2 Insurer 3 0304... 4586... 6436... 9384... 5463... 5854... … Feb 2018, 50 km, Stadt- mobil Feb 2018, 25 km, DB March 2018, 1534 km, Sixt Transfer by customer!

Slide 108

Slide 108 text

How do transactions get into the blocks in other blockchain platforms like Ethereum?

Slide 109

Slide 109 text

Node 1 – Max Block: 20 Node 1 – Max Block: 21 Node 2 – Max Block: 20 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Node 3 – Max Block: 20 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Block 21 (in progress) Tx #78 Tx #79 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Pending Transactions (Mempool, p2p Sync) Tx X Tx Y Tx Y Tx Z Tx Z Tx X Tx X Tx Z Tx Y Smart contract execution for #78 Failed! Smart contract execution for #79 Block hash Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z Block closed

Slide 110

Slide 110 text

Node 1 – Max Block: 20 Node 1 – Max Block: 21 Node 2 – Max Block: 20 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Node 3 – Max Block: 20 Key Value 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z Pending Transactions (Mempool, p2p Sync) Tx Z Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash

Slide 111

Slide 111 text

Node 1 – Max Block: 20 Node 1 – Max Block: 21 Node 2 – Max Block: 21 Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z Node 3 – Max Block: 21 Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z Key Value 0151123123123 Telco A 01511111111111 Telco A 01511111111112 Telco Z Pending Transactions (Mempool, p2p Sync) Tx Z Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash Block 21 Block 21 Block 21 Block 21 Tx #78 Tx #79 Failed! Block hash

Slide 112

Slide 112 text

Block Creator

Slide 113

Slide 113 text

• Who creates the next block? (Or: "who could rewrite the history of the chain?) • Crypto-economic techniques • Proof-of-Work: Crypto riddle (power consumption!) • Proof-of-Stake: Monetary penalties • Proof-of-Authority: Contractual agreements Selecting a node to create blocks

Slide 114

Slide 114 text

Where are the clients?

Slide 115

Slide 115 text

AWS for Telco B DC Telco Z Azure Azure (VM Telco C) DC Telco A Client (Telco A) Client (Telco X) Client (Telco Y) Client (Telco Z) Node 1 Node 2 Node 3 (Telco A) Node 4 Node 5 Node 6 (Telco B) Node 7 (Telco C) Client (Telco B) DC Telco C Client (Telco C) Client – has private key Node is part of BC Connection to trusted node (grpc/grpcs, ...)

Slide 116

Slide 116 text

Thank you! • Slides: https://speakerdeck.com/ingorammer • Contact: [email protected] • Twitter: @ingorammer