Agents of Anoma: Validators

There are various ways you can participate in Anoma and contribute to the ecosystem. This series, ‘agents of anoma,’ focuses on the different roles you can take on in the growing community. Follow the series to learn more about what each role entails, and why it is important to Anoma. This first component of the series, ‘Validators,’ explains the concepts that define the role, what it takes to be a validator, its importance, and how this relates to the security of the network. Additionally, learn more about what validator features can be experimented with on Anoma’s first public testnet, Feigenbaum, and how to get started.

If you are interested in joining the testnet and are looking for the docs, check out the instructions for installing and joining the Feigenbaum testnet.

Basic concepts

There are concepts in the design of public blockchain protocols that are essential to understanding the role of a validator. Note that these concepts’ terminology may vary across projects.

Decentralization

While a decentralized system is a system where there is no central authority controlling it, decentralization refers to the transfer of control from a centralized entity (this could be an individual, institution or group of people) to a distributed network. The goal of decentralization is to reduce the level of trust required between users, as well as the power one user may have over another, in a way that does not reduce network functionality.

Whereas public blockchains strive to achieve decentralization, not every blockchain is decentralized. In some cases, the organization behind the network controls who their validators are, or in other cases, the organization itself runs the nodes. Decentralization in all aspects of the blockchain, although limits scalability as it incurs an upper bound for throughput, facilitates a trustless setting, has a high fault tolerance and increases in security alongside the number of users. Additionally, many decentralized blockchains offer a level of transparency from open-sourcing their software.

Sybil resistance mechanism

A sybil resistance mechanism is a mechanism that determines the requirements for participating in consensus in a network. A sybil attack is when an entity or a node creates or operates multiple accounts at the same time to exert more influence over a system. The aim of this attack is to gain majority influence to carry out malicious actions (with respect to the rules set by the network) in the system. Sybil resistance mechanisms prevent this using different methods depending on which type it is. For example, proof-of-work as a sybil resistance mechanism requires node operators to consume electricity to solve a puzzle. This can require a heavy amount of electricity to prove the authenticity of every block, and without this, you cannot participate in creating blocks. With each identity on the network carrying out a non-arbitrary and equal amount of computational work, every sybil identity must perform as much work as every honest identity. This makes it difficult and very expensive for a single organization to control a significant percentage of them to carry out a sybil attack, but still possible as mining power can be concentrated.

Proof-of-stake (PoS)

Proof-of-stake is a sybil resistance mechanism. In other words, an algorithm used to determine who is allowed to participate in consensus. In a PoS system, validators (validating nodes) must set aside a portion of stake (resources as collateral) in order to participate in consensus, which they may automatically lose if they deviate from the protocol. What rule is implemented to determine which is the next validator that proposes the next block varies case by case.

Consensus (protocol and algorithm)

A consensus protocol is a set of rules and processes that determine how nodes reach an agreement on a single view of the world, i.e. these protocols ensure that everyone agrees on what information to add onto a blockchain, as everyone can submit information to be stored onto it. Because public blockchains aim to be decentralized, meaning that there is no centralized authority dictating what is right or wrong, consensus protocols are the predefined rules that nodes have to follow to agree on the state of the network.

A consensus algorithm is the method designed to achieve automatic agreement in the process of decision-making in a system where many nodes or peers are participating. Through the consensus algorithm, all peers in the distributed environment establish a connection among one another, and reach a common agreement about the current state of the ledger.

BFT consensus

To understand BFT consensus requires also the definitions of consensus, the Byzantine general’s problem and Byzantine fault tolerance. Consensus means that a general agreement has been reached, such as 3 out of 5 people deciding on one movie in a group of 5 friends achieving majority.

In a public network there may be nodes that actively work against reaching consensus, and it is impossible to reliably know whether nodes are providing faulty information about transactions (or other information) by accident or maliciously. Therefore, a system that is Byzantine fault tolerant is resistant, by design, to the Byzantine general’s problem (which is the condition where a system requires the agreement of all participants, but one or more choose to break the agreement, causing the system to fail), and assumes that there are malicious participants.

The Tendermint consensus algorithm is an example of Byzantine fault tolerant (BFT) consensus. It is an algorithm that securely and consistently replicates an application on many machines. A network with this algorithm works securely even if up to ⅓ of machines fail in arbitrary ways. Non-faulty machines see the same transaction log and compute the same state, ensuring that the network remains stable. The Tendermint consensus algorithm’s ability to tolerate failing machines (may it be accidental or malicious) makes it a Byzantine fault tolerant.

What is a validator?

Validators are persons or entities running nodes that participate in consensus and run block validation for one or more proof-of-stake networks. This could also be offered as a public service. These entities have a similar role to the miners in a proof-of-work blockchain: ordering transactions and creating new blocks so that all nodes can agree on the state of the network. As mentioned earlier, validators must put up stake. A certain level of knowledge about the protocol and ecosystem might contribute to helping validators operate securely, as in many networks, being a validator means participating in consensus and participating in protocol upgrade mechanisms as well. The name validator itself may vary from network to network.

Under ‘proof-of-stake,’ the stake set aside by validators can be slashed if they deviate from the protocol. This action of providing stake as a collateral is called staking or bonding. This way, validators accept the cryptoeconomic rules, including the punishment that comes with deviating from the protocol. Bonding and staking means that validators take an active role in the networks.

Delegators

While validators operate infrastructure, delegators can choose to delegate their stake to a validator. Delegators do not need to operate the nodes themselves, “delegating” their staking power to validators instead. Individuals or entities that do not wish to operate infrastructure themselves but still participate in consensus can delegate their stake to validators.

Being a validator on Anoma

Anoma is a proof-of-stake protocol that currently deploys Tendermint as a consensus algorithm, in which the next block proposer is chosen via round-robin leader election. In Anoma’s cryptoeconomics design, validators must put up stake. This stake can be lost and the validator can drop out of consensus if they deviate from the protocol, such as by double-spending or signing other invalid state transitions. By running secure infrastructure, validators on Anoma can attract delegators to stake with them (delegators) and increase their total stake.

The importance of validators on Anoma

Validators secure the network

From a security perspective, if a validator misbehaves, such as trying to create a fork, voting multiple times in consensus or performing a light client attack, the punishment system in place slashes their stake. There is an incentive for validators to not deviate from the protocol and ultimately, as value is at stake, validators are incentivised to operate secure infrastructure.

Validators provide protection against front running

Validators on Anoma are required to run the DKG protocol for front-running protection. Anoma deploys Ferveo, a cryptographic implementation that allows users to submit encrypted transactions that can only be decrypted if at least ⅔ of the validators (by staked weight) act honestly. As a result, anyone observing the mempool, where all unconfirmed but valid transactions are stored, can only see encrypted transactions, and are unable to see what is inside. When validators propose a block, they cannot favor a transaction and profit from it by having information earlier than other participants, since this information is fully encrypted. On the mainnet, likely only validators will run the DKG protocol and it is an automatic process. For more information on Ferveo see:

• The Anoma Tangram article Ferveo: A Distributed Key Generation Scheme for Front Running Protection
• Ferveo Cryptography Overview

Validator features supported on Feigenbaum

For participants looking to try out the validator role, you can run a validator node, storing a copy of the blockchain and creating new blocks on the latest testnet. The Feigenbaum testnet also supports validator-specific PoS actions, such as self-bonding, unbonding and withdrawing stake. Upon registration, validators generate a consensus key used to sign blocks in consensus following, a validator account key for signing transactions on the validator account (the PoS actions previously mentioned, and more), and another staking reward account key for signing transactions on staking reward accounts. These keys enable all validator actions, which are detailed in the user guide linked in the following section.

How to join Feigenbaum as a validator

Feigenbaum is a public, permissionless testnet open to everyone. Anyone may join by pulling the code from the Anoma repository and following the instructions in the docs.

When the installation is complete, you may begin trying out the validator role by interacting with the PoS system. We suggest registering a new validator account through the instructions in our user guide under the section for PoS validators.

If you have any questions or need assistance regarding the setup and details of running a validator node, several members from the team building Anoma will also be participating in the Feigenbaum testnet to ensure that it operates stably. Our team members are on Discord in our new #feigenbaum channel to answer any questions regarding Feigenbaum.

To stay updated on all news related to Feigenbaum and Anoma’s future testnets, we recommend signing up for our testnet newsletter.