Hyperledger Fabric V1

The Linux Foundation is the organization of choice for the world's top developers and companies to build ecosystems that accelerate open technology development and commercial adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company.

The Linux Foundation has 16 years experience of providing governance structure and infrastructure to support the development of large scale, successful open source projects such as:

About The Linux Foundation

– Open Ledger Project announced December 17, 2015 with 17 founders, now over 80 members

– Hyperledger Project rebrand in February 2016

– Collaborative effort to advance Blockchain technology by identifying and addressing important features for a cross-industry open standard for distributed ledgers that can transform the way business transactions are conducted globally

– Open source, open standards, open governance

Enable adoption of shared ledger technology at a pace and depth not achievable by any one

company or industry

QUICK FACTS

Chairman Blythe Masters/DAH

Executive Director Brian Behlendorf

Technical Chair Chris Ferris/IBM

Contribution 44,000 lines of code in February 2016

Sprint to one codebase with unified thinking

Staged releases

www.Hyperledger.org

Linux Foundation’s Hyperledger Project

4

Jul Sept Dec MarAug Oct Nov Jan Feb

• Custom events• Version indicator (log

and cli)• CC deploy SDK API

• Member services 1• Enhance Ledger API• Status codes & msg’s• Event listener SDK

• Consensus 1• Life-cycle SCC• Error handling• Tx simulation rw-set• File-based datastore

• Enhance protocol• Life-cycle SCC• SDK specification• SDK submitting TX

• ACL• Kafka 1• Multichannel 1• HSM support PKCS11

• Auditability API• State cache• Upgrade chaincode• Kafka 2• Multichannel 2

• Sec code hardening• Bug fixes

• Bug fixes

• Bug fixes

Skeleton drop - 11/11/16 Complete basic transaction flow of v1.0 architecture, from node.js SDK to commit on block.

Alpha drop of v1.0 -12/17/16 Previous Alpha features move to Beta, additional features introduced as Alpha.

Beta driver of v1.0 – 1/31/17Previous Alpha features move to Beta, additional features introduced as Alpha

GA - 3/31/17

Hyperledger Fabric: Updated Roadmap and Releases

4

Overview of Hyperledger Fabric v1

Today’s V0.6 Hyperledger Fabric Blockchains

• InaPBFTblockchain network,smartcontract(chaincode)isrunonall validatingnodes.

• Iftherearealargenumberofpeerswithupdatetransactionsbeingsubmitted,thenetworkmaynotscalewell.

• Forexample,takeanetworkbuiltaroundvehicleleasingintheUK:

• WithPBFT,theDVLA,allthemanufacturers,andalltheleasingcompanieshavetoprocesseveryupdatetransaction,iftheyallruntheirownvalidatingnodes.

6

DVLA Audi

BMW Mazda

Ford

Fiat

ToyotaFiatSkodaTop

LeaseLease Plus

GoGoLease

YouLease

Considerations - Confidentiality

• Inthevehicleleasingexample,themanufacturersandleasingcompaniesmaynotwanttheircompetitorstoseedetailsoftransactions.

• Forexample,aleasecompanycoulduseevidenceofdiscountratesforothercompaniesagainstthemanufacturerinfuturenegotiations.

• Encryptionofdatacanhelp,butbusinessesarekeentoavoidtransactionsbeingexecutedoncompetitorsnodes.

7

DVLA AudiFord

Fiat

ToyotaFiatSkodaTop

LeaseLease Plus

5% discount 10% discount

membership

keysConsensusLedgerEventsChaincode

state

peerSDK

ECA, TCA, TLS-CA

Current Architecture (v0.6)

8

We need to:• Support broader confidentiality • Scale the number of participants and transaction throughput • Eliminate non deterministic transactions • Enable pluggable data store • Be able to dynamically upgrade fabric and chaincode• Remove SPF and enable multiple providers of Membership

Services

What We Have Learned

9

Overview of Hyperledger Fabric v1Exampletransactionflow

membership

keys

EndorserCommitterLedgerEventsChaincode

state

Proposal

No SPoFNo SPoT

peerSDK

ConsensusService

Order TXs in a batch according to consensus

Relay

Batch

v1.0 Architecture

11

https://github.com/hyperledger/fabric/blob/master/proposals/r1/Next-Consensus-Architecture-Proposal.md

A sample transaction (1/7)

E2

CCCCE1

E3

ClientApp

Client App proposes a transaction for Smart Contract A to the Endorsing peer E0. Note: Endorsement policy: “E0, E1 and E2 must sign”. E3, E4 and E5 are not part of the policy

1 (Propose)

Blockchain Network

A

Smart Contract

DA B

A B

E0

12

A B

E4

E5

ZY

ZY

A sample transaction (2/7)

E2

CCCCE1

E3

ClientApp

Endorsing peer E0 endorses a tx and (optionally) “anchors it” with respect to the ledger state version numbers. An “anchor” contains all data read and written by the contract that is to be confirmed by other endorsers

A

Smart Contract

DA B

A B

E0

13

A B

2 (Transaction-Valid, anchor)

Blockchain Network

E4

E5

ZY

ZY

A sample transaction (3/7)

E2

CCCCE1

E3

ClientApp

The client requests further endorsement from E1 and E2.The client may decide to suggest an anchor obtained from E0. to E1 and E2

A

Smart Contract

DA B

A B

E0

14

A B

3 (Propose, anchor)

3 (Propose, anchor)

Blockchain Network

E4

E5

ZY

ZY

A sample transaction (4/7)

E2

CCCCE1

E3

ClientApp

The Endorsing peers E1 and E2 send the endorsement to client

A

Smart Contract

DA B

A B

E0

15

A B

4 (Transaction-Valid)

4 (Transaction-Valid)

Blockchain Network

E4

E5

ZY

ZY

A sample transaction (5/7)

E2

CCCCE1

E3

ClientApp

Client formats the transaction and broadcasts it to the consensus-service nodes for inclusion in the ledger

A

Smart Contract

DA B

A B

E0

16

A B

5 (Broadcast)

Blockchain Network

E4

E5

ZY

ZY

A sample transaction (6/7)

E2

CCCCE1

E3

ClientApp

The consensus service delivers the next block in the ledger with the consented transaction. E4 and E5 are not on the same channel and therefore do not receive an update

A

Smart Contract

DA B

A B

E0

17

A B

6 (Deliver)

6 (Deliver)

6 (Deliver)6 (Deliver)

Blockchain Network

E4

E5

ZY

ZY

A sample transaction (7/7)

E2

CCCCE1

E3

ClientApp

The peers validate the block received from the consensus-service and update their ledger and world-state.

A

Smart Contract

DA B

A B

E0

18

A B

7 (Validate)

7 (Validate)

Blockchain Network

E4

E5

ZY

ZY

7 (Validate) 7 (Validate)

batching

• Raw Ledger: may contain invalid transactions – output by consensus service

• Validated Ledger: a filtered version of Raw Ledger produced by Peers

VerifyversionDeps,endorsement

IfOKthenapplystateUpdatesElseinvalidtransaction(blob)

ValidatedLedger(VL)

seqNo=blckNo

RawLedgerbatch

ValidatedLedgerblock

RawLedger(RL)

Raw and Validated Ledger (batches vs. blocks)

SeqNoblob1blob2blob3

BlockNo

txn1txn2

Submitting

Client

Peer

blob

CCCC

batch

Example PBFT network (i.e. as today)

• All peers connect to the same system channel (red).• All peers have the same chaincode and maintain the same ledger• Endorsement by peers E0, E1, E2 and E3

Blockchain Network

Smart Contract

E0

20

AB

E3

E2

E1

CCCC

ClientApp

AB

AB

AB

ClientApp

Example confidential chaincode network

• Peers E0 and E3 connect to the red channel for chaincode A and B• Peers E1 and E2 connect to the blue channel for chaincode Y and Z

Blockchain Network

Smart Contract

E0

21

ZY

E3

E2

E1

CCCC

ClientApp

AB

AB

YZ

ClientApp

Pluggable world stateHowisdatamanagedontheledger?

World state today (v0.6)

• SmartcontractscanstoredataintheBlockchainusingakey/valuestore.• ThisdataismanagedandpersistedusingRocksDB.

– RocksDB isanopensource,embeddablekey-valuestore.

• UnderlyingpersistencestoreishiddenfromdeveloperbythechaincodeAPIs:– GetState()andPutState()

• Worldstateiscurrentlyquiterestrictive– forexample,thereislimitedcapabilitytoruncomplexqueriesagainststoreddata.

23

RocksDB

Smart contract Chaincode

APIs

World-state in the future

• Underlyingstoragetobemade“pluggable”,sonetworkoperatorscanchoosewhichimplementationtouse.

• FirstimplementationwilluseApacheCouchDB:– NoSQLdatabasethatstoresJSONdocuments.– Extensivequerycapabilities.

24

RocksDB

Smart contract Chaincode

APIs

CouchDB

Permissioned Ledger AccessTransactionandidentityprivacy

Requestscertificates

1xEcert,NxTcert

ConsensusNetwork

BlockchainUserA

usesEcert

Tcert invokesSCtxn(signedwithTkeyA,encryptedwithVkey)

TkeyA

Smartcontract

deployedoneveryvalidatingpeer

Enrollmentcertificates(Ecerts)andTransaction

certificates(Tcerts)canonlybelinkedbyCAanduser …

(signedwithEkey oforigin,encryptedwithvalidators’key)

BlockchainUserB

Vkey

Accessesledger

Private Ledger Access

U

U

Application

Application

uses

ü

sc

Membership

CertificateAuthority

(storedinwallet)

26

Transaction and Identity Privacy

• TransactionCertificates,Tcerts– Disposablecertificates,typicallyusedonce,requestedfromTransactionCA– Tcert derivedfromlongtermidentity- EnrollmentCertificate,Ecert– OnlyTransactionCAcanlinkEcert andTcert

• PermissionedInteractions– ConsumersharespublicTcert toprovider– Providerinvokeschaincodetransactionasusual,but

• Signswithprovider’sprivateTcert forauthentication• EncryptswithproviderandconsumerTcerts forsubsequentaccess

– Consumerscansubsequentlyaccessledgerdatausingtheirprivatekey

• Securechaincode– CCcanalsobesignedandencrypted,tokeepverifyandsecurecontractdetails– Signingisbycontractowner/author– Encryptionensuresonlyvalidatorscanseeandexecutetransactionchaincode

27

Summary and Next StepsForusers

Summary

• V1Hyperledger Fabric

• Supportbroaderconfidentiality

• Scalethenumberofparticipantsandtransactionthroughput

• Eliminatenondeterministictransactions

• Enablepluggabledatastore

• Beabletodynamicallyupgradefabricandchaincode

• RemoveSPFandenablemultipleprovidersofMembershipServices

29

Thank You!

30

Next Generation ConsensusDetailsoftheproposedHyperLedger next

generationconsensusprotocol

membership

keys

EndorserCommitterLedgerEventsChaincode

state

Proposal

No SPoFNo SPoT

peerSDK

ConsensusService

Order TXs in a batch according to consensus

Relay

Batch

v1.0 Architecture

32

https://github.com/hyperledger/fabric/blob/master/proposals/r1/Next-Consensus-Architecture-Proposal.md

Next Generation Consensus Protocol

•Validationrolewillbesplitinto2independentroles:– Endorsement

• Endorsingatransactionverifyingthatitscontentobeysagivensmartcontract.Endorsers“sign”thecontract

– Consensus• Consentingtheinclusionofaverifiedtransactionintheledger.Consensuscontrolswhatgoesintheledgermakingsurethattheledgerisconsistent

• IntroductionofEndorsementPoliciesandChannels

33

Nodes and roles

• Peer:Commitstransactions,maintainsledgerandstate

• Endorsingpeer:Specialised roleofpeerthatreceivesatransactionproposalforendorsement,respondsgrantingordenyingendorsement

• Consensus-Service:Approvestheinclusionoftransactionblocksintotheledgerandcommunicateswithpeerandendorsingpeernodes

34

Endorsement Policies

Anendorsementpolicydescribestheconditionsbywhichatransactioncanbeendorsed.Atransactioncanonlybeconsideredvalidifithasbeenendorsedaccordingtothepolicy.

–Peersmaintainasetofendorsementpolicies–Anendorsementpolicyisspecifiedondeploymentofchaincode

35

Peer

Endorsement PolicyEndorsement PolicyEndorsement Policy

ChaincodeChaincodeChaincodeChaincodeChaincode

Endorsement Policy Examples

• Suppose the chaincode specifies the endorser set

E = {Alice, Bob, Charlie, Dave, Eve, Frank, George}.

• Example policies–Avalid signature from all members of E.– A valid signature from any single member of E.– Valid signatures from a subset of E (using AND / OR)– Valid signatures from a subset of E based on a weighting value

36

Channels

Peersbroadcastandreceivemessagesfromtheconsensus-serviceviachannels.Channelsenablepartitioningofconfidentiality.

37

– Enableschaincode confidentiality– Messagescanbepartitionedintoseparatechannels– Nodescanconnecttooneormorechannels– Channelsdonotneedtobeconnectedtobyallnodes– Peersarepermissionedtoconnecttoachannelviaanaccesscontrolpolicy

– Transactionsbroadcasttoachannelareorderedbytheconsensusservice.

– Allpeersreceivetransactionsinexactlythesameorderforachannel.

– Transactionsaredeliveredincryptographicallylinkedblocks.– Eachpeervalidatesthedeliveredblocksandcommitsthemtotheledger.