Blockchain Explored: A technical deep-dive
20 likes5,535 views
The document provides a technical overview of blockchain technology, specifically Hyperledger Fabric. It explains core components such as membership services, consensus mechanisms, and application flow, emphasizing the modular nature that allows developers to create secure and scalable applications on a distributed ledger. It also details the transaction process from proposal to validation, highlighting key elements like endorsements and ordering services.
![7
Ledger
Latest written key/values for
use in transaction simulation
Supports keyed queries,
composite key queries, key
range queries
TX
Reads[]
Writes[]
TX
Reads[]
Writes[]
TX
Reads[]
Writes[]
TX
Reads[]
Writes[]
State Database
Transaction Log
Last written key/value
CouchDB (external option)
supports keyed queries,
composite key queries, key
range queries, plus full data
rich queries (beta in 1.0)
blockHash à SegNo + offset
blockNum à SegNo + offset
txId à SegNo + offset
Block index
block
tx array
File System Level DB
Replaceable
tracking history of a key
Key History index](https://image.slidesharecdn.com/session1462a-170327181640/85/Blockchain-Explored-A-technical-deep-dive-7-320.jpg)
Blockchain Explored: A technical deep-dive
- 1. 1© 2016 IBM Corporation Blockchain Explored: A Technical Deep-Dive Binh Nguyen Hyperledger Fabric Chief Architect
- 3. 3 A mutual distributed ledger technology allowing any participant in the business network to independently compute and validate the source of truth Introducing Blockchain
- 4. 4 Reference Architecture Distributed Ledger Technology Services APIs, Events, SDKs SMART CONTRACT Chain-code Services AP Membership Services Enrollment Attributes Consensus Services Distributed Ledger Ordering Service Network Protocol Endorsement Validation Secure Container Secure Registry TRANSACTIONS LEDGER IDENTITY Security and Crypto Services IDENTITY Pluggable, Membership, Privacy and Auditability of transactions. LEDGER | TRANSACTIONS Distributed transactional ledger whose state is updated by consensus of stakeholders SMART-CONTRACT “Programmable Ledger”, provide ability to run business logic against the blockchain (aka smart contract) APIs, Events, SDKs Multi-language native SDKs allow developers to write DLT apps
- 5. 5 Orderer • A group of Orderers runs a communication service, called ordering service, to provide atomic broadcast • Ordering service is the genesis of a network. Clients of ordering service are peers and applications – Accept transactions and deliver blocks – Process all configuration transactions to set up network policies (readers, writers, admins) • Orderer manages a pluggable trust engine (eg CFT or BFT) that performs the ordering of the transactions orderer Atomicbroadcast System Config Config Processor Trust Model
- 6. 6 Peer • A Peer is a node on the network maintaining state of the ledger and managing chaincodes • Any number of Peers may participate in a network • A Peer can be an endorser, committer and/or submitter (submitter has not been implemented). An endorser is always a committer – An endorser executes and endorses transactions – A committer verifies endorsements and validates transaction results • A Peer manages event hub and deliver events to the subscribers • Peers form a peer-to-peer gossip network Endorser Committer Ledger Chaincode Event Submitter peer
- 7. 7 Ledger Latest written key/values for use in transaction simulation Supports keyed queries, composite key queries, key range queries TX Reads[] Writes[] TX Reads[] Writes[] TX Reads[] Writes[] TX Reads[] Writes[] State Database Transaction Log Last written key/value CouchDB (external option) supports keyed queries, composite key queries, key range queries, plus full data rich queries (beta in 1.0) blockHash à SegNo + offset blockNum à SegNo + offset txId à SegNo + offset Block index block tx array File System Level DB Replaceable tracking history of a key Key History index
- 8. 8 Channel • A data partitioning mechanism to control transaction visibility only to stakeholders • Consensus takes place within a channel by members of the channel – Other members on the network are not allowed to access the channel and will not see transactions on the channel • A chaincode may be deployed on multiple channels, each instance is isolated within its channel – A chaincode may query another chaincode in other channel (ACL applied)
- 9. 9 Membership Service Provider • An abstraction of identity provider – <MSP.id, MSP.sign, MSP.verify, MSP.validateid, MSP.admin> – govern application, endorser and orderer identities • Used as building blocks for access control frameworks – at the system level (read/write access on system controls, and channel creation) – at the channel level (read/write access), – at the chaincode level (invocation access) • Represent a consortium or a member Client End-user Bob Endorser Endorser Endorser Membership Service Provider Orderer Channel ü External Certificate Authority Fabric-CA Certificate Authority ü
- 10. 10 Crypto Service Provider • CSP abstracts crypto standards (software and hardware) to enable plugging in different implementation – Alternate implementations of crypto interface can be used within the Fabric code, without modifying the core • Support for Multiple CSPs – Easy addition of more types of CSPs, e.g., of different HSM types – Enable the use of different CSP on different system components transparently Fabric Components ACSP EP11 (enterprise PKCS11 firmware) IBM HSM (card) OpenCryptoKi (remote PKCS11) (PKCS11) (enterprise PKCS11) Software BCCSP HSM BCCSP (PKCS11) CSP Factory
- 11. 11 Ecert Tcert Fabric-CA • Default implementation of the Membership Services Provider Interface. • Issues Ecerts (long-term identity) and Tcerts (disposable certificate) • Supports clustering for HA characteristics • Supports LDAP for user authentication • Supports HSM Fabric-CA cluster DB LDAP Authenticate Enroll ID, secret HSM Root Certificate Authority ü Membership Services Provider Implements
- 12. 12 Overview of Application Flow • Developers create application and smart contracts (chaincodes) – Chaincodes are deployed on the network and control the state of the ledger – Application handles user interface and submits transactions to the network which call chaincodes • Network emits events on block of transactions allowing applications to integrate with other systems cached state, history, tx Blockchain block txn txn txn txn … Blockchain developer Smart Contract Invokes/queriesdevelops develops Application Accesses event emits emits D Ledger ‘get’ ‘put, ‘delete’ SDK Peer
- 13. 13 Contents 13Page© 2016 IBM Corporation What? How? When?
- 14. 14 Bootstrapping a Network • Decide on members (MSPs) controlling the ordering service – Set up MSP configuration for each member (root certs, signing certs, key, admins) – Set up policies governing the network (who has privilege to modify config and create channels) – Start up orderers with the configuration • Each member decides on the number of peers to participate – For each peer, issue peer identity (local MSP configuration) and start it up • At this point, we have a network of peers and orderers – Peers are not yet connected to orderers nor to each other
- 15. 15 Two-Member Network Ordering Service (transaction timestamping) Orderer Peer Peer Peer Peer Peer Peer Orderer Profiles: TwoMembers: Orderer: <<: *OrdererDefaults Organizations: - *Member1 - *Member2 Application: <<: *ApplicationDefaults Organizations: - *Member1 - *Member2 Membership Service Provider Membership Service Provider
- 16. 16 Setting up Channels, Policies, and Chaincodes • Depending on the business network, 1 or more channels may be required • To create a channel, send a configuration transaction to the ordering service specifying members of the channel, ACL policies, anchor peers – The configuration becomes part of the genesis block of the channel – Then notify members to join the channel (a peer may join multiple channels) • Deploy chaincodes on the channel with appropriate endorsement policy • Now the network is ready for transacting
- 17. 17 Consensus Redefined • Consensus = Transaction Endorsement + Ordering + Validation • Endorsement: Each stakeholder decides whether to accept or reject a transaction • Ordering: Sort all transactions within a period into a block to be committed in that order • Validation: Verify transaction endorsement satisfied the policy and transaction transformation is valid according to multiversion concurrency control (MVCC)
- 18. 18 Transaction Endorsement • An endorsement is a signed response of the result of a transaction execution • An endorsement policy encapsulates the requirement for a transaction to be accepted by the stakeholders, either explicit or implicit – A signature from both member1 and member2 – Either a signature from both member1 and member2 or a signature from member3 – A signature from John Doe • The endorsement policy is specified during a chaincode instantiation on a channel; each channel-chaincode may have different endorsement policy
- 19. 19 Two-Member Network with A Channel Ordering Service (transaction timestamping) Orderer Peer Peer Peer Peer Peer Peer Orderer Channel Channel App App What if we want to add more members ?
- 20. 20 N-Member Network with Multichannel Ordering Service (transaction timestamping) Orderer Peer Peer Peer Peer Peer Peer Orderer Channel Channel App App Peer Peer Peer Orderer Channel Peer Peer Peer Peer
- 21. 21 Sample transaction: Step 1/7 – Propose transaction E0 Client Application E1 E2 S D K Endorser Ledger Committer Application Orderier Smart Contract (Chain code) Endorsement Policy Key: Fabric Ordering-Service O O O OAp Application proposes transaction Endorsement policy: • “E0, E1 and E2 must sign” • (P3, P4 are not part of the policy) Client application submits a transaction proposal for chaincode A. It must target the required peers {E0, E1, E2} P4P3 A B A B A B A D
- 22. 22 Sample transaction: Step 2/7 – Execute proposal Endorsers Execute Proposals E0, E1 & E2 will each execute the proposed transaction. None of these executions will update the ledger Each execution will capture the set of Read and Written data, called RW sets, which will now flow in the fabric. E0 Client Application E1 E2 S D K Fabric Ordering-Service O O O OAp Endorser Ledger Committer Application Orderier Smart Contract (Chain code) Endorsement Policy Key: P4P3 A B A B A B A D
- 23. 23 Sample transaction: Step 3/7 – Proposal Response Application receives responses The RW sets are signed by each endorser and returned to the application E0 Client Application E1 E2 S D K Fabric Ordering-Service O O O OAp Endorser Ledger Committer Application Orderier Smart Contract (Chain code) Endorsement Policy Key: P4P3 A B A B A B A D
- 24. 24 Sample transaction: Step 4/7 – Order Transaction Application submits responses for ordering Application submits responses as a transaction to be ordered. Ordering happens across the fabric in parallel with transactions submitted by other applications Fabric E0 E1 E2 O O O OAp Client Application S D K Endorser Ledger Committer Application Orderier Smart Contract (Chain code) Endorsement Policy Key: (other applications) Ordering-Service P4P3 A B A B A B A D
- 25. 25 Sample transaction: Step 5/7 – Deliver Transaction Orderer delivers to all committing peers Ordering service collects transactions into blocks for distribution to committing peers. Peers can deliver to other peers using gossip (not shown) Different ordering algorithms available: • SOLO (single node, development) • Kafka (blocks map to topics) • SBFT (tolerates faulty peers, future) Fabric E0 E1 E2 O O O OAp Client Application S D K Endorser Ledger Committer Application Orderier Smart Contract (Chain code) Endorsement Policy Key: Ordering-Service P4P3 A B A B A B A D
- 26. 26 Sample transaction: Step 6/7 – Validate Transaction Committing peers validate transactions Every committing peer validates against the endorsement policy. Also check RW sets are still valid for the current state Transactions are written to the ledger and update caching DBs with validated transactions Fabric E0 E1 E2 O O O OAp Client Application S D K Endorser Ledger Committer Application Orderier Smart Contract (Chain code) Endorsement Policy Key: Ordering-Service P4P3 A B A B A B A D
- 27. 27 Sample transaction: Step 7/7 – Notify Transaction Committing peers notify applications Applications can register to be notified when transactions succeed or fail, and when blocks are added to the ledger Applications will be notified by each peer to which they are connected Fabric E0 A B E1 A B E2 A B O O O OAp Client Application S D K Endorser Ledger Committer Application Orderier Smart Contract (Chain code) Endorsement Policy Key: Ordering-Service P3 A D P4 ! ! ! ! ! !
- 28. 28 Contents 28Page© 2016 IBM Corporation What? How? When?
- 29. 29 2017!December January 31 March 20 May Early Docker Images for the December Connect- A-Thon with Press Release 11 companies in Australia, Hungary, UK, US East Coast, US West Coast, Canada Docker images for Hyperledger Community 60+ participants real time testing out latest Hyperledger Fabric 1.0 and documentation at Hyperledger Developer Event in San Fransisco Interconnect: Docker images aligned with Beta for HSBN Docker images aligned with the HSBN Consortium offering GA Proposal to community on current content (which also applies to Interconnect 2017) https://wiki.hyperledger.org/projects/proposedv1alphacontent Docker Images Continually produced through Continuous Integration March 3 Docker images for community, being used by select customers Moving Forward
- 30. 30 Where to Ask Questions Hyperledger Community has moved off Slack to RocketChat. Go to chat.hyperledger.org and register. You will be required to have a linux foundation ID however. If you aren't registered with the Linux Foundation, get an ID from https://identity.linuxfoundation.org/ For questions on Version 1.0, go to the fabric-questions channel. Also every day, the docker build status is posted when passing the continuous integration tests will be posted on fabric-ci (only posted when tests pass)
- 31. 31 Useful Information To Get You Started • Documentation actively getting updated as we progress: http://hyperledger-fabric.readthedocs.io/en/latest/ • Support for Docker images for easy deployment for Hyperledger-fabric 1.0. Docker images will be available for all major components to run a network (peers, solo orderer, CLI, CA, Kafka, CouchDB). A “Getting started” section will be available in the Hyperledger-fabric publications. Getting started will help a developer or user to start the network, run a simple application , and learn the basics of running fabric 1.0. See: http://hyperledger-fabric.readthedocs.io/en/latest/ • Support for a tool that helps bootstrap a network. The bootstrap network tool is available and called the Configuration Transaction Generator (configtxgen). The tool is designed to configure the network with organizations included in the ordering service genesis block and generates the configuration transaction artifacts used for channel creation.
- 32. 32© 2016 IBM Corporation http://hyperledger.org http://ibm.com/blockchain