ethereum/eth2.0-pm

ETH2.0 project management

[DEPRECATED] ETH2.0 Project Management

WARNING: This repo is now deprecated in favor of unification with the https://github.com/ethereum/pm/ repo. Please see this other repo for calls, notes, and other project management items

Interop Standards

This repo hosts a collection of standards to aid in client interoperability testing.

Previous ETH2.0 Implementers Calls

№	Date	Notes	Recording
75	Thu, Nov 4th, 2021 14:00 UTC	agenda | notes | no reddit	video
68	Thu, Jul 15, 2021 1400UTC	agenda | notes | reddit	video
67	Thu, July 1st, 2021 14:00 UTC	agenda | notes | no reddit	video
66	Thu, Jun 17rd, 2020 14:00 UTC	agenda | notes | no reddit	video
65	Thu, Jun 3, 2021 14:00 UTC	agenda | notes | no reddit	video
64
63
62
61
60
59
58
57
56
55	Thu, Jan 14, 2021 14:00 UTC	agenda | notes | no reddit	video
54
53	Thu, Dec 2, 2020 14:00 UTC	agenda | notes | reddit	video
52
51
50	Thu, Oct 15, 2020 14:00 UTC	agenda | notes | reddit	video
49
48
47
46
45
44
43
42
41	Thu, Jun 11, 2020 14:00 UTC	agenda | notes | reddit	video
40	Thu, May 28, 2020 14:00 UTC	agenda | notes | reddit
39	Thu, May 14, 2020 14:00 UTC	agenda | notes | reddit
38	Thu, Apr 23, 2020 14:00 UTC	agenda | notes | reddit
37	Thu, Apr 09, 2020 14:00 UTC	agenda | notes | reddit
36	Thu, Mar 26, 2020 14:00 UTC	agenda | notes | reddit	video
35	Thu, Mar 3, 2020 14:00 UTC	agenda | notes | reddit	video
34	Thu, Feb 27, 2020 14:00 UTC	agenda | notes | reddit	video
33	Thu Feb 06, 2020 14:00 UTC	agenda | notes | reddit	video
32	Thu, Jan 23, 2020 14:00 UTC	agenda | notes | reddit	video
31	Thu, Jan 09, 2020 14:00 UTC	agenda | notes | reddit	video
30	Thu, Dec 19, 2019 14:00 UTC	agenda | notes | reddit	video
29	Thu, Dec 5, 2019 14:00 UTC	agenda | notes | no reddit	video
28	Thu, Nov 21, 2019 14:00 UTC	agenda | notes | no reddit	video
27	Thu, Nov 7, 2019 14:00 UTC	agenda | notes | reddit	video
26	Thu, Oct 24, 2019 14:00 UTC	agenda | notes | reddit	video
25	Thu, Sep 9, 2019 14:00 UTC	agenda | notes | reddit	video
24	Thu, Aug 29, 2019 14:00 UTC	agenda | notes | reddit	video
23	Thu, Aug 15, 2019 14:00 UTC	agenda | notes | reddit	video
22	Thu, Jul 25, 2019 14:00 UTC	agenda | notes | no reddit	video
21	Thu, Jul 11, 2019 14:00 UTC	agenda | notes | reddit	video
20	Thu, Jun 13, 2019 14:00 UTC	agenda | notes | reddit	video
19	Thu, Jun 13, 2019 14:00 UTC	agenda | notes | no reddit	video
18	Thu, May 23, 2019 14:00 UTC	agenda | notes | reddit	video
17	Thu, May 02, 2019 14:00 UTC	agenda | no notes | no reddit	video
16	Thu, Apr 18, 2019 14:00 UTC	agenda | notes | no reddit	video
15	Thu, Mar 28, 2019 14:00 UTC	agenda | notes | no reddit	video
14	Thu, Mar 14, 2019 14:00 UTC	agenda | notes | reddit	video
13	Thu, Feb 28, 2019 14:00 UTC	agenda | notes | no reddit	video
12	Thu, Feb 14, 2019 14:00 UTC	agenda | notes | reddit	video
11	Thu, Jan 31, 2019 14:00 UTC	agenda | notes | no reddit	video
10	Thu, Jan 17, 2019 14:00 UTC	agenda | notes | reddit	video
9	Thu, Jan 03, 2019 14:00 UTC	agenda | notes | reddit	video
8	Thu, Dec 13, 2018 14:00 UTC	agenda | notes | reddit	video
7	Thu, Nov 29, 2018 14:00 UTC	agenda | notes | reddit	video
6	Thu, Nov 15, 2018 14:00 UTC	agenda | notes | reddit	video
5	Thu, Oct 11, 2018 14:00 UTC	agenda | notes | reddit	video
4	Thu, Sept 27, 2018 14:00 UTC	agenda | notes | reddit	video
3	Thu, Sept 13, 2018 14:00 UTC	agenda | notes | reddit	video
2	Thu, Aug 30, 2018 14:00 UTC	agenda | notes | reddit	video
1	Thu, Aug 16, 2018 14:00 UTC	agenda | notes | reddit	video
0	Thu, Aug 02, 2018 14:00 UTC	agenda | notes | reddit	video

eth2.0-pm's Issues

Eth2.0 Implementers Call 8 Agenda

Eth2.0 Implementers Call 8 Agenda

Meeting Date/Time: Thursday 2018/12/13 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Client Updates
2. Research Updates
3. "low hanging fruits" for testing
4. unsigned under and overflow problems
5. Spec discussion
6. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 10 Agenda

Eth2.0 Implementers Call 10 Agenda

Meeting Date/Time: Thursday 2018/1/17 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Client Updates
2. Research Updates
3. PoW -> PoS ether transfers
4. Test formats discussion
   • ssz
   • tree hashing
5. Spec discussion
6. Open Discussion/Closing Remarks

Eth2.0 Call 27 Agenda

Eth2.0 Call 27 Agenda

Meeting Date/Time: Thursday 2019/11/7 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing and Release Updates
2. Client Updates
3. Research Updates
4. Networking
5. Spec discussion
6. Testnets discussion
7. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 18 Agenda

Eth2.0 Implementers Call 18 Agenda

Meeting Date/Time: Thursday 2019/5/23 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. Network
5. interop lockin
6. beacon node validator api
7. Spec discussion
8. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 22 Agenda

Eth2.0 Implementers Call 22 Agenda

Meeting Date/Time: Thursday 2019/7/25 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. Network
5. Spec discussion
6. Open Discussion/Closing Remarks

stubbed eth1data votes for interop testing

stubbed eth1data votes for interop testing

Considering most of our initial interop tests will not have an associated eth1 chain to come to consensus upon via the eth1data vote mechanism, it is worth coming to a quick standard on how clients should stub this vote. The goal here is to actually not successfully come to consensus on a new eth1data value because they would then require deposit processing.

We may want to come up with a more clever mechanism that can actually handle deposits in the future, but for now we should just operate in such a way that disables deposits.

A proposer should fill their block.body.eth1_data with the following:

Eth1Data(
    deposit_root=hash(current_epoch),
    deposit_count=slot,
    block_hash=hash(hash(current_epoch)),
)

Alternative

An alternative to test that the eth1data mechanism actually updates is to use a mechanism that agrees upon deposit_root and block_hash and always keeps deposit_count at state.eth1_deposit_index so that the consensus does not force deposits even as eth1data is updated.

We could use the following for this:

epochs_per_period = SLOTS_PER_ETH1_VOTING_PERIOD // SLOTS_PER_EPOCH
voting_period = current_epoch // epochs_per_period
Eth1Data(
    deposit_root=hash(voting_period),
    deposit_count=state.eth1_deposit_index,
    block_hash=hash(hash(voting_period)),
)

Eth2.0 Call 25 Agenda

Eth2.0 Call 25 Agenda

Meeting Date/Time: Thursday 2019/9/19 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing and Release Updates
2. Client Updates
3. Research Updates
4. Network
5. Next interop steps
6. Spec discussion
7. Open Discussion/Closing Remarks

ETH 2.0 Meeting Oct 29th / Same day as EthMagicians?

Hello! I've heard that Oct 29th is a tentative date for meeting ahead of DevCon4, which is the same day as the EthMagicians Council.

Any way we can connect / overlap the two?

Eth2.0 Implementers Call 24 Agenda

Eth2.0 Implementers Call 24 Agenda

Meeting Date/Time: Thursday 2019/8/29 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing and Release Updates
2. Client Updates
3. Research Updates
4. Network
5. API proposal
6. Interop survey and retreat discussion
7. Spec discussion
8. Open Discussion/Closing Remarks

Eth2.0 Call 26 Agenda

Eth2.0 Call 26 Agenda

Meeting Date/Time: Thursday 2019/10/24 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing and Release Updates
   • v0.8.4
   • upcoming phase 0 semi-major release
   • muskoka
   • fuzzing
2. Client Updates
3. Research Updates
4. Testnet discussion
5. Spec discussion
6. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 21 Agenda

Eth2.0 Implementers Call 21 Agenda

Meeting Date/Time: Thursday 2019/7/11 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. Network
5. Spec discussion
6. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 20 Agenda

Eth2.0 Implementers Call 20 Agenda

Meeting Date/Time: Thursday 2019/6/27 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. Network
5. Move to discord
6. Graffiti in testing
7. Spec discussion
8. Open Discussion/Closing Remarks

Meeting

When will be the next call. I want to participate and discuss on stateless client concept.

Notes for Meeting 28

Take notes for Ethereum 2.0 call meeting 28.

Eth2.0 Implementers Call 13 Agenda

Eth2.0 Implementers Call 13 Agenda

Meeting Date/Time: Thursday 2019/2/28 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. Phase 0 Wire Protocol
5. Serialization
6. Spec discussion
7. Open Discussion/Closing Remarks

Production Readiness

Just want to begin a list and conversation of the things we need to be ready to move to production

• Long standing public testnet (how long?)
• Incentivized testnets
• Extensive Fuzzing
• Extensive static test vectors
• FV Deposit Contract
• FV BeaconChain safety+liveness
• Network stress testing to meet requirements with 300k+ validators split amongst N nodes (N == 10k?)
• 3 (absolute minimum of 2) clients "production ready"
  • External audits and security reviews
    • dos vectors
    • incentive analysis
  • Performed exceptionally in testnets

Notes for Meeting 24

The Cat Herders have allocated myself to take the notes for Meeting 24.

@djrtwo would it be possible to get the gitcoin bounty up and running to fund these notes?

Interop arbitrary state start

Problem

The interop spec states that clients must "start chain from specified state", which can be "some arbitrary state at any point in a chain's history".

I think this requirement is too broad. Lighthouse currently makes the assumption that it has all blocks/states up to the most recent finalized state. I would expect such assumptions to be common. It's also not clear how fork choice should behave without access to prior justified states.

The current scope also includes states that might be half-way through an epoch. Shuffling caches might make assumptions that if we're processing some block n > 1 deep into some epoch then we've already cached the shuffling.

I don't doubt that we could implement the ability to start from any arbitrary state, however I think it's a little premature and there would be quite a lot of edge-cases.

Suggestions

I think we we should reduce the scope of starting states to something like: the state from the first slot of a finalized epoch. I'm not even sure that's accurate.

I don't think it's worth us trying to define this scenario right now and my preference would be to say it's not a required for the Canada interop.

Testnet tooling

Creating a running list of tooling we need/want monitor and understand testnets. Please add additional items in the comments.

• ethstats for 2.0 (interest from lodestar)
• libp2p pubsub visualizer (proposal in the works from Protocol Labs)
• prometheus metrics (exists for many clients)
• eth2 block explorer (interest from existing ethereum block explorers)
• visualize validator queue/deposits
• fork monitor
• deposit interface and CLI (prysmatic has web interface, @CarlBeek working on both a web interface and CLI)
• --evil validator client command to induce slashable offenses

Call 21 Notes

• Create detailed notes for call 21 (#55)
• Add relevant links to README

Eth2.0 Implementers Call #0 Agenda

Eth2.0 Implementers Call #0 Agenda

This agenda was ported from another issue on a research repo. See here for original discussion.

Meeting Date/Time: Thursday 2018/08/02 at 14:00 GMT

Meeting Duration ~1 hour

Agenda

1. General Introduction of Sharding Meeting
2. Client Updates
3. Research Updates
4. Open Discussion
   • v2.1 spec
   • Conforming to p2p messages, prysmatic protocol buffers, and other p2p related discussion
   • BLS signature standard libraries
     • 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

Eth2.0 Implementers Call 3 Agenda

Eth2.0 Implementers Call 3 Agenda

Meeting Date/Time: Thursday 2018/9/13 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Client Updates
2. Research Updates
3. YAML test format
4. v2.1 Discussion
5. Let's form some at least tentative decision on the following:
   1. p2p serialization format
   2. p2p network protocol
   3. p2p discovery protocol
6. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 9 Agenda

Eth2.0 Implementers Call 9 Agenda

Meeting Date/Time: Thursday 2018/1/3 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream

Agenda

1. Client Updates
2. Research Updates
3. Spec discussion
4. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 11 Agenda

Eth2.0 Implementers Call 11 Agenda

Meeting Date/Time: Thursday 2019/1/31 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Client Updates
2. Research Updates
3. Number theoretic shuffling (ethereum/consensus-specs#323)
4. Any followup to @ledgerwatch comments from last meeting (#23 (comment))
5. Spec discussion
6. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 15 Agenda

Eth2.0 Implementers Call 15 Agenda

Meeting Date/Time: Thursday 2019/3/28 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. Network Updates
5. SSZ/SOS update from piper
   • ethereum/consensus-specs#787
6. Testnets progress, roadmap, PM
7. Spec discussion
8. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 19 Agenda

Eth2.0 Implementers Call 19 Agenda

Meeting Date/Time: Thursday 2019/6/13 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. Network
5. Spec discussion
6. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 16 Agenda

Eth2.0 Implementers Call 16 Agenda

Meeting Date/Time: Thursday 2019/4/18 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Briefings from workshop
4. Research Updates
5. Network Updates
   • libp2p
   • discovery
   • phase 0 networking protocol
   • network serialization
     • ethereum/consensus-specs#861
     • ethereum/consensus-specs#871
   • gossipsub tests
6. Spec discussion
7. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 7 Agenda

Eth2.0 Implementers Call 7 Agenda

Meeting Date/Time: Thursday 2018/11/29 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Client Updates
2. Research Updates
3. p2p discovery protocol
   • Current state of discv5
     • Does it meet our needs?
     • What implementations exist?
     • Complexity of implementing from scratch
   • Any alternatives being considered?
4. Validator privacy and roles
   • val privacy discussion
   • WIP min validator interface
   • prysmatic val service protos
   • pros/cons of strict polling interface (like eth1.0 rpc methods) vs streaming interface (something like grpc)
5. libp2p 2019 roadmap
6. Spec discussion
7. Open Discussion/Closing Remarks

Notes for Meeting 25

The Ethereum Cat Herders have assigned @poojaranjan to take these notes for meeting 25.

@djrtwo can you please arrange to have a gitcoin bounty posted for this purpose?

I am aware that there have been delays and issues around posting bounties for previous Eth2.0 neeting note taking - I am unclear as to the process but we would be keen to streamline it. Is this something that the Cat Herders can take on and work with yourself and gitcoin to make it more consistent?

Call 20 notes

• Create detailed notes for call 20 (#51)
• Add relevant links to README

Eth2.0 Implementers Call 5 Agenda

Eth2.0 Implementers Call 5 Agenda

Meeting Date/Time: Thursday 2018/10/11 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Client Updates
2. Research Updates
3. libp2p updates
4. Testing
5. Alternative tree storage structures
6. v2.1 Discussion
7. Open Discussion/Closing Remarks

Eth2 Networking Call 0

Meeting Date/Time:

Meeting Date/Time: Wednesday 2019/12/4 at 13:00 GMT

Meeting Duration:

1.25 hours

Agenda

1. Opening

2. Enumeration of network items being worked on and status updates

   • discv5
     • state of spec
     • dos resistance
     • fitness for shard sub-net advertisement?
       • time required to update advertisements
       • frequency ENRs can change without damaging protocol
       • etc
   • aggregation
     • any implementations of naive strategy? any feedback or issues?
     • state of research on sophisticated strategies
   • gossipsub
     • whiteblock
     • harmony simulations
     • alternative algorithms (?)
     • any effort to formalize the properties (?)
   • Items marked "mainnet" in spec
     • Noise
       • state of specs and implementations
       • any blockers?
     • multi-stream select 2.0
       • state of spec? blockers? any implementations?
     • yamux
       • just curious.. anyone implement this?
     • snappy
       • any issues in any languages for implementation?
   • TLS 1.3 and QUIC

3. Discussion of items that are under-{researched, tested, resourced} and plan of action

   • validator privacy

4. Open discussion

5. Closing remarks and plans for next call or other organizational items

Eth2.0 Implementers Call 4 Agenda

Eth2.0 Implementers Call 4 Agenda

Meeting Date/Time: Thursday 2018/9/27 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Client Updates
2. Research Updates
   • 3d visualization of beacon chain and shard blocks
3. Block processing timing results
4. libp2p daemon
   • work in progress repo
   • @raulk from Protocol Labs will be joining us
5. Testing
   • YAML chain test format
   • Proposed formats for SSZ tests
   • (empty) Unified Tests repo
6. Proposal to use separate serialization format for wire vs hashing
7. Alternative tree storage structures
8. v2.1 Discussion
9. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 6 Agenda

Eth2.0 Implementers Call 6 Agenda

Meeting Date/Time: Thursday 2018/11/15 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link TBD

Agenda

1. Client Updates
2. Research Updates
3. Working group followup
   a. notes: https://notes.ethereum.org/2-HRUzGjSc6jmwRgsVJqsg
4. min libp2p requirements
5. Proposal to use SSZ for consensus only
   a. Should we have two serialization formats?
   b. If so, what should the second be? (@rawfalafel suggests protobufs in the above issue)
6. big vs little endian
7. Spec discussion
8. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 14 Agenda

Eth2.0 Implementers Call 14 Agenda

Meeting Date/Time: Thursday 2019/3/14 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. quick update from raul/protocol labs
5. lighthouse benchmarks update
6. Leap seconds and time drift
7. Network spec
8. Quic(k) update
9. shuffling swap semantics
10. serialization benchmarks
11. Spec discussion
12. Open Discussion/Closing Remarks

Eth2.0 Phase 2 Community Call

Meeting Date/Time:

Tuesday 2019/12/03 at 15:00 GMT

Meeting Duration:

1.25 hours

Agenda

Team Updates

• Ewasm
• Quilt
• Eth 2 Research
• Other?

Discussion Time

The discussion time should be a casual Q&A. For this first meeting, we want to cover an overview and spend a max of 10 minutes per topic. If we don't make it through the entire agenda, we can continue discussion in the next community call.

1. Stateless, relayers & state providers (Will)
2. EE tooling (Axic + Matt)
3. Current accumulator work (Paul)
4. Metering/interpreter Benchmark (Casey)
5. Contract languages (Axic)
6. Cross Shard (Will + Proto)
7. Switchover (Casey)
8. Alternate Proposals (Casey + Will)
9. General Discussion

Meeting Link

Will be posted in relevant channels 15 minutes before

mocked start of eth2 for interop testing

mocked start of eth2 for interop testing

As we push forward toward interop testing, we need to conform on a standard to mock testnet starts across clients without an eth1 network from which to read deposits.

A network start consists of the following:

1. Genesis BeaconState
2. Network configuration
3. Agreed upon distribution of validators across nodes

Genesis state

Generate deposits

The genesis BeaconState is created from two parameters genesis_time and validator_count that can be specified either in a YAML file or as command-line params. This method is appealing because it is both simple and succinct. The main drawback of this method is that all validators are initialized with MAX_EFFECTIVE_BALANCE to start

A list of validator_count deposits is derived using the first validator_count pubkey/privkey pairs from a shared pubkey/privkey rainbow table of valid pubkey/privkeys generated in the method below. withdrawal_credentials for each are set to BLS_WITHDRAWAL_PREFIX + hash(deposit.data.pubkey)[1:]. amount for each is set to MAX_EFFECTIVE_BALANCE.

Create genesis state

Clients must create the genesis state by calling initialize_beacon_state_from_eth1() with coordinated junk values for eth1_block_hash = b'\x42'*32 and eth1_timestamp = 2**40, and with the list of deposits created in the prior section. The returned BeaconState must then be modified with state.genesis_time = specified_genesis_time.

Clients must not run is_valid_genesis_state as this state is already considered valid. Specifically, we do not check nor care about MIN_GENESIS_TIME in these coordinated starts.

Network configuration

The specs repo already contains two configuration presets -- mainnet and minimal. minimal will likely serve as a good choice for many interop tests. If there are components of this configuration that do not serve a specific need, we can add more configurations here.

Distribution of validators across nodes

Simple: Do an even split between the various client teams participating and the initial validator indices. Client teams will then provision their nodes with some distribution of validators that they control. The rainbow table for pubkeys/privkeys should enable any distribution desired in a given test.

Another option is to add more coordination params to a YAML file validator_map that maps pubkeys to node_ids ({pubkey: node_id) where each client team runs a set of node_ids.

Seeking feedback on how we might bettercoordinate nodes, pubkeys, etc. Keeping it super simple to start.

Pubkey/privkey generation

The following script is used to generated pubkey/privkeys for the first N validators. The i-th deposit/validator index uses the validator_index_to_pubkey[i] pubkey and associated privkey.

Note, this deterministic privkey algorithm is not secure (due to severe modulo bias) and should only be used for testing purposes.

CURVE_ORDER = 52435875175126190479447740508185965837690552500527637822603658699938581184513
validator_index_to_pubkey = {}
pubkey_to_privkey = {}
privkey_to_pubkey = {}
for index in range(N):
    privkey = int.from_bytes(
        sha256(int_to_bytes(n=index, length=32)),
        byteorder='little'
    ) % CURVE_ORDER
    pubkey = bls.privtopubkey(privkey)
    pubkey_to_privkey[pubkey] = privkey
    privkey_to_pubkey[privkey] = pubkey
    validator_index_to_pubkey[index] = pubkey

Call 22 Notes

• Create detailed notes for call 20 (#64)
• Add relevant links to README

Eth2.0 Implementers Call 1 Agenda

Eth2.0 Implementers Call 1 Agenda

Meeting Date/Time: Thursday 2018/8/16 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Client Updates
2. Research Updates
3. Updated BeaconChain spec
   • issues in shuffling algorithm and proposed changes ethereum/beacon_chain#57
4. P2P research
   • update on network simulations
   • Zak from WhiteBlock will be joining us. He has a network simulation platform and would like to aid in vetting the libp2p protocols for our purposes
   • beacon chain wire protocol
   • message serialization
5. Bootstrapping initial validator set
6. Pre-devcon sharding meetup
   • Potential share space with Status hackathon
   • Length of meetup?
7. Open Discussion/Closing Remarks

Notes for Meeting 26

The Ethereum Cat Herders have assigned @DBrettRobertson to take these notes for meeting 26.

@djrtwo can you please arrange to have a gitcoin bounty posted for this purpose?

Eth2.0 Call 28 Agenda

Eth2.0 Call 28 Agenda

Meeting Date/Time: Thursday 2019/11/21 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing and Release Updates
2. Client Updates
3. Research Updates
4. Domain specific calls
   • eth1x
   • phase 2
   • networking
   • light client task force
5. Networking
   • quick notes from protocol labs
6. Spec discussion
   • issues with and options for signing root
7. Testnets discussion
8. Open Discussion/Closing Remarks

Eth2.0 Implementers Call 23 Agenda

Eth2.0 Implementers Call 23 Agenda

Meeting Date/Time: Thursday 2019/8/15 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing and Release Updates
2. Client Updates
3. Research Updates
   • VDF update
4. Network
   • Block capacity and compression
   • BFT vs scalability in p2p network
5. Spec discussion
6. Open Discussion/Closing Remarks

sharding attestation policing across validators/nodes

sharding attestation policing across validators/nodes

For the network to be well-policed wrt attestation slashings, we need to actively be checking for slashable attestations within the "weak subjectivity period". The weak subjectivity period is variable in eth2 due to the validator queuing mechanism, but it is on the order of ~8 months when 10M eth (300k validators) are participating.

This brings up the non-trivial challenge of efficiently storing attestations and related data, and searching through this space on demand when new (and potentially historic) attestations come in.

After some consideration on the load of Attestations and search data that needs to be stored, it seems prudent to default shard this responsibility across nodes/validators rather than have each validator attempt to store and search the entire space. It is also assumed that large data consumers (block explorers, API providers, etc) will store and search the entire space.

This issue discusses both the efficient search algorithms, along with a discussion on to splitting up the search space.

Slashing search

There are two types of slashable attestations -- "double vote" and "surround vote". Double votes are relatively simple to find, whereas surround takes a little more consideration.

The strategies discussed here attempt minimize database reads for attestations when searching and instead rely upon relevant bitfields and epochs related to each validator. If a slashing is detected, then a more intensive find for the particular attestation from the DB is warranted.

Double vote

Detecting a double vote is relatively simple and requires storing only N bits per validators where N is the number of epochs in the weak subjectivity period. When a new attestation comes in for epoch, for each validator in the attestation, check if double_vote bit for validator at epoch is set to 1. If set to 1, found slashable message, retrieve from DB. If set to 0, set to 1.

This is a constant time search and constant time update per validator so linear in the number of validators in an attestation.

Surround vote

Detecting a surround vote is a bit more complex and requires more data. An algorithm developed by @vbuterin requires 2*N*log(N) bits per validator. The search is constant time per validator and the data update is linear in the worst case but normally likely sub-linear, near constant time update.

The algorithm requires storing 2*N epochs per validator. The basic principle is the following:

For each epoch E and for each validator, maintain the highest target epoch of an attestation whose source <= E. This creates an always-sorted list that can be updated by starting from the attestation's source position in the array and then continuing to move right until no longer adjusting the maximum. When a new attestations is received, check it against that list for each validator in the attestation to find if the new attestation is surrounded by any prior attestation. To check if the new attestation surrounds an earlier attestation, maintain the opposite of the above described array and perform the opposite checks.

Sharding responsibility

Although these algorithms are very efficient in search time, the data requirement for maintaining these lists can actually become quite large in addition to the already large data requirement of storing historic attestations through the weak subjectivity period, thus the need to shard responsibility of the attestation slashing search spec across validators.

We recommend strong client defaults in this matter to (1) provide sufficient policing of the network in the case that the 2/3 honesty assumption fails wrt safety while at the same time (2) do not place excessive resource requirements on any one validator to do so.

In addition to consumer node policing, we fully expect large data users to execute policing of the full dataset as they already will be storing it for other purposes. Fortunately, policing of attestations works if a minimum of one honest user sufficiently monitors the entire weak subjectivity period worth of attestations.

There are multiple options for strong user defaults, the most appealing of which scales as the number of validators working off of a node, but as most BN vs VC architecture does not persistently store which validators are connected to a BN, this might require additional tracking that is not currently in place. To this end, a BN could catalogue for which pubkeys validator attestation creation requests have been made and scale responsibility that way. If the user default goes in this direction, it likely makes sense to not broadcast slashable attestations immediately when found and instead to package them into blocks eventually for the one of the associated pubkeys connected to the BN and for the profitability of the validator.

An alternative is to have a slightly higher per-node default epoch range that a node is responsible for and disregard which validators might be connected. In this case, it likely makes sense to instead immediately broadcast slashable messages to be picked up by any validator to be put into a block. Due to the node not persistently knowing if validators are connected to it, a slashable message might be kept around locally for an indefinite period of time and not serve value to the network.

agenda faq

Does someone working on https://ethresear.ch/t/the-stateless-client-concept/172 I would like to participate in it.

Eth2.0 Implementers Call 2 Agenda

Eth2.0 Implementers Call 2 Agenda

Meeting Date/Time: Thursday 2018/8/30 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Client Updates
2. Research Updates
3. Beacon chain testing lang
   • Vitalik test-string proposal
   • Prysmatic revised proposal
4. Q/A on v2.1
   • shuffling algorithm
   • anything else
5. Practical details of random beacon and committee selection
6. Practical VDF implementations
7. Cross-shard communication
   • Simple synchronous cross-shard txs
   • Cross-shard contract yanking
   • Merge blocks and synchronous cross-shard state execution
   • async communication via cross-links
8. Proof of Custody
9. Pre-devcon meetup
10. Open Discussion/Closing Remarks

Notes for Meeting 23

The Cat Herders have allocated Jim Bennett to take the notes for Meeting 23.

@djrtwo would it be possible to get the gitcoin bounty up and running to fund these notes?

BLS12-381 curve and aggregation libraries

I'm gathering info about the state of BLS12-381 implementations and associated signature/aggregation libraries. Please let me know any corrections or missing data.

BLS12-381 Curve implementations

Repo	Language	License	Audit	Notes
ZCash pairing library in Rust	Rust	MIT or Apache 2.0 (option)	Kudelsk	Audit to be published "soon"
Chia BLS12-381 in cpp	cpp	Apache 2.0	"when done"
Chia BLS12-381 in python	Python	Apache 2.0	"when done"
Chia python bindings	python	Apache 2.0	"when done"	python bindings for cpp implementation
Nim wrapper for Chia cpp	Nim	MIT	None	wraps Chia cpp so those components are Apache 2.0
Herumi MCL	cpp	modified BSD	not sure
Milagro Crypto	C, cpp, Go, Java, JS, Python, Rust, Swift, WASM	Apache 2.0	not sure	potential issues or unknowns with licensing
py_ecc	Python	MIT	None

BLS signature libraries

Repo	Language	License	Audit	Notes
Herumi BLS	cpp, go	modified BSD		uses Herumi MCL

NOTE: About to take off on a flight. I think the "BLS12-381 Curve implementations" is done to the best of my knowledge, but I haven't had a chance to add all of the "BLS signature libraries". Coming soon.

Eth2.0 Implementers Call 12 Agenda

Eth2.0 Implementers Call 12 Agenda

Meeting Date/Time: Thursday 2019/2/14 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. discv5 update/discussion
5. Quick note on light clients
6. Minimal phase 0 wire api
7. Path to testnets
   • suggested reading: https://lighthouse.sigmaprime.io/update-07.html
8. Genesis slot number & signed vs unsigned ints
9. Spec discussion
10. Open Discussion/Closing Remarks

Notes for Meeting 27

Take notes for Ethereum 2.0 Call meeting 27.

Eth2.0 Implementers Call 17 Agenda

Eth2.0 Implementers Call 17 Agenda

Meeting Date/Time: Thursday 2019/5/2 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link TBD

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. Network
   • libp2p updates
   • discv5 in the context of libp2p
   • gossipsub testing
5. Spec discussion
6. Open Discussion/Closing Remarks