Problem Statement:

Digital transactions and cryptocurrencies have been a hot topic lately. People prefer to use digital transactions due to their simplicity and they choose cryptos because they provide a sense of safety and anonymity that regular currencies cannot. While the latter are not bounded by a government or a country, their success relies on the distributed nature of their platforms. The technology behind them is known as blockchain, a chain of information blocks where we store all the transactions that have taken place since the start of the system. The amount of transactions stored on a block depends on the type of  blockchain  and the  information  can  be  provided to every member of the system (public blockchain) or to a few members of it (permissioned blockchain) .  In this project we  shall  implement  a  simplified  version  of  a  blockchain  system  that'll  help  us understand how cryptocurrency transactions work. For this scenario, we will have three nodes  on the  blockchain where  each  stores  a group of transactions. These will be represented by backend servers. While in the blockchain the transaction protocol deals with updating the digital wallet of each user, for this project we will have a main server in charge  of  running  the  calculations  and  updating  the  wallets  for  each  user.  Each transaction reported in the blockchain will include, in the following order, the transaction number, sender, receiver and amount being transferred.

In this project, you will implement a simplified version of a blockchain service called Alichain, where two clients issue a request for finding their current amount of alicoins in their account, transfer them to another client and provide a file statement with all the transactions  in  order. These requests will be sent to a Central Server which in turn interacts with three other backend servers for pulling information and data processing.

The Main server will connect to servers A, B and C, which have a group of transactions that  are  not  in  order.  When  required,  the  main  server  has to  pull the transaction

information from each backend server to find out the current wallet balance of the user, to transfer money from one user to another and to write back a file statement with all the transactions  and  store  it  on  the  Main  server.  The  steps  and  explanation  of each operation that will be required for the blockchain platform is provided in each phase of the project.

Figure 1. Illustration of the network

Server A has access to a file named block1.txt, server B has access to a file named block2.txt and server C has access to a file named block3.txt . Both clients and   the   main   server   communicate   over   a   TCP   connection   while   the communication between main server and the Back-Servers A, B & C is over a UDP connection. This setup is illustrated in Figure 1.

Source Code Files

Your  implementation should include the source code files described below, for each component of the system.

1. ServerM:  You  must  name  your code file: serverM.c or serverM.cc or serverM.cpp (all  small  letters  except  ‘M’).  Also  you  must  include  the corresponding header file (if you have one; it is not mandatory) serverM.h (all small letters except ‘M’).

2. Back-Server A, B and C: You must use one of these names for this piece of code: server#.c or server#.cc or server#.cpp (all small letters except  for #). Also you must include the corresponding header file (if you have one; it is not mandatory). server#.h (all small letters, except for #). The “#” character  must  be  replaced  by the  server  identifier  (i.e. A  or  B  or  C), depending on the server it corresponds to. Note: You are not allowed to use one executable for all four servers (i.e. a “fork” based implementation).

3. ClientA: The name of this piece of code must be clientA.c or clientA.cc or clientA.cpp (all small letters) and the header file (if you have one; it is not mandatory) must be called clientA.h (all small letters).

4. ClientB: The code file for the monitor must be called clientB.c or clientB.cc or clientB.cpp (all small letters) and the header file (if you have one; it is not

mandatory) must be called clientB.h (all small letters).

Application workflow phase Description:

Phase 1: (30 points)

Establish the connections between the Clients and Main Server

All four server programs (Main Server, Backend ServerA, Backend ServerB and             Backend ServerC) boot up in this phase. While booting up, the servers must display a   boot message on the terminal. The format of the boot message for each server is given in the onscreen messages tables at the later part of the document. As the boot               message indicates, each server must listen on the appropriate port information for         incoming packets/connections.

Once the server programs have booted up, two client programs should run. Each client displays a boot message as indicated in the onscreen messages table. Note that each  client code takes an input argument from the command line that specifies the                 username(s).

Note: Once started, the main server and the three backend servers should always be running (unless stopped manually). The clients can terminate their connections with the main  server  once  they  receive the  response for the  operation they  had  requested (checking balance or performing a transaction) .

For the first two phases the client can perform two kinds of request operations, namely   “CHECK WALLET”, “TXCOINS” (transfer coins). Which operation is performed depends on the number of input arguments that the code takes from the command line:

Operation1: CHECK WALLET

In this operation, the input argument should be the client’s own name and it will be used to fetch the client’s balance in the wallet, which will be described in the next section.       The format for running each client code in this operation is:

The command for the client A should be

./clientA 

The command for the client B should be

./clientB 

The usernames from the ClientA and ClientB are the inputs for getting the balance of  each of their wallets. As an example, to check client A's wallet balance, the command should be run as follows:

./clientA Martin

Operation2: TXCOINS

In this operation, There will be three input arguments, namely the client name of the      transfer out, the client name of the transfer in, and the number of transfers. The main     server will complete and record this transaction according to the input arguments, more details will be described in the next section. The format for running each client code in   this operation is:

The command for the client A should be

./clientA   

The command for the client B should be

./clientB   

The usernames from the Clients are the inputs for transferring coins from one user to  another. As an example, to transfer 100 alicoins from client A to client B should be run as follows

./clientA Martin Luke 100

After booting up, the ClientA and ClientB establish TCP connections with the server.       After successfully establishing the connections, the two clients first send the usernames to Server C. Once these are sent, each client should print a message in the format         given in the table 8 & 9. This ends Phase 1 and we now proceed to Phase 2.

Phase 2: (40 points)

Phase 2A: Main  Server connects to  backend  servers  and  proceeds to  retrieve the information.

In Phase 1, you read what should be sent from ClientA and ClientB to server M (main    server) over the TCP connections. For Phase 2, Server M will send messages to the      three back-servers (Server A, Server B and Server C) with UDP connections. The          request will be sent to their respective back-end server depending on which information they need to get and which operation they need to execute.

Every member of the platform received 1000 alicoins as incentive to join this blockchain. On table 1 we can see the format of each row in the block files stored at the backend servers.

Operation1: CHECK WALLET

For this operation the main server will use the input username provided on phase 1 and check if the username is found on the transaction records while communicating with the backend servers. If the username is not found the main server will provide a message    as indicated below on the On-screen messages portion of the document. If the               username exists we will calculate the amount the username has on Alichain.

Operation2: TXCOINS

For this operation the main server will use the input username1 , username2 and amount provided on phase 1 and check if both usernames can be found on the records  while communicating with the backend servers. If any of the usernames is not found the main server will provide a message as indicated below on the On-screen messages       portion of the document. If both usernames exist, we will add the transaction to any of    the block files that are located in the backend servers.

Phase 2B: Main Server computes the operation and replies to the client.

Once the  connection  server  (or the  main  server) receives the relevant data for the desired operation from the other three servers (namely serverA, serverB and serverC), it  will  perform  the  required  computation  and  send  the  results  to  the  clients.  The computation performed by the main server depends on the service requested by the clients (i.e, CHECK WALLET or TXCOINS)

Operation1: CHECK WALLET

In this operation, the main server would be receiving only those transaction logs from each of the three backend servers (serverA, serverB and serverC) in which the client was  involved.  There  can  be  multiple  transaction  logs  related to  a  particular client distributed randomly across the three log files. Each backend server would be handling it’s own log file.

Based on the log data (mentioned above) received, the main server will compute the current balance of the client based on the following formula :

= +   ∑ −   ∑

As  already  mentioned  in  phase  2A, initially all the members would be having  1000 alicoins. So, ‘Initial Balance’ for everyone would be 1000.

After computing the current balance for a client, the main server will send this info to that respective client.

Operation2: TXCOINS

In this operation, the main server would notify the client about the transaction status. The transaction  can  either  be  successful  or  unsuccessful.  In  either case, the main server should notify the client about the status.

The transaction  can  be  unsuccessful  mainly  because of two reasons. The first one being  insufficient  current  balance  of the  sender. Transactions  can  also fail  if either sender or recipient (or both) is not part of the network.

If the transaction is feasible (both the sender and the receiver are part of the network and the sender’s balance is equal to or more than what he/she is intending to send), the main server would perform the following computations:

●   The main server would figure out what should be the serial number of the current transaction.  Every  transaction  would  have  a  serial  number which  should  be assigned   in  a  contiguous  fashion  as  they  occur.  In  the  log  files,  these transactions would not be arranged in some specific order of their serial number as the transaction log data is randomly distributed across three log databases handled by the three backend servers (serverA, serverB and serverC) separately. So, if the last transaction had a serial number ‘n’, then the current transaction should have the serial number of ‘n+1’.

●   The main server would then generate the log entry (which would be similar to the the other logs):

●   The  main  server  then  randomly  selects  any  of  the  three  backend  servers (serverA, serverB and serverC) and sends this log entry to the selected server.

The server which receives this log information records this log information as a new entry in its log database and sends a confirmation message to the main server.

●   Upon  receiving  the  confirmation,  the  main  server  enquiries  for  the  updated balance of the sender and sends the transaction status along with the updated balance (current balance after this transaction) to the sender client.

Phase 3: (30 points)

In phases 1 and 2 we have described two operations that required us to do            calculations to check each user’s account balance and also to add transactions to the blockchain. For phase 3, we will add one more operation named TXLIST

Operation3: TXLIST

For this operation the client will send a keyword to indicate that the client is asking to  get the full text version of all the transactions that have been taking place in Alichain    and save it on a file named ”alichain.txt” located on the main server. The format of the operation will be as follows:

./clientA TXLIST  or  ./clientB TXLIST

Either client should be able to handle this operation. When the client runs this operation, main server will receive this request and connect to the backend servers to gather all      the information from the transactions. Main server will sort the list of transactions and      generate the “alichain.txt” file with all the transactions made up to that point (including     any new transactions made from the moment we booted up the servers). Students will    have the freedom to choose any algorithm they prefer for this sorting operation.

Phase 4: (10 points extra, not mandatory)

If you want to earn 10 extra points, you can implement an extra operation where either client provides a statistical result with a summary of all the transactions and provides a list of all the users the client has made transactions with usernameA. This operation     cannot be done separately, i.e, it should be on the same command line “ ./clientA stats” . For example, for username Ali when running the command:

./clientA Ali stats