Investigate EVM Istanbul upgrade

[enlight]

What are the breaking changes? Is it worth upgrading?

[Sriep]

Six code changes https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1679.md Eventually, Solidity compiler will be updated to use Istanbul at which point we will be wanting to be supporting it.

A new precompile for the BLAKE2b hash function used for Zcash.
A new opcode for getting a unique chain id for the EVM. Could have varied uses, but designed to prevent replay attacks between different chains.
The remaining four are restructuring gas usage and probably don't affect us much.

• EIP 152: New precompile for Zcash hash function.
• EIP 1108: Repricing precompiles
• EIP 155: New OP code to return unique chain ID.
• EIP 1884: Rebalance op code gas costs.
• EIP 2028: Reduce gas cost of Calldata.
• EIP2200: Gas metering.

[enlight]

Any idea when the Solidity compiler will get official update to Istanbul?

[Sriep]

It is possible to set the Solidity compiler to use istanbul now, which adds two new opcodes to assembly. However for the latest Solidity v0.5.12, the default EVM target is petersburg, which is functionality the same as constantinople, which we support.

I guess most people will just use the default.

Some documentationt that suggests that Solidity 0.5.13 will still default to petersburg.

[Sriep]

EIP 155: The chain id opcode is designed to tie a signature event to a chain via its network(chain) id. The v byte in (v,s,r) breakdown ties to the network Id.

Users can sign a piece of data incorporating the network id of a target chain before passing to a solidity function. A Solidity contract, running on the EVM, can then verify that the network ids match. If such a transaction later gets replayed, there is a guarantee that it has been replayed on the correct DappChain.

[enlight]

Our current go-ethereum fork is based on a commit between go-ethereum v1.8.16 and v1.8.17, while Constantinople was activated on Ethereum Mainnet on v1.8.20 v1.8.22, which means we don't have 100% Constantinople compatibility right now. For instance the CREATE2 opcode probably uses less gas in v1.8.16 than in v1.8.20, I haven't dug into the other differences yet. Since Constantinople is already enabled on our clusters we're going to have to add another feature flag to enable the 100% Ethereum compatible version of it.

The Petersburg fork was activated on Ethereum Mainnet at the same time as Constantinople, it fixes an issue in Constantinople, since we activated some half-baked version of Constantinople we probably still need to activate Petersburg.

The Istanbul hard fork happened on Ethereum Mainnet a few days ago, on go-ethereum v.1.9.9 (https://blog.ethereum.org/2019/11/20/ethereum-istanbul-upgrade-announcement/) so we should probably rebase our go-ethereum fork on that release, port whatever hacks we have, and hack the Constantinople upgrade.

go-ethereum v1.9.8 switched over to using Go modules, so might be a good idea for us to switch over from dep to Go modules too.