Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eth2.0 Implementers Call 14 Agenda #33

Closed
djrtwo opened this issue Mar 11, 2019 · 11 comments

Comments

Projects
None yet
9 participants
@djrtwo
Copy link
Collaborator

commented Mar 11, 2019

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
@jrhea

This comment has been minimized.

Copy link

commented Mar 12, 2019

I watched Justin's talk at EthCC and he mentioned that slots will account for leap seconds. Can we talk about the reason why this is necessary? Also, I'd like to hear what other people think about the potential problem with time drift and if we plan on using some sort of method for time sync.

@zscole

This comment has been minimized.

Copy link

commented Mar 12, 2019

I watched Justin's talk at EthCC and he mentioned that slots will account for leap seconds. Can we talk about the reason why this is necessary? Also, I'd like to hear what other people think about the potential problem with time drift and if we plan on using some sort of method for time sync.

Yes, I have opinions.

I would also like to discuss the need for TLS support in the wire protocol. I don't think this is necessary and would only incur additional overhead.

@Mikerah

This comment has been minimized.

Copy link

commented Mar 12, 2019

Can we let the Pegasys team go into details about their results on using QUIC for handel? They posted a summary in this issue and I think it can help in informing us in which transports to support/use.

@bkolad

This comment has been minimized.

Copy link

commented Mar 13, 2019

@Mikerah thanks for bringing it, sure we can give an update about our experience with QUIC.

@nkeywal

This comment has been minimized.

Copy link

commented Mar 13, 2019

Can we let the Pegasys team go into details about their results on using QUIC for handel? They posted a summary in this issue and I think it can help in informing us in which transports to support/use.

We're more than happy to do a quic(k) update during the call :-)

@protolambda

This comment has been minimized.

Copy link

commented Mar 14, 2019

ethereum/eth2.0-specs#774
(TLDR: spec defines shuffling as a way to retrieve the right validators by querying for a sequential subset of the output, i.e. a committee. This is technically un-shuffling. Shuffling here is technically only really used in implementation to get the new list permutation from the old list permutation)

Discussion about semantics of shuffling, short read, just something to agree on. Would like to discuss this in the call. Vitalik also mentioned another related issue: ethereum/eth2.0-specs#729
(TLDR: in phase 1 we introduce a "shard" param to get a specific committee, which is also really just a sequential subset of the shuffled list.

@paulhauner

This comment has been minimized.

Copy link

commented Mar 14, 2019

I have been bench-marking per-block/state processing across different hardware (my laptop and desktop) with different validator counts and scenarios (full block, not-so-full block).

I don't have a whole lot to say that isn't in the doc (apart from that I am sick of markdown tables). Happy to field questions or feedback though :)

https://github.com/sigp/serenity-benches

@leobago

This comment has been minimized.

Copy link

commented Mar 14, 2019

I have been bench-marking per-block/state processing across different hardware (my laptop and desktop) with different validator counts and scenarios (full block, not-so-full block).

I don't have a whole lot to say that isn't in the doc (apart from that I am sick of markdown tables). Happy to field questions or feedback though :)

https://github.com/sigp/serenity-benches

It seems the links to the source codes are not working.

@paulhauner

This comment has been minimized.

Copy link

commented Mar 14, 2019

It seems the links to the source codes are not working.

Thanks for the heads up!

I've pulled them out for now. You can find the source here: https://github.com/sigp/lighthouse/tree/master/eth2/state_processing/src :)

Most optimized is here: https://github.com/sigp/lighthouse/tree/sane-case/eth2/state_processing/src

@djrtwo

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 14, 2019

Quick update from Raul from Protocol Labs:

We’re working to add deprecation notices to the areas of the spec that are outdated.
Making significant strides with https://docs.libp2p.io
Writing a non-normative walkthrough of the libp2p stack that everybody can use as a reference
Engaging in various debates on GitHub

@zscole

This comment has been minimized.

Copy link

commented Mar 14, 2019

@djrtwo djrtwo closed this Mar 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.