Implementation of chain data structure

references #3, #4, #5

Blocks and appropriate functions

• Chain, #1
• Blocks, #2
• Transactions, #6

• Patient
• Admission node
• Doctor's node

• Sync between nodes (I have some good ideas how we can solve this in a smooth way, please ask if you want to implement it)

• Interaction: We need to be able to start nodes with some cli interface in docker. There are 2 different types: (a) doctor -> just give me options to generate transactions; (b) admission: give options to generate block at random time, wait until a generated block is broadcasted (so ask "Should I send the new block? (Y/N)) (wip #45)

• There are a lot of inline todos. e.g. transactions in branches that get's deleted need to be added to the queue again (if not already in another block)

• Some random latency in the network module would be nice.

• Try every option in the user interfaces!

• Does it work to register d3 as admission? In this case we can undo the changes in blockchain/transaction/vaccine_transaction.py of db8b717

• improve some validity checks (for example is doctor?)

Block broadcast doesn't work, if it is only sent to the same server. We have to test this feature, once we have more neighbours.

This issue describes what need to be done to make judgements work

General notes:

• A block is discarded from a chain if the host received more than half the number of admissions denying the block at this point of the chain
• Each admission will send judgements over the received blocks. Each block gets an accept, if the block matches more appropriate at any point of the chain (e.g. it was created by a older admission node at this point of the index).
  A admission can change an accept to deny if it receives a more suitable block for that positions (in this case the new block gets an accept and the accept of the old block (and every following block) is changed to deny
• Until a block gets enough denys there could be more than one chain branch. the chain is therefore saved as a tree structure. (since every admission node will just accept one tree at a time, it will converge towards a tree with 1 child per tree-node)

TODOs (the list is probably not extensive. Feel free to add ToDos)

• block creation should check to generate a block for each leaf of the tree (PR #42)

• Blocks needs to be saved to disk with following filenames: <index of the block>_<hash of the parent>_<own hash> and we need to reconstruct the tree structur from these files (implemented in PR #40)

• receive block methods needs to remove contained transaction from its own queue (implemented in branch tree_structure PR #42)

• judgements: create judgement object (implemented in PR #41)

• full_client: send judgement: broadcast the judgements(implemented in PR #41)

• full-client: receive judgement: save judgement, check if we can delete a tree branch (wip PR #41)

• chain: admissions_at_hash: who was a admission at the block with hash (including the transactions in this block) (PR #42)

• chain: history_at_hash: what are the oldest admission (descending) at block with hash. Again including the block with hash (PR #42)

• full_client: sync: sync the tree with neighbors (keep in mind there may be new branches yet unknown to you. We also need to send the judgements with the block, as the node that gets synchronized would miss out on all the judgements otherwise)

• chain: admissions: return the admission list for each leaf of the tree with the following structure: [(last_hash, [history of admissions descending]), (...), ...] (PR #42)

• chain: remove_tree_at_hash: remove the complete sub-tree including the node with hash (implemented in branch tree_structure PR #42)

• chain: get_tree_list_at_hash: get a list of all blocks in the sub-tree with hash as root (needed to change judgements to deny) (implemented in branch tree_structure PR #42)

• chain: add_block: Add block in the tree if possible or add it to dangling blocks. (PR #41)

• chain: replace list data structure with tree structure (implemented in branch tree_structure, WIP, contains bugs) (PR #42)

• print the chain tree (for demo) (implemented in branch tree_structure, demo in main.py)
  Inline

• inline ToDos
  full-client process_dangling_blocks needs to adjust to chain

• full-client process_dangling_blocks needs to adjust to chain tree (PR #41)

• #44

Optional (not directly needed by demo)

• Don't save complete block in the chain tree. just frequently used informations (like hash, timestamp, index). Additional infos are read from disk if needed

• Minimize tree node content. Just safe blockindex and hash of block. every other information needed is loaded from the disk (that shouldn't occure frequently). Therefore we have space to save the cahces within each tree node (dynamically created - not written to disk)

• Don't hold the complete tree in RAM. Just from the point where we have the first node with multiple children. older parts are loadad as needed.

Raw-Notes:

• clean up unused/obsolete methods
• refactor/rename methods of network module (e.g. broadcast_new_tx does not broadcast but send to a specific node) fixed in #55
• decide on what to do for inlined TODOs (fix, WONTIFX, or remove)
• finish method documentation
• document how to use docker (which volumes do exist and can be replaced, which env variables exist...)
• refactor public key handling. Conversions can be part of cryptography helper module
• Explain structure of chain tree in readme
• Explain consensus protocol in readme
• CI
• CI like document generation: Possiblewith sphinx and readthedocs. Sphinx is rather hard to setup
• Add description how to generate genesis block with this code
  ver
• version number in the beginning of the block (on disk) - won't implement
• edit version check in block_validator
• create git tags
• delete unused branches or describe why they still exist
• send final mail