EarthBucks Transaction State Machine, Part 1: Instant Transactions Globally

Bitcoin is the canonical cryptocurrency and has proved the concept of electronic cash is possible. However, it is not without issues, and one of the biggest issues is that transactions are not known to be confirmed until at least ten minutes, if not an hour, after they are broadcast. Is there a better way?

The EarthBucks Transaction State Machine

EarthBucks solves the instant transaction problem by assigning a domain name to each mine and then polling all mines to ask if a transaction is valid, and relying on a majority of mining power to determine consensus.

The software that does this is called the “transaction state machine.” This software takes every received transaction through several states:

1. “received”: The transaction has been received and has been parsed, but not validated.
2. “validated”: The transaction has been validated, but it may be a double spend.
3. “voted”: The transaction has been voted on by the mining network and determined not to be a double spend.
4. “merkled”: The transaction has been included in the current working Merkle tree of the mine.
5. “synchronized”: The Merkle proof of this transaction has been synchronized to all mines.
6. “block”: The transaction has been included in a block.

If any error occurs along the way, the transaction goes into a final error state:

7. “error”: The transaction is invalid.

In this article, I will focus on the first three states: “received,” “validated,” and “voted.”

The “received” State

When a transaction is received from the network, it is parsed, and assuming it parses (meaning it is not corrupt or nonsensical), it is immediately stored in the transactions table. This table has an autoincrementing ID. That is, every transaction has a number that records its order of arrival.

Every mine records all transactions in a slightly different order. For instance, a mine in Japan will see a delay of approximately 70ms for a transaction from New York. That is the length of time it takes light to travel from one side of the planet to the other.

The blockchain records the order of all transactions. However, each block records the order as seen by a particular mine. Every mine sees all transactions in a slightly different order.

This matters for two reasons:

1. If there is a double spend, the first transaction is valid, but not the second transaction.
2. Every new valid transaction defines a Merkle tree unique to each mine. By sending the Merkle proof, or even just the order number, for each transaction to every mine, the Merkle tree can be reconstructed on every mine, saving the need to send the entire block when it is found.

The “validated” State

After a transaction is received, it needs to be validated. The order has already been established, so validation consists of two stages:

1. Make sure it is technically valid by running all the scripts and other validation checks.
2. Make sure there is no double spend, i.e., that this is the first transaction to spend all the previously unspent outputs.

If an error occurs, such as the transaction being invalid or a double spend, the transaction is moved into the “error” state and ignored unless a mine asks about it.

The “voted” State

This state has no precedent in Bitcoin. Because EarthBucks assigns a domain name to every mine, and all mines are in contact with all other mines, it is possible to vote on the validity of a transaction. By polling all the mines, assuming all mines agree that a transaction is valid, which is the case under normal circumstances, then the user will have 100% certainty that their transaction will be included in an upcoming block. This is what allows instant transactions.

This doesn’t work in Bitcoin because there is no way to identify and therefore poll the mines to ask them if they believe a transaction is valid. In fact, it’s worse than that, because a “Replace By Fee” mechanism was added to Bitcoin that allows the creator of a transaction to replace the transaction before it is confirmed by paying a higher fee, making instant transactions impossible.

On EarthBucks, if the user double spends their transaction, then the mines will not have 100% agreement, and the transaction will not show up as “valid” until some sort of outcome is decided. The precise outcome depends on how the transaction is invalid. Assuming it is a double spend, then the double spend will be detected by at least one mine, and then sent to all other mines. Whichever transaction is valid will depend on which transaction actually gets into a block. So, in the case of a double spend, transactions are not instant. But there is no legitimate reason to create a double spend, so this does not impact ordinary users who are not trying to cheat the system.

Conclusion

This covers the first three states of the EarthBucks transaction state machine. In a nutshell, it is possible to enable instant transactions by first giving a domain name to every mine, making them queryable, and then polling them all about the validity of a given transaction.

In the next article, I will cover the “merkled” state, which is the state where the mine has put the transaction into the Merkle tree, and the “synchronized” state, where the Merkle proof has been sent to all other mines. This is the mechanism that allows instant block propagation in EarthBucks.