Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Executor environment parameters should be configurable on the fly #6805

Closed
s0me0ne-unkn0wn opened this issue Mar 1, 2023 · 4 comments · Fixed by #6934
Closed

Executor environment parameters should be configurable on the fly #6805

s0me0ne-unkn0wn opened this issue Mar 1, 2023 · 4 comments · Fixed by #6934
Assignees
Labels
I4-annoyance Code behaves within expectations, however this “expected behaviour” itself is at issue.

Comments

@s0me0ne-unkn0wn
Copy link
Contributor

Currently, executor environment parameters may only be changed with the runtime upgrade. We need the ability to configure them through governance.

@s0me0ne-unkn0wn s0me0ne-unkn0wn added the I4-annoyance Code behaves within expectations, however this “expected behaviour” itself is at issue. label Mar 1, 2023
@s0me0ne-unkn0wn s0me0ne-unkn0wn self-assigned this Mar 21, 2023
@s0me0ne-unkn0wn s0me0ne-unkn0wn changed the title Executor envitonment parameters should be configurable on the fly Executor environment parameters should be configurable on the fly Mar 21, 2023
@crystalin
Copy link

Can you give an exemple of some of the parameters that are needed ? I'm curious/concerned if those are mandatory for the correct execution or only optimizations.

@s0me0ne-unkn0wn
Copy link
Contributor Author

@crystalin TL;DR: those are parameters of the PVF execution environment that set the semantics of Wasmtime compilation and runtime environment, current list is here: #6873 (comment) (right now we're discussing more in #6918). They are not mandatory to be provided by governance, as we have safe defaults hardcoded, and we only want governance to be able to alter them if needed.

Longer answer may be found in paritytech/polkadot-sdk#917, #6161, #6793, paritytech/polkadot-sdk#694

@crystalin
Copy link

Thank you for the summary.
Is there a risk if those are hardcoded/on-chain to make it more likely that if a bug is introduced which is related to those settings, that all the validators would be running that bug because they all have the same settings ?

@s0me0ne-unkn0wn
Copy link
Contributor Author

As for hardcoded safe defaults, they represent the same semantics that was in place before executor parameters were introduced, so no risks here, everything is working exactly as it worked before.

Changing them through governance MAY break things. But that's the governance. It may brick the whole network if it wants. Basically, that may be achieved by lowering some limits to undesirable values. We're not going to lower anything ever, the parameters were introduced for us to be able to grow them if needed and to introduce new features (but not to get rid of old ones) so while the network is acting in its interest we are safe. But if the network wants to commit suicide, not much we can do with that ☹️

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
I4-annoyance Code behaves within expectations, however this “expected behaviour” itself is at issue.
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants