Issue created by jeff-aion (on Monday Oct 22, 2018 at 19:04 GMT)
The SoftCache used to implement the hot DApp cache currently assumes that it is always accessed at a time after its previous access. This can cause a problem for situations where the AVM may be invoked for out of order blocks or where a block may be executed multiple times.
Since the code is immutable, once it is stored, this problem only matters from the perspective of whether or not this did exist prior to being accessed where incorrect cache hits could cause inconsistencies across the network.
For example, 2 conflicting blocks which both create a different contract at the same address (or the same contract, even) must give the same result whether or not the first version was in the cache.
Comment by jeff-aion (on Monday Oct 22, 2018 at 19:06 GMT)
I suspect that this is as simple as storing the block number where a contract was cached and providing a way to request that the cache drop everything after X block number when starting a batch.
Issue created by jeff-aion (on Monday Oct 22, 2018 at 19:04 GMT)
The
SoftCache
used to implement the hot DApp cache currently assumes that it is always accessed at a time after its previous access. This can cause a problem for situations where the AVM may be invoked for out of order blocks or where a block may be executed multiple times.Since the code is immutable, once it is stored, this problem only matters from the perspective of whether or not this did exist prior to being accessed where incorrect cache hits could cause inconsistencies across the network.
For example, 2 conflicting blocks which both create a different contract at the same address (or the same contract, even) must give the same result whether or not the first version was in the cache.