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
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.
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)
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?
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)
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
("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
{"tx":"requestTransfer", "phone":"0151-123123123", owner: "TelcoA", encryptedCustomerData: "0xe2cbcf5f890afabc4dbd236d19f949db 05fcec2155..."} Signed: Telco B Encrypted with public key of Telco A
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
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)
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)
Read and write "World State": the actual information in the blockchain Smart Contracts Number Owner 0151123123123 Telco C 01511111111111 Telco A 01511111111112 Telco Z
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
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
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
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
of the Linux Foundation • An umbrella for blockchain technologies • For example Fabric, Sawtooth, Iroha, Indy, … • Additional tools • Cello, Explorer, Composer What is Hyperledger?
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?
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!
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
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
• 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
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
• 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
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
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
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
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
– 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
if not using a CA • configtxgen – create configuration transactions • configtxlater – translator between different config representations Base Fabric tools
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
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
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
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
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
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
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
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
… • 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?
• 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?
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
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
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
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)
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!
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
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
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, ...)