I’d like to raise another concern: upgrading a common good parachain requires the root track, because we need to XcmPallet.send() a message from the relaychain to the cg-parachain.
This is problematic due to multiple reasons:
A decision deposit of 3.33 kKSM is a substantial amount. Encointer needs to upgrade imminently and doesn’t have that amount of KSM on its account currently. compared to its previous treasury proposals, such a high amount would seem unreasonable to just keep in reserve for runtime upgrades
The support threshold curve for root is too demanding for a CGP like Encointer or even Statemine. The last runtime upgrade of statemine passed on gov1 with a turnout of 0.21%. This turnout would not even be enough to make that upgrade pass in gov2 at all, because it needs at least 50%x3/(28x24)=0.2232% 3h before 28d are over. Even with twice that turnout such an update would still require 28 days until enactment.
max_deciding is set to 1 for this track, so only one referendum at the time is in deciding phase at any time. I don’t think parachain matters should compete with relaychain matters like that.
So, as a concrete example: Right now, Encointer would depend on a whale to provide the 3.33KSM to submit its referendum for an upgrade of its runtime and then needs a bunch of whales (12.5% of all KSM) to vote in its favor in order to enact the upgrade within a reasonable 7d.
Looking at the rather frequent runtime upgrades of statemine, I wonder how that can be done in gov2 as it is now.
please correct me if I misunderstood the code.
I do acknowledge, however, that TrustedTeleporter CGPs can potentially do significant damage with malicious updates and reasonable time for review of the runtime upgrade changes must be granted.
My suggestion here would be to involve the Fellowship. Maybe we can let them approve runtime upgrades of GCP somehow, as a prerequisite for a faster track similar to LeaseAdmin. (History shows that we’ll need a quick way to unbrick auctioned parachains too - more often than we’d wish for)
would be great to have @joepetrowski’s thoughts on this
Agreed that its hard for common good chains to upgrade when using root origin. For this, @joepetrowski had a few ideas, including:
Split Root into a two tracks: RelayRoot and SystemParaRoot , with exactly the same parameters. The SystemParaRoot could support multiple proposals at once, but only limit them to xcm.send(...) , so that it can’t be used for other things on the Relay Chain.
Ease the curve a bit on this new track
I also think that it essential to involve Fellowship on this so they can assist with a whitelist.
very reasonable solution to my concerns. Please ease the deposit too. I know that’s not an issue for Statemine, but it leads to dependency (centralization) at least for Encointer, as outlined above.
Just wanted to let ppl know we have prepared a whitelisted root call proposal (thanks @joepetrowski for investigating on the process)
A few remarks with respect to this discussion:
I guess it is obvious that this process needs a decent UI. it is way too heavy to lift now and could be easily assisted through a UI.
I believe it is actually a good thing that common good parachain upgrades must undergo a whitelist referendum by the fellowship to get a fast-track enactment. This way we can hope that a knowledgeable person has indeed reviewed the changes
therefore, this use case does probably not need its own SystemParaRoottrack as proposed above
the decision deposit of currently 33.3 k KSM for whitelisted caller is ridiculous. I won’t repeat my centralization&stagnation concerns
the support threshold of whitlisted caller saturates at 10% (14% after 3d). Such a turnout seems prohibitive to me. I’m not aware of any referendum that ever yielded such turnover during gov1.
I suggest to change the whitelisted_caller track as follows:
decision deposit: 333 KSM (100x smaller)
max_deciding: 1000 (100x higher) ( we can’t decrease the deposit without raising this, otherwise a DDOS attack is possible, jamming the queue. It should still be easy to keep an overview in spite of 1000 potential parallel proposals if we filter by whitelisting status)
decision_period: 7d
confirm_period: 3h
approval threshold saturates at 66.6% ( a higher approval requirement makes sense to me here)
support threshold is 14% after 3d but goes down to 0.1% after 7d
As someone who just submitted a proposal under Gov2 to Tip a fellow community member using track 31 (Big Tipper), I’m strongly in favour of lowering the submission_deposit to 1/10 of the current value (100 KSM) in particular for the Tipper tracks.
I’d like to iterate on a discussion in the PR:
from @brenzi
What is the reasoning behind the 10% support threshold for whitelisted_caller? This is higher than root itself and very hard to attain. Doesn’t that grant a gatekeeper position to whales?
Reduced to 5% now. There should likely be some substantial turnout needed to avoid the possibility of the network being controlled de facto by the Fellowship.
I agree on the goal not to give too much power to the fellowship. For me this would mean that the whitelisted_caller track should only be faster than root track but not less demanding in terms of minimum support and approval. However, if minimum support is 5% for whitelisted_caller wheras it is ~0.2% after 28d for root, that means that the former is actually more demanding than the latter. This does not make any sense to me. Why should we expect higher support for whitelisted_caller than for root which doesn’t need fellowship approval?
With regards to the new OpenGov curves presented by @otar in the Kusama Direction Channel
My feedback is the following:
166 KSM deposit for the starting range of big spender(34), represents a 33%, which I think is excessive.
I think it would be more appropriate, at least during the crypto winter, to extend the range of Medium Spender to 1000 KSM.
50 KSM decision deposit for a 1000KSM proposal represent 5%, which is in line with the top end of Big Spender as 166KSM decision deposit for 5000KSM proposal represents 3%.