Course Final Project Requirements

INTRODUCTION:

The final course project will be delivered by teams of students.  Students will self-organize into teams of  approximately 4 students per team.  More will be said about team formation below.

Teams should form during the first two weeks of class, and will need approval by Professor Shacklette.  No team may contain more than four students nor less than three students.  By 11:59 PM of the third week of class, teams will need to formally declare their composition, along with an initial indication of what type of final project ideas they are considering.  As far as forming teams, students should think about relative strengths and weaknesses of each individual team member in terms of experience with application development, programming languages, algorithms, networking, and core math, designing teams that a reinforcing rather than teams that are heavy on a one or two capabilities to the exclusion of others.

ONE POSSIBILITY:

The first possibility is the delivery of a functional blockchain, complete with components including the distributed peer-to-peer blockchain itself, a cryptocurrency, a hashing mechanisms (SHA-256, RIPEMD-160), a Merkle balanced binary tree or Patricia Tree for efficiently managing transactions in the blockchain, a mining capability with a consensus mechanism of your choice along with an associated cryptocurrency, and a wallet for interaction.  That said, we all realize that the summer course is 10 weeks long.  Therefore, any expectations that a team's deliverable as described above will take over the Ethereum market are unwarranted.  The goal here is to give students hands-on experience in the fundamentals of blockchain development and operation.  This means that, among other things, GUI requirements should be kept to a minimum.  Depending on a team's core competencies, you can either add a web-based front end for your blockchain (e.g., for wallets, chain searching/viewing) or you can simply forget about a web-based front end and provide a strict "command-line interface" to your blockchain. 

As you will need to develop your blockchain likely on your laptops, you will not have at your disposal thousands of peer computers on which to exercise your blockchain.  You should therefore use docker+compose to launch the miners and other components of your blockchain in order to simulate peer intercommunication and interaction.  You should plan on demonstrating some significant advancement over and above what you will each turn in in Lab 7, so for example, a stack-based scripting capability would be a good idea.

Your blockchain could be used in connection in exploring a variety of potential use cases, including:

1.  Clinical Trials Management in Pharmaceutical Research
2.  Healthcare management of patients' PHI, such that versatile permissioning tokens may be issued to certain designees (for instance your doctors) and may be revoked at any time and may have a time of expiration
3.  An electronic voting system that allows voters with known identity tokens to cast one vote that is recorded in your blockchain.
4.  A land registry system that can be used to validate ownership of real estate, thus automating title searching
5.  An identity management system that uses private keys and addresses to authenticate identity
6.  A Regulatory and Compliance Audit System

For other ideas, see take a look here and here and here.

OTHER POSSIBILITIES:

Really anything related to Blockchain.  These may include:

A data analytics play that leverages available APIs from existing exchanges and aggregates or otherwise provides real-time analytics for one or more cryptocurrencies, perhaps exploring arbitrage opportunities.

A Trading Application that runs on (perhaps) Testnet or Regtest, that performs trades against an exchange that you will write.  The exchange will provide various services including a Matching Engine, Trade Publisher, Book Publisher, and Reporting Engine.