Creating a simple cryptocurrency: part 12
The latest repository.
The wt object (WebTorrent)
If every member of a Scryp community was a server, the project would be almost complete (except for a convenient user interface). In a practical situation, only a few members are servers and the rest are clients. Clients could send payments, but they couldn't monitor the servers to see if their payments are processed.
The servers could operate an HTTP server which responds to requests from clients, but for large communities the request load could be large enough to interfere with essential server processing. This task could be offloaded to dedicated HTTP servers; the servers would only need to update these adjunct servers and let them handle the request load and archival storage, for that matter.
But instead, we make the design choice to use another breakthrough technology: WebTorrent, a version of Bittorrent that can run in some browsers but can also run as a node.js program. WebTorrent makes use of Bittorrent's Mainline DHT, but cannot share files directly with Bittorrent peers, only WebTorrent peers. We already use the same bittorrent-dht NPM package that WebTorrent uses, so it is straightforward to add a new wt object; they even use the same port, UDP for the DHT and TCP for WebTorrent. Our server is now invoked from the command line with:
$ server.js [torrentPort [serverPort]]
with the default ports being 6881 and 6882. WebTorrent and DHT work better if the torrentPort is forwarded by your router, along with serverPort.
For the reasons discussed in part 11, it is necessary to copy the $HOME/node_modules/webtorrent directory to the node_modules directory in the directory where you keep your server.js file, after first installing it in the $HOME directory: npm install webtorrent.
Our servers now create a torrent of the balances database and seed it. The infohash of the torrent is stored in the DHT along with the hash of the current database and a few recent infohashes. Clients only need to retrieve the infohashes from the DHT, knowing the public keys of the servers.
This scheme distributes sharing of the database among all connected clients. Since most clients will not be continuously connected, the community may operate some special clients continuously just for the purpose of reducing the load on the servers.
Now that our basic design is complete, we can summarize the main design features:
- There is no block chain of transactions, only a database of all account balances.
- A small (odd) number of servers are trusted to maintain the integrity of the database.
- A failure of a minority of the servers can be tolerated.
- Decentralization is enhanced by the use of WebTorrent and the Mainline DHT (dynamic hash table)
- All code is Javascript/Node.js, which is mostly platform independent and even can be run in some browsers.
Testing
A new file client.js has been added to the repository to help with testing the WebTorrent distribution of the balances database. It simply downloads a torrent from the WebTorrent network, specified by a 20-digit hex-string infohash given on the command line:
$ client.js infohash
The hex-string can also be a concatenation of serveral infohashes, in which case only the last (most recent) is downloaded. The current version of server.js logs to the console the hex-string retrieved from the DHT every minute, for each other server. Just use this hex-string as the argument to client.js, run in any directory, then check the downloaded balances file with the linux utility od.
The .keys file
The public keys of the servers are no longer hard-coded into server.js. They have been moved to the file .keys, a text file with 64-digit hex-string public keys separated by single newline characters.