Ethereum Core Devs Meeting 47 Agenda
lrettig opened this issue · 31 comments
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
- Testing
- Client Updates
- Research Updates
- Constantinople
- EIP 1108: Reduce alt_bn128 precompile gas costs
- ProgPoW
Time permitting i think it would be useful to discuss the recent ProgPow developments:
ethereum/go-ethereum#17731
https://twitter.com/nicksdjohnson/status/1042382028837203968
@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?
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.
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
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.
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.
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.
IfDefElse have been invited to the meeting this Friday.
@Souptacular good to hear that! I'm looking forward to the meeting! 👍
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
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.
@holiman I think this would be the safest way forward. Thank you for spending your time making this work.
@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.
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
ConstantinopleBlockandProgpowBlockto 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.
So now that we know that the devs have decided to definitely not include ProgPOW in Constantinople (or push it out a month) I think it's high time of us talking about taking out the issuance reduction out of Constantinople & include it into the ProgPOW HF thereafter.
As mentioned and agreed upon by several community members, it is very apparent and logical what an issuance-reduction HF will do to the network and how it will cause chaos when forking the 'ASIC net' away back to the 'GPU network' to introduce ProgPOW.
If you keep issuance reduction in Constantinople anyway, it will give a clear signal to the community that you'll likely just drop the ball on ProgPOW after Constantinople and it'll sink a lot on the priority ladder,
dragging it out to Istanbul.
Taking the issuance reduction out will assure that you follow up on the promise of ProgPOW.
Could you include that into the next dev meeting?
It was a great meeting by the way with a lot of valuable insight, thanks @ifdefelse for joining the call!
So now that we know that the devs have decided to definitely not include ProgPOW in Constantinople (or push it out a month) I think it's high time of us talking about taking out the issuance reduction out of Constantinople & include it into the ProgPOW HF thereafter.
As mentioned and agreed upon by several community members, it is very apparent and logical what an issuance-reduction HF will do to the network and how it will cause chaos when forking the 'ASIC net' away back to the 'GPU network' to introduce ProgPOW.
If you keep issuance reduction in Constantinople anyway, it will give a clear signal to the community that you'll likely just drop the ball on ProgPOW after Constantinople and it'll sink a lot on the priority ladder,
dragging it out to Istanbul.
Taking the issuance reduction out will assure that you follow up on the promise of ProgPOW.
Could you include that into the next dev meeting?
I agree that is a perfectly reasonable compromise. I respect the fact that there's a lot of technical work to be done. But the only aspect of constantinople that this issue is tied to is the issuance reduction. Those two things need to happen in parallel.
If you keep issuance reduction in Constantinople anyway, it will give a clear signal to the community that you'll likely just drop the ball on ProgPOW after Constantinople and it'll sink a lot on the priority ladder, dragging it out to Istanbul. Taking the issuance reduction out will assure that you follow up on the promise of ProgPOW.
I don't want to speak for everybody, but why this would give such a signal? The main motivation behind issuance reduction has to do with the delaying of the difficulty bomb, if I remember correctly. I was not under impression so far that there is some kind of horse trading going on between developers and the miners. I have an impression that we are instead trying to talk like civilised people and make decisions when enough information is available.
@AlexeyAkhunov
Premise 1: There are ASICs on the network that are more efficient than existing GPUs. Those ASICs likely also operate in big data centers with access to cheap electricity.
Premise 2: Reducing issuance from 3 ETH to 2 ETH will cause a significant shift towards the more efficient machine (the ASIC).
Conclusion: Switching from an ASIC/GPU mixed network to a GPU-only network causes less trouble, than to first switch to an ASIC-only network (that premise 1 and premise 2 imply) and then after a few months to a GPU-only network.
Do you agree?
PERSONAL OPINION: I personally believe that when Constantinople rolls around and you do the issuance reduction and the hashrate drops by 30 something percent, the general feel amongst developers will just be: "meh, hashrate dropped 30%, no big deal", this would likely drag the implementation out by a couple months, if not to the Istanbul HF.
Taking issuance reduction out will incentivize the devs to keep working on ProgPOW until it is implemented.
As Martin has said on the call (and if I understood it correctly), technically it will be feasible to implement it in a fast manner (into Constantinople) but politically/governance-wise it's a problem. I ask: why?
Almost everyone agrees that ProgPOW will decentralize the Ethereum network and some people say technically it's not too hard to implement, so why let politics come in the way of technical innovation?
The 2 best ways forward:
- Push Constantinople out 1 month (or whatever time is needed, if any additional time is even needed) and implement ProgPOW into Constantinople.
- Take issuance reduction out of Constantinople and implement ProgPOW in a separate ProgPOW HF.
If you keep issuance reduction in Constantinople anyway, it will give a clear signal to the community that you'll likely just drop the ball on ProgPOW after Constantinople and it'll sink a lot on the priority ladder, dragging it out to Istanbul. Taking the issuance reduction out will assure that you follow up on the promise of ProgPOW.
I don't want to speak for everybody, but why this would give such a signal? The main motivation behind issuance reduction has to do with the delaying of the difficulty bomb, if I remember correctly. I was not under impression so far that there is some kind of horse trading going on between developers and the miners. I have an impression that we are instead trying to talk like civilised people and make decisions when enough information is available.
My understanding was that a significant motivator for the issuance reduction was not purely technical, but an economic policy decision to lower the rate of monetary inflation. By doing so they would significantly reduce the viability of ETH mining to the majority of the smaller miners, thereby increasing centralization by concentrating power within large farms, particularly ASIC farms.
The reason they are tied together is very straightforward - the issuance reduction significantly threatens small to medium sized GPU miners, and because ProgPoW takes ASICs off the table it is supportive of small GPU miners. So it balances out.
And may I quote the Ethereum Whitepaper at this point:
The Bitcoin mining algorithm works by having miners compute SHA256 on slightly modified versions of the block header millions of times over and over again, until eventually one node comes up with a version whose hash is less than the target (currently around 2192). However, this mining algorithm is vulnerable to two forms of centralization. First, the mining ecosystem has come to be dominated by ASICs (application-specific integrated circuits), computer chips designed for, and therefore thousands of times more efficient at, the specific task of Bitcoin mining. This means that Bitcoin mining is no longer a highly decentralized and egalitarian pursuit, requiring millions of dollars of capital to effectively participate in. Second, most Bitcoin miners do not actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers. This problem is arguably worse: as of the time of this writing, the top three mining pools indirectly control roughly 50% of processing power in the Bitcoin network, although this is mitigated by the fact that miners can switch to other mining pools if a pool or coalition attempts a 51% attack.
According to the Whitepaper, ASIC-resistance provides decentralization to the network, the very foundation of any credible cryptocurrency. If it is threatened, the very first priority is to defend the foundation of said cryptocurrency. If nothing is done, and the argument of "PoS is coming" is constantly parroted, it would have made sense to just choose SHA256 from the beginning, because back then it was also known that "PoS is coming soon". Obviously Ethereum didn't do that and chose to go the way of decentralization and I hope the EF will protect one of Ethereum's most valuable features until PoS is implemented.
Small scale-mining side is where I come from, and thats why I've been reading this and following news lately. I think many here , are doing really great job, delivering best of their work and so on. But if we look at this whole Etherium as a whole from distance. Its become bigger and it is full of everything. It comes with solutions for future, mechanisms, community, everything... also fear. There is no single person whos responsible for all what happens right? Every one bring 1 piece of their knowledge to something whats called "soup?" It is good to talk about facts , and what is likely to happen. If we look at those facts, and drop the fear factor for sec and not blame anyone for anything. There is a possibility of Asic invasion and loads of problems, if issuance reduction is turned on without Progpow. Fact right? Is it worth testing how its going to be? If aiming for shiny future, should there be elimination of every "maybes" on way to get there?
@MoneroCrusher I was not going to get into a debate over issuance reduction, as I do not hold strong opinion on this matter. I just wanted to point out that you might be making wrong projections about how developers would behave and creating tension where it would not otherwise be any.
@AlexeyAkhunov
That's reasonable and noted, but you have to understand that the miner community has been neglected since May (they had ifdefelse on their meeting back then already (which was positive, meeting #40) and it wouldn't even be a debate now if they had taken the time to properly look at it back then. Only after big community outlash and tons of heated arguments they seem to have gotten more interested.
I'm sure the ETH devs are very fine people but I think there's not enough understanding about the severe consequences of hashrate centralization and it's probably the most pressing problem for the project right now.
With regards to issuance reduction my argument stands outlined above. It's all about having a smooth switch, which is best achieved when issuance reduction + ProgPOW go hand in hand.
By doing it separately you will have 2 problems instead of 0
Problem 1: switching to issuance reduction-only chain might split the chain into ASIC chain and GPU chain 1
Problem 2: switching ASIC-only chain to ProgPOW chain will cause another split and possible intense manufacturer propaganda
You end up with 3 chains: old chain, ASIC chain and ProgPOW chain
If it's going hand in hand:
ASIC/GPU-mixed chain straight to the ProgPOW chain, manufacturers will continue mining on the old chain and will maybe get politically involved anyway, maybe not (in the case of Monero Bitmain created Monero Classic (XMC, it's real look it up) but it's a dead shitcoin nobody cares about. But since the manufacturers are not developing the project any further it will quickly become apparent they're only mining it to dump it on the markets, which will result in a quick inevitable death. Mission accomplished.
By first embracing the ASIC chain you create very easily avoidable trouble.
but you have to understand that the miner community has been neglected since May (they had ifdefelse on their meeting back then already (which was positive, meeting #38) and it wouldn't even be a debate now if they had taken the time to properly look at it back then.
Ok, I have just listened to the part of that meeting back in May (unfortunately, I could not participate, and I did not watch the recording until now) - thanks for giving me a lead!
It was indeed very positive meeting, and participants were generally supportive. I have not seen ProgPOW mentioned anywhere until perhaps couple of weeks ago (perhaps I was looking in the wrong places, I am sorry), so I was completely unaware it was even a thing. I wonder what was the reason for the gap May - September. Do you think Ethereum Core Developers are to blame for that? I suspect they were quite busy with preparing Constantinople EIPs and improving the clients, and the go implementation of ProgPOW appeared only very recently. "Ms If" said on that meeting back in May that their team was going to make implementations and core devs will be looking at them. Isn't this what is happening now? Were the implementations ready before and everyone was ignoring them? "Ms If" also mentioned that education was missing, and now the education is happening.
So I am not very happy with the presumption of mutual distrust and neglect. Lets apply critical thinking instead
@AlexeyAkhunov To my understanding the state of ProgPOW was the same in April 2018 as it was in the beginning of September 2018, pretty much nothing happened on the Ethereum side in that time.
Anyways I agree we can move beyond that, now that the Ethereum devs have had the chance to look into it a little more and are positive towards it.
My only concern right now is that when not applied in parallel - ProgPOW and issuance reduction that is - then it will cause unnecessary problems.
So my big question:
Why is it such a huge problem to implement ProgPOW into Constantinople when it is technically feasible?
If the argument is "there's not enough time" then why is it a problem to just postpone it 1-2 months? If postponing is a problem, why is it a problem to take out issuance reduction? Taking out issuance reduction is 0% effort, as nothing has to be done.
That is to warrant a smooth transition, as mentioned several times.
If you think that applying ProgPOW & Issuance Reduction in parallel will not cause a smoother transition, please let me know your reasoning behind it.
@MoneroCrusher :) If it was only up to me, I would only include 1 single change in Constantinople - which is Ice Age delay (because everything else is not essential and does not make Ethereum more scalable). Instead, I would keep optimising the clients and working on Eth 2.0. But (luckily) it is not just up to me. Also, if it was only up to me, I would roll out most features like shifts, CREATE2, etc., in smaller hard forks, gradually polishing the process and making it more adapted to more frequent and smaller changes. But again, it is not just up to me, and I would like to pick my battles :)
because everything else is not essential and does not make Ethereum more scalable
🎉
🎉
🎉
issuance reduction
the issuance is not reduced, the block reward is
@5chdn what is the main reason for the block reward reduction? It won't affect the price at all. Only the total supply. Why?
To stabilize the issuance while delaying the ice age.
Okay i understand