ethereum/pm

Ethereum Core Devs Meeting 43 Agenda

lrettig opened this issue · 18 comments

lrettig commented

Ethereum Core Devs Meeting 43 Agenda

Meeting Date/Time: Friday 07/27/18 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

  1. Testing
  2. Client Updates
  3. Research Updates
  4. Four competing EIPs to delay the difficulty bomb and/or reduce the block reward:
    a. EIP-858 - Reduce block reward to 1 ETH per block.
    b. EIP-1227 - Delay bomb and change rewards to 5 ETH.
    c. EIP-1234 - Delay bomb and change rewards to 2 ETH.
    d. EIP-1240 - Remove the difficulty bomb entirely.
  5. Constantinople hard fork timing and what to include (continuing conversation from last call).
    a. EIP 145: Bitwise shifting instructions in EVM: pretty well-formed, but not 100% implemented or tested.
    b. EIP 210: Blockhash refactoring.
    d. EIP 1052: EXTCODEHASH Opcode.
    e. EIP 1087: Net gas metering for SSTORE operations.
    f. EIP 1014: Skinny CREATE2.
  6. Potentially lowering the cost of pre-compiles (bnAdd?, bnMul?)
  7. Fellowship of Ethereum Magicians Update
5chdn commented

4.a: Parity-Ethereum implemented EIP-145,1052
4.g: There are two three four competing proposals:

5: might be worth to have a quick "FEM Updates" after the Berlin gathering on the agenda. /cc @bmann

chfast commented

4.b: aleth has the implementation of EIP-145.
4.d: The draft of EIP-1052 has been updated. Because of the REVERT, there are a lot of edge cases to test (but not more than in EXTCODESIZE). Discussion: the spec differentiate empty and non-existing accounts.
4.f: Implementation in aleth accepted (ethereum/aleth#5121). Discuss option 2 of the spec. Small tweak to the spec: ethereum/EIPs#1247.

karalabe commented

Geth status:

Missing:

  • EIP 210 blockhash
bmann commented

FEM Updates: I will try and make it, if @gcolvin or @jpitts or @ligi usually attends they can pipe up.

This is the link to the big wrap up https://ethereum-magicians.org/t/council-of-berlin-wrap-up-request-for-feedback/847

I'd say the creation of Rings as a way to cluster around topics, and gather interested & experts who can help "scale" quality EIPs is a thing to mention.

And that Core Devs should set aside time ahead of Devcon4 to join the Council of Prague.

holgerd77 commented

EthereumJS

We have now a first release series v2.4.x out where we introduced partial support for Constantinople (bitwise shifting instructions, EIP 145), see the according announcement post on Reddit.

Work on other EIPs hasn't started yet though. I will make a follow-up Reddit call for participation tomorrow, since we currently don't have the people power to implement all ourself.

If anyone is interested in helping head over to our VM repository. I'll also write up issues tomorrow on the Constantinople EIPs with some instructions on where to start.

holiman commented

If there's time, I'd like to talk again about lowering costs for precompiles, gauge the interest and feasibility of doing so

holiman commented

And which ones (bnAdd, bnMul?)

barryWhiteHat commented

I build miximus and semaphore both of which will use the ec verification. Currently this costs ~2.5 USD which is quite expensive. There are some optimizations I can do such as using Groth16 but reducing the op code price is still the biggest reduce in this cost that is available.

Rough Data:
With groth16 we're down to 560k gas
With EIP 1187, we'd be down to 230k
With EIP 1108, we'd be down to 108k

There is some problems with the current curve altbn128 which can have its security reduced to ~110 bits using a number sive optimization so zcash is moing to a new curve which i would like to follow them to because of

  1. It brings security back to 128 bits.
  2. I can reuse other zcash tools like bellman easily.
  3. I can use the jub jub curve that they embedded to make pedersen commitments. Which will reduce the proving requiremtns from 7 mintues (currently, tho with optimizations i can get to 40 seconds but requires a few GB of RAM) to 7 seconds (40 mb of memory)
  4. I can use jubjub to make a signature scheme that is varifiable inside a snark. Which would allow me to batch transactions together and do some really cool scaling stuff.

I raised the idea of adding BLS12-381 privately with some core devs and their opinions were to wait for EWASM. I can still do 3 and 4 in the current curve but i lose on the benefit of using zcash's and already quite well reviewed work.

TL;DR

  1. Update gas prices for EC OPs as EIP 1187 EIP 1108 is definitely a good idea with very little downside.
  2. BLS12-381 would be nice but if not its not the end of the world. And i will just follow them with EWASM.
  • 👍1
barryWhiteHat commented

WIth miximus we need to pay for gas without breaking anonymity. We attempt this by defineing layer2 trasnaction abstraction an update on the plans for layer1 transaction abstraction would be interesting. Is it dead? Or is it still on the road map.

  • 👍1
HarryR commented

I have been trying to use the pairing operator to implement things like BLS signatures, Bilinear Accumulators etc. however the way the opcode is implemented in EVM means that almost none of the popular research papers on pairings can be implemented as-is without a lot of new work which essentially discards many of the security proofs.

e.g. pairing opcode is e(A,B) * ... * e(C,D) = 1 - so I cannot implement BLS signatures or any scheme which directly checks the equality of two points on GT after a pairing.

I've found other methods of turning an equality check of two GT points into an equation supported by the EVM pairing opcode, however in most of the obvious cases I thought of it makes it very easy to forge proofs and isn't secure - without using multiple sets of pairing checks to ensure the arguments don't cancel each other out etc. (but that increases the cost significantly).

  • 👍3
axic commented

I raised the idea of adding BLS12-381 privately with some core devs and their opinions were to wait for EWASM.

@barryWhiteHat that is already in prototype stage for ewasm: ewasm/ewasm-precompiles#2

barryWhiteHat commented

@axic I don't want to build on something when i don't know how far it is out. My understanding is that all shards will be ewasm which for me is too long to wait.

holiman commented

I'm not for increasing the reward. I am tentatively for decreasing it, in line with EIP 1234. Would be curious to hear arguments against decreasing it. Also, if there is any background material on the profitability of different chains, I'd like to know a bit about that. Where does Ethereum mining stand, on the profitability spectrum, compared to other projects?

MicahZoltu commented

The higher the mining reward, the more expensive it is to double spend with less than 50% hashing power. If you assume no single actor controls 50% of hashing power then higher mining rewards translates to fewer confirmations needed to secure (economically) a transaction since the number confirmations required for strong economic guarantees of finality is a function of total value transferred per second and miner reward per second (including fees).

A chain with little value transfer per second has significantly less need for hashing power than a chain with more value transfer per second, so I think comparing chains is not a useful measure here.

What would be a useful measure is an idea of how much value is transferred per second on Ethereum, since this dictates how much money an attacker can make via a double spend attempt.

Unfortunately, this is very hard to compute for Ethereum due to contracts having non-eth value transfers. Also, the above analysis ignores attackers with greater than 50% hashing power, which is a bigger problem with small chains.

CamQuatman commented

With today's current profitability, a miner buying a brand new GPU will likely take ~1.5 years to pay off. ASIC's have entered the market, if purchased today it would take ~.5 years to pay off. That is to say that the current price, reward per block, difficulty, block time, and network hashrate do not change. Even with current delays to POS, I would and have advised someone not to purchase any mining equipment due to issues with profitability. By decreasing the rewards per block without lowering block times and difficulty, you will have effectively cut of GPU mining in favor of ASIC. Furthermore, operation costs maybe become to high, GPU's will be turned off first due to the higher operating costs and network hashrate will drop, again favoring ASIC.

lrettig commented

Closing in favor of #52

lrettig commented

@MicahZoltu @holiman this analysis that @djrtwo posted may partially answer your questions: https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a

Let's take this discussion to one of the Discourse forums.