Query At block

[S0c5]

No description provided.

[olanod]

now we have query_storage with the added block option but also we already had query_storage_at, sounds like redundancy so we should kill either of the two. I would also suggest accepting a block number instead of a hash since 99% of the time the client will want to provide a number instead of hash and will end up resolving the block to the hash on their own, we should save them that work ;)

[S0c5]

remove query_storage_at or query_storage

I understand the Backend trait as a mapping for the underlying rpc methods, while we can only have query_storage_at given it is specific to retrieve multiple keys, the trade off here is an overhead for the implementations that needs to retrieve a single value but have to deal with this:

virto-sdk/sube/src/lib.rs

Lines 395 to 399 in 92398ce

	#[derive(Deserialize, Serialize, Debug)]
	pub struct StorageChangeSet {
	block: String,
	changes: Vec<[String; 2]>,
	}

So, I'd leve the both methods given they have different goals.

Working on the block number!

[olanod]

I think we should have this only as a number(e.g. u32) and do resolution internally in the RPC implementations . 99% of the time users want to use a block number instead of a hash. If we were to use a hash we should also accept it as a byte array instead of string since the hex encoding of stuff is very JSON RPC specific.