So basically, one could run 100 pools by himself 
1 Like
If that 1 person or entity has enough ADA to fund 100 pools enough so that it can produce blocks, then yes. That’s why this needs cooperation from the delegators also. But first and foremost, there’s a lot that IOG and CF themselves can do.
CF is already making rounds distributing their delegations every 3 epochs. IOG has already promised but yet to actually do, retire (or take private) 19 of their 20 pools and possibly distribute delegations also…
Definitely understand your frustration. I think the good news is that the potential economic benefit of having a decentralized chain far outweighs the benefits of not. I do believe parameters will be adjusted to make reality meet the desired outcome.
Cardano still has a long way to go. But I still back it.
Although unfortunately especially the stake pool ranking algorithm is disappointing. Frankly it’s rubbish and needs attention, to better encourage decentralization.
As you don’t have to identify yourself to set up a pool one of the multi pool operators could also run another 100 pools under different tag names that make them look like solo operators.
In the end the parameters need to make this work even if all pool operators including IOG are out for themselves and don’t want to be nice to anyone. In the meantime, I am glad IOG have a lot of control over this as its in their interest to make this work. I am sure they know this is not perfect and things need to change but it has only been couple of months.
I would like to see the ability to pledge from a hardware wallet just like staking as I think this would encourage pool operators to pledge more.
That’s not really what’s happening, and I don’t see it happening.
Operators are openly running several pools, using the brand name they’re building to promote them. And the problem is, that is precisely the behavior that is being rewarded right now. If SPO operators are supposed to promote their pools, well, it’s natural that only a handful are successful, there’s just no way to have 500 operators successfully reaching the same target (or, for that matter, 150). Just imagine to have 500 “equally successful” search engines, auction sites, soda brands…
IMHO, if each SPO has to promote her pool, the system will inevitably tend towards concentration.
In my opinion, the system should evolve to a system where delegation could be assigned on technical merit. Where the default could be something like: change my delegation each 5 epochs to an unsaturated pool with a pledge above X, that has been running for at least 3 months, and has been online at least 99% of the time.There’s surely better metrics, but note I do not mention “producing blocks”, or pool size, to allow for new entrants, as long as they’re committed and competent.
4 Likes
I like this. I think this is something worth considering for wallet developers… especially the devs of Daedalus.
2 Likes
I don’t think that multi pool operators have set up solo pools just that they can. They are more likely to set up more than one multipool operation. How do you know for sure that SOLO AND 1PCT are not connected (not that I think they are)?
With companies you have the monopolies commission (if you didn’t Microsoft would have bought our Apple long ago instead of bailing them out). but you don’t have this with pool operators and so somehow this needs to be checked.
Are you saying people should not have a choice where they stake and should be forced to change every 5 epochs? By just setting this as a default people would want to turn this off (and rightly so) I also don’t think this has been thought through or would work.
The same owner might decide to operate several “pool brands”, of course, but only to a point, if he has to promote each of those brands.
I say people should have that option, not that it should be the only option. And I consider two main reasons for that:
- Pool “brand names” tend to concentrate delegation on them. To approach a better decentralization, an opposite influence should be created. Think of a centrifugal vs centripetal force, to reach an equilibrium.
- Being vigilant about pool performance and saturation might be OK for the current Cardano delegators, but I don’t think is realistic going forward. A reasonable “set it and forget it” delegation option should exist.
How do you know for sure that SOLO AND 1PCT are not connected (not that I think they are)?
SOLO is not a real group. It’s a grouping of all independent operators, as far as we know.
The suggestion is not to “force” delegators to change pools every so often, but to give them the ability or the option to be able to set technical criteria for the pools that they want to delegate to.
This way, after specifying their criteria, they won’t have to manually choose stake pools anymore. It will be either the wallet or the network protocol that will automatically choose stake pools for them, based on their given criteria.
4 Likes
You’re comparing apples and oranges here.
Any mining rig inside mainland China is monitored by and, while possibly owned by separate entities, controlled by the CCP.
The Cardano ADA pools are broken up between genuinely different distinct entities that you can identify many times by name and offer some level of transparency and accountability. So while it’s possible that they could some day work together, they are not doing so now. And if they did, they could be personally addressed and held accountable in some way.
Most importantly, the Cardano pools are not controlled by a single authoritarian entity with a track record for fraud, repression, and a host of other offenses, as Bitcoin and most minable PoW coins/tokens are.
That distinction, in my mind, makes the world of difference.
Additionally, the various groups behind Cardano (the Cardano Foundation, IOHK, etc.) share your concerns and continue to work tirelessly to address them.
Cardano/ADA is as far from Bitcoin as you can get in the cryptocurrency space.
2 Likes
That’s the issue right there. It means the wallet would have access to the secret keys at will and perform operations without the user final consent. That’s a no-no as far a I am concerned.
Delegating is a vote of confidence. I would not let anyone nor a software implementation do any voting on my behalf.
You’re missing the point. No one is talking about taking control of your keys.
We are just talking about some kind of programmatic stake delegation. Think of it like this:
- You provide your technical specifications for your delegation.
- Sign those specifications (or instructions) with your keys.
- Submit to the chain.
- The protocol implements those specifications. Or, alternatively, the wallet can implement the already-signed instructions. They wouldn’t be able to change those instructions because they don’t have your keys. And they wouldn’t be able to implement anything else in your behalf because the instructions need to be signed with your keys.
This idea doesn’t require wallets or anyone else to touch your keys.
There’s also nothing about this that means a software will implement anything in your behalf that isn’t part of YOUR own instruction. This is no different from submitting a transaction that contains a “technical instruction” that says send X amount of ADA to address YYYYYYYYYYXXXXXXX and only to address YYYYYYYYYYXXXXXXX and no one else.
It’s software that implements that instruction. That instruction is very specific. This is the kind of delegation instruction we’re talking about - the delegator providing specific instructions, sign those instructions and submit it to the protocol for implementation.
On top of that, there is also no part of this idea that suggests this will be the “only” way to stake. We’re just talking about making this an “option”.
I am no blockchain wizdev, but what you propose at the moment is not feasible
That said - even if it would be - I still think delegation is a vote of confidence to a pool or a group of pools for the value / work / directions they provide or take. They can have to adjust their fees for example, going up for a while or down. They could be unlucky for some time with the slot lottery and so on … I would still back them up for a reason.
Programmatically playing with delegation kinds of breaks an implicit social contract that goes with it. That’s why I am not fond of it. And that’s why even if it would be available today, I would not use it.
Dude, this only requires coding. It probably takes more than a few lines of code but this is way simpler than the algorithms already implemented into the current Cardano software.
To say that this is “not feasible” (either now or in the future) can be taken as an insult to the engineering capacity of the devs building Cardano.
And again, I don’t know which part of the technical instructions being YOUR OWN is hard to grasp. If it is only your own instructions that are being implemented, that means it is your own “vote of confidence” that is still being respected, that is being applied.
Here’s another attempt to make you see that your concern is misplaced. Think of it this way:
Some delegators come into Cardano without any particular preferred stake pool. They want to get involved with the project and want to support the network by staking. But they don’t want to pick any particular stake pool manually. But they have a set of specifications in mind - a set of criteria for the stake pools they want to delegate to.
For example:
- Pools that are below saturation
- Pools whose KES are not expired
- Pools that have at least 98% of assigned blocks actually minted
- Pools with pledge of at least 50k ADA
The idea is that it would be great if delegators like this are given the option to put these specifications into a delegation instruction of some form and it gets executed by the protocol.
There’s totally no social contract that gets broken here because it’s the delegator who specifies his/her criteria. This is as if those specifications are the “terms and conditions” of the “social contract” that the delegator wants to enter.
You might not be able to relate to this, but some of us actually find it more convenient to stake like this instead of manually checking out hundreds of stake pools one by one in order to find just one that best matches our preferences.
And for users like yourself, you don’t have to stake like this if you prefer to choose your pool manually. No problem with that also.
But to oppose an improvement like this just because you prefer to do things manually, is like telling people they should never be allowed to convert their delegation preference into code because just because.
5 Likes
English is not my primary language; it should read “not feasible today, right now, as it works today with the current implementation”.
- Easy to filter with an UI.
- Only the pool operator knows that
- Only the pool operator knows that
- Easy to filter with an UI.
Again, I’d rather see people involved in the delegation process than blindly trust into an algo even if they customized it.
Example: Pool AK47 // Any benefit from the pool will fund AK-47s shipment to war zones.
How do you deal with this programmatically ?
- Users like yourself can continue to use the UI the way you currently do.
- Nope, the protocol can check on this. And it currently does check, on every block proposed by every stake pool.
- Also incorrect. The protocol also keeps track of this metric. This is how the network can quarantine a stake pool after a while of it not producing blocks assigned to it. Otherwise, a lot of blocks will not be created if the network keeps assigning blocks to be minted by pools that don’t work.
- No problem.
And as to the UI, who said the delegator will have to actually write code to delegate like this? A UI can be provided to allow delegators to provide their specifications.
Have you seen the Marlowe playground? You can create smart contracts in there without writing a single line of code.
No problem. For those who want to do it like you do, no worries.
As to the “blind trust”, this wouldn’t be blind at all. It’s the delegator who provided the specifications. If anything, this is providing the delegator even more granular control on how they stake… or in your words - how they allocate their “votes of confidence”.
This is an open, permissionless system. You don’t deal with things like this by opposing a new, useful functionality from being added into the system.
Besides, even the current way you stake doesn’t deal with that problem at all.
I don’t know anything about that pool at all but I suppose the only way you found out about what they do is because they openly talk about it. If they chose to be discreet with what they actually do, you wouldn’t have any clue at all. For example, if they wanted to, they could have just as easily said that they do “charity work” or that they “donate their earnings…” or something else like that… (seems popular with some pools).
And also, even if they openly talk about supporting war mongering or terrorism, those people who will want to support them, will and can support them with the way things are right now.
Lastly, the proposed delegation mechanism we are discussing here can easily be improved to allow the delegator to exclude specific stake pools that they don’t want to delegate to. Easy!
I guess I should have made my point better.
-
KES related thing. An expired KES leads to rejected blocks. Of course anyone can see a pool is not producing blocks. I understood your trigger as a “KES expiry soon”-trigger, that would probably be more useful.
-
I disagree with you here and I think it is down to definitions. Only the pool knows which blocks it was assigned for a given epoch, and that is part of the protocol security. The network is aware of the estimated performance, which is based on your stake. Those two are very different in practice.
As for the rest, I have used an exaggerated example to demonstrate the difficulty to place boundaries between what’s acceptable to what is not. Here we can all agree this AK-47 pool idea sucks. But what about more subtle behaviours ?
In my eyes, what you propose is a system that supposedly helps delegators by streamlining their decision process. In a sense, that’s already what the Daedalus ranking achieves by focusing only on best ada returns. First pool = best pool. With the success we’ve all witnessed …
What I say is : I’d love delegators to put a little bit more thoughts to what they do. And where is the benefit of this solution if you need to implement in the code the parameters you fancy ? That time is not really saved in the end.
Anyway, we might not agree and that is fine as well.
No, this would not be useful at all. If you’re going to filter out pools from your choice just because their KES will soon expire, it’s like you are considering them to already have expired KES even if they actually still have time to rotate their keys.
What I’m talking about are pools that have really, already expired KES. The protocol can identify those pools and hence, the protocol can exclude them from the delegator’s specified choices.
It appears you haven’t actually read the engineering specifications of the Cardano staking mechanism.
Here’s a relevant excerpt from that doc:
It is not just the stake pool that knows its scheduled blocks. The protocol, the entire network does. This information is just not easily readable by operators for pools other than their own.
This is not something that’s subject to agreement or disagreement. This is an established fact. This is also not down to definitions. This is how the protocol works.
It’s part of its intended operation to know the blocks scheduled for minting by each pool even before the epoch starts and it also needs to keep a history of each pool’s performance so that it will not be vulnerable to simple attacks like some pool being funded with a huge amount of stake but won’t actually produce blocks.
But anyway, we are getting sidetracked already. You are raising specific concerns about how to implement my example specifications. I’m supporting a general idea thrown in here by @nachocm. But as you can see, those specific concerns can easily be addressed.
The way Daedalus ranks stake pools right now is effectively the same as the commercial censorship that CH has been complaining about with Wikipedia. Daedalus is effectively, systematically disadvantaging the newly-started pools with not a lot of capital.
Capital alone is not the only measure of a stake pool’s ability to help secure the network. But the Daedalus ranking algorithm gives too much weight on that.
Blind trust
You speak of not wanting to see people “blindly trusting” algorithms… yet you endorse the ranking algorithm for stake pools in Daedalus… as I’ve mentioned above, it appears to me that you haven’t read the design specs of the staking mechanism… I think it’s safe to assume you also did not really look at the code that implements the maths behind the Daedalus rankings.
That would be a great example of the “blind trust” on an algorithm that you mentioned. And in this case, you’re the one actually doing it.
The Daedalus pool ranking algo doesn’t give due consideration to the fact that new stake pools can get traction and more delegators through their marketing efforts. But if from the start, Daedalus doesn’t even rank them, it’s like depriving them the chance to even prove themselves. This ranking algorithm is handicapping new and small community stake pools right at the start.
In effect, it favors only the currently, already big pools. This in turn allows them to grow even more. That in turn allows them to create more new stake pools they also control. This is heading to consolidation, centralization.
I’ve said this several times in other places, and I’m going to say this again here - the “long-term” returns won’t matter if by that time, we will have achieved centralization instead of decentralization. I know this is an extreme supposition but the Daedalus rankings are steering us that way.
“First pool = best pool” is a naive assumption.
4 Likes