Course:CPSC312-2017-312Coin

From UBC Wiki
Jump to: navigation, search

312 Coin (Pending a better name)

Authors: Corey Jack Wilson, Lyndon Won

What is the problem?

The biggest hype word in computer science right now is clearly the word 'Blockchain', so we want to see if we can build one using a functional programming language like Haskell. At first glance, Haskell seems well suited to several challenges a proper implementation of a blockchain needs to handle. First, making Proof of Word algorithms easy to understand and maintain as the codebase grows. Second, implementing hashing algorithms to ensure the blockchain can scale. Finally, providing an efficient implementation of a transaction validation algorithm to ensure the blockchain is accurate. Thus, we plan to implement a blockchain that is efficiently implemented, easy to use and maintain.

What are the necessary user stories we will address?

In order to be a blockchain we need to implement several things:

  • Transactions can be validated
  • Transactions can be stored in a block with unique IDs
  • Users can interact with the blockchain, transactions, and mine blocks through a basic REST API

What is the something extra?

We will attempt two other use cases:

  • Transactions are stored in a pool and propagate through nodes in a P2P network
  • Nodes can arrive at consensus on the Transactions Pool

Nice to haves (If we have time)

  • Maximum transactions per block with a CLI argument to set
  • Reporting on status of all nodes in the network via a REST endpoint
  • Nodes mine for rewards
  • Incase all nodes go offline, use a RDB to backup the chain, transactions, etc

Known Issues/Bugs

1. A block can be mined that contains no transactions

  • trying to figure out the Maybe pattern so that the mineBlocks function can return nothing if the transaction pool of the node == []

Change Notes

1. We changed "What are the necessary user stories we will address?" to:

  • Transactions can be validated
  • Transactions can be stored in a block with unique IDs
  • Users can interact with the blockchain, transactions, and mine blocks through a basic REST API

We did this because the PoW algorithm and hashing was mostly provided by the Legion cryptocurrency implementation that we sourced from.

2. We changed "What is the something extra?" to:

  • Transactions are stored in a pool and propagate through nodes in a P2P network
  • Nodes can arrived at consensus on the Transactions Pool

We did this because the registration of new nodes was provided by the Distributed.Backend.P2P module that we used. Similarly, the consensus algorithm was provided by the Legion cryptocurrency implementation that we sourced. Finally, adding in rewards did not make any sense with our specification of how the blockchain would work. In essence, we couldn't figure out an effective way of implementing competing for mining of blocks when the initiation of block mining was due to a REST trigger.

What did we learn from doing this?

Does the code work? Aside from the bug mentioned in the aforementioned section the code meets specifications. Transactions can be created, validated and stored in blocks where the mining takes into account the transactions when hashing. Moreover, users can interact with the network to initiate mining, submit a transaction, and get all the current transactions mined so far in the chain.

Is the extra part interesting? Does it give evidence for the usefulness of what you have done? Sure is! Because we need to be able to initiate mining on any node, we used a P2P network to propagate all validated transactions throughout the network. That way, a user can mine at any available node, and validated transactions will always persist throughout the network as nodes log in and out.

Is the code readable and well documented? Does it give the intended interpretation for all symbols? Would someone else be able to take your code and build on it? We plan to continue working on 312Coin(with hopefully a better name) after this project is done, so we made sure to make the code readable and easily extensible. The code is also organized in terms of functionality. We made sure to do type declaration and documentation for our functions. Additionally, we made sure to label code that we used from existing open-source projects. If we have time before the demo, code will be refactored out into modules to make maintenance easier.

Is the conclusion on the feasibility of your approach justified by the evidence?' So here is where things get interesting. Haskell on its own is very efficient in calculating the PoW, hashing, and providing the necessary functions for quickly extracting data from the chain (i.e. when validating transactions). Moreover, maintainability is simply, the code is easier to read, and not having to deal with side effects is beneficial (especially when dealing with a P2P network). The catch is that the modules one has to rely upon are relatively immature and the communities for support as basically non-existent. For example Control.Distributed.Backend.P2P, which we relied up for this project, had very sparse documentation and few examples to draw upon for basic information on how it even worked. Moreover, it even appears abandoned in favour of the Cloud Haskell framework. This was similarly the case for the Spock web framework which we used. Few examples, limited documentation, and no community. In sum, while a functional language like Haskell has obvious benefits for simplifying non-trivial algorithms often involved in blockchains, and cryptocurrencies, these benefits are tempered by the lack of maturity in the additional frameworks required for bringing such a project to production without having to reinvent the wheel.

Code Used

Source Code

Github Repository