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 of nOpt , it was quickly obvious that increase in a0 - while good for honest majority, is easily used as an advertisement, as well as advocation for Pledge 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 top nOpt 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.
If people follow that article from Aggelos, then only the biggest bag holders will run pools, and people should only delegate to the most well pledged pools. There are contradictions in the article.
The little guys will stay little and the big guys will get bigger.
Little vs big is not the topic of the thread (and not the intention either), let’s keep it away from favourite SPO debates and stick to what thread is for, viz , have an approval layer and proper research material for change of protocol parameters before applying because we are in transitional praos era where only IOG can make changes. The deficiencies of specific parameters are more of a defect against specs. The last line in original post was intentionally added anticipating such replies
But you instead propose to ignore the rules of behavior shared by a majority that supports decentralization, and create a pool farm (8 pools and counting) with only K=500.
Anggelo’s guide has a very important background, and you know it. PoS is not just about creating a protocol that handles all aspects of consensus. It’s the Cardano constitution. And upon it must rule many human actions that revolve around that protocol for the network to be healthy.
Tell me one thing. If we all did what you are doing, what would be the result? Because the race to the bottom is just as valid as the race in splitting pools. 50 entities max?
For me and many of us, it costs nothing to create dozens of pools, based on an economy of scale that would destroy decentralization.
I also don’t see you giving any importance to leverage. But it has just as important a substance as pledge. Look at this numbers:
The total number of blocks created by the entire hispanic community represents 70% of the total of blocks created by a single entity (DIGI).
This single entity is 1.4x more influential than the entire hispanic community combined, but having 5x less pledge.
In other words, you are using the consensus power of your delegators to acquire more dominant position in the ecosystem. This so-called leverage should be taken into account in your business planning scheme.
The start of post clarifies what are the two intents. The original intention suggested by IOG small regular step increases from 150, and that was the last real protocol parameter update where we had a notification and justification beforehand. Since then , we have only had a high-level - not systematic - blogs and none about the actual numbers used for updates.
Again, it’s not proving one or the other wrong (or getting into never ending small pools vs big pools or morales vs business view debates), but asking for an approval layer with justifications for existing limitations discovered as per first step increase and adapting learnings before directly applying changes.
My 2 cents: Removing the concept of pool identity makes sense to me. If users were presented with “option 1, 2, n” instead of “1pct, 1pct2, bloom” then we would at least help removing brand identity which makes people stick with pools run by the same entity/person.
That would be more effective especially before we reach k=1000 when delegators will be forced to reallocate their stake and leave saturated pools.
In complete agreement with the essence of this post, to propose and establish an approval layer on changes to the protocol. As said, we’re in Praos transition and changes to parameters like nOpt and a0 made now will have long lasting influence, possibly negative, on the health of the network. Establishing an approval layer is the first step in fading out BFT level changes in favor of community level governance.
However I do not think the root cause is how IOHK set the parameters. They have the data scientists and are experts. Adding manual bureaucracy in a pre-voltaire world could cause more issues. I agree completely with the first bullet on publishing rationale on how parameters are set, what are the limitations and what were the justifications. A post parameter change analysis would be good too i.e. what happened after we moved nOpt to 150 to 500.
The gap here is the knowledge of delegators. The official wallets should link delegators to a page hosted by the CF with guidance on how to make good staking decisions. That way delegators can make informed decisions at the point of delegation.
This to me would be a very easy upgrade to Daedalus & Yoroi and the CF, IOHK and Emurgo can work as a team to add this in.
I would say it’s rather expecting an average trader would be interested in decentralisation, as well as clarifying what assumptions honest majority really means - because there is an expectation of what delegators will do , which seems to be contradicted by real world social dynamics.
These are genuine defects with social behaviour and expectations (hence, the referral blog from research team itself in the original post, which exemplifies what expectation was from underlying research teams). To me personally, the mentioned blog does a good job of highlighting the guidance, but unless that guidance is forced in code (not at wallet layer) - there isnt much that tweaking existing parameters can achieve. Also, long term - yes, it will be chaotic, which is all the more reason why we need to start having an approval system now, when IOG can still at the end control the outcomes, rather than doing it later directly by pushing it in the hands of community when BFT nodes no longer hold any power
Delegator education seems to be the key here. Question is how to have enough of it to influence awareness about the ecosystem and what optimal health of the network looks like and what role they play. I tell my stakeholders, not only are you improving your financial well being with the stake’s reward system, you are also a material participant in the fundamental mechanics of the blockchain. Your choice matters and it’s my job to help you understand how. That is why I sometimes promote other pools when I see that their desires and needs are better suited or that the network would benefit from it. Since I’m only 40% saturated at k=500, I obviously have room to grow for realization of the delegation design spec per section 5.6.1 “Pool Desirability and Ranking” whereas:
"We predict that pools with rank ≤ k will eventually be saturated, whereas pools with rank
k will lose all members and only consist of the owner(s)"
I have seen the delegator community rise and make better choices over time. The more they understand, the more I find them making better staking choices while helping others do the same, and so on.
I find myself fantasizing about a wallet interface that elegantly encourages decentralization graphically by showing the delegator where the stake is ideally placed for optimal network health based on parameters of the protocol, delegation design spec and a playlist filter for inclusion in or support of things like Mission Driven Pools, Dev Pools,etc. The question is does the protocol actually know where the best place for that stake is or does it only care about saturating k=500 pools, ensuring immutability af 3k/f slots and maintaining probability that enforces ~5% ROS.
Some remains to be seen, some hopefully we can influence for the better. At the very least a community based approval layer that truly decentralizes the future of the blockchain.
I agree with essentially everything highlighted and am hopeful that we can convince IOG to provide justification for parameter changes. I’m a bit less optimistic that we will be able to convince IOG to relinquish its power anytime soon and provide a path for the ecosystem to submit CIPs which would be voted on by the community rather than decided by IOG. I’m also a bit less optimistic that we will see any form of an identity system (at least one that is effective) anytime in the near term. There are a number of problems within the space (such as pool splitting) where the most obvious solution involves some form of an identity solution, but I assume that an effective dID is much more difficult to create than most people think.
From what I’ve been able to tell, IOG appears to be moving more away from “research and discuss the fundamentals” and more toward a “build fast and break things” approach, especially on the governance side of things. To me, this is partially understandable given the competition that is looming in the space and the urgency to deliver a product, however, this also means that there is a general lack of communication with the community as things are liable to change at a moments notice.
I’ve discussed what I believe are problems with the current reward function, assumptions in the underlying research, and proof of stake in general Criticisms of Proof of Stake. I’ve also put forward a suggestion for, what I believe to be, a rather substantial improvement An Alternative to a0 and k, that essentially uses a constant reward (percentage) and a variable saturation as opposed to a constant saturation and variable reward as exists with the current rewards function. To prevent hijacking the thread, anyone who is more interested in discussing network parameters, pool splitting, and the like are welcome to brainstorm solutions in the attached posts.
Interesting ideas, looking forward to seeing where those go. Looks like there is consensus around a need to monitor protocol changes submitted by IOG without a approval layer well integrated into governance.
There is much hope in this thread for enlightened self interest when the best you will get is self interest. The protocol assumes self interest, and you get a Nash equilibrium because of it… So let’s not expect something irrational.
Personally I’ve yet to be convinced that the pool distribution we see is a problem. Nor that the identity mechanics are a problem. SPO’s are motivated to brand and provide a reliable and trustworthy service.
They need to compete with the likes of Binance and multiple pools? Sure, get used to a competitive world. There is no way to stop this without a central registration authority and we see how well that works in PKI. Even if it could be done who would arbitrate and decide? How would you stop someone providing funds to another party? It’s a pipe dream, forget about it and move on.
The need for transparency on changes to protocol parameters and careful transition to governance by the community obviously makes sense and should be pursued as part of Voltaire.
k=1000 benefits the system as a whole and grows the environment. Bring it on. We want to be thinking about k=10000 before long.
Cardano has always been about formally-verified and transparent decision making based on research, and this aspect (atleast for public eyes) been lacking for the updates (in terms of number) to protocol parameters. I cannot care less about what magical numbers are decided, as in my view, things would not change much by just tweaking around existing parameters. When we have to write blog articles and hope that delegators will make an informed choice , it goes quite against the methodology.
Note that the most troublesome part of ITN networking is yet to be enabled - P2P networking. While we expect the experience to be much much smoother, there will be increased demands involved, and much more professionalism expected down the line from an average SPO as SC layer is unlocked. So no - while there is a large business/competitiveness/etc quarrels happening around, this post is not about success or competitiveness of SPOs themselves, but addressing current gaps. There are multiple other things that I do not touch in my post, knowing that it will quickly derail the conversation from the missing governance and proven research layer accumulating for what’s missing.
Note that the most troublesome part of ITN networking is yet to be enabled - P2P networking. While we expect the experience to be much much smoother, there will be increased demands involved, and much more professionalism expected down the line from an average SPO as SC layer is unlocked
Agree with all of this. And the fact that it will be harder is good.
I contend we want low barriers to entry but for it to be demanding to succeed. That leads to a highly competitive market and allows SPOs to differentiate based on uptime.
SC’s mean hardware performance and operational excellence will become increasingly important and those left standing will be true businesses.
Understand that when we start to really challenge existing finance and Wall Street we are going to have the fight of our lives. They are not going to just roll over and let us take their lunch.
So let’s start getting a bit serious ourselves.
P.S. And lets keep having some fun on the way as part of the best Crypto community there is
I totally agree and concerned on technical requirements, skillsets needed to operate nodes effectively and securely as this just by itself may pose a major risk to the health of the network after d reaches 0… this must be addressed urgently as any misstep could be quite damaging.
Node operations are a big deal as utility infrastructure will become even more critical as our ecosystem grows sustainably.
Another aspect someone brought up above is about delegation. In the short-mid term making delegators merely the driving factor may prove to not be ideal as delegator comprises a very diversified community with many different viewpoints and expectations… This is a very uneven community, we must acknowledge that. In the future delegators will get more educated, new profiles,… this process takes time.
There is no easy answer but a more inclusive and open dialogue involving multiple parties, different viewpoints are needed. Rushing up a decision is not ideal. Without jumping into conclusions, not only establishing the right framework but also finding a healthy balance between these variables may prove key: identity (anonymity), fair ranking parameters, rewards and pledge, network must not incentivize workarounds and “bad” behaviors.
March 31st is right around the corner, and undoing whatever is rushed would be troubling…
.
