An 1-million TPS real-time Bitcoin

How it works, and what is the tradeoff.

Notes:

The tradeoffs

  • Centralization: This network is centralized by a group of a few tens of entities with plenty of resources. That is, large corporations. This system is run by a consortium between Google, Amazon, Facebook, etc. If you can trust a public consensus between them (for this, I do), you’re good to go;
  • Equipment ($): Each company will have to spend millions of dollars to build and run their nodes. Each company would have to maintain several servers that have each something to the order of 1 Petabyte of RAM (the system can start off with less, e.g. 1 TB, and grow it over time with usage).

Why would they do it?

The existence of this platform would give them control of something with huge potential, and open up a ton of possibilities for them as users of the technology they are enabling.

Each company can set different sorts of cryptocurrency fees for processing transactions, but I believe they would just collect minimal fees (necessary to avoid free spam) and redistribute them in grants to the same sorts of entities they already give grants to.

In what is it better than Bitcoin?

It actually implements transparent transfer of value on the Internet (e.g. for reusable Hashcash — great for throttling all sorts of real-world services). It is scalable (1M TPS easily achievable) and confirmations are instant (i.e. it is “real-time”).

Real-time (instant confirmations)

The overall architecture of the commercial Internet deeply favors client-server applications, which are already favored by developers by being much simpler to implement and fit for almost all practical distributed applications. This mirrored client-server system is fast, scalable, reliable and still relatively simple. The client software is trivial, and can be embedded in any application and implemented in any language very quickly. Yes, mobile, embedded (“IoT”), etc. It’s client-server!

To operate this cryptocurrency, you (or a small process on a simple device) interface with a chosen server (a public node operated by one of those companies). You ask for something to happen with a tiny transaction message, they reply with a tiny message saying it will be done, and you’re good to go. You can’t really be any faster than this, unless you centralize the currency at a single entity (which can also be done — that’s what governments are, by the way — but is not the best idea simply because we can do exponentially better with a relatively small consortium).

If you don’t want to trust a single server (for example, for non-routine, large transactions), then you can wait until the “block” (simulation step) the transaction put in is processed by all of the servers. You query all servers (so you send e.g. 20 tiny queries out instead of one) to check all of them are in agreement, and then you’re good. The whole process could take a few minutes. If the server implementation is good, it could take a few seconds.

Scalable (throw all transactions and all accounts you want at it)

The ledger is kept in RAM. An account entry takes 80 bytes in Java, and if you do it in C++, it can be brought down to 40 (or something like that). Assuming I’m off, let’s say 128 bytes. If so, allocating 1TB of RAM for the ledger allows you to store 8 billion accounts. Bitcoin peaked at 700,000. 1 PB RAM machines (which large companies can afford) can store 1,000 accounts per person alive.

Persistence is implemented by Prevayler or a similar strategy. That’s what I’m using to run the democratic.money pilot. The Prevayler tech is almost 20 years old and it just works great.

Synchronization between the ledgers is done by conservative (lockstep) simulation with zero look-ahead. This is a simple, traditional algorithm. Conflicts — including handling non-voting (silent, crashed) replicas — are resolved by voting, wherein a quorum of over 50% of voters is put in effect. The system continues to work as long as over half of the sites are on-line.

The core simulator servers run by each company can have an internal layer of fault-tolerance and be replicated. Similarly, the core servers can be surrounded by a number of witness (read-only) servers which can then be used to serve read-only queries from clients directly or indirectly.

Final thoughts

That’s pretty much it. If the large tech corporations got together, they could provide us an amazing system to play with.

If it is implemented with a fixed token supply, which is actually the simplest and probably only way this can be done, I’m sure it would replace Bitcoin and all others in the “currency” application department for 95%+ of users.

With minimal fuss it can support “multisig.” And if someone is motivated by that, variations of this system can be thought of that provide “smart contracts.” But I haven’t gone far in researching that direction.

The code is very easy to do, and they have the money to put in it, which is a tiny investment compared to the benefits. I’m not sure why this is not happening right now. Then again, I don’t understand corporatism.