Skip to content

[V133-specific] Mimir V1 implementation of OperationalMimirs (no longer including Admin disabling)

[V133-specific]

This is in reference to #1640 (closed)
'ADD: Mimir V2'.

As expresssed in December 2023 at !3265 (comment 1676969901)
I am skeptical of whether currently-proposed Mimir V2 code is usable for arbitrary-Asset keys.

This MR is intended as a subject-to-change draft of how proposed Mimir V2 effects could be implemented in Mimir V1 through IsOperationalMimir checks.

Though #1640 (closed) reads "keep admin mimir for backup (6 months)",
this MR contains a demonstration commit that disables Admin (together with regression tests updating commits);
however, these Admin-related commits can be removed for now if preferred
(in which case links to the commits and pipeline would be added to this Overview).

[2024-03-08 update: As reflected in
https://gitlab.com/thorchain/thornode/-/commits/fde7deaa
( 6d95d344 )
https://gitlab.com/thorchain/thornode/-/pipelines/1155764362
this MR's initial 2024-01-29 submission included painstaking regression test numerical updates
to reflect that dog newly had to pay bond costs for Mimir transactions,
in turn affecting block rewards, pool depths, and anything which used pools.
Rather than do this a second time in rebasing a month later,
this MR now leaves Admin undisabled, with those changes to be in a later MR;
this MR then plausibly allows easier reading of the changes which are (or rather aren't) made.]

As always, feedback is welcome.


For further context, currently the Mimir values control network behaviour
(overriding Constants where applicable)
and NodeMimir votes are referred to on MsgMimir handling to determine whether to change the Mimir value when updating a NodeMimir value,
so outside the mimir handler it is sufficient to check only the Mimir value and not refer to NodeMimirs
(unless for example clearing a key's votes upon a churn).

Edited by Multipartite

Merge request reports

Loading