The Fetch.AI Minimal Agency Consensus Scheme

We’ve kept it under the radar up to now. But an integral part of the Fetch.AI vision is our technology for providing the world’s fastest, most secure and decentralised ledger. Consensus is a vital component of any ledger design. I am thus delighted to be able to announce the release of our minimal agency consensus protocol. When combined with our scalable ledger, this consensus scheme is part of our plans to overcome the blockchain trilemma.

We have been working on designing a sharded blockchain that can process a large number of transactions in each shard. By running many of these shards, we will be able to offer vast and scalable throughput. Low-cost transactions and smart contracts are key parts of our ambitions for autonomous agents.

The blockchain trilemma states that scalable blockchains cannot achieve both security and decentralisation. The idea behind our protocol is that the trilemma can be overcome by reducing the "agency" of block producers. (Block producers or nodes replicate the ledger and contribute to consensus by adding blocks to the blockchain). This means that they must behave in a very restricted way and have limited flexibility. Critically, individual nodes have little control over which transactions go into the blockchain. These features give the ledger security and performance characteristics to match centralised systems. The combination of this consensus scheme with a sharded blockchain will enable everyone to take part in the network. This will be possible without great wealth or access to expensive equipment.

Consensus design is a technical subject. So, we’ve used a Question and Answer format to explain the most important aspects of the consensus in an accessible way. Our yellow paper describes the protocol in greater detail.

Can you briefly describe your consensus mechanism?

The protocol uses a Proof-of-Stake mechanism to construct a blockchain. A core part of the consensus is a decentralised random beacon (DRB). The DRB is a cryptographic technique that computes a sequence of secure random numbers. It relies on a multi-party computation between the entire collection of nodes, which we refer to as the assembly. The value of the DRB at a particular point is used to decide which node will add the next block to chain. The key benefit of the DRB is that no individual node can interfere with (or stop) the computation of the next value.

The current random value decides which nodes will propose transaction sets for next block. The nodes communicate the transaction sets with each other using a Directed Acyclic Graph (DAG). The leader then closes the DAG, converts the transaction sets to a block and adds it to the chain. The DAG is a transient (non-permanent) data structure that is not stored indefinitely.

(a) A blockchain is a linked list of blocks. (b) In Directed Acyclic Graphs (DAGs) the blocks have more than one connection to previous blocks. The two data structures have distinct properties that are useful for different purposes. Blockchains have strict ordering, which is useful for providing rapid and secure finality. The useful property of DAGs is that they can be built asynchronously. The Fetch.AI consensus uses transient DAGs for proposing transactions but this is later converted to a blockchain.

What is the philosophy behind the consensus and how does it improve on what already exists?

The fundamental design principle is minimal agency. This means that individual nodes have little direct control over the transactions that are entered into the global state. The system achieves this by asking the assembly of nodes to submit candidate transactions. The leader then closes this candidate transaction set for the current block. After closure of the epoch, an algorithm decides which transactions will reach the global state. This algorithm is public and deterministic, and is implemented in the Fetch.AI virtual machine. Two advantages of this approach lie in resisting transaction censoring and denial-of-service attacks. This maintains security without compromising transaction throughput.

How does someone take part in the consensus?

Users can participate in the consensus by purchasing a stake and turning on their computer. In the future, the ledger will achieve high throughput by running a small number of shards on a desktop PC. The consensus is also compatible with a ledger running a larger number of shards for higher throughput. At higher throughputs, people will still be able to participate in the consensus by running a subset of the shards on their desktop.

Doesn’t Proof-of-Stake mean that the rich get richer? How do you prevent that from happening?

It’s important to keep in mind what staking means from a security perspective. This represents the cost for participating in consensus. If you sum up the costs of all participants then you have a measure of the cost for an attacker to take over the protocol. From a security point-of-view, this needs to be as high as possible. Thus, the best outcome that any secure consensus design can hope to achieve is to spread the cost out over as many people as possible. This goal is also key to achieving decentralisation. One advantage of Proof-of-Stake is that an attacker must buy a large number of tokens on the open market. We expect that this will drive the price of the token higher and lead to a much higher cost than for the existing participants. It’s possible to prevent the “rich getting richer” by ensuring that the returns and risk are the same for both smaller and larger stakeholders. Our consensus includes this and other elements that prevent centralisation of tokens.

How do you deal with a nothing-at-stake attack?

The blockchain incorporates a deterministic notion of finality. This means that, beyond a certain depth, blocks cannot be altered or replaced. If your transaction is in a block of this depth or deeper then you can be confident that it will reach the global state. In blockchain terminology it will have reached finality. Bitcoin and related blockchains have a probabilistic notion of finality. This means that you can never be completely certain that your transaction will not be revoked. Deterministic finality also limits nothing-at-stake attacks to the very recent past.

The blocks are also created collaboratively by a randomly-selected committee of nodes using a DAG. The committee can identify nodes that add multiple vertices during a single epoch. It’s possible to discourage this behaviour by fining the perpetrators. This is known as stake slashing and is one way of preventing nothing-at-stake attacks over shorter time-frames.

How does your protocol solve the scalability trilemma?

The scalability trilemma states that no ledger can be scalable, secure and decentralised. Our consensus and ledger design represent a viable solution to the scalability trilemma. The three properties and the technology used to attain them are:

• Scalability. The sharded ledger can support a high throughput of transactions.

• Decentralisation. Node operation will be open to everyone and not involve any specialised equipment.

• Security. The minimal agency design restricts the potential for attack. Transaction fees can also be levied without artificially constraining the system’s throughput.

Why do you use a decentralised random beacon (DRB)?

We use the decentralised random beacon to assign responsibilities to nodes at different times. This is an energy-efficient, secure and scalable alternative to Proof-of-Work. We anticipate that DRBs will become an industry standard in the coming years.

How does your protocol improve over others that use a DRB?

The main difference is in design philosophy. Most of the other projects use classical theories of distributed computing and cryptography. These build on the concept of an adversary who is endowed with a specific set of capabilities. The goal is then to design the system to be resistant to the specified attacker. In our case, we are still using the classical adversarial models, but we are also treating the blockchain as a multi-agent system. In this view, we treat the processing nodes as self-interested agents. Security is provided by making any deviation from the protocol costly for the participants. This is similar to how the existing economy works. Most people trust Visa with their transactions or Google with their data because it would be costly for those companies to abuse that trust. The reputation of those firms combined with their profit motive gives consumers confidence that they can be trusted. The minimal agency principle also provides protection against many other types of misconduct. These include the potential for bribery or denial-of-service attacks on processing nodes.

Your protocol incorporates a DAG. What are the advantages of your consensus scheme compared with other DAG-based ledgers?

A disadvantage of protocols based on DAGs is that transactions sometimes take a long time to reach finality. The technical term for this property is liveness. One way of resolving this problem is to use a coordinator to snapshot the DAG at different time intervals. Unfortunately, this type of ledger is under the control of the coordinator, and thus centralized. Most ledgers, based on DAGs, are unsuitable for smart contracts as they do not produce a strict ordering of transactions. In some cases, they also contain redundant information, and thereby increase storage costs. The Fetch.AI minimal agency scheme is designed to produce better liveness, scalability and more rapid transaction ordering than ledgers based solely on DAGs.

How does your protocol remove the need for a central coordinator?

The decentralised random beacon elects a committee of leaders who fulfil the same role as the central coordinator. This delivers better performance and security than semi-centralized alternatives.

How is your protocol different or better than existing scalable blockchains?

One of the key differences is that there are no technical limitations on the number of nodes that can take part in the Fetch.AI consensus. Although the number of nodes will be capped at the launch of the main-net. This is due to economic reasons and the number of nodes is set to increase as the platform grows in popularity. Many existing projects, such as EOS, Neo or Tron, can only achieve scalability if the number of nodes is small. This leads to strong centralization of those platforms. In these examples, the situation is made even worse by the node operators being able to extract very high rents through inflation. This will cause even greater centralization of wealth in the future, very much to the detriment of other users. The Fetch.AI token is non-inflationary, which protects the value of users’ holdings.

What is the difference between Fetch.AI and other AI/ML blockchain projects?

Fetch.AI is a state-of-the-art cryptocurrency project whose goal is to build the fastest, most scalable and secure ledger in the world. This differs from other AI projects whose focus is restricted to applications. Another important difference is that Fetch.AI is building a platform for multi-agent systems. This is the most appropriate scientific formalism for building blockchain applications. As a result, we have a much more general focus on blockchain technology. We’re using machine learning in the Open Economic Framework (OEF) for matching trading partners. But, the main purpose of the AI is to support deployment of multi-agent systems.

What are your future plans?

We’ll be releasing more details in the coming months. This will include academic papers, patent applications and general interest articles. We’ll also be benchmarking the consensus’ performance on the test network.

It sounds like you are making good progress on the ledger itself. How does this affect the economic platform for autonomous agents?

There is a synergy between these two elements. The Open Economic Framework (OEF) depends on the blockchain for financial exchange. The OEF provides cryptoeconomic security to the blockchain. It’s going to be exciting to further develop the connections between these two fascinating technologies.

I would like to thank David Galindo, Troels Rønnow, Marcin Abram, Jin-mann Wong, Daniel Honerkamp and other colleagues at Fetch.AI for their help in preparing the consensus document.