State Access Helper Functions

[RodrigoVillar]

Context and scope

In the context of contract storage, StateDB is a mapping from 32-byte words to 32-byte words (i.e. a mapping from hashes to hashes). While this is easy to comprehend, the more complex part is converting arbitrary values to hashes that StateDB can use. Subnet-EVM currently does not provide any helper functions that handle these hash conversions for developers.

Discussion and alternatives

We can add getter/setter functions to Subnet-EVM that hash/unhash values whenever necessary and interacts with StateDB for the user. An example of what these helper functions could look like is as follows:

StoreString(StateDB, storageKey, someString)
GetString(StateDB, storageKey)
StoreInt(StateDB, storageKey, someInt)
GetInt(StateDB, storageKey)

In the case of setter functions, each one would hash the value to be stored, and update the necessary mapping in StateDB. Likewise, in the case of getter functions, each one would return the value mapped to storageKey within StateDB.

One issue that was brought up by @darioush was how a setter function would store a string that was longer than 32-bytes. In general, for any value of length greater than 32-bytes, an option is deferring to how Solidity manages the storage of such values. In the case of string, the following documentation explains the storage/retrieval process: Layout of State Variables in Storage .

AvalancheGo, as an example, comes with helper functions, as seen here: helper.go

Open questions

• Where would these helper functions go in Subnet-EVM?
• Should these helper functions also handle the hashing of storage keys?
• In addition to big.Int and string, what other types should these helper functions handle?

[aaronbuchwald]

Hmm the layout of state variables in Solidity is dependent on the order in which those variables are declared in the contract.

It would be really cool to take a contract and map directly to golang bindings that support reading/writing to those variables and encoding them correctly in the state based off of the order in which the variables are declared in the corresponding Solidity interface.