[Community Vote] Delegate Probation - Proposal #3

larrypang · February 18, 2020, 6:32pm

Voting Results: PASSED on March 25

The proposal was passed with ~66% YES votes. See poll results for full details.

Review the full Proposal below – for any questions, you may ask in this thread or on the official IoTeX Telegram Group.

Background

There is a “nothing-at-stake” problem in proof of stake (PoS) consensus systems. Unlike proof of work (PoW) consensus, which requires computing power for mining, PoS does not require block producers to consume physical resources in order to produce and sign blocks. Therefore, it is possible for malicious block producers to attack PoS networks without any costs or risks if effective “slashing” policies are not implemented.

In developing this slashing proposal, we explored how different projects enforce their slashing policies, including what types of misbehavior (e.g., downtime, double signing) are penalized via different methods (e.g., kick out, slash stake).

IoTeX Slashing Overview

The IoTeX Network’s Delegate slashing policy will address two types of safeguards to penalize / protect against two types of negative Delegate behaviors:

Institute temporary “probation” for any unresponsiveness Delegates that are not producing blocks due to node being offline, incorrect software version, etc. This is largely due to negligence, not malicious behavior.
Slash the stake of any Delegate that double-produce or double-sign blocks (or similar behaviors). This is considered a severe attack, as it indicates purposefully malicious behavior.

Proposal #1: Probation for Unresponsive Nodes

Today, the IoTeX Foundation is sharing our proposal to address #1 above – how to manage “probation” for unresponsive Delegates that are not producing blocks.

Proposal: Any Delegate that does not achieve 85% productivity (i.e., misses 5 or more blocks) for a given epoch will be put on probation – they will be ineligible to produce blocks for the next 6 epochs and will receive greatly reduced rewards. After the probation period, the Delegate will be re-eligible to produce blocks again.
Methodology: for Delegates on probation, the protocol will enforce a 10% reduction in voting power for six epochs, which will a) effectively remove them from being selected as a block producer, and b) greatly reduce their rewards (i.e., no block rewards or foundation bonus, 10% of epoch bonus reward).
Expected Benefits: 1) Minimize impact on overall quality of service (QoS); 2) Require all Delegates to provide consistently robust infrastructure; 3) Encourage proactive resolution of node downtime issues from Delegates.

Note: the parameters of this proposal (i.e., 85% productivity, 6 epoch probation, 10% intensity rate) are designed to be somewhat flexible for Delegates as IoTeX Mainnet continues to mature. These parameters may be updated via future community votes.

Voting Process & Timeline

We welcome all IoTeX community members to discuss this proposal. Please share any questions/thoughts directly in this forum thread – we will reply to your feedback accordingly. The timeline for approving this proposal is as follows:

Week of 2/17: Community Discussion
Week of 3/9: Deploy to Testnet & Finalize Proposal
Week of 3/16: Community Voting via ioPay
By End of March: Deploy to Mainnet & Activate Proposal

Note: anyone that has staked IOTX is eligible to vote (1 IOTX = 1 vote)

LEO · February 20, 2020, 2:12pm

Voting will be in early March

JoeGoodman · February 20, 2020, 6:31pm

I agree with the measure, as it is designed to improve the quality of service of delegates.
What is designed to address the problem #2? Is it already implemented? (slashing the stake of any delegate that produces double production or double signature blocks) Or will it be addressed in future network improvements?

flyinalex · February 20, 2020, 9:35pm

This seems like a good improvement, slightly harsher penalties for bad behavior but without resorting to draconian steps. Looking forward to the vote!

Is there a place to see the statistics on the delegate history of uptime and any flags for malicious behavior? Thanks!

Lastly, additional votes gained for longer staking do not make a difference for voting purposes, correct? Only the actual number of IOTX staked counts for voting. Plz confirm.

Dorothy · February 21, 2020, 7:15pm

For the problem #2 – slash the stakes, it’ll be addressed in future network improvements, coming soon!

Dorothy · February 21, 2020, 10:23pm

For the first question, yes we are going to show the status of current malicious node and the history of delegate.
And for the second, voting power is based on actual number of IOTX and staking duration, which means that additional voting power gained for longer staking will be counted for voting too.
Thank you!

metanyx · February 22, 2020, 1:52am

Just want to clarify the language, the delegate who is slashed will not receive any block rewards or epoch bonus for 1 + 6 epochs in total? So the following 6 epochs after being slashed they will not receive any rewards correct?

worksshop · February 23, 2020, 4:56pm

Will a stakeholder re-vote be necessary if in the future the IoTeX Foundation and the IoTeX community decide to increase the minimum delegate productivity for a given epoch to more than 85%?

What types of rewards will not a delegate receive if it does not achieve 85% productivity for a given epoch? Will voters who vote for such a delegate receive their rewards? Will rewards from the kick-out delegates be redistributed among other delegates?

Will delegate productivity statistics for voters be periodically published? Or will it be available on the voting portal?

worksshop · February 23, 2020, 4:58pm

Analysis of nodes productivity over the past 3 months

Artanovskaya · February 25, 2020, 10:45pm

What about this proposal? Will there be any voting?

Dorothy · February 26, 2020, 10:31pm

The total epoch being punished is 6 epochs, from the epoch after it underperforms. Yes they won’t get any block rewards or epoch bonus.

Dorothy · February 26, 2020, 11:18pm

For the first question, yes we need to re-vote for increasing productivity threshold more than 85% because it’s going to be another hard-fork.

And about the second question, that’s a good point to clarify. Now we are giving 3 types of rewards. Regarding the block reward and foundation bonus reward, since the unproductive node won’t be included on top 36, the other delegate will back up his place. Therefore, those rewards will be given to the other. Also for the epoch reward, even though they are in top 100, because their voting power is temporarily 0, they won’t get any of it. Accordingly, it’ll be redistributed among other delegates.
As for reward distribution to voters, we are not directly distributing reward to voters, but giving it only to delegate, which means that the distribution process to voters in case of underperformance is up to delegate.

Lastly, we are planning to show the delegate productivity statistics on the voting portal to give more information to the voters.

Dorothy · February 26, 2020, 11:25pm

Yes there will be community voting for the second proposal too!

Artanovskaya · March 14, 2020, 12:15pm

I don’t quite understand what this type of slashing means. Can you explain how the Delegate falls under this type of slashing?
Thank you!

larrypang · March 26, 2020, 5:45pm

larrypang · March 26, 2020, 5:47pm

larrypang · March 26, 2020, 5:48pm

larrypang · March 26, 2020, 5:58pm

Hi @Artanovskaya – there are two types of penalties we plan to implement for Delegates:

Probation for not producing blocks: for any Delegates that are offline, they will be put on probation and not eligible to mine or receive rewards for 6 epochs. This is the purpose of this proposal that was passed.
Slashing for malicious activities: if any Delegate double produces/signs blocks, a portion of their stake will be slashed. This is considered an “attack” on the network, so the penalty is much higher. We are designing how to do this and will share a new proposal, after which there will be a community vote.

metanyx · April 4, 2020, 8:01pm

So in this respect it is preferred to have a producer go offline than risk an automatic failover where by two producers may come online at the same time if a split brain exists (your two nodes fail to communicate with each other or an arbitrator believes one is offline but really is not).

The HA design https://github.com/zjshen14/iotex-leader-election referenced here if incorrectly promoting backup to active (as one might believe active is offline from location of test) may cause double signing. A reference to this was in Cosmos https://twitter.com/zmanian/status/1145072296723275776?lang=en

It is safer for the network that promotion is manual or if implemented needs to abide by Stonith takeover.

As a self bond is 1.2 million what percentage of this self bond would be slashed for a double sign? 1.2 million is the minimum requirement what if the validator falls below this due to the double sign i assume they must top it. What are the penalties being produced for double signing?

metanyx · April 4, 2020, 8:17pm

Picking and choosing production timeframe of 3 months seems arbitrary why not from beginning of time.

0-8300 (current epoch)
iotexcore = 98.8

Metanyx
Metanyx = 100.6
(cant upload two images apparently but you can run it here https://analytics.iotexscan.io/query to verify, output
{ "data": { "delegate": { "productivity": { "production": "112792", "expectedProduction": "112140" } } } }

Suffice to say the >100 is random if you are in a round another producer is failing to produce in and if you are lucky enough to get selected to fill in for the failing one.

As per above our preferred approach is to avoid double signing, as we are running two nodes in different locations there is no way to be 100% sure to prevent both from becoming active so manual promotion is preferred. The only safe way to avoid Double Signing is to have a Stonith takeover in a single location. If the location fails then you are offline where as two servers in two different locations achieves ability to recover.