Optimize NEAR EVM implementation

[evgenykuzyakov]

The current implementation uses TreeMap for range deletes. We probably don't need it and it can be replaces as UnorderedMap of lookup maps + keys.

Some operations do Vec<u8> conversions and we don't need it.

We should also replace UnorderedMap with something like a LookupMap that doesn't have a key/value iterator and saves on storage operations.

[SkidanovAlex]

In EVM the keys to the account storage are 52 bytes, where the first 20 bytes are the contract address, and the last 32 bytes are the slot, which are not necessarily the first several slots, they are all over the place.

Without having a tree map, how would you nuke the storage of an EVM contract?

[MaksymZavershynskyi]

We just need to be able to iterate over the state of the given solidity contract, we can do it by associating each contract with a vector, which will create only 2x overhead for storage writes as oppose to >6x overhead that TreeMap gives (if I remember the numbers correctly).

Also, there is quite a lot of excessive copying. Also, we should check whether borsh serialization/desirialization of byte arrays slows down it a lot, at the minimum it adds yet another excessive copying.

[MaksymZavershynskyi]

Also, this is super suboptimal: https://github.com/near/near-evm/blob/master/src/lib.rs#L140 They are passing bytecode as hex and then parse it, basically they operate with hex everywhere, which is a large overhead.

[MaksymZavershynskyi]

Also, evm should probably be not using JSON for input/output, but should be using borsh, since it is all blobs of bytes.

[MaksymZavershynskyi]

@SkidanovAlex @evgenykuzyakov Actually we need to double check how contract removal works in Solidity, it might be the case the contract's destructor code is fully responsible for cleaning up the storage. If that's the case, we don't need to worry about us nuking the storage of the Solidity contract when it is removed.

[SkidanovAlex]

Anton confirmed that the self-destruct is responsible for wiping out the storage.