In this lecture i take you through all the set-up requirements for our python development environment. We are going to develop this blockchain from a Virtual Private Server (VPS) or Digital Ocean Droplet. This set up is good if you do not want to clutter your personal machine with a blockchain node, but also it will enable us to standardise the course. So whether or not you are on a Mac or Windows machine, the process to acquire a VPS and work with it will be the same.

In this lecture we will be creating our folder structure in the VPS that we will be working from. We will also create a remote git repo in our VPS which will be connected to our private machine. This will allow us to write code in our private machine on the code-editor and push it to the git repo immediately, so we can run that code in the VPS and python environment.

In this lecture we complete the set-up process by installing the Python virtual environment. We install python and all the development tools required for the system to work. We also install the python virtual environment - VENV. This will be the space where we run our code from. When the environment is created, we install the python libraries that we will need for this project, in addition to that we write some code to test our ENV and push it to the VPS. To complete the lecture, we create our genesis block - or write code associated with out genesis block, and print it on the command line.

Create functions within the Account class of the blockchain. All the EC - Eliptic Curve functions will sit in this class mostly. We start with creating a private and public key, displaying them so you see what they look like. We then create a transaction dictionary object which includes the transaction data, transaction id and timestamp. This object is then encoded and signed to get a signature that will go with the transaction. We create our first transaction.

We complete our transaction signing process from last lecture. Then we move on to write code for mining a block. This is the proof-of-work function, we explain how mining difficult is introduced in proof-of-work algorithm to delay how long nodes take to mine a block. We expand our Blockchain class by adding the init function that creates the genesis block as well.

In this lecture we expand on our account class and blockchain class, re-write them to include everything that we need. We then create a new file called app - where we import these classes in to one file - so we can call the account class to get signing keys, and the blockchain class to create transactions and blocks from the same file. We test out our functions from one common file, adding a couple of transactions to our transaction pool and mining a block. We display results to visualise our blockchain on the terminal - so you can see what the data looks like that is currently saved.

In this lecture we go through the process of creating our flask application. We are going to need a client facing web-app to allow for communication with the blockchain end-points within the same node. So far we have be hard-coding our transactions, but in reality - someone may enter it in a web app. We go through best-practice folder structure for Flask and create a basic skeleton app and run it on our VPS.

We recap on everything we have done so far and draw a picture showing where we started and where we want to go with this program. I show a high level overview of our one node - and how this node is going to interact with the peer network, where the database comes in and how the client communicates through the web-application. This is a good time-out to take account of where we are in this blockchain coding journey. I help you understand how everything fits together - so far.

MYSQL database set-up on the VPS machine. We create the database that we will be using outside of python - we go through the normal process of creating a MYSQL database in Ubuntu 20.04 from the command line and adding our blockchain database to it. We need the database to store out transaction and block data in a local database for our node.

We continue with MYSQL database set-up. We create a test table from the command line and populate it from python code, add data to the table and display the data again. Just to go though basic mysql functions we will be using in our app and to get you familiar with it.

We create the blockchain database tables that we will need - this is very specific as MYSQL requires one to specify exactly the data type in the columns before getting started with entering any data. This means we have to be clear from the start what columns we will be having in our blockchain database and what datatypes will be in those columns. We create: (1) Transaction table, (2) Blockchain table and (3) Nodes table.

Back to our Flask application, we style our front-end with Bootsrap CSS and JS library. We also start building the endpoints - routes of our flask application. The first routes we build is: (1) A route to allow for transactions to be added from the front-end. Transaction data will be accepted in the back end and processed in to the transaction pool, including the signature, transaction id etc., (2) A route to display all the transactions in the transaction pool.

In this lecture we add the form required to the front end of the app to capture transactions and send them to the back-end.

In this lecture we start re-writing all out blockchain functions to include the SQL database integration. Start by re-writing the genesis block function, then move on to the transaction function and the mining function. The blockchain class now needs to talk to the database instead of storing data in memory. Transactions are stored in the transaction table and blocks and stored in the blockchain table. We also re-write our Account function to create public and private keys that are stored outside of the application. We export the keys and store them in the filling system, where we can import them as we need to sign and confirm transactions. At this point, each node as one set of private and public key-pairs that is stored in the node itself.

In this lecture we start by going through the existing Flask application end-points. We create new endpoints to help us communicate with the blockchain: (1) A route to test that the transactions we have in our transaction pool are valid - all the signatures match the data, (2) Create a route to display and get the chain from database, (3) create a route to call the - genesis block creation function and (4) one last route to mine a block. At this stage we should mention that we are not creating these routes to manage or run the blockchain from them - but to call functions that we need to - test the functions and see what is happening with our blockchain data for now.

We introduce ZMQ - the library we will be using to create out Peer to Peer network. This is where we will upgrade from a typical one node blockchain to multi-node distributed ledger. ZMQ will enable nodes to communicate on a peer to peer network where data can be shared, through broadcasts and subscriptions. I share the ZMQ website and documentation, and explain how we are going to use it for our application and creating the peer to peer network. Ultimately we want to be able to manage the same dataset - between all connected nodes, without the need to trust each other. Every node can confirm transactions and confirm the chain.

In this lecture we introduce the concept of a publisher / broadcaster in a peer to peer network. A publisher creates a port where any nodes can listen in to broadcasts on the network. We also discuss the subscriber who listens in on the broadcast ports like a radio station waiting for data. In our case, all our nodes are both publishers and subscribers. They publish data, but also listen for data published by peer nodes. We discuss the functions that will be required for the Peer2Peer network - these include: (1) adding nodes to the network, (2) subscribing to a peer - for both transaction and chain broadcasts, (3) binding nodes for broadcast - for both transactions and the chain, and finally (4) broadcasting data in to the network - both transactions and the chain.

We add more Peer2Peer functions, we start by client functions that will be called from the flask end-point. When a new nodes wants to connect to the network - they will make a post request on an end-point, we start by writing the code for this end-point and discuss what must happen when a new node joins the network. This new node needs to be added to the database - then the current node must subscribe to this new node and send the new node information regarding other connected nodes.

In this lecture we write the function to create the blockchain connection from the connecting node. This function will call the flask endpoint, but we need to create the logic of how this connection is made and differentiate between the alpha node and rest of the nodes. We will also write the function to manage blockchain mining, when there is enough transactions in the transaction pool - the mining proof-of-work must execute automatically. Remove all system functions from endpoints and write them in to individual functions.

In this lecture we write broadcast transaction function - we need to write the logic of what happens when a node receives a broadcasted transaction. We will write the code for the steps associated with receiving transaction data, processing it, verifying the transactions and adding them to the transaction pool.

We will write the code for the logic to process the data a node receives when a chain has been broadcast. When we receive a new chain we need to: (1) check if the chain is valid and if it is longer than our chain - that signals that that node doing the broadcast has mined a new block and is informing the network by broadcasting its latest chain. T

We continue in this lecture writing the function and logic of receiving a chain broadcast. We look in to - what to do with our chain when we receive a longer chain that has more data than we have. How can we make sure that the chain is correct and integrate it with our own.

In this lecture we introduce the concept of threading - with all the functions we have written - they cannot all run on the same thread. We need some of the functions to run in parallel - for example, the function awaiting a broadcast, needs to run on a continuous so not to lose any data. The function mining the chain also needs to be running continuously - therefore we create threads to run these functions simultaneously.