# Do you need more block history in the ink env?

**URL:** <https://forum.polkadot.network/t/do-you-need-more-block-history-in-the-ink-env/8771>\
**Category:** Tech Talk\
**Tags:** ink, rpc\
**Created:** [June 24, 2024, 11:32am UTC](https://forum.polkadot.network/t/do-you-need-more-block-history-in-the-ink-env/8771 "2024-06-24T11:32:31Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![sinzii](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/sinzii/32/6947_2.png) [@sinzii](https://forum.polkadot.network/u/sinzii)\
**Post date:** [July 5, 2024, 5:19am UTC](https://forum.polkadot.network/t/do-you-need-more-block-history-in-the-ink-env/8771/11 "2024-07-05T05:19:33Z")

</div>

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](https://forum.polkadot.network/t/introducing-dedot-a-delightful-javascript-client-for-polkadot-substrate-based-blockchains/8956)) is calling an RPC `state_call` to the `contractsApi.call` runtime api. The [`state_call`](https://github.com/paritytech/polkadot-sdk/blob/e16ef0861f576dd260487d78b57949b18795ed77/substrate/client/rpc-api/src/state/mod.rs#L39) 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:

```typescript
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](https://paritytech.github.io/json-rpc-interface-spec/introduction.html), 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](https://paritytech.github.io/json-rpc-interface-spec/api/chainHead_v1_follow.html)). For RPC nodes, I think we can access history block/state via the [`archive`-prefixed](https://paritytech.github.io/json-rpc-interface-spec/api/archive.html) if they supports, but this force dapps to use RPC nodes which is not ideal.

---

_[View the full topic](https://forum.polkadot.network/t/do-you-need-more-block-history-in-the-ink-env/8771)._