Do you need more block history in the ink env?

,

Technically, accessing historical ink! contract state is possible, since contract state is still part of the whole state at a given block. So I think, we can still access contract state at a given block if the full state at a block is still around and has not being pruned.

Under the hood, if you call contract.query.get to call the get method on an ink! contract. The client (pjs or dedot) is calling an RPC state_call to the contractsApi.call runtime api. The state_call accepts a hash param to allow us customize the block we want to make the state call. So if somehow we can pass a historal block hash into the contract.query.get then we can query the state at that specific block.

I was able to do that with pjs with some trick to bypass the ContractPromise check api instance to access the historal state of a flipper contract, something like this:

const api = await ApiPromise.create(...)
const apiAt = await api.at(...)

// Some trick to bypass the api instance check of `ContractPromise`
// @ts-ignore
apiAt.isConnected = true
// @ts-ignore
apiAt.tx.contracts = { instantiateWithCode: () => {} }
// @ts-ignore
apiAt.tx.contracts.instantiateWithCode.meta = { args: Array(6).fill(0) }

// Initialize the contract instance using the apiAt
const contract = new ContractPromise(apiAt as unknown as ApiPromise, flipperAbi, 'contract address');
// now you can call 
console.log(await contract.query.get(contractAddress, { gasLimit, storageDepositLimit }));

While this is doable with the legacy JSON RPC api, this might probably not the case with the new JSON-RPC spec, especially for the light client for now. So with the new JSON-RPC spec, light client currently only support the chainHead_ prefixed api to access the state, so that means light client only interested in the head of the chain, and we cannot access historical block/state with light client (we technically do if some historical blocks is still pinned). For RPC nodes, I think we can access history block/state via the archive-prefixed if they supports, but this force dapps to use RPC nodes which is not ideal.