Ledgers

In order to learn about our protocol, we must first talk about ledgers. A ledger is a document (such as a book or other piece of paper) where financial transactions are recorded. The first known ledger dates back to ancient Mesopotamia, where it was used to record livestock, grain, and other commodities.

 

In the medieval era, ledgers were used to keep track of land ownership, debts, and other financial transactions. Today, ledgers are still used for these purposes, as well as to record stock ownership, investments, and other financial assets.

blockchain

The next step in the evolution of ledgers came with the creation of Bitcoin, the first decentralized cryptocurrency. Bitcoin was first described in a whitepaper in 2008 by an anonymous person or group of people known as Satoshi Nakamoto. Blockchain is a public digital ledger which is both distributed and decentralized.

In this context, distributed means that the ledger is duplicated across a network of computers. Because there are many computers, if one (or more) fails, the network can still remain online.

 

Each computer in the network has a copy of the ledger and the entire history of all the transactions that have ever been made. When a new transaction is made, it is broadcast to the network and each computer verifies the transaction. Once it is verified, it is added to the ledger.

Fig a. Each computer retains an exact copy of the same ledger.

A distributed ledger alone is not enough for blockchain. Most of the web services you are familiar with are already on distributed systems. If the distributed system is controlled by a central authority, it is what we refer to as centralized.
 

The central server(s) which host the ledger are controlled by a single individual or organization. If they want to change something on the ledger, they can. This requires you to entirely trust the single centralized authority which owns the server to provide you with accurate information.

client

client

client

central server

client

Fig b. A central server controlled by a single authority sends it's data to users (clients). 

A decentralized system is a distributed network of computers, each of which is controlled by a different person or organization. There is no single point of failure, and no central authority who alone can make changes to the ledger. This makes decentralized systems much more secure and transparent. 

Server A

Server B

Server C

Server X

Server Y

Server Z

Fig c. A network of computers, each controlled by a different person or organization, all share the same ledger. 

Cryptography is used to verify the authenticity of transactions on a blockchain. A digital signature is created for each transaction using a private key, which is then verified against it's paired public key. This ensures that only the owner of the private key can create a valid signature for a transaction.
 

A blockchain then uses hashes to verify the history of its blocks. When a block is created, a hash is generated based on the contents of the block. This hash acts a unique, verifiable "signature" of the block. The hash is then added to the next block, creating a chain of hashes linked together. If anyone tries to change a block, the hash of that block will no longer match the hashes of the subsequent blocks. Their proposed blockchain will be invalid, and rejected by the network.

A DIRTY Consensus

Blockchains are great, but building one is much easier said than done. How do you actually achieve a unified agreement between all participants? That unified agreement is called consensus, and the method in which any particular blockchain solves this problem is it's consensus protocol.

 

Bitcoin uses Proof of Work. This requires nodes on a network to provide evidence that they have expended computational power (i.e. work) in order to achieve consensus in a decentralized manner. A malicious actor would need control of 51% of the network to alter the blockchain, which would be impossibly expensive to do. While this does indeed keep the blockchain flowing, it comes at significant cost. In 2021, Bitcoin alone was estimated to have consumed about 67TWh of electricity, emitting approximately 57 million tons of CO2. 

It's easy to gloss over big numbers. 67 Terawatt hours of electricity... 57 million tons of CO2... What does that mean? Its a lot... right?

The average US house consumes about 11,000 Kwh of electricity per year. Bitcoin's 67 Twh could power every household in Nevada, New Mexico, Kentucky, Alaska, Montana, Wyoming, Maine, and West Virginia, combined.


One square kilometer of forest will sequester about 500 tons of CO2 per year. Scaling that to Bitcoin's carbon footprint, we're talking 114,000 Km², or 28 million acres of trees required to sequester Bitcoin's carbon emissions in 2021. 28 million acres is approximately 67% the area of our home state of Florida, or the size of Switzerland, Belgium, and the Netherlands combined. It's also about how much forest humans cut down every 2 years. 

All that, just to reach consensus on 7 transactions per second. What a gross waste of resources.

A different Consensus

Good news! There is an easier way. Lantah uses a federated Byzantine agreement system. This particular method was first implemented by Stellar and described by David Mazières in a 2015 whitepaper. In this section, we'll cover some of the details on how it works.

 

First, what is a Byzantine agreement system? In a way, a consensus protocol (an agreement system) can be viewed as a solution to the infamous "Byzantine General's Problem". Imagine a number of generals are attacking a fortress and must decide as a group only whether to attack or retreat. Some generals may prefer to attack, while others prefer to retreat. The important thing is that all generals agree on a common decision, for a halfhearted attack by a few generals would be worse than either a coordinated attack or a coordinated retreat.


The problem is complicated by the presence of treacherous generals who may not only cast a vote for a suboptimal strategy, they may do so selectively. For instance, if nine generals are voting, four of whom support attacking while four others are in favor of retreat, the ninth general may send a vote of retreat to those generals in favor of retreat, and a vote of attack to the rest. Those who received a retreat vote from the ninth general will retreat, while the rest will attack (which may not go well for the attackers). The problem is complicated further by the generals being physically separated and having to send their votes via messengers who may fail to deliver votes or may forge false votes. We need a way to know both the vote outcome and that it is true.

If all generals attack in coordination, the battle is won.
If two generals falsely declare that they intend to attack, but instead retreat, the battle is lost.

Fig d. Demonstration of the Byzantine General's Problem

The Lantah Network utilizes a Federated Byzantine Fault Tolerant system to solve this problem. Each validator chooses a list of other validators they trust (Quorum Set), and compare validity of transactions with to form a Quorum Slice. These Quorum Slices overlap throughout the entire network to form a Quorum. When a certain percentage of the network agrees, each Quorum Slice comparing against different Quorum Sets, one can determine with a certain mathematical precision whether or not any particular transaction actually happened or not.

Fig e. Individual nodes chose quorum sets to form a quorum slice. Quorum slices of different nodes overlap to form a network-wide quorum, achieving consensus among all nodes.

Anyone can run a validator and any validator can participate in consensus if any other validator adds them to their slice. As more validators are added to the network, more quorum slices overlap, adding to the decentralization of the network. Because there is no mining involved, just message passing and voting, consensus can be achieved very rapidly on consumer-grade hardware.

Centralized vs decentralized