[EVM] Update the EVM to the most recent version

[alexauroradev]

The implementation of the EVM in #3257 is not the most recent. Before releasing we should update the implementation

[artob]

@djsatok As discussed on the call just now, I'll take a stab at this. (Please assign the task?)

[artob]

@djsatok @mikedotexe @ailisp All right, to summarize our discussion on the sync call yesterday:

We are currently pulling in Parity-Ethereum at revision openethereum/openethereum@eed630a, dated Jun 5, 2019. That roughly corresponds to upstream's 2.6.0-beta release.

Since then, Parity-Ethereum has been rebranded to OpenEthereum, and they have released the 2.7 and 3.0 branches. (They also note that due to database format changes, upgrading from 2.6.x to 2.7.x or 3.0 is a one-way only operation.)

Since the transitive dependency graph change for the full upgrade is rather large, and our code will need to be adjusted as well, we discussed on the call to do the upgrade in more than one step:

1. Upgrading ASAP to the last 2.6 security release, 2.6.8, dated Dec 31, 2019. That already rolls us forward half a year, without (hopefully) many breaking API changes.

2. Upgrading from 2.6 to the latest 3.0.1, dated Jun 1, 2020. That'll be painful, so we should try to schedule and phase it such that it doesn't disrupt everybody's work too badly.

Since we talked, I've upgraded my local dev env progressively through 2.6.x releases. Everything still compiles perfectly up to 2.6.2, but at 2.6.3 we do hit some API changes (never mind semantic versioning):

Given that, what I'd do is send a PR today for the no-brainer 2.6.2 update, and then work on making 2.6.3 (through 2.6.8) compile. Sound good, @djsatok?

[alexauroradev]

@artob, sure, no problem, let's follow suggested approach

[artob]

Consider run runtime/near-evm-runner/tests/standard_ops.rs test and make it pass again locally. And add a test case for blake2 precompile function

Originally posted by @ailisp in #3558 (comment)

[artob]

To summarize the current state of things:

1. As a first step, we upgraded to OpenEthereum 2.6.2 in Upgrade to OpenEthereum 2.6.2 #3542. That rolled us forward about 3 months (from Jun 2019 to Aug 2019).

2. Thereafter, we upgraded to OpenEthereum 2.6.8 in Upgrade to OpenEthereum 2.6.8 (Istanbul support) #3558. That rolled us forward another 4 months (from Aug 2019 to Dec 2019), and brought us to parity with the Istanbul hard fork. The upgrade chiefly required implementing a new API that is called when the new CHAINID opcode is executed.

3. I'm currently working on the upgrade to OpenEthereum 2.7.2. That will roll us forward another 2 months (from Dec 2019 to Feb 2020). And that will get us to a stable release: the whole 2.6.x series is considered beta, with 2.7.x being the stable branch. To complete the upgrade, there are a number of dependency issues and build errors to address:

4. As a final step, we are planning to upgrade to OpenEthereum 3.0.1, the current stable release at the time of writing. That will roll us forward another 4 months (from Feb 2020 to Jun 2020), for a total of 12 months forward from the starting point.

[artob]

Related to this issue, here’s a Solidity/OpenEthereum version cross reference that I compiled at @djsatok's request:

https://gist.github.com/artob/c2b5dc6c834134f3e7c1ef86232b416d

[artob]

As discussed on the weekly call today, the current state of this task is that we've now completed and merged the 2.7.2 upgrade (#3595), and it makes sense to freeze the dependency at that release for now.

OpenEthereum surprised us a week ago by releasing 3.1.0 which they had been developing in another repository. OpenEthereum 3.1.0 isn't a continuation of the 3.0.x lineage, but rather a fresh fork of the old 2.5.x branch. The 3.0.x branch appears to be considered a dead end, now.

In investigating the new branch this week, my assessment, and the team's consensus, is that upgrading to OpenEthereum 3.1.0 is too risky right now, so we will build on 2.7.2 for the time being.

The 2.7.2 version was the last Parity Ethereum release, before the OpenEthereum team took over. So, it is relatively popular and well tested. It will serve us as a “good enough” release until the Berlin hard fork takes effect, which may require an upgrade to 3.1.x, or else some backporting work to 2.7.x.

@djsatok @evgenykuzyakov I think we can close this task, for now, as I don't think there's anything further actionable here until it's time to prep for the Berlin hard fork (in January, perhaps, if Berlin doesn't get delayed further).

[alexauroradev]

Closed by #3595 and previous PRs