When Intercoin begun architecting its ledger, we started with the premise that it must be fast and scalable in order to handle everyday payments. That required challenging the prevailing architecture of the day, including Bitcoin, Ethereum, Ripple, etc. which all relied on monolithic blockchains and consensus about every transaction in the world. This approach doesn’t scale to handle everyday payments, and if the open source permissionless crypto world doesn’t get its act together, then handling payments will belong to Facebook, Amazon, Telegram etc. Even their own creators acknowledge this:
Vitalik Buterin: Using Ethereum is expensive, and its blockchain is ‘almost full’
He also said blockchain’s ‘problem’ is that every computer verifies every transaction
So we quickly settled on two specific imperatives for Intercoin’s technical design:
- Each coin would be non-divisible (unlike Bitcoin’s UTXOs or Ethereum balances)
- Each coin’s ownership would be watched by a subset of the network
There can be optional enhancements in various directions, of course. For example, ownership of a coin could be completely end-to-end encrypted, where only the last owner would be able to verify they own the coin, while the nodes on the network would only care about the hash of its states. Or, the coin could actually be a chatroom, or some other group activity that evolves through time, with transactions being chats or collaborations on a document. So Intercoin can be generalized to a platform of InterActivities. But here we will ignore all those possible enhancements and just talk about the core. What can we know and prove about Intercoin’s consensus mechanism?
The Current Intercoin Consensus Process
You can imagine each coin in the Intercoin network (whether a local community coin, or a global one) as a file that is stored on the BitTorrent network. Kademlia was described in 2002 and was first used in Vuze and BitTorrent around 2005, predating Bitcoin. By contrast, the current top cryptocurrencies rely on monolithic blockchains that need to obtain a global consensus about every transaction in the world, a slow and expensive process. In addition, every full node has to store the entire history of every transaction. In BitTorrent terms, that would be similar to every computer seeding every single file and movie on the network – this is overkill.
On the Intercoin network, each coin is non-divisible, and is watched by 10-30 notaries, a subset of the network, that is selected by a routing process such as Kademlia Distributed Hash Table or a global routing table with tokens being generated provably random numbers.
For example, the MaidSAFE network uses this approach. A mathematical paper from 2009 establishes mathematical upper bounds for the probability that these smaller consensus groups can be subverted. It turns out that there are quickly diminishing returns from adding more than 10-30 notaries to a group, so you can achieve great security with just a few notaries watching the consensus.
When a transaction is signed by the coin’s current owner(s), it submitted to the Intercoin network, which routes it to be watched by one or more of the notaries watching the coin. The notaries’ job is not to make sure the transaction is valid – that falls to the owners of the coin. The notaries simply:
- Check that the transaction T was signed by the latest owner(s) of the coin
- Check whether they to date received any conflicting transaction about this coin
- Gossip T along with conflicting transactions, if any, in one shot to the other (N–1) notaries watching this coin
- If a supermajority of the N notaries in this small consensus have reported receiving a valid T without conflicting transactions, then record an approval and transmit to the coin sender, for final endorsement
- The sending user endorses the transaction (along with, possibly, the recipient) and posts it to the notaries, who record it in an immutable ledger (optionally secured by the entire network in a scalable way)
The supermajority in part 4 is supposed to contain a majority of honest notaries, allowing for some dishonest notaries to be present in the consensus. For example, to allow 60% dishonest notaries, we need more than 50 + 60/2 = 80 notaries to report in.
Notably, this allows more dishonesty than, Bitcoin (51% attack) or most others, like Hashgraph, which fall apart if more than 33% of the notaries are dishonest. With Proof of Work or Proof of Stake blockchains, the entire history can be entirely replaced by a different history and the entire network may become corrupted as long as an attacker controls 51% of the hashing power (or voting power). That’s why it was not suitable for our model (with small consensus groups), or indeed, for any small crypto-currencies for communities, of the type Intercoin is supposed to power.
By contrast, Intercoin has small consensus groups where the number of nodes is well known (and permissioned automatically by the “elder notaries” in the group), so a “majority” has meaning. Because each notary has its own public key, and signs all its messages with the corresponding private key, it can’t get away with sending conflicting messages to its compatriots. If the group of notaries watching a coin is strongly connected, even a large proportion of malicious nodes of nodes can’t subvert the consensus, because they will compare notes and consider it malicious (one strike and you’re out). And checkpoints after every transaction has successfully settled prevent new notaries from rewriting history (just as they do in the Ripple Consensus Process).
Coins can become Frozen
The current problem relates to latency and availability of notaries. Although notaries can do very little to subvert a consensus, they can prevent it from completing, and thus the coin from moving. Thus your Intercoin wallet may contain coins in three possible states:
- Green – no recent issues with the notary group, coin can be sent easily
- Yellow – too many notaries unavailable or laggy, transaction will take time
- Red – the entire group of notaries has been verified to be malicious
The vast majority of the coins would be green. Sometimes, when the network is netsplit, or you are running Intercoin in some basement with no Internet connectivity, the coins will be yellow. Most merchants would accept yellow coins for small amounts (e.g. grocery shopping) and wait for them to become green. However, red coins need to be migrated by the network to a new group of notaries.
The reason for #5 above (endorsement of original sender / recipient) is in case they want to retry some stalled transactions by using other coins. This way, they will cancel the original transactions by simply never approving them. It’s like taking out a different credit card when one is declined or the processor is unreachable.
Can we make a scalable, usable payment network that works quickly 99% of the time and still have it secure even when we have a small group of notaries, watching a small group of coins? Can we avoid needing to strictly order transaction, by simply rejecting both conflicting transactions? This is the question I’d like to explore in this thread. In the past I discussed and debated about it with David Schwartz of Ripple, who said it can power payments but perhaps not smart contracts. I also discussed it with the MaidSAFE team on their forum. Vitalik also proposed similar things in 2018 … namely, having nodes actively watching the consensus. (Of course, in his formulation, the consensus is about the entire network).
Can we do better?
Well, this is what I want to discuss. I am going to make a new thread about it. Feel free to comment in this one if it has to do with Intercoin’s current architecture that is slated for 1.0 (described here). Does it need any assumptions on synchronization vs async? These impossibility results suggest we can’t do better with 100% certainty, but perhaps we can make a network that works amazingly 99% of the time.
Update: I just started a discussion about Experimental Improvements for Intercoin’s Consensus – you can comment there.