Reduce gas with faster evm

[rakita]

Had chat with somebody in local near meetup about idea of reducing gas usage in aurora by replacing sputnik with more performant option. Not sure if it matter, but wanted to leave comparison link: cassc/rust-evm-bench#2

[birchmd]

Thanks for the suggestion @rakita . This is something we've discussed internally as well. The main considerations are the risk involved in switching (sputnik isn't the fastest EVM out there, but they have been careful about following the EVM spec), and the cost in terms of developer time. We are also exploring other avenues for continuing to reduce the amount of NEAR gas the aurora-engine uses.

[rakita]

First guideline that I wrote to express what matter to me when building REVM was EVM compatibility and stability and by that, i mean that In blockchain industry, stability is most desired attribute of any system. i value this more than speed (you can read this in REVM readme).

Sputnik is here for longer but it still fails a lot of ethereum tests and it didn't update its test suit for over the year, in that sense, REVM is a lot more compliant to EVM spec as it passes all new and recently all legacy ethereum tests and tests are run inside CI. And last time i checked, not sure if it is still the case, aurora precompiles didn't pass some of those tests. Additionally revm is chosen by foundry as it gave them a sense of stability and utilization they needed to build amazing tool for testing and in there revm is tested by it users.

As in any project, the risk and cost of switching to a different library (EVM) is there, as an interface is different, and it costs the developer time to integrate it ( I can probably help with some arrangement), but in the end, there seems to be a benefit of speeding up the aurora and having faster and more maintained evm.

@birchmd thank you for responding

[joshuajbouw]

Which tests in particular is it failing? As per the precompiles, they are fine now as of the last three version releases.

[rakita]

Here is the list of the problem that I had with precompiles: #307
time does fly fast :)

[rakita]

About sputnik, there are ignored folders in teat with no explanation why and I am not sure if all folders are there as they are manually added. This should be easy to find out. And additionaly test suit should be updated

[rakita]

Okay it was nothing critical I overreacted, there are few special case precompile 0x03 that is not handled inside sputnk, a few overflows with updated suit rust-blockchain/evm-tests#15, in st_create2 seems like there is a bug that is probably related with create2 call limit, and few folders are missing 53 are handled but ls | wc -l shows 57.

[joshuajbouw]

Thanks for the interest in the project including being interested into reducing the NEAR gas cost by improving the efficiency of the underlaying EVM!

This has been something that we have been discussing about internally since the beginning of this year and aim to start making headway on this next quarter! We have not looked at REVM, but it is on our radar now. We had been considering evmodin. What will be interesting is if someone had benchmarked it against REVM already.

[rakita]

evmodin only has interpreter part of EVM it is missing host to have journaling, revert mechanism, subcalls, accesslist etc, I am not sure if this is enough for aurora or you will need to add host part to it.

When optimizing REVM I compared the speed of what is considered faster evm out there written in cpp evmone, and i got REVM interpreter to be as fast as evmone. You can read about that here: bluealloy/revm#7

[joshuajbouw]

We are aware of what we need to add extra to it in order to make it viable, don't worry about that. That is very interesting that revm is as fast as cpp evmone which evmodin is based on.

[rakita]

evmone is in forefront of EVM research so it is not surprissing.