OOP 2019: Hyperledger Fabric – Architecture and Smart Contracts of the Open Source Blockchain
In this session at OOP 2019 in Munich, Ingo Rammer presented the originally IBM initiated - and nowadays Linux Foundation hosted - open source blockchain Hyperledger Fabric.
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: [email protected] Twitter: @ingorammer
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
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?
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
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
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
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
• 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