Ethereum Core Devs Meeting 25 Agenda
Souptacular opened this issue · 10 comments
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".
-
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 - openethereum/parity-ethereum#4833
- cpp-ethereum - ethereum/aleth#4050
- ethereumJ - ethereum/ethereumj#923
- ethereumJS - ethereumjs/ethereumjs-monorepo#209
- yellowpaper - ethereum/yellowpaper#229
- pyethapp
- Other clients
d. Review time estimate for testing/release. -
EIP 706: Snappy compression for devp2p - very simple change yet reduces sync bandwidth by 60-80%. [Peter]
-
EIP: 152 - BLAKE2b
F
Compression Function Precompile [Zooko] -
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?"
Please provide comments to add or correct agenda topics.
b,
2. Hive tests status
Please add this for ethereumjs: ethereumjs/ethereumjs-monorepo#209
@winsvega @jwasinger Added!
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
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)
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?
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.