pokt-network
Increasing Validator Security through Delegation and Other Ideas
Please explain the goal of the RFP.
The goal of this proposal is to increase validator security through validator delegation, similiar to CosmosHub delegators or Nano representatives. This allows servicers to delegate their POKT staked to be reflected in a single validator's voting power.
I'd imagine this is not the only solution to this particular problem, and I'm opening the floor for this GH issue to be the starting point on how to make solve this problem feasibly in the right time frame.
Please provide a justification for your RFP.
Once upon a time, our validator set was composed of thousands of diverse validators until PIP-7, which caused servicers and validators to split, resulting in only the top 1000 nodes (ranked by POKT staked) as guardians of the network. From my understanding, this was due to a magnitude of factors such as a limitation to block sizes, poor consensus gossipping, and general overhead when it comes to consensus. Certainly so, I do believe this was the right decision at the time of the project.
However, this also caused a side effect of how much it costs to perform an attack on the network. The network, before PIP-7, indicated that all servicers were participants of the network when it comes to security. However, that significantly changed once PIP-7 was approved. Today (9/23/2022), with PIP-7, we only have 67M tokens (66,795,682 POKT) protecting the network, whereas it could've been 670M POKT (673,820,721) if it was not for network restrictions.
Furthermore, there are a couple more important points on why a better system is needed.
- A true, trustless decentralized network should not rely strictly on game theory to ensure that the network is secure.
- More competition in the space means there is more incentive to see POKT fail
- Servicers have more at stake than validators in general. It is a bit odd and not in good health that only a small portion of actors in the network gets to be the sole deciders. Delegation allows for a more fair system while also not introducing much overhead to the network.
- Without true network security, this causes other side effects with proposals such as TransferStake. There are scenarios where i.e a single large node provider can instantly take control of the network if TransferStake is approved. Though, in defense of TransferStake, this is also a weak point, as the large node provider can unstake, and restake and overtake the network within one block as well.
Implementation:
- On a high level, in a similar fashion to CosmosHub, servicers can delegate to any validator at any given time. As a suggestion, there should not be a waiting period before you can delegate to another provider. It is socialized amongst the community to select validators that they believe are trustworthy and good actors in the network
- Slashing penalty is also split amongst delegators if the validator is not behaving properly, incentizing the network to shift to properly good behaving valdiators
- Block proposing rewards is also split amongst delegators. (The DAO is still responsible for deciding the proposer amount, but I would suggest that this amount is high enough to incentivize validators and delegators, but low enough to prevent de-incentizing servicers). It is very interesting as in Nano - representatives/"validators" are not rewarded at all. It is food for thought, but everyone who is a validator already has incentive to perform since they are also servicers. Token economics experts should dig into deeper what the optimal amount is or whether there should be a reward in the first place.
Please provide a success criteria for proposals responding to this RFP.
- Overhead of implementation is kept minimal for engineering workload viability. I believe one good engineer is all that is needed for a trivial implementation
- Increasing the number of tokens required to make validators go byzantine to prevent a 34% chain halt / 67% attack.
V1 will solve this all. In order for V1 to ever be a thing, V0 needs to stay well protected and alive. Plus, the engineering bandwidth required is pretty reasonable IMO.
Add additional context regarding this RFP.
- I have considered that this will introduce elevated block storage and slightly more validator processing power overhead when it comes to processing. But both should be minimal by leveraging caches, pruning and LeanPOKT. I think in general, POKT nodes are generally overprovisioned anyway.
- This in theory can be very minimal engineering overhead and only introduce one additional field to the node struct. We can introduce a new transaction or leverage an existing stake transaction.
- There are alternatives we can do such as increasing validator count or raising PIP-22 stake bins. However, the amount increased by both proposals is still marginal in comparison to delegation due to given how many tokens are at stake via servicers.
This issue has been mentioned on Pocket Network Forum. There might be relevant details there:
https://forum.pokt.network/t/pip-24-transferstake/3359/43
This issue has been mentioned on Pocket Network Forum. There might be relevant details there:
https://forum.pokt.network/t/revisiting-the-dao-structure/3402/18