Creating a simple cryptocurrency: part 5

server.js

The Part 5 repository now has a preliminary version of server.js, incorporating recv.js and adding new functionality.

The opportunity has been taken to fully establish the convention that all code besides the require statements be organized into objects with two-letter names. Two new objects tx (transactions) and bl (balances) are discussed below. As mentioned before, this convention encapsulates related code such that the only global variables are the objects and the required modules. The use of this is avoided except in the string-methods module.

The tx object (transactions)

Incoming transactions are processed in this object by the function tx.store, which stores valid transactions in the buffer tx.txsfor future use then passes them to bl.update. Storing them in memory (and not in a file) is efficient but of course limits their number and implies that they are expendable. The future intention is to clear the buffer after sending them to non-alpha servers near the end of the consensus time frame. A permanent record of transactions may be kept by clients.

Incoming transactions must pass three validation tests:

1. They must be timestamped within +/- tx.offset (+/- 5 seconds) of the current time
2. The signature must be verified
3. The transaction must not already be in the tx.txs buffer

The bl object (balances)

Valid transactions are passed to this object, where they are processed by bl.update, updating the balance database on disk. Instead of using an npm database module, for now we use the file system because it is simple and adequate for our needs. Our database is a directory named balpopulated with files containing account balances and named with account ids. Both the ids and balances are hex strings for convenience, 64 and 8 hex-digits long respectively. For example, one file in the bal directory might be named

0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

and contain

00000abc

The bl object performs these checks and actions:

1. The payer account must have a sufficient balance to make the payment including a transaction fee bl.txFee
2. The fee is deducted from the payer's balance
3. If the payee is also the payer, the transaction is nullified, but the fee is charged
4. If the transaction results in a zero balance for the payer, the payer account is deleted
5. The balance database is updated with the payer's (if non-zero) and payee's new balances

The transaction fee

The transaction fee is necessary to penalize frivolous transactions. It is currently set to one unit of the currency.

The fee is deducted from the payer's balance but not added to any other client's balance and therefore the total coin supply slowly deflates with use.

Testing

The reader may test server.js by starting it in some directory and then sending a payment to it with pay.js, started in a directory with a seed file. server.js will create an empty bal subdirectory in its directory but since there are no accounts initially, it will not be able to process the payment. However, it will display the incoming transaction like so:

2017-06-13 15:55:43 UTC tx: valid tx #1 received from => f5367deb65d536b9b944d3574c5d926e6a28ea69b0d3a5afab211513b19e60a9

Now that you have the payer's account id in hex string form, you can create a new file inside the bal directory with the id as its name and, for instance, ffffffff as its content. Resend the payment and notice that this time the payer's balance is updated and a new payee account is created containing the payment.

< part 4 | part 6 >