You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Prevent calling the invariants from changing the state.
Problem Definition
The role of the invariants is checking whether a blockchain invariant is broken. And any module can register its own invariants. However, the logic inside the invariant can change the chain state due to its side effect. The module developers will do their best, but there is no guarantee that it can be prevented. As an innocuous example, there are some getter logics (like GetModuleAccount()) which actually modifies the chain state. So I think x/crisis should take responsibility and prevent it from changing the state of the chain.
There are two places in which x/crisis calls the invariants.
k.AssertInvariants() in its EndBlock.
VerifyInvariant() in its message server.
While the case 2 uses CacheContext() in prior to the call, there is no such instrument in the case 1.
It seems there is no critical side effect right now, it would be better to prevent the possible risks.
Proposal
Use CacheContext() in x/crisis AssertInvariants().
Pros:
Executing invariants cannot cause side effects.
Cons:
Impacts the performance.
The text was updated successfully, but these errors were encountered:
Summary
Prevent calling the invariants from changing the state.
Problem Definition
The role of the invariants is checking whether a blockchain invariant is broken. And any module can register its own invariants. However, the logic inside the invariant can change the chain state due to its side effect. The module developers will do their best, but there is no guarantee that it can be prevented. As an innocuous example, there are some getter logics (like
GetModuleAccount()
) which actually modifies the chain state. So I think x/crisis should take responsibility and prevent it from changing the state of the chain.There are two places in which x/crisis calls the invariants.
k.AssertInvariants()
in its EndBlock.VerifyInvariant()
in its message server.While the case 2 uses CacheContext() in prior to the call, there is no such instrument in the case 1.
It seems there is no critical side effect right now, it would be better to prevent the possible risks.
Proposal
Use CacheContext() in x/crisis
AssertInvariants()
.Pros:
Cons:
The text was updated successfully, but these errors were encountered: