2020p block-chain-solution PDF

Preview

Summary

Minimum Viable Block ChainSecond Deliverable (theoretical alternative)Author: Antonio González Distributed Systems course Spring 2020Índex de contingutsAssignment outline.............................................................................................. Theoretical questions.................

Description

Minimum Viable Block Chain Second Deliverable (theoretical alternative) Author: Antonio González Distributed Systems course Spring 2020

Índex de continguts Assignment outline..............................................................................................1 Theoretical questions..........................................................................................1 Practical exercises...............................................................................................2 To deliver.............................................................................................................3 Annex I: blockchain notification headers.............................................................4 Annex II: PKI reference........................................................................................4 Sign / Verify:.....................................................................................................4 Asymmetric encryption....................................................................................5

Assignment outline The aim of this assignment is to understand the main concepts of the block chain systems. Block chain systems combine many concepts in order to give a solution to a distributed ledger with security. In order to get the basic details of the Block Chain read the following article: https://www.igvita.com/2014/05/05/minimum-viable-block-chain After reading the full article the assignment consist on: •

Responding the “Theoretical questions”

•

Resolve the “Practical exercises”

Theoretical questions 1. Explain why digital signatures, proof-of-work and transaction blocks are needed. •

digital signatures: To ensure authentication, non-repudiation and integrity of transactions.

•

proof-of-work: To retain cheaters to behave badly by forcing all parties to make an effort for each transaction that they want to be accepted. It is an economic measure, the proof itself has no more use than associating a cost to each transaction.

•

transaction blocks: To incentive participants in the network to confirm transactions by allowing them to pool and confirm multiple transactions at once.

2. In a block chain with 10 million users, what prevents users falsifying transactions? Is it infallible? One can say that all properties of the system help in preventing against cheating users. Being said that, the use of PKI cryptography and the proof-of-work may be highlighted. PKI cryptography to ensure the integrity of the transactions, and the proof-of-work (POW) to keep bad users away from cheating the system by impacting them with high costs to achieve its bad behavior. 3. How it is resolved that a user does not have to spend a value equal to or greater than the value of the transaction itself. Allowing network participants to confirm multiple transactions at once. 4. In what situations do chain conflicts occur? How are they resolved? As block generation is not coordinated by the network, all peers willing to confirm a block of transactions compete to add their last confirmed block at the top of the ledger. This may result in conflicts when blocks propagate through the network. The way to resolve this conflicts is by finding the longest chain of linked blocks and switching to this branch of the block chain and discarding the other branches. 5. When we send a transaction to the network for confirmation, when can we be confident that it is definitively confirmed? Because the number of peers in the network is unknown and changing, there is always the possibility that a longer chain of linked blocks arrives. If that chain does not contain our transaction, it then should be considered unconfirmed. So there is never a moment when one can say that a given transaction is confirmed with 100% confidence. 6. Can you list some use cases for a Block chain? Open answer

Practical exercises 1. Sketch a diagram (you can use Dia: https://wiki.gnome.org/action/show/Apps/Dia, or the alternative that better suits you) highlighting the main actors of the described block chain. (Delivery should be in PDF format, this is not a UML diagram). Open answer 2. Let's say you are a party interested in collecting fees by validating and confirming transactions. You have received enough transaction notifications (File: transaction_notifications.csv -csv headers in Annex I-) to compensate your proof-of-work costs so you are willing to generate as many blocks as possible. Now you have to validate all received transactions (remember to check for double-spends) and aggregate them into blocks of five transactions each.

NOTE: The balance of each participant at t0 is: •

A: 100€

•

B: 50€ (suppose that all signatures verify correctly). a) Have you received double-spents? in this case indicate which transactions are not valid. Marked in bold in the “transaction notifications” tab in the transactions_correction.odt file. b) Show which transactions get aggregated into which blocks. Second tab (named “ledger”) in the transactions_correction.odt file. c) Which fields are required by a ledger.csv to support both transactions and block annotations? Current fields may be reused, but students may propose options with more fields that may also be correct. Let’s explain how fields can be reused: Each Block will add one transaction annotation and one block annotation. For the transaction the “From” field can be filled with “Fees” and the “What” field with the list of transactions in the block. For the block annotation the “sha256” field will be filled as usual, the “From”, “To” and “Value” fields will have to be left blank, and the “What” field will be filled with a reference to the previous block. d) Write a ledger.csv file with the annotations for your blocks and the transactions that this blocks aggregate. (suppose fees for 0.1% for each transaction in a block) See “ledger” tab in transactions_correction.ods. e) Which is the balance of C at the end of the exercise taking into account the 0.1% fees? (3 decimals) 39,905€ See “ledger” tab in transactions_correction.ods.

3. Using the same transaction_notifications.csv file, plus the *.signature files: NOTE: signatures made with the command: echo 'A,B,€,1,35'|openssl dgst -sha256 -sign pki/A.key -out notification_1.signature

a) Verify all signatures and indicate which signatures are correct and which don’t verify. Remove invalid notifications, if any. All are correct. b) Generate your key-pair and sign your block transactions from the previous exercise. Should be checked manually with openssl.

Two things should be cheked: the checksum of the signature and the signature. Repeat he steps from some random rows of the student’s csv: - Select some row and find the corresponding transaction.signature file, copy the checksum in the clipboard. - Generate the checksum of the signature with: openssl dgst -sha256 transaction.signature - To verify with public key, the transaction.signature: openssl dgst -sha256 -verify...