Creating a r/sys/config realm for runtime configuration
#1856
Comments
This was referenced Mar 28, 2024
Kouteki
modified the milestones:
🏗4️⃣ test4.gno.land,
🏗4️⃣ test4.gno.land [POST LAUNCH]
|
Will be replaced by #2920. However, let's keep the issue open in case we need to write a solid realm. |
moul
added a commit
that referenced
this issue
Oct 23, 2024
- [x] port x/params -> sdk/params b930513 - [x] inject in vmkeeper + add std.SetConfig 602245d - [x] implement in `gnoland` 783a044 - [x] appchain - [x] rpc query - [x] txtar - [x] implement or add comment where we should use it in the existing codebase - [x] namespace's realm target - [ ] questions - [x] do we want a `std.GetConfig` from the contract part? -> No, it allows unsafe, complex, and implicit patterns. If you want to get a value from another contract, you can either import it or use a registry pattern. This approach preserves type safety and other GNOVM protections. - [ ] do we want to restrict the realms able to call `SetConfig` (only `r/sys`), or maybe set an expensive gas price? - [x] after discussion with jae - [x] Rename Config -> Param for consistency - [x] Remove `interface{}` from the setters and use specific types, including in the tm2 implementation (string, uint64, int64, bool, bytes) - [x] Remove the `.<type>` suffix addition, but ensure that the type is explicitly defined by the user; and remove the table. - [x] Remove the types table from the tm2 implementation Related #1418 Related #1856 --------- Signed-off-by: moul <[email protected]>
Kouteki
added
in focus
|
@moul what values should be in the config? |
|
Per discussion with the team, I'm closing this issue - we've done enough for the launch milestone. Future work will be tracked in #3271 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is a need to create a
r/sys/configrealm to configure and update blockchain configuration by governance. This would include changing parameters such as VM memory limit, CPU cycle, and parameters that will be read by tendermint2 for some custom modules we'll want to develop later.As for other gnoland module, the goal would be to use the upcoming event emit system (#575) to alert tm2 of a change once the contract confirms that all the requirements are met (i.e., DAO approved a change).
This realm should be linked with genesis. Right now, configuration is either hardcoded or in the configuration file, but in our case, the goal is for the blockchain to start with minimal config while relying then on this realm. So we should imagine maybe having a shorter genesis and configuration file, while focusing on making it easy to extend this realm with new variables that are then read by tm2.
This issue is to make it clear that this realm should be developed but also to have a reference for existing discussions so we can centralize all the discussions here.
Depends on #575
Related with #828 (review)
Related with #1837 (comment)
Related with #1807
The text was updated successfully, but these errors were encountered: