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
Currently the Steel API only supports proving the result of contract calls. It also be useful to be able to prove other historical chain state, in this case the state of accounts/contracts.
Motivation
While a workaround is to deploy a contract that returns the desired values certain applications may wish to read this state directly rather than taking this approach. For example when reading values far into the past such a function may not have been deployed.
Implementation
API
It probably makes sense to follow the function name conventions of alloy providers e.g. get_balance, get_code_at, get_transaction_count on the guest side.
One idea for the host might be to add a include method to EvmEnv which accepts an enum with variants corresponding to the different account state values function calls e.g.
Feature
Currently the Steel API only supports proving the result of contract calls. It also be useful to be able to prove other historical chain state, in this case the state of accounts/contracts.
Motivation
While a workaround is to deploy a contract that returns the desired values certain applications may wish to read this state directly rather than taking this approach. For example when reading values far into the past such a function may not have been deployed.
Implementation
API
It probably makes sense to follow the function name conventions of alloy providers e.g.
get_balance
,get_code_at
,get_transaction_count
on the guest side.One idea for the host might be to add a
include
method toEvmEnv
which accepts an enum with variants corresponding to the different account state values function calls e.g.but other ideas also welcome
The text was updated successfully, but these errors were encountered: