Eth2.0 Implementers Call 6 Agenda

[djrtwo]

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

[Mikerah]

Can we add summaries of the working groups from the Sharding session in Prague? I think we all have something to share or thoughts that came up during that day.

[lrettig]

Some of the notes are here: https://notes.ethereum.org/2-HRUzGjSc6jmwRgsVJqsg

[Mikerah]

@lrettig I've been through all of them. But, one thing that I gathered from talking to people at Devcon is that it all of this goes over their heads and thus makes our work unaccessible. I think we should make an effort to make these calls little more accessible by going over thought processes, clarifications,etc.

[lrettig]

Is the purpose of the calls for the teams working on ETH 2.0 implementations to coordinate, or to make our work more accessible to the general public? Not a rhetorical question (and to be clear there are some synergies between the two--we should of course strive for things to be as accessible as possible, other things being equal, to enfranchise more people and get them excited to contribute).

[Mikerah]

Mostly the former but a little of the latter. Some of the people I've spoken to are mystified about where to get a lot of the information related to ETH 2.0. Some people also feel left out from contributing since it seems out of reach. I'm not saying we should have a section of the call dedicated to getting people up to date. During the calls, it is understood among us implementers what we are discussing but it may not be obvious to others. I think we may need to be more cognizant of this during the calls.

As a side note, personally, I am planning some articles in order to help demystify this for others, instead of me just mentioning it on this issue.

[lrettig]

One final thought: while I do think it's incumbent upon us, generally speaking, to make our work as accessible to as broad a segment of the community as possible, I actually don't think this particular call is the right vehicle for that. Curious what others think.

[Mikerah]

@lrettig, I wasn't talking about this particular call but more about future calls. Also, my first comment in this issue, to clarify, was about adding a recap from the working groups into the agenda for Thursday's call. I guess it went out of hand.

[rawfalafel]

Can't make the call (sorry!) but I opened an issue that might be worth discussing: ethereum/consensus-specs#129

[arnetheduck]

I prefer that the call is focused on coordinating development. If we end up using it for education, we will need a separate coordination call, or lose depth and efficient time use.

For context, the teams are publishing education material and updates as we go along - I find these, as well as "story-like" overviews from conference presentations, podcasts and of course https://notes.ethereum.org/9MMuzWeFTTSg-3Tz_YeiBA?view# more valuable.

[Swader]

Bruno from Nimbus here, education would likely detract too much from dev so agreed, no need to discuss it in detail today, we wordy types can have a separate "Eth 2.0 educators" call if needed. I have started a new peer review repo in an effort to forward education: https://github.com/status-im/the-explainers - all the info on collaboration is in there, @Mikerah I'd be super happy to get you involved somehow.

[paulhauner]

I would like to discuss why the shard sync should be handled inside the beacon chain instead of outsourced to separate binaries. I can probably just bring this up during the working group recap.

[mkalinin]

Would be great to get a quick update on the fork choice rule, the latest algorithm that researchers are leaning too.

[djrtwo]

From @arnetheduck:

what would the appetite be for switching to little endian throughout in serializations?

• +LE won the endian struggle on commodity hardware - can save a few operations here and there, exploiting mmap, bulk memcpy instead of item-by-item copies etc on most hardware - in other words, actually make better use of the fixed-size properties of SSZ

• -there's a tendency to use BE in network protocols for historical reasons, so inconsistent
• -having BE forces people to remember that endianess still might be a thing (eg on MIPS)
  if there's interest at all, I could write up an RFC

[aj07]

@djrtwo Whats the streaming link ?

[pggallagher]

@djrtwo Whats the streaming link ?

https://www.youtube.com/watch?v=VNwANifX7qE

[zastil]

Nice has Vitalik any input on this?