Storage inspection command

[ascjones]

Contract metadata describes the storage in the layout section. A storage command should be introduced which utilizes this to allow inspection of a contract's storage from the command line.

So for the flipper:

#[ink::contract]
pub mod flipper {
    #[ink(storage)]
    pub struct Flipper {
        value: bool,
    }
}

Calling cargo contract storage --contract <contract_account> would result in the following:

Flipper { value: false }

This would work by using the metadata to generate keys and query the get_storage rpc: https://github.com/paritytech/substrate/blob/30ecb9b259140a860b20c662fda01b5b2c33e5fa/frame/contracts/rpc/runtime-api/src/lib.rs#L54.

The metadata would then be used to decode the results into human readable form, building on the "SCON" work done in #79.

For an initial implementation I think we don't need to do everything in a single PR, we can define a basic implementation that is useful and then add features as follow up PRs.

Lazy and Collections

We would need to consider how to handle the built-in lazy and collection types, they would probably require some custom display code.

Keys

It might be useful to be able to augment the data with the actual storage keys, and also query individual storage keys either by the raw key or by name.

Raw Storage

For debugging of corrupt storage it would be useful to be able to inspect the raw contract storage (without decoding).

[Robbepop]

I added the blocked label since this feature depends on some changes made in ink!'s layout metadata section. The current metadata format cannot represent some more or less common scenarios and really needs some restructuring. When I tried some weeks ago I immediately hit a wall for recursive data structures.

We first have to define semantics, definitions and structures for a new and better layout metadata section before we should tackle this issue. We have to think about cases like:

• recursively defined data structures such as enum Tree { Leaf(i32), Node(Box<Tree>, Box<Tree>) } or in case of ink_storage: ink_storage::Vec<ink_storage::Vec<i32>>, packed elements where some elements actually have some further pointers Pack<(i32, ink_storage::Box<i32>) and more.

Maybe we have to restrict the final metadata to not support certain use cases because their metadata format would become too complex otherwise.

We might want to create a new issue for this in the ink! repository.

[cmichi]

Whoever implements this should take a look at the CLI layout that Truffle uses. I have only this shaky photo from a talk:

The layout is quite nice and clean.

[ascjones]

I have only this shaky photo from a talk:

It looks good (I think!). I wonder can the image be cleaned up using magic technology?

[ascjones]

I have only this shaky photo from a talk:

It looks good (I think!). I wonder can the image be cleaned up using magic technology?

Perhaps easier to run the command ourselves to see the output 🙈

[cmichi]

I've obtained a better screengrab 🙃:

(source)