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

add 0th call and basic readme

This commit is contained in:
Danny Ryan 2018-08-06 13:51:38 -05:00
commit a0a44e8be5
2 changed files with 352 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
README.md Normal file
View File

@ -0,0 +1,7 @@
## ETH2.0 Project Management
### Previous ETH2.0 Implementers Calls
№ | Date | Notes | Recording |
--- | -------------------------------- | -------------- | -------------------- |
0 | Thu, Aug 2, 2018 14:00 UTC | [agenda](https://github.com/ethereum/beacon_chain/issues/44) \| [notes](eth2.0-implementers-calls/call_000.md) [reddit](https://www.reddit.com/r/ethereum/comments/949eo6/ethereum_sharding_implementers_call_0/) | [video](https://www.youtube.com/watch?v=Ynqrka5DQOI) |

345
eth2.0-implementers-calls/call_000.md Normal file
View File

@ -0,0 +1,345 @@
# Ethereum Sharding Implementers Call 0 Notes
### Meeting Date/Time: Thu, Aug 2, 2018 14:00 UTC
### Meeting Duration: ~1 hour
### [GitHub Agenda Page](https://github.com/ethereum/beacon_chain/issues/44)
### [Audio/Video of the meeting](https://www.youtube.com/watch?v=Ynqrka5DQOI&feature=youtu.be)
# Agenda
1. General Introduction of Sharding Meeting
2. Client Updates
3. Research Updates
4. Open Discussion
* [v2.1 spec](https://notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ#)
* [Conforming to p2p messages, prysmatic protocol buffers](https://github.com/ethereum/beacon_chain/issues/44#issuecomment-405298161), and other p2p related discussion
* [BLS signature standard libraries](https://github.com/ethereum/beacon_chain/issues/44#issuecomment-405415540)
* https://github.com/milagro-crypto/amcl/tree/master/version3
* Current state of cross shard communication research
* Actionable items for clients and research
* Format/Timing of future meetings
# 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
* Wrapper in NIM for [Milagro Crypto](https://github.com/milagro-crypto/milagro-crypto-c)
* Considering building from scratch
* 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](https://github.com/ethereum/ethereumj/wiki/Sharding-Implementation)
* 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](https://ethresear.ch/t/beacon-chain-casper-ffg-rpj-mini-spec/2760)
* 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
* [Collection of research and materials](https://github.com/status-im/athenaeum/blob/master/ethereum_research_records.json) related to sharding
* Please create pull request if anything missing
* Justin
* Randomness Beacon
* how to construct once we have VDF
* Which VDF to use
* Favorite -- [Construction by Benjamin Wesolowski](https://eprint.iacr.org/2018/623)
* 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](https://developers.google.com/protocol-buffers/)
* 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](https://ethresear.ch/t/discussion-p2p-message-serialization-standard/2781)
* 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](https://gitter.im/ethresearch/sharding-p2p-poc)
* 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](https://eips.ethereum.org/EIPS/eip-196) in [Byzantium](https://eips.ethereum.org/EIPS/eip-197)
* 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](https://blog.z.cash/new-snark-curve/) (~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](https://rist.tech.cornell.edu/papers/pkreg.pdf) 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](https://github.com/ethereum/wiki/wiki/Sharding-FAQs#how-can-we-facilitate-cross-shard-communication) and [yanking](https://ethresear.ch/t/cross-shard-contract-yanking/1450). 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](https://twitter.com/drakefjustin/status/1025040874386939904)
* VDF presentation
* Sharding AMA
# Links shared during meeting
* [Status sharding research records](https://github.com/status-im/athenaeum/blob/master/ethereum_research_records.json)
* [Prysmatic message proto](https://github.com/prysmaticlabs/prysm/blob/master/proto/sharding/p2p/v1/messages.proto)
* [Prysmatic serialization github issue](https://github.com/prysmaticlabs/prysm/issues/150)
* [Cap'n Proto](https://capnproto.org/)
* [Flat Buffers](ttps://google.github.io/flatbuffers/)
* [how protobuf is non-deterministic](https://developers.google.com/protocol-buffers/docs/encoding#order)
* [protobuf notes gist](https://gist.github.com/kchristidis/39c8b310fd9da43d515c4394c3cd9510)
* [Harmony sharding implementation progress](https://github.com/ethereum/ethereumj/wiki/Sharding-Implementation)
* [JS Lodestar Chain](https://github.com/ChainSafeSystems/lodestar_chain)
* [Serialization comparison table](https://notes.ethereum.org/15_FcGc0Rq-GuxaBV5SP2Q)
* [Serialization ethresearch post](https://ethresear.ch/t/discussion-p2p-message-serialization-standard/2781)
* [Milagro crypto](https://github.com/milagro-crypto/milagro-crypto-c)
* [VDF Construction by Benjamin Wesolowski](https://eprint.iacr.org/2018/623)
* [Justin VDF presentation on gitcoin](https://twitter.com/drakefjustin/status/1025040874386939904)
* [VDF Reading list](https://t.co/hDVSNImQ40)
# 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)