View
3
Download
0
Category
Preview:
Citation preview
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.
Recommended