[Beyond EVM] performant StateDB implementation - part 2

[ramtinms]

see #5129

[codecov-commenter]

Codecov Report

Attention: 38 lines in your changes are missing coverage. Please review.

Comparison is base (ffddae1) 56.50% compared to head (036c370) 56.61%.

Files	Patch %	Lines
fvm/evm/emulator/state/delta.go	87.11%	26 Missing and 12 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5167      +/-   ##
==========================================
+ Coverage   56.50%   56.61%   +0.10%     
==========================================
  Files         983      984       +1     
  Lines       93757    94052     +295     
==========================================
+ Hits        52979    53247     +268     
- Misses      36828    36844      +16     
- Partials     3950     3961      +11     

Flag	Coverage Δ
unittests	56.61% <87.20%> (+0.10%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fxamacker]

Nice! I left some comments and suggestions.

Some account related questions:

• Can account be present in both created and suicided list in the same view?
• If so, what is the status of that account?
• Do we need to reset account cache, such as codes, balances, etc after account is flagged for deletion?
• Do we want to return error in setters after account is flagged for deletion?

[ramtinms]

@fxamacker @sideninja I spent some time going over the Geth code and updated the logics for creation and suicide at 036c370

[ramtinms]

To answer your questions @fxamacker :

Can account be present in both created and suicided list in the same view? If so, what is the status of that account?

Yes, it could be in the state of suicided then created (then we flag it with recreate), clean up the old data and delete the account at the end of the transaction and create a new one with changes.
The reverse is not allowed right now, if an account is created then suicided.

Do we need to reset the account cache, such as codes, balances, etc after account is flagged for deletion?

when an account is set for deletion, everything except the balance has to be still accessible throughout the transaction, except for when recreation is called then we clean all the account values (in this case we also have to carry over the balance of the old account before flagging for deletion.

Do we want to return error in setters after account is flagged for deletion?

we don't do anything even if an account is flagged for deletion, we accept them and ignore them at the end and delete the account. Yeah I know it feels odd but that's how Geth behaves.

[ramtinms]

going to merge this PR but feel free to provide feedback so I can address it in the next PR