Revision c6868e1d
| ID | c6868e1d7fd7ce6179942b2b909686d0a9ec2b0b |
| Parent | d2525573 |
| Child | 7a5d3bbd |
Fix sstore handling in Processor
- no need to keep the sstore as an object member, remove it
- don't reinitialize sstore only if self.cfg is None
This is not an issue, as the Processor is recycled for every opcode,
but in general we know that (a) we might need a different type of
sstore for different opcodes and (b) initializating them is cheap
- recreate sstore when chaining opcodes
Without this fix chaining an opcode which requires a writable sstore
to one which doesn't would fail. This doesn't happen today, but it's
better to fix it anyway
These changes are possible because nowadays all opcodes already require
a working cluster/configuration.
Reviewed-by: iustinp
Files
- added
- modified
- copied
- renamed
- deleted