There is one SortKeyCache instance for reading/writing contract state cache.
As ppe pointed out this means that the rollback batch is shared among all contract cache.
In case of a very unfortunate events order this may cause some incorrect rollback/commit behaviour??
Since now we do not perform any rollbacks on the state cache this seems not be a problem, at least for now...
Warp evolves very fast and it is very important to keep that issue mind and maybe change the rollback implementation to a map
Map<tx_id, rollbackBatch>
There is one SortKeyCache instance for reading/writing contract state cache. As ppe pointed out this means that the rollback batch is shared among all contract cache. In case of a very unfortunate events order this may cause some incorrect rollback/commit behaviour??
Since now we do not perform any rollbacks on the state cache this seems not be a problem, at least for now... Warp evolves very fast and it is very important to keep that issue mind and maybe change the rollback implementation to a map Map<tx_id, rollbackBatch>
Related to https://github.com/warp-contracts/warp-contracts-lmdb/pull/24#discussion_r1170229454