Blockchain Systems Fundamentals (part 2).pptx

Blockchain Systems Fundamentals Reference: Blockchain Basics – A non-technical introduction in 25 steps by Daniel Drescher Step 13: Authorising Transactions Goal: Only owner of an account can transfer the property – any other attempt should be identified as unauthorised and rejected C...

Blockchain Systems Fundamentals Reference: Blockchain Basics – A non-technical introduction in 25 steps by Daniel Drescher Step 13: Authorising Transactions Goal: Only owner of an account can transfer the property – any other attempt should be identified as unauthorised and rejected Challenge: The peer-to-peer system is open to everyone – how to maintain transparency whilst respecting integrity Idea: Use a digital security measure similar to a handwritten signature – digital signature which use cryptographic hashing and private-to-public asymmetric cryptography Elements of digital signature: Creation of signature Verifying data by using the signature Identifying fraud by using the signature Step 13: Authorising Transactions Creating a signature Message is first hashed and the result is encrypted with the private key to create the digital signature It is unique to the sender and can be traced back to him Then the message and the digital signature are put together as the digitally signed message Verifying data by using the signature Receiver calculates the hash value of received message He then decrypts the digital signature with the public key He compares the result with the hash he calculated If they are the same, it means the message is authentic and was actually sent by the sender i.e transaction was authorised by the sender If they are not the same, it means the message is not authentic, it was either not the original message or not sent by the sender i.e transaction was not authorised by the sender Step 14: Storing Transaction Data Goal: Maintain the whole history of transaction data in an ordered fashion Challenge: Store transaction data in a way that quickly and easily detects any changes made to the data How: Store the data in a change-sensitive manner using hash references Analogy: Library with an ordering catalog to a simplified version of the blockchain-data-structure Books have the following properties: Store content on their pages Sentences and pages are all kept in order Pages are physically connected to the book spine and logically connected via their content and page numbers This allows us to move sequentially through the book or to go directly to a page Let us check what happens with a few transformations Step 14: Storing Transaction Data Transformation 1: Make page dependency explicit Each page will not only show its number but also the preceding page number Transformation 2: Outsourcing the content Pages no longer contain content and focus only on maintaining order of pages Transformation 3: Replacing page numbers Page numbers are no longer natural numbers but references instead Transformation 4: Creating reference numbers Use Cryptographic hash values to create unique page numbers Transformation 5: Get rid of the spine It is not needed as each page contains its own reference number, the preceding page reference number and the reference number of the content A normal book would a mass of disorderly pages without the spine but with our transformations, we can move from page to page seamlessly Step 14: Storing Transaction Data Property Book Transformed Book Storing Content On the page themselves On separate content pages Each page has a unique reference number Ordering Physically: location of the pages Logically: With reference values to Content in the book content pages Logically: based on page numbers Connecting Physically: flipping the pages Logically: Through the reference pages Logically: based on page numbers numbers Browsing Forward / Backward / Directly to Backward only through the through pages the page reference to the preceding page.. Step 14: Storing Transaction Data Transformed Book Blockchain data structure A page in the ordering catalog A block header The whole ordering catalog The chain of block headers Reference number of a page in the The cryptographic hash value of a block ordering catalog header Reference number to the preceding The cryptographic hash value of the page preceding block header Content Transaction data A content page A Merkle tree containing transaction data Reference to the content page The root of the Merkle tree that contains transaction data The mental unit of a page of the One block of the blockchain data structure ordering catalog and its corresponding content page.. The whole ordering catalog and all The blockchain data structure content pages together Step 14: Storing Transaction Data Block 1 Block 2 Block Header 1 Block Header 2 R1 R3 B 2 B1 2 4 R R R R 3 4 1 2 Transactio Transactio Transactio Transactio n1 n2 n3 n4 Simplified blockchain data structure containing 4 transactions Step 15: Using the Data Store Metaphor: Knitting – to correct any specific stitch, one has to rip out all of its succeeding stiches in reverse order starting from the end of the row until one arrives at the stitch to be corrected Adding a new transaction Create a new Merkle tree that contains all new transaction data to be added Create a new block header that contains both a hash reference to its preceding header and the root of the Merkle tree that contains the new transaction data Create a hash reference to the new block header which is now the current head of the blockchain data structure Step 15: Using the Data Store Detecting changes Changes the content of transaction data Changing a reference in the Merkle tree Replacing a transaction Changing the Merkle root Changing a block header reference In all the above cases, the data structure detects the change and is invalidated – this is due to the properties of hash references To effectively carry out the change, one should change everything from the point that caused the change up to the header of the blockchain Note that the blockchain does not differentiate between legitimate and illicit changes – all have to follow the same procedure Step 16: Protecting the Data Store Metaphor: Say I want to pretend to be from an aristocratic family, I would have to forge a full lineage of personalities and documents. If this were easy, I might do it but if it is too cumbersome, I might stick to my humbler roots Goal: History of transaction data represents a truthful source of ownership Challenge: Keep the system open to everyone and yet protect the history of transactions from being manipulated Idea: As we cannot easily distinguish between intentions, it is better to make the history of transaction data unchangeable, thereby meeting the goal How it works broadly Store the data in such a way that the slightest change is noticeable Enforce that any modification requires rewriting a huge part of the data Making modifications computationally expensive (solving hash puzzles for each block) Step 16: Protecting the Data Store How it works (details): The addition of a new block as described before is not computationally expensive - to make the blockchain immutable, we have to make this task computationally expensive Every block header of the blockchain data structure has to contain at least: The root of a Merkle tree containing transaction data A hash reference to the header of the preceding block The difficulty level of the hash puzzle The time when solving the hash puzzle started The nonce that solves the hash puzzle Step 16: Protecting the Data Store How it works (details continued): Creating a new block involves the following steps: 1. Get the root of the Merkle tree that contains the transaction data to be added 2. Create a hash reference to the header of that block that will be the predecessor from the new block header’s point of view 3. Obtain the required difficulty level 4. Get the current time 5. Create a preliminary block header that contains the data in points 1 to 4 above 6. Solve the hash puzzle for the preliminary block header 7. Finish the new block by adding the nonce that solves the hash puzzle to the preliminary header Step 16: Protecting the Data Store How it works (details continued): Every block header has to fulfil the following rules: 1. It must contain a valid hash reference to a previous block 2. It must contain a valid root of a Merkle tree containing transaction data 3. It must contain a correct difficulty level 4. Its time stamp is after the time stamp of its preceding block header 5. It must contain a nonce 6. The hash value of all the five pieces of data combined together fulfils the difficulty level The validation rules ensure that only those blocks are added to the blockchain data structure for which the hash puzzle was solved and the computational costs were paid Rule 4 above ensures that the blocks and transaction data are indeed ordered according to the time being added Step 16: Protecting the Data Store Assuming that solving a hash puzzle takes on average 10 minutes, adding a block which has 20 blocks preceding it would require a total of 210 minutes of computation times Difficulty level should be determined carefully If it is too low, people could manipulate the history of transactional data If it is too high, people would not want to add new blocks and this would affect adoption of the blockchain Moreover, computational power of computers keep increasing with technical advances Therefore, difficulty level is set dynamically – it is based on the speed at which new blocks are added Step 17: Distributing the Data Store among peers Metaphor: If you want to spread some news in a company, just share it with a couple of chatty employees and tell them to keep it a secret The goal: Keep all peers informed about transaction data The challenge: Have all peers up to date without any central co-ordination The idea: Peers will engage in the following types of communication: Small talk: Keeps relationships alive News: Exchanging new information Introducing new peers: Introducing new members in the group Step 17: Distributing the Data Store among peers A peer-to-peer system connected through the internet have the following characteristics: Each node has a unique address Each node can connect/disconnect at any time Each node maintains a list of peers it communicates with Communication is based on messages Messages can be sent to another node with its unique address Messages are not guaranteed to arrive at the address, may arrive more than once and in a different order These issues are dealt with as follows: Every node that receives new information will forward it to its peers it communicates with Each message has its hash value – duplicates can thus be ignored Time stamp in message allows the messages to be ordered objectively Step 17: Distributing the Data Store among peers How it works is based on the following: Keeping existing connections alive Regularly each node sends a ping message to its peers, requesting a pong message in return In case no message is repeatedly received, the node is removed from the list of peers Establishing new connections A node can send a request to any of the peers to join the group The peer stores the address of the new node in its list of peers and send a confirmation message A node will send a request to several peers to stay connected Distributing new information occurs in different ways New information (blocks, transactions) are distributed as they occur Updates are distributed to nodes that reconnect after a disconnection Onboarding of new nodes – they need a full history of transactions This step focused on communication between the nodes – the next step will focus on how the information received is processed Step 18: Verifying and adding transactions Metaphor: A company which offers the service of correction of multiple-choice tests for universities Unfortunately, the employed contractors show little motivation for doing their job correctly So, the company provides a performance-related compensation governed by the following rules: 1. All answer sheet are to be marked and the solutions and marked answer sheets are available to all contractors 2. Only the first contractor who marks an answer sheet first correctly receives a compensation 3. If a contractor finds out that another contractor marked an answer sheet incorrectly, the contractor who made the mistake has to refund his compensation and the one who discovered the mistake receives the compensation instead Step 18: Verifying and adding transactions Metaphor (continued): Consequences of this performance-related compensation system: All contractors have a strong economic incentive to follow the rules – they get paid only then Due to rule 1, all contractors have the same chance to contribute and earn money Due to rule 1, all contractors have the information needed to control and correct the work of their peers Due to rule 2, each contractor has an incentive to work fast (although quality may suffer) Due to rule 3, each contractor has an incentive to pay attention to quality Due to rule 3, each contractor has an incentive to control and correct the work of its peers What happened next Initially performance improved but afterwards quality dropped drastically – the tests were marked randomly Moral of the story A combination of reward, punishment, peer pressure and competition can be used to manage a group of independently acting individuals as long as they do not collectively counteract The blockchain follows the same rules and is therefore subject to the same weakness Step 18: Verifying and adding transactions Goal: Allow everyone to add new transaction data to the history of transaction data while preserving its integrity Challenge: Keep the system open while ensuring only valid transactions are accepted Idea: Allow all nodes to act as supervisors for their peers and reward them for adding valid and authorised transactions and for finding errors in the work of others All nodes have an incentive to process transactions correctly and point out mistakes of other nodes Step 18: Verifying and adding transactions How it works The blockchain algorithm is a sequence of instructions that governs how nodes process new transaction data and blocks as follows: Validation rules Transaction data: These encompass formal correctness, semantic correctness and authorisation – they are specific to the application goal of the blockchain Block headers: These are agnostic of the content of transaction data but instead on the way information is added to the blockchain data structure – Only blocks whose headers contain the solution of the hash puzzle are processed, otherwise they are discarded immediately Reward Creating valid blocks costs energy, time and money because it requires solving the hash puzzle Only way for peers to solve the hash puzzle is to offer a reward – which is defined by the blockchain algorithm Punishment Whenever there is a reward, there is the temptation to corrupt integrity – punishment is the counterbalance Examples of punishment include reclaiming the reward, not providing a reward if the block is not valid Step 18: Verifying and adding transactions How it works (continued) The blockchain algorithm is a sequence of instructions that governs how nodes process new transaction data and blocks as follows: Competition Providing rewards are costly and therefore it must be strictly controlled A competition based on two types of criteria is needed to have high quality work whilst reducing costs and only those winning both competitions are rewarded Speed competition: the node which solves the hash puzzle first (proof of work) is the winner of speed competition and is the only one considered for the quality competition Quality competition this focuses on the correctness of the submitted block it submits the block to all other nodes, which act as a referee of the quality of the block based on the validation rules for transaction data and block headers if the block is valid, the node is rewarded If the block is invalid, the speed competition is re-opened All nodes have an incentive to be excellent referees of the quality of the block Peer Control All nodes are workers (create new blocks and verify transactions) and supervisors (validate blocks of other nodes as well) This ensures all rules are strictly followed Step 18: Verifying and adding transactions How it works (details) 1. New transaction data and new blocks are forwarded to all nodes (gossip) 2. Each node collects new transaction data in an inbox and selects them for processing 3. Each node processes new blocks immediately with highest priority 4. Each node processes new transaction data by validating them for authorisation, formal and semantic correctness 5. Each node collects only valid transaction data into a Merkle tree and starts creating a new block by solving its hash puzzle 6. As soon as a node finishes the hash puzzle, it sends the newly created block to all other nodes 7. Each node processes new blocks by verifying the solution of its hash puzzle and by verifying all its containing transaction data for formal correctness, semantic correctness and authorisation Step 18: Verifying and adding transactions How it works (details) 8. Each node adds valid blocks to its own copy of the blockchain data structure 9. If a newly arrived block has been identified as invalid, it will be discarded, and the nodes continue with processing transaction data or with finishing the hash puzzle of a new block 10.If a newly arrived block has been identified as valid, the node removes those transactions that are contained in the new block from its own inbox and starts with processing transaction data and the creation of a new block 11.If a block that was added to the blockchain data structure is identified as invalid or useless later, that block as well as all its subsequent block will be removed from the blockchain data structure, and their transactions will be added to the inbox to be processed again 12.The node whose block was accepted will receive the fees for all transaction contained in the block as reward 13.If a block is removed from the blockchain data structure, then the reward for adding it is withdrawn from the node that initially received it Step 18: Verifying and adding transactions Why it works (interpreting the rules) Due to rule 1, all nodes receive all information needed to validate and add transaction data Due to rule 2, nodes process new transaction data they receive Due to rule 3, the blocks created by other nodes are processed immediately on arrival at the nodes inbox Due to rule 4, only valid transaction data are added to the blockchain data structure Due to rule 5, all nodes take part in a race for solving the hash puzzle – the nature of the hash puzzle makes it unpredictable which node will solve it first Due to rule 6, all nodes are informed when a node solves the hash puzzle of a new block Due to rules 6 and 3, all nodes receive the newly created block and recognise the winner of the race for solving the hash puzzle Due to rule 7, all nodes of the system review and verify newly created blocks and ensure that only correct blocks are accepted Due to rule 8, all nodes add new blocks to their own copy of the blockchain data structure and hence grow the transaction history Step 18: Verifying and adding transactions Why it works (interpreting the rules) Due to rule 9, the collectively maintained transaction history is kept free of invalid transactions and hence integrity is preserved Due to rule 10, no transaction data will be added twice Due to rule 11, no valid transactions will get lost even if previously processed blocks are reprocessed Due to rule 11, the system is able to perform ex post validity checks on the transaction history and correct it retrospectively Due to rule 12, nodes have an incentive to process transactions and to create new blocks quickly Due to rule 12, all nodes have an incentive to inform all other nodes about a new block because earning a reward depends on having transactions examined and accepted by all other nodes Due to rule 13, nodes have an incentive to work correctly, to avoid accepting any invalid transaction data, or producing invalid blocks Due to rule 13, nodes have an incentive to review and revalidate blocks and transactions in a retrospective way Step 18: Verifying and adding transactions Dealing with dishonest behaviour It is difficult to create integrity and trust in an open peer to peer system with an unknown number of nodes with unknown reliability and trustworthiness Examples of dishonest behaviour: Submitting transactions by pretending to be someone else Accepting invalid transaction data or blocks Overwhelming a node with many transaction data with the goal to make it crash Refusing to process certain transaction data Refusing to forward information Step 18: Verifying and adding transactions Dealing with dishonest behaviour Security concept of the transactions (identification, authentication, authorisation via asymmetric cryptography and digital signature) restricts access to an account to the owner of the corresponding private key Gossip communication model ensure all nodes eventually receive all information The architecture of the system ensures that the whole system stays alive even if some individual nodes crash or stop processing data The blockchain algorithm provides the rules to process transaction data Everything rests on the assumption that a majority of nodes is honest and will detect and report dishonest behaviour (as it benefits them) – to bring down this system, we need to have a majority of dishonest nodes working in unison Nevertheless, sometimes differences in transaction history of the blockchain data structure will be detected and this is examined in the next step