I am also seeing the Ropsten fork date as extremly tight, considering that EIP-1014 for CREATE2 is not finalized and tests for EXTCODEHASH ethereum/tests#484, SSTORE ethereum/tests#511 and difficulty bomb delay are not yet production-ready.
One thing is that breaking Ropsten testnet might not be the "end of the world" (Piper), but I think on this path we'll break it for-sure (at least very likely).
But tests won't be regenerated in time :/
For the record, Pantheon’s CREATE2 implementation follows the new gas calculation and other changes from ethereum/go-ethereum#17812. It will be tight given the prep we need to do for initial open sourcing, but I’m hopeful that we’ll have full Constantinople support before it actually kicks in on Ropsten. The biggest concern is that the ethereum reference tests appear to be in a fairly unhappy state at the moment so testing compatibility is challenging.
And that was the wrong link… too many tabs open and all looking like github pull requests….
We've started an initiative to improve on the situation with tests. See this gist for more details: https://gist.github.com/holiman/fdec3547f2b104803abbd2c6e751a8e7 . There is a new hire who will (among other things) work on this
@holiman :thumbsup: :thumbsup: :thumbsup: That's great! @winsvega is doing a great job on the execution side, to complete the picture it would be great if you could also extend on communication with the new hire, atm it is hard to get e.g. the latest state of the Constantinople implementation or generally a picture what is happening related to tests.
Stuff I would value a lot here:
- More structured issues or alternatively projects to sum up work e.g. for Constantinople, test reorg,...
- More work on the documentation at https://ethereum-tests.readthedocs.io/en/latest/ (still have admin access there and can pass on access if desired)
- Regular updates (biweekly or so) what is going on (Reddit, medium, somewhere, can also be minimalistic for not adding too much additional workload)
Just some wishlist. :smile:
I think it is definitely a good idea to postpone Ropsten hard-fork, and chose another block number when we know geth and parity have CREATE2 gas cost implemented. Also, didn't we overestimate the block time on Ropsten last time (took 15 sec instead of 12 something seconds)?
to be clear, Parity can support ropsten hf on nightly and beta, but our stable released probably won't make it
since it's only a test network it's probably fine
So we were off by about a day
By 'let it be' I mean don't postpone
I am currently working on gas calculation update for
CREATE2. it should be ready by tomorrow. But it turns that we won't be ready to publish a release before Ropsten fork block happens, so, it'll be available only in a Snapshot version. But it doesn't look like a big problem and we're ok on keeping 4_200_000 for Ropsten
@elichai this isn't the place for that kind of support, you should ask on https://ethereum.stackexchange.com/
@holiman I don't necessarily want to postpone. I think this is a more prudent from the "process" point of view. If there are tests you can run on the clients before going into the testnet, you should run them first. If not, and you won't, then of course it does not matter
so I will reformulate the question to the client devs: will postponing the Ropsten fork allow you to run more code reviews/checks/tests on the code? If the answer is yes for at least geth or parity, I would recommend postponing. If no, then postponing does not help
@AlexeyAkhunov I see it a bit differently. We're understaffed on testing, and a good way to get more test coverage is to put it on a mainnet where everyone can help test it. It wouldn't have to be ropsten, it could have been a new testnet, but I think forcing clients to make real releases with Constantinople as soon as possible is better for everyone. I don't want to bork Ropsten intentionally, but if it uncovers a consensus error then that's a very good thing.
We know some clients will stay on the non-Constantinople Ropsten fork, like parity stable. Tests aren't complete, so it's reasonable to expect consensus errors too. We might say it's acceptable to break a test network, but plenty of devs think of it as a place to test their contracts rather than for core to test consensus. All of that implies delaying.
On the other hand, I see two key rationales for not delaying: 1) we can use Ropsten to help identify consensus issues quickly and 2) we train developers to deal with chain splits and long reorgs. Those are both very valuable. IMO, they are valuable enough to aggressively launch on Ropsten, with a caveat: we need a loud communications broadcast.
All teams involved should be posting to twitter, blogs, etc saying "we are intentionally testing a contentious fork to Constantinople on Ropsten at 4.2M, we expect clients to split the chain during testing". If parity, EF, etc aren't comfortable broadcasting that message in the next ~24 hours, then I think we should delay the Ropsten fork, and launch a brand new testnet instead, to start consensus tests.
On the other hand, I see two key rationales for not delaying: 1) we can use Ropsten to help identify consensus issues quickly and 2) we train developers to deal with chain splits and long reorgs. Those are both very valuable. IMO, they are valuable enough to aggressively launch on Ropsten, with a caveat: we need a loud communications broadcast.
All teams involved should be posting to twitter, blogs, etc saying "we are intentionally testing a contentious fork to Constantinople on Ropsten at 4.2M, we expect clients to split the chain during testing". If parity, EF, etc aren't comfortable broadcasting that message in the next ~24 hours, then I think we should delay the Ropsten fork, and launch a brand new testnet instead, to start consensus tests.
From Grigore: how to count gas without metering it.
https://gitter.im/runtimeverification/iele-semantics?at=5bb41fa51c100a4f29212814
https://gitter.im/runtimeverification/iele-semantics?at=5bb41fa51c100a4f29212814
