Currently, the InterpreterStorage trait has two issues:
It imposes an unnecessary constraint on MerkleRootStorage which can be removed.
The getter and setter methods for assets and state are prefixed with merkle_; however, implementations of these methods do not necessarily need to Merklize the data, and it is the responsibility of specific implementations to understand when Merklization is needed.
By removing the merkle_ prefix, we make it more clear that the methods are simply methods to query or mutate data in interpreter storage. Any Merklization is an internal detail. Additionally, this means that implementations of these methods that do not apply Merklization, i.e. for MemoryStorage, are more congruent with the method name.
This enables future interface changes to be done more easily and with greater confidence in their correctness.
Related issues:
Currently, the
InterpreterStoragetrait has two issues:MerkleRootStoragewhich can be removed.merkle_; however, implementations of these methods do not necessarily need to Merklize the data, and it is the responsibility of specific implementations to understand when Merklization is needed.By removing the
merkle_prefix, we make it more clear that the methods are simply methods to query or mutate data in interpreter storage. Any Merklization is an internal detail. Additionally, this means that implementations of these methods that do not apply Merklization, i.e. forMemoryStorage, are more congruent with the method name.This enables future interface changes to be done more easily and with greater confidence in their correctness.