Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate EVM Istanbul upgrade #1571

Open
enlight opened this issue Nov 6, 2019 · 5 comments
Open

Investigate EVM Istanbul upgrade #1571

enlight opened this issue Nov 6, 2019 · 5 comments
Assignees
Labels

Comments

@enlight
Copy link
Contributor

enlight commented Nov 6, 2019

What are the breaking changes? Is it worth upgrading?

@Sriep
Copy link
Contributor

Sriep commented Nov 6, 2019

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
Copy link
Contributor Author

enlight commented Nov 6, 2019

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

@Sriep
Copy link
Contributor

Sriep commented Nov 6, 2019

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
Copy link
Contributor

Sriep commented Nov 6, 2019

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
Copy link
Contributor Author

enlight commented Dec 12, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants