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
Hence the tweet
How long would you manage without a non-broken ropsten?
Tweet served its purpose :) . I am here saying we heavily use ropsten for testing our contracts atm. We are rather close to mainnet release and really don't want to add the task of finding another testnet on top of my team right now.
How bad would it be for you if there was a chain split?
Would effectively make testing almost impossible. Say a chainsplit between parity/geth. Half of us use parity, other half geth to test both clients.
How long would you manage without a non-broken ropsten?
I don't understand the question. You mean for how much longer do we need a testnet?
