Downloaded 648 times
Uploaded byEric Cattoir
Anatomy of a hyperledger application
This document provides an overview of the anatomy of a Hyperledger application. It describes the key components including the Hyperledger architecture, application components, smart contracts, permissioned ledger access, and how applications interact with the blockchain network. The Hyperledger architecture supports various participants like developers, users, and network operators. Applications use smart contracts to interact with the ledger, while smart contracts encapsulate business logic and transactions. Permissioned access controls who can access the ledger through the use of certificates. The document also provides examples of how applications, smart contracts, and external systems integrate with the permissioned ledger.
More Related Content
Similar to Anatomy of a hyperledger application
Anatomy of a hyperledger application
- 1. Anatomy of aHyperledger Application Eric Cattoir eric_cattoir@be.ibm.com @CattoirEric Dina Fatkulbayanova dfatkulbayanova93@gmail.com @dfatkulbayanov1
- 2. Agenda •Hyperledger Architecture •Application Components •SmartContracts •Permissioned Ledger Access •Summary 2
- 3. Agenda •Hyperledger Architecture •Application Components •SmartContracts •Permissioned Ledger Access •Summary 3
- 4.
- 5. Blockchain User Certificate Authority Blockchain Developer Blockchain Network Operator Traditional Processing Platforms Traditional Data Sources Blockchain B2Btransactions access to logic access to data creates applications operates accesses security certificates Regulator performs oversight The Participants in a Blockchain Network R U D O 5
- 6. Blockchain Participants the businessuser, operating in a business network. This role interacts with the Blockchain using an application. They are not aware of the Blockchain. the overall authority in a business network. Specifically, regulators may require broad access to the ledger’s contents. the developer of applications and smart contracts that interact with the Blockchain and are used by Blockchain users. defines, creates, manages and monitors the Blockchain network. Each business in the network has a Blockchain Network operator. manages the different types of certificates required to run a permissioned Blockchain. an existing computer system which may be used by the Blockchain to augment processing. This system may also need to initiate requests into the Blockchain. an existing data system which may provide data to influence the behavior of smart contracts. Blockchain User Blockchain Developer Certificate Authority Blockchain Regulator Traditional Processing Platform Traditional Data Sources Blockchain Network Operator U R D O 6
- 7. Blockchain Components Membership Smart Contract Systems Management Events Consensus Network Wallet Ledger containsthe current world state of the ledger and a Blockchain of transaction invocations f(abc); encapsulates business network transactions in code. transaction invocations result in gets and sets of ledger state … E T a collection of network data and processing peers forming a Blockchain network. Responsible for maintaining a consistently replicated ledger manages identity and transaction certificates, as well as other aspects of permissioned access creates notifications of significant operations on the Blockchain (e.g. a new block), as well as notifications related to smart contracts. Does not include event distribution. provides the ability to create, change and monitor Blockchain components securely manages a user’s security credentials i Blockchain Systems Integration responsible for integrating Blockchain bi-directionally with external systems. Not part of Blockchain, but used with it. 7
- 8. Agenda •Hyperledger Architecture •Application Components •SmartContracts •Permissioned Ledger Access •Summary 8
- 9. Typical Application 9 User Interface APILayer NodeJS Backend Frontend API Golang Chain code
- 10. World/Ledger state Blockchain block txn txn txntxn … Blockchain developer Smart Contract invokesdevelops develops each ‘put’ or ’delete’ invoke recorded * Application Blockchain Applications and the Ledger Accesses (Rest API) event emits emits D 10 Ledger ‘get’ ‘put, ‘delete’
- 11. Blockchain Applications • Application –Focuses on Blockchain user business needs and experience – Calls smart contract for interactions with ledger state – Can access transaction ledger directly, if required – Can process events if required • Smart Contract – Chain code encapsulates business logic. Choice of implementation language – Contract developer defines relevant interfaces (e.g. queryOwner, updateOwner …) – Different interfaces access ledger state accordingly – consistent read and write provided – Each invocation of a smart contract is a “Blockchain transaction” • Ledger – World/Ledger state holds current value of smart contract data • e.g. vehicleOwner=Daisy – Blockchain holds historic sequence of all chain code transactions • e.g. updateOwner(from=John, to=Anthony); updateOwner (from=Anthony, to=Daisy);etc 11
- 12. Blockchain Operator configures, operates Smart Contract Application deployed to and executeson peer nodes invoke SC peer Exact network structure depends on consensus mechanism. e.g. PBFT has leader, validating and non-validating peers Consensus Network Consensus and the Blockchain Network O consensus msg consensus messages flow between appropriate peers to ensure the Blockchain SC transactions are kept in order; world state is kept consistent through local transaction replay … … scscsc … … scscsc … … … scscsc … scscsc 12
- 13. How a PBFTNetwork Works (1/4) – Submission Non-validating peer Validating peer Validating Leader 456 Transaction submitted to network 123 Transaction submitted to network 789 Transaction submitted to network …789 123 456 …456 789 123 …456 123 789 …123 456 789
- 14. How a PBFTNetwork Works (2/4) – Ordering Non-validating peer Validating peer Validating Leader 456 123 789 …123 456 789 …123 456 789 …123 456 789 …123 456 789 14 …123 456 789 Consensus network establishes order as
- 15. How a PBFTNetwork Works (3/4) – Execution Non-validating peer Validating peer Validating Leader …123 456 789 …123 456 789 …123 456 789 …123 456 789 15 …123 456 789 Consensus network establishes order as Δ Δ Δ Δ
- 16. How a PBFTNetwork Works (4/4) – Distribution Non-validating peer Validating peer Validating Leader …123 456 789 …123 456 789 …123 456 789 …123 456 789 16 …123 456 789 Consensus network establishes order as
- 17. Blockchain Networks • BlockchainNetwork – Comprises a connected set of peer nodes, each owning a copy of the ledger – Peers collaborate to maintain consistent replicated copies of the ledger • Different mechanisms for collaboration – so-called “consensus protocols” – Peers managed by key network participants • Consensus Protocol Options – PBFT excellent first choice. NOOPs (No Operation) available for starter networks – Other protocols can be added (non-trivial!) • PBFT Overview – Defines non-validating peers, validating peers, with 1-validating leader – Leader receives transactions from connected applications – Leader organizes and distributes transactions with validator network • Copes with erring and malicious validators at very low compute cost – Each v-peer executes transactions to bring local ledger copy up-to-date – Non-validating-peers’ ledgers maintained from connected validating-peer’s – Castro & Liskov's paper ‘Practical Byzantine Fault Tolerance and Proactive Recovery’ 17
- 18. Agenda •Hyperledger Architecture •Application Components •SmartContracts •Permissioned Ledger Access •Summary 18
- 19. Implementing Chaincode • ImplementChaincode Shim Interface • Init() • Invoked when you deploy the chain code • Invoke() • Called when executing the contract • Takes function name as parameter • Query() • Implement Main() • Deploy through github 19
- 20. Blockchain network … Integrating with ExistingSystems Transform Existing systems 4. System events 3. Blockchain events Smart contract 1. Call out to existing systems to enrich smart contract logic 20 2. Call into Blockchain network from existing systems
- 21. Non-Deterministic Number Errors 21 …123456 789 …123 456 789 …123 456 789 …123 456 789 External System 1005 – If each smart contract calls out to external system to receive information or uses a non-deterministic variable, it will prevent consensus being achieved. – All external data sources should return the same result for the same calls and variables must be deterministic, any non-deterministic values must be defines as part of the transaction Requested current mileage of moving car 1006 1007 1008
- 22. Agenda •Hyperledger Architecture •Application Components •SmartContracts •Permissioned Ledger Access •Summary 22
- 23. Requests certificates 1xEcert, NxTcert Consensus Network Blockchain User A usesEcert Tcertinvokes SC txn (signed with TkeyA, encrypted with TkeyA, TkeyB…) TkeyA Smart contract deployed on every validating peer Enrollment certificates (Ecerts) and Transaction certificates (Tcerts) can only be linked by CA and user … (signed with Ekey of origin, encrypted with validators’ key) Blockchain User B TkeyB TkeyB shares Tcert public key Accesses ledger Permissioned Ledger Access U U Application Application uses TkeyB sc Membership Certificate Authority (stored in wallet) 23
- 24. Transaction and IdentityPrivacy • Transaction Certificates, Tcerts – Disposable certificates, typically used once, requested from Transaction CA – Tcert derived from long term identity - Enrollment Certificate, Ecert – Only Transaction CA can link Ecert and Tcert • Permissioned Interactions – Consumer shares public Tcert to provider – Provider invokes chain code transaction as usual, but • Signs with provider’s private Tcert for authentication • Encrypts with provider and consumer Tcerts for subsequent access – Consumers can subsequently access ledger data using their private key • Secure chain code – CC can also be signed and encrypted, to keep verify and secure contract details – Signing is by contract owner/author – Encryption ensures only validators can see and execute transaction chain code 24
- 25. Integrating with Existingsystems • Blockchain is network System of Record • Smart contracts can call out to existing systems – Query is most likely interaction for smart decisions • e.g. all payments made before asset transfer? – Transactions execute on every peer in the Blockchain network • Care over predictability… transaction must provide same outputs each time it executes • Two-way exchange – Events from Blockchain network create actions in existing systems – Cumulative actions in existing systems result in Blockchain interaction • Transformation between Blockchain and existing systems’ formats – GBO, ASBO is most likely approach – Standard approach will be for Gateway products to bridge these formats – Gateway connects to peer in Blockchain network and existing systems 25
- 26. Agenda •Hyperledger Architecture •Application Components •SmartContracts •Permissioned Ledger Access •Summary 26
- 27. Summary and NextSteps • Hyper ledger protocol Specification • http://hyperledger-fabric.readthedocs.io/en/latest/ • Blockchain Courses IBM Developerworks • https://developer.ibm.com/courses/all-courses/blockchain-for-developers/ • Chaincode Developers Guide • http://hyperledger-fabric.readthedocs.io/en/latest/#chaincode-developer- guide • Bluemix Blockchain service • https://console.ng.bluemix.net/docs/services/blockchain/index.html 27
- 28.
Editor's Notes
- #6 This shows the major participants within a Blockchain network and what they are doing within the network Details on next slide
- #8 These are the major components within Hyperledger Blockchain, Additional Details: Membership – This is eCerts & tCerts. tCerts are equivialant to one time use certificates to be stored on the blockchain for the users linkable but hidden identity. Wallet – this term is used throughtout blockchain fabrics and does not store the money, only identification (eCert & tCerts)
- #11 Delete can only delete from the World State, not the Blockchain! A developer will create an application and smart contract (could be different developers) The application will invoke calls within the smart contract Those calls are processed by the business logic within the smart contract - a ‘put’ or ‘delete’ command will go through consensus protocol selected and added to the blockchain - a ’get’ command can only read from the world state but is not recorded on the blockchain To read from the blockchain a smartcontract must use the Rest APIs oh Hyperledger in the same way a application would An application can access Block information via rest APIs such as get block height
- #13 The Consensus network is in the Hexagon containing the Validating nodes & Non-validating nodes. Each operation only needs to be sent into the network once where it is then distributed around the network. The items being inputted into the network are abound the edge, Smart Contracts, Applications and configurations by a Blockchain Operator.
- #14 In the Hexagon is the consensus network. It has a central core of validators who press the transaction and reach consensus and a set of non-validating nodes who will receive a copy of the results and output. Validating leaders are found through an election process in PBFT, more on what they do in next slide. The first step is submitting the transactions. Around the edge are 3 participants inputting 3 transactions each (transaction numbers 1, 2, 3, 4, 5, 6, 7, 8 & 9) These are then distributed around the validators so each have a copy of all the transactions However, these transactions may arrive at validators at different times (e.g. 456 arrive first on the left side validators but last on the right side validator) so the validators will have differing orders of transactions
- #15 The Validating leader for this block is the one that decides the final order for the transactions. This validating leader has received the transactions in order 123456789 so sends this order to the other validators. Each validator then re-arranges the transactions they already had into the order set by the validating leader Each submitters transactions will stay in the order that they submitted them but may not be consectuive (e.g 145267839)
- #16 This is the point the validators then execute the transactions Each validator independently runs the transactions in the order set previously and adds the results to a delta (Δ) in the world state. The delta can be rolled back if consensus is not achieved
- #17 The validators then update the non-validators to that they have a copy of the latest blockchain and world state
- #22 A consideration to be made when writing applications that will call upon external systems is the external system may not give the same result If different results are received by different vlidators, they will not reach consensus They should request the result before submitting the transaction and then submit the result as part of transaction