Dissecting IIP-1: The first IoTeX Improvement Proposal
What's an IIP?
IIP stands for IoTeX Improvement Proposal. An IIP is a design document providing information to the IoTeX community, or describing a new feature for IoTeX or its processes or environment. The IIP should provide a concise technical specification of the feature and a rationale for the feature.
IIPs are intended to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into IoTeX. The IIP author is responsible for building consensus within the community and documenting dissenting opinions.
Because the IIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. Anyone can submit an IIP, not just team members, nor just developers — anyone!
IIP Types
There are three kinds of IIP:
- A Standards Track IIP describes any change that affects most or all IoTeX implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using IoTeX.
- An Informational IIP describes an IoTeX design issue, or provides general guidelines or information to the IoTeX community, but does not propose a new feature. Informational IIPs do not necessarily represent an IoTeX community consensus or recommendation, so users and implementers are free to ignore Informational IIPs or follow their advice.
- A Process IIP describes a process surrounding IoTeX, or proposes a change to (or an event in) a process. Process IIPs are like Standards Track IIPs but apply to areas other than the IoTeX protocol itself. They may propose an implementation, but not to IoTeX’s codebase. They often require community consensus but, unlike Informational IIPs, they are more than recommendations and users are not typically free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in IoTeX development. Any meta-IIP is also considered a Process IIP.
IIP Lifecycle
The IIP lifecycle looks something like the diagram below, and contains the following stages:
- Draft: an IIP that is open for consideration.
- Accepted: an IIP that is planned for immediate adoption.
- Final: an IIP that has been adopted previously.
- Deferred: an IIP that is not being considered for immediate adoption. May be reconsidered in the future.
- Closed: an IIP that is no longer considered for adoption.
- Obsolete: an IIP that was accepted but has now been superceded
Ok, enough, what’s IIP-1 !?
IIP: 1
Title: Improving slashing policy enforced on underperforming delegates
Author: Zhijie Shen (zhijie@iotex.io)
Status: Draft
Type: Standards Track
Created: 2019-05-20IIP-1 tackles the issue of delegate performance and rewards incentives, namely, the slashing policy on IoTeX. Slashing in simple terms refers to the possibility of stake/vote destruction for not following protocol rules. There are different approaches taken to slashing by the various DPOS projects in operation today — the table below outlines some current approaches.
Currently on IoTeX, slashing occurs as a penalty for poor delegate performance and rule-breaking — when delegate performance drops below the required threshold in any given epoch, their epoch bonus rewards are not given to them. At < 1000 IOTX per epoch this is a rather small price to pay, so talk has started on whether a formal slashing policy should be put in place with greater consequences.
The proposed change
IIP-1 proposes that when a delegate misses the 85% productivity threshold (aka misses 3+ out of 15 blocks) it will:
- be excluded from the consensus delegate pool for the next 3 epochs and
- Miss all rewards during these 3 epochs (block reward + epoch bonuses)
Additionally, the X+1-th delegate, where X is the number of consensus delegates, will be moved into consensus delegate pool, and have the chance to be rolled as the active consensus delegate. 3 epochs were proposed because it seems to be a reasonable enough time for a responsive delegate to recover the node. However, this number could be debatable.
Does the change have support?
Raullen Chai, IoTeX co-founder and core developer took to Twitter to have a quick and easy check of whether IIP-1 or increased slashing in general had support among the community — of those engaged enough to vote on the poll, the answer was a resounding yes! Including from us. 100% of voters agreed that IIP-1 is a good idea. In the near future, when the Grand Design of IoTeX is realised, such voting will occur on the ‘Gravity Chain’, which is the designated name for the governance chain on IoTeX. Voters will be able to proxy their votes to the delegates who will then vote on whether or not the IIP should be proposed.
Potential IIP-1 amendments
While IIP-1 is comprehensive and already technically sound, if I were to suggest any edits it would likely involve:
- The number of epochs for rewards to be slashed
- A penalty for repeat offenders
- Whether voters should also be penalised for voting for inefficient delegates, rather than just validators
- Different slashing policy for different offences
Tackling repeat offenders
Delegates who are regularly slashed in a close period should be removed from the consensus delegate pool for an extended amount of time. This would prevent nodes from being down for too long in instances where a delegate is unavailable to solve their hardware problem. For example if a node is removed for just 3 epochs (roughly 3 hours), but after those 3 hours is elected again and subsequently slashed again, it is a reasonable assumption to assume they are not available to solve the issue, and should be perhaps taken out for a longer period (e.g. 24 epochs / 1 day).
Sharing the blame
As can be seen in table 1, different PoS projects make different choices about who takes the ‘risk’ when delegates are not performing well. In IoTeX the validator takes the blame, but in Cosmos and Ethereum, the voters are also penalised. This approach takes advantage of the fact that it will make voters more proactive with their votes and ensure that their delegate is one who is consistently performant, while it can be considered harsh because voters have no influence on the day-to-day operations of a delegate’s hardware set-up.
Although harsh, I believe this approach is better because stricter conditions will lead to a more efficient network. Voters could have, for example, ≤0.1% of their stake (not votes, stake) burned per epoch for each epoch where they have voted for a slashed delegate. This also has the bonus effect of reducing the total supply of IOTX, which could have positive effects on the supply-demand curve.
Not all slashes shall be created equal
In comparison to malicious acting, under-performance is a fairly tame sin. Having one slashing policy for under-performance and another for malicious acts could act as an improvement on IIP-1, where malicious actors incur far greater slashing penalties than the under-performers — what exactly those penalties are would have to be a topic of discussion.
In Summary
In this first instalment of Dissecting IoTeX, we explore the very first IoTeX Improvement Protocol, IIP-1, submitted by Zhijie Shen.
We reviewed what IIPs are, how they’re submitted, who can submit them, and why we should. We then delved into the specifics of IIP-1 and proposed some additional improvements and potential amendments. The status of IIP-1 at the time of writing is Draft, which means it’s open to amendments and suggestions from the community.
Most implications are at a technical level and the expected impact is low to most stakeholders, though delegates will have greater incentive to take responsibility for their node’s performance, and, in case my suggestion of also slashing voters is acted upon, voters will need to be more mindful of who they vote for and how their votes affect network efficiency. I will keep an eye on IIP-1 as it goes through the IIP life cycle and update all readers on any interesting changes or progress as it happens.
This article was written by the founder of iotxplorer, a proud IoTeX delegate.
Website | Twitter | Telegram |Medium | IoTeX Delegate Profile | About
