Ethereum Core Devs Meeting 54 Agenda

[Souptacular]

Ethereum Core Devs Meeting 54 Agenda

• Meeting Date/Time: Friday 1 February 2019 at 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream Link
• Livepeer Stream Link

Agenda

1. Roadmap a) Constantinople - Ropsten fork? b) Istanbul Hardfork Roadmap c) Outlook: PoS finality gadget on PoW chain (Serenity) d) ProgPoW audit?
2. Working Group Updates a) Ethereum 1.x Stanford Meetings Overview b) State Rent c) EWasm d) Pruning/Sync e) Simulation
3. Testing Updates (time allowing)
4. Client Updates (time allowing) a) Geth b) Parity Ethereum c) Aleth/eth d) Trinity/PyEVM e) EthereumJS f) EthereumJ/Harmony g) Pantheon h) Turbo Geth i) Nimbus j) Mana/Exthereum
5. Research Updates (time allowing)

[lrettig]

For the record, this is my recollection of how we arrived at 7.28M, feel free to tweak if I've gotten anything wrong:

1. @vbuterin suggested six weeks, which he said would put us around block 7.25-7.3M.
2. A couple of folks including myself asked if we could do it sooner, but the consensus was that we wanted a bit more time for updating tests, maybe rolling out on a new testnet, etc.
3. @5chdn proposed Feb. 27, which falls on a Wednesday, and also happens to be during a quiet week between ETHDenver and EthCC.
4. I used a simulation script to look at predicted block times and numbers, with the latest block height, difficulty, and timestamp. All of the details were shared to AllCoreDevs, starting here.
5. I did sensitivity analysis on network hashpower and current average blocktime. Based on this analysis I expect block 7.28M to occur between 00:00 and 09:00 UTC on 2019-02-27, the target date,

@naikmyeong we agreed that it makes sense to target upgrades to occur mid-week so it's more likely developers will be online and so that people aren't forced to work weekends.

[5chdn]

1. March 1 is a Friday
2. Epoch does not matter
3. It's decided already

[RSAManagement]

I made this reddit post: https://www.reddit.com/r/ethereum/comments/aiy5ns/uncle_rates_more_node_efficiency_or_less/ and this spreadsheet: https://docs.google.com/spreadsheets/d/1SZn6_MuOciDI_B20KqqeHtpK9yAhHIgGdpVH-SDLRnU/edit?usp=sharing

because I'm seriously worried and scared about how uncle rates are going down. Uncle rates are going down linearly since mid 2018, so it is hard to say that is because of more efficient nodes, one of the most important bug in this area was fixed just recently ( parity client, #9954) .

So i think that the problem is more and more centralization on the ethereum blockchain for two reason: 1) falling price in fiat currency (less minig reward in fiat currency) 2) asics mining

The first issue is something that could be adjusted by economic incentives (disincentives) given enough time BUT if we are experiencing ( and I think so) a massive switch on asics mining every single day with ethash is very dangerus for the future of the entire project as a truly decentralized blockchain.

In my opinion the ProgPow (or other asic resistant algos) implementation actually is the most important issue by far, even far more the important CostantiNOPEles saga. Please take it in consideration.

[5chdn]

Could you elaborate how you connect uncle rates with ASICs?

[RSAManagement]

@5chdn sure, I know in deep a medium sized mining farm with a good ( i think) efficiency and actually they are in the position to quit ether mining or swich to asics, . I think that the actual reward/difficulty ratio for GPU mining is telling that there are more and more players that are mining with "better" hardware than GPU only and thatthis GPU unconfortable enviorment started with asics arrival on the market, not only because the price drop. I'm sorry because I can't produce in deep analysis with numbers and clearly the actual low ether mining reward for GPU miniers could be just temporary. In my experience Asics are the foundation of big centralized mininig farms, expecialy if there is one or two producers/miners/stakeholders, bitcoin is an example of what I mean.

Big miners are more efficient, they use professional or custom services for transactions and new blocks propagation, I suppose that how the actual uncle rate is dropping is directly related with more centralizzation over big mining farms that are using asics mining.

[5chdn]

Big miners are more efficient

But we would see their hashrate somewhere, and I don't see any significant portion that could be a new ASIC mining farm here:

• https://etherscan.io/stat/miner?range=7&blocktype=blocks
• https://etherscan.io/stat/miner?range=7&blocktype=uncles

If these farms use some of the existing pools, I don't see how this should impact uncle rates.

The five biggest unknown miners from that chart that could be indeed mining farms, accounting for 4.1371% of the network hashrate. This does not allow the conclusion that they are the main driver behind reduced uncle rates.

[RSAManagement]

The five biggest unknown miners from that chart that could be indeed mining farms, accounting for 4.1371% of the network hashrate. This does not allow the conclusion that they are the main driver behind reduced uncle rates.

Good point, so we can speculate that the linear uncle rate reduction is because of: 1) better blocks and transaction propagation because of better propagation services used by mining pools. 2) better blocks and transaction propagation, and faster DB handling because of better nodes topology. 3) less medium sized or little GPU miners

I don't know how many asics farms are connected with pools so I can't give any opinion on it, but in my experience point 3 remain an issue. Anyway I would be really glad to be wrong.

[bmann]

I'm not sure when / where to put this on the agenda, so please let me know if there is a better spot for this,

I worked to support @AlexeyAkhunov in putting together a post-Stanford EthRoadmap AMA on Feb 6th. See https://ethereum-magicians.org/t/eth-roadmap-ama-webinar-feb-6th-8am-pst-1700-utc-1/2518 for details. Consider this a call for participation, I think @AlexeyAkhunov is talking to some of you about presenting.

Given the shifting schedules of Constantinople / Istanbul, is it useful to plan ahead for the rest of the year and start making plans for any in-person meetings? I have suggested an in-person meeting the day after ETHCC in Paris here https://ethereum-magicians.org/t/eth1x-istanbul-prep-meeting/2396

I realize that's only ~6 weeks from now, so tight timing that may not be worth it. If people want to plan further ahead, I'd be happy to help support the process.

[atlanticcrypto]

I'd like to directly refute RSAManagement's claims here.

The uncle rate has been dropping substantially due to pre-fork adoption of new Parity/Geth client versions across the network. It was a blanket rollout of the better block propagation technology over a short window of time. It is not driven by some special "better propagation services used by mining pools" - the competitive technology advantages you believe exist at the large miner level are big foot sightings. You would be embarrassed at the way many of these firms/facilities operate.

I'm not sure how lowered uncle rates is a scary thing - it theoretically increases total network throughput via lowered block times and higher miner reward per block.

[salanki]

I second @atlanticcrypto's experience. I attribute lower uncle rates to better client code and less gas per block than during the peak a year ago.

[AndreaLanfranchi]

I'm quite surprised next agenda does not include any discussion about possible PoW algo change. My personal feeling is that a considerable audience of individual miners is awaiting for a clear statement whether this path will or won't be considered as a future implementation: the no-committal attitude experienced until now is, imho, damaging the image of ethereum. Any statement (for or against) must be quickly achieved: any decision is better than this hanging around. My two cents.

[Daft-Wullie]

I second the opinion expressed by @AndreaLanfranchi in the post above. I personally like ProgPOW but at this point i feel like what most hobbyist miners like me who do it mostly to support the network want more than anything is clarity on this issue. Even if ProgPOW is deemed non viable it should be evaluated in the near future.

[AndreaLanfranchi]

Apparently there is a deliberate intention no to face the matter. Originally ProgPoW topic was in agenda and then silently removed.

[Souptacular]

Some of us already said in the previous meeting that we shouldn't be the ones making the decision because it is political and not technical. I'll add it back so I can potentially outline the 3rd party audit we are organizing.

[Daft-Wullie]

Thanks @Souptacular that is much appreciated altho i don't understand how it is a political decision since the goal and rationale for being asic resistant is enshrined in the ETH Whitepaper. Personally i would not mind a rejection of ProgPoW on technical grounds(lack of testing, diverting too much dev resources, CPU verification taking longer etc) but i'm kinda flabbergasted by how special interests groups are manufacturing a false sense of contentiousness about the end goal of progpow. Still a comprehensive 3rd party audit is a welcome initiative.

[AndreaLanfranchi]

Thank you @Souptacular for your comment. At least we know (now) that some kind of auditing is going on. This, nevertheless, in my very personal opinion, tombstones any value in AllCoreDevs meetings and related streams: they're becoming only a report on the current status on "researches" most people (unless highly skilled) don't understand. I (mistakenly) thought the team had decisional powers (like eg. for issuance reduction) but apparently this matter has greatly involved powerful lobbies. What disturbs me is the lack of clarity and consistency.

Thanks anyway.

[gcolvin]

We seem to have no established social practices for making "political" decisions. From my point of view politics is about coercion. It's what a community resorts to when it can't achieve consensus but doesn't want to "fork".

[AndreaLanfranchi]

@gcolvin Wasn't the issuance reduction a "political" decision ?

[gcolvin]

I felt like a central banker afterwards.

[AndreaLanfranchi]

@gcolvin Like it or not also in this case you will feel uncomfortable. Either you decide in favour, or against or do not decide at all.

[gcolvin]

@AndreaLanfranchi I agree. I understand there were technical reasons for the issuance reduction, but they were beyond my expertise. Unless there are technical reasons to prefer GPUs over ASICs it's a difficult decision for us to make. But someone has to make it.

[AndreaLanfranchi]

@gcolvin

But someone has to make it.

You nailed it ! All I am saying it's a waste of time to delay further. A go or no-go are needed now. An audit process will take months to complete trying to establish fixed points of reference on economies and power balances which are changing day by day, hour by hour. As said elsewhere act NOW (in favour or against) ... do not promise an action will be taken "in future" ... this is no decision at all and keeps miners hung by their fingers to wishful thinking.

[jean-m-cyr]

@gcolvin

But someone has to make it.

Who then? The position EF is taking, that it will only exercise technical influence, seems untenable. Any grouping of more than two individuals will include 'politics'.

[AndreaLanfranchi]

@jean-m-cyr

here is the response https://twitter.com/hudsonjameson/status/1090643066556420096

[salanki]

An audit process by a 3rd party is supported by the community and a good idea. Much like the issuance reduction however the decision to change PoW needs to come from the ETH devs. Decisionmaking can’t be outsourced to a third party.

[holiman]

Decisionmaking can’t be outsourced to a third party.

I agree. I think it's a decision we need to make. We should take in all available signals, discuss until all questions are answered and until people feel they know what they need to know -- but the decision needs to be made, we can't just keep postponing it.

[OhGodAGirl]

One of the things that has been most baffling to me is how we come to consensus in the Ethereum ecosystem. Isn’t the point of mining to vote with your hashpower? If the community does not mine on the ProgPoW chain, they will not support it. They will not switch to it. That’s it. That’s how you let the community vote: you put it in, and the longest chain wins.

Proof-of-work was engineered to put an end to the stress of consensus. You simply let people vote - with their hashpower. ProgPoW could be initiated and application developers simply build on the longest chain.

We’re reinventing consensus mechanisms again.

One GPU. One vote.

Food for thought.

[AndreaLanfranchi]

That would be a chain split. I think we should all try to avoid it

[OhGodAGirl]

The chain splits anyway. Hence a fork. But the longest chain is adopted by the network, and the users and developers keep using and building on that chain.

Ethereum is an ecosystem of developers. It is up to the developers to decide what they support. The users will follow the developers.

[gcolvin]

@cartercarlson

I haven't seen many developers vocally support ProgPow that don't somehow directly or indirectly benefit from it

The discussions I've seen here have had far more to do with centralization, the health of the network, and the original intent of ETHHash. It's not clear that these factors are strong enough to outweigh all the others. The fact that GPU vs. ASIC has financial consequences for miners is part of makes this decision so hard.

Ethereum's end goal is PoS

vs.

1. c) Outlook: PoS finality gadget on PoW chain (Serenity)

Someone please tell me if I'm wrong, but PoW isn't going away any time soon. If it's going away eventually I'd like to know when and how.

[AndreaLanfranchi]

The road to PoS is still long. As correctly reminded PoW isn't going to disappear anytime soon. Due to this PoW must be protected to prevent any dominance by specialized hardware manufacturers cause the power they may gain could be used in future to stop the migration to PoS. Any dominant position, by its nature, fights to keep the status quo

[Sonia-Chen]

An audit can add methodical rigor that is lacking: environmental impact / power consumption, fairness between Nvidia and AMD chips, exclusion of Chinese miners, business motivation of authors (main supporter being CTO of a large farm whose major customer is coingeek), verification slowdown (loss of computational asymmetry), claims of ASIC resistance.

Disclosure: We currently work on an upcoming Ethash machine (launched at ETC Summit), and have conflicts of interest in any PoW discussion. We are happy to contribute our thinking. Strong leadership/governance should take control of this issue and find the best solution with largest community support. We are fairly predictable: We make chips (machines) whenever there is a paying customer, and we think that adds security to the network.

[MoneroCrusher]

With regards to ProgPoW I believe I got a great idea for which I'm crafting an EIP for (if IfDefElse don't support it in their official ProgPoW). I trust that the ProgPow devs know that ProgPow will break all current ASICs.

However there are still two problems:

1. HBM ASICs will very likely resurface
2. Objectively speaking, it will favour Nvidia if we take status quo as baseline that has billions of investments in AMD infrastructure (which is controversial to say the least)

My solution makes

1. Economically less- or even uninteresting
2. Decimate that problem completely

Solution: Take ProgPow and deploy it in a 3-step process which is very easy with its few lines of codes and easy reprogrammability.

1. Introduce ProgPow_v1 ASAP, but only with 10-15% additional core utilization in comparison to Ethash. This will brick all current ASICs and still keep AMD as the majority infrastructure as it currently stands (and how it has been the past 5 years) Also introduce

   PROGPOW_PERIOD: 50 -> 5 or 10
   PROGPOW_CNT_CACHE: 12 -> 11
   PROGPOW_CNT_MATH: 20 -> 18

   And equalize the x3 /x4 difference in 32 bit mul in Nvidia/AMD GPUs with the potential solution suggested by OhGodAGirl, as recognized even by herself, favours Nvidia as it currently stands.

2. In the Istanbul HF introduce ProgPow_v2 but with 25-35% additional core utilization in comparison to Ethash

3. In the HF after Istanbul introduce ProgPow_v3 with the current proposal of core utilization.

Given Ethash's memory hardness, ASICs likely wouldn't get created for the 10-15% batch because they'd have to be taped out & ROI'd until Istanbul HF which is impossible. Likely also not for the 25-35% batch, but with a higher likeliness put into production with the final ProgPow specification, meaning even if ASICs get created, GPUs will have at minimum a full year of better cost-effectiveness than potential ASICs. This slow-ramp up also creates further risk for ASIC producers as they never know for sure how the next (or final) fork really is going to end up (and tweaked). Higher risk of business means smaller chance of ASICs.

Additionally the slow ramp-up in power would allow for farm owners to plan in more power and do their upgrades over time. An overnight increase like ProgPow_v3 does is a strain on many network owners' instrastructures and many people would likely hit or get near their installed power limits. Unfortunately this solution still increases power, but at least newly released devices will get more efficient at solving the same problem. People have time to make hardware adjustments, doing an overnight switch from one architecture to another would cause a rapture in the Ethereum community.

With the laid out plan you will get majority support of the network. In the beginning it will be very much like Ethash, aligning itself with the majority of the current network infrastructure, over time with each fork, GPUs with stronger compute replace the older cards that are now still viable but will not be anymore anyway by the time that will happen, so it's really a win for everyone this way, except for ASIC manufacturers,

[gcolvin]

@OhGodAGirl

Ethereum is an ecosystem of developers. It is up to the developers to decide what they support. The users will follow the developers.

Yes. We generally can't afford to develop multiple versions of multiple clients and let the hashpower decide. So the developers have to decide what to develop somehow. And in the end it's people who decide what to do with their hashpower anyway. It takes a community of developers, users, and more to keep a blockchain up and running, so choosing not to go with what the developers decide is a big risk.

@Linzhi I'd love to have that information. Soon. I'm probably not alone. So failing a full audit, whatever it is you already know or surmise.

@AndreaLanfranchi Yes, PoW must be protected, but I don't think anyone is expert enough in economics and psychology to know for sure what the effects of ASICs now would be on PoS later. But I think we can make a call soon, and change it later if the effects aren't good.

My call would be ProgPoW, and @MoneroCrusher just made it seem easier, but I'd defer to those more knowledgeable. That is, I wouldn't block consensus either way. I'd suggest we take the Yes/No/Over-My-Dead-Body poll tomorrow morning to see how far apart we are before further discussion.

It would be nice if someone else could make the call, but as of now there isn't anyone else. I'd love to see a better way to develop community consensus, but until then we are the dictators, and should try to be benevolent. Refusing to decide is not a viable option.

[AndreaLanfranchi]

@MoneroCrusher agree with all your plan but please stop saying AMD has to be kept the king in ethash mining. The objective of ProgPow is to level all GPUs. If there's a king to be kept then we don't need to do absolutely nothing and keep the status quo. AMD mining will die due to ASICS anyway

[MoneroCrusher]

@AndreaLanfranchi I'm not saying this just like that, but because with a big change like that you want to align with the majority and not the minority of the network, so it goes as smoothly as possible. Check current GPU distribution on Ethos, the most used mining OS amonst hobby miners: http://ethosdistro.com/versions/ It shows AMD is around 70% of the network in this sample.

 101970 Radeon RX 470
  82663 Radeon RX 580
  59013 Radeon RX 570
  25701 P104-100
  21628 P106-100
  19602 GeForce GTX 1060 6GB
  18516 GeForce GTX 1070
  15059 P102-100
  13915 Radeon RX 480
   8828 GeForce GTX 1060 3GB
   7525 GeForce GTX 1050 Ti
etc

I agree that older GPUs will get phased out over time - like I mentioned in my post - but let it happen more naturally and not in one swift move, if you want to have a happy community.

[AndreaLanfranchi]

As I said. We're trying to reduce gap but exactly for the numbers you exposed AMD will keep their position for two reasons. First is numerical, second is the fact that forking out ASICS they will benefit as a consequence even if some Nvidia catch up. There is no loss on AMD due to ProgPow

[MoneroCrusher]

What I'm implying is that going straight for ProgPow_v3 dramatically increases the likelihood of a contentious hardfork. Therefore phase it out like I proposed and let Moore's law make its bid. Everyone would profit from that, including all Nvidia and all AMD miners.

Then you got an even playing field afterwards and you know what you'll have to expect with each new HF and you get time to make your hardware adjustments and planning over a span of approximately 2-3 years. ProgPow does not offer that ability to the average Joe miner. A phased-out ProgPow would.

[AndreaLanfranchi]

We don't have 2 or 3 years of PoW on eth. Maybe 1 and a half

[AndreaLanfranchi]

Anyway I'm not pushing for this technicalities. What I would like to see is a go or no-go now

[gcolvin]

@AndreaLanfranchi

We don't have 2 or 3 years of PoW on eth. Maybe 1 and a half

What do mean? That PoW will stop working if we don't do something?

[AndreaLanfranchi]

I mean that as soon as Casper has a definitive schedule then difficulty bomb will trigger anyway and will ice any PoW algorithm still in place

[MoneroCrusher]

1. We don't know that. Personally I believe we won't be on PoS in 12 months to 18 months.
2. Assuming it does get implemented within 12-18 months and if the EF and ETH core devs are environmentally conscious, then a simpler fork that bricks current ASICs would be the correct solution in that case and that doesn't unnecessarily waste 5256-7848 GW/h (that's a mid sized nuclear power plant running on full steam for 200-300 days, https://en.wikipedia.org/wiki/Clinton_Power_Station) because ASICs won't re-takeover the network en-masse given the current market circumstances, implying a "hardcore" solution like ProgPow_v3 (+50-60% power) would not be necessary for such a short period. But of course 5256-7848 GW/h wouldn't just appear out of thin air, what ProgPow_v3 coupled with the imminent reward reduction would do is instantly centralize all hashing power into the hands of dozen-Megawatt farms with plenty of cheap electricity that your average Joe miner doesn't have.

Anyways, I still stand with ProgPoW + V1-V2-V3 phase out plan, as it's technically easily feasible and GPUs get more efficient over time (just look at the 7nm Radeon 7) and even if PoS gets implemented within 12-18 months, then so be it, the two do not contradict eachother and it doesn't negatively affect any GPU miner. Additionally it gives everyone time to plan things out should PoS take longer than the 12-18 months, and not leave everyone behind except for corporations that have dozen-Megawatt installations.

The only people that I think would be against this would be people that got all excited for their Nvidia GPUs being instant-hash-kings on the originally proposed ProgPow. The grand majority of GPU owners would favour a phase-out. So in that sense, go with the flow.

[gcolvin]

I'm ignorant, @AndreaLanfranchi but if the PoW chain is iced what is the point of staking ETH on it?

[AndreaLanfranchi]

Sorry @MoneroCrusher but I can't stand all this Nvidia/AMD debate anymore. You don't understand there will be no king at all if no action is taken.

[MoneroCrusher]

I didn't say to take no action. I say take action and implemented ProgPow in a reasonable 3-step phase-out that is technically very easily achievable and also reaches the same goal but will get overwhelming community support and will therefore be much easier implemented than plain vanilla ProgPow - governance & political wise.

This is the most sensible and fair approach to all parties. And I spent a lot of time thinking about this lately and how to come up with a solution that will please all parties except for ASIC manufacturers. This is it.

[AndreaLanfranchi]

@gcolvin this is the plan to force migration to Ethereum 2.0

[AndreaLanfranchi]

@MoneroCrusher You won't get any overwhelming support from the community of miners as long as they're focused on fight each other without understanding the enemy is elsewhere. They're already dying and only care about the fact AMD is more or less penalized. This is kind of palm face

[MoneroCrusher]

@AndreaLanfranchi My proposed solution is vendor neutral. Please re-read my posts if that doesn't crystallize.

[gcolvin]

@AndreaLanfranchi

this is the plan to force migration to Ethereum 2.0

I'm ignorant. What is the plan? Last I checked (two minutes) the beacon chain depends on the 1.0 chain. You have to stake ETH on it to become a validator. If 1.0 is iced how can you stake and what do you have at stake?