Ethereum Core Devs Meeting 47 Agenda

[lrettig]

Ethereum Core Devs Meeting 47 Agenda

Meeting Date/Time: Friday 28 Sept 2018 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Livepeer Stream Link

Constantinople Progress

Agenda

1. Testing
2. Client Updates
3. Research Updates
4. Constantinople
5. EIP 1108: Reduce alt_bn128 precompile gas costs
6. ProgPoW

[Daft-Wullie]

Time permitting i think it would be useful to discuss the recent ProgPow developments:
ethereum/go-ethereum#17731
https://twitter.com/nicksdjohnson/status/1042382028837203968

[HiddeHoogland]

@Daft-Wullie I think that will be fair to the community. A lot of requests from users and miners to discuss ProgPow. Maybe a good idea to include some ProgPow developers in the discussion?

[Shadowfiend]

I would like to hop in to discuss the best path forward for EIP-1108, including some new benchmarks since the discussion at Core Devs meeting 43 and their implications.

[MoneroCrusher]

Interesting to follow:
ethereum/go-ethereum#17731

Progpow turned out to be extremely easy to add, since it was not a new consensus engine per se, but rather an internal switchover from hashimoto to progpow inside ethash. -holiman

~~The only problem right now is a verification time of a block of 4ms Ethash vs. 80ms ProgPOW
ProgPOW devs are looking into this.
But you also got to ask yourself: what's worse? A centralized network or slowdown of some components of the network until PoS (14s block time stays the same)? Syncing a new node will take the biggest hit (6 days with 1 CPU core), or 0.75 days with a modern Ryzen CPU.~~~
see answer by @OhGodAGirl below. On discord chat she said verification time goes from 4ms to 8ms so it's negligible @holiman

[OhGodAGirl]

If required, the IfDefElse team will be available with sufficient notice.

The CPU verification is a bug in the geth code and we're addressing it and testing internally before we push the code; our GPU verification stack was copied to the CPU for internal testing, and needs to be appropriately addressed. It should be 2 times slower (twice the data being pushed), not whatever it is now (give me a break, it's 4:38AM here, I don't do math in my head at this time).

I would like to remind all developers to again take a look at the code base and investigate bugs on their own, too, rather than pointing to a bug and using that as an argumentative basis for all the reasons a change cannot be considered.

[Nmining]

After my little coffee-accident, I've been cleaning all those fans and circuits. Just to come back and check things here and.. But hey, now it seems things are going to really good direction. So I believe I'll keep my gpus on ether. Thank you.

[5chdn]

see answer by @OhGodAGirl below. On discord chat she said verification time goes from 4ms to 8ms so it's negligible @holiman

please link to the details of this. 20x verification performance drawback would be a show-stopper for progpow. I'd say even 2x is an issue, especially for light clients.

edit, sorry I'm blind.

I would like to remind all developers to again take a look at the code base and investigate bugs on their own, too

we have a p.o.c. rust implementation of progpow to start playing around with.

[Souptacular]

IfDefElse have been invited to the meeting this Friday.

[HiddeHoogland]

@Souptacular good to hear that! I'm looking forward to the meeting! 👍

[chfast]

Looks like progpow verification is buggy also in C++ code.

----------------------------------------------------------------
Benchmark                         Time           CPU Iterations
----------------------------------------------------------------
verify                            1 ms          1 ms        546
verify_progpow                 1508 ms       1508 ms          1

[holiman]

Some testcases and benchmarks for progpow in geth is available here: ethereum/go-ethereum#17731 (comment) . Basically verification is about a 2x increase. I personally don't think that's a blocker -- we're not going to go another 6M blocks with it anyway, just until PoS...

My proposal would be to prepare a separate hf which is decoupled from Constantinople. Because the two really are not technically tied together. If we eventually decide to set both ConstantinopleBlock and ProgpowBlock to the same number, then fine, but that's not a necessity.

From a testing perspective, the tests for progpow are very different from the tests that are written manually by @winsvega to find quirks in the evm implementation. Tests for progpow require no knowledge about the EVM, so the actual tests could/should be produced by someone else so that process can run in paralell and does not have to take time from the constantinople testbed.

[HiddeHoogland]

@holiman I think this would be the safest way forward. Thank you for spending your time making this work.

[MoneroCrusher]

@holiman
As I have outlined before, a separate fork only makes sense when you take the issuance reduction out of Constantinople.
If you leave it in you'll have an ASIC network after Constantinople..then 1-2 months later you want to destroy that very ASIC network with a ProgPOW fork?
Doing one thing is really asking for trouble and the Chinese manufacturers effort to keep the old chain alive (it'll happen anyways but you'll have less friction in one swift move).
The two must go hand in hand, either in Constantinople or in separate ProgPOW HF after it.

[mdaria510]

Some testcases and benchmarks for progpow in geth is available here: ethereum/go-ethereum#17731 (comment) . Basically verification is about a 2x increase. I personally don't think that's a blocker -- we're not going to go another 6M blocks with it anyway, just until PoS...

My proposal would be to prepare a separate hf which is decoupled from Constantinople. Because the two really are not technically tied together. If we eventually decide to set both ConstantinopleBlock and ProgpowBlock to the same number, then fine, but that's not a necessity.

From a testing perspective, the tests for progpow are very different from the tests that are written manually by @winsvega to find quirks in the evm implementation. Tests for progpow require no knowledge about the EVM, so the actual tests could/should be produced by someone else so that process can run in paralell and does not have to take time from the constantinople testbed.

From a technical perspective that makes sense, but from a practical/political standpoint it doesn't. First off, by doing the issuance reduction first, you set the stage for a potential ASIC takeover in the intervening weeks/months. Also, segwit2x is very strong in my memory. Just because one faction of stakeholders supposedly "agree" to do something, once they get what they want, they no longer have any pressing need to do the thing that they've obviously signaled they don't particularly care for.

To be completely frank, the dismissive attitude of the developers prior to the increasing vocal opposition has burned any semblance of trust with the mining community. It's no longer credible to me that developers will support this change post-constantinople, where there would be no more pressure to do so. So I will continue to oppose and rally support to maintain the existing chain until it is confirmed to be included along with the rest of the proposed changes.

It IS a necessity that it's tied to the same block.