Uploaded byIBM Sverige
Blockchain architected
This document discusses key concepts and components related to blockchain solutions, including actors such as users, developers, operators, and architects. It describes various components that make up blockchain solutions such as ledgers, smart contracts, consensus mechanisms, and how applications interact with blockchains. It also covers considerations for blockchain developers and operators, and challenges around integrating blockchains with existing systems and achieving determinism.
More Related Content
Similar to Blockchain architected
![[DSC Europe 25] Milovan Jovicic - Beyond AI's Reach: The Enduring Value of Ev...](https://cdn.slidesharecdn.com/ss_thumbnails/pyeij0hurgwq5jugmtnv-2-milovan-jovicic-beyond-ais-reach-the-enduring-value-of-evergreen-design-v2-260120105856-d6ee57e5-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DSC Europe 25] Milos Belcevic - Product Professional's Journey to Full-Stack...](https://cdn.slidesharecdn.com/ss_thumbnails/1zovd6fgsycdg4wvgvls-milos-belcevic-product-professionals-journey-to-full-stack-product-developer-260123083019-d993120d-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DSC Europe 25] Borko Kozomora - Optimizing business workflows with advances ...](https://cdn.slidesharecdn.com/ss_thumbnails/hbgekyb0txw0xpo4yfml-borko-kozomora-leading-ai-transformation-260122103838-cc29ee38-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DSC Europe 25] Tamas Srancsik - How To Teach Your AI Football? An Argument f...](https://cdn.slidesharecdn.com/ss_thumbnails/bcjh1m9xtbosv20ucftb-tamas-srancsik-how-to-teach-your-ai-football-260121115910-08b53e9e-thumbnail.jpg?width=640&height=640&fit=bounds)
Blockchain architected
- 1. Blockchain Architected The TechnicalConcepts behind a Blockchain Solution Blockchain Architected Blockchain Explored Blockchain Solutions Blockchain Composed Next Steps Blockchain Explained IBM Blockchain Platform V2.02, 12 January 2018
- 2. Concepts and Components Considerationsfor the Developer, Operator and Architect
- 3. 3 Blockchain User Membership Services Blockchain Developer Blockchain Network Operator Blockchain B2B transactions access to logic accessto data creates applications operates accesses security certificates Regulator performs oversight Traditional Data Sources Traditional Processing Platforms R U D O Blockchain Architect A designs Actors in a blockchain solution
- 4. 4 The business user,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. 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. U R D O Responsible for the architecture and design of the blockchain solution A Blockchain Operator Blockchain Architect Blockchain User Blockchain Regulator Blockchain Developer Membership Services Traditional Processing Platform Traditional Data Sources Actors in a blockchain solution
- 5. 5 Components in ablockchain solution Membership Smart Contract Systems Management Events Peer Network Wallet Ledger A ledger is a channel’s chain and current state data which is maintained by each peer on the channel. f(abc); Software running on a ledger, to encode assets and the transaction instructions (business logic) for modifying the assets. … E T A broader term overarching the entire transactional flow, which serves to generate an agreement on the order and to confirm the correctness of the set of transactions constituting a block. Membership Services authenticates, authorizes, and manages identities on a permissioned blockchain network. Creates notifications of significant operations on the blockchain (e.g. a new block), as well as notifications related to smart contracts. Provides the ability to create, change and monitor blockchain components Securely manages a user’s security credentials i Systems Integration Responsible for integrating Blockchain bi-directionally with external systems. Not part of blockchain, but used with it. !
- 6. Concepts and Components Considerationsfor the Developer, Operator and Architect
- 7. 7 Ledger … The blockchain developer Blockchain Developer D f(abc); Smart Contract Blockchaindevelopers’ primary interests are… They should NOT have to care about operational concerns, such as: Peers Consensus …and how they interact with the ledger and other systems of record: Systems IntegrationEvents ! Traditional Data Sources Traditional Processing Platforms Application X Security
- 8. 8 A ledger oftenconsists of two data structures • Blockchain o A linked list of blocks o Each block describes a set of transactions (e.g. the inputs to a smart contract invocation) o Immutable – blocks cannot be tampered • World State o An ordinary database (e.g. key/value store) o Stores the combined outputs of all transactions o Not usually immutableWorld state block txn txn txn Blockchain
- 9. 9 Block detail (simplified) -A blockchain is made up of a series of blocks with new blocks always added to the end - Each block contains zero or more transactions and some additional metadata - Blocks achieve immutability by including the result of a hash function of the previous block - The first block is known as the “genesis” block Block 16 Previous Block Hash: 57ec2fda71 Block Hash: 87ea2ffe94Block Hash: 57ec2fda71 Block 15 Previous Block Hash: d68b2f0a3b Block 17 Previous Block Hash: 87ea2ffe94 Block Hash: 44bf2efe32 Transaction Transaction Transaction Transaction TransactionTransaction … …
- 10. 10 Working with theledger example: a change of ownership transaction World state Transaction input - sent from application invoke(myContract, setOwner, myCar, Matt) … myCar.vin = 1234 myCar.owner = Matt myCar.make = Audi … World state: new contents Smart contract implementation setOwner(Car, newOwner) { set Car.owner = newOwner } txn txn txnmyCar.vin = 1234, ... “Invoke, myContract, setOwner, myCar, Matt” Application f(abc); Smart Contract
- 11. 11 Blockchain developer Smart Contract submitsdevelops develops recorded accesses event emits emits D Ledger ‘get’, ‘put’, ‘delete’ Client Application SDK ! ! Worldstate block txn txn txn Blockchain Peer event How applications interact with the ledger
- 12. 12 How events areused in blockchain • In computing, an event is an occurrence that can trigger handlers – e.g. disk full, fail transfer completed, mouse clicked, message received, temperature too hot… • Events are important in asynchronous processing systems like blockchain • The blockchain can emit events that are useful to application programmers – e.g. Transaction has been validated or rejected, block has been added… • Events from external systems might also trigger blockchain activity – e.g. exchange rate has gone below a threshold, the temperature has gone up, a time period has elapsed… txn txn txn ! New txn New txn handler Transfer confirmed Application
- 13. 13 Integrating with existingsystems – possibilities Transform Existing systems 1. System events 2. Blockchain events 3. Call into blockchain network from existing systems Blockchain network Existing systems ! !
- 14. 14 • Blockchain isa network system of record • Two-way exchange – Events from blockchain network create actions in existing systems – Cumulative actions in existing systems result in Blockchain interaction Integrating with existing systems – using middleware • 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 • Smart contracts can call out to existing systems – Query is most likely interaction for smart decisions • e.g. all payments made before asset transfer? • Warning: Take care over predictability… transaction must provide same outputs each time it executes
- 15. 15 Non-determinism in blockchain •Blockchain is a distributed processing system – Smart contracts are run multiple times and in multiple places – As we will see, smart contracts need to run deterministically in order for consensus to work • Particularly when updating the world state • It’s particularly difficult to achieve determinism with off-chain processing – Implement services that are guaranteed to be consistent for a given transaction, or – Detect duplicates for a transaction in the blockchain, middleware or external system getDateTime() getExchangeRate() getTemperature() random() incrementValue inExternalSystem(…)
- 16. Concepts and Components Considerationsfor the Developer, Operator and Architect
- 17. 17 The blockchain operator Blockchain Operator O Blockchainoperators’ primarily interests are in the deployment and operation of part of the blockchain: They should NOT have to care about development concerns, such as: Application code Smart contract code Peers Consensus Security X
- 18. 18 Peers • Peers arethe technical services that a blockchain requires in order to work – Peers hold and maintain the ledger – They receive transactions from applications (and other peers) – Peers can validate transactions – They notify applications about the outcome of submitted transactions • Peers are implemented as an operating system process – …to which applications and other peers can connect – Very similar to web servers! • Peers connect to other peers to form nodes on a peer-to-peer blockchain network – Peers can be run wherever makes sense; allows for heterogeneous technology choices – Some blockchains are worldwide, others are private to a business network – However, peers from one blockchain implementation cannot talk with others (yet!) • For example, an Ethereum blockchain cannot transfer assets to a Hyperledger Fabric blockchain – It might make sense to have one peer per business network participant, but this is not necessarily so
- 19. 19 Consensus: The processof maintaining a consistent ledger before after LEDGE R peer CONSENSUS ABC DEF ABC ABC ABC ABC JKLJKL Keep all peers up-to-date Fix any peers in error Ignoring all malicious nodes
- 20. 21 Some examples ofconsensus algorithms Proof of stake Proof of Elapsed Time PBFT based Proof of work Kafka / Zookeeper Solo / No-ops
- 21. 22 Consensus algorithms havedifferent strengths and weaknesses Proof of stake Proof of Elapsed Time Proof of work Require validators to solve difficult cryptographic puzzles PROs: Works in untrusted networks CONS: Relies on energy use; slow to confirm transactions Example usage: Bitcoin, Ethereum Require validators to hold currency in escrow PROs: Works in untrusted networks CONS: Requires intrinsic (crypto)currency, ”Nothing at stake” problem Example usage: Nxt Wait time in a trusted execution environment randomizes block generation PROs: Efficient CONS: Requires processor extensions Example usage: Hyperledger Sawtooth
- 22. 23 Consensus algorithms havedifferent strengths and weaknesses PBFT-based Solo / No-ops Kafka / Zookeeper Validators apply received transactions without consensus PROs: Very quick; suited to development CONS: No consensus; can lead to divergent chains Example usage: Hyperledger Fabric V1 Practical Byzantine Fault Tolerance implementations PROs: Reasonably efficient and tolerant against malicious peers CONS: Validators are known and totally connected Example usage: Hyperledger Fabric V0.6 Ordering service distributes blocks to peers PROs: Efficient and fault tolerant CONS: Does not guard against malicious activity Example usage: Hyperledger Fabric V1
- 23. 24 Security: Public vs.private blockchains • Some use-cases require anonymity, others require privacy – Some may require a mixture of the two, depending on the characteristics of each participant • Most business use-cases require private, permissioned blockchains – Network members know who they’re dealing with (required for KYC, AML etc.) – Transactions are (usually) confidential between the participants concerned – Membership is controlled • For example, Bitcoin • Transactions are viewable by anyone • Participant identity is more difficult to control Public blockchains Private blockchains • For example, Hyperledger Fabric • Network members are known but transactions are secret
- 24. 25 Security: Real-world vs.digital identity CA CA R U U • Consider real-world identity documents… – The issuers of the identity documents are trusted third parties (e.g. passport office) – There is usually a chain of trust (e.g. to get a bank card you need a drivers license or passport) – Identity documents are often stored in wallets • In the digital world, identities consist of public/private key pairs known as certificates – Identity documents are issued by trusted third parties known as Certificate Authorities (CAs) • Private blockchain networks also require CAs – So network members know who they’re dealing with – May sit with a regulatory body or a trusted subset of participants
- 25. 26 Security: Encryption andSigning • Cryptography basics – Every member of the network has (at least) one public key and one private key – Assume that every member of the network knows all public keys and only their own private keys – Encryption is the process applying a transformation function to data such that it can only be decrypted by the other key in the public/private key pair – Users can sign data with a private key; others can verify that it was signed by that user • For example – Alice can sign a transaction with her private key such that anyone can verify it came from her – Anyone can encrypt a transaction with Bob’s public key; only Bob’s private key can decrypt it • In private, permissioned blockchains – Transactions and smart contracts can be signed to verify where they originated – Transactions and their payloads can be encrypted such that only authorized participants can decrypt
- 26. 27 Blockchain Blockchain User A signs /encrypts transactions Blockchain User B Certificate Authorities and Blockchain U U uses Certificate Authority Client Application SDK verifies/decrypts transactions Certs requests certificates issues certificates Client Application SDK uses R
- 27. Concepts and Components Considerationsfor the Developer, Operator and Architect
- 28. 29 The blockchain architect Howeverthere are additional considerations for architects to bear in mind from the outset. For example: For a successful solution, blockchain architects need a good understanding of many development and operational concerns discussed in this session: Business concerns $ Blockchain Architect A Applications Events and IntegrationSmart contracts Peers Consensus Security Design Tradeoffs
- 29. 30 Business considerations • Asa B2B system, blockchain adds a number of aspects that are not typical in other projects: – Who pays for the development and operation of the network? – Where are the blockchain peers hosted? – When and how do new participants join the network? – What are the rules of confidentiality in the network? – Who is liable for bugs in (for example) shared smart contracts? – For private networks, what are the trusted forms of identity? • Remember that each business network participant may have different requirements (e.g. trust) – Evaluate the incentives of potential participants to work out a viable business model • Mutual benefit → shared cost (e.g. sharing reference information) • Asymmetric benefit → money as leveler (e.g. pay for access to KYC)
- 30. 31 Trade-offs between non-functionalrequirements Consider the trade-offs between performance, security and resiliency! Performance o The amount of data being shared o Number and location of peers o Latency and throughput o Batching characteristics Security o Type of data being shared, and with whom o How is identity achieved o Confidentiality of transaction queries o Who verifies (endorses) transactions Resiliency o Resource failure o Malicious activity o Non-determinism
- 31. 32 Non-Functional Requirements Multi-tenant Cloud LowControls Single Site Development SaaS Constrained Monolithic Higher re-use Proven Low Low Low Dedicated High Controls High Availability & DR On-Premise Ready For Growth Highly Modular Custom Build Leading Edge High High High Isolation Security Resilient Design Dev Options Sized For Growth Componentisation Re-Use Production Readiness Blockchain Network Complexity Blockchain Network Security/Privacy Complexity Blockchain SC Complexity Adjust the sliders with the client early in the project so all parties are aligned on the expectations of robustness, isolation, security controls etc. as all these factors have material impact on the cost and complexity of the solution. $ $$$
- 32. 33 Summary of KeyConcepts Blockchain Developer D Blockchain Operator O Peers Consensus Security Systems IntegrationEvents ! Ledger … Traditional Data Sources Traditional Processing Platforms f(abc); Smart Contract Application Blockchain Architect A Business concerns $ Design Tradeoffs
- 33. Thank you www.ibm.com/blockchain developer.ibm.com/blockchain www.hyperledger.org © CopyrightIBM Corporation 2017. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. Any statement of direction represents IBM's current intent, is subject to change or withdrawal, and represents only goals and objectives. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
Editor's Notes
- #3 This presentation is in three sections: What is Blockchain: Covers the essentials of blockchain for business Why is it relevant: Key use-cases How can IBM help: IBM’s value proposition and the state of the technology
- #4 This shows the major actors within a blockchain network and what they are doing within the blockchain. The details are on the next slide. Presenters might like to hide either this slide or the following one, depending on personal preference.
- #5 A description of the major actors within the blockchain. The details are on the next slide. Presenters might like to hide either this slide or the preceding one, depending on personal preference.
- #7 This presentation is in three sections: What is Blockchain: Covers the essentials of blockchain for business Why is it relevant: Key use-cases How can IBM help: IBM’s value proposition and the state of the technology
- #8 We’re simplifying things slightly – but making an assumption that the blockchain developer is responsible for the development of the end-user application and the smart contracts that are deployed to the blockchain. No application operates in isolation, so they’ll need to integrate it with existing processing platforms and data sources, as well as figure out what they want to use the ledger for. We’re assuming the developer is interested in the data formats and wire protocols that will allow them to integrate with these systems of record and the ledger, but will have no access to the production systems that carry live data.
- #9 In order to understand how the developer interacts with the ledger, it’s important to note that there are two data structures that are needed in order for the system to work. This is somewhat dependent on the blockchain implementation, but most work in a similar way. The blockchain itself – a chain of blocks – are used to hold transaction data. As we will see on the next chart, this is immutable meaning that data on this structure cannot be tampered with. There is also a data store needed to hold any variables that is manipulated as part of a transaction. Think about the blockchain as storing the input parameters to a transaction (e.g. transfer MyCar from Matt to Dave), and the world state as storing the output (e.g. MyCar is currently owned by Dave). Why do you need both? Think of a transaction to transfer currency from one party to another – how do you know how much balance the sending party has in order to see if the transaction can be completed? If you only had the blockchain linked list you would need to traverse the entire chain every time you wanted to check the balance, which is time consuming (and increasingly so as the chain grows). By storing current balances in a data store you can look this information up more quickly. Different blockchain implement this in different ways (e.g. UTXO - unspent transaction output which is used in Bitcoin).
- #10 This slide looks at the block in more detail and how it achieves immutability. The crucial aspect is the hash function. Each block contains a hash of the previous block, which itself is used to calculate the next block’s hash. This means that if any block were to be tampered with (e.g. a transaction added, deleted or modified) then the hash values would change and the blockchain would no longer be integral. The genesis block usually contains an arbitrary key value that is used to initialise the hash function. This is a simplification of the block detail. Generally, each block contains a Merkel root that links off to a tree of transactions. There is also other metadata, depending on the blockchain implementation (e.g. nonces and timestamps).
- #11 This is an example of the transaction and how it might be stored on the blockchain. Again, blockchain implementations will do this in different ways and we’re talking about generalised smart contract processing blockchains here – but the pseudocode should give you an idea of how this can happen. Note that the transaction on the blockchain contains the payload of the transaction inputs (including the smart contract class and method name and the input parameters to it), and the world state is the result of having run the transaction.
- #12 A developer will create an application and smart contract (could be different developers) The application will invoke calls within the smart contract via an SDK 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 An application can access Block information via rest APIs such as get block height Note the use of ‘Delete’ here – delete can delete keys from the world state database, but not transactions from the blockchain, which we’ve established is immutable.
- #13 Events are important in blockchains, because depending on the blockchain implementation it can take a long time to confirm transactions due to their distributed nature. This slide describes the concepts of events in general, and contains how they might be used in blockchains.
- #14 Events are crucial in integrating with existing systems as they allow you to trigger behaviour, either when something happens in the blockchain (e.g. update a UI when a transaction is confirmed), or when something happens in an external system (e.g. a system clock tells us ten minutes has passed). Of course, instead of triggering this behaviour through events, you can also (3) instantiate blockchain transactions directly from existing systems, or (4) external actions directly from the blockchain.
- #15 It’s logical to use middleware as a means of transferring data between blockchains and external systems. The top screenshot shows an integration flow in IBM Integration Bus, showing how data originating in a file, SAP or MQ can be used to issue a transaction running on Hyperledger Composer. The picture at the bottom is of an IBM DataPower appliance which can also be used to integrate with blockchains. There is a need to decide on the data formats to use inside the blockchain, and the interchange formats with existing systems. GBO stands for Generic Business Object, and ASBO stands for Application-Specific Business Object.
- #16 Be aware that systems integration in blockchain is DIFFICULT to get right because of its distributed nature. Individual transactions are run multiple on multiple nodes and as we’ll see in the next section, the network needs to agree on the result in order for consensus to be achieved. Therefore, you can’t do things like random numbers as each invocation will probably return a different result, and consensus will not be achieved. Even things like timestamps, exchange rates, temperature readings and mileage of a moving car will be susceptible to minor variances, so cannot be relied on. The problem gets worse when calling out to external systems, because it is easy to get into a situation where the external system is called multiple times, with potentially different values. Think about a simple example of incrementing a value in an external system. The result will be dependent on how many nodes there are in the blockchain network, as each invocation of the smart contract will cause the value to be incremented. To get round this problem, you need to detect duplicate invocations either in the blockchain, middleware or external system – or otherwise guarantee consistency for a given transaction Read up on the concepts of ‘oracles’ or ’cryptlets’ for more details on these.
- #17 This presentation is in three sections: What is Blockchain: Covers the essentials of blockchain for business Why is it relevant: Key use-cases How can IBM help: IBM’s value proposition and the state of the technology
- #18 In this section we will cover the concepts of Peers, Consensus and Security.
- #19 What do peers do, and introducing the concept of a peer network.
- #20 This is the conceptual objective of consensus On left is the starting state. On the Right is the end state. On the left there are 2 nodes with correct result of ‘ABC’ 1 node that has MISTAKENLY got a result od ‘DEF’ 1 node had MALICIOUSLY got a result of ‘JKL’ The objective of consensus is to reach the state on the right MISTAKEN nodes are convinced to agree with the others consensus of ‘ABC’ MALICIOUS nodes will not be able to be convinced of the correct result so will be Quarantined
- #21 This is one example flow – they are very blockchain implementation specific. We will cover how Hyperledger Fabric consensus works in “Blockchain Explored”.
- #22 Some examples of consensus algorithms. Will discuss in details on the next slides.
- #23 Proof of work: Adds an artificial cost to transactions (electricity), to help remove the incentive fraudulent behaviour. Similar to requiring students to solve a Rubik’s Cube before they can ask a question. Proof of stake: Requires validators to prove they have currency in order to validate transactions. Similar to requiring students to put $100 on the table before they can ask a question. Proof of elapsed time: Requires validators to wait before validated transactions. Wait is enforced by a locked down computing environment. Similar to requiring students to wait five minutes before they can ask a question.
- #24 Solo: When a transaction is recived, it’s applied directly to the ledger without question. Similar to allowing students to ask questions at any time, with no cost. PBFT: The node network is split into groups (quorums) and common patterns of answers are looked for. Stretching the analogy slightly, it’s similar to allowing students to form groups and selecting appropriate questions to ask. Kafka/Zookeeper: Adds fault tolerance but no guard against malicious behaviour. No real student anaology, as all questions can be asked but redundancy mechanisms to ensure that all questions DO get asked in an agreed order.
- #25 Moving onto the topic of security. Making the assumption that public blockchains are anonymous (or at least pseudononymous). This may not always be the case but is a reasonable assumption for now. Think of privacy as being the polar opposite of anonymity: Anonymity = you know something happened but not who did it; Privacy = you know who did something but not what they did. Most businesses have KYC requirements, which necessitates privacy rather than anonymity.
- #26 A recap of security in the digital world and how it relates to security in the real world.
- #27 A recap of public key infrastructure (PKI) and how that can apply to blockchain. A good opportunity to whiteboard the basics.
- #28 A diagram that shows how encryption and signing can be used in a blockchain.
- #29 This presentation is in three sections: What is Blockchain: Covers the essentials of blockchain for business Why is it relevant: Key use-cases How can IBM help: IBM’s value proposition and the state of the technology
- #30 A blockchain architect should have a reasonable understanding of everything we’ve covered today. However in this section we will cover some additional considerations related to business and other non-functional requirements.
- #31 Before any blockchain solution can be built, there are fundamental questions to ask related to how it gets paid for. These are particularly important given the nature of business networks and the importance they give to blockchain.
- #32 Typically, if you want a blockchain solution to perform fast, you’ll need to trade-off against malicious behaviour. For example, proof of work is very slow but guards against many forms of malicious activity.
- #33 Left is simpler/faster, Right is longer/Costly. Top sliders affect the complexity and price the most.
- #34 Summary of what we’ve discussed in this session.