Deletion proof should be collected while committing phase

[noel2004]

Currently we collect deletion proof from zktrie while each SSTORE has involved deletion, i.e. set a slot from non-zero to 0. This induce an addition committing in the corresponding store trie and malicous user can make use of this cost for some attacking.

[noel2004]

There would be several rules for collecting proofs:

1. Must action after each transaction, since MPT table would build entries for storage trie in each tx, not the whole block.
2. Deletion proof must be collected for each storage slot being deleted in the tx, to be exact, the first time it is deleted.
3. Notice the sequence of ops would affect the accessing of ndoes for deletion proof, consider following example:

Two differnt operating sequences lead to the same final trie. In the seq above, we need the node x as deletion proof when deleting B; while in the seq below, x is not needed.

[noel2004]

Here we purpose a resolution:

1. trace each storage slot for each account involved in deletion by logtrace module
2. Deletion trie: we start from the storage trie of an account before tx execution, and apply every deletion on the trie, collect the deletion proof with Proofwithdeletion method before each deletion.

Note:

• If an key is just created in the tx then being deleted, apply deletion of this key on deletion trie simply leads an non-op
• Though no sound proof avaliable, it seems the sequence of deletions do not affect what we would collect, and the collected deletion proof is enough

[noel2004]

Also note:

Currently implement call StorageTrie and some node would be updated into db and finnally being commited into storage, causing unnecessary cost on storage. We need a db with additional memory storage layer for the purposed deletion trie to avoid this cost.

[29988122]

Moved to asana per request. Use asana instead in the future scrum process (whenever possible)