Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ethereum Core Devs Meeting 31 Agenda #29

Closed
Souptacular opened this issue Dec 16, 2017 · 13 comments
Closed

Ethereum Core Devs Meeting 31 Agenda #29

Souptacular opened this issue Dec 16, 2017 · 13 comments

Comments

@Souptacular
Copy link
Contributor

Souptacular commented Dec 16, 2017

Ethereum Core Devs Meeting 31 Agenda

Meeting Date/Time: Friday 01/12/18 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

  1. Testing updates.
  2. Yellow paper update.
  3. EWASM update + update on the following related EIPs.
    a. EVM 2.0 - EVM 2/wasm 105 EIPs#48
    b. Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN - Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN EIPs#174
    c. Subroutines and Static Jumps for the EVM - EIP-615: Subroutines and Static Jumps for the EVM EIPs#615
  4. Stateless client development.
  5. Add ECADD and ECMUL precompiles for secp256k1 - Add ECADD and ECMUL precompiles for secp256k1 EIPs#603 [See this blog post for context].
  6. Introduce miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined).
  7. Creating a relay network of nodes to mitigate issues described here and other transaction propagation issues.
  8. Fork release management/Constantinople.
  9. Client updates.
  10. Client improvements to alleviate issues.

Please provide comments to add or correct agenda topics.

@Buttaa
Copy link

Buttaa commented Dec 18, 2017

since it is a month from now ... updates on Constantinopel?

@5chdn
Copy link
Contributor

5chdn commented Dec 18, 2017

since it is a month from now ... updates on Constantinople?

Yes, this meeting will be 3 months after Byzantium, and it would be sweet talk about Fork Release Management again. We discussed earlier that we don't want to start too late talking about EIPs.

@RSAManagement
Copy link

RSAManagement commented Dec 24, 2017

In the short term the main issue is if and how is it possible to improve the ethereum database in order to try a bigger max gas limit per block without getting so much uncle blocks. I suggest to continue to discuss this topic until tests will be fully performed and eventually solutions will be founded.

@Crypto247365
Copy link

Crypto247365 commented Dec 31, 2017

I have been getting a lot of inquiries from my Crypto-community about the POW to POS change with Ethereum. The miners are the most concerned. Could you elaborate on this change, will it happen, when, and why? Several have considered selling their cards now to prevent getting caught in any flood when the change happens.

It will be a gradual swap right?

@coinaisseur
Copy link

I agree with @RSAManagement point. Ethereum network is clogged again, and a short term fix is necessary while Constantinople is implemented

@B5m3M
Copy link

B5m3M commented Jan 5, 2018

I'd like to hear you guys talk a bit about...

  1. The Stateless Client Development
  2. WASM with regard to
    EVM 2/wasm 105 EIPs#48
    Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN EIPs#174
    EIP-615: Subroutines and Static Jumps for the EVM EIPs#615
    (Maybe Christian has some insight into that)
  3. Decision Process on EIPs

Thank you for this open discussion and ethresear.ch so we can participate and get involved.

Edit: Sorry, I referenced the EIPs
Edit 2: After the live stream - Thank you so much guys for discussing this topic - Helped a lot.

@shapeshed
Copy link

shapeshed commented Jan 5, 2018

I'd like to hear you talk about ethereum/EIPs#603
Our opinion is that privacy on Ethereum is too expensive.

We've developed a ring signature privacy solution in Mobius

With a ring size of 4 it costs 600k gas to Deposit and 3 million Gas to Withdraw, given that the block Gas limit on Ethereum is 3,141,592 (π million) this would have to be spread across multiple blocks and could significantly disrupt other transactions (similar to CryptoKitties) if any privacy technology gained significant popularity.

@AlexeyAkhunov
Copy link
Contributor

to the agenda - introducing miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined)

@RSAManagement
Copy link

Hallo I find this very interesting discussion on reddit:
https://www.reddit.com/r/ethereum/comments/7pfshh/why_is_8m_gas_causing_so_many_uncles/?st=jcal6fxo&sh=2b52fb4e
It seems that the 2 most important miners pool do generate 51,8% of the blocks and only 12% of the uncles.
There could be 2 reasons:

  1. big pool have better hardware/node setups
  2. big pool have better propagation route for the blocks they mined

The first issue is already in disucussion, the second issue could be mitigate by a sort of worldwide ethereum relay network. A proper set of high performance, widely interconnected nodes.

We know that the foundation set some bounties to boost some specific scaling methods for ethereum, I do think that build an high performance ethereum relay network could be very helpful to small miners with the final scope is to mantain decentralization. So I propose to set up similar bounties to run one or more relay network and to research how to build the better possible network in term of costs and efficency.

@pipermerriam
Copy link
Member

pipermerriam commented Jan 11, 2018

It's questionable whether I'll be able to directly participate in the meeting (though I'll be attempting to listen in). My updates for python-land.

  • Implementation of full node sync in py-evm is underway.
  • Initial foundation for running py-evm as a stateless client.
  • Implementation of simplified Ethereum Gas Station pricing algorithm in progress for web3.py.
  • Preparation for alpha release of the py-evm based client.

I assume someone from the research team may give an update on sharding with more details, but sharding research and development continues.

@AlexeyAkhunov
Copy link
Contributor

AlexeyAkhunov commented Jan 11, 2018

@RSAManagement I suspect those two big miners simply connected their nodes directly using "addPeer", so they propagate new blocks directly to each other.

I would generally oppose encouraging specialised relay networks, because the end effect would be that the network will be more like a concentrated ring of miners and periphery, rather than more like a mesh now. And that would be bad for small independent miners, because if they are not part of the club (or ring), they end up on the periphery, and their blocks are more likely to be uncle-d.

I think it is absolutely urgent to improve the propagation speed every time we see congestion like this, so that the miners have no incentive creating such a ring-relay network. The longer we keep the network a mesh, the healthier ecosystem we will get

@GriffGreen
Copy link

  1. There have been major issues with transaction propagation out of node with high throughput (infura, Bittrex, etc) I would love to hear if any one has any insight on what could be causing this. See this tweet as one example, but this has been an on going issue over the past month.

Also

  1. Updates on scaling, will we see any scaling improvement from Constantanople? Are there going to be any improvements because of CasperFFG? (I expect not in either case but worth asking) I know Plasma and Sharding are far from being implemented.. but would love to hear guesses (best case, worst case) on time frame for any scaling improvements. Many dapp devs have come to the conclusion that the main chain is not able to host their DApp because of gas costs. We are looking to build sidechain solutions to bide our time until we see some further improvements here, but would love to hear your input.

@Silur
Copy link

Silur commented Jan 12, 2018

ruffct/stringct implementation I mentioned during the meeting, the paper is still WIP but the implementation follows our latest work: https://github.com/monero-project/research-lab/tree/master/source-code/StringCT-java

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests