ubclaunchpad / cumulus

💸 Cryptocurrency that doesn't waste your time

Cumulus 💸

Cryptocurrency that doesn't waste your time.

Introduction

At UBC Launch Pad we’ve been interested in crypto-currency and blockchain tech for a while now, and after several months of experimentation we’re excited to announce our latest project. Cumulus is a new cryptocurrency with its own blockchain and token. The current command line interface allows users to create wallets, mine coins, and send funds to other users.

There are a lot of cryptocurrencies out there already, so it’s a fair question to ask what makes Cumulus special over other, more entrenched currencies like Bitcoin and Ethereum. The short answer is because we’re all excited by the possibilities created by this technology! In addition, there are many problems in the blockchain space that remain to be solved. Other cryptocurrencies have significant downsides like small block sizes and vast computation waste spent securing the network. We are addressing many of these problems in Cumulus. Beyond that, we see massive opportunities in this space in the years to come. Cumulus is the infrastructure on which we can build in the blockchain space as it matures.

You can read more about Cumulus in the Medium post introducting the project as well as the extensive wiki documentation.

Installation

MacOS - the Cumulus CLI can be installed using Homebrew:

brew install ubclaunchpad/tap/cumulus

Windows - the Cumulus CLI can be installed using Scoop:

scoop bucket add ubclaunchpad https://github.com/ubclaunchpad/scoop-bucket
scoop install cumulus

You can check the installation and see the Cumulus CLI documentation by running:

cumulus --help

Building

First, install Go and grab the Cumulus source code:

go get -u github.com/ubclaunchpad/cumulus

Cumulus uses dep for dependency management. The following will install dep and run dep ensure:

make deps

You can now build and run Cumulus:

make run-console

Testing

make test

cumulus's Issues

Mining & PoW

Design a PoW system and implement an algorithm for miners to run to find solutions. Add consensus rules to block verification that check PoW. Design a system to choose the PoW puzzle for the next block

Transaction Pooling

Transaction Pooling

🤔 When nodes become aware of Transactions, they have to individually validate and store them somehow.
💭 New Transactions must be validated with respect to the BlockChain and to the pool of validated transactions.

💡 Ideas

🚋 FIFO the incoming transactions, add validated transactions to a sorted list (the pool), do logn lookups within the pool to validate.
🌴 Merkle tree the FIFO Queue, do lookups and rebuild in logn time.

Considerations & Workflow

1. Node becomes aware of transaction.
2. Node validates transaction.
   • Node ensures outputs not already spent
   • Node verifies uniqueness of transaction.
3. Node relays transaction to other nodes.
4. Node prunes pool when it becomes aware of new blocks.

Internal node state model

A model for all the data a node needs to be aware of:

• blockchain
• transaction pool
• etc.

Implement P2P Scaling

Implement P2P Scaling based on design in #16. Write integration tests to verify that load is distributed

Fix net/identi error "did not have own public key in Peerstore"

This happens when attempting to set up a Stream.

Implement Verification

Implement ValidTransaction and ValidBlock

• Check Signature against public key.
• Verify Fee (if applicable).
• More...

Optimize Block Transaction Structure

Optimize Block Transaction Structure

👎 Currently some Block validation operations are in polynomial time. We would like to reduce that.

💡 Ideas

1. A sorted list, sorted by input Hash, results in logn lookup, nlogn build time.
2. A merkle tree logn lookup, nlogn build time.
3. A hashmap with input Hash as key.

Fix errors in `goveralls`

Goveralls causes Travis build to fail. See https://travis-ci.org/ubclaunchpad/cumulus/jobs/229615046

Research Go and Cryptocurency

Read:

• Effective Go
• Chapter 1 of Princeton Bitcoin Book
• Misc. research on cryptocurrency

P2P Message-Sending

Design a protocol for sending messages between peers.

High priority messages:

• Initial connection (maybe just handled by libp2p)
• Request/send list of peers
• Request/send blockchain
• Request/send particular block by index
• Send block (new block has been mined)
• Send transaction (new transaction waiting to be put into blockchain)

Peer - create connections to another peer

All using message layer:

• create initial connection
• request / automatically get list of available peers (store somewhere)
• create new connections to other peers
• accept new connections from other peers
• keep "subnet" updated with current peers

Message Layer Gob Issues

The way the message layer is set up doesn't work very well with gob.

• Fix this
• Add tests to verify that sending/receiving messages will work.

Write High-Level design draft for blockchain implementation

Do research into Ethereum implementation and write a wiki page detailing the high-level design of the blockchain, including structure of wallets, transactions, blocks.

Design P2P Scaling

Research P2P Scaling and design a protocol for ensuring we can scale our network and distribute load.

Set up heartbeat for peers

Implement simple version of blockchain

gotta be good. highest quality only

Simple 1 to 1 transactions

• Ability to hash transactions and blocks
• Ability to encode/decode blocks for transmission over the network
• Ability to verify a transaction given a blockchain
• Ability to verify a new block given a blockchain

Create example `estimate` values

Create some sort of documentation for how we will measure estimates.

Read Ch. 1 of Bitcoin Book

Initialization logic

Logic for getting a newly started node into a stable state.

• acquire the blockchain
• connect to some neighbouring nodes

Business Logic for nodes

How the node should behave.

When a node is started from the command line, it should do some initialization:

• download the blockchain
• connect to some other nodes in the network

After it has reached a stable state, it should respond to requests and pushes in a reasonable manner by updating its state.

Set up integration testing

• Set up an integration testing environment with ginkgo
• Write a couple example tests with it
• Incorporate into Makefile and Travis

Consensus Algorithms

Nodes will potentially need to be aware of multiple forks of the blockchain and a pool of unconfirmed transactions at any given time. We need to provide consensus rules for each node to follow so that decisions they make are respected by the rest of the network. For instance, a mining node should always work off the longest version of the blockchain, but keep older versions around in case one catches up.

Read Effective Go

Peer package refinements

• Remove chanStore, request method should provide a callback
• Modify Dispatcher to call response callback
• Store callbacks where we store the response channels
• Come up with better name than peerstore

Request handling logic

Respond to requests in a reasonable way.

Set up continuous integration and testing

Protect master
Create dev branch
Set up Coveralls, Travis, minimum test coverage for merging to master

App skeleton

• Create an app package which will contain the business logic for the app.
• Create a constructor for making a new app instance that accepts a configuration object as parameter

Error handling in miner code

Replace TODOs with error handling in miner code

Create a math library for the Hash type

This can be done using math.big

Set up Heroku Peer

Once the basic p2p code has been written we need to set up auto-deploy to a Heroku instance so we essentially always have a peer running that we can communicate with.

Maintain peer connections within certain range

Create algorithm for keeping number of peer connections above a minimum threshold. Create rules to respond to new connections and dropped connections

Make project timeline

Plan 4-month timeline of research and implementation

P2P Scaling

Research, design, and implement P2P scaling.
We want:

• nodes to detect disconnected peers and connect to new peers to offset the loss
• every node to have roughly the same number of peers, most of the time
• ingress nodes to be able to quickly offload new peers to the rest of the network

Push handling logic

Update internal state with the payload when a push comes in.

Miner PoW Prototype

Miner PoW Prototype

🥈 Create a Prototype for miner's proof of work.

Additional Information

🏃 Miners compete to solve a Puzzle (which is produced with the hash of the most recent Block appended to the Blockchain).
🔫 For a prototype, we want Miners to repeatedly hash their own Wallet concatenated with some random string of bits.
😶 The first Miner who generates a hash that is similar enough to the Puzzle hash has "mined" the next block.

Connection Layer

Implement a connection layer that:

• Creates connections to other peers
• Expose a net.Conn

Install and set up basic libp2p

• Install the package
• Document installation on the wiki (especially the tricky bits)
• Write "Hello World" code that uses libp2p and connects to available peers

Create Cobra Scaffolding

Refactor main.go code into a Cobra app

Vendor dependencies with Glide

Do this after #7 is merged

NAT Traversal

We need a way for computers behind a NAT to connect to the network.

Some options:

• hole punching
• UPnP

Write tests for blockchain implementation

Get code coverage for package blockchain to 100%

Model for connections

Model for "other nodes on the network":

• Contains that peer's connection
• Has a reader on the stream that dispatches message to handlers
• Exposes a thread-safe Write method
• Is well tested

Allow peers to communicate over public IPs

Currently peer IPs are hard-coded to 127.0.0.1 (sadface). Make it better!

Visuals & Demoability

What is going to be the end result or deliverable of this project? We have build this cool cryptocurrency, but how do we show people?

Comment any ideas on this issue :)

Replace libp2p with Wrapper over TCP

libp2p doesn't really do anything for us and has been causing some problems.

We have a solid message layer that reads and writes messages from an io.Writer/io.Reader.

We need a wrapper around TCP for:

• Creating connections to other peers
• Expose a net.Conn

We need a model for "the other people on the network" that:

• Contains that peer's connection
• Has a reader on the stream that dispatches message to handlers
• Exposes a thread-safe Write method

We need:

• To keep track of the set of peers we're connected to

System for spending mined coins

Implement a system for encoding mined coins in a block and ensure that spending of these coins works.

Chad's idea: put mined transaction at Transactions[0] with a special input

Command Line Interface

Create a CLI for Cumulus (probably using Cobra)

• start a new peer
  • mine or not
  • ingress URI
  • other options...
• send a transaction
  • ingress node to send transaction to
  • key to sign with
  • quantity/recipients/etc.

Set up Makefile

• Build executable
• Run tests
• Get dependenciess
• Update travis to use Makefile

Build message layer

• List of message types
• Documentation for message types, syntax, meaning
• Encode/Decode capability (gob)

Test Miner

Write test suite for new miner and hash functions used for miner