The repository now includes consensus determination.
Consensus determination (continued)
In part 8, consensus could be achieved if all of the servers were started together and in sync from the start. But if one server became out of sync, it could not rejoin consensus. To rejoin, the out-of-sync server must obtain a current copy of the balance database file.
In part 9, the beta server receives hashes from the other servers and determines if there is consensus. If so, and if it agrees with consensus, it will send a copy of its own version of the database to any out-of-sync servers, which can then rejoin consensus.
At this stage of development, the servers will stop if consensus is lost. A manual restart is required, after server operators agree on which version of the database to use.
There is now an archive directory to preserve recent versions of the database, each named like so: hash.timestamp, were hash is the hash of the packed balance database contained in the file and timestamp is the unix time in seconds of the relevant consensus determination time frame.
A code byte has been added to the TCP messages between servers: zero when the payload begins with the hash of the packed balance database file and one when the payload is the packed balance database itself.
| head | head | pay-load | payload | payload |
|---|---|---|---|---|
| public key | signature of (hash of payload) | code 0 | hash of packed balance database file | transaction buffer (beta only) |
| public key | signature of (hash of payload) | code 1 | packed balance database file |
At this stage of development, a simplifying design choice has been made to store both the packed balance database and transactions received during the current consensus time frame in single buffers in memory. This choice limits the number of transactions that can be processed in a time frame and the number of distinct accounts that can be managed. Besides storing this data in memory, the transactions and (occasionally) the database must be transferred between servers during the time frame.
When the number of transactions and accounts is small, processing and transferring is very fast, so the time frame has been reduced from two minutes to one minute for convenience. Future tests will determine the practical limits on transactions and accounts, and the minimum duration of the time frame. Our hope is that the software can be kept relatively small and simple while still being able to meet the needs of local communities.
Testing
- As before, modify server.js to include three of your own server keys and ports
- Start the servers at about the same time
- Observer them exchange messages
- Stop one server and observe the other two continue to achieve consensus
- Restart the stopped server and observe it rejoin consensus (since balances haven't changed)
- Stop two servers and observe the third one self-terminate because consensus is not possible (at least two must agree)
- Restart the three servers and send the beta server some transactions
- Observe that consensus persists
- Stop one server, send transactions to the others, then restart the stopped server
- Observe that the restarted server rejoins consensus
- Observe the filenames in the
balFileArcharchive directory of the previously stopped server - Notice the temporary discrepancy with other servers and then self-correction