status-im
/
eth2.0-pm
mirror of https://github.com/status-im/eth2.0-pm.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
eth2.0-pm/eth2.0-implementers-calls/call_003.md

14 KiB
Raw Blame History

Ethereum 2.0 Implementers Call 3 Notes

Meeting Date/Time: Thu, Sept 13, 2018 14:00 UTC

Meeting Duration: 1.5 hours

GitHub Agenda Page

Audio/Video of the meeting

Agenda

  1. Client Updates
  2. Research Updates
  3. YAML test format
  4. v2.1 Discussion
  5. Tentative decision on the following:
    1. p2p serialization format
    2. p2p network protocol
    3. p2p discovery protocol

Client Updates

  • Prysmatic (Terence)
    • Aligning with v2.1
      • new state and dynasty updates
      • need to do FFG balance updates
    • implemented validator service
      • with partial proposer responsibilities
      • with partial attester responsibilities
    • refactored codebase for readibility and maintainability
    • Currently using levelDB but benchmarking others
  • Lodestar (Mikerah)
    • Planning dev of libraries
      • Pairings library in JS (research phase)
      • GossipSub (research phase)
      • BLS sig library
      • VDF Library
  • Lighthouse (Paul)
  • Pegasys (Ben)
    • Onboarding new hires
    • Researchers analyzing and modeling new casper
    • Blaze getting up to speed on p2p protocols
    • Beginning to write some beacon chain code
  • Nimbus (Jacek)
  • Harmony (Mikhail -- read by Danny)
    • working on State transition
    • attestations are next milestone
    • still working on potential proposal of DB state changes
  • Parity (Afri)
    • Probably start working on new client for Eth2.0
    • Team meeting in two weeks to discuss path forward for eth2.0
  • beacon_chain (Danny)
    • implemented dynasty change
    • some work on justified_slot in attestation
    • working through reward logic to clean up spec

Research Updates

  • eWASM (Lane)
    • Focussed on preparing testnet for launch before devcon
    • Casey working on shasper sim and prototypes around state execution
  • add to v2.1 (Vitalik)
    • Dynasty transition
    • balance changes
  • Simplified Casper Slashing condition (Justin)
    • Slashing conditions can be weakened to single slashing condition
    • Safety proof still holds
  • VDF (Justin)
    • how to program moduli (hardcoded or programmable)
      • looks like hard coded is better for us
    • picking moduli carfeully can reduce logic gates in ASIC (reduced die area)
    • debating class groups vs RSA groups
      • Chia likely to use class groups
      • Eth still considering RSA groups
    • Can construct hybrid between two provers. Between
      • one that is optimal and size
      • one that is efficient to compute
    • Obelisk Launchpad might be good service to build the ASIC
    • Considering multi-party ceremony for picking RSA modulus
      • approach seems viable
      • only need one honest player to destroy their source
      • new constructions are 10x faster and one team thinks can do 1000s of participants in a few minutes
    • Been discussing modular multiplication with specialized teams
  • Trusted cermony notes (Vitalik)
    • even if we go with the ceremony approach, the casper ghost alg is designed with the idea that the VDF can be broken and we still get the basic guarantees of security
    • If VDF is secure, then security tolerances can be much lower and the RNG can be used for applications.
  • sharding p2p poc (Kevin)
    • refactoring and debugging
    • working on log aggregation
    • restructuring relationship between go and python to move most of logic in python
    • To do
      • looking into testing more at scale
      • looking into alternative protocols for discovery
  • gossipsub simulations (Jannik)
    • Simulated collation propogation in single shard
      • nothing too surprising
      • max block size in this network was 3MB
      • All but slowest nodes have available bandwidth
      • number of peers didn't matter too much. Good numbers between 4 and 8 peers
    • Tested push-pull protocol
      • No obvious advantages over gossip sub
    • next up is peer discovery
    • GossipSub
      • Simple
      • can handle the load
      • appears to do what we want
  • Structured aggregation
    • Vitalik - has anyone given any thought to protocols that aggregate sigs step by step instead of putting entire burden on proposer
    • Danny - so thought is to have subset of notes that aggregate subsections of the network and aggregating?
    • Vitalik
      • essentially, yes. There are probably lots of ways to do this
      • Unstructured aggregation will likely result in duplicates that can't be aggregated anymore
    • Justin - We can make the bitfields handle some amount of overlap
    • Vitalik
      • This might complicate unnecessarily. We should try to solve at network level first
      • It will be okay do it naively during testnets, but we'll need something before launch
      • IDEA:
        • validators already in shard p2p
        • dual purpose existing shard subnets for sub aggregation
        • republish aggregates to main p2p for proposer to fully aggregate
        • requires bridge nodes and multiple rounds of communication
        • might need slot length to be 16s instead of 8s
  • Benchmarks on block verification
    • Vitalik - Have there been benchmarks assuming a certain number of validators?
    • Danny
      • Python implementation could pump these numbers out easily
      • I'll make an issue so multiple clients can try this
    • Vitalik - As opposed to eth1.0, beacon chain won't have potential issues with quadratic blowup do the state calculations
  • RSA Modulus
    • Mamy - do we need to implement RSA wrt the RSA modulus or is it just for the VDF?
    • Justin
      • Just for VDF
      • Just RSA in the sense that it has same requirements -- unfactorizable
  • Sparse merkle tree

YAML Test Format

v2.1 Discussion

  • libp2p support
    • Blaze
      • Any discussion about porting libp2p to other languages?
      • How to make it available in other languages
    • Paul
      • Protocol labs interested in assisting new implementations
    • Jacek
      • Discussing an implementation in Nim which would expose an impl in C
      • No where near completion
    • Mamy
      • Still unsure about libp2p so not dedicating too much resources yet
    • Danny
      • Are we feeling confident in deciding to use libp2p and gossipsub?
    • Jannik
      • I like gossipsub based on research
      • Not sure about discovery yet
    • Danny - So close, but not quite ready to make decision
    • Jannik - existing discovery mechanism could work for testnet purposes
    • Kevin
      • We can use some common code with GRPC to allow other languages like we are doing with python/go in PoC now.
    • Blaze
      • protocol labs provided an http daemon for IPFS.
      • Maybe we do same for gossipsub
    • Hsiao-Wei
      • Longterm we want a python implementation of gossipsub
    • Danny
      • Research team signalling 90/95% sure on gossipsub
      • probably worth investigating what an implementation in your language would look like
      • close to decision
  • BLS Proof of Possession
    • Terence - how do we generate?
    • Vitalik
      • there is a standard formula
      • for now, use your key to sign a hash of your public key
    • Danny
      • Needs to be a different hash function
      • these params will almost certainly be verified in beacon chain
      • so beacon chain will to support main hash plus auxiliary hash for Proof of possession
  • Generating public/private key
    • Terence
      • Have we decided on library for generating private/public key?
    • Vitalik
      • Either using bn256 or BLS12-381
      • as far as library it depends on your language and what is available
  • Shuffling motiviations
    • Paul
      • What motivations of get_new_shuffling
      • Assuming
        • spread out validators across slots evenly
        • ensure every shard is attested to
      • there are some cases where there are enough validators to create commmittees of min size and attest to every shard, but not always doing that
      • seems to target 2*min_committee_size
    • Vitalik
      • intention is for min_committee_size to be a min, not a target
      • as validators --> infinity, committee size should stablize toward 2 * min_committee_size
    • Paul
      • going to write out some requirements for clearly understanding and testing
      • will request feedback
  • Rejecting blocks quickly
    • Paul
      • figuring out how to most quickly reject invalid blocks to prevent dos attacks
      • Is there a way we can easily see if block producer sig is in the attestations to easily throw out if not
    • Vitalik
      • We can make spec put proposer attestation at the 0th position
    • Danny
      • block validity rule is premised upon inclusion attestation from parent block proposer
      • but, I shouldn't process a block unless I see a proposer attestation for the block in question come in on the wire
      • 4 conditions before processing -- one is receiving proposer attestion with block
  • p2p serialization
    • Danny
      • previously discussed using ssz for serialization of wire protocol
      • are there any objections?
      • can we make decision today?
      • silence says, we are making a tentative decision
      • decision made
    • Paul
      • lighthouse has been implementing and it seems pretty simple and optimal
    • Mamy
      • Can we create test repo for shared tests
      • maybe use new YAML scheme?
    • Danny
      • the YAML scheme is more of a chain test
      • Will consider if it can be more generic for this purpose
      • definitely time for test repo
    • Paul
    • Vitalik
      • looking now...
      • oh wait what version of ssz is this?
    • Paul
      • version from beacon_chain
    • Vitalik
      • in this version, because length of int32 is known, no length is part of the serialization
      • seems like name collision issue
      • this was designed to optimize for the availability of direct mappings for datatypes
      • speeds up block processing
      • length in serialization only occurs for variable length datatypes
    • Mamy
      • We can use compression on top of ssz to compress the space
    • Jacek
      • How does this differ from parsing a format into binary convenient to you
    • Vitalik
      • true but has a clean separation of layers
      • serialization alg isn't going to achieve optimal no matter what so people will be incentivized to compress
    • Jacek
      • need to look at blow up attacks for decompression
    • Vitalik
      • good to look at
      • but fundamental scalability of protocol does not need compression
    • Mikerah
      • Need formal spec of ssz
    • Vitalik - Should work on one
    • Danny
      • good target
      • currently only what is in beacon chain
      • will pull it out as library as well
  • Discovery protocol
    • Danny
      • Not enough research yet
      • tabling this decision

Tentative Decisions

  • p2p serialization format
    • decided ssz
    • need formal spec and shared tests
  • p2p network protocol
    • 90/95% sure on gossipsub
  • p2p discovery protocol
    • too early
    • need more research

Links shared during meeting

Attendees

  • Lane Rettig (eWASM)
  • Vitalik Buterin (EF/Research)
  • Alexey Akhunov (turbo-geth)
  • Nishant Das (Prysmatic)
  • Blaze (Pegasys)
  • Mikerah (Lodestar/ChainSafeSystems)
  • Danny Ryan (EF/Research)
  • Carl Beekhuizen (Decentralized staking pools)
  • Terence (Prysmatic)
  • Justin Drake (EF/Research)
  • Liam Horne (L4)
  • Kevin Chia (EF/Research)
  • Jannik Luhn (Brainbot/Research)
  • Paul Hauner (Lighthouse/Sigma Prime)
  • Chih-Cheng Liang (EF/Research)
  • Martin Holst Swende (EF/geth/security)
  • Adrian Manning (Lighthouse/Sigma Prime)
  • Nicolas Liochon (Pegasys)
  • Ben Edgington (Pegasys)
  • Mamy Ratsimbazafy (Status/Nimbus)
  • Casey Detrio (eWASM/EthereumJS)
  • Preston Van Loon (Prysmatic)
  • Jacek Sieka (Status/Nimbus)
  • Hsiao-Wei Wang (EF/Research)
  • Afri (Parity)
  • Nicholas Lin (EF/Research)