This is not a traditional CIP, but could be seen as follow up to original CIP. The intent of this post is two-fold:
- At urgent effect, to prevent directly IOG from modifying protocol parameters without acknowledging the limitations and justifying the actions behind updating protocol parameters.
- In longer term, form a process around modifications to protocol parameters - since we do not know when (not in terms of life cycle, but in terms of timeline) protocol parameters submitted solely by BFT will move away.
Currently, there are limitations around adjustments to nOpt
and a0
values as below (there have been some losely held communications before about increasing nOpt
to 1000):
-
nOpt:
We have seen from previous increase from 150 to 500 that it is easily worked around by increasing number of pools run by a single entity. This does not even enforce additional infrastructure. While on paper, the increase makes it seem that decentralisation is increasing, in reality, it is actually enforcing those who do not want to split their pools to potentially incur losses (unless they reduce their desirability by increasing fees). The onus/assumption is made that delegators will be informed enough and make decisions in best care of network (thereby, the value), while the drive solely (as to be expected) is based on brand visibility and ROI. There was a very sane and good article recently published by Prof Aggelos which perfectly captures the right concerns and perspective from research for which protocol was based upon. The protocol cannot take into account the problem with identity (which is acknowledging difficult) , but that does not mean we should enforce those who do not intend to split incur losses - while those who see no issues with splitting simply workaround the nOpt limitations. As such beyond a blog or a model calculation which does not actually take into account social behaviour, it feels very wrong to simply continue heading towards increase to 1000 without really being able to address or enforce leverage factor as indicated in aforementioned article. -
a0:
While this was originally thought to be a good counter action against increase ofnOpt
, it was quickly obvious that increase in a0 - while good for honest majority, is easily used as an advertisement, as well as advocation forPledge as a Service
operations. The attraction of high ROI to a decent stake holder not only undermines the trust requirement between operator and co-owner of a pool (mainly due to social dynamics of humans involved), but also enhances avenues and possibilities for scam operations to increase within the project. Thus, there is a very negative social impact to be considered with increase of this parameter. -
Pre-Requisite actions for indication:
If we’re depending on delegators to actually make informed decisions, then we need the existing indicators (eg: Daedalus ranking) to start considering identity of a pool. An example of pool cluster definition that can be used is here. Currently Daedalus does not care if the desired nOpt are all actually exchange pools, if pledged fully and having half decent setup - It can rate all the exchange pools at topnOpt
pool, which on paper can still be claimed as decentralised.
Things to note:
- No, we do not have an answer to what’s the ideal parameter. Currently, the community has become increasingly knowledgeable on how to get around current parameter limitations which intend to decentralise network conversely to actually continue centralising the network instead to entities, some of which are not really operating in best interest of network or project.
- The immediate request is for IOG to submit a CIP and have a layer of approval (even if technically they control the BFT nodes and thus, the protocol decisions) as a preparation towards decentralisation, gearing towards community involvement.
- The model/calculations to include considerations for human behaviour and drill down into what honest majority assumption really means to protocol. In absence of such a model/calculation (which is obviously no where close to easy), to not rush into an action.
- Have actions in place to encourage the best practices beforehand, a very good guidance here instead simply moving ahead without any real visibility or opportunity to onboard feedback (no, opaque online forms do NOT count).
- The change from current protocol parameters, is not initiated by community - it is initiated by IOG. Thus, the expectation is for them to create a proposal first and get some feedback. In absence of any such proposal (from community in future or from IOG at present), it would be wrong to proceed making a decision for the protocol that it cannot recover from , from governance point of view.
Note that the intent of this post is not to call out any behaviour, but ask IOG to start walking the path that they expect the community to follow in the future.