On the frontend in polkadot js, we can use api.at(block_num) to rewind the blockchain back by up to 256 blocks (as these are stored on the rpc nodes as I understand) and essentially run functions on recent history as if we were at that block.
It would be nice if ink could do the same, especially considering the ink computation is being carried out on the same node containing those last 256 blocks (I believe).
If this is possible, it would be super handy for contracts which are time sensitive and require recent history access. We have a contract which fits that case, and we're currently storing historical data manually across a recent block window of 100 blocks. This adds significant bloat to the contract size and storage. If we had a method like .at() on the frontend available in ink, this problem resolve very nicely and make our contract greatly more efficient.
I imagine this is a big ask however, so interested to know your thoughts :)
On the frontend in polkadot js, we can use
api.at(block_num)
to rewind the blockchain back by up to 256 blocks (as these are stored on the rpc nodes as I understand) and essentially run functions on recent history as if we were at that block.It would be nice if ink could do the same, especially considering the ink computation is being carried out on the same node containing those last 256 blocks (I believe).
If this is possible, it would be super handy for contracts which are time sensitive and require recent history access. We have a contract which fits that case, and we're currently storing historical data manually across a recent block window of 100 blocks. This adds significant bloat to the contract size and storage. If we had a method like
.at()
on the frontend available in ink, this problem resolve very nicely and make our contract greatly more efficient.I imagine this is a big ask however, so interested to know your thoughts :)