Creating a simple cryptocurrency: part 6

The repository now includes changes to server.js. There are two new objects, kp (key pair) and cr (coordinator), discussed below.

The kp object (key pair)

Servers are identified by their public keys; their IPv4 address and port may change. Their secret keys are used to sign outgoing data. So each server needs a key pair, generated from a seed, even if it has no account. But it may have an account and this may be desirable so that clients can be assured that servers have a stake in the success of the currency.

kp creates a random seed and saves it to disk if one does not already exist in the current directory. It then logs the public key.

The cr object (coordinator)

Our scheme is to rotate the status of alpha server among a predetermined set of servers. cr does this. Every cr.serverInterval minutes (currently two minutes), a new server becomes alpha, which allows it to accept incoming transactions until cr.blackout seconds (currently 15 seconds) before the two minute interval ends. The two minute interval is synchronized to universal time, so that it starts and ends on exactly an even-numbered minute, UTC. The alpha period starts on even-numbered minutes, but lasts only one minute, 45 seconds.

The blackout period is necessary to prevent a single transaction from being processed by one alpha server, then the next. Each server accepts transactions with timestamps up to five seconds early or late, to allow for variations in client clocks relative to the alpha server's clock and network delays. If there is no blackout period, then a single transaction could be sent to the first server within five seconds of the end of the two minute window and then sent to the next server within five seconds of the start of the next, since the next server doesn't yet have the first server's stored transactions and so cannot check whether the transaction has already been accepted.

This design choice may be somewhat inconvenient for clients, but significantly simplifies the design. And we have already decided that although transactions may occasionally disappear, clients will know if they do only a short time later. But to avoid disappearing transactions, clients should keep track of universal time so as to avoid blackouts and to know which is the current alpha server.

Looking ahead, our intention is for the alpha server to broadcast its stored transactions, along with a hash of the updated balance database, soon after its alpha status ends and long before the next server's alpha status ends, so that the next alpha server has time to update its own balance database before processing new incoming transactions. So we designate the former alpha server as the beta server until the next alpha server becomes the next beta server in its turn. The beta period lasts two full minutes.

Suppose there are three servers, server 1, server 2 and server 3. This table shows how the alpha and beta designations change with time, a full rotation taking six minutes:

Before testing, modify the cr.servers array to contain the public keys of your test servers.

Testing

The reader can test this scheme by starting two servers in two different directories, using two different ports and two different console windows. Then, in a third console window, start pay.js in some client directory that has a seed file, specifying a payment to any chosen payee, and sending the transaction to the current alpha server port. In the future, pay.js will be upgraded to client.js, which will automatically know when and where to send transactions. As explained before, the transaction will be processed only if the server balance database includes an account for this client.

At this stage of development, the balance databases of the two servers will go out of synchronization unless care is taken to send each transaction twice, once to each server when it becomes the alpha server.

< part 5 | part 7 >