Closed cthulhu-rider closed 9 months ago
I'd leave it as is for now. _deploy
params is not something that should normally be changed for an installation and committee groups can be handled more effectively in the future (we need to analyze how they're really used in our contract set).
We have minimal _deploy
parameters now, no committee groups and it all works fine not limiting us at all.
Currently all contracts require an internal version upgrade to update (see
version
methods and_deploy
callbacks). In general, this is quite expected: changed the code - raise the version. However, this introduces restrictions on changing the rest of the state parameters.Manifest
Manifest can't be changed w/o internal version upgrade (i.e. code changing). Overall, version should be bumped if manifest is changed by source code (see
config.yml
files). At the same time, there are special cases when it may be required to update the manifest dynamically. Practical example: assignment of groups.Extra data
Additional update parameters are more of an unwanted feature than a practical mechanism, but they exist. Currently we can't pass custom args to
update
w/o NEF changes.Extra data isn't a problem in 99% cases: we try to avoid it as much as possible. In theory, this is still the limit.
Group list modification also not a daily routine, but still more likely. For example, NeoFS Inner Ring controls committee group which, as a committee itself, is a dynamic entity. Currently there is a workaround used on initial setup, but later updates are problematic. See https://github.com/nspcc-dev/neofs-node/issues/2195 for details.
Possible solution