Covers: Quality, Security, Reliability, Compliance, Insurance, Hardware/Software, and Economics
In proof-of-stake (PoS) consensus mechanisms, consensus is achieved by requiring users to stake any amount (in some cases in addition to a security deposit) of native tokens in order to have a chance to be selected as the block validator and receive a reward (known as staking reward). The block validator is chosen in a deterministic way based on how much is staked and the design of the protocol. Two common validator selection methods are Coin Age and Randomized Block Selection. Coin Age Selection depends on how long the tokens have been staked for, and Randomized Block Selection chooses validators based on low hash rates and high stakes. The stake or security deposit is collateral for the validator to behave non-maliciously, as they would lose their stake and potential rewards from creating future blocks. Unlike in proof-of-work (PoW) consensus mechanisms, validators (miners in PoW systems) receive transaction fees as rewards as opposed to block rewards where new cryptocurrency is created (in the Bitcoin network this is currently 12.5 bitcoin per block mined) as the total amount of tokens are typically created at launch for PoS systems. Inflation can occur in PoS systems but is not common. There are also punishments for acting maliciously, such as being slashed (in the Cosmos network) or losing their staked tokens. Therefore it can be expensive (in lost token value) to cheat the system.
Anyone who holds the blockchain’s native tokens can become a validator in some way, as each protocol approaches PoS consensus differently. For example in Delegated PoS (DPoS), a token holder can delegate their stake to a validator that pools tokens to create a larger stake and increase the odds of being chosen as the next block creator. The staking reward for creating this block is then distributed to those that contributed to the staking pool. Some protocols were designed to limit the number of validators, and therefore is a DPoS-like system: as long as you have more tokens than the smallest validator you have a chance to create the next block. And in some cases, you simply need to have a minimum amount of the native token to become a validator. All of these and more will be discussed further in sections below.
Quality of Validators
PoS validators come in varying shapes, sizes, and quality. For chains with more complex staking and validating protocols, strict standards are implemented such as: little to no downtown, hardware requirements, software protections, etc. Protocols designed to allow any native token holder to become a validator might have looser requirements: a simple internet connected device can be used to stake and validate. Compliance standards taken from the cybersecurity and SaS realm are being taken very seriously, and noncompliant validators (for systems in which you can delegate your tokens to a validator) have the potential to get slashed.
Characteristics of Quality Validators
- What is the average downtime vs. uptime of the validator in question?
- How many blocks have been missed (and how many are allowed to be missed)?
- Is there an uninterrupted, redundant power supply?
- Are there multiple validators running in tandem or readily available for backup should one go down?
While there are no compliance standards in place yet, validators should aim to become SOC 2 compliant in the future. SOC 2 is an auditing procedure (performed by a third party) that provides information about controls related to 5 principles:
- Security: refers to protection of the system against unauthorized access, such as: system abuse, theft of physical or digital assets (data), improper use of system, or improper disclosure of information.
- Availability: refers to accessibility of the system, products, or services. This includes things like network monitoring and procedures to handle failure incidents.
- Processing Integrity: refers to whether or not the system achieves its purpose in a complete, valid, accurate, timely, and authorized manner. This does not imply there is data integrity, as that is out of the scope of SOC auditing but should be monitored by the company.
- Confidentiality: refers to data remaining accessible only by authorized parties and controls being put in place to ensure this, such as encryption, network firewalls, and application firewalls.
- Privacy: refers to the system’s collection, use, storage, disclosure, and disposal of personal information in alignment with the company’s privacy notice as well as industry standard practices.
There are two types of SOC 2 reporting, with Type 2 being the ultimate goal:
- SOC 2 Type 1: Evaluates and reports on the design of the system and controls at a point in time
- SOC 2 Type 2: Evaluates and reports on the design of the system and controls and their operational effectiveness over time
For example: when a validator implements new controls, hardware, software, etc. they can publish a new Type 1 report, and at the end of a determined time period (for example at the end of each month) the validator can publish a Type 2 report that details it’s progress and achievements over time.
Validators have more incentive to maintain the network than they do to try to game it. However, should something happen to their network (like a natural disaster, apocalypse, etc.) the validator should have insurance to protect their staked tokens.
Hardware and Software Architecture:
- Types of Machines Required to Run Network
- Hardware Security Module (HSM)
- Monitoring, Reporting and Alerting Management Solutions
Not only are characteristics like down time, blocks missed, and honesty important reputation indicators, things like community and project engagement are also important. For example, did the validator participate in any test net and contribute to the advancement of the project? Does the validator engage with it’s delegates and act in their benefit? What is their voting track record like? A quality validator will have a reputation for project engagement and advancement.
Reporting to/Paying Out Delegates:
- How often does the validator engage with its delegates?
- How often does the validator send out reports to its delegates?
- How often does the validator pay out block rewards, and is it an automatic process or must the delegates manually request them?
Security of Validators: Risks and Mitigation Strategies
In PoS systems, security risks can take a few forms: physical, digital, and operational. Below is a list of common threats to the security and operational effectiveness of validators and some ways to weaken or mitigate them.
- Code and Infrastructure Security:
- Validator architecture diagrams: draw out physical and virtual architecture and determine potential threat vectors, then identify ways to fend off threats
- DoS Strategy, including automated incident remediation: Host-based and network-based intrusion detection or prevention tooling: using the validator architecture diagrams, outline ways to detect physical and virtual intrusion prevention
- Continuous integration and delivery: set up an automated and manual way to build, package, and run updates to the code base
- Code testability and automated testing: set a schedule to test the code base through static/dynamic analysis
- Postmortems for bugs, faults, failures
- Operational Security:
- Security policy to govern organization and collaborators: determine standard operating procedures the validator and it’s collaborators should follow to ensure operational security, including setting privacy and authentication controls
- Physical security plan to protect devices used to build validator and the validator itself: determine standard operating procedure for ensuring security of components used to build the validator (for example, purchasing from a variety of sources) and then security of the validator when it becomes active
- Password policy: determine authentication practices to reduce risk of auth-based attacks, including utilizing a multi-factor authentication process for all involved in the validator operations, including segmenting access into security clearance zones
- Centralized logging on production and organization level: create and maintain the authenticity of a log to ensure traceability in case an adverse event takes place, this includes who gained access and when to physical assets, services, and third parties
- Asset management: determine who has access to key assets such as the physical validator, staked tokens, and keys
- Take inventory: hosts, services, data, hardware components, software components, cryptographic frameworks, third party services
- Ensuring third party security: conduct a security assessment of all third party service providers used by the validator
- Auditing security practices: go through a third party ato audit security protocols to identify any gaps
- Business Continuity Plan that outlines what will happen to both the organization and the node in the case of an adverse event or disaster
- Reputation Threats
- Bad inside actor: what will the validator do in the event of an insider (employee, contractor, vendor, etc.) becoming a bad actor
- Reputation management: what will the validator do to manage their external reputation
Economics of Validators
Profitability of validators depends on their costs, network transaction fees, commission rates, and price of the staked tokens.
- Capital Expenditures: include items such as bandwidth, CPU, memory, initial fees to set up and house physical and digital network. These expenditures can vary depending on desired security level, if multiple validators will be running in tandem for redundancy, where the validators are running, and how many locations will house the validators.
- Operating Expenditures: include items such as electricity, data center fees, salaries, software and hardware updates. These expenditures also vary depending on the factors listed above.
- Transaction Fees: these are typically low enough that a validator cannot become profitable simply by creating new blocks.
- Commission Rates: these are set by each individual validator and delegates should be comfortable with the rate of their chosen validator. Lower commission rates mean lower profit for the validator, but high commission rates could turn potential delegates away.
Below is an example calculation of the profitability of two Cosmos Validators that are ranked in the top 10 and around the middle of the 100 active validators. Rank, staked Atoms, and commission rate were pulled from multiple validator tracking websites, atom price was pulled from Coin Market Cap, and staking yields were pulled from stakingrewards.com.
The amount of staked Atoms is multiplied by the annual staking yield (13.08%) to produce how many Atoms per year the validator is awarded. This value is then multiplied by the validators commission rate to determine the amount of Atoms kept by the validator each year after paying out it’s delegates. Finally, this value is multiplied by the price of an Atom to determine how profitable the validator is.
Certus One (as of 11/18/2019):
|Rank (out of 100):||6|
|Current Price of Atom||$3.52|
|Atoms per Year Awarded to Validator:||977,333.80|
|Atoms per Year Held by the Validator:||122,166.72|
|Annual Profit of Validator:||$430,026.87|
|Monthly Profit of Validator:||$35,835.57|
Mythos (as of 11/18/2019):
|Rank (out of 100):||50|
|Current Price of Atom||$3.52|
|Atoms per Year Awarded to Validator:||100,749.35|
|Atoms per Year Held by the Validator:||15,112.40|
|Annual Profit of Validator:||$53,195.65|
|Monthly Profit of Validator:||$4,432.97|
Validators of the Future: Looking Ahead
With many blockchain networks upgrading or being developed to use PoS consensus mechanisms, large exchanges offering custody and staking services for PoS based tokens, and large institutional money coming into the crypto space the market for validators can be expected to grow significantly in the coming years. For example, Ethereum has long stated that it wants to transition to a PoS network for it’s increased network security and lower energy consumption. The goal is to create a system where security is not derived from external resources (electricity and computing power) but rather the value stored within the system itself.
Though many projects will implement PoS consensus mechanisms, each will be designed differently in regards to who can become a validator and what the requirements are. In all PoS networks holding and staking some of the native token is required, but the amount varies by network. Hardware and software requirements also vary greatly depending on the design of the consensus mechanism. For instance it is relatively easy to become a baker (validator) in the Tezos network: all you need is 10,000 XTZ tokens, a computer, and the latest version of the BakeChain software. For comparison, in the Terra stablecoin network has a set of staked “miners” that LUNA holders can delegate their tokens to. In the Cosmos network, there will ever only be 300 validators (increasing from 100 each year until 300 is reached) but validators will be punished if they miss more blocks or voting periods than permitted. In this case it is imperative to have appropriate software and hardware to ensure as little downtime as possible.
In many cases it is advantageous for an individual to stake their tokens with a large validator pool because there is an access issue: unless an individual has enough capital to acquire enough of the native tokens or hardware/software, they will not have enough of a stake or meet the minimum requirements to be profitable from validating. There is a valid concern that the commoditization of validators will push these networks away from their decentralized roots. However, many of these systems were designed to use the validators to not only create new blocks but also vote on upgrades and changes to the network. If an individual does not like the voting record of their validator, they can delegate to a different one that better aligns with their morals and ideas for the network.
Thanks to Kelly McCoy for helping me write this.
Check out out scoring rubric on how we evaluate validators.