I’ve been thinking recently about the possibilities that Goguen might bring in combination with some threat modelling and I’ve come up with a smart contract that I hope, somehow won’t work.
Let’s say I am a pool operator and I make a smart contract that does the following:
1 accept payment from any wallet A
2 put that payment in a new wallet B
3 register that address as a pledge address with my pool (probably off-chain?)
4 monitor the rewards address C
5 calculate rewards and send it to address A
6 send back ADA from wallet B to wallet A
There are many features and added options to add here like holding the ADA for multiple epochs, but this is the essence.
This should be a win-win situation, because a higher pledge means higher rewards and higher desireability.
The downside for the stakeholder is that the ADA is forcefully locked up for at least an epoch because if the pledge is not met, the pool will not mint. However, this seems like a very small price to pay.
Can someone explain to me why this idea would not work?
That is incorrect. If the pledge for the epoch is not met, the pool can still forge blocks in the epoch, but the pool will get zero rewards for that epoch. Neither the SPO nor the delegators get rewards for this epoch.
Hi Erik, thanks for that correction. Yes, the risk is not getting rewards if the pledge is not met.
The way for this hypothetical smart contract to mitigate that is to only return the contributed pledge after the epoch is over and subsequently update the pool certificate.
Do you see a reason why this mechanism won’t work? I’m very interested
At the start of epoch N, a snapshot is taken of the current stake and pledge state. If the pledge is not met for epoch N, there are no rewards for that epoch. Moving pledge or stake after the snapshot is taken makes no difference to the reward calculation for epoch N. Likewise moving pledge into the pool after the start of epoch N make not difference to the reward calculation for that epoch.
No need to apologise. Thanks again for the clarification. It would actually make this hypothetical smart contract easier to implement with less downside to the ‘stakeholders’.
It’s of course valuable to get the details right, but the main point of my post is to validate if it’s possible to subvert the pledging mechanism like this.
Pledge has an important function and the prohibitive force is a required level of trust with the stake pool operators. If we can implement that trust with a smart contract it seems logical that everyone will use that smart contract and ‘regular’ staking will become a thing of the past. I’d think that is undesireable.
Interesting idea. If I understand correctly the delegator would have to redelegate via the smart contract in each epoch also it would be more difficult to prevent over saturation.
Due to a0, a pool with more pledge gets higher rewards. So if you have ADA and you can choose to either stake or pledge, pledging is better. That is the win for the person with ADA.
Pledging is a mechanism to prevent the creation of many 0% pools and use that as a sybil attack. As a stakepool operator or attacker you need to bring the pledge yourself which is a finite resource. Being able to bring in ADA as pledge from a third party without requiring trust (or even human interaction) subverts this mechanism. The smart contract implements that trust. This is the win for the stake pool operator because he/she can operate as many desirable pools as they like without being constrained by how much ADA they have available for pledging in each of them.
Not necessarily. I was alluding to this among other things with the ‘extra features’.
You can implement in the smart contract a trigger to release the funds from wallet B and send it back to wallet A instead of automatically. Very simple example, if I send 1 extra ADA from A into the contract, that will trigger the refund. This way you can have your stake be pledged indefinitely without thinking about it in a safe way.
Again, I am looking for ways to prevent this because if this is possible, then I am confident that we will see it happen and it will be detrimental for the network.
But the low level of interaction on this thread is not making me very hopeful
Edit: There are actually many issues with what I have below. I’m going to write a more details response as I’ve been musing on this for the last hour.
The pledge factor as it is currently set has a very low impact on rewards. There is a non-zero cost to running the smart contract you describe and it would be somewhat complex. I don’t know if it would be profitable with the current pledge factor. Even if it were profitable, it requires the contract to update the pool parameters whenever Ada enters or leaves. A change could be made to limit the number of times a pool’s parameters can be updated in the same epoch. Some reasonable limit could be conceived of that a normal pool would have no issues with.
The minimum stake pool fee has a greater protection against Sybil attacks at a protocol level right now from my perspective.
For the suggestion of a ‘smart pool’ to be profitable it has to meet the following criteria:
It has to be more profitable for the delegators.
It has to be profitable enough for the pool operator to run the pool.
There have to be no negative consequences for any of the parties involved.
Delegators will incur the following costs:
Additional cost to send Ada to the smart contract (we don’t know the additional cost but triggering a smart contract will almost certainly be more expensive then delegating)
Additional cost to take their stake/rewards back from the smart contract. This is a somewhat additional cost. Delegators remain fully in their control of the stake when they delegate. Under this system a delegator requests their Ada back, which trigger the smart contract and will cost some amount. Delegators still have to pay to ‘claim’ their rewards under normal delegation but trigger the smart contract is almost certainly more expensive than a transaction to claim rewards.
The monitoring and calculating of rewards probably happens at the beginning of every epoch. Amounts are calculated and saved into the data of the smart contract. This triggers the smart contract and would be a cost that has to be split among all the delegates, proportional to their stake I imagine.
The smart contract at a minimum has to update the pool certificate once an epoch, near the end, so that the current pool pledge matches the actual for it to have the correct benefits. In theory it could sometimes not update if no additions or subtractions have been made to the pool but all it would take is one person adding or subtracting to force it to happen so I think it is safe to assume it will happen every epoch. This triggering is another static cost that must be split among delegates.
The costs of 1 and 2 can be minimized by putting in stake and keeping it there for a long time. The costs of 3 and 4 are ongoing and happen every epoch.
Delegators get the following benefits:
Their stake is earning the pool additional rewards because it is pledge. However at the moment this amount is very small.
In this scenario the benefits have to outweigh the costs for it to be worth it for delegators. That is not clear at this time but with the current low pledge factor my gut feeling is that it would be a wash.
Now we go to the pool operator.
Let’s start from the base case, the operator charges 0 margin and they themselves have 0 pledge and don’t take any rewards from the pool besides the static minimum fee or some portion of the fee (the smart contract could take the fee and split it among the delegates). As long as they are happy with that amount and the delegators get more benefit than costs this whole thing works and maybe something has to be done.
Let’s say the operator wants to charge a margin and they figure out calculations in the smart contract so they get the same amount of Ada as if everyone was delegating and they had this margin. Thus the contract passes on all benefits of the pledge to the delegators. For example they set the lowest margin possible (I don’t know what that is) which is 0.01%. Now we have a comparison to make. How much does a delegate make delegating to this ‘smart pool’ vs. delegating to a 0 pledge, 0% margin pool? At some amount of margin, delegating to a smart pool will be the same as delegating to a dumb pool. Which brings us to the risks.
The above works without risk if we assume the smart contract has no bugs. This could perhaps evolve over time but might be bumpy on the way. And how do you know when the bugs are gone? Will the profit for delegators be enough to take on this risk? People trust the protocol delegation and rewards because that system was researched, published, built with formal methods and verified with fuzzy testing. Will that same level of rigor be applied to this ‘smart pool’ contract? How long will that take and who will pay to build it? What happens when the first bug happens and people stop using it? How much Ada could get locked up?
Even if the above risks aren’t as bad as I think, there is always the solution of changing the pledge protocol. I’ve thought for a long time introducing a locking mechanism for pledge (but not delegation) that further could increase pool rewards would be a good idea. There are pros and cons but this could force people to lockup pledge and thus while not the current trust model, would establish a new trust model where pools commit to lockups in exchange for greater rewards.