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 40 Agenda #44

Closed
lrettig opened this Issue Jun 1, 2018 · 10 comments

Comments

Projects
None yet
10 participants
@lrettig
Copy link
Member

lrettig commented Jun 1, 2018

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

This comment has been minimized.

Copy link

Daft-Wullie commented Jun 8, 2018

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

This comment has been minimized.

Copy link

rauljordan commented Jun 14, 2018

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

This comment has been minimized.

Copy link

holiman commented Jun 14, 2018

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

This comment has been minimized.

Copy link
Contributor

AlexeyAkhunov commented Jun 14, 2018

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

This comment has been minimized.

Copy link
Contributor

jamesray1 commented Jun 15, 2018

@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

This comment has been minimized.

Copy link

jpritikin commented Jun 15, 2018

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

@karalabe

This comment has been minimized.

Copy link
Member

karalabe commented Jun 15, 2018

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

This comment has been minimized.

Copy link
Collaborator

vbuterin commented Jun 15, 2018

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

This comment has been minimized.

Copy link

winsvega commented Jun 15, 2018

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

This comment has been minimized.

Copy link
Member Author

lrettig commented Jun 16, 2018

Closing in favor of #46

@lrettig lrettig closed this Jun 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment