search

near / near-evm

Obsolete EVM contract experiments. Find current development at: https://github.com/aurora-is-near/aurora-engine
GNU General Public License v3.0
32 stars 11 forks source link

Optimize NEAR EVM implementation #43

Open evgenykuzyakov opened 4 years ago

evgenykuzyakov commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

MaksymZavershynskyi commented 4 years ago

@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 commented 4 years ago

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