Ethereum Core Devs Meeting 40 Agenda

[lrettig]

Ethereum Core Devs Meeting 40 Agenda

Meeting Date/Time: Friday 06/15/18 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Livepeer Live Stream Link

Agenda

1. Testing
2. Client Updates
3. Research Updates
4. EIP 1087: Net gas metering for SSTORE operations
5. Skinny CREATE2.
6. EIP 210: Blockhash refactoring still needs to be updated
   a. clarify that it does not change the current semantics when invoked via BLOCKHASH -- does not deliver older blocks
   b. possibly be fixed to be able to return the genesis hash
   c. have a nicer abi signature)
7. 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.
   c. EIP859: account abstraction.
   d. EIP 1052: EXTCODEHASH Opcode.
   e. EIP 1087: Net gas metering for SSTORE operations.
   f. EIP 1014: Skinny CREATE2.
   Please provide comments to add or correct agenda topics.

[Daft-Wullie]

Would it be possible to include EIP 648 in the agenda for the meeting?A year ago it was being evaluated for inclusion in the Byzantium HF but then it got dropped in favor of more ambitious long term scaling solutions iirc. With many Ðapps about to launch maybe it could be worthwhile to have a fresh discussion on this EIP to decide if it could merit being included in the Constantinople HF.
Thanks.
EDIT:
great comment by Casey Detrio explaining the situation and why the EIP may be superseded so it's probably not worth it to include it in the next meeting.
ethereum/EIPs#648 (comment)

[rauljordan]

Hi all, Raul from Prysmatic Labs here working on the sharding implementation for Geth. Would love to participate and give a brief update on our progress with my partner @prestonvanloon as part of the client updates in the agenda.

[holiman]

I'm going to miss this coredev call. A couple of thoughts..

• Skinny CREATE2 -- I'm all for that one. I'm hoping a few more reads up on it and if @vbuterin is present in the call, maybe he can talk about it. I would personally like to see that one included in the next fork. Reason being that I understand it makes state channels easier/better, and having working state channels could really help take the load off the chain.
• The blockhash EIP 210 still needs to be updated (1. clarify that it does not change the current semantics when invoked via BLOCKHASH -- does not deliver older blocks and 2) possibly be fixed to be able to return the genesis hash, and 3) have a nicer abi signature)
• I am 👍 on Net gas metering.

[AlexeyAkhunov]

Voting for Skinny CREATE2. Better state channels is one of the things we need.

Would also be great to discuss potential changes in the Roadmap from implementers' point of view. There were "rumours" about skipping Casper FFG to go straight to Sharded Casper. They way I see it is that Sharded Casper is much further away in terms of implementation than Casper FFG (as far as I know there are already couple of implementations of it). So I would like people to think about pros/cons of changing the Roadmap so we can discuss it, if it is appropriate place.

I should be able to join the call tomorrow and give a quick update on Turbo-Geth.

[jamesray1]

@AlexeyAkhunov I did suggest to bring Casper CBC forward in the roadmap e.g. to reduce energy consumption as Ethereum scales, but that suggestion hasn't gained traction/support from others. @JustinDrake and @vbuterin have been researching Casper FFG integration with sharding, as detailed by some of their recent posts on ethresear.ch. Casper CBC isn't until phase 5 of the roadmap: https://github.com/ethereum/wiki/wiki/Sharding-roadmap.

[jpritikin]

Any update on Swarm? It feels like it's taking forever.

[karalabe]

Regarding CREATE2, do we have any restriction on the execution context, or it remains the same? The reason I'm asking is because the EIP states:

Allows interactions to be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code.

Even though this statement is true, the final deployed contract can behave arbitrarily differently depending on who deploys it and when (since the execution environment changes). This is in itself fine, but I think it's an important limitation of the opcode to explicitly highlight, otherwise we'll see many many abuses around this.

Alternatively we could enforce CREATE2 to not have access to environmentals, but that might be an ugly complication.

Just food for thought.

[vbuterin]

I will give an update on Casper / sharding plans, and @djrtwo and @JustinDrake can also chime in if either or both are around.

Even though this statement is true, the final deployed contract can behave arbitrarily differently depending on who deploys it and when (since the execution environment changes). This is in itself fine, but I think it's an important limitation of the opcode to explicitly highlight, otherwise we'll see many many abuses around this.

Agree fully. That said, I'd strongly oppose adding restrictions to CREATE2 to solve this problem at EVM level. The right layer of the ecosystem for programming language paternalism of the type that potentially impacts legitimate functionality is Solidity/Vyper/other HLLs, and banning external calls or dependence on environmentals for CREATE2 in Vyper (possibly with exceptions, like a standardized variable for time_created) seems like something that's fundamentally very reasonable to do.

[winsvega]

Testing update (cpp client)

General Genesis config format json validation scheme discussion and PR:
ethereum/tests#469

• Blockchain tests via RPC and without mining execution success
• State tests generation into blockchain test via RPC success
• Full state tests via RPC execution on cpp client with 8 threads time - 450 seconds.

TODO:
cpp codebase requires refactoring to run the blockchain tests. rpc requests implementation is not optimized.
merge WIP test branch into cpp develop.

[lrettig]

Closing in favor of #46