Also understand the motivation here but don’t agree with it. First and foremost, how do you even know who owns a particular address, where they’re from or how they affiliate now. This opens up the door for geo-political conflict naturally growing in the protocol. There are also other issues to consider:
If said address is already delegated to you, who pays the fees to block/reject/undelegate?
How are users actively notified that such a thing happened? People don’t typically spend their days staring at their wallets to look for notification that their delegation has been pulled. As an SPO, you essentially agreed to an implicit contract already that you personally have no control to “deny” service to anyone especially when doing so is not an interactive affair.
I can see where the protocol could help “block” new delegation upon saturation. Honestly the way Daedalus sorts pools is still IMHO quite misguided given the focus on larger pools.
One could argue that a pool perhaps moving forward could restrict who delegates, like based on geography but again this opens up a giant can of worms. How do you know who owns what? How do you know their location, nationality, location or nationality changes. Perhaps this is better dealt with a change that allows pools to declare that they require KYC or you can’t delegate but what kind of entity are you to require or collect/promise to keep safe KYC information. Perhaps in a permisioned version of Cardano I could see that.
In my opinion the less specific control a pool has the better. Also in my humble opinion there are more important things to focus on in the immediate/short term. Bringing real utility & scalability for example.
I’m starting thinking that trying to solve two different problems with the same functionality wasn’t too smart at all, and the proposed functionality have to much problems, more than it’s supposed to solve.
Talking with friends and reading some comments here I have come to the conclusion that it may be better to split this draft in two, and specifically:
For the saturation problem an SPO could set a max-saturation as percentage of the optimal (let say 100%, 110%, 120%, etc.) in the pool registration and this can be easily managed by the network in the new delegation phase. Does not solve the problem for existing delegation growing over time but it’a a starting point not to disruptive to implement, also using it is optional.
For the regulatory problem I’m still convinced that some SPOs may need, maybe soon, to be able to filter delegation using their own KYC to create a white-list because of possible strange law all over the world and the network should give everyone the ability to comply, but the proposed method is too much inefficient.
I’m elaborating another solution, something integrated in the pool registration that act before the delegation is done. It’s much easier than rejecting it after it’s done. Now, it can be done with an external json, like metadata.json, fully loaded on-chain at registration time or only referenced as an url. I think this can be easy to implement and not invasive on the protocol, at all.
What I’m still unsure about is if is better to load it on-chain or not:
In the first case it will be a slow process since new entry in the white-list will be evaluated only the next epoch and it will force SPOs to update the registration too often.
The second case, without an hash on-chain, provides near real-time updates but it introduce another problem because I’m not sure if nodes can access an external url when new delegation come to a pool that has this option active. Well, if it fail because the site is down it’s not a great problem, they can try again, but reading a json from an external source can lead to security problems.
So, I started this because I think this are real problems and I would like to suggest a solution. While I’m still convinced this are real problems I must admit this proposal is not the solution I’m looking for.
Right, who pays? This and other problems make me changing idea, if you want you can comment on my latest reply here, I must admit this is not the solution I’m looking for.
Sadly it seems it’s not enough, there are pools over 120% and this is not good, I think.
More than a “permisioned version of Cardano” (Cardano is one) I prefer to have the ability to declare permisioned pools with their own KYC, and this is what I’m trying to propose, in my last reply here you can find another proposal that may address the problem in a better way, even if with some doubt.
I’d definitely put it on-chain. It’s vital knowledge needed to know if a delegation to a pool is valid, if a transaction to delegate should go through. Such information should not be stored externally, where we can never validate, what it looked like at any specific point in time.
Why should that be the case? Transactions are available to the other nodes immediately. (At the moment, “immediately” seems to mean a couple of hours, but that will hopefully be solved soon.)
It is a design decision of the rewards process to use snapshots every epoch, but that does not determine other processes in delegation to also only use epoch snapshots.
Still, the question is if this allow-list solution only restricts future delegations or if removal from that KYC list by the SPO shall also mean that the delegator is kicked out.
Since your fear is government regulation, probably the latter is needed, because regulators that do not buy “It’s a passive process. The SPO does not have more to do with their delegators than a football team has with people betting on their game results.” will also not buy: “We can restrict future delegation, but we cannot undo past delegation.”
Along those lines: Is it possible that the introduction of these possibilities is the thing that leads to the necessity of also using them? Does this proposal make delegators more customer-like?
I don’t think this should be allowed. This makes it possible for fake pools to draw delegators from real pools and drop them, causing lower overall pledge. With enough fake pools it may be a way to attack the network by removing large amounts of delegation just before the epoch starts. Also, it causes loss of Tx fee to delegator with out any way to notify them.
SPOs do not issue rewards, so they have no need to deal with regulators. If there is a country/ region that starts considering SPOs as financial services, then SPO can just increase the fee to 99% and issue rewards as payments, since that is what regulation forces on SPO to be anyways. At 99% it wont matter if someone delegates and oversaturates with out permission since you hold 99% of rewards anyways.
Other option would be to set rewards at 100% and collect each individual delegation for locked staking.
I think if you are trying to address such issues maybe a top down approach is better. Maybe ask to change the ability of private stake pools to manually add addresses they will allow to share in 100% locked pool. This way it doesn’t impact any regular pools, just adds an option for private (100%) pools to manage stake addresses associated with it.
This way any delegator will know what they are getting into before they pay Tx fee to delegate to a stake pool.
About the new way to attack the network if SPO can remove stake addresses?
It opens a new vector of attack.
Example:
Bad actor can open 500 pools for only 250k ADA. They could lure delegators with fake ISPO or lottery system that awards 1 million ADA to random delegator or something like that. When enough ADA is moved to those pools, then a bad actor could remove them all from delegating reducing overall level of delegation. Thus giving pools that have remaining delegators easier time to break 51% needed and they maybe able to control a whole Epoch worth of transactions.
We saw that recent ISPO can easily concentrate billions in to just a few stakepools. So, this type of attack would be possible with in just a few weeks. It could remove enough ADA out of delegation to allow consortium of remaining pools to take over block production.
Hope previous example clarifies what I was saying.
Delegation to open pools must stay permissionless for delegators, otherwise it can be used to compromise security of the network. Also, why would you delegate to anyone if you think that at any time you can be just kicked out with out any explanation.
Hmm, alas I haven’t done any staking as I wait for a spare part for my computer. Let’s see if I can contribute.
As for the first problem, I wonder if it would make sense to see of the staker could do something. If you don’t want to stake at a pool that is close to satiration, could you somehow query the stake pool, ideally from the wallet, before you decide on which stake pool to use?
The second problem seems very hard. Let’s say you know that some person should be blocked for some reason and you also know this persons Cardano address. What prevents that person from transferring coins between wallets? How can you possibly know the coins still belong to the same person? At least, that’s how I understand the problem.
Since I know nothing about staking, I have a question that may be completely nonsensical. Would it be possible to create some kind of ”umbrella stake pool”. There would be several regular SPO’s under the umbrella and if one is oversaturated, then the staked amount could be moved between the members every now and then?
The current protocol assumes delegates want to support the network, be rewarded, and choose pools. The current protocol also assumes operators want to secure the network, be rewarded, and maintain pools. When these assumptions break down so does the balance. The protocol must only support the goal of decentralization.
I would focus your CIP here. For example proposing a threshold of over-saturation that automatically rejects subsequent stake delegation transactions …
There is absolutely no way to enforce this in a decentralized way. On the one hand a centralized authority could be integrated into exchanges, PRISM, or some other KYC gateway. Legislation is an ineffective communication method in the best of circumstances and enforcing it is not the responsibility of the protocol or the SPO at all.
China has banned BTC multiple times in multiple ways yet is still a large contributor to BTC hash-rate
