Ethereum Core Devs Meeting 105 Agenda

[timbeiko]

Ethereum Core Devs Meeting 105 Agenda

• Meeting Date/Time: Friday 5 February 2021, 14:00 UTC.
• Meeting Duration 1.5 hours
• YouTube Live Stream: https://youtu.be/ju92hAKzKcg

Agenda

1. YOLOv3 & Berlin client updates
   1. Goerli & other testnet block proposals
2. Finalize eth/66 specification
3. Other EIPs or discussion items
   1. EVM 384 Update
   2. 1559 Performance Tests Update
   3. ACD Feedback

Next Call: February 19, 2021 14:00 UTC

[CryptoBlockchainTechnologies]

Please add discussion of EIP-1057 implementation to the agenda if @gcolvin @anlan @bitsbetrippin will be available to discuss implementation. I have started a discussion at magicians here: https://ethereum-magicians.org/t/eip-1057-break-glass-moment-is-here/5255

[Souptacular]

@CryptoBlockchainTechnologies We have had many meetings relating to ProgPoW and there has been multiple complaints about it taking up time on the core dev calls. Berlin is coming up and that is more important than ProgPoW talk, especially in light of the fact that there appears to be primarily speculation and no immediate threat (such as an attack actively happening). I would be happy to re-add it to the agenda if you can provide better data pointing to the fact that there is an immediate threat or if there are calls from a client team to bring this up again and they would like to address it.

[greerso]

no immediate threat (such as an attack actively happening). I would be happy to re-add it to the agenda if you can provide better data pointing to the fact that there is an immediate threat

Has there ever been any clarity on what a 'threat' or 'attack' looks like? Centralization of hash due to efficient miners only sold privately to enterprise doesn't seem to be considered a threat as long as it is done in secret? If it cannot be proven, it is not happneing?

[catdsnny]

Hi guys,

I'm going to be 100% transparent, which I think alot of all of you should also do. I'm a miner. I make about 10% of my active income from mining. I've invested hundreds of thousands of USD in mining. When you are posting in reddit or github or discord I hope you will disclose your DeFi affiliations and biases.

1 - You need to publish what the impact of 1559 is. There's too much anxiety. I'm working to force a fork with miners.

2 - Please read this : https://gulovsen.io/proof-of-security/
You need to very seriously consider what 2.0, POS and the "internet bond" means in terms of United States securities laws. This is no joke. You are going to destroy ETH as we know it.

I look forward to speaking with all of you on this open source project call.

Thanks,
Shaun

[timbeiko]

@catdsnny re: 1559, it is not scheduled for discussion on the call. What do you mean by "impact of 1559"? We have a full list of resources available here, many of which discuss the technical, economic, and mining impacts.

re: (2), I'm not sure legal matters have ever been discussed on this car, which is focused on the technical updates to Ethereum. IANAL, nor is anyone on the call, so it does not feel like the best venue to have a productive discussion about this. Also, FWIW, the article you shared is focused on Ethereum 2.0, which is out of scope for this call and is already live.

More generally, we try to keep this call civil and level-headed. Things like implying "DeFi affiliations", "working to force a fork" and "You are going to destroy ETH" are needlessly inflammatory and don't help move forward the conversations around the various topics you are concerned about.

[CryptoBlockchainTechnologies]

@Souptacular @timbeiko @gcolvin @anlan @bitsbetrippin Here is some additional data showing ASICs are now actively ingaging in a network attack RIGHT NOW.

F2Pool is known for hosting the majority of ASICs. This is about the best proof we have that ASICs are a threat to the network. Unfortunately the devs still only think in terms of 51% attack instead of an attack like this that goes unnoticed.

This article is 2 years old, but it is worse today and I have posted an updated chart on Magicians.

https://t.co/pkuSnEnug2?amp=1

[recmo]

I did an investigation into empty blocks recently and my conclusion was that it is miner software switching tactics from mining uncles to mining empty blocks when the header is received but unprocessed. The net effect on daily gas processing of this switch is negligible. I found no evidence that some miners disproportionately produce empty blocks or that anything malicious is going on.

[catdsnny]

Hi Remco, do you have the underlying analysis, source or references? I see a few lovely graphs but no reference to where they came from or how they were assembled. I'm not questioning your work, which seems quite thorough, I'm interested in the methodology of detecting/attributing empty blocks. Thanks!
-Shaun

[recmo]

All graphs are original work, made by pulling all blocks and transaction from a Geth full node I run on an AWS server, so data is straight from the chain. Data was analyzed using a Jupyter notebook with numpy/pandas/matplotlib. No processing was done on the data other than applying moving averages. I've indicated in the axis labels what averageing was applied.

The only non-trivial bit was attributing blocks to mining pools. Here I used the extraData field and the assumption that a given address belongs to only one miner (some miners left out/changed extraData field on occasion while keeping address).

[CryptoBlockchainTechnologies]

All graphs are original work, made by pulling all blocks and transaction from a Geth full node I run on an AWS server, so data is straight from the chain. Data was analyzed using a Jupyter notebook with numpy/pandas/matplotlib. No processing was done on the data other than applying moving averages. I've indicated in the axis labels what averageing was applied.

The only non-trivial bit was attributing blocks to mining pools. Here I used the extraData field and the assumption that a given address belongs to only one miner (some miners left out/changed extraData field on occasion while keeping address).

Is it possible you can extrapolate from the data the nonce pattern to show if these are ASICs mining empty blocks? Below is an excerpt how CoinMetrics was able to determine there were 40% ASICs on the network two years ago.

"Minehan also pointed out a forthcoming study from CoinMetrics on so-called nonce patterns in ethereum mining. In crypto mining, machines look for a nonce, or a specific golden number, to create a block and receive a coin reward. In some situations, you can tell what portion of a network is running a certain model of mining rig depending on the nonce patterns guessed by the machines."

Here is an application for XMR to show nonce distribution. https://github.com/noncesense-research-lab/nonce_distribution/tree/master/liveviz

In 2019 Etherchain.org was used to plot the ASIC nonce distribution but looks like it was taken down:

Peter (bitfly) @peterbitfly Oct 20 2019 12:37
here you go https://www.etherchain.org/charts/noncewatch
last 1M blocks only, the chart lib has issues plotting more data

It would be also beneficial if someone could run a new study showing the amount of ASICs currently on the network.

[poemm]

I would like to give an update on EVM384, time permitting.

Relevant links:

• The Ewasm team published EVM384 update 5: https://notes.ethereum.org/@poemm/evm384-update5
• I published a some EVM-specific optimizations: https://ethresear.ch/t/surveying-precomputation-methods-in-cryptography-request-for-help/8606

[timbeiko]

@recmo thanks for sharing! It may be best to post that comment and continue the conversation with @CryptoBlockchainTechnologies elsewhere (EthMagicians?), because these issues get closed after each call.

[timbeiko]

@poemm added 👍

[timbeiko]

I can give a quick update on some of our preliminary 1559 performance tests using the large state testnet. Preliminary results here: https://hackmd.io/@timbeiko/1559-prelim-perf

[timbeiko]

Over the past few weeks, I've collected feedback from core developers about what they like/dislike/would want to see in AllCoreDevs. I've compiled it here: https://hackmd.io/@timbeiko/acd-feedback

A few people agreed on discord it would make sense to bring this up on the call. IMO the three most relevant things to discuss are (quoted from the doc):

1. As Berlin gets wrapped up, have 1-2 calls to discuss the Eth2 Merge and longer-term roadmap before starting to plan the next HF;
2. Instead of having only the next call’s agenda available, open the next ~3 months’ agendas in advance. Schedule “important but not urgent” topics in advance, and identify calls on which we expect decisions to be made, so people can attend what matters the most to them.
3. Discuss the following on ACD:
   1. The “bar” we require to discuss EIPs on the call, both for the first time, and repeat;
   2. ACD Code of Conduct (“Be Excellent to Each Other”?)
   3. ACD “Mission Statement” (“Ensure the Security & Long Term Sustainability/Viability/??? of Ethereum”?)

They are ordered by "easiest to get consensus on" to "hardest to get consensus on" 😅

[q9f]

Depending on the Yolo v3 outcomes, I would like to propose a block number for Goerli Testnet 4540000 (Mar/31) for Berlin (or not).

[shamatar]

I can indirectly support Remco's result I think. Some time ago I made a simples script to look at the blocks and found that over 100k block window there hold a relationship like block_size/GAS_PER_SECOND_CONSTANT / block_time ~ percent_of_empty_blocks, that means that probability that the empty block is mined roughly follows an expected value for a Poisson process

[q9f]

Depending on the Yolo v3 outcomes, I would like to propose a block number for Goerli Testnet 4540000 (Mar/31) for Berlin (or not).

moved to feb/23 according to discord (missed the call due to traffic sorry)

ethereum/execution-specs#14

edit: ropsten? ethereum/ropsten#38

[timbeiko]

Closing. Agendas are now at https://github.com/ethereum/pm#agendas

[holgerd77]

@q9f just for clarification, since I now stumbled twice upon the date you mentioned: is this feb/23 or mar/23?

[holgerd77]

@q9f Update: i did some basic estimation based on the block number difference from 4540000 to 4333333, this would be (~200000 Blocks)*15/60/60/24 ~= 35 days, so this would really point to your feb/23 date.

Assuming this is correct: this is already in one week? Is this information still up-to-date? I can't imagine how this would work right now.

[q9f]

No. The discussion was continued on Discord.

Scenario A: Berlin Mainnet March Rollout

• Ropsten: Feb/24, TimeRemaining 1045200s, CurrentBlock 9_648_023, BlockTime 13.8s, TargetForkBlock 9_723_762 (est.)
• Goerli: Feb/24, TimeRemaining 1045200s, CurrentBlock 4_269_595, BlockTime 15.0s, TargetForkBlock 4_339_275 (est.)
• Rinkeby: Feb/24, TimeRemaining 1045200s, CurrentBlock 8_059_600, BlockTime 15.0s, TargetForkBlock 8_129_280 (est.)
• Kovan: Feb/24, TimeRemaining 1045200s, CurrentBlock 23_434_222, BlockTime 5.3s, TargetForkBlock 23_631_429 (est.)
• (5 weeks buffer)
• Mainnet: Mar/31, TimeRemaining 4072740s, CurrentBlock 11_841_026, BlockTime 13.1s, TargetForkBlock 12_151_922 (est.)

Scenario B: Berlin Staged Testnet Rollout

• Ropsten: Feb/24, TimeRemaining 1045200s, CurrentBlock 9_648_023, BlockTime 13.8s, TargetForkBlock 9_723_762 (est.)
• Goerli: Mar/03, TimeRemaining 1649940s, CurrentBlock 4_269_595, BlockTime 15.0s, TargetForkBlock 4_379_591 (est.)
• Rinkeby: Mar/10, TimeRemaining 2254680s, CurrentBlock 8_059_600, BlockTime 15.0s, TargetForkBlock 8_209_912 (est.)
• Kovan: Mar/17, TimeRemaining 2859480s, CurrentBlock 23_434_222, BlockTime 5.3s, TargetForkBlock 23_973_746 (est.)
• (6 weeks buffer)
• Mainnet: Apr/21, TimeRemaining 5887020s, CurrentBlock 11_841_026, BlockTime 13.1s, TargetForkBlock 12_290_416 (est.)

But since nobody committed to this timeline, we are looking at a May rollout slowly but surely.

Edit: #248

[holgerd77]

@q9f thanks for the update, yes, makes very much sense to open a dedicated issue for this.