Skip to content

Latest commit

 

History

History
345 lines (336 loc) · 15.8 KB

call_000.md

File metadata and controls

345 lines (336 loc) · 15.8 KB
Raw

Ethereum Sharding Implementers Call 0 Notes

Meeting Date/Time: Thu, Aug 2, 2018 14:00 UTC

Meeting Duration: ~1 hour

GitHub Agenda Page

Audio/Video of the meeting

Agenda

  1. General Introduction of Sharding Meeting
  2. Client Updates
  3. Research Updates
  4. Open Discussion

Client Updates

  • Lighthouse (Paul)
    • Waiting for v2.1 spec to finalize
    • Have first version of beacon chain implemented
    • Working on minimal p2p
    • Looking at BLS implementations
  • Python beacon_chain (Danny)
    • Almost done with v2.1
  • Nimbus (Mamy)
    • Working on v2.1 from spec
    • Exploring BLS options
  • Prysm (Raul)
    • Migrated away from geth -- independent eth2.0
    • Local network p2p via gossipsub
    • Full beacon node running (v2.1)
      • State transition functions
      • Shuffling, cutoffs
      • Induct incoming validators from pow receipts
      • Working on forkchoice and chain sync
    • Sharding client (separate process communicates via RPC)
    • Simulator tool for simulating incoming blocks
  • Pegasys (Ben Edgington)
    • Team building -- Olivier and another new hire
    • Looking into BLS implementation
    • RNG research
    • Working on beacon chain implementation
  • Harmony (Mikhail)
    • Beacon chain
      • Deposit contract and induct validators from receipts
      • Working on block production, state transition functions, etc
    • Progress and plans
  • Lodestar Chain (Mikerah)
    • Javascript beacon chain implementation
    • Looking into BLS options
      • Trying to use Milegro crypto primatives to build BLS curve
      • Looking into compiling from rust to web assembly
    • Beginning to implement v2.1 state transition functions
    • Project started at internal hackathon. Steady progress

Research Updates

  • Vitalik
    • Recursive Proximity to Justification (RPJ) forkchoice
      • minimal partial spec on ethresearch
        • focuses just on ffg+rpj
        • Goal to be analyzed and formally proven
      • RPJ design goals
        • Maintain safety and liveness of FFG
        • Simplicity
        • Stability
          • Forkchoice is a good prediction of future forkchoice
          • hybrid rules are bad at this
          • RPJ is good
        • Maximize resistance to manipulation of RNG
          • resistant up to 80-90% of chain being overtaken by attackers as long as majority of attesters are honest
    • 99% fault tolerant article coming soon
  • Mamy
  • Justin
    • Randomness Beacon
      • how to construct once we have VDF
      • Which VDF to use
        • Favorite -- Construction by Benjamin Wesolowski
        • True VDF -- exponential gap between compute/verify
        • Based on RSA Groups so need to think about setup (how to pick RSA modulus)
          • Can use small random numbers as moduli for parallel sub-VDFs
          • If at least one modulus cannot be factored, then who construction is safe
      • VDF cryptographers meeting in SF to discuss
      • Hardware manufacturing
        • Build VDF ASIC commodity
        • Needs to be close to no-expense-spared attacker ASIC
        • Access to these commodity ASICs will counter no-expense-spared attacker
      • Full RNG spec likely in 1.5 to 2 months
  • WASM execution engine and cross-shard txs (Casey)
    • Black box sharding phase 1 in an effort to prototype phase 2 (execution and cross-shard execution)
      • black box the ordered data-blobs and links between them
      • phase 2 prototype will just process ordered datablobs from json
    • Advantages prototyping phase 2 in JS
      • libp2p library
      • access to native jit engine
    • Delayed state execution model

BeaconChain v2.1

  • Vitalik
    • Parts of this spec are provisional. Expect to change broadly if RPJ is included
      • Dynasty transition
        • just have one validator set for now
      • Epoch transition
      • RNG
    • Things worth working on
      • BLS aggregate signatures
      • General structure
        • ActiveState
        • CrystallizedState
        • bitfield tracking aggregate signatures
      • Stub what shard to work on
        • each height can just correspond to one particular shard
    • If you get to the above and block box the suggested, then try working on p2p
    • Rest of protocol details will be filled in likely over next 2 months
  • What is v2.1
    • Danny: combining block attestations and shard crosslinks also serving as FFG votes
    • Vitalik: three things
      • ffg voting
      • small scale block attestation
      • shard crosslinks
    • Vitalik
      • If num_validators is too small to have one distinct committee at every height, will probably have committees overlap.

P2P

  • p2p message format
    • Preston
      • Prysmatic currently using protobufs
      • protobufs have unordered fields which can be a problem with hashing
      • Exploring alternatives such as FlatBuffers
      • Proposal: Agree early on a schema with wide adoption
    • Hsaio-Wei: Is it deterministic serialization?
    • Jacek
      • Protobuf spec doesn't define the order
      • Little extra features that make protobuf difficult to use in a hashing setting
      • Stripped down version could work
    • Mamy: FlatBuffer and CaptainProto are options
    • Hsaio-Wei
      • Prysm is using protobufs for messages but which serialization are you using for encoding the data for database?
      • If we use different serialization for data and p2p, we might have to do two serializations when syncing
    • Raul
      • Prysm uses proto for serialization in DB
      • protos for all process communication
    • Vitalik
      • Why crystallizedstate need any special serialization when you can just pack values together
    • Raul: because state is communicated between processes
  • Signature aggregation wrt network
    • Mikhail
      • What does this look like? How many messages required to attest?
    • Vitalik
      • Not much yet
      • validators publishing messages that need to be aggregated every ~8 seconds could be a bottleneck and warrant a separate p2p
      • If naive is too hard, we can consider hierarchical scheme
        • Selected nodes are in charge of aggregation for subset of network
    • Justin
      • Could use random path strategy
        • tag on own signature as attestation is passed around
    • Vitalik
      • That takes O(N) time
      • Need something that takes 2-3 rounds of network communication
    • Raul
      • Currently setting up pieces of system to be able to test aggregation
  • RLP
    • Mikhail: what's wrong with RLP
    • Hsaio-Wei: Too complicated
    • Preston: RLP not very fast
    • Jacek
      • RLP missing a schema
      • Would like a schema
  • Further discussion on message format at ethresearch
  • P2P layer (Gossipsub?)
    • Paul: Is Prysm using gossipsub?
    • Raul: Yes
    • Danny: Is the beaconchain and shard chains p2p going to be the same?
    • Vitalik: Beacon chain should be on some layer everyone downloads by default
    • Raul: Beacon nodes on topic "shard -1" and have network for separate shards
    • Kevin
      • Beacon chain messages in a global topic
      • So everyone in same network but segregated
    • Justin
      • How many topics per shard?
      • could be -- one for headers, one for unsigned blocks and unaggregated signatures, one for fully signed and aggregated blocks
    • Mikhail: Does number of channels affect network amplification rate?
    • Kevin
      • You only broadcast to peers that have subscribed
      • If receive message not subscribed to, can band peer
    • Mikhail
      • More concerned about discovery being impacted by number of channels
    • Kevin: worth testing
    • Justin
      • One strategy is to have common discovery layer for all channels and have gossip on top.
    • Kevin
      • We currently have a global channel for discovery
      • Exploring other discovery protocols
    • Danny: gitter channel for testing and discussing here
    • Mamy: It's not worth implementing libp2p from scratch because we haven't made a firm decision, right?
    • Danny: Yes, we don't have enough testing to say we are going to use it for sure at this point.

BLS Signatures

  • Danny: So it seems that there aren't a ton of standard BLS implementations across the various languages
  • Vitalik
    • There are standards for BN128 because we put it as precompile in Byzantium
    • Not sure how substantial it is to migrate these libraries to BLS12-381
  • Danny: What's the benefit of changing the curve?
  • Vitalik
    • Higher security margin (~100 bits --> 128 bits)
    • ZCash and other projects are standardizing so worth going with the flow.
  • Justin: Chia too
  • Jacek: Chances of community finding another curve?
  • Vitalik
    • Unlikely due to standardization effort going in
    • Unlikely something broken in bls12-381
    • One property a new curve could have that would be better:
      • if new curve pointed to a pair of curves where one is the modulus of the other, and the other is the curve order of the first. This would be really nice for zkSNARKS
  • Danny: What needs to be done to standarize these libraries?
  • Vitalik
    • I need all the params and a couple hours of hand-holding with a knowledgable cryptographer
  • Jacek: Outlook for fully audited reference implementation for this curve?
  • Justin
    • Rust implementation being spearheaded by ZCash
    • Has been audited by security company
    • Abstract spec has also been audited another security company
    • Rust impl has been worked on for many years
  • Paul: Does it have aggregates?
  • Justin
    • It's for base layer operations
    • Aggregation is trivial on top
  • Paul
    • We hacked together an implementation but probably "as safe as broken glass"
  • Vitalik
    • Preference for dealing with "rogue key attacks" is proof of possession at deposit time.
    • Not currently implemented but fairly trivial
  • Paul: on PoW chain or separate?
  • Vitalik
    • Do on beacon chain
    • Probably should do as little as possible on PoW chain to facilitate migrating deposits to shard chains
  • Paul: Should probably put a note about rogue key attack in reference implementation
  • Danny
    • It's in the v2.1 spec but still in PoW chain.
    • Likely just going to do the burn in the PoW contract and do all the validation of validator init data in beacon chain
  • Justin
    • As much as possible in beacon chain
    • Question remains: how to do the bootstrapping process to onboard initial validators
    • Research post coming soon
    • Rust BLS implementation is performant but not constant time crypto so possibly vulnerable to timing attacks
  • Vitalik
    • Pairings do not need anti-side-channel protection because just verification
    • Elliptic curve multiplications need it
    • There are decades of research on this so no fundamental obstacle here

Cross-shard communication research

  • Mikerah
    • v2.1 doesn't really go into cross-shard comms. Does research team have any more formal ideas, writings, etc
  • Vitalik
    • v2.1 spec doesn't cover state execution at all
    • There are various posts on cross-shard txs and yanking. That's the extent at this point
  • Casey
    • In terms of the phase 2 proto type, are phase 1 and 2 sufficiently decoupled for this to work?
  • Vitalik
    • If they are to be entirely decoupled, execution and data consensus would have to be separate.
    • Blocks would not contain state roots
  • Casey
    • That's delayed state execution?
  • Vitalik
    • Yes, if we make an agreement that we are doing delayed state execution, then the two are fully decoupled.
    • If use eth1.0 model, they are coupled
  • Justin
    • Considering not shuffling shard proposers often so they don't have to incur the cost of syncing state
  • Casey
    • In stateless execution, don't have that problem
    • In general, execution and cross-shard comm are relatively understudied.
    • Hoping to spike more interest in this problem
    • Even names phase 1 and phase 2 give impression of not being able to work on phase 2 before phase 1 is built.
    • Would like to see more work on phase 2 in parallel

Last remarks

  • Sharding workshop
    • Ben Edgington: Any interest in workshop/get-together around devcon?
    • Justin: Makes sense to do an event immediately before or after
    • Jacek
      • Status hosting hack-a-thon before in Prague. Might be able to use venue. Will check with team
  • get_shuffling
    • Paul: Looks like it might have an infinite loop
    • Vitalik
      • It is the case that there is no upper bound
      • But sharp probablistic bounds
    • Danny: I remember there being a loop too, will check it out
  • Shared repo for testing and contracts
    • Raul: Makes sense to open a shared repo for testing and contracts
    • Danny: I agree esp on testing. Are we ready for shared testing?
    • Raul: No, not yet.
    • Danny: Let's get something together in the next couple of weeks.
  • Justin VDF presentation on gitcoin
    • VDF presentation
    • Sharding AMA

Links shared during meeting

Attendees

  • Justin Drake (EF/Research)
  • Danny Ryan (EF/Research)
  • Raul Jordan (Prysmatic)
  • Nikolay Volf (Parity)
  • Mikhail Kalinin (Harmony)
  • Dmitry (Harmony)
  • Ben Edgington (Pegasys)
  • Olivier (Pegasys)
  • Preston Van Loon (Prysmatic)
  • Jannik Luhn (Brainbot/Research)
  • Hsiao-Wei Wang (EF/Research)
  • Mamy Ratsimbazafy (Status)
  • Ryan (Status)
  • Jarrad Hope (Status)
  • Jacek Sieka (Status)
  • Chris Spannos (EF scaling grant recipient)
  • Paul Hauner (Lighthouse/Sigma Prime)
  • Adrian Manning (Lighthouse/Sigma Prime)
  • Carl Beekhuizen (Decentralized staking pools)
  • Chih Cheng Liang (EF/Research)
  • Lang Rettig (EF/eWASM)
  • Kevin Chia (EF/Research)
  • Nicholas Lin (EF/Research)
  • Vitalik Buterin (EF/Research)
  • Mikerah (Lodestar/ChainSafeSystems)
  • Casey Detrio (EF/ethereumJS)
  • Alex Beregszaszi (EF/Ewasm)