Permalink
Find file Copy path
2b2063f Dec 7, 2018
2 contributors

Users who have contributed to this file

@lrettig @arnetheduck
320 lines (308 sloc) 19.6 KB

Ethereum Core Devs Meeting 51 Notes

Meeting Date/Time: Fri, December 7, 2018 14:00 UTC

Meeting Duration: 1.5 hours

GitHub Agenda Page

Audio/Video of the meeting

Agenda

  1. Testing
  2. Client Updates
  3. Research Updates
  4. Working Group Updates
  5. Constantinople HF
  6. Openness of meetings
  7. ProgPoW update
  8. Quick announcement re: coordinator roles
  9. Date for next meeting?

Testing

  • Brian intro
    • Recently hired to work full time on making testing better
    • Not sure what that means yet - easy to generate and use tests
    • I've talked to Trinity, have an idea what they want
    • Please reach out and tell me what you'd like to see improved
  • Dimitry
    • Finishing EXTCODEHASH implementation
    • Discovered that every EXTCODEHASH test can be used to test *SIZE, *COPY, and *CALL
      • Not related to Const.
      • Each could be enhanced like that
      • Received a lot of help writing these tests from [Andrei?] and Hugo
    • Finishing things still on list
    • Still waiting for contribution on bitshift test review
    • Waiting for hive results to see if there are any issues we need to fix, or new tests we need to write
    • Martin said Hive has some maintenance
    • CREATE2, SSTORE tests ready, bitshift ready but needs review, EXTCODEHASH mostly covered
  • Martin
    • We're in process of rewriting Hive and making it more robust
    • In the meantime it's kind of flakey
    • Will also see some additional tests, P2P stuff I mentioned previously
    • Regarding tests
      • Updated all tests for geth less than two weeks ago
      • All tests pass
      • Kind of expected client devs to import and run tests in native settings, despite having Hive
      • But hoping to have Hive up and running again within next couple of days
      • No new failures on fuzz testers running for at least last couple of weeks
      • So I'm fairly confidence in code in geth and parity

Client updates

  • Harmony/EthereumJ (Mikhail)
    • No major updates
    • Mostly working on Beacon chain impl., been major spec changes lately, still catching up over next couple of weeks
  • Parity (Fred)
    • Released 2.2.2 with new improvements, some exciting stuff
    • Improves sync performance
    • Pairing stability, fixed pairing issues where it now finds a lot of pairs but fluctuation in pair counts
    • Block propagation fixed - waiting to see effect on network
    • Other minor things
    • Decided to move jsonrpc APIs not yet accepted in an EIP but implemented anyway (eth.person or web3 namespaces) - now disabled by default, enable with flag -jsonrpc-experimental
  • Geth (Peter)
    • Database optimizations
    • Just trying out ideas and looking at charts
  • Turbogeth (Alexey)
    • Fixed bugs found with Ropsten sync, syncs now
    • Started to work on test suite
    • Never run tests, have issues, fixing them
    • In order to make it work, had to modify boltDB
    • Now can run boltDB in in-memory mode, nothing on disk, wanted to try this for a long time
    • Client still not ready for Const., CREATE2 revival still not addressed, will address this
    • Found myself using turbogeth a lot recently as it's useful for extracting data I used for state rent proposal
    • 300gb database on external DB, made some copies of it and running data analysis
  • Aleth (Pawel)
    • Fixes and improvements to network code
    • Probably today will have a new tool that will work as a bootnode, can be used similarly to geth bootnode, want to put somewhere on mainnet or testnet as alternate implementation
  • Nimbus (Jacek)
    • Been focusing on parts of VM related to DevEx, e.g. debug and tracing
    • Let us know if you have any ideas, this is a good time to discuss
    • First Eth 2.0 testing framework and PoC things are landing right now, discussion on gitter
    • Good time to influence direction of Eth 2.0 testing
    • https://gitter.im/eth2-0-tests/Lobby - Ethereum 2 testing working group looking for feedback on the first proof-of-concept test vectors - now is a good time to join :)
  • Pantheon (Danno)
    • Planning on minor release next week
    • Includes contribs from external contributors
    • Including Goerli support
    • Looking into [missed this]
    • Beacon chain impl.
  • Mana (Andrew)
    • Syncing Const. blocks on Ropsten, anticipating full sync shortly
  • Adam (Swarm)
    • Swarm is a part of geth, in same repo with own semantic versioning
    • Last geth release contains swarm improvements such as access control on feeds
    • Will be announced with a blog post coming with next major release of geth
    • Last two weeks, introduced user perception tests [?] and benchmarks
  • Ewasm (Lane)
    • Working towards testnet spec v3
    • Released #Eth1x proposal, working towards this

Research

  • Danny update
    • Revisions of phase 0 - Serenity beacon chain spec
    • Readability, reorg., polishing data structures - major edits of spec
    • Tough to keep up, homing in on first version of release candidate
    • Phase 1 - sharded data chain algo. - data structures forming there
      • General algorithms known
      • Being specified
    • State execution, account structures - lots of thought going into this
    • Handful of proposals on ethresear.ch that V posted that we're looking for feedback on
    • Justin and VFD alliance: increasing number of blockchains interested in adding VFDs in various ways
    • Begun to do Beacon chain implementation in py-evm
  • Justin did talk on VDFs at Devcon, video online
  • Other DevCon IV talks should be online today

Working group updates

  • Whiteblocks (Zak)
    • Putting together specs for testnet
    • Working with 1x in simulation group
    • Relevant for testers as well
    • Will schedule separate call today that I'll post in issue that I opened
    • Please join and provide feedback, we can start getting specs for testnet and building it out
    • Will be powered by Whiteblock framework
  • Alexey
    • I have a writeup on state rent - first version of proposal published, received a lot of feedback
    • Most interesting one: V suggested using CREATE2 opcode and some other things to implement something I proposed to do with linear cross-contract storage
    • I managed to implement ERC-20 contract based on these ideas
    • It actually works, can mint and transfer tokens
    • Interesting to get feel of how you'd use CREATE2
    • Commented on issue in solidity, created thread on EthMagicians for ppl interested in creating new primitives to make it easier to work with CREATE2
    • Right now you have to copy and paste bytecode into source code
    • Linear cross-contract storage will most likely be dropped from next version of proposal
      • Priority queue too
      • But I'll still look into linear storage elsewhere e.g. Ewasm integration
    • I've asked PegaSys team to help with PoC, Adrian Sutton created first prototype, reviewing and hope to get my prototype running as well - so this is based on pantheon for now
    • Done a lot of data analysis, not all included in proposal
      • Trying to run heuristics to identify all ERC20 tokens in state
      • Looking for successful token transfers
      • Around 71k contracts
      • Take around 53% of all contract storage
      • Cryptokitties is also ERC-20 - has both this and 721
      • Very important class of contract, that's why I did sample implementation using V's ideas
    • Next step will be to look into on-chain order books
    • Put some ideas about how to identify them
    • Will do some analysis about token nexus contracts - tokens go in and out - likely will be on-chain order books
    • Might be able to compress state using generations
      • Looking into how we can have a very compact representation of current state
      • E.g. all contracts that GasToken creates could be generated using minimal seed data
      • So it would not take a lot of space in the snapshot
      • Not sure how well suited other clients are for data analysis - but someone could look at Google Ethereum dataset - see if it's possible to reproduce the data analysis I did, some in state rent proposal, plus this ERC20 analysis
      • If someone gets the hang of this, might be a good way to split up this work, there's so much to do in this workstream and I can't do it all alone
      • So trying to enlist people to do PoC, data analysis, maybe mods to Solidity and Vyper to make all this easier
  • Ewasm
    • See proposal and FEM thread
  • Peter "working group" on state pruning
    • FEM thread: https://ethereum-magicians.org/t/ethereum-chain-pruning-for-long-term-1-0-scalability-and-viability/2074
    • Long Github gist about two weeks ago (proposal)
    • In blog post I mentioned that I think there are two viable approaches we should experiment with
      • IPFS and Bittorrent
      • But both kinda of suck
      • Want to experiment with Felix's ENR work
      • Tiny extension to discovery protocol, really elegant
      • Nodes can advertise certain capabilities
      • Most infra. in place already
      • Want to play around with it where nodes advertise that they're a light or full node with certain datasets available
      • Trying to figure out whether we could do the whole historical state retrieval in protocol without needing to hack another decentralized protocol for it
      • Not sure if it's possible, but this is a third direction that may be valuable, need it anyway for light servers
    • Q: is this discovery V5?
    • A: depends how you define it, it's different, but Felix wants this ENR work to become new discovery v5
    • Problem is that it was hacked into protocol but not scalable
    • ENR approach is clear, there are a few EIPs open, quite a lot of published material
    • Danny: We are discussing using mature version of Dv5 for advertising which shards you're participating in
    • Peter: Considering putting historical state on top of that mechanism
    • Can't yet see single proposal that will work

Constantinople hard fork

  • Afri block time proposals
    • Last time we decided to talk about a block number at this meeting
    • I just put down some numbers
    • Did calculations to see how much it could vary if we target a Weds - would most likely fall on a weekday
    • Afri proposed block 7080042
    • Lane: have we always used even numbers ending in -0000 in the past?
    • Alexey: We don't think someone will start super mining to speed up the fork do we?
    • Danny: Would be very expensive on mainnet
    • Afri: very unlikely because of high difficulty of mainnet. Worst case scenario, if price of Eth continues dropping fast and a lot of miners stop mining then it could slow us down
    • Block times have been stable recently so this is not a concern
    • Martin: We'll put block number into next release with possible commandline option to delay it
      • Only reason to change block number again would be if we find another consensus bug
    • Hudson: All previous ones have been -000
    • Hudson: Do people prefer the palindrome or sticking with -000?
    • Peter: palindromes could be hard in the future
      • Easy if block numbers still in the millions'
    • Greg: four zeroes, keep it easy
    • Palindromes for testnet, four zeroes for mainnet - let's do this
    • So let's use 7080000
  • Stireby update
    • [missed a bit]
    • Alexey
      • Failure was that there was a GPU miner, we fell prey to this because spec was public
      • Plan was to have a bit more mining, didn't happen
      • Not going to push to have another one
      • I think this was worth doing
    • Martin: Suggestion for new PoW testnet called Gangnam with more genesis alloc, can deprecate Ropsten
      • For dapp testing
    • Peter: Good time to bring up a few discussions
      • We agreed we don't want to continue Ropsten
      • But do we want to relaunch a PoW or instead do a PoA network?
      • Afri & co. have been working on Goerli testnet
      • Would mean we don't have a public PoW testnet but we could always do public PoW testnet forks just to verify PoW and difficulties when we need to do a hard fork
      • Not too much point in running a PoW replacement for Ropsten
    • Martin: We'd drop all Trinity, aleth, and those that haven't yet implemented clique yet
    • Afri: This can be done
      • With all devs out there we can do this
      • Agree with Peter that going fwd with PoW not feasible, this Stirby experience showed how unfeasible PoW testnets are
      • Esp. having one for apps not for consensus needs
    • Mikhail: Fresh test networks not good for testing difficulty bomb delays - block numbers too low, not yet activated
    • Zak: join this testnet call since we can create testnets with relative ease that are provisioned and controlled
    • Peter: We can create purpose-built testnets to test difficulty adjustment - for everything else PoA is a saner approach from dapp developer perspective
    • Zak: Will probably want different consensus algos in different testnets for different reasons - purpose built
      • Provisioning, ensuring adequate activity is the hard part
    • Peter: if we want a purpose-built testnet to test difficult adjustment then we don't need any activity
      • For other stuff PoA works fine
    • Mikhail: Could add configuration for difficult bomb and delays
    • Peter: Don't need to make a decision about this here
      • If we want to replace Ropsten it might be a good idea to do a PoA testnet
      • Everyone please think about it, if someone has a good reason why it's a horrible idea we'll consider that
    • Zak: Activity, background traffic will affect consensus and various metrics within the network
    • Peter: This is the point of having a public testnet, have traffic etc.
    • Alexey: Let's explore option of purpose-built PoW network with Zac and then come back and discuss more on next call, whether this is feasible, PoW for specific things and PoA for everything else
    • Zak: These testnets can be ephemeral, not entirely public, will be permissioned, activity and behavior will be automated with our tools
    • Hudson: This is a good topic for the next meeting
      • Will Goerli be compatible with ETC? Is that a problem?
      • Afri: No, it will not have ETC compatibility
      • But we work on something similar for ETC

Openness for meetings

  • Hudson: Enough people who said "over my dead body" re: any type of closed meetings
    • So we will have open meetings for now
    • Less inclination to do this for these calls
    • Not sure about in person yet - technical feasibility is different
    • Won't have any more "Eth1x" / mainnet improvement calls as WG all created now
    • So we'll just keep doing what we've been doing
    • If anyone has a differing opinion speak now or speak to me privately later
  • Martin: There are WG, we will talk within them
    • Is that frowned upon?
  • Hudson: That can be private or public, it's not a core dev meeting
    • There was some confusion around that
  • Greg: There was useful discussion on where to make the call about what you open up and how much
    • It's a matter of judgment
    • From chat: While we worry about not feeling free to speak our minds in public in the face of a clueless press, I used to help organize anti-war actions with FBI infiltrators at our open meetings, and a press that would accuse us of violence when the cops had finished beating us.
    • When I did war demonstrations, we had FBI and CIA infiltrators and a press who would accuse us of violence after the police beat us up
    • So I shrug and say, this is important but we don't really have that much on the line, it just isn't that hard

ProgPoW update

  • Pawel: Last two weeks, there's one reported issue left, reported at beginning of this week, need to resolve
    • Solution is decided but requires some small changes to implementation to mitigate small flaw in algorithm
  • Martin: Had implementations in C++, ethhash, verifiers for geth and parity, then spec changed, geth and cpp updated, parity hasn't yet implemented latest changes
    • Some more discussion about potentially changing spec
    • Two clients in sync
    • If parity implements most recent changes then we could launch a testnet
  • Martin: We had discussion with various people in crypto communities
    • One is David Warwick (?), creator of Zia
    • Got his approval to quote him
    • ProgPoW, if we were to replace hashimoto S/ethhash with this, it would probably keep ASICs away for 1-1.5 years
    • If we increase the resistance towards ASICs then that could itself increase centralization because only a very advanced ASIC manufacturer could afford to R&D such an ASIC that would get efficiency gains
    • So he believes it would buy us 1-2 yrs, but another approach is to use an algo which is extremely ASIC-friendly
    • We could adopt ProgPoW now and if a year from now we still don't have PoS, we might consider switching to something very ASIC friendly which even a small manufacturer can produce
    • Regarding prevalence of ASICs on network today, it's very hard to find numbers
    • Have been reported from various sources but none can be taken as fact
    • No records on units manufactured or sold so it's hard to take that into account
    • Some people think the fact that we're implementing ProgPoW is already decided, this is not the case, we are open to other options
  • Alexey: I started to think about ProgPoW more because of eth1x proposals, elephant in room is what are other things slated for eth1.0
    • ProgPoW which will take some amount of work
    • Second, Justin's interview for Epicenter, he said the reason they want to develop a VDF ASIC so that no one else can get a major advantage by creating something much much better
    • I'm glad Martin mentioned as well that there is a potential downside (re: centralization)
    • I want people to explore both
  • Hudson: Reminder that these eth1x roadmap working groups are still not finalized
  • Lane: Would it make sense for the new app testnet to be a ProgPoW POW testnet?
    • A: Not really
    • Martin: Just envelope of blocks, doesn't matter whether they are full or empty
    • Pawel: We want a testnet with a switch from one algo to the other, so not pure ProgPoW, or switching back and forth, let's keep them separate
    • Martin: Try different configs with a series of testnets

Quick announcement re: coordinator roles

  • Hudson, Danny, Lane, Afri, Piper, Casey, Jamie Pitts have been getting people together to discuss coordinator role
    • Person/people in thids role could help out with hard forks with Hudson and Afri
    • Also EIPs and core devs calls
    • Will be announcing them over the next few months, starting in January
    • You'll start seeing more of that
    • Main goal is to lighten load for Hudson, Lane, Afri and others who have been handling coordination for things like core devs calls
    • Also to train people as future PMs for teams
    • We'll work hard to get them more integrated into these calls, do it in a way that supports the core devs
    • Idea to make it as easy and stress-free as possible for core devs

Date for next meeting

  • Anyone opposed to skipping next call for holidays?
  • No opposition
  • Next call will be Jan. 4

Attendees

  • Hudson
  • Lane
  • Alexey
  • Pawel
  • Peter
  • Fred
  • Mikhail
  • Zak Cole
  • Fred Harryson
  • Dimitry Khoklov
  • Brian
  • Jacek
  • Danny
  • Danno
  • Andrew Gross
  • Daniel Ellison
  • Afri
  • Martin Holst Swende
  • Greg
  • Adam Schmideg
  • Shahan Khatchadourian