Skip to content

Latest commit

 

History

History
122 lines (98 loc) · 11.4 KB

Meeting 25.md

File metadata and controls

122 lines (98 loc) · 11.4 KB
Raw

Ethereum Core Devs Meeting #25

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

Meeting Duration 1.5 hours

Audio/Video of the meeting

Reddit thread

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.

  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")."

Notes

1. Metropolis updates/EIPs.

a. Any "subtleties" or questions we need to work out.

b. Updates to testing.

  1. 5:11 status/statusCode in receipts (eth rpc) [Arkidiy/Martin H.S] - Resolution: status will be used.
  2. 6:10 Hive tests update - Update: Going pretty good. geth has a few failures due to how empty accounts are handled, but this shouldn't be a problem in the future. - Parity and cpp are doing well on Hive and most of the errors are for small reasons. - The one thing is that difficulty tests (outside of Hive) are lacking, but some of the testing team is working on it. ethereumJ is working on RLP and other tests before they begin Hive integration. - There is no work on pyethapp integrating with Hive currently, but there is work ongoing to get the block tests to work with pyethereum. - Pre-compile accounts on testnet and mainnet have been filled with at least 1 wei to avoid weird Spurious Dragon account #3 bug.
  3. 10:40 Testnet launch update. - Byzantium fork on the Ropsten Ethereum testnet was successful. - We verified the zk-SNARK of a Zcash transaction on the testnet. - There is (or was) an attack on the Ropsten network. The block gas price on Ropsten was pushed down to 50gwi to mitigate the attack and that seems to have helped. The attack seems fairly inconsequential, but shows that Ropsten is a good test-bed for real world attacks.

c. Details and implementations of EIPs.

  1. Implementation Updates

d. Review time estimate for testing/release of Byzantium.

  • 23:36 Testnet has been running smoothly so far since the fork to Byzantium.
    • We discussed picking block number 4.35mil (Oct. 9th), 4.36mil (Oct. 13th), 4.37mil (Oct. 17th), or 4.4mil (Oct. 27th) for the mainnet fork.
    • Even though block number 4.36mil would be falling on a neat date, it would fall on a Friday so if things go wrong we'd have to work through the weekend. Also, Friday 13th is spooky and has bad luck associated. /s
    • Block number 4.4mil is very close to Devcon so that is not a good date.
    • We need some time to tests the new features and assure that clients stay in sync.
    • Unlike previous hard forks there is not an emergency or attack going on so we can be more conservative on the release date.
    • The Ethereum mainnet fork for Byzantium will occur at block number 4.37mil (roughly Oct. 17th) in order to give more time for testing.
    • The fork date/block number may be changed if major issues are found.

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

  • 38:44 - EIP discussion on Github has wrapped up.
    • Although there is a small amount of disagreement about implementing Snappy compression at the protocol, rather than a subprotocol level, all parties have agreed to move forward with the EIP because a majority are for it.
    • Reddit comments from /u/alsomahler were discussed and Peter addressed their concerns. Click here for the Reddit comment.

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

  • Zooko wasn't able to make the call, but he wants to propose moving forward with the BLAKE2b EIP to include it as a pre-compile in Ethereum citing it's speed and compactness.
  • He wants to use it to create more efficient zk-SNARKs to make proving times lower. Can help improve things like zero knowledge token transfers and more efficient interactions between the Ethereum and ZCash chains.
  • Can be added in either Constantinople or Serenity.
  • In the call, no one voiced opposition to adding it, but questioned what different primitives would enable what integrations cross chain.
  • Clients still need to look and see how easy/hard it would be to implement BLAKE2b in their client.
  • Hudson will be working with Tjaden (original EIP author) and Jay from the ZCash team to update the EIP to the newest standard.

4. 51:20 EIP 718: Concurrency and locks for storage

  • Anti-reentrency related EIP.
  • Will discuss more in next meeting after investigating it more.

5. 55:49 EIP 215: Bitwise shifting

  • EIP was basically approved in a previous core dev meeting.
  • EIP is now final.
  • Greg will merge it in the EIPs repo.

6. 1:00:34 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. 1:01:00 "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")."

  • Related to 718 and we can discuss it in future meetings.

Off Topic:

  • 1:02:15 ERC Process: How Does It Work?

    • Hudson, Casey, and Greg discussed what our view of the process is (as editors of the EIPs). We all agree we need to discuss this further and get a more well defined process, but so far ERCs are approved/finalized once the community members who benefit from the ERC and thought leaders come together, agree on an ERC spec, and implement the spec.
    • 2 good examples of this is ERC-190 - ETHPM and ERC-20.
    • We are open to proposals on how to define the process for approving ERCs (you can reach out to Hudson Jameson (/u/Souptacular on Reddit or [email protected]) with suggestions.

  • 1:06:14 Discussion on the difficulty tests.

    • The testing team will be taking the discussion offline to decide how clients should collaborate on making difficulty tests more flexible.

Attendance

Alex Beregszaszi (EWASM/Solidity), Alex Van de Sande (Mist/Ethereum Wallet), Andrei Maiboroda (cpp-ethereum), Anton Nashatyrev (ethereumJ), Arkadiy Paronyan (Parity), Casey Detrio (Volunteer), Christian Reitwiessner (cpp-ethereum/Solidity), Daniel Nagy (SWARM), David Knott (Research), Dimitry Khokhlov (cpp-ethereum), Greg Colvin (EVM), Hudson Jameson (Ethereum Foundation), Jared Wasinger (ethereumJS and Testing), Karl Floersch (Research) Lefteris Karapetsas (Raiden), Martin Holst Swende (Security), Matthew English (Testing), Mikhail Kalinin (ethereumJ), Paweł Bylica (cpp-ethereum), Péter Szilágyi (geth), Tim Siwula (Testing), Vitalik Buterin (Research & pyethereum), Yoichi Hirai (EVM)