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 25 Agenda #23

Closed
Souptacular opened this issue Sep 17, 2017 · 10 comments
Closed

Ethereum Core Devs Meeting 25 Agenda #23

Souptacular opened this issue Sep 17, 2017 · 10 comments

Comments

@Souptacular
Copy link
Contributor

Souptacular commented Sep 17, 2017

Ethereum Core Devs Meeting 25 Agenda

Meeting Date/Time: Friday 9/22/17 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

Reminder: Metropolis is now split into 2 hard forks: "Byzantium" first and then "Constantinople".

  1. Metropolis updates/EIPs.
    a. Any "subtleties" or questions we need to work out.
    - EIP #603: Add ECADD and ECMUL precompiles for secp256k1. See this comment for details and request to add to Constantinople. [Matthew D.]
    b. Updates to testing.
    1. status/statusCode in receipts (eth rpc) [Arkidiy/Martin H.S]
    2. Hive tests update.
    3. Testnet launch update.
    c. Details and implementations of EIPs.
    1. Updates from client teams.
    - geth - https://github.com/ethereum/go-ethereum/issues?q=label%3Ametropolis+is%3Aclosed
    - Parity - Byzantium release openethereum/parity-ethereum#4833
    - cpp-ethereum - [META] Byzantium implementation progress aleth#4050
    - ethereumJ - Byzantium release ethereumj#923
    - ethereumJS - [META] Byzantium Implementation Progress ethereumjs/ethereumjs-monorepo#209
    - yellowpaper - Byzantium changes yellowpaper#229
    - pyethapp
    - Other clients
    d. Review time estimate for testing/release.

  2. EIP 706: Snappy compression for devp2p - very simple change yet reduces sync bandwidth by 60-80%. [Peter]

  3. EIP: 152 - BLAKE2b F Compression Function Precompile [Zooko]

  4. EIP 718: Concurrency and locks for storage

  5. EIP 215: Bitwise shifting

  6. Account abstraction discussion - "I think we should also slowly bring up account abstraction again. How do the toolset providers think about it? Did we find better solutions in the meantime?"

  7. "Some way to reduce the gas costs for an SSTORE if that slot (or the whole contract) is destroyed at the end of the transaction ("ephemeral storage")."

Please provide comments to add or correct agenda topics.

@winsvega
Copy link

b,
2. Hive tests status

@jwasinger
Copy link

Please add this for ethereumjs: ethereumjs/ethereumjs-monorepo#209

@Souptacular
Copy link
Contributor Author

@winsvega @jwasinger Added!

@LefterisJP
Copy link

An interesting EIP raising the question of concurrency and locks for storage: ethereum/EIPs#718.

There is already some discussion about it in the EIP and perhaps by bringing it up in the meeting we can see opinions of other core devs on the topic: ethereum/EIPs#718

@axic
Copy link
Member

axic commented Sep 22, 2017

Perhaps we could agree on the bitwise shifting EIP: ethereum/EIPs#215. There is one change from last time: the operand order was swapped to match more natural use cases (shifting a value already on the stack and as such removes the need for swap)

@chriseth
Copy link
Contributor

I think we should also slowly bring up account abstraction again. How do the toolset providers think about it? Did we find better solutions in the meantime?

@chriseth
Copy link
Contributor

Something that does not yet have an EIP (at least I think): Some way to reduce the gas costs for an SSTORE if that slot (or the whole contract) is destroyed at the end of the transaction ("ephemeral storage"). This is useful for mutexes and auxiliary data that is passed to contracts deep inside the call chain but that we neither want to pass along all the time nor store permanently in some data storage contract.

@holiman
Copy link

holiman commented Sep 22, 2017

@chriseth would SSTORE be the best vehicle for ephemeral storage? Or would a new type of memory be better?

@chriseth
Copy link
Contributor

@holiman open to anything as long as it solves the use-cases :-)

@Souptacular
Copy link
Contributor Author

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

8 participants