Ethereum Core Devs Meeting 30 Agenda

[Souptacular]

Ethereum Core Devs Meeting 30 Agenda

Meeting Date/Time: Friday 12/15/17 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates.
2. Digital cats caused network congestion this month. Meow.
   a. Why did this happen and what solutions are available to prevent future network congestion? See comments below for some ideas.
   b. Stateless Clients proposal.
   c. Would having minimum system requirements to set up an optimal client/full node help?
   d. Is the bottleneck is not just disk bandwidth, but specifically sequential disk bandwidth?
   e. Vitalik has some ideas around gas cost changes and scalability-relevant client optimizations.
3. Plans on Quantum-resistant cryptography and any plans to include it in the next update?
4. Introduction to K-EVM team (Everett H.)
5. Does it remain the case that the Yellow Paper is intended to be Ethereum's formal specification?

Time permitting:
6. Parity stuck ether proposals.
7. POA Testnet unification [Update]
8. Core team updates.

Please provide comments to add or correct agenda topics.

[5chdn]

Shall we talk about transaction backlogs?

Just some random thoughts.

• Shouldn't the block gas limit go up at this consistently high transaction load?

• Is there anything short-term we can do? Like recommending higher gas limits? Is it even safe to recommend higher block gas limits? If yes, what would be a reasonable limit?

• Is there anything we can do to improve applications like crypto-kitties to use less gas, or anything else to relax the situation? Did anyone look into options yet?

[ethernian]

Is there anything short-term we can do?

Just a mid-term raw idea (not perfect, I know):
We could limit gas usage (or increase min gas price specifically for heavy contracts) per contract group (contracts with the same codebase) if network becomes overloaded. A contract deployer can't easily overcome this restriction by delivering many slightly altered contracts with another codebase, because this bunch of different contracts could not be so easily trusted and accepted as the single one. Such "loadbalancing" is in tradeoff to acceptance.

[v1thesource]

With Cryptokitties making up >10% of all tx's currently (https://ethgasstation.info/gasguzzlers.php), the best medium-term solution may be helping them implement a payment channel mechanism. Uncles / total blocks per day is around 21%, which is not disastrous, but is only aggravated by a gas limit increase. If the gas limit is increased, we'd have to tell everyone to wait for more block confirmations per tx to make sure they get on the right chain.

Crazy idea, but at this point it may be worth looking at increasing the target time per block from ~15s. Users will have to wait for multiple confirmations anyway with the current increasing uncle rate, at least with a higher block time interval we can increase the gas limit with a reduced effect on uncle rate.

[esques]

@dip239 while I see the first part of the idea, the second part "contracts must be audited" is easly circumvented by adding harmless nonsense functions. And it would be lead to batteries of loadbalancer contracts anyway.

[AlexeyAkhunov]

I would like to bring up the Stateless Clients proposal, as I described here: https://medium.com/@akhounov/how-to-speed-up-ethereum-in-the-face-of-crypto-kitties-7a9c901d98e9

I am collecting more data now about how much impact it can make, and what is the overhead, hopefully can present something very briefly

[ethernian]

part "contracts must be audited" is easly circumvented by adding harmless nonsense functions

My idea is not perfect, I agree, it is more the way of thinking about the problem: I am just trying to punisch an excessive gas consumption by target contracts instead of gas provisioning by transactions.

Nevertheless my point was, that "loadbalancing" will not working "for free": a careful user needs to trust N contracts instead of single one if their codebase is not identical. Personally I wouldn't trust a bunch of loadbalancing contracts with "almost" the same code: too much to check every single one.
But CryptoKitty players possibly do not care about contracts they trust at all.

[coinaisseur]

Whatever solution we adopt, we can all agree that this is an emergency situation that must be solved short term. With the 'accidental' success of CryptoKitties, we can assume there are a bunch of developers coding Ethereum dApps right now as I write this message, so this transaction backlog will only get worse from now.

[ethernian]

Thought more:
... there should be some "central contract" behind the "loadbalancer", coordinating the whole application. We could sum all gas burned in all transactions going through this "central contract" in some time frame (TxGasBurningRate for this contract). If the network is currently overloaded AND some contract is involved into excessive gas burning, all transactions going throw it should be deincentivized by higher gas price.

further discussion is moved to ethereum/research

Might be missing something obvious here: Why do we have a static blocktime target, variable gas limits, and (a more abstract) acceptable uncle rate (which is actually variable). Why isn't the blocktime target also variable in order to target a more well defined/specified uncle rate target? (or uncle/time rate to keep it fair for miners)

[vbuterin]

Why isn't the blocktime target also variable in order to target a more well defined/specified uncle rate target?

The blocktime target is flexible as of Byzantium, to keep total rewards roughly constant. See it rising slightly here: https://etherscan.io/chart/blocktime

I personally oppose further blocktime increases. The contribution of the fast blocktime to the total uncle rate is relatively small, and furthermore it's ADDITIVE, not multiplicative, with contribution to uncle rate from capacity. That is:

uncle_rate ~= k1 / blocktime + k2 * gas_per_sec

This is confirmed with bitcoin in Decker and Wattenhofer's 2013 paper, and experience suggests the same is true with ethereum. Right now it's the second term in the sum that is the problem, not the first.

IMO we should consider a few optimizations:

• Do another round of increasing gas costs on account-accessing opcodes (BALANCE, EXTCODESIZE, etc), and SLOAD, as that's still our major weak point from the PoV of DoS resistance. I'd recommend SLOAD -> 320, BALANCE -> 800, EXTCODESIZE/CALL/CALLCODE/DELEGATECALL/.... -> 1200. But we should add an exception, that self-calls and calls to precompiles cost only 100.
• Some variant of Kill dust accounts EIPs#168 and Dust account replay security EIPs#169 to alleviate state size growth
• Increase the cost of sending a tx by 30000 if it goes to a currently empty account

I also totally support the idea of stateless clients. Right now it actually already is possible to implement without any core protocol changes, as long as miners are stateful. There's also the possibility of a "stateless partially full node" - be a light node by default, but fully (statelessly) verify specific blocks if a trusted server tells you that they're invalid. This gives the security model that you won't accept an invalid block unless BOTH (i) there is an active 51% attack, and (ii) all trusted servers you're connecting to are colluding.

Also, it would make sense to have a much more coordinated benchmarking effort, so we can see what opcodes are currently the slowest, and what can be done to improve their execution speed.

Finally, we should have a poll on where we are at for key scalability-relevant client optimizations. This includes:

• Garbage collection
• On-disk state caching
• State tree pruning
• Network compression
• Database optimization

[tejasriram]

I would like to hear about the Ethereum team's plans on Quantum-resistant cryptography and any plans to include it in the next update?

[RSAManagement]

Hallo, I would like the foundation to recommend the minimum system requirements to set up an optimal client/full node. This is probably a basic step to mitigate a bit the uncle rate problem, it seem that the hard drive is one of the most important bottleneck given the high number of I/O calls to the database.
https://medium.com/@akhounov/how-to-speed-up-ethereum-in-the-face-of-crypto-kitties-7a9c901d98e9

[vbuterin]

I would like to hear about the Ethereum team's plans on Quantum-resistant cryptography and any plans to include it in the next update?

Properly incorporating this requires account abstraction, which is going into the sharding spec; I don't think there is yet consensus on how/when it's going into the main chain. Abstraction will also be available for Casper validators.

[vbuterin]

See my comment on stateless client numbers here:

https://medium.com/@VitalikButerin/regarding-bandwidth-requirements-for-stateless-clients-i-can-give-some-precise-numbers-be357fb69b6d

[vbuterin]

I do have a question that I'd like to hear answered as well as possible.

It seems to me that the bottleneck is not just disk bandwidth, but specifically sequential disk bandwidth. That is, for example, if we somehow magically knew ahead of time what state tree nodes need to be accessed, and we could make the accesses happen in parallel, then processing speed could be increased greatly.

First, is this true? That is, is it the case that loading 1000 specific state trie keys from the DB in parallel is much faster than doing it sequentially? Second, if so, how much faster?

If there are substantial gains to be made, then there are clever things we can do, like requiring miners to provide a witness specifying what accounts and storage keys get accessed in the block, and additionally it means that there are potential great scalability gains in EIP 648.