Deploy a blockchain web-app with Hyperledger Fabric 1.4 - Concepts & Code

Editor's Notes

• #10: 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.
• #11: 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.
• #12: 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.
• #13: 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.
• #14: 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).
• #15: 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).
• #16: 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).
• #17: 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).
• #18: The modular architecture, allows innovation and flexibility allowing components, such as consensus and membership services, to be plug-and-play.
• #19: The modular architecture, allows innovation and flexibility allowing components, such as consensus and membership services, to be plug-and-play.
• #20: The modular architecture, allows innovation and flexibility allowing components, such as consensus and membership services, to be plug-and-play.
• #21: 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.
• #22: 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.
• #23: 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.
• #38: 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.
• #49: 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
• #50: 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.
• #51: 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.
• #52: 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.
• #53: 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.
• #54: 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.
• #55: The photo is taken from Think 2019, where Marley Gray (head of blockchain for Microsoft) and Gari Singh (IBM CTO for blockchain) connected a Hyperledger Fabric network running on Azure to IBM Blockchain Platform
• #57: The photo is taken from Think 2019, where Marley Gray (head of blockchain for Microsoft) and Gari Singh (IBM CTO for blockchain) connected a Hyperledger Fabric network running on Azure to IBM Blockchain Platform