Creating a simple cryptocurrency: part 2
Decentralized consensus determination
Achieving consensus in a decentralized network is a difficult problem, especially when the network may be under attack. The solution used by Bitcoin is a revolutionary breakthrough technology. Over time, the miners with the majority of hashing power determine which transactions are included in the block chain. (Read the Bitcoin Developer Guide for technical details.) Since the appearance of Bitcoin, hundreds of competitors have appeared. Many use a variation of Bitcoin's scheme, while others use distinctly different schemes. The goal is always to prevent one entity (or a group of cooperating entities) to gain control of consensus determination.
With the advent of mining pools, hashing power became concentrated among relatively few entities. At one time, one mining pool almost had a majority of hashing power, threatening the integrity of Bitcoin. Another weakness in Bitcoin's approach is that, due to intense competition, hashing has become very expensive in terms of both hardware investment and electrical power use. The expense can only be justified if Bitcoin's price keeps rising and transaction fees keep increasing (especially considering that the block reward periodically halves), and these dynamics work against the usefulness of Bitcoin as a currency.
In a local community, where people are known to each other and have a reputation, the consensus problem can be simplified. Designate some individuals as servers. The rest of the community are designated as clients. The servers are trusted not to collude with one another, and must each agree to continuously operate a hardware server running the same version of software. Consensus is determined by a simple majority of servers.
Clients will have greater trust in servers who have a greater stake in the currency (own more of it) and who will therefore have a greater vested interest in the integrity and success of the currency. In a more complex variation of this project, we could make this a requirement, or in another variation allow all clients to vote for servers in proportion to their stake. For now, let's use the simplest variation: the servers are hard-coded into the software and can only be changed if the software is updated.
This scheme is not fully decentralized; it is rather partially decentralized. But it can be said that neither is Bitcoin fully decentralized. The degree of decentralization is a function of the number of servers. In principle, every community member could be a server, but that is impractical for large communities. Besides, in a community the quality of servers outweighs the quantity of them. And should the community desire that their cryptocurrency be backed by something like gold, such a feature is more feasible when trusted individuals are already part of the scheme, who could also act as custodians.
Compared to Bitcoin, this scheme is very efficient. Large mining operations using enormous amounts of electrical power are unnecessary and so this scheme is economical and environmentally sound.
As with Bitcoin, servers must adhere to a consensus time frame and coordinate their activities by synchronizing with universal time. But unlike Bitcoin, our consensus time frame does not randomly vary but is fixed. As long as a majority of servers are functioning properly, consensus is achieved within a short, well-defined time frame. This allows us to impose a simplifying condition that transactions reported to the servers by clients are not guaranteed to be processed, and if not processed they expire at the end of the current consensus time frame and must be resubmitted. In contrast, Bitcoin transactions can remain in limbo for days, during which time the parties involved do not know if and when their transactions will be processed.
As with Bitcoin, during any consensus time frame only one server is responsible to collect, sequence and validate transactions. With Bitcoin, this server is the winner of the hashing competition. With our scheme, this server, which we will name the alpha server, is determined by a regular rotation among the servers, synchronized to universal time. So, all clients know in advance which server to send transactions to during any given consensus time frame. The alpha server then updates account balances and reports the block of processed transactions along with a hash of the updated balances to the other servers so that they can update their own balances and compare to the hash. If the hash agrees, then they publicly report their agreement. Otherwise, they reset to the previous consensus state and discard pending transactions. The consensus state is a ledger of balances, not transactions.
In some consensus schemes, the goal is to make all of the servers appear to be one server with one definitive account ledger. Our scheme more closely resembles the scheme designed by NASA in its early days: each actuator on a spacecraft receives signals from all on-board computers and complies with the majority. Each client monitors all servers and trusts the majority consensus among them.
Perhaps the most distinguishing feature of our scheme is that transactions are not the fundamental unit of record, rather balances are. Once consensus is reached for a particular time frame, the most recent transactions are discarded, although they may be kept by clients who can continuously monitor the servers and have sufficient storage capacity.
Why this design decision? First, because it is consistent with the overriding objective of simplicity. Practically, there is no need to store an ever-growing block chain; only the balances of each account need be stored, proportional to the number of members in the community. Even if the community has millions of members, the storage and transmission requirements are manageable. And philosophically, it more closely resembles traditional currency: does your paper or metallic currency have printed or engraved on it a record of all previous holders? For this reason, I will refer to our simple cryptocurrency as scryp in honor of the stamp scrip used by the Wörgl community in 1932, with a twist in honor of cryptography.