HyperVMs are currently able to define their own state keys during execution on-the-fly. This means that HyperSDK can't sanity-check state keys in advance at the time of initialization, so it's possible for the HyperVM to touch state managed by the HyperSDK (fees, consensus state, etc). Some solutions would be to create separate merkledb instances for the SDK vs the VM, or to create a single partitioned merkledb instance that each component has a dedicated prefix for.
aaronbuchwald
commented
1 month ago
HyperVMs are currently able to define their own state keys during execution on-the-fly. This means that HyperSDK can't sanity-check state keys in advance at the time of initialization, so it's possible for the HyperVM to touch state managed by the HyperSDK (fees, consensus state, etc). Some solutions would be to create separate merkledb instances for the SDK vs the VM, or to create a single partitioned merkledb instance that each component has a dedicated prefix for.