memoriesadrift / tuw-cryptocurrencies-blockchain Goto Github PK

Description

This task is two things:
High priority, quick task: create the foundations for how to write tests so we can stick to it in the future.
Low priority, collaborative task: Whenever you finish a task, add some tests for it.

I don't personally think bothering with things like code coverage is worthwhile. Let's just make sure all the important functions are reasonably tested and do what we expect them to.

Scope

1. Create a testing framework & define how to test by creating sensible templates (we can use jest or something probably, but can also make our own and extend as we go)

Scope:

1. Create the logic to represent a transaction. The protocol description defines the struc-
   ture of a transaction.
2. Create the logic for transaction validation as specified by the protocol description. Trans-
   action validation contains the following steps:
   a) For each input, validate the outpoint. For this, ensure that a valid transaction with
   the given txid exists in your object database and that it has an output with the given
   index.
   b) For each input, verify the signature.
   c) Outputs contain a public key and a value. The public keys must be in the correct
   format and the values must be a non-negative integer.
   d) Transactions must satisfy the weak law of conservation: The sum of input values
   must be equal or exceed the sum of output values.
   For now, assume that a (syntactically valid) coinbase transaction is always valid. I.e.,
   you do not have to check how many new coins have been created or what the height is
   set to. We will validate these starting in the next homework.
3. When you receive a transaction object, validate it. If the transaction is valid, store it
   in your object database and gossip it using an ihaveobject message. If it is invalid,
   send an error message to the node who sent the transaction and do not gossip it. In
   case the other node sent you an invalid transaction, you should consider the other node
   faulty. If you could not verify a transaction because it references an object not known to
   you, this does not indicate a faulty communication partner and you should not close the
   connection, just send an UNKNOWN_OBJECT error message (for now).
   You should test your transaction validation by generating different valid and invalid transac-
   tions, signed using a private key of your choice.

Description

We expect you to host your implementation yourself and let it actively participate in the Kerma
network.

• Use a static and public IPv4 address. One way to get such an address is make use of
  free student offers available through (for instance) GitHub Student, and to host your
  node on a VM in the cloud. Upload the static ip address to TUWEL.
• Host your node behind a dynamic, public ip address and provide us with a domain entry
  that always points to this address.
  In addition to your solution for Task 1, each group must provide a static IPv4 address or a
  hostname until the deadline for this task.

Scope

1. A static IP or domain for the project
2. Investigate and decide on hosting for the project

Description

Note that a single message may get split across different packets, e.g. you may receive "type":"ge and tpeers" in separate messages. So you should defragment such JSON strings. Alternatively, a single packet could contain multiple messages (separated by "\n") and your node should be able to separate them. Note that JSON strings you receive may not be in canonical form, but they are valid messages nevertheless.

Scope

• Defragment messages
• Split messages by \n
• We should already be accepting messages in non-canonical JSON

In this exercise, you will implement a UTXO set and update it by executing the transactions of each block that you receive. This task will not yet cover all the features of the UTXO set. We will revisit this part in future homeworks.

1. For each block in your database, store a UTXO set that will be computed by executing the transactions in that block. This set is not modified when you receive transactions, only when they get executed during handling of new block objects.
2. When you receive a new block, you will compute the UTXO set after that block in the following way. To begin with, initialize the UTXO set to the UTXO set after the parent block (the block corresponding to the previd). Note that the UTXO set after the genesis block is empty. For each transaction in the block:
   (a) Validate the transaction as per your validation logic implemented in Task 2. Addi- tionally, check that each input of the transaction corresponds to an output that is present in the UTXO set. This means that the output exists and also that the output has not been spent yet.
   (b) Apply the transaction by removing UTXOs that are spent and adding UTXOs that are created. Update the UTXO set accordingly.
   (c) Repeat steps a-b for the next transaction using the updated UTXO set. This is because a transaction can spend from an output of a non-coinbase transaction in the same block.
   For testing your node, you can use the genesis block which is a valid block. Below is another block mined on the genesis block that is valid. You can also mine more blocks to test your validation.

Description

• Implement peer discovery bootstrapping by hard-coding some peers (for now, only hard-
  code the bootstrap node 128.130.122.101:18018).
• Store a list of discovered peers locally. This list should survive reboots.

Scope

1. Maintain local peer list
2. Implement peer discovery -> i.e. what to do with data obtained from peers/getpeers

In this exercise, you will implement block validation for your Kerma node.

1. Create the logic to represent a block, as defined in the protocol description.
2. Check that the block contains all required fields and that they are of the correct format.
3. Ensure that the target is the one required, i.e.
   "00000000abc00000000000000000000000000000000000000000000000000000"
4. Check the proof-of-work.
5. Check that for all the txids in the block, you have the corresponding transaction in your local object database. If not, then send a "getobject" message to your peers in order to get the transaction and leave the validation of the block pending. Resume validation once you received all transactions. Note: fail transactions if we can't get missing info within 5 seconds for each missing item
6. For each transaction in the block, check that the transaction is valid, and update your UTXO set based on the transaction. More details on this in Section 5. If any transaction is invalid, the whole block must be considered invalid.
7. Check for coinbase transactions. There can be at most one coinbase transaction in a block. If present, then the txid of the coinbase transaction must be at index 0 in txids. The coinbase transaction cannot be spent in another transaction in the same block (this is in order to make the law of conservation for the coinbase transaction easier to verify).
8. Validate the coinbase transaction if there is one.
   (a) Check that the coinbase transaction has no inputs, exactly one output and a height. Check that the height and the public key are of the valid format.
   (b) Verify the law of conservation for the coinbase transaction. The output of the coin- base transaction can be at most the sum of transaction fees in the block plus the block reward. In our protocol, the block reward is a constant 50 × 1012 picaker. The fee of a transaction is the sum of its input values minus the sum of its output values.
9. When you receive a block object from the network, validate it. If valid, then store the block in your local database and gossip the block to all of your peers as you did with transactions in the last task.

Description

• When you connect to a node or another node connects to you, send a "hello"
  message with the specified format.
• If a connected node sends any other message prior to the hello message, you must
  send an "error" message with error name INVALID_HANDSHAKE to the node and
  then close the connection with that node.

Note: Every message you send on the
network must have a newline, i.e. "\n" at the end. Your node should use this to
help parse and defragment valid messages. If you do not receive a hello message
after 20s or receive a second hello message, you should send an error message
(again with name INVALID_HANDSHAKE) and close the connection.

Scope

1. Send hello message to newly discovered nodes
2. Error when receiving anything but a hello from unknown nodes
3. Reply with hello when receiving hello from unknown nodes

Useful links

DB interface documentation

Scope:

1. Maintain a local database of known objects. The database should survive reboots.
2. Implement a function to map objects to objectids. The objectid is obtained by taking
   the blake2s hash of the canonical JSON representation of the object. You can test your
   function using the Genesis block and its blockid given in the protocol description.
3. Implement object exchange using the getobject, ihaveobject, object messages.
   a) On receiving an ihaveobject message, request the sender for the object using a
   getobject message if the object is not already in your database.
   b) On receiving an object, ignore objects that are already in your database. Accept
   objects that are new and store them in your database if they are valid.
   c) Implement gossiping: Broadcast the knowledge of newly received valid objects to
   your peers by sending an ihaveobject message to all your connected peers.
   d) On receiving a getobject message, send the requested object if you have it in your
   database

Description

Implement canonical JSON encoding for messages as per the format specified in the
protocol.
Implement message parsing, defragmentation, and canonical JSON encoding and decod-
ing. On receiving data from a connected node, decode and parse it as a JSON string.
If the received message is not a valid JSON or doesn’t parse into one of the valid mes-
sage types, send an "error" message with error name INVALID_FORMAT to the node.
Note that a single message may get split across different packets, e.g. you may re-
ceive "type":"ge and tpeers" in separate messages. So you should defragment such
JSON strings. Alternatively, a single packet could contain multiple messages (separated
by "\n") and your node should be able to separate them. Note that JSON strings you
receive may not be in canonical form, but they are valid messages nevertheless.

Scope

1. Decide on internal data structures
2. Implement encoding to canonical JSON from internal data structure
3. Implement decoding to canonical JSON from internal data structure

Note

Try leverage TS support in JSON.parse()

This seems like a larger task, maybe we can divide it, but I feel like making two different people work on the same problem from two different angles may lead to confusion

Description

Various smaller tasks to make sure submission is OK.

If your node receives a valid message with different type than hello, getpeers or peers,
you are not required to determine its validity in this task. You should not, however, close
the connection if such a message is sent to you. For instance, if your node receives a
{"type":"getchaintip"} message, then you should just ignore this message for now.

Test creating and running the source code as if it were being submitted, see readme.

Scope

1. Ignore method calls that we don't currently support
2. Test for submission

Description

Implement the networking core of your node. Your submitted node must listen to TCP
port 18018 for connections and must also be able to initiate TCP connections with other
peers. Your node must be able to support connections to multiple nodes at the same
time.

Scope

1. Support multiple concurrent TCP connections
2. Initiate TCP connections

Blocked by #4, #5

Description

• Upon connection with any peer (initiated either by your node or the peer), send a
  "getpeers" message immediately after the "hello" message.
• On receiving a "peers" message from a connected peer, update your list of discovered
  peers.
• On receiving a "getpeers" message from a connected peer, send a "peers" message
  with your list of peers. Note that by specification of the protocol, a "peers" message
  must not contain more than 30 peers. If you have more than 30 peer stored, devise a
  policy on which 30 you send over the network.
• Devise a policy to decide which peers to connect to and how many to connect to. We
  suggest to connect to just a few nodes, and not all of them.

Scope

1. Send getpeers message after establishing a handshake
2. Send peers message when receiving getpeers message from a known host
3. Devise a policy on which nodes to connect to (should be more robust, akin to a final implementation, imo)
4. Devise a method of choosing 30 peers to send if over 30 peers stored (can probably be a placeholder strategy for now)