This document describes a path to improve ICON’s economics and core infrastructure in preparation for growing into a cross-chain hub. Without decentralized block production, high availability and an effective penalty system, it unfortunately doesn’t matter how secure the BTP protocol is.
The fact of the matter is that if ICON is not viewed as secure and sufficiently decentralized, a cross-chain protocol running on it will not be viewed as secure and decentralized either, regardless of the underlying technical design. If ICON is compromised, all integrations may also be compromised. This issue with the hub model was raised when speaking with well-researched industry participants in the cross-chain space (funds invested in cross-chain, researchers, other cross-chain solutions, etc.).
The goals below are all aligned with the messaging that ICON has implemented the most secure, decentralized and scalable cross-chain solution available. Here are 3 goals this proposal aims to achieve:
- Effective penalty system
- Rewards only for securing the network
- Decentralized block production
This section specifies the changes proposed by Lydia Labs to achieve the three aforementioned goals.
These proposed penalties are modeled off of typical Cosmos SDK slashing rules and penalties. The Cosmos ecosystem has one of the most robust ecosystems of validators supporting many different (but similar) networks.
Part of the Cosmos Hub narrative is offering interchain security (“ICS”), meaning they have put significant thought into making their core network secure and decentralized, otherwise ICS would not be valuable. Therefore, we felt modeling off of an existing and successful ecosystem while leveraging what has already been built in Goloop would be the best path forward.
We propose two types of penalties, the Validation Penalty (which already exists on ICON) and the Double-Sign Penalty. Both result in slashing and “jail”, as defined below.
Once penalized, regardless of penalty type, the validator will be removed from the validator set and jailed. When in jail, a validator does not earn any rewards. Validators will remain in jail until they successfully validate or propose another block. This means that an offline validator will not earn any rewards. This also means that an offline sub-validator will not earn any rewards until their next opportunity to produce a block, which depends primarily on the validator set size and the amount of rotating sub-validators. The replacement for a removed validator is always based on the highest power of a sub-validator.
Validation penalty occurs if a node misses 41,040 blocks (95% of blocks) in 1 term. The slashing percentage will be _% of their bond. As mentioned earlier, if a validator suffers a validation penalty it will be Jailed and not earn any rewards until it successfully validates or proposes a new block. Currently, the Validation Penalty on ICON requires multiple offenses before slashing (which is currently set to 0% anyway), making it extremely easy to profitably operate a sub-validator without actually running a node.
When a validator is found to have committed equivocation by signing two blocks at the same height, the validator will be slashed _% of their bond. Currently, there is no double-sign penalty on ICON, so this would need to be developed.
Other networks, such as Cosmos and Tezos, feature the concept of validators charging a commission or fee to voters. Block rewards are ascribed to validators, validators take a commission, then validators distribute the remaining tokens to voters. Each validator can determine their own commission rate as a manually-set parameter. Distribution will be automated based on the manually-set parameter.
This system, combined with the effective penalty system mentioned above, rewards voters only if they are securing the network. If the validator is Jailed it does not earn rewards, therefore neither do their voters, as the validator has no rewards to distribute.
Therefore, combined with an effective penalty system, voters must vote for a node that is securing the network in order to receive rewards. If a node is slashed/jailed, the node receives no rewards, which means it has no rewards to distribute, which means the voter receives no rewards. If a node doesn’t have a bond, the node doesn’t receive rewards and therefore neither do their voters.
ICON has a two second block time which enables fast finality on the network. Ideally we would like to keep it this way while achieving greater decentralization. A large set of rotating sub-validators achieves this goal.
At most, we can have ⅓ of the validator set rotating. Any more than that would risk a permanent network halt during the rotation, as the network requires ⅔+1 consensus to produce a block.
Therefore, we propose a rotation of 9 sub-validators with 19 fixed main-validators, resulting in 28 total validators per block. This was recommended by the ICONLOOP team to optimize decentralization, safety and speed. This provides decentralized block production and makes it more difficult to coordinate an attack without impacting the speed of the network. Ideally, the rotation-selection process will be randomized, but more R&D is necessary.
In order for rotating sub-validators to reliably provide security and decentralization to the network, they must be operating a node. For the network to reliably have a large set of rotating sub-validators, it must be profitable (or at least close to profitable) to operate a sub-validator.
We propose the network allocate some inflation to a minimum wage provided to the top 100 validators. Minimum wage will only be effective when combined with the penalty system outlined above. The rules of Jail apply to minimum wage, meaning offline/malicious validators would not receive minimum wage.
We would also propose a _ICX minimum bond requirement to receive the minimum wage. This further secures the minimum wage by providing a financial barrier to entry. If anybody sees a clear way to profitably abuse this system, please let us know in the comments.
We propose up to 100 nodes be eligible for minimum wage. If there are less than 100 eligible validators, minimum wage is split among the validators that are eligible. To implement this, we will use an inflation bucket similar to iVoter and other buckets.
Our initial proposal is __% of inflation be allocated to minimum wage. This results in a minimum wage of $xyz based on current ICX prices.